在执行系统工程活动时，重要的是要考虑过程和所需系统之间的相互关系。 正在生产的系统类型（请参阅系统类型 ）将影响所需的过程，如系统生命周期过程驱动程序和选择中所示。 这可能会导致对定义的过程进行剪裁，如系统工程标准的应用中所述。

过程和产品模型

生命周期模型 图 1 介绍了将过程执行提供的阶段工作产品视为不同生命阶段的感兴趣系统 (SoI) 版本的视角。 在任何人造系统的生命周期中发生的根本变化包括定义、生产和利用。 在这些基础上构建时，考虑通用过程和产品生命周期阶段模型的结构是有用的，如下图 1 所示。

图 1. 系统生命周期的通用 (T) 阶段结构（Lawson 2010）。 经 Harold “Bud” Lawson 许可转载。 所有其他权利均由版权所有者保留。

(T) 模型表示定义阶段先于 已完成两个或多个系统元素的实施（获取、供应或开发）的生产阶段。 系统元素根据定义的关系集成到 SoI 中。 因此，描述了过程和产品方面。 在提供初级阶段结果（即在组装的系统产品或服务实例中）时遵循实施和集成过程。 但是，如生命周期模型 中所述，在开发阶段提供的 SoI 定义也可以是系统第一版的结果。 例如，一个 原型，这可以被视为生产或预生产阶段的一种形式。 生产阶段之后是利用阶段。 其他相关阶段可以包括支持和退休。 请注意，此模型还显示了定义与实现和集成之间的重要区别。

根据ISO/IEC/IEEE 15288(2015)，这种结构对于任何类型的人造 SoI 进行生命周期管理都是通用的。 因此，生产阶段成为 (T) 模型的焦点，在该模型中，系统元素被实现并根据定义集成到系统产品或服务实例中。 对于已定义的物理系统，这是制造和组装产品实例（单独或批量生产）的点。 对于非物理系统，实现和集成过程在被实例化以提供服务之前用于服务准备（建立）。 对于软件系统，这是生成将软件元素组合成版本、发行版或其他形式的托管软件产品的构建点。

使用递归分解 ，每个系统元素的实现可以涉及在下一个最低级别再次调用标准，从而将系统元素本身视为一个 SoI。 然后将新的生命周期结构用于较低级别的 SoI。

这在 Dual Vee 模型中得到了说明（图 2a 和 2b）。 Dual Vee 模型是一种三维系统开发模型，在系统和组件架构的创建中集成了产品和过程。 它强调

• 同时进行机会和风险管理；
• 用户进程内 验证；
• 集成、验证和确认计划；
• 验证问题解决。

当分解根据实际需要和风险收益分析终止时，系统元素将根据所涉及的元素类型实施（获取、供应或开发）。

图 2a。 Dual Vee 模型 (2a) (Forsberg, Mooz, Cotterman 2005)。 经 John Wiley & Sons Inc. 许可转载。版权所有者保留所有其他权利。

图 2b。 双 Vee 模型 (2b) (Forsberg, Mooz, Cotterman 2005)。 经 John Wiley & Sons Inc. 许可转载。版权所有者保留所有其他权利。

可能影响过程和产品方面的一个实际方面是决定以商业现货 (COTS) 形式使用现货元件。 在这种情况下，不需要进一步分解元素。 COTS 元素（及其内部创建的邻居或非开发项目 (NDI)）的使用已变得广泛，并且已经证明了它们的价值。 但是，开发人员必须确保 COTS 产品适合他们的环境。

在预期环境中正常使用产品时不经常发生的已知缺陷可能是良性的并且易于处理。 在新的情况下，它可能会产生巨大的不利后果，例如 1998 年在 USS Yorktown Cruiser 上发生的后果（Wired News Contributors 1998）。 客户要求将 Windows NT 用作该船的主要操作系统。 除以零 故障 导致操作系统发生故障，船在水中死去。 它不得不被拖回港口三次。

螺旋模型不仅可以同时设计过程和产品模型，还可以设计属性和成功模型。图 3 显示了这些模型如何在里程碑审查和做出个别模型选择 时提供制衡。 “当模型碰撞时：软件系统分析的教训”（Boehm 和 Port 1999）、“避免软件模型冲突蜘蛛网”（Boehm、Port 和 Al-Said 2000）和“在软件系统开发过程中检测模型冲突”（Al-Said 2003）。

图 3. 过程模型、产品模型、成功模型、属性模型的螺旋模型支持（Boehm 和 Port 1999）。 经© 版权所有 IEEE 许可转载 - 保留所有权利。 所有其他权利均由版权所有者保留。

对于软件系统，进入生产阶段是创建将软件元素（代码模块）组合成版本、发布或其他形式的托管软件产品的构建点。 因此，一般系统和软件系统之间的主要区别是一般模型的轻微变体，如图 4 所示。

