生命周期模型選用指南

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

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

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

4、 缺乏靈活性瀑布模型要求在項(xiàng)目的初期明確定義全部需求，然而客戶在項(xiàng)目初期很難明確描述所有的需求，這種不確定性難以滿足模型要求的“穩(wěn)定的、明確定義的需求”的要求。事實(shí)上，在設(shè)計(jì)完成和代碼完成之前很難充分描述需求，因?yàn)榭蛻糁荒茉谧詈箅A段看到產(chǎn)品，產(chǎn)品是否滿足客戶的真正需求只有此刻才可以得以檢驗(yàn)。因此是否滿足客戶真正需求的風(fēng)險(xiǎn)往往只能在開發(fā)過(guò)程后期才顯露，相應(yīng)的修改成本巨大。· 很難反映實(shí)際的開發(fā)過(guò)程實(shí)際的開發(fā)過(guò)程很難象瀑布模型中所有活動(dòng)按照既定的順序執(zhí)行的設(shè)想一樣，因?yàn)楹芏嗷顒?dòng)是重復(fù)進(jìn)行的。· 對(duì)于要求快速開發(fā)的項(xiàng)目，瀑布模型可能導(dǎo)致過(guò)多的文檔· 由于是單一流程，開發(fā)

5、中的經(jīng)驗(yàn)教訓(xùn)不能反饋應(yīng)用于本產(chǎn)品的過(guò)程；· 用戶的反饋只有到項(xiàng)目后期才看得到。4.1.4 適用場(chǎng)景l(fā) 適合前期需求比較明確,且項(xiàng)目管理能力比較欠缺的的項(xiàng)目；l 適合有穩(wěn)定的產(chǎn)品定義和易于掌握的技術(shù)方案的項(xiàng)目l 適合處理易于理解但復(fù)雜的項(xiàng)目l 適合質(zhì)量需求高于進(jìn)度和成本需求的項(xiàng)目l 適合項(xiàng)目的開發(fā)隊(duì)伍的技術(shù)力量比較薄弱或缺乏經(jīng)驗(yàn)的情況l 適合于小型項(xiàng)目4.2 帶反饋的瀑布模型(Waterfall Model With Feedback)4.2.1 模型定義該模型是在瀑布模型的基礎(chǔ)上，為了改變瀑布模型環(huán)節(jié)間的不可逆向交互的情況，而設(shè)置了反饋環(huán)節(jié)而成。4.2.2 模型圖4.2.3 模型特點(diǎn)

6、帶反饋的瀑布模型在保持原有瀑布模型活動(dòng)階段自上而下、相互銜接、逐級(jí)下落的次序的同時(shí)，增加了反饋環(huán)節(jié)，當(dāng)某階段發(fā)現(xiàn)上游缺陷時(shí)可通過(guò)追溯予以消除或改進(jìn)。4.2.4 使用場(chǎng)景l(fā) 適用于需求比較明確，各環(huán)節(jié)間反饋更新信息較少的項(xiàng)目。針對(duì)煙臺(tái)海頤軟件股份有限公司而言，本模型適合于小型的、推廣性質(zhì)的網(wǎng)站、縣級(jí)客服、營(yíng)銷管理系統(tǒng)等項(xiàng)目。4.3 V型模型(V-shaped Model)4.3.1 模型定義V 形模型也是連續(xù)開發(fā)模型的一種，有時(shí)也被成為快速應(yīng)用開發(fā)模型(RAD)，類似于瀑布模型。區(qū)別在于每個(gè)開發(fā)階段有一個(gè)測(cè)試階段與之匹配：需求同系統(tǒng)測(cè)試，架構(gòu)設(shè)計(jì)同集成測(cè)試，子系統(tǒng)設(shè)計(jì)同單元測(cè)試。V 模型是瀑布模

