基线baseline 在配置项的生存周期内的某一特定时刻已正式指定和固定的且经正式批准的配置项的一个版本， 而不管其媒体是什么。 3.6 配量项configurationitem 某个配置中的实体，它满足一项最终使用功能，并在给定的参考点上能够唯一地加以标识。 3.7 使用周境contextofuse 用户、任务、设备（硬件、软件和资料）以及产品使用的物理和社会环境。 3.8 合同contract 通过法律约束当事双方的一个协定，或者个组织内类似的内部协定，以便软件服务的提供、或软 件产品的提供、开发、生产、运行或维护。 3.9 开发方developer 在软件生存周期过程中执行开发活动（包括需求分析、设计、测试直到验收）的组织。 3.10 评价evaluation 系统地确定一个实体项目满足其规定准则的程度。 3.11 固件firmware 硬件装置和作为只读软件驻留在硬件装置中的计算机指令或计算机数据的组合，该软件不能在程 序控制下方便地修改，

基线baseline 在配置项的生存周期内的某一特定时刻已正式指定和固定的且经正式批准的配置项的一个版本， 而不管其媒体是什么。 3.6 配量项configurationitem 某个配置中的实体，它满足一项最终使用功能，并在给定的参考点上能够唯一地加以标识。 3.7 使用周境contextofuse 用户、任务、设备（硬件、软件和资料）以及产品使用的物理和社会环境。 3.8 合同contract 通过法律约束当事双方的一个协定，或者个组织内类似的内部协定，以便软件服务的提供、或软 件产品的提供、开发、生产、运行或维护。 3.9 开发方developer 在软件生存周期过程中执行开发活动（包括需求分析、设计、测试直到验收）的组织。 3.10 评价evaluation 系统地确定一个实体项目满足其规定准则的程度。 3.11 固件firmware 硬件装置和作为只读软件驻留在硬件装置中的计算机指令或计算机数据的组合，该软件不能在程 序控制下方便地修改

一个包含过程、活动和任务的框架，这些过程，活动和任务涉及软件产品的开发、运 需求定义到终止使用的系统生存周期。

过程process 把输人转换为输出的一组彼此相关的活动。 注：术语“活动”包括资源的使用。 3.19 合格性认定 qualification 证实一个实体是否能够完成规定需求的过程。 3.20 合格性需求qualificationrequirement 为了证明一个软件产品依从其规格说明且可以在其目标环境中使用，该软件产品必须满足的一组 推则或条件。

过程process 把输人转换为输出的一组彼此相关的活动。 注：术语“活动”包括资源的使用。 3.19 合格性认定 qualification 证实一个实体是否能够完成规定需求的过程。 3.20 合格性需求qualificationrequirement 为了证明一个软件产品依从其规格说明且可以在其目标环境中使用建筑节能，该软件产品必须满足的一组 推则或条件。

合格性测试qualificationtesting

由开发方进行并由需方见证的测试（如合适），以证明软件产品符合其规格说明，并可以在其目标环 境中使用。

质保证qualityassurance

为了提供足够的信任以表明实体能够满足质量要求，而在质量体系中实施并根据需要进行证实的 全部有计划和有系统的活动。 注1：质量保证有内部和外部两种目的。 a）内部质量保证：在组织内部，质量保证向管理者提供信任。 b）外部质量保证：在合同或其他情况下，质量保证向顾客或他方提供信任。 注2：质量控制和质量保证的某些活动是相互关联的。 注3：只有质量要求全面反映了用户的要求，质量保证才能提供足够的信任。 3.23 发布release 已准备好用于特定目的（例如测试发布）的一个配置项的特定版本。 3.24 招标（标书）requestforproposal(tender) 需方使用的一种文档，用来向潜在的投标人表示它要获得特定系统、软件产品或软件服务的要求和 意图。 3.25 退役retirement 运行和维护组织撤出现有的支持，部分或全部由一个新的系统代替或者安装一个升级的系统。 3.26 安全保密性security 对信息和数据的保护，以使未经授权的人员或系统不能阅读或修改它们，且不拒绝授权人员或系统 对它们的访间。

为了提供足够的信任以表明实体能够满足质量要求，而在质量体系中实施并根据需要进行证实的 全部有计划和有系统的活动。 注1：质量保证有内部和外部两种目的。 a）内部质量保证：在组织内部，质量保证向管理者提供信任。 b）外部质量保证：在合同或其他情况下，质量保证向顾客或他方提供信任。 注2：质量控制和质量保证的某些活动是相互关联的。 注3：只有质量要求全面反映了用户的要求，质量保证才能提供足够的信任。 3.23 发布release 已准备好用于特定目的（例如测试发布）的一个配置项的特定版本。 3.24 招标（标书）requestforproposal(tender) 需方使用的一种文档，用来向潜在的投标人表示它要获得特定系统、软件产品或软件服务的要求和 意图。 3.25 退役retirement 运行和维护组织撤出现有的支持，部分或全部由一个新的系统代替或者安装一个升级的系统。 3.26 安全保密性 security 对信息和数据的保护，以使未经授权的人员或系统不能阅读或修改它们，且不拒绝授权人员或系统 对它们的访问。 3.27 软件产品softwareproduct

