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

隨著我們所開發(fā)的軟件項目越來越復(fù)雜,，傳統(tǒng)的瀑布型開發(fā)流程不斷地暴露出以下問題：

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

在傳統(tǒng)的瀑布模型中，需求和設(shè)計中的問題是無法在項目開發(fā)的前期被檢測出來的,，只有當(dāng)?shù)谝淮蜗到y(tǒng)集成時,，這些設(shè)計缺陷才會在測試中暴露出來，從而導(dǎo)致一系列的返工：重新設(shè)計,、編碼,、測試,，進而導(dǎo)致項目的延期和開發(fā)成本的上升,。

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

與傳統(tǒng)的瀑布式開發(fā)模型相比較,，迭代化開發(fā)具有以下特點：

• 允許變更需求
  需求總是會變化,，這是事實。給項目帶來麻煩的常常主要是需求變化和需求"蠕變",，它們會導(dǎo)致延期交付,、工期延誤、客戶不滿意,、開發(fā)人員受挫,。通過向用戶演示迭代所產(chǎn)生的部分系統(tǒng)功能，我們可以盡早地收集用戶對于系統(tǒng)的反饋,，及時改正對于用戶需求的理解偏差,，從而保證開發(fā)出來的系統(tǒng)真正地解決客戶的問題,。
• 逐步集成元素
  在傳統(tǒng)的項目開發(fā)中,，由于要求一下子集成系統(tǒng)中所有的模塊,，集成階段往往要占到整個項目很大比例的工作量（最高可達40%），這一階段的工作經(jīng)常是不確定并且非常棘手,。在迭代式方法中,，集成可以說是連續(xù)不斷的,，每一次迭代都會增量式集成一些新的系統(tǒng)功能，要集成的元素都比過去少得多,，所以工作量和難度都是比較低的,。
• 盡早降低風(fēng)險
  迭代化開發(fā)的主要指導(dǎo)原則就是以架構(gòu)為中心，在早期的迭代中所要解決的主要問題就是盡快確定系統(tǒng)架構(gòu),，通過幾次迭代來盡快地設(shè)計出能夠滿足核心需求的系統(tǒng)架構(gòu),，這樣可以迅速降低整個項目的風(fēng)險。等到系統(tǒng)架構(gòu)穩(wěn)定之后,，項目的風(fēng)險就比較低了,，這個時候再去實現(xiàn)系統(tǒng)中尚未完成的功能，進而完成整個項目,。
• 有助于提高團隊的士氣
  開發(fā)人員通過每次迭代都可以在短期內(nèi)看到自己的工作成果,，從而有助于他們增強信心，更好地完成開發(fā)任務(wù),。而在非迭代式開發(fā)中,，開發(fā)人員只有在項目接近尾聲時才能看到開發(fā)的結(jié)果，在此之前的相當(dāng)長時間,，大家還是在不確定性中摸索前近,。
• 生成更高質(zhì)量的產(chǎn)品
  每次迭代都會產(chǎn)生一個可運行的系統(tǒng)，通過對這個可運行系統(tǒng)進行測試,，我們在早期的迭代中就可以及時發(fā)現(xiàn)缺陷并改正,，性能上的瓶頸也可以盡早發(fā)現(xiàn)并處理。因為在每次迭代中總是不斷地糾正錯誤,，我們可以得到更高質(zhì)量的產(chǎn)品,。
• 保證項目開發(fā)進度
  每次迭代結(jié)束時都會進行評估，來判斷該次迭代有沒有達到預(yù)定的目標(biāo),。項目經(jīng)理可以很清楚地知道有哪些需求已經(jīng)實現(xiàn)了,，并且比較準(zhǔn)確地估計項目的狀態(tài)，對項目的開發(fā)進度進行必要的調(diào)整,，保證項目按時完成,。
• 容許產(chǎn)品進行戰(zhàn)術(shù)改變
  迭代化的開發(fā)具有更大的靈活性，在迭代過程中可以隨時根據(jù)業(yè)務(wù)情況或市場環(huán)境來對產(chǎn)品的開發(fā)進行調(diào)整,。例如為了同現(xiàn)有的同類產(chǎn)品競爭,，可以決定采用搶先競爭對手一步的方法,，提前發(fā)布一個功能簡化的產(chǎn)品。
• 迭代流程自身可在進行過程中得到改進和精煉
  一次迭代結(jié)束時的評估不僅要從產(chǎn)品和進度的角度來考察項目的情況,，而且還要分析組織和流程本身有什么待改進之處,，以便在下次迭代中更好地完成任務(wù)。

迭代化方法解決的主要是對于風(fēng)險的控制問題,，從下圖可以看出,，傳統(tǒng)的開發(fā)流程中系統(tǒng)的風(fēng)險要到項目開發(fā)的后期（主要是測試階段）才能夠被真正降低。而迭代化開發(fā)中的風(fēng)險,，可以在項目開發(fā)的早期通過幾次迭代來盡快地解決掉,。在早期的迭代中一旦遇到問題，如某一個迭代沒有完成預(yù)定的目標(biāo),，我們還可以及時調(diào)整開發(fā)進度以保證項目按時完成,。一般到了項目開發(fā)的后期（風(fēng)險受控階段），由于大部分高風(fēng)險的因素（如需求,、架構(gòu),、性能等）都已經(jīng)解決，這時候只需要投入更多的資源去實現(xiàn)剩余的需求即可,。這個階段的項目開發(fā)具有很強的可控性,，從而保證我們按時交付一個高質(zhì)量的軟件系統(tǒng)。

迭代化開發(fā)不是一種高深的軟件工程理論,，它提供了一種控制項目風(fēng)險的非常有效的機制,。在日常的工作我們也經(jīng)常地應(yīng)用到這一基本思想，如對于一個非常大型的工程項目,，我們經(jīng)常會把它分為幾期來分步實施,，從而把復(fù)雜的問題分解為相對容易解決的小問題，并且能夠在較短周期內(nèi)看到部分系統(tǒng)實現(xiàn)的效果,，通過盡早暴露問題來幫助我們及早調(diào)整我們的開發(fā)資源,，加強項目進度的可控程度，保證項目的按時完成,。

3. 管理迭代化的軟件項目
當(dāng)我們在實際工作中實踐迭代化思想時，Rational統(tǒng)一開發(fā)流程RUP(Rational Unified Process)可以給予我們實踐的指導(dǎo),。RUP是一個通用的軟件流程框架,，它是一個以架構(gòu)為中心、用例驅(qū)動的迭代化軟件開發(fā)流程,。RUP是從幾千個軟件項目的實踐經(jīng)驗中總結(jié)出來的,，對于實際的項目具有很強的指導(dǎo)意義，是軟件開發(fā)行業(yè)事實上的行業(yè)標(biāo)準(zhǔn),。

3.1 軟件開發(fā)的四個階段
在RUP中,，我們把軟件開發(fā)生命周期劃分為四個階段,，每個階段的結(jié)束標(biāo)志就是一個主要的里程碑（如下圖所示）。

這四個階段主要是為了達到以下階段性的目標(biāo)里程碑：

• 先啟(Inception)：確定項目開發(fā)的目標(biāo)和范圍
• 精化(Elaboration)：確定系統(tǒng)架構(gòu)和明確需求
• 構(gòu)建(Construction)：實現(xiàn)剩余的系統(tǒng)功能
• 產(chǎn)品化(Transition)：完成軟件的產(chǎn)品化工作,，將系統(tǒng)移交給客戶

每個目標(biāo)里程碑都是一個商業(yè)上的決策點,，如先啟階段結(jié)束之后，我們就要決定這個項目是否可行,、是否要繼續(xù)做這個項目,。每一個階段都是由里程碑來決定的，判斷一個階段是否結(jié)束的標(biāo)志就是看項目當(dāng)前的狀態(tài)是否滿足里碑中所規(guī)定的條件,。

從這種階段劃分模式中可以看出,，項目的主要風(fēng)險集中在前兩個階段。在精化階段中經(jīng)過幾次迭代后,，我們要為系統(tǒng)建立一個穩(wěn)定的架構(gòu),，在此之后再實現(xiàn)更多的系統(tǒng)需求時，不再需要對該架構(gòu)進行修改,。同時,，在精化階段中，我們通過迭代來不斷地收集用戶的需求反饋,，便得系統(tǒng)的需求逐步地明確和完整,。

3.2 關(guān)于開發(fā)資源的分配
基于RUP風(fēng)險驅(qū)動的迭代化開發(fā)模式，我們只需要在項目的先啟階段投入少量的資源,，對項目的開發(fā)前景和商業(yè)可行性進行一些探索性的研究,。在精化階段再投入多一些的研發(fā)力量來實現(xiàn)一些與架構(gòu)相關(guān)的核心需求，逐步地把系統(tǒng)架構(gòu)搭建起來,。等到這兩個階段結(jié)束之后,，項目的一些主要風(fēng)險和問題也得到了解決，這時候再投入整個團隊進行全面的系統(tǒng)開發(fā),。等到產(chǎn)品化階段,，主要的開發(fā)任務(wù)已經(jīng)全部完成，項目不再需要維持一個大規(guī)模的開發(fā)團隊,，開發(fā)資源也可以隨之而減少,。在項目開發(fā)周期中，開發(fā)資源的分配可以如下圖所示,。

這樣安排可以最充分有效地利用公司的開發(fā)資源,，緩解軟件公司對于人力資源不斷增長的需求，從而降低成本,。另外一方面,，由于前兩個階段（先啟和精化）的風(fēng)險較高，我們只是投入部分的資源,，一旦發(fā)生返工或是項目目標(biāo)的改變,，我們也可以將資源浪費降到最低點,。在傳統(tǒng)的軟件開發(fā)流程中，對于開發(fā)資源的分配基本上是貫穿整個項目周期而不變的,，資源往往沒有得到充分有效地利用,。

基于這種資源分配模式，一個典型的項目在項目進度和所完成的工作量之間的關(guān)系可能如下表中的數(shù)據(jù)所示,。

3.3 迭代策略
關(guān)于迭代計劃的安排,，通常有以下四種典型的策略模式：

• 增量式(Incremental)
  這種模式的特點是項目架構(gòu)的風(fēng)險較小（往往是開發(fā)一些重復(fù)性的項目）,，所以精化階段只需要一個迭代,。但項目的開發(fā)工作量較大，構(gòu)建階段需要有多次迭代來實現(xiàn),，每次迭代都在上一次迭代的基礎(chǔ)上增加實現(xiàn)一部分的系統(tǒng)功能,，通過迭代的進行而逐步實現(xiàn)整個系統(tǒng)的功能。
• 演進式(Evolutionary)
  當(dāng)項目架構(gòu)的風(fēng)險較大時（從未開發(fā)過類似項目）,，需要在精化階段通過多次迭代來建立系統(tǒng)的架構(gòu),，架構(gòu)是通過多次迭代的探索，逐步演化而來的,。當(dāng)架構(gòu)建立時,，往往系統(tǒng)的功能也已經(jīng)基本實現(xiàn)，所以構(gòu)建階段只需要一次迭代,。
• 增量提交(Incremental Delivery)
  這種模式的特點產(chǎn)品化階段的迭代較多,，比較常見的例子是項目的難度并不大，但業(yè)務(wù)需求在不斷地發(fā)生變化,，所以需要通過迭代來不斷地部署完成的系統(tǒng),；但同時又要不斷地收集用戶的反饋來完善系統(tǒng)需求，并通過后續(xù)的迭代來補充實現(xiàn)這些需求,。應(yīng)用這種策略時要求系統(tǒng)架構(gòu)非常穩(wěn)定,，能夠適應(yīng)滿足后續(xù)需求變化的要求。
• 單次迭代(Grand Design)
  傳統(tǒng)的瀑布模型可以看作是迭代化開發(fā)的一個特例,，整個開發(fā)流程只有一次迭代,。但這種模式有一個固有的弱點，由于它對風(fēng)險的控制能力較差,，往往會在產(chǎn)品化階段產(chǎn)生一些額外的迭代,，造成項目的延誤。

這幾種迭代策略只是一些典型模式的代表,，實際應(yīng)用中應(yīng)根據(jù)實際情況靈活應(yīng)用，最常見的迭代計劃往往是這幾種模式的組合,。

