Cycle de vie du projet et Cas d’utilisation

Présentation au sujet: "Cycle de vie du projet et Cas d’utilisation"— Transcription de la présentation:

1 Cycle de vie du projet et Cas d’utilisation
Direction Technique Cycle de vie du projet et Cas d’utilisation

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

3 Qu’est ce qu’un 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 en cascade 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. Principes de base

5 Le cycle de vie en cascade
Que se passe-t-il lorsqu’on découvre à ce stade des changements par rapport aux exigences ? 2 mois Now is the time for men in the ranks to stay in the ranks. 1 mois Et à ce stade ? 4 mois Et à celui-ci ? Recueillir les exigences Analyser 12 mois 2 mois Concevoir Cycle en cascade type : Définir la plupart des exigences Concevoir l’architecture de base Concevoir les parties essentielles du système (c’est-à-dire : les diagrammes et documents décrivant la conception) Modéliser avec soin la couche du domaine, jusqu’à ce que le développement soit satisfaisant et robuste Procéder à l’implémentation à partir de la conception Effectuer l’intégration, les tests et le contrôle qualité Coder Intégrer, tester & effectuer le contrôle qualité Principes de base

6 Caractéristiques d’un cycle de vie en cascade
Les fonctionnalités (exigences) doivent être clarifiées avant de débuter la conception ou l’implémentation. Les objets du domaine (Métier) sont précisément modélisés avant la conception ou l’implé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 l’implémentation. Principes de base

7 Difficultés liées au cycle de vie en cascade (1)
Suppose que l’on 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 à l’implémentation. Exige d’accorder 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

8 Difficultés liées au cycle de vie en cascade (2)
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. D’engagements importants dans un contexte de profonde incertitude. D’un désir inévitable de procéder à des changements. Principes de base

9 Le processus « idéal » pour le développement de logiciel
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

10 7 bonnes pratiques Pilotage par les risques.
Développement de manière itérative. Pilotage par les risques. Gestion des exigences (piloté par les cas d’utilisation). Maîtrise des modifications. Développement à base de composants centré sur l’architecture. Évaluation continue de la qualité. Modélisation visuelle. Les bonnes pratiques …

11 Qu’est ce qu’un processus ?
Suite ordonnée d’opérations aboutissant à un résultat. Un même projet s’appuie sur de multiples processus simultanés. Projet Gestion des exigences Implémentation Gestion de configuration Test Gestion de projet Origine du processus unifié

12 Les spécialistes en méthodologie distinguent:
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 à : Définir tous les besoins. Mettre au point une conception détaillée. Implémenter. Origine du processus unifié

13 Des processus «adaptatifs».
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 d’itération en itération. Origine du processus unifié

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

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

16 Définition d’une itération
Une itération est une séquence définie d’activité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. Itératif …

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

18 Qu'est-ce que le Développement Itératif ?(2)
Basé sur de petites étapes, le feedback et l’adaptation. 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 ou 4 semaines 2 ou 4 semaines Itératif …

19 Planification initiale Besoins Analyse et conception
Cycle itératif Planification initiale Besoins Analyse et conception Planification Implémentation Évaluation Déploiement Chaque itération a pour résultat une version exécutable Les activités d’ingénierie sont couvertes par plusieurs itérations Les tests sont réalisés régulièrement, le développement itératif implique le passage de tests de non régression (automatisation des tests). Test Itératif …

20 La réduction du risque pilote les itérations
Réviser Plan Global Projet Coût Planning Portée/Contenu Planifier Itération N 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 Risques Projet Initiaux Portée Initiale du Projet Itératif …

21 Modifications des besoins
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 l’organisation ou l’équipe. Premier projet objet pour l’organisation ou l’équipe. Incep- tion Elaboration Construction Transi- Modifications des besoins Itératif …

22 3 caractéristiques importantes de l’approche 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 d’exécutables. Certains en interne, certains fournis au client. Itératif …

23 Exemple d’une itération de deux semaines
Lundi Répartition du travail. Exigences. Analyse & conception Mardi Exigences.Analyse & conception. Mercredi Analyse & conception Implém. Tests & contrôle qualité. Jeudi Analyse & conception Implém. Tests & Contrôle qualité Vendredi Implém. Tests & contrôle qualité. Intégration Semaine 2 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 Jeudi Implém. Préparation Démo. Planif. itération suivante. Plan du projet. Vendredi Évaluation de l’itération Finalisation planification Si une démonstration doit avoir lieu, elle est programmée le Vendredi (sem 2). Itératif …

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 Défini par Barry Boehm en 1981.
Modèle en spirale Défini par Barry Boehm en 1981. 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 Pour surmonter les difficultés : itérer !!
A retenir Décomposer le développement en courtes itérations Pour surmonter les difficultés : itérer !! Adopter réellement cette démarche impliquent de profonds changements dans les pratiques et les valeurs de beaucoup d’organisations. Et une erreur courante consiste à ne pas comprendre la signification de ce changement des plus critiques. Au lieu de cela, des entreprises pensent avoir adopté le UP en se fixant sur des idées mineures du UP, telles que les workflows, ou les Development Cases. Si on n’adopte pas le changement profond que suppose le passage du cycle en cascade au cycle itératif, on ne fait pas vraiment du UP. Conclusion

