1、軟件過程的管理與改進,第3章 軟件過程的管理與改進,3.1 軟件過程管理與改進概述 3.2 度量軟件過程 3.3 能力成熟度模型CMM 3.4 個體軟件過程PSP 3.5 團體軟件過程TSP 3.6 內容總結,軟件過程的管理與改進,3.1 軟件過程管理與改進概述,軟件過程的發(fā)展1984年第一屆國際軟件過程討論會正式提出，軟件工程又一次認識上飛躍。 1、軟件過程的概念-軟件過程是指人們開發(fā)和維護軟件及其相關產(chǎn)品所采取的一系列活動。其中軟件相關產(chǎn)品包括項目計劃、設計文檔、源代碼、測試用例和用戶手冊等。 軟件產(chǎn)品的質量主要取決于產(chǎn)品開發(fā)和維護的軟件過程的質量。一個有效的、可視的軟件過程能夠將人力資源

2、、物理設備和實施方法結合成一個有機的整體，并為軟件工程師和高級管理者提供實際項目的狀態(tài)和性能，從而可以監(jiān)督和控制軟件過程的進行。 IEEE廣義軟件過程：包括軟件的采購、開發(fā)、維護、運作、獲取、管理、支持 ISO 12207分成三個過程：基本過程、支持過程、組織過程 研究目的：管理和改進軟件過程 軟件過程管理：對軟件產(chǎn)品及對強化軟件系統(tǒng)的開發(fā)、維護和支持所涉及的工作過程進行管理 軟件過程改進：為了更有效的達到優(yōu)化軟件過程的目的而實施的改善或改變其軟件過程的系列活動。,軟件過程的管理與改進,3.1 軟件過程管理與改進概述,2、軟件過程改進的實際意義： 軟件過程實例：軟件組織在進行具體軟件項目時采用

3、的軟件過程。 成功的改進帶來的價值：提高效率、減少錯誤、保證進度、提高質量 軟件過程管理改進：是軟件組織評估和認證的基礎，也是競標軟件項目的基礎。 軟件組織角度看軟件過程管理和改進：有利于組織獲得認證以提高競爭力；從產(chǎn)業(yè)角度，可以提高產(chǎn)業(yè)整體水平和競爭力（印度）,軟件過程的管理與改進,3.1 軟件過程管理與改進概述,3、軟件過程建模與軟件過程改進的理論與方法： 軟件過程模型：又稱軟件工程開發(fā)模型或軟件生命周期模型，是軟件開發(fā)全部過程、資源和任務的結構框架。包括組織、功能、行為及其他方面。 如件過程建模：通過過程設計和過程定義來建立過程模型的活動。包含兩種常用方法： 結構化：基于模塊化思想，進行

4、結構化分析、設計和編程 面向對象：用面向對象的分析、設計、編程及測試方法為軟件過程建模。目前的主流方法。用UML工具進行具體建模。 過程管理改進的理論：以統(tǒng)計過程控制理論為基礎，內容包括：過程的可控性，如何改進使其產(chǎn)生預期結果，如何在度量和統(tǒng)計基礎上進行過程改進。,軟件過程的管理與改進,3.1 軟件過程管理與改進概述,軟件過程管理的職責： 定義過程 度量過程 控制過程 改進過程 4、過程改進的模式和體系 目標驅動模式 預先設定目標自頂向下制定過程度量或評價模型，有目的的開展改進活動。 缺陷驅動模式 根據(jù)過程缺陷反饋的信息，進行有針對性的改進活動,軟件過程的管理與改進,3.1 軟件過程管理與改進

5、概述,過程改進體系： ISO 9001：服務行業(yè)的通用標準，后追加了ISO 9000-3，包含了軟件組織滿足ISO認證的20個條款 CMM：是指關注軟件開發(fā)的過程體系，明確強調持續(xù)的軟件過程改進。專用于軟件的。 Trillium SPICE BOOTSTRAP 5、過程改進的原則和步驟 最普遍的原則： 改進建立在評價和度量基礎之上 是一個持續(xù)過程 活動本身應作為一個過程改進項目完成 將過程度量用于對改進過程進行監(jiān)控，及時對改進活動作必要的調整 適當重復軟件過程的評價活動,軟件過程的管理與改進,3.1 軟件過程管理與改進概述,5、過程改進活動的組織和實施 改進活動涉及的問題： SPI立項 成立S

