軟件生命周期選擇指南

1、軟件生命周期選擇指南目的本指南的制定是為了在項(xiàng)目研發(fā)過程中，可以有一種完整統(tǒng)一的措施來分析項(xiàng)目需求，預(yù)先辨認(rèn)項(xiàng)目特性，并提供可供項(xiàng)目選擇的軟件生命周期模型，使其可以和組織原則軟件過程結(jié)合在一起使用。合用范疇軟件生命周期是指從軟件產(chǎn)品開始到軟件停止使用為止的時間間隔。對生命周期細(xì)分階段進(jìn)行管理稱為周期模型，典型的幾種生命周期模型涉及瀑布模型、增量模型、螺旋模型和迅速原型模型、迭代模型。項(xiàng)目組應(yīng)在軟件項(xiàng)目籌劃階段，認(rèn)真考慮項(xiàng)目的特性和目的，在此基本上參照原有模型，或?yàn)轫?xiàng)目開發(fā)新設(shè)計(jì)出一種軟件生命周期模型。無論選擇何種模型，都要涉及下列一般軟件工程過程必須涉及的內(nèi)容：項(xiàng)目啟動項(xiàng)目籌劃需求分析軟件設(shè)計(jì)

2、編碼測試交付與驗(yàn)收運(yùn)營維護(hù)項(xiàng)目停止使用責(zé)任項(xiàng)目經(jīng)理1）迅速歸納軟件項(xiàng)目研發(fā)需求2）總結(jié)類似項(xiàng)目的開發(fā)經(jīng)驗(yàn)3）提出項(xiàng)目開發(fā)參照模型4）與項(xiàng)目構(gòu)成員一起討論裁剪模型項(xiàng)目成員總結(jié)類似項(xiàng)目的開發(fā)經(jīng)驗(yàn)與其她項(xiàng)目成員一起裁剪模型規(guī)定啟動準(zhǔn)則項(xiàng)目籌劃開始制定。輸入初始顧客需求及初始項(xiàng)目籌劃。重要環(huán)節(jié)軟件生命周期模型一般都是在原有的模型基本上根據(jù)客戶的需求變更和最后的目的實(shí)現(xiàn)判斷項(xiàng)目特性進(jìn)行裁剪產(chǎn)生的，重要經(jīng)歷四個環(huán)節(jié)：需求分析、原型參照、裁剪定義和模型實(shí)行。需求分析 從軟件概念第一次被提出，并且明確了實(shí)現(xiàn)目的，就進(jìn)入項(xiàng)目概念階段，這個時候項(xiàng)目組開始組建，同步收集需求，項(xiàng)目經(jīng)理應(yīng)積極配合業(yè)務(wù)代表參與需求研討和

3、項(xiàng)目的籌劃，安排有經(jīng)驗(yàn)的人員進(jìn)入項(xiàng)目組，迅速對需求進(jìn)行初步分析，概括項(xiàng)目的特性。 此部分的需求分析還應(yīng)當(dāng)涉及對歷史項(xiàng)目的回憶，總結(jié)成功實(shí)行經(jīng)驗(yàn)和吸取失敗教訓(xùn)，并歸檔備案作為組織的過程資產(chǎn)庫。原型參照 當(dāng)項(xiàng)目最后實(shí)現(xiàn)目的擬定，同步辨認(rèn)出項(xiàng)目特性，從組織批準(zhǔn)使用的軟件生命周期模型中挑選出一種以供參照，該周期原型必須在很大限度上適合項(xiàng)目的具體特性以及可以結(jié)合組織原則軟件過程一起使用。 項(xiàng)目一開始，周期模型僅作參照，下一步還必須結(jié)合實(shí)際的越來越豐富的需求進(jìn)行裁剪以達(dá)到新模型的指引目的。新裁剪出的模型可以歸檔成為下一種類似項(xiàng)目的原始參照模型。 原型的描述重要涉及軟件生命周期模型的原理、優(yōu)缺陷、階段定義和

