Djamel-Abdelhak SERIAI seriai@ensm-douai.fr csl.ensm-douai.fr/seriai

1. Développement de Systèmes Informatiques Orientés objets en UMLÉléments du génie logiciel, du paradigme objet et de la notation unifiée Djamel-Abdelhak SERIAI seriai@ensm-douai.fr http://csl.ensm-douai.fr/seriai

2. Objectifs du cours • Le Logiciel et le Génie logiciel • C’est quoi le problème ? • Cycle de vie d’un logiciel • Les méthodes de développement (SADT, Merise, …,UML...?) • Les concepts objet à travers UML • Le paradigme objet • Notation UML des concepts objet • La notation UML pas à pas • Les différents diagrammes • Des exemples • Le langage OCL (?) • Des travaux pratiques pour maîtriser UML • Les outils CASE • Développement d’un exemple complet

3. Organisation du cours • Organisation du cours Le logiciel et Le Génie logiciel Approche objet et UML Notation UML Notation UML TP UML un exemple de A à Z Un outil CASE (AGL) 20/01 22/01 27/01 03/02 24/02 26/02 Cours TP

4. Partie I : Le Logiciel et le Génie logiciel

5. Logiciel et Génie logiciel • Introduction en image : Informatique et logiciels

6. Logiciel et Génie logiciel • Logiciel et processus de développement Fonctions réalisées dans un environnement suivant certaines exigences (performance, sûreté, etc.) Service Produit Processus Caractéristiques Du système : Structure, adaptabilité, Complexité, etc. Organisation des moyens, procédures, méthodes et Outils pour développer et valider le produit

7. Logiciel et Génie logiciel • Caractéristiques d’un produit logiciel • Un logiciel est un produit (manufacturé) comme une voiture ou une machine à outils • Procédé de fabrication : processus de développement • Un logiciel est un produit avec des caractéristiques particulières • Pas de problème de fabrication en série • La reproduction d’un logiciel se fait par simple copie • Processus de développement itératif : certaines étapes peuvent déclencher la révision des étapes précédentes : • La détection d’une erreur lors d’un test va déclencher un retour sur la programmation, peut-être la conception voir même la spécification • Le procédé de fabrication d’un logiciel est invisible • pour pallier au problème de l'invisibilité, il donne lieu à la production de documents intermédiaires permettant de contrôler un logiciel en cours de développement

8. Logiciel et Génie logiciel • Caractéristiques d’un produit logiciel • Un logiciel est un produit avec des caractéristiques particulières • Le processus de développement se poursuivi après la livraison du logiciel, pour la maintenance • Après son développement un produit logiciel est mis en exploitation et entre dans une phase de maintenance qui peut remettre en cause les fonctions du système et impliquer des modifications et/ou un re-développement • La correction des défauts : maintenance corrective • Adaptation du logiciel à un nouvel environnement : maintenance adaptative • Amélioration des caractéristiques et suivi de l’évolution des besoins : maintenance perfective

9. Logiciel et Génie logiciel • La crise du logiciel • Quelques constats de l'ampleur de l'impact des défaillances : • la sonde Mariner vers Vénus s'est perdue dans l'espace à cause d'une erreur de programme FORTRAN ; • en 1972, lors d'une expérience météorologique en France 72 ballons contenant des instruments de mesure furent détruits à cause d'un défaut dans le logiciel ; • en 1981, le premier lancement de la navette spatiale a été retardé de deux jours à cause d'un problème logiciel. La navette a d'ailleurs été lancé sans que l'on ait localisé exactement le problème (mais les symptômes étaient bien délimités) ; • le développement du compilateur PL1 de Control Data n'a jamais abouti ;

10. Logiciel et Génie logiciel • La crise du logiciel • Quelques constats de l'ampleur de l'impact des défaillances : • EDF a récemment renoncé à la mise en service de nouveaux systèmes de contrôle-commande de ses centrales 1400 méga-watts • la SNCF a rencontré des difficultés importantes pour la mise en service du système Socrate • l'explosion d'Ariane 5, le 4 juin 1996, qui a coûté un demi milliard de dollars (non assuré !), est dûe à une faute logicielle d'une composante dont le fonctionnement n'était pas indispensable durant le vol • Pourquoi : manque de méthodologie de développement des produits logiciels

