搜索结果: GB/T 22032-2021, GB/T22032-2021, GBT 22032-2021, GBT22032-2021
| 标准编号 | GB/T 22032-2021 (GB/T22032-2021) | | 中文名称 | | | 英文名称 | Systems and software engineering - System life cycle processes | | 行业 | 国家标准 (推荐) | | 中标分类 | L77 | | 字数估计 | 98,915 | | 发布机构 | 国家市场监督管理总局、中国国家标准化管理委员会 | GB/T 22032-2021
Systems and software engineering - System life cycle processes
ICS 35.080
L77
中华人民共和国国家标准
代替GB/T 22032-2008
系统与软件工程 系统生存周期过程
(ISO/IEC/IEEE15288:2015,IDT)
2021-04-30发布
2021-11-01实施
国 家 市 场 监 督 管 理 总 局
国 家 标 准 化 管 理 委 员 会 发 布
目次
前言 Ⅲ
引言 Ⅴ
1 概述 1
1.1 范围 1
1.2 目的 1
1.3 应用领域 1
1.4 限制 1
2 符合性 2
2.1 预期用法 2
2.2 完全符合 2
2.3 剪裁符合 3
3 规范性引用文件 3
4 术语、定义和缩略语 3
4.1 术语和定义 3
4.2 缩略语 9
5 本标准的关键概念和应用 9
5.1 概述 9
5.2 系统的概念 9
5.3 组织和项目的概念 11
5.4 生存周期的概念 12
5.5 过程的概念 13
5.6 本标准中的过程 13
5.7 过程的应用 15
5.8 过程参考模型 16
6 系统生存周期过程 16
6.1 协定过程组 16
6.2 组织的项目使能过程组 19
6.3 技术管理过程组 25
6.4 技术过程组 37
附录A(规范性附录) 剪裁过程 66
附录B(资料性附录) 过程信息项示例 68
附录C(资料性附录) 用于评估目的的过程参考模型 71
附录D(资料性附录) 过程集成与过程构建 73
附录E(资料性附录) 过程视图 75
附录F(资料性附录) 架构建模 80
附录G(资料性附录) 系统生存周期过程在SoS中的应用 82
附录NA(资料性附录) 新旧标准结构对比 85
参考文献 88
系统与软件工程 系统生存周期过程
1 概述
1.1 范围
本标准为描述人工系统的生存周期建立了一个通用框架,从工程的角度定义了一组过程及相关的
术语。这些过程可以应用于系统结构的各个层次。在整个生存周期中,被选定的过程集合可应用于管
理、运行系统生存周期的各个阶段。这是通过所有与系统有关的各方参与,以实现顾客满意为最终目标
来完成的。
本标准还提供了一些过程,支持用于组织或项目中生存周期过程的定义、控制和改进。当获取和供
应系统时,组织和项目可使用这些生存周期过程。
本标准涉及一个或多个可由以下元素配置的人工系统:硬件、软件、数据、人员、过程(例如给用户提
供服务的过程)、规程(例如操作指南)、设施、物资和自然存在的实体。
当系统元素是软件时,ISO/IEC/IEEE12207:2015可以用于实现此系统元素。两个标准互相协
调,可以在单个项目或单个组织中同时使用。
1.2 目的
本标准的目标是在系统生存周期中提供一个已定义过程集合,来促进需方、供方和其他利益相关方
之间的交流。
本标准适用于作为需方和供方的组织。它既可由单方作为自我改进工作采用,也可用于多方的情
况。各方可以来自同一个组织,也可来自不同的组织,各方之间的关系可以是非正式协定到正式的
合同。
本标准的过程可用于作为创建业务环境(例如方法、规程、技术、工具和专业人员)的基础。对这些
系统生存周期过程进行剪裁的规范性要求见附录A。
1.3 应用领域
本标准应用于完整的系统生存周期,包括系统的概念、开发、生产、使用、保障和退役,同时也应用于
系统的获取和供应,无论是在组织内部还是外部运行。本标准的生存周期过程可同时地、迭代地、递归
地应用于系统,也可递增地应用于系统元素。
在系统的目的、应用领域、复杂性、规模、新颖性、适应性、数量、位置、生存时间与演变等方面,系统
是千差万别的。本标准描述了包含人工系统的生存周期过程。它既可应用于单件生产、量产或可定制
可适应的系统,也可应用于完整的单机系统或可嵌入/集成为更大、更复杂的完整系统中的系统。
本标准提供了根据过程目的和过程输出特性的过程参考模型,而过程目的和过程输出来源于活动
和任务的成功执行。与不同过程相关制品和信息项的例子参见附录B。本标准作为参考模型,用于支
持过程评估(参见ISO/IEC 15504-2:2003)。作为过程参考模型和关于系统生存周期使用的信息参见
附录C。使用过程参考模型的过程结构参见附录D。
1.4 限制
本标准并不规定具体的系统周期模型、开发方法学、方法、模型或者技术。
本标准的用户负责选择项目的生存周期模型,把本标准的过程、活动和任务映射到模型。用户也负
责选择和应用合适的方法学、方法、模型和适合项目的技术。
尽管本标准并没有设置管理体系,但它与ISO 19001规定的质量管理体系、ISO/IEC 20000-1:
2011(IEEEStd20000-1-2013)规定的服务管理体系、ISO/IEC 27000规定的信息安全保密管理体系
相兼容。
本标准没有详述关于命名、格式、明确内容、记录介质的信息项。生存周期过程信息项内容参见
ISO/IEC/IEEE15289。
2 符合性
2.1 预期用法
本标准的要求包含在第6章和附录A中。在系统或产品生存周期过程中,本标准为一些适合使用
的过程提供了要求。特殊的项目或组织或许不需要使用本标准提供的所有过程。因此,本标准的实施
通常涉及选择和声明适合此组织或项目的过程集合。有两种方法可以声明符合本标准规定,即完全符
合和剪裁符合。
有两种准则来声明完全符合。尽管所选择的准则(或原则)是在声明中陈述的,但达到这两种准则
都足以满足符合性要求。声明任务的完全符合表明已获得所有被声明过程集合的活动和任务的要求。
声明输出的完全符合表明已获得被声明过程集合所需要的所有输出的要求。输出的完全符合允许在执
行符合性过程时有更大的自由度,在执行用于创新生存周期模型的过程中可能有用。
注1:符合的可选性提供了应用本标准时所需的灵活性。每个过程都有一组目标集(称为“输出”)和一组获得目标
的方式(称为“活动和任务”)。
注2:实现了声明的过程集的活动和任务的用户可以确定与所选过程的任务完全符合。但是,某些用户可能对过
程做了一定创新,可以在没有执行完所有活动和任务的前提下,实现了声明过程集的目标(即输出)。这些用
户可以确定与声明的过程集的输出完全符合。任务符合和输出符合这两种准则不一定等价,因为某些情况
下特定活动和任务的执行可能需要比达到输出符合更高的能力。
注3:当本标准用于促进供需双方之间的协定时,本标准的条款可结合或不做任何修改地被编入协定中。这种情
况下,需方和供方之间遵守协定比遵守本标准更适合。
注4:一个将本标准作为贸易条件的组织(例如:国家、行业协会、公司),可以指定并公开所需过程、输出、活动和任
务的最低限度,来对供方的权衡条件做承诺。
注5:本标准通过动词“应”的使用来标记要求,通过动词“宜”的使用来标记建议,通过动词“可”的使用来标记允
许。但尽管使用了这些标记动词,还需优先符合上述要求。
2.2 完全符合
2.2.1 输出完全符合
完全符合的声明给出了符合本标准的一组过程集合。通过证明已实现所声明的一组过程的所有输
出,实现了对输出的完全符合。在这种情况下,无论在此条款中为“应”“宜”还是“可”,对所声明的一组
过程的任务和活动的规定都是建议而不是要求。
注:本标准的一个预期用途是促进过程评估和提升。为了这个目的,每个过程的目标都以输出的形式写入兼容
ISO/IEC 15504-2和ISO/IEC 33002的规定中。这些标准提出了本标准过程的评估和提升的基础。想要过程
评估和提升的用户会使用写入本标准的过程输出,作为ISO/IEC 15504-2和ISO/IEC 33002所需的过程参考
模型。
2.2.2 任务完全符合
完全符合的声明给出了符合本标准的一组过程集合。通过证明已实现所声明的一组过程的所有活
动和任务的要求,实现了对任务的完全符合。在这种情况下,无论在此条款中为“应”“宜”还是“可”,对
所声明的一组过程的输出的规定都是建议而不是要求。
注:在需方或监管机构要求详细了解供应过程的规定情境(法律意义上的合同或契约约定)下,声明为任务完全符
合是比较适合的。
2.3 剪裁符合
当以本标准为基础建立的过程集不足以满足完全符合的要求时,需要符合附录A中规定的剪裁过
程对本标准的条款进行选择或修改,并给出剪裁符合的声明。通过证明已实现剪裁后的输出、活动和任
务来实现剪裁符合。
3 规范性引用文件
本文件没有规范性引用文件。
4 术语、定义和缩略语
4.1 术语和定义
下列术语和定义适用于本文件。
注:其他术语和定义参见ISO/IEC/IEEE24765。
4.1.1
需方 acquirer
从供方获得或采购某一产品或服务的利益相关方。
注:需方的同义术语,常用的有买方、顾客、所有者、购买者或内部/组织赞助方。
4.1.2
获取 acquisition
获得某一系统、产品或服务的过程。
4.1.3
活动 activity
某一过程中结合在一起的各项任务的集合。
4.1.4
协定 agreement
据以维持工作关系并得到相互确认的条款与条件。
示例:合同、协定备忘录。
4.1.5
架构 architecture
体系结构
< 系统 >系统在其环境中的基本概念或属性,体现在其元素、关系以及设计和演变原则中。
[ISO/IEC/IEEE42010:2011,定义3.2]
4.1.6
体系结构框架
在特定应用领域和利益相关方的团体中,为描述架构所建立的惯例、原则和实践。
示例1:(ISO 15704中的)通用企业参考架构、方法论(GERAM)是一种架构框架。
示例2:(ISO/IEC 10746中的)开放分布式处理参考模型(RM-ODP)是一种架构框架。
[ISO/IEC/IEEE42010:2011,定义3.4]
4.1.7
架构视图 architectureview
从特定系统关注的视角来表达某一系统架构的制品。
[ISO/IEC/IEEE42010:2011,定义3.5]
4.1.8
为给特定系统的关注事项定下框架,而对构建、解释和利用架构视图建立约定的制品。
[ISO/IEC/IEEE42010:2011,定义3.6]
4.1.9
审核 audit
为评估制品或制品集是否符合规范、标准、合同协定或其他准则而进行的独立检查。
[ISO 24765:2010,定义3.213]
4.1.10
基线 baseline
经正式核准的技术状态项的版本。它与介质无关,是在技术状态项的生存周期中的特定时间节点
确定并固化的。
[IEEE828-2012,定义2.1]
4.1.11
运营观念 conceptofoperations
对于某一组织的一项或一系列行动的设想或意图,以文字和/或图形做出的概略表述。
注1:运营观念通常在长远战略规划和年度运营计划中得到体现。在年度运营计划中,运营观念覆盖同时或相继
进行的一系列相关行动。运营观念旨在描述组织运行的整体图景。参见4.1.25运行概念。
注2:运营观念提供确定运行空间、系统能力、界面和运行环境边界的基础。
[ANSI/AIAAG-043A-2012e,定义1.3.1]
4.1.12
关注 concern
< 系统 >一个或多个利益相关方对某一系统的利害所在。
注:关注涉及对某一系统在其环境方面的各种影响,包括开发的、技术的、业务的、运行的、组织的、政策的、经济的、
法律的、监管的、生态的以及社会的影响。
[ISO/IEC/IEEE42010:2011,定义3.7]
4.1.13
技术状态项 configurationitem
配置项
为了进行技术状态管理而指定的,在技术状态管理的过程中作为单一实体对待的硬件、软件或软硬
件综合项或聚合体。
[ISO/IEC/IEEE24765:2010,定义3.777]
4.1.14
顾客 customer
接受某项产品或服务的组织或个人。
示例:消费者、客户、用户、需方、购买者、采购方。
注1:顾客可以是组织内部的或外部的。
注2:改写GB/T 19000-2008,定义3.3.5。
4.1.15
设计(动词) design
< 过程 >界定架构、系统元素、接口以及某一系统或系统元素的其他特性。
4.1.16
设计(名词) design
设计(4.1.15)过程的结果。
注1:包括系统元素及其相互关系的规范,充分完备足以支持架构兼容实现的信息。
注2:设计提供了系统元素的详尽的实施级的物理结构、行为、时间关系和其他属性。
4.1.17
设计特性 designcharacteristic
属于一个产品或服务的可测量描述的设计属性或特有属性。
4.1.18
使能系统 enablingsystem
对所关注的系统在其生存周期阶段提供支持,但在其运行期间不必直接发挥功用的系统。
示例:当所关注的系统进入生产阶段时,需要一个帮助生产的使能系统。
注:每一个使能系统都有自己的生存周期。当使能系统为了其自身的需要也作为所关注的系统对待时,本标准适
用于每一个使能系统。
4.1.19
环境 environment
< 系统 >决定对一个系统的所有影响的设置和情势的周境。
[ISO/IEC/IEEE42010:2011,定义3.8]
4.1.20
设施 facility
促进行动执行的物理手段或设备,例如厂房、仪器、工具。
4.1.21
偶发事件 incident
项目、产品、服务或系统在其生存周期中任意时刻出现的异常、意外事件或者是事件、条件、情况的
集合。
4.1.22
信息项 informationitem
为人的使用而生产、存储和传递的信息的单独可识别体。
[ISO/IEC/IEEE15289:2011,定义3.1.13]
4.1.23
生存周期 lifecycle
系统、产品、服务、项目或其他人工实体从概念到退役的演变。
4.1.24
生存周期模型 lifecyclemodel
与生存周期相关的过程和活动的框架,可以组织成多个阶段,也可作为交流和理解的通用参考。
4.1.25
运行概念 operationalconcept
对于一个组织的,关于一个系统或一组相关系统的一种运行或一系列运行的,设想或意图的文字和
图形化表述。
注:运行概念它使用一个或更多特定系统或与一组相关的系统,从用户和操作者角度,给出运行的整体描述。参见
4.1.11。
[ANSI/AIAAG-043A-2012e,定义1.3.2]
4.1.26
操作方 operator
操作员
执行系统操作的个人或组织。
注1:操作者和用户的角色可被同时或顺序授予同一个人或组织。
注2:与知识、技能和规程为一体的每个操作者都可以认为是系统的一个元素。
注3:操作者可根据操作指令是否在系统边界内来对系统进行不同操作。
4.1.27
组织 organization
职责、权限和相互关系得到安排的一组人员及设施。
示例:公司、集团、商行、企事业单位、研究机构、慈善机构、代理商、社团或上述组织的部分或组合。
注:指定组织的一部分(小到只有一个人)或者指定的组织团体,只要具有职责、权限和相互关系,都可以被当做组
织。为了特定目的而组织起来的一部分人也是组织,例如俱乐部、联盟、公司、社团。
[GB/T 19000-2008,定义3.3.1]
4.1.28
当事方 party
涉入协定的组织。
注:本标准中,协定的当事方分别称为需方和供方。
4.1.29
问题 problem
需要调查和改正的,难度、不确定性或其他的认识到的非预期的事件、事件集、条件或状况。
4.1.30
过程 process
将输入转化为输出的相互关联或相互作用的活动集合。
[GB/T 19000-2008,定义3.4.1]
4.1.31
过程目的 processpurpose
执行过程的高层次的目标,过程有效实施的可能输出。
注:执行过程的目的是给利益相关方提供利益。
4.1.32
产品 product
过程的结果。
注:有四种被认可的通用产品类别:硬件(例如发动机机械零件)、软件(例如计算机程序)、服务(例如运输)和流程
性材料(例如润滑油)。硬件和流程性材料通常是有形的,软件和服务通常是无形的。
[GB/T 19000-2008,定义3.4.2]
4.1.33
项目 project
按照确定的开始与结束准则,依据给定的资源和需求创建产品或服务的努力。
注:项目可看作包含协作和受控活动的独特过程,可由本标准中定义的项目过程和技术过程的活动组成。
4.1.34
质量保证 qualityassurance
是质量管理的一部分,致力于提供质量要求会得到满足的置信度(统计上的可信程度)。
注:改写GB/T 19000-2008,定义3.2.11。
4.1.35
与要求有关的,产品、过程或系统的固有属性。
注1:严格意义上的质量特性一般包括与健康、安全性、信息安全性、可靠性、可信性、可用性、支持性相关的内容。
注2:改写GB/T 19000-2008,定义3.5.2。
4.1.36
质量管理 qualitymanagement
在质量方面指挥和控制组织的协调的活动。
[GB/T 19000-2008,定义3.2.8]
4.1.37
需求 requirement
对需要及其约束和条件的表达。
[ISO/IEC/IEEE29148:2011,定义4.1.17]
4.1.38
资源 resource
过程执行期间使用或消耗的资产。
注1:包括不同的实体,例如资金、人力、设施、固定设备、工具和公共设施,例如电力、水力、燃料和通信设施。
注2:资源包括可循环使用的、可再生的或者消耗品。
4.1.39
退役 retirement
负责运行和维护的组织撤销了对当前系统的有效支持,当前系统已被新系统或升级改造的系统部
分或者完全的替代。
4.1.40
风险 risk
不确定性对目标的影响。
注1:影响是指偏离预期,可以是正面的和/或负面的。正面的影响也被认为是机遇。
注2:目标有不同的方面(例如财务、健康与安全、环境)和层面(例如战略、组织、项目、产品和过程等)的目标。
注3:通常用潜在事件、结果或者两者的组合来区分风险。
注4:通常用事件后果(包括情形的变化)和事件发生可能性的组合来表述风险。
注5:不确定性是指对事件及其后果或可能性的信息缺失或了解片面的状态。
[GB/T 23694-2013,定义2.1]
4.1.41
信息安全性 security
防止故意破坏或者强制失效。信息安全性一般由保密性、完整性、可用性和可问责性四个属性组
成,有时加上第5个属性---易用性,上述五个方面都有保证这些属性实现的相关问题。
[NATOAEP-67]
4.1.42
服务 service
活动、工作和职责的履行。
注1:服务是自包含的、固有的、离散的,可包含其他服务。
注2:服务一般是无形的产品。
4.1.43
阶段 stage
与自身描述和认识有关的整个实体的生存周期的节点。
注1:使用本标准,与整个实体生存周期中主要过程和成就转折点有关的阶段。
注2:阶段经常会交迭。
4.1.44
利益相关方 stakeholder
权益相关方
在一个系统或系统特性范围内具有权利、份额或主张,以满足其要求和期望的利益的个人或组织。
示例:最终用户、最终用户组织、支持方、开发方、培训方、维护方、部署方、需方、供方组织和监管机构。
注:某些利益相关方可具有相互对立或与系统对立的利益。
4.1.45
供方 supplier
与需方达成关于产品或服务供应协定的组织或个人。
注1:一般用于供方的其他术语有承包人、生产者、卖家、供应商。
注2:需方和供方有时是同一个组织的一部分。
4.1.46
系统 system
为达到一个或多个规定目的而组织起来的、相互作用的元素的组合体。
注1:一个系统可被认为是一种产品或者是一种它所提供的服务。
注2:实际中,对系统含义的解释通常通过使用一个联合名词......
|