1、.生命周期模型及選擇指南Version 1.1文檔名稱： ZD-MMI-Guidelines-生命周期及模型選擇指南-V1.1.修訂歷史記錄序號日期版本號修改說明修改人評審人批準人1.2014-5-230.1初次撰寫李葉繁王洪濤2.2014-6-201.0EPG評審發布王洪濤EPG、質量管周順平理中心EPG、質量管3.2015-1-91.1制度化發布王洪濤周順平理中心4.5.6.7.8.9.目錄1 目的和范圍 .12 生命周期可選模型簡介 .12.1瀑布模型 .12.1.1標準瀑布模型 .12.1.2 V 模型 .32.1.3中等簡化 V 字模型（ V4 模型） .42.1.4最簡化 V 字模

2、型（ V3 模型） .62.2原型模型 .82.2.1原型模型的形式 .82.2.2特點 .82.2.3缺點 .92.2.4適用項目 .92.2.5階段劃分 .92.3螺旋模型 .102.3.1特點 .102.3.2適用項目 .112.3.3階段劃分 .112.4增量模型 .112.4.1特點 .112.4.2適用項目 .122.4.3階段劃分 .122.5迭代模型 .122.5.1特點 .142.5.2適用情況 .142.5.3迭代分類 .153 生命周期模型選擇指南 .16.3.1生命周期模型選擇特性指標 .163.1.1需求清晰性、完整性、穩定性 .163.1.2項目規模 .163.1.

3、3項目類型 .173.1.4技術復雜度 .173.1.5可重用性 .183.1.6重用已有產品 .183.2生命周期模型選擇決策參考 .183.3生命周期模型與特性指標對應關系.193.4生命周期選擇 .20附錄：標準項目生命周期圖 .21.軟件生命周期模型及選擇指南1 目的和范圍本文用以描述中地公司推薦的軟件項目生命周期（以下簡稱LC）模型，并說明如何根據項目特性選擇合適的LC模型。2 生命周期可選模型簡介軟件生命周期指軟件開發全部過程、 活動和任務的結構框架。 軟件開發包括需求、 設計、編碼和測試等階段，有時也包括維護階段。2.1 瀑布模型需求分析設計開發時期編碼測試發布實施維護時期運行維

4、護2.1.1 標準瀑布模型.1 特點1、階段間具有順序性和依賴性：必須等前一階段的工作完成之后，才能開始后一階段的輸入。對本階段工作進行評審，若得到確認，則繼續下階段工作，否則返回前一階段，甚至更前階段。只有前一階段輸出正確，后一階段才能正確；.2、推遲實現的觀點：在編碼之前，設置了需求分析與設計的各個階段，分析與設計階段的根本任務規定在這兩個階段主要考慮目標系統的邏輯模型，不涉及軟件的物理實現；3、質量保證的觀點是每個階段都堅持兩個做法：規定文檔，沒有文檔就沒有完成該段任務；每個階段結束前都要對完成的文檔進行評審，以便盡早發現問題，改正錯誤。.2 缺點1、無法解決軟件需求不明確或不準確的問題

5、；2、依賴于早期進行的唯一的一次需求調查，不能適應需求的變化；3、由于是單一流程，開發中的經驗教訓不能反饋應用于本產品的過程；4、風險往往遲至后期的開發階段才顯露，因而失去及早糾正的機會。.3 適用項目1、充分理解用戶需求，且需求是確定不變的；2、用戶有一定的能力，對需求的表述是確切的；3、充分理解該解決方案的技術和體系；4、需要一個可維護性和可支持性較高的解決方案；5、所有過程工作產品的控制基線，需要有可見度和可靠性；6、適用于新的有較多用戶的產品、平臺 / 中間件開發項目，或者是用戶對開發過程有嚴格要求的工程定制項目；7、項目經理有一定的項目管理經驗；8、需求清晰明了且時間要求寬松的軟件開