7、型的改進(jìn)。4.3.2 模型圖4.3.3 模型特點(diǎn)1) 優(yōu)點(diǎn)l 應(yīng)用和管理簡(jiǎn)單：為開發(fā)階段定義的進(jìn)入準(zhǔn)則和出口準(zhǔn)則可以清楚的定義，對(duì)項(xiàng)目進(jìn)行有效管理的相關(guān)評(píng)判尺度也可以清楚的定義。同時(shí)，由于軟件開發(fā)過(guò)程的任何一個(gè)時(shí)間點(diǎn)，相應(yīng)的文檔和代碼等都只有一個(gè)基線，所以對(duì)于配置管理也是一件比較輕松的事情。l 強(qiáng)調(diào)測(cè)試階段/過(guò)程與開發(fā)過(guò)程的對(duì)應(yīng)關(guān)系：從模型中也可以看出，軟件測(cè)試是V 模型的重點(diǎn)。在V 模型生命周期模型中，軟件測(cè)試的活動(dòng)是和開發(fā)的每個(gè)階段活動(dòng)對(duì)應(yīng)的。l 可以不考慮過(guò)程的反復(fù)l 不必隨時(shí)列出管理和支持過(guò)程2) 缺點(diǎn)：l V 模型在處理風(fēng)險(xiǎn)方面存在不足：假如存在風(fēng)險(xiǎn)或者軟件需求方面的大的變更，我們回

8、頭去修改前面階段的框架、設(shè)計(jì)、代碼或測(cè)試文檔和測(cè)試用例等，將需要極大的成本，同時(shí)難度也較大。l 軟件產(chǎn)品在開發(fā)過(guò)程中對(duì)用戶是不可見的：在開發(fā)階段中，用戶沒有直觀的工作產(chǎn)品可以體驗(yàn)，只能是在產(chǎn)品交付之后才能使用。這導(dǎo)致用戶在開發(fā)過(guò)程中參與的力度不足。4.3.4 適用場(chǎng)景􀁺 需求是穩(wěn)定可靠的􀁺 軟件實(shí)現(xiàn)方法是成熟的􀁺 軟件結(jié)構(gòu)清晰，模塊間的界限明晰結(jié)合本組織實(shí)際情況，本模型可以被中小規(guī)模的系統(tǒng)改造項(xiàng)目所采用。4.4 原型法模型(Prototype Model)4.4.1 模型定義原型模型的基本指導(dǎo)思想是在需求階段開始前或過(guò)程中，通過(guò)部分實(shí)現(xiàn)系統(tǒng)

9、功能的方式，進(jìn)行快速開發(fā)，建立軟件中對(duì)用戶可見的部分，即所謂的原型。然后基于這個(gè)原型，同客戶進(jìn)行溝通、交流，更好的了解客戶需求，同時(shí)也使開發(fā)組對(duì)該軟件有更好的理解，過(guò)程中進(jìn)行迭代，不斷修改這個(gè)原型，到了雙方都認(rèn)可的程度，再做詳細(xì)的分析、設(shè)計(jì)和編碼、測(cè)試等，最終開發(fā)出客戶滿意的軟件產(chǎn)品。4.4.2 模型圖4.4.3 模型特點(diǎn)1) 優(yōu)點(diǎn)l 直觀的表示：在需求定義之前可快速構(gòu)建系統(tǒng)，構(gòu)建部分系統(tǒng)實(shí)現(xiàn)的原型，構(gòu)建的系統(tǒng)需求原型可以給予客戶一個(gè)直觀的認(rèn)識(shí)。l 用戶反饋：客戶直接對(duì)系統(tǒng)原型提供反饋，開發(fā)可以根據(jù)客戶對(duì)原型提供的反饋，確認(rèn)系統(tǒng)存在的問(wèn)題以及系統(tǒng)實(shí)現(xiàn)的優(yōu)點(diǎn)?？梢宰鳛橄到y(tǒng)開發(fā)人員進(jìn)行系統(tǒng)需求規(guī)格

10、的修改，以滿足客戶實(shí)際的需要。2) 缺點(diǎn)：l 開發(fā)人員和客戶對(duì)系統(tǒng)需求的了解都不是很深入，存在許多不確定的因素，仍有許多不能關(guān)閉的問(wèn)題。l 原型可能沒有包含產(chǎn)品應(yīng)該包含的各個(gè)方面。l 原型可能使用了在實(shí)際環(huán)境中無(wú)法使用的資源比如操作系統(tǒng)。l 原型可能無(wú)法處理在滿負(fù)荷情況下的運(yùn)行。l 當(dāng)需求不清楚時(shí)可能導(dǎo)致拋棄已開發(fā)出的原型，造成原型不能利用，從而導(dǎo)致成本的增加。4.4.4 適用場(chǎng)景l(fā) 用戶技術(shù)素養(yǎng)較差，不能清晰的描述其意圖，對(duì)未來(lái)軟件的功能和期望不明確，造成項(xiàng)目不明確因素太多；l 用戶的具體功能需求不明確；l 用戶定義了軟件的一般性目標(biāo)，但不能標(biāo)識(shí)出詳細(xì)的輸入、處理和輸出需求l 分析設(shè)計(jì)人員對(duì)

