净室基础

净室基础

本文经许可转载自软件工程专家网www.21cmm.com，

未经许可，请勿随便转载，谢谢合作

　　净室理论基础来自于数学。Harlan Mills敏锐地看出计算机程序可以执行一个数学函数，从而为软件开发确立了合适的科学基础。在他的早期论文“结构化程序设计的数学基础”、“计算机程序设计的新数学”和“如何正确编写和认识程序”中，解释了软件开发基于数学的函数理论。Mills在软件测试的统计特性方面同样敏锐地确立了相应的科学基础，也就是说，软件测试只是从无限的可能使用中抽取的样本。他的早期论文，如关于计算机程序的统计验证“将统计学应用于软件认证。Mills提出的软件的科学基础使得净室软件工程成为一个真正的工程学科。对Mills的基本思想感兴趣的读者，可从1988年相关出版物以及Mills的早期论文汇编<<软件生产率>>(由Dorset House公司出版)中获得第一手资料。

函数理论

　　净室开发方法基于数学中的函数理论。一个函数定义了一个从定义域到值域的映谢，定义域中的每个元素都可在值域中找到惟一的元素与之对应。一个特定的程序好似定义了一个从定义域（程序所有可能输入序列的集合）到值域（所有对应于输入的输出集合）的映射。这样一个程序的规范就是一个函数的规范，描述了一个程序的定义域（或输入序列）到值域（或输出空间）的映射。

　　一个定义明确(well-defined)的函数有如下特性：完备性、一致性和正确性。因为一个程序规范描述了一个函数，所以它必须是完备的、一致的和正确的。

　　（1）数学完备性要求对定义域中的每个元素，值域中至少有一个元素与之对应。也就是说，每种可能的输入都必须定义，并有一个输出与之对应。

　　（2）数学一致性要求在值域中最多有一个元素与定义域中的同一元素对应，也就是说，每个输入只能对应一个输出。

　　（3）相对于需求的规范正确性由定义域专家判断。然而对于一个给定的正确的规范，某项设计及其规范的正确性是可以通过基于函数理论的推理来验证的。

　　Linger、Mills和Hevner（1986）提出的用于净室软件开发的盒子结构的方法取代了由Linger、Mills和Witt（1997）提出的将数学函数理论应用于软件开发的方法。被明确提出的有三种功能形式的盒子：黑盒、状态盒和明盒。

统计理论

　　净室测试方法基于统计学。过去的几十年中统计学在工程中获得了广泛的成功和应用。当从经济上或技术上无法测试样本全体时，可以使用统计抽样的方法。如果统计结果没有达到质量目标，生产过程需做必要调整。这种以统计学为坚实基础的从产品度量到生产过程之间的反馈循环，得到了广泛的认可和应用。怎样把这种方法应用于软件呢？在制造业，统计数字在于所生产产品的有形变化；在一些处理过程（如包裹投递）中，统计数学牌预期处理的偏差中，那么在软件中统计数学中如何产生呢？

　　在软件中，用于采样的全体(population)是所有可能使用情况的集合其中集合中的每个元素代表系统的一种可能运行情况。统计的目的是度量系统正确运行一个样本的能力。因为总体是无限的，完全的测试是不可能的，所以必须利用统计学方法来对系统发生做一个有效的推理。测试过程不论如何扩展，在所有可能的输入序列中都只能算一个很小的集合所有的测试活动只能是无限总体中的抽样。　　在净室软件工程中，统计测试既可用于产品检测（单开发过程循环的结果），也可用于过程检测（多开发过程循环的结果）。净室采用增量开发的迭代过程，这样可测量和提高运行的一致性。

净室小组的工作

　　净室开发小组完成三项主要工作：制定系统规范、开发和认证。开发小组通常很小，由3~8人组成，这样可减少协调和简化通信。小组中有一名组长。根据整个组的责任和进度优先级，任务在小组内部分配和协调。对于小组规模项目，一个小组足够了。这种情况下，小组在开发的不同阶段分别完成规范制定、开发和认证工作。对于中等规模的项目，可能需要组际(team-of-teams)方法。一个最初的组通常由一些最有经验的人组成。他们规范和定义系统的结构，开发并认证一两个增量，并为子系统制定规范。然后由这个初始小组的成员担任开发和认证各个子系统的小组组长。为了适应用户需求变化或系统层次策略的改变，初始小组在一段时间（1天或一个月或更长时间）后可能重组。对于大规模的系统，组际方法是必要的，可能会指定规范组、开发组和认证组。因此，应该组成三个初始组，一个组制定系统规范，一个组开发初始增量，还有一个组认证这些增量。之后这些组的成员在子系统层次上领导特定小组。无论是什么组织，所有小组成员都要接受净室技术培训。这种培训可在有经验的小组领导的指导下作为在职训练进行。

　　评审是净室小组的一项重要工作。每个产品从最初的概念到最后形成都要经历多次评审。有两种评审。一种称为开发评审，开发评审的焦点集中于技术策略、好的想法以及小组培训和交流。举例来说，一个小组成员可以召集人们来评论一个只有一两页程序的设计方案讨论的焦点是关于控制和最初数据结构的策略、算法折中方案等待。接着最好的思路产生了，这可能导致下一次开发评审时评论的是5页纸的方案。最初的开发评论可能很短，经常只有约半小时，但随着产品的进化，评论的时间将不断增加。一个产品可能要经历许多次开发评审。在成功的评审会上，通过积累的知识交流可提高效率并节省时间。这样随着评审的进行，小组成员对产品更熟悉。最后的产品将是小组所有成员智慧的结晶。

　　所有工作产品的简化是小组评审的显著目标之一。最初的思路几乎从来就不是最好的，所以评审的一个关键目标是在规范、设计和验证方面找到更好的思路。例如，一个较好的思路可使1000行的设计取代原来5000行的设计。验证（或维护）1000行代码要比5000行容易得多。为了简化或更好的思路而重新设计几乎总是一种有效的策略。分类结构的标识和重用常常导致简化，这种结构验证一次，可以永远重用。

　　第二种评审称为验证评审。这种评审通过形式化方法来验证工作产品的正确性和完备性，这些验证通常这样进行，设计者以口头方式逐一列举其满足基于函数的正确性条件的理由。小组按顺序检查每个条件，不允许有存在异议的情况。任何修改必须经过后续评审的重新验证。一个工作产品经过验证评审后而不再有更改的必要时就被认为是正确的和完整的。从这一点看，整个组对工作产品拥有主权，其中任何后续错误都应该由该组承担责任。在先前的开发评审中，每个参与者都已熟悉了被验证产品的结构和内容，所以在检查评审中效率得到了保证。另外，经常采用的是可重用的规范和设计模型，所以验证部分大体上也是可重用的。