1 modèles génériques dun processus de développement mustapha el feddi...
Post on 03-Apr-2015
105 Views
Preview:
TRANSCRIPT
2
Plan des cours
Les différents cycles de vie du logiciel
Les modèles linéaires
Les modèles itératifs
Autres modèles
Conclusion
3
Modèles génériques d’un processus de développement
Les différents cycles de vie du logiciel
4
Définition du cycle de vie du logiciel
Un cycle de vie d’un logiciel est un ordonnancement des différents étapes du processus de développement
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).
5
Modèles de cycles de vie Les modèles de cycle de vie du logiciel
décrivent à un niveau très abstrait et idéalisé des 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
6
Modèles génériques Modèles linéaires
modèle en cascade modèle en V
Modèles itératifs modèle de développement incrémental modèle de développement en spirale modèle par prototypage
prototypage jetable prototypage évolutif
Autres modèles
7
Modèles génériques d’un processus de développement
Modèle linéaires
8
Modèles linéaires: Modèle en cascade
Historiquement, la première tentative pour mettre de la rigueur dans le ‘développement sauvage’ (coder et corriger ou ‘code and fix’) a consisté à distinguer une phase d’analyse avant la phase d’implémentation (séparation des questions).
Analyse
Implémentation
9
Modèles linéaires: Modèle en cascade
Un plus grand nombre d’étapes étaient nécessaires pour organiser le développement des applications complexes
Il faut distinguer: l’analyse du ‘quoi faire ?’ qui doit être validée
par rapport aux objectifs poursuivis la conception du ‘comment faire?’ qui doit
être vérifiée pour sa cohérence et sa complétude.
10
Modèles linéaires: Modèle en cascadeLe modèle en cascade décrit cette succession d’étapes
qui sont représentées ici (Six étapes fondamentales)
ConceptionConception
ImplémentationImplémentationet tests unitaireset tests unitaires
ValidationValidationet tests d’intégrationet tests d’intégration
Exploitation Exploitation et maintenanceet maintenance
AnalyseAnalysedes besoinsdes besoins
Analyse Analyse du systèmedu système
Pas de validation intermédiaireHaut risque : erreurs coûteuses !
Peut être viable pour des « petits » projets(Taille + Nbre de participants)
11
Modèles linéaires: Modèle en cascade
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 et activités, ils sont soumis à une revue approfondie (on ne passe à la phase suivante que s'ils sont jugés
satisfaisants)
12
Modèles linéaires: Modèle en cascade Certaines phases portent le nom d'une activité
signifie que l'activité est essentielle pour cette phase, mais n'impose pas qu'elle n'ait lieu que dans cette étape.
D'autres activités interviennent, par exemple le contrôle technique et la gestion de la configuration, tout au long du processus.
Le modèle original ne comporte pas de possibilité de retour en arrière. a été rajoutée sur la base qu'une étape ne remet en
cause que l'étape précédente, ce qui, dans la pratique, s'avère insuffisant.
13
Modèles linéaires: Modèle en cascade
Même si on l’étend avec des possibilités de retour en arrière, idéalement limitées à la seule phase qui précède celle remise en cause, le développement reste fondamentalement linéaire.
ConceptionConception
ImplémentationImplémentationet tests unitaireset tests unitaires
AnalyseAnalysedes besoinsdes besoins
Analyse Analyse du systèmedu système
14
Modèles linéaires: Modèle en cascade
Ce modèle se fonde sur l’hypothèse souvent irréaliste que l’on peut dès le départ définir complètement et en détail ce qu’on veut réaliser (expressions des besoins). La pratique montre que c’est rarement le cas.
Même si elle n’est pas réaliste, cette représentation très simplifiée a permis de définir des cadres conceptuels et terminologiques, largement acceptés et normalisés par plusieurs organismes (ISO, AFNOR, IEEE, DOD pour les applications militaires aux USA, ESA, etc.)
Ceci facilite la gestion et le suivi des projets.
15
Modèles linéaires: Modèle en cascade
Étude préliminaire ou étude de faisabilité ou planification : (rapport d’analyse préliminaire ou schéma directeur) définition globale du problème, différentes stratégies possibles avec
avantages/inconvénients, ressources, coûts, délais.
16
Modèles linéaires: Modèle en cascade 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 (définition de ce que peuvent attendre les clients) et une partie destinée aux concepteurs (spécification des besoins).
17
Modèles linéaires: Modèle en cascade
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
18
Modèles linéaires: Modèle en cascade
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
19
Modèles linéaires: Modèle en cascade
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
20
Modèles linéaires: Modèle en cascade
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’)
21
Modèles linéaires: Modèle en cascade
Installation Mise en fonctionnement opérationnel
chez les utilisateurs. Parfois restreint dans un premier temps à des utilisateurs sélectionnés (‘beta testing’).
22
Modèles linéaires: Modèle en cascade
Maintenance : maintenance corrective (ou curative) maintenance adaptative maintenance perfective
23
Modèles linéaires: Modèle en cascade
Activités transversales à tout le cycle de vie Spécification Documentation validation et vérification management.
24
Modèles linéaires: Modèle en cascade
Des études ont été menées pour évaluer le coût des différentes étapes du développement
Type de système
Conception Implémentation Test
Gestion 44 28 28
Scientifique 44 26 30
Industriel 46 20 34
Mais c’est la maintenance qui coûte le plus cher.
25
Modèles linéaires: Modèle en V
Objectifs Validations intermédiaires pour prévenir les
erreurs tardives : meilleure planification et gestion
Principes du cycle de vie en V Processus linéaire Validation à chaque étape
Préparation des protocoles de validation finaux à chaque étape descendante
Validation finale montante et confirmation de la validation descendante
26
Modèles linéaires: Modèle en V avec toute décomposition doit être décrite la
recomposition, la préparation des dernières phases (validation-
vérification) est explicite par les premières (construction du logiciel)
toute description d'un composant est accompagnée de tests qui permettront de s'assurer qu'il correspond à sa description. permet ainsi d'éviter un écueil bien connu de la
spécification : énoncer une propriété qu'il est impossible de vérifier objectivement après la réalisation.
27
Modèles linéaires: Modèle en V
SpécificationsSpécifications
AnalyseAnalyseConceptionConception
ImplémentationImplémentation
MaintenanceMaintenance
Expression Expression des besoinsdes besoins
Validation Validation fonctionnellefonctionnelle
Validation Validation AnalyseAnalyse
Validation finaleValidation finale
validé parvalidé par Validation Validation besoinsbesoins
Validations des étapes intermédiaires sous forme de documentsValidations des étapes intermédiaires sous forme de documents
28
Modèles linéaires: Modèle en V On distingue donc deux sortes de dépendances :
enchaînement et itération : se déroulent essentiellement de gauche à droite
préparation des phases ultérieures
Par exemple à l'issue de la conception architecturale le protocole et les jeux de test de l'intégration doivent être complètement décrits.
29
Modèles linéaires: Modèle en V Conséquences :
obligation de concevoir les jeux de test et leurs résultats réflexion et retour sur la description en cours meilleure préparation de la branche droite du V
Les activités de chaque phase peuvent être réparties en 5 catégories : assurance qualité production contrôle technique gestion contrôle de qualité
30
Modèles linéaires: Modèle en V
SpécificationsSpécifications
AnalyseAnalyseConceptionConception
ImplémentationImplémentation
Expression Expression des besoinsdes besoins
Validation Validation fonctionnellefonctionnelle
Validation Validation AnalyseAnalyse
Validation finaleValidation finale
Validation Validation besoinsbesoins
Protocoles de validation définis par l’analyse descendanteProtocoles de validation définis par l’analyse descendante
Processus descendant
Val
idat
ion
mon
tant
e
31
Modèles linéaires: Modèle en V
intérêts Validations intermédiaires
bon suivi du projet : avancement éclairé et limitation des risques en cascade d’erreurs
favorise la décomposition fonctionnelle de l’activité
génération de documents et outils supports Modèle très utilisé et éprouvé
32
Modèles linéaires: Modèle en V
Limitations Un modèle séquentiel (linéaire)
manque d’adaptabilité maintenance non intégrée : logiciels à
vocation temporaire validations intermédiaires non formelles :
aucune garantie sur la non transmission d’erreurs
Un modèle adaptée aux problèmes si les besoins sont bien identifiés, l’analyse et
la conception sont claires
33
Modèles linéaires: Modèle en V
Améliorations Retours de correction des phases précédentes
Fonctionne si corrections limitées casser la linéarité : cycle de vie itératif
SpécificationsSpécifications
AnalyseAnalyseConceptionConception
ImplémentationImplémentation
Expression Expression des besoinsdes besoins
34
Modèles génériques d’un processus de développement
Modèle itératifs
35
Modèles itératifs: Modèle par incrément
Face aux dérives bureaucratiques de certains gros développements, et à l’impossibilité de procéder de manière aussi linéaire, le modèle incrémental a été proposé dans les années 80.
temps
Incrémentsdélivrés
36
Modèles itératifs: Modèle par incrément 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.
Les premiers incréments peuvent être des maquettes (jetables s’il s’agit juste de comprendre les besoins des utilisateurs) ou des prototypes (réutilisables pour passer au prochain incrément en les complétant et/ou en optimisant leur implantation).
Le risque de cette approche est celui de la remise en cause du noyau.
37
Modèles itératifs: Modèle par incrément
Différents des autres modèles où 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
38
Modèles itératifs: Modèle par incrément
Intérêts chaque développement est moins complexe
les intégrations sont progressives
possibilité de livraisons et de mises en service après chaque incrément
meilleur lissage du temps et de l'effort de développement à cause de la possibilité de recouvrement des différentes phases
39
Modèles itératifs: Modèle par incrément
Risques mettre en cause le noyau ou les incréments
précédents ne pas pouvoir intégrer de nouveaux incréments
Recommandations Le noyau, les incréments ainsi que leurs
interactions doivent donc être faites globalement, au début du projet
Les incréments doivent être aussi indépendants que possibles, fonctionnellement mais aussi sur le plan du calendrier du développement.
40
Modèles itératifs: Modèle par incrément
Modèle de développement incrémental
Identifie Identifie les incréments les incréments
Produit les Produit les incréments incréments
Evalue les Evalue les incrémentsincréments
Spécifie et implémenteSpécifie et implémenteles incréments les incréments
41
Modèles itératifs: Modèle en spirale Proposé par B. Boëhm en 1988, ce modèle général
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
42
Modèles itératifs: Modèle en spirale
AnalyseAnalyse
SpécificationsSpécificationsConceptionConception
ImplémentationImplémentation
ValidationValidation
TestsTests
V1.0 V1.3V1.1 V1.2
43
Modèles itératifs: Modèle en spirale
Les principaux risques et leurs remèdes, tels que définis par Boëhm
RisqueRisque RemèdeRemèdeDé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, …
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, ...
44
Modèles itératifs: Prototypage Idée : fournir rapidement un prototype
exécutable pour permettre une validation concrète (ici expérimentale) et non sur papier (document)
Progressions par incréments successifs de versions successives du prototype : itérations
Certains prototypes peuvent être « validés » par le client
Ne dispense pas de fournir des documents intermédiaires
45
Modèles itératifs: Prototypage jetable
Spécification Spécification schématiqueschématique
Codage duCodage duprototypeprototype
Evaluation duEvaluation duprototype prototype
Spécification Spécification du systèmedu système
Modèle gérable d’un point de vue changement des spécifications
Les spécifications sont générées par prototypage
46
Modèles itératifs: Prototypage évolutif
Spécification Spécification schématiqueschématique
Codage duCodage duprototypeprototype
Evaluation duEvaluation duprototype prototype
Acceptation Acceptation du systèmedu système
Modèle difficile à gérer
47
Modèles itératifs: Intérêts
Validation plus concrète (pas sur document)
Correction à chaque itération : risques limités et flexibilité modification des spécifications maintenance
Client impliqué dès le début : Besoins du client apparaissent progressivement
(et pas la veille de la livraison) Meilleure Planification
une nouvelle itération
48
Modèles itératifs: Intérêts
Processus itératif Adapté à une démarche incrémentale
Modèle de programmation orientée objet Nécessitant une planification rigoureuse
et ne supportant pas l’improvisation Planification supportant abstraction et
raffinements successifs Ayant une portée générale
49
Modèles génériques d’un processus de développement
Autres modèles
50
Autres modèles: Transformationnels
Spécification Spécification formelleformelle
TransformationTransformationcorrectecorrecte
SpécificationSpécificationformelle concrète formelle concrète
Génération de Génération de codecode
ProgrammeProgrammecorrectecorrecte
Modèle gérable Difficile à mettre en œuvre : Passage du formel au concret =>nécessite de connaissances
avancées (techniques et formelles)
51
Autres modèles: Hybrides
Principe : Système complexe = composition de
sous-systèmes Utilisation d’un processus de
développement adapté à chaque sous-systèmes Utilisation du modèle à chute d’eau pour les
sous-systèmes bien connus Utilisation du modèle de prototypage évolutif
pour les sous-systèmes « délicats »
52
Conclusion 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.
Souvent, un même projet peut mêler différentes approches, comme le prototypage pour les sous-systèmes à haut risque et la cascade pour les sous systèmes bien connus et à faible risque.
53
Questions Citer les différentes étapes du processus de
développement d’un logiciel
Donner une définition d’un Cycle de vie
Citer quelques exemples de cycles de vie d’un logiciel
top related