02第二章：軟件過程報(bào)告

軟件工程過程是為了獲得高質(zhì)量軟件所需要完成的一系列任務(wù)的框架，它規(guī)定了完成各項(xiàng)任務(wù)的工作步驟。

本章講述在軟件生命周期全過程中應(yīng)該完成的基本任務(wù)，并介紹各種常用的過程模型。第二章：軟件過程2.1軟件生命周期的基本任務(wù)2.2瀑布模型2.3快速原型模型2.4增量模型2.5螺旋模型2.6噴泉模型2.7Rational統(tǒng)一過程2.8敏捷過程與極限編程2.9能力成熟度模型第二章：軟件過程1.軟件定義：確定軟件開發(fā)工程必須完成的總目標(biāo)；確定工程的可行性；導(dǎo)出實(shí)現(xiàn)工程目標(biāo)應(yīng)該采用的策略及系統(tǒng)必須完成的功能；估計(jì)完成該項(xiàng)工程需要的資源和成本，并且制訂工程進(jìn)度表。這個(gè)時(shí)期的工作通常又稱為系統(tǒng)分析，由系統(tǒng)分析員負(fù)責(zé)完成。軟件定義時(shí)期通常進(jìn)一步劃分為3個(gè)階段，即問題定義、可行性研究和需求分析。軟件生命周期：2.軟件開發(fā)：具體設(shè)計(jì)和實(shí)現(xiàn)在前一個(gè)時(shí)期定義的軟件，它通常由下述4個(gè)階段組成：概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼和單元測試、綜合測試。其中前兩個(gè)階段又稱為系統(tǒng)設(shè)計(jì)，后兩個(gè)階段又稱為系統(tǒng)實(shí)現(xiàn)。軟件生命周期：3.運(yùn)行維護(hù)：當(dāng)軟件在使用過程中發(fā)現(xiàn)錯(cuò)誤時(shí)應(yīng)該加以改正；當(dāng)環(huán)境改變時(shí)應(yīng)該修改軟件以適應(yīng)新的環(huán)境；當(dāng)用戶有新要求時(shí)應(yīng)該及時(shí)改進(jìn)軟件以滿足用戶的新需要。通常對維護(hù)時(shí)期不再進(jìn)一步劃分階段，但是每一次維護(hù)活動本質(zhì)上都是一次壓縮和簡化了的定義和開發(fā)過程。軟件生命周期：

通過調(diào)研，系統(tǒng)分析員應(yīng)該提出關(guān)于問題性質(zhì)、工程目標(biāo)和工程規(guī)模的書面報(bào)告，并且需要得到客戶對這份報(bào)告的確認(rèn)。2.1.1問題定義確定上一個(gè)階段的問題是否有行得通的解決辦法用最小的代價(jià)在盡可能短的時(shí)間內(nèi)確定問題是否能夠解決。2.1.2可行性研究解決“目標(biāo)系統(tǒng)必須做什么”這個(gè)問題可行性研究的基本目的是用較小的成本在較短的時(shí)間內(nèi)確定是否存在可行的解法，因此許多細(xì)節(jié)被忽略了。然而在最終的系統(tǒng)中卻不能遺漏任何一個(gè)微小的細(xì)節(jié)是用正式文檔準(zhǔn)確地記錄對目標(biāo)系統(tǒng)的需求，該文檔通常稱為規(guī)格說明書（specification）。2.1.3需求分析概括地回答“怎樣實(shí)現(xiàn)目標(biāo)系統(tǒng)？”概要設(shè)計(jì)又稱為初步設(shè)計(jì)、邏輯設(shè)計(jì)、高層設(shè)計(jì)或總體設(shè)計(jì)。設(shè)計(jì)幾種可能的方案推薦最佳方案制定詳細(xì)計(jì)劃模塊化2.1.4概要設(shè)計(jì)將抽象概括的方式具體化“應(yīng)該怎樣具體地實(shí)現(xiàn)這個(gè)系統(tǒng)”設(shè)計(jì)出程序的詳細(xì)規(guī)格說明詳細(xì)設(shè)計(jì)也稱為模塊設(shè)計(jì)、物理設(shè)計(jì)或低層設(shè)計(jì)。在這個(gè)階段將詳細(xì)地設(shè)計(jì)每個(gè)模塊，確定實(shí)現(xiàn)模塊功能所需要的算法和數(shù)據(jù)結(jié)構(gòu)。2.1.5詳細(xì)設(shè)計(jì)這個(gè)階段的關(guān)鍵任務(wù)是寫出正確的，容易理解、容易維護(hù)的程序模塊程序員應(yīng)該根據(jù)目標(biāo)系統(tǒng)的性質(zhì)和實(shí)際環(huán)境，選取一種適當(dāng)?shù)母呒壋绦蛟O(shè)計(jì)語言（必要時(shí)用匯編語言），把詳細(xì)設(shè)計(jì)的結(jié)果翻譯成用選定的語言書寫的程序，并且仔細(xì)測試編寫出的每一個(gè)模塊。2.1.6編碼和單元測試這個(gè)階段的關(guān)鍵任務(wù)是通過各種類型的測試（及相應(yīng)的調(diào)試）使軟件達(dá)到預(yù)定的要求。最基本的測試是集成測試和驗(yàn)收測試。必要時(shí)還可以再通過現(xiàn)場測試或平行運(yùn)行等方法對目標(biāo)系統(tǒng)進(jìn)一步測試檢驗(yàn)。2.1.7綜合測試集成測試是根據(jù)設(shè)計(jì)的軟件結(jié)構(gòu)，把經(jīng)過單元測試檢驗(yàn)的模塊按某種選定的策略裝配起來，在裝配過程中對程序進(jìn)行必要的測試。驗(yàn)收測試則是按照規(guī)格說明書的規(guī)定（通常在需求分析階段確定），由用戶（或在用戶積極參加下）對目標(biāo)系統(tǒng)進(jìn)行驗(yàn)收。2.1.7綜合測試通過各種必要的維護(hù)活動使系統(tǒng)持久地滿足用戶的需要。改正性維護(hù)：也就是診斷和改正在使用過程中發(fā)現(xiàn)的軟件錯(cuò)誤適應(yīng)性維護(hù)：即修改軟件以適應(yīng)環(huán)境的變化2.1.8軟件維護(hù)完善性維護(hù)：即根據(jù)用戶的要求改進(jìn)或擴(kuò)充軟件使它更完善預(yù)防性維護(hù)：即修改軟件為將來的維護(hù)活動預(yù)先做準(zhǔn)備。2.1.8軟件維護(hù)實(shí)際上每一項(xiàng)維護(hù)活動都應(yīng)該經(jīng)過提出維護(hù)要求（或報(bào)告問題），分析維護(hù)要求，提出維護(hù)方案，審批維護(hù)方案，確定維護(hù)計(jì)劃，修改軟件設(shè)計(jì)，修改程序，測試程序，復(fù)查驗(yàn)收等一系列步驟。因此，實(shí)質(zhì)上是經(jīng)歷了一次壓縮和簡化了的軟件定義和開發(fā)的全過程。每一項(xiàng)維護(hù)活動都應(yīng)該準(zhǔn)確地記錄下來，作為正式的文檔資料加以保存。2.1.8軟件維護(hù)2.1軟件生命周期的基本任務(wù)2.2瀑布模型2.3快速原型模型2.4增量模型2.5螺旋模型2.6噴泉模型2.7Rational統(tǒng)一過程2.8敏捷過程與極限編程2.9能力成熟度模型第二章：軟件過程在20世紀(jì)80年代之前，瀑布模型（waterfallmodel）一直是唯一被廣泛采用的生命周期模型，現(xiàn)在它仍然是軟件工程中應(yīng)用最廣泛的過程模型。圖2.1所示為傳統(tǒng)的瀑布模型。2.2瀑布模型2.2瀑布模型圖2.1傳統(tǒng)的瀑布模型1.階段間具有順序性和依賴性