6、PI小組 SPI計劃 制定SPI意義： 明確特定項目活動的目標、目標期限和預計輸出 項目分解成有特定操作目標的有限任務，使項目更易完成 保證任務的優(yōu)先次序和協(xié)調，闡明各任務間關系 幫助高層管理者、SPI項目成員和相關從業(yè)者建立完成特定承諾 作為交流工具，確保SPI過程被正確的看到和理解 度量和反饋 漸進和革命 建立基準 約定 普遍建立過程改進意識,軟件過程的管理與改進,3.2度量軟件過程,度量：是對對象進行量化處理。就是采集數(shù)據(jù)和分析數(shù)據(jù)。 軟件有關的度量有： 軟件產(chǎn)品度量 軟件項目度量 軟件質量度量 軟件錯誤和缺陷度量 軟件過程度量：是軟件過程改進的基礎 軟件過程改進度量：軟件過程改進本身作

7、為一個過程也需要度量,軟件過程的管理與改進,3.2度量軟件過程,1、度量軟件過程的步驟： 制定度量計劃 確定過程問題 選擇與定義度量 規(guī)劃如何將度量與軟件過程集成 與軟件過程集成 采集數(shù)據(jù) 數(shù)據(jù)的保存 分析過程行為 2、過程行為分析技術 分析過程行為的目的是對過程穩(wěn)定行進行測試和評價，找出異常過程行為模式，發(fā)現(xiàn)和糾正可歸屬的原因，進行過程能力分析,軟件過程的管理與改進,3.2度量軟件過程,過程的穩(wěn)定性分析：一個穩(wěn)定的過程的可度量特征或過程性能的基礎分布是始終唯一的，對穩(wěn)定性進行測試，需要專門的統(tǒng)計處理 異常過程行為模式分析：找出過程中異常行為的規(guī)律和特點，以便發(fā)現(xiàn)問題的癥結。 過程能力分析：過

8、程能力指的是通過這個過程能達到的結果。過程能力分析除了明確過程能力，還要將過程能力與客戶或企業(yè)需要進行比較，如果不能滿足客戶需要，必然要對過程改進,軟件過程的管理與改進,3.3 軟件能力成熟度模型（CMM）,軟件能力成熟度模型CMM（Capability Maturity Model）是由美國卡內基-梅隆大學軟件工程研究所(CMU/SEI)推出的評估軟件能力與成熟度的一套標準。并提供了軟件過程評估和軟件能力評價兩種評估方法和軟件成熟度提問單。4年之后，SEI將軟件過程成熟度框架進化為軟件能力成熟度模型（Capability Maturity Model For Software，簡稱SW-CM

9、M）。 該標準基于眾多軟件專家的實踐經(jīng)驗，側重于軟件開發(fā)過程的管理及工程能力的提高與評估，是國際上流行的軟件生產(chǎn)過程標準和軟件企業(yè)成熟度等級認證標準，它更代表了一種管理哲學在軟件工業(yè)中的應用。 目前，CMM認證已經(jīng)成為世界公認的軟件產(chǎn)品進入國際市場的通行證。為推動我國軟件產(chǎn)業(yè)的發(fā)展，促進軟件企業(yè)向正規(guī)化和國際化邁進，應進一步引入和推廣CMM認證。,軟件過程的管理與改進,3.3 軟件能力成熟度模型（CMM）,1. CMM的體系發(fā)展,1999年提出CMMI集成能力成熟度模型，也叫綜合能力成熟度模型。包括：CMM SW（軟件工程CMM）、CMM SE（系統(tǒng)工程CMM）、CMM/SE/SW with

