Cycle de vie en Génie Logiciel

Définition

 Il s’agit du processus de gestion d’une application. Il regroupe l’ensemble des phases par lesquelles passe généralement un produit partant de l’identification des besoins jusqu’à la clôture du projet. L’objectif d’un tel découpage est de permettre de déterminer la validité du projet et la vérification de son processus de développement. Le but est de faciliter la préparation de la mission, ainsi que son bon déroulement. Cette structure offre aussi la possibilité d’identifier les grandes étapes du planning.

Activité d’un cycle de vie

 Chaque projet est différent mais généralement chacun comprend au minimal les activités suivantes : Définition du besoin : Au commencement, cette étape permet de définir les objectifs du projet et sa stratégie globale, elle sera appelée à être enrichie au cours de la mission. Conception générale : Élaboration théorique de la solution et la préparation de l’architecture générale du système et de définir chaque sous-ensemble du logiciel à produire. Conception détaillée : C’est la phase durant laquelle les exigences sont transformées en caractéristiques spécifiques ou en spécification d’un produit, d’un procédé ou d’un système avant sa mise en œuvre. Développement (Implémentation ou programmation) : Il s’agit d’une traduction des fonctionnalités définies dans la phase de conception par son implémentation en utilisant une technologie adéquate. Etape de clôture : C’est la dernière étape et dans la quelle le système développé est déployé en production. Ces étapes de base sont organisées suivant le système, la nature de ses besoins, et les contraintes techniques et organisationnelles. Ainsi, nous avons plusieurs processus proposés tels que : cycle de vie en V, cycle de vie en spirale, cycle de vie en cascade, etc. Dans le cadre de ce projet, nous avons les contraintes suivantes :

• Environnement stable : contrairement à un environnement hostile et dynamique, la bibliothèque de la faculté des sciences exactes et d’informatique peut être considérée comme un environnement stable avec peu à pas de changements. 
• Nos besoins fonctionnels sont stables : vu la durée de ce projet, des changements importants des besoins sont peu probables. 
• Pas d’exigences techniques : à part la nécessité d’utiliser des technologies web (imposées par la nature du web 2.0), aucune autre contrainte technique n’est imposée. Nous notons aussi l’absence d’un code de base, ainsi, nous pouvons entamer l’analyse et la conception sans une attention particulière au choix technique.
• Une seule itération majeure : en tenant compte de la durée de réalisation ainsi que la taille du système d’un point de vu organisationnel (peu de postes de travail), une seule itération majeure est planifiée. Il sera par la suite possible d’apporter des mises à jour limitées (amélioration de l’IHM, statistiques) mais sans un changement réel sur la structure de la base de données ou bien au niveau des fonctionnalités. Par conséquent, nous avons opté pour le processus en cascade. 

Processus en Cascade

 Le modèle en cascade (waterfall model) est un modèle de gestion linéaire qui divise les processus de développement en phases de projet successives. Contrairement aux modèles itératifs, chaque phase est effectuée une seule fois. Les sorties de chaque phase antérieure sont intégrées comme entrées de la phase suivante. Le modèle en cascade est principalement utilisé dans le développement de logiciels (voir fig : 4.1).