软件
产品
软件项目量化管理是CMMI高成熟度的标志，也是项目管理及软件工程的难点。本人做为项目经理，在CMMI4和5的试点和实施过程中，体会到量化管理是上述高成熟度项目管理的核心。本文重点是量化管理应用的实践，介绍量化管理主要概念和进行量化管理的过程。
在整个项目管理知识体系中，涉及到需要量化管理的领域非常多。一般依据事前估算（预测）、事中控制和事后管理的角度来分，可以分为估算（预测）、过程控制和度量等，并据此调整工作量和工作计划，形成闭环循环过程。
其实，量化管理的数据内容很多，本文的实践，核心量化数据是工作量、工作成果（例如：KLOC）和缺陷数，相关的还有人员能力、评审/测试次数等基础数据，由于篇幅有限，数据的度量、人员能力评价等内容省略；关键过程域中管理工作内容实践的有：项目策划中的项目估算，量化管理及原因分析两个部分。
CMMI是Capacity MaturityModelIntegrated的简称，即集成的软件能力成熟度模型，是一种综合性模型，它是工程实施和管理方法，它在软件与系统集成以外的如科研、工程等领域都得到了广泛的应用。
CMMI将软件过程中的很多过程都通过过程工程规范起来，它给出了过程改进的模型和大框架。
CMMI给我们带来了如下好处：改进项目进度和预算的可预测性、改进监控项目过程及子过程的性能和稳定性、改进开发周期、提高生产率、改进质量、增加客户的满意度、提高员工的士气、增加投资回报和低质量成本。
⑴、CMMI高成熟度定义
①．ML4量化管理级（Quantitative Management）
与量化管理的关键过程域有：PP、MA、PMC、IPM，如下图所示。
⑴、度量（MA）为QPM提供的数据
度量数据来源于度量数据库和里程碑报告。
①．各个阶段及活动工作量度量数据
如此表所示，工作量数据包括工程活动和质量控制活动两部分，其中，实际工作量包括正常开发和返工两部分。
②．质量控制度量数据
工作量估算主要是考虑使用组织级的资产库和历史数据，例如依据“过程裁剪指南”所形成的开发过程定义（PDP）、“软件生命周期指南”所选定的软件生命周期、“度量数据库”中的缺陷数、文档的页码、代码行。
度量数据库的使用，就是参考相当规模的项目，获取文档页码、缺陷注入率、缺陷移除率、工作量等度量数据。
估算方法有：专家法（Delphi）、功能点法、类比法、占比等。
⑴、WBS分解分类及分解准则
①．WBS分解分类：项目分解WBS（项目管理类型任务分解）、技术分解WBS（项目工程任务及特有技术工作内容分解）。
②．WBS分解原则：
⑴、编码部分估算
编码部分估算，主要是在软件功能分解的基础上，对各个功能模块代码量进行估算，估算单位是KLoc。本文是采用专家法进行估算编码工作量，由于部分功能估算估算偏差超出额定偏差（本项目定义为20%），进行了第二轮估算超出的功能模块，如下图所示：
⑵、工作规模估算
其他工程活动，例如需求开发中的需求分析活动，按输出产品规模进行估算，也就是页数（文档按标准模版编写，已经定义好的格式），如下图所示。而相关的工作量按估算模型折算为工作量。
⑶、项目管理、支持活动按占比为：项目管理10～15%，预留5%，QA%5～6、CM3～4%。
项目经理在项目级QA协助下，制定项目的质量目标，根据组织过程性能基线和模型裁剪项目过程，并对项目进行实时量化的监控，确定项目定义过程，选择度量和统计技术，对监控过程中发现的问题分析，确定并采取纠正措施。
项目经理在项目级QA协助下，制定量化项目管理计划，计划中包括：过程性能目标、项目子过程（选择）、量化管理技术、子过程路径、量化管理方案。
⑴、制定项目质量和过程性能目标
目标实现概率在95%以上
⑴、缺陷注入率（需求开发缺陷注入率RD_DIR）监控
使用Minitab中RD_DIR回归公式预测RD_DIR的预测值、上限值和下限值，预测结果定义为三角分布。
⑵、缺陷移除率（需求阶段缺陷移除率RR_DRR）监控
使用Minitab中RR_Defect回归模型（根据之前选定的分组选择回归模型）来预测RR_Defect的预测值、上限值和下限值
⑴、具备子过程能力和性能稳定描述
在过程性能监控的控制图中，活动的能力线在能力基线范围内容，能力基线（蓝色线）在红色规格基线范围内，活动的点不能连续上升、偏于中心线某一侧。
⑵、过程能力不足/超出和不稳定的处理方式
例一：
如上图所示，第二次设计评审后，评审的缺陷移除率的自然能力上限超出规格上限，并且波动较大，说明该过程的能力不足。经根因分析，原因及解决措施如下：
①．原因及异常说明
本应参与第二次评审的吴JF因出差，未能按期参与评审。此次评审中由外项目组李BX做为专家来代替，由于李BX对项目背景不熟悉，自然能力上下限超出规格限。
②．应对措施
与公司相关领导及项目管理部门联系后，在后续的评审中让吴JF参与。同时提前与吴JF本人沟通确认，保证她按时参与其后的设计评审。
③．实施效果
通过对后续评审的持续过程跟踪，自然能力限收窄，且达到规格限要求，项目QPPO达成率大于95%。
例二：
如上图所示，第3轮单元测试后发现缺陷移除率自然能力线下限超出规格线下限。经根因分析，执行了Car，原因及解决措施如下：
①．原因及异常说明
使用PPB与PPM进行分析，测试用例覆盖率及测试工作量投入都正常，通过调整模型因子无法提高过程能力。经原因分析发现是测试用例质量不高，而导致过程能力不足。
②．应对措施
执行CAR，识别本原因并加以解决。详见：本项目原因分析与解决记录。
③．实施效果
执行CAR后，UT过程能力得到提升，项目QPPO可以达成。
④．固化措施
向EPG提出改进建议：单元测试用例的质量对于单元测试过程至关重要，因此要加强单元测试用例的评审。
⑴、子过程数据不充分
在量化监控子过程过程中，技术评审、测试次数过少，例如只有3、4次。
这样的数据量，在使用控制图模型时，无法满足使用条件，也很难起到监控子过程的目的。
⑵、度量数据不真实 在精细化管理中，缺陷、工作成果度量是重叠的，而精细化管理中涉及到绩效考核，这样，在考核与项目冲突的情况下，往往会出现不真实反映项目情况的数据，为此，需要项目经理的智慧来解决这些问题，掌握好双刃剑的度。
⑴、触发条件（入口准则）
在量化分析子过程过程中，发生未达能力问题时，在调整因子或优化路径情况下，无法达成QPPO，则根据体系文件《原因分析与解决过程》所规定的入口准则，启动根因分析，由项目经理编制根因分析实施计划。
工作中，发生计划等活动中未预测到的事件（问题或好的方法），触发根因分析，根因分析要使用预测模型。
⑵、过程
①．确定原因分析的范围
②．分析原因，确定建议的改进措施
项目组（经理）组织项目相关人员，同样采用鱼骨图（鱼骨图至少应分解到第三层）和Pareto图等技术，分析问题和缺陷的根本原因，并制定改进措施。
③．制定行动计划
项目经理制定计划，经EPG批准后执行。
④．实施改进建议
项目组（经理）组织项目相关人员，在项目级QA的指导下，执行项目改进措施及建议。
⑤．评价实施效果
⑶、根因分析实践
对项目单元测试过程进行分析，分析单元测试缺陷移除率低的原因，并制定改进实施方案。
①．要因分析：
对输入、工具、人员、管理、过程、环境等原因，逐级深化分析，根因分析目标就是鱼头（UT_DRR低，单元测试缺陷移除率低的问题）。
②．做Pareto分析图表
按二八原则，80%的问题是由于20%原因造成的，选出20%的问题进行改进方案。
③．应对措施
改进实施方案如下：
●方案目标
通过改进方案的实施：
在访谈中，Henry问：项目级QA审计很多（在各个阶段的结束、里程碑、评审），为什么没有发现重大的不符合项，仅仅是少量小问题呢？
我的回答如下：
在项目级QA协助下，从CMMI3级开始，项目严格按体系文件执行，经历了多年的CMMI4、CMMI5试点，项目管理持续改进，开发过程基本稳定，所以，QA很难发现不符合项。
访谈预发布中，Henry给出的意见，对我触动较大的有三条：
①．蒙特卡洛模拟预测模型置信度为66%，那么预测目标达成率再高，也存在35%的系统误差；
②．项目经理对组织级和项目级QPPO关系认识不清，建议由项目经理负责制定项目级QPPO，由组织级进行审批；
③．项目经理需掌握项目过程监控技术技能，例如：如何使用控制图监控过程稳定、监控过程能力。
①．项目经理需要掌握数理统计技能，例如能灵活使用统计过程控制技术、蒙特卡洛模拟预测技术；
②．在CMMI4级后，引入了量化管理，使项目管理目标可以预测，过程可以控制。对于量化管理模型（PPM），仍需持续改进；
③．项目经理要积极与EPG互动，带领项目团队按体系文件重复执行项目过程，积累有效数据才能优化模型。
总之， CMMI的成熟度，很大程度还是依赖于人，人员的稳定、能力持续成长是很关键的。工具、方法是在人的使用、分析下才有意义。一句话，提高薪酬待遇，促进团队健康成长、发展，也是CMMI的关键点。
免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删
技术文档
推荐好文
155-2731-8020
