Cours GL-L3NTIE Lakhrissi

Le Génie Logiciel

IUP NTIE

2010/2011

Sophie Ebersold & Younes Lakhrissi

2

Le génie logicielPartie I

Notions de base & Principes

Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 3

Plan de la Partie I

1 1 -- DDééfinitions de basefinitions de baseLogicielGénie logicielCritères de la qualité logicielle

2 2 -- Cycle de vie de logicielCycle de vie de logicielObjectifPhases nominales du développement logiciel

3 3 -- ModModèèles de cycle de vieles de cycle de vieModèles linéaires Modèles non linéaires


Logiciel ?

DDééfinition : finition : Un logiciel ou une application est un ensemble de programmes, qui permet à un ordinateur ou à un système informatique d'assurer une tâche ou une fonctionnalité

Physiquement :Une suite d’items ou d’objetsune structure d’informations Incluant programmes, données, documents, …

Le logiciel n’est pas seulement un ensemble de programmes, mais aussi la documentation pour :

l’installation,l’utilisation,le développement,la maintenance.


Les différentes catégories de logiciel (1/3)

Sur mesureSur mesurePour un client spécifique

GGéénnéériqueriqueVendu sur le marché• un tableur (spreadsheet), un outil de base de donnée (database) • un outil de traitement de texte (word processor)• …

EmbarquEmbarquééssExécutent dans du matériel électronique isolé

machine à laver, télévision, lecteur DVD, téléphone mobile,magnétoscope, four à micro-ondes, réfrigérateur, joueur MP3, ...

Difficile à modifier


Logiciel Logiciel àà temps rtemps rééelelSystèmes de contrôle et de surveillanceManipulent et contrôlent le matériel techniqueRéaction immédiate requiseEnvironnement contraignant

Logiciel de traitement de donnLogiciel de traitement de donnééesesIls stockent, recherchent, transforment et présentent l'information aux utilisateursGrandes quantités de données avec des corrélations complexes, enregistrées dans les bases de donnéesLargement utilisés en administration des affairesFiabilité des résultatsSécurité dans l’accès aux données

Quelques fois les 2 aspects sont prQuelques fois les 2 aspects sont préésents dans un logicielsents dans un logiciel



Les systLes systèèmes distribumes distribuééssSynchronisent la transmission, assurent l’intégrité des données et la sécurité, ...Technologies utiliséesCORBA, DOM/DCOM/.NET, SOAP, EJB, …

Les systLes systèèmes de matmes de matéérielrielSystèmes d'exploitation, exécutions de matériel de bas niveau

Les systLes systèèmes d'entreprisemes d'entrepriseDécrivent les buts, les ressources, les règles et le travail réel dans une entreprise



La nature du logiciel (1/3)

Le logiciel est facile Le logiciel est facile àà reproduirereproduireTout le coût se trouve dans son développementPour d’autres produits, la fabrication est souvent le processus le pluscoûteux

Le logiciel est intangibleLe logiciel est intangibleIl est difficile d'estimer l’effort de développement

Le processus de dLe processus de dééveloppement est difficile veloppement est difficile àà automatiserautomatiserL’industrie du logiciel exige beaucoup de main d’œuvre

Même des informaticiens peu qualifiMême des informaticiens peu qualifiéés peuvent s peuvent arriver arriver àà bricoler bricoler quelque chose qui semble fonctionnerquelque chose qui semble fonctionner

La qualité d’un logiciel n’est pas apparente


Un logiciel semble facile Un logiciel semble facile àà modifiermodifierLa tentation est forte d’effectuer des changements rapides sans vraiment en mesurer la portée

Un logiciel ne sUn logiciel ne s’’use pasuse pasIl se détériore à mesure que des changements sont effectués

en raison de l’introduction d’erreurs ou par une complexification indue

Beaucoup de logiciels sont mal conBeaucoup de logiciels sont mal conççus et se dus et se dééttéériorent riorent rapidementrapidement

La demande pour du logiciel est toujours croissanteLa demande pour du logiciel est toujours croissante



Raisons pour lesquelles le logiciel vieillit :Raisons pour lesquelles le logiciel vieillit :Maintenance (bug fixes)Erosion architecturaleInflexibilité dès le débutDocumentation insuffisante ou inconsistanteManque de modularitéComplexité croissante, …

Un logiciel est fiable sUn logiciel est fiable s’’il :il :Répond aux spécificationsNe produit jamais de résultat erronéNe jamais entrer dans un état incohérentRéagir de façon sensée et utile en présence d’une situation inattendue



Art de produire du logicielArt de produire du logicielArt de spécifier, concevoir, 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 ordinateur pour résoudre certains problèmes.

Art de bien faire de bons LogicielArt de bien faire de bons LogicielArt : technique, créativité, esthétique,…Bien faire : réussite, rentabilité,…Bons : performance, fiabilité,…

On parle de processus de dOn parle de processus de dééveloppement de logiciels et gestion de veloppement de logiciels et gestion de projets projets

Gestion du personnel : Efforts Gestion des ressources : CoûtsAspects techniques : Conception & Réalisation Contraintes de réalisations : Planification

Le Génie Logiciel ?


Le génie logiciel

Les points communs des dLes points communs des dééfinitions finitions Travail de groupe et non d’un individu isoléBesoins techniques et non-techniques

Connaissances informatiquesCapacité de communicationGestion de projet

Objectif du GLObjectif du GLDévelopper des logiciels considérés comme :

Logiciels fiablesLogiciels satisfaisant les besoinsLogiciels maintenablesLogiciels exploitables dans différents environnement


Le génie logiciel - Origine

Origine : Apparu en 1968, devant les insatisfactions gOrigine : Apparu en 1968, devant les insatisfactions géénnéérales en rales en matimatièère de logiciel : re de logiciel :

Fiabilité douteuseDépassement des délais Dépassement des coûtsErreurs résiduelles persistantesSensibilité aux erreurs humaines, aux pannes matériellesDifficultés de conversion, de mise en œuvreDifficultés d'évolution

+ Complexité croissante du logicielCoût croissant lié en grande partie à la maintenance (excessive)

+ Criticité des secteurs d'activité


Le génie logiciel - Risques

Risques majeurs du dRisques majeurs du dééveloppement logiciel veloppement logiciel Défaillance humaine

Calendrier et Budget irréaliste

Développement de fonction inappropriées

Développement IHM inapproprié

Produit « plaqué-or »

Volatilité des besoins

Composants externes manquants

Problèmes de performances,

….


Quelques statistiques

ÉÉtude du gouvernement amtude du gouvernement amééricain en 1979ricain en 1979

Payés mais jamais livrés 45%Livrés mais jamais utilisés 30%Abandonnés ou refaits 20%Utilisés après modification 3%Utilisés tel quel 2%

Part des erreurs

64%

36%

erreurs de définition.erreurs de codage


Les critères de qualité du logiciel

Validité

Robustesse

Extensibilité

Réutilisabilité

Compatibilité

Efficacité

Portabilité

Vérifiabilité

Intégrité

Facilité d'utilisation

: Conformité d'un logiciel avec sa spécification

: Capacité à fonctionner même dans des conditions anormales

: Facilité d'adaptation à des changements de spécifications

: Capacité à être réutilisé en tout ou partie dans une nouvelle application

: Facilité avec laquelle des composants logiciels peuvent être combinés

: Utilisation optimale des ressources matérielles

: Facilité de transfert dans différents environnements

: Facilité de préparation des procédures de validation

: Aptitude à protéger codes et données

: Ergonomie, Facilité d'apprentissage


Cycle de vie du logiciel ?

Le développement d’un grand système logiciel prend un temps considérableOn identifie un certain nombre d’étapes dans la période de développementCes étapes constituent le cycle de vie du logiciel

Définition :C’est le processus qui couvre le déroulement des phases de développement, de distribution et de disparition d’un logiciel Le logiciel est le résultat d’un processus d’élaboration constitué d’une suite d’étapes ou phases ayant pour objectifs de passer du QUOI (Spécification) au COMMENT (Conception).Chaque phase utilise des produits en entrée et génère des produits en sortie, qui sont utilisés dans les phases ultérieures.


Cycle de vie du logiciel

ObjectifsObjectifsMaîtriser les coûts en terme de délai et de budget

Maîtriser les risquesAvoir une qualité conforme aux exigences

C’est la feuille de route du développement logiciel

Le cycle de vie est fortement lié à l’assurance qualité

Il faudra en permanence assurer la vérification et la validationVérification : Est-ce que nous construisons bien le produit ?

Validation : Est-ce que nous construisons le bon produit ?


Cycle de vie du logiciel

Phases du cycle de viePhases du cycle de vie

Définition des objectifs

Définition des besoins

Analyse des besoins

Planification et gestion de projet

Conception globale

Codage et tests unitaires

Intégration

Qualification

Maintenance


Phase de définition des objectifs/besoins

But : Première description du futur systèmeDescription de ce que doit faire le logiciel, indépendamment de l'implantation (QUOI et non COMMENT)

Définition des objectifsÉtude de faisabilitéStratégieDécider du besoin de produire le logicielÉlaboration du schéma directeur (vue globale, orientations, suggestion, planification)

Définition des besoinsÉtablir le Cahier des Charges (CDC)Lancement d’appel d’offresLe CDC décrit les fonctionnalités attendues du produit, les contraintes non fonctionnelles (temps de réponse, contraintes matérielles,…)

Produits issus de cette phase : Le cahier des chargeProduits issus de cette phase : Le cahier des chargess


Le cahier des charges

Définition C’est un document technique Rédigé par l’équipe marketing ou par le clientS’adresse au client et aux développeurs et sera à la base du contrat

