评审中常见的问题

1．准备问题

评审的问题很大一部分出现在准备上，这不仅仅是说某个项目的评审准备，甚至可能是整个组织内部对评审工作没有制定相关的标准和规范，没有建立组织级过程。评审资源没有得到保证，资深评审人员其他工作比较多，没有投入足够的时间。评审计划草率、不合实际，或没有及时调整，或实施不力。项目经理没有为评审或改正保证足够的时间。

现象1：被评审人员缺少自我检查，或因计划不合理，提交文档是“粗稿”。提交的文档是应该经过被评审人员自己充分检查过的文档，不能把查问题的责任完全推给评审人员。应该有类似“冒烟测试”的过程，明显未达到要求的文档退回修改后再提交评审。

现象2：评审人员到评审会议时才看文档或才看到文档，而没有提前阅读文档并解决大部分问题。正式会议评审的准备不够充分，不做准备而完全靠评审会议上的有限时间来进行评审是评审失败80%的原因。造成这一现象的原因可能是评审人员事情太多，也可能是因为评审人员对会议有依赖心理，不愿意阅读文档，只希望到会议上听别人解说。

现象3：没有足够的时间改正已经发现的错误，如果没有有效的跟踪，久而久之可能忘记，或者不具备对开发团队的指导意义，造成错误可能会流转到下一环节。

2．焦点问题

就某个文档而评审该文档，没有对照已有的成果和标准。需求和设计是软件开发项目的中间文档，前面会有一些约定输入，也可能会要求遵守相关标准。除非是对这些输入的内容已经了如指掌，可以敏感地发现互相之间的不一致性；否则一定要考虑仔细对照相关的输入。

就某个系统而评审该系统，没有考虑相关系统。当客户或企业已经开发了多个软件系统之后，系统之间的相关性必须是考虑的因素，这些相关性包括数据之间的关系、业务之间的关系、用户管理、系统管理的一致性，操作习惯和界面的关联性和软件复用等。

过多地讨论问题如何改正，评审的目的主要在于指出问题。而一旦正确地确认了问题之后，解决问题就容易得多。大多数都能很快找到解决方案，而一时无法给出解决方案的问题可以在评审后研究讨论。

在小问题上花太多时间，捡芝麻丢西瓜。在一些无关紧要的事情上纠缠不清，争执不下，造成时间的浪费。当然要注意的是，有些细节是项目成败的关键，所以要分清什么是重要的细节，什么是不重要的细节。

评审与评价混淆，评审的目的是指出具体问题以便改进，评价是给最终工作结果及人员工作绩效下结论。

3．人员问题

评审人员搭配不合理，遗漏一些角度或一些层次的人员。和每个软件开发项目团队的人员搭配一样，评审人员的搭配也应该尽可能合理，考虑全面性和有效性。可以用上述评审角色层次结构与角度结构（可进一步完善）来发现选拔各个层次和角度的评审人员，建立公司级别的评审人员库，在需要评审的项目中针对具体情况组合评审队伍。

无论是企业内部还是用户都有可能找不到合格的评审人员，如用户看不懂建模图形，或者企业内部缺乏具备相关行业业务知识和相关经验的技术人员等。评审人员的素质对评审效果起决定性的作用，因此评审人员的选拔是很重要的。如果确实没有合适的人选，那么在评审准备阶段进行评审所需的知识和技能的培训是很有必要的。《问题解决心理学》说：“用有关的过去经验来解决当前问题的一个主要障碍就是，首先要找到相关的过去经验”来进行类比，而“类比思维的核心是通过一个映射的过程，将知识从一种情景转换到另一种情景”。而如果整个企业都找不到有人具备“有关的过去经验”，会大大影响评审的效果。

如果评审人员对必要性认识不足，认为评审不过是一种形式，不去努力发现问题，则评审必然是没有什么效果的。如果管理层对评审的必要性认识不足，就有可能造成资源不到位。软件开发队伍中总有一些被业内称为“大忽悠”的人士，这种人对专业技术或行业知识一知半解、不懂装懂，却能爬得很快。他们为了掩盖自己的不足，有可能吹毛求疵地找一些小毛病，来显示自己还能发现问题。

孔子说：“知之为知之，不知为不知，是知也。”在评审过程中应当要有实事求是的态度，不知道的事情应当问清楚，不要不懂装懂，盲目地下结论。杨振宁说：“知之为知之，不知也要知。”为了做好评审，评审准备阶段应当尽可能花时间使“不知”变为“知之”。

