軟件生命周期選取指南

1、中國廣東核電集團(tuán)CHINA GUANGDONG NUCLEAR POWER GROUP記 錄 文 件CGN-IT-C3-A18-01軟件生命周期選擇指南版本編寫審核審定批準(zhǔn)生效時(shí)間A/0黃福同林樹順楊曉晨高立剛 2011-7-31注：如無受控文件標(biāo)識（藍(lán)色印章）則為非有效版本，以受控文件規(guī)定為準(zhǔn)。本文件產(chǎn)權(quán)屬中科華核電技術(shù)研究院所有，未經(jīng)許可，不得以任何方式外傳。內(nèi)部使用如無藍(lán)色受控文件標(biāo)識章，則為非有效版本，請以受控文件規(guī)定為準(zhǔn)。NO修改日期修改摘要（涉及頁碼/條款/內(nèi)容）版本修改原因目 錄1.目的52.適用范圍53.責(zé)任5項(xiàng)目經(jīng)理5項(xiàng)目成員54.規(guī)定6啟動準(zhǔn)則6輸入6主要步驟6需求分析6原

2、型參考7裁剪定義7輸出8結(jié)束準(zhǔn)則8度量8剪裁85.定義與縮略語8定義8縮略語96.附錄9附錄A 軟件生命周期模型1瀑布模型1模型介紹1優(yōu)缺點(diǎn)1階段定義2選用規(guī)則2增量模型2模型介紹2優(yōu)缺點(diǎn)3階段定義3選用規(guī)則4螺旋模型4模型介紹4優(yōu)缺點(diǎn)5階段定義5選用規(guī)則6快速原型模型6模型介紹6優(yōu)缺點(diǎn)7階段定義7選用規(guī)則7RUP迭代模型7模型介紹7優(yōu)缺點(diǎn)8階段定義9選用規(guī)則9敏捷開發(fā)模型9模型介紹9優(yōu)缺點(diǎn)11階段定義12選用規(guī)則12V模型13V模型介紹13優(yōu)缺點(diǎn)15階段定義16選用規(guī)則161. 目的本指南的制定是為了在項(xiàng)目研發(fā)過程中，能夠有一個(gè)完整統(tǒng)一的方法來分析項(xiàng)目需求，預(yù)先識別項(xiàng)目特征，并提供可供項(xiàng)目選

3、擇的軟件生命周期模型，使其可以和組織標(biāo)準(zhǔn)軟件過程結(jié)合在一起使用。2. 適用范圍軟件生命周期是指從軟件產(chǎn)品開始到軟件停止使用為止的時(shí)間間隔。對生命周期細(xì)分階段進(jìn)行管理稱為周期模型，典型的幾種生命周期模型包括瀑布模型、增量模型、螺旋模型和快速原型模型、迭代模型。項(xiàng)目組應(yīng)在軟件項(xiàng)目計(jì)劃階段，認(rèn)真考慮項(xiàng)目的特征和目標(biāo)，在此基礎(chǔ)上參考原有模型，或?yàn)轫?xiàng)目開發(fā)新設(shè)計(jì)出一個(gè)軟件生命周期模型。無論選擇何種模型，都要包括下列一般軟件工程過程必須包含的內(nèi)容：Ø 項(xiàng)目啟動Ø 項(xiàng)目計(jì)劃Ø 需求分析Ø 軟件設(shè)計(jì)Ø 編碼Ø 測試Ø 交付與驗(yàn)收Ø

4、 運(yùn)行維護(hù)Ø 項(xiàng)目停止使用3. 責(zé)任3.1 項(xiàng)目經(jīng)理1）快速歸納軟件項(xiàng)目研發(fā)需求2）總結(jié)類似項(xiàng)目的開發(fā)經(jīng)驗(yàn)3）提出項(xiàng)目開發(fā)參考模型4）與項(xiàng)目組成員一起討論裁剪模型3.2 項(xiàng)目成員1) 總結(jié)類似項(xiàng)目的開發(fā)經(jīng)驗(yàn)2) 與其他項(xiàng)目成員一起裁剪模型4. 規(guī)定4.1 啟動準(zhǔn)則項(xiàng)目計(jì)劃開始制定。4.2 輸入初始用戶需求及初始項(xiàng)目計(jì)劃。4.3 主要步驟軟件生命周期模型一般都是在原有的模型基礎(chǔ)上根據(jù)客戶的需求變更和最終的目標(biāo)實(shí)現(xiàn)判斷項(xiàng)目特征進(jìn)行裁剪產(chǎn)生的，主要經(jīng)歷四個(gè)步驟：需求分析、原型參考、裁剪定義和模型實(shí)施。4.3.1 需求分析從軟件概念第一次被提出，并且明確了實(shí)現(xiàn)目標(biāo)，就進(jìn)入項(xiàng)目概念階段，這個(gè)時(shí)

