第2章軟件過程

1、第二章 軟件過程2.1 軟件過程概述軟件工程框架軟件工程框架可可用用性性性性性性確確正正合合算算選取適宜的開發(fā)范型選取適宜的開發(fā)范型采用合適的設(shè)計(jì)方法采用合適的設(shè)計(jì)方法提供高質(zhì)量的工程支持提供高質(zhì)量的工程支持重視軟件工程的管理重視軟件工程的管理基基本本過過程程支支持持過過程程組組織織過過程程目標(biāo)目標(biāo)過程過程原原則則軟件工程的層次軟件工程的層次 軟件工程是一門建立在以質(zhì)量焦點(diǎn)為基礎(chǔ)，分過程、方法和工具三個研究層次的綜合技術(shù)。 軟件工程的基層是過程層，它是將方法和技術(shù)結(jié)合在一起的凝聚層，使得軟件能合理地、及時地開發(fā)處理 方法層提供了軟件開發(fā)過程中技術(shù)上的支持。包括建?；顒雍推渌枋黾夹g(shù)等。 工具是

2、對軟件過程和方法提供自動和半自動的支持2.2軟件過程軟件生命周期軟件過程概念軟件生命周期模型 軟件生存周期v軟件從定義開始，經(jīng)過開發(fā)、使用和維護(hù)，軟件從定義開始，經(jīng)過開發(fā)、使用和維護(hù)， 直到最終退役的全過程稱為軟件生存周期。直到最終退役的全過程稱為軟件生存周期。v可將軟件生存周期劃分為可將軟件生存周期劃分為3個過程共個過程共9個階段。個階段。v3個過程是：軟件定義過程、軟件開發(fā)過程、個過程是：軟件定義過程、軟件開發(fā)過程、 軟件使用與維護(hù)過程。軟件使用與維護(hù)過程。v9個階段有：可行性研究、需求分析、概要設(shè)個階段有：可行性研究、需求分析、概要設(shè) 計(jì)、詳細(xì)設(shè)計(jì)、實(shí)現(xiàn)、組裝測試、計(jì)、詳細(xì)設(shè)計(jì)、實(shí)現(xiàn)、組

3、裝測試、 驗(yàn)收測試、使用與維護(hù)、退役驗(yàn)收測試、使用與維護(hù)、退役。 圖圖1-3-1 軟件生存周期階段的劃分軟件生存周期階段的劃分使用與維護(hù)驗(yàn)收測試組裝測試實(shí)現(xiàn)詳細(xì)設(shè)計(jì)概要設(shè)計(jì)需求分析退役開發(fā)過程使用與維護(hù)過程定義過程可行性研究軟件生存周期v各個階段所要完成的基本任務(wù)各個階段所要完成的基本任務(wù)問題定義與可行性研究問題定義與可行性研究 本階段要回答的關(guān)鍵問題是本階段要回答的關(guān)鍵問題是“到底要解決什么問題？在到底要解決什么問題？在成本和時間的限制條件下能否解決問題？是否值得做？成本和時間的限制條件下能否解決問題？是否值得做？” (2) (2) 需求分析需求分析 本階段要回答的關(guān)鍵問題是本階段要回答的關(guān)

4、鍵問題是“目標(biāo)系統(tǒng)應(yīng)當(dāng)做什么？目標(biāo)系統(tǒng)應(yīng)當(dāng)做什么？” (3) (3) 軟件設(shè)計(jì)軟件設(shè)計(jì) 設(shè)計(jì)是軟件工程的技術(shù)核心。本階段要回答的關(guān)鍵問題設(shè)計(jì)是軟件工程的技術(shù)核心。本階段要回答的關(guān)鍵問題是是“如何實(shí)現(xiàn)目標(biāo)系統(tǒng)？如何實(shí)現(xiàn)目標(biāo)系統(tǒng)？” 軟件生存周期v各個階段所要完成的基本任務(wù)各個階段所要完成的基本任務(wù)(4) (4) 程序編碼和單元測試程序編碼和單元測試 本階段要解決的問題是本階段要解決的問題是“正確地實(shí)現(xiàn)已做的設(shè)計(jì)正確地實(shí)現(xiàn)已做的設(shè)計(jì)”，即，即“如何編寫正確的、可維護(hù)的程序代碼？如何編寫正確的、可維護(hù)的程序代碼？” (5) (5) 集成和系統(tǒng)測試集成和系統(tǒng)測試 測試是控制軟件質(zhì)量的重要手段，本階段的

5、主要任務(wù)是做測試是控制軟件質(zhì)量的重要手段，本階段的主要任務(wù)是做集成測試和系統(tǒng)測試。集成測試和系統(tǒng)測試。 (6) (6) 軟件運(yùn)行和維護(hù)軟件運(yùn)行和維護(hù) 已交付的軟件投入正式使用，便進(jìn)入運(yùn)行階段。這一階段已交付的軟件投入正式使用，便進(jìn)入運(yùn)行階段。這一階段可能持續(xù)若干年。軟件在運(yùn)行中可能由于多方面的原因，可能持續(xù)若干年。軟件在運(yùn)行中可能由于多方面的原因，需要對它進(jìn)行修改。需要對它進(jìn)行修改。 軟件過程又稱為軟件生存周期過程，是軟件生存周期內(nèi)為達(dá)到一定目標(biāo)而必須實(shí)施的一系列相關(guān)過程的集合。它是圍繞軟件的活動序列，財(cái)務(wù)、市場等活動不屬于軟件過程。在傳統(tǒng)的軟件工程中，軟件產(chǎn)品的生存周期一般可以劃分為6個階段