软件产品softwareproduc

软件服务software service

软件单元softwareunit 完成某个特定功能的最基本的程序段。 3.30 工作说明 statementofwork 需方使用的一种文档，用来描述和规定按合同必须执行的任务。 3.31 供方supplier 与需方签订合同，并按合同规定提供系统、软件产品或软件服务的组织。 注1：术语“供方”是承制方、生产方、卖方或供货方的同义词。 注2：需方可以指定本组织的一部分为供方。 3.32 系统system 由过程、硬件、软件、设施和人员组成的集合体，提供满足明确的要求或目标的能力 3.33 测试覆盖率 testcoverage 测试用例测试系统或软件产品的需求的程度 3.34 可测试性 testability 为了确定一项需求是否满足，能够设计个客观且可行的测试的程度。 3.35 用户user 使用运行系统完成一项特定功能的个人或组织。 注：用户可以扮演其他角色，比如需方、开发方或维护方。 3.36 确认validation 通过检查和提供客观证据来证实针对某一特定预期用途的需求已经得到满足。 注1：在设计和开发中，确认涉及到检查某个产品以确定是否符合用户需要的过程。 注2：确认通常是对最终产品在规定的使用条件下进行的。在早期阶段，也可能需要进行确认。 注3：“确认过的”一词用来表示柜应的状况。 注4：如果有不同的预期用途，可以进行多重确认。 3.37 验证verification 通过检查和提供客观证据来证实规定需求已经得到满足 注1：在设计和开发中，验证是指对某项规定活动的结果进行检查的过程，以确定该活动对规定需 注2：“验证过的”用来表示相应的状况。 3.38 版本version 某一配置项的已标识的实例。 注：对软件产品的某个版本进行修改会产生一个新版本，需要对这种修改实施配置管理活动。 3.39

过程的process purpose

执行过程的高级目标并有效地实施过程的可能结果，实施本过程应使共利益者得到切实的利益，

过程目的成功实现的可观察成果。 注1：结果陈述应描述下列内容之一！ 一人工制品： 状态的重要变更； 满足规定的限制，如需求、自标等。 注2：基本过程的结果清单构成

本章阐述应用于获得、供应、开发 件的软件生存周期的各个过程。目 用户提供一个路线图，以便用户按照该路 日把握自己的方向，合理地应用本标准，

本标准把软件生存周期中可能执行的活动分为5个基本过程、9个支持过程和7个 生存周期过程划分为一组活动，每一项活动进一步划分为一组任务。子条款的编号x， ，X.X.x表示一项活动，X.x.x,x表示一个任务。这些生存周期过程将在下面进行介绍 了描述。

4. 1. 1. 1生存周期基本过程

生存周期基本过程（第5章）包括5个过程，这些过程供各主要参与方在软件生存， 要参与方是发起或完成软件产品开发、运行或维护的组织。这些主要参与方有软件 开发方、操作方和维护方。

4. 1. 1. 2 生存周期支持过程

4. 1. 1. 3生存周期组织过程

4. 1. 2 剪裁过程

附录A是一个规范性附录，为对本标准进行剪裁而定义所需要的基本活动； 裁要求提供一个简要的指南，它列出了赖以做出剪裁决策的一些关键要素。

4.1.3过程和组织之间的关系

本标准包含一些适用于软件整个生存周期的不同过程，这些过程可以被不同的组织根据其需要和 目标加以使用。为便于理解，附录C阐述了生存周期过程与各有关方之间的关系。

2 附录 D 和正文的

本章定义的生存周期基本过程如下： a） 获取过程； b）供应过程； c 开发过程； d) 运作过程； 维护过程。 基本过程中的活动和任务是启动并实施这些过程的组织的职责。这种组织要保证过程存在并且起 作用

本章定义的生存周期基本过程如下： a） 获取过程； b) 供应过程； c） 开发过程； d) 运作过程； e) 维护过程。 基本过程中的活动和任务是启动并实 作用

