瀑布模型的問題是什麼？ - IT 觀察者隨筆

Table of Contents hide

對於某些工程設計領域，瀑布模型是一種相對線性的順序設計方法。

在軟件開發中，它往往是較少迭代和靈活的方法之一，因為進展在很大程度上是向下流動的，就像瀑布一樣，通過概念、啟動、分析、設計、構建、測試、部署和維護等階段。在軟件開發項目中使用的階段通常如下所示：

一、要求

如果您從事軟件開發或任何類型的項目創建團隊，您會想知道您嘗試創建的業務環境——您想定義您嘗試解決的問題類型以及人們對您的反應的反應完成的產品。在您定義了所有這些“要求”之後，您就有了進入下一步所需的輸入。

2. 設計

此步驟由滿足您之前確定的所有要求所需的所有步驟組成。在軟件開發中，這是您定義所有軟件和硬件架構、編程語言、數據存儲等的部分。這也是您確定項目如何對其最終用戶有用的部分。

3. 實施

在這一步中，您開始構建您在計劃中設計的內容。瀑布方法的這一部分致力於滿足您在前面的步驟中製定的標準。這是開發團隊的人進來並讓前面步驟中討論的所有事情發生的部分。

4. 驗證

這是質量保證人員進入以確保開發團隊沒有犯任何錯誤的方法的一部分。這也很可能是人們意識到他們的計劃中哪些有效或無效的部分。

注意

當項目開發人員對所有事情都滿意時，如果項目準備好啟動，客戶或最終用戶就會進來並做出最終決定。

瀑布方法指出，當某個特定階段出現問題時，人們可以回到前一個階段，看看出了什麼問題。例如，如果計劃實施中出現問題，而人們知道他們只是按照交給他們的藍圖進行操作，那麼管理者就會查看他們的計劃並從那裡進行修改。

客戶在看到工作軟件之前可能並不確切地知道他們的需求是什麼，因此會改變他們的需求，從而導致重新設計、重新開發和重新測試，並增加成本。

開發人員在設計新的軟件產品或功能時可能沒有意識到未來的困難，在這種情況下，最好修改設計而不是堅持不考慮任何新發現的約束、要求或問題的設計。

因此，不能保證組織所考慮的要求會真正起作用。從這裡，您會意識到瀑布模型存在以下問題：

1. 人們盲目地遵循計劃。

在傳統的方法中，人們更多地關注事情在正確的時刻會如何發生，而不去注意事情是否真的到位。雖然計劃很重要，但開發人員和質量檢查人員了解事情應該如何發生也很重要，尤其是與客戶或最終用戶。同樣重要的是，所有參與項目的人都可以立即說出項目執行中的特定步驟如何在無需等待測試階段的情況下崩潰。

2. 順序流程和變更成本高昂

這種方法沒有考慮到隨著項目的進展而改變定義的需求。因此，軟件很可能無法完全滿足用戶的需求，效率低下，功能差。

這是不夠的，因為開發人員不能隨著消費者需求的變化而返回並更改前一階段的某些內容，而是開發人員必須回到需求需要更改的地方並重新開始該階段。直到那個階段完成，他才能進入下一個階段。

3. 最終用戶不知道他們想要什麼。

大多數時候，最終用戶的想法是不斷變化的，大多數人對他們的軟件需求有一個模糊的概念，並且隨著軟件的發展，他們指定了他們的需求。

當到了將成品交給客戶的時候，他們很可能不喜歡結果，儘管在最初階段故意說不同。隨著時間的推移，客戶和最終用戶很容易改變他們想要的東西。瀑布系統還沒有辦法解決這個問題，而無需修改計劃並完全重做整個項目。

4. 質量測試可能會受到影響。

一個項目的結果是無法準確預測的，當整個團隊時間緊迫時，為了趕上最後期限，縮短測試階段是可能的。

5. 你永遠不知道自己真正處於什麼階段。

由於您嘗試創建的產品直到最後才會生產，因此您不確定您是否仍在計劃中或已經處於開發階段。這意味著由於能見度差，您在舞台上花費的時間也可能比您預期的要多。

最後，瀑布方法可能太冒險了，因為它太死板了。為了讓您生產出有效且足夠靈活的產品，以幫助您確定什麼有效或無效。