La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Direction Technique Cycle de vie du projet et Cas dutilisation.

Présentations similaires


Présentation au sujet: "Direction Technique Cycle de vie du projet et Cas dutilisation."— Transcription de la présentation:

1 Direction Technique Cycle de vie du projet et Cas dutilisation

2 Objectifs Détailler le cycle de vie dun projet itératif. Connaître les bonnes pratiques de développement logiciel. Appréhender le processus de développement logiciel. Comprendre les cas dutilisations.

3 Quest ce quun cycle de vie Ensemble généralement séquentiel de phases de projet, dont le nom et le nombre sont déterminés en fonction des besoins de suivi par l(es) organisation(s) impliquée(s) dans le projet. –Exemples Cycle en Cascade Cycle en V Cycle en Spirale Principes de base

4 Cycle de vie linéaire, séquentiel, dit «en cascade». Celui-ci a été défini dans les années 70. Ce cycle de vie est basé sur la production déléments livrables. Le cycle de vie «en V» est une alternative au cycle en cascade. Cycle de vie en cascade Principes de base

5 1.Now is the time for men in the ranks to stay in the ranks. 2.Now is the time for men in the ranks to stay in the ranks. 3.Now is the time for men in the ranks to stay in the ranks. 4.Now is the time for men in the ranks to stay in the ranks. 5.Now is the time for men in the ranks to stay in the ranks. 6.Now is the time for men in the ranks to stay in the ranks. 7.Now is the time for men in the ranks to stay in the ranks. 8.Now is the time for men in the ranks to stay in the ranks. 9.Now is the time for men in the ranks to stay in the ranks. 10.Now is the time for men in the ranks to stay in the ranks. 11.Now is the time for men in the ranks to stay in the ranks. Recueillir les exigences Analyser Concevoir Coder Intégrer, tester & effectuer le contrôle qualité 2 mois 1 mois 4 mois 12 mois 2 mois Que se passe-t-il lorsquon découvre à ce stade des changements par rapport aux exigences ? Et à ce stade ? Et à celui-ci ? Principes de base Le cycle de vie en cascade

6 Les fonctionnalités (exigences) doivent être clarifiées avant de débuter la conception ou limplémentation. Les objets du domaine (Métier) sont précisément modélisés avant la conception ou limplémentation. Un projet bien mené suit du début à la fin du projet un plan détaillé construit au démarrage. Des architectes et analystes experts doivent définir la conception, avant de la transmettre aux programmeurs pour limplémentation. Principes de base Caractéristiques dun cycle de vie en cascade

7 Suppose que lon puisse définir toutes les exigences, ou au moins la plupart, dès le début. Refuse tout changement pour «tout bien faire dès le début». –La formalisation exacte des exigences doit précéder la conception, qui doit elle-même être finalisée avant de passer à limplémentation. Exige daccorder une attention très importante aux documents. –Ex. : livrer une première ébauche, attendre 15 jours les retours, intégrer ces commentaires (10 jours), livrer une nouvelle version,... Principes de base Difficultés liées au cycle de vie en cascade (1)

8 Retarde la résolution des facteurs de risque. –Par exemple, intégration tardive dans le cycle de vie Entraîne une identification tardive de la conception, et un démarrage tardif du codage. Entraîne des relations conflictuelles avec les parties prenantes en raison : –Du manque de clarté de la définition des exigences. –Dengagements importants dans un contexte de profonde incertitude. –Dun désir inévitable de procéder à des changements. Principes de base Difficultés liées au cycle de vie en cascade (2)

9 Il doit permettre de : –Bien comprendre les demandes des utilisateurs finaux. –Tenir compte des changements du cahier des charges. –Empêcher la découverte tardive de défauts sérieux dans le projet. –Traiter au plus tôt tous les points critiques du projet. –Bien communiquer avec le client. –Bien maîtriser la complexité. –Favoriser la réutilisation. –Définir une architecture robuste. –Faciliter le travail en équipe. –... Principes de base Le processus « idéal » pour le développement de logiciel

