軟件生命周期模型選擇及WBS分解指南

1、軟件生命周期模型選擇及WB分解指南一、概述同任何事物一樣，一個(gè)軟件產(chǎn)品或軟件系統(tǒng)也要經(jīng)歷孕育、誕生、成長(zhǎng)、成熟、衰亡等階段，一般稱 為“軟件生命周期”。軟件生命周期模型，通俗說(shuō)就是，軟件開發(fā)過(guò)程中所遵循的模式，即把整個(gè)軟件生 存周期劃分為若干階段，使得每個(gè)階段有明確的任務(wù)，使規(guī)模大，結(jié)構(gòu)復(fù)雜和管理復(fù)雜的軟件開發(fā)變的容 易控制和管理。軟件生命周期模型和項(xiàng)目開發(fā)過(guò)程有非常緊密關(guān)系， 它是經(jīng)過(guò)多次實(shí)踐總結(jié)出來(lái)適合于不同項(xiàng)目使用 的經(jīng)典、有效的軟件開發(fā)方法，它按照軟件生命周期的各個(gè)階段劃分任務(wù)，依照一定的規(guī)則和步驟，有效 地進(jìn)行軟件開發(fā)。選用恰當(dāng)?shù)能浖芷谀Ｐ瓦M(jìn)行軟件開發(fā)， 可以提高產(chǎn)品質(zhì)量； 降

2、低項(xiàng)目管理難度； 縮短開發(fā)進(jìn)度； 便于項(xiàng)目狀態(tài)跟蹤；為過(guò)程改進(jìn)和度量提供基線；改善組織級(jí)的過(guò)程弱勢(shì)，提高過(guò)程能力成熟度級(jí)別。為了便于分類匯總和統(tǒng)計(jì)各種生命周期模型的指標(biāo)和數(shù)據(jù)，結(jié)合公司軟件開發(fā)過(guò)程的實(shí)際，我們選擇 了常用的幾種基本模型進(jìn)行了描述，項(xiàng)目開發(fā)小組在進(jìn)行項(xiàng)目策劃時(shí)，可以根據(jù)模型的適用前提、優(yōu)缺點(diǎn) 和項(xiàng)目的實(shí)際需要進(jìn)行選擇，并在項(xiàng)目實(shí)施計(jì)劃中，參加評(píng)審。二、軟件生命周期模型常用的軟件生命周期模型有：瀑布模型、迭代模型、增量模型、原型模型等。 以上所提到的件生命周期模型病不存在孰優(yōu)孰劣的問(wèn)題， 每一種模型在實(shí)際工作中都有所應(yīng)用。 只要 選擇了最適合的，并按照此模型的流程來(lái)開發(fā)軟件，都會(huì)取

3、得成功。需要強(qiáng)調(diào)的是，不管采用什么模型，項(xiàng)目實(shí)施中有四項(xiàng)活動(dòng)是必不可少的需求、設(shè)計(jì)、編碼和測(cè) 試。不管是有意識(shí)還是無(wú)意識(shí)，這些活動(dòng)都會(huì)出現(xiàn)在項(xiàng)目過(guò)程中。這也是最重要的四項(xiàng)活動(dòng)，其他的活動(dòng) 其實(shí)都是為這些活動(dòng)服務(wù)的，不管是配置管理、風(fēng)險(xiǎn)管理，還是評(píng)審等等。以下對(duì)各種常用的軟件生命周期模型的設(shè)計(jì)思想、WBS分（Work Breakdown Structure ，即工作分解結(jié)構(gòu)）、優(yōu)缺點(diǎn)、使用范圍進(jìn)行分析。1、瀑布模型(1)基本思想瀑布模型(Waterfall Model )是最基本也最常用的一種生命周期模型，又稱線性模型。瀑布模型是一個(gè)項(xiàng)目開發(fā)架構(gòu)，開發(fā)過(guò)程是通過(guò)設(shè)計(jì)一系列階段順序展開的，從系統(tǒng)需

4、求分析開始直到產(chǎn)品發(fā)布和維護(hù)，每個(gè)階段都會(huì)產(chǎn)生循環(huán)反饋，因此，如果有信息未被覆蓋或者發(fā)現(xiàn)了問(wèn)題，那么最好返回”上一個(gè)階段并進(jìn)行適當(dāng)?shù)男薷?，?xiàng)目開發(fā)進(jìn)程從一個(gè)階段流動(dòng)”到下一個(gè)階段，這也是瀑布模型名稱的由來(lái)。瀑布模型可以應(yīng)用于軟件工程開發(fā)、企業(yè)項(xiàng)目開發(fā)、產(chǎn)品生產(chǎn)以及市場(chǎng)銷售等領(lǐng)域。瀑布模型的突出特征是文檔驅(qū)動(dòng)。從需求分析到系統(tǒng)維護(hù)，每一項(xiàng)活動(dòng)的工作成果就是此項(xiàng)活動(dòng)所產(chǎn)生的工作文檔，以及在此基礎(chǔ)上形成的產(chǎn)品。采用瀑布模型的項(xiàng)目依照該模型選定的階段順序進(jìn)行，每一個(gè)階段的工作產(chǎn)品都是下一個(gè)階段工作的輸入，每一個(gè)階段只有在上一個(gè)階段通過(guò)檢查，確認(rèn)完成后才開始新的階段工作，所以項(xiàng)目必須有明確的 階段里程碑

