瀑布模型/改進(jìn)的瀑布模型

　雖然瀑布模型仍然存在很多的問題有待解決,但瀑布模型仍然是最基本的和最效的一種可供選擇的軟件開發(fā)生命周期模型.瀑布模型要求軟件開發(fā)嚴(yán)格按照需求->分析->設(shè)計(jì)->編碼->測試的階段進(jìn)行,每一個(gè)階段都可以定義明確的產(chǎn)出物和驗(yàn)證準(zhǔn)則.瀑布模型在每一個(gè)階段完成后都可以組織相關(guān)的評審和驗(yàn)證,只有在評審?fù)ㄟ^后才能夠進(jìn)入到下一個(gè)階段.

　由于需要對每一個(gè)階段進(jìn)行驗(yàn)證,瀑布模型要求每一個(gè)階段都有明確的文檔產(chǎn)出,對于嚴(yán)格的瀑布模型每一個(gè)階段都不應(yīng)該重疊,而應(yīng)該是在評審?fù)ㄟ^,相關(guān)的產(chǎn)出物都已經(jīng)基線后才能夠進(jìn)入到下一個(gè)階段.
　
　瀑布模型的優(yōu)點(diǎn)仍然是可以保證整個(gè)軟件產(chǎn)品較高的質(zhì)量,保證缺陷能夠提前的被發(fā)現(xiàn)和解決.采用瀑布模型可以保證系統(tǒng)在整體上的充分把握,使系統(tǒng)具備良好的擴(kuò)展性和可維護(hù)性.但對于前期需求不明確,而又很難短時(shí)間明確清楚的項(xiàng)目則很難很好的利用瀑布模型.另外對于中小型的項(xiàng)目,需求設(shè)計(jì)和開發(fā)人員往往在項(xiàng)目開始后就會(huì)全部投入到項(xiàng)目中,而不是分階段投入,因此采用瀑布模型會(huì)導(dǎo)致項(xiàng)目人力資源過多的閑置的情況,這也是必須要考慮的問題.

　很多人往往會(huì)以進(jìn)度約束而不選擇瀑布模型,這往往是一個(gè)錯(cuò)誤的觀點(diǎn).導(dǎo)致這種情況的一個(gè)關(guān)鍵因素往往是概念需求階段人力不足.因此在概念需求階段人力能夠得到充分保證的情況下,瀑布模型和迭代模型在開發(fā)周期上并不會(huì)存在太大的差別.反而是很多項(xiàng)目對于迭代或敏捷模型用不好,為了趕進(jìn)度在前期需求不明確,沒有經(jīng)過一個(gè)總體的架構(gòu)設(shè)計(jì)情況下就開始編碼,后期出現(xiàn)大量的返工而嚴(yán)重影響進(jìn)度.

架構(gòu)設(shè)計(jì)是軟件開發(fā)中一個(gè)重要的關(guān)注點(diǎn).因此在RUP中也提及到軟件開發(fā)要以架構(gòu)為核心.因此在架構(gòu)設(shè)計(jì)完成后系統(tǒng)會(huì)被分為相關(guān)的子系統(tǒng)和功能模塊.每個(gè)功能模塊間的接口都可以定義清楚.在這種情況下,當(dāng)模塊B的詳細(xì)設(shè)計(jì)做完成后往往就沒有必要等到其它模塊的詳細(xì)設(shè)計(jì)都要完全作完才開始編碼,因此在架構(gòu)設(shè)計(jì)完成后可以將系統(tǒng)分為多個(gè)模塊并行開發(fā),每個(gè)模塊仍然遵循先設(shè)計(jì)和編碼測試的瀑布模型思路.這是瀑布模型的一種最重要的改進(jìn)思路,也可以說這是一種增量開發(fā)的模型.

當(dāng)一個(gè)新系統(tǒng)的開發(fā)存在多個(gè)完全不相關(guān)的獨(dú)立需求的功能開發(fā)的時(shí)候,這個(gè)時(shí)候也可以選擇將整個(gè)開發(fā)過程按獨(dú)立的需求來分為多個(gè)小瀑布進(jìn)行操作.這種方式的最大問題就是沒有一個(gè)完全總體的設(shè)計(jì),架構(gòu)設(shè)計(jì)人員無法在洞悉了所有需求后從系統(tǒng)的可擴(kuò)展性,復(fù)用等方面總體規(guī)劃.

　在項(xiàng)目管理中有一種壓縮進(jìn)度的方法叫趕工,因此瀑布模型的另外改進(jìn)處就在適當(dāng)?shù)闹丿B各個(gè)階段過程,達(dá)到資源的有效利用.比如我們通過討論,會(huì)議確定的實(shí)現(xiàn)方式就可以開始執(zhí)導(dǎo)下一個(gè)階段的工作而不一定完全等到相關(guān)的交付物文檔化出來.

