級聯模型設備
瀑布模型，也稱為 Waterfall，是最著名的軟件開發方法之一。該模型的作者是溫斯頓羅伊斯。1970 年，他在一篇詳細介紹其優缺點的文章中描述了他的創新的本質。在同一個地方，他解釋瞭如何將這個模型細化為迭代模型。最初，在瀑布模型中，開發階段按以下順序進行：
- 需求的定義和協調；
- 立項；
- 編碼;
- 創建軟件產品的工作版本；
- 測試和調試；
- 軟件安裝；
- 支持。
根據瀑布模型，開發人員執行的操作是按順序發生的——逐點進行。首先，正在完成工作以確定並同意以待完成列表的形式的軟件需求。
之後，過渡到項目的創建和批准，結果是編寫描述如何實現先前商定的軟件需求的文檔。
如果設計完成，開發人員將負責實施。接下來是代碼的合併——項目各個部分的集成，這些部分由不同的團隊成員共同完成。
下一步是測試和調試產品。以前發現的錯誤已在此處修復。
最後，程序被安裝和支持。它涉及在必要時對功能進行更改並消除發現的錯誤。
級聯模型假定您可以嚴格按順序進入下一個開發階段——只有在完成前一個任務之後。不提供階段中回滾或不一致的可能性。
的優點和缺點
瀑布模型有時會因為缺乏靈活性而受到批評。許多人不喜歡它，因為項目管理的目標在其中占主導地位，而滿足最後期限、成本和開髮質量更為重要。
但是，對於大型項目，管理往往更為重要，因為這可以降低項目的風險並提高工作的透明度。
儘管存在不足，PMBOK第三版只正式規定了“級聯模型”方法論。不提供其他選項，包括迭代項目管理。
瀑布模型的優點：
- 團隊開發更容易掌控。客戶熟悉程序員當前的工作，他可以更改項目的截止日期和預算。
- 開發成本在第一階段得到批准。在對實施的所有階段達成一致後，軟件產品被連續編寫。
- 不需要經驗豐富的測試人員。對於測試階段，您可以使用程序文檔。
瀑布模型的缺點：
- 由於測試是在開發完成階段開始的，如果發現錯誤，修復它的成本將比初始階段高。畢竟，測試人員只有在開發人員已經完成代碼編寫時才會發現錯誤，而撰稿人 - 文檔。
- 開發完成後，客戶會熟悉成品。因此，只有當產品幾乎完全準備好時，他才能評估產品。如果他不喜歡這個結果，項目預算的成本就會因為需要修正而顯著增加。
- 技術文檔越多，完成工作所需的時間就越長。此類文檔需要更多的更改和批准。
“瀑布”通常用於醫療和航空航天行業的項目中，這些行業已經有廣泛的文檔基礎，可以在此基礎上製定新軟件的需求。
使用瀑布模型時，主要是寫詳細的需求。在測試期間，不應發現某處存在對整個項目產生不利影響的錯誤。
GO TO FULL VERSION