获取过程包括需方的活动和任务。该过程从定义要获取的系统、软件产品或软件服务的需要开始， 接着就是制定和发布标书，选择供方和管理获取过程，直到验收系统、软件产品或软件服务为止。 具有这种需要的组织可以称为拥有者，拥有者可以就某一项或全部获取活动与某代理机构签订合 同，该机构将根据获取过程开展这些活动。本条中的需方既可以是拥有者，也可以是代理机构 需方接管理过程（7.1)在项目级上管理本条中具体说明的获取过程；按基础设施过程（7.2）建立本 过程的基础设施；接剪裁过程（附录A）为具体项自剪裁本过程，按改进过程（7.3）和人力资源过程（7.4） 在组织级上管理本过程；按资产管理过程（7.5）、重用大纲管理过程（7.6）和领域工程过程（7.7）在项目 级或组织级上开发、管理、重用本过程产生的或用于本过程的资产。 活动清单：本过程包括下述活动： a）启动； b） 招标标书的准备， 合同的编制和更新； d） 对供方监督； e 验收和完成： f 合同结束； 8） 获取政策；

此项活动包括下述任务： 5.1.1.1需方通过描述为获取、开发或增强系统、软件产品或软件服务的概念或需要来开始获取过程 5.1.1.2需方要定义并分析系统需求。系统需求宜包括业务、组织和用户的需求，以及安全性、安全保 密性与设计、测试有关的其他关键要求和应遵循的标准、规程。 5.1.1.3如果需方委托供方进行系统需求分析，需方要批准所分析的需求。 5.1.1.4需方可以自已定义和分析软件需求，也可委托供方完成这项任务。 5.1.1.5宜应用开发过程（5.3)完成5.1.1.2和5.1.1.4中的任务。需方可使用附录D中描述的需 求启动子过程来建立顾客带求。

5.1.1.1需方通过描述为获取、开发或增强系统、软件产品或软件服务的概念或需要来开始获取过程 5.1.1.2需方要定义并分析系统需求。系统需求宜包括业务、组织和用户的需求，以及安全性、安全保 密性与设计、测试有关的其他关键要求和应遵循的标准、规程。 5.1.1.3如果需方委托供方进行系统需求分析，需方要批准所分析的需求。 5.1.1.4需方可以自已定义和分析软件需求，也可委托供方完成这项任务。 5.1.1.5宜应用开发过程（5.3)完成5.1.1.2和5.1.1.4中的任务。需方可使用附录D中描述的需 求启动子过程来建立顾客需求。 5.1.1.6 6需方要以风险、费用和效益等方面的适当准则对每个获取选择方案进行分析，这些选择方案 包括： a) 购买满足需求的现货软件产品； 在内部开发软件产品或得到软件服务： c 通过合同开发软件产品或得到软件服务； 上述a)、b)、c)项的组合； e） 增强现有的软件产品或服务。 5.1.1.7 当要获取现货软件产品时，供方要保证满足下述条件： a） 满足对该软件产品的需求； b 具有有效的文档； c） 满足专利权、使用权、拥有权、担保权和许可权； d） 具有软件产品的未来支持计划。 5.1.1.8 需方宜准备、编制并执行一个获取计划，该计划宜包括下述内容： a） 对系统的需求； b 计划的系统应用； C） 所应用的合同类型； d 有关组织的职责； e 使用的支持概念； C 已考虑的风险以及管理这些风险的方法

购买满足需求的现货软件产品； b） 在内部开发软件产品或得到软件服务， c） 通过合同开发软件产品或得到软件服务 d) 上述a）、b）、c)项的组合； e） 增强现有的软件产品或服务。 5.1.1.7 当要获取现货软件产品时，供方要保证满足下述条件： a） 满足对该软件产品的需求； b) 具有有效的文档； c 满足专利权、使用权、拥有权、担保权和许可权； d） 具有软件产品的未来支持计划。 5.1.1.8 需方宜准备、编制并执行一个获取计划，该计划宜包括下述内容 对系统的需求； b) 计划的系统应用； c） 所应用的合同类型； d) 有关组织的职责； e 使用的支持概念； ) 已考虑的风险以及管理这些风险的方法。

5. 1.2招标[标书]的准备

1.2.1需方宜编制获取需求文档（例如招标书），文档内容取决于在5.1.1.6中选取的获取方案。合 适时，获取文档宜包括： a） 系统需求； b) 范围说明； c 投标者须知； d） 软件产品清单； e） 期限和条件； f) 子合同的控制； 2 技术约束（例如目标环境）

，获取文档宜包括： a) 系统需求； b) 范围说明； c) 投标者须知； d) 软件产品清单； e) 期限和条件； f) 子合同的控制； 8 技术约束（例如目标环境）。