①必須等前一階段的工作完成之后，才能開始后一階段的工作；②前一階段的輸出文檔就是后一階段的輸入文檔。2.推遲實(shí)現(xiàn)的觀點(diǎn)

實(shí)踐表明，對于規(guī)模較大的軟件項(xiàng)目來說，往往編碼開始得越早最終完成開發(fā)工作所需要的時(shí)間反而越長。傳統(tǒng)的瀑布模型的特點(diǎn)3.質(zhì)量保證的觀點(diǎn)①每個(gè)階段都必須完成規(guī)定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務(wù)。②每個(gè)階段結(jié)束前都要對所完成的文檔進(jìn)行評審，以便盡早發(fā)現(xiàn)問題，改正錯(cuò)誤。傳統(tǒng)的瀑布模型的特點(diǎn)傳統(tǒng)的瀑布模型過于理想化了。事實(shí)上，人在工作過程中不可能不犯錯(cuò)誤。因此，實(shí)際的瀑布模型是帶“反饋環(huán)”的，如圖2.2所示（圖中實(shí)線箭頭表示開發(fā)過程，虛線箭頭表示維護(hù)過程）。當(dāng)在后面階段發(fā)現(xiàn)前面階段的錯(cuò)誤時(shí)，需要沿圖中左側(cè)的反饋線返回前面的階段，修正前面階段的產(chǎn)品之后再回來繼續(xù)完成后面階段的任務(wù)。2.2瀑布模型2.2瀑布模型圖2.2加入迭代過程的瀑布模型可強(qiáng)迫開發(fā)人員采用規(guī)范的方法嚴(yán)格地規(guī)定了每個(gè)階段必須提交的文檔要求每個(gè)階段交出的所有產(chǎn)品都必須經(jīng)過質(zhì)量保證小組的仔細(xì)驗(yàn)證瀑布模型的優(yōu)點(diǎn)瀑布模型是由文檔驅(qū)動的”：在可運(yùn)行的軟件產(chǎn)品交付給用戶之前，用戶只能通過文檔來了解產(chǎn)品是什么樣的。很可能最終開發(fā)出的軟件產(chǎn)品不能真正滿足用戶的需要。瀑布模型的缺點(diǎn)（1）用戶的需求非常清楚全面，且在開發(fā)過程中沒有或很少變化（2）開發(fā)人員對軟件的應(yīng)用領(lǐng)域很熟悉（3）用戶的使用環(huán)境非常穩(wěn)定（4）開發(fā)工作對用戶參與的要求很低瀑布模型的適用范圍2.1軟件生命周期的基本任務(wù)2.2瀑布模型2.3快速原型模型2.4增量模型2.5螺旋模型2.6噴泉模型2.7Rational統(tǒng)一過程2.8敏捷過程與極限編程2.9能力成熟度模型第二章：軟件過程快速原型（rapidprototype）是快速建立起來的可以在計(jì)算機(jī)上運(yùn)行的程序，它所能完成的功能往往是最終產(chǎn)品能完成的功能的一個(gè)子集。如圖2.3所示（圖中實(shí)線箭頭表示開發(fā)過程，虛線箭頭表示維護(hù)過程）2.3快速原型模型2.3快速原型模型圖2.3快速模型原型優(yōu)點(diǎn)：快速原型模型是不帶反饋環(huán)的，軟件產(chǎn)品的開發(fā)基本上是按線性順序進(jìn)行的。原型系統(tǒng)已經(jīng)通過與用戶交互而得到驗(yàn)證，據(jù)此產(chǎn)生的規(guī)格說明文檔正確地描述了用戶需求。開發(fā)人員通過建立原型系統(tǒng)已經(jīng)學(xué)到了許多東西，在設(shè)計(jì)和編碼階段發(fā)生錯(cuò)誤的可能性也比較小。2.3快速原型模型快速原型的本質(zhì)是“快速”。開發(fā)人員應(yīng)該盡可能快地建造出原型系統(tǒng)，以加速軟件開發(fā)過程，節(jié)約軟件開發(fā)成本。原型的用途是獲知用戶的真正需求，一旦需求確定了，原型將被拋棄。當(dāng)快速原型的某個(gè)部分是利用軟件工具由計(jì)算機(jī)自動生成的時(shí)候，可以把這部分用到最終的軟件產(chǎn)品中。2.3快速原型模型（1）對所開發(fā)的領(lǐng)域比較熟悉而且有快速的原型開發(fā)工具（2）項(xiàng)目招投標(biāo)時(shí)，可以以原型模型作為軟件的開發(fā)模型（3）進(jìn)行產(chǎn)品移植或升級時(shí)，或?qū)σ延挟a(chǎn)品原型進(jìn)行客戶化工作時(shí)，原型模型是非常適合的2.3快速原型模型的適用范圍2.1軟件生命周期的基本任務(wù)2.2瀑布模型2.3快速原型模型2.4增量模型2.5螺旋模型2.6噴泉模型2.7Rational統(tǒng)一過程2.8敏捷過程與極限編程2.9能力成熟度模型第二章：軟件過程增量模型也稱為漸增模型，如圖2.4所示。使用增量模型開發(fā)軟件時(shí)，把軟件產(chǎn)品作為一系列的增量構(gòu)件來設(shè)計(jì)、編碼、集成和測試。每個(gè)構(gòu)件由多個(gè)相互作用的模塊構(gòu)成，并且能夠完成特定的功能。2.4增量模型2.4增量模型圖2.4增量模型增量模型分批地逐步向用戶提交產(chǎn)品，每次提交一個(gè)滿足用戶需求子集的可運(yùn)行的產(chǎn)品。整個(gè)軟件產(chǎn)品被分解成許多個(gè)增量構(gòu)件，開發(fā)人員一個(gè)構(gòu)件接一個(gè)構(gòu)件地向用戶提交產(chǎn)品。每次用戶都得到一個(gè)滿足部分需求的可運(yùn)行的產(chǎn)品，直到最后一次得到滿足全部需求的完整產(chǎn)品。2.4增量模型難點(diǎn)：把每個(gè)新的增量構(gòu)件集成到現(xiàn)有軟件體系結(jié)構(gòu)中時(shí)，必須不破壞原來已經(jīng)開發(fā)出的產(chǎn)品。此外，必須把軟件的體系結(jié)構(gòu)設(shè)計(jì)得便于按這種方式進(jìn)行擴(kuò)充，向現(xiàn)有產(chǎn)品中加入新構(gòu)件的過程必須簡單、方便。2.4增量模型從某種意義上說，增量模型本身是自相矛盾的。它一方面要求開發(fā)人員把軟件看做一個(gè)整體，另一方面又要求開發(fā)人員把軟件看做構(gòu)件序列，每個(gè)構(gòu)件本質(zhì)上都獨(dú)立于另一個(gè)構(gòu)件。除非開發(fā)人員有足夠的技術(shù)能力協(xié)調(diào)好這一明顯的矛盾，否則用增量模型開發(fā)出的產(chǎn)品可能并不令人滿意。2.4增量模型（1）進(jìn)行已有產(chǎn)品升級或新版本開發(fā)，增量模型是非常適合的；（2）對完成期限嚴(yán)格要求的產(chǎn)品，可以使用增量模型；（3）對所開發(fā)的領(lǐng)域比較熟悉而且已有原型系統(tǒng)，增量模型也是非常適合的。2.4增量模型的適用范圍2.1軟件生命周期的基本任務(wù)2.2瀑布模型2.3快速原型模型2.4增量模型2.5螺旋模型2.6噴泉模型2.7Rational統(tǒng)一過程2.8敏捷過程與極限編程2.9能力成熟度模型第二章軟件過程使用原型及其他方法來盡量降低風(fēng)險(xiǎn)。理解這種模型的一個(gè)簡便方法，是把它看做在每個(gè)階段之前都增加了風(fēng)險(xiǎn)分析過程的快速原型模型，如圖2.5所示。圖中帶箭頭的點(diǎn)畫線的長度代表當(dāng)前累計(jì)的開發(fā)費(fèi)用，螺線旋過的角度值代表開發(fā)進(jìn)度。基本思想2.5螺旋模型圖2.5螺旋模型設(shè)計(jì)上的靈活性，可以在項(xiàng)目的各個(gè)階段進(jìn)行變更；以小的分段來構(gòu)建大型系統(tǒng)，使成本計(jì)算變得簡單容易；客戶始終參與每個(gè)階段的開發(fā)，保證了項(xiàng)目不偏離正確方向以及項(xiàng)目的可控性；隨著項(xiàng)目推進(jìn)，客戶始終掌握項(xiàng)目的最新信息，

