DO-178C en une minute
DO-178C (ED-12C en Europe) ne décrit pas une méthode de développement. Elle fixe des objectifs à atteindre pour qu'un logiciel embarqué soit accepté par l'autorité, les activités qui permettent de les atteindre et les données qui en apportent la preuve. Le nombre d'objectifs applicables et l'exigence d'indépendance dépendent du niveau logiciel, fixé par l'évaluation de sécurité du système.
| Niveau | Condition de panne la plus grave à laquelle le logiciel peut contribuer | Couverture structurelle attendue |
|---|---|---|
| A | catastrophique | MC/DC, décisions, instructions |
| B | dangereuse | décisions, instructions |
| C | majeure | instructions |
| D | mineure | aucune |
| E | sans effet | DO-178C ne s'applique pas au-delà de l'identification du niveau |
Les objectifs sont regroupés dans les dix tableaux de l'Annexe A (A-1 à A-10). Pour chaque objectif et chaque niveau, ils disent s'il s'applique, s'il doit être atteint avec indépendance, et la catégorie de contrôle (CC1 ou CC2) des données produites. Ce sont ces tableaux qu'il faut garder ouverts à côté de ses plans.
Les documents, regroupés par étape
Les plans : ce que l'équipe va faire
| Document | Rôle | Section DO-178C |
|---|---|---|
| PSAC · Plan for Software Aspects of Certification | Le contrat avec l'autorité : quel logiciel, quel niveau, quels processus, quelles données, quels points particuliers | §11.1 |
| SDP · Software Development Plan | Processus d'exigences, de conception, de codage et d'intégration, environnement, critères de transition | §11.2 |
| SVP · Software Verification Plan | Revues, analyses, tests, couverture, indépendance, environnement de vérification, régression | §11.3 |
| SCMP · Software Configuration Management Plan | Identification, lignes de base, rapports de problème, archivage, reconstruction | §11.4 |
| SQAP · Software Quality Assurance Plan | Audits, autorité de l'assurance qualité, revue de conformité | §11.5 |
Les standards : des règles numérotées et vérifiables
| Document | Rôle | Section |
|---|---|---|
| Standard d'exigences | Comment écrire une exigence de haut niveau vérifiable | §11.6 |
| Standard de conception | Règles d'architecture et d'exigences de bas niveau | §11.7 |
| Standard de codage | Sous-ensemble du langage, règles de complexité, interdits | §11.8 |
Un bon standard permet à un relecteur d'écrire « écart à EX-04 » plutôt que « exigence imprécise ».
Les données de développement et de vérification
| Document | Rôle | Section |
|---|---|---|
| SRD · Software Requirements Data | Exigences de haut niveau, y compris les exigences dérivées | §11.9 |
| SDD · Design Description | Architecture et exigences de bas niveau | §11.10 |
| Code source et code objet | Avec leur identification en configuration | §11.11, §11.12 |
| SVCP · Verification Cases and Procedures | Cas et procédures de test, de revue et d'analyse | §11.13 |
| SVR · Verification Results | Résultats, couverture, analyses d'écarts | §11.14 |
| Rapports de problème | Formulaire, circuit, analyse d'impact sur la sécurité | §11.17 |
| Enregistrements d'assurance qualité | Audits, revue de conformité | §11.19 |
Si les exigences et les tests vivent dans un outil (Jira, Polarion, DOORS…), ces documents deviennent l'export daté de l'outil, avec la référence de la ligne de base.
La clôture
| Document | Rôle | Section |
|---|---|---|
| SCI · Software Configuration Index | Tout ce qu'il faut pour reconstruire, recharger et revérifier le logiciel | §11.16 |
| SECI · Life Cycle Environment Configuration Index | L'environnement : compilateurs, options, outils, machines hôtes | §11.15 |
| SAS · Software Accomplishment Summary | La réponse point par point au PSAC : ce qui a été fait, les écarts, les rapports ouverts | §11.20 |
Si des outils servent à éliminer, réduire ou automatiser une activité sans que leur sortie soit vérifiée par ailleurs, il faut aussi les qualifier (§12.2). La qualification suit DO-330, qui a ses propres plans et données.
L'ordre d'écriture qui évite les reprises
- Confirmer le niveau avec l'équipe système. Il vient de l'évaluation de sécurité, pas d'un choix du logiciel.
- Écrire le PSAC, au moins dans les grandes lignes. Il fixe ce que les autres plans détailleront.
- Inventorier les outils et décider de leur qualification. C'est souvent là qu'un projet découvre un coût caché.
- Écrire SDP, SVP, SCMP, SQAP et les trois standards.
- Revoir les plans en interne, puis soumettre le PSAC à l'autorité.
- Développer en tenant la matrice de traçabilité à jour au fil de l'eau : exigence système, exigence de haut niveau, de bas niveau, code, test.
- Vérifier : chaque test se rattache à une exigence ; la couverture structurelle se mesure sur les tests fondés sur les exigences, pas sur des tests écrits pour la couverture.
- Clôturer : SCI, SECI, revue de conformité par l'assurance qualité, SAS.
Les revues avec l'autorité (SOI)
En pratique, l'autorité ou l'organisme qui agit pour elle intervient à quatre moments, les « stages of involvement ». Ils ne sont pas définis par DO-178C elle-même mais par les documents de l'autorité (FAA Order 8110.49A, et côté EASA l'AMC 20-115 en vigueur).
| Revue | Ce qu'on vous demandera |
|---|---|
| SOI 1 · planification | Plans et standards cohérents, approuvés, en configuration ; points particuliers justifiés |
| SOI 2 · développement | Un échantillon d'exigences, de conception et de code, revu, tracé, en configuration |
| SOI 3 · vérification | Un échantillon de cas, procédures, résultats, couverture, rapports de problème |
| SOI 4 · finale | SCI, SECI, SAS, revue de conformité |
La meilleure répétition : choisissez vous-même une exigence système et suivez-la jusqu'au test et à son résultat. C'est exactement ce que fera l'autorité.
Les dix erreurs qui reviennent le plus
- Plans écrits pour l'autorité, pas pour l'équipe, puis non suivis.
- PSAC soumis trop tard, après le début du développement.
- Indépendance annoncée mais non tenue (revue clôturée par l'auteur).
- Exigences de haut niveau qui décrivent la conception.
- Exigences invérifiables : « rapidement », « suffisant ».
- Exigences dérivées non transmises au processus système.
- Traçabilité reconstituée à la fin du projet.
- Tests écrits à partir du code pour atteindre la couverture.
- Outils de vérification utilisés pour supprimer une activité sans qualification.
- Assurance qualité rattachée au chef de projet, sans pouvoir de blocage.
Ce qui change vraiment selon le niveau
Un bon plan de niveau D ressemble à un bon plan de niveau A, avec moins d'objectifs et moins d'indépendance. Les différences qui pèsent le plus :
| Point | A | B | C | D |
|---|---|---|---|---|
| Couverture structurelle | MC/DC, décisions, instructions | décisions, instructions | instructions | aucune |
| Analyse du couplage données et contrôle | oui | oui | oui | non |
| Code objet non traçable au source | à analyser | non | non | non |
| Indépendance de la vérification | forte | forte | selon l'Annexe A | selon l'Annexe A |
Partir d'un dossier structuré
Le kit DO-178C en français fournit ces 17 documents en gabarits Word, déclinés pour les niveaux A à D, avec des consignes de rédaction, un exemple fictif complet, les checklists de revue en Excel et une matrice de traçabilité préréglée. Il renvoie aux sections de la norme sans en reproduire le texte, et ne remplace ni l'autorité ni l'expérience. La checklist de revue des plans (niveau C) est gratuite sur la même page. Pour la traçabilité seule, la matrice de traçabilité des exigences existe aussi en édition gratuite.
Sources
- RTCA DO-178C / EUROCAE ED-12C, Software Considerations in Airborne Systems and Equipment Certification, 2011 (sections citées par leur numéro, texte non reproduit)
- RTCA DO-330 / EUROCAE ED-215, Software Tool Qualification Considerations
- FAA Order 8110.49A, Software Approval Guidelines
- EASA AMC 20-115D, Airborne software development assurance using EUROCAE ED-12 and RTCA DO-178