6、，分別是：可行性研究需求分析 軟件設(shè)計(jì)編碼 軟件測試 軟件維護(hù) 軟件過程概念圖 1 5 傳統(tǒng)軟件生存周期的各個階段軟件過程標(biāo)準(zhǔn)圖 1 6 ISO12207軟件生存周期過程標(biāo)準(zhǔn)框架軟件生存周期模型 ISO12207標(biāo)準(zhǔn)將軟件生存周期模型定義為： 一個包括軟件產(chǎn)品開發(fā)、運(yùn)行和維護(hù)中有關(guān)過程、活動和任務(wù)的框架，其中這些過程、活動和任務(wù)覆蓋了從該系統(tǒng)的需求定義到系統(tǒng)的使用終止。 把這個概念應(yīng)用到開發(fā)過程中，可以發(fā)現(xiàn)所有軟件開發(fā)生存周期模型的內(nèi)在基本特征： 描述了開發(fā)的主要階段 定義了每一個階段要完成的主要過程和活動 規(guī)范了每一個階段的輸入和輸出（提交物） 提供了一個框架，可以把必要的活動映射到該框架中

7、軟件生命周期模型 常見的軟件生命周期模型包括： 瀑布模型 原型模型 增量模型 噴泉模型 螺旋模型 統(tǒng)一過程模型 敏捷過程模型 微軟工程模型瀑布模型在在2020世紀(jì)世紀(jì)8080年代之前，瀑年代之前，瀑布模型一直是唯一被廣泛布模型一直是唯一被廣泛采用的生命周期模型。采用的生命周期模型。傳統(tǒng)的瀑布模型如圖所示。傳統(tǒng)的瀑布模型如圖所示。 圖 1 7 瀑布模型實(shí)際的瀑布模型實(shí)際的瀑布模型實(shí)際的瀑布模型是帶實(shí)際的瀑布模型是帶“反饋環(huán)反饋環(huán)”的，如圖所的，如圖所示。示。 圖中實(shí)線箭頭表示開發(fā)圖中實(shí)線箭頭表示開發(fā)過程，虛線箭頭表示維過程，虛線箭頭表示維護(hù)過程。護(hù)過程。瀑布模型的優(yōu)點(diǎn)瀑布模型的優(yōu)點(diǎn)可強(qiáng)迫開發(fā)人員

8、采用規(guī)范化的方法?？蓮?qiáng)迫開發(fā)人員采用規(guī)范化的方法。嚴(yán)格地規(guī)定了每個階段必須提交的文檔。嚴(yán)格地規(guī)定了每個階段必須提交的文檔。要求每個階段交出的所有產(chǎn)品都必須是經(jīng)過驗(yàn)證要求每個階段交出的所有產(chǎn)品都必須是經(jīng)過驗(yàn)證的。的。瀑布模型的缺點(diǎn)瀑布模型的缺點(diǎn)由于瀑布模型幾乎完全依賴于書面的規(guī)格說明，很由于瀑布模型幾乎完全依賴于書面的規(guī)格說明，很可能導(dǎo)致最終開發(fā)出的軟件產(chǎn)品不能真正滿足用戶可能導(dǎo)致最終開發(fā)出的軟件產(chǎn)品不能真正滿足用戶的需要。如果需求規(guī)格說明與用戶需求之間有差異，的需要。如果需求規(guī)格說明與用戶需求之間有差異，就會發(fā)生這種情況。就會發(fā)生這種情況。瀑布模型只適用于項(xiàng)目開始時需求已確定的情況。瀑布模型只

9、適用于項(xiàng)目開始時需求已確定的情況。瀑布模型 瀑布模型的優(yōu)點(diǎn)是過程模型簡單，執(zhí)行容易；缺點(diǎn)是無法適應(yīng)變更。瀑布模型適應(yīng)于具有以下特征的軟件開發(fā)項(xiàng)目： 在軟件開發(fā)的過程中，需求不發(fā)生或發(fā)生很少變化，并且開發(fā)人員可以一次性獲取到全部需求。否則，由于瀑布模型較差的可回溯性，在后續(xù)階段中需求經(jīng)常性的變更需要付出高昂的代價。 軟件開發(fā)人員具有豐富的經(jīng)驗(yàn)，對軟件應(yīng)用領(lǐng)域很熟悉。 軟件項(xiàng)目的風(fēng)險(xiǎn)較低。瀑布模型不具有完善的風(fēng)險(xiǎn)控制機(jī)制。原型模型 原型模型主要用于挖掘需求，或是進(jìn)行某種技術(shù)或開發(fā)方法的可行性研究，是一種開發(fā)人員為了快速而準(zhǔn)確地獲取需求經(jīng)常采用的方法。 在初步獲取需求后，開發(fā)人員會快速地開發(fā)一個原型