10 7 bonnes pratiques Œ DŒ Développement de manière itérative.  Pilotage par les risques. Ž Gestion des exigences (piloté par les cas dutilisation).  Maîtrise des modifications.  Développement à base de composants centré sur larchitecture. ‘ Évaluation continue de la qualité. ’ Modélisation visuelle. Les bonnes pratiques …

11 Quest ce quun processus ? Suite ordonnée dopérations aboutissant à un résultat. –Un même projet sappuie sur de multiples processus simultanés. Projet Gestion des exigences ImplémentationTestGestion de configuration Gestion de projet Origine du processus unifié

12 Notion de processus (1) Les spécialistes en méthodologie distinguent: les processus «lourds» des processus «légers» –Terme péjoratif qui sert à suggérer que le processus présente l'une des caractéristiques suivantes. nombreux artefacts créés dans un environnement bureaucratique; rigidité et contrôle; planification à long terme; élaborée et détaillée; –processus prédictif plutôt qu'adaptatif. les processus «prédictifs» –tente de prévoir et de planifier en détail toutes les activités et les allocations de ressources (les individus) sur une période relativement longue. –Les processus prédictifs ont généralement un cycle de vie en "cascade" ou séquentiel, qui consiste à : 1.Définir tous les besoins. 2.Mettre au point une conception détaillée. 3.Implémenter. Origine du processus unifié

13 Notion de processus (2) Des processus «adaptatifs». –Accepte que le changement soit un moteur inévitable, et il favorise souplesse et adaptation. Son cycle de vie est habituellement itératif. –Un processus "agile" est léger et adaptatif. –De préférence, l'ensemble des activités et des artefacts doit être restreint. –Comme le Processus Unifié est itératif, les spécifications et la conception ne sont pas terminées avant le début de l'implémentation. Elles sont développées sur un mode adaptatif lors de la suite des itérations, grâce au feed-back. –Le projet global n'a pas de plan détaillé. Il existe un plan de phases qui estime une date d'achèvement et d'autres échéances majeures, mais ne détaille pas précisément les étapes, nécessaires pour les atteindre. Un plan détaillé, nommé plan d'itération, ne planifie de façon détaillée qu'une itération à la fois. La planification détaillée s'effectue de manière adaptative ditération en itération. Origine du processus unifié

14 Activités du processus (UP) InceptionÉlaborationConstructionTransition Organisation selon le temps Organisation selon le contenu V1 Itération(s) Itér. #1Itér. #2Itér. nItér. n+1Itér. n+2Itér. m Principaux enchaînements du processus Modélisation métier Gestion des exigences Analyse et conceptionImplémentation Tests Déploiement Principaux enchaînements de soutien Gestion de la config. & des changements Direction de projet Environnement 10%30%50%10% Répartition typique de leffort Aspect statique Aspect dynamique Processus à 2 dimensions

15 Bonne pratique Bonne pratique : Développer de manière itérative.

16 Une itération est une séquence définie dactivités qui se déroule selon un plan établi et se termine par une livraison (interne ou externe), et pour laquelle on a défini des critères dévaluation. Définition dune itération Itératif …

17 Qu'est-ce que le Développement Itératif ?(1) Cest planifier et gérer. Cest prévoir. Cest adapter les modifications des besoins en douceur. Cest piloté par le risque. Cest basé sur des prototypes évolutifs qui fonctionnent, pas de la documentation. Ça implique le client et lutilisateur pendant tout le processus. Itératif …

18 Basé sur de petites étapes, le feedback et ladaptation. Aussi appelé évolutif, en spirale,... Le feedback continu est un élément clé du succès. –De la part le retour des utilisateurs, des tests,... A chaque itération, on s'adapte en se basant sur le feedback et les leçons de la dernière itération, et on converge doucement vers de meilleurs : –Conception, Plans, Exigences, Estimations. 2 o u 4 semaines Itératif … Qu'est-ce que le Développement Itératif ?(2)