11. Logiciel et Génie logiciel • La crise du logiciel • Prise de conscience : • La première reconnaissance publique de la crise du logiciel a été faite lors d’une conférence à Garmisch • Les symptômes les plus caractéristiques de cette crise sont : • Les logiciels réalisés ne correspondent souvent pas aux besoins des utilisateurs • Les logiciels contiennent trop d’erreurs (qualité du logiciel insuffisante) • Les coûts de développement sont rarement prévisibles et sont généralement prohibitifs • La maintenance des logiciels est une tâche complexe et coûteuse • Les délais de réalisation sont généralement dépassés • Les logiciels sont rarement portables

12. Logiciel et Génie logiciel • La crise du logiciel • Prise de conscience : • Comparer l’évolution du coût du logiciel et du matériel : • Le coût du matériel baisse régulièrement; • Le matériel devient de plus en plus puissant, conduisant à la réalisation de logiciels de plus en plus complexes et donc coûteux • Le coût des logiciels représenterait actuellement 85 % des dépenses totales des systèmes informatiques

13. Logiciel et Génie logiciel • La crise du logiciel • Quelques sources de la crise • Une idée grossière du logiciel à réaliser est suffisante pour commencer d’écrire un programme (il est assez tôt de se préoccuper des détails plus tard). • Faux : une idée imprécise du logiciel à réaliser est la cause principale d’échecs • Une fois que le programme est écrit et fonctionne, le travail est terminé. • Faux : la maintenance du logiciel représente un travail important : le coût de la maintenance représente plus du 50 % du coût total d’un logiciel

14. Logiciel et Génie logiciel • La crise du logiciel • Quelques sources de la crise • Si les spécifications du logiciel à réaliser changent continuellement, cela ne pose pas de problème, puisque le logiciel est un produit souple • Faux : des changements de spécifications peuvent se révéler coûteux et prolonger les délais • Si la réalisation du logiciel prend du retard par rapport aux délais prévus, il suffit d’ajouter plus de programmeurs afin de finir dans les délais. • Faux : si l’on ajoute de gens à un projet, il faut compter une période de familiarisation. Le temps passé à communiquer à l’intérieur du groupe augmente également, lorsque la taille du groupe augmente

15. Logiciel et Génie logiciel • Le génie logiciel • Est un domaine de recherche qui a été défini (fait rare) du 7 au 11 octobre 1968, à Garmisch-Partenkirchen, sous le parrainage de l'OTAN. • Le génie logiciel est la discipline née en réponse à la crise du logiciel. • Le génie logiciel se caractérise par une approche rigoureuse et systématique à la construction de logiciels ne pouvant être maîtrisés par une seule personne. • Le génie logiciel est donc l'art : • De spécifier, de concevoir, de réaliser, et de faire évoluer des programmes, des documentations et des procédures de qualité • Avec des moyens et dans des délais raisonnables, en vu d'utiliser un système informatique pour résoudre certains problèmes.

16. Logiciel et Génie logiciel • Le génie logiciel • Objectif du génie logiciel • Optimiser le coût de développement du logiciel. • L'importance d'une approche méthodologique s'est montrée par la crise de l'industrie du logiciel à la fin des années 60 : • augmentation des coûts ; • difficultés d'évolution ; • non fiabilité ; • non respect des spécifications ; • non respect des délais.

17. Logiciel et Génie logiciel • Cycle de vie de logiciel • Dans la réalisation d'un programme simple, fait par une personne, il est possible de distinguer 3 phases: • la phase d'analyse du problème; • la phase de codage et de mise au point; • la phase d'opération (le programme est opérationnel). • Cette approche n'est pas appropriée pour un projet important impliquant plusieurs personnes. • Dans un tel cas il est nécessaire de distinguer plus de phases

