软件缺陷发现.pptVIP

2.1.7同行评审注意事项一次针对产品需求的同行评审定在某日上午9:00——11:00进行。之前邮件通知了与会人员，未发放评审材料。邀请了两位技术负责人，其他都是不很了解技术和评审过程与意义的管理人员，没有安排专人记录。结果可能是——会上，多数管理人员按个人喜好与想法来评价软件的优缺点，并对该软件的开发人员进行评论，提出了偏离评审会议主题的各种意见，导致会议时间延长到4小时。软件中存在的问题很少被关注。主持人宣布会议主题后，作者简述产品需求，评审提出自己的意见。评审员小李说：“关于……需要改进。”其他人也参与进来。“这需要A项目组配合修改，A组负责人小张说说是否可行，打算怎么改。”小张提出自己的想法及改进方法，几个同行说出自己的想法，有时不一致，开始解释和说明……该问题占用了近40分钟时间。继续……2小时后，需求评审只进行了一半。会议没有得到评审结果就宣告结束，只能下次继续。会议过程中没有任何记录。出了什么问题？没有专门通知到个人没有预先下发被评审的工作产品和检查单会议焦点不在解决问题上，而是转移到了如何解决问题主持人没经验，没能很好主持和控制会场局面没有作缺陷记录和发现工作量的记录同行评审应遵循的原则123准则同行评审准备时间等于或大于开会时间同行评审期间发现的缺陷数量应是同行评审准备期间发现的缺陷数量的2倍以上同行评审发现缺陷的效率是测试发现缺陷的3倍同行评审需要管理层的支持，否则，即使是目标明确的开发组成员也会抵制同行评审同行评审是结构化的过程，涉及许多参与人员的角色，选择评审专家时要注意其中的互补性对每种类型的同行评审，应制定通用的工作产品评审检查表，必要时可适当裁减以适应特定项目的要求评审开始前，评审人应准备好自己所关注和将提出的问题评审的重点在于发现问题，而非解决问题对技术人员工作的审查应由技术人员进行，管理人员别参与。但应将评审结果和解决发现问题的日期通知管理人员评审的过程是对事不对人的，例如，可以说“这个假设是错误的”，不能说“你的假设根本不对”成功的审查要求所有参与者精力高度集中，可能会令人十分疲惫，因此每个审查阶段最好不超过2个小时。每个人每天最好只参加一个阶段审查将评审数据输入到组织度量库中，用于监测评审效果，并管理和跟踪产品。例如：在全过程使用同行评审，要占10%的开发工作量每20页叙述性文档，需要40人时每12页概要设计，需要30人时每1000行代码，需要55人时使用一段时间后，评价一个项目或一个组织的审查结果需要1人月同行评审应遵循的原则同行评审通过的准则最小准则工作产品已经返工和确认主持人已经发布审查报告基于组织的度量元或早期的审查，可以为这类工作产品设置出口准则剩余主要缺陷数的估计是否在限定范围内剩余次要缺陷数的估计是否在限定范围内变更数量在限值范围内（例如：IBM某部门的指南规定，变更代码应少于评审代码的5%）2.1.8同行评审的经验共享所有缺陷最终都应追溯到需求，因为最严重的错误是“导致程序无法满足需求”的错误软件开发人员和管理人员首先应该尽早地和不断地进行软件质量保证活动（如需求和设计阶段的同行评审和走查等）软件开发人员应避免检查自己的程序，利用同行评审的方式对代码进行审查在进行各种分析和修复工作中，要充分注意修复工作所产生的影响效果和波及效果统计表明约有６０％的错误是在设计阶段之前注入的，且修正一个软件错误所需的费用将随着软件生存期的进展而上升程序中的大部分错误往往是在一小部分模块中发现的，遵循“二八定理”缺陷会掩盖会加重缺陷。遵照规范化的方法仔细复查和测试每个小程序模块，尽早排除缺陷。测试不能避免缺陷发生，只是一种补救。2.1.9同行评审的质量根据WatteHumphrey于1998年提出的经验数据，设计阶段同行评审工作量应占该阶段工作量的1/3或以上，代码评审工作量要占到编码和单元测试阶段的工作量1/3以上。若它们都只占到15%，此时同行评审的质量系数仅为0.5业内通用质量准则：设计同行评审工作量应占设计阶段总工作量的1/3以上,其质量准则为：设计文档同行评审应至少发现3个缺陷/页。经评审修改后，缺陷清除率1级100%，2级100%，3级80%以上，残留缺陷密度控制在0.5个/页以下。代码同行评审工作量应占实现阶段总工作量的1/3以上。同行评审准备过程发现的缺陷数应是同行评审会上发现的缺陷数的2倍以上。建议的同行评审效率如果软件开发全过程中使用同行评审及审查，它们的总工作量要占开发工作量的10%同行评审准备效率需求250行（5页）/小时概要设计200行（4页）/小时详细设计150行（3页）/小时源码150行（无注释）/小时同行评审会议效率每20页叙述