Module:

« Méthodologies d’Analyse des

Systèmes d’Information (MASI) »

Responsable du CM/TD/TP : Dr Khalifa GAYE

Contact: [email protected]

1
 Méthodologies d’Analyse des Systèmes d’Information (MASI)

Objectifs
Objectif général
— Maîtriser l’analyse et la conception d’applications par une
approche systémique ou orientée objet.

Objectifs spécifiques :
A l’issue de ce cours l’étudiant sera capable
— de décrire les différentes étapes de réalisation d’un système
informatique
— de concevoir les modèles qui seront produits dans chaque
étape
— développer des systèmes logiciels suivant une approche
orientée objet.

2
Méthodologies d’Analyse des Systèmes d’Information
(MASI)

Contenu

— Approche systémique pour les systèmes d’information.

— Approche orientée objet pour les systèmes d’information.
— Les méthodes séquentielles (MERISE, SADT, etc.)
— Les méthodes itératives et incrémentales (UP, RUP, 2TUP,
MACAO)
— Les méthodes agiles (XP, Scrum, RAD, etc.)
— Etude détaillée de la méthode (2TUP)
— Application de la méthode 2TUP à un cas pratique de
réalisation d’un produit logiciel
3
 Modalités de l'évaluation
— Etude de cas.

4
Références Bibliographiques
— « Merise Guide pratique modélisation des données
et des traitements, langage SQL » de Jean Luc
BAPTISTE
— « UML en Action de l’analyse des besoins à la
conception » de Pascal Roques et de Franck Vallée
— « Conduite de projets informatiques :
Développement, analyse et pilotage » Brice-Arnaud
GUERIN
— « Conduite de projets informatiques : Principes et
techniques s’appuyant sur la méthode MERISE »
José Moréjon, Jean-René Rames

5
Approche systémique et
systèmes d'information
Approche systémique
L'approche systémique se distingue de la
pensée cartésienne pour appréhender des
objets de grande complexité. Un objet
complexe se caractérise par un nombre
important de relations entre les éléments qui
le constituent, alors qu'un objet compliqué est
caractérisé par un nombre important
d'éléments. L'analyse cartésienne s'applique
bien au domaine du compliqué, mais mal aux
domaines du complexe.

!!! Si les éléments sont imbriqués et corrélés, alors il faut une vision d'ensemble, une
approche systémique.
Approche systémique
La notion de système

Un système est un ensemble d'éléments en

interaction dynamique organisés en fonction d'un
but. Joël de Rosnay (1975)

Ou:

Un système est défini comme quelque chose

(n'importe quoi d'identifiable) qui fait quelque
chose (activité, fonction) et qui est doté d'une
structure, qui évolue dans le temps, dans quelque
chose (environnement), pour quelque chose
(finalité). J.J. Le Moigne (1977)
Approche systémique
La notion de système
Approche systémique
La notion de système

Trois propriétés formelles caractérisent les systèmes :

— propriété de totalité : le système est composé
d'éléments qui constituent un tout cohérent et
indivisible. La complexité d'un système dépend autant
de la variété de ses composants que de l'interaction
entre ces mêmes composants.
— propriété de rétroaction : on possède en entrée des
informations sur les sorties (cycle d'information)
— propriété d'équifinalité : les mêmes conséquences
peuvent avoir des origines différentes (contrairement
aux systèmes fermés).
Système d’information
organisation + environnement = SYSTEME ORGANISATIONNEL

entrées sorties
Organisation

transformations

11
Système d’information
Ensemble de moyens humains et matériels et de méthodes permettant de
réaliser les traitements nécessaires sur les différentes formes d’information
pour la bonne conduite de l’organisation

Un SI est en quelque sorte une extension de la mémoire humaine qui amplifie le

pouvoir de mémorisation des acteurs de l'organisation et facilite leur prise de
décision.

12
Système d’information
Un système d'information possède diverses facettes. La représentation la plus utilisée
est celle des trois cycles : abstraction, décision, vie.

Ø Le cycle de vie est le cheminement

chronologique du système
d'information : conception,
réalisation, maintenance, déclin.
Ø Le cycle d'abstraction correspond
à plusieurs niveaux, trois en général
(Merise) : conceptuel (indépendant
de l'organisation et des moyens
techniques), logique/organisationnel
(dépend de qui, oui, comment, où),
physique (dépend des moyens
techniques).
Ø Le cycle de décision représente
l'ensemble des mécanismes de
décision.
 Système d’information
Cycle d'abstraction

Niveau Conceptuel

Niveau Logique

Cycle de vie
Niveau Physique

Etude préalable

Etude détaillée

Etude technique
Réalisation

Maintenance

Ordre de décision

L’axe Cycle de vie permet de planifier les évolutions du SI et d’organiser les

changements, l’axe cycle d’abstraction permet une certaine indépendance entre la
solution conceptuelle et la solution technique.
Système d’information
Rôle : produire des informations «légales»
déclencher des décisions programmées

SD : système décisionnel SI : système d’information SO : système opérant

15
Informatisation d'un système d'information
L'informatisation du système d'information conduit à distinguer dans la conception
d'un système d'information deux niveaux d'étude différents
Informatisation d'un système d'information

outils
entreprise informatiques

langage strict
organisation vivante
contraintes technologiques
problèmes mal définis

17
Informatisation d'un système d'information

nécessité de conception

méthodes d’analyse et de conception

Analyse du cycle de vie du SI

Suivi de principes

Interfaces de haut niveau

standards d’environnement

Conception ===> Méthodologie

18
 Informatisation d'un système d'information
!"#$%&'()*+,-./&0$+., 10,./0&0()'#(&2$3.).4.5+'#
Panorama des méthodologies
30+1232425.)$ $4H"3',38&,#&-(%"23&'(% !#)*+,)-,.$)