4、選用規(guī)則。裁剪定義 裁剪基于項(xiàng)目特性 項(xiàng)目特性是裁剪工作的出發(fā)點(diǎn)，涉及項(xiàng)目規(guī)模（如大、中、小等）、項(xiàng)目類型（如新開發(fā)、維護(hù)等），以及技術(shù)難度、產(chǎn)品類型、項(xiàng)目周期等要素。明確可裁剪的對象可裁剪對象擬定了裁剪的范疇，不僅僅限于過程元素和活動，還涉及參照原則、措施和工具、輸出產(chǎn)品及模板等。擬定裁剪所考慮的要素裁剪要素界定了裁剪的方向和尺度。例如，對于某個裁剪對象，其范疇與頻度都是裁剪要素。對于有開發(fā)經(jīng)驗(yàn)的小項(xiàng)目，可以合適減少對于技術(shù)方面的評審的頻度。裁剪的決定要基于風(fēng)險進(jìn)行考慮基于風(fēng)險可檢查裁剪的合適性。對過程或活動的調(diào)節(jié)或放棄，需要通過度析其所帶來的風(fēng)險和影響再做決定。模型實(shí)行 裁剪后的周期模型，

5、是個具有項(xiàng)目特性的組織原則軟件過程，該過程涉及軟件生命周期模型的原理、優(yōu)缺陷等描述，可以協(xié)助軟件開發(fā)人員更好地理解和運(yùn)用組織已批準(zhǔn)的軟件生命周期進(jìn)行項(xiàng)目開發(fā)。 新模型對于項(xiàng)目開發(fā)具有指引意義，必須將該模型下達(dá)告知到項(xiàng)目組所有成員，項(xiàng)目經(jīng)理必須監(jiān)督保證模型的推廣，實(shí)現(xiàn)“項(xiàng)目可控，質(zhì)量可靠”的最后目的。模型選擇建議在前期需求明確的狀況下盡量采用瀑布模型或改善型的瀑布模型。在顧客無信息系統(tǒng)使用經(jīng)驗(yàn)，需求分析人員技能局限性狀況下一定要借助原型。在不擬定性因素諸多，諸多東西前面無法籌劃狀況下，盡量采用增量迭代和螺旋模型。在需求不穩(wěn)定狀況下盡量采用增量、迭代模型。在資金和成本無法一次到位狀況下可以采用增量

6、模型，軟件產(chǎn)品分多種版本進(jìn)行發(fā)布。對于完全多種獨(dú)立功能開發(fā)可以在需求階段就分功能并行，但每個功能內(nèi)都應(yīng)當(dāng)遵循瀑布模型。對于全新系統(tǒng)的開發(fā)必須在總體設(shè)計(jì)完畢后再開始增量或并行。對于編碼人員經(jīng)驗(yàn)較少狀況下，建議不要采用敏捷或迭代等生命周期模型。增量、迭代和原型可以綜合使用，但每一次增量或迭代都必須有明確的交付和出口準(zhǔn)則。輸出具有項(xiàng)目特性的軟件生命周期模型。結(jié)束準(zhǔn)則項(xiàng)目生命周期模型已擬定。度量本指南暫無度量規(guī)定。剪裁本指南不容許剪裁。定義與縮略語定義無縮略語SLCSoftware Lift Cycle軟件生命周期SLCMSoftware Lift Cycle Model軟件生命周期模型PMProje

7、ct Manager項(xiàng)目經(jīng)理SEISoftware Engineering Institute 軟件工程學(xué)院SLCPSLC-Process軟件生命周期流程文檔附錄附錄A軟件生命周期模型附錄A 軟件生命周期模型瀑布模型模型簡介概要設(shè)計(jì)發(fā)布測試實(shí)現(xiàn)具體設(shè)計(jì)需求分析維護(hù)概要設(shè)計(jì)發(fā)布測試實(shí)現(xiàn)具體設(shè)計(jì)需求分析維護(hù)瀑布模型規(guī)定了各項(xiàng)軟件工程活動是按照自上而下、互相銜接的固定順序逐漸完畢。其形如瀑布流水，逐級而下，其狀持續(xù)不斷，直到項(xiàng)目后期才干開圖 瀑布模型發(fā)出軟件產(chǎn)品。瀑布模型為軟件開發(fā)和軟件維護(hù)提供了一種有效的管理圖示。根據(jù)這一圖示制定開發(fā)籌劃、進(jìn)行成本預(yù)算、組織開發(fā)力量，以項(xiàng)目的階段評審和文檔控制為手