5.1.2.2需方宜确定本标准中哪些过程、活动和任务适合于该项目，并宜对这些过程、活动和任务进行 相应的剪裁。特别是，需方宜规定适用的支持过程（第6章）及其执行组织，如果不是供方，还应规定其 职责。这样供方就可以在他们的标书中确定每一适用的支持过程的方法。需方应确定引用合同的那些 任务的范围。 5.1.2.3获取文档还要确定合同的里程碑，此时要评审和审核供方的进度，作为监督获取的一部分 (见 6. 6和 6. 7)。

获取需求宜提交给选择来执行获取活动的

此项活动包括下述任务： 5.1.3.1需方宜建立选择供方的规程，包括标书的评价准则和符合需求的程度。 5.1.3.2需方宜根据对供方的标书、能力评价和其他需要考虑的因素来选择一个供方。 5.1.3.3需方可以联合其他各方、包括潜在的供方，在合同签订前针对项目剪裁本标准，然而，需方要 对剪裁作出最后决定。需方要在合同中纳入或者引用经过剪裁的标准。 5.1.3.4需方要与供方一起就合同进行准备和谈判，合同涉及获取需求，包括需交付的软件产品或服 务的费用和进度。合同还要涉及与可重用的现货软件产品相关的专利权、使用权、所有权、担保权和许 可权。 5.1.3.5一且合同开始执行，作为变更控制机制的一部分，需方要通过与供方谈判来控制对合同的变 更。应对合同的变更进行研究，以确定其对项目计划、费用、效益、质量和进度的影响。 注：需方确定在本标准的应用中是否使用术语“合同”或“协定”

5. 1. 4 对供方监押

此项活动包括下述任务： 5.1.4.1需方要按照联合评审过程（6.6)和审核过程（6.7)监督供方的活动。需方宜根据需要利用验 证过程（6.4）和确认过程（6.5）来补充监督。 5.1.4.2需方要与供方合作，以便及时提供所有必要信息，并解决所有遗留问题。

此项活动包括下述任务： 5.1.5.1需方宜根据已确定的验收策略和准则来准备验收，宜包括准备测试用例、测试数据、测试规程 和测试环境。宜确定供方参与的程度。

和测试环境。宜确定供方参与的程度。 5.1.5.2需方要对可交付的软件产品或服务进行验收评审和验收测试，当所有验收条件满足时，要从 共方接受它。验收规程宜符合5.1.1.9的规定。 1验定件产证

供方接受它。验收规程宜符合5.1.1.9的规定， 5.1.5.3验收之后，需方宜负责已交付软件产品的配置管理职责（见6.2）。

此项活动包括下述任务： 除了7.1.5中定义的正常项目管理结束活动，需方还要确保满足以下要求： a 付款的最终方式已协商一致，并已安排时间进度； b） 确认提供给供方的所有机密的信息是安全保密的； C 实现在所有相关方之间的获取信息交换； d）针对最初的要求和/或目标，评估获取项目在合同、项目、技术和财务方面的全部结果

此项活动包括下述任务： 5.1.7.1需方要确立需要.以在组织内部署通用获取政策。获取政策宜考虑通用的高层目标、基本的 获取需要和在获取项日中部署的方法，

5.1.7.2在定义有效的获取政策时，要考虑如下内容： a）1 优化获取所选择的技术、过程、方法、厂商、标准和合法的强制性法规或它们的基础； 6） 管理获取所需的资源、资质和技能，包括合同的、技术的、财务的、法律的以及项目管理技能； c 已定义的质重标准； d) 与供方、用户和其他受影响的各方之间的关系。

5. 1.8 管理供方关系

此项活动包括下述任务： 5.1.8.1组织内的获取职能机构要定义涉及供方全部关系的政策，这里的供方是指与组织当前的和将 来的需要相关的供方。总的目标就是根据服务和价值改善供方需方关系，以便就双方的要求达成共识。 5.1.8.2在一些合同情形下，国家政策有可能是不干涉供方的关系，但在许多领域，特别是随着电子采 购的出现，与供方的关系正向着战略伙伴的方向发展。

国家的或国际的来购法规和/或政策； b) 所有权和合作关系； 改善关系的潜在利益和不改善关系的相应风险； d）评审和监督供方关系的有效性，

5. 1. 9 管理用户关系

此项活动包括下述任务： 1.9.1组织内的获取职能机构要定义关于用户全部关系的政策，这里的用户是指与维 需要相关的用户。总的目标是根据服务和价值改善需方用户关系，以便就双方的要求 1.9.2要考虑下列内容作为定义的政策的一部分：

a）所有权和合作关系，

5. 1. 10 财务管理

