|
正如在系统生命周期过程驱动和选择文章中所讨论的，这些模型分为三个主要类别:(1)主要是预先指定的和顺序的过程，Vee模型;(2)演化过程和并行过程(如敏捷统一过程和螺旋模型);(3)主要是人际关系和不受约束的过程(例如，敏捷开发、Scrum、极限编程(XP)、动态系统开发方法和基于创新的过程)。
本文特别关注Vee模型，将其作为预先指定的顺序过程的主要示例。在此讨论中，重要的是要注意Vee模型，以及Vee模型的变体，都处理相同的系统工程(SE)活动的基本集合。这些模型之间的主要区别在于它们对上述SE活动进行分组和表示的方式。
在系统设计和开发中使用Vee模型的一般含义将在下面讨论;对于生命周期模型如何影响系统工程活动的更具体的理解，请参阅第3部分中的其他知识领域(KAs)。
主要预先指定的顺序过程模型:Vee模型
Vee模型的顺序版本如图1所示。它的核心涉及计划、规范和产品的连续发展，这些都是基线化的，并置于配置管理之下。垂直的双头箭头使项目能够执行并行的机会和风险分析，以及持续的过程验证。Vee模型包括INCOSE系统工程手册的“通用生命周期阶段及其目的和决策门选项”表中列出的前两个生命周期阶段:概念和开发(INCOSE 2015)。图1需要替换为手册版本4中的图3.7。
图 1. 序列 Vee 模型的左侧（Forsberg、Mooz 和 Cotterman 2005）。 经 John Wiley & Sons Inc. 许可转载。版权所有者保留所有其他权利。
Vee 模型支持 INCOSE 系统工程手册 (INCOSE 2015) 对生命周期阶段及其目的或活动的定义，如下图 2 所示。 将图 2 替换为删除第一个探索阶段的更新图。
图 2. 阶段、目的和主要决策门的示例。 （SEBoK 原创）
Vee 图的更详细版本将生命周期活动合并到更通用的 Vee 模型中。 这个由美国国防采办大学 (DAU) 开发的 Vee 图如下图 3 所示。
图 3. Vee 活动图（Prosnik 2010）。 由国防采办大学 (DAU)/美国国防部 (DoD) 发布。
Vee模型的应用 Lawson (Lawson 2010) 详细阐述了每个生命周期阶段的活动，并指出对于任何类型的感兴趣系统 (SoI) 考虑通用生命周期阶段模型的结构是有用的，如图 4 所示。 (T) 模型表示一个或多个定义阶段先于已完成两个或多个系统元素的实施（获取、供应或开发）的生产阶段。
图 4. 系统生命周期模型的通用 (T) 阶段结构（Lawson 2010）。 经 Harold Lawson 许可转载。 所有其他权利均由版权所有者保留。
在下面的讨论中，Ryan 进一步定义了一组通用术语来定义需要和要求的级别，并将它们与通用组织角色相关联。 有关此一般描述如何映射到不同应用程序上下文或组织结构的讨论，请分别参见 第 4 部分和 第 5 部分 。 图 1 中的各种视图称为层。 在最高层，企业有许多指导其未来的战略。 例如，在上面的插图中，系统起源于运营概念(ConOps) 或战略业务计划 (SBP)，它传达了领导层关于现有系统和待定系统的组织运营的意图。发达。 在这一层，ConOps 或 SBP 用“品牌”来定义企业，并
图 5 显示了从标准组织 (ISO/IEC) 到商业和政府组织的各种利益相关者的通用生命周期阶段。 尽管这些阶段在细节上有所不同，但它们都具有相似的顺序格式，强调如图 2 所示的核心活动（概念、生产和利用/退役）。 图 5 需要更新，通用生命周期已过时。
图 5. 生命周期模型的比较（Forsberg、Mooz 和 Cotterman 2005）。经 John Wiley & Sons 许可转载。所有其他权利均由版权所有者保留。
需要注意的是，整个生命周期中的许多活动都是迭代的。这是第3部分简介中讨论的递归(术语表)示例。
生命周期阶段和项目管理阶段的基础
对于本次讨论，重要的是要注意：
- 阶段一词 是指系统在其生命周期中的不同状态； 有些阶段可能会在时间上重叠，例如利用阶段和支持阶段。ISO/IEC/IEEE 15288 中使用了术语“阶段” 。
- 阶段 一词 是指支持和管理系统生命周期的程序的不同步骤； 这些阶段通常不重叠。 “阶段”一词在许多成熟的模型中被用作“阶段”一词的等价物。
程序管理采用阶段、里程碑和 决策门 ，用于评估系统在各个阶段的演变。 阶段包含为实现目标而执行的活动，并用于控制和管理阶段的顺序以及每个阶段之间的转换。 对于每个项目，必须定义和发布用于各个项目的术语和相关定义，以尽量减少混淆。
一个典型的程序由以下阶段组成：
- 可行性阶段 包括在开始执行阶段之前研究替代概念的 可行性以达到第二个决策门。 在可行性阶段，确定利益相关者的要求和系统要求，确定和研究可行的解决方案，并实施虚拟 原型（词汇表）。 在此阶段，继续前进的决定基于：
- 一个概念是否可行并被认为能够应对已识别的威胁或利用机会；
- 一个概念是否足够成熟以保证新产品或产品线的持续开发； 和
- 是否批准响应提案请求而生成的提案。
- 执行阶段 包括与系统生命周期的四个阶段相关的活动： 开发 、生产、利用和支持 。 通常，有两个决策门和两个与执行活动相关的里程碑。 第一个里程碑为管理层提供了在批准之前审查执行计划的机会。 第二个里程碑提供了在决定开始生产之前审查进度的机会。 执行期间的决策门可用于确定是否生成已开发的 SoI 以及是否对其进行改进或淘汰。
这些项目管理视图不仅适用于 SoI，还适用于其元素和结构。
生命周期阶段
Vee 模型的变体处理生命周期的相同一般阶段：
- 新项目通常从探索性研究阶段开始，该阶段通常包括概念定义 活动，特别是业务或任务分析 的主题以及对利益相关者需求和要求的理解。 这些随着项目从探索阶段到概念阶段再到开发阶段而成熟。
- 生产阶段包括系统定义和系统实现的活动，以及 通过验证和确认开发系统需求（术语表）和 体系结构（术语表）。
- 利用阶段包括 系统部署和系统运行的活动。
- 支持阶段包括系统维护、 物流以及产品和使用寿命管理 等活动，其中可能包括使用寿命延长或 能力更新、升级和现代化等活动。
- 报废阶段包括处置和报废 活动，但在某些模型中， 使用寿命延长或 能力更新、升级和现代化等活动被归入“报废”阶段。
可以在以下部分中找到有关每个阶段的其他信息（有关更多详细信息，请参阅上面第 3 部分其他文章的链接）。 值得注意的是，这些生命周期阶段以及每个阶段的活动都由一组系统工程管理过程支持。
概念阶段
用户需求分析和协议是概念阶段的一部分，对于成功系统的开发至关重要。 如果没有正确理解用户的需求，任何系统都会冒着被构建来解决错误问题的风险。 概念阶段的第一步是定义用户（和利益相关者）的要求和约束。 此过程的一个关键部分是确定满足用户要求的可行性，包括技术准备情况评估。 与许多 SE 活动一样，这通常是反复进行的，并且随着新信息的可用，利益相关者的需求和要求会被重新审视。
国家研究委员会最近的一项研究（国家研究委员会 2008 年）侧重于减少美国空军项目的开发时间。 报告指出，“简单地说，系统工程就是通过迭代过程将用户的需求转化为系统及其架构的定义，从而产生有效的系统设计。” 利益相关者的反复参与对项目的成功至关重要。
除了项目的第一个和最后一个决策门外，这些门是同时执行的。 请参见下面的图 6。
图 6. 安排开发阶段。 （SEBoK 原创）
在 概念阶段，创建替代概念以确定满足利益相关者需求的最佳方法。 通过设想替代方案和创建模型，包括适当的原型，利益相关者的需求将被阐明并突出驱动问题。 这可能导致系统开发的增量或进化方法。 可以并行探索几个不同的概念。
发展阶段
在概念阶段确定的选定概念被详细阐述到最低级别，以产生满足利益相关者要求的解决方案。 在整个这个阶段，通过过程内验证（Vee 模型上的向上箭头）继续让用户参与是至关重要的。 在硬件上，这是通过频繁的程序审查和客户常驻代表（如果适用）来完成的。 在敏捷开发中，实践是将客户代表整合到开发团队中。
生产阶段
生产阶段是构建或制造 SoI 的地方。 可能需要对产品进行修改以解决生产问题、降低生产成本或增强产品或 SoI 功能。 这些修改中的任何一个都可能影响系统要求，并可能需要系统重新 确认、重新验证 。 所有此类更改都需要在更改获得批准之前进行 SE 评估。
利用阶段
产品生命周期管理的一个重要方面是提供对维持产品运行至关重要的支持系统。 虽然提供的产品或服务可能被视为收购方的狭义利益系统 (NSOI) ，但 收购方还必须将支持系统纳入更广泛的利益系统 (WSOI)。 这些支持系统应被视为系统资产，在需要时激活以响应在 NSOI 运行方面出现的情况。 这套支持系统的统称是综合后勤支持（ILS）系统。
在定义、生产和操作系统产品和服务时，拥有一个整体视图至关重要。 图 7 描绘了系统设计和开发与 ILS 要求之间的关系。
图 7. 将 ILS 与系统生命周期相关联（Eichmueller 和 Foreman 2009） 。 经 ASD/AIA S3000L 指导委员会许可转载。 所有其他权利均由版权所有者保留。
对可靠性的要求，导致需要可维护性和可测试性，是驱动因素。
支持阶段
在支持阶段，向 SoI 提供支持持续运行的服务。 可以提出修改以解决可支持性问题、降低运营成本或延长系统的寿命。 这些变化需要 SE 评估，以避免在运行时丢失系统功能。 相应的技术流程是维修流程。
退休阶段
在退役阶段，SoI 及其相关服务将从运营中移除。 这一阶段的 SE 活动主要侧重于确保满足处置要求。 事实上，处置计划是概念阶段系统定义的一部分。 20 世纪的经验一再证明，如果从一开始就没有考虑系统报废和处置的后果。 在 21 世纪初期，许多国家已经修改了法律，要求 SoI 的创建者对系统的正确报废处置负责。
生命周期评论
为了控制项目的进度，计划了不同类型的审查。 最常用的列举如下，虽然名称并不通用：
- 系统 需求审查 (SRR) 计划在开始详细设计活动之前验证和确认系统需求集。
- 初步设计评审 ( PDR) 计划在第一个工程循环（也称为“设计到”门）结束时验证和验证系统需求集、设计工件和论证元素。
- 关键设计评审 ( CDR) 计划在最后一个工程循环结束时验证和验证一组系统需求、设计工件和论证元素（发布“构建”和“代码”设计经过这次审查）。
- 随着 组件组装到更高级别的子系统和元素中，计划了集成、验证和 确认审查。 进行一系列审查，以确保所有内容都正确集成，并且有客观证据表明所有要求都已得到满足。 还应该有一个过程中的验证系统，随着它的发展，将满足利益相关者的要求（参见图 7）。
- 最终验证审查在集成阶段结束时进行。
- 根据系统类型和相关风险，可以计划和执行其他与管理相关的审查，以控制工作的正确进展。
图 8. Vee 模型的右侧（Forsberg、Mooz 和 Cotterman 2005）。 经 John Wiley & Sons Inc. 许可转载。版权所有者保留所有其他权利。
| 
