GB/T 32421-2015 软件工程 软件评审与审核

　　ICS 35. 080 L 77

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 32421—2015

　　软件工程 软件评审与审核

　　Softwareengineering—Softwarereviewsand audits

　　2015-12-31发布 2016-08-01实施

　　中华人民共和国国家质量监督检验检疫总局中 国 国 家 标 准 化 管 理 委 员 会

　　发

　　布

　　GB/T 32421—2015

　　前 言

　　本标准按照 GB/T 1. 1—2009给出的规则起草 。

　　请注意本文件的某些内容可能涉及专利 。本文件的发布机构不承担识别这些专利的责任 。

　　本标准由全国信息技术标准化技术委员会(SAC/TC28)提出并归 口 。

　　本标准起草单位 :广州广软信息技术服务有限公司 、中国电子技术标准化研究院 、国家网络软件产品质量监督检验中心(济南) 、中国航天科技集团公司软件评测中心 、上海计算机软件技术开发中心 。

　　本标准主要起草人 :袁肃蓉 、刘新 、黄姗姗 、田辉 、杨桂枝 、蔡立志 、刘振宇 、龚家瑜 。

　　引 言

　　本标准为软件开发的管理和技术人员提供软件管理和工程的标准规范和方法 ,是实现软件质量保证的重要措施 。软件的评审和审核应利用科学的方法 , 以严谨的态度及严格的规定有序地进行 ,软件开发的管理和技术人员各履其职 ,制定完备的计划及措施确保评审和审核的过程顺利完成 。

　　本标准是为软件评估和相应的规定 、标准 、指南 、计划 、规格说明和规程的符合性评价而提出 ,是对软件和开发过程所做的一种独立检查 。本标准包括管理评审 、技术评审 、审查 、走查 、审核等部分 ,规定了软件评审和审核的对象 、角色 、职责 、输入 、入口准则 、规程 、出 口准则和输出等方面的要求 。软件管理者应按照适用的标准和规程 ,并结合法律 、合同或其他法规的要求进行评审 。

　　本标准中的角色对象以及评审审核过程形成一个较完整的集合 ,贯穿软件开发及服务的整个生存周期过程 ,软件开发的管理和技术人员并可通过此标准控制和改进过程 。

　　本标准适用于在整个软件生存周期内进行的软件评审和审核 ,软件开发的管理和技术人员可将本标准与 GB/T 8566《信息技术 软件生存周期过程》对照使用 ,可相应选择适合软件开发和后续服务的子过程或全过程 。

　　软件工程 软件评审与审核

　　1 范围

　　本标准规定了软件评审与审核的对象 、角色 、职责 、输入 、入口准则 、规程 、出 口准则和输出等方面的要求 。软件评审与审核包括管理评审 、技术评审 、审查 、走查和审核等五种类型 。

　　本标准适用于软件产品的生存周期全部过程 。

　　2 规范性引用文件

　　下列文件对于本文件的应用是必不可少的 。凡是注 日期的引用文件 ,仅注 日期的版本适用于本文件 。凡是不注日期的引用文件 ,其最新版本(包括所有的修改单)适用于本文件 。

　　GB/T 11457 信息技术 软件工程术语

　　GB/T 19001 质量管理体系 要求

　　3 术语和定义

　　GB/T 11457中界定的以及下列术语和定义适用于本文件 。

　　3. 1

　　异常 anomaly

　　与根据需求规格说明 、设计文档 、用户文档 、标准等建立的期望相偏离的情况 ,或者与人的感知或经验相偏离的情况 。

　　注 : 异常可以在下述(但不 限 于) 期 间 发 现 : 软 件 产 品 或 适 用 文 档 的 评 审 、测 试 、分 析 、编 译 或 使 用 。 包 括 故 障 、缺陷等 。

　　3.2

　　评审 review

　　向项目成员 、管理人员 、用户 、顾客 、用户代表 、审核员或其他相关方阐述软件产品 、软件产品集合或软件过程的过程或会议 , 以便进行检查 、评论或批准 。

　　3.3

　　管理评审 managementreview

　　由管理部门或者代表管理部门对软件产品或过程的进行的一种系统性评价 , 以便监督进展 ,确定计划和进度的状态 ,确认需求和需求的系统分配 ,或者评价管理方法的有效性以达到最佳的 目的 。

　　3.4

　　技术评审 technicalreview

　　由一组具备资格的人员对软件产品进行的一种系统性评价 , 以检查软件产品对其预期用途的适合性 ,并标识与规格说明和标准的差异 。技术评审可提出推荐的备选方法并检查各种不同的备选方法 。

　　3.5

　　审查 inspection

　　对软件产品的一种可视检查 , 以检测和标识软件异常 ,其中包括错误 、对标准和规格说明的偏离 。审查是由受过审查技术培训的 、公正的组织者领导的同行检查 。

　　注 : 审查结果可不包括解决方案 ,但宜确定异常的补救措施或调查措施 。

　　3.6

　　走查 walk-through

　　一种静态分析技术 ,设计者或程序员引导开发组成员和其他有关方通读软件产品,参与者提出问题并对可能的异常 、违反开发标准之处和其他问题进行评论 。

　　3.7

　　审核 audit

　　为评估与规格说明 、标准 、合同协议或其他准则的符合性而由第三方实施的对软件产品 、软件过程或软件过程集合所作的一种独立检查 。

　　注 : 审核宜对是否已达到审核准则给出一个明确的指示 。

　　4 管理评审

　　4. 1 一般要求

　　管理评审由直接负责系统的管理人员或其代表执行 , 以识别里程碑工作成果与计划的一致性和偏离 ,或者识别遵循管理规程的充分性 。

　　管理评审应由具有资格评价软件产品或过程的人员来实施 。

　　4.2 对象

　　管理评审的对象如下 :

　　基于文档的对象包括(但不仅限于)如下 :

　　● 异常报告 ;

　　● 审核报告 ;

　　● 备份和恢复计划 ;

　　● 应急方案 ;

　　● 需求规格说明 ;

　　● 顾客或用户代表的投诉 ;

　　● 容灾方案 ;

　　● 硬件性能方案 ;

　　● 安装计划 ;

　　● 维护计划 ;

　　● 采购和签约方法 ;

　　● 进度报告 ;

　　● 风险管理计划 ;

　　● 软件配置管理计划 ;

　　● 软件项目管理计划 ;

　　● 软件质量保证计划 ;

　　● 软件安全性设计 ;

　　● 软件验证和确认计划 ;

　　● 技术评审报告 ;

　　● 软件产品分析 ;

　　● 验证和确认报告 ;

　　● 迁移策略和计划 ;

　　● 测试结果 ;

　　● 软件开发过程描述 ;

　　● 软件架构描述 。

　　基于过程的对象包括(但不仅限于)如下 :

　　● 获取过程 ;

　　● 供应过程 ;

　　● 开发 、运作和维护过程 ;

　　● 文档编制过程 ;

　　● 配置管理过程 ;

　　● 质量保证过程 ;

　　● 验证 、确认和联合评审过程 ;

　　● 审核过程 ;

　　● 问题解决过程 ;

　　● 管理 、改进和基础过程 ;

　　● 培训过程 。

　　4.3 角色和职责

　　4.3. 1 角色

　　应为管理评审确定下述角色 :

　　● 决策者 ;

　　● 评审组长 ;

　　● 记录员 ;

　　● 管理人员 ;

　　● 技术人员 。

