1.5 軟件外包的一般流程概述

軟件外包是一種軟件開發項目的活動，因此按照軟件工程的一般規律，一個軟件項目通常要經歷需求分析、設計、編碼、測試、交付、維護等一系列的階段，伴隨這個軟件生命周期的還有商務活動、項目管理和質量保證活動、信息安全管理的相關管理工作。

下面將概要講述軟件項目的開發周期及相關的活動。

1.5.1 項目接洽

軟件外包項目的需求，來自開發組織之外，因此，項目的需求和來源是項目啟動的原始依據。當一個企業根據自己的生產和經營情況，需要應用IT技術進行信息處理，或對原有的信息處理系統進行升級改造時，就產生了軟件需求。如果要將軟件開發任務發包給外包的專業軟件開發公司完成，則內部的信息管理部門應做好了必要的準備工作，如軟件需求的大致內容、目標范圍、可行性分析報告、費用預算等，經過了高層管理者的批準，才能發布招標信息，進行發包工作。

一般來說，企業發包軟件采用兩種方式發布軟件外包信息，一種是通過媒體發布招標信息，另一種是直接在有良好合作關系的軟件公司范圍內選擇合適的開發商。

軟件開發商一般通過市場公開信息，收集到有軟件需求的企業，通過銷售人員與技術人員的配合，與發包方進行項目接洽。如果是長期合作的客戶發來軟件需求，一般通過已有的項目負責人先行進行接洽，弄清基本需求后，在公司內經過研究，符合公司的經營策略，能夠勝任此項工作，則組織合適的人員參與項目初步調研，形成軟件需求分析報告和可行性報告。

項目接洽屬于商務活動的范圍，但是與技術相關性很大，因為洽談項目必須就軟件的功能、開發技術、開發環境進行商談，這是軟件外包項目的特點所致。因此營銷人員在軟件項目洽談中，必須具備一定的IT應用技術基礎和一定程度的解決方案咨詢能力，完全脫離軟件技術的銷售，難以達到理想的效果。

曾經有過不懂IT技術的銷售人員，到客戶現場后，滿口答應可以為客戶提供滿意的解決方案，但是回公司后，經過與技術人員溝通，發現不完全具備開發客戶需求的軟件的能力，結果再跟客戶溝通時，就非常被動了。此種情況下，也會發生銷售人員與技術人員之間的矛盾，銷售人員對銷售業績負責，而技術人員對實現的結果負責，如果二者沒有相互緊密地合作，則難以達到配合默契的程度。

1.5.2 需求分析與報價

當銷售人員或者項目負責人，與客戶方面就項目進行了洽談，被接受作為候選的開發商后，技術人員可以到客戶現場進行較詳細的項目需求調研。調研的內容，既要作為將來項目開發的范圍也要作為預算的依據。在軟件外包協議沒有簽訂之前，需求分析的結果，主要用于對工作量和技術要求的分析，并以此作為項目費用預算的依據。

目前軟件項目的報價單位，基本上以工作量為主，也就是根據需求和項目范圍，采取多種方法來評估工作量，工作量的單位是人月，即一個人干一個月的工作量級。根據技術難度和市場價格，確定一個人月單價，軟件外包項目的總預算即為預估的總人月數乘以人月單價。

有很多專著對軟件項目的報價進行了論述。但是，無論何種方法，都存在各自的優點和缺陷。因為軟件項目是人的腦力勞動，技術含量很高，勞動成果的表現形式雖然是程序代碼，但是各階段的成果還是因人而異的，而且水平和質量相差很大，即使是相同質量的結果，勞動效率也有差異。所以要準確評估軟件項目的費用，是一件比較困難的事情。

1.5.3 項目啟動與項目管理

項目啟動不是一個項目的開工儀式，而是項目開始階段的一系列活動。項目啟動本身屬于項目管理的范疇。但是由于項目啟動的重要性，因此將它單獨闡述一下。

項目啟動包含的主要活動如下。

（1）由項目的承擔組織高層管理者宣布項目經理及其職責，并以文件的方式正式任命與發布。

（2）由項目經理編寫項目章程，該章程將項目的背景、目標、項目組織結構及成員、主要角色職責、項目范圍及相關條件和約束、項目總體計劃（預計開始日期、預計結束日期）、項目風險及其對策等做出明確說明。項目章程作為下一階段管理過程的依據，為整個項目定下了總體框架。