8、段有效地對整個開發(fā)過程進(jìn)行指引，從而保證軟件產(chǎn)品及時交付，并達(dá)到預(yù)期的質(zhì)量規(guī)定。優(yōu)缺陷瀑布模型強(qiáng)調(diào)開發(fā)的階段性，強(qiáng)調(diào)初期籌劃和需求調(diào)查，強(qiáng)調(diào)產(chǎn)品的測試和驗(yàn)收。對于軟件外包這樣強(qiáng)調(diào)階段性檢查的項(xiàng)目具有很大的合用性。但模型突出的缺陷是缺少靈活性，依賴于初期進(jìn)行的需求調(diào)查，特別是無法解決軟件需求不明確或不精確的問題，這種狀況往往需要進(jìn)行返工或者在維護(hù)中糾正需求的偏差，極大的增長了風(fēng)險成本，并由于是單向流動，開發(fā)過程中的階段經(jīng)驗(yàn)教訓(xùn)很難反饋在項(xiàng)目同階段的實(shí)行過程中。階段定義階段進(jìn)入原則任務(wù)退出原則需求分析分派到軟件的系統(tǒng)需求已擬定；項(xiàng)目籌劃已批準(zhǔn) 進(jìn)行軟件需求分析軟件需求分析完畢并形成基線。概要設(shè)計(jì)軟

9、件需求規(guī)格闡明書已經(jīng)完畢并通過評審進(jìn)行數(shù)據(jù)庫設(shè)計(jì)、各模塊的概要設(shè)計(jì)、集成測試用例編寫數(shù)據(jù)庫設(shè)計(jì)、概要設(shè)計(jì)、集成測試用例編寫完畢并形成基線。具體設(shè)計(jì)數(shù)據(jù)庫設(shè)計(jì)、概要設(shè)計(jì)、集成測試用例編寫完畢并形成基線。進(jìn)行具體設(shè)計(jì)及單元測試用例編寫。具體設(shè)計(jì)及單體測試用例編寫完畢并形成基線。實(shí)現(xiàn)具體設(shè)計(jì)及單體測試用例編寫完畢進(jìn)行編碼及單元測試編碼及單體測試完畢并形成基線。測試編碼完畢進(jìn)行集成、系統(tǒng)測試集成、系統(tǒng)測試報告發(fā)布測試已經(jīng)完畢顧客手冊、在線協(xié)助等文檔編寫，安裝程序制作顧客手冊、在線協(xié)助等文檔編寫完畢并形成基線，安裝程序制作完畢選用規(guī)則當(dāng)項(xiàng)目的需求明確、理解充足、并且較為穩(wěn)定期，適合選擇瀑布模型，絕大部分

10、的原則軟件過程都可以應(yīng)用瀑布模型。增量模型模型簡介增量模型是瀑布模型的一種變化模型。這種方式是一方面建立概要設(shè)計(jì)，然后設(shè)計(jì)的實(shí)現(xiàn)是通過一系列小的、互相交錯的子項(xiàng)目，每個子項(xiàng)目完畢一種獨(dú)特的功能。第一種增量往往是核心的產(chǎn)品，即實(shí)現(xiàn)了基本的規(guī)定，但諸多補(bǔ)充的特性還沒有開發(fā)。核心產(chǎn)品交顧客使用的成果是下一種增量的開發(fā)籌劃。該籌劃涉及對核心產(chǎn)品的修改，也涉及新增的特點(diǎn)和功能。這個過程在每個增量發(fā)布后不斷反復(fù)，直到產(chǎn)生最后的完善產(chǎn)品。增量1具體設(shè)計(jì)編碼單元測試系統(tǒng)集成測試交付增量2具體設(shè)計(jì)增量3具體設(shè)計(jì)編碼單元測試系統(tǒng)集成測試系統(tǒng)集成測試編碼單元測試軟件系統(tǒng)測試概要設(shè)計(jì)分析需求增量1具體設(shè)計(jì)編碼單元測試

