各种评审的形式

1．人

如果就参加评审的人员而论，有以下几类评审形式。

• 同行评审（Peer Review）：也翻译为“同伴评审”或“同级评审”或“对等审查”等。由软件开发文档的编写者的同事对软件文档进行系统的检查，以发现错误和检查修改过的区域，并提供改进的建议。

• 独立评审：安排一些人对成果进行个别检查，以单独完成对成果的评审，评审人员相互之间暂时不进行讨论。
• 组内评审：项目团队内部组织的对成果的评审。
• 相关项目成员评审：相关项目成员可以分为横向和纵向两类，所谓横向，指与本项目同时进行的项目的成员；所谓纵向，指历史上已经开发与这个系统有关的软件系统项目的成员。在必要时，也可以请规划中即将建设的软件项目的成员参加。横向和纵向可以是针对同一个用户而言，主要是为了在客户的业务上进行统一的规划设计，如统一的用户账号管理及统一的用户信息代码管理等；也可以是针对公司内部而言，这主要是在软件的技术和设计风格上进行统一的规划。以充分利用软件复用技术来提高效率和易维护性，充分考虑各系统之间的接口、兼容性和界面一致性。

• 企业内评审：也可以称为“项目组外评审”，是企业内部抽调必要的力量进行组织的，有条件时也可请用户参与。相关项目成员评审是企业内评审的一种特例。
• 邀请专家评审：在特殊情况下或为了特殊的目的，管理层或用户邀请专家对阶段成果进行评审。这些专家可以是软件技术方面的专家，也可以是与客户业务密切相关的行业业务专家，如国家某个行业信息规划人员和行业标准制定人员等。
• 用户评审：以用户为主的评审，一般是把文档交给用户检查，或以用户为首组织的评审会议。一般情况下，每份需求文档都要经过数次的用户评审，尽可能地得到最终的确认。而设计文档则视情况而定，一般较少进行用户评审。

• 第三方评审：用户委托第三方机构进行评审，如监理机构、检测机构和专家验收组等对需求设计文档或其他工作成果进行评审。

2．对象

如果就评审的对象完整性而论，有以下几类评审形式。

• 整体评审：在文档整体完成后，对需求或设计文档的整体进行评审。当文档比较大而难以进行整体评审时，可分而治之，分多次进行“部分评审”。
• 物理部分评审：不同评审人员对某一成果的某些物理部分内容进行评审，如按照文档章节、功能划分或模块划分等。
• 逻辑部分评审：分阶段检查某一成果是否具有某个所期望的特性，或不同评审人员对某一成果的某些特性（如可读性或可维护性）要求进行评审。
• 迭代评审：迭代开发模式中分阶段对部分内容进行评审，每一部分评审通过后即可作为下一阶段相关部分工作的基础，每一次迭代都包括需求、分析、设计、实现和测试活动。同时每次迭代都建立在前一次迭代工作的基础上，每次迭代都会生成更加接近最终产品的可执行版本。
• 回归评审：原来的评审发现问题需要整改并再次进行的评审，以检查问题是否已经得到修改，同时检查是否出现新的问题。

3．环境

就评审的环境或使用的工具而论，有以下几类评审形式。

• 临时检查：在需要的情况下临时检查文档、评审人员与作者随时对文档中的问题进行讨论。这是评审中最不正式的一种，可以快速听取评审人员的意见。主要为了解决当前的某个特定问题，或对某个特定问题进行确认。临时检查也翻译为“专案评审”（ad hoc）或“随时评审”，可以及时沟通，及时发现问题。但要注意适度，在必要时进行。
• 工具评审：通过安装在网络环境上的管理工具软件将项目阶段成果提交给评审人员阅读，评审人员利用工具阅读文档后填写意见（如Domino.Doc）。
• 邮件评审：通过邮件将项目阶段成果发给相关人员进行评审，评审人员通过邮件反馈意见。
• 会议评审：相关人员集中在一起开会对项目阶段成果进行评审，这是最常用的形式。所以当提到“评审”时，很多人就会自然地联想到开会。
• 远程会议评审：不仅在主会场进行评审，而且通过视频及音频与外地的评审人员进行实时在线沟通。这是会议评审的一种特殊形式，可以突破空间的限制，对于项目团队成员或评审人员有出差在外的项目是一个比较经济的形式。

