《轉(zhuǎn)載軟件開發(fā)流程》word版

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

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

3、，需求和設計中的問題是無法在項目開發(fā)的前期被檢測出來的，只有當?shù)谝淮蜗到y(tǒng)集成時，這些設計缺陷才會在測試中暴露出來，從而導致一系列的返工：重新設計、編碼、測試，進而導致項目的延期和開發(fā)成本的上升。2.采用迭代化開發(fā)控制項目風險為了解決傳統(tǒng)軟件開發(fā)流程中的問題，我們建議采用迭代化的開發(fā)方法來取代瀑布模型。在瀑布模型中，我們要完成的是整個軟件系統(tǒng)開發(fā)這個大目標。在迭代化的方法中，我們將整個項目的開發(fā)目標劃分成為一些更易于完成和達到的階段性小目標，這些小目標都有一個定義明確的階段性評估標準。迭代就是為了完成一定的階段性目標而所從事的一系列開發(fā)活動，在每個迭代開始前都要根據(jù)項目當前的狀態(tài)和所要達到的階段

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

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

6、從而有助于他們增強信心，更好地完成開發(fā)任務。而在非迭代式開發(fā)中，開發(fā)人員只有在項目接近尾聲時才能看到開發(fā)的結(jié)果，在此之前的相當長時間，大家還是在不確定性中摸索前近。生成更高質(zhì)量的產(chǎn)品每次迭代都會產(chǎn)生一個可運行的系統(tǒng)，通過對這個可運行系統(tǒng)進行測試，我們在早期的迭代中就可以及時發(fā)現(xiàn)缺陷并改正，性能上的瓶頸也可以盡早發(fā)現(xiàn)并處理。因為在每次迭代中總是不斷地糾正錯誤，我們可以得到更高質(zhì)量的產(chǎn)品。保證項目開發(fā)進度每次迭代結(jié)束時都會進行評估，來判斷該次迭代有沒有達到預定的目標。項目經(jīng)理可以很清楚地知道有哪些需求已經(jīng)實現(xiàn)了，并且比較準確地估計項目的狀態(tài)，對項目的開發(fā)進度進行必要的調(diào)整，保證項目按時完成。容許產(chǎn)

7、品進行戰(zhàn)術(shù)改變迭代化的開發(fā)具有更大的靈活性，在迭代過程中可以隨時根據(jù)業(yè)務情況或市場環(huán)境來對產(chǎn)品的開發(fā)進行調(diào)整。例如為了同現(xiàn)有的同類產(chǎn)品競爭，可以決定采用搶先競爭對手一步的方法，提前發(fā)布一個功能簡化的產(chǎn)品。迭代流程自身可在進行過程中得到改進和精煉一次迭代結(jié)束時的評估不僅要從產(chǎn)品和進度的角度來考察項目的情況，而且還要分析組織和流程本身有什么待改進之處，以便在下次迭代中更好地完成任務。迭代化方法解決的主要是對于風險的控制問題，從下圖可以看出，傳統(tǒng)的開發(fā)流程中系統(tǒng)的風險要到項目開發(fā)的后期(主要是測試階段)才能夠被真正降低。而迭代化開發(fā)中的風險，可以在項目開發(fā)的早期通過幾次迭代來盡快地解決掉。在早期的迭

8、代中一旦遇到問題，如某一個迭代沒有完成預定的目標，我們還可以及時調(diào)整開發(fā)進度以保證項目按時完成。一般到了項目開發(fā)的后期(風險受控階段)，由于大部分高風險的因素(如需求、架構(gòu)、性能等)都已經(jīng)解決，這時候只需要投入更多的資源去實現(xiàn)剩余的需求即可。這個階段的項目開發(fā)具有很強的可控性，從而保證我們按時交付一個高質(zhì)量的軟件系統(tǒng)。迭代化開發(fā)不是一種高深的軟件工程理論，它提供了一種控制項目風險的非常有效的機制。在日常的工作我們也經(jīng)常地應用到這一基本思想，如對于一個非常大型的工程項目，我們經(jīng)常會把它分為幾期來分步實施，從而把復雜的問題分解為相對容易解決的小問題，并且能夠在較短周期內(nèi)看到部分系統(tǒng)實現(xiàn)的效果，通過

