净室技术

净室技术

未经允许，严禁转载本栏目内容

本文经许可转载自软件工程专家网www.21cmm.com， 未经CSDN许可，请勿随便转载，谢谢合作

净室软件工程可用如下三个关键技术来刻画：置于统计过程控制之下的增量开发，基于函数的规范、设计和验证以及统计测试和软件认证。这些技术可分开使用，也可一起使用。采用这些技术可改进技术生产过程。 在统计过程控制下的增量开发 　　增量开发基于产品开发中受控迭代的工程原理------控制迭代。增量开发不是把整个开发过程作为一个整体，而是将其划分为一系列较小的、累积的增量。每个增量都是累积的，也就是所有以前的增量加上新的工作而不断累积。增量开发是开发小组保持对项目智能控制的基础。因为小组成员在任何时刻只需把注意力集中于工作的一部分，而不是一次考虑所有的事情。 　　增量开发把一个净室项目分成一个有序的开发周期序列。在每个周期完成一些用户功能。在每个增量开发完成时，产品的功能便可向客户演示。这样客户对产品有真实的感观认识，他们可不受约束重新确认需求或使需求更加清晰。这将使产品在完成时双方的不满程序降到最低。 　　增量开发计划由系统结构驱动。在成熟的生产线，一个参考结构可以规定高层的结构和接口，增量将致力于重用、修改或者在体系结构的已知位置开发组件。在新的开发中，顶层结构要么先于第一个增量，要么成为第一个增量所关注的对象。而后续增量将具体完成结构中的桩模块。在一个业已存在的旧系统中，增量计划可以和一个再工程计划吻合，使得变化不是动摇而是改进了系统。在维护环境中，修补和增强视为增量开发的一种延续，采用新增量开发中用到的同样的进程准则。 　　给定一个系统结构，在增量规划中，有许多因素要考虑。在嵌入式系统中，硬件开发的进度协调是一个要考虑的要素。在图形用户界面（GUI）系统中，第一个增量通常是制定用户接口原型，需求的最易改变部分是可讨论的。因为增量开发避免了整体框架，在给增量分配开发任务时总要考虑功能依赖的问题。比如，一个文件中的记号有其他用处时，必须对该文件做语法分析。影响增量开发的其他因素还有危险性、复杂性、新颖性、重用性以及使用频率等。如果可能，在较早的增量中要包含最具不确定性的部分，这样可尽早理解影响进度的因素。 　　智能控制、客户反馈、风险管理以及增量开发的优点是使项目组有效地进行统计过程控制。在每一增量开发结束时，要度量产品的质量并和小组的质量目标进行比较。比较的结果可以确定是否在控制之下，出现较小的偏差时要对项目进行追踪，而出现不可接受的偏差时要进行仔细的性能主审。如果确定了问题，小组要进行过程调整以便在下一个增量中改进性能。 基于函数的规范、设计和验证 　　净室采用的方法不仅有坚实的理论基础，而且可操作性很好。规范从一个外部视图（称之为状态盒），最后由一个过程（明盒）来实现。这些形式上不同、行为上等价的视图统称为盒子结构。盒子结构是基于对象的，并支持软件工程的关键原则：信息隐藏和实现分离。 　　黑盒规范定义了一个系统或其组件从输入到输出的映射的外部行为。只需定义外部行为，而不必描述内部状态或实现细节。黑盒只定义一个系统或其组件的用户视图。这里的用户可能是一个人，硬件单元或其他程序。下图从概念上描述了一个黑盒，其中SH代表激励历史(stimulus history),R代表相应的响应（response）。 　　一个激励序列是对系统的一系列单一输入。一个激励可能由用户产生（如一次按键或鼠标单击），也可能是硬件（如一个时钟脉冲或来自传感器的信号），或者是另一个软件组件（如操作系统或数据库）。一系列这样的激励组成一个独一无二的激励序列，它必须对应一个响应。黑盒由所有可能的激励列表、响应列表以及激励到响应的映射规则组成。黑盒是一种与状态无关，与过程无关的函数描述，其映射必须是完备的、一致的和可跟踪性正确的。 　　状态盒规范由黑盒导出，是通向实现的第一步。状态盒把为获得黑盒指定的外部行为而需保存的激励元素定义为状态数据。状态盒把系统或其组件所需行为定义为一个从当前激励和旧状态到对应响应和新状态的映射（变换）。定义状态数据后，就不必考虑激励历史了。下图描述了状态盒的概念视图。 　　状态盒只描述了系统或其组件的响应和状态更新，仍不包括过程实现细节。和黑盒一样，状态盒必须满足完备性、一致性和可跟踪正确性。 　　明盒规范用过程实现了对应的状态盒。这些过程实现了状态盒的映射规则，也有可能引进代表宏操作的新黑盒。过程必须足以完成必要的状态更新和所需的响应。下图描述了明盒的概念视图，为一顺序控制结构。分支、循环和并发控制结构也可在明盒中出现。引入的黑盒将在随后的求精过程中细化为状态盒和明盒。 　　与黑盒和状态盒一样，明盒也必须满足完备性、一致性和可跟踪正确性。明盒可由系统的设计语言或目标语言来加以定义。 正确性验证 　　在盒子结构规范设计中，定义黑盒来记录所需的行为。状态盒是黑盒的细化，定义了所需的状态数据，明盒是状态盒的细化，定义了所需的过程。每一种盒结构在小组评审时都要经正确性验证。小组采用基于函数理论的推理根据前一步来验证每一细化步骤的正确性。换言之，开发小组确认在每一步中定义的激励-响应映射规则都在后续步骤中被保持。 　　例如，在明盒过程验证中，函数理论的正确性定理为正确程序定义了必须满足和条件(Linger、Mills和Witt 1979)。开发小组在验证评审中将用想象和文字来验证这些条件的正确性。明盒过程可能包含无限多的路径，这些路径不可能通过基于路径的审查或软件测试来得到全部的检查。但正确性定义是基于验证单个控制结构而不是跟踪路径的。因为过程包括有限的控制结构，所以正确性定理将验证规定为有限情形的检查，并从逻辑上人武部验证了所有可能的使用情况。 　　所有净室开发的软件在由开发组提交给认证测试组之前都必须经过基于函数理论的正确性验证。一个可行而有力的验证过程使得开发组可以根据规范彻底验证软件的正确性。验证步骤对删除错误很有效，这也是净室提高软件质量的主要因素。 统计测试和软件认证 　　净室测试方法采用统计学的基本原理，即当总体太大时必须采取抽样的方法。首先确定一个使用模型来代表系统所有可能使用的（一般是无限的）总体。然后由使用模型产生测试用例。因为测试用例是总体的一个随机样本，所以可得到系统预期操作性能的有效的统计推导。 　　使用模型是指系统使用中所有可能的情形及其发生的概率。使用模型可由许多形式（包括马尔可夫模型和形式化的语法）来表示。在马尔可夫模型中，使用模型则一个状态集组成，状态之间由转移弧线连接，转移弧线指系统测试时可能的激励，并有一个概率值与之对应。概率指从给定状态进行特定转移的可能性大小。从起始状态穿过模型到终点状态便得到了一个测试用例。图1.4描述了一个使用模型。其中弧线代表激励，节点代表使用状态，每条弧线标有激励和发生概率。 　　使用模型是可重用的项目资源，它能产生任意数目的测试用例。实际上，测试一个系统可采用多种使用模型，对每种使用模型可采用多种概率分布。例如，许多系统提供一些很少使用的功能，但这些功能处理失误的严重后果，如在核电厂关闭反应堆。这种功能在一般的使用模型中的执行概率是很小的。当集中测试这种能产生重大后果的功能时，需要采用严格安全使用模型、冒险使用模型、恶意使用模型或其他特定环境使用模型。统计测试可以容易地结合其他测试一起进行。