软件项目量化管理（QPM）及根因分析实践总结（CMMI高成熟度访谈）

1、前言

    软件项目量化管理是CMMI高成熟度的标志，也是项目管理及软件工程的难点。本人做为项目经理，在CMMI4和5的试点和实施过程中，体会到量化管理是上述高成熟度项目管理的核心。本文重点是量化管理应用的实践，介绍量化管理主要概念和进行量化管理的过程。

    在整个项目管理知识体系中，涉及到需要量化管理的领域非常多。一般依据事前估算（预测）、事中控制和事后管理的角度来分，可以分为估算（预测）、过程控制和度量等，并据此调整工作量和工作计划，形成闭环循环过程。

    其实，量化管理的数据内容很多，本文的实践，核心量化数据是工作量、工作成果（例如：KLOC）和缺陷数，相关的还有人员能力、评审/测试次数等基础数据，由于篇幅有限，数据的度量、人员能力评价等内容省略；关键过程域中管理工作内容实践的有：项目策划中的项目估算，量化管理及原因分析两个部分。

1.1、CMMI概述

    CMMI是Capacity MaturityModelIntegrated的简称，即集成的软件能力成熟度模型，是一种综合性模型，它是工程实施和管理方法，它在软件与系统集成以外的如科研、工程等领域都得到了广泛的应用。
   CMMI将软件过程中的很多过程都通过过程工程规范起来，它给出了过程改进的模型和大框架。
   CMMI给我们带来了如下好处：改进项目进度和预算的可预测性、改进监控项目过程及子过程的性能和稳定性、改进开发周期、提高生产率、改进质量、增加客户的满意度、提高员工的士气、增加投资回报和低质量成本。

1.2、CMMI高成熟度

⑴、CMMI高成熟度定义

   ①．ML4量化管理级（Quantitative Management）

• 组织过程性能OPP（Organizational Process Performance）
• 量化项目管理QPM（Quantitative Project Management）

   ②．ML5优化级（Optimizing）

• 原因分析与解决方案CAR（Causal Analysis and Resolution）
• 组织革新与部署OID（Organizational Innovation and Deployment）

⑵、高成熟度常用技术

   ①．统计过程控制技术

    统计过程控制（简称SPC)是应用统计技术对过程中的各个阶段进行评估和监控，建立并保持过程处于可接受的且稳定的水平，从而保证产品质量要求的一种质量管理技术。

    统计过程控制是过程控制的一部分，从内容上说主要是有两个方面：

    一是利用控制图分析过程的稳定性，对过程存在的异常因素进行预警；

    二是计算过程能力指数分析稳定的过程能力满足技术要求的程度，对过程质量进行评价。

    在这里，统计过程控制技术使用了控制图、直方图、排列图（柏拉图）等。

   ②．蒙特卡洛分析技术

    蒙特卡罗法（Monte Carlo Simulation）也称随机模拟，它主要依据概率分布对随机变量进行抽样，然后将样本带入数学模型进行计算得到应变量。虽然蒙特卡罗模拟技术只给出的是统计估计而非精确的结果，但它对问题的维数不敏感，对求解对象是线性问题与否也没有原则性要求，因此在复杂系统的不确定分析中，蒙特卡罗方法成为不可或缺的手段。而且对于那些无法得到解析结果的复杂问题来说，这种手段可能是唯一有效的结果。

⑶、高成熟度模型

   ①．量化管理

   ②．优化级

    ● CAR

    PPB、PPM

• 为组织级原因分析，提供识别缺陷和问题的参考
• 可用于评价组织CAR改进效果 
• 用以分析、选择改进措施与活动。

    ● OID

    PPB、PPM

• 为组织OID识别革新提供参考 
• 用以估计、分析组织改进活动的效果，以预测是否过程性能是否达成目标

1.3、项目经理高成熟度工作与软件工程

     

   与量化管理的关键过程域有：PP、MA、PMC、IPM，如下图所示。

⑴、度量（MA）为QPM提供的数据

   度量数据来源于度量数据库和里程碑报告。

   ①．各个阶段及活动工作量度量数据

  如此表所示，工作量数据包括工程活动和质量控制活动两部分，其中，实际工作量包括正常开发和返工两部分。

   ②．质量控制度量数据

