Vous êtes sur la page 1sur 10

TD-IGL SITW 2011-2012

Modèles de Cycle de Vie en GL


1. Qu'est-ce que le Génie Logiciel ?

Le terme Génie Logiciel (GL) désigne l'ensemble des méthodes, techniques et outils permettant la
production d'un logiciel, au-delà de la seule activité de programmation. Cette branche de l'informatique
s'intéresse plus particulièrement à la manière dont le code source d'un logiciel est spécifié puis produit.
Le génie logiciel touche au cycle de vie des logiciels où toutes les phases de la création d'un logiciel
informatique y sont abordées: l'analyse du besoin, l'élaboration des spécifications, la conceptualisation
du mécanisme interne au logiciel ainsi que des techniques de programmation, le développement, la
phase de test et finalement à la maintenance.

L'ingénieur logiciel peut, par exemple, mettre au point des logiciels responsables des effets spéciaux
dans les films de science-fiction. Il peut également déterminer comment les interfaces usagers
appropriées (Icônes, fenêtres, images, objets en 3D) se présentent à l'écran. D'autres vont concevoir,
spécifier, valider et vérifier des logiciels destinés à des processeurs intégrés.

On retrouve ces processeurs intégrés non seulement dans nos ordinateurs personnels, mais aussi dans
une multitude d'objets manipulés quotidiennement. Ils sont souvent responsables du développement, de
l'élaboration et de la gestion de projets à grande échelle où sécurité du public, maintenance et évolution
des systèmes logiciels sont d'une importance primordiale.

2. Cycle de Développement de Logiciel

Un logiciel est construit selon certaines étapes afin d’aboutir à un produit d’une certaine qualité.

2.1. Critère de qualité

Le but du développement de logiciel est de produire un soft de qualité. De nombreux critères existent
afin de définir la qualité d'un logiciel.

Exactitude
C'est l'obtention des résultats escomptés. Si un logiciel doit effectuer des calculs sur des matrices, on
s'attend à ce qu'il le fasse. Obtenir tout autre résultat ne nous intéresse pas et ne répond pas à nos
besoins.

Portabilité
C'est la facilité à porter un logiciel sur un autre système d'exploitation. Par exemple, on pourrait citer
Mozilla et Apache qui ont cette qualité, car ils existent pour divers systèmes.

Extensibilité
C'est la facilité qu'un logiciel puisse être adapté pour de nouveaux besoins. Un système mal conçu
pourrait faire en sorte que tout le système doit être refait afin d'ajouter quelques fonctionnalités que les
utilisateurs désirent. Un tel logiciel ne serait alors pas extensible.

Cycle de développement 1
TD-IGL SITW 2011-2012
Réutilisabilité
C'est la capacité à utiliser certaines parties du logiciel pour créer d'autres logiciels. Une telle approche
permet de diminuer les coûts et risques lors de la construction d'un système.

Vérifiabilité
C'est la facilité à créer des tests pour un logiciel.

Intégrité
C'est l'aptitude d'un logiciel à se protéger contre les accès interdits au niveau du code et des données

Robustesse
C'est la capacité du logiciel à bien répondre lorsque les conditions d'utilisation sont anormales. Un
logiciel pourrait être conçu pour qu'environ 100 utilisateurs puissent l'utiliser simultanément. Des tests
avec 1000 utilisateurs pourraient être faits afin de savoir si le logiciel est encore capable de répondre
convenablement aux usagers.

D'autres qualités peuvent exister pour un système. Un logiciel ne peut combler toutes ces qualités.

2.2. Etapes de développement

Le développement de logiciel, peut se résumer en 7 étapes pouvant varier d'une entreprise à l'autre.
Elles constituent néanmoins le squelette du cycle logiciel.

Déterminer les besoins


La communication est primordiale afin d'arriver au résultat recherché par le client qui n'est pas
nécessairement un connaisseur en informatique. C'est pour cette raison que la communication est
primordiale afin que les deux parties se mettent d’accord sur ce qui doit être réalisé.

Cette section doit spécifier les fonctions nécessaires pour répondre aux besoins du client devant être
traduits en :
- besoins logiciels ;
- connaissances informatiques qu'ont les utilisateurs ;
- les performances requises ;
- les contraintes de réalisation ;
- le nombre de fois que l'usager doit utiliser le système ;
- les caractéristiques clés.

Plusieurs moyens sont disponibles pour obtenir ces informations. Il est possible :
- d'effectuer des entretiens avec les clients et les utilisateurs ;
- d’utiliser des questionnaires ainsi que d'observer les utilisateurs dans leurs tâches.

Les besoins du client au niveau des interfaces, performances contraintes, qualités... doivent être
traduits. Les deux parties doivent bien s'attendre afin que la suite puisse fonctionner.

