新聞資訊   News
聯系我們   Contact
搜索   Search
你的位置:首頁 > 新聞資訊 > 行業新聞

軟件開發公司-開發軟件流程[轉載]

2018-07-26 01:58:10      點擊:


軟件開發公司的流程[轉]
迭代化軟件開發技術 

    
    

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

軟件開發公司 軟件定制開發 設備管理軟件下載 學校資產管理軟件下載
隨著我們所開發的軟件項目越來越復雜,傳統的瀑布型開發流程不斷地暴露出以下問題:

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

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


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


深圳軟件開發公司 固定資產管理軟件


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

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


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


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

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 過程可以從兩種不同而又密不可分的視角來觀察:

    從管理的視角來看,涉及財務、戰略、商業和人文方面
    從技術的視角來看,涉及質量、工程和設計方法方面

2.2 周期和階段


從管理的角度,即從業務和經濟的角度來看,對應項目的進展,軟件的生命周期包含四個主要階段:

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

完成這4個階段稱為一個開發周期, 它產生的軟件稱作代(generation)。 除非產品的生命結束, 一個現有產品可以通過重復下一個相同的起始、細化、構建和移交四階段,各個階段的側重點與次不同,從而演進為下一代產品。 這個時期我們稱之為演進(evolution)。后伴隨著產品經過幾個周期的演進,新一代產品也不斷被制造出來。

例如,演進周期的啟動可能由以下這幾項觸發:用戶建議增強功能、用戶環境的改變、重要技術的變更,以及應對競爭的需要。


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

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


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

管理角度和技術角度之間是協調的, 而且各個階段的結束還和各次迭代的結束保持同步。
換句話說,每個階段可以分為一次或多次迭代過程。


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

這些工件的可用性、工件是否滿足所建立的評估標準,是構成里程碑的主要具體元素,比日歷牌上的日期提供了多得多的內容。

像周期一樣,迭代之間也會有輕微重疊。即第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 過程中各個階段的名稱(如起始、細化、構建、移交)與描述活動的術語(如分析、設計、測試等)相差甚遠。 因此我們容易理解某種活動的進行并不局限于某個特定階段,也與其他作者、標準及特定領域的所使用的術語無關。這些活動確實發生,但它們在每個階段和每次迭 代中的程度有所不同。下圖表明了活動重點如何隨時間的推進而發生演進。


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

盡管具體的項目有具體的區別,但對于一個中等規模、初次開發的典型項目來說,其開發周期中各種活動的比例如下:
計劃與管理     15%
分析/需求     10%
設計/集成     15%
實施/功能測試     30%
度量/評估/驗收測試     15%
工具/環境/變更管理     10%
維護(開發過程中的修補)     5%

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

5.1管理工件
管理工件不是產品,而是用來驅動或監控項目進展、估計項目風險、調整項目資源,以及使客戶或投資者對項目保持一定的"可見性" 的。

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

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

    用戶手冊, 在生命周期早期開發。
    軟件文檔, 好以源代碼自建文檔和模型的形式,其中模型是用合適的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 為軟件工程師提供了不同的指導,以幫助他們創建恰當的組件。以用例和補充(非功能)需求的形式提出的需求是足夠詳細的,可以使工程師開展工作。RUP 中的若干活動為設計、實施和測試不同種類的組件提供了指南。一名有經驗的軟件工程師不需要詳細查看這些活動。經驗稍欠缺一些的工程師可以通過佳實踐獲得 很大的幫助。每個團隊成員都可以按需要深入研究過程或者只是稍微了解一下。不過,他們都參照一個單獨的過程知識基礎。

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

XP 的長處在于構建階段。對于大多數團隊來說,都存在適用于他們的"智慧與指南的結晶"。XP 中顯著的實踐包括:

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

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

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

持續集成--集成與構建工作需要持續進行,可能每天不止一次。這是一種確保代碼結構完整的很好的方式,它還允許在集成測試過程中進行持續的質量監控。

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

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

代碼標準--這一直都是一項良好實踐。標準是什么都沒關系,只要您使用它們而且每個人都認可就可以。

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

在構建階段的迭代過程中將會產生哪些工件呢?這取決于迭代是處于構建階段的早期還是后期,您可以創建以下工件:

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

培訓資料--如果系統的用戶界面比較復雜,那么請在用例的基礎上盡早編寫用戶手冊和其他培訓資料的初稿。

部署計劃--客戶需要一個系統。部署計劃描述了一組安裝、測試并且有效地向用戶交付產品所需的任務。對于 以Web 為中心的系統來說,我們已經發現,部署計劃的重要性又提高了。

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

代碼完整嗎?
認為代碼就是設計并且設計也就是代碼。代碼與自身總是一致的,這一點是千真萬確的。我們認為花費精力進行設計并且溝通設計是很值得的,而不僅僅是創建代碼。下面的小故事會說明這一點。
RUP 與 XP 間的差異除了建立構架的方法以外,還包括其他方面的不同。其中一點就是關于設計概念的溝通方式。XP

一名工程師曾有兩次這樣的軟件項目經歷,設計體現在代碼中,并且只能在代碼中找到設計信息。這兩個項目都是關于編譯器的:一個是改進與維護用于 Ada 編譯器的優化程序,另一個項目是將一個編譯器的前端移植到一個新的平臺上,并且連接一個第三方的代碼生成器。

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

