当软体品质目标明确规定了分析指标、编程指南，以及执行阶段错误的接受标准和??值，车用软体系统透过这些标准会自动进行评估，软体变更时执行，就成为软体开发流程中完整的一部分。如何降低程式码品质评估的主观性，并改善软体开发周期的整体开发效率，就成为当中要点。

车用软体系统在现今车辆的安全性、可靠性及效率扮演着愈来愈重要的角色。因此，工程团队专注於提供先进驾驶辅助系统（advanced driver assistance systems；ADAS）、电池管理系统、稳定控制及其他类似的创新功能。通常，他们也需要透过证明符合ISO 26262/SAE 21434的规定，以确保满足功能安全与网路安全的要求。

全球顶级车辆供应商Ficosa International正在开发使用在各式车辆应用的软体。作为确保产品符合产业标准的其中一部份流程，我们的工程团队在从实现到单元验证、整合及监定测试的完整开发周期，均使用Polyspace静态程式码分析产品来衡量并改进程式码品质。许多使用的流程都是基於一套明确定义的软体品质目标，由诸如所开发的元件的关键性和专案的成熟度等要素组织而成。

软体品质目标明确规定了Polyspace静态分析指标、MISRA和CERT/CWE等编程指南，以及执行阶段错误的接受标准和??值。现在这些标准会自动地进行评估，并且在每一次软体变更时执行，成为软体开发流程中完整的一部分。因此，我们尽可能降低程式码品质评估的主观性，同时改善软体开发周期的整体开发效率。

进行Polyspace使用评估

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公司）