　　也可确定下述角色 :

　　● 其他组员 ;

　　● 顾客代表 ;

　　● 用户代表 。

　　参评者可担任一个以上(但不是全部)的角色 ,一个角色可由多人担任 。

　　4.3.2 职责

　　4.3.2. 1 决策者

　　管理评审是为决策者而实施的 。决策者应确定评审的目标是否已达到 。

　　4.3.2.2 评审组长

　　评审组长应负责确保与评审有关的管理任务得以完成 ,应负责在 4. 6. 2 和 4. 6. 4 中描述的策划和准备工作 ,应确保评审工作以有序的方式进行并满足评审的目标 ,并按 4. 8 中的描述发布评审输出 。

　　4.3.2.3 记录员

　　记录员应将评审组提出的异常 、措施项 、决策和建议形成文档 。

　　4.3.2.4 管理人员

　　指定实施管理评 审 的 管 理 人 员 应 积 极 参 与 管 理 评 审 。 对 系 统 整 体 负 责 的 管 理 人 员 还 应 承 担 在

　　4. 6. 1 中规定的其他职责 。

　　4.3.2.5 技术人员

　　技术人员应向管理人员提供必要的信息 , 以便管理人员履行其职责 。

　　4.3.2.6 顾客或用户代表

　　在评审之前 ,顾客或用户代表的职责由评审组长确定 。

　　4.4 输入

　　管理评审的输入应包括 :

　　● 管理评审的目标说明 ;

　　● 待评价的软件产品或过程 ;

　　● 软件项目管理计划 ;

　　● 相对于计划 , 已完成或过程中的软件产品或过程的状态 ;

　　● 当前的异常或问题清单 ;

　　● 文档化的评审规程 ;

　　● 过去评审类似产品或过程的措施项清单(如果存在的话) 。

　　也可包括 :

　　● 资源的状况(适当时 ,包括资金的状况) ;

　　● 异常分类(参见附录 A) ;

　　● 风险评估报告 。

　　在评审组长要求的情况下 ,负责软件产品或过程的人员应提供其他的参考材料 。

　　4.5 入口准则

　　4.5. 1 授权

　　应在适当的项目策划文档中首先确立实施管理评审的需要 ,如 4. 1 和 4. 2 所列 。在这些计划中 ,在某个具体的软件产品或者活动完成时 ,可根据需要进行一次管理评审 。 除了某个具体计划要求的管理评审之外 ,软件质量管理部门 、职能管理部门 、项 目管理部门 、顾客或者用户代表根据本地化规程的要求 ,也可以提出并实施一些其他的管理评审 。

　　4.5.2 前提

　　仅当下述两个条件同时满足时才可实施管理评审 :

　　● 决策者已经确立了评审目标的说明 ;

　　● 必要的评审输入可用 。

　　必要的评审输入在要求的时间内可用 , 以便使所有参与者能充分了解 。

　　4.6 规程

　　4.6. 1 管理准备

　　管理者应确保按照适用的标准和规程并按照法律 、合同或其他法规的要求进行评审 。 为此 , 管理者应 :

　　● 按照 GB/T 19001或其他相关标准的要求 ,策划实施评审所需要的时间和资源 ,包括支撑职能 ;

　　● 提供策划 、定义 、执行和管理该评审所需要的资金和设施 ;

　　● 提供适用于给定项目的有关评审规程的培训和定向培训 ;

　　● 确保评审组成员具有理解待评审软件产品或过程的 、适当的专业和知识水平 ;

　　● 确保已策划的评审得到实施 ;

　　● 及时对评审组的建议采取措施 。

　　4.6.2 策划评审

　　评审组长应负责下述活动 :

　　● 确定评审组成员的角色 ;

　　● 为评审组成员分配具体的职责 ;

　　● 安排并通知会议的 日程 ;

　　● 向参评者分发评审材料 ,并为他们留出足够的准备时间 ;

　　● 建立一个发布评审材料 、返回意见并将意见提交给作者处理的时间表 。

　　4.6.3 评审规程概述

　　在评审组长要求的情况下 ,应由一名具备资格的人员为评审组进行概要介绍 。 可以在评审会上作概要介绍(见 4. 6. 5) ,也可以单独开会作概要介绍 。

　　4.6.4 准备

　　在评审会议之前 ,评审组成员均应检查软件产品或过程和其他评审输入 。在检查期间发现的异常应形成文档并提交给评审组长 。评审组长应分类这些异常 , 以确保评审会的时间得到最有效的使用 。评审组长应将异常提交给软件产品的作者或所有者进行处理 。

　　4.6.5 检查

　　管理评审应包括一次或多次评审组会议 。会议应完成下述目标 :

　　● 评审管理评审的目标 ;

　　● 对照目标 ,评价待评审的软件产品或过程 ;

　　● 评价项目状态 ,其中包括计划和进度的状态 ;

　　● 评审由评审组在评审前标识出的异常 ;

　　● 产生措施项清单 , 以及隐含的风险和应对措施 ;

　　● 将会议内容形成文档 。

　　也可完成下述目标 :

　　● 评价和管理那些可能妨碍项目取得成功的风险问题 ;

　　● 资源分配调整和项目重定向及重新计划 ;

　　● 确认软件需求和需求的系统分配 ;

　　● 确定要采取的行动方针或者措施建议 ;

　　● 识别应处理的其他问题 。

　　4.6.6 返工或后续工作

　　评审组长或其代表应验证在评审会中指定的措施项已关闭 。

　　4.7 出 口准则

　　当 4. 6. 5 中列出的活动已经完成且在 4. 8 中描述的输出已经存在时 ,管理评审才应视为已完成 。

　　4. 8 输出

　　管理评审的输出应为文档化的记录 ,包括下述内容 :

　　● 已评审的软件产品与过程 ;

　　● 评审组成员 ;

　　● 评审目标 ;

　　● 评审的具体输入 ;

　　● 措施项的状态(待处理或已关闭) 、责任人和预定日期(若为待处理)或者完成日期(若为已关闭) ;

　　● 评审组标识的异常清单 ,这些异常应进行处理以满足项 目 目标 。

　　本标准只对文档化证据的内容提出最低要求 ,有关附加内容 、格式和存储介质等方面的要求宜在分项规程中描述 。在分项规程中确认的评审的输出应提交给决策者 、其他管理者以及项目涉及人员 。

　　5 技术评审

　　5. 1 一般要求

　　技术评审可提供对不同备选方案的建议和检查 ,技术评审可根据需要召开一次或多次会议 。检查不必包含产品的所有方面 。

　　技术评审组宜由三名以上成员组成 。

　　5.2 对象

　　技术评审的对象包括(但不仅限于)如下 :

　　● 软件需求规格说明 ;

　　● 软件设计说明 ;

　　● 软件测试文档 ;

　　● 软件用户文档 ;

　　● 维护手册 ;

　　● 系统开发规程 ;

　　● 安装规程 ;

　　● 发布说明 ;

　　● 软件开发过程描述 ;

　　● 软件架构说明 。

　　5.3 角色和职责

　　5.3. 1 角色

　　应为技术评审确定下述角色 :

　　● 决策者 ;

　　● 评审组长 ;

　　● 记录员 ;

　　● 技术人员 。

　　也可确定下述角色 :

　　● 管理人员 ;

　　● 其他组员 ;

　　● 其他利益相关方如管理者 、技术人员 、顾客和用户 。

