增量和迭代模型
增量迭代是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,則這種原型一般都建議拋棄掉.而對于迭代開發來將,每次迭代的產出都是可以獨立運行和包含基礎功能的系統,是后續細化的基礎,這類原型一般都不建議拋棄,后期的設計開發也要基于該原型逐漸的進行完善.
快速和敏捷開發