10、系統(tǒng)。通過對原型系統(tǒng)進(jìn)行模擬操作，開發(fā)人員可以更直觀、更全面和更準(zhǔn)確地了解用戶對待開發(fā)系統(tǒng)的各項(xiàng)要求，同時還能挖掘到隱藏的需求。如果開發(fā)人員對將采用的開發(fā)技術(shù)把握不大，也可以采用原型模型進(jìn)行技術(shù)上的嘗試，以降低后續(xù)開發(fā)的風(fēng)險(xiǎn)。 原型系統(tǒng)通常針對軟件開發(fā)系統(tǒng)的子功能模塊，所以功能相對不完善。此外，由于原型系統(tǒng)功能的局部性以及存在階段的局部性，在軟件開發(fā)的實(shí)踐中，原型模型通常結(jié)合其他的軟件開發(fā)模型共同使用，發(fā)揮作用。原型模型圖 1 8 原型模型增量模型 圖 1 9 增量模型增量模型假設(shè)需求可以分段，成為一系列增量產(chǎn)品，每一增量增量模型假設(shè)需求可以分段，成為一系列增量產(chǎn)品，每一增量可以分別地開發(fā)。如

11、圖可以分別地開發(fā)。如圖1-9所示。所示。增量模型 增量模型作為瀑布模型的一個變體，具有瀑布模型的所有優(yōu)點(diǎn)，此外，它還有以下優(yōu)點(diǎn)： 第一個可交付版本所需要的成本和時間很少； 開發(fā)由增量表示的小系統(tǒng)所承擔(dān)的風(fēng)險(xiǎn)不大； 由于很快發(fā)布了第一個版本，因此可以減少用戶需求的變更； 允許增量投資，即在項(xiàng)目開始時，可以僅對一個或兩個增量投資。Company Logo增量模型 增量模型的不足為： 如果沒有對用戶的變更要求進(jìn)行規(guī)劃，那么產(chǎn)生的初始增量可能會造成后來增量的不穩(wěn)定； 如果需求不像早期思考的那樣穩(wěn)定和完整，那么一些增量就可能需要重新開發(fā)，重新發(fā)布； 管理發(fā)生的成本、進(jìn)度和配置的復(fù)雜性，可能會超出組織的能

12、力。增量模型 增量模型適用于以下特點(diǎn)的軟件項(xiàng)目。 軟件產(chǎn)品可以分批次地進(jìn)行交付。 待開發(fā)的軟件系統(tǒng)能夠被模塊化。 軟件開發(fā)人員對應(yīng)用領(lǐng)域不熟悉，難以一次性地進(jìn)行系統(tǒng)開發(fā)。 項(xiàng)目管理人員對全局把握的水平較高。噴泉模型 圖 1 10 演化模型 噴泉模型是典型的面向?qū)ο笊芷谀Ｐ汀?“噴泉”一詞體現(xiàn)了迭代和無間隙特性。圖中代表不同階段的圓圈相互重疊，這明確表示兩個活動之間存在重疊。 它是以面向?qū)ο蟮能浖_發(fā)方法為基礎(chǔ)，以用戶需求為動力，以對象來驅(qū)動的模型。維維 護(hù)護(hù)測測 試試實(shí)實(shí) 現(xiàn)現(xiàn)設(shè)設(shè) 計(jì)計(jì)分分 析析演演 化化螺旋模型 螺旋模型通常用來指導(dǎo)大型軟件項(xiàng)目的開發(fā)。它把開發(fā)過程分為制定計(jì)劃、風(fēng)險(xiǎn)分析

13、、實(shí)施開發(fā)和用戶評估四類活動。風(fēng)險(xiǎn)分析被擴(kuò)展到了各個階段中，因此采用螺旋模型可以降低項(xiàng)目開發(fā)的風(fēng)險(xiǎn)。生命周期計(jì)劃生命周期計(jì)劃需求計(jì)劃需求計(jì)劃風(fēng)險(xiǎn)分析風(fēng)險(xiǎn)分析原型原型1原型原型2原型原型3可操作可操作的原型的原型建模建模模擬模擬評價評價操作概念操作概念軟件需求軟件需求需求確認(rèn)需求確認(rèn)開發(fā)計(jì)劃開發(fā)計(jì)劃組裝測試計(jì)劃組裝測試計(jì)劃風(fēng)險(xiǎn)分析風(fēng)險(xiǎn)分析風(fēng)險(xiǎn)分析風(fēng)險(xiǎn)分析風(fēng)險(xiǎn)分析風(fēng)險(xiǎn)分析軟件產(chǎn)品軟件產(chǎn)品設(shè)計(jì)設(shè)計(jì)設(shè)計(jì)驗(yàn)證與確認(rèn)設(shè)計(jì)驗(yàn)證與確認(rèn)詳細(xì)詳細(xì)設(shè)計(jì)設(shè)計(jì)編碼編碼單元單元測試測試組裝組裝測試測試驗(yàn)收驗(yàn)收測試測試實(shí)現(xiàn)實(shí)現(xiàn)成本成本順時針為進(jìn)展方向順時針為進(jìn)展方向計(jì)劃：計(jì)劃：明確目標(biāo)、約束條件明確目標(biāo)、約束條件選擇方案選

