軟件生命周期選取指南(共27頁)

1、精選優(yōu)質(zhì)文檔-傾情為你奉上中國廣東核電集團CHINA GUANGDONG NUCLEAR POWER GROUP記 錄 文 件CGN-IT-C3-A18-01軟件生命周期選擇指南版本編寫審核審定批準(zhǔn)生效時間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)。專心-專注-專業(yè)修改記錄頁NO修改日期修改摘要（涉及頁碼/條款/內(nèi)容）版本修改原因目 錄1. 目的本指南的制定是為了在項目研發(fā)過程中，能夠

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

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

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

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

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

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

8、8; 增量、迭代和原型可以綜合使用，但每一次增量或迭代都必須有明確的交付和出口準(zhǔn)則。4.3.4 輸出具有項目特征的軟件生命周期模型。4.3.5 結(jié)束準(zhǔn)則項目生命周期模型已確定。4.4 度量本指南暫無度量要求。4.5 剪裁本指南不允許剪裁。5. 定義與縮略語5.1 定義無5.2 縮略語SLCSoftware Lift Cycle軟件生命周期SLCMSoftware Lift Cycle Model軟件生命周期模型PMProject Manager項目經(jīng)理SEISoftware Engineering Institute 軟件工程學(xué)院SLCPSLC-Process軟件生命周期流程文檔6. 附錄&#

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

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

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

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

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

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

15、即：1) 制定計劃：確定軟件目標(biāo)，選定實施方案，弄清項目開發(fā)的限制條件2) 風(fēng)險分析：分析所選方案，考慮如何識別和消除風(fēng)險3) 實施工程：實施軟件開發(fā)4) 客戶評估：評價開發(fā)工作，提出修正建議螺旋模型在每一個開發(fā)階段之前，都引入非常嚴(yán)格的風(fēng)險識別、風(fēng)險分析和風(fēng)險控制，直到采取了消除風(fēng)險的措施之后，才開始計劃該階段的開發(fā)工作，而每次回旋都開發(fā)出更為完善的一個新的軟件版本。例如：在第一圈，確定了初步的目標(biāo)、方案和限制條件后，轉(zhuǎn)入右上相限，對風(fēng)險進(jìn)行識別和分析。如果風(fēng)險分析表明，需求有不確定性，那么在右下的實施工程相限內(nèi)，所建的原型會幫助開發(fā)人員和客戶，考慮其它開發(fā)模型，并對需求做進(jìn)一步修正。客戶對

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

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

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

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

20、對需求的管理能力。6.5.3 階段定義階段進(jìn)入標(biāo)準(zhǔn)任務(wù)退出標(biāo)準(zhǔn)分析客戶提出部分需求對需求進(jìn)行快速分析分析得到概要設(shè)計構(gòu)造需求的概要設(shè)計已經(jīng)完成根據(jù)設(shè)計開發(fā)原型系統(tǒng)系統(tǒng)開發(fā)完畢并體現(xiàn)重要特性運行系統(tǒng)開發(fā)完畢發(fā)布系統(tǒng)提交客戶評估新的原型系統(tǒng)開發(fā)完畢評估系統(tǒng)正常運行與客戶溝通進(jìn)一步明確系統(tǒng)需求需求變更程度達(dá)到新一輪的原型構(gòu)造6.5.4 選用規(guī)則對于從項目概念到項目立項周期要求較短但無法提供明確需求、具備演示性質(zhì)或者試點工程之類的的項目適合選擇快速原型模型。6.6 RUP迭代模型6.6.1 模型介紹RUP（Rational Unified Process）是 IBM Rational公司提出的一套開發(fā)

21、過程模型，它是一個面向?qū)ο筌浖こ痰耐ㄓ脴I(yè)務(wù)流程。它描述了一系列相關(guān)的軟件工程流程，它們具有相同的結(jié)構(gòu)，即相同的流程構(gòu)架。RUP 為在開發(fā)組織中分配任務(wù)和職責(zé)提供了一種規(guī)范方法，其目標(biāo)是確保在可預(yù)計的時間安排和預(yù)算內(nèi)開發(fā)出滿足最終用戶需求的高品質(zhì)的軟件。RUP具有兩個軸，一個軸是時間軸，這是動態(tài)的。另一個軸是工作流軸，這是靜態(tài)的。在時間軸上，RUP劃分了四個階段：初始階段、細(xì)化階段、構(gòu)造階段和發(fā)布階段。每個階段都使用了迭代的概念。在工作流軸上，RUP設(shè)計了六個核心工作流程和三個核心支撐工作流程，核心工作流軸包括：業(yè)務(wù)建模工作流、需求工作流、分析設(shè)計工作流、實現(xiàn)工作流、測試工作流和發(fā)布工作流。核