• 各个阶段和工程活动的质量活动基础：KLOC（千代码行）
• 各个阶段和工程活动所产生的缺陷数和缺陷移除数

⑵、项目策划为QPM提供的数据

   ①．质量目标是通过项目实施计划下达

   ②．数据及过程

• 估算报告提供估算的工程工作量
• 项目定义过程提供裁剪的过程

2、软件项目规模及工作量估算

2.1、工作量估算依据

    工作量估算主要是考虑使用组织级的资产库和历史数据，例如依据“过程裁剪指南”所形成的开发过程定义（PDP）、“软件生命周期指南”所选定的软件生命周期、“度量数据库”中的缺陷数、文档的页码、代码行。

    度量数据库的使用，就是参考相当规模的项目，获取文档页码、缺陷注入率、缺陷移除率、工作量等度量数据。

    估算方法有：专家法（Delphi）、功能点法、类比法、占比等。

2.2、任务分解

⑴、WBS分解分类及分解准则

    ①．WBS分解分类：项目分解WBS（项目管理类型任务分解）、技术分解WBS（项目工程任务及特有技术工作内容分解）。

    ②．WBS分解原则：

• 项目要求；
• 定义逐步求精；
• 人时（工作量）：一般的任务不超过2周，也就是80人时；
• 任务责任到人；
• 团队工作原则：项目经理在制定项目计划过程中，尤其是在任务分解，工期估计对关键过程中一定要与项目成员一起进行。

⑵、任务分解

    首先，跟踪任务分解模版，分别定义项目工程活动、项目管理活动、项目支持活动三部分；

    项目工程活动按本项目实践的瀑布模型生命周期和PDP，主要定义如下：需求开发、需求评审、软件设计、设计评审、编码与测试、代码走查、单元测试、集成测试、系统测试、项目验收等活动。其中，编码与测试中编码细活动，是根据项目实际情况和前期需求，分解到具体功能模块（树状结构）；

    项目管理活动分解活动如下：项目立项、项目策划、周报例会、项目结项、其他项目管理活动（例如：需求管理、量化管理等）、项目度量；

    项目支持活动分解为配置管理和质量保证两类活动。

2.3、项目估算

⑴、编码部分估算

    编码部分估算，主要是在软件功能分解的基础上，对各个功能模块代码量进行估算，估算单位是KLoc。本文是采用专家法进行估算编码工作量，由于部分功能估算估算偏差超出额定偏差（本项目定义为20%），进行了第二轮估算超出的功能模块，如下图所示：

⑵、工作规模估算

    其他工程活动，例如需求开发中的需求分析活动，按输出产品规模进行估算，也就是页数（文档按标准模版编写，已经定义好的格式），如下图所示。而相关的工作量按估算模型折算为工作量。

 

⑶、项目管理、支持活动按占比为：项目管理10～15%，预留5%，QA%5～6、CM3～4%。

 

3、软件项目量化管理（QPM）及根因分析实践

  项目经理在项目级QA协助下，制定项目的质量目标，根据组织过程性能基线和模型裁剪项目过程，并对项目进行实时量化的监控，确定项目定义过程，选择度量和统计技术，对监控过程中发现的问题分析，确定并采取纠正措施。

3.1、量化管理计划建立过程

  项目经理在项目级QA协助下，制定量化项目管理计划，计划中包括：过程性能目标、项目子过程（选择）、量化管理技术、子过程路径、量化管理方案。

⑴、制定项目质量和过程性能目标

    目标实现概率在95%以上

• 客户要求目标：交付缺陷小于23个（0.139 Defects/KLOC）;
• 公司要求目标：工作量小于589人天（3.57 Man-days/KLOC）

   经营管理部依据内外部对项目的要求下达质量目标，定义到量化项目管理计划及监控报告的过程性能目标中。

    如果目标存在冲突，解决方案如下：

• 若QPPO达成率在  90-95%之间， 则将其纳入风险进行监控与管理
• 若QPPO达成率 < 90% ,则与管理层进行谈判、沟通，是否可以降低目标，如果降低，则重新进行QPPO达成率预测；否则则接受，并纳入风险进行监控。