此项活动包括下述任务： 5.1.10.1组织须确保对获取项目进行合理的财务管理。总的目标是确保按一致同意的计划和目标识 别和管理获取的成本和预算。财务管理常常在组织中的不同职能部门间划分不同的职责。 5.1.10.2为达到合理的财务管理，要完成以下活动 建立并维护财务计划和目标； b） 编制并批准预算； 维护记录； d) 向负责管理项目的人员提出项目支出的建议； e） 报告并分析计划支出和实际支出的差异； f） 采取决策以确保满足财务目标要求

a) 建立并维护财务计划和目标； b) 编制并批准预算； c) 维护记录； d) 向负责管理项目的人员提出项目支出的建议： e) 报告并分析计划支出和实际支出的差异： 采取决策以确保满足财务目标要求

供应过程包括供方的活动和任务。本过程可以按下述方式启动：或者决定编制投标书来答复需方 的招标书，或者与需方签订一项合同以提供系统、软件产品或软件服务。接着确定为管理和保证项目所 需的规程和资源，包括编制项目计划，执行计划，直到将系统、软件产品或软件服务交付给需方为止。 供方按照管理过程（7.1)在项目级上管理本条中具体说明的供应过程。按照基础设施过程（7.2）建 立本过程的基础设施。按照剪裁过程（附录A）为该项目剪裁本过程。按照改进过程（7.3）和人力资源 过程（7.4)在组织级上管理本过程、按资产管理过程（7.5）、重用大纲管理过程（7.6）和领域工程过程 （7.7)在项目级或组织级上开发、管理、重用本过程产生的或用于本过程的资产。

活动清单：本过程包括下述活动： a） 启动; b) 准备投标 c) 签订合同， d) 编制计划， e) 执行和控制； f) 评审和评价； g) 交付和完成。

活动清单：本过程包括下述活动： a) 启动： b) 准备投标 c) 签订合同， d) 编制计划， e) 执行和控制； f) 评审和评价； g 交付和完成。

此项活动包括下述任务： 5.2.1.1在考虑本组织的方针和其他规章后，供方研究或评审招标书中的需求。 5.2.1.2供方宜作出投标或接受合同的决定，

此项活动包括下述任务！

5. 2. 3签订合同

此项活动包括下述任务： 5.2.3.1供方宜与需方组织谈判并签订提供软件产品或服务的合同。 5.2.3.2作为变更控制机制一部分，供方可以要求修改合同

此项活动包括下述任务： 5.2.4.1供方应对获取需求进行评审，以确定一项框架来管理和保证项目，并保证可交付软件产品或 服务的质量。 5.2.4.2如果合同中没有规定，供方应确定或选择一个适合于该项目的范围、规模和复杂度的软件生 存周期模型，宜从本标准中选择过程、活动和任务，并将其映射到生存周期模型中。 5.2.4.3供方应建立计划需求，以便管理和保证该项目，并保证可交付软件产品或服务的质量。计划 需求宜包括需要的资源和需方的参与。 5.2.4.4一且建立了计划需求，供方应根据对每一种选择带来的风险进行分析，考虑开发软件产品或 提供软件服务的选择方案。选择方案包括： a） 利用内部资源开发软件产品或提供软件服务； b） 通过分包合同开发软件产品或提供软件服务； C） 从内部或外部资源获得现货软件产品； d） 以上a)、b)、c)项的组合。 5.2.4.5供方应根据计划需求和按5.2.4.4选择的方案，制订项目管理计划，并形成文档。计划中考 虑的项目包括但不限于如下： a 每一组织单元的项目组织结构、职责和职权，包括外部组织； b）工程环境（适用时，用于开发、运行或维护），包括测试环境、程序库、设备、设施、标准、规程和 工具； C 生存周期过程和活动的工作分解结构，包括要完成的软件产品、软件服务和非交付项以及预 算、人员配备、物理资源、软件规模和与任务有关的进度安排； d 软件产品或服务的质量特性的管理，可以制订独立的质量计划： e） 软件产品或服务的安全、安全保密性和其他关键需求的管理，可以制订独立的安全、安全保密 性计划；

5.2.4.5供方应根据计划需求

慧的项自包括但不限于如下： a）每一组织单元的项目组织结构、职责和职权，包括外部组织； b）工程环境（适用时，用于开发、运行或维护），包括测试环境、程序库、设备、设施、标准、规程和 工具； C 生存周期过程和活动的工作分解结构，包括要完成的软件产品、软件服务和非交付项以及预 算、人员配备、物理资源、软件规模和与任务有关的进度安排； d 软件产品或服务的质量特性的管理，可以制订独立的质量计划； e 软件产品或服务的安全、安全保密性和其他关键需求的管理，可以制订独立的安全、安全保密 性计划：

GB/T 8566—2007