5、，在每個(gè)階段結(jié)束時(shí)都要進(jìn)行里程碑評(píng)審，以判定是否可以開始下一階段的工作。例如：在項(xiàng) 目策劃沒(méi)有完成時(shí)，需求分析和設(shè)計(jì)工作就不能進(jìn)行，同樣，在需求分析和設(shè)計(jì)沒(méi)有完成時(shí)就不開始編碼。 瀑布模型中，每個(gè)階段完成后，可以在下一個(gè)階段修改上一個(gè)階段的工作產(chǎn)品，但是必須按照基線變更進(jìn) 行管理，如果發(fā)生變更，需要回溯前面所有階段的工作產(chǎn)品，以便使工作產(chǎn)品保持一致。(2) WB劃分圖1瀑布模型的思想示意圖說(shuō)明：圖中標(biāo)記為 的階段為選定的里程碑，該階段完成時(shí)需進(jìn)行里程碑評(píng)審活動(dòng)，并對(duì)其輸出進(jìn)行嚴(yán)格的變更控制。(2) WBS劃分此表僅作為參考，需根據(jù)項(xiàng)目所選定的標(biāo)準(zhǔn)過(guò)程的活動(dòng)和任務(wù)進(jìn)一步細(xì)化。階段和 項(xiàng)目標(biāo)準(zhǔn)過(guò)程

6、ID任務(wù)工作成果名稱項(xiàng)目策劃階段項(xiàng)目策劃管 理規(guī)范1 起草項(xiàng)目任務(wù)書項(xiàng)目任務(wù)書2審批項(xiàng)目任務(wù)書已批準(zhǔn)的項(xiàng)目任務(wù)書3策劃準(zhǔn)備項(xiàng)目實(shí)施計(jì)劃4啟動(dòng)項(xiàng)目策劃產(chǎn)品的功能結(jié)構(gòu)圖、 WB工作任務(wù)分解5項(xiàng)目估計(jì)和成果列表項(xiàng)目實(shí)施計(jì)劃：工作量估計(jì)，進(jìn)度計(jì)劃，人力資源計(jì)劃， 軟/硬件、工具要求，風(fēng)險(xiǎn)管理計(jì)劃，培訓(xùn)計(jì)劃，溝通計(jì)劃， 交付工作產(chǎn)品清單等6制訂項(xiàng)目計(jì)劃項(xiàng)目實(shí)施計(jì)劃（有些客戶需要質(zhì)量保證計(jì)劃（方案）、 配臵管理計(jì)劃（方案）等相關(guān)計(jì)劃）7項(xiàng)目計(jì)劃評(píng)審按照項(xiàng)目評(píng)審管理規(guī)范 的規(guī)定，Q/組織對(duì)項(xiàng)目實(shí)施計(jì)劃 組織評(píng)審，直到通過(guò)評(píng)審8審批項(xiàng)目計(jì)劃項(xiàng)目實(shí)施計(jì)劃獲得相關(guān)領(lǐng)導(dǎo)的審批需求分析階段需求開發(fā)與 管理規(guī)范9需求調(diào)

7、研開始按照需求調(diào)研計(jì)劃，米取需求調(diào)研記錄表進(jìn)行調(diào) 研，完成系統(tǒng)需求分析說(shuō)明書初稿10需求分析如果客戶需求不清晰需要密切跟蹤，要完成需求調(diào)研記錄跟蹤矩陣、需求不一致項(xiàng)列表11需求不一致項(xiàng) 協(xié)商處理相關(guān)修訂文檔，可能包括系統(tǒng)需求分析說(shuō)明書 和需求不 一致項(xiàng)列表等文件12r需求規(guī)格說(shuō)明書完善:系統(tǒng)需求分析說(shuō)明書正式稿、需求跟蹤管理表13需求驗(yàn)證需求冋級(jí)評(píng)審相關(guān)記錄。驗(yàn)證后的系統(tǒng)需求分析說(shuō)明書、需求跟蹤管理表14需求分析階段評(píng)審按照項(xiàng)目評(píng)審管理規(guī)范的規(guī)定，QA組織對(duì)需求分析說(shuō)明書的評(píng)審15里程碑評(píng)審（可選）完成項(xiàng)目里程碑報(bào)告并組織評(píng)審分析設(shè)計(jì)階段分析設(shè)計(jì)管 理規(guī)范16概要設(shè)計(jì)概要設(shè)計(jì)相關(guān)技術(shù)資料17設(shè)

