《GB_T 8566-2022 系统与软件工程 软件生存周期过程.docx》由会员分享，可在线阅读，更多相关《GB_T 8566-2022 系统与软件工程 软件生存周期过程.docx（118页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、GB/T85662022/ISO/IEC/IEEE12207:2017目次前言Ill引言IV1范围11.1概述11.2目的11.3应用领域11.4限制22规范性引用文件23术语和定义、缩略语23.1 术语和定义23.2 缩略语94符合性104.1预期用法104.2完全符合114.3 剪裁符合115关键概念和应用115.1 导引115.2 软件系统概念115.3 组织和项目概念155.4 生存周期概念155.5 过程概念175.6 过程组175.7 过程应用195.8过程参考模型206软件生存周期过程206.1协定过程组206.2组织的项日使能过程组246.3技术管理过程组306.4技术过程组4
2、3附录A（规范性）剪裁过程79附录B（资料性）过程信息项示例81附录C（资料性）用于评估日的的过程参考模型85附录D（资料性）过程集成和过程构建87附录E（资料性）过程视图89附录F（资料性）软件系统架构建模96附录G（资料性）将软件生存周期过程应用于系统之系统98附录H（资料性）敏捷的应用101附录NA（资料性）本文件与GB/T85662007的差异103参考文献107IIGB/T85662022/ISO/IEC/IEEE12207:2017软件系统的复杂性已经增加到前所未有的程度。这为创建和使用系统的组织带来了新的机遇.但也带来了更多的挑战，这些挑战存在于软件系统的整个生存周期以及架构层次
3、上的所有细节。本文件提供了一个公共过程框架，以便采用软件工程方法描述人工创建的系统生存周期。软件工程是成功实现软件系统的一种跨学科方法和手段，它关注定义利益相关方的需要以及开发周期之前所要求的功能，它关注建立需求文档,它关注执行设计集成和系统验证，同时也考虑全局性的问题。软件工程将所有的规程和专业组集成到一个团队工作中，形成一个从概念到生产、到操作、到维护的结构化开发过程，同时也考虑全部利益相关方的业务和技术需要，以提供满足用户和其他利益相关方要求的高质量产品为目标。该生存周期跨越了从概念到系统退役的整个过程，为系统的获取和供应.提供了相应的过程，同时也有助于改进创建、使用和管理现代软件系统各
4、方之间的沟通和合作，使它们可以按一种集成化的、高内聚的模式工作。该框架还提供了对生存周期过程的评估和改进。本文件中的过程形成了一个全面的集合，组织可从中构建适合其产品和服务的软件生存周期模型。根据组织目的.可选择并应用一个适当的子集来实现该目的。本文件可在下列一种或多种模式下使用。a）组织使用一一帮助建立所需过程的环境。这些过程可由方法、过程、技术、工具和经过培训的人员组成基础结构来支持。然后组织可使用上述环境来执行和管理自身的项目，并通过它们的生存周期阶段来开发软件系统。在这种模式下，本文件用于评估已声明的、已建立的环境是否符合其规定。b）项目使用一一帮助选择、构建和使用一个已建立的环境元素
5、来提供产品和服务。在这种模式下.本文件用于评估项目是否符合已声明和已建立的环境。c）需方和供方使用一帮助制定关于过程和活动的协议。通过该协议，本文件中的过程和活动被选定、协商、同意和执行。在这种模式下,本文件用于指导协议的制定。d）过程评估者使用一一作为过程参考模型.用于过程评估的绩效.以支持组织的过程改进。考虑到软件和系统范围的区别.本文件中的软件生存周期过程模型中的“特定项目包管理过程”与GB/T22302-2021系统生存周期过程模型中的“项日群管理过程”指的是同一过程.但在表述上存在差异。NGB/T85662022/ISO/IEC/IEEE12207:2017系统与软件工程软件生存周期
6、过程1范围1.1概述本文件使用良好定义的术语，为软件生存周期过程建立了一个公共框架，以供软件产业界引用。该框架包含过程、活动和任务，可用于软件系统、产品和服务的获取、供应、开发、运行、维护或处置期间。这些生存周期过程是通过所有与系统有关的各方参与，以实现顾客满意为最终目标来完成的。本文件适用于软件系统、产品和服务.以及任何系统中的软件部分的获取、供应、开发、运行、维护和处置（无论在组织内部还是外部执行）。软件包括固件的软件部分，还包括为软件产品和服务提供环境所需的系统定义那些部分。本文件还提供了可用于一个组织或一个项目内来定义、控制和改进软件生存周期过程的过程。本文件中的过程、活动和任务还可应
7、用于一个包含软件的系统的获取期间,其中.既可以单独使用，也可以和GB/T220322021结合使用。GB/T22032-2021主要关注那些很少使用或不使用软件的人造系统，与GB/T22032-2021的使用环境相比，本文件主要关注的是一个连续统一体的软件人造系统。现实中，很少遇见一个没有软件的复杂系统,旦所有软件系统均需通过物理系统的部件（硬件）来运行，或只作为关注焦点的软件系统的一部分，或只作为一个使能系统或基础设施。因此，是否把本文件应用于软件生存周期，还是把GB/T22032-2021应用于软件生存周期,这一选择依赖于所关注的系统。两个标准中的过程具有相同的过程目的和过程输出，但是分别
8、在执行软件工程或系统工程的活动和任务中有所不同。1.2目的本文件的目标是在系统生存周期中提供一个已定义过程集合，来促进需方、供方和其他利益相关方之间的沟通。本文件适用于软件系统、产品和服务的需方、供方、开发方、集成方、操作方、维护方、管理者、质量保证管理者和用户。它既可由单方作为自我改进工作采用，也可用于多方的情况。各方可来自于同一个组织，也可来自不同的组织，各方之间的关系可以是非正式合同或正式合同。本文件的过程可用于作为创建业务环境（例如，方法、规程、技术、工具和专业人员）的基础。附录A规定了对这些软件生存周期过程进行剪裁的规范性要求。1.3应用领域本文件应用于完整的软件系统、产品和服务的生
9、存周期，包括概念、开发、生产、使用、支持和退役，同时也应用于它们的获取和供应，无论是在组织内部还是外部运行。本文件定义的生存周期过程可同时地、迭代地、递归地应用于软件系统，也可递增地应用于软件系统元素。在软件系统的目的、应用领域、复杂性、规模、新颖性、适应性、数量、位置、生存时间与演进等方面，软件系统是千差万别的。本文件描述了包含人工软件系统的生存周期过程。因此.它既可应用于单件生产、面向广泛的商业或公共发行.以及可定制可适应的软件系统，也可应用于完整的单机软件系统和可嵌入/集成为更大更复杂的完整系统中的软件系统。本文件提供了根据过程目的和过程输出特征而展现的过程参考模型，而过程目的和过程输出
10、来源于活动和任务的成功执行。附录B列出了与不同过程相关工作产品和信息项的例子。因此本文件作GB/T85662022/ISO/IEC/IEEE12207:2017为参考模型，用于支持过程评估（参见ISO/IEC33002:2015）。附录C提供了作为过程参考模型和关于软件生存周期使用的信息。附录D描述了使用过程参考模型的过程结构。1.4限制本文件并不规定具体的软件生存周期模型、开发方法学、方法、建模方法或者技术。本文件的用户负责选择项目的生存周期模型，并把本文件的过程、活动和任务映射到模型。各方也可选择和应用适合该项目的合适的方法学、方法、模型和技术。本文件没有建立管理体系，也未要求使用任何管理
11、体系标准。然而还是期望与GB/T19001规定的质量管理体系JSO/IEC20000-1（IEEEstd20000-1）规定的服务管理体系以及GB/T29246规定的信息安全管理体系兼容。本文件没有详述关于命名、格式、明确内容、记录媒介的信息项。生存周期过程信息项（文档）内容参见ISO/IEC/IEEE15289。2规范性引用文件本文件没有规范性引用文件。3术语和定义、缩略语3.1术语和定义下列术语和定义适用于本文件。3.1.1需方acquirer从供方获得或采购某一产品或服务的利益相关方。注：需方的同义术语.常用的有买方、顾客、所有者、购买者或内部/组织赞助方。3.1.2获取acquisit
12、ion获得某一系统、产品或服务的过程。3.1.3活动activity某一过程中高内聚的任务集合。3.1.4敏捷开发agiledevelopment以迭代开发、频繁检查和调整、增量交付为手段，依靠跨功能团队协同和持续与利益相关方沟通反馈促进需求和解决方案不断演进的软件开发方法。来源：ISO/IEC/IEEE26515:20113.1.5协定agreement据以维持工作关系并得到相互确认的条款与条件。示例：合同.协定备忘录。3.1.6架构architecture体系结构（系统）在其环境中的一些基本概念或性质.体现在其元素、关系.以及设计与演进原则中。来源：IS()/IEC/IEEE42010:2
13、011,3.23.1.7架构框架architectureframework体系结构框架在特定应用领域和/或利益相关方的团体中,为描述架构所建立的约定、原理和实践。示例1：GB/T18757中的通用企业参考架构、方法论(GERAM)是一种架构框架。示例2JSO/IEC10746开放分布式处理参考模型(RM-ODP)是种架构框架。来源：1SO/IEC/IEEE42010：2011,3.43.1.8架构视图architectureview从特定系统关注的视角来表达某一系统架构的工作产品。来源：IS()/IEC/IEEE42010:2011,3.53.1.9架构视角architectureviewpo
14、int为架构视图的构造、解释和使用，建立约定的工作产品，以便构建特定系统的关注焦点。来源：1SO/IEC/IEEE42010：2011,3.63.1.10审核audit审计为评估工作产品或工作产品集是否符合规范、标准、合同协定或其他准则而进行的独立检查。来源:GB/T114572006,3.2133.1.11基线baseline经正式批准的配置项。它与媒介无关，是在该配置项的生存周期中的特定时间节点确定并固化的。来源：1EEEStd8282012,2.13.1.12业务过程businessprocess为了达到某种期望的最终结果，从而实现组织的既定目标，可执行的部分有序的企业活动的集合。3.1
15、.13运营观念conceptofoperations对于某一组织的一项或一系列行动的设想或意图，以文字和/或图形做出的概略表述。注1：运营观念通常在长远故胳规划和年度运营计划中得到体现。在年度运营计划中.运营观念覆盖同时或相继进行的一系列相关行动。运营观念旨在描述组织运行的整体图景。参见3.1.28运行概念。注2：运莒观念为提供确定运行空间、系统能力、界面和运行环境边界的基础。来源：ANSI/A1AAG-O43A2012c,5.23.1.14关注焦点concern(系统)一个或多个利益相关方对某一系统的利益所在。注：关注焦点涉及对某一系统在其环境方面的各种影响.包括开发的、技术的、业务的、运行
16、的、组织的、政策的、经济的、法律的、监管的、生态的以及社会的影响。来源：IS()/IEC/IEEE42010:2011,3.73.1.15配置项configurationitem技术状态项为了进行配置管理而指定的，在配置管理的过程中作为单个实体对待的硬件、软件或软硬件综合项或聚合体。示例：软件、固件、数据、硬件、人员、过程（如为用户提供服务的过程）、程序（如操作说明和用户手册）、设施、服务、材料和自然存在的实体。来源：IS（）/1EC/IEEE24765:2010,3.5633.1.16顾客customer接受某项产品或服务的组织或个人。示例：消费者、客户、用户、需方、买方或购买者。注：顾客可
17、以是组织内部的或外部的。3.1.17设计（动词）design（过程）界定架构、系统元素、接口，以及某一系统或系统元素的其他特性。来源：IS（）/IEC/IEEE24765:2010,3.800,有修改3.1.18设计（名词）design设计（3.1.17）过程的结果。注1：信息.包括系统元素及其相互关系的*见范,充分完备足以支持架构兼容实现的信息。注2：设计提供了系统元素的洋细的实现级的物理结构、行为、时间关系和的其他属性。3.1.19设计特性designcharacteristic属于一个产品或服务的可测量描述的设计属性或特有性质。3.1.20使能系统enablingsystem对所关注的系
18、统在其生存周期阶段提供支持，但在其运行期间不必直接发挥功用的系统。示例：在软件开发期间用于控制软件元素的配置管理系统。注：每一个使能系统都有自己的生存周期。当使能系统为了其自身的需要也被作为所关注的系统对待时，本文件同样适用于它们。3.1.21环境environment（系统）决定对一个系统的所有影响的设置和情势的周境。来源：IS（）/1EC/1EEE42010.2011,3.83.1.22设施facility促进行动执行的物理手段或设备，例如厂房、仪器、工具。3.1.23偶发事件incident项目、产品、服务或系统在其生存周期中任意时刻发生的异常、意外事件或者事件、条件、情况的集合。3.1
19、.24信息项informationitem信息产品informationproduct供人们使用而制作、存储和交付的可单独识别的信息体。来源：IS（）/IEC/IEEE15289:2015,3.1.123.1.25基础设施infrastructure支持计算机系统与软件的设计、开发和改进的硬件和软件环境。3.1.26生存周期lifecycle系统、产品、服务、项目或其他人工实体从概念到退役的演变。3.1.27生存周期模型lifecyclemodel与生存周期相关的过程和活动的框架，可以组织成多个阶段，也可作为交流和理解的通用参考。3.1.28运行概念operationalconcept对于一个
20、组织的，关于一个系统或一组相关系统的运行或一系列运行的，设想或意图的文字和图形化表述。注：运行概念使用一个或多个特定系统或与一组相关的系统.从用户和操作者角度.给出运行的整体描述。参见运营观念(3.1.13).来源：ANSI/AIAAG-O43A-2O12e,5.23.1.29操作方operator操作员执行系统操作的个人或组织。注1：操作者和用户的角色可被同时戒顺序授予同一个人或组织。注2：与知识、技能和规程为一体的操作者都可以被认为是系统的一个元素。注3：操作者可根据操作指令是否在系统边界内来对系统进行不同的操作。3.1.30组织organization职责、权限和相互关系得到安排的一组人
21、员及设施。示例：公司、集团、商行、企事业单位、研究机构、慈善机构、代理商、社团或上述组织的部分或组合。注：指定组织的一部分(小到只有一个人)或者指定的组织团体.只要具有职责、权限和相互关系，都可以被当做组织。为了特定目的而组织起来的一部分人也是组织.如俱乐部、联盟、公司、社团。3.1.31当事方party达成协定的组织。注：在本文件中.协定的当事方分别称为需方和供方。3.1.32问题problem需要探究并采取纠正措施的困境、不确定性，或其他已认识的和不期望的事件、事件集、条件或状况。3.1.33过程process一组将输入转化为输出的相互关联或相互作用的活动。3.1.34过程输出proces
22、soutcome成功达到过程目的、可观察的结果。3.1.35过程目的processpurpose执行过程的高层次的目标,过程有效实施的可能输出。注：执行过程的目的是为利益相关方提供权益。3.1.36产品product过程的结果。注：有四种被认可的通用产品类别：硬件（如发动机机械零件）、软件（如计算机程序,以及可能有关的文件和资料）、服务（如运输）和流程性材料（如润滑剂）。硬件和流程性材料通常是有形的产品.而软件和服务通常是无形的。3.1.37项目project按照明确的开始和结束准则，依据给定的资源和需求创建产品或服务的努力。注：项目可看作是包含协作和受控活动的独特过程，可由本文件中定义的来自
23、技术管理过程组和技术过程组的活动组成。3.1.38项目特定项目包portfolio专注于组织的战略目标的项目的集合。注：GB/T220322021中使用“项目群”。3.1.39资质qualification证明实体是否有能力满足规定要求的过程。3.1.40质量保证qualityassurance质量保障质量管理的一部分.致力于提供质量要求会得到满足的置信度（统计上的可信程度）。来源:GB/T190002016,3.3.6,有修改3.1.41质量特性qualitycharacteristic与要求有关的，产品、过程或系统的固有属性。注：严格意义上的质量特性通常包括与健康、安全性、信息安全保证、可
24、靠性、可用性和支持性相关的内容。3.1.42质量管理qualitymanagement在质量方面指挥和控制组织的协调的活动。3.1.43发布release用于特定目的的可用配置项的特定版本。示例：测试发布。3.1.44需求requirement对需要及其约束和条件的表达。来源：IS（）/IEC/IEEE29148:2018,3.1.19,有修改3.1.45资源resource过程执行期间使用或消耗的资产。注：资源包括可循环使用、可再生的或消耗品。示例：不同的实体.如资金、人力、设施、固定设备、工具和公共设施；如电力、水力、燃料和通信基础设施。3.1.46退役retirement负责运行和维护的
25、组织撤销了对当前系统的有效支持.当前系统已被新系统或升级改造的系统部分或者完全的替代。3.1.47风险risk不确定性对目标的影响。注1：影响是指偏离预期.可以是正面的和/或负面的。正面的影响也被称为机遇。注2：目标祈不同的方面（例如财务、健康与安全，以及环境的目标）并可应用在不同层次（例如战略、绢织范围、项目、产品和过程注3：通常用潜在事件、结果或者两者的组合来区分风险。注4：通常用事件后果（包括情形的变化）和事件发生可能性的组合来表述风险。注5：不确定性指对事件及其后果或可能性的信息缺失或了解片面的状态。来源:GB/T236942013,2.13.1.48安全safety系统在给定条件下不
26、会导致人们生命、健康、财产或环境处于危险状态的期望。3.1.49信息安全性security以防故意破坏或强使失效的保护。信息安全一般由保密性、完整性、可用性和可追溯性四个属性组成，有时加上第5个属性一一易用性，上述5个方面都有保障这些属性实现的相关问题。来源:NATOAEP-673.1.50服务service活动、工作或职责的履行。注1：服务是自包含的、固有的、离散的.可包含其他服务。注2：服务一般是无形的产品。3.1.51软件元素softwareelement本身是软件的系统元素。3.1.52软件工程softwareengineering将系统化的、严格约束的、可量化的方法应用于软件的开发、
27、运行和维护。注：即将工程化应用于软件。3.1.53软件项softwareitem源代码、目标代码、控制代码、控制数据或这些项的集合。注：软件项可被视为本文件和GB/T22032:2021的一个系统元素。软件项通常是配置项。3.1.54软件产品softwareproduct一组计算机程序、规程以及可能的相关文档和数据。注：软件产品被看作是一种由过程产生输出（产品）的软件系统。3.1.55软件系统softwaresystem软件对于利益相关方来说是最为重要的部分的系统。注1：最常见的软件系统是由硬件、软件、人员及其操作过程组成。注2：在软件系统中.软件是满足系统需求的主要驹动。3.1.56软件系统
28、元素softwaresystemelement构成软件系统的一组元素的成员。注1：软件系统元素可包括一个或更多的软件单元、软件元素、硬件单元、硬件元素、服务以及其他系统元素和系统。注2：软件系统元素可以被看作是一个系统元素。3.1.57软件单元softwareunit软件体系结构中,可接受独立测试的最小组件。注：一些软件单元是可单独编译的代码段。来源:GB/T34590.12017,2.125,有修改3.1.58阶段stage实体生存周期中的一个区段，与实体的描述或实现的状态有关。注1：使用本文件，与整个实体生存周期中主要过程和成就转折点有关的阶段。注2：阶段经常会交迭。3.1.59利益相关方
29、stakeholder在系统或所属其特性中有权利、份额、声明或利益.以满足其需要及期望的个人或组织。示例：最终川户、最终用户组织、支持方、开发方、培训方、维护方、部署方、需方、供方组织和监管机构。注：某些利益相关方可具有相互对立或系统对立的利益。3.1.60供方supplier与需方达成关于产品或服务供应协定的组织或个人。注1：一般用于供方的其他术语有承包人、生产者、卖家或供方。注2：需方和供方有时是同一个组织的一部分。3.1.61系统system为达到一个或多个明确目的而组织起来的、相互作用的元素的组合体。注1：系统有时可被认为是一种产品或者一种它所提供的服务。注2：实际中.对系统含义的解释
30、通常通过使用一个联合名词来阐述.如6行器系统。有时候“系统”这个词也可简单地由依赖语境的同义词来替代，如飞行器.虽然这可能会使系统的视角不太明显。注3：完整的系统包括相关装置、设备、原料、软件、固件、技术文档、服务和运行、支持所必需的人力，并能在其预期的环境中使用。注4：参见比较:使能系统.所关注的系统.系统之系统。3.1.62系统元素systemelement组成系统的一组元素中的成员。示例：硬件、软件、数据、人、过程（例如提供给用户服务的过程）、规程（例如操作指南）、设备、原料、自然存在的实体或其任意组合。注：系统元素是系统中的离散部分,通过实现它可以完成规定的需求。3.1.63所关注的系
31、统system-of-interest正在考虑其生存周期的系统。3.1.64系统之系统systeni-of-system一组集成的或可互操作的系统,以提供任一组成系统都无法单独完成的独特能力。注：每个组成系统本身都是一个有用的系统.具有其自身的管理、目标和资源.但在S()S内部协调以提供S()S的独特能力。3.1.65系统工程systemsengineering一种跨学科方法，用于控制将一系列利益相关方的要求、期望、约束转化为解决方案，并在整个生存周期中支持此解决方案所需要的全部技术工作和管理工作。3.1.66任务task要求的、推荐的或可允许的活动，目的是有助于一个或多个过程输出的达成。3.
32、1.67技术管理technicalmanagement运用技术和行政资源来规划、组织和控制工程职能。3.1.68权衡tradeoff基于利益相关方的净利益，从各种需求和备选解决方案中做出选择的决策活动。3.1.69可追溯性traceability在两个或两个以上的逻辑实体之间建立关系的程度，特别是相互之间有前后相继或主从关系的实体.例如需求、系统元素、验证或任务。示例：软件特性和测试用例通常迫溯到软件需求。3.1.70用户user在系统使用过程中，与系统进行交互或从系统中获益的个人或组织。注：用户和操作者的角色可能同时或依次地归属于同一个人或组织。来源:GB/T25000.102016,3.2
33、7,有修改3.1.71确认validation通过提供客观证据，对特定的预期用途或应用的需求已得到满足的认定。注1：系统能够在预期的运行环境下,完成预期的用途、目标和目的(如满足利益相关方的要求),则建立了正确的系统。注2：在生存周期周境中确认涉及一系列以获得系统能够在与操作环境类似的环境中完成其预期用途、目标和目的的信心的活动。3.1.72验证verification通过提供客观证据，对特定需求已得到满足的认定。注：验证是一系列将系统或系统元素与需求的特性相比较的活动集合.包括但不限于规定的需求、设计描述和系统本身。系统是按照正确的过程建造的。来源:GB/T190002016,定义3.8.1
34、2,有修改3.2缩略语下列缩略语适用于本文件。CCB：配置控制委员会(ConfigurationControlBoard)CM：配置管理(ConfigurationManagement)COTS：商业现货(Commercial-Off-The-Shelf)FCA：功能配置审核(FunctionalConfigurationAudit)FOSS：免费开源软件(FreeandOpenSourceSoftware)GUI：图形用户界面(GraphicalUserInterface)NDI:非开发项(Non-DevelopmentalItems)PCA:物理配置审核(PhysicalConfigura
35、tionAudit)PESTEL:大环境分析(Political*EconomicSocial,Technological.Environmental*andLegal)PMI:项目管理协会(ProjectManagementInstitute)PMP：项目管理计划(ProjectManagementPlan)PRM：过程参考模型(ProcessReferenceModel)QA：质量保证(QualityAssurance)SCM:软件配置管理(SoftwareConfigurationManagement)SDP：软件开发计划(SoftwareDevelopmentPlan)SEMP：系统工
36、程管理规划(SystemsEngineeringManagementPlan)SOI:所关注的系统(System-of-Interest)S()S：系统之系统(SystemofSystems)SWOT:态势分析法(Slrengihs,Weaknesses,Opporlunilies,Threais)WBS：T.作分解结构(WorkBreakdownStructure)4符合性4.1预期用法本文件的要求包含在第6章和附录A中。本文件提供了适合在软件系统或产品的生存周期中使用的一些过程要求。特定的项目或组织或许不需要使用本文件提供的所有过程.因此，本文件的实施通常涉及选择和声明适合组织或项日的过程
37、集合。有两种符合本文件规定的实施可被声明的方法一完全符合和剪裁符合。声明完全符合存在两个准则。不管达到哪个准则均满足符合性，尽管所选择的准则(或原则)要在声明中给出。声明“任务的完全符合，即表明达到了所声明的那个过程集的活动和任务的所有要求，与此相对地.声明“输出的完全符合即表明实现了所声明的过程集的所有要求的输出。输出的完全符合允许在符合过程的实施中具有更大的自由度，并对实现使用于一个创新生存周期模型环境中的过程是有益处的。注1：为满足应用本文件所需的灵活性，提供了符合性选项。每个过程都布一组目标(称为“输出”)、活动与任务，它们代表实现这些目标的一种方式。注2：实现被声明过程集的活动和任务
38、的用户可以确定与所选过程的任务完全符合。然而有些用户可能具有实现被声明过程集的目标(如输出)而无需执行所有的活动和任务的创新过程变体。这些用户可以确定与被声明过程集的输出完全符合。这两个准则任务符合与输出符合并不一定是等同的.因为在某些情况下，活动和任务的具体执行可能比仅仅实现输出需要更高的能力水平。注3：当本文件用于帮助促进供需双方之间的协定时,无论修改与否都可以选择将本文件中的条款纳入协定。在这种情况下，对需方和供方来说，要求遵守协定比符合本文件更合适。注4：将本文件作为交易条件的组织(如，国家、行业协会、公司)可以规定并公开构成供方满足协定条件所需过程、输出、活动和任务的最小集。注5：本
39、文件通过助动词“应”的使用来标讪要求，通过助动词“宜”的使用来标记建议，通过助动词“可”的使用来标记允许。然而尽管使用了助动词，符合性要求还是如前所述的那样被选择。4.2完全符合4.2.1输出的完全符合完全符合的声明给出了声明符合性的过程集。通过证明已完成所声明过程集的所有输出.来实现输出的完全符合。在这种情况下，有关宣称的过程集所含活动和任务的条款是指导性的，而不是要求，尽管在该条款中使用了动词形式。使用本文件的目的之一是促进过程评估和改进。就这一意图而言，每个过程的目的是以“输出”的形式给出的.与1SO/IEC33002兼容。ISO/1EC33002为本文件的过程评估、过程改进提供了基础。
40、期望过程评估和改进的用户，可以使用本文件中给出的过程输出，作为ISO/IEC33002所需要的过程参考模型。4.2.2任务的完全符合完全符合的声明给出了声明符合性的过程集。通过证明所声明过程集的所有活动和任务都已符合要求,来实现任务的完全符合。在这种情况下，有关声明的过程集之输出的条款是指导性的，而不是要求，尽管在该条款中使用了动词形式。注：在合同情况中，当需方或监管者需要详细了解供方的过程.任务的完全符合的声明会是比较合适的。4.3剪裁符合当本文件作为建立过程集的基础而使用时，其中该过程集并非限制为是完全符合的,那么就可根据附录A中规定的剪裁过程选择本文件的章条内容，或修改之。剪裁文本是为表
41、明剪裁符合而声明的。通过证明已完成剪裁后的输出、活动和任务，来实现剪裁符合。5关键概念和应用5.1导引本章旨在强调并帮助解释本文件所依据的基本概念。注：这些概念的进一步阐述可以在关于生存周期管理应用的ISO/IEC/IEEE24748-1JSO/IEC/IEEE24748-2和ISO/IEC/1EEE24748-3中找到。5.2软件系统概念5.2.1软件系统本文件中涉及的软件系统是人工制造的，创建并使用这些软件系统是为了用户和其他利益相关方的利益提供待定环境下的产品或服务。这些软件系统可以包括以下系统元素：硬件、软件、数据、人、过程（如提供服务给用户的过程）、规程（如操作说明）、设施、服务、原
42、料和自然存在的实体。对用户而言，它们被认为是产品或服务。本文件适用于对利益相关方来说软件是其最重要部分的系统。它基于系统工程和软件工程的一般原理。本文件的一个基本前提是软件始终运行于系统的背景下。由于软件的运行离不开硬件，因此执行软件的处理器可以看作是系统的一部分。另外，承载软件系统并处理与其他系统通信的硬件或服务也可以视为运行环境中的使能系统或外部系统。对于特定软件系统及其结构和元素的理解和定义，取决于利益相关方的利益和职责。一个利益相关方所关注的系统（SOI）可以当作另一个利益相关方关注的系统元素，也可以被当作另一利益相关方SOI环境的一部分。以下列举了SOI的重要特性：a）定义的边界封装
43、了有意义的需要和实际的解决方案；b）系统元素间存在层次关系或其他关系；c）SOI中任何层次中的一个实体都可被当作一个系统；d）系统包含集成的、已定义的从属系统元素的集合；e）人既可以被看作是系统外的用户，也可以认为是系统内的系统元素（如操作者）；f）系统可被孤立地当作一个实体（如产品）或当作能够与周围环境相互作用的功能集合体（如服务集合）。本文件的概念是通用的，无论选择什么边界来定义系统，允许使用者将生存周期中的各个实例关联起来或使之适应其系统原理。5.2.2软件系统结构本文件中生存周期过程的描述是与软件系统相关的。软件系统是由一组互相作用的系统元素组成的（包括软件元素），每个系统元素能分别实
44、施以完成各自特定的需求（图1）。因此，任一系统元素的实施职责，可以通过协定委托给另一当事方。软件系统由一组交互的要达到一个或多个目的图1软件系统和软件系统元素的关系对于最简单的SOI,软件系统与其系统元素全集之间的关系通常可以用表示元素间关系的层级结构来描述。分解是某些软件活动中的一种方法，其他方法包括面向对象法，在这种方法中，系统元素以平面（非层次）描述的方式布局,例如在网络图中。对于更复杂的SOI,在系统元素的全集得到确切定义之前，一个预期的系统元素本身有可能需要被看作一个系统（该系统又进一步由系统元素组成）（图2）。以这种方式,将合适的系统生存周期过程递归地应用于S（）I.用以将其结构分
45、解到可理解的和可管理的系统元素能够实施（创建、调整、获取或重用）的程度。17所关注的软件系统软件系统系统系统元素系统元素系统元素软件系统系统元素软件元素软件系统系统软件元素软件元素系统软件元素软件系统系统元素软件元素系统元素系统元素件素5B系统元素图2所关注的软件系统的结构示例图1、图2隐含了一种层次关系。实际上，从一个或多个方面看,属于非层级结构的系统数量在不断增加,例如网络和其他分布式系统。附录G讨论了系统之系统(S()S)的概念。注：分解对于许多软件活动来说是一种基本活动。并非所有的分解都意味着指定新的软件系统元素以及相应的活动递归应用。只有当适合将不同的需求、设计或实现活动应用于其开发时，才需要将分解的构造指定为元素。适当情况的一个例子是，当元素由不同的组织开发时。另一个例子是.当管理层决定有区别地监视元素的开发或定制状态时。5.2.3使能系统S()I在其整个生存周期内，需要从那些并不直接属于SOI运行环境的系统获得必要的服务，例如建模系统、培训系统、维护系统,这些系统每一个都是系统使能的一部分.例如，SOI的生存周期中要实施的某个阶段。这类系统称为“使能系统”，它们促进了S()I在其生存周期内的进展。SOI为其运行环境提供服务.使能系统为SOI提供服务.这两种服务的关系见图3。使能系统可视为直接促成了SOI提供的服务。SOI和使能系统之间的相互关系可以是双向的，也可是