基于ALM系统的嵌入式软件平台管理方案

王飞飞 史家涛 王梦 何晓飞

(潍柴动力股份有限公司 山东省潍坊市 261061)

嵌入式软件通常是基于项目来管理构建每一版软件所需要的需求、变更、缺陷,在传统的嵌入式软件管理模式中,各嵌入式软件开发项目之间相互独立,各项目分别管理本项目下的需求、变更、缺陷,发起版本构建任务,并交付构建后的软件,整个过程采用V流程的开发模式。但在实际开发过程中,同一组织的不同嵌入式软件开发项目之间会存在大量可复用的需求、变更、缺陷,基于项目维度的管理方式,会造成同一需求、变更、缺陷的多次重复调度,重复分析、设计、实现、集成、测试,这会造成对组织资源的巨大浪费。

与此同时,在配置管理方面,传统嵌入式软件基于需求、变更、缺陷所产生的模型或者代码的配置管理模式也是针对项目本身分别开展配置管理,这决定了同一需求、变更、缺陷所修改的模型或者代码的配置管理工作也需开展多次。在传统项目制模式下,不同项目中对同一模型的负责人可能并不相同,极有可能造成在一个项目中已经被正确实现的需求,在其他项目中却未被正确实现的问题,无法保证需求与所关联模型与代码版本的一致性,从而造成最终产品的质量问题。同理,传统项目管控模式亦无法保证缺陷、变更在不同项目之间的移植复用率。

针对上述问题,本文提出了嵌入式软件平台化管理方案,通过平台类项目以及应用匹配类项目的建设,实现对可复用需求、变更、缺陷的平台化管理,从根本上解决重复需求开发管理、重复修复缺陷的问题。

PTC公司的ALM(软件生命周期管理)系统可以实现嵌入式软件的V流程中所有环节的全生命周期管理,本文提出的平台化管理方案可以基于PTC公司的ALM系统开展。通过一系列定制开发,实现平台类项目以及应用匹配类项目在ALM系统中的线上管理,实现需求、变更、缺陷以及模型、代码的在不同项目间的灵活复用。

嵌入式软件需求通常分为三个层级:客户需求、系统需求、软件需求,客户需求直观体现客户提出的相关功能、性能、接口相关需求;
系统需求将客户需求转换为需求开发人员可以理解的技术要求;
软件需求将系统需求转化为软件层级需要实现的逻辑功能要求;
而针对软件需求层级,由于需求实现方式的不同,进一步划分为应用软件需求和基础软件需求;
应用软件需求通常是由Matlab建模实现,采用基于模型的设计理念;
基础软件需求由C语言实现。

实现需求、缺陷、变更的平台项目管理理念,需建立平台项目,平台项目架构建议如图1所示。

图1:平台项目架构

平台项目架构中包含两类平台项目,一类应用匹配类项目:其中I类平台项目为应用软件平台类项目,用于管理嵌入式软件的平台化的客户需求、系统需求、应用软件需求;
II类平台项目为硬件平台类项目,用于管理嵌入式软件中跟硬件强相关的基础软件需求,如传感器信号采集处理、驱动信号输出等;
III类项目为应用匹配类项目,用于管理嵌入式软件集成以及应用匹配类项目所特有的无法与其他项目共享的特殊需求,如专用领域的接口需求。所有对终端客户所交付的软件版本均由第III类项目:应用匹配类项目进行集成和发布。

基于平台项目的架构,建立平台项目的需求架构,并建立各层级需求的追溯跟踪关系。各应用匹配类项目共用的客户需求以及系统需求在I类平台项目中建立并维护,平台类的硬件需求和基础软件需求在II类硬件平台类项目中建立并维护。II类平台项目中的硬件需求和基础软件需求直接与I类项目的系统需求建立追溯管理,II类项目中不再需要重复维护客户需求与系统需求。I类项目与II类项目的需求追溯关系如图2所示。

通过I类、II类项目的需求管理架构,实现平台化的客户需求、系统需求、软/硬件需求管理;
并通过ALM系统中已有的建立需求追溯关系的功能建立客户需求、系统需求、软硬件需求(应用软件需求、基础软件需求、硬件需求)的双向追溯关系。通过规划的平台项目架构(图1所示)和平台项目需求架构(图2所示)及ALM系统的需求追溯管理功能,可实现各层级需求条目本身的平台化管理目的。

图2:I、II类项目需求追溯关系图

从I类平台的应用软件需求、II类平台的基础软件需求到设计实现的追溯,则可以通过ALM系统中现有的Task任务功能实现,通过Task任务,可追溯每一条软件需求影响到的模型或代码,以及模型或代码的具体版本。需求与设计实现的追溯关系如3所示。