3.4 制定項目開發(fā)計劃
在迭代化的開發(fā)模式中,，項目開發(fā)計劃也是隨著項目的進展而不斷細化,、調(diào)整并完善的。傳統(tǒng)的項目開發(fā)計劃是在項目早期制定的,，項目經(jīng)理總是試圖在項目的一開始就制定一個非常詳細完善的開發(fā)計劃,。與之相反，迭代開發(fā)模式認(rèn)為在項目早期只需要制定一個比較粗略的開發(fā)計劃,，因為隨著項目的進展,，項目的狀態(tài)在不斷地發(fā)生變化，項目經(jīng)理需要隨時根據(jù)迭代的結(jié)果來對項目計劃進行調(diào)整,，并制定下一次迭代的詳細計劃,。

在RUP中，我們把項目開發(fā)計劃分為以下三部分：

• 項目計劃
  確定整個項目的開發(fā)目標(biāo)和進度安排,，包括每一個階段的起止時間段,。
• 階段計劃
  當(dāng)前階段中包含有幾個迭代，每一次迭代要達到的目標(biāo)以及進度安排,。
• 迭代計劃
  針對當(dāng)前迭代的詳細開發(fā)計劃,，包括開發(fā)活動以及相關(guān)資源的分配。

項目開發(fā)計劃也是完全體現(xiàn)迭代化的思想,，每次迭代中項目經(jīng)理都會根據(jù)項目情況來不斷地調(diào)整和細化項目開發(fā)計劃,。迭代計劃是在對上一次迭代結(jié)果進行評估的基礎(chǔ)上制定的，如果上一次迭代達到了預(yù)定的目標(biāo),，那么當(dāng)前迭代只需要解決剩下的問題,；如果上一次迭代中留有一些問題還沒有解決，則當(dāng)前迭代還需要繼續(xù)去解決這些問題,。所以必須注意,，迭代是不能重疊的，即你還沒有完成當(dāng)前迭代時,，你決不能進入下一迭代,，因為下一次迭代的計劃是根據(jù)當(dāng)前迭代的結(jié)果而制定的。

1. 引言
本文對 Rational 軟件開發(fā)過程（Rational Software Development Process）的原理和結(jié)構(gòu)給出了高度的描述,，它是：

• 迭代的,、增量的開發(fā)過程
• 面向?qū)ο蟮拈_發(fā)過程
• 管理和控制的開發(fā)過程

它具有足夠的普遍性，可以在規(guī)模與應(yīng)用領(lǐng)域方面,，為各個軟件產(chǎn)品和項目量身訂做,。

2.總體軟件生命周期

2.1 兩種視角
Rational 過程可以從兩種不同而又密不可分的視角來觀察：

• 從管理的視角來看，涉及財務(wù),、戰(zhàn)略,、商業(yè)和人文方面
• 從技術(shù)的視角來看，涉及質(zhì)量、工程和設(shè)計方法方面

2.2 周期和階段

從管理的角度,，即從業(yè)務(wù)和經(jīng)濟的角度來看,，對應(yīng)項目的進展，軟件的生命周期包含四個主要階段:

• 起始階段（Inception）-- 有一個好的想法：詳細構(gòu)想出最終產(chǎn)品的設(shè)想和它的業(yè)務(wù)案例,，確定項目的范圍 ,。
• 細化階段（Elaboration）--計劃必要的活動和所需資源，詳細確定功能并設(shè)計構(gòu)架 ,。
• 構(gòu)建階段（Construction）-- 構(gòu)建產(chǎn)品,， 發(fā)展最初的設(shè)想、構(gòu)架和計劃,，直到一個可以交付給用戶的產(chǎn)品（完成后的設(shè)想）完成,。
• 移交階段（Transition）-- 將產(chǎn)品移交用戶使用，包括：制造,、交付,、培訓(xùn)、支持,、維護,，直到用戶滿意。

完成這4個階段稱為一個開發(fā)周期, 它產(chǎn)生的軟件稱作第一代（generation）,。 除非產(chǎn)品的生命結(jié)束,， 一個現(xiàn)有產(chǎn)品可以通過重復(fù)下一個相同的起始、細化,、構(gòu)建和移交四階段,，各個階段的側(cè)重點與第一次不同，從而演進為下一代產(chǎn)品,。 這個時期我們稱之為演進(evolution),。最后伴隨著產(chǎn)品經(jīng)過幾個周期的演進，新一代產(chǎn)品也不斷被制造出來,。

例如,，演進周期的啟動可能由以下這幾項觸發(fā)：用戶建議增強功能、用戶環(huán)境的改變,、重要技術(shù)的變更,，以及應(yīng)對競爭的需要。

實際中,，周期之間會有輕微重疊：起始階段和細化階段可能會在上一個周期的移交階段未結(jié)束時就開始了,。

2.3. 迭代
從技術(shù)的角度來看，軟件開發(fā)可以視為一連串的迭代過程,，通過這些迭代被開發(fā)的軟件得以增量演進,。 每次迭代都以一個可執(zhí)行的產(chǎn)品的發(fā)布而結(jié)束， 該產(chǎn)品可能是完整版本的一個子集，但從工程的或用戶的角度來看是有用的,。 每次發(fā)布都伴隨一些支持性工件：版本描述,、用戶文檔和計劃等。

一次迭代包括以下活動： 計劃,、分析、設(shè)計,、實施和測試,。 根據(jù)迭代在開發(fā)周期中所處位置的不同，這些活動分別占不同的比例,。

管理角度和技術(shù)角度之間是協(xié)調(diào)的,， 而且各個階段的結(jié)束還和各次迭代的結(jié)束保持同步。

換句話說,，每個階段可以分為一次或多次迭代過程,。

(注意：本圖中每階段的迭代數(shù)目僅為示意)

但是，這兩個角度（管理角度和技術(shù)角度）,，不僅僅只是保持同步,，它們還具有一些完全相同的里程碑，它們共同貢獻出一些隨時間演進的產(chǎn)品和工件,。 一些工件更多地處于技術(shù)方面控制之下,，另一些工件更多地處于管理方面的控制之下。見第五節(jié),。

這些工件的可用性,、工件是否滿足所建立的評估標(biāo)準(zhǔn)，是構(gòu)成里程碑的主要具體元素,，比日歷牌上的日期提供了多得多的內(nèi)容,。

像周期一樣，迭代之間也會有輕微重疊,。即第N次迭代的計劃和構(gòu)架在第N-1次迭代還未結(jié)束時就開始了,。有時候，迭代也會平行進行：一個工作于系統(tǒng)某一部分的小組,，可能在某個迭代內(nèi)沒有可交付的工件,。

2.4.區(qū)別
對于不同的項目而言，每個階段的側(cè)重點,，入口和出口準(zhǔn)則,，一個開發(fā)周期的各個工件，以及各次迭代的數(shù)目和長度都會不同,。這主要取決于作為過程判別式的的四個主要項目特征,。按照影響程度降序排列，它們是：

• 業(yè)務(wù)環(huán)境
  • 契約性工作，開發(fā)者基于給定的客戶規(guī)格說明只為該客戶開發(fā)軟件,。
  • 推測性開發(fā)或商業(yè)開發(fā),，開發(fā)者開發(fā)軟件以推向市場。
  • 內(nèi)部項目,， 開發(fā)者和客戶在同一個機構(gòu)中,。
• 軟件開發(fā)工作量的規(guī)模:
  按照一些度量標(biāo)準(zhǔn)來確定，比如 Delivered Source Instructions,，或功能點,、人-月數(shù)，或者只按照成本,。
• 新穎程度：
  對于軟件開發(fā)組織,，這個軟件新穎程度如何有多新，尤其是該軟件是否為第二次或更后面的周期,。這項區(qū)別包括了組織和過程的成熟度,、資產(chǎn)、技術(shù)水平,，當(dāng)前的技狀況，以及諸如組建并培訓(xùn)團隊,、獲取工具及其他資源這樣的問題,。
• 應(yīng)用類型，目標(biāo)領(lǐng)域：
  MIS,，命令和控制系統(tǒng), 嵌入式實時系統(tǒng), 軟件開發(fā)環(huán)境工具等等, 尤其時具體的應(yīng)用領(lǐng)域會給開發(fā)提出特殊的約束條件：安全性,、性能,、國際化,、內(nèi)存限制等。
  本文首先描述適用所有類型軟件開發(fā)的通用過程,，然后描述了一些有區(qū)別價值的特定過程實例,，并列舉了幾個例子。

2.5工作量和日程安排
各階段在工作量和時間安排上是不同的,。盡管由于不同項目類型之間相差會很大,，一個典型的中等規(guī)模項目的最初開發(fā)周期可以預(yù)計為下面的比率：

可以用下圖表示：

但是對于一個演進周期來說，起始階段和細化階段可能大大縮減,。使用特定工具和技術(shù)（如應(yīng)用程序構(gòu)建器）,，構(gòu)建階段可以遠遠小于起始階段和細化階段的總和。

3. Rational 過程的各個階段

3.1. 起始階段
這個階段產(chǎn)生一個預(yù)測產(chǎn)品的最初設(shè)想,，并將其轉(zhuǎn)換為一個實際的項目。本階段的目的是建立一個新產(chǎn)品或一次大的更新的業(yè)務(wù)案例,，并且指定項目的范圍,。

對于一個新產(chǎn)品的開發(fā)，本階段的主要結(jié)果是得到一個"做還是不做"的決定以進入下一階段,，并投入一定的時間和資金來詳細分析構(gòu)建什么,、能否構(gòu)建，以及如何構(gòu)建,。

對于一個現(xiàn)有產(chǎn)品的演進,，這會是一個簡短的階段， 主要看用戶或客戶的要求,、問題報告,，或是新的技術(shù)動態(tài)。

對于一個契約性的開發(fā),，是否進行項目的決定取決于在特定領(lǐng)域的經(jīng)驗,、以及組織在此領(lǐng)域的競爭力和市場情況。這里起始階段可以歸結(jié)為一個參加投標(biāo)的決定,，或投標(biāo)活動本身,。該決定可能是基于一個現(xiàn)有的研究原型，其結(jié)構(gòu)對最終軟件可能合適,，也可能不合適,。

入口準(zhǔn)則:

對于一項需要的描述，可以采用以下形式：

• 一份最初的設(shè)想
• 一個遺留系統(tǒng)
• 一份建議請求（An RFP --request for proposal)
• 先前一代的產(chǎn)品和一個增強要求清單
• 一些資產(chǎn)(軟件, 專門技能, 財務(wù)資產(chǎn))
• 一個概念原型或?qū)嵨锬Ｐ?

出口準(zhǔn)則：

• 一個初始的業(yè)務(wù)案例至少要包含以下內(nèi)容:
  • 對產(chǎn)品設(shè)想的明確表達即核心需求,，表述為功能,、范圍、性能,、容量和技術(shù)等,。
  • 成功標(biāo)準(zhǔn) (如收入的數(shù)目)
  • 最初的風(fēng)險評估
  • 完成細化階段所需的資源估算

通常在初試階段結(jié)束時,，我們將得到：

• 一個最初的域分析模型(完成大約10%-20%), 確定最關(guān)鍵的用例, 并且足以進行進構(gòu)架工作。
• 一個最初的構(gòu)架原型,，在這個階段可以是一個一次性原型

3.2. 細化階段
本階段的主要目的是更徹底地分析問題域,，定義構(gòu)架并使之穩(wěn)定，確定項目的最大風(fēng)險,。這樣在本階段結(jié)束時,，我們可以得到一個關(guān)于下2個階段如何工作的綜合計劃：

• 一個基于分析模型的基線產(chǎn)品設(shè)想（即最初的需求集合）。
• 至少對第一次構(gòu)建迭代的評價準(zhǔn)則,。
• 一個基線軟件構(gòu)架,。
• 開發(fā)和部署產(chǎn)品的必需資源，尤其是人員和工具,。
• 一份日程安排,。
• 足以對構(gòu)建階段的成本、日程安排和質(zhì)量做出"精確"的評估的一份風(fēng)險決議,。

