2.4如何選擇過程模型
阿新 • • 發佈：2021-12-01
2.4如何選擇過程模型
基本原則
- 軟體工程是個不斷髮展的學科，新的軟體過程模型會不斷出現。
- 選用時不必拘泥於某種模型，可組合多種模型，可根據實際創造新的模型
- 結合軟體的特點和軟體過程模型的特點來選擇。
具體分析
| 情況 | 模型 | 原因 |
|---|---|---|
| 前期需求明確 | 瀑布模型 | 瀑布模型管理規範，在需求明確的情況下，可以最大化保證軟體質量 |
| 使用者無系統使用經驗，需求分析人員技能不足 | 原型模型 | ||| |
| 不確定因素很多，很多東西無法提前計劃 | 增量模型或螺旋模型 | 這種情況下，此時使用者和需求人員很難通過面談等方式確定需求，而採用原型模型能夠幫助他們理解待開發系統進而明確需求 |
| 需求不穩定 | 增量模型 | 增量模型的迭代式增量開發允許在開發過程中修改需求，從而良好應對需求變化的情況 |
| 資金和成本無法一次到位 | 增量模型 | 據資金和成本到位情況，來規劃增量進行開發 |
| /// | ||| | \\\ |
| 需要完成多個獨立功能開發的情況，可在需求分析階段就進行功能並行， | 每個功能內部！都遵循瀑布模型 | 要注意的是在功能內部 |
| 全新系統的開發必須在總體設計完成後再開始增量或並行 | ||| | 開發人員對於開發全新系統缺少經驗的話，風險較大，總體設計完成後再開始增量或並行風險相對較小 |
| 編碼人員經驗較少 | 不要採用敏捷或迭代模型 | 敏捷或迭代模型對開發人員要求較高，不適合初級程式設計人員 |
| 三者可綜合使用，但是要有明確的交付和出口原則 | 增量、迭代、原型 | 否則會陷入邊做邊改或者效率低下的狀況 |
案例1：醫療裝置控制軟體
案例分析
需求明確且穩定
- 可靠性和安全性要求極高。否則會出現人員傷亡，
- 對軟體錯誤和故障的控制和跟蹤能力強，發現故障一定要找出原因並加以修復
- 需要對軟體開發過程嚴格控制
- 需要大量嚴格的文件
結果
瀑布模型
案例2：校園一卡通系統
案例分析
- 包括若干相對獨立的功能，如宿舍門禁、就餐、借書等
- 系統需要具有可擴充性，以便以後增加新功能，例如課堂考勤、校車乘坐等。
- 系統具體需求不明確且會發生變化
- 使用者需要熟悉和適應新的系統
- 專案複雜程度中等、有一定風險
- 產品和文件的再使用率較高
結果
增量模型（管理較嚴格）
案例3：智慧化小區
具體內容
1、智慧家庭
·家居資訊的實時和遠端監視
·家用電器的遠端和自動控制
·家庭安防報警和遠端通知
2、智慧小區
·安防門禁、可視對講等
·物業管理
·一卡通系統
·繳費、包裹、公告、便民資訊等釋出到戶
·家政相關服務，如送水、送餐等
案例分析
- 包括若干相對獨立的功能
- 系統具體需求不明確且會發生變化
- 部分技術方案可行性不確定
- 系統需要具有可擴充性
- 使用者需要熟悉和適應新的系統
- 專案複雜程度較大、風險較大
- 希望儘早投入市場
結果
原型化模型+增量模型。
【具體需求不明確和部分技術方案可行性不確定問題——原型化模型】
【系統需求會發生變化、系統需要具有可擴充性、希望儘早投入市場、以及風險較大等問題——增量模型】
“朝著一個既定的方向去努力，就算沒有天賦，在時間的積累下應該也能稍稍有點成就吧。”