迭代軟件開發(fā)流程

1、1. 傳統(tǒng)開發(fā)流程的問題傳統(tǒng)的 軟件開發(fā)流程是一個文檔驅動的流程，它將整個軟件開發(fā)過程劃分為順序相接的幾個階段，每個階段 都必需完成全部規(guī)定的任務文檔后才能夠進入下一個階段。如必須完成全部的系統(tǒng)需求規(guī)格說明書之后才能夠進入概要設計階段，編碼必需在系統(tǒng)設計完成之后才能夠進行。這就意味著只有當所有的系統(tǒng)模塊全部 開發(fā)完成之 后，我們才進行系統(tǒng)集成，對于一個由上百個模塊組的復雜系統(tǒng)來說，這是一個非常艱巨而漫長 的工作。傳統(tǒng)的開發(fā)昶_瀑布模型隨著我們所開發(fā)的軟件工程越來越復雜，傳統(tǒng)的瀑布型開發(fā)流程不斷地暴露岀以下問題:需求或設計中的錯誤往往只有到了工程后期才能夠被發(fā)現(xiàn)例如：系統(tǒng)交付客戶之后才發(fā)現(xiàn)原先對

2、于需 求的理解是錯誤的，系統(tǒng)設計中的問題要到測試階段才能被發(fā)現(xiàn)。對于工程風險的控制能力較弱工程風險在工程開發(fā)較晚的時候才能夠真正降低，往往是經(jīng)過系統(tǒng)測試 之后，才能確定該設計是否能夠真正滿足系統(tǒng)需求。軟件工程常常延期完成或開發(fā)費用超岀預算工程開發(fā)進度往往會被意外發(fā)生的問題所打亂，需要進行 返工或其他一些額外的開發(fā)周期，造成工程延期或費用超支。工程管理人員專注于文檔的完成和審核來估計工程的進展情況所以工程經(jīng)理對于工程狀態(tài)的估計往往 是不準確的，當他答復系統(tǒng)已完成了80%的開發(fā)任務時，剩下 20%的開發(fā)任務實際上消耗的是整個項目80%的開發(fā)資源。在傳統(tǒng)的瀑布模型中，需求和設計中的問題是無法在工程開

3、發(fā)的前期被檢測岀來的，只有當?shù)谝淮蜗到y(tǒng)集成 時，這些設計缺陷才會在測試中暴露岀來，從而導致一系列的返工：重新設計、編碼、測試，進而導致工程的 延期和開發(fā)本錢的上升。傳統(tǒng)瀑布模型的問題*碾戦才康廉軼呻陽* m的幵豹S力je在較科冊E2. 采用迭代化開發(fā)控制工程風險為了解決傳統(tǒng)軟件開發(fā)流程中的問題，我們建議采用迭代化的開發(fā)方法來取代瀑布模型。在瀑布模型中，我 們要完成的是整個軟件系統(tǒng)開發(fā)這個大目標。在迭代化的方法中，我們將整個工程的開發(fā)目標劃分成為一些更易于完成和到達的階段性小目標，這些小目標都有一個定義明確的階段性評估標準。迭代就是為了完成一定 的階段 性目標而所從事的一系列開發(fā)活動，在每個迭代

4、開始前都要根據(jù)工程當前的狀態(tài)和所要到達的階段性 目標制定迭代方案，整個迭代過程包含了需求、設計、實施編碼、部署、測試等各種類型的開發(fā)活動，迭代完成之后需要對迭代完成的結果進行評估，并以此為依據(jù)來制定下一次迭代的目標。與傳統(tǒng)的瀑布式開發(fā)模型相比擬，迭代化開發(fā)具有以下特點:允許變更需求需求總是會變化，這是事實。給工程帶來麻煩的常常主要是需求變化和需求"蠕變"，它們會導致延期交付、工期延誤、客戶不滿 意、開發(fā)人員受挫。通過向用戶演示迭代所產(chǎn)生的局部系統(tǒng)功能，我們可以 盡早地收集用戶對于系統(tǒng)的反應，及時改正對于用戶需求的理解偏差，從而保證開發(fā)出來 的系統(tǒng)真正 地解決客戶的問題。逐步

5、集成元素 在傳統(tǒng)的工程開發(fā)中，由于要求一下子集成系統(tǒng)中所有的模塊，集成階段往往要占到整個工程很大比例 的工作量最 高可達 40% ，這一階段的工作經(jīng)常是不確定并且非常棘手。在迭代式方法中，集成可 以說是連續(xù)不斷的，每一次迭代都會增量式集成一些新的系統(tǒng)功能，要集成 的元素都比過去少得多， 所以工作量和難度都是比擬低的。盡早降低風險 迭代化開發(fā)的主要指導原那么就是以架構為中心，在早期的迭代中所要解決的主要問題就是盡快確定系統(tǒng) 架構，通過幾 次迭代來盡快地設計出能夠滿足核心需求的系統(tǒng)架構，這樣可以迅速降低整個工程的風 險。等到系統(tǒng)架構穩(wěn)定之后，工程的風險就比擬低了，這個時候再去實現(xiàn)系統(tǒng) 中尚未完成的

