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 GÉNIE LOGICIEL Cession Ingénieur Programmeur 2011 Chargé du cours: Mr BOURBET.M E ntreprise N ationale des S ystèmes I nformatiques ENSI.

Présentations similaires


Présentation au sujet: "1 GÉNIE LOGICIEL Cession Ingénieur Programmeur 2011 Chargé du cours: Mr BOURBET.M E ntreprise N ationale des S ystèmes I nformatiques ENSI."— Transcription de la présentation:

1 1 GÉNIE LOGICIEL Cession Ingénieur Programmeur 2011 Chargé du cours: Mr BOURBET.M E ntreprise N ationale des S ystèmes I nformatiques ENSI

2 2 Définition du logiciel Un logiciel (software) est lensemble des programmes, des procédures et des documentations nécessaires au fonctionnement dun système informatique BOURBET.M

3 3 Critères de qualité du logiciel BOURBET.M Exactitude Aptitude dun logiciel à fournir des résultats voulus dans les conditions normales dutilisation. Robustesse Aptitude à bien réagir lorsque lon sécarte des conditions normales dutilisation. Exemple : IP (Internet Protocol). Le succès dInternet est du à la robustesse du protocole de communication utilisé. Un datagramme IP arrive à destination même si un réseau local est inaccessible.

4 4 Critères de qualité du logiciel BOURBET.M Extensibilité Facilité avec laquelle un programme pourra être adapté pour faire face à une évolution des besoins de lutilisateur. Réutilisabilité Possibilité dutiliser certaines parties du logiciel pour développer un autre logiciel répondants à dautres besoins. Cette notion est souvent relié à lorienté objet où une classe générale sera facilement réutilisable.

5 5 Critères de qualité du logiciel BOURBET.M Portabilité Facilité avec laquelle on peut exploiter un logiciel dans différentes implémentations. Exemple Windows 95 ou Linux. Efficience Temps dexécution, taille mémoire…

6 6 Caractéristiques du logiciel - 1 le logiciel est facile à reproduire Tout le coût se trouve dans le développement le logiciel est immatériel et invisible On ne peut lobserver quen lutilisant La qualité nest pas vraiment apparente Difficile destimer leffort de développement développement difficile à automatiser Beaucoup de main-dœuvre nécessaire … BOURBET.M

7 7 Caractéristiques du logiciel - 2 le logiciel ne suse pas, mais il vieillit complexification indue duplication de code introduction derreurs Détérioration suite aux changements : Mal conçu au départ : inflexibilité manque de modularité documentation insuffisante Evolution du matériel BOURBET.M

8 8 Différentes catégories de logiciels sur-mesure : pour un client spécifique générique : vendu sur un marché BOURBET.M

9 9 Différents types de logiciels système dinformation et daide à la décision logiciel temps-réel logiciel embarqué logiciel distribué BOURBET.M

10 10 Problématique historique du logiciel « Dune part le logiciel nest pas fiable, dautre part il est incroyablement difficile de réaliser dans les délais prévus des logiciels satisfaisant leur cahier des charges » BOURBET.M

11 11 Le logiciel nest pas fiable … Quelques exemples célèbres : 1ère sonde Mariner vers Vénus navette spatiale ATT avion F16 bug de lan 2000 perdue dans lespace (erreur Fortran) lancement retardé (problème logiciel) appels longue distance suspendus (changement de version) retourné à léquateur (non prise en compte hémisphère sud) Tout système comporte des bugs … BOURBET.M

12 12 Délais et exigences non satisfaits … Quelques exemples célèbres : OS 360 dIBM Aéroport de Denver (système de livraison des bagages) SNCF (système Socrate) en retard, dépassement mémoire et prix, erreurs 1 an de retard difficultés importantes BOURBET.M

13 13 Abandons … Quelques exemples célèbres : EDF (contrôle-commande centrales 1400 MWatts) bourse de Londres (projet dinformatisation) Etats-Unis (système de trafic aérien) renonce après plusieurs années defforts abandon : 4 années de travail ML perdus abandon La non rencontre des exigences et les dépassements de délais sont fréquents : 300 à 400 % BOURBET.M

14 14 Naissance dune nouvelle discipline Problématique apparue dès les années 1960 Conférence parrainée par lOTAN (1968) Naissance du « Génie Logiciel » (software engineering) Historique BOURBET.M