11、系統(tǒng)集成測試交付增量2具體設(shè)計(jì)增量3具體設(shè)計(jì)編碼單元測試系統(tǒng)集成測試系統(tǒng)集成測試編碼單元測試軟件系統(tǒng)測試概要設(shè)計(jì)分析需求圖 增量模型優(yōu)缺陷增量模型強(qiáng)調(diào)開發(fā)的分散性，項(xiàng)目需求可以分批獲取，任意一種子項(xiàng)目的需求一經(jīng)擬定就可進(jìn)入設(shè)計(jì)和編碼階段，最后提交驗(yàn)證測試，可以及早地從測試過程中發(fā)現(xiàn)實(shí)現(xiàn)過程中存在的問題，并將經(jīng)驗(yàn)教訓(xùn)反饋在項(xiàng)目的下一種循環(huán)過程。由于在項(xiàng)目初期就能獲得項(xiàng)目監(jiān)控數(shù)據(jù)，有助于辨認(rèn)和分析風(fēng)險，并可對后期開發(fā)做出的確的項(xiàng)目估算，增長項(xiàng)目的成功率。同樣模型也是存在明顯的缺陷的。開發(fā)的分散，削弱了需求設(shè)計(jì)的完整性，重要問題反映在項(xiàng)目的系統(tǒng)集成階段，影響了系統(tǒng)性能和產(chǎn)品的可維護(hù)性，同步也增長版本

12、控制等不安定的因素。階段定義階段進(jìn)入原則任務(wù)退出原則增量1項(xiàng)目籌劃已批準(zhǔn)并進(jìn)行了總體的需求分析及概要設(shè)計(jì)進(jìn)行第一階段的具體設(shè)計(jì)、編碼、測試及發(fā)布。第一階段產(chǎn)品完畢并形成基線增量2增量1產(chǎn)品已經(jīng)完畢并完善了本階段的需求分析及概要設(shè)計(jì)進(jìn)行第二階段的具體設(shè)計(jì)、編碼、測試及發(fā)布。第二階段產(chǎn)品完畢并形成基線增量3增量2產(chǎn)品已經(jīng)完畢并完善了本階段的需求分析及概要設(shè)計(jì)進(jìn)行第三階段的具體設(shè)計(jì)、編碼、測試及發(fā)布第三階段產(chǎn)品完畢并形成基線各階段中涉及的具體階段請參照瀑布模型。選用規(guī)則當(dāng)項(xiàng)目可清晰地劃分為多種功能獨(dú)立的子項(xiàng)目，或采用階段開發(fā)時，適合選擇增量模型。螺旋模型模型簡介螺旋模型也是瀑布模型的一種變化模型，其

13、中的每個回旋代表一種特定開發(fā)階段。每個特定開發(fā)階段都結(jié)合了風(fēng)險分析和瀑布原型，這也是與瀑布模型的區(qū)別之處。制定籌劃制定籌劃風(fēng)險分析客戶評估工程實(shí)行圖 螺旋模型螺旋模型沿著螺線旋轉(zhuǎn)，如圖所示，在笛卡爾坐標(biāo)的四個象限上分別體現(xiàn)了四個方面的活動，即：制定籌劃：擬定軟件目的，選定實(shí)行方案，弄清項(xiàng)目開發(fā)的限制條件風(fēng)險分析：分析所選方案，考慮如何辨認(rèn)和消除風(fēng)險實(shí)行工程：實(shí)行軟件開發(fā)客戶評估：評價開發(fā)工作，提出修正建議螺旋模型在每一種開發(fā)階段之前，都引入非常嚴(yán)格的風(fēng)險辨認(rèn)、風(fēng)險分析和風(fēng)險控制，直到采用了消除風(fēng)險的措施之后，才開始籌劃該階段的開發(fā)工作，而每次回旋都開發(fā)出更為完善的一種新的軟件版本。例如：在第一

14、圈，擬定了初步的目的、方案和限制條件后，轉(zhuǎn)入右上相限，對風(fēng)險進(jìn)行辨認(rèn)和分析。如果風(fēng)險分析表白，需求有不擬定性，那么在右下的實(shí)行工程相限內(nèi)，所建的原型會協(xié)助開發(fā)人員和客戶，考慮其他開發(fā)模型，并對需求做進(jìn)一步修正?？蛻魧こ坛晒龀鲈u價之后，給出修正建議。在此基本上需再次籌劃，并進(jìn)行風(fēng)險分析。每浮現(xiàn)一種新的版本都越來越符合客戶需求，逐漸消除或減少風(fēng)險的損害。在每一圈螺線上，做出風(fēng)險分析的終點(diǎn)與否繼續(xù)下去的判斷。如果風(fēng)險過大，開發(fā)者和顧客無法承受，項(xiàng)目有也許終結(jié)。多數(shù)狀況下沿螺線的活動會繼續(xù)下去，自內(nèi)向外，逐漸延伸，最后得到所盼望的系統(tǒng)。優(yōu)缺陷螺旋模型強(qiáng)調(diào)風(fēng)險管理，強(qiáng)調(diào)對項(xiàng)目的各個階段審查，提供機(jī)會

