瀑布模型/改進的瀑布模型
架構設計是軟體開發中一個重要的關注點.因此在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周一次疊代.如果項目沒有一個很好的架構師,很難規劃出每次疊代的內容和要到達的目標,驗證相關的交付和產出.因此疊代模型雖然能夠很好的滿足與用戶的交付,需求的變化,但確是一個很難真正用好的模型.
就對風險的消除上,增量和疊代模型都能夠很好的控制前期的風險並解決.但疊代模型在這方面更有優勢.疊代模型更多的可以從總體方面去系統的思考問題,從最早就可以給出相對完善的框架或原型,後期的每次疊代都是針對上次疊代的逐步精化.
業界比較標準的增量模型往往要求在軟體需求規格說明書全部出來後後續的設計開發再進行增量.同時每個增量也可以是獨立發布的小版本.由於系統的總體設計往往對一個系統的架構和可擴展性有重大的影響,因此我們推薦的增量最好是在架構設計完成後再開始進行增量,這樣可以更好的保證系統的健壯性和可擴展性.
