瀑布模型/改進(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)的交付物文檔化出來.

轉(zhuǎn)帖于：軟件水平考試_考試吧