Validation et Qualification d'un Produit

C'est la phase la plus connue : elle provient du génie civil, pour lequel un projet peut avoir des durées importantes et les erreurs initiales peuvent être catastrophiques !

Si les fondations d'un immeuble ne sont pas bonnes, l'électricien ou le plombier ne pourront rien y faire et les corrections seront complexes et coûteuses.

L'inconvénient majeure du modèle de cycle en cascade est que la vérification du bon fonctionnement du produit est réalisée trop tardivement.

La méthode du cycle de vie en V tente de résoudre un problème simple : dans le cycle en cascade, les gens qui font les tests ne sont pas les mêmes que ceux qui ont conçu le logiciel.

De même pour ceux qui valident le logiciel et ceux qui font le cahier des charges.

Il est alors décidé d'employer une méthode permettant travailler par rôle, en créant des couches successives.

Les méthodes agiles sont des groupes de pratiques pouvant s'appliquer à divers types de projets, mais se limitant plutôt actuellement aux projets de développement en informatique (conception de logiciel). Les méthodes agiles se veulent plus pragmatiques que les méthodes traditionnelles.

Elles impliquent au maximum le demandeur (client) et permettent une grande réactivité à ses demandes.

Elles visent la satisfaction réelle du besoin du client et non les termes d'un contrat de développement. La notion de méthode agile a été officialisée en 2001 par un document, le Manifeste Agile (Agile Manifesto), signé par 17 personnalités impliquées dans l'évolution du génie logiciel, en particulier, en tant qu'auteur de leur propre méthode.

Valeurs :

Dans ce but, elles prônent 4 valeurs fondamentales (entre parenthèses, les citations du manifeste) :

• L'équipe (« Les individus et leurs interactions plus que les processus et les outils ») :

Dans l'optique agile, l'équipe est bien plus importante que les outils (structurants ou de contrôle) ou les procédures de fonctionnement. Il est préférable d'avoir une équipe soudée et qui communique, composée de développeurs (éventuellement à niveaux variables), plutôt qu'une équipe composée d'experts fonctionnant chacun de manière isolée. La communication est une notion fondamentale.

• L'application (« Des logiciels opérationnels plus qu'une documentation exhaustive ») :

Il est vital que l'application fonctionne. Le reste, et notamment la documentation technique, est une aide précieuse mais non un but en soi. Une documentation précise est utile comme moyen de communication. La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n'est pas à jour. Il est préférable de commenter abondamment le code lui-même, et surtout de transférer les compétences au sein de l'équipe (on en revient à l'importance de la communication).

• La collaboration (« La collaboration avec les clients plus que la négociation contractuelle ») :

Le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l'équipe et fournir un feed-back continu sur l'adaptation du logiciel à ses attentes.

• L'acceptation du changement (« L'adaptation au changement plus que le suivi d'un plan ») :

La planification initiale et la structure du logiciel doivent être flexibles afin de permettre l'évolution de la demande du client tout au long du projet. Les premières releases du logiciel vont souvent provoquer des demandes d'évolution.