在先行开发阶段，因为开发新产品而需要进行组件开发和性能评估，因此要增加或修正很多功能，需要通过试错来进行规格的更改。在增加或修正工作等需要在短时间内完成的情况下，对于现有的业务标准流程存在“编写文件需要耗费许多时间”，“修正和新增带来的流带来程未被定义”，“难以明白修正与新增的规格该对应到源码的何处”等问题。为了解决这些问题，参考了专门用于派生开发的流程XDDP（eXtreme Derivative Development Process），用于在各项目中定义派生开发流程。其结果是在生产效率和品质方面发现了改善。

本连载的上篇将为大家介绍改善QCD的方法及其方法/手段，下篇将以“铅电池状态检测传感器”和“车载距离感应雷达”两个案例来阐述软件开发中如何适用派生开发流程。

改善QCD的方法

1.软件开发现状

尤其是在先行开发中的软件开发，因为开发新产品而需要进行组件开发和性能评估，因此要增加或修正很多功能，需要通过试错来进行规格的更改。同时因为要向客户提供试制品并进行评估和试验，因此必须开发和提供许多与之对应的软件。这些软件因为还需要对功能进行修正或增加，因此很多情况下是小团队进行短期开发。时间上的制约使得现在的业务标准流程经常被省略，在开发流程图中的文档编写工作也被省略。还有一些案例是发现问题较迟，导致从下游工序又返工到上游工序的情况发生。

2.软件开发中的问题

修正及新增功能需要短时间内完成，我们认为现有的业务标准流程存在如下问题。

3.解决手段

为了解决这些功能修正与新增案例中软件开发的问题，参考专门为派生开发规定的流程XDDP，运用于定义各项目中的派生开发流程。引入派生开发流程的优点如下。

（1）流程能轻松对应开发现场的频繁要求。

（2） 通过编写变更要求规格书，轻松掌握变更或修正位置的前后状态。

（3） 通过编写TM（Traceability Matrix）来对应修正或新增规格在源码中的位置。

（4） 编写完成的资料在检查时可以发现规格的错误。

（5） 变更或修正位置在文档上留有记载。

下面我们介绍应用于“铅电池状态检测传感器”和“车载距离感应雷达”两个案例中的派生开发应用。

手段/方法

1.派生开发流程

派生开发流程指的是伴随着增加新开发的功能或对应新的要求，需要对软件进行专门修正或新增的开发流程。本流程从大约2007年起在软件行业中流行，从大约2010年起在汽车行业中流行，并有被汽车零部件供应商引入的案例 。派生开发流程推荐编写和运用如下所述的文档 。

（1）变 更 要需求规 格 书（USDM：Universal Specification Describing Manner）

（2） TM

（3） 变更设计书

流程方面，可以根据来自修正、新增的软件成果（源码，设计书等）的状况任意设定，但大原则是编写上述3个文档后修正源码，同样编写完成的各个文档有必要让有关人士审查。遵循这些规则可以提高生产效率，期待软件品质得到提升。以下就本方法的各个文档和审查方法上举例介绍。

2.变更要求规格书

图1所示的USDM是关于系统变更或新增要求，以及对应这些要求的规格的将每个项目分层级记述的方法（格式）。对软件开发方法论的目标指向及结构化手法的亲和性也不错。而且变更要求规格书中明确记载了变更什么（What），而且记载了变更要求的理由（Why）也是一大特征。明确要求的理由，这能够防止对要求内容产生误解，更可以预测要求变化的方向 。实际上编写本文档时，就会知道很难决定各层级的记述详细度。一个应对方法的例子是图1中第一层级设定为“要求”，第二层级设定为“迁移状态等级的规格”，第三层级是“函数等级的规格”，按这一标准尝试记述各个案例。

图1 变更规格要求书

3.Traceability Matrix

TM是连接USDM与现有软件的资源和头文件的资料，与提高软件品质的“保存性（改良功能时的方便程度）”密切相关。而且在修正软件时，本文档可以明确变更了哪里（Where）。只使用汽车固件开发指南书中定义的文档，那么在进行功能变更和BUG修正时，很难找准要修正的代码，而且伴随着修正还可能带来新的BUG。本文档能有效解决这些问题，并与软件品质的提高有直接关系。这次的方法中也记述了对于有画面的的而不仅仅是源码的GUI（Graphical User Interface），成为了对第三方而言更易懂的资料。

4.变更设计书

在变更设计书中如果想变更函数等具体内容时，变更方法以文字方式记述是其特征。记述“谁（Who）”、“何时（When）”、“怎样（How）”变更的，并尽可能详细地记述操作工时以及实际修正所需的工时等。（图3）。以下介绍的事例中，使用本文档基于之前编写的流程图、数据流图（Data Flow Diagram）、状态迁移图、状态迁移表等进行了编码工作。

图3 变更设计书

5.审查

派生开发时有必要对之前的成果和软件进行审查。审查中相关人士作为审查者参与，目的在于事先清除成果中可能存在的BUG。派生开发所需的观念如下所述。

①如何看待客户委托的变更要求？

②如何看待源中的变更位置？

③如何考虑函数等级中的变更方法？

尤其是②很重要，也有的案例在新增或修正规格资料这一功能前，需要把软件的结构和设计意图写入到文档中。

那么，运用结果将是如何呢？请持续关注我们，下篇将会为大家带来精彩案例！