　　参评者可以担任一个以上(但不能是全部)的角色 。

　　5.3.2 职责

　　5.3.2. 1 决策者

　　技术评审是为决策者而实施的 。决策者应确定是否达到了评审的目标 。

　　5.3.2.2 评审组长

　　评审组长应负责评审 。其职责包括执行与评审有关的管理任务 、确保评审以一种有序的方式进行 、并确保评审满足其目的 。评审组长应按 5. 8 中的描述发布评审输出 。

　　5.3.2.3 记录员

　　记录员应将评审组提出的异常 、措施项 、决策和建议形成文档 。

　　5.3.2.4 技术人员

　　技术人员应积极参与评审并且评价软件产品 。

　　5.3.2.5 管理人员

　　管理人员可以参与技术评审 , 以便标识出需要管理部门解决的问题 。

　　5.3.2.6 顾客或用户代表

　　在评审之前 ,顾客或用户代表的职责由评审组长确定 。评审组长应根据具体的评审确定是否需要顾客或用户代表的角色 ,并在评审期间定义其职责 。

　　5.4 输入

　　技术评审的输入应包括如下 :

　　● 技术评审的目标说明 ;

　　● 待检查的软件产品 ;

　　● 当前的软件产品异常或问题清单 ;

　　● 文档化的评审规程 。

　　也可包括如下 :

　　● 相关的评审报告 ;

　　● 用于检查软件产品的规定 、标准 、指南 、计划 、规格说明和规程 ;

　　● 评审支持材料如表单 、清单 、规定和异常分类(参见附录 A) ;

　　在评审组长要求的情况下 ,负责软件产品的人员应提供其他的参考材料 。

　　5.5 入口准则

　　5.5. 1 授权

　　应在项目策划文档中确定实施技术评审的需要 ,例如项目策划 、质量保证计划 、安全计划等 。 除了某个具体计划要求的技术评审之外 ,职能管理部门 、项目管理部门 、软件质量管理部门 、系统工程组或软件工程组根据本地化规程的要求 ,也可以授权提出并实施一些其他的技术评审 。 可要求技术评审评价硬件或第三方产品的异常或者缺陷对软件产品的影响 。

　　5.5.2 前提

　　仅当评审的目的说明已建立和职责人员已充分培训这两者同时满足时才可实施技术评审 。

　　5.6 规程

　　5.6. 1 管理准备

　　管理者应确保按照适用的标准和规程并按照法律 、合同或其他法规的要求进行评审 。 为此 , 管理者应 :

　　● 按照 GB/T 19001或其他相关标准的要求 ,策划实施评审所需要的时间和资源 ,包括支持职能 ;

　　● 提供策划 、定义 、执行和管理该评审所需要的资金和设施 ;

　　● 提供适用于给定项目的有关评审规程的培训和定向培训 ;

　　● 确保评审组成员有足够理解待评审软件产品的适当的技术 、专业和知识水平 ;

　　● 确保已策划的评审得到实施 ;

　　● 及时对评审组的建议采取措施 。

　　注 : 评审组长负责挑选评审员 ,管理者负责管理评审员 。

　　5.6.2 策划评审

　　评审组长应负责下述活动 :

　　● 通过适当的管理支持来标识评审组成员的角色 ;

　　● 为评审组成员分配具体的职责 ;

　　● 安排并通知会议的 日程 ;

　　● 向参与者分发评审材料 ,并为他们留出足够的准备时间 ;

　　● 建立一个发布评审材料 、返回评论并将评论提交给作者处理的时间表 。

　　作为策划规程的一个部分 ,评审组应确定是否在评审会上讨论备选方案 。备选方案既可以在评审会上讨论 ,也可以在此后的某次单独的会议上讨论 ,还可以留待软件产品的作者解决 。

　　5.6.3 评审规程概述

　　在评审组长要求的情况下 ,应由一名具备资格的人员为评审组进行概要介绍 。 可以在评审会上作概要介绍(见 5. 6. 6) ,也可以单独开会作概要介绍 。

　　5.6.4 软件产品概述

　　在评审组长要求的情况下 ,应由一名具备技术资格的人员为评审组作软件产品概述 。 可以在评审会上作软件产品概述(见 5. 6. 6) ,也可以单独开会做概述 。

　　5.6.5 准备

　　在评审会议之前 ,每一个评审组成员都应检查软件产品和其他评审输入 。在检查期间发现的异常应形成文档并提交给评审组长 。评审组长应对这些异常进行分类 , 以确保评审会的时间得到最有效的使用 。评审组长应将异常提交给软件产品的作者进行处理 。

　　评审组长应验证评审组成员已为技术评审做好了准备 。如果评审组成员的准备不充分 ,评审组长应采用更换人员 、重新分配任务或重新安排会议的 日程等纠正措施 。

　　5.6.6 检查

　　在技术评审期间 ,评审组应召开一次或多次会议 。会议应达到下述目标 :

　　a) 决定评价软件产品和异常的 日程 ;

　　b) 确定 :

　　● 软件产品是否完备 ;

　　● 软件产品是否符合适用于项目的规定 、标准 、指南 、计划 、规格说明和规程 ;

　　● 软件产品的更改是否得到了适当的实施且只影响指定的区域 ;

　　● 软件产品是否适合于预期的用法 ;

　　● 软件产品是否就绪 , 以便进行下一项活动 ;

　　● 检查中发现的软件项目安排中的必要的调整 ;

　　● 是否在硬件 、外部或附属软件等其他系统元件中存在异常是否存在硬件异常或者规格说明差异 。

　　c) 标识异常并确认其危险性 ;注 : 措施项由后续的管理分配 。

　　d) 产生措施项清单 ,强调风险 ;

　　e) 将会议内容形成文档 。

　　在软件产品评审之后 ,应形成文档 , 以便记录会议内容 ,列出在软件产品中发现的异常 ,描述为管理部门提出的建议 。

　　在异常足够关键或者足够多时 ,评审组长应建议对修改后的软件产品进行一次附加评审 。 附加评审至少应涵盖为解决异常而更改了的区域以及这些更改的副作用 。

　　5.6.7 返工或后续工作

　　评审组长或其代表应验证在评审会中指定的措施项已关闭 。

　　5.7 出 口准则

　　当 5. 6. 6 中列出的活动已经完成且在 5. 8 中描述的输出已经存在时 ,技术评审才应视为已完成 。

　　5. 8 输出

　　技术评审的输出应为文档化的记录 ,包括下述内容 :

　　● 已评审的项 目 ;

　　● 评审组成员 ;

　　● 已评审的软件产品 ;

　　● 评审的具体输入 ;

　　● 评审目标以及是否达到了评审目标 ;

　　● 软件产品异常清单 ;

　　● 未解决的系统或硬件异常清单或措施说明 ;

　　● 管理问题清单 ;

　　● 措施项的状态(待处理或已关闭) 、责任人和预定日期(若为待处理)或者完成日期(若为已关闭) ;

　　● 评审组针对如何处理未解决的问题和异常提出的建议 ;

　　● 软件产品是否无偏离地满足适用的规定 、标准 、指南 、计划和规程 。

　　本标准只对文档化证据的内容提出最低要求 ,有关附加内容 、格式和存储介质等方面的要求宜在分项规程中描述 。

　　6 审查

　　6. 1 一般要求

　　审查组宜由 3 名 ~ 6名成员组成(包括作者) 。