Les besoins relevés dans le CDC doivent être :PrécisCohérentsCompletsTestables par une métriqueMaintenables et flexibles


Le cahier des charges

CritCritèères de succres de succèèssSe placer à un bon niveau de généralité

Décrire bien le problème posé

Définir les critères de validation

Exprimer facilement les changements au niveau des besoins

Le rédacteur du CDC doit avoir les qualités suivantes :Capable d’abstraction et de structurationCapable de connaître et anticiper le processus de développementAvoir un recul


Phase d’analyse des besoins

But Étude du domaine d'application et de l'état actuel de l'environnement du futur système :

FrontièresRôleRessources disponibles et requisesContraintes d'utilisation et de performance

DémarcheÉlaboration des spécificationsDescription des contraintes de réalisationÉbauche du manuel d’utilisation

Produits issus de cette phase :Une ébauche du manuel d’utilisateurUne ébauche du glossaire propre au projetLe dossier d’analyse

Doit fournir une description complète et détaillée des fonctions du produit dans sa relation avec l’environnementSera utilisé par le client et par les développeursDéfinit les termes du contrat passé entre le client et le fournisseur du logiciel


Dossier d’analyse (DA): principes de base

Le DA contient la description du produit vu de lLe DA contient la description du produit vu de l’’extextéérieur, pour en drieur, pour en déériver :river :La documentation clientLes jeux de test

Dossier dDossier d’’analyse : plan typeanalyse : plan typeIntroduction

Objectifs, fonctionnalités attendues, environnement, faisablité, éléments de coûts,…

Fonctions du produitConcepts et terminologie, description fonctionnelle externe (entrées-sorties, IHM,…)

Description interneInteraction avec environnement, contraintes,…

Questions ouvertes et réponses apportées par les développeurs

Éléments de livraisonCahier provisoire de recette


Phase de planification et gestion de projet

Démarche Découpage du projet en tâchesEnchaînement de tâches dans le tempsAttribution de durée et d’effort à chaque tâche

Produits issus de cette phase :Le plan qualitéLe plan projet destiné aux développeursUne estimation des coûts réelsUn devis destiné au client


Phase de conception

Conception architecturale Définition de l’architecture du logicielDécomposition du logiciel en composants plus simples et spécification modulaireÉlaboration des interfaces entre les différents modulesProduits issus de cette phase :

Le dossier de conceptionLe plan d’intégrationLes plans de testLe planning mis à jour

Conception détailléeEnrichir la description du logiciel de détails d'implantation afin d'aboutir à une description proche de la programmation.Produits issus de cette phase :

Pour chaque composant : description des fonctions à réaliser : algorithmes, représentation des données


Phase de codage et tests unitaires

Chaque module est codé individuellementEntrée : Résultat de la conception détailléeProduit : Ensemble de programmes ou de composants de programme

Chaque module est testé indépendamment des autresProduits issus de cette phase :

Les modules codés et testésLa documentation de chaque moduleLes résultats des tests unitairesLe planning mis à jour

Part de chaque activité dans l'effort total de développement

20%

40%

40% programmationSpécification et ConceptionValidation et Vérification


Phase de gestion de configuration et Intégration

Gestion de configurationPermettre la gestion des composantsEn maîtriser l'évolutionEn faire les mises à jour tout au long du processus de développementProduits issus de cette phase :

Documents relatifs au développement du logiciel

Intégration : Assemblage de composants pour obtenir un système exécutableChaque module testé est intégré avec les autres selon le plan d’intégrationL’ensemble des modules est testé conformément au plan de testsProduits issus de cette phase :

Le logiciel testéLes tests de régressionLe manuel d’installationLa version finale du manuel utilisateur


Phase de Qualification et Maintenance

QualificationLe produit est testé en vraie grandeur dans des conditions d’utilisation normalesÀ l’issue de cette phase, le logiciel est prêt à l’exploitation

MaintenanceAprès livraison, le logiciel entre dans la phase de maintenanceAu fur et à mesure que l’environnement change, le système doit s’adapter à ces changementsCe processus de changement s’appelle l’évolution du logicielLa maintenance d’un logiciel consiste à en corriger les erreurs et àmodifier le système pour refléter les changements de l’environnement


Activités transversales

Validation et vValidation et véérificationrificationBut :

Validation : Contrôler l'adéquation entre les besoins des utilisateurs spécifiés lors de l'analyse des besoins et les fonctionnalités du logicielVérification : Contrôler l'adéquation de la spécification globale et du logiciel

