许多软件企业在实施CMM时，过多地采用“拿来主义”，实施工具要“拿来”（照搬国外的工具），体系“设计”也要“拿来”（用别人的成套模板改改来用）。这种做法不一定适合软件企业的实际，会使软件过程改进（SPI）失去意义，那么体系设计有没有方法？这里提出CMM体系设计的三步曲，就是CMM体系设计中应依次采取三种不同设计方法：概要设计、详细设计和度量设计。

通过软件过程改进，得以构建一套系统的工程化管理体系（以下简称SEMP），该体系是以文档形式来体现的，这些文档分三类，其关系如图1。

图1

体系设计的三种方法分别输出三类文档：总体文档、过程文档和支持文档。总体文档描述系统总体，指出系统设计依据、总体目标、方针、策略和系统概貌描述，在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同样是从诊断得出的需求而来，通常需要优先采集的度量数据包括：代码缺陷、进度跟踪数据、开销跟踪数据。

以下两例显示GQM的使用方法：

样例一：有关缺陷的度量设计

G：能否有重点的消除缺陷;

Q：缺陷数据是否被记录，

缺陷数据是否被分析;

M：文档——评审报告;

代码：问题报告单。

样例二：对产品缺陷的度量设计输出

度量设计的输出将体现在各类工作表单、过程数据库中，而度量总体的描述可以纳入总体文档中，方便阅读者全局把握。