　　所有参评人员都是审查员 。作者既不能作为审查组长 ,也不能作为领读者或记录员 。其他角色均可由审查组成员担当 ,个别成员可以担当一个以上的角色 。

　　审查组组长由经过审查技术培训且公正的专业人士担任 。 任何审查组成员的管理者均不应参加审查 。

　　尽管在审查会上不做出解决方案 ,但应确定异常的补救措施或调查措施 。

　　在软件审查过程中 ,宜进行数据收集 , 以便分析和改进软件工程规程(包括所有评审规程) 。

　　6.2 对象

　　审查的对象包括(但不仅限于)如下 :

　　● 软件需求规格说明 ;

　　● 软件设计说明 ;

　　● 源代码 ;

　　● 软件测试文档 ;

　　● 软件用户文档 ;

　　● 维护手册 ;

　　● 系统开发规程 ;

　　● 安装规程 ;

　　● 发行说明 ;

　　● 软件原型 ;

　　● 软件开发过程描述 ;

　　● 政策 、战略 、计划 ;

　　● 市场和政策文档 ;

　　● 软件架构描述 。

　　6.3 角色和职责

　　6.3. 1 角色

　　应为审查确定下述角色 :

　　● 审查组长 ;

　　● 记录员 ;

　　● 领读者 ;

　　● 作者 ;

　　● 审查员 。

　　所有参评人员都是审查员 。作者既不能作为审查组长 ,也不能作为领读者或记录员 。其他角色均可由审查组成员担当 ,个别成员可以担当一个以上的角色 。任何审查组成员的管理者均不应参加审查 。

　　6.3.2 职责

　　6.3.2. 1 审查组长

　　审查组长应负责与审查有关的策划和组织的管理任务 ,应在审查会议上与作者一起确认待审核的软件产品的零部件和源文件及 6. 6. 2 和 6. 6. 4 中描述的策划和准备工作 ,应确保审查工作以一种有序的方式进行并满足它的目的 ,应确保收集审查数据(如果适用的话) ,并按 6. 8 中的描述发布审查输出 。

　　6.3.2.2 记录员

　　记录员应将审查组提出的异常 、措施项 、决策 、弃权声明和建议形成文档 。记录员应记录进行过程

　　分析所需要的审查数据 。评审组长可作为记录员 。

　　6.3.2.3 领读者

　　领读者应以一种全面和逻辑的方式引导审查组遍历软件产品,解释工作的各个部分(例如 ,通常以1~ 3行为一个解释组)并强调重要的方面 。

　　软件产品应被划分为逻辑部分并分配给不同的领读者以便减少所需的准备时间 。

　　6.3.2.4 作者

　　作者应负责软件产品满足审查的入口准则 ;使审查能够在充分理解软件产品的基础上进行 ;并负责执行所需要的返工 , 以使软件产品符合审查的出口准则 。

　　6.3.2.5 审查员

　　审查员应标识和描述软件产品中的异常 。审查员的选择应基于他们的专业和在会议中应代表的不同视角(例如 ,主办者 、需求 、设计 、代码 、安全性 、测试 、独立测试 、项 目管理 、质量管理和硬件工程) 。 审查员应只提出与产品审查相关的观点 。

　　应指定部分审查员负责特定的审查专题以确保有效的覆盖 。例如 ,一个审查员可以关注与某个或某些特定标准的符合性 ,另一些审查员可以关注语法的符合性或数据的准确性 ,其他审查员可以负责整体的相关性 。如 6. 6. 2所阐述的那样 , 当策划审查时 ,这些角度应由审查组长分配 。

　　6.4 输入

　　审查的输入应包括如下 :

　　● 审查目标的陈述 ;

　　● 待审查的软件产品 ;

　　● 文档化的审查规程 ;

　　● 审查报告的表格 ;

　　● 当前的异常或问题清单 。

　　也可包括 :

　　● 源文件 ,例如需求和软件产品输入等已被开发者采用的软件产品的开发输入 ;

　　● 审查检查单 ;

　　● 质量准则所要求的再检查 ;

　　● 已检查 、批准或已建立为一个基线的上一版本软件产品 ;

　　● 审查软件产品所依据的规定 、标准 、指南 、计划 、规格说明和规程 ;

　　● 硬件 、仪器或其他软件产品的规格说明 ;

　　● 性能数据 ;

　　● 异常分类(参见附录 A) 。

　　在审查组长要求的情况下 ,负责软件产品的人员应提供其他的参考材料 。

　　6.5 入口准则

　　6.5. 1 授权

　　审查应在相应的项目策划文档(例如 ,整个项目的计划 ,或软件质量保证计划或者软件验证和确认计划)中进行策划和形成文档 。

　　在软件产品的生存周期过程中 ,可以根据项目管理 、质量管理或作者的要求 ,按照本地化的规程实

　　施额外的审查 。

　　6.5.2 前提

　　仅当相关的审查输入可用时才可实施审查 。

　　6.5.3 最小入口准则

　　除非存在一个被管理者所接受的 、书面的证明 ,否则 ,须满足以下所有条件才应实施审查 :

　　● 待审查的软件产品是完整的 ,并在格式上符合项目的标准 ;

　　● 审查前所需要的自动化错误检测工具(例如 ,拼写检查器和编译器)是可用的 ;

　　● 已满足在相应策划文档中标识的 、先前的里程碑要求 ;

　　● 必要的支持文档是可用的 ;

　　● 对于复查 ,在异常清单中记录的 、对待审查软件产品有影响的所有项均已解决 。

　　6.6 规程

　　6.6. 1 管理准备

　　管理者应确保按照适用的标准和规程并按照法律 、合同或其他政策规定的要求进行审查 。为此 ,管理者应 :

　　● 按照 GB/T 19001或其他相关标准的要求 ,策划实施审查所需要的时间和资源 ,包括支持职能 ;

　　● 提供策划 、定义 、执行和管理审查所需要的资金 、设施和工具 ;

　　● 提供适用于给定项目的有关审查规程的培训和定向培训 , 确保评审审查组成员具有理解待审查软件产品的 、适当的专业和知识水平 ;

　　● 确保审查是有计划的 ,确保计划的审查得到实施 ;

　　● 及时对审查组的建议采取措施 。

　　6.6.2 策划审查

　　作者应为审查组长汇总审查材料 ,包括待审查软件产品,用于软件产品开发的标准及文档 。审查组长应负责下述活动 :

　　● 通过适当的管理支持来确定审查组成员的角色 ;

　　注 : 确保审查组成员具有充分理解待审查软件产品及作者用于开发软件产品的文档的知识及专业水平 。

　　● 为审查组成员分配具体的职责 ;

　　● 安排会议的 日程 、选择会议场所及通知审查组成员 ;

　　● 给所有参与者分发审查材料 ,并为他们留出足够的准备时间 ;

　　● 建立一个发布审查材料 、返回评论并将评论提交给作者处理的时间表 。

　　● 确定审查范围包括优先审查的文件 ;

　　● 设定准备及会议期间预期的审查速率 。

　　注 : 多数情况下 ,预估的审查速率是审查策划中的重要因素 。表 1 提 供 了 以 页 或 行 代 码 每 小 时 为 单 位 的 典 型的审查速率和异常记录速率参考 。

　　表 1 审查文档类型和审查速率

　　表 1 (续)

　　6.6.3 审查规程概述

　　审查组长应分派各种角色 。审查组长应回答有关检查单和角色分配的问题 ,并提交诸如最小准备时间 、建议的审查速率和在过去类似产品中发现的典型异常数目之类的审查数据 。

