Cours GL IGA Complet [PDF]

Zitiervorschau

Le Génie logiciel et La qualité logicielle - Introduction Dr. Youssef GAHI [email protected]

IGA Casablanca 2015-2016 1

Objectifs du cours (24 heures) 

Saisir l’importance du génie logiciel 



Comprendre le cycle de vie d’un logiciel et le rôle des différents intervenants. 



Analyse, Conception, Implémentation, Support…

Se familiariser avec les modèles de conception. 



Analyse des besoins, Contrôle de l’évolution…

Conception d’objets réutilisables, API, MDA…

Comment apporter de la qualité a un logiciel? 

Design Patterns, Scrum, Tests unitaire…

2

Plan du cours 

Introduction au génie logiciel (3h) Logiciel vs Génie logiciel  Pourquoi le GL ?  Les différents intervenants dans la production logicielle.  Cycle de vie d’un logiciel. Modèles, Techniques et Processus de développement (4h)  Cycle de développement  Objets réutilisables, API, MDA 



 

Etude de cas (2h) Outils permettant de créer des logiciels de qualités (6h)   



Qualité logicielle (6h) 



Outils de Conception Outils d’implémentation et de gestion Outils d’analyse Patrons de conception (Design Patterns)

Travaux Pratiques (3h)

3

Introduction au génie logiciel

4

Logiciel vs Génie logiciel 

Qu’est ce que c’est logiciel?

Programmes et la documentation associée – cahier de charges, modèles, manuels



Qu’est ce que c’est génie logiciel?

Le génie logiciel comporte des aspects de gestion de projet et des notions de qualité (satisfaire le client) Ceci en utilisant des méthodes, des modèles, et des outils.



Quelle est la différence entre génie logiciel et informatique? 5

Génie logiciel 

Développement en équipe d'un logiciel complexe 



Un intervenant = une (petite) partie du travail

Programmation : entre 15% et 35% du travail 

Analyse, conception, vérification, gestion de projet

Complexité croissante des logiciels  Sécurité  Coût du logiciel (>> coût du matériel) 

6

Pourquoi le GL? 

Si l'on veut maîtriser le développement de systèmes complexes, il faut : 

rédiger de façon claire les spécifications du système (ce que le client attend du produit)  



comment être sûrs que ces spécifications sont complètes ? comment être sûrs que ces spécification sont cohérentes ?

valider/vérifier toutes les étapes du développements 