10、IPPD（集成的產(chǎn)品和過程開發(fā)）、CMM SA（系統(tǒng)采辦）。來源于CMM2.0草案，1.1版本2003年1月正式發(fā)布。 PSP個體軟件過程，如果沒有個體過程意識和過程能力的支持，不可能提高能力成熟度。1995提出PSP TSP團體軟件開發(fā)過程：提供如何提高軟件開發(fā)小組本身的知識和技能的方法。1996提出TSP。TSPi專門用于開發(fā)小組。,軟件過程的管理與改進,3. 軟件過程成熟度 軟件過程成熟度是指一個軟件過程被明確定義、管理、度量和控制的有效程度。成熟意味著軟件過程能力持續(xù)改善的過程，成熟度代表軟件過程能力改善的潛力。 成熟度等級用來描述某一成熟度等級上的組織特征，每一等級都為下一等級奠定基

11、礎，過程的潛力只有在一定的基礎之上才能夠被充分發(fā)揮。 成熟級別的改善包括管理者和軟件從業(yè)者基本工作方式的改變，組織成員依據(jù)建立的軟件過程標準執(zhí)行并監(jiān)控軟件過程，一旦來自組織和管理上的障礙被清除后，有關技術和過程的改善進程能迅速推進。,軟件過程的管理與改進,軟件過程的成熟度等級,CMM將軟件過程的成熟度分為5個級別（Maturity Levels） ，如圖所示，5個等級分別是：,1、初始級（Initial） 2、可重復（Repeatable） 3、已定義級（Defined） 4、已管理級（Managed） 5、優(yōu)化級（Optimizing）,SW-CMM為每個軟件組織建立和改善軟件過程提供了一個

12、階梯式的過程成熟度框架，這一框架由5個成熟度等級構成。除初始級以外，其余的成熟度等級都包含了若干個關鍵過程區(qū)域，每個關鍵過程區(qū)域又包含了若干個關鍵實踐，這些關鍵實踐按照5個共同特點加以組織。,成熟度等級,單擊鼠標左鍵 查看相應內容,軟件過程的管理與改進,初始級（Initial） 在初始級，企業(yè)一般不具備穩(wěn)定的軟件開發(fā)與維護環(huán)境。項目成功與否在很大程度上取決于是否有杰出的項目經(jīng)理和經(jīng)驗豐富的開發(fā)團隊。此時，項目經(jīng)常超出預算和不能按期完成，組織的軟件過程能力不可預測。,初始級,軟件過程的管理與改進,可重復級(Repeatable): 在可重復級，組織建立了管理軟件項目的方針以及為貫徹執(zhí)行這些方針的

13、措施。組織基于在類似項目上的經(jīng)驗對新項目進行策劃和管理。組織的軟件過程能力可描述為有紀律的，并且項目過程處于項目管理系統(tǒng)的有效控制之下。,可重復級,可重復級,軟件過程的管理與改進,已定義級（Defined）： 在已定義級，組織形成了管理軟件開發(fā)和維護活動的組織標準軟件過程，包括軟件工程過程和軟件管理過程。項目依據(jù)標準定義自己的軟件過程進行管理和控制。組織的軟件過程能力可描述為標準的和一致的，過程是穩(wěn)定的和可重復的并且高度可視,已定義級,軟件過程的管理與改進,已管理級（Managed）： 在已管理級，組織對軟件產(chǎn)品和過程都設置定量的質量目標。項目通過把過程性能的變化限制在可接受的范圍內，實現(xiàn)對產(chǎn)