螺旋模型

　首先螺旋模型是遵從瀑布模型的.即需求->架構(gòu)->設(shè)計(jì)->開發(fā)->測試的路線.螺旋模型最大的價(jià)值在于整個(gè)開發(fā)過程是迭代和風(fēng)險(xiǎn)驅(qū)動(dòng)的.通過將瀑布模型的多個(gè)階段轉(zhuǎn)化到多個(gè)迭代過程中,以減少項(xiàng)目的風(fēng)險(xiǎn).

螺旋模型的每一次迭代都包含了以下六個(gè)步驟
　　1.決定目標(biāo),替代方案和約束
　　2.識別和解決項(xiàng)目的風(fēng)險(xiǎn)
　　3.評估技術(shù)方案和替代解決方案
　　4.開發(fā)本次迭代的交付物和驗(yàn)證迭代產(chǎn)出的正確性.
　　5.計(jì)劃下一次迭代
　　6.提交下一次迭代的步驟和方案.

　螺旋模型實(shí)現(xiàn)了隨著項(xiàng)目成本投入不斷增加,風(fēng)險(xiǎn)逐漸減小.以幫我我們加強(qiáng)項(xiàng)目的管理和跟蹤,在每次迭代結(jié)束后都需要對產(chǎn)出物進(jìn)行評估和驗(yàn)證,當(dāng)發(fā)現(xiàn)無法繼續(xù)進(jìn)行下去時(shí)可以及早的終止項(xiàng)目.

　螺旋模型復(fù)雜的地方在于盡責(zé),專心和知識淵博的管理.因?yàn)閷τ诿恳淮蔚覀円贫ǔ銮逦哪繕?biāo),分析出相關(guān)的關(guān)鍵風(fēng)險(xiǎn)和計(jì)劃中可以驗(yàn)證和測試的交付物并不是一件容易的事情.

　螺旋模型的每一次迭代只包含了瀑布模型的某一個(gè)或兩個(gè)階段.如第二次迭代重點(diǎn)是需求,第三次迭代是總體設(shè)計(jì)和后續(xù)設(shè)計(jì)開發(fā)計(jì)劃等.因此這是和RUP提倡的迭代模型是有區(qū)別的,RUP的每一次迭代都會(huì)包含需求,設(shè)計(jì),開發(fā)和測試等各個(gè)階段的活動(dòng).RUP迭代的目的在于逐步求精而不是僅僅完成瀑布模型某一階段的工作.

增量和迭代模型

　增量迭代是RUP統(tǒng)一過程常采用的軟件開發(fā)生命周期模型.增量和迭代有區(qū)別但兩者又經(jīng)常一起使用.所以這里要先解釋下增量和迭代的概念.假設(shè)現(xiàn)在要開發(fā)A,B,C,D四個(gè)大的業(yè)務(wù)功能,每個(gè)功能都需要開發(fā)兩周的時(shí)間.則對于增量方法而言可以將四個(gè)功能分為兩次增量來完成,第一個(gè)增量完成A,B功能,第二次增量完成C,D功能;而對于迭代開發(fā)來將則是分兩次迭代來開發(fā),第一次迭代完成A,B,C,D四個(gè)基本業(yè)務(wù)功能但不含復(fù)雜的業(yè)務(wù)邏輯,而第二個(gè)功能再逐漸細(xì)化補(bǔ)充完整相關(guān)的業(yè)務(wù)邏輯.在第一個(gè)月過去后采用增量開始時(shí)候A,B全部開發(fā)完成而C,D還一點(diǎn)都沒有動(dòng);而采用迭代開發(fā)的時(shí)候A,B,C,D四個(gè)的基礎(chǔ)功能都已經(jīng)完成.

RUP強(qiáng)調(diào)的每次迭代都包含了需求,設(shè)計(jì)和開發(fā),測試等各個(gè)過程,而且每次迭代完成后都是一個(gè)可以交付的原型.迭代不是并行,在每次迭代過程中仍然要遵循需求->設(shè)計(jì)->開發(fā)的瀑布過程.迭代周期的長度跟項(xiàng)目的周期和規(guī)模有很大的關(guān)系.小型項(xiàng)目可以一周一次迭代,而對于大型項(xiàng)目則可以2-4周一次迭代.如果項(xiàng)目沒有一個(gè)很好的架構(gòu)師,很難規(guī)劃出每次迭代的內(nèi)容和要到達(dá)的目標(biāo),驗(yàn)證相關(guān)的交付和產(chǎn)出.因此迭代模型雖然能夠很好的滿足與用戶的交付,需求的變化,但確是一個(gè)很難真正用好的模型.
　