14、擇方案風(fēng)險(xiǎn)分析風(fēng)險(xiǎn)分析構(gòu)造原型構(gòu)造原型工程實(shí)現(xiàn)工程實(shí)現(xiàn)用戶評價；階段評審用戶評價；階段評審圖圖1-4-3 螺旋模型螺旋模型驗(yàn)收測試計(jì)劃驗(yàn)收測試計(jì)劃需求精化計(jì)劃需求精化計(jì)劃需求評價需求評價評審決策實(shí)現(xiàn)計(jì)劃實(shí)現(xiàn)計(jì)劃螺旋模型 螺旋模型綜合了傳統(tǒng)的生存期模型的優(yōu)點(diǎn)，同時擴(kuò)展了增量模型管理任務(wù)的范圍：風(fēng)險(xiǎn)分析，用來彌補(bǔ)其不足。螺旋模型的另外一個特征是，只有一個迭代過程真正開發(fā)可交付的軟件。螺旋模型也存在其缺點(diǎn)：一個周期執(zhí)行時間太長；要有方法和自動化工具支持，否則無法實(shí)施。 螺旋模型適應(yīng)于風(fēng)險(xiǎn)較大的大型軟件項(xiàng)目的開發(fā)。統(tǒng)一過程模型 統(tǒng)一過程模型（Rational Unified Process）是種軟件工

15、程過程，它提供了如何在開發(fā)組織中嚴(yán)格分配任務(wù)和職責(zé)的方法；統(tǒng)一過程模型是一個過程產(chǎn)品，有自己的過程框架，捕獲了現(xiàn)代軟件開發(fā)中的最佳實(shí)踐。統(tǒng)一過程模型具有三大特點(diǎn)：用例驅(qū)動，以架構(gòu)為中心，迭代和增量開發(fā)。 統(tǒng)一過程模型 圖 1 12 統(tǒng)一過程模型統(tǒng)一過程模型 統(tǒng)一過程的工作流 在統(tǒng)一過程中，有6個核心工作流。 業(yè)務(wù)建模工作流。用商業(yè)用例為商業(yè)過程建立文檔。 需求工作流。目標(biāo)是描述系統(tǒng)應(yīng)該做什么，確保開發(fā)人員構(gòu)建正確的系統(tǒng)。為此，需明確系統(tǒng)的功能需求和非功能需求（約束）。 分析和設(shè)計(jì)工作流。其目標(biāo)是說明如何做。結(jié)果是分析模型和設(shè)計(jì)模型。統(tǒng)一過程模型 實(shí)現(xiàn)工作流。用分層的方式組織代碼的結(jié)構(gòu)，用構(gòu)件的

16、形式來實(shí)現(xiàn)類，對構(gòu)件進(jìn)行單元測試，將構(gòu)件集成到可執(zhí)行的系統(tǒng)中。 測試工作流。驗(yàn)證對象之間的交互、是否所有的構(gòu)件都集成了、是否正確實(shí)現(xiàn)了所有需求、查錯并改正。 部署工作流。制作軟件的外部版本、軟件打包、分發(fā)、為用戶提供幫助和支持。Company Logo統(tǒng)一過程模型 統(tǒng)一過程的階段 統(tǒng)一過程有4個階段，分別是初始階段、細(xì)化階段、構(gòu)造階段和移交階段。 初始階段。初始階段主要關(guān)注項(xiàng)目計(jì)劃和風(fēng)險(xiǎn)評估，其目的是確定是否值得開發(fā)目標(biāo)信息系統(tǒng)。 細(xì)化階段。細(xì)化階段關(guān)心定義系統(tǒng)的總體框架，其目標(biāo)是：細(xì)化初始需求（用況）、細(xì)化體系結(jié)構(gòu)、監(jiān)控風(fēng)險(xiǎn)并細(xì)化它們的優(yōu)先級、細(xì)化業(yè)務(wù)案例以及制訂項(xiàng)目管理計(jì)劃。統(tǒng)一過程模型

17、統(tǒng)一過程的階段 構(gòu)造階段。構(gòu)造階段是建立系統(tǒng)，構(gòu)造信息系統(tǒng)的第1個具有操作質(zhì)量的版本，以能夠交付給客戶進(jìn)行測試的版本結(jié)束，有時稱為測試版本。 移交階段。移交階段包含測試時期，以發(fā)布完整的系統(tǒng)而終止，其目標(biāo)是確保信息系統(tǒng)真正滿足客戶的需求。敏捷模型 “敏捷聯(lián)盟”為了幫助希望使用敏捷方法來進(jìn)行軟件開發(fā)的人們定義了12條原則：(1) 我們首先要做的是通過盡早和持續(xù)交付有價值的軟件來讓客戶滿意。(2) 需求變更可以發(fā)生在整個軟件的開發(fā)過程中，即使在開發(fā)后期，我們也歡迎客戶對于需求的變更。敏捷過程利用變更為客戶創(chuàng)造競爭優(yōu)勢。(3) 經(jīng)常交付可工作的軟件。交付的時間間隔越短越好，最好23周一次。(4) 在