6、功能，進 而完成整個工程。有助于提高團隊的士氣 開發(fā)人員通過每次迭代都可以在短期內看到自己的工作成果，從而有助于他們增強信心，更好地完成開 發(fā)任務。而在非迭代式開發(fā)中，開發(fā)人員只有在工程接近尾聲時才能看到開發(fā)的結果，在此之前的相當 長時間，大家還是在不確定性中摸索前近。生成更高質量的產(chǎn)品 每次迭代都會產(chǎn)生一個可運行的系統(tǒng)，通過對這個可運行系統(tǒng)進行測試，我們在早期的迭代中就可以及 時發(fā)現(xiàn)缺陷并改正，性能上的瓶頸也可以盡早發(fā)現(xiàn)并處理。因為在每次迭代中總是不斷地糾正錯誤，我 們可以得到更高質量的產(chǎn)品。保證工程開發(fā)進度 每次迭代結束時都會進行評估，來判斷該次迭代有沒有到達預定的目標。工程經(jīng)理可以很清楚

7、地知道有 哪些需求已經(jīng)實現(xiàn)了，并且比擬準確地估計工程的狀態(tài)，對工程的開發(fā)進度進行必要的調整，保證工程 按時完成。容許產(chǎn)品進行戰(zhàn)術改變 迭代化的開發(fā)具有更大的靈活性，在迭代過程中可以隨時根據(jù)業(yè)務情況或市場環(huán)境來對產(chǎn)品的開發(fā)進行 調整。例如為了同現(xiàn)有的同類產(chǎn)品競爭，可以決定采用搶先競爭對手一步的方法，提前發(fā)布一個功能簡 化的產(chǎn)品。迭代流程自身可在進行過程中得到改良和精煉 一次迭代結束時的評估不僅要從產(chǎn)品和進度的角度來考察工程的情況，而且還要分析組織和流程本身有 什么待改良之處，以便在下次迭代中更好地完成任務。迭代化方法解決的主要是對于風險的控制問題，從以下列圖可以看岀，傳統(tǒng)的開發(fā)流程中系統(tǒng)的風險要

8、到工程開 發(fā)的后期主要是測試階段才能夠被真正降低。而迭代化開發(fā)中的風險，可以在工程開發(fā)的早期通過幾次迭代來盡快地解決掉。在早期的迭代中一旦遇到問題，如某一個迭代沒有完成預定的目標，我們還可以及時 調整開發(fā)進度以保證工程按時完成。一般到了工程開發(fā)的后期風險受控階段，由于大局部高風險的因素如需求、架構、性能等都已經(jīng)解決，這時候只需要投入更多的資源去實現(xiàn)剩余的需求即可。這個階段的工程開發(fā)具有很強的可控性，從而保證我們按時交付一個高質量的軟件系統(tǒng)。風臉RK風隍受:控階段揉索階段解訣航段迭代化開發(fā)不是一種高深的軟件工程理論，它提供了一種控制工程風險的非常有效的機制。在日常的工作我們 也經(jīng)常地應用到這一根

9、本思想，如對于一個非常大型的工程工程，我們經(jīng)常會把它分為幾期來分步實施，從而把復雜的問題分解為相對容易解決的小問題，并且能夠在較短周期內看到局部系統(tǒng)實現(xiàn)的效果，通過盡早暴露問題來幫助我們及早調整我們的開發(fā)資源，加強工程進度的可控程度，保證工程的按時完成。3. 管理迭代化的軟件工程當我們在實際工作中實踐迭代化思想時，Rational統(tǒng)一開發(fā)流程 RUP(Rational Unified Process)可以給予我們實踐的指導。RUP是一個通用的軟件流程框架，它是一個以架構為中心、用例驅動的迭代化軟件開發(fā)流 程。RUP是從幾千個軟件 工程的實踐經(jīng)驗中總結岀來的，對于實際的工程具有很強的指導意義，是

10、軟件開發(fā) 行業(yè)事實上的行業(yè)標準。3.1軟件開發(fā)的四個階段在RUP中，我們把軟件開發(fā)生命周期劃分為四個階段，每個階段的結束標志就是一個主要的里程碑如以下 圖所示。先啟| 精優(yōu) |構建|產(chǎn)吊北|主命周期T 生箱周朗T 產(chǎn)品發(fā)布目標星區(qū)碗性襤里懼瑋這四個階段主要是為了到達以下階段性的目標里程碑:先啟(Inception):確定工程開發(fā)的目標和范圍?精化(Elaboration):確定系統(tǒng)架構和明確需求?構建(Construction):實現(xiàn)剩余的系統(tǒng)功能?產(chǎn)品化仃ransition)：完成軟件的產(chǎn)品化工作，將系統(tǒng)移交給客戶每個目標里程碑都是一個商業(yè)上的決策點，如先啟階段結束之后，我們就要決定這個工程

