©2010-2026 宁波自信网络信息技术有限公司 版权所有
客服电话：0574-28810668 投诉电话：18658249818
浙ICP备2021020529号-1 | 浙B2-20240490
关注我们 ：
1、ISO9000-3:97 质量管理和质量保证标准 ISO9001：1994在计算机软件开发、供应、安装和维护中的应用指南 引 言 标准为计算机软件设计、开发、安装和维护等业务的供方应用ISO 9001：1994提供指导。 供方业务可涉及以下内容： 作为同部组织签订商务合同的部分； 作为市场部门可获得的产品； 为了支持供方的业务过程； 作为嵌入硬件产品的软件。 本标准指出需要涉及的问题，而与供方采用的技术、生存周期模型、开发过程、活动顺序或组织结构无关。当一个组织质量体系中计算机
2、软件要素与其它方面之间的关系宜清楚地定写在一个统一的质量体系文件中。 本标准为应用ISO 9001：1994提供指南，在引用ISO 9001：1994原文的地方加上方框，以便于辨别。 本标准自始至终用“应”（shall）表示双方或多方间有约束力的规定；用“愿意”（will）表示一方的目的的声明或意图；用“最好”、“建议”、或“宜”（should）表示在诸多可能性中的一种推荐；用“可以”（may）指明在本标准范围内允许的作法。 1.范围 本标准为便于计算机软件开发、供应、安装和维护的组织采用国际标准ISO 9001：1994提供指南。本标准未增加或
3、改变ISO 9001的要求。 本标准不打算用作质量体系注册/认证时的评估准则。 2.引用标准 本标准引用下列标准的有关条款。本标准发布时，这些引用标准均为有效版本。所有的标准都将修订。 因此，鼓励依据本标准达成协议的各方尽可能采用下列标准的最新版本。IEC和ISO成员均持有现行有效的国际标准。 ISO 8402：1994质量管理和质量保证术语 ISO 9001：1994质量体系 设计、开发、生产、安装和服务的质量保证模式 3.定义 本标准ISO 8402 中的定义及下述定义 3.1产品 pro
4、duct 活动或过程的结果。 注1：产品包括服务、硬件、流程性材料、软件或它们的组合。 注2：产品可以是有形的（如组织或流程性材料），也可是无形的（如知识或概念），或是它们的组合。 注3：本标准中“产品“这一术语，仅适用于期望提供的产品，而不是影响环境的非期望有”副产品“，这不同于ISO 8402中的定义[ISO 9001]。 3.2 投标 tender 供方应邀作出提供满足合同要求产品的报盘[ISO 9001]。 3.3 合同 contract 供方和顾客之间以任何方式传递的、双方同意的要求[IS
5、O 9001]。 3.4 基线 baseline 一个配置项在其生存周期的某一特定时间被正式标明、固定并经正式批准的版本。无论媒体是什么[ISO/IEC 12207]。 3.5 开发 development 软件生存周期过程，包括需求分析、设计、编码、集成、测试、安装和支持软件产品验收等活动。 3.6 生存周期模型 life cycle model 一个框架，它包含从定义需求开始到不能再使用的系统寿命期间与软件产品开发、运行和维护有关的过程、活动和[ISO/IEC 12207]。 3.7 阶段 phase
6、 注：某一个阶段，并不意味着使用任一特定的生成周期模型。 3.8 回归测试 regression testing 为确认纠正缺陷所作的更改不致引起派生缺陷的测试。 3.9 复制 replication 将软件产品从一个媒体拷贝到另一个媒体。 3.10 软件 software 见软件产品（3.11）。 注：本标准中的术语“软件”限定为计算机软件。 3.11 软件产品 software product 整套的计算机程序、规程。可能还有与其相关的文档和数据[ISO/IEC 12207]。
7、 注：软件产品可以是指定用于交付的产品，另一产品的组成部分或在开发过程中使用的产品。 3.12 软件项 software item 软件产品的任何可标识部分。 4. 质量体系要求 4.1 管理职责 4.1.1质量方针 负有执行职责的供方管理者，应规定质量方针，包括质量目标和对质量的承诺，并形并形成文件。 质量方针应体现供方的组织目标以及顾客的期望和需要。供方应确保其各级人员都理解质量方针，并坚持贯彻执行。 不需要有与软件有关的进一步指南。 4.1.2组织 4.1.2.1职责和权限 对从
8、事与质量有关的管理、执行和验证工作的人员，特别是对需要独立行使权力开展以下工 作的人员，应规定其职责、权限和相互关系，并形成文件： 采取措施，防止出现与产品、过程和质量体系有关的不合格； 确认和记录与产品、过程和质量体系有关的问题； 通过规定的渠道，采取、推荐或提出解决办法； 验证解决办法的实施效果； 控制不合格产品的进一步加工、交付或安装，直至缺陷或不满足要求的情况得到纠正。 不需要有与软件有关的进一步指南。 4.1.2.2资源 对管理，执行工作和验证活动（包括内部质量审核），供方应确定
9、资源要求并提供充分的资源，包括委派经过培训的人员（见4.18）。 不需要有与软件有关的进一步指南。 4.1.2.3 管理者代表 负有执行职责的供方管理者，应在自己的管理层中指定一名成员为管理者代表，不论其在其他方面职责如何，应明确权限，以便： 确保按照本标准要求建立，实施和保持质量体系； 向供方管理者报告质量体系的运行情况，以供评审和作为质量体系改进的基础。 注：管理者代表的职责还可包括就供方质量体系有关事宜与外部各方的联络工作。 不需要有与软件有关的进一步指南。 4.1.3 管理评审 负
10、有执行职责的供方管理者，应按规定的时间间隔对质量体系进行评审，确保持续的适宜性和有效性，以满足本标准的要求和供方规定的质量方针和目标（见4.1.1）。评审记录应予以保存（见4.16）。 不需要有与软件有关的进一步指南。 4.2 质量体系 4.2.1总则 供方应建立质量体系，形成文件并加以保持，作为确保产品符合规定要求的一种手段。供方应编制覆盖本标准要求的质量手册。质量手册应包括或引用质量体系程序，并概述质量体系文件的结构。 注：ISO 10013 提供了质量手册的编制指南。 不需要有与软件有关的进一步指南。 4.2.2质
11、量体系程序 供方应： a)编制与本标准要求有和供方规定的质量方针相一致的形成文件的程序； b)有效地实施质量体系及其形成文件的程序。 基于本标准的目的，作为质量体系的一部分的质量体系程序，其程序范围和详细程序可应取决于工作的复杂程序、所用的方法，以及开展这项活动涉及的人员所需的技能和培训。 注：形成文件的程序可以引用规定某项活动如何进行的作业指导书。 不需要有与软件有关的进一步指南。 4.2.3质量策划 供方应对如何满足质量要求做出规定，并形成文件。质量策划应与供方质量体系的所有其他要求相一
12、致，并形成适于供方操作的文件。为满足产品、基础上或合同规定的要求，供方应适当考虑下述活动： 编制质量计划； 确定和配备必要的控制手段、过程、设备（包括检验和试验设备）、工艺装备、资源和技能，以达到所要求的质量； 确保设计、生产过程、安装、服务、检验和试验程序和有关文件的相容性； 必要时，更新质量控制、检验和试验技术，包括研制新的调度设备； 确定所有测量要求，包超出现有的水平但在足够时限内能开发的测量能力； 确定在产品形成适当阶段的合适的验证； 对所有特性的要求，包括含有主观因素的特性和要求，明确接
13、收标准； 确定和准备质量记录（见4.16）。 注：4.2.3a）提及的质量计划可以采取引用相应的形成文件的程序的方式，这些程序构成供方质量体系的一个部分。 当合适时，质量计划应规定下述项目： 合适的地方，以可测量的术语表示的质量要求； 用于软件开发的生存周期模型； 规定起动和结束每一基础上阶段的准则； 明确需要执行的评审、测试以及其他验证和确认活动的类型； 明确需要执行的配置管理规程； 详细策划（包括进度安排、程序、资源和批准）和特定的质量活动职责和权限，比如：
14、 ——配置管理； ——开发产品的验证和确认； ——采购产品的验证和确认； ——顾客提供的产品的验证； ——不合格产品的控制以及纠正措施； ——确保完成质量计划中所述的活动。 质量计划为质量体系应用于特定的项目、产品或合同提供剪裁方法。如合适，质量计划可以在包括引用通用的和/或项目/产品/合同的特定规程。 质量计划应根据开发进展情况更新，当某一阶段开始时，与该阶段有关的活动应完全确定。 质量计划应由在其执行中有关的所有组织加以评审和协商一致。 描述质量计划的文档可以是独立
15、的文档（加质量计划标题），或作为另一文档的一部分，或由若干文档组成。 质量计划可以包括或引用单元测试、集成测试、系统测试和验收测试的计划，测试策划和测试环境的指南是检验和测试的一部分。 注：质量计划指南在ISO 10005 中给出，配置管理指南在ISO 10007中给出。为得到更多的信息，参看ISO/12207：1995的6.2至6.5条。 4.3 合同评审 4.3.1总则 供方应建立并保持合同评审的一部分开发，作为市场上可获得的产品、作为硬件产品中嵌入的软件或作为供方业务过程的支撑而开发。合同评审适用于所有这些情况。 4.3.2评审
16、 在投标或接受合同或订单（对要求的说明）之前，供方应对标书、合同或订单进行评审，以确保： 各项要求都有明确规定并形成文件；在以口头方式接到订单，而对要求没有书面说明情况下，供方应确保订单的要求在其接受之前得到同意； 任何与投标不一致的合同或订单的要求已经得到解决； 供方具有满足合同或订单的要求的能力。 在供方对软件标书、合同或订单评审期间，还可以涉及到下述有关的事项。 与顾客有关的事项： ——采用的名词术语由有关各方协商一致； ——顾客具有行履行合同义务的能力和资源； —
17、—经过协商一致的顾客接受或拒收产品的准则； ——在联合开发或分包工作中，顾客参与的程度； ——为监督合同进展而进行联合评审的安排； ——经过协商一致的在开发和/或维护期间处理顾客要求的更改的程序； ——顾客强加的生存周期过程； ——验收后发现的问题处理，包括申诉、顾客的抱怨； ——在任何保证期之后消除不合格部分的职责； ——当供方要求时，向后续版本升级后顾客承担的义务。或者供方保存历史 版本的义务； ——推广应用和有关的用户培训。 技术事项：
18、 ——符合需求的可行性； ——需采用的软件开发标准和规程； ——明确需由顾客提供的设施、工具、软件项和资料，确定评估它们对使用适合性的方法，并形成 文档； ——操作系统或硬件平台； ——关于软件产品接口的控制协议； ——复制和分发要求。 c. 管理方面： ——明确可能的事故和风险，并评估它们对后续活动的影响； ——供方与分包工作有关的职责； ——进度、技术评审和交付物的安排； ——安装、人力和财力资源的及时可得性。 d . 法规、
19、安全和保密事项： ——按合同使用的信息可能会遇到知识产权、许可证协议、保密性和保护问题： ——产品原版的保护，以及顾客访问或验证该原版的权力； ——需由各方协商同意的向顾客透露信息的程度； ——保证期限确定； ——与合同相关连的责任/处理。 注：为得到更多的信息，参看ISO/IEC 12207：1995的5.2.1,5.2.6和6.4.2.1条。 4.3.3合同的修订 供方应确定如何进行合同修订，并正确传递到供方组织内的有关职能部门。 不需要有与软件有关的进一步指南。
20、 注：为得到更多的信息，参看ISO/IEC 12207 的5.1.3.5 和5.2.3.2条。 4.3.4记录 应保存合同评审的记录（见4.16）。 注：供方应与顾客建立有关的事宜的联络渠道和接口。 不需要有与软件有关的进一步指南。 4.4 设计控制 4.4.1总则 供方应建立并保持产品设计控制和验证的形成文件的程序,以确保满足规定的要求 本节提供需求分析、体系结构设计、详细设计和编码等到开发活动的指南。这一切还包括开发策划指南。 软件开发项目应根据一个或多个生存周期模型进行组织。过程、活动和任务应根据采用的生存
21、周期模型的性质加以计划并实施。采用的生存周期模型可以更新，应适合具体的项目要求。本实施在大纲主张应用时与采用的生存周期模型无关，不主张指出特定的生存周期模型。 生存周期模型明确一套过程，并规定何时和如何引用这些过程。在本国际标准中描述的过程的顺序并非以任何方式建议按此顺序完成这些任务。 开发过程就是将需求规范转换为软件产品。这种过程应以规定的方法步骤实施，以免引人错误。这种方法作为明确问题的唯一方法而降低了对验证和确认过程的依赖。因此，供方应建立和维持文件化的规程，以保证软件产品的设计和实现符合规定的要求，并按开发计划和/或质量计划进行。 下述设计活动的固有方面应加以考虑：
22、 a) 设计方法：应系统地使用设计方法。应考虑这种方法对任务、产品或项目类型的适合性，以及所采用的方法与工具的兼容性。 b) 利用过去的经验：利用从过去的实践吸取的经验教训，供方通过应用从先前项目、度量分析用过去项目评审学到的经验，应避免同样的或类似的问题重复出现。 c) 后续过程：软件产品应尽可能设计得便于测试、安装、维护和使用。 d) 保密和安全：设计应特别考虑可测试性或便于确认。对于失效将给人员、性能或环境造成危险的产品，这种软件的设计应保证特定的设计要求，即规定所希望的免于发生潜在的失效状态，或对潜在的失效状态做出系统反应。 对于编码，最好规定并遵守：编程语
23、言使用规则、一致的命名约定、编码和适当的注释规则。这类规则应形成文件并加以控制。 建议只有当所有已知缺陷的后果都能圆满解决时，或者进程中的风险已知时，才应开始进行设计活动。 供方可以使用工具、设备和技术，以便落实本标准中的质量体系指南。这些工具、设备和技术对于管理目的以及产品开发和/或服务可能是有效的。不管这些工具和技术是内部开发的或购买的，供方均应评价它们是否适合于使用目的。在产品实现中使用的工具，比如分析和设计工具、编译程序、汇编程序等应经批准，并在使用之前应按配置管理控制的适当级别配置。这种工具和技术的使用范围最好形成文件，并按规定的间隔复审它们的使用，确定是否需要改进它们和
24、/或使它们升级。 在开始使用这种工具和技术时，或任何改进/升级之后，可能需要对人员进行培训。 4.4.2 设计和开发的策划 供方应对每项设计和开发活动编制计划。计划应阐明或列出应开展的活动，并规定实施这些活动的职责。设计和开发活动应委派给具备一定资格的人员去完成，并为其配备充分的资源。计划应随设计院的进展加以修改。 对于软件产品，开发策划应确定软件产品的下述活动：需求分析、设计、编码、集成、测试、安装和接收支持。开发策划应以开发计划形式形成文件。 开发计划可以确定项目如何进行管理，要求的进度评审，向管理者、顾客和其他有关方报告的类型和频次。要考虑任何合同要求。
25、 如合适，开发策划可包括下述内容： a) 项目的定义，包括对其目的说明以及引用的顾客或供方的任何有关项目； b) 作为一整体项目的输入和输出的定义； c) 项目资源的组织，包括工作小组的组成、职责，分包商的使用以及需使用的物资资源； d) 个人或小组之间的组织接口和技术接口，例如： ——子项目小组； ——分承包商； ——用户； ——顾客代表； ——质量保证代表； c) 标明或引用以下内容： ——需完成的开发活动； ——每一活动所要求的输入； ——每一活动所要求的输出； ——需完成的管理和支持过程； f)
26、 对伴随开发的可能风险、假设、相依性和问题的分析； g)进度安排标明： ——项目的各个阶段； ——需进行的工作（每项任务的输入、输出和定义）； ——相关的资源和时间要求； ——相关的依存关系； ——里程碑； h) 明确下述内容： ——标准、规则、惯例和约定； ——开发用的工具和技术。包括对这类工具和技术的鉴定和配置控制； ——配置管理惯例； ——控制不合格品的方法； ——用于支持开发的非交付软件的控制方法； ——备份和恢复（包括应付偶然事故的计划）的规程； ——归档、备份和恢复的程序，包括应急计划； ——
27、病毒防护的控制方法； I) 标明有关计划（包括系统级计划），如： ——质量计划； ——风险管理计划； ——配置管理计划； ——集成计划； ——测试计划； ——安装计划； ——移交计划； ——培训计划； ——维护计划； ——重用计划； 开发计划和任何有关的这些计划可以是一份独立的文件，或作为另一文件的一部分，或者由若干文件组成。 注：为得到更多的信息，参看ISO/IEC 12207：1995的5.2.4条。 4.4.3 组织和技术接口 应规定参与设计过程的不同部门之间在组织上和技术上的接口,将必要的信息形成
28、文件,予以传递并定期评审。 软件生产的每一部门的职责范围、在所有各方之间传递技术信息的方式，应在供方或分承包方的开发计划中清楚地确定。供方可以要求分承包方提交开发计划，以供评审。 在确定接口时，除了顾客和供方之外，应注意考虑到对设计、安装、维护和培训活动有要求的各方。他们可以包括分承包方、上级管理机关、相关开发项目和咨询服务人员。特别 是，可能需要最终用户和所有中间运行职能部门的参与，以保证得到适当的能力和培训，达到承诺的服务水平。 按合同顾客可能有某些职责。特别需要关心的事包括需要顾客与供方合作以及时提供必要的信息，并解决相关事项。在有顾客代表的地方，顾客代表可以代表
29、产品的最终使用者并执行管理，有权处理合同事项，包括但不限于下列事项： a) 确定顾客对供方的要求； b) 回答供方的询问； c) 批准供方的建议； d) 与供方达成协议； e) 保证顾客的组织遵守与供方达成的协议； f) 确定验收准则和规程； g) 处理顾客提供的不适合使用的软件项、数据、设施和工具； h) 确定顾客的职责。 相互协商一致时，供方和顾客的联合评审可以安排为定期的或项目发生重大事件时进行，联合评审视情况合适与否覆盖下述方面： a) 供方的软件开发工作的进展； b) 顾客同意承担的活动的进展； c) 开发的产品
30、是否符合顾客同意的需求规格说明； d) 开发涉及系统最终用户的活动的进展，比如系统转换和培训； e) 验证结果； f) 验收测试结果。 注：为得到更多的信息，参看 ISO/IEC12207 的6.6.2条。 4.4.4 设计输入 供方就确定与产品有关的设计输入要求，包括适用的法令和法规要求，形成文件，并评审其是否适当。对不完善的、含糊的或矛盾的要求，应会同提出者一起解决。 设计输入应考虑合同评审活动的结果。 需求规格说明最好由顾客提供。然而，在相互协商一致时，供方也可提供需求规格说明。在这种情况下，如合适，供方应注意下列事项： a) 建立文
31、件化的程序来制订需求规格说明书，包括： ——商定需求和授权更改的方法，特别是在反复制定需求的情况下； ——如采用了原型或演示，对原型或演示的评价方法； ——记录和审查双方讨论的结果； b) 与顾客密切合作制订需求规格说明书，并且采取措施，例如提供术语定义、解释需求的背景等，力求避免误解； c) 取得顾客对需求规格说明书的批准。 如合适，可采用交谈、调查、研究、提供原型、演示和分析等方法来制订需求规格说明书。 需求规格说明书可以以系统说明书形式提供并协商一致。在这种情况下，应有适当的程序以确保将系统要求正确地分配到硬件、软件及适当的接口说明书中。
32、需求规格说明书在接受合同时可以不完全确定，在项目进行期间可继续制定。当需求规格说明书更改时，合同可以修订。对需求规格说明书的更改应加以控制。 需求应包括为满足用户同意的需要所必需的所有方面。需求规格说明书可能需要考虑运行环境。需求可以包括但不限于下述特性：功能性、可靠性、易用性、效率、可维护性和可移植性（见ISO/IEC9126）。可以规定例如保密等子特性，还可以规定安全性和法定义务。 如果软件产品需要与其他软件或硬件产品接口，在需求规格说明书中应尽可能规定这些接口，可以直接规定，也可以引用。 需要最好用产品验收时能够确认的形式表示。 注：为得到更多的信息，参看ISO/
33、IEC 12207：1995 的5.3.2至5.3.4条。 4.4.5 设计输出 设计输出应形成文件，并以能够对照设计输入要求进行验证的形式来表达。设计输出应: a 满足设计输入的要求； b包含或引用验收准则 c标出与产品安全和正常工作关系重大的设计特性（如操作、贮存、搬运、维修和处置的要求）。 设计输出文件在发放前应予以评审 每项设计活动所要求的输出应根据所选择的方法确定并形成文档。这种文档应是正确的、完整的并符合要求。设计的输出可以包括： ——概要设计说明书； ——详细设计说明书； ——源代码； ——用户指南； 注：为
34、得到更多的信息。参看ISO/IEC12207：1995的5.3.5至5.3.7条 4.4.6设计评审 在设计的适当阶段,应有计划地对设计结果进行正式的评审,并形成文件.每次设计评审的参加者应包括与被评审的设计阶段有关的所有职能部门的代表,需要时也应包括其他专家.这些评审记录应予以保存.(见4.16). 供方应有尽有对所有软件开发制定计划并实施评审过程。与评审过程相关联的活动的形式和严格度适合于产品的复杂程序以及与软件产品规定的使用相关联的风险程度。供方应建立文件化的程序来处理在这些活动期间发现的产品缺陷和过程缺陷或不合格事项。 在设计评审时，最好考虑到设计活动的内要因素
35、例如，可行性、保密性、安全性、编程规则和可测试性。 评审结果以及为确保符合规定要求所需的进一步活动。当它们完成时应加以记录和核实。只有经验证的 开发输出才应提交验收和后续使用。 开发期间的大多设计评审要加以计划安排，但也可能有一些未经安排的设计评审。 形成文件的设计评审程序应提及下述内容： a 评审什么，何时评审以及评审类型； b 在每种评审类型中应涉及什么功能组，如果需要召开评审会议，应由谁主持； c 必须产什么记录，例如：会议记录、结果、问题、措施和措施状态。 在设计文件的设计评审程序应提及下述内容： a 为保证符合性对规则、惯例和约
36、定的应用进行监督的方法，如同行评审、审查、代友审查； b 在进行评审之前必须做些什么，如制定目标、会议日程、需要的文档和评审人员的分工； c 评审期间要做些什么，包括需采用的技术和所有参加人员的守则；。 d 评审通过的准则； e 采用什么跟踪方法以确保评审中发现的问题得以解决。 合同中有夫规定时，供方应与顾客合作召开设计评审会议。双方应对评审结果协商一致。 建议只有当所有已知的缺陷都得到满意的解决，或者继续进行的风险已知时，才继续进行一步的设计活动。 注：为得到更多的信息。参看ISO/IEC12207：1995的5.3.4.2,5.3.5.6,5.3.
37、6.7和6.6.3 4.4.7设计验证 在设计的适当阶段,应进行设计验证,以确保设计阶段的输出满足该设计阶段输入的要求.设计验证应予以记录(见4.16) 注:除实施设计评审(见4.6.6)之外,设计验证还可包括下活动: ——变换方法进行计算； ——可能时，将新设计与已证实的类似设计进行比较； ——进行试验和证实； ——对发放前的设计阶段文件进行评审。 建立在开发过程中，适当地进行设计验证。设计验证可由设计输出评审，包括原型和仿真的演示或测试组成。验证可对其他开发活动的输出进行。这些验证活动应根据质量计划或形成文件的程序予以记录，并胩当措施完成时进
38、行核算。 只有经验证的开发输出才应提交验收和后续使用。建立对任何发现的问题都有要充分论述并加以解决。 注：为得到更多的信息，参看ISO/IEC12207：1995的5.3.4.2,5.3.6,5.3.5.7,5.3.7.5,5.3.9和6.4条. 4.4.8设计确认 应进行设计确认，以确保产品符合规定的使用者需要和/或要求。 注： 设计确认在成功的设计验证（见4.4.7）之后进行； 确认通常在规定的操作条件下进行； 确认通常针对最终产品进行，但产品完成前的各阶段也可能需要进行； 如果有不同的预期用途，也可以进行多次确认。 在产品提交顾
39、客验收之前，例如在最终检验和测试期间，供方根据其规定的预期用途确认产品。 在软件开发中，为了确保满足规定的要求，确认结果以及需进一步采用的措施应加以记录，并且当措施完成时加以检查。这一点非常重要。只有经确认的产品才应提交验收或后续使用。 注：为了得到更多信息，参见ISO/IEC12207：1995的5.3.1和6.5条。 4.4.9设计更改 所有的设计更改和修改的实施之前都应由授权人员加以确定，形成文件，并评审和批准。 供方应建立和维持控制任何设计更改的实施的程序，这种更改可能在产品开发生存周期的任何时期发生。建立这种程序为了： 将更改形成文档并证实它是否是
40、合理的； 评价更改的后果； 批准或不批准更改； 实施并验证更改。 在软件开发环境中，设计更改的控制通常在配置管理规定中说明。 注：为了得到更多信息，参见ISO 12207：1995的5.5.2,5.5.3和6.2.3条。 ISO 9000-3-97 质量管理和质量保证标准 ISO 9001：1994在计算机软件开发、供应、安装和维护中的应用指南（续） 4.5 文件和资料控制 4.5.1总则 供方应建立并保持形成文件和程序，以控制与本标准要求有关的所有文件和资料，并包括适当范围的外来文件，如标
41、准和顾客提供的图样。 注：文件和资料可以呈任何形式，如硬拷贝或电子媒体。 配置管理程序可以用来实施文档和数据控制。在建立的控制所有文档和数据的程序中，供方应确定那些需服从控制程序的文档的数据，包括外部来源的文档和数据，例如标准和顾客提供的数据。 文档和数据控制程序应用于有关的文档和数据，包括下述种类： 合同规定的文档，包括需求规格说明书； 用于描述软件生存周期内的质量体系的形式文件的程序； 描述供方活动的策划和进展，以及供方与顾客相互配合的计划文档； 描述一具有软件产品的或与特定软件产品相关联的产品文件和数据。 注：为了得到更多信息，参见ISO/
42、IEC 12207：1995的6.1条。 4.5.2文件和资料的批准和发布 文件和资料在发布前应由授权人员审批其适用性。应制定并可随时得到识别文件的现行修订状态的控制清单或相当的文件控制程序，以防止使用失效和/或作废的文件。 这种控制应确保： 在对质量体系有效运行起重要作用的各个场所，都能得到相应文件的有效版本； 从所有发放或使用场所用时撒出失效和/或作废的文件， 或以其他方式确保防止误用； 为法律和/或积累知识的目的所保留的任何已作废的文件，都应进行适当标识。 在使用电子手段实现文档控制的地方，对其适当的批准存取、发放、媒体和归档规程应予以特别注意。
43、 4.5.3文件和资料的更改 除非有专门指定，文件和资料的更改应由该文件的原审批部门/组织进行审批。若指定其他部门/组织审批时，该部门/组织应获得审批所需依据的有关背景资料。 可行时，应在文件或相应的附件上标明更改的性质。 不需要有与软件有关的进一步指南。 4.6 采购 4.6.1总则 供方应建立并保持形成文件的程序，以确保所采购的产品（见3.1）符合规定要求。 在开发、供应、安装和维护软件产品过程中，采购的产品可包括： ——市售现成软件软件； ——分承包方开发的软件； ——计算机和通信硬件； ——帮助软件开发的工具；
44、 ——合同制工作人员； ——维护和顾客支持服务； ——培训课程和教材。 注：为了得到更多信息，参看ISO/IEC12207：1995的5.1条。 4.6.2分承包方的评价 供方应： 根据满足分合同要求（包括质量体系和特定的质量保证要求）的能力评价和选择分承包方； 明确供方对分承包方实行控制的方式和程度，这种方式和程度取决于产品的类别以及分承包的产品对成品质量的影响，还取决于已证实的分承包方能力和业绩的质量审核报告和/或质量记录； 建立并保存合格分承包方的质量记录（见4.16）。 不需要有与软件有关的进一步指南。 4.6.3采购资
45、料 购文件应清楚地说明订购产品的资料，可包括： 类别、形式、等级或其他准确标识方法； 规范、图样、过程要求、检验规程及其他有关技术资料（包括产品、程序、过程设备和人员的认可或鉴定要求）的名称或其他明确标识和适用版本； 适用的质量体系标准的名称、编号和版本。 供方应在采购文件发放前对规定的要求是否适当进行审批。 用于软件开发的采购文档最好包括清楚地说明订购产品的数据，可包括： 订购产品的准确标识，如产品名称和/或产品编号； 需求规格说明，或它的等同文档（或当需求规格说明在订购时尚未完全确定，就规定确定需求规格说明的规程）； 采用的标准（例如通
46、信协议、体系结构规范）； 规程和/或工作需求说明； 开发环境； 对人员的要求。 关于合同评审的考虑也可用于分合同。 4.6.4采购产品的验证 4.6.4.1供方在分承包方货源处的验证 当供方提出在分承包方货源处对采购产品进行验证时，供方应在采购文件中规定验证安排以及产品放行的方式。 不需要有与软件有关的进一步指南 4.6.4.2顾客对分承包方产品的验证地 当合同规定时，供方顾客或其代表应权在分承包方处和供方处对分承包的产品是否符合规定要求进行验证。供方不能把该验证用作分承包方对质量进行了有效控制的证据。顾客的验证既不能免供方提供可接收
47、产品的责任，也不能排除其后顾客的拒收。 不需要有与软件有关的进一步指南。 4.7 顾客提供产品的控制 供方对顾客提供的产品（用于供应品或有关活动）应建立并保持验证、贮存和维护的形成文件的控制程序。如有丢失、损坏或不适用的情况，应予以记录并向顾客报告（见4.16) 供方的验证不能免除顾客提供可接收产品的责任。 顾客可能要求供方取得由顾客提供的包括数据在内的产品，并将其纳入供方产品中，例如： 软件产品，包括顾客提供的市售软件产品； 开发工具； 开发环境，包括网络服务； 测试数据和运行数据； 接口规格说明或其他规格说明； 硬件；
48、 顾客专有信息，包括规格说明。 在任何与待交付的产品有关的维护协议中，最好在合同中说明这类软件产品所需的许可证和支持。 应确定已接收并已集成的顾客提供的软件项的更新方法，供方可以应用与采购产品相同的验证活动来验证顾客提供的产品。 注：为得到更多信息，参看ISO/IEC 12207：1995的6.1条。 4.8产品标识和可追溯性 必要时，供方应建立并保持形成文件的程序，在接收和生产、交付及安装的各阶段以适当的方式标识产品。 在规定有可追溯性要求的场合，供方应建立并保持形成文件的程序，对每个或每批产品都应有唯一标识，这种标识应加以记录（见4.16）。 供方
49、最好建立并保持程序，用以标识从规格说明到开发、复制与交付的所有阶段的软件项。如果合同要求，这些程序也要适用于产品交付之后。 该程序最好跟踪产品整个生存周期的软件项或软件产品的部件。根据合同和市场需求的不同，从可将某一变更要求加于特定发行物到记录产品的每一变更目标和用法。 在软件中，可以实现的标识可追溯性的一种方法就是配置管理。配置管理是一种管理学科，对配置项（包括软件项）的开发和生存周期的支持，给予技术和管理指导。这种学科还适用于有关的文档编制硬件。配置管理的使用取决于项目规模和复杂性以及风险水平。 配置管理的一个目标编制文档，并对产品现有配置和达到其要求的状态提供足够的可视
50、性。另一目标是项目的每个工作人员工在项目的生存周期中的任何时刻都能采用正确的和准确的信息。 配置管理系统可以提供下述能力： 唯一地标识每一软件项的版本； 标识共同构成一完整产品的特定版本的每一软件项的版本； 标识正在开发的和已交付安装的软件产品的构成状态； 控制由两个或多个独立工作的人员同时对一给定的软件项的更新； 按要求在一个或多个位置对复杂产品的更新进行协调； 标识并跟踪所有的措施和更改，这些措施和更改是在从直到放行期间，由于更改请求或问题引起的。 供方应按下述内容标识配置： 产品结构和配置项的选择； 文档编制和计算机文档；
©2010-2026 宁波自信网络信息技术有限公司 版权所有
客服电话：0574-28810668 投诉电话：18658249818
浙ICP备2021020529号-1 | 浙B2-20240490
关注我们 ：
