Waarom standaards-gebaseerde ontwikkelpraktijken ertoe doen - zelfs wanneer niet verplicht

Een toegewijde industrie rond verificatie en validatie - gedreven door standaarden zoals IEC 61508, ISO 26262, IEC 62304, MISRA C en CWE - is ontstaan om ervoor te zorgen dat software betrouwbaar, veilig en van hoge kwaliteit is. Zelfs als uw product niet onder de strenge regulatorische vereisten van deze standaarden valt, kan het adopteren van hun bewezen best-practice-processen bugs dramatisch verminderen, time-to-market verkorten en onderhoudskosten verlagen.

Typen fouten en tools om ze aan te pakken

Software-defecten vallen in twee brede categorieën, elk vereist distincte mitigatietechnieken:

• Coding-fouten - bijv. out-of-bounds array-toegang - kunnen vroeg gedetecteerd worden met static analysis.
• Applicatie-fouten ontstaan wanneer de code niet voldoet aan specificaties; deze worden alleen onthuld door requirements-gedreven testen.

Coding-fouten en code-review

Static analysis is een krachtige eerste verdedigingslijn, vooral wanneer geïntegreerd aan het begin van een project. Het identificeert schendingen van coding-regels die anders moeilijk-te-debuggen bugs later kunnen worden. Complementair aan static analysis, controleert een rigoureuze code-review of de code voldoet aan een gekozen coding-standaard, zoals MISRA C:2012.

In theorie zou een taal ontworpen voor veiligheid - Ada, bijvoorbeeld - veel valkuilen elimineren door sterke typing en expliciete constructies. In de praktijk vertrouwen de meeste embedded-teams op C of C++, die flexibiliteit bieden maar ook ontwikkelaars blootstellen aan subtiele vallen als undefined, unspecified en implementation-defined gedrag. Door de gebruikte taalfeatures te beperken en riskante constructies te verbieden (bijv. goto, malloc, signed en unsigned arithmetic mengen), kan een coding-standaard de lat voor defect-preventie verhogen.

Hier zijn een paar veelvoorkomende valkuilen geïllustreerd in de C/C++-wereld:

1. Implementation-defined shift van een signed integer: vult een right-shift de high-order-bit met nullen of enen?
2. Unspecified volgorde van functie-argument-evaluatie, wat het resultaat van een eenvoudige routine als rollDice() kan wijzigen.
3. Signed en unsigned waarden mengen, wat kan leiden tot subtiele overflows.

Figuur 1: Het gedrag van sommige C en C++ constructies hangt af van de gebruikte compiler. (Bron: LDRA)

Figuur 2: Het gedrag van sommige C en C++ constructies is ongespecificeerd door de talen. (Bron: LDRA)

Het adopteren van een wel-gevestigde coding-standaard zoals MISRA C:2012 helpt deze valkuilen te vermijden. De standaard's regels dekken meer dan 300 specifieke coderingspraktijken, elk ondersteund door uitleg die verwijst naar de taal's undefined en unspecified gedrag. Meeste guidelines zijn "decidable," wat betekent dat een static-analysis-tool schendingen automatisch kan detecteren; een paar zijn "undecidable," waar de tool potentiële issues moet vlaggen en ontwikkelaars beslissen of ze echte problemen zijn.

In april 2016 breidde MISRA zijn scope uit om security-kritische software aan te pakken door 14 nieuwe guidelines toe te voegen. Directive 4.14 richt zich expliciet op undefined behavior, wat een extra beschermingslaag biedt voor security-georiënteerde projecten. Figuur 4 toont hoe MISRA's security-overwegingen lijnen met het bredere veiligheidsframework.

Figuur 4: MISRA en security-overwegingen. (Bron: LDRA)

Applicatie-fouten en requirements-testen

Terwijl coding-standaarden beschermen tegen low-level bugs, ontstaan applicatie-bugs wanneer de software niet voldoet aan het beoogde gedrag. Het detecteren van deze vereist een solide requirements-basis en traceerbare koppeling tussen requirements, ontwerp en code.

Bidirectionele traceerbaarheid zorgt ervoor dat elke requirement geïmplementeerd is en elke implementatie teruggetraceerd kan worden naar een requirement. Figuur 5 en 6 illustreren deze tweerichtings-mapping, wat ontbrekende of redundante functionaliteit vroeg in de lifecycle onthult.

Figuur 5: Bidirectionele traceerbaarheid, met functie geselecteerd. (Bron: LDRA)

Figuur 6: Bidirectionele traceerbaarheid, met requirement geselecteerd. (Bron: LDRA)

Eenmaal traceerbaarheid op zijn plaats is, kunnen testcases afgeleid worden van low-level requirements. Figuur 7 toont een typische low-level-requirement die een enkele functie's gedrag volledig specificeren, en Tabel 1 demonstreert hoe testcases mappen op die requirements.

Figuur 7: Voorbeeld low-level-requirement. (Bron: LDRA)

Tabel 1: Testcases afgeleid van low-level-requirements. (Bron: LDRA)

Het uitvoeren van deze tests met een unit-test-framework op zowel host als target bevestigt dat de implementatie de requirement matcht. Figuur 8 toont een regressie-suite waar alle testcases slagen. Na test-uitvoering verifiëren structurele coverage-metrics dat de gehele codebase geoefend is; eventuele gaps vragen om additionele tests of code-refactoring.

Figuur 8: Unit-tests uitvoeren. (Bron: LDRA)

Conclusie

Software-complexiteit stijgt, en zo ook het risico op defecten. Best-practice-ontwikkeling - gegrondvest in een moderne coding-standaard als MISRA C:2012, rigorese metrics, traceerbare requirements en requirements-gebaseerde testen - biedt een bewezen pad naar hoog-kwaliteit, betrouwbare en robuuste code. Of uw project nu gebonden is aan formele veiligheidsreguleringen of niet, de discipline en transparantie die deze praktijken meebrengen, zijn een netto-voordeel voor elk ontwikkelteam.