（3）正式的項目啟動會議和儀式。

項目管理包含了項目從啟動到結尾全部內容的管理過程，是為了使軟件項目能夠按照預定的成本、進度和質量順利完成，而對人員、產品、過程和項目進行分析、監控和管理的活動。項目管理活動貫穿整個項目進行的過程。項目管理的內容主要包含如下幾個方面：人員的組織與管理、軟件度量、軟件項目計劃、風險管理、軟件質量保證、軟件過程能力評估、軟件配置管理等內容。

1.5.4 組織開發團隊

軟件項目的開發，最重要的是人的因素。開發團隊中人員的素質、技術水平、組織的文化、團隊合作的狀況、人員穩定性和積極性等都是關乎項目成敗的重要因素。現代的軟件多數都是規模龐大和復雜的，由一個或幾個軟件技術精英單獨在短時間內完成的可能性已經很小了，因此一般情況下，軟件開發需要由人數較多的團隊來完成。

軟件開發團隊是一定數量的個體成員組成的集體，包括組織內的成員、客戶相關人員、供應商和其他與項目有關的人員。團隊的含義就由若干人員組成，承擔一個共同的目標，在項目經理的領導下，為實現項目目標而努力工作的群體。

組織和管理開發團隊，是項目管理的主要工作，并且始終貫穿于整個項目生命周期。人員是項目的最活躍因素，也是最關鍵因素，因此如何組建開發團隊，是項目經理和高層首先要考慮的問題。

組織開發團隊的首要任務，就是在組織內選用相關的人員，對于有一定規模的項目（50人月以上），參與的人員包括項目管理人員、技術開發人員、質量保證人員、其他輔助人員（如國際軟件外包項目的翻譯人員、專用設備的維護人員）。

在項目生命周期內，各個階段所需要的人員角色和數量是不同的，因此在項目團隊組中，人員是陸續有進有出的。有的人員工作不是全職而是兼職的。這些動態變化的狀況，應該在項目計劃中有預先的準備和規劃。

根據項目的要求組建開發團隊時，要做好團隊人員計劃，即項目人力資源配置計劃，明確各類人員的角色和職責、進出項目的日期。該計劃需要項目經理進行管理和維護，根據項目的進展、項目內容的變更或項目團隊出現的各種情況，不斷進行計劃的調整，保證項目的順利進行。

項目團隊的管理，在人文方面，還要注意團隊文化建設，一個良好的團隊文化，可以促進項目的內部溝通和合作，便于技術交流和問題的及時反饋。文化建設從根本上來講是團隊管理者的思想。不同的管理者有不同的做事理念和風格。雖然管理者的管理風格各不相同，但是以人為本是管理好團隊的根本原則，尊重每一位團隊成員，鼓勵任何成就，承擔管理者的責任而不是推卸責任，將對團隊建設起到非常良好的作用。

1.5.5 軟件工程活動

軟件工程活動是項目啟動后，進行項目開發的過程中一系列的活動。軟件工程作為一門研究用工程化方法構建和維護有效的、實用的和高質量的軟件的學科，已經發展了幾十年。但是軟件工程一直以來始終缺乏一個統一的定義，很多學者、組織機構都分別給出了自己認可的定義。下面分別概述一下這些軟件工程的定義。

IEEE在軟件工程術語匯編中的定義：軟件工程是將系統化的、嚴格約束的、可量化的方法應用于軟件的開發、運行和維護，即將工程化應用于軟件，同時對這些方法進行研究。

ISO 9000對軟件工程的定義：軟件工程是輸入轉化為輸出的一組彼此相關的資源和活動。

《計算機科學技術百科全書》中的定義：軟件工程是應用計算機科學、數學、邏輯學及管理科學等原理，開發軟件的工程。軟件工程借鑒傳統工程的原則、方法，以提高質量、降低成本和改進算法。其中，計算機科學、數學用于構建模型與算法，工程科學用于制定規范、設計范型、評估成本及確定權衡，管理科學用于計劃、資源、質量、成本等管理。

目前社會上比較認可的一種定義認為：軟件工程是研究和應用如何以系統性的、規范化的、可定量的過程化方法去開發和維護軟件，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最后的技術方法結合起來。