Moyens : Revues, Inspections de manuels et Maquettage pour la validationPreuves et Tests pour la vérification (tests unitaires, tests d'intégration, tests système)

MaquettageMaquettageUtilisé lors de la validation, afin de fournir un aperçu des fonctionnalités du système final (prototype rapide).Soumis à de scénarii en liaison avec les futurs utilisateurs : permet de préciser leurs souhaits ou leurs choix (maquette exploratoire)Expérimentation et confrontation de choix de conception différents (maquette expérimentale)


Modèles de cycle de vie


Modèles ?

DDééfinition :finition :Un modèle est une abstraction de quelque chose de réel qui permet de comprendre avant de construire, ou de retrouver les informationsnécessaires pour effectuer des modifications et extensionsLe modèle simplifie la gestion de la complexité en offrant des points de vue et niveaux d’abstractions + ou - détaillés selon les besoins

JJ--L. L. LemoigneLemoigne, 1990, 1990«Action d’élaboration et de construction intentionnelle, par composition de symboles, de modèles susceptibles de rendre intelligible un phénomène perçu complexe et d’amplifier le raisonnement de l’acteur projetant une intervention délibérée au sein du phénomène : raisonnement visant notamment à anticiper les conséquences de ces projets d’action possibles»



DDééfinition :finition :Permettent d'avoir une méthodologie commune entre le client et la société de développement Définissent et concrétisent les étapes du développementDéfinit et planifier les documents à produire permettant de valider chacune des étapes avant de passer à la suivante

Le rôle des modLe rôle des modèèles les Faciliter la compréhension humaine et la communicationSupporter l’amélioration des processus de développement et de maintenanceSupporter la conduite et la gestion des processus de développement et de maintenanceAssurer un guidage automatique des acteursFaciliter l’automatisation des processus de développement et de maintenance



Les modLes modèèles linles linééairesairesLa cascadeLe modèle transformationnelLe modèle en YLe modèle en VLe modèle en XLe modèle en W

Les modLes modèèles non linles non linééairesairesLe prototypage Le modèle en spirale Le modèle par incrémentsLe modèle évolutif


Modèles de cycle de vie linéaires


La cascade

PrincipePrincipetoutes les étapes doivent être réaliséesordre respectépassage de l'étape n à l'étape n+1 qu'après acceptation de l'étape nremises en cause de l'étape n propagées uniquement jusqu'à l'étape n-1

Définition des besoins

ConceptionLogiciel

Intégration etValidation

Maintenance


La cascade

AvantagesAvantagesFacile à comprendreCe modèle est approprié lorsque les besoins sont bien clarifiés et les changements sont très limités durant la conception du processusPlus utilisé dans l’industrie

Limites Limites Pas transparent au client lors du développementDifficulté de répondre aux besoins changeants du clientPas de frontières claires entre conception et développementDifficulté d’apporter des changements après finalisation du processusUne phase doit être achevée avant de pouvoir passer à la phase suivante

Ce modCe modèèle est en gle est en géénnééral abandonnral abandonnéé au profit du modau profit du modèèle en V plus le en V plus rréécent et actuellement, dans les mcent et actuellement, dans les mééthodes objetthodes objet


Le modèle en V

Principe :Principe :La représentation en V tient d'avantage compte de la réalitépart du principe que les procédures de vérification de la conformité du logiciel aux spécifications doivent être élaborées dès les phases de conceptionIl montre que:

c'est en phase de spécification que l'on se préoccupe des procédures de qualificationc'est en phase de conception globale que l'on se préoccupe des procédures d'intégrationc'est en phase de conception détaillée que l'on prépare les tests unitaires

Chaque étape prend en entrée les résultats de l'étape précédente et les documents produits.


Le modèle en V


Le modèle en V


Modèle en W


Le modèle en Y

Un processus en 2 chemins ou modUn processus en 2 chemins ou modèèle en Y le en Y

La branche fonctionnelle correspond La branche fonctionnelle correspond àà la tâche traditionnelle de la tâche traditionnelle de modmodéélisationlisation

du domainedu problème à résoudre des besoins des utilisateurs.

L'ajout d'une branche technique indL'ajout d'une branche technique indéépendante pendante il faut faire des choix en matière de techniques

La troisiLa troisièème branche : une synthme branche : une synthèèse des 2 chemins :se des 2 chemins :articuler le mieux possible des composants "métier" avec des composants technologiques pour produire une solution logicielle


Le modèle en Y


Le modèle en Y

La branche technique ; exemples de choix :La branche technique ; exemples de choix :Une BD centrale unique ou des BD réparties qui communiquent entre elles. mise en œuvre de composants autres que le seul stockage et accès sécurisé aux données :

interfaces utilisateurs,communication de l'information via des réseaux (locaux, intranet, internet...), présentation de l'information sur les postes de travail, etc.


Le modèle transformationnel

Suppose un systSuppose un systèème automatique de transformation des me automatique de transformation des spspéécifications validcifications validéées en programmes. es en programmes.

Trois scTrois scéénarios dnarios d’’automatisation automatisation 1. les spécifications formelles des besoins sont traduites à l’aide d’outils

appropriés en un logiciel opérationnel2. les spécifications formelles des besoins sont décrites et traduites à

l’aide d’outils appropriés en des spécifications détaillées exécutables3. le code est généré à l’aide d’outils logiciels tels que les générateurs de

code

Spécification

Validation

Transformation


Le modèle en X

Repose sur le principe de la rRepose sur le principe de la rééutilisabilitutilisabilitééPropose deux processus de dPropose deux processus de dééveloppement concurrents des veloppement concurrents des logicielslogiciels

Le premier processus consiste en la réalisation de solutions logicielles réutilisables (DER ou « Build for Reuse »)Le second processus consiste à produire des solutions logicielles àpartir d’une base de solutions existantes (DAR ou « Build with Reuse »)

La rLa rééutilisabilitutilisabilitéé dans le moddans le modèèle le «« en Xen X »» peut être rpeut être rééalisaliséée e ààplusieurs niveaux :plusieurs niveaux :

au niveau de l’architecture logique ou physique des composants au niveau de l’architecture conceptuelle (domaine d’intérêt du sujet)au niveau des modèles du domaineau niveau des spécifications


Les modèles de cycle de vie linéaire - Synthèse -

Avantages :Avantages :Processus ordonné et discipliné du développementConception robuste Meilleur contrôle de la qualité et la maintenance

InconvInconvéénients :nients :Pas de recouvrement des phasesEffort de documentation important à chaque phaseReprises coûteuses en cas de divergences par rapport à la compréhension des besoins utilisateur


Les modèles de cycle de vie non linéaires

PrincipePrincipeLes logiciels réalisés suivant ces modèles sont développés par itérations ou incréments successifsLes détails de réalisation peuvent être reportés afin de produire une version opérationnelle du logiciel le plus tôt possible au cours du processus de développementCes modèles semblent plus appropriés pour prendre en compte le caractère évolutif des besoins des utilisateurs et les applications novatrices

Exemples de modExemples de modèèles non linles non linééairesairesLe prototypage Le modèle en spirale Le modèle par incrémentsLe modèle évolutif


Le Prototypage

DDééfinition : finition : l’élaboration de versions opérationnelles du futur logiciel dès le début du cycle de vie la mise en évidence et la clarification par expérimentation des problèmes les plus significatifsl’élaboration de prototypes qui constituent une base de discussion et de communication entre les utilisateurs, les informaticiens et les autres acteurs de l’organisation

Le logiciel est ensuite dLe logiciel est ensuite dééveloppveloppéé àà nouveau dans le souci de satisfaire nouveau dans le souci de satisfaire les critles critèères de qualitres de qualitéé

Consulter Client

Tester le prototype

Construire oumodifier prototype


Le prototypage

SpécificationsGrossières

Réalisation du Prototype

Evaluation Spécification du système

Conception etImplantation

Validation duSystème


Le prototypage

AvantagesAvantagesClient est acteur dans le processusClient reçoit des résultats rapidementPermettre de se concentrer sur les points critiques, les zones d’incertitudes très tôt dans le développementSimplifier l’élaboration des spécifications, de l’interface H/M: les spécifications ne sont plus écrites mais montrées

InconvInconvéénients :nients :Problèmes relatifs à la conduite du développementProblèmes relatifs à la gestion de projetQualité du produit développé est souvent faibleProduit non commercialisable


Le modèle par incréments ou par grappes

Principe : Principe : Développement du logiciel noyau puis développement et intégration des composants, successivement.



AvantagesAvantages : : Développement moins complexe et itératif

Développement ascendant : des incréments généraux (fonctions utilitaires) aux incréments spécifiques (proches de l’application)

Intégrations progressives : Ordonnancement flexible des incréments (fonctions des ressources, de l’expérience de l’équipe, des demandes de la direction, et des clients, …)

Ordre des étapes du cycle de vie respecté pour chaque incrément

Relations entre incréments : chaque incrément peut être client d’incréments de niveau inférieur

Livraison et mise en service possibles après chaque intégration d’incrément

Effort de maintenance dune version provisoire généralement négligeable



InconvInconvéénients :nients :Il faut spécifier dès le début du développement de l’architecture globale du logiciel et les différents lots qui seront développés: le noyau, les incréments (qui doivent être indépendants fonctionnellement), leur intégration Risque de voir remettre en cause le noyau ou les incréments précédents un développement L ’ajout de composants peut être complexe Chaque développement est de + en + complexe, du point de vue de l ’intégration

Solutions :Solutions :Spécification noyau, incréments et interactions au début du projetIncréments aussi indépendants que possible (fonctionnellement et dans le temps) : Contradiction


Le modèle évolutif

Le dLe dééveloppement veloppement éévolutif consiste volutif consiste ààrrééaliser :aliser :

une version provisoire du logiciel (prototype) qui sera mise en exploitation

des nouvelles versions de ce logiciel opérationnel (prototype) comprenant de nouvelles fonctionnalités ou une version modifiée des fonctionnalités déjà installées

La version finale comportera toute la documentation, la formation, ...pour la mise en exploitation du logiciel

Détermination des besoins

Programmation

Expérimentation

Version n +1

Version n


Le modèle évolutif

InconvInconvéénientsnientsComme dans le modèle incrémental, la réalisation d’une nouvelle version comporte plus de risques que celle de la version précédenteDifficulté d’obtenir dans les délais les résultats de l’évaluation par les utilisateurs de la nouvelle version du prototypeDifficulté de gestion des différentes versions du logiciel et de traçabilitéde leurs composantsDifficulté de déterminer le niveau de qualité du prototype et de sa documentation


Le modèle en spirale

Principe : Principe : Cycles de développement successifs du logiciel

Un prototype identifié par cycle

Quatre quadrants représentant quatre phase de développement pour chaque cycle

Analyse préliminaire, détermination des objectifs du cycle, des alternatives, des contraintes

Analyse des risques, Evaluation des alternatives, Prototypage

Développement et Vérification de la solution

Tests, Revue des résultats, Planification du cycle suivant





Avantages :Avantages :Produit rapidement un logiciel opérationnel minimal. Permet de ce concentrer sur les aspects les plus incertains du développementSuppose une discipline stricte pour éviter de « coder/finaliser ». Il faut accepter les remises en cause de la part du client à chaque nouvelle évaluationOuverture à l ’ensemble des approches et technologies de développement existantes

InconvInconvéénients:nients:Difficultés pour mener à bien les premiers cycles de la spiraleRisque de remise en cause des spécifications des modules/versions déjàréalisés lors de l ’analyse de nouveaux modules/versionsDifficultés de mise en oeuvre au niveau procédural et de contrôle du processusOrganisation opérationnelle du développement souvent modifiée pour le client


Les modèles de cycle de vie non linéaires- Synthèse -

AvantagesAvantagesPermettre de livrer rapidement une version opérationnelle du logicielPermettre de cerner les besoins des utilisateurs et des développeurs avant d ’engager des dépenses plus importantesEliminer la maintenance: le logiciel entre dans un cycle de développement-évolution permanent

InconvInconvéénientsnientsRisque de blocage dans le cas où il y beaucoup d’utilisateurs pour évaluer les versions Risque d’itérations sans fin Conduit à coder avant de finaliserProblèmes relatifs à la gestion de projet: (dérive des coûts et des délais, changement du mode opérationnel du développement fréquent pour les clients, pb de gestion de versions, ... )


Les modèles de cycle de vie- Synthèse -

Dilemme :Dilemme :Quel modèle pour quel projet ?

62

Le génie logicielPartie II

Techniques d’Analyse/Conception


Plan de la partie II

11-- Techniques de SpTechniques de Spéécificationcification

22-- Techniques dTechniques d’’Analyse et de ConceptionAnalyse et de Conception

33-- Techniques de VTechniques de Véérificationrification


Spécification ?

DDééfinition :finition :Méthodes développées pour répondre à l’évolution des matériels, des systèmes, des langages de programmation et essentiellement à la complexité croissante des logiciels.Elles permettent de «normaliser » et «formaliser » les différentes activités afin de limiter les problèmes d’incompréhension entre les différents intervenants

On distingue 3 types de spOn distingue 3 types de spéécifications :cifications :spécifications informelles

en langue naturellesemi formelles

souvent graphiques, dont la sémantique est plus ou moins préciseformelles

quand la syntaxe et la sémantiques sont définies formellement par des outils mathématiques


Différentes techniques de spécification

Techniques informellesTechniques informellesLe dictionnaire des données ou glossaire,La table de décision, …

Techniques semiTechniques semi--formellesformellesLe modèle entité-association (Entity Relationship Model),Les diagrammes de flots de données (Data Flow),Les diagrammes de structure (Structured Charts), …

Techniques FormellesTechniques FormellesLes diagrammes états-transitions,Les réseaux de Pétri, …


Techniques de spécification informelles

DéfinitionElles sont très souples, conviennent pour tous les aspects, sont très facilement communicables à des non spécialistes. Elles manquent de structuration, de précision et sont difficiles àanalyser.Des efforts peuvent être faits pour les structurer (spécifications standardisées) :

chapitres, sections, items, justifications, etc

ExemplesLe dictionnaire des données ou glossaire :

Ensemble des spécifications des données utilisées aux différents niveaux d’analyse et de conception

La table de décisionReprésentation tabulaire de tous les cas des valeurs d’entrée d’un processus et des valeurs de sortie correspondant à chacune de ces combinaisons


Techniques semi-formelles

Souvent graphiques, dont la sémantique est plus ou moins précise

Le modèle entité-association (Entity Relationship Model),Les diagrammes de flots de données (Data Flow Diagram),Les diagrammes de structure (Structured Charts), …


Le modèle entité-association

Utilisé dans de nombreuses méthodes d’analyse sous sa forme initiale ou dans des méthodes à objets sous sa forme étendueparfaitement adapté à la conception de bases de données

Concepts mis en Concepts mis en œœuvreuvre : : classe d’entité : regroupement des propriétés communes à plusieurs entitésoccurrence d’entité : représentation d'un objet matériel ou immatériel du monde réelattribut : propriété (champ)identifiant (clé) : attribut d’une entité dont la valeur permet de la désigner sans ambiguïté. relation ou association : lien entre deux classes d’entitécardinalité de la relation : spécification du nombre d’occurrence d’entités concernées


Le modèle entité-association

concerne

(1,1)

est_concerné

(0,n)

(0,n)envoie

num_propdate_arrivéeétat

code_sociéténom_sociétéadresse_société

code_projetnom_projetnom_responsabledate_limite

est_envoyé(1,1)

Envoyer

PROPOSITION PROJET

SOC-SERVICE

concerner

Cardinalitésà tout X correspond :

ExempleExemple

au plus un Y

un et un seul Y

0 ou plusieurs Y

1 ou plusieurs Y


Les diagrammes de flots de données (Data Flow Diagramm)

CaractCaractééristiquesristiquesModélisation des traitements Permettent de montrer comment chaque processus transforme ses entrées successives (flots de données entrants) en sorties correspondantes (flots de données sortants) 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).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