5、候項(xiàng)目組開始組建，同時(shí)收集需求，項(xiàng)目經(jīng)理應(yīng)積極配合業(yè)務(wù)代表參與需求研討和項(xiàng)目的策劃，安排有經(jīng)驗(yàn)的人員進(jìn)入項(xiàng)目組，迅速對需求進(jìn)行初步分析，概括項(xiàng)目的特征。此部分的需求分析還應(yīng)該包括對歷史項(xiàng)目的回顧，總結(jié)成功實(shí)施經(jīng)驗(yàn)和吸取失敗教訓(xùn)，并歸檔備案作為組織的過程資產(chǎn)庫。4.3.2 原型參考當(dāng)項(xiàng)目最終實(shí)現(xiàn)目標(biāo)確定，同時(shí)識別出項(xiàng)目特征，從組織批準(zhǔn)使用的軟件生命周期模型中挑選出一個(gè)以供參考，該周期原型必須在很大程度上適合項(xiàng)目的具體特征以及能夠結(jié)合組織標(biāo)準(zhǔn)軟件過程一起使用。項(xiàng)目一開始，周期模型僅作參考，下一步還必須結(jié)合實(shí)際的越來越豐富的需求進(jìn)行裁剪以達(dá)到新模型的指導(dǎo)目的。新裁剪出的模型可以歸檔成為下一個(gè)類似項(xiàng)目

6、的原始參考模型。原型的描述主要包括軟件生命周期模型的原理、優(yōu)缺點(diǎn)、階段定義和選用規(guī)則。4.3.3 裁剪定義裁剪基于項(xiàng)目特征項(xiàng)目特征是裁剪工作的出發(fā)點(diǎn)，包括項(xiàng)目規(guī)模（如大、中、小等）、項(xiàng)目類型（如新開發(fā)、維護(hù)等），以及技術(shù)難度、產(chǎn)品類型、項(xiàng)目周期等要素。² 明確可裁剪的對象可裁剪對象確定了裁剪的范圍，不僅僅限于過程元素和活動，還包括參照標(biāo)準(zhǔn)、方法和工具、輸出產(chǎn)品及模板等。² 確定裁剪所考慮的要素裁剪要素界定了裁剪的方向和尺度。例如，對于某個(gè)裁剪對象，其范圍與頻度都是裁剪要素。對于有開發(fā)經(jīng)驗(yàn)的小項(xiàng)目，可以適當(dāng)減少對于技術(shù)方面的評審的頻度。² 裁剪的決定要基于風(fēng)險(xiǎn)進(jìn)行考

7、慮基于風(fēng)險(xiǎn)可檢驗(yàn)裁剪的適當(dāng)性。對過程或活動的調(diào)整或放棄，需要通過分析其所帶來的風(fēng)險(xiǎn)和影響再做決定。4.3.3.1 模型實(shí)施裁剪后的周期模型，是個(gè)具有項(xiàng)目特征的組織標(biāo)準(zhǔn)軟件過程，該過程包含軟件生命周期模型的原理、優(yōu)缺點(diǎn)等描述，能夠幫助軟件開發(fā)人員更好地理解和運(yùn)用組織已批準(zhǔn)的軟件生命周期進(jìn)行項(xiàng)目開發(fā)。新模型對于項(xiàng)目開發(fā)具有指導(dǎo)意義，必須將該模型下達(dá)通知到項(xiàng)目組所有成員，項(xiàng)目經(jīng)理必須監(jiān)督保證模型的推廣，實(shí)現(xiàn)“項(xiàng)目可控，質(zhì)量可靠”的最終目標(biāo)。4.3.3.2 模型選擇建議² 在前期需求明確的情況下盡量采用瀑布模型或改進(jìn)型的瀑布模型。² 在用戶無信息系統(tǒng)使用經(jīng)驗(yàn)，需求分析人員技能不足情

8、況下一定要借助原型。² 在不確定性因素很多，很多東西前面無法計(jì)劃情況下，盡量采用增量迭代和螺旋模型。² 在需求不穩(wěn)定情況下盡量采用增量、迭代模型。² 在資金和成本無法一次到位情況下可以采用增量模型，軟件產(chǎn)品分多個(gè)版本進(jìn)行發(fā)布。² 對于完全多個(gè)獨(dú)立功能開發(fā)可以在需求階段就分功能并行，但每個(gè)功能內(nèi)都應(yīng)該遵循瀑布模型。² 對于全新系統(tǒng)的開發(fā)必須在總體設(shè)計(jì)完成后再開始增量或并行。² 對于編碼人員經(jīng)驗(yàn)較少情況下，建議不要采用敏捷或迭代等生命周期模型。² 增量、迭代和原型可以綜合使用，但每一次增量或迭代都必須有明確的交付和出口準(zhǔn)則。4.

9、3.4 輸出具有項(xiàng)目特征的軟件生命周期模型。4.3.5 結(jié)束準(zhǔn)則項(xiàng)目生命周期模型已確定。4.4 度量本指南暫無度量要求。4.5 剪裁本指南不允許剪裁。5. 定義與縮略語5.1 定義無5.2 縮略語SLCSoftware Lift Cycle軟件生命周期SLCMSoftware Lift Cycle Model軟件生命周期模型PMProject Manager項(xiàng)目經(jīng)理SEISoftware Engineering Institute 軟件工程學(xué)院SLCPSLC-Process軟件生命周期流程文檔6. 附錄² 附錄A軟件生命周期模型6.1 附錄A 軟件生命周期模型6.2 瀑布模型6.2.