軟件工程的內涵，就是為了獲得軟件產品，在軟件工具的支持下由軟件工程師完成的一系列軟件工程活動。從軟件開發的觀點看，它就是使用適當的資源（包括人員、軟硬件資源、時間等），為開發軟件進行的一組開發活動，在活動結束時輸入（即擁有的需求）轉化為輸出（最終符合用戶需求的軟件產品）。

軟件開發過程作為一個工程，大致有3個階段。

（1）定義階段：可行性研究、初步項目計劃、需求分析；

（2）開發階段：概要設計、詳細設計、實現（編碼）、測試；

（3）運行和維護階段：運行、維護、廢棄。

遵循以上軟件工程定義和思想，在實際工作中，產生了很多開發策略和模式。這些模式從不同的角度或者實際情況出發，為避免項目風險、降低開發成本，采取了不同的開發步驟。常用的開發方法有以下幾種。

1．瀑布模型

瀑布模型（Waterfall Model）是在1970年由溫斯頓·羅伊斯（W. Royce）提出的軟件開發模型，是最早的計算機軟件開發方法。該模型給出了固定的順序，將軟件開發活動從上一個階段向下一個階段逐級過渡，如同流水下泄像瀑布一樣。它強調嚴格遵循預先計劃的需求分析、設計、編碼、集成、測試、維護的步驟順序進行。每個步驟的成果物作為衡量進度的方法，如需求規格書、設計文檔、測試計劃和代碼審閱等。瀑布式開發的主要問題是它嚴格分級，導致開發自由度降低，項目早期做出的承諾導致對后期需求的變化難以調整。瀑布式方法在需求不明并且項目進行過程中可能變化的情況下基本是不行的。

瀑布模型如圖1.4所示。

2．快速原型模型

快速原型模型（Rapid Prototype Model）的第一步是建造一個快速原型，實現客戶或未來的用戶與系統的交互，用戶或客戶對原型進行評價，進一步細化待開發軟件的需求。通過逐步調整原型使其滿足客戶的要求，開發人員可以確定客戶的真正需求是什么；第二步則在第一步的基礎上開發客戶滿意的軟件產品。

快速原型法可以克服瀑布模型的缺點，減少由于軟件需求不明確帶來的開發風險，具有顯著的效果。

快速原型的關鍵在于盡可能快速地建造出軟件的原型，一旦確定了客戶的真正需求，所建造的原型將被丟棄。因此，原型系統的內部結構并不重要，重要的是必須迅速建立原型，隨之迅速修改原型，以反映客戶的需求。

3．迭代式開發也被稱作迭代增量式開發（Incremental Model）或迭代進化式開發

這是一種與傳統的瀑布式開發相反的軟件開發過程，它彌補了傳統開發方式中的一些弱點，具有更高的成功率和生產率。在該模型中，開發工作類似建造一個大廈，軟件被一步一步建造起來。軟件被作為一系列的增量構建來設計、實現、集成和測試，每一個構件是由多種相互作用的模塊所形成的提供特定功能的代碼片段構成，增量模型在各個階段并不交付一個可運行的完整產品，而是交付滿足客戶需求的一個子集的可運行產品。整個產品被分解成若干個構件，開發人員逐個構件地交付產品，這樣做的好處是軟件開發可以較好地適應變化，客戶可以不斷看到所開發的軟件，從而降低開發風險。

具體操作上，迭代式開發每次只設計和實現產品的一部分，每次設計和實現的一個階段叫作一個迭代。迭代開發時，將開發工作組織為一系列短小的、固定長度（如3周）的小項目，被稱為一系列的迭代，每一次迭代都包括了需求分析、設計、實現與測試，如圖1.5所示。

采用這種方法，開發工作可以在需求被完整地確定之前啟動，并在一次迭代中完成系統的一部分功能或業務邏輯的開發工作。再通過客戶的反饋來細化需求，并開始新一輪的迭代。

迭代開發的優點是可以降低風險，得到早期用戶反饋，持續地測試和集成，適于需求變更，提高了軟件復用性。

但是，增量迭代模型也存在以下缺陷。

（1）由于各個構件是逐漸并入已有的軟件體系結構中的，所以加入構件必須不破壞已構造好的系統部分，這需要軟件具備開放式的體系結構。

