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

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

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

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

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

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

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

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