10、1 模型介紹概要設(shè)計(jì)發(fā)布測試實(shí)現(xiàn)詳細(xì)設(shè)計(jì)需求分析維護(hù)瀑布模型規(guī)定了各項(xiàng)軟件工程活動是按照自上而下、相互銜接的固定次序逐步完成。其形如瀑布流水，逐級而下，其狀連續(xù)不斷，直到項(xiàng)目后期才能開圖瀑布模型發(fā)出軟件產(chǎn)品。瀑布模型為軟件開發(fā)和軟件維護(hù)提供了一種有效的管理圖示。根據(jù)這一圖示制定開發(fā)計(jì)劃、進(jìn)行成本預(yù)算、組織開發(fā)力量，以項(xiàng)目的階段評審和文檔控制為手段有效地對整個(gè)開發(fā)過程進(jìn)行指導(dǎo)，從而保證軟件產(chǎn)品及時(shí)交付，并達(dá)到預(yù)期的質(zhì)量要求。6.2.2 優(yōu)缺點(diǎn)瀑布模型強(qiáng)調(diào)開發(fā)的階段性，強(qiáng)調(diào)早期計(jì)劃和需求調(diào)查，強(qiáng)調(diào)產(chǎn)品的測試和驗(yàn)收。對于軟件外包這樣強(qiáng)調(diào)階段性檢查的項(xiàng)目具有很大的適用性。但模型突出的缺點(diǎn)是缺乏靈活性，

11、依賴于早期進(jìn)行的需求調(diào)查，特別是無法解決軟件需求不明確或不準(zhǔn)確的問題，這種情況往往需要進(jìn)行返工或者在維護(hù)中糾正需求的偏差，極大的增加了風(fēng)險(xiǎn)成本，并由于是單向流動，開發(fā)過程中的階段經(jīng)驗(yàn)教訓(xùn)很難反饋在項(xiàng)目同階段的實(shí)施過程中。6.2.3 階段定義階段進(jìn)入標(biāo)準(zhǔn)任務(wù)退出標(biāo)準(zhǔn)需求分析分配到軟件的系統(tǒng)需求已確定；項(xiàng)目計(jì)劃已批準(zhǔn)進(jìn)行軟件需求分析軟件需求分析完成并形成基線。概要設(shè)計(jì)軟件需求規(guī)格說明書已經(jīng)完成并通過評審進(jìn)行數(shù)據(jù)庫設(shè)計(jì)、各模塊的概要設(shè)計(jì)、集成測試用例編寫數(shù)據(jù)庫設(shè)計(jì)、概要設(shè)計(jì)、集成測試用例編寫完成并形成基線。詳細(xì)設(shè)計(jì)數(shù)據(jù)庫設(shè)計(jì)、概要設(shè)計(jì)、集成測試用例編寫完成并形成基線。進(jìn)行詳細(xì)設(shè)計(jì)及單元測試用例編寫。

12、詳細(xì)設(shè)計(jì)及單體測試用例編寫完成并形成基線。實(shí)現(xiàn)詳細(xì)設(shè)計(jì)及單體測試用例編寫完成進(jìn)行編碼及單元測試編碼及單體測試完成并形成基線。測試編碼完成進(jìn)行集成、系統(tǒng)測試集成、系統(tǒng)測試報(bào)告發(fā)布測試已經(jīng)完成用戶手冊、在線幫助等文檔編寫，安裝程序制作用戶手冊、在線幫助等文檔編寫完成并形成基線，安裝程序制作完成6.2.4 選用規(guī)則當(dāng)項(xiàng)目的需求明確、理解充分、并且較為穩(wěn)定時(shí)，適合選擇瀑布模型，絕大部分的標(biāo)準(zhǔn)軟件過程都可以應(yīng)用瀑布模型。6.3 增量模型6.3.1 模型介紹增量模型是瀑布模型的一種變化模型。這種方式是首先建立概要設(shè)計(jì)，然后設(shè)計(jì)的實(shí)現(xiàn)是通過一系列小的、相互交錯(cuò)的子項(xiàng)目，每個(gè)子項(xiàng)目完成一個(gè)獨(dú)特的功能。第一個(gè)增

13、量往往是核心的產(chǎn)品，即實(shí)現(xiàn)了基本的要求，但很多補(bǔ)充的特性還沒有開發(fā)。核心產(chǎn)品交用戶使用的結(jié)果是下一個(gè)增量的開發(fā)計(jì)劃。該計(jì)劃包括對核心產(chǎn)品的修改，也包括新增的特點(diǎn)和功能。這個(gè)過程在每個(gè)增量發(fā)布后不斷重復(fù)，直到產(chǎn)生最終的完善產(chǎn)品。增量1詳細(xì)設(shè)計(jì)編碼單元測試系統(tǒng)集成測試交付增量2詳細(xì)設(shè)計(jì)增量3詳細(xì)設(shè)計(jì)編碼單元測試系統(tǒng)集成測試系統(tǒng)集成測試編碼單元測試軟件系統(tǒng)測試概要設(shè)計(jì)分析需求圖增量模型6.3.2 優(yōu)缺點(diǎn)增量模型強(qiáng)調(diào)開發(fā)的分散性，項(xiàng)目需求可以分批獲取，任意一個(gè)子項(xiàng)目的需求一經(jīng)確定就可進(jìn)入設(shè)計(jì)和編碼階段，最后提交驗(yàn)證測試，可以及早地從測試過程中發(fā)現(xiàn)實(shí)現(xiàn)過程中存在的問題，并將經(jīng)驗(yàn)教訓(xùn)反饋在項(xiàng)目的下一個(gè)循環(huán)

