软件过程度量和CMMI模型概述
1.1 软件度量的基本思想
1.1.1 度量的概念
软件度量是针对计算机软件的度量，是对软件系统、组件或过程中具有的某个给定属性进行的一个定量测量[15]。在软件度量领域内经常出现Measure，Metric，Measurement，Indicator等与度量有关的相关概念，它们既相互联系又相互区别，以下是对它们的解释[16]：
1．Measure，度量，分为名词和动词两种情况。作为名词，度量指的是在一定的规则下，软件过程或产品属性的数值或类别；作为动词，度量指的是按照度量过程中的过程定义，对软件过程或软件产品实施度量的实际动作。
2．Measurement，测量，是指按照一定的规则用度量(名词)给软件实体属性赋值的过程。测量强调量化软件实体属性的过程性，目的是提取软件过程或软件产品属性的度量(名词)。
3．Metric，度量，是己定义的测量方法和测量尺度，在很多场合与指示器(Indicator)交叉出现，泛指软件对象的属性的量化表现，其内涵大于Indicator。
4．Indicator，指示器，是指用于评价或预测其他度量（名词）的度量（名词）。它是一个或多个度量的综合，能够对软件产品或过程的某一方面特征作出某种程度的反映。
1.1.2 软件度量及其分类
软件度量过程是进行确认、定义、收集和分析度量的软件过程，也是对软件属性定量化分析的过程，以此我们可以更好地了解和评估项目、产品和过程，并可以对项目进行进一步的预测和改进。度量过程可根据度量对象的不同分为项目度量、产品度量和过程度量三类，其分类如图1.1所示。
图1.1 度量过程分类
软件过程度量是本文讨论的重点，它是对软件开发过程本身的度量，其度量结果可以为持续改进软件开发过程进行提供依据。在IEEE标准1061-1998[17]中对其定义如下：
过程度量：一种用来测量在软件系统开发、实现、测试和维护过程中使用的方法、技术和过程本身的属性的度量。
过程度量一般不直接进行，它通过大量的项目度量数据分析和总结得出。与项目度量不同，过程度量是在一定组织范围内对大量项目实践的总结，能够对项目度量提供战略性的指导意义；项目度量只针对具体的某个项目进行预测、评估和改进，属于战术性的范畴。表1.1给出了项目度量、产品度量和过程度量的度量范围和各自的侧重点。
表1.1 软件度量范围
| 度量过程分类 | 度量范围 | 侧重点 | 度量具体内容 |
| 过程度量 | 软件开发过程 | 理解和控制组织当前情况，同时包括对当前过程的改进和未来过程的能力预测。 | 成熟度、管理、生命周期、生产率等。 |
| 项目度量 | 具体软件项目 | 理解和控制当前项目的情况和状态。 | 规模、成本、工作量、进度、生产力、风险、顾客满意度等。 |
| 产品度量 | 软件产品质量 | 理解和控制当前产品的质量状况，用于对产品质量的预测和控制 | 以质量度量为中心，包括功能性、可靠性、易用性、可维护性、可移植性等。 |
1.2 软件过程度量的基本思想
1.2.1 过程度量的目标和内容
软件过程度量的目标是为了对软件过程进行管理，并在度量的基础上对软件过程进行控制、评估和改进，其最终目的是为项目管理和软件过程管理服务，如图1.2所示。
图1.2 过程度量的目标
软件过程度量主要关注三个方面的内容：改善软件产品质量、提高生产效率和降低成本。而这三大类度量可细分为六个小的方面：进度、质量、资源和费用、开发性能、技术完备性和稳定性。它们是相互关联、有机统一的整体。如图1.3所示。
图1.3 度量关系图
从图1.3可以看出，软件开发性能和质量是正向关系，而和进度以及资源费用是反向关系，这说明软件开发性能的提高，就能在减少项目开发中资源和人员投入，同时缩短进度，提高软件质量；同样技术越完备，软件开发过程和产品的稳定性就越能获得保证；提高了软件过程和产品的稳定性，资源和费用的投入就相对较少；加大资源和费用的投入虽然可以加快软件生产的进度，但是一旦过度就往往过犹不及，也就是说，过分加快进度往往造成软件产品质量的降低；软件质量的提高可以减少软件维护费用，相反，对于差的软件质量，就不得不在软件维护投入大量的资源和费用。
1.2.2 过程度量的用户对象
作为企业整个软件过程的一部分，软件过程的度量过程与软件过程的其他子过程相互作用又相互影响。软件过程中不同组织和对象对度量往往有不同的需求和应用，如图1.4中所示。
图1.4 度量用户对象
首先从项目组内部来看，通过度量信息可以对项目的成本、进度、质量、资源和风险管理的计划和实施提供帮助，而且度量信息还可以作为项目管理者与公司管理层及客户进行项目状态沟通的基础；另外，度量数据还可以被软件过程组分析，进而制订过程改进计划并检验改进后的效果。
其次在项目组外部，项目过程度量信息能提高项目过程的可见性，从而有利于高层项目管理人员做出正确决策；客户可通过产品或过程的度量信息可以对软件的开发状态有比较直观的认识；大量的项目度量信息是研究部门的宝贵资源，可以用来分析和研究更好的软件过程技术。
1.2.3 过程度量的基本流程
软件过程度量通常包括选择和定义度量、制定度量计划、收集度量数据、度量分析、评估过程性能、根据评估结果采取相应的纠正、改进或者变更措施等一系列的活动，如图1.5所示。
图1.5 软件过程的度量过程
首先通过对项目的商业目标的分析选择和定义合适的度量，然后将这些度量与具体项目相结合制定度量计划。在项目的执行过程中，需要按照度量计划进行数据收集工作并对这些度量数据进行分析，最后根据分析结果来评估过程的性能。如果过程性能不稳定，则需要查找可能的原因并采取相应改进措施；如果过程性能是稳定的，那么就可以评估过程能力，并决定是变更过程或是继续改进过程。[18]
1.3 过程度量的建模方法
1.3.1 GQM方法概念
GQM(Goal-Question-Metric，目标-问题-度量)模型是由Maryland大学的Victor R. Basili教授及其助手提出的一种软件度量范式，在业界得到了广泛应用。GQM方法基于这样一个假设：对于一个软件组织，如果要进行有目的的度量，必须首先明确组织其本身的目标以及各项目的子目标，然后必须收集为这些目标定义的可操作的数据，最后它还需要提供一种框架来根据已确定的目标解释这些获取倒的数据[3]。
“目标”是指度量的目标，而不是软件组织本身的商业目标，但这两者之间是相互联系的。采用GQM范式开展度量之前需要确定度量目标，而这个目标要根据软件组织的商业目标来制定。
“问题”是指在软件过程中实现上述度量目标可能会遇到的问题，它是对度量目标的一种表述形式。对同一个目标可以提出一系列的问题，每个问题都可以从某个特定角度来反映目标，同时，问题又直接关系到需要对哪些度量信息进行收集。
“度量”是对问题的回答，是软件开发过程中度量实体属性的量化表示。
从图1.6可以看出，GQM模型最上层是目标层，对该层中的每个目标分解就得到若干个问题，进而构成问题层。对于每一个问题，再进行进一步细化就得到一系列的度量项。当然，对于不同的目标可能会遇到相同的问题，对不同的问题的回答也可能使用相同的度量。即使是测量同一个度量项，也有可能因为观测角度不同而得到不同的结果。
图1.6 GQM模型
1.3.2 其他建模方法
很多研究人员根据自己的理解和经验总结，在GQM模型的基础上提出了自己的建模方法，主要有以下几种：
1、GQIM建模方法
卡内基梅隆大学软件工程研究所软件工程度量和分析组(SEMA)在GQM模型的基础上提出了利用GQM模型进行与目标相关的度量定义。[19]
GQIM 区别于GQM的地方就在于它在Q和M之间加入了可视化的指示器(Indicator)，用于建立问题和度量数据之间的联系。这些指示器可以作为需求说明书，用以指导需要收集数据的类型，并对这些数据需要进行哪些处理作出分析，进而为这些活动制定相应的计划。
2、GQM-D建模方法
在对GQM的研究的基础上，我国研究人员宿为民、朱三元在《支持过程度量的软件过程建模方法的研究》[20]一文中提出了GQM-D方法。文章提出应从过程建模的角度考虑对过程度量的支持问题,并提出一种支持过程度量的软件过程建模方法的框架。它包括面向目标的过程度量模型建模方法、支持过程度量的软件过程描述机制的选择和支持过程度量的软件过程建模算法。GQM-D对GQM的扩展主要包括以下3个方面：
（1）对度量的分解。
（2）引入数据项分层D。
（3）增加度量集和数据项集的结构化描述。
3、GQAM建模方法[21]
GQAM(Goal-Question-Attribution-Metric，目标-问题-属性-度量)模型是在GQM模型基础上提出的，在问题层和度量层之间增加属性层以建立问题层和度量层之间的联系，同时对问题层进行简化。在实际的软件活动中，明确目标并确定与目标相关的关键问题之后，通过在属性层定义相关的关键属性，并根据属性得到具体度量，这样既可以避免选择度量的盲目性，还可以提高模型本身的可扩展性。
1.4 CMMI的构成
实施软件过程度量的主要目的是改进软件过程，目前采用较多的软件过程改进模型有CMM，ISO9000.3，ISO／IECl5504，SPICE以及CMMI等。这里主要讨论过程改进模型CMMI。
1.4.1 CMMI的源模型
CMMI(Capability Maturity Model Integration，能力成熟度模型集成)是以三个基本成熟度模型软件工程(SW-CMM )、系统工程(SE-CMM)和集成产品开发（IPD-CMM)为基础综合而来的[22]。
1.4.2 CMMI的模型系列
CMMI的模型系列包括CMMI-SW(软件能力模型集成)、CMMI-SE/SW（系统工程和软件工程能力模型集成）、CMMI-SE/SW/IPPD（系统工程、软件工程、集成化产品和过程开发能力模型集成）和CMMI- SE/SW/IPPD/SS（系统工程、软件工程、集成化产品和过程开发、供应商管理能力模型组成）。其中，SE/SW是核心，在此基础上扩展了SE/SW/ IPPD,SE/SW/ IPPD/SS。在实际应用中，不同的企业可以根据实际需要来选择不同的模型。例如，对于纯软件企业CMMI-SW比较适合；而对于制造业企业，CMMI- SE/SW/IPPD/SS是一个更好的选择。也就是说CMMI可以在不同的应用领域都适用，但是在实施中会有比较明显的差别。
1.5 CMMI的表示方式
CMMI有两种表示方式：阶段式和连续式。不同表示方式具有不同的结构，所关注的重点也各不相同。阶段式关注组织的成熟度，而连续式则是强调的是单个过程域的能力。
虽然两种表示方式的模型在结构上有所区别，但本质上并没有什么不同，所以CMMI产品组在开发中尽量确保了两者在逻辑上的一致性，这主要表现在：过程域、目标在两种表示法中一样；特定实践和共性实践在两种表示法中不存在根本区别。
1.5.1 阶段式
CMMI的阶段式[23]表示方法把CMMI中的若干个过程区域分成了5个成熟度级别，总共包含25个过程域，它们被分配到各个相应层级中，表1.2显示了阶段式过程域的分布情况。
表1.2 CMMI阶段式表示模型
| 成熟度 模型 | 过程域 | ||
| 初始级 | 无 | ||
| 管理级 | 项目计划PP | 需求管理REQM | 配置管理CM |
| 度量和分析MA | 过程和产品质量保证PPQA | ||
| 项目监督和控制PMC | 供应商合同管理SAM | ||
| 定义级 | 集成项目管理IPM | 风险管理RSKM | 集成组IT |
| 集成供应商管理ISM | 组织过程定义OPD | 组织过程焦点OPF | |
| 组织培训OT | 需求开发RD | 技术解决方案TS | |
| 产品集成PI | 验证VER | 确认VAL | |
| 组织集成环境OEI | 决策分析和解决方案DAR | ||
| 量化管理级 | 量化项目管理QPM | 组织过程性能OPP | |
| 优化级 | 组织改革和实施OID | 原因分析和解决方案CAR |
每个过程域都有与各自相对应的目标和实践，在阶段式表示方法中，通用的实践被分成4类具有公共特性的活动，这些活动是执行承诺、执行能力、指导实施以及验证实施。其中执行承诺指的是创建过程改进策略的主导关系；执行能力指用以确保项目以及软件组织具有实现过程改进所需要的资源；指导实现指的是收集、度量和分析相关数据的过程；验证实现是指验证项目和软件组织在改进过程中是否遵循相关的需求、过程和规范。如图1.7所示。
图1.7 CMMI阶段式模型部件
CMMI中成熟度等级的概念与CMM模型相同，只是第2级以及第4级的名称发生了变化，它们分别变成了己管理级和定量管理级，通过这种变化，突出了定性管理和定量管理在软件过程中的重要性。以下是对CMMI中5个等级的描述：
第1级是初始级，这个过程成熟度中结果不可预测，软件取得成功主要取决于团队的技能，过程中包含了一些特别的方法、符号、工作和反应管理，但都未予以定义。
第2级是已管理级，在这个成熟度下，项目执行是可重复的。在这个级别，组织制定了一些基本准则并以此为标准来进行需求管理、项目计划、监督和控制、供应商协议管理、配置管理、产品和过程的质量保证以及度量和分析等活动。对于级别2而言，主要的过程焦点在于项目级的活动和实践。
第3级是已定义级，以组织内改进项目执行为特征。
第4级是量化管理级，这个等级主要是以改进组织性能为特征的，历史结果可用来交替使用，可以预测在业务表现的成本、质量、时间等方面的结果。
第5级是优化管理级，这个等级具有可快速进行重新配置的组织性能，以及可持续进行定量过程改进等特征。
阶段式的表示方法具有以下优点：
首先，它提供了一种明确的跨越式发展途径。软件组织在跨越每个成熟度等级的过程中，都需要致力解决好某一方面的问题，如图1.8所示。
图1.8 阶段式CMMI与各级改进
另外，阶段式改进方式可以在不同组织之间形成对比，通过对不同组织所达到的不同成熟度等级的比较，就可以对各个组织在各方面所存在的差别有一个基本的了解。
当然，阶段式表示法存在着一定的缺陷。在这种模型中，软件组织要达到某一成熟度等级，就必须符合某个等级所有过程域的要求，这样灵活性就比较差。除此之外，在阶段式跨越时，需要针对目标等级同时进行多个过程的改进，工作量大且成本较高。
1.5.2 连续式
连续式表示方法[24]将CMMI中过程区域分为四大类：过程管理、项目管理、工程以及支持。如表1.3所示。
表1.3 CMMI连续式表示模型
| 类别 | 过程域 | ||
| 过程管理 | 组织过程定义OPD | 组织过程焦点OPF | 组织培训OT |
| 组织过程性能OPP | 组织改革和实施OID | ||
| 项目管理 | 量化项目管理QPM | 风险管理QSKM | 集成组IT |
| 集成供应商管理ISM | 项目计划PP | 集成项目管理IPM | |
| 供应商合同管理SAM | 项目监督和控制PMC | ||
| 工程 | 供求管理REQM | 需求开发RD | 技术解决方案TS |
| 产品集成PI | 验证VER | 确认VAL | |
| 支持 | 度量和分析MA | 配置管理CM | 组织集成环境OEI |
| 原因分析和解决方案CAR | 决策分析和解决方案DAR | 过程和产品质量保证PPQA |
对于每个大类中的过程域，根据每种活动的能力表现，可以分成单个过程域的能力等级CL0-CL5 (CL，Capability Level)六个能力表达层次。同样，连续式表示法的每个过程域也有其相对应的目标和实践，如图1.9所示。
图1.9 CMMI连续式模型部件
在按照连续式表示方法实施CMMI的时候，软件组织可以集中力量解决关键问题，把某一个或几个实践一直做到最好，而先不考虑其他方面的过程域。
但在实际应用中，连续式表示法并不常用，这是由于连续式方法本身的局限性决定的：由于缺乏的具体的改进路线，组织的过程改进需要有专家的指导才能确定哪些过程需要优先改进以及它们的先后次序如何；由于没有像阶段式那样的成熟度等级，与其他组织对比时具有一定的难度。所以使用CMMI模型实施过程改进的组织大部分采用阶段式表示法，但是连续式表示法也有自己的优势：
首先，连续式有比较大的灵活性，组织可以根据自身的需要来安排过程改进活动的顺序，不拘泥于阶段式单一的改进方式。
其次，连续式模型的评估结果具有更好的可见性。根据每个过程域的能力等级，可以对强项和弱项的有更加清楚的认识。
1.5.3 两种表示方法的选择
CMMI两种表示方式虽然结构上有一定不同，但二者的本质上是一致的。组织可以根据实际需要和具体情况来选择不同的表示方式。一般来说，阶段式表示法适合于从未实施过程改进或流程重组的组织，可以根据明确的改进次序来一步步地进行改进，可以步步为营；而对于曾推行过程改进的组织，采用连续式模型就会更加适合，可以根据经验选择薄弱的过程作为改进的重点，可以有的放矢。
1.6 小结
本文首先详细介绍了软件过程度量的基本思想及过程度量的几种建模方法，然后从过程改进模型CMMI的两种表示方式—阶段式和连续式出发，分析了阶段式以及连续式的优缺点，以及两种表示方式所适合的情况，为下一步研究打好基础。
