Il y a quelques années, la qualité liée au logiciel était définie comme la "conformité aux exigences fonctionnelles et de performance explicites, aux normes de développement explicitement documentées, et aux caractéristiques implicites qui sont attendues de tout le logiciel professionnellement développé".

Sans doute à cette époque les informaticiens apprenaient-ils à développer avec les mêmes méthodes « professionnelles ». Tous les clients attendaient des systèmes informatiques les mêmes caractéristiques implicites sans qu'il soit nécessaire de les énoncer. Les systèmes étaient propriétaires et communiquaient peu entre eux.

Avec la mondialisation, les développeurs apprennent surtout à développer rapidement, jonglent avec les nouvelles interfaces de développement et les protocoles de communication. De nouveaux métiers sont nés. Architecte des systèmes d'information, assistant maitrise d'ouvrage, concepteur, testeur et toujours bien entendu le développeur. Autant de métiers devant assurer leur part de qualité. Un exposé de Bertrand Cornanguer (45 ans) – Consultant Senior chez ACIAL, spécialiste du test logiciel

Il y a quelques années, la qualité liée au logiciel était définie comme la "conformité aux exigences fonctionnelles et de performance explicites, aux normes de développement explicitement documentées, et aux caractéristiques implicites qui sont attendues de tout le logiciel professionnellement développé".

Sans doute à cette époque les informaticiens apprenaient-ils à développer avec les mêmes méthodes « professionnelles ». Tous les clients attendaient des systèmes informatiques les mêmes caractéristiques implicites sans qu'il soit nécessaire de les énoncer. Les systèmes étaient propriétaires et communiquaient peu entre eux.

Avec la mondialisation, les développeurs apprennent surtout à développer rapidement, jonglent avec les nouvelles interfaces de développement et les protocoles de communication. De nouveaux métiers sont nés. Architecte des systèmes d'information, assistant maitrise d'ouvrage, concepteur, testeur et toujours bien entendu le développeur. Autant de métiers devant assurer leur part de qualité.

Des objectifs différents et pas de gestion globale de la qualité

Dans les grandes sociétés, les services informatiques ont chacun leurs objectifs, MOA, développement-études, production, et dépendent d’une DSI dans laquelle la qualité n’est pas gérée de manière transverse. Pour beaucoup encore, faire de la qualité, c’est faire des tests fonctionnels avant livraison en production. Plus les anomalies sont détectées en tests, plus les budgets de développement augmentent… Pourquoi ne pas utiliser ces enveloppes pour industrialiser la qualité logicielle sur tout le cycle de développement, et même sur le cycle de vie du système d’information ?

Une fois le système mis en production, les activités de gestion des incidents prennent le relai, et sont assurées par des personnes n’ayant pas de périmètre d’action au niveau des développements.

Pourquoi ? Parce que les budgets sont différents. Certains considèrent que si des anomalies logicielles surviennent, c’est que le processus de fabrication est défectueux. Or le processus de fabrication logicielle est souvent une suite d’activités indépendantes non pilotée par la qualité.

Dans certains appels d’offres, les missions de Tierce Recette Applicative et de Tierce Maintenance Applicative sont séparées, ce qui n’est malheureusement pas toujours le cas. Mais même dans ce cas, il manque le pilotage transverse de la qualité et l’on peut voir les deux entités « s’étriper » au lieu de travailler ensemble à l’élaboration d’un processus industriel.

Aujourd’hui, la qualité logicielle pâtit de mises en production de systèmes non conformes aux besoins du client. Peut-être certains préfèrent prendre ou cacher ce risque plutôt que d'informer et de décider de retards dans la planification ?

Des référentiels Qualité créant des inégalités

Dans les grandes sociétés, on découvre des organisations qui ont évolué au fil du temps, avec des référentiels Qualité spécifiques et indépendants les uns des autres (ISO, ITIL, CMMI).

La norme qualité organisationnelle ISO9000 est destinée à rassurer le client, mais peut être déployée sur une partie seulement de l’entreprise. Par exemple, les services administratifs en relation avec les clients pourront être ISO9000, avec des processus métier, des procédures réfléchies et des indicateurs de non conformités pertinents et suivis. Il est probable que les services de production informatique ou d’infogérance aient également mis en place des processus organisationnels basés sur ITIL car ils communiquent directement avec les utilisateurs finaux.

Mais qu’en est-il de la conception et de la réalisation informatique ? Parfois, ces services sont sous-traités en tout ou partie, obéissent à des règles particulières, et règnent sur les jalons du processus de fabrication informatique car sans eux point de logiciel.

L’idéal serait de mettre en place une stratégie assurant la qualité tout au long du processus de fabrication logiciel. Les projets sont régis par le triptyque Qualité-Coûts-Délais. Il est donc nécessaire en début de projet d’identifier les risques et les impacts des pannes sur le système à développer, et de programmer à quelles phases du processus de développement et par quelles entités ces risques seront couverts par des tests.