19 Analyse et conception Implémentation Test Évaluation Planification Besoins Planification initiale Déploiement Chaque itération a pour résultat une version exécutable Cycle itératif Itératif …

20 La réduction du risque pilote les itérations Risques Projet Initiaux Portée Initiale du Projet Réviser Plan Global Projet Coût Planning Portée/Contenu Planifier Itération N Coût Planning Fixer Itération N Risques Éliminés Réviser Risques Projet Réordonner Priorités Développer Itération N Collecter coût et métriques de qualité Définition de scénarios Risques supérieurs Itération N Itératif …

21 Durée des itérations « Idéalement, une itération doit durer de 2 à 6 semaines. » P.Kruchten, « The RUP - An Introduction » personnes : 2-4 sem personnes : 2-6 sem. Raccourcir les itérations permet de réduire les risques. Facteurs augmentant la durée : –Séparation géographique de léquipe. –Premier projet UP pour lorganisation ou léquipe. –Premier projet objet pour lorganisation ou léquipe. Incep- tion ElaborationConstruction Transi- tion Modifications des besoins Itératif …

22 3 caractéristiques importantes de lapproche itérative Attaque du risque avec une progression quantifiable. –La progression est mesurée sur le produit, pas sur de la documentation ou sur des estimations. Intégration continuelle. –Pas testée en une seule fois la veille de rendre le projet ! Publications fréquentes dexécutables. –Certains en interne, certains fournis au client. Itératif …

23 Lundi Répartition du travail. Exigences. Analyse & conception Mardi Exigences. Analyse & conception. Mercredi Analyse & conception Implém. Tests & contrôle qualité. Semaine 1 Semaine 2 Jeudi Implém. Préparation Démo. Planif. itération suivante. Plan du projet. Vendredi Évaluation de litération Finalisation planification Jeudi Analyse & conception Implém. Tests & Contrôle qualité Vendredi Implém. Tests & contrôle qualité. Intégration Lundi Implém. Tests & contrôle qualité. Intégration Mardi Implém. Tests & contrôle qualité. Intégration Mercredi Implém. Tests & contrôle qualité. Intégration Itératif … Exemple dune itération de deux semaines

24 Bénéfices La publication de versions intermédiaires force léquipe de développement à finir quelque chose à intervalles réguliers. –On ne peut pas tomber dans le piège du fini à 90% avec 90% restant à faire. Les problèmes et les modifications peuvent être traités dans des itérations futures, plutôt que de devoir casser la production en cours. Les acteurs qui supportent le projet (testeurs, support hotline, …) peuvent organiser leur travail de manière plus efficace. Itératif …

25 Modèle en spirale Défini par Barry Boehm en Réévaluation des risques en cours de développement. Chaque phase / itération démarre avec un objectif et finit par une validation client. Estimations budgétaires et calendaires plus réalistes au fur et à mesure de l'avancement du projet. Facilité de prise en compte des inévitables changements intervenant en cours de projet. Itératif …

26 A retenir Décomposer le développement en courtes itérations Pour surmonter les difficultés : itérer !! Conclusion

27 Bonne pratique Bonne pratique : Gestion des exigences grâce aux cas dutilisation.

28 Cas dutilisation Un cas dutilisation est une séquence dactions que réalise un système et qui fournit un résultat observable ayant une valeur pour un acteur particulier. Un acteur est quelquun ou quelque chose se situant à lextérieur du système et qui interagit avec lui. La gestion des exigences

29 Exemple(1) Etudier le Cas dutilisation « Retrait Visa » formalisé avec UML. Ajouter quelques exigences non fonctionnelles à ce cas dutilisation. La gestion des exigences

30 Système DAB Client Système Consulter Solde Retirer Argent Consulter dernières Opérations Cas dutilisation Acteurs Frontière du système Système dautorisation VISA Exemple(2) La gestion des exigences

