01 工具鉴定

现代软件工程中，工具已经出现在软件研制过程中的各个环节中。在常见的软件研制环节中，使用工具包括软件需求工具、软件设计工具、软件架构工具和软件测试工具等。这些工具的使用可以提高软件的开发效率，并且在正确使用相关工具的条件下还有望能提高软件的质量。当然，如果工具中存在错误或未能正确的使用工具，也将会带来负面的影响。并且由于工具的功能日益强大，人类有时已经无法对工具的输出进行直接的判断。

正如前文不断提及的那样，民用飞机时刻以安全性为最高要求。为了保证达到预期的安全水平往往不惜牺牲效率和其它性能。就民机机载软件研制过程中使用的工具来说，风险也是显而易见的，主要原因在于：

● 相比纯手工开发，工具的输出中隐藏的错误往往更加分散难以被发现；

● 工具生成的软件中含有的缺陷往往难以通过手工的方式排查并加以修正；

● 相比人工活动，工具产生的错误不再是偶然的。当同样的工具被用于多个项目中时，同样的错误将被成批的复制。

为了规避工具的应用给民机机载软件带来的风险，适航审定过程中通常采取将机载软件的要求延伸到相关工具中的方法，这一方法也可以称之为“鉴定”。工具鉴定正是DO-178C第十二章第二节所描述的内容。为了区别工具鉴定与机载软件的适航要求，RTCA组织在DO-178C标准推出之时也同步颁布了DO-330文件。将工具鉴定要求和方法分开处理的出发点是将基于软件过程管理技术和方法的工具鉴定这一思路运用于各类可能需要用于证明工具自身功能或者性能的领域。

02 DO-178C的工具鉴定要求

2.1 何时需要进行工具鉴定？

“Qualification of a tool is needed when processes of this document are eliminated, reduced or automated by the use of a software tool without its output being verified as specified in section 6.” （RTCA DO-178C 12.2）

“当使用软件省略、减少或自动化了本文所要求的过程，并且没有采用本文件第六章的要求对输出进行验证，则工具需要鉴定。”（RTCA DO-178C第12.2节）

上文描述了工具鉴定的两个基本条件，分别是“省略、减少或自动化了本文所要求的过程”以及“没有采用本文第六章的要求对输出进行验证。”

我们先来看看什么是“省略、减少和自动化”。从字面上来看，“省略”自然就是因为软件工具的使用而可以省去不再执行的软件生命周期过程，或过程中的某些步骤；“减少”则是DO-178C要求的过程依然执行，但是减少了过程中所包含部分活动；“自动化”顾名思义是原先标准要求的过程原先由人工执行，现在被工具自动化地实现了。由此可以看出，“省略、减少、自动化”是工具影响到软件过程或活动做多少和由谁做的置信度问题。下面我们通过一个例子来仔细分析上面三者间的区别。

例如，我们假设某软件研制过程中工具A能直接从低级需求和系统架构设计文件转换并且生成全部的源代码文件，在研制过程中无需进行人工编码。我们看到，在这一过程中源代码是被工具编写出来的，所以实质上DO-178C所描述的软件编码过程（Software Coding Process）是被“自动化”了。但是由于这一工具的出色性能，研制单位认为在自动转换过程中不可能引入错误，从而决定不再进行对低级需求和源代码一致性的验证，则DO-178B第六章的验证工作在对源代码和目标代码一致性验证这点上被“省略”了。我们不妨再假设，研制单位对工具的信心非常足，以至于决定将原先执行一类构型控制的源代码由于工具的使用降为二类。可见，在这一过程中，构型管理过程及其活动依然保留，并且还是由人工进行，但部分过程将被“减少”。总结来说，软件工具鉴定的条件可通过下图表示：

图1 工具鉴定的条件和分类

从DO-178C的要求中我们也不难看出，如果软件工具的使用没有省略、减少或自动化DO-178C标准所要求的过程，则不需要对工具进行鉴定。这类工具常见的例子如构型管理（也称配置管理）工具。构型管理工具协助研制团队实现DO-178C第七章所要求的目标和活动，但如果它们仅仅对软件研制过程起到辅助作用而没有起到上文中所描述的“省略、减少或自动化”某一过程的效果，则这种工具不需要鉴定，可以在机载软件项目中直接使用。当然，所有使用的工具都应该在相应的软件研制环境计划中描述，同时也需要将这一计划放入构型管理的范围内。

