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