4．效力

• 正式评审：得出是否批准通过的正式结论。

• 非正式评审：不具否决权的“评审”，也可以称为“评阅”，主要是为了讨论，收集意见和建议，不做是否批准通过的结论。

正式评审或非正式评审都可以通过会议、邮件及工具的各种形式，也可以是整体评审、部分评审或迭代评审。当然正式评审最好是整体文档完成后的评审，批准主要是针对整个文档的，但迭代开发的例外。

• 观摩培训式评审：一般是一种会议形式，主要是为了培养新人。在评审会议召开时，可安排一些不同角色新人来旁听。他们不对评审的工作负责，而是以学习评审技术，体验评审工作为目的。

需求与设计评审活动的角色分工

1．角色分类与原则

需求与设计评审需要的角色首先要有评审组长，即这个项目的整个评审工作的组织者，需要有管理、评审及会议主持等工作经验。其他除了文档的作者及记录人员之外，主要的角色就是评审人员，这一角色可以由具有以下不同角度知识技能经验的人员构成。

• 项目管理专家：具备项目管理知识与经验，主要是为了检查需求或设计对项目管理的可能影响，现行项目管理工作与这些文档中所提要求的符合性。
• 质量管理专家：掌握过程与文档相关规范，这些规范可以是行业内部通用的，也可以是企业内部制定的。
• 软件工程专家：掌握软件工程、需求和设计建模方法，能够对文档中表达方法的正确性进行判断。
• 相关行业专家：具备丰富的行业业务经验，一个好的系统分析员也应该是好的业务专家。对于需求评审来说，有客户或所建系统相关行业专家的参与是至关重要的。
• 企业资产库管理者、中间件和平台专家：“永远别重新发明轮子”，软件开发一般是将系统建立在某种平台之上或者使用某些中间件。而每个企业针对自己使用的开发方法都会有一定的积累，如类库、系统框架、用户管理、系统管理、信息代码管理和界面管理等都是可以复用的资源，不需要从头开发。
• 相关系统开发人员：在后面提到的前后左右相关的项目成员。
• 内部后继环节人员：包括编程语言及工具专家／数据库专家、界面设计师／美工和测试人员和维护人员等，他们一方面对需求与设计文档进行熟悉；另一方面也可以检查文档是否可以被理解，也可以其知识和经验进行判断。
• 某类硬件专家：与硬件系统较密切的软件开发项目，如电梯、手机、机器人和驱动等，需要对这些硬件的性能和接口较熟悉的人员。
• 产品经理、类似产品和竞争对手分析人员。
• 最终用户、客户和行业标准制定人员。

11.全球化专家／用户所在国文化专家：对外包或外销软件开发项目而言。

以上只是提供一个较为全面的角色选项，不是每种角色都有一个人，而是一个人可以兼多个角色。评审组成员的构成也不是一定都需要里面的所有角色，具体项目要具体考虑，选择其中必要的角色进行搭配。

2．角色构成因素

评审人员的选择是评审效果的关键，需要考虑以下因素。

• 项目重要性：项目重要性是决定角色构成的最重要的因素，评审角色的构成因素首先要根据项目的重要性而定。这与需要投入的成本有关，对于重要的项目一般会更多地投入资源，提高评审级别。
• 项目复杂度：项目的复杂度也是决定角色构成的因素之一，根据温伯格的公式，项目管理的复杂度相当于功能规模的平方数。笔者认为还应该考虑技术复杂度、技术新鲜度和文档复杂度等因素。
• 项目组成员的能力成分和水平：评审角色构成还应当根据项目团队成员本身的各项技术水平，特别是分析和设计的技术水平如何，行业领域知识是否丰富来进行搭配。

