软件工程软件评审与审核

软件工程软件评审与审核

国家标准 GB/T32421一2015 软件工程软件评审与审核 Softwareengineering一Softwarereiewsandaudits 2015-12-31发布 2016-08-01实施 国家质量监督检验检疫总局 发布 国家标准化管理委员会国家标准
GB/T32421一2015 目 次 前言 引言 范围 规范性引用文件 术语和定义 管理评审 -般要求 4.1 对象 4.2 4.3角色和职责 4.4输人 4.5人口准则 4.6规程 4.7出口准则 4.8输出 技术评审 5.l -般要求 5.2对象 角色和眼责 5.3 5.4输人 5.5人口准则 5.6规程 5.7 出口准则 5.8输出 审查 6.1 -般要求 6.2对象 6.3角色和职责 6.4输人 6.5 人口准则 2 6.6规程 6.7出口准则 6.8输出 6.9数据收集和改进 走查 7.1 -般要求 15 15 7.2对象
GB/T32421一2015 15 7.3角色和职责 16 7.4输人 7.5人口准则 16 1" 7.6规程 7.7出口准则 18 7.8输出 18 7.9数据收集和改进 18 审核 8 -般要求 8 8.1 8.2对象 8.3角色和职责 21 8.4 输人 21 8.5人口准则 21 8.6规程 8.7出口准则 23 8.8输出 24 附录A(资料性附录)软件异常分类示例 25 附录B(资料性附录)评审与审核内容的比较 28 附录c规范性附录)数据收集建议和过程改进要求 30
GB/T32421一2015 前 言 本标准按照GB/T1.1一2009给出的规则起草 请注意本文件的某些内容可能涉及专利 本文件的发布机构不承担识别这些专利的责任 本标准由全国信息技术标准化技术委员会(SAC/TC28)提出并归口 本标准起草单位:广州广软信息技术服务有限公司、电子技术标准化研究院、国家网络软件产 品质量监督检验中心(济南,航天科技集团公司软件评测中心、上海计算机软件技术开发中心 本标准主要起草人:袁肃蓉,刘新、黄姗姗、田辉、杨桂枝、蔡立志,刘振宇,龚家瑜 m
GB/T32421一2015 引 言 本标准为软件开发的管理和技术人员提供软件管理和工程的标准规范和方法,是实现软件质量保 证的重要措施 软件的评审和审核应利用科学的方法,以严谨的态度及严格的规定有序地进行,软件开 发的管理和技术人员各履其职,制定完备的计划及措施确保评审和审核的过程顺利完成 本标准是为软件评估和相应的规定、标准、指南、计划,规格说明和规程的符合性评价而提出,是对 软件和开发过程所做的一种独立检查 本标准包括管理评审、技术评审、审查,走查、审核等部分,规定 了软件评审和审核的对象,角色 人口准则、规程、出口准则和输出等方面的要求 软件管理 者应按照适用的标准和规程,并结合法律、合同或其他法规的要求进行评审 本标准中的角色对象以及评审审核过程形成一个较完整的集合,贯穿软件开发及服务的整个生存 周期过程,软件开发的管理和技术人员并可通过此标准控制和改进过程 本标准适用于在整个软件生存周期内进行的软件评审和审核,软件开发的管理和技术人员可将本 标准与GB/T856(信息技术软件生存周期过鞋》对照使用.可相应选择适合软件开发和后续服务的 子过程或全过程
GB/I32421一2015 软件工程软件评审与审核 范围 本标准规定了软件评审与审核的对象,角色、职责,输人,人口准则,规程,出口准则和输出等方面的 要求 软件评审与审核包括管理评审、技术评审审查,走查和审核等五种类型 本标准适用于软件产品的生存周期全部过程 规范性引用文件 下列文件对于本文件的应用是必不可少的 凡是注日期的引用文件,仅注日期的版本适用于本文 件 凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件 GB/T11457信息技术软件工程术语 GB/T19001质量管理体系要求 术语和定义 GB/T11457中界定的以及下列术语和定义适用于本文件 异常 an0mal 与根据需求规格说明、设计文档、用户文档、标准等建立的期望相偏离的情况,或者与人的感知或经 验相偏离的情况 注:异常可以在下述(但不限于)期间发现软件产品或适用文档的评审、测试,分析、编译或使用 包括故障,缺 陷等 3.2 评审review 向项目成员、管理人员、用户,顾客、用户代表,审核员或其他相关方阐述软件产品、软件产品集合或 软件过程的过程或会议,以便进行检查、评论或批准 3.3 管理评审managementreview 由管理部门或者代表管理部门对软件产品或过程的进行的一种系统性评价,以便监督进展,确定计 划和进度的状态,确认需求和需求的系统分配,或者评价管理方法的有效性以达到最佳的目的 3.4 技术评审teehnicealreyiew 由一组具备资格的人员对软件产品进行的一种系统性评价,以检查软件产品对其预期用途的适合 性,并标识与规格说明和标准的差异 技术评审可提出推荐的备选方法并检查各种不同的备选方法 3.5 审查inspetiom 对软件产品的一种可视检查,以检测和标识软件异常,其中包括错误,对标准和规格说明的偏离 审查是由受过审查技术培训的、公正的组织者领导的同行检查 注审查结果可不包括解决方案,但宜确定异常的补救措施或调查措施
GB/T32421一2015 3.6 wallk-thr 走查 hrough 一种静态分析技术,设计者或程序员引导开发组成员和其他有关方通读软件产品,参与者提出问题 并对可能的异常、违反开发标准之处和其他问题进行评论 3.7 审核audit 为评估与规格说明、标淮、合同协议或其他准则的符合性而由第三方实施的对软件产品、软件过程 或软件过程集合所作的一种独立检查 注，审核宜对是否已达到审核准则给出一个明确的指示 管理评审 4.1 -般要求 管理评审由直接负责系统的管理人员或其代表执行,以识别里程碑工作成果与计划的一致性和偏 离,或者识别遵循管理规程的充分性 管理评审应由具有资格评价软件产品或过程的人员来实施 4.2对象 管理评审的对象如下 基于文档的对象包括但不仅限于)如下 异常报告; 审核报告; 备份和恢复计划; 应急方案; 需求规格说明; 顾客或用户代表的投诉; 容灾方案; 硬件性能方案; 安装计划; 维护计划; 采购和签约方法; 进度报告; 风险管理计划; 软件配置管理计划; 软件项目管理计划 软件质量保证计划 软件安全性设计; 软件验证和确认计划 技术评审报告 软件产品分析 验证和确认报告; 迁移策略和计划 测试结果;
GB/T32421一2015 软件开发过程描述; 软件架构措述 基于过程的对象包括(但不仅限于)如下 获取过程; 供应过程; 开发、运作和维护过程; 文档编制过程; 配置管理过程; 质量保证过程; 验证、确认和联合评审过程; 审核过程; 问题解决过程; 管理、改进和基础过程; 培训过程 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管理人员 指定实施管理评审的管理人员应积极参与管理评审 对系统整体负责的管理人员还应承担在
GB/T32421一2015 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/T19001或其他相关标准的要求,策划实施评审所需要的时间和资源,包括支撑职能 提供策划、定义、执行和管理该评审所需要的资金和设施;
GB/T32421一2015 提供适用于给定项目的有关评审规程的培训和定向培训 确保评审组成员具有理解待评审软件产品或过程的,适当的专业和知识水平 确保已策划的评审得到实施; 及时对评审组的建议采取措施 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中描述的输出已经存在时,管理评审才应视为已完成
GB/T32421一2015 4.8输出 管理评审的输出应为文档化的记录,包括下述内容 已评审的软件产品与过程; 评审组成员; 评审目标; 评审的具体输人; 措施项的状态(待处理或已关闭、责任人和预定日期(若为待处理)或者完成日期(若为已关闭); 评审组标识的异常清单,这些异常应进行处理以满足项目目标 本标准只对文档化证据的内容提出最低要求,有关附加内容、格式和存储介质等方面的要求宜在分 项规程中描述 在分项规程中确认的评审的输出应提交给决策者,其他管理者以及项目涉及人员 技术评审 -般要求 技术评审可提供对不同备选方案的建议和检查,技术评审可根据需要召开一次或多次会议 检查 不必包含产品的所有方面 技术评审组宜由三名以上成员组成 5.2对象 技术评审的对象包括(但不仅限于)如下 软件需求规格说明; 软件设计说明 软件测试文档 软件用户文档; 维护手册; 系统开发规程; 安装规程; 发布说明; 软件开发过程描述; 软件架构说明 5.3 角色和职责 5.3.1 角色 应为技术评审确定下述角色 决策者; 评审组长; 记录员 技术人员 也可确定下述角色 管理人员; 其他组员;
GB/T32421一2015 其他利益相关方如管理者、技术人员、顾客和用户 参评者可以担任一个以上(但不能是全部)的角色 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授权 应在项目策划文档中确定实施技术评审的需要,例如项目策划质量保证计划,安全计划等 除了 某个具体计划要求的技术评审之外,职能管理部门、项目管理部门、软件质量管理部门、系统工程组或软 件工程组根据本地化规程的要求,也可以授权提出并实施一些其他的技术评审 可要求技术评审评价 硬件或第三方产品的异常或者缺陷对软件产品的影响
GB/T32421一2015 5.5.2前提 仅当评审的目的说明已建立和职责人员已充分培训这两者同时满足时才可实施技术评审 5.6规程 5.6.1管理准备 管理者应确保按照适用的标准和规程并按照法律、合同或其他法规的要求进行评审 为此,管理 者应 按照GB/T19001或其他相关标准的要求,策划实施评审所需要的时间和资源,包括支持职能; 提供策划、定义、执行和管理该评审所需要的资金和设施， 提供适用于给定项目的有关评审规程的培训和定向培训 确保评审组成员有足够理解待评审软件产品的适当的技术、专业和知识水平 确保已策划的评审得到实施; 及时对评审组的建议采取措施 注:评审组长负责挑选评审员,管理者负责管理评审员 5.6.2策划评审 评审组长应负责下述活动 通过适当的管理支持来标识评审组成员的角色 为评审组成员分配具体的职责; 安排并通知会议的日程; 向参与者分发评审材料,并为他们留出足够的准备时间 建立一个发布评审材料,返回评论并将评论提交给作者处理的时间表 作为策划规程的一个部分,评审组应确定是否在评审会上讨论备选方案 备选方案既可以在评审 会上讨论,也可以在此后的某次单独的会议上讨论,还可以留待软件产品的作者解决 5.6.3评审规程概述 在评审组长要求的情况下,应由一名具备资格的人员为评审组进行概要介绍 可以在评审会上作 概要介绍(见5.6.6),也可以单独开会作概要介绍 5.6.4软件产品概述 在评审组长要求的情况下,应由一名具备技术资格的人员为评审组作软件产品概述 可以在评审 会上作软件产品概述(见5.6.6),也可以单独开会做概述 5.6.5准备 在评审会议之前,每一个评审组成员都应检查软件产品和其他评审输人 在检查期间发现的异常 应形成文档并提交给评审组长 评审组长应对这些异常进行分类,以确保评审会的时间得到最有效的 使用 评审组长应将异常提交给软件产品的作者进行处理 评审组长应验证评审组成员已为技术评审做好了准备 如果评审组成员的准备不充分,评审组长 应采用更换人员,重新分配任务或重新安排会议的日程等纠正措施 5.6.6检查 在技术评审期间,评审组应召开一次或多次会议 会议应达到下述目标
GB/T32421一2015 决定评价软件产品和异常的日程; a b确定 软件产品是否完备; 软件产品是否符合适用于项目的规定、标准,指南,计划、规格说明和规程; 软件产品的更改是否得到了适当的实施且只影响指定的区域; 软件产品是否适合于预期的用法 软件产品是否就绪,以便进行下一项活动; 检查中发现的软件项目安排中的必要的调整; 是否在硬件外部或附属软件等其他系统元件中存在异常是否存在硬件异常或者规格说 明差异 标识异常并确认其危险性 注:措施项由后续的管理分配 d)产生措施项清单,强调风险; 将会议内容形成文档 e 在软件产品评审之后,应形成文档,以便记录会议内容,列出在软件产品中发现的异常,描述为管理 部门提出的建议 在异常足够关键或者足够多时,评审组长应建议对修改后的软件产品进行一次附加评审 附加评 审至少应涵盖为解决异常而更改了的区域以及这些更改的副作用 5.6.7 返工或后续工作 评审组长或其代表应验证在评审会中指定的措施项已关闭 5.7 出口准则 当5.6.6中列出的活动已经完成且在5.8中描述的输出已经存在时,技术评审才应视为已完成 5.8输出 技术评审的输出应为文档化的记录,包括下述内容 已评审的项目; 评审组成员; 已评审的软件产品; 评审的具体输人; 评审目标以及是否达到了评审目标; 软件产品异常清单; 未解决的系统或硬件异常清单或措施说明; 管理问题清单; 措施项的状态(待处理或已关闭,责任人和预定日期(若为待处理)或者完成日期(若为已关闭); 评审组针对如何处理未解决的问题和异常提出的建议: 软件产品是否无偏离地满足适用的规定、,标准,指南,计划和规程 本标准只对文档化证据的内容提出最低要求,有关附加内容、格式和存储介质等方面的要求宜在分 项规程中描述 审查 6.1一般要求 审查组宜由3名6名成员组成(包括作者.
GB/T32421一2015 所有参评人员都是审查员 作者既不能作为审查组长,也不能作为领读者或记录员 其他角色均 可由审查组成员担当,个别成员可以担当一个以上的角色 审查组组长由经过审查技术培训且公正的专业人士担任 任何审查组成员的管理者均不应参加 审查 尽管在审查会上不做出解决方案,但应确定异常的补救措施或调查措施 在软件审查过程中,宜进行数据收集,以便分析和改进软件工程规程(包括所有评审规程) 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记录员 记录员应将审查组提出的异常、措施项、决策,弃权声明和建议形成文档 记录员应记录进行过程 10o
GB/T32421一2015 分析所需要的审查数据 评审组长可作为记录员 6.3.2.3领读者 领读者应以一种全面和逻辑的方式引导审查组遍历软件产品,解释工作的各个部分(例如,通常以 13行为一个解释组)并强调重要的方面 软件产品应被划分为逻辑部分并分配给不同的领读者以便减少所需的准备时间 6.3.2.4作者 作者应负责软件产品满足审查的人口准则;使审查能够在充分理解软件产品的基础上进行;并负责 执行所需要的返工.,以使软件产品符合审查的出口准则 6.3.2.5审查员 审查员应标识和描述软件产品中的异常 审查员的选择应基于他们的专业和在会议中应代表的不 同视角(例如,主办者、需求、设计、代码,安全性,测试,独立测试、项目管理、质量管理和硬件工程) 审 查员应只提出与产品市查相关的观点 应指定部分审查员负责特定的审查专题以确保有效的覆盖 例如，一个审查员可以关注与某个或 某些特定标准的符合性,另一些审查员可以关注语达的符合性或数据的准确性,其他审查员可以负责整 体的相关性 如6.6.2所阐述的那样,当策划审查时,这些角度应由审查组长分配 6.4输入 审查的输人应包括如下: 审查目标的陈述; 待审查的软件产品 文档化的审查规程; 审查报告的表格 当前的异常或问题清单 也可包括 源文件,例如需求和软件产品输人等已被开发者采用的软件产品的开发输人; 审查检查单; 质量准则所要求的再检查; 已检查,批准或已建立为一个基线的上一版本软件产品， 审查软件产品所依据的规定、标准、指南,计划、规格说明和规程; 硬件、仪器或其他软件产品的规格说明; 性能数据; 异常分类(参见附录A 在审查组长要求的情况下,负责软件产品的人员应提供其他的参考材料 6.5入口准则 6.5.1授权 审查应在相应的项目策划文档例如,整个项目的计划,或软件质量保证计划或者软件验证和确认 计划)中进行策划和形成文档 在软件产品的生存周期过程中,可以根据项目管理、质量管理或作者的要求,按照本地化的规程实 1l
GB/T32421一2015 施额外的审查 6.5.2前提 仅当相关的审查输人可用时才可实施审查 6.5.3最小入口准则 除非存在一个被管理者所接受的、书面的证明,否则,须满足以下所有条件才应实施审查: 待审查的软件产品是完整的,并在格式上符合项目的标准; 审查前所需要的自动化错误检测工具(例如,拼写检查器和编译器)是可用的 已满足在相应策划文档中标识的、先前的里程碑要求; 必要的支持文档是可用的; 对于复查,在异常清单中记录的、对待审查软件产品有影响的所有项均已解决 6.6规程 6.6.1 管理准备 管理者应确保按照适用的标准和规程并按照法律、合同或其他政策规定的要求进行审查 为此,管 理者应 按照GB:/T19001或其他相关标准的要求,策划实施审查所需要的时间和资源,包括支持职能; 提供策划定义、执行和管理审查所需要的资金、设施和工具 提供适用于给定项目的有关审查规程的培训和定向培训,确保评审审查组成员具有理解待审 查软件产品的,适当的专业和知识水平; 确保审查是有计划的,确保计划的审查得到实施 及时对审查组的建议采取措施 6.6.2策划审查 作者应为审查组长汇总审查材料,包括待审查软件产品用于软件产品开发的标准及文档 审查组 长应负责下述活劝 通过适当的管理支持来确定审查组成员的角色; 注:确保审查组成员具有充分理解待审查软件产品及作者用于开发软件产品的文档的知识及专业水平 为审查组成员分配具体的职责; 安排会议的日程、选择会议场所及通知审查组成员; 给所有参与者分发审查材料,并为他们留出足够的准备时间 建立一个发布审查材料,返回评论并将评论提交给作者处理的时间表 确定审查范围包括优先审查的文件; 设定准备及会议期间预期的审查速率 注;多数情况下,预估的审查速率是审查策划中的重要因素 表1提供了以页或行代码每小时为单位的典型 的审查速率和异常记录速率参考 表1审查文档类型和审查速率 审查文档类型 审查速率 架构 2PPH3PPHH" 需求 2PPH~3PPH 12
GB/T32421一2015 表1(续 审查文档类型 审查速率 概要设计 3PPH~4PPH 3PPH4PPH 详细设计 源代码 100lLPHI200LPHH 测试计划 5PPH7PPH 变更 50LPH一75LPH 用户文档 8PPH20PPH 页每小时 行代码每小时 6.6.3审查规程概述 审查组长应分派各种角色 审查组长应回答有关检查单和角色分配的问题,并提交诸如最小准备 时间、建议的审查速率和在过去类似产品中发现的典型异常数目之类的审查数据 6.6.4审查产品概述 作者应提交一份有关待审查软件产品的概述 该概述应用于向审查员介绍软件产品 从该陈述中 受益的其他项目成员可以参加概述活动 6.6.5准备 每一个审查组成员均应在审查会前检查软件产品和其他审查输人 在检查期间发现的异常均应形 成文档并提交给审查组长 审查组长应对这些异常进行分类,以便确定是否有必要取消审查会议,从而 有计划地有效利用审查会议时间 一旦审查组长确认异常的程度或严重性足够,可取消审查,并要求当 软件产品达到最小人口准则及合理性的无缺陷状态时再审查 审查组长应将异常提交给软件产品的作 者进行处理 审查组长或者领读者应规定一个适当的顺序(例如,以顺序,分层、数据流、控制流、自底向 上或自顶向下的顺序)来审查软件产品 领读者应确保有充分准备的能在审查会上陈述软件产品 6.6.6检查 6.6.6.1介绍会议 审查组长应介绍审查的参与者并描述他们的角色 审查组长应陈述审查的目的,并提醒审查员应 致力于发现异常,而不是寻求解决异常 审查组长还应提醒审查员把他们的意见直接提供给领读者,并 且只评论软件产品而不评论产品的作者 审查员可以向作者提出有关软件产品的问题 审查组长应解 决审查员提出的任何规程上的问题 有关问题的讨论应放在会议结束后,或者作为一次单独的会议 6.6.6.2作好准备 审查组长应验证审查员是否已经准备就绪 若审查员的准备不够充分,审查组长应重新安排会议 的日程 审查组长应收集每个审查员的准备时间,并在审查文档中记录 13
GB/T32421一2015 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输出 审查输出应为文档化记录,内容包括 已审查的项目: 审查组成员; 审查会的持续时间; 已审查的软件产品; 已审查材料的规模(例如,文本页数); 审查的具体输人; 审查的目标以及这些目标是否得到满足; 异常清单,包括每一个异常的位置、描述和分类;
GB/T32421一2015 软件产品的处置; 任何豁免授权或豁免要求; 审查组个人及全员的准备时间; 总返工时间 审查输出还应包括 按异常分类统计的每类异常数目; 对影响较大的返工的工作量和返工完成日期的估计; 在审查中发现的,已固定项目的预期节省费用与后续标识出的固定项目成本对比 本标准只对文档化证据的内容提出最低要求,有关附加内容、格式和存储介质等方面的要求宜在分 项规程中描述 6.9数据收集和改进 审查的数据收集和过程改进应按照附录C的相关要求进行 走查 -般要求 一次走查可能指出若干缺陷例如,软件产品的效率和可读性问题,在设计或编码中的模块性问题 或者不可测试的规格说明 走查组宜由2名7名成员组成 每个成员可担任多个角色，一个角色也可由多个成员担任 走 查组长或作者可以作为记录员 走查组长也可以是作者 任何走查组成员的管理者均不得参加走查 7.2对象 走查的对象包括(但不限于)如下: 源代码 软件需求规格说明; 软件设计说明 软件测试计划和规程; 软件用户文档 维护手册; 系统开发规程; 安装规程; 发行说明; 授权证书; 软件开发过程描述; 软件架构描述 7.3角色和职责 7.3.1角色 应为走查确定下述角色: 走查组长; 15
GB/T32421一2015 记录员; 作者; 走查组成员 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前提 仅当下述所有条件均成立时才可实施走查 16
GB/T32421一2015 需要实施走查的管理人员建立了走查目标说明 必要的走查输人可用 必要的评价软件产品的标准可用 7.6规程 7.6.1管理准备 管理者或相关走查负责人应确保按照适用标准和规程的要求并根据法律、合同或其他政策的规定 实施走查 总之,管理者应做如下 策划走查所需要的时间和资源; 提供策划、定义、执行和管理走查所必需的资金和设施 提供适用于给定项目的有关走查规程的培训和定向培训 确保走查组成员具备理解待走查软件产品的,适当的专业和知识水平 确保已策划的走查得到实施 及时对走查组的建议采取措施 7.6.2策划走查 走查组长应负责下述活动 标识走查组成员的角色; 为走查组成员分配具体的职责; 安排会议的日程并选择会议场所; 给所有参与者分发必要的输人材料,并为他们留有足够的准备时间 7.6.3概述 作为走查会的一个部分,作者可对走查对象进行概要介绍 7.6.4准备 走查组长应分发软件产品,并主持走查会议 走查组成员应通过检查软件产品并列出要在走查会 上讨论的项目清单,做好参加走查会的准备 应将这些讨论项分为两类;通用的和特定的 通用项适用 于整个产品,特定项适用于产品的某个部分 在走查会开始前,每名走查组成员均应检查软件产品和其 他评审输人 在检查期间发现的异常应形成文档并提交给走查组长 走查组长应对这些异常进行分 类,以确保走查会的时间得到有效的使用 走查组长应将这些异常提交给软件产品的作者进行处理 作者或走查组长应规定一个明确的次序(例如;顺序、分层、数据流、控制流、自底向上的或自顶向下 等)来评价软件产品 7.6.5检查 走查组长应介绍所有参与者并描述他们的角色 走查组长应陈述走查的目的,促进并确保每个成 员都有发言机会以及征求与会者的意见确保每个建议都能被听到 走查组长提醒走查组成员将重点放 在发现异常而不是解决异常上 走查组长应提醒走查组成员只评论软件产品而不评论其作者 走查组 成员可以向作者提出有关软件产品的问题 走查组长应解决走查组成员提出的、有关走查规程的任何 问题 在走查会期间 作者或走查组长应概述待检查软件产品 17
GB/T32421一2015 走查组长应协调有关通用异常的讨论 作者或走查组长应陈述软件产品,说明软件产品的每一个部分 当作者陈述到与异常有关的软件产品部分时,走查组成员应提出具体的异常 走查组长协调并指导走查组对每个异常逐项做出决定或者标识建议和措施 记录员记录所有决定、建议和措施 在走查会后,走查组长应发布详细描述异常,决定、措施和其他相关信息的走查输出 在7.8中给 出了走查输出内容的最低要求 7.6.6返工或后续工作 走查组长或其代表应验证走查会上指定的措施项已经关闭. 7.7出口准则 当满足下述条件时,走查才应视为已完成 7.4描述的目标已达到 已记录了决定、建议和措施， 已完成了走查输出 7.8输出 走查输出应为文档化的记录,内容包括 已走查的项目; 走查组成员; 已走查的软件产品; 在本次走查会期间完成的目标说明,以及这些目标是否已经达到; 异常清单,包括每个异常的定位和描述; 针对每个异常所做出的建议清单 措施、完成日期和责任人的清单 走查组针对如何处理缺陷和未解决异常而提出的所有建议 走查组对后续走查而提出的所有建议 本标准只对文档化证据的内容提出最低要求,有关附加内容、格式和存储介质等方面的要求宜在本 地规程中描述 7.9数据收集和改进 走查的数据收集和改进应按照附录C的相关要求进行 审核 8.1 -般要求 在审核前应首先召开一个预备会,在会上审核员和待审核组织检查并同意审核安排 在制定审核计划时,审核员可能提出一些建议 这些建议应单独报告 审核组宜由1名5名成员组成 主任审核员可以作为记录员 发起人可以作为主任审核员 18
GB/T32421一2015 8.2对象 审核的软件产品对象包括(但不限于)如下 备份和恢复计划; 应急计划 合同 顾客或用户代表的投诉; 容灾计划 硬件性能方案; 安装计划 安装规程; 维护计划 管理评审报告 操作和用户手册; 采购和签约方法; 报告和数据(例如,评审、审核、项目状态、,异常报告、,测试数据); 招标书; 风险管理计划; 软件配置管理计划; 软件设计说明; 源代码; 单元开发文件夹; 软件项目管理计划; 软件质量保证计划; 软件需求规格说明 软件安全性计划 软件测试文档 软件用户文档 软件验证和确认计划; 软件架构描述 标准,规定、,指南、计划、规格说明和规程; 系统开发规程; 技术评审报告 商文档; 走查报告; 可交付介质<例如光盘》. 审核的软件过程对象包括《但不限于)软件开发生存周期过程描述 8.3角色和职责 8.3.1角色 应为审核确定下述角色 主任审核员; 19
GB/T32421一2015 记录员; 审核员; 发起人 被审核组织 主任审核员可以作为记录员 发起人不应该作为主任审核员 候补审核员应被包括在审核组;由 单独一个人的审核也是允许的 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发起人 发起人应负责下述活动 确定审核的需要; 确定审核的目的与范围; 确定待审核的软件产品; 确定评价所使用的规定、标准、指南、计划和规程; 决定实施审核的人员 评审审核报告 确定必要的后续措施; 发布审核报告 发起人既可以是被审核组织的管理者,也可以是被审核组织的顾客或者用户代表,还可以是第三方 2o0
GB/T32421一2015 组织 8.3.2.5被审核组织 被审核组织应为审核员提供一名联络员,并提供审核员需要的所有信息 在审核完成时,被审核组 织应实施纠正措施和建议 8.4输入 在审核计划中应列出审核的输人,并应包括如下 审核的目的和范围; 被审核组织的背景信息 待审核的软件产品或过程; 审核所使用的适用规定、标准,指南、计划,规格说明和规程 “需要改进的”“不可接受的”、“不评定的” 评价准则.例如,“可接受的"、 也可包括以往类似审核的记录 在审核组长要求的情况下,负责软件产品或过程的人员应提供其他的参考材料 8.5入口准则 8.5.1授权 发起人确定审核需要 该决定既可以由某个例行事件(例如,到达项目的某个里程碑)启动,也可以 由某个非例行事件(例如,怀疑或者发现了一个重大不符合项)启动 发起人选择一家能够实施独立评价的审核组织 发起人为审核员提供确定审核目的的信息、待审 核的软件产品或过程和评价准则 发起人应要求审核员提出建议 ，主任审核员完成审核计划,审核员 做好审核准备 可通过下述一个或多个事件确定审核的需要 供方组织决定验证对适用规定、标准,指南、计划,规格说明和规程的符合性(这种决定可能在 策划项目时就已经做出); 顾客组织决定验证对适用规定、标准、指南、计划、规格说明和规程的符合性; 第三方(例如,某个管理机构或评估实体)决定需要审核供方组织,以验证对适用规定、标准、指 南、计划、规格说明和规程的符合性 在每一种情况下,发起人都应对审核进行授权 8.5.2前提 仅当下述条件均成立时才可实施审核 审核已得到发起人的授权; 已建立审核目标说明; 必要的审核输人可用 8.6规程 8.6.1管理准备 管理者应保证审核按照适用标准和规程的要求以及法律,合同或其他政策的强制性要求进行 为 了达到这个目的,管理者应做如下: 策划审核需要的时间和资源,其中包括支持职能、法律或规定文本,或其他适用标准 为策划、定义、实施和管理审核提供必要的资金和设备; 21
GB/T32421一2015 针对适用于特定项目的审核规程,提供培训和定向培训 确保具备相应的专业水平和知识,以便理解待审核的软件产品 确保已策划的审核活动得到实施; 及时对审核组的建议采取措施 8.6.2策划审核 审核计划应描述如下内容 审核的目的和范围; 被审核的组织(包括场地和管理); 待审核的软件产品; 评价准则,包括用于评价的适用规定、标准、指南、计划和规程; 审核员的职责; 检查活动(例如,访谈人员、阅读和评价文档、观察测试等). 审核活动资源需求; 审核活动的进度安排; 保密需求， 检查单; 报告格式; 报告发布 必要的后续活动 当采取抽样技术时,应使用在统计学上有效的抽样方法,以确立选择的准则和样本的大小 审核计 划应得到发起人的批准 审核计划应允许根据在审核期间收集到的信息进行更改,并得到发起人的 批准 8.6.3首次会议 在开始审核的检查阶段时,应召开审核组和被审核组织之间的首次会议 整个会议议程应包括: 审核的目的和范围; 待审核的软件产品或过程; 审核规程和输出 被审核组织对审核的预期贡献(例如,被访谈人数,会议设施; 审核的进度安排; 获得必要的设备、信息和文档 8.6.4准备 除非特殊原因,发起人应在进行审核之前书面通知被审核组织的管理人员 通知应明确审核的目 的和范围,应标识待审核的内容、审核员和审核的进度安排 通报的目的是使被审核组织能够确保在审 核中被检查的人员和材料及时到位 审核员应通过研究下述内容来准备审核 审核计划; 被审核组织; 待审核产品或过程; 用于评价的适用规定、标准、指南、计划、规格说明和规程; 评价准则 22
GB/T32421一2015 主任审核员还应安排如下事项 审核组的培训和定向培训; 用于审核访谈的设施; 审核规程所需要的材料、文档和工具 8.6.5检查 8.6.5.1证据收集 审核员应通过访谈被审核组织的员工、检查文档和见证过程的形式,收集符合与否的证据 审核员 应尝试在审核计划中定义的所有检查活动 如果审核员认为需要进行某些额外的调查活动来确定符合 性或不符合性的程度,那么,他们应承担这些额外的调查活动 审核员应将不符合性的所有观察和符合性示例形成文档 观察是在审核期间作出的事实陈述,且 该事实由某个客观证据所证实 -致性的示例包括如下 根本不使用适用的规定、标准、指南、计划、规格说明和规程; 未正确地使用适用的规定、标准、指南、计划、规格说明和规程 观察应分类为主要的或者次要的 如果不符合性可能对产品质量、项目成本或者项目进度产生重 大影响,则该观察应被分类为主要的(主要观察通常被称为“发现” 在末次审核会议召开之前,所有观察均应同被审核组织进行讨论以得到核实 8.6.5.2末次会议 主任审核员应召集被审核组织的管理人员参加末次会议 未次会议应评审如下 审核计划的实际实施情况; 实施审核计划过程中经历的所有问题 审核员作出的观察; 审核员的初步结论; 审核员的初步建议; 全面的审核评估例如,被审核组织是否成功通过审核准则 应解决被审核组织提出的解释和问题 在末次审核会议期间应达成协议,在审核报告定稿之前须 达成一致 8.6.5.3报告 主任审核员应按8.8的要求编制审核报告 审核报告应在审核后尽快编制完成 在末次审核会议 和发布报告期间,审核员和被审核组织间进行的交流和报告的争议都应通过主任审核员 主任审核员 应向发起人和被审核组织提交审核报告 发起人应在被审核组织中发布审核报告 8.6.5.4返工或后续工作 若存在返工,则返工应由发起人和被审核组织负责,并应包括如下 决定采用必要的纠正措施,以便消除或者防止某种不符合性 启动纠正措施 出口准则 在满足下列条件时应视为审核已完成 审核报告已提交给发起人; 23
GB/T32421一2015 在审核范围内审核组织的所有后续活动发现都已得到处理或解决和批准关闭执行、评审和 批准 8.8输出 审核的输出是审核报告 审核报告应包括如下内容 审核的目的和范围; 被审核组织,其中包括场所、联络员和管理人员; 已审核软件产品或过程的标识 用于评价的适用规定、标准、指南、计划、规格说明和规程; 评价准则; 审核员的组织的概况 检查活动概况 未执行的计划内检查活动的概况; 已按主次分类的观察清单; 审核发现(包括关键的不符合项)的概况和解释; 审核后续活动的类型和时间安排 此外,在审核计划有规定时,应给被审核组织和发起人提供建议 建议可以与审核结果分开报告 本标准只对文档化证据的内容提出最低要求,有关附加内容、格式和存储介质等方面的要求宜在分项规 程中描述 关于管理评审、技术评审、审查、走查和审核这五种评审类型的比较参见附录B 24
GB/T32421一2015 附 录A 资料性附录 软件异常分类示例 A.1逻辑问题 逻辑问题可分为 a)遗忘的情况或步骤; D 重复逻辑 e)不必要的功能 d)错误解释 遗漏条件测试 检查错误的变量; 不正确的循环: 不正确的循环初值; 2) 不正确的循环终止条件; 3 不正确的循环计数; 循环永不终止 4 A.2计算问题 计算问题可分为 等式不充分或不正确: a 缺少计算; 2 等式中的操作符不正确; 等式中的操作数不正确 3) 4括号的使用不正确; 5) 除数为零 对负数求平方根 6 b精度问题 舍人进位或截断进位问题 1) 2) 混合运算问题 3) 符号约定故障; 4) 定点比例尺选择不当 5 常数有效位不够 A.3接口或定时问题 接口或定时问题可分为 中断处理不正确 a 1未对必要的数据或寄存器进行保护; 25

