生命周期模型是系统工程(SE)的关键概念之一。系统的生命周期通常由一系列阶段组成，这些阶段由一组管理决策控制，这些决策确认系统已经足够成熟，可以离开一个阶段进入另一个阶段。

主题

SEBoK的每个部分都被划分为知识领域(KAs)，即具有相关主题的信息分组。KAs又被划分为不同的主题。该KA包含以下主题:

• 系统生命周期过程驱动和选择
• 生命周期过程和企业需求
• 系统生命周期过程模型：Vee
• 系统生命周期过程模型：迭代
• 系统生命周期过程模型：敏捷系统工程
• 过程和产品模型的集成

有关第7部分中包含的案例研究和概要到第3部分中涉及的主题的映射，请参阅实现示例矩阵。

增值产品/服务类型

通用生命周期模型仅展示了通过系统生命周期各个阶段的单步方法。增加价值(作为产品、服务或两者兼而有之)是所有企业的共同目标，无论是公共企业还是私营企业，无论是盈利企业还是非盈利企业。价值是通过根据系统描述提供并将系统的元素集成到产品或服务中，并将其转化为生产性使用而产生的。这些价值考虑将导致图1中各种形式的通用生命周期管理方法。一些例子如下(Lawson 2010):

• 制造企业生产螺母、螺栓、锁紧垫圈等产品，作为增值要素销售给其他企业使用;反过来，这些企业将这些产品集成到他们更全面的增值系统中，如飞机或汽车。他们的要求通常由客户或行业标准预先规定。
• 批发或零售企业向顾客提供产品。其客户(个人或企业)获取产品并将其作为系统中的元素使用。随着新的基础设施功能或需求模式的出现，企业支持系统可能会机会主义地发展。
• 商业服务企业，如银行，向客户销售各种产品作为服务。这包括经常账户、储蓄账户、贷款和投资管理。这些服务增加了价值，并被纳入个人或企业的客户系统。随着新的基础设施功能或需求模式的出现，服务企业的支持系统也可能会机会主义地发展。
• 政府服务企业向公民提供的服务千差万别，但可能包括医疗保健、公路、养老金、执法或国防等服务。在适当的情况下，这些服务成为个人和/或企业感兴趣的更大的包含系统中使用的基础设施元素。诸如下一代空中交通控制系统或大都市地区危机管理系统(飓风、台风、地震、海啸、洪水、火灾)等重大举措将足够复杂，从而遵循一种进化的开发和部署方法。在基本级别上，可能存在预先指定的单次循环生命周期。
• 对于飞机和汽车系统，可能会有一个预先指定的多通道生命周期，以便在第一次通道中利用早期功能，但在架构上可以在以后的通道中添加进一步的增值功能。
• 多元化软件开发企业提供满足涉众需求(需求)的软件产品，从而为产品用户提供服务。将需要开发它，使其具有可裁剪的能力，以便在不同客户的生命周期方法中加以利用，还需要具有可快速和容易地应用于类似客户系统开发的产品线能力。它的业务模型可能还包括向客户提供系统生命周期支持和演化能力。

在这些例子中，有些系统在相当长的一段时间内保持稳定，有些则变化迅速。这些例子和它们的过程所代表的多样性说明了为什么没有一个放之四海而皆放的过程可以用来定义特定的系统生命周期。管理和领导方法必须考虑所涉及的系统类型，它们的寿命，以及快速适应不可预见的变化的需要，无论是在竞争、技术、领导或任务优先级。反过来，管理和领导方法影响部署的生命周期模型的类型和数量，以及将在任何特定生命周期中使用的流程。

有几种渐进式和进式方法可以对生命周期阶段进行排序，以处理上面提出的一些问题。生命周期模型知识领域总结了许多增量的和进化的生命周期模型，包括它们的主要优点和缺点，并讨论了选择最佳方法的标准。

生命周期模型的分类

