当软件质量目标明确规定了分析指针、编程指南，以及运行时错误的接受标准和阈值，系统透过这些标准会自动进行评估，软件变更时执行，就成为软件开发流程中完整的一部分。如何降低程序代码质量评估的主观性，并改善软件开发周期的整体开发效率，就成为当中要点。
系统在现今车辆的安全性、可靠性及效率扮演着愈来愈重要的角色。因此，工程团队专注于提供先进驾驶辅助系统（advanced driver assistance systems；ADAS）、电池管理系统、稳定控制及其他类似的创新功能。通常，他们也需要透过证明符合ISO 26262/SAE 21434的规定，以确保满足功能安全与网络安全的要求。
全球顶级车辆供货商Ficosa International正在开发使用在各式车辆应用的软件。作为确保产品符合产业标准的其中一部份流程，我们的工程团队在从实现到单元验证、整合及鉴定测试的完整开发周期，均使用产品来衡量并改进程序代码质量。许多使用的流程都是基于一套明确定义的软件质量目标，由诸如所开发的组件的关键性和项目的成熟度等要素组织而成。
软件质量目标明确规定了静态分析指针、MISRA和CERT/CWE等编程指南，以及运行时错误的接受标准和阈值。现在这些标准会自动地进行评估，并且在每一次软件变更时执行，成为软件开发流程中完整的一部分。因此，我们尽可能降低程序代码质量评估的主观性，同时改善软件开发周期的整体开发效率。

进行使用评估
2010年，我们开始进行车辆通讯模块项目。这项项目的其中一部分要求，客户指定使用静态分析来检查是否符合MISRA C。经过对市面上的静态分析产品进行完整评估之后，我们根据产品的表现和成本，选择了Polyspace。同时间，我们也致力于逐渐符合Automotive SPICE能力等级2（level 2），并且开始搭配使用Polyspace Bug Finder和Polyspace Code Prover静态分析来支持软件单元验证活动。
很快地，我们的工程团队开始进入ADAS的其他领域，而我们的客户开始要求符合ASPICE level 3。与此同时，我们还开始几项需要符合ISO 26262以被视为满足功能安全要求的项目。不久之后，还有一些客户开始要求符合CERT C和通用缺陷列表（Common Weakness Enumeration；CWE）的检查，以确保满足安全的程序代码编写标准，在这个案例是需要寻求符合ISO 21434。
使用Polyspace软件进行静态分析帮助我们支持这其中每一项行动。然而，从企业组织的角度来看，缺少了开发及验证活动的全面性计划，计划里面应该要清楚定义会在何时，以及采用哪些技术、衡量方式及阈值来确保软件质量。
正式架构尚未就位的其中一个缺点，是研发团队会倾向等到项目更后面的阶段才执行静态分析，而不是从项目一开始就系统化地执行。可以料想，这些在开发后期进行静态分析结果出现了许多违规行为，其中包含许多违反MISRA C的违规行为。由于这些问题是在项目后期才被发现，很难透过问题解决或论证来弥补。
为了处理这类挑战，我们透彻分析Ficosa International该如何优化的符合软件质量目标，以及我们的客户跨越多种领域，在可靠性、功能安全和安全防护等方面的目标。这项分析的终端产品是一份软件质量目标文件，这份文件现在被我们的团队视为确保交付的软件系统质量的基础。

定义软件质量目标
在Ficosa International的软件质量目标文件中，我们定义了在验证所开发的软件时所有生效的指针和规则，包含以MISRA C、CERT C及CWE为基础的指针和规则，还有诸如循环复杂度及批注密度等软件指针。
下一步，我们依据待验证的程序代码的源头、开发中的组件类型以及其成熟度来定义指针和规则的采用标准。举例来说，为第三方程式码、既有程序代码（legacy code）、自动产生的程序代码，以及人工编写的程序代码定义了不同的目标（图1）。

 
图1 : 依据软件组件类型和项目成熟度而定义的Ficosa International软件质量目标

