Rapport de Synthse Cycle en V, UP et SCRUM

Ralis par : BELLINI Quentin GNANAKULENTHIRAN Anitha GOVINDEN Johana MEZINE Ahcene TIMZOUERT Chabane

19/10/2011

www.sup-galilee.univ-paris13.fr

Table des matires

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) Dfinition ...................................................................................................................7 2) Les caractristiques de SCRUM ..............................................................................7 3) Les rles de la mthodologie SCRUM ....................................................................8 4) Les processus de la mthodologie SCRUM ...........................................................9 5) Gestion des besoins .................................................................................10

IV. UP..........................................................................................................10
1)Dfinition....10 2)Pilot par les cas d'utilisation..10 3)Centr sur l'architecture.............................................................................11 4)Itratif et incrmental..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 dveloppement d'un logiciel informatique, on prvoit une mthodologie de travail pour assurer le bon droulement du projet tout en restant dans les limites du budget. En informatique et spcifiquement dans le domaine du dveloppement, on a recours diffrentes techniques et mthodes de travail qui permettent de grer, d'organiser les quipes et de rpondre aux besoins du client par la ralisation du produit dsir en un dlai fix. Dans ce rapport, on prsentera en dtails deux mthodes itratives (UP, SCRUM) et une mthode squentielle (Cycle en V) assez utilises:

I) CYCLE EN V:
1) Description :
Le modle du cycle en V est une mthode d'organisation pour le dveloppement d'un logiciel. Ce modle a t imagin pour pallier aux problmes du modle en cascade. Le principe de celui-ci est de dcouper le projet en plusieurs tapes distinctes sur le principe du non-retour. Le cycle en V est devenu un modle standard de l'industrie logicielle depuis les annes 80.En quelque mots, il permet de vrifier la qualit du produit en continu au fur et mesure de l'avancement du projet. Le principe tant de limiter le retour aux tapes prcdentes. Voici un aperu du cycle en V :

2 figure1. Le cycle en V

Comme nous pouvons le voir sur la figure1. le modle est constitu de trois grandes phases : descendante (1) ou phase de conception, phase de ralisation ou codage (2) et enfin la phase de validation ou ascendante (3).

2 Description des phases du cycle :

L'tape de spcification est en correspondance avec l'tape de validation. L'tape de conception gnrale est en correspondance avec l'tape des tests d'intgration. L'tape de conception dtaille 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 dpart du cycle, cette tape reflte les besoins du client. Cela doit rpondre diffrentes questions : que veut le client ? Est-ce ralisable ? Les cots ? Le cahier des charges, rdig par le client, dcrit l'ensemble des besoins fonctionnels attendus par le systme. Elle permet une meilleure comprhension du systme et la structuration des besoins du client. b) Spcification: Les spcifications reprennent en dtail les lments du cahier des charges. Cette tape dcrit de faon exhaustive ces exigences avec, par exemple, des diagrammes de cas d'utilisations (UML). c) Conception gnrale : La conception gnrale dcrit de faon plus dtaille les fonctionnalits du logiciel. Chaque fonctionnalit est dcrite en spcifiant son algorithme. La conception gnrale dcrit galement l'architecture du futur logiciel. A cette tape, la phase des tests d'intgration est initie c'est--dire les tests qui permettront de dmontrer que chaque fonctionnalit a t correctement implment. d) Conception dtaille : Chaque algorithme spcifi dans l'tape prcdente est dtaill pour permettre un programmeur de coder des algorithmes justes en lisant la conception dtaille. On est trs proche du code final. A cette tape, est initie la phase des tests unitaires qui permettront plus tard de prouver l'absence de " bugs".

2-2) Phase de ralisation :

a) Codage : Le codage ou dveloppement informatique est la transcription en langage interprtable par un compilateur de la conception dtaille avec des langages comme JAVA, C++, PHPetc. La fin du codage ne signifie pas la fin du projet, car il reste encore un ensemble de dysfonctionnement ou bugs qu'il est ncessaire de dtecter et corriger. La phase de test est l pour supprimer autant que faire se peut les dysfonctionnements du codage.

2-3) Phase ascendante :

a) Tests unitaires : Les tests unitaires permettent de vrifier qu'il n'y a aucune erreur entre la transcription de la conception gnrale et le code. Ces tests ont dj t dcrits dans la conception dtaille. b) Tests d'intgration : Cette tape permet de vrifier quil nexiste pas derreurs entre la conception gnrale et la conception dtaille. Ces tests ont dj t dcrits dans la conception gnrale. c) Validation et Maintenance : On montre au client que le logiciel dcrit dans le cahier des charges est bien en accord avec le produit final, pour cela une batterie de tests est imagine 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 dtaille et ou la phase de codage, des difficults d'ordre technique ou de cohrence surviennent. Dans la partie thorique, ces problmes ne peuvent survenir. C'est au cours de cette phase que l'on se rende compte que les spcifications peuvent tre incompltes, irralisables ou mme fausses. Pour certains produits comptitifs (exemple : logiciels micros....) la dure impose par le cycle de vie est difficilement accepte. 3-2)avantages : L'avantage du modle est qu'il est un excellent support la formalisation des relations entre le client et l'quipe de dveloppement. En effet, il oblige le client rflchir aux diffrents aspects de sa demande. La phase de " spcification " permet l'quipe de vrifier que la demande du client t bien comprise. Le client valide gnralement la spcification. La vrification/validation vite les retours arrire.

