大量的生命周期过程模型，正如在系统生命周期过程驱动和选择文章中所讨论的，这些模型分为三个主要类别:

(1)主要是预先指定的和顺序的过程(Vee模型);

(2)主要是进化和并发的过程(如敏捷统一过程和螺旋模型);

(3)人际关系和无约束或增量过程(例如，敏捷开发、Scrum、极限编程(XP)、动态系统开发方法和基于创新的过程)。

本文讨论了Vee模型变体之外的演化和增量开发模型(上面列出的第二和第三类)。虽然有许多描述项目环境的不同模型，但是螺旋模型和Vee模型已经成为可视化开发过程的主要方法。Vee和螺旋都是有用的模型，它们强调系统生命周期的不同方面。

在系统设计和开发中使用增量模型的一般含义将在下面讨论。对于生命周期模型如何影响系统工程活动的更具体的理解，请参阅第3部分中的其他知识领域(KAs)。本文主要关注增量生命周期过程模型在系统工程中的使用。(请参阅第6部分中的系统工程和软件工程，以获得关于软件工程中生命周期含义的更多信息。)

循序渐进的发展

进化方法概述

一种称为进化开发的特定方法在政府和业务部门的研发 (R&D) 环境中很常见。 图 1 说明了这种方法，该方法用于 NASA 航天飞机的高温瓦片的演变（Forsberg 1995）。 在进化方法中，每个开发阶段的最终状态都是未知的，尽管每个阶段的目标是产生某种有用的产品。

图 3. 进化通用模型 (Forsberg, Mooz, Cotterman 2005)。经 John Wiley & Sons, Inc. 许可转载。版权所有者保留所有其他权利。

现实世界的开发环境复杂且难以映射，因为许多不同的项目周期同时进行。

增量方法概述

自 1960 年代（也许更早）以来，就一直在使用增量开发方法。 它们允许项目提供初始能力，然后连续交付以达到所需的相关利益系统(SoI)。

图 2 所示的增量方法用于以下情况：

• 需要快速探索和实施部分系统；
• 需求从一开始就不明确；
• 资金有限；
• 客户希望让 SoI 对以后插入新技术的可能性持开放态度；
• 需要进行实验来开发连续的原型（词汇表）版本。

将增量与单程、计划驱动的方法区分开来的属性是速度和适应性。

图 1. 多次交付的增量开发（Forsberg、Mooz 和 Cotterman 2005）。 经 John Wiley & Sons Inc. 许可转载。版权所有者保留所有其他权利。

如果在生命周期的早期就知道需求，那么增量开发本质上也可能是“计划驱动的”。 功能的开发是增量执行的，以允许插入最新技术或潜在的需求或需求变化。 增量发展也施加了限制。 图 3 所示的示例使用增量早期开发高风险子系统（或组件），但在所有增量完成之前系统无法运行。

图 2. 单次交付的增量开发（Forsberg, Mooz, Cotterman 2005）。 经 John Wiley & Sons Inc. 许可转载。版权所有者保留所有其他权利。

建议将此图和部分移至 SEBoK 的案例研究部分。--- 图 4 显示了航天飞机轨道器开发的应用研究时代，并说明了多层次的同时开发、贸易研究，最终，执行。

图 4. 在创建大型“单程”项目期间组件和轨道器子系统（包括航天飞机瓦片）的演变（Forsberg 1995）。 经 Kevin Forsberg 许可转载。 所有其他权利均由版权所有者保留。

建议将此信息移至第 6 部分，除非它是多余的或过时的。---

迭代软件开发过程模型

软件是一种灵活且具有延展性的媒介，与 系统的纯物理组件相比，它在更大程度上促进了迭代 分析、 设计、 构建、 验证和 确认。迭代开发模型的每次重复都会为不断增长的软件库添加材料（代码）； 扩展的代码库经过测试，必要时重新设计，并证明满足基线需求。

软件开发过程模型支持不同长度周期的迭代开发。 表 1 列出了三个迭代软件开发模型，下面将详细介绍这些模型，以及这些模型所强调的软件开发方面。

请注意，以下信息专门针对软件系统的不同生命周期模型的使用。 为了更好地理解软件工程 (SwE) 和系统工程 (SE) 之间的交互，请参阅第 6 部分中的系统工程和软件工程 KA 。

迭代开发过程模型概述

开发和修改软件涉及受许多外部和可变力量影响的创造性过程。 长期经验表明，不可能第一次就“做对”，迭代开发过程优于线性顺序开发过程模型，例如著名的瀑布模型。 在迭代开发中，迭代的每个周期都包含上一次迭代的软件，并为不断发展的产品添加新功能，以创建软件的扩展版本。 迭代开发过程具有以下优点：