從而能夠和管理層有效地交互。優(yōu)點(diǎn)（1）采用螺旋模型需要具有相當(dāng)豐富的風(fēng)險(xiǎn)評估經(jīng)驗(yàn)和專門知識，在風(fēng)險(xiǎn)較大的項(xiàng)目開發(fā)中，如果未能夠及時(shí)標(biāo)識風(fēng)險(xiǎn)，勢必造成重大損失；（2）過多的迭代次數(shù)會增加開發(fā)成本，延遲提交時(shí)間。缺點(diǎn)螺旋模型主要適用于內(nèi)部開發(fā)的大規(guī)模軟件項(xiàng)目。如果進(jìn)行風(fēng)險(xiǎn)分析的費(fèi)用接近整個(gè)項(xiàng)目的經(jīng)費(fèi)預(yù)算，則風(fēng)險(xiǎn)分析是不可行的。事實(shí)上，項(xiàng)目越大，風(fēng)險(xiǎn)也越大，因此，進(jìn)行風(fēng)險(xiǎn)分析的必要性也越大。螺旋模型的主要優(yōu)勢在于，它是風(fēng)險(xiǎn)驅(qū)動的，但是，這也可能是它的一個(gè)弱點(diǎn)。2.5螺旋模型2.1軟件生命周期的基本任務(wù)2.2瀑布模型2.3快速原型模型2.4增量模型2.5螺旋模型2.6噴泉模型2.7Rational統(tǒng)一過程2.8敏捷過程與極限編程2.9能力成熟度模型第二章：軟件過程迭代是軟件開發(fā)過程中普遍存在的一種內(nèi)在屬性。經(jīng)驗(yàn)表明，軟件過程各個(gè)階段之間的迭代或一個(gè)階段內(nèi)各個(gè)工作步驟之間的迭代，在面向?qū)ο蠓缎椭斜仍诮Y(jié)構(gòu)化范型中更常見。圖2.6所示的噴泉模型是典型的面向?qū)ο笊芷谀Ｐ??！皣娙边@個(gè)詞體現(xiàn)了面向?qū)ο筌浖_發(fā)過程迭代和無縫的特性。2.6噴泉模型2.6噴泉模型圖2.6噴泉模型為避免使用噴泉模型開發(fā)軟件時(shí)開發(fā)過程過分無序，應(yīng)該把一個(gè)線性過程（例如，快速原型模型或螺旋模型中的中心垂線）作為總目標(biāo)。但是，同時(shí)也應(yīng)該記住，面向?qū)ο蠓缎捅旧硪蠼?jīng)常對開發(fā)活動進(jìn)行迭代或求精。2.6噴泉模型噴泉模型不像瀑布模型那樣，需要分析活動結(jié)束后才開始設(shè)計(jì)活動，設(shè)計(jì)活動結(jié)束后才開始編碼活動。該模型的各個(gè)階段沒有明顯的界限，開發(fā)人員可以同步進(jìn)行開發(fā)。優(yōu)點(diǎn)其優(yōu)點(diǎn)是可以提高軟件項(xiàng)目開發(fā)效率，節(jié)省開發(fā)時(shí)間，適應(yīng)于面向?qū)ο蟮能浖_發(fā)過程?？梢詮娜魏我粋€(gè)階段（圓圈）轉(zhuǎn)到其它一個(gè)階段。即，在整個(gè)過程中補(bǔ)漏、拾遺、糾錯(cuò)的切入點(diǎn)大大增多，受到的階段性的限制較少。優(yōu)點(diǎn)由于噴泉模型在各個(gè)開發(fā)階段是重疊的，因此在開發(fā)過程中需要大量的開發(fā)人員，因此不利于項(xiàng)目的管理。噴泉模型要求嚴(yán)格管理文檔，使得審核的難度加大，尤其是面對可能隨時(shí)加入各種信息、需求與資料的情況。缺點(diǎn)2.1軟件生命周期的基本任務(wù)2.2瀑布模型2.3快速原型模型2.4增量模型2.5螺旋模型2.6噴泉模型2.7Rational統(tǒng)一過程2.8敏捷過程與極限編程2.9能力成熟度模型第二章：軟件過程Rational統(tǒng)一過程（rationalunifiedprocess，RUP）是由Rational軟件公司（已被IBM并購）推出的一個(gè)軟件開發(fā)過程框架。所謂軟件開發(fā)過程框架是指團(tuán)隊(duì)可以根據(jù)具體的項(xiàng)目組或軟件開發(fā)企業(yè)的不同需求，能夠定義、配置、定制和實(shí)施一致的軟件開發(fā)過程。2.7Rational統(tǒng)一過程1.用于成功開發(fā)軟件的一組基本觀念和原則。2.一套關(guān)于可重用方法內(nèi)容和過程構(gòu)建的框架。3.基礎(chǔ)的方法和過程定義語言。RUP核心元素2.7.1最佳實(shí)踐1.迭代式開發(fā)：迭代式開發(fā)允許在每次迭代過程中需求發(fā)生變化，這種開發(fā)方法通過一系列細(xì)化來加深對問題的理解，因此能更容易地容納需求的變更。也可以把軟件開發(fā)過程看做是一個(gè)風(fēng)險(xiǎn)管理過程，迭代式開發(fā)通過采用可驗(yàn)證的方法來減少風(fēng)險(xiǎn)。圖2.7迭代式開發(fā)2.管理需求：在開發(fā)軟件的過程中，客戶需求將不斷地發(fā)生變化，因此，確定系統(tǒng)的需求是一個(gè)連續(xù)的過程。RUP描述了如何提取、組織系統(tǒng)的功能性需求和約束條件并把它們文檔化。RUP采用用例分析來捕獲需求，并由它們驅(qū)動設(shè)計(jì)和實(shí)現(xiàn)。2.7.1最佳實(shí)踐3.使用基于組件的架構(gòu)：所謂組件就是功能清晰的模塊或子系統(tǒng)。系統(tǒng)可以由已經(jīng)存在的、由第三方開發(fā)商提供的組件構(gòu)成，因此組件使軟件重用成為可能。RUP提供了使用現(xiàn)有的或新開發(fā)的組件定義架構(gòu)的系統(tǒng)化方法，從而有助于降低軟件開發(fā)的復(fù)雜性，提高軟件重用率。2.7.1最佳實(shí)踐4.可視化建模：RUP與可視化的統(tǒng)一建模語言（UnifiedModelingLanguage，UML）緊密地聯(lián)系在一起，在開發(fā)過程中建立起軟件系統(tǒng)的可視化模型，可以幫助人們提高管理軟件復(fù)雜性的能力。2.7.1最佳實(shí)踐5.驗(yàn)證軟件質(zhì)量：某些軟件不受用戶歡迎的一個(gè)重要原因，是其質(zhì)量低下。在軟件投入運(yùn)行后再去查找和修改出現(xiàn)的問題，比在開發(fā)的早期階段就進(jìn)行這項(xiàng)工作需要花費(fèi)更多的人力和時(shí)間。在RUP中，軟件質(zhì)量評估不再是一種事后的行為或由單獨(dú)小組進(jìn)行的孤立活動，而是內(nèi)建在貫穿于整個(gè)開發(fā)過程的、由全體成員參與的所有活動中。2.7.1最佳實(shí)踐6.控制軟件變更：在變更是不可避免的環(huán)境中，必須具有管理變更的能力，才能確保每個(gè)修改都是可接受的而且能被跟蹤的。RUP描述了如何控制、跟蹤和監(jiān)控修改，以確保迭代開發(fā)的成功。2.7.1最佳實(shí)踐（1）前景：制定前景