9、盡早暴露問題來幫助我們及早調(diào)整我們的開發(fā)資源，加強項目進度的可控程度，保證項目的按時完成。3.管理迭代化的軟件項目當我們在實際工作中實踐迭代化思想時，Rational統(tǒng)一開發(fā)流程RUP(Rational Unified Process)可以給予我們實踐的指導。RUP是一個通用的軟件流程框架，它是一個以架構(gòu)為中心、用例驅(qū)動的迭代化軟件開發(fā)流程。RUP是從幾千個軟件項目的實踐經(jīng)驗中總結(jié)出來的，對于實際的項目具有很強的指導意義，是軟件開發(fā)行業(yè)事實上的行業(yè)標準。3.1軟件開發(fā)的四個階段在RUP中，我們把軟件開發(fā)生命周期劃分為四個階段，每個階段的結(jié)束標志就是一個主要的里程碑(如下圖所示)。這四個階段主要

10、是為了達到以下階段性的目標里程碑：先啟(Inception)：確定項目開發(fā)的目標和范圍精化(Elaboration)：確定系統(tǒng)架構(gòu)和明確需求構(gòu)建(Construction)：實現(xiàn)剩余的系統(tǒng)功能產(chǎn)品化(Transition)：完成軟件的產(chǎn)品化工作，將系統(tǒng)移交給客戶每個目標里程碑都是一個商業(yè)上的決策點，如先啟階段結(jié)束之后，我們就要決定這個項目是否可行、是否要繼續(xù)做這個項目。每一個階段都是由里程碑來決定的，判斷一個階段是否結(jié)束的標志就是看項目當前的狀態(tài)是否滿足里碑中所規(guī)定的條件。從這種階段劃分模式中可以看出，項目的主要風險集中在前兩個階段。在精化階段中經(jīng)過幾次迭代后，我們要為系統(tǒng)建立一個穩(wěn)定的架構(gòu)，

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

12、。在項目開發(fā)周期中，開發(fā)資源的分配可以如下圖所示。這樣安排可以最充分有效地利用公司的開發(fā)資源，緩解軟件公司對于人力資源不斷增長的需求，從而降低成本。另外一方面，由于前兩個階段(先啟和精化)的風險較高，我們只是投入部分的資源，一旦發(fā)生返工或是項目目標的改變，我們也可以將資源浪費降到最低點。在傳統(tǒng)的軟件開發(fā)流程中，對于開發(fā)資源的分配基本上是貫穿整個項目周期而不變的，資源往往沒有得到充分有效地利用。基于這種資源分配模式，一個典型的項目在項目進度和所完成的工作量之間的關系可能如下表中的數(shù)據(jù)所示。先啟精化構(gòu)建產(chǎn)品化工作量5%20%65%10%進度10%30%50%10%3.3迭代策略關于迭代計劃的安排，

13、通常有以下四種典型的策略模式：增量式(Incremental)這種模式的特點是項目架構(gòu)的風險較小(往往是開發(fā)一些重復性的項目)，所以精化階段只需要一個迭代。但項目的開發(fā)工作量較大，構(gòu)建階段需要有多次迭代來實現(xiàn)，每次迭代都在上一次迭代的基礎上增加實現(xiàn)一部分的系統(tǒng)功能，通過迭代的進行而逐步實現(xiàn)整個系統(tǒng)的功能。演進式(Evolutionary)當項目架構(gòu)的風險較大時(從未開發(fā)過類似項目)，需要在精化階段通過多次迭代來建立系統(tǒng)的架構(gòu)，架構(gòu)是通過多次迭代的探索，逐步演化而來的。當架構(gòu)建立時，往往系統(tǒng)的功能也已經(jīng)基本實現(xiàn)，所以構(gòu)建階段只需要一次迭代。增量提交(Incremental Delivery)這種