II. SCRUM : 1) Dfinition :

SCRUM est un terme anglais qui signifie : mle. C'est comme au rugby, tous les membres de l'quipe doivent tre souds pour atteindre un but commun. C'est une mthode agile dans l'objectif est d'amliorer la productivit. Les mthodes agiles sont des groupes de pratiques pouvant s'appliquer divers types de projets, notamment aux projets de dveloppement en informatique. Ces mthodes impliquent au maximum le client pour une relle satisfaction des ses besoins. Les valeurs des mthodes agiles sont: Les personnes et interactions priment sur les processus et les outils Logiciel fonctionnel privilgi par rapport une documentation dtaille Collaboration avec le client plutt qu'une ngociation au contrat S'adapter au changement plutt que de suivre un plan

2) Les caractristiques de SCRUM :

Itratif, li a des processus incrmentaux Approche bas sur l'quipe Fait pour dvelopper des produits/applications ncessitant une grande adaptabilit Contrler le chaos rsultat de conflits d'intrt et des diffrents besoins Augmenter la communication et maximiser la coopration Protger l'quipe des lments externes perturbateurs Un moyen d'augmenter la productivit Le principe de base de Scrum est de focaliser l'quipe sur une partie limite et matrisable des fonctionnalits raliser. Ces incrments se ralisent successivement lors de priodes de dure fixe de une quatre semaines, appeles sprints. Chaque sprint possde, un but atteindre, dfini par le directeur de produit, partir duquel sont choisies les fonctionnalits implmenter dans cet incrment. Un sprint aboutit toujours la livraison d'un produit partiel fonctionnel.

3) Les rles de la mthodologie SCRUM : a) Directeur de produit :

Le directeur de produit (Product Owner) est le reprsentant des clients et utilisateurs. C'est lui qui dfinit l'ordre dans lequel les fonctionnalits seront dveloppes et qui prend les dcisions importantes concernant l'orientation du projet.

b) quipe :
L'quipe ne comporte pas de rles prdfinis, elle est auto-gre sans aucune hirarchie interne : toutes les dcisions sont prises ensemble avec beaucoup d'efficacit et une production de qualit de faon spontane. L'quipe s'adresse directement au directeur de produit qu'il puisse ajuster les dtails d'ergonomie et d'interface par exemple.

c) ScrumMaster :
Le facilitateur / animateur (ScrumMaster), on le considre bien souvent comme le manager de projet ou le Chef d'quipe. Il est charg de protger l'quipe de tous les lments perturbateurs extrieurs l'quipe et de rsoudre ses problmes non techniques. Responsable de faire appliquer par lquipe les valeurs et les pratiques de Scrum Rsout des problmes S'assure que l'quipe est compltement fonctionnelle et productive Facilite une coopration pousse entre tous les rles et fonctions Protge l'quipe des interfrences extrieures

d) Intervenants :
Les intervenants (Stakeholders) sont les personnes qui souhaitent avoir une vue sur le projet sans rellement s'investir dedans.

4) Les processus de la mthodologie SCRUM :

a) Planification :
La runion de planification (Sprint Planning) consiste dfinir d'abord un but pour le sprint, puis choisir les items de backlog de produit qui seront raliss dans ce sprint

b) Sprint:
Scrum est un processus itratif : les itrations sont appeles des sprints et durent gnralement entre 2 et 4 semaines. Chaque sprint a un but avec une liste d'items de backlog de produit (fonctionnalits) raliser. Ces items sont dcomposs par l'quipe en tches lmentaires de quelques heures, les items de backlog de sprint.

c) Scrum quotidien :
Au quotidien, une runion appele le ScrumMeeting, de 5 min environ et debout, permet l'quipe et au ScrumMaster de faire un point d'avancement sur les tches et sur les difficults rencontres.

d) Revue du Sprint :
A la fin du sprint, tout le monde se runit 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) Rtrospective :
Cette tape est une dmarche courante en fin de projet. Pendant 15 30 min, on rflchit ce qui marche et ce qui ne marche pas. On applique ici un principe de Start / Stop / Continue.

5) Gestion des besoins :

a) Backlog de produit :
On appelle backlog de produit la liste de fonctionnalits raliser. chaque item de backlog sont associs deux attribut : une estimation en points arbitraires et une valeur client, qui est dfinie par le directeur de produit (retour sur investissement par exemple). Ce dernier dfinit dans quel ordre devront tre raliss ces items. Il peut changer cet ordre en cours de projet et mme ajouter, modifier ou supprimer des items dans le backlog.