• 不断集成、验证和确认不断发展的产品；
• 经常展示进步；
• 及早发现缺陷；
• 工艺问题预警；
• 系统地整合软件开发中不可避免的返工；
• 尽早交付子集功能（如果需要）。

SwE 中的迭代开发有多种形式，包括：

• 增量构建过程，用于生成增加产品功能的定期（通常是每周）构建；
• 敏捷开发，用于使原型客户密切参与可能每天重复的迭代过程； 和
• 螺旋模型，用于应对和减轻在开发产品的连续版本时遇到的风险因素。

增量构建模型

增量构建模型是迭代周期的构建-测试-演示模型，其中强调了对进度的频繁演示、验证和对最新工作的验证。 该模型基于稳定的需求和软件架构规范。 每次构建都会为不断增长的产品添加新功能。 当最终版本被客户验证、验证、演示和接受时，该过程结束。

表 2 列出了一些将增量开发划分为（通常）每个日历周的增量构建单元的划分标准。 增量和可用于项目的开发人员数量决定了每个增量构建中可以包含的功能数量。 这反过来又决定了整个时间表。

图 5 说明了增量构建过程中构建-验证-验证-演示周期的详细信息。 每个构建都包括由开发人员完成的详细设计、编码、集成、审查和测试。 在无需修改即可重用代码的情况下，增量构建的部分或全部可能包括对使用重用代码进行扩充的基本代码的审查、集成和测试。 重要的是要注意，增量的开发可能会导致对以前为集成而开发的组件进行返工以修复缺陷。

图 5. 增量构建-验证-验证-演示周期（Fairley 2009）。 经 IEEE 计算机协会和 John Wiley & Sons Inc. 许可转载。版权所有者保留所有其他权利。

如图 5 所示，增量验证、确认和演示通过以下方式克服了瀑布方法的两个主要问题：

• 及早暴露问题，以便在问题发生时予以纠正； 和
• 将由于后续构建中的增量演示而发生的对需求的微小范围内更改。

图 5 还说明了可以重叠产品的连续构建。 例如，可以在验证当前版本的同时开始下一个版本的详细设计。

三个因素决定了可以实现的重叠程度：

1. 人员可用性；
2. 上一个版本有足够的进展；
3. 由于对先前正在进行的构建的更改，下一个重叠构建的重大返工的风险。

增量构建过程通常适用于小型团队，但可以针对大型项目进行扩展。

增量构建过程的一个显着优势是，首先构建的功能得到最频繁的验证、验证和演示，因为后续构建包含了早期迭代的功能。 例如，在构建控制核反应堆的软件时，可以先构建紧急关闭软件，然后结合每个后续构建的功能对其进行验证和验证。

总之，与所有迭代模型一样，增量构建模型具有以下优势：持续集成和验证不断发展的产品、频繁展示进度、早期预警问题、提前交付子集功能，以及系统地整合不可避免的返工发生在软件开发中。

原型在软件开发中的作用

在 SwE 中， 原型 是系统某些部分所需功能的模型。 这与物理系统形成对比，其中原型通常是系统的第一个全功能版本（Fairley 2009, 74）。

过去，将原型软件整合到生产系统中会产生许多问题。 原型设计是一种有用的技术，应酌情采用； 然而，原型设计 并不是 软件开发的过程模型。 在构建软件原型时，通过原型开发获得的知识对程序是有益的； 但是，原型代码可能不会在系统的可交付版本中使用。 在许多情况下，使用通过原型设计获得的知识从头开始构建生产代码比重新设计现有代码更有效和更有效。

软件的生命周期维护

与所有系统一样，软件需要持续努力来增强能力、适应新环境和纠正缺陷。 软件的主要区别在于维护工作改变了软件。 与物理实体不同，软件组件不必因为物理磨损而更换。 更改软件需要重新验证和重新验证，这可能涉及广泛的回归测试以确定更改具有预期的效果并且没有改变功能或行为的其他方面。

软件退化

有用的软件很少被淘汰； 但是，有用的软件在其生命周期中经常会经历多次升级。 更高版本可能与初始版本几乎没有相似之处。 在某些情况下，在以前的操作环境中运行的软件在硬件模拟器上执行，这些模拟器在较新的硬件上提供虚拟机。 在其他情况下，主要增强功能可能会替换和重命名软件的旧版本，但增强版本以兼容的方式提供以前软件的所有功能。 但是，有时，较新版本的软件可能无法提供与旧版本的兼容性，这需要对系统进行其他更改。