a-t-on des moyens de validation/vérification (mathématiques) ? de réutiliser des sous-systèmes déjà réalisés (mais pas n'importe comment)  a-t-on des règles, des outils pour aider à la réutilisation ?



Maitriser les coûts.

7

Coût d’un logiciel 

Coût de développement 



Coût d’installation 



Effort jour-homme (entre 500 et 1000 euros par jour)

Frais de déplacement, avion, hôtel…

Coût de support/maintenance 

Résolutions des bugs, assistance… 8

Les défis devant le GL

9

Rôles des intervenants dans le développement logiciel

10

Les commerciaux Présenter des solutions pour les clients.  Accompagner les clients dans la définition de leur besoin (avec l’aide des analystes fonctionnels) 

11

Analyste fonctionnel-Concepteur Etude de faisabilité.  Transformer le besoin fonctionnel en une architecture logiciel.  Choix technologique 

  

Type d’architecture Protocoles Estimation grosse maille

12

Chef de projets Piloter et suivre l’avancement des projets.  Définir les différentes dates en collaboration avec les responsables de développements.  Assurer des réunions avec le client final et les responsables de développements.  Calculer et estimer les couts nécessaires ainsi que la rentabilité du projet. 

13

Responsable de développements Architecture logicielle  Suivre l’avancement de l’équipe  Communiquer les livraisons ou Annoncer les retards.  Assurer des réunions avec les différentes parties notamment les chef de projets. 

14

Développeur 

La réalisation de toute la matière logicielle du projet.  

 

Codage des traitements Tests Préparation des binaires et des scripts Documentation

15

Intégrateur 

Vérification des prérequis



Installation et configuration du produit



Validation des recettes de tests.



Rapport de missions

16

Les partenaires 

Equipes externes



Sous-traitants



Institut



Stagiaires

17

Cycle de vie d’un logiciel

18

Cycle de vie d’un logiciel Analyse des besoins  Spécifications (Contrat commercial)  La conception fonctionnelle et technique  La Réalisation  Vérification et Validation  L’intégration  La recette interne et recette fonctionnelle  La formation  Documentations  Maintenance et évolution 

19

Analyse des besoins Fonctionnalités attendues du système  Point de vue métier, de l'utilisateur  Aider à formuler le besoin  Produit un document textuel, avec schémas, intelligible par le client  Conduit à la définition du cahier des charges => les "spécifications" 

20

Spécifications Ce que doit faire le système  Produit un document textuel avec schémas, lisible par toutes les parties  Base du contrat commercial  Base des tests de vérification de la phase d'installation 

21

Conception générale Comment réaliser le logiciel ?  Choix techniques : explorer plusieurs solutions… Décrire la solution retenue  Architecture générale 



Composants  





Structures de données Fonctionalités

Interactions entre ces composants

Tous les éléments de la spécification doivent être pris en compte 22

Conception détaillée Décompose chaque composant en souscomposants, jusqu'au niveau où le codage devient facile  Précise pour chaque composant : 

  



Son interface Les algorithmes Le traitement des erreurs

Produits :  

L'ensemble de ces descriptions Le plan des tests unitaires (jeux de données) 23

Implémentation Traduction dans un langage de programmation des différents modules  Mise au point  Tests de développements  Commentaires 

24

Vérification et Validation 

Vérification 



Revues des spécifications (checklist)

Validation 

   

Analyse du produit: Sécurité, Gestion des mot de passes… Plateformes de tests indépendante. Beta et Alpha Test Recette des tests interne Tests de charge

25

Test (1) Dans la pratique, il convient d’intégrer les développements unitaires au sein de l’architecture technique cible, tout en testant la cohérence fonctionnelle et technique globale de l’application, avant livraison et installation sur le site du client.



 

Les tests réalisés seront :

Un test spécifique du Framework après développement sur la base de la conception définie au début de la conception fonctionnelle et technique,



Un test de réception des composants achetés pour le projet (modules sous-traités),



Les tests unitaires des fonctions développées,





Les tests d’assemblage sur les plates-formes de développement avec données réelles permettant entre autres le test des procédures de reprise, Les test d’intégration sur les plates-formes, 26



Les tests de charge sur chaque module.

Test (2)  







Tests des composants externes

L’objectif de cette étape est de s’assurer que l’ensemble des composants externes à l’application sont conformes sur les plans fonctionnel et métier aux spécifications prévues dans les phases de conception. Sur un plan technique, il s’agit de s’assurer que le composant technique ne crée aucune interaction non-souhaitée (ou interférence) de par son installation, registration, instanciation,… Les composants externes sont par exemple et suivant les technologies employées des composants OCX, VBX, DLL… La qualification technique pourra avoir été réalisée dans le cadre d’un 27 projet antérieur

Test (3)  

Ces tests sont réalisés au fil de l’eau par l’équipe de développement. Chaque personne de cette équipe consigne que le développement de la fonction X a été réalisé par lui et après exécution en environnement de développement ou sur simulateur. Il s’agit de confirmer que cette fonction est conforme aux spécifications fonctionnelles et techniques décrites.

 

Tests Unitaires

Tests d’assemblage

Ces tests sont réalisés par le chef de projet ou sous son autorité par une personne de l’équipe de développement détachée sur cette mission. Cette phase permet de s’assurer que l’ensemble des composants techniques développés ou acquis s’interfacent correctement : l’application fonctionne sans défaillance, les résultats attendus sont 28 conformes sur les axes règles de calcul et règles de gestion. Cette phase s’effectue sur le jeu d’essai de développement.

Test (4)  

Cette phase de test s’effectue sur une plate-forme d’intégration déclarée conforme par le client à l’environnement de production. Cela concerne tant les aspects techniques (OS serveur, base, client) que les interfaces (entrantes notamment), ainsi que le jeu de données.

 

Tests d’intégration

Tests de charge

L’objectif de cette phase est d’effectuer une montée en charge des données entrantes et existantes dans l’application. La base de données sera chargée avec une volumétrie équivalente au fonctionnement nominal de l’application. Les transactions devront s’effectuer dans les temps de réponses prévues lors de l’élaboration du cahier de charge. A défaut de temps de réponse décrit, l’application devra prouver qu’elle fournit les réponses attendues avec la volumétrie nominale. 29

Installation Dernière étape avant exploitation  Installer le logiciel dans son environnement opérationnel  Vérifier le logiciel dans son environnement opérationnel  Organiser la formation  Planifier la transition 

30

Recettes 

Préparation des procédures de vérification/validation du logiciel 



plan de validation

Version provisoire des manuels :  

d'utilisation et d'exploitation du logiciel

31

Recettes (1)  

Il s’agit d’une validation interne, effectuée par la direction projet, des livrables avant fourniture au client du lot réalisé. La recette interne assure que le chef de projet en charge du projet suit le déroulement des actions de la contractualisation à la mise en œuvre du résultat prévu.

 

La recette interne

La recette fonctionnelle

La recette fonctionnelle est effectuée par le client et plus spécifiquement par le Chef de Projet Utilisateur du Client. Elle est usuellement effectuée sur la plate-forme de développement ou la plate-forme d’intégration. Les compléments et/ou évolutions détectées lors de la recette fonctionnelle peuvent donner lieu à l’établissement 32 d’avenant(s) au contrat

Formations 

La formation peut prendre plusieurs formes. Elle peut viser les utilisateurs mais aussi les équipes techniques (exemple : les équipes de maintenance). Différentes déclinaisons sont envisageables en fonction du contexte projet considéré : 





Les sessions de formation : elles s’appuient sur l’alternance d’un enseignement théorique et des mises en pratiques immédiates (TP). Les sessions de formation doivent impérativement être intégrées dès le début dans le plan projet pour qu’elles soient optimales. Le transfert de compétences : il est principalement dédié aux équipes techniques d’exploitation ou de maintenance. L’objectif est de traiter sur la fin du projet l’ensemble des points critiques du projet en parfaite transparence. L’accompagnement en production : il se met en place lorsque la montée en charge et/ou le déploiement représente(nt) un enjeu majeur et critique du projet. Ainsi, l’ensemble des anomalies 33 pouvant survenir sont traitées en collaboration directe avec l’équipe projet.

Documentation Les manuels d'utilisation et d'exploitation doivent être prêts au plus tard lors de l'installation  Selon la complexité du logiciel : 

  

 

Guide d'installation Guide de l'utilisateur Guide de l'opérateur Manuel de référence Documentations des composants logiciels 34

Guide d’installation Fonctionnalités du logiciel  Architecture  Interfaces utilisateurs  Comportements en cas d'erreurs  Performances requises  Interfaces avec autres logiciels  Interfaces avec le(s) matériel(s)  Contraintes de réalisations (matériels, logiciels, normes…) 

35

Guide de l’utilisateur Le document décrivant l'architecture générale  Un plan d'intégration, avec un plan des tests d'intégration (procédures de tests, jeux de données) 

36

Maintenance et évolution 

Corrections des erreurs



Prise en compte de nouveaux cas d'utilisation



Ajout de nouvelles fonctionnalités

37

Cycle de développement d’un logiciel

38

Rappel 

C’est quoi un logiciel ? Programmes et la documentation associée – cahier de charges, modèles, manuels



C’est quoi Le Génie Logiciel ? Le génie logiciel comporte des aspects de gestion de projet et des notions de qualité (satisfaire le client) Ceci en utilisant des méthodes, des modèles, et des outils.



Les intervenants dans le Génie Logiciel?

Les Commerciaux, Analyste, Chef de Projets, Resp. de Dev, Développeur, Intégrateur, Partenaires. 

Les étapes du Génie Logiciel ?  

      



Analyse des besoins Spécifications (Contrat commercial) La conception fonctionnelle et technique La Réalisation Vérification et Validation L’intégration La recette interne et recette fonctionnelle La formation Documentations Maintenance et évolution

39

Le Cahier des charges 

Le cahier des charges est un document par lequel un demandeur (entreprise, organisme privé ou public) exprime le besoin devant être satisfait par un objet à concevoir. Pour cela, il précise les fonctions de service qu'il doit assurer et les contraintes à respecter. C'est un contrat qui engage le concepteur.



Il servira de "consigne de recherche" pour que les idées abstraites de départ débouchent sur un projet concret. Pour chaque fonction, il définira également les critères rentrant en compte, le niveau de performance attendu et la flexibilité tolérée.



Pour ne rien oublier lors de la rédaction du CdCF on se doit d'être rigoureux et méthodique.

40

Le processus de définir les besoins Etude de faisabilité

Trouver les besoins et analyse Spécification des besoins Validation des besoins

Rapport de faisabilité Modèles du système Besoins d’usager et du système

Document des besoins (Cahier de charge) 41

Cahier des charges d'un robot aspirateur L'expression du besoin

Le besoin Réduire le temps consacré au ménage en réalisant de manière automatique le passage de l'aspirateur. La réponse actuelle au besoin De nombreuses entreprises fabriquant des aspirateurs traditionnels ont le projet de concevoir ce type d'aspirateur. Actuellement, très peu de produits fiables sont disponibles sur le marché. Les objectifs Réaliser un aspirateur robot fiable pouvant remplacer un aspirateur traditionnel, à un prix acceptable pour les ménages. Les interventions humaines 42 sont à limiter au maximum.

Cahier des charges d'un robot aspirateur

2 2 3

Fonctions de service et contraintes Aspirer la poussière au sol sans intervention de l'utilisateur Aspirer la poussière sous les meubles Aspirer le long des murs et des obstacles Éviter les obstacles en douceur

4

Passer sur des obstacles (tapis, seuils de porte...)

5 6

Ne pas tomber dans les escaliers Stocker la poussière aspirée

7

Assurer la sécurité des personnes et des animaux

8 9 10

Doit être esthétique Être transportable Pouvoir être rangé dans un placard

1

43

Cahier des charges fonctionnel Exemple : Support de téléphone portable Fonctions Doit permettre de maintenir un téléphone mobile. Doit être visible la nuit

Doit assurer la sécurité de l'utilisateur.

Doit plaire, Doit être beau, esthétique Doit être résistant Sera posé (support de téléphone mobile) sur un plan horizontal pour une lisibilité aisée de 44 l'écran.

Cahier des charges fonctionnel Application : Support de téléphone portable Fonctions Être réalisable au collège Être compétitif (coût matière maxi 5 euros) Doit être peu onéreux

Assurer une bonne autonomie

45

Le processus de logiciel 

Activités 

  

Spécification – qu’est ce que le logiciel doit faire et les contraintes posées au développement Développement - production logiciel Validation – vérification si le logiciel est celui qui est attendu du client. Evolution – modification du logiciel en accordance avec les besoins.

46

Modèles génériques Effet Tunnel  Cascade  Modèle en V  Modèle en W  Modèle en Spirales  Développement évolutif et itératif  Développement itératif incrémental  Basé à l’assemblage de composants 

47

L’effet tunnel Un jour, peut-être ...

Le départ est connu

Le modèle de développement en tunnel n’offre aucune visibilité sur l’état d’avancement du logiciel. 48

Le modèle en cascade 

Cycle de vie linéaire sans aucune évaluation entre le début du projet et la validation



Le projet est découpé en phases successives dans le temps



Chaque phase ne peut remettre en cause que la phase précédente.



Le développement en cascade est en général rythmé par la génération de documents qui servent de validation pour le passage d’une phase à l’autre



Chaque phase est donc achevée avant que ne débute la suivante. 49

Cascade

50

Cascade 

Problèmes  



Avantages 



Il est difficile de séparer les étapes On peut l’utiliser quand les besoins sont bien définis et ils sont stables. Bien documenté à chaque phase

Désavantages



Rigide (on ne peut pas de répondre au besoins nouveaux ou modifiés des clients) Les vrais projets suivent rarement un développement séquentiel. Etablir tous les besoins au début d’un projet est difficile. Aucune validation intermédiaire (aucune préparation des phases de vérification)



Sensibilité à l’arrivée de nouvelles exigences refaire toutes les étapes

   

51

Le modèle en « V » 

A ce jour, le cycle en V reste le cycle de vie le plus utilisé. C’est un cycle de vie orienté test



A chaque activité créative (spécification, conception et codage) correspond une activité de vérification (validation, intégration, tests unitaire)



Chaque phase en amont prépare la phase correspondante de vérification (la vérification est prise en compte au moment même de la création). 52

Le modèle en « V »

53

Les limites des cycles de vie en « V » Les cycles de vie sont trop longs. Les relations entre les clients et les fournisseurs ne sont pas suffisamment formalisées.  Ils ne gèrent pas les risques.  L’intégration est trop tardive dans le cycle de vie.  La documentation est réalisée d’abord et le logiciel après …  

54

Cycle en V 

Avantage: 



La préparation des dernières phases (validationvérification) par les premières (construction du logiciel), permet de d’éviter d’énoncer une propriété qu’il est impossible de vérifier objectivement après la réalisation.

Inconvénients:    

Construit-on le bon logiciel? le logiciel est utilisé très (trop) tard Il faut attendre longtemps pour savoir si on a construit le bon logiciel Difficile d’impliquer les utilisateurs lorsque qu’un logiciel utilisable n’est disponible qu’à la dernière phase. Idéal quand les besoins sont bien connus, quand 55 l’analyse et la conception sont claires.

Le modèle en « W » Ce modèle est une variante du modèle en « V ».  Le cycle de développement ne commence que quand les problèmes ou les besoins sont parfaitement connus (cf. module de communication selon la méthode Merise).  Un cycle en « W » peut être couplé à un cycle en « V », quand il est nécessaire de décomposer le système en sous-systèmes. 

56

Le modèle en « W » Exigences brutes

Spécification des IHM du système

Vérification des flux logiques

Validation ou tests d’acceptation

Conception des sous-systèmes

Intégration et tests des sous-systèmes

Conception des modules

Intégration et tests des modules

2ème cycle de Goldberg Codage et tests unitaires

57

Le modèle en spirale  





Ce modèle complexe est dû à Boehm. Il apporte une vue évolutive au modèle en cascade au travers d’une approche fondée sur l’analyse et la gestion des risques, puis la conception et la réalisation de prototypes évolutifs en fonction de l’avancement du projet. Le développement présente quatre grandes phases qui se succèdent au fur et à mesure de la construction de la spirale, Au dernier tour de la spirale, le produit est totalement défini, les risques résolus et le produit développé. 58

Développement spirale

59

Le modèle en spirale 







Premier cycle : Analyse du risque → Prototype 1 → Simulations et/ou modélisations et/ou bancs d'essais → Définition de la mission (par la MO) → Planification de l'analyse (c'est-à-dire du cycle suivant, portant principalement sur un travail d'analyse) Second cycle : Analyse du risque → Prototype 2 → Simulations et/ou modélisations et/ou bancs d'essais → Définition (par la ME) et validation (par la MO) des besoins → Définition du plan de développement (c'est-à-dire des deux cycles suivants, consacrés à la conception, au codage, aux tests et à la mise en oeuvre du logiciel) Troisième cycle : Analyse du risque → Prototype 3 → Simulations et/ou modélisations et/ou bancs d'essais → Définition (par la ME), vérification (par la ME) et validation (par la MO) de la conception générale → Réajustement, le cas échéant, du plan de développement (ne concerne que la conception détaillée, le codage, les tests et la mise en oeuvre du logiciel) Quatrième cycle : Analyse du risque → Prototype 4 → Simulations et/ou modélisations et/ou bancs d'essais → Conception détaillée, codage, tests divers et mise en oeuvre du logiciel 60

