EkoTIC

Il y a quelques années, on disait encore « Heureusement qu’on ne construit pas les voitures comme les téléphones portables ! ». Ce constat venait du fait que les téléphones de l’époque étaient très bugués mais qu’au final, les conséquences n’étaient pas si graves ! Aujourd’hui, les voitures ont des accidents à cause de régulateurs de vitesse qui restent coincés, le logiciel est omniprésent et le code de plus en plus complexe. Les conséquences, elles, peuvent être dramatiques : on se souvient d’accident de radiothérapie à cause d’une mauvaise ergonomie d’un logiciel de calibrage ou la fusée Ariane en 1996 qui a explosé peu de temps après son lancement (« bug informatique le plus coûteux de l’histoire »)…

Les processus qualité se sont donc peu à peu mis en place. Il est à peu près évident pour tout le monde maintenant que travailler en amont du codage est indispensable car le coût de changement ou correction est inférieur à ce qu’il serait une fois le développement terminé. Que ce soit pour un site web ou tout autre développement logiciel, voici ce qui peut être mis en place par l’entreprise qui réalise le développement. En tout premier lieu, il faut comprendre et bien analyser les besoins du client. Il est d’ailleurs courant que ces derniers aient déjà écrit leur cahier des charges. De l’analyse de ce cahier des charges, doit ressortir des spécifications techniques, des documents d’architecture et d’interface homme-machine si besoin. Toutes ces informations sont nécessaires afin que le développeur puisse commencer à travailler, préparer la conception du logiciel puis débuter le codage. Pour faciliter mais aussi garantir la qualité du développement, chaque fonctionnalité du cahier des charges du client pourra être numérotée et devra dans ce cas, correspondre à un item des spécifications. Evidemment tout document devra être soigneusement nommé, versionné, relu et approuvé par les différents acteurs du projet. Le stockage devra aussi se faire de préférence sur un serveur plutôt que sur un disque dur afin d’éviter toute perte de document.

En parallèle, comme le montre ce diagramme en V, des tests doivent être écrits puis passés.

C’est le développeur qui doit être d’abord garant du logiciel en ayant fait relire son code puis en ayant passé des tests unitaires. Ces tests doivent vérifier que chaque module, chaque fonction du code est correct. Le développeur pourra ensuite livrer son logiciel avec une note expliquant le fonctionnement, décrivant les tests passés et la compatibilité, si nécessaire, avec d’autres composants du logiciel complet. Après le passage de software vérifiant la robustesse des lignes de code (ClockWork Inforce par exemple), viennent alors les tests d’intégrations qui vérifient les différentes spécifications après assemblage de tout le code. C’est l’équipe validation qui termine le cycle des tests avec les tests fonctionnels qui sont tirés directement du cahier des charges du client. A la recette du logiciel (du site web par exemple), le client passera ses propres tests et donnera son accord ou non sur la livraison.

La qualité, bien que lourde et contraignante, assure la plupart du temps une certaine fiabilité par la mise en place d’indicateurs (nombre de défauts trouvés pour 1000 lignes de code, nombre de défauts trouvés par page de spécifications relue, nombre de bugs trouvés dans le logiciel, respect règles de codage et de design…).

Tous ces indicateurs sont les résultats d’expériences vécues (les « lessons learned ») sur des projets antérieurs. Les préoccupations sont évidemment économiques, le but étant de limiter le coût des erreurs et améliorer la sécurité des logiciels. Cette notion de cycle d’amélioration continue se retrouve dans les normes qualité ISO (International Organization for Standardization) et CMMi (Capability Maturity Model Integration issue du département de la défense américaine).

On retrouve aussi cette méthodologie empirique d’amélioration du process à petits pas, dans le DMAIC (Define Measure Analyze Improve Control) qui est issue du Digital Six Sigma, méthode inventée en 1986 par Motorola (plus d’infos sur http://www.isixsigma.com/ ). Les outils indispensables à cette méthode sont souvent des outils très connus comme :

- les « 5 Why’s »

- les diagrammes de causes à effets (Ishikawa, Fishbone par exemple)

- le diagramme de Pareto

Hélas beaucoup d’entreprises, plutôt que de mener cette politique de changement basée sur des process existants, préfèrent mettre en place des ERP (Entreprise Resource Planning). Par définition, ces ERP gèrent « l’ensemble des processus opérationnels d’une entreprise ». Il y a donc nécessité pour tous les acteurs de l’entreprise de s’adapter à ces ERP, au risque de voir apparaître un rejet massif des salariés envers des outils lourds à installer et à utiliser.

D’autres solutions aux problèmes de fiabilité et de process commencent à faire leur apparition. C’est le cas d’IDM (Ingénierie Dirigée par les Modèles) qui propose une modélisation en amont (correspondant à la phase de spécifications). Une fois les composants assemblés, le code est généré automatiquement. Les coûts de développement sont donc réduits et les sources d’erreurs quasi nulles si le travail a été correctement réalisé au préalable.

Affaire à suivre mais il est rassurant de voir que la qualité des logiciels est une préoccupation générale !