1、1,第6章 软件评审,2,内容提要,6.1 为什么需要软件评审 6.2 软件评审的角色和职能 6.3 评审的内容 6.3.1 管理评审 6.3.2 技术评审 6.3.3 文档评审 6.3.4 过程评审,3,内容提要,6.4 评审的方法和技术 6.4.1 评审的方法 6.4.2 评审的技术 6.5 评审会议流程 6.5.1 准备评审会议 6.5.2 召开评审会议 6.5.3 跟踪和分析评审结果 6.6 小结,4,6.1 为什么需要软件评审,总体来说，在开发过程中，评审可以让我们获得以下收益： 提高项目的生产率。这是由于早期发现了错误，因而减少了返工时间，还可能减少测试时间。 改善软件的质量。 在
2、评审过程中，使开发团队的其他成员更熟悉产品和开发过程。 通过评审，标志着软件开发的一个阶段的完成。 生产出更容易维护的软件。主要原因是：对于被评审的软件，评审者必须是非常熟悉的；同时，在评审过程中，一定会产生并利用很多证明文档，于是评审就迫使开发者产生出许多有用的文档，而这些文档如果不是因为评审，则在整个项目期间可能都不会生产。此外，评审过程也将增加对所开发软件的理解。,5,6.2 软件评审的角色和职能,评审组长（Moderator） 宣读员（Reader） 记录员（Recorder） 作者（Author） 评审员（Reviewer、Inspector）,6,评审员的主要职责,熟悉评审内容，为
3、评审做好准备。 在评审会议上应该关注问题而不是针对个人。 主要的问题和次要的问题可以被分别讨论。 在会议前或者会议后可以就存在的问题提出建设性的意见和建议。 明确自己的角色和责任。 做好接受错误的准备。,7,6.3 评审的内容,6.3.1 管理评审 一个组织之所以需要管理，是为了能更好的进步和发展。为了达到这个目的，通常需要对原来的发展状况进行回顾，分析并总结出存在的问题和改进的措施。这也就是为什么进行管理评审的原因。 管理评审就是最高管理者为评价管理体系的适宜性、充分性和有效性所进行的活动。 管理评审的主要内容是组织的最高管理者就管理体系的现状、适宜性、充分性和有效性以及方针和目标的贯彻落实
4、及实现情况进行正式的评价，其目的就是通过这种评价活动来总结管理体系的业绩，并从当前业绩上考虑找出与预期目标的差距，同时还应考虑任何可能改进的机会，并在研究分析的基础上，对组织在市场中所处地位及竞争对手的业绩予以评价，从而找出自身的改进方向。,8,管理评审的目的,适宜性 有效性 充分性,9,管理评审的输入,近期内、外审的评审结果； 顾客信息反馈； 相关方关注的问题； 工作业绩与存在的问题； 纠正与预防措施实施情况； 上次管理评审有关决定和措施的执行情况； 可能影响管理体系变更的情况 （如：法律、法规的变化，组织机构或产品、活动的变化、外部环境的变化等）； 管理方针、目标和指标的适宜性及其实现情况
5、。,10,管理评审的输出,管理评审报告需要包含以下内容： 管理评审的目的、时间、参加人员及评审内容； 管理体系及过程的适用性、充分性、有效性的综合评价和需要的改进； 管理方针、目标、指标适宜性的评价及需要的更改； 资源需求的决定和措施； 管理评审所确定的改进措施、责任部门和完成日期。,11,管理评审流程,12,6.3.2 技术评审,技术评审的目的 发现软件在功能、逻辑、实现上的错误； 验证软件符合它的需求规格； 确认软件符合预先定义的开发规范和标准； 保证软件在统一的模式下进行开发； 便于项目管理。 技术评审的输入 评审的目的是说明为什么要进行该评审，该评审的实施目的是什么； 评审的内容包括需
6、求文档、源代码、测试用例等； 评审检查单（检查项）； 其他必须的文档，如对设计文档进行评审，那么需求文档可以作为相关文档带入技术评审会。 技术评审的输出技术评审报告 会议的基本信息； 存在的问题和建议措施； 评审结论和意见； 问题跟踪表； 技术评审问答记录（通常作为附录出现在报告中）。,13,6.3.3 文档评审,文档评审的目的 文档评审的内容 在软件开发过程中，需要进行评审的文档很多，主要包括如下内容： 需求评审，对市场需求说明书、产品需求说明书、功能说明书等进行评审。 设计评审，对总体设计说明书、详细设计说明书等进行评审。 代码评审，对代码进行审核。 质量验证评审，对测试计划、测试用例等进
7、行评审。,14,6.3.4 过程评审,过程评审的作用如下： 评估主要的质量保证流程。 考虑如何处理和解决评审过程中发现的不符合问题。 总结和共享好的经验。 指出需要进一步完善和改进的部分。,15,过程评审流程,16,6.4 评审的方法和技术,特别检查（Ad hoc review） 轮查（Pass Around） 走查（Walkthrough） 团队评审（Group Review） 检视（Inspection）,17,检视、团队评审和走查异同点比较表,18,6.4.2 评审的技术,缺陷检查表 规则集 评审工具的使用 Gerrit Jupiter SourceMonitor 从不同角度理解产品 场
8、景分析技术,19,6.5 评审会议流程,6.5.1 准备评审会议 在评审会议开始之前，评审组长需要发出评审通知（评审内容、会议时间、会议地点、参加人员等），并且将相关待评审的相关资料也发送给参加会议的评委。其主要的目的有两个： 让参加会议的人员对会议的内容有一定的了解，在会议前做好准备，避免盲目的参加会议而浪费自己和其他人的时间； 如果有评审员在会议时间有其他紧急的事情，可以及早反馈给评审组长，以便召集人重新确定评委或者评审会议改期召开。,20,评审会议召开时间点,21,选择哪些评审材料,由于作者意愿和评审会议时间的限制，不大可能对所有交付的产品和文档都进行评审，因此，需要由评审组长和作者一起
9、协商选定需要进行评审的材料。 Daniel Freedman提出了一些材料筛选的原则： 基础性和早期的文档，如需求说明和原型等； 与重大决策有关的文档，如体系结构模型； 对如何做没有把握的部分，如一些挑战性模块，它们实现了不熟悉的或复杂的算法，或涉及复杂的商业规则和开发人员不了解的其他领域； 将不断被重复使用的部件。 总之，大体原则为：选择那些最复杂和最危险的部分进行评审。,22,打包分发评审材料,通常如下材料需要被打包： 需要评审的部分可交付产品和文档； 定义了可交付产品的前期文档； 评审会议成员需要的所有表格； 有助于评审员发现缺陷的工具和文档，如缺陷检查表、规则集等； 用于验证可交付产品
10、的测试文档。,23,合理安排评审活动进程,在评审会议正式开始之前，评审组长还需要收集每个评审员的准备时间，并在审查文档中记录总的准备时间。 当这一切准备就绪之后，评审组长还要制定相应的活动进度表，安排会议房间，并将时间、地点等相关信息通知评审会议成员。 安排会议时应注意以下几点： 至少提前2-3天通知评审会议成员； 不要安排同一个人一天参加多个评审会议； 根据工作情况，适当安排评审会议，合理协调项目进度和评审会议之间的关系，不要让彼此相互影响。,24,6.5.2 召开评审会议,评审预备 评审开始 成员介绍 评审员进行演示或说明 评审员就不清楚或疑惑的地方与作者进行沟通 记录员在会议过程中完成会议记录 评审决议 评审结束 评审中应把握的几个原则,25,6.5.3 跟踪和分析评审结果,跟踪 有条件接受的缺陷跟踪 不接受的缺陷跟踪 分析 有效性 效率和成本,26,6.6 小结,人的认识不可能100%符合客观实际，因此在软件生存期的每个阶段的工作中，都可能引入人为的缺陷。 在某一阶段中出现的缺陷，如果得不到及时的纠正，就会传播到开发的后续阶段中去，并在后续阶段中引出更多的缺陷。 实践证明，提交给测试阶段的产品中包含的缺陷越多，经过同样时间的测试之后，产品中仍然潜伏的缺陷也越多。 所以必须将发现缺陷的工作提前，在开发时期的每个阶段，都要进行严格的软件评审，尽量不让缺陷传播到下一阶段。,