有一個(gè)清晰的前景是開發(fā)一個(gè)滿足項(xiàng)目干系人（stakeholder）需求的產(chǎn)品的關(guān)鍵。前景（vision）給更詳細(xì)的技術(shù)需求提供了一個(gè)高層的、有時(shí)候是合同式的基礎(chǔ)。前景的內(nèi)容將回答以下問題：

關(guān)鍵術(shù)語是什么？（詞匯表）2.7.2RUP的十大要素

我們要嘗試解決什么問題？（問題聲明）

誰是項(xiàng)目干系人？誰是用戶？他們的需要是什么？

產(chǎn)品的特性是什么？

功能性需求是什么？（用例）

非功能性需求是什么？

設(shè)計(jì)約束是什么？2.7.2RUP的十大要素（2）計(jì)劃：按計(jì)劃管理

在RUP中，軟件開發(fā)計(jì)劃（softwaredevelopmentplan，SDP）綜合了管理項(xiàng)目所需的各種信息，也許會包括一些在先啟階段開發(fā)的單獨(dú)的內(nèi)容。SDP必須在整個(gè)項(xiàng)目中被維護(hù)和更新。2.7.2RUP的十大要素（3）風(fēng)險(xiǎn)：降低風(fēng)險(xiǎn)并跟蹤相關(guān)問題RUP的要點(diǎn)之一是在項(xiàng)目早期就標(biāo)識并處理最大的風(fēng)險(xiǎn)。項(xiàng)目組標(biāo)識的每一個(gè)風(fēng)險(xiǎn)都應(yīng)該有一個(gè)相應(yīng)的緩解或解決計(jì)劃。風(fēng)險(xiǎn)列表應(yīng)該既作為項(xiàng)目活動的計(jì)劃工具，又作為組織迭代的基礎(chǔ)。2.7.2RUP的十大要素（4）業(yè)務(wù)案例：檢驗(yàn)業(yè)務(wù)案例

