Rapport de Synthèse Cycle en V, UP et SCRUM Réalisé par : BELLINI Quentin GNANAKULENTHIRAN Anitha GOVINDEN Johana MEZINE Ahcene TIMZOUERT Chabane 19/10/2011 www.sup-galilee.univ-paris13.fr
Table des matières I. Introduction... 3 II. Cycle en V...4 1) Description...4 2) Description des phases du cycle...5 3) Risques et avantages du cycle en V...6 III. SCRUM...7 1) Définition...7 2) Les caractéristiques de SCRUM...7 3) Les rôles de la méthodologie SCRUM...8 4) Les processus de la méthodologie SCRUM...9 5) Gestion des besoins...10 IV. UP....10 1)Définition....10 2)Piloté par les cas d'utilisation.. 10 3)Centré sur l'architecture...11 4)Itératif et incrémental..11 5)Cycle de vie du processus.11 6)Conclusion.12 V. Conclusion.....12 VI. Sources et Annexes....12
I. Introduction : Avant de se lancer dans le développement d'un logiciel informatique, on prévoit une méthodologie de travail pour assurer le bon déroulement du projet tout en restant dans les limites du budget. En informatique et spécifiquement dans le domaine du développement, on a recours à différentes techniques et méthodes de travail qui permettent de gérer, d'organiser les équipes et de répondre aux besoins du client par la réalisation du produit désiré en un délai fixé. Dans ce rapport, on présentera en détails deux méthodes itératives (UP, SCRUM) et une méthode séquentielle (Cycle en V) assez utilisées: 3
I) CYCLE EN V: 1) Description : Le modèle du cycle en V est une méthode d'organisation pour le développement d'un logiciel. Ce modèle a été imaginé pour pallier aux problèmes du modèle en cascade. Le principe de celui-ci est de découper le projet en plusieurs étapes distinctes sur le principe du non-retour. Le cycle en V est devenu un modèle standard de l'industrie logicielle depuis les années 80.En quelque mots, il permet de vérifier la qualité du produit en continu au fur et à mesure de l'avancement du projet. Le principe étant de limiter le retour aux étapes précédentes. Voici un aperçu du cycle en V : 2 figure1. Le cycle en V Comme nous pouvons le voir sur la figure1. le modèle est constitué de trois grandes phases : descendante (1) ou phase de conception, phase de réalisation ou codage (2) et enfin la phase de validation ou ascendante (3). 4
2 Description des phases du cycle : L'étape de spécification est en correspondance avec l'étape de validation. L'étape de conception générale est en correspondance avec l'étape des tests d'intégration. L'étape de conception détaillée est en correspondance avec l'étape des tests unitaires. 2-1) Phase descendante : a) Le besoin d'étude et de faisabilité (Cahier des charges) : C'est le point de départ du cycle, cette étape reflète les besoins du client. Cela doit répondre à différentes questions : que veut le client? Est-ce réalisable? Les coûts? Le cahier des charges, rédigé par le client, décrit l'ensemble des besoins fonctionnels attendus par le système. Elle permet une meilleure compréhension du système et la structuration des besoins du client. b) Spécification: Les spécifications reprennent en détail les éléments du cahier des charges. Cette étape décrit de façon exhaustive ces exigences avec, par exemple, des diagrammes de cas d'utilisations (UML). c) Conception générale : La conception générale décrit de façon plus détaillée les fonctionnalités du logiciel. Chaque fonctionnalité est décrite en spécifiant son algorithme. La conception générale décrit également l'architecture du futur logiciel. A cette étape, la phase des tests d'intégration est initiée c'est-à-dire les tests qui permettront de démontrer que chaque fonctionnalité a été correctement implémenté. d) Conception détaillée : Chaque algorithme spécifié dans l'étape précédente est détaillé pour permettre à un programmeur de coder des algorithmes justes en lisant la conception détaillée. On est très proche du code final. A cette étape, est initiée la phase des tests unitaires qui permettront plus tard de prouver l'absence de " bugs". 2-2) Phase de réalisation : a) Codage : Le codage ou développement informatique est la transcription en langage interprétable par un compilateur de la conception détaillée avec des langages comme JAVA, C++, PHP etc. La fin du codage ne signifie pas la fin du projet, car il reste encore un ensemble de dysfonctionnement ou «bugs» qu'il est nécessaire de détecter et corriger. La phase de test est là pour supprimer autant que faire se peut les dysfonctionnements du codage. 5
2-3) Phase ascendante : a) Tests unitaires : Les tests unitaires permettent de vérifier qu'il n'y a aucune erreur entre la transcription de la conception générale et le code. Ces tests ont déjà été décrits dans la conception détaillée. b) Tests d'intégration : Cette étape permet de vérifier qu il n existe pas d erreurs entre la conception générale et la conception détaillée. Ces tests ont déjà été décrits dans la conception générale. c) Validation et Maintenance : On montre au client que le logiciel décrit dans le cahier des charges est bien en accord avec le produit final, pour cela une batterie de tests est imaginée pour montrer qu'il fonctionne bien comme le client le souhaitait. 3 - Risques et avantages du cycle en V : 3-1)Risques : Il arrive qu'à la phase de conception détaillée et ou à la phase de codage, des difficultés d'ordre technique ou de cohérence surviennent. Dans la partie théorique, ces problèmes ne peuvent survenir. C'est au cours de cette phase que l'on se rende compte que les spécifications peuvent être incomplètes, irréalisables ou même fausses. Pour certains produits compétitifs (exemple : logiciels micros...) la durée imposée par le cycle de vie est difficilement acceptée. 3-2)avantages : L'avantage du modèle est qu'il est un excellent support à la formalisation des relations entre le client et l'équipe de développement. En effet, il oblige le client à réfléchir aux différents aspects de sa demande. La phase de " spécification " permet à l'équipe de vérifier que la demande du client à été bien comprise. Le client valide généralement la spécification. La vérification/validation évite les retours arrière. 6
II. SCRUM : 1) Définition : SCRUM est un terme anglais qui signifie : mêlée. C'est comme au rugby, tous les membres de l'équipe doivent être soudés pour atteindre un but commun. C'est une méthode agile dans l'objectif est d'améliorer la productivité. Les méthodes agiles sont des groupes de pratiques pouvant s'appliquer à divers types de projets, notamment aux projets de développement en informatique. Ces méthodes impliquent au maximum le client pour une réelle satisfaction des ses besoins. Les valeurs des méthodes agiles sont: Les personnes et interactions priment sur les processus et les outils Logiciel fonctionnel privilégié par rapport à une documentation détaillée Collaboration avec le client plutôt qu'une négociation au contrat S'adapter au changement plutôt que de suivre un plan 2) Les caractéristiques de SCRUM : Itératif, lié a des processus incrémentaux Approche basé sur l'équipe Fait pour développer des produits/applications nécessitant une grande adaptabilité Contrôler le chaos résultat de conflits d'intérêt et des différents besoins Augmenter la communication et maximiser la coopération Protéger l'équipe des éléments externes perturbateurs Un moyen d'augmenter la productivité Le principe de base de Scrum est de focaliser l'équipe sur une partie limitée et maîtrisable des fonctionnalités à réaliser. Ces incréments se réalisent successivement lors de périodes de durée fixe de une à quatre semaines, appelées sprints. Chaque sprint possède, un but à atteindre, défini par le directeur de produit, à partir duquel sont choisies les fonctionnalités à implémenter dans cet incrément. Un sprint aboutit toujours à la livraison d'un produit partiel fonctionnel. 7
3) Les rôles de la méthodologie SCRUM : a) Directeur de produit : Le directeur de produit (Product Owner) est le représentant des clients et utilisateurs. C'est lui qui définit l'ordre dans lequel les fonctionnalités seront développées et qui prend les décisions importantes concernant l'orientation du projet. b) Équipe : L'équipe ne comporte pas de rôles prédéfinis, elle est auto-gérée sans aucune hiérarchie interne : toutes les décisions sont prises ensemble avec beaucoup d'efficacité et une production de qualité de façon spontanée. L'équipe s'adresse directement au directeur de produit qu'il puisse ajuster les détails d'ergonomie et d'interface par exemple. c) ScrumMaster : Le facilitateur / animateur (ScrumMaster), on le considère bien souvent comme le manager de projet ou le Chef d'équipe. Il est chargé de protéger l'équipe de tous les éléments perturbateurs extérieurs à l'équipe et de résoudre ses problèmes non techniques. Responsable de faire appliquer par l équipe les valeurs et les pratiques de Scrum Résout des problèmes S'assure que l'équipe est complètement fonctionnelle et productive Facilite une coopération poussée entre tous les rôles et fonctions Protège l'équipe des interférences extérieures d) Intervenants : Les intervenants (Stakeholders) sont les personnes qui souhaitent avoir une vue sur le projet sans réellement s'investir dedans. 8
4) Les processus de la méthodologie SCRUM : a) Planification : La réunion de planification (Sprint Planning) consiste à définir d'abord un but pour le sprint, puis à choisir les items de backlog de produit qui seront réalisés dans ce sprint b) Sprint: Scrum est un processus itératif : les itérations sont appelées des sprints et durent généralement entre 2 et 4 semaines. Chaque sprint a un but avec une liste d'items de backlog de produit (fonctionnalités) à réaliser. Ces items sont décomposés par l'équipe en tâches élémentaires de quelques heures, les items de backlog de sprint. c) Scrum quotidien : Au quotidien, une réunion appelée le ScrumMeeting, de 5 min environ et debout, permet à l'équipe et au ScrumMaster de faire un point d'avancement sur les tâches et sur les difficultés rencontrées. d) Revue du Sprint : A la fin du sprint, tout le monde se réunit pour effectuer la Revue de sprint, qui dure au maximum 4 heures. L'objectif de la revue de sprint est de valider le logiciel qui a été produit pendant le sprint. e) Rétrospective : Cette étape est une démarche courante en fin de projet. Pendant 15 à 30 min, on réfléchit à ce qui marche et ce qui ne marche pas. On applique ici un principe de Start / Stop / Continue. 9
5) Gestion des besoins : a) Backlog de produit : On appelle backlog de produit la liste de fonctionnalités à réaliser. À chaque item de backlog sont associés deux attribut : une estimation en points arbitraires et une valeur client, qui est définie par le directeur de produit (retour sur investissement par exemple). Ce dernier définit dans quel ordre devront être réalisés ces items. Il peut changer cet ordre en cours de projet et même ajouter, modifier ou supprimer des items dans le backlog. b) Backlog de sprint : Le backlog de sprint est le fait de décomposer chaque item du backlog en liste de tâches élémentaires estimées en heures et ne devant pas durer plus de 2 jours. c)les burndown charts (graphiques d'avancement ) : permettent de visualiser graphiquement l'avancement du travail : la quantité totale d'heures restantes à faire dans le sprint, la quantité totale de points restant à faire, au fil des sprints. IV) UNIFIED PROCESS : 1)Définition Unified Process (appelé UP) est un processus de développement logiciel orienté objet itératif et incrémental, piloté par les cas d'utilisation et centré sur l'architecture. Ce processus est générique (on parle de Framework), il fournit un ensemble de pratique et de concept qu'il va falloir adapter au contexte spécifique du projet afin de répondre aux quatre questions suivante: QUI participe au projet? QUOI, qu'est-ce qui est produit durant le projet? COMMENT doit-il être réalisé? QUAND est réalisé chaque livrable? Ce processus est basé sur les composants et utilise UML (il a d'ailleurs été crée par un créateur d'uml et en constitue finalement une dérivation). 2)Piloté par les cas d'utilisation : Le but d'un logiciel est de rendre service à ses utilisateurs. Afin de définir les fonctions que devront offrir le logiciel on définit le modèle de cas d'utilisation basés sur l utilisation du langage UML. A partir du modèle des cas d utilisation, les développeurs créent une série de modèles de conception et d implémentation réalisant les cas d utilisation. La conformité par rapport au modèle de cas d'utilisation est le moteur du processus c'est pour cela qu'on dit qu'il est piloté par les cas d'utilisation. Mais ces cas doivent trouver leur place dans une architecture spécifique qui va être pensée dés le démarrage du processus 10
3)Centré sur l'architecture : L'architecture est définie selon différentes vues centrées sur l'analyse des besoins de l'utilisateur. Sa conception est aussi tributaire de la plate forme sur laquelle devra s'exécuter le système et des briques de base réutilisable. L'architecture est défini de manière sommaire, indépendamment des cas d'utilisation, au départ du processus et ensuite elle va émerger au fil des spécifications des cas d'utilisation jusqu'à obtenir une architecture jugée stable. 4)Itératif et incrémental : Afin de limiter les risques et les coûts on découpe le développement (qui peut être très long) en différentes étapes qu'on appelle itération. Au cours de l'itération on va implémenter certains cas d'utilisation sous forme de composant (c'est à dire un prototype exécutable). Si on juge l'implémentation correcte on obtient un incrément et on passe à l'itération suivante. Le choix des cas d'utilisation pertinents (en privilégiant d'abord les fonctions à risque) à implémenter aux différentes itérations est fait en début de processus. Cette manière de découper le développement permet de détecter et réparer une erreur sans attendre la phase de test en fin de développement (comme dans les méthodes séquentielles). Au chaque itération on va effectuer plusieurs activités qui vont de l'expression des besoins aux phases de conception et de test. Les itérations vont être répétées plusieurs fois dans les différents cycles du processus. 5)Cycle de vie du processus Le processus répète une série de cycles qui vont aboutir à chaque fois à une nouvelle version du système livrée au client. Chaque cycle est découpé en quatre phases contenant chacune des itérations. Pour obtenir une version livrable au client au bout du cycle il faut développer toutes les représentations du logiciel par le biais de différents modèles liés. http://en.wikipedia.org/wiki/ibm_rational_unified_process 11
Au cours des quatre phases du cycle certaines activités de l'itération seront plus sollicitées que d'autres comme on peut le voir sur le graphique. La phase de création (inception) est l'occasion de faire une étude de rentabilité du système et permet de faire apparaître une première idée du produit fini. On définit les cas d'utilisation principaux et les risque majeurs. On définit grossièrement une architecture et on planifie l'élaboration. La phase d'élaboration permet de spécifier les cas d'utilisations et de définir une architecture de référence. Le chef de projet peut alors estimer les ressources et activités nécessaires. La phase de construction va permettre de transformer l'architecture en produit fini répondant au cas d'utilisation définit en accord avec le client et de définir aussi des cas d'utilisation auquel on n'aurait pas pense précédemment. Ce produit est considéré comme stable mais il peut contenir encore des erreurs qui vont pouvoir être décelé au cours de la phase de transition. En effet cette phase consiste a faire essayer une version bêta a un groupe d'utilisateur formé qui vont faire remonter les anomalies rencontrés. 6)Conclusion : Unified Process met donc en place un cadre général qui peut être adapté ou la conception et la définition des cas d'utilisation s effectuent de manière concomitante. Il existe beaucoup d'implémentation de ce processus qui sont bien sur toujours itérative, pilotées par les cas d'utilisation et centrées sur l'architecture. La plus connu des implémentations est sans doute la méthode RUP développé par Rational Software (une division d'ibm). V. CONCLUSION: Les processus Scrum et UP sont tous les deux itératif ce qui permet de tester petit à petit les fonctionnalités du logiciel en privilégiant d'abord le noyau critique. Contrairement a une méthode séquentielle comme le cycle en V ou les phases de test sont effectuer seulement à la fin. L'un des inconvénients du cycle en V est qu'il délimite complètement la phase de conception et la phase d'implémentation. Alors que c'est souvent lors de la phase de codage qu'on réalise que les spécifications initiales étaient irréalisables. De plus le client peut demander de nouvelles fonctionnalités au cours du développement. Il est difficile d'opposer la méthode UP et la méthode SCRUM, elle peuvent être d'ailleurs utiliser en même temps sur un projet. La méthode UP offrant le cadre générale et la méthode SCRUM s'intéresse plutôt à l'organisation du projet qu'aux aspects techniques, et implique beaucoup plus le client au cours de la réalisation. VI. Sources et Annexes : http://fr.wikipedia.org/wiki/cycle_en_v. http://fr.wikipedia.org/wiki/unified_process. http://fr.wikipedia.org/wiki/scrum_(m%c3%a9thode). 12