生命周期模型選用指南

1、生命周期模型選用指南版本1.0發(fā)布時間：煙臺海頤軟件股份有限公文件變更記錄*A - 增加 M - 修訂 D - 刪除變更版本號日期變更類型（A*M*D）修改人變更摘要備注1. 目的本文檔統(tǒng)一規(guī)范描述了組織內(nèi)軟件開發(fā)過程中可以使用的各種生命周期模型，供項目策劃時根據(jù)項目的具體情況選用，由此確定軟件項目開發(fā)過程的各種不同的階段以及各階段的執(zhí)行順序，從而加強(qiáng)項目管理，提高過程能力成熟度級別，保證產(chǎn)品質(zhì)量。2. 適用范圍機(jī)構(gòu)：產(chǎn)品部、開發(fā)部、工程部、質(zhì)量部。業(yè)務(wù)：本指南適用于組織內(nèi)的全部軟件項目。3. 名詞術(shù)語軟件生命周期：軟件生命周期，是指從開始策劃軟件產(chǎn)品到軟件不再使用為止這段時間。典型的軟件生命

2、周期包括策劃階段、需求階段、分析與設(shè)計階段、實現(xiàn)階段（構(gòu)造階段）、測試階段、實施和維護(hù)階段。軟件生命周期模型軟件生命周期模型是對軟件工程活動的組織方式。軟件生命周期模型通過確定軟件開發(fā)活動的順序和相互制約關(guān)系來保證軟件工程活動的流程化。4. 軟件生命周期模型4.1 瀑布模型(Waterfall)4.1.1 模型定義該模型首先由Royce1970提出，又稱線性順序模型，或典型生命周期模型，指軟件生命周期的各項活動始終按照固定順序執(zhí)行：需求、設(shè)計、構(gòu)造、集成、測試、維護(hù)，各活動之間有明確的界限，非連續(xù)的，對階段結(jié)束的成果進(jìn)行判斷以確定是否可以開始下一階段的工作，形如瀑布流水，最終得到軟件產(chǎn)品。瀑布

3、模型是所有軟件生命周期模型的基礎(chǔ)。4.1.2 模型圖4.1.3 模型特點1) 優(yōu)點瀑布模型是一種文檔驅(qū)動模型，主要的工作產(chǎn)品通過文檔從一個階段傳遞到下一階段，瀑布模型的每個活動的完成都是以該活動的評審?fù)ㄟ^作為標(biāo)志的。當(dāng)項目有著明確的產(chǎn)品定義以及易于理解的技術(shù)方案的情況下，瀑布模型有助于及早發(fā)現(xiàn)問題，降低階段成本。瀑布模型的主要特點： 簡單、易于理解 要求嚴(yán)格的管理，包括周密的項目計劃、明確的交付物、嚴(yán)格的質(zhì)量控制手段（如階段的評審）等 客戶在項目的后期才可以見到的產(chǎn)品以及判斷產(chǎn)品的質(zhì)量 強(qiáng)調(diào)產(chǎn)品的測試2) 缺點： 缺乏靈活性瀑布模型要求在項目的初期明確定義全部需求，然而客戶在項目初期很難明確描

4、述所有的需求，這種不確定性難以滿足模型要求的“穩(wěn)定的、明確定義的需求”的要求。事實上，在設(shè)計完成和代碼完成之前很難充分描述需求，因為客戶只能在最后階段看到產(chǎn)品，產(chǎn)品是否滿足客戶的真正需求只有此刻才可以得以檢驗。因此是否滿足客戶真正需求的風(fēng)險往往只能在開發(fā)過程后期才顯露，相應(yīng)的修改成本巨大。 很難反映實際的開發(fā)過程實際的開發(fā)過程很難象瀑布模型中所有活動按照既定的順序執(zhí)行的設(shè)想一樣，因為很多活動是重復(fù)進(jìn)行的。 對于要求快速開發(fā)的項目，瀑布模型可能導(dǎo)致過多的文檔 由于是單一流程，開發(fā)中的經(jīng)驗教訓(xùn)不能反饋應(yīng)用于本產(chǎn)品的過程； 用戶的反饋只有到項目后期才看得到。4.1.4 適用場景l(fā) 適合前期需求比較明