对于第三方程式码，仅执行强制性的MISRA C规则，并且假定这类程序代码附有其他相配的质量证明。对于既有程序代码、自动产生的程序代码和人工编写的程序代码，我们采用愈来愈严格的规则。涉及功能安全或安全防护的组件还会进行额外的检查，以符合ISO 26262的汽车安全完整性等级（Automotive Safety Integrity Level；ASIL）要求和ISO/SAE 21434的网络安全保证等级（cybersecurity assurance level；CAL）要求。
此外，随着组件从早期开发（A sample）进展到中期、倒数第二个阶段、最终交付（B、C、D samples），我们还会为项目定义更为严格的目标。最终，会有一个整合程序代码的独立、经过缩减的规则与指针子集—亦即一组组件之中的每一个组件均通过各自的软件质量目标评估，而且现在被整合在一起，成为更大系统的一部分。这对于简化复杂软件的静态分析非常有用。

将静态分析整合至开发工作流程
当有了明确定义软件质量目标的文件，我们便开始使用Polysapce静态分析产品，将这些文件整合至开发及测试流程（图2）。

 
图2 : 对于程序代码实现和验证的流程，可看见静态分析和后续修正的整合。

这套流程其中的一项关键步骤，在于纳入针对开发人员向我们的版本控制系统Git发送收取要求时的规定。对于需要核准的收取要求，它除了要有单元测试结果之外，还必须成功通过Polyspace Bug Finder和Polyspace Code Prover的特定静态分析检查。单是这项改变就为我们整体工作流程带来重大改善，因为它建立了一个闸门机制，确保开发人员只有在他们的程序代码完整通过合适的软件质量目标，并且解决或证明在静态分析找到的任何问题时，才能够成功完成收取要求。
在软件整合及测试期间，Polyspace产品被使用来执行以整合程序代码的软件质量目标为基础的静态分析。在此阶段， MISRA C的相符及程序代码指针的检查仅限于系统层级规则和整合软件指针。有个重点是整合层级的问题，像是共享内存的协作存取、无作用程序代码、重大运行时错误等。
随着采用Jenkins进行持续整合持续部署（continuous integration and continuous delivery，CI/CD）的情况愈来愈多，Polyspace产品支持频繁的静态分析及持续的反馈，确保开发人员及整合人员能够维持源代码与设定的质量目标的一致性。除此之外，透过Polyspace Access网络接口，我们所有的团队都可以存取一个中央数据库，查看结果并且监控交付质量目标等级的进展。
在开发功能安全产品的时候，有另一个重要的考虑点是要确保软件工具不会造成、或者没有发现在软件量产阶段的错误。ISO 26262明确要求软件工具的认可流程，依据软件的关键性进行分类，并且执行必要的活动来审核。针对Polyspace产品，MathWorks提供支持Bug Finder和Code Prover在项目范畴的认证套件。

关键优势
透过Polyspace产品来运用良好定义的软件质量目标，为Ficosa International须遵循ISO 26262与ISO/SAE 21434标准的开发和交付，带来几项重要的优势。
优势之一是稳定地提升开发人员之间的开发技能。进一步来说，他们从Polyspace产品接收到的快速响应，帮助他们了解其程序代码质量哪里需要修改及如何修改，而且因此可以帮助他们成为技术更佳、更有生产力的开发人员。事实上，透过我们建置的流程，他们必须要了解并解决通过静态分析侦测到的问题—没有其他的选项。
我们还发现另一个重要的好处是得以简化ASPICE和ISO 26262外部质量评估，或者其他客户要求须要遵循的目标。今天，我们做的每一件事都更易于论证，因为我们有清楚的软件质量目标，并且附有报告呈现，举例来说，MISRA与CERT变异数量远比以往更少，还有证据显示我们的程序代码通过了目标质量标准。
也许更为重要的是，Polyspace产品帮助我们达成质量目标，同时间增加效率，或者至少维持了同样的效率。通常，在管理团队或类似的团体调整组织的开发工作流程来制定执行的早期验证步骤型态时，开发人员会将所需要完成的额外步骤视为另外的工作。有了Polyspace产品，我们便能够向团队证明，这些为了每一次的收取要求而执行的静态分析所产生的额外步骤，实际上让效率提升了。他们可以更有效率、更具信心地交付高质量的程序代码，因为所有透过静态分析找到的错误都在较早的阶段就已经被消灭，而不会留存到最终阶段。
（本文由钛思科技提供；作者David Tuset、Roger Marsal、Yolanda Guasch任职于Ficosa International公司）