4．会议效果问题

什么都完全靠会议讨论来解决问题是不切实际的，会前不做任何准备必将影响评审效果。

会上蜻蜓点水，走马观花，没有深入考察要评审的文档发现潜在的问题。

注意力不集中，会议跑题。开会时东拉西扯，动不动就不着边际，离题万里。

对文档中某些术语概念的认知有差异、争执不下，纠缠不清。对于同一个词汇，不同人的理解不一样，争来争去最后才发现说的不是同一件事。

评审内容遗漏了关键部分，评审内容的完整性可以通过CheckList来保证。

虎头蛇尾，对发现的问题缺乏有效的跟踪及纠正措施，没有规定跟踪责任人。

如下评审工作的最佳实践主要在效果的保证、工作的导向、人员心理、避免盲目信任，以及保证完整性等方面。

1．保证评审效果

没有效果的工作还不如不做，所以做一件事情首先要考虑如何保证效果。要保证评审的效果首先应当保证资源，不但要保证评审的资源应当是质量合格且数量充足的，也要保证被评审的资源，使他们能及时地拿出“不冒烟的”阶段成果，及时地修改错误。

应当在公司层面结合行政管理与人力资源管理，建立保证评审效果的保障机制。评审与评价相结合将更能保证效果，虽然要区分评审和评价的区别，使管理人员不会不恰当地使用评审数据。但如果评审发现的问题的修改情况不与对项目团队或被评审人员的评价挂钩，评审的效果就会大打折扣。所以应该先评审后评价，评价是针对评审效果和最终成果的评价。也许在评审的过程中发现很多问题，但是这些问题如果都已经改正了，就应该给与鼓励，而不是以原来的文档有多少错误来评价这个项目或文档作者。

很重要的一点在前面也已提到，应当做好评审规划、评审准备并分清职责。评审规划和评审标准提前通知相关人员，评审人员应该带着问题进入评审会议。军事上说“不打无准备之仗”，外国人说“Haste makes waste”，古人说“磨刀不误砍柴工”，都指必须做好准备工作。

评审效果取决于评审人员的素质和投入，所以应当根据项目情况确定评审级别并挑选评审人员。避免“盲人给盲人引路”，必要时邀请行业业务标准制定人员参与评审。

评审事先应该建立入口和出口准则，评审开始应当符合入口准则，评审的结束应该符合出口准则。如果文档不容易理解，结合原型演示进行评审会起到更好的效果，特别是对于有用户参与的评审来说。

适度评审，分清缺陷与建议。缺陷是一定要修改的问题；否则会造成质量问题或成本及进度问题；建议可以采纳，也可以不采纳，项目组视情况而定。因为建议可能“镀金”，所以评审人员应当尽可能不提“镀金”的建议，同时也要在评审中指出需求或设计中出现的“镀金”问题。当然，对于“镀金”问题也要一分为二地看。有的“镀金”可能会形成产品的一些“亮点”，同时在成本上增加的投入又比较少，可以考虑保留。但对于投入成本太高，又不会有什么效果的就应当放弃。对于一种方案是否“镀金”，不同的人会可能有不同的看法。因此评审也要综合考虑ROI投资回报率，因为企业存在的目的就是赚取利润。要注意评审工作不管采用什么形式，形式只是手段，关键看效果和效益。

问题：如何看待编码快完成才进行文档评审，这样的评审是否走过场？

个人观点：由于项目条件的复杂性，编码快完成时文档才完成，这样的情况还是比较常见的。很多人因此就认为这时候评审是形式主义，走过场。“编码都编完了还有必要进行文档评审吗”？甚至有些人对于文档的必要性都提出了质疑。

确实，在开发过程中，由于口头沟通比书面沟通来得方便快捷，所以先以口头沟通方式使读者完成软件编码是常有的事。但笔者认为如果条件允许的话，还是很有必要尽可能早地在软件交付之前进行评审。一是因为这时候评审还是可以帮助发现潜在问题的，纠正还来得及；二是可以帮助对软件的评价提供某些方面的依据；三是为后面的软件维护工作留下一份合格的文档。

2．注意评审工作导向

