评审的形式
1.人
如果就参加评审的人员而论,有以下几类评审形式。
① 同行评审(Peer Review):也翻译为“同伴评审”或“同级评审”或“对等审查”等。由软件开发文档的编写者的同事对软件文档进行系统的检查,以发现错误和检查修改过的区域,并提供改进的建议。
② 独立评审:安排一些人对成果进行个别检查,以单独完成对成果的评审,评审人员相互之间暂时不进行讨论。
③ 组内评审:项目团队内部组织的对成果的评审。
④ 相关项目成员评审:相关项目成员可以分为横向和纵向两类,所谓横向,指与本项目同时进行的项目的成员;所谓纵向,指历史上已经开发与这个系统有关的软件系统项目的成员。在必要时,也可以请规划中即将建设的软件项目的成员参加。横向和纵向可以是针对同一个用户而言,主要是为了在客户的业务上进行统一的规划设计,如统一的用户账号管理及统一的用户信息代码管理等;也可以是针对公司内部而言,这主要是在软件的技术和设计风格上进行统一的规划。以充分利用软件复用技术来提高效率和易维护性,充分考虑各系统之间的接口、兼容性和界面一致性。
⑤ 企业内评审:也可以称为“项目组外评审”,是企业内部抽调必要的力量进行组织的,有条件时也可请用户参与。相关项目成员评审是企业内评审的一种特例。
⑥ 邀请专家评审:在特殊情况下或为了特殊的目的,管理层或用户邀请专家对阶段成果进行评审。这些专家可以是软件技术方面的专家,也可以是与客户业务密切相关的行业业务专家,如国家某个行业信息规划人员和行业标准制定人员等。
⑦ 用户评审:以用户为主的评审,一般是把文档交给用户检查,或以用户为首组织的评审会议。一般情况下,每份需求文档都要经过数次的用户评审,尽可能地得到最终的确认。而设计文档则视情况而定,一般较少进行用户评审。
⑧ 第三方评审:用户委托第三方机构进行评审,如监理机构、检测机构和专家验收组等对需求设计文档或其他工作成果进行评审。
2.对象
如果就评审的对象完整性而论,有以下几类评审形式。
① 整体评审:在文档整体完成后,对需求或设计文档的整体进行评审。当文档比较大而难以进行整体评审时,可分而治之,分多次进行“部分评审”。
② 物理部分评审:不同评审人员对某一成果的某些物理部分内容进行评审,如按照文档章节、功能划分或模块划分等。
③ 逻辑部分评审:分阶段检查某一成果是否具有某个所期望的特性,或不同评审人员对某一成果的某些特性(如可读性或可维护性)要求进行评审。
④ 迭代评审:迭代开发模式中分阶段对部分内容进行评审,每一部分评审通过后即可作为下一阶段相关部分工作的基础,每一次迭代都包括需求、分析、设计、实现和测试活动。同时每次迭代都建立在前一次迭代工作的基础上,每次迭代都会生成更加接近最终产品的可执行版本。
⑤ 回归评审:原来的评审发现问题需要整改并再次进行的评审,以检查问题是否已经得到修改,同时检查是否出现新的问题。
3.环境
就评审的环境或使用的工具而论,有以下几类评审形式。
① 临时检查:在需要的情况下临时检查文档、评审人员与作者随时对文档中的问题进行讨论。这是评审中最不正式的一种,可以快速听取评审人员的意见。主要为了解决当前的某个特定问题,或对某个特定问题进行确认。临时检查也翻译为“专案评审”(ad hoc)或“随时评审”,可以及时沟通,及时发现问题。但要注意适度,在必要时进行。
② 工具评审:通过安装在网络环境上的管理工具软件将项目阶段成果提交给评审人员阅读,评审人员利用工具阅读文档后填写意见(如Domino.Doc)。
③ 邮件评审:通过邮件将项目阶段成果发给相关人员进行评审,评审人员通过邮件反馈意见。
④ 会议评审:相关人员集中在一起开会对项目阶段成果进行评审,这是最常用的形式。所以当提到“评审”时,很多人就会自然地联想到开会。
⑤ 远程会议评审:不仅在主会场进行评审,而且通过视频及音频与外地的评审人员进行实时在线沟通。这是会议评审的一种特殊形式,可以突破空间的限制,对于项目团队成员或评审人员有出差在外的项目是一个比较经济的形式。
4.效力
① 正式评审:得出是否批准通过的正式结论。
② 非正式评审:不具否决权的“评审”,也可以称为“评阅”,主要是为了讨论,收集意见和建议,不做是否批准通过的结论。
正式评审或非正式评审都可以通过会议、邮件及工具的各种形式,也可以是整体评审、部分评审或迭代评审。当然正式评审最好是整体文档完成后的评审,批准主要是针对整个文档的,但迭代开发的例外。
③ 观摩培训式评审:一般是一种会议形式,主要是为了培养新人。在评审会议召开时,可安排一些不同角色新人来旁听。他们不对评审的工作负责,而是以学习评审技术,体验评审工作为目的。