质量管理和质量保证标准第三部分ISO9001：1994在计算机软件开发、供应、安装和维护中的应用指南.doc

1、ISO9000-3:97质量管理和质量保证标准ISO9001：1994 在计算机软件开发、供应、安装和维护中的应用指南引 言标准为计算机软件设计、开发、安装和维护等业务的供方应用 ISO 9001：1994 提供指导。供方业务可涉及以下内容：作为同部组织签订商务合同的部分；作为市场部门可获得的产品；为了支持供方的业务过程；作为嵌入硬件产品的软件。本标准指出需要涉及的问题，而与供方采用的技术、生存周期模型、开发过程、活动顺序或组织结构无关。当一个组织质量体系中计算机软件要素与其它方面之间的关系宜清楚地定写在一个统一的质量体系文件中。本标准为应用 ISO 9001：1994 提供指南，在引用 IS

2、O 9001：1994 原文的地方加上方框，以便于辨别。本标准自始至终用“应” （shall）表示双方或多方间有约束力的规定；用“愿意”（will）表示一方的目的的声明或意图；用“最好” 、 “建议 ”、或“宜” （should）表示在诸多可能性中的一种推荐；用“可以” （may）指明在本标准范围内允许的作法。1.范围本标准为便于计算机软件开发、供应、安装和维护的组织采用国际标准 ISO 9001：1994 提供指南。本标准未增加或改变 ISO 9001 的要求。本标准不打算用作质量体系注册/认证时的评估准则。2.引用标准本标准引用下列标准的有关条款。本标准发布时，这些引用标准均为有效版本。所

3、有的标准都将修订。因此，鼓励依据本标准达成协议的各方尽可能采用下列标准的最新版本。IEC 和 ISO成员均持有现行有效的国际标准。ISO 8402：1994 质量管理和质量保证术语ISO 9001：1994 质量体系 设计、开发、生产、安装和服务的质量保证模式3.定义本标准 ISO 8402 中的定义及下述定义3.1 产品 product活动或过程的结果。注 1：产品包括服务、硬件、流程性材料、软件或它们的组合。注 2：产品可以是有形的（如组织或流程性材料） ，也可是无形的（如知识或概念） ，或是它们的组合。注 3：本标准中“产品“这一术语，仅适用于期望提供的产品，而不是影响环境的非期望有”副

4、产品“，这不同于 ISO 8402 中的定义ISO 9001。3.2 投标 tender供方应邀作出提供满足合同要求产品的报盘ISO 9001。3.3 合同 contract供方和顾客之间以任何方式传递的、双方同意的要求ISO 9001。3.4 基线 baseline 一个配置项在其生存周期的某一特定时间被正式标明、固定并经正式批准的版本。无论媒体是什么ISO/IEC 12207。3.5 开发 development 软件生存周期过程，包括需求分析、设计、编码、集成、测试、安装和支持软件产品验收等活动。3.6 生存周期模型 life cycle model 一个框架，它包含从定义需求开始到不能

5、再使用的系统寿命期间与软件产品开发、运行和维护有关的过程、活动和ISO/IEC 12207。3.7 阶段 phase 注：某一个阶段，并不意味着使用任一特定的生成周期模型。3.8 回归测试 regression testing 为确认纠正缺陷所作的更改不致引起派生缺陷的测试。3.9 复制 replication 将软件产品从一个媒体拷贝到另一个媒体。3.10 软件 software 见软件产品（3.11） 。注：本标准中的术语“软件”限定为计算机软件。3.11 软件产品 software product 整套的计算机程序、规程。可能还有与其相关的文档和数据ISO/IEC 12207 。注：软件

6、产品可以是指定用于交付的产品，另一产品的组成部分或在开发过程中使用的产品。3.12 软件项 software item 软件产品的任何可标识部分。 4. 质量体系要求 4.1 管理职责4.1.1 质量方针负有执行职责的供方管理者，应规定质量方针，包括质量目标和对质量的承诺，并形并形成文件。质量方针应体现供方的组织目标以及顾客的期望和需要。供方应确保其各级人员都理解质量方针，并坚持贯彻执行。不需要有与软件有关的进一步指南。4.1.2 组织4.1.2.1 职责和权限对从事与质量有关的管理、执行和验证工作的人员，特别是对需要独立行使权力开展以下工作的人员，应规定其职责、权限和相互关系，并形成文件：采

7、取措施，防止出现与产品、过程和质量体系有关的不合格；确认和记录与产品、过程和质量体系有关的问题；通过规定的渠道，采取、推荐或提出解决办法；验证解决办法的实施效果；控制不合格产品的进一步加工、交付或安装，直至缺陷或不满足要求的情况得到纠正。不需要有与软件有关的进一步指南。4.1.2.2 资源对管理，执行工作和验证活动（包括内部质量审核） ，供方应确定资源要求并提供充分的资源，包括委派经过培训的人员（见 4.18） 。不需要有与软件有关的进一步指南。4.1.2.3 管理者代表负有执行职责的供方管理者，应在自己的管理层中指定一名成员为管理者代表，不论其在其他方面职责如何，应明确权限，以便：确保按照本