另外，还需要重点关注DO-178C关于工具鉴定条件的第二条。如果存在工具，虽然满足上面所提的条件，即“省略、减少或自动化”了DO-178C所要求的某项活动。但如果研制单位能够通过对工具的输出进行全面的验证，且验证活动按照DO-178C第六章的要求进行，满足第六章的目标、活动和数据要求。则这个工具也可以不进行鉴定。

2.2 如何进行工具鉴定？

“The purpose of the tool qualification process is to ensure that the tool provides confidence at least equivalent to that of the process(es) eliminated, reduced, or automated.”

“所谓工具鉴定就是为了确定工具能够提供与其省略、减少或自动化了的过程具备同样的适航审定置信度。”

（1）工具鉴定准则

在DO-178C中，工具被进一步根据以下三个准则分成三个类别：

准则1――“工具的输出是机载软件的一部分并且可能引入错误。”我们可以看出，这一定义与B版本中的开发工具是完全对应的。换句话说，C版中的1类工具就是B版中所谓的“开发工具”。

准则2――“将自动验证某些过程，并可能漏检错误；同时，这些输出被用来证明对以下过程的省略和减少是合理的：a. 并没有被工具自动化的验证过程；b. 可能对机载软件产生影响的开发过程。”

准则3――“在预期的使用范围内，可能漏检错误。

“事实上，准则2和准则3都是对B版本中验证工具的进一步细分。

准则1的工具比较好分辨，就是开发过程中需求、设计、编码或者集成过程中用到的产生软件本体的数据的工具。准则3的工具则是用于验证需求、设计、编码或者可执行目标码的工具，但是其作用较为单一，不会产生“副作用”。准则2的工具首先是验证工具，例如检查数组索引越界的工具，如果因为该工具的使用，使得代码中预防数组索引越界的代码可以不用添加，那么该验证工具不但影响了验证过程，而且影响了开发过程，是一种超级验证工具，称之为准则2的工具。准则2的工具的另外一个例子是测试用例的生成工具，其首先作用是生成测试用例，假如此时测试用例还无需人工评审或者部分减免了人工评审其与需求的追踪性，那么这个工具同时影响了DO-178C A-6表和A-7表中的目标，产生跨表的符合性表达，也是一种准则2的工具。

（2）工具鉴定等级（Tool Qualification Level）

上世纪90年代，工具的规模和功能都与今天无法同日而语。近年来，软件工具的功能复杂度甚至超过机载软件产品本身，而在老版标准中对工具鉴定要求的描述过于简单，对于验证工具的要求甚至只有黑盒测试的要求。这与DO-178C标准中对整个机载软件开展全面系统的研制保证管理的要求差距较大。因此，DO-178C标准在考虑上面提到的工具分类准则的基础上，结合工具工作对象（软件）的等级，细化了工具鉴定等级的要求。如下表：

表1 工具鉴定等级的要求

在上述对工具分级的

基础上，DO-178C标准要求工具鉴定的过程依据DO-330标准的相应要求进行。

03 工具操作要求

我们不难发现，不论是开发工具还是验证工具，在工具鉴定中都涉及工具操作需求。常见的误解通常认为，工具操作需求是一份类似于使用说明书的文件。我们也曾发现没有取证经验的研制单位因为无法提交令人信服的软件操作需求而造成工具无法通过鉴定的情况。事实上，工具的操作需求作为工具鉴定活动中必须准备的生命周期数据，应该按照软件生命周期数据中的软件高级或低级需求的标准来编制。并且严格的执行适用的构型管理和更改控制。工具的操作需求起到机载软件验证过程中系统需求的作用，而工具的鉴定活动因此更加类似与我们经常进行的系统审查。我们除了对工具的操作需求其精确性和正确性进行评审之外，还需考虑工具在预期运行环境下的功能测试、鲁棒性测试以及需求和结构覆盖率分析等，而工具软件的高级需求则被作为符合工具操作需求的软件高级需求来对待。