15、討論項(xiàng)目與否有價值繼續(xù)進(jìn)展下去，可以及早地發(fā)現(xiàn)和終結(jié)虧損項(xiàng)目。由于引入嚴(yán)格的風(fēng)險管理，這對項(xiàng)目管理水平提出更高的規(guī)定，需要更多的人員、資金和時間的投入，增長了項(xiàng)目成本。階段定義階段進(jìn)入原則任務(wù)退出原則原型1項(xiàng)目籌劃已批準(zhǔn)進(jìn)行原型1制作原型1提交并形成基線原型2原型1形成基線進(jìn)行原型2制作原型2提交并形成基線原型3原型2形成基線進(jìn)行原型3制作原型3提交并形成基線各階段中涉及的具體階段請參照瀑布模型。選用規(guī)則對于大規(guī)模、復(fù)雜而需求理解不充足、風(fēng)險較大、產(chǎn)品規(guī)定質(zhì)量高且對開發(fā)周期沒有嚴(yán)格規(guī)定的項(xiàng)目適合選擇螺旋模型。迅速原型模型模型簡介迅速原型模型不同于老式的瀑布模型，其核心是套用原型，迅速開發(fā)。由于

16、客戶對需求的不明朗，無法在初期就能對需求進(jìn)行明確分析和相應(yīng)的風(fēng)險管理，將在設(shè)計(jì)階段不斷返工，導(dǎo)致項(xiàng)目成本增大，而迅速原型模型可以較好地解決這個問題。在獲得一組基本需求闡明后，通過迅速分析構(gòu)造出一種小型的軟件系統(tǒng)，滿足顧客的基本規(guī)定，使得客戶可在試用原型系統(tǒng)的過程中得到親身感受和受到啟發(fā)，做出反映和評價，然后開發(fā)者根據(jù)顧客的意見對原型加以改善。隨著不斷實(shí)驗(yàn)、糾錯、使用、評價和修改，獲得新的原型版本，如此周而復(fù)始，逐漸減少分析和通信中的誤解，彌補(bǔ)局限性之處，進(jìn)一步擬定多種需求細(xì)節(jié)，適應(yīng)需求的變更，從而提高了最后產(chǎn)品的質(zhì)量。原型評估迅速分析或修改構(gòu)造運(yùn)營原型評估迅速分析或修改構(gòu)造運(yùn)營圖 迅速原型模型

17、迅速原型模式類似于增量模式和螺旋模型的結(jié)合，只是，由于強(qiáng)調(diào)快，因此在功能和性能上有所取舍，同步不強(qiáng)調(diào)階段審查和風(fēng)險管理。需要注意的是構(gòu)造原型的目的是反映最后系統(tǒng)的重要特性，因此，我們必須明確規(guī)定對原型進(jìn)行考核和評價的內(nèi)容，如界面形式、系統(tǒng)構(gòu)造、功能或模擬性能等。優(yōu)缺陷迅速原型模型強(qiáng)調(diào)迅速分析，鼓勵與客戶互動，可以掌握客戶第一手需求資料，并通過與客戶的交流使開發(fā)者學(xué)習(xí)到應(yīng)用范疇的專業(yè)知識，可以更好地協(xié)助開發(fā)者理解和設(shè)計(jì)最后系統(tǒng)。該模型強(qiáng)調(diào)快的同步一般忽視了性能規(guī)定，因此一般原型版本并不是最后版本，最后版本都是在原型基本上重新設(shè)計(jì)開發(fā)的，無形中增長了項(xiàng)目成本，同步要精確地構(gòu)造一種原型并不是件容易的

18、事情，規(guī)定開發(fā)者具有豐富的項(xiàng)目開發(fā)經(jīng)驗(yàn)和相應(yīng)用范疇具有一定的專業(yè)知識，也規(guī)定項(xiàng)目經(jīng)理具有與客戶反復(fù)溝通的交流能力?？蛻羰菍﹂_發(fā)原型進(jìn)行評價得出需求的，因此，需求存在多變性，必須加強(qiáng)對需求的管理能力。階段定義階段進(jìn)入原則任務(wù)退出原則分析客戶提出部分需求對需求進(jìn)行迅速分析分析得到概要設(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)造選用規(guī)則對于從項(xiàng)目概念到項(xiàng)目立項(xiàng)周期規(guī)定較短但無法提供明確需求、具有演示性質(zhì)或者試點(diǎn)工程之類的的項(xiàng)目適合選擇迅速