14、品和過程的控制。組織的軟件過程能力可描述為可預測的，軟件產(chǎn)品具有可預測的高質量,已管理級,已管理級,軟件過程的管理與改進,優(yōu)化級（Optimizing）： 在優(yōu)化級，組織通過預防缺陷、技術創(chuàng)新和更改過程等多種方式，不斷提高項目的過程性能以持續(xù)改善組織軟件過程能力。組織的軟件過程能力可描述為持續(xù)改善的。,優(yōu)化級,優(yōu)化級,軟件過程的管理與改進,表1描述了SW-CMM不同成熟度等級過程的可視性和過程能力。,可視性與過程能力的比較,軟件過程的管理與改進,SW-CMM的關鍵過程區(qū)域,關鍵過程區(qū)域 除了初始級外，每一成熟度等級又由若干個關鍵過程區(qū)域(Key Process Areas)構成。關鍵過程區(qū)域指

15、出為了達到某個成熟度等級所要著手解決的問題。達到一個成熟度等級，必須實現(xiàn)該等級上的全部關鍵過程區(qū)域。要實現(xiàn)一個關鍵過程區(qū)域，就必須達到該關鍵過程區(qū)域的所有目標。,軟件過程的管理與改進,每個等級內容按三個層面組織： 關鍵過程域（KPA） 共同特點 關鍵實踐 關鍵過程區(qū)域KPA(Key Process Areas)是一組相關的活動，可按照上表描述，也可按照圖描述。,關鍵實踐：對軟件組織的能力成熟度有關鍵意義的實踐 共同特點五個： 承諾 能力 活動 監(jiān)控 驗證,軟件過程的管理與改進,CMM常見關鍵過程域,(1) 需求管理(requirements management) 建立客戶的軟件項目需求，並使

16、項目開發(fā)人員與客戶對軟件需求產(chǎn)生一致的理解。這是軟件項目規(guī)劃(SPP)和管理(SPTO)的基礎，需求變更依賴于配置管理(SCM)的變更控制流程。在項目實施過程中，最突出的現(xiàn)象就是項目組成員沒有完全理解需求，軟件需求不穩(wěn)定，客戶經(jīng)常變更需求，無法有效控制需求變更，需求變更往往造成項目延期和費用超支。,軟件過程的管理與改進,CMM要求的需求管理的基本流程可如所示。該流程描述了軟件工程組開始獲取原始需求，匯總為系統(tǒng)需求，分配系統(tǒng)需求，復審軟件需求，軟件需求必須文檔化形成需求文檔，此文檔必須經(jīng)過相關組和個人的評審，通過評審之后才納入配置管理，為需求文檔建立基線。軟件項目計劃、活動及軟件工作產(chǎn)品，應和軟

17、件需求的變化保持一致。,軟件過程的管理與改進,a. 獲取需求和確認需求以Use case（用例）為單位，以Rational Requisite Pro作為需求管理工具，使用Rational Rose進行維護Use case和Use case Model。 b. 通過訪談，從客戶處獲取原始需求，形成需求文檔。 c. 分析軟件需求形成Use case描述文檔，與客戶共同確認需求，向客戶展示Use case文檔，獲得客戶認可。 d. 建立基線的需求必須通過相關組的審查，包括：系統(tǒng)分析組、設計組、編碼組、測試組、質量保證組、配置管理組、文檔管理中心及個人。通過審查，項目組成員發(fā)現(xiàn)需求是否可行、是否完善

18、、是否清晰、是否可進行測試。 e. 通過審查后，將需求文檔納入配置管理，為需求創(chuàng)建基線。,需求管理步驟：,軟件過程的管理與改進,f. 通過工具管理，對需求進行跟蹤，盡快找出需求變更受影響的需求及工件，并了解需求的實現(xiàn)情況。 g. 客戶確認后如需變更，項目小組成員向其說明變更的影響，并有可能增加費用及時間，盡量控制客戶的需求。需求變更的流程按配置管理的變更流程執(zhí)行。 h. 一旦需求發(fā)生變更，項目計劃、活動、工序隨之變更，并重新提交相關組和個人復審。 i. 實際項目需求管理中應用的文檔有： 項目需求管理流程定義、項目需求復審流程定義、項目需求及狀態(tài)跟蹤流程定義、需求獲取表格、需求狀態(tài)報告、需求復審