现在都讲“以人为本”，什么是以人为本？每件事情都是人做的，特别是软件开发离不开人。人的素质决定了成果的质量，所以人的素质是最重要的因素。每件事情是为了特定的人群做的，工作成果是否符合这部分人的需求很重要，所以人的需求也是最重要的因素。因此评审中的“以人为本”是指人的素质与人的需求是最重要的，这里的“人”包括了与软件系统相关的所有的人—项目团队、企业、用户和软件的社会受众等；素质包括与项目相关的人的素质，在这里特别强调的是评审人员的素质；需求最主要是用户的需求，但也包括组织和项目成员的需求。因此评审工作应该以人性导向、用户导向、成本导向和社会导向。

Jesse Liberty在《Clouds to Code》中强调：“不要让客户离开你的视线，他们不关心你的技术是否先进。”在《客户驱动编程》中的一句话应该引起“技术导向”的人员的思考：“软件开发的目标不是创建伟大的软件，而是帮助客户创造财富，有人买才是开发软件的惟一目的。”

软件大师温伯格也说：“如果不明白自己在做什么，技术是毫无价值的”（在此不是宣传技术无用论，而是提醒人们要从技术中去发现人的需求，从人的需求出发去开发技术）。“质量就是对相关人员的价值”，比如对企业的价值是赚取了利润，对用户的价值是服务了社会，对项目团队成员的价值是学习了新的技术、经累了经验并获得了相应的报酬。

Donald A. Norman在《设计心理学》中提到“诺曼门”的概念，那些因为设计不周而难以打开的门、令人迷惑的电灯开关被称为“诺曼门”或“诺曼开关”。依此类推，难以使用的软件可以称为“诺曼软件”。作者感叹世界上有太多的东西在设计和制作过程中根本就没有考虑或是毫不在乎用户的需要，称某种产品为“诺曼门”，实际是承认了该产品的制作者没有关注用户的需求。每当一项新技术被开发出来，公司便把过去的技术抛开，让工程师制造出新颖、前卫且功能众多的产品，结果是用户不断陷入迷惑。要设计出以人为中心并方便适用的产品，设计人员从一开始就要把各种因素考虑进去，协调与设计相关的各类学科，用户需求应当贯穿在整个设计（软件开发）过程之中。

我们不妨把需求和设计评审工作中涉及的“人”分为如下4类。

• 客户、用户、老板和社会受众：我们说以用户为导向，用户是第一位的，但老板才是项目真正的“客户”。而客户的需求也有可能符合某些“标准”，也有可能他们不了解某些标准或不愿意遵守某些标准，因此无论是评审人员还是项目团队都要在这几个方面进行平衡。
• 文档作者：他们在完成文档后一般具有成就感和自豪感，同时又担心被奚落。因此对他们的建议就是应信任并能够尊重评审人员，虚心接受意见。
• 项目下游人员：设计、编码、界面、测试、实施并维护，他们也兼有评审的职责，应积极提出意见。不能事不关己，高高挂起。
• 评审人员：应当尊重作者的辛勤劳动，言词谨慎，要有根据。

不论是文档作者还是评审人员、下游人员都应当防止以技术为导向，避免为了学习新技术而不管软件系统需求是否需要这些技术，也不考虑这些新技术有多大风险。

3．注意各种心理问题

在心理上最常见的是面子问题，被评审人员把他人对文档的意见认为是个人批判而紧张拘谨，这是人之常情。而造成的双方急于辩护，敌视或对抗在心理学上称为“知觉防御”，即对不利于自己的信息回避并否定。

另一问题就是评审人员做好好先生。也可能是能力不足，不提问题，只会附和。亚里士多德说：“我们很容易回避批评——不说什么、不做什么、不存在什么”。知错而不发言是道德问题。各方应该针对工作成果中的问题，而不是针对作者，互相尊重，以减少双方挫折感。

戴明14点之一：“驱除恐惧，所有同事必须能大胆发言，提出问题或表达意见”。

Cosgrove说：“不愿意为设计书写文档的原因，不仅仅是由于惰性或者时间压力；相反，设计人员通常不愿意提交尝试性的设计决策，再为它们辩解”。通过设计文档化，设计人员将自己暴露在每个人的批评之下，他必须能够为其书写的一切进行辩护。如果团队架构因此受到任何形式的威胁，则没有任何东西会被文档化（引自《人月神话》）。不知道这些大师有没有夸大这种现象。

