摘 要： 軟件外包是近幾年國(guó)內(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è)為了專注核心競(jìng)爭(zhēng)力和降低軟件項(xiàng)目成本，將軟件項(xiàng)目的全部或部分工作發(fā)包給提供服務(wù)的企業(yè)以完成軟件需求的活動(dòng),。一般是委托方與承包方不在同一場(chǎng)所工作,。
    目前在國(guó)內(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)是：簡(jiǎ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.