ibm rational 技術***
傅純一 ibm中國****軟體部rational中國區技術銷售經理
2004 年 9 月
1. 傳統開發流程的問題傳統的軟體開發流程是乙個文件驅動的流程，它將整個軟體開發過程劃分為順序相接的幾個階段，每個階段都必需完成全部規定的任務（文件）後才能夠進入下乙個階段。如必須完成全部的系統需求規格說明書之後才能夠進入概要設計階段，編碼必需在系統設計完成之後才能夠進行。這就意味著只有當所有的系統模組全部開發完成之後，我們才進行系統整合，對於乙個由上百個模組組的複雜系統來說，這是乙個非常艱鉅而漫長的工作。
隨著我們所開發的軟體專案越來越複雜，傳統的瀑布型開發流程不斷地暴露出以下問題：
在傳統的瀑布模型中，需求和設計中的問題是無法在專案開發的前期被檢測出來的，只有當第一次系統整合時，這些設計缺陷才會在測試中暴露出來，從而導致一系列的返工：重新設計、編碼、測試，進而導致專案的延期和開發成本的上公升。
2. 採用迭代化開發控制專案風險
為了解決傳統軟體開發流程中的問題，我們建議採用迭代化的開發方法來取代瀑布模型。在瀑布模型中，我們要完成的是整個軟體系統開發這個大目標。在迭代化的方法中，我們將整個專案的開發目標劃分成為一些更易於完成和達到的階段性小目標，這些小目標都有乙個定義明確的階段性評估標準。迭代就是為了完成一定的階段性目標而所從事的一系列開發活動，在每個迭代開始前都要根據專案當前的狀態和所要達到的階段性目標制定迭代計畫，整個迭代過程包含了需求、設計、實施（編碼）、部署、測試等各種型別的開發活動，迭代完成之後需要對迭代完成的結果進行評估，並以此為依據來制定下一次迭代的目標。
與傳統的瀑布式開發模型相比較，迭代化開發具有以下特點：
迭代化方法解決的主要是對於風險的控制問題，從下圖可以看出，傳統的開發流程中系統的風險要到專案開發的後期（主要是測試階段）才能夠被真正降低。而迭代化開發中的風險，可以在專案開發的早期通過幾次迭代來盡快地解決掉。在早期的迭代中一旦遇到問題，如某乙個迭代沒有完成預定的目標，我們還可以及時調整開發進度以保證專案按時完成。一般到了專案開發的後期（風險受控階段），由於大部分高風險的因素（如需求、架構、效能等）都已經解決，這時候只需要投入更多的資源去實現剩餘的需求即可。這個階段的專案開發具有很強的可控性，從而保證我們按時交付乙個高質量的軟體系統。
迭代化開發不是一種高深的軟體工程理論，它提供了一種控制專案風險的非常有效的機制。在日常的工作我們也經常地應用到這一基本思想，如對於乙個非常大型的工程專案，我們經常會把它分為幾期來分步實施，從而把複雜的問題分解為相對容易解決的小問題，並且能夠在較短週期內看到部分系統實現的效果，通過盡早暴露問題來幫助我們及早調整我們的開發資源，加強專案進度的可控程度，保證專案的按時完成。
3. 管理迭代化的軟體專案
當我們在實際工作中實踐迭代化思想時，rational統一開發流程rup(rational unified process)可以給予我們實踐的指導。rup是乙個通用的軟體流程框架，它是乙個以架構為中心、用例驅動的迭代化軟體開發流程。rup是從幾千個軟體專案的實踐經驗中總結出來的，對於實際的專案具有很強的指導意義，是軟體開發行業事實上的行業標準。
3.1 軟體開發的四個階段
在rup中，我們把軟體開發生命週期劃分為四個階段，每個階段的結束標誌就是乙個主要的里程碑（如下圖所示）。
這四個階段主要是為了達到以下階段性的目標里程碑：
每個目標里程碑都是乙個商業上的決策點，如先啟階段結束之後，我們就要決定這個專案是否可行、是否要繼續做這個專案。每乙個階段都是由里程碑來決定的，判斷乙個階段是否結束的標誌就是看專案當前的狀態是否滿足裡碑中所規定的條件。
從這種階段劃分模式中可以看出，專案的主要風險集中在前兩個階段。在精化階段中經過幾次迭代後，我們要為系統建立乙個穩定的架構，在此之後再實現更多的系統需求時，不再需要對該架構進行修改。同時，在精化階段中，我們通過迭代來不斷地收集使用者的需求反饋，便得系統的需求逐步地明確和完整。
3.2 關於開發資源的分配
基於rup風險驅動的迭代化開發模式，我們只需要在專案的先啟階段投入少量的資源，對專案的開發前景和商業可行性進行一些探索性的研究。在精化階段再投入多一些的研發力量來實現一些與架構相關的核心需求，逐步地把系統架構搭建起來。等到這兩個階段結束之後，專案的一些主要風險和問題也得到了解決，這時候再投入整個團隊進行全面的系統開發。等到產品化階段，主要的開發任務已經全部完成，專案不再需要維持乙個大規模的開發團隊，開發資源也可以隨之而減少。在專案開發周期中，開發資源的分配可以如下圖所示。
這樣安排可以最充分有效地利用公司的開發資源，緩解軟體公司對於人力資源不斷增長的需求，從而降低成本。另外一方面，由於前兩個階段（先啟和精化）的風險較高，我們只是投入部分的資源，一旦發生返工或是專案目標的改變，我們也可以將資源浪費降到最低點。在傳統的軟體開發流程中，對於開發資源的分配基本上是貫穿整個專案週期而不變的，資源往往沒有得到充分有效地利用。
基於這種資源分配模式，乙個典型的專案在專案進度和所完成的工作量之間的關係可能如下表中的資料所示。
先啟精化
構建產品化
工作量~5%
20%65%
10%進度
10%30%
50%10%
3.3 迭代策略
關於迭代計畫的安排，通常有以下四種典型的策略模式：
這幾種迭代策略只是一些典型模式的代表，實際應用中應根據實際情況靈活應用，最常見的迭代計畫往往是這幾種模式的組合。
3.4 制定專案開發計畫
在迭代化的開發模式中，專案開發計畫也是隨著專案的進展而不斷細化、調整並完善的。傳統的專案開發計畫是在專案早期制定的，專案經理總是試圖在專案的一開始就制定乙個非常詳細完善的開發計畫。與之相反，迭代開發模式認為在專案早期只需要制定乙個比較粗略的開發計畫，因為隨著專案的進展，專案的狀態在不斷地發生變化，專案經理需要隨時根據迭代的結果來對專案計畫進行調整，並制定下一次迭代的詳細計畫。
在rup中，我們把專案開發計畫分為以下三部分：
專案開發計畫也是完全體現迭代化的思想，每次迭代中專案經理都會根據專案情況來不斷地調整和細化專案開發計畫。迭代計畫是在對上一次迭代結果進行評估的基礎上制定的，如果上一次迭代達到了預定的目標，那麼當前迭代只需要解決剩下的問題；如果上一次迭代中留有一些問題還沒有解決，則當前迭代還需要繼續去解決這些問題。所以必須注意，迭代是不能重疊的，即你還沒有完成當前迭代時，你決不能進入下一迭代，因為下一次迭代的計畫是根據當前迭代的結果而制定的。
迭代化軟體開發技術
ibm rational 技術 傅純一 ibm中國 軟體部rational中國區技術銷售經理 2004 年 9 月 1.傳統開發流程的問題 傳統的軟體開發流程是乙個文件驅動的流程，它將整個軟體開發過程劃分為順序相接的幾個階段，每個階段都必需完成全部規定的任務 文件 後才能夠進入下乙個階段。如必須完成...
迭代軟體開發
迭代軟體開發 整理 一 迭代軟體開發介紹 在迭代式開發方法中，整個開發工作被組織為一系列的短小的 固定長度 如 3周 的小專案，被稱為一系列的迭代。每一次迭代都包括了需求分 析 設計 實現與測試。採用這種方法，開發工作可以在需求被完整地確定之前啟動，並在一次迭代中完成系統的一部分功能或業務邏輯的開發...
迭代式軟體開發也有陷阱
迭代式 iterative 軟體開發似乎已經成為了目前業內被證明最有效的開發方式，不管是微軟模式，還是rup或者xp，還有別的個別公司和個人嚐到的模式，除去具體細節上的差別，核心思想都是迭代。這世界上道理是想通的，摸著石頭過河 也就是迭代式的思想，走一步看看情況如何，然後決定下一步怎麼走。迭代式開發...