（五）、使用基于模型的设计改进开发方法

最新推荐文章于 2023-07-10 14:18:14 发布

Nautiluss

最新推荐文章于 2023-07-10 14:18:14 发布

阅读量196

点赞数

分类专栏：基于模型的设计文章标签：汽车单片机 matlab

本文链接：https://blog.csdn.net/Nautiluss/article/details/130625768

版权

基于模型的设计专栏收录该内容

9 篇文章 2 订阅

订阅专栏

从 70 年代末到 90 年代初，瀑布模型（）是标准的软件开发方法。它严格的、循序渐进的方法很适合当时的官僚或矩阵组织。然而，20 世纪 90 年代中期互联网和其他技术进步的出现加快了软件项目变革的步伐，需要更灵活的方法。
当今的工程组织使用范围广泛的开发方法。理想情况下，项目经理选择最适合项目性质和正在开发的系统的方法。然而，在现实中，情况并非总是如此，一个团队可能需要对每个项目使用相同的方法——不是因为它是最佳的，而是因为这一直是完成工作的方式。

        从构造到进化：通用开发方法
        大多数开发方法都介于经典的、基于计划的“构建”方法和更灵活、迭代的“进化”方法之间。以下方法是最常见的：
        • 瀑布
        • V-Model
        • 迭代和增量开发 (IID)
        • 螺旋
        • 敏捷开发
        • 极限编程 (XP)

瀑布开发

瀑布方法将开发分为五个步骤或阶段：需求、设计、实施、验证和维护。每一步都必须在下一步开始之前完成。

瀑布方法易于管理和理解。仔细记录工作和项目细节，确保在团队成员离开项目时不会丢失信息。只要需求和过程保持不变，瀑布就可以很好地处理大型系统开发，但它的逐步方法过于僵化，无法处理需求的变化。此外，瀑布不鼓励创新。 为了有效，它需要团队成员以前解决过类似的问题。

         瀑布方法中的基于模型的设计
        基于模型的设计通过以下方式增强了瀑布方法：
        • 自动化使应对变化变得更加容易。当报告生成等任务自动化时，重做一个步骤会更容易。
        • 系统级仿真通过显示组件之间的交互使管理复杂性变得更加容易。
        • 假设分析使团队成员能够快速且无风险地尝试新想法，从而促进创新。

V-Model开发

V 模型开发方法在汽车组织中很常见。它使用与瀑布基本相同的步骤。不同之处在于，它不是以线性方式执行这些步骤，而是在实施（编码）阶段之后向上弯曲，从而将每个开发步骤与相应的测试阶段相匹配。

V 模型的主要缺点是整个系统设计都是在一开始就开发的。这使得很难处理复杂的系统，其中某些组件、交互或其他元素可能要到过程的后期才能知道。

        V 模型中基于模型的设计
        基于模型的设计以许多与增强瀑布相同的方式增强了 V 模型方法：
        • 自动化使处理变化更容易——当报告生成等任务自动化时，重做一个步骤更容易。
        • 系统级仿真通过显示组件之间的交互使管理复杂性变得更加容易。
        • 假设分析使团队成员能够快速且无风险地尝试新想法，从而促进创新。
        • 系统级建模和仿真使得在一开始就开发整个系统成为可能，即使关键元素是未知的——这些元素可以在以后添加而不会中断开发流程。

迭代和增量开发

迭代和增量开发 (IID) 以一周到六个月的周期（发布）进行。每个周期的目标是交付一个部分完整的系统用于集成和测试。通常，在早期周期中花在需求上的时间比在后期周期中花费的时间更多，但所有周期都包括生产编码。这意味着没有原型或概念验证版本。