18. Projet abondonné non Pré-analye Pourquoi ? Oui Quoi ? Pécification Cahier des charges Comment ? Conception Décopage du logiciel en modules Impémentation Code Test Logiciel opérationnel Maintenance Logiciel et Génie logiciel • Cycle de vie de logiciel • L'approche traditionnelle distingue 6 phases dans la vie du logiciel • La phase de pré-analyse : étude d'opportunité; • La phase de spécification (software requirements) :l'analyse des besoins ; • La phase de conception (software design): la spécification globale, la conception architecturale et détaillée. • La phase d'implémentation : la programmation • La phase de test : la validation et vérification • La phase de maintenance, la gestion de configuration et intégration.

19. Logiciel et Génie logiciel • Cycle de vie de logiciel • La phase de pré-analyse • Précède le développement proprement dit et répond à la question pourquoi: • Pourquoi faut-il réaliser un certain logiciel, quels sont les besoins? • Quelques autres questions typiques à se poser durant cette phase : • Pourquoi a-t-on besoin du logiciel? • Y a-t-il de meilleures alternatives? • Le logiciel sera-t-il satisfaisant pour les utilisateurs? • Y a-t-il un marché pour le logiciel? • Quelles sont les ressources nécessaires pour réaliser le logiciel (budget, personnel, matériel). • La réponse de la phase de pré-analyse est oui ou non: • Oui, la décision est prise de réaliser le logiciel; • Non, le projet est abandonné.

20. Logiciel et Génie logiciel • Cycle de vie de logiciel • Analyse des besoins • But : • La phase de spécification répond à la question quoi ? • Eviter de développer un logiciel non adéquat • Permettre de définir précisément quelles sont les fonctions à réaliser par le logiciel. • Exemple : Si l'on considère un logiciel effectuant le paiement des salaires dans une entreprise, la phase de spécification permettra de répondre notamment aux questions suivantes : • Les employés sont-ils enregistrés sur bande ou sur disque? • Quel est le format de chaque enregistrement du fichier? • Quel est le format des sorties? • Etc.

21. Logiciel et Génie logiciel • Cycle de vie de logiciel • Analyse des besoins • Entrée: • données fournies par des experts du domaine d'application et les futurs utilisateurs • Méthodes: • Il faut surtout établir un dialogue avec les experts du domaine, qui ne sont pas forcément des informaticiens, • Utiliser des méthodes plutôt cognitives : entretiens, questionnaires, observations de l'existant, études de situations similaires • Démarche : pour établir les besoins (le cahier des charges), il faut étudier le domaine d'application ; • l'état actuel de l'environnement du futur système ; • le rôle du système ; • les ressources disponibles et requises ; • les contraintes d'utilisation ; • les performances attendues ; …

22. Logiciel et Génie logiciel • Cycle de vie de logiciel • Analyse des besoins • Lien : Cette activité doit être menée en liaison avec les études de faisabilité et la planification, et doit se poursuivre durant tout le processus de développement. • Résultat: Le cahier des charges du logiciel (spécification des besoins, software requirement specification) • Documents décrivant • l'environnement du futur système • son rôle • son utilisation (manuel d'utilisation préliminaire) • si nécessaire, partage entre matériel et logiciel • Durée : Peut se poursuivre durant tout le cycle de vie (maintenance évolutive).

23. Logiciel et Génie logiciel • Cycle de vie de logiciel • Conception architecturale, détaillée : Spécification globale • Remarque : la spécification globale est souvent regroupée dans la même étape que la spécification des besoins. • But : • établir une première description du futur système • répondre à la question comment: comment réaliser le logiciel défini par le cahier des charges • Entrée: • analyse des besoins + considérations techniques et faisabilité informatique • Méthodes: • SADT, SART, MERISE, UML, ...

24. Logiciel et Génie logiciel • Cycle de vie de logiciel • Conception architecturale, détaillée : Spécification globale • Résultat: • modèle conceptuel pour produire une description de ce que doit faire le système mais sans préciser comment il le fait (on précise le quoi mais pas le comment). • complément au manuel d'utilisation • manuel de référence préliminaire • Remarque • Cette activité ne fait pas apparaître de choix d'implémentation.