Un DFD est souvent accompagnUn DFD est souvent accompagnéé d'un d'un diagramme de contextediagramme de contexteReprésentation des échanges de flots de données avec les acteurs extérieurs au système à modéliser

Responsable du

Projet

Société de

servicesSélection

des

propositions

critères de sélection

Proposition

Lettre d'acceptation

Lettre de refus


Saisie

SOC_SERVICES

PROJET

PROPOSITION

Acceptation

Refus

Evaluation

Note

Proposition

Lettre de refus

Lettre d'acceptation

critères de sélection


Exemple de DFDExemple de DFD


Techniques de spécification formelles

La syntaxe et la sémantiques sont définies formellement par des outils mathématiques

ExemplesExemplesLes diagrammes états-transitionsLes réseaux de Pétri


Les diagrammes états-transitions

Matérialisent l’incidence des événements sur les différents états du système en indiquant les actions à effectuer

Sont particulièrement bien adaptés pour modéliser le cycle de vie d’un objet

permettent de préciser les valeurs d'un attribut (ex : état soumis, en examen, accepté ou refusé) défini dans le modèle entité/association

Sont plus adaptés aux systèmes synchrones qu’asynchrones

C’est une technique formelle très largement répandu pour décrire les aspects liés au contrôle


Les diagrammes états-transitions

Exercice :Exercice :Réaliser un diagramme états/transitions sur le déroulement d’un appel téléphonique.

Quelques états : En attente, En Tonalité, En numérotation, En connexion, En sonnerie,…


Les réseaux de Pétri

DDééfinition finition Outil mathématique permettant de modéliser le comportement d'un système dynamique à événements discrets.Technique formelle est particulièrement bien adaptée pour décrire le comportement des systèmes asynchrones avec des évolutions parallèles

Constituants : Constituants : Places ( ) : états du systèmetransitions ( ) : changements d'étatmarquage ( jeton ) : permettent de définir l'état du système à un instant donné



SSéémantiquemantiqueChaque place peut contenir un ou des jetons

L’état du RdP est défini par le marquage de ses places.

Si toutes les places d’entrée contiennent au moins un jeton, la transition est franchissable :

ce qui retire un jeton de chaque place d’entréeajoute un jeton dans chaque place de sortie.

Attention aux Attention aux interblocagesinterblocages !!



P1P2

P3P6

P4P5

T1T4

T3T2

P1 : Appel d'offre en coursP2 : Enregistrement propositionP3 : Examen propositionP4 : Proposition acceptéeP5 : Proposition refuséeP6 : Appel d'offre terminé (annulé)

T1 : Début d'examen(transition simple)

T2 : Critères Satisfaits(condition)

T3 : Critères non satisfaits(condition)

T4 : Arrivée date limite(événement)

ExerciceExercice



22-- Techniques dTechniques d’’analyse et de conceptionanalyse et de conceptionMéthodes fonctionnellesMéthodes orientées objet


Plan


Méthodes d'analyse et de conception

On distingue les approches ascendantes et les approches descendantes.

MMééthode descendante : thode descendante : Démarche par affinages successifs consistant à partir de l’expression la plus générale du problème et à décomposer de façon itérative les tâches à réaliser en sous tâches jusqu’à un niveau d’expression assez élémentaire pour pouvoir être traduit dans un langage de programmation

MMééthode ascendante : thode ascendante : Réutilisation de composants logiciels préexistants et construction de nouveaux systèmes par combinaison d’éléments prédéfinis

Certaines approchent combinent les deux, notamment dans le Certaines approchent combinent les deux, notamment dans le domaine domaine ««objet objet »»


Méthodes fonctionnelles

CaractCaractééristiquesristiquesPlus orientées vers les traitements que vers les données, mettent en évidence les fonctions à assurer et proposent une approche hiérarchique, descendante et modulaire, en précisant les liens entre les différents modulesUtilisent des notations de type DFD

ExemplesExemplesSADT (Structured Analysis and Design Technique)SA (Structured Analysis )SD (Structured Design)


SADT (Structured Analysis and Design Technique)

Couvre essentiellement la première partie du cycle de vie

Suite cohérente et hiérarchisée de diagrammes obtenus par raffinements successifs

Datagramme : Représentation des données (boites) et des activités qui les créent ou les utilisent (flèches)Actigramme : description de l’enchaînement des activités (boites) et des données qu’elles manipulent (flèches).

Activités de Contrôle

Activités Productrices

Activités Consommatrices

Données de Contrôle

Données d'entréeContrôle

Données de sortieContrôle

DONNEES ACTIVITES

Unité de stockage Unité de traitement

Datagramme Actigramme


Chaque boite peut être dChaque boite peut être déécomposcomposéée en un diagramme plus de en un diagramme plus déétailltaillééVérification de chaque étape de décomposition : Respect des

informations liées aux flèches

RemarqueRemarque : Plusieurs mod: Plusieurs modèèles SADT correspondant les SADT correspondant àà diffdifféérents rents points de vue sur le systpoints de vue sur le systèème sont rme sont rééalisaliséés pour une meilleure s pour une meilleure comprcomprééhension hension

Vérification de la cohérence entre les différents modèles : par vérification systématique de la cohérence entre données et traitements au moyen de contrôles croisés d’actigrammes et de datagrammes.

SADT (Structured Analysis and Design Technique)


L'analyse structurée SA (Structured Analysis )

méthode descendante par raffinages successifs des traitements et des processus.

A chaque niveau de décomposition, utilisation de la notation des DFD :

Niveau le plus haut : ensemble du problème : diagramme de contexteNiveaux inférieurs : décomposition en plusieurs processus des processus des niveaux juste supérieurs, en respectant les flots de données entrant et sortant.

Niveau de granularité maximale : processus non décomposés : une mini spécification leur est attachée, sous une forme plus ou moins formelle, afin de préciser comment les sorties sont obtenues à partir des entrées.

Un dictionnaire des données précise également la définition des données, des processus et des fichiers (ou zones de stockage).


1

3 4

2

3.1

3.3 3.4

3.2

1.1

1.3

1.22.1

2.2

4.1 4.2

4.3

L'analyse structurée SA (Structured Analysis )


MMééthodes dthodes d’’analyse conception analyse conception orientorientéées objetes objet


Méthodes d'Analyse et de conception orientées objet

La conception propose une solution au problème spécifié lors de l’analyse :

architecture de l’application (architecture logicielle et architecture physique),description détaillée des modules, des interfaces utilisateurs, des données.

L'objet outil de modélisation : Une méthode d'analyse et de conception par objets apporte en plus une démarche pour faire émerger un modèle de données et une analyse de leur comportement. Idée : objet = unité principale de décomposition de systèmesPoint de départ : Travaux de G. Booch sur la conception de logiciels avec ADA


Classe :Classe :Décrit une collection d'objets ayant même structure et même comportement.

La structure (ensemble des données) est constituée des attributsLe comportement est décrit par des méthodes

Les instances de la classe sont les objetsPossède une interface (publique, protégée, privée)

Objet : Objet : Instance d’une entité particulièreA une identité uniquePossède un état : valeurs particulières de ses attributs Communique avec les autres objets par envoi de messages, activation de méthodes

Seules les méthodes de l'objet sont habilitées à modifier ses valeurs d'attributs La réalisation de l'action associée à un envoi de message dépend de l'objet récepteur qui gère ses propres attributs avec ses propres méthodes

Méthodes d'Analyse et de conception orientées objet - Concepts


HHééritage : ritage : Relation d'inclusion conceptuelle entre classes : les sous-classes héritent de la structure et du comportement de leurs super-classes.Enrichissement, spécialisation, fusion font partie du concept d'héritage.

Associations et liens :Associations et liens :Représentation au niveau des classes des liens qui unissent les objets (association, agrégation, composition)



Trois aspects : Trois aspects :

Dimension Structurelle :propriétés des objets et liens

Dimension TemporelleComportement des objets : description des changements d'états (valeurs, événements)

Dimension Fonctionnelle :fonctions réalisées par les objets par l'intermédiaire des méthodes



Méthodes d'Analyse et de conception orientées objet

Quelques mQuelques mééthodes :thodes :OOA -OOD (Coad et Yourdon)OODa, OOADa (Booch)OOSA (Shlaer et Mellor)OOSE (Jacobson)OOM (Rochfeld)OMT (Rumbaugh)HOOD (ESA)RAD(Rationnal)RUP (Rationnal)


OMT (Object Modeling Technique)