Développement spirale 

Secteurs   



Préciser les objectifs Définir et minimiser le risque Développement et validation Planifier l’itération suivante

61

Processus évolutif

Aperçu de description

Spécification

Version initiale

Développement

Versions intermédiaires

Validation

Versions finale

62

Le cycle itératif incrémental Risques initiaux, portée du projet

Planification de l’itération Développement de l’itération Itération N

Évaluation

Révision du plan du projet Risques éliminés Révision des risques 63

Itération

Phase

Objectif

Itération préliminaire

Etude d’opportunité

Comprendre le problème

Décision Ressources pour l’élaboration

Itération d’architecture

Elaboration

Comprendre la solution

…xN

…

… Ressources pour la construction

Itération de développement

Construction

Réaliser la solution

…xN

…

… Livrer le produit (version bêta)

Itération de transition …xN

Transition …

Transmettre la solution … Recette client 64

Les avantages des cycles de vie itératifs et incrémentaux 



Ces processus sont basés sur l’évolution de prototypes exécutables :  L’utilisateur est placé devant des situations d’utilisation concrètes. Il est partenaire du projet.  L’intégration est progressive et permet d’éviter l’effet « big bang » à l’approche de la date de livraison.  Les progrès se mesurent par des programmes démontrables et non par des documents ou estimations. Le découpage par incréments permet de réduire la complexité du système en la ventilant dans les incréments. 65