　　6.6.4 审查产品概述

　　作者应提交一份有关待审查软件产品的概述 。该概述应用于向审查员介绍软件产品 。从该陈述中受益的其他项目成员可以参加概述活动 。

　　6.6.5 准备

　　每一个审查组成员均应在审查会前检查软件产品和其他审查输入 。在检查期间发现的异常均应形成文档并提交给审查组长 。审查组长应对这些异常进行分类 , 以便确定是否有必要取消审查会议 ,从而有计划地有效利用审查会议时间 。一旦审查组长确认异常的程度或严重性足够 ,可取消审查 ,并要求当软件产品达到最小入口准则及合理性的无缺陷状态时再审查 。审查组长应将异常提交给软件产品的作者进行处理 。审查组长或者领读者应规定一个适当的顺序(例如 , 以顺序 、分层 、数据流 、控制流 、自底向上或自顶向下的顺序)来审查软件产品 。领读者应确保有充分准备的能在审查会上陈述软件产品 。

　　6.6.6 检查

　　6.6.6. 1 介绍会议

　　审查组长应介绍审查的参与者并描述他们的角色 。 审查组长应陈述审查的 目 的 ,并提醒审查员应致力于发现异常 ,而不是寻求解决异常 。审查组长还应提醒审查员把他们的意见直接提供给领读者 ,并且只评论软件产品而不评论产品的作者 。审查员可以向作者提出有关软件产品的问题 。审查组长应解决审查员提出的任何规程上的问题 。

　　有关问题的讨论应放在会议结束后 ,或者作为一次单独的会议 。

　　6.6.6.2 作好准备

　　审查组长应验证审查员是否已经准备就绪 。若审查员的准备不够充分 , 审查组长应重新安排会议的 日程 。审查组长应收集每个审查员的准备时间 ,并在审查文档中记录 。

　　6.6.6.3 审查通用项

　　涉及软件产品的通用异常(并因此不归因于某个特定实例或位置的异常) 应提交给审查员并记录在案 。

　　6.6.6.4 审查软件产品并记录异常

　　领读者应向审查组陈述软件产品 。审查组应客观和彻底地检查软件产品,在该审查会议期间审查组长应致力于形成异常清单 。记录员应在异常清单上填写每个异常 、位置 、描述和分类(异常分类参见附录 A) 。在此期间 ,作者应根据他对软件产品的特殊理解 , 回答具体的问题并发现其中的异常 。如果对某个异常存在争议 ,则应记录并标记为潜在的异常 , 以便在会议结束时加以解决 。

　　6.6.6.5 评审异常清单

　　在审查会结束时 ,审查组长应和审查组一起评审异常清单 , 以确保其完整性和准确性 。审查组长应为讨论每一个存在争议的异常留出足够的时间 。 审查组长应使讨论的重点放在阐述构成异常的要素上 ,而不关注异常的解决方法 。如果对异常或异常的严重性存在争议 ,该争议在会议上不能快速解决 ,那么该争议应该形成文档放进异常报告 。

　　6.6.6.6 作出结束决定

　　结束决定的目的是使审查会明确地结束 。结束决定应确定软件产品是否满足审查出 口和质量准则 ,并应描述相应的返工和验证 。具体地讲 ,审查组应将软件产品的处置方式标识为下述方式之一 :

　　● 无需(验证)返工或只需返工的验证次要的返工即可接受 。软件产品被完全接受或者只需次要的返工即可被接受(例如 ,软件产品无需进行进一步的验证) 。

　　● 返工验证后接受 。在审查组长或者某个指定的审查组成员(非作者) 验证了返工之后 , 软件产品才被接受 。

　　● 重新审查 。不被接受的软件产品,当异常被解决时 ,应安排重新审查的 日程 , 以验证返工 。 重新审查至少应检查因解决上次审查中发现的异常而更改的软件产品区域以及更改的副作用 。

　　6.6.7 返工或后续工作

　　审查组长或其代表应验证在审查会中指定的措施项已关闭 。

　　6.7 出 口准则

　　当 6. 6. 6 中列出的活动已经完成且 6. 8 中描述的输出已经存在时 ,审查才应视为已完成 。

　　6. 8 输出

　　审查输出应为文档化记录 , 内容包括 :

　　● 已审查的项 目 ;

　　● 审查组成员 ;

　　● 审查会的持续时间 ;

　　● 已审查的软件产品 ;

　　● 已审查材料的规模(例如 ,文本页数) ;

　　● 审查的具体输入 ;

　　● 审查的目标以及这些目标是否得到满足 ;

　　● 异常清单 ,包括每一个异常的位置 、描述和分类 ;

　　● 软件产品的处置 ;

　　● 任何豁免授权或豁免要求 ;

　　● 审查组个人及全员的准备时间 ;

　　● 总返工时间 。

　　审查输出还应包括 :

　　● 按异常分类统计的每类异常数目 ;

　　● 对影响较大的返工的工作量和返工完成日期的估计 ;

　　● 在审查中发现的 , 已固定项目的预期节省费用与后续标识出的固定项目成本对比 。

　　本标准只对文档化证据的内容提出最低要求 ,有关附加内容 、格式和存储介质等方面的要求宜在分项规程中描述 。

　　6.9 数据收集和改进

　　审查的数据收集和过程改进应按照附录 C 的相关要求进行 。

　　7 走查

　　7. 1 一般要求

　　一次走查可能指出若干缺陷(例如 ,软件产品的效率和可读性问题 ,在设计或编码中的模块性问题或者不可测试的规格说明) 。

　　走查组宜由 2 名 ~ 7名成员组成 。 每个成员可担任多个角色 ,一个角色也可由多个成员担任 。走查组长或作者可以作为记录员 。走查组长也可以是作者 。

　　任何走查组成员的管理者均不得参加走查 。

　　7.2 对象

　　走查的对象包括(但不限于)如下 :

　　● 源代码 ;

　　● 软件需求规格说明 ;

　　● 软件设计说明 ;

　　● 软件测试计划和规程 ;

　　● 软件用户文档 ;

　　● 维护手册 ;

　　● 系统开发规程 ;

　　● 安装规程 ;

　　● 发行说明 ;

　　● 授权证书 ;

　　● 软件开发过程描述 ;

　　● 软件架构描述 。

　　7.3 角色和职责

　　7.3. 1 角色

　　应为走查确定下述角色 :

　　● 走查组长 ;

　　● 记录员 ;

　　● 作者 ;

　　● 走查组成员 。

　　7.3.2 职责

　　7.3.2. 1 走查组长

　　走查组长应负责实施走查 ,处理与走查有关的管理任务(诸如分发文档和安排会议等) ,并确保走查按有序的方式进行 。走查组长应制定目标说明 , 以指导走查组进行走查 。走查组长应确保走查组为每一讨论项作出一个决定或者确定一个已标识的措施 ,并按 7. 8 中的描述发布走查输出 。

　　7.3.2.2 记录员

　　记录员应记录在走查会议期间作出的所有决定和已标识的措施 。此外 ,记录员还应记录在走查期间针对下述内容所作出的所有评论 :

　　● 发现的异常 ;

　　● 风格问题 ;

　　● 遗漏 ;

　　● 矛盾 ;

　　● 改进的建议或者备选方法 。

　　7.3.2.3 作者

　　作者应在走查中陈述软件产品 。