只開發代碼帶來的主要問題就是無論代碼文檔編寫得多么好,它都沒有告訴您它本身要解決的問題,它只提供了問題的解決方案。一些需求文檔在初用戶和 開發人員繼續工作很長時間以后,仍然可以很好地解釋項目的原始目標。為了維護系統,您往往需要了解初項目團隊的設計目標。一些設計文檔都是相似的 --代碼經常沒有經過高度的抽象,所以無法提供任何信息以表明整體的系統能夠實現什么功能。在面向對象的系統中,這一點尤其是正確的,因為僅僅查看里面的 類文件是很難甚無法得出執行線程。設計文檔指導您在后期出現問題時該查看的內容--在后期經常會出現問題。

這個故事說明花費時間創建與維護設計文檔確實會有所幫助。這可以降低誤解的風險,并且加速開發過程。XP 的方式就是花費幾分鐘勾畫出設計的大概內容或者使用 CRC 卡片。 但是團隊不主張這樣,而只是進行代碼開發。他們有一個隱含的假設,那就是任務很簡單,我們已經知道該如何進行了。即使我們成功地完成了任務,那么下一個新 來的人可能就不會如此幸運。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 的以下定義中:

角色--執行的系列活動和擁有的工件。
學科--軟件工程中的關鍵領域,例如需求、分析與設計、實施與測試。
活動--工件生成與評估方式的定義。
工件--在執行活動中所使用的、生成的或修改的工作產品。

RUP 是一個迭代過程,確定了任何軟件開發項目的四個階段。隨著時間的推進,每個項目都要經歷起始階段、細化階段、構建階段和交付階段。每個階段包括一次或多次 迭代,其中您可以生成可執行文件,但是系統可能不完整(可能起始階段除外)。在每次迭代過程中,您以不同的細節級別執行幾個學科中的活動。下文是 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的基本思路就是通過測試來推動整個開發的進行。而測試驅動開發技術并不只是單純的測試工作。

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

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

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

快樂工作的基礎就是對自己有信心,對自己的工作成果有信心。當前很多開發人員卻經常在擔心:“代碼是否正確?”“辛苦編寫的代碼還有沒有嚴重 bug?”“修改的新代碼對其他部分有沒有影響?”。這種擔心甚導致某些代碼應該修改卻不敢修改的地步。測試驅動開發提供的測試集就可以作為你信心的來 源。

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

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

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

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

我們這里把這個技術的應用領域從代碼編寫擴展到整個開發過程。應該對整個開發過程的各個階段進行測試驅動,首先思考如何對這個階段進行測試、驗證、考核,并編寫相關的測試文檔,然后開始下一步工作,后再驗證相關的工作。下圖是一個比較流行的測試模型:V測試模型。

【圖 V測試模型】

在開發的各個階段,包括需求分析、概要設計、詳細設計、編碼過程中都應該考慮相對應的測試工作,完成相關的測試用例的設計、測試方案、測試計劃的編 寫。這里提到的開發階段只是舉例,根據實際的開發活動進行調整。相關的測試文檔也不一定是非常詳細復雜的文檔,或者什么形式,但應該養成測試驅動的習慣。

關于測試模型,還有X測試模型。這個測試模型,我認為,是對詳細階段和編碼階段進行建模,應該說更詳細的描述了詳細設計和編碼階段的開發行為。及針對某個功能進行對應的測試驅動開發。

【圖 X測試模型】

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

3. 過程
軟件開發其他階段的測試驅動開發,根據測試驅動開發的思想完成對應的測試文檔即可。下面針對詳細設計和編碼階段進行介紹。

測試驅動開發的基本過程如下:

1) 明確當前要完成的功能?梢杂涗洺梢粋 TODO 列表。

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

3) 測試代碼編譯不通過。

4) 編寫對應的功能代碼。

5) 測試通過。

6) 對代碼進行重構,并保證測試通過。

7) 循環完成所有功能的開發。

為了保證整個測試過程比較快捷、方便,通?梢允褂脺y試框架組織所有的測試用例。一個免費的、優秀的測試框架是 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

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

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

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

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

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

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

可測試性。功能代碼設計、開發時應該具有較強的可測試性。其實遵循比較好的設計原則的代碼都具備較好的測試性。比如比較高的內聚性,盡量依賴于接口等。

及時重構。無論是功能代碼還是測試代碼,對結構不合理,重復的代碼等情況,在測試通過后,及時進行重構。關于重構,我會另撰文詳細分析。

小步前進。軟件開發是個復雜性非常高的工作,開發過程中要考慮很多東西,包括代碼的正確性、可擴展性、性能等等,很多問題都是因為復雜性太大導致 的。極限編程提出了一個非常好的思路就是小步前進。把所有的規模大、復雜性高的工作,分解成小的任務來完成。對于一個類來說,一個功能一個功能的完成,如 果太困難就再分解。每個功能的完成就走測試代碼-功能代碼-測試-重構的循環。通過分解降低整個系統開發的復雜性。這樣的效果非常明顯。幾個小的功能代碼 完成后,大的功能代碼幾乎是不用調試就可以通過。一個個類方法的實現,很快就看到整個類很快就完成啦。本來感覺很多特性需要增加,很快就會看到沒有幾個 啦。你甚會為這個速度感到震驚。(我理解,是大幅度減少調試、出錯的時間產生的這種速度感)

5. 測試技術

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

測試驅動開發強調測試并不應該是負擔,而應該是幫助我們減輕工作量的方法。而對于何時停止編寫測試用例,也是應該根據你的經驗,功能復雜、核心功能的代碼就應該編寫更、細致的測試用例,否則測試流程即可。

測試范圍沒有靜態的標準,同時也應該可以隨著時間改變。對于開始沒有編寫足夠的測試的功能代碼,隨著bug的出現,根據bug補齊相關的測試用例即可。

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

5.2. 怎么編寫測試用例
測試用例的編寫就用上了傳統的測試技術。

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

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

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


[轉自網絡]