f）分包方管理，当需要时包括分包方选择以及分包方与需方之间的参与； g）质量保证（见6.3） h 验证（见6.4)和确认（见6.5），如果有规定时，包括与验证机构和确认机构的接口方式； 需方参与：通过诸如联合评审（见6.6）、审核（见6.7）、非正式会议、报告、修改和变更、实施、批 准、验收以及使用设施等方法： 用户参与：通过需求的设定活动、原型演示和评价等方法； K 风险管理；即对涉及潜在的技术、成本和进度安排风险的项目区域的管理； 安全保密性方针：即在每一个项目组织级上需要知道的和可以访问的信息的准则： m） 诸如规章、所需的认证、专利权、使用权、所有权、担保权以及许可证授予权等方面所要求的 批准， 进度安排、追踪和报告的方法： 人员培训(见7.4)

分包方管理，当需要时包括分包方选择以及分包方与需方之间的参与； g） 质量保证（见6.3） h） 验证（见6.4)和确认（见6.5），如果有规定时，包括与验证机构和确认机构的接口方式； 需方参与：通过诸如联合评审（见6.6）、审核（见6.7）、非正式会议、报告、修改和变更、实施、批 准、验收以及使用设施等方法； 用户参与：通过需求的设定活动、原型演示和评价等方法； k 风险管理；即对涉及潜在的技术、成本和进度安排风险的项目区域的管理； 安全保密性方针：即在每一个项目组织级上需要知道的和可以访问的信息的准则； m） 诸如规章、所需的认证、专利权、使用权、所有权、担保权以及许可证授予权等方面所要求的 批准， 进度安排、追踪和报告的方法： Q 人员培训（见7.4)

5. 2. 5 执行和控制

此项活动包括下述任务！

a）按照开发过程（5.3）开发软件产品； b）按照运作过程（5.4）运行软件产品； c 按照维护过程（5.5）维护软件产品。 5.2.5.3供方应在合同确定的整个生存周期内监督和控制该项目的软件产品或服务的进度和质量。 这应是连续的、反复进行的任务，它应提供： a）监督技术性能、费用和日程的进展，并报告项自的状态； b）问题的标识、记录、分析和解决。 5.2.5.4供方应按照获取过程（5.1）管理和控制分包方。供方应传达所有必要的合同要求，以确保交 付给需方的软件产品或服务按照主合同要求进行开发或完成。 5.2.5.5供方应按合同和项目计划中的规定与独立的验证、确认或测试机构接触。 5.2.5.6供方应按合同和项目计划中的规定与其他各方接触

a）按照开发过程（5.3）开发软件产品； b）按照运作过程（5.4）运行软件产品； c）按照维护过程（5.5）维护软件产品。 5.2.5.3供方应在合同确定的整个生存周期内监督和控制该项目的软件产品或服务的进度和质量。 这应是连续的、反复进行的任务，它应提供： a）监督技术性能、费用和日程的进展，并报告项自的状态； b）问题的标识、记录、分析和解决。 5.2.5.4供方应按照获取过程（5.1）管理和控制分包方。供方应传达所有必要的合同要求，以确保交 付给需方的软件产品或服务按照主合同要求进行开发或完成。 5.2.5.5供方应按合同和项目计划中的规定与独立的验证、确认或测试机构接触。 5.2.5.6供方应按合同和项目计划中的规定与其他各方接触

5.2.6.1供方宜与需方组织协调合同评审活动、界面和沟通。 5.2.6.2供方应按合同和项目计划的规定与需方一起进行或支持非正式会议、验收评审、验收测试、联 合评审和审核。联合评审应按6.6实施，审核应按6.7实施。 5.2.6.3供方应分别按照6.4和6.5进行验证和确认，以证实软件产品或服务和过程完全满足各自的 需求。 5.2.6.41 供方应按合同中的规定，使需方能够得到评价、评审、审核、测试和解决问题的报告。 5.2.6.5供方应按合同和项目计划的规定，为了有效地进行软件产品或服务的评审，需方可以使用供 方和分包方的设施。 5.2.6.6供方应按6.3开展质量保证活动。

5.2.7.1供方应按合同中的规定交付软件产品或服务。 5.2.7.2供方应按合同中的规定，在所交付的软件产品或服务的支持中协助需方。

5.2.7.1供方应按合同中的规定交付软件产品或服务。

