(SPC)软件过程改进的应用 - CMMI
作者：睿泰科技高级咨询师杜普利
软件产业历来就存在着一些问题，而这些问题的是不会自动解决的。为了解决这些问题，需要用基于数据的客观方法来观察问题，研究问题的内容以及产生问题的原因，从而找到一些解决问题的方法和途径，不断改善软件的开发管理过程，提高产品的质量。统计过程控制（SPC）有助于对软件开发中的各项活动进行定量的了解和精确的控制，同时也有助于对过程的改进和产品的改进提供明确的指导。SPC有利于事先分析改进活动的成本效益，预测改进后的效果；事中进行定量的跟踪与监控，客观及时地发现活动中的问题，便于采取精确的纠正措施；事后能够进行客观定量化的分析与总结，对于软件企业的资产积累就有非常实用的效益。
尽管很多人并不认可软件度量是软件工程和管理方面的一个重要因素，认为测量很难进行，测量的结果很少有使用价值和参考意义。但是在实际的活动中人们却一直试图用测量来管理和监控自己的项目。开发人员通过测量软件的特性，以了解软件需求是否一致和完整，实际的质量达到了什么程度，代码是否可以进行测试；PM通过测量过程和产品的特性，来了解项目的进度和成本是否在控制范围之内，对未来的发布时间和预算进行预测；当然客户也要通过测量，来检验最终的产品是否满足需求和产品的质量到底达到了什么程度；而维护人员也需要通过测量来对当前的产品进行评估，以便做出是否需要进行升级和改进的决策。虽然，现在越来越多的软件从业人员都认识到了历史数据对项目的帮助极为重要，都想使用数据来进行估算和预测，但是大多数人对究竟怎样去进行度量和收集数据还并不清楚，或者收集了数据，却不知道怎样利用收集到的数据区进行分析，并用于指导自己的工作。另外，在软件行业还存在这样一些不正确的观点，许多人认为软件是一个高度智力化的人为的工作，由于从业人员的经验、技能，所使用的过程，方法和工具等很多方面的不确定性，这些因素的组合将导致各种不同的结果。因此他们认为软件项目的性能和过程是无法进行统一的测量的，或者说测量的结果可参考的意义也是不大的。为了消除人们的这种错误认识，并且帮助那些已经意识到历史数据的重要性的人去利用这些数据来客观的确定组织的强项、弱项，需要改进的问题，问题的根本原因，以及产品和过程性能的发展趋势，就需要使用工程度量领域的统计过程控制理论。
统计过程控制（SPC）起源于20世纪20年代，由贝尔实验室的Walter A Shewhart提出，二战后，W.Edwards Deming 和Joseph M Juran 对这一方法进行了推广。以Watts S. Humphrey 为代表的CMU SEI：CMM/CMMI，他们把SPC的理论用于软件的开发领域。SPC是适用于任何过程的一系列解决问题的工具，主要包括：柱状图，帕累托图，趋势图，因果图，控制图，散点图等，统计控制图是SPC中最强大的和应用最广泛的。统计是对数据进行收集、分析的技术和过程，以此帮助人们在面对选择时进行决策。统计学和概率论、数理统计密切相关，它们都是研究和揭示随机现象统计规律性的学科，“随机现象”指事物产生的结果具有不确定性，但是有符合统计规律性的现象。统计过程控制（SPC）就是我们用来研究过程的不确定性，分析其中的统计规律，识别过程改进，并指导分析与决策的一个工具或者技术。在软件过程改进活动中，SPC有助于人们理解人类过程的“可靠性”；为过程建立管理希望的边界；理解偏差的原因和模式；确认用于预测和计划的度量分析模型；对项目进行定量的管理和控制。
本文基于以下几个假设展开讨论：
读者从思想上接受和认可过程改进对产品质量的提高。
所在的组织已经经历了初级的过程定义和数据收集阶段。
软件过程的各种数据随机变量都服从或近似服从正态分布。
读者具有一定的统计学和概率论、数理统计的基础知识。
笔者结合自己的经验和实际工作，主要从以下三个方面来说明统计过程控制（SPC）在过程改进的应用，文中不涉及具体的概率统计基础知识的定义和公式推导。
一、建立过程性能基线，对项目进行定量管理
在CMM/CMMI模型中，组织过程性能（OPP）是第4级的一个过程域（PA），它是实现定量管理的前提和依据，是用来反映和衡量一个稳定过程的性能指标。定量项目管理（QPM –Quantitative Project Management）是CMM/CMMI模型第4级的另外一个过程域，是对项目管理的高层次的要求；用SPC作为工具来建立的过程性能基线，是进行定量项目管理的基础和依据，没有SPC就谈不上定量项目管理。
任何一个过程，无论它的设计有多么精确，执行有多么认真，一定程度的内在的或者自然的变异总是存在的，自然变异或者背景噪声是那些小的，根本无法避免的原因的累计。当过程中的背景噪声比较小时，通常被看作是过程绩效的一个可接受水平。在统计过程控制的框架中，自然变异通常被称之为随机因素的稳定系统。其它类型的变异有时候也会存在于过程之中，这种变异与背景噪声相比会对过程性能产生较大的影响，它通常表示过程绩效在一个不能接受的水平，这些不属于随机因素变异的资源被称为非随机因素。在非随机因素存在下的过程则被认为不在控制之中。
统计过程控制有助于软件工程人员识别、测量和分析各种噪声引起系统偏差的原因，从而采取措施减少和防范这种偏差，使过程趋于稳定。稳定的过程是在统计过程控制下的过程，即它的可度量特征或过程性能的基础分布是始终如一的，只有对稳定的过程进行统计分析，建立过程性能基线才是有意义的。统计过程控制及其相关的控制图是研究过程系统稳定性的有效工具。控制图以图形的方式表示过程随时间的变化，用于区别随机原因和非随机原因引起的偏差。在剔除非随机因素的影响之后，就可以利用统计过程控制中的XmR图得到过程的性能基线。
举例说明建立过程性能基线的过程，假设已经定义出了项目计划的过程，那么就可以通过度量项目估算的准确性，来检查项目的计划过程的能力。统计一段时期内组织内的所有项目的估算偏差，使用控制图来检查这个过程的稳定性，分析过程的性能，建立过程的性能基线。
明显有一些点超出3西格玛范围之内，这说明该过程是不稳定的，还存在一些异常噪音，需要去研究分析出现这些异常的根本原因，找出解决对策以保证过程中不再出现这样的异常。下图是剔除异常点之后，建立的过程性能基线。
其中控制中心值（CL），控制上线（UCL）和控制下线（LCL）是过程性能基线的主要参数，这些参数为软件工程人员以后制定项目计划和估算项目风险时提供了一个可参考的依据。而且，利用这个过程的控制图，还可以在实际项目应用中，监控该项目过程是否在控制范围内，及时发现过程中的异常情况，判断是否需要采取干预措施，使它回归到可控范围之内。同理
也可以建立其它过程方面的性能基线，比如说：生产率，进度，成本，质量等。
二、分析过程属性的影响关系，建立过程性能模型
几乎所有的工程分析中，模型都是非常重要的。模型分为两种，一类是机械模型，二是经验模型。机械模型来自于一些被验证的公理或者定理，比如：假设我们要测量一个铜丝中的电流，这一现象的模型就是欧姆定律，这一类模型就是机械模型，存在于各种资料中，人们需要做的就是学习和掌握它。可是对于另外一些问题并没有这样现成的模型供人们使用，而且也会因为环境等因素的变化，模型也会变化。这种模型就需要人们自己去分析总结，举例来说：通过统计和分析开发人员的工作经验、开发工具、项目业务内容等对项目质量的影响关系，建立一个产品质量与人员经验、开发工具、项目业务内容之间的关系模型，这就是经验模型。统计学可以帮助人们分析各种不同因素对结果的影响，建立过程或者系统的经验模型，用于分析和决策。
对于一个稳定的过程，通过对其中的相关因素和结果进行分析，即可建立起它们之间的相关性经验模型，例如，在软件项目中测试人员经常会遇到这样的问题，对于一个系统需要准备多少个测试用例，才能够充分的测试系统的质量。也就是说对于UT测试，每千行代码要写多少个测试用例，才能保证UT的质量。
下面就以UT测试密度为例来说明，如何使用SPC中的关系图来模拟测试密度与测试规模之间的相关性模型。首先，假定已经建立了组织的单元测试过程，并且经过了上一阶段的异常噪音分析，建立了相应的过程性能基线。其次，利用一段时间内连续记录的单元测试规模数和所用测试用例数的统计数据，绘制测试规模和测试用例个数之间的散点图，并利用模拟技术来寻找这两个属性之间的关系。通常需要先根据经验判断这两个属性之间的经验关系，一般表现为测试规模越大，则需要的测试用例越多。因此，可以利用这样一个线性模型进行表达，即：测试用例=规模*测试密度+修正因子。这就是一个关于UT测试中测试规模与测试密度的相关性经验模型。最后，就需要借助于统计过程控制技术，并利用过去成功项目的经验数据，求出模型中的两个参数：测试密度和修正因子。这样就得到了适合该测试过程中的测试密度与规模的相关性参数模型。在以后的类似项目中，就可以利用这个模型估算出每个模块具体应该写多少个测试用例，才能保证代码的质量和UT测试的充分性。
同理也可以类似的求出集成测试、系统测试中关于测试用例与规模之间的相关性经验模型。当然对于测试整个过程来说，其影响因素还包括很多方面，如果以测试结果Bug发现率作为一个输出的话，那么影响Bug发现的因素，包括了测试方案的质量，测试用例的质量，以及人的因素，时间，成本的因素等，那么要对测试质量进行建模的话，我们需要分别分析测试结果与各影响因素之间的相关性，最后才能得到一个考虑了多方因素后的多元的测试质量模型。但是，从作者多年的经验来说，目前的软件过程人为因素，不可控因素太多，要对一个过程整体进行量化建模还存在很大的难度，但是如果按照前面的思路，对局部建立相关性经验模型，还是可行的，并且如果结合几个局部的相关性经验模型，共同来分析一个过程输出还是很有参考价值的。
比如说：结合测试密度和Bug密度来看一个产品的测试质量，如下图：
横坐标是测试密度，纵坐标是bug密度，根据项目中各功能点的这两个数据画出的测试散点图，利用我们第一部分建立的测试密度和Bug密度的PPB的上下限，对坐标系进行象
限划分，其中只有落在中间方格内的是质量最好的，原因是因为这部分是在合理的测试用例下发现了合理的Bug，是符合公司过程性能经验指标的，其余象限不是测试密度异常，就是Bug密度异常，需要我们在测试总结时进行分析的。
三、采取革新手段，改进过程性能
统计过程控制（SPC）是用来识别过程中的噪音，进行过程改进，并指导分析与决策的一项技术。其目的就是为了对过程进行持续的改进，这一点在软件过程改进中，就是指能力成熟度的最高级CMMI5级——持续不断的改进和优化过程。在CMMI5级的根本原因分析（CAR）中，使用SPC中的帕累托图、鱼骨图来分析过程偏差的原因，制定相应的预防措施，防止或者减少这种原因的出现，使过程更加的稳定。这是一种问题解决型的改进，其过程本质上并没有发生变化，但它可以使过程更加稳定，控制的范围变得更窄，这同时也意味着管理控制的能力的提高。CMMI5级中的另一个过程域——组织革新与推广（OID）是通过使用新的流程或者新方法、新技术的首都，对原有过程进行革新，使得过程性能有一个质的提升。举个简单的例子：以前人们以自行车为交通工具，每小时的行程是20公里，可是换了汽车以后，速度提高了好几倍，达到了每小时上百公里，这就是一个革新，是本质上的飞跃。下图形象的说明了革新前后过程性能的变化。
组织过程改进到了高成熟度级别以后，过程已经非常稳定，过程性能基线也已经建立，并且形成了许多过程的模型。如果一直按照这个过程去执行，项目的结果就会在模型的预测之中。可是由于技术的进步，市场竞争的加剧，对项目的要求也越来越高，如果还是按照以前的流程和方法进行开发，就会导致在竞争中处于劣势。举例来说，以前一个月写几百行代码，生产率就已经很不错了。可是随着新的开发语言和开发工具的出现，现在要求生产率必须提高到2KLOC/每人月，才能保证项目按照进度完成，并确保项目的利润。这时就需要采取一种革新的方法对过程进行改进，也就说对过程进行一次彻底的改变，才能使过程性能发生一个质的飞跃。
以软件测试方面的革新为例，在早期对于测试主要是人工编写测试用例，在模块开发完成后进行用例测试，判断模块的质量。这个过程通常要花费很长的时间和很大的成本。随着新的测试方法和测试技术的出现，可以利用测试工具进行测试。只要在前期设置好测试的观点和测试流程，就可以在程序完成以后，使用测试工具进行自动测试。这样不仅节省了测试时间和费用，而且还可以防止因人为原因而产生的测试观点遗漏的现象，提高产品的质量。使用工具前，质量性能基线如下：
其中，中心值（CL）=4.2，控制上线（UCL）=5.8和控制下线（LCL）=2.0
使用工具后，质量性能基线如下：
其中，中心值（CL）=1.8，控制上线（UCL）=2.65和控制下线（LCL）=4.85
对比使用测试工具前后，测试中发现的故障密度，明显减少了，控制上、下限的范围也明显变窄了。同时也分析了测试所花费的工作量，也明显减少。通过以上的数据分析表明，这次引进测试工具对产品质量的提高，项目成本的减少效果明显。这里SPC的作用其实是一个指示器，清晰的说明了革新前后的过程性能改善的程度，同时可以用SPC分析革新的投入与产出比，评价改进的有效性等。
总之，正如CMM/CMMI模型不是万能的一样，统计过程控制（SPC）技术也不是万能的。SPC的另一个同等重要的成分是使用者的看法和经验，它只是一个工具，要让它发挥效果关键在于使用它的人。统计过程控制技术提供了一种对过程进行观察和分析的依据，形象的说，是一种诊断的工具，而不是治疗或解决问题的措施，对于具体问题的分析和解决还需要人们的经验去判断。统计过程控制技术的使用建立在组织和人员对过程、技术、管理等各方面具有相应水平的环境下，才能更好的发挥作用。设计度量和收集相关的测量数据去建立过程性能模型和进行过程改进是一种主动的统计过程控制方法，仅依靠控制图则是一种被动的方法。
SPC用于过程改进对于公司是十分重要的，但是也要注意一些问题：
不要把全部的度量值都用SPC来处理，不要为了SPC而SPC。
SPC仅仅用于项目或组织的某些重要方面。
在过程稳定前只是进行观察，SPC仅用于稳定的过程。
当采集的数据较少时，需要解释控制图的结果以观测某些报警信号。
在使用SPC技术前，要很好的理解度量数据，否则得不到所期望的结果。
理解如何定义数据、如何收集数据，对使用SPC去分析和表示数据是至关重要的。
在组织内，必须要求对数据的收集和报告按照统一的方法和格式，跨项目比较和合并数据时，更要小心从事
参考文献：
Measuring the Software Process —Statistical Process Control for Software Process Improvement. William A.FloracAnita D. Carleton
Metrics and Models in Software Quality Engineering (Second Edition)
Stephen H. Kan