通过图1的平台项目需求架构和图3需求与设计实现追溯关系,可以实现客户需求-系统需求-软件需求-模型、代码版本的逐级追溯关系,实现需求开发全过程可追溯。

图3:需求与设计实现追溯关系图

在实现需求全过程可追溯的基础上,针对不同层级的平台需求,开发相应层级的测试用例,通过ALM系统中需求条目的关联测试用例的功能建立测试用例与需求条目之间的追溯关系,确保所有的需求条目均有相应的测试用例进行覆盖,实现需求条目与测试用例的双向追溯,如图4所示。

图4:需求与测试用例追溯关系图

至此,基于PTC公司的ALM系统并借助于该解决方案,可实现平台化的需求开发、设计、实现、测试用例的管理和双向追溯,可有效避免同一需求、测试用例在多个项目中重复管理。

针对同一缺陷、变更需要在多个项目中解决或者实现的场景,可采取类似于平台化需求管理的解决方案,将缺陷、变更在平台项目中进行全生命周期管理,直接在平台项目中建立缺陷、变更,并在平台项目中建立缺陷、变更与需求的追溯关系,通过Task在平台项目中追溯缺陷或者变更解决过程。具体解决方案如图5所示。

图5:缺陷、变更平台化管理方案

针对软件版本测试发现的缺陷,或者在软件开发过程中发生的变更,若该缺陷或变更属于应用软件平台类项目,则直接在第I类项目下创建该缺陷或变更,通过缺陷或变更的关联(spawned by)功能建立缺陷或变更与需求条目的追溯关系;
若该缺陷或变更属于硬件平台类项目,则直接在第II类项目下创建该缺陷或变更,并建立与需求条目的追溯关系。同时,针对缺陷和变更,也需要分别设计测试用例,通过缺陷或变更的关联(validated by)功能建立测试用例与缺陷或变更的追溯关系,通过平台化项目缺陷、变更架构实现缺陷、变更与需求的追溯管理以及缺陷、变更与测试用例的追溯管理。

基于本文1-3章节搭建的平台化项目和平台化需求架构、平台化项目缺陷、变更架构的管理方案,可以实现平台化需求、缺陷、变更管理,采用平台化方式管理需求、缺陷、变更从创建、分析、实现(模型、代码)、测试用例的全过程追溯管理。

应用匹配类项目通过第III类项目进行管理,根据应用匹配的具体需要,从第I类项目和第II类项目中关联项目自身所需要的需求、缺陷、变更,基于项目所选取的需求、缺陷、变更开展集成。应用匹配类项目与平台类项目的关联关系如图6所示。

图6:应用匹配类项目集成管理

在该种模式下,同一需求、缺陷、变更可以同时被不同的应用匹配类项目进行关联集成,也可以同时被同一应用匹配类项目的不同软件版本进行关联集成;
且所关联需求、缺陷、变更的测试用例也可以直接在软件版本中直观体现;
不同的应用匹配类项目,可以基于应用匹配的具体情况,在关联的测试用例的基础上进行有目的性的筛选,开展不同程度的测试验证工作,并针对不同项目的软件版本分别显示相应测试用例的运行结果,实现基于项目和软件版本的测试验证过程的精准跟踪;
基于该方案,完全可以实现同一需求、缺陷、变更在不同项目间以及同一项目的不同软件版本的移植复用。

本文针对同一需求、缺陷、变更被多项目复用的场景,给出了平台化的解决方案,搭建了平台化项目的架构,并基于该平台化项目架构,给出了平台化需求、缺陷、变更管理的方案,基于该解决方案,可以实现需求、缺陷、变更的平台化管理;
并针对该解决方案给出了工具的实现方案,确保该解决方案可以在工具中予以实现。

猜你喜欢 测试用例嵌入式软件架构 基于云控平台雾计算架构的网联汽车路径控制内燃机与配件(2022年2期)2022-01-17浅析嵌入式软件技术的现状与发展动向科学与财富(2019年1期)2019-02-28基于模型检查的嵌入式软件构件化分析与验证现代电子技术(2016年24期)2017-01-19面向多目标测试用例优先排序的蚁群算法信息素更新策略计算机应用(2016年9期)2016-11-01嵌入式软件在计算机软件开发过程中的运用旅游纵览·行业版(2016年5期)2016-06-16VIE:从何而来,去向何方中国总会计师(2015年5期)2015-06-16企业架构的最佳实践中国信息化周报(2014年41期)2014-11-07三层架构在企业信息化中的应用中国高新技术企业(2012年8期)2012-06-04基于TestLink的测试管理系统研究新媒体研究(2009年24期)2009-07-05测试用例集的优化技术分析与改进现代电子技术(2009年6期)2009-05-31