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