团队以不同的方式选择要在每个周期中实施的任务。在基于风险的选择中，最先执行风险最高的任务。如果他们失败了，该项目可以调整或取消。在基于客户的选择中，客户或客户决定在每个周期中执行哪些任务以及是继续还是终止项目。

        IID 在以下情况下效果很好：
        • 任务和功能是独立的。
        • 正在将功能添加到现有的正常运行的系统中。
        • 正在维护阶段添加功能和修复程序。
        • 以前完成过类似的项目，并且了解依赖性和复杂性。
        IID 有以下缺点：
        • 每个周期中的风险评估和需求分析引入了大量流程（ceremony）。
        • 增量交付需要一个灵活的架构，允许不断添加功能。如果体系结构是所有代码的重要组成部分，或者如果功能齐全的系统需要大量功能，这可能是一个缺点。
        • 当项目包含未知数时，增量交付会延迟。在这种情况下，必须在开始交付之前完成包括原型设计和试验在内的广泛研究。
        • 虽然较短的循环时间降低了每个循环的复杂性，但随着功能的增加，完整的系统动态可能会出现问题。在所有功能都到位之前，这些问题不会变得明显。
        • 风险评估、需求分析和规划的开销会使这种方法对于较小的项目效率低下。

        IID 中基于模型的设计
        基于模型的设计通过以下方式支持 IID：
        • 您可以使用自动化来管理所需的任务或流程。
        • 您可以通过使用假设分析和模拟来增加创新。
        • 系统级仿真提高了该方法处理复杂性的能力。
        • 自动化和模拟可以使每个周期中的工作更有效率，这有助于缩短周期时间。自动化还减少了与风险评估、需求分析和规划相关的开销。
        此外，基于模型的设计使您能够将自上而下的方法整合到 IID 工作流中。在自上而下的方法中，在工作流程的每个步骤中向设计添加更多细节，并通过性能、风险、功能等方面的仿真不断评估设计。这种方法具有以下优点：
        • 在早期迭代中，高级模型可用于评估需求和设计概念。结果，在将增量集成到最终产品之前，系统和集成问题就被很好地发现了。
        • 通过自上而下的开发，可以快速完成原型设计和试验，降低包含未知数的项目延迟交付的风险。
        • 仿真输出和快速原型制作结果可以在开发的每一步都呈现给客户，从而更容易管理、记录和共享复杂系统。
        • 自上而下的方法更容易管理变更。在部署功能或组件之前，可以使用模拟来了解新组件将如何影响系统。

螺旋开发

螺旋方法使用许多与瀑布方法相同的步骤：需求、设计、实施和测试。不同之处在于，这些步骤以一年或两年的周期完成，重点关注整个系统的某些功能。一旦一个周期完成，团队将重新评估项目风险和要求，并决定是否继续。如果项目继续，另一个周期开始。随着每个周期，风险降低，最终系统的更多功能得以实现。

螺旋方法主要用于处理大型项目中的风险，但它也能很好地处理变化和创新。它的迭代性质使团队能够专注于实验和创新，而不是交付。它可以很好地从小型项目扩展到大型复杂系统，例如飞机、军用车辆或风力涡轮机。
螺旋式的主要缺点是它没有定义特定的方法来管理正在开发的系统的复杂性，并且它只有一个主要版本，这使得它不适合必须逐个交付的项目。

        螺旋式开发中的基于模型的设计
        • 您可以通过将假设分析和模拟纳入设计迭代来支持螺旋方法的创新。
        • 系统级仿真提高了处理复杂性的能力。
        • 自动化和模拟可以使每个周期内的工作更有效率，减少周期时间。

Scrum 开发

Scrum 方法源于敏捷原则，采用简约的开发方法。在敏捷开发中，开发由小型、自我管理的团队执行。任务在两周到四个星期的时间内执行，称为冲刺。参与者在每日 Scrum 会议上报告他们的进展。在每个冲刺结束时，客户（可以是内部客户）需要接受工作并确定工作队列中剩余任务的优先级。

Scrum 开发需要很少的开销（浪费）。凭借其快速迭代，Scrum 开发可以很好地处理快节奏的变化。Scrum 开发定义了如何计划和组织项目，但没有定义开发工作的执行方式。因此，它没有提供管理具有相互关联部分的复杂系统的过程。由于Scrum 开发严重依赖于非正式沟通和接近度，因此它对地理上分散的团队（远程办公）的可行性还有待证明。

Scrum 开发中基于模型的设计
借助系统级仿真，您可以管理更大、更复杂的系统，因为仿真将每个周期中的所有部分组合在一起，使团队更容易处理交互和界面。对于敏捷开发团队中的个人，假设分析和基于模型设计的其他概念可能很有用。自动化可以帮助您的团队在较短的敏捷开发周期内交付大型项目。

极限编程 (XP Extreme Programming)

        与敏捷开发一样，XP 方法论源自敏捷原则，但敏捷开发侧重于项目管理，而 XP 侧重于通过定义如何进行实际开发工作来提高质量和生产力。
        XP 在称为发布的短开发周期中进行，具有用于引入新客户需求的内置检查点。 XP 强调对所有代码进行广泛的代码审查和单元测试，但它避免建立正式的方法和文档。
        XP 的极简主义、分散式方法需要经验丰富的程序员共享一个工作区。当团队成员分散在各地、经验不足的工程师加入项目，或者团队成员离开并带走了他们未记录或未存储的知识时，就会出现问题。

        XP 中基于模型的设计
        XP 可以通过与敏捷开发类似的方式从基于模型的设计中获益：
        • 系统级仿真支持分散方法，使团队能够将项目的各个部分放在一起。系统级仿真还有助于管理这种分散方法中各部分之间的复杂性、交互和接口。
        • 自动化和持续测试与验证支持持续集成（构建和重新测试）的 XP 实践。
        • 使用模型获取和管理知识支持 XP 的极简主义文档方法。如果人们离开或改变角色，模型将用作文档和存储知识。