14、模式的特點產(chǎn)品化階段的迭代較多，比較常見的例子是項目的難度并不大，但業(yè)務需求在不斷地發(fā)生變化，所以需要通過迭代來不斷地部署完成的系統(tǒng)；但同時又要不斷地收集用戶的反饋來完善系統(tǒng)需求，并通過后續(xù)的迭代來補充實現(xiàn)這些需求。應用這種策略時要求系統(tǒng)架構(gòu)非常穩(wěn)定，能夠適應滿足后續(xù)需求變化的要求。單次迭代(Grand Design)傳統(tǒng)的瀑布模型可以看作是迭代化開發(fā)的一個特例，整個開發(fā)流程只有一次迭代。但這種模式有一個固有的弱點，由于它對風險的控制能力較差，往往會在產(chǎn)品化階段產(chǎn)生一些額外的迭代，造成項目的延誤。這幾種迭代策略只是一些典型模式的代表，實際應用中應根據(jù)實際情況靈活應用，最常見的迭代計劃往往是這幾

15、種模式的組合。3.4制定項目開發(fā)計劃在迭代化的開發(fā)模式中，項目開發(fā)計劃也是隨著項目的進展而不斷細化、調(diào)整并完善的。傳統(tǒng)的項目開發(fā)計劃是在項目早期制定的，項目經(jīng)理總是試圖在項目的一開始就制定一個非常詳細完善的開發(fā)計劃。與之相反，迭代開發(fā)模式認為在項目早期只需要制定一個比較粗略的開發(fā)計劃，因為隨著項目的進展，項目的狀態(tài)在不斷地發(fā)生變化，項目經(jīng)理需要隨時根據(jù)迭代的結(jié)果來對項目計劃進行調(diào)整，并制定下一次迭代的詳細計劃。在RUP中，我們把項目開發(fā)計劃分為以下三部分：項目計劃確定整個項目的開發(fā)目標和進度安排，包括每一個階段的起止時間段。階段計劃當前階段中包含有幾個迭代，每一次迭代要達到的目標以及進度安排。

16、迭代計劃針對當前迭代的詳細開發(fā)計劃，包括開發(fā)活動以及相關資源的分配。項目開發(fā)計劃也是完全體現(xiàn)迭代化的思想，每次迭代中項目經(jīng)理都會根據(jù)項目情況來不斷地調(diào)整和細化項目開發(fā)計劃。迭代計劃是在對上一次迭代結(jié)果進行評估的基礎上制定的，如果上一次迭代達到了預定的目標，那么當前迭代只需要解決剩下的問題；如果上一次迭代中留有一些問題還沒有解決，則當前迭代還需要繼續(xù)去解決這些問題。所以必須注意，迭代是不能重疊的，即你還沒有完成當前迭代時，你決不能進入下一迭代，因為下一次迭代的計劃是根據(jù)當前迭代的結(jié)果而制定的。Rational開發(fā)過程1.引言本文對Rational軟件開發(fā)過程(Rational Software

17、Development Process)的原理和結(jié)構(gòu)給出了高度的描述，它是：迭代的、增量的開發(fā)過程面向?qū)ο蟮拈_發(fā)過程管理和控制的開發(fā)過程它具有足夠的普遍性，可以在規(guī)模與應用領域方面，為各個軟件產(chǎn)品和項目量身訂做。2.1兩種視角Rational過程可以從兩種不同而又密不可分的視角來觀察：從管理的角度，即從業(yè)務和經(jīng)濟的角度來看，對應項目的進展，軟件的生命周期包含四個主要階段：起始階段(Inception)-有一個好的想法：詳細構(gòu)想出最終產(chǎn)品的設想和它的業(yè)務案例，確定項目的范圍。細化階段(Elaboration)-計劃必要的活動和所需資源，詳細確定功能并設計構(gòu)架。構(gòu)建階段(Construction)

