5種專案生命週期模型（個人筆記）
2.一個完整的專案生命週期一般分為：計劃、需求分析、設計、編碼、測試、釋出、實施以及執行維護階段。
參見下圖標準過程：
3.軟體過程模型是從專案需求定義直至經使用後廢棄為止，跨越整個生存期的系統開發、運營維護所經歷的全部過程、活動和任務的結構框架。
4.軟體過程模型一般分為：瀑布模型、原型模型、螺旋模型、增量模型。
5. 5種專案生命週期模型
a.瀑布模型：
1) 特點
l 階段間具有順序性和依賴性：必須等前一階段的工作完成之後，才能開始後一階段的輸入。對本階段工作進行評審，若得到確認，則繼續下階段工作，否則返回前一階段，甚至更前階段。只有前一階段輸出正確，後一階段才能正確。
l 推遲實現的觀點：在編碼之前，設定了需求分析與設計的各個階段，分析與設計階段的根本任務規定在這兩個階段主要考慮目標系統的邏輯模型，不涉及軟體的物理實現。
l 質量保證的觀點：
每個階段都堅持兩個做法：
規定文件，沒有文件就沒有完成該段任務。
每個階段結束前都要對完成的文件進行評審，以便儘早發現問題，改正錯誤。
2) 缺點
l 依賴於早期進行的唯一的一次需求調查，不能適應需求的變化；
l 由於是單一流程，開發中的經驗教訓不能反饋應用於本產品的過程；
l 風險往往遲至後期的開發階段才顯露，因而失去及早糾正的機會。
3) 適用專案
l 需求清晰明瞭且時間要求寬鬆的軟體開發專案；
l 規模小，需求簡單，功能單一的專案
4) 階段劃分
計劃階段
需求階段
設計階段
編碼階段
測試階段
釋出階段
實施階段
執行維護階段
b.原型模型：
原型模型快速建立起來的可以在計算機上執行的程式，他所能完成的功能往往是最終產品能完成的功能的一個子集。一般來說，根據客戶的需要在很短的時間內解決使用者最迫切需要，完成一個可以演示的產品，這個產品只實現部分功能。原型最重要的是為了確定使用者的真正需求。
原型模型在克服瀑布模型缺點、減少由於軟體需求不明確給開發工作帶來風險方面，確有顯著效果。軟體系統的原型常用有以下形式：
拋棄型：開發原型為了獲取需求，在原型開發之後，已獲取了更為清晰的需求資訊，原型無需保留而廢棄；
漸進型：原型作為軟體最終產品的一部分，可滿足使用者的部分需求，進一步在此基礎上開發，則可增加需求，實現後再交付使用；
1) 特點
l 使用者需求不完全或不確定；
l 針對總體的輪廓先建立一個使用者需求原型，然後進行評價和反饋；
l 對原型進行擴充、改進和求精；
l 完成最終系統
2) 缺點
l 沒有考慮軟體的整體質量和長期的可維護性。
l 大部分情況是不合適的操作演算法被採用目的為了演示功能，不合適的開發工具被採用僅僅為了它的方便，還有不合適的作業系統被選擇等等。
l 由於達不到質量要求產品可能被拋棄，而採用新的模型重新設計。
3) 適用專案
l 客戶能提出一般性的目標，但不能標出詳細的輸入、處理及輸出需求；或開發者不能確定演算法的有效性、作業系統的適應性、及人機互動的形式。
l 使用者定義了一組一般性目標，但不能標識出詳細的輸入、處理及輸出需求；
l 開發者可能不能確定演算法的有效性、作業系統的適應性或人機互動的形式
4) 階段劃分
拋棄型原型模型的階段劃分：
需求分析階段--獲取業務需求
原型實現階段—主要是介面實現，業務流程用圖形方式表示。
客戶評價階段--和客戶確認，完善業務需求
漸進型原型模型的階段劃分：
需求分析階段（需求分析、原型實現、客戶評價）
設計階段
編碼階段
測試階段
釋出階段
實施階段
執行維護階段c.螺旋模型
將瀑布模型與原型模型結合起來，並且加入兩種模型均忽略了的風險分析。
1) 特點
風險驅動的，關注風險，風險分析後決策是否繼續進行專案
2) 優點
l 對可選方案和約束條件的強調有利於已有軟體的重用，也有助於把軟體質量作為軟體開發的一個重要目標；
l 減少了過多測試或測試不足；
l 維護和開發之間並沒有本質區別。
3) 適用專案
主要是用於大規模軟體專案，需求不明朗，風險比較高的專案。
4) 階段劃分
螺旋模型沿著螺線旋轉，自內向外每旋轉一圈便開發出更完善的一個新版本。一個螺旋為一個階段，每個螺旋式週期可分為：
l 制定計劃： 確定軟體目標，選定實施方案，弄清專案開發的限制條件；
l 風險分析： 分析所選方案，考慮如何識別和消除風險；
l 實施工程： 實施軟體開發（需求、設計、編碼、測試等按螺旋週期推進）
l 客戶評估： 評價本輪的開發結果，提出修正建議，計劃下一輪的工作。
d.增量模型
融合了瀑布模型的基本成分和原型的迭代特徵。採用隨著日程時間的進展而交錯的線性序列。把軟體產品作為一系列的增量構件來分析、設計、編碼、測試和釋出。
l 第一階段增量往往是核心產品
l 每一階段增量均為可釋出一個版本，早期的增量是最終產品的“可拆卸”版本
2) 優點
l 人員分配靈活，剛開始不用投入大量人力資源，當核心產品很受歡迎時，可增加人力實現下一個階段增量。同時人員可以並行工作。
l 需求明確部分可以分階段實現，逐步優化系統需求，逐步整合系統元素
l 階段交付，當配備的人員不能在設定的期限內完成產品時或者客戶/市場要求進度急迫時，提供了一種先推出核心產品的途徑，這樣階段交付部分功能給客戶，對客戶起到鎮靜劑的作用。
3) 適用專案
適用於需求逐漸清晰的軟體專案
4) 階段劃分
計劃階段
第一階段（需求、設計、編碼、測試、釋出）
第二階段（需求、設計、編碼、測試、釋出）
第N階段（需求、設計、編碼、測試、釋出）
釋出階段
實施階段
執行維護階段
e.V模型
最典型的V模型版本一般會在其開始部分對軟體開發過程進行描述：
v-model是一種軟體生存期模型，旨在提高軟體開發的效率和有效性，是瀑布模型的一種改進，瀑布模型（Waterfall Model）將軟體生命週期劃分為計劃、分析、設計、構建、測試和維護六個階段，且規定了它們自上而下、相互銜接的固定次序，由於早期的錯誤可能要等到開發後期的測試階段才能發現，所以帶來嚴重的後果。 v-model就是在這點改進了瀑布模型，在軟體開發的生存期，開發活動和測試活動幾乎同時的開始，這兩個並行的動態的過程就會極大的較少bug和error出現的機率。在v-model中，我認為一個關鍵詞就是parallel，說起來簡單，卻是v-model的核心。
v-model包含了三個等級，分別是生存期模型，分配模型，功能性工具需求模型，生存期模型回答了“What has to be done?”的問題，闡述了應當實施哪些活動，應當產生哪些結果，諸如此類。分配模型回答了“How is it be done”，決定了在實施活動的時候應該使用什麼方法，功能性工具需求模型回答了“What is used to do it”，採用什麼樣的工具來實現這些活動。所有這些等級中又是由4個子模組組成的，分別是專案管理模組(PM)，系統開發模組(SD)，品質保證模組(QA)，配置管理模組(CM)，這些模組的功能就顯而易見了。