GJB5000A为软件产品及软件过程提供了一套定量的表示和分析,即软件度量的模型，软件度量过程能促进组织的软件过程能力的改进。

文章介绍了基于GJB5000A的软件产品的度量模型,并着重讨论了基于GJB5000A的软件过程度量,总结了软件过程度量的工作方法和思路,提出了解决软件度量的一般性方法,为软件过程改进提供了可行的方法和实践。

一、度量几个基本的原则。

第一，一定要明确度量的目标和意义。

度量的意义在于提供一个反映实际的精确指标。

所以我们的度量目标，就是提供我们过程效能的量化指标。

比如项目的指标，开始时用三个就够了：周期、效率、质量；但是要一起监控。

作为一位项目经理，要帮助团队提高，就需要监控所有的项目，看大家在一段时间之内的发展趋势，是否对头。

也需要观察项目是否能够在关键因素之间找到最佳的平衡。

这就提供了一个管理的依据，是持续改进的基础。

从项目组的角度，既然能够通过度量关键的因素，看到因素之间的关系，那就更能够有效处理这些因素。

比如，以前单单关注进度。

我们就会通过度量周期、效率、和质量，看到在什么条件底下缩短周期，对效率和质量有什么影响。

不同时监控这三个因素，就不能了解他们之间的关系，就不能有效平衡项目的这几个关键因素。

明确了要求项目平衡这些因素之后，项目了解了因素之间的关系，就自然会要求有针对性的改善项目的个别活动或是过程单元。

那么，项目立刻就面临一些问题，比如哪些活动对项目的目标影响最大？这个问题重要，因为我们要优先改进最关键的活动。

另外一个问题就是，如何制订这些活动有效性的指标？我们需要用度量来回答这些问题。

很多同志都说不明白如何制订度量目标。

为这些问题找答案，就是我们的度量目标。

在一般的软件项目里，要满足项目的进度目标，最关键的活动，可能就是通过各个里程碑的成功率，如客户接受方案之前的确认次数，版本构建的成功率，通过系统测试的版本数等等。

次数越少，对进度越有利。

项目就要度量这些次数。

这样项目就制定了一些度量定义了。

比如要满足项目的效率目标，影响最大的，可能就是每一个活动的效率，比如项目里所有的会议，需求收集、编码、测试等效率。

可能影响效率的也包括各类活动的工作量和周期的分配。

分派合理，就提高效率，如需求、编码、测试的比例，或是管理与开发的比例等等。

这些活动的度量定义，有些是容易的，有些不那么容易。

要知道，这些因素都是相关联的，一时未必可以理顺，所以还是主观地找一些关键的和可以度量的开始，就可以了。

举两个案例：第一个，要支持项目的效率目标，我们知道项目有些活动是直接关联到最终产品的，有些不是。

那么，主观上，有关联的活动的比例越大越好。

那么，我们可以制定哪些是关联强的，如需求、编码等等；哪些是关联弱的，如培训、会议、测试等等。

我们就统计这两种活动的工作量。

更简单一点，我们可以单单统计其中一种也可以。

第二个案例，就是找其中一个活动来度量，比如会议。

有关会议的测量，同样可以是进度、效率和质量。

会议的进度比较简单，就是开会的时间。

但却不是最关键的。

效率呢，就需要有一个会议的成就的度量。

我提议用议程项或是决策项就可以了，反正会议是要来做决策解决问题的。

会议的质量呢，就没有那么明确了。

想一想，什么会议我们觉得是高质量的。

可能是决策之前，考虑比较多的因素，可能是所有开会的人都发言，也可能是会议的决策没有被推翻。

要有一个正确的会议质量度量比较复杂。

我们就要判断是否值得。

不值得可以压根儿不度量。

一个变通的办法就是简化其中的因素，比如强调考虑过的因素是否充分，就不考虑决策的接受率或是实施率等等。

这样当然有不准确的风险。

我们不能因为不准确就不去度量，只要小心决定这个风险是可以承担就可以了。

这样我们就可以制订会议的度量，如：参加人数、会议时间、议程或决策点、讨论的因素、与会人员的发言比例（有兴趣可以想一下如何定义这个度量）等等。

二、二级度量项定义1.进度进度的定义，在乎始点和终点。