5、確,且項目管理能力比較欠缺的的項目；l 適合有穩(wěn)定的產(chǎn)品定義和易于掌握的技術(shù)方案的項目l 適合處理易于理解但復(fù)雜的項目l 適合質(zhì)量需求高于進(jìn)度和成本需求的項目l 適合項目的開發(fā)隊伍的技術(shù)力量比較薄弱或缺乏經(jīng)驗的情況l 適合于小型項目4.2 帶反饋的瀑布模型(Waterfall Model With Feedback)4.2.1 模型定義該模型是在瀑布模型的基礎(chǔ)上，為了改變瀑布模型環(huán)節(jié)間的不可逆向交互的情況，而設(shè)置了反饋環(huán)節(jié)而成。4.2.2 模型圖4.2.3 模型特點帶反饋的瀑布模型在保持原有瀑布模型活動階段自上而下、相互銜接、逐級下落的次序的同時，增加了反饋環(huán)節(jié)，當(dāng)某階段發(fā)現(xiàn)上游缺陷時可通過追

6、溯予以消除或改進(jìn)。4.2.4 使用場景l(fā) 適用于需求比較明確，各環(huán)節(jié)間反饋更新信息較少的項目。針對煙臺海頤軟件股份有限公司而言，本模型適合于小型的、推廣性質(zhì)的網(wǎng)站、縣級客服、營銷管理系統(tǒng)等項目。4.3 V型模型(V-shaped Model)4.3.1 模型定義V 形模型也是連續(xù)開發(fā)模型的一種，有時也被成為快速應(yīng)用開發(fā)模型(RAD)，類似于瀑布模型。區(qū)別在于每個開發(fā)階段有一個測試階段與之匹配：需求同系統(tǒng)測試，架構(gòu)設(shè)計同集成測試，子系統(tǒng)設(shè)計同單元測試。V 模型是瀑布模型的改進(jìn)。4.3.2 模型圖4.3.3 模型特點1) 優(yōu)點l 應(yīng)用和管理簡單：為開發(fā)階段定義的進(jìn)入準(zhǔn)則和出口準(zhǔn)則可以清楚的定義，對

7、項目進(jìn)行有效管理的相關(guān)評判尺度也可以清楚的定義。同時，由于軟件開發(fā)過程的任何一個時間點，相應(yīng)的文檔和代碼等都只有一個基線，所以對于配置管理也是一件比較輕松的事情。l 強(qiáng)調(diào)測試階段/過程與開發(fā)過程的對應(yīng)關(guān)系：從模型中也可以看出，軟件測試是V 模型的重點。在V 模型生命周期模型中，軟件測試的活動是和開發(fā)的每個階段活動對應(yīng)的。l 可以不考慮過程的反復(fù)l 不必隨時列出管理和支持過程2) 缺點：l V 模型在處理風(fēng)險方面存在不足：假如存在風(fēng)險或者軟件需求方面的大的變更，我們回頭去修改前面階段的框架、設(shè)計、代碼或測試文檔和測試用例等，將需要極大的成本，同時難度也較大。l 軟件產(chǎn)品在開發(fā)過程中對用戶是不可見

8、的：在開發(fā)階段中，用戶沒有直觀的工作產(chǎn)品可以體驗，只能是在產(chǎn)品交付之后才能使用。這導(dǎo)致用戶在開發(fā)過程中參與的力度不足。4.3.4 適用場景 需求是穩(wěn)定可靠的 軟件實現(xiàn)方法是成熟的 軟件結(jié)構(gòu)清晰，模塊間的界限明晰結(jié)合本組織實際情況，本模型可以被中小規(guī)模的系統(tǒng)改造項目所采用。4.4 原型法模型(Prototype Model)4.4.1 模型定義原型模型的基本指導(dǎo)思想是在需求階段開始前或過程中，通過部分實現(xiàn)系統(tǒng)功能的方式，進(jìn)行快速開發(fā)，建立軟件中對用戶可見的部分，即所謂的原型。然后基于這個原型，同客戶進(jìn)行溝通、交流，更好的了解客戶需求，同時也使開發(fā)組對該軟件有更好的理解，過程中進(jìn)行迭代，不斷修改這

