La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

1 Modèles génériques dun processus de développement Mustapha EL FEDDI

Présentations similaires


Présentation au sujet: "1 Modèles génériques dun processus de développement Mustapha EL FEDDI"— Transcription de la présentation:

1 1 Modèles génériques dun processus de développement Mustapha EL FEDDI

2 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 3 Modèles génériques dun processus de développement Les différents cycles de vie du logiciel

4 4 Définition du cycle de vie du logiciel Un cycle de vie dun logiciel est un ordonnancement des différents étapes du processus de développement Comme pour toutes les fabrications, il est important davoir un procédé de fabrication du logiciel bien défini et explicitement décrit et documenté. En GL, il sagit dun type de fabrication un peu particulier : en un seul exemplaire, car la production en série est triviale (recopie).

5 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 dorganiser la production. Les étapes, leur ordonnancement, et parfois les critères pour passer dune étape à une autre sont explicités critères de terminaison dune étape revue de documents critères de choix de létape suivante critères de démarrage dune étape

6 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 7 Modèles génériques dun processus de développement Modèle linéaires

8 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 danalyse avant la phase dimplémentation (séparation des questions). Analyse Implémentation

9 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: lanalyse 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 10 Modèles linéaires: Modèle en cascade Le modèle en cascade décrit cette succession détapes qui sont représentées ici (Six étapes fondamentales) Conception Implémentation et tests unitaires Validation et tests dintégration Exploitation et maintenance Analyse des besoins Analyse du système Pas de validation intermédiaire Haut risque : erreurs coûteuses ! Peut être viable pour des « petits » projets (Taille + Nbre de participants)

11 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 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 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. Conception Implémentation et tests unitaires Analyse des besoins Analyse du système

14 14 Modèles linéaires: Modèle en cascade Ce modèle se fonde sur lhypothèse souvent irréaliste que lon peut dès le départ définir complètement et en détail ce quon veut réaliser (expressions des besoins). La pratique montre que cest rarement le cas. Même si elle nest 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 15 Modèles linéaires: Modèle en cascade Étude préliminaire ou étude de faisabilité ou planification : (rapport danalyse 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 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é dutilisation, 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 17 Modèles linéaires: Modèle en cascade Analyse du système : (dossier danalyse + plan de validation) modélisation du domaine modélisation de lexistant (éventuellement) définition dun modèle conceptuel (ou spécification conceptuelle) plan de validation

18 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 lanalyse organisation de lapplication 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 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 dessais par module selon le plan de test

20 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 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 22 Modèles linéaires: Modèle en cascade Maintenance : maintenance corrective (ou curative) maintenance adaptative maintenance perfective

23 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 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 ConceptionImplémentationTest Gestion4428 Scientifique Industriel Mais cest la maintenance qui coûte le plus cher.

25 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 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 27 Modèles linéaires: Modèle en V Spécifications AnalyseConception Implémentation Maintenance Expression des besoins Validationfonctionnelle ValidationAnalyse Validation finale validé par Validationbesoins Validations des étapes intermédiaires sous forme de documents

28 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 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 30 Modèles linéaires: Modèle en V Spécifications AnalyseConception Implémentation Expression des besoins Validationfonctionnelle ValidationAnalyse Validation finale Validationbesoins Protocoles de validation définis par lanalyse descendante Processus descendant Validation montante

31 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 derreurs favorise la décomposition fonctionnelle de lactivité génération de documents et outils supports Modèle très utilisé et éprouvé

32 32 Modèles linéaires: Modèle en V Limitations Un modèle séquentiel (linéaire) manque dadaptabilité maintenance non intégrée : logiciels à vocation temporaire validations intermédiaires non formelles : aucune garantie sur la non transmission derreurs Un modèle adaptée aux problèmes si les besoins sont bien identifiés, lanalyse et la conception sont claires

33 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écifications AnalyseConception Implémentation Expression des besoins

34 34 Modèles génériques dun processus de développement Modèle itératifs

35 35 Modèles itératifs: Modèle par incrément Face aux dérives bureaucratiques de certains gros développements, et à limpossibilité de procéder de manière aussi linéaire, le modèle incrémental a été proposé dans les années 80. temps Incréments délivrés

36 36 Modèles itératifs: Modèle par incrément Le produit est délivré en plusieurs fois, de manière incrémentale, cest à dire en le complétant au fur et à mesure et en profitant de lexpé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 sil sagit 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 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 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 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 40 Modèles itératifs: Modèle par incrément Modèle de développement incrémental Identifie les incréments Produit les incréments Evalue les incréments Spécifie et implémente les incréments

41 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 42 Modèles itératifs: Modèle en spirale Analyse Spécifications Conception Implémentation Validation Tests V1.0 V1.3V1.1 V1.2

43 43 Modèles itératifs: Modèle en spirale Les principaux risques et leurs remèdes, tels que définis par Boëhm RisqueRemède Défaillance de personnelEmbauches de haut niveau, formation mutuelle, leaders, adéquation profil/fonction, … Calendrier et budgets irréalistesEstimation détaillée, développement incrémental, réutilisation, élagage des besoins, … Développement de fonctions inappropriéesRevues dutilisateurs, manuel dutilisation précoce,... Développement dinterfaces utilisateurs inappropriées Maquettage, analyse des tâches, … Volatilité des besoinsDéveloppement incrémental de la partie la plus stable dabord, masquage dinformation,... Problèmes de performancesSimulations, 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éfaillantsAudit des sous-traitants, contrats, revues, analyse de compatibilité, essais et mesures,...

44 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 45 Modèles itératifs: Prototypage jetable Spécificationschématique Codage du prototype Evaluation du prototype Spécification du système Modèle gérable dun point de vue changement des spécifications Les spécifications sont générées par prototypage

46 46 Modèles itératifs: Prototypage évolutif Spécificationschématique Codage du prototype Evaluation du prototype Acceptation du système Modèle difficile à gérer

47 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 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 limprovisation Planification supportant abstraction et raffinements successifs Ayant une portée générale

49 49 Modèles génériques dun processus de développement Autres modèles

50 50 Autres modèles: Transformationnels SpécificationformelleTransformationcorrecteSpécification formelle concrète Génération de code Programmecorrecte Modèle gérable Difficile à mettre en œuvre : Passage du formel au concret => nécessite de connaissances avancées (techniques et formelles)

51 51 Autres modèles: Hybrides Principe : Système complexe = composition de sous-systèmes Utilisation dun processus de développement adapté à chaque sous- systèmes Utilisation du modèle à chute deau pour les sous-systèmes bien connus Utilisation du modèle de prototypage évolutif pour les sous-systèmes « délicats »

52 52 Conclusion Il ny 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 53 Questions Citer les différentes étapes du processus de développement dun logiciel Donner une définition dun Cycle de vie Citer quelques exemples de cycles de vie dun logiciel


Télécharger ppt "1 Modèles génériques dun processus de développement Mustapha EL FEDDI"

Présentations similaires


Annonces Google