14、過程。因?yàn)樵陧?xiàng)目早期就能獲得項(xiàng)目監(jiān)控?cái)?shù)據(jù)，有助于識別和分析風(fēng)險(xiǎn)，并可對后期開發(fā)做出確實(shí)的項(xiàng)目估算，增加項(xiàng)目的成功率。同樣模型也是存在明顯的缺點(diǎn)的。開發(fā)的分散，削弱了需求設(shè)計(jì)的完整性，主要問題反應(yīng)在項(xiàng)目的系統(tǒng)集成階段，影響了系統(tǒng)性能和產(chǎn)品的可維護(hù)性，同時(shí)也增加版本控制等不安定的因素。6.3.3 階段定義階段進(jìn)入標(biāo)準(zhǔn)任務(wù)退出標(biāo)準(zhǔn)增量1項(xiàng)目計(jì)劃已批準(zhǔn)并進(jìn)行了總體的需求分析及概要設(shè)計(jì)進(jìn)行第一階段的詳細(xì)設(shè)計(jì)、編碼、測試及發(fā)布。第一階段產(chǎn)品完成并形成基線增量2增量1產(chǎn)品已經(jīng)完成并完善了本階段的需求分析及概要設(shè)計(jì)進(jìn)行第二階段的詳細(xì)設(shè)計(jì)、編碼、測試及發(fā)布。第二階段產(chǎn)品完成并形成基線增量3增量2產(chǎn)品已經(jīng)完成并完

15、善了本階段的需求分析及概要設(shè)計(jì)進(jìn)行第三階段的詳細(xì)設(shè)計(jì)、編碼、測試及發(fā)布第三階段產(chǎn)品完成并形成基線各階段中包含的詳細(xì)階段請參照瀑布模型。6.3.4 選用規(guī)則當(dāng)項(xiàng)目可清晰地劃分為多個(gè)功能獨(dú)立的子項(xiàng)目，或采用階段開發(fā)時(shí)，適合選擇增量模型。6.4 螺旋模型6.4.1 模型介紹螺旋模型也是瀑布模型的一種變化模型，其中的每個(gè)回旋代表一個(gè)特定開發(fā)階段。每個(gè)特定開發(fā)階段都結(jié)合了風(fēng)險(xiǎn)分析和瀑布原型，這也是與瀑布模型的區(qū)別之處。圖螺旋模型螺旋模型沿著螺線旋轉(zhuǎn)，如圖所示，在笛卡爾坐標(biāo)的四個(gè)象限上分別表達(dá)了四個(gè)方面的活動，即：1) 制定計(jì)劃：確定軟件目標(biāo)，選定實(shí)施方案，弄清項(xiàng)目開發(fā)的限制條件2) 風(fēng)險(xiǎn)分析：分析所選方

16、案，考慮如何識別和消除風(fēng)險(xiǎn)3) 實(shí)施工程：實(shí)施軟件開發(fā)4) 客戶評估：評價(jià)開發(fā)工作，提出修正建議螺旋模型在每一個(gè)開發(fā)階段之前，都引入非常嚴(yán)格的風(fēng)險(xiǎn)識別、風(fēng)險(xiǎn)分析和風(fēng)險(xiǎn)控制，直到采取了消除風(fēng)險(xiǎn)的措施之后，才開始計(jì)劃該階段的開發(fā)工作，而每次回旋都開發(fā)出更為完善的一個(gè)新的軟件版本。例如：在第一圈，確定了初步的目標(biāo)、方案和限制條件后，轉(zhuǎn)入右上相限，對風(fēng)險(xiǎn)進(jìn)行識別和分析。如果風(fēng)險(xiǎn)分析表明，需求有不確定性，那么在右下的實(shí)施工程相限內(nèi)，所建的原型會幫助開發(fā)人員和客戶，考慮其它開發(fā)模型，并對需求做進(jìn)一步修正?？蛻魧こ坛晒龀鲈u價(jià)之后，給出修正建議。在此基礎(chǔ)上需再次計(jì)劃，并進(jìn)行風(fēng)險(xiǎn)分析。每出現(xiàn)一個(gè)新的版本都越