業(yè)務(wù)案例主要用于為實(shí)現(xiàn)項(xiàng)目前景而制定經(jīng)濟(jì)計(jì)劃。一旦制定之后，業(yè)務(wù)案例就用來對項(xiàng)目提供的投資收益率（ROI）進(jìn)行精確的評估。

業(yè)務(wù)案例的描述不應(yīng)深挖問題的細(xì)節(jié)，而應(yīng)就為什么需要該產(chǎn)品樹立一個(gè)有說服力的論點(diǎn)。2.7.2RUP的十大要素（5）架構(gòu)：設(shè)計(jì)組件架構(gòu)

在RUP中，軟件系統(tǒng)的架構(gòu)是指一個(gè)系統(tǒng)關(guān)鍵部件的組織或結(jié)構(gòu)，組件之間通過接口交互，而組件是由一些更小的組件和接口組成的。架構(gòu)由軟件架構(gòu)文檔通過多個(gè)視圖表示，每個(gè)視圖都描述了某一組項(xiàng)目干系人所關(guān)心的系統(tǒng)的某個(gè)方面2.7.2RUP的十大要素（6）原型：增量地構(gòu)建和測試產(chǎn)品RUP是為了盡早排除問題和解決風(fēng)險(xiǎn)和問題而構(gòu)建、測試和評估產(chǎn)品的可執(zhí)行版本的一種迭代方法。遞增地構(gòu)造和測試系統(tǒng)的組件，這是實(shí)施和測試規(guī)程及原則通過迭代證明價(jià)值的“要素”。2.7.2RUP的十大要素（7）評估：定期評估結(jié)果

顧名思義，RUP的迭代評估審查了迭代的結(jié)果。評估得出了迭代滿足需求規(guī)范的程度，同時(shí)還包括學(xué)到的教訓(xùn)和實(shí)施的過程改進(jìn)。根據(jù)項(xiàng)目的規(guī)模、風(fēng)險(xiǎn)以及迭代的特點(diǎn)，評估可以是對演示及其結(jié)果的一條簡單的記錄，也可能是一個(gè)完整的、正式的測試評審記錄。2.7.2RUP的十大要素（8）變更請求：管理并控制變更RUP的配置和變更管理流程的要點(diǎn)是當(dāng)變化發(fā)生時(shí)管理和控制項(xiàng)目的規(guī)模，并且貫穿整個(gè)生命周期。在RUP中，變更請求通常用于記錄和跟蹤缺陷和增強(qiáng)功能的要求，或者對產(chǎn)品提出的任何其他類型的變更請求。2.7.2RUP的十大要素（9）用戶支持：部署可用的產(chǎn)品

在RUP中，部署流程的要點(diǎn)是包裝和交付產(chǎn)品，同時(shí)交付有助于最終用戶學(xué)習(xí)、使用和維護(hù)產(chǎn)品的所有必要的材料。項(xiàng)目組至少要給用戶提供一個(gè)用戶指南（也許是通過聯(lián)機(jī)幫助的方式提供），可能還有一個(gè)安裝指南和版本發(fā)布說明。2.7.2RUP的十大要素（10）過程：采用適合項(xiàng)目的過程

