生命周期模型選用指南

..生命周期模型選用指南版本1.0發(fā)布時間：XX海頤軟件股份有限公文件變更記錄*A-增加M-修訂D-刪除變更版本號日期變更類型〔A*M*D修改人變更摘要備注目的本文檔統(tǒng)一規(guī)范描述了組織內軟件開發(fā)過程中可以使用的各種生命周期模型,供項目策劃時根據項目的具體情況選用,由此確定軟件項目開發(fā)過程的各種不同的階段以及各階段的執(zhí)行順序,從而加強項目管理,提高過程能力成熟度級別,保證產品質量。適用范圍機構：產品部、開發(fā)部、工程部、質量部。業(yè)務：本指南適用于組織內的全部軟件項目。名詞術語軟件生命周期：軟件生命周期,是指從開始策劃軟件產品到軟件不再使用為止這段時間。典型的軟件生命周期包括策劃階段、需求階段、分析與設計階段、實現階段〔構造階段、測試階段、實施和維護階段。軟件生命周期模型軟件生命周期模型是對軟件工程活動的組織方式。軟件生命周期模型通過確定軟件開發(fā)活動的順序和相互制約關系來保證軟件工程活動的流程化。軟件生命周期模型瀑布模型<Waterfall>模型定義該模型首先由Royce[1970]提出,又稱線性順序模型,或典型生命周期模型,指軟件生命周期的各項活動始終按照固定順序執(zhí)行：需求、設計、構造、集成、測試、維護,各活動之間有明確的界限,非連續(xù)的,對階段結束的成果進行判斷以確定是否可以開始下一階段的工作,形如瀑布流水,最終得到軟件產品。瀑布模型是所有軟件生命周期模型的基礎。模型圖模型特點優(yōu)點瀑布模型是一種文檔驅動模型,主要的工作產品通過文檔從一個階段傳遞到下一階段,瀑布模型的每個活動的完XX是以該活動的評審通過作為標志的。當項目有著明確的產品定義以及易于理解的技術方案的情況下,瀑布模型有助于及早發(fā)現問題,降低階段成本。瀑布模型的主要特點：·簡單、易于理解·要求嚴格的管理,包括周密的項目計劃、明確的交付物、嚴格的質量控制手段〔如階段的評審等·客戶在項目的后期才可以見到的產品以及判斷產品的質量·強調產品的測試缺點：·缺乏靈活性瀑布模型要求在項目的初期明確定義全部需求,然而客戶在項目初期很難明確描述所有的需求,這種不確定性難以滿足模型要求的"穩(wěn)定的、明確定義的需求"的要求。事實上,在設計完成和代碼完成之前很難充分描述需求,因為客戶只能在最后階段看到產品,產品是否滿足客戶的真正需求只有此刻才可以得以檢驗。因此是否滿足客戶真正需求的風險往往只能在開發(fā)過程后期才顯露,相應的修改成本巨大?！ず茈y反映實際的開發(fā)過程實際的開發(fā)過程很難象瀑布模型中所有活動按照既定的順序執(zhí)行的設想一樣,因為很多活動是重復進行的?！τ谝罂焖匍_發(fā)的項目,瀑布模型可能導致過多的文檔·由于是單一流程,開發(fā)中的經驗教訓不能反饋應用于本產品的過程；·用戶的反饋只有到項目后期才看得到。適用場景適合前期需求比較明確,且項目管理能力比較欠缺的的項目；適合有穩(wěn)定的產品定義和易于掌握的技術方案的項目適合處理易于理解但復雜的項目適合質量需求高于進度和成本需求的項目適合項目的開發(fā)隊伍的技術力量比較薄弱或缺乏經驗的情況適合于小型項目帶反饋的瀑布模型<WaterfallModelWithFeedback>模型定義該模型是在瀑布模型的基礎上,為了改變瀑布模型環(huán)節(jié)間的不可逆向交互的情況,而設置了反饋環(huán)節(jié)而成。模型圖模型特點帶反饋的瀑布模型在保持原有瀑布模型活動階段自上而下、相互銜接、逐級下落的次序的同時,增加了反饋環(huán)節(jié),當某階段發(fā)現上游缺陷時可通過追溯予以消除或改進。使用場景適用于需求比較明確,各環(huán)節(jié)間反饋更新信息較少的項目。針對XX海頤軟件股份有限公司而言,本模型適合于小型的、推廣性質的網站、縣級客服、營銷管理系統(tǒng)等項目。V型模型<V-shapedModel>模型定義V形模型也是連續(xù)開發(fā)模型的一種,有時也被成為快速應用開發(fā)模型<RAD>,類似于瀑布模型。區(qū)別在于每個開發(fā)階段有一個測試階段與之匹配：需求同系統(tǒng)測試,架構設計同集成測試,子系統(tǒng)設計同單元測試。V模型是瀑布模型的改進。模型圖模型特點優(yōu)點應用和管理簡單：為開發(fā)階段定義的進入準則和出口準則可以清楚的定義,對項目進行有效管理的相關評判尺度也可以清楚的定義。同時,由于軟件開發(fā)過程的任何一個時間點,相應的文檔和代碼等都只有一個基線,所以對于配置管理也是一件比較輕松的事情。強調測試階段/過程與開發(fā)過程的對應關系：從模型中也可以看出,軟件測試是V模型的重點。在V模型生命周期模型中,軟件測試的活動是和開發(fā)的每個階段活動對應的?？梢圆豢紤]過程的反復不必隨時列出管理和支持過程缺點：V模型在處理風險方面存在不足：假如存在風險或者軟件需求方面的大的變更,我們回頭去修改前面階段的框架、設計、代碼或測試文檔和測試用例等,將需要極大的成本,同時難度也較大。軟件產品在開發(fā)過程中對用戶是不可見的：在開發(fā)階段中,用戶沒有直觀的工作產品可以體驗,只能是在產品交付之后才能使用。這導致用戶在開發(fā)過程中參與的力度不足。適用場景﹡需求是穩(wěn)定可靠的﹡軟件實現方法是成熟的﹡軟件結構清晰,模塊間的界限明晰結合本組織實際情況,本模型可以被中小規(guī)模的系統(tǒng)改造項目所采用。原型法模型<PrototypeModel>模型定義原型模型的基本指導思想是在需求階段開始前或過程中,通過部分實現系統(tǒng)功能的方式,進行快速開發(fā),建立軟件中對用戶可見的部分,即所謂的原型。然后基于這個原型,同客戶進行溝通、交流,更好的了解客戶需求,同時也使開發(fā)組對該軟件有更好的理解,過程中進行迭代,不斷修改這個原型,到了雙方都認可的程度,再做詳細的分析、設計和編碼、測試等,最終開發(fā)出客戶滿意的軟件產品。模型圖模型特點優(yōu)點直觀的表示：在需求定義之前可快速構建系統(tǒng),構建部分系統(tǒng)實現的原型,構建的系統(tǒng)需求原型可以給予客戶一個直觀的認識。用戶反饋：客戶直接對系統(tǒng)原型提供反饋,開發(fā)可以根據客戶對原型提供的反饋,確認系統(tǒng)存在的問題以及系統(tǒng)實現的優(yōu)點?？梢宰鳛橄到y(tǒng)開發(fā)人員進行系統(tǒng)需求規(guī)格的修改,以滿足客戶實際的需要。缺點：開發(fā)人員和客戶對系統(tǒng)需求的了解都不是很深入,存在許多不確定的因素,仍有許多不能關閉的問題。原型可能沒有包含產品應該包含的各個方面。原型可能使用了在實際環(huán)境中無法使用的資源比如操作系統(tǒng)。原型可能無法處理在滿負荷情況下的運行。當需求不清楚時可能導致拋棄已開發(fā)出的原型,造成原型不能利用,從而導致成本的增加。適用場景用戶技術素養(yǎng)較差,不能清晰的描述其意圖,對未來軟件的功能和期望不明確,造成項目不明確因素太多；用戶的具體功能需求不明確；用戶定義了軟件的一般性目標,但不能標識出詳細的輸入、處理和輸出需求分析設計人員對應用領域不熟悉；開發(fā)者不能確定算法的有效性、操作系統(tǒng)的適應性或人機交互的形式；新的產品領域,或者項目包含一種新技術,例：新硬件、新的開發(fā)語言、新的系統(tǒng)架構等；高風險項目;結合本組織的情況,本模型可以適用于新產品開發(fā)、WEB網站建設等。螺旋模型<Spiral>模型定義螺旋模型結合了瀑布模型的系統(tǒng)化特點和原型法模型的迭代的特征,并加入兩者所忽略的風險分析所建立的一種軟件開發(fā)模型。該模型于1998年由美國TRW公司〔提出。螺旋模型是一種風險驅動的模型。軟件項目風險的大小作為指引軟件過程的一個重要因素。采用螺旋模型的開發(fā)過程,交付的軟件系統(tǒng)是通過一系列增量版本的發(fā)布組成,早期的增量版本可能是一個紙面上的模型或是一個原型,而最后的增量版本是日漸完善的軟件系統(tǒng)。模型圖模型特點優(yōu)點包含瀑布模型和原型模型將階段分成更細小的塊允許設計的變化受風險分析的驅動,可降低開發(fā)風險用戶可較早看到產品用戶與產品開發(fā)緊密相連經費不必預先分配需應用保護性活動〔軟件配置管理和軟件質量保證缺點模型比較復雜,對項目團隊的管理能力,特別是風險的管理能力要求較高,同時需要人員,資金,和時間的投入。適用場景風險是項目中最主要的限制因素客戶無法提出明確的需求可能發(fā)生重大變更的項目項目規(guī)模和資金投入較大的項目新技術的引入,缺乏相關經驗開發(fā)團隊要求具備管理經驗特別是風險管理經驗和技能增量模型模型定義增量模型,是具備迭代特征的瀑布模型。采用該模型,每一個增量的開發(fā)過程都采用瀑布模型,產生的結果是新增部分功能或性能。當使用增量模型時,第一個增量往往是核心產品,即實現了基本的需求；核心產品交用戶使用〔或進行更詳細的復審,使用和/或評估的結果是下一個增量的開發(fā)計劃,計劃中明確了對下一增量版本內容的修改和新增待開發(fā)的功能,如此迭代,直至系統(tǒng)整體實現。增量模型和原型模型的不同之處是其強調每一個增量均要發(fā)布一個可操作產品。模型圖模型特點優(yōu)點可快速生產出可使用的系統(tǒng)在達到初始需求之前可降低成本客戶可將早期的增量作為系統(tǒng)的原型,從中獲得對后面系統(tǒng)增量的需求經驗可以減少開發(fā)過程中的返工項目總體性失敗的風險比較低。雖然可能在一些增量中存在問題,但其他的增量會成功交付。能夠有計劃地管理技術風險缺點由于增量模型的靈活性,如果沒有完善的配置管理,容易造成邊開發(fā)邊修改,喪失軟件的整體性。由于在增量實現前,需求不能被詳細定義,對確定系統(tǒng)的架構及所有增量都用到的公共服務有一定的影響。需要科學合理的進行控制增量規(guī)模和配置管理。過大的增量劃分、雜亂的基線管理等都將增加項目的風險。適用場景項目工期較緊且客戶接受分階段交付的項目;分析設計人員對應用領域不熟悉或難以全面把握的項目;已有系統(tǒng)技術路線發(fā)生改變但需求明確的移植類項目。各種中、大規(guī)模的項目類型；結合本組織的情況,本模型可以適用于工期非常緊的項目以及新產品開發(fā)。RUP的迭代模型模型定義迭代生命周期模型并不是在開始的時候就將軟件的所有需求開發(fā)出來。相反的,從實現軟件的某個部分開始,通過對這個部分進行評審來明確更進一步的需要開發(fā)的需求。重復這個過程,在模型的每個周期都生成一個新的軟件版本。迭代式模型是RUP推薦的周期模型。在RUP中,迭代被定義為：迭代包括產生產品發(fā)布的全部開發(fā)活動和必需的所有其他外圍元素。RUP中的軟件生命周期在時間上被分解為四個順序的階段,分別是：初始階段<Inception>、細化階段<Elaboration>、構造階段<Construction>和交付階段<Transition>。RUP認為,RUP中的每個階段可以進一步分解為迭代。一個迭代是一個完整的開發(fā)循環(huán),產生一個可執(zhí)行的產品版本,是最終產品的一個子集,它增量式地發(fā)展,從一個迭代過程到另一個迭代過程到成為最終的系統(tǒng)每一次的迭代都會產生一個可以發(fā)布的產品。RUP用二維坐標來描述。橫軸通過時間組織,是過程展開的生命周期特征,體現開發(fā)過程的動態(tài)結構,用來描述它的術語主要包括周期<Cycle>、階段<Phase>、迭代<Iteration>和里程碑<Milestone>；縱軸以內容來組織為自然的邏輯活動,體現開發(fā)過程的靜態(tài)結構,用來描述它的術語主要包括活動<Activity>、產物<Artifact>、工作者<Worker>和工作流<Workflow>。模型圖模型特點優(yōu)點降低了在一個增量上的開支風險。如果開發(fā)人員重復某個迭代,那么損失只是這一個開發(fā)有誤的迭代的花費。降低了產品無法按照既定進度進入市場的風險。通過在開發(fā)早期就確定風險,可以盡早來解決而不至于在開發(fā)后期匆匆忙忙。加快了整個開發(fā)工作的進度。因為開發(fā)人員清楚問題的焦點所在,他們的工作會更有效率。由于用戶的需求并不能在一開始就做出完全的界定,它們通常是在后續(xù)階段中不斷細化的。因此,迭代過程這種模式使適應需求的變化會更容易些。迭代和瀑布的最大的差別就在于風險的暴露時間上。二者的區(qū)別如下圖所示：缺點需要完備的項目管理過程支持,例如配置管理等。適用場景較復雜的應用項目大型應用項目<10人以上>高風險的項目選用軟件生命周期模型的策略選擇項目軟件的生命周期模型,一般來說包括如下步驟：步驟一：明確項目特點步驟二：根據項目特點分析識別項目風險和需求的清晰性步驟三：根據項目目標和風險、需求不確定性分析結果確定軟件生命周期策略步驟四：根據軟件生命周期策略選擇并剪裁軟件生命周期模型步驟五：評審選定的軟件生命周期模型分析項目的特點軟件生命周期模型的選擇首先要考慮項目的特點,包括：·項目借鑒資源<如是否有類似項目、類似產品的實施經驗>·資源的可用性〔包括人、資金、設施、工具·項目復雜度〔如子系統(tǒng)數量·項目的難度<如新技術的采用、新領域產品等>·開發(fā)成本〔包括人力、物力、資金等·項目進度壓力·需求的不確定性和穩(wěn)定性〔需求是否明確、是否逐漸變更、性能要求·項目版本要求〔是否以后升級、是否逐漸變更、版本重用性要求·項目風險分析分析項目風險和需求的不確定性根據項目特點分析項目的風險和需求的不確定性,不同的生命周期模型在解決風險和不確定性方面的能力是不同的,例如螺旋模型是一種以風險為導向的模型,確保隨著項目成本投入的增加,風險程度降低；而瀑布模型對風險的應對能力相對較弱,采用瀑布模型的項目中可能遺留關鍵的項目風險在項目后期才能暴露出來,而這種風險的發(fā)生帶來的損失比項目前期引起的損失大的多。當然,風險和不確定性的管理需要投入項目資源,并對項目團隊提出了相應的要求,如風險管理的能力和技能的要求、項目計劃和跟蹤與監(jiān)督的要求等,所以風險和需求不確定性大小是選擇軟件生命周期模型的重要因素,卻不是絕對的。生命周期模型選擇矩陣根據如下矩陣來評估項目,確定要選用的生命周期模型。標準V形模型瀑布模型原型模型增量模型螺旋模型迭代模型資源可用性低高有一些有一些有一些中項目復雜度低低中高高高項目成本低低低中高高以后的升級成本高高低低低低不連續(xù)的需求變更大大小小小小易使用性簡單簡單簡單復雜復雜復雜應用功能需求明確明確不明確不明確不明確不明確漸進式的需求變更小小小大大大項目壽命－－短長長長產品技術存在存在新新新新生產率高高低高高高產品和交付的階段工作產品的重用性低低低高高高需求的不確定性否否是是是是未知需求否否是是是是合并生命周期模型一個項目在不同的階段可根據需要合并生命周期模型。例如：在項目需求階段使用原型模型；在設計和編碼階段使用V形模型；在測試活動中使用瀑布模型；在運行和維護時使用迭代模型。附錄RUP介紹軟件過程是指實施于軟件開發(fā)和維護中的階段、方法、技術、實踐及相關產物<計劃、文檔、模型、代碼、測試用例和手冊等>的集合。行之有效的軟件過程可以提高開發(fā)軟件組織的生產效率、提高軟件質量、降低成本并減少風險。目前市場上領先的軟件過程主要有RUP<RationalUnifiedProcess>、OPENProcess和OOSP<Object-OrientedSoftwareProcess>。RUP的提出者Rational軟件公司聚集了面向對象領域三位杰出專家Booch、Rumbaugh和Jacobson,同時它又是面向對象開發(fā)的行業(yè)標準語言——標準建模語言<UML>的創(chuàng)立者。RUP是由Objectory過程演化而來,其初始版本為5.0,先后經歷了5.1、5.11、5.5、RationalUnifiedProcess2000等版本。RUP的二維開發(fā)模型RUP可以用二維坐標來描述。橫軸通過時間組織,是過程展開的生命周期特征,體現開發(fā)過程的動態(tài)結構,用來描述它的術語主要包括周期<Cycle>、階段<Phase>、迭代<Iteration>和里程碑<Milestone>；縱軸以內容來組織為自然的邏輯活動,體現開發(fā)過程的靜態(tài)結構,用來描述它的術語主要包括活動<Activity>、產物<Artifact>、工作者<Worker>和工作流<Workflow>。如圖:開發(fā)過程中的各個階段和里程碑RUP中的軟件生命周期在時間上被分解為四個順序的階段,分別是：初始階段<Inception>、細化階段<Elaboration>、構造階段<Construction>和交付階段<Transition>。每個階段結束于一個主要的里程碑<MajorMilestones>；每個階段本質上是兩個里程碑之間的時間跨度。在每個階段的結尾執(zhí)行一次評估以確定這個階段的目標是否已經滿足。如果評估結果令人滿意的話,可以允許項目進入下一個階段。初始階段初始階段的目標是為系統(tǒng)建立商業(yè)案例并確定項目的邊界。為了達到該目的必須識別所有與系統(tǒng)交互的外部實體,在較高層次上定義交互的特性。本階段具有非常重要的意義,在這個階段中所關注的是整個項目進行中的業(yè)務和需求方面的主要風險。對于建立在原有系統(tǒng)基礎上的開發(fā)項目來講,初始階段可能很短。初始階段結束時是第一個重要的里程碑：生命周期目標<LifecycleObjective>里程碑。生命周期目標里程碑評價項目基本的生存能力。細化階段細化階段的目標是分析問題領域,建立健全的體系結構基礎,編制項目計劃,淘汰項目中最高風險的元素。為了達到該目的,必須在理解整個系統(tǒng)的基礎上,對體系結構作出決策,包括其范圍、主要功能和諸如性能等非功能需求。同時為項目建立支持環(huán)境,包括創(chuàng)建開發(fā)案例,創(chuàng)建模板、準則并準備工具。細化階段結束時第二個重要的里程碑：生命周期結構<LifecycleArchitecture>里程碑。生命周期結構里程碑為系統(tǒng)的結構建立了管理基準并使項目小組能夠在構建階段中進行衡量。此刻,要檢驗詳細的系統(tǒng)目標和范圍、結構的選擇以及主要風險的解決方案。構造階段在構建階段,所有剩余的構件和應用程序功能被開發(fā)并集成為產品,所有的功能被詳細測試。從某種意義上說,構建階段是一個制造過程,其重點放在管理資源及控制運作以優(yōu)化成本、進度和質量。構建階段結束時是第三個重要的里程碑：初始功能<InitialOperational>里程碑。初始功能里程碑決定了產品是否可以在測試環(huán)境中進行部署。此刻,要確定軟件、環(huán)境、用戶是否可以開始系統(tǒng)的運作。此時的產品版本也常被稱為"beta"版。交付階段交付階段的重點是確保軟件對最終用戶是可用的。交付階段可以跨越幾次迭代,包括為發(fā)布做準備的產品測試,基于用戶反饋的少量的調整。在生命周期的這一點上,用戶反饋應主要集中在產品調整,設置、安裝和可用性問題,所有主要的結構問題應該已經在項目生命周期的早期階段解決了。在交付階段的終點是第四個里程碑：產品發(fā)布<ProductRelease>里程碑。此時,要確定目標是否實現,是否應該開始另一個開發(fā)周期。在一些情況下這個里程碑可能與下一個周期的初始階段的結束重合。RUP的核心工作流<CoreWorkflows>RUP中有9個核心工作流,分為6個核心過程工作流<CoreProcessWorkflows>和3個核心支持工作流<CoreSupportingWorkflows>。盡管6個核心過程工作流可能使人想起傳統(tǒng)瀑布模型中的幾個階段,但應注意迭代過程中的階段是完全不同的,這些工作流在整個生命周期中一次又一次被訪問。9個核心工作流在項目中輪流被使用,在每一次迭代中以不同的重點和強度重復。商業(yè)建模<BusinessModeling>商業(yè)建模工作流描述了如何為新的目標組織開發(fā)一個構想,并基于這個構想在商業(yè)用例模型和商業(yè)對象模型中定義組織的過程,角色和責任。需求<Requirements>需求工作流的目標是描述系統(tǒng)應該做什么,并使開發(fā)人員和用戶就這一描述達成共識。為了達到該目標,要對需要的功能和約束進行提取、組織、文檔化；最重要的是理解系統(tǒng)所解決問題的定義和范圍。分析和設計<Analysis&Design>分析和設計工作流將需求轉化成未來系統(tǒng)的設計,為系統(tǒng)開發(fā)一個健壯的結構并調整設計使其與實現環(huán)境相匹配,優(yōu)化其性能。分析設計的結果是一個設計模型和一個可選的分析模型。設計模型是源代碼的抽象,由設計類和一些描述組成。設計類被組織成具有良好接口的設計包<Package>和設計子系統(tǒng)<Subsystem>,而描述則體現了類的對象如何協(xié)同工作實現用例的功能。設計活動以體系結構設計為中心,體系結構由若干結構視圖來表達,結構視圖是整個設計的抽象和簡化,該視圖中省略了一些細節(jié),使重要的特點體現得更加清晰。體系結構不僅僅是良好設計模型的承載媒介,而且在系統(tǒng)的開發(fā)中能提高被創(chuàng)建模型的質量。實現<Implementation>實現工作流的目的包括以層次化的子系統(tǒng)形式定義代碼的組織結構；以組件的形式<源文件、二進制文件、可執(zhí)行文件>實現類和對象；將開發(fā)出的組件作為單元進行測試以及集成由單個開發(fā)者〔或小組所產生的結果,使其成為可執(zhí)行的系統(tǒng)。測試<Test>測試工作流要驗證對象間的交互作用,驗證軟件中所有組件的正確集成,檢驗所有的需求已被正確的實現,識別并確認缺陷在軟件部署之前被提出并處理。RUP提出了迭代的方法,意味著在整個項目中進行測試,從而盡可能早地發(fā)現缺陷,從根本上降低了修改缺陷的成本。測試類似于三維模型,分別從可靠性、功能性和系統(tǒng)性能來進行。部署<Deployment>部署工作流的目的是成功的生成版本并將軟件分發(fā)給最終用戶。部署工作流描述了那些與確保軟件產品對最終用戶具有可用性相關的活動,包括：軟件打包、生成軟件本身以外的產品、安裝軟件、為用戶提供幫助。在有些情況下,還可能包括計劃和進行beta測試版、移植現有的軟件和數據以及正式驗收。配置和變更管理<Configuration&ChangeManagement>配置和變更管理工作流描繪了如何在多個成員組成的項目中控制大量的產物。配置和變更管理工作流提供了準則來管理演化系統(tǒng)中的多個變體,跟蹤軟件創(chuàng)建過程中的版本。工作流描述了如何管理并行開發(fā)、分布式開發(fā)、如何自動化創(chuàng)建工程。同時也闡述了對產品修改原因、時間、人員保持審計記錄。項目管理<ProjectManagement>軟件項目管理平衡各種可能產生沖突的目標,管理風險,克服各種約束并成功交付使用戶滿意的產品