软件工程软件评审与审核GB/T32421-2015解析

GB/T32421-2015《软件工程 软件评审与审核》（以下简称GB/T32421）是由中国国家标准化委员会发布的一项标准，旨在规范软件评审和审核的过程，提高软件质量和开发效率。

一、概述

软件评审是指对软件需求、设计、编码、测试等方面进行检查和审查的过程，目的是发现和纠正软件中存在的缺陷和问题。软件审核是指对已经完成的软件进行审核和确认的过程，目的是确保软件符合用户需求和规格要求。

二、软件评审

GB/T32421规定了软件评审的基本步骤和流程，并明确了各个参与者的职责和任务。其中，软件评审包括了需求评审、设计评审、代码评审、测试评审等环节。评审人员需要根据相应的评审标准和规则进行评审，并及时记录和反馈评审结果。

三、软件审核

GB/T32421规定了软件审核的基本要求和流程，并明确了审核人员的职责和任务。软件审核包括了软件开发过程中的各个阶段，如需求确认、设计审核、编码审核、测试确认等环节。审核人员需要对软件进行全面的检查和确认，确保软件符合用户需求和规格要求。

四、软件评审与审核的关系

软件评审和审核在软件开发过程中都起着至关重要的作用。评审主要是在软件开发的过程中进行缺陷和问题的发现和纠正，而审核则是在软件开发完成后对软件进行全面的确认和确认。

五、总结

GB/T32421规范了软件评审和审核的流程和方法，为软件工程的开发提供了标准化的支持。在实际应用中，我们应该根据具体情况选择适合的评审和审核方式，并遵循相应的标准和规则，以提高软件质量和开发效率。

软件工程软件评审与审核的相关资料

和软件工程软件评审与审核类似的标准