15 15 Naissance dune nouvelle discipline Démarche de développement ingénierique Principes, méthodes, outils Techniques de fabrication assurant : Objectif respect des exigences respect de la qualité respect des délais et des coûts BOURBET.M

16 16 Définition du « Génie Logiciel » la résolution de problèmes posés par un client par le développement systématique et lévolution de systèmes logiciels de grande taille et de haute qualité en respectant les contraintes de coûts, de temps, et autres Processus visant : BOURBET.M

17 17 Résolution de problèmes posés par un client … identifier et comprendre le problème à résoudre solution utile résolvant un problème concret la solution peut être de ne rien développer ! BOURBET.M

18 18 Développement systématique et évolution … techniques maîtrisées, organisation, rigueur bonnes pratiques standardisées (IEEE, ISO) la plupart des projets consistent en une évolution BOURBET.M

19 19 Systèmes de grande taille et haute qualité … travail en équipe(s) bonne coordination essentielle principal défi : subdiviser et recomposer harmonieusement produit final : critères de qualités bien établis BOURBET.M

20 20 Respectant les contraintes … les ressources sont limitées (temps, argent, …) le bénéfice doit être supérieur aux coûts la productivité doit rester concurrentielle mauvaise estimation échec BOURBET.M

21 21 Transition … ne pas remplir les exigences du client produire un logiciel non fiable dépasser les délais, les coûts et autres contraintes Risques majeurs du développement de logiciels : BOURBET.M

22 22 Méthodes du Génie Logiciel Méthodologies de développement BOURBET.M

23 23 Introduction on décompose la production en « phases » lensemble des phases constitue un « cycle de vie » les phases font apparaître des activités clés Comme pour tout produit manufacturé complexe : BOURBET.M

24 24 Activités du développement de logiciel Analyse des besoins Spécification Conception Programmation Intégration Vérification et validation BOURBET.M

25 25 Analyse des besoins But : déterminer ce que doit faire (et ne pas faire) le logiciel déterminer les ressources, les contraintes Caractéristiques : parler métier et non info entretiens, questionnaires observation de lexistant, étude de situations similaires Résultat : ensemble de documents rôle du système future utilisation aspects de lenvironnement (parfois) un manuel dutilisation préliminaire BOURBET.M

26 26 Spécification But : établir une 1ère description du futur système consigner dans un document qui fait référence Données : résultats de lanalyse des besoins + faisabilité informatique Résultat : Spécification Technique de Besoin (STB) ce que fait le logiciel, mais pas comment pas de choix dimplémentation (parfois) un manuel de référence préliminaire Remarques : BOURBET.M

27 27 Conception But : décrire comment le logiciel est construit décider comment utiliser la techno. pour répondre aux besoins Travail : enrichir la description de détails dimplémentation pour aboutir à une description très proche dun programme 2 étapes : conception architecturale conception détaillée BOURBET.M

28 28 Conception architecturale But : décomposer le logiciel en composants mettre au point larchitecture du système définir les sous-systèmes et leurs interactions concevoir les interfaces entre composants Résultat : description de larchitecture globale du logiciel spécification des divers composants BOURBET.M

29 29 Conception détaillée But : élaborer les éléments internes de chaque sous-syst. Résultat : pour chaque composant, description des structures de données, algorithmes Remarque : si la conception est possible, la faisabilité est démontrée sinon, la spécification est remise en cause BOURBET.M

30 30 Programmation But : passer des structures de données et algorithmes à un ensemble de programmes Résultat : ensemble de programmes ensemble de bibliothèques / modules documentés (commentaires) activité la mieux maîtrisée et outillée (parfois automatisée) Remarque : BOURBET.M

31 31 Gestion de configurations et Intégration Gestion de configurations : gérer les composants logiciels (programmes, bibliothèques, …) maîtriser leur évolution et leurs mises à jour Intégration : assembler les composants pour obtenir un système exécutable BOURBET.M

32 32 Vérification But : vérifier par rapport aux spécifications vérifier que les descriptions successives (et in fine le logiciel) satisfont la STB Moyens : revues de projet, tests 4 types de tests : test unitaire : composants isolés test dintégration : composants assemblés test système : système installé sur site test dacceptation : testé par lutilisateur test = chercher des erreurs dans un programme exécution sur un sous-ensemble fini de données BOURBET.M