選擇適合正開發(fā)的產(chǎn)品類型的流程是非常必要的。即使在選定一個(gè)流程后，也不能盲目遵循這個(gè)流程——必須應(yīng)用常理和經(jīng)驗(yàn)來配置流程和工具，以滿足組織和項(xiàng)目的需要。2.7.2RUP的十大要素2.7.3RUP生命周期圖2.8方法內(nèi)容定義與方法內(nèi)容在流程中的應(yīng)用業(yè)務(wù)建模：深入了解使用目標(biāo)系統(tǒng)的機(jī)構(gòu)及其商業(yè)運(yùn)作，評估目標(biāo)系統(tǒng)對使用它的機(jī)構(gòu)的影響。需求：捕獲客戶的需求，并且使開發(fā)人員和用戶達(dá)成對需求描述的共識。分析與設(shè)計(jì)：把需求分析的結(jié)果轉(zhuǎn)化成分析模型與設(shè)計(jì)模型。（1）核心流程實(shí)現(xiàn)：把設(shè)計(jì)模型轉(zhuǎn)換成實(shí)現(xiàn)結(jié)果（形式化地定義代碼結(jié)構(gòu)；用構(gòu)件實(shí)現(xiàn)類和對象；對開發(fā)出的構(gòu)件進(jìn)行單元測試；把不同實(shí)現(xiàn)人員開發(fā)出的模塊集成為可執(zhí)行的系統(tǒng)）。測試：檢查各個(gè)子系統(tǒng)的交互與集成，驗(yàn)證所有需求是否都被正確地實(shí)現(xiàn)了，識別、確認(rèn)缺陷并確保在軟件部署之前消除缺陷。（1）核心流程部署：成功地生成目標(biāo)系統(tǒng)的可運(yùn)行的版本，并把軟件移交給最終用戶。配置與變更管理：跟蹤并維護(hù)在軟件開發(fā)過程中產(chǎn)生的所有制品的完整性和一致性。項(xiàng)目管理：提供項(xiàng)目管理框架，為軟件開發(fā)項(xiàng)目制定計(jì)劃、人員配備、執(zhí)行和監(jiān)控等方面的實(shí)用準(zhǔn)則，并為風(fēng)險(xiǎn)管理提供框架。（1）核心流程環(huán)境：向軟件開發(fā)機(jī)構(gòu)提供軟件開發(fā)環(huán)境，包括過程管理和工具支持。（1）核心流程先啟階段：建立業(yè)務(wù)模型，定義最終產(chǎn)品視圖，并且確定項(xiàng)目的范圍。精化階段：設(shè)計(jì)并確定系統(tǒng)的體系結(jié)構(gòu)，制定項(xiàng)目計(jì)劃，確定資源需求。構(gòu)建階段：開發(fā)出所有構(gòu)件和應(yīng)用程序，把它們集成為客戶需要的產(chǎn)品，并且詳盡地測試所有功能。移交階段：把開發(fā)出的產(chǎn)品提交給用戶使用。（2）工作階段（2）工作階段圖2.9項(xiàng)目的階段和里程碑RUP強(qiáng)調(diào)采用迭代和漸增的方式來開發(fā)軟件，整個(gè)項(xiàng)目開發(fā)過程由多個(gè)迭代過程組成。事實(shí)上，RUP重復(fù)一系列組成軟件生命周期的循環(huán)。每個(gè)階段又進(jìn)一步細(xì)分為一次或多次迭代過程。（3）RUP迭代式開發(fā)2.1軟件生命周期的基本任務(wù)2.2瀑布模型2.3快速原型模型2.4增量模型2.5螺旋模型2.6噴泉模型2.7Rational統(tǒng)一過程2.8敏捷過程與極限編程2.9能力成熟度模型第二章：軟件過程（1）“個(gè)體和交互”勝過“過程和工具”

優(yōu)秀的團(tuán)隊(duì)成員是軟件開發(fā)項(xiàng)目獲得成功的最重要因素，但不好的過程和工具也會使最優(yōu)秀的團(tuán)隊(duì)成員無法發(fā)揮作用。團(tuán)隊(duì)成員的合作、溝通以及交互能力要比單純的軟件編程能力更為重要2.8.1敏捷過程概述（2）“可以使用的軟件”勝過“面面俱到的文檔”

軟件開發(fā)的主要目標(biāo)是向用戶提供可以使用的軟件而不是文檔，但是，完全沒有文檔的軟件也是一種災(zāi)難。開發(fā)人員應(yīng)該把主要精力放在創(chuàng)建可使用的軟件上面，僅當(dāng)迫切需要并且具有重大意義時(shí)，才進(jìn)行文檔編制工作，而且所編織的內(nèi)部文檔應(yīng)該盡量簡明扼要和主題突出。2.8.1敏捷過程概述（3）“客戶合作”勝過“合同談判”

客戶通常不可能做到一次性地把他們的需求完整準(zhǔn)確地表述在合同中。能夠滿足客戶不斷變化的需求的切實(shí)可行的途徑是：開發(fā)團(tuán)隊(duì)與客戶密切協(xié)作。因此，能指導(dǎo)開發(fā)團(tuán)隊(duì)與客戶協(xié)同工作的合同才是最好的合同。2.8.1敏捷過程概述（4）“響應(yīng)變化”勝過“遵循計(jì)劃”

軟件開發(fā)過程總會有變化，這是客觀存在的現(xiàn)實(shí)。一個(gè)軟件過程必須反映現(xiàn)實(shí)，因此，軟件過程應(yīng)該有足夠的能力及時(shí)響應(yīng)變化。然而沒有計(jì)劃的項(xiàng)目也會因陷入混亂而失敗，關(guān)鍵是計(jì)劃必須有足夠的靈活性和可塑性，在形勢發(fā)生變化時(shí)能迅速調(diào)整，以適應(yīng)業(yè)務(wù)、技術(shù)等方面的變化。2.8.1敏捷過程概述1.最重要的是通過盡早和持續(xù)地交付有價(jià)值的軟件以滿足客戶需要。2.即使在開發(fā)后期也歡迎需求的變化。敏捷過程駕馭變化帶給客戶競爭優(yōu)勢。3.經(jīng)常交付可以使用的軟件，間隔可以從幾星期到幾個(gè)月，時(shí)間尺度越短越好。4.業(yè)務(wù)人員和開發(fā)人員應(yīng)該在整個(gè)項(xiàng)目過程中每天都在一起工作?！懊艚菪浴钡脑瓌t5.使用積極的開發(fā)人員進(jìn)行項(xiàng)目，給他們提供所需環(huán)境和支持，并信任他們能夠完成任務(wù)。6.在開發(fā)小組中最有效率和效果的信息傳達(dá)方式是面對面的交談。7.可以使用的軟件是度量進(jìn)度的主要標(biāo)準(zhǔn)。8.敏捷過程提倡的是持續(xù)開發(fā)過程。投資“敏捷宣言”的原則人、開發(fā)人員和用戶應(yīng)該維持一個(gè)長期穩(wěn)定的步調(diào)。9.持續(xù)地追求卓越的技術(shù)與良好的設(shè)計(jì)會增加敏捷性。10.簡單（盡可能減少工作量）是最重要的。11.最好的架構(gòu)、需求和設(shè)計(jì)都來自于自組織的團(tuán)隊(duì)。

“敏捷宣言”的原則12.團(tuán)隊(duì)要定期總結(jié)如何提高效率，然后相應(yīng)地調(diào)整自己的行為。根據(jù)上述價(jià)值觀提出的軟件過程統(tǒng)稱為敏捷過程，其中應(yīng)用比較廣泛的是極限編程和Scrum?！懊艚菪浴钡脑瓌t極限編程（extremeprogramming）是敏捷過程中最負(fù)盛名的一個(gè)，其名稱中“極限”二字的含義是指把好的開發(fā)實(shí)踐運(yùn)用到極致。目前，極限編程已經(jīng)成為一個(gè)典型的開發(fā)方法，廣泛應(yīng)用于需求模糊且經(jīng)常改變的場合。2.8.2極限編程