DescriptionDescriptionCouvre les phases d'analyse et de conception en utilisant le même formalismeTrois points de vue analytiques (statique, dynamique, fonctionnel)Trois modèles : objet, dynamique, fonctionnel.

Avantages de OMT: Avantages de OMT: modèle statique très richenombreux domaines d'applications Unifiée avec la méthode OODa UML


OMT - Le modèle objet

Description graphique de la structure : Description graphique de la structure : diagramme des classes

Processus de construction du modProcessus de construction du modèèle objet : le objet : Identifier les classes d'objetsFaire un dictionnaire des donnéesIdentifier et ajouter les associations entre les classesIdentifier et ajouter les attributs aux classes et aux associationsOrganiser et simplifier les classes grâce à l'héritageTester les chemins d'accès en utilisant des scénariiGrouper les classes en modules


OMT - Le modèle objet

PERSONNE nomINSEEadresse déménager

ENTREPRISEnomadresse

travaille-pour

SERVICES………

salairefonction

salariéemployeur


OMT - Le modèle dynamique

DDéécrit les aspects temporels et le crit les aspects temporels et le ssééquencementquencement des opdes opéérations :rations :événements, scénarii, états, organisation des événements et des états

Formalisme graphique de reprFormalisme graphique de repréésentation : sentation : Diagrammes états-transitions

Processus de construction :Processus de construction :Préparer les scénarii de séquences d'événements typiquesIdentifier les événements entre objets et préparer pour chaque scénario une trace des événementsPréparer un diagramme de flots d'événements pour le systèmeDévelopper un diagramme d'états pour chaque classeVérifier la complétude et la cohérence des événements communs àplusieurs diagrammes d'états


OMT - Le modèle fonctionnel

DDéécrit les aspects licrit les aspects liéés s àà la transformation des valeurs des objetsla transformation des valeurs des objetsFonctions, contraintes, dépendances fonctionnelles

Formalisme de reprFormalisme de repréésentation : sentation : Diagrammes de flots de données

Processus de construction :Processus de construction :Identifier les valeurs d'entrée-sortieUtiliser des DFD pour montrer les dépendances fonctionnellesDécrire ce que fait chaque fonctionIdentifier les contraintesSpécifier les critères d'optimisation


La méthode MERISE

Version 1 :Version 1 :Approche systémique (liens système d'information - système opérant, SI - système de pilotage)

Couverture de tout le cycle de vie du logiciel (schéma directeur, études préalable, étude détaillée, étude technique, production de logiciels, mise en œuvre, maintenance)

Cycle d'abstraction sur trois niveaux (conceptuel, organisationnel, physique)

Séparation modèles de données et modèles de traitements


Merise : Les modèles


Merise - Niveau conceptuel

Modèle conceptuel des données (ou MCD), schéma représentant la structure du système d'information, du point de vue des données

les dépendances ou relations entre les différentes données du système d'informationpar exemple : le client, la commande, la ligne de commande, etc.,

Modèle conceptuel des traitements (ou MCT), schéma représentant les traitements, en réponse aux événements àtraiter par exemple : la prise en compte de la commande d'un client


Modèle Logique des Données (MLD), reprend le contenu du MCD précédent, mais précise la volumétrie, la structure et l'organisation des donnéestelles qu'elles pourront être implémentées. Par exemple, à ce stade, il est possible de connaître la liste exhaustive des tables qui seront à créer dans une base de données relationnelle

Modèle Logique des Traitements (MLT ou MOT), précise les acteurs et les moyens qui seront mis en œuvre. C'est ici que les traitements sont découpés en procédures fonctionnelles. décrit avec précision l’organisation à mettre en place pour réaliser une ou, le cas échéant, plusieurs opérations figurant dans le MCT. Il répond aux questions suivantes : qui ? quoi ? où ? quand ? À un MCT correspondent donc généralement plusieurs MOT.

Merise - Niveau logique ou organisationnel


Merise - Niveau physique

Modèle Physique des Données (MPD) permet de préciser les systèmes de stockage employés (implémentation du MLD dans le SGBD retenu)

le Modèle Physique des Traitements (MPT)permet de spécifier les fonctions telles qu'elles seront ensuite réalisées par le programmeur.


Merise

Version 2 :Version 2 :Enrichissement des traitements au niveau conceptuel par l'introduction :

de diagrammes de flots de données

d'un Modèle Conceptuel des Traitements Analytiques (considération des données qui s'y rattachent dés la conception préparation de la validation)

de la notion de Cycle de Vie d'un Objet

Enrichissement au niveau logique par la prise en compte des structures , des moyens matériels et humains àmettre en place

la définition des interfaces avec les utilisateurs

les ressources logiques de traitements et de stockage, la répartition des données


Orientation Objet dans Merise

Version 3 : Version 3 : Trois dimensions : statique, dynamique, fonctionnelleProcessus :

Développement de la dimension fonctionnelle : permet de représenter les frontières du système à modéliser par rapport à son environnement.

Utilisation d'un diagramme de contexte.Définition des besoins par des DFD

Importance de la dimension statique, la plus stable dans le tempsRepose sur un modèle E/A étenduAssociation à chaque objet de son comportement, par l'intermédiaire des méthodes apparues dans le DFD

Représentation de l'enchaînement des opérations dans différents scénarii, les opérations pouvant rassembler les services de plusieurs objets : modèles de traitements classiques de MERISE + objets sur lesquels portent les traitements


Méthode Macao (IUT Blagnac)

Démarche participative par prototypage incrémental (spirale)MACAO utilise la notation UML

structure du logiciel en termes de classes et de composants, dynamique à l'aide de diagrammes d'interactions ou d'états/transitions

A partir des Cas d'Utilisation obtenus par interviews des utilisateurs, deux types de modèles originaux sont utilisés pour représenter l'IHM du logiciel :

un modèle conceptuel construit à partir du diagramme des classes et de patrons de conception un modèle de réalisation permettant une mise en œuvre optimum en langage JAVA sous Windows ou LINUX, ou en HTML pour les applications Intranet.

Afin de limiter les tests de non régression toujours très lourds et coûteux, MACAO applique à chaque prototype réalisé le principe de non régression basé sur l'encapsulation et l'héritage


Méthodes d'analyse/conception- Synthèse -

Tentative de standardisation des mTentative de standardisation des mééthodesthodes : : Applicables quel que soit le secteur d’activitéHarmonisation des méthodes existantesTerminologie uniqueNormalisationDéfinition d’un métamodèle : le modèle structurel

NNéécessitcessitéé dd’’introduire des techniques formelles et des outils pour introduire des techniques formelles et des outils pour spspéécifier et prouver les rcifier et prouver les réésultats de lsultats de l’’analyse et couvrir tout le analyse et couvrir tout le cycle de vie.cycle de vie.


UMLUnified Modelling Language

DescriptionDescription

Il est né en début de 1997 dans l'optique d'unifier les méthodes d'analyse et de conception des systèmes.

Consensus autour des méthodes existantes (OMT, OOSE, OOA/OOD)

se définit comme le langage, standard, universel de modélisation graphique et textuelle.

Notation couvrant toutes les phases du cycle de vie logiciel

Issu de la recherche de l’OMG

L'OMG adopte en novembre 1997 UML 1.1 comme langage de modélisation des systèmes d'information à objets.

La version d'UML actuelle est UML 2.3 (mai 2010)


UML

Diagrammes UML utilisables tout au long du projetanalyse → conception → implantation

les les composants composants

logicielslogiciels

la structuration la structuration des objetsdes objets

la dynamique la dynamique des objetsdes objets

les fonctions les fonctions du systdu systèèmeme

ll’’architecture architecture physiquephysique

Vue implantation

Diagrammescomposants

Vue externecas

d’utilisation

Vue logique statique

Diagrammes classes, objets, collaborations, séquences

Vue logique dynamique

Diagrammesétats, activités

Vue déploiement

Diagrammes déploiement


Diagramme de classes

Diagramme de composants

Diagramme d'objets

Diagramme de structure composite

Diagramme de packages

Diagramme de déploiement

Diagramme de séquence

Diagramme de communication

Diagramme de temps

Diagramme de vue d'ensemble des interactions

Diagramme d'états

Diagramme d'activités

Diagramme de cas d'utilisation

Diagramme comportementalDiagramme structurel

Diagramme UML2

Diagramme d'interaction

UML 2.3 (Mai 2010)


UML – Cas d’Utilisation

Permet d'identifier les fonctionnalités que doit fournir le système Identifier les acteurs interagissant avec le système

Exemple :Exemple :Gérer les voitures

réparer

proceder à l'expertise

enregistrer

MecanicienElectricien

Maintenicien

effectuer le test

Client

ResponsableAtelier

ChefAgence

effectuer maintenance

<<extend>>

<<include>>

<<extend>>


UML – Diagramme de classes

représentant la Structure statique d'un modèle, à savoir les éléments classes et types, et leurs relations les uns par rapport aux autres.


UML- Diagramme de Séquences

Exemple qui modélise l'envoi, par un enseignant, des notes d'une classe d'étudiants à l'administration et le traitement effectué sur ces notes.


UML – Diagramme états/transitions

montre les différents états d’un objet ainsi que les transitions entre ces états


UML - diagramme de composants

Exemple :Exemple :


UML

SynthSynthèèsese

La version d'UML actuelle est UML 2.3 (mai 2010)

Les travaux d'amélioration d’UML se poursuivent !



22-- Techniques dTechniques d’’analyse et de conceptionanalyse et de conception


Plan


Test de Logiciel

DDééfinitionfinitionRecherche d'inadéquation d'un logiciel par rapport à des références établies : spécifications du logiciel, normes ou règles portant sur son code ou les documents le concernant