11、應(yīng)用領(lǐng)域不熟悉；l 開發(fā)者不能確定算法的有效性、操作系統(tǒng)的適應(yīng)性或人機(jī)交互的形式；l 新的產(chǎn)品領(lǐng)域，或者項(xiàng)目包含一種新技術(shù)，例：新硬件、新的開發(fā)語(yǔ)言、新的系統(tǒng)架構(gòu)等；l 高風(fēng)險(xiǎn)項(xiàng)目;結(jié)合本組織的情況，本模型可以適用于新產(chǎn)品開發(fā)、WEB網(wǎng)站建設(shè)等。4.5 螺旋模型 (Spiral)4.5.1 模型定義螺旋模型結(jié)合了瀑布模型的系統(tǒng)化特點(diǎn)和原型法模型的迭代的特征，并加入兩者所忽略的風(fēng)險(xiǎn)分析所建立的一種軟件開發(fā)模型。該模型于1998 年由美國(guó)TRW 公司（B.W.Boehm）提出。螺旋模型是一種風(fēng)險(xiǎn)驅(qū)動(dòng)的模型。軟件項(xiàng)目風(fēng)險(xiǎn)的大小作為指引軟件過(guò)程的一個(gè)重要因素。采用螺旋模型的開發(fā)過(guò)程，交付的軟件系統(tǒng)是通

12、過(guò)一系列增量版本的發(fā)布組成，早期的增量版本可能是一個(gè)紙面上的模型或是一個(gè)原型，而最后的增量版本是日漸完善的軟件系統(tǒng)。4.5.2 模型圖4.5.3 模型特點(diǎn)1) 優(yōu)點(diǎn)l 包含瀑布模型和原型模型l 將階段分成更細(xì)小的塊l 允許設(shè)計(jì)的變化l 受風(fēng)險(xiǎn)分析的驅(qū)動(dòng)，可降低開發(fā)風(fēng)險(xiǎn)l 用戶可較早看到產(chǎn)品l 用戶與產(chǎn)品開發(fā)緊密相連l 經(jīng)費(fèi)不必預(yù)先分配l 需應(yīng)用保護(hù)性活動(dòng)（軟件配置管理和軟件質(zhì)量保證）2) 缺點(diǎn)l 模型比較復(fù)雜，對(duì)項(xiàng)目團(tuán)隊(duì)的管理能力，特別是風(fēng)險(xiǎn)的管理能力要求較高，同時(shí)需要人員，資金，和時(shí)間的投入。4.5.4 適用場(chǎng)景l(fā) 風(fēng)險(xiǎn)是項(xiàng)目中最主要的限制因素l 客戶無(wú)法提出明確的需求l 可能發(fā)生重大變更的

13、項(xiàng)目l 項(xiàng)目規(guī)模和資金投入較大的項(xiàng)目l 新技術(shù)的引入，缺乏相關(guān)經(jīng)驗(yàn)l 開發(fā)團(tuán)隊(duì)要求具備管理經(jīng)驗(yàn)特別是風(fēng)險(xiǎn)管理經(jīng)驗(yàn)和技能4.6 增量模型4.6.1 模型定義增量模型，是具備迭代特征的瀑布模型。采用該模型，每一個(gè)增量的開發(fā)過(guò)程都采用瀑布模型，產(chǎn)生的結(jié)果是新增部分功能或性能。當(dāng)使用增量模型時(shí)，第一個(gè)增量往往是核心產(chǎn)品，即實(shí)現(xiàn)了基本的需求；核心產(chǎn)品交用戶使用（或進(jìn)行更詳細(xì)的復(fù)審），使用和/或評(píng)估的結(jié)果是下一個(gè)增量的開發(fā)計(jì)劃，計(jì)劃中明確了對(duì)下一增量版本內(nèi)容的修改和新增待開發(fā)的功能，如此迭代，直至系統(tǒng)整體實(shí)現(xiàn)。增量模型和原型模型的不同之處是其強(qiáng)調(diào)每一個(gè)增量均要發(fā)布一個(gè)可操作產(chǎn)品。4.6.2 模型圖4.6.