9、個原型，到了雙方都認(rèn)可的程度，再做詳細(xì)的分析、設(shè)計和編碼、測試等，最終開發(fā)出客戶滿意的軟件產(chǎn)品。4.4.2 模型圖4.4.3 模型特點1) 優(yōu)點l 直觀的表示：在需求定義之前可快速構(gòu)建系統(tǒng)，構(gòu)建部分系統(tǒng)實現(xiàn)的原型，構(gòu)建的系統(tǒng)需求原型可以給予客戶一個直觀的認(rèn)識。l 用戶反饋：客戶直接對系統(tǒng)原型提供反饋，開發(fā)可以根據(jù)客戶對原型提供的反饋，確認(rèn)系統(tǒng)存在的問題以及系統(tǒng)實現(xiàn)的優(yōu)點。可以作為系統(tǒng)開發(fā)人員進(jìn)行系統(tǒng)需求規(guī)格的修改，以滿足客戶實際的需要。2) 缺點：l 開發(fā)人員和客戶對系統(tǒng)需求的了解都不是很深入，存在許多不確定的因素，仍有許多不能關(guān)閉的問題。l 原型可能沒有包含產(chǎn)品應(yīng)該包含的各個方面。l 原型可

10、能使用了在實際環(huán)境中無法使用的資源比如操作系統(tǒng)。l 原型可能無法處理在滿負(fù)荷情況下的運行。l 當(dāng)需求不清楚時可能導(dǎo)致拋棄已開發(fā)出的原型，造成原型不能利用，從而導(dǎo)致成本的增加。4.4.4 適用場景l(fā) 用戶技術(shù)素養(yǎng)較差，不能清晰的描述其意圖，對未來軟件的功能和期望不明確，造成項目不明確因素太多；l 用戶的具體功能需求不明確；l 用戶定義了軟件的一般性目標(biāo)，但不能標(biāo)識出詳細(xì)的輸入、處理和輸出需求l 分析設(shè)計人員對應(yīng)用領(lǐng)域不熟悉；l 開發(fā)者不能確定算法的有效性、操作系統(tǒng)的適應(yīng)性或人機(jī)交互的形式；l 新的產(chǎn)品領(lǐng)域，或者項目包含一種新技術(shù)，例：新硬件、新的開發(fā)語言、新的系統(tǒng)架構(gòu)等；l 高風(fēng)險項目;結(jié)合本組

11、織的情況，本模型可以適用于新產(chǎn)品開發(fā)、WEB網(wǎng)站建設(shè)等。4.5 螺旋模型 (Spiral)4.5.1 模型定義螺旋模型結(jié)合了瀑布模型的系統(tǒng)化特點和原型法模型的迭代的特征，并加入兩者所忽略的風(fēng)險分析所建立的一種軟件開發(fā)模型。該模型于1998 年由美國TRW 公司（B.W.Boehm）提出。螺旋模型是一種風(fēng)險驅(qū)動的模型。軟件項目風(fēng)險的大小作為指引軟件過程的一個重要因素。采用螺旋模型的開發(fā)過程，交付的軟件系統(tǒng)是通過一系列增量版本的發(fā)布組成，早期的增量版本可能是一個紙面上的模型或是一個原型，而最后的增量版本是日漸完善的軟件系統(tǒng)。4.5.2 模型圖4.5.3 模型特點1) 優(yōu)點l 包含瀑布模型和原型模型

