路線圖： 生存期 項目初始： - 項目確立 - 生存期
項目階段和項目生存期
-
項目的執行組織通常將項目分成【若干個項目階段】，以便提供更好的【管理控制】，並與項目執行組織的持續運作之間簡歷恰當聯系；
-
【項目階段的全體】被成為【項目生存期】；
-
每個項目階段以一個或幾個可交付成果的完成作為標志；
-
【項目生存期】用來定義一個【項目的開始與結束】；
-
項目中的各個子項目也可能有明顯不同的項目生存期；
項目生存期的特點
-
費用和人力投入開始比較低，然后逐漸升高，在項目的實施、控制階段，達到最高峰。此后主鍵下降，直到項目的終止；
-
項目開始時風險和不確定性最高，隨着任務一項項的完成，不確定因素主鍵減少，項目成功完成的概率將會逐漸增加；
-
隨着項目的進行，項目變更和改正錯誤所需要的花費將隨着項目生存期的推進而激增；
-
項目干系人的影響逐步降低
項目生存期典型階段
* 啟動階段： 【概念和建議】
* 中間階段： 【開發、執行、驗證】
* 完成階段： 【收尾】
軟件生存期模型
1、軟件開發的一種框架。
2、說明了軟件的活動和進行軟件開發的過程。
3、這個模型可以是以活動為中心，可以以產品為中心的。
軟件生存期模型特征
1、描述了開發的主要階段；
2、定義了每一個階段要完成的主要過程和活動；
3、規范了每一個階段的輸入和輸出；
4、提供了一個框架，可以將必要的活動映射到該框架中；
軟件生存期模型的變遷
作坊式 =》 過程控制 =》 敏捷模型 =》DevOps
軟件生存期模型分類
預測型模型
傳統的方法，需要提前進行大量的計划工作，然后一次持續的執行；
- 瀑布模型
- V模型
適應型模型
-
迭代模型： 允許對未完成的工作進行反饋，從而改進和修改該工作；
-
增量模型： 想客戶提供已完成的，可以立即使用的可交付成果；
-
敏捷模型： 同時利用迭代和增量特征，便於完善工作；
混合模型
| 方法 | 需求 | 活動 | 提交 | 目標 |
|---|---|---|---|---|
| 預測型 | 固定 | 整個項目只執行一次 | 提交一次 | 成本可管理 |
| 迭代型 | 變化 | 一直重復執行直到正確為止 | 提交一次 | 正確的解決方案 |
| 增量型 | 變化 | 每個特定增量的活動只執行一次 | 頻繁小增量提交 | 速度 |
| 敏捷型 | 變化 | 一直重復執行直到正確為止 | 頻繁小增量提交 | 通過頻繁提交和反饋體現客戶價值 |
預測性生存期模型
-
充分利用已知和已經證明的事物，不確定性和復雜性減少，允許項目團隊將工作分解為一系列可預測的小組；
-
要求項目是高確定性的、有明確的需求順序執行；
-
包括瀑布模型和V模型；
============================================================
【需求分析】 =》 【設計】 =》 【實施】 =》 【測試】 =》 【交付】
瀑布模型
瀑布模型是將軟件生存周期的各項活動規定為按固定順序而連接的若干階段工作，形如瀑布流水，最終得到軟件產品。
瀑布模型適合的項目： 【項目的需求要明確】【解決方案要明確】【短期項目】
V模型
V模型是瀑布模型的一個變種，強調【測試與開發的一一對應關系】
項目規划 - 接收測試
需求分析 - 系統測試
總體設計 - 集成測試
詳細設計 - 單元測試
編碼和調試
V模型優缺點
優點 ：
- 強調測試過程與開發過程的對應性和並行性。
- 開發進程比較嚴格，執行過程需要嚴密控制。
- 為項目提供了按階段的檢查點，當前一個階段完成后，只需關注后續階段。
缺點：
- 不能適應需求的快速變化
- 項目的實現方案需要很明確
- 不能存在變更
V模型適合的項目： 【項目的需求很明確】【解決方案很明確】【項目對系統的性能安全很嚴格】
迭代型生存期模型
-
迭代型生存期模型： 通過連續的原型或概念驗證來改進產品或成果，每個新的原型都能帶來相關新的反饋和團隊見解。這種迭代有利於識別和減少項目的不確定性；
-
原型模型： 是在需求階段快速構建一部分系統的生存期模型，實現客戶或未來用戶與系統的交互，用戶或客戶可以作為進一步修改系統的依據；
在實踐中，迭代型生存期模型直接等同於原型模型。
原型模型適合的項目 【項目需求不明確】【希望減少項目需求的不確定性】【確定顯示界面、第一次開發的產品，驗證可行性等】
增量模型： Incremental Model
增量型生存期模型的策略是不同時開發項目需求，將需求分段，使其成為一系列增量產品
- ★ 每一增量可以分別實施，每一個增量包括需求分析、設計、實施、測試、提交等；
- ★ 每一增量是一個交付成果；
- ★ 第一增量通常是實現基本需求的核心產品；
增量模型優缺點
優點：
- 可以較好地適應變化，客戶可以不斷地看到所開發地軟件，從而降低風險。
- 可以避免一次性投資太多帶來地風險。
- 可以更快地開發出可操作地系統。
- 可以減少開發過程中用戶需求地變更。
缺點： - 軟件需具備開放式地體系結構。
- 早期需求地不穩定或不完整可能導致有地增量需要重新開發，增加了過程控制地難度。
敏捷宣言：
1. 個體交互勝過過程工具
2. 客戶合作勝過合同談判
3. 可以工作的軟件勝過面面俱到的文檔
4. 響應變化勝過遵循計划
* 應對迅速變化需求的快速軟件開發方法 * 是一種以人為核心的迭代、遵循漸進的開發方法 * 是一種輕量級的軟件開發方法