同行评审过程描述（一）——概述 博客分类： workdocs 设计模式软件测试工作单元测试项目管理
程序员文章站
2024-02-21 20:19:34
...
1. Overview（概述）
In a peer review, co-workers of a person who created a software work product examine that product to identify defects and correct shortcomings. A review:
在同行评审中，由软件工作产品创建者的同行们检查该工作产品，识别产品的缺陷，改进产品的不足。评审：
· verifies whether the work product correctly satisfies the specifications found in any predecessor work product, such as requirements or design documents
· 检验工作产品是否正确的满足了以往的工作产品中建立的规范，如需求或设计文档
· identifies any deviation from standards, including issues that may affect maintainability of the software
· 识别工作产品相对于标准的偏差，包括可能影响软件可维护性的问题
· suggests improvement opportunities to the author
· 向创建者提出改进建议
· promotes the exchange of techniques and education of the participants.
· 促进参与者之间的技术交流和学习
All interim and final development work products are candidates for review, including:
所有中间和最终的开发工作产品都可以进行评审，包括：
· requirements specifications
· 需求规格说明书
· user interface specifications and designs
· 用户界面规范及设计
· architecture, high-level design, and detailed designs and models
· 架构，概要设计，详细设计及模型
· source code
· 源代码
· test plans, designs, cases, and procedures
· 测试计划，设计，用例及步骤
· software development plans, including project management plan, configuration management plan, and quality assurance plan
· 软件开发计划，包括项目管理计划，配置管理计划和质量保证计划
This document defines an overall peer review process. It includes procedures for conducting inspections and two types of informal peer review, a walkthrough and a passaround, as well as guidance for selecting the appropriate approach for each review.
该文档定义了一个全面的同行评审过程。包括了执行评审的步骤和两种非正式的同行评审，走查和轮查，以及对每个评审选择适当方法的指南。
2. Work Aids（工作辅助项）
The following peer review work aids are available from :
<场所>中，需要有如下的同行评审工作辅助项：
· Inspection Summary Report
· 评审总结报告
· Issue Log
· 问题日志
· Typo List
· 微错清单
· Inspection Moderator’s Checklist
· 评审负责人的检查表
· Inspection Lessons Learned Questionnaire
· 评审经验教训问卷
· defect checklists for several types of software work products
· 各种软件工作产品的缺陷检查表
3. Risk Assessment Guidance（风险评估指南）
To judge which software components (or portions of components) to review and what type of review method to use, consider the following risk criteria:
在判断哪些软件组件（或组件的部分）需要评审及使用哪种评审方法的时候，需要考虑如下的风险条件：
· components that use new technology, techniques, or tools
· 使用了新技术，方法，工具的组件
· key architectural components
· 关键的架构性的组件
· complex logic or algorithms that are difficult to understand but must be accurate and optimized
· 难以理解，却又必须准确和优化的复杂逻辑或算法
· mission-, security-, or safety-critical components with dangerous failure modes
· 具有危险失败模式的组件，而且是任务、可靠性、安全性关键的
· components having many exception conditions or failure modes
· 具有多个异常条件或失败模式的组件
· exception handling code that cannot easily be tested
· 不易测试的异常处理代码
· components that are intended to be reused
· 打算复用的组件
· components that will serve as models or templates for other components
· 将作为其他组件的模型或模板的组件
· components that affect multiple portions of the product
· 影响产品多个部分的组件
· complex user interfaces
· 复杂的用户界面
· components created by less experienced developers
· 由缺乏经验的开发者创建的组件
· code modules having high cyclomatic complexity
· 具有高度圈复杂性的代码模块
· modules having a history of many defects or changes
· 以往具有很多缺陷或变更的模块
Work products that fit in one or more of these categories are considered high risk. A product is considered low risk if an undetected error will not significant affect the project’s ability to meet its schedule, quality, cost, and feature objectives. Use inspections for high-risk work products, or the high-risk portions of large products, and for major work products that are about to be baselined. Less formal reviews are acceptable for other work products
符合这些条件中一种或几种的工作产品被认为是高风险的。如果未发现的缺陷对项目达成进度，质量，成本及特征目标的能力没有重大影响，则该工作产品被认为是低风险的。评审只用于高风险的工作产品或大产品的高风险部分或将要被基线化的主要工作产品。对其他的工作产品可以进行不太正式的评审。
4. Participants（参与者）
Table 1 suggests project roles who might review different work products. Not all of these perspectives need to be represented. In general, a work product should be reviewed by:
表1列出了评审不同工作产品的项目角色。不是所有这些角度都必须表现出来。通常，一项工作产品的评审需要有：
· the author of any predecessor document or specification
· 以往的文档或规范的创建者
· someone who must base their subsequent work on the work product
· 以该工作产品为基础进行后续工作的人。
· peers of the author
· 创建者的同行们
· anyone responsible for a component to which the work product interfaces
· 使用该工作产品接口的组件的负责人
Attendance by anyone with supervisory authority over the author is by invitation of the author only.
对工作产品创建者具有监督权力的人只能在创建者的邀请下参加评审。
Table 1. Review Participants for Different Types of Work Products.
表1. 各类工作产品的参评人
In a peer review, co-workers of a person who created a software work product examine that product to identify defects and correct shortcomings. A review:
在同行评审中，由软件工作产品创建者的同行们检查该工作产品，识别产品的缺陷，改进产品的不足。评审：
· verifies whether the work product correctly satisfies the specifications found in any predecessor work product, such as requirements or design documents
· 检验工作产品是否正确的满足了以往的工作产品中建立的规范，如需求或设计文档
· identifies any deviation from standards, including issues that may affect maintainability of the software
· 识别工作产品相对于标准的偏差，包括可能影响软件可维护性的问题
· suggests improvement opportunities to the author
· 向创建者提出改进建议
· promotes the exchange of techniques and education of the participants.
· 促进参与者之间的技术交流和学习
All interim and final development work products are candidates for review, including:
所有中间和最终的开发工作产品都可以进行评审，包括：
· requirements specifications
· 需求规格说明书
· user interface specifications and designs
· 用户界面规范及设计
· architecture, high-level design, and detailed designs and models
· 架构，概要设计，详细设计及模型
· source code
· 源代码
· test plans, designs, cases, and procedures
· 测试计划，设计，用例及步骤
· software development plans, including project management plan, configuration management plan, and quality assurance plan
· 软件开发计划，包括项目管理计划，配置管理计划和质量保证计划
This document defines an overall peer review process. It includes procedures for conducting inspections and two types of informal peer review, a walkthrough and a passaround, as well as guidance for selecting the appropriate approach for each review.
该文档定义了一个全面的同行评审过程。包括了执行评审的步骤和两种非正式的同行评审，走查和轮查，以及对每个评审选择适当方法的指南。
2. Work Aids（工作辅助项）
The following peer review work aids are available from :
<场所>中，需要有如下的同行评审工作辅助项：
· Inspection Summary Report
· 评审总结报告
· Issue Log
· 问题日志
· Typo List
· 微错清单
· Inspection Moderator’s Checklist
· 评审负责人的检查表
· Inspection Lessons Learned Questionnaire
· 评审经验教训问卷
· defect checklists for several types of software work products
· 各种软件工作产品的缺陷检查表
3. Risk Assessment Guidance（风险评估指南）
To judge which software components (or portions of components) to review and what type of review method to use, consider the following risk criteria:
在判断哪些软件组件（或组件的部分）需要评审及使用哪种评审方法的时候，需要考虑如下的风险条件：
· components that use new technology, techniques, or tools
· 使用了新技术，方法，工具的组件
· key architectural components
· 关键的架构性的组件
· complex logic or algorithms that are difficult to understand but must be accurate and optimized
· 难以理解，却又必须准确和优化的复杂逻辑或算法
· mission-, security-, or safety-critical components with dangerous failure modes
· 具有危险失败模式的组件，而且是任务、可靠性、安全性关键的
· components having many exception conditions or failure modes
· 具有多个异常条件或失败模式的组件
· exception handling code that cannot easily be tested
· 不易测试的异常处理代码
· components that are intended to be reused
· 打算复用的组件
· components that will serve as models or templates for other components
· 将作为其他组件的模型或模板的组件
· components that affect multiple portions of the product
· 影响产品多个部分的组件
· complex user interfaces
· 复杂的用户界面
· components created by less experienced developers
· 由缺乏经验的开发者创建的组件
· code modules having high cyclomatic complexity
· 具有高度圈复杂性的代码模块
· modules having a history of many defects or changes
· 以往具有很多缺陷或变更的模块
Work products that fit in one or more of these categories are considered high risk. A product is considered low risk if an undetected error will not significant affect the project’s ability to meet its schedule, quality, cost, and feature objectives. Use inspections for high-risk work products, or the high-risk portions of large products, and for major work products that are about to be baselined. Less formal reviews are acceptable for other work products
符合这些条件中一种或几种的工作产品被认为是高风险的。如果未发现的缺陷对项目达成进度，质量，成本及特征目标的能力没有重大影响，则该工作产品被认为是低风险的。评审只用于高风险的工作产品或大产品的高风险部分或将要被基线化的主要工作产品。对其他的工作产品可以进行不太正式的评审。
4. Participants（参与者）
Table 1 suggests project roles who might review different work products. Not all of these perspectives need to be represented. In general, a work product should be reviewed by:
表1列出了评审不同工作产品的项目角色。不是所有这些角度都必须表现出来。通常，一项工作产品的评审需要有：
· the author of any predecessor document or specification
· 以往的文档或规范的创建者
· someone who must base their subsequent work on the work product
· 以该工作产品为基础进行后续工作的人。
· peers of the author
· 创建者的同行们
· anyone responsible for a component to which the work product interfaces
· 使用该工作产品接口的组件的负责人
Attendance by anyone with supervisory authority over the author is by invitation of the author only.
对工作产品创建者具有监督权力的人只能在创建者的邀请下参加评审。
Table 1. Review Participants for Different Types of Work Products.
表1. 各类工作产品的参评人
| Work Product Type工作产品类型 | Work Product Type工作产品类型 |
| Architecture or High-Level Design架构或概要设计 | architect, requirements analyst, designer, project manager, integration test engineer架构师，需求分析师，设计师，项目经理，集成测试工程师 |
| Detail Design详细设计 | designer, architect, programmer, integration test engineer设计师，架构师，程序员，集成测试工程师 |
| Process Documentation过程文档 | process improvement group leader, process improvement working group members, management-level process owner, practitioner representatives who will use the process过程改进组负责人，过程改进工作组成员，管理级的过程拥有者，使用过程的实践者的代表 |
| Project Plans项目计划 | project manager, program manager, business sponsor, marketing or sales representative, technical lead, quality assurance manager项目经理，产品经理，需求提出者，市场或销售代表，技术负责人，质量保证工程师 |
| Requirements Specification需求规格说明书 | requirements analyst, project manager, architect, designer, system test engineer, quality assurance manager, user or marketing representative, documentation writer, subject matter expert, technical support representative需求分析师，项目经理，架构师，设计师，系统测试工程师，质量保证经理，用户或市场代表，文档编写者，业务专家，技术支持代表 |
| Source Code源代码 | programmer, designer, unit test engineer, maintainer, requirements analyst, coding standards expert程序员，设计师，单元测试工程师，维护者，需求分析师，编码标准专家 |
| System Technical Documentation系统技术文档 | author, project manager, maintainer, programmer创建者，项目经理，维护者，程序员 |
| Test Documentation测试文档 | test engineer, programmer (unit testing) or architect (integration testing) or requirements analyst (system testing), quality assurance representative测试工程师，程序员（单元测试）或架构师（集成测试）或需求分析师（系统测试），质量保证代表 |
| User Interface Design用户界面设计 | user interface designer, requirements analyst, user, application domain expert, usability or human factors expert, system test engineer用户界面设计师，需求分析师，用户，应用领域专家，可用性或人体专家，系统测试工程师 |
| User Manual用户手册 | ocumentation writer, requirements analyst, user or marketing representative, system test engineer, maintainer, designer, instructional designer, trainer, technical support representative文档编写者，需求分析师，用户或市场代表，系统测试工程师，维护人员，设计师，用户教育设计师，培训师，技术支持代表 |
上一篇： 多线程计数,怎么保持计数准确的方法