! 45#$ 02%(&(3&452'(3*( ! 45#$ L$"'#*82"3&'(&',%%(

! !$2%( ! 0,28$2%($ EP23KE,82"3
! (P,'4$2*,3 '$(,'
! *8 AB&;&D=C &'((823@%
! 65#$ ;(*1($*1(&'3#3&'"')E( ! 65#$ ;(*1($*1(&'(%&@,23%&'(&H$"'#*825284
! F4-#8&;&H$"@$,'',82"3&%8$#*8#$4( ! !$2%(&H48$"E2)$(
! 02E2(#&;&*I*E(&'(&52( ! (P,KK$"38('(38&(%8""#(%8

! ,23&;&'481"'(%&'(&%H4*2K2*,82"3#&
*"3*(H82"3
! 75#$ ,"$'($&#3&8"#8&*"14$(38 ! 75#$ (,&K23&'#&'"')E(&124$,$*12.#(
D"#5(E&23'2*,8(#$&;&E(&*1M',@(
! 0481"'"E"@2(%&'(&'45(E"HH('(38 !
! (,&K23&'(%&23'#%8$2(%&E"#$'(%
! #82E%#&(352$"33('(38% ! (2-4$,E2%,82"3&'(%&KE#-&K23,3*2($%
! M,23%&'(&H$"'#*825284
! 85#$ ='4E2"$,82"3% ! 85#$ (P,5)3('(38&'(%&$4%(,#-
! ;4#82E2%,-2E284 ! (,&'4'"*$,82%,82"3&'(&E,&-"#$%(
((%&K#%2"3%",*.#2%282"3%
! *38($""H4$,-2E284 !
! (P(38$(H$2%(&48(3'#(

!"#$%&'(&)*
9555#$ E(&52EE,@(&HE,348,2$(&"#N(8&E,&8(*8"32.#(&'(&HE,.#(%&O
+"$'(,#-&! .//0
 Informatisation
!"#$%&'()*+,-./&0$+., d'un système d'information
10,./0&0()'#(&2$3.).4.5+'#
Panorama des méthodologies
! !)$73089,:1)$73:.*<2,89+.$9+.2*7$2*+79=;2=,3:1=.7:2**=)$7)+7?.)*7
30<.*.)$

! 39.$ 7.47$=?$.$+)7)*:2,)73)7*28?,)=/7-,2?4B8)$73:2,3,)7< 497<2.$7

0:2*28.D=)$ 7-24.+.D=)$ 7$2:.9=/7)+72,59*.$9+.2**)4$ EEE

! F)7*28?,)=/7-,2;)+$70:12=)*+7)*7,9.$2*73=7*2*7,)$-):+73=7:91.),7
3)$7:19,5)$ 7< 497<2.$7)*7:)7D=.7:2*:),*)74)$7?=35)+$7)+74)$73049.$

! !)$7425.:.)4$74.G,0$7*)7$2*+7-9$7+2=;2=,$73)7D=94.+0 !"# .4$7*)7

,0-2*3)*+7-9$79=/7?)$2.*$73)$7=+.4.$9+)=,$

! -=$$.7-9,4)&+&2*7+2=;2=,$73)7:,.$)7)*750*.)7425.:.)4

!"#$%&'(&)*
+"$'(,#-&! .//0
 !"#$%&'()*+,-./&0$+., 10,./0&0()'#(&2$3.).4.5+'#
Informatisation d'un système d'information
Panorama des méthodologies
! !"#$%&'"(()(#*:,-.&%/01,(01,&-#/%/"#(:,3#0$$0%0=1#0);&)%*:6),#
7,"-#*8.,-,#"1#'&*8 ##-:"(1#$0(#1&103"/"-1#/0=1%,(8

! !0#'%,("#*)#3&:,',"3#("#/0-,."(1"#< 1%0<"%(#
! 3"#*8%0$0:"#*"(#*830,(#"1#*"(#'&>1(#*"#*8<"3&$$"/"-1#*"#30#
$3)$0%1#*"(#$%&;"1(#,-.&%/01,>)"(

! 30#%803,(01,&-#*"#3&:,',"3(#*"#/0)<0,("#>)03,18
! >),#-"#(01,(.&-1#$0(#3"(#)1,3,(01")%(