19、報告、需求變更報告、需求跟蹤報告,軟件過程的管理與改進,軟件過程的管理與改進,(2)軟件項目計劃(software project planning) 制定實施軟件工程與管理軟件項目的工作計劃。 CMM軟件項目計劃根據(jù)納入配置管理后的軟件需求進行項目估算，并依據(jù)文檔化的流程，形成項目計劃文檔。項目計劃文檔經(jīng)復審后納入配置管理，由項目開發(fā)人員遵循，并據(jù)此跟蹤檢查計劃的執(zhí)行。項目計劃文檔在復審過程中，如果項目計劃對風險估算不足或存在其它問題，就需要對項目計劃文檔重新修正，以獲得項目組和高層管理者的支持。,軟件過程的管理與改進,a) 項目采用 Microsoft Word 擬定計劃文檔，以 Micr

20、osoft Project 擬定計劃的進度表。 b) 項目經(jīng)理根據(jù)項目軟件需求進行估算，確定進行項目選擇的生命周期、項目規(guī)模、所需的人員、時間、進度、資源、風險等內容。將估算的結果形成估算過程文檔，并擬定軟件開發(fā)計劃。 c) 軟件開發(fā)計劃內容包含：軟件項目計劃、迭代計劃、進度時間表、配置管理計劃、質量保證計劃、需求管理計劃、項目評測計劃、風險管理計劃、產(chǎn)品驗收計劃、問題解決計劃、測試計劃。,軟件項目計劃的實際應用模式如下：,軟件過程的管理與改進,d) 估算過程文檔和軟件項目計劃文檔必須通過相關組的審查，以獲得相關組及個人的支持，包括：系統(tǒng)分析組、設計組、編碼組、測試組、質量保證組、配置管理組、

21、文檔管理中心及個人。通過審查，發(fā)現(xiàn)并修正項目估算和項目計劃的偏差。只有獲得了支持，軟件項目組在開發(fā)過程中才能盡量避免或消除風險。 e) 在高層管理者復審通過后，項目經(jīng)理指定人員或參與擬定軟件開發(fā)計劃其它部分，并由相關組和個人復審。 f) 配置管理人員將軟件開發(fā)計劃文檔納入配置管理。 g) 實際項目中應用的文檔有： 制定項目計劃流程定義、項目估算流程定義、項目評估表、資源評估表、軟件開發(fā)計劃模板（包括：軟件項目計劃、迭代計劃、配置管理計劃、質量保證計劃、需求管理計劃、項目評測計劃、風險管理計劃、產(chǎn)品驗收計劃、問題解決計劃、測試計劃）、進度時間表、制訂軟件開發(fā)計劃的指南。,軟件過程的管理與改進,(

22、3) 軟件項目跟蹤和監(jiān)督(software project tracking and oversight) 根據(jù)軟件開發(fā)計劃管理軟件項目，隨時掌握軟件項目的實際開發(fā)過程。按照項目計劃對軟件開發(fā)的進度和階段產(chǎn)品進行跟蹤和評審，當軟件項目的執(zhí)行狀況與軟件項目計劃發(fā)生較大偏差時，管理機構必須采取有效控制措施，必要時根據(jù)項目的實際完成情況和結果，修訂項目計劃。,軟件過程的管理與改進,CMM軟件項目跟蹤與監(jiān)控的基本流程可如所示。該流程描述了軟件項目組根據(jù)文檔化的估計、承諾、計劃跟蹤和審查軟件成果，并基于實際調整計劃。文檔化的軟件項目計劃被用作跟蹤軟件活動、了解狀態(tài)和修正計劃的基礎。項目經(jīng)理根據(jù)項目開發(fā)計