图 4. 软件系统的 T 模型（Lawson 2010）。 经 Harold “Bud” Lawson 许可转载。 所有其他权利均由版权所有者保留。

阶段执行顺序

生命周期阶段的顺序执行是最直接的。 如系统生命周期过程模型：Vee 和 系统生命周期过程模型：迭代 ，当实际考虑需要非线性执行生命周期阶段时，Vee 模型和螺旋模型的变体提供非顺序模型。 在这两个模型的基础上，重要的是要注意各种类型的复杂系统需要在获得洞察力（知识）以及利益相关者需求发生变化时重新审视生命周期模型的各个阶段。 迭代可能涉及过程和产品或服务系统中的必要更改。 因此，在 (T) 阶段模型的上下文中，可以方便地描述阶段执行的各种顺序——反映非顺序阶段顺序的形式——如图 5 所示。

图 5. 生命周期阶段的迭代（Lawson 2010）。 经 Harold “Bud” Lawson 许可转载。 所有其他权利均由版权所有者保留。

阶段执行的每个模式都涉及先前阶段的迭代，可能对过程或系统的要求有所改变。 图 5 中的粗线表示重新访问的端点的分界线。 三种是迭代形式，可以从中提取几个变体：

1. 为了评估涉众需求、分析需求和开发可行的架构设计，经常部署 迭代开发。 因此，通常在开发阶段可能会重新审视概念阶段。 对于产品基于物理结构（电子、机械、化学品等）的系统，生产开始后的迭代可能涉及大量成本和进度延迟。 因此，重要的是让它 “正确” 在开始生产之前。 因此，早期阶段用于建立信心（验证和验证）解决方案正常工作并将满足利益相关者的需求。 自然，这种方法也可以用于软件和人类活动系统； 然而，由于它们的柔软性，通过试验和评估系统的各种配置来进一步发展可能是有用的。
2. 迭代开发和实现 涉及生产（定义、实施和集成）系统的各种版本，评估它们满足利益相关者要求的程度，可能是在需求变化的背景下，然后重新审视概念和/或开发阶段。 这种迭代在软件系统开发中是典型的，其中生产成本不像定义的物理系统那么重要。 这种方法的一个变体是螺旋模型，其中连续的迭代填充了更多细节（Boehm 和 May 1998）。 使用这种方法需要仔细注意与基线和配置管理相关的问题。 在这种方法中，应该对软件系统进行重要的验证（测试），以建立对交付的系统将满足利益相关者要求的信心。
3. 增量或渐进式采集 涉及以产品和/或服务的形式向消费者发布系统。 当部署后以受控方式预期结构和能力（功能）变化时，这种方法是合适的。 使用这种方法可能是因为在开始时不了解所有需求，这会导致逐步获取/部署，或者是因为决定处理系统的复杂性及其增量使用（即增量获取）。 这些方法对于软件是重要系统元素的复杂系统至关重要。 每个增量都涉及重新审视定义和生产阶段。 这些方法的使用必须基于供应商和收购企业之间明确的、商定的关系。 实际上，

在所有方法中，明智的做法是使用建模和仿真技术以及相关工具来帮助理解在生命周期管理的复杂系统中所做的更改的影响。 这些技术通常部署在早期阶段； 但是，它们可用于深入了解与后期使用和维护相关的潜在问题和机会（例如，了解所需的后勤和服务台方面）。

分配和满足需求 - 过程和产品模型的集成

无论生命周期阶段的执行顺序如何，系统的涉众需求，包括每次迭代中的变更需求，都必须分配到项目中各个阶段使用的过程的适当活动中，以及分配到项目元素的属性中。产品系统或服务系统及其定义的关系。 此分布在 Lawson 的 T 模型的第四个变体中进行了说明，如 系统生命周期过程模型：迭代 和 系统生命周期过程模型：Vee 中所述。

理想情况下，项目管理团队应该实施经过验证的过程，将技术过程模型与项目管理产品模型集成起来，以管理前面讨论的任何过程，包括增量和渐进式开发。 显示的过程是项目管理过程，从开发阶段的开始（Forsberg、Mooz 和 Cotterman 2005、201）开始。

图 6a。 新产品规划过程——入门（Forsberg、Mooz 和 Cotterman 2005）。 经 John Wiley & Sons Inc. 许可转载。版权所有者保留所有其他权利。

图 6b。 解决问题的新产品规划过程（Forsberg、Mooz 和 Cotterman 2005）。 经 John Wiley & Sons Inc. 许可转载。版权所有者保留所有其他权利。

图 6c。 新产品规划过程——获得承诺（Forsberg、Mooz 和 Cotterman 2005）。 经 John Wiley & Sons Inc. 许可转载。版权所有者保留所有其他权利。