程序员既不愿写文档，也不善言谈。在软件工程学术上基于不同的假设出现了不同的软件开发过程模型，主要分为轻量级和重量级。因为项目成员不愿意写文档，所以有轻量级过程强调项目团队成员之间、项目团队与用户之间的充分随时的沟通；因为项目成员不善言谈，所以有重量级过程，强调“把要做的事情写出来，按写的去做，把做的事情记录下来”。这有点像管理学中的X理论和Y理论，似乎是分别基于性恶说和性善说的假设。

注意“金鱼缸效应”，一些新建的办公系统软件为什么受到抵制？在各种“金”字头的的工程建设中，政府部门为了有效了解各类业务的办理情况，提高业务透明度，开发了相应的办公系统软件，然而使用初期这些办公系统却在基层使用单位受到了冷遇。因为透明度提高了，一些工作疏忽或作弊很容易被发现，统计数字也真实了，难以“随心所欲”。这就是金鱼缸效应：“人人都喜欢把鱼放在金鱼缸，但人人都不愿意做里面的金鱼”。

Jesse Liberty在《Clouds to Codes》中说：“程序员认为他们是周围人群中最聪明的”，这里的程序员实际上泛指软件开发人员。因此不论是评审人员，还是被评审人员，都应该秉持谦虚、谨慎、尊重、感恩，以及协商的学习态度，避免过于自负、情绪化或有伤害的言辞。评审过程中要心态客观，眼光专业，对事不对人，重在讲道理。各方都应当把评审工作作为帮助，而不是批评。评审会议主持人要及时地限制各方的不良态度，但不限制评审人员有根据地指出问题，也不限制对方对问题进行解释。

在软件开发项目中既要考虑管理、风格、设计等各方面的一致性，又要考虑独特性；既要考虑使各项工作具有规范性，又要保护项目团队成员的创造性；既要讲究原则性，又要讲究灵活性；既要讲究管理上的可控性，又要保护员工的积极性。而质量管理、项目管理工作应该做到以上4个方面的平衡。

4．注意信任的副作用

同事之间相互信任是人类的本性，也是人类交互中的不可缺少的部分。诺曼先生在《情感化设计》中提醒：盲目的信任造成错误。人数多时产生的盲目信任，当更多人参加一个任务的检查时，安全性会降低，这称为“旁观者淡漠”。因为检查的人越多，每个人对其他人就有依赖心理，责任心就会降低，每个人完成的任务就越不仔细。当有更多的人负责时，信任起到了妨碍的作用。在评审工作中由于盲目信任造成的对评审效果的影响情况是较普遍的，最常见的是组内评审中出现的盲目信任，还有就是对资深技术人员的盲目信任和对上级的盲目信任。

当一个人质疑另一个人的工作成果时，会被认为含有缺乏信任的意思。但我们应该学会习惯于把质疑作为一种尊重的标志，而不是缺乏信任的象征，评审就是要有怀疑一切的态度。

5．评审工作完整性

评审工作的完整性很重要，遗漏重要的部分可能造成不可估量的损失，这方面的建议主要有以下几条。

• 规划好应该评审的不同的部分、角度和层次。
• 不同的人员评审覆盖不同的部分或角度。
• 大规模的软件可分物理或逻辑部分进行评审。
• 要考虑软件系统的泛一致性，要兼顾前后左右系统和标准。
• 要考虑各阶段工作成果的可追溯性，上下游的作者可互相评审，如设计人员评审需求，分析人员评审设计。
• 需求和设计变更是难免的，要给出需要进行“变更评审”的准则，注意必要的评审。

麦肯锡系统思维的结构化思路核心概念Mutually Exclusive Collectively Exhaustive（MECE）对我们评审工作的完整性具有深刻的指导意义。

评审工作就应该在整体思维下做到没有遗漏，没有重复。但是为了更好地利用有限的资源条件，要有优先级并突出重点。

6．关于组内评审的建议

不拘形式，随时评审（检查和走查）。同一个项目团队的成员如果作为安排比较方便，可以随时对需求或设计进行讨论。

安排团队内部不同人员可从不同层次和角度评审不同的部分，无法覆盖的部分或比较薄弱的部分一定要请求公司安排资深技术人员进行评审。

组内评审的缺点之一是评审的水平问题，受项目组内水平限制，有些潜在的问题可能发现不了。

组内评审的缺点之二是团队成员可能存在不愿提问题的心理，特别是在分析或设计人员是项目经理或资深技术人员的情况下。