22、心支撐工作流包括：環(huán)境工作流、項目管理工作流和配置與變更管理工作流。RUP與增量迭代不完全相同，但是二者往往互相包含，在一個項目中往往一起使用。圖 RUP模型6.6.2 優(yōu)缺點RUP 匯集現(xiàn)代軟件開發(fā)中多方面的最佳經(jīng)驗，并為適應(yīng)各種項目及組織的需要提供了靈活的形式。作為一個商業(yè)模型，它具有非常詳細(xì)的過程指導(dǎo)和模板，由于該模型通過多次迭代來完成軟件項目開發(fā)任務(wù)，具有適應(yīng)變更、及早降低風(fēng)險、提高軟件質(zhì)量的優(yōu)點。但是同樣由于該模型比較復(fù)雜，因此在模型的掌握上需要花費比較大的成本。尤其對項目管理者提出了比較高的要求。6.6.3 階段定義階段進(jìn)入標(biāo)準(zhǔn)任務(wù)退出標(biāo)準(zhǔn)先啟項目計劃和迭代計劃已制定1 了解需創(chuàng)建

23、的系統(tǒng)，確定愿景、范圍、邊界2 確定系統(tǒng)的主要功能3 制定至少一個可行的方案4了解與項目有關(guān)的成本、時間進(jìn)度與風(fēng)險5 確定遵循的過程和相關(guān)工具項目目標(biāo)通過評審精化先啟階段結(jié)束1細(xì)化需求2 設(shè)計、實現(xià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è)計、實現(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)方完成驗收工作6.6.4 選用規(guī)則RUP模型是一個高規(guī)范度的迭代化方法，所有的文檔需要基于U

24、ML，對項目成員技能要求較高，如果用戶提出的項目對時間進(jìn)度要求相對寬松，風(fēng)險管理要求較高同時又能組建有足夠經(jīng)驗的項目團隊的情況下可選用RUP方法。6.7 敏捷開發(fā)模型6.7.1 模型介紹敏捷開發(fā)（agile development）是一種以人為核心、迭代、循序漸進(jìn)的開發(fā)方法，是一種迭代和增量（發(fā)展）的方法，通過項目涉眾以高度協(xié)作和自組織的方式執(zhí)行，利用適量資源以經(jīng)濟有效且及時的方式生產(chǎn)能滿足涉眾不斷變化的需求的高質(zhì)量軟件。在敏捷開發(fā)中，軟件項目的構(gòu)建被切分成多個子項目，各個子項目的成果都經(jīng)過測試，具備集成和可運行的特征。簡言之，就是把一個大項目分為多個相互聯(lián)系，但也可獨立運行的小項目，并分別完

25、成，在此過程中軟件一直處于可使用狀態(tài)。但敏捷開發(fā)并不是一種創(chuàng)新，敏捷開發(fā)可理解為在原有軟件開發(fā)方法基礎(chǔ)上的整合取其精華，去其糟粕。因此敏捷開發(fā)繼承了不少原有方法的優(yōu)勢。敏捷開發(fā)方法過程設(shè)計的幾個原理：1 、交互的面對面的交流是代價最小，最迅速的交換信息的方法；2、 超過實際需要的過程是浪費的；3 、大的團隊需要重量級方法；4 、處理重大問題的項目需要重量級方法強調(diào)；5、 增加反饋和交流可以減少中間產(chǎn)品和文檔的需求；6、 輕量級方法更強調(diào)理解（understanding），自律（discipline）和技能(skill)，重量級方法更強調(diào)文檔（documentation），過程（process）

26、和正式（formality）；understanding指整個團隊關(guān)于項目的全部知識，包括討論的過程，documentation只能記錄其中的一部分；discipline是指個人主動的完成工作，process指個人根據(jù)指令完成工作，skill指具有良好技能的人可以省略中間的產(chǎn)品，formality指必須按照規(guī)定步驟完成工作。7、 確定開發(fā)中間的瓶徑，提高它的效率；對于瓶頸處的工作應(yīng)該盡量加快，減少重復(fù)，（使用更熟練的人，使用更多的人，使用更好的工具，使瓶頸處的工作的深入盡量穩(wěn)定）對于非瓶頸處的工作可以多一些重復(fù)，在輸入還不確定的情況下也可以盡早開始。上述原理的幾個結(jié)論：1、向一個項目增加人員要

27、花費較大代價，因為原有人員和新加入人員之間的交流要花費大量時間；2、團隊的規(guī)模經(jīng)常是跳躍的，例如：需要6個熟練的程序員，但是只有4個，于是增加不熟練的程序員，結(jié)果團隊的大量時間花費在培訓(xùn)不熟練的程序員上面，最后增加到了20個不熟練的程序員；3、應(yīng)該側(cè)重于提高團隊的技能而不是擴充團隊；4、對不同的項目使用不同的過程；5、在適用的條件下，輕量級的方法優(yōu)于重量級的方法；6、對不同的項目要裁減過程。6.7.2 優(yōu)缺點敏捷開發(fā)模型對于需求已經(jīng)明確而且內(nèi)容較少，技術(shù)方面的風(fēng)險較少的項目，適合采用這種模型。敏捷模型剪裁了過程，并要求過程間快速跟進(jìn)，可以出現(xiàn)邊分析、邊設(shè)計、邊編碼、邊測試的情形，但是這些過程不

