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

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

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

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

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

    面向中小企業綜合管理系統的開發中，日方為節約開發成本、縮短開發周期，有些項目沒有書寫詳細設計的時間，因此實際項目的開發過程如圖4所示?？蚓€內的部分是日方擔當，其余部分由中方公司擔當。此過程是分階段同時并行作業的，即不是日方概要設計全部完成后再進行開發，而是在整體的數據庫DB設計、整體的功能一覽表、一部分業務功能的概要設計完成后就進行開發。在概要設計中要表達用戶操作系統時的交互畫面的設計，畫面項目與數據庫表中字段的對應關系以及所要實現的業務等要表達清楚。

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

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