18、整個的軟件開發(fā)周期中，業(yè)務(wù)人員和開發(fā)人員應(yīng)該天天在一起工作。(5) 圍繞受激勵的個人構(gòu)建項(xiàng)目，給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作。(6) 在團(tuán)隊(duì)的內(nèi)部，最有效果和效率的信息傳遞方法是面對面交談。(7) 可工作的軟件是進(jìn)度的首要度量標(biāo)準(zhǔn)。(8) 敏捷過程提倡可持續(xù)的開發(fā)速度。責(zé)任人、開發(fā)人員和用戶應(yīng)該能夠保持一種長期穩(wěn)定的開發(fā)速度。(9) 不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計(jì)會增強(qiáng)敏捷能力。(10) 盡量使工作簡單化。(11) 好的架構(gòu)、需求和設(shè)計(jì)來源于自組織團(tuán)隊(duì)。(12) 每隔一定時間，團(tuán)隊(duì)?wèi)?yīng)該反省如何才能有效地工作，并相應(yīng)調(diào)整自己的行為。敏捷模型 敏捷方法是一種輕量級的軟件工程方

19、法，相對于傳統(tǒng)的軟件工程方法，它更強(qiáng)調(diào)軟件開發(fā)過程中各種變化的必然性，通過團(tuán)隊(duì)成員之間充分的交流與溝通以及合理的機(jī)制來有效地響應(yīng)變化。 敏捷開發(fā)啟動于“敏捷軟件開發(fā)宣言”。在2001年2月，17位軟件開發(fā)者在Utah召開了長達(dá)兩天的會議，制訂并簽署了“敏捷軟件開發(fā)宣言”，該宣言聲明如下： 我們正在通過親身實(shí)踐以及幫助他人實(shí)踐的方式來揭示更好的軟件開發(fā)之路，通過這項(xiàng)工作，我們認(rèn)為： 個體和交互勝過過程和工具； 可工作軟件勝過寬泛的文檔； 客戶合作勝過合同談判； 響應(yīng)變化勝過遵循計(jì)劃。敏捷模型 敏捷模型避免了傳統(tǒng)的重量級軟件開發(fā)過程復(fù)雜、文檔繁瑣和對變化的適應(yīng)性低等各種弊端，它強(qiáng)調(diào)軟件開發(fā)過程中團(tuán)

20、隊(duì)成員之間的交流、過程的簡潔性、用戶反饋、對所作決定的信心以及人性化的特征。 敏捷過程模型中比較有代表性的是XP模型（eXtreme Programming）。它由一系列與開發(fā)相關(guān)的規(guī)則、規(guī)范和慣例組成。其規(guī)則和文檔較少，流程靈活，易于小型開發(fā)團(tuán)隊(duì)使用。XP認(rèn)為軟件開發(fā)有效的活動是：需求、設(shè)計(jì)、編碼和測試，并且在一個極限的環(huán)境下使它們發(fā)揮到極致，做到最好。XP偏重于軟件過程的描述，表現(xiàn)為激進(jìn)的迭代，組織模型和建模方法比較薄弱。生存周期模型的選擇要結(jié)合具體的項(xiàng)目特色，并在項(xiàng)目實(shí)施過程中予以改進(jìn)。敏捷方法的主要特征與原則敏捷開發(fā)方法又稱為“輕量級”開發(fā)方法 一、主要特征 強(qiáng)調(diào)適應(yīng)性 對人的關(guān)注 強(qiáng)

21、調(diào)“快”二、原則“ 剛剛好 ”敏捷開發(fā)原則我們最優(yōu)先要做的是通過盡早地、持續(xù)地交付有價值的軟件來滿足客戶需要。 我們歡迎需求的變化，即使到了開發(fā)后期。敏捷過程能夠駕馭變化，為客戶創(chuàng)造競爭優(yōu)勢。 經(jīng)常交付可以工作的軟件，從幾個星期到幾個月，時間間隔越短越好。 在整個項(xiàng)目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須朝夕工作在一起。 圍繞斗志高昂的人構(gòu)建項(xiàng)目。給他們提供所需的環(huán)境和支持，并且信任他們能夠完成任務(wù)。 在團(tuán)隊(duì)內(nèi)部，最有效率也最有效果的信息傳達(dá)方式，就是面對面的交談。 可以工作的軟件是進(jìn)度主要的度量標(biāo)準(zhǔn)。 敏捷過程提倡可持續(xù)開發(fā)。出資人、開發(fā)者和用戶應(yīng)該總是保持穩(wěn)定的開發(fā)速度。 對卓越技術(shù)和良好設(shè)計(jì)的