开发过程包括开发方的活动和任务。该过程包括需求分析、设计、编码、集成、测试和与软件产品有 的安装和验收等活动。如果合同中有规定，它可以包括和系统有关的活动。开发方按照合同执行或 持这种过程中的活动： 开发方按照管理过程（7.1)在项目级上管理本条中具体说明的开发过程。按照基础设施过程（7.2） 立本过程的基础设施；按照剪裁过程（附录A）为该项目剪裁本过程；按照改进过程（7.3）和人力资源 程（7.4)在组织级上管理本过程；资产管理过程（7.5）、重用大纲管理过程（7.6和领域工程过程（7.7） 项目级或组织级上开发、管理、重用本过程产生的或用于本过程的资产。 当开发方是所开发的软件产品的供方时，开发方要执行供应过程（5.2）。 活动清单：本过程包括下述活动： a）过程实施； b） 系统需求分析， c） 系统体系结构设计： d） 软件需求分析， e 软件体系结构设计； f） 软件详细设计： &） 软件综码和测试； h） 软件集成； 软件合格性测试； 系统集成； k 系统合格性测试； 软件安装； m) 软件验收支持，

此项活动包括下述任务： 5.3.1.1如果合同中没有规定，开发方应规定或选择适合于项目范围、规模和复杂度的软件生存周期 模型。应选择本标准的开发过程的活动和任务，并将其映射到生存周期模型。 注：这些活动和任务可以重叠或相互作用，并且可以重复或循环地进行，

模型。应选择本标准的开发过程的活动和任务，并将其映射到生存周期模型。 注：这些活动和任务可以重叠或相互作用，并且可以重复或循环地进行。 5.3.1.2开发方应： & 按照文档编制过程（6.1）将输出形成文档： b 将输出置于配暨管理过程（6.2）之下，并按照配置管理的要求进行变更控制； C） 按照问题解决过程（6.8），文档化并解决在软件产品和任务中发现的问题和不符合项； d） 按合同规定实施支持过程（第6章）； e） 适当时按需方和供方确定的要求为每个配置项建立基线。 5.3.1.3开发方应选择、剪裁和使用那些已形成文档的、恰当的、并由执行开发过程和支持过程（第6章） 的活动的组织建立的标准、方法、工具和计算机编程语言（如果合同没有限定）。 5.3.1.4开发方应为实施开发过程的活动制定开发计划。该计划应包括与包括安全、安全保密性在内 的所有需求的开发、合格性认定相关的特定标准、方法、工具、措施和职责。如果必要，可以制订一些独 立的计划，这些计划应形成文档并得到执行。 5.3.1.5非交付项可用于软件产品的开发或维护。但应确保可交付软件产品在交付给需方后，它的运 行和维护独立于非交付项。否则，这些非交付项应被考虑为可交付的。

5.3.1.2开发方应

5.3.2系统需求分析

下列任务组成，开发方应按照合同要求执行

5.3.2.1应分析待开发系统的特定的预期使用要求，以规定系统需求。系统需求规格说明应描述：系 统的功能与能力；业务、组织和用户的需求；安全、安全保密性、人因工程（人机工程学）、接口、运行和维 护需求；设计约束和合格性带求。系统需求规格说明应形成文档

a）获取需要的可追踪性： b） 获取需要的一致性； c) 可测试性： d) 系统体系结构设计的可行性； e）运行和维护的可行性。

a）获取需要的可追踪性 b） 获取需要的一致性； 可测试性： d) 系统体系结构设计的可行性： e）运行和维护的可行性。

5.3.3系统体系结构设讯

此项活动由下列任务组成，开发方应按合同要求执行或支持这些任务。 5.3.3.1应建立系统的顶层体系结构。该体系结构应标识硬件、软件和人工操作项。应确保所有系统 需求都被分配到各项中。然后应从这些项中标识出硬件配置项、软件配置项和手工操作项。分配到各 项中的系统体系结构和系统需求应形成文档。

a) 系统需求的可追踪性： b) 与系统需求的一致性； c) 所使用的设计标准和方法的适宜性： d) 软件项满足其分配需求的可行性； 运行与维护的可行性，

5.3.4软件盘求分析

对于每一个软件项（或软件配置项，如巢已标识），此项活动由下述任务组成： 3.4.1开发方应建立软件需求（包括质量特性规格说明）并形成文档。软件质量特性规定见 /T16260.1。软件需求包括： a）功能与能力规格说明，包括性能、物理特性和软件项执行的环境条件； b） 软件项的外部接口， 合格性需求； d） 安全规格说明，包括那些与运行、维护相关的方法、环境影响和人为损坏； 安全保密性规格说明，包括那些与敏感信息泄露相关的要求； 人因工程（人机工程学）规格说明，包括与人工操作、人机界面、对人员的约束、需要人员集中注 意力的区域（这些区域对人为差错和培训是敏感的）等有关的要求； 数据定义和数据库需求； h) 在运行和维护场所安装与验收已交付的软件产品的需求； i） 用户文档； j） 用户操作与执行需求： k 用户维护需求。 .4.2开发方应根据下列评价准则评价软件需求。评价结果应形成文档： 系统需求和系统设计的可追踪性； b） 与系统需求的外部一致性： c） 内部一致性： 可测试性： e） 软件设计的可行性 f) 运行和维护的可行性