23、劃跟蹤項目的執(zhí)行情況，定期形成項目進度報告，并與項目開發(fā)計劃進行對比，發(fā)現(xiàn)問題，根據(jù)實際情況對軟件開發(fā)計劃進行修正。掌握了這個核心，實施軟件項目跟蹤與監(jiān)控活動就很容易了。,軟件過程的管理與改進,a) 項目組使用 Rational 的工具進行管理，將 Microsoft Project 擬定的項目計劃進度表導入 ClearQuest，主要以 ClearCase 和 ClearQuest 作為跟蹤監(jiān)控工具。 b) 項目經(jīng)理每周根據(jù)項目的實際執(zhí)行情況，擬定項目的進度報告。然后召集項目小組成員，對進度報告進行確認和修正。 c) 項目經(jīng)理對照計劃與實際執(zhí)行情況，發(fā)現(xiàn)差距并將其紀錄成問題報告，其中包括：費

24、用、進度、風險、人員、資源狀況等。 d) 由高層管理者復審進度報告及問題報告，并敦促項目經(jīng)理修正其計劃及解決項目存在的問題和風險。 e) 實際項目中應用的文檔有： 項目跟蹤與監(jiān)控流程定義、項目進度報告、項目進度指標收集指南。,項目計劃跟蹤與監(jiān)控采取如下方式：,軟件過程的管理與改進,軟件過程的管理與改進,(4) 軟件分包合同管理(subcontract management) 根據(jù)商業(yè)聯(lián)盟、過程能力和技術等因素選擇高質量的軟件承制方，承制軟件項目的部分子項目。制訂子項目承制方的工作任務和項目計劃文檔，它是主承制方跟蹤檢查和監(jiān)督子項目過程和產(chǎn)品的依據(jù)。,軟件過程的管理與改進,(5) 軟件質量保證(

25、quality assurance) 評審軟件產(chǎn)品和活動，檢驗它們是否與應用的標準和規(guī)程保持一致，對發(fā)現(xiàn)的問題應采取必要措施予以解決。 軟件質量保證的基本流程可如所示。該流程描述了軟件質量保證計劃的形成與復審，SQA人員根據(jù)質量保證計劃開展質量保證活動，發(fā)現(xiàn)問題，跟蹤解決問題，并最終向高層管理者匯報項目的執(zhí)行情況。質量保證計劃一般包含項目過程采用的標準（如：項目計劃估算過程、計劃過程、測試過程、復審過程、開發(fā)過程、風險管理等）以及軟件工作產(chǎn)品的標準（如：編碼標準、接口定義標準等）。,軟件過程的管理與改進,軟件質量保證過程,a) 項目質量保證人員以Microsoft Word擬定項目質量保證計劃

26、文檔，以Microsoft Project擬定項目質量保證活動的進度表。 b) 由質量保證經(jīng)理或高層管理者指定項目的質量保證人員。項目的質量保證人員在項目開發(fā)計劃復審通過之后，擬定項目的質量保證計劃，并提交給項目經(jīng)理和質量保證經(jīng)理或高層管理者復審。 c) 質量保證人員根據(jù)計劃對項目執(zhí)行的活動進行定期審計，記錄與項目流程定義不一致的問題，并形成報告。,軟件過程的管理與改進,d) 質量保證人員組織人員對產(chǎn)出的工作產(chǎn)品進行復審，以驗證其是否與項目采用的標準一致，并形成報告。 e) 將審計和復審發(fā)現(xiàn)的問題記錄到項目的問題跟蹤進度表中，跟蹤并協(xié)調問題的解決情況，并定期向高層管理者匯報。如果不能解決的由高

27、層管理者協(xié)助解決。 f) 項目經(jīng)理或高層管理者定期檢查質量保證人員的活動。 g) 實際項目中應用的文檔有： 項目質量保證流程定義、質量保證計劃、流程審計報告、軟件工作產(chǎn)品復審報告、質量保證計劃進度表、SQA問題跟蹤解決進度表。,軟件過程的管理與改進,軟件過程的管理與改進,(6)軟件配置管理(configuration management) 保證軟件項目生成的產(chǎn)品在軟件生命周期中的完整性。在給定時間點上確定軟件配置，如工作產(chǎn)品及其說明。系統(tǒng)的控制軟件配置的變化并在整個軟件生命周期中維護配置的完整性和可跟蹤性。 軟件配置管理可以分為兩方面的內容，一是配置項的識別和管理，另一方面是變更管理。,軟件

