Plan des cours

1. 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

2. Modèles génériques d’un processus de développement Les différents cycles de vie du logiciel

3. 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).

4. 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

5. 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

6. Modèles génériques d’un processus de développement Modèle linéaires

7. 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

8. 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.

9. 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

10. 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)

11. 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.

12. 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

13. 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.

14. 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.

15. 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).

16. 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

17. 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

18. 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

19. 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’)

20. 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’).

21. Modèles linéaires: Modèle en cascade • Maintenance : • maintenance corrective (ou curative) • maintenance adaptative • maintenance perfective

22. Modèles linéaires: Modèle en cascade • Activités transversales à tout le cycle de vie • Spécification • Documentation • validation et vérification • management.

23. 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 Mais c’est la maintenance qui coûte le plus cher.

24. 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

25. 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.

26. validé par Validation besoins Expression des besoins Validation fonctionnelle Spécifications Analyse Conception Validation Analyse Implémentation Validation finale Maintenance Validations des étapes intermédiaires sous forme de documents Modèles linéaires: Modèle en V

27. 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.

28. 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é

29. Validation besoins Expression des besoins Processus descendant Validation montante Validation fonctionnelle Spécifications Analyse Conception Validation Analyse Implémentation Validation finale Protocoles de validation définis par l’analyse descendante Modèles linéaires: Modèle en V

30. 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é

31. 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

32. Expression des besoins Spécifications Analyse Conception Implémentation 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

33. Modèles génériques d’un processus de développement Modèle itératifs

34. 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

35. 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.

36. 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

37. 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

38. 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.

39. Identifie les incréments Spécifie et implémente les incréments Produit les incréments Evalue les incréments Modèles itératifs: Modèle par incrément • Modèle de développement incrémental

40. 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

41. Modèles itératifs: Modèle en spirale Analyse Conception Spécifications V1.0 V1.2 V1.1 V1.3 Implémentation Validation Tests

42. Modèles itératifs: Modèle en spirale Les principaux risques et leurs remèdes, tels que définis par Boëhm

43. 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

44. 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

45. 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

46. 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

47. 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

48. Modèles génériques d’un processus de développement Autres modèles

49. 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

50. 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 »