Vous êtes sur la page 1sur 19

Introduction ........................................................................................................................

3
I.

MERISE ..................................................................................................................... 4
1-

Dfinition.............................................................................................................. 4

2-

Historique ............................................................................................................ 4

3-

Etapes et Niveaux ................................................................................................ 4


i-

Schma directeur ................................................................................................. 4

ii-

tude pralable ................................................................................................ 5

iii-

Etude dtaille ................................................................................................. 5

iv-

Etude technique ............................................................................................... 5

v-

Ralisation du logiciel ....................................................................................... 5

vi-

Mise en service ................................................................................................ 5

vii-

Maintenance .................................................................................................... 6

4-

II.

Les points forts et faibles de MERISE .................................................................. 6


i-

Les points forts .................................................................................................... 6

ii-

Les points faibles ............................................................................................. 6

UML ........................................................................................................................... 8
1-

Dfinition.............................................................................................................. 8

2-

Historique ............................................................................................................ 8

3-

Vues et Diagrammes ........................................................................................... 8

4-

Les points forts et faibles de UML .......................................................................10


i-

Les points forts ...................................................................................................10

ii-

Les points faibles ............................................................................................10

III.

SCRUM ..................................................................................................................11

1-

Dfinition.............................................................................................................11

2-

Historique ...........................................................................................................11

3-

Mthodologie Scrum et Cycle de dveloppement ...............................................11


i-

Rles ..................................................................................................................12

ii-

Runions .........................................................................................................12

iii-

Livrables ..........................................................................................................12

4-

IV.

Les points forts et faibles de SCRUM .................................................................13


i-

Les points forts ...................................................................................................13

ii-

Les points faibles ............................................................................................13

Comparaison MERISE/UML/SCRUM .....................................................................14

1-

Approche fonctionnelle .......................................................................................14

2-

Schma Entit/Association .................................................................................14

3-

Mthodologie ......................................................................................................15

4-

Cycle de dveloppement ....................................................................................16

5-

Les acteurs .........................................................................................................16

6-

La dmarche .......................................................................................................17

Conclusion........................................................................................................................19

Introduction
Un systme dinformation est un ensemble constitu dlments unis par des relations, ces
lments et ces relations tant munis de proprits. La conception d'un systme
d'information n'est pas vidente car il faut rflchir l'ensemble de l'organisation que l'on doit
mettre en place pour fidliser les besoins du client. Une mthode d'analyse et de conception
a donc pour objectif de permettre de formaliser les tapes prliminaires du dveloppement
d'un systme dinformation afin de rendre ce dveloppement plus fidle aux besoins du
client. Il existe plusieurs mthodes d'analyse dont MERISE la mthode la plus utilise en
France et celle UML la mthode amricaine la plus rpandue internationalement.
MERISE (Mthode dEtude et de Ralisation Informatique pour les Systmes dEntreprise)
est une mthode d'analyse et de ralisation des systmes d'information qui est labore en
plusieurs tapes: schma directeur, tude pralable, tude dtaille et la ralisation.
Alors que UML (Unified Modeling Langage) est plutt un langage de modlisation des
systmes standard (et non pas vraiment une mthode), qui utilise des diagrammes pour
reprsenter chaque aspect d'un systme cest-a-dire statique, dynamique,....en s'appuyant
sur la notion d'orient objet qui est un vritable atout pour ce langage.
Mais toutefois leur but tant darriver concevoir un systme dinformation.
Le projet danalyse et de conception des systmes dinformation est cependant gr par
diffrents types de mthodes dites mthodes Agiles.
Les mthodes Agiles sont un style de mthode de dveloppement logiciel itratif centr sur
les personnes et qui met l'accent sur la satisfaction du client travers l'intgration continue
d'un logiciel entirement fonctionnel. Elles visent la satisfaction relle du besoin du client et
non les termes d'un contrat de dveloppement. Parmi ces mthodes on trouve la toute
premire appele RAD (Rapid Applications Development) cre en 1991, Scrum cre en
1996, XP (Extreme Programming) cre en 1999, ASD (Adaptiv Software Development )
cre en 2000
De toutes les mthodologies Agile, Scrum est unique parce qu'elle introduit le concept de
"contrle empirique des processus". Ce qui signifie que Scrum utilise le progrs rel d'un
projet plutt qu'une estimation ou une prvision mal informe afin de planifier les livrables.
Scrum est un processus lger permettant de grer et de contrler le dveloppement de
produits logiciels. Mettant en uvre des pratiques itratives et incrmentales, Scrum est, en
soi, une mthode efficace. Elle peut nanmoins tre associe dautres pratiques
d'ingnierie, notamment Extreme Programming et dautres mthodes de dveloppement
logiciel itratif. Cest lune des mthodes agiles les plus employes, car elle permet
damliorer notablement la productivit tout en acclrant le retour sur investissement.
Lobjectif de cette tude est de prsenter et de comparer les mthodes danalyse et de
conception des systmes dinformation UML et MERISE ainsi que la mthode Agile de
gestion des projets de dveloppement informatique SCRUM.

I.

MERISE
1- Dfinition

Merise est une mthode d'analyse et de conception structurelle du systme d'information,


trs utilise dans les entreprises franaises. Elle est base sur la sparation des donnes et
des traitements effectuer en plusieurs modles conceptuels et physiques. Son but est juste
darriver concevoir un systme d'information.