除了团队内部自己进行评审之外，评审团队最好是一些独立于项目团队之外的成员构成。Bhuvan Unhelker在《基于UML的软件项目的过程质量保障》中说：“要保持质量职能的独立性，只有通过指定项目以外的人员来承当角色才起作用”，测试工作也有“独立性”的要求。
应当注意的原则是人数要少而精，一个人可以兼多个角色，但要覆盖各项人员需求。需要说明的是，不具备评审能力的不应参加，可以通过旁听来提高水平。

3．基本角色职责

• 评审组长：制定评审计划、确定或制定各项评审准则、必要时组织评审人员进行培训、组织必要的资源、进行评审分工、确保正式评审准备充分、分发待评审文档、必要时召开并主持评审会议、向有关领导报告评审结果，并且跟踪评审错误的改正。
• 评审人员：必要时参加与评审有关的培训、按评审计划阅读待评审材料、保证对待评审材料的理解、与待评审材料作者讨论，并且指出和记录问题。
• 文档作者：按评审计划准备并按时提交待评审材料、必要时对材料进行解释、必要时参加评审会议，并且在确定需要改进时按时完成修改。
• 记录人员：评审会议中记录评审人员提出的问题及相关讨论。
• 项目经理：制定保证评审和改正的项目进度计划，还要确保评审准备时间、评审会议时间及错误的改正时间。而且评审安排及结果与所有项目成员沟通，必要时参加评审会议、阅读评审报告、分析缺陷原因，并且改进项目质量。

1．层次管理概览

• 过程规范：是否符合过程规范。
• 文档规范：是否符合文档模板规范。
• 文档语法：是否使用通用术语，是否符合某种建模标准或分析设计方法。
• 文档语义：是否表达清晰且正确。
• 文档逻辑：是否考虑周全，符合相关行业标准。
• 文档美学：是否最佳表述。
• 结果优化：是否最佳分析设计。

过程规范和文档规范主要保证规范性，文档语法和文档语义主要保证可读性，文档语义和文档逻辑主要保证正确性，文档美学和文档优化主要保证最优性。

2．质量层次模型在评审中的作用

质量层次模型在评审中的作用主要体现在以下几个方面。

• 可以使评审工作有层次并有阶段地开展，管理层次按照规范性→可读性→正确性→最优性的方向逐步提高要求。
• 可以用于确定评审人员层次结构，每个评审人员比较擅长或适合哪个层次的评审可以在评审工作中进行考察并确定。
• 可以按层次建立企业评审专家库，即通过以往评审工作的考察建立。
• 可以按层次合理选拔评审人员，即从企业评审专家库中选拔。合理搭配，确实保证多角度和多层次的评审。
• 可以为个人职业发展方向提供参考，个人选择比较适合自己的层次作为努力的方向。

3．评审的层次

• 过程规范：是否符合过程规范、是否按照计划提交、是否按时经过评审、是否准时发布（注意提交时间与发布时间的区别），以及评审的流程是否规范。适合的评审人员：SQA。
• 文档规范：文档成果符合企业或业界已经制定的文档模板规范。企业，甚至行业应当制定统一的文档规范，形成一个文档约定和规则，以统一文档内容与风格。适合的评审人员：SQA。
• 文档语法：文档成果正确使用通用的方法与术语并符合软件工程相关的技术标准，这里所说的语法包括自然语言的语法和建模语言的语法。适合的评审人员要求：精通软件工程、分析与设计方法、建模工具和相关标准。

以上3点站在规范性角度，是进一步评审的基础（基本可读性），可采用非正式评审。