25. Logiciel et Génie logiciel • Cycle de vie de logiciel • Conception architecturale, détaillée : Spécification globale • Techniques de spécification • Énonces informels • description en langage naturel pouvant respecter des plans types (standardisés ou propres à une entreprise ou à un projet) • Risque de non-cohérence, d'ambiguïté, de non complétudes, de difficulté d'organisation et de redondance d'informations • Présentations formatées • Dictionnaire de données ou glossaire : - spécification de l'ensemble des données utilisées en analyse et en conception - définition des termes, sigles, codes, symboles, synonymes et alias - peut utiliser des notations syntaxique strictes de forme Backus-Naur

26. Logiciel et Génie logiciel • Cycle de vie de logiciel • Conception architecturale, détaillée : Spécification globale • Techniques de spécification • Table de décision : • correspondance entre les valeurs d'entrée et les valeurs de sortie d'un processus (adaptée à la définition des systèmes finis). • Table états-transitions : • table des états et, pour chaque état les événements qui provoquent la transition à un autre état, les actions à effectuer et l'état suivant pour chaque transition. Peut être représentée par une matrice. • Techniques graphiques ou semi-formelles : Représentation graphique formelle accompagnée de textes informels • Modèle entité-association

27. Logiciel et Génie logiciel • Cycle de vie de logiciel • Conception architecturale, détaillée : Spécification globale • Techniques de spécification • Techniques graphiques ou semi-formelles : • Diagrammes de flots de données DFD : montrent comment chaque processus transforme les données qu'il reçoit entrée pour générer celle qu'il produit en sortie. • Diagrammes de structures : description du système sous forme de hiérarchie de fonctions. La notation permet d'exprimer les appels de fonctions, les paramètres (entrées, sorties, contrôle), les structures itératives et alternatives. • Diagrammes états-transitions : semblables (et complémentaires) aux tables états-transitions.

28. Logiciel et Génie logiciel • Cycle de vie de logiciel • Conception architecturale, détaillée : Spécification globale • Techniques de spécification • Techniques graphiques ou semi-formelles : • Réseaux de Petri et : un réseau de Petri est un outil mathématique très général permettant de modéliser le comportement d'un système dynamique à des événements discrets. • Grafcet: le Graphset, inspiré des réseaux de Petri, est un outil de spécification des automates logiques fréquemment utilisé en automatique. • Techniques formelles • Langage B • Langage Z • Etc.

