软件咨询及其提供质量管理体系专业审核作业指导书.doc

软件咨询及其提供质量管理体系专业审核作业指导书（完整版）实用资料
(可以直接使用，可编辑 完整版实用资料，欢迎下载）
质量管理体系专业审核作业指导书

Direction for Audit of Quality Management System
————————————————————————————————————————
软件咨询及其提供
质量管理体系专业审核作业指导书
编号:ZY -Q-84F 修改状态:0
中鉴认证有限责任公司
GZCC
Ę
目录
1.范围: (2
2.引用文件 (2
3.定义: (2
4.产品/服务范围、特点与专业代码: (3
5.业务/服务流程: (8
6.关键质量活动: (9
7.审核要点和审核方法: (10
8.法规与技术标准/规范要求的检查方法: (24
Ę
前言
编制本作业指导书的目的是:结合的产品特点,指导专业审核员根据GB/T19001-2000 idt ISO9001:2000标准和软件提供及其咨询行业的特定要求,对软件咨询及其提供行业的质量管理体系实施现场审核,判定其是否符合ISO90001
:2000质量管理体系要求,并满足顾客和适用法规的要求,而达到顾客满意。
ZY-Q-01F质量管理体系审核作业指导书(通用为各种类型组织的质量管理体系认证审核提供了指南.本作业指导书是对《软件咨询及其提供》、《其他企与计算计有关的活动》企业实施质量管理体系认证审核提供了专业性指南,以确保审核的一致性和有效性.
附录A 相关法律法规;
附录B 相关技术标准
附录C 软件提供及其咨询产品标准
编制:陈顺萍
审核:范建平
批准:胡苏山Ę
1.适用范围:
1.1 本审核指导书提出了软件企业按照GB/T19001:2000-USO9001:2000标
准建立的质量体系审核的要点;
1.2 适用;软件开发及咨询(与计算有关的其它活动专业参照实行;
2.引用文件
GB/T19000-2000 idt ISO9000:2000 《质量管理体系―基础和术语》
GB/T19001-2000 idt ISO9001:2000 《质量管理体系-要求》
GB/T19004-2000 idt ISO9004:2000 《质量管理体系—业绩改进指南》GB/T19011-2003 idt ISO19011:2000 《质量与环境审核指南》
3. 定义
以下引自GB/T8566—2001 idt ISO/IEC12207—2001 信息技术―《软件生存周期过程》
3.1软件产品
一组计算机程序、规程以及可能的相关文档和数据。
3.2软件项
在开发中间阶段或最后阶段的软件产品中的任何可标识的部分。
3.3软件服务
Ę
实施与软件产品有关的活动、工作或义务,比如软件开发、维护和运作。
3.4软件单元
一段可分开编译的代码。
3.5供方
与需方签订合同,并按合同规定提供系统、软件产品或软件服务的组织。
3.6需方
从供方获得或采购系统、软件产品或软件服务的组织。
3.7开发者
在软件生存周期过中执行开发活动(包括需求分析、软件、测试直到验收的一个组织。
3.8维护者
执行维护活动的组织
3.9用户
使用运行系统完成一项特定功能的个人或组织。
注:用户可以扮演其它角色,比如需方、开发者或维护者。
3.10版本
某一配置项的己标识了的实例。
3.11获取
取得系统、软件产品或软件服务的过程。
3.12基线
在配置项的生存周期内的某一特定时刻已正式软件并固定了的且经正式批淮的配置项的一个版本,而不管媒体是什么。
3.13配置项
一个配置中的实体,它满足一项最终使用功能,并能在给定的基准点上单独标识。
3.14退役
运作和维护组织撤出现有的支持,部分或全部由一个新的系统代替或者安装一个升级系统。
4.产品/服务范围、特点与专业代码
4.1产品范围: 软件提供及其咨询. (其它与计算机有关的活动参照执行 4.2产品特点:
4.2.1软件是与计算机系统的操作有关的程序、规程、规则及任何与之有关的
文档.
Ę
《程序》是按“按具体要求产生的、适合计算机处理的指令序列”。
《规程》是“为解决某一问题而采取的动作的经过的描述”或“每次完成某一任务时要遵循的一组手工的步骤”,主要描述在软件生存周期中应如何实施有关政策、规则和标准.如测试规程,用于描述进行软件测试时应遵循的测试步骤。
《规则》指软件开发人员在开发软件时应共同遵守的准则和法规。
《文档》指一种数据媒体及其记录的数据。
4.2.2从软件的组织结构来看,软件是一个由计算机配置项(软件配置项、计算机软件部件(CSC和计算机软件单元(CSC构成的层次结构.
《计算机软件配置项》是为独立的配置管理而软件的、且能满足最终用户功能的一组软件.
《计算机软件部件》是”软件配置项”中的一个明确部分.它可以进一步分解成其他计算机软件部件和计算机软件单元.
《计算机软件单元》是计算机软件部件软件中确定的、且能单独测试的部分.
4.2.3软件作为一种逻辑实体,具备以下几个显著的特点:
1 抽象性:软件产品不是实物产品,其可见性差。
2 严密性:软件工程是一个严密的逻辑工程.软件产品无正品和次品之分,
不存在误差,
误差即错误。
3 “一次性”:任何软研制都是一个新的开发过程,即一次性“创造性”
的劳动.而软件的成
批生产只不过是简单的复制。
4 “智力性”:软件研制主要靠人的脑力劳.动。
5 “持久性”:软件产品的质量与使用时间的长短无关,即软件产品无磨
损性.因此软件
的故障不能用普通产品更换零部件的方法来解决。
6 “依赖性”:软件产品常受限于具体的计算机系统,为了减少软件产品
对计算机系统
的依赖性,应提高软件产品的可移植性。
7 “复杂性”:有人认为,计算机软件是人类能够创造的最复杂的产品之
一,软件的复
杂性既来自它所处理的实际问题的复杂性,又来自程序逻辑结构本身的复杂性。
因此,软件技术的发展落后于人们对软件的需求,并且随着时间的推移,这种
Ę
差距还在日益加大。
8“难以度量”:目前对智力劳动尚无有效的度量方法,而软件研制又是新
开发的智力
产业,对软件开发的人力、物力投入无法精确估计,往往造成大量的超出预算的情况。
9“易出错”:软件开发过程涉及一系列的“信息转移”,在有信息转移的
环节都有可
能发生信息转移的错误。
10“必须维护”:软件产品在交付使用后还可能需要经常更改,因而软件
维护是软件
工程的一个必不可少的阶段。
11“成本昂贵”软件产品的研制需要投入大量的、复杂的、高强度的脑力
劳动,其成
本是非常高的在国外,软件己占整个计算机系统成本70%以上。
4.2.4软件质量特牲
在GB/T 16260—1996 idt ISO/IEC 9126:1991 信息技术―《〈软件
产品评价质量特性及其使用指南》中定义了6个软件质量特性和21个子特性.

4.2.5 a
软件业和硬件制造业产品实现控制过程的比较

b
软件与硬件在制做过程中的区别
软
件
硬
件
(1 软件是逻辑实体,它不会老化,只是其载体可变化.
(1硬件是物理实体,每件相同规格的产品在限定的误差范围内变化;随时间变化而老化、磨损以至失效.
(2 别作过程主要是脑力劳动,是无形产品,难以测量控制.
(2别做过程是脑力和体力过程相结合,有物理实体产品.
(3产品不可靠性主要是由于人为差错造成的. (3人员、没备、原材料、作业指导书、生产环
境(4M1E等方面都会对产品可靠性产生影响. (4程序是指令序列,即使每条指令本身都正确,但在执行时有各种逻辑组合,结果往往不一
定完全正确.
(4硬件故障基本都上是由于其零部件及它们的结合问题引起的.
(5软件系统的数学模型是离散型的,其输入在合理的范围内的微小变化可能引起输出的巨大变化.故障的形成没有物理原因,失效的发生取决于输入值和运行状态组合,没有前兆. (5硬件系统在正常工作条件下其行为是渐芄的,故障的形成和失效的发生一般有物理原因,有前兆性.
c 软件产品与硬件产品在可靠性和可维护性方面的区别软件硬件
(1在软件开发的全过程应加强质量控制,采取措施防错、改错,而在批量复制时软件本身一般不会再变化(除非有病毒侵入. (1硬件产品实现的全过程都可能产生错误,包括软件开发、原材料、生产、贮存交付.
(2精心设汁测试输入条件,严格检测所有内
容、排除错误,降低可靠性.
(2按照检捡规范全数或抽样检验.
(3采取冗余软件时,尽量保证冗余软件之间的高度独立性,否则只仅不会提高可靠性,还会增加复杂性,降低可靠性. (3相同的部件之间是独立的,其适当的冗余可提高可靠性.
(4使用过程中出现故障,必须修改产品以解决问题;如修改时没有产生新的问题,则产品的可靠性会提高. (4使用过程中出现故障后,可采取返工、返修或更换失效零部件,以恢复合格状态,一般可靠性与原来相同.
(5软件的某处修改会影响程序的其它部分,
有头“牵一发而动全身”的影响,维护时
必须考虑这种波及面,保证整体一致.
(5维修某一处,一般不会影响产品的其他部分.
(6失效率随故障的排除而下降. (6实效率变化类似“浴盆曲线”,使用中经维修后故障率下降,但随着产品的老化、磨损,故障率又渐次上升.
(7可靠性参数的估计没有物理基础. (7可靠性参数的估计有物理基础.
4.3主要顾客群: 直接顾客经销商、批发商;
中间顾客软件销售点、电脑市场;
最终顾客使用软件的组织、个人.
4.4专业代码: 大类中类小类

Ę
5.业务/服务流程软件开发流程

6 关键质量活动
软件开发的关键活动为软件需求分析、软件开发策划及各阶段的验证、评审、确认、更改活动的控制。
软件需求分析:
是要把软件功能和性能的要求描述为具体的软件需求规格说明,从而奠定软件开发基础.然而软件需求分析是一个不断认识和逐步细化的过程,软件分析深入描述软件的功能和性能,确定软件软件的限制和软件同其他系统组成部分的接口细节,形成软件需求规格说明.参考
GB/T9385—1988《计算机软件需求说明编制指南》《软件需求规格说明》。
软件开发策划:
GB/T19001:2000标准7.3.1条款要求组织应策划和控制至少包确定括以下3项要求:
a 开发阶段;
b 适合于每个软件和开发阶段的评审、验证、确认活动;
c 开发的职责和权限。
组织还应对参与开发的不同小组之间的接口进行管理,以确保有效管理,以确保有效
的沟通,并明确分工。
随着开发的进展,在适当时,策划的输出应予更新.参考GB/T9385—1988《计算机软件需求说明编制指南》《软件开发计划》。
软件开发的输入:
软件开发的输入应包括以下内容:
Ę
a产品主要功能、性能要求.这些要求主要来自用户或市场的需求和期望,一般应包
含在合同或项目可行性研究报告中;
b适用的法律、法规要求,对国家强制性标准一定要满足;
c以前类似设计提供的适用信息;
d对确定产品的安全性和适用性至关重要的特性要求,包括安全、维护及使用环境等.
软件井发的输入应形成文件,项目开发人员应编制《软件需求说明书》、《数据要求说明书》、《规则、惯例和约定》等。
软件开发的输出:
软件开发输出应以能针对软件开发输入进行验证的形式来表达,以使于证明满足输入要求,.
软件开发输出因产品不同而不同,除开发编制的应用软件外,还应根据产品特点规定对安全和正常使用至关重要的产品特性,包括安装、使用、维护等的要求.适当时期输出文件包括;《概要设计说明书》、《详细设计说明书》、《数据库设计说明书》、《模块开发宗卷》、《测试计划》、《用户手册》、《操作手册》、《维护手册》、《培训手册》等。
软件开发的评审:
应按开发策划要求在软件开发的适当阶段应进行系统的、综合的评审,填写《软件开发评
审报告》,评审结果和根据需要采取的相应改进或纠正措施,要予以记录,并跟踪记录措施的执行情况。
软件开发的验证:
应按开发策划要求在软件开发开发的适当阶段计对软件开发进行验证,并编制《测试计划》,并填写《测试分析报告》,把单元测试和系统测试的结果、发现及分析形成文件予以记录.其内容包括:测试概要、测试结果及发现、对阶段软件功能的结论,分析摘要、测试资源消耗等.确保软件开发输入中每一项性能、功能指标都有相应的验证记录,达不到预定的软件开发需求时,根据需要采取相应的改进或纠正措施,并跟踪记录措施的执行情况。
软件开发的确认:
确认的目的是证明产品能够满足规定的使用要求和巳知的预期用途要求.通常应在产品
交付之前(如单件产品或产品实施(如批量产品之前完成,应尽可能地在类似于合同规定的使用环境下对整个产品的运行进行确认.如需经用户使用一段时间才能完成确认工作的,应在可能的适用范围内实现局部确认,确认结果及任何必要措施应予以记录,确认完成应提交《软件确认报告》。
软件开发更改的控制:
软件开发的更改可发生在软件生存期的任何阶段.开发人员应正确识别和评估软件更改
对对软件使用性能、安全性、可靠性等方面带来的影响.
当更改涉及到主要技术参数和功能、性能指标的改变,或人身安全及相关法律法规要求时,应对更改进行适当的评审、验证和确认。
7 审核要点与审核方法
序号主要过程的关键
质量活动
对应标准
条款
通常涉及的职能
部门、单位
审核要点及取证方法
1 l 建筑物和设
施的布局;
6.3基础
设施
管理层、
技术开发部门
专用计算机房
审核要点:
1.软件开发者所使用建筑物主要是工作室和
专用计算机房.
2.开发用的硬件为个人计算机(含外围设备、
刻录机、烧录机和网络设备(交换机、服
务器等。
3.开发用的软件有各种软件,可分为三大类:
a 系统软件;
b 支持性软件;
c 应用软件.
4.软件开发使用到的各种开发平台、编程语
言和工具.
取证方法:
1识别并满足软件开发运作所必须的设施、
硬、软件,一般情况下与网络有关的硬件故
障率较低,即是出现故障,致件;
2特别关注软件系统防火墙是否有效、杀毒
软件是否符合要求,并按规定运行.
3现场观察设施、硬、软件运行的完好程度
以及是否满足各方面要求.
Ę
2 l 工作室和专
用计算机房
的工作环境;6.4工作
环境
管理层、
技术开发部门
计算机房
审核要点:
1. 用于开发用的软件工作室的一般要求:
a 清洁;
b 无尘;
c 空调环境,确保适宜温度.
2. 专用计算机房
专用计算机房对环境要求较高
a 清洁度要求:无尘,人员进入机房要
换鞋、必要时更衣.
b 全封闭空调房,一般:
恒温(23℃±2℃
恒湿(65%±5%左右或遵守行业规定.
3. l 质量策划7.1产品
实现的策
划管理层、
技术开发部门
审核要点:
a 是否对产品的实现过程进行识别、确
定、策划并形成文件?是否配备了必要的资
源?
b没有形成文件的过程和活动如何实施?
如何控制?
c是否明确相应验证和确认活动以及验证
准则?
d是否明确所必需的质量记录,以证明过
程和相应结果合格?
e针对特定产品、项目或合约是否进行策
划并形成质量计划?
f必要的法律、法规及其更新?
取证方法:
1 本条款的取证主要依据7.2、7.3、7.4
7.5、7.6、8.2.4、条款审核结果得出结论.
2 需要指出的是:
在软件行业里7.5.1的过程主要涉及
到软件的多媒体加工复制过程(此过程即
33.02.01软件的出版小类和7.5.1f 软件
产品的交付及交付后服务(软件维护的话动
证据;
软件产品是可以通过过程的输出结果的

条款是合理的.
7.5.3条款在软件产品里应查阅复杂、
大、中型软件应有配置管理活动, 简单、
小型软件则以版本/修改状态表示.
Ę
4 l 相关法规、标
准的收集、评
价、识别与产
品有关的法
规要求;
l 顾客要求识
别、确定
7.2.1与
产品有关
的要求的
确定
业务部门
技术开发部门
审核要点:
a 软件产品相关法规,标准的收集、评价
并执行,见对录A/B;
b 顾客的要求包括软件需求的组织(上
级部门、批发商、零售商、和广大消费者的
要求,软件顾客在许多情况下是提不出对软
件明确的功能、性能需求的, 通常的做法是
由供方(含开发者 在经过需求分析和需求
评审后,形成《需求分析报告》.
c 顾客没有明确的要求,但预期或规定
的必要要求,如软件系统防火墙设置是否有
效、杀毒软件是否符合要求等.
取证方法:
1顾客明示的要求是否明确,抽查有关招
标书、协议书、合同(上级部门的合同及
要货通知(含口头、 、 记录;
2法律法规、地方软件产品管理部门的政
策是否明确,工作人员是否清楚,有关文件
是否齐全;
3顾客没有明确要求,但预期或规定的必
要要求,如软件系统防火墙设置是否有效、
杀毒软件是否符合要求等,是否明确.
4组织自己和顾客提出的附加要求是否明
确.
Ę
5 l 在宣传产品之
前的评审
l 合同评审
l 合同变更的评
审及采取的措

与产品有
关的要求
评审
业务部门、技术部
门、管理层
审核要点:
a企业对顾客、社会作出公开承诺
(如产品说明书、网上销售报单前,
应进行评审;
b签订销售合同之前应进行评审,评
审方式可根据实际运作和合同情况而
确定;
c评审的内容:《公开承诺》和《合
同草案》中的要求组织是否有能力实
现;签订合同时,顾客的要求能否满足;
评审的结果及所引起的措施应记录并
落实;
d 当顾客要求发生变更,或公开承
诺变更时,应能传递到相关人员。
取证方法:
1是否在对市场、社会、顾客做出
《公开承诺、网上销售报单》之前进行
评审;查记录;
2签订合同或接受订单元前是否进
行评审,一般软件产品还会有招、投标
活动,应对顾客招标书、组织自己的投
标书、及最终顾客中标书进行评审,应
查验以上有关活动多次评审的记录;
3评审结果及引起的措施是否落实,必要
时检查合同台帐,工作进度监控、出货记录等;
4当承诺或顾客要求发生变更时,是否对
没有形成文件(如口头、 、 、E-MAIL、
网上销售的顾客要求,组织是否在接收顾客
要求前进行确认,并存了相关记录。
6 l 与供方沟通
l 顾客的沟通
l 必要时与主管
部门的沟通,
间接了解顾客
要求,投诉和
抱怨
7.2.3顾
客沟通
业务部门审核要点:
a内、外部沟通至关重要,特别对沟通的
渠道、内容、方法应明确规定,如:供方和分
包商信息、产品信息、问询、合同处理、顾客
意见反馈信息等;
b顾客反馈的信息应及时收集、处理;
取证方法:
1是否明确了与顾客(包括直接顾客、间
接顾客、最终顾客沟通的渠道、内容、方式
等,沟通是否有效;
2顾客反馈的信息是否得到及时处理,效
果如何;
3通过顾客投诉/建议等,查处理结果;
4类似的顾客投诉、抱怨是否重复发生. Ę
7 软件开发7.3.1软
件开发的
策划管理层
技术开发部
审核要点:
a组织是否对产品的软件开发进策划,如何
策划?
b是否对软件开发组别之间、部门之间、技
术包括与外部的接口进行管理确保有效沟通
和明确责任?
c软件开发过程的各个阶段是否明确、软件
的适当阶段的评审,验证,确认,活动的确认?
d软件开发活动的人员责任和权限是否明
确?
e在软件开发的进展中是否对软件策划进
行及时的更新?
取证方法:
1是否明确产品开发活动的任务、职责和要
求;
2是否明确了沟通的方式;
3是否有效地控制了软件开发的全过程.
4软件开发周期与软件规模大小有关,但均
应查阅《软件开发计划》并在计划中含以下内
容:
a开发阶段;
b适合于每个软件和开发阶段的评审、验
证、确认活动;
c开发的职责和权限.
5 软件开发策划需由有经验的高层管理者进
行, 我国软件开发工作落后于市场需求, 且
目前软件行业中此类成熟管理者不多, 企业
《软件开发计划》中不能明晰含盖4 中的全
部要求, 审核和记录中要重点关注.
l 产品标准法规要求
l 市场要求
l 顾客的需求
7.3.2软
件开发的
输入
审核要点:
应明确与产品有关的输入,包括:
a 产品接收准则,功能和性能要求;软件开
发的输入要求是否明确,是否有文件的形式?
b 以前类似的开发的信息(如同类软件
等;
c 产品相关的法律法规要求;
d 其他必需的要求.
e 是否对输入的适当性进行了评审,不完
整、含糊或矛盾的要求是否得到了解决?
取证方法:
1查验产品开发输入的信息《软件需求说
明书》、《数据要求说明书》、《规则、惯例和约
定》等是否明确。
2是否明确了产品接收准则和其他要求.
3 输入评审记录及必要时可查软件输入
清单。
Ę
l 满足标准要求l 市场要求
l 顾客的需求7.3.3软
件开发输
出
审核要点:
软件开发输出应以能针对软件开发输入
进行验证的形式来表达,以使于证明满足输入
要求.
a软件开发输出满足输入要求,包含和引用
产品接收准则;
b给出采购、生产和服务的适当信息,包括
安装、使用、维护等的要求.;
c规定对安全和正常使用至关重要的产品
特性.
取证方法
1查阅输出文件,适当时,可包括;
《概要设计说明书》
《详细设计说明书》
《数据库设计说明书》
《模块开发宗卷》
《测试计划》
《用户手册》
《操作手册》
《维护手册》
《培训手册》等.
2 软件开发输出, 多用电子文件存贮,由
必要时, 直接查阅电子文档.
l 不同阶段的评审
l 评审方式灵活,多样(会议
或会签
7.3.4软
件开发评
审
审核要点:
软件产品的评审应:
是否按开发策划要求在适当的阶段对软件
开发进行系统评审,以保证:
a评估满足要求的能力;
b识别问题及建议解决的方案.
c参与评审的部门是否包括被评审软件和/
或开发阶段有关的职能部门的代表?
e评审的结果和之后的跟进措施是否有记
录?
取证方法:
1 查阅《软件开发评审报告》关注评审
的内容是否完整、系统.
2 查阅评审结果、结论.
3 有修改要求时,根据需要采取的相应
改进或纠正措施,并跟踪记录措施的执行情
况, 查阅相关记录,
Ę
验证方式
l 单元测试(可在工作室
l 系统测试(多在现场, 与顾
吝硬件系统联
调
7.3.5软
件开发验
证
审核要点:
验证是为了确保开发输出能满足输入的
要求,软件开发的验证应包括:
a应按开发策划要求在软件开发开发的适
当阶段计对软件开发进行验证;
b识别问题并提出必要措施;
取证方法:
1查阅《测试计划》;
2查阅《测试分析报告》其内容包括;
有无把单元测试和系统测试的结果、发现
及分析形成文件予以记录;
3当达不到预定的软件开发需求时,根据
需要采取相应的改进或纠正措施,并跟踪记录
措施的执行情况。
Ę
l 可通过顾客进行确认
l 内、外(含权威机构鉴定会
方式7.3.6软
件开发确
认
审核要点:
a 应按应按开发策划要求对软件开发进行
确认,确认应确得软件产品能够满足规定的使
用要求和己知的预期用途的要求;
b如何进行软件开发确认,是否在交付或实
现产品前完成确认,如果不能完全完成确认时
是否最大程度实施部分确认;
c软件和/或开发确认的结果及之后的跟进
措施是否有记录。
取证方法:
1是否按策划的安排进行确认后产品才实
施;
2确认的方式、内容、人员及其职责是否
明确;
3确认结果如何,是否提出必要措施.
4通常应在产品交付之前(如单件产品
或产品实施(如批量产品之前完成,应
尽可能地在类似于合同规定的使用环境下对
整个产品的运行进行确认.如需经用户使用一
段时间才能完成确认工作的,应在可能的适用
范围内实现局部确认,确认结果及任何必要措
施应予以记录,确认完成是否提交《软件确认
报告》;
5 在某些情况下, 可以将确认、现场测试
和验收测试合为一个活动, 验证和确认记录
也可在一起进行。
7
l 软件变更的确认,方式可灵
活
7.3.7软
件开发更
改的控制
审核要点:
a软件开发的更改可发生在软件生存期的
任何阶段.开发人员应正确识别和评估软件更
改对对软件使用性能、安全性、可靠性等方面
带来的影响;
b当更改涉及到主要技术参数和功能、性能
指标的改变,或人身安全及相关法律法规要求
时,应对更改进行适当的评审、验证和确认。
取证方法:
1对软件在各阶段要求的更改查验有无按
P-D-C-A循环方法予以处理;
2 检查更改全过程记录是否完整,包括需
要进行适当的评审、验证和确认的证据。Ę
l 软件开发工具软件采购
l 与软件开发有关的硬件采购l 分包方确定
l 供方和分包方评价7.4采购

采购过程
采购部门审核要点:
为确保采购产品、分包服务符合规定要求应:
a是否对采购、分包服务过程进行控制,确
保采购产品、分包服务符合要求,如何控制,
控制的方式和程度如何确定;
b是否根据提供符合组织产品要求的能力
来评估和选择供方、分包方;
c是否制定选择、评价和重新评价的标准;
d评估结果及之后的跟进措施是否有记录。
取证方法:
1选择、评价供方的准则;
2供方、分包方评价结果和跟踪措施记录

采购信息
审核要点:
a是否有包括描述采购产品、分包要求的资
料;
b采购文件是否包括:
批准和认可的要求;
产品、程序、过程、设备、人员等要求
质量管理体系的各项要求;
c采购文件发出前是否确保所包含规定要
求适当后才予以发出。
审核证据:
采购信息记录《采购申请单》、《分包协议/
合同》及批准的证据。
8
l 硬、软件及分包服务质量验
证/检验

采购产品
的验证
审核要点:
a是否对采购产品的验证的所必须的活动
加以识别;
b是否实施验证活动;
c当顾客或组织到供方货源处进行验证活
动时是否在采购资料中做出明确规定包括验
证的产品放行方法。
审核证据:
1采购硬、软件产品及分包服务质量验证/
检验的记录(通常在8.2.4条款进货、分包验
证/检验记录具体描述 。
2询问有无当顾客或组织到供方货源处进
行验证活动,若有,查捡是否在采购资料中做
出明确规定包括验证的产品放行方法。Ę

9 标识和可追溯性
l 配置管理
l 可追溯性
7.5.3 管埋层
技术开发部
生产部门
审核要点:
一. 审查配置管理系统:
a 唯一性标识每个软件项的正式版本;
b 标识构成一个特定版本的完整产品的各
软件项的版本;
c 标识在开发、交付及安装中的软件产品
的状态;
d 控制由一个以上的程序员同时对同一软
件项进行的更新;
e 对多个产品一处或多处的更新进行协
调;
f 确定和追踪由一个更改申请而引起的所
有措施和更改, 包括从开始到释放的全过程。
二. 审查配置管理计划
a 有关的机构及其职责;
b 配置管理活动;
c 使用的工具、技术和方法;
d 将各配置项置于配置之下的相应阶段。
三. 配置项管理活动
1.配置标识和追踪
组织应建立和维护从编制规格说明到开发、
复制和交付所有阶段中标识软件项的规程。如
果合同要求, 这些规程还可在产品交付之后
使用。每个软件项都应有唯一的标识。这些规
程应能保证对软件项的每一版本标识下列内
容:
a 功能和技术规格说明;
b 影响功能和技术规格说明的所有开发工
具;
c 与其他软件项和硬件的所有接口;
d 与软件项有关的所有文档和计算机文
件;
软件项的标识应能表明软件项与合同要求
关系。对所释放的产品应制定便于追踪软件项
或产品的规程。
2.更改的控制
在对配置管理下的软件项, 组织应制定对
更改的标识、记录、评审和批准的规程。软件

条款要求。
3.配置状态报告
对软件项的状态、更改申请和以批准更改
的实现情况, 但织织应制定记录、管理和报告
的规程识并遵照执行。
取证方法:
1软件配置项的管理是一个十份重要的工
作, 在大、中型复杂软件更是必不可少。审核
时首先要查阅软件标识、记录、评审和批准及
更改控制的规程。按规程要求查阅相关记录;
2 在小型和简单软件开发中一般以版本和Ę

顾客财产
业务部
生产技术部
审核要点:
a 客户财产主是否由顾客供的安装环境图
纸(保密资料等及与顾客产品有关的工作现
场环境。
b是否对组织使用的或组合产品中的客户
财产予以标识、验证、保护和维护;
c任何客户财产出现损失/损坏或发现不适
用时应予以记录并报告客户。
取证方法:
1顾容财产清单或标识及验证记录;
2保护和维护的证实信息,如与安装人员的
交谈对顾客财产防护要求等;
3丢失、损坏或不适用时向顾容报告的记
录。

产品防护
软件复制工作室
成品仓库
审核要点:
对CD-ROM固化模块烧录和复制软件的光盘
有包装、防护要求, 主要对产品加工全过程直
到交付到目的地。在运输、储存环境中有不得
碰撞、强烈震动、防潮、防火的要求。
取证方法:
1查看实物产品包装方式和包装质量;
2查看原料、半成品、成品仓库产品防护是
否良好, 具备防潮、防火功能。
l 软件测试工具7.6监视
和测量装
置的控制技术开发部审核要点:
a是否识别使用了作为软件进行监视和测
量工具;
b测试软件在初次使用前要进行确认, 必
要时再确认。
取证方法:
1查有哪些测试用软件,有无清单;
2测试软件初次使用前是否进行确认, 有
无必要时再确认的需求, 如有,抽查再确认;
3当发现测试软件无效时,如何处理。
l 软件开发全过程的监控

过程的监
视和测量
生产技术部审核要求:
a 软件开发全过程的文档的编制是对软件
开发全过程的监控有效手段。
b 软件开发过程发生任何更改按7.3.7条
款严格控制。.
取证方法:
1查看相关文档是否齐全。
2 查看开发更改过程是否有效。
Ę
12 l 软件产品监视
和测量
l 软件复制后多
媒体产品的监
视和测量

产品的监
视和测量
生产技术部
生产车间
审核要点:
a产品的监视和测量应包含包括软件产品
分包方的监视和测量和软件复制后多媒体产
品的监视和测量;
b 软件检捡依据主要是《软件需求说明
书》、《数据要求说明书》,测试方法策划是《测
试计划》,测试结果是《测试分析报告》;
c 分包方监视和测量依据《分包协议/合
同》进行监视和测量;
d 复制软件产品监视和测量依据《软件复
制检验规程》进行监视和测量。
取证方法:
1进厂检验:主要依据《软件复制检验规
程》对CD-ROM原料、光盘原料验收。抽查其
抽样策划、进货要求与实施结果的符合性;
2 查对分包方提供验牧依据《分包协议/
合同》和相关于验收记录;
3 对软件产品监视和测量详见7.3.5条款
记录, 推向市场直接面对客户的产品还应提
供产品合格证。
13 l 原辅料不合格
l 半成品不合格
l 收/退回产品
的不合格
8.3
不合格品
控制
技术开发部
生产车间
审核要点:
a应规定不合格品控制,处置的职责权限;
b对不合格品进行标识(如盖章、隔离;
c处置不合格品的措施:
l 对复制软件产品和分包方不合格控制要
求有:
1 进厂检验发现原、辅料不合格应记录,
并退货;
2 生产过程中发现的不合格品,根据其严
重程度确定是否可接受;
3 成品不合格或过期产品,是否规定处置
方法,并查处理记录;
4 收/退回产品的处理.
l 对软件不合格产品应记录, 并返工, 直
到测试通过。
取证方法:
1是否规定了不合格控制、处理的职责和
权限;
2是否对不合格品采取了隔离、标识等措
施;
3是否规定不同情况下不合格品的处置方
法;
4查相关记录。
Ę
8． 法 规 与 技 术 标 准 /规 范 要 求 的 检 查 方 法 ： 8.1 是否识别并确定了有关的法律法规、标准并确保其有效版本； 8.2 是否严格执行有关法律法规、国家标准的规定. 8.3 相关法律法规、标准： l 《中华人民共和国产品质量法》 ； l 《互联网文化管理暂行规定》 l 《中国互联网行业自律公约》 2003.05.10 2004.06.21 文化部令第 27 号发布 中国互联网协会 信 l 《中华人民共和国信息产业部关于中国互联网络域名体系的公范》2002.11.22 息产业部 l 《中国互联网络域名管理办法》 2002.09.01 l 《保护网络作品权利信息公约》 2002.09.17 8.4 法规与技术标准/规范要求的检查方法 信息产业部 QMS：产品/服务必须满足的有关法律、法规或其他强制性要求所适用的过程，及对具备 满足法律和法规要求的能力的证据的检查方法. EMS/OHSMS：与环境管理/健康安全有关的适用的法律法规、强制性技术标准/规范的目录 清单. 附录 A 列出适用的法律法规和强制性技术标准/规范的目录清单. GB/T 11457-1995 《软件工程术语》 GB/T 13702-1992 《计算机软件分类代码》 GB/T 18492-2001 信息技术----《系统及软件完整性级别》 GB/T 15538--1995《软件工程标准分类法》 GB/T 16260—1996 idt 南》. GB/T 1526-1989 ISO/IEC 9126：1991 《软件产品评价 质量特性及其使用指 图和系统资源图的文件编制符号及约定》 GB/T 13502-1992 《信息处理 程序构造及其表示的约定》 GB/T8566—2001 idt ISO/IEC12207—2001 信息技术―《软件生存周期过程》 GB/Z 18493—1996 GB/T 16680-1996 《软件文档管理指南》 GB/T 8567—2004 《计算机软件文档编制规范》 GB/T 9385-1998 《计算机软件需求说明编制指南》 GB/T 15532-1995 《计算机软件单元测试》 GB/T 9386-1988 《计算机软件测试文件编制规范》 GB/T 12505-1990 《计算机软件配置管理计划规范》 24 PDF 文件使用 "pdfFactory Pro" 试用版本创建 fineprint Ę 《信息处理 数据流程图、程序流程图、系统流程图、程序网络 信息技术《软件生存周期过程指南》
GB/T 14097-1993 《软件维护指南》 GB/T 12504-1990 《计算机软件质量保证计划规范》 HB 6466-1990 《软件质量保证计划编制规定 GB/T 15853-1995 《软件支持环境》 GB/Z18914-2002 信息技术----《软件工程 CASE 工具的采用指南》 GB/T 18234-2000 信息技术----《CASE 工具的评价和选择指南》 GB 4943-2001 《信息技术设备的安全》 《软件