33 33 Validation But : vérifier par rapport aux utilisateurs Moyen : revues de projet BOURBET.M

34 34 Maintenance But : corriger des défauts améliorer certaines caractéristiques suivre les évolutions (besoin, environnement) peut remettre en cause les fonctions du système peut impliquer un re-développement (re-ingeneering) Remarque : BOURBET.M

35 35 Maquettage / Prototypage But : préciser les besoins et les souhaits des utilisateurs développer rapidement une ébauche du système 2 types de maquettes : maquette exploratoire : spécification maquette expérimentale : conception BOURBET.M

36 36 Répartition des activités Actuellement, dans un projet logiciel bien conduit : 40 % Analyse, Spécification, Conception 20 % Programmation 40 % Intégration, Vérification, Validation BOURBET.M

37 37 Résumé analyse des besoins spécification (maquettage) conception architecturale détaillée programmation config. et intégration vérif. et validation maintenance descriptions de plus en plus précises = raffinements Exécutable + Doc. BOURBET.M

38 38 Introduction Modèle de développement ? enchaînements et interactions entre les activités But pour le projet : ne pas sapercevoir des pbs quà la fin contrôler lavancement des activités en cours vérifier / valider les résultats intermédiaires Objectif général : obtenir des processus de développement rationnels contrôlables reproductibles BOURBET.M

39 39 Modèles de développement logiciel modèle en cascade (fin des années 1960) modèle en V (années 1980) modèle en spirale (Boehm, 1988) BOURBET.M

40 40 Modèle en cascade BOURBET.M

41 41 Modèle en cascade principe :le développement se divise en étapes une étape se termine à une certaine date des docs ou prog sont produits à la fin de chaque étape les résultats détapes sont soumis à revue on passe à létape suivante ssi lexamen est satisfaisant une étape ne remet en cause que la précédente commentaire : modèle séduisant car simple moyennement réaliste (trop séquentiel) BOURBET.M

42 42 Modèle en V BOURBET.M

43 43 Modèle en V principe :les premières étapes préparent les dernières interprétation : 2 sortes de dépendances entre étapes en V, enchaînement séquentiel (modèle en cascade) de gauche à droite, les résultats des étapes de départ sont utilisés par les étapes darrivée commentaire : avec la décomposition est écrite la recomposition vérification objective des spécifications modèle plus élaboré et réaliste éprouvé pour de grands projets, le plus utilisé BOURBET.M

44 44 Modèle en spirale BOURBET.M

45 45 Modèle en spirale principe :développement itératif (prototypes) interprétation : chaque mini-cycle se déroule en 4 phases 1. Analyse des besoins, Spécification 2. Analyse des risques, Alternatives, Maquettage 3. Conception et Implémentation de la solution retenue 4. Vérification, Validation, Planification du cycle suivant commentaire : nouveau : analyse de risques, maquettes, prototypage modèle complet, complexe et général effort important de mise en œuvre utilisé pour projets innovants ou à risques BOURBET.M

46 46 Résumé modèles : enchaînements et interactions entre étapes passage dune étape à la suivante : documents, tests vérifiés et validés 3 modèles : cascade, V, spirale (séquentiels et itératif) cascade :simple mais pas très réaliste spirale : nouvelles notions, très complet mais lourd V : assez réaliste, le plus éprouvé et utilisé BOURBET.M

47 47 Maturité du processus de développement notion définie par le SEI (Software Engineering Institute) Capacity Maturity Model (CMM) 5 niveaux de maturité : Initial Reproductible Défini Géré Optimisé BOURBET.M

48 48 Niveaux de maturité BOURBET.M

49 49 Etude américaine (1991) Etude SEI Organisations américaines BOURBET.M

50 50 Etude américaine (1999) Etude SEI Organisations américaines BOURBET.M

51 51 Principes du Génie Logiciel Vers une assurance qualité … BOURBET.M

52 52 Différentes perceptions de la qualité … QUALITÉ EXTERNE QUALITÉ INTERNE BOURBET.M