（2）在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應這種變化，防范風險能力大大優于瀑布模型和快速原型模型，但也很容易退化為邊做邊改的模型方式，從而使軟件過程的控制失去整體性。

4．螺旋開發模型

螺旋開發（Spiral Model）模型產生于1988年，由Barry Boehm正式發表了軟件系統開發的“螺旋模型”，它將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合于大型復雜的系統。

螺旋模型剛開始開發規模很小，當項目被定義得更好、更穩定時，逐漸展開。其核心就在于不需要在剛開始的時候就把所有事情都定義得非常清楚。先輕松上陣，定義最重要的功能，實現后，聽取客戶的意見，之后再進入到下一個階段。如此不斷輪回重復，直到得到滿意的最終產品。

螺旋模型很大程度上是一種風險驅動的方法體系，因為在每個階段之前及經常發生的循環之前，都必須首先進行風險評估。這個過程大致包括以下幾方面。

（1）制訂計劃：確定軟件目標，選定實施方案，弄清項目開發的限制條件。

（2）風險分析：分析評估所選方案，考慮如何識別和消除風險。

（3）實施工程：實施軟件開發和驗證。

（4）客戶評估：評價開發工作，提出修正建議，制訂下一步計劃。

螺旋模型的示意圖如圖1.6所示。

5．敏捷軟件開發

敏捷軟件開發又稱敏捷開發，是從20世紀90年代開始逐漸引起廣泛關注的新型軟件開發方法，是一種應對快速變化的需求的一種軟件開發能力。相對于“非敏捷”式開發，更強調程序員團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應需要變化的代碼編寫和團隊組織方法，也更注重軟件開發中人的作用。

敏捷開發強調如下幾點。

（1）人和交互重于過程和工具。

（2）可以工作的軟件重于求全而完備的文檔。

（3）客戶協作重于合同談判。

（4）隨時應對變化重于循規蹈矩。

以上內容最為重要的是人員彼此信任，人少但是精干，可以面對面溝通。

敏捷開發小組主要的工作方式可以歸納為：作為一個整體工作，按短迭代周期工作，每次迭代交付一些成果，關注業務優先級，檢查與調整。

敏捷方法中要考慮的重要因素是人員的規模。隨著項目規模的增長，面對面的溝通就愈加困難，因此，敏捷方法更適用于較小的隊伍，40人以下的人員比較合適。大規模的敏捷軟件開發尚處于積極研究的領域。

在國際軟件外包項目中，比較常見的是瀑布型開發。這是因為通過離岸方式的外包開發，溝通是最大的問題，由于難以即時、面對面地與客戶或上游設計人員溝通，因此書面的、正規文檔溝通方式成為國際軟件外包溝通的主要形式，而這樣的溝通形式，客觀上就迫使軟件開發局限于瀑布式的工作過程。

即使采用瀑布式的開發，也常常為了項目的順利進行，需要在岸保留一定的BSE（Bridge Senior Engineer）與客戶或發包商進行密切地接觸，保持溝通的暢通。

1.5.6 軟件質量保證活動

軟件項目是否成功，取決于4個方面的因素，即在約定的時間內、按預算的成本、完成了規定的軟件功能范圍開發，并達到了預定的質量標準。

在以上4個評判標準中，時間、成本和功能，是比較容易進行量化跟蹤和監控的。但是對于質量的評判，則比較困難，有些質量問題是直接可以通過軟件外觀看到的，而更多的、影響軟件運行效能的問題，則很難直接觀察出來。例如，同樣編出了相同功能的軟件代碼，但是由于處理方法和算法的不同，執行效率會有很大差異。我們在這里所探討的軟件質量，主要是指對于實現既定功能有影響的質量問題，如程序算法錯誤、未處理異常情況、未進行計算機資源回收等直接影響軟件系統功能的質量問題，屬于程序邏輯方面的錯誤。至于軟件算法效率方面，需要開發人員個人技能的提高和組織。

按照ISO 9000的定義，質量是一組由固有特性滿足需求的程度。通俗地說，就是軟件與文檔中規定或描述的標準之間符合的程度。影響軟件質量的主要因素，從管理的角度來度量，可以分為3類，即正確性（包括完整性、可用性、效率等）、可理解性（包括可維修性、可測試性等）和可移植性（包括可復用性、可移植運行性等）。

