ETUDE COMPAREE DES DIFFERENTS CYCLES DE VIE DE LOGICIELS

Dans le domaine de l’informatique et notamment dans le domaine du développement des logiciels, on entend par cycle de vie d’un logiciel (en anglais software lifecycle) une procédure en vue du développement dudit logiciel de sa conception à sa disparition.

En effet, le cycle de vie d’un logiciel est la description d'un processus couvrant les phases de:

· Création du logiciel,

· Distribution du logiciel sur un marché,

· Disparition du logiciel.

Ainsi, l’objectif du cycle de vie d’un logiciel est de définir des jalons intermédiaires permettant la validation du développement logiciel, c’est-à-dire :

· la conformité du logiciel avec les besoins exprimés,

· la vérification du processus de développement (en d’autres termes l’adéquation des méthodes mises en œuvre).

Le cycle de vie d’un logiciel permet donc de détecter les erreurs au plus tôt et ainsi de maîtriser :

· la qualité du logiciel,

· les délais de sa réalisation,

· les coûts associés,

· les risques.

En tant que procédure, le cycle de vie d’un logiciel est composé de différentes étapes. Ainsi, en général, le cycle de vie d’un logiciel comprend au minimum les étapes suivantes :

· Analyse des besoins

· Conception globale

· Conception détaillée

· Codification

· Tests

· Recette

· Intégration

· Documentation

· Déploiement

· Maintenance et évolution

La séquence et la présence de chacune de ces activités (étapes) dans le cycle de vie dépend du choix d’un Modèle de Cycle de Vie (MCV) entre le client et l’équipe de développement.

En effet, il existe plusieurs MCV. Il est donc important pour une équipe de développement de logiciels de bien choisir son MCV. Car, ce dernier prend en compte, en plus des aspects techniques, l’organisation et les aspects humains. Ainsi, chaque équipe de développement de logiciels se doit de comparer les différents MCV en vue de choisir celui qui est adapté à leur contexte.

ETUDE COMPAREE DES DIFFERENTS CYCLES DE VIE DE LOGICIELS

Comme nous l’avons déjà dit, il existe une multitude de MCV (en cascade, en V, par incrément, en B, en spirale, etc.). Face à cette multitude de modèles, nous avons fait le choix de faire la comparaison sur quatre (04) cycles de vie à savoir :

· Le modèle en cascade,

· Le modèle en V,

· Le modèle en spirale,

· Le modèle par incrément.

Mais avant de faire une comparaison sur ces MCV, il est important de les décrire au préalable.

A. DESCRIPTION DES MCV

1. LE CYCLE DE VIE EN CASCADE (Waterfalls)

Dans ce modèle, le principe est très simple : chaque phase se termine à une date précise par la production de certains documents ou logiciels. Les résultats sont définis sur la base des interactions entre étapes, ils sont soumis à une revue approfondie et on ne passe à la phase suivante que s’ils sont jugés satisfaisants. Ce modèle, développé dans les années 1970 par W. ROYCE a servi pendant des années de modèle de référence.

2. LE CYCLE DE VIE EN V

Il s’agit d’un modèle en cascade dans lequel le développement des tests et du logiciel sont effectués de manière synchrone.

Le principe de ce modèle est qu’avec toute décomposition doit être décrite la recomposition et que toute description d’un composant est accompagnée de tests qui permettront de s’assurer qu’il correspond à sa description.

C’est le cycle de vie le plus connu et certainement le plus utilisé.

3. LE CYCLE DE VIE EN SPIRALE

Proposé par B. Boehm en 1988, ce modèle est beaucoup plus général que le précédent. Il met l’accent sur l’activité d’analyse des risques. Chaque cycle de la spirale se déroule en quatre phases :

· l’analyse préliminaire des besoins, des objectifs du cycle, des alternatives pour les atteindre et des contraintes ;

· la conception, l’analyse des risques, évaluation des alternatives et, éventuellement maquettage ;

· la réalisation, le développement et la vérification de la solution retenue, un modèle « classique » (cascade ou en V) peut être utilisé ici ;

· la validation et la revue des résultats et vérification du cycle suivant.

4. LE CYCLE PAR INCREMENT

Dans les modèles précédents, un logiciel est décomposé en composants développés séparément et intégrés à la fin du processus.

Dans les modèles par incrément un seul ensemble de composants est développé à la fois : des incréments viennent s’intégrer à un noyau de logiciel développé au préalable. Chaque incrément est développé selon l’un des modèles précédents. En bref, le modèle par incrément découpe le système en domaines qui sont traités individuellement sur le modèle en cascade.

