开发敏捷系统

在以前的博客中，我们讨论了为什么我的需求在产品或系统开发过程中不断变更，以及控制和管理变更。也可以从产品或系统投入运营后发生的变更的角度来解决变更。从这个角度来看，要解决的问题是：“尽管在操作过程中可能发生环境或任务的变更，但产品或系统是否能够在其操作环境中达到其预期目的（定义系统验证）？

这些变更可能是输入的变更，操作环境的变更，意外的威胁，意外的机会或由于系统故障或性能下降而引起的变更。也可能会导致变更，因为在定义项目范围时所做的假设被证明是无效的。例如，该系统是基于某些关键假设而设计的，但是在系统投入运行后，其中一些假设被证明是错误的。参数输入的范围，输入量或操作环境可能与假定的不同。变更可能是与已知未知数和未知未知数相关的不确定性的结果。

鉴于这些可能的变更和不确定性，我们是否能够完成需要完成的工作？如果系统是用于军事或NASA的一项探索任务，是否仍能实现任务的需求，目标和目的？定义的任务能否成功完成？

为了在不确定性和随之而来的变更成为常态的这种类型的操作环境中取得成功，需要一种不同的，更灵活的产品定义和设计方法。

敏捷系统与敏捷开发

当您看到“敏捷”一词时，最常见的用法是描述软件系统开发的方法或理念，尽管只要有适当的组织先决条件就没有理由不能将敏捷开发应用于任何系统的开发。支持敏捷开发方法。

但是，“敏捷”也可以用来指代系统本身的属性。因此，敏捷系统工程和敏捷系统工程是两回事。本文的重点是“敏捷系统”。

什么是敏捷系统？

将敏捷系统定义为一种能够“在不确定且不可预测的不断开发的环境中蓬勃开发；在任务范围内部署对机会和威胁的有效响应。”“有效反应有四个指标：及时（足够快地交付价值），负担得起的（费用可以根据需要重复多次），可预测的（可以指望满足需求），以及全面（系统任务范围内的所有内容）。”

特别令人关注的是“不确定且变化莫测的环境”。为了使系统敏捷，它需要具有弹性和可组合性，以便能够对新的，不可预测的环境条件做出反应和主动响应。抵御能力提供“至少部分和长期地修复，替换，修补或以其他方式重建由于不幸，损坏或环境不稳定引起的损失的功能或性能（以及有效性）的能力。”可组合可允许对系统进行“重塑”，并根据需要重新配置系统资源，以有效响应由于新威胁或机会而引起的变更。在电影《火星人》中，这两个概念都得到了清晰的展示。

反应性反应是对环境威胁性变化的强制性系统应对，旨在维持或恢复竞争性功能表现。一个积极的回应是在环境的改变启用，目的是提高竞争力的功能特性的非强制性全身开始。

应对变更

在其他有关变更的文章中，我指出解决变更的一种方法是“为变更而设计”。他在Rick的论文中指出：“敏捷系统是为变更而设计的。它们可以通过新的功能进行扩充。可以使用子系统之间的不同内部关系来重组它们。它们可以按比例放大或缩小，以经济地提供功能。可以对它们进行重塑，以恢复与形状已改变的环境的兼容性或协同作用。这些类型的变更本质上是结构性的，需要一种适应结构性变更的架构。”

变更设计可以通过以下几种方法来完成：设计系统以便可以变更它，调整大小以提供比当前所需更多的功能，根据风险评估包括足够的利润，而不是将其“硬编码”为常量，而是使其成为可以变更的变量，并且使用模块化方法进行系统架构。

模块化是敏捷系统的关键概念。当使用模块化方法时，系统基础结构需要允许模块互连，并允许根据需要重新配置或扩展基础结构，以“有效地响应”“不可预测的变化环境”。在参考文件中，列出了设计团队在设计具有模块化功能的敏捷系统时需要考虑的十种常见设计原则，这些原则分为三类。

敏捷系统的需求

使用通用系统工程最佳实践来完成对敏捷系统的需求开发。

首先，需要进行全面的问题分析，以便清楚了解敏捷系统的目的/任务是什么。根据问题分析，可以生成需求陈述以及系统的目标和目的。例如，“需求”语句可能是：“一种负担得起的，安全且敏捷的系统架构，允许人类探索火星。”然后，可以在目标中记录对可负担，安全和敏捷的系统的期望。任务的利益相关方将参与问题陈述的定义以及目标的制定。确定定义架构时需要考虑的驱动因素和约束。

接下来，需要为每个生命周期阶段制定各种概念，从中至少可以定义一个可行的（成本，进度，技术）概念。通过这些努力，可以定义范围，并记录和基线利益相关方的期望。

为了定义对敏捷系统的期望，参与项目的利益相关方了解任务是什么，操作环境是什么，风险是什么以及接受对这一知识的不确定性的接受很重要。

系统概念需要解决每个生命周期阶段的不确定性。一个好的方法是基于用例的定义。用例说明“参与者”，初始条件，要执行的功能，完成功能的标称方案，完成功能的替代标称方案，每个标称和替代标称方案的偏离标称的方案，以及最终条件或状态。

使许多传统系统与敏捷系统区分开的一件事是，在定义备用标称和标称之外的方案上花费了很多精力。（由于预算或进度表的考虑，通常将系统定义为一组非常狭窄的假定操作环境，而对不确定性，替代标称情景和偏离标称的情景的关注不足。）

在开发敏捷系统时，重要的是要认识到不确定性和风险，并确认需要这样一种系统，该系统的架构应能够“处理在不确定和不可预测的不断变化的环境中运行所带来的不确定性和风险，并能够有效地做出响应在定义的任务参数范围内应对机会和威胁。”

利益相关方的期望将由此而开发。这些期望将作为范围定义的一部分作为基线。

在基线范围内，将按照正常系统工程流程以自上而下的方式得出需求。请注意，需求开发是一项工程活动，并且是逐层开发的。在架构 层的需求将集中在所需的功能，功能，性能和质量上。重点在于什么，而不是如何。这些需求将反映在基线范围内定义的敏捷系统的标称，替代标称和标称之外的期望。

 

根据敏捷设计指南，开发人员将定义满足这些期望的架构。然后，需求将向下（分配）到已定义架构的下一层，构成架构要素的组织将按照相同的过程来定义和开发其包括“敏捷性”在内的要素。他们系统利益的属性。

风险管理

对我而言，在系统工程中采用敏捷系统方法的主要价值是风险管理。即使在不确定和不可预测的环境中，使任务成功，也需要能够应对威胁并在机遇暴露时寻求机会。

敏捷系统的开发成本会更高吗？也许。但是，任务失败或失败的代价是什么？开发敏捷系统可以使成功的任务与失败的任务区分开来。对于上面关于人类对火星的探索的需求说明示例，敏捷系统可能是失去的机组人员和/或任务或完成任务并能够安全返回地球的机组人员之间的区别。再次，这在电影《火星人》中非常清楚地说明了。