軟件開發流程（轉載）

軟件開發流程

迭代化軟件開發技術 1. 傳統開發流程的問題 傳統的 軟件開發流程是一個文檔驅動的流程，它將整個軟件開發過程劃分爲順序相接的幾個階段，每個階段都必需完畢全部規定的任務（文檔）後才能夠進入下一個階段。 如必須完畢全部的系統需求規格說明書以後才能夠進入概要設計階段，編碼必需在系統設計完畢以後才能夠進行。這就意味着僅僅有當全部的系統模塊全部開發完畢之 後，咱們才進行系統集成，對於一個由上百個模塊組的複雜系統來講，這是一個很艱鉅而漫長的工做。 隨着咱們所開發的軟件項目愈來愈複雜，傳統的瀑布型開發流程不斷地暴露出下面問題： 需求或設計中的錯誤每每僅僅有到了項目後期才能夠被發現好比：系統交付客戶以後才發現原先對於需求的理解是錯誤的，系統設計中的問題要到測試階段才幹被發現。 對於項目風險的控制能力較弱項目風險在項目開發較晚的時候才能夠真正減小，每每是通過系統測試以後，才幹肯定該設計是否能夠真正知足系統需求。 軟件項目常常延期完畢或開發費用超出預算項目開發進度每每會被意外發生的問題所打亂，需要進行返工或其它一些額外的開發週期，形成項目延期或費用超支。 項目管理人員專一於文檔的完畢和審覈來預計項目的進展狀況因此項目經理對於項目狀態的預計每每是不許確的，當他回答系統已完畢了80%的開發任務時，剩下20%的開發任務實際上消耗的是整個項目80%的開發資源。 在傳統的瀑布模型中，需求和設計中的問題是沒法在項目開發的前期被檢測出來的，僅僅有當第一次系統集成時，這些設計缺陷纔會在測試中暴露出來，從而致使一系列的返工：又一次設計、編碼、測試，進而致使項目的延期和開發成本的上升。 2. 採用迭代化開發控制項目風險 爲 瞭解決傳統軟件開發流程中的問題，咱們建議採用迭代化的開發方法來代替瀑布模型。在瀑布模型中，咱們要完畢的是整個軟件系統開發這個大目標。在迭代化的方 法中，咱們將整個項目的開發目標劃分紅爲一些更易於完畢和達到的階段性小目標，這些小目標都有一個定義明白的階段性評估標準。迭代就是爲了完畢必定的階段 性目標而所從事的一系列開發活動，在每個迭代開始前都要依據項目當前的狀態和所要達到的階段性目標制定迭代計劃，整個迭代過程包括了需求、設計、實施（編 碼）、部署、測試等各類類型的開發活動，迭代完畢以後需要對迭代完畢的結果進行評估，並以此爲根據來制定下一次迭代的目標。 與傳統的瀑布式開發模型相比較，迭代化開發具備下面特色： 贊成變動需求 需求老是會變化，這是事實。給項目帶來麻煩的常常主要是需求變化和需求"蠕變"，它們會致使延期交付、工期延誤、客戶不滿 意、開發者受挫。經過向用戶演示迭代所產生的部分系統功能，咱們可以儘早地收集用戶對於系統的反饋，及時改正對於用戶需求的理解誤差，從而保證開發出來 的系統真正地解決客戶的問題。 逐步集成元素 在傳統的項目開發中，由於要求一會兒集成系統中所有的模塊，集成階段每每要佔到整個項目很是大比例的工做量（最 高可達40%），這一階段的工做經常是不肯定並且很棘手。在迭代式方法中，集成可以說是接二連三的，每一次迭代都會增量式集成一些新的系統功能，要集成 的元素都比過去少得多，因此工做量和難度都是比較低的。 儘早減小風險 迭代化開發的主要指導原則就是以架構爲中心，在早期的迭代中所要解決的主要問題就是儘快肯定系統架構，經過幾 次迭代來儘快地設計出能夠知足核心需求的系統架構，這樣能夠迅速減小整個項目的風險。等到系統架構穩定以後，項目的風險就比較低了，這個時候再去實現系統 中還沒有完畢的功能，進而完畢整個項目。 有助於提升團隊的士氣 開發者經過每次迭代都可以在短時間內看到本身的工做成果，從而有助於他們加強信心，更好地完畢開發任務。而在非迭代式開發中，開發者僅僅有在項目接近尾聲時才幹看到開發的結果，在此以前的至關長時間，你們仍是在不肯定性中摸索前近。 生成更高質量的產品 每次迭代都會產生一個可執行的系統，經過對這個可執行系統進行測試，咱們在早期的迭代中就可以及時發現缺陷並改正，性能上的瓶頸也可以儘早發現並處理。因爲在每次迭代中老是不斷地糾正錯誤，咱們可以獲得更高質量的產品。 保證項目開發進度 每次迭代結束時都會進行評估，來推斷該次迭代有沒有達到預約的目標。項目經理可以很是清楚地知道有哪些需求已經實現了，並且比較準確地預計項目的狀態，對項目的開發進度進行必要的調整，保證項目按時完畢。 允許產品進行戰術改變 迭代化的開發具備更大的靈活性，在迭代過程當中可以隨時依據業務狀況或市場環境來對產品的開發進行調整。好比爲了同現有的同類產品競爭，可以決定採用搶先競爭對手一步的方法，提早公佈一個功能簡化的產品。 迭代流程自身可在進行過程當中獲得改進和精煉 一次迭代結束時的評估不只要從產品和進度的角度來考察項目的狀況，而且還要分析組織和流程自己有什麼待改進之處，以便在下次迭代中更好地完畢任務。 迭代化方法解決的主要是對於風險的控制問題，從下圖能夠看出，傳統的開發流程中系統的風險要到項目開發的後期（主要是測試階段）才能夠被真正減小。 而迭代化開發中的風險，可以在項目開發的早期經過幾回迭代來儘快地解決掉。在早期的迭代中一旦遇到問題，如某一個迭代沒有完畢預約的目標，咱們還可以及時 調整開發進度以保證項目按時完畢。通常到了項目開發的後期（風險受控階段），由於大部分高風險的因素（如需求、架構、性能等）都已經解決，這時候僅僅需要投 入不少其它的資源去實現剩餘的需求就能夠。這個階段的項目開發具備很是強的可控性，從而保證咱們按時交付一個高質量的軟件系統。 迭代化開發不是一種高深的軟件project理論，它提供了一種控制項目風險的頗有效的機制。在平常的工做咱們也經常地應用到這一基本思想，如對於一個很 大型的project項目，咱們經常會把它分爲幾期來分步實施，從而把複雜的問題分解爲相對easy解決的小問題，並且能夠在較短週期內看到部分系統實現的效果，經過盡 早暴露問題來幫助咱們及早調整咱們的開發資源，增強項目進度的可控程度，保證項目的按時完畢。 3. 管理迭代化的軟件項目 當我 們在實際工做中實踐迭代化思想時，Rational統一開發流程RUP(Rational Unified Process)可以給予咱們實踐的指導。RUP是一個通用的軟件流程框架，它是一個以架構爲中心、用例驅動的迭代化軟件開發流程。RUP是從幾千個軟件 項目的實踐經驗中總結出來的，對於實際的項目具備很是強的指導意義，是軟件開發行業其實的行業標準。 3.1 軟件開發的四個階段 在RUP中，咱們把軟件開發生命週期劃分爲四個階段，每個階段的結束標誌就是一個基本的里程碑（例如如下圖所看到的）。 這四個階段主要是爲了達到下面階段性的目標里程碑： 先啓(Inception)：肯定項目開發的目標和範圍 精化(Elaboration)：肯定系統架構和明白需求 構建(Construction)：實現剩餘的系統功能 產品化(Transition)：完畢軟件的產品化工做，將系統移交給客戶 每一個目標里程碑都是一個商業上的決策點，如先啓階段結束以後，咱們就要決定這個項目是否可行、是否要繼續作這個項目。每一個階段都是由里程碑來決定的，推斷一個階段是否結束的標誌就是看項目當前的狀態是否知足裏碑中所規定的條件。 從這樣的階段劃分模式中可以看出，項目的主要風險集中在前兩個階段。在精化階段中通過幾回迭代後，咱們要爲系統創建一個穩定的架構，在此以後再實現更 多的系統需求時，再也不需要對該架構進行改動。同一時候，在精化階段中，咱們經過迭代來不斷地收集用戶的需求反饋，便得系統的需求逐步地明白和完整。 3.2 關於開發資源的分配 基於 RUP風險驅動的迭代化開發模式，咱們僅僅需要在項目的先啓階段投入少許的資源，對項目的開發前景和商業可行性進行一些探索性的研究。在精化階段再投入多一 些的研發力量來實現一些與架構相關的核心需求，逐步地把系統架構搭建起來。等到這兩個階段結束以後，項目的一些主要風險和問題也獲得瞭解決，這時候再投入 整個團隊進行全面的系統開發。等到產品化階段，基本的開發任務已經全部完畢，項目再也不需要維持一個大規模的開發團隊，開發資源也可以隨之而下降。在項目開 發週期中，開發資源的分配可以例如如下圖所看到的。 這樣安排可以最充分有效地利用公司的開發資源，緩解軟件公司對於人力資源不斷增加的需求，從而減小成本。另一方面，由於前兩個階段（先啓和精化） 的風險較高，咱們僅僅是投入部分的資源，一旦發生返工或是項目目標的改變，咱們也可以將資源浪費降到最低點。在傳統的軟件開發流程中，對於開發資源的分配基 本上是貫穿整個項目週期而不變的，資源每每沒有獲得充分有效地利用。 基於這樣的資源分配模式，一個典型的項目在項目進度和所完畢的工做量之間的關係可能例如如下表中的數據所看到的。 先啓 精化 構建 產品化 工做量 ~5% 20% 65% 10% 進度 10% 30% 50% 10% 3.3 迭代策略 關於迭代計劃的安排，一般有下面四種典型的策略模式： 增量式(Incremental) 這樣的模式的特色是項目架構的風險較小（每每是開發一些反覆性的項目），因此精化階段僅僅需要一個迭代。但項目的開發工做量較大，構建階段需要有屢次迭代來實現，每次迭代都在上一次迭代的基礎上添加�實現一部分的系統功能，經過迭代的進行而逐步實現整個系統的功能。 演進式(Evolutionary) 當項目架構的風險較大時（從未開發過類似項目），需要在精化階段經過屢次迭代來創建系統的架構，架構是經過屢次迭代的探索，逐步演化而來的。當架構創建時，每每系統的功能也已經基本實現，因此構建階段僅僅需要一次迭代。 增量提交(Incremental Delivery) 這樣的模式的特色產品化階段的迭代較多，比較常見的樣例是項目的難度並不 大，但業務需求在不斷地發生變化，因此需要經過迭代來不斷地部署完畢的系統；但同一時候又要不斷地收集用戶的反饋來無缺系統需求，並經過興許的迭代來補充實現 這些需求。應用這樣的策略時要求系統架構很穩定，能夠適應知足興許需求變化的要求。 單次迭代(Grand Design) 傳統的瀑布模型可以看做是迭代化開發的一個特例，整個開發流程僅僅有一次迭代。但這樣的模式有一個固有的弱點，由於它對風險的控制能力較差，每每會在產品化階段產生一些額外的迭代，形成項目的延誤。 這幾種迭代策略僅僅是一些典型模式的表明，實際應用中應依據實際狀況靈活應用，最多見的迭代計劃每每是這幾種模式的組合。 3.4 制定項目開發計劃 在迭代 化的開發模式中，項目開發計劃也是隨着項目的進展而不斷細化、調整並無缺的。傳統的項目開發計劃是在項目早期制定的，項目經理老是試圖在項目的一開始就制 定一個很具體無缺的開發計劃。與之相反，迭代開發模式以爲在項目早期僅僅需要制定一個比較粗略的開發計劃，因爲隨着項目的進展，項目的狀態在不斷地發生變 化，項目經理需要隨時依據迭代的結果來對項目計劃進行調整，並制定下一次迭代的具體計劃。 在RUP中，咱們把項目開發計劃分爲下面三部分： 項目計劃 肯定整個項目的開發目標和進度安排，包含每一個階段的起止時間段。 階段計劃 當前階段中包括有幾個迭代，每一次迭代要達到的目標以及進度安排。 迭代計劃 針對當前迭代的具體開發計劃，包含開發活動以及相關資源的分配。 項目開發計劃也是全然體現迭代化的思想，每次迭代中項目經理都會依據項目狀況來不斷地調整和細化項目開發計劃。迭代計劃是在對上一次迭代結果進行評 估的基礎上制定的，假設上一次迭代達到了預約的目標，那麼當前迭代僅僅需要解決剩下的問題；假設上一次迭代中留有一些問題尚未解決，則當前迭代還需要繼續 去解決這些問題。因此必須注意，迭代是不能重疊的，即你尚未完畢當前迭代時，你決不能進入下一迭代，因爲下一次迭代的計劃是依據當前迭代的結果而制定 的。   Rational開發過程 　 1. 引言 本文對 Rational 軟件開發過程（Rational Software Development Process）的原理和結構給出了高度的描寫敘述，它是： 迭代的、增量的開發過程 面向對象的開發過程 管理和控制的開發過程 它具備足夠的廣泛性，可以在規模與應用領域方面，爲各個軟件產品和項目量身訂作。 2.總體軟件生命週期 2.1 兩種視角 Rational 過程可以從兩種不一樣而又密不可分的視角來觀察： 從管理的視角來看，涉及財務、戰略、商業和人文方面 從技術的視角來看，涉及質量、project和設計方法方面 2.2 週期和階段 從管理的角度，即從業務和經濟的角度來看，相應項目的進展，軟件的生命週期包括四個主要階段: 起始階段（Inception）-- 有一個好的想法：具體構想出終於產品的設想和它的業務案例，肯定項目的範圍 。 細化階段（Elaboration）--計劃必要的活動和所需資源，具體肯定功能並設計構架 。 構建階段（Construction）-- 構建產品， 發展最初的設想、構架和計劃，直到一個可以交付給用戶的產品（完畢後的設想）完畢。 移交階段（Transition）-- 將產品移交用戶使用，包含：製造、交付、培訓、支持、維護，直到用戶愜意。 完畢這4個階段稱爲一個開發週期, 它產生的軟件稱做第一代（generation）。 除非產品的生命結束， 一個現有產品可以經過反覆下一個一樣的起始、細化、構建和移交四階段，各個階段的側重點與第一次不一樣，從而演進爲下一代產品。 這個時期咱們稱之爲演進(evolution)。最後伴隨着產品通過幾個週期的演進，新一代產品也不斷被製造出來。 好比，演進週期的啓動可能由下面這幾項觸發：用戶建議加強功能、用戶環境的改變、重要技術的變動，以及應對競爭的需要。 實際中，週期之間會有輕微重疊：起始階段和細化階段可能會在上一個週期的移交階段未結束時就開始了。 2.3. 迭代 從技術的角度來 看，軟件開發可以視爲一連串的迭代過程，經過這些迭代被開發的軟件得以增量演進。 每次迭代都以一個可運行的產品的公佈而結束， 該產品多是完整版本號的一個子集，但從project的或用戶的角度來看是實用的。 每次公佈都伴隨一些支持性工件：版本號描寫敘述、用戶文檔和計劃等。 一次迭代包含下面活動： 計劃、分析、設計、實施和測試。 依據迭代在開發週期中所處位置的不一樣，這些活動分別佔不一樣的比例。 管理角度和技術角度之間是協調的， 而且各個階段的結束還和各次迭代的結束保持同步。 換句話說，每個階段可以分爲一次或屢次迭代過程。 (注意：本圖中每階段的迭代數目僅爲示意) 但是，這兩個角度（管理角度和技術角度），不僅不過保持同步，它們還具備一些全然一樣的里程碑，它們共同貢獻出一些隨時間演進的產品和工件。 一些工件不少其它地處於技術方面控制之下，還有一些工件不少其它地處於管理方面的控制之下。見第五節。 這些工件的可用性、工件是否知足所創建的評估標準，是構成里程碑的主要詳細元素，比日曆牌上的日期提供了多得多的內容。 像週期同樣，迭代之間也會有輕微重疊。即第N次迭代的計劃和構架在第N-1次迭代還未結束時就開始了。有時候，迭代也會平行進行：一個工做於系統某一部分的小組，可能在某個迭代內沒有可交付的工件。 2.4.差異 對於不一樣的項目而言，每個階段的側重點，入口和出口準則，一個開發週期的各個工件，以及各次迭代的數目和長度都會不一樣。這主要取決於做爲過程判別式的的四個主要項目特徵。依照影響程度降序排列，它們是： 業務環境 契約性工做，開發人員基於給定的客戶規格說明僅僅爲該客戶開發軟件。 猜測性開發或商業開發，開發人員開發軟件以推向市場。 內部項目， 開發人員和客戶在同一個機構中。 軟件開發工做量的規模: 依照一些度量標準來肯定，比方 Delivered Source Instructions，或功能點、人-月數，或者僅僅依照成本。 新穎程度： 對於軟件開發組織，這個軟件新穎程度怎樣有多新，尤爲是該軟件是否爲第二次或更後面的週期。這項差異包含了組織和過程的成熟度、資產、技術水平，當前的技情況，以及諸如組建並培訓團隊、獲取工具及其它資源這種問題。 應用類型，目標領域： MIS，命令和控制系統, 嵌入式實時系統, 軟件開發環境工具等等, 尤爲時詳細的應用領域會給開發提出特殊的約束條件：安全性、性能、國際化、內存限制等。 本文首先描寫敘述適用所有類型軟件開發的通用過程，而後描寫敘述了一些有差異價值的特定過程實例，並列舉了幾個樣例。 2.5工做量和日程安排 各階段在工做量和時間安排上是不一樣的。雖然由於不一樣項目類型之間相差會很是大，一個典型的中等規模項目的最初開發週期可以估計爲如下的比率： 起始階段 細化階段 構建階段 移交階段 工做量 5% 20% 65% 10% 日程安排 10% 30% 50% 10% 可以用下圖表示： 但是對於一個演進週期來講，起始階段和細化階段可能大大縮減。使用特定工具和技術（如應用程序構建器），構建階段可以遠遠小於起始階段和細化階段的總和。 3. Rational 過程的各個階段 3.1. 起始階段 這個階段產生一個預測產品的最初設想，並將其轉換爲一個實際的項目。本階段的目的是創建一個新產品或一次大的更新的業務案例，並且指定項目的範圍。 對於一個新產品的開發，本階段的主要結果是獲得一個"作仍是不作"的決定以進入下一階段，並投入必定的時間和資金來具體分析構建什麼、是否能構建，以及怎樣構建。 對於一個現有產品的演進，這會是一個簡短的階段， 主要看用戶或客戶的要求、問題報告，或是新的技術動態。 對於一個契約性的開發，是否進行項目的決定取決於在特定領域的經驗、以及組織在此領域的競爭力和市場狀況。這裏起始階段可以歸結爲一個參加投標的決定，或投標活動自己。該決定多是基於一個現有的研究原型，其結構對終於軟件可能合適，也可能不合適。 入口準則: 對於一項需要的描寫敘述，可以採用下面形式： 一份最初的設想 一個遺留系統 一份建議請求（An RFP --request for proposal) 先前一代的產品和一個加強要求清單 一些資產(軟件, 專門技能, 財務資產) 一個概念原型或實物模型 出口準則： 一個初始的業務案例至少要包括下面內容: 對產品設想的明白表達即核心需求，表述爲功能、範圍、性能、容量和技術等。 成功標準 (如收入的數目) 最初的風險評估 完畢細化階段所需的資源估算 一般在初試階段結束時，咱們將獲得： 一個最初的域分析模型(完畢大約10%-20%), 肯定最關鍵的用例, 並且足以進行進構架工做。 一個最初的構架原型，在這個階段可以是一個一次性原型 3.2. 細化階段 本階段的主要目的是更完全地分析問題域，定義構架並使之穩定，肯定項目的最大風險。這樣在本階段結束時，咱們可以獲得一個關於下2個階段怎樣工做的綜合計劃： 一個基於分析模型的基線產品設想（即最初的需求集合）。 至少對第一次構建迭代的評價準則。 一個基線軟件構架。 開發和部署產品的必需資源，尤爲是人員和工具。 一份日程安排。 足以對構建階段的成本、日程安排和質量作出"精確"的評估的一份風險決議。 在這個階段，創建了一個可運行的構架原型；它至少實現了初始階段識別出的最關鍵的用例 ，攻克了項目的最大技術風險；依據範圍、規模、風險和項目新穎程度的不一樣構架原型需要一次或屢次迭代。這是一個生成高質量代碼（這些代碼成爲架構基線）的 演進原型，但是也不排除開發出一個或幾個試探性的、一次性原型，以減小開發的風險：對需求、可行性、人機界面研究、向投資者演示等的精化。在本階段的結束 時，仍然會產生一個"作仍是不作"的決定， 以肯定是否要真正投資構建這個產品（或參與合同項目的競標）。 此時產生的計劃必定要足夠具體，風險也必須充分減小，可以對開發工做的完畢進行精確的成本和日程估算。 入口準則： 前一階段出口準則所描寫敘述的產品和工件 被項目管理者和投資者承認的計劃，和細化階段所需的資源 出口準則： 一份具體的軟件開發計劃，包括： 更新後的風險評估 一份管理計劃 一份人員配置計劃 一份顯示迭代內容和次數的階段計劃 一份迭代計劃，具體計劃下次迭代 開發環境和所需的其它工具 一份測試計劃 一個基線設想，以對終於產品的一個評估準則的集合的形式 用於評估構建階段最初的迭代結果的客觀、可測量的演進標準 一個域分析模型（80%完畢），對應的構架可以稱之爲是"完整的" 一個軟件構架描寫敘述（說明約束和限制） 一個可運行的構架基線 3.3. 構建階段 本階段可以劃 分爲數次迭代，不斷充實構架基線，向終於產品逐步演進或增量演進。在每次迭代過程當中，上個階段（細化階段）的工件獲得擴充和修正， 但它們終於將隨着系統向正確和完整的方向的演進而穩定下來。在這個階段，除了軟件自己，還生成一些新的工件：文檔（既有內部使用的文檔，也有面向終於用戶 的文檔）、測試牀及測試套件、部署附件，以及用於支持下一階段的部署輔助（好比銷售輔助）。 對每次迭代，都具備： 入口準則： 上次迭代的產品和工件。 迭代計劃必須闡明迭代的特定目標： 將要開發的新添加�能，覆蓋了哪些用例或場景 本次迭代過程當中下降的風險 本次迭代過程當中改動的缺陷 出口準則： 更新後的產品和工件，另外還有: 一個版本號描寫敘述文檔，記錄了迭代的結果 測試用例和依據產品得出的測試結果 一個具體描寫敘述下一次迭代的計劃 對下一次迭代的客觀度量標準 到構建階段的後期，必須完畢下面工件，及本階段最後一次迭代額外的出口準則： 一個部署計劃，指定必需的事項： 打包 訂價 演示 支持 培訓 移交策略 (好比一個現有系統的更新計劃) 產品 (軟盤和手冊) 用戶文檔 3.4. 移交階段 移交階段是將產品交付給終於用戶的階段。 它涉及銷售、打包、安裝、配置、支持用戶社區和作出修正等. 從技術角度來看，伴隨本階段迭代的是一次或屢次公佈：`beta' 版公佈、正式版公佈、修補bug , 或加強版公佈。 當用戶對產品愜意時，本階段即告結束。 好比，契約性開發時正式驗收， 或者產品有關的所有活動都已結束。 此時，某些積累的資產可以加以整理，覺得下一個週期或其它項目重用。 入口準則： 上一次迭代的產品和工件， 尤爲是足夠成熟可以交付給用戶的軟件產品 出口準則： 前一階段某些文檔的更新，以及必要時依據原始及修訂後的成功標準，進行"過後"項目性能分析，從而替換原有計劃。 一個簡短的清單，列出本次開發週期給組織帶來的新的資產 3.5. 演進週期 對於重要的演進，咱們應用整個過程遞歸，仍從起始階段開始一個新的週期。因爲咱們已經有了一個產品，因此比起一個初次開發的產品，起始階段可能大大縮短。細化階段也可能縮小範圍，而在計劃方面的關注程度要大於分析或構架的演進方面。需要指出：週期之間可以略有重疊。 較小的演進可以經過延長移交階段或添加�一兩次迭代來完畢。 移交階段可以以一個終結過程而結束，即產品再也不演進了，但是爲了終結它，需要採取一些特定的動做。 4. Rational過程當中的活動 Rational 過程當中各個階段的名稱(如起始、細化、構建、移交)與描寫敘述高級活動的術語（如分析、設計、測試等）相差甚遠。 所以咱們easy理解某種活動的進行並不侷限於某個特定階段，也與其它做者、標準及特定領域的所使用的術語無關。這些活動確實發生，但它們在每個階段和每次迭 代中的程度有所不一樣。下圖代表了活動重點怎樣隨時間的推動而發生演進。 圖中活動重點的變化也說明雖然每次迭代在形式上都是"相似"的，但它們的性質和內容倒是隨時間而改變的。 這還代表，一項活動的結束並不總意味着還有一項活動的開始，即並不是分析完畢了才開始設計，而是這些活動相關的各類"工件"在隨着開發人員對問題或需求的理解的加深也不斷獲得更新。 最後，在一個迭代過程當中，計劃、測試和集成這些活動不是集中堆積在開發活動的開始和結束階段，而是增量地分佈在整個開發週期的各個階段、每次迭代之中。 它們並不表現爲開發過程的某個獨立的階段或步驟。 雖然詳細的項目有詳細的差異，但對於一箇中等規模、初次開發的典型項目來講，其開發週期中各類活動的比比例如如下： 計劃與管理 15% 分析/需求 10% 設計/集成 15% 實施/功能測試 30% 度量/評估/驗收測試 15% 工具/環境/變動管理 10% 維護（開發過程當中的修補） 5% 5. 生命週期工件 開發過程不是文檔驅動的：它的工件中必須一直包含軟件產品自身。文檔應該十分精簡，數目不能太多，應僅僅保留那些確實從管理或技術的角度有真正價值的文檔。 Rational 建議保留下面典型的文檔集。 5.1管理工件 管理工件不是產品，而是用來驅動或監控項目進展、預計項目風險、調整項目資源，以及使客戶或投資者對項目保持必定的"可見性" 的。 一份機構策略文檔，是機構開發過程的明文規定。 它包括一個此類項目的實例。 一份遠景文檔, 描寫敘述系統級需求，質量要求和優先級。 一份業務案例文檔, 描寫敘述財務環境、合同，以及項目的投資回報等等。 一份開發計劃文檔, 包含總體的迭代計劃和當前及最近迭代的具體規劃。 一份評估標準文檔，包括需求、驗收標準及其它特定的技術目標，它們由各個階段演進的主要"里程碑"組成。包括迭代的目標和驗收水平。 每次公佈的版本號描寫敘述文檔。 部署文檔, 包括對交付、培訓、安裝、銷售、製造和交割相關的實用信息。 狀態評估文檔: 項目狀態的階段性"快照"， 具備進展、人力、開銷、結果、關鍵風險、活動等的度量標準。 5.2技術工件 它們或者是交付的產品，可運行的軟件及手冊，或者是一些用於製造產品的藍圖，這些產品包含軟件模型、源碼和其它有助於理解和演進產品的project信息。 用戶手冊, 在生命週期早期開發。 軟件文檔, 最好以源碼自建文檔和模型的形式，當中模型是用合適的CASE工具捕獲並維護的這些模型包含用例、類圖和過程圖等。 一個軟件構架文檔, 描寫敘述軟件的整體構架，及它的主要組成元素的分講解明： 類的分組、類、過程、子系統、關鍵接口的定義和關鍵設計決策的根據。 本文第3部分中列舉的入口準則和出口準則可以映射到這11類文檔之中。 上面介紹的這套文檔可以按照詳細項目的類型進行擴充和刪減，一些文檔可以合併。 文檔沒必要必定是紙張形式---也可以是電子表格、文本文件、數據庫、源碼的凝視、超文本文檔等等---但對應的信息資源必須被清楚地識別，易於訪問，也要保存一些歷史記錄。 5.3需求 Rational 軟件開發過程也不是需求驅動的。 在產品演進的週期中，需求表現爲不一樣的形式： 業務案例給出了主要約束，可能是些可用的資源。 遠景文檔從用戶角度僅描寫敘述了系統的關鍵需求，它在開發過程當中將緩慢演進。 更具體的需求在第二階段（細化階段）以用例和場景的形式進行闡明，並在第三階段（構建階段）隨着對產品和用戶需求瞭解的加深進一步精化。這些更具體的需求記錄在評估標準文檔中，它們驅動了構建階段和移交階段迭代內容的定義， 並在迭代計劃中引用。 6. Rational過程的樣例 依照2.4節中所述的差異，Rational 過程採用不一樣的形式。 這裏有兩個極端的樣例。 6.1大型契約性軟件開發的Rational過程 對這個軟件開發項目，Rational 過程分爲3個階段創建招標, 相應3個不一樣類型的合同。 一個研究與設計階段, 包括了生命週期的起始階段和細化階段, 一般以風險分擔方式投標，舉例來講，成本加獎金合同（ cost plus award fee contract ，CPAF）。 一個生產階段，包括了生命週期的構建和移交階段, 一般做爲一個公司、固定的價格合同（a firm, fixed price contract ,FFP）來投標。 一個維護階段，相應生命週期的演進階段，一般做來工做量水平合同（ a level of effort contract ，LOE）來投標。 因爲用戶需要更高的可視性來評估項目，還因爲項目涉及大量人員和組織，開發過程應更加正規化，要比小型、內部的項目更加劇視書面工件。第5部分列出的11類文檔都以某種形式或名稱存在。 6.2小型商業軟件產品的Rational過程 在按規模分類的過程家族的還有一端，是小型的商業軟件開發。它的流動性更強一些，僅僅有有限的正規性， 表現爲一些基本的里程碑和有限的文檔集： 一個產品遠景 （A product vision）。 一份開發計劃，顯示資源和日程安排 版本號描寫敘述文檔，在每次迭代的開始指明本次迭代的目標，在迭代結束時 做爲版本號說明（release notes）進行更新。 必要的用戶手冊 軟件結構、軟件設計、開發過程可以經過代碼自己或軟件開發環境來進行文檔化。   在項目中集成RUP和XP 概述 咱們集中討論怎樣經過使用兩個流行的方法獲得過程的恰當級別：Rational Unified Process 或簡稱 RUP 以及極限編程（XP）。咱們展現怎樣在小型項目中使用 RUP 以及 RUP 怎樣處理 XP 沒有涉及到的領域。兩者融合爲項目團隊提供了所需的指南--下降風險同一時候完畢交付軟件產品的目標。 RUP 是由 IBM Rational 開發的過程框架。它是一種迭代的開發方法，基於六個通過行業驗證的最佳實踐（參見 RUP 附錄）。隨着時間的推動，一個基於 RUP 的項目將經歷四個階段：起始階段（Inception）、細化階段（Elaboration）、構造階段（Construction）、交付階段 （Transition）。每個階段都包含一次或者屢次的迭代。在每次迭代中，您依據不一樣的要求或工做流（如需求、分析和設計等）投入不一樣的工做量。 RUP 的關鍵驅動因素就是減小風險。RUP 經過數千個項目中數千名 IBM Rational 客戶和合做夥伴使用而獲得精化。下圖展現了一個典型迭代過程的工做流： 典型迭代流 做爲風險怎樣影響過程的一個樣例，咱們應該考慮是否需要爲業務建模。假設由於對業務的理解中沒有考慮到一些重大風險，將致使咱們所構建的系統是錯誤 的，那麼咱們就應該運行一些業務建模工做。咱們需要正式進行建模工做嗎？這取決於咱們的涉衆--假設一個小團隊將非正式地使用結果，那麼咱們或許僅僅進行非 正式的記錄就可以。假設組織中的其它人也將使用結果或者查看結果，那麼咱們可能就要投入更大的努力，並且確保該結果的正確性和可理解性。 您可以定製 RUP 使其知足差點兒不論什麼項目的需要。假設沒有知足您特定需要的即裝即用的過程或路線圖，您可以輕鬆地建立您本身的路線圖。路線圖描寫敘述了該項目怎樣計劃使用過程， 所以表明了該項目的特定過程實例。這就意味着，RUP 可以按需要變得簡單或複雜，咱們將在本文中詳解。 XP 是一個用於小型項目中的以代碼爲中心的輕量級過程（參見 XP 附錄）。它來自 Kent Beck 的創意，在大概 1997 年 Chrysler 公司的 C 3 工資單項目中獲得軟件界的關注。如同 RUP 同樣，XP 也是基於迭代的，並且體現了諸如小規模公佈、簡單設計、測試以及持續迭代幾項實踐，。XP 爲恰當的項目和環境引入了一些有效的技術；只是，當中也存在隱藏的若是、活動和角色。 RUP 和 XP 具備不一樣的基本原理。RUP 是過程組件、方法以及技術的框架，您可以將其應用於不論什麼特定的軟件項目，咱們但願用戶限定 RUP 的使用範圍。XP，從還有一方面來講，是一個具備不少其它限制的過程，需要附加內容以使其適合完整的開發項目。這些不一樣點解釋了軟件開發界的一個觀點：開發大型 系統的人員使用 RUP 解決這個問題，而開發小型系統的人員使用 XP 做爲解決方式。咱們的經驗代表大部分的軟件項目都處於二者之間--盡力找尋適用於各自狀況的過程的恰當級別。單純地使用二者之中的一個是不充分的。 當您在 RUP 中融合了 XP 技術時，您會獲得過程的正確量，既知足了項目所有成員的需要，又攻克了所有基本的項目風險問題。對於一個工做於高信任環境中的小型項目團隊，當中用戶是團 隊的一部分，那麼 XP 全然可以勝任。對於團隊愈來愈分散，代碼量愈來愈大，或者構架沒有很是好定義的狀況，您需要作一些其它工做。在用戶交互具備"契約"風格的項目中，僅有 XP 是不夠的。RUP 是一個框架，您可以從 RUP 出發，在必要時以一組更健壯的技術來擴展 XP。 本文的下面部分描寫敘述了一個基於 RUP 四個階段的小型項目。在每個階段中，咱們都肯定了所產生的活動和工件 。儘管 RUP 和 XP 具備不一樣的角色和職責，但是咱們在這裏不會處理這些差別。對於不論什麼組織或項目，實際項目成員必須在過程當中與正確的角色關聯起來。 項目啓動－起始階段 對於新的開發項目來講，起始階段是很是重要的，在項目繼續進行前，您必須處理重要的業務與需求風險。對於那些加強現有系統的項目，起始階段是比較短暫的，但是其目的還是肯定該項目的實施價值及可行性。 在起始階段中，爲了構建軟件您可以建立業務案例。視圖是起始過程當中的關鍵工件。它是系統的高級描寫敘述。它爲每個人解釋該系統是什麼、可能使用系統的用 戶、使用系統的緣由、必須具有的功能，以及存在的約束。視圖可能很是短，或許僅僅有一兩段。視圖每每包含軟件必須爲客戶提供的關鍵功能。 如下的樣例展現了一個項目的很是短視圖，該項目對 Rational 的外部站點進行了改造。 爲使 Rational 的地位達到電子開發（包含工具、服務和最佳實踐）的世界率先程度，可以經過動態的、個性化的站點增強客戶關係，爲訪問者提供自助服務、支持和目標內容。新的過程和技術啓用可以使內容供應商經過一種簡化的、本身主動的解決方式加速公佈並提升內容的質量。 RUP 起始階段中 4 個重要活動爲： 制定項目的範圍。假設咱們打算構建一個系統，咱們需要知道其內容以及它怎樣知足涉衆的需要。在這個活動中，咱們捕獲內容和最重要的需求的足夠具體的信息，從而得出產品可接受的標準。 計劃並準備業務案例。咱們使用視圖做爲指導，定義風險緩和策略，開發起始的項目計劃，並肯定已知成本、日程計劃，以及盈利率平衡。 綜合得出備選構架。假設正在計劃中的系統沒什麼新穎性，而且使用的框架廣爲人之，那麼您可以跳過這一步。咱們一旦知道客戶的需求，就要開始分配時間 研究可行的備選構架。新技術能夠帶來解決軟件問題的新的並且通過改進的解決方式。在過程的早期花些時間評估購買仍是建立系統，並選擇技術，也能夠開發出一 個起始原型，這些都可以下降項目的一些主要風險。 準備項目環境。不論什麼項目都需要項目環境。不論您使用 XP 技術（好比結對編程），仍是較傳統的技術，您都需要肯定團隊將要使用的物理資源、軟件工具以及步驟。 進行小型項目開發時，並不需要太多的"過程時間"來運行起始過程。您每每可以在幾天中或者更少的時間裏完畢，如下的內容說明了本階段除了視圖以外的預期工件。 一個經批准的業務案例 涉衆有機會 從業務的角度認定項目是值得進行的。RUP 和 XP 都認可最好在早期就得出項目是否值得進行的結論，以避免在一個註定將要失敗的項目中花費寶貴的資源。如同在"Planning Extreme Programming" 一書描寫敘述的那樣，XP 對於項目是怎樣造成的以及涉及哪些角色這兩個問題的回答是比較模糊的（彷佛在現有項目或系統的環境中是最清晰的），但是在研究階段，XP 處理的工件與 RUP 起始過程當中的是一樣的。 不論您在 XP 中非正式地考慮業務問題，仍是在 RUP 中將業務案例作成一流的項目工件，您都需要考慮這些問題。風險清單您應該在整個項目開發過程當中都保持記錄 Risk List（風險清單）。使用有風險清單可以是一個具備通過計劃的風險緩和策略的簡單清單。爲各個風險設定優先級。不論什麼與項目有關的人員都可以隨時看到風險 的內容以及怎樣處理風險，但是沒有提供解決風險的通常方式 。 初步項目計劃 本計劃包含資源估算、規模以及階段計劃。對於不論什麼項目，這些估算都是不斷變化的，您必須監控它們。 項目驗收計劃 您的計劃正式與否依 賴於項目的類型。您必須推斷客戶會怎樣才幹以爲您的項目取得了成功。對於一個 XP 項目，客戶會採取驗收測試的形式。在更廣泛的過程當中，客戶可能不會真正地進行測試，但是接受的標準必須直接由客戶做出，或者由還有一個角色做出，好比與客戶 直接接觸的系統分析員。也可能存在其它的驗收標準，好比建立終於用戶文檔和幫助，但是XP並不涉及此內容。 起始細化迭代計劃 在基於 RUP 的項目中，在上次迭代的最後，您將具體計劃下次迭代。在迭代的最後，您可以評估迭代開始時設立的標準。XP 提供了探監控與衡量迭代成功的一些優秀技巧。衡量標準是簡單的，您可以輕鬆地將它們合併到迭代計劃和評估標準中。 起始用例模型 儘管這聽起來比較正 式而讓人望之卻步，但是它卻至關簡單。用例與客戶在XP中編寫的"故事"相相應。其間的差別就是一個用例就是一套完整的動做，由參與者或系統外部的人員或 事物發起，這正是用例的價值所在。用例可能包含若干個XP"故事"。RUP 爲了定義項目的邊界，推薦在起始過程當中肯定用戶與角色。從用戶的觀點關注整套操做有助於將系統分爲有價值的部分。這有助於斷定恰當的實施特性，所以咱們能 夠在每次迭代的最後向客戶交付一些成果（可能在起始迭代與細化迭代早期除外）。 RUP 與 XP 都可以幫助咱們確保避免一種狀況，即整個項目已完畢 80％，但都不是可交付的形式。咱們一直但願公佈的系統對用戶都是有價值的。 在這一點上，用例模型在識別用例和參與者方面差點兒沒有或僅僅有很是少提供支持的細節。它可以是手工或使用工具繪製的簡單的文本或者 UML（統一建模語言）圖。該模型幫助咱們確保已經包括了涉衆所關心的正確的功能，並且沒用忘記不論什麼功能，並贊成咱們輕鬆地查看整個系統。用例依據若干因 素設定優先級，這些因素包含風險、對客戶的重要程度以及技術難點。起始階段中不需要過於正式的或過大的工件。依照您的需求讓它們保持簡單或者正式就可以。 XP 包含對計劃與系統驗收的指南，但是 RUP 需要在項目的早期加入�不少其它的一些內容。這些少許加入�可能經過處理一套更完整的風險而爲項目提供很是大的價值。 細化階段 細化階段的目標是爲系統構架設立基線，爲在構建階段大量的設計與實施工做打下堅實的基礎。構架經過考慮最重要的需求（那些對系統構架影響最大的需求）與評估風險演進而來。構架的穩定性是經過一個或多個構架原型進行評估的。 在 RUP 中，設計活動主要關注系統構架的概念，對於軟件密集型的系統來講，就是軟件構架的概念。使用組件構架是在 RUP 中體現的軟件開發 6 項最佳實踐當中之中的一個，該實踐推薦在開發與所做所爲構架上要投入一些時間。在這項工做花費的時間可以減緩與脆弱的、僵化日系統有關的風險。 XP 使用"隱喻"替換了構架的概念。隱喻僅僅捕獲構架的一部分，而其他構架部分則隨着代碼開發的天然結果而演進。XP假定構架的造成是從生成簡單的代碼開始，而後進行持續的代碼重構。 在 RUP 中，構架不只僅是"隱喻"。在細化階段中，您構建可運行的構架，從中可能減小與是否知足非功能性需求相關的不少風險，好比性能、可靠性以及健壯性。經過閱讀 XP文獻，很是可能判斷出一些 RUP 爲細化階段所描寫敘述的內容，尤爲是過於 XP 所稱的基礎設施的過度關注，都是徒勞無功的。XP 以爲在沒有必要的狀況下建立基礎設施所作的工做致使瞭解決方式過於複雜，並且所建立的結果對客戶沒有價值。在 RUP 中，構架與基礎設施不是等同的。 在 RUP 與 XP 中建立構架的方法是大相徑庭。RUP 建議您關注構架，避免隨時間變化而產生的範圍蔓延、添加�項目規模以及採用新技術帶來的風險。XP 採用足夠簡單或是很是好理解的現有構架，該構架能夠隨着代碼而演進。XP 建議您不要爲明天而設計，而要爲今天而實施。XP 相信假設您儘量地保持設計簡單，那麼未來管理起來也垂手可得。RUP 但願您考慮該主張帶來的風險。假設系統或者部分系統在將來不得不重寫，那麼 XP 以爲這樣的舉措比方今就計劃這樣的可能性更明智而且花費更少。對於一些系統，這是千真萬確的，而且使用 RUP 時，在您細化階段考慮風險也會得出同一結論。RUP 並不以爲對於所有系統這都是正確的，而且經驗代表對於那些較大型、較複雜和沒有先例的系統來講，這多是災難性的。 儘管爲將來的可能性（可能永遠不會生生）花費太多的精力多是一種浪費但是對將來進行足夠的關注不失爲一件精明之舉。多少公司能花得起代價不斷重寫或者甚至是重構代碼呢？ 對於不論什麼項目，在細化階段您應該至少完畢這三項活動： 定義、驗證並且設定構架的基線。 使 用風險清單從起始階段開發備選構架。咱們關注是否能夠保證構想中的軟件具備可行性。假設選定技術對於系統沒什麼新穎性或者複雜性，這項任務不會花費太長時 間。假設您正在向現有系統中加入�內容，那麼假設現有構架不需要進行變動，這項任務就不是必要的。但是當真正出現構架風險時，您並不想讓您的架構來"碰運 氣"。 做爲這項活動的一部分，您可能運行一些組件選擇，並且作出決定進行購買/建立/重用組件。假設這需要大量工做，您可以將其分爲單獨的活動。 精化視圖。 在起始 階段，您開發了一個視圖。因爲你要肯定項目的可行性，並且涉衆有時間檢查和評價系統，所以可能要對視圖文檔及需求做出一些變動。對視圖與需求的改動通常在 細化階段進行。在細化階段的最後，您已經深入理解了用來構建和計劃的最關鍵的用例。涉衆需要獲得承認，在當前構架的環境中，僅僅要依照當前的計劃開發整個系 統，就能實現當前的設想。在隨後的迭代過程當中，變動的數量應該有所下降，但是您可能會在每次迭代中花一些時間進行需求管理。 爲構建階段建立迭代計劃並且設定基線 。 現在，可以爲您的計劃填充細節了。在每次構建迭代的最後，您可以按需要又一次考慮計劃並且進行調整。調整過程經常是必需的，因爲需要進行的工做每每被錯誤地 估算，業務環境也會常常變化，有時需求也會發生變動。爲用例、場景以及技術工做設定優先級，而後將它們分配到迭代過程當中。在每次迭代過程的最後，您計劃產 生一個能夠爲涉衆提供價值的工做產品。 您可以在細化階段運行其它活動。咱們推薦您創建測試環境並且開始開發測試。儘管具體的代碼尚未完畢，但是您仍然可以設計測試，或許可以實施集成測 試。程序猿應該隨時準備進行單元測試，並且瞭解怎樣使用項目選定的測試工具。XP 推薦您在編寫代碼前先設計測試內容。這是個獨到的看法，尤爲是當您向現有代碼主體中加入�內容時。只是，無論您選擇怎樣進行測試，都應該在細化階段創建常規 測試體制。 RUP 描寫敘述的細化階段包含 XP 中的研究階段和投入階段。XP 處理技術風險（好比新穎性和複雜性）的方式爲使用"spike"解決方式，好比花費一些時間進行試驗以對工做量進行估算。這樣的技術在不少案例中都是有效 的，當較大風險沒有體現在單個用例或"故事"中時，您就需要花些工夫確保系統的成功而且對工做量進行精確的估算。 在細化階段，您會經常更新工件，好比起始階段的需求與風險清單。在細化階段可能出現的工件包含： 軟件構架文檔（SAD）。 SAD 是一個複合型的工件，它提供了整個項目的技術信息的單一來源。在細化階段的最後，該文檔可能會包括具體的介紹，描寫敘述在結構上很是重要的用例，並且肯定關鍵的 機制和設計元素。對於加強現有系統的項目，您可以使用曾經的 SAD，或者假設你認爲不會帶來什麼風險，那麼就決定不使用該文檔。在所有的狀況下，您都應該深思熟慮並且記錄於文檔中。 構建過程的迭代計劃。 您 可以在細化階段計劃構建迭代的次數。每次迭代都有特定的用例、場景以及其它分配的工做項目。這些信息都在迭代計劃中有所體現並且設定基線。評審與覈准計劃 可以做爲細化階段的出口標準的一部分。對於很小的短時間項目來講，您可以將細化階段的迭代與起始過程和構建過程合併。關鍵性的活動仍然可以進行，但是迭代 計劃和評審所需的資源都會有所下降。 構建階段 構建的目標是完畢系統開發。構建階段從某種意義上來看是一個製造過程，當中重點工做就是管理資源、控制操做以優化成本、日程和質量。從這個意義上來說，管理理念應該進行一個轉換，從起始階段和細化階段的知識產權開發轉換到構建和交付階段的部署產品的開發。 XP 側重構建階段。構建階段是編寫產品代碼的階段。XP所有階段的目的都是爲了進行計劃，但是 XP 的關注焦點是構建代碼。 構建階段的每次迭代都具備三個關鍵活動： 管理資源與控制過程。 每個人都需要了解本身的工做內容和時間。您必須保證工做負荷不會超過您的能力，而且工做可以按計劃進行。 開發與測試組件。 您構建組件以知足迭代中用例、場景以及其它功能的需要。您對其進行單元測試和集成測試。 對迭代進行評估。 在迭代完畢時，您需要推斷是否已經達到了迭代的目標。假設沒有，您必須又一次劃分優先級並管理範圍以確保能夠按時交付系統。 不一樣類型的系統需要使用不一樣的技術。RUP 爲軟件project師提供了不一樣的指導，以幫助他們建立恰當的組件。以用例和補充（非功能）需求的形式提出的需求是足夠具體的，可以使project師開展工做。RUP 中的若干活動爲設計、實施和測試不一樣種類的組件提供了指南。一名有經驗的軟件project師不需要具體查看這些活動。經驗稍欠缺一些的project師可以經過最佳實踐得到 很是大的幫助。每個團隊成員都可以按需要深刻研究過程或者僅僅是略微瞭解一下。只是，他們都參照一個單獨的過程知識基礎。 在 XP 中，"故事"驅動實施過程。在 Extreme Programming Installed 一書中，Jeffries等人以爲"故事"是程序猿的"會話承諾"（promises for conversation）。 持續有效的交流大有裨益。儘管老是需要澄清一些細節，假設"故事"不夠具體，而使程序猿不能完畢他們大部分工做，那麼可以說"故事"尚未就緒。用例必須 足夠具體以方便程序猿實施。在不少狀況下，程序猿會幫助編寫用例的技術細節。Jeffries 等人以爲，會話應該記錄在文檔中並且附加到"故事"中。RUP 也容許這個觀點，除了以用例規格說明的形式，可以按需要使用非正式的形式。捕獲並管理會話的結果是您必須管理的任務。 XP 的好處在於構建階段。對於大多數團隊來講，都存在適用於他們的"智慧與指南的結晶"。XP 中最顯著的實踐包含： 測試--程序猿不斷地隨着代碼的開發編寫測試。測試反映了"故事"。XP提倡您首先編寫測試，這是一項優秀的實踐，因爲它可以迫使您深入地理解"故 事"，並且在必要的地方提出不少其它的問題。不論在編寫代碼以前仍是以後，必定要編寫測試。將它們添�到您的測試包中，並且保證每次代碼變動時都執行測試。 重構--不斷重構系統的結構而不改變其行爲，可以使其更加簡單或靈活。您需要推斷對您的團隊來講是否存在一個較好的實踐。簡單與複雜的判別否因人而 異。有這樣一個樣例，一個項目中的兩個很是聰明的project師每晚都要重寫對方的代碼，因爲他們以爲對方的代碼過於複雜。這產生了一個反作用，也就是他們老是干擾 次日其它成員的工做。測試是有幫助的，但是假設他們之間不陷入代碼之爭的話，那麼團隊的處境就會更好一些。 結對編程--XP 以爲結對編程可以在更短的時間內建立出更好的代碼。有證據代表這是正確的 。假設您遵守這項實踐，就需要考慮不少人文與環境的因素。程序猿願意對此進行嘗試嗎？您的物理環境可以知足這樣的狀況嗎，即有足夠的空間使兩個程序猿在一個 單獨工做站中有效地工做？您怎樣對待遠程工做或者在其它地點工做的程序猿？ 持續集成--集成與構建工做需要持續進行，可能天天不止一次。這是一種確保代碼結構完整的很是好的方式，它還贊成在集成測試過程當中進行持續的質量監控。 集體代碼所有權--不論什麼人都可以隨時改動不論什麼代碼。XP 依賴這樣一個事實，即一組好的單元測試將會下降這項實踐的風險。讓你們將每一件事都搞清楚的優勢不能侷限在必定的尺度上--是 1 萬行代碼、2 萬行代碼仍是必定要少於 5 萬行？ 簡單設計--隨着重構過程的進行，需要不斷地改動系統設計使其變動簡單。再一次重申，您需要推斷這項工做進行到何種程度纔剛好合適。假設您在細化階段中花費了必要霎時間來設計構架，咱們相信簡單的設計將會很是快完畢並且很是快變得穩定。 代碼標準--這一直都是一項良好實踐。標準是什麼都不要緊，僅僅要您使用它們而且每個人都承認就可以。 RUP 與 XP 都以爲您必須管理（和控制）迭代過程。衡量標準可以提供較好的計劃信息，因爲它們可以幫助您選擇對於您的團隊來講什麼是最適合的。需要衡量三件事：時間、 規模和缺陷。這樣您就可以得到所有類型您所感興趣的統計數字。XP 爲您提供簡單的衡量標準來推斷進展並且預測成果。這些衡量標準環繞着完畢的"故事"數量、經過測試的數量以及統計中的趨勢這些問題。XP 爲使用最少許的衡量標準作出了一個優秀的表率，因爲查看太多並不必定會添加�項目成功的機會。RUP 爲您提供了對於您可以衡量的內容以及怎樣衡量的指導，並且舉了有關衡量標準的樣例。在所有的狀況中，衡量標準必須簡單、客觀、易於蒐集、易於表達，並且不 易產生誤解。 在構建階段的迭代過程當中將會產生哪些工件呢？這取決於迭代是處於構建階段的早期仍是後期，您可以建立下面工件： 組件--組件表明了軟件代碼中的一部分（源碼、二進制代碼或者可運行程序），或者包括信息的文件，好比，一個啓動文件或者一個 ReadMe 文件。組件還可以是其它組件的聚合，好比由幾個可運行程序組成的應用程序。 培訓資料--假設系統的用戶界面比較複雜，那麼請在用例的基礎上儘早編寫用戶手冊和其它培訓資料的初稿。 部署計劃--客戶需要一個系統。部署計劃描寫敘述了一組安裝、測試並且有效地向用戶交付產品所需的任務。對於 以Web 爲中心的系統來講，咱們已經發現，部署計劃的重要性又提升了。 交付階段迭代計劃--臨近交付時，您需要完畢並且評審交付階段迭代計劃。 代碼完整嗎？ 以爲代碼就是設計並且設計也就是代碼。代碼與自身老是一致的，這一點是千真萬確的。咱們以爲花費精力進行設計並且溝通設計是很是值得的，而不不過建立代碼。如下的小故事會說明這一點。 RUP 與 XP 間的差別除了創建構架的方法之外，還包含其它方面的不一樣。當中一點就是關於設計概念的溝通方式。XP 一名project師曾有兩次這種軟件項目經歷，設計體現在代碼中，並且僅僅能在代碼中找到設計信息。這兩個項目都是關於編譯器的：一個是改進與維護用於 Ada 編譯器的優化程序，還有一個項目是將一個編譯器的前端移植到一個新的平臺上，並且鏈接一個第三方的代碼生成器。 編譯器技術是比較複雜的，但也是廣爲人知的。在這兩個項目中，該project師想要概覽編譯器（或者優化程序）的設計和實施。在每個案例中，他都接到一堆源 代碼清單，大概有幾英尺厚，而且被告知"查看這些信息"。他本應被提供一些帶有支持性文字的構建很是好的圖。優化程序的項目沒有完畢。但是編譯器項目確實取 得了成功，由於在代碼開發過程當中進行了普遍的測試，因此代碼質量很是高。這位project師花費了數天時間研究調試器中的代碼以弄明確其做用。我的的損失尚在其次， 團隊的損失代價就更不值得。咱們並無按 XP 所看到的的那樣在 40 小時後完畢開發，咱們反而花費了大量我的努力來完畢工做。 僅僅開發代碼帶來的主要問題就是無論代碼文檔編寫得多麼好，它都沒有告訴您它自己要解決的問題，它僅僅提供了問題的解決方式。一些需求文檔在最初用戶和 開發者繼續工做很是長時間之後，仍然可以很是好地解釋項目的原始目標。爲了維護系統，您每每需要了解最初項目團隊的設計目標。一些高級設計文檔都是相似的 --代碼經常沒有通過高度的抽象，因此沒法提供不論什麼信息以代表整體的系統能夠實現什麼功能。在面向對象的系統中，這一點尤爲是正確的，因爲只查看裏面的 類文件是很是難甚至沒法得出運行線程。設計文檔指導您在後期出現故障時該查看的內容--在後期經常會出現故障。 這個故事說明花費時間建立與維護設計文檔確實會有所幫助。這可以減小誤解的風險，並且加速開發過程。XP 的方式就是花費幾分鐘勾畫出設計的大概內容或者使用 CRC 卡片。 但是團隊不主張這樣，而僅僅是進行代碼開發。他們有一個隱含的若是，那就是任務很是easy，咱們已經知道該怎樣進行了。即便咱們成功地完畢了任務，那麼下一個新 來的人可能就不會如此幸運。RUP建議您多花費一些時間建立並維護這些設計工件。 交付階段 交付階段的焦點就是確保軟件對於終於用戶是可用的。交付階段包含爲公佈進行產品的測試，在用戶反饋的基礎上作微小的調整等幾方面內容。在生命週期的這個時刻，用戶反饋主要集中在精確調整產品、配置、安裝，以及可用性等問題上。 較早公佈、經常性公佈都是很是好的辦法。但是，咱們經過公佈要達到的目的是什麼呢？XP 沒有清楚地解釋這個問題，也沒有處理公佈商業軟件所必須製造問題。在內部項目中，您可以爲解決這些問題找到捷徑，但是即便這樣，您仍然需要編輯文檔、員工 培訓等工做。那麼技術支持與變動管理又怎樣呢？但願現場客戶控制這些內容，這是可行的嗎？Bruce Conrad 在他的 XP 的 InfoWorld 評論 中指出用戶並不但願獲得的軟件老是在持續變動。您必須對高速變動軟件的利益和變動的劣勢及可能帶來的不穩定性進行權衡。 當您決定公佈的時候，您必須爲終於用戶提供比代碼多得多的東西。交付階段的活動和工件會指導您完畢本部分軟件開發過程。這些活動主要是爲了向您的客戶提供可用的產品。交付階段的關鍵活動例如如下： 肯定終於用戶支持資料。該活動比較簡單，您僅僅需提供一個清單就能夠。但是務必要確保您的組織已準備好對客戶進行技術支持。 在用戶的環境中測試可交付的產品。假設您能夠在公司內部模擬用戶環境，那是最好只是的。不然，就到客戶的公司去，安裝軟件並且保證其能夠執行。您必定不想尷尬地回答客戶："但是在咱們的系統上工做很是正常。" 基於用戶反饋精確調整產品。假設可能的話，在您向有限數量客戶交付軟件時計劃一次或者屢次 Beta 測試周期。假設進行該測試，那麼就需要對 Beta 測試周期進行管理，並且考慮您"收尾工做"中的客戶反饋。 向終於用戶交付終於產品。對於不一樣類型的軟件產品和公佈版本號，需要處理不少有關打包、製造和其它產品問題。您確定不會只將軟件拷貝到一個目錄中，而後向客戶發一封郵件告訴他們軟件已經到位了。 與其它階段同樣，過程的格式與複雜度都有所不一樣。只是，假設您沒有注意部署細節，那麼可能致使數週或數月的良好開發工做前功盡棄，從而在進入目標市場時以失敗了結。 在交付階段中您可以生成若干工件。假設您的項目涉及到未來的公佈（有多少項目沒有涉及到呢？），那麼您就應該開始爲下次公佈肯定功能和缺陷。對於不論什麼項目，下列工件都相當重要： 部署計劃--完畢您始於構建階段的部署計劃並且將其做爲交付的路線圖。 版本號凝視--它是一個比較少見的軟件產品，不包括對終於用戶相當重要的指令。可以對其作出計劃，對於凝視要有一個可用的、一致的格式。 交付階段資料與文檔--這類資料可以採取很是多形式。您可以在線提供所有內容嗎？您會進行指導嗎？您的產品幫助完整並且可用嗎？不要以爲您所瞭解的，客戶也相同瞭解。您的成功就在於幫助您的客戶取得成功。 結束語 構建軟件的工做遠遠多於編 寫代碼所工做。一個軟件開發過程必須集中處理向用戶公佈高質量軟件的所有必需活動。一個完整的過程沒必要是龐大的。咱們經過集中論述項目中的主要活動和工 件，已經向您展現了怎樣進行一個小型但是完整的過程。假設運行某項活動或者建立某個工件對於緩解項目中的風險是有幫助的，那麼就請進行。您可以按需要爲您 的項目團隊和組織使用或多或少的過程和格式。 RUP 和 XP 並沒必要是互相排斥的。經過結合使用這兩種方法，您全然可以獲得一個過程，幫助您比方今更快地交付更高質量的軟件。Robert Martin 描寫敘述了一個叫作 dX 的過程，他將其做爲 RUP 的附屬品 。它就是一個從 RUP 框架中構建的過程的實例。 一個優秀的軟件過程可以使用經業界驗證的最佳實踐。最佳實踐已經在真實的軟件開發組織中使用，並且經歷了時間的考驗。XP 是眼下廣爲關注的方法。它以代碼爲中心，並提供了一項承諾：花費最少的過程開銷獲得最大的生產力。XP 中的不少技術值得在恰當的狀況中考慮和採用。 XP 關注"故事"、測試和代碼--它以必定的深度討論了計劃，但沒有具體闡述怎樣獲取計劃。XP 意味着您可以完畢其它一些工做，好比"使用一些卡片進行 CRC 設計或者草擬某種 UML……"或者"請不要生成並不使用的文檔或者其它工件"，但僅僅是一帶而過。RUP 但願您在定製和更新開發計劃時，只考慮建立實用和必須的東西，並且指出了這些東西該是什麼。 RUP 是一個可以處理整個軟件開發週期的過程。它關注最佳實踐，並且通過了數千個項目的洗禮。咱們鼓舞研究和發明新的技術以產生最佳實踐。隨着新的最佳實踐嶄露頭腳，咱們但願將它們歸入 RUP 中。 附錄：Rational Unified Process Rational Unified Process，或者簡稱 RUP，提供了軟件開發的規律性方法。它是由IBM Rational開發並維護的過程產品。它爲來同類型的項目提供了幾種即裝即用的路線圖。RUP 還提供了一些信息，幫助您在軟件開發過程當中使用其它 Rational 工具，但是它不要求將 Rational 工具備效地應用於整個組織，您也可以將 Rational 工具與其它供應商的產品進行集成。 RUP 爲軟件項目所有方面提供了指導。並不需要您運行不論什麼特定的活動或者建立不論什麼特定的工件。它僅僅爲您提供信息和指南，您可以決定將哪些應用於您的組織。假設沒有特定的路線圖適合您的項目或者組織，RUP 還提供了一些指南來幫助您量身定作你的過程。 RUP 強調採用現代軟件開發的一些最佳實踐，做爲一種減小開發新軟件所帶來的內在風險的方式。這些最佳實踐包含： 1． 迭代開發 2． 管理需求 3． 使用基於組件的構架 4． 可視建模 5． 持續的質量驗證 6． 控制變動 這些最佳經驗融合到 Rational Unified Process 的下面定義中： 角色--運行的系列活動和擁有的工件。 學科--軟件project中的關鍵領域，好比需求、分析與設計、實施與測試。 活動--工件生成與評估方式的定義。 工件--在運行活動中所使用的、生成的或改動的工做產品。 RUP 是一個迭代過程，肯定了不論什麼軟件開發項目的四個階段。隨着時間的推動，每個項目都要經歷起始階段、細化階段、構建階段和交付階段。每個階段包含一次或屢次 迭代，當中您可以生成可運行文件，但是系統可能不完整（可能起始階段除外）。在每次迭代過程當中，您以不一樣的細節級別運行幾個學科中的活動。下文是 RUP 的概述圖。 RUP 概覽圖 The Rational Unified Process, An Introduction, Second Edition 一書是 RUP 的好的概述。您可以在 Rational 的 Web 網站 www.rational.com 上找到更進一步的信息和對於 RUP 的評價。 附錄：極限編程 極限編程（XP） 是由 Kent Beck 在 1996 年開發的一種軟件開發學科。它基於四個價值：溝通、簡單、反饋和勇氣。它強調客戶與開發團隊成員的持續溝通，在開發進程中設立一名現場客戶。該現場客戶決 定建立的內容和順序。經過持續重構代碼並建立最小的非代碼工件集合而體現簡單。不少短時間公佈和持續單元測試創建了反饋機制。勇氣意味着完畢正確的事情，即 使並不是最流行的事情。它還意味着誠實面對您能作的和不能作的事情。 12 個 XP 實踐爲這四個價值提供支持。它們是： 有計劃的開發：經過結合使用優先級"故事"和技術估算，肯定下一版本號的功能。 小版本號：以小的增量版本號經常向客戶公佈軟件。 隱喻：隱喻是一個簡單、共享的"故事"或描寫敘述，說明系統怎樣工做。 簡單設計：經過保持代碼簡單從而保證設計簡單。不斷的在代碼中尋找複雜點並且立馬進行移除。 測試：用戶編寫測試內容以對"故事"進行測試。程序猿編寫測試內容來發現代碼中的不論什麼問題。在編寫代碼前先編寫測試內容。 重構：這是一項簡化技術，用來移除代碼中的反覆內容和複雜之處。 結對編程：團隊中的兩個成員使用同一臺計算機開發所有的代碼。一我的編寫代碼或者驅動，還有一我的同一時候審查代碼的正確性和可理解性。 集體代碼所有權：不論什麼人都擁有所有的代碼。這就意味這每個人都可以在不論何時變動不論什麼代碼。 持續集成：天天屢次建立和集成系統，僅僅要不論什麼實現任務完畢就要進行。 每週 40 個小時：程序猿在疲勞時沒法保證最高效率。連續兩週加班是絕對不一樣意的。 現場客戶：一名真實的客戶全時工做於開發環境中，幫助定義系統、編寫測試內容並回答問題。 編碼標準：程序猿採用一致的編碼標準。 淺談測試驅動開發（TDD） 　 測試驅動開發(TDD)是極限編程的重要特色，它以不斷的測試推進代碼的開發，既簡化了代碼，又保證了軟件質量。本文從開發者使用的角度，介紹了 TDD 優點、原理、過程、原則、測試技術、Tips 等方面。 背景 一個高效的軟件開發過程 對軟件開發者來講是相當重要的，決定着開發是痛苦的掙扎，仍是不斷進步的喜悅。國人對軟件藍領的不屑，對繁瑣冗長的傳統開發過程的不耐，使大多數開發人 員無所適從。近期興起的一些軟件開發過程相關的技術，提供一些比較高效、有用的軟件過程開發方法。當中比較基礎、關鍵的一個技術就是測試驅動開發 （Test-Driven Development）。儘管TDD光大於極限編程，但測試驅動開發全然可以單獨應用。如下就從開發者使用的角度進行介紹，使開發者用最少的代價盡 快理解、掌握、應用這樣的技術。如下分優點，原理，過程，原則，測試技術，Tips等方面進行討論。 1. 優點 TDD的基本思路就是經過測試來推進整個開發的進行。而測試驅動開發技術並不只僅是單純的測試工做。 需求向來就是軟件開發過程當中感受最很差明白描寫敘述、易變的東西。這裏說的需求不只僅是指用戶的需求，還包含對代碼的使用需求。很是多開發者最懼怕的就是 後期還要改動某個類或者函數的接口進行改動或者擴展，爲何會發生這種事情就是因爲這部分代碼的使用需求沒有很是好的描寫敘述。測試驅動開發就是經過編寫測試 用例，先考慮代碼的使用需求（包含功能、過程、接口等），而且這個描寫敘述是無二義的，可運行驗證的。 經過編寫這部分代碼的測試用例，對其功能的分解、使用過程、接口都進行了設計。而且這樣的從使用角度對代碼的設計一般更符合後期開發的需求。可測試的要求，對代碼的內聚性的提升和複用都很故意。所以測試驅動開發也是一種代碼設計的過程。 開發者一般對編寫文檔很厭煩，但要使用、理解別人的代碼時一般又但願能有文檔進行指導。而測試驅動開發過程當中產生的測試用例代碼就是對代碼的最好的解釋。 快樂工做的基礎就是對本身有信心，對本身的工做成果有信心。當前很是多開發者卻經常在操心：「代碼是否正確？」「辛苦編寫的代碼還有沒有嚴重 bug？」「改動的新代碼對其它部分有沒有影響？」。這樣的操心甚至致使某些代碼應該改動卻不敢改動的地步。測試驅動開發提供的測試集就可以做爲你信心的來 源。 固然測試驅動開發最重要的功能還在於保障代碼的正確性，能夠迅速發現、定位bug。而迅速發現、定位bug是很是多開發者的夢想。針對關鍵代碼的測試集，以及不斷無缺的測試用例，爲迅速發現、定位bug提供了條件。 個人一段功能很是複雜的代碼使用TDD開發完畢，真實環境應用中僅僅發現幾個bug，而且很是快被定位解決。您在應用後，也必定會爲那種自信的開發過程，功能不斷添加�、無缺的感受，迅速發現、定位bug的能力所感染，喜歡這個技術的。 那麼是什麼樣的原理、方法提供上面說的這些優勢哪？如下咱們就看看TDD的原理。 2. 原理 測試驅動開發的基本思想就是在開發功能代碼以前，先編寫測試代碼。也就是說在明白要開發某個功能後，首先思考怎樣對這個功能進行測試，並完畢測試代碼的編寫，而後編寫相關的代碼知足這些測試用例。而後循環進行加入�其它功能，直到完全部功能的開發。 咱們這裏把這個技術的應用領域從代碼編寫擴展到整個開發過程。應該對整個開發過程的各個階段進行測試驅動，首先思考怎樣對這個階段進行測試、驗證、考覈，並編寫相關的測試文檔，而後開始下一步工做，最後再驗證相關的工做。下圖是一個比較流行的測試模型：V測試模型。 【圖 V測試模型】 在開發的各個階段，包含需求分析、概要設計、具體設計、編碼過程當中都應該考慮相相應的測試工做，完畢相關的測試用例的設計、測試方案、測試計劃的編 寫。這裏提到的開發階段僅僅是舉例，依據實際的開發活動進行調整。相關的測試文檔也不必定是很具體複雜的文檔，或者什麼形式，但應該養成測試驅動的習慣。 關於測試模型，還有X測試模型。這個測試模型，我以爲，是對具體階段和編碼階段進行建模，應該說更具體的描寫敘述了具體設計和編碼階段的開發行爲。及針對某個功能進行相應的測試驅動開發。 【圖 X測試模型】 基本原理應該說很easy，那麼怎樣進行實際操做哪，如下對開發過程進行具體的介紹。 3. 過程 軟件開發其它階段的測試驅動開發，依據測試驅動開發的思想完畢相應的測試文檔就能夠。如下針對具體設計和編碼階段進行介紹。 測試驅動開發的基本步驟例如如下： 1） 明白當前要完畢的功能。可以記錄成一個 TODO 列表。 2） 高速完畢針對此功能的測試用例編寫。 3） 測試代碼編譯不經過。 4） 編寫相應的功能代碼。 5） 測試經過。 6） 對代碼進行重構，並保證測試經過。 7） 循環完畢所有功能的開發。 爲了保證整個測試過程比較快捷、方便，一般可以使用測試框架組織所有的測試用例。一個免費的、優秀的測試框架是 Xunit 系列，差點兒所有的語言都有相應的測試框架。 開發過程當中，一般把測試代碼和功能代碼分開存放，這裏提供一個簡單的測試框架使用樣例，您可以經過它瞭解測試框架的使用。如下是文件列表。 project/ 項目主文件夾 project/test 測試項目主文件夾 project/test/testSeq.cpp 測試seq_t 的測試文件，對其它功能文件的測試文件複製後改動就能夠 project/test/testSeq.h project/test/Makefile 測試項目的 Makefile project/test/main.cpp 測試項目的主文件，不需要改動 project/main.cpp 項目的主文件 project/seq_t.h 功能代碼，被測試文件 project/Makefile 項目的 Makefile 主要流程基本如此，但要讓你的代碼很是easy的進行測試，全面又不繁瑣的進行測試，仍是有很是多測試原則和技術需要考慮。 4. 原則 測試隔離。不一樣代碼的測試應該相互隔離。對一塊代碼的測試僅僅考慮此代碼的測試，不要考慮事實上現細節（比方它使用了其它類的邊界條件）。 一頂帽子。開發者開發過程當中要作不一樣的工做，比方：編寫測試代碼、開發功能代碼、對代碼重構等。作不一樣的事，承擔不一樣的角色。開發者完畢相應的 工做時應該保持注意力集中在當前工做上，而不要過多的考慮其它方面的細節，保證頭上僅僅有一頂帽子。避免考慮無關細節過多，無謂地添加�複雜度。 測試列表。需要測試的功能點很是多。應該在不論什麼階段想加入�功能需求問題時，把相關功能點加到測試列表中，而後繼續手頭工做。而後不斷的完畢相應的測試用例、功能代碼、重構。一是避免疏漏，也避免干擾當前進行的工做。 測試驅動。這個比較核心。完畢某個功能，某個類，首先編寫測試代碼，考慮其怎樣使用、怎樣測試。而後在對其進行設計、編碼。 先寫斷言。測試代碼編寫時，應該首先編寫對功能代碼的推斷用的斷言語句，而後編寫對應的輔助語句。 可測試性。功能代碼設計、開發時應該具備較強的可測試性。事實上遵循比較好的設計原則的代碼都具有較好的測試性。比方比較高的內聚性，儘可能依賴於接口等。 及時重構。無論是功能代碼仍是測試代碼，對結構不合理，反覆的代碼等狀況，在測試經過後，及時進行重構。關於重構，我會另撰文具體分析。 小步前進。軟件開發是個複雜性很是高的工做，開發過程當中要考慮很是多東西，包含代碼的正確性、可擴展性、性能等等，很是多問題都是因爲複雜性太大致使 的。極限編程提出了一個很好的思路就是小步前進。把所有的規模大、複雜性高的工做，分解成小的任務來完畢。對於一個類來講，一個功能一個功能的完畢，如 果太困難就再分解。每個功能的完畢就走測試代碼－功能代碼－測試－重構的循環。經過分解減小整個系統開發的複雜性。這種效果很明顯。幾個小的功能代碼 完畢後，大的功能代碼差點兒是不用調試就可以經過。一個個類方法的實現，很是快就看到整個類很是快就完畢啦。原本感受很是多特性需要添加�，很是快就會看到沒有幾個 啦。你甚至會爲這個速度感到震驚。（我理解，是大幅度下降調試、出錯的時間產生的這樣的速度感） 5. 測試技術 5.1. 測試範圍、粒度 對 哪些功能進行測試？會不會太繁瑣？何時可以中止測試？這些問題比較常見。按大師 Kent Benk 的話，對那些你以爲應該測試的代碼進行測試。就是說，要相信本身的感受，本身的經驗。那些重要的功能、核心的代碼就應該重點測試。感到疲勞就應該停下來休 息一下。感受沒有必要更具體的測試，就中止本輪測試。 測試驅動開發強調測試並不該該是負擔，而應該是幫助咱們減輕工做量的方法。而對於什麼時候中止編寫測試用例，也是應該依據你的經驗，功能複雜、核心功能的代碼就應該編寫更全面、仔細的測試用例，不然測試流程就能夠。 測試範圍沒有靜態的標準，同一時候也應該可以隨着時間改變。對於開始沒有編寫足夠的測試的功能代碼，隨着bug的出現，依據bug補齊相關的測試用例就能夠。 小步前進的原則，要求咱們對大的功能塊測試時，應該先分拆成更小的功能塊進行測試，比方一個類A使用了類B、C，就應該編寫到A使用B、C功能的測 試代碼前，完畢對B、C的測試和開發。那麼是否是每個小類或者小函數都應該測試哪？我以爲沒有必要。你應該運用你的經驗，對那些可能出問題的地方重點測 試，感受不可能出問題的地方就等它真正出問題的時候再補測試吧。 5.2. 怎麼編寫測試用例 測試用例的編寫就用上了傳統的測試技術。 操做過程儘可能模擬正常使用的過程。 全面的測試用例應該儘可能作到分支覆蓋，核心代碼儘可能作到路徑覆蓋。 測試數據儘可能包含：真實數據、邊界數據。 測試語句和測試數據應該儘可能簡單，easy理解。 爲了不對其它代碼過多的依賴，可以實現簡單的樁函數或樁類（Mock Object）。 假設內部狀態很複雜或者應該推斷流程而不是狀態，可以經過記錄日誌字符串的方式進行驗證。 6. Tips 很是多朋友有疑 問，「測試代碼的正確性怎樣保障？是寫測試代碼仍是寫測試文檔？」這樣是否是會陷入「雞生蛋，蛋生雞」的循環。事實上是不會的。一般測試代碼通常是很easy 的，一般環繞着某個狀況的正確性推斷的幾個語句，假設太複雜，就應該繼續分解啦。而傳統的開發過程一般強調測試文檔。但隨着開發節奏的加快，用戶需求的不 斷變化，維護高層（需求、概要設計）的測試文檔可以，更低層的測試文檔的成本的確太大了。而且可實時驗證功能正確性的測試代碼就是對代碼最好的文檔。 軟件開發過程當中，除了遵照上面提到的測試驅動開發的幾個原則外，一個需要注意的問題就是，謹防過分設計。編寫功能代碼時應該關注於完畢當前功能點， 經過測試，使用最簡單、直接的方式來編碼。過多的考慮後期的擴展，其它功能的加入�，無疑添加�了過多的複雜性，easy產生問題。應該等到要加入�這些特性時在進 行具體的測試驅動開發。到時候，有整套測試用例作基礎，經過不斷重構很是easy加入�相關特性。

公佈時間:2005-8-17