GJB5000A度量分析方法和要求

GJB5000A为软件产品及软件过程提供了一套定量的表示和分析,即软件度量的模型，软件度量过程能促进组织的软件过程能力的改进。文章介绍了基于GJB5000A的软件产品的度量模型,并着重讨论了基于GJB5000A的软件过程度量,总结了软件过程度量的工作方法和思路,提出了解决软件度量的一般性方法,为软件过程改进提供了可行的方法和实践。

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

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

度量的意义在于提供一个反映实际的精确指标。所以我们的度量目标，就是提供我们过程效能的量化指标。比如项目的指标，开始时用三个就够了：周期、效率、质量；但是要一起监控。作为一位项目经理，要帮助团队提高，就需要监控所有的项目，看大家在一段时间之内的发展趋势，是否对头。也需要观察项目是否能够在关键因素之间找到最佳的平衡。这就提供了一个管理的依据，是持续改进的基础。

从项目组的角度，既然能够通过度量关键的因素，看到因素之间的关系，那就更能够有效处理这些因素。比如，以前单单关注进度。我们就会通过度量周期、效率、和质量，看到在什么条件底下缩短周期，对效率和质量有什么影响。不同时监控这三个因素，就不能了解他们之间的关系，就不能有效平衡项目的这几个关键因素。

明确了要求项目平衡这些因素之后，项目了解了因素之间的关系，就自然会要求有针对性的改善项目的个别活动或是过程单元。那么，项目立刻就面临一些问题，比如哪些活动对项目的目标影响最大？这个问题重要，因为我们要优先改进最关键的活动。另外一个问题就是，如何制订这些活动有效性的指标？我们需要用度量来回答这些问题。很多同志都说不明白如何制订度量目标。为这些问题找答案，就是我们的度量目标。

在一般的软件项目里，要满足项目的进度目标，最关键的活动，可能就是通过各个里程碑的成功率，如客户接受方案之前的确认次数，版本构建的成功率，通过系统测试的版本数等等。次数越少，对进度越有利。项目就要度量这些次数。这样项目就制定了一些度量定义了。比如要满足项目的效率目标，影响最大的，可能就是每一个活动的效率，比如项目里所有的会议，需求收集、编码、测试等效率。可能影响效率的也包括各类活动的工作量和周期的分配。分派合理，就提高效率，如需求、编码、测试的比例，或是管理与开发的比例等等。这些活动的度量定义，有些是容易的，有些不那么容易。要知道，这些因素都是相关联的，一时未必可以理顺，所以还是主观地找一些关键的和可以度量的开始，就可以了。

举两个案例：第一个，要支持项目的效率目标，我们知道项目有些活动是直接关联到最终产品的，有些不是。那么，主观上，有关联的活动的比例越大越好。那么，我们可以制定哪些是关联强的，如需求、编码等等；哪些是关联弱的，如培训、会议、测试等等。我们就统计这两种活动的工作量。更简单一点，我们可以单单统计其中一种也可以。

第二个案例，就是找其中一个活动来度量，比如会议。有关会议的测量，同样可以是进度、效率和质量。会议的进度比较简单，就是开会的时间。但却不是最关键的。效率呢，就需要有一个会议的成就的度量。我提议用议程项或是决策项就可以了，反正会议是要来做决策解决问题的。会议的质量呢，就没有那么明确了。想一想，什么会议我们觉得是高质量的。可能是决策之前，考虑比较多的因素，可能是所有开会的人都发言，也可能是会议的决策没有被推翻。要有一个正确的会议质量度量比较复杂。我们就要判断是否值得。不值得可以压根儿不度量。一个变通的办法就是简化其中的因素，比如强调考虑过的因素是否充分，就不考

虑决策的接受率或是实施率等等。这样当然有不准确的风险。我们不能因为不准确就不去度量，只要小心决定这个风险是可以承担就可以了。这样我们就可以制订会议的度量，如：参加人数、会议时间、议程或决策点、讨论的因素、与会人员的发言比例（有兴趣可以想一下如何定义这个度量）等等。

二、二级度量项定义

1.进度

进度的定义，在乎始点和终点。如果我们希望使用度量来让自己的业绩好看一点，我们就会千方百计地把“始点”的定义延后，把“终点”的定义推前。这只是自己骗自己而已。反之，我们应该尽量地把试点定义为全部的开发活动。这就是项目已经具备资源以开展开发活动的时候开始。这些资源，未必是全部的资源，只要可以启动开发活动就可以了。项目的开发活动，包括开发产品需求，系统方案，实施，确认与验证，以及获取客户的接收。项目具备资源开展任何以上的部分活动，这个一般是制订产品需求，就是项目的“始点”。“终点”不应该时系统测试通过，因为这个定义有利益冲突。了解这点，“终点”就理所当然地是获得客户的接收了。

这样的定义，项目经理很有意见，因为现在的管理理念，项目经理未必有这个权力来处理好一头一尾的时间段。这就是误解了度量的用处。我们有一个用度量来评价人或是项目的心态。这是奥林匹克比赛的度量观。每一个独立的数据点都是全部的意义。这是不对的。同一个活动，不同的实施，就受到不同的氛围、条件限制。同一个活动的两个实施，不一定是可比的。这不符合过程的度量观。

过程的度量观是反映团队的效能。一个组织的效能，就是所有项目的效能的总和。就是说，所有项目的效能（其中包括项目经理和成员的技能）数据作为一个集，才能代表组织的文化氛围与过程能力。如果组织不能合理有效地处理资源的下达，获取客户的接收，那么度量的确应该反映团队不具备很好的效能这个现实。正确的管理理念，就是项目经理需要看见这个现实，从过程的角度，考虑如何提高改进，而不是追究责任！经理的责任，就是分析这个项目的效能数据集，从而找到改进的道路，帮助组织提高效能。

2.规模

软件项目，规模通常就是代码行。代码行是产品的规模。功能点才是项目的规模，因为这是项目需要实施的功能。

工作量

工作量可以用于几个不同的目的。一个是反映某些任务的大小，另外一个目的是帮助策划将来的项目。工作量可以应用在不同的任务，比如会议的工作量，或是编码、测试等的工作量。会议的工作量比较明确，有多少人，会议进行了多久，就可以算出来会议的工作量。以后也可以用这个数据来策划将来的会议。但是我们不会想到会议里有些是有意义的发言，有些是风花雪月的闲谈（尤其是开始的时候），我们不会把这些时间段分的非常清楚吧。分的这么清楚有意义么？一定不容易，而且意义不大。但是我们编码的时候，就往往要求只记录真正编码的工作量。比如，一天之中，开了一个会，回了一些邮件的时间，要从编码的时间减除掉。这样的工作量，听起来是比较准确，但没有用。因为将来估算类似的任务的时候，我们还要知道一天的平均会议，回邮件等等的时间。这样非常麻烦，而且会引进不准确的因素。要解决这个问题，我们需要按照项目管理的原则，制定一个在组织氛围低下完成任务的工作量。我叫这个定义为“成本工作量”。

要定义有意义的工作量，项目首先需要按项目管理的原则制定“任务”。任务有很多层次，比如：开发一个模块是一个任务，主持一个会议也是一个任务。这两个任务是在不同的层次上面的。开发模块，是产品的组成部分。会议，可能是完成这个模块所需的，所以层次比较