8、計(jì)文檔編寫:概要設(shè)計(jì)說(shuō)明書18概要設(shè)計(jì)評(píng)審（可選）概要設(shè)計(jì)說(shuō)明書的評(píng)審（建議詳細(xì)設(shè)計(jì)或概要設(shè)計(jì)必須做 一個(gè)正式評(píng)審）19詳細(xì)設(shè)計(jì):詳細(xì)設(shè)計(jì)相關(guān)工具和技術(shù)資料20文檔編寫詳細(xì)設(shè)計(jì)說(shuō)明書21用戶界面設(shè)計(jì)用戶界面設(shè)計(jì)說(shuō)明書22數(shù)據(jù)庫(kù)設(shè)計(jì)數(shù)據(jù)庫(kù)設(shè)計(jì)說(shuō)明書23p詳細(xì)設(shè)計(jì)評(píng)審設(shè)計(jì)評(píng)審記錄項(xiàng)目評(píng)審報(bào)告24r里程碑評(píng)審（可選）完成項(xiàng)目里程碑報(bào)告并組織評(píng)審實(shí)現(xiàn)開發(fā)階段25編程源代碼產(chǎn)品實(shí)現(xiàn)管 理規(guī)范26代碼走查代碼走杳檢杳單27單元測(cè)試單元測(cè)試報(bào)告28初步完成三大手冊(cè)初步完成系統(tǒng)安裝手冊(cè)用戶操作手冊(cè)項(xiàng)目維護(hù)手冊(cè)測(cè)試階段 項(xiàng)目測(cè)試管理規(guī)范29集成測(cè)試測(cè)試bug清單30測(cè)試文檔項(xiàng)目測(cè)試計(jì)劃、測(cè)試用例、測(cè)試報(bào)告部署運(yùn)

9、行系統(tǒng)部署管理規(guī)范31部署安裝使用系統(tǒng)部署用戶確認(rèn)書需要用戶確認(rèn)32客戶培訓(xùn)客戶培訓(xùn)簽到表客戶培訓(xùn)效果調(diào)查表驗(yàn)收項(xiàng)目驗(yàn)收管 理規(guī)范32內(nèi)部驗(yàn)收在正式部署之前完成。項(xiàng)目?jī)?nèi)部驗(yàn)收評(píng)審報(bào)告33客戶驗(yàn)收客戶驗(yàn)收計(jì)劃、客戶驗(yàn)收?qǐng)?bào)告結(jié)項(xiàng)階段項(xiàng)目結(jié)項(xiàng)管理規(guī)范34結(jié)項(xiàng)申請(qǐng)結(jié)項(xiàng)申請(qǐng)表35結(jié)項(xiàng)總結(jié)結(jié)項(xiàng)總結(jié)報(bào)告36總結(jié)會(huì)議結(jié)項(xiàng)總結(jié)維護(hù)階段項(xiàng)目運(yùn)行維 護(hù)管理規(guī)范37維護(hù)計(jì)劃審批維護(hù)工作啟動(dòng)制定項(xiàng)目維護(hù)計(jì)劃并通過(guò)審批38維護(hù)報(bào)告項(xiàng)目結(jié)束維護(hù)，完成項(xiàng)目維護(hù)總結(jié)報(bào)告(3)優(yōu)缺點(diǎn)該模型的優(yōu)點(diǎn)： 階段分明、活動(dòng)明確，為軟件開發(fā)工作提供一種結(jié)構(gòu)化、有序的方法； 過(guò)程控制可見性較強(qiáng)： 按照順序開展每一個(gè)階段的工作，每一階段是在上一

10、階段徹底完成的情況下才啟動(dòng)，可以保證每一個(gè)階段的開發(fā)質(zhì)量都有保證，減少了返工； 開發(fā)過(guò)程中的各項(xiàng)文檔降低了溝通的成本，有利于及早發(fā)現(xiàn)問(wèn)題，降低項(xiàng)目的階段成本； 文檔多，過(guò)程記錄比較全，有利于后期維護(hù)。該模型的缺點(diǎn)： 不能回溯：項(xiàng)目從開始到發(fā)布可見的版本需要較長(zhǎng)的周期，用戶直到項(xiàng)目開發(fā)晚期才能了解產(chǎn)品的真實(shí)面貌和質(zhì)量，不易變更；如果必須回溯，則回溯成本很大。 缺乏靈活性，不能跨階段操作； 文檔多，花費(fèi)較多成本。(4)適用范圍 產(chǎn)品定義(或項(xiàng)目需求)和技術(shù)方案非常明確、用戶的需求有很好的了解; 對(duì)質(zhì)量的要求高于對(duì)成本和進(jìn)度的要求； 工期相對(duì)較寬裕； 開發(fā)隊(duì)伍技術(shù)力量較弱或缺乏經(jīng)驗(yàn); 維護(hù)項(xiàng)目。2、