不同的项目可以采用不同的评审策略，但组内评审都是必需的，只是形式可以灵活随意。如定制开发需求的评审策略可以是：用户评审→组内评审→组外非正式评审→正式评审；定制开发设计的评审策略可以是：组内评审→组外非正式评审→正式评审；产品研发的评审策略可以是：产品组内评审→项目组内评审→组外非正式评审→正式评审。

当然，（正式的）组内评审也可不单独进行，而是与“组外评审”同时进行。

7．关于网络评审的建议

网络评审可包括电子邮件或其他通信工具或网上管理工具，电子邮件或网上管理工具是一个很好的“异步”评审工具，而QQ、MSN或其他聊天工具可以达到“同步”的效果，弥补异步的不足。

应该注意及时收发邮件，养成及时收邮件的习惯。在条件允许的情况下，应该每天收取邮件，同时应该注意及时反馈意见。

对于疑问及时沟通，身在异处的多个人要共同讨论问题还是不很方便。因此可以通过回复邮件、网上聊天和电话方式及时沟通，澄清疑问。
发送邮件后最好再通过电话等其他通信方式提醒和确认收件人接收邮件，对于使用网上管理工具的也可通过类似方式提醒和确认。

网络评审的好处有：

一是基本不受地区限制，很多公司的业务扩展到全国或全球，网络评审的使用率将越来越高；

二是可以让评审人员提前阅读，做好正式评审准备；

三是附带保存了评审记录；

四是不像会议评审那样同时要花费众人的时间，特别是在会议跑题时。

Patricia Wallace在《Internet心理学》提到网络沟通在心理学意义上的优缺点——

优点之一是互相看不到对方，没有面子问题，评审人员可以直接说出问题，避免个人之间的冲突；

优点之二是写电子邮件或在网上管理工具填写意见一般比口头发言会经过更多（更成熟）的思考。

缺点之一是写电子邮件或在网上管理工具填写意见比口头发言麻烦，要多花很多时间；

缺点之二是缺乏会议评审中的那种气氛，激励与会人员共同协作来解决问题；

缺点之三是如果没有及时的提醒或确认，评审人员在事情比较多时对这项工作的优先级认识不同，可能会没有投入时间来进行评审。

因此网络评审应当和随时评审和会议评审相结合，在前期准备阶段通过网络使大家对评审对象有一个深刻的理解，结合随时评审解决一些容易解决的问题，最终通过较为正式的会议评审全面地把文档过一遍。

8．关于会议评审的建议

会议之前要做好各项准备工作，没有准备的会议一般是不会成功的。为了做好会议评审的准备，应该提前3~5天把文档发给评审人员，保证评审人员有足够时间阅读，不强迫评审进度。在会前通过非会议形式如邮件评审、随意评审来消除大部分问题。为节省时间，会议时间应尽可能短，参与人员尽可能少。

正式评审意味着要有批准意见的记录，而正式评审不一定必须通过开会这种形式，即正式评审≠会议评审。对于一些项目来说，如果其他形式的评审能够起到比较好的效果的话，会议评审不是必需的。

会议评审主持人应当做好协调工作，面对面的沟通尤其应当注意心理因素。文档作者应当虚心接受意见、避免争论、不找借口并且不固执己见；评审人员提出的问题应当有根有据，对事不对人、言辞谨慎，有疑问要及时澄清。

为了提高会议效率，要有一个安静的环境。主持人应当随时使大家注意力集中，避免发生跑题。

关于形式与内容的问题，我们以结婚仪式为例。形式的重要性在于向各方宣示这一事件具有重要意义，引起大家重视，包括引起新郎新娘的重视。但仪式一过，新娘就脱下婚纱，不用一辈子穿婚纱。后面的日子不必天天都如此庄重，才有轻松的气氛，这说明了内容比形式更重要。另外，结婚仪式的例子也说明了评审准备或其他形式的与会议评审之间的关系。在结婚仪式上如果主持人问新娘“您愿意嫁给新郎吗？”新娘不出意外会说“愿意！”，而不会说“我还要再考虑一下”或“不，还有些问题没有解决”。