如果我们希望使用度量来让自己的业绩好看一点，我们就会千方百计地把“始点”的定义延后，把“终点”的定义推前。

这只是自己骗自己而已。

反之，我们应该尽量地把试点定义为全部的开发活动。

这就是项目已经具备资源以开展开发活动的时候开始。

这些资源，未必是全部的资源，只要可以启动开发活动就可以了。

项目的开发活动，包括开发产品需求，系统方案，实施，确认与验证，以及获取客户的接收。

项目具备资源开展任何以上的部分活动，这个一般是制订产品需求，就是项目的“始点”。

“终点”不应该时系统测试通过，因为这个定义有利益冲突。

了解这点，“终点”就理所当然地是获得客户的接收了。

这样的定义，项目经理很有意见，因为现在的管理理念，项目经理未必有这个权力来处理好一头一尾的时间段。

这就是误解了度量的用处。

我们有一个用度量来评价人或是项目的心态。

这是奥林匹克比赛的度量观。

每一个独立的数据点都是全部的意义。

这是不对的。

同一个活动，不同的实施，就受到不同的氛围、条件限制。

同一个活动的两个实施，不一定是可比的。

这不符合过程的度量观。

过程的度量观是反映团队的效能。

一个组织的效能，就是所有项目的效能的总和。

就是说，所有项目的效能（其中包括项目经理和成员的技能）数据作为一个集，才能代表组织的文化氛围与过程能力。

如果组织不能合理有效地处理资源的下达，获取客户的接收，那么度量的确应该反映团队不具备很好的效能这个现实。

正确的管理理念，就是项目经理需要看见这个现实，从过程的角度，考虑如何提高改进，而不是追究责任！经理的责任，就是分析这个项目的效能数据集，从而找到改进的道路，帮助组织提高效能。

2.规模软件项目，规模通常就是代码行。

代码行是产品的规模。

功能点才是项目的规模，因为这是项目需要实施的功能。

工作量工作量可以用于几个不同的目的。

一个是反映某些任务的大小，另外一个目的是帮助策划将来的项目。

工作量可以应用在不同的任务，比如会议的工作量，或是编码、测试等的工作量。

会议的工作量比较明确，有多少人，会议进行了多久，就可以算出来会议的工作量。

以后也可以用这个数据来策划将来的会议。

但是我们不会想到会议里有些是有意义的发言，有些是风花雪月的闲谈（尤其是开始的时候），我们不会把这些时间段分的非常清楚吧。

分的这么清楚有意义么？一定不容易，而且意义不大。

但是我们编码的时候，就往往要求只记录真正编码的工作量。

比如，一天之中，开了一个会，回了一些邮件的时间，要从编码的时间减除掉。

这样的工作量，听起来是比较准确，但没有用。

因为将来估算类似的任务的时候，我们还要知道一天的平均会议，回邮件等等的时间。

这样非常麻烦，而且会引进不准确的因素。

要解决这个问题，我们需要按照项目管理的原则，制定一个在组织氛围低下完成任务的工作量。

我叫这个定义为“成本工作量”。

要定义有意义的工作量，项目首先需要按项目管理的原则制定“任务”。

任务有很多层次，比如：开发一个模块是一个任务，主持一个会议也是一个任务。

这两个任务是在不同的层次上面的。

开发模块，是产品的组成部分。

会议，可能是完成这个模块所需的，所以层次比较低。

一个项目，最高层次的任务，应该是按产品的构建而制定的，就是说，是跟系统方案是一致的。

这样的任务，才可以代表整个项目的范围。

这个层次的任务，我把它称为“项目层任务”。

会议、评审等等，就不是项目层任务。

还是需要策划，但度量的方法不一样。

有了这个概念，才能定义出有意义的工作量。

3.工作量成本工作量，是一个项目成员完成他的项目任务所需的“在勤时间”。

在勤时间，就是他上班的时间。

那么，一个项目成员在他开始一个项目任务的时间，到这个任务完成的时间，他的上班时间，就是这个任务的工作量。

其中包括会议的，评审自己与他人工作的，回邮件的，甚至上厕所的，自己胡思乱想的时间。

如果同时处理多个任务，就要制定原则，把时间分配到各个任务上去。