11、迭代模型（1）基本思想迭代模型是RUP（ Rational Unified Process，統(tǒng)一軟件開發(fā)過(guò)程）推薦的周期模型。在 RUF中，迭代被定義為：迭代包括產(chǎn)生產(chǎn)品發(fā)布（穩(wěn)定、可執(zhí)行的產(chǎn)品版本）的全部開發(fā)活動(dòng)和要使用該發(fā)布必需的所 有其他外圍元素。在某種程度上，開發(fā)迭代是一次完整地經(jīng)過(guò)所有工作流程的過(guò)程：需求、分析設(shè)計(jì)、實(shí) 施和測(cè)試工作流程。實(shí)質(zhì)上，它類似小型的瀑布式項(xiàng)目。RU認(rèn)為，所有的階段都可以細(xì)分為迭代。每一次的迭代都會(huì)產(chǎn)生一個(gè)可以發(fā)布的產(chǎn)品，這個(gè)產(chǎn)品是最終產(chǎn)品的一個(gè)子集。岡険分折 評(píng)價(jià)方案鳳險(xiǎn)少咅肖除園臉/軟杵/ T 藍(lán)/軫皿/ 魁輕/彳單元i競(jìng)7 與舉”仏J W ；I驗(yàn)啦:與丨

12、幵瘍撿證 下一產(chǎn)品-圖2迭代模型的思想示意圖說(shuō)明:迭代模型沿著螺線進(jìn)行若干次迭代，圖中的四個(gè)象限代表了以下活動(dòng)： 制定計(jì)劃：確定軟件目標(biāo)，選定實(shí)施方案，弄清項(xiàng)目開發(fā)的限制條件； 風(fēng)險(xiǎn)分析：分析評(píng)估所選方案，考慮如何識(shí)別和消除風(fēng)險(xiǎn)； 實(shí)施工程：實(shí)施軟件開發(fā)和驗(yàn)證； 客戶評(píng)估：評(píng)價(jià)開發(fā)工作，提出修正建議，制定下一步計(jì)劃。迭代模型由風(fēng)險(xiǎn)驅(qū)動(dòng)， 強(qiáng)調(diào)可選方案和約束條件從而支持軟件的重用，有助于將軟件質(zhì)量作為特殊目 標(biāo)融入產(chǎn)品開發(fā)之中。使用迭代模型進(jìn)行軟件開發(fā)，項(xiàng)目活動(dòng)包含以下幾個(gè)階段： 初始階段初始階段有時(shí)也稱先啟階段。初始階段的目標(biāo)是為系統(tǒng)建立商業(yè)案例并確定項(xiàng)目的邊界。為了達(dá)到該目的必須識(shí)別所有與系

13、統(tǒng)交互的外部實(shí)體，在較高層次上定義交互的特性。本階段具有非常重要的意義， 在這個(gè)階段中所關(guān)注的是整個(gè)項(xiàng)目進(jìn)行中的業(yè)務(wù)和需求方面的主要風(fēng)險(xiǎn)。對(duì)于建立在原有系統(tǒng)基礎(chǔ)上的開 發(fā)項(xiàng)目來(lái)講，初始階段可能很短。 細(xì)化階段細(xì)化階段的目標(biāo)是分析問(wèn)題領(lǐng)域，建立健全的體系結(jié)構(gòu)基礎(chǔ)，編制項(xiàng)目計(jì)劃，淘汰項(xiàng)目中最高風(fēng)險(xiǎn)的元素。為了達(dá)到該目的，必須在理解整個(gè)系統(tǒng)的基礎(chǔ)上，對(duì)體系結(jié)構(gòu)做出決策，包括其范圍、主要功能和 諸如性能等非功能需求。同時(shí)為項(xiàng)目建立支持環(huán)境，包括創(chuàng)建開發(fā)案例，創(chuàng)建模板、準(zhǔn)則并準(zhǔn)備工具。 構(gòu)造階段在構(gòu)建階段，所有剩余的構(gòu)件和應(yīng)用程序功能被開發(fā)并集成為產(chǎn)品，所有的功能被詳細(xì)測(cè)試。從某種意義上說(shuō)，構(gòu)建階段是一