6、發項目；9、規模小、需求簡單、功能單一的項目。.4 階段劃分1、需求階段2、設計階段3、編碼階段4、測試階段5、發布階段6、實施階段.7、運行維護階段2.1.2 V 模型V 模型其實就是瀑布模型，它是一種線型順序模型，是項目自始至終按照一定順序的步驟從需求分析進展到系統測試直到提交用戶使用，它提供了一種結構化的、自頂向下的軟件開發方法，每階段主要工作成果從一個階段傳遞到下一個階段，必須經過嚴格的評審或測試，以判定是否可以開始下一階段工作，各階段相互獨立、不重疊。V 字模型是所有生命周期模型的基礎。流程圖如下所示：Product InvestigationReport/Acceptance Te

7、st PlanAcceptance TestUser Requirements/PISystem TestSTDELCLSRAPlanKOProjectDCKickoffIntegration TestDeliveryRSOHLDPlanCompleteRequirementsSCSign OffSystemITCompleteASOModuleTestFCArchitectureLLDPlanFunctionSign OffCompleteDSOCSOSystemDesign SignCUTSuggested forOffCode Sign Offsystem shape:LEGENDSub

8、systemSubsystemSubsystemControl FlowData FlowModuleModuleModuleModuleXXXCheckpoint that canModuleModulebe signed off by theUnitProject ManagerUnitUnitUnitUnitCheckpoint that isUnitUnitUnitUnitrecommended toUnitUnitUnitUnitUnitXXXbe signed off bySeniorStandard V-Waterfall LifecycleManagement.1 特點1、強調

9、開發的階段性；2、強調早期的計劃及需求調查與分析；3、強調產品測試的完備性；4、過程文檔齊全，便于追溯和重用；5、過程的可見性強，便于過程質量控制；6、只要需求是穩定的，則進度也是穩定的。.2 缺點1、無法解決軟件需求不明確或不準確的問題；2、靈活性差，依賴于早期進行的需求調查，不能適應需求的變化；3、由于是單一流程，開發中的經驗教訓不能及時反饋并應用于本產品的過程改進。.3 適用項目1、充分理解用戶需求，需求是確定不變的；2、用戶有一定的能力，對需求的表述是確切的；3、充分理解該解決方案的技術和體系；4、需要一個可維護性和可支持性較高的解決方案；5、所有過程工作產品的控制基線，需要有可見度和

10、可靠性；6、適用于新的有較多用戶的產品、平臺 / 中間件開發項目，或者是用戶對開發過程有嚴格要求的工程定制項目；7、項目經理有一定的項目管理經驗；8、要求開發周期時間較充分。.4 階段劃分1、需求開發2、項目計劃3、概要設計4、詳細設計5、編碼和單元測試6、集成測試7、系統測試8、驗收測試9、驗收10、發布2.1.3 中等簡化 V 字模型（ V4 模型）針對項目的實際情況，對V 字（瀑布）模型進行演化是必要的。中等簡化V 字模型是.在標準瀑布模型基礎上根據組織中一些小項目等的實際需要演化來的。流程圖如下所示：Product Investigation Report/User requireme

11、ntsAcceptance Test PlanAcceptance TestPISystem TestDELCLSKOPlanSTProjectRAKickoffDCSCRSODeliverySystemCompleteRequirementsCompleteSign OffCUTLLDCSODSOCode Sign OffDesign SignOffLEGENDSuggested forControl Flowsystem shape:SystemData FlowXXXCheckpoint that canbe signed off by theUnitUnitUnitUnitProjec

12、t ManagerCheckpoint that isXXXrecommended tobe signed off bySeniorFour Phase V-Waterfall Life CycleManagement.1 特點1、可以適應中等和較小項目的較靈活的管理需要；2、提供中度的進度控制，相對標準V 字模型，可以減少部分項目管理工作量和開支；3、在產品交付方面進行合理的控制。.2 缺點因項目開發流程相對簡化，項目的風險增大，質量隱患增大。.3 適用項目1、項目的復雜度、團隊的規模、工作量和周轉時間都是中等程度的；2、需求和技術都已被充分理解；3、項目經理有較高的項目管理和控制的經驗。.