• 文档语义：文档成果表达清晰、无歧义，可以反映系统目标。所有质量合格的文档（包括模型）都代表它期望代表的语义，而且应该在代表这些语义时具有一致性。文字与图表应当互相补充说明，以更加清晰。让别人看得懂，看完后知道下一步该怎么做。适合的评审人员：行业业务专家，有经验的系统分析与设计人员、高级程序员和测试工程师。
• 文档逻辑：主要体现需求与设计正确性、一致性，无遗漏、多余或错误。前后左右考虑周全，不同文档之间、文档与行业标准之间、同一文档各成分之间不互相矛盾，清晰说明相关部分之间的关系，特别是要符合相关行业的业务标准规范。适合的评审人员：行业业务专家、产品经理、有经验的系统分析与设计人员和测试工程师。
  上面几个层次已经保证阶段成果基本满足质量要求，后面所提的两个层次是在此基础上进一步的优化。
• 文档美学：文档成果能否表述得更好一些，文字、图表是否能更加均衡和完整。需要追求平衡的美，每个组成部分应该大小适中，可解读并可变更。平衡有多个方面，如排版次序更加合理、文字、图形更加精炼并更易理解等。适合的评审人员：系统分析与设计专家，以及建模工具专家。
• 结果优化：通过检查判断文档成果（如项目计划、需求规格及设计方案）是否还有改进的空间，以便更加方便地进行项目管理、降低成本、加快进度、提高质量并减少风险，尽可能达到最佳方案。任何一项设计都可以有许多不同的方案，通过“方案优化”选定一种最好的方案。适合的评审人员：系统分析与设计专家、项目经理和产品经理。

4．评审级别判断因素

• 项目团队技能水平：相对于使用的技术，对团队成员来说是比较熟练的还是新技术？软件技术不断发展，使用新技术是常见的事情。
• 项目对公司业务的影响程度：所开发的软件是否有较好的或广阔的市场前景，或者对与客户的关系有较大影响？
• 项目对用户的重要程度：是否为用户方的“一把手”工程？
• 人员投入及进度的紧张程度。
• 项目规模、项目环境和项目的各项要求。
• 项目目的是赢利还是科研试验。
• ROI投资回报率：投资回报率高，自然得到高度重视，各项投入也会增加。评审力度自然也要加强，以确保预期的投资回报率变成真实的投资回报率。
• 项目工业化分类，常规的可分为以下几类。

— 产品研发型和定制工程型：这是可以比较正规地按照软件工程方法组织开发的项目。

— 半产品半定制型：这是比较常见的开发类型。

— 产品升级型和定制升级型：随着公司的发展，用户的业务需求也不断发展，版本也会不断更新。而留住老客户成了主要任务，服务性质的工作会越来越多。

— 装修型、侍从型和打靶型：这几个都是典型的“四边型”项目，即边做、边提需求、边改、边完善。摸着石头过河，逐渐满足客户的需求或逐渐靠近项目的目标。

— 民间工艺型：个人利用“业余”时间开发小软件，可以随意地发挥个人的创造性。

当然，以上的分类不一定完整，各类之间也只是“量变到质变”的关系，还有其他不同的类型，不过都可能变成四边型。最常见的是类型的不断演化，形成混合型。

混合型1：研发→定制→装修→侍从→升级。

混合型2：定制→研发→装修→侍从→升级。

不同的类型对评审的要求显然是不同的。

评审的流程

1．评审流程概览

• 确定评审组长。
• 制定并发布评审计划。
• 准备评审。
• 举行评审会议。
• 改正、跟踪和回归评审。
• 分析、总结和报告。
• 归档。

2．确定评审组长

由品质保证人员与项目经理、部门经理及公司高层讨论协商，确定项目的评审级别及评审人员角色构成要求，初步确定评审组长人选。品质保证人员与评审组长沟通，最终确定评审组长。评审组长充分了解项目相关情况，为制定评审计划做好准备。

3．评审计划

• 评审组长制定评审计划（根据项目计划和质量计划）。
• 评审组长确定评审对象和评审时间。
• 评审组长确定评审级别和策略（形式的组合）。
• 评审组长确定评审流程裁减和提交物。
• 评审组长确定入口条件并通过准则。
• 评审组长确定回归评审准则。
• 评审组长制定评审检查表（CheckList）。
• 评审组长确定评审角色构成。
• 评审组长根据评审角色构成确定评审人员并成立评审小组。
• 相关人员（评审人员和项目团队双方）确认评审计划。
• 评审组长发布评审计划。