14、個(gè)制造過(guò)程，其重點(diǎn)放在管理資源及控制運(yùn)作以優(yōu)化成本、進(jìn)度和質(zhì)量。 交付階段交付階段的重點(diǎn)是確保軟件對(duì)最終用戶是可用的。交付階段可以跨越幾次迭代， 包括為發(fā)布做準(zhǔn)備的產(chǎn)品測(cè)試，基于用戶反饋的少量的調(diào)整。 在生命周期的這一點(diǎn)上， 用戶反饋應(yīng)主要集中在產(chǎn)品調(diào)整， 設(shè)臵、 安裝和可用性問(wèn)題，所有主要的結(jié)構(gòu)問(wèn)題應(yīng)該已經(jīng)在項(xiàng)目生命周期的早期階段解決了。篠卅再弄T忤唐 411 M舟祈料逐討室盤洌試配理軀甘3jya圖3迭代模型的幾個(gè)階段(2) WBS劃分實(shí)際采用迭代模型中， 項(xiàng)目階段仍可參考瀑布執(zhí)行。迭代模型實(shí)施重要的關(guān)鍵點(diǎn)是架構(gòu)設(shè)計(jì)（概要設(shè) 計(jì)）、制定迭代開發(fā)計(jì)劃。階段和 項(xiàng)目標(biāo)準(zhǔn)過(guò)程任務(wù)工作成果名稱項(xiàng)目策

15、劃階段項(xiàng)目策劃管理規(guī)范完成項(xiàng)目實(shí)施計(jì)劃項(xiàng)目實(shí)施計(jì)劃中 WB分解要參考本表項(xiàng)目迭代計(jì)劃 （）項(xiàng)目迭代開發(fā)計(jì)劃必須有架構(gòu)設(shè)計(jì)（概要設(shè)計(jì)）項(xiàng)目迭代開發(fā)計(jì)劃必須說(shuō)明哪些是關(guān)鍵迭 代，完成的時(shí)機(jī)以及預(yù)期成果 下一個(gè)迭代，在前幾個(gè)迭代基礎(chǔ)上需要完善的要 點(diǎn)以及完善步驟架構(gòu)（概要）設(shè)計(jì)（）: 概要設(shè)計(jì)說(shuō)明書系統(tǒng)完成架構(gòu)設(shè)計(jì)（概要設(shè)計(jì)）詳細(xì)需求分析、設(shè)計(jì)及實(shí)現(xiàn)第1個(gè)迭代需求分析迭代1的需求分析，形成需求說(shuō)明書需求評(píng)審關(guān)鍵迭代需要組織評(píng)審詳細(xì)設(shè)計(jì)直接做詳細(xì)設(shè)計(jì)，完成迭代設(shè)計(jì)說(shuō)明書文檔編寫詳細(xì)設(shè)計(jì)說(shuō)明書用戶界面設(shè)計(jì)用戶界面設(shè)計(jì)說(shuō)明書數(shù)據(jù)庫(kù)設(shè)計(jì)數(shù)據(jù)庫(kù)設(shè)計(jì)說(shuō)明書編程源代碼代碼走查按照項(xiàng)目實(shí)施計(jì)劃中質(zhì)量控制點(diǎn)計(jì)劃要求完

16、成代 碼走杳檢杳單單元測(cè)試按照項(xiàng)目實(shí)施計(jì)劃中質(zhì)量控制點(diǎn)計(jì)劃要求完成單 元測(cè)試報(bào)告第一個(gè)迭代部署/集成按照項(xiàng)目迭代開發(fā)計(jì)劃 將迭代開發(fā)成果部署到統(tǒng) 一架構(gòu)中。第一個(gè)迭代集成測(cè)試迭代后的開發(fā)成果部署到統(tǒng)一架構(gòu)后做集成測(cè)試詳細(xì)需求分析、設(shè)計(jì)及實(shí)現(xiàn)第2個(gè)迭代按照項(xiàng)目迭代開發(fā)計(jì)劃 中的規(guī)劃實(shí)現(xiàn)，如果實(shí)現(xiàn) 計(jì)劃有變化需要變更該計(jì)劃。詳細(xì)需求分析、設(shè)計(jì)及實(shí)現(xiàn)第N個(gè)迭代按照項(xiàng)目迭代開發(fā)計(jì)劃 中的規(guī)劃實(shí)現(xiàn)，如果實(shí)現(xiàn) 計(jì)劃有變化需要變更該計(jì)劃。測(cè)試階段項(xiàng)目測(cè)試管理規(guī)范所有迭代按照 項(xiàng)目迭代開發(fā)計(jì)劃 全部實(shí)現(xiàn)后，需 要做系統(tǒng)測(cè)試。（3）優(yōu)缺點(diǎn)與傳統(tǒng)的瀑布模型相比較，迭代模型具有以下優(yōu)點(diǎn): 降低了在一個(gè)增量上的開支風(fēng)