Développement par composants

Spécification des besoins

Analyse des composants

Conception avec réutilisation

Modification des besoins

Développement et intégration

Validation

66

Origine et définitions 

Problèmes   





Fiabilité – comment l’utilisateur va croire que le composants ne va pas échouer Certification – qui va certifié le composant Les propriétés intégrales – comment les prévoir Compromis des besoins – comment faire le compromis entre les besoins assurés des différents composants

Caractéristiques     

Standardisé Indépendant Composable Déployable Documenté 67

Interface de composants

Requires interface Defines the services from the component’s environment that it uses

Provides interface Component

Defines the services that are provided by the component to other components

68

Composants et objets Les composants sont déployables  Les composants ne définirent pas des types  L’implémentation des composants est opaque  Les composants sont indépendant de langage  Les composants sont standardisés 

69

Modèles 

Définition 



Le modèle de composants c’est la définition des standard pour implémentation, documentation et déploiement du composant

Exemples   

EJB .NET (COM+) Corba Component Model

70

Eléments du modèle Customisation

Naming convention Composition Interface definition

Specific interfaces

Interfaces

Documentation Meta-data access Usage information

Packaging

Evolution support

Deployment and use

Component model

71

Gestion des risques 

Qu’est ce que c’est risque? La probabilité que quelque circonstances défavorables vont arriver



Types de risque   

De projet – affecte l’emploi de temps ou les ressources De produit – affecte la qualité et le comportement du logiciel D’organisation – affecte le l’organisation

72

Gestion des risques Identification de risque  Analyse de risque 





Planifier le risque 



Estimer la probabilité et conséquences; Plans d’éviter et minimiser les effet du risque;

Suivi du risque

73

Gestion des risques

Identification des risques

Analyse

Planifier

Suivi

Liste de risques potentiels

Liste prioritaire des risques

Plans pour éviter les risques et d’urgence

Estimer le risk

74

Gestion des risques 

Identification du risque    





Technologiques Personnel. Organisation. Besoins. Estimation.

Analyse – La probabilité et les effets du sinistre  

Probabilité – très basse, basse, modérée, haute, très haute. Effets – catastrophique, sérieux, tolérable, insignifiant.

75

Gestion des risques 

Planifier – pour chaque risque   



Stratégie d’éviter le risque – diminuer la probabilité Stratégie de minimisation – minimiser l’effet du sinistre Plan d’urgence – quand l’événement arrive qu’est ce qu’on doit faire.

Suivi   

Estimer chaque risque par périodes réguliers pour voir si la probabilité a changé. Estimer les effets de chaque risque Ne pas voir peur de discuter les problèmes

76

Annexe 

Cahier de Charge: 



est le recueil des exigences fonctionnelles demandées par la maîtrise d'ouvrage, il décrit des règles de gestion et de traitement dans le langage du métier (vue externe du système, c'est la vision utilisateur).

Cahier de Spécifications: 