22、不斷追求有助于提高敏捷性。 簡單盡量減少工作量的藝術(shù)是至關(guān)重要的。 最好的構(gòu)架、需求和設(shè)計(jì)都源自自我組織的團(tuán)隊(duì)。 每隔一定時間，團(tuán)隊(duì)都要總結(jié)如何更有效率，然后相應(yīng)地調(diào)整自己的行為。常用的敏捷開發(fā)方法 極限編程、Scrum、自適應(yīng)軟件開發(fā)、動態(tài)系統(tǒng)開發(fā)、特征驅(qū)動開發(fā)1. 極限編程極限編程 極限編程極限編程（Extreme Programming，XP）是Kent Beck、Ward Cunningham和Ron Jeffries在20世紀(jì)90年代開發(fā)的一套動態(tài)編程實(shí)踐。如今，XP是高技術(shù)行業(yè)最常采用的敏捷方法。XP中最值得關(guān)注的實(shí)踐是結(jié)對編程（pair programming）和測試驅(qū)動開發(fā)（t

23、est-driven development）。XP是一個輕量級的、靈巧的軟件開發(fā)方法；同時它也是一個非常嚴(yán)謹(jǐn)和周密的方法。它的基礎(chǔ)和價值觀是交流、樸素、反饋和勇氣；即，任何一個軟件項(xiàng)目都可以從四個方面入手進(jìn)行改善：加強(qiáng)交流；從簡單做起；尋求反饋；勇于實(shí)事求是。XP是一種近螺旋式的開發(fā)方法，它將復(fù)雜的開發(fā)過程分解為一個個相對比較簡單的小周期；通過積極的交流、反饋以及其它一系列的方法，開發(fā)人員和客戶可以非常清楚開發(fā)進(jìn)度、變化、待解決的問題和潛在的困難等，并根據(jù)實(shí)際情況及時地調(diào)整開發(fā)過程。 2. Scrum Scrum是一種迭代式增量軟件開發(fā)過程，通常用于敏捷軟件開發(fā) Scrum更多的是一種敏捷項(xiàng)

24、目管理的框架而不是一個敏捷過程。Scrum提供了一套簡單的規(guī)則。除了這些簡單規(guī)則以外，Scrum對于出現(xiàn)的情況極為靈活、極為適應(yīng)。Scrum是橄欖球術(shù)語，它不是一個首字母縮寫詞。簡單地說，Scrum與現(xiàn)有項(xiàng)目管理實(shí)踐頗為不同。首先，傳統(tǒng)項(xiàng)目經(jīng)理要扮演三種不同的角色：產(chǎn)品所有者、Scrum隊(duì)長以及團(tuán)隊(duì)。其次，使用兩種不同的待辦事宜（backlog）來對范圍進(jìn)行管理：產(chǎn)品待辦事宜捕獲產(chǎn)品的范圍；沖刺待辦事宜包含當(dāng)前迭代的詳細(xì)工作。沖刺是Scrum稱呼迭代的同義詞，每次沖刺為4周時間。整個Scrum團(tuán)隊(duì)每天碰面15分鐘，以便讓每個成員之間相互快速更新信息。Scrum在敏捷行業(yè)非常流行。3、自適應(yīng)軟件

25、開發(fā) 基于協(xié)助的敏捷、自適應(yīng)開發(fā)方法。軟件開發(fā)主要包括思考、協(xié)作和學(xué)習(xí)三個階段。4、動態(tài)系統(tǒng)開發(fā)方法 動態(tài)系統(tǒng)開發(fā)方法（Dynamic System Developmenet Method，DSDM）也是在20世紀(jì)90年代中期開發(fā)的，它的根源在于快速應(yīng)用程序開發(fā)（Rapid Application Development，RAD），這是一個在每個開發(fā)階段使用原型的迭代-增量過程模型。與敏捷開發(fā)努力在每個迭代結(jié)束時生成可工作的軟件相比，原型可能是不完整、不能工作的。不過，原型的確提供了一個很好的方法使得涉眾可以在確定需求的工作中很早就被包括進(jìn)來，因?yàn)樵涂梢杂糜讷@得反饋比如來自最終用戶的反饋。系

26、統(tǒng)的各個方面都可創(chuàng)建原型，包括其架構(gòu)。實(shí)際上，它們通常與用戶界面一起使用。動態(tài)系統(tǒng)開發(fā)方法（DSDM）由下列原則組成： 活動用戶參與。 處理業(yè)務(wù)需求。 為高層次的范圍制定基線。 在所有涉眾中進(jìn)行交流與協(xié)作。 經(jīng)常交付。 團(tuán)隊(duì)決策。 集成測試。 迭代-增量式開發(fā)。 整個開發(fā)中的可逆變更。5、特征驅(qū)動開發(fā) 特征驅(qū)動開發(fā)（Feature-Driven Development,FDD）方法是新興的敏捷軟件開發(fā)過程家族的一員，其特點(diǎn)是可以不斷提交切實(shí)可行的結(jié)果。 它強(qiáng)調(diào)特性驅(qū)動，快速迭代，即能保證快速開發(fā)，又能保證適當(dāng)文檔和質(zhì)量，非常適合中小型團(tuán)隊(duì)開發(fā)管理。它提出的每個功能開發(fā)時間不超過兩周，為每個用例