Conception préliminaire
Cette section décrit de façon globale le produit. Les résultats de l'étape précédente sont utilisés afin de
produire ce que le système doit faire. Cette section doit permettre de savoir si le projet est faisable au
niveau informatique, l'estimation de travail à faire. On doit pouvoir savoir comment réaliser le logiciel

Cycle de développement 2
TD-IGL SITW 2011-2012
à la fin de cette section. La solution doit être décomposée en une architecture modulaire. Tous les
besoins doivent être définis et décomposé en fonction. C'est l'étape du «quoi».

Conception détaillée
La description du logiciel est faite. Maintenant, on doit spécifier davantage les détails du système afin
d'arriver à une description très proche du programme. C'est l'étape du «comment».
- Les modules de la section précédente doivent être décrits minutieusement.
- Les fonctions doivent être décomposées en éléments plus petits.
- Les données et algorithmes doivent être décrits pour chaque élément.
- Les données d'entrée et de sortie doivent être précisées.
- Un plan de test doit être fait pour chaque module.
- Une bonne estimation du temps et du nombre de personnes nécessaires peut-être fait à la
suite de cette section.

Implémentation
Les modules de la section précédente doivent être codés, réalisés dans un langage de programmation.
C'est souvent à cette étape que les gens s'attardent le plus les autres étant souvent très négligées, pour
ne pas dire oublié. Des tests des modules séparés sont effectués.

Intégration
Cette étape vérifie si l'architecture spécifiée dans la conception préliminaire est bien respectée. On
rassemble les modules entre eux et on fait des tests progressivement en vérifiant les résultats obtenus à
ceux attendus. Un travail de modification doit être fait si les résultats ne concordent pas avec ceux
escomptés.

Test
Cette étape permet de savoir si on a bien écrit le système que le client désirait, de savoir si on a répondu
à ses besoins. Des tests de validation doivent être faits afin de vérifier si le logiciel est conforme aux
spécifications déjà établies du logiciel. Le système doit être testé par d'autres personnes que ceux qui
l'ont conçu et sur d'autres machines.
Au succès des tests, le système est installé chez le client et une formation est donnée à l'aide de
documentation et au besoin avec des vidéo ou des cours.

Maintenance
Des anomalies peuvent être retrouvées après l’utilisation et une ou des personnes sont en charge de
modifier les modules, documentations, etc., afin de résoudre ces problèmes.
De nouvelles fonctionnalités peuvent être ajoutées et des tests peuvent être refaits afin de s'assurer que
les corrections n'apportent pas d'autre problème sur le système.

Note : Même si aucun problème n'était trouvé, rien ne garantit, que le système est bien, celui que le
client désirait.

Chaque étape du cycle de vie a un temps approximatif. Mais l’on remarque que très souvent la majorité
du temps est passé à l'implémentation.

Déterminer les besoins environ 15% Conception préliminaire environ 10%


Conception détaillée environ 15% Implémentation environ 20%
Intégration environ 10% Test environ 30%

Cycle de développement 3
TD-IGL SITW 2011-2012
Selon des études, seulement 30 % des projets informatiques des entreprises connaissent la réussite.
C'est très peu. Environ 15 % d'entre eux sont purement et simplement des échecs et 50 % ne répondent
pas aux contraintes qui leur avaient été imposées, d'où la nécessité de bien s'attendre avec le client sur
ce qui doit être fait.

Le cycle présenté ici ne garantit pas que le projet soit une réussite, mais il diminue les risques d'avoir
un échec. Une étape ne doit pas être nécessairement être terminé pour en entamer une autre. Le modèle
présenté ici est général. Nous allons voir plus en détail des modèles de développement qui existent.

2.3. Modèles de cycle de vie

Comme pour toutes les fabrications, il est important d’avoir un procédé de fabrication du logiciel bien
défini et explicitement décrit et documenté. En GL, il s’agit d’un type de fabrication un peu particulier :
« en un seul exemplaire », car la production en série est triviale (recopie).

Les modèles de cycle de vie du logiciel décrivent à un niveau très abstrait et idéalisé les différentes
manières d’organiser la production. Les étapes, leur ordonnancement, et parfois les critères pour passer
d’une étape à une autre sont explicités (critères de terminaison d’une étape - revue de documents -,
critères de choix de l’étape suivante, critères de démarrage d’une étape).

Il faut souligner la différence entre étapes (découpage temporel) et activités (découpage selon la nature
du travail). Il y a des activités qui se déroulent dans plusieurs étapes (ex : la spécification, la validation
et la vérification), voire dans toutes les étapes (ex : la documentation).

2.3.1. Modèle en cascade (Waterfall)

