Entreprise Nationale des Systmes Informatiques ENSI GNIE LOGICIEL

Entreprise Nationale des Systèmes Informatiques ENSI GÉNIE LOGICIEL Cession Ingénieur Programmeur 2011 Chargé du cours: Mr BOURBET. M 1

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

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

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

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

Caractéristiques du logiciel -1 n le logiciel est facile à reproduire § Tout le coût se trouve dans le développement n le logiciel est immatériel et invisible § On ne peut l’observer qu’en l’utilisant § La qualité n’est pas vraiment apparente § Difficile d’estimer l’effort de développement n développement difficile à automatiser § Beaucoup de main-d’œuvre nécessaire … BOURBET. M 6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 36

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

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

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

Modèle en cascade BOURBET. M 40

Modèle en cascade n 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 l’examen est satisfaisant une étape ne remet en cause que la précédente n commentaire : modèle séduisant car simple moyennement réaliste (trop séquentiel) BOURBET. M 41

Modèle en V BOURBET. M 42

Modèle en V n principe : les premières étapes préparent les dernières n 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 d’arrivée n 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 43

Modèle en spirale BOURBET. M 44

Modèle en spirale n principe : développement itératif (prototypes) n 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 n 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 45

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

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

Niveaux de maturité BOURBET. M 48

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

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

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

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

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

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

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

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

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

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

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

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

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

Anticipation des changements n le logiciel évolue constamment pour différentes raisons : § 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 d’exigences non-fonctionnelles n avant de développer, poser les questions : quels changements, où ? comment les rendre plus faciles à appliquer ? BOURBET. M 62

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

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

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