必须得会的汽车ECU研发基础—软件管理工具7

0 前言

ECU开发通常采用V流程形式，为了使V流程能运转好，必须要有强有力的管理工具支持才行，这样才能使开发能满足需求，且具有追溯性，同时也能管理好不断迭代更新的开发数据。目前使用过的V流程管理工具有Excel，Doors和 MKS，其中Excel是在以前没有另外的管理工具用过，且用得太初级，效果很不好；Doors只是一款很成熟的需求管理工具，不足以覆盖整个V流程，好像也没谁听说过用得很爽；而MKS使用时间最长，基本上都覆盖V流程各个阶段的管理，总体我觉得还是非常好用。因此，本文我就以MKS为例，介绍其都有哪些功能，以此也概述下一个软件开发的大致流程和文档管理。

1 MKS介绍

MKS，也称为PTC Integrity， 是一款应用程序生命周期管理 (ALM) 软件。它有助于团队管理产品和系统需求，实现闭环产品验证，并加快全球软件开发。PTC Integrity 能让企业解决在开发现代化的产品和应用程序时遇到的复杂性问题。利用 PTC Integrity，开发团队能够改善工作效率和质量，简化合规，以及清楚了解产品的整体状况，最终推动更具创新性的产品进入市场。PTC Integrity 管理全球软件开发过程并将系统和软件项目（包括需求、模型、代码和测试）联系在一起以确保整个生命周期完全可跟踪[1]。

2 需求与变更，测试管理

在MKS可实现需求与变更，测试管理。软件开发内容一部分来源于最初始的客户需求，另一部分来源于开发过程的客户不断新增需求或变更，这些内容都可以在MKS的需求管理功能中操作，如上篇文章提到的客户需求，系统需求，软件需求，这些需求可按先后层次区分，即系统需求来源于客户需求，软件需求来源于系统需求，同时他们之间可建立明确的追随关系，即一条客户需求至少被一条系统需求覆盖，同理软件需求也是。

需求必须被测试验证，因此需要对不同层次的测试用例，即系统需求有对应的测试用例，软件需求也会有对应的测试用例，这些测试用例都可以在MKS的测试管理功能中添加和管理，且能建立测试用例与需求的追溯关系，即一条需求至少被一条测试用例覆盖。

下图示意了一条需求与一条测试用例的追溯关系：

我们知道一个产品的研发会经历几个阶段，随着项目的进行，会出现多次锁定需求或多次释放软件的情况，所以经常会使用MKS来打baseline，也就是说和客户确认好了需求，我们就会标记或锁定一个版本的需求，软件和测试，后面有新的变更或变化，在此基础上继续开发，这样就能清晰地知道每次锁定或释放的内容，还能对比出不同版本之间的差异，很有利于软件需求和源代码的管理。

• 3 源代码管理
• 在软件开发过程，模型或源代码会随着需求的增加而不断升级，如下图所示：最开始开发好了一个功能，上传最初版的模型或代码到MKS，如1.1，然后随着开发了更多需求，在主支有了1.2，1.3，比如客户要求1.3版本需要释放做测试，那么1.3就会被集成释放，在释放之后客户测试反馈有bug，而这时已经开发到1.4了，且1.4的内容不应该包含在1.3释放的测试版本，那么就需要在1.3创建分支保存修复bug的软件，以这种方式满足客户要求释放的测试版本，也保证软件管理有序进行。当然像下图1.3.1.3发展了一条独立的分支，而1.4.1.2又回到主支，这个主要由需求或项目定义决定。有时几个项目基于同样base开发，就需要采用主支与分支共存的方式来管理。

• 

MKS提供这样的方式来管理源代码，只要及时上传源代码，就可以保存好开发成果，做好历史版本和信息的管理，另外一大好处是非常利于软件的释放操作，下面将会提到。

4 软件释放管理

MKS里源代码被称为成员（Member），不同成员构成项目（Project），这里Project可以理解每次向客户释放一次需求或软件所生成的成员集合。就如下图示意：Project 1.2包含了两个成员code A.src 1.3和code B.src 1.4版本，其实在MKS操作是先选中了他俩为目标版本，然后从Project 1.1 升级（Checkpoint），就会生成Project 1.2。记得以前做软件集成的时候经常要干这样的活，即根据释放计划先选择各成员的目标版本，再软件集成之后就会去checkpoint，生成目标Project。 

在上述管理或释放过程，除了源代码，还有文档之类的内容其实也是采用同样的方法来管理，比如对于开发有详细设计说明书，对于评审有评审记录表等。

5 过程和工作流管理

上面相当于介绍了V流程中的各个阶段所包含的内容，但是要让V流程流畅运行起来，还需要对开发过程和工作流进行管理，MKS中提供流程管理功能，具体以一个例子来说明：假如要开发一条需求(如下图红框的Change request)，那么按照V流程的话，需要分4步来执行，先需求分析，再详细设计，然后单元测试，最后集成测试，这里把每步的工作成为成一个任务Task。对于每个任务，为了保证开发质量，需要安排不同的人去分别做设计和评审工作，同时也需要有状态来表示任务开发的情况，是设计中，评审中还是已完成等。也就是说当设计的人完成详细设计开发，就可以将任务状态切换到评审，然后评审的人接收了就会展开工作，没问题将切换为已完成，这时下一个任务单元测试就会开启，负责单元测试的人就可以开始测试，这就是关于需求如何被分解成任务，任务如何被执行以及如何被切换的过程，这样就使得V流程能够从左到右有序执行。

当然MKS的这个功能还支持项目经理或者软件经理来预估软件释放时间的合理性以及评估项目开发的状态。具体怎么实现呢？就是当每条需求被分解每个任务后，会有软件经理或者对应工程师来评估开发时间，即详细设计多少天，评审多少天，以此就可以知道每个需求多少effort。而客户需要在多长时间内释放多少需求时，与MKS的评估effort结果对比，就能快速识别，然后可以与客户或内部沟通，折中一个合理的计划。另外软件经理通过MKS这个功能检查各个需求或任务的状态，比如某些任务完成明显不及预期，那么就可以及时发现，可能能提前识别出风险点等，以保证项目或软件尽量按计划进行。

6 总结

• 以上就以MKS功能为例，介绍了V流程是如何通过专业的管理工具被实施的。总的来说，需要管理工具来保证需求，设计，测试的追溯性和保存它们所产生的历史数据；同时保证开发过程和工作流程的有序执行，甚至协助项目的管理。

Reference:

[1] https://www.ruanfujia.com/software/10342/

作者：谦益行
文章来源：上汽零束SOA开发者论坛 
原文链接：https://bbs.z-onesoft.com/omp/community/front/api/page/mainTz?articleId=7632