Demandez ce que coûte le DO-178C et vous entendrez des chiffres couvrant un ordre de grandeur, tous livrés avec assurance. La réponse honnête est que le multiplicateur dépend moins de la norme que de décisions qui vous appartiennent — et que les chiffres du folklore proviennent de programmes qui ont mal pris ces décisions.

Cet article ne vous donnera pas de chiffre. Il vous donnera les cinq facteurs dont le chiffre dépend réellement, la forme de la dépense, et les questions qui rendent un devis significatif.

Pourquoi les chiffres du folklore ne servent à rien

Les multiplicateurs souvent cités — « la certification double le coût », « le niveau A coûte cinq fois le commercial » — partagent un défaut : ils confondent dans une même moyenne les programmes qui ont ajouté l'assurance après coup sur du code terminé et ceux qui l'ont intégrée dès le départ. Ce ne sont pas les mêmes activités. Ajouter après coup, c'est reconstruire des exigences à partir du code, justifier rétroactivement des décisions de conception que personne n'a documentées, et découvrir au moment de la couverture que l'architecture résiste aux essais. Intégrer dès le départ, c'est consigner ce que vous alliez consigner de toute façon, sous une forme qu'un auditeur peut échantillonner.

Le premier cas est réellement coûteux. Le second relève surtout de la discipline. En faire la moyenne produit un chiffre qui ne décrit personne.

Les cinq facteurs

Ce qui influence le coût du DO-178C, du plus fort au plus faible : le niveau d'assurance (DAL), la qualité et la stabilité des exigences, le crédit de réutilisation de logiciel déjà développé, la qualification des outils, et l'expérience de l'équipe Niveau d'assurance (DAL) Qualité des exigences Réutilisation (PDS) Qualification des outils Expérience de l'équipe Classées de l'influence la plus forte à la plus faible
Ce qui fait réellement bouger le coût, par influence approximative. Notez lesquels vous contrôlez.
Facteur Effet sur le coût Qui le contrôle
Niveau d'assurance Fixe le nombre d'objectifs, la dotation en indépendance et le critère de couverture — la frontière C-D est la plus grande marche L'évaluation de sécurité (et l'architecture)
Qualité et stabilité des exigences Chaque changement d'exigence tard en vérification rejoue une tranche du programme ; une exigence invérifiable coûte deux fois Vous
Réutilisation et logiciel préexistant Un crédit de réutilisation véritable retire des pans entiers d'objectifs ; la fausse réutilisation (« ça a déjà volé », sans preuves) ne retire rien En partie vous, en partie l'histoire
Qualification des outils Un outil qualifié élimine du travail manuel de vérification, mais la qualification a son prix — une décision d'investissement par outil Vous
Expérience de l'équipe Le premier programme DO-178C d'une équipe porte une taxe d'apprentissage qu'aucun processus n'élimine ; le deuxième coûte spectaculairement moins En partie vous
Les cinq facteurs, et l'effet de chacun sur un budget.

Où va réellement l'argent

Les équipes qui découvrent la norme présument que le coût est de la paperasse. La forme réelle, programme après programme : la vérification domine — elle approche typiquement la moitié de l'effort d'ingénierie aux niveaux supérieurs, une fois comptés honnêtement le développement des essais, leur exécution, l'analyse de couverture et la dotation en indépendance. La planification et les normes sont une erreur d'arrondi en comparaison — ce qui ne manque pas d'ironie, puisqu'elles déterminent le coût de tout le reste.

Le cycle de vie logiciel du DO-178C : la planification, les étapes de développement, et les processus transverses qui les accompagnent Planification Exigences Conception Code Intégration Les processus transverses accompagnent le développement : vérification, gestion de configuration, assurance qualité, liaison de certification
Les processus intégraux durent tout le programme — c'est pourquoi l'effort se concentre dans la vérification, et non dans la documentation.

L'échéancier : la version honnête

La question de l'échéancier a la même structure que celle du coût, avec un ajout : la certification comporte des jalons qui ne se compriment pas. On peut paralléliser le développement, mais les revues SOI se tiennent dans l'ordre, la clôture des constats prend du temps de calendrier, et la disponibilité de l'autorité ne se planifie pas à votre convenance. Les programmes qui ratent leurs dates sont rarement lents en ingénierie — ils sont surpris par un temps de clôture qu'ils n'avaient jamais budgété.