图 1 中的通用系统生命周期模型并未明确适用于所有情况。 一个简单的、先例的、后续的系统在定义阶段可能只需要一个阶段，而一个复杂的系统可能需要两个以上的阶段。 使用构建系统（相对于一次性）原型，在定义阶段可能会进行大量开发。 系统集成 、 验证 和确认可以在系统元素的实施或获取之后进行。 对于软件，尤其是测试优先和日常构建，集成、验证和确认与元素实现交织在一起。 此外，随着即将到来的 第三次工业革命 3D 打印和数字制造（Whadcock 2012），不仅可以在概念阶段完成初始开发，还可以进行初始生产。

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

软件可以在数字通信范围内的世界任何地方以电子方式购买、销售、交付和升级，这使得其物流与硬件明显不同且更具成本效益。 它不会磨损，它的修复会改变它的内容和行为，使得回归测试比硬件修复更复杂。 它的离散性质决定了它的测试不能像硬件一样依赖分析连续性。 在 15 位寄存器中将 1 添加到 32767 不会产生 32768，而是会产生 0，就像在使用爱国者导弹等严重情况下所经历的那样。

有大量潜在的 生命周期过程 模型。 它们分为三大类：

1. 主要是预先指定的和顺序的过程（例如单步瀑布模型）
2. 主要是进化和并发过程（例如精益开发、敏捷统一过程以及各种形式的 vee 和螺旋模型）
3. 主要是人际关系和紧急过程（例如敏捷开发、Scrum、极限编程 (XP)、动态系统开发方法和基于创新的过程）

集成的交互式硬件-软件系统的出现使预先指定的过程具有潜在的危害性，因为最有效的人机系统界面往往会随着它的使用而出现，从而导致进一步的过程变化，例如软 SE (Warfield 1976, Checkland 1981)和人机系统集成过程（Booher 2003，Pew 和 Mavor 2007）。 直到最近，流程标准和成熟度模型一直试图涵盖所有可能发生的情况。 它们包括采购管理、来源选择、审查和审计、质量保证、配置管理和文档管理的广泛流程，在许多情况下会变得过于官僚和低效。 这导致了更精益（Ohno 1988; Womack et al. 1990; Oppenheim 2011）和敏捷（Beck 1999;

在下一篇关于 系统生命周期过程驱动因素和选择的文章中，将识别和介绍生命周期模型主题的这些变体。

系统工程职责

无论部署何种生命周期模型，系统工程师的角色都涵盖了相关系统的整个生命周期。 系统工程师协调解决方案的开发和演变，从定义需求到操作，最终直到系统退役。 他们确保适当地参与领域专家，寻求所有有利机会，并识别所有重大风险，并在可能的情况下减轻风险。 系统工程师与项目经理密切合作，定制通用生命周期，包括关键 决策门 ，以满足其特定项目的需求。

系统工程任务通常集中在生命周期的开始； 然而，商业和政府组织都认识到在整个系统生命周期中对 SE 的需求。 通常，这种持续的努力是在系统、产品或服务进入生产或投入运行后对其进行修改或更改。 因此，SE 是所有生命周期阶段的重要组成部分。 例如，在生产、支持和利用 (PSU) 阶段，SE 执行性能分析、接口监控、故障分析、物流分析、跟踪和分析提议的变更。 所有这些活动对于系统的持续支持都是必不可少的。 在基于模型的系统工程 (MBSE) 工具中维护需求和设计可以在整个 SOI 生命周期中进行配置管理和分析。

所有项目经理都必须确保项目周期的业务方面（成本、进度和价值）和技术方面保持同步。 通常，技术方面会推动项目。 系统工程师有责任确保所考虑的技术解决方案与成本和进度目标一致。 这可能需要与用户和客户一起修改目标以适应业务范围。 这些问题也推动了决策门在整个项目周期中适当间隔的需求。 尽管这些决策门的性质会因上述主要类别而异，但每个都将涉及 开发人员和最终用户之间的进程内验证。过程中验证提出以下问题： “我们正在计划或创造的东西会满足利益相关者的需求吗？” 过程中验证从项目初始化开始，在用户需求发现期间开始，并持续到日常活动、正式的决策门审查、最终产品或解决方案交付、运营，最终到系统收尾和处置。