2- Historique
Au dbut des annes 70, les bases de donnes commencent se dvelopper. Aux EtatsUnis, Codd propose le formalisme relationnel.
En 1973 le Professeur Jean-Louis Le Moigne invente la notion de systme d'information.
En 1974, le CETE d'Aix en Provence et l'Universit d'Aix-Marseille s'associent pour
prsenter un projet de recherche auprs de l'INRIA intitul : Mthode, modles et outils
pour la conception de la base de donnes d'un systme d'information . L'quipe, place
sous la direction scientifique du Professeur Jean-Louis Le Moigne est pilote par Hubert
Tardieu.
Ds 1977, la Mission informatique du Ministre de l'Industrie souhaite tablir une mthode
nationale dans le domaine de la conception des systmes d'information.
Merise voit officiellement le jour en 1979, sous la forme d'un premier fascicule publi par
Ministre de l'Industrie: Mthode de dfinition d'un systme d'information . Le nom de
Merise a t trouv comme la mtaphore du merisier qui doit tre greff pour porter des
fruits.
Le projet Merise se poursuit donc jusqu'en dbut 1981 avec la publication de plusieurs
documents de rfrence sur la mthode Merise.
A partir de 1981, certaines grandes SSII (socit de services en ingnierie informatique) qui
avaient accompagn Merise entament la diffusion de la mthode auprs des grandes
entreprises et de l'Administration.
Et en 1983, est publi le premier ouvrage sur Merise, ouvrage qui restera la rfrence. La
mthode Merise Tome I : Principes et outils de H. Tardieu, A. Rochfeld et R. Coletti, qui
sera suivi en 85 par : La mthode Merise Tome II : Dmarches et pratiques de H.
Tardieu, A. Rochfeld, R. Coletti, G. Panet et G. Vahee.
Ds lors, Merise connat un engouement. De nombreux ouvrages paraissent. Merise est
dsormais enseigne dans les formations universitaires.
La fin des annes 80 dnombrera plus de 15 outils franais sur Merise. Quasiment toute
grande SSII propose le sien.

3- Etapes et Niveaux
Merise dfinit une dmarche danalyse par tapes ralises simultanment :
i-

Schma directeur

Un projet doit s'inscrire dans les objectifs gnraux de l'entreprise car il mobilise
gnralement du personnel pendant une grande priode de temps. C'est la raison pour
laquelle il est ncessaire pour une organisation, avant mme de se lancer dans des projets,
de dfinir ses intentions moyen terme (un trois ans). Ce sont ces plans dactions
moyen terme qui sont appels schma directeur.

ii-

tude pralable

Cette tape prliminaire est primordiale pour lensemble du projet. Il est prvu quelle soit
confie celui qui est en relation commerciale avec le client et qui aura la charge de la
coordination des diffrents intervenants. Le contact commercial et lauditeur peuvent
nanmoins tre deux entits spares. Ltude pralable a pour but principal de planifier
lopration et de prparer les interventions suivantes. Les ventuelles difficults techniques
devront tre aussi intgres.
iii-

Etude dtaille

L'tude dtaille vise l'exhaustivit de la description de la solution. Les spcifications


dtailles sont la traduction prcise des besoins fonctionnels, techniques et organisationnels
exprims par la matrise d'ouvrage ou les utilisateurs, en termes de :

traitements proposer aux utilisateurs de l'application,


donnes grer par l'application,
interface utilisateurs : crans, tats, enchanement d'crans,
contraintes de scurit et techniques.

Une fois le dossier d'tude dtaille valid par la matrise d'ouvrage, il constitue le cahier des
charges pour la production ou la maintenance d'une application. En cas de modifications ou
d'volutions du cahier des charges durant la phase d'laboration de l'tude dtaille, il est
important de veiller ce qu'il soit maintenu jour.
iv-

Etude technique

L'tude technique est la phase d'adaptation de la conception l'architecture technique


