CMM實施手記之四：體系設計三步曲
北京SPIN 雅行
人們常常采用“拿來主義”的方法來完成體系“設計”，就是拿別人的成套模板改改來用。我從前在某企業時，曾有一位顧問師負責給寫質量手冊，當我閱讀時發現，竟有一半的部門和角色那個企業根本沒有！這是“拿來主義”的極致。那么體系設計有沒有方法？
通過軟件過程改進，得以構建一套系統的工程化管理體系（以下簡稱SEMP），該體系是以文檔形式來體現的，這些文檔分三類，其關系如下：
SEMP體系文檔關系
體系設計過程中，應依次采取三種不同的設計方法：概要設計、詳細設計、度量設計。
分別輸出三類文檔：總體文檔、過程文檔、支持文檔。
總體文檔描述描述系統總體，指出系統設計依據、總體目標、方針、策略和系統概貌描述；在ISO9000中稱為質量手冊；過程文件描述具體的活動、誰、什么時候、做什么事，這是系統的主體部分；支持文檔的種類非常多，提供具體的方法、規范、模板和工具。比如“JAVA編碼規范”、“配置管理工具使用指南”、“項目開發計劃模板”。
概要設計
體系的概要設計要完成如下任務：，
Ø 總體方案概述：簡述實施方案
Ø 總體策略：自底向上還是自頂向下，一步走還是分步到達
Ø 遠景目標：在比較長的一個期限內，比如1-2年，達到什么樣的狀態
Ø 階段目標：分解段實施，每階段的目標
² 第一階段
² 第二階段
Ø 設計依據
Ø 流程概述：設計哪些流程？各流程完成什么活動的簡要敘述，各流程的相互關系
Ø 生命周期：流程相對與項目生命周期、產品生命周期的關系
Ø 度量系統：度量需要達到的總體目標，源數據的獲取、處理、報告、周期、角色。
Ø 文檔圖例：體系特別是過程文件的圖例說明
Ø 責任矩陣：體系的面向角色的職責分解
Ø 體系文件清單：體系各層次文件的名錄匯總
關于SPI策略選擇已有專述論及，（參見《軟件過程改進總體策略選擇》）
總體文檔不僅僅明確了系統設計的總體，而且還可以極大方便使用者快速把握系統概貌。需要特別一提的是責任矩陣，過程文件通常是以過程為中心描述的，各角色的職責分散在不同的過程文件中，這樣難以獲得具體角色在體系中究竟何時何地做何事的信息。在總體文檔中設置責任矩陣，此問題將迎刃而解。
在此階段，將選擇和裁減有關知識域構成體系設計的理論依據。
可利用的知識域——
Ø CMM：能力成熟度模型，由美國卡內基梅隆大學軟件工程研究所提出
Ø ISO9000：國際標準，不只適用于軟件
Ø SEBOK：軟件工程知識體系
Ø PMBOK：項目管理知識體系，美國項目管理協會提出
Ø PSP：個體軟件過程
Ø TSP：小組軟件過程
Ø P-CMM：人力資源能力成熟度模型
Ø Best practice：介于理論和實踐之間的結合層，經驗性的知識，散布與各種著作和報道中
上述知識域多數自成完整系統，要想不拘泥于上述體系，希望獲得更靈活設計，需要設計者對上述體系都有著深入的掌握。尤其要對CMM、ISO9000、項目管理知識體系的相互關系進行透徹解析，這些已經有專門的文章論述，在此不贅述。
設計需要考慮的三個關鍵要素是：診斷識別出的組織的實際需求、組織的資源能力、管理基礎和成熟度。
大多數情況下，以下要素是優先需要被重視的：
Ø 配置管理
Ø 項目計劃
進一步擴展后可能會包括：
Ø 項目跟蹤和監控
Ø 項目啟動
Ø 項目收尾
再擴展：
Ø 軟件質量保障
Ø 同行評審
Ø 培訓。。。。。。
在實際情況中，存在很多復雜情況，缺乏基本軟件工程的企業可能需要在實施配置管理的同時實施基本軟件工程甚至軟件技術，避免配置管理的垃圾進垃圾出問題。不少軟件企業的部門一級沒有足夠權利，造成對SPI的推進乏力，可能需要先解決責權明晰這個基本問題。
樣例：體系概要設計輸出（部分）
詳細設計
體系的詳細設計階段需要實現概設中裁定的一系列過程。過程定義有著非常標準的模板：
Ø 目的：定義本過程的目的
Ø 角色：本過程中涉及的角色及其職責
Ø 入口準則：什么條件會觸發本過程的啟動
Ø 輸入：文檔、資源、數據
Ø 過程步驟：本過程有關的處理步驟
Ø 輸出：文檔、資源、數據
Ø 出口準則：什么條件會觸發本過程的結束
根據需要還可以增加如下的條款，以方便使用：
Ø 度量：
Ø 過程監控方法：
Ø 工具技術和方法：
Ø 差距分析：
Ø 過程改進歷史：
Ø 相關過程：
Ø 引用摸板：
Ø CHKLST：
過程步驟的描述可以采用任何的形式，但是使用圖形可以極大的方便閱讀。參加下例——
樣例：用圖形方式描述過程
一些良好驗證過的方法和實踐，不妨列入“工具技術方法”中，會對使用者提供不少方便。
度量設計
度量設計常采用所謂GQM方法，即goal-question-measurement，goal同樣是從診斷得出的需求而來，通常需要優先采集的度量數據包括：代碼缺陷、進度跟蹤數據、開銷跟蹤數據。
以下兩例顯示GQM的使用方法：
樣例：有關缺陷的度量設計
G：能否有重點的消除缺陷
Q：缺陷數據是否被記錄
缺陷數據是否被分析
M：文檔：評審報告
代碼：問題報告單
樣例：對SQA工作量度量的設計
G：了解SQA的開銷，最終統計新增管理活動的費效比
Q：是否知道SQA過程審計的開銷？
是否知道SQA參與評審的開銷？
是否知道SQA進行培訓的開銷？
M：審計CHKLST
同行評審報告
培訓簽到表
樣例：對產品缺陷的度量設計輸出
度量設計的輸出將體現在各類工作表單、過程數據庫中，而度量總體的描述可以納入總體文檔中，方便閱讀者全局把握。
體系經過概要設計、詳細設計、度量設計三步并獲得評審通過，標志著文檔編制階段結束。
[說明：本系列文章由作者在“北京軟件過程改進沙龍”的演講整理而成]
文章來源于領測軟件測試網 http://www.kjueaiud.com/