Classification des mClassification des mééthodes thodes Tests statiques ( traitent le texte du logiciel : spécifications ou programmes)Tests dynamiques (exécution effective du logiciel sur un sous-ensemble du domaine de ses entrées possibles)


Approches de Vérification

Vérification dynamique : expérimenter le comportement de l’application (la tester) avec un ensemble bien choisi de données;

Les tests ont pour but de mettre en évidence les erreurs. Les tests peuvent prouver la présence d’erreurs mais ne peuvent pas prouver leur absence

Vérification statique : analyser les propriétés du système, sans exécution ;

Les techniques informellesLes techniques formelles


Test ou vérification dynamique

Les test unitaires de programmes ou de modulestest d’un programme isoléeffectué par simulation des comportement des modules appeléset par simulation les appels du module

Les tests d’intégrationAprès avoir testé unitairement les modules il faut tester leur intégration progressive jusqu’à obtenir le système complet

Les test de réceptioneffectué par le client, avec la participation du fournisseur, pour vérifier que les dispositions contractuelles sont bien respectées

Les tests de non régressioneffectué à la suite de la modification d'un logicielIl a pour but de montrer que les autres parties du logiciel n'ont pas étéaffectées par cette modification


Vérifications statiques

Lectures croisées et inspection :vérification d'un document par des relecteurs différents des auteurs, puis vérification par des groupes de relecteurs ayant des rôles différents sur le projet (chef de projet, auteur du document, responsables de tests,…)

Analyse d'anomalies : Établissement d'un critère d'acceptabilité des programmes testésConstruction d'un graphe (graphe de contrôle, flot de données, graphe de dépendances, réseau de Pétri, graphe de transitions,…) représentant un sous-ensemble des informations pour vérifier les critères choisisÉtude des chemins du graphe avec un prédicat portant sur la satisfaction des critères établis



Les techniques informelles

Il s’agit d’activités réalisées par un groupe d’inspecteurs qui examinent un document à la recherche d’erreurs

parmi les erreurs classiques en programmation on peut citer :l’utilisation de variables non initialisées,les affectations incompatibles,les boucles infinies,les débordements de tableaux,les allocations et libérations impropres de zones mémoire,etc.



Les techniques formellesprouver formellement la correction d’un programme

Le programme est caractérisé par sa précondition (condition éventuelle àrespecter par les données du programme) et sa postcondition (condition vraie à la fin du programme qui définit donc son objectif)Technique basée sur les assertions logiques

Évaluation symboliqueSimulation de l'exécution du programme sur des données symboliques

expressions symboliques correspondant au texte des programmesUtilisation de graphe de contrôle Parcours du graphe à partir de données en entrée, jusqu'aux données de sortie : production d'une expression symbolique retraçant les calculs effectués et les conditions associées

122

Le génie logicielPartie III

Génie Logiciel Avancé


Plan

11-- ÉÉvolution des technologies dvolution des technologies d’’analyse conceptionanalyse conceptionOCL Object Constraint LanguagePatrons (patterns) Technologie des composantsL’architecture MVCProgrammation par Aspect (Aspect Oriented Programming)OMG-MDA Model Driven Architecture

22-- ÉÉvolution des processus de dvolution des processus de dééveloppementveloppementProcessus UnifiéMéthodes agiles


Les limites de la programmation par objets

Absence de vision globale de l'application Absence de vision globale de l'application les principaux concepts sont définis au niveau d'un objet individuel pas de notion de description globale de l'architecture

DifficultDifficultéé d'd'éévolution volution conséquence de l'absence de vision globale

Absence de services Absence de services les services nécessaires doivent être réalisés ''à la main'' (persistance, sécurité, etc.)

Conclusion Conclusion charge importante pour le programmeur incidence sur la qualité de l'application une partie du cycle de vie n'est pas couverte


Construction des systèmes complexes

Les nouvelles Exigences :Besoins fonctionnels en constante augmentationBesoins techniques complexes et évolutifsMultiples acteurs, …

Conséquence :des composants complexes et hétérogènes …

Symptômes :Dispersion : une fonctionnalité est distribuée dans tout le système, et non pas placée dans une unité bien identifiéeCouplage des fonctionnalités : le cas où une unité contient des éléments provenant de différentes préoccupations

!Réutilisation

Évolution

Traçabilité


Évolution des technologies en Génie Logiciel

Abandon de la Technologie Objets pour la Technologie Modèles (J. Bézivin)

Technologie des Procédures

Technologie des Composants

Technologieà Objets

Objets,Classes,

Smalltalk, C++,...

Procédures,Pascal,

C,...

Packages,Frameworks,

Patterns,…

1980 1995 2000

Raffinement Procédural

CompositionDes Objets

Technologie des Modèles

TransformationDe Modèles

Modèles, Méta-modèles,

UML, MOF,XML, XMI,,…


Qualité du logiciel : Evolution des technologies

Parlons les mêmes langages et partageons les mêmes technologies Parlons les mêmes langages et partageons les mêmes technologies !!Les standard de l’OMG : UML, XMI, CWM, CORBA, IDL, …

Expression de contraintes sur les modExpression de contraintes sur les modèèles UML les UML OMG-OCL

AdaptabilitAdaptabilitéé, extension d, extension d’’UMLUMLProfils UML

InteropInteropéérabilitrabilitééMéta-modélisationOMG-MDA

RRééutilisation des solutions utilisation des solutions Composants, Patrons de conception

SSééparation des prparation des prééoccupations occupations Aspect, pt vue


Object Constraint LanguageOCL


OMG - OCL (Object Constraint Language)

Pour spécifier complètement une application :Diagrammes UML seuls sont généralement insuffisantsNécessité de rajouter des contraintes

Comment exprimer ces contraintes ?Langue naturelle mais manque de précision compréhension pouvant être ambigüeLangage formel avec sémantique précise : par exemple OCL

OCL : Object Constraint LanguageOCL est un langage formel pour l’expression de contraintes, standardisé par l’OMG.


OCL (Object Constraint Language)

Description

Langage de contraintes orienté-objet

S'applique sur les diagrammes UML

OCL se veut un langage formel permettant de décrire ces contraintes de façon déterministe.

Il se veut simple à écrire ainsi qu’à comprendre.

Langage formel (mais simple à utiliser) avec une syntaxe,

une grammaire, une sémantique (manipulable par un outil)

OCL est purement un langage interrogatif : en aucun cas il ne peut modifier le modèle auquel il se rapporte. On parle de langage sans effet de bord, ou side-effect free.


Utilisation d’OCL

OCL permet principalement d'exprimer des contraintes sur l'état d'un objet ou d'un ensemble d'objets :

Des invariants qui doivent être respectés en permanence

Des pré et post-conditions pour une opération :Précondition : doit être vérifiée avant l'exécution

Postcondition : doit être vérifiée après l'exécution

Gardes sur transitions de diagrammes d'états ou de messages de diagrammes de séquence/collaboration

Des ensembles d'objets destinataires pour un envoi de message

Des attributs dérivés

Des stéréotypes

...


OCL par des exemples (1/3)



ContexteUne expression OCL est toujours définie dans un contexteCe contexte est une instance d'une classeMot-clé : context

Un invariant exprime une contrainte sur un objet ou un groupe d'objets qui doit être respectée en permanenceMot-clé : inv:

Exemple : Pour toutes les instances de la classe Company, le nombre des employés doit toujours être supérieur à 50

context Company inv: self.numberOfEmployees > 50



Pour spécifier une opération :Précondition : état qui doit être respecté avant l'appel de l'opérationPostcondition : état qui doit être respecté après l'appelMots-clés : pre: et post:Exemple : La somme à débiter doit être positive pour que l'appel de l'opération soit valide :

context Compte::débiter(somme : int)pre: somme > 0post: solde = solde@pre – somme

Dans une contrainte OCL associée à un objet, on peut :Accéder à l'état interne de cet objet (ses attributs)Naviguer dans le diagramme : accéder de manière transitive à tous les objets (et leur état) avec qui il est en relation

context Companyinv: self.manager.isUnemployed = false inv: self.employee->notEmpty()


La rLa rééutilisation dans lutilisation dans l’’ingingéénierie logiciellenierie logiciellePatrons (patterns) Technologie des composants


Réutilisation dans l’ingénierie logicielle

DDééfinitionfinition ::Un composant réutilisable :

traite un problème récurrent de l’ingénierie des SI, capitalise un fragment de produit ou de processus, offre une solution conceptuelle et/ou logicielle testée, acceptée et adaptable.

La réutilisation ne doit plus être limitée aux produits logicielsUne très grande variété de composants réutilisables.Conséquences :

Nécessité de classifier, documenter, organiser, composer les composants…Nécessité de démarches centrées réutilisation.

ConsConsééquences sur les produitsquences sur les produits : : Plus rapides à développer, Plus faciles à maintenir, Certainement meilleurs, Moins originaux.

Technologie des composantsPatrons (Design patterns)



Expression des besoins

Analyse (abstraction du monde réel)

Conception (solution technique)

Implantation (solution opérationnelle)

Patrons d’analyse Modèles de domaine Composants métiers conceptuels

Patrons d’architecture Patrons de conception ERP, Frameworks

Patrons d’implantationComposants métiers logicielsBibliothèques de classes

SpécificationsInformelles

ModèleDescriptif & Normatif

Informatisable

ModèleEffectif Informatisé

Logiciel


Technologie des patrons


Patron

IntroductionIntroduction

La beauté est-elle subjective ou existe-t-il des critères permettant de distinguer ce qui est beau de ce que ne l’ai pas ?

Par exemple, si une personne doit concevoir l’entrée d’une maison, peut-elle savoir objectivement si son projet est bon ?

les individus d’une même culture sont généralement d’accord sur ce qui peut être considéré comme une bonne conception.