系统生命周期过程驱动和选择

正如在通用生命周期模型文章中所讨论的，有许多组织因素会影响哪些生命周期流程适合于特定的系统。此外，技术因素也会影响适合于给定系统的生命周期模型的类型。例如，系统需求可以是预先确定的，也可以是变化的，这取决于系统开发的范围和性质。这些考虑导致了不同的生命周期模型选择。本文讨论了在选择生命周期过程模型时可以考虑的不同技术因素，并从文献中提供了示例、指南和工具来支持生命周期模型的选择。所选择的生命周期模型可以影响系统设计和开发的所有其他方面。(请参阅第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）。 经美国国家科学院许可转载，由华盛顿特区国家科学院出版社提供 所有其他权利均由版权所有者保留。

生命周期过程和企业需求

通用生命周期模型描述了从实现结果的需求到实现新的或修改的工程系统的建议的简单转换。这就形成了在该利益体系（SoI）的生命周期中投入时间、金钱和其他资源的决策基础。这一转变中涉及的SE活动有很大一部分涉及不同级别和类型的需求。

需求和生命周期

在生命周期的概念定义阶段，当企业确定需要的新功能时，业务或任务分析开发反映问题空间观点的高级策略和需求集(可以表示为任务或业务需求)。随着解决方案空间的探索和解决方案类的特征化，开发涉众需求并将其转换为涉众需求(从用户的角度)。在确定了解决方案类并寻求了特定的解决方案之后，在生命周期的系统定义阶段，涉众需求被转换为系统需求(从解决方案的角度)。由于系统定义递归地定义了解决方案的较低级别的细节，需求是用较低的抽象级别定义的。在最高级别上，理想的需求是与实现无关的，因此不是特定于一个解决方案，允许一系列可能的解决方案。在最低的层次上，需求陈述可能变得更加特定于所选的解决方案。

概念定义进一步描述了业务或企业以及涉众的需求和要求。它讨论了如何将业务或企业的新功能定义为理解问题空间的一部分。它还讨论了涉众需求的开发，以及从用户的角度将其转换为需求。

系统定义有对需求及其类型的进一步描述(例如，系统需求、涉众需求、派生需求)。它讨论了不同的过程角色/状态、层次和需求的性质如何应用于对需求的理解。

将企业需求转变为需求

需要和需求可以存在于多个层次上，用于描述这些层次的术语将因应用程序域和服务于它们的企业而不同。这使得将一般的SE生命周期流程与它们关联起来变得困难。Ryan(2013)提出了一个通用模型(见图1)，在该模型中，某种类型的企业形成了将战略意图转化为系统定义的焦点。在企业观中，企业领导制定企业战略、概念和计划;一种业务管理视图，在这种视图中，业务管理派生业务需求和约束，并形式化它们的需求;业务操作视图，涉众在其中定义他们的需求和需求。在系统视图中，定义了一个工程系统，如果需要，扩展到系统元素的较低级别的视图。注意，一个工程系统可能包含许多元素，包括产品、人员和过程。可以创建系统体系结构，以定义这些元素如何一起为组织启用所需功能的逻辑和物理视图。

图 1. 将需求转化为需求 (Ryan, 2013) 由 M. Ryan 授予许可。 所有其他权利均由版权所有者保留。

在下面的讨论中，Ryan 进一步定义了一组通用术语来定义需要和要求的级别，并将它们与通用组织角色相关联。 有关此一般描述如何映射到不同应用程序上下文或组织结构的讨论，请分别参见 第 4 部分和 第 5 部分 。

图 1 中的各种视图称为层。 在最高层，企业有许多指导其未来的战略。 例如，在上面的插图中，系统起源于运营概念(ConOps) 或战略业务计划 (SBP)，它传达了领导层关于现有系统和待定系统的组织运营的意图。发达。 在这一层，ConOps 或 SBP 用“品牌”来定义企业，并建立使命宣言和相应的目标和目标，清楚地说明企业前进的原因和战略。

业务或任务分析流程以组织的任务或愿景声明、由 ConOps 或 SBP 传达的目标和目的开始。 业务管理使用此指南来定义业务需求，主要以生命周期概念的形式，捕获业务管理的采购、开发、营销、运营、部署、支持和退役的概念。 然后使用这些概念来定义该层的特定需求。

生命周期概念中包含的业务需求被详细阐述并形式化为业务需求，这些需求记录在业务需求规范 (BRS) 或业务需求文档 (BRD) 中。 将业务需求转化为业务需求的过程称为任务分析或业务分析。

一旦业务管理层满足了他们的需求和要求，他们就会将它们传递给业务运营层。 在这里，利益相关者需求和要求 (SNR) 定义流程使用 ConOps 或 SBP 以及生命周期概念中包含的概念作为指导。 需求工程师 (RE) 或业务分析师 (BA) 通过结构化流程从业务运营层引导利益相关者，以获取利益相关者的需求——以精炼的 OpsCon 或类似文档和其他生命周期概念的形式（参见图 1）。 RE 或 BA 使用结构化流程来引出特定需求，如用户故事、用例、场景、系统概念或操作概念中记录的那样。 如需进一步讨论作战概念和作战概念文件及其相互作用，

然后将利益相关者的需求转化为一组正式的利益相关者要求，这些要求记录在利益相关者要求规范 (StRS) 或利益相关者要求文档 (StRD) 中。 这种转变是由一个定义明确、可重复、严格且记录在案的需求分析过程指导的。 这种需求分析可能涉及使用功能流程图、时间线分析、N2 图、设计参考任务、建模和模拟、电影、图片、状态和模式分析、故障树分析、故障模式和影响分析以及贸易研究。 在某些情况下，这些需求分析方法可以使用作为高级逻辑架构的一部分创建的视图。

在系统层，在系统需求定义过程中，StRS 中的需求然后由 RE 或 BA 转换为 系统需求，并记录在系统需求规范 (SyRS) 或系统需求文档 (SyRD) 中。 与前面的过程一样，RE 或 BA 使用与上述相同的需求分析方法来定义需求，完成需求到需求的转换。 在每一层，产生的需求都将被记录、同意、基线化，并置于配置管理之下。 如上所述，系统需求分析也可以链接到适当的逻辑和物理架构，非正式地或在共享配置控制下。 请注意，一些组织可能会为为满足业务需求而开发的多个系统中的每一个系统准备单独的生命周期概念。

一旦一组需求在一个层被记录、同意和基线化，它们将向下传递到下一层，如图 1 所示。在下一层，需求是需求转换过程的结果在该层以及从前一层的需求分解或派生的结果。 因此，许多 SyRS 或 SyRD 要求可以从 StRS 或 StRD 分解（即，由其要求明确）或衍生（即，由其要求隐含）。 在子系统或系统元素层也是如此，其中许多子系统或系统元素需求可以分解或从 SyRS 或 SyRD 派生。 在所有情况下，对于图 1 所示的每一层， 这组需求可以追溯到分解或派生它们的前一层的需求。 这个过程继续到下一层系统元素。

需求的表达方式因这些层而异，因此表达它们的规则也不同。 随着需求的开发——以及解决方案的设计——通过抽象层，我们期望需求陈述变得越来越具体。 在最高级别上，理想的要求并不特定于特定的解决方案，而是允许一系列可能的解决方案。 在最低级别，需求陈述将完全针对所选解决方案。 需要注意的是，某一层的需求形式可能不适用于另一层。 例如，在业务管理层，可能要求所有产品都是“安全的”。 虽然这是一个糟糕的系统要求，但它适用于业务管理层。 在下一层，业务运营， 定义“安全”的要求会更少，更详细。 这些要求适用于所有产品线。 在系统层，将为该特定系统制定更具体的安全要求。 然后，这些要求将分配给下一个较低层的系统元素。

系统生命周期过程模型：Vee

正如在系统生命周期过程驱动和选择文章中所讨论的，这些模型分为三个主要类别:(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. 许可转载。版权所有者保留所有其他权利。

系统生命周期过程模型：迭代

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

(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 原则在倡导完整的预先指定的项目计划和一组需求时对需求出现有些不敏感。

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

系统生命周期过程模型：敏捷系统工程

对于一个系统，生命周期通常从概念定义阶段开始，按照概念定义阶段的定义，经历多个阶段直到系统完成。生命周期的模型可以是该生命周期的物理、数据或图形表示。该流程描述了完成生命周期每个阶段的步骤，包括该阶段的输入和输出。在技术变革、环境变化和快速发展的任务需求的压力下，当今复杂且高度互联的系统面临着快速淘汰。为了让这些系统保持强大的抗破坏能力，它们必须被设计成能够灵活地适应。为了满足这些需求，必须对系统进行评估，以应用最适合系统、子系统或相关利益系统(SOI)组件的流程。

在概念定义阶段早期确定SOI的最佳生命周期非常重要。在一个将要灵活运行的项目上，尤其是如果它是一个具有敏捷和其他生命周期模型的混合模型，那么在基于硬件或其他长周期项目成熟度的关键集成点定义和协调它们是很重要的。南非射电天文观测站（SARAO）的各个重要组成部分在使用的多个生命周期中确定了关键集成点，这是一个信息丰富的案例研究，提供了一个方法裁剪过程的绝佳例子(Kusel 2020)。

在敏捷SE过程中，系统工程师以一种迭代的、增量的方式工作，持续地建模、分析、开发和交易选项，以使系统解决方案的定义成为焦点。这项工作的一个例子将不仅分析和维护需求，而且还要分析和维护高层次需求的体系结构模型，以及从这些高层次需求到被分析的低层次需求的链接。除了需求和体系结构表示之外，随着开发的进展，维护和验证接口是系统工程师的一些任务。不管生命周期如何，系统工程师的这些职责是相同的，尽管顺序和组织可能不同。项目领导、系统工程和所有团队成员都在一种代表敏捷思维的文化中工作。敏捷思维是来自敏捷价值观的信念和行动的组合，包括经常关注交付工作能力，相信有能力的工作者会找到最好的解决方案，通过定期的演示和回顾来改进产品和过程，经常计划实施学到的经验教训。。

敏捷开发原则

敏捷开发原则(Marbach 2015)为跨职能团队的工作关系提供了基础，其中包括系统工程师和软件工程师，他们从事包括硬件开发和软件开发的客户项目。表1中的这些原则是源自于《敏捷宣言》(Beck 2001)的改进版本，并扩展到应用于系统工程。采用这些原则将使团队中的团队逐渐地产生高价值的能力。

敏捷开发原则强调关注工作能力，并保持正在进行的工作规模较小。表1将敏捷开发原则映射到SEBoK中其他地方阐述的传统SE原则。敏捷开发原则是传统SE原则的补充，在某些情况下非常相似。点击这里查看完整的SEBoK系统工程原理。

面向混合学科工程的敏捷系统工程生命周期模型(Dove 2019)描述了促进行动中的操作敏捷性的原则:感知、响应和进化(SRE)。贯穿整个生命周期的大型程序将受益于应用这些原则。此外，scale Agile Framework®(SAFe®)描述了在包括系统工程在内的团队中促进大型项目开发敏捷性的原则。操作敏捷原则和安全精益敏捷原则映射在表2中，以显示它们之间的一致性。从敏捷思维开始并应用一组原则是有价值的。

表 2. 跨学科团队原则的比较（或映射）。 SAFe精益敏捷原则 是 规模化敏捷, 等. 的版权材料。

使用与敏捷价值观一致的敏捷思维，敏捷开发原则和安全精益敏捷原则可以应用于敏捷SE生命周期的各个阶段。

通用生命周期模型显示了定义阶段、实现阶段和退化阶段。每一阶段都有进一步的阶段。每个SOI都有一个对应的生命周期模型，该模型由使用流程填充的阶段组成。根据定义阶段执行的SOI评估，每个阶段中的过程可能是Vee、迭代或敏捷。在文献中提出了几种过程模型，它们可以被称为敏捷系统工程过程、模型或框架。

根据ISO/IES/IEEE 24748-1《系统与软件工程-生命周期管理-第1部分:生命周期管理指南》(ISO/IES/IEEE 2018)，“常见的”有六个系统生命周期阶段。Dove描述了“异步和并行的生命周期阶段和过程活动”，增加了第7个生命周期阶段，即态势感知(Dove2019)。图1是作为在系统开发中有效使用敏捷实践的组织的四个案例研究的一部分开发的。使用这种敏捷系统工程生命周期模型(ASELCM)的路径可以从“概念”阶段开始，进入“情境感知”阶段，然后进入开发阶段，再回到“情境感知”阶段，如此循环往复。在将注意力转移到下一个适当的阶段(如回到概念或开发)之前，这个情境感知阶段允许进行演示、审查和持续改进。

图 1.敏捷系统工程生命周期模型 (ASELCM)。 （Dove and Schindel 2019，经许可使用）

图 1 中表示的生命周期模型可以使用图 2 中所示的 S*Pattern 类层次结构直观地描述。在这个层次结构中，顶层显示了实体关系范式，“为工程目的对任何系统进行建模所需的最小概念内容或科学。” （Schindel，2016 年）。 当我们转向更具体的模型表示时，ASELCM模式从父模式继承内容。

图 2. S* Pattern 类层次结构（Schindel 和 Dove 2016，经许可使用）

图2中间所示的“一般ASELCM模式”在图3中被放大。在开发一个相关利益的系统(SOI)时，我们不仅必须考虑我们可以认为是目标系统的SOI，如图3中的系统1，还必须考虑产生目标系统的过程，如图3中的系统2。除了制度1和制度2之外，还有第三个制度，即创新制度。这个系统3是影响目标系统的设计、开发和操作的元视图，系统1和系统2的嵌入式行为框架。在对目标系统建模时，应考虑其他影响系统2和3。

图 3. 敏捷系统工程生命周期模型 (ASELCM) 模式（Schindel 和 Dove 2016，经许可使用）

这些 SEBoK 文章中描述了 其他系统工程模型，传统（或瀑布）、Vee 、 增量和迭代。

结构

在每个阶段执行的敏捷系统工程过程步骤通常包括：

1. 首先定义最高优先级和/或最高风险的项目，保持设计选项的开放，直到最后负责任的时刻。这将产生一个工作项列表，其中最高的工作项位于最上面。这个工作项的优先级列表被称为程序backlog。
2. 在开发迭代过程中，工程师分析需求，设计解决方案以满足这些需求，开发他们的产品，执行该产品的测试，并演示该产品。对于系统工程产品，这些记录最好保存在工具中，例如需求管理工具、基于模型的系统工程工具，以及配置控制的存储库，等等。开发迭代是一段很短的时间，通常持续时间从两周到四周。

3. 对于开发中的大型产品，多个团队将他们的工作项集成在一起，以显示一个可演示的产品，可能需要几个迭代来达到这一点。这个多次迭代周期通常被称为增量，通常需要大约三个月的时间。

4. 在开始一个增量之前，所有致力于生产可演示产品的团队，都应该计划他们的工作，识别团队之间的依赖关系，并建立满足计划的承诺。根据程序使用的框架的不同，这种规划被称为不同的东西。有人叫它大房间计划，有人叫它程序增量计划。

5. 在一系列迭代的最后，可演示的产品可能会被“发布”给涉众。然后项目的所有成员开会计划下一个工作增量。

图 4 显示了团队按照这种描述的节奏工作的可视化表示（Rosser 等人，2014 年）。

图 4. 敏捷 SE 框架（Rosser 等人，2014 年，经许可使用）

这个敏捷系统工程(SE)框架(Rosser 2014)与大规模敏捷框架(SAFe)使用迭代开发对团队工作程序和团队积压的描述保持一致。SAFe是一个实现迭代开发原则的框架。它表示一个大型系统如何在一段时间内并行地遵循多个生命周期过程。需要在多个生命周期流程之间调整关键决策点。有许多敏捷方法，程序可以按原样使用或组合使用，以适应特定领域的最佳工作方式。敏捷联盟(2017,100)阐述了许多“基于指导深度和生命周期广度的敏捷方法”。

对于需求不断变化的复杂系统，评估可能导致决定使用增量的、迭代的开发方法。无论选择哪种模型或框架，项目都是从远景、预算和一段时间的性能开始的。然后，规划的利益相关者首先确定需要开发的最高价值的能力。能力列表按优先级排序，以便看到长期发展。然而，这个优先顺序可能会随着工作的进行而改变。关于预期产品的已知信息可能有很好定义的需求和架构表示，而概念性的信息将随着时间的推移逐步开发这些需求和设计。这种增量式开发方法是通过使用开放系统体系结构、基于模型的系统工程(MBSE)工具、基于集合的设计、设计思维、持续集成、持续开发、体系结构模式、微服务体系结构和精益工程实现的。

过程和产品模型的集成

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

过程和产品模型

生命周期模型 图 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. 许可转载。版权所有者保留所有其他权利。

精益系统工程 (LSE)

精益系统工程 (LSE)是将精益思维 (Womack 2003) 应用于系统工程 (SE) 以及企业和项目管理的相关方面。 LSE 是一种适用于整个系统生命周期的方法。 LSE 的目标是以最少的浪费为技术复杂的系统提供最佳的生命周期价值。 精益工程与所有传统的 SE 技术流程相关（参见概念定义、 系统定义、系统实现 、系统部署和使用 等）。 精益工程还与第 6 部分中讨论的许多专业工程学科相互作用并加以利用 。

精益系统工程

SE 是一种成熟的、健全的实践，但并不总是有效地交付。 大多数程序都背负着某种形式的浪费，例如：协调不力、需求不稳定、质量问题、延误、返工或管理挫折。 最近美国政府问责办公室 (GAO)、美国国家航空航天协会 (NASA) 和麻省理工学院 (MIT) 对政府项目的研究记录了重大预算和进度超支以及政府项目中的大量浪费 - 有些达到 70%的收费时间。 这种浪费代表了计划中的生产力储备和提高计划效率的主要机会。

LSE 是将精益思想应用于系统工程以及企业和项目管理的相关方面。 SE 专注于能够开发复杂技术系统的学科。 精益思维是一种整体范式，专注于为客户提供最大价值并最大限度地减少浪费的做法。 它已成功应用于制造、机库、行政、供应链管理、医疗保健和产品开发，其中包括工程。 LSE 是精益思维和 SE 之间的协同领域，旨在以最少的浪费为技术复杂的系统提供最佳的生命周期价值。 LSE 并不意味着更少的 SE。 这意味着更多更好的 SE，具有更高的责任、权限和责任 (RAA)，从而带来更好、无浪费的工作流程，并增加任务保证。 根据伦敦政治经济学院的理念，任务保证是不可协商的，任何为成功而合法需要的任务都必须包括在内； 但是，它应该经过精心策划和执行，并尽量减少浪费。

精益原则

Oppenheim (2011) 将产品开发 (PD) 的六项精益原则描述如下：

1. 捕捉 客户定义的 价值。 在资源支出增加以避免不必要的返工之前，不能过分强调以精确、清晰和完整的方式捕获任务或程序价值（需求、CONOPS 等）的重要性。
2. 绘制价值流图（计划程序） 并消除浪费。 映射所有端到端链接任务、控制/决策节点以及实现客户价值所需的互连信息流。 在映射过程中，消除所有非增值活动，并使剩余的活动能够流动（无需返工、回流或停止）。 术语 信息流 是指由不同任务创建并流向其他任务以进行后续增值的信息（知识）包，例如：设计、分析、测试、审查、决策或集成。 如果每项任务在交付客户价值的背景下提高有用信息的水平并降低风险，它就会增加价值。
3. 通过计划和简化的增值步骤和流程使工作流转，无需停止或空闲时间、计划外返工或回流 。 为了优化流程，应该计划任务的最大并发性，直到接近企业的容量。 PD 中经常需要合法的工程迭代，但如果它们跨学科扩展，它们往往既耗时又昂贵。 精益 PD 鼓励 早期失败的有效方法 - 经常失败 通过早期设计阶段的快速架构和发现技术。 精益流程还尽一切努力使用防止冗长迭代的技术，例如设计前端加载、交易空间探索、集合设计、模块化设计、遗留知识和大利润。 在确实需要详细的跨职能迭代的情况下，精益流程优化迭代循环以获得整体价值。
4. 让客户 拉动 价值。 在 PD 中，拉动原则有两个重要含义：（1）在程序中包含任何任务必须由内部或外部客户的特定需求证明并与他们协调，以及（2）任务应该在何时完成客户需要输出。 过早完成会导致“保质期过时”，包括可能丧失人类记忆或改变需求，而过晚完成会导致进度延误。 这就是每个任务负责人或工程师都需要与内部客户保持密切沟通以充分了解他们的需求和期望并协调他们的工作的原因。
5. 追求所有流程的 完美 。 全球竞争需要不断改进流程和产品。 然而，任何组织都无法负担得起一直花费资源来改进一切。 系统工程师必须区分流程和流程输出。 完善和细化给定任务中的 工作输出 必须以定义何时输出“足够好”的整体价值主张（系统或任务成功、项目预算和进度表）为界。 相反， 出于竞争原因，必须不断改进工程和其他 流程。
6. 尊重 人。 精益企业是一个认识到员工是最重要资源的组织。 在精益企业中，人们不惧怕实时坦诚公开地发现问题和缺陷，不惧怕地就根本原因和纠正措施进行头脑风暴，或以共识方式共同计划有效的解决方案，以防止问题再次发生。

系统的精益推动者

2009 年，国际系统工程委员会 (INCOSE) 的精益 SE 工作组 (LSE WG) 发布了一个名为“ 系统工程精益推动者 (LEfSE) ”的在线产品。 它是一套基于精益思想的实践和建议的集合，被制定为 SE 的“注意事项”和“注意事项”。 这些实践涵盖了广泛的 SE 和其他相关企业管理实践，一般侧重于提高项目价值和利益相关者满意度，并减少浪费、延误、成本超支和挫折。 LEfSE 归类于上述六项精益原则。 LEfSE 无意成为强制性实践，但应用作良好实践的清单。 LEfSE 不会取代传统的 SE； 相反，他们用精益思想对其进行了修改。

LEfSE 是由 14 名经验丰富的 INCOSE 从业者、来自工业界、学术界和政府（如美国、英国和以色列）的一些公认的精益和 SE 领导者与 160 名成员的国际 LSE WG 合作开发的。 他们收集了许多公司的最佳实践，增加了 LSE WG 成员的集体隐性知识、智慧和经验，并插入了精益研究和文献中的最佳实践。 该产品已通过调查和与 GAO 和 NASA 最近的计划建议进行比较来评估。

Oppenheim (2011) 包括对促成因素的全面解释，以及 LSE 的历史、LEfSE 的发展过程、工业示例和其他材料。 Oppenheim、Murman 和 Secor (2011) 提供了一篇关于 LEfSE 的学术文章。 奥本海姆在 2009 年也发表了一份简短的总结。