管理流程（Managing Ceremony）

每种开发方法都涉及一定程度的流程——正式的步骤和程序、文档、审查流程和指标。通常，使用多个短周期的方法比使用更少、更长周期的方法需要更少的流程：

        • 瀑布式项目是非迭代的和基于文档的，因此非常有仪式感（流程多）。
        • V 模型在流程上得分很高，因为它指定了用于测试和验证的正式步骤和文档。
        • IID 使用了几个长周期，并依赖于持续的风险评估和需求分析，使其具有很高的仪式感（流程多）。
        • 螺旋有几个长迭代，具有持续的需求和风险分析。
        • 敏捷开发使用中等数量的周期，没有特定的流程要求；因此，它可以被纳入任何仪式级别的流程中。
        • XP 有很多短周期，因此，流程很少。

基于模型的设计可以帮助组织在不减慢开发速度的情况下满足流程要求。因为基于模型的设计自动化了报告生成和代码审查等过程，所以可以在不影响周期时间的情况下引入更多的流程或形式。
同时，代码审查等仪式元素的自动化意味着 XP 等仪式性非常低的方法可以在不失去该方法优势的情况下引入更多流程。如果您需要将认证要求纳入您的工作流程，这会很有用。

选择开发方法

Boehm 和 Turner (2004) 将开发方法分为两种类型：计划驱动（瀑布、V 模型）和敏捷（Scrum、XP 和 IID）。每种类型都有一个主场（适合的领域）。计划驱动的方法适用于具有稳定需求、大型开发团队和需要秩序的文化的大型、复杂、高完整性系统。敏捷方法更适合需求不断变化和截止日期紧迫的项目，以及在混乱中茁壮成长的文化。
同样，当团队距离足够近以实现自发沟通时，敏捷方法会更加有益。当团队分布在多个地点时，可能在不同的国家/地区，则需要进行更多的规划。

         选择开发方法时，请考虑以下问题：
        • 您的项目要求有多稳定？
        • 最后期限有多紧迫？
        • 项目规模有多大？
        • 项目团队在哪里？
        • 是否涉及关键资源？
        • 项目是业务关键型还是任务关键型？
        每个问题都很容易单独解决，但综合考虑，可能需要权衡取舍。例如，对于安全关键且要求预计会发生变化的小型项目，或者对于期限紧迫且需要关键资源的大型项目，可能需要进行权衡。
然而，当您考虑这些权衡时，请记住 Boehm 和 Turner 的观察，即计划驱动和敏捷方法都是“未来软件成功的关键”。小型项目和团队需要能够扩大规模，而大型项目和团队需要更加灵活（互补的原则）。

使用基于模型的设计改进您的开发方法

基于模型的设计可以帮助您根据当前需求调整任何开发方法。这意味着当传统的、基于计划的开发方法（如瀑布）在不断变化的环境中受到影响时，您可以使用基于模型的设计将其转换为更适合新条件的方法。

瀑布方法在采用基于模型的设计（实线）之前和采用基于模型的设计（虚线）之后处理变更、项目规模和创新的能力

         涉及大型物理系统（例如飞机、卡车或风力发电平台）的项目传统上使用瀑布模型或 V 模型。在基于模型的设计的帮助下，您甚至可以对这些类型的项目采用迭代方法。通过模拟模型而不是实际的物理系统，您可以确保正确的测试级别和程度。
        实施基于模型设计的核心概念可增加每种开发方法可用于的项目类型和种类。例如，一个使用系统级仿真、代码生成、报告生成和持续验证的团队可以使用 XP 来处理一个由 20 名工程师组成的关键任务项目。同样，一个不是关键任务但包含新技术且具有高风险的较小项目可以使用更具仪式感的方法，例如 IID，即使该项目仅涉及六名工程师。
        当需要权衡时，基于模型的设计特别有用。例如，如果您的项目有关键资源或昂贵的测试装置，这指向基于计划的瀑布或 V 模型。
        基于模型的设计可以通过引入可以模拟的模型而不是在原型上进行测试来提供帮助。这缓解了原型导致的瓶颈，并允许采用更敏捷或迭代的方法来开发。另一个示例是具有安全关键应用程序的小型项目。项目的关键性需要基于计划的方法，包括安全标准。使用基于模型的设计，您可以自动生成许多所需的文档和工件，并通过仿真执行早期验证。基于模型的设计有助于与安全标准相关的仪式，并允许采用更灵活的方法。