1 软件系统
本文件中考虑的软件系统是人造的，其被创建和使用是为了在定义的环境中提供产品或服务，造福用户和其他利益相关者 1。这些软件系统可以包括以下系统元素：硬件、软件、数据、人类、过程（例如，为用户提供服务的过程）、程序（例如，操作员指令）、设施、服务、材料和自然发生的实体。从用户的角度来看，它们被视为产品或服务。
本文件适用于对利益相关者而言软件至关重要的系统。它基于系统工程和软件工程的一般原则。本文件的基本前提是软件始终存在于系统环境中。由于软件离开硬件，因此执行软件的处理器可被视为系统的一部分。
或者，承载软件系统并处理与其他系统通信的硬件或服务也可以被视为操作环境中的支持系统或外部系统。
对特定软件系统、其架构和要素的认知和定义取决于利益相关者的利益和责任。一个利益相关者的利益系统可以被视为另一个利益相关者利益系统中的系统要素。此外，一个利益系统可以被视为另一个利益相关者利益系统环境的一部分。
以下是关于感兴趣系统特征的要点：
- 明确的界限囊括了有意义的需求和切实可行的解决方案；
- 系统要素之间存在层次关系或其他关系；
- 感兴趣的系统中任何级别的实体都可以被视为一个系统；
- 一个系统由一组完整的、 定义的从属系统元素组成；
e）人类既可以被视为系统外部的用户，也可以被视为系统内部的元素（即操作员）。系統；及
- 一个系统可以孤立地看作一个实体， 即一个产品；或者一个能够与周围环境交互的功能集合，即一组服务。
无论选择何种边界来定义系统，本文档中的概念都是通用的，并允许从业者将生命周期的个别实例与其系统原则关联或调整。
2 软件体系结构
本文档中的生命周期过程与由一组相互作用的系统元素（包括软件元素）组成的软件系统有关，每个系统元素均可实施以满足其各自指定的要求（图 1）。因此，可以通过协议将任何系统元素的实施责任委托给另一方。
十三
图1 软件系统与软件系统元素关系
软件系统与其整个系统元素集之间的关系通常可以用元素之间的关系来表示 通常以层次结构来描述最简单的系统。分解是一些软件活动的方法。其他方法包括面向对象的方法，其中系统元素以平面（非层次）描述的形式排列，例如网络图。对于更复杂的软件感兴趣的系统， 可能需要将预期的系统元素视为一个系统（反过来又由系统元素组成），然后才能自信地定义一组完整的系统元素（图 2）。以这种方式， 适当的系统生命周期过程将递归应用于感兴趣的系统，以将其结构解析为可理解和可管理的软件系统元素可以实现（创建、 调整、获取或重用）的程度。
软件系统兴趣
软件 系统系统 元素系统
系统 系统 软件 系统 软件 软件元素 元素 系统 元素 元素 系统
系统 软件 软件 系统软件 软件元素 元素 元素 系统
系统 软件 软件 软件系统 系统 系统元素元素 元素 元素 元素 元素 元素
图2 感兴趣的软件系统结构示例
虽然图 1 和图 2 暗示了层次关系，但实际上，从一个或多个方面来看，越来越多的系统并不是层次化的，例如网络和其他分布式系统。附件G 讨论了系统的系统 (SoS) 的概念。
注：分解是许多软件活动的基本活动。并非所有的分解都只是指定新的软件系统元素和相应的递归应用该活动。仅当适合将不同的需求、设计或实施活动应用于其开发时，才需要将组合构造指定为元素。一个适当情况的示例是当元素由不同的组织开发时。另一个示例是当管理层确定适合明确监视元素的开发或定制状态时。
3 支持系统
在感兴趣的系统的整个生命周期中，需要从不直接属于感兴趣的系统的操作环境的系统提供基本服务，例如建模系统、培训系统、维护系统。这些系统中的每一个都使感兴趣的系统生命周期的一个阶段能够进行。它们被称为“支持系统”，它们促进感兴趣的系统在其生命周期中的进展。
图 3 显示了感兴趣的系统向操作环境提供的服务与支持系统向感兴趣的系统提供的服务之间的关系。 可以看到，支持系统间接地为感兴趣的系统提供的服务做出贡献。 感兴趣的系统与支持系统之间的相互关系可以是双向的， 也可以是单向的。除了与支持系统交互之外， 感兴趣的系统还可以与操作环境中的其他系统交互，如图 A、B 和 C 所示。感兴趣的系统的要求包括与支持系统和操作环境中的其他系统的接口要求。
系统 B操作环境
软件系统A 软件系统C在运作中 在运作中环境 环境
与互动包括以下系统 支持软件操作环境系统十
感兴趣的软件系统
启用系统
是
与支持系统的交支持软件互
系统是
图3 感兴趣的软件系统、其运行环境和支持系统
在软件生命周期的一个阶段，相关的支持系统和感兴趣的系统被一起考虑。由于它们相互依赖，因此也可以将它们视为一个系统。当不存在合适的支持系统时，负责感兴趣的系统的项目可以直接负责
创建和使用支持系统。创建支持系统可被视为一个单独的项目，随后再被视为另一个感兴趣的系统。
在 ISO/IEC/IEEE24748（所有部分）中关于生命周期过程的应用可以找到对这些概念的进一步阐述。
注：软件开发中的支持系统包括目标平台的软件开发和测试环境。
4 软件系统的生命周期流程
在软件系统中，系统级的需求、架构和设计过程导致将系统需求分配给各个元素。感兴趣的软件系统的实现主要通过分析软件系统需求、架构和设计，确定哪些功能将在软件中或其他元素中实现，实现软件和其他元素，并将这些元素集成为软件系统。因此，软件产品或服务可以被视为软件系统的一个元素。
在某些情况下，软件系统的架构定义可以表明将其视为一组不同的从属元素是适当的。反过来，每个软件元素都可以被视为一个不同的软件系统，如前所述。在这些情况下，可以递归地应用此文档来获取或开发从属元素。
本文档与 ISO/IEC/IEEE15288:2015、系统与软件工程有密切的关系系统生命周期过程， 更适用于软件系统。 为了解释 ISO/IEC/IEEE15288:2015 和 ISO/IEC/IEEE12207:2017 同时应用的情况（例如，开发包含软件的系统， 或开发包含硬件的软件系统）， 它们的过程结构被协调为相同。 本文档的流程直接对应于 ISO/IEC/IEEE15288 的流程，并专门针对软件产品和服务。
在系统非软件元素具有主要重要性的情况下，组织可以决定应用 ISO/IEC/IEEE15288 来执行适当的生命周期流程、活动和任务。对于系统的每个软件元素，组织可以应用此文档来创建、调整、获取或重用软件元素。