為了達到這些質量標準，在開發過程中，應該按照規定的質量保證程序，進行產品的生產活動。一定規律的活動，就會產生一定質量水平的產品。就是說，質量的結果，很大程度上取決于生產活動的規則和技術水平。如果把產品質量看作是生產活動的結果，那么，要提高產品質量，就必須改進或改善生產活動本身的規則。這就是質量保證活動的基本原則。例如，生產出了一個有缺陷的產品，如果要改進產品的質量，是對生產出來的產品做質量上的改進，對其缺陷進行修復，還是對生產這個產品的過程進行改進呢？如果要對產品逐一進行修復，那么從這個生產過程中出來的產品，將會連續不斷地出現類似的質量問題，產出的量越大，要修復的產品缺陷也越多，無法從根本上消除產品的質量問題，進而提高產品的質量。如果對產品的生產過程進行分析和改進，那么，改進后的生產過程，將會避免產生產品缺陷的某個活動中的問題，從而杜絕通過這一活動過程產生質量問題的關鍵因素。不斷改進生產過程，從而保證產品質量，使得一個組織的生產過程的質量趨于穩定，這就是質量保證體系追求的目標，也是質量保證活動的重點工作。

在軟件外包行業中，目前比較通行的質量保證體系及其認證，當屬“能力成熟度模型”（Capability Maturity Model，CMM）。CMM是美國卡內基·梅隆大學軟件研究所（SEI）在美國國防部的資助下所做的一個項目的成果。1987年，在SEI的技術報告中，把軟件能力成熟度模型（CMM）作為評價國防部合同承包方過程成熟度的方法論；1991年，SEI發布了1.0版軟件CMM（SW-CMM）。

CMM自1987年開始實施認證，現在已經成為軟件業權威的評估認證體系。CMM包括了5個等級，共計18個過程域，52個目標和300多個關鍵實踐活動。

在軟件外包發包中，對于很多較大項目的招標，都要求承包方具有CMM的認證，當然，認證的等級有所不同。國際大型軟件公司的項目發包，有的要求承包方達到CMM5級的最高等級。也有的對承包方的質量保證體系進行實地考察和評估，滿足發包方的要求后，才能作為軟件外包提供商，承接項目。

1.5.7 項目交付與驗收

軟件外包的結果，是承包方向發包方提交開發完成的成果物。軟件項目的成果物包括項目從開始到結束一系列過程中產生的各種需要提交的內容，包括各種技術文檔、代碼、測試文檔和測試結果，還有客戶提供的臨時使用的設備等。

當項目到了結尾階段，需要交付的成果分為兩部分。

一部分是開發方需要自行保留的，包括從項目開始到結束的全部資料，既有項目管理方面的文檔，也有項目工程方面的文檔和代碼，還有項目支持方面的相關文檔及項目總結報告等內容。這部分成果物，應作為開發方的財產，進行完整的備份，納入公司財富管理庫中保存。歷史信息和經驗教訓信息，也應該一并做好總結，移存到經驗知識庫里。

另一部分則是需要提交給客戶的成果物，包括項目分析、設計、使用和維護等方面的文檔，以及程序代碼和相關的手冊。還要包括提供給客戶的附屬設備、配套的使用環境資料。

項目的驗收，是指客戶方要按照合同的要求，逐項檢查成果物是否達到了要求，是否符合質量標準，以及是否滿足性能要求等工作。項目驗收要檢驗成果物和附屬的文檔資料是否完整，對于今后的系統升級或維護，要有完整的系統資料說明。除了提交的可見成果物，有的驗收過程還包括對服務性工作的檢驗。例如，對客戶的系統使用培訓，為客戶提供的維護是否及時、有效等。

對客戶方面的驗收，最終需要客戶出具正式的項目接受和驗收文檔。

在國際軟件外包項目中，很多情況下，項目組的工作通過網絡直接連接在客戶的服務器上，或直接連接在存放在客戶端的開發環境上。絕大多數的工作成果，如代碼和技術文檔，都是隨時保存在客戶服務器上，因此客戶也會隨時得到成果物，也有即時測試和驗收的。這種情況，往往驗收工作比較簡單，當項目開發完畢，驗收也很快就結束了。