27、user case限定了粒度，具有良好可執(zhí)行性，也可以對項(xiàng)目的開發(fā)進(jìn)程進(jìn)行精確及時地監(jiān)控。它抓住了軟件開發(fā)的核心問題領(lǐng)域，即正確和及時地構(gòu)造軟件。FDD還打破了傳統(tǒng)的將領(lǐng)域和業(yè)務(wù)專家/分析師與設(shè)計(jì)者和實(shí)現(xiàn)者隔離開來的壁壘。分析師被從抽象的工作中解脫出來，直接參與到開發(fā)人員和用戶所從事的系統(tǒng)構(gòu)造工作中。 FDD定義了六種關(guān)鍵項(xiàng)目角色 ：項(xiàng)目經(jīng)理、主設(shè)計(jì)師、開發(fā)經(jīng)理、主程序員、類的所有者、領(lǐng)域?qū)＜夷芰Τ墒於饶Ｐ停–MM） 能力成熟度模型（能力成熟度模型（Capability Maturity Model Capability Maturity Model for Softwarefor Softw

28、are，英文縮寫為英文縮寫為SW-CMM,簡稱簡稱CMMCMM）是對于軟件組織在定義、實(shí)施、度量、控制和改善其軟件過程的實(shí)踐中各個發(fā)展階段的描述。 CMMCMM的核心的核心是把軟件開發(fā)視為一個過程，并根據(jù)這一原則對軟件開發(fā)和維護(hù)進(jìn)行過程監(jiān)控和研究，以使其更加科學(xué)化、標(biāo)準(zhǔn)化、使企業(yè)能夠更好地實(shí)現(xiàn)商業(yè)目標(biāo)。CMM背景 CMM是“軟件能力成熟度模型”的英文簡寫，該模型由美國卡內(nèi)基-梅隆大學(xué)的軟件工程研究所（簡稱SEI）受美國國防部委托，于1991年研究制定，初始的主要目的是為了評價美國國防部的軟件合同承包組織的能力，后因?yàn)樵谲浖髽I(yè)應(yīng)用CMM模型實(shí)施過程改進(jìn)取得較大的成功，所以在全世界范圍內(nèi)被廣泛使

29、用，SEI同時建立了主任評估師評估制度，CMM的評估方法為CBAIPI。CMM的基本思想 CMM的基本思想是，因?yàn)閱栴}是由我們管理軟件過程的方法引起的，所以新軟件技術(shù)的運(yùn)用不會自動提高生產(chǎn)率和利潤率。CMM有助于組織建立一個有規(guī)律的、成熟的軟件過程。改進(jìn)的過程將會生產(chǎn)出質(zhì)量更好的軟件，使更多的軟件項(xiàng)目免受時間和費(fèi)用的超支之苦。 軟件過程包括各種活動、技術(shù)和用來生產(chǎn)軟件的工具。因此，它實(shí)際上包括了軟件生產(chǎn)的技術(shù)方面和管理方面。CMM策略力圖改進(jìn)軟件過程的管理，而在技術(shù)上的改進(jìn)是其必然的結(jié)果。 CMM整體結(jié)構(gòu) 5個成熟度 18個關(guān)鍵過程域 52個目標(biāo) 316個關(guān)鍵實(shí)踐見P16圖 “成熟度”等級 C

30、MM是一種用于評價軟件承包能力并幫助其改善軟件質(zhì)量的方法，側(cè)重于軟件開發(fā)過程的管理及工程能力的提高與評估。CMM分為五個等級：一級為初始級，二級為可重復(fù)級，三級為已定義級，四級為已管理級，五級為優(yōu)化級。 一個組織可按一系列小的改良性步驟向更高的成熟度等級前進(jìn) ?！俺墒於取钡燃?成熟度等級成熟度等級1：初始級(Initial)。處于這個最低級的組織，基本上沒有健全的軟件工程管理制度。每件事情都以特殊的方法來做。如果一個特定的工程碰巧由一個有能力的管理員和一個優(yōu)秀的軟件開發(fā)組來做，則這個工程可能是成功的。然而通常的情況是，由于缺乏健全的總體管理和詳細(xì)計(jì)劃，時間和費(fèi)用經(jīng)常超支。結(jié)果，大多數(shù)的行動只是