12、l 將階段分成更細(xì)小的塊l 允許設(shè)計的變化l 受風(fēng)險分析的驅(qū)動，可降低開發(fā)風(fēng)險l 用戶可較早看到產(chǎn)品l 用戶與產(chǎn)品開發(fā)緊密相連l 經(jīng)費不必預(yù)先分配l 需應(yīng)用保護(hù)性活動（軟件配置管理和軟件質(zhì)量保證）2) 缺點l 模型比較復(fù)雜，對項目團(tuán)隊的管理能力，特別是風(fēng)險的管理能力要求較高，同時需要人員，資金，和時間的投入。4.5.4 適用場景l(fā) 風(fēng)險是項目中最主要的限制因素l 客戶無法提出明確的需求l 可能發(fā)生重大變更的項目l 項目規(guī)模和資金投入較大的項目l 新技術(shù)的引入，缺乏相關(guān)經(jīng)驗l 開發(fā)團(tuán)隊要求具備管理經(jīng)驗特別是風(fēng)險管理經(jīng)驗和技能4.6 增量模型4.6.1 模型定義增量模型，是具備迭代特征的瀑布模型。

13、采用該模型，每一個增量的開發(fā)過程都采用瀑布模型，產(chǎn)生的結(jié)果是新增部分功能或性能。當(dāng)使用增量模型時，第一個增量往往是核心產(chǎn)品，即實現(xiàn)了基本的需求；核心產(chǎn)品交用戶使用（或進(jìn)行更詳細(xì)的復(fù)審），使用和/或評估的結(jié)果是下一個增量的開發(fā)計劃，計劃中明確了對下一增量版本內(nèi)容的修改和新增待開發(fā)的功能，如此迭代，直至系統(tǒng)整體實現(xiàn)。增量模型和原型模型的不同之處是其強(qiáng)調(diào)每一個增量均要發(fā)布一個可操作產(chǎn)品。4.6.2 模型圖4.6.3 模型特點1) 優(yōu)點l 可快速生產(chǎn)出可使用的系統(tǒng)l 在達(dá)到初始需求之前可降低成本l 客戶可將早期的增量作為系統(tǒng)的原型，從中獲得對后面系統(tǒng)增量的需求經(jīng)驗l 可以減少開發(fā)過程中的返工l 項目總

14、體性失敗的風(fēng)險比較低。雖然可能在一些增量中存在問題，但其他的增量會成功交付。l 能夠有計劃地管理技術(shù)風(fēng)險2) 缺點l 由于增量模型的靈活性，如果沒有完善的配置管理，容易造成邊開發(fā)邊修改，喪失軟件的整體性。l 由于在增量實現(xiàn)前，需求不能被詳細(xì)定義，對確定系統(tǒng)的架構(gòu)及所有增量都用到的公共服務(wù)有一定的影響。l 需要科學(xué)合理的進(jìn)行控制增量規(guī)模和配置管理。過大的增量劃分、雜亂的基線管理等都將增加項目的風(fēng)險。4.6.4 適用場景l(fā) 項目工期較緊且客戶接受分階段交付的項目;l 分析設(shè)計人員對應(yīng)用領(lǐng)域不熟悉或難以全面把握的項目;l 已有系統(tǒng)技術(shù)路線發(fā)生改變但需求明確的移植類項目。l 各種中、大規(guī)模的項目類型；