est la traduction du cahier des charges en termes plus techniques (données en entrée, données en sortie, description des écrans de l'IHM, règles de calcul, de transformation des données, ...) dont le but est de décrire de façon détaillée comment les exigences fonctionnelles vont être implémentées 77

Annexe (1) 

Spécifications:     

Des scenarii plus détaillés Base de la conception du système Ils peuvent être inclus dans le cahier de charge et dans le contrat On peut utiliser et des modèles du système (les UML diagrammes) Ils sont interdépendants avec l’architecture du système

78

Annexe (2) 

Désavantages de la langue naturelle   



Ambiguïté Sur-flexibilité Manque de structure

Alternatives    

Langues structurées – formulaires, modèles, tableaux Langages spécifiques – rarement utilisés Notations graphiques – UML Spécifications mathématiques 79

Annexe (3) Modifier un item

Ajouter un item

Supprimer un item Consultation de l’inventaire

Commande fournisseur

Saisir livraison

Responsable des opérations Produire des rapports

80

Annexe (4) 

Spécifications fonctionnelles   



Le guichet doit vérifier la validité de la carte insérée Le guichet doit valider le code PIN. Le guichet doit allouer une somme maximum de 5000 DH

Spécifications non fonctionnelles:   

Le système de Guichet doit être réalisé en C++ Le système doit utiliser un cryptage de 256 bits Le système doit vérifier le PIN en moins de 3 sec.

81

Méthodes d’analyse et de Conception

82

Analyse et Conception 

Analyse du système   

modélisation du domaine, modélisation de l’existant (éventuellement), définition d’un modèle conceptuel (ou spécification conceptuelle), plan de validation.



On élabore un dossier d’analyse plus un plan de validation.



Conception    



proposition de solution au problème spécifié dans l’analyse organisation de l’application en modules et interface des modules (architecture du logiciel), description détaillée des modules avec les algorithmes essentiels (modèle logique) structuration des données

On élabore un dossier de conception plus un plan de test global et par module

83

Méthodes d’Analyse et de Conception 

Proposition d ’une démarche distinguant les étapes du développement dans le cycle de vie du logiciel (modularité, réduction de la complexité, réutilisabilité éventuelle, abstraction)



Utilisation d ’un formalisme de représentation qui facilite la communication, l’organisation et la vérification



Production de documents (modèles) qui facilitent les retours sur conception et l’évolution des applications

84

Techniques de Conception 

Méthodes fonctionnelles hiérarchiques 



Méthodes données 



Data-Flow/SADT/SA-SD, Structure-Chart, ...

Entité-Relation, MERISE, UML

Méthodes comportements 

Réseaux de Pétri, ... 85

Méthodes fonctionnelles: SADT 

SADT : technique structurée d'analyse et de modélisation

86

Méthodes fonctionnelles: SADT (2)

87

Méthodes fonctionnelles: SADT (3)

88

Méthodes fonctionnelles: Data Flow

sang

Paramètres du sang Capteur de glucose sanguin

Analyse de glucose sanguin

Niveau du glucose

Calcul du besoin d’insuline insuline

Instructions vers la pompe

Pompe d’insuline

Gestion de délivrance d’insuline

Besoin d’insuline

89

Méthodes fonctionnelles: Data Flow (2) Visio 2000

Visio 5.x From Flow Chart / Data Flow Diagram

From Software Diagram / Gane-Sarson DFD

From Flow Chart / Data Flow Diagram

ID #

Process Process

Process

Data Store Data Store

1

Data Store

ID #

External Entity

External Entity

External Entity

90

Méthodes fonctionnelles: Data Flow (3)

91

Méthodes fonctionnelles: Data Flow (4)

92

Méthodes données: Entité-Relation 





Entité [définition de Chen] :  chose qui peut être identifiée distinctement Propriété (ou Attribut) :  les entités (et les associations) sont décrites par des propriétés caractérisées par un nom et un type Association [définition de Chen] :  Lien entre entités  elle peut être binaire, ternaire, n-aire

93

Méthodes données: Entité-Relation (2)

94

Méthodes données: Merise 

Merise 

  

Une approche systémique Approche fonctionnelle A une vision duale des données-traitements A trois niveaux d’abstraction   

Niveau conceptuel Niveau logique Niveau physique

95

Méthodes données: Merise - MCT

96

Méthodes données: UML Système réel

Analyse Modèle d’Analyse

Conception Modèle de Conception

Réalisation Modèle de Réalisation

Déploiement Modèle de Déploiement

BOOCH, OMT, OOSE,…

UML (Unified Modeling Language)

97

Méthodes données: UML (2) Résumé • UML est une notation, pas une méthode • UML est un langage de modélisation objet • UML convient pour toutes les méthodes objet

Programmation Orientée Objet modéliser informatiquement des éléments d'une partie du monde réel en un ensemble d'entités informatiques (objets) Intérêt d'une méthode objet • définir le problème à haut niveau sans rentrer dans les spécificités du langage • définir un problème de façon graphique • utiliser les services offertes par l’objet sans rentrer dans le détail de programmation (Encapsulation) • Réutilisation du code 98

Méthodes données: UML (3) Voiture Numéro de série : Int Poids : double Immatriculation : String Kilométrage : double

FIAT-UNO-17 233434 : Numéro de série 1500 kg : Poids 8864 YF 17 : Immatriculation 33 000 : kilométrage

Démarrer () Arrêter() Rouler()

Renault-Clio-17 5323454 : Numéro de série 1500 kg : Poids 64 YFT 17 : Immatriculation 23 000 : kilométrage

Peugeot-206-75 3434 : Numéro de série 1700 kg : Poids 8634 YGG 75 : Immatriculation 15 000 : kilométrage

99

Méthodes données: UML (4) 



Vues statiques  Les diagrammes  Les diagrammes  Les diagrammes  Les diagrammes  Les diagrammes

de classes d’objets de cas d’utilisation de composants de déploiement

Vues dynamiques  Les diagrammes  Les diagrammes  Les diagrammes  Les diagrammes

de séquence de collaboration d’états-transition d’activités

100

Méthodes données: UML (5)

Cas d’utilisation

Acteur

Objectif du système, motivé par un besoin d'un (ou plusieurs) acteur(s) Personne ou composant d’origine d’une interaction avec le système Documente un élément du modèle

Note

Relation d’utilisation

Le cas source contient aussi le comportement décrit dans la cas destination

101

Méthodes données: UML (6)

102

Méthodes comportements Réseaux de Pétri  





C'est un ensemble d'automates à états finis communicants Pour pouvoir analyser :  on représente les états internes des automates et les communications entre les automates avec les mêmes primitives Graphe avec deux types de nœuds  les états (partiels = des automates) sont des ronds ce sont les places  les transitions (arcs dans la représentation des automates) sont des rectangles (barres) Les communications  asynchrones : ajout (ou fusion) de places  synchrones : fusion (ou ajout) de transitions 103

Méthodes comportements Réseaux de Pétri (2)

104

Outils d’Analyse et d’implémentation

105

Les outils de génie logiciel Outils  Outils  Outils  Outils  Outils  Outils  Outils  Outils 

d’Analyse de design de modélisation (diagrammes) de programmation de gestion de projet de prototype de qualité de maintenance 106

Outils d’Analyse Ces outils permettent de rassembler les besoin et les obligations.  Vérifier les redondance et traduite automatiquement les spécifications textes vers des schémas basique.  Exemples: 



  

Accept 360. Visual Paradigm. CaseComplete. Visible Analyst. 107

108

Outils de Design Ces outils aident les concepteurs de logiciels pour concevoir la structure du bloc du logiciel qui peut en outre être décomposé en modules plus petits en utilisant des techniques de raffinement.  Ces outils montrent l’interaction entre les différents gros modules.  Exemples: Animated Software Design 

109

110

111

Outils de modélisation Ces outils sont utilisés pour représenter les composants du système, les données et les flux de contrôle.  Ces composants sont représentés en frome graphique tout en montrant l’interaction entre les différents objets.  Exemples: Flow Chart Maker, jMerise, Rational Roze, ArgoUML. 

112

113

114

115

Outils de prototypage Prototype de logiciel est une version simulée du logiciel prévu. Le Prototype fournit une première impression du produit et simule quelques aspect du produit réel.  Un outil de prototypage est compose de plusieurs briques graphiques pour créer une version rapide.  Exemples: Windev, Dreamweaver, Mockup Builder, Visual Sudio, NetBeans. 

116

Outils de prototypage (2)

117

Outils de programmation 

Ces outils consistent a construire les modules et les différents composants.



Ces outils permettent aussi de générer des livrables, simuler et tester les fonctionnalités.



Exemples: Eclipse, NetBeans, Visual Studio 118

Outils de programmation: Eclipse

119

Outils de programmation: NetBeans

120

Outils de programmation: V. Studio

121

Outils de Gestion de Projet Ces outils sont utilisés pour la planification du projet, le coût, l'effort, planification de projet et planification des ressources.  Les gestionnaires doivent respecter strictement l'exécution du projet à chaque étape mentionnée dans la gestion de projet logiciel.  Outils de gestion de projet aident à stocker et partager des informations sur le projet en temps réel dans toute l'organisation.  For example: SCRUM. 

122

Les méthodes agiles 

Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit collaboratif avec juste ce qu’il faut de formalisme

 

Elle génère un produit de haute qualité tout en prenant en compte l’évolution des besoins des clients



Concepts formalisés en 2001 par le Manifeste Agile. 123

Les méthodes agiles (2)  Les 4 principes essentiels du Manifeste Agile:  L'équipe : Personnes et interactions plutôt que processus et outils

 L'application :Logiciel fonctionnel plutôt que documentation complète  La collaboration :Collaboration avec le client plutôt que négociation de contrat  L'acceptation du changement :Réagir au changement plutôt que suivre un plan.

124

Scrum – Principes clés 



Scrum est une méthode agile qui permet de produire la plus grande valeur métier dans la durée la plus courte. Méthode itérative et incrémentale: 

Réalisation d’un ensemble de fonctionnalités par itération Itération d’une durée fixe (d’2 à 4 semaines)// sprint



Livraison d’un produit partiel fonctionnel par itération





Participation du client:  

Définition des fonctionnalités prioritaires Ajout de fonctionnalités en cours de projet (pas pendant un sprint !)

125

Scrum – Les rôles 

Les rôles:  



Le product owner Le scrummaster L’équipe

12 6

Scrum – Planifier un projet LCL GUR Remaining 300

250

Number

200

150

100

50

0 0

1

2

3

4

5

6

7

8

9

10

11

12

Jour



Constitution du backlog produit par le product owner.



Répartition en sprints et en releases. 127

Scrum – Organisation 1/5

Source : www.scrumalliance.org

1. Backlog produit (ou catalogue des besoins)  Besoins priorisés par le product owner  Besoins évalués par l’équipe 128

Scrum – Organisation 2/5

Source : www.scrumalliance.org

2. Backlog de sprint  Extrait du backlog produit  Besoins éclatés en tâches 129

Scrum – Organisation 3/5

3. Sprint  Développement des fonctionnalités du backlog de sprint  Aucune modification du backlog de sprint possible 130

Scrum – Organisation 4/5

Source : www.scrumalliance.org

4. Mêlée quotidienne  Point de contrôle quotidien de l’équipe  Interventions régulées – 2 min. par personne 131

Scrum – Organisation 5/5

Source : www.scrumalliance.org

5. Incrément logiciel : livré au product owner à la fin du sprint. 132

Scrum – Indicateurs de projet 1/2 

Le tableau des tâches

133

Scrum – Indicateurs de projet 2/2 

Le burndown chart

134

Scrum – Ingénierie logicielle 

Scrum est une méthode de gestion de projet



Doit être complétée par des techniques d’ingénierie logicielle



Complémentaire avec Extreme Programming :  

Test Driven Development Intégration continue 135

Outil de qualité 

Assurance de la qualité dans un développement logiciel consiste a mettre en place un processus d'ingénierie et des méthodes adoptées pour développer le produit conforme selon les normes du standard.

 Qualité logicielle.

136

Qualité Logiciel 

Les outils de versionning 



Les tests unitaires 





Junit

L’intégration continue 



SCM, SVN, SubVersion

Hudson, Jenkins

Les outils de compilation Inspection de code 

Sonar, 137

Qualité Logiciel: Versioning 

Gérer les sources dans le temps



Conserver un historique de toutes les modifications - plusieurs versions de chaque fichier



Coordonner les travaux de plusieurs auteurs



Montrer les différences entre les versions d'un fichier



Modifications du document - la raison du changement

138

Qualité Logiciel: Versioning (2) client

checkout (first time)

(do some work, test) check status update (resolve conflicts) commit (do more work, test)

server

Envoyer la version ( n ) Vérifier s’il y a des changements Mettre a jour la version locale par celle du serveur Mettre a jour le serveur par le contenu local

Qualité Logiciel: Versioning (3) Repository parent dir

Root Project 1

Project 1

trunk

trunk

tags

tags

branches

Project 2

branches

Project 2

trunk

trunk

tags

tags

branches

branches

Qualité Logiciel: Versioning (4)

/var/svn/kuclock revision 4 revision 3 revision 2 revision 1 (initial repo structure)

revision 3:  content diffs  author  date 

reason for change (comment)

revision 2:  initial project check-in  ...etc...

Qualité Logiciel: Versioning (5) 0

Numéro de la révision est augmentée pour chaque transaction qui modifie le repository.

1

2

3

Propriétés d’un Repository   

Histoire de toutes les modifications apportées aux fichiers et répertoires. Il est possible de récupérer une version précédente d'un fichier. Contrôle d’accès  



Autorisation de lecture / écriture pour les utilisateurs et les groupes Les autorisations peuvent appliquer à repo, répertoire ou un fichier

Logging   

Auteur du changement La date du changement La raison du changement

SVN cycle de vie Soumettre les changements

Créer une copie locale svn checkout svn update

Subversion Repository

svn commit 106

100

Fixer les conflits

Faire des changements svn add svn move svn delete

svn diff svn resolved 105

Vérifier ce qui a été changé

svn status -u

Mettre a jour la copie locale svn update

Qualité Logiciel: Les tests unitaires 

Junit

145

Qualité Logiciel: Les tests de charge 

jMeter

146

Qualité Logiciel: Les tests de non régression 

Cahier de Tests

MyIcIphone Client

Tel : +33 (0)2 98 14 30 40

Doc Reference

Author Audited by Approved by

Fax : +33 (0)2 98 14 39 06

Mail : [email protected]

Title Test document

File Name MyIcIphone – MyIcTestGuide.doc

Fonction

Name

Ingénieur développeur Team Leader / Contact Administrative Manager

Y. Gahi

Alcatel-Lucent Services for Enterprise All Rights Reserved © Alcatel-Lucent 2007

147

Qualité Logiciel: L’intégration continue

Spécifications

Spécifications

Développeme nt

Intégration

Développement Intégration

148

Qualité Logiciel: L’intégration continue

149

Qualité Logiciel: L’intégration continue 

Hudson

150

Qualité Logicielle: Outil de compilation 

Debuggage

151

Qualité Logicielle: Inspection du code 

Cobertura et Sonar

152

Qualité Logicielle 4 Build + Tests 5 Déploiement

$ Gcc –c *.c –o test Compiling… Compilation Sucessfull Testing… Junit tests … OK Integration tests … OK Performance tests … OK Code Inspection … 86% Deploying in test environnement … OK

Serveur de test

6 Notification

Serveur d’intégration 3 Update

Serveur de recette

2 Vérification des

modifs

Postes de dev

Serveur de production

1 Commit

SCM

Outils de maintenance 

La maintenance du logiciel comprend des modifications dans le produit logiciel après sa livraison.



Des logs automatiques, des prise d’ecrans, rapports techniques…



Exemples: Bugzilla, JIRA.

154

Outils de maintenance (2): Bugzilla 

Bugzilla

155

Design Patterns

156

Les patrons de conception 

Patron de conception = design pattern

Un design pattern traite un problème de conception recurrent.  Ne pas réinventer la roue.  Facilite la communication entre développeurs 



Il apporte une solution générale, indépendante du contexte  Description de l'organisation de classes et d'instances en 157 interaction pour résoudre un problème de conception

les patrons de conception (2)  

Quatre éléments principaux définissent un patron Objectif 



Problème / Motivation 





Quand appliquer le patron de conception Relations problématiques entre les classes

Solution proposée   



Description de son utilité

Eléments impliqués Relations entre les éléments Schémas conceptuels (e.g., diagrammes UML)

Conséquences  

Compromis éventuels Qualité de la solution 158

Catégories de Design Patterns 

Création  



Structure 





Description de la manière dont un objet ou un ensemble d’objets peuvent être créés, initialisés, et configurés Isolation du code relatif à la création, à l’initialisation afin de rendre l’application indépendante de ces aspects Description de la manière dont doivent être connectés des objets de l’application afin de rendre ces connections indépendantes des évolutions futures de l’application Découplage de l’interface et de l’implémentation de classes et d’objets

Comportement  

Description de comportements d’interaction entre objets Gestion des interactions dynamiques entre des classes et des objets

159

Design Patterns du GoF

160

Création 

Abstraction du processus de création.



Encapsulation de la logique de création.



On ne sait pas a l'avance ce qui sera créée ou comment cela sera créé.

161

Création: Singleton 

Problèmes: 

 



Certaines applications possèdent des classes qui doivent être instanciées une seule et unique fois Assurer qu'il n'existe qu'une seule instance de la classe Fournir un moyen d'obtenir cette instance unique

Solution: 

Une seule instance est renvoyée a chaque fois 162

Cas d’utilisation 

le cas d’une classe qui implémenterait un pilote pour un périphérique, ou encore un système de journalisation. En effet, instancier deux fois une classe servant de pilote à une imprimante provoquerait une surcharge inutile du système et des comportements incohérents.

163

Meilleur Solution La première étape consiste à empêcher les développeurs d’utiliser le constructeur de la classe pour l’instancier  déclarer privé tous les constructeurs de la classe. 

Nous allons construire un pseudo constructeur. 

il faut déclarer une méthode statique qui retournera un objet correspondant au type de la classe 

164

Exercice 

On veut créer un Aeroport ainsi que des objets de type Avion. Voici le code des classes Aeroport et Avion, ainsi que de la classe test de l'ensemble.

On souhaite que les clients, les objets de type Avion, ne puisse pas créer plus d'un Aeroport,afin qu'ils se situent tous dans un même Aeroport. Comment empêcher la possibilité à un Avion de créer un Aeroport s'il en existe déjà un ? 

165

Création: Factory 

Problèmes:  



Le client ne peut déterminer le type d'objet à créer qu'à l'exécution Il y a une volonté de centraliser la création des objets

Solutions: 



Concevoir une classe qui va instancier différents types d'objets suivant un paramètre fourni Des applications individuelles de définir elles166 mêmes leurs propres objets à créer

Cas d’utilisation 



une usine va fabriquer des produits en fonction du modèle qu'on lui indique. L'idée la plus simple pour répondre à ce besoin est d'écrire une succession de conditions qui suivant le modèle demandé, instancie et retourne l'objet correspondant. Le problème avec cette implémentation, c'est que la classe correspondant à l'usine va être fortement couplée à tous les produits qu'elle peut instancier car elle fait appel à leur type concret. Or ce code va être amené à évoluer régulièrement lors de l'ajout de nouveaux produits à fabriquer ou de la suppression de certains produits obsolètes.

 On se retrouve alors avec du code fortement couplé, qui risque d'être dupliqué à plusieurs endroits de l'application. 167

Meilleur Solution La première solution est de regrouper l'instanciation de tous les produits dans une seule classe chargée uniquement de ce rôle.  On évite alors la duplication de code et on facilite l'évolution au niveau de la gamme des produits.  L'utilisateur du produit fait appel à la Fabrique Simple pour obtenir un Produit.  L'utilisateur du produit est donc fortement couplé uniquement à la Fabrique Simple et non à tous les produits 168 qu'il prend en charge. 

Meilleur Solution (2) 

Etape 1: Créer un interface

 Etape2: Créer les Classes

 Etape3: Créer le Factory

169

Meilleur Solution (3) 

Etape4: utiliser le Factory

170

Exercice Modifier la structure pour Eviter les duplications et optimiser l’architecture a l’aide du concept Factory. Règles: 1) On définit un interface qui contient la méthode commune. 2) Toutes les classes implémente l’interface. 3) On définit une nouvelle classe qui se charge de la création des différents objets. 4) La nouvelle n’utilise pas le type Programme1,… mais plutôt l’interface générique. 5) Le client ne communique qu’avec cette classe.

