軟體生存期模型是跨越整個生存期的系統開發、運作和維護所實施的全部過程、活動和任務的結構框架
~瀑布模型
瀑布模型規定了各項軟體工程活動，包括制定開發計畫、需求分析和說明、軟體設計、程式編碼、測試和執行、維護，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。
實踐表明，上述各項活動之間並非完全是自上而下，呈線性圖式。實際情況是，每項開發活動均應具有以下特徵：
（1）從上一級活動接受本項活動的工作物件，作為輸入；
（2）利用這一輸入實施本項活動應完成的工作；
（3）給出本項活動的工作成果，作為輸出傳給下一項活動；
（4）對本項活動實施的工作進行評審，若其工作得到確認，則繼續進行下一項活動，否則返回前一項活動，甚至更前的活動進行返工。
為了保證軟體開發的正確性，每一階段任務完成後，都必須對它的階段產品進行評審，確認之後再轉入下一階段。如評審過程中發現錯誤和疏漏，應該返回前面的有關階段修正錯誤、彌補漏洞，然後再重複前面的工作，直至該階段的工作通過評審後再進入下一階段。
嚴格按照軟體生存週期階段劃分，順序執行各階段構成軟體開發的瀑布模型，是傳統的軟體工程生存期模式。採用瀑布模型進行開發組織時，應指定開發規範或開發標準，其中要明確規定各個開發階段應交付的產品，這為嚴格控制軟體開發專案的進度，最終按時交付產品以及保證軟體產品質量創造了條件。瀑布模型為軟體開發和維護提供了一種有效的管理模式。
瀑布模型是非常經典的，它的的思想是：從製作時間上按工序把問題化簡，將功能實現與製作分開，便於分工協作。
優點： 奠定了軟體工程方法的基礎；流水依賴，便於分工協作；推遲物理實現，易於修改文件，有複審質量保證。
不足：瀑布模型也存在很大的不足，這種方法開發的軟體，與使用者見面太晚，往往得到的成品，與使用者的需求存在一定的差距。
適用範圍：瀑布模型使用於系統要求明確的系統，各種應用軟體的開發均可使用。
瀑布模型圖如下：
~快速原型模型
快速原型模型克服了瀑布模型中系統分析員不了解使用者的需求的缺點。它的基本思想是軟體開發人員根絕使用者提出的軟體基本需求快速開發乙個原型，以便向使用者展示軟體系統應有的部分或全部的功能和效能，在徵求使用者對原型的評價意見之後，進一步使需求精確化、完全化，並據此改進、完善原型，如此迭代，知道軟體開發人員和使用者都確認軟體系統的需求並達成一致的理解為止。軟體需求分析確定之後，便可進行設計、編碼、測試等以後的各個開發步驟。可見，原型主要是為了完成需求分析階段的任務而構建的。
快速原型的開發途徑：
（1）僅模擬軟體系統的人機介面和人機互動方式；
（2）開發乙個工作模型，實現軟體系統中重要的或容易產生誤解的功能；
（3）利用乙個或幾個類似的正在執行的軟體向使用者展示軟體需求中的部分或全部功能。
雖然使用者和開發人員都非常喜歡原型，因為它能使使用者能夠感受到實際系統，開發人員能 很快建造一些東西。但是它也存在著一些問題：比如臨時搭建的軟體，並沒有考慮軟體的整體質量和今後的可維護性，當使用者被告知該產品必須重建時，他們往往叫苦連天。
雖然會出現問題，原型模型仍是軟體工程的乙個有效典範。建立元習慣僅僅是為了定義需求，之後就該拋棄，實際的軟體在充分考慮了質量和可維護性之後才被開發。它比瀑布模型更符合人們認識事物的過程和規律，是一種較實用的開發框架。它適合那些不能預先確切定義需求的軟體系統的開發。
快速原型模型圖如下：
~增量模型
增量模型規定軟體的開發過程是一次開發產品的乙個部分。首先應該開發產品的基本部分，然後再逐步開發產品的附加部分。為了使所開發的產品的各個部分最後能有機地組合起來，首先應該有乙個統一的體系結構設計。
再改模型中，產品的設計、實現、整合和試驗是以一系列增量構件為基礎進行的，構件是由一些模組的編碼構成並能提供特定的功能。
例如：在作業系統中，排程程式是乙個構件，然後整合到先前已構成的產品中並作為乙個整體進行測試，當這個產品滿足規定的功能，即滿足它的需求規範時，這個過程停止。開發者可以任意分解目標產品以得到一些構件，但是這些構件必須能集成為乙個滿足需要功能的產品。如果目標產品智慧型分解為很少的構件，那麼增量模型可能退化為建造與修改模型。如果目標產品分解為太多的構件，那麼每個階段結束時，使用者可能得不到需要的功能，並且有更多的時間浪費在整合上，因此構件的大小應適中，這取決於使用者的需求。乙個典型的產品通常由10-50個構件組成。
瀑布模型和快速原型模型都是提交完整的可操作質量的軟體。客戶希望交付的產品滿足所有的需求，並且應該得到全面的和正確的文件，這些文件應該用於各種維護。但是客戶得到其產品，必須等數月或者數年。
而增量型在每個階段都交付乙個可操作的產品，但是它僅僅滿足客戶需求的乙個子集。完整的產品劃分成一些構件，產品是一次乙個構件的方式開發的。當使用增量模型時，第乙個增量經常是核心產品，他滿足使用者的基本需求，而許多附加功能將在以後的增量中交付。當沒有足夠的人員在規定的 期限內開發完整的產品時，或者由於不可克服的客觀原因而把交付期限規定得太短時，增量開發方式是特別有用的。
對於增量模型來說，它的開發的乙個難點是後來開發的構件必須能夠整合到先前已開發的產品中而不毀壞已開發的功能。進而，現存的產品必須容易擴充，後開發的構件必須是簡單和直觀並容易整合。因此，對於增量模型，產品的體系結構的設計必須是開放的。
增量模型圖如下：
~螺旋模型
對於複雜的大型軟體，開發乙個原型往往達不到要求。螺旋模型將瀑布模型和原型模型結合起來，不僅體現了兩個模型的優點，而且還增加了兩個模型都忽略了的風險分析，彌補了兩者的不足。
螺旋模型的結構由四部分組成：制定計畫、風險分析、實施開發、客戶評估。在迪卡兒座標的四個象限上分別表達了四個方面的活動。
沿螺旋線自內向外每旋轉一圈便開發出乙個更為完善的新的軟體版本。例如：在第一圈，在制定計畫階段，確定了初步的目標、方案和限制條件以後，轉入風險分析階段，對專案的風險進行識別和分析。如果風險分析表明，需求有不確定性，對需求做進一步的修改。軟體開發完成之後，客戶會對工程成果做出評價，給出修正建議。在此基礎上進入第二圈螺旋，再次進行制定計畫、風險分析、實施開發和客戶評估等工作。假如風險過大，開發者和使用者無法承受，專案有可能終止。多數情況下，軟體開發過程是沿螺旋線的路徑進行的，自內向外，逐步延伸，最終總能得到乙個使用者滿意的軟體版本。
如果軟體開發人員對所開發專案的需求有了較好的理解，則無需開發原型。可採用普通瀑布模型。螺旋模型不僅保留了瀑布模型中系統地、按階段逐步地進行軟體開發和「邊開發、邊評審」的風格，而且還引入了風險分析，並把製作原型作為風險分析的主要措施。使用者始終關心、參與軟體開發，並對階段性的軟體產品提出評審意見，這對保證軟體產品的質量十分有利。
但是，螺旋模型的使用需要具有相當豐富的風險評估經驗和專門知識，而且費用昂貴，所以只適用大型軟體開發。
螺旋模型圖如下：
~噴泉模型
噴泉模型是近幾年提出來的軟體生存週期模型。它是以物件導向的軟體開發方法為基礎，以使用者需求為動力，以物件來驅動的模型。噴泉模型的特點：
（1）整個開發過程（包括維護過程）包括5個階段，即需求階段、設計、實現、測試和維護。因此，使軟體系統可維護性較好；
（2）各階段相互重疊，表明了物件導向開發各階段間的交叉和無縫過渡；
（3）整個模型是乙個迭代的過程，包括乙個階段內部的迭代和跨階段的迭代；
（4）模型具有增量開發特性，即能做到邊分析，邊設計；邊實現，邊測試，使相關功能隨之加入到演化的系統中；
（5）模型是物件驅動的，物件是各階段活動的主體，也是專案管理的基本內容；
（6）該模型很自然地支援軟體部件的重用。
噴泉模型圖如下：
分享到：
軟體生存期模型介紹
軟體生存期模型是跨越整個生存期的系統開發 運作和維護所實施的全部過程 活動和任務的結構框架 瀑布模型 瀑布模型規定了各項軟體工程活動，包括制定開發計畫 需求分析和說明 軟體設計 程式編碼 測試和執行 維護，並且規定了它們自上而下 相互銜接的固定次序，如同瀑布流水，逐級下落。實踐表明，上述各項活動之間...
靜態生存期和動態生存期
靜態生存期 定義 如果某乙個物件的生存期和程式的執行的生存期一樣，則這個物件具有靜態生存期。關鍵字 static 特點靜態變數不會隨著每次函式的呼叫產生乙個新的副本，也不會隨著函式返回而失效。第n次呼叫函式時，靜態變數的值為第n 1次呼叫的靜態變數的值，依次類推！也就是說靜態變數 第一次賦值有效，也...
軟體工程 軟體生存期
軟體生存期即軟體的生命期，是指乙個軟體從最初的想法到最終被取代的這一整個過程！軟體生存期可以分為三個大的階段，即計畫階段 開發階段 維護階段！也可以分為六個階段 問題定義與可行性研究 需求分析 軟體設計 編碼 軟體測試 執行與維護。這個階段主要是開發商與客戶共同討論，確定軟體開發的目標和可行性！可行...