軟件過程的管理與改進(jìn).ppt

軟件過程的管理與改進(jìn) 1軟件過程管理與改進(jìn)概述2度量軟件過程3能力成熟度模型CMM4個體軟件過程PSP5團(tuán)體軟件過程TSP6內(nèi)容總結(jié) 1軟件過程管理與改進(jìn)概述 軟件過程的發(fā)展 1984年第一屆國際軟件過程討論會正式提出 軟件工程又一次認(rèn)識上飛躍 1 軟件過程的概念 軟件過程是指人們開發(fā)和維護(hù)軟件及其相關(guān)產(chǎn)品所采取的一系列活動 其中軟件相關(guān)產(chǎn)品包括項目計劃 設(shè)計文檔 源代碼 測試用例和用戶手冊等 軟件產(chǎn)品的質(zhì)量主要取決于產(chǎn)品開發(fā)和維護(hù)的軟件過程的質(zhì)量 一個有效的 可視的軟件過程能夠?qū)⑷肆Y源 物理設(shè)備和實施方法結(jié)合成一個有機(jī)的整體 并為軟件工程師和高級管理者提供實際項目的狀態(tài)和性能 從而可以監(jiān)督和控制軟件過程的進(jìn)行 IEEE廣義軟件過程 包括軟件的采購 開發(fā) 維護(hù) 運(yùn)作 獲取 管理 支持ISO12207分成三個過程 基本過程 支持過程 組織過程研究目的 管理和改進(jìn)軟件過程軟件過程管理 對軟件產(chǎn)品及對強(qiáng)化軟件系統(tǒng)的開發(fā) 維護(hù)和支持所涉及的工作過程進(jìn)行管理軟件過程改進(jìn) 為了更有效的達(dá)到優(yōu)化軟件過程的目的而實施的改善或改變其軟件過程的系列活動 1軟件過程管理與改進(jìn)概述 2 軟件過程改進(jìn)的實際意義 軟件過程實例 軟件組織在進(jìn)行具體軟件項目時采用的軟件過程 成功的改進(jìn)帶來的價值 提高效率 減少錯誤 保證進(jìn)度 提高質(zhì)量軟件過程管理改進(jìn) 是軟件組織評估和認(rèn)證的基礎(chǔ) 也是競標(biāo)軟件項目的基礎(chǔ) 軟件組織角度看軟件過程管理和改進(jìn) 有利于組織獲得認(rèn)證以提高競爭力 從產(chǎn)業(yè)角度 可以提高產(chǎn)業(yè)整體水平和競爭力 印度 1軟件過程管理與改進(jìn)概述 3 軟件過程建模與軟件過程改進(jìn)的理論與方法 軟件過程模型 又稱軟件工程開發(fā)模型或軟件生命周期模型 是軟件開發(fā)全部過程 資源和任務(wù)的結(jié)構(gòu)框架 包括組織 功能 行為及其他方面 如件過程建模 通過過程設(shè)計和過程定義來建立過程模型的活動 包含兩種常用方法 結(jié)構(gòu)化 基于模塊化思想 進(jìn)行結(jié)構(gòu)化分析 設(shè)計和編程面向?qū)ο?用面向?qū)ο蟮姆治?設(shè)計 編程及測試方法為軟件過程建模 目前的主流方法 用UML工具進(jìn)行具體建模 過程管理改進(jìn)的理論 以統(tǒng)計過程控制理論為基礎(chǔ) 內(nèi)容包括 過程的可控性 如何改進(jìn)使其產(chǎn)生預(yù)期結(jié)果 如何在度量和統(tǒng)計基礎(chǔ)上進(jìn)行過程改進(jìn) 1軟件過程管理與改進(jìn)概述 軟件過程管理的職責(zé) 定義過程度量過程控制過程改進(jìn)過程4 過程改進(jìn)的模式和體系目標(biāo)驅(qū)動模式預(yù)先設(shè)定目標(biāo)自頂向下制定過程度量或評價模型 有目的的開展改進(jìn)活動 缺陷驅(qū)動模式根據(jù)過程缺陷反饋的信息 進(jìn)行有針對性的改進(jìn)活動 1軟件過程管理與改進(jìn)概述 過程改進(jìn)體系 ISO9001 服務(wù)行業(yè)的通用標(biāo)準(zhǔn) 后追加了ISO9000 3 包含了軟件組織滿足ISO認(rèn)證的20個條款CMM 是指關(guān)注軟件開發(fā)的過程體系 明確強(qiáng)調(diào)持續(xù)的軟件過程改進(jìn) 專用于軟件的 TrilliumSPICEBOOTSTRAP5 過程改進(jìn)的原則和步驟最普遍的原則 改進(jìn)建立在評價和度量基礎(chǔ)之上是一個持續(xù)過程活動本身應(yīng)作為一個過程改進(jìn)項目完成將過程度量用于對改進(jìn)過程進(jìn)行監(jiān)控 及時對改進(jìn)活動作必要的調(diào)整適當(dāng)重復(fù)軟件過程的評價活動 1軟件過程管理與改進(jìn)概述 5 過程改進(jìn)活動的組織和實施改進(jìn)活動涉及的問題 SPI立項成立SPI小組SPI計劃制定SPI意義 明確特定項目活動的目標(biāo) 目標(biāo)期限和預(yù)計輸出項目分解成有特定操作目標(biāo)的有限任務(wù) 使項目更易完成保證任務(wù)的優(yōu)先次序和協(xié)調(diào) 闡明各任務(wù)間關(guān)系幫助高層管理者 SPI項目成員和相關(guān)從業(yè)者建立完成特定承諾作為交流工具 確保SPI過程被正確的看到和理解度量和反饋漸進(jìn)和革命建立基準(zhǔn)約定普遍建立過程改進(jìn)意識 2度量軟件過程 度量 是對對象進(jìn)行量化處理 就是采集數(shù)據(jù)和分析數(shù)據(jù) 軟件有關(guān)的度量有 軟件產(chǎn)品度量軟件項目度量軟件質(zhì)量度量軟件錯誤和缺陷度量軟件過程度量 是軟件過程改進(jìn)的基礎(chǔ)軟件過程改進(jìn)度量 軟件過程改進(jìn)本身作為一個過程也需要度量 2度量軟件過程 1 度量軟件過程的步驟 制定度量計劃確定過程問題選擇與定義度量規(guī)劃如何將度量與軟件過程集成與軟件過程集成采集數(shù)據(jù)數(shù)據(jù)的保存分析過程行為2 過程行為分析技術(shù)分析過程行為的目的是對過程穩(wěn)定行進(jìn)行測試和評價 找出異常過程行為模式 發(fā)現(xiàn)和糾正可歸屬的原因 進(jìn)行過程能力分析 2度量軟件過程 過程的穩(wěn)定性分析 一個穩(wěn)定的過程的可度量特征或過程性能的基礎(chǔ)分布是始終唯一的 對穩(wěn)定性進(jìn)行測試 需要專門的統(tǒng)計處理異常過程行為模式分析 找出過程中異常行為的規(guī)律和特點 以便發(fā)現(xiàn)問題的癥結(jié) 過程能力分析 過程能力指的是通過這個過程能達(dá)到的結(jié)果 過程能力分析除了明確過程能力 還要將過程能力與客戶或企業(yè)需要進(jìn)行比較 如果不能滿足客戶需要 必然要對過程改進(jìn) 3軟件能力成熟度模型 CMM 軟件能力成熟度模型CMM CapabilityMaturityModel 是由美國卡內(nèi)基 梅隆大學(xué)軟件工程研究所 CMU SEI 推出的評估軟件能力與成熟度的一套標(biāo)準(zhǔn) 并提供了軟件過程評估和軟件能力評價兩種評估方法和軟件成熟度提問單 4年之后 SEI將軟件過程成熟度框架進(jìn)化為軟件能力成熟度模型 CapabilityMaturityModelForSoftware 簡稱SW CMM 該標(biāo)準(zhǔn)基于眾多軟件專家的實踐經(jīng)驗 側(cè)重于軟件開發(fā)過程的管理及工程能力的提高與評估 是國際上流行的軟件生產(chǎn)過程標(biāo)準(zhǔn)和軟件企業(yè)成熟度等級認(rèn)證標(biāo)準(zhǔn) 它更代表了一種管理哲學(xué)在軟件工業(yè)中的應(yīng)用 目前 CMM認(rèn)證已經(jīng)成為世界公認(rèn)的軟件產(chǎn)品進(jìn)入國際市場的通行證 為推動我國軟件產(chǎn)業(yè)的發(fā)展 促進(jìn)軟件企業(yè)向正規(guī)化和國際化邁進(jìn) 應(yīng)進(jìn)一步引入和推廣CMM認(rèn)證 3軟件能力成熟度模型 CMM 1 CMM的體系發(fā)展 1999年提出CMMI集成能力成熟度模型 也叫綜合能力成熟度模型 包括 CMMSW 軟件工程CMM CMMSE 系統(tǒng)工程CMM CMM SE SWwithIPPD 集成的產(chǎn)品和過程開發(fā) CMMSA 系統(tǒng)采辦 來源于CMM2 0草案 1 1版本2003年1月正式發(fā)布 PSP個體軟件過程 如果沒有個體過程意識和過程能力的支持 不可能提高能力成熟度 1995提出PSPTSP團(tuán)體軟件開發(fā)過程 提供如何提高軟件開發(fā)小組本身的知識和技能的方法 1996提出TSP TSPi專門用于開發(fā)小組 軟件過程成熟度軟件過程成熟度是指一個軟件過程被明確定義 管理 度量和控制的有效程度 成熟意味著軟件過程能力持續(xù)改善的過程 成熟度代表軟件過程能力改善的潛力 成熟度等級用來描述某一成熟度等級上的組織特征 每一等級都為下一等級奠定基礎(chǔ) 過程的潛力只有在一定的基礎(chǔ)之上才能夠被充分發(fā)揮 成熟級別的改善包括管理者和軟件從業(yè)者基本工作方式的改變 組織成員依據(jù)建立的軟件過程標(biāo)準(zhǔn)執(zhí)行并監(jiān)控軟件過程 一旦來自組織和管理上的障礙被清除后 有關(guān)技術(shù)和過程的改善進(jìn)程能迅速推進(jìn) 軟件過程的成熟度等級 CMM將軟件過程的成熟度分為5個級別 MaturityLevels 如圖所示 5個等級分別是 1 初始級 Initial 2 可重復(fù) Repeatable 3 已定義級 Defined 4 已管理級 Managed 5 優(yōu)化級 Optimizing SW CMM為每個軟件組織建立和改善軟件過程提供了一個階梯式的過程成熟度框架 這一框架由5個成熟度等級構(gòu)成 除初始級以外 其余的成熟度等級都包含了若干個關(guān)鍵過程區(qū)域 每個關(guān)鍵過程區(qū)域又包含了若干個關(guān)鍵實踐 這些關(guān)鍵實踐按照5個共同特點加以組織 成熟度等級 單擊鼠標(biāo)左鍵查看相應(yīng)內(nèi)容 初始級 Initial 在初始級 企業(yè)一般不具備穩(wěn)定的軟件開發(fā)與維護(hù)環(huán)境 項目成功與否在很大程度上取決于是否有杰出的項目經(jīng)理和經(jīng)驗豐富的開發(fā)團(tuán)隊 此時 項目經(jīng)常超出預(yù)算和不能按期完成 組織的軟件過程能力不可預(yù)測 初始級 可重復(fù)級 Repeatable 在可重復(fù)級 組織建立了管理軟件項目的方針以及為貫徹執(zhí)行這些方針的措施 組織基于在類似項目上的經(jīng)驗對新項目進(jìn)行策劃和管理 組織的軟件過程能力可描述為有紀(jì)律的 并且項目過程處于項目管理系統(tǒng)的有效控制之下 可重復(fù)級 可重復(fù)級 已定義級 Defined 在已定義級 組織形成了管理軟件開發(fā)和維護(hù)活動的組織標(biāo)準(zhǔn)軟件過程 包括軟件工程過程和軟件管理過程 項目依據(jù)標(biāo)準(zhǔn)定義自己的軟件過程進(jìn)行管理和控制 組織的軟件過程能力可描述為標(biāo)準(zhǔn)的和一致的 過程是穩(wěn)定的和可重復(fù)的并且高度可視 已定義級 已管理級 Managed 在已管理級 組織對軟件產(chǎn)品和過程都設(shè)置定量的質(zhì)量目標(biāo) 項目通過把過程性能的變化限制在可接受的范圍內(nèi) 實現(xiàn)對產(chǎn)品和過程的控制 組織的軟件過程能力可描述為可預(yù)測的 軟件產(chǎn)品具有可預(yù)測的高質(zhì)量 已管理級 已管理級 優(yōu)化級 Optimizing 在優(yōu)化級 組織通過預(yù)防缺陷 技術(shù)創(chuàng)新和更改過程等多種方式 不斷提高項目的過程性能以持續(xù)改善組織軟件過程能力 組織的軟件過程能力可描述為持續(xù)改善的 優(yōu)化級 優(yōu)化級 表1描述了SW CMM不同成熟度等級過程的可視性和過程能力 可視性與過程能力的比較 SW CMM的關(guān)鍵過程區(qū)域 關(guān)鍵過程區(qū)域除了初始級外 每一成熟度等級又由若干個關(guān)鍵過程區(qū)域 KeyProcessAreas 構(gòu)成 關(guān)鍵過程區(qū)域指出為了達(dá)到某個成熟度等級所要著手解決的問題 達(dá)到一個成熟度等級 必須實現(xiàn)該等級上的全部關(guān)鍵過程區(qū)域 要實現(xiàn)一個關(guān)鍵過程區(qū)域 就必須達(dá)到該關(guān)鍵過程區(qū)域的所有目標(biāo) 每個等級內(nèi)容按三個層面組織 關(guān)鍵過程域 KPA 共同特點關(guān)鍵實踐關(guān)鍵過程區(qū)域KPA KeyProcessAreas 是一組相關(guān)的活動 可按照上表描述 也可按照圖描述 關(guān)鍵實踐 對軟件組織的能力成熟度有關(guān)鍵意義的實踐共同特點五個 承諾能力活動監(jiān)控驗證 CMM常見關(guān)鍵過程域 1 需求管理 requirementsmanagement 建立客戶的軟件項目需求 並使項目開發(fā)人員與客戶對軟件需求產(chǎn)生一致的理解 這是軟件項目規(guī)劃 SPP 和管理 SPTO 的基礎(chǔ) 需求變更依賴于配置管理 SCM 的變更控制流程 在項目實施過程中 最突出的現(xiàn)象就是項目組成員沒有完全理解需求 軟件需求不穩(wěn)定 客戶經(jīng)常變更需求 無法有效控制需求變更 需求變更往往造成項目延期和費(fèi)用超支 CMM要求的需求管理的基本流程可如所示 該流程描述了軟件工程組開始獲取原始需求 匯總為系統(tǒng)需求 分配系統(tǒng)需求 復(fù)審軟件需求 軟件需求必須文檔化形成需求文檔 此文檔必須經(jīng)過相關(guān)組和個人的評審 通過評審之后才納入配置管理 為需求文檔建立基線 軟件項目計劃 活動及軟件工作產(chǎn)品 應(yīng)和軟件需求的變化保持一致 a 獲取需求和確認(rèn)需求以Usecase 用例 為單位 以RationalRequisitePro作為需求管理工具 使用RationalRose進(jìn)行維護(hù)Usecase和UsecaseModel b 通過訪談 從客戶處獲取原始需求 形成需求文檔 c 分析軟件需求形成Usecase描述文檔 與客戶共同確認(rèn)需求 向客戶展示Usecase文檔 獲得客戶認(rèn)可 d 建立基線的需求必須通過相關(guān)組的審查 包括 系統(tǒng)分析組 設(shè)計組 編碼組 測試組 質(zhì)量保證組 配置管理組 文檔管理中心及個人 通過審查 項目組成員發(fā)現(xiàn)需求是否可行 是否完善 是否清晰 是否可進(jìn)行測試 e 通過審查后 將需求文檔納入配置管理 為需求創(chuàng)建基線 需求管理步驟 f 通過工具管理 對需求進(jìn)行跟蹤 盡快找出需求變更受影響的需求及工件 并了解需求的實現(xiàn)情況 g 客戶確認(rèn)后如需變更 項目小組成員向其說明變更的影響 并有可能增加費(fèi)用及時間 盡量控制客戶的需求 需求變更的流程按配置管理的變更流程執(zhí)行 h 一旦需求發(fā)生變更 項目計劃 活動 工序隨之變更 并重新提交相關(guān)組和個人復(fù)審 i 實際項目需求管理中應(yīng)用的文檔有 項目需求管理流程定義 項目需求復(fù)審流程定義 項目需求及狀態(tài)跟蹤流程定義 需求獲取表格 需求狀態(tài)報告 需求復(fù)審報告 需求變更報告 需求跟蹤報告 2 軟件項目計劃 softwareprojectplanning 制定實施軟件工程與管理軟件項目的工作計劃 CMM軟件項目計劃根據(jù)納入配置管理后的軟件需求進(jìn)行項目估算 并依據(jù)文檔化的流程 形成項目計劃文檔 項目計劃文檔經(jīng)復(fù)審后納入配置管理 由項目開發(fā)人員遵循 并據(jù)此跟蹤檢查計劃的執(zhí)行 項目計劃文檔在復(fù)審過程中 如果項目計劃對風(fēng)險估算不足或存在其它問題 就需要對項目計劃文檔重新修正 以獲得項目組和高層管理者的支持 a 項目采用MicrosoftWord擬定計劃文檔 以MicrosoftProject擬定計劃的進(jìn)度表 b 項目經(jīng)理根據(jù)項目軟件需求進(jìn)行估算 確定進(jìn)行項目選擇的生命周期 項目規(guī)模 所需的人員 時間 進(jìn)度 資源 風(fēng)險等內(nèi)容 將估算的結(jié)果形成估算過程文檔 并擬定軟件開發(fā)計劃 c 軟件開發(fā)計劃內(nèi)容包含 軟件項目計劃 迭代計劃 進(jìn)度時間表 配置管理計劃 質(zhì)量保證計劃 需求管理計劃 項目評測計劃 風(fēng)險管理計劃 產(chǎn)品驗收計劃 問題解決計劃 測試計劃 軟件項目計劃的實際應(yīng)用模式如下 d 估算過程文檔和軟件項目計劃文檔必須通過相關(guān)組的審查 以獲得相關(guān)組及個人的支持 包括 系統(tǒng)分析組 設(shè)計組 編碼組 測試組 質(zhì)量保證組 配置管理組 文檔管理中心及個人 通過審查 發(fā)現(xiàn)并修正項目估算和項目計劃的偏差 只有獲得了支持 軟件項目組在開發(fā)過程中才能盡量避免或消除風(fēng)險 e 在高層管理者復(fù)審?fù)ㄟ^后 項目經(jīng)理指定人員或參與擬定軟件開發(fā)計劃其它部分 并由相關(guān)組和個人復(fù)審 f 配置管理人員將軟件開發(fā)計劃文檔納入配置管理 g 實際項目中應(yīng)用的文檔有 制定項目計劃流程定義 項目估算流程定義 項目評估表 資源評估表 軟件開發(fā)計劃模板 包括 軟件項目計劃 迭代計劃 配置管理計劃 質(zhì)量保證計劃 需求管理計劃 項目評測計劃 風(fēng)險管理計劃 產(chǎn)品驗收計劃 問題解決計劃 測試計劃 進(jìn)度時間表 制訂軟件開發(fā)計劃的指南 3 軟件項目跟蹤和監(jiān)督 softwareprojecttrackingandoversight 根據(jù)軟件開發(fā)計劃管理軟件項目 隨時掌握軟件項目的實際開發(fā)過程 按照項目計劃對軟件開發(fā)的進(jìn)度和階段產(chǎn)品進(jìn)行跟蹤和評審 當(dāng)軟件項目的執(zhí)行狀況與軟件項目計劃發(fā)生較大偏差時 管理機(jī)構(gòu)必須采取有效控制措施 必要時根據(jù)項目的實際完成情況和結(jié)果 修訂項目計劃 CMM軟件項目跟蹤與監(jiān)控的基本流程可如所示 該流程描述了軟件項目組根據(jù)文檔化的估計 承諾 計劃跟蹤和審查軟件成果 并基于實際調(diào)整計劃 文檔化的軟件項目計劃被用作跟蹤軟件活動 了解狀態(tài)和修正計劃的基礎(chǔ) 項目經(jīng)理根據(jù)項目開發(fā)計劃跟蹤項目的執(zhí)行情況 定期形成項目進(jìn)度報告 并與項目開發(fā)計劃進(jìn)行對比 發(fā)現(xiàn)問題 根據(jù)實際情況對軟件開發(fā)計劃進(jìn)行修正 掌握了這個核心 實施軟件項目跟蹤與監(jiān)控活動就很容易了 a 項目組使用Rational的工具進(jìn)行管理 將MicrosoftProject擬定的項目計劃進(jìn)度表導(dǎo)入ClearQuest 主要以ClearCase和ClearQuest作為跟蹤監(jiān)控工具 b 項目經(jīng)理每周根據(jù)項目的實際執(zhí)行情況 擬定項目的進(jìn)度報告 然后召集項目小組成員 對進(jìn)度報告進(jìn)行確認(rèn)和修正 c 項目經(jīng)理對照計劃與實際執(zhí)行情況 發(fā)現(xiàn)差距并將其紀(jì)錄成問題報告 其中包括 費(fèi)用 進(jìn)度 風(fēng)險 人員 資源狀況等 d 由高層管理者復(fù)審進(jìn)度報告及問題報告 并敦促項目經(jīng)理修正其計劃及解決項目存在的問題和風(fēng)險 e 實際項目中應(yīng)用的文檔有 項目跟蹤與監(jiān)控流程定義 項目進(jìn)度報告 項目進(jìn)度指標(biāo)收集指南 項目計劃跟蹤與監(jiān)控采取如下方式 4 軟件分包合同管理 subcontractmanagement 根據(jù)商業(yè)聯(lián)盟 過程能力和技術(shù)等因素選擇高質(zhì)量的軟件承制方 承制軟件項目的部分子項目 制訂子項目承制方的工作任務(wù)和項目計劃文檔 它是主承制方跟蹤檢查和監(jiān)督子項目過程和產(chǎn)品的依據(jù) 5 軟件質(zhì)量保證 qualityassurance 評審軟件產(chǎn)品和活動 檢驗它們是否與應(yīng)用的標(biāo)準(zhǔn)和規(guī)程保持一致 對發(fā)現(xiàn)的問題應(yīng)采取必要措施予以解決 軟件質(zhì)量保證的基本流程可如所示 該流程描述了軟件質(zhì)量保證計劃的形成與復(fù)審 SQA人員根據(jù)質(zhì)量保證計劃開展質(zhì)量保證活動 發(fā)現(xiàn)問題 跟蹤解決問題 并最終向高層管理者匯報項目的執(zhí)行情況 質(zhì)量保證計劃一般包含項目過程采用的標(biāo)準(zhǔn) 如 項目計劃估算過程 計劃過程 測試過程 復(fù)審過程 開發(fā)過程 風(fēng)險管理等 以及軟件工作產(chǎn)品的標(biāo)準(zhǔn) 如 編碼標(biāo)準(zhǔn) 接口定義標(biāo)準(zhǔn)等 軟件質(zhì)量保證過程 a 項目質(zhì)量保證人員以MicrosoftWord擬定項目質(zhì)量保證計劃文檔 以MicrosoftProject擬定項目質(zhì)量保證活動的進(jìn)度表 b 由質(zhì)量保證經(jīng)理或高層管理者指定項目的質(zhì)量保證人員 項目的質(zhì)量保證人員在項目開發(fā)計劃復(fù)審?fù)ㄟ^之后 擬定項目的質(zhì)量保證計劃 并提交給項目經(jīng)理和質(zhì)量保證經(jīng)理或高層管理者復(fù)審 c 質(zhì)量保證人員根據(jù)計劃對項目執(zhí)行的活動進(jìn)行定期審計 記錄與項目流程定義不一致的問題 并形成報告 d 質(zhì)量保證人員組織人員對產(chǎn)出的工作產(chǎn)品進(jìn)行復(fù)審 以驗證其是否與項目采用的標(biāo)準(zhǔn)一致 并形成報告 e 將審計和復(fù)審發(fā)現(xiàn)的問題記錄到項目的問題跟蹤進(jìn)度表中 跟蹤并協(xié)調(diào)問題的解決情況 并定期向高層管理者匯報 如果不能解決的由高層管理者協(xié)助解決 f 項目經(jīng)理或高層管理者定期檢查質(zhì)量保證人員的活動 g 實際項目中應(yīng)用的文檔有 項目質(zhì)量保證流程定義 質(zhì)量保證計劃 流程審計報告 軟件工作產(chǎn)品復(fù)審報告 質(zhì)量保證計劃進(jìn)度表 SQA問題跟蹤解決進(jìn)度表 6 軟件配置管理 configurationmanagement 保證軟件項目生成的產(chǎn)品在軟件生命周期中的完整性 在給定時間點上確定軟件配置 如工作產(chǎn)品及其說明 系統(tǒng)的控制軟件配置的變化并在整個軟件生命周期中維護(hù)配置的完整性和可跟蹤性 軟件配置管理可以分為兩方面的內(nèi)容 一是配置項的識別和管理 另一方面是變更管理 a 配置項管理的基本流程可如所示 該流程描述了軟件工程組在進(jìn)行開發(fā)過程中 生成軟件工作產(chǎn)品 識別配置項 為配置項創(chuàng)建基線 配置管理項最顯著的特征就是包含版本號或發(fā)布日期 實際項目管理經(jīng)常不知道該如何識別區(qū)分配置項和基線 b 變更管理描述了納入配置管理的配置項進(jìn)行變更的完整流程 根據(jù)新需求 項目進(jìn)度報告 客戶意見反饋 軟件工作產(chǎn)品復(fù)審記錄等不同的原因提出變更申請 由項目小組或變更控制委員會 SCCB 分析其影響 確定變更請求的拒絕 接受或擱置 并根據(jù)不同的決定進(jìn)行不同的處理 一直到變更請求被處理 一旦采用了嚴(yán)格的變更控制管理流程 才能了解變更造成的影響 所有項目組成員才了解變更 形成共識 接受變更 缺少對變更有效的控制 往往會造成配置管理的無序 導(dǎo)致項目返工 延期 甚至失敗 a 項目設(shè)定配置管理人員 以RationalClearCase為配置管理工具 根據(jù)項目計劃擬定項目的配置管理計劃文檔 以MicrosoftProject擬定項目配置活動的進(jìn)度表 b 項目的配置管理計劃包含以下內(nèi)容 配置管理工具 目錄結(jié)構(gòu) 識別配置項的方法 配置項命名 創(chuàng)建配置管理庫 基線管理 配置審計 配置狀態(tài)報告 變更管理等 c 在ClearCase創(chuàng)建項目的VOB 版本對象庫 創(chuàng)建項目小組成員的工作區(qū)和集成區(qū) 項目組成員只在各自的工作區(qū)Checkin或Checkout操作 由配置管理人員進(jìn)行合并 標(biāo)識出軟件配置項 d 由配置管理人員負(fù)責(zé)在適當(dāng)?shù)臅r機(jī) 如 里程碑處或迭代結(jié)束 創(chuàng)建基線 晉升基線 下降基線 并由其負(fù)責(zé)備份和恢復(fù)基線 軟件配置管理的方法 e 根據(jù)配置管理計劃對項目的配置項和基線定期 或里程碑處 進(jìn)行審計 以驗證其是否與項目配置計劃或項目開發(fā)計劃一致 f 所有的變更請求首先向配置管理人員提出 由配置管理人員對變更請求進(jìn)行分析確定其影響 組織變更評審小組 g 一旦同意變更 由配置管理人員Checkout需變更的配置項 然后對配置項進(jìn)行變更 變更完成后再由配置管理人員Checkin到配置管理庫中 h 由SQA人員定期審計配置管理的活動 i 實際項目中應(yīng)用的文檔有 項目配置管理計劃制定流程定義 項目配置管理活動流程定義 項目配置管理計劃 配置狀態(tài)報告 基線審計報告 見附表 配置項變更申請表 項目配置管理活動進(jìn)度表 配置管理工具操作指南 能力成熟度模型集成CMMI 1能力成熟度模型集成CMMI的產(chǎn)生軟件能力成熟度模型CMM取得了成功 產(chǎn)生了很大影響 系統(tǒng)工程 系統(tǒng)安全工程 集成化產(chǎn)品開發(fā)等許多工程學(xué)科和領(lǐng)域也都參照CMM建立自己的能力成熟度模型 如SE CMM PeopleCMM IPD CMM FAA iCMM等 模型的繁衍導(dǎo)致模型框架 術(shù)語等方面的矛盾和不一致 當(dāng)某一工程項目涉及若干個學(xué)科和領(lǐng)域后 這種矛盾就十分突出了 能力成熟度模型集成CMMI的產(chǎn)生 CMM公布后的若干年內(nèi)工程環(huán)境更加復(fù)雜 工程規(guī)模更大 參與工程項目的組織和人員更多 范圍更廣泛 工程的施工涉及多學(xué)科 交叉學(xué)科 并行工程 及更多的國際標(biāo)準(zhǔn) 這些新的變化促使美國國防部 美國國防工業(yè)協(xié)會和SEI CMU共同開發(fā)一種新的模型 CMMI CapabilityMaturityModelIntegration 能力成熟度模型集成CMMI CMMI項目在1998年正式啟動來自業(yè)界 政府部門和SEI CMU三個方面的170多人 經(jīng)過兩年的工作于2000年發(fā)布CMMI SE SW IPPDV1 0CMMI SE SW IPPDv1 0的主要參考模型軟件學(xué)科的SW CMM系統(tǒng)工程學(xué)科的EIA IS731集成化產(chǎn)品和過程開發(fā)領(lǐng)域的IPDCMMv0 98 能力成熟度模型集成CMMI CMMI繼承了SW CMM的階段式表示法和EIA IS731的連續(xù)式表示法 軟件學(xué)科的兩種表示法均采用統(tǒng)一的24個過程域 它們在邏輯上是等價的 對同一組織采用兩種模型分別進(jìn)行CMMI評估應(yīng)該得到相同的結(jié)論 2階段式模型和連續(xù)式模型 1 階段式模型階段式模型基本沿襲SW CMM模型框架 仍保持五個 成熟度等級 但過程域做了一些調(diào)整和擴(kuò)充 如表2 23所示 過程域的階段式分組 成熟度等級過程域L2可重復(fù)級需求管理項目計劃配置管理項目監(jiān)督和控制供應(yīng)商合同管理度量和分析過程和產(chǎn)品質(zhì)量保證L3己定義級需求開發(fā)技術(shù)解決方案產(chǎn)品集成驗證確認(rèn)組織級過程焦點組織級過程定義組織級培訓(xùn)集成化項目管理風(fēng)險管理集成化的團(tuán)隊決策分析和解決方組織級集成環(huán)境L4己管理級組織級過程性能項目定量管理L5優(yōu)化級組織級改革和實施因果分析和解決方案 2 連續(xù)式模型 連續(xù)式模型沒有與組織成熟度相關(guān)的幾個階段 連續(xù)式模型將24個過程域按照功能劃分為過程管理 項目管理 工程 支持四個過程組 表2 24連續(xù)式模型的過程域分組 連續(xù)式分組過程域過程管理組織級過程焦點組織級過程定義組織級培訓(xùn)組織級過程性能組織級改革和實施項目管理項目計劃項目監(jiān)督和控制供應(yīng)商合同管理集成化項目管理風(fēng)險管理集成化的團(tuán)隊項目定量管理工程需求管理需求開發(fā)技術(shù)解決方案產(chǎn)品集成驗證確認(rèn)支持配置管理度量和分析過程和產(chǎn)品質(zhì)量保證決策分析和解決方案組織級集成環(huán)境因果分析和解決方案 CMM和CMMI的選擇和應(yīng)用 CMM優(yōu)點CMM模型概念清晰 層次分明 易于操作 為組織負(fù)責(zé)人和管理者提供指導(dǎo)組織逐步成熟的 明確的 有效的 單一路途 CMM缺點在階段式模型中 屬于較高級別成熟度的過程域不支持較低級別的過程域 如在L2級就無法安排屬于L3級的 同行評審 過程域的實踐活動 CMM過程域的度量只有通過或不通過 度量比較粗糙沒有反映優(yōu)勢和一般 CMMI優(yōu)點CMMI SE SW和CMMI SE SW IPPD模型綜合了系統(tǒng)工程 軟件工程 集成化產(chǎn)品和過程開發(fā)三個過程改進(jìn)模型 綜合了階段式和連續(xù)式兩種結(jié)構(gòu)組織的成熟度評價和項目的軟件過程能力評估系統(tǒng)性更強(qiáng) 適應(yīng)范圍更大CMMI提供了24個過程域 組織可根據(jù)自身情況或項目的特點進(jìn)行剪裁