28、過程的管理與改進,a. 配置項管理的基本流程可如所示，該流程描述了軟件工程組在進行開發(fā)過程中，生成軟件工作產(chǎn)品，識別配置項，為配置項創(chuàng)建基線。配置管理項最顯著的特征就是包含版本號或發(fā)布日期。實際項目管理經(jīng)常不知道該如何識別區(qū)分配置項和基線。,軟件過程的管理與改進,軟件過程的管理與改進,b. 變更管理描述了納入配置管理的配置項進行變更的完整流程。根據(jù)新需求、項目進度報告、客戶意見反饋、軟件工作產(chǎn)品復審記錄等不同的原因提出變更申請，由項目小組或變更控制委員會（SCCB）分析其影響，確定變更請求的拒絕、接受或擱置，并根據(jù)不同的決定進行不同的處理，一直到變更請求被處理。一旦采用了嚴格的變更控制管理流程

29、，才能了解變更造成的影響，所有項目組成員才了解變更，形成共識，接受變更。缺少對變更有效的控制，往往會造成配置管理的無序，導致項目返工、延期，甚至失敗。,軟件過程的管理與改進,軟件過程的管理與改進,a) 項目設定配置管理人員，以Rational ClearCase為配置管理工具，根據(jù)項目計劃擬定項目的配置管理計劃文檔，以Microsoft Project擬定項目配置活動的進度表。 b) 項目的配置管理計劃包含以下內容：配置管理工具、目錄結構、識別配置項的方法、配置項命名、創(chuàng)建配置管理庫、基線管理、配置審計、配置狀態(tài)報告、變更管理等。 c) 在ClearCase創(chuàng)建項目的VOB（版本對象庫），創(chuàng)建

30、項目小組成員的工作區(qū)和集成區(qū)，項目組成員只在各自的工作區(qū)Check in 或Check out操作，由配置管理人員進行合并，標識出軟件配置項。 d) 由配置管理人員負責在適當?shù)臅r機（如：里程碑處或迭代結束）創(chuàng)建基線，晉升基線，下降基線，并由其負責備份和恢復基線。,軟件配置管理的方法,軟件過程的管理與改進,e) 根據(jù)配置管理計劃對項目的配置項和基線定期（或里程碑處）進行審計，以驗證其是否與項目配置計劃或項目開發(fā)計劃一致。 f) 所有的變更請求首先向配置管理人員提出，由配置管理人員對變更請求進行分析確定其影響，組織變更評審小組。 g) 一旦同意變更，由配置管理人員Check out需變更的配置項，

31、然后對配置項進行變更，變更完成后再由配置管理人員Check in到配置管理庫中。 h) 由SQA人員定期審計配置管理的活動。 i) 實際項目中應用的文檔有： 項目配置管理計劃制定流程定義、項目配置管理活動流程定義、項目配置管理計劃、配置狀態(tài)報告、基線審計報告（見附表）、配置項變更申請表、項目配置管理活動進度表、配置管理工具操作指南,軟件過程的管理與改進,能力成熟度模型集成CMMI,1能力成熟度模型集成CMMI的產(chǎn)生 軟件能力成熟度模型CMM取得了成功，產(chǎn)生了很大影響。 系統(tǒng)工程、系統(tǒng)安全工程、集成化產(chǎn)品開發(fā)等許多工程學科和領域也都參照CMM建立自己的能力成熟度模型，如SE-CMM、People

32、 CMM、IPD-CMM、FAA-iCMM等。 模型的繁衍導致模型框架、術語等方面的矛盾和不一致。 當某一工程項目涉及若干個學科和領域后，這種矛盾就十分突出了。,軟件過程的管理與改進,能力成熟度模型集成CMMI的產(chǎn)生,CMM公布后的若干年內工程環(huán)境更加復雜，工程規(guī)模更大、參與工程項目的組織和人員更多、范圍更廣泛，工程的施工涉及多學科、交叉學科、并行工程、及更多的國際標準。 這些新的變化促使美國國防部、美國國防工業(yè)協(xié)會和SEI/CMU共同開發(fā)一種新的模型CMMI（Capability Maturity Model Integration）。,軟件過程的管理與改進,能力成熟度模型集成CMMI,CM