19、原型模型。RUP迭代模型模型簡介RUP（Rational Unified Process）是 IBM Rational公司提出的一套開發(fā)過程模型，它是一種面向?qū)ο筌浖こ痰耐ㄓ脴I(yè)務(wù)流程。它描述了一系列有關(guān)的軟件工程流程，它們具有相似的構(gòu)造，即相似的流程構(gòu)架。RUP 為在開發(fā)組織中分派任務(wù)和職責(zé)提供了一種規(guī)范措施，其目的是保證在可估計(jì)的時間安排和預(yù)算內(nèi)開發(fā)出滿足最后顧客需求的高品質(zhì)的軟件。RUP具有兩個軸，一種軸是時間軸，這是動態(tài)的。另一種軸是工作流軸，這是靜態(tài)的。在時間軸上，RUP劃分了四個階段：初始階段、細(xì)化階段、構(gòu)造階段和發(fā)布階段。每個階段都使用了迭代的概念。在工作流軸上，RUP設(shè)計(jì)了六個

20、核心工作流程和三個核心支撐工作流程，核心工作流軸涉及：業(yè)務(wù)建模工作流、需求工作流、分析設(shè)計(jì)工作流、實(shí)現(xiàn)工作流、測試工作流和發(fā)布工作流。核心支撐工作流涉及：環(huán)境工作流、項(xiàng)目管理工作流和配備與變更管理工作流。RUP與增量迭代不完全相似，但是兩者往往互相涉及，在一種項(xiàng)目中往往一起使用。圖 RUP模型優(yōu)缺陷RUP 匯集現(xiàn)代軟件開發(fā)中多方面的最佳經(jīng)驗(yàn)，并為適應(yīng)多種項(xiàng)目及組織的需要提供了靈活的形式。作為一種商業(yè)模型，它具有非常具體的過程指引和模板，由于該模型通過多次迭代來完畢軟件項(xiàng)目開發(fā)任務(wù)，具有適應(yīng)變更、及早減少風(fēng)險、提高軟件質(zhì)量的長處。但是同樣由于該模型比較復(fù)雜，因此在模型的掌握上需要耗費(fèi)比較大的成本

21、。特別對項(xiàng)目管理者提出了比較高的規(guī)定。階段定義階段進(jìn)入原則任務(wù)退出原則先啟項(xiàng)目籌劃和迭代籌劃已制定1 理解需創(chuàng)立的系統(tǒng)，擬定愿景、范疇、邊界2 擬定系統(tǒng)的重要功能3 制定至少一種可行的方案4理解與項(xiàng)目有關(guān)的成本、時間進(jìn)度與風(fēng)險5 擬定遵循的過程和有關(guān)工具項(xiàng)目目的通過評審精化先啟階段結(jié)束1細(xì)化需求2 設(shè)計(jì)、實(shí)現(xiàn)、驗(yàn)證系統(tǒng)架構(gòu)并建立架構(gòu)基線3 化解重要風(fēng)險，更精確的制定進(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)

22、境并轉(zhuǎn)換數(shù)據(jù)庫與有關(guān)方完畢驗(yàn)收工作選用規(guī)則RUP模型是一種高規(guī)范度的迭代化措施，所有的文檔需要基于UML，對項(xiàng)目成員技能規(guī)定較高，如果顧客提出的項(xiàng)目對時間進(jìn)度規(guī)定相對寬松，風(fēng)險管理規(guī)定較高同步又能組建有足夠經(jīng)驗(yàn)的項(xiàng)目團(tuán)隊(duì)的狀況下可選用RUP措施。敏捷開發(fā)模型模型簡介敏捷開發(fā)（agile development）是一種以人為核心、迭代、循序漸進(jìn)的開發(fā)措施，是一種迭代和增量（發(fā)展）的措施，通過項(xiàng)目涉眾以高度協(xié)作和自組織的方式執(zhí)行，運(yùn)用適量資源以經(jīng)濟(jì)有效且及時的方式生產(chǎn)能滿足涉眾不斷變化的需求的高質(zhì)量軟件。在敏捷開發(fā)中，軟件項(xiàng)目的構(gòu)建被切提成多種子項(xiàng)目，各個子項(xiàng)目的成果都通過測試，具有集成和可運(yùn)營的

