运行结果 —— 案例一：运用于检测传感器

1.引入派生开发流程

以下报告派生开发流程运用于状态检测传感器（BSS）的开发案例。本方法是汽车研第一次引入派生开发流程，因此 ①编写USDM、②编写TM、③编写基本设计所 是组合在现有的V字开发流程的形式开发的。本项目中如图4所示，定义了流程进行开发。图4中必须新编写文档的工序为“要求分析”、“基本设计”。接下来记述这些工序变更对软件的品质和生产效率造成了怎样的影响。

图4 BSS 派生开发流程图

2.运用派生开发流程的结果

这次的开发中，研究阶段的算法对于现有的源码进行新增实装时，对基源码（约7 kstep）开发约1 kstep的新编码，以及移植约1 kstep的编码。BSS的派生开发结果（实装步骤数、开发工时数、检测到BUG数、总测试次数）以及由此算出的软件开发指标（生产效率、BUG密度、测试密度）如表1所示。本计划中BUG的定义为要返工到前一工序的原因。

表1  BSS 派生开发的结果和开发指标

（1）软件的品质。

软件品质的相关指标是“测试密度”，以单位步骤数中的测试件数求得，按IPA（独立行政法人　情报处理推进机构）的标准，50 ～ 100次／ kstep对于希望获得高品质和可信任的系统是有必要的 4）。这次开发中新开发编码是84次／kstep（移植部分已经在之前实施过测试），属于符合该标准的测试次数。“BUG密度”为单位步骤数中的检测到的BUG数，根据Beizer的调查（1990）结果报告称， 统计上而言10 ～ 30个／ kstep会潜藏在测试工序前一阶段 5）。关于“BUG密度”是10.5件／Kstep的结果，因此确认本次开发得到了开发速度提升以及确保软件品质的改善效果。

（2）软件的生产效率

软件开发指标之一的“生产效率”，表示的是单位步骤数的开发工时数，之前的汽车研中开发是（包括新开发）是约4 人月／ kstep。这次的开发是算法开发，包括应对BUG也有2.5人月／kstep的生产效率完成了开发，可以认为引入派生开发流程取得了一定的效果。

（3）总结、考察

这次检查出BUG总数为21个，存在BUG的工序细目为：“算法开发”：11 个，“要求分析”：4 个，“编码”：6个。此外发现BUG的工序是“算法开发”：4 个，“编码”：1 个，“单体测试”：5 个，“结合测试”：3个，“系统测试”：8个（图5）。

图5 Bug detection rate and bug mixing rate in each process.

从结果可以看出，BUG的一半以上是出自上游工序，BUG的一半以上是在下游工序中检查到的。检查到BUG后返工修正和验证BUG，说明很有必要改善审查方法和测试手法以及在上游工程的验证方法，以求尽早检测到BUG，在上游测试工程中检测到BUG。

另一方面，引入派生开发流程这一观点中编写“要求分析”的USDM，“基本设计”的TM和变更设计书，明确展示要求和规格的结合，对于排除缺漏型BUG原因很有效果。与之相伴的“要求分析”和“基本设计”工序中，带有BUG的比例占全部的20%以下，说明排除BUG很有效果。

运行结果 —— 案例二：运用于车载距离感应雷达

1.引入派生开发流程

以下报告派生开发流程用于车载距离感应雷达的例子。车载距离感应雷达的相关软件是与雷达本身的微电脑组装在一起的，雷达评估工具是从固件和电脑两方面评估雷达性能。无论哪种软件都被要求在新增雷达功能时缩短交齐以及提升软件品质。为了对应这些要求，应用了派生开发流程。通过引入派生开发流程，编写各种文档，实施审查，以提升QCD为目标。

2.运用派生开发流程的结果

（1）软件的品质。

表2显示了常规开发和三个派生开发过程中每个步骤的工时比，图7显示了每个步骤中的工时率。从表2和图7可以看出，派生开发过程中，设计过程的工时率增加了。换句话说，工时比从用于执行编码/测试的下游过程，转移到了用于设计的上游过程。上游流程中工时百分比增加的原因是文档创建和审查。 因此，与传统开发相比，在上游过程中产生质量的环境已经到位。

同时，作为应用派生开发过程的结果，已完成的结果超过了预计情况。原因是不熟悉创建各种文档，需要时间来检查所需规范中的详细程度，并改进文档的格式。

表3还显示了常规开发以及应用开发过程中应用程序的错误密度。缺陷密度的计算，是通过将耦合/功能测试时的故障数除以变化步数（LOC）。换而言之，在降低耦合/功能测试时的故障密度方面，应用派生开发过程的三种情况都得到了改善。

（2）软件的生产效率

表4对比了常规开发和派生开发过程之间编码的生产率。设计过程中的工时比例增加了约40％，而编码过程中的工作效率提高了约三倍。换而言之，分配给常规编码过程的工时几乎可以转移到设计过程，减少了编码过程中的返工，并且可以有效地进行工作。

（3）总结、考察

引入了雷达派生开发的过程，与常规开发相比，上游过程与总工时的比率增加。 但是，由于项目的总工时几乎没有变化，开发的重心可能会从下工序转移到上游工序，导致组合/功能测试和质量改进中的故障密度降低。 此外，减少了编码过程中的返工，从而显着提高了编码效率。

在派生开发流程开始时，所用工时超出了预计，是由于创建了不熟悉的文档和审查，因此他们无法实现引入的效果。 然而，随着开发的继续，文档格式和开发流程逐步改进，使生产力和质量提高。因此得出结论：确定适合开发雷达的开发流程是十分重要的。

最后

在尝试引入派生改善流程后，我们发现，一方面，雷达开发在生产率/质量方面的某些方面得到了改进。另一方面，我们也看到以下问题。

①在要求规范的情况下，TM，规格材料的要求需要详细到什么成都？是否进行有效审查？ 

②如何在短时间内有效地进行审查？ 

③如果使用相同的软件重复修改/添加工作，差异材料将增加，差异管理变得严重。