31 Exemple(3) Liste des acteurs Liste de pré-conditions Événement déclencheur Liste de post-conditions Acteurs : client, système dautorisation VISA Cas dutilisation : Retrait VISA Pré-conditions : - le DAB fonctionne - la caisse du DAB est alimentée Description : Le cas dutilisation commence lorsque le client introduit sa carte dans le lecteur. […] Post-conditions : - le montant demandé est délivré - lopération de retrait est enregistrée - le client a récupéré sa carte Résumé : Retrait dargent avec une carte bleue VISA Séquences dinteractions La gestion des exigences

32 Un cas dutilisation spécifie : –Un enchaînement « nominal ». –Des enchaînements alternatifs. –Des enchaînements derreur et dexception. Enchaînement nominal : Lorsquun enchaînement nominal ou alternatif est exécuté, les post- conditions sont atteintes. 1. Enchaînement nominal : a. Le cas dutilisation commence lorsque le client introduit sa carte b. Le DAB demande au client de saisir son code didentification. e. Le DAB demande une autorisation au système VISA. f. Le système VISA donne son accord et délivre un numéro dautorisation. g. Le DAB demande au client de saisir le montant désiré. h. Le client saisit le montant désiré. i. Le DAB contrôle le montant demandé par rapport au solde hebdomadaire j. Le DAB rend sa carte au client. k. Le client reprend sa carte. l. Le DAB délivre les billets et un ticket m. Le client prend les billets et le ticket. n. Ce cas dutilisation se termine lorsque le DAB est prêt à fonctionner c. Le client saisit son code didentification. d. Le DAB vérifie le code didentification avec celui codé sur la carte. Exemple(4) La gestion des exigences

33 Exemple(5) Enchaînement derreur : Lorsquun enchaînement derreur est exécuté, les post-conditions sont toujours atteintes. 2. Enchaînement derreur : code didentification incorrect Lenchaînement démarre au point 1-d. de lenchaînement nominal a. Le DAB indique au client que le code est erroné b. Le DAB enregistre léchec sur la carte Lenchaînement nominal reprend au point 1-b. 3. Enchaînement dexception : le client a saisi 3 fois un code erroné : a. le DAB confisque la carte b. Le système VISA est informé et le cas dutilisation se termine. 4. Enchaînement derreur : montant supérieur au solde hebdomadaire Lenchaînement démarre au point 1-i. de lenchaînement nominal a. Le DAB indique que le montant demandé est supérieur au solde Lenchaînement nominal reprend au point 1-g. Enchaînement dexception : Lorsquun enchaînement dexception est exécuté, les post-conditions ne sont pas atteintes. La gestion des exigences

34 A retenir Décomposer le développement en courtes itérations Décrire les exigences par les cas dutilisation !! Conclusion

35 …Et aussi Appliquer les 5 autres bonnes pratiques : Pilotage par les risques. Maîtrise des modifications. Développement à base de composants centré sur larchitecture. Évaluation continue de la qualité. Modélisation visuelle. Conclusion

36 Plus dinformations … Livres –Introduction au Rational Unified Process, Philippe Kruchten, Eyrolles, –Rédiger des cas dutilisation efficaces, Alistair Cockburn, Eyrolles, –Le processus unifié de développement logiciel, I.Jacobson, G.Booch, J.Rumbaugh, Eyrolles, –Rational Unified Process Made Easy: A Practitioner's Guide to the RUP, Per Kroll & Philippe Kruchten, Addison-Wesley, –Object Solutions - Managing the Object-Oriented Project, Grady Booch, Addison-Wesley, –Articles Sites –UML Rational (IBM) : –AmbySoft : –Ronin : –OMG : –UML :


Télécharger ppt "Direction Technique Cycle de vie du projet et Cas dutilisation."

Présentations similaires


Annonces Google