这个定义，工作量的收集不用员工操心，考勤的信息就可以了，是非常简单的，也是与项目的操作相配合的，收集数据的额外干扰就减到最少了。

这个定义不是唯一的。

我们可以定义成本工作量为“在职时间”。

这就包括了请病假、接收培训、出差之类的时间。

各有好处。

大家自己研究一下，自己决定。

项目的总工作量，就是所有项目层任务的工作量，加上管理与支持的工作量。

要监控项目里的各种调控，就需要有比较精确的度量，我们是不能从考勤信息拿到，是需要特别度量的。

我称它为“度量工作量”。

比如项目的会议所占的比例，就是所有会议的工作量之和，对比整个项目的成本工作量。

那么，我们就需要有精确的会议工作量。

这个我们从会议纪要里可以算出来。

评审占的比例也是如此。

另外一个案例就是返工量。

这个不是项目层任务。

所以我们要精确地算出来。

一个方法就是用变更控制系统。

如果变更控制系统是规范的，每一次每一位员工处理变更请求单里的要求所用的实际工作量填上去，那么，返工量就是这些变更控制系统里的工作量之和。

4.质量真正的质量指标，应该是独立于项目的，是由项目之外传递过来的，例如：现场故障数、故障间隔（MTBF）、客户满意度等等。

在成熟的团队，度量真正被利用来管理项目，那么项目过程之中的缺陷数，跟实际的产品质量还是有一定的关系的。

定义缺陷的时候，需要考虑失效与缺陷的分别。

我们通过测试或是现场发现失效。

缺陷是产品里面造成失效或是不能满足需求的原因。

我们需要分别他们，是因为每一个失效里，可能有一个或是多个缺陷。

所以数量就不同了。

在项目里，缺陷的定义可以是基于失效的，也可以是基于缺陷的。

最终还是需要能够建立项目里的质量特征（无论是建立在失效或是缺陷之上），与产品的现场表现关联起来的。

与产品质量关联的项目质量特征，包括两方面：项目里的缺陷密度与发现缺陷的阶段分布。

所以质量的指标，在统计缺陷数的同时，也要统计在不同阶段的缺陷发现分布。

所有这些数据，都应该可以在变更控制系统里拿到，它们的收集，还是比较理所当然，不会让项目受到太大的干扰的。

三、二级之后的度量项定义1.进度方面实际进度的计划进度的偏差情况，Gantt图和Pert图。

返工时间占项目总时间的比例情况项目能够容忍的最大的处理变更的时间三级强调了偏差的范围，四级强调严格的上下限控制(控制图)2.工作量实际工作量和计划工作量的偏差三级增加对好质量成本和坏质量成本相关工作量的度量(COGQ,COPQ)对项目返工，评审，测试和处理变更工作量的分别度量3.成本计划成本和实际成本的偏差三级强调了成本和进度的性能指示器(挣值分析)三级强调了偏差的范围，四级强调严格的上下限控制(控制图)五级强调了会提供可选择的过程改进和缺陷预防策略供选择，而这个是在对项目的成本和效益做了比较和平衡后得出的。

4.软件质量保证不合格项的信息SQA具体的审核信息5.Review的结果Review的活动项的状态6.问题报告问题项的具体状态(打开,处理,关闭)问题的原因的分析，对问题的分类的统计问题的平均处理周期度量7.同行评审和缺陷同行评审的缺陷的打开和关闭的情况统计缺陷密度缺陷移除率和缺陷泄漏率同行评审的效率，评审速率的度量同行评审的覆盖率四级强调对缺陷分类后的帕累托分析四级强调对同行评审的关键特征项的控制图分析8.需求的度量需求的规模的情况需求的稳定度或需求的变更率需求变更的不同类型的分布情况需求变更处理的效率和周期度量9.培训实际安排课程和计划课程的对比实际参与人员和计划参与人员的对比对培训的成本和花费的度量对培训取得的效果的度量10.测试过程测试的生产率的度量测试规模的度量对测试BUG的分类后的帕累托分析生命周期不同阶段发现缺陷的数量分布，泄漏情况测试BUG的密度四、度量分析与评价1.要看图，不能只看表格在收集数据之前，需要清楚如何分析收集到的数据，并且如何使用分析的结果。