18、-構(gòu)建產(chǎn)品，發(fā)展最初的設想、構(gòu)架和計劃，直到一個可以交付給用戶的產(chǎn)品(完成后的設想)完成。移交階段(Transition)-將產(chǎn)品移交用戶使用，包括：制造、交付、培訓、支持、維護，直到用戶滿意。完成這4個階段稱為一個開發(fā)周期,它產(chǎn)生的軟件稱作第一代(generation)。除非產(chǎn)品的生命結(jié)束，一個現(xiàn)有產(chǎn)品可以通過重復下一個相同的起始、細化、構(gòu)建和移交四階段，各個階段的側(cè)重點與第一次不同，從而演進為下一代產(chǎn)品。這個時期我們稱之為演進(evolution)。最后伴隨著產(chǎn)品經(jīng)過幾個周期的演進，新一代產(chǎn)品也不斷被制造出來。例如，演進周期的啟動可能由以下這幾項觸發(fā)：用戶建議增強功能、用戶環(huán)境的改變、重要

19、技術(shù)的變更，以及應對競爭的需要。實際中，周期之間會有輕微重疊：起始階段和細化階段可能會在上一個周期的移交階段未結(jié)束時就開始了。2.3.迭代從技術(shù)的角度來看，軟件開發(fā)可以視為一連串的迭代過程，通過這些迭代被開發(fā)的軟件得以增量演進。每次迭代都以一個可執(zhí)行的產(chǎn)品的發(fā)布而結(jié)束，該產(chǎn)品可能是完整版本的一個子集，但從工程的或用戶的角度來看是有用的。每次發(fā)布都伴隨一些支持性工件：版本描述、用戶文檔和計劃等。一次迭代包括以下活動：計劃、分析、設計、實施和測試。根據(jù)迭代在開發(fā)周期中所處位置的不同，這些活動分別占不同的比例。管理角度和技術(shù)角度之間是協(xié)調(diào)的，而且各個階段的結(jié)束還和各次迭代的結(jié)束保持同步。換句話說，每

20、個階段可以分為一次或多次迭代過程。(注意：本圖中每階段的迭代數(shù)目僅為示意)但是，這兩個角度(管理角度和技術(shù)角度)，不僅僅只是保持同步，它們還具有一些完全相同的里程碑，它們共同貢獻出一些隨時間演進的產(chǎn)品和工件。一些工件更多地處于技術(shù)方面控制之下，另一些工件更多地處于管理方面的控制之下。見第五節(jié)。這些工件的可用性、工件是否滿足所建立的評估標準，是構(gòu)成里程碑的主要具體元素，比日歷牌上的日期提供了多得多的內(nèi)容。像周期一樣，迭代之間也會有輕微重疊。即第N次迭代的計劃和構(gòu)架在第N-1次迭代還未結(jié)束時就開始了。有時候，迭代也會平行進行：一個工作于系統(tǒng)某一部分的小組，可能在某個迭代內(nèi)沒有可交付的工件。2.4.

21、區(qū)別對于不同的項目而言，每個階段的側(cè)重點，入口和出口準則，一個開發(fā)周期的各個工件，以及各次迭代的數(shù)目和長度都會不同。這主要取決于作為過程判別式的的四個主要項目特征。按照影響程度降序排列，它們是：業(yè)務環(huán)境契約性工作，開發(fā)者基于給定的客戶規(guī)格說明只為該客戶開發(fā)軟件。推測性開發(fā)或商業(yè)開發(fā)，開發(fā)者開發(fā)軟件以推向市場。內(nèi)部項目，開發(fā)者和客戶在同一個機構(gòu)中。軟件開發(fā)工作量的規(guī)模：按照一些度量標準來確定，比如Delivered Source Instructions，或功能點、人-月數(shù)，或者只按照成本。新穎程度：對于軟件開發(fā)組織，這個軟件新穎程度如何有多新，尤其是該軟件是否為第二次或更后面的周期。這項區(qū)別包

22、括了組織和過程的成熟度、資產(chǎn)、技術(shù)水平，當前的技狀況，以及諸如組建并培訓團隊、獲取工具及其他資源這樣的問題。應用類型，目標領域：MIS，命令和控制系統(tǒng),嵌入式實時系統(tǒng),軟件開發(fā)環(huán)境工具等等,尤其時具體的應用領域會給開發(fā)提出特殊的約束條件：安全性、性能、國際化、內(nèi)存限制等。本文首先描述適用所有類型軟件開發(fā)的通用過程，然后描述了一些有區(qū)別價值的特定過程實例，并列舉了幾個例子。2.5工作量和日程安排各階段在工作量和時間安排上是不同的。盡管由于不同項目類型之間相差會很大，一個典型的中等規(guī)模項目的最初開發(fā)周期可以預計為下面的比率：起始階段細化階段構(gòu)建階段移交階段工作量5%20%65%10%日程安排10%