Règles empiriques qui survivent au contact du réel : la vérification prend plus de temps que le développement la première fois, quoi qu'en dise le plan ; la clôture d'un constat SOI se mesure en semaines, non en jours ; et les cinq derniers pour cent de couverture structurelle prennent aussi longtemps que les quatre-vingt-quinze premiers si l'architecture n'a pas été conçue pour la testabilité.

Rendre un devis significatif

  1. Fixez d'abord le niveau. Un devis antérieur à l'évaluation de sécurité est une supposition déguisée en chiffrier.
  2. Énoncez précisément la prétention de réutilisation. « Fondé sur notre produit précédent » peut signifier n'importe quoi, du véritable crédit de réutilisation au développement neuf à attaches sentimentales.
  3. Décidez la qualification outil par outil, tôt. Chaque outil qualifié est un dossier d'investissement : le coût de qualification contre le travail manuel qu'il retire, multiplié par le nombre de programmes qui le réutiliseront.
  4. Chiffrez le deuxième programme en achetant le premier. Une grande part du coût d'un premier programme construit une capacité — plans, normes, environnements, personnel formé — dont le suivant hérite gratuitement. Un devis de premier programme lu comme coût récurrent surestime tous les suivants.
  5. Budgétez la clôture, pas seulement les revues. La rencontre SOI coûte des jours ; les constats coûtent des semaines.

Ce que cela signifie pour un fournisseur canadien qui se lance

Pour une entreprise qui bâtit une capacité DO-178C pour la première fois — cas de plus en plus fréquent à mesure que les programmes canadiens s'approvisionnent au pays — le cadrage compte plus que l'estimation : le premier programme est en partie un investissement de capacité, et le chiffrer comme pur coût de projet le fait paraître pire qu'il n'est. Les disciplines ci-dessus, ajoutées aux questions de délégation et de validation traitées ailleurs dans cette série, sont exactement là où un conseil précoce se rembourse — non que la norme soit mystérieuse, mais parce que les erreurs coûteuses surviennent toutes avant le moment où la plupart des équipes croient que le travail de certification a commencé.

Foire aux questions

Alors, que coûte réellement le DO-178C ?

Quiconque répond sans demander votre niveau, la maturité de vos exigences, votre position de réutilisation, votre outillage et l'expérience de votre équipe cite du folklore. Ces cinq questions répondues, une estimation défendable devient possible — et l'écart honnête entre de bonnes et de mauvaises réponses à ces questions couvre plusieurs fois le coût de base.

Le niveau A coûte-t-il deux fois le niveau C ?

Il n'existe pas de multiplicateur stable. Le passage de C à A ajoute relativement peu d'objectifs mais accroît fortement l'indépendance et ajoute la couverture MC/DC et la traçabilité source-objet — le coût se loge dans la dotation et l'infrastructure de vérification. Pour la plupart des programmes, c'est le passage de D à C qui constitue le choc budgétaire, car c'est là qu'arrivent la couverture structurelle et l'essentiel du nombre d'objectifs.

Le DO-178C double-t-il l'échéancier ?

Sur un programme bien planifié, l'assurance ajoute nettement moins que ce que craignent les équipes — une grande part du travail est de l'ingénierie qu'elles devraient faire de toute façon, sous forme auditable. Sur un programme mal planifié, le doublement est optimiste. La variable n'est pas la norme ; c'est le moment où le travail d'assurance commence par rapport au code.

Peut-on réduire le coût en qualifiant des outils ?

Parfois substantiellement — un outil de couverture ou d'analyse qualifié retire un effort manuel récurrent. Mais la qualification a un coût réel : c'est une décision d'investissement par outil, la plus solide lorsqu'elle s'amortit sur plusieurs programmes. Un seul petit programme justifie rarement de qualifier un outil à partir de zéro.

Est-il moins cher de certifier un logiciel existant que de le réécrire ?

Pas de façon fiable. Ajouter des preuves après coup à un code qui n'a pas été bâti pour cela — reconstruire les exigences, rétroconcevoir la logique de conception, courir après la couverture sur une architecture intestable — coûte régulièrement plus cher qu'une redéveloppement discipliné. Tout dépend des preuves qui existent déjà, ce qu'établit précisément une analyse d'écarts.

Vous cadrez un premier programme, ou vous voulez éprouver une estimation qu'on vous a remise ? Cette conversation vaut la peine d'être tenue avant que le budget ne soit engagé — écrivez-nous.