客戶作為開發(fā)團(tuán)隊(duì)的成員

使用用戶素材

短交付周期

驗(yàn)收測試

結(jié)對編程

測試驅(qū)動開發(fā)

集體所有1．極限編程的有效實(shí)踐

持續(xù)集成

可持續(xù)的開發(fā)速度

開放的工作空間

及時(shí)調(diào)整計(jì)劃

簡單的設(shè)計(jì)

重構(gòu)

使用隱喻1．極限編程的有效實(shí)踐

必須至少有一名客戶代表在項(xiàng)目的整個(gè)開發(fā)周期中與開發(fā)人員在一起緊密地配合工作，客戶代表負(fù)責(zé)確定需求、回答開發(fā)人員的問題并且設(shè)計(jì)功能驗(yàn)收測試方案?？蛻糇鳛殚_發(fā)團(tuán)隊(duì)的成員

所謂用戶素材就是正在進(jìn)行的關(guān)于需求的談話內(nèi)容的助記符。根據(jù)用戶素材可以合理地安排實(shí)現(xiàn)該項(xiàng)需求的時(shí)間。使用用戶素材

每兩周完成一次的迭代過程實(shí)現(xiàn)了用戶的一些需求，交付出目標(biāo)系統(tǒng)的一個(gè)可工作的版本。通過向有關(guān)的用戶演示迭代生成的系統(tǒng)，獲得他們的反饋意見。短交付周期

通過執(zhí)行由客戶制定的驗(yàn)收測試來捕獲用戶素材的細(xì)節(jié)。驗(yàn)收測試

結(jié)對編程就是由兩名開發(fā)人員在同一臺計(jì)算機(jī)上共同編寫解決同一個(gè)問題的程序代碼，通常一個(gè)人編碼，另一個(gè)人對代碼進(jìn)行審查與測試，以保證代碼的正確性與可讀性。結(jié)對編程是加強(qiáng)開發(fā)人員相互溝通與評審的一種方式。結(jié)對編程

極限編程強(qiáng)調(diào)“測試先行”。在編碼之前應(yīng)該首先設(shè)計(jì)好測試方案，然后再編程，直至所有測試都獲得通過之后才可以結(jié)束工作。測試驅(qū)動開發(fā)

極限編程強(qiáng)調(diào)程序代碼屬于整個(gè)開發(fā)小組集體所有，小組每個(gè)成員都有更改代碼的權(quán)利，每個(gè)成員都對全部代碼的質(zhì)量負(fù)責(zé)。集體所有

極限編程主張?jiān)谝惶熘畠?nèi)多次集成系統(tǒng)，而且隨著需求的變更，應(yīng)該不斷地進(jìn)行回歸測試。持續(xù)集成

開發(fā)人員以能夠長期維持的速度努力工作。XP（extremeprogramming）規(guī)定開發(fā)人員每周工作時(shí)間不超過40h，連續(xù)加班不可以超過兩周，以免降低生產(chǎn)率?？沙掷m(xù)的開發(fā)速度XP項(xiàng)目的全體參與者（開發(fā)人員、客戶等）一起在一個(gè)開放的場所中工作，項(xiàng)目組成員在這個(gè)場所中自由地交流和討論。開放的工作空間

計(jì)劃應(yīng)該是靈活的、循序漸進(jìn)的。制訂出項(xiàng)目計(jì)劃之后，必須根據(jù)項(xiàng)目進(jìn)展情況及時(shí)進(jìn)行調(diào)整，沒有一成不變的計(jì)劃。及時(shí)調(diào)整計(jì)劃

開發(fā)人員應(yīng)該使設(shè)計(jì)與計(jì)劃要在本次迭代過程中完成的用戶素材完全匹配，設(shè)計(jì)時(shí)不需要考慮未來的用戶素材。在一次次的迭代過程中，項(xiàng)目組成員不斷變更系統(tǒng)設(shè)計(jì)，使之相對于正在實(shí)現(xiàn)的用戶素材而言始終處于最優(yōu)狀態(tài)。簡單的設(shè)計(jì)

所謂代碼重構(gòu)就是在不改變系統(tǒng)行為的前提下，重新調(diào)整和優(yōu)化系統(tǒng)的內(nèi)部結(jié)構(gòu)，以降低復(fù)雜性、消除冗余、增加靈活性和提高性能。應(yīng)該注意的是，在開發(fā)過程中不要過分依賴重構(gòu)，特別是不能輕視設(shè)計(jì)，對于大中型系統(tǒng)而言，如果推遲設(shè)計(jì)或者干脆不做設(shè)計(jì)，將造成一場災(zāi)難。重構(gòu)

可以將隱喻看做是把整個(gè)系統(tǒng)聯(lián)系在一起的全局視圖，它描述系統(tǒng)如何運(yùn)作，以及用何種方式把新功能加入到系統(tǒng)中。使用隱喻首先，項(xiàng)目組針對客戶代表提出的“用戶故事”然后，項(xiàng)目組在隱喻和用戶故事的基礎(chǔ)上，根據(jù)客戶設(shè)定的優(yōu)先級制訂交付計(jì)劃最后，開始多個(gè)迭代過程，在迭代期內(nèi)產(chǎn)生的新用戶故事不在本次迭代內(nèi)解決，以保證本次開發(fā)過程不受干擾。2．極限編程的整體開發(fā)過程2．極限編程的整體開發(fā)過程圖2.10極限編程的整體開發(fā)過程3．極限編程的迭代過程圖2.11極限編程的迭代過程

