瀑布模型/改進的瀑布模型
　雖然瀑布模型仍然存在很多的問題有待解決,但瀑布模型仍然是最基本的和最效的一種可供選擇的軟體開發生命週期模型.瀑布模型要求軟體開發嚴格按照需求->分析->設計->編碼->測試的階段進行,每一個階段都可以定義明確的產出物和驗證準則.瀑布模型在每一個階段完成後都可以組織相關的評審和驗證,只有在評審通過後才能夠進入到下一個階段.
　    由於需要對每一個階段進行驗證,瀑布模型要求每一個階段都有明確的文件產出,對於嚴格的瀑布模型每一個階段都不應該重疊,而應該是在評審通過,相關的產出物都已經基線後才能夠進入到下一個階段.
　    瀑布模型的優點仍然是可以保證整個軟體產品較高的質量,保證缺陷能夠提前的被發現和解決.採用瀑布模型可以保證系統在整體上的充分把握,使系統具備良好的擴充套件性和可維護性.但對於前期需求不明確,而又很難短時間明確清楚的專案則很難很好的利用瀑布模型.另外對於中小型的專案,需求設計和開發人員往往在專案開始後就會全部投入到專案中,而不是分階段投入,因此採用瀑布模型會導致專案人力資源過多的閒置的情況,這也是必須要考慮的問題.
　    很多人往往會以進度約束而不選擇瀑布模型,這往往是一個錯誤的觀點.導致這種情況的一個關鍵因素往往是概念需求階段人力不足.因此在概念需求階段人力能夠得到充分保證的情況下,瀑布模型和迭代模型在開發週期上並不會存在太大的差別.反而是很多專案對於迭代或敏捷模型用不好,為了趕進度在前期需求不明確,沒有經過一個總體的架構設計情況下就開始編碼,後期出現大量的返工而嚴重影響進度.

         架構設計是軟體開發中一個重要的關注點.因此在RUP中也提及到軟體開發要以架構為核心.因此在架構設計完成後系統會被分為相關的子系統和功能模組.每個功能模組間的介面都可以定義清楚.在這種情況下,當模組B的詳細設計做完成後往往就沒有必要等到其它模組的詳細設計都要完全作完才開始編碼,因此在架構設計完成後可以將系統分為多個模組並行開發,每個模組仍然遵循先設計和編碼測試的瀑布模型思路.這是瀑布模型的一種最重要的改進思路,也可以說這是一種增量開發的模型.

        一個新系統的開發存在多個完全不相關的獨立需求的功能開發的時候,這個時候也可以選擇將整個開發過程按獨立的需求來分為多個小瀑布進行操作.這種方式的最大問題就是沒有一個完全總體的設計,架構設計人員無法在洞悉了所有需求後從系統的可擴充套件性,複用等方面總體規劃.
　    在專案管理中有一種壓縮排度的方法叫趕工,因此瀑布模型的另外改進處就在適當的重疊各個階段過程,達到資源的有效利用.比如我們通過討論,會議確定的實現方式就可以開始執導下一個階段的工作而不一定完全等到相關的交付物文件化出來.

螺旋模型
　    首先螺旋模型是遵從瀑布模型的.即需求->架構->設計->開發->測試的路線.螺旋模型最大的價值在於整個開發過程是迭代和風險驅動的.通過將瀑布模型的多個階段轉化到多個迭代過程中,以減少專案的風險.

螺旋模型的每一次迭代都包含了以下六個步驟
　　1.決定目標,替代方案和約束
　　2.識別和解決專案的風險
　　3.評估技術方案和替代解決方案
　　4.開發本次迭代的交付物和驗證迭代產出的正確性.
　　5.計劃下一次迭代
　　6.提交下一次迭代的步驟和方案.

　    螺旋模型實現了隨著專案成本投入不斷增加,風險逐漸減小.以幫我我們加強專案的管理和跟蹤,在每次迭代結束後都需要對產出物進行評估和驗證,當發現無法繼續進行下去時可以及早的終止專案.
　    螺旋模型複雜的地方在於盡責,專心和知識淵博的管理.因為對於每一次迭代我們要制定出清晰的目標,分析出相關的關鍵風險和計劃中可以驗證和測試的交付物並不是一件容易的事情.
　    螺旋模型的每一次迭代只包含了瀑布模型的某一個或兩個階段.如第二次迭代重點是需求,第三次迭代是總體設計和後續設計開發計劃等.因此這是和RUP提倡的迭代模型是有區別的,RUP的每一次迭代都會包含需求,設計,開發和測試等各個階段的活動.RUP迭代的目的在於逐步求精而不是僅僅完成瀑布模型某一階段的工作.

