|
通用生命周期模型描述了一组生命周期阶段及其关系。在定义它时，我们描述了对每个阶段的成功至关重要的一些技术和管理活动。虽然这种活动到阶段的联系很重要，但我们也必须认识到这些活动之间的贯穿生命的关系，以确保我们采用系统方法。
系统工程、技术和管理活动定义在一组生命周期过程中。这些活动紧密相关，使我们能够描述它们之间的关系。在本主题中，我们将讨论关于生命周期模型中流程活动之间相互关系性质的许多观点。
一般来说，技术和管理活动是根据通用系统工程范例中描述的并发、迭代和递归的原则来应用的。这些原则在某种程度上重叠，可以被视为对确保我们能够采取整体系统方法的相同基本需要的相关观点，同时允许对我们的活动进行某种结构和顺序。下面展示的视图应该被视为不同SE作者展示这些重叠思想的方法的示例。
生命周期过程术语
过程
过程是为了达到某一特定目的而采取的一系列行动或步骤。流程可以由人或机器执行，将输入转换为输出。
在SEBoK中，过程以多种方式解释，包括:技术、生命周期、业务或制造流程过程。第3部分的很多部分都是按照技术过程(例如设计、验证)来构建的;然而，生命周期模型也描述了许多高级的程序生命周期序列，它们称之为过程(例如，rational统一过程(RUP)等)。
第4部分:系统工程的应用和第5部分:启用系统工程利用了与服务和企业操作相关的过程。
系统工程生命周期过程定义了跨一个或多个阶段执行的技术和管理活动，以提供作出生命周期决策所需的信息;并在必要时支持跨其生命周期模型的利益系统(SoI)的实现、使用和维护。生命周期模型和流程活动之间的关系可以用来描述SE如何应用于不同的系统上下文。
需求
需求是需要或想要的东西，但并非在所有情况下都是强制性的。要求可能指的是产品或过程特征或约束。对需求的不同理解依赖于过程状态、抽象级别和类型(例如功能、性能、约束)。随着时间的推移，单个需求也可能有多种解释。
需求存在于具有多个抽象级别的企业或系统的多个级别。这包括从最高级别的企业能力或客户需求到最低级别的系统设计。因此，需求需要在它们所应用的实体级别的适当细节级别上定义。请参阅生命周期过程和企业需求这篇文章，以获得关于跨概念定义和系统定义从企业到最低系统元素的需求和需求转换的进一步详细信息。
架构
体系结构是指系统的组织结构，系统可以在不同的上下文中定义。建筑设计是设计结构的艺术或实践。查看下面关于使用逻辑和物理体系结构模型级别来定义相关系统和系统元素的进一步讨论;并支持需求活动。
架构可以申请系统产品、企业或服务。例如，第3部分主要考虑系统工程师创建的产品或服务相关的体系结构，但是企业体系结构描述了组织的结构。第5部分:启用系统工程以比跨组织使用的IT系统更广泛的方式解释企业架构，IT系统是架构的一个特定实例。
框架与架构密切相关，因为它们是表示架构的方式。有关定义和示例，请参阅架构框架。
其他流程
以下提到了其他一些生命周期过程，包括系统分析、集成、验证、验证、部署、操作、维护和处置;它们在系统实现和系统部署与使用知识领域中进行了详细讨论。
生命周期过程并发
在通用生命周期模型中，我们列出了对成功完成每个阶段至关重要的关键活动。 这是说明每个阶段目标的有用方式，并指示流程如何与这些阶段保持一致。 这在考虑如何规划资源、里程碑等时可能很重要。但是，重要的是要注意流程活动的执行没有划分到特定的生命周期阶段（Lawson 2010）。
图 1 显示了技术和管理流程贯穿整个生命周期的简单说明。 该图直接建立在应用于工程系统的系统方法中描述的“驼峰图”原则之上。
图 1：生命周期阶段和流程之间的一般关系（根据 Lawson 2010 修改）
此图上的线条表示通用生命周期中每个流程的活动量。 活动的高峰（或驼峰）代表流程活动成为阶段主要焦点的时期。 这些峰值之前和之后的活动可能代表由过程焦点引起的贯穿整个生命周期的问题，例如，维护约束在系统需求中的表现可能性有多大。 这些考虑有助于在每个阶段保持更全面的观点，或者它们可以代表前瞻性规划，以确保完成未来活动所需的资源已包含在估计和计划中，例如验证所需的所有资源都已到位或可用。 确保以可实现的方式实施此驼峰图原则，
生命周期过程迭代
迭代的概念适用于生命周期模型中的生命周期阶段，也适用于流程。 下面的图 2 给出了与概念和系统定义相关的生命周期过程中的迭代示例。
图 2. 与系统定义相关的流程迭代示例（Faisandier 2012）。Sinergy'Com 授予的许可。所有其他权利均由版权所有者保留。
对问题或机会的探索与一个或多个可行解决方案的定义之间通常存在紧密的联系； 请参阅 工程系统的系统方法 。 因此，本例中的相关过程通常会以迭代的方式应用。 这些过程之间的关系在系统定义KA 中进一步讨论。
下面的图 3 给出了其他生命周期过程之间的迭代示例。
图 3. 系统实现。（SEBoK 原创）
此示例中的迭代与图 1 中所示的流程结果的重叠相关。它们允许考虑跨流程问题以影响系统定义（例如，考虑可能的集成或验证方法可能使我们考虑故障模式或添加数据收集或监控元素进入系统）或者它们允许风险管理和通过生命规划活动来识别未来活动的需要。
这些过程之间的关系在系统实现和系统部署使用中进一步讨论。
生命周期过程递归
SoI 的全面定义通常使用分解层和 系统元素来实现。 图 4 展示了系统分解结构的基本模式。
图 4. Sol系统的分层分解（Faisandie 2012）。Sinergy'Com 授予的许可。所有其他权利均由版权所有者保留。
在每个分解层和每个系统中，系统定义过程都是递归应用的，因为“系统”的概念本身就是递归的； SoI、系统和系统元素的概念基于相同的概念（参见第 2 部分）。 图 5 显示了生命周期过程的递归示例。
图 5. 层上流程的递归（Faisandie 2012）。Sinergy'Com 授予的许可。所有其他权利均由版权所有者保留。
解决方案综合的系统方法
上面的部分给出了关于 SE 生命周期过程如何相关以及这如何影响其应用的不同观点。 解决方案综合 在第 2 部分中描述为采用系统方法 来创建解决方案的一种方式。 一般来说，合成是自上而下和自下而上方法的混合，如下所述。
自上而下的方法：从问题到解决方案
在自上而下的方法中，概念定义活动主要集中在理解问题、问题空间内的操作需求/要求，以及限制解决方案和限制解决方案空间的条件。 概念定义活动确定任务上下文、 任务分析以及新的或修改后的系统（即 SoI）在该上下文中实现的需求，并解决利益相关者的需求和要求。
系统定义活动根据 概念定义的结果考虑一个或多个解决方案的功能、行为、时间和物理方面。系统分析考虑了所提出的系统解决方案的优缺点，包括它们如何满足概念定义中建立的需求，以及相对成本、时间尺度和其他开发问题。 这可能需要进一步细化概念定义，以确保所有与特定解决方案架构相关的遗留关系和利益相关者都已在利益相关者要求中得到考虑。
概念定义和系统定义之间的迭代结果定义了所需的系统解决方案及其关联的问题上下文，用于一个或多个解决方案实施的 系统实现、系统部署和使用以及产品和服务生命周期管理 。 在这种方法中，问题理解和解决方案选择活动在系统开发和设计的前端部分完成，然后在任何最终解决方案系统的整个生命周期中根据需要进行维护和改进。 自上而下的活动可以是顺序的、迭代的、递归的或进化的，具体取决于生命周期模型。
自下而上的方法：解决方案的演变
在某些情况下，概念定义活动决定了发展现有能力或向现有系统添加新能力的需要。 在概念定义期间，评估满足需求的替代方案。 然后引导工程师重新考虑系统定义，以便在产品或服务生命周期期间修改或调整某些结构、功能、行为或时间属性，以适应不断变化的使用环境 或改进现有解决方案。
逆向工程通常是必要的，以使系统工程师能够（重新）表征感兴趣系统 (SoI) 或其元素的属性。 这是确保系统工程师在开始修改之前了解 SoI 的重要步骤。 有关系统定义的更多信息，请参阅 系统定义文章。
出于分析目的或（重新）使用设计架构 中的现有元素，自下而上的方法是必要的 。 使用环境的变化或改进的需要会促使这一点。 相反，自上而下的方法通常用于定义与问题或一组需求相对应的初始设计解决方案。
解决方案合成
在大多数实际问题中，自下而上和自上而下的方法的结合提供了由需求驱动的创新解决方案思维和由现有事物驱动的受限和务实思维的正确组合。 这通常被称为“中间”方法。
作为最实用的方法，综合具有使生命周期专注于整个系统问题的潜力，同时允许探索描述可实现解决方案所需的重点细节水平； 有关更多信息， 请参阅 合成系统解决方案。 | 
