软件过程不成熟的企业如何实施度量

测试积点老人

提高开发效率和质量是软件企业始终关注的目标，我们一直希望能够通过某种简单的方法来实现这个目标。近年来，越来越多的人开始讨论度量在其中的作用，的确，度量是解决软件项目中很多问题的有效手段。

软件度量可以从两个角度满足企业的需要：第一，项目需要——我们使用度量数据进行估计、监控项目的进度和执行情况、确定软件产品是否符合质量要求；第二，组织需要——度量数据可以帮助我们确定整个组织的开发效率和质量的总体水平、发展趋势，使我们更好地进行产品组合、判断资金/技术投向，策划、管理或验证软件开发活动。

度量不但是管理的根基，同样也必须是有效的管理体系的重要组成部分，只有这样度量才能够有效地发挥作用，度量和管理是相辅相成的。

那么，通常软件企业的管理水平如何呢？根据SEI的统计，75%的软件企业的过程成熟度处于CMM的1级水平，缺乏一致性、混乱，不能为度量提供较好的基础；项目的策划、控制活动缺乏有效性，无法对质量进行量化的评价。企业达到了2级，就已经建立了有效的项目管理体系：项目范围清楚、计划合理、实施了有效的跟踪和管理。那么对于1级的软件企业来说，进行过程改进的目的就是获得2级的核心能力，因此所实施的度量必须有利于这个目标的实现。

Jim Clemmer在“Firing on All Cylinders”一书中指出,“ 有关服务/质量的度量数据可以很少、很简单但很有效，它们能够成为企业能量传输的通路；度量的核心领域是高回报率的、有战略意义的领域”。对于1级的软件企业，哪些度量数据符合这一原则呢？那就是：软件规模、项目成本、工期、缺陷数据。

对规模的估计是所有估计活动的基础。过去的估计方法很简单，只是单纯的比较。现在我们有了更多的估计规模的技术，这些技术也可以用来更合理地估计成本和工期。

常用的规模单位有两种：代码行和功能点。代码行多用于传统的软件工程系统，需要对系统的内部有准确的了解。功能点更多用于信息系统的开发，主要是从用户的角度、从外部来看系统。

哪个度量单位更好呢？虽然我本人也曾经犹豫不定，但我现在认为功能点对项目策划和度量最终的交付产品更有效，而代码行更适合编码阶段和测试阶段对进度的度量。

成本和工期的度量是项目控制的基础，可以作为建立度量体系的起点。度量的主要目的是将实际值与估计值进行比较，如果使用了获得价值方法，我们可以很容易发现有关项目进度的问题。另外，将成本和工期的数据与软件规模数据相联系，就可以确定项目和组织的开发效率。

对软件质量的度量主要是统计可能引起问题的缺陷数。能力成熟度处于1级的企业可以使用《用户问题报告》来获得产品发布后的缺陷数据，并且做到合理而一致；但如果没有建立较好的检验和测试实践，就不容易收集到开发过程中有用的数据。

如果度量数据是管理活动或技术活动的正常输出，度量体系就会非常容易实施；相反，如果数据过于复杂、对数据的作用没有进行详细的说明，项目组的成员就会觉得提供度量数据的工作是额外的负担、对自己的开发工作没有什么作用，甚至会被用做评价个人业绩，那么度量工作的阻力就会非常大。

实施软件度量需要持恒和毅力。如果我们能够使度量过程足够简单、与开发活动密切结合、成为开发过程不可分割的部分，主要对稳定的、已定义的软件过程进行度量，企业就可以开始从数量化的软件质量管理体系中受益了。

我的观点：度量以项目为核心，密切结合开发活动，收集的数据少而精，易于操作，对过程、产品和项目有直接作用。