14、3 模型特點(diǎn)1) 優(yōu)點(diǎn)l 可快速生產(chǎn)出可使用的系統(tǒng)l 在達(dá)到初始需求之前可降低成本l 客戶可將早期的增量作為系統(tǒng)的原型，從中獲得對(duì)后面系統(tǒng)增量的需求經(jīng)驗(yàn)l 可以減少開發(fā)過(guò)程中的返工l 項(xiàng)目總體性失敗的風(fēng)險(xiǎn)比較低。雖然可能在一些增量中存在問(wèn)題，但其他的增量會(huì)成功交付。l 能夠有計(jì)劃地管理技術(shù)風(fēng)險(xiǎn)2) 缺點(diǎn)l 由于增量模型的靈活性，如果沒有完善的配置管理，容易造成邊開發(fā)邊修改，喪失軟件的整體性。l 由于在增量實(shí)現(xiàn)前，需求不能被詳細(xì)定義，對(duì)確定系統(tǒng)的架構(gòu)及所有增量都用到的公共服務(wù)有一定的影響。l 需要科學(xué)合理的進(jìn)行控制增量規(guī)模和配置管理。過(guò)大的增量劃分、雜亂的基線管理等都將增加項(xiàng)目的風(fēng)險(xiǎn)。4.6.4

15、 適用場(chǎng)景l(fā) 項(xiàng)目工期較緊且客戶接受分階段交付的項(xiàng)目;l 分析設(shè)計(jì)人員對(duì)應(yīng)用領(lǐng)域不熟悉或難以全面把握的項(xiàng)目;l 已有系統(tǒng)技術(shù)路線發(fā)生改變但需求明確的移植類項(xiàng)目。l 各種中、大規(guī)模的項(xiàng)目類型； 結(jié)合本組織的情況，本模型可以適用于工期非常緊的項(xiàng)目以及新產(chǎn)品開發(fā)。4.7 RUP的迭代模型4.7.1 模型定義迭代生命周期模型并不是在開始的時(shí)候就將軟件的所有需求開發(fā)出來(lái)。相反的，從實(shí)現(xiàn)軟件的某個(gè)部分開始，通過(guò)對(duì)這個(gè)部分進(jìn)行評(píng)審來(lái)明確更進(jìn)一步的需要開發(fā)的需求。重復(fù)這個(gè)過(guò)程，在模型的每個(gè)周期都生成一個(gè)新的軟件版本。迭代式模型是RUP推薦的周期模型。在RUP中，迭代被定義為：迭代包括產(chǎn)生產(chǎn)品發(fā)布的全部開發(fā)活動(dòng)

16、和必需的所有其他外圍元素。RUP中的軟件生命周期在時(shí)間上被分解為四個(gè)順序的階段，分別是：初始階段(Inception)、細(xì)化階段(Elaboration)、構(gòu)造階段(Construction)和交付階段(Transition)。RUP認(rèn)為，RUP中的每個(gè)階段可以進(jìn)一步分解為迭代。一個(gè)迭代是一個(gè)完整的開發(fā)循環(huán)，產(chǎn)生一個(gè)可執(zhí)行的產(chǎn)品版本，是最終產(chǎn)品的一個(gè)子集，它增量式地發(fā)展，從一個(gè)迭代過(guò)程到另一個(gè)迭代過(guò)程到成為最終的系統(tǒng)每一次的迭代都會(huì)產(chǎn)生一個(gè)可以發(fā)布的產(chǎn)品。RUP用二維坐標(biāo)來(lái)描述。橫軸通過(guò)時(shí)間組織，是過(guò)程展開的生命周期特征，體現(xiàn)開發(fā)過(guò)程的動(dòng)態(tài)結(jié)構(gòu)，用來(lái)描述它的術(shù)語(yǔ)主要包括周期(Cycle)、階段