23、特性。簡言之，就是把一種大項(xiàng)目分為多種互相聯(lián)系，但也可獨(dú)立運(yùn)營的小項(xiàng)目，并分別完畢，在此過程中軟件始終處在可使用狀態(tài)。但敏捷開發(fā)并不是一種創(chuàng)新，敏捷開發(fā)可理解為在原有軟件開發(fā)措施基本上的整合取其精髓，去其糟粕。因此敏捷開發(fā)繼承了不少原有措施的優(yōu)勢。敏捷開發(fā)措施過程設(shè)計(jì)的幾種原理：1 、交互的面對面的交流是代價最小，最迅速的互換信息的措施；2、 超過實(shí)際需要的過程是揮霍的；3 、大的團(tuán)隊(duì)需要重量級措施；4 、解決重大問題的項(xiàng)目需要重量級措施強(qiáng)調(diào)；5、 增長反饋和交流可以減少中間產(chǎn)品和文檔的需求；6、 輕量級措施更強(qiáng)調(diào)理解（understanding），自律（discipline）和技能(skil

24、l)，重量級措施更強(qiáng)調(diào)文檔（documentation），過程（process）和正式（formality）；understanding指整個團(tuán)隊(duì)有關(guān)項(xiàng)目的所有知識，涉及討論的過程，documentation只能記錄其中的一部分；discipline是指個人積極的完畢工作，process指個人根據(jù)指令完畢工作，skill指具有良好技能的人可以省略中間的產(chǎn)品，formality指必須按照規(guī)定環(huán)節(jié)完畢工作。7、 擬定開發(fā)中間的瓶徑，提高它的效率；對于瓶頸處的工作應(yīng)當(dāng)盡量加快，減少反復(fù)，（使用更純熟的人，使用更多的人，使用更好的工具，使瓶頸處的工作的進(jìn)一步盡量穩(wěn)定）對于非瓶頸處的工作可以多某些反復(fù)，

25、在輸入還不擬定的狀況下也可以盡早開始。上述原理的幾種結(jié)論：1、向一種項(xiàng)目增長人員要耗費(fèi)較大代價，由于原有人員和新加入人員之間的交流要耗費(fèi)大量時間；2、團(tuán)隊(duì)的規(guī)模常常是跳躍的，例如：需要6個純熟的程序員，但是只有4個，于是增長不純熟的程序員，成果團(tuán)隊(duì)的大量時間耗費(fèi)在培訓(xùn)不純熟的程序員上面，最后增長到了20個不純熟的程序員；3、應(yīng)當(dāng)側(cè)重于提高團(tuán)隊(duì)的技能而不是擴(kuò)大團(tuán)隊(duì)；4、對不同的項(xiàng)目使用不同的過程；5、在合用的條件下，輕量級的措施優(yōu)于重量級的措施；6、對不同的項(xiàng)目要裁減過程。優(yōu)缺陷敏捷開發(fā)模型對于需求已經(jīng)明確并且內(nèi)容較少，技術(shù)方面的風(fēng)險較少的項(xiàng)目，適合采用這種模型。敏捷模型剪裁了過程，并規(guī)定過程間

26、迅速跟進(jìn)，可以浮現(xiàn)邊分析、邊設(shè)計(jì)、邊編碼、邊測試的情形，但是這些過程不要相重疊得太多，原則上容許兩個階段的過程同步進(jìn)行。此模型為規(guī)模小，周期短的項(xiàng)目簡化了項(xiàng)目跟蹤控制，減少了過程支撐部分的時間耗費(fèi)。敏捷模型注重的是項(xiàng)目各過程的迅速跟進(jìn)，即前一過程已經(jīng)基本完畢，等待評審或驗(yàn)證，就可以開始開展下一過程的工作，運(yùn)用階段評審或驗(yàn)證的時間迅速跟進(jìn)，加快了項(xiàng)目推動速度。再一種長處就是可以減少某些把握性比較高評審。缺陷是在項(xiàng)目剪裁掉的過程或者評審，增長了項(xiàng)目的風(fēng)險，定義小項(xiàng)目才采用這種模型，改正起來比較容易。階段定義圖 敏捷開發(fā)模型敏捷軟件開發(fā)生命周期開始于初始需求和架構(gòu)設(shè)想，以創(chuàng)立初始工作項(xiàng)堆棧并為團(tuán)隊(duì)設(shè)

