軟體開發生命周期
來源于百度百科在新視窗打開：軟體生命周期(Software Life Cycle,SLC)是軟體的産生直到報廢或停止使用的生命周期。軟體生命周期内有問題定義、可行性分析、總體描述、系統設計、編碼、調試和測試、驗收與運作、維護更新到廢棄等階段，也有将以上階段的活動組合在内的疊代階段，即疊代作為生命周期的階段。
軟體生命周期又稱為軟體生存周期或系統開發生命周期，是軟體的産生直到報廢的生命周期，周期内有問題定義、可行性分析、總體描述、系統設計、編碼、調試和測試、驗收與運作、維護更新到廢棄等階段，這種按時間分程的思想方法是軟體工程中的一種思想原則，即按部就班、逐漸推進，每個階段都要有定義、工作、審查、形成文檔以供交流或備查，以提高軟體的品質。但随着新的面向對象的設計方法和技術的成熟，軟體生命周期設計方法的指導意義正在逐漸減少。
軟體生命周期的六個階段
問題的定義和規劃
這一階段是軟體開發方和需求方共同讨論，目的是确定軟體開發的目的和可行性，制定項目總體開發計劃。其實就是完成一個初步需求。
需求分析
在确定軟體開發可行的前提下，對軟體需要實作的各個功能進行詳細分析，完成PRD文檔(産品需求文檔)，并送出産品部，開發部，測試部評審。這裡，我們需要注意到一點就是，同樣的需求在軟體開發過程中會不斷變化和深入，此時我們便需要制定需求變更計劃來應對這種變化，以保證整個項目的正常進行。需求文檔通過評審之後，技術部制定技術文檔，并進行技術評審，評審通過進行軟體開發。
軟體設計開發
這個階段主要是根據需求分析的結果，對整個軟體系統進行設計，包括系統結構的設計，資料庫的設計等等。軟體設計又被分為詳細設計和概要設計，這兩個概念又如何了解呢？
- 概要設計：主要是對整個軟體架構的實作，搭建架構，表述各個子產品的功能，設計子產品接口連接配接以及資料傳遞的實作等事務。
- 詳細設計：對概要設計中表述的各子產品進行詳細分析，包括了對資料庫的設計。
- 軟體編碼
這一階段是将軟體設計開發的結構轉化為計算機可以運作的代碼。在編碼中要制定統一，符合标準的編寫規範，以保證代碼的可讀性，易維護性，提高代碼的效率。完成子產品的編碼後送出測試。
軟體測試
軟體設計完成之後，軟體需要經過嚴密的測試，以發現整個軟體設計過程中存在的問題并加以改正。測試的方法主要有白盒測試和黑盒測試。這裡我們要注意，測試之前需要制定詳細的測試計劃文檔，并且嚴格按照測試計劃文檔進行測試，以減少測試的随意性。測試的過程主要有單元測試，內建測試和系統測試以及驗收測試。那麼每一個測試階段又該如何了解呢？下面我們一一介紹。
- 單元測試：這一測試主要進行程式代碼的測試，確定各單元子產品被正确編譯，比如有具體到子產品的測試，也有具體到類，函數，方法的測試等。其實就可以了解為測試軟體的每個零件，這一部分通常是開發人員來完成，一般通過白盒測試的方法進行，也就是看代碼的方式啦。
- 內建測試：完成單元測試之後，将各個單元連接配接起來，形成完整的體系，然後測試軟體機關之間的接口是否正确，資料是否正常傳遞。這一階段也可以叫做接口測試，由測試人員完成，一般使用灰盒測試的方法。
- 系統測試: 把軟體系統搭建起來，按照軟體規格說明中的要求，測試軟體的性能，功能是否和使用者需求相符合，測試軟體在系統運作中是否存在漏洞等。其實在這個階段，就是測試整個軟體系統，測試軟體的功能，界面，性能，安全性，易用性，相容性等等。需要測試這個産品的詳細功能，冒煙測試一般也在這個階段完成。
- 驗收測試：這一測試是在使用者拿到軟體之後，在其使用現場，根據前邊提出的需求，以及産品規格說明書來做相應的測試，這一測試是确定軟體是否符合原定效果的測試。
運作維護
軟體維護時軟體生命周期中持續時間最長的階段，在軟體開發完成并投入使用之後，由于多方面的原因，軟體不能繼續使用使用者的需求，這是如果要延續軟體的壽命，就必須對軟體進行維護，軟體的維護包括糾錯行維護和改進型維護。
常見模型
那麼如何将上述軟體開發過程方法化呢？這就是過程模型。過程模型（Process Models） 意圖解決軟體過程中的混亂，将軟體開發過程中的溝通、計劃、模組化、建構和部署等活動（activities）有效地組織了起來。
他們之間的線性（linear）、疊代（iterative）、演進（evolutionary）和平行（parallel）關系會産生不同的模型。常見的過程模型包括：瀑布模型、原型模型、增量模型、螺旋模型等。
(結合軟體測試在不同階段的，又演化出側重測試的軟體測試模型，包括 V 模型、W 模型、H 模型、X 模型等)
1、瀑布模型
瀑布模型（Waterfall Model）是最早出現的軟體開發模型，是傳統軟體開發方法的代表。在軟體工程中占有重要的地位，它提供了軟體開發的基本架構。1970 年溫斯頓·羅伊斯（Winston Royce）提出了著名的“瀑布模型”，直到 80 年代早期，它一直是唯一被廣泛采用的軟體開發模型。
瀑布模型将軟體生命周期劃分為 制定計劃、需求分析、軟體設計、程式編寫、軟體測試和運作維護 等六個基本活動，并且規定了它們 自上而下、互相銜接的固定次序 ，如同瀑布流水，逐級下落。其 嚴格強調文檔，前一個階段的輸出就是下一個階段的輸入，文檔是個階段銜接的唯一資訊。是以很多開發人員好象是在開發文檔，而不是開發軟體，因為要到開發的後期，才可以看到軟體的“模樣”。
優點：
- 讓軟體開發過程有序可控，為項目提供了按階段劃分的檢查點。瀑布模型的每個階段都有明确的任務，每個階段都有明确的傳遞産物，都有相應的裡程碑。這些讓整個過程更可控，而且能及早發現問題
- 目前一階段完成後，您隻需要去關注後續階段
- 它提供了一個模闆，這個模闆使得分析、設計、編碼、測試和支援的方法可以在該模闆下有一個共同的指導。
- 讓分工協作變成可能。瀑布模型的六個階段，也讓軟體開發産生相應的基礎分工：項目經理、産品經理、架構師、軟體工程師、測試工程師、運維工程師。
- 品質有保障。瀑布模型每個階段都需要傳遞相應的文檔，而文檔的撰寫和評審，可以幫助在動手之前把問題溝通清楚，想清楚。瀑布模型在編碼結束後，會有嚴密的測試，隻有測試驗收通過後，才能上線釋出，這些措施都讓軟體的品質更有保障。
缺點：
- 各個階段的劃分完全固定，階段之間産生大量的文檔，極大地增加了工作量。
- 由于開發模型是線性的，使用者隻有等到整個過程的末期才能見到開發成果，進而增加了開發風險。
- 沒有疊代與回報。瀑布模型對回報沒有涉及，是以對變化的客戶需求非常不容易适應，瀑布就意味着沒有回頭路。
- 通過過多的強制完成日期和裡程碑來跟蹤各個項目階段。
- 瀑布模型的突出缺點是不适應使用者需求的變化。
- 瀑布模型是一種軟體文檔的開發，把開發者變成流水線上的機器，大量重複性的工作讓程式設計人員提不起興趣，工作很枯燥，沒有激情，程式設計成了一種沒有創意的機械勞動，這讓一向以高科技為标志的進階程式人員大為惱火。
雖然現在瀑布模型已經不是最主流的開發模式。但是不管什麼軟體項目，不管采用什麼開發模式，有四種活動是必不可少的，那就是需求、設計、編碼和測試。而這四項活動，都是起源自瀑布模型，也是瀑布模型中核心的部分。 管理人員喜歡瀑布模型的原因是把文檔了解為開發的速度，可以友善地界定不同階段的裡程碑。
2、原型模型
快速原型模型（Rapid Prototype Model）又稱原型模型，它是增量模型的另一種形式；它是在開發真實系統之前，構造一個原型，在該原型的基礎上，逐漸完成整個系統的開發工作。
下圖顯示了快速原型模型開發的基本步驟：
由于種種原因，在需求分析階段得到完全、一緻、準确、合理的需求說明是很困難的。快速原型是利用原型輔助軟體開發的一種新思想。 經過簡單快速分析，快速實作一個原型，使用者與開發者在試用原型過程中加強通信與回報，通過反複評價和改進原型，減少誤解，彌補漏洞，适應變化，最終提高軟體品質。
優點
- 原型系統已經通過與使用者互動而得到驗證，克服瀑布模型的缺點，據此産生的規格說明可以正确地描述使用者的需求。是以，在開發過程的後續階段不會因為發現了規格說明文檔的錯誤而進行較大的返工。
- 開發人員通過建立原型系統已經學到了許多東西（至少知道了“系統不應該做什麼，以及怎麼不去做不該做的事情”），是以，在設計和編碼階段發生錯誤的可能性也比較小，這自然減少了在後續階段需要改正前面階段所犯錯誤的可能性。
缺點
- 快速建立起來的系統結構加上連續的修改可能會導緻産品品質低下，是以不适合大型系統的開發（适合開發小型的、靈活性高的系統）。
- 使用這個模型的前提是要有一個展示性的産品原型，是以在一定程度上可能會限制開發人員的創新
- 所選用的原型（開發技術和工具）不一定符合主流的發展
- 快速原型模型是不帶回報環的，軟體産品的開發基本上是按線性順序進行的。
現在很多網際網路企業提供了各式各樣的原型設計工具，例如：Mockplus、Balsamiq、Axure 等。
3、螺旋模型
螺旋模型（Spiral Model）是巴利·玻姆（Barry Boehm）于 1988 年 5 月在他的文章《一種螺旋式的軟體開發與強化模型》提出的。它兼顧了快速原型的疊代的特征以及瀑布模型的系統化與嚴格監控，強調了其他模型所忽視的風險分析，特别适合于大型複雜的系統。螺旋模型最大的特點在于 引入了其他模型不具備的風險分析，使軟體在無法排除重大風險時有機會停止，以減小損失。同時，在每個疊代階段建構原型是螺旋模型用以減小風險的途徑。
螺旋模型采用一種周期性的方法來進行系統開發。這會導緻開發出衆多的中間版本。使用它，項目經理在早期就能夠為客戶實證某些概念。該模型是快速原型法，以進化的開發方式為中心，在每個項目階段使用瀑布模型法。這種模型的每一個周期都包括需求定義、風險分析、工程實作和評審 4 個階段，由這 4 個階段進行疊代。軟體開發過程每疊代一次，軟體開發又前進一個層次。采用螺旋模型的軟體過程如下圖所示:
優點
- 通過原型的建立，使軟體開發在每個疊代的最初明确方向；
- 通過風險分析，最大程度地降低軟體徹底失敗造成損失的可能性；
- 在每個疊代階段植入軟體測試，使每個階段的品質得到保證；
- 整體過程具備很高的靈活性，在開發過程的任何階段自由應對變化；
- 每個疊代階段累計開發成本，使支出狀況容易掌握；
- 通過對使用者回報的采集，與使用者溝通，以保證使用者需求的最大實作；
缺點
- 過分依賴風險分析經驗與技術，一旦在風險分析過程中出現偏差将造成重大損失；
- 過于靈活的開發過程不利于已經簽署合同的客戶與開發者之間的協調；
- 由于隻适用大型軟體，過大的風險管理支出會影響客戶的最終收益；
螺旋模型很大程度上是一種風險驅動的方法體系，因為在每個階段之前及經常發生的循環之前，都必須首先進行風險評估。在需求不明确的情況下，适合用螺旋模型進行開發，便于風險控制和需求變更。
5、增量模型
增量模型（Incremental Model）融合了瀑布模型的基本成分（重複應用）和原型實作的疊代特征，該模型采用随着日程時間的進展而交錯的線性序列，每一個線性序列産生軟體的一個可釋出的“增量”。産品被分解為多個元件，每個元件都是單獨設計和建構的。各個構件完成後逐漸并入已有的軟體體系結構中。
當使用增量模型時，第 1 個增量往往是核心的産品，即第 1 個增量實作了基本的需求，但很多補充的特征還沒有釋出。客戶對每一個增量的使用和評估都作為下一個增量釋出的新特征和功能，這個過程在每一個增量釋出後不斷重複，直到産生了最終的完善産品。增量模型強調每一個增量均釋出一個可操作的産品。采用增量模型的軟體過程如下圖所示：
在增量模型中，每個疊代階段都得到開發，是以每個階段都将經曆軟體開發生命周期的要求、設計、編碼，最後是測試子產品。每個階段開發的功能都将添加到以前開發的功能上，在軟體完全開發之前，該功能将重複。在每個增量階段，都會進行審查，根據審查，下一階段的決定将作出。
增量模型與原型實作模型和其他演化方法一樣，本質上是疊代的，但與原型實作不一樣的是其強調每一個增量均釋出一個可操作産品。早期的增量是最終産品的“可拆卸”版本，但提供了為使用者服務的功能，并且為使用者提供了評估的平台。
增量模型的特點是引進了增量包的概念，無須等到所有需求都出來，隻要某個需求的增量包出來即可進行開發。雖然某個增量包可能還需要進一步适應客戶的需求并且更改，但隻要這個增量包足夠小，其影響對整個項目來說是可以承受的。
增量模型的特征：
- 系統被分解成許多小型開發項目。
- 部分系統是為了生成最終系統而建構的。
- 首先滿足最高優先級要求。
- 一旦開發遞增部分，部分的需求将被當機。
優點
- 采用增量模型的優點是人員配置設定靈活，剛開始不用投入大量人力資源。如果核心産品很受歡迎，則可增加人力實作下一個增量。是以，增量能夠有計劃地管理技術風險。
- 每次疊代後，應執行回歸測試。在此測試期間，可以快速識别軟體的故障元素，因為在任何單個疊代中很少進行更改。
- 測試和調試比其他類型的軟體開發方法更容易，因為每次疊代時所做的更改相對較小。這允許對整個産品中的每個元素進行更有針對性的、更嚴格的測試。
- 客戶可以響應功能并檢視産品，以了解任何需要或有用的更改。
- 增量模型的靈活性可以使其适應這種變化的能力大大優于瀑布模型和快速原型模型
缺點
- 由于各個構件是逐漸并入已有的軟體體系結構中的，是以加入構件必須不破壞已構造好的系統部分，這需要軟體具備開放式的體系結構
- 在開發過程中，需求的變化是不可避免的。很容易退化為邊做邊改模型，進而是軟體過程的控制失去整體性。
- 如果增量包之間存在相交的情況且未很好處理，則必須做全盤系統分析
- 随着産品增加了其他功能，可能會出現與系統體系結構相關的問題，而早期原型中并不明顯
- 由增量産生的成本可能會超過組織的成本。
PS：增量理念也用于靈活流程模型
部分來源于網絡，作為交流分享用，如侵請聯系背景處理