15、 結(jié)合本組織的情況，本模型可以適用于工期非常緊的項目以及新產(chǎn)品開發(fā)。4.7 RUP的迭代模型4.7.1 模型定義迭代生命周期模型并不是在開始的時候就將軟件的所有需求開發(fā)出來。相反的，從實現(xiàn)軟件的某個部分開始，通過對這個部分進(jìn)行評審來明確更進(jìn)一步的需要開發(fā)的需求。重復(fù)這個過程，在模型的每個周期都生成一個新的軟件版本。迭代式模型是RUP推薦的周期模型。在RUP中，迭代被定義為：迭代包括產(chǎn)生產(chǎn)品發(fā)布的全部開發(fā)活動和必需的所有其他外圍元素。RUP中的軟件生命周期在時間上被分解為四個順序的階段，分別是：初始階段(Inception)、細(xì)化階段(Elaboration)、構(gòu)造階段(Construction

16、)和交付階段(Transition)。RUP認(rèn)為，RUP中的每個階段可以進(jìn)一步分解為迭代。一個迭代是一個完整的開發(fā)循環(huán)，產(chǎn)生一個可執(zhí)行的產(chǎn)品版本，是最終產(chǎn)品的一個子集，它增量式地發(fā)展，從一個迭代過程到另一個迭代過程到成為最終的系統(tǒng)每一次的迭代都會產(chǎn)生一個可以發(fā)布的產(chǎn)品。RUP用二維坐標(biāo)來描述。橫軸通過時間組織，是過程展開的生命周期特征，體現(xiàn)開發(fā)過程的動態(tài)結(jié)構(gòu)，用來描述它的術(shù)語主要包括周期(Cycle)、階段(Phase)、迭代(Iteration)和里程碑(Milestone)；縱軸以內(nèi)容來組織為自然的邏輯活動，體現(xiàn)開發(fā)過程的靜態(tài)結(jié)構(gòu)，用來描述它的術(shù)語主要包括活動(Activity)、產(chǎn)物(A

17、rtifact)、工作者(Worker)和工作流(Workflow)。4.7.2 模型圖4.7.3 模型特點1) 優(yōu)點l 降低了在一個增量上的開支風(fēng)險。如果開發(fā)人員重復(fù)某個迭代，那么損失只是這一個開發(fā)有誤的迭代的花費。l 降低了產(chǎn)品無法按照既定進(jìn)度進(jìn)入市場的風(fēng)險。通過在開發(fā)早期就確定風(fēng)險，可以盡早來解決而不至于在開發(fā)后期匆匆忙忙。 l 加快了整個開發(fā)工作的進(jìn)度。因為開發(fā)人員清楚問題的焦點所在，他們的工作會更有效率。l 由于用戶的需求并不能在一開始就做出完全的界定，它們通常是在后續(xù)階段中不斷細(xì)化的。因此，迭代過程這種模式使適應(yīng)需求的變化會更容易些。l 迭代和瀑布的最大的差別就在于風(fēng)險的暴露時間上

18、。二者的區(qū)別如下圖所示： 2) 缺點需要完備的項目管理過程支持，例如配置管理等。4.7.4 適用場景l(fā) 較復(fù)雜的應(yīng)用項目l 大型應(yīng)用項目(10人以上)l 高風(fēng)險的項目5. 選用軟件生命周期模型的策略選擇項目軟件的生命周期模型，一般來說包括如下步驟：步驟一：明確項目特點步驟二：根據(jù)項目特點分析識別項目風(fēng)險和需求的清晰性步驟三：根據(jù)項目目標(biāo)和風(fēng)險、需求不確定性分析結(jié)果確定軟件生命周期策略步驟四：根據(jù)軟件生命周期策略選擇并剪裁軟件生命周期模型步驟五：評審選定的軟件生命周期模型5.1 分析項目的特點軟件生命周期模型的選擇首先要考慮項目的特點，包括： 項目借鑒資源(如是否有類似項目、類似產(chǎn)品的實施經(jīng)驗)

19、 資源的可用性（包括人、資金、設(shè)施、工具） 項目復(fù)雜度（如子系統(tǒng)數(shù)量） 項目的難度(如新技術(shù)的采用、新領(lǐng)域產(chǎn)品等) 開發(fā)成本（包括人力、物力、資金等） 項目進(jìn)度壓力 需求的不確定性和穩(wěn)定性（需求是否明確、是否逐漸變更、性能要求） 項目版本要求（是否以后升級、是否逐漸變更、版本重用性要求） 項目風(fēng)險分析5.2 分析項目風(fēng)險和需求的不確定性根據(jù)項目特點分析項目的風(fēng)險和需求的不確定性，不同的生命周期模型在解決風(fēng)險和不確定性方面的能力是不同的，例如螺旋模型是一種以風(fēng)險為導(dǎo)向的模型，確保隨著項目成本投入的增加，風(fēng)險程度降低；而瀑布模型對風(fēng)險的應(yīng)對能力相對較弱，采用瀑布模型的項目中可能遺留關(guān)鍵的項目風(fēng)險在