17、(Phase)、迭代(Iteration)和里程碑(Milestone)；縱軸以內(nèi)容來(lái)組織為自然的邏輯活動(dòng)，體現(xiàn)開發(fā)過(guò)程的靜態(tài)結(jié)構(gòu)，用來(lái)描述它的術(shù)語(yǔ)主要包括活動(dòng)(Activity)、產(chǎn)物(Artifact)、工作者(Worker)和工作流(Workflow)。4.7.2 模型圖4.7.3 模型特點(diǎn)1) 優(yōu)點(diǎn)l 降低了在一個(gè)增量上的開支風(fēng)險(xiǎn)。如果開發(fā)人員重復(fù)某個(gè)迭代，那么損失只是這一個(gè)開發(fā)有誤的迭代的花費(fèi)。l 降低了產(chǎn)品無(wú)法按照既定進(jìn)度進(jìn)入市場(chǎng)的風(fēng)險(xiǎn)。通過(guò)在開發(fā)早期就確定風(fēng)險(xiǎn)，可以盡早來(lái)解決而不至于在開發(fā)后期匆匆忙忙。 l 加快了整個(gè)開發(fā)工作的進(jìn)度。因?yàn)殚_發(fā)人員清楚問(wèn)題的焦點(diǎn)所在，他們的工作會(huì)更

18、有效率。l 由于用戶的需求并不能在一開始就做出完全的界定，它們通常是在后續(xù)階段中不斷細(xì)化的。因此，迭代過(guò)程這種模式使適應(yīng)需求的變化會(huì)更容易些。l 迭代和瀑布的最大的差別就在于風(fēng)險(xiǎn)的暴露時(shí)間上。二者的區(qū)別如下圖所示： 2) 缺點(diǎn)需要完備的項(xiàng)目管理過(guò)程支持，例如配置管理等。4.7.4 適用場(chǎng)景l(fā) 較復(fù)雜的應(yīng)用項(xiàng)目l 大型應(yīng)用項(xiàng)目(10人以上)l 高風(fēng)險(xiǎn)的項(xiàng)目5. 選用軟件生命周期模型的策略選擇項(xiàng)目軟件的生命周期模型，一般來(lái)說(shuō)包括如下步驟：步驟一：明確項(xiàng)目特點(diǎn)步驟二：根據(jù)項(xiàng)目特點(diǎn)分析識(shí)別項(xiàng)目風(fēng)險(xiǎn)和需求的清晰性步驟三：根據(jù)項(xiàng)目目標(biāo)和風(fēng)險(xiǎn)、需求不確定性分析結(jié)果確定軟件生命周期策略步驟四：根據(jù)軟件生命周期

19、策略選擇并剪裁軟件生命周期模型步驟五：評(píng)審選定的軟件生命周期模型5.1 分析項(xiàng)目的特點(diǎn)軟件生命周期模型的選擇首先要考慮項(xiàng)目的特點(diǎn)，包括：· 項(xiàng)目借鑒資源(如是否有類似項(xiàng)目、類似產(chǎn)品的實(shí)施經(jīng)驗(yàn))· 資源的可用性（包括人、資金、設(shè)施、工具）· 項(xiàng)目復(fù)雜度（如子系統(tǒng)數(shù)量）· 項(xiàng)目的難度(如新技術(shù)的采用、新領(lǐng)域產(chǎn)品等)· 開發(fā)成本（包括人力、物力、資金等）· 項(xiàng)目進(jìn)度壓力· 需求的不確定性和穩(wěn)定性（需求是否明確、是否逐漸變更、性能要求）· 項(xiàng)目版本要求（是否以后升級(jí)、是否逐漸變更、版本重用性要求）· 項(xiàng)目風(fēng)險(xiǎn)分析

20、5.2 分析項(xiàng)目風(fēng)險(xiǎn)和需求的不確定性根據(jù)項(xiàng)目特點(diǎn)分析項(xiàng)目的風(fēng)險(xiǎn)和需求的不確定性，不同的生命周期模型在解決風(fēng)險(xiǎn)和不確定性方面的能力是不同的，例如螺旋模型是一種以風(fēng)險(xiǎn)為導(dǎo)向的模型，確保隨著項(xiàng)目成本投入的增加，風(fēng)險(xiǎn)程度降低；而瀑布模型對(duì)風(fēng)險(xiǎn)的應(yīng)對(duì)能力相對(duì)較弱，采用瀑布模型的項(xiàng)目中可能遺留關(guān)鍵的項(xiàng)目風(fēng)險(xiǎn)在項(xiàng)目后期才能暴露出來(lái)，而這種風(fēng)險(xiǎn)的發(fā)生帶來(lái)的損失比項(xiàng)目前期引起的損失大的多。當(dāng)然，風(fēng)險(xiǎn)和不確定性的管理需要投入項(xiàng)目資源，并對(duì)項(xiàng)目團(tuán)隊(duì)提出了相應(yīng)的要求，如風(fēng)險(xiǎn)管理的能力和技能的要求、項(xiàng)目計(jì)劃和跟蹤與監(jiān)督的要求等，所以風(fēng)險(xiǎn)和需求不確定性大小是選擇軟件生命周期模型的重要因素，卻不是絕對(duì)的。5.3 生命周期模