广州每年召开贸易投资洽谈会，每次都引进数千个投资项目，数百亿美元的外资。但这些成果都不是在这几天的会议中就能达成的，而是经过了很多会前会和会后会。这个盛大的聚会只是一种形式，原来谈好的项目在这里进行签约。在这里，新认识的朋友需要进一步的沟通，新找到商机需要在会后进一步的落实。曾仕强先生说：“会而不议，议而不决”。会而不议是说大部分的事项会前已经议好，问题已经基本解决，不需要等到正式开会时再来讨论。会上只要宣布结果，可以大大缩短会议的时间；议而不决是说如果会议上大家对一些事情还有争议，则最好是不要急于形成什么结论。这样一是避免仓促做出决定；二是可以保护双方的面子，容易做好协调工作。

要注意的是做好会议记录，即评审记录和评审报告。为了保证记录的正确性和完整性，应该指定能够理解的人做记录，在记录时最好能说明每条意见的提出人。评审记录和报告要说明问题解决负责人、跟踪人和问题解决时间，并且应当及时发给相关人员签字确认评审记录和报告作为跟踪依据。

最后还要根据评审记录跟踪落实问题的改正，评审会议的成功≠评审成功。只有有效地发现“所有”缺陷，并修改了所有问题才是“评审成功”。

他山之石

在国外的软件开发实践中有很多很好的做法值得借鉴，这里简单地罗列了一些，如IBM、微软、日本软件企业、CMMI及RUP（Rational Unified Process，统一软件过程）等。

1．IBM的技术评审

IBM中著名的Fagan inspections（审查法，1976）是我们可以找到的最“古老”而系统的软件评审方法。Fagan七步审查法分为7步，即计划、概述、准备、审查、过程改进、修改和后继活动。有一个很著名的应用实例，休斯敦航天飞机的相关软件中缺陷的85%通过审查发现，15%通过测试发现，而完成后没有再发现缺陷。这一实例说明了评审工作的重要性，也说明了这次评审的有效性。

2．微软的技术评审

微软软件开发中的评审称为“技术评审”（technical review），包括Walkthroughs（浏览和走查）、inspections（检查和调查）和code reading（程序阅读）。微软的技术评审较强调由资深开发人员评审和发现问题，同时提倡新开发人员参与评审以获得更多经验，也鼓励新开发人员向老的设计思想提出挑战。

3．日本软件企业的技术评审

日本企业的质量管理是非常严格的，软件研发企业也不例外。现在越来越多的日本软件开发外包，所以在这里简单地提一下。
日本软件企业的技术评审包括审查和测试等，从软件开发流程的角度有试样审查、设计审查、编码审查和测试审查；从项目管理内容的角度有范围审查、质量审查、进度审查和成本审查；从审查实施人员角度有自查、项目管理者审查和独立第三方审查。
日本软件开发企业在软件开发的过程中，将验证和确认作为阶段性作业的审查结点。他们认为验证和确认的本质意义在于一是强化软件开发人员的责任感，让其认识到不能将不合格的工作成果移交给验证者和确认者；二是让验证者和确认者真正参与到软件开发中来，成为软件开发质量把关的真正力量。

4．RUP中的技术评审

RUP的指南中提供了如下3种复审。

• 复审（Review）：一次正式的会议，在会议上向用户、客户或其他相关各方介绍阶段成果，以征求对方的意见和批准。
• 检查（Inspection）：一种正式的评估方法，将由非制作者本人的个人或小组详细检查阶段成果，以查明是否有错误、是否违反开发标准及是否存在其他问题。
• 走查（Walkthrough）：一个复审过程，由某个开发人员领导一个或多个开发团队成员对他（或她）所编写的阶段成果进行检查，同时由其他成员针对技术、风格、可能的错误、是否违反开发标准和其他问题提出问题并发表意见。

5．其他评审方法

• Gilb/Graham方法：这是一种比较严格的方法，强调用审查来量化产品质量。分为4个阶段，即动员大会Kick-off meeting（总体会议overview）、个人检查individual checking（准备preparation）、记录会议logging meeting（审查会议inspection）和编辑editing（返工rework），强调先各自检查、小部分取样检查、获取并分析错误密度分布和错误类型，对大型项目完成10%就checking10%。
• High－Impact Inspection：强调使用各种分析技术来发现缺陷并应了解软件历史、合逻辑的论据和使用场景，强调细察特定方面胜过简单地查找缺陷，经过个别检查阶段后进入讨论阶段。
• Phased Inspection：（分阶段）一系列严格的指定角度的检查，每次只检查某一成果是否具有某一个所期望的特性。这些特性可以是关于质量的（如可移植性和可维护性），也可以是关于技术的（如某个算法逻辑的正确性）。