| 编辑推荐: |
文章描述了一种系统动力学仿真模型，该模型允许决策者在调整关键模型参数的同时比较软件开发实践。
本文来自于insights.sei.cmu，由火龙果软件Luca编辑、推荐。 |
|
敏捷开发实践在政府中的应用提供了决策者可以用来改进政策、程序和实践的经验。(如基于Agent的建模、计算博弈论和系统动力学)为构建敏捷软件开发的有效、一致和可执行的特性提供了一种方法。这些技术可以帮助回答有关敏捷概念和敏捷应用的关键问题。BModSim补充了数据分析方法，例如机器学习，通过描述组织在敏捷应用中的大局面，将来自数据分析的各种结果放在上下文中，并确定最有利可图的领域以用于将来的数据收集。这篇博客文章描述了一种系统动力学仿真模型，该模型允许决策者在调整关键模型参数的同时比较软件开发实践，例如系统需求基线的大小、发展增量的数量以及人员配置水平。
为什么BModSim很重要？
采用敏捷实践并使之适应于应用程序的政府项目面临着若干挑战。随着敏捷开发方法的变体已经激增，程序需要指导和基于证据的标准来决定选择哪种变体。政府系统通常比以往应用敏捷实践的系统大。因此，程序受到挑战，以重构政府应用系统，用于增量和迭代开发，并将人员的分配扩展到敏捷项目中典型的小型团队之外。此外，尝试新想法的实验很难在政府环境中进行。
使用BModSim进行的分析可以帮助减轻政府计划的这些挑战。BModSim可以帮助揭示使敏捷在政府计划中有用的基础机制的运作。在进行实验之前（或没有进行实验），BModSim可以通过分析不同方法的潜在成本，进度和质量影响，帮助决策者准确了解不同的敏捷方法如何以及何时创造价值。最后，BModSim可以通过仿真来帮助测试软件开发策略和过程的有效性，从而进行改进，从而增加在实施之前成功的可能性。
这篇博文中描述的模型可以用来为探索、改进和验证敏捷的政府应用程序提供一个严格的基础。经过进一步完善，该模型有可能成为决策者和系统开发人员的有用决策辅助工具。增量式和迭代式开发是敏捷开发的一个核心方面，它允许用户尝试软件的早期工作版本，以促进在新的或完善的需求方面向开发人员提供建设性的反馈。这篇博文还展示了该模型如何验证增量开发与传统开发和获取实践相比，满足需求增长而减少了对计划的干扰的断言。特别是，使用敏捷的增量开发可以减少后期需求添加的影响，方法是在正常的迭代规划过程中引入需求添加。
系统动力学仿真模型
SEI多年来一直致力于使用国防部内的数据来促进更好的软件开发和更好的获取。我们使用因果模型作为开发仿真模型的基础，该模型可以是获取管理者的决策辅助工具，使其能够应用数据揭示的见解。因果模型看起来超越相关性，以建立变量之间的因果关系。
系统动力学模型在结构上具有因果关系。我们使用系统动力学模型来描述软件密集型系统获取过程.我们的模型包括政府项目管理办公室(PMO)的管理流程，以及承包商的软件开发过程。通过仿真，我们可以对这些过程进行评估，以提高性能。
当过时的需求被拒绝或延迟时，决定通常是由保持进度的需求决定的。但是，有压力要提前实施最新的需求，尤其是在联合计划中，这些计划有很高的动力去满足各种利益相关者的需求。拒绝迟交的要求可能导致社区购买的问题。
图1：库存和流量基础结构
图1显示了与开发过程相关的模型的基本库存和流量结构。从开发_工作_剩余库存开始，与后期需求相关的新工作可能会添加到剩余工作中。随着工件的发展，它们会进行单元分析，例如单元测试或静态代码分析。未能通过单元分析的工件将转到失败_工作_剩余库存，并最终得到修复。最终，工件被传递用于系统测试，当需要修复或重新加工新的工作时，这些工件可以返回到开发过程中，这需要对先前开发的工件进行改变。
图2：完整的系统动态模型概述
图2中显示了一个更完整的实例化模型。开发流程的库存和流程在中间，图的左上方有额外的库存和流程，用于后期需求处理和跟踪缺陷。如紫色所示，被接受的最新需求会产生新的工作，并最终会刺激返工。当感知的完成日期与宣布的日期有所不同时，关键动态将以红色显示，从而产生进度压力。进度压力促使质量保证捷径产生更多缺陷，同时作为较少严格的单元分析的一部分，发现更少的缺陷。这些捷径可以在短期内加快开发速度，但会在最终发现这些缺陷时产生更大的进度压力，而当这些缺陷难以修复时，可能会大大缩短生命周期。图中压力引起的缺陷。
执行模型
系统动力学模型的执行探索了敏捷的一个方面（即，增量开发）相对于整体系统开发的好处，并找到了通过微调敏捷实践的应用来放大这些好处的方法。该探索的参数是
·基线大小
·后期需求水平
·增量数
·测试严谨性
·日程安排的现实性
·人员配置水平
该模型的基本运行假设由15.5名全职等效开发人员开发了1100个需求，从而产生了110K个等效源代码行（ESLOC）。由于计划压力及其相关的质量保证过程捷径，会引入缺陷。整体开发根据需要每24个月最多授予2个计划扩展，尽管这些也是可以在模拟中更改的参数。增量开发将后期需求的引入延迟到下一个增量，并从那里制定新的时间表。缺陷修复时间由对数正态分布生成，平均一个人修复缺陷的时间为2.2天。
上面用于校准模型的值来自两个数据源：
·SEI 国防部软件简介，2017年7月发布
·在SEI的团队软件流程（TSP）研究中建立的行业指标
通常需要使用多个数据源来全面了解实践中发生的情况，但是这些源的不同假设和目标使统一该图像具有挑战性。我们经过校准的模型将这两个来源合并在一起，以表示DoD
Software Factbook的普通DoD大型项目开发人员与使用TSP的高于平均水平的开发人员之间的开发概况。
图3显示了仿真结果，该结果比较了通过整体大型开发项目连续引入其他后期需求与在下一个增量计划周期中针对五个增量中的每一个引入这些需求的效果。模拟进行了84个月（7年），其中整体显示为蓝色（模拟运行1），增量显示为红色（模拟运行2）。
图3：大型整体开发和增量开发的比较
在系统获取过程中较晚引入其他需求可能会导致进度增长超出需求本身。该模型的初步观察结果支持以下结论：与整体系统开发相比，增量开发可以适应需求增长，并且对计划的干扰更少。增量开发比整体开发提前15个月完成，这主要是由于返工量减少了40％。进行此改进的主要原因是减少了计划压力（和流程捷径）。在下一个迭代计划周期中引入较新的需求可将累积或返工减少40％。下表1列出了模型中整体开发和增量开发的缺陷生成和修复配置文件。
表1：大型整体式和增量式发展仿真的缺陷概况
上面的分析提出了一个问题，即两种开发方法将如何处理不同级别的后期需求引入。BModSIm的优点是我们可以使用工具来探索这个问题。下图显示了对于整体系统开发，当后期需求达到初始基准范围的35％时，进度将增加两倍。增量开发使此计划的增长减少了40％。
图4：增量式开发可以更好地容忍范围增长
展望未来
我们的系统动力学在敏捷软件开发中的应用是一项正在进行的工作，但它展示了BModSim方法在回答有关敏捷应用程序的关键问题方面的潜在价值，特别是在扩展其传统应用程序的上下文中。未来的潜在工作包括基于内部缺陷率和修复效率的内部度量对现有模型进行进一步的校准，除其他可能的收益之外探索敏捷的极限，扩展模型和仿真以支持敏捷项目经理和企业的决策。政策制定者。
在模型细化、验证和校准方面需要做更多的工作，以便将该工具塑造成真正的决策辅助工具。 |