17、來越符合客戶需求，逐步消除或減少風(fēng)險(xiǎn)的損害。在每一圈螺線上，做出風(fēng)險(xiǎn)分析的終點(diǎn)是否繼續(xù)下去的判斷。假如風(fēng)險(xiǎn)過大，開發(fā)者和用戶無法承受，項(xiàng)目有可能終止。多數(shù)情況下沿螺線的活動會繼續(xù)下去，自內(nèi)向外，逐步延伸，最終得到所期望的系統(tǒng)。6.4.2 優(yōu)缺點(diǎn)螺旋模型強(qiáng)調(diào)風(fēng)險(xiǎn)管理，強(qiáng)調(diào)對項(xiàng)目的各個(gè)階段審查，提供機(jī)會討論項(xiàng)目是否有價(jià)值繼續(xù)進(jìn)展下去，可以及早地發(fā)現(xiàn)和終止虧損項(xiàng)目。由于引入嚴(yán)格的風(fēng)險(xiǎn)管理，這對項(xiàng)目管理水平提出更高的要求，需要更多的人員、資金和時(shí)間的投入，增加了項(xiàng)目成本。6.4.3 階段定義階段進(jìn)入標(biāo)準(zhǔn)任務(wù)退出標(biāo)準(zhǔn)原型1項(xiàng)目計(jì)劃已批準(zhǔn)進(jìn)行原型1制作原型1提交并形成基線原型2原型1形成基線進(jìn)行原型2制作

18、原型2提交并形成基線原型3原型2形成基線進(jìn)行原型3制作原型3提交并形成基線各階段中包含的詳細(xì)階段請參照瀑布模型。6.4.4 選用規(guī)則對于大規(guī)模、復(fù)雜而需求理解不充分、風(fēng)險(xiǎn)較大、產(chǎn)品要求質(zhì)量高且對開發(fā)周期沒有嚴(yán)格要求的項(xiàng)目適合選擇螺旋模型。6.5 快速原型模型6.5.1 模型介紹快速原型模型不同于傳統(tǒng)的瀑布模型，其核心是套用原型，快速開發(fā)。由于客戶對需求的不明朗，無法在早期就能對需求進(jìn)行明確分析和對應(yīng)的風(fēng)險(xiǎn)管理，將在設(shè)計(jì)階段不斷返工，導(dǎo)致項(xiàng)目成本增大，而快速原型模型能夠很好地解決這個(gè)問題。在獲得一組基本需求說明后，通過快速分析構(gòu)造出一個(gè)小型的軟件系統(tǒng)，滿足用戶的基本要求，使得客戶可在試用原型系統(tǒng)

19、的過程中得到親身感受和受到啟發(fā)，做出反應(yīng)和評價(jià)，然后開發(fā)者根據(jù)用戶的意見對原型加以改進(jìn)。隨著不斷試驗(yàn)、糾錯(cuò)、使用、評價(jià)和修改，獲得新的原型版本，如此周而復(fù)始，逐步減少分析和通信中的誤解，彌補(bǔ)不足之處，進(jìn)一步確定各種需求細(xì)節(jié)，適應(yīng)需求的變更，從而提高了最終產(chǎn)品的質(zhì)量。原型評估快速分析或修改構(gòu)造運(yùn)行圖快速原型模型快速原型模式類似于增量模式和螺旋模型的結(jié)合，只是，由于強(qiáng)調(diào)快，所以在功能和性能上有所取舍，同時(shí)不強(qiáng)調(diào)階段審查和風(fēng)險(xiǎn)管理。需要注意的是構(gòu)造原型的目的是反映最終系統(tǒng)的重要特性，因此，我們必須明確規(guī)定對原型進(jìn)行考核和評價(jià)的內(nèi)容，如界面形式、系統(tǒng)結(jié)構(gòu)、功能或模擬性能等。6.5.2 優(yōu)缺點(diǎn)快速原型模

20、型強(qiáng)調(diào)快速分析，鼓勵(lì)與客戶互動，能夠掌握客戶第一手需求資料，并通過與客戶的交流使開發(fā)者學(xué)習(xí)到應(yīng)用范圍的專業(yè)知識，能夠更好地幫助開發(fā)者理解和設(shè)計(jì)最終系統(tǒng)。該模型強(qiáng)調(diào)快的同時(shí)一般忽略了性能要求，所以通常原型版本并不是最終版本，最終版本都是在原型基礎(chǔ)上重新設(shè)計(jì)開發(fā)的，無形中增加了項(xiàng)目成本，同時(shí)要準(zhǔn)確地構(gòu)造一個(gè)原型并不是件容易的事情，要求開發(fā)者具有豐富的項(xiàng)目開發(fā)經(jīng)驗(yàn)和對應(yīng)用范圍具有一定的專業(yè)知識，也要求項(xiàng)目經(jīng)理具備與客戶反復(fù)溝通的交流能力?？蛻羰菍﹂_發(fā)原型進(jìn)行評價(jià)得出需求的，因此，需求存在多變性，必須加強(qiáng)對需求的管理能力。6.5.3 階段定義階段進(jìn)入標(biāo)準(zhǔn)任務(wù)退出標(biāo)準(zhǔn)分析客戶提出部分需求對需求進(jìn)行快速分

