2.4如何選擇過程模型

基本原則

1. 軟件工程是個不斷發展的學科，新的軟件過程模型會不斷出現。
2. 選用時不必拘泥於某種模型，可組合多種模型，可根據實際創造新的模型
3. 結合軟件的特點和軟件過程模型的特點來選擇。

具體分析

情況	模型	原因
前期需求明確	瀑布模型	瀑布模型管理規范，在需求明確的情況下，可以最大化保證軟件質量
用戶無系統使用經驗，需求分析人員技能不足	原型模型	|||
不確定因素很多，很多東西無法提前計划	增量模型或螺旋模型	這種情況下，此時用戶和需求人員很難通過面談等方式確定需求，而采用原型模型能夠幫助他們理解待開發系統進而明確需求
需求不穩定	增量模型	增量模型的迭代式增量開發允許在開發過程中修改需求，從而良好應對需求變化的情況
資金和成本無法一次到位	增量模型	據資金和成本到位情況，來規划增量進行開發
///	|||	\\\
需要完成多個獨立功能開發的情況，可在需求分析階段就進行功能並行，	每個功能內部！都遵循瀑布模型	要注意的是在功能內部
全新系統的開發必須在總體設計完成后再開始增量或並行	|||	開發人員對於開發全新系統缺少經驗的話，風險較大，總體設計完成后再開始增量或並行風險相對較小
編碼人員經驗較少	不要采用敏捷或迭代模型	敏捷或迭代模型對開發人員要求較高，不適合初級編程人員
三者可綜合使用，但是要有明確的交付和出口原則	增量、迭代、原型	否則會陷入邊做邊改或者效率低下的狀況

案例1：醫療設備控制軟件

案例分析

需求明確且穩定

• 可靠性和安全性要求極高。否則會出現人員傷亡，
• 對軟件錯誤和故障的控制和跟蹤能力強，發現故障一定要找出原因並加以修復
• 需要對軟件開發過程嚴格控制
• 需要大量嚴格的文檔

結果

瀑布模型

案例2：校園一卡通系統

案例分析

• 包括若干相對獨立的功能，如宿舍門禁、就餐、借書等
• 系統需要具有可擴充性，以便以后增加新功能，例如課堂考勤、校車乘坐等。
• 系統具體需求不明確且會發生變化
• 用戶需要熟悉和適應新的系統
• 項目復雜程度中等、有一定風險
• 產品和文檔的再使用率較高

結果

增量模型（管理較嚴格）

案例3：智能化小區

具體內容

1、智能家庭
·家居信息的實時和遠程監視
·家用電器的遠程和自動控制
·家庭安防報警和遠程通知
2、智能小區
·安防門禁、可視對講等
·物業管理
·一卡通系統
·繳費、包裹、公告、便民信息等發布到戶
·家政相關服務，如送水、送餐等

案例分析

• 包括若干相對獨立的功能
• 系統具體需求不明確且會發生變化
• 部分技術方案可行性不確定
• 系統需要具有可擴充性
• 用戶需要熟悉和適應新的系統
• 項目復雜程度較大、風險較大
• 希望盡早投入市場

結果

原型化模型+增量模型。

【具體需求不明確和部分技術方案可行性不確定問題——原型化模型】

【系統需求會發生變化、系統需要具有可擴充性、希望盡早投入市場、以及風險較大等問題——增量模型】