Le modèle de cycle de vie en cascade a été mis au point dès 1966, puis formalisé aux alentours de
1970. Il définit des phases séquentielles à l'issue de chacune desquelles des documents sont produits
pour en vérifier la conformité avant de passer à la suivante :

Figure 1. Le modèle en cascade avec itérations


Cycle de développement 4
TD-IGL SITW 2011-2012
+ Simplicité (structuration en étapes)

- Les étapes sont chronologiquement séquentielles (sans retour en arrière dans la variante simplifiée)
- Le modèle repose lourdement sur la capacité à dresser les besoins dès le début, ce qui n’est pas une
tâche facile.
- Les problèmes dans la spécification sont souvent détectés tardivement, au moment des tests, voire au
moment de la livraison du logiciel à l’utilisateur.
- Le procédé peut prendre beaucoup de temps avant que la première version qui tourne ne soit
produite.

Note : Ce modèle est seulement applicable pour les projets qui sont bien compris et maîtrisés.

2.3. 2. Modèle en V

Le modèle en V part du principe que les procédures de vérification de la conformité du logiciel aux
spécifications doivent être élaborées dès les phases de conception.

Le V est parcouru de gauche à droite en suivant la forme de la lettre : les activités de construction
précèdent les activités de validation et vérification. Mais l’acceptation est préparée dès la construction
(flèches de gauche à droite). Cela permet de mieux approfondir la construction et de mieux planifier la
"remontée".

Figure 2. Le modèle en V
Cycle de développement 5
TD-IGL SITW 2011-2012
Notons que dans ce modèle, les premières étapes du développement préparent les dernières étapes. La
première branche correspond à un modèle en cascade classique mais avec des sorties correspondant à
des descriptions de plus en plus raffinées, accompagnées de définitions de tests sur ces mêmes
descriptions.
Avec les jeux de tests préparés dans la première branche, les étapes de la deuxième branche peuvent
être mieux préparées et planifiées.

+ Eviter d’énoncer une propriété qu’il est impossible de vérifier objectivement une fois le logiciel
réalisé.
+ Permet une meilleure anticipation.
+ Evite les retours en arrière.

- Les coûts provoqués par l’échec d’un test sont proportionnels au temps écoulé jusqu’alors.

Note : Ce modèle est le plus utilisé particulièrement pour les systèmes embarqués.

2.3.3. Modèle par Prototypage

Le modèle par protypage permet d’affiner progressivement la spécialisation des besoins, à partir d’une
spécification grossière jusqu’à une spécification détaillée en passant par des validations successives de
prototypes (utilisation d’interfaces graphiques pour le prototypage)

Figure 3. Le modèle par prototypage

L’évaluation du prototype consiste à l’utiliser et à vérifier son adéquation au logiciel désiré.

Note : Ce modèle de développement est utilisé lorsque les besoins ne sont pas très claires ou s’il faut
inclure le client dans le processus de développement.

2.3.4. Modèle en spirale

Enfin le modèle en spirale, de Boehm (1988), met l’accent sur l’évaluation des risques. A chaque étape,
après avoir défini les objectifs et les alternatives, celles-ci sont évaluées par différentes techniques
(prototypage, simulation, ...), l’étape est réalisée et la suite est planifiée. Le nombre de cycles est
variable selon que le développement est classique ou incrémental.

Cycle de développement 6
TD-IGL SITW 2011-2012

Figure 4. Le modèle en Spirale

+ Réduit les risques s’il est bien appliqué.


- Augmente considérablement les risques si le contrôle faiblit.
Note : Ce modèle est utilisé pour des projets innovants, à risques, et dont les enjeux sont importants.
Exemple : Centrale nucléaire / Système embarqué d’un avion

2.3.5. Modèle par incréments

Un logiciel peut être construit étape par étape bien qu’il soit spécifié et conçu dans son ensemble mais
sa réalisation se fait par incréments de fonctionnalités. Chaque incrément est intégré à l’ensemble des
précédents (le processus de développement de chaque incrément (composant) est un processus
classique) et à chaque étape, le produit est testé, exploité et maintenu dans son ensemble.
Incréments
Conception / Réalisation / teste

Conception / Réalisation / teste

Noyau
Conception / Réalisation / teste

Temps
Figure 5. Le modèle par incréments

Cycle de développement 7
TD-IGL SITW 2011-2012
+ Les intégrations sont progressives et il peut y avoir des livraisons et des mises en service après
chaque intégration d’incrément ;
+ En conséquence, le modèle permet de faire accepter progressivement un logiciel par les utilisateurs
plutôt que de faire un changement brutal des habitudes.

- La possibilité de remise en cause du noyau et des incréments précédents. De même, la possibilité de


