1. 傳統開發流程的問題 
傳統的軟件開發流程是一個文檔驅動的流程，它將整個軟件開發過程劃分為順序相接的幾個階段，每個階段都必需完成全部規定的任務（文檔）后才能夠進入下一個階段。如必須完成全部的系統需求規格說明書之后才能夠進入概要設計階段，編碼必需在系統設計完成之后才能夠進行。這就意味著只有當所有的系統模塊全部開發完成之后，我們才進行系統集成，對于一個由上百個模塊組的復雜系統來說，這是一個非常艱巨而漫長的工作。
 

隨著我們所開發的軟件項目越來越復雜，傳統的瀑布型開發流程不斷地暴露出以下問題：

（1）需求或設計中的錯誤往往只有到了項目后期才能夠被發現例如：系統交付客戶之后才發現原先對于需求的理解是錯誤的，系統設計中的問題要到測試階段才能被發現。
（2）對于項目風險的控制能力較弱項目風險在項目開發較晚的時候才能夠真正降低，往往是經過系統測試之后，才能確定該設計是否能夠真正滿足系統需求。
（3）軟件項目常常延期完成或開發費用超出預算項目開發進度往往會被意外發生的問題所打亂，需要進行返工或其他一些額外的開發周期，造成項目延期或費用超支。
（4）項目管理人員專注于文檔的完成和審核來估計項目的進展情況所以項目經理對于項目狀態的估計往往是不準確的，當他回答系統已完成了80%的開發任務時，剩下20%的開發任務實際上消耗的是整個項目80%的開發資源。

在傳統的瀑布模型中，需求和設計中的問題是無法在項目開發的前期被檢測出來的，只有當第一次系統集成時，這些設計缺陷才會在測試中暴露出來，從而導致一系列的返工：重新設計、編碼、測試，進而導致項目的延期和開發成本的上升。

2. 采用迭代化開發控制項目風險 
為了解決傳統軟件開發流程中的問題，我們建議采用迭代化的開發方法來取代瀑布模型。在瀑布模型中，我們要完成的是整個軟件系統開發這個大目標。在迭代化的方法中，我們將整個項目的開發目標劃分成為一些更易于完成和達到的階段性小目標，這些小目標都有一個定義明確的階段性評估標準。迭代就是為了完成一定的階段性目標而所從事的一系列開發活動，在每個迭代開始前都要根據項目當前的狀態和所要達到的階段性目標制定迭代計劃，整個迭代過程包含了需求、設計、實施（編碼）、部署、測試等各種類型的開發活動，迭代完成之后需要對迭代完成的結果進行評估，并以此為依據來制定下一次迭代的目標。

 與傳統的瀑布式開發模型相比較，迭代化開發具有以下特點：

（1）允許變更需求

需求總是會變化，這是事實。給項目帶來麻煩的常常主要是需求變化和需求"蠕變"，它們會導致延期交付、工期延誤、客戶不滿意、開發人員受挫。通過向用戶演示迭代所產生的部分系統功能，我們可以盡早地收集用戶對于系統的反饋，及時改正對于用戶需求的理解偏差，從而保證開發出來的系統真正地解決客戶的問題。

（2）逐步集成元素

在傳統的項目開發中，由于要求一下子集成系統中所有的模塊，集成階段往往要占到整個項目很大比例的工作量（最高可達40%），這一階段的工作經常是不確定并且非常棘手。在迭代式方法中，集成可以說是連續不斷的，每一次迭代都會增量式集成一些新的系統功能，要集成的元素都比過去少得多，所以工作量和難度都是比較低的。

（3）盡早降低風險

迭代化開發的主要指導原則就是以架構為中心，在早期的迭代中所要解決的主要問題就是盡快確定系統架構，通過幾次迭代來盡快地設計出能夠滿足核心需求的系統架構，這樣可以迅速降低整個項目的風險。等到系統架構穩定之后，項目的風險就比較低了，這個時候再去實現系統中尚未完成的功能，進而完成整個項目。