摘 要： 軟件外包是近幾年國內(nèi)發(fā)展迅速的產(chǎn)業(yè)。一般是委托方擔(dān)當(dāng)系統(tǒng)的概要設(shè)計，中方擔(dān)當(dāng)詳細(xì)設(shè)計、編程、單體測試以及集成測試。由于地域、語言、文化等差異，如何保證項目的質(zhì)量，時常成為困擾企業(yè)的難題。在實際的面向中小企業(yè)統(tǒng)合管理系統(tǒng)項目的開發(fā)基礎(chǔ)上，通過分析影響實際項目質(zhì)量的主要因素，總結(jié)并提出了在不寫詳細(xì)設(shè)計文檔的情況下，加強概要設(shè)計的復(fù)審，加強溝通環(huán)節(jié)以保證軟件項目質(zhì)量的一些觀點。這種方式下開發(fā)的系統(tǒng)其品質(zhì)得到了較好的控制并取得了客戶的認(rèn)可。
關(guān)鍵詞： 軟件外包； 項目質(zhì)量； V模型； offshore; 瀑布模型； 概要設(shè)計； 詳細(xì)設(shè)計

    軟件外包就是企業(yè)為了專注核心競爭力和降低軟件項目成本，將軟件項目的全部或部分工作發(fā)包給提供服務(wù)的企業(yè)以完成軟件需求的活動。一般是委托方與承包方不在同一場所工作。
    目前在國內(nèi),離岸軟件外包（offshore）是一個發(fā)展迅速的行業(yè),雖然軟件的設(shè)計、制造、測試都已經(jīng)流程化,并且運用軟件工程來規(guī)范,但是由于語言、文化、地域等差異,使得軟件開發(fā)的質(zhì)量得不到保證。以下是在實際工作中總結(jié)出的為控制項目質(zhì)量而需要著力解決的幾個比較重要的方面。 
1 項目計劃
    制作項目計劃書，如表1所示。

    項目負(fù)責(zé)人在項目立項前就進度、人員配備、配置管理等各項活動進行計劃，并形成文檔。系統(tǒng)開發(fā)計劃書由系統(tǒng)概要、開發(fā)體制、進度計劃等構(gòu)成。
    項目計劃書是跨部門多人溝通的文檔，它有助于項目負(fù)責(zé)人在項目啟動前，將項目中應(yīng)有的資源及風(fēng)險做提前的部署與對應(yīng)，并為項目的獨立監(jiān)查及質(zhì)量跟蹤提供依據(jù)。
2 溝通的管理
    項目計劃階段除了要將中方與日方的角色與職責(zé)明確定義外，雙方的作業(yè)流程也要明確，特別是窗口的溝通體制要明確。目前對日外包項目比較多的是圖1所示的溝通管理作業(yè)形式，中方的作業(yè)范圍是從詳細(xì)設(shè)計開始，編程、單元測試及集成測試。中方的BSE起到雙方溝通的橋梁作用，溝通的方式可以采用電子郵件E-mail、電視會議、即時聊天工具、使用開發(fā)的管理工具等。由于外包開發(fā)的設(shè)計人員與編程人員不在同一地點，因此溝通的準(zhǔn)確與及時就顯得格外重要。項目組成員的所有疑問都應(yīng)該使用QA表進行統(tǒng)一的管理，QA表中記錄了本項目的所有開發(fā)人員所提出的疑問及待確認(rèn)項目以及日方擔(dān)當(dāng)人員的回答內(nèi)容；特別是對于共通的問題開發(fā)全體人員都要周知，這樣有助于所有開發(fā)人員對項目整體的理解并且便于統(tǒng)一的管理。