21、型選擇矩陣根據(jù)如下矩陣來(lái)評(píng)估項(xiàng)目，確定要選用的生命周期模型。標(biāo)準(zhǔn)V形模型瀑布模型原型模型增量模型螺旋模型迭代模型資源可用性低高有一些有一些有一些中項(xiàng)目復(fù)雜度低低中高高高項(xiàng)目成本低低低中高高以后的升級(jí)成本高高低低低低不連續(xù)的需求變更大大小小小小易使用性簡(jiǎn)單簡(jiǎn)單簡(jiǎn)單復(fù)雜復(fù)雜復(fù)雜應(yīng)用功能需求明確明確不明確不明確不明確不明確漸進(jìn)式的需求變更小小小大大大項(xiàng)目壽命短長(zhǎng)長(zhǎng)長(zhǎng)產(chǎn)品技術(shù)存在存在新新新新生產(chǎn)率高高低高高高產(chǎn)品和交付的階段工作產(chǎn)品的重用性低低低高高高需求的不確定性否否是是是是未知需求否否是是是是5.4 合并生命周期模型一個(gè)項(xiàng)目在不同的階段可根據(jù)需要合并生命周期模型。例如：在項(xiàng)目需求階段使用原型模型；

22、在設(shè)計(jì)和編碼階段使用V 形模型；在測(cè)試活動(dòng)中使用瀑布模型；在運(yùn)行和維護(hù)時(shí)使用迭代模型。6. 附錄 RUP介紹軟件過(guò)程是指實(shí)施于軟件開發(fā)和維護(hù)中的階段、方法、技術(shù)、實(shí)踐及相關(guān)產(chǎn)物(計(jì)劃、文檔、模型、代碼、測(cè)試用例和手冊(cè)等)的集合。行之有效的軟件過(guò)程可以提高開發(fā)軟件組織的生產(chǎn)效率、提高軟件質(zhì)量、降低成本并減少風(fēng)險(xiǎn)。目前市場(chǎng)上領(lǐng)先的軟件過(guò)程主要有RUP(Rational Unified Process)、OPEN Process和OOSP(Object-Oriented Software Process)。 RUP的提出者Rational軟件公司聚集了面向?qū)ο箢I(lǐng)域三位杰出專家Booch、Rumbau

23、gh和Jacobson，同時(shí)它又是面向?qū)ο箝_發(fā)的行業(yè)標(biāo)準(zhǔn)語(yǔ)言標(biāo)準(zhǔn)建模語(yǔ)言(UML)的創(chuàng)立者。RUP是由Objectory過(guò)程演化而來(lái)，其初始版本為5.0，先后經(jīng)歷了5.1、5.11、5.5、 Rational Unified Process2000等版本。6.1 RUP的二維開發(fā)模型 RUP可以用二維坐標(biāo)來(lái)描述。橫軸通過(guò)時(shí)間組織，是過(guò)程展開的生命周期特征，體現(xiàn)開發(fā)過(guò)程的動(dòng)態(tài)結(jié)構(gòu)，用來(lái)描述它的術(shù)語(yǔ)主要包括周期(Cycle)、階段(Phase)、迭代(Iteration)和里程碑(Milestone)；縱軸以內(nèi)容來(lái)組織為自然的邏輯活動(dòng)，體現(xiàn)開發(fā)過(guò)程的靜態(tài)結(jié)構(gòu)，用來(lái)描述它的術(shù)語(yǔ)主要包括活動(dòng)(Acti

24、vity)、產(chǎn)物(Artifact)、工作者(Worker)和工作流(Workflow)。如圖: 6.2 開發(fā)過(guò)程中的各個(gè)階段和里程碑RUP中的軟件生命周期在時(shí)間上被分解為四個(gè)順序的階段，分別是：初始階段(Inception)、細(xì)化階段(Elaboration)、構(gòu)造階段(Construction)和交付階段(Transition)。每個(gè)階段結(jié)束于一個(gè)主要的里程碑(Major Milestones)；每個(gè)階段本質(zhì)上是兩個(gè)里程碑之間的時(shí)間跨度。在每個(gè)階段的結(jié)尾執(zhí)行一次評(píng)估以確定這個(gè)階段的目標(biāo)是否已經(jīng)滿足。如果評(píng)估結(jié)果令人滿意的話，可以允許項(xiàng)目進(jìn)入下一個(gè)階段。 6.2.1 初始階段初始階段的目標(biāo)是