21、析分析得到概要設(shè)計(jì)構(gòu)造需求的概要設(shè)計(jì)已經(jīng)完成根據(jù)設(shè)計(jì)開發(fā)原型系統(tǒng)系統(tǒng)開發(fā)完畢并體現(xiàn)重要特性運(yùn)行系統(tǒng)開發(fā)完畢發(fā)布系統(tǒng)提交客戶評估新的原型系統(tǒng)開發(fā)完畢評估系統(tǒng)正常運(yùn)行與客戶溝通進(jìn)一步明確系統(tǒng)需求需求變更程度達(dá)到新一輪的原型構(gòu)造6.5.4 選用規(guī)則對于從項(xiàng)目概念到項(xiàng)目立項(xiàng)周期要求較短但無法提供明確需求、具備演示性質(zhì)或者試點(diǎn)工程之類的的項(xiàng)目適合選擇快速原型模型。6.6 RUP迭代模型6.6.1 模型介紹RUP（Rational Unified Process）是 IBM Rational公司提出的一套開發(fā)過程模型，它是一個(gè)面向?qū)ο筌浖こ痰耐ㄓ脴I(yè)務(wù)流程。它描述了一系列相關(guān)的軟件工程流程，它們具有相同的

22、結(jié)構(gòu)，即相同的流程構(gòu)架。RUP 為在開發(fā)組織中分配任務(wù)和職責(zé)提供了一種規(guī)范方法，其目標(biāo)是確保在可預(yù)計(jì)的時(shí)間安排和預(yù)算內(nèi)開發(fā)出滿足最終用戶需求的高品質(zhì)的軟件。RUP具有兩個(gè)軸，一個(gè)軸是時(shí)間軸，這是動態(tài)的。另一個(gè)軸是工作流軸，這是靜態(tài)的。在時(shí)間軸上，RUP劃分了四個(gè)階段：初始階段、細(xì)化階段、構(gòu)造階段和發(fā)布階段。每個(gè)階段都使用了迭代的概念。在工作流軸上，RUP設(shè)計(jì)了六個(gè)核心工作流程和三個(gè)核心支撐工作流程，核心工作流軸包括：業(yè)務(wù)建模工作流、需求工作流、分析設(shè)計(jì)工作流、實(shí)現(xiàn)工作流、測試工作流和發(fā)布工作流。核心支撐工作流包括：環(huán)境工作流、項(xiàng)目管理工作流和配置與變更管理工作流。RUP與增量迭代不完全相同，但

23、是二者往往互相包含，在一個(gè)項(xiàng)目中往往一起使用。圖RUP模型6.6.2 優(yōu)缺點(diǎn)RUP 匯集現(xiàn)代軟件開發(fā)中多方面的最佳經(jīng)驗(yàn)，并為適應(yīng)各種項(xiàng)目及組織的需要提供了靈活的形式。作為一個(gè)商業(yè)模型，它具有非常詳細(xì)的過程指導(dǎo)和模板，由于該模型通過多次迭代來完成軟件項(xiàng)目開發(fā)任務(wù)，具有適應(yīng)變更、及早降低風(fēng)險(xiǎn)、提高軟件質(zhì)量的優(yōu)點(diǎn)。但是同樣由于該模型比較復(fù)雜，因此在模型的掌握上需要花費(fèi)比較大的成本。尤其對項(xiàng)目管理者提出了比較高的要求。6.6.3 階段定義階段進(jìn)入標(biāo)準(zhǔn)任務(wù)退出標(biāo)準(zhǔn)先啟項(xiàng)目計(jì)劃和迭代計(jì)劃已制定1 了解需創(chuàng)建的系統(tǒng)，確定愿景、范圍、邊界2 確定系統(tǒng)的主要功能3 制定至少一個(gè)可行的方案4了解與項(xiàng)目有關(guān)的成本、

24、時(shí)間進(jìn)度與風(fēng)險(xiǎn)5 確定遵循的過程和相關(guān)工具項(xiàng)目目標(biāo)通過評審精化先啟階段結(jié)束1細(xì)化需求2 設(shè)計(jì)、實(shí)現(xiàn)、驗(yàn)證系統(tǒng)架構(gòu)并建立架構(gòu)基線3 化解主要風(fēng)險(xiǎn)，更精確的制定進(jìn)度表和成本估算4 細(xì)化開發(fā)用例并搭建開發(fā)環(huán)境系統(tǒng)架構(gòu)通過評審構(gòu)建精化階段結(jié)束迭代開發(fā)準(zhǔn)備交付給用戶的完整產(chǎn)品，包括設(shè)計(jì)、實(shí)現(xiàn)及測試相關(guān)工作具備產(chǎn)品BETA測試條件產(chǎn)品化功能齊全的BETA版本1進(jìn)行BETA測試2用戶培訓(xùn)3準(zhǔn)備產(chǎn)品環(huán)境并轉(zhuǎn)換數(shù)據(jù)庫與相關(guān)方完成驗(yàn)收工作6.6.4 選用規(guī)則RUP模型是一個(gè)高規(guī)范度的迭代化方法，所有的文檔需要基于UML，對項(xiàng)目成員技能要求較高，如果用戶提出的項(xiàng)目對時(shí)間進(jìn)度要求相對寬松，風(fēng)險(xiǎn)管理要求較高同時(shí)又能組建