! >),#-"#(&-1#$0%.&,(#;0/0,(#)1,3,(8(#

! &)#>),#-8'"((,1"-1#*"#-&/7%")("(#"1#'&>1")("(#%8<,(,&-(

! !"(#".."1(#*"#30#'%,("#$&%1"-1#0)((,#7,"-#()%#3"#$30-#8'&-&/,>)"#"1#
.,-0-',"%#>)"#()%#3"#$30-#&%:0-,(01,&--"3#"1#6)/0,-

!"#$%&'(&)*
 Informatisation d'un système d'information
Panorama des méthodologies
!"#$%&'()*+,-./&0$+., 10,./0&0()'#(&2$3.).4.5+'#
Les !"(#$%&73@/"(
problèmes
! !"(#/816&*"(#"1#1"'6-,>)"(#*"#:8-,"#3&:,',"3#*&,<"-1#$"%/"11%"#
*?0*0$1"%#&)#*"#.0,%"#8<&3)"%#)-#3&:,',"3#0$%@(#(0#/,("#"-#
"/$3&,101,&-

! !?&7(10'3"#/0;")%#$&)%#'"%-"%#3"(#7"(&,-(#*"(#)1,3,(01")%(#<,"-1#*"#
'"#>)"#3"(#)1,3,(01")%(#-"#'&--0,(("-1#$0(#1&);&)%(#1%@(#7,"-#3")%(#
$%&$%"(#7"(&,-(#0)#*87)1#*)#$%&;"1

! )3#<,"-1#8:03"/"-1#*"#'"#>)"#'"#7"(&,-#8<&3)"#0)#'&)%(#*)#$%&;"1#"-#
("#-&)%%,((0-1#*"(#%8()3101(#*"#3?0-03C("#*"#3?&%:0-,(01,&-D

! )3#<,"-1#()%1&)1#*"#'"#>)"#30#'&//)-,'01,&-#0<"'#3"(#,-.&%/01,',"-(#
-?"(1#$0(#&)#/03#:8%8"D

! )3#<,"-1#*)#'0%0'1@%"#07('&-(#*"#30#'&/$3"/,18 *"(#E&)<"33"(#
!"#$%&'(&)*
?"'6-&3&:,"(#*"#3?)-.&%/01,&-
+"$'(,#-&! .//0
 Informatisation d'un système d'information
!"#$%&'()*+,-./&0$+., 10,./0&0()'#(&2$3.).4.5+'#
Panorama des méthodologies

! *',234($&'(%&%"5#63"4%&'761"'"5"23.#(%&.#3&:($'(66(46

! '(&'7;(5"::($&(6&'(&<,3$(&7;"5#($&#4&5"23*3(5&%#3;,46&5(%&-(%"34%&$7(5%&'(%&
#6353%,6(#$%

! '33':53.#($&',;,46,2(&5(%&#6353%,6(#$%&(6&5(%&$(%:"4%,-5(%&4 6"#%&5(%&43;(,#-&'(&
',4,2('(46&',4%&5(&:$"*(%%#%&'(&'7*3%3"4&(6&'(&'7;(5"::('(46&'(%&5"23*3(5%

! '3,'753"$($&5,&<"$',63"4

! '(&$7'#3$(&5(&<,$'(,#&'(&5,&',346(4,4*(&(6&5(&*"56&'(&'7;(5"::('(46&

3"?@,&,!,.)"(
!"#$%&'(&)*
+"$'(,#-&! .//0
Informatisation d'un système d'information
Panorama des méthodologies
!"#$%&'()*+,-./&0$+., 10,./0&0()'#(&2$3.).4.5+'#

A,-./0&2.34,-,5.367089:9;9<=.3B

! ! !#$%&''(')*+'%+,-+./ 0(+)1/."#&)(.)&.'&34-&)*&)
3$*"-&')*/%#+56.7)-&')*+88/#&.7')6',&%7')*9(.)'#'7"3&)
-$1+%+&-;)&.)(7+-+'6.7)(.&)%&#76+.&).$767+$.)4+&.)*/8+.+& <
!+""*1#&60$
! >4%('-5(&'(&$)25(%&-3(4&'7<343(%&.#3&*"4'#3%(46&:"#$&#4&
:$"-5)'(&4 #4(&%"5#63"4&*"$$(*6(&
! 24(&'761"'(&,&:"#$&"-P(6
! '(&'7*$3$(&53(4%('-5(&'(%&6<*1(%&4 ,**"':53$#&
! 53"$'"44,4*('(46&'(&*(%&6<*1(%#
! 5(%&'"*#'(46%&(6&5(%&%6,4',$'%&.#3&5(#$&%"46&,%%"*37(%#&
! K(&'"44($&#4(&'7',$*1(&:"#$&'(4($&5(%&,4,5L%(%
 Informatisation d'un système d'information
Panorama des méthodologies
!"#$%&'()*+,-./&0$+., 10,./0&0()'#(&2$3.).4.5+'#

! 22(&'451"'(&'"75&:5$(&!"#"$%&'
! ()#*%++'$,-'*< /#'*0'12#-3/'*4%$0-1/&-5$'
! 2%4%7&'*8'*9%-$'*9%1'*< 8'+*4$);'0+*8'*0%-&&'*'0*+/;'0*,%$-"+
! C'$<'00$'*&%*<%=0$-+'*8'+*7/8!'0+
! D-/'$*&'*1%8$'*8@/0-&-+%0-)#*)40-<-+"'*8'+*)/0-&+*8@%-8'*< &%*
+4"1-9-1%0-)# *&%*1)#1'40-)# *&%*$"%&-+%0-)# *BBB
! -11$)=0$'*&%*4$)8/10-,-0" 8'+*+'$,-1'+*-#9)$<%0-3/'+
! -++/$'$*&%*1)2"$'#1'*8'+*+)&/0-)#+*1)#E/'+*'0*&'/$*-#0"!$%0-)#*
8%#+*/#'*+0$%0"!-'*!&)7%&'

! 22(&'451"'(&'"75&%9,'$(%%($&4 5"#%&;(%&,*5(#$%
! %-8'*< &%*<-+'*'#*4&%1'*8@/#*&%#!%!'*1)<</#*%/*+'-#*8'*
&@)$!%#-+%0-)#
! 4)/$*!%$%#0-$*/#'*<'-&&'/$'*1)<</#-1%0-)#*'#0$'*0)/+*&'+*
!"#$%&'(&)*
4%$0'#%-$'+
+"$'(,#-&! .//0
 Informatisation d'un système d'information
!"#$%&'()*+,-./&0$+.,
Panorama 10,./0&0()'#(&2$3.).4.5+'#
des méthodologies
2)<4)+%#0'+*8@/#'*<"02)8)&)!-'*
" 22(&'4',$*1(&"#&,==$"*1(
! >==$"*1(&%5$#*5#$4(N@"2*57"22(;;(
3%#-5$'*8@%7)$8'$*&%*4$)7&"<%0-3/'*
! >==$"*1(&%A%54'7.#( "+)/,'#0*&-" < &%*+0$/10/$'*8'*&@)$!%#-+%0-)#*"0/8-"'$
! >==$"*1(&"-P(5
! >==$"*1(&Q0

" 22(&'A2,'7.#(
! >%*(2',25(N'(%*(2',25( ,$!%#-+%0-)#*8'+*42%+'+*8'*&@%#%&F+'
! !A*;(&'(&G7(
.'+0-)#*8'*4$);'0
" 22&;,2H,H(
! 045,"'"');(
! (,2H,H(&'(&0"'4;7%,57"2&
,/0-&+*8@%#%&F+'**********
"4'$<'0*8'*9)$</&'$*&%*8"<%$12'$
! (,2H,H(&'(&=$"H$,'',57"2&2,57@

" L(%&"#57;%
! >M(&'(&'"'4;7%,57"2 (/44)$0*< &%*4$)8/10-)#*8'+*&-,$%7&'+*
! +#%72(%%&=$"*(%% 0"'(;($ "8-%!$%<<'+ *+4"1-9-1%0-)#+ *0'<4&%0'+ #$
!"#$%&'(&)*
+"$'(,#-&! .//0
 Informatisation d'un système d'information
!"#$%&'()*+,-./&0$+., 10,./0&0()'#(&2$3.).4.5+'#
Panorama des méthodologies
! $#$%%#$($)(*$+%,$-./012,$+%34+,$)1+5$./+23,5$#,*$601*,* F
753*/1/,

! !"#$%&'()*)+),-"#$.)/01-##"1'$020"%"1'$*"#$#)+/'-)1#$,+)32+"#$#/0$
')/'"#$4"#$4)%5)#21'"#$%2-#$5+/'F'$*"#$#)+/'-)1#$520'-"++"#$#/0$
4"0'2-1"#

! >3&4536(&("86*6(:#&"3&,
! +"#$%&'()*"#$*"$4)1*/-'"$*"$50);"'#
! +"#$%&'()*"#$*"$#5&4-.-42'-)1
! +"#$%&'()*"#$*8212+9#"$"'$*"$4)14"5'-)1
! +"#$%&'()*"#$*"$0&2+-#2'-)1
! +"#$%&'()*"#$*"$,"#'-)1$*"$50);"'#
! +"#$%&'()*"#$*82##/0214"$"'$*"$,"#'-)1$*"$+2$:/2+-'&
! +"#$%&'()*"#$*"$,"#'-)1$"'$*8&;2+/2'-)1$*"#$4)>'#$"'$*"#$0-#:/"#
! ===
!"#$%&'(&)*
+"$'(,#-&! .//0
 Informatisation d'un système d'information
!"#$%&'()*+,-./&0$+., 10,./0&0()'#(&2$3.).4.5+'#
Panorama des méthodologies
C0-14-52+"#$%&'()*"#$*"$4)14"5'-)1$

011.2/3$ &%.-/%-.)$ &'(%)*+,-$ !"#$%

-5520-'-)1 ((%&<:#%&,3*6(3% C15"$6(&'(%& ((&<:#%&$5*(3=

%@%=)'(%
,0-,-1" K38:""),-"3( >#$"<5(33( (,38,8(%&

3)*&+-#2'-)1 H5*"'<"%6=6"3& 0"'5:6%,=6"3&'(%& -P(=&?&)=$#*=#$(&U&

,$-"$(%*(3=(&'(%& '"335(%&(=&'(%& !"'<"$=('(3=
T"3*=6"3% =$,6=('(3=%
22024= ,:#-&'(&'"335(% )5<,$,=6"3& *'<:5'(3=,=6"3&
'"335(%&N&
=$,6=('(3=%
?/"%5+"# )KHC 0>;*)> 20L&N&20(
H>0K;! KS*K( H
T 2;H D *HK R H
!"#$%&'(&)*
+"$'(,#-&! .//0
 Informatisation d'un système d'information

Méthodes de conception existantes

Années 70 — Les approches cartésiennes

Années 80 — Les approches systémiques

Années 90 — les approches objet

29
Informatisation d'un système d'information

Les méthodes existantes

Selon la manière dont les méthodes perçoivent le SI,

on distingue :
Ø les méthodes d’analyse et de décomposition
hiérarchiques (approche cartésienne) qui
correspondent à la première génération des
méthodes des années 70
Ø les méthodes d’analyse et de représentation
systémiques qui constituent la deuxième
génération (années 80)
Ø les méthodes d’analyse et de conception orienté
objet (troisième génération années 90).
Informatisation d'un système d'information

Les méthodes existantes

Les approches cartésiennes

Issues de la programmation structurée, elles

décomposent hiérarchiquement un problème
en sous problèmes pour en maîtriser la
complexité.
Jackson (Jackson 76), SADT (Marco 88) ,
Yourdon (Yourdon 89)…
Informatisation d'un système d'information

Les méthodes existantes

Les approches systémiques

Inspirées de la théorie systémique des organisations,

ces méthodes considèrent le SI comme un objet
complexe actif dont il faut décrire la structure
(architecture) et les objectifs fonctionnels
(fonctions).
Merise (Tardieu 83), Axial (Pellaumail 86),
Information Engineering (Martin 86)
Informatisation d'un système d'information
Les méthodes existantes

Les approches objet

Ces méthodes peuvent être considérées comme une
évolution des approches systémiques dans laquelle le
côté dynamique des objets est pris en compte de
manière plus cohérente.
OOD (Booch 91),
HOOD (Delatte 93),
OMT (Rumbaugh 91),
OOSE (Jacobson 92),
OOA/SM (Shlaer 92),
OOA/OOD (Coad 91),
OOM (Rochfeld 93),
Classe-Relation (Desfray 94)
Informatisation d'un système d'information

Les étapes de Merise

— Merise est une méthode de conception des systèmes

d'information. Comme beaucoup de méthodes nées entre 1975 et
1980, les considérations précédentes s'appliquent et notamment
si l'on se base sur le cycle de vie (mais pas seulement), on peut
considérer que la construction d'un système d'information se
résume à une succession d'étapes.
— En l'occurrence, pour Merise, les étapes sont :
– le schéma directeur
– l'étude préalable
– l'étude détaillée
– la réalisation
– la mise en œuvre
– la maintenance
— Ces étapes considèrent que le problème à résoudre doit être
préalablement examiné de manière globale, puis après découpage
du sujet traité en domaines et sous-domaines, on procède à des
analyses plus fines.
Informatisation d'un système d'information
Les étapes de Merise
Le schéma ci-dessous indique pour Merise le découpage entre les
différentes étapes.
Informatisation d'un système d'information
Les étapes de Merise
Informatisation d'un système d'information
Les étapes de Merise
Ø schéma directeur
◦ objectif : relier la stratégie et les besoins en systèmes d'information
◦ identification des domaines de gestion (exemple : achats, études,
fabrication, commercial, personnel, qualité, finances...) et des finalités
(exemple : concevoir des produits nouveaux, vendre des produits,
acheter des matières premières, recruter du personnel, livrer des
produits commandés...)
Ø étude préalable
◦ reprise par domaine du schéma directeur et étude plus approfondie
des projets
◦ doit être courte mais complète
◦ proposition de solutions en vue du choix
Ø étude détaillée
◦ étude effectuée projet par projet
◦ conception fonctionnelle : étude préalable, puis scénarios puis choix,
puis cahier des charges
◦ conception technique : cahier des charges de réalisation
Informatisation d'un système d'information
Les étapes de Merise
Ø réalisation
◦ étude technique : description logique et physique de l'organisation des
données ; description de l'architecture des traitements.
◦ programmation suivie de recette
Ø mise en œuvre
◦ réalisation et initialisation des bases de données
◦ réception et installation des ressources
◦ confection de la documentation utilisateur
◦ formation des utilisateurs
◦ lancement des nouvelles applications en parallèle avec les anciennes
avant lancement définitif
Ø maintenance
◦ Faire « vivre » les applications
◦ qualité des étapes précédentes : diminution des coûts de maintenance
Les méthodes « classiques et obsolètes »

KGaye 39
Les méthodes « classiques et obsolètes »
Vocabulaire
§ On distingue :
ØLes Méthodes de Conception de SI, qui permettent de
représenter ou de modéliser le SI (objets, données,
fonctions, ...). Exemple : Merise.
ØLes Méthodes de Conduite de Projet, qui définissent
l’intégralité des règles selon lesquelles le projet sera mené
(Cf. page suivante).
§ Toutes ces méthodes s’appuient, explicitement ou
non, sur un découpage du projet en phases
temporelles et/ou en activités qu’on appelle «
modèle de développement ».
Ces phases/activités sont délimitées dans le temps et dans
leur fonction. On peut ainsi subdiviser la tâche afin de la
rendre plus facilement planifiable et contrôlable.
Le respect rigoureux de cette subdivision constitue la
première étape de la démarche de suivi d’une méthode.
KGaye 40
Les méthodes « classiques et obsolètes »
Ø Les Méthodes de Conduite de Projet sont extrêmement
complètes et laissent très peu de marge d’initiative à l’équipe
projet car elles définissent :

◦ Le modèle de développement du projet (phases et activités

détaillées)
◦ Les principes de gestion (management) du projet :
ü L’organisation générale (rôles et responsabilités des acteurs)
ü Le mode de planification et de suivi (plannings, jalons, revues, ...)
ü les outils de contrôle et de décision (analyse de risque, reporting, audits,...)
ü La liste et le contenu normé de tous les livrables
ü Des procédures de mise à jour des livrables et des produits
ü ...
◦ Les principes d’exécution du projet :
ü La méthode de conception du SI
ü ...
à Le respect intégral d’une méthode de Conduite de
Projet peut être très lourd. Il n’est donc efficace et
rentable que pour des projets de grande taille.
KGaye 41
Les méthodes « classiques et obsolètes »
Évolution des méthodes et des modèles de
développement
Ø Il existe de nombreuses méthodes et modèles de
développement pour mener un projet informatique,
plus ou moins formalisés, apparus progressivement à
partir des années 1960/70. Parmi les plus célèbres on
trouve des méthodes d’analyse structurée (SA, SADT),
le RAD, etc...
Ø Avec l’émergence d’UML sont apparus de nouvelles
méthodes de conduite de projet, les processus unifiés
(unified process) parmi lesquels :
qle RUP (Rational Unified Process) en 1999
qle 2TUP (2 Track Unified Process).
Sans être totalement opposés aux processus classiques
(ils en reprennent souvent les grands concepts) ils
représentent une modernisation sensible en la matière.
KGaye 42
Les méthodes « classiques et obsolètes » : Le Modèle en cascade
Ø C’est le modèle le plus classiquement utilisé dans les années 70/80.
◦ Il jalonne rigoureusement le processus selon une succession d’étapes donnant
chacune lieu à une validation officielle; on ne passe à l’étape suivante que si le
contrôle est satisfaisant à Pas de retour possible sur les options validées
antérieurement.

Le modèle en Cascade
Waterfall model

KGaye 43
 Vérification : le produit correct ?

Les méthodes « classiques et obsolètes » : Le Modèle en cascade

P. Collet 6

Le modèle en Cascade
Modèle en cascade Waterfall model
(1970)

Analyse des besoins

vérification
Specif. fonctionnelles vérification Changement
vérification dans l’expression
Planification des besoins
vérification
Conception
vérification
Implémentation
tests unitaires
Intégration
tests
Qualification
tests
Exploitation

Retrait
P. Collet 8

KGaye 44
Les méthodes « classiques et obsolètes » : Le Modèle en cascade

Inconvénients majeurs du modèle en cascade :

Ø « L’effet tunnel » : l’utilisateur est consulté exclusivement au

tout début (recueil des besoins) et à la fin du projet (validation). Dans
l’intervalle le projet est «sous le tunnel» et l’utilisateur en perd la
visibilité. Il en ressort plusieurs mois après et on découvre alors que
les livrables ne sont pas conformes aux spécifications ou aux
attentes.
Ø Cloisonnement entre acteurs (notamment entre les «
fonctionnels » et les « techniques ») : La documentation ne suffit pas
pour communiquer, il faut plus d’interactivité directe.
Ø Abstraction : la conception reste très abstraite car il n’y a
jamais de matérialisations du produit final avant sa livraison.
Ø Conception non évolutive : le modèle en cascade ne
permet pas de prendre en compte des évolutions de spécifications en
cours de processus. Or il est presque impossible de concevoir
exhaustivement un système dès l’initiation du projet.
KGaye 45
Les méthodes « classiques et obsolètes » : Le Modèle en V

Encore le plus largement utilisé aujourd’hui, il constitue une amélioration de

modèle en cascade en réduisant l’effet tunnel.
—Phase descendante = Spécifications et Conception.
—Phase ascendante = Tests et Validations.
—Lors de chaque étape de la phase descendante on explicite les critères
d’acceptation du système. Dans l’étape correspondante de la phase
ascendante on possède donc les éléments stables, objectifs et consensuels
pour valider le travail.
—Exemple : le contenu des tests unitaires est défini avant la conception des
programmes. Lorsque ceux-ci seront réalisés on pourra mesurer
objectivement la qualité du programme.
—Autre exemple : le cahier de recette est conçu en même temps que les
spécifications fonctionnelles par la MOA. Il sera donc plus facile de tester
l’ensemble des fonctionnalités de système une fois celui-ci livré.
—Inconvénient : les tests arrivent toujours assez tardivement par rapport à
l’input user.
KGaye 46
Les méthodes « classiques et obsolètes » : Le Modèle en V

Ø Part d’une concepAon globale et décompose leISIAG système en sous-

- MASTER 2
ensembles, qui sont développés et testésETséparément.
METHODOLOGIE CONDUITE DEOnPROJETS
fait ensuite
l’intégraAon et les tests du système complet. Il ne prévoit pas de retour
arrière. Le Modèle en V

Expression
Expressiondes
desbesoins
besoins Bilan
BilanProjet
Projet

Spécifications
Spécificationsfonctionnelles
fonctionnelles Recette
Recette

Conception
ConceptionGénérale
Générale Test
Testd’Intégration
d’Intégration

Conception
Conceptiondétaillée
détaillée Test
TestUnitaires
Unitaires

Codage
Codage
ABIC
KGaye 9
47
Les méthodes « classiques et obsolètes » : Le Modèle en W

Ø Il part du modèle en V, en y ajoutant des phases

d’élaboraAon de maqueNes permeNant de valider la
concepAon. Il ne prévoit pas de retour arrière.

Définition des besoins bruts Analyse des besoins Tests d'acceptation

Conception du système Tests du système

Conception Maquettes
de haut niveau
Conception du Test du
composant 'i' composant 'i'

Vérification des flux Codage du

logiques composant 'i'
KGaye 48
 Les méthodes « classiques et obsolètes » : Le Modèle en cascade
les activités et livrables
Phase Activités Résultats (essentiellement des
documents)
ÉTUDE Etude de faisabilité Rapport d'étude Schéma directeur Grandes lignes
PRÉALABLE Analyse des besoin des besoins
Cahier des charge
PLANIFICATION Organisation et mise en place du projet - Plan de développement (référentiel dont le planning)
ET Définition des besoins - Définition de la Spécification technique des besoins Spécification (ou
SPÉCIFICATION stratégie de test - Définition des interfaces plan) des tests d'acceptation Manuel utilisateur
utilisateurs préliminaire
CONCEPTION Conception de l'architecture - Définition des Architecture des modules logiciels Spécification des
PRÉLIMINAIRE interfaces - Définition des tests d'intégration interfaces Spécification (ou plan) des tests
d'intégration
CONCEPTION Analyse détaillée des modules - Définition des Spécification des modules - Spécification (ou plan)
DÉTAILLÉE tests unitaires des tests unitaires
CODAGE Codage ou programmation - Tests unitaires de Code source des modules - Comptes rendus des
chaque module tests unitaires
INTÉGRATION Intégration - Tests d'intégration - Recette Comptes rendus des tests d'intégration Comptes
usine (tests de validation chez le fournisseur) rendus des tests de validation Manuel utilisateur final
INSTALLATION Livraison chez le client - Installation et mise Bordereau de livraison
en œuvre - Recette (validation opérationnelle) Comptes rendus des tests de validation Procès
verbal d'acceptation par le client
EXPLOITATION Formation des utilisateurs - Corrections des Rapports d'anomalies Demandes d'évolutions - 49
KGaye
ET anomalies - Améliorations ou évolutions - Versions du produit logiciel
MAINTENANCE Gestion en configuration des livraisons
Les méthodes «classiques et obsolètes» : Synthèse
Ø Intérêts :
◦ PermeNent de connaître « dès le départ » l’ensemble des foncAonnalités
d’une applicaAon è Rassurant
◦ Fournies une documentaAon avancée du logiciel
◦ Simple à appréhender è Rassurant pour beaucoup de décideurs

Ø Difficultés à postériori :
◦ Savez-vous aujourd’hui définir dans le détail et par avance la maison de vos
rêves ??

è Réponse oui en théorie, et NON dans la pra+que : au mieux vous en aurez

une idée plus ou moins précise (votre 3ème maison sera la bonne!)
– Il en va de même avec la concepAon d’une applicaAon.
– Le besoin réel se construit au fur et à mesure de son uAlisaAon.
◦ Cela implique la plus part du temps :
– Une applicaAon mal pensée par rapport aux besoins réels des uAlisateurs
– Un dépassement des délais et des coûts établis au départ du projet
KGaye 50
Annexe

51
Les disciplines d’un projet

52
 Les disciplines d’un projet: vue d’ensemble
Rappel :

Exp. Spécificati Conceptio Développ Déploiem Exploitati

Besoins ons n ement Recette ent on

Maîtrise d’ouvrage Domaine Production

Projet domaine « Etudes »

Le cycle de vie du projet ne concerne que la réalisaAon du produit

informaAque (en rouge)

53
Les disciplines d’un projet : spécificaAons
— SpécificaAons = manière dont l’applicaAon va implémenter
les besoins (étape précédente = expression de besoin)
— Définir le périmètre de l’applicaAon :
◦ au niveau foncAonnel : acAvités méAer à informaAser (souvent sous UML)
– NavigaAon dans l’applicaAon
– DescripAon détaillé des écrans : maqueNes, règles de gesAon écran
– OrganisaAon des traitements
– DescripAon détaillée des traitements « batch »
– GesAon des habilitaAons
– Paramétrage et contrôle des traitements
◦ au niveau technique : interfaces techniques du projet (normes, flux
de données, interfaces matérielles (info indus, imprimantes,
équipements mobiles, …)
— Livrables
◦ SpécificaAons FoncAonnelles Générales (SFG) - opAon
◦ SpécificaAons FoncAonnelles Détaillées (SFD) - obligatoire
◦ SpécificaAons Techniques Générales (STG) - opAon
◦ SpécificaAons Techniques Détaillées (STD) - opAon
54
 Les disciplines d’un projet : Architecture
Technique
— Peut être opAonnel (si l’architecture est déjà en place et
maîtrisée)
— Nécessaire s’il faut industrialiser les développements sur de
gros projets
— Tâches :
◦ SélecAonner avec soin les ouAls de développement
◦ Récupérer un framework existant ou le créer
◦ MeNre en place des foncAons standard pour les DAO
◦ IdenAfier et contourner les contraintes techniques (ex : projets
J2EE : comportements différents selon les navigateurs)
◦ Réaliser des modèles d’implémentaAon qui seront largement
uAlisés, exemple :
– Écran de saisie, navigaAon standard dans l’écran
– Fenêtres standard d’erreurs et gesAon standard des retours d’erreur
— Livrables
◦ Dossier d’architecture logicielle
55
Les disciplines d’un projet : ConcepAon
Technique
— ConcepAon Technique = Passerelle entre SFD et
Code
— Point d’entrée des développeurs
— Tâches :
◦ Analyser les SFD et détecter d’éventuelles anomalies
◦ IdenAfier les composants à développer (classes, écrans,
services méAer, …)
◦ Formaliser la navigaAon entre les écrans
◦ Formaliser sous forme de pseudo code les traitements
— Livrables
◦ Dossier de ConcepAon Technique

56
Les disciplines d’un projet : développement
— Tâches
◦ Développement, dans le respect :
– Des spécificaAons
– De la concepAon applicaAve
◦ Tests usine
– Tests Unitaires
– Tests d’intégraAon
– Tests par mutaAon, tests par propriétés
– Tests foncAonnels, Tests IHM
– Tests de montée en charge, de robustesse, de sécurité, de scalabilité,
….
— Livrables
◦ Code source
◦ Exécutables, dans un package de livraison complet
◦ DocumentaAon du code (si intérêt)
◦ DocumentaAon uAlisateur (dérive spécificaAons foncAonnelles)
◦ DocumentaAon des tests

57
 Les disciplines d’un projet : receNe
— But
◦ Passage de ses tests avant mise en producAon
— Plusieurs niveaux :
◦ VT : ValidaAon technique (non contractuelle) : porte sur des sous ensembles
de l’applicaAon
◦ VA : VérificaAon d’ApAtude (ou VABF : VA au Bon FoncAonnement) :
opéraAon contractuelle : vérifier que l’applicaAon finale respecte
scrupuleusement les spécificaAons. CeNe validaAon déclenche la mise en
producAon
◦ VSP : VérificaAon sur Site Pilote (opAonnel) : correcAon de bugs éventuels en
producAon sur une extracAon des sites client
◦ VSR : VérificaAon pour Service Régulier (contractuel) : correcAon de bugs en
producAon sur tous les sites clients. Déclenche le début de la garanAe
contractuelle
— Livrables
◦ Bordereaux de livraison (chaque étape)
◦ PV (procès verbal) de receNe (chaque étape)
– « sans réserves »
– « avec réserves » : bugs à corriger (mineurs)

58