-举重
软件项目量化管理
（
QPM
）
及根因分析实践总结
（
CMMI
高成熟度访谈）
关于实践
CMMI
高成熟度等级的实践步骤
1.
识别能够支持企业业务目标和改进过程和机会
清楚的定义企业的战略计划和执行过程
通过使用
QFD
或者过程目标组合矩阵，识别增值最大的改进
过程和机会
定义组织，职能和项目的平衡积分卡
(
前导和后导过程
)
开发度量框架
(
不同等级
< br>-
前导和后导过程
)
定义项目的
PPB
，选择稳定项目定义组织
PPB
根据需要定义
PPM
过程性能模型
识别在项目级和组织级定义需要进行统计学控制的改进过程
定义高成熟度的过程
2.
组织机构调整
使用业务目标的仪表板来重新审视过程
对于
EPG
组的过程顾问最好是
6S
igma
的绿带或黑带，对
SPC
有深
入理解
给管理者和项目团队进行统计学知识和量化管理的培训
(SPC,ANOVA,
回归
,CB<
/p>
工具
)
2.
对工具的需求和掌握
MindManager
-
系统思维，头脑风暴和
知识管理
Minitab
-
必须的工具
开发
PPB
和建立
PPM
< br>模型
过程的稳定性和性能分析
相关性分析，正态检验，回归和方差分析
SPC
统计过程控制
(
控制图
)
CrystalBall
-
水晶球，必须工具
使用蒙特卡洛分析和模拟来分析和预测项目性能
通过敏感性分析来来识别关键的
X
和
Y
<
/p>
使用精益
6Sigma
来实现价值再造<
/p>
通过
Wh
at
-
if
分析来匹配目标和过程要素
间关系
3.
对知识的需求和掌握
正态性检验和假设检验
-
必须
方差分析和卡方分析
(ANOVA,Chi
-
Square)
-
必须<
/p>
多元和一元回归分析，相关性分析
-<
/p>
必须
SPC
统
计过程控制
(
特殊原因和一般原因，
I
-
MR
控制图，
X
-
bar
图，过程稳定，异常判定
)
蒙特卡洛技术
-
必须
平衡计分卡和
6Sigma
-
高成熟度等级必须
4.
高成熟度等级的一些关键点
项目内的过程或子过程是否是稳定的？项目是否建立了自己的
PPB
和
UCL
和
L
CL
数据？
Y=f(x1,x2,x
3)
因此不是对
Y
直接去控制，要达到
目标
Y
要对
x
进行控制，
x
要是稳定的。
由于
x
之间也存在相互的作用和影响，得到了<
/p>
PPM
模型后根据目标
Y
做
what
-
if
分析，不断的调整。
x
-
bar
图和
I
-
MR
图如何应用的问题，
I
-
MR
是单组，数据要能够很好的体现时间序列。
1
不建议对
< br>EV
挣值，工作量偏差，进度等进行控制图管理。
在建立
PPB
的时候要注意区分，不同类型
的项目或生命周期模型需要建立不同的
PPB
。
项目自身过程稳定才能够作为样本去建立组织级的
P
PB
。
PCB
和
PPB
的概念要区分清楚
,PCB
是期望而
PPB
是实际能达到的范围。
---------------------------
--------------------------------------------------
--------------------------------------------------
----------------------
1
、前言
软件项
目量化管理是
CMMI
高成熟度的标志，也是项目管理及软件工
程的难点。本人做为项目经理，在
CMMI4
和
5
的试点和实施过程中，体会到量化管理是上述高成熟度项目管理的核心。本文
重点是量化管理
应用的实践，介绍量化管理主要概念和进行量化管理的过程。
在整个项目管理知识体系中，涉及到需要量化管理的领域非常
多。一般依据事前估算（预测）
、事中控
制和事后管理的角度来
分，可以分为估算（预测）
、过程控制和度量等，并据此调整工作量和工作计划，形
成闭环循环过程。
其实，
量化管理的数据内容很多，本文的实践，核心量化数据是工作量、工作成果（例如：
KL
OC
）和缺
陷数，相关的还有人员能力、评审
< br>/
测试次数等基础数据，由于篇幅有限，数据的度量、人员能力评价等内
容省略；关键过程域中管理工作内容实践的有：项目策划中的项目估算，量化管理及原因分析两个
部分。
1.1
、
CMMI
概述
CMMI
是
Capacity
MaturityModelIntegrated
的简称，即集成的
软件能力成熟度模型，是一种综合性模型，
它是工程实施和管理方法，它在软件与系统集
成以外的如科研、工程等领域都得到了广泛的应用。
<
/p>
CMMI
将软件过程中的很多过程都通过过程工程规范起来，它给
出了过程改进的模型和大框架。
CMMI
给我们带来了如下好处：改进项目进度和预算的可预测性、改进监控项目过程
及子过程的性能和稳
定性、改进开发周期、提高生产率、改进质量、增加客户的满意度、
提高员工的士气、增加投资回报和低
质量成本。
1.2
、
CMMI
高成熟度
⑴、
CMMI
高成熟度定义
①．
ML4
量化管理级（
Quantitative
Management
）
组织过程性
能
OPP
（
Organization
al Process Performance
）
量化项目管理
QPM
（
Quantitative Project
Management
）
②．
ML5
优化级（
Optimizing
）
原因分析
与解决方案
CAR
（
Causal
Analysis and Resolution
）
组织革新与部署
OID
（
Organizational Innovation and Deployment
）
⑵、高成熟度常用技术
①．统计过程控制技术
统计过
程控制（简称
SPC)
是应用统计技术对过程中的各个阶段进行
评估和监控，建立并保持过程处于可
接受的且稳定的水平，从而保证产品质量要求的一种
质量管理技术。
统计过程控制是过程控制的一部分
，从内容上说主要是有两个方面：
一是利用控制图分析过程的稳定性
，对过程存在的异常因素进行预警；
二是计
算过程能力指数分析稳定的过程能力满足技术要求的程度，对过程质量进行评价。
在这里，统计过程控制技术使用了控制图、直方图、排列图（柏拉图）等。
< br>
②．蒙特卡洛分析技术
蒙特卡罗法（
Monte
Carlo
Simulation
）也称随机模拟，它主要依据概率分布对
随机变量进行抽样，然后
将样本带入数学模型进行计算得到应变量。虽然蒙特卡罗模拟技
术只给出的是统计估计而非精确的结果，
但它对问题的维数不敏感，对求解对象是线性问
题与否也没有原则性要求，因此在复杂系统的不确定分析
中，蒙特卡罗方法成为不可或缺
的手段。而且对于那些无法得到解析结果的复杂问题来说，这种手段可能
是唯一有效的结
果。
2
⑶、高成熟度模型
①．量化管理
②．优化级
● CAR
PPB
、
PPM
为组织级原因分析，提供识别缺陷和问题的参考
可用于评价组织
CAR
改进效果
用以分析、选择改进措施与活动。
● OID
PPB
、
PPM
为组织
OID
识别革新提供参考
用以估计、分析组织改进活
动的效果，以预测是否过程性能是否达成目标
1.3
、项目经理高成熟度工作与软件工程
与量化管理的关键过程域有：
P
P
、
MA
、
P
MC
、
IPM
，如下图所示。
⑴、度量（
MA<
/p>
）为
QPM
提供的数据
< br>
度量数据来源于度量数据库和里程碑报告。
3
①．各个阶段及活动工作量度量数据
如此表所示，工作量数据包括工程活动和质量控制活动两部
分，其中，实际工作量包括正常开发和返工两
部分。
②．质量控制度量数据
各个阶段和工程活动的质量活动基础：
KLOC
（千代码行）
各个阶段和工程活动所产生的缺陷数和缺陷移除数
⑵、项目策划为
QPM
提供的数据
①．质量目标是通过项目实施计划下达
②．数据及过程
估算报告提供估算的工程工作量
项目定义过程提供裁剪的过程
2
、软件项目规模及工作量估算
2.1
、工作量估算依据
工作量估算主要是考虑使用组织级的资产库和历史数据，例如依据
“
过程裁剪指南
”
所形成的开发过程定<
/p>
义（
PDP
）
、
“
软件生命周期指南
”
所选定的软件生命周期、
“
度量数据库
”
中的缺陷数、文档的页码、代码行。
度量数据库的使用，就是参考相当规模的项目，获取文档页码、缺陷注入率、缺陷移除率、工
作量等度
量数据。
估算方
法有：专家法（
Delphi
）
、功能
点法、类比法、占比等。
2.2
、任务分解
< br>⑴、
WBS
分解分类及分解准则
①．
WBS
分解分类：项目分解
WBS
（项目管理类型任务分解）
、技术分解
WBS
（项目工程任务及特有技
术工作内容
分解）
。
< br>②．
WBS
分解原则：
项目要求；
定义逐步求精；
人时（工作量）
：一般的任务不超过
2
周，也就是
80
人时；
任务责任到人；
团队工作原则：项目
经理在制定项目计划过程中，尤其是在任务分解，工期估计对关键过程中一定要与项
目成
员一起进行。
⑵、任务分解
首先，跟踪任务分解模版，分别定义项目工程活动、项目管理活动、项目支持活动三部分；<
/p>
项目工程活动按本项目实践的瀑布模型生命周期和
PDP
，主要定义如下：需求开发、需求评审、软件设
计、设计评审、编码与测试、代码走查、单元测试、集成测试、系统测试、项目验收等活动。其中，编码
与测试中编码细活动，是根据项目实际情况和前期需求，分解到具体功能模块（树状结构）<
/p>
；
项目管理活动分解活动如下：项目
立项、项目策划、周报例会、项目结项、其他项目管理活动（例如：
需求管理、量化管理
等）
、项目度量；
项目支持活动分解为配置管理和质量保证两类活动。
4
2.3
、项目估算
⑴、编码部分估算
编码部
分估算，主要是在软件功能分解的基础上，对各个功能模块代码量进行估算，估算单位是
KLoc
。
本文是采用专家法进行估算编码工作量，由于部分功
能估算估算偏差超出额定偏差（本项目定义为
20%
）
，
进行了第二轮估算超出的功能模块，如下图所示：
⑵、工作规模估算
其他工
程活动，例如需求开发中的需求分析活动，按输出产品规模进行估算，也就是页数（文档按标准
< br>模版编写，已经定义好的格式）
，如下图所示。而相关的工作量按估算模型折算为
工作量。
⑶、项目管理、支持活动按占比为：项目管理
10
～
15%
，预留
5%
，<
/p>
QA%5
～
6
、
CM3
～
4%
。
3
、软
件项目量化管理（
QPM
）及根因分析实践
项目经理在项目级
QA
协助下，制定项目的质量目标，根据组织过程性能基线和模型裁剪项目过程，并对
项目进行实时量化的监控，确定项目定义过程，选择度量和统计技术，对监控过程中发现的问题分析 ，确
定并采取纠正措施。
3.1
、量化管理计划建立过程
项目经理在项目级
QA
协助下，
制定量化项目管理计划，
计划中包括：<
/p>
过程性能目标、
项目子过程
（选择）
、
量化管理技术、子过程路径、量化管理方案。
5
⑴、制定项目质量和过程性能目标
目标实现概率在
95%
以上
客户要求目标：交付缺陷小于
23
个（
0.139
Defects/KLOC
）
;
公司要求目标：工作量小于
589
人天（<
/p>
3.57 Man
-
days/KLOC
）
经
营管理部依据内外部对项目的要求下达质量目标，
定义到量化项目管理计划及监控报告的
过程性能目标
中。
如果目标存在冲突，解决方案如下：
若
QPPO
达成率在
90
-
95
%
之间，
则将其纳入风险进行监控与管理
若<
/p>
QPPO
达成率
< 90% ,
则与管理层进行谈判、沟通，是否可以降低目标
，如果降低，则重新进行
QPPO
达
成
率预测；否则则接受，并纳入风险进行监控。
⑵、项目子过程定义及选择
<
/p>
项目经理在项目级
QA
协助下，按过程工
程与质量相关性进行分析，复用公司分析经验，以及项目的特征
值，并根据《组织过程裁
剪指南》进行裁剪，来确定项目子过程。主要子过程有：需求开发、需求评审、
软件设计
、设计评审等
10
个子过程。
子过程选择标准
:
< br>与项目的
QPPO
具有强相关性（是有大的贡献）且是稳
定的；
子过程的一个或多个属性是
P
PM
中的控制因子；
子过程可被重复
和频繁地执行，且可以为统计管理它们提供充足数据。
⑶、确定量化管理技术
量化管理技术有：
统计过程控制技术
（控制图
、
三角分布等）
、
蒙特卡洛分析技术、
多目标决策分析技术。
⑷、预测过程及子过程选择
6
⑸、量化管理方案决策选择
过程组合分析（
Optques
t
）分别以交付质量最高、工作量最少为目标进行多目标决策分析，两个方案交付
质量都可满足项目的
QPPO
（置信度大于<
/p>
95%
）
，通过综合分析，选择工作量最
少的方案和过程及子过程选
择。
⑹、蒙特卡罗方法（
Monte Carlo
< br>，
MC
）及目标优化组合（
Op
tQuest
）分析结果
3.2
、过程监控
< br>⑴、缺陷注入率（需求开发缺陷注入率
RD_DIR
）监
控
使用
Minitab
中
RD_DIR
回
归公式预测
RD_DIR
的预测值、上限值和下限值，预测结果
定义为三角分布。
⑵、缺陷移除率（需求阶段缺陷移除率
RR_DRR
）监控
使用
Minitab
中
RR_Defect
回归模型（根据之前选定的分组选择回归模型）来预测
RR_Defect
的预测值、
上限值和下限值
3.3
、子过程性能监控
⑴、具备子过程能力和性能稳定描述
在过程性能监控的控制图中，活动的能力线在能力基线范围内容，能力基线（蓝色线）在
红色规格基线范
围内，活动的点不能连续上升、偏于中心线某一侧。
⑵、过程能力不足
/
超出和不稳定的处理方式
例一：
如上图所示，第二次设计评审后，评审的缺陷移除率的自然能力上限超出规格上限，并且
波动较大，说明
该过程的能力不足。经根因分析，原因及解决措施如下：
①．原因及异常说明
本应参与第二次评审的吴
JF
因出差，未能按期
参与评审。此次评审中由外项目组李
BX
做为专家来代替，
由于李
BX
对项目背景不熟悉，自然能力上
下限超出规格限。
②．应对措施
与公司相关领导及项目管理部门联系后，在后续的评审中让吴
JF
参与。同时提前与吴
JF
本人沟通确认，
保证她按时参与其后的设计评审。
③．实施效果
7
通过对后续评审的持续过程跟踪，自然能力限收窄，且达
到规格限要求，项目
QPPO
达成率大于
95%
。
例二：
如上图所示，
第
3
轮单元测试后发现缺陷移除率自然能力线下限超出规格线下限。
经根因分析，
执行了
Car
，
原因
及解决措施如下：
①．原因及异常说明
使用
PPB
与
PPM<
/p>
进行分析，测试用例覆盖率及测试工作量投入都正常，通过调整模型因子无法提高过程
能力。经原因分析发现是测试用例质量不高，而导致过程能力不足。
②．应对措施
执行
CAR
，识别本原因并加以解决。详见：本项目原因分析与解决记录。
③．实施效果
执行
CAR
后，
UT
过程能力得到提升，项目
QPPO
可以达成。<
/p>
④．固化措施
向
EPG
提出改进建议：
单元
测试用例的质量对于单元测试过程至关重要，
因此要加强单元测试用例的评审。
3.4
、量化项目管理问题
⑴、子过程数据不充分
在量化监控子过程过程中，技术评
审、测试次数过少，例如只有
3
、
4<
/p>
次。
这样的数据量，在使用控制图模型
时，无法满足使用条件，也很难起到监控子过程的目的。
⑵、度量数据不真实
在精细
化管理中，缺陷、工作成果度量是重叠的，而精细化管理中涉及到绩效考核，这样，在考核与项
< br>目冲突的情况下，往往会出现不真实反映项目情况的数据，为此，需要项目经理的智慧来解决这些问题，< /p>
掌握好双刃剑的度。
3.5
、根因分析
⑴、触发条件（入口准则）
<
/p>
在量化分析子过程过程中，发生未达能力问题时，在调整因子或优化路径情况下，无法达成
QPPO
，则根
据体系文件《原因分析
与解决过程》所规定的入口准则，启动根因分析，由项目经理编制根因分析实施计
划。<
/p>
工作中，发生计划等活动中未预
测到的事件（问题或好的方法）
，触发根因分析，根因分析要使用预测模
型。
⑵、过程
①．确定原因分析的范围
②．分析原因，确定建议的改进措施
项目组（经理）组织项目相关人员，同样采用鱼骨图（鱼骨图至少应分解到第三层）和<
/p>
Pareto
图等技术，
分析问题和缺陷
的根本原因，并制定改进措施。
③．制定行动计划
8
项目经理制定计划，经
EPG<
/p>
批准后执行。
④．实施改进建议
项目组（经理）组织项目相关人员，在项目级
QA
的指导下，执行项目改进措施及建议。
⑤．评价实施效果
⑶、根因分析实践
对项目单元测试过程进行分析，分析单元测试缺陷移除率低的原因，并制定改进实施方案。
①．要因分析：
对输入、工具、人员、管理、过程、环境等原因，逐级深化
分析，根因分析目标就是鱼头（
UT_DRR
低，
单元测试缺陷移除率低的问题）
。
②．做
Pareto
分析图表
9
按二八原则，
80%
的问题是由于
20%
原
因造成的，选出
20%
的问题进行改进方案。
< br>
③．应对措施
改进实施方案如下：
●
方案目标
通过改进方案的实施：
经过单元测试用例的重新梳理及测试用例评审提高单元测试用例的质量；
通过重新测试保证测试的充分性，提高代码质量。
●
活动名称
重新整理单元测试用例
单元测试用例评审
对单元测试缺陷移
除率低的模块进行重新测试，并对后续模块进行测试
跟踪执行效果
进行效果评价
4
、总结
4.1
、访谈实录点滴
10
在访谈中，
Henry
问：项目级
QA
审计很多（在各个阶段的结束、里程碑、评审）
，为什么没有发现重大
的不符合项，仅仅是少量小问题呢？
我的回答如下：
在项目级
QA
协助下，
从
CMMI3
级开始，
项目严格按体系文
件执行，
经历了多年的
CMMI4
、<
/p>
CMMI5
试点，
项目管理持续改进，开
发过程基本稳定，所以，
QA
很难发现不符合项。
访谈预发布中，
Henry
给出的意见，对我触动较大的有三条：
①．蒙特卡洛模拟预测模型置信
度为
66%
，那么预测目标达成率再高，也存在
35%
的系统误差；
②．项目经理对组织级和项目级
QPPO
关系认识不清，建议由项目经理负责制定项目级
QPPO
，由
组织级
进行审批；
③．项目经理需掌握项目过程监控技术技能，例如：如何使用控制图监控过程稳定、监控过程能力
。
4.2
、结论
在项目管理过程中，被动的接受
QPPO
，
按体系文件执行，忽略了对项目管理本质的思考，也忽略了对
CMMI
< br>高成熟度在项目管理中的作用的思考。
仅仅做到执行是远远不够的，
需要项目经理对体系更多的贡献，
贡献度量数据、经验教训、过程改进建议是
基本，更需要项目经理与
EPG
互动起来，为
< br>PPM
、过程改进也
有所贡献。
①．
项目经理需要掌握数理统计技能，例如能灵活使用统计过程控制技术、蒙特卡洛模拟预测技术；
< br>
②．
在
CMMI4
级后，
引入了量化管理，
使项目管理目标可以预测，
过程可以控制。
对于量化管
理模型
（
PPM
）
，
仍需持续改进；
③．项目经理要积极与
EPG
互动，带领项
目团队按体系文件重复执行项目过程，积累有效数据才能优化
模型。
总之，
CMMI
的成熟度，很大程度还是依赖于人，人员的稳定、能力持续成长是很关键的。工具、方法
是在人的使用、分析下才有意义。一句话，提高薪酬待遇，促进团队健康成长、发展，也是
< br>CMMI
的关键
点。
由于作者水平有限，欢迎网友、同行反馈意见。
能力成熟度模型集成（
CMMI
）术语
1 AC
或
ACWP
：
已经完成工作量的实际成本。
Actual Cost of
Work Performed
，已完成工作的实际成本
——<
/p>
实际成本（工作
量）
，显示到项目状态日
期或当前日期为止，与某任务的已完成工作所对应的实际成本。
2 BAC
：
完成预算
3 Baseline
：
配置管理术语，基线。基线包括如下属性：
1
）是一系列工作产品的集合；
2
）是项目最新工作产品的
断面或快照；
3
）基线一旦发布，即成为
“
冻结
”
状态，不可随意修改；
4
）组成基线的配置项发生变更，需要执行正式的变更管理流程
。
4
BCWP
：
Budget Cost of Work Performed
，已完成工作的预算成本
—
实际计划成本（工作量）
，到状态日期或当前
日期为止，任务、资源或工作分配的完成百分比乘以时间分段的比较基准成本后、再进行累计得到的值。
5 BCWS
：
Budget
Cost
of
Work
Scheduled
，计划完成工作
的预算成本
—
计划成本（工作量）
<
/p>
，到状态日期或当前
日期为止，时间分段比较基准成本的累计值。
11
6
CA
：
Customer
Acceptance
，客户验收
7
CAR
：
Causal Analysis and
Resolution
，原因分析与解决
8
CCB
：
Change Control
Board
，变更控制委员会
9
CI
：
Configuration
Item
，配置项
10
CI
：
Coding and
Integration
，项目阶段之实现与集成阶段
11
CL
：
Checklist,
检查表
12
CM
：
Configuration Management
（
Engineer
）
，配置管理（工程师）<
/p>
13
CMMI
：
Capability Maturity Model
Integration
，能力成熟度模型集成
14
CPI
：
Cost Performance Index
，成本性能指
标，显示到项目的状态日期或当前日期为止，已完成工时的预算（或
比较基准）成本与已
完成工时的实际成本之间的比值
15
CT
：
Coding and
Testing,
编码与单元测试阶段
16
CV
：
Cost Variation
，成本偏差，显示到状态日期或
当前日期为止，为达到当前的完成程度应花费的成本与实际
花费的成本之间的差异
17
CV%
：
Cost Variation Percentage
，
成本偏差率，
示成本差异
CV
与已完成工时的预算成本
BCWP
的比值，
以百分比
表示。该值指示到状态日期或当前日期为止，为达到当前完成程
度应当花费的成本与实际已花费的成本之
间的差异。
18
DAR
：
Decision Analysis and
Resolution
，决策分析与解决方案
19
DD
：
Detail
Design
，详细设计
20
DEV
：
Develop
Process,
软件开发过程组
21
EAC
：
完工估算
22
ECF
：
Environmental Complexity
Factor
，环境复杂度因素
23
EPG
：
Engineering Process Group
，
工程过程组，
支持组织流程建设以及参与组织过程的改进工作，
该组介于战略
和战术之间，更多支持战术层工作。
< br>
24
EV
：
已经完成工作量的预算成本，
已完工作量的预算成本
(BCWP)
，
即
(Bu
dgeted Cost for Work Performed)
。
或称
挣值、盈值和挣得值。
12
25
EX
：
Example,
例子
26
FP
：
Function
Point
，功能点
27
GL
：
Guide Line,
指南
28 HLD
：
High Level
Design
，概要设计
29
HR
：
Human Resource
，人力资源
(
部门
)
30 IT
：
Implementation and
Test
，实现与测试
31
IT
：
Integration
test,
集成测试
32
KLOC
：
Thousand lines of
code
，千行代码
33
LC
：
Life Cycle
，生命周期
34 MA
：
Measurement and
Analysis
，度量分析
35
MR
：
Management
review,
管理评审
36
MSG
：
Management Steering
Group
，管理督导组
37
NC
：
Non
-
conformance,
不符合项
38
OMR
：
Organization's Measurement
Repository
，组织度量库
39 OPA
：
Organization's Process A
ssets
（
Library
）
，组织过程资产
（库）
40
OPD
：
Organizational Process
Definition
，组织过程定义
41 OPM
：
Organizational Process
Management
，组织过程管理
42 ORG
：
Organizational
Process,
组织制度过程组
43 OSSP
：
Organization's Set of
Standard Process
，组织标准过程集
44 OT
：
Organizational
Training
，组织培训
45
PA
：
Process Areas
，过程域
46 PAM
：
13
Project acceptance
management
，项目验收管理
47 PAT
：
Process
Action
Team
，
过程行动组
48
PC
：
Project
Closure
，项目阶段之项目结项阶段
49 PD
：
立项
50 PDP
：
Project
Defined Process
项目定义过程
51
PERT
：
三点估算法。
52
PI
：
Process
Improvement
，过程改进
53 PI
：
Procedure
Instruction
，规程
54
PI
：
Product
Integration
，产品集成
55 Pilot
：
Project
Pilot
，项目阶段之项目试点阶段
56 PM
：
Project
Manager
，项目经理
57
PM
：
Project Manage
Process,
项目管理过程组
58 PMC
：
Project Monitoring And
Control
，项目监督与控制
59 PMO
：
Project Management
Office
，项目管理办公室
60
PO
：
项目结项
61
PP
：
Project Plan
，项目计划
,
项目策划阶段
62
PPQA
：
Process and Product Quality
Assurance
，过程及产品质量保证
63 PS
：
Project Startup
，项目阶段之项目启动阶段
Process,
过程
64 PV
：
计划工作量的预算成本，
BC
WS
是指项目实施过程中某阶段计划要求完成的工作量所需的预算费用。计算
公式为：
BCWS=
计划工作量
< br>×
预算定额。
BCWS
主要是反
映进度计划应当完成的工作量
(
用费用表示
)
。
65
QA
：
Quality Assurance
（
Enginee
）
，质量保证（工程师）
66 QC
：
Quality
Control,
质量控制
67
RD
：
Requirement Development
，需求开发
或项目阶段之需求开发阶段。
14
68 RDM
：
Requirement Development
and Management
，需求开发管理
69 REF
：
Reference,
参考
70 REQM
：
Requirement
Management
，需求管理
71 RM
：
Requirement
Management
，需求管理
72 RSKM
：
Risk
Management
，风险管理
73 SAM
：
Project monitoring and
control
，供应商协议管理，采购。
74 SD
：
System
Design
，项目阶段之系统设计阶段。
75 SM
：
Service and
Maintenance
，服务与维护
76 SOP
：
Standard Operation
Process,
标准作业流程
77
SPI
：
Software Process
Improvement
，软件过程改进
78 SPI
：
Schedule Performance Ind
ex
，进度性能指标，已完成工作量的预算成本与计划工作量的预算成本之间的比
值（
BCWP/BCWS
）
< br>。
SPI
常用于估算项目的完成日期
79
Sponsor
：
过程改进发起人
80
SRS
：
Software Requirement
Specification
，软件需求说明书
81 ST
：
System
Test
，系统测试或项目阶段之系统测试阶段
82 ST
：
Standard,
标准
83 SUPPORT
：
Support
Process,
支持过程组
84
SV
：
Schedule Variation
，进度偏差，显示到状
态日期或当前日期为止，某项任务、某资源的所有分配任务或某
项工作分配的当前进度与
比较基准计划之间的成本差异。可使用
SV
来检查成本，以确定任务或工作分配
是否按时进行。
85 SV%
：
Schedule
Variation
Percentage
< br>，进度偏差率，显示进度偏差
SV
与计划工时的预算成本
BCWS
之间的比值，
用百分比表示。
86
SWOT
分析法：
即自我诊断方法，
SWOT
四个英文字母代表<
/p>
Strength
，
Weakness<
/p>
，
Opportunity
，
Threat
。意思分别为：
S
< br>，
强项、优势；
W
，弱项、劣势
；
O
，机会、机遇；
T
，威胁、对手。
87
TCF
：
15
Technical Complexity
Factor
，技术复杂度因素
88
TP
：
Template,
模板
89 TR
：
Technical
review
，技术评审
90
UA
：
User
acceptance,
用户验收
91 UAW
：
Unadjusted Actor
Weight
，未调整角色因素值
92 UCL
：
Upper Control
limit
，控制上限，多个项目的最大值
93 UCP
：
Use Case
Point
，用例点
94
UI
：
User
Interface
，用户交互界面
95 UR
：
User
Requirement
，用户需求
96 UUCW
：
Unadjusted Use Case
Weight,
未调整用例因素值
97
不一致性问题：
文档、系统部分或部件间存在的不统一性、未标准化或
相互矛盾的问题。
98
测试策略：
测试策略描述测试工程的总体方法和目标。
描述目前在进行哪一阶段的测试
（单元测试、
集成测试、
系统
测试）以及每个阶段内在进行的测试种类（功能测试、性能测试、压力测试等）
。
99
测试度量指标：
为了判断测试的有效性，完整性，测试产品的质量，通常包括进度，成本，规模，效率，质量的度量 。
100
测试用例：
测试用例是针对一个特殊目标所设定的输入、执行条件和预期结果的集合。
101
产品质量：
项目组的工作产品及最终交付的产品是否符合既定的开
发规范，是否违背了一致性原则。
102
非正式同行评审：
评审方式比较随意，通过
Email
、现场讨论
的方式进行评审，尽早发现问题，并及时地解决问题；
103
风险：
不确定的事件，主要指可能造成损失的事件。
104
功能测试：
验证软件在指定的条件下使用时，软件产品提供满足规
定或隐含的需求功能的能力的测试类型。
105
管理评审：
管理评审是对工作产品进行的一种系统评估。
向上层管理者提供信息，
以帮助决策，
判定是否能够进入下
一个阶段。<
/p>
106
过程绩效：
过程绩效是对遵循某个过程所达到的实际结果的度量，
用过程度量值
（例如工作量、
时间间隔期、
缺陷清
除有效性等）和产品度量值（例如，可靠性和缺陷密度）予以表征。
107
过程质量：
项目组的活动是否符合公司既定的规范。如，公司的规
程、过程、方针等等。
16
108
回归测试：
软件经过了整理、修改、或者其环境发生变化进行的测试，其目的是检验对软件进行的修改是否正确。<
/p>
109
基线：
是由一个或多个配置项组成的逻辑实体，
并可以作为进一步开发的基础。
组成基线的配置项需要经过正式
的评审和批准、正式的变更控制规程。
110
技术编辑：
针对语法、拼写、模板的检查。
111
轮查：
一种评审方式，
通常由技术负
责人或项目经理召集，
一般三人以上参加。
目的在于通过对开发
人员的工作
产品的技术审查，提出改进意见
112
偏差：
相对于额定值、计划、标准、规程，或者被评审变量的
明显的偏移。
113
软件工作产品：
软件过程中产生的一切文件、文档、源代码等。
114
审查（
Inspection
）
：
一种评审方式，通常是由经过技术评审培训的项目经理或
PPQ
A
主持，规模在
3
< br>～
7
人之间为宜，一般在
完成了
一个工作产品后对其进行的评审
115
同行评审：
由作者的同行
（一个或几个同事）
对工作产品进行系统
性检查，
主要是技术的完整性和适宜性，
在本过程
文件中同行评审分为正式同行评审、非正式同行评审、走查；
116
系统测试：
系统测试是对已经集成好的软件系统进行全面的测试，
以验证软件系统的正确性和性能等满足其规约所指
定的要求。<
/p>
117
性能测试：
验证软件产品或系统是否在多用户并发以及大数据压力下能够满足预期的性能、效率指标的测试类型。<
/p>
118
正式同行评审：
最系统化、最严密的评审技术，被认为是最实用、最有效的评审方法，严格定义评审流程；
119
走查（
Wa
lkthrough
）
：
评审方式比较随意，
一个或几
个同事对工作产品进行相互交流，
尽早的发现问题；
审查的范围
根据需求的
优先级通常由管理人员来确定，主要是静态质量分析和编程规则检查。通常是
小型讨论会，一般是在工作
产品形成的早期进行，作者有一定的想法时，希望从中获得一
些帮助或补充一些想法。当然也可以在编制
工作产品的任何阶段进行，两三个人参加，由
作者主持，主要是评估和提高工作产品的质量
120
量化管理技术：
（
Satistical Technique
）采用以下技术对项目进行量化管理，统计过程控制技术
(SPC)
；蒙特卡洛模拟分析
技术
(Monte Carlo
Simulation)
；
多目标决策分析技术
(Crystal Ball OptQuest)
121
蒙特卡洛模拟：
蒙特卡洛
(Monte Ca
rlo)
模拟是一种通过设定随机过程，反复生成时间序列，计算参数估计量和统计量，
进
而研究其分布特征的方法。
122
OptQuest
：
Crystal Ball
的一个优化工具
,
能够引导自定义和参数设置过程
,
并以直观的图形显示结果。
123 Crystal
Ball
：
水晶球，计算机仿真工具。
124
需求稳定度：
需求稳定度
=
未变更需求数
/
现有需求总数
17
125
需求变化率：
需求变化率
=
需求变更总数
/
现有需求总数
126
缺陷注入率：
缺陷注入率（
Defects
/Kloc
）
=
当前阶段注入的缺陷数
/
软件规模
127
缺陷移除率：
缺陷移除率（
Defects
/Kloc
）
=
当前活动识别的缺陷数
/
软件规模
128
遗漏缺陷识别率
(%)
：
遗漏缺
陷识别率
(%)=
当前活动识别的缺陷数
/(
本阶段注入的缺陷数
+
上游阶段
遗漏的缺陷总数
)*100%
18
CMMI5
访谈学习笔记（项目经理角色）
在软件项目管理中，总是把估计值当作承诺，无论是对自
已或对同事，都会造成不必要的焦虑。为避免此
类困境，就算最后期限迫在眉睫，你也能
专注于该做的事。然而也应该做到随时沟通，让相关人员看到事
情进展。
项目管理过程方针：规范产品
/
项目立项和结项过程，制定合理的项目计划，并据此对项目进行跟踪，建
立对项目监控的可视性，使项目管理者能在项目执行明显偏离项目计划时及时采取有效的纠正
措施。
CMMI
由如下内容构成，组织级体系文件、工作指南、证据；在工作中处理问题原则，识别问题、跟踪问
题、解决问题、关闭问题。
一、关于访谈
1
、访谈问题类型及回答方法
提问类型有：如何（
How
）
、什么（
What
）
、分析、有没有、是否等类型。
回答方法有：
⑴、输入条件、前提
=>
过程描述
=>
输出产品
⑵、事前预测
=>
事中控制
=>
事后分析
⑶、制度（或体系）已经存在
=>
被使用
=>
被一致执行
=>
改进
，形成闭环
⑷、回答问题关键
词：依据软件开发过程体系文件（或指南）
、受过培训、经过评审、发布通知（例会、<
/p>
报给项目经理）
⑸、结合实际项目回答。
2
、访谈内容关键点
计划、评审、度量、量化管理、风险、决策分析。
⑴、量化分析技术
量化管理技术：统计过程控制技术、蒙特卡洛分析技术、
多目标决策分析技术
⑵、量化分析工具
MiniTab
、
CrystarBall
3
、什么是过程？
过程是为了达到特定目标所实施的一系统活动或步骤。一
个标准的过程应该包括：
目标
/
目的（
Purpose
）
< br>
角色与职责（
Role and
Responsibility
）
入口准则（
Entry
Criteria
）
出口准则（
Exit
Criteria
）
输入（
Inputs
）
输出
（
Outputs
）
流程图及活动说明（
Activities
）
度量（
Measures
）
验证（
Verificati
on
）
4
、过程域
⑴、项目管理主要
7
个过程域
19
⑵、基本项目管理过程域模型
⑶、高级项目管理过程域模型
20
5
、评审方法
在体系文件《技术评审过程》中定义了评审方法。
审查（
Inspection
）
< br>，通常是由经过技术评审培训的项目经理或
PPQA
主持
，规模在
3
～
7
人之间为宜，一般
在完成了一个工作产品后对其进行的评审
轮查（
EmailRouting
）<
/p>
，通常由技术负责人或项目经理召集，
一般三人以上参加。目的在
于通过对开发人员的
工作产品的技术审查，提出改进意见
走查
（
Walkthrough
）
，审查的范围根据需求的优先级通常由管理人员来确定，
主要是静态质量分析和编程规
则检查。通常是小型讨论会，一般是在工作产品形
成的早期进行，作者有一定的想法时，希望从中获得一
些帮助或补充一些想法。当然也可
以在编制工作产品的任何阶段进行，两三个人参加，由作者主持，主要
是评估和提高工作
产品的质量
二、准则、依据
1
、风险的管理策略：
a.
当风险系数
(
< br>高
)
在
16~25
之间，
必须制定应急计划，并且随时监控风险变化情况，
一旦风险发生，则立刻
启动应急计划。
b.
当风险系数
(
< br>中
)
在
9~15
之间，可不制定应急计划，定期监控风险变更情况，随时准备启动缓解措施。
c.
当风险系数
< br>(
低
)
在
1~8
之间，可不制定应急计划，定期监控风险变更情况，
必要时启动缓解措施。
注：对于部分低风险，可选择接受。
2
、项目
QPPO
下达：
经营管理部立项审批时下达，基于内部环
境
(
例如：基线
)
与外部环境
(
例如：客户要求
)<
/p>
的考虑，项目经理
在
QA
的协助下，预测项目
QPPO
达成率：
若
QPPO
达成率
〉
95
，则接受
若
QPPO
达成率在
90
-
95
之间，
则将其纳入风险进行监控与管理
若
QPPO
达成率
< 90 ,
则与管理层进行谈判、沟通，是否可以降低
目标，如果降低，则重新进行
QPPO
达
成率预测；否则则接受，并纳入风险进行监控
3
、评审通过准则：
21
评审出缺陷数满足要求。
4
、评审准则（以需求为例）
：
依据《技术评审检查列表》中
“
用户需求说明书检查单
”
，主要有：完
整性、一致性、描述清晰性等
9
项检
查
点。
5
、任务分解准则（
WBS
）
：
依据
《项目定义过程》
、
《项目估算报告》
、
《项目实施计划》
、
《项目进度计划模版》
等过程体系文件和指南，
任务分解准则如下：
⑴、
WBS
分解分类：项目分解
WBS
（项目管理类型任务分解）
、技术分解
WBS
（项目工程任务及特有技
术
工作内容分解）
。
⑵、
WBS
分解原则：
项目要求；
定义逐步求精；
人时（工作量）
：一般的任务不超过
2
周，也就是
80
人时；
任务责任到人；
团队工作原则：项目
经理在制定项目计划过程中，尤其是在任务分解，工期估计对关键过程中一定要与项
目成
员一起进行。
6
、评审员的选择准则：
在要评审的领域拥有丰富经验。
具备专业技术知识。
能够有效识别待评审工作产品中存在的缺陷。
7
、评审度量指标
评审活动的工时及工作量
评审发现的缺陷数（按严重程度及类型）
评审产品的规模
8
、项目经理技能
项目估算的能力
有较强的沟通协调能力
风险识别、分析、管理的能力
项目策划的能力
进度及预算编制的能力
项目监控与管理的能力
具体需求管理的能力
9
、基线、版本、存储的定义
基线：是由一个或多个配置项组成的逻辑实体，并可以作为进一步开发的基础。组成基线的配置
项需要经
过正式的评审和批准、正式的变更控制规程。通过评审的文档、开发文档，以及
通过测试的，例如：代码、
计划（策划阶段）
版本：
存储：工作记录，例如：会议纪要、报告
11
、项目级
Car
基本改进原则
：
项目执行中，当前性能目标无法达到现有组织过程性能。
项目执行中，出现的缺陷或问题等导致与当前组织过程绩效出现严重偏差，明显影响项目绩效
。
工作产品与需求出现明显的偏离。
12
、确定软件开发生命周期模型的参考规则
< br>
22
13
、完成里程碑成果的准则：
偏差不大于
20%
（项目可控）
交付产品通过审批或验证
里程碑内主要工作完成。
14
、软件项目风险管理规则
风险类别有：人员、客户、管理、质量、测试、环境等；
风险系数有：高、中、低；
风险发生
概率和风险影响范围分别
1
～
5
分。
三、项目策划实践
1
、项目策划实践过程简述
我在试点项目中的，策划过程如下图所示，其中包含过程
中的输入、输出，以及参与的角色。
23
2
、流程中关键点说明：
⑴、项目实施计划内容：
项目的章程、项目概况、项目组构成及人力资源计划、项
目预算及进度计划、干系人参与计划、其他下属
24
计划（度
量分析计划以及数据管理计划、项目监控计划、需求管理计划、决策分析计划、项目评审计划、
< br>承诺管理等子计划）
。
⑵、项目估算
a.
如何使用资产库和历史数据
？做估算、计划。
过程裁剪指南、软件生命周期指南、标准工
作环境指南、团队指南等、风险库；
开发过程定义（
PDP
）
生产率、估算模型、工作分配比例、人员技能水平。
b.
估算参数：代码行、页码、
缺陷密度；质量参数：缺陷清除率、缺陷数；
c.
文档（需求、设计等技术文档）是按类比法进行估算（页码）
，参考规定相当的度量库，再通过页数转换
为工作量（转换模型）
；
d.<
/p>
采用
Delphi
（专家法）估算代码行
数，额定偏差为
20%
；
e.
项目管理占比为
10
～
15%
，预留
5%
，
QA%5
～
6
、
CM3
～
4%
。
⑶、生命周期
< br>本项目采用瀑布模型，在需求比较明确、文档，复杂度较低情况下采用，思路、路径清晰，但是前期出现< /p>
的问题，在后期会方法；
需求阶段、
设计阶段、
编码及单元测试阶段、<
/p>
集成测试阶段、
系统测试阶段、
验收测试
阶段，
其中，
需求、
编码及单元测试、
系统测试、验收测试为里程碑。
⑷、估算成本、估算假设
估算成本由工作量（人工成本）
、差旅、采购等成本构成。
估算假设：
团队水平高于平均水平，包括环境、士气；
需求变更范围很小；
技术复杂度低。
Budget——
指标
/
人
天（成本）
⑸、进度计划
< br>任务分解（
WBS
）
-
>
网络图（前置、后期任务）
-
>
分配资源
-
>
估算任务（征询当事人的意见）
-
>
资源平衡
-
>
设定里程碑。<
/p>
⑹、人力资源计划
根据项目工期、工作量、沟通工作，按项目时间进度来安排项目人员进出。
识别项目需要技能、业务知识，例如此项目需要
Cordys<
/p>
平台开发技术；
根据人员技术，进行差
距分析，例如有部分人员缺乏
Cordys
平台开发技术；
根据差异制定培训计划。
⑺、软、硬件资源及其环境
组织级工作环境提供了标准办公环境，例如工作终端、配置库等；
项目特有环境，例如：开发服务器。
3
、关键过程举例说明
⑴、项目过程定义（过程剪裁）
在项目过程定义中，在项目级
Q
A
的协助下，参考《组织过程裁剪指南》和《软件生命周期》裁剪定制适
合于项目的生命周期模型，制定《项目定义过程》
。例如：接口设计过程，在项
目定义中剪裁到详细设计文
档中体现。
⑵、如何管理项目计划？
管理项目计划包括渐进明细维护项目计划，与组员及时沟通计划完成情况，以及通过周例会、
周报、报工
系统收集计划完成情况和进度，并通过挣值分析分析项目的偏差，也通过周例
会收集风险、问题，及时跟
25
踪；
通过挣值分析管理项目进度、成本偏差；
问题管理，识别问题、跟踪问题、关闭问题。
⑶、如何评价团队的有效性，如何构建项目团队的？
组织团队指南；
在项目启动时，项目通知中初步提供人员；
< br>按项目实施计划模版，制定人力资源计划，对人员进行分工（项目经理、开发人员、
QA
、
CM
）
。
⑷、什么地方记录了项目干系人，如何确保干系人参与有效？
在项目实施计划中干系人管理计划中，干系人沟通记录；
在与干系人沟通时，事前通知，事中控制、确认，事后分析。
⑸、项目关键依赖
依赖客户，需要客户提供需求和需求确认，以及系统部署
、验收测试。
四、量化管理及监控（
QPM
）实践
1
、度量点、统计技术的选择准则：
度量点选择准则：
（
1
）
与商业目标有关的度量点；
（
2
）
度量点能覆盖项目生命周期；
（
3
）
度量是能够被有效地正确地收集；
（
4
）
度量点是客观的；
（
5
）
度量点有足够的历史数据
;
（
6
）
通过改变过程或子过程，度量点是可控制的；
统计技术的选择准则：
（
1
）根据度量点的数据类型选择统计技术，
X/Y
都是连续型变量，则选择相关性分析和回归分析；
（
2
）根据度量点的单值性，选择单值
-
移动极差
I
-
MR
控制
图
.
2
、量化过程
⑴、量化执行过程图
量化优化路径说明：
⑵、
MiniTab
回归预测
在每个子过程的前后，都需要进行回归预测，例如需求评审前，预测需求评审缺陷移除率（<
/p>
RR_Defect
）是
否在基线范围内
（
PPB
-
PPM
）
，预测输入是：
（
RR_Size
）需求评审文档正
文页数（单位：页）
；
（
RR_Workload
）
需求评审投入工作量（单位：人天）
；
（
RR_TL
）
需求评审高级人员比例
26
⑶、蒙特卡洛模拟分析（水晶球）
在需求启动和各个子过程阶段后，使用
CB:OptQuest
，根据项目过程性能目标选择最佳的过程或子过程的
组合。选择
完之后将最佳方案的实现概率填写到
QPMPlan
中。
3
、量化管理结果达成规则（
QPPO
冲突）
达成概率
>95%
，接受
90—95%
，关注风险，有
10%
-
5%
的概率达不到
<90%
，协商（降低目标，不降低也只能接受，当风险管理）谈判
补充：
工作
量
（成本）
是限定条件，
量化管理就是
达成成本与质量的平衡，
综合考虑，
达到较好的性价比。
如果，不满足综合性价比，则可以进行决策分析。
4
、度量点在什么时候发生变化：
QPPO
发生变化，过程发生变
化，公司要求度量额外信息，导致度量点的变化，客户提出的要求（个性化
的要求，例如
非标准度量要求）
。
5
、过程性能监控
使用统计过程控制技术，对每一次评审的性能进行监控。
如果在子过程性能监控中发现过程不稳定时，需
要分析异常原因，并且采取纠正措施。<
/p>
过程性能
监控说明子过程稳定性和有能力规则如下：
不能超过上下限；
不能出现连续
7
个上升；
在规格线之间表示有能力。
6
、量化项目管理问题记录
需要仔细分析量化项目管理问题记录，包括原因及异常说
明、应对措施、实施效果、图表说明、固化措施
（提交到
EPG
）
，详细内容略。
7
、开发过程量化分析与评审过程量
化分析差异
⑴、预测缺陷注入
率
(RD_DIRSD_DIRCD_DIR)
在项目需求开发前获取
RD_E
ffort
和
RD_DE
，
使用
Minitab
中
R
D_DIR
回归公式预测
RD_DIR
的预测值、
上限
值和下限值，如果预测值不在基线范围内，则需
要调整
RD_Effort
和
RD_D
E
，并重新预测。将调整后的因子
和预测值填入需求开发前调整
列。把
RD_DIR
的最新预测值定义成三角分布。
27
⑵、评审过程使用
Minitab
线性回归预测
缺陷移除率（
DRR
）在
PPB
-
PPM
范围内
⑶、
五、原因分析与解决过程实践
1
、触发条件（入口准则）
在量化分析子过程过程中，发生未达能力问题时，在调整
因子或优化路径情况下，无法达成
QPPO
，则根
据体系文件《原因分析与解决过程》所规定的入口准则，启动根因分析，由项目经理编制根因分析实施
计
划。
工作中，发生计划等活动中未预测到的事件（问题或好的方法）
，触发根因分析，根因
分析要使用预测模
型。
2
、过程
⑴、确定原因分析的范围
⑵、分析原因，确定建议的改进措施
项目组（经理）组织项目相关人员，同样采用鱼骨图（鱼骨图至少应分解到第三层）和<
/p>
Pareto
图等技术，
分析问题和缺陷
的根本原因，并制定改进措施。
⑶、制定行动计划
项目经理制定计划，经
EPG
批准后执行。
⑷、实施改进建议
项目组（经理）组织项目相关人员，在项目级
QA
的指导下，执行项目改进措施及建议。
⑸、评价实施效果
3
、根因分析实践
对项目单元测试过程进行分析，分析单元测试缺陷移除率
低的原因，并制定改进实施方案。
⑴、要因分析：
28
对输入、工具、人员、管理、
过程、环境等原因，逐级深化分析，根因分析目标就是鱼头（
UT_DRR
低，
单元测试缺陷移除率低的问题）
。
⑵、做
Pareto
分析图表
按二八原则，
80%
的问题是由于
20%
原
因造成的，选出
20%
的问题进行改进方案。
< br>
⑶、应对方案
29
说明：
< br>AP
－
Action
Proposal
，行动方案；
H
－高，
M
－
中，
L
－低；
●
－实施，
○
－暂缓实施，
△
－
不实施
4
、改进实施方案
●
方案目标
通过改进方案的实施：
经过单元测试用例的重新梳理及测试用例评审提高单元测试用例的质量；
通过重新测试保证测试的充分性，提高代码质量。
●
活动名称
重新整理单元测试用例
单元测试用例评审
对单元测试缺陷移
除率低的模块进行重新测试，并对后续模块进行测试
跟踪执行效果
进行效果评价
5
、
CAR
实施效果评价报告
⑴、效果分析说明：
●
统计分析结果说明：通过本次
原因分析与解决工作的实施，改进前与改进后的
RR_DRR
改
进效果说明如
下：
●
分析结论：
如上图所示：
CAR
方案实施后，后续的单元测试模块过程过
程能力也得控制，稳定性也得到显著提高。
因此判定本次
CAR
的执行有效。
30
⑵、固化改进成果
单元测试用例的质
量对于单元测试过程至关重要，因此要加强单元测试用例的评审；
修改编码与测试过程，删除编码与测试过程中单元测试用例可不进行评审的描述。
六、决策分析过程实践
1
、输入：组织级过程体系文件《决策分析过程》
、
《决策分析指南》
入口准则：存在多个技术方案选择时
2
、决策准则
⑴、入口准则
全新标准产品立项时。
定制产品立项时。
存在多个技术方案选择时。
决定全新
开发、
复用还是采购商用组件时，
同时所做出的决定对项目的成
败或进度、
成本影响大于
50%
时。<
/p>
⑵、评估准则
评估准则选择，依据体系文件
中决策分析报告模版的
“
建议评估准则
”
。
3
、评估方法
此次（项目仅有一次）评估方法为专家打分法（
Delphi
）
。
评
估常用方法有：
SWOT
分析、头脑风暴法、决策树分析法。<
/p>
4
、候选方案列表
方案一：自主开发消息管理
方案二：采用第三方消息中间件（
IBM
MQ
）
5
、实施过程与计划
项目经理根据项目前期的需求和方案，识别出两套技术解
决方案，根据组织级过程体系文件《决策分析过
程》
、
《决策分析指南》和入口准则，编制
“
决策分析
计划
”
，计划内容包括（开始时间为
3
月
28
日）
：
决策问题描述：
制定决策分析计划：
成立决策小组：
小组由项目组成员、项目
QA
、项目经理构成；
建立评估准则：根据待决策问题的特征，确定明确的评估准则和评分标准，填
写评估准则列表；
识别候选方案：寻找潜在的候选解决方案，填写候选方案列表
确定评估方法：
评选候选方案：
31
完成决策分析：根据评估结果确定最终方案，填写决策分析报告。
6
、决策分析结果
根据两种方案评估结果和可接受准则：方案一得分最高，
并且评估项
1
达到
60
分，所以选择方案一。
风险：
对现有系统改造，
改造质量影响系统稳定运行；
应对措施：
引入了代码自动化检查工具及测试工具，
< br>提升代码质量
七、项目监控实践
项目监控
(Project Monitoringand C
ontrolPMC)
的目的是通过周期性地跟踪项目计划的各种参数，
如进度、
工
作量、资源、工作成果等，并不断的了解项
目进展情况，以便当项目实际进展状况显著偏离计划时能够及
时采取纠正措施。
1
、监控依据
过程体系文件《项目监控过程》
模版
：个人工作周报、项目工作周报、里程碑报告、例会会议纪要、外部干系人管理记录
2
、入口准则
项目计划已发布。
项目组人员已到位，并得到相关培训。
3
、监控输入
项目实施计划
项目进度计划
质量保证计划与跟踪表
配置管理计划与跟踪表
风险管理跟踪表
4
、监控输出
项目进度计划（已更新）
个人工作周报
项目工作周报
项目度量数据库
里程碑报告
例会会议纪要
里程碑评审会议纪要
风险管理跟踪表（已更新）
外部干系人管理记录
5
、证据举例
以项目例会为例，在例会上监控内容和点如下：
工作进度及完成工作量，识别项目偏差并分析；
识别问题并分析问题；
识别风险并跟踪风险，对项目风险进行规避，直至关闭；
按进度计划，安排组员的具体任务（
TFS
）
，并协调相关任务；
QA
监控过程符合状况；
进行干系人计划跟踪，组织干系人参与里程碑会议和其他讨论会。
八、度量实践
1
、度量体系简介
⑴、度量目标
项目性能度量
:
监控项目性能，保证项目能够按计划
要求完成项目任务
32
产品质量度
量
:
监控项目产品工作质量，保证项目能够高质量地完成
需求变更度量
:
监
控项目需求稳定性，保证通过需求管理及需求开发活动，减少需求变更
过程质量度量
:
监控项目过程质量，保证
QA
人员能够了解项目成员对过程的遵守程度，识别不符合项高的
过程加以指导和审计
项目规模度量
:
监控项目的规模，识别估计规模和实际规模的偏差
其它度量数据
:
监控各阶段的评审和测
试方式、资源投入、人员水平、各过程的复用率、覆盖率、按期交付
率
< br>
⑵、挣值分析
PV
：计划工作量的预算成本
EV
：已经完成工作量的预算成本
AC
：已经完成工作量的实际成本。
进度偏差率
(SV%)
：进度偏差
SV
（
SV=EV
-
PV
）与计划工时的预算成本
BCW
S
（
PV
）之间的比值
成本偏差率
(CV%)
：成
本差异
CV
（
CV=EV
-
AC
）与已完成工时的预算成本
< br>BCWP
（
EV
）的比值
进度性能指标
(SPI)
成本性能指标
(CPI)
2
、度量数据收集来源
报工系统
技术评审报告
各类测试报告
周例会
3
、度量数据记录在度量数据库里
4
、度量过程
如上图所示，
度量是周期性的工作
，
发生在各个阶段和里程碑点之后，
数据来源于工作周报
（报工系统）
、
技术评审报告、估算报告、测
试计划和报告等，度量数据记录在度量数据库里。
5
、度量分析
度量分析主要是在度量数据库和里程碑报告中，结项报告
是引用度量报告。
九、项目风险管理实践
1
、概述（基本概念补充）
⑴、风险应对策略
风险应对策略就是对已经识别的风险进行定性分析、
定量分析和进行风险排序，
制订相应的应对措施和整
体策略。
风险规避：是改变项目计划来消除特定风险
事件的威胁。例如，对于开发过程中存在的技术风险，我们可
以采用成熟的技术，团队成
员熟悉的技术或迭代式的开发过程等方法来规避风险。
风险转
移：是转移风险的后果给第三方，通过合同的约定，由保证策略或者供应商担保。
风险减轻：是减少不利的风险事件的后果和可能性到一个可以接受的范围。通常在项目的早期
采取风险减
轻策略可以收到更好的效果。
风险接受：准备应对风险事件，包括积极的开发应急计划，或者消极的接受风险的后果。对于不可预见的
风险，例如不可抗力；或者在风险规避，风险转移或者风险减轻不可行，或者上述活动执行成
本超过接受
风险的情况下采用。
⑵、风险来源
来自那些不好的事情，或者是造成潜在问题的源头：
不稳定的需求
复杂、不成熟的技术
过多的接口
33
客户的配合情况
团队技术水平低
（来源于公司资产库
——
风险库，项目个性化情况。
）
⑶、风险分类
在风险管理指南中，风险分类定义有：需求、设计、编码、测试、开发环境、人员、客户、管理、质量、
商业（市场）
、其他。
2
、识别风险与风险分析
⑴、识别风险
项目经理针对项目情况，综合考虑项目成本、进度、质量
、范围等因素，项目经理组织风险分析小组进行
识别风险活动，并将识别结果及时更新到
《风险管理跟踪表》中。
在识
别风险过程中，需要明确风险项、风险来源、风险类别等要素，并参考《风险数据库》
。
风险识别方式：头脑风暴法、假设法、访谈法、文档审查法等。
⑵、风险分析
项目经理根据项目情况，组织风险分析小组对风险进行定性
分析，确定每个风险项的
“
风险发生概率
”
、
“
风
险
影响范围
”
，计算出风险系数，并及时更新到《风险管理跟踪表
》
。
（风险系数
=
风险发生概率
×
风险影响范围。
）
风
险影响范围包括：范围、成本、进度、质量等项，每项分为
1
～
5
级（例如成本
5
级划分如下：小于
5%
的成本增加、
5%
～
10%
的成本增加、
11%
～
20%
的成本
增加、
21%
～
30%
的成本增加、
大于
30%
的成
本增加）
。
风险发生概率也分成
5
级
3
、风险应对措施
/
计划
首先，参考公司资产库中的风险库（风险列表）
，公司以往最佳
实践所提供的应对措施，业界常用的应对措
施；
接着，是团队的智慧，大家讨论。
例如：在实施计划中安排培训计划，减轻人力资源不足、不稳定的风险。
4
、如何跟踪风险，跟踪哪些？
按项目实施计划，通过项目周例会，在风险跟踪管理表上
进行跟踪风险。
跟踪开放状态风险及其应对措施
跟踪重新分析
不断识别新风险
风险跟踪记录在风险跟踪管理表中。
5
、举例说明本项目风险跟踪情况
本项目识别出
8
个风险项，主要风险是：
人力资源不足
,
资源负载严重，可能影响项目进度、质量，来源是不稳定的团队；
不能按进度计划要求完成项目开发各阶段任务，来源是技术不成熟。
十、技术评审与测试
1
、技术评审概况
34
2
、评
审收集数据
评审规模、规模单位（例如页数）
预评审工作量（人时）
评审人数
评审总工作量
缺陷数量
3
、评审缺陷分类、等级
⑴、缺陷分类
:
遗漏（
M
）
：
Missing
，工作产品遗漏了必要的内容。
错误（
W
）
：
Wrong
，工作产品存在错误。
其它（
E
）
：
Extra
，其它不属于以上两类的缺陷。
⑵、缺陷等级（
Defect
Severity
）
:
致命缺陷（
A
）
：指被评审
的工作产品存在结构上或内容上的缺陷，如果不进行修正后续的工作无法开展或
造成软件
存在功能上的缺陷。
严重缺陷（
B<
/p>
）
：指被评审的工作产品存在内容上的缺陷，如果不进行修正后续
的工作可能产生更为严重的
缺陷。
一
般缺陷（
C
）
：指被评审的工作产品存
在内容上的缺陷，如果不进行修正后续的工作基本不受影响，但可
能对最终的软件产品质
量造成一定影响。
轻微缺陷
（
D
）
：
指被评审的工
作产品存在文字、
规范等方面的缺陷，
不会对最终的软件产品质
量造成影响。
十一、软件开发过程中的知识点
1
、需求跟踪矩阵的两个作用
跟踪管理需求变更；
跟踪需求实现完全覆盖，保证需求与输出产品完整一致。
2
、需求变更评价及其影响分析
需求变更接受后，将涉及到计划调整，一般工期影响不大
，主要是成本。
⑴、变更影响分析报告
35
⑵、变更控制跟踪
变更申请
-
>
变更分析
-
>
变更审批
-
>
变更执行
-
>
变更
验证
-
>
重新入库与发布
变更起止时间、状态（开放、关闭）
3
、变更影响值分析规则
注：
如果级别为
1
，需要由
CCB
审批后才可
执行；
如果级别为
2
，需要
CCB
组长审批后即可执行；
< br>
如果级别为
3
，只要项目经理
审批就可执行。
十二、过程建议及贡献
1
、建议采用商用级代码检查和自动化测试工具
36
例如：业界发明了程序静态分析（
Program Stati
cAnalysis
）技术，静态分析是指在不运行代码的方式下，通
< br>过词法分析、语法分析、控制流分析等技术对程序代码进行扫描，验证代码是否满足规范性、安全性、可< /p>
靠性、可维护性等指标的一种代码分析技术。它可以帮助软件开发人员、质量保证人员查找
代码中存在的
结构性错误、安全漏洞和代码缺陷等问题，从而保证软件的整体质量。静态
分析的特点是能够在代码研发
的全周期协助开发人员优化代码，缩短项目周期，降低研发
成本，提高代码质量。
建议采用商用软件
Klocwork
Insight
。
2
、项目贡献（对
EPG
贡献）
⑴、贡献有：
项目度量数据
项目经验教训（包括好的经验、不好的教训）
复用代码
好的工作产品，例如设计、架构
CAR
的输出
⑵、经验教训举例
在单元测试中，采用交叉测试，并提高测试用例的质量，对
发现更多的缺陷有很大的帮助；
在设计阶段同行评审中，由于组员临时出差，找其他项目人员替代参与评审，评审时识别缺陷偏少，原因
是替代人员对业务、技术架构不熟悉，很难识别问题，因此，在以后评审时，尽量安排项目组成员
或对业
务、技术较熟悉人员参与，例如，在后续评审时，通过经理协商，把出差人员抽调
回来。
2013
< br>年
11
月
1
日补充。
37
38
软件项目量化管理（
CMMI<
/p>
高成熟度）实践经验
谈——之概述篇
目录
一、前言
1
、写在开始之前
< br>2
、我所认识的
CMMI5
级<
/p>
3
、试点项目概况
二、项目管理过程
1
、项目策划
2
、项目监督与控制
3
、决策分析与解决
4
、度量与分析
5
、其他
三、量化项目管理
1
、量化管理技术
2
、量化管理条件
3
、量化管理过程及注意事项
4
、根因分析
5
、量化管理中的问题
四、经验总结、交流
1
、实际工作经验
2
、量化管理总结
3
、讨论
一、前言
1
、写在开始之前
在软件项目管理中，总是把估计值当作承诺，无论是对自已或
对同事，都会造成不必要的焦虑。为避免
此类困境，就算最后期限迫在眉睫，你也能专注
于该做的事。然而也应该做到随时沟通，让相关人员看到
事情进展。
不稳定的团队在项目初期被做为风险，此风险在中后期演变成
问题。现实上，我们只有这样的团队，不
必抱怨，也不用花费精力分析领导分配资源公不
公？你应专注于该做的事，做好在这种资源情况下的项目
管理。
不仅在
验收前，就是时隔几年后，还经常有人有意、无意的找你抱怨软件产品上的缺陷。你不必为此自
< br>责，为此做出过多的解释，因为我们的软件成熟度模型当时只能达到这样的成熟度，存在缺陷是必然，是< /p>
达到我们的质量目标的，你应专注于该做的事，为我们的软件开发成熟度做出贡献。
通过本次交流，让下面的话远离你我：
我所带的项目特殊；
我所带的项目团队能力不足；
需求老在变；
工期太紧，一直在加班，都疲劳了；
系统上线时问题较多；
这个项目不挣钱，还赔钱呢！
39
项目经
理在
SOP
过程体系中的主要职责如下：
2
、
我所认识的
CMMI5
级
2.1
、
CMMI
核心观
点
观点
1
：
一切改进皆为商业目标服务；
观点
2
：不同的人，做好同样的事；
观点<
/p>
3
：没有度量就没有管理；
观点
4
：知识积累，共享文化的建立；
观点
5
：人才、技术、
方法一个都不能少。
2.2
、逐渐成熟的企业
已交付软件平均缺陷密度（缺陷遗漏率）
：
CMM1
级企业：
7.50
defects/kloc
CMM2
级企业：
6.24
defects/kloc
CMM3
级企业：
4.73
defects/kloc
CMM4
级企业：
2.28
defects/kloc
CMM5
级企业：
1.05
defects/kloc
摘自：
The Team Software Process
(TSP)in Practice: A Summary of Recent
Results
，
September
2003
，
SEI)
对个体的依赖性越来越小；
40
量化管理能力（用数据说话的能力）不断提高；
结构化、流程化管理能力不断提高；
生产效率和产品质量不断提高；
对企业经营决策的支撑性信息越来越多。
2.3
、
CMMI5
个等级与过程
域（
PA
）
一、项目管理过程
CMMI
2
级：项目策划
(PP)
CMMI
2
级：项目监督与控制
(PMC)
CMMI
2
级：供应商协议管理
(SAM)
CMMI
3
级：集成项目管理
(IPM)
CMMI
2
级：需求管理
(REQM)
CMMI
3
级：风险管理
(RSKM)
CMMI
4
级：量化项目管理
(QPM)
二、开发过程
CMMI
3
级：需求开发
(RD)
CMMI
3
级：技术解决
(TS)
CMMI
3
级：产品集成
(PI)
CMMI
3
级：验证
(VER)
CMMI
3
级：确认
(VAL)
三、支持过程
CMMI
2
级：
度量与分析
(MA)
CMMI 2
级：过程与产品质量保证
(PPQA)
CMMI
2
级：配置管理
(CM)
CMMI
3
级：决策分析与解决
(DAR)
CMMI
5
级：原因分析与解决
(CAR)
四、组织过程
CMMI
3
级：组织过程焦点
(OPF)
CMMI
3
级：组织过程定义
(OPD)
CMMI
3
级：组织培训
(OT)
CMMI
4
级：组织过程性能
(OPP)
CMMI
5
级：组织性能管理
(OPM)
41
2
.4
、项目经理（
PM
）职责
项目经理在软件项目管理
CMMI<
/p>
体系下，主要职责如下：
2.5
、人员角色及主要干系人
过程改进组
(EPG)
项目经理
(PM)
需求管理人员
(RM)
系统设计人员
(SA /
Designer)
开发人员
(Developer)
42
测试人员
(Tester)
质量保证人员
(QA)
配置管理人员
(CM)
2.6
、
C
MMI2
、
3
级成熟度概况
在定义级水平上，
企业不仅能够对项
目的实施有一整套的管理措施，
并保障项目的完成；
而且，
企业
能够根据自身的特殊情况以及自己的标准流程，将这套管理体系
与流程予以制度化，这样企业不仅能够在
同类的项目上得到成功的实施，在不同类的项目
上一样能够得到成功的实施。科学的管理成为企业的一种
文化，企业的组织财富。
总结一下
3
级的几个重要特点：
明确规定了需求开发、设计、编码、测试
、集成等软件开发各过程的要求。
对项目管理提出了更高的要
求，要利用组织级的数据来管理项目。
出现了专门针对组织级
的
PA
，要求有专门的组织来负责过程改进的工作。
提供了一个做出最佳决策的指导，而这个方法可以用于软件工程，也可以
用于组织级过程改进。
由这些特点大家可以看到，
3
级已经对软件开发的各个方面有了详细的要求，
2
级很多不明细的地方
全部已经明确。一个达到
3
级的企业，肯定会定义了很多软件开发各个方面的过程，并且会有组织级
的财
富库。所以
3
级叫
“
已定义
”
级。
如上图所示，在
< br>3
级中，项目经理根据标准过程、组织过程资产库、基线和模型，与客户共同协商
设定项目目标，再依据标准过程进行过程裁剪，按过程进行项目管理，项目结束后，把度
量数据和项目结
果贡献给
EPG
。
2.7
、
CMM
I4
、
5
级高成熟度概况
43
CMMI4
级是在量化管理级水平上，
企业的项目管理不仅形成了一种制度，
而且要实现数字化的管理。
对管理流程要做到量化与数字化。通过量化技术来实现流
程的稳定性，实现管理的精度，降低项目实施在
质量上的波动。
CMMI5
在量化项目管理的基础上增强了企业进行根本原因分析的能力和持续自主过程
改进
的能力。
如上图所示，
在项目管理过程中，<
/p>
增加了过程性能，
项目管理目标可以量化预测，
< br>在量化管理过程中，
如果预测目标达不到或过程性能不稳定，则进行原因分与解决
，以此过程持续、自主的改进过程以优化。
3
、试点项目概况
3.1
、项目背景及建设目标
项目背景：
系统由公文管理、通用办公、专业流程、综合信息、专业办公五大子系统组成。
系统采用全省集中模式，统一平台
2009
年建设，
< br>2010
年初投入应用
系统注册用户
21000
系统应用
Cordys
平台，采用
SOA
和
BPM
技术
在系统应用过程中，省公司和地市
公司都提出了大量需求，需要对全省集中办公系统进行扩展建设，
以满足用户使用需要。
建设目标：
扩展综合信息管理，延伸到地市；
优
化系统展现界面，提高界面打开速度、增强兼容性，提高系统易用性；
扩展并完善业务流程管理平台，进一步加强业务覆盖能力；
增加消息管理，提高消息、文件传输的稳定性；
系统接入集团云门户
3.2
、项目概况
项目需求：
新增需求
业务流程管理平台新增流程
时限管理、统计报表、个性化查询等深入应用需求
公文管理新增功能及手机办公扩展功能的需求
综合信息管理平台扩展到网络公司和地市公司需求
地市公文、业务流程维护管理需求
办公系统历史数据管理需求
人力资源考评需求
改造需求
44
-举重
-举重
-举重
-举重
-举重
-举重
-举重
-举重
-
上一篇：商业用语
下一篇：2016年股票期权分析报告(经典版)