在這個階段,，建立了一個可執(zhí)行的構(gòu)架原型；它至少實現(xiàn)了初始階段識別出的最關(guān)鍵的用例 ,，解決了項目的最大技術(shù)風(fēng)險,；根據(jù)范圍、規(guī)模,、風(fēng)險和項目新穎程度的不同構(gòu)架原型需要一次或多次迭代,。這是一個生成高質(zhì)量代碼（這些代碼成為架構(gòu)基線）的演進原型，但是也不排除開發(fā)出一個或幾個試探性的,、一次性原型,，以降低開發(fā)的風(fēng)險：對需求、可行性,、人機界面研究,、向投資者演示等的精化。在本階段的結(jié)束時,，仍然會產(chǎn)生一個"做還是不做"的決定,， 以確定是否要真正投資構(gòu)建這個產(chǎn)品（或參與合同項目的競標(biāo)）。

此時產(chǎn)生的計劃一定要足夠詳細,，風(fēng)險也必須充分降低,，可以對開發(fā)工作的完成進行精確的成本和日程估算。

入口準(zhǔn)則：

• 前一階段出口準(zhǔn)則所描述的產(chǎn)品和工件
• 被項目管理者和投資者認(rèn)可的計劃,，和細化階段所需的資源

出口準(zhǔn)則：

• 一份詳細的軟件開發(fā)計劃,，包含：
  • 更新后的風(fēng)險評估
  • 一份管理計劃
  • 一份人員配置計劃
  • 一份顯示迭代內(nèi)容和次數(shù)的階段計劃
  • 一份迭代計劃，詳細計劃下次迭代
  • 開發(fā)環(huán)境和所需的其他工具
  • 一份測試計劃
• 一個基線設(shè)想,，以對最終產(chǎn)品的一個評估準(zhǔn)則的集合的形式
• 用于評估構(gòu)建階段最初的迭代結(jié)果的客觀,、可測量的演進標(biāo)準(zhǔn)
• 一個域分析模型（80%完成）,，相應(yīng)的構(gòu)架可以稱之為是"完整的"
• 一個軟件構(gòu)架描述（說明約束和限制）
• 一個可執(zhí)行的構(gòu)架基線

3.3. 構(gòu)建階段
本階段可以劃分為數(shù)次迭代，不斷充實構(gòu)架基線,，向最終產(chǎn)品逐步演進或增量演進,。在每次迭代過程中，上個階段（細化階段）的工件得到擴充和修正,， 但它們最終將隨著系統(tǒng)向正確和完整的方向的演進而穩(wěn)定下來,。在這個階段，除了軟件本身,，還生成一些新的工件：文檔（既有內(nèi)部使用的文檔,，也有面向最終用戶的文檔）、測試床及測試套件,、部署附件,，以及用于支持下一階段的部署輔助（例如銷售輔助）。

對每次迭代,，都具有：

入口準(zhǔn)則：

• 上次迭代的產(chǎn)品和工件,。 迭代計劃必須闡明迭代的特定目標(biāo)：
  • 將要開發(fā)的新增功能，覆蓋了哪些用例或場景
  • 本次迭代過程中減少的風(fēng)險
  • 本次迭代過程中修改的缺陷

出口準(zhǔn)則：

更新后的產(chǎn)品和工件,，另外還有:

• 一個版本描述文檔，記錄了迭代的結(jié)果
• 測試用例和根據(jù)產(chǎn)品得出的測試結(jié)果
• 一個詳細描述下一次迭代的計劃
• 對下一次迭代的客觀度量標(biāo)準(zhǔn)

到構(gòu)建階段的后期,，必須完成以下工件,，及本階段最后一次迭代額外的出口準(zhǔn)則：

• 一個部署計劃，指定必需的事項：
  • 打包
  • 定價
  • 演示
  • 支持
  • 培訓(xùn)
  • 移交策略 (例如一個現(xiàn)有系統(tǒng)的更新計劃)
  • 產(chǎn)品 (軟盤和手冊)
• 用戶文檔

3.4. 移交階段
移交階段是將產(chǎn)品交付給最終用戶的階段,。 它涉及銷售,、打包、安裝,、配置,、支持用戶社區(qū)和做出修正等.

