第二部分：为什么需要一个独立的评价和测试KPA（The Justification For A Separate Evaluation and Test KPA)
有五个重要方面能说明必须有一个独立的Evaluation and Test KPA，即：(1)评价和测试在促进向有纪律的软件工程过程的文化转变中的作用；(2)评价和测试在项目跟踪中所起的作用；(3)整个开发和维护在评价和测试部分的预算；(4)评价和测试训练对软件交付时间和成本方面的影响；(5)评价和测试对软件其余缺陷的影响(the impact of residual defects in software)。
1.促进文化转变
电子工程师和建筑工程师要远比软件工程师们训练有素。电子工程师们可以制造近乎0缺陷的包含上百万个晶体管的大规模集成电路。在有关Pentium处理器的热烈的缺陷声讨中，经常被忽略的是310万个晶体管中竟然只有一个缺陷。那么好了，再看看软件，你上次看到的在310万行软件代码中只有一个缺陷是什么时候？硬件工程师们没有继续达到更好结果是因为他们比软件工程师们更加smart。他们达到的质量水平幅度远远高于软件，因为他们更加训练有素，他们的开发和测试方法更加严格。他们愿意话更多的时间和精力来保证产品的完整性。他们真正认识到了缺陷所带来的影响：经济的或者其他的。
然而，另一方面，软件却是完全不同的方式。Gerald Weinberg的描述很著名：如果建筑师们也像软件工程使开发软件那样来建造大楼，来的第一个啄木鸟就将摧毁文明。
我们不得不承认软件工业相对于其他工程专业还十分年轻。如果你从Grace Hopper作为第一个编程人员的话，你可能会说它才仅仅50岁 (当然如果你将Ada Lovelace作为第一个的话，可能会所谓大一点) 。然而，更加切实的开始日期应当在1960年左右，也就是说我们软件工业也不过30多年。做个对比，IEEE在1984年庆祝其成立100周年，这意味着到1884年，已经有大量的电子工程师，从而形成一个专业协会。而在1945年，Mr. Hopper则在聚集软件工程师方面还十分孤独。
将软件工业从一种手工(艺)匠方法向真正的训练有素的工程层次迈进实在是一种文化的转折、跃变。CMM的首要的而且也是最重要的目标是，建立一种机制来对软件工程是引进文化改变。但是一个文化不可能发生激烈的改变，除非你深刻理解改变的重要性。必须全面理解向新的文化改变所能给我们解决的问题。最后这一点，将使我们引导我们来讨论测试在这一加速向训练有素的文化改变中所起的作用。
在1960年代后期，IBM是第一批开始应用正式软件工程技术的组织之一。一开始使用的是Dijkstra支持的技术。具有讽刺意味的是，并不是由软件开发人员发起这项努力的，而是软件测试人员。这一创始性工作是在Poughkeepsie实验室进行的，属于Philip Carol领导的面向测试的设计项目。
Phil是软件测试技术工作组(SW Test Technology Group)的一个系统测试工程师。这个工作组主要负责定义软件测试技术和工具以用于整个公司。大概在30年以前，他们就开始意识到你不可能通过测试将质量注于代码中。你需要像考虑测试过程一样也得考虑分析、设计和编码过程。作为测试人员，由于测试需要接触软件开发的所有方面，他们对问题有更加彻底深入的理解，因而他们取得了这一深入洞察
正是这一对问题的深入认识并将这一问题明确有力地向开发人员指出推动了软件开发文化的迅速改变。随着改进的开发和测试技术的应用，IBM的OS操作系统的缺陷率在下一个发布降低了1/10。这确实是在短时间内产生的重要的文化变革，特别是这涉及到了分布在不同地域的近千名软件开发人员。
这种变化的加速除了对问题的重视的直接推动外，另一个推动因素是与测试有关的一些因素，即在测试过程和开发过程集成中的反馈环。随着开发过程的不断改进，评价和测试过程并行地改进以反映新的成功准则。随着开发不断使用新技术，他们直接从测试人员那里得到及时的反馈---他们究竟做的怎么样-----因为测试人员就是专门来基于新的尺度对交付产品进行确认的。
一个具体的例子是需求撰写改进技术的应用，需求必须是明确的、确定的、逻辑上是一致的、完备的、正确的。有关结构化分析方法和面向对象的方法的培训课教系统分析员如何来写一个好的需求。如果在他们刚刚写完第一个功能描述时就进行模糊性评审，那么他们写的下一个功能就会更加清楚(out of box)。这种紧凑的反馈环—写一个功能、评价一个功能----有效地加速了其学习曲线。这样的话，过程从缺陷检测到缺陷预防转移的相当快速----他们正在写着清晰、不模糊的规格。
将这些经验与我们的整个软件工业做一个对比，结构化设计技术和面向对象的技术已经在25年前就可以应用了(是的，OO确实已经那么老了)，然而我们的时间的情况却远远落后于这些方法的最新技术发展水平。问题是除非组织理解了正在解决的问题，否则它不会全面接受或者全面理解一个解决方案（如：软件工程方法和技术），而集成的评价和测试正是问题理解的杠杆和关键。这里“集成评价和测试”被定义为将测试集成到软件过程的每一步中，它也是为掌握一个技术所需的必要的反馈环的关键部分。任何没有紧密反馈环的过程是具有致命缺陷的过程，因此评价和测量是加速文化改变的关键。
|
|