13、4 階段劃分1、需求開發2、設計3、編碼和單元測試4、系統測試5、驗收測試6、驗收7、發布2.1.4 最簡化 V 字模型（ V3 模型）最簡化V 字模型在標準瀑布模型基礎上根據組織中的小項目和維護項目等的實際需要演化而來。流程圖如下所示：Project Go AheadAcceptance Test PlanAcceptance TestInvestigationTest strategyDELCLS(INV)STDCDeliveryDSOCompleteSCDesign SignSystemOffCompleteCUTCSOCode Sign offSuggested for small p

14、rojectswhose scope is enhancement ofLEGENDan existing productControl FlowData FlowXXXCheckpoint that canbe signed off by theProject ManagerCheckpoint that isThree Phase V- Waterfall Life CycleXXXrecommended to besigned off by SeniorManagement.1 特點1、可以適應小項目的靈活性；2、減少過程復雜帶來的產品提交時間延長；3、過程相對簡單，項目管理控制的工作量

15、相對較少；4、提供中度的進度控制；.5、減少開支。.2 缺點1、對階段性的控制較弱，問題不能及時發現；2、項目前期控制較弱，使得項目產品質量留有隱患。.3 適用項目1、項目的規模和工作量都比較小；2、項目具有較小的開發團隊；3、需求和技術都是被充分確定和理解的；4、系統具有低復雜度，不需要獨立的設計階段；5、產品的體系結構是穩定的；6、項目經理經驗豐富，對項目有較好的管理控制能力；7、項目開發周期較短。.4 階段劃分1、集成設計階段2、編碼和單元測試3、系統測試4、驗收5、發布.2.2 原型模型需求分析原型開發用戶反饋原型評價最終系統設計最終系統實現原型模型是快速建立起來的可以在計算機上運行的

16、程序， 它所能完成的功能往往是最終產品能完成的功能的一個子集。 一般來說， 根據客戶的需要在很短的時間內解決用戶最迫切需要， 完成一個可以演示的產品， 這個產品只實現部分功能。 原型最重要的是為了確定用戶的真正需求。原型模型在克服瀑布模型缺點、減少由于軟件需求不明確給開發工作帶來風險方面，確有顯著效果。2.2.1 原型模型的形式.1 拋棄型開發原型為了獲取需求，在原型開發之后，已獲取了更為清晰的需求信息，原型無需保留而廢棄。.2 漸進型原型作為軟件最終產品的一部分，可滿足用戶的部分需求，如進一步在此基礎上開發，則可在實現其他需求后交付使用。2.2.2 特點1、用戶需求不完全或不確定；2、針對總

17、體的輪廓先建立一個用戶需求原型，然后進行評價和反饋；.3、對原型進行擴充、改進和求精；4、完成最終系統。2.2.3 缺點1、沒有考慮軟件的整體質量和長期的可維護性；2、大部分情況是不合適的操作算法被采用，目的是為了演示功能，不合適的開發工具被采用，僅僅為了它的方便，還有不合適的操作系統被選擇等等；3、由于達不到質量要求產品可能被拋棄，而采用新的模型重新設計。2.2.4 適用項目1、客戶能提出一般性的目標，但不能標出詳細的輸入、處理及輸出需求；或開發者不能確定算法的有效性、操作系統的適應性、及人機交互的形式；2、用戶定義了一組一般性目標，但不能標識出詳細的輸入、處理及輸出需求；3、開發者可能不能

18、確定算法的有效性、操作系統的適應性或人機交互的形式。2.2.5 階段劃分.1 拋棄型原型模型的階段劃分1、需求分析階段獲取業務需求2、原型開發階段主要是界面實現，業務流程用圖形方式表示3、原型評價階段和客戶確認，完善業務需求4、系統設計5、系統實現.2 漸進型原型模型的階段劃分1、需求分析階段（需求分析、原型實現、客戶評價）2、設計階段3、編碼階段4、測試階段5、發布階段6、實施階段.2.3 螺旋模型螺旋模型是將瀑布模型與演化模型結合起來，并且加入兩種模型均忽略了的風險分析。累計制訂計劃成本決定目標方案和限制風險風分險析分風險析分析提交原型 1原型 2原型 3評審需求計劃軟件生存期計劃開軟件發