3 影響項目質(zhì)量的主要因素
    除了要做好上述的項目計劃、做好溝通管理外，實際的項目經(jīng)驗是開發(fā)周期(是否過短)、所接收的客戶設(shè)計書的質(zhì)量、設(shè)計書的變更情況、業(yè)務(wù)的復(fù)雜度、開發(fā)人員的技術(shù)水平、項目負(fù)責(zé)人的管理能力、是否有新技術(shù)的風(fēng)險、開發(fā)的規(guī)模(規(guī)模越大質(zhì)量與成本的風(fēng)險就越大)等各因素都直接影響到最終項目的質(zhì)量與成本。影響項目質(zhì)量的因素繁多并且很復(fù)雜，但比較重要的有以下幾點：
    (1)日方的概要設(shè)計書的質(zhì)量
    在軟件的整個生命周期中，軟件產(chǎn)品的質(zhì)量首先取決于它的設(shè)計，設(shè)計質(zhì)量控制在全面質(zhì)量管理中也是非常重要的一個環(huán)節(jié)。據(jù)統(tǒng)計，設(shè)計錯誤占軟件錯誤的63%,編碼錯誤僅占37%[1]。在編程之前，進行概要設(shè)計的復(fù)審(即設(shè)計Review)很重要。
    是否變更很頻繁,業(yè)務(wù)的描述是否詳細(xì),概要設(shè)計書的文檔格式是否標(biāo)準(zhǔn)化。復(fù)雜的邏輯判斷要盡量用圖形或表格，盡量使用數(shù)學(xué)語言(A=B)表達(dá)。
    圖2是針對已完成的6個項目(每個符號代表一個項目)，對影響項目的部分因素進行分析評價的結(jié)果。從中可以看到，日方設(shè)計書的質(zhì)量、變更以及管理情況對項目的質(zhì)量有較大的影響。

    (2)開發(fā)團隊人員的配置也很重要。PL(項目負(fù)責(zé)人)、BSE以及SE的項目經(jīng)驗，BSE要對項目有整體的理解并與日方設(shè)計人員進行有效的溝通；SE對設(shè)計書復(fù)審、提QA并做集成測試；PG做代碼編寫及單元測試。從所做項目的質(zhì)量分析結(jié)果來看，系統(tǒng)Bug的20%左右是設(shè)計書理解有誤所引起的，因此加強溝通確認(rèn)設(shè)計書也很重要。
4 實際項目的開發(fā)流程
    “瀑布模型(Waterfall Model)”是由溫斯頓·羅伊斯(Winston Royce)于1970年提出的，直到20世紀(jì)80年代早期，它一直是唯一被廣泛應(yīng)用于軟件開發(fā)領(lǐng)域。瀑布模型將將軟件生命周期劃分為制定計劃、需求分析、軟件設(shè)計、程序編寫、軟件測試和運行維護等6個基本活動。
