【IT168 技术文章】

    一直以来，软件产品与软件过程的分析与改进是软件企业最为关注的事情之一。作为项目/产品的开发人员，在整个软件开发过程中，从需求分析到系统构架，到编码、单元测试、联合测试，再到最终发布使用，如何把握软件过程中的质量、进度控制，将开发过程的每一部分控制在可预算范围内，主管人员往往通过经验和对人员的了解进行一个定性的分析以及结论，这样的结果往往造成企业缺乏有效的统计数据，对软件过程进行定量的分析和统计。一个生存了许多年的软件企业，却拿不出企业自身对软件产品和过程有效控制的统计数据作为评判依据，无疑说明了它在软件开发的发展方面是失败的。

    CMMI为软件产品及软件过程提供了一套定量的表示和分析的模型，即软件度量。因此软件度量分为软件产品度量和软件过程度量两大部分。

    先简单介绍一下软件产品的度量（我个人认为，软件产品的度量评估比较EASY，重点放在软件过程度量上），由三部分组成：
    1.质量要素：包括 功能性，可靠性，易用性，高效性，可维护性，可移植性 六条。
    2.评价标准：包括 精确、健壮、通信有效、处理有效、设备有效、可操作等等共22点。以这22点作为上面六条的评判标准。
    3.度量元：指软件的需求分析，概要设计，详细设计，CODING实现，设置测试，确认测试，使用维护七个阶段中的度量元素，比如各阶段的里程碑--文档等。

    对于软件过程度量，我们先来讨论，在软件过程中，我们最需要掌握这个过程中的什么。
    因为我们需要在通过每一个软件过程后，能交付符合该过程需要的结果，即该过程产品，该产品性能是否达到组织的商业目标。为了让这个目标成功，让它所有过程中的行为在整个管理中可以预测，判断现阶段这个过程设计是否合理，我们不仅仅需要主管和经验丰富的开发人员的经验，还需要定量的数据作为分析、参考。并把每个软件过程记录入库，作为今后的统计分析参考数据，这样科学的辅佐开发人员将软件过程控制住。

    如何设定并采集参考数据，这些数据如何使用，可以采用那些数据统计、描述工具。下面我举系列例子：
    对于一个开发项目，首先我们将其归入某一项目种类中，然后将开发人员人数、级别（如一个P4,两个P3，5个P2等）记录，统计他们对一功能模块（以代码行为标准，乘以其难度系数）的开发时间，在此类数据积累够多时，我们就可以预测并控制下一次遇到此类的项目（或实现该功能模块）大致需要的时间上、下限，并能查找偏差来进行控制，直方图或正态分布图可以有效的表示出这一点，这是开发进度的控制方式之一。

    对于软件过程中遇到的偏差以及问题，我们可以采用头脑风暴法，将这些问题罗列出来，用来探测和展示问题的可能原因，鱼骨图可以很形象的将其描述。问题是罗列出来了，但是本方式存在的弊端也很明显，就是缺陷主次不明，时间、资源都是有限的，如何从问题最大的缺陷下手呢，我们可以采用PARETO图将问题展示出来，根据其二八原则，先将缺陷种类中的20%解决，却就解决了80%的问题，这样缺陷解决的过程得以优先排序。

    我们可以通过对整个软件过程中的七个阶段进行离散分析，可以得出各阶段中缺陷的发现及解决比例，从而判断出哪个阶段问题最大，将解决重点放在该阶段。比如，如果在分析阶段缺陷比例最大，而后期依次减小至理想状态，这说明本软件过程是非常成功的，反之，如果在测试阶段甚至使用阶段缺陷比例很大，很可能说明这个软件过程在分析、或者构架时就存在很大的问题。　　

    由于俺也接触CMMI不多，无法做到很深入的剖析，但求能起个抛砖引玉的效果，希望有兴趣的朋友一起来讨论研究，共同进步。