19、需求集產品計劃需求確認成與設計確認測試與驗證單元集成測試驗收與實現測試測試客戶評價風險分析評價方案，識別風險、消除風險可運行原型詳細設計編碼實施工程開發、驗證下一產品2.3.1 特點風險驅動的，關注風險，風險分析后決策是否繼續進行項目。.1 優點1、對可選方案和約束條件的強調有利于已有軟件的重用，也有助于把軟件質量作為軟件開發的一個重要目標；2、減少了過多測試或測試不足；3、維護和開發之間并沒有本質區別。.2 缺點1、執行風險分析的費用較高，會大大降低項目的利潤。一般只有大型項目才有必要采用此模型，并且要有足夠的經費支持；2、使用該模型要求開發人員具備相當豐富的風險分析經驗，如果項目實際上正走

20、向災.難，而分析人員還認為一切良好，那么項目就會失敗；3、螺旋模型過于復雜，不及瀑布模型那么容易理解和使用。2.3.2 適用項目主要是用于大規模軟件項目，需求不明朗，風險比較高的項目。2.3.3 階段劃分螺旋模型沿著螺線旋轉，由內向外每旋轉一圈便開發出更完善的一個新版本。一個螺旋式周期可分為：1、制定計劃：確定軟件目標，選定實施方案，弄清項目開發的限制條件；2、風險分析：分析所選方案，考慮如何識別和消除風險；3、實施工程：實施軟件開發（需求、設計、編碼、測試等按螺旋周期推進）；4、客戶評估：評價本輪的開發結果，提出修正建議，計劃下一輪的工作。2.4 增量模型增量模型融合了瀑布模型的基本成分和原

21、型的迭代特征。采用隨著日程時間的進展而交錯的線性序列。把軟件產品作為一系列的增量構件來分析、設計、編碼、測試和發布。計劃第一階段增量需求設計編碼測試發布第二階段增量需求設計編碼測試發布第N 階段增量需求設計編碼測試發布實施運行維護2.4.1 特點1、第一階段增量往往是核心產品；2、每一階段增量均為可發布一個版本，早期的增量是最終產品的“可拆卸”版本。.1 優點1、人員分配靈活，剛開始不用投入大量人力資源，當核心產品很受歡迎時，可增加人力實現下一個階段增量。同時人員可以并行工作；2、需求明確部分可以分階段實現，逐步優化系統需求，逐步集成系統元素；3、階段交付， 當配備的人員不能在設定的期限內完成

22、產品時或者客戶/ 市場要求進度急迫時， 提供了一種先推出核心產品的途徑，這樣階段交付部分功能給客戶，對客戶起到鎮靜劑的作用。.2 缺點新開發的“增量”在合并進原有軟件系統時，可能破壞原來構造好了的內容。2.4.2 適用項目適用于需求逐漸清晰的軟件項目。2.4.3 階段劃分1、計劃階段2、第一階段（需求、設計、編碼、測試、發布）3、第二階段（需求、設計、編碼、測試、發布）4、第 N 階段（需求、設計、編碼、測試、發布）5、發布階段6、實施階段7、運行維護階段2.5 迭代模型在項目做計劃的過程中，選用迭代模型時，有如下要求：1、進行第一次項目計劃時，確定所選擇的生命周期模型為迭代模型時，要求在計劃

23、中明確進行迭代流程階段、迭代的次數、 每次迭代所選的生命周期模型以及每次迭代的起止日期；2、每次迭代所選的生命周期模型， 可以根據本次迭代的重點， 選擇瀑布型 -標準 V 模型、中等簡化 V 字模型、最簡化 V 字模型中的一種，或者是某種瀑布模型的某幾個流程階段，.確定為本次迭代的工作流程階段。對項目 WBS 的要求：1、以下表格可以與WBS結合， 用于明確各流程階段的工作任務、該任務在本次迭代中的重要程度（強、中、弱）、該流程階段的控制點及控制手段（如重要程度為“強”的任務須進行評審， “中”的任務可以通過變更過程進行控制，“弱”的任務可以通過批準直接在文檔的修訂頁中注明） 。重要程度迭代次