就對風(fēng)險(xiǎn)的消除上,增量和迭代模型都能夠很好的控制前期的風(fēng)險(xiǎn)并解決.但迭代模型在這方面更有優(yōu)勢.迭代模型更多的可以從總體方面去系統(tǒng)的思考問題,從最早就可以給出相對完善的框架或原型,后期的每次迭代都是針對上次迭代的逐步精化.

　業(yè)界比較標(biāo)準(zhǔn)的增量模型往往要求在軟件需求規(guī)格說明書全部出來后后續(xù)的設(shè)計(jì)開發(fā)再進(jìn)行增量.同時(shí)每個(gè)增量也可以是獨(dú)立發(fā)布的小版本.由于系統(tǒng)的總體設(shè)計(jì)往往對一個(gè)系統(tǒng)的架構(gòu)和可擴(kuò)展性有重大的影響,因此我們推薦的增量最好是在架構(gòu)設(shè)計(jì)完成后再開始進(jìn)行增量,這樣可以更好的保證系統(tǒng)的健壯性和可擴(kuò)展性.

　原型法

　原型一般都不是單獨(dú)采用的一種生命周期模型,往往會(huì)結(jié)合瀑布和增量迭代等方法一起使用.對于螺旋模型就可以理解為瀑布+迭代+原型+風(fēng)險(xiǎn)的一種生命周期模型.對于迭代開發(fā)來講,每一個(gè)迭代周期的產(chǎn)出都可以看做是下個(gè)階段要精化的原型.而對于瀑布模型開發(fā)來講,我們在需求階段也可以進(jìn)行界面和操作建模,形成DEMO后和用戶做進(jìn)一部的需求溝通和確認(rèn).

　當(dāng)你的用戶沒有信息系統(tǒng)的使用經(jīng)驗(yàn),你的系統(tǒng)分析員也沒有過多的需求分析和挖掘經(jīng)驗(yàn)的時(shí)候,需求分析和調(diào)研過程則更需要是一個(gè)啟發(fā)式的過程.而原型則是這種很好的啟發(fā)式方法,可以快速的挖掘用戶需求并達(dá)成需求理解上的一致.否則即使雙方都簽字認(rèn)可的需求往往仍然不是客戶真正想要的東西.

　原型可以分為拋棄型的和不拋棄型的.如果原型僅僅是需求階段方面和用戶溝通畫的DEMO,則這種原型一般都建議拋棄掉.而對于迭代開發(fā)來將,每次迭代的產(chǎn)出都是可以獨(dú)立運(yùn)行和包含基礎(chǔ)功能的系統(tǒng),是后續(xù)細(xì)化的基礎(chǔ),這類原型一般都不建議拋棄,后期的設(shè)計(jì)開發(fā)也要基于該原型逐漸的進(jìn)行完善.

　快速和敏捷開發(fā)

　我們一般將快速和敏捷開發(fā)做為方法論,而很少將其做為一種軟件開發(fā)生命周期模型.敏捷的目的是減少繁重和不必要的工件的輸出,提高效率.而不是要我們?nèi)ヌ綦A段或過程,不是分析設(shè)計(jì)都還沒有做就去做開發(fā).因此對于瀑布,增量迭代或原型我們都可以借鑒敏捷方法論中的一些好的實(shí)踐,這些實(shí)踐都是對傳統(tǒng)的生命周期模型很好的補(bǔ)充.對于敏捷方法論在此不再做過多的敘述.

關(guān)于選擇生命周期模型的最后的總結(jié)

　　1.在前期需求明確的情況下盡量采用瀑布模型或改進(jìn)型的瀑布模型.
　　2.在用戶無信息系統(tǒng)使用經(jīng)驗(yàn),需求分析人員技能不足情況下一定要借助原型.
　　3.在不確定性因素很多,很多東西前面無法計(jì)劃情況下盡量采用增量迭代和螺旋模型
　　4.在需求不穩(wěn)定情況下盡量采用增量迭代模型
　　5.在資金和成本無法一次到位情況下可以采用增量模型,軟件產(chǎn)品分多個(gè)版本進(jìn)行發(fā)布
　　6.對于完全多個(gè)獨(dú)立功能開發(fā)可以在需求階段就分功能并行,但每個(gè)功能內(nèi)都應(yīng)該遵循瀑布模型
　　7.對于全新系統(tǒng)的開發(fā)必須在總體設(shè)計(jì)完成后再開始增量或并行.
　　8.對于編碼人員經(jīng)驗(yàn)較少情況下建議不要采用敏捷或迭代等生命周期模型.
　　9.增量,迭代和原型可以綜合使用,但每一次增量或迭代都必須有明確的交付和出口準(zhǔn)則