增量和迭代模型
　   增量迭代是RUP統一過程常採用的軟體開發生命週期模型.增量和迭代有區別但兩者又經常一起使用.所以這裡要先解釋下增量和迭代的概念.假設現在要開發A,B,C,D四個大的業務功能,每個功能都需要開發兩週的時間.則對於增量方法而言可以將四個功能分為兩次增量來完成,第一個增量完成A,B功能,第二次增量完成C,D功能;而對於迭代開發來將則是分兩次迭代來開發,第一次迭代完成A,B,C,D四個基本業務功能但不含複雜的業務邏輯,而第二個功能再逐漸細化補充完整相關的業務邏輯.在第一個月過去後採用增量開始時候A,B全部開發完成而C,D還一點都沒有動;而採用迭代開發的時候A,B,C,D四個的基礎功能都已經完成.RUP強調的每次迭代都包含了需求,設計和開發,測試等各個過程,而且每次迭代完成後都是一個可以交付的原型.迭代不是並行,在每次迭代過程中仍然要遵循需求->設計->開發的瀑布過程.迭代週期的長度跟專案的週期和規模有很大的關係.小型專案可以一週一次迭代,而對於大型專案則可以2-4週一次迭代.如果專案沒有一個很好的架構師,很難規劃出每次迭代的內容和要到達的目標,驗證相關的交付和產出.因此迭代模型雖然能夠很好的滿足與使用者的交付,需求的變化,但確是一個很難真正用好的模型.
        就對風險的消除上,增量和迭代模型都能夠很好的控制前期的風險並解決.但迭代模型在這方面更有優勢.迭代模型更多的可以從總體方面去系統的思考問題,從最早就可以給出相對完善的框架或原型,後期的每次迭代都是針對上次迭代的逐步精化.
　    業界比較標準的增量模型往往要求在軟體需求規格說明書全部出來後後續的設計開發再進行增量.同時每個增量也可以是獨立釋出的小版本.由於系統的總體設計往往對一個系統的架構和可擴充套件性有重大的影響,因此我們推薦的增量最好是在架構設計完成後再開始進行增量,這樣可以更好的保證系統的健壯性和可擴充套件性.

原型法
　   原型一般都不是單獨採用的一種生命週期模型,往往會結合瀑布和增量迭代等方法一起使用.對於螺旋模型就可以理解為瀑布+迭代+原型+風險的一種生命週期模型.對於迭代開發來講,每一個迭代週期的產出都可以看做是下個階段要精化的原型.而對於瀑布模型開發來講,我們在需求階段也可以進行介面和操作建模,形成DEMO後和使用者做進一部的需求溝通和確認.
　    當你的使用者沒有資訊系統的使用經驗,你的系統分析員也沒有過多的需求分析和挖掘經驗的時候,需求分析和調研過程則更需要是一個啟發式的過程.而原型則是這種很好的啟發式方法,可以快速的挖掘使用者需求並達成需求理解上的一致.否則即使雙方都簽字認可的需求往往仍然不是客戶真正想要的東西.
　    原型可以分為拋棄型的和不拋棄型的.如果原型僅僅是需求階段方面和使用者溝通畫的DEMO,則這種原型一般都建議拋棄掉.而對於迭代開發來將,每次迭代的產出都是可以獨立執行和包含基礎功能的系統,是後續細化的基礎,這類原型一般都不建議拋棄,後期的設計開發也要基於該原型逐漸的進行完善.

快速和敏捷開發
　    我們一般將快速和敏捷開發做為方法論,而很少將其做為一種軟體開發生命週期模型.敏捷的目的是減少繁重和不必要的工件的輸出,提高效率.而不是要我們去挑階段或過程,不是分析設計都還沒有做就去做開發.因此對於瀑布,增量迭代或原型我們都可以借鑑敏捷方法論中的一些好的實踐,這些實踐都是對傳統的生命週期模型很好的補充.對於敏捷方法論在此不再做過多的敘述.

關於選擇生命週期模型的最後的總結
　　1.在前期需求明確的情況下儘量採用瀑布模型或改進型的瀑布模型.
　　2.在使用者無資訊系統使用經驗,需求分析人員技能不足情況下一定要藉助原型.
　　3.在不確定性因素很多,很多東西前面無法計劃情況下儘量採用增量迭代和螺旋模型
　　4.在需求不穩定情況下儘量採用增量迭代模型
　　5.在資金和成本無法一次到位情況下可以採用增量模型,軟體產品分多個版本進行釋出
　　6.對於完全多個獨立功能開發可以在需求階段就分功能並行,但每個功能內都應該遵循瀑布模型
　　7.對於全新系統的開發必須在總體設計完成後再開始增量或並行.
　　8.對於編碼人員經驗較少情況下建議不要採用敏捷或迭代等生命週期模型.
　　9.增量,迭代和原型可以綜合使用,但每一次增量或迭代都必須有明確的交付和出口準則。