Il existe de nombreuses façons de s'y prendre pour livrer un produit conforme aux attentes d'un client… et surtout aucune qui soit consensuelle. Ainsi, certaines équipes travaillent en mode agile (avec des méthodes comme Scrum ou Kanban par exemple), d'autres avec des approches plus classiques comme le cycle en V, modèle en cascade, spirale…), d'autres encore sans méthode concrètement formalisée…
Important La qualité logicielle est un dénominateur commun à tous les projets informatiques, quelque soit leur mode d'organisation. C'est une préoccupation transverse.
Ainsi, l'intégration des préoccupations liées à la qualité (au sens large : conformité technique, qualité des process, conformité fonctionnelle…) dans les process IT est tout à fait primordiale, et doit se faire à tous les niveaux, et à tous les moments du cycle de vie du logiciel. Ce sujet est du reste généralement confié à une équipe dédiée dans les organisations, qui a en charge la définition, la mise en œuvre et le suivi d'une démarche qualité auprès de l'ensemble des équipes (concepteurs, développeurs, analystes…).
Le V du fameux cycle en V, aujourd'hui décrié par certains (car un peu passé de mode dans la mouvance agile), a le mérite d'expliciter très clairement et de positionner les étapes fondamentales de la démarche qualité, avec un niveau de formalisme avancé.
Le cycle en V intègre des éléments forts liés à la qualité
Ainsi, toute la partie droite du V préconise des éléments liés à la qualité du système délivré (pas de panique si vous ne connaissez pas encore la nature, la raison d'être ou encore les détails de mise en œuvre de ces éléments : c'est tout le but de ce cours !) :
Le cycle en V, comme beaucoup de méthodes « traditionnelles » préconise donc la validation de la qualité des éléments du système après leur création, dans un processus très séquentiel : en théorie, tous les développements sont fait, puis testés unitairement, puis en intégration, etc.
Les méthodes agiles prennent le contre-pied de cette organisation séquentielle, en tentant de répondre à une problématique souvent constatée dans ce genre de méthodologie : on ne sait jamais (ou très très rarement), au début d'un projet, ce que l'on va finalement devoir produire (donc tester et valider). De nombreux éléments aboutissent à cet état de fait, comme par exemple la fluctuation des attentes du client (elle-même impliquée, souvent, par la fluctuation du marché dans lequel évolue le dit client), le fait que certaines problématiques de conception ou d'implémentation ne pourront être découvertes qu'en cours de route, etc.
La solution proposée par l'agilité : moins de plan, plus d'adaptabilité. C'est un procédé fortement itératif : on fait, on regarde, on corrige, et on recommence !
Scrum et son fameux tableau blanc… se préoccupe aussi de la qualité !
La qualité est tout aussi centrale dans un projet agile que dans d'autres formes d'organisation. D'autre part, le caractère « mouvant » des spécifications implique une nécessiter vitale de détecter rapidement les régressions éventuelles. Ceci est notamment rendu possible, comme nous le verrons par la suite, grâce à l'instauration systématique de tests unitaires et d'intégration, et d'une démarche dite d'intégration continue. Les projets agiles font également la part belles aux « acceptance tests », des tests fondés sur les cas d'utilisation et destinés à valider la conformité fonctionnelle des développement réalisés.
Il existe des tas de manières d'organiser un projet informatique, mais le problème de fond ne change jamais : à la fin du projet, il faut pouvoir livre au client un produit qui correspond à ses attentes, fonctionnel, et qui le restera.
Pourquoi la qualité est-elle une préoccupation transverse dans les projets de développement informatique ?
Le plan qualité définit un référentiel de travail applicable pour l'ensemble des acteurs d'un projet.
Quel est l'intérêt d'une bonne politique qualité dans un projet IT ?
Citez des différences de gestion de la qualité logicielle entre les méthodes agiles et les autres méthodes plus traditionnelles.
Attention : agile ne veut pas dire « sans specs » ou « sans conception »…