瀑布模型/改進的瀑布模型
雖然瀑布模型仍然存在很多的問題有待解決,但瀑布模型仍然是最基本的和最效的一種可供選擇的軟
件開發生命周期模型.瀑布模型要求軟件開發嚴格按照需求->分析->設計->編碼->測試的階段進行,
每一個階段都可以定義明確的產出物和驗證准則.瀑布模型在每一個階段完成后都可以組織相關的評
審和驗證,只有在評審通過后才能夠進入到下一個階段.
由於需要對每一個階段進行驗證,瀑布模型要求每一個階段都有明確的文檔產出,對於嚴格的瀑布模
型每一個階段都不應該重疊,而應該是在評審通過,相關的產出物都已經基線后才能夠進入到下一個
階段.
瀑布模型的優點仍然是可以保證整個軟件產品較高的質量,保證缺陷能夠提前的被發現和解決.采用
瀑布模型可以保證系統在整體上的充分把握,使系統具備良好的擴展性和可維護性.但對於前期需求
不明確,而又很難短時間明確清楚的項目則很難很好的利用瀑布模型.另外對於中小型的項目,需求設
計和開發人員往往在項目開始后就會全部投入到項目中,而不是分階段投入,因此采用瀑布模型會導
致項目人力資源過多的閑置的情況,這也是必須要考慮的問題.
很多人往往會以進度約束而不選擇瀑布模型,這往往是一個錯誤的觀點.導致這種情況的一個關鍵因
素往往是概念需求階段人力不足.因此在概念需求階段人力能夠得到充分保證的情況下,瀑布模型和
迭代模型在開發周期上並不會存在太大的差別.反而是很多項目對於迭代或敏捷模型用不好,為了趕
進度在前期需求不明確,沒有經過一個總體的架構設計情況下就開始編碼,后期出現大量的返工而嚴
重影響進度.
架構設計是軟件開發中一個重要的關注點.因此在 RUP 中也提及到軟件開發要以架構為核心.因此在
架構設計完成后系統會被分為相關的子系統和功能模塊.每個功能模塊間的接口都可以定義清楚.在
這種情況下,當模塊 B 的詳細設計做完成后往往就沒有必要等到其它模塊的詳細設計都要完全作完才
開始編碼,因此在架構設計完成后可以將系統分為多個模塊並行開發,每個模塊仍然遵循先設計和編
碼測試的瀑布模型思路.這是瀑布模型的一種最重要的改進思路,也可以說這是一種增量開發的模型.
當一個新系統的開發存在多個完全不相關的獨立需求的功能開發的時候,這個時候也可以選擇將整個
開發過程按獨立的需求來分為多個小瀑布進行操作.這種方式的最大問題就是沒有一個完全總體的設
計,架構設計人員無法在洞悉了所有需求后從系統的可擴展性,復用等方面總體規划.
在項目管理中有一種壓縮進度的方法叫趕工,因此瀑布模型的另外改進處就在適當的重疊各個階段過
程,達到資源的有效利用.比如我們通過討論,會議確定的實現方式就可以開始執導下一個階段的工作
而不一定完全等到相關的交付物文檔化出來
原著：https://www.hxtdpx.com/PMPcjwt/3569.html