Une stratégie qualité globale dépassant les clivages organisationnels et la domination de la technologie

Plus tôt des défauts sont découverts, moins le projet coute cher. Cette stratégie vise à assurer que le client sera satisfait. Par le biais des revues et d’une gestion des exigences, on pourra s’assurer que le client a bien énoncé son besoin et que les spécifications le traduisent explicitement pour des caractéristiques fonctionnelles et non fonctionnelles. En effet, vous n’attendez pas seulement de la voiture que vous achetez qu’elle fonctionne, mais qu’elle soit également confortable, attrayante, fiable….

A chaque activité de conception ou de réalisation, correspond une activité de test. Une fois développé, un composant sera testé unitairement afin d’éliminer les erreurs de programmation. Le test unitaire est aidé par l’analyse structurelle que délivrent les logiciels d’analyse statique ou de métrologie de code. Lors des tests d’intégration, les intégrateurs testent les interfaces entre les composants unitaires ou les applications.

Au final, le client reçoit un logiciel conforme aux spécifications et réalise des tests d’acceptation correspondant à son cahier des charges. A ce niveau, les anomalies doivent être anecdotiques.

Mais qui est en charge de la stratégie d’assurance qualité ?

Peut être le chef de projet ? Mais en a-t-il le temps et le savoir ? Il existe des sociétés dans lesquelles le chef de projet n’a pas de formation qualité logicielle et fait la part belle à la technologie. Pour certains, faire de la qualité logicielle c’est tester avant de livrer le client. Les jalons sont prévus avec une faible marge de sécurité que chaque intervenant cherche à consommer pour ses besoins. Dans ces organisations, les tests sont appelés recettes. Ils ont pour seul objectif de trouver des défauts. Parfois les recettes sont programmées pour une durée fixe !

Et les tests de production ? Saviez vous qu’une fois développé, le logiciel continue son cycle de vie et quitte le cycle de développement ? Les services de production doivent accepter opérationnellement le nouveau système. Tests de backups, crash tests, performances et autres tests techniques prennent du temps et sont différents suivant leurs types et le système d’exploitation sur lequel ils fonctionnent.

C’est dès le lancement du cycle de développement d’un produit, que la politique qualité doit être mise en place. Pour cela, il faut définir comment les phases de test seront organisées, quels seront leurs objectifs et leur budget.

Même dans le cas de la sous-traitance, le maître d’œuvre devra prouver que les tests correspondant à son niveau ont été réalisés. Cela n’est possible que si un contrat, une norme ou une charte l’y oblige.

La difficulté de la transversalité

Les services de qualité transverses se heurtent à l’hégémonie de certains responsables de développement. Ces derniers considèrent que le développement logiciel est une boite noire et espèrent toujours avoir plus de temps que prévu pour développer. Tout comme les individus peuvent rencontrer des difficultés à travailler en équipe et préférer la séparation et la distribution individuelle des tâches, les services préfèrent travailler séquentiellement.

Si le suivi qualité n’est pas assuré et les responsables des autres activités du processus non informés, le client demande la livraison de son logiciel alors que ce dernier n’est pas terminé. C’est l’effet « tunnel » qui peut provenir d’un projet de développement au forfait pour lequel il n’y a pas de suivi hebdomadaire de l’avancement. Dans certains cas, le client en arrive à suppléer le maître d’œuvre en réalisant lui-même les tests !

Les principaux freins à la qualité logicielle engendrés par les organisations sont :

• Les contrats qui limitent les engagements des développeurs
• Les jalons que certains rebutent à décaler
• Les processus non décrits dans lesquels personne ne sait qui fait quoi quand et comment
• La non prise en compte des politiques de qualité par les chefs de projet.
• Le refus d’accepter l’ingérence des services qualité transverses dans les projets de développement
• Les recettes vues comme des projets isolés non inclus dans une stratégie qualité globale.
• Les difficultés de communication dues à l’éloignement des équipes.
• La nécessité de produire des retours sur investissement prévisionnels avant de lancer un cycle d’amélioration du processus de fabrication logiciel.

Lever les freins en créant la « charte de bonne conduite du développement logiciel »

Pourtant notre industrie manufacturière a depuis longtemps levé ces freins. La conception et la fabrication d’un logiciel peuvent suivre les même processus que la conception et la fabrication d’un phare automobile ou d’un ordinateur.

• Dans ce cas, pourquoi ne pas proposer un encadrement de projet composé d’ingénieurs et responsables ayant un vécu industriel ?
• Pourquoi ne pas créer un standard de contrat de maîtrise d’œuvre informatique assurant la qualité logicielle ?
• Pourquoi ne pas proposer un standard d’appels d’offres dans lequel le client devra fournir un cahier des charges exhaustif de type IEEE830 avant qu’un maitre d’œuvre puisse lui faire une offre de service de développement ?

Assurons le développement durable et créons et adhérons aujourd’hui à la « Charte de bonne conduite du développement logiciel ».

Bertrand Cornanguer

Consultant Senior chez ACIAL