软件项目量化管理方法(转载)
摘要：本文在对软件企业量化管理应用常见问题分析的基础上，以解决可操作性、可比性等问题为着眼点，识别出了量化管理中必须明确的四要素，表述了企业在量化四要素上采用的常见做法。
本文采用80/20原则，说明了企业在识别度量对象时应避免的问题；采用持续改进的理论，说明了企业在量化管理应遵循的客观规律。在结合平衡记分卡与目标驱动组合式的量化管理方法理论基础上，提出了软件企业的量化管理的具体应用步骤。
关键词：量化管理 四要素 80/20原则 持续改进 GQ(I)M
1. 引言
如今，很多国内软件企业选择采用能力成熟度系列 模型（Capability Maturity Model, CMM）或其它模型来建立本企业的软件过程规范，欲通过提升软件过程的能力达到提高产品质量、降低开发风险、减少开发成本、保证产品按时交付等目的。将软件过程规范的一个目的就是使软件过程可视化，这个可视化则要求了对软件过程的量化；而产品质量是否提高、开发风险是否降低、开发成本是否减少、项目延期是否缩短，对这些问题的回答则要求了对软件项目的量化；软件过程改进与量化管理息息相关。
不少企业在将识别出的量化管理方法应用于软件项目管理过程时，发现不少问题。最为常见的是：
|博锐|19
量化工作的可操作性不强，如：部分量化数据难以收集、难以统计投入的成本没有得到预期的产出。如：量化工作投入了成本，但形成的量化结果参考价值不高提供给管理层用于决策的支持数据也不够，数据缺乏可比性量化结果不是管理层所关心的，达不到管理层预期的过程可视化程度
针对此类问题，本文识别出了在量化管理中必须要考虑的四个方面，即：量化四要素，并从量化四要素对量化管理方法进行了分析，建议了软件企业采用的量化管理方法。
2. 量化四要素
“只有通过对产品、过程的度量，才能描述、评价、提高产品与过程”。
笔者认为，要度量，就要明确度量的对象；要度量对象，就要明确标识度量对象的计量单位；要产生度量结果，就要明确度量方法，包括度量技术和数据收集的方法；要评价度量对象，就要明确用于比对的基准指标，即表征度量对象目前情况的标尺，通过该标尺与度量结果的比对，得出对度量对象的评价。而度量对象（Object）、计量单位（Unit）、度量方法（Method）、基准指标（Benchmark），这就是笔者所说的量化四要素。
我们先看看目前软件企业在量化四要素上的常见做法：
(1) 度量对象
往往软件企业在识别度量对象时，是根据所采用的模型或标准中提出的相关要示去做的，比如：
综合能力成熟度模型（Capability Maturity Model Integration, CMMI）等级2中建议的量化目标[2]：
估计产品规模和实际规模
预算成本和实际成本
进度情况
缺陷率、测试与验收覆盖率和同行评审覆盖率
质量要求和质量度量
有些软件企业量化了识别出的各软件过程，建立了各过程的改进度量对象。可能有的企业识别出的度量对象更多。
(2) 计量单位
针对同一个目标，不同软件企业采用的计量单位也不尽相同。简单来讲，分为面向规模、面向功能的度量。
以软件规模的计量单位为例，常见的面向规模的有：代码行（lines of code，LOC）、人/月；面向功能的有：功能点、特征点（feature point）、对象点（object point）、3-D功能点（3-D function points）、标准构件法（standard component）等。
有的企业并非单纯地采取一种类型的计量单位，在某些目标上他们可能采用的是面向规模的计量单位，在另外的目标采用的又是面向功能的计量单位。
此外，对于软件质量的计量单位，有的企业可能就是用缺陷率来表征软件质量；有的企业可能将软件质量拆分成若干个子量化目标，对这些子目标再明确其计量单位。
(3) 度量技术
目前软件企业常用的度量技术，如挣值法、控制图、直方图、散布图等。项目中用于估算的技术有典型的估算方法，如Delphi法和类比法。
l 直方图
它是表示数据变化情况的一种主要工具，用于整理度量值的观测数据，分析其分布状态的统计方法，用于对总体的分布特征进行推断。
挣值法
挣值法是一种分析比较出目标实施与目标期望之间差异的方法，用于项目过程中的进度与费用分析。
它通过测量和已完成的工作的预算费用与已完成工作的实际费用和计划工作的预算费用得到有关计划实施的进度和费用偏差，而达到判断项目预算和进度计划执行情况的目的[3]。
控制图（SPC）
它是一种控制界限的图，用来区分引起质量波动的原因是偶然的还是系统的，可以提供系统原因存在的信息，从而判断生成过程是否处于受控状态。
按其用途可发为两类，一类是供分析用的控制图，用于分析生成过程的有关质量特性的变化情况，看工序是否处于稳定受控状态；再一类是供管理用的控制图，主要用于发现生产过程中是否出现了异常情况，以预防产生不合格品。
6 Sigma的统计分析技术就需要采用SPC度量方法。
Delphi法
Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种相关经验人的参与，互相说服对方。
类比法
类比法适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到估计数据。类比法估计结果的精确度取决于历史项目数据的完整性和准确度。
针对项目工期估计，常采用计划评估技术（Program Evaluation an Review Technique，PERT）进行估算。
针对项目成本估计，较好的方法有经验估算法、因素估算法和WBS基础上的全面详细估算法等多种方法。
(4) 基准指标
不少企业建立了基准指标，也有不少企业忽略了基准指标的建立。
为建立基准指标，建议采用如下步骤：
建立度量库
收集历史项目数据
量化历史项目
建立各项基准指标
3. 量化管理方法
通过以上描述，不难看到，若软件企业对识别出的所有度量对象都要在项目中去收集、去度量、去分析，无疑需要分配不少的资源、投入时间与成本。
笔者认为：在软件企业识别出的大量需要度量的对象中，企业目前所真正关注的、而且识别出来能提高软件过程改进的重要对象往往只占20%，即 “80/20原则”：即百分之八十的量化结果价值是来自百分之二十的度量对象的收集与分析工作，其余的百分之二十的价值则来自剩余百分之八十的量化工作。所以，如何把有效的人力物力投入到这20%的目标中，采用恰当的量化管理方法是非常重要的。
此外，计量单位、度量技术的不恰当选用也是导致工作量增加、可操作性降低的原因。以代码行这种计量单位为例，若企业缺乏相应的资源与相应度量工具的支持，其度量结果的准确程度与可信度就会大打折扣。
即使有了较为准确的度量结果，若企业缺乏基准指标，则难以评价度量对象，难以完成各项目的比对；缺乏基准指标的度量结果提交给管理层，管理层仍然很难通过提供的数据做出决策。
Wolfhart Goethert和Matt Fisher在集合了目标驱动式量化管理GQ(I)M和基于平衡记分卡BSC量化管理的基础上，提出了新的管理方法：BSC与目标驱动组合式的量化管理方法[4]。
我们将这种方法具体应用到软件企业的量化管理，结合量化四要素，结合持续改进的管理思想，笔者认为应遵循的步骤如下：
(1) 应先明确软件过程中的量化工作，该过程采用的：
明确企业的经营目标，弄清楚企业想知道什么
从财务、客户满意、内部流程、学习和创新四个方面确定软件量化过程的子目标
根据识别出的子目标，确定可量化的问题和指标
确定过程中的度量对象、计量单位、度量方法和基准指标
确定软件项目中应度量对象、计量单位、度量方法和基准指标
建立历史项目的度量库
(2) 延伸至软件项目时，可按如下过程具体化软件项目的量化工作：
确实业务目标、软件过程目标（在软件过程的量化工作中获得），结合两者，形成本项目的目标
从财务、客户满意、内部流程、学习和创新四个方面确定软件项目的子目标
根据认别出的子目标，确定可量化的问题和指标
结合软件过程中确定的度量对象、计量单位、度量方法和基准指标，制定本软件项目的度量对象、计量单位、度量方法和期望达到的基准指标（该项目的可以建立自己的基准指标）
制定度量计划
(3) 通过实际试用，及时纠正度量对象、计量单位、度量方法和基准指标中存在的不合理的因素，以保证量化管理过程的有效性
(4) 持续改进：企业应基于自身的实际能力成熟度，建立适宜本企业的量化管理方法。随着企业管理需求、能力成熟度的提高，通过量化过程、软件项目中的数据收集、统计分析，持续改进量化管理方法的有效性。
4. 结论
通过度量库建设环节，能让管理层清晰了解企业目前状态，管理层的目标期望不至于太脱离企业目前的能力；采用这种量化管理方法，也能够保证软件项目的目标与企业目标一致，找出需要量化的关键对象和基准指标。同样，由于事先明确了计量单位和度量方法，可操作性得到了提高。此外，由于软件项目的量化管理都是基于软件过程的量化管理基础上，就容易为企业建立一个统一的基线指标，容易将不同的项目进行比对。
另外，企业的目标是在不断调整与持续改进的，量化管理要求也在不断变化，量化管理水平将随着企业成熟度的提高而提高。量化四要素也应在保持阶段性稳定的基础上根据企业所处的不同阶段进行调整，也应随着企业成熟度的提高而逐步改进、逐渐细化、精确。
参考文献：
[1] Project Management Institute’s Organizational Project Management Maturity Model (OPM3 TM), PMI North American Congress, 2003
[2] Capability Maturity Model Integration, CMMISM for Software Engineering，SEI, August 2002
[3] A Guide to the Project Management Body of Knowledge (PMBOK Guide), PMI, 2000
[4] Deriving Enterprise-Based Measures Using the Balanced Scorecard and Goal-Driven Measurement Techniques, Wolfhart Goethert, Matt Fisher, October 2003
本文采用80/20原则，说明了企业在识别度量对象时应避免的问题；采用持续改进的理论，说明了企业在量化管理应遵循的客观规律。在结合平衡记分卡与目标驱动组合式的量化管理方法理论基础上，提出了软件企业的量化管理的具体应用步骤。
关键词：量化管理 四要素 80/20原则 持续改进 GQ(I)M
1. 引言
如今，很多国内软件企业选择采用能力成熟度系列 模型（Capability Maturity Model, CMM）或其它模型来建立本企业的软件过程规范，欲通过提升软件过程的能力达到提高产品质量、降低开发风险、减少开发成本、保证产品按时交付等目的。将软件过程规范的一个目的就是使软件过程可视化，这个可视化则要求了对软件过程的量化；而产品质量是否提高、开发风险是否降低、开发成本是否减少、项目延期是否缩短，对这些问题的回答则要求了对软件项目的量化；软件过程改进与量化管理息息相关。
不少企业在将识别出的量化管理方法应用于软件项目管理过程时，发现不少问题。最为常见的是：
|博锐|19
量化工作的可操作性不强，如：部分量化数据难以收集、难以统计投入的成本没有得到预期的产出。如：量化工作投入了成本，但形成的量化结果参考价值不高提供给管理层用于决策的支持数据也不够，数据缺乏可比性量化结果不是管理层所关心的，达不到管理层预期的过程可视化程度
针对此类问题，本文识别出了在量化管理中必须要考虑的四个方面，即：量化四要素，并从量化四要素对量化管理方法进行了分析，建议了软件企业采用的量化管理方法。
2. 量化四要素
“只有通过对产品、过程的度量，才能描述、评价、提高产品与过程”。
笔者认为，要度量，就要明确度量的对象；要度量对象，就要明确标识度量对象的计量单位；要产生度量结果，就要明确度量方法，包括度量技术和数据收集的方法；要评价度量对象，就要明确用于比对的基准指标，即表征度量对象目前情况的标尺，通过该标尺与度量结果的比对，得出对度量对象的评价。而度量对象（Object）、计量单位（Unit）、度量方法（Method）、基准指标（Benchmark），这就是笔者所说的量化四要素。
我们先看看目前软件企业在量化四要素上的常见做法：
(1) 度量对象
往往软件企业在识别度量对象时，是根据所采用的模型或标准中提出的相关要示去做的，比如：
综合能力成熟度模型（Capability Maturity Model Integration, CMMI）等级2中建议的量化目标[2]：
估计产品规模和实际规模
预算成本和实际成本
进度情况
缺陷率、测试与验收覆盖率和同行评审覆盖率
质量要求和质量度量
有些软件企业量化了识别出的各软件过程，建立了各过程的改进度量对象。可能有的企业识别出的度量对象更多。
(2) 计量单位
针对同一个目标，不同软件企业采用的计量单位也不尽相同。简单来讲，分为面向规模、面向功能的度量。
以软件规模的计量单位为例，常见的面向规模的有：代码行（lines of code，LOC）、人/月；面向功能的有：功能点、特征点（feature point）、对象点（object point）、3-D功能点（3-D function points）、标准构件法（standard component）等。
有的企业并非单纯地采取一种类型的计量单位，在某些目标上他们可能采用的是面向规模的计量单位，在另外的目标采用的又是面向功能的计量单位。
此外，对于软件质量的计量单位，有的企业可能就是用缺陷率来表征软件质量；有的企业可能将软件质量拆分成若干个子量化目标，对这些子目标再明确其计量单位。
(3) 度量技术
目前软件企业常用的度量技术，如挣值法、控制图、直方图、散布图等。项目中用于估算的技术有典型的估算方法，如Delphi法和类比法。
l 直方图
它是表示数据变化情况的一种主要工具，用于整理度量值的观测数据，分析其分布状态的统计方法，用于对总体的分布特征进行推断。
挣值法
挣值法是一种分析比较出目标实施与目标期望之间差异的方法，用于项目过程中的进度与费用分析。
它通过测量和已完成的工作的预算费用与已完成工作的实际费用和计划工作的预算费用得到有关计划实施的进度和费用偏差，而达到判断项目预算和进度计划执行情况的目的[3]。
控制图（SPC）
它是一种控制界限的图，用来区分引起质量波动的原因是偶然的还是系统的，可以提供系统原因存在的信息，从而判断生成过程是否处于受控状态。
按其用途可发为两类，一类是供分析用的控制图，用于分析生成过程的有关质量特性的变化情况，看工序是否处于稳定受控状态；再一类是供管理用的控制图，主要用于发现生产过程中是否出现了异常情况，以预防产生不合格品。
6 Sigma的统计分析技术就需要采用SPC度量方法。
Delphi法
Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种相关经验人的参与，互相说服对方。
类比法
类比法适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到估计数据。类比法估计结果的精确度取决于历史项目数据的完整性和准确度。
针对项目工期估计，常采用计划评估技术（Program Evaluation an Review Technique，PERT）进行估算。
针对项目成本估计，较好的方法有经验估算法、因素估算法和WBS基础上的全面详细估算法等多种方法。
(4) 基准指标
不少企业建立了基准指标，也有不少企业忽略了基准指标的建立。
为建立基准指标，建议采用如下步骤：
建立度量库
收集历史项目数据
量化历史项目
建立各项基准指标
3. 量化管理方法
通过以上描述，不难看到，若软件企业对识别出的所有度量对象都要在项目中去收集、去度量、去分析，无疑需要分配不少的资源、投入时间与成本。
笔者认为：在软件企业识别出的大量需要度量的对象中，企业目前所真正关注的、而且识别出来能提高软件过程改进的重要对象往往只占20%，即 “80/20原则”：即百分之八十的量化结果价值是来自百分之二十的度量对象的收集与分析工作，其余的百分之二十的价值则来自剩余百分之八十的量化工作。所以，如何把有效的人力物力投入到这20%的目标中，采用恰当的量化管理方法是非常重要的。
此外，计量单位、度量技术的不恰当选用也是导致工作量增加、可操作性降低的原因。以代码行这种计量单位为例，若企业缺乏相应的资源与相应度量工具的支持，其度量结果的准确程度与可信度就会大打折扣。
即使有了较为准确的度量结果，若企业缺乏基准指标，则难以评价度量对象，难以完成各项目的比对；缺乏基准指标的度量结果提交给管理层，管理层仍然很难通过提供的数据做出决策。
Wolfhart Goethert和Matt Fisher在集合了目标驱动式量化管理GQ(I)M和基于平衡记分卡BSC量化管理的基础上，提出了新的管理方法：BSC与目标驱动组合式的量化管理方法[4]。
我们将这种方法具体应用到软件企业的量化管理，结合量化四要素，结合持续改进的管理思想，笔者认为应遵循的步骤如下：
(1) 应先明确软件过程中的量化工作，该过程采用的：
明确企业的经营目标，弄清楚企业想知道什么
从财务、客户满意、内部流程、学习和创新四个方面确定软件量化过程的子目标
根据识别出的子目标，确定可量化的问题和指标
确定过程中的度量对象、计量单位、度量方法和基准指标
确定软件项目中应度量对象、计量单位、度量方法和基准指标
建立历史项目的度量库
(2) 延伸至软件项目时，可按如下过程具体化软件项目的量化工作：
确实业务目标、软件过程目标（在软件过程的量化工作中获得），结合两者，形成本项目的目标
从财务、客户满意、内部流程、学习和创新四个方面确定软件项目的子目标
根据认别出的子目标，确定可量化的问题和指标
结合软件过程中确定的度量对象、计量单位、度量方法和基准指标，制定本软件项目的度量对象、计量单位、度量方法和期望达到的基准指标（该项目的可以建立自己的基准指标）
制定度量计划
(3) 通过实际试用，及时纠正度量对象、计量单位、度量方法和基准指标中存在的不合理的因素，以保证量化管理过程的有效性
(4) 持续改进：企业应基于自身的实际能力成熟度，建立适宜本企业的量化管理方法。随着企业管理需求、能力成熟度的提高，通过量化过程、软件项目中的数据收集、统计分析，持续改进量化管理方法的有效性。
4. 结论
通过度量库建设环节，能让管理层清晰了解企业目前状态，管理层的目标期望不至于太脱离企业目前的能力；采用这种量化管理方法，也能够保证软件项目的目标与企业目标一致，找出需要量化的关键对象和基准指标。同样，由于事先明确了计量单位和度量方法，可操作性得到了提高。此外，由于软件项目的量化管理都是基于软件过程的量化管理基础上，就容易为企业建立一个统一的基线指标，容易将不同的项目进行比对。
另外，企业的目标是在不断调整与持续改进的，量化管理要求也在不断变化，量化管理水平将随着企业成熟度的提高而提高。量化四要素也应在保持阶段性稳定的基础上根据企业所处的不同阶段进行调整，也应随着企业成熟度的提高而逐步改进、逐渐细化、精确。
参考文献：
[1] Project Management Institute’s Organizational Project Management Maturity Model (OPM3 TM), PMI North American Congress, 2003
[2] Capability Maturity Model Integration, CMMISM for Software Engineering，SEI, August 2002
[3] A Guide to the Project Management Body of Knowledge (PMBOK Guide), PMI, 2000
[4] Deriving Enterprise-Based Measures Using the Balanced Scorecard and Goal-Driven Measurement Techniques, Wolfhart Goethert, Matt Fisher, October 2003