11、是否可行、是否要繼 續(xù)做這個工程。每一個階段都是由里程碑來決定的，判斷一個階段是否結束的標志就是看工程當前的狀態(tài)是否 滿足里碑中所規(guī)定的條件。從這種階段劃分模式中可以看岀，工程的主要風險集中在前兩個階段。在精化階段中經(jīng)過幾次迭代后，我們要 為系統(tǒng)建立一個穩(wěn)定的架構，在此之后再實現(xiàn)更多的系統(tǒng)需求時，不再需要對該架構進行修改。同時，在精化階段中，我們通過迭代來不斷地收集用戶的需求反應，便得系統(tǒng)的需求逐步地明確和完整。3.2關于開發(fā)資源的分配基于RUP風險驅動的迭代化開發(fā)模式，我們只需要在工程的先啟階段投入少量的資源，對工程的開發(fā)前景和 商業(yè)可行性進行一些探索性的研究。在精化階段再投入多一些的研發(fā)力

12、量來實現(xiàn)一些與架構相關的核心需求，逐步地把系統(tǒng)架構搭建起來。等到這兩個階段結束之后，工程的一些主要風險和問題也得到了解決，這時 候再投入整個團隊進行全面的系統(tǒng)開發(fā)。等到產(chǎn)品化階段，主要的開發(fā)任務已經(jīng)全部完成，工程不再需要維 持一個大規(guī)模的開發(fā)團隊，開發(fā)資源也可以隨之而減少。在工程開發(fā)周期中，開發(fā)資源的分配可以如以下列圖所示。這樣安排可以最充分有效地利用公司的開發(fā)資源，緩解軟件公司對于人力資源不斷增長的需求，從而降低成 本。另外一方面，由于前兩個階段先啟和精化的風險較高，我們只是投入局部的資源，一旦發(fā)生返工或是工程目標的改變，我們也可以將資源浪費降到最低點。在傳統(tǒng)的軟件開發(fā)流程中，對于開發(fā)資源的

13、分配基 本上是貫穿整個工程周期而不變的，資源往往沒有得到充分有效地利用?；谶@種資源分配模式，一個典型的工程在工程進度和所完成的工作量之間的關系可能如下表中的數(shù)據(jù)所示。1 1先啟精化構建產(chǎn)品化工作量5%20%65%10%進度110%30%50%10%3.3迭代策略關于迭代方案的安排，通常有以下四種典型的策略模式：? 增量式(Incremental)這種模式的特點是工程架構的風險較小往往是開發(fā)一些重復性的工程，所以精化階段只需要一個迭 代。但工程的開發(fā)工作量較大，構建階段需要有屢次迭代來實現(xiàn)，每次迭代都在上一次迭代的根底上增 加實現(xiàn)一局部的系統(tǒng)功能，通過迭代的進行而逐步實現(xiàn)整個系統(tǒng)的功能。? 演

14、進式(Evolutionary)當工程架構的風險較大時從未開發(fā)過類似工程，需要在精化階段通過屢次迭代來建立系統(tǒng)的架構， 架構是通過屢次迭代的探索，逐步演化而來的。當架構建立時，往往系統(tǒng)的功能也已經(jīng)根本實現(xiàn)，所以 構建階段只需要一次迭代。?增量提交 (Incremental Delivery)這種模式的特點產(chǎn)品化階段的迭代較多，比擬常見的例子是工程的難度并不 大，但業(yè)務需求在不斷地 發(fā)生變化，所以需要通過迭代來不斷地部署完成的系統(tǒng)；但同時又要不斷地收集用戶的反應來完善系統(tǒng) 需求，并通過后續(xù)的迭代來補充實現(xiàn) 這些需求。應用這種策略時要求系統(tǒng)架構非常穩(wěn)定，能夠適應滿 足后續(xù)需求變化的要求。?單次迭代

15、 (Grand Design)傳統(tǒng)的瀑布模型可以看作是迭代化開發(fā)的一個特例，整個開發(fā)流程只有一次迭代。但這種模式有一個固 有的弱點，由于它對風險的控制能力較差，往往會在產(chǎn)品化階段產(chǎn)生一些額外的迭代，造成工程的延 誤。這幾種迭代策略只是一些典型模式的代表，實際應用中應根據(jù)實際情況靈活應用，最常見的迭代方案往往是這 幾種模式的組合。3.4 制定工程開發(fā)方案在迭代 化的開發(fā)模式中，工程開發(fā)方案也是隨著工程的進展而不斷細化、調整并完善的。傳統(tǒng)的工程開發(fā)計 劃是在工程早期制定的，工程經(jīng)理總是試圖在工程的一開始就制 定一個非常詳細完善的開發(fā)方案。與之相 反，迭代開發(fā)模式認為在工程早期只需要制定一個比擬粗略的開發(fā)方案，因為隨著工程的進展，工程的狀態(tài)在 不斷地發(fā)生變 化，工程經(jīng)理需要隨時根據(jù)迭代的結果來對工程方案進行調整，并制定下一次迭代的詳細計 劃。在 RUP 中，我們把工程開發(fā)方案分為以下三局部：? 工程方案 確定整個工程的開發(fā)目標和進度安排，包括每一個階段的起止時間段。? 階段方案 當前階段中包含有幾個迭代，每一次迭代要到達的目標以及進度安排。? 迭代方案 針對當前