23、30%50%10%可以用下圖表示：但是對于一個演進周期來說，起始階段和細化階段可能大大縮減。使用特定工具和技術(shù)(如應用程序構(gòu)建器)，構(gòu)建階段可以遠遠小于起始階段和細化階段的總和。3.1.起始階段這個階段產(chǎn)生一個預測產(chǎn)品的最初設想，并將其轉(zhuǎn)換為一個實際的項目。本階段的目的是建立一個新產(chǎn)品或一次大的更新的業(yè)務案例，并且指定項目的范圍。對于一個新產(chǎn)品的開發(fā)，本階段的主要結(jié)果是得到一個做還是不做的決定以進入下一階段，并投入一定的時間和資金來詳細分析構(gòu)建什么、能否構(gòu)建，以及如何構(gòu)建。對于一個現(xiàn)有產(chǎn)品的演進，這會是一個簡短的階段，主要看用戶或客戶的要求、問題報告，或是新的技術(shù)動態(tài)。對于一個契約性的開發(fā)，是

24、否進行項目的決定取決于在特定領域的經(jīng)驗、以及組織在此領域的競爭力和市場情況。這里起始階段可以歸結(jié)為一個參加投標的決定，或投標活動本身。該決定可能是基于一個現(xiàn)有的研究原型，其結(jié)構(gòu)對最終軟件可能合適，也可能不合適。入口準則：對于一項需要的描述，可以采用以下形式：一份最初的設想一個遺留系統(tǒng)一份建議請求(An RFP-request for proposal)先前一代的產(chǎn)品和一個增強要求清單一些資產(chǎn)(軟件,專門技能,財務資產(chǎn))一個概念原型或?qū)嵨锬Ｐ统隹跍蕜t：一個初始的業(yè)務案例至少要包含以下內(nèi)容：對產(chǎn)品設想的明確表達即核心需求，表述為功能、范圍、性能、容量和技術(shù)等。成功標準(如收入的數(shù)目)最初的風險評估

25、完成細化階段所需的資源估算通常在初試階段結(jié)束時，我們將得到：一個最初的域分析模型(完成大約10%-20%),確定最關鍵的用例,并且足以進行進構(gòu)架工作。一個最初的構(gòu)架原型，在這個階段可以是一個一次性原型3.2.細化階段本階段的主要目的是更徹底地分析問題域，定義構(gòu)架并使之穩(wěn)定，確定項目的最大風險。這樣在本階段結(jié)束時，我們可以得到一個關于下2個階段如何工作的綜合計劃：一個基于分析模型的基線產(chǎn)品設想(即最初的需求集合)。至少對第一次構(gòu)建迭代的評價準則。一個基線軟件構(gòu)架。開發(fā)和部署產(chǎn)品的必需資源，尤其是人員和工具。一份日程安排。足以對構(gòu)建階段的成本、日程安排和質(zhì)量做出精確的評估的一份風險決議。在這個階段

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

27、理者和投資者認可的計劃，和細化階段所需的資源出口準則：一份詳細的軟件開發(fā)計劃，包含：更新后的風險評估一份管理計劃一份人員配置計劃一份顯示迭代內(nèi)容和次數(shù)的階段計劃一份迭代計劃，詳細計劃下次迭代開發(fā)環(huán)境和所需的其他工具一份測試計劃一個基線設想，以對最終產(chǎn)品的一個評估準則的集合的形式用于評估構(gòu)建階段最初的迭代結(jié)果的客觀、可測量的演進標準一個域分析模型(80%完成)，相應的構(gòu)架可以稱之為是完整的一個軟件構(gòu)架描述(說明約束和限制)一個可執(zhí)行的構(gòu)架基線3.3.構(gòu)建階段本階段可以劃分為數(shù)次迭代，不斷充實構(gòu)架基線，向最終產(chǎn)品逐步演進或增量演進。在每次迭代過程中，上個階段(細化階段)的工件得到擴充和修正，但它們