⑵、项目子过程定义及选择

   项目经理在项目级QA协助下，按过程工程与质量相关性进行分析，复用公司分析经验，以及项目的特征值，并根据《组织过程裁剪指南》进行裁剪，来确定项目子过程。主要子过程有：需求开发、需求评审、软件设计、设计评审等10个子过程。

    子过程选择标准:

• 与项目的QPPO具有强相关性（是有大的贡献）且是稳定的；
• 子过程的一个或多个属性是PPM中的控制因子；
• 子过程可被重复和频繁地执行，且可以为统计管理它们提供充足数据。

⑶、确定量化管理技术

   量化管理技术有：统计过程控制技术（控制图、三角分布等）、蒙特卡洛分析技术、多目标决策分析技术。

⑷、预测过程及子过程选择

⑸、量化管理方案决策选择

   过程组合分析（Optquest）分别以交付质量最高、工作量最少为目标进行多目标决策分析，两个方案交付质量都可满足项目的QPPO（置信度大于95%），通过综合分析，选择工作量最少的方案和过程及子过程选择。

⑹、蒙特卡罗方法（Monte Carlo，MC）及目标优化组合（OptQuest）分析结果

3.2、过程监控

⑴、缺陷注入率（需求开发缺陷注入率RD_DIR）监控

    使用Minitab中RD_DIR回归公式预测RD_DIR的预测值、上限值和下限值，预测结果定义为三角分布。

⑵、缺陷移除率（需求阶段缺陷移除率RR_DRR）监控

    使用Minitab中RR_Defect回归模型（根据之前选定的分组选择回归模型）来预测RR_Defect的预测值、上限值和下限值

3.3、子过程性能监控

⑴、具备子过程能力和性能稳定描述

   在过程性能监控的控制图中，活动的能力线在能力基线范围内容，能力基线（蓝色线）在红色规格基线范围内，活动的点不能连续上升、偏于中心线某一侧。

⑵、过程能力不足/超出和不稳定的处理方式

    例一：

  如上图所示，第二次设计评审后，评审的缺陷移除率的自然能力上限超出规格上限，并且波动较大，说明该过程的能力不足。经根因分析，原因及解决措施如下：

    ①．原因及异常说明

   本应参与第二次评审的吴JF因出差，未能按期参与评审。此次评审中由外项目组李BX做为专家来代替，由于李BX对项目背景不熟悉，自然能力上下限超出规格限。

   ②．应对措施

   与公司相关领导及项目管理部门联系后，在后续的评审中让吴JF参与。同时提前与吴JF本人沟通确认，保证她按时参与其后的设计评审。

   ③．实施效果

   通过对后续评审的持续过程跟踪，自然能力限收窄，且达到规格限要求，项目QPPO达成率大于95%。

    例二：

  如上图所示，第3轮单元测试后发现缺陷移除率自然能力线下限超出规格线下限。经根因分析，执行了Car，原因及解决措施如下：

    ①．原因及异常说明

   使用PPB与PPM进行分析，测试用例覆盖率及测试工作量投入都正常，通过调整模型因子无法提高过程能力。经原因分析发现是测试用例质量不高，而导致过程能力不足。

   ②．应对措施

   执行CAR，识别本原因并加以解决。详见：本项目原因分析与解决记录。

    ③．实施效果

   执行CAR后，UT过程能力得到提升，项目QPPO可以达成。

  ④．固化措施

   向EPG提出改进建议：单元测试用例的质量对于单元测试过程至关重要，因此要加强单元测试用例的评审。

3.4、量化项目管理问题

⑴、子过程数据不充分

    在量化监控子过程过程中，技术评审、测试次数过少，例如只有3、4次。

    这样的数据量，在使用控制图模型时，无法满足使用条件，也很难起到监控子过程的目的。

⑵、度量数据不真实

    在精细化管理中，缺陷、工作成果度量是重叠的，而精细化管理中涉及到绩效考核，这样，在考核与项目冲突的情况下，往往会出现不真实反映项目情况的数据，为此，需要项目经理的智慧来解决这些问题，掌握好双刃剑的度。

