Modèles génériques d’un processus de développement

Présentation au sujet: "Modèles génériques d’un processus de développement"— Transcription de la présentation:

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

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

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

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 Scientifique 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écifications Analyse Conception Implémentation Maintenance Expression des besoins Validation fonctionnelle Validation finale validé par besoins Validations 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écifications Analyse Conception Implémentation Expression des besoins Validation fonctionnelle Validation finale besoins Protocoles de validation définis par l’analyse descendante Processus descendant Validation montante

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écifications Analyse Conception Implémentation Expression des 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. Incréments délivrés temps

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 les incréments Produit les incréments Evalue les Spécifie et implémente

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
Analyse Conception Spécifications V1.0 V1.1 V1.2 V1.3 Implémentation Validation Tests

43 Modèles itératifs: Modèle en spirale
Les principaux risques et leurs remèdes, tels que définis par Boëhm Risque Remède 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, … 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 schématique Codage du prototype Evaluation du prototype Modèle gérable d’un point de vue changement des spécifications Les spécifications sont générées par prototypage Spécification du système

46 Modèles itératifs: Prototypage évolutif
Spécification schématique Codage du prototype Evaluation du prototype Acceptation du 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 formelle Transformation correcte Spécification formelle concrète Modèle gérable Difficile à mettre en œuvre : Passage du formel au concret => nécessite de connaissances avancées (techniques et formelles) Génération de code Programme correcte

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