20、項目后期才能暴露出來，而這種風(fēng)險的發(fā)生帶來的損失比項目前期引起的損失大的多。當(dāng)然，風(fēng)險和不確定性的管理需要投入項目資源，并對項目團(tuán)隊提出了相應(yīng)的要求，如風(fēng)險管理的能力和技能的要求、項目計劃和跟蹤與監(jiān)督的要求等，所以風(fēng)險和需求不確定性大小是選擇軟件生命周期模型的重要因素，卻不是絕對的。5.3 生命周期模型選擇矩陣根據(jù)如下矩陣來評估項目，確定要選用的生命周期模型。標(biāo)準(zhǔn)V形模型瀑布模型原型模型增量模型螺旋模型迭代模型資源可用性低高有一些有一些有一些中項目復(fù)雜度低低中高高高項目成本低低低中高高以后的升級成本高高低低低低不連續(xù)的需求變更大大小小小小易使用性簡單簡單簡單復(fù)雜復(fù)雜復(fù)雜應(yīng)用功能需求明確明確不明

21、確不明確不明確不明確漸進(jìn)式的需求變更小小小大大大項目壽命短長長長產(chǎn)品技術(shù)存在存在新新新新生產(chǎn)率高高低高高高產(chǎn)品和交付的階段工作產(chǎn)品的重用性低低低高高高需求的不確定性否否是是是是未知需求否否是是是是5.4 合并生命周期模型一個項目在不同的階段可根據(jù)需要合并生命周期模型。例如：在項目需求階段使用原型模型；在設(shè)計和編碼階段使用V 形模型；在測試活動中使用瀑布模型；在運行和維護(hù)時使用迭代模型。6. 附錄 RUP介紹軟件過程是指實施于軟件開發(fā)和維護(hù)中的階段、方法、技術(shù)、實踐及相關(guān)產(chǎn)物(計劃、文檔、模型、代碼、測試用例和手冊等)的集合。行之有效的軟件過程可以提高開發(fā)軟件組織的生產(chǎn)效率、提高軟件質(zhì)量、降低成

22、本并減少風(fēng)險。目前市場上領(lǐng)先的軟件過程主要有RUP(Rational Unified Process)、OPEN Process和OOSP(Object-Oriented Software Process)。 RUP的提出者Rational軟件公司聚集了面向?qū)ο箢I(lǐng)域三位杰出專家Booch、Rumbaugh和Jacobson，同時它又是面向?qū)ο箝_發(fā)的行業(yè)標(biāo)準(zhǔn)語言標(biāo)準(zhǔn)建模語言(UML)的創(chuàng)立者。RUP是由Objectory過程演化而來，其初始版本為5.0，先后經(jīng)歷了5.1、5.11、5.5、 Rational Unified Process2000等版本。6.1 RUP的二維開發(fā)模型 RUP可以用

23、二維坐標(biāo)來描述。橫軸通過時間組織，是過程展開的生命周期特征，體現(xiàn)開發(fā)過程的動態(tài)結(jié)構(gòu)，用來描述它的術(shù)語主要包括周期(Cycle)、階段(Phase)、迭代(Iteration)和里程碑(Milestone)；縱軸以內(nèi)容來組織為自然的邏輯活動，體現(xiàn)開發(fā)過程的靜態(tài)結(jié)構(gòu)，用來描述它的術(shù)語主要包括活動(Activity)、產(chǎn)物(Artifact)、工作者(Worker)和工作流(Workflow)。如圖: 6.2 開發(fā)過程中的各個階段和里程碑RUP中的軟件生命周期在時間上被分解為四個順序的階段，分別是：初始階段(Inception)、細(xì)化階段(Elaboration)、構(gòu)造階段(Construction

24、)和交付階段(Transition)。每個階段結(jié)束于一個主要的里程碑(Major Milestones)；每個階段本質(zhì)上是兩個里程碑之間的時間跨度。在每個階段的結(jié)尾執(zhí)行一次評估以確定這個階段的目標(biāo)是否已經(jīng)滿足。如果評估結(jié)果令人滿意的話，可以允許項目進(jìn)入下一個階段。 6.2.1 初始階段初始階段的目標(biāo)是為系統(tǒng)建立商業(yè)案例并確定項目的邊界。為了達(dá)到該目的必須識別所有與系統(tǒng)交互的外部實體，在較高層次上定義交互的特性。本階段具有非常重要的意義，在這個階段中所關(guān)注的是整個項目進(jìn)行中的業(yè)務(wù)和需求方面的主要風(fēng)險。對于建立在原有系統(tǒng)基礎(chǔ)上的開發(fā)項目來講，初始階段可能很短。 初始階段結(jié)束時是第一個重要的里程碑：