25、為系統(tǒng)建立商業(yè)案例并確定項(xiàng)目的邊界。為了達(dá)到該目的必須識(shí)別所有與系統(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)講，初始階段可能很短。 初始階段結(jié)束時(shí)是第一個(gè)重要的里程碑：生命周期目標(biāo)(Lifecycle Objective)里程碑。生命周期目標(biāo)里程碑評(píng)價(jià)項(xiàng)目基本的生存能力。6.2.2 細(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)作出決策，包括其范圍、主要功

26、能和諸如性能等非功能需求。同時(shí)為項(xiàng)目建立支持環(huán)境，包括創(chuàng)建開發(fā)案例，創(chuàng)建模板、準(zhǔn)則并準(zhǔn)備工具。 細(xì)化階段結(jié)束時(shí)第二個(gè)重要的里程碑：生命周期結(jié)構(gòu)(Lifecycle Architecture)里程碑。生命周期結(jié)構(gòu)里程碑為系統(tǒng)的結(jié)構(gòu)建立了管理基準(zhǔn)并使項(xiàng)目小組能夠在構(gòu)建階段中進(jìn)行衡量。此刻，要檢驗(yàn)詳細(xì)的系統(tǒng)目標(biāo)和范圍、結(jié)構(gòu)的選擇以及主要風(fēng)險(xiǎn)的解決方案。6.2.3 構(gòu)造階段 在構(gòu)建階段，所有剩余的構(gòu)件和應(yīng)用程序功能被開發(fā)并集成為產(chǎn)品，所有的功能被詳細(xì)測(cè)試。從某種意義上說(shuō)，構(gòu)建階段是一個(gè)制造過(guò)程，其重點(diǎn)放在管理資源及控制運(yùn)作以優(yōu)化成本、進(jìn)度和質(zhì)量。 構(gòu)建階段結(jié)束時(shí)是第三個(gè)重要的里程碑：初始功能(Init

27、ial Operational)里程碑。初始功能里程碑決定了產(chǎn)品是否可以在測(cè)試環(huán)境中進(jìn)行部署。此刻，要確定軟件、環(huán)境、用戶是否可以開始系統(tǒng)的運(yùn)作。此時(shí)的產(chǎn)品版本也常被稱為“beta”版。6.2.4 交付階段 交付階段的重點(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)目生命周期的早期階段解決了。 在交付階段的終點(diǎn)是第四個(gè)里程碑：產(chǎn)品發(fā)布(Product Release)里程碑。此時(shí)，要確定目標(biāo)是否實(shí)現(xiàn)，是否應(yīng)該開始另一個(gè)開發(fā)周

28、期。在一些情況下這個(gè)里程碑可能與下一個(gè)周期的初始階段的結(jié)束重合。6.3 RUP的核心工作流(Core Workflows) RUP中有9個(gè)核心工作流，分為6個(gè)核心過(guò)程工作流(Core Process Workflows)和3個(gè)核心支持工作流(Core Supporting Workflows)。盡管6個(gè)核心過(guò)程工作流可能使人想起傳統(tǒng)瀑布模型中的幾個(gè)階段，但應(yīng)注意迭代過(guò)程中的階段是完全不同的，這些工作流在整個(gè)生命周期中一次又一次被訪問(wèn)。9個(gè)核心工作流在項(xiàng)目中輪流被使用，在每一次迭代中以不同的重點(diǎn)和強(qiáng)度重復(fù)。6.3.1 商業(yè)建模(Business Modeling) 商業(yè)建模工作流描述了如何為新的