171

Structure 

Ces modèles de conception tentent de composer des classes pour bâtir de nouvelles structures.



Comment sont assemblés les objets.



Découpler l'interface de l'implémentation.



On obtient donc une structure plus large mais toujours facilement manipulable.

172

Structure: Adaptateur 

Problème:  



L’utilisation d’une classe existante dont l’interface ne nous convient pas. Utilisation de plusieurs sous-classes dont l’adaptation des classes est impossible par dérivation

Solutions: 



L'Adapteur ou Adapter est un moyen commode de faire fonctionner un objet avec une interface qu'il ne possède pas. L'idée est de concevoir une classe supplémentaire qui se charge d'implémenter la bonne interface (L'Adapteur) et d'appeler les méthodes correspondantes dans l'objet à utiliser (L'adapté). 173

Cas d’utilisation 

Le système doit intégrer un soussystème existant. Ce sous-système a une interface non standard par rapport au système.



Cela peut être le cas d'un driver bas niveau pour de l'informatique embarquée. Le driver fournit par le fabricant ne correspond pas à l'interface utilisée par le système pour d'autres drivers. 174

Meilleur Solution La solution est de masquer cette interface non stantard au système et de lui présenter une interface standard. La partie cliente utilise les méthodes de l'Adaptateur qui utilise les méthodes du soussystème pour réaliser les opérations correspondantes. 