以極限編程為杰出代表的敏捷過程，可以快速、敏捷地響應(yīng)變化和不確定的需求，同時(shí)仍然能夠保持可持續(xù)的開發(fā)速度。上述這些特點(diǎn)使得敏捷過程能夠較好地適應(yīng)商業(yè)競爭環(huán)境下對項(xiàng)目提出的有限資源和有限開發(fā)時(shí)間的約束。3．極限編程的迭代過程2.1軟件生命周期的基本任務(wù)2.2瀑布模型2.3快速原型模型2.4增量模型2.5螺旋模型2.6噴泉模型2.7Rational統(tǒng)一過程2.8敏捷過程與極限編程2.9能力成熟度模型第二章：軟件過程能力成熟度模型（capabilitymaturitymodel，CMM）并不是一個(gè)軟件生命周期模型，而是改進(jìn)軟件過程的一種策略，它與實(shí)際使用的過程模型無關(guān)。1986年美國卡內(nèi)基—梅隆大學(xué)軟件工程研究所首次提出能力成熟度模型（CMM），不過在當(dāng)時(shí)它被稱為過程成熟度模型。2.9能力成熟度模型問題是由管理軟件過程的方法不當(dāng)引起的，所以新軟件技術(shù)的運(yùn)用并不會自動提高生產(chǎn)率和軟件質(zhì)量。能力成熟度模型有助于軟件開發(fā)組織建立一個(gè)有規(guī)律的、成熟的軟件過程。改進(jìn)后的過程將開發(fā)出質(zhì)量更好的軟件，使更多的軟件項(xiàng)目免受時(shí)間和費(fèi)用超支之苦?；舅枷?.成熟度等級（maturitylevels）：一個(gè)成熟度等級是在朝著實(shí)現(xiàn)成熟軟件過程進(jìn)化途中的一個(gè)妥善定義的平臺。5個(gè)成熟度等級構(gòu)成了CMM的頂層結(jié)構(gòu)。2.過程能力（processcapability）：軟件過程能力描述，通過遵循軟件過程能實(shí)現(xiàn)預(yù)期結(jié)果的程度。2.9.1能力成熟度模型的結(jié)構(gòu)3.關(guān)鍵過程域（keyprocessareas，KPA）：每個(gè)成熟度等級由若干關(guān)鍵過程域組成。每個(gè)關(guān)鍵過程域都標(biāo)識出一串相關(guān)的活動，當(dāng)把這些活動都完成時(shí)所達(dá)到的一組目標(biāo)，對建立該過程成熟度等級是至關(guān)重要的。2.9.1能力成熟度模型的結(jié)構(gòu)4.目標(biāo)（goals）：目標(biāo)概括了關(guān)鍵過程域中的關(guān)鍵實(shí)踐，并可用于確定一個(gè)組織或項(xiàng)目是否已有效地實(shí)施了該關(guān)鍵過程域。5.公共特性（commonfeatures）：CMM把關(guān)鍵實(shí)踐分別歸入下列5個(gè)公共特性之中：執(zhí)行約定、執(zhí)行能力、執(zhí)行的活動、測量和分析以及驗(yàn)證實(shí)施。2.9.1能力成熟度模型的結(jié)構(gòu)6.關(guān)鍵實(shí)踐（keypractices）：每個(gè)關(guān)鍵過程域都用若干關(guān)鍵實(shí)踐描述，實(shí)施關(guān)鍵實(shí)踐有助于實(shí)現(xiàn)相應(yīng)的關(guān)鍵過程域的目標(biāo)。2.9.1能力成熟度模型的結(jié)構(gòu)2.9.1能力成熟度模型的結(jié)構(gòu)圖2.12CMM結(jié)構(gòu)1．初始級

軟件過程的特征是無序的，有時(shí)甚至是混亂的。幾乎沒有什么過程是經(jīng)過定義的，項(xiàng)目能否成功完全取決于個(gè)人能力。

處于這個(gè)最低成熟度等級的組織，基本上沒有健全的軟件工程管理制度。每件事情都以特殊的方法來做。2.9.2能力成熟度等級2．可重復(fù)級

建立了基本的項(xiàng)目管理過程，以追蹤成本、進(jìn)度和功能性。必要的過程規(guī)范已經(jīng)建立起來了，使得可以重復(fù)以前類似項(xiàng)目所取得的成功。2.9.2能力成熟度等級3．已定義級

用于管理和工程活動的軟件過程已經(jīng)文檔化和標(biāo)準(zhǔn)化，并且已經(jīng)集成到整個(gè)組織的軟件過程中。所有項(xiàng)目都使用文檔化的、組織批準(zhǔn)的過程來開發(fā)和維護(hù)軟件。這一級包含了第2級的所有特征。2.9.2能力成熟度等級4．已管理級

已收集了軟件過程和產(chǎn)品質(zhì)量的詳細(xì)度量數(shù)據(jù)，使用這些詳細(xì)的度量數(shù)據(jù)，能夠定量地理解和控制軟件過程和產(chǎn)品。這一級包含了第3級的所有特征。2.9.2能力成熟度等級5．優(yōu)化級

通過定量的反饋能夠?qū)崿F(xiàn)持續(xù)的過程改進(jìn)，這些反饋是從過程及對新想法和技術(shù)的測試中獲得的。這一級包含了第4級的所有特征。2.9.2能力成熟度等級能力成熟度模型并不詳細(xì)描述所有與軟件開發(fā)和維護(hù)有關(guān)的過程，但是，有一些過程是決定過程能力的關(guān)鍵因素，這就是CMM所稱的關(guān)鍵過程域。關(guān)鍵過程域是達(dá)到一個(gè)成熟度等級的必要條件。除第1級成熟度之外，每個(gè)成熟度等級都指明了為改進(jìn)其軟件過程，軟件開發(fā)組織應(yīng)該重視的區(qū)域，同時(shí)也指明了為達(dá)到某個(gè)成熟度等級所必須解決的問題。2.9.3關(guān)鍵過程域（a）軟件配置管理。（b）軟件質(zhì)量保證。（c）軟件子合同管理。（d）軟件項(xiàng)目跟蹤和監(jiān)督軟件。（e）項(xiàng)目計(jì)劃。（f）需求管理。1．成熟度第2級（a）同事復(fù)審。（b）組間協(xié)作。（c）軟件產(chǎn)品工程。（d）集成的軟件管理。（e）培訓(xùn)計(jì)劃。（f）組織過程定義。（g）組織過程焦點(diǎn)。2．成熟度第3級（a）軟件質(zhì)量管理。（b）定量的過程管理。3．成熟度第4