31、應(yīng)付危機(jī)，而非事先計(jì)劃好的任務(wù)。處于成熟度等級1的組織，由于軟件過程完全取決于當(dāng)前的人員配備，所以具有不可預(yù)測性，人員變化了，過程也跟著變化。結(jié)果，要精確地預(yù)測產(chǎn)品的開發(fā)時間和費(fèi)用之類重要的項(xiàng)目，是不可能的。 “成熟度”等級 成熟度等級成熟度等級2：可重復(fù)級(Repeatable)。在這一級，有些基本的軟件項(xiàng)目的管理行為、設(shè)計(jì)和管理技術(shù)是基于相似產(chǎn)品中的經(jīng)驗(yàn)，故稱為“可重復(fù)”。在這一級采取了一定措施，這些措施是實(shí)現(xiàn)一個完備過程所必不可缺少的第一步。典型的措施包括仔細(xì)地跟蹤費(fèi)用和進(jìn)度。不像在第一級那樣，在危機(jī)狀態(tài)下方行動，管理人員在問題出現(xiàn)時便可發(fā)現(xiàn)，并立即采取修正行動，以防它們變成危機(jī)。關(guān)鍵的

32、一點(diǎn)是，如沒有這些措施，要在問題變得無法收拾前發(fā)現(xiàn)它們是不可能的。在一個項(xiàng)目中采取的措施也可用來為未來的項(xiàng)目擬定實(shí)現(xiàn)的期限和費(fèi)用計(jì)劃。 “成熟度”等級 成熟度等級成熟度等級3：已定義級(Defined)。在第3級，已為軟件生產(chǎn)的過程編制了完整的文檔。軟件過程的管理方面和技術(shù)方面都明確地做了定義，并按需要不斷地改進(jìn)過程，而且采用評審的辦法來保證軟件的質(zhì)量。在這一級，可引用CASE環(huán)境來進(jìn)一步提高質(zhì)量和產(chǎn)生率。而在第級過程中，“高技術(shù)”只會使這一危機(jī)驅(qū)動的過程更混亂。 “成熟度”等級 成熟度等級成熟度等級4：已管理級(Managed)。一個處于第4級的公司對每個項(xiàng)目都設(shè)定質(zhì)量和生產(chǎn)目標(biāo)。這兩個量將

33、被不斷地測量，當(dāng)偏離目標(biāo)太多時，就采取行動來修正。利用統(tǒng)計(jì)質(zhì)量控制，管理部門能區(qū)分出隨機(jī)偏離和有深刻含義的質(zhì)量或生產(chǎn)目標(biāo)的偏離(統(tǒng)計(jì)質(zhì)量控制措施的一個簡單例子是每千行代碼的錯誤率。相應(yīng)的目標(biāo)就是隨時間推移減少這個量)。 “成熟度”等級 成熟度等級5：優(yōu)化級(Optimizing)。個第5級組織的目標(biāo)是連續(xù)地改進(jìn)軟件過程。這樣的組織使用統(tǒng)計(jì)質(zhì)量和過程控制技術(shù)作為指導(dǎo)。從各個方面中獲得的知識將被運(yùn)用在以后的項(xiàng)目中，從而使軟件過程融入了正反饋循環(huán)，使生產(chǎn)率和質(zhì)量得到穩(wěn)步的改進(jìn)。 “成熟度”等級 整個企業(yè)將會把重點(diǎn)放在對過程進(jìn)行不斷的優(yōu)化，采取主動的措施去找出過程的弱點(diǎn)與長處，以達(dá)到預(yù)防缺陷的目標(biāo)。同

34、時，分析各有關(guān)過程的有效性資料，作出對新技術(shù)的成本與效益的分析，并提出對過程進(jìn)行修改的建議。達(dá)到該級的公司可自發(fā)的不斷改進(jìn)，防止同類缺陷二次出現(xiàn)。 CMM為軟件的過程能力提供了一個階梯式的改進(jìn)框架，它基于以往軟件工程的經(jīng)驗(yàn)教訓(xùn)，提供了一個基于過程改進(jìn)的框架圖，它指出一個軟件組織在軟件開發(fā)方面需要那些主要工作，這些工作之間的關(guān)系，以及開展工作的先后順序，一步一步的做好這些工作而使軟件組織走向成熟。 關(guān)鍵過程域：(KPA) CMM2:可重復(fù)階段需求管理：requrement management軟件項(xiàng)目計(jì)劃：software project planning軟件項(xiàng)目跟蹤和監(jiān)督：software p

35、roject tracking oversight軟件子合同管理：software subcontract management 軟件質(zhì)量保證：software quanlity assurance 軟件配置管理：software configuratione managementCMM3:已定義階段組織過程焦點(diǎn)：organization process focus組織過程定義：organization process definition 培訓(xùn)大綱：training program集成軟件管理：intergrated software management軟件產(chǎn)品工程：software pr

36、oduct engineering組間協(xié)調(diào)：intergroup coordination同行評審：peer reviewCMM4:已管理階段定量管理過程：quantitative process management軟件質(zhì)量管理：software quality managementCMM5:優(yōu)化階段缺陷預(yù)防：defect prevention技術(shù)改革管理：technology change management過程更改管理：process change managementCMM應(yīng)用 CMM標(biāo)準(zhǔn)主要應(yīng)用于三個方面1）用于軟件過程改進(jìn)（Software Process Improvement,SPI）：幫助軟件企業(yè)對軟件過程的改進(jìn)進(jìn)行計(jì)劃、制定和實(shí)施。2）用于軟件過程評估（ Software Process Assessmen