　　7.3.2.4 走查组成员

　　走查组成员应做好足够准备并积极参与走查 。走查组成员应标识和描述软件产品中的异常 。

　　7.4 输入

　　走查的输入应包括如下 :

　　● 走查目标说明 ;

　　● 待检查的软件产品 ;

　　● 获取 、供应 、开发 、运行和(或)维护软件产品的 、现行有效的标准 ;

　　● 评价软件产品所依据的规定 、标准 、指南 、计划 、规格说明和规程(包括测试用例等) ;

　　● 异常分类(参见附录 A) ;

　　● 走查清单 。

　　在走查组长要求的情况下 ,负责软件产品的人员应提供其他的参考材料 。

　　7.5 入口准则

　　7.5. 1 授权

　　应在适当的项目计划文档中明确实施走查的需要 。在获取 、供应 、开发 、运行和维护软件产品期间 ,可以应项目管理 、质量管理或作者的要求 ,依据本组织的规程来实施附加的走查 。

　　7.5.2 前提

　　仅当下述所有条件均成立时才可实施走查 :

　　● 需要实施走查的管理人员建立了走查目标说明 ;

　　● 必要的走查输入可用 ;

　　● 必要的评价软件产品的标准可用 。

　　7.6 规程

　　7.6. 1 管理准备

　　管理者或相关走查负责人应确保按照适用标准和规程的要求并根据法律 、合同或其他政策的规定实施走查 。 总之 ,管理者应做如下 :

　　● 策划走查所需要的时间和资源 ;

　　● 提供策划 、定义 、执行和管理走查所必需的资金和设施 ;

　　● 提供适用于给定项目的 、有关走查规程的培训和定向培训 ;

　　● 确保走查组成员具备理解待走查软件产品的 、适当的专业和知识水平 ;

　　● 确保已策划的走查得到实施 ;

　　● 及时对走查组的建议采取措施 。

　　7.6.2 策划走查

　　走查组长应负责下述活动 :

　　● 标识走查组成员的角色 ;

　　● 为走查组成员分配具体的职责 ;

　　● 安排会议的 日程并选择会议场所 ;

　　● 给所有参与者分发必要的输入材料 ,并为他们留有足够的准备时间 。

　　7.6.3 概述

　　作为走查会的一个部分 ,作者可对走查对象进行概要介绍 。

　　7.6.4 准备

　　走查组长应分发软件产品,并主持走查会议 。走查组成员应通过检查软件产品并列出要在走查会上讨论的项目清单 ,做好参加走查会的准备 。应将这些讨论项分为两类 :通用的和特定的 。通用项适用于整个产品,特定项适用于产品的某个部分 。在走查会开始前 ,每名走查组成员均应检查软件产品和其他评审输入 。在检查期间发现的异常应形成文档并提交给走查组长 。走查组长应对这些异常进行分类 , 以确保走查会的时间得到有效的使用 。走查组长应将这些异常提交给软件产品的作者进行处理 。

　　作者或走查组长应规定一个明确的次序(例如 :顺序 、分层 、数据流 、控制流 、自底向上的或自顶向下等)来评价软件产品 。

　　7.6.5 检查

　　走查组长应介绍所有参与者并描述他们的角色 。走查组长应陈述走查的 目 的 ,促进并确保每个成员都有发言机会以及征求与会者的意见确保每个建议都能被听到 。走查组长提醒走查组成员将重点放在发现异常而不是解决异常上 。走查组长应提醒走查组成员只评论软件产品而不评论其作者 。走查组成员可以向作者提出有关软件产品的问题 。走查组长应解决走查组成员提出的 、有关走查规程的任何问题 。

　　在走查会期间 :

　　● 作者或走查组长应概述待检查软件产品 ;

　　● 走查组长应协调有关通用异常的讨论 ;

　　● 作者或走查组长应陈述软件产品,说明软件产品的每一个部分 ;

　　● 当作者陈述到与异常有关的软件产品部分时 ,走查组成员应提出具体的异常 ;

　　● 走查组长协调并指导走查组对每个异常逐项做出决定或者标识建议和措施 ;

　　● 记录员记录所有决定 、建议和措施 。

　　在走查会后 ,走查组长应发布详细描述异常 、决定 、措施和其他相关信息的走查输出 。 在 7. 8 中给出了走查输出内容的最低要求 。

　　7.6.6 返工或后续工作

　　走查组长或其代表应验证走查会上指定的措施项已经关闭 。

　　7.7 出 口准则

　　当满足下述条件时 ,走查才应视为已完成 :

　　● 7. 4描述的目标已达到 ;

　　● 已记录了决定 、建议和措施 ;

　　● 已完成了走查输出 。

　　7. 8 输出

　　走查输出应为文档化的记录 , 内容包括 :

　　● 已走查的项 目 ;

　　● 走查组成员 ;

　　● 已走查的软件产品 ;

　　● 在本次走查会期间完成的目标说明 , 以及这些目标是否已经达到 ;

　　● 异常清单 ,包括每个异常的定位和描述 ;

　　● 针对每个异常所做出的建议清单 ;

　　● 措施 、完成日期和责任人的清单 ;

　　● 走查组针对如何处理缺陷和未解决异常而提出的所有建议 ;

　　● 走查组对后续走查而提出的所有建议 。

　　本标准只对文档化证据的内容提出最低要求 ,有关附加内容 、格式和存储介质等方面的要求宜在本地规程中描述 。

　　7.9 数据收集和改进

　　走查的数据收集和改进应按照附录 C 的相关要求进行 。

　　8 审核

　　8. 1 一般要求

　　在审核前应首先召开一个预备会 ,在会上审核员和待审核组织检查并同意审核安排 。

　　在制定审核计划时 ,审核员可能提出一些建议 。这些建议应单独报告 。

　　审核组宜由 1 名 ~ 5 名成员组成 。

　　主任审核员可以作为记录员 。发起人可以作为主任审核员 。

　　8.2 对象

　　审核的软件产品对象包括(但不限于)如下 :

　　● 备份和恢复计划 ;

　　● 应急计划 ;

　　● 合同 ;

　　● 顾客或用户代表的投诉 ;

　　● 容灾计划 ;

　　● 硬件性能方案 ;

　　● 安装计划 ;

　　● 安装规程 ;

　　● 维护计划 ;

　　● 管理评审报告 ;

　　● 操作和用户手册 ;

　　● 采购和签约方法 ;

　　● 报告和数据(例如 ,评审 、审核 、项目状态 、异常报告 、测试数据) ;

　　● 招标书 ;

　　● 风险管理计划 ;

　　● 软件配置管理计划 ;

　　● 软件设计说明 ;

　　● 源代码 ;

　　● 单元开发文件夹 ;

　　● 软件项目管理计划 ;

　　● 软件质量保证计划 ;

　　● 软件需求规格说明 ;

　　● 软件安全性计划 ;

　　● 软件测试文档 ;

　　● 软件用户文档 ;

　　● 软件验证和确认计划 ;

　　● 软件架构描述 ;

　　● 标准 、规定 、指南 、计划 、规格说明和规程 ;

　　● 系统开发规程 ;

　　● 技术评审报告 ;

　　● 厂商文档 ;

　　● 走查报告 ;

　　● 可交付介质(例如光盘) 。

　　审核的软件过程对象包括(但不限于)软件开发生存周期过程描述 。

　　8.3 角色和职责

　　8.3. 1 角色