28、最終將隨著系統(tǒng)向正確和完整的方向的演進而穩(wěn)定下來。在這個階段，除了軟件本身，還生成一些新的工件：文檔(既有內(nèi)部使用的文檔，也有面向最終用戶的文檔)、測試床及測試套件、部署附件，以及用于支持下一階段的部署輔助(例如銷售輔助)。對每次迭代，都具有：入口準則：上次迭代的產(chǎn)品和工件。迭代計劃必須闡明迭代的特定目標：將要開發(fā)的新增功能，覆蓋了哪些用例或場景本次迭代過程中減少的風險本次迭代過程中修改的缺陷出口準則：更新后的產(chǎn)品和工件，另外還有：一個版本描述文檔，記錄了迭代的結(jié)果測試用例和根據(jù)產(chǎn)品得出的測試結(jié)果一個詳細描述下一次迭代的計劃對下一次迭代的客觀度量標準到構(gòu)建階段的后期，必須完成以下工件，及本階段

29、最后一次迭代額外的出口準則：一個部署計劃，指定必需的事項：打包定價演示支持培訓移交策略(例如一個現(xiàn)有系統(tǒng)的更新計劃)產(chǎn)品(軟盤和手冊)用戶文檔3.4.移交階段移交階段是將產(chǎn)品交付給最終用戶的階段。它涉及銷售、打包、安裝、配置、支持用戶社區(qū)和做出修正等.從技術(shù)角度來看，伴隨本階段迭代的是一次或多次發(fā)布：beta版發(fā)布、正式版發(fā)布、修補bug,或增強版發(fā)布。當用戶對產(chǎn)品滿意時，本階段即告結(jié)束。例如，契約性開發(fā)時正式驗收，或者產(chǎn)品有關的所有活動都已結(jié)束。此時，某些積累的資產(chǎn)可以加以整理，以為下一個周期或其他項目重用。入口準則：上一次迭代的產(chǎn)品和工件，尤其是足夠成熟可以交付給用戶的軟件產(chǎn)品出口準則：前

30、一階段某些文檔的更新，以及必要時根據(jù)原始及修訂后的成功標準，進行事后項目性能分析，從而替換原有計劃。一個簡短的清單，列出本次開發(fā)周期給組織帶來的新的資產(chǎn)3.5.演進周期對于重要的演進，我們應用整個過程遞歸，仍從起始階段開始一個新的周期。因為我們已經(jīng)有了一個產(chǎn)品，所以比起一個初次開發(fā)的產(chǎn)品，起始階段可能大大縮短。細化階段也可能縮小范圍，而在計劃方面的關注程度要大于分析或構(gòu)架的演進方面。需要指出：周期之間可以略有重疊。較小的演進可以通過延長移交階段或增加一兩次迭代來完成。移交階段可以以一個終結(jié)過程而結(jié)束，即產(chǎn)品不再演進了，但是為了終結(jié)它，需要采取一些特定的動作。4.Rational過程中的活動Ra

31、tional過程中各個階段的名稱(如起始、細化、構(gòu)建、移交)與描述高級活動的術(shù)語(如分析、設計、測試等)相差甚遠。因此我們?nèi)菀桌斫饽撤N活動的進行并不局限于某個特定階段，也與其他作者、標準及特定領域的所使用的術(shù)語無關。這些活動確實發(fā)生，但它們在每個階段和每次迭代中的程度有所不同。下圖表明了活動重點如何隨時間的推進而發(fā)生演進。圖中活動重點的變化也說明盡管每次迭代在形式上都是相似的，但它們的性質(zhì)和內(nèi)容卻是隨時間而改變的。這還表明，一項活動的結(jié)束并不總意味著另一項活動的開始，即并不是分析完成了才開始設計，而是這些活動相關的各種工件在隨著開發(fā)者對問題或需求的理解的加深也不斷得到更新。最后，在一個迭代過程中，計劃、測試和集成這些活動不是集中堆積在開發(fā)活動的開始和結(jié)束階段，而是增量地分布在整個開發(fā)周期的各個階段、每次迭代之中。