主要是进化和并发过程：增量承诺螺旋模型

增量承诺螺旋模型概述

增量承诺螺旋模型 (ICSM) 的视图如图 6 所示。

图 6. 增量承诺螺旋模型 (ICSM)（Pew 和 Mavor 2007）。 经美国国家科学院许可转载，由华盛顿特区国家科学院出版社提供 所有其他权利均由版权所有者保留。

在 ICSM 中，每个螺旋同时而不是顺序地处理需求和解决方案，以及产品和流程、硬件、软件、人为因素方面以及替代产品配置或产品线投资的业务案例分析。 利益相关者考虑风险和风险缓解计划并决定行动方案。 如果风险是可接受的并且被风险缓解计划覆盖，则项目将进入下一个螺旋。

第一次开发承诺审查后的开发螺旋式遵循三团队增量开发方法，以实现图 2“ 系统生命周期过程驱动程序和选择的“进化-并发快速变更处理和高保证”中显示和讨论的敏捷性和保证。

增量承诺螺旋模型的其他视点

图 7 显示了国家研究委员会在系统开发过程 研究中推荐的 ICSM 生命周期过程的更新视图 （Pew 和 Mavor 2007）。 它在研究中被称为增量承诺模型（ICM）。 ICSM 建立在当前流程模型的优势之上，例如Vee 模型中的早期验证和确认概念、并发工程模型中的并发概念、敏捷和精益模型中的轻量级概念、螺旋模型中的风险驱动概念、合理统一过程 (RUP) 中的阶段和锚点 (Kruchten 1999; Boehm 1996)，以及最近扩展螺旋模型以解决系统 (SoS) 能力获取问题 (Boehm 和 Lane 2007)。

图 7. 通用增量承诺螺旋模型过程的阶段视图（Pew 和 Mavor 2007）。 经美国国家科学院许可转载，由华盛顿特区国家科学院出版社提供 所有其他权利均由版权所有者保留。

图 7 中的第一行活动表明，许多系统方面正在同时进行设计，理解、定义和开发水平不断提高。 这些方面中最重要的部分如图 8 所示，它是作为 RUP 的一部分开发的并行工程软件活动的类似 “驼峰图” 视图的扩展（Kruchten 1999）。

图 8. ICSM 活动类别和努力程度（Pew 和 Mavor 2007）。 经美国国家科学院许可转载，由华盛顿特区国家科学院出版社提供 所有其他权利均由版权所有者保留。

与 RUP 版本一样，工作水平的大小和形式将是风险驱动的，并且可能因项目而异。 图 8 表明大量并发活动发生在 ICSM 各个阶段之内和各个阶段之间，所有这些都需要 “同步和稳定”， 这是从 Microsoft Secrets （Cusumano 和 Selby 1996）中提取的最佳实践短语，以保持项目控制下。

独立专家的审查过程和使用基于“架构审查：实践和经验”（Maranzano 等人，2005 年）中描述的非常成功的 AT&T 架构审查委员会程序。 图 9 显示了可行性证据描述的内容。 展示并发开发元素的可行性有助于同步和稳定并发活动。

图 9. 可行性证据描述内容（Pew 和 Mavor 2007）。 经美国国家科学院许可转载，由华盛顿特区国家科学院出版社提供 所有其他权利均由版权所有者保留。

运营承诺审查 (OCR) 的不同之处在于它解决了部署不完善系统的运营风险通常较高。 一般来说，利益相关者在经历工程认证审查 (ECR) 到设计认证审查 (DCR)里程碑的顺序时，承诺水平会增加 2 到 10 倍，但从 DCR 到 OCR 的增加可能很多更高。 这些承诺水平基于采购生命周期各个阶段的典型成本概况。

基本的 ICSM 原则

ICSM 有四个必须遵守的基本原则：

1. 基于利益相关者价值的系统定义和演进；
2. 增量承诺和问责制；
3. 并发系统和软件定义和开发；
4. 证据和基于风险的决策。

迄今为止的模特经验

National Research Council Human-Systems Integration 研究 (2008) 发现 ICSM 流程和原则与最佳业务实践非常吻合，如第 7 部分的下一代医用输液泵案例研究中所述。更多示例可在 Human-System Integration中找到 在系统开发过程：新面貌 （Pew and Mavor 2007，第 5 章）、 软件项目管理 （Royce 1998，附录 D）和年度“质量软件项目五强”系列中，发表于 CrossTalk（2002- 2005）。
建议删除以下信息或将其移至第 6 部分，因为其中一些信息对于新文章敏捷系统工程和精益部分将是多余的，如果对精益工程文章是多余的。 这些举措将推动引用所需的更新/清理。 ---