　　应为审核确定下述角色 :

　　● 主任审核员 ;

　　● 记录员 ;

　　● 审核员 ;

　　● 发起人 ;

　　● 被审核组织 。

　　主任审核员可以作为记录员 。发起人不应该作为主任审核员 。候补审核员应被包括在审核组 ; 由单独一个人的审核也是允许的 。

　　8.3.2 职责

　　8.3.2. 1 主任审核员

　　主任审核员应对审核负责 ,其职责包括管理与审核有关的任务 ,确保审核以有序的方式进行并满足它的目标 。 主要包括如下 :

　　● 编制审核计划(见 8. 6. 2) ;

　　● 组建审核组 ;

　　● 管理审核组 ;

　　● 做出有关审核实施的决定 ;

　　● 做出有关审核观察的决定 ;

　　● 编制审核报告(见 8. 8) ;

　　● 报告在审核过程中人员不能或者明显不能履行职责的情况 ;

　　● 同发起人协商差异或者不一致性 , 这 些 差 异 或 者 不 一 致 性 可 能 削 弱 满 足 出 口 准 则(见 8. 7) 的能力 ;

　　● 推荐纠正措施 。

　　主任审核员应不带任何偏见且不施加任何影响 , 以免降低审核员作出独立且客观评价的能力 。

　　8.3.2.2 记录员

　　记录员应将审核组提出的异常 、措施项 、决定和建议形成文档 。

　　8.3.2.3 审核员

　　审核员应按照审核计划的定义对项目进行检查 。他们应将其观察和提出的纠正措施形成文档 。审核员应不带任何偏见且不施加任何影响 , 以免降低其他审核员作出独立且客观评价的能力 ;或者应标识自己的观点 ,并在得到发起人的认可后再进行其余活动 。

　　8.3.2.4 发起人

　　发起人应负责下述活动 :

　　● 确定审核的需要 ;

　　● 确定审核的目的与范围 ;

　　● 确定待审核的软件产品 ;

　　● 确定评价所使用的规定 、标准 、指南 、计划和规程 ;

　　● 决定实施审核的人员 ;

　　● 评审审核报告 ;

　　● 确定必要的后续措施 ;

　　● 发布审核报告 。

　　发起人既可以是被审核组织的管理者 ,也可以是被审核组织的顾客或者用户代表 ,还可以是第三方

　　组织 。

　　8.3.2.5 被审核组织

　　被审核组织应为审核员提供一名联络员 ,并提供审核员需要的所有信息 。在审核完成时 ,被审核组织应实施纠正措施和建议 。

　　8.4 输入

　　在审核计划中应列出审核的输入 ,并应包括如下 :

　　● 审核的目的和范围 ;

　　● 被审核组织的背景信息 ;

　　● 待审核的软件产品或过程 ;

　　● 审核所使用的适用规定 、标准 、指南 、计划 、规格说明和规程 ;

　　● 评价准则 :例如 ,“可接受的 ”、“需要改进的 ”、“不可接受的 ”、“不评定的 ”。

　　也可包括以往类似审核的记录 。

　　在审核组长要求的情况下 ,负责软件产品或过程的人员应提供其他的参考材料 。

　　8.5 入口准则

　　8.5. 1 授权

　　发起人确定审核需要 。该决定既可以由某个例行事件(例如 ,到达项目的某个里程碑)启动 ,也可以由某个非例行事件(例如 ,怀疑或者发现了一个重大不符合项)启动 。

　　发起人选择一家能够实施独立评价的审核组织 。发起人为审核员提供确定审核 目 的的信息 、待审核的软件产品或过程和评价准则 。发起人应要求审核员提出建议 。 主任审核员完成审核计划 , 审核员做好审核准备 。可通过下述一个或多个事件确定审核的需要 :

　　● 供方组织决定验证对适用规定 、标准 、指南 、计划 、规格说明和规程的符合性(这种决定可能在策划项目时就已经做出) ;

　　● 顾客组织决定验证对适用规定 、标准 、指南 、计划 、规格说明和规程的符合性 ;

　　● 第三方(例如 ,某个管理机构或评估实体)决定需要审核供方组织 , 以验证对适用规定 、标准 、指南 、计划 、规格说明和规程的符合性 。

　　在每一种情况下 ,发起人都应对审核进行授权 。

　　8.5.2 前提

　　仅当下述条件均成立时才可实施审核 :

　　● 审核已得到发起人的授权 ;

　　● 已建立审核目标说明 ;

　　● 必要的审核输入可用 。

　　8.6 规程

　　8.6. 1 管理准备

　　管理者应保证审核按照适用标准和规程的要求以及法律 、合同或其他政策的强制性要求进行 。 为了达到这个目的 ,管理者应做如下 :

　　● 策划审核需要的时间和资源 ,其中包括支持职能 、法律或规定文本 、或其他适用标准 ;

　　● 为策划 、定义 、实施和管理审核提供必要的资金和设备 ;

　　● 针对适用于特定项目的审核规程 ,提供培训和定向培训 ;

　　● 确保具备相应的专业水平和知识 , 以便理解待审核的软件产品 ;

　　● 确保已策划的审核活动得到实施 ;

　　● 及时对审核组的建议采取措施 。

　　8.6.2 策划审核

　　审核计划应描述如下内容 :

　　● 审核的目的和范围 ;

　　● 被审核的组织(包括场地和管理) ;

　　● 待审核的软件产品 ;

　　● 评价准则 ,包括用于评价的适用规定 、标准 、指南 、计划和规程 ;

　　● 审核员的职责 ;

　　● 检查活动(例如 ,访谈人员 、阅读和评价文档 、观察测试等) ;

　　● 审核活动资源需求 ;

　　● 审核活动的进度安排 ;

　　● 保密需求 ;

　　● 检查单 ;

　　● 报告格式 ;

　　● 报告发布 ;

　　● 必要的后续活动 。

　　当采取抽样技术时 ,应使用在统计学上有效的抽样方法 , 以确立选择的准则和样本的大小 。审核计划应得到发起人的批 准 。 审 核 计 划 应 允 许 根 据 在 审 核 期 间 收 集 到 的 信 息 进 行 更 改 , 并 得 到 发 起 人 的批准 。

　　8.6.3 首次会议

　　在开始审核的检查阶段时 ,应召开审核组和被审核组织之间的首次会议 。整个会议议程应包括 :

　　● 审核的目的和范围 ;

　　● 待审核的软件产品或过程 ;

　　● 审核规程和输出 ;

　　● 被审核组织对审核的预期贡献(例如 ,被访谈人数 、会议设施) ;

　　● 审核的进度安排 ;

　　● 获得必要的设备 、信息和文档 。

　　8.6.4 准备

　　除非特殊原因 ,发起人应在进行审核之前书面通知被审核组织的管理人员 。通知应明确审核的 目的和范围 ,应标识待审核的内容 、审核员和审核的进度安排 。通报的目的是使被审核组织能够确保在审核中被检查的人员和材料及时到位 。

　　审核员应通过研究下述内容来准备审核 :

　　● 审核计划 ;

　　● 被审核组织 ;

　　● 待审核产品或过程 ;

　　● 用于评价的适用规定 、标准 、指南 、计划 、规格说明和规程 ;

　　● 评价准则 。

　　主任审核员还应安排如下事项 :

　　● 审核组的培训和定向培训 ;

　　● 用于审核访谈的设施 ;