retenue, tout en dcrivant et documentant le fonctionnement de chaque unit du logiciel. Son
livrable est un dossier dtude technique.
L'laboration d'un dossier d'tude technique dbute lorsque la conception a t valide par
le comit de pilotage (dossier d'tude dtaille, plan de conduite du changement, protocole
de rception externe sur sites pilotes, s'il y a lieu). Les objectifs d'un dossier d'tude
technique sont de :

v-

Fournir une description complte et dtaille du logiciel dans l'environnement


technique cible de l'application : dcoupage en composants logiciels, structures des
fichiers, des bases de donnes, des interfaces

S'assurer des performances prvisibles et de la scurit de l'application.


Ralisation du logiciel

Il s'agit de la phase oprationnelle de cration de du systme dinformation. Elle est mene


par la matrise d'uvre, en relation avec la matrise d'ouvrage. Cette phase commence par
la rception du cahier des charges fonctionnel et technique et se clture par lachvement du
systme dinformation.
viMise en service
Il s'agit de la mise en production de l'ouvrage, c'est--dire s'assurer que l'ouvrage est
conforme aux attentes des utilisateurs et faire en sorte que son " installation " et son
utilisation se droule correctement. Dans la mesure o la matrise d'uvre connat le produit
qu'elle a mis au point, il lui revient de l'installer. Cette phase aboutit un manuel utilisateur.

vii-

Maintenance

Elle prend 3 formes qui sont :


La maintenance corrective permet de corriger les erreurs qui nont pas t dtectes lors des
prcdentes phases de tests.
La maintenance adaptative doit soccuper de faire voluer et dadapter le logiciel
lapparition de nouvelles contraintes.
La maintenance perfective a pour objectif loptimisation des performances du logiciel.
Merise propose ensuite plusieurs niveaux dabstraction afin de dcrire progressivement la
complexit :
Niveau conceptuel. A ce niveau 2 modles sont dcrits :
Le modle conceptuel de donnes ou MCD est un schma qui reprsente la structure du
systme dinformation, du point de vue des donnes, c'est--dire quil dcrit les objets, les
proprits et les associations entre les objets.
Le Modle conceptuel des traitements ou MCT permet de traiter la dynamique du systme
d'information, c'est--dire les oprations qui sont ralises en fonction d'vnements.
(exemple : Inscription dun tudiant).
Niveau logique et organisationnel. A ce niveau aussi 2 modles sont dcrits :
Le modle logique de donnes ou MLD volue le plus souvent vers la description dune
structure relationnelle et prcise en outre les cls daccs aux occurrences dun objet, les
relations, les oprateurs (union, jointure) et introduit la notion de table. A ce stade, il est
possible de connatre la liste exhaustive des tables qui seront crer dans une base de
donnes relationnelle.
Le Modle Logique des Traitements ou MLT prcise les acteurs et les moyens qui seront mis
en uvre.
Niveau physique. A ce niveau aussi 2 modles sont dcrits :
Le modle physique des donnes ou MPD dcrit limplmentation physique du modle
(structure de la base de donnes ou des fichiers de donnes).
le Modle Oprationnel des Traitements ou MOT permet de spcifier les fonctions telles
qu'elles seront ensuite ralises par le programmeur.

4- Les points forts et faibles de MERISE


i-

Les points forts

Merise, mthode la plus utilise en France dans les domaines de gestion, s'appuie sur une
approche systmique. Donc elle permet une apprhension globale et rapide du systme
dinformation concevoir. Elle est trs adapte un contexte de cration d'application et
ses concepts sont peu nombreux et simples pour ltude du systme et elle est assez
indpendante vis vis de la technologie. Nanmoins, certains points faibles ont t nots
sur cette mthode lors de lanalyse et de la conception des systmes dinformation.
ii-

Les points faibles

Elle ne s'occupe pas de l'interface utilisateur et nest pas adapte un problme de


maintenance ou de seconde informatisation. Elle ne permet pas rellement une validation

rapide de la part des utilisateurs et par la suite il est trs difficile de valider les traitements par
rapport aux donnes et cela au niveau conceptuel ou organisationnel.

II.

UML
1- Dfinition

Unified Modeling Langage ou encore UML est langage d'analyse et de conception orient
objet dfini par l'OMG (Object Management Group) et aussi considr comme une mthode
permettant la mise en schma syntax et structur de la relation entre divers systmes
(client-serveur, par exemple) dans un cahier des charges et cela permet de dcouper les
diffrentes parties coder.

2- Historique
UML est n (1997) de la fusion de 3 langages : OMT : par Rumbaugh (Rational Software),
OOD : par Booch (General Electric) et OOSE : par Jacobson (Ericsson).
OMT : Object Modeling Techniques a des vues statiques c'est--dire ne modifie pas lobjet,
des vues dynamiques c'est--dire peut modifier lobjet et des vues fonctionnelles.
OOD : Oriented Object Design a des vues logiques c'est--dire base sur de la
dcomposition logicielle et des vues physiques base sur de la dcomposition matrielle.
OOSE : Oriented Object Software Engineering a des vues bases sur le cycle vie logiciel
(Analyse, Conception, Ralisation/Implmentation, Test/Maintenance).

3- Vues et Diagrammes
UML est un langage cadr sur les analyses dobjets. Il permet de reprsenter un systme
selon diffrentes vues :

Vue des cas dutilisation constitue le lien et motive la cration de tous les
diagrammes d'architecture et correspond aux besoins attendus par chaque acteur
(c'est le QUOI et le QUI).
Vue logique constitue la principale description architecturale d'un systme
informatique et explique comment peuvent tre satisfaits les besoins des acteurs
(c'est le COMMENT).
Vue d'implmentation dfinit les dpendances entre les modules.
Vue des processus met en uvre les notions de tches concurrentes, stimuli,
contrle, synchronisation, etc.
Vue de dploiement dcrit la position gographique et l'architecture physique de
chaque lment du systme (c'est le O).

UML comporte diffrents diagrammes dpendants et hirarchiques. Ils se compltent de


faon permettre la modlisation d'un projet tout au long de son cycle de vie :

Diagrammes statiques. Il sagit de :


o

Le diagramme de classes est utilis pour reprsenter l'organisation des


donnes dans les Systmes d'Information. Mais il ne peut pas mettre en
vidence les relations existant un instant dtermin de la vie du systme,
entre les diverses instances des classes composant le systme. Il ne peut
montrer quune instance particulire (ayant des valeurs dattributs bien
dfinies) est ncessaire dans un cas dutilisation particulier. Cest l le rle du
Diagramme dobjets

o
o
o
o

Diagrammes comportementaux. Il sagit de :


o

Le diagramme de composants montre les dpendances entre les composants


de lapplication. Un composant peut tre un excutable, un code source,
fichier, bases de donnes etc.
Le diagramme de dploiement est une vue statique qui montre la disposition
physique des matriels qui composent le systme et la rpartition des
composants sur ces matriels.
Le diagramme des paquetages permet de mettre en vidence les
dpendances entre paquetages. Un paquetage tant un conteneur logique
permettant de regrouper et d'organiser les lments dans le modle UML.
Le diagramme de structure composite est un nouveau diagramme introduit
par le standard UML2.0. il joue le mme rle quun diagramme de classes
mais permet de dcrire les relations entre composants d'une classe.

Le diagramme de cas d'utilisation reprsente les cas d'utilisation, les acteurs


et les relations entre les cas d'utilisation et les acteurs, dcrit sous la forme
d'actions et de ractions, le comportement d'un systme du point de vue d'un
utilisateur et permet de dfinir les limites du systme et les relations entre un
systme et l'environnement. Et un cas d'utilisation est une manire spcifique
d'utiliser un systme. Il est l'image d'une fonctionnalit du systme,
dclenche en rponse la stimulation d'un acteur externe.
Le diagramme tats-transitions dcrit sous forme de machine tats finis le
comportement dynamique des objets dans le temps en modlisant les cycles
de vie des objets de chaque classe.
Le diagramme dactivit est utilis pour modliser un workflow (flux
d'informations au sein de compagnie) dans un cas dutilisation ou entre
plusieurs cas dutilisations et pour spcifier une opration (dcrire la logique
dune opration).

Diagrammes dinteraction ou dynamiques. Il sagit de :


o

Le diagramme de collaboration montre des interactions entre objets


(instances de classes et acteurs). Ils permettent de reprsenter le contexte
d'une interaction, car on peut y prciser les tats des objets qui interagissent.
o Le diagramme de squences permet de reprsenter des collaborations entre
objets selon un point de vue temporel, on y met l'accent sur la chronologie
des envois de messages et lexpression des interactions. Contrairement au
diagramme de collaboration, on n'y dcrit pas le contexte ou l'tat des objets,
la reprsentation se concentre sur l'expression des interactions.
o Le diagramme de communication est un nouveau diagramme introduit par le
standard UML2.0. Cest une reprsentation simplifie d'un diagramme de
squence qui met laccent sur lorganisation structurelle des objets qui
envoient et reoivent des messages.
o Le diagramme dinteraction permet dtablir un lien entre les diagrammes de
cas dutilisation et les diagrammes de classes : ils montrent comment des
objets (i.e. des instances de classes) communiquent pour raliser une
certaine fonctionnalit. Ils apportent ainsi un aspect dynamique la
modlisation du systme.
o Le diagramme global dinteraction est aussi un nouveau diagramme introduit
par le standard UML2.0 qui permet de dcrire les enchanements possibles
entre les scnarios pralablement identifis sous forme de diagrammes de
squences. Cest une variante du diagramme dactivit.

Le diagramme de temps est aussi un nouveau diagramme introduit par le


standard UML2.0 qui permet de dcrire les variations d'une donne au cours
du temps.

4- Les points forts et faibles de UML


i-

Les points forts

ii-

UML est un langage formel et normalis


o gain de prcision
o gage de stabilit
o encourage l'utilisation d'outils
UML est un support de communication performant
o Il cadre l'analyse.
o Il facilite la comprhension de reprsentations abstraites complexes.
o Son caractre polyvalent et sa souplesse en font un langage universel.
Les points faibles

La mise en pratique d'UML ncessite un apprentissage et passe par une priode


d'adaptation. UML nest pas l'origine des concepts objets, mais en constitue une tape
majeure, car il unifie les diffrentes approches et en donne une dfinition plus formelle.
Le processus (non couvert par UML) est une autre cl de la russite d'un projet. Or,
l'intgration d'UML dans un processus n'est pas triviale et amliorer un processus est une
tche complexe et longue. Les auteurs d'UML sont tout fait conscients de l'importance du
processus, mais l'acceptabilit industrielle de la modlisation objet passe d'abord par la
disponibilit d'un langage d'analyse objet performant et standard.

10

III.

SCRUM
1- Dfinition

Scrum est une mthode agile pour la gestion de projets base sur des multiples petites
quipes travaillant intensment et indpendamment. Scrum maximise sa productivit facile
adapter son cycle de dveloppement et ncessite la saisie et le suivi d'une liste de
fonctionnalits pour l'ensemble du projet et d'une liste de tches pour chaque itration. Elle
demande galement la production de tableaux de bords (c'est--dire rapports graphiques).
Bien sr, un simple fichier Excel peut suffire, mais l'accs partag un fichier Excel par toute
l'quipe, en criture et en consultation, est toujours problmatique.

2- Historique
Le terme Scrum est emprunt au rugby et signifie mle. Ce processus s'articule en effet
autour d'une quipe soude, qui cherche atteindre un but, comme c'est le cas en rugby
pour avancer avec le ballon pendant une mle.
En 1986, Hirotaka Takeuchi et Ikujiro Nonaka dcrivent une nouvelle approche holistique qui
augmenterait la vitesse et la flexibilit dans le dveloppement commercial de nouveaux
produits. Dans celle-ci les phases se chevauchent fortement et l'ensemble du processus est
ralis par une quipe aux comptences croises travers diffrentes phases. Ils ont
compar cette nouvelle approche au rugby, o l'quipe essaye d'avancer unie, en faisant
circuler la balle.
En 1991, DeGrace et Stahl font rfrence cette approche comme Scrum (mle, en
anglais), un terme de rugby mentionn dans l'article de Takeuchi et Nonaka. Dans le dbut
des annes 1990, Ken Schwaber a utilis une approche qui a conduit Scrum au sein de
son entreprise. En mme temps, Jeff Sutherland, John Scumniotales et Jeff McKenna
dveloppent une approche similaire Easel Corporation et sont les premiers appeler cela.
En 1995, Sutherland et Schwaber ont prsent conjointement un document dcrivant Scrum
l'OOPSLA de 1995 Austin. Schwaber et Sutherland ont collabor au cours des annes
suivantes pour fusionner les publications, leurs expriences et les meilleures pratiques du
secteur en ce qui est maintenant connu comme Scrum. En 2001, Schwaber fait quipe avec
Mike Beedle pour dcrire la mthode dans le livre "Agile Software Development With
Scrum". En France, le premier livre franais entirement consacr Scrum est publi en
fvrier 2010 : "SCRUM : Le guide pratique de la mthode agile la plus populaire".

3- Mthodologie Scrum et Cycle de dveloppement


Scrum utilise le progrs rel d'un projet et les projets sont diviss en parties succinctes de
travail, appeles "sprints", qui sont gnralement d'une dure de 1 4 semaines. la fin de
chaque sprint, les membres de l'quipe ainsi que les autres gens impliqus se rencontrent
afin d'valuer les progrs du projet et planifier les prochaines tapes. Ceci permet d'ajuster
ou rorienter un projet selon l'volution du travail et non des spculations ou des prdictions.
Chaque Sprint possde un but atteindre, dfini par le Directeur de produit, partir duquel
sont choisies les fonctionnalits implmenter dans ce sprint, et dure au plus quatre
semaines.
Un sprint aboutit toujours sur la livraison d'un produit partiel fonctionnel. Pendant ce temps,
le Scrum Master a la charge de rduire au maximum les perturbations extrieures et de
rsoudre les problmes non techniques de l'quipe.
Pendant un Sprint, des runions quotidiennes de moins de 15 minutes (appeles Scrum)

11

permettent toute l'quipe de faire le point sur le travail accompli par chacun depuis la
dernire runion Scrum, les obstacles rencontrs, et le travail prvu d'ici la prochaine
runion.
La mthodologie Scrum Agile apporte des rles, responsabilits et runions qui assurent le
bon droulement d'un projet.
i-

Rles

ii-

Le propritaire: Communique la vision du produit aux membres de l'quipe.


Reprsente les intrts du client via les besoins et la priorisation de ceux-ci. Possde
la plus haute autorit des 3 rles et aussi le plus de responsabilit. Lorsqu'un projet
tourne mal, c'est vers lui que l'on pointe.
Le Scrum Master: Lien entre l'quipe et le propritaire. Ne gre pas l'quipe mais fait
tout en sorte pour enlever les recueilles sur la route de l'quipe de dveloppement
afin d'atteindre les buts du sprint. Aide l'quipe demeurer productive et montre
l'avancement au propritaire. Indique aussi au propritaire les faons d'optimiser le
retour sur investissement pour l'quipe.
Les membres de l'quipe: Responsables de complter le travail. L'quipe idale
consiste de 7 membres provenant de disciplines diffrentes et plus ou moins 2 autre
individus. Pour un projet d'application une quipe typique sera compose d'un
amalgame d'ingnieurs, architectes, programmeurs, analystes, experts AQ, testeurs
et designers dUI. chaque sprint, l'quipe est responsable de dterminer comment
est accomplira le travail. Ceci offre une grande autonomie mais aussi la
responsabilit d'atteindre ces buts pour le sprint.
Runions

iii-

Runion de planification du sprint: Durant cette runion l'quipe et le propritaire


discutent de priorisation et des items en attente de dveloppement. Les membres de
l'quipe s'entendent sur le travail faire et se cre une liste des tches effectuer
durant le sprint.
Scrum journalier: chaque jour durant le sprint, l'quipe se runie avec le Scrum
Master et le propritaire. Cette runion est limite une dure de 15 minutes. Durant
cette runion, l'quipe discute de ce qui t fait la journe prcdente, ce qui fera
aujourd'hui et ce qui pourrait les empcher d'avancer. Les Scrums journalier
permettent l'quipe de se synchroniser.
Revue du sprint ( la fin du sprint): Durant cette runion l'quipe discute des ajouts
faits dans le projet durant le sprint. Le but de cette runion est de colliger les
commentaires du propritaire et toute autre personne implique dans l'valuation ou
la revue du produit. Ces commentaires pourraient mener la modification de
nouvelles fonctionnalits fraichement ajouter. Mais il se pourrait que de nouveaux
items soient ajouts/modifis la liste des tches en attentes.
Rtrospective du sprint ( la fin du sprint): Tous y participent. Permet de revoir le
droulement du sprint et d'apporter des amliorations pour les prochains.
Livrables

Carnet de commandes du produit: une liste constamment priorise d'items.


Carnet de commandes du sprint: une liste des items les plus hautement prioriss du
carnet de commandes du produit.

12

4- Les points forts et faibles de SCRUM


L'avantage des Mthodes Agiles rside avant tout dans le fait qu'elles mettent en avant une
dmarche plus pragmatique que les dmarches traditionnelles, en impliquant au maximum le
client, et en privilgiant la ralisation d'un produit vritablement oprationnel, et tout cela
moindre cot.
Rpondre au changement plutt que suivre un plan prtabli, prendre en compte le fait que
les conditions et les objectifs d'une entreprise puissent voluer avec le temps, mme
pendant que se droule le projet, correspond tout fait la vision de l'innovation, inhrente
au dveloppement des Mthodes Agiles.
Un principe fort en Scrum est la participation active du client pour dfinir les priorits dans
les fonctionnalits du logiciel, et pour choisir celles qui seront ralises dans chaque sprint. Il
peut tout moment complter ou modifier la liste des fonctionnalits raliser, mais jamais
celles qui sont en cours de ralisation pendant un sprint.
i-

Les points forts

ii-

Il est entirement dvelopp et test pour de courtes itrations.


Ses processus de dveloppement sont trs simples.
Ses rgles sont dfinies clairement.
Augmentation de productivit.
Organisation personnelle.
Chaque quipe a son lot de responsabilit.
Amlioration de la communication.
Combinaison possible avec XP.
Les points faibles

Peu, voire pas, de documentation crite. Le gros problme rside bien souvent dans
l'aspect Documentation du projet. Comme la mthode privilgie le fonctionnel, on se
retrouve rapidement avec des projets non-documents.
La mise en uvre du dveloppement n'est pas prcise, seule compte la gestion
des ressources humaines.
L'quipe ne se prte pas au SCRUM. Il est clair que si l'quipe ne prend pas le temps
de remplir correctement les indicateurs comme le SCRUM Board et les Burndow
Chart, le suivi n'est pas correctement assur.
D'autres parts on remarque bien souvent que dans la gestion du SCRUM les
manager sont tents de passer outre les responsabilits hirarchiques pour aller
remonter le problme au sommet. On constate bien souvent ce problme dans des
quipes ou un dveloppeur requiert directement le client plutt que son propre
SCRUM master, ou Directeur de Produit.

13

IV.

Comparaison MERISE/UML/SCRUM

1- Approche fonctionnelle
Merise propose une approche descendante o le systme rel est dcompos en activits,
elles-mmes dclines en fonctions.
Les fonctions sont composes de rgles de gestion, elles-mmes regroupes en oprations.
Ces rgles de gestion au niveau conceptuel gnrent des modules dcomposs en modules
plus simples et ainsi de suite jusqu' obtenir des modules lmentaires...
Les limites d'une telle approche rsident dans le fait que les modules sont difficilement
extensibles et exploitables pour de nouveaux systmes.
Dans UML les fonctions cdent la place aux cas d'utilisation qui permettent de situer les
besoins de l'utilisateur dans le contexte rel. A chaque scnario correspond des diagrammes
d'interaction entre les objets du systme et non pas un diagramme de fonction...
Scrum utilise une approche fonctionnelle pour rcolter les besoins des utilisateurs. L'objectif
est d'tablir une liste de fonctionnalits raliser, que l'on appelle backlog de produit (NDT :
Le terme backlog peut tre traduit par cahier, liste ou carnet de commandes, qui ne collent
pas bien avec l'esprit du terme anglais qui voque aussi une rserve, un retard accumul ;
aussi ce terme a t gard tel quel).
chaque item de backlog sont associs deux attributs : une estimation en points arbitraires
(voir Estimation) 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.
La somme des points des items du backlog de produit constitue le reste faire total du
projet. Cela permet de produire un release burndown chart, qui montre les points restant
raliser au fur et mesure des sprints.

2- Schma Entit/Association
Le schma entit/association est un diagramme pour des descriptions de haut niveau de
modles conceptuels de donnes ou MCD.
L'entit est une association d'objets traduisant un rseau de relations de dpendance.
Et une association est dfinie comme un lien smantique de mme nature reliant les
occurrences de plusieurs entits donc elle dfinit des liens entre des types d'entit. Les
associations sont caractrises par des cardinalits. Le choix des cardinalits est essentiel
et est aussi parfois discutable, et constitue donc l'aspect le plus dlicat de la modlisation.
Les cardinalits sont notes par deux chiffres. Le chiffre de droite est la cardinalit
maximale, et celui de gauche est la cardinalit minimale. Mais cette dernire est moins
importante que la cardinalits maximales.
La notation * est quivalente 0..* .
La notation 1 est quivalente 1..1 .
Dans la notation UML, on indique les cardinalits aux deux extrmits d'un lien d'association
entre deux entits E1 et E2. Les cardinalits pour E1 sont places l'extrmit du lien allant
dE1 vers E2 et les cardinalits pour E2 sont l'extrmit du lien allant dE1 vers E2. Alors
que dans la notation Merise cest le contraire. Les cardinalits pour E1 sont l'extrmit du

14

lien allant dE1 vers E2 et les cardinalits pour E2 sont places l'extrmit du lien allant
dE1 vers E2.
Notation UML
1

inscrits

Ecole

Ecole

1..
*

Elves

Notation Merise
1..*

inscrits

Elves

Dans les 2 cas, les schmas ci-dessus veulent dire que dans une Ecole sont inscrits un
plusieurs (1..*) Elves mais les Elves sont inscrits dans une et une seule Ecole (1..1 ou 1).

3- Mthodologie
Merise est une mthode d'analyse de systme d'information qui est labore en plusieurs
tapes.
Alors que UML est un mtalangage (et pas une mthode proprement parler) de description
d'application se basant sur l'hypothse que le systme dinformation dvelopp est orient
objet.
Et Scrum est un processus agile permettant de grer et de contrler le travail de
dveloppement et peut tre utilis pour intgrer des pratiques de gnie logiciel existantes.
Ils travaillent tous trois sur des concepts diffrents. Merise travaille sur un concept relationnel
tandis quUML travaille sur un concept objet. Et Scrum travaille sur le concept de la qualit
de l'environnement de travail de l'quipe. Cela inclut :
Pas de changements imposs pendant un sprint.
Toute l'quipe dans une mme pice.
Un bon outil de suivi du projet
Prvenir des interventions extrieures (tlphone, irruption dans la pice, etc)
Un tableau blanc et/ou en lige
Merise = Franco-franais utilise pour le relationnel
UML = International et mthode amricaine utilise pour la modlisation objet.
Scrum = Mthode agile pour la gestion des projets.
En plus UML est beaucoup plus vaste que son modle de donnes. Donc pour lanalyse et la
conception des systmes dinformation, Scrum est une mthode utiliser pour grer le projet
tandis que Merise et UML sont des mthodes utiliser pour analyser et concevoir le projet.
La mthode Merise ressemble la mthode UML pour la phase de modlisation de la base
de donnes. La diffrence principale est que Merise est une mthode d'analyse, et UML un
langage de modlisation de donnes. Par la conception, Scrum aide lquipe dtecter et
liminer les obstacles entravant le dveloppement et la livraison des produits et amliore la
communication. Le dveloppement de produits logiciels fait natre un chaos considrable qui
se traduit par une grande incertitude et des comportements imprvisibles. Donc Scrum
optimise la coopration et permet de contrler le chaos drivant dintrts et de besoins
divergents.

15

4- Cycle de dveloppement
La diffrence de MERISE, UML ne propose pas de cycle prcis : les organisations sont
libres de choisir le cycle qui leur convient.
UML fonctionne sur un principe ditrations qui ne soppose pas aux phases dfinies dans
MERISE. MERISE dcoupe plus au travers de ses phases lanalyse mtier et larchitecture
logicielle. Dans UML, larchitecture logicielle a une place prpondrante et est intgre
trs en amont dans llaboration du systme dinformation.
Dans UML, lavancement du projet est mesur par le nombre de cas dutilisation, de
classes... rellement implantes et non par la documentation produite ce qui est le cas dans
Merise. Les itrations servent en outre rpartir lintgration et les tests tout au long du
processus dlaboration du systme dinformation.
Scrum repose sur une thorie moderne du contrle des processus et permet dlaborer de
faon systmatique les meilleurs logiciels possibles partir des ressources disponibles, un
niveau de qualit acceptable et dans le respect des dlais de livraison. Le cycle de vie
Scrum sarticule en brves itrations de dveloppement appeles Sprints . Scrum
synchronise troitement les exigences logicielles avec toute une srie de prototypes itratifs.
Et ses projets sont contrls par la mise en place, lactualisation et le suivi de paramtres de
contrle essentiels, qui forment lossature du processus Scrum.

5- Les acteurs
Les acteurs dun systme sont les entits externes ce systme qui interagissent (saisie de
donnes, rception dinformation, ) avec lui. Les acteurs sont donc lextrieur du
systme et dialoguent avec lui. Ces acteurs permettent de cerner linterface que le systme
va devoir offrir son environnement. Oublier des acteurs ou en identifier de faux conduit
donc ncessairement se tromper sur linterface et donc la dfinition du systme produire.
Trois acteurs sont essentiels un projet SCRUM :

Le product owner reprsente le client, disponible pour orienter l'quipe, il ordonne le


travail en mettant jour le product backlog.
Le Scrum master protge de toutes perturbations la dynamique de l'quipe en
solutionnant ses problmes non techniques.
L'quipe s'autogre sans hirarchie interne

Il faut faire attention ne pas confondre acteurs et utilisateurs (utilisateur avec le sens de la
personne physique qui va appuyer sur un bouton) dun systme. Dune part parce que les
acteurs inclus les utilisateurs humains mais aussi les autres systmes informatiques ou
hardware qui vont communiquer avec le systme. Dautre part parce quun acteur englobe
tout une classe dutilisateur. Ainsi, plusieurs utilisateurs peuvent avoir le mme rle, et donc
correspondre un mme acteur, et une mme personne physique peut jouer des rles
diffrents vis--vis du systme, et donc correspondre plusieurs acteurs.
En UML on distingue 2 types dacteurs :
Acteurs principaux : Ceux qui vont raliser le cas dutilisation (la relation avec le cas
dutilisation est illustre par le trait liant le cas dutilisation et lacteur dans un
diagramme de cas dutilisation).
Acteurs secondaires : Ceux qui ne font que recevoir des informations lissue de la
ralisation du cas dutilisation.
Ils sont reprsents dans le diagramme des cas dutilisation.
En Merise on distingue aussi 2 types dacteurs :

16

Acteurs externes : Elments externes avec lesquels le systme change des flux
dinformation. Ex : clients, fournisseurs...
Acteurs internes : Acteurs faisant partie du systme dinformation tudi. Ex : guichet,
service informatique...
Ils sont reprsents dans le MCC (Modle Conceptuel de Communication) et dans le MCT
(Modle Conceptuel de Traitement).

6- La dmarche
UML est un mtalangage et n'est pas une mthode donc elle ne prsente aucune dmarche.
Cependant, les auteurs dUML proposent dutiliser une dmarche pour favoriser la russite
du projet :
Une dmarche itrative et incrmentale. Pour modliser (comprendre et reprsenter)
un systme complexe, il vaut mieux s'y prendre en plusieurs fois, en affinant son
analyse par tapes.
Une dmarche guide par les besoins des utilisateurs du systme. Avec UML, ce
sont les utilisateurs qui guident la dfinition des modles :
o Le primtre du systme modliser est dfini par les besoins des utilisateurs
(les utilisateurs dfinissent ce que doit tre le systme).
o Le but du systme modliser est de rpondre aux besoins de ses
utilisateurs (les utilisateurs sont les clients du systme).
Les besoins des utilisateurs sont indispensables tout au long de la dmarche itrative
et incrmentale :
o A chaque itration de la phase d'analyse, on clarifie, affine et valide les
besoins des utilisateurs.
o A chaque itration de la phase de conception et de ralisation, on veille la
prise en compte des besoins des utilisateurs.
o A chaque itration de la phase de test, on vrifie que les besoins des
utilisateurs sont satisfaits.
Une dmarche centre sur larchitecture. Une architecture adapte est la cl de vote
du succs d'un dveloppement. Car elle dcrit des choix stratgiques qui dterminent
en grande partie les qualits du logiciel (adaptabilit, performances, fiabilit...).
Contrairement UML, Merise qui en propose une. La dmarche de dveloppement dun
systme dinformation de Merise doit tre conduite suivant trois axes appels cycles dont le
degr de prise en compte par les diffrentes mthodes oriente le choix de lune dentre elles
en fonction des objectifs de ltude :
Cycle de vie. Il se situe sur une chelle de temps qui nous mne du point de dpart
lexploitation du systme, en passant par sa cration, sa maturit et sa maintenance.
Cycle de dcision. Il reprsente lensemble des choix qui doivent tre fait durant le
droulement du cycle de vie.
Cycle dabstraction. Cest le dcoupage en ensembles homognes de
proccupations :
o Le niveau conceptuel qui dtermine les choix de gestion.
o Le niveau organisationnel qui dtermine les choix dorganisation.
o Le niveau technique qui dtermine les contraintes techniques.
La ralisation dun systme dinformation est conduite au travers dun projet dcompos en
tapes sappuyant sur les trois cycles dfinis prcdemment :
Le schma directeur.
o Dfinition des domaines dtudes
o planification du dveloppement de chaque domaine
o valuation des moyens en personnel et matriel

17

o mise en uvre de la mthode.


Ltude pralable. Dtermination du systme de ltude afin de donner aux
responsables les moyens de prendre des dcisions pertinentes sur la globalit du
projet.
Ltude dtaille. Dtermination des spcifications fonctionnelles.
Ralisation.
o Etude technique
o Production des programmes
o Rdaction des consignes dutilisation.
Maintenance.
o Corrections
o Adaptation aux volutions de lentreprise.

Les trois premires tapes correspondent la partie conception du cycle de vie et les
suivantes concernent la ralisation du systme et son lancement. La mthodologie Merise
sintresse plus particulirement cette partie conception.
En Scrum, les projets sont diviss en parties succinctes de travail, appeles "sprints", qui
sont gnralement d'une dure de 1 4 semaines. la fin de chaque sprint, les membres de
l'quipe ainsi que les autres gens impliqus se rencontrent afin d'valuer les progrs du
projet et planifier les prochaines tapes. Ceci permet d'ajuster ou rorienter un projet selon
l'volution du travail et non des spculations ou des prdictions.
Ci-dessous les tapes suivre durant un Scrum :
Cration d'un carnet de commandes du produit: Le propritaire et l'quipe se
rencontre afin de prioriser les items du carnet de commandes du produit. Le
propritaire doit tre en mesure de formuler sa vision du produit.
Runion de planification de sprint.
Cration de la planification du sprint. Sparation et distribution des items du carnet
entre les membres de l'quipe selon leur disponibilit.
Dbut du sprint pour une dure de 1 4 semaines. Aucune autre tche ne peut tre
ajoute.
Scrum journalier.
Revue du sprint.
Redmarrage du cycle.

18

Conclusion
En dfinitive, nous avons vu comment modliser un dveloppement de systemes
dinformation laide des mthodes telles que Merise et UML bien quUML est plus un
langage quune mthode. Merise et UML ont des caractristiques voisines au niveau de la
modlisation des bases de donnes mais galement des points de divergence.
En effet, la mthode MERISE ncessite une dmarche par tape qui favorise la qualit de
chaque modle avec ses diffrents niveaux de validations. Alors que le langage UML
nimpose pas de mthode de travail particulire. Ces deux mthodes peuvent tre intgres
n'importe quel processus de dveloppement logiciel dont Scrum.
Scrum, processus de dveloppement logiciel, introduit dont des rgles pour suivre un
processus itratif empirique permettant d'obtenir un produit trs proche de besoins qui
voluent et ainsi de maximiser la valeur pour les clients. Mais Scrum est un processus idal
pour de petites quipes et tout le monde dans lquipe surveille par un Scrum Master se
doit non seulement dinteragir avec le projet mais aussi dtre rellement investie dans sa
bonne ralisation.

19