29. Logiciel et Génie logiciel • Cycle de vie de logiciel • Conception architecturale, détaillée : • But • Définir l’architecture logicielle par l’établissement d’une description très proche du système à réaliser. • Répartition des entités (ou des fonctions) identifiées dans la spécification sur une architecture matérielle et logicielle • Décomposer le logiciel en composants plus simples, définis par leurs interfaces et leurs fonctions (les services qu'ils rendent) • Choix d’algorithmes • Démontrer que la spécification est correctement décrite • Cohérence entre description, spécification et conception • Comportement • Propriétés

30. Logiciel et Génie logiciel • Cycle de vie de logiciel • Conception architecturale, détaillée : • Documents d’entrée • Document de spécification : les spécifications globales + contraintes d'implémentation • Entités • Description des comportements locaux • Description des comportement globaux • Documents de sortie • Documents de conception générale (ou préliminaire) • Description des modules • Description des interfaces entre modules • Traçabilité avec la spécification • Plans de test d’intégration • Document de conception détaillée • Plan de test unitaire

31. Logiciel et Génie logiciel • Cycle de vie de logiciel • Conception architecturale, détaillée : • Méthodes: • Enrichir la description du système de détails d'implémentation. Deux étapes: • conception architecturale :décomposer le logiciel en composants plus simples en terme de fonctions et interfaces • conception détaillée : description de chaque composant: algorithmes, structure des données, ... • Résultat : Modèle d'implémentation: • Architecture du système et spécification des composants • Algorithmes et modèle des données (entité-association) • Selon la nature de la conception: • Fonctionnelle: modèles par flux de données: DFD, Contexte, AFD, structure, Petri, ... • Objets: diagrammes UML • ...

32. Logiciel et Génie logiciel • Cycle de vie de logiciel • Conception architecturale, détaillée • Démarche de conception • Conception de l'architecture : identifier les sous-systèmes et leurs relations • Spécification abstraite : pour chaque sous-système produire une spécification abstraite des services qu'il offre et des contraintes auxquelles il est soumis • Conception de l'interface : pour chaque sous-système, concevoir et documenter (de manière claire) l'interface avec les autres sous-systèmes • Conception des composants de chaque sous-système • Conception détaillée des structures de données • Conception détaillée des algorithmes

33. Logiciel et Génie logiciel • Cycle de vie de logiciel • Conception architecturale, détaillée : • Quelques critères mesurant la qualité de la conception • Cohésion • Une composante (module) doit implanter une seule entité logique. • Toutes les parties de cette composante doivent contribuer à cette implantation. • Ainsi dans un système (logiciel) chaque composante résout une partie du problème. • Couplage • Est relatif à la cohésion : • Il exprime le degré d'interconnexion des différents composants d'un système. • Un couplage fort (partage de données, échange d'informations de contrôle, etc.) implique des difficultés d'entretien.

34. Logiciel et Génie logiciel • Cycle de vie de logiciel • Conception architecturale, détaillée : • Quelques critères mesurant la qualité de la conception • Compréhensibilité : La compréhensibilité d'un module dépend de : • sa cohésion ; • l'appellation : utilisation de noms significatifs ; • la documentation : établir un lien entre le monde réel et le composant • Complexité • une composante complexe nécessite un effort de documentation supplémentaire • Adaptabilité • L'adaptabilité dépend du couplage et de la documentation. • Une conception ou un logiciel adaptable doit avoir un haut degré de lisibilité : fournir plusieurs représentations, cohérentes avec l'implantation, à différents niveaux d'abstraction. • Les modifications doivent être faciles à incorporer sur tous les niveaux pour ne pas avoir des problèmes d'incohérence.

35. Logiciel et Génie logiciel • Cycle de vie de logiciel • Programmation • But : • Réalisation, à partir de la conception détaillée, d'un ensemble de programmes ou de composants de programmes • Projection des concepts du modèle sur un langage de programmation. • Il s’agit d’un processus manuel • Entrée: • conception détaillée + contraintes de l'environnement de programmation • Résultat: documents décrivant: • code source de chaque module • directives: compilation, liens, ... • documentation d'implémentation

36. Logiciel et Génie logiciel • Cycle de vie de logiciel • Programmation • Méthodes: • Automatique : Dans certains cas, cette étape peut être automatisée (génération automatique de code) • Manuel : • En général le modèle statique contient tout ou partie de la structure déclarative - En approche fonctionnelle, il faut projeter le dictionnaire des données (interfaces des fonctions) sur les variables et les fonctions sur des procédures. - En approche objet :passage du modèle objet au langages objets manuel ou dérivation du code (par exemple génération des classes à partir des class diagrams) et nécessité d’implanter manuellement les associations et agrégations • L’implantation de la dynamique est réalisée en traduisant les diagrammes d’états (state charts) en structure de contrôle

37. Logiciel et Génie logiciel • Cycle de vie de logiciel • Validation et vérification • But de cette activité est de s'assurer de l'adéquation du système produit face aux besoins et spécifications • Spécifions-nous le bon système c'est à dire un système correspondant aux attentes des utilisateurs et respectant les contraintes de leur environnement? celui qui répond à l'attente des utilisateurs ? • Elle consiste essentiellement en des revues et inspections de spécifications ou de manuels et du prototypage rapide • Entrée: documents produits par l'ensemble des étapes précédentes

38. Logiciel et Génie logiciel • Cycle de vie de logiciel • Validation et vérification • Méthodes : • examens des spécifications, programmes, preuves, tests • test unitaire , test d'intégration et test système • on distingue : • tests statiques: examen ou analyse du texte des programme • tests dynamiques : consiste en l'exécutions du logiciel sur un sous-ensemble des données permettant de vérifier tous les chemins d'accès logiques et la plage de validité des données et en particulier les conditions limites • Résultat: documents décrivant: • opérations effectuées • acceptation ou non

39. Logiciel et Génie logiciel (?) • Cycle de vie de logiciel • Gestion de configurations et intégration • But : obtenir tout ou partie exécutable du système. • L'intégration a pour but de réaliser un ou plusieurs systèmes exécutables à partir des composants. Les choix possibles correspondent à des variantes du système • Entrée: les composants + description des configurations • Méthodes: gérer les composants du système, leur évolution, leur mise à jour, leur intégration • Résultat: documents décrivant: • les exécutables • les configurations

40. Logiciel et Génie logiciel • Cycle de vie de logiciel • La phase de maintenance • Commence une fois le logiciel est opérationnel • On distingue dans cette phase: • la maintenance corrective , qui s'occupe de corriger les erreurs découverts une fois le logiciel remis au client • la maintenance adaptative qui adapte le logiciel à un environnement (logiciel et matériel) qui évolue • par exemple adaptation d'un logiciel à une nouvelle version d'un système d'exploitation • la maintenance perfective , qui s'occupe d'étendre le logiciel pour y inclure de nouvelles possibilités, de nouvelles fonctions, etc.

41. Pré-analye Pécification Conception Impémentation Test Maintenance Logiciel et Génie logiciel • Cycle de vie de logiciel • Cycle avec retour • Inconvénient d’un cycle sans retour • Le cycle de vie sans retour est trop simpliste pour plusieurs raisons: • Plus on avance dans le projet, plus on le maîtrise, et donc plus on a tendance à revenir sur certains choix faits alors que l'ensemble du projet était moins bien cerné • Lors de la spécification d'un logiciel, certaines considérations sur l'implémentation peuvent être utiles. A défaut, certains aspects du cahier des charges pourraient être irréalistes (il s'agit donc ici de l'anticipation partielle d'une phase future); • Certaines spécifications (c'est-à-dire certains aspects du cahier des charges) peuvent changer en cours de projet, parce que le client change d'avis.

42. Logiciel et Génie logiciel • Cycle de vie de logiciel • Répartition de l’effort • Dans un projet « bien conduit », l'effort se répartit comme suit : • 15 à 20% programmation, • 40% spécification et conception, • 40% validation et vérification. spécification 20 % Développemet 40 % Test 40 % Test et Maintenance 60% conception 20 % Maintenance 20 %

43. Logiciel et Génie logiciel • Cycle de vie de logiciel • Les approches alternatives de développement de logiciels • Prototypage rapide (rapid prototyping) • Un prototype est à un logiciel n'implémentant que les aspects les plus importants du logiciel final et permettant ainsi de tenir compte des réactions de l'utilisateur avant de développer le produit définitif • Langages de très haut niveau • Permet de produire rapidement des logiciels ayant de plus peu d'erreurs • Les applications de gestion sont un domaine typique où ces méthodes semblent particulièrement adaptées; • Exemple: le langage HIBOL, adapté aux applications de gestion. • Réutilisation de logiciel • Il s'agit ici de constituer une bibliothèque de modules. Lors de la réalisation d'un nouveau logiciel, on cherchera le plus possible à utiliser des modules existants. • cette méthode ne s'applique pas lorsqu'il s'agit de réaliser un logiciel dans un domaine relativement neuf.

44. Logiciel et Génie logiciel • Qualité de logiciel • Les facteurs de qualité : • Internes ou de conception : visibles par les développeurs • Externes: visibles par les utilisateurs. • Parmi ces derniers : • Validité : aptitude d'un produit logiciel à remplir exactement ses fonctions, définies par le cahier des charges et les spécifications • Fiabilité (ou robustesse) : aptitude d'un produit logiciel à fonctionner dans des conditions anormales • Extensibilité : facilité avec laquelle un logiciel se prête à une modification ou à une extension des fonctions qui lui sont demandées • Réutilisation : aptitude d'un logiciel à être réutilisé, en tout ou en partie, dans de nouvelles applications • Compatibilité : facilité avec laquelle un logiciel peut être combiné avec d'autres logiciels.

45. Logiciel et Génie logiciel • Qualité de logiciel : • Les facteurs de qualité : • Externes : • Efficacité : Utilisation optimales des ressources matérielles. • Portabilité : facilité avec laquelle un logiciel peut être transférée sous différents environnements matériels et logiciels • Vérifiabilité : facilité de préparation des procédures de test • Intégrité : aptitude d'un logiciel à protéger son code et ses données contre des accès non autorisés • Facilité d'emploi : facilité d'apprentissage, d'utilisation, de préparation des données, d'interprétation des erreurs et de rattrapage en cas d'erreur d'utilisation.

46. Logiciel et Génie logiciel • Le cycle de vie de logiciel • Modèles de cycle de vie • Définition : • Modèles généraux de développement décrivant les enchaînements et les interactions entre activités. • Objectif : • Obtenir des processus de développement rationnels, reproductibles et contrôlable. Utilisés pour mieux maîtriser le processus développement en permettant de prendre en compte, en plus des aspects techniques, l'organisation et les aspects humains • Remarques : • Une étape, telle que la conception, peut faire intervenir plusieurs activités, comme celles de la spécification globale, du maquettage et de la validation • une activité comme la documentation peut se dérouler pendant plusieurs étapes

47. Logiciel et Génie logiciel • Le cycle de vie de logiciel • Modèles de cycle de vie • Historique : • A la fin des années 60, le modèle de développement par étapes successives est apparu. Il s'agissait du modèle de la cascade • Puis, durant les années 80, le modèle en V à émergé. C'est encore le modèle le plus utilisé aujourd'hui • Enfin, plus récemment le modèle en spirale, plus complet, mais également plus complexe a introduit de nouveaux aspects comme l'analyse des risques et l'utilisation systématique de prototypes pour s'assurer de la bonne compréhension des besoins de l'utilisateur final

48. Pré-analye Analye des besoins Conception préliminaire Conception détaillée Codage Intégration maintenance Logiciel et Génie logiciel • Cycle de vie de logiciel • Modèles du cycle de vie • Modèle de la cascade (waterfall) • Dans ce modèle, chaque phase se termine à une date précise par la production de certains documents ou logiciels. • on ne passe à la phase suivante que si les résultats de l’étape précédente sont jugés satisfaisants • D'autres activités interviennent, par exemple le contrôle technique et la gestion de la configuration sont présents tout au long du processus.

49. Logiciel et Génie logiciel • Cycle de vie de logiciel • Modèles du cycle de vie • Modèle de la cascade (waterfall) • Le modèle original ne comportait pas de possibilité de retour en arrière. • Celle-ci a été rajoutée ultérieurement 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. • Les développements récents de ce modèle font paraître de la validation-vérification à chaque étape : • faisabilité et analyse des besoins : validation ; • conception du produit et conception détaillée : vérification ; • intégration : test d'intégration et test d'acceptation ; • installation : test du système.

50. Analye des beoins Et faisabilité Installation Test système spécification Test D’acceptation Conception architcturale Intégration Et test D’intégration Conception détaillée Test unitaire Programmation Logiciel et Génie logiciel • Cycle de vie de logiciel • Modèles du cycle de vie • Modèle en V • contrairement au modèle de la cascade, ce modèle fait apparaître le fait que le début du processus de développement conditionne ses dernières étapes. • avec toute décomposition doit être décrite la recomposition, • toute description d'un composant est accompagnée de tests qui permettront de s'assurer qu'il correspond à sa description. • ceci rend explicite la préparation des dernières phases (validation-vérification) par les premières (construction du logiciel), • permet ainsi d'éviter un écueil bien connu de la spécification du logiciel :énoncer une propriété qu'il est impossible de vérifier objectivement après la réalisation. • le cycle en V est le cycle qui a été normalisé • il est largement utilisé, notamment en informatique industrielle et télécoms