4．评审准备

• 正式评审前准备：文档作者向相关人员发布文档。
• 评审人员阅读了解文档，争取发现大部分问题。
• 文档作者解决大部分发现的问题。
• 评审组长确定会议地点、环境、设备和所有材料。
• 评审组长确定人员职责和会议议程。
• 评审组长确定评审开始条件成熟。
• 评审组长通知相关人员到会。

5．评审会议

• 主持人（评审组长）宣布会议议程、人员职责和会场纪律。
• 文档作者介绍工作成果，对评审人员的疑问进行必要的解释。
• 评审人员对不解之处提出疑问，指出问题或缺陷并说明根据。
• 文档作者与评审人员讨论缺陷的真实性，分清缺陷性问题和建议性问题，讨论确定是否需要按照评审人员的要求进行改进。一般不涉及为节省时间改进方案或错误的纠正方案。

6．评审记录

• 正式评审应当记录有共识的问题或缺陷，也要记录有争议待解决的问题。使评审工作文档化，便于跟踪最终解决。
• 总体记录：包括项目名称、系统名称版本号、日期时间、主文档名称、附文档名称、文档版本号、作者、评审类型（首次、回归、部分和阶段）、评审人员和评审结论。
• 缺陷记录：包括缺陷编号、提出者、章节／页码、缺陷描述、缺陷类型（严重、一般和建议）和承诺改正时间。
• 验证记录：全部打勾的CheckList，说明CheckList所列的工作都已经做完，所列的内容都已经评审完，确保工作的完整性。

7．评审结论

评审结论包括如下内容。

• 是否需要修改？这是就成果的整体而言，结论可以是无需、少量、较大或是一个量化的数字。
• 项目组确定是否接受修改要求？这是针对具体的一条意见或建议。有些问题可能是误会，消除了就不是问题；有些建议性的问题，项目组考虑进度可不接受修改要求。

— 如不接受修改要求，项目组给出不修改的理由。

— 如何处理？是否需要进行回归评审？

— 总体结论：合格或不合格。

— 确定的修改责任人和跟踪责任人。

— 确定的回归评审时间。

— 是否都认同评审结论？如果需要做得更正式一些，可以要求相关人员签字表示同意评审结论，签字只有在较为正式的会议评审中要求。如果是邮件或软件工具，则以电子记录为准。

8．跟踪与总结

评审中发现的问题的后续跟踪是改正错误并消除缺陷的有效措施，应当有专门的责任人进行后续跟踪确认错误都已改正，根据结论必要时回归评审。

• 评审组长分析评审数据并总结经验。
• 评审组长发布评审记录与数据分析报告。
• 管理人员应当防止评审数据被不恰当地使用，如果使用评审数据来对个人进行绩效评价，将会给以后的评审工作造成障碍，使评审各方不能放开进行评审。
• 评审组长进行工作总结，工作总结很有必要，有利于对项目或过程的改进。
• 评审组长提交各类评审报告，有关领导批准发布通过的文档。

9．材料归档

评审材料归档是项目配置管理工作的一部分。新建项目，记载配置管理工具中为此项目建立一个目录，并建立下列子目录。

• 待评阅态：文件放入此目录后会自动通过邮件通知需要评阅的人员，全体评阅人员评阅完毕，也会自动通过邮件把意见通知文档作者并实现到期自动提醒功能。
• 待评审态：文件放入此目录后会自动通过邮件通知需要评审的人员，全体评阅人员评审完毕，也会自动通过邮件把批准或拒绝的意见通知文档作者并实现到期自动提醒功能。
• 受控态：评审批准后自动转入受控态并发布自动邮件。
• 签出态：为了修改而版本升级，当文件签出时放入签出态。修改后的文档可能签入到待评阅态、待评审态或直接到受控态，但文档版本已经升级。
• 产品态：项目结束后受控态的文档自动归到产品态。