17、險(xiǎn)。如果開發(fā)人員重復(fù)某個(gè)迭代，那么損失只是這一個(gè)開發(fā)有誤的迭代的花費(fèi)； 降低了產(chǎn)品無(wú)法按照既定進(jìn)度進(jìn)入市場(chǎng)的風(fēng)險(xiǎn)。通過(guò)在開發(fā)早期就確定風(fēng)險(xiǎn)，可以盡早來(lái)解決而不至于在開發(fā)后期匆匆忙忙； 加快了整個(gè)開發(fā)工作的進(jìn)度。因?yàn)殚_發(fā)人員清楚問(wèn)題的焦點(diǎn)所在，他們的工作會(huì)更有效率; 由于用戶的需求并不能在一開始就做出完全的界定，它們通常是在后續(xù)階段中不斷細(xì)化的。因此,迭代過(guò)程這種模式使適應(yīng)需求的變化會(huì)更容易些。迭代模型的缺點(diǎn)： 風(fēng)險(xiǎn)管理成本較高： 迭代模型本身強(qiáng)調(diào)風(fēng)險(xiǎn)， 但風(fēng)險(xiǎn)管理本身也存在成本問(wèn)題； 如果風(fēng)險(xiǎn)管理成本 過(guò)大，將會(huì)嚴(yán)重影響項(xiàng)目的利潤(rùn)； 對(duì)項(xiàng)目組成員的要求非常高： 在風(fēng)險(xiǎn)分析、 進(jìn)度管理等方面，

18、需要有較高層次的人員配臵及豐富的 項(xiàng)目管理和項(xiàng)目實(shí)施的經(jīng)驗(yàn)。這對(duì)于開發(fā)隊(duì)伍技術(shù)力量較弱或缺乏經(jīng)驗(yàn)的團(tuán)隊(duì)很難實(shí)施。（4）適用范圍 在項(xiàng)目開發(fā)早期需求可能有所變化； 分析設(shè)計(jì)人員對(duì)應(yīng)用領(lǐng)域很熟悉； 高風(fēng)險(xiǎn)項(xiàng)目； 用戶可不同程度地參與整個(gè)項(xiàng)目的開發(fā)過(guò)程； 使用面向?qū)ο蟮恼Z(yǔ)言或統(tǒng)一建模語(yǔ)言（Unified Modeling Language ， UML ； 使用 CASE（ Computer Aided Software Engineering，計(jì)算機(jī)輔助軟件工程）工具，如 Rose（ Rose是非常受歡迎的物件軟體開發(fā)工具）； 具有高素質(zhì)的項(xiàng)目管理者和軟件研發(fā)團(tuán)隊(duì)。3、增量模型（ 1）基本思想增量模

19、型是通過(guò)對(duì)用戶需求的判斷，在定義了用戶要求和系統(tǒng)需求, 進(jìn)行總體構(gòu)架設(shè)計(jì)后，采用序列化地創(chuàng)建產(chǎn)品的方法進(jìn)行開發(fā)的過(guò)程。每一個(gè)線性序列產(chǎn)生軟件的一個(gè)可發(fā)布的“增量”，第一個(gè)建立的增量完成預(yù)計(jì)功能 / 性能的一部分（往往包含了核心功能，即實(shí)現(xiàn)了基本的需求），下一個(gè)增量實(shí)現(xiàn)另 外的部分，增加更多的功能 / 性能，然后與前面實(shí)現(xiàn)的增加進(jìn)行集成，如此循環(huán)，直到系統(tǒng)完全實(shí)現(xiàn)。增量模型的特點(diǎn)是引進(jìn)了增量包的概念， 無(wú)須等到所有需求都出來(lái)， 只要某個(gè)需求的增量包出來(lái)即可 進(jìn)行開發(fā)。雖然某個(gè)增量包可能還需要進(jìn)一步適應(yīng)客戶的需求并且更改，但只要這個(gè)增量包足夠小，其影 響對(duì)整個(gè)項(xiàng)目來(lái)說(shuō)是可以承受的。其實(shí)現(xiàn)過(guò)程簡(jiǎn)圖如

