Testez abondamment avant le grand saut !
PublicitéUn climat d'échec Dans un contexte où les mauvaises nouvelles sont légion, l'indifférence gagne rapidement et de telles « déroutes » viennent simplement s'ajouter à une longue liste d'échecs de projets informatiques publics... Nous devrions pourtant conserver notre capacité d'indignation dans la mesure où ces désastres informatiques peuvent être prévenus et ne sont pas un « mal nécessaire » auquel nous devrions nous habituer. Les entreprises comme les administrations devraient plutôt abandonner l'idée selon laquelle le développement logiciel serait une « forme d'art » et reconnaître qu'il s'agit d'un processus métier soumis aux mêmes contraintes de gouvernance et d'administration que n'importe quel autre processus d'entreprise. L'une des approches pour y parvenir est l'ALM (Application Lifecycle Management) qui permet d'interconnecter les différentes phases, activités et ressources impliquées dans l'ensemble du processus de livraison de logiciels. En d'autres termes, de transformer un processus chaotique et imprévisible en procédure contrôlée. Une des originalités de cette approche réside dans l'intégration des préoccupations de qualité tout au long du cycle de vie : de la validation de la précision des exigences initiales jusqu'au taux de couverture des tests. Ironiquement, la qualité - qui devrait être un facteur clé du processus de livraison logiciel - est trop souvent reléguée à son extrême fin et gérée avec beaucoup trop de légèreté... Une erreur trop commune - Traiter la qualité a posteriori Les préoccupations de qualité interviennent très souvent dans les ultimes étapes du cycle de livraison logiciel. Quand les tests de qualité débutent, les problèmes sont malheureusement déjà devenus très complexes et coûteux à solutionner - exigeant de multiples interventions manuelles souvent menées par une seule équipe. Certaines entreprises positionnent même scrupuleusement les activités qualité à l'extrême fin du processus d'arbitrage entre délais et budgets ; une approche qui ne peut conduire qu'à la catastrophe... D'autres contraignent les équipes de livraison à adopter une approche essentiellement réactive face aux défauts constatés ou aux exigences non respectées. Une approche plus mûre est aujourd'hui indispensable pour maximiser la qualité des logiciels tout en réduisant les coûts de développement et en améliorant les délais de mise sur le marché. En gardant ces impératifs à l'esprit, la qualité doit devenir un élément constitutif de toutes les étapes du cycle de vie de chaque projet. Certes le concept de « qualité » porte à la subjectivité... Cependant, en matière de développement informatique, il peut être quantifié en fonction de la conformité aux exigences, de l'exactitude du code, du nombre de défauts, etc. Autant de critères qui garantissent la correspondance du produit livré avec les exigences exprimées. Mieux vaut prévenir que guérir ! La livraison de logiciels doit adopter une approche proactive et préventive plutôt que strictement réactive et « en cascade » comme la subissent encore aujourd'hui de trop nombreuses entreprises. Pour cela, elles doivent se focaliser sur l'amélioration de leur capacité à livrer régulièrement et en toute confiance des produits logiciels de haute qualité pour éviter des désastres ultérieurs. Les défauts résultant de l'insuffisance des tests de qualité peuvent avoir de multiples raisons (violation de licences, médiocrité de conception, manque de lisibilité du code, ambiguïtés des exigences, vulnérabilités de sécurité, etc.) qui pourraient pourtant parfaitement être évitées - pour peu que la qualité devienne une priorité tout au long du processus de développement. Bien trop souvent, les vérifications de qualité ne débutent qu'au moment des tests - alors que le temps est compté et que de multiples lignes de code ont été déjà été écrites... Une approche qualité préventive doit naturellement débuter bien plus tôt : avant même l'écriture de la première ligne de code. Il est en effet indispensable de valider la qualité dès la définition du projet et de mettre en oeuvre des tests anticipés, plus fréquents et mieux suivis à chaque phase essentielle du cycle de livraison logiciel. En synthèse, le contrôle qualité doit être intégré dès l'initialisation du processus de développement et non uniquement à la fin, lors des tests ultimes. Cette approche, consistant à appliquer des tests rigoureux avant de faire « le grand saut », aurait été salutaire à la plupart des projets Informatiques qui défraient aujourd'hui la chronique... Deux étapes cruciales avant de se jeter à l'eau ! Pour approcher les enjeux de qualité avec plus de « maturité », les entreprises impliquées dans des projets logiciels auraient tout intérêt à adopter un processus à deux étapes : la première consistant à se focaliser sur le pré-déploiement pour anticiper d'éventuels problèmes le plus tôt possible - et ne pas être contraint de les localiser et les traiter trop tard et sous pression. La réalisation de tests cohérents suffisamment tôt et souvent est une procédure incontournable pour que les défauts n'impactent pas d'autres projets, le système dans son ensemble ou ne conduisent à un effondrement général du projet. La seconde phase consiste à ne plus considérer la qualité comme un artefact final du processus de livraison, mais de l'intégrer dès l'initialisation pour en faire l'une des priorités du projet. Cela suppose notamment de valider la clarté de définition des exigences et la qualité du code, de minimiser les erreurs et d'aligner le projet avec les besoins globaux de l'entreprise. En dépit du nombre de projets du secteur public qui ont connu une fin désastreuse en raison d'une médiocre qualité logicielle - avec des conséquences considérables - la qualité n'est toujours pas une préoccupation traitée avec le sérieux qu'elle mérite. Plus que jamais, il est temps d'abolir les barrières entre les exigences de développement métier et les impératifs d'assurance qualité pour résoudre les problèmes le plus tôt possible dans le cycle de vie du projet. Si seulement cette approche d'anticipation des tests avait plus d'adeptes, il est bien probable que les échecs de projets informatiques cesseraient de défrayer la chronique !
Article rédigé par
Christian Lainé, Directeur Général de Borland France
Commentaire
INFORMATION
Vous devez être connecté à votre compte CIO pour poster un commentaire.
Cliquez ici pour vous connecter
Pas encore inscrit ? s'inscrire