Atelier de génie logiciel

Transcription

1 Atelier de génie logiciel Plan du cours I. Introduction II. III. IV. Principes de génie logiciel Modèles, processus AGL (windev) 1

2 I- introduction: 1- activité: Programme Logiciel I- introduction: 1- activité: Programme créer par un individu unique facile peut etre produit sans conception Logiciel la fabrication collective difficile concrétisée par les documents, conception, programmes et de jeux de tests multiples versions 2

3 1- definition: Le génie logiciel est un domaine des sciences de l ingénieur dont l objet d étude est la conception, la fabrication et la maintenance des systèmes informatiques complexes 2- objectifs: Activité: Seulement 15 % des applications écrites sont mises en place et fonctionnent! (selon des enquêtes réalisées aux USA) Pourquoi? 3

4 Pourquoi? Retards de livraisons Dépassements de budgets Technologies en mutation Complexité des applications Evolution des spécifications en cours de développement Objectifs de GL assurer que les 4 critères suivants soient satisfaits Fonctionnalités Le système qui est fabriqué répond aux besoins des utilisateurs La qualité correspond au contrat de service initial Les coûts restent dans les limites prévues au départ. Les délais restent dans les limites prévues au départ. Règle du CQFD : Coût Qualité Fonctionnalités Délai. 4

5 II- Principes de génie logiciel Cette partie liste sept principes fondamentaux (proposés par Carlo Ghezzi): rigueur séparation des problèmes modularité abstraction anticipation du changement généricité construction incrémentale rigueur le résultat d'une activité de création d un logiciel peut être évalué rigoureusement, avec des critères précis, exact. En pratique: Utilisation au maximum de lois mathématiques précises Suivi à la lettre de techniques formelles 5

6 séparation des problèmes C est une règle de bons sens qui consiste à considérer séparément différents aspects d un problème afin d en maîtriser la complexité diviser pour régner séparation des problèmes Séparation dans le temps avec la notion de cycle de vie du logiciel. Séparation des qualités que l on cherche à optimiser à un stade donné. Séparation des vues que l on peut avoir d un système. 6

7 séparation des problèmes Exemple: Comment créer dynamiquement une page internet pour visualiser et modifier le contenu d une BD sans la corrompre? Solution: Décomposition en trois composants: Modèle: son rôle est gérer le stockage des données. Vue: son rôle est visualiser les données. Contrôleur: son rôle est de n autoriser que les modifications correctes. modularité Un système est modulaire s il est composé de sous-systèmes plus simples, ou modules. 7

8 abstraction L abstraction consiste à ne considérer que les aspects jugés importants d un système à un moment donné, anticipation du changement Un logiciel est presque toujours soumis à des changements continuels Ceci requiert des efforts particuliers pour prévoir, faciliter et gérer ces évolutions inévitables. 8

9 généricité Il est parfois avantageux de remplacer la résolution d un problème spécifique par la résolution d un problème plus général. Cette solution générique pourra être réutilisée plus facilement Des solutions génériques (paramétrables, adaptables) sont plus facilement réutilisables. Classes génériques, héritage, construction incrémentale Un procédé incrémental atteint son but par étapes en s en approchant de plus en plus ; chaque résultat est construit en étendant le précédent. Par exemple : réaliser d abord un noyau des fonctions essentielles et ajouter progressivement les aspects plus secondaires. 9

10 III modèles Modèles en cascade Modèles en V Modèle en spirale Modèles incrémentaux Modèle en B III 1 le cycle de vie d'un logiciel : Analyse des besoins (Expression des besoins du produit) Spécification globale (Conception préliminaire, au niveau système) Conception architecturale et détaillée Implémentation (Programmation ou Phase de codage) Gestion de Configuration et Intégration Validation et Vérification Maintenance et Assistance 10

11 Répartition de l effort Avec ou sans génie logiciel 11

12 Analyse des besoins La première étape du cycle de développement d'un logiciel consiste à produire un document qui décrit les utilisateurs visés et leurs objectifs. «Que doit-on faire et qui utilisera le produit?». Analyse des besoins Mise du logiciel dans son contexte : type de produit, les objectifs des clients. Etude de l existant : - Etude des produits similaires dans le marché - Critiquer les produits concurrents - Etude du processus/logiciels existants à l entreprise 12