25、生命周期目標(biāo)(Lifecycle Objective)里程碑。生命周期目標(biāo)里程碑評價項目基本的生存能力。6.2.2 細(xì)化階段 細(xì)化階段的目標(biāo)是分析問題領(lǐng)域，建立健全的體系結(jié)構(gòu)基礎(chǔ)，編制項目計劃，淘汰項目中最高風(fēng)險的元素。為了達(dá)到該目的，必須在理解整個系統(tǒng)的基礎(chǔ)上，對體系結(jié)構(gòu)作出決策，包括其范圍、主要功能和諸如性能等非功能需求。同時為項目建立支持環(huán)境，包括創(chuàng)建開發(fā)案例，創(chuàng)建模板、準(zhǔn)則并準(zhǔn)備工具。 細(xì)化階段結(jié)束時第二個重要的里程碑：生命周期結(jié)構(gòu)(Lifecycle Architecture)里程碑。生命周期結(jié)構(gòu)里程碑為系統(tǒng)的結(jié)構(gòu)建立了管理基準(zhǔn)并使項目小組能夠在構(gòu)建階段中進(jìn)行衡量。此刻，要檢驗詳細(xì)的

26、系統(tǒng)目標(biāo)和范圍、結(jié)構(gòu)的選擇以及主要風(fēng)險的解決方案。6.2.3 構(gòu)造階段 在構(gòu)建階段，所有剩余的構(gòu)件和應(yīng)用程序功能被開發(fā)并集成為產(chǎn)品，所有的功能被詳細(xì)測試。從某種意義上說，構(gòu)建階段是一個制造過程，其重點放在管理資源及控制運作以優(yōu)化成本、進(jìn)度和質(zhì)量。 構(gòu)建階段結(jié)束時是第三個重要的里程碑：初始功能(Initial Operational)里程碑。初始功能里程碑決定了產(chǎn)品是否可以在測試環(huán)境中進(jìn)行部署。此刻，要確定軟件、環(huán)境、用戶是否可以開始系統(tǒng)的運作。此時的產(chǎn)品版本也常被稱為“beta”版。6.2.4 交付階段 交付階段的重點是確保軟件對最終用戶是可用的。交付階段可以跨越幾次迭代，包括為發(fā)布做準(zhǔn)備的產(chǎn)

27、品測試，基于用戶反饋的少量的調(diào)整。在生命周期的這一點上，用戶反饋應(yīng)主要集中在產(chǎn)品調(diào)整，設(shè)置、安裝和可用性問題，所有主要的結(jié)構(gòu)問題應(yīng)該已經(jīng)在項目生命周期的早期階段解決了。 在交付階段的終點是第四個里程碑：產(chǎn)品發(fā)布(Product Release)里程碑。此時，要確定目標(biāo)是否實現(xiàn)，是否應(yīng)該開始另一個開發(fā)周期。在一些情況下這個里程碑可能與下一個周期的初始階段的結(jié)束重合。6.3 RUP的核心工作流(Core Workflows) RUP中有9個核心工作流，分為6個核心過程工作流(Core Process Workflows)和3個核心支持工作流(Core Supporting Workflows)。盡

