敏捷环境能否加速嵌入式软件验证和认证

　　尽管大多数软件开发组织都采用敏捷开发，但大多数嵌入式开发人员，尤其是那些寻求认证的开发人员，仍然抵制使用敏捷方法。与获得认证所需的传统规范方法和工件相比，开发人员认为迭代敏捷方法的风险更大。具体问题源于如何在敏捷过程中捕获需求，以及如何在嵌入式系统硬件可用之前满足敏捷开发的早期和经常测试原则。

　　反对者没有考虑到的是已经可用的工具范围，这些工具有助于确保在采用敏捷方法时满足认证目标。是什么将它们编织在一起？需求可追溯性使软件分析和验证在每个冲刺中成为可能，硬件仿真工具使持续验证成为可能。最后，工作流管理工具有助于将所有项目工件整合到一个协作环境中，同时定义和管理项目认证标准目标。

　　捕获用户情景

　　那么，如何获得严谨性呢？反对者声称敏捷流程避开了所有认证活动所依赖的正式要求。尽管敏捷流程的开发在一整套功能需求可用之前就开始了，但这并不意味着在敏捷过程中生成的需求比传统的规范方法更不严格。

　　敏捷方法隐含着早期和经常失败的概念，从系统需求开始。敏捷中的前期规划需要与客户合作开发一系列用户“故事”，以封装所需的系统功能。然后定义开发过程的每次迭代处理这些故事的顺序，每次迭代的目标是发布一个版本，即它完全正常运行、经过全面测试，并且是包含最高优先级功能的潜在可部署系统。

　　作为文档或需求捕获工具捕获，用户故事可以汇集到工作流管理工具（如LDRA的TBmanager）中。开发代码后，可以将条目提交到工具，从而使代码能够追溯到用户故事。在下游，工作流管理器还可以将代码映射到软件验证活动和结果。然后，工作流管理器成为认证所需的所有验证证据的所在地。

　　将质量融入软件

　　为需要认证的系统生产潜在的可部署软件需要满足软件的所有认证标准验证目标，这是对敏捷口头禅“尽早和经常失败”的完美补充。通过静态和动态软件分析技术的组合实现最高水平的软件质量，所有这些都可以从工作流管理器中访问，以确保维护分析的结果和上下文。

　　静态分析

　　静态分析是指在不执行代码的情况下审查正在开发的代码以发现和修复质量问题的做法。例如，当您使用自动化工具验证代码标准合规性时，可以使用静态分析。认证标准要求使用编码标准和质量分析来验证开发的代码是否已统一设计和实施。在开发、集成、测试和验证的所有阶段实施这些标准具有以下几个优势：

　　• 消除

　　潜在缺陷• 通过创建统一代码提高代码的可读性和可维护性• 防止过于复杂的代码更容易出错且更难维护

　　• 识别无法访问或使代码

　　覆盖率的测试构建具有挑战性

　　的代码• 生成更模块化的代码，更容易追溯到低级需求

　　动态分析

　　敏捷方法使用测试来持续提供有关新兴产品满足业务需求程度的反馈。敏捷团队不断测试，因为这是确保每次迭代的功能都已完成并取得进展的唯一方法。

　　对于嵌入式系统，软件开发取决于目标平台的可用性，但该硬件通常要到开发生命周期的后期才可用。敏捷开发人员依靠硬件系统模拟器（如Wind River Systems Simics）来帮助填补这一空白。

　　这些工具模拟完整的目标系统，并且可以在仿真框架内运行未经修改的目标软件（相同的引导加载程序、BIOS、固件、实时操作系统、板级支持包 （BSP）、中间件和应用程序）。使用硬件模拟器意味着敏捷项目的硬件相关测试可以在尽可能早的迭代中开始。

　　作为补充，测试自动化工具可以在模拟硬件上自动生成和执行测试用例。可以经常运行自动测试用例生成和执行，在几分钟内提供反馈。然后，可以从工作流管理器中控制这些测试的测试用例生成、执行、结果和状态，以提供对当前迭代进度的可见性。

　　对于认证，有必要使用代码覆盖率来衡量测试完整性。认证需要适当程度的测试严格性，这意味着所有测试都必须基于需求并在系统级别执行。如果没有代码覆盖率分析，就不可能获得提高测试有效性所需的反馈、知识和理解，并且它提供了额外的保证措施，即满足当前迭代的潜在可部署系统目标。

　　认证和文件

　　使用工作流管理器作为所用工具和在整个开发过程中生成的结果的主机，使生成认证所需的文档变得非常简单。可以从该工具访问所有项目工件，从而有助于准备要呈现给证书颁发机构的数据。

　　这也是为寻求认证的项目通过嵌入式系统开发加速敏捷方法的关键。在工作流管理器中管理项目工件有助于确保从需求到基于主机和目标的验证结果，它们在敏捷项目的每次迭代中都得到维护。

　　审核编辑：郭婷