b) Backlog de sprint :
Le backlog de sprint est le fait de dcomposer chaque item du backlog en liste de tches lmentaires estimes 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)Dfinition
Unified Process (appel UP) est un processus de dveloppement logiciel orient objet itratif et incrmental, pilot par les cas d'utilisation et centr sur l'architecture. Ce processus est gnrique (on parle de Framework), il fournit un ensemble de pratique et de concept qu'il va falloir adapter au contexte spcifique du projet afin de rpondre aux quatre questions suivante: QUI participe au projet ? QUOI, qu'est-ce qui est produit durant le projet ? COMMENT doit-il tre ralis ? QUAND est ralis chaque livrable ?

Ce processus est bas sur les composants et utilise UML (il a d'ailleurs t cre par un crateur d'UML et en constitue finalement une drivation).

2)Pilot par les cas d'utilisation :

Le but d'un logiciel est de rendre service ses utilisateurs. Afin de dfinir les fonctions que devront offrir le logiciel on dfinit le modle de cas d'utilisation bass sur lutilisation du langage UML. A partir du modle des cas dutilisation, les dveloppeurs crent une srie de modles de conception et dimplmentation ralisant les cas dutilisation. La conformit par rapport au modle 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 spcifique qui va tre pense ds le dmarrage du processus

10

3)Centr sur l'architecture :

L'architecture est dfinie selon diffrentes vues centres sur l'analyse des besoins de l'utilisateur. Sa conception est aussi tributaire de la plate forme sur laquelle devra s'excuter le systme et des briques de base rutilisable. L'architecture est dfini de manire sommaire, indpendamment des cas d'utilisation, au dpart du processus et ensuite elle va merger au fil des spcifications des cas d'utilisation jusqu' obtenir une architecture juge stable.

4)Itratif et incrmental :
Afin de limiter les risques et les cots on dcoupe le dveloppement (qui peut tre trs long) en diffrentes tapes qu'on appelle itration. Au cours de l'itration on va implmenter certains cas d'utilisation sous forme de composant (c'est dire un prototype excutable). Si on juge l'implmentation correcte on obtient un incrment et on passe l'itration suivante. Le choix des cas d'utilisation pertinents (en privilgiant d'abord les fonctions risque) implmenter aux diffrentes itrations est fait en dbut de processus. Cette manire de dcouper le dveloppement permet de dtecter et rparer une erreur sans attendre la phase de test en fin de dveloppement (comme dans les mthodes squentielles). Au chaque itration on va effectuer plusieurs activits qui vont de l'expression des besoins aux phases de conception et de test. Les itrations vont tre rptes plusieurs fois dans les diffrents cycles du processus.

5)Cycle de vie du processus

Le processus rpte une srie de cycles qui vont aboutir chaque fois une nouvelle version du systme livre au client. Chaque cycle est dcoup en quatre phases contenant chacune des itrations. Pour obtenir une version livrable au client au bout du cycle il faut dvelopper toutes les reprsentations du logiciel par le biais de diffrents modles lis.

http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process

11

Au cours des quatre phases du cycle certaines activits de l'itration seront plus sollicites que d'autres comme on peut le voir sur le graphique. La phase de cration (inception) est l'occasion de faire une tude de rentabilit du systme et permet de faire apparatre une premire ide du produit fini. On dfinit les cas d'utilisation principaux et les risque majeurs. On dfinit grossirement une architecture et on planifie l'laboration. La phase d'laboration permet de spcifier les cas d'utilisations et de dfinir une architecture de rfrence. Le chef de projet peut alors estimer les ressources et activits ncessaires. La phase de construction va permettre de transformer l'architecture en produit fini rpondant au cas d'utilisation dfinit en accord avec le client et de dfinir aussi des cas d'utilisation auquel on n'aurait pas pense prcdemment. Ce produit est considr comme stable mais il peut contenir encore des erreurs qui vont pouvoir tre dcel au cours de la phase de transition. En effet cette phase consiste a faire essayer une version bta a un groupe d'utilisateur form qui vont faire remonter les anomalies rencontrs.

6)Conclusion :
Unified Process met donc en place un cadre gnral qui peut tre adapt ou la conception et la dfinition des cas d'utilisation seffectuent de manire concomitante. Il existe beaucoup d'implmentation de ce processus qui sont bien sur toujours itrative, pilotes par les cas d'utilisation et centres sur l'architecture. La plus connu des implmentations est sans doute la mthode RUP dvelopp par Rational Software (une division d'IBM).

V. CONCLUSION:
Les processus Scrum et UP sont tous les deux itratif ce qui permet de tester petit petit les fonctionnalits du logiciel en privilgiant d'abord le noyau critique. Contrairement a une mthode squentielle comme le cycle en V ou les phases de test sont effectuer seulement la fin. L'un des inconvnients du cycle en V est qu'il dlimite compltement la phase de conception et la phase d'implmentation. Alors que c'est souvent lors de la phase de codage qu'on ralise que les spcifications initiales taient irralisables. De plus le client peut demander de nouvelles fonctionnalits au cours du dveloppement. Il est difficile d'opposer la mthode UP et la mthode SCRUM, elle peuvent tre d'ailleurs utiliser en mme temps sur un projet. La mthode UP offrant le cadre gnrale et la mthode SCRUM s'intresse plutt l'organisation du projet qu'aux aspects techniques, et implique beaucoup plus le client au cours de la ralisation.

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