33、MI項目在1998年正式啟動 來自業(yè)界、政府部門和SEI/CMU三個方面的170多人，經(jīng)過兩年的工作于2000年發(fā)布 CMMI-SE/SW/IPPD V1.0 CMMI-SE/SW/IPPD v1.0的主要參考模型 軟件學科的SW-CMM 系統(tǒng)工程學科的EIA/IS 731 集成化產(chǎn)品和過程開發(fā)領域的IPD CMM v0.98,軟件過程的管理與改進,能力成熟度模型集成CMMI,CMMI繼承了SW-CMM的階段式表示法和EIA/IS 731的連續(xù)式表示法。 軟件學科的兩種表示法均采用統(tǒng)一的24個過程域，它們在邏輯上是等價的。 對同一組織采用兩種模型分別進行CMMI評估應該得到相同的結論。,軟件過

34、程的管理與改進,2 階段式模型和連續(xù)式模型,1) 階段式模型 階段式模型基本沿襲SW-CMM模型框架，仍保持五個“成熟度等級”，但過程域做了一些調整和擴充，如表2.23所示,軟件過程的管理與改進,過程域的階段式分組,成熟度等級 過程域 L2可重復級 需求管理 項目計劃 配置管理 項目監(jiān)督和控制 供應商合同管理 度量和分析 過程和產(chǎn)品質量保證 L3己定義級 需求開發(fā) 技術解決方案 產(chǎn)品集成 驗證 確認 組織級過程焦點 組織級過程定義 組織級培訓 集成化項目管理 風險管理 集成化的團隊 決策分析和解決方 組織級集成環(huán)境 L4 己管理級 組織級過程性能 項目定量管理 L5 優(yōu)化級 組織級改革和實施

35、因果分析和解決方案,軟件過程的管理與改進,2) 連續(xù)式模型,連續(xù)式模型沒有與組織成熟度相關的幾個階段。 連續(xù)式模型將24個過程域按照功能劃分為 過程管理、項目管理、工程、支持 四個過程組。,軟件過程的管理與改進,表2.24 連續(xù)式模型的過程域分組,連續(xù)式分組 過程域 過程管理 組織級過程焦點 組織級過程定義 組織級培訓 組織級過程性能 組織級改革和實施 項目管理 項目計劃 項目監(jiān)督和控制 供應商合同管理 集成化項目管理 風險管理 集成化的團隊 項目定量管理 工 程 需求管理 需求開發(fā) 技術解決方案 產(chǎn)品集成 驗證 確認 支 持 配置管理 度量和分析 過程和產(chǎn)品質量保證 決策分析和解決方案 組織

36、級集成環(huán)境 因果分析和解決方案,軟件過程的管理與改進,CMM和CMMI的選擇和應用,CMM優(yōu)點 CMM模型概念清晰、層次分明、易于操作。 為組織負責人和管理者提供指導組織逐步成熟的、明確的、有效的、單一路途。 CMM缺點 在階段式模型中，屬于較高級別成熟度的過程域不支持較低級別的過程域，如在L2級就無法安排屬于L3級的“同行評審”過程域的實踐活動。 CMM過程域的度量只有通過或不通過，度量比較粗糙沒有反映優(yōu)勢和一般。,軟件過程的管理與改進,CMMI優(yōu)點 CMMI-SE/SW和CMMI-SE/SW/IPPD模型綜合了系統(tǒng)工程、軟件工程、集成化產(chǎn)品和過程開發(fā)三個過程改進模型。 綜合了階段式和連續(xù)式兩種結構 組織的成熟度評價和項目的軟件過程能力評估系統(tǒng)性更強、適應范圍更大 CMMI提供了24個過程域，