《软件质量管理实践(共50页).doc》由会员分享，可在线阅读，更多相关《软件质量管理实践(共50页).doc（50页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、精选优质文档-倾情为你奉上软件质量管理实践4 同行评审在、等很多公司都有一个很好的实践，那就是代码复审。这种代码审查的过程，不是将代码发给某一个人或某几个人去看，而是强调程序员自己定期走上台，向人讲解自己源程序的活动。因为要向大家讲解自己的程序，程序员会极其重视自己的进度、代码质量，在写代码时，就时刻想着可能随时会被选中去做代码复审，所以会非常认真地对待每一行代码。公司为某省交通厅开发并实施了一套多层级公文交换系统。在平稳运行了3个月之后，出现了经常性地死机、公文流转串件现象。重新组织大规模，将近10天时间，仍没有很好地定位错误。“王哥，有时间吗？耽误您几分钟。这段代码有点问题，始终搞不定，您
2、能帮我看下吗？”“好的，是什么问题？”“公文流转系统里经常串件，在正常情况下，发给王处长的文件跑到高局长那里去了。”“咱们看看啊”“这段代码没有什么大问题，可能是使用了这个全局变量的事，通常它是个捣蛋鬼。”小张仔细检查了一下自己的代码，的确，轻易地使用全局变量，导致了这样一个很严重的问题。下面一组数据是软件工程中常用到的：AT&T的贝尔实验室在其开发中引入审查后的成功案例：生产率提高了14%，质量提高了10倍。有一个大型电力交换系统，发现错误的成本降低了10倍，在发现错误方面，审查的成效是测试的20倍。TRW对一个大型软件进行了研究，发现2019个由用户发现的错误导致代码变更。分析结果表明，在
3、这些错误中，通过代码审查可以发现62.7%，通过设计审查可以发现57.7%。本书中研究的同行评审，定义为“由软件工作产品生产者的同行遵循已定义的规程对产品进行的技术评审”。其目的是为了及早和高效地从软件工作产品中识别并消除缺陷，让软件变得更易读和维护，同时减少最终泄漏到产品发布时的缺陷。主要工作第一是发现工作产品中的具体错误，第二是通过对这些错误的分类和统计，发现共同的错误类型和将来避免这类错误的方法，提供今后对所发现的同类错误进行控制的数据。通过对开发过程中的反馈和从错误中汲取教训，避免今后类似的缺陷和错误发生。4.1 同行评审与测试的关系发现缺陷的手段为什么要引入同行评审而不是继续完全使用
4、测试呢？有些工作产品在早期阶段就可以进行同行评审去发现缺陷，但无法对其进行测试；即使到了编码阶段，测试活动也不能发现某些特定类型的缺陷（例如违反编程规范）。从图4-1（开发各阶段缺陷放大图）可以看出，随着开发的不断开展，缺陷不断泄漏和放大，最终形成的产品是一个灰色的距离用户真正需求很远的一个“东西”。这就需要在开发的过程中不断进行同行评审，减少泄漏到下一个阶段的缺陷。成功的同行评审是提高质量和生产率的重要因素，不管人们喜欢与否，审查过程会迫使每个人在一种开放式的环境中工作。一旦人们懂得了他们的工作都要接受同行评审，他们就会越早地将他们的工作公之于众，以待监督。在同级评审上的投入把组织的一些质量
5、成本从昂贵的测试以及后期的大规模返工转变为早期的缺陷发现。更重要的是，工作产品的作者学到了如何将工作做得更好，从而避免了缺陷。固然同行评审的准备、活动和跟踪需要花费一定的时间和工作量，但这些可以在测试中节省更多。从经济角度考虑，许多缺陷是在早期阶段注入的，越早消除缺陷就越能降低开发成本。据统计，对于保存精确记录的大系统，一套完整的同行评审体系能够使项目在每个测试阶段出现的错误减少了90%。这样一来，即使在综合考虑了同行评审活动成本的情况下，同行评审活动也会使测试成本下降50%80%。同时，通过同行评审，开发人员能够及时地得到专家的帮助和指导，加深对工作成果的理解，更好地预防缺陷，在一定程度上提
6、高了开发生产率。再者，消除工作成果的缺陷，可以提高产品质量，提高客户满意度。图4-1开发各阶段缺陷放大图总之，同行评审有助于“提高质量、提高生产率、降低成本”。但是要注意，同行评审不可能代替测试，正如测试不可能替代同行评审一样。那么，工作产品通过了什么样的评审才算合格呢？同行评审本身的要求有没有在质量目标里？评审的工作量和参加人员的资格、评审时间是否有要求呢?4.2 同行评审的种类和对象同行评审活动的关注点应该是工作产品中的缺陷，而不应该是工作产品的作者或者生产者，管理者也不应使用同行评审的结果去评价个人的行为。同行评审的分类有很多种，自从IBM的Fagan发明了同行评审之后，软件行业提出了很
7、多同行评审模型，比较著名的有IEEE1028评审、微软的技术评审、GillGraham审查、VanEmden审查、Yourdon结构化走查等。4.2.1 同行评审的种类本书中按照CMMI模型的提法，将同行评审分为3 类。（1）正式评审（Inspection），通常是由经过同行评审培训的项目经理或PPQA主持，规模在 37人之间为宜，一般在完成了一个工作产品后对其进行的评审。正式评审的目的在于定位并除去工作产品中的缺陷。（2）技术审查（TechnicalReviews），或称内部评审，通常由技术负责人或项目经理召集，三人以上参加。技术审查一般是在工作产品的中期进行或完成了某部分独立的工作产品时进
8、行，也可在书写草案遇到问题时就其中专门的一两项问题讨论和审查。也可以是检查工作产品与规程、模板、计划、标准的符合性或者变更是否被正确地执行。技术审查的目的在于通过对开发人员的工作产品的技术审查，提出改进意见。（3）走查（Walkthrough），又叫代码走查或代码走读，审查的范围根据需求的优先级通常由管理人员来确定，主要是静态质量分析和编程规则检查。通常是小型讨论会，一般是在工作产品形成的早期进行，作者有一定的想法时，希望从中获得一些帮助或补充一些想法。当然也可以在编制工作产品的任何阶段进行，两三个人参加，由作者主持，主要是评估和提高工作产品的质量或教育参加者。其中，“正式评审”是正式的，“技
9、术审查”和“走查”是常用的非正式同行评审方法。4.2.2同行评审的对象同行评审的对象包括所有软件开发的中间和最终工作产品，例如包括：（1）产品需求规格说明书；（2）用户界面规范及设计；（3）架构设计、概要设计、详细设计及模型；（4）源代码；（5）测试计划、设计、用例及步骤；（6）项目计划，包括开发计划、配置管理计划和质量保证计划等。所有这些会涉及的评审内容，应该在编制的项目计划或者小的开发计划中体现，不应该也不能是临时性的安排。 4.3 同行评审过程根据同行评审的重要程度，正式评审、技术审查和走查三种形式的流程和成果物的使用力度不尽相同，但其主要的步骤和内容大体一致，参见如图4-2所示的同行评
10、审流程图。图4-2 同行评审流程图4.3.1正式评审流程正式评审包括下述6个基本步骤。（1）预备：为保证评审的质量，可以先进行一个预备会议。会议上，由作者花几分钟的时间向评审组概要介绍评审材料，例如讲解一下本产品的目标是什么，相关的实现细节、开发标准等。应该允许甚至鼓励评审组成员动手查看工作产品，或者查看开发过程中所用到的检查单等。这个讲解的过程从某种角度上来说，也保证了作者提交工作产品的质量。会议结束时把文档分发给每位与会者，下发的材料应该控制在2小时之内审核完成为宜。这些文档可以包括： 要审查的工作产品； 参考文档； 工作产品评审检查表； 工作产品审阅情况记录表。（2）审查：在预备会和正式
11、评审会之间，评审小组成员会对工作产品进行彻底检查，并依据相关标准和准则评审工作产品，记录发现的缺陷、问题种类与严重程度、所用的时间等。（3）评审：在预定的正式评审时间内（会议时间建议控制在2小时），评审小组成员以会议形式聚在一起，依次对产品进行检查。每个评审员花一定的时间（一般为十几分钟）指出问题，并和作者确定问题和定义问题的严重程度。注意，评审过程中是发现错误，而不是现场改正它们。会议中，记录员详细记录每一个已达成共识的缺陷，包括缺陷的位置、简短描述缺陷、缺陷类别、该缺陷的发现者等。未达成共识的缺陷也将记录下来，加入“待处理”或者TBD标识，评审主持人将指派作者和评审员在会后处理评审会议中未
12、能解决的问题。（4）书写评审报告：评审主持人根据记录员的记录和自己的总结，在一天内写出评审报告，内容包括： 根据评审专家个人的输入创建总的问题清单； 加入会议中发现的问题； 剔除经确认属于重复或者无效的问题； 共同确定需要修改的问题及修改的程度。（5）返工：作者根据评审报告的决议，负责解决确定的所有缺陷和问题。（6）跟踪：评审组长必须确保所提出的每个问题都得到了圆满解决。必须仔细检查对文档的每个修正，以确保没有注入新的错误。4.3.2技术审查流程技术审查通常包括下述3个基本步骤。（1）准备：评审组长（通常是项目经理）要求项目组成员提供需要考虑的特定问题并分发评审材料。评审组长确定评审重点： 需
13、要注意的特定问题； 需要满足的特殊标准或规格说明； 需要审查的接口或依赖关系。（2）评审：评审人各自审查评审材料，目的是发现错误，而不是改正它们（通常每次评审会不超过1小时）。评审组组长应在一天内写出评审报告。评审会议内容包括： 汇总个人发现的问题； 加入会议中发现的问题。（3）跟踪：作者负责解决评审报告中的所有错误及问题。评审组长检查所提出的每个问题都得到了解决。组长起草评审发现报告： 问题或弱项清单； 小组对如何解决这些问题或弱项清单的建议； 行动事项。4.3.3走查流程走查对形式的要求更为简单，主要有下述两种方式。（1）参与者驱动法：参与者按照事先准备好的列表，提出他们不理解的术语和认为
14、不正确的术语。作者必须回答每个质疑，要么承认确实有错误，要么对质疑做出解释。（2）文档驱动法：作者向评审人仔细解释文档（或代码）。在此过程中，可以将评审的内容（如关键代码、架构图、业务逻辑图等）用投影仪投射到屏幕上，作者对产品进行讲解，评审人不时针对事先准备好的问题或解释过程中发现的问题提出质疑。它比参与者驱动法可能更有效，往往能检查出更多错误。经验表明，使用文档驱动法时许多错误是由文档讲解者自己发现的。在走查过程中，每个评审人都要记录错误或建议，会后要整理会议记录，作为走查报告。工作产品的作者可以根据自己的思路对走查报告质疑。注：对代码的同行评审其实就是代码走查，可以使用投影仪打出关键代码位
15、置与参与人员一起读，也可以几个开发人员一起进行交叉走查。选定的进行代码走查的范围根据需求的优先级来具体确定。4.4同行评审方式的选择对于同一个产品，根据所处于的阶段可以使用不同的评审方式。如对于工作产品刚刚勾画、起草时，可以采用走查方式；对于完成了某一个单独的章节，可以采用技术审查方式；待整个产品完成，使用正式评审全面考察。4.4.1三种同行评审方式的比较对不同的工作产品，可以根据表4-1建议结合项目情况进行调整和裁剪。表4-1三种同行评审方式的比较种类正式评审技术审查走查目的以比较详细的粒度，定位并去除工作产品中的缺陷表明工作产品与规约、计划、标准的符合性或者变更被正确地执行了评估、提高工作
16、产品，教育参加者入口准则工作产品符合已建立的准备准则发布了评审目的，工作产品就绪，作者准备好工作产品计划中标识时机工作产品全部完成完成独立的章节架构、蓝图、草稿规模38人35人23人评审材料相对较少中等或较多，需要根据评审的目的确定中等准备时间35天准备2天准备主持人专职主持人小组长/组长作者变更验证主持人验证返工组长验证，作为评审报告的一部分由的项目控制手段执行成果物缺陷清单和度量元总结技术评审报告，包括缺陷清单以及行动计划走查报告，缺陷记录以及改进建议4.4.2同行评审的结果同行评审的结果通常有3种：（1）正常：评审专家做好了评审准备，会议正常，结果明确，不需要再次评审；（2）延期：30%
17、以上评审专家没有做好准备，会议无法正常进行，需要确定再次评审时间；（3）取消：在初审阶段就发现很多问题，需要作者进行修正，然后再进行第二次同行评审。4.4.3正式评审的特征相对于走查和技术评审，正式评审具有一些明显的特征。（1）评审以一种正式的形式进行，如有正式的、事先定义好的有关职责的各种角色，并遵循组织规定的标准流程。（2）对于任何产品的评审，都会组建与之对应的专门评审组，包括作者、主持人、记录员以及评审员若干。评审组成员也可以包括项目经理、PPQA，但是不能有作者的直接领导或者管理者。（3）评审小组先召开一个预备会议，作者会针对工作产品向大家做一个总体的介绍，例如讲解一下本工作产品的目标
18、是什么，相关的实现细节、开发标准等。应该允许甚至鼓励评审组成员动手查看工作产品，或者查看开发过程中所用到的检查单等。（4）评审小组的主持人负责确定什么时间开始真正的评审会议，在预备会和正式评审会之间，评审小组成员会对工作产品进行彻底检查，并依据相关标准和准则评审工作产品。（5）在预定时间，评审小组成员以会议形式聚在一起，依次对产品进行检查，主持人负责对整个会议的进展进行控制，而记录员则负责记录下整个过程。（6）在工作产品中发现的每一个缺陷都会被认真记录下来，并被适当分类。（7）会议结束后，负责人需要分析有关缺陷，找出产生此缺陷的原因并加以修正。（8）主持人应确保所有的缺陷都会得到解决和修正。如
19、果过程需要加以变更的话，应将相关问题移交相关的过程质量组。正式评审的正规性特征还体现在按发生频率和严重程度，仔细划分缺陷的类型，并且把这些信息运用到缺陷预防阶段以及未来产品的同行评审过程中。4.4.4工作产品的同行评审方式对开发过程中产生的主要产品所采用的同行评审方式以及参加评审人员，可以参考表4-2确定。表4-2常见工作产品的同行评审方式和参加评审人员工作产品同行评审方式参与评审人员项目总体计划走查项目经理、产品经理、需求提出者、市场或销售代表、技术负责人、质量保证工程师、高层技术管理者和过程管理者用户需求说明书走查需求分析师、项目经理、架构师、设计师、工程师、质量保证经理、用户或市场代表、
20、文档编写者、业务专家和技术支持代表产品需求规格说明书正式评审需求分析师、项目经理、架构师、设计师、系统测试工程师、质量保证经理、用户或市场代表、文档编写者、业务专家和技术支持代表项目已定义过程正式审查过程改进组负责人、过程改进工作组成员、管理级的过程拥有者和使用过程的实践者的代表开发计划技术审查创建者、项目经理、维护者和程序员系统测试计划技术审查测试工程师、程序员（）或架构师（集成测试）或需求分析师（系统测试）和质量保证代表系统测试用例走查测试工程师、程序员（单元测试）或架构师（集成测试）或需求分析师（系统测试）、质量保证代表概要设计说明书正式评审架构师、需求分析师、设计师、项目经理和集成测试
21、工程师集成测试计划技术审查测试工程师、程序员（单元测试）或架构师（集成测试）或需求分析师（系统测试）和质量保证代表详细设计说明书正式评审设计师、架构师、程序员和集成测试工程师单元测试计划走查测试工程师、程序员（单元测试）或架构师（集成测试）或需求分析师（系统测试）和质量保证代表代码走查程序员、设计师、单元测试工程师、维护者、需求分析师和编码标准专家集成/验收测试记录和报告走查测试工程师、程序员（单元测试）或架构师（集成测试）或需求分析师（系统测试）和质量保证代表用户使用手册走查文档编写者、需求分析师、用户或市场代表、系统测试工程师、维护人员、设计师、用户教育设计师、培训师和技术支持代表用户界面
22、设计技术审查用户界面设计师、需求分析师、用户、应用领域专家、可用性或人体专家和系统测试工程师项目总结报告技术审查项目经理、产品经理、需求提出者、市场或销售代表、技术负责人、质量保证工程师、高层技术管理者和过程管理者4.5 迭代生命周期的审查审查是提高瀑布模型项目质量的好方法。但对于迭代项目来说，如何在短的周期来做该呢？需要考虑迭代开发生命周期中审查的角色。在瀑布型过程中，审查对成功是至关重要的，因为团队不看重较早开发的代码，也就是说，他们不会回到前面的“阶段”。同时，由于瀑布周期时段很长，以至于到下游阶段发现错误时，原作者常常已经帮不上忙，即使可以，他们也已经忘记了工作的内容。使用瀑布方法时，
23、审查是对抗糟糕质量的唯一安全措施。相反，迭代开发周期短（平均39周），每个团队成员都是确保迭代成功的关键，即当下游人员发现错误时，这些成员不仅可用，而且他们已经准备好并期望在生命周期中尽早开始修复工作。通常在进行工作产品审查时，大家倾向于无论看到的问题对于迭代成功的重要性如何，都会猛扑向任何发现的错误（甚至是极其微小、无足轻重的）。尽管审查似乎要求成员尽量争取完美，然而在短的迭代周期中，更应该关注的是完成工作。一定要记住迭代方法的原则是“让迭代自己证明自己”，允许质量可疑的事情进行。当实际使用时，我们将认识到它是否足够好。无论何种开发生命周期，审查中的主要反馈来自下游的使用者，因为他们将不得不
24、使用系统。对于迭代开发过程，唯一不同的是与其在交付到下一道“工序”前审查工作产品，不如把工作产品实际地立即投入使用，在实践中进行检验，这是它最重要的改进。那么这意味着在迭代生命周期中不应该有任何审查吗？不是的，但确实进行的次数比大部分项目团队少得多，特别是如果团队一开始就采用瀑布型的方法。如果真的接受迭代方法，那么审查的数量应该被自动地减少。举例来说，如果迭代项目的生命周期是六周，则应该考虑进行多少审查工作，而不影响完成迭代的工作。在迭代开发中，创建计划证明迭代过程的正确性是非常必要的。对于重视审查的项目团队，在初始阶段还有一个额外的步骤。就是要将需审查的每个工作产品映射到迭代中。假设限制每个
25、迭代过程中最多三个工作产品，那么对于六周的迭代过程，三个审查会显得很繁重，唯一的办法就是减少审查的数量，因而需要为审查计划提供许多提示，并且确保正确的人参与。，避免落入频繁审查的圈套。4.6 同行评审的注意事项为了有效地提高同行评审过程的质量，经常需要对过程数据进行度量（关于软件度量的专题，见本书第7章中相关内容），作为进一步提高过程的依据。公司有一次组织产品需求的同行评审，会议定在5号上午9：0011：00进行。开始之前采用邮件形式通知了参会人员，并没有把评审材料发给大家。会议邀请了两位技术负责人，人员都是对技术不是很了解，且不了解评审过程与意义的管理人员，没有安排专门的人员做会议记录。会议
26、上，大多数管理人员按照个人的喜好与想法来评价软件的优缺点，并且对此软件的开发人员进行评论，提出了偏离评审会议主题的各种意见，使得原本安排2个小时的评审会议时间延长到了4个小时。软件中存在的问题给予了很少的关注。主持人宣布了会议的主题。作者开始简述自己的产品需求，接下来评审提出自己的意见。评审员小李说：“关于查询结果排序：查询后的表格应该是动态的，现在FW是固定的，这个需要改进。”其他人也参与该问题的讨论。“如果继续使用FW提供排序功能，那么需要FW项目组进行修改，FW的负责人小张说说是否可行，打算怎么修改。”小张开始提出自己的想法以及如何改进，几个同行也都说出自己的想法，有时会遇到不统一的现象
27、，开始解释和说明，等这个问题讨论完了，才发现时间已经过去40分钟。大家继续后边的问题，2个小时过去后，需求评审只进行了一半，会议以没有评审结果而宣告结束，只能下次继续进行，会议中没有任何表格填写。通过上边的例子，我们看到在评审中发生了5个违反规则的做法：（1）采用邮件方式通知大家，没有专门通知到个人。（2）没有预先下发被评审的产品和检查单。（3）会议的焦点不是在确定问题上，而是转到了如何解决问题。针对问题的解决，讨论很多，同行评审会议最主要的是找到和确定哪些是问题，至于如何解决问题，可以在评审会后相关人员继续讨论。（4）主持人没有经验，没有很好地主持和控制会场局面，当遇到会议跑题的时候，一定要
28、记住会议主题，将讨论的焦点带回来，不然容易越走越远。（5）没有作缺陷的记录和发现工作量的记录。同行评审时，需要注意以下几点事项。4.6.1 同行评审遵循的原则同行评审有所谓的“123准则”：同行评审准备时间大于开会时间，同行评审期间发现的缺陷数量应该是同行评审准备期间发现的缺陷数量2倍以上，同行评审发现缺陷的效率是发现缺陷的3倍。（1）同行评审需要管理层的支持，如果没有，即使是目标明确的开发组成员也会抵制进行评审。管理层的支持包括建立评审策略和目标，提供资源、时间、培训和激励，并遵守评审小组的决定等。（2）同行评审是结构化的过程，涉及许多参与人员的角色，在评审专家的选择性上，一定要注意其中的互
29、补性。经验表明，同行评审的参加人员在他相关的技术领域与方向发现缺陷的效率较高，需要为参加人员分配职责，会议参加人员要从不同的技术角度发现缺陷。（3）对于每种类型的同行评审，应制定通用的工作产品评审检查表，必要时可以进行裁剪以适应特定项目的要求。工作产品评审检查表应涵盖审查计划、准备、实施、结束和报告准则。（4）评审开始前，评审人应提前准备好自己所关注和将要提出的问题。（5）评审的重点在于发现问题，而非解决问题，再加上认真细致的准备工作，可以最大程度避免在评审中浪费时间。（6）对于技术人员工作的审查，应由技术人员进行，管理人员不要参与。但应将评审结果和解决所发现问题的日期通知管理人员。（7）评审
30、的过程是对事不对人的，例如用“这个假设是错误的”来表述，而不是尖刻地说“你的假设根本不对”。（8）成功的审查要求所有参与人员精力高度集中，可能会使参与人员十分疲惫。因此，每个审查阶段最好不要超过2小时。对每个人来说，一天最好只参加一个阶段审查。（9）将评审数据输入到组织度量库中，用于监测评审效果，并管理和跟踪产品质量。相关的度量数据示例有：在全过程使用同行评审，要占10%的开发工作量；每20页叙述性文档，需要40人时；每12页概要设计，需要30人时；每1000行代码，需要55人时；使用一段时间后，评价一个项目或一个组织的审查结果需要1人月。4.6.2 同行评审关注的问题（1）有同行评审计划，并
31、在每次评审前进行详细安排，如邀请合格的专家参加评审，邀请被评审产品的作者参加评审，明确定义应该评审哪些内容，评审人员要有明确的分工。（2）对同行评审中发现的缺陷进行详细记录，如缺陷所属模块、缺陷严重程度、解决期限等，并安排相关人员对缺陷进行跟踪直至解决。（3）对评审的过程进行度量，如评审准备时间和评审时间以及这两个时间之比，评审准备期间发现的缺陷数和评审期间发现的缺陷数以及这两个数值之比，评审产品的规模和评审效率等。（4）为保证同行评审的独立性、公正性，需要有经验的组外同行参加，需要对评审人员的能力定期衡量，及时更新保证其有效。（5）对类似的软件进行评审和。有句话说得很好“你想不到的你的敌人会
32、告诉你”，通过对竞争对手产品研究，可以很好地提高工作效率。4.6.3 同行评审通过的准则同行评审通过需要满足以下的准则。1最小准则（1）工作产品已经返工和确认；（2）主持人已经发布审查报告。2基于组织的度量元或早期的审查，可以为这类工作产品设置出口准则（1）剩余主要缺陷数的估计是否在限定范围内；（2）剩余次要缺陷数的估计是否在限定范围内；（3）变更数量在限制范围内（例如：一个部门的指南规定，变更代码应少于评审代码的5%。Ebenau，1994，p.58）。4.6.4 同行评审的经验共享只有软件的生产者是唯一可能做到生产出无缺陷程序的人，任何人都对此无能为力。（1）所有的缺陷最终都应追溯到需求，
33、因为最严重的错误是“导致程序无法满足需求”的错误。（2）软件开发人员和管理人员首先应该尽早地和不断地进行各种软件质量保证活动（如需求和设计阶段同行评审和走查等）。（3）软件开发人员应避免检查自己的程序，利用同行评审的方式对代码进行审查（因为自己检查容易依照原有的程序设计思路进行，往往查不出问题）。（4）在进行各种分析和修复工作中，要充分注意修复工作所产生的影响效果和波及效果。（5）统计表明大约有60%的错误是在设计阶段之前注入的，并且修正一个软件错误所需的费用将随着软件生存期的进展而上升。错误发现得越晚，修复它的费用就越高，而且呈指数增长的趋势（见附录中1:10:100公理）。（6）程序中的大
34、部分错误往往是在一小部分模块中发现的，遵循普遍适用的“二八定理”（即80%的错误往往是由20%的模块所造成的）。（7）缺陷会掩盖或加重其他缺陷。也就是说，当一个程序有许多缺陷时，由于缺陷相互作用，使得发现和修复缺陷的过程更加复杂。这使得一些缺陷很难查找和修复。一个缺陷可能掩盖其他缺陷，使得这些被掩盖的缺陷难以发现，增加了它们逃过测试的可能性。（8）遵照规范化的方法，仔细复查和测试每个小程序模块，这比让任何测试组在你的程序中发现缺陷的效果要好。也就是说，尽早地将缺陷排除掉。测试不能避免缺陷的发生，只能是一种补救。4.6.5 文档审查重点文档审查要对文档的完整性、一致性和正确性进行审查。1文档的完
35、整性审查（1）用人工审查的方法，验证所提交软件文档是否齐全；（2）文档中是否包含对软件接收输入数据类型和边界值的描述或说明，包括最大值、最小值、键长、文件记录的最大长度、搜索准则最大值、最小样本尺寸；（3）对不可能提供固定的边界值（例如，某些边界值依赖于应用类型或输入数据）的情况，是否说明极值；（4）是否包含与保密信息有关的信息，应包括防止非法授权访问的措施说明。2文档的一致性审查（1）用人工审查的方法，审查文档内容和术语的含义前后是否一致，有没有自相矛盾的地方；（2）检查文档与程序的一致性；（3）检查书面文档与联机帮助文档的一致性。3文档的正确性审查（1）用人工审查的方法，审查文档内容是否正
36、确和准确；（2）是否有错别字；（3）是否有二义性的定义、术语或内容。4.7同行评审的度量同行评审和被业界认为是最主要的有效发现缺陷的手段（二者所发现的缺陷可以占到发现的缺陷总数80%90%，因此对二者的度量分析将更加重要。具体的度量过程、方法、度量元，会在本书中的“软件度量”相关章节中详细描述。本节仅就同行评审中应该注意搜集的数据进行一下说明。为了有效地提高同行评审过程的质量，经常需要对过程数据进行度量，通过度量分析可以看到同行评审效率怎样，测试效果如何，作为进一步提高过程的依据，不断改进的过程，提高产品质量。某款软件产品的设计文档有20页，按以往的估计，评审中将会有100个缺陷。但是，这次评
37、审实际上仅仅发现了60个，原因何在？可以使用鱼骨图、因果图对发现内容进行分析，是具体的同行评审过程执行得不好？还是经验不足？抑或是同行评审过程规定得有缺陷？是否规定了先看过再评审？还是产品的设计文档质量比较高？这些都需要考虑一下。4.7.1常用度量元对同行评审应进行度量，如需要获得评审准备的时间和评审时间以及这两个时间之比，评审准备期间发现的缺陷数和评审期间发现的缺陷数以及这两个数值之比，评审工作产品的规模和评审效率等主要内容。具体的度量数据应该包括：（1）主要问题的个数/同行评审投入的总工作量。这些工作量一般用人时来表示，其中包括准备、发现以及更正等所有环节和方面的工作量。（2）一般在缺陷会
38、议结束时估计，然后在同行评审结束时得到实际值。（3）我们的效率是否正常/工作产品是否正常。（4）评审准备时发现缺陷数和评审时发现缺陷数及其比率。（5）记录问题的个数/评审会议所用的时间，一般用个数/分钟表示。（6）评审会议结束后得到问题记录的速率。（7）反映评审会议的控制是否得当。（8）评审专家的准备是否充分。（9）主要问题与所有记录项的比率。（10）主要问题个数/所有记录项个数。（11）判断角色分配是否合理。（12）缺陷密度。（13）同行评审总缺陷数和有效缺陷数及其比率。（14）评审文档页数（代码行数）。（15）缺陷移除率和缺陷泄漏率。（16）准备时间和评审时间（小时）及其比率。（17）同行
39、评审的缺陷打开和关闭的情况统计。（18）同行评审的效率、评审速率的度量。（19）同行评审的覆盖率。4.7.2同行评审的质量准则根据WatteHumphrey于1998年提出的经验数据，设计阶段同行评审量应该占到该阶段工作量1/3或以上，代码评审工作量也要占到编码和阶段的工作量1/3以上。如果它们都只占到15%，此时同行评审的质量系数仅仅是0.5。业界的通用准则如下：（1）设计同行评审工作量应占设计阶段总工作量的1/3以上，其质量准则为：设计文档同行评审应该至少发现3个缺陷/页。经评审修改后，缺陷清除率1级100%，2级100%，3级80%以上，残留缺陷密度控制在0.5个/页以下。（2）代码同行
40、评审工作量应占实现阶段总工作量的1/3以上。（3）同行评审准备过程发现的缺陷数应该是同行评审会上发现的缺陷数的2倍以上。4.7.3建议的同行评审效率如果在软件开发全过程中使用同行评审及审查，它们的总工作量要占10%的开发工作量。1同行评审准备效率（1）需求250行（5页）/小时；（2）概要设计200行（4页）/小时；（3）详细设计150行（3页）/小时；（4）源码150行（无注释）/小时。2同行评审会议效率（1）每20页叙述性文档，需要40人时；（2）每12页概要设计，需要30人时；（3）每1000行代码，需要55人时。审查的效率取决于以下因素：（1）在准备和实施过程中所耗费的时间和工作量；（
41、2）实际的审查速度超过推荐的审查速度时，审查效率往往会降低；（3）最佳的审查速度取决于所审查的产品类型与审查人员的技能和经验。4.7.4同行评审覆盖率在有效的开发过程中，一般对同行评审有如下的覆盖率要求。（1）对需求的同行评审覆盖率要求100%；（2）对设计的同行评审覆盖率要求100%；（3）对系统和验收测试用例的同行评审覆盖率要求100%；（4）对代码的同行评审覆盖率要求不少于30%。 新编代码的关键部位和关键算法要进行100%的同行评审（此比例不能放松，每个分支的组合条件都要审查）。 非新编代码采取采样评审，采样比不少于25%。4.8评审常见问题根据Humphrey的经验，审查不能发挥作用
42、的原因大致如下：（1）最大的问题是进度紧张而且管理重视不足，使得审查流于形式；（2）实施审查的方法不当；（3）准备不足；（4）参与人员太多或者参与人员不能胜任，或者有管理人员参与；（5）一次涵盖的内容太多；（6）在记录会议中试图修复问题；（7）记录会议拖沓冗长；（8）对个人进行评价等。同行评审常见问题总结如图4-3所示。图4-3同行评审常见问题其中有些原因和解决方式在前面“同行评审遵循的原则”中已经讲到了，在本书的后续章节中也会述及。4.8.2准备问题 评审的问题很大一部分出现在准备上，这不仅仅是说某个项目的评审准备，甚至可能是整个组织内部对评审没有制定相关的标准和规范，没有建立组织级过程。现
43、象1：在项目计划中没有列入大的评审工作由于没有明确的组织过程遵循，造成评审计划草率、不合实际，或没有及时调整，或实施不力。由于计划组织不充分，评审资源没有得到保证，资深技术人员或者评审人员忙于工作，没有投入足够的时间。现象2：没有接受培训此评审人员的选拔是很重要的。如果确实没有合适的人选，那么在评审准备阶段进行评审所需的知识和技能的培训是很有必要的。评审员一般是领域专家而不是评审活动的专家，他们没有掌握进行评审的方法、技巧、过程等，因此需要对评审员进行培训。对评审员的培训也可以区分为简单培训与详细培训两种。简单培训可能需要十几分钟或者几十分钟，需要将在评审过程中需要把握的基本原则及要注意的常见
44、问题说清楚；详细培训需要对评审的方法、技巧、过程进行正式的培训，需要花费较长的时间，是一个独立的活动。对于主持人来说，掌握完整的审查原则和方法对他们来说是绝对必要的。培训不仅可以向他们传授基本技能，同时也有助于他们建立信心，来组织往往有争议的审查工作。现象3：直到评审会议上评审人员才看文档，而没有提前阅读文档并提出大部分问题造成这一现象的原因可能是评审人员事情太多，也可能是因为评审人员对会议有依赖心理，不愿意阅读文档，只希望到会议上听别人解说。不做准备而完全靠评审会议上的有限时间来进行评审是评审失败的主要原因。现象4：文档质量太差作者缺少自我检查，或因计划不合理，提交的文档是没有任何复查的“草
45、稿”。一定要注意，正式评审中提交的文档应该是经过被评审人员自己充分检查过的文档，不能把查问题的责任完全推给评审人员。对于明显未达到要求的文档，需要退回修改后再提交评审。判断作者在提交评审前是否试图完善了他们的产品。在工作进行了一小部分后即进行预评审以纠正系统错误，及早提供改进的机会，以便作者能够保持适度的热情。4.8.3焦点问题现象1：没有遵循2/8原则注意评审的重点要评审的对象内容需要有侧重点，一般按照2/8原则确定主要内容进行评审，而不要泛泛地对整篇文章进行处理。现象2：就某个文档而孤立地评审该文档，没有对照已有的成果和标准需求和设计是软件开发项目的中间文档，前面会有一些约定输入，也可能会要求遵守相关标准。除非是对这些输入的内容已经了如指掌，可以敏感地发现互相之间的不一致性；否则一定要考虑仔细对照相关的输