175

Structure: Composite 

Problème: 



Etablir des structures arborescentes entre des objets et les traiter uniformément.

Solutions:  

Le modèle Composite cherche à éliminer toute différence entre un groupe d'objets et un objet. Il s'agit d'une démarche récurrente valable pour tous les problèmes qui font émerger de nouvelles structure par association.

176

Cas d’utilisation 

Vous avez l'impression d'utiliser de multiples objets de la même façon, souvent avec des lignes de code identiques ou presque. Par exemple, lorsque la seule et unique différence entre deux méthodes est que l'une manipule un objet de type Carré, et l'autre un objet Cercle. Lorsque, pour le traitement considéré, la différenciation n'a pas besoin d'exister, il serait plus simple de considérer l'ensemble de ces objets comme homogène.

177

Meilleur Solution 



Un exemple simple consiste à considérer l'affichage des noms de fichiers contenus dans des dossiers :  Pour un fichier, on affiche ses informations.  Pour un dossier, on affiche les informations des fichiers qu'il contient. Dans ce cas, le patron composite est tout à fait adapté :  L'Objet est de façon générale ce qui peut être contenu dans un dossier : un fichier ou un dossier,  L'ObjetSimple est un fichier, sa méthode affiche() affiche simplement le nom du fichier,  L'ObjetComposite est un dossier, il contient des objets (c'est à dire des fichiers et des dossiers). Sa méthode affiche() parcourt l'ensemble des objets qu'il contient (fichier ou dossier) en appelant leur méthode affiche().

