字號: 小 中 大 |
推薦給好友
上一篇 |
下一篇
CMM體系設計三步曲(附圖表)
發布: 2007-6-04 13:59 |
作者: 網絡轉載 |
來源:
網絡 |
查看: 68次 | 進入軟件測試論壇討論
領測軟件測試網
許多軟件企業在實施CMM時,過多地采用“拿來主義”,實施工具要“拿來”(照搬國外的工具),體系“設計”也要“拿來”(用別人的成套模板改改來用)。這種做法不一定適合軟件企業的實際,會使軟件過程改進(SPI)失去意義,那么體系設計有沒有方法?這里提出CMM體系設計的三步曲,就是CMM體系設計中應依次采取三種不同設計方法:概要設計、詳細設計和度量設計。 |
通過軟件過程改進,得以構建一套系統的工程化管理體系(以下簡稱SEMP),該體系是以文檔形式來體現的,這些文檔分三類,其關系如圖1。 |
圖1
|
體系設計的三種方法分別輸出三類文檔:總體文檔、過程文檔和支持文檔?傮w文檔描述系統總體,指出系統設計依據、總體目標、方針、策略和系統概貌描述,在ISO9000中稱為質量手冊;過程文件描述具體的活動、誰、什么時候、做什么事,這是系統的主體部門;支持文檔的種類非常多,提供具體的方法、規范、模板和工具,比如Java編碼規范、配置管理工具使用指南、項目開發計劃模板。 |
體系的概要設計要完成如下任務:總體方案概述——簡述實施方案;總體策略——自底向上還是自頂向下,一步走還是分步到達;遠景目標——在比較長的一個期限內,比如1~2年,達到什么樣的狀態;階段目標——分段實施,每階段的目標; 流程概述——設計哪些流程?各流程完成什么活動的簡要敘述,各流程的相互關系;生命周期——流程相對與項目生命周期的關系;度量系統——度量需要達到的總體目標,源數據的獲取、處理、報告、周期和角色;文檔圖例——體系特別是過程文件的圖例說明;責任矩陣——體系的面向角色的職責分解; 體系文件清單——體系各層次文件的名錄匯總。 |
總體文檔不僅僅明確了系統設計的總體,而且它還可以極大方便使用者快速把握系統概貌。需要特別提到的是責任矩陣,過程文件通常是以過程為中心描述的,各角色的職責分散在不同的過程文件中,這樣難以獲得具體角色在體系中究竟何時何地做何事的信息。在總體文檔中設置責任矩陣,此問題將迎刃而解。 |
在此階段,將選擇和裁減有關知識域構成體系設計的理論依據。 |
可利用的知識域: CMM——能力成熟度模型,由美國卡內基梅隆大學軟件工程研究所提出; ISO9000——國際標準,不只適用于軟件企業;SEBOK——軟件工程知識體系;PMBOK——項目管理知識體系,美國項目管理協會提出;PSP——個體軟件過程;TSP——小組軟件過程;P-CMM——人力資源能力成熟度模型; Best Practice——介于理論和實踐之間的結合層,經驗性的知識,散布于各種著作和報道中。 |
上述知識域多數自成完整系統,要想不拘泥于上述體系,希望獲得更靈活設計,需要設計者對上述體系都有深入的掌握。尤其要對CMM、ISO9000、項目管理知識體系的相互關系進行透徹解析。 |
設計需要考慮的三個關鍵要素是:診斷識別出的組織的實際需求、組織的資源能力、管理基礎和成熟度。 |
大多數情況下,以下要素是企業優先需要重視的:配置管理、項目計劃、項目跟蹤和監控、項目啟動和項目收尾(見圖2)。 |
圖2
|
在實際情況中,存在很多復雜情況,缺乏基本軟件工程的企業可能需要在實施配置管理的同時實施基本軟件工程甚至軟件技術,避免配置管理的“垃圾進垃圾出問題”。不少軟件企業的部門一級沒有足夠權利,造成對SPI的推進乏力,可能需要先解決責權這個基本問題。 |
體系的詳細設計階段需要實現概設中裁定的一系列過程。過程定義有著非常標準的模板:目的——定義本過程的目的; 角色——本過程中涉及的角色及其職責; 入口準則——什么條件會觸發本過程的啟動; 輸入——文檔、資源和數據; 過程步驟——本過程有關的處理步驟;輸出——文檔、資源和數據; 出口準則——什么條件會觸發本過程的結束。 |
根據需要還可以增加如下的條款: 度量、過程監控方法、工具技術和方法、差距分析、過程改進歷史和相關過程。 |
過程步驟的描述可以采用任何的形式,但是使用圖形可以極大的方便閱讀(見圖3)。 |
圖3
|
一些良好驗證過的方法和實踐,不妨列入“工具技術方法”中,會對使用者提供不少方便。 |
度量設計常采用所謂GQM(Goal-Question-Measurement目標問題度量)法,Goal同樣是從診斷得出的需求而來,通常需要優先采集的度量數據包括:代碼缺陷、進度跟蹤數據、開銷跟蹤數據。 |
度量設計的輸出將體現在各類工作表單、過程數據庫中,而度量總體的描述可以納入總體文檔中,方便閱讀者全局把握。 | |
文章來源于領測軟件測試網 http://www.kjueaiud.com/
TAG:
cmm
設計
體系
三步曲
附圖表