正如在通用生命周期模型文章中所讨论的，有许多组织因素会影响哪些生命周期流程适合于特定的系统。此外，技术因素也会影响适合于给定系统的生命周期模型的类型。例如，系统需求可以是预先确定的，也可以是变化的，这取决于系统开发的范围和性质。这些考虑导致了不同的生命周期模型选择。本文讨论了在选择生命周期过程模型时可以考虑的不同技术因素，并从文献中提供了示例、指南和工具来支持生命周期模型的选择。所选择的生命周期模型可以影响系统设计和开发的所有其他方面。(请参阅第3部分中的知识领域，了解生命周期如何影响系统工程(SE)过程的描述。)

固定需求和进化开发过程

除了传统的、预先指定的、顺序的、单步开发过程（被确定为固定需求）之外，还有几种 演化模型开发过程； 然而，没有一种万能的方法最适合所有情况。 对于快速部署的情况，最简单的原型设计方法可能是最合适的。 对于持久的系统，最简单的方法可能会产生一个不可扩展的系统，其中架构无法实现高水平的性能、安全性或安全性。 一般来说，系统演进现在需要更高水平的 SE 工作、更早和持续的集成和测试、解决系统变化源的主动方法、更高水平的并行工程以及基于可行性证据与计划和系统描述的成就审查.

自 1960 年代（也许更早）以来，进化开发过程或方法就一直在使用。 它们允许项目提供初始能力，然后连续交付以达到所需 的相关利息系统 (SoI)。 这种做法在以下情况下特别有价值

• 需要快速探索和实施部分系统；
• 需求从一开始就不清楚，或者正在迅速变化；
• 资金有限；
• 客户希望在 SoI 成熟时对插入新技术的可能性持开放态度；
• 需要进行实验来开发连续的版本。

在渐进式开发中，产品的能力是随着时间的推移而开发的。 增量的每个周期都包含前一个增量的系统元素，并为不断发展的产品添加新功能，以创建开发中产品的扩展版本。 这种使用增量的渐进式开发过程可以提供许多优势，包括

• 不断集成、验证和确认不断发展的产品；
• 经常展示进步；
• 及早发现缺陷；
• 工艺问题的早期预警；
• 系统地纳入可能发生的不可避免的返工。

增量和进化发展的主要模型

增量和进化发展的主要模型侧重于不同的竞争和技术挑战。 每个模型的时间阶段如下图 1 所示，根据定义 (Df)、开发 (Dv) 和生产、支持和利用 (PSU) 的增量 (1, 2, 3, ...) 内容) 生命周期模型 文章 中图 1（通用系统生命周期模型）中的阶段。

图 1. 增量和进化发展的主要模型。（SEBoK 原创）

图 1 的符号（Df1..N 和 Dv1..N）表明，它们的初始阶段不仅针对第一个增量，而且针对整个增量集产生规范。 假设这些对于预先指定的顺序模型保持稳定，但预计会涉及进化并发模型的变化。 后者的符号（Dv1 和 Df2R）在同一时间范围内，PSU1、Dv2 和 Df3R 在同一时间范围内等）表明系统工程团队正在重新确定下一个增量的计划和规范，同时与当前增量的发展和前一个增量的PSU。 这减轻了开发团队处理变更流量的工作，并显着提高了按预算和进度完成当前增量的机会。

为了选择合适的生命周期模型，首先要了解主要原型以及它们的最佳使用位置，这一点很重要。 表 1 根据示例、优势和劣势总结了单步、增量和进化开发的每个主要模型，并附有解释性说明。

表 1. 增量和进化发展的主要模型 (Boehm, et. al. 2014, page 73)。

表 1 中的 预先指定的单步 和 预先指定的多步 模型不是进化的。 预先指定的多步骤模型将开发拆分，以实现早期的初始操作能力，然后是几个预先计划的产品改进 (P3I)。 另一个版本将工作拆分，但不包含中间增量。 当需求被很好地理解和稳定时，预先指定的模型可以实现强大的、可预测的过程。 当需求出现和/或快速变化时，如果它们导致撤销架构承诺，它们通常需要昂贵的返工。