178

Comportement 

Description de structures d’objets ou de classes avec leurs interactions.



Le modèle de comportement simplifie l'organisation d'exécution des objets.



ils définissent comment organiser les objets pour que ceux-ci collaborent (distribution des responsabilités) 179

Comportement: Observateur 

On trouve des classes possédant des attributs dont les valeurs changent régulièrement.



Un certain nombre de classes doit être tenu informé de l’évolution de ces valeurs.

180

Cas d’utilisation  





On considère une classe HeurePerso possédant dans le même attribut l’heure et la minute courante. Cette classe est utilisé par une autre classe AfficheHeure pour l’affichage de l’heure courante dans un écran. Quelle démarche adopter pour que la classe chargée de l’affichage soit tenue informée en temps réel de l’heure courante stockée dans la classe HeurePerso ? Deux solutions possibles:  

Soit la classe d’affichage se charge de demander à la classe HeurePerso la valeur de son attribut soit c’est la classe HeurePerso qui informe la classe AfficheHeure lors de changements.

181

Meilleur solution: Obesrvateur L’interface Observateur sera implémenté par toutes classes qui souhaitent avoir le rôle d’observateur.  la classe ObservateurConcret qui implémente la méthode actualiser(Observable). Cette méthode sera appelée automatiquement lors d’un changement d’état de la classe observée.  On trouve également une interface Observable qui devra être implémentée par les classes désireuses de posséder des observateurs. 

182

Comportement: Iterateur 

Problème: 





Une collection contient un ensemble d'objets stocké par différentes méthodes (un tableau, un vecteur...). L'exploitant qui accède a contenu de la collection ne souhaite pas être concerné par cette manière de gérer les objets.

Solution: 

Un seule interface qui gère tout type d’objets

183

Meilleur Solution 

Un itérateur ressemble à un pointeur disposant essentiellement de deux primitives:  Accéder à l'élément pointé en cours (dans le conteneur)  Se déplacer pour pointer vers l'élément suivant

184

Merci pour votre attention Questions / Réponses

185