13 Spécification Globale (Conception préliminaire) C'est une description de haut niveau du produit, en termes de «modules» et de leurs interactions. «ce que doit faire le logiciel» Conception Architecturale et Détaillée: C'est au niveau de la conception détaillée que chacun des modules énumérés dans le dossier de conception préliminaire est décrit en détail Deux choses doivent émerger lors de cette étape : un diagramme de PERT ou de GANTT, montrant comment le travail doit être fait et dans quel ordre, ainsi qu'une estimation plus précise de la charge de travail induite par la réalisation de chacun des modules. 13

14 Conception Architecturale et Détaillée: On peut trouver différents type d architecture : Architecture orientée objets Architecture en couches Architecture orientée composants Architecture orientée services Conception Architecturale et Détaillée: Exemple: Architecture par couches Couche de présentation Couche métier Couche d accès aux données BD 14

15 Implémentation (Programmation): Chacun des modules décrits dans le document de spécification détaillé doit être réalisé. Gestion des Configurations et Intégration: Appelée aussi phase de déploiement. Quand tous les modules sont terminés, l'intégration, au niveau du système, peut être réalisée. C'est là que tous les modules sont réunis en un seul ensemble de code source, compilés et liés pour former un paquetage qui constitue le système. 15

16 Validation et Vérification: La validation a pour base les besoins que le produit doit satisfaire, et pour fonction la mise en évidence de défauts. Valider c'est répondre à la question : "Faisons nous le bon produit?" La vérification a pour fonction la mise en évidence d'erreurs. Vérifier c'est répondre à la question "Faisons nous le produit correctement?" Maintenance et assistance: Les défauts du logiciel rencontrés, soit pendant la phase de test soit après sa diffusion, doivent être enregistrés dans un système de suivi. Il faudra affecter un ingénieur logiciel pour la prise en charge de ces défauts, qui proposera de modifier soit la documentation du système, soit la définition d'un module ou la réalisation de ce module. 16

17 III.2 Le Modèle en Cascade: consiste en une succession de phases dont chacune est méthodiquement vérifiée avant de passer à l'étape suivante : Le principe de modèle en cascade est de découper le projet en phases distinctes sur le principe du non-retour. Lorsque une phase est achevée, son résultat sert de point d'entrée à la phase suivante. Etude préliminaire schéma Modèle en cascade Analyse des besoins Projets de petite taille Analyse du système Démarche basée sur la spécialisation des tâches dans un enchaînement de phases qui reste simple et intuitif Conception du système Développement Tests Installation Maintenance 17

18 III.3 Modèle en «V» (variante du modèle en cascade) L'assurance qualité est le processus qui permet de vérifier en continu la qualité du produit à fur et à mesure de sa fabrication. Le modèle en V met l'accent sur ce processus. Il confronte les différents niveaux de test avec les phases de projet de même niveau. Ceci permet à chaque étape de définir non seulement les fonctions, mais également les critères de validation. La cohérence entre les deux éléments permet de vérifier en continu que le projet progresse vers un produit répondant aux besoins initiaux. Ce modèle est adapté aux projets de taille et de complexité moyenne. Le modèle en «V» 18

19 Le Modèle en Cascade Avantages Simple et facile à comprendre Force la documentation : une phase ne peut se terminer avant qu un document soit validé Les progrès sont tangibles (pour l équipe de développement) Modèles en cascade Limites Modèle dirigé par les documents Non compréhensibles par les clients Le produit final est la première chose que voit le client Ne marche que si les besoins sont stables et le problème connu ne traite pas les évolutions Problèmes découverts en phase de validation 19

20 La nature changeante d un projet L environnement technique et économique évolue Les besoins et les souhaits des clients changent Les priorités du management aussi les méthodes en cascade ne marchent pas On ne peut pas attendre de tout savoir pour commencer Modèles incrémentaux Principes Diviser le projet en incréments Un incrément = une sous partie fonctionnelle cohérente du produit final Chaque incrément ajoute de nouvelles fonctions Chaque incrément est testé comme un produit final Les incréments sont définis a priori 20