24、數流程階段工作任務工作產品控制點及控制手段（強、中、弱）2、根據每次迭代的WBS 任務和各WBS 任務在本次迭代中的重要程度（強、中、弱），參照迭代模型樣例圖，繪制本項目的迭代模型圖；3、從第二次到第N 次的迭代，在不與第一次計劃沖突的基礎上，制訂本次迭代的小計劃，也可以直接在項目的Project 圖上進行本次迭代計劃的細化；4、如果后幾次迭代對第一次計劃的內容有變動，如進度的調整，控制點的變化等，則須進行變更及批準。迭代模型的開發流程圖如下：.2.5.1 特點1、允許變更需求，中途的修改是容易的，但需要在項目組內部和外部之間有良好的溝通渠道；2、有助于項目組的學習和提高，團隊成員有機會在整個

25、生命周期中邊做邊學，各顯其能；3、迭代流程自身可在進行過程中得到改進和精煉；4、生成性能更強壯的產品；5、風險管理比較容易，可及早降低風險，前提是存在良好的信息傳遞渠道；6、與其他生命周期模型相比，它在開發周期內具有更好的性能。.1 缺點1、因本模型較為靈活，對管理的要求較高，項目經理需要有豐富的項目管理經驗；2、迭代的次數和任務規劃難把握，對項目策劃要求較高。2.5.2 適用情況1、規模較大的項目或產品；.2、需求的清晰度低，且需要進一步的調查；3、技術或體系結構方面的知識匱乏。2.5.3 迭代分類新領域、新技術的研發項目，比如公司內部的平臺系統的研發就屬于標準的迭代類型，兩種代表性的迭代模

26、型：.1 以需求、計劃、設計為重點的迭代模型此種模型是根據組織目前的實際情況制定的，常用于需求不明確的項目。使用此模型的要求與迭代模型相同，流程圖如下所示.2 以計劃、設計、編碼、測試為重點的迭代模型此種模型是根據組織目前的實際情況制定的，常用于算法型等技術難度較高的項目。使用此模型的要求與迭代模型相同，流程圖如下所示：.3 生命周期模型選擇指南3.1 生命周期模型選擇特性指標在選擇軟件生命周期模型的時候，需要考慮以下因素：3.1.1 需求清晰性、完整性、穩定性1、清晰性：項目成員及客戶對需求的理解程度。需求越明確，后期需求變更就越小；2、完整性：需求定義的來源多樣，需求開發可兼顧各類項目干系

27、人；3、穩定性：需求的穩定程度。若需求穩定程序不高，對瀑布模型要適當調整或組合。等級分為三級：High、 Medium and Low 。3.1.2 項目規模項目規模通過以下指標進行衡量：.1 工作量指完成項目的工作量，通常工作量越大，就要求越嚴格、正規的LC規模。.1、 Large:Effort > 30 Person Month (PM)2、 Medium:Effort between 15-30 PM3、 Small:Effort between 6-15 PM4、 Very Small:Effort < 6 PM說明： 1 Person Month 22 Person Da

28、y.2 團隊規模指項目團隊的人員數量，通常團隊規模越大，就要求越嚴格、正規的LC 規模，以緩解溝通渠道增加帶來的風險。1、 Large:>302、 Medium:Between 10 and 303、 Small:Between 3 and 104、 Very Small:<3.3 項目周期對從項目開始到完成的日歷時間，一般來說，LC模型越正規，要求時間越長。1、 Large:> 12 月2、 Medium:Between 6-12 月3、 Small:Between 3-6 月4、 Very Small:< 3 月3.1.3 項目類型1、內部產品研發：因公司戰略發展需要，根據市場調研的用戶需求、技術發展動向，結合有關的政策、法令、法規和標準，面向特定領域、行業針對性的產品成果或解決方案。2、市場合同項目：為履行與外部客戶已訂立合同的項目。3.1.4 技術復雜度指開發軟件的復雜度，復雜度與規模、功能、接口數量有關。復雜度越高、就要求越嚴格、正規的LC 規模，因為其有更好的控制機制。等級分為三級：