AGILITE ET SURETE DE FONCTIONNEMENT

Voici une annonce citant l'utilisation des démarches agiles pour le développement d'applications critiques.

Pour comprendre pourquoi ce rapprochement est pertinent, lisez les billets suivants: EXTREME PROGRAMMING EMBARQUE et MOINS CHERS ET PLUS SURS.

EXTREME PROGRAMMING CRITIQUE

La pratique de l'Extreme Programming est très peu répandue pour le développement de logiciels critiques. Ces applications sont utilisées dans l'avionique, le médical, le ferroviaire, le nucléaire et l'automobile.

LES ALEAS DU LOGICIEL CRITIQUE

Les logiciels critiques doivent être certifiés par un organisme spécialisé pour garantir la sûreté de fonctionnement.

La certification est obtenue après une série d'audits exigeant la fourniture des preuves des activités menées pour garantir la sûreté de fonctionnement.
Par exemple, l'organisme certifacteur va s'assurer que le logiciel contient exclusivement du code implémentant les besoins opérationnels du produit. L'implémentation de tous les besoins opérationnels et tout le code devront être vérifiés par des tests. Ces tests devront être joués sur la version finale du logiciel. Ainsi, un changement même mineur du code de la version finale implique que l'intégralité des tests devront être rejoués. Ceci peut représenter un coût considérable si les tests sont joués manuellement par un opérateur. Enfin, tous les produits du développement (exigences, documents, traçabilité, architecture, code, tests) devront être revus.

Les projets de développement de logiciels critiques sont clairement marqués par les processus, les outils, la documentation et la recherche de la conformité aux plans. Le développement logiciel agile et l'Extreme programming en particulier sont-ils applicables dans ce secteur?

EXTREME SURETE

Certaines pratiques de l'Extreme Programming se révèlent être une grande aide au développement de logiciels critiques.
La construction incrémentale pilotée par les besoins opérationnels (les user stories) et les tests d'acceptation assure que le code n'est écrit que pour faire passer les tests d'acceptation d'un besoin opérationnel. Ainsi, le logiciel contient exclusivement du code implémentant des besoins opérationnels.
Les tests d'acceptation systématiques assurent que la prise en compte de tous les besoins opérationnels sont vérifiés par test.
Les tests dévéloppeur systématiques assurent que tout le code est vérifié par test.
La pratique du Test First Programming assure que les tests sont indépendants du code qu'ils vérifient puisqu'ils sont écrits avant même le code.
Les tests d'acceptation et développeur sont automatisés et vérifient leurs résultats. L'intégralité de ces tests est automatiquement rejouée par l'outil d'Intégration Continue dès que le code est modifié. Ainsi, la dernière version du logiciel est toujours intégralement et rigoureusement testée de manière reproductible à faible coût.
Le Pair Programming assure que les produits sont revus en continu.

ADAPTATION

Les pratiques d'XP ne fournissent pas le niveau de formalisme requis par les audits de certification. Certaines pratiques devront être adaptées et d'autres ajoutées. Par exemple, la documentation devra être considérée comme faisant partie du produit. Elle devra alors être incrémentalement rédigée au fil des itérations afin de rester potentiellement livrable.

CONCLUSION

Les pratiques disciplinées et rigoureuses de l'Extreme Programming sont une aide au développement de logiciels critiques. Par contre, les pratiques doivent être adaptées pour fournir le niveau de formalisme requis par les audits de certification.

MOINS CHERS ET PLUS SURS

Aujourd'hui, Alex et moi avons rapidement traversé un labo d'intégration et de validation de logiciels critiques. Tout en discutant nous avons remarqué que:

• plusieurs opérateurs déroulaient des procédures de test à la main;

• un des opérateurs rédigeait un SMS sur son téléphone portable tout en déroulant à la main une procédure de test. Nous ne pouvons pas lui en vouloir, la procédure de test manuelle est sûrement assommante et ce n'est probablement la première fois que l'opérateur déroule cette même procédure. De plus, il ne s'agit pas d'une exécution de test comptant pour une certification de sûreté de fonctionnement.
  

De cette petite visite, nous avons tiré les conclusions suivantes:

• des tests automatisés réduiraient le coût des tests déroulés dans ce labo;

• Alex et moi aurions plus confiance en un logiciel vérifié par un test automatisé qu'en un logiciel vérifié par un opérateur distrait.

Bref, par rapport à des tests manuels, les tests automatisés sont économiquement plus intéressants et améliorent la sûreté de fonctionnement.

Une troisième pensée me vient en rédigeant ce billet. Rien ne vaut aller et constater par soi-même (ou Genchi Genbutsu en Japonais), conformément au Toyota Way. Impossible de parler d'Alex sans évoquer le Lean ;o)

A la prochaine Alex!