53 53 Facteurs de qualité - 1 complétude fonctionnelle tâches effectuées sans problème fonctionne même dans des cas atypiques ergonomie / convivialité fiabilité / robustesse réalise toutes les tâches attendues facile dutilisation apprentissage aisé Qualité externe : BOURBET.M

54 54 Facteurs de qualité - 2 adaptabilité Qualité interne : le fonctionnement du logiciel est facile à comprendre réutilisabilité traçabilité / compréhension facile à modifier, à faire évoluer des parties peuvent être réutilisées facilement efficacité / performance bonne utilisation des ressources (mémoire, cpu, …) portabilité capacité à marcher dans un autre contexte ou env. BOURBET.M

55 55 Comment agir sur la qualité logicielle ? rigueur et formalisme séparation des préoccupations modularité généralité / abstraction incrémentalité anticipation des changements La qualité est atteinte ou améliorée en appliquant certains principes : BOURBET.M

56 56 Rigueur et formalisme rigueur = précision, exactitude (confiance en la fiabilité) formalisme = le plus haut degré de rigueur (mathématiques) spécification formelle vérification formelle (preuve) analyse de complexité dalgorithmes … nécessaire pour les parties critiques (haut risque) peut être utilisé dans chaque phase BOURBET.M

57 57 Séparation des préoccupations - 1 principe : traiter séparément les aspects dun problème résultat : réduit la quantité de complexité à contrôler diviser pour régner BOURBET.M

58 58 Séparation des préoccupations - 2 domaine de problème : quoi résoudre ? domaine de solution : comment résoudre ? séparation de domaine différentes sortes de séparations : séparation de temps : phases du cycle de vie séparation de qualité vues séparées sur le logiciel : modélisation en UML séparation de responsabilités : org. en équipes projet maquettes, prototypes conception globale, détaillée cas dutilisation, structure statique comportement dynamique, architecture BOURBET.M

59 59 Modularité principe : séparer le système en composants logiques avantages : modules conçus et construits séparément réutilisés réduction de complexité les modules peuvent être système modifié en changeant un nombre limité de modules BOURBET.M

60 60 Généralité / Abstraction généraliser un problème particulier le rendre réutilisable dans dautres contextes design : des solutions généralisées pour des logiciel générique vs logiciel sur mesure principe : exemple : problèmes typiques de conception BOURBET.M

61 61 Incrémentalité développer le logiciel en une série dincréments se rapprocher de la solution par raffinements successifs cycle de vie en spirale phase de conception principe : exemple : BOURBET.M

62 62 Anticipation des changements réparation des erreurs détectées adaptation à de nouveaux environnements traitement de nouvelles exigences changements dans les exigences changement des formats de données changement dexigences non-fonctionnelles le logiciel évolue constamment pour différentes raisons : avant de développer, poser les questions : quels changements, où ? comment les rendre plus faciles à appliquer ? BOURBET.M

63 63 Résumé qualité externe : client, utilisateurs qualité interne : développeurs, gestionnaires la qualité du logiciel est fondamentale elle est aperçue différemment selon les points de vue : pour latteindre, on adopte des principes participation des activités et modèles de développement lutilisation de lapproche OO participe aussi beaucoup à remplir ces objectifs BOURBET.M

64 64 Résumé général logiciel programme problèmes : pas fiable dépassements (délais, coûts) non conforme au cahier des charges génie logiciel : démarche ingénierique méthodes, principes, outils méthodes : processus de développement activités et modèles (cascade, V, spirale) principes : pour atteindre des objectifs de qualité outils : Ateliers de Génie Logiciel (AGL) BOURBET.M

65 65 Conclusion situation en progrès : logiciel plus fiable plus facilement modifiable satisfait mieux les utilisateurs en contrepartie, les problèmes sont plus critiques, centr. téléph., centrales nucléaires avions, spatial, ferroviaire banque, bourse, … plus complexes, de plus en plus de fonctionnalités systèmes distribués mutations technologiques rapides et les exigences plus fortes (fiabilité, permanence du service) la maîtrise du logiciel reste un défi scientifique et technologique majeur BOURBET.M


Télécharger ppt "1 GÉNIE LOGICIEL Cession Ingénieur Programmeur 2011 Chargé du cours: Mr BOURBET.M E ntreprise N ationale des S ystèmes I nformatiques ENSI."

Présentations similaires


Annonces Google