ne pas pouvoir intégrer d’autres incréments, d’où il est nécessaire de définir les incréments, les plus
indépendants possible, au début du projet et ce de façon globale.

Exemple : Un Scheduler (Ordonnanceur) ou un gestionnaire de fichiers peuvent constituer des


incréments d’un système d’exploitation.

3. Méthodes Agiles

Les méthodes de développement dites « méthodes agiles » (en anglais Agile Modeling, noté AG) visent
à réduire le cycle de vie du logiciel (donc accélérer son développement) en développant une version
minimale, puis en intégrant les fonctionnalités par un processus itératif basé sur une écoute client et des
tests tout au long du cycle de développement.

L'origine des méthodes agiles est liée à l'instabilité de l'environnement technologique et au fait que le
client est souvent dans l'incapacité de définir ses besoins de manière exhaustive dès le début du projet.

Grâce aux méthodes agiles, le client est pilote à part entière de son projet et obtient très vite une
première mise en production de son logiciel.

RAD - Développement rapide d'applications

La « méthode de développement rapide d'applications » (en anglais Rapid Application Development,


notée RAD), définie par James Martin au début des années 80, consiste en un cycle de développement
court basé sur 3 phases (Cadrage, Design et Construction) dans un délai idéal de 90 jours et de 120
jours au maximum.

DSDM

La méthode DSDM (Dynamic Software Development Method) a été mise au point en s'appuyant sur la
méthode RAD afin de combler certaines de ses lacunes, notamment en offrant un canevas prenant en
compte l'ensemble du cycle de développement.

Les principes fondateurs de la méthode DSDM sont les suivants :

• Une implication des utilisateurs


• Un développement itératif et incrémental
• Une fréquence de livraison élevée
• L'intégration des tests au sein de chaque étape
• L'acceptation des produits livrés dépend directement de la satisfaction des besoins

Cycle de développement 8
TD-IGL SITW 2011-2012
UP - Unified Process

La méthode du Processus Unifié (UP pour Unified Process) est un processus de développement itératif
et incrémental, ce qui signifie que le projet est découpé en phases très courtes à l'issue de chacune
desquelles une nouvelle version incrémentée est livrée.

Il s'agit d'une démarche s'appuyant sur la modélisation UML pour la description de l'architecture du
logiciel (fonctionnelle, logicielle et physique) et la mise au point de cas d'utilisation permettant de
décrire les besoins et exigences des utilisateurs.

RUP - Rational Unified Process

RUP (Rational Unified Process) est une méthode de développement par itérations promue par la société
Rational Software, rachetée par IBM. RUP propose une méthode spécifiant notamment la composition
des équipes et le calendrier ainsi qu'un certain nombre de modèles de documents.

XP - eXtreme Programming

La méthode XP (pour eXtreme Programming) définit un certain nombre de bonnes pratiques


permettant de développer un logiciel dans des conditions optimales en plaçant le client au cœur du
processus de développement, en relation étroite avec le client.

L'eXtreme Programming est notamment basé sur les concepts suivants :

• Les équipes de développement travaillent directement avec le client sur des cycles très courts
d'une à deux semaines maximum.
• Les livraisons de versions du logiciel interviennent très tôt et à une fréquence élevée pour
maximiser l'impact des retours utilisateurs.
• L'équipe de développement travaille en collaboration totale sur la base de binômes.
• Le code est testé et nettoyé tout au long du processus de développement.
• Des indicateurs permettent de mesure l'avancement du projet afin de permettre de mettre à jour
le plan de développement.

4. Durée de cycle de vie

La durée d'un cycle de vie est très variable d'un projet à l'autre.

Exemple 1 : SGBD RELATIONNEL


- Premier prototype: 5 à 7 ans
- Premier système commercial: 3 à 4 ans
- Maintenance > 10 ans
- Re- livraison tous les 6 mois /1an

Exemple 2: Langage ADA


- Définition et analyse des besoins: 3 ans
- Compilateur industriel : 3 ans
- Maintenance : > 15 ans
- Re- livraison tous les 1 à 2 ans.

Cycle de développement 9
TD-IGL SITW 2011-2012

Bibliographie

G. Booch, Object Oriented Analysis and Design with Applications, Deuxième Edition, Benjamin /
Cummings, Menlo Park (Calif.), 1994.

M.C. Gaudel et al. Précis du génie logiciel, Editions Masson,1996.

D.J. Hatley, Stratégies de spécification des systèmes temps réels (SA-RT), Editions Masson, 1991.

A. Strohmeier, D. Buchs, Génie logiciel: principes, méthodes et techniques, collection : informatique,


1996.

Cycle de développement 10

Vous aimerez peut-être aussi