Vous êtes sur la page 1sur 57

Les processus (modèles de cycle de vie)

Les logiciels (Les grands)qui sont


fabriquées par un grand nombre de
gens doivent être fabriquées en
utilisant une bonne méthodologie ou
processus
Les processus (modèles de cycle de vie)
• Une méthodologie est une :
– Façon systématique pour faire les choses
– Un processus répétitive qu’on peut suivre
de les premiers étapes du développement
d’un logiciel jusqu’a la maintenance d’un
logiciel installée.
Les processus
• Une méthodologie aide :
1. Augmenter notre compréhension du problème
2. Améliore la qualité de notre solution
3. Spécifie qu’est ce qu’on doit faire à la fin de chaque
étape.
4. Produire une code qui est
• Plus extensible (facile a changer)
• Plus réutilisable (applicable à d’autre problème)
• Facile a debugger (parce qu’il contient beaucoup de
documentation)
Modèles de cycle de vie

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
La différence entre étapes et activités
• é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).
La différence entre vérification et
validation

• Vérification : « are we building the product


right ? » (« construisons nous le produit
correctement ? »

• Validation : « are we building the right


product » (« construisons nous le bon
produit ? » - adaptation vis à vis des besoins
des utilisateurs
Vie d’un logiciel
Les étapes du cycle de vie d’un
logiciel
• Etude préliminaire
• Analyse
• Analyse du système
• Conception
• Programmation
• Intégration et tests de qualification
• Installation ou déploiement
• Maintenance
• Activités transversales
Etude préliminaire
• Etude préliminaire ou étude de faisabilité ou
planification :
– définition globale du problème,
– différentes stratégies possibles avec
avantages/inconvénients,
– ressources, coûts, délais
Analyse
• Analyse des besoins ou analyse préalable :
(cahier des charges + plan qualité)
– qualités fonctionnelles attendues en termes des
services offerts,
– qualités non fonctionnelles attendues : efficacité,
sûreté, sécurité, facilité d’utilisation, portabilité, etc.
– qualités attendues du procédé de développement (ex :
procédures de contrôle qualité).
– Le cahier des charges peut inclure une partie destinée
• aux clients (ce que peuvent attendre les clients) et
• une partie destinée aux concepteurs (spécification des
besoins).
Analyse du système
• Analyse du système : (dossier d’analyse + plan de
validation)
– modélisation du domaine,
– modélisation de l’existant (éventuellement),
– définition d’un modèle conceptuel (ou spécification
conceptuelle),
– plan de validation.
Conception
• Conception : (dossier de conception + plan de test
global et par module)
– proposition de solution au problème spécifié dans
l’analyse
– organisation de l’application en modules et interface
des modules (architecture du logiciel),
– description détaillée des modules avec les algorithmes
essentiels (modèle logique)
– structuration des données.
Programmation
• Programmation et tests unitaires : (dossiers de
programmation et codes sources)
– traduction dans un langage de programmation,
– tests avec les jeux d’essais par module selon le plan
de test.
Intégration et tests de
qualification
• Composition progressive des modules,

• Tests des regroupements de modules,

• Test en vraie grandeur du système complet selon


le plan de test global (‘alpha testing’).
Installation ou deploiement

• Mise en fonctionnement opérationnel chez les


utilisateurs.

• Parfois restreint dans un premier temps à des


utilisateurs sélectionnés (‘beta testing’).
Maintenance
• Maintenance corrective,

• Maintenance adaptative,

• Maintenance perfective.
Activités transversales
• Activités transversales à tout le cycle de vie :
– spécification,
– documentation,
– validation et vérification,
– management.
Cycle de vie

• Différents modèles :
– en cascade (waterfall)
– en V
– en spirale
– Incrémental
– Prototypage
– Itérative
– ...
Des Cycle de vie

• S'il y a plusieurs modèles, c'est que :


– pas un parfait, ni même meilleur que les autres
– des qualités et des défauts, suivant les contextes
– garder un regard critique
Modèle en cascade
• La première tentative pour mettre de la rigueur
dans le ‘développement sauvage’
• Consiste à distinguer une phase d’analyse avant la
phase d’implantation
Modèle en cascade
• Pendant les 70,
– Plus grand nombre d’étapes étaient nécessaires pour le
développement des applications complexes.
– Il faut en particulier distinguer
– L’analyse du ‘quoi faire ?’ qui doit être validée par
rapport aux objectifs poursuivis et
– La conception du ‘comment faire?’ qui doit être
vérifiée pour sa cohérence et sa complétude.
Modèle en cascade
Modèle en cascade
• Même si
– on l’étend avec des possibilités de retour en arrière, (la phase
qui précède)
– le développement reste fondamentalement linéaire.
– il se fonde sur l’hypothèse souvent irréaliste que
• on peut dès le départ définir complètement et en détail ce
qu’on veut réaliser.

La pratique montre que c’est rarement le cas


Modèle en cascade
Caractéristiques du modèle
en cascade
• Même si elle n’est pas réaliste, cette représentation
très simplifiée a permis de définir :
– des cadres conceptuels (définition des différentes
phases -) et terminologiques,
• Largement acceptés et normalisés par plusieurs
organismes (ISO,AFNOR, IEEE, DOD pour les
applications militaires aux USA, ESA, etc.).
Critique du modèle en cascade
• Easy to plan (Similarité)
• Easy to schedule (complexité, nombre de
développeur, nombre totale de phases)
• Nous permet d’avoir des développeurs avec
différentes types d’expérience a chaque phase
• Chaque équipe d’expertise plonge dans son phase
jusqu’à
– Trouver une solution de son partie du problème
– Puis elle documente son travail
– Puis elle passe le bâton a l’équipe suivante
Critique du modèle en cascade
• C’est une bonne idée mais pas realistic
– Car on ne peut pas prévoir les difficulté qu'on peut
rencontre dans le future (mauvais modélisation,
technologie inconvenable, tremblement de terre !!!)
• Par suite :
– Chaque phase peut prendre plus de temps
– Et le projet tout entier va etre en retard

En pratique, c’est exactement la réalité dans la


plupart de cas
Critique du modèle en cascade
• Et pour le client, sponsor??
– Aurons -t’ils leurs besoins ou ce qu’ils veulent?
– Le client à été consultée au début
– Les fonctionnalités du système ont été bien discutée (
Requirement phase)
• Mais :
– Si une fonctionnalité est impossible à réaliser
– Le client ne sera pas consultée jusqu’à la phase de test
ou peu être de déploiement
Mais c’est trop tard
Critique du modèle en cascade
• C’est ne sont pas les seuls
problèmes
• Ce model se focalise sur la
résolution d’un problème en
tout entier
• Manger un éléphant est une
tache trop dure
– Si on vous demande de
manger un éléphant est ce
que vous l’avaler tout entier
ou bien vous mangez une
portion, prenez une pose,
mangez une autre portion et
ainsi de suite…
Critique du modèle en cascade
• Malgré ce grand nombre de points négatifs
• La plupart de développement des logiciels ont utilise
cette méthode
• Des grandes compagnies étaient trop satisfaisante
d’utilise cette méthodologie et de le choisir comme best
practice dans leurs départements et construire une grande
carrière
• Il est préférable de l’utiliser :
– On applique une type particulier de développement avec des petites
modifications
– Pour le développement rapide de petites logiciels avec un petit nombre de
développeurs
Caractéristiques du modèle en V
• Le modèle en V est une autre façon de
présenter une démarche qui reste linéaire,
• Mais qui fait mieux apparaître
– les produits intermédiaires à des niveaux d’abstraction
et de formalité différents
– et les procédures d’acceptation (validation et
vérification) de ces produits intermédiaires.
Modèle en V
Caractéristiques du modèle en V
• 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’.
Caractéristiques du modèle en V
• Tâches effectuées en parallèle
– Horizontalement : préparation de la vérification
• Ex. : dès que la spécification fonctionnelle est faite :
– plan de tests de qualification
– plan d'évaluation des performances
– documentation utilisateur
– Verticalement : développement des modules
• Ex. : dès que la conception globale est validée :
– conception détaillée des modules
– programmation et tests unitaires
Critique des modèles cascade et en V
• Modèles parfois
difficiles à appliquer :
– difficile de prendre en
compte des changements
importants dans les
spécifications dans une
phase avancée du projet
– durée parfois trop longue
pour produits compétitifs
• Gestion du risque :
– trop de choses reportées à
l'étape de programmation
– pas assez de résultats
intermédiaires pour valider
la version finale du produit
Prototypage rapide
• Construit et utilisé lors des phases suivantes :
– analyse des besoins
– spécifications fonctionnelles
• Validation des spécifications par expérimentation
« Je saurai ce que je veux quand je le verrai ! »
• Client et développeur d'accord sur le produit
– nature, interface, fonctionnalités
– rapidité : réduction des allers-retours
Prototypage expérimental
• Construit et utilisé en phase de conception
– s'assurer de la faisabilité de parties critiques
– valider des options de conception
• Statut
– En général, jeté après développement
– Si gardé, alors s'appelle « prototype évolutif »
Prototypage évolutif
• Principe :
– Première version du proto = embryon du produit final
– On itère jusqu'au produit final

• Problèmes :
– difficulté à mettre en œuvre des procédures de
validation et de vérification
Modèle en spirale
• Enfin le modèle en spirale, de Boehm, 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
• 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.
Modèle en spirale
Modèle en spirale
• Chaque fois qu’on avance d’un cycle on va :
– Augmenter notre compréhension du domaine
– La qualité de notre solution
– Fait participer notre clients et sponsor
• Ils corrigent si on n’a pas bien compris leurs besoins
• Ou les fonctionnalités du système
Modèle en spirale
• Fait participer les client pendant toute la cycle de vie
• Tout les gens voient qu’il y a des avancement
• Elle n’est pas idéale
• Meilleure que le modèle en cascade car traite les
choses plusieurs fois
• Pas flexible car on doit suivre les étapes par ordre
• S’il y a des problèmes on l’ajourne jusqu’à la
prochaine cycle
Modèle en spirale : Risques et remèdes
• Les principaux risques sont les suivants :
– défaillance de personnel : embauches de haut niveau,
formation mutuelle, leaders, adéquation
profil/fonction, ...
– calendrier et budgets irréalistes : estimation
détaillée, développement incrémental, réutilisation,
élagage des besoins, ...
– développement de fonctions inappropriées : revues
d’utilisateurs, manuel d’utilisation précoce, ...
– développement d’interfaces utilisateurs
inappropriées : maquettage, analyse des tâches, .
Modèle en spirale : Risques et remèdes
– produit ‘plaqué or’ : analyse des coûts/bénéfices, conception tenant
compte des coûts, ...
– volatilité des besoins : développement incrémental de la partie la
plus stable d’abord, masquage d’information, ...
– problèmes de performances : simulations, modélisations, essais et
mesures, maquettage,
– exigences démesurées par rapport à la technologie : analyses
techniques de faisabilité, maquettage, ...
– tâches ou composants externes défaillants : audit des sous-
traitants, contrats, revues, analyse de compatibilité, essais et
mesures, ...
Modèle itérative
• Le modèle spirale nous oblige de finir chaque niveau avent
de passer au suivant
• Donc on a besoin d’un modèle qui nous permet d’itérer
pendant les phases: avancer, retarder, chaque fois qu’on a
besoin
• C’est le but du modèle itérative
Modèle itérative
• Mais toujours on a un problème
• Avec le modèle spirale et itérative on essaie
toujours de manger l’éléphant
• Donc on a besoin de l’ incrémentation
Prototypage et incrémentale
• Retours d'expérience avant version finale
– Dans l'industrie :
• prototype : premier d'une série
• maquette : modèle réduit (pas censé être opérationnel)
– En développement de logiciel :
• prototype rapide (ou « maquette »), opérationnel (mais
restreint), expérimental, évolutif
• Développement incrémental
– Ajouts successifs de nouvelles fonctionnalités sur une
base opérationnelle
Le modèle incrémental
• Chaque incrément peut donner lieu à un cycle de
vie classique plus ou moins complet.
• Les premiers incréments peuvent être des
maquettes (jetables)
• Ou des prototypes (réutilisables)
• Le risque de cette approche est celui de la remise
en cause du noyau.
Le modèle incrémental
• Il a été proposé dans les années 80
• Le produit est délivré en plusieurs fois, de
manière incrémentale, c’est à dire en le
complétant au fur et à mesure et en profitant de
l’expérimentation opérationnelle des incréments
précédents.
• Chaque incrément peut donner lieu à un cycle de
vie classique plus ou moins complet.
Le modèle incrémental

• On planifie de délivrer la version 1.0 de notre système


avec des fonctionnalités basique et cruciales
• Puis, on délivre la version 1.1 avec des fonctionnalités
additionnelles
• Après, on peut délivrer la version 2.0 avec des grandes
changement.
• Et ainsi de suite…
Le modèle incrémental

• C’est le modèle qui est le plus utilisée en pratique


• Il donne un peu de liberté
Les processus réels
• Il n’y a pas de modèle idéal car tout dépend des
circonstances.
• Le modèle en cascade ou en V est risqué pour les
développements innovants car les spécifications et la
conception risquent d’être inadéquats et souvent remis en
cause.
• Le modèle incrémental est risqué car il ne donne pas
beaucoup de visibilité sur le processus complet.
• Le modèle en spirale est un canevas plus général qui
inclut l’évaluation des risques.
Combiner les processus
• Au premier niveau on sait qu’on doit planifier pour une
succession des incrémentions

• Pour chaque incrément le modèle spirale suggère qu’on


doit au moins faire deux itérations

• Pour chaque spirale le modèle en cascade les phases et


l’ordre dans lequel on doit le réaliser
Combiner les processus
• Pour chaque mini-waterfal, le modèle itérative nous
permettre de répéter les phases ou la combinaison de
phases

• Le modèle itérative nous permettre de fixer les bugs des


que l’on trouve
Autres concepts liés aux processus
• La réingénierie des systèmes

– Il s’agit de “retraiter” ou de recycler des logiciels en


fin de vie.

– Les “vieux” logiciels sont un capital fonctionnel qui


peut être de grande valeur par leur conception et leur
architecture prouvées.
Autres concepts liés aux processus
• La réingénierie des systèmes
– Le code source est adaptable aux nouvelles
technologies :
• migration de chaînes de traitements batch vers du
transactionnel,
• fichiers à bases de données,
• intégration de composants standards (progiciels),
• migration de transactionnel vers du client-serveur
• migration du client-serveur vers des architectures à 3
niveaux

Vous aimerez peut-être aussi