8、标准要求建立，实施和保持质量体系；向供方管理者报告质量体系的运行情况，以供评审和作为质量体系改进的基础。注：管理者代表的职责还可包括就供方质量体系有关事宜与外部各方的联络工作。不需要有与软件有关的进一步指南。4.1.3 管理评审负有执行职责的供方管理者，应按规定的时间间隔对质量体系进行评审，确保持续的适宜性和有效性，以满足本标准的要求和供方规定的质量方针和目标（见 4.1.1） 。评审记录应予以保存（见 4.16） 。不需要有与软件有关的进一步指南。4.2 质量体系4.2.1 总则供方应建立质量体系，形成文件并加以保持，作为确保产品符合规定要求的一种手段。供方应编制覆盖本标准要求的质量手册。质

9、量手册应包括或引用质量体系程序，并概述质量体系文件的结构。注：ISO 10013 提供了质量手册的编制指南。不需要有与软件有关的进一步指南。4.2.2 质量体系程序供方应：a)编制与本标准要求有和供方规定的质量方针相一致的形成文件的程序；b)有效地实施质量体系及其形成文件的程序。基于本标准的目的，作为质量体系的一部分的质量体系程序，其程序范围和详细程序可应取决于工作的复杂程序、所用的方法，以及开展这项活动涉及的人员所需的技能和培训。注：形成文件的程序可以引用规定某项活动如何进行的作业指导书。不需要有与软件有关的进一步指南。4.2.3 质量策划供方应对如何满足质量要求做出规定，并形成文件。质量策

10、划应与供方质量体系的所有其他要求相一致，并形成适于供方操作的文件。为满足产品、基础上或合同规定的要求，供方应适当考虑下述活动：编制质量计划；确定和配备必要的控制手段、过程、设备（包括检验和试验设备） 、工艺装备、资源和技能，以达到所要求的质量；确保设计、生产过程、安装、服务、检验和试验程序和有关文件的相容性；必要时，更新质量控制、检验和试验技术，包括研制新的调度设备；确定所有测量要求，包超出现有的水平但在足够时限内能开发的测量能力；确定在产品形成适当阶段的合适的验证；对所有特性的要求，包括含有主观因素的特性和要求，明确接收标准；确定和准备质量记录（见 4.16） 。注：4.2.3a）提及的质量

11、计划可以采取引用相应的形成文件的程序的方式，这些程序构成供方质量体系的一个部分。当合适时，质量计划应规定下述项目：合适的地方，以可测量的术语表示的质量要求；用于软件开发的生存周期模型；规定起动和结束每一基础上阶段的准则；明确需要执行的评审、测试以及其他验证和确认活动的类型；明确需要执行的配置管理规程；详细策划（包括进度安排、程序、资源和批准）和特定的质量活动职责和权限，比如：配置管理；开发产品的验证和确认；采购产品的验证和确认；顾客提供的产品的验证；不合格产品的控制以及纠正措施；确保完成质量计划中所述的活动。质量计划为质量体系应用于特定的项目、产品或合同提供剪裁方法。如合适，质量计划可以在包括

12、引用通用的和/或项目/ 产品/合同的特定规程。质量计划应根据开发进展情况更新，当某一阶段开始时，与该阶段有关的活动应完全确定。质量计划应由在其执行中有关的所有组织加以评审和协商一致。描述质量计划的文档可以是独立的文档（加质量计划标题） ，或作为另一文档的一部分，或由若干文档组成。质量计划可以包括或引用单元测试、集成测试、系统测试和验收测试的计划，测试策划和测试环境的指南是检验和测试的一部分。注：质量计划指南在 ISO 10005 中给出，配置管理指南在 ISO 10007 中给出。为得到更多的信息，参看 ISO/12207：1995 的 6.2 至 6.5 条。4.3 合同评审4.3.1 总则

13、供方应建立并保持合同评审的一部分开发，作为市场上可获得的产品、作为硬件产品中嵌入的软件或作为供方业务过程的支撑而开发。合同评审适用于所有这些情况。4.3.2 评审在投标或接受合同或订单（对要求的说明）之前，供方应对标书、合同或订单进行评审，以确保：各项要求都有明确规定并形成文件；在以口头方式接到订单，而对要求没有书面说明情况下，供方应确保订单的要求在其接受之前得到同意；任何与投标不一致的合同或订单的要求已经得到解决；供方具有满足合同或订单的要求的能力。在供方对软件标书、合同或订单评审期间，还可以涉及到下述有关的事项。与顾客有关的事项：采用的名词术语由有关各方协商一致；顾客具有行履行合同义务的能