20、下所示：L煖量1 |計(jì)卜|如卜|測(cè)武煙產(chǎn)】|粉折卜彳$計(jì)君隔|-*測(cè)逐堆說(shuō)I牛斯卜f亦訃+ “ 卜|甲楚I 罐最斗I分忻j藥訂一I麗T；耳可圖4增量模型的思想示意圖說(shuō)明：在策劃階段，項(xiàng)目經(jīng)理需要與客戶協(xié)商確定增量的數(shù)目、規(guī)模、每一增量發(fā)布的時(shí)間表，在概要設(shè)計(jì)階段需要考慮各增量集成的順序、接口等問(wèn)題，制定集成策略。增量循環(huán)的循環(huán)體可以根據(jù)項(xiàng)目的實(shí)際情況進(jìn)行控制。增量模型本質(zhì)上是迭代的， 但其強(qiáng)調(diào)每一個(gè)增量均發(fā)布一個(gè)可操作產(chǎn)品。早期的增量是最終產(chǎn)品的“可拆卸”版本，但提供了為用戶服務(wù)的功能，并且為用戶提供了評(píng)估的平臺(tái)。(2) WBS劃分階段和項(xiàng)目標(biāo)準(zhǔn)過(guò)程任務(wù)工作成果名稱概要設(shè)計(jì)概要設(shè)計(jì)概要設(shè)計(jì)相關(guān)

21、技術(shù)資料、設(shè)計(jì)文檔編寫概要設(shè)計(jì)說(shuō)明書概要設(shè)計(jì)評(píng)審（必須）設(shè)計(jì)評(píng)審記錄設(shè)計(jì)實(shí)現(xiàn)開發(fā)第一個(gè)增量（如A模塊）詳細(xì)設(shè)計(jì)A模塊詳細(xì)設(shè)計(jì)文檔編寫詳細(xì)設(shè)計(jì)說(shuō)明書用戶界面設(shè)計(jì)用戶界面設(shè)計(jì)說(shuō)明書數(shù)據(jù)庫(kù)設(shè)計(jì)數(shù)據(jù)庫(kù)設(shè)計(jì)說(shuō)明書編程源代碼代碼走查代碼走杳檢杳單單元測(cè)試單元測(cè)試報(bào)告第一個(gè)增量測(cè)試增量產(chǎn)品測(cè)試發(fā)布第一個(gè)增量增量產(chǎn)品發(fā)布和部署設(shè)計(jì)實(shí)現(xiàn)開發(fā)第二個(gè)增量（如B模塊）詳細(xì)設(shè)計(jì)B模塊詳細(xì)設(shè)計(jì)文檔編寫詳細(xì)設(shè)計(jì)說(shuō)明書用戶界面設(shè)計(jì)用戶界面設(shè)計(jì)說(shuō)明書數(shù)據(jù)庫(kù)設(shè)計(jì)數(shù)據(jù)庫(kù)設(shè)計(jì)說(shuō)明書編程源代碼代碼走查代碼走杳檢杳單單元測(cè)試單元測(cè)試報(bào)告13第一個(gè)增量測(cè)試增量產(chǎn)品測(cè)試發(fā)布第一個(gè)增量增量產(chǎn)品發(fā)布和部署開發(fā)第N個(gè)增量（3）優(yōu)缺點(diǎn)該模型的優(yōu)點(diǎn):

22、在達(dá)到初始需求之前可降低成本：采用增量模型可以靈活分配人員,剛開始不用投入大量人力資源。如果核心產(chǎn)品很受歡迎，則可增加人力實(shí)現(xiàn)下一個(gè)增量;可快速生產(chǎn)出可使用的系統(tǒng)：它提供了一種先推出核心產(chǎn)品的途徑,這樣即可先發(fā)布部分功能給客戶，對(duì)客戶起到鎮(zhèn)靜劑的作用;能夠有計(jì)劃地管理技術(shù)風(fēng)險(xiǎn)。該模型的缺點(diǎn):系統(tǒng)集成難度大：由于各個(gè)構(gòu)件是逐漸并入已有的軟件體系結(jié)構(gòu)中的,各增量的集成難度增大，所以在概要設(shè)計(jì)階段需要制定詳細(xì)的集成策略；項(xiàng)目管理風(fēng)險(xiǎn)加大： 在開發(fā)過(guò)程中，需求的變化是不可避免的， 增量模型的靈活性可以使其適應(yīng)這種變化的能力大大優(yōu)于瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而使軟件過(guò)程的控

23、制失去整體性。（4）適用范圍 用戶核心需求非常清楚； 項(xiàng)目人員不足； 產(chǎn)品可以分割成不同的階段分別完成。4、原型模型（1）基本思想原型模型通過(guò)向用戶提供原型獲取用戶的反饋,使開發(fā)出的軟件能夠真正反映用戶的需求。同時(shí)，原型模型采用逐步求精的方法完善原型，使得原型能夠“快速”開發(fā)，避免了像瀑布模型一樣在冗長(zhǎng)的開發(fā) 過(guò)程中難以對(duì)用戶的反饋?zhàn)龀隹焖俚捻憫?yīng)。相對(duì)瀑布模型而言，原型模型更符合人們開發(fā)軟件的習(xí)慣，使 目前較流行的一種實(shí)用軟件生存期模型。15原型模型是一種用戶需求驅(qū)動(dòng)的方法，使得用戶在系統(tǒng)生存周期的設(shè)計(jì)階段起到積極的作用；它能減少系統(tǒng)開發(fā)的風(fēng)險(xiǎn)，特別是在大型項(xiàng)目的開發(fā)中，由于對(duì)項(xiàng)目需求的分析難