Ces raisonnements peuvent être appliqués à la qualité d’un logiciel ?

en quoi une conception est-elle bonne au mauvaise? Quels aspects les différentient ?

les bonnes constructions qui rles bonnes constructions qui réésolvent le même problsolvent le même problèème ont des me ont des points communs (qualifipoints communs (qualifiéés de patrons).s de patrons).


Patron

DDééfinition: finition: « une solution apportée à un problème dans un contexte donné »« chaque patron décrit un problème récurrent dans notre environnement, puis le cœur de la solution qui sera réutilisable indéfiniment, quelle que soit la mise en pratique choisie »

Exemple: CrExemple: Crééation textile ation textile

Difficile !!!! Solutions prédéfinies Projet réussi


Intérêt des patrons

RRééutiliser les solutionsutiliser les solutions : : En utilisant des solutions prédéfinies, on évite les pièges de début de projet et on bénéficie de l’expérience d’autre concepteurs. On n’a pas àréinventer des solutions à des problèmes récurrents.

AmAmééliorer la communication et lliorer la communication et l’’apprentissageapprentissage : : Les patrons impliquent l’adoption d’une approche commune au sein d’une équipe de développeurs. Ils constituent une même référence pour tous lors des phases d’analyse et de conception d’un projet, ce qui simplifie bien évidement la communication.

Souplesse du logicielSouplesse du logiciel : : La plupart des design patterns facilitent la modification ultérieur du logiciel.

Ils apportent donc des solutions plus facilement modifiables queIls apportent donc des solutions plus facilement modifiables quecelles auxquelles vous pouvez penser en dcelles auxquelles vous pouvez penser en déébut de projet.but de projet.


processus

entreprise

domaine

générique

analyse

concepti

on

implanta

tion

Coad GoF

SIP

Coad GoF

Ambler

Systèmes de patrons

[ LSR-IMAG ]


Systèmes de patrons

“Un patron processus fournit une collection de techniques, d’actions et/ou de tâches à suivre pour le développement des logiciels”. Ambler 98

« Un langage de patrons est une collection structurée de patrons construits l’un sur l’autre pour transformer les besoins et les contraintes dans une architecture ». C. Alexander / J. Coplien

Un patron constitue une base de savoir et de savoir-faire pour résoudre un problème récurrent dans un domaine

Un système de patrons est une collection de patrons coordonnés intégrant une démarche de conception pour résoudre un problème complexe


Patrons de Conception de GOF :

GOF: Gang of Four = la bande des quatreErich Gamma, Richard Helm, Ralph Johnson and John Vlissides.

Creational Structural Behavioral

Class • Factory Method • Adapter • Interperter

ScopeObject

• AbstractFactory

• Builder• Prototype• Singleton

• Adapter• Bridge• Composite• Decorator• Facade• Flyweight• Proxy

• Chain of Responsibility• Command• Iterator• Mediator• Momento• Observer• State• Strategy• Vistor


Exemple 1 : Patron Composite

ExerciceExercice


Exemple 1 : Patron Composite

Structure du patron CompositeStructure du patron Composite


Exemple 2 : Patron Observateur (E. Gamma)

ObjectifPermettre à un objet de prévenir un ensemble d'autres objets inconnus au moment de sa conception de certains changements de son état

ProblèmeCertains changements d'état d'un objet O sont susceptibles d'en intéresser d'autresCes autres objets sont inconnus lors de la conception de O

SolutionFaire gérer à O une liste d'observateurs (ou écouteurs) et les prévenir lors des changements d'états intéressants


Exemple 2 : Patron Observateur

1 sujet

Ouest = 33,5Nord = 12,4Est = 44,0Sud=10,1

2003

Ouest

Nord

Est

Sud

0

5

10

15

20

25

30

35

40

45

50

OuestNordEstSud

3 observateurs

Patron de conception Observateur (E. Gamma)Patron de conception Observateur (E. Gamma)


Exemple 2 : Patron Observateur

Structure du patron ObservateurStructure du patron Observateur


Structure d’un patron

Description dDescription d’’un patronun patronNomIntentionMotivationIndication d’utilisationStructureConstituantsConséquencesImplémentationExemples de codeModèles apparentés

ProblemProblem

Context

SolutionSolution

Benefits

Related Patterns

Consequences


Ingénierie des patrons

Identifier les problèmes

Construire un

référentiel

Analyser lesmodèles existants

Identifier lesproblèmes

Intégrer le patron associé

dans le catalogue

Définir de nouveaux patrons dérivant des

patrons existants

Décomposer le problèmeen sous-problèmes

Définir nouvelle

solution

Problème déjà traité

raffinement d'unproblème

Nouveau problème

Problème décomposable

Spécifier les solutions


Technologie des composants


Composants : description

classe avec ses connexions figées (les associations avec les autres classes matérialisent des liens structurels), ne constitue pas une réponse adaptée à la problématique de la réutilisation

Description Description La réutilisation est l’aptitude d’un logiciel à être réutilisé, en tout ou en partie, dans de nouvelles applicationsLes composants permettent la construction d'applications par composition de briques de base configurables Un composant est un module logiciel autonome

unité de déploiement (installation sur différentes plates-formes) unité de composition (combinaison avec d'autres composants)

Facilite la compréhension globale du système outil de documentation

Facilite le processus d'évolution modification des composants (interface, réalisation) modification des relations entre composants modification du déploiement


PropriPropriééttéés s spécifie explicitement la ou les interface(s) fournie(s) spécifie explicitement la ou les interface(s) requise(s) peut être configuré

La programmation par composants constitue une évolution technologique soutenue par de nombreuses plateformes :

EJB (Enterprise JavaBeans) CORBA (Common Object Request Broker Architecture) WSDL (Web Services Description Language).Net, , …

Ce type de programmation met lCe type de programmation met l’’accent sur la raccent sur la rééutilisation du composant et utilisation du composant et ll’’indindéépendance de son pendance de son éévolution visvolution vis--àà--vis des applications qui lvis des applications qui l’’utilisent.utilisent.

Composants : description


Composants : modèle générique

Composant

Propriété configurables(interfaces spéciales avec accès restreint)

Contraintes techniques• placement, sécurité• transactionnel, persistance• interfaces fournies par le système (bibliothèques, etc.)

Interfaces requises(fournies par d’autres

composants)Interfaces fournies


Support logiciel pour composants

Pour assurer leurs fonctions, les composants ont besoin d'un supPour assurer leurs fonctions, les composants ont besoin d'un support port logiciel logiciel

Conteneur Conteneur encapsulation d'un composant prise en charge des services du système

nommage, sécurité, transactions, persistance, etc. prise en charge partielle des relations entre composants (connecteurs)

invocations, événements techniques utilisées : interposition, délégation

Structure d'accueil Structure d'accueil espace d'exécution des conteneurs et composants médiateur entre conteneurs et services du système


Mise en œuvre des composants

Structure d’accueil

Conteneur

Structure d’accueil

Conteneur

Conteneur

Composant

Composant

Composant

Client

Bus logiciel + services (désignation, persistance, transaction, sécurité,etc.)


Composants : situation

Premiers produits, ne rPremiers produits, ne réépondent pas encore pondent pas encore àà tous les besoins tous les besoins Java Beans, (Enterprise Java Beans)COM (Component Object Model ) DCOM (Distributed COM ) .NET

DDéébut de normalisation but de normalisation Composants CORBA (OMG), normalisation en cours (CORBA 3)

Ce qui manque encore Ce qui manque encore Descriptions d'architectures

prototypes de recherche, produits encore attendus Support pour déploiement, évolution, configuration

travaux en cours à l'OMG (OSD : Open Software Description) Aide à la conception

travaux sur l'extension de l'UML


Exemple : CORBA (Common Object Request Broker Architecture)

Standard de lStandard de l’’OMGOMG



Expression des besoins

SpécificationsInformelles

Modèle Descriptif & Normatif

Informatisable

ModèleEffectif Informatisé

Logiciel

Analyse (abstraction du monde réel)

Conception (solution technique)

Implantation (solution opérationnelle)

CCOOMMPPOOSSAANNTTSS


Technologie des composants - Synthèse -

DDééveloppement pour et par la rveloppement pour et par la rééutilisationutilisation

Par réutilisationPour la Réutilisation

Concepteur de composants Ingénieur d’applications

Ingé

nier

ie

d’ap

plic

atio

ns

Application

Ingé

nier

ie d

e co

mpo

sant

s


L’architecture MVC



ButIsoler la donnée elle-même de sa présentationDistinguer la consultation de la modification

PrincipePour une donnée, trois composantes distinguées et séparées

Le modèle (sa structure)La vue (sa représentation pour affichage)Le contrôleur (les moyens de modifier la valeur)



Utilisateur

VueContrôleur

Modèle Métier

utilise

Choisi la vue appropriée

manipule,

envoi de requête met à jour,

réponse

présente le résultat

StructureStructure


MVC - Le modèle

RôleEncapsuler les propriétés d'une donnéeÊtre indépendant des vues et contrôleurs

ConséquencesDéfinir les accesseurs aux propriétés de cette donnéeMaintenir une liste d'écouteurs (vues et contrôleurs se déclarent comme écouteurs)Prévenir les écouteurs lorsque la donnée est modifiée

Implantation du design pattern Observer


MVC - Le contrôleur

RôlePermettre à l'utilisateur de modifier la donnée encapsulée dans le modèle

ConséquencesDoit éventuellement s'enregistrer comme écouteur du modèle pour être mis à jour si le modèle est modifiéDoit appeler les accesseurs du modèle en fonction des actions de l'utilisateur


MVC – la vue

RôleReprésenter la donnée encapsulée via un modèleSe maintenir à jour lorsque le modèle est modifié

ConséquencesDoit s'enregistrer comme écouteur au niveau du modèle


Exemple : Application du MVC au web


La multiLa multi--modmodéélisationlisation

Programmation par Aspect(Aspect Oriented Programming)


La multi-modélisation

Séparation des préoccupations pour simplifier la modélisationDécomposition des exigences

Assemblage du système globalComposition de modèles partiels

Approches basées sur la séparation des préoccupations :Modélisation par aspect Modélisation par points de vueModélisation par sujet Etc.


Programmation par aspects

Motivationsle principal problème dans l’évolution et la réutilisation des logiciels est un problème d’organisation des programmesDans toutes les approches de développement traditionnelles (fonctionnelle ou objet) la structuration d’une application repose sur sa décomposition en unités fonctionnelles.

Application basée sur l’orientée objet :

• Divers classes

• Chacune des classes possède son propre code

•Du code non fonctionnel peut venir ‘‘polluerpolluer’’ le code métier

Logger.log(‘SEVERE’, ‘appel 1’);

Ce n’est pas du code métier!


Programmation par aspects

Principe de découpageles services de base d’une application et ses propriétés (fonctionnalités transversales), correspondent à des fonctions indépendantes qui doivent être découplées

Un logiciel contient :Des préoccupations métierDes préoccupations de niveau système


Exemple : paiement par carte de crédit

Préoccupations métier :Effectuer des paiements : débiter un montant d'un compte défini

Préoccupations techniques :Intégrité de la transactionIdentification / authentificationSécurité (confidentialité)Performancesetc

AOP - Exemple


Le rouge montre les lignes de code qui traitent du logging Très mal modularisé

Copyright © aspectj.org

AOPDispersion du code


Point de jonction (join point) : désigne un endroit du programme où l’on souhaite ajouter un aspect.

Coupe (pointcut) : désigne un ensemble de point de jonction.

Code advice : bloc de code définissant le comportement d’un aspect (i.e ce que l’aspect greffe dans l’application).

AOPDefinition d’un aspect


Composants

C1 C2 C3 … Cn

Aspects

A1

A2

A3

….

An

Point de jonction

AOPDefinition d’un aspect


AspectJ

Extension Java permettant la programmation par AspectsExtension Java permettant la programmation par Aspectshttp://aspectJ.org

Principe de Principe de ddééveloppmentveloppmentIdentifier le préoccupations métier (classes) et techniques (aspects) Implémenter chaque préoccupation séparémentTisser les différentes préoccupations

Code Métier

Définition des aspects

CompilateurAspectJ

Code final


Un aspect en Concret

packagepackage aop.aspectjaop.aspectj;;

publicpublic aspectaspect tracertracer{{

pointcutpointcut tobetracedtobetraced(): (): call(public call(public voidvoid Client.newClientClient.newClient(..))|| call (public (..))|| call (public voidvoid Commande.newCdeCommande.newCde(..));(..));;;

before() before() : : tobetracedtobetraced()(){{System.out.println("PremierSystem.out.println("Premier Aspect executer le 01/10/2010Aspect executer le 01/10/2010””););}}

}}