25、有足夠經(jīng)驗(yàn)的項(xiàng)目團(tuán)隊(duì)的情況下可選用RUP方法。6.7 敏捷開發(fā)模型6.7.1 模型介紹敏捷開發(fā)（agile development）是一種以人為核心、迭代、循序漸進(jìn)的開發(fā)方法，是一種迭代和增量（發(fā)展）的方法，通過項(xiàng)目涉眾以高度協(xié)作和自組織的方式執(zhí)行，利用適量資源以經(jīng)濟(jì)有效且及時(shí)的方式生產(chǎn)能滿足涉眾不斷變化的需求的高質(zhì)量軟件。在敏捷開發(fā)中，軟件項(xiàng)目的構(gòu)建被切分成多個(gè)子項(xiàng)目，各個(gè)子項(xiàng)目的成果都經(jīng)過測試，具備集成和可運(yùn)行的特征。簡言之，就是把一個(gè)大項(xiàng)目分為多個(gè)相互聯(lián)系，但也可獨(dú)立運(yùn)行的小項(xiàng)目，并分別完成，在此過程中軟件一直處于可使用狀態(tài)。但敏捷開發(fā)并不是一種創(chuàng)新，敏捷開發(fā)可理解為在原有軟件開發(fā)方法基

26、礎(chǔ)上的整合取其精華，去其糟粕。因此敏捷開發(fā)繼承了不少原有方法的優(yōu)勢。敏捷開發(fā)方法過程設(shè)計(jì)的幾個(gè)原理：1 、交互的面對面的交流是代價(jià)最小，最迅速的交換信息的方法；2、 超過實(shí)際需要的過程是浪費(fèi)的；3 、大的團(tuán)隊(duì)需要重量級方法；4 、處理重大問題的項(xiàng)目需要重量級方法強(qiáng)調(diào)；5、 增加反饋和交流可以減少中間產(chǎn)品和文檔的需求；6、 輕量級方法更強(qiáng)調(diào)理解（understanding），自律（discipline）和技能(skill)，重量級方法更強(qiáng)調(diào)文檔（documentation），過程（process）和正式（formality）；understanding指整個(gè)團(tuán)隊(duì)關(guān)于項(xiàng)目的全部知識，包括討論的過程

27、，documentation只能記錄其中的一部分；discipline是指個(gè)人主動的完成工作，process指個(gè)人根據(jù)指令完成工作，skill指具有良好技能的人可以省略中間的產(chǎn)品，formality指必須按照規(guī)定步驟完成工作。7、 確定開發(fā)中間的瓶徑，提高它的效率；對于瓶頸處的工作應(yīng)該盡量加快，減少重復(fù)，（使用更熟練的人，使用更多的人，使用更好的工具，使瓶頸處的工作的深入盡量穩(wěn)定）對于非瓶頸處的工作可以多一些重復(fù)，在輸入還不確定的情況下也可以盡早開始。上述原理的幾個(gè)結(jié)論：1、向一個(gè)項(xiàng)目增加人員要花費(fèi)較大代價(jià)，因?yàn)樵腥藛T和新加入人員之間的交流要花費(fèi)大量時(shí)間；2、團(tuán)隊(duì)的規(guī)模經(jīng)常是跳躍的，例如：需

28、要6個(gè)熟練的程序員，但是只有4個(gè)，于是增加不熟練的程序員，結(jié)果團(tuán)隊(duì)的大量時(shí)間花費(fèi)在培訓(xùn)不熟練的程序員上面，最后增加到了20個(gè)不熟練的程序員；3、應(yīng)該側(cè)重于提高團(tuán)隊(duì)的技能而不是擴(kuò)充團(tuán)隊(duì)；4、對不同的項(xiàng)目使用不同的過程；5、在適用的條件下，輕量級的方法優(yōu)于重量級的方法；6、對不同的項(xiàng)目要裁減過程。6.7.2 優(yōu)缺點(diǎn)敏捷開發(fā)模型對于需求已經(jīng)明確而且內(nèi)容較少，技術(shù)方面的風(fēng)險(xiǎn)較少的項(xiàng)目，適合采用這種模型。敏捷模型剪裁了過程，并要求過程間快速跟進(jìn)，可以出現(xiàn)邊分析、邊設(shè)計(jì)、邊編碼、邊測試的情形，但是這些過程不要相重疊得太多，原則上允許兩個(gè)階段的過程同時(shí)進(jìn)行。此模型為規(guī)模小，周期短的項(xiàng)目簡化了項(xiàng)目跟蹤控制，減

29、少了過程支撐部分的時(shí)間花費(fèi)。敏捷模型注重的是項(xiàng)目各過程的快速跟進(jìn)，即前一過程已經(jīng)基本完成，等待評審或驗(yàn)證，就可以開始開展下一過程的工作，利用階段評審或驗(yàn)證的時(shí)間快速跟進(jìn)，加快了項(xiàng)目推進(jìn)速度。再一個(gè)優(yōu)點(diǎn)就是可以減少一些把握性比較高評審。缺點(diǎn)是在項(xiàng)目剪裁掉的過程或者評審，增加了項(xiàng)目的風(fēng)險(xiǎn)，定義小項(xiàng)目才采取這種模型，改正起來比較容易。6.7.3 階段定義圖 敏捷開發(fā)模型敏捷軟件開發(fā)生命周期開始于初始需求和架構(gòu)設(shè)想，以創(chuàng)建初始工作項(xiàng)堆棧并為團(tuán)隊(duì)設(shè)定技術(shù)方向。團(tuán)隊(duì)從每個(gè)迭代中生成一個(gè)可論證的產(chǎn)品，該產(chǎn)品可能對外提供。在此過程中，涉眾通過描述，確定優(yōu)先級和改進(jìn)需求積極參與。該產(chǎn)品繼續(xù)經(jīng)過開發(fā)團(tuán)隊(duì)、涉眾和獨(dú)