27 Bonne pratique : Gestion des exigences grâce aux cas d’utilisation.

28 Cas d’utilisation Un cas d’utilisation est une séquence d’actions que réalise un système et qui fournit un résultat observable ayant une valeur pour un acteur particulier. Un acteur est quelqu’un ou quelque chose se situant à l’extérieur du système et qui interagit avec lui. La gestion des exigences

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

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

31 Exemple(3) La gestion des exigences Liste des acteurs Liste de
Cas d’utilisation : Retrait VISA Résumé : Retrait d’argent avec une carte bleue VISA Liste de pré-conditions Acteurs : client, système d’autorisation VISA Pré-conditions : Événement déclencheur - le DAB fonctionne - la caisse du DAB est alimentée Description : Séquences d’interactions Le cas d’utilisation commence lorsque le client introduit sa carte dans le lecteur. […] Liste de post-conditions Post-conditions : D’autres sections peuvent être ajoutées pour spécifier des contraintes ou des exigences non fonctionnelles : Besoins d’IHM Exigences de performance et de capacité temps de réponse fréquence volumétrie concurrence Exigences de disponibilité, intégrité, sécurité, sûreté Exigences techniques etc. - le montant demandé est délivré - l’opération de retrait est enregistrée - le client a récupéré sa carte La gestion des exigences

32 Exemple(4) Un cas d’utilisation spécifie :
Un enchaînement « nominal ». Des enchaînements alternatifs. Des enchaînements d’erreur et d’exception. 1. Enchaînement nominal : a. Le cas d’utilisation commence lorsque le client introduit sa carte b. Le DAB demande au client de saisir son code d’identification. Enchaînement nominal : Lorsqu’un enchaînement nominal ou alternatif est exécuté, les post-conditions sont atteintes. c. Le client saisit son code d’identification. d. Le DAB vérifie le code d’identification avec celui codé sur la carte. e. Le DAB demande une autorisation au système VISA. f. Le système VISA donne son accord et délivre un numéro d’autorisation. 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 d’utilisation se termine lorsque le DAB est prêt à fonctionner La gestion des exigences

33 Exemple(5) La gestion des exigences Enchaînement d’erreur :
Lorsqu’un enchaînement d’erreur est exécuté, les post-conditions sont toujours atteintes. Enchaînement d’exception : Lorsqu’un enchaînement d’exception est exécuté, les post-conditions ne sont pas atteintes. 2. Enchaînement d’erreur : code d’identification incorrect L’enchaînement démarre au point 1-d. de l’enchaînement nominal a. Le DAB indique au client que le code est erroné b. Le DAB enregistre l’échec sur la carte L’enchaînement nominal reprend au point 1-b. 3. Enchaînement d’exception : 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 d’utilisation se termine. 4. Enchaînement d’erreur : montant supérieur au solde hebdomadaire L’enchaînement démarre au point 1-i. de l’enchaînement nominal a. Le DAB indique que le montant demandé est supérieur au solde L’enchaînement nominal reprend au point 1-g. La gestion des exigences

34 Décrire les exigences par les cas d’utilisation !!
A retenir Décomposer le développement en courtes itérations Décrire les exigences par les cas d’utilisation !! Adopter réellement cette démarche impliquent de profonds changements dans les pratiques et les valeurs de beaucoup d’organisations. Et une erreur courante consiste à ne pas comprendre la signification de ce changement des plus critiques. Au lieu de cela, des entreprises pensent avoir adopté le UP en se fixant sur des idées mineures du UP, telles que les workflows, ou les Development Cases. Si on n’adopte pas le changement profond que suppose le passage du cycle en cascade au cycle itératif, on ne fait pas vraiment du UP. Conclusion

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

36 Plus d’informations … Livres
Introduction au Rational Unified Process, Philippe Kruchten, Eyrolles, 2000. Rédiger des cas d’utilisation efficaces, Alistair Cockburn, Eyrolles, 2001. Le processus unifié de développement logiciel, I.Jacobson, G.Booch, J.Rumbaugh, Eyrolles, 2000. Rational Unified Process Made Easy: A Practitioner's Guide to the RUP, Per Kroll & Philippe Kruchten, Addison-Wesley, 2003. Object Solutions - Managing the Object-Oriented Project, Grady Booch, Addison-Wesley, 1996. Articles Sites UML Rational (IBM) : AmbySoft : Ronin : OMG : UML : Et … Unified Modeling Language - An Application Guide, Booch, Rumbaugh, Jacobson, Addison-Wesley, 1999 Unified Software Development Process, Jacobson, Booch, Rumbaugh, Addison-Wesley - coming Q1, 1999 Conclusion