Génie Logiciel - 2ème Année DUT EST Salé - Cours PDF

GÉNIE LOGICIEL 2éme année DUT EST Salé 1 V OLUME HORAIRE Volume Nature horaire Elément 2 : Génie logiciel Cours 20H TD...

GÉNIE LOGICIEL 2éme année DUT EST Salé 1 V OLUME HORAIRE Volume Nature horaire Elément 2 : Génie logiciel Cours 20H TD 0H TP 20H Autres (Travaux de terrain, Projets, Stages…) 0H TOTAL 24H Travail personnel (préciser) Devoirs, exposés, mini 3H projet (*) 2 O BJECTIF DU COURS  L’objectif spécifique de « Génie Logiciel » est de former des développeurs de haut niveau dans le domaine du génie logiciel, capables de maîtriser les spécificités des applications standard, mobiles et aussi les ERP sur les différentes plateformes.  L’objectif principale est d’assurer et d’améliorer la qualité d’un produit logiciel et de fournir les méthodes et techniques nécessaire à tout programmeur pour utiliser ou réutiliser les applications existantes. 3 OBJECTIFS DÉTAILLER o A la fin de ce cours l’étudiant aura la capacité d’opter pour l’architecture logicielle la mieux adéquate et de réussir la mise en œuvre d’une approche de développement d’architecture à base de modèles à travers les métadonnées et les transformations de modèles. 4 COMPÉTENCES SPÉCIFIQUES AU GÉNIE LOGICIEL  Maitriser les techniques et les outils utilisés dans la production industrielle des logiciels.  Connaitre les différents modèles de processus pour le développement logiciel  Maitriser Les outils d’aide à la prise de décision  Développer une application selon une architecture distribuée  Créer et déployer des services web  Développer des applications sur des terminaux mobiles sur différentes plates formes 5  Gérer la migration d’une application entre les différentes plates formes mobiles P LAN DU COURS  Les Techniques et les Outils lies à une Phase des Cycles de Vie ⚫ Les différents modèles de cycle de vie ⚫ La spécification ⚫ La conception ⚫ Le codage 6 CHAPITRE1: INTRODUCTION AU GÉNIE LOGICIEL  Qu'est ce que ce génie logiciel  Pour quoi la naissance de GL  Processus du développement logiciel  Cycle de vie des logiciels 7 Q U’ EST CE QU’ UN LOGICIEL? Système informatique Logiciels classiques Propriétés statiques Propriétés dynamiques Les traitements prennent de plus en plus Systèmes d’Information d’Aide à la d’importance Décision Systèmes d’Information (BD) Les données sont au centre du système : orientation sujet (entrepôt) Les données sont Les données sont au centre du système et persistantes Les systèmes procèdent de plus persistantes en plus à des post-traitements : fouille de données et aide à la décision 8  Quelles sont les qualités d’un bon logiciel ? Qu’est-ce que le génie logiciel ? Génie Logiciel= génie + Logiciel (Software engineering) Quelles sont les activités fondamentales du génie logiciel? 9 QU’EST-CE QUE LE GÉNIE LOGICIEL? IEEE definition: Le Génie Logiciel est l’application d’une approche systématique, disciplinée et quantifiable au développement, à l’exploitation et à la maintenance du logiciel. C’est-à-dire, l’application de l’ingénierie au logiciel D’après MC. Gaudel : Le Génie Logiciel est l’art de spécifier, de concevoir, de réaliser et de faire évoluer, avec des moyens et dans des délais raisonnables, des programmes, des documentations et des procédures de qualité en vue d’utiliser un système informatique pour résoudre certains problèmes 10 LA CRISE DU LOGICIEL: NAISSANCE Constat du développement logiciel depuis la fin des années 60 : délais de livraison non respectés budgets non respectés ne répond pas aux besoins de l'utilisateur ou du client difficile à utiliser, maintenir, et faire évoluer Q D C 11 1969 LA CRISE DU LOGICIEL : Étude du DoD 1995 Étude du Department of Defense des États-Unis sur les logiciels produits dans le cadre de 9 gros projets militaires des projets payés mais jamais livrés 45% des projets utilisés tels quel 2% des projets livrés Utilisés après mais jamais modification 3% utilisés 30% des projets Abandonnées ou refaits 20% 12 Synthèse: 98% des projet ont échoué grâce aux bugs B UGS Raisons principales des bugs : oErreurs humaines oTaille et complexité des logiciels oManque de méthodes de conception oNégligence de la phase d'analyse des besoins du client oNégligence et manque de méthodes et d'outils des phases de validation/vérification 13 B UGS Exemple de Bugs : Healthcare.Gov en 2014: ❖ Programme lancer par Obama (probléme de saturation de serveur) Sonde Mariner 1, 1962… ❖ Détruite 5 minutes après son lancement; coût : $18,5 millions ❖ Défaillance des commandes de guidage due à une erreur de spécification ❖ Erreur de transcription manuelle d'un symbole mathématique dans la spécification 14 La crise du logiciel : GL est surtout conçu pour maîtriser le développement des systèmes complexes 15 STANDISH GROUP, CHAOS MANIFESTO 2013 - THINK BIG, A CT SMALL, 2013 M YTHES DU LOGICIEL ❖ Idée grossière du logiciel suffisante pour commencer à programmer. ❖ Travail terminé quand programme écrit et fonctionnel ❖ Facile de gérer spécifications changeantes ❖ En cas de retard, solution : ajouter des programmeurs 16 S YNTHÈSE Pour répondre à cette crise, les chercheurs ont essayé d’appliquer les méthodes connues de l’ingénieur au domaine du logiciel, pour établir des méthodes fiables sur lesquelles construire une industrie du logiciel. Il s’agit de se donner un cadre rigoureux pour : Guider le développement du logiciel, de sa conception à sa livraison; Contrôler les coûts, évaluer les risques et respecter les délais; Établir des critères d’évaluation de la qualité d’un logiciel. 17 PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL Définition: Le « processus de développement logiciel» désigne toutes les étapes du développement d'un logiciel, de sa conception à sa disparition. Ce découpage permet la validation du développement logiciel (conformité du logiciel avec les besoins exprimés), et la vérification du processus de développement (adéquation des méthodes mises en oeuvre). L'origine de ce découpage provient du constat que les erreurs ont un coût d'autant plus élevé qu'elles sont détectées tardivement dans le processus de réalisation. Le Processus de développement logiciel permet de détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du logiciel, les délais de sa réalisation et les coûts associés. 18 PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL Le génie logiciel est une démarche d’ingénierie qui traite tous les aspects de la production de logiciels. Le développement comprend un ensemble d’activités: La gestion des exigences // La spécification La conception La construction La validation Le déploiement La maintenance 19 PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL Description: La description du processus peut aussi inclure: Les produits, qui sont les résultats des sorties d’une activité d’un processus (les livrables) Les rôles, qui reflètent les responsabilités des personnes impliquées dans le processus (ex: Scrum-Master and Product-Owner) Les pré-et post-conditions, qui sont des conditions vraies avant et après l’activité d’un processus (ex: durée de sprint). 20 PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL Phase : définition des besoins 21 PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL Phase : Analyse des besoins / spécification 22 PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL Phase : Planification / Gestion de projet 23 PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL Phase : Conception 24 PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL Phase : Codage et tests unitaires 25 PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL Phase : Intégration 26 PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL Phase : Qualification 27 PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL Phase : Maintenance 28 Q U’ EST CE QU’ UN CYCLE DE VIE Ensemble séquentiel de phases, dont le nom et le nombre sont déterminés en fonction des besoins du projet, permettant généralement le développement d’un service ou d’un produit. 29 M ODÈLE DE CYCLE DE VIE Modèle linéaire : ✓ Modèle en cascade ✓ Modèle en V Modèle itératif ✓ Modèle en spirale ✓Modèle incrémental Modèle avec méthode Agile ✓ XP ✓Scrum ✓Crystal ✓ RAD 30 ✓…  MODÈLE LINÉAIRE : 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 la phase d’analyse avant la phase d’implémentation (séparation des questions). 31 MODÈLE EN CASCADE Il a été mis au point dès 1966, puis formalisé aux alentours de 1970. Le modèle de la cascade défini des étapes (ou phases) durant lesquelles les activités de développement se déroulent. Une étape doit se terminer à une date donnée par la production de certains documents ou logiciels Les résultats de l'étapes ont soumis à une étude approfondie. L'étape suivante n'est abordée que si les résultats sont jugés satisfaisants. 32 MODÈLE EN CASCADE 33 MODÈLE EN CASCADE- CARACTÉRISTIQUES Hérité des méthodes classiques d'ingénierie; Découverte d'une erreur entraîne retour à la phase à l'origine de l'erreur et nouvelle cascade, avec de nouveaux documents... Coût de modification d'une erreur important, donc le choix en amont cruciaux (typique d'une production industrielle). 34 MODÈLE EN CASCADE- INCONVÉNIENTS Le modèle en cascade rend coûteux le développement itératif puisque la rédaction des documents de validation de chaque phase demande beaucoup de travail. Ce modèle est inadapté au développement de systèmes dont la spécification est difficile à formuler a priori. 35 M ODÈLE EN V 36 MODÈLE EN V Modèle de cascade amélioré dans lequel le développement des tests et du logiciels sont effectués de manière synchrone. Le principe de ce modèle est qu’avec toute décomposition doit être décrite la recomposition et que toute description d’un composant est accompagnée de tests qui permettront de s’assurer qu’il correspond à sa description. Problème de vérification trop tardive du bon fonctionnement du système. 37 MODÈLE EN V - NIVEAU DE Test unitaire : test de chaque unité de programme TEST (méthode, classe, composant), indépendamment du reste du système Test d'intégration : test des interactions entre composants (interfaces et composants compatibles). Test d'acceptation et système : test du système complet par rapport à son cahier des charges. Recette : faite par le client, validation par rapport aux besoins initiaux (tests, validation des documents, conformité 38 aux normes...). MODÈLE EN V Objectifs : Validations intermédiaires pour prévenir les erreurs tardives; meilleure planification et gestion. Principes Validation à chaque étape; Préparation des protocoles de validation finaux à chaque étape descendante; Validation finale montante et confirmation de la validation descendante; 39 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; 40 Contrôle de qualité. INTÉRÊT DU MODÈLE EN V 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é 41 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 Problème de vérification trop tardive du bon fonctionnement du système 42 MODÈLES ITÉRATIFS: 43  M ODÈLE EN SPIRALE (B. B OËHM ) - met l'accent sur l’évaluation des risques; à chaque étape: On n’a pas la possibilité de retourner en arrière. Le nombre de cycles est variable selon que le développement est classique ou incrémental. 44 M ODÈLE EN SPIRALE 45 M ODÈLE EN SPIRALE 46 M ODÈLE EN SPIRALE-LIMITATION -Calendrier et budget irréalistes -Développement de fonction inapproprié -Problème de performance a besoin de compétences dans l'évaluation approfondie des incertitudes et des risques associés au projet et leur réduction. - 47 M ODÈLE EN SPIRALE-LIMITATION 48 M ODÈLE INCRÉMENTAL le modèle incrémental a été proposé dans les années 80. 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 49 M ODÈLE INCRÉMENTAL - Le développement est réaliser par suite d’incréments ou composantes, qui correspondent à des parties des spécification, et qui viennent intégrer le noyau de logiciel. - L’objectif est d’assurer la meilleur adéquation aux besoins possibles. - Le choix d’incrément est un compromis entre la durée de développement et le niveau de prise en compte des spécification. 50 M ODÈLE INCRÉMENTAL Hiérarchiserles besoins du client; Concevoir et livrer au client un produit implantant un sous ensemble de fonctionnalités par ordre de priorité. 51 MODÈLE INCRÉMENTAL - A VANTAGES - Le système peut être mis en production plus rapidement, avec la diffusion ensuite sous forme de version - Les premiers incréments permettent de renforcer l’expression de besoin et autorisent la définition des incrément suivant. 52 MODÈLE INCRÉMENTAL - R ISQUES -Les noyaux, les incréments ainsi que leurs interactions doivent être spécifiés globalement, au début du projet; - -Les incréments doivent être aussi indépendants que possibles. - 53 S YNTHÈSE 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. 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. 54 MODÈLE AVEC MÉTHODE AGILE 55 M ÉTHODES A GILE (NAISSANCE)  réduire le cycle de développement des projets informatiques  répondre plus rapidement aux évolutions des demandes de l’utilisateur final. ⚫ intégrer au cours du projet de manière continue le client final ⚫ Gérer les projets informatiques de manière adaptative et incrémentale. 56 V ALEURS DES MÉTHODES AGILES  Des logiciels opérationnels plus qu’une documentation exhaustive  La collaboration entre les développeurs et les clients plus que la négociation contractuelle  L’adaptation au changement plus que le suivi d’un planning 57 C ARACTÉRISTIQUES DES MÉTHODES AGILES  Le développement est centré sur le code.  Il s'agit de produire rapidement des prototypes exécutables.  Orientées client plutôt que processus  Moins orientés documentation  Méthodes adaptatives Processus auto-adaptatif : révision du processus à chaque itération 58 MÉTHODE AGILE  Les méthodes agiles utilisent un principe de développement itératif => Ces itérations sont en fait des mini-projets définis avec le client en détaillant les différentes fonctionnalités qui seront développées en fonction de leur priorité.  Le chef de projet établi alors un macroplanning correspondant aux tâches nécessaires pour le développement de ces fonctionnalités. 59 M ÉTHODES AGILES Plusieurs méthodes de type agiles existent On peut citer :  XP (Extreme programming)  Scrum  Crystal  RAD (rapid application development)  …. 60 P ROCESSUS DE DÉVELOPPEMENT SCRUM  Développée en 1996, par J.Sutherland et K.Schwaber  Cette méthode de gestion, ou plutôt ce Framework de management de projet, à pour objectif d’améliorer la productivité de son équipe.  Concentrer l’équipe, de manière itérative, sur un ensemble de fonctionnalités à réaliser Durée des itérations -SCRUM suggère un mois 61 R ÔLE : D IRECTEUR DU PRODUIT Représentant des clients et des utilisateurs  Définit l’ordre de développement des fonctionnalités  Décide sur les orientations importantes du projet  choisit la date et le contenu de la release  accepte et rejette les résultats Product owner 62 ROLE: S CRUM MASTER Représente le management de projet:  Veille à résoudre les problèmes non techniques  Veille à l’application des valeurs de Scrum  Il est garant du cadre méthodologique Scrum  Il est un coach, et non un supérieur  Des compétences humaines indispensables  L’analogie avec le maître du jeu Scrum Master 63 R OLE : EQUIPE  Se composent de 5 à 10 personnes  Auto-gérée  regroupent tous les rôles: architecte, concepteur, analyste, développeur, testeur  Décisions prises ensemble  se concentrent sur un sprint à la fois (sprint courant) 64 SCRUM- ITÉRATIONS (Sprint) Le cycle de vie Scrum est rythmé par des itérations de quelques semaines.  Une itération, appelée Sprint, dure 30 jours (2 à 4 semaines)  Chaque Sprint a un but à atteindre  Un Sprint aboutit sur la livraison d’un produit partiel fonctionnel  La participation du client est déterminante pour le choix des priorités dans les fonctionnalités du logiciel 65 RÉFÉRENTIEL DES EXIGENCES : LE PRODUCT BACKLOG Le référentiel des exigences initiales est dressé et hiérarchisé avec le client. Il constitue ce que l’on nomme le product backlog. Il ne doit pas nécessairement contenir toutes les fonctionnalités attendues dès le début du projet, il va évoluer durant le projet en parallèle des besoins du client. 66 USER STORY Les fonctionnalités décrites portent le nom de User Stories et sont décrites en employant la terminologie utilisée par le client. Une User Story ou Story contient généralement les informations suivantes : 1. ID – un identifiant unique 2. Nom – un nom court (entre 2 et 10 mots), descriptif de la fonctionnalité attendue par le client. 3. Importance – un entier qui fixe la priorité des Stories. La priorité d’une story peut être changée en cours de réalisation du projet. 67 USER STORY 4. Estimation – La quantité de travail nécessaire pour développer, tester, et valider cette fonctionnalité. L’unité de mesure peut être un nombre de jours idéaux (jours à 100% dédiés à la fonctionnalité) ou un nombre de points. Les estimations se font en relatif en comparant les estimations des stories terminées avec la story à estimer. 5. Demo – Un test relativement simple (ex : exporter un objet en XML puis l’effacer de la base, l’importer depuis le XML, à la fin l’objet doit être dans la base). Ce test constitue un test de validation. 6. Notes – toute autre information : clarifications, références documentaires … 68 PLANNIFICATON Planification à trois niveaux :  Sprint : itération de 30 jours  Release/projet : regroupement d’itérations  Quotidien : réunion (srcum) de mise au point 69 S CRUM BOARD 70 AN EXAMPLE OF A SPRINT BACKLOG 71 S CRUM PROCESS 72 O UTILS POUR SCRUM Outils libres :  IceScrum (open source) Outils propriétaires :  ScrumWorks 73 METHODE XP eXtreme Programming (XP) Apparaît en 1999 par Ken Beck de Chrysler. Nouvelle approche de développement incrémental basée sur la réalisation rapide, en équipe, d’incréments fonctionnels. Caractéristiques : Emphase sur la satisfaction du client le produit dont il a besoin des livraisons aux moments où il en a besoin un processus robuste si les exigences sont modifiées Emphase sur le travail d'équipe 74 managers, clients, développeurs : ensemble VALEURS DE L ’E XTREME P ROGRAMMING (XP) Communication: Au sein de l’équipe de développeurs et avec le client Feedback : Itérations rapides permettant la réactivité, test du code dès le début Simplicité : Code simple livrable ne contenant que les exigences du client avec un design propre et simple 75 PRATIQUE DE L’EXTREME PROGRAMMING (EQUIPE) Responsabilité collective du code : polyvalence des développeurs, contribution collective aux nouvelles fonctionnalités, à la correction de bugs et à la restructurations (pas de droits exclusifs); Programmation en binôme : partage des compétence, prévention des erreurs, motivation mutuelle; Langage commun \ Métaphore : Les mots utilisés pour désigner les entités techniques doivent être choisis parmi les métaphores du domaine de projet; Rythme durable : maintenir un niveau optimal de travail entre énergie nécessaire pour le développement et le repos réparateur. 76 PRATIQUE DE L’EXTREME PROGRAMMING (CODE) Refactoring : Investissement pour le futur, réduction de la dette technique; Conception simple : facilité des reprises du code, facilité de l’ajout de fonctionnalité; Tests unitaires: Test en premier pour une programmation ultérieure plus facile et plus rapide, fixe la spécification (ambiguïtés) avant le codage, feedback immédiat lors du développement, itération du processus pour tout tester; Intégration continue : Ajout de valeurs chaque jour, évite la divergences, efforts fragmentés et permet la diffusion rapide pour la réutilisation; 77 Règles de codage : cohérence globale, code lisible / modifiable par toute l'équipe. PRATIQUE DE L’EXTREME PROGRAMMING (PROJET) Client sur site : orienter le développement en fonction des réactions des usagers et des points critiques du domaine d’utilisation Tests d’acceptation : conformité par rapport aux attentes du client Planification itérative et livraison fréquente : Les fiches sont rédigés tout au long du projet, chaque fiche correspond à une fonctionnalité (scénario) où figure la description du scénario, l’ordre de priorité, la durée de réalisation, les noms des développeurs… 78 LE CYCLE STANDARD XP ❖ 1. Le client écrit ses besoins sous forme de scénario ❖ 2. Les développeurs évaluent le coût de chaque scénario, si le coût est trop élevé pour un scénario ou difficile à estimer, le client le découpe en plusieurs scénario et les soumet aux développeurs ❖ 3. Le client choisi, en accord avec les développeur, les scénario à intégrer à la prochaine livraison ❖ 4. Chaque binôme des développeurs prend la responsabilité d’une tâche 79 LE CYCLE STANDARD XP ❖ 5. Le binôme écrit les tests unitaires correspondant au scénario à implémenter ❖ 6. Le binôme procède à l’implémentation du programme ❖ 7. Le binôme réorganise le code (refactoring) ❖ 8. Le binôme intègre ses développement à la version d’intégration, en s’assurant que tous les tests de non régression passent 80 CRYSTAL Cette méthode a été mise au point par Alistair Cockburn(signataire du Manifeste) en 1997. Plusieurs principes doivent être partagés par l’ensemble de l’équipe 81 PRINCIPE DE C RYSTAL ❖ La communication et la collaboration entre les membres de l’équipe est omniprésente ❖ Le nombre de membres de l’équipe ne peut pas dépasser 6 personnes ❖ Toute l’équipe doit travailler dans la même pièce ❖ Les diagrammes de modélisation doivent être élaborés en groupe et sur tableau blanc ❖ Livrer fréquemment des parties exécutables 82 CARACTÉRISTIQUES DE CRYTSAL Ses caractéristiques principales sont : Une collaboration étroite entre toutes les parties prenantes, y compris en dehors de l’équipe (stakeholders) Une bonne communication interpersonnelle Focus sur l’objectif et disponibilité Un contact permanent avec les utilisateurs Une réflexion constante sur ces propriétés 83 CARACTÉRISTIQUES DE CRYTSAL La spécialisation consiste à observer les utilisateurs dans leur travail pour mieux connaître leurs besoins Classer par priorité les différents cas d'utilisation. Elaboration d’une ébauche de conception impliquant les outils à utiliser. Développement des itérations (d'une longueur de 2 à 3 mois) 84 M ÉTHODES C LASSIQUES VS AGILES Les méthodes classique (prédictives) tentent de réduire l'incertitude dès le début du projet par une planification très précise et très détaillée. Cette levée de risque implique que les exigences de l'application soient figées. Les méthodes Agiles (adaptables) préfèrent, partant d'une planification initiale, réévaluée régulièrement, s'adapter aux évolutions du contexte. => La réévaluation servira de base à une prise de décision de type GO ou NO GO à chaque grand changement appliqué au projet initial. 85 R ÉCAPITULATIF MÉTHODE AGILES  Les méthodes agiles seront plus utilisées pour les gros projets car elles offrent une meilleure adaptabilité, visibilité et gestion des risques.  Elles pourraient tout aussi bien être utilisées pour les projets où il n’y pas de documentations détaillées 86 R ÉCAPITULATIF MÉTHODES CLASSIQUES  Les méthodes classiques seront plus utilisées si vous avez une idée très précise de votre projet avec un cahier des charges et planning très détaillé où vous avez anticipé tous les risques possibles.  Le chef de projet se retrouve souvent seul face à lui-même lors de la prise de décision, de gérer les retours client, devant l’incertitude afin de satisfaire le client tout en respectant les 3C. 87 88 CHAPITRE 2: LA SPÉCIFICATION 89  SPÉCIFIER….? Préciser Exprimer Objectif : comprendre les besoins du clients Définir Déterminer Établir une description claire de ce que doit faire le Indiquer logiciel (fonctionnalités détaillées, exigences de qualité, interface...) 90 E XIGENCE VS BESOIN  Besoin ➔objectif a atteindre  Exigence➔ comment satisfaire le besoin de ce client!!!  Exemple: ⚫ Besoin d’application :sécurité ⚫ Se mettre d’accord sue le type de sécurité : Exigence (doit apparaitre dans le CDC) 91 SPÉCIFICATION Déterminer ce que doit faire le système (côté client) = > Document précis spécifiant les fonctionnalités attendues; Exemple : définition de la frontière du système, description des fonctionnalités du système, interactions… À noter : Les spécifications ne sont jamais complètes ni définitives. 92 L’INGÉNIERIE DES EXIGENCES Définition : « L’ingénierie de exigences est la branche du génie logiciel qui concerne les buts réels, les fonctions et les contraintes d’un système logiciel. Elle concerne aussi la relation que ces facteurs entretiennent avec les spécifications précises du comportement logiciel, et avec leur évolution dans le temps et à travers les familles de logiciels. » Zave 1997 93 L’INGÉNIERIE DES EXIGENCES La gestion des exigences est une activité méthodique pluridisciplinaire qui permet: ▪ Recueillir, spécifier, affiner et qualifier les exigences d'un système dans son environnement, ▪ Définir l'engagement "à faire", ▪ Maîtriser les changements de ces exigences dans le temps. ➔C’est un ensemble de techniques, consistant à recueillir les besoins, à les transformer en exigences, et à les spécifier dans un cahier des charges. Objectif: la rédaction du CDC selon des étapes précises. 94 LOGICIEL : CARACTÉRISTIQUES Spécification fonctionnelle : Fonctionnalités du logiciel, réponse aux besoins des utilisateurs. Spécification non fonctionnelle : Facilité d'utilisation : prise en main et robustesse Performance : temps de réponse, débit, fluidité... Fiabilité : tolérance aux pannes Sécurité : intégrité des données et protection des accès Maintenabilité : facilité à corriger et à faire évoluer le logiciel Portabilité : adaptabilité à d'autres environnements matériels ou logiciels 95 SPÉCIFICATION : TYPES DES EXIGENCES Exigences fonctionnelles Exemple: ajouter/modifier/supprimer Exigences non-fonctionnelles Des cas opérationnels exprimer d’une manière fonctionnelle (norme ISO 9126 / norme ISO 25019 ’version 2011’) Contraintes Obligation du client en relation avec: budget, délai, technologie, modèle,… 96 TYPES DES EXIGENCES : EXERCICE Identifier le type des exigences suivantes : - le système doit utiliser des mots de passe - le système doit se déconnecter automatiquement après 2 mn sans utilisation -Le projet permet d’aider ceux qui souffrent d’Alzheimer. - système ne peut fonctionner que sur une plate-forme mobile smartphone avec un système d'exploitation Android. - Le système doit permettre un accès direct et précis aux contacts en cas d’urgence. 97 TYPES DES EXIGENCES : EXERCICE -Le système doit fournir une interface pour la recherche. -la recherche doit être effectuée dans un délai de 3s. - Le système doit présenter des objets fréquemment utilisés. -La plate-forme mobile doit disposer des ressources environnementales nécessaires pour faire fonctionner le système. 98 ELICITATION : RECUEIL DES BESOINS Les méthodologies de collection de besoins et exigences (non formelles) : - effectuées en individuel (analyse documentaire, observation, etc.) - en groupe (questionnaire, mind-mapping, méthode des post-it, interviews, storyboards, sondage/questionnaire etc.) - brainstorming, étude de la documentation existante (recherche interne), groupes de discussion. 99 ELICITATION : RECUEIL DES BESOINS Par le biais des méthodes formelles : Utilisation du bachmarking: étude des projets similaires Utilisation des ontologies des graphes, KAOS, SIG Utilisation des freamwork : NFR Framework 100 ELICITATION : RECUEIL DES BESOINS - NFR Framework Types de Relation : AND OR 101 QUELS SONT LES PROBLÈMES LIÉS À CES EXIGENCES? Exemple de fausse rédaction d’exigence? ▪ La régulation sera efficace dans tous les cas. ▪ Toutes les informations inutiles ne sont pas affichées. ▪ L’interface est simple d’utilisation. ▪ Les données sont sauvegardées autant que possible. ▪ L’application n’a pas de bugs. ▪ « Le logiciel calcule la vitesse du missile et sa trajectoire, en 5 secondes maximum » ….a un sens différent de: « Le logiciel calcule la vitesse du missile, et sa trajectoire en 5 secondes maximum » ➔L’exigence doit être :compréhensible claire et interpréter 102 d’une seul manière par plusieurs lecteur COMMENT RÉDIGER UN CAHIER DES CHARGES ? Exemple de Volere 103 COMMENT RÉDIGER UN CAHIER DES CHARGES ? La norme IEEE 830 104 CHAPITRE 3:CONCEPTION RAPPEL MERISE RAPPEL M ODÉLISATION OBJET RAPPEL UML LES PRINCIPES FONDAMENTAUX EN GL 105 MERISE (RAPPEL)  Les modèles de la méthode Merise :  Le modèle de flux  Le modèle conceptuel de données  Le modèle conceptuel de traitements  Le modèle organisationnel de traitements  Le modèle logique de données  Le modèle opérationnel des traitements  Le modèle physique des données 106 POURQUOI L’ORIENTÉ OBJET? une liste de ‘concepts ’(water, salt water...) a été donné aux élèves de primaires. Résultat => (Harry) a construit un schéma conceptuel Etude [Martin & Odell] [Novak, 1984, Cambridge University Press] 107 MODELISATION OBJET (RAPPEL) Principaux concepts objet :  Classe ⚫ Type d’objet caractérisé par sa structure de données (attributs) et son comportement (méthodes)  Objet ⚫ Un objet représente un individu, une entité identifiable réelle ou conceptuelle avec un rôle bien défini dans le domaine du problème ou dans un système (instance de classe)  Attribut ⚫ Un attribut est une propriété, une caractéristique, une qualité inhérente ou distinctive d’un objet (exemples : la 108 couleur ou l’immatriculation d’une voiture)  Méthode ⚫ Une méthode est une action qu’un objet effectue de sa propre initiative ou à la demande (réaction à un événement ou à un envoi de message). Ces méthodes décrivent les propriétés dynamiques d’un objet.  Quelques méthodes "classiques" : ⚫ Un constructeur est une méthode qui permet de construire et d’initialiser un objet (instanciation d’un objet) ⚫ Par opposition, un destructeur est une méthode qui permet de détruire un objet instancié 109 ⚫ Unaccesseur est une méthode qui permet de récupérer la valeur d’un attribut d’un objet (get… et is…) ⚫ Un modificateur est une méthode qui permet de modifier la valeur d’un attribut d’un objet (set…) ⚫ Un observateur est une méthode qui permet de retrouver des informations sur l’histoire (l’état) d’un objet ⚫ Un itérateur est une méthode qui permet d’appliquer à chaque partie d’un objet (par exemple dans le cas d’un objet de type collection) une action déterminée 110  Association ⚫ Une association permet de préciser une relation entre différents objets. Une association possède généralement un nom qui sert à décrire la nature de la relation ⚫ Une association est également caractérisée par le nombre d’objets pouvant être reliés par l’intermédiaire d’une instance d’association : 0..1, 0..n, 1..n, n..n  Agrégation ⚫ Une agrégation est une relation binaire entre deux objets qui spécifie une inclusion entre une partie et un tout. Une partie peut appartenir à d’autres agrégations et exister indépendamment  Composition ⚫ Une composition est un type particulier d’agrégation qui spécifie une inclusion entre une partie et un tout plus forte que l’agrégation : quand on supprime l’élément composite, il y a obligatoirement suppression des composants 111  Héritage ⚫ Mécanisme permettant à une classe d’objets de bénéficier de la structure de données et du comportement d’une classe "mère", tout en lui permettant de les affiner et ce, afin de prendre en compte les spécificités de la classe "fille", sans avoir cependant à redéfinir ce que les deux classes ont de commun  Généralisation ⚫ Dans le cas d’un héritage, on dit qu’une classe "mère" est une généralisation des propriétés de ses classes "fille"  Spécialisation ⚫ Dans le cas d’un héritage, on dit qu’une classe "fille" est une spécialisation des propriétés de sa classe "mère" 112  Encapsulation (interface) ⚫ Mécanisme permettant de dissimuler les détails du fonctionnement interne d’une classe aux autres classes  Abstraction (classe abstraite) ⚫ Mécanisme permettant la dissociation entre la déclaration d’une classe et son implémentation (interface)  Polymorphisme ⚫ Mécanisme permettant d’associer à un comportement, une implémentation différente en fonction de l’objet auquel on se réfère (par exemple : dessiner à l’écran un carré ou un cercle). L’émetteur n’a pas besoin de connaître la classe du receveur, seulement que la sémantique du message sera la même pour toutes les classes similaires (par exemple : la méthode toString en JAVA, les injecteurs en 113 C++)  Message ⚫ Mécanisme caractéristique des langages objet. Le message est l’unique support de communication entre objets. L’arrivée d’un message provoque l’exécution d’une méthode de l’objet  Type d’accès, portée, visibilité ⚫ Public ⚫ Private ⚫ Protected  Surcharge de méthode ⚫ Mécanisme permettant de déclarer plusieurs constructeurs ou plusieurs fois une même méthode (même nom) dans une classe, à condition que tous aient une signature différente (valeur de retour et/ou 114 paramètres différents). UML (UNIFIED M ODELING L ANGUAGE ) :  Auteurs ⚫ James Rumbaugh, Grady Booch et Yvar Jacobson  Objectifs ⚫ Faciliter la communication entre les différents acteurs d’un projet ⚫ Faciliter la communication avec la machine ⚫ Documenter un projet de bout en bout ⚫ Spécifier et donc limiter les ambiguïtés ⚫ Construire (interpréter les diagrammes pour code)  Définition ⚫ Langage de description des objets permettant une modélisation rigoureuse des systèmes complexes 115 ⚫ Langage Unifié pour la Modélisation objet UML  Avantages d’UML : ⚫ Formel et normalisé (garantit stabilité et performance d’un projet, réduit les risques) ⚫ Support de communication performant et éprouvé (permet de cadrer l’analyse et de faciliter la compréhension de représentations abstraites : c’est « l’esperanto » de l’analyse)  Inconvénients d’UML : ⚫ Période d’apprentissage ⚫ Processus de production non couvert 116 DIAGRAMMES UML 117 ORDONNANCEMENT DES DIAGRAMMES UML  1. Découverte des besoins ⚫ Diagramme de cas d’utilisation : décrit les fonctions du système (point de vue de ses futurs utilisateurs - Jacobson) ⚫ Diagramme de séquence : représentation des interactions temporelles entre objets dans la réalisation d’une IHS 118 ORDONNANCEMENT DES DIAGRAMMES UML  2. Analyse ⚫ Diagramme de classes : structure des données ⚫ Diagramme d’objets : illustration ⚫ Diagramme collaboratif : représentation des interactions entre objets ⚫ Diagramme d’états : représentation du comportement des objets d’une classe en terme d’états et de transitions d’états 119 ⚫ Diagramme d’activités : structure d’une opération en actions ORDONNANCEMENT DES DIAGRAMMES UML  3. Conception ⚫ Diagramme de séquence : représentation des interactions temporelles entre objets dans la réalisation d’une opération ⚫ Diagramme de déploiement : description du déploiement des composants sur les dispositifs matériels ⚫ Diagramme de composants : architecture des composants physiques d’une application 120 POINT DE DÉPART: DÉCOUVERTE DES BESOINS (SPÉCIFICATION)  Cette activité met donc en œuvre un mode de représentation fonctionnel s’appuyant sur : ⚫ Les diagrammes de cas d’utilisation qui permettent d’identifier et de formaliser les différents acteurs ainsi que les services attendus de la future application. ⚫ La maquette pour sa part, permet de présenter de manière concrète ces services via les IHM (Interface Homme Machine) de l’application. 121 POINT DE DÉPART: SPÉCIFICATION 122 E XEMPLE DE USE- CASE 123  Exemple de description pour le cas d’utilisation s’authentifier 124  Exemple de maquette 125 ANALYSE  Étape intermédiaire entre la spécification des besoins et la conception du système ➔identifier les classes de conception intervenant dans les diagrammes d’interaction du modèle conceptuel, deux sous étapes sont nécessaires : 126 L’ ANALYSE STATIQUE Modèle du domaine  Construire le modèle du domaine. Sorte de glossaire formalisé des concepts fondamentaux de l’espace du problème, ce modèle fournit une partie des classes de conception : celles correspondant directement aux concepts métier manipulés par les experts du domaine et les utilisateurs. Ces concepts, leurs attributs et leurs relations vont être décrits en UML par des diagrammes de classes simplifiées. ➔C’est une représentation formelle d’un domaine de connaissance avec plus de précision sur les comportements 127 L’ ANALYSE STATIQUE Exemple :Modèle du domaine 128 L’ ANALYSE STATIQUE Diagrammes de classes participants  Construire les diagrammes de classes participants. Afin de prendre en compte également l’IHM et la cinématique de l’application, les diagrammes de classes participantes font la jonction entre les cas d’utilisation, le modèle du domaine, la maquette… et les diagrammes de conception logicielle. Il s’agit de diagrammes de classes qui décrivent, par cas d’utilisation, les trois principales classes d’analyse et leurs relations. 129 L’ ANALYSE STATIQUE  Les diagrammes de classes participantes : ⚫ Les classes de type dialogue : elles permettent les interconnections entre l’IHM et ses utilisateurs. Ce sont typiquement les écrans proposés à l’utilisateur : les formulaires de saisie, les résultats de recherche… Elles proviennent directement de l’analyse de la maquette. ⚫ Les classes de type métier : elles représentent les règles métier et proviennent directement du modèle du domaine mais sont confirmées et complétées pour chaque cas d’utilisation. ⚫ Les classes de type contrôle : elles contiennent la cinématique de l’application et font la transition entre les dialogues et les classes métier, en permettant aux écrans de manipuler des informations détenues par un ou 130 plusieurs objets métier. L’ ANALYSE STATIQUE  Exemple de diagramme de classes participantes: 131 L’ ANALYSE DYNAMIQUE  Le modèle dynamique permet de décrire : ⚫ Pour chaque cas d’utilisation, la séquence des interactions entre les acteurs et le système vue comme une boîte noire, représentée par les diagrammes de séquence système.  ➔ Ces diagrammes qui feront le lien entre les cas d’utilisation et les diagrammes d’interaction du niveau conceptuel. 132 L’ ANALYSE DYNAMIQUE  Le modèle dynamique permet de décrire : ⚫ Une manière formelle l’ensemble des chemins possibles entre les principaux écrans proposés à l’utilisateur, et à partir des informations fournies par la maquette, il reste à détailler les diagrammes d’activités de navigation. ⚫ Si nécessaire, le cycle de vie commun aux objets d’une même classe, peut être explicité par les diagrammes d’états. 133 L’ ANALYSE DYNAMIQUE  Exemple de diagramme de séquence système pour le CU s’authentifier 134 L’ ANALYSE DYNAMIQUE  Exemple de diagramme d’activités de navigation pour le CU s’authentifier : 135 C ONCEPTION DU SYSTÈME  La conception du système Cible Dans les activités de conception, le modèle correspond aux concepts informatiques utilisés par les outils, les langages ou les plates-formes de réalisation.  Le modèle sert ici à étudier, documenter, communiquer et anticiper la solution logicielle. 136 C ONCEPTION SYSTÈME 137 L A CONCEPTION DU SYSTÈME  Dans le cadre de systèmes orientés objet, la structure du code est définie par des classes logicielles et leurs regroupements en ensemble (appelés packages).  La conception représente deux points de vue : la structure statique et le comportement dynamique, deux perspectives qui complètent la compréhension du système à développer. 138 L A CONCEPTION DU SYSTÈME  Le modèle statique, qui permet de décrire les différents composants logiciels structurant le système, est représenté à l’aide de diagrammes de classes de conception.  Le modèle dynamique, permet quant à lui de décrire l’attribution des bonnes responsabilités (services) aux bonnes classes. Tout le comportement du système est ainsi réparti entre les classes de conception. C’est le rôle des diagrammes d’interaction (diagrammes de séquence ou de collaboration) de représenter graphiquement ces décisions d’allocation de responsabilités ainsi que les collaborations induites. 139 L A CONCEPTION DU SYSTÈME  Exemple de diagramme de classes de conception de Struts : 140 P RINCIPES FONDAMENTAUX EN GL Séparation des problèmes Modularité Abstraction Anticipation du changement Généricité Construction incrémentale 141 S ÉPARATION DES PROBLÈMES En pratique, plusieurs façons de faire :  Séparation dans le temps (= ordonnancement)  Séparation dans l’espace (= on se répartit les taches)  Séparation des qualités (= priorités) 142 MODULARITÉ Caractéristique d’un système, matériel ou logiciel, conçu en séparant les fonctions élémentaires pour qu’elles puissent être étudiées et réalisées séparément. Les modules sont des entités cohérentes qui peuvent éventuellement être sorties du contexte et réutilisées. 143 ABSTRACTION  Opération qui consiste à isoler l’un des caractères de quelque chose et à le considérer indépendamment des autres caractères de l’objet.  C’est un exemple de séparation des problèmes. On ne considère à un instant donné que certains aspects du système que l’on juge importants. On peut souvent considérer plusieurs niveaux d’abstraction pour un même système 144 A NTICIPATION DES CHANGEMENT La caractéristique essentielle du logiciel, par rapport à d’autres produits, qu’il est presque toujours soumis à des changements continuels, dus à des corrections d’imperfections et/ou des évolutions en fonction des besoins. Ceci requiert des efforts pour prévoir, faciliter et gérer ces évolutions inévitables. ➔Il faut : ❑ Faire attention à la modularité (localisation des changements) ❑ Faire attention à la compatibilité entre différentes versions d’un même module 145 GÉNÉRACITÉ Caractéristique générale qui permet d’englober une classe d’objets dont chacun, pris séparément, reçoit une dénomination spécifique. Exemple: Siège est un terme générique d’une classe comprenant la chaise, le fauteuil, le tabouret, etc.. Il peut être parfois utile de remplacer la résolution d’un problème spécifique par la résolution d’un problème plus général. Des solutions génériques (paramétrables, adaptables) sont plus facilement réutilisables. cf classes, héritage, 146 spécialisation C ONSTRUCTION INCRÉMENTALE Un procédé incrémental atteint son but par étapes, en s’en approchant progressivement. Chaque résultat intermédiaire est construit en étendant le précédent. En pratique, on implémente d’abord un noyau fonctionnel pour chaque module, qui inclut les fonctions de base. Ce noyau est ensuite incrémenté petit à petit par de nouvelles fonctionnalités. 147 CHAPITRE 4: CODAGE 148 CODAGE  ➔L'objectif: transformer la conception d'un système en code avec un langage de haut niveau.  Les programmeurs adhèrent a un style bien défini de codage qui s’appel « standard de codage ». 149 CODAGE  Pour la mise en œuvre de notre conception en un code, nous avons besoin d'un bon langage de haut niveau. ⚫ Une norme de codage assure une uniformité du code écrit par différents ingénieurs ⚫ Il facilite la compréhension du code. ⚫ Favorise de bonnes pratiques de programmation 150 C ODAGE : STANDARS ET GUIDLINES  1.Contenu des en-têtes pour différents modules. Voici quelques-unes (des données d'en-tête) standard : ⚫ Nom du module. ⚫ La date à laquelle le module a été créé. ⚫ Le nom de l'auteur. ⚫ Historique des modifications. ⚫ Différentes fonctions prises en charge, ainsi que leurs paramètres d'entrée / sortie. ⚫ Les variables globales accessibles / modifiées par le module. 151 C ODAGE : STANDARS ET GUIDLINES  2. Conventions de dénomination des variables globales, variables locales et les identificateurs constants : ⚫ Une convention de nommage possible peut être que les noms des variables commencent toujours par une lettre majuscule, les noms de variables locales sont en minuscule et noms constants sont toujours des lettres majuscules.  3. Conventions de retour d’erreur et les mécanismes de gestion des exceptions : ⚫ La façon dont les erreur sont signalées, par des fonctions différentes dans un programme, devrait respecter la norme au sein d'une organisation. 152 C ODAGE : STANDARS ET GUIDLINES  Autres directives de codage recommandées par de nombreuses organisations de développement de logiciels. ⚫ 1.Ne pas utiliser un style de codage trop difficile à comprendre; ⚫ 2.Ne pas utiliser un identifiant à des fins multiples (Chaque variable doit avoir un nom descriptif indiquant son but). ➔Utilisation de variables à des fins multiples rend généralement les futures améliorations (les modifications) plus difficile. 153 C ODAGE : STANDARS ET GUIDLINES  3. Le code devrait être bien documenté : (usage des commentaires)  4. La longueur de toute fonction ne doit pas dépasser 10 lignes de source : Une fonction qui est très long est généralement très difficile à comprendre.  5. Ne pas utiliser les instructions goto : Utilisation des instructions goto fait un programme non structuré et très difficile à comprendre. 154 LA RÉVISION DU CODE  La Révision du Code à pour but d’avoir un module développé, compilé avec succès on se débarrassant de toutes les erreurs (de syntaxe).  Les examens du code sont des stratégies très rentables pour la réduction des erreurs de codage et pour produire un code de haute qualité. 155  Auto-correction Inspection de code (desk-checking) Technique d’examen du code Lecture croisée (author- reader cycle) Revue structurée Code walk-through 156 RÉVISION DU CODE : CODAGE DESK-CHECKING  Auto-correction (desk-checking) : c'est une relecture personnelle avec une efficacité quasi nulle pour les documents amont, faible pour le code. 157 RÉVISION DU CODE : CODAGE AUTHOR-READER  Lecture croisée (author-reader cycle) : un collègue qui cherche les ambiguïtés, les lacunes, les incertitudes du code. L'efficacité de cette méthode est faible pour les documents amont mais plus adapté pour la relecture du code. 158 RÉVISION DU CODE : REVUE STRUCTURÉE  Revue structurée : c'est la constitution d'une liste de défauts, pendant un débat dirigé par un responsable, en utilisant une liste de défauts typiques (checklist) cela a une bonne contribution à l'assurance qualité 159 RÉVISION DU CODE : INSPECTION  Inspection : C'est un cadre de relecture plus formel avec recherche des défauts avant les débats et un bon suivi des décisions et corrections cela a une excellente contribution à l'assurance qualité 160 RÉVISION DU CODE : C ODE WALK-THROUGH  On donne le code à des membres de l'équipe de développement, quelques jours avant la réunion de ‘walkthrough’. Chaque membre sélectionne certains cas de test et simule l'exécution du code à la main.  Les membres notent leurs remarques à en discuter dans la réunion où le ‘développeur’ du module est présent.  Les principaux objectifs sont : découvrir les erreurs algorithmiques et logiques dans le code. 161 RÉVISION DU CODE : C ODAGE WALK THROUGH  Même s’elle est une technique d'analyse informelle, plusieurs directives ont évolué au fil des ans pour faire de cette technique d'analyse utile et plus efficace:  L'équipe effectuant le walkthrough devrait par être ni trop grand ni trop petit. Idéalement, il devrait être composé de trois à sept membres.  La discussion devrait se concentrer sur la découverte d'erreurs et non pas sur la façon de corriger les erreurs découvertes.  Les Managers ne devraient pas participer à la réunion 162 walkthrough. DÉFAUTS TYPIQUES  1. Référence aux données : ⚫ Variables non initialisées ⚫ Indices de tableaux hors bornes ⚫ Accès à des structures/records à champs variables ou à des unions ⚫ Confusion entre donnée et pointeur vers la donnée ⚫ Déréférence de pointeurs nuls ⚫ Pointeurs sur des données désallouées ou pas encore allouées ⚫ Pointeurs sur des données devenues inutiles mais non 163 libérées DÉFAUTS TYPIQUES  2. Calculs : ⚫ Conversions de type (implicites et explicites) ⚫ Underflow/overflow (dépassement de capacité du type) ⚫ Division par zéro ⚫ Précédence des opérateurs 164 DÉFAUTS TYPIQUES  3. Comparaison : ⚫ incohérence des types : mélanges d'entiers et de booléens ⚫· inclusion ou non des bornes incorrecte : < au lieu de = au lieu de >, … ⚫ · inversion du test : == au lieu de !=, > au lieu de