Nous venons de faire la description de ces quatre (04) MCV. Nous allons maintenant faire les comparer selon les critères ci-après :

· Forces

· Faiblesses

· A quel moment utiliser tel ou tel MCV

B. TABLEAU COMPARATIF DES DIFFERENTS CYCLES DE VIE

CYCLE DE VIE

FORCES

FAIBLESSES

QUAND UTILISER

CASCADE (WATERFALLS)

· Facile à comprendre et à utiliser

· Adapté pour une équipe inexpérimentée

· Les limites de chaque étape sont visibles

· Facilite un management du projet

· La définition des besoins est non-évolutive

· La qualité prime sur le coût

· Tous les besoins doivent être bien spécifiés au départ

· Donne une fausse impression de l’avancée des travaux

· Pas d’interaction entre les phases de développement

· L’intégration n’a lieu qu’à la fin du cycle

· Le client peut se retrouver non satisfait

· Pas de retour en arrière d’une phase à l’autre

· La phase de spécification a été très bien faite

· La définition du produit est stable

· Il s’agit d’une nouvelle version d’un produit existant

· L’implantation d’un produit existant sur une nouvelle plate-forme

· Une bonne maîtrise de la technologie

EN V

· Facile à utiliser

· Les tests sont effectués à chaque étape

· Le contrôle se fait progressivement à chaque étape

· Les phases de validation sont prises en main très tôt dans le processus de développement

· Une mauvaise prise en compte des évènements concurrents

· Le processus n’est pas itératif

· Une mauvaise prise en compte des changements de la spécification des besoins

· Ne contient pas les activités d’analyses de risques

· Les spécifications de besoins doivent être bien faites

· La solution à développer et la technologie à utiliser doivent être parfaitement connues

· Les changements doivent être faits avant l’analyse

· Excellent pour les systèmes requérant une grande sûreté

EN SPIRALE

· Sans coût élevé, donne des indications sur les risques majeurs

· Les fonctions critiques à haut risque sont développées en premier lieu

· La conception ne doit pas forcément être terminée

· Les utilisateurs finaux sont intimement associés à toutes les étapes du développement

· Le développement se fait en interaction avec les clients

· L’évolution du coût de développement est sous contrôle

· Les utilisateurs ont dès le départ une vue globale du système

· Le temps consacré à l’évaluation des risques est trop élevé pour des petits projets

· Le temps mis à planifier, évaluer les risques, fixer les objectifs, les prototypes peut être excessif

· Ce modèle est complexe

· Une expertise en évaluation des risques est nécessaire

· La spirale peut être infinie

· les développeurs travaillent par intermittence

· il est difficile de définir les objectifs et les points de validation intermédiaires entre les différentes étapes

· les coûts et l’évaluation des risques est important

· pour des projets à risque au moins moyennement élevé

· pour des projets à long terme dont les financements peuvent varier

· les utilisateurs ne définissent pas clairement leurs besoins

· la spécification des besoins est complexe

· il s’agit d’une nouvelle gamme de produits

· des changements significatifs peuvent intervenir à cause par exemple de l’évolution de la recherche ou de l’exploration

PAR INCREMENT

· Le client peut valider chaque étape du processus

· Utilise la méthode Diviser Pour Régner

· La délivrance du produit est rapide

· Le coût de lancement du projet est moindre

· Un produit exploitable peut être délivré à tout moment

· Les clients obtiennent les fonctionnalités majeures du système très tôt

· Le risque du changement des besoins est minimal

· Développe les fonctions primordiales dès le départ

· Requière une bonne planification et une bonne conception

· Requière la définition complète des fonctionnalités du système pour une définition des différents incréments

· Le coût total du développement du système n’est pas négligeable

· Les différentes interfaces doivent être bien définies

· Sur un projet utilisant de nouvelles technologies

· Sur des projets ayant une durée de développement assez longue

· Le besoin pour les développeurs de connaître dès le départ les fonctionnalités majeures

· La plupart des fonctionnalités doivent être connues au départ mais certaines ne seront utilisées que plus tard

· Les risques, le financement, la complexité du logiciel, l’élaboration ou les besoins pour les bénéfices maximum dès le départ

CONCLUSION

En termes de conclusion, il n’est pas facile de comparer ces différents cycles de vie. Chacun a ses forces, ses faiblesses et un cadre d’utilisation bien déterminé. Malgré tout, nous constatons une plus grande utilisation du cycle en V par la plupart des équipes de développement.

Partager cet article

Repost0

Published by patjo82 - dans éducation
commenter cet article …

patjo82 à l'ENS