一、实验原理
正式技术复审(FTR)是一种由软件工程师进行的①软件质量保证活动。FTR的目标是(1)在软件的任何一种表示形式中发现功能、逻辑或实现的错误；(2)证实经过复审的软件的确满足需求；(3)保证软件的表示符合预定义的标准；(4)得到以一种一致的方式开发的软件；(5)使项目更易于管理。由于FTR 的进行使大量人员对软件系统中原本并不熟悉的部分更为了解，因此，FTR 还
起到了提高项目连续性和培训后备人员的作用。FTR 实际上是一类复审方式，包括“走查”(Walkthrough)、“审查”(Inspection)、“轮查”(Round-robin Review)以及其他软件小组的技术评估。每次FTR 都以会议形式进行，只有经过适当的计划、控制和参与，FTR才能获得成功。在后面的段落中，我们给出了类似于“走查”［FRE90，GIL93］的典型正式技术复审的指南。
二、实验步骤
1.复审会议
不论选择何种FTR 形式，每个复审会议都应该遵守下面的约束： ·复审会议(通常)应该在3 到5 个人之间进行。
·应该进行提前准备，但是每人占用工作时间应该少于2 小时。
·复审会议时间应该不超过2 小时。
在上述约束之下，显然FTR 应该关注的是整个软件中的某个特定(且较小)部分。例如，不要试图复审整个设计，而是对每个模块或者一小组模块进行走查。当FTR 的关注范围较小时，发现错误的可能性更大。FTR 的焦点是某个工作产品——软件的一部分(如一部分需求规约、一个模块的详细设计、一个模块的源代码清单)。开发这一产品的个人(即“生产者”)通知项目管理者工作产品已经完成，需要进行复审。项目管理者与“复审主席”联系，主席负责评估工作产品是否准备就绪，创建副本，并将其分发给两到三个“复审者”以便事先准备。每个复审者应该花1 到2 个小时复审工作产品、做笔记或者用其他方法熟悉这一工作。与此同时，复审主席也对工作产品进行复审、并制定复审会议的日程表，通常安排在第二天开会。复审会议由复审主席、所有复审者和生产者参加。其中一个复审者作为“记录员”，负责记录
在复审过程中发现的所有重要问题。FTR 将从介绍会议日程开始，并由生产者做简单的介绍。然后生产者将“遍历”工作产品、作出解释，而复审者将根据各自的准备提出问题。当发现问题或错误时，记录员逐个加以记录。 在复审结束时，所有FTR 的与会者必须做出以下决定中的一个：(1)工作产品可以不经修改而被接受(2)由于严重错误而否决工作产品(错误改正后必须再次进行复审)(3)暂时接受工作产品(发现必须改正的微小错误，但是不再需要进一步复审)。作出决定之后，所有FTR 与会者需要“签名”，以表示他们参加了此次FTR 并且同意复审小组所做的决定。
2 复审报告和记录保存
在FTR 期间，一名复审者(记录员)主动记录所有被提出的问题。在复审会议结束时，对这些问题进行小结，并生成一份“复审问题列表”。此外，还要完成一份简单的“复审总结报告”。复审总结报告将回答以下问题：1.复审什么？2.由谁复审？3.发现了什么，结论是什么？
复审总结报告通常是一页纸大小(可能还有附件)。它是项目历史记录的一部分，有可能被分发给项目管理者和其他感兴趣的参与方。复审问题列表有两个作用：(1)标识产品中存在问题
的区域(2)用作“行动条目”检查表以指导生产者进行改正。通常在总结报告中将问题列表作为附件。建立一个跟踪规程，以保证问题列表中的每一条目都得到适当的改正，这一点非常重要。只有做到这一点，才能保证提出的问题真正得到控制。一种方法是将跟踪的责任指派给复审主席。更为正式的方法是将这一责任分配给一个独立的SQA 小组。
3 复审指南
进行正式技术复审之前必须建立复审指南，分发给所有复审者，并得到大家的认可，然后才能依照它进行复审。不受控制的复审，通常比没有复审更加糟糕。下面给出了正式技术复审指南的最小集合：
1.复审产品，而不是复审生产者。FTR 涉及到别人和自我。如果进行得恰当，FTR 可以使所有参与者体会到温暖的成就感。如果进行得不恰当，则可能陷入一种审问的气氛之中。应该温和的指出错误，会议的气氛应该是轻松的和建设性的；不要试图贬低或羞愧别人。复审主席应该引导复审会议，以保证会议始终处于恰当的气氛和态度之中，并在讨论失去控制时应立即休会。
2.制定日程，并且遵守日程。各种类型的会议都具有一个主要缺点：放任自流。FTR 必须保证不要离题和按照计划进行。复审主席被赋予维持会议程序的责任，在有人转移话题时应该提醒他。
3.限制争论和辩驳。在复审者提出问题时，未必所有人都认同该问题的严重性。不要花时间争论这一问题，这样的问题应该被记录在案，留到会后进一步讨论。
4.对各个问题都发表见解，但是不要试图解决所有记录的问题。复审不是一个问题解决会议。问题的解决通常由生产者自己或者在其他人的帮助下来完成。问题解决应该放到复审会议之后进行。
5.作书面笔记。有时候让记录员在黑板上做笔记是个好注意，这样在记录员记录信息时，其他的复审者可以推敲措辞，并确定问题的优先次序。
6.限制参与者人数，并坚持事先做准备。两个人的脑袋好过一个，但是14 个脑袋未必就好过4 个。将复审涉及的人员数量保持在最小的必需值上。但是所有的复审组成员都必须事先作好准备。复审主席应该向复审者要求书面意见(以表明复审者的确对材料进行了复审。)
7.为每个可能要复审的工作产品建立一个检查表①。检查表能够帮助复审主席组织FTR 会议，并帮助每个复审者将注意力集中在重要问题上。应该为分析、设计、编码、甚至测试文档都建立检查表。
8.为FTR 分配资源和时间。为了让复审有效，应该将复审作为软件工程过程中的任务加以调度。而且要为由复审结果必然导致的修改活动分配时间。
9.对所有复审者进行有意义的培训。为了提高效率，所有复审参与者都应该接受某种正式培训。培训要强调的不仅有与过程相关的问题，而且应该涉及复审的心理学因素。Freedman 和Weinberg［FRE90］为每20 个人有效的参与复审而估算了一份1 个月的学习曲线。
10.复审以前所作的复审。听取汇报对发现复审过程本身的问题十分有益。最早被复审的工作产品本身可能就会成为复审指南。由于成功的复审涉及到许多变数(如，开发者数量、工作产品类型、时间和长度、特定的复审方法等)，软件组织应该在实验中决定何种方法最为适用。Porter［POR95］及其同事为这类实验提供了良好的指南。
三、实验用例
学生根据自己系统自行安排。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议