敏捷和精益流程

根据 INCOSE 系统工程手册 3.2.2， “项目执行方法可以描述为从‘自适应'到‘预测'的连续统一体。 敏捷方法存在于这个连续体的“适应性”方面，这与说敏捷方法是“无计划的”或“无纪律的”不同” （INCOSE 2011, 179）。 敏捷开发方法可用于支持迭代生命周期模型，允许线性过程的灵活性，更好地与系统的计划生命周期保持一致。 与明确的书面知识相比，它们主要强调隐性人际知识的开发和使用，正如 “敏捷宣言” 中的四个价值主张所证明的那样：

我们正在通过开发软件并帮助他人开发软件来发现更好的方法。 通过这项工作，我们开始重视

• 个人和交互 超过流程和工具；
• 工作软件 优于综合文档；
• 合同谈判中的 客户协作； 和
• 响应变化 而不是遵循计划。

也就是说，虽然右边的项目有价值，但我们更重视左边的项目。 （敏捷联盟 2001）

精益流程通常与敏捷方法相关联，尽管它们更具可扩展性并且适用于高保证系统。 下面，介绍一些具体的敏捷方法，并讨论精益方法的演变和内容。 有关特定敏捷和精益流程的更多详细信息，请参阅“主要参考资料”、“其他参考资料”和精益工程 文章。

Scrum

图 10 显示了将 Scrum 作为敏捷流程流的示例。 与大多数其他敏捷方法一样，Scrum 使用表 1（上图）所示的演化顺序过程，并在固定需求和演化开发过程部分中进行了描述，其中系统功能在短时间内开发，通常大约 30 天。 然后，该项目重新确定其积压的所需功能的优先级，并确定团队（通常为 10 人或更少）在接下来的 30 天内可以开发多少功能。

图 10 还显示，一旦要为当前 Scrum 开发的功能已经扩展（通常以非正式故事的形式）并分配给团队成员，团队就会建立一个每天的节奏，从一个简短的会议开始，每个团队在会议上成员提供大约一分钟的摘要，描述自上次 Scrum 会议以来的进展、潜在的障碍以及下一天的计划。

图 10. 敏捷流程示例：Scrum (Boehm and Turner 2004)。 经 Ken Schwaber 许可转载。 所有其他权利均由版权所有者保留。

架构敏捷方法

在过去十年中，一些组织已经能够通过使用两层十人 Scrum 团队来扩展敏捷方法。 这包括，除其他外，让每个 Scrum 团队的日常会议随后召开 Scrum 团队领导者的日常会议，讨论对不断发展的系统架构的前期投资（Boehm 等人，2010）。 图 11 显示了架构敏捷方法的示例。

图 11. 架构敏捷过程示例 (Boehm 2009)。 经 Barry Boehm 代表 USC-CSSE 许可转载。 所有其他权利均由版权所有者保留。

敏捷实践和原则

从 Scrum 和架构敏捷方法中可以看出，“普遍共享”的原则不一定是“统一遵循”的。 但是，大多数敏捷方法都有一些通用实践和原则：

• 项目团队在定义的 SE 过程中理解、尊重、工作和行为；
• 在项目期间以最少的停机时间或人员分流，尽可能快地执行项目，并管理关键路径；
• 所有关键球员都在物理上或电子上并置，并且“笔记本”被认为是所有人都可以使用的团队财产；
• 基线管理和变更控制是通过基于“做出承诺——信守承诺”原则的正式口头协议来实现的。 参与者互相追究责任；
• 通过专家咨询和快速模型验证以及密切的客户协作来实现机会探索和风险降低；
• 软件开发在快速开发环境中完成，硬件开发在多学科模型车间进行； 和
• 建设性对抗的文化遍布项目组织。 团队拥有成功的所有权； 这绝不是“别人的责任”。

敏捷开发原则（适用于 SE）如下（改编自 敏捷宣言背后的原则 （Beedle et al. 2009））：

1. 首先，通过早期和持续交付有价值的软件（和其他系统元素）来满足客户。
2. 欢迎不断变化的需求，即使是在开发的后期； 敏捷流程利用变化来获得客户的竞争优势。
3. 频繁地交付工作软件（和其他系统元素），从几周到几个月不等，优先考虑更短的时间范围。
4. 业务人员和开发人员必须在整个项目中每天一起工作。
5. 围绕有动力的个人建立项目； 为他们提供环境，支持他们的需求，并相信他们能够完成工作。
6. 传达信息最有效和最有效的方法是面对面交谈。
7. 工作软件（和其他系统元素）是进度的主要衡量标准。
8. 敏捷流程促进可持续发展； 赞助商、开发人员和用户应该能够无限期地保持恒定的步伐。
9. 对卓越技术和良好设计的持续关注提高了敏捷性。
10. 简单——最大化未完成工作量的艺术——是必不可少的。
11. 最好的架构、需求和设计来自自组织团队。

