24.3其它评审方法.PDFVIP

第二十四章 评 审 389 检查表 有效检查法 · 你的检查表是否着重将检查员的注意力引向过去常发生错误的地方？ · 是否侧重于缺陷检查而不是纠错？ · 在检查会议之前检查员是否有足够的准备时间？每一位检查员都作好了准备吗？ · 每一位参与者是否都扮演不同的角色？ · 会议是否开得富有成果？ · 会议是否限制在2 小时之内？ · 协调者在指导检查方面接受过特殊的训练吗？ · 在每次检查中，错误类型数据是否都作了收集，以便于你今后制作检查表？ · 是否收集了准备和检查率，以便可以优化将来的准备和检查？ · 每次检查所指定的条款是否都落实了？是由协调员本人还是重新作了检查？ · 管理员是否明白为什么他不参加检查会议？ 检查概述 检查表可使检查员注意力集中在某一类错误上。由于检查过程有标准的检查表和标准的各 司其职的人员，它是一个有组织的过程。它也是一个自我优化过程，因为它使用有正规的反馈 循环以提高检查表质量、监控准备和检查速度。有了以上对过程的控制和优化，不管它怎样开 始的，检查很快就成为一种强有力的方法。软件工程学会 （SEI）已经定义了用于度量软件开发 过程效率的技术标准。检查过程表明了何为最高水平。同时，检查过程应是有组织的、可重复 的，并能使用可度量反馈以提高检查质量。你同样可将本方法实际应用于本书所讨论过的任何 技术中。在开发过程中将这些思想归纳起来，那么简单地说，它们可使你所在机构向着最高质 量和生产率的层次进军。 24.3 其它评审方法 其它评审方法不像检查方法那样得到实际经验的有力支持，所以目前它们所涉及的范围不 广。本节所讨论的评审方法有：普查、代码阅读、软件演示。 普查 普查是一种流行的评审方法。普查这个词定义并不严密，因为人们实际上可称任何类型的 评审方法为“普查”。 由于普查定义不严密，所以也就很难对其给出确切的定义。当然，普查包括二人或多人讨 论设计或代码这种情况。普查可能就像即席的随意探讨会一样不正式。有时它也可能像一个预 定的会议或送给管理者的总结报告一样正规。在某种意义上讲，“什么地方有两或三个人聚在一 起”，什么地方就存在普查。普查方法的支持者赞成使用这样一个宽松的定义。所以本文只打算 找出普查的一些共同之处，剩余的细节留给你自己去处理。 普查通常由接受评审的设计或代码的主持者所采用。 第二十四章 评 审 390 · 普查的目的是为了提高程序的技术质量，而不是评估程序。 · 所有参与者通过阅读设计或代码为普查做准备并寻找错误。 · 普查可为老资格程序员向新手提供传播经验和合作精神的机会，它也为年轻的程序员 提出新方法，并向一些过时的结论挑战提供机会。 · 普查通常需花费30 到60 分钟的时间。 · 普查侧重于发现错误，而不是纠正错误。 · 管理人员并不参加普查。 · 普查这个概念是灵活的，它也适应于特定的场合。 你能通过普查获何收益 如果用得恰当，普查可得到和其它评审方法类似的结果，就是说，它一般能发现程序中30% 到 70%的错误（Myers 1979,Boehm 1987，Yourdon 1989）。普查的检错效率比评审稍低一些， 但是在一些场合，普查还是相当有效的。 如使用不得当，普查可能会造成不少麻烦。普查的最低效率为 30%，这并无多大价值。至 少一个组织已经发现对代码的扫视检查将是“异常不合算”的（Boeing Computer Services）。 Boeing 发现，说服项目人员自始至终应用普查方法是困难的，而且当压力增大时，应用普查方 法几乎是不可能的（Glass 1982）。 检查和普查的对比 检查和普查有何差别？以下为二者差别摘要。 性质 检查 普查 正规协调者培训 是 否