GB/T8566—2007

5.3.4.3开发方应按照6.6实施联合证

3开发方应按照6.6实施联合评审

5.3.5软件体系结构设讯

对于每一个软件项（或软件配置项，如果已标识），此项活动由下列任务组成： 5.3.5.1开发方应把软件项的需求转变为一种体系结构，该体系结构描述其顶层结构并标识各个软件 部件。应确保软件项的所有需求都被分配给了其软件部件，并得到进一步的细化以便于进行详细设计。 软件项的体系结构应形成文档。

对于每一个软件项（或软件配暨项，如果已标识），此项活动由下列任务组成： 5.3.5.1开发方应把软件项的需求转变为一种体系结构，该体系结构描述其顶层结构并标识各个软件 部件。应确保软件项的所有需求都被分配给了其软件部件，并得到进一步的细化以便于进行详细设计。 软件项的体系结构应形成文档。 5.3.5.2开发方应开发关于软件项的外部接口以及软件项的各个软件部件间的接口的顶层设计，并形 成文档。 5.3.5.3开发方应编制数据库的项层设计，并形成文档。 5.3.5.4开发方宜编制用户文档的最初版本，并形成文档。 5.3.5.5开发方应确定软件集成的初步测试需求和进度安排，并形成文档。 5.3.5.6开发方应根据下列评价准则评价软件项的体系结构、接口和数据库设计，评价结果应形成 文档： a） 软件项需求的可追踪性； b） 与软件项需求的外部一致性； 软件部件之间的内部一致性； 所应用的设计方法和标准的适宜性； 详细设计的可行性； 运行与维护的可行性

5.3.5.7开发方应按照6.6实施联合评

7开发方应按照6.6实施联合评审。

5.3.6软件详细设计

对于每一个软件项（或软件配置项，如果已标识），此项活动由下述任务组成： .3.6.1开发方应对软件项的每一软件部件进行详细设计。软件部件应细化到更低级别，这些级别 含能被编码、编译、测试的软件单元。应确保来自这些软件部件的所有软件项需求都被分配到软件 元。详细设计应形成文档。 5.3.6.2开发方应开发关于软件项外部接口，软件部件之间以及软件单元之间的接口的详细设计， 等其形成文档。接口的详细设计应允许在不需要更多信息的情况下进行编码。 5.3.6.3开发方应编制数据库的详细设计并形成文档。 5.3.6.4必要时，开发方应更新用户文档。 5.3.6.5开发方应规定要测试的软件单元的测试需求和进度安排，并将其形成文档。测试需求宜包 对软件单元在需求边界的强化要求。 5.3.6.6开发方应更新软件集成的测试需求和进度安排。 5.3.6.7开发方应根据下列评价准则评价软件详细设计和测试需求，评价结果应形成文档： a） 软件项带求的可追踪性； 与结构设计的外部一致性： 软件部件和软件单元之间的内部一致性； 所应用的设计方法和标准的适宜性 e） 测试的可行性； f 运行与维护的可行性。 3.6.8开发方应按照66实施联合评审

对于每一个软件项（或软件配置项，如果已标识），此项活动由下述任务组成： 5.3.6.1开发方应对软件项的每一软件部件进行详细设计。软件部件应细化到更低级别航天标准，这些级别包 含能被编码、编译、测试的软件单元。应确保来自这些软件部件的所有软件项需求都被分配到软件单 元。详细设计应形成文档。

5.3.7软件继码和测试

对于每一个软件项（或软件配置项，如果已标识），此项活动由下述任务组成： 7.1开发方应开发下列各项并形成文档：

a） 每一个软件单元和数据库； b） 用于测试每一个软件单元和数据库的测试规程和数据。 3.7.2开发方应测试每个软件单元和数据库，以确保满足需求。测试结果应形成文档。 3.7.3 必要时，开发方应及时更新用户文档。 3.7.4 开发方应及时更新测试需求和软件集成进度安排。 B.7.5 开发方应根据下列准则评价软件编码和测试结果，评价结果应形成文档： 软件项需求和设计的可追踪性； b) 与软件项的需求及设计的外部一致性； c） 单元需求之间的内部一致性： 单元的测试覆盖率； e) 所应用的编码方法和标准的适宜性， f) 软件集成与测试的可行性； 运行与维护的可行性。

a）每一个软件单元和数据库；

建材标准软件项需求和设计的可追踪性； b) 与软件项的需求及设计的外部一致性 c) 单元需求之间的内部一致性. d) 单元的测试覆盖率； 所应用的编码方法和标准的适宜性！ f) 软件集成与测试的可行性： 运行与维护的可行性。