一个团队应该反思如何定期提高效率，然后相应地调整和调整其行为。 这种自我反省是实施敏捷流程的项目的一个关键方面。

精益系统工程与开发

起源

随着汽车等消费品的制造变得更加多样化，传统的预先计划的大规模生产方法在质量和适应性方面的问题越来越多。 精益制造系统，如丰田生产系统 (TPS) (Ohno 1988) 更适合适应多样性、提高质量和支持即时制造，这种制造可以快速适应不断变化的需求模式，而无需携带大量，昂贵的库存。

这种转变很大程度上是由 W. Edwards Deming 的工作推动的，他的全面质量管理 (TQM) 方法将质量和生产力的责任从计划人员和检查员转移到更接近实际过程的生产工人身上（Deming 1982）。 戴明的方法涉及制造组织中的每个人，以寻求持续的过程改进，或“改善”。

一些 TQM 技术，如统计过程控制和可重复性，更适合重复性制造过程，而不是系统工程 (SE) 和软件工程 (SwE) 等知识工作。 其他的，例如早期错误消除、浪费消除、工作流程稳定和改善，同样适用于知识工作。 在 Watts Humphrey 的领导下，TQM 成为软件能力成熟度模型（Humphrey 1987；Paulk 等人 1994）和 CMM 集成或 CMMI 的焦点，后者将其范围扩展到包括系统工程（Chrissis 等人 2003）。 一项重大变化是将成熟度级别 2 从“可重复”重新定义为“管理”。

麻省理工学院 (MIT) 对 TPS 进行了研究，产生了一种类似的方法，称为“精益生产系统”(Krafcik 1988; Womack et al. 1990)。 “精益思维”的后续发展和麻省理工学院的相关工作导致了空军赞助的精益航空航天计划（现在称为精益推进计划），该计划将精益思想应用于 SE（Murman 2003，Womack-Jones 2003）。 同时，精益思想被用来加强软件敏捷方法的可扩展性和可靠性方面（Poppendieck 2003；Larman-Vodde 2009）。 面向看板流程的方法已成功应用于软件开发（Anderson 2010）。

原则

这些努力中的每一个都发展了一套相似但不同的精益原则。 对于系统工程，目前最好的来源是系统工程 精益 ，这是 INCOSE 精益 SE 工作组几年工作的产物（Oppenheim 2011）。 它被组织成六项原则，每项原则都被细化为一组精益使能者和子使能者模式以满足该原则：

1. 价值。 通过确定客户和其他关键利益相关者的价值主张来指导项目。 让他们参与并管理其价值主张的变化。
2. 绘制价值流图（计划程序）。 这包括全面的需求规范、价值主张之间贸易空间的同时探索、COTS 评估和技术成熟度评估，从而形成完整的项目计划和一组需求。
3. 流动。 关注项目的关键路径活动以避免代价高昂的停工，包括与外部供应商的协调。
4. 拉。 根据优先级的需求和依赖关系拉下要完成的任务。 如果找不到该任务的需求，则将其视为浪费而拒绝。
5. 完美。 应用持续的过程改进来接近完美。 尽早排除缺陷以在第一次 # 时使系统正确， 而不是在检查和测试期间修复它们。 查找并修复根本原因而不是症状。
6. 尊重人。 将责任、权力和责任下放到所有人员。 营造学习氛围。 将人员视为组织最有价值的资产。 （奥本海姆 2011）

这些精益 SE 原则与四个基本的增量承诺螺旋模型原则非常相似。

• 原则 1：基于利益相关者价值的系统定义和演进 ，解决精益 SE 价值、价值流映射和尊重人的原则（开发人员是 ICSM 中对成功至关重要的利益相关者）。
• 原则 2：增量承诺和问责制 ，部分解决了拉动原则，也解决了对人（对自己的承诺负责）的尊重。
• 原则 3：并行系统和软件定义和开发 ，部分解决价值流映射和流程。
• 原则 4：证据和基于风险的决策 ，使用可实现性的证据作为其成功的衡量标准。 总体而言，ICSM 原则对持续过程改进有些轻描淡写，而精益 SE 原则在倡导完整的预先指定的项目计划和一组需求时对需求出现有些不敏感。

有关详细信息，请参阅精益工程。