3.5、根因分析

⑴、触发条件（入口准则）

   在量化分析子过程过程中，发生未达能力问题时，在调整因子或优化路径情况下，无法达成QPPO，则根据体系文件《原因分析与解决过程》所规定的入口准则，启动根因分析，由项目经理编制根因分析实施计划。

   工作中，发生计划等活动中未预测到的事件（问题或好的方法），触发根因分析，根因分析要使用预测模型。

⑵、过程

   ①．确定原因分析的范围

   ②．分析原因，确定建议的改进措施

   项目组（经理）组织项目相关人员，同样采用鱼骨图（鱼骨图至少应分解到第三层）和Pareto图等技术，分析问题和缺陷的根本原因，并制定改进措施。

   ③．制定行动计划

   项目经理制定计划，经EPG批准后执行。

   ④．实施改进建议

   项目组（经理）组织项目相关人员，在项目级QA的指导下，执行项目改进措施及建议。

    ⑤．评价实施效果

⑶、根因分析实践

   对项目单元测试过程进行分析，分析单元测试缺陷移除率低的原因，并制定改进实施方案。

   ①．要因分析：

  对输入、工具、人员、管理、过程、环境等原因，逐级深化分析，根因分析目标就是鱼头（UT_DRR低，单元测试缺陷移除率低的问题）。

   ②．做Pareto分析图表

   按二八原则，80%的问题是由于20%原因造成的，选出20%的问题进行改进方案。
   ③．应对措施

    改进实施方案如下：

   ●方案目标 

    通过改进方案的实施：

• 经过单元测试用例的重新梳理及测试用例评审提高单元测试用例的质量；
• 通过重新测试保证测试的充分性，提高代码质量。

    ●活动名称

• 重新整理单元测试用例
• 单元测试用例评审
• 对单元测试缺陷移除率低的模块进行重新测试，并对后续模块进行测试
• 跟踪执行效果
• 进行效果评价

4、总结

4.1、访谈实录点滴

    在访谈中，Henry问：项目级QA审计很多（在各个阶段的结束、里程碑、评审），为什么没有发现重大的不符合项，仅仅是少量小问题呢？

    我的回答如下：

    在项目级QA协助下，从CMMI3级开始，项目严格按体系文件执行，经历了多年的CMMI4、CMMI5试点，项目管理持续改进，开发过程基本稳定，所以，QA很难发现不符合项。

    访谈预发布中，Henry给出的意见，对我触动较大的有三条：

    ①．蒙特卡洛模拟预测模型置信度为66%，那么预测目标达成率再高，也存在35%的系统误差；

    ②．项目经理对组织级和项目级QPPO关系认识不清，建议由项目经理负责制定项目级QPPO，由组织级进行审批；

    ③．项目经理需掌握项目过程监控技术技能，例如：如何使用控制图监控过程稳定、监控过程能力。

4.2、结论

    在项目管理过程中，被动的接受QPPO，按体系文件执行，忽略了对项目管理本质的思考，也忽略了对CMMI高成熟度在项目管理中的作用的思考。仅仅做到执行是远远不够的，需要项目经理对体系更多的贡献，贡献度量数据、经验教训、过程改进建议是基本，更需要项目经理与EPG互动起来，为PPM、过程改进也有所贡献。

    ①．项目经理需要掌握数理统计技能，例如能灵活使用统计过程控制技术、蒙特卡洛模拟预测技术；

    ②．在CMMI4级后，引入了量化管理，使项目管理目标可以预测，过程可以控制。对于量化管理模型（PPM），仍需持续改进；

    ③．项目经理要积极与EPG互动，带领项目团队按体系文件重复执行项目过程，积累有效数据才能优化模型。

    总之， CMMI的成熟度，很大程度还是依赖于人，人员的稳定、能力持续成长是很关键的。工具、方法是在人的使用、分析下才有意义。一句话，提高薪酬待遇，促进团队健康成长、发展，也是CMMI的关键点。

    由于作者水平有限，欢迎网友、同行反馈意见。