　    瀑布模型的特點是：簡單，分階段，階段間存在因果關(guān)系，各階段完成后都有評審，要求預(yù)先確定需求。適用的范圍是易于完善定義且不易變更的軟件系統(tǒng)[2]。本階段的成果作為下一階段的輸入；對本階段的工作進行評審，若本階段的工作得到確認(rèn)，則繼續(xù)下階段的工作。只有前一階段的輸出文檔正確，后一階段的工作才能獲得正確的結(jié)果。通常它適用于需求分析做得比較好的系統(tǒng)，例如二次開發(fā)系統(tǒng)等。
    瀑布模型是開發(fā)模型，而V模型是測試模型，V模型[3](見圖3)是最廣為人知的測試模型。
    單元測試所檢測的是代碼的開發(fā)是否符合詳細(xì)設(shè)計的要求。集成測試檢測此前測試過的各組成部分是否能完好地結(jié)合到一起。系統(tǒng)測試檢測已集成在一起的產(chǎn)品是否符合最終用戶的需求。一般項目開發(fā)的過程順序如表2所示。   

    面向中小企業(yè)綜合管理系統(tǒng)的開發(fā)中，日方為節(jié)約開發(fā)成本、縮短開發(fā)周期，有些項目沒有書寫詳細(xì)設(shè)計的時間，因此實際項目的開發(fā)過程如圖4所示。框線內(nèi)的部分是日方擔(dān)當(dāng)，其余部分由中方公司擔(dān)當(dāng)。此過程是分階段同時并行作業(yè)的，即不是日方概要設(shè)計全部完成后再進行開發(fā)，而是在整體的數(shù)據(jù)庫DB設(shè)計、整體的功能一覽表、一部分業(yè)務(wù)功能的概要設(shè)計完成后就進行開發(fā)。在概要設(shè)計中要表達(dá)用戶操作系統(tǒng)時的交互畫面的設(shè)計，畫面項目與數(shù)據(jù)庫表中字段的對應(yīng)關(guān)系以及所要實現(xiàn)的業(yè)務(wù)等要表達(dá)清楚。

    這樣做的好處是：在開發(fā)的同時做下一階段的概要設(shè)計，可縮短項目整體的周期，節(jié)約成本；另外在項目開發(fā)過程中，經(jīng)常有概要設(shè)計的變更，概要設(shè)計頻繁變更時，詳細(xì)設(shè)計就要頻繁地對應(yīng)，實際的情況是最終很難保證兩套設(shè)計文檔與代碼的一致，結(jié)果都是只能夠維護一套文檔。
    不利點是：由于缺少書寫詳細(xì)設(shè)計的環(huán)節(jié)，為了保證項目質(zhì)量，就必須追加概要設(shè)計書的復(fù)審環(huán)節(jié)。同時，概要設(shè)計文檔的書寫格式也要規(guī)范化，具體的措施是:
    (1)在開發(fā)前，項目整體的共通要求必須要明確,包括交互界面的共通要求等。
    (2)用統(tǒng)一的概要設(shè)計的文檔格式，畫面項目與數(shù)據(jù)庫項目的對應(yīng)、業(yè)務(wù)功能的描述等要明確。
    (3)系統(tǒng)的命名規(guī)約、函數(shù)接口的命名方法以及共通函數(shù)等共通事項必須事先定義。
    (4)編碼之前,必須要有SE的概要設(shè)計復(fù)審及QA確認(rèn)環(huán)節(jié)。檢查概要設(shè)計的漏點及錯誤等，并通過QA確認(rèn)，在編碼之前，將這些錯誤及不明確點解決掉。事實上，在開發(fā)過程中發(fā)生的許多概要設(shè)計的變更是由SE在概要設(shè)計復(fù)審以及在PG編程前發(fā)現(xiàn)的概要設(shè)計的誤記或考慮不足以及設(shè)計錯誤。
    目前，實際開發(fā)的項目許多是采用圖4所示的開發(fā)過程及圖5所示的測試模型。經(jīng)驗證，項目整體的質(zhì)量得到了較好的控制，并且已滿足客戶的要求。

    實踐證明，面向中小企業(yè)開發(fā)的統(tǒng)合管理系統(tǒng)的項目中，不寫詳細(xì)設(shè)計，在開發(fā)的環(huán)節(jié)中增加概要設(shè)計的復(fù)審；同時，開發(fā)前統(tǒng)一定義好共通函數(shù)及接口、命名規(guī)范等同樣能保證項目的質(zhì)量。外包開發(fā)中，溝通環(huán)節(jié)(即QA確認(rèn))實施是否順暢，對項目的質(zhì)量影響較大。
參考文獻(xiàn)
[1] 張海藩.軟件工程導(dǎo)論（第三版）1.2.1[M].北京: 清華大學(xué)出版社,1998.
[2] 譚慶平，毛新軍，董威.軟件工程實踐教程文獻(xiàn)題目[M]. 北京：高等教育出版社,2009.
[3] GOLDSMITH R F. 軟件測試:V模型，還是X模型[Z]. 開放軟件測試研究，2003.