28、管6個核心過程工作流可能使人想起傳統(tǒng)瀑布模型中的幾個階段，但應(yīng)注意迭代過程中的階段是完全不同的，這些工作流在整個生命周期中一次又一次被訪問。9個核心工作流在項目中輪流被使用，在每一次迭代中以不同的重點和強(qiáng)度重復(fù)。6.3.1 商業(yè)建模(Business Modeling) 商業(yè)建模工作流描述了如何為新的目標(biāo)組織開發(fā)一個構(gòu)想，并基于這個構(gòu)想在商業(yè)用例模型和商業(yè)對象模型中定義組織的過程，角色和責(zé)任。 6.3.2 需求(Requirements)需求工作流的目標(biāo)是描述系統(tǒng)應(yīng)該做什么，并使開發(fā)人員和用戶就這一描述達(dá)成共識。為了達(dá)到該目標(biāo)，要對需要的功能和約束進(jìn)行提取、組織、文檔化；最重要的是理解系統(tǒng)所解

29、決問題的定義和范圍。6.3.3 分析和設(shè)計(Analysis & Design) 分析和設(shè)計工作流將需求轉(zhuǎn)化成未來系統(tǒng)的設(shè)計，為系統(tǒng)開發(fā)一個健壯的結(jié)構(gòu)并調(diào)整設(shè)計使其與實現(xiàn)環(huán)境相匹配，優(yōu)化其性能。分析設(shè)計的結(jié)果是一個設(shè)計模型和一個可選的分析模型。設(shè)計模型是源代碼的抽象，由設(shè)計類和一些描述組成。設(shè)計類被組織成具有良好接口的設(shè)計包(Package)和設(shè)計子系統(tǒng)(Subsystem)，而描述則體現(xiàn)了類的對象如何協(xié)同工作實現(xiàn)用例的功能。 設(shè)計活動以體系結(jié)構(gòu)設(shè)計為中心，體系結(jié)構(gòu)由若干結(jié)構(gòu)視圖來表達(dá)，結(jié)構(gòu)視圖是整個設(shè)計的抽象和簡化，該視圖中省略了一些細(xì)節(jié)，使重要的特點體現(xiàn)得更加清晰。體系結(jié)構(gòu)不僅僅是良好設(shè)計

30、模型的承載媒介，而且在系統(tǒng)的開發(fā)中能提高被創(chuàng)建模型的質(zhì)量。 6.3.4 實現(xiàn)(Implementation)實現(xiàn)工作流的目的包括以層次化的子系統(tǒng)形式定義代碼的組織結(jié)構(gòu)；以組件的形式(源文件、二進(jìn)制文件、可執(zhí)行文件)實現(xiàn)類和對象；將開發(fā)出的組件作為單元進(jìn)行測試以及集成由單個開發(fā)者（或小組）所產(chǎn)生的結(jié)果，使其成為可執(zhí)行的系統(tǒng)。 6.3.5 測試(Test) 測試工作流要驗證對象間的交互作用，驗證軟件中所有組件的正確集成，檢驗所有的需求已被正確的實現(xiàn), 識別并確認(rèn)缺陷在軟件部署之前被提出并處理。RUP提出了迭代的方法，意味著在整個項目中進(jìn)行測試，從而盡可能早地發(fā)現(xiàn)缺陷，從根本上降低了修改缺陷的成本。

31、測試類似于三維模型，分別從可靠性、功能性和系統(tǒng)性能來進(jìn)行。6.3.6 部署(Deployment) 部署工作流的目的是成功的生成版本并將軟件分發(fā)給最終用戶。部署工作流描述了那些與確保軟件產(chǎn)品對最終用戶具有可用性相關(guān)的活動，包括：軟件打包、生成軟件本身以外的產(chǎn)品、安裝軟件、為用戶提供幫助。在有些情況下，還可能包括計劃和進(jìn)行beta測試版、移植現(xiàn)有的軟件和數(shù)據(jù)以及正式驗收。6.3.7 配置和變更管理(Configuration & Change Management) 配置和變更管理工作流描繪了如何在多個成員組成的項目中控制大量的產(chǎn)物。配置和變更管理工作流提供了準(zhǔn)則來管理演化系統(tǒng)中的多個變體，跟蹤軟件創(chuàng)建過程中的版本。工作流描述了如何管理并行開發(fā)、分布式開發(fā)、如何自動化創(chuàng)建工程。同時也闡述了對產(chǎn)品修改原因、時間、人員保持審計記錄。6.3.8 項目管理(Project Management) 軟件項目管理平衡