21 Modèles incrémentaux La première version constitue le noyau Les versions suivantes s appuient sur l existant et étendent l architecture Chaque version donne lieu à un cycle de vie complet cycle de vie complet cycle de vie complet Version 1 Version 2 Version 3 Modèles incrémentaux Avantages Une première version du système est fournie rapidement Réduit le stress du management! Les risques d échec sont diminués Découverte des problèmes assez tôt Les parties importantes sont fournies en premier et seront donc testées plus longuement Les clients peuvent ajouter des besoins à tous moments 21

22 Modèles incrémentaux Limites Difficile à définir les incréments: Difficile de concevoir une architecture stable dès le début ou facilement évolutive Ne traite pas toutes les évolutions, notamment celles qui remettent en cause l architecture Le modèle en spirale Enfin le modèle en spirale, de Boehm (88), met l accent sur l évaluation des risques A chaque étape, après avoir défini les objectifs et les alternatives, celles-ci sont évaluées par différentes techniques (prototypage, simulation,...), l étape est réalisée et la suite est planifiée. 22

23 modèle en spirale Les modèles: Lequel choisir? Pas de modèle idéal Cascade : risqué pour les projets innovants évolutif : coûteux pour les projets clairs dès le début Pour les projets de taille petite ou moyenne (< l) Une approche incrémentale est souvent plus appropriée Pour les grands projets (multi-sites, multi-équipes) Approche mixte intégrant des aspects des modèles évolutifs et des modèles en cascade 23

24 Synthèse: Un cycle de vie apporte stabilité, contrôle et organisation des activités meilleure estimation des coûts et besoins meilleure coordination meilleure productivité meilleure visibilité et compréhension IV- spécification Tout produit complexe à construire doit d abord être spécifié ; par exemple un pont de 30 mètres de long, supportant au moins 1000 tonnes, construit en béton, etc. Ces spécifications peuvent être considérées comme un contrat entre un client et un producteur De manière générale une spécification décrit les caractéristiques attendues (le quoi) d une implantation (le comment). 24

25 Des techniques de spécification pour les phases d analyse Les spécifications en langue naturelle: elles manquent de structuration, de précision et sont difficiles à analyser. Les spécifications semi formels: pour spécifier des systèmes par des langages spécialisés(ada, UML, DFD, ). Formelle : quand la syntaxe et la sémantiques sont définies formellement par des outils mathématiques Les diagrammes de flots de données (DFD) Il s agit d une technique semi-formelle et opérationnelle. Les DFD décrivent des collections de données manipulées par des fonctions. Les données peuvent être persistantes (dans des stockages) ou circulantes (flots de données). 25

26 DFD La représentation graphique classique distingue : les fonctions par des cercles les stockages par des boîtes ouvertes les flots par des flèches les entités externes par des rectangles DFD d un guichet bancaire Client carte passwd Vérifier les informations du client Clients argent Somme à tirer Choisir la somme Les infos correctes Comptes Solde suffisant sortir l argent Argents 26

27 diagramme de contexte Au niveau le plus abstrait, on peut se contenter des entités à l interface ( acteurs ) et des flots qu ils s échangent, sans décomposition en fonctions. On parle alors de diagramme de contexte diagramme de contexte d un guichet bancaire carte passwd Client Somme à tirer argent Guichet 27

28 Exercice: On s'intéresse au processus des emprunts des livres dans une bibliothèque. Un étudiant se présente au guichet pour emprunter un livre, donne à l'employé de la bibliothèque la référence du livre voulu. l'employé demande à l'étudiant sa carte qui sera saisie à l aide d un lecteur optique (lecture du code à barres). Il vérifie ensuite si le livre est déjà emprunté ou non. Si le livre est présent dans la bibliothèque, il le donne à l'étudiant et met à jour la base de données. Si le livre est emprunté, il retourne à l'étudiant la date à laquelle il pourra avoir le livre. Il met à jour ensuite le statut du livre dans la base de données. Donner le DFD? Donner le diagramme de contexte? 28