28、要相重疊得太多，原則上允許兩個階段的過程同時進(jìn)行。此模型為規(guī)模小，周期短的項目簡化了項目跟蹤控制，減少了過程支撐部分的時間花費。敏捷模型注重的是項目各過程的快速跟進(jìn)，即前一過程已經(jīng)基本完成，等待評審或驗證，就可以開始開展下一過程的工作，利用階段評審或驗證的時間快速跟進(jìn)，加快了項目推進(jìn)速度。再一個優(yōu)點就是可以減少一些把握性比較高評審。缺點是在項目剪裁掉的過程或者評審，增加了項目的風(fēng)險，定義小項目才采取這種模型，改正起來比較容易。6.7.3 階段定義圖 敏捷開發(fā)模型敏捷軟件開發(fā)生命周期開始于初始需求和架構(gòu)設(shè)想，以創(chuàng)建初始工作項堆棧并為團隊設(shè)定技術(shù)方向。團隊從每個迭代中生成一個可論證的產(chǎn)品，該產(chǎn)品可

29、能對外提供。在此過程中，涉眾通過描述，確定優(yōu)先級和改進(jìn)需求積極參與。該產(chǎn)品繼續(xù)經(jīng)過開發(fā)團隊、涉眾和獨立測試人員的驗證。敏捷項目要經(jīng)過不同的階段，在各個階段，團隊的重點會發(fā)生變化，過程嚴(yán)密性在開始并不重要，在轉(zhuǎn)換期間會變得很重要。6.7.4 選用規(guī)則項目的需求明確、理解充分、并且需求內(nèi)容較少；軟件的應(yīng)用環(huán)境是常規(guī)的、主流的和成熟的；項目擬采用的技術(shù)是成熟的，擬使用的開發(fā)工具是為項目組人員所熟練掌握的；項目組人員有類似的項目經(jīng)驗；項目的風(fēng)險較少，對風(fēng)險管理要求不高的；項目投入人員少于10人，并且開發(fā)周期在6個月以內(nèi)的；6.8 V模型6.8.1 V模型介紹如V模型圖中所示，左邊下降的是開發(fā)過程各階段

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

31、的是針對詳細(xì)設(shè)計中可能存在的問題，尤其是檢查各單元與其它程序部分之間的接口上可能存在的錯誤。 Ø 系統(tǒng)測試的主要針對概要設(shè)計，檢查了系統(tǒng)作為一個整體是否有效地得到運行。 Ø 驗收測試通常由業(yè)務(wù)專家或用戶進(jìn)行，以確認(rèn)軟件產(chǎn)品能真正符合用戶業(yè)務(wù)上的需要。 圖 V模型另外，項目經(jīng)理要按不同階段適時運用人員，恰當(dāng)掌握用人標(biāo)準(zhǔn)。一般來說，軟件項目不同階段不同層次技術(shù)人員的參與情況是不一樣的。下圖是V模型的軟件開發(fā)人員參與情況曲線：6.8.2 優(yōu)缺點² 為測試用例的設(shè)計提供了更廣泛的信息在傳統(tǒng)的軟件生命周期中，測試階段的順序被置于中后期，測試用例的設(shè)計就主要依據(jù)于前期各階段的

32、文檔，而文檔更新的速度遠(yuǎn)遠(yuǎn)不及代碼變化的速度，文檔的信息也有所失真；而V模型就可以克服傳統(tǒng)軟件生命周期在測試方面的缺點，在需求分析與設(shè)計的同時就可以進(jìn)行相應(yīng)層次的測試用例的設(shè)計，有效的保證測試的目標(biāo)和覆蓋率，通過團隊成員間的及時溝通，充分利用了需求人員，設(shè)計人員的力量來指導(dǎo)測試工作，使得測試工作不僅僅是依賴于文檔。² 測試與編碼的混合狀態(tài)如果等到所有的編碼完成再開始單元測試，集中測試發(fā)現(xiàn)的結(jié)果必將讓開發(fā)團隊措手不及；V模型的方法就是：開發(fā)一段，測試一點；發(fā)現(xiàn)缺陷，修復(fù)缺陷；再開發(fā)，再測試。編碼和測試是處于一種反復(fù)輪換的狀態(tài)，可以及時有效地處理測試缺陷。²  階段的并行性在 V模型中，軟件分析與設(shè)計階段在邏輯上分別對應(yīng)于右側(cè)的各個測試