进化 顺序 模型涉及一种方法，在这种方法中，系统的初始操作能力迅速发展，并根据操作经验进行升级。 纯敏捷软件开发适合这种模式。 如果某些事情没有达到预期并需要更改，它将在下一次发布时在 30 天内修复。 快速部署也适合这种模型，适用于更大的或硬件软件系统。 它的主要优势是能够在现场实现快速响应能力。 对于纯敏捷，该模型可能会成为最简单的架构承诺的牺牲品，例如，当系统开发人员试图将工作负载扩大 10 倍或在以后的增量中添加安全性作为新功能时，这些承诺就会中断. 为了快速部署，

进化 机会主义 模型可以在涉及推迟下一个增量的情况下采用，直到：一个足够有吸引力的机会出现，所需的新技术足够成熟，可以添加，或者直到其他促成因素（如稀缺组件或关键人员）可用。 它也适用于同步升级多个商用现货 (COTS) 产品。 在等待推动者的同时将 SE 和开发团队保持在一起可能会很昂贵，但同样，这可能是值得的。

进化 并发 模型涉及一组系统工程师同时处理变更流量并为下一个增量重新定义计划和规范，以保持当前增量开发稳定。 下面的表 2 中提供了一个示例和讨论。

增量和进化发展决策表

表 2 提供了一些标准，用于决定使用哪些与主要类别的增量和进化开发模型相关的过程。

表 2. 增量和进化发展决策表。 （Boehm 等人，2014 年，第 74 页）。 经许可转载。

*示例促成因素：技术成熟度； 外部系统能力； 所需资源； 新的机会

如果产品的需求是可预先指定的并且发生重大变化的可能性很小并且没有价值或机会交付部分产品功能，则以传统瀑布或顺序 Vee 模型为例 的 预先指定的单步过程是合适的。 一个很好的例子是地球资源监测卫星的硬件，它在进入轨道后将无法修改。

预先指定的多步骤 流程 将开发拆分，以实现早期初始操作能力和多个 P3I。 最好能提前指定产品的全部功能，并且发生重大变化的可能性很小。 这在等待开发完整系统导致失去重要且可交付的增量任务能力的情况下很有用。 这方面的一个很好的例子是星载地球资源监测卫星的软件升级的易于理解和优先排序的序列。

进化 顺序 过程开发初始操作能力并根据操作经验对其进行升级，例如敏捷方法。 当需要在定义和开发下一个增量内容之前获得关于初始能力的操作反馈时，最需要它。 一个很好的例子是卫星有效载荷经验所建议的软件升级，例如哪种多光谱数据收集和分析能力最适合哪种天气条件下的哪种农业。

进化 机会主义 过程推迟下一个增量，直到它的新功能可用并且成熟到可以添加。 当增量不需要等待运营反馈时，最好使用它，但它可能需要等待下一个增量促成因素，例如技术成熟度、外部系统能力、所需资源或新的增值机会。 一个很好的例子是需要等待基于代理的卫星异常趋势分析和任务适应软件在将其纳入计划增量之前变得可预测地稳定。

如图 2 所示，在增量承诺螺旋模型（Pew 和 Mavor 2007；Boehm 等人，2014，第 75 页）中实现 的 进化并发 流程有一个持续的系统工程师团队来处理变更流量和重新- 为下一个增量制定计划和规范，同时保持开发团队稳定，以按时、高保证地交付当前增量，并采用并行 验证 和 确认 (V&V) 团队执行持续的缺陷检测，以实现更高的保证水平。 一个很好的例子是卫星的地面任务控制和数据处理软件的下一个增量重新基线以适应新的 COTS 版本和用户对数据处理升级的持续请求。

卫星示例说明了未来的复杂系统、系统的不同部分及其软件可能以多种方式演变的各种方式，再次肯定了软件没有一刀切的过程进化。 但是，表 2 在确定哪些过程最适合发展系统的每个部分时非常有帮助。 此外，图 2 中的三团队模型为项目提供了一种开发未来具有挑战性的软件密集型系统的方法，这些系统既需要适应快速变化，又需要高水平的保证。

图 2. 进化并发快速变化处理和高保证（Pew 和 Mavor 2007，图 2-6）。 经美国国家科学院许可转载，由华盛顿特区国家科学院出版社提供 所有其他权利均由版权所有者保留。