24、以一次完成，應(yīng)用原型法效果更為明顯。原型模型根據(jù)其最終保留情況分為非拋棄型和拋棄型兩種：非拋棄型原型是先根據(jù)用戶的最主要的要求，開發(fā)出能實(shí)現(xiàn)系統(tǒng)最基本功能的一個(gè)原型，再根據(jù)用戶對(duì)原型使用與評(píng)價(jià)的意見，反復(fù)修改完善原型，直到等到用戶滿意的最終系統(tǒng)為止。原型模型從需求收集開始，軟件開發(fā)組與目標(biāo)用戶一起定義軟件的總體目標(biāo)，標(biāo)識(shí)出已知的需求， 并規(guī)劃出進(jìn)一步定義的區(qū)域。然后是“快速設(shè)計(jì)”?？焖僭O(shè)計(jì)建立軟件中對(duì)用戶可見的部分，即“原型”。原型由用戶評(píng)估，并據(jù)此進(jìn)一步精化用戶需求。逐步調(diào)整原型使其滿足用戶的要求，同時(shí)也使開發(fā)組對(duì)該 軟件有更好的理解，這個(gè)過(guò)程是迭代的，每一個(gè)迭代完成后均可生成一個(gè)可用的產(chǎn)品

25、版本。拋棄型原型模型一般用來(lái)描述和驗(yàn)證用戶需求，可以采用與實(shí)際開發(fā)所不同的開發(fā)工具，建立模擬的數(shù)據(jù)庫(kù)系統(tǒng)，從而達(dá)到與用戶交流的最好效果。到用戶需求確定之后即不再繼續(xù)開發(fā)此原型。與非拋棄型原型模型的主要區(qū)別在于： 目的不同，拋棄型原型模型的目的是為了與用戶更好的溝通； 手段不同，拋棄型原型模型采用的技術(shù)手段與正式開發(fā)可以完全不同； 結(jié)果不同，拋棄型原型模型的工作產(chǎn)品不會(huì)在軟件研發(fā)中使用或大量使用，而多用于開發(fā)deme及驗(yàn)證用戶需求的復(fù)合性。使用原型模型進(jìn)行軟件開發(fā)，項(xiàng)目活動(dòng)包含以下幾個(gè)階段： 確定用戶需求階段軟件項(xiàng)目負(fù)責(zé)人員根據(jù)用戶意向或市場(chǎng)調(diào)研等前期準(zhǔn)備的資料、文檔，對(duì)用戶需求進(jìn)行分析， 編寫

26、用戶需求文檔。 建造/修改原型階段項(xiàng)目組根據(jù)原型評(píng)價(jià)結(jié)果對(duì)設(shè)計(jì)原型進(jìn)行建立、修改和完善，并記錄相關(guān)過(guò)程。 運(yùn)行/評(píng)價(jià)原型階段明確設(shè)計(jì)原型中要保留的和需去除的原項(xiàng)目負(fù)責(zé)人協(xié)同市場(chǎng)人員與用戶對(duì)設(shè)計(jì)原型進(jìn)行評(píng)價(jià)和討論,型設(shè)計(jì)部分，提出需要進(jìn)一步補(bǔ)充和完善的需求內(nèi)容。重復(fù)上述過(guò)程，直至用戶需求全部明確為止。各階段需要遵循的項(xiàng)目標(biāo)準(zhǔn)過(guò)程參見 PD項(xiàng)目標(biāo)準(zhǔn)過(guò)程裁剪指南。圖6原型模型開發(fā)的幾個(gè)階段(2) WBS劃分非拋棄型原型模型的WB劃U分階段和過(guò)程ID從過(guò)程中選取任務(wù)工作成果名稱用戶需求分析需求開發(fā)與管理規(guī)范1獲取用戶需求需求調(diào)研記錄單2建立系統(tǒng)需求需求分析說(shuō)明書3驗(yàn)證需求已經(jīng)驗(yàn)證的軟件系統(tǒng)需求建造/修改原型產(chǎn)品實(shí)現(xiàn)管理規(guī)范4搭建開發(fā)環(huán)境開發(fā)環(huán)境5編寫代碼源代碼、產(chǎn)品原型運(yùn)行/評(píng)價(jià)原型6運(yùn)行評(píng)價(jià)原型更新后需求分析說(shuō)明書拋棄型原型模型的WB劃分任務(wù)類型ID任務(wù)工作成果名稱用戶需求分析1需求調(diào)查和分析需求調(diào)研記錄