30、立測試人員的驗(yàn)證。敏捷項(xiàng)目要經(jīng)過不同的階段，在各個(gè)階段，團(tuán)隊(duì)的重點(diǎn)會發(fā)生變化，過程嚴(yán)密性在開始并不重要，在轉(zhuǎn)換期間會變得很重要。6.7.4 選用規(guī)則項(xiàng)目的需求明確、理解充分、并且需求內(nèi)容較少；軟件的應(yīng)用環(huán)境是常規(guī)的、主流的和成熟的；項(xiàng)目擬采用的技術(shù)是成熟的，擬使用的開發(fā)工具是為項(xiàng)目組人員所熟練掌握的；項(xiàng)目組人員有類似的項(xiàng)目經(jīng)驗(yàn)；項(xiàng)目的風(fēng)險(xiǎn)較少，對風(fēng)險(xiǎn)管理要求不高的；項(xiàng)目投入人員少于10人，并且開發(fā)周期在6個(gè)月以內(nèi)的；6.8 V模型6.8.1 V模型介紹如V模型圖中所示，左邊下降的是開發(fā)過程各階段，與此相對應(yīng)的是右邊上升的部分，即測試過程的各個(gè)階段。在模型圖中的開發(fā)階段一側(cè)，先從定義業(yè)務(wù)需求和需

31、求分析開始，然后把這些需求不斷地轉(zhuǎn)換到概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)中去，最后開發(fā)為程序代碼。在測試執(zhí)行階段一側(cè)，執(zhí)行先從單元測試開始，然后是集成測試、系統(tǒng)測試和驗(yàn)收測試。V模型的價(jià)值在于它非常明確地標(biāo)明了測試過程中存在的不同測試層次，模型圖將測試層次和軟件開發(fā)階段的關(guān)系表現(xiàn)得非常清晰，縱向關(guān)系體現(xiàn)了驗(yàn)證的對象，橫向的對應(yīng)關(guān)系則體現(xiàn)了各類型的測試所確認(rèn)的對象。這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系如下： Ø 單元測試的主要目的是針對編碼過程中可能存在的各種錯(cuò)誤。 Ø 集成測試的主要目的是針對詳細(xì)設(shè)計(jì)中可能存在的問題，尤其是檢查各單元與其它程序部分之間的接口上可能存在的錯(cuò)誤。 

32、16; 系統(tǒng)測試的主要針對概要設(shè)計(jì)，檢查了系統(tǒng)作為一個(gè)整體是否有效地得到運(yùn)行。 Ø 驗(yàn)收測試通常由業(yè)務(wù)專家或用戶進(jìn)行，以確認(rèn)軟件產(chǎn)品能真正符合用戶業(yè)務(wù)上的需要。 圖 V模型另外，項(xiàng)目經(jīng)理要按不同階段適時(shí)運(yùn)用人員，恰當(dāng)掌握用人標(biāo)準(zhǔn)。一般來說，軟件項(xiàng)目不同階段不同層次技術(shù)人員的參與情況是不一樣的。下圖是V模型的軟件開發(fā)人員參與情況曲線：6.8.2 優(yōu)缺點(diǎn)² 為測試用例的設(shè)計(jì)提供了更廣泛的信息在傳統(tǒng)的軟件生命周期中，測試階段的順序被置于中后期，測試用例的設(shè)計(jì)就主要依據(jù)于前期各階段的文檔，而文檔更新的速度遠(yuǎn)遠(yuǎn)不及代碼變化的速度，文檔的信息也有所失真；而V模型就可以克服傳統(tǒng)軟件生命周期在測試方面的缺點(diǎn)，在需求分析與設(shè)計(jì)的同時(shí)就可以進(jìn)行相應(yīng)層次的測試用例的設(shè)計(jì)，有效的保證測試的目標(biāo)和覆蓋率，通過團(tuán)隊(duì)成員間的及時(shí)溝通，充分利用了需求人員，設(shè)計(jì)人員的力量來指導(dǎo)測試工作，使得測試工作不僅僅是依賴于文檔。² 測試與編碼的混合狀態(tài)如果等到所有的編碼完成再開始單元測試，集中測試發(fā)現(xiàn)的結(jié)果必將讓開發(fā)團(tuán)隊(duì)措手不及；V模型的方法就是：開發(fā)一段，測試一點(diǎn)；發(fā)現(xiàn)缺陷，修復(fù)缺陷；再開發(fā)，再測試。編碼和測試是處于一種反復(fù)輪換的狀態(tài)，可以及時(shí)有效地處理測試缺陷。²  階段的并行性在 V模型中