敏捷软件开发和基于模型的设计工程

大多数团队开发软件工程应用今天认识到传统的缺点(瀑布)方法。这些包括缺陷的发现和设计问题在项目的后期阶段,无法适应需求的变化,和交付系统的风险,不满足客户的需求。

为了克服这些缺点,许多团队采用了一种结合了敏捷方法和基于模型的方法设计。

基于模型设计的考试和敏捷方法表明,基于模型的工程应用设计补充甚至使敏捷。像敏捷,基于模型的设计是支持快速迭代。万博1manbetx这也符合系统工程的挑战不是仅仅通过敏捷来解决:

• 如何执行早期没有访问设备测试
• 如何管理工程系统的复杂性
• 如何降低测试未经证实的软件的风险代价高昂的硬件
• 如何满足功能安全的要求和其他标准,包括- 178 b / C和ISO 26262吗

这篇文章解释了如何基于模型的设计支持敏捷开发的核心价值观,与一个自适应巡航控制的例子,结合万博1manbetx了基于模型的设计和敏捷方法和Scrum框架。

敏捷的核心价值映射到基于模型的设计

敏捷软件开发宣言定义了四个核心价值观:

• 个体和交互过程和工具
• 全面的文档的工作软件
• 客户协作重于合同谈判
• 响应变化胜过遵循计划

该宣言的作者指出,“在”并不意味着“不”。他们提出的是一个转变的重点:“虽然有价值物品在右边,我们更看重左边的项目。”

让我们来看看这些敏捷值映射到基于模型的设计。

关注个体和交互

在基于模型的设计流程和工具,建模和simulation-foster富有成效的个人和团队之间的交互。该模型可以直接在仿真软件共享万博1manbetx^®在一份报告中,或作为一个web页面,使所有利益相关者使用它作为一个共同的参考点和真理的单一来源。仿真结果是清晰可见的,可以方便的设计决策,与利益相关者Scrum计划和讨论。

专注于客户合作

客户协作是敏捷方法的核心。每个sprint计划会议开始,结束回顾会议,经常邀请客户提供输入。建模与仿真不仅支持生产客户协作,但也使跨团队合作,领域和学科。万博1manbetx从硬件设计工程师,系统设计,功能和组件开发有一个共同的语言,可以集中在一起工作,而不是担心工具。

关注工作软件

基于模型的主要优势之一,设计团队使用敏捷开发的能力系统的一个工作版本的最早的冲刺,即使嵌入式目标,植物、传感器、或其他硬件不可用。通过万博1manbetx仿真可以作为仿真软件模型验证工作软件在整个项目中。模型作为系统的一个可执行的规范发展。早在冲刺,当硬件可能不可用,仿真结果可以与客户共享代替硬件测试结果和用来衡量进展,寻求支持,或者下一个sprint计划。模型还提供一个清晰和方便的方式来衡量进展。模型阐述了,它可以用来生成代码software-in-the-loop(银),processor-in-the-loop(公益诉讼)和半实物(边境)测试以及实时原型和生产系统。

这个模型还充当全面文档化的基础。在基于模型的设计中,文档是一个设计过程的输出,而不是离散的任务,可以从模型中生成文档和报告。

专注于应对变化

瀑布开发的主要障碍是无法充分响应不断变化的需求和条件。敏捷开发和基于模型的设计解决这个缺点,使团队更有效地应对变化。对于任何重要的变化在一个工程应用,使用基于模型的设计工程师可以修改模型,然后简单地重新生成代码。实现任何更改之前,团队可以假设分析确定最佳运行方式以适应特定的变更请求。在模型中进行更改后,工程师可以运行模拟回归测试,以确保系统中变化不会引起意想不到的行为。当模型与需求,团队可以执行影响分析来了解改变模型的一部分会影响其他部分。

用例:结合敏捷方法和基于模型的设计开发一个自适应巡航控制器

在这个例子中,一个汽车工程团队开发软件的自适应巡航控制系统与传感器融合。系统融合输入数据从车载雷达和视觉传感器来识别最重要的对象及其自我适应车辆的速度和距离保持安全距离。

在这个项目中,一组工程师致力于开发控制算法而另一个开发驾驶场景和合成传感器数据。这种合成数据将使工程师开发和测试算法在实际传感器数据变得可用。早期的模拟使用合成数据可以通知设计决策,如类型、数量,车载传感器的定位。

在第一个冲刺,每一个子团队(或一组工程师)模型各自的子系统,使用共享的系统级仿真软件模型(图2)来协调他们的工作。即使在这个早期阶段,他们可以运行模拟,看看控制器在不同条件下的行为。万博1manbetx他们调试控制器,确定优化参数,从一个工作版本和可视化关键性能指标的变化在写作或生成一行代码。

审查会议期间与客户第一sprint快结束的时候,他们共享模型和仿真结果(图3)。该模型和结果提供一个具体的工作软件的例子中,通过举例说明如何另一辆车后车辆的速度减少转移到车道上。

在随后的冲刺,团队改进或提高模型基于客户反馈的例子中,通过调整后的安全距离或速度的改变车辆加速或decelerates-and优化代码生成和部署的ECU。生成的代码可能被用作与遗留代码或集成作为一个更大系统的一部分。持续集成(CI)与詹金斯™是用来不断检查生成的代码与手工的集成代码,运行测试模型,检查符合建模标准,和之后,对生成的代码进行测试。所有这些活动的结果报告为利益相关者不使用自动跟踪进展和开发工具。

在后面的冲刺,团队将更严格的验证和确认活动,包括银、公益诉讼、或边境测试,以确保设计满足需求。他们也检查模型和代码遵守已建立的标准和指导方针,使用静态分析和正式的方法来证明缺乏关键的运行时错误,并生成报告和其他工件在准备认证标准。

随着项目的进展,客户需求可以转变。例如,客户可能请求模型预测控制,而不是一个经典控制算法因为一个先进的MPC控制器使车辆更激进的行动作出反应的其他车辆的环境。因为一个系统模型被用在这个项目中,该算法团队可以很容易地替换原来的控制算法和新开发的模型预测控制器和离开模型的其余部分保持不变。团队重播模拟和与客户分享结果。一个明智的决定可以在是否进行设计更改或恢复到以前的方法。

这个团队使用基于模型的设计在他们的敏捷开发流程和交付工作软件在硬件有关。建模与仿真使团队不断提高设计根据客户反馈,甚至适应重大需求变更在项目后期。