　　● 审核规程所需要的材料 、文档和工具 。

　　8.6.5 检查

　　8.6.5. 1 证据收集

　　审核员应通过访谈被审核组织的员工 、检查文档和见证过程的形式 ,收集符合与否的证据 。审核员应尝试在审核计划中定义的所有检查活动 。如果审核员认为需要进行某些额外的调查活动来确定符合性或不符合性的程度 ,那么 ,他们应承担这些额外的调查活动 。

　　审核员应将不符合性的所有观察和符合性示例形成文档 。观察是在审核期间作出的事实陈述 ,且该事实由某个客观证据所证实 。不一致性的示例包括如下 :

　　● 根本不使用适用的规定 、标准 、指南 、计划 、规格说明和规程 ;

　　● 未正确地使用适用的规定 、标准 、指南 、计划 、规格说明和规程 。

　　观察应分类为主要的或者次要的 。如果不符合性可能对产品质量 、项 目成本或者项 目进度产生重大影响 ,则该观察应被分类为主要的(主要观察通常被称为 “发现 ”) 。

　　在末次审核会议召开之前 ,所有观察均应同被审核组织进行讨论以得到核实 。

　　8.6.5.2 末次会议

　　主任审核员应召集被审核组织的管理人员参加末次会议 。末次会议应评审如下 :

　　● 审核计划的实际实施情况 ;

　　● 实施审核计划过程中经历的所有问题 ;

　　● 审核员作出的观察 ;

　　● 审核员的初步结论 ;

　　● 审核员的初步建议 ;

　　● 全面的审核评估(例如 ,被审核组织是否成功通过审核准则) 。

　　应解决被审核组织提出的解释和问题 。在末次审核会议期间应达成协议 ,在审核报告定稿之前须达成一致 。

　　8.6.5.3 报告

　　主任审核员应按 8. 8 的要求编制审核报告 。审核报告应在审核后尽快编制完成 。在末次审核会议和发布报告期间 ,审核员和被审核组织间进行的交流和报告的争议都应通过主任审核员 。 主任审核员应向发起人和被审核组织提交审核报告 。发起人应在被审核组织中发布审核报告 。

　　8.6.5.4 返工或后续工作

　　若存在返工 ,则返工应由发起人和被审核组织负责 ,并应包括如下 :

　　● 决定采用必要的纠正措施 , 以便消除或者防止某种不符合性 ;

　　● 启动纠正措施 。

　　8.7 出 口准则

　　在满足下列条件时应视为审核已完成 :

　　● 审核报告已提交给发起人 ;

　　● 在审核范围内 审 核 组 织 的 所 有 后 续 活 动 发 现 都 已 得 到 处 理 或 解 决 和 批 准 关 闭 执 行 、评 审 和批准 。

　　8. 8 输出

　　审核的输出是审核报告 。审核报告应包括如下内容 :

　　● 审核的目的和范围 ;

　　● 被审核组织 ,其中包括场所 、联络员和管理人员 ;

　　● 已审核软件产品或过程的标识 ;

　　● 用于评价的适用规定 、标准 、指南 、计划 、规格说明和规程 ;

　　● 评价准则 ;

　　● 审核员的组织的概况 ;

　　● 检查活动概况 ;

　　● 未执行的计划内检查活动的概况 ;

　　● 已按主次分类的观察清单 ;

　　● 审核发现(包括关键的不符合项)的概况和解释 ;

　　● 审核后续活动的类型和时间安排 。

　　此外 ,在审核计划有规定时 ,应给被审核组织和发起人提供建议 。建议可以与审核结果分开报告 。本标准只对文档化证据的内容提出最低要求 ,有关附加内容 、格式和存储介质等方面的要求宜在分项规程中描述 。

　　关于管理评审 、技术评审 、审查 、走查和审核这五种评审类型的比较参见附录 B。

　　附 录 A

　　(资料性附录)

　　软件异常分类示例

　　A. 1 逻辑问题

　　逻辑问题可分为 :

　　a) 遗忘的情况或步骤 ;

　　b) 重复逻辑 ;

　　c) 不必要的功能 ;

　　d) 错误解释 ;

　　e) 遗漏条件测试 ;

　　f) 检查错误的变量 ;

　　g) 不正确的循环 :

　　1) 不正确的循环初值 ;

　　2) 不正确的循环终止条件 ;

　　3) 不正确的循环计数 ;

　　4) 循环永不终止 。

　　A.2 计算问题

　　计算问题可分为 :

　　a) 等式不充分或不正确 :

　　1) 缺少计算 ;

　　2) 等式中的操作符不正确 ;

　　3) 等式中的操作数不正确 ;

　　4) 括号的使用不正确 ;

　　5) 除数为零 ;

　　6) 对负数求平方根 。

　　b) 精度问题 :

　　1) 舍入进位或截断进位问题 ;

　　2) 混合运算问题 ;

　　3) 符号约定故障 ;

　　4) 定点比例尺选择不当 ;

　　5) 常数有效位不够 。

　　A.3 接口或定时问题

　　接口或定时问题可分为 :

　　a) 中断处理不正确 :

　　1) 未对必要的数据或寄存器进行保护 ;

　　2) PUSH 和 POP操作不匹配 ;

　　3) 中断嵌套考虑不周 。

　　b) I/O定时不正确 :

　　1) 定时故障导致数据丢失 。

　　c) 子程序或模块不匹配 :

　　1) 不正确的子程序调用 ;

　　2) 不存在的子程序调用 ;

　　3) 不一致的子程序参数 。

　　A.4 数据处理问题

　　数据处理问题可分为 :

　　a) 数据初始化不正确 :

　　1) 堆栈初始化不正确 ;

　　2) 数组初始化不正确 ;

　　3) 指针初始化不正确 ;

　　4) 局部变量初始化不正确 ;

　　5) 全局变量初始化不正确 ;

　　6) 循环变量初始化不正确 。

　　b) 数据访问或存储不正确 :

　　1) 标志或索引设置不正确 ;

　　2) 压缩或解压缩数据不正确 ;

　　3) 引用了错误的数据变量 ;

　　4) 数据引用越界 。

　　c) 数据的单位不正确 ;

　　d) 数据维数不正确 :

　　1) 变量类型不正确 ;

　　2) 下标变量不正确 。

　　e) 数据范围不正确 。

　　A.5 数据问题

　　数据问题可分为 :

　　a) 传感器数据不正确或遗漏 ;

　　b) 操作数数据不正确或遗漏 ;

　　c) 表中的嵌入数据不正确或遗漏 ;

　　d) 外部数据不正确或遗漏 ;

　　e) 输出数据不正确或遗漏 ;

　　f) 输入数据不正确或遗漏 。

　　A.6 文档问题

　　文档问题可分为 :

　　a) 二义性的陈述 ;

　　b) 不完全的项 目 ;

　　c) 不正确的项 目 ;

　　d) 遗漏的项 目 ;

　　e) 冲突的项 目 ;

　　f) 冗余的项 目 ;

　　g) 混淆的项 目 ;

　　h) 不合逻辑的项 目 ;

　　i) 不可验证的项 目 ;

　　j) 不可达到的项 目 。

　　A.7 文档质量问题

　　文档质量问题可分为 :

　　a) 不满足适用的标准 ;

　　b) 不可跟踪的 ;

　　c) 非当前的 ;

　　d) 不一致性 ;

　　e) 不完整性 。

　　附 录 B

　　(资料性附录)

　　评