Avant la livraison à un client, le développement d'un logiciel passe par plusieurs étapes définies au cours des deux dernières décennies :
* La recette est une vérification de conformité du logiciel par rapport aux spécifications théoriques définies au début du projet, avant son déploiement final.
Le développement d'un produit applicatif doit prendre en compte des risques inhérents à cette activité (développement d'interfaces utilisateurs, ou de fonctions inappropriées, non-respect du cahier des charges, problèmes de performance, etc.) et à l'évolution d'une entreprise (calendrier irréalisable, budget inadapté, défection des personnels, etc.).
C'est pourquoi, une société de service en ingénierie informatique doit se conformer à des règles intangibles de développement d'application. A cet effet, il existe plusieurs modèles de cycle de vie d'un logiciel :
- Le modèle en cascade consiste en une succession de phases dont chacune est méthodiquement vérifié avant de passer à l'étape suivante :
- faisabilité et analyse des besoins : validation,
- conception générale et détaillée : vérification,
- intégration : tests d'intégration et tests d'acceptation,
- installation : tests du système.
- Le modèle en V repose sur une étroite interdépendance des étapes soumises à une validation avant la prochaine étape et une vérification anticipatoire du produit final :
- spécification textuelle,
- conception générale,
- conception détaillée,
- codage,
- tests unitaires,
- tests d'intégration,
- validation.
- Le modèle en spirale s'appuie sur une succession de cycles dont chacun se déroule en quatre phases :
- analyse initiale des besoins et des objectifs du cycle (solutions et contraintes) ou analyse à partir du cycle précèdent,
- étude des risques, évaluation des solutions de remplacement et éventuellement conception,
- développement et vérification de la solution résultant de l'étape précédente,
- examen du produit et projection vers le cycle suivant.
- Le modèle par incrément propose un développement du logiciel par morceaux, lesquels sont livrés successivement au client, en venant se greffer à un noyau logiciel.
Le modèle en V demeure actuellement le cycle de vie le plus connu et certainement le plus utilisé.
La première étape, appelé spécification ou analyse des besoins, a pour but de dégager du cahier des charges, toutes les contraintes nécessaires à l'élaboration du logiciel. Trois sortes de contraintes logicielles sont à prendre en considération :
- Les contraintes externes définissent les caractéristiques d'entrée/sortie du logiciel attendues par le client (données à utiliser et à afficher, les exigences ergonomiques, le parc informatique, etc.).
- Les contraintes fonctionnelles caractérisent le fonctionnement interne du logiciel, c'est-à-dire, quels moyens seront mis en oeuvre pour traiter les informations d'entrée/sortie du logiciel (méthode de calcul, intervalle des données, etc.).
- Les contraintes de performances indiquent la vitesse d'exécution du logiciel ou de ses modules, la résolution d'affichage, la précision des données, etc..
Les documents produits (plan de développement du logiciel, spécifications des besoins du logiciel et cahier de recette) au cours de cette phase permettent de passer à l'étape suivante et également de préparer les vérifications de conformité du logiciel.
Cette phase constitue environ 15 pourcents du temps total du cycle de développement.
La conception générale (ou analyse organique générale)a pour objectif de déduire de la spécification, l'architecture du logiciel. Lors de cette phase, plusieurs solutions peuvent être envisagées afin d'en étudier leur faisabilité. A l'issue, un document de conception générale du logiciel est réalisé afin de décrire la structure générale de l'alternative approuvée.
Lors de cette phase, il peut être décider de découper le logiciel en plusieurs modules distincts afin de les sous-traiter par plusieurs équipes de développement. Un module possède une interface permettant son intégration au logiciel global ou à d'autres modules, et un corps pour son fonctionnement interne. Ils sont hiérarchisés de telle façon que des modules de bas niveau s'emboîtent dans des modules intermédiaires, lesquels s'intègrent à un module de haut niveau (noyau logiciel).
Un autre découpage peut être aussi utilisé pour scinder le logiciel en tâches distinctes. L'application contient alors plusieurs sous-ensembles ayant en charge des traitements spécifiques (tâches externes et tâches internes au logiciel), lesquels s'interconnectent entre eux
La phase de conception détaillée (ou analyse organique détaillée) en s'appuyant sur le document de conception générale, énumère l'architecture approfondie du logiciel jusqu'à parvenir à une description externe de chaque sous-ensemble et information utilisable dans le futur logiciel. A partir de cette étape, seront connus toutes les données (variables, constantes, attributs, champs, etc.) et fonctions (procédures, méthodes, etc.) de l'application vue de l'extérieur. Le logiciel peut être entièrement écrit en algorithme. Un langage de programmation est en général validé lors de cette phase. Un document de conception détaillée, ainsi qu'un manuel d'utilisation sont édités afin de respectivement de décrire l'architecture détaillée et la mise en oeuvre du logiciel. Les phases de conception doivent prendre environ 25 pourcents du temps total du cycle de développement.
Des spécifications de tests d'intégration et unitaire sont également produites, à l'issue des deux phases de conception. Elles permettront de confronter le fonctionnement de l'application à son architecture générale et détaillée.
Le codage consiste à écrire avec un langage de programmation chacune des sous-programmes du logiciel. Le développement peut être confié à une seule personne dans le cas d'une application simple ou divisé entre plusieurs équipes de développeurs dans le cas de projets importants. Cette phase durant environ 15 pourcents du temps total du cycle de vie se termine par la production d'un code source.
Les tests unitaires ont pour objectif de vérifier individuellement la conformité de chaque élément du logiciel (fonctions et variables) par rapport aux documents de conception détaillée. Toutes les fonctionnalités internes et externes de chaque sous-programme sont contrôlées méthodiquement. En outre, un contrôle des performances globales et locales est également entrepris. Cette phase consomme aux alentours de 5 pourcents du temps total du cycle de vie et se finalise par la rédaction des résultats des tests.
La phase d'intégration permet de vérifier l'assemblage des différentes parties du logiciel. Les différents modules du logiciel sont successivement intégrés jusqu'à aboutir à la construction complète, en respectant rigoureusement les spécifications des tests d'intégration. Chaque module doit parfaitement être assimilé sans que le fonctionnement des modules précédemment intégrés n'en soit aucunement affecté. Les résultats de cette phase sont consignés dans un document des tests d'intégration. En général, une présentation du logiciel est également réalisée. Les tests d'intégration représentent en moyenne 20 pourcents du temps total du cycle de développement.
La dernière phase a pour vocation de valider le logiciel dans son environnement extérieur. Le produit applicatif est mis en situation d'utilisation finale afin de vérifier s'il répond parfaitement aux besoins énoncés dans les spécifications textuelles (première phase). Un document appelé résultat de la recette est produit au terme de la phase de validation qui dure 10 pourcents du temps total du cycle de vie du développement du logiciel.
La finalité du cycle de vie en V consiste à parvenir sans incident à livrer un logiciel totalement conforme au cahier des charges. Lors de la phase de spécification textuelle, une négociation avec le client permet d'affiner ou d'enrichir les besoins à propos de certains points techniques omis ou obscurs dans le cahier des charges. Lorsque la spécification est validée, la suite du processus de développement doit être parfaitement encadré, contrôlé et approuvé de telle sorte qu'à aucun moment, il ne soit possible de diverger des règles énoncées lors de la première phase.