什么是评审

1.1   什么是评审

1.1.1  IEEE729-1983规范

在正式的会议上将软件项目的成果(包括各阶段的文档、产生的代码等)提交给用户、客户或有关部门人员对软件产品进行评审和批准。其目的是找出可能影响软件产品质量开发过程、维护工作的适用性和环境方面的设计缺陷，并采取补救措施,以及找出在性能、安全性和经济方面的可能的改进。

1.1.2  评审的目标

在软件开发与测试的各个阶段进行相应的检查,有利于软件产品与过程的质量提高。

1.1.3  定义

1.1.3.1  同行评审

由软件工作产品创建者的同行们检直该工作产品,识别产品的缺陷，改进产品的不足。

1.1.3.2  管理评审

由软件项目/产品管理者对项目过程中管理活动进行评估,识别过程缺陷，改进管理活动。

1.1.3.3  单人评审

由单独一个评审员对简单的工作产品进行评估，识别产品的缺陷,改进产品的不足。

1.2   评审准确

1.2.1  评审入口准则

1. 评审组长被任命
2. 评审在相关计划中被定义
3. 被评审的产品准备就绪
4. 评审 员经过评审规程的培训
5. 评审员应经过被评审问题的技能的培训
6. 协调员应当受过如何执行评审的正式培训，或者应当参加几次评审的经验
7. 《项目计划》已经制定

1.3   评审过程

1.3.1  同行评审准则

1. 评审产品,而不是评审设计者(不能使设计者有任何压力)
2. 会场要有良好的气氛
3. 限制争论与反驳(评审会不是为了解决问题，而是为了发现问题) 
4. 指明问题范围,而不是解决提到的问题
5. 展示记录(最好有黑板，将问题随时写在黑板上)
6. 组评审时会议人数应在5-9人为佳
7. 组评审时评审员中应包括被评审产品作者的同行。( 例如对程序设计文档的评审，评审员中应包括其他程序设计人员)
8. 组评审时评审员中应包括被评审产品的上下游相关人员。( 例如对程序设计文档的评审，评审员中应包括详细设计人员和后续的编码人员)
9. 坚持会前准备工作
10. 对全部评审人员进行必要的培训
11. 参与人员不了解评审
12. 评审没有被安排进项目计划
13. 评审会议变成了问题解决方案讨论
14. 评审人员事先对评审工件没有足够了解
15. 评审人员关注于非实质性问题
16. 忽视组织细节
17. 会议时间过长

1.4   评审的误区

1.4.1  评审的误区

1.5   风险分析

学太多的历史悲剧告诉我们风险无处不在，不学会控制它，就一 定会被它所控制必风险分类。

1.5.1  风险分类

1.5.1.1  软件风险

这种风险分析主要是确定软件中要测试什么，测试的优先级，测试的深度。

1.5.1.2  规划风险

这种风险主要是为了防范未计划而影响项目进度的事件发生。比如测试人员突然离开导致人员不足、软件的需求的突然变更。