29、目標(biāo)組織開發(fā)一個(gè)構(gòu)想，并基于這個(gè)構(gòu)想在商業(yè)用例模型和商業(yè)對(duì)象模型中定義組織的過(guò)程，角色和責(zé)任。 6.3.2 需求(Requirements)需求工作流的目標(biāo)是描述系統(tǒng)應(yīng)該做什么，并使開發(fā)人員和用戶就這一描述達(dá)成共識(shí)。為了達(dá)到該目標(biāo)，要對(duì)需要的功能和約束進(jìn)行提取、組織、文檔化；最重要的是理解系統(tǒng)所解決問(wèn)題的定義和范圍。6.3.3 分析和設(shè)計(jì)(Analysis & Design) 分析和設(shè)計(jì)工作流將需求轉(zhuǎn)化成未來(lái)系統(tǒng)的設(shè)計(jì)，為系統(tǒng)開發(fā)一個(gè)健壯的結(jié)構(gòu)并調(diào)整設(shè)計(jì)使其與實(shí)現(xiàn)環(huán)境相匹配，優(yōu)化其性能。分析設(shè)計(jì)的結(jié)果是一個(gè)設(shè)計(jì)模型和一個(gè)可選的分析模型。設(shè)計(jì)模型是源代碼的抽象，由設(shè)計(jì)類和一些描述組成。設(shè)

30、計(jì)類被組織成具有良好接口的設(shè)計(jì)包(Package)和設(shè)計(jì)子系統(tǒng)(Subsystem)，而描述則體現(xiàn)了類的對(duì)象如何協(xié)同工作實(shí)現(xiàn)用例的功能。 設(shè)計(jì)活動(dòng)以體系結(jié)構(gòu)設(shè)計(jì)為中心，體系結(jié)構(gòu)由若干結(jié)構(gòu)視圖來(lái)表達(dá)，結(jié)構(gòu)視圖是整個(gè)設(shè)計(jì)的抽象和簡(jiǎn)化，該視圖中省略了一些細(xì)節(jié)，使重要的特點(diǎn)體現(xiàn)得更加清晰。體系結(jié)構(gòu)不僅僅是良好設(shè)計(jì)模型的承載媒介，而且在系統(tǒng)的開發(fā)中能提高被創(chuàng)建模型的質(zhì)量。 6.3.4 實(shí)現(xiàn)(Implementation)實(shí)現(xiàn)工作流的目的包括以層次化的子系統(tǒng)形式定義代碼的組織結(jié)構(gòu)；以組件的形式(源文件、二進(jìn)制文件、可執(zhí)行文件)實(shí)現(xiàn)類和對(duì)象；將開發(fā)出的組件作為單元進(jìn)行測(cè)試以及集成由單個(gè)開發(fā)者（或小組）所產(chǎn)生

31、的結(jié)果，使其成為可執(zhí)行的系統(tǒng)。 6.3.5 測(cè)試(Test) 測(cè)試工作流要驗(yàn)證對(duì)象間的交互作用，驗(yàn)證軟件中所有組件的正確集成，檢驗(yàn)所有的需求已被正確的實(shí)現(xiàn), 識(shí)別并確認(rèn)缺陷在軟件部署之前被提出并處理。RUP提出了迭代的方法，意味著在整個(gè)項(xiàng)目中進(jìn)行測(cè)試，從而盡可能早地發(fā)現(xiàn)缺陷，從根本上降低了修改缺陷的成本。測(cè)試類似于三維模型，分別從可靠性、功能性和系統(tǒng)性能來(lái)進(jìn)行。6.3.6 部署(Deployment) 部署工作流的目的是成功的生成版本并將軟件分發(fā)給最終用戶。部署工作流描述了那些與確保軟件產(chǎn)品對(duì)最終用戶具有可用性相關(guān)的活動(dòng)，包括：軟件打包、生成軟件本身以外的產(chǎn)品、安裝軟件、為用戶提供幫助。在有些情況下，還可能包括計(jì)劃和進(jìn)行beta測(cè)試版、移植現(xiàn)有的軟件和數(shù)據(jù)以及正式驗(yàn)收。6.3.7 配置和變更管理(Configuration & Change Management) 配置和變更管理工作流描繪了如何在多個(gè)成員組成的項(xiàng)目中控制大量的產(chǎn)物。配置和變更管理工作流提供了準(zhǔn)則來(lái)管理演化系統(tǒng)中的多個(gè)變體，跟蹤軟件創(chuàng)建過(guò)程中的版本。工作流描述了如何管理并行開發(fā)、分布式開發(fā)、如何自動(dòng)化創(chuàng)建工程。同時(shí)也闡述了對(duì)產(chǎn)品修改原因、時(shí)間、人員保持審計(jì)記錄。6.3.8 項(xiàng)目管理(Project Management) 軟件項(xiàng)目管理平衡各種可能產(chǎn)生