Advicede

type before

coupecoupe


OMGOMG--MDAMDA

Model Driven Architecture


OMG - MDA

l’OMG, consortium de plus 1000 entreprises, initie la démarche MDA.


L’approche MDA

DescriptionDescriptionLe MDA est l'outil qui permet à une industrie de décrire ses fonctions indépendamment des implémentations

Penser l'application au niveau du modèle et laisser le soin de l'implémentation aux outils

Interopérabilité au niveau des modèles : Il s'agit d'avoir la possibilitéd'écrire et de faire évoluer le modèle en fonction de l'organisation métier de l’application et non plus par les plate-formes.

Au niveau de l'organisation : PIM (Plateform Independant Model) Au niveau des plate-formes : PSM (Plateform Specific Model).

Une application complUne application complèète de MDA : un PIM et un ou plusieurs PSMte de MDA : un PIM et un ou plusieurs PSMLangage de description du MDA : UML. L'application sera ensuite implémentée sur un large éventail de systèmes.


L’approche MDA

Les PSM peuvent communiquer entre eux en faisant intervenir plusieurs plate-formes qui ont à échanger des données ( CORBA par exemple) MDA est implémenté dans un outil qui intègre la modélisation et le développement. Il gère des classes servant les objets métiers, leur présentation et leur persistance.

avantages du MDA : une architecture basée sur MDA est prête pour les évolutions technologiques. plus grande facilité d'intégration des applications et des systèmes autour d'une architecture partagée. une interopérabilité plus large permettant de ne pas être lié à une plate-forme.


Les standards de l’OMG

Architecture à quatre niveaux.


Evolution des processus de développement

Les processus unifiLes processus unifiééssUPRUP2TUP

LL’’agilitagilitééXPRAD


UP - le Processus Unifié

DescriptionDescriptionUP (Unified Process) est une méthode générique de développement de logiciel.

Générique signifie qu'il est nécessaire d'adapter UP au contexte du projet, de l'équipe, du domaine et/ou de l'organisation (exemple:

R.UP : Rational Unified ProcessX.UP : Extreme Unified Process


UP - le Processus Unifié

Cadre gCadre géénnééralralLe processus unifié est un processus de développement logiciel : il regroupe les activités à mener pour transformer les besoins d’un utilisateur en système logiciel

CaractCaractééristiques essentielles du processus unifiristiques essentielles du processus unifiéé ::A base de composantsUtilise le langage UML Piloté par les cas d’utilisationCentré sur l’architectureItératif et incrémental.


Le processus unifié : RUP

Rational Unified Rational Unified ProcessProcess, , Instanciation par Rational Software (IBM) des préceptes UP


Le 2 TUP

Cadre gCadre géénnééralralTwo Track Unified Process

CaractCaractééristiques essentielles du processus unifiristiques essentielles du processus unifiéé ::ItératifS’articule autour de l’architecturePropose un cycle de développement en Y « Détaillé dans UML en action »Pour des projets de toutes tailles


Le 2 TUP


Méthodes agiles

DDééfinitionfinitionméthodes de développement informatique permettant de concevoir des logiciels en impliquant au maximum le demandeur (client)se veulent plus pragmatiques que les méthodes traditionnelles. Le développement agile tire son nom du Manifeste Agile, document rédigé en février 2001 et signé par 17 personnalités du domaine. Douze principes ont été définis, dont :

Parvenir à la satisfaction du client par le biais d'un cycle de développement rapide, récurrent et incrémental de versions fonctionnelles;Se montrer apte à prendre en compte les changements de dernière minute à tout moment du projet;Mettre en place une coopération quotidienne entre développeurs et décideurs/commerciauxFaire simple, mais pas simpliste;Laisser l'équipe s'organiser au mieux de ses possibilités.


Méthodes agiles

ExemplesExemplesMéthodes adaptées aux petites équipes

Crystal, XP, Scrum, …

Méthodes prévues pour des groupes conséquentsRAD ASD…


XP (eXtreme Programming)

cadre gcadre géénnééralralMéthode agileEnsemble de « best practices » de développement (travail en équipes, transfert de compétences, …)

CaractCaractééristiques essentielles du processus unifiristiques essentielles du processus unifiéé ::ItératifPas de phase d’analysePlutôt pour des projets à effectif restreint (10 personnes max)Valeurs :

CommunicationSimplicitéFeedback


XP (eXtreme Programming)

Cycle de dCycle de dééveloppementveloppement


RAD (Rapid Application Development)

1 - Initialisation

2 - Cadrage3 - Conception

4 - Construction 5 - Finalisation

Intégration, déploiement et maintenance

Cerner et stabiliser les objectifs Conception globale

et modélisation

Modélisation détaillée, prototypage et test

Préparer l’organisation du projet



InitialisationCette phase permet de définir le périmètre général du projet :

structurer le travail par thèmessélectionner les acteurs pertinentsamorcer une dynamique de projet

CadragePhase d’analyse et expression des exigences Exprime les besoins des utilisateurs lors d’entretiens de groupe

Conception Les utilisateurs sont également impliqués dans cette étape. Ils participent à l’affinage et à la validation des modèles organisationnels :

fluxtraitementsdonnées

Ils valident également le premier niveau de prototype présentant l’ergonomie et la cinématique générale de l’application



Construction Phase de prototypage et réalisation, Durant cette phase, l’équipe RAD doit construire l’application module par module. L’utilisateur participe toujours activement aux spécifications détaillées et à la validation des prototypes.Plusieurs sessions itératives sont nécessaires.

Finalisation Phase de recette et déploiementDes recettes partielles ayant été obtenues à l’étape précédente, il s’agit dans cette phase d’officialiser une livraison globale et de transférer le système en exploitation et maintenance


RAD – Répartition des charges

6 %9 %

23%

50 %

12 %

Initialis

ation

Cadrag

e

conce

ption

Constructi

on

Finalisa

tion


Conclusion Générale

Le génie logiciel a apporté un cadre formel au développement logiciel

Toutes les activités identifiées sont supportés par des techniques, des méthodes, des outils.

Encore des efforts à faire au niveau :

Réutilisation

Traçabilité (remonter jusqu’à l’origine d’un problème)

Interopérabilité

Evolution

La phase de capture des exigences (analyse des besoins) n’est pas assez valorisée dans les processus : elle devient une discipline à part entière.


Conclusion Générale

Dernier conseil : s’ouvrir !

Parce que les technologies et les méthodes avancent en vitesse, il faut :

Se tenir au courant,Être curieux

Lire …

Cours GL-L3NTIE Lakhrissi

Documents

Transcript of Cours GL-L3NTIE Lakhrissi