Avant de payer qui que ce soit pour une analyse d'écarts — nous y compris — consacrez deux heures à cette liste. Elle est organisée par domaine du cycle de vie, ne pose que des questions auxquelles vos propres preuves permettent de répondre, et vous dira où une véritable analyse d'écarts devrait se concentrer — ou si vous en avez besoin tout court.
Répondez honnêtement et par écrit. La valeur n'est pas dans le score ; elle est dans les items précis auxquels vous n'avez pas su répondre.
1. Planification
| nº | Demandez-vous | Signal d'alarme si... |
| 1.1 | Les cinq plans (PSAC, SDP, SVP, SCMP, SQAP) existent-ils, approuvés, pour ce programme — et non des gabarits du précédent ? | Les plans sont « en cours de mise à jour » pendant que le développement avance |
| 1.2 | Le PSAC énonce-t-il le niveau logiciel et sa provenance ? | Personne ne peut montrer l'évaluation de sécurité derrière le niveau |
| 1.3 | Les normes d'exigences, de conception et de codage existent-elles et correspondent-elles à ce que l'équipe fait réellement ? | La norme de codage cite une version du langage que vous n'utilisez plus |
| 1.4 | Les critères de transition sont-ils définis — ce qui doit être vrai avant d'entamer la conception, le codage, les essais ? | Le travail commence quand les gens se libèrent, non quand les critères sont remplis |
| 1.5 | Le calendrier des SOI a-t-il été proposé et convenu ? | « Nous contacterons l'autorité quand nous serons prêts » |
2. Exigences
| nº | Demandez-vous | Signal d'alarme si... |
| 2.1 | Des exigences de haut niveau existent-elles pour chaque fonction, chacune identifiée de façon unique ? | Les exigences vivent dans un tableur que personne n'a mis sous référence |
| 2.2 | Savez-vous distinguer exigence et conception — et les exigences de bas niveau existent-elles comme niveau à part entière ? | Une seule liste plate sert aux deux |
| 2.3 | Les exigences dérivées sont-elles identifiées comme telles et retournées au processus de sécurité ? | Le terme suscite des regards vides |
| 2.4 | Chaque exigence est-elle vérifiable telle que rédigée ? | Les exigences disent « doit être rapide », « doit être robuste » |
| 2.5 | Les exigences ont-elles été revues contre une liste de contrôle, avec enregistrements ? | La revue s'est faite « en réunion » |
3. Conception et code
| nº | Demandez-vous | Signal d'alarme si... |
| 3.1 | Des données de conception décrivent-elles l'architecture et le comportement de bas niveau ? | Le code tient lieu de conception |
| 3.2 | Le code se trace-t-il aux exigences de bas niveau, et les normes ont-elles été appliquées ? | L'analyse statique tourne, mais ses constats ne sont pas statués |
| 3.3 | Chaque avertissement du compilateur est-il résolu ou expliqué ? | Les avertissements sont supprimés en bloc |
| 3.4 | Le compilateur, l'éditeur de liens et leurs options sont-ils sous gestion de configuration ? | Les compilations diffèrent d'une machine à l'autre |
4. Vérification
| nº | Demandez-vous | Signal d'alarme si... |
| 4.1 | Chaque cas d'essai se trace-t-il à une exigence ? | Les essais ont été écrits à partir du code |
| 4.2 | Des cas de robustesse existent-ils — entrées invalides, conditions aux limites ? | Seuls des cas en plage normale existent |
| 4.3 | La couverture structurelle est-elle mesurée au bon critère pour votre niveau, lacunes analysées ? | La couverture est un chiffre sans analyse derrière |
| 4.4 | Les revues et analyses ont-elles été faites là où les objectifs l'exigent, et pas seulement des essais ? | « Vérification » signifie « essais » dans chaque phrase |
| 4.5 | Les résultats de vérification sont-ils sous GC, rejouables, avec l'indépendance là où elle est exigée ? | Les résultats vivent dans un dossier nommé final_v2_corrige |
5. Gestion de configuration
| nº | Demandez-vous | Signal d'alarme si... |
| 5.1 | Chaque élément du cycle de vie — pas seulement le code — est-il sous gestion de configuration ? | Les versions des exigences n'existent que dans les courriels |
| 5.2 | Des références de configuration existent-elles, et savez-vous en reconstruire chacune ? | Reconstruire la version de l'an dernier est une aventure |
| 5.3 | Existe-t-il un système de rapports de problèmes dont les rapports sont classés et statués ? | Les bogues se corrigent en silence, sans trace |
| 5.4 | Pouvez-vous produire l'index de configuration logicielle (SCI) de ce que vous livreriez aujourd'hui ? | Le SCI est « une tâche pour plus tard » |
6. Assurance qualité et liaison
| nº | Demandez-vous | Signal d'alarme si... |
| 6.1 | L'AQ logicielle a-t-elle audité la conformité réelle aux plans, avec enregistrements ? | L'AQ lit des documents mais n'observe jamais le travail |
| 6.2 | L'AQ a-t-elle l'autorité de refuser une approbation, et l'a-t-elle déjà exercée ? | L'AQ relève du gestionnaire dont elle menace l'échéancier |
| 6.3 | Quelqu'un est-il nommé à la liaison de certification, avec du temps alloué ? | La relation avec l'autorité est « prise en charge par le client » |
| 6.4 | Suivez-vous les rapports de problèmes ouverts en pensant à la décision de livraison ? | La liste ouverte n'est le problème de personne avant le SOI nº 4 |
Lire votre résultat
| Motif | Signification | Prochaine étape sensée |
| Surtout des oui, quelques partiels | Vous êtes prêt pour l'audit ou presque ; les écarts relèvent de la finition | Tirez vos propres fils ; envisagez une revue légère pré-SOI |
| Oui en développement, non en planification/GC | La forme classique équipe-forte-processus-faible | Corrigez d'abord plans et GC ; ils coûtent peu et tout en hérite |
| Partiel partout | Les preuves existent mais ne survivraient pas à l'échantillonnage | Une analyse d'écarts ciblée se paiera d'elle-même ; cadrez-la avec cette liste |
| Non en exigences ou en vérification | L'écart coûteux — reprise de travaux, pas paperasse | Faites-vous aider avant d'écrire plus de code sur des exigences invérifiables |
Foire aux questions
Combien de temps cette auto-évaluation devrait-elle prendre ?
De deux à quatre heures pour quelqu'un qui connaît le programme et répond à partir des preuves plutôt que de mémoire. Si cela prend beaucoup plus longtemps parce que les éléments sont difficiles à trouver, ce constat est en soi le résultat.
Quand avons-nous besoin d'une véritable analyse d'écarts ?
Quand le motif est « partiel partout », quand une revue SOI approche et que les réponses ici sont inconfortables, ou quand vous héritez d'un logiciel — ou en faites l'acquisition — dont vous ne connaissez pas parfaitement l'histoire. Si cette liste revient surtout à oui, une analyse complète dépasse peut-être votre besoin.
S'applique-t-elle à tous les niveaux logiciels ?
Les domaines s'appliquent à tous les niveaux ; la profondeur, non. Au niveau D, plusieurs items de vérification rétrécissent ou disparaissent, et au niveau A les questions d'indépendance mordent plus fort. Servez-vous-en comme d'une boussole, et laissez les tableaux de l'annexe A de votre niveau trancher.
Peut-on l'utiliser pour un logiciel qui vole déjà ?
Oui — elle fonctionne comme bilan de santé d'un logiciel hérité ou patrimonial, où la découverte habituelle est un code solide aux preuves minces. Le tableau de lecture ci-dessus s'applique toujours ; la ligne « reprise de travaux » fait simplement plus mal.
Si vous avez parcouru cette liste et que les réponses vous inquiètent, la conversation suivante est exactement notre métier : une analyse d'écarts indépendante, cadrée là où se trouvent réellement les non — écrivez-nous.