14、力和资源；经过协商一致的顾客接受或拒收产品的准则；在联合开发或分包工作中，顾客参与的程度；为监督合同进展而进行联合评审的安排；经过协商一致的在开发和/或维护期间处理顾客要求的更改的程序；顾客强加的生存周期过程；验收后发现的问题处理，包括申诉、顾客的抱怨；在任何保证期之后消除不合格部分的职责；当供方要求时，向后续版本升级后顾客承担的义务。或者供方保存历史版本的义务；推广应用和有关的用户培训。技术事项：符合需求的可行性；需采用的软件开发标准和规程；明确需由顾客提供的设施、工具、软件项和资料，确定评估它们对使用适合性的方法，并形成文档；操作系统或硬件平台；关于软件产品接口的控制协议；复制和分发要求。

15、c. 管理方面：明确可能的事故和风险，并评估它们对后续活动的影响；供方与分包工作有关的职责；进度、技术评审和交付物的安排；安装、人力和财力资源的及时可得性。d . 法规、安全和保密事项：按合同使用的信息可能会遇到知识产权、许可证协议、保密性和保护问题：产品原版的保护，以及顾客访问或验证该原版的权力；需由各方协商同意的向顾客透露信息的程度；保证期限确定；与合同相关连的责任/处理。注：为得到更多的信息，参看 ISO/IEC 12207：1995 的 5.2.1,5.2.6 和 6.4.2.1 条。4.3.3 合同的修订供方应确定如何进行合同修订，并正确传递到供方组织内的有关职能部门。不需要有与软件

16、有关的进一步指南。注：为得到更多的信息，参看 ISO/IEC 12207 的 5.1.3.5 和 5.2.3.2 条。4.3.4 记录应保存合同评审的记录（见 4.16） 。注：供方应与顾客建立有关的事宜的联络渠道和接口。不需要有与软件有关的进一步指南。4.4 设计控制4.4.1 总则供方应建立并保持产品设计控制和验证的形成文件的程序,以确保满足规定的要求本节提供需求分析、体系结构设计、详细设计和编码等到开发活动的指南。这一切还包括开发策划指南。软件开发项目应根据一个或多个生存周期模型进行组织。过程、活动和任务应根据采用的生存周期模型的性质加以计划并实施。采用的生存周期模型可以更新，应适合具体

17、的项目要求。本实施在大纲主张应用时与采用的生存周期模型无关，不主张指出特定的生存周期模型。生存周期模型明确一套过程，并规定何时和如何引用这些过程。在本国际标准中描述的过程的顺序并非以任何方式建议按此顺序完成这些任务。开发过程就是将需求规范转换为软件产品。这种过程应以规定的方法步骤实施，以免引人错误。这种方法作为明确问题的唯一方法而降低了对验证和确认过程的依赖。因此，供方应建立和维持文件化的规程，以保证软件产品的设计和实现符合规定的要求，并按开发计划和/或质量计划进行。下述设计活动的固有方面应加以考虑：a) 设计方法：应系统地使用设计方法。应考虑这种方法对任务、产品或项目类型的适合性，以及所采用

18、的方法与工具的兼容性。b) 利用过去的经验：利用从过去的实践吸取的经验教训，供方通过应用从先前项目、度量分析用过去项目评审学到的经验，应避免同样的或类似的问题重复出现。c) 后续过程：软件产品应尽可能设计得便于测试、安装、维护和使用。d) 保密和安全：设计应特别考虑可测试性或便于确认。对于失效将给人员、性能或环境造成危险的产品，这种软件的设计应保证特定的设计要求，即规定所希望的免于发生潜在的失效状态，或对潜在的失效状态做出系统反应。对于编码，最好规定并遵守：编程语言使用规则、一致的命名约定、编码和适当的注释规则。这类规则应形成文件并加以控制。建议只有当所有已知缺陷的后果都能圆满解决时，或者进程

19、中的风险已知时，才应开始进行设计活动。供方可以使用工具、设备和技术，以便落实本标准中的质量体系指南。这些工具、设备和技术对于管理目的以及产品开发和/或服务可能是有效的。不管这些工具和技术是内部开发的或购买的，供方均应评价它们是否适合于使用目的。在产品实现中使用的工具，比如分析和设计工具、编译程序、汇编程序等应经批准，并在使用之前应按配置管理控制的适当级别配置。这种工具和技术的使用范围最好形成文件，并按规定的间隔复审它们的使用，确定是否需要改进它们和/或使它们升级。在开始使用这种工具和技术时，或任何改进/升级之后，可能需要对人员进行培训。4.4.2 设计和开发的策划供方应对每项设计和开发活动编制计划。计划应阐明或列出应开展的活动，并规定实施这些活动的职责。设计和开发活动应委派给具备一定资格的人员去完成，并为其配备充分的资源。计划应随设计院的进展加以修改。