從技術(shù)角度來看，伴隨本階段迭代的是一次或多次發(fā)布：`beta' 版發(fā)布,、正式版發(fā)布,、修補bug , 或增強版發(fā)布。

當(dāng)用戶對產(chǎn)品滿意時,，本階段即告結(jié)束,。 例如，契約性開發(fā)時正式驗收,， 或者產(chǎn)品有關(guān)的所有活動都已結(jié)束,。 此時，某些積累的資產(chǎn)可以加以整理,，以為下一個周期或其他項目重用,。

入口準(zhǔn)則：

• 上一次迭代的產(chǎn)品和工件,， 尤其是足夠成熟可以交付給用戶的軟件產(chǎn)品

出口準(zhǔn)則：

• 前一階段某些文檔的更新，以及必要時根據(jù)原始及修訂后的成功標(biāo)準(zhǔn),，進行"事后"項目性能分析,，從而替換原有計劃。
• 一個簡短的清單,，列出本次開發(fā)周期給組織帶來的新的資產(chǎn)

3.5. 演進周期
對于重要的演進,，我們應(yīng)用整個過程遞歸，仍從起始階段開始一個新的周期,。因為我們已經(jīng)有了一個產(chǎn)品,，所以比起一個初次開發(fā)的產(chǎn)品，起始階段可能大大縮短,。細化階段也可能縮小范圍,，而在計劃方面的關(guān)注程度要大于分析或構(gòu)架的演進方面。需要指出：周期之間可以略有重疊,。

較小的演進可以通過延長移交階段或增加一兩次迭代來完成,。

移交階段可以以一個終結(jié)過程而結(jié)束，即產(chǎn)品不再演進了,，但是為了終結(jié)它,，需要采取一些特定的動作。

4. Rational過程中的活動
Rational 過程中各個階段的名稱(如起始,、細化,、構(gòu)建、移交)與描述高級活動的術(shù)語（如分析,、設(shè)計,、測試等）相差甚遠。 因此我們?nèi)菀桌斫饽撤N活動的進行并不局限于某個特定階段,，也與其他作者,、標(biāo)準(zhǔn)及特定領(lǐng)域的所使用的術(shù)語無關(guān)。這些活動確實發(fā)生,，但它們在每個階段和每次迭代中的程度有所不同,。下圖表明了活動重點如何隨時間的推進而發(fā)生演進。

圖中活動重點的變化也說明盡管每次迭代在形式上都是"相似"的,，但它們的性質(zhì)和內(nèi)容卻是隨時間而改變的,。

這還表明，一項活動的結(jié)束并不總意味著另一項活動的開始,，即并不是分析完成了才開始設(shè)計,，而是這些活動相關(guān)的各種"工件"在隨著開發(fā)者對問題或需求的理解的加深也不斷得到更新。

最后,，在一個迭代過程中,，計劃,、測試和集成這些活動不是集中堆積在開發(fā)活動的開始和結(jié)束階段，而是增量地分布在整個開發(fā)周期的各個階段,、每次迭代之中,。 它們并不表現(xiàn)為開發(fā)過程的某個獨立的階段或步驟。

盡管具體的項目有具體的區(qū)別,，但對于一個中等規(guī)模,、初次開發(fā)的典型項目來說，其開發(fā)周期中各種活動的比例如下：

5. 生命周期工件
開發(fā)過程不是文檔驅(qū)動的：它的工件中必須一直包括軟件產(chǎn)品自身,。文檔應(yīng)該十分精簡,，數(shù)目不能太多，應(yīng)只保留那些確實從管理或技術(shù)的角度有真正價值的文檔,。 Rational 建議保留以下典型的文檔集,。

5.1管理工件
管理工件不是產(chǎn)品，而是用來驅(qū)動或監(jiān)控項目進展,、估計項目風(fēng)險,、調(diào)整項目資源，以及使客戶或投資者對項目保持一定的"可見性" 的,。

• 一份機構(gòu)策略文檔,，是機構(gòu)開發(fā)過程的明文規(guī)定。 它包含一個此類項目的實例,。
• 一份遠景文檔, 描述系統(tǒng)級需求,，質(zhì)量要求和優(yōu)先級。
• 一份業(yè)務(wù)案例文檔, 描述財務(wù)環(huán)境,、合同,，以及項目的投資回報等等,。
• 一份開發(fā)計劃文檔, 包括總體的迭代計劃和當(dāng)前及近期迭代的詳細規(guī)劃,。
• 一份評估標(biāo)準(zhǔn)文檔，包括需求,、驗收標(biāo)準(zhǔn)及其他特定的技術(shù)目標(biāo),，它們由各個階段演進的主要"里程碑"組成。包含迭代的目標(biāo)和驗收水平,。
• 每次發(fā)布的版本描述文檔,。
• 部署文檔, 包含對交付、培訓(xùn),、安裝,、銷售、制造和交割相關(guān)的有用信息,。
• 狀態(tài)評估文檔: 項目狀態(tài)的階段性"快照",， 具有進展,、人力、開銷,、結(jié)果,、關(guān)鍵風(fēng)險、活動等的度量標(biāo)準(zhǔn),。

5.2技術(shù)工件
它們或者是交付的產(chǎn)品,，可執(zhí)行的軟件及手冊，或者是一些用于制造產(chǎn)品的藍圖,，這些產(chǎn)品包括軟件模型,、源代碼和其他有助于理解和演進產(chǎn)品的工程信息。

• 用戶手冊, 在生命周期早期開發(fā),。
• 軟件文檔, 最好以源代碼自建文檔和模型的形式,，其中模型是用合適的CASE工具捕獲并維護的這些模型包括用例、類圖和過程圖等,。
• 一個軟件構(gòu)架文檔, 描述軟件的整體構(gòu)架,，及它的主要組成元素的分解說明： 類的分組、類,、過程,、子系統(tǒng)、關(guān)鍵接口的定義和關(guān)鍵設(shè)計決策的依據(jù),。

本文第3部分中列舉的入口準(zhǔn)則和出口準(zhǔn)則可以映射到這11類文檔之中,。

上面介紹的這套文檔可以依照具體項目的類型進行擴充和刪減，一些文檔可以合并,。 文檔不必一定是紙張形式---也可以是電子表格,、文本文件、數(shù)據(jù)庫,、源代碼的注釋,、超文本文檔等等---但相應(yīng)的信息資源必須被清楚地識別，易于訪問,，也要保存一些歷史記錄,。

5.3需求
Rational 軟件開發(fā)過程也不是需求驅(qū)動的。 在產(chǎn)品演進的周期中,，需求表現(xiàn)為不同的形式：

• 業(yè)務(wù)案例給出了主要約束,，多是些可用的資源。
• 遠景文檔從用戶角度僅描述了系統(tǒng)的關(guān)鍵需求,，它在開發(fā)過程中將緩慢演進,。
• 更詳細的需求在第二階段（細化階段）以用例和場景的形式進行闡明，并在第三階段（構(gòu)建階段）隨著對產(chǎn)品和用戶需求了解的加深進一步精化。這些更詳細的需求記錄在評估標(biāo)準(zhǔn)文檔中,，它們驅(qū)動了構(gòu)建階段和移交階段迭代內(nèi)容的定義,， 并在迭代計劃中引用。

6. Rational過程的例子
按照2.4節(jié)中所述的區(qū)別,，Rational 過程采用不同的形式,。 這里有兩個極端的例子。

6.1大型契約性軟件開發(fā)的Rational過程
對這個軟件開發(fā)項目,，Rational 過程分為3個階段建立招標(biāo), 對應(yīng)3個不同類型的合同,。

• 一個研究與設(shè)計階段, 包含了生命周期的起始階段和細化階段, 通常以風(fēng)險分擔(dān)方式投標(biāo)，舉例來說,，成本加獎金合同（ cost plus award fee contract ,，CPAF）。
• 一個生產(chǎn)階段,，包含了生命周期的構(gòu)建和移交階段, 通常作為一個公司,、固定的價格合同（a firm, fixed price contract ,FFP）來投標(biāo)。
• 一個維護階段,，對應(yīng)生命周期的演進階段,，通常作來工作量水平合同（ a level of effort contract ，LOE）來投標(biāo),。

因為用戶需要更高的可視性來評估項目,，還因為項目涉及大量人員和組織，開發(fā)過程應(yīng)更加正規(guī)化,，要比小型,、內(nèi)部的項目更加重視書面工件。第5部分列出的11類文檔都以某種形式或名稱存在,。

6.2小型商業(yè)軟件產(chǎn)品的Rational過程
在按規(guī)模分類的過程家族的另一端,，是小型的商業(yè)軟件開發(fā)。它的流動性更強一些,，只有有限的正規(guī)性,， 表現(xiàn)為一些主要的里程碑和有限的文檔集：

• 一個產(chǎn)品遠景 （A product vision）。
• 一份開發(fā)計劃,，顯示資源和日程安排
• 版本描述文檔,，在每次迭代的開始指明本次迭代的目標(biāo),，在迭代結(jié)束時 作為版本說明（release notes）進行更新,。
• 必要的用戶手冊

軟件結(jié)構(gòu)、軟件設(shè)計,、開發(fā)過程可以通過代碼本身或軟件開發(fā)環(huán)境來進行文檔化,。

我們集中討論如何通過使用兩個流行的方法得到過程的恰當(dāng)級別：Rational Unified Process 或簡稱 RUP 以及極限編程（XP）。我們展示如何在小型項目中使用 RUP 以及 RUP 如何處理 XP 沒有涉及到的領(lǐng)域。二者融合為項目團隊提供了所需的指南--減少風(fēng)險同時完成交付軟件產(chǎn)品的目標(biāo),。

RUP 是由 IBM Rational 開發(fā)的過程框架,。它是一種迭代的開發(fā)方法，基于六個經(jīng)過行業(yè)驗證的最佳實踐（參見 RUP 附錄）,。隨著時間的推進,，一個基于 RUP 的項目將經(jīng)歷四個階段：起始階段（Inception）、細化階段（Elaboration）,、構(gòu)造階段（Construction）,、交付階段（Transition）。每個階段都包括一次或者多次的迭代,。在每次迭代中,，您根據(jù)不同的要求或工作流（如需求、分析和設(shè)計等）投入不同的工作量,。RUP 的關(guān)鍵驅(qū)動因素就是降低風(fēng)險,。RUP 通過數(shù)千個項目中數(shù)千名 IBM Rational 客戶和合作伙伴使用而得到精化。下圖展示了一個典型迭代過程的工作流：

典型迭代流

作為風(fēng)險如何影響過程的一個例子,，我們應(yīng)該考慮是否需要為業(yè)務(wù)建模,。如果由于對業(yè)務(wù)的理解中沒有考慮到一些重大風(fēng)險，將導(dǎo)致我們所構(gòu)建的系統(tǒng)是錯誤的,，那么我們就應(yīng)該執(zhí)行一些業(yè)務(wù)建模工作,。我們需要正式進行建模工作嗎？這取決于我們的涉眾--如果一個小團隊將非正式地使用結(jié)果,，那么我們也許只進行非正式的記錄就可以,。如果組織中的其他人也將使用結(jié)果或者查看結(jié)果，那么我們可能就要投入更大的努力,，并且確保該結(jié)果的正確性和可理解性,。

您可以定制 RUP 使其滿足幾乎任何項目的需要。如果沒有滿足您特定需要的即裝即用的過程或路線圖,，您可以輕松地創(chuàng)建您自己的路線圖,。路線圖描述了該項目如何計劃使用過程，因此代表了該項目的特定過程實例,。這就意味著,，RUP 可以按需要變得簡單或復(fù)雜，我們將在本文中詳細解釋,。

XP 是一個用于小型項目中的以代碼為中心的輕量級過程（參見 XP 附錄）,。它來自 Kent Beck 的創(chuàng)意，在大概 1997 年 Chrysler 公司的 C 3 工資單項目中得到軟件界的關(guān)注,。如同 RUP 一樣,，XP 也是基于迭代的，并且體現(xiàn)了諸如小規(guī)模發(fā)布、簡單設(shè)計,、測試以及持續(xù)迭代幾項實踐,，。XP 為恰當(dāng)?shù)捻椖亢铜h(huán)境引入了一些有效的技術(shù),；不過,，其中也存在隱藏的假設(shè)、活動和角色,。

RUP 和 XP 具有不同的基本原理,。RUP 是過程組件、方法以及技術(shù)的框架,，您可以將其應(yīng)用于任何特定的軟件項目,，我們希望用戶限定 RUP 的使用范圍。XP,，從另一方面來說,，是一個具有更多限制的過程，需要附加內(nèi)容以使其適合完整的開發(fā)項目,。這些不同點解釋了軟件開發(fā)界的一個觀點：開發(fā)大型系統(tǒng)的人員使用 RUP 解決問題,，而開發(fā)小型系統(tǒng)的人員使用 XP 作為解決方案。我們的經(jīng)驗表明大部分的軟件項目都處于兩者之間--盡力找尋適用于各自情況的過程的恰當(dāng)級別,。單純地使用兩者之一是不充分的,。

當(dāng)您在 RUP 中融合了 XP 技術(shù)時，您會得到過程的正確量,，既滿足了項目所有成員的需要,，又解決了所有主要的項目風(fēng)險問題。對于一個工作于高信任環(huán)境中的小型項目團隊,，其中用戶是團隊的一部分,，那么 XP 完全可以勝任。對于團隊越來越分散,，代碼量越來越大,，或者構(gòu)架沒有很好定義的情況，您需要做一些其他工作,。在用戶交互具有"契約"風(fēng)格的項目中,，僅有 XP 是不夠的。RUP 是一個框架,，您可以從 RUP 出發(fā),，在必要時以一組更健壯的技術(shù)來擴展 XP。

本文的以下部分描述了一個基于 RUP 四個階段的小型項目,。在每個階段中,，我們都確定了所產(chǎn)生的活動和工件 。雖然 RUP 和 XP 具有不同的角色和職責(zé),，但是我們在這里不會處理這些差異,。對于任何組織或項目，實際項目成員必須在過程中與正確的角色關(guān)聯(lián)起來,。

項目啟動－起始階段
對于新的開發(fā)項目來說,，起始階段是很重要的，在項目繼續(xù)進行前,，您必須處理重要的業(yè)務(wù)與需求風(fēng)險,。對于那些增強現(xiàn)有系統(tǒng)的項目，起始階段是比較短暫的,，但是其目的仍是確定該項目的實施價值及可行性,。

在起始階段中，為了構(gòu)建軟件您可以創(chuàng)建業(yè)務(wù)案例,。視圖是起始過程中的關(guān)鍵工件,。它是系統(tǒng)的高級描述。它為每個人解釋該系統(tǒng)是什么,、可能使用系統(tǒng)的用戶,、使用系統(tǒng)的原因、必須具備的功能,，以及存在的約束,。視圖可能很短，也許只有一兩段,。視圖往往包括軟件必須為客戶提供的關(guān)鍵功能,。

下面的例子展示了一個項目的很短視圖，該項目對 Rational 的外部網(wǎng)站進行了改造,。

為使 Rational 的地位達到電子開發(fā)（包括工具,、服務(wù)和最佳實踐）的世界領(lǐng)先程度，可以通過動態(tài)的,、個性化的網(wǎng)站加強客戶關(guān)系,，為訪問者提供自助服務(wù)、支持和目標(biāo)內(nèi)容,。新的過程和技術(shù)啟用可以使內(nèi)容供應(yīng)商通過一種簡化的,、自動的解決方案加速發(fā)布并提高內(nèi)容的質(zhì)量。

RUP 起始階段中 4 個重要活動為：

制定項目的范圍,。如果我們打算構(gòu)建一個系統(tǒng),，我們需要知道其內(nèi)容以及它如何滿足涉眾的需要。在這個活動中,，我們捕獲內(nèi)容和最重要的需求的足夠詳細的信息,，從而得出產(chǎn)品可接受的標(biāo)準(zhǔn),。

計劃并準(zhǔn)備業(yè)務(wù)案例。我們使用視圖作為指導(dǎo),，定義風(fēng)險緩和策略,，開發(fā)起始的項目計劃，并確定已知成本,、日程計劃,，以及盈利率平衡。

綜合得出備選構(gòu)架,。如果正在計劃中的系統(tǒng)沒什么新穎性,，而且使用的框架廣為人之，那么您可以跳過這一步,。我們一旦知道客戶的需求,，就要開始分配時間研究可行的備選構(gòu)架。新技術(shù)能夠帶來解決軟件問題的新的并且經(jīng)過改進的解決方案,。在過程的早期花些時間評估購買還是創(chuàng)建系統(tǒng),，并選擇技術(shù)，也可以開發(fā)出一個起始原型,，這些都可以減少項目的一些主要風(fēng)險,。

準(zhǔn)備項目環(huán)境。任何項目都需要項目環(huán)境,。不論您使用 XP 技術(shù)（例如結(jié)對編程）,，還是較傳統(tǒng)的技術(shù)，您都需要確定團隊將要使用的物理資源,、軟件工具以及步驟,。

進行小型項目開發(fā)時，并不需要太多的"過程時間"來執(zhí)行起始過程,。您往往可以在幾天中或者更少的時間里完成,，下面的內(nèi)容說明了本階段除了視圖之外的預(yù)期工件。

一個經(jīng)批準(zhǔn)的業(yè)務(wù)案例
涉眾有機會從業(yè)務(wù)的角度認(rèn)定項目是值得進行的,。RUP 和 XP 都承認(rèn)最好在早期就得出項目是否值得進行的結(jié)論,，以免在一個注定將要失敗的項目中花費寶貴的資源。如同在"Planning Extreme Programming" 一書描述的那樣,，XP 對于項目是如何形成的以及涉及哪些角色這兩個問題的回答是比較模糊的（似乎在現(xiàn)有項目或系統(tǒng)的環(huán)境中是最清晰的）,，但是在研究階段，XP 處理的工件與 RUP 起始過程中的是相同的,。

不論您在 XP 中非正式地考慮業(yè)務(wù)問題,，還是在 RUP 中將業(yè)務(wù)案例做成一流的項目工件，您都需要考慮這些問題,。風(fēng)險清單您應(yīng)該在整個項目開發(fā)過程中都保持記錄 Risk List（風(fēng)險清單）,。使用有風(fēng)險清單可以是一個具有經(jīng)過計劃的風(fēng)險緩和策略的簡單清單,。為各個風(fēng)險設(shè)定優(yōu)先級。任何與項目有關(guān)的人員都可以隨時看到風(fēng)險的內(nèi)容以及如何處理風(fēng)險,，但是沒有提供解決風(fēng)險的一般方式 ,。

初步項目計劃
本計劃包括資源估算、規(guī)模以及階段計劃,。對于任何項目,，這些估算都是不斷變化的,，您必須監(jiān)控它們,。

項目驗收計劃
您的計劃正式與否依賴于項目的類型。您必須判斷客戶會如何才能認(rèn)為您的項目取得了成功,。對于一個 XP 項目,，客戶會采取驗收測試的形式。在更普遍的過程中,，客戶可能不會真正地進行測試,，但是接受的標(biāo)準(zhǔn)必須直接由客戶作出，或者由另一個角色作出,，例如與客戶直接接觸的系統(tǒng)分析員,。也可能存在其他的驗收標(biāo)準(zhǔn)，例如創(chuàng)建最終用戶文檔和幫助,，但是XP并不涉及此內(nèi)容,。

起始細化迭代計劃
在基于 RUP 的項目中，在上次迭代的最后,，您將詳細計劃下次迭代,。在迭代的最后，您可以評估迭代開始時設(shè)立的標(biāo)準(zhǔn),。XP 提供了探監(jiān)控與衡量迭代成功的一些優(yōu)秀技巧,。衡量標(biāo)準(zhǔn)是簡單的，您可以輕松地將它們合并到迭代計劃和評估標(biāo)準(zhǔn)中,。

起始用例模型
雖然這聽起來比較正式而讓人望之卻步,，但是它卻相當(dāng)簡單。用例與客戶在XP中編寫的"故事"相對應(yīng),。其間的差異就是一個用例就是一套完整的動作,，由參與者或系統(tǒng)外部的人員或事物發(fā)起，這正是用例的價值所在,。用例可能包括若干個XP"故事",。RUP 為了定義項目的邊界，推薦在起始過程中確定用戶與角色,。從用戶的觀點關(guān)注整套操作有助于將系統(tǒng)分為有價值的部分,。這有助于判定恰當(dāng)?shù)膶嵤┨匦?，因此我們能夠在每次迭代的最后向客戶交付一些成果（可能在起始迭代與細化迭代早期除外）。

RUP 與 XP 都可以幫助我們確保避免一種情況,，即整個項目已完成 80％,，但都不是可交付的形式。我們一直希望發(fā)布的系統(tǒng)對用戶都是有價值的,。

在這一點上,，用例模型在識別用例和參與者方面幾乎沒有或只有很少提供支持的細節(jié)。它可以是手工或使用工具繪制的簡單的文本或者 UML（統(tǒng)一建模語言）圖,。該模型幫助我們確保已經(jīng)包含了涉眾所關(guān)心的正確的功能,，并且沒用忘記任何功能，并允許我們輕松地查看整個系統(tǒng),。用例根據(jù)若干因素設(shè)定優(yōu)先級,，這些因素包括風(fēng)險、對客戶的重要程度以及技術(shù)難點,。起始階段中不需要過于正式的或過大的工件,。按照您的需求讓它們保持簡單或者正式就可以。XP 包括對計劃與系統(tǒng)驗收的指南,，但是 RUP 需要在項目的早期添加更多的一些內(nèi)容,。這些少量添加可能通過處理一套更完整的風(fēng)險而為項目提供很大的價值。

細化階段
細化階段的目標(biāo)是為系統(tǒng)構(gòu)架設(shè)立基線,，為在構(gòu)建階段大量的設(shè)計與實施工作打下堅實的基礎(chǔ),。構(gòu)架通過考慮最重要的需求（那些對系統(tǒng)構(gòu)架影響最大的需求）與評估風(fēng)險演進而來。構(gòu)架的穩(wěn)定性是通過一個或多個構(gòu)架原型進行評估的,。

在 RUP 中,，設(shè)計活動主要關(guān)注系統(tǒng)構(gòu)架的概念，對于軟件密集型的系統(tǒng)來說,，就是軟件構(gòu)架的概念,。使用組件構(gòu)架是在 RUP 中體現(xiàn)的軟件開發(fā) 6 項最佳實踐其中之一，該實踐推薦在開發(fā)與所作所為構(gòu)架上要投入一些時間,。在這項工作花費的時間可以減緩與脆弱的,、僵化日系統(tǒng)有關(guān)的風(fēng)險。

XP 使用"隱喻"替換了構(gòu)架的概念,。隱喻只捕獲構(gòu)架的一部分,，而其余構(gòu)架部分則隨著代碼開發(fā)的自然結(jié)果而演進。XP假定構(gòu)架的形成是從生成簡單的代碼開始,，然后進行持續(xù)的代碼重構(gòu),。

在 RUP 中，構(gòu)架不只是"隱喻",。在細化階段中,，您構(gòu)建可執(zhí)行的構(gòu)架,，從中可能降低與是否滿足非功能性需求相關(guān)的許多風(fēng)險，例如性能,、可靠性以及健壯性,。通過閱讀XP文獻，很可能推斷出一些 RUP 為細化階段所描述的內(nèi)容,，尤其是過于 XP 所稱的基礎(chǔ)設(shè)施的過分關(guān)注,，都是徒勞無功的。XP 認(rèn)為在沒有必要的情況下創(chuàng)建基礎(chǔ)設(shè)施所做的工作導(dǎo)致了解決方案過于復(fù)雜,，并且所創(chuàng)建的結(jié)果對客戶沒有價值,。在 RUP 中，構(gòu)架與基礎(chǔ)設(shè)施不是等同的,。

在 RUP 與 XP 中創(chuàng)建構(gòu)架的方法是截然不同,。RUP 建議您關(guān)注構(gòu)架,，避免隨時間變化而產(chǎn)生的范圍蔓延,、增加項目規(guī)模以及采用新技術(shù)帶來的風(fēng)險。XP 采用足夠簡單或是很好理解的現(xiàn)有構(gòu)架,，該構(gòu)架能夠隨著代碼而演進,。XP 建議您不要為明天而設(shè)計，而要為今天而實施,。XP 相信如果您盡可能地保持設(shè)計簡單,，那么將來管理起來也輕而易舉。RUP 希望您考慮該主張帶來的風(fēng)險,。如果系統(tǒng)或者部分系統(tǒng)在未來不得不重寫,，那么 XP 認(rèn)為這種舉措比現(xiàn)在就計劃這種可能性更明智而且花費更少。對于一些系統(tǒng),，這是千真萬確的,，而且使用 RUP 時，在您細化階段考慮風(fēng)險也會得出同一結(jié)論,。RUP 并不認(rèn)為對于所有系統(tǒng)這都是正確的,，而且經(jīng)驗表明對于那些較大型、較復(fù)雜和沒有先例的系統(tǒng)來說,，這可能是災(zāi)難性的,。

雖然為未來的可能性（可能永遠不會生生）花費太多的精力可能是一種浪費但是對未來進行足夠的關(guān)注不失為一件精明之舉。多少公司能花得起代價不斷重寫或者甚至是重構(gòu)代碼呢,？

對于任何項目,，在細化階段您應(yīng)該至少完成這三項活動：

定義、驗證并且設(shè)定構(gòu)架的基線,。使用風(fēng)險清單從起始階段開發(fā)備選構(gòu)架。我們關(guān)注是否能夠保證構(gòu)想中的軟件具有可行性,。如果選定技術(shù)對于系統(tǒng)沒什么新穎性或者復(fù)雜性,，這項任務(wù)不會花費太長時間。如果您正在向現(xiàn)有系統(tǒng)中添加內(nèi)容,，那么如果現(xiàn)有構(gòu)架不需要進行變更，這項任務(wù)就不是必要的,。但是當(dāng)真正出現(xiàn)構(gòu)架風(fēng)險時,，您并不想讓您的架構(gòu)來"碰運氣"。

作為這項活動的一部分,，您可能執(zhí)行一些組件選擇,，并且做出決定進行購買/創(chuàng)建/重用組件。如果這需要大量工作,，您可以將其分為單獨的活動,。

精化視圖。在起始階段,，您開發(fā)了一個視圖,。因為你要確定項目的可行性，并且涉眾有時間檢查和評價系統(tǒng),，因此可能要對視圖文檔及需求作出一些變更,。對視圖與需求的修改一般在細化階段進行。在細化階段的最后,，您已經(jīng)深刻理解了用來構(gòu)建和計劃的最關(guān)鍵的用例,。涉眾需要得到認(rèn)可，在當(dāng)前構(gòu)架的環(huán)境中,，只要按照當(dāng)前的計劃開發(fā)整個系統(tǒng),，就能實現(xiàn)當(dāng)前的設(shè)想。在隨后的迭代過程中,，變更的數(shù)量應(yīng)該有所減少,，但是您可能會在每次迭代中花一些時間進行需求管理,。

為構(gòu)建階段創(chuàng)建迭代計劃并且設(shè)定基線?，F(xiàn)在，可以為您的計劃填充細節(jié)了,。在每次構(gòu)建迭代的最后,，您可以按需要重新考慮計劃并且進行調(diào)整。調(diào)整過程經(jīng)常是必需的,，因為需要進行的工作往往被錯誤地估算,，業(yè)務(wù)環(huán)境也會常常變化，有時需求也會發(fā)生變更。為用例,、場景以及技術(shù)工作設(shè)定優(yōu)先級,，然后將它們分配到迭代過程中。在每次迭代過程的最后,，您計劃產(chǎn)生一個能夠為涉眾提供價值的工作產(chǎn)品,。

您可以在細化階段執(zhí)行其他活動。我們推薦您建立測試環(huán)境并且開始開發(fā)測試,。雖然詳細的代碼還沒有完成,，但是您仍然可以設(shè)計測試，也許可以實施集成測試,。程序員應(yīng)該隨時準(zhǔn)備進行單元測試,，并且了解如何使用項目選定的測試工具。XP 推薦您在編寫代碼前先設(shè)計測試內(nèi)容,。這是個獨到的見解,，尤其是當(dāng)您向現(xiàn)有代碼主體中添加內(nèi)容時。不過,，無論您選擇如何進行測試,，都應(yīng)該在細化階段建立常規(guī)測試體制。

RUP 描述的細化階段包括 XP 中的研究階段和投入階段,。XP 處理技術(shù)風(fēng)險（例如新穎性和復(fù)雜性）的方式為使用"spike"解決方案,，例如花費一些時間進行試驗以對工作量進行估算,。這種技術(shù)在許多案例中都是有效的,，當(dāng)較大風(fēng)險沒有體現(xiàn)在單個用例或"故事"中時，您就需要花些工夫確保系統(tǒng)的成功而且對工作量進行精確的估算,。

在細化階段,，您會經(jīng)常更新工件，例如起始階段的需求與風(fēng)險清單,。在細化階段可能出現(xiàn)的工件包括：

軟件構(gòu)架文檔（SAD）,。SAD 是一個復(fù)合型的工件，它提供了整個項目的技術(shù)信息的單一來源,。在細化階段的最后,，該文檔可能會包含詳細的介紹，描述在結(jié)構(gòu)上很重要的用例,，并且確定關(guān)鍵的機制和設(shè)計元素,。對于增強現(xiàn)有系統(tǒng)的項目，您可以使用以前的 SAD,，或者如果你覺得不會帶來什么風(fēng)險,，那么就決定不使用該文檔。在所有的情況下，您都應(yīng)該深思熟慮并且記錄于文檔中,。

構(gòu)建過程的迭代計劃,。您可以在細化階段計劃構(gòu)建迭代的次數(shù)。每次迭代都有特定的用例,、場景以及其他分配的工作項目,。這些信息都在迭代計劃中有所體現(xiàn)并且設(shè)定基線。評審與核準(zhǔn)計劃可以作為細化階段的出口標(biāo)準(zhǔn)的一部分,。對于非常小的短期項目來說,，您可以將細化階段的迭代與起始過程和構(gòu)建過程合并。關(guān)鍵性的活動仍然可以進行,，但是迭代計劃和評審所需的資源都會有所減少,。

構(gòu)建階段
構(gòu)建的目標(biāo)是完成系統(tǒng)開發(fā)。構(gòu)建階段從某種意義上來看是一個制造過程,，其中重點工作就是管理資源,、控制操作以優(yōu)化成本、日程和質(zhì)量,。從這個意義上來講,，管理理念應(yīng)該進行一個轉(zhuǎn)換，從起始階段和細化階段的知識產(chǎn)權(quán)開發(fā)轉(zhuǎn)換到構(gòu)建和交付階段的部署產(chǎn)品的開發(fā),。

XP 側(cè)重構(gòu)建階段,。構(gòu)建階段是編寫產(chǎn)品代碼的階段。XP所有階段的目的都是為了進行計劃,，但是 XP 的關(guān)注焦點是構(gòu)建代碼,。

構(gòu)建階段的每次迭代都具有三個關(guān)鍵活動：

管理資源與控制過程。每個人都需要了解自己的工作內(nèi)容和時間,。您必須保證工作負荷不會超過您的能力,，而且工作可以按計劃進行。

開發(fā)與測試組件,。您構(gòu)建組件以滿足迭代中用例,、場景以及其他功能的需要。您對其進行單元測試和集成測試,。

對迭代進行評估,。在迭代完成時，您需要判斷是否已經(jīng)達到了迭代的目標(biāo),。如果沒有,，您必須重新劃分優(yōu)先級并管理范圍以確保能夠按時交付系統(tǒng)。

不同類型的系統(tǒng)需要使用不同的技術(shù),。RUP 為軟件工程師提供了不同的指導(dǎo),，以幫助他們創(chuàng)建恰當(dāng)?shù)慕M件,。以用例和補充（非功能）需求的形式提出的需求是足夠詳細的，可以使工程師開展工作,。RUP 中的若干活動為設(shè)計,、實施和測試不同種類的組件提供了指南。一名有經(jīng)驗的軟件工程師不需要詳細查看這些活動,。經(jīng)驗稍欠缺一些的工程師可以通過最佳實踐獲得很大的幫助,。每個團隊成員都可以按需要深入研究過程或者只是稍微了解一下。不過,，他們都參照一個單獨的過程知識基礎(chǔ),。

在 XP 中，"故事"驅(qū)動實施過程,。在 Extreme Programming Installed 一書中,，Jeffries等人認(rèn)為"故事"是程序員的"會話承諾"（promises for conversation）。 持續(xù)有效的交流大有裨益,。雖然總是需要澄清一些細節(jié),，如果"故事"不夠詳細，而使程序員不能完成他們大部分工作,，那么可以說"故事"還沒有就緒,。用例必須足夠詳細以方便程序員實施。在許多情況下,，程序員會幫助編寫用例的技術(shù)細節(jié),。Jeffries 等人認(rèn)為，會話應(yīng)該記錄在文檔中并且附加到"故事"中,。RUP 也同意這個觀點,，除了以用例規(guī)格說明的形式，可以按需要使用非正式的形式,。捕獲并管理會話的結(jié)果是您必須管理的任務(wù),。

XP 的長處在于構(gòu)建階段。對于大多數(shù)團隊來說,，都存在適用于他們的"智慧與指南的結(jié)晶"。XP 中最顯著的實踐包括：

測試--程序員不斷地隨著代碼的開發(fā)編寫測試,。測試反映了"故事",。XP提倡您首先編寫測試，這是一項優(yōu)秀的實踐,，因為它可以迫使您深刻地理解"故事",，并且在必要的地方提出更多的問題。不論在編寫代碼之前還是之后,，一定要編寫測試,。將它們加入到您的測試包中，并且保證每次代碼變更時都運行測試。

重構(gòu)--不斷重構(gòu)系統(tǒng)的結(jié)構(gòu)而不改變其行為,，可以使其更加簡單或靈活,。您需要判斷對您的團隊來說是否存在一個較好的實踐。簡單與復(fù)雜的判別否因人而異,。有這樣一個例子,，一個項目中的兩個很聰明的工程師每晚都要重寫對方的代碼，因為他們認(rèn)為對方的代碼過于復(fù)雜,。這產(chǎn)生了一個副作用,，也就是他們總是干擾第二天其他成員的工作。測試是有幫助的,，但是如果他們之間不陷入代碼之爭的話,，那么團隊的處境就會更好一些。

結(jié)對編程--XP 認(rèn)為結(jié)對編程可以在更短的時間內(nèi)創(chuàng)建出更好的代碼,。有證據(jù)表明這是正確的 ,。如果您遵照這項實踐，就需要考慮許多人文與環(huán)境的因素,。程序員愿意對此進行嘗試嗎,？您的物理環(huán)境可以滿足這種情況嗎，即有足夠的空間使兩個程序員在一個單獨工作站中有效地工作,？您如何對待遠程工作或者在其他地點工作的程序員,？

持續(xù)集成--集成與構(gòu)建工作需要持續(xù)進行，可能每天不止一次,。這是一種確保代碼結(jié)構(gòu)完整的很好的方式,，它還允許在集成測試過程中進行持續(xù)的質(zhì)量監(jiān)控。

集體代碼所有權(quán)--任何人都可以隨時修改任何代碼,。XP 依賴這樣一個事實,，即一組好的單元測試將會減少這項實踐的風(fēng)險。讓大家將每一件事都搞清楚的好處不能局限在一定的尺度上--是 1 萬行代碼,、2 萬行代碼還是一定要少于 5 萬行,？

簡單設(shè)計--隨著重構(gòu)過程的進行，需要不斷地修改系統(tǒng)設(shè)計使其變更簡單,。再一次重申,，您需要判斷這項工作進行到何種程度才恰好合適。如果您在細化階段中花費了必要霎時間來設(shè)計構(gòu)架,，我們相信簡單的設(shè)計將會很快完成并且很快變得穩(wěn)定,。

代碼標(biāo)準(zhǔn)--這一直都是一項良好實踐。標(biāo)準(zhǔn)是什么都沒關(guān)系,，只要您使用它們而且每個人都認(rèn)可就可以,。

RUP 與 XP 都認(rèn)為您必須管理（和控制）迭代過程,。衡量標(biāo)準(zhǔn)可以提供較好的計劃信息，因為它們可以幫助您選擇對于您的團隊來說什么是最適合的,。需要衡量三件事：時間,、規(guī)模和缺陷。這樣您就可以獲得所有類型您所感興趣的統(tǒng)計數(shù)字,。XP 為您提供簡單的衡量標(biāo)準(zhǔn)來判斷進展并且預(yù)測成果,。這些衡量標(biāo)準(zhǔn)圍繞著完成的"故事"數(shù)量、通過測試的數(shù)量以及統(tǒng)計中的趨勢這些問題,。XP 為使用最少量的衡量標(biāo)準(zhǔn)做出了一個優(yōu)秀的表率,，因為查看太多并不一定會增加項目成功的機會。RUP 為您提供了對于您可以衡量的內(nèi)容以及如何衡量的指導(dǎo),，并且舉了有關(guān)衡量標(biāo)準(zhǔn)的例子,。在所有的情況中，衡量標(biāo)準(zhǔn)必須簡單,、客觀,、易于搜集、易于表達,，并且不易產(chǎn)生誤解,。

在構(gòu)建階段的迭代過程中將會產(chǎn)生哪些工件呢？這取決于迭代是處于構(gòu)建階段的早期還是后期,，您可以創(chuàng)建以下工件：

組件--組件代表了軟件代碼中的一部分（源代碼,、二進制代碼或者可執(zhí)行程序）,，或者包含信息的文件，例如,，一個啟動文件或者一個 ReadMe 文件,。組件還可以是其他組件的聚合,，例如由幾個可執(zhí)行程序組成的應(yīng)用程序。

培訓(xùn)資料--如果系統(tǒng)的用戶界面比較復(fù)雜，那么請在用例的基礎(chǔ)上盡早編寫用戶手冊和其他培訓(xùn)資料的初稿,。

部署計劃--客戶需要一個系統(tǒng),。部署計劃描述了一組安裝,、測試并且有效地向用戶交付產(chǎn)品所需的任務(wù),。對于 以Web 為中心的系統(tǒng)來說,，我們已經(jīng)發(fā)現(xiàn)，部署計劃的重要性又提高了,。

交付階段迭代計劃--臨近交付時,，您需要完成并且評審交付階段迭代計劃。

代碼完整嗎,？
認(rèn)為代碼就是設(shè)計并且設(shè)計也就是代碼,。代碼與自身總是一致的,，這一點是千真萬確的。我們認(rèn)為花費精力進行設(shè)計并且溝通設(shè)計是很值得的,，而不僅僅是創(chuàng)建代碼。下面的小故事會說明這一點,。

一名工程師曾有兩次這樣的軟件項目經(jīng)歷,，設(shè)計體現(xiàn)在代碼中,，并且只能在代碼中找到設(shè)計信息。這兩個項目都是關(guān)于編譯器的：一個是改進與維護用于 Ada 編譯器的優(yōu)化程序,，另一個項目是將一個編譯器的前端移植到一個新的平臺上,，并且連接一個第三方的代碼生成器。

編譯器技術(shù)是比較復(fù)雜的,，但也是廣為人知的,。在這兩個項目中,，該工程師想要概覽編譯器（或者優(yōu)化程序）的設(shè)計和實施。在每個案例中,，他都接到一堆源代碼清單,，大概有幾英尺厚,，而且被告知"查看這些信息",。他本應(yīng)被提供一些帶有支持性文字的構(gòu)建很好的圖。優(yōu)化程序的項目沒有完成,。但是編譯器項目確實取得了成功,，由于在代碼開發(fā)過程中進行了廣泛的測試，所以代碼質(zhì)量很高,。這位工程師花費了數(shù)天時間研究調(diào)試器中的代碼以弄明白其作用,。個人的損失尚在其次,，團隊的損失代價就更不值得。我們并沒有按 XP 所示的那樣在 40 小時后完成開發(fā),，我們反而花費了大量個人努力來完成工作,。

只開發(fā)代碼帶來的主要問題就是無論代碼文檔編寫得多么好，它都沒有告訴您它本身要解決的問題,，它只提供了問題的解決方案,。一些需求文檔在最初用戶和開發(fā)人員繼續(xù)工作很長時間以后，仍然可以很好地解釋項目的原始目標(biāo),。為了維護系統(tǒng),，您往往需要了解最初項目團隊的設(shè)計目標(biāo)。一些高級設(shè)計文檔都是相似的--代碼經(jīng)常沒有經(jīng)過高度的抽象,，所以無法提供任何信息以表明整體的系統(tǒng)能夠?qū)崿F(xiàn)什么功能,。在面向?qū)ο蟮南到y(tǒng)中，這一點尤其是正確的,，因為僅僅查看里面的類文件是很難甚至無法得出執(zhí)行線程,。設(shè)計文檔指導(dǎo)您在后期出現(xiàn)問題時該查看的內(nèi)容--在后期經(jīng)常會出現(xiàn)問題。

這個故事說明花費時間創(chuàng)建與維護設(shè)計文檔確實會有所幫助,。這可以降低誤解的風(fēng)險,，并且加速開發(fā)過程。XP 的方式就是花費幾分鐘勾畫出設(shè)計的大概內(nèi)容或者使用 CRC 卡片,。 但是團隊不主張這樣,，而只是進行代碼開發(fā)。他們有一個隱含的假設(shè),，那就是任務(wù)很簡單,，我們已經(jīng)知道該如何進行了。即使我們成功地完成了任務(wù)，那么下一個新來的人可能就不會如此幸運,。RUP建議您多花費一些時間創(chuàng)建并維護這些設(shè)計工件,。

交付階段
交付階段的焦點就是確保軟件對于最終用戶是可用的。交付階段包括為發(fā)布進行產(chǎn)品的測試,，在用戶反饋的基礎(chǔ)上做微小的調(diào)整等幾方面內(nèi)容,。在生命周期的這個時刻，用戶反饋主要集中在精確調(diào)整產(chǎn)品,、配置,、安裝，以及可用性等問題上,。

較早發(fā)布、經(jīng)常性發(fā)布都是很好的辦法,。但是,，我們通過發(fā)布要達到的目的是什么呢？XP 沒有清楚地解釋這個問題,，也沒有處理發(fā)布商業(yè)軟件所必須制造問題,。在內(nèi)部項目中，您可以為解決這些問題找到捷徑,，但是即使這樣,，您仍然需要編輯文檔、員工培訓(xùn)等工作,。那么技術(shù)支持與變更管理又如何呢,？希望現(xiàn)場客戶控制這些內(nèi)容，這是可行的嗎,？Bruce Conrad 在他的 XP 的 InfoWorld 評論 中指出用戶并不希望得到的軟件總是在持續(xù)變更,。您必須對快速變更軟件的利益和變更的劣勢及可能帶來的不穩(wěn)定性進行權(quán)衡。

當(dāng)您決定發(fā)布的時候,，您必須為最終用戶提供比代碼多得多的東西,。交付階段的活動和工件會指導(dǎo)您完成本部分軟件開發(fā)過程。這些活動主要是為了向您的客戶提供可用的產(chǎn)品,。交付階段的關(guān)鍵活動如下：

確定最終用戶支持資料,。該活動比較簡單，您只需提供一個清單即可,。但是務(wù)必要確保您的組織已準(zhǔn)備好對客戶進行技術(shù)支持,。

在用戶的環(huán)境中測試可交付的產(chǎn)品。如果您能夠在公司內(nèi)部模擬用戶環(huán)境,，那是最好不過的,。否則，就到客戶的公司去，安裝軟件并且保證其可以運行,。您一定不想尷尬地回答客戶："但是在我們的系統(tǒng)上工作很正常,。"

基于用戶反饋精確調(diào)整產(chǎn)品。如果可能的話,，在您向有限數(shù)量客戶交付軟件時計劃一次或者多次 Beta 測試周期,。如果進行該測試，那么就需要對 Beta 測試周期進行管理,，并且考慮您"收尾工作"中的客戶反饋,。

向最終用戶交付最終產(chǎn)品。對于不同類型的軟件產(chǎn)品和發(fā)布版本,，需要處理許多有關(guān)打包,、制造和其他產(chǎn)品問題。您肯定不會僅僅將軟件復(fù)制到一個文件夾中,，然后向客戶發(fā)一封郵件告訴他們軟件已經(jīng)到位了,。

與其他階段一樣，過程的格式與復(fù)雜度都有所不同,。不過,，如果您沒有注意部署細節(jié)，那么可能導(dǎo)致數(shù)周或數(shù)月的良好開發(fā)工作前功盡棄,，從而在進入目標(biāo)市場時以失敗告終,。

在交付階段中您可以生成若干工件。如果您的項目涉及到將來的發(fā)布（有多少項目沒有涉及到呢,？）,，那么您就應(yīng)該開始為下次發(fā)布確定功能和缺陷。對于任何項目,，下列工件都至關(guān)重要：

部署計劃--完成您始于構(gòu)建階段的部署計劃并且將其作為交付的路線圖,。

版本注釋--它是一個比較少見的軟件產(chǎn)品，不包含對最終用戶至關(guān)重要的指令,?？梢詫ζ渥龀鲇媱潱瑢τ谧⑨屢幸粋€可用的,、一致的格式,。

交付階段資料與文檔--這類資料可以采取很多形式。您可以在線提供所有內(nèi)容嗎,？您會進行指導(dǎo)嗎,？您的產(chǎn)品幫助完整并且可用嗎？不要認(rèn)為您所了解的,，客戶也同樣了解,。您的成功就在于幫助您的客戶取得成功,。

結(jié)束語
構(gòu)建軟件的工作遠遠多于編寫代碼所工作。一個軟件開發(fā)過程必須集中處理向用戶發(fā)布高質(zhì)量軟件的所有必需活動,。一個完整的過程不必是龐大的,。我們通過集中論述項目中的主要活動和工件，已經(jīng)向您展示了如何進行一個小型但是完整的過程,。如果執(zhí)行某項活動或者創(chuàng)建某個工件對于緩解項目中的風(fēng)險是有幫助的,，那么就請進行。您可以按需要為您的項目團隊和組織使用或多或少的過程和格式,。

RUP 和 XP 并不必是互相排斥的,。通過結(jié)合使用這兩種方法，您完全可以得到一個過程,，幫助您比現(xiàn)在更快地交付更高質(zhì)量的軟件,。Robert Martin 描述了一個叫做 dX 的過程，他將其作為 RUP 的附屬品 ,。它就是一個從 RUP 框架中構(gòu)建的過程的實例,。

一個優(yōu)秀的軟件過程可以使用經(jīng)業(yè)界驗證的最佳實踐。最佳實踐已經(jīng)在真實的軟件開發(fā)組織中使用,，并且經(jīng)歷了時間的考驗。XP 是目前廣為關(guān)注的方法,。它以代碼為中心,，并提供了一項承諾：花費最少的過程開銷得到最大的生產(chǎn)力。XP 中的許多技術(shù)值得在恰當(dāng)?shù)那闆r中考慮和采用,。

XP 關(guān)注"故事",、測試和代碼--它以一定的深度討論了計劃，但沒有詳細闡述如何獲取計劃,。XP 意味著您可以完成其他一些工作,，例如"使用一些卡片進行 CRC 設(shè)計或者草擬某種 UML……"或者"請不要生成并不使用的文檔或者其他工件"，但只是一帶而過,。RUP 希望您在定制和更新開發(fā)計劃時,，僅僅考慮創(chuàng)建有用和必須的東西，并且指出了這些東西該是什么,。

RUP 是一個可以處理整個軟件開發(fā)周期的過程,。它關(guān)注最佳實踐，并且經(jīng)過了數(shù)千個項目的洗禮,。我們鼓勵研究和發(fā)明新的技術(shù)以產(chǎn)生最佳實踐,。隨著新的最佳實踐嶄露頭腳，我們希望將它們納入 RUP 中,。

附錄：Rational Unified Process
Rational Unified Process,，或者簡稱 RUP,，提供了軟件開發(fā)的規(guī)律性方法。它是由IBM Rational開發(fā)并維護的過程產(chǎn)品,。它為來同類型的項目提供了幾種即裝即用的路線圖,。RUP 還提供了一些信息，幫助您在軟件開發(fā)過程中使用其他 Rational 工具,，但是它不要求將 Rational 工具有效地應(yīng)用于整個組織,，您也可以將 Rational 工具與其他供應(yīng)商的產(chǎn)品進行集成。

RUP 為軟件項目所有方面提供了指導(dǎo),。并不需要您執(zhí)行任何特定的活動或者創(chuàng)建任何特定的工件,。它只為您提供信息和指南，您可以決定將哪些應(yīng)用于您的組織,。如果沒有特定的路線圖適合您的項目或者組織,，RUP 還提供了一些指南來幫助您量身定做你的過程。

RUP 強調(diào)采用現(xiàn)代軟件開發(fā)的一些最佳實踐,，作為一種降低開發(fā)新軟件所帶來的內(nèi)在風(fēng)險的方式,。這些最佳實踐包括：

1． 迭代開發(fā)
2． 管理需求
3． 使用基于組件的構(gòu)架
4． 可視建模
5． 持續(xù)的質(zhì)量驗證
6． 控制變更

這些最佳經(jīng)驗融合到 Rational Unified Process 的以下定義中：

角色--執(zhí)行的系列活動和擁有的工件。
學(xué)科--軟件工程中的關(guān)鍵領(lǐng)域,，例如需求,、分析與設(shè)計、實施與測試,。
活動--工件生成與評估方式的定義,。
工件--在執(zhí)行活動中所使用的、生成的或修改的工作產(chǎn)品,。

RUP 是一個迭代過程,，確定了任何軟件開發(fā)項目的四個階段。隨著時間的推進,，每個項目都要經(jīng)歷起始階段,、細化階段、構(gòu)建階段和交付階段,。每個階段包括一次或多次迭代,，其中您可以生成可執(zhí)行文件，但是系統(tǒng)可能不完整（可能起始階段除外）,。在每次迭代過程中,，您以不同的細節(jié)級別執(zhí)行幾個學(xué)科中的活動。下文是 RUP 的概述圖,。

RUP 概覽圖

The Rational Unified Process, An Introduction, Second Edition 一書是 RUP 的好的概述,。您可以在 Rational 的 Web 站點 www.rational.com 上找到更進一步的信息和對于 RUP 的評價。

附錄：極限編程
極限編程（XP）是由 Kent Beck 在 1996 年開發(fā)的一種軟件開發(fā)學(xué)科,。它基于四個價值：溝通,、簡單,、反饋和勇氣。它強調(diào)客戶與開發(fā)團隊成員的持續(xù)溝通,，在開發(fā)進程中設(shè)立一名現(xiàn)場客戶,。該現(xiàn)場客戶決定創(chuàng)建的內(nèi)容和順序。通過持續(xù)重構(gòu)代碼并創(chuàng)建最小的非代碼工件集合而體現(xiàn)簡單,。許多短期發(fā)布和持續(xù)單元測試建立了反饋機制,。勇氣意味著完成正確的事情，即使并不是最流行的事情,。它還意味著誠實面對您能做的和不能做的事情,。

12 個 XP 實踐為這四個價值提供支持。它們是：

有計劃的開發(fā)：通過結(jié)合使用優(yōu)先級"故事"和技術(shù)估算,，確定下一版本的功能,。

小版本：以小的增量版本經(jīng)常向客戶發(fā)布軟件。

隱喻：隱喻是一個簡單,、共享的"故事"或描述,，說明系統(tǒng)如何工作。

簡單設(shè)計：通過保持代碼簡單從而保證設(shè)計簡單,。不斷的在代碼中尋找復(fù)雜點并且立刻進行移除,。

測試：用戶編寫測試內(nèi)容以對"故事"進行測試。程序員編寫測試內(nèi)容來發(fā)現(xiàn)代碼中的任何問題,。在編寫代碼前先編寫測試內(nèi)容,。

重構(gòu)：這是一項簡化技術(shù)，用來移除代碼中的重復(fù)內(nèi)容和復(fù)雜之處,。

結(jié)對編程：團隊中的兩個成員使用同一臺計算機開發(fā)所有的代碼。一個人編寫代碼或者驅(qū)動,，另一個人同時審查代碼的正確性和可理解性,。

集體代碼所有權(quán)：任何人都擁有所有的代碼。這就意味這每個人都可以在任何時候變更任何代碼,。

持續(xù)集成：每天多次創(chuàng)建和集成系統(tǒng),，只要任何實現(xiàn)任務(wù)完成就要進行。

每周 40 個小時：程序員在疲勞時無法保證最高效率,。連續(xù)兩周加班是絕對不允許的,。

現(xiàn)場客戶：一名真實的客戶全時工作于開發(fā)環(huán)境中，幫助定義系統(tǒng),、編寫測試內(nèi)容并回答問題,。

編碼標(biāo)準(zhǔn)：程序員采用一致的編碼標(biāo)準(zhǔn)。

測試驅(qū)動開發(fā)(TDD)是極限編程的重要特點,，它以不斷的測試推動代碼的開發(fā),，既簡化了代碼,，又保證了軟件質(zhì)量。本文從開發(fā)人員使用的角度,，介紹了 TDD 優(yōu)勢,、原理、過程,、原則,、測試技術(shù)、Tips 等方面,。

背景
一個高效的軟件開發(fā)過程對軟件開發(fā)人員來說是至關(guān)重要的,，決定著開發(fā)是痛苦的掙扎，還是不斷進步的喜悅,。國人對軟件藍領(lǐng)的不屑,，對繁瑣冗長的傳統(tǒng)開發(fā)過程的不耐，使大多數(shù)開發(fā)人員無所適從,。最近興起的一些軟件開發(fā)過程相關(guān)的技術(shù),，提供一些比較高效、實用的軟件過程開發(fā)方法,。其中比較基礎(chǔ),、關(guān)鍵的一個技術(shù)就是測試驅(qū)動開發(fā)（Test-Driven Development）。雖然TDD光大于極限編程,，但測試驅(qū)動開發(fā)完全可以單獨應(yīng)用,。下面就從開發(fā)人員使用的角度進行介紹，使開發(fā)人員用最少的代價盡快理解,、掌握,、應(yīng)用這種技術(shù)。下面分優(yōu)勢,，原理,，過程，原則,，測試技術(shù),，Tips等方面進行討論。

1. 優(yōu)勢
TDD的基本思路就是通過測試來推動整個開發(fā)的進行,。而測試驅(qū)動開發(fā)技術(shù)并不只是單純的測試工作,。

需求向來就是軟件開發(fā)過程中感覺最不好明確描述、易變的東西,。這里說的需求不只是指用戶的需求,，還包括對代碼的使用需求。很多開發(fā)人員最害怕的就是后期還要修改某個類或者函數(shù)的接口進行修改或者擴展,，為什么會發(fā)生這樣的事情就是因為這部分代碼的使用需求沒有很好的描述,。測試驅(qū)動開發(fā)就是通過編寫測試用例,，先考慮代碼的使用需求（包括功能、過程,、接口等）,，而且這個描述是無二義的，可執(zhí)行驗證的,。

通過編寫這部分代碼的測試用例,，對其功能的分解、使用過程,、接口都進行了設(shè)計,。而且這種從使用角度對代碼的設(shè)計通常更符合后期開發(fā)的需求?？蓽y試的要求,，對代碼的內(nèi)聚性的提高和復(fù)用都非常有益。因此測試驅(qū)動開發(fā)也是一種代碼設(shè)計的過程,。

開發(fā)人員通常對編寫文檔非常厭煩,，但要使用、理解別人的代碼時通常又希望能有文檔進行指導(dǎo),。而測試驅(qū)動開發(fā)過程中產(chǎn)生的測試用例代碼就是對代碼的最好的解釋,。

快樂工作的基礎(chǔ)就是對自己有信心，對自己的工作成果有信心,。當(dāng)前很多開發(fā)人員卻經(jīng)常在擔(dān)心：“代碼是否正確,？”“辛苦編寫的代碼還有沒有嚴(yán)重bug？”“修改的新代碼對其他部分有沒有影響,？”,。這種擔(dān)心甚至導(dǎo)致某些代碼應(yīng)該修改卻不敢修改的地步。測試驅(qū)動開發(fā)提供的測試集就可以作為你信心的來源,。

當(dāng)然測試驅(qū)動開發(fā)最重要的功能還在于保障代碼的正確性,，能夠迅速發(fā)現(xiàn)、定位bug,。而迅速發(fā)現(xiàn)、定位bug是很多開發(fā)人員的夢想,。針對關(guān)鍵代碼的測試集,，以及不斷完善的測試用例，為迅速發(fā)現(xiàn),、定位bug提供了條件,。

我的一段功能非常復(fù)雜的代碼使用TDD開發(fā)完成，真實環(huán)境應(yīng)用中只發(fā)現(xiàn)幾個bug,，而且很快被定位解決,。您在應(yīng)用后,，也一定會為那種自信的開發(fā)過程，功能不斷增加,、完善的感覺,，迅速發(fā)現(xiàn)、定位bug的能力所感染,，喜歡這個技術(shù)的,。

那么是什么樣的原理、方法提供上面說的這些好處哪,？下面我們就看看TDD的原理,。

2. 原理
測試驅(qū)動開發(fā)的基本思想就是在開發(fā)功能代碼之前，先編寫測試代碼,。也就是說在明確要開發(fā)某個功能后,，首先思考如何對這個功能進行測試，并完成測試代碼的編寫,，然后編寫相關(guān)的代碼滿足這些測試用例,。然后循環(huán)進行添加其他功能，直到完全部功能的開發(fā),。

我們這里把這個技術(shù)的應(yīng)用領(lǐng)域從代碼編寫擴展到整個開發(fā)過程,。應(yīng)該對整個開發(fā)過程的各個階段進行測試驅(qū)動，首先思考如何對這個階段進行測試,、驗證,、考核，并編寫相關(guān)的測試文檔,，然后開始下一步工作,，最后再驗證相關(guān)的工作。下圖是一個比較流行的測試模型：V測試模型,。

【圖 V測試模型】

在開發(fā)的各個階段,，包括需求分析、概要設(shè)計,、詳細設(shè)計,、編碼過程中都應(yīng)該考慮相對應(yīng)的測試工作，完成相關(guān)的測試用例的設(shè)計,、測試方案,、測試計劃的編寫。這里提到的開發(fā)階段只是舉例,，根據(jù)實際的開發(fā)活動進行調(diào)整,。相關(guān)的測試文檔也不一定是非常詳細復(fù)雜的文檔，或者什么形式，但應(yīng)該養(yǎng)成測試驅(qū)動的習(xí)慣,。

關(guān)于測試模型,，還有X測試模型。這個測試模型,，我認(rèn)為,，是對詳細階段和編碼階段進行建模，應(yīng)該說更詳細的描述了詳細設(shè)計和編碼階段的開發(fā)行為,。及針對某個功能進行對應(yīng)的測試驅(qū)動開發(fā),。

【圖 X測試模型】

基本原理應(yīng)該說非常簡單，那么如何進行實際操作哪,，下面對開發(fā)過程進行詳細的介紹,。

3. 過程
軟件開發(fā)其他階段的測試驅(qū)動開發(fā)，根據(jù)測試驅(qū)動開發(fā)的思想完成對應(yīng)的測試文檔即可,。下面針對詳細設(shè)計和編碼階段進行介紹,。

測試驅(qū)動開發(fā)的基本過程如下：

1） 明確當(dāng)前要完成的功能?？梢杂涗洺梢粋€ TODO 列表,。

2） 快速完成針對此功能的測試用例編寫。

3） 測試代碼編譯不通過,。

4） 編寫對應(yīng)的功能代碼,。

5） 測試通過。

6） 對代碼進行重構(gòu),，并保證測試通過,。

7） 循環(huán)完成所有功能的開發(fā)。

為了保證整個測試過程比較快捷,、方便,，通常可以使用測試框架組織所有的測試用例,。一個免費的,、優(yōu)秀的測試框架是 Xunit 系列，幾乎所有的語言都有對應(yīng)的測試框架,。

開發(fā)過程中,，通常把測試代碼和功能代碼分開存放，這里提供一個簡單的測試框架使用例子,，您可以通過它了解測試框架的使用,。下面是文件列表。

	project/				項目主目錄
                        project/test			測試項目主目錄
                        project/test/testSeq.cpp		測試seq_t 的測試文件,，對其他功能文件的測試文件復(fù)制后修改即可
                        project/test/testSeq.h
                        project/test/Makefile			測試項目的 Makefile
                        project/test/main.cpp			測試項目的主文件，不需要修改
                        project/main.cpp		           項目的主文件
                        project/seq_t.h			功能代碼,，被測試文件
                        project/Makefile		           項目的 Makefile

主要流程基本如此,，但要讓你的代碼很容易的進行測試,，全面又不繁瑣的進行測試，還是有很多測試原則和技術(shù)需要考慮,。

4. 原則
測試隔離,。不同代碼的測試應(yīng)該相互隔離。對一塊代碼的測試只考慮此代碼的測試,，不要考慮其實現(xiàn)細節(jié)（比如它使用了其他類的邊界條件）,。

一頂帽子。開發(fā)人員開發(fā)過程中要做不同的工作,，比如：編寫測試代碼,、開發(fā)功能代碼、對代碼重構(gòu)等,。做不同的事,，承擔(dān)不同的角色。開發(fā)人員完成對應(yīng)的工作時應(yīng)該保持注意力集中在當(dāng)前工作上,，而不要過多的考慮其他方面的細節(jié),，保證頭上只有一頂帽子。避免考慮無關(guān)細節(jié)過多,，無謂地增加復(fù)雜度,。

測試列表。需要測試的功能點很多,。應(yīng)該在任何階段想添加功能需求問題時,，把相關(guān)功能點加到測試列表中，然后繼續(xù)手頭工作,。然后不斷的完成對應(yīng)的測試用例,、功能代碼、重構(gòu),。一是避免疏漏,，也避免干擾當(dāng)前進行的工作。

測試驅(qū)動,。這個比較核心,。完成某個功能，某個類,，首先編寫測試代碼,，考慮其如何使用、如何測試,。然后在對其進行設(shè)計,、編碼。

先寫斷言。測試代碼編寫時,，應(yīng)該首先編寫對功能代碼的判斷用的斷言語句,，然后編寫相應(yīng)的輔助語句。

可測試性,。功能代碼設(shè)計,、開發(fā)時應(yīng)該具有較強的可測試性。其實遵循比較好的設(shè)計原則的代碼都具備較好的測試性,。比如比較高的內(nèi)聚性,，盡量依賴于接口等。

及時重構(gòu),。無論是功能代碼還是測試代碼,，對結(jié)構(gòu)不合理，重復(fù)的代碼等情況,，在測試通過后,，及時進行重構(gòu)。關(guān)于重構(gòu),，我會另撰文詳細分析,。

小步前進。軟件開發(fā)是個復(fù)雜性非常高的工作,，開發(fā)過程中要考慮很多東西,，包括代碼的正確性、可擴展性,、性能等等,，很多問題都是因為復(fù)雜性太大導(dǎo)致的。極限編程提出了一個非常好的思路就是小步前進,。把所有的規(guī)模大,、復(fù)雜性高的工作，分解成小的任務(wù)來完成,。對于一個類來說,，一個功能一個功能的完成，如果太困難就再分解,。每個功能的完成就走測試代碼－功能代碼－測試－重構(gòu)的循環(huán),。通過分解降低整個系統(tǒng)開發(fā)的復(fù)雜性。這樣的效果非常明顯,。幾個小的功能代碼完成后,，大的功能代碼幾乎是不用調(diào)試就可以通過。一個個類方法的實現(xiàn),，很快就看到整個類很快就完成啦,。本來感覺很多特性需要增加,，很快就會看到?jīng)]有幾個啦。你甚至?xí)檫@個速度感到震驚,。（我理解,，是大幅度減少調(diào)試、出錯的時間產(chǎn)生的這種速度感）

5. 測試技術(shù)

5.1. 測試范圍,、粒度
對哪些功能進行測試？會不會太繁瑣,？什么時候可以停止測試,？這些問題比較常見。按大師 Kent Benk 的話,，對那些你認(rèn)為應(yīng)該測試的代碼進行測試,。就是說，要相信自己的感覺,，自己的經(jīng)驗,。那些重要的功能、核心的代碼就應(yīng)該重點測試,。感到疲勞就應(yīng)該停下來休息一下,。感覺沒有必要更詳細的測試，就停止本輪測試,。

測試驅(qū)動開發(fā)強調(diào)測試并不應(yīng)該是負擔(dān),，而應(yīng)該是幫助我們減輕工作量的方法。而對于何時停止編寫測試用例,，也是應(yīng)該根據(jù)你的經(jīng)驗,，功能復(fù)雜、核心功能的代碼就應(yīng)該編寫更全面,、細致的測試用例,，否則測試流程即可。

測試范圍沒有靜態(tài)的標(biāo)準(zhǔn),，同時也應(yīng)該可以隨著時間改變,。對于開始沒有編寫足夠的測試的功能代碼，隨著bug的出現(xiàn),，根據(jù)bug補齊相關(guān)的測試用例即可,。

小步前進的原則，要求我們對大的功能塊測試時,，應(yīng)該先分拆成更小的功能塊進行測試,，比如一個類A使用了類B、C,，就應(yīng)該編寫到A使用B,、C功能的測試代碼前,，完成對B、C的測試和開發(fā),。那么是不是每個小類或者小函數(shù)都應(yīng)該測試哪,？我認(rèn)為沒有必要。你應(yīng)該運用你的經(jīng)驗,，對那些可能出問題的地方重點測試,，感覺不可能出問題的地方就等它真正出問題的時候再補測試吧。

5.2. 怎么編寫測試用例
測試用例的編寫就用上了傳統(tǒng)的測試技術(shù),。

• 操作過程盡量模擬正常使用的過程,。
• 全面的測試用例應(yīng)該盡量做到分支覆蓋，核心代碼盡量做到路徑覆蓋,。
• 測試數(shù)據(jù)盡量包括：真實數(shù)據(jù),、邊界數(shù)據(jù)。
• 測試語句和測試數(shù)據(jù)應(yīng)該盡量簡單,，容易理解,。
• 為了避免對其他代碼過多的依賴，可以實現(xiàn)簡單的樁函數(shù)或樁類（Mock Object）,。
• 如果內(nèi)部狀態(tài)非常復(fù)雜或者應(yīng)該判斷流程而不是狀態(tài),，可以通過記錄日志字符串的方式進行驗證。

6. Tips
很多朋友有疑問,，“測試代碼的正確性如何保障,？是寫測試代碼還是寫測試文檔？”這樣是不是會陷入“雞生蛋,，蛋生雞”的循環(huán),。其實是不會的。通常測試代碼通常是非常簡單的,，通常圍繞著某個情況的正確性判斷的幾個語句,，如果太復(fù)雜，就應(yīng)該繼續(xù)分解啦,。而傳統(tǒng)的開發(fā)過程通常強調(diào)測試文檔,。但隨著開發(fā)節(jié)奏的加快，用戶需求的不斷變化,，維護高層（需求,、概要設(shè)計）的測試文檔可以，更低層的測試文檔的成本的確太大了,。而且可實時驗證功能正確性的測試代碼就是對代碼最好的文檔,。

軟件開發(fā)過程中，除了遵守上面提到的測試驅(qū)動開發(fā)的幾個原則外,，一個需要注意的問題就是,，謹(jǐn)防過度設(shè)計,。編寫功能代碼時應(yīng)該關(guān)注于完成當(dāng)前功能點，通過測試,，使用最簡單,、直接的方式來編碼。過多的考慮后期的擴展,，其他功能的添加,，無疑增加了過多的復(fù)雜性，容易產(chǎn)生問題,。應(yīng)該等到要添加這些特性時在進行詳細的測試驅(qū)動開發(fā),。到時候，有整套測試用例做基礎(chǔ),，通過不斷重構(gòu)很容易添加相關(guān)特性。