本文件使用良好定义的术语，为软件生存周期过程建立了一个公共框架，以供软件产业界引用。该框架包含过程、活动和任务，可用于软件系统、产品和服务的获取、供应、开发、运行、维护或处置期间。这些生存周期过程是通过所有与系统有关的各方参与，以实现顾客满意为最终目标来完成的。　　 本文件适用于软件系统、产品和服务，以及任何系统中的软件部分的获取、供应、开发、运行、维护和处置（无论在组织内部还是外部执行）。软件包括固件的软件部分，还包括为软件产品和服务提供环境所需的系统定义那些部分。 本文件还提供了可用于一个组织或一个项目内来定义、控制和改进软件生存周期过程的过程。

ICS.35.080
cCs L:7
中华人民共和国国家标准
GB/T8566——2022/ISO/IEC/IEEE12207:2017代替GB/T8566—2007
系统与软件工程
软件生存周期过程
Systems and software engineeringSoftware life cycle processes(ISO/IEC/IEEE12207:2017,IDT)2022-10-12发布
国家市场监督管理总局
国家标准化管理委员会
2023-05-01实施
1范围
应用领域
2规范性引用文件
3术语和定义、缩略语
3.1术语和定义
3.2缩略语
4符合性..
预期用法.
4..2完全符合.
4.3剪裁符合
关键概念和应用..
软件系统概念.
组织和项目概念
生存周期概念
过程概念
过程组，
过程应用..
过程参考模型.
软件生存周期过程
协定过程组
组织的项目使能过程组
技术管理过程组
6.4技术过程组
附录A（规范性）剪裁过程
附录B（资料性）过程信息项示例，目
附录C（资料性）用于评估目的的过程参考模型附录D（资料性）过程集成和过程构建..附录E（资料性）过程视图
附录F（资料性）软件系统架构建模GB/T 8566—2022/ISO/IEC/IEEE12207:2017次
GB/T8566—2022/ISO/IEC/IEEE12207:2017附录G（资料性）将软件生存周期过程应用于系统之系统附录H（资料性）敏捷的应用
附录NA（资料性）本文件与GB/T8566一2007的差异参考文献
GB/T85662022/ISO/IEC/IEEE12207:2017前言
本文件按照GB/T1.1一2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定起草。
本文件与GB/T22032一2021《系统与软件工程系统生存周期过程》共同构成了软件与系统工程领域的基础性标准。
本文件代替GB/T8566一2007《信息技术软件生存周期过程》。与GB/T8566一2007相比，除结构调整和编辑性改动外，主要技术变化如下：一一术语和定义做了调整和补充（见第3章，2007年版的第3章）；一软件生存周期过程模型作了重大调整和变化(详见附录NA)。本文件等同采用ISO/IEC/IEEE12207:2017《系统与软件工程软件生存周期过程》。本文件做了下列最小限度的编辑性改动：删除附录I（资料性）与ISO/IEC/IEEE12207:2008的过程映射，本文件代替的2007版本采用ISO/IEC12207:1995,本文件米用ISO/IEC/IEEE12207:2017ISO/IEC/IEEE12207:2008
为中间版本，对国家标准没有意义，并不涉及技术内容的变更；一增加了附录NA（资料性）。
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。本文件由全国信息技术标准化技术委员会(SAC/TC28)提出并归口。本文件起草单位：浙江省电子信息产品检验研究院、中国电子技术标准化研究院、江苏赛西科技发展有限公司、深圳赛西信息技术有限公司、中国电子科技集团公司第五十四研究所、北京航天自动控制研究所、浙江中控技术股份有限公司、中国航发商用航空发动机有限责任公司、山东山科数字经济研究院有限公司、中国航天系统科学与工程研究院、北京软件和信息服务交易所有限公司、上海宝信软件股份有限公司、大连理工大学、中国电子科技集团公司第十研究所、山东省计算中心（国家超级计算济南中心）、广东益安人防工程科技有限公司、上海计算机软件技术开发中心、北京赛迪认证中心有限公司、成都四方伟业软件股份有限公司、山东正中信息技术股份有限公司、北京华宇软件股份有限公司、上海市软件评测中心有限公司。
本文件主要起草人：张君、张旸旸、季永炜、李文鹏、孙纪敏、赵浩强、郭晓慧、刘永召、祝钦、李刚、杨桂枝、于铁强、张星星、黄钰梅、宋明秋、董李梅、赫畅、孙金洋、王公韬、马烈、胡芸、颜怀柏、宋丽华、祁雨奇、庄园、王春晓、董冠涛、米坤、孟艳、李艳、韩德隆、李敏。本文件及其所代替文件的历次版本发布情况为：—1988年首次发布为GB/T8566—1988《计算机软件开发规范》；—一1992年第一次修订为GB/T856一1992《信息技术软件生存期过程》；-2001年第二次修订为GB/T8566—2001《信息技术软件生存周期过程》，2007年第三次修订；
本次为第四次修订。
GB/T85662022/ISO/IEC/IEEE
12207:2017
软件系统的复杂性已经增加到前所未有的程度。这为创建和使用系统的组织带来了新的机遇，但也带来了更多的挑战，这些挑战存在于软件系统的整个生存周期以及架构层次上的所有细节。本文件提供了一个公共过程框架，以便采用软件工程方法描述人工创建的系统生存周期。软件工程是成功实现软件系统的一种跨学科方法和手段，它关注定义利益相关方的需要以及开发周期之前所要求的功能，它关注建立需求文档，它关注执行设计集成和系统验证，同时也考虑全局性的问题。软件工程将所有的规程和专业组集成到一个团队工作中，形成一个从概念到生产、到操作、到维护的结构化开发过程，同时也考虑全部利益相关方的业务和技术需要，以提供满足用户和其他利益相关方要求的高质量产品为目标。该生存周期跨越了从概念到系统退役的整个过程，为系统的获取和供应，提供了相应的过程，同时也有助于改进创建、使用和管理现代软件系统各方之间的沟通和合作，使它们可以按一种集成化的、高内聚的模式工作。该框架还提供了对生存周期过程的评估和改进。本文件中的过程形成了一个全面的集合，组织可从中构建适合其产品和服务的软件生存周期模型，根据组织目的，可选择并应用一个适当的子集来实现该目的。本文件可在下列一种或多种模式下使用a）组织使用二二帮助建立所需过程的环境。这些过程可由方法、过程、技术、工具和经过培训的人员组成基础结构来支持。然后组织可使用上述环境来执行和管理自身的项目，并通过它们的生存周期阶段来开发软件系统。在这种模式下，本文件用于评估已声明的、已建立的环境是否符合其规定
b）项目使用二二帮助选择、构建和使用一个已建立的环境元素来提供产品和服务。在这种模式下，本文件用于评估项目是否符合已声明和已建立的环境。需方和供方使用一一帮助制定关于过程和活动的协议。通过该协议，本文件中的过程和活动c）
被选定、协商、同意和执行。在这种模式下，本文件用于指导协议的制定。d）过程评估者使用一一作为过程参考模型，用于过程评估的绩效，以支持组织的过程改进考虑到软件和系统范围的区别，本文件中的软件生存周期过程模型中的“特定项目包管理过程”与GB/T22302一2021系统生存周期过程模型中的“项目群管理过程”指的是同一过程，但在表述上存在差异。
1范围
1.1概述
GB/T8566—2022/ISO/IEC/IEEE12207:2017系统与软件工程软件生存周期过程本文件使用良好定义的术语，为软件生存周期过程建立了一个公共框架，以供软件产业界引用。该框架包含过程、活动和任务，可用于软件系统、产品和服务的获取、供应、开发、运行、维护或处置期间。这些生存周期过程是通过所有与系统有关的各方参与，以实现顾客满意为最终目标来完成的。本文件适用于软件系统、产品和服务，以及任何系统中的软件部分的获取、供应、开发、运行、维护和处置（无论在组织内部还是外部执行）。软件包括固件的软件部分，还包括为软件产品和服务提供环境所需的系统定义那些部分。
本文件还提供了可用于一个组织或一个项目内来定义、控制和改进软件生存周期过程的过程。本文件中的过程、活动和任务还可应用于一个包含软件的系统的获取期间，其中，既可以单独使用，也可以和GB/T22032—2021结合使用。GB/T22032一2021主要关注那些很少使用或不使用软件的人造系统，与GB/T22032-2021的使用环境相比，本文件主要关注的是一个连续统一体的软件人造系统。现实中，很少遇见一个没有软件的复杂系统，且所有软件系统均需通过物理系统的部件（硬件）来运行，或只作为关注焦点的软件系统的部分，或只作为一个使能系统或基础设施。因此，是否把本文件应用于软件生存周期，还是把GB/T22032-2021应用于软件生存周期，这一选择依赖于所关注的系统。两个标准中的过程具有相同的过程目的和过程输出，但是分别在执行软件工程或系统工程的活动和任务中有所不同。1．2自的
本文件的目标是在系统生存周期中提供一个已定义过程集合，来促进需方、供方和其他利益相关方之间的沟通。
本文件适用于软件系统、产品和服务的需方、供方、开发方、集成方、操作方、维护方、管理者、质量保证管理者和用户。它既可由单方作为自我改进工作采用，也可用于多方的情况。各方可来自于同一个组织，也可来自不同的组织，各方之间的关系可以是非正式合同或正式合同。本文件的过程可用于作为创建业务环境（例如，方法、规程、技术、工具和专业人员)的基础。附录A规定了对这些软件生存周期过程进行剪裁的规范性要求。1.3应用领域
本文件应用于完整的软件系统、产品和服务的生存周期，包括概念、开发、生产、使用、支持和退役，同时也应用于它们的获取和供应，无论是在组织内部还是外部运行。本文件定义的生存周期过程可同时地、迭代地、递归地应用于软件系统，也可递增地应用于软件系统元素。在软件系统的目的、应用领域、复杂性、规模、新颖性、适应性、数量、位置、生存时间与演进等方面，软件系统是千差万别的。本文件描述了包含人工软件系统的生存周期过程。因此，它既可应用于单件生产、面向广泛的商业或公共发行，以及可定制可适应的软件系统，也可应用于完整的单机软件系统和可嵌入/集成为更大更复杂的完整系统中的软件系统。本文件提供了根据过程目的和过程输出特征而展现的过程参考模型，而过程目的和过程输出来源于活动和任务的成功执行。附录B列出了与不同过程相关工作产品和信息项的例子。因此本文件作1
GB/T 8566—2022/ISO/IEC/IEEE 12207:2017为参考模型，用于支持过程评估（参见IS0/IEC33002:2015）。附录C提供了作为过程参考模型和关于软件生存周期使用的信息。附录D描述了使用过程参考模型的过程结构。1.4限制
本文件并不规定具体的软件生存周期模型、开发方法学、方法、建模方法或者技术。本文件的用户负责选择项目的生存周期模型，并把本文件的过程、活动和任务映射到模型。各方也可选择和应用适合该项目的合适的方法学、方法、模型和技术。本文件没有建立管理体系，也未要求使用任何管理体系标准。然而还是期望与GB/T19001规定的质量管理体系、ISO/IEC20000-1(IEEEstd20000-1)规定的服务管理体系以及GB/T29246规定的信息安全管理体系兼容。
本文件没有详述关于命名、格式、明确内容、记录媒介的信息项。生存周期过程信息项(文档)内容参见ISO/IEC/IEEE15289。
2规范性引用文件
本文件没有规范性引用文件。
3术语和定义、缩略语
3.1术语和定义
下列术语和定义适用于本文件
需方acquirer
从供方获得或采购某一产品或服务的利益相关方。注：需方的同义术语，常用的有买方、顾客、所有者、购买者或内部/组织赞助方。3.1.2
获取acquisition
获得某一系统、产品或服务的过程。3.1.3
活动activity
某一过程中高内聚的任务集合。3.1.4
敏捷开发agiledevelopment
以迭代开发、频繁检查和调整、增量交付为手段，依靠跨功能团队协同和持续与利益相关方沟通反馈促进需求和解决方案不断演进的软件开发方法，［来源：ISO/IEC/IEEE
协定 agreement
26515:20111
据以维持工作关系并得到相互确认的条款与条件。示例：合同，协定备忘录
架构　architecture
体系结构
（系统)在其环境中的一些基本概念或性质，体现在其元素、关系，以及设计与演进原则中。2
[来源：ISO/IEC/IEEE
42010:2011,3.21
架构框架architectureframework体系结构框架
GB/T85662022/ISO/IEC/IEEE12207:2017在特定应用领域和/或利益相关方的团体中，为描述架构所建立的约定、原理和实践。示例1:GB/T18757中的通用企业参考架构、方法论(GERAM)是一种架构框架。示例2:ISO/IEC10746开放分布式处理参考模型(RM-ODP)是一种架构框架［来源：ISO/IEC/IEEE
42010:2011,3.4
架构视图architectureview
从特定系统关注的视角来表达某一系统架构的工作产品。[来源：ISO/IEC/IEEE
42010:2011,3.5]
架构视角architectureviewpoint为架构视图的构造、解释和使用，建立约定的工作产品，以便构建特定系统的关注焦点。［来源：ISO/IEC/IEEE
审核audit
42010:2011,3.6]
为评估工作产品或工作产品集是否符合规范、标准、合同协定或其他准则而进行的独立检查。[来源：GB/T11457—2006,3.213]3.1.11
基线baseline
经正式批准的配置项。它与媒介无关，是在该配置项的生存周期中的特定时间节点确定并固化的。［来源：IEEEStd828—2012,2.1]3.1.12
业务过程businessprocess
为了达到某种期望的最终结果，从而实现组织的既定目标，可执行的部分有序的企业活动的集合。3.1.13
运营观念
conceptofoperations
对于某一组织的一项或一系列行动的设想或意图，以文字和/或图形做出的概略表述。注1：运营观念通常在长远战略规划和年度运营计划中得到体现。在年度运营计划中，运营观念覆盖同时或相继进行的一系列相关行动。运营观念旨在描述组织运行的整体图景。参见3.1.28运行概念。注2：运营观念为提供确定运行空间、系统能力、界面和运行环境边界的基础。[来源：ANSI/AIAAG-043A—2012e,5.2]3.1.14
关注焦点concern
（系统）一个或多个利益相关方对某一系统的利益所在。注：关注焦点涉及对某一系统在其环境方面的各种影响，包括开发的、技术的、业务的、运行的、组织的、政策的、经济的、法律的、监管的、生态的以及社会的影响。[来源：ISO/IEC/IEEE42010:2011,3.7]3.1.15
配置项configurationitem
技术状态项
为了进行配置管理而指定的，在配置管理的过程中作为单个实体对待的硬件、软件或软硬件综合项GB/T8566—2022/ISO/IEC/IEEE12207:2017或聚合体。
示例：软件、固件、数据、硬件、人员、过程(如，为用户提供服务的过程)、程序(如，操作说明和用户手册)、设施、服务、材料和自然存在的实体。
[来源：ISO/IEC/IEEE
顾客customer
24765:2010,3.563]
接受某项产品或服务的组织或个人。示例：消费者、客户、用户、需方、买方或购买者。注：顾客可以是组织内部的或外部的。3.1.17
设计(动词）design
(过程)界定架构、系统元素、接口，以及某一系统或系统元素的其他特性。［来源：ISO/IEC/IEEE
设计（名词）design
设计(3.1.17)过程的结果，
24765:2010.3.800.有修改
注1：信息，包括系统元素及其相互关系的规范，充分完备足以支持架构兼容实现的信息注2：设计提供了系统元素的详细的实现级的物理结构、行为、时间关系和的其他属性。3.1.19
设计特性design characteristic属于一个产品或服务的可测量描述的设计属性或特有性质。3.1.20
使能系统 enabling system
对所关注的系统在其生存周期阶段提供支持，但在其运行期间不必直接发挥功用的系统，示例：在软件开发期间用于控制软件元素的配置管理系统。注：每一个使能系统都有自己的生存周期。当使能系统为了其自身的需要也被作为所关注的系统对待时，本文件同样适用于它们。
环境environment
(系统)决定对一个系统的所有影响的设置和情势的周境。［来源：ISO/IEC/IEEE
设施facility
42010:2011,3.8]
促进行动执行的物理手段或设备，例如厂房、仪器、工具。3.1.23
偶发事件incident
项目、产品、服务或系统在其生存周期中任意时刻发生的异常、意外事件或者事件、条件、情况的集合。3.1.24
信息项information item
信息产品informationproduct
供人们使用而制作、存储和交付的可单独识别的信息体。［来源：ISO/IEC/IEEE
基础设施infrastructure
15289:2015,3.1.12]
支持计算机系统与软件的设计、开发和改进的硬件和软件环境。3.1.26
生存周期lifecycle
GB/T85662022/ISO/IEC/IEEE12207:2017系统、产品、服务、项目或其他人工实体从概念到退役的演变3.1.27
生存周期模型lifecyclemodel
与生存周期相关的过程和活动的框架，可以组织成多个阶段，也可作为交流和理解的通用参考。3.1.28
operational concept
运行概念
对于一个组织的，关于一个系统或一组相关系统的运行或一系列运行的，设想或意图的文字和图形化表述。
注：运行概念使用一个或多个特定系统或与一组相关的系统，从用户和操作者角度，给出运行的整体描述。参见运营观念(3.1.13)。
[来源：ANSI/AIAA
操作方operator
操作员
G-043A-2012e,5.2]
执行系统操作的个人或组织。
注1：操作者和用户的角色可被同时或顺序授予同一个人或组织。注2：与知识、技能和规程为一体的操作者都可以被认为是系统的一个元素。注3：操作者可根据操作指令是否在系统边界内来对系统进行不同的操作。3.1.30
组织organization
职责、权限和相互关系得到安排的一组人员及设施。示例：公司、集团、商行、企事业单位、研究机构、慈善机构、代理商、社团或上述组织的部分或组合。注：指定组织的一部分(小到只有一个人)或者指定的组织团体，只要具有职责、权限和相互关系，都可以被当做组织。为了特定目的而组织起来的一部分人也是组织，如俱乐部、联盟、公司、社团。3.1.31
当事方party
达成协定的组织。
注：在本文件中，协定的当事方分别称为需方和供方。3.1.32
问题problem
需要探究并采取纠正措施的困境、不确定性，或其他已认识的和不期望的事件、事件集、条件或状况。
过程process
组将输入转化为输出的相互关联或相互作用的活动。3.1.34
过程输出process outcome
成功达到过程目的、可观察的结果。3.1.35
过程自的
processpurpose
执行过程的高层次的目标，过程有效实施的可能输出。注：执行过程的目的是为利益相关方提供权益。5
GB/T85662022/ISO/IEC/IEEE12207:20173.1.36
产品product
过程的结果。
注：有四种被认可的通用产品类别：硬件(如发动机机械零件)、软件(如计算机程序，以及可能有关的文件和资料)、服务（如运输）和流程性材料（如润滑剂D。硬件和流程性材料通常是有形的产品，而软件和服务通常是无形的3.1.37
项目project
按照明确的开始和结束准则，依据给定的资源和需求创建产品或服务的努力。注：项目可看作是包含协作和受控活动的独特过程，可由本文件中定义的来自技术管理过程组和技术过程组的活动组成。
(项目>特定项目包portfolio
专注于组织的战略目标的项目的集合。注：GB/T220322021中使用“项目群”。3.1.39
资质qualification
证明实体是否有能力满足规定要求的过程。3.1.40
质量保证
qualityassurance
质量保障
质量管理的一部分，致力于提供质量要求会得到满足的置信度（统计上的可信程度）。［来源：GB/T190002016,3.3.6,有修改]3.1.41
质量特性quality characteristic与要求有关的，产品、过程或系统的固有属性。注：严格意义上的质量特性通常包括与健康、安全性、信息安全保证、可靠性、可用性和支持性相关的内容。3.1.42
质量管理qualitymanagement
在质量方面指挥和控制组织的协调的活动。3.1.43
发布release
用于特定目的的可用配置项的特定版本。示例：测试发布
需求requirement
对需要及其约束和条件的表达bzxZ.net
［来源：ISO/IEC/IEEE
资源resource
29148:2018,3.1.19,有修改
过程执行期间使用或消耗的资产。注：资源包括可循环使用、可再生的或消耗品。示例：不同的实体，如资金、人力、设施、固定设备、工具和公共设施；如电力、水力、燃料和通信基础设施。o
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。