27、定技術(shù)方向。團(tuán)隊(duì)從每個迭代中生成一種可論證的產(chǎn)品，該產(chǎn)品也許對外提供。在此過程中，涉眾通過描述，擬定優(yōu)先級和改善需求積極參與。該產(chǎn)品繼續(xù)通過開發(fā)團(tuán)隊(duì)、涉眾和獨(dú)立測試人員的驗(yàn)證。敏捷項(xiàng)目要通過不同的階段，在各個階段，團(tuán)隊(duì)的重點(diǎn)會發(fā)生變化，過程嚴(yán)密性在開始并不重要，在轉(zhuǎn)換期間會變得很重要。選用規(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)險較少，對風(fēng)險管理規(guī)定不高的；項(xiàng)目投入人員少于10人，并且開發(fā)周期在6個月以內(nèi)的；V模型V模型簡介如V模型圖中所示，

28、左邊下降的是開發(fā)過程各階段，與此相相應(yīng)的是右邊上升的部分，即測試過程的各個階段。在模型圖中的開發(fā)階段一側(cè)，先從定義業(yè)務(wù)需求和需求分析開始，然后把這些需求不斷地轉(zhuǎn)換到概要設(shè)計(jì)和具體設(shè)計(jì)中去，最后開發(fā)為程序代碼。在測試執(zhí)行階段一側(cè)，執(zhí)行先從單元測試開始，然后是集成測試、系統(tǒng)測試和驗(yàn)收測試。V模型的價值在于它非常明確地標(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)系如下： 單元測試的重要目的是針對編碼過程中也許存在的多種錯誤。 集成測試的重要目的

29、是針對具體設(shè)計(jì)中也許存在的問題，特別是檢查各單元與其他程序部分之間的接口上也許存在的錯誤。 系統(tǒng)測試的重要針對概要設(shè)計(jì)，檢查了系統(tǒng)作為一種整體與否有效地得到運(yùn)營。 驗(yàn)收測試一般由業(yè)務(wù)專家或顧客進(jìn)行，以確認(rèn)軟件產(chǎn)品能真正符合顧客業(yè)務(wù)上的需要。 圖 V模型此外，項(xiàng)目經(jīng)理要按不同階段適時運(yùn)用人員，恰當(dāng)掌握用人原則。一般來說，軟件項(xiàng)目不同階段不同層次技術(shù)人員的參與狀況是不同樣的。下圖是V模型的軟件開發(fā)人員參與狀況曲線：優(yōu)缺陷為測試用例的設(shè)計(jì)提供了更廣泛的信息在老式的軟件生命周期中，測試階段的順序被置于中后期，測試用例的設(shè)計(jì)就重要根據(jù)于前期各階段的文檔，而文檔更新的速度遠(yuǎn)遠(yuǎn)不及代碼變化的速度，文檔的信息

30、也有所失真；而V模型就可以克服老式軟件生命周期在測試方面的缺陷，在需求分析與設(shè)計(jì)的同步就可以進(jìn)行相應(yīng)層次的測試用例的設(shè)計(jì)，有效的保證測試的目的和覆蓋率，通過團(tuán)隊(duì)成員間的及時溝通，充足運(yùn)用了需求人員，設(shè)計(jì)人員的力量來指引測試工作，使得測試工作不僅僅是依賴于文檔。測試與編碼的混合狀態(tài)如果等到所有的編碼完畢再開始單元測試，集中測試發(fā)現(xiàn)的成果必將讓開發(fā)團(tuán)隊(duì)措手不及；V模型的措施就是：開發(fā)一段，測試一點(diǎn)；發(fā)現(xiàn)缺陷，修復(fù)缺陷；再開發(fā)，再測試。編碼和測試是處在一種反復(fù)輪換的狀態(tài)，可以及時有效地解決測試缺陷。階段的并行性在V模型中，軟件分析與設(shè)計(jì)階段在邏輯上分別相應(yīng)于右側(cè)的各個測試階段。對于嚴(yán)格按照順序執(zhí)行的各個測試階段，容許其靈活的做合適的提前和推后，使得相鄰，甚至非相鄰的