SlideShare une entreprise Scribd logo
1  sur  157
Télécharger pour lire hors ligne
E-­‐business 
: 
stratégie 
marketing 
et 
développement 
2012-­‐2013 
Manon 
Cuylits
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
2 
PARTIE 
1 
: 
DEVELOPPEMENT 
DE 
SYSTEMES 
E-­‐BUSINESS 
PLAN 
• Projet 
de 
développement 
d’un 
système 
e-­‐business 
o Processus 
de 
développement 
o Spécificités 
des 
projets 
e-­‐business 
o Cycle 
de 
développement 
• Lancement 
du 
projet 
o Définition 
de 
la 
portée 
du 
système 
o Gestion 
des 
acteurs 
o Gestion 
du 
projet 
• Etude 
d’opportunité 
• Spécification 
o Définition 
de 
la 
spécification 
o Diagramme 
de 
cas 
d’utilisation 
o Diagramme 
d’activité 
o Diagramme 
de 
contenu 
o Diagramme 
d’interface 
o Etude 
de 
cas 
Développement 
de 
systèmes 
e-­‐business 
• Réalisation 
o Conception 
et 
mise 
en 
oeuvre 
o Outils 
de 
développement 
§ Outils 
de 
développement 
classiques 
§ Générateurs 
de 
sites 
§ Package 
et 
content 
management 
o Techniques 
clés 
§ Pages 
dynamiques 
§ Interopérabilité 
des 
systèmes 
• Mise 
en 
production 
• Test 
• Exemple 
: 
Rational 
Unified 
Process 
• Maintenance 
et 
promotion 
• Sécurité 
o Etat 
et 
enjeux 
o Solutions 
o Exemple 
de 
procédure 
de 
sécurité
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
Le 
développement 
d’un 
système 
e-­‐business 
suit 
un 
processus 
de 
développement 
organisé 
et 
constitue 
un 
projet 
pour 
l’organisation. 
On 
souhaite 
créer 
un 
système 
e-­‐business 
dans 
notre 
organisation, 
(exemple 
3 
1. 
PROJET 
DE 
DEVELOPPEMENT 
D’UN 
SYSTEME 
D’E-­‐BUSINESS 
ð Processus 
de 
développement 
ð Spécificités 
des 
projets 
e-­‐business 
ð Cycle 
de 
développement 
PROJET 
DE 
DEVELOPPEMENT 
E-­‐BUSINESS 
Thierry 
Van 
den 
Berghe 
: 
site 
de 
vente 
en 
ligne, 
site 
communautaire, 
etc.) 
il 
faut 
que 
ce 
projet 
soit 
motivé, 
qu’on 
puisse 
démontrer 
que 
ce 
projet 
produit 
de 
la 
valeur 
ajoutée. 
Tout 
projet 
doit 
s’inscrire 
dans 
une 
stratégie 
et 
être 
cohérent. 
Le 
développement 
d’un 
système 
e-­‐business 
suit 
un 
processus 
organisé 
selon 
des 
étapes 
principales. 
On 
construit 
par 
étapes. 
La 
règle 
est 
de 
réfléchir 
avant 
d’agir, 
essayer 
d’adopter 
une 
approche 
industrielle 
dans 
le 
développement 
d’un 
logiciel. 
(Cf. 
ingénierie 
logicielle 
plus 
bas). 
Le 
développement 
d’un 
système 
e-­‐business 
constitue 
un 
projet 
pour 
l’organisation 
: 
-­‐ opérationnaliser 
la 
stratégie 
-­‐ gérer 
les 
ressources 
-­‐ gérer 
les 
contraintes 
de 
résultat, 
de 
budget 
et 
de 
délai 
L’INGENIERIE 
LOGICIELLE 
: 
DEFINITION 
& 
DEMARCHE 
L’ingénierie 
logicielle 
consiste 
à 
« 
appliquer 
une 
démarche 
systématique, 
disciplinée 
et 
quantifiable 
pour 
le 
développement 
d’un 
logiciel, 
un 
système 
e-­‐business 
». 
è 
élaboration 
de 
processus 
de 
développement. 
Un 
projet 
de 
développement 
suit 
un 
processus 
qui 
est 
généralement 
organisé 
en 
phases 
successives. 
Démarche 
générique 
:
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
4 
En 
général 
on 
trouve 
4 
grandes 
phases 
: 
Réflexion 
préalable 
au 
commencement 
du 
projet 
: 
Développement 
de 
systèmes 
e-­‐business 
1. comprendre 
le 
problème 
Par 
exemple 
: 
quels 
sont 
les 
besoins 
au 
niveau 
logistique 
pour 
construire 
un 
nouveau 
bâtiment 
2. planifier 
des 
solutions. 
Réalisation 
concrète 
de 
ce 
qui 
a 
été 
imaginé 
au 
préalable 
: 
3. exécuter 
le 
plan. 
4. Evaluer 
le 
résultat 
: 
phase 
de 
retour 
sur 
expérience 
: 
quand 
le 
projet 
est 
terminé 
on 
fait 
un 
bilan 
de 
ce 
qui 
a 
fonctionné 
ou 
non 
On 
distingue 
4 
phases 
et 
lors 
de 
ces 
phases 
on 
réalise 
une 
série 
d’activités 
(exemple 
: 
interview 
des 
utilisateurs 
pour 
connaître 
leurs 
besoins). 
Certaines 
activités 
peuvent 
avoir 
lieu 
à 
des 
phases 
différentes. 
Les 
tests 
de 
qualité 
interviennent 
en 
permanence 
par 
exemple. 
Ce 
sont 
des 
activités 
transversales 
qui 
ont 
lieu 
tout 
au 
long 
du 
projet. 
PRINCIPES 
DE 
BASE 
DE 
L’INGENIERIE 
LOGICIELLE 
• L’intention 
première 
d'un 
système 
est 
de 
donner 
de 
la 
valeur 
aux 
utilisateurs 
Un 
système 
est 
souvent 
développé 
pour 
une 
autre 
personne 
è 
collaborer, 
communiquer 
et 
documenter. 
Un 
système, 
développé 
par 
des 
informaticiens, 
qui 
n’est 
pas 
directement 
en 
connexion 
avec 
la 
demande 
des 
utilisateurs 
ce 
n’est 
pas 
une 
bonne 
chose. 
Tout 
le 
projet 
est 
guidé 
par 
une 
demande 
des 
utilisateurs. 
Ce 
n’est 
pas 
le 
cas 
pour 
la 
production 
d’autres 
types 
de 
bien 
mais 
c’est 
typique 
du 
logiciel. 
• garder 
le 
système 
simple 
= 
ligne 
de 
conduite 
intellectuelle 
Un 
système 
simple 
est 
plus 
facile 
à 
développer, 
à 
maintenir 
et 
à 
utiliser. 
Néanmoins, 
travailler 
à 
la 
simplification 
d'un 
système 
prend 
du 
temps 
et 
est 
ardu. 
• rester 
ouvert 
au 
futur 
et 
intégrer 
la 
flexibilité 
Les 
besoins 
des 
utilisateurs 
évoluent 
è 
le 
système 
doit 
pouvoir 
être 
adapté 
facilement! 
Les 
systèmes 
informatiques 
doivent 
suivre 
les 
attentes 
des 
utilisateurs 
et 
dans 
le 
business 
la 
manière 
dont 
on 
traite 
les 
affaires 
évolue 
constamment. 
Il 
faut 
pouvoir 
évoluer 
en 
proportion. 
Exemple 
du 
bug 
de 
l’an 
2000 
: 
en 
1999 
les 
informaticiens 
se 
sont 
rendu 
compte 
qu’il 
fallait 
gérer 
le 
fait 
qu’on 
allait 
passer 
de 
2 
chiffres 
à 
4 
chiffres, 
gérer 
le 
siècle. 
Les 
systèmes 
informatiques 
de 
l’époque 
étaient 
très 
mal 
prévus 
pour 
intégrer 
des 
changements. 
Ce 
n’est 
pas 
facile 
de 
construire 
un 
système 
qu’on 
peut 
faire 
évoluer. 
Un 
logiciel 
on 
le 
modifie 
encore 
une 
fois 
qu’il 
est 
« 
fini 
», 
ce 
n’est 
pas 
le 
cas 
des 
voitures 
par 
exemple.
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
5 
• encourager 
la 
réutilisation 
des 
composantes 
Thierry 
Van 
den 
Berghe 
o Exemple 
: 
construire 
un 
système 
en 
assemblant 
des 
composants 
existants 
Dans 
certaines 
industries, 
comme 
celle 
de 
l’automobile, 
on 
essaye 
de 
standardiser 
les 
composantes, 
les 
intégrer 
dans 
des 
ensembles 
plus 
vastes, 
mais 
dans 
le 
cas 
des 
logiciels 
cette 
standardisation 
a 
du 
mal 
à 
s’imposer 
et 
cela 
représente 
un 
cout 
significatif. 
1. 
PROCESSUS 
DE 
DEVELOPPEMENT 
Le 
Processus 
de 
développement: 
c’est 
un 
canevas 
qui 
structure 
et 
guide 
les 
informaticiens 
dans 
la 
production 
de 
logiciels, 
montre 
les 
différentes 
étapes 
à 
parcourir. 
Si 
on 
souhaite 
construire 
une 
maison 
on 
va 
suivre 
différentes 
étapes 
claires 
et 
structurées, 
c’est 
pareil. 
La 
production 
de 
la 
plupart 
des 
biens 
matériels 
et 
immatériels 
suivent 
un 
processus 
d’ingénierie 
bien 
précis. 
Processus 
Ø Quelles 
phases 
& 
tâches 
? 
Ø Quels 
délivrables 
? 
Ø Quels 
rôles 
? 
Ø Etc. 
Tâches 
managériales 
Ø Planification 
Ø Gestion 
des 
ressources 
Ø Gestion 
des 
risques 
Ø Gestion 
de 
la 
qualité 
Ø Etc. 
Tâches 
techniques 
Ø Spécification 
du 
système 
Ø Modélisation 
Ø Programmation 
Le 
processus 
c’est 
un 
ensemble 
d’étapes 
réalisées 
pour 
atteindre 
un 
but 
précis. 
Dans 
les 
processus 
de 
développement 
de 
système 
e-­‐business 
on 
distingue 
deux 
grandes 
dimensions 
: 
une 
dimension 
managériale 
et 
technique. 
• Tâches 
managériales 
: 
L’aspect 
managérial 
englobe 
tout 
ce 
qui 
concerne 
la 
gestion 
de 
projet, 
on 
va 
le 
retrouver 
dans 
les 
projets 
de 
toute 
nature. 
On 
retrouve 
là 
dedans 
des 
taches 
de 
planification, 
de 
gestion 
des 
risques, 
de 
gestion 
des 
ressources, 
et 
de 
gestion 
de 
la 
qualité, 
entre 
autres. 
Exemple 
de 
tâches 
managériales 
: 
planification 
des 
activités, 
constitution 
d’une 
équipe 
• Tâches 
techniques 
: 
Elles 
contribuent 
directement 
à 
la 
production 
du 
produit 
final. 
On 
y 
retrouve 
par 
exemple 
la 
spécification 
du 
système, 
la 
modélisation 
et 
la 
programmation.
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
Parallèle 
avec 
la 
construction 
d’une 
maison 
: 
tracer 
des 
plans 
pour 
le 
bâtiment, 
le 
gros 
oeuvre, 
etc. 
sont 
des 
taches 
techniques 
mais 
au 
niveau 
managérial, 
on 
réalise 
plutôt 
des 
activités 
comme 
le 
suivi 
budgétaire 
etc. 
Autrement 
dit, 
un 
processus 
est 
un 
ensemble 
d’activités 
coordonnées 
(tâches 
techniques 
et 
managériales/de 
gestion 
de 
projet) 
pour 
atteindre 
un 
but 
: 
le 
projet 
informatique 
(application 
d’un 
processus 
donné 
pour 
développer 
un 
système 
d’information). 
Le 
processus 
va 
spécifier 
: 
• les 
phases 
du 
projet 
et 
son 
cycle 
de 
développement 
; 
• les 
tâches 
à 
réaliser 
au 
sein 
de 
chacune 
des 
phases 
et 
leur 
enchaînement 
dans 
le 
6 
Exemple 
de 
tâches 
: 
modélisation 
du 
système 
à 
construire, 
programmation 
Développement 
de 
systèmes 
e-­‐business 
temps 
; 
• les 
produits 
à 
produire 
et 
fournir 
et 
• les 
différents 
rôles 
à 
assumer 
TYPES 
DE 
PROCESSUS 
• Processus 
inexistant 
Just 
do 
it 
! 
Certains 
projets 
sont 
réalisés 
sans 
processus. 
Par 
exemple 
si 
on 
doit 
développer 
un 
petit 
site 
web, 
on 
ne 
va 
pas 
mettre 
en 
activité 
un 
processus 
long, 
on 
va 
directement 
produire 
le 
site. 
Dés 
qu’on 
s’engage 
dans 
un 
projet 
plus 
important, 
2 
manières 
de 
travailler 
: 
processus 
prescriptif 
ou 
adaptatif. 
• Processus 
prescriptifs 
o planification 
complète 
des 
activités 
puis 
exécution 
du 
plan 
o les 
activités 
sont 
réalisées 
une 
seule 
fois 
en 
séquence 
o vue 
globale 
du 
projet 
dès 
le 
départ 
mais 
travail 
de 
révision 
potentiel 
en 
cas 
de 
changements 
Analogie 
avec 
le 
blocus: 
si 
on 
travaille 
selon 
un 
processus 
prescriptif, 
on 
va 
planifier 
notre 
blocus 
et 
session 
d’examen 
de 
manière 
précise 
et 
jusqu’au 
bout, 
on 
sait 
combien 
de 
temps 
d’étude 
on 
a 
prévu 
pour 
chaque 
cours, 
chaque 
jour. 
On 
connait 
toutes 
les 
tâches 
à 
réaliser, 
l’objectif 
à 
atteindre, 
mais 
ce 
processus 
n’intègre 
pas 
facilement 
le 
changement. 
Si 
on 
est 
malade 
et 
qu’on 
ne 
sait 
pas 
travailler 
le 
3ème 
jour, 
on 
doit 
tout 
re-­‐planifier 
pour 
s’adapter 
au 
changement.
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
7 
Thierry 
Van 
den 
Berghe 
• Processus 
adaptatifs 
o planification 
réduite 
et 
gestion 
intégrant 
le 
changement 
o des 
itérations 
répètent 
certaines 
activités 
plusieurs 
fois 
§ Exemple 
: 
plusieurs 
prototypes 
successifs 
sont 
construits 
et 
évalués 
jusqu'à 
répondre 
correctement 
à 
la 
demande 
de 
l'utilisateur 
§ Exemple 
: 
méthodes 
Agile 
C’est 
la 
tendance 
ces 
dernières 
années. 
On 
va 
avoir 
une 
planification 
générale 
et 
peu 
détaillée, 
les 
grandes 
phases 
sont 
détaillées 
mais 
la 
planification 
détaillée 
n’intervient 
qu’à 
très 
court 
terme, 
pour 
quelques 
jours. 
On 
se 
dit 
qu’on 
ne 
sait 
pas 
tout 
connaître 
dés 
le 
départ. 
C’est 
donc 
de 
la 
planification 
à 
court 
terme. 
Pour 
développer 
des 
sites 
web 
ca 
marche 
super 
bien 
car 
c’est 
très 
compliqué 
d’anticiper 
précisément 
les 
attentes 
de 
l’utilisateur, 
elles 
se 
précisent 
au 
fur 
et 
à 
mesure. 
CONTREPIED 
DE 
LA 
PLANIFICATION 
: 
METHODES 
AGILE 
Principe 
des 
méthodes 
Agile: 
les 
besoins 
des 
utilisateurs, 
le 
processus 
de 
développement 
et 
le 
logiciel 
à 
produire 
émergent 
progressivement 
au 
cours 
du 
projet 
• planification 
peu 
détaillée 
• cycles 
courts 
• système 
découpé 
en 
différents 
modules 
• collaboration 
étroite 
avec 
les 
utilisateurs 
et 
feedback 
immédiat 
è 
accent 
très 
important 
sur 
la 
collaboration 
entre 
l’utilisateur 
et 
l’informaticien 
• livraison 
régulière 
de 
parties 
du 
système 
(exemple 
: 
développement 
du 
module 
« 
présentation 
des 
produits 
», 
puis 
du 
module 
« 
prise 
de 
commande 
», 
puis 
du 
module 
« 
suivi 
des 
commandes 
», 
etc.) 
http://www.agilealliance.org, 
http://www.extremeprogramming.org 
PHASES 
& 
ACTIVITES 
TYPIQUES 
DE 
DEVELOPPEMENT
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
8 
PREMIERE 
PRESENTATION 
DES 
ACTIVITES 
CLES 
Il 
y 
4 
grandes 
phases 
qu’on 
retrouve 
dans 
tous 
les 
cycles 
de 
développement 
: 
1. Comprendre 
le 
problème 
2. Planifier 
une 
solution 
3. Exécuter 
le 
plan 
4. Evaluer 
le 
résultat 
On 
va 
détailler 
les 
activités 
pour 
chacune 
de 
ces 
phases: 
1) 
comprendre 
le 
problème 
: 
Développement 
de 
systèmes 
e-­‐business 
• lancer 
le 
projet 
: 
préciser/déterminer 
les 
objectifs 
principaux 
du 
système 
qu’on 
veut 
construire, 
les 
contraintes, 
les 
ressources 
et 
la 
planification 
du 
projet 
è 
cadrer 
le 
projet 
• étudier 
l'opportunité 
: 
réfléchir 
à 
l’opportunité 
qu’il 
y 
aurait 
de 
lancer 
le 
projet 
: 
retours 
supérieurs 
aux 
investissements 
è 
évaluer 
les 
apports 
et 
décider 
de 
la 
réalisation 
du 
projet 
• spécifier 
le 
système 
(de 
manière 
assez 
détaillée): 
décrire 
les 
facilités 
attendues 
du 
système 
à 
partir 
de 
besoins 
exprimés 
par 
les 
utilisateurs 
2) 
Planifier 
une 
solution 
& 
3) 
Exécuter 
le 
plan 
• concevoir 
et 
mettre 
en 
oeuvre 
le 
système 
(plus 
technique) 
: 
réaliser 
le 
système 
en 
concevant 
d'abord 
la 
solution 
technique 
puis 
programmant 
le 
système 
(choisir 
les 
techniques 
les 
plus 
adaptées) 
• mettre 
en 
production 
: 
transférer 
le 
système 
aux 
utilisateurs 
(réaliser 
le 
système, 
programmer, 
le 
mettre 
en 
production) 
4) 
Evaluer 
le 
résultat 
: 
• tester 
le 
système 
: 
vérifier 
la 
qualité 
et 
corriger 
les 
défauts 
(en 
réalité, 
cette 
activité 
est 
faite 
en 
permanence)
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
9 
2. 
SPECIFICITES 
DES 
PROJETS 
E-­‐BUSINESS 
Thierry 
Van 
den 
Berghe 
• application 
e-­‐business 
o logiciel 
de 
traitement 
de 
données 
accessible 
par 
Internet. 
Visent 
à 
produire 
et 
transformer 
de 
l’information. 
§ exemple 
: 
Web-­‐banking, 
enregistrement 
de 
commandes 
• site 
e-­‐business 
o ensemble 
de 
contenus 
relativement 
stables 
accessibles 
par 
Internet 
§ exemple 
: 
site 
de 
présentation 
d'une 
entreprise 
(site 
vitrine) 
• système 
e-­‐business 
o ensemble 
de 
composants 
accessible 
par 
Internet. 
Ces 
systèmes 
visent 
à 
diffuser 
de 
l’information. 
Par 
contre 
les 
applications 
e-­‐business 
visent 
à 
produire 
et 
transformer 
de 
l’information. 
§ exemple 
: 
système 
combinant 
un 
site 
vitrine 
et 
une 
application 
de 
vente 
EXEMPLES 
D’EXIGENCES 
SPECIFIQUES 
DES 
APPLICATIONS 
E-­‐BUSINESS 
1. Rendre 
une 
application 
attractive 
Surtout 
pour 
les 
applications 
de 
commerce 
électronique. 
Il 
est 
très 
important 
d’avoir 
un 
système 
attractif. 
Il 
faut 
que 
les 
accès 
soient 
adaptés 
à 
des 
profils 
d’utilisateurs 
variés 
• Exemple 
: 
le 
designer 
(ou 
un 
graphiste) 
développe 
des 
maquettes 
de 
site 
• Exemple 
: 
l'ergonome 
améliore 
la 
facilité 
d'utilisation 
d'une 
application 
è 
ergonomie 
= 
facilité 
d’utilisation 
Exemple 
ci-­‐dessus 
: 
Site 
a 
gauche 
peu 
attirant 
et 
a 
droite 
beaucoup 
plus 
dynamique, 
mieux 
foutu, 
l’effort 
d’ergonomie 
et 
plus 
important 
que 
pour 
le 
site 
de 
gauche.
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
Beaucoup 
de 
systèmes 
de 
l’internet 
sont 
à 
diffusion 
mondiale. 
Il 
est 
très 
important 
de 
contrôler 
l’information 
diffusée 
sur 
les 
sites 
web, 
surtout 
quand 
on 
a 
une 
construction 
collaborative 
de 
contenu, 
comme 
dans 
le 
cas 
des 
forums. 
Pour 
les 
sites 
de 
diffusion 
d’informations, 
il 
faut 
définir 
des 
mécanismes 
de 
validation 
des 
contenus, 
de 
contrôle 
des 
différents 
messages 
etc. 
La 
qualité 
d’un 
système 
Web 
dépend 
en 
grande 
partie 
de 
son 
contenu 
10 
2. prévoir 
des 
mécanismes 
de 
contrôle 
collaboratifs 
des 
données 
Développement 
de 
systèmes 
e-­‐business 
• Exemple 
: 
le 
gestionnaire 
de 
contenu 
met 
à 
jour 
les 
news 
d'une 
page 
d'accueil 
• Exemple 
: 
le 
modérateur 
contrôle 
le 
ton 
des 
messages 
postés 
sur 
un 
forum 
3. assurer 
la 
sécurité 
L’Internet 
est 
un 
espace 
public 
accessible 
à 
des 
hackers. 
è 
Au 
départ 
les 
technologies 
de 
l’internet 
n’ont 
pas 
été 
conçues 
pour 
être 
correctement 
sécurisées. 
Il 
existe 
une 
série 
de 
mécanismes 
qui 
sécurisent 
jusqu’à 
un 
certain 
point 
les 
infos 
qui 
circulent 
sur 
le 
net 
mais 
on 
est 
encore 
loin 
de 
la 
perfection. 
Internet 
: 
on 
est 
la 
cible 
potentielle 
de 
milliers 
de 
hackers 
qui 
n’ont 
que 
ca 
à 
faire 
: 
attaquer 
les 
systèmes 
etc. 
On 
n’a 
pas 
droit 
à 
l’erreur, 
si 
un 
pirate 
rentre 
sur 
notre 
système 
les 
effets 
peuvent 
être 
désastreux. 
• Exemple 
: 
un 
expert 
sécurité 
met 
en 
place 
des 
protections 
contre 
le 
piratage 
4. assurer 
la 
performance 
Dans 
le 
cas 
des 
systèmes 
orientés 
réseau 
et 
massivement 
multi-­‐utilisateurs, la 
charge 
d’un 
système 
est 
imprévisible 
et 
peut 
être 
très 
variable 
au 
cours 
du 
temps, 
surtout 
dans 
le 
cas 
d’un 
site 
de 
vente 
en 
ligne. 
On 
ne 
sait 
pas 
dire 
combien 
d’utilisateurs 
vont 
utiliser 
notre 
système 
en 
même 
temps. 
Cela 
peut 
lancer 
des 
problèmes 
de 
performance 
critiques 
(exemple 
: 
on 
lance 
une 
super 
promo, 
des 
tonnes 
de 
clients 
prennent 
le 
site 
d’assaut 
et 
cela 
crée 
des 
problèmes, 
parfois 
même 
pour 
une 
durée 
très 
courte). 
Faut 
il 
investir 
en 
infrastructure 
pour 
faire 
face 
à 
cela 
? 
Le 
débat 
n’est 
pas 
évident. 
• Exemple 
: 
un 
web 
master 
adapte 
l’infrastructure 
en 
fonction 
du 
trafic
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
11 
3. 
CYCLE 
DE 
DEVELOPPEMENT 
D’UN 
LOGICIEL 
• le 
développement 
d’un 
logiciel 
est 
progressif 
o la 
complexité 
impose 
une 
découpe 
o un 
projet 
est 
souvent 
organisé 
en 
phases 
o une 
phase 
est 
le 
lieu 
d’activités 
Thierry 
Van 
den 
Berghe 
Le 
développement 
est 
progressif. 
Pourquoi 
? 
Aujourd’hui 
les 
demandes 
des 
utilisateurs 
et 
les 
technologies 
qu’on 
veut 
mettre 
en 
place 
sont 
tellement 
complexes 
qu’on 
doit 
structurer 
en 
différentes 
phases. 
• le 
cycle 
de 
développement 
précise 
les 
interrelations 
entre 
les 
phases 
: 
o dans 
quel 
ordre 
et 
à 
quelle 
fréquence 
exécuter 
les 
phases? 
o quels 
critères 
pour 
passer 
d’une 
phase 
à 
l’autre? 
o quels 
délivrables 
pour 
chaque 
phase? 
Le 
cycle 
de 
développement 
précise 
les 
interrelations 
entre 
les 
différentes 
phases. 
Dans 
quel 
ordre 
enchainer 
les 
phases 
? 
Faut-­‐il 
exécuter 
les 
phases 
plusieurs 
fois 
? 
Qu’est 
ce 
qui 
déclenche 
le 
passage 
d’une 
phase 
à 
l’autre, 
etc. 
CYCLE 
DE 
DEVELOPPEMENT 
EN 
CASCADE 
Cycle 
de 
développement 
en 
cascade 
: 
On 
enchaine 
les 
différentes 
phases, 
une 
seule 
fois 
: 
l’output 
est 
déversé 
en 
tant 
qu’input 
dans 
la 
phase 
suivante. 
On 
enchaine 
de 
manière 
linéaire 
Ø la 
spécification 
du 
système 
Ø la 
conception 
du 
système 
Ø la 
mise 
en 
oeuvre 
du 
système 
Ø le 
test 
du 
système 
Ø la 
mise 
en 
production 
du 
système
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
1. Ce 
cycle 
en 
cascade, 
en 
une 
seule 
séquence 
n’est 
pas 
très 
réaliste, 
essentiellement 
parce 
que 
la 
spécification 
du 
système 
(= 
la 
description 
des 
attentes 
de 
l’utilisateur) 
n’a 
lieu 
qu’à 
la 
première 
étape 
puis 
qu’on 
n’y 
retourne 
pas. 
Cela 
suppose 
que 
l’utilisateur 
connaît 
exactement 
ses 
attentes 
et 
qu’elles 
n’évoluent 
pas, 
ça 
ne 
se 
passe 
pas 
comme 
cela 
dans 
la 
réalité. 
Il 
est 
difficile 
pour 
les 
utilisateurs 
et 
les 
spécialistes 
de 
cerner 
les 
besoins, 
en 
outre, 
dans 
un 
environnement 
changeant, 
ces 
besoins 
sont 
instables. 
Pour 
finir, 
les 
systèmes 
à 
construire 
sont 
complexes. 
• lourdeur 
des 
tests 
concentrés 
en 
fin 
de 
cycle 
• les 
risques 
restent 
présents 
très 
tard 
dans 
le 
projet, 
car 
peu 
de 
tests 
en 
début 
de 
12 
EVALUATION 
DU 
CYCLE 
EN 
CASCADE 
2. Mise 
en 
production 
selon 
un 
mode 
"big 
bang" 
Développement 
de 
systèmes 
e-­‐business 
projet 
3. Limité 
aux 
projets 
réduits 
en 
taille 
et 
en 
durée 
de 
développement 
PLUSIEURS 
APPROCHES 
POUR 
MAITRISER 
LA 
COMPLEXITE 
Pour 
maitriser 
la 
complexité 
d’un 
développement, 
il 
existe 
plusieurs 
approches 
possibles. 
Ø Diviser 
le 
problème 
: 
Le 
projet 
est 
subdivisé 
en 
sous-­‐projets 
portant 
sur 
le 
développement 
d'une 
partie 
du 
système 
(module). 
Les 
modules 
sont 
développés 
dans 
le 
cadre 
d’une 
itération. 
è 
Cycles 
de 
développement 
itératifs. 
è 
Quand 
le 
problème 
a 
résoudre 
est 
très 
ardu, 
on 
peut 
essayer 
de 
diviser 
le 
système 
e-­‐ 
business 
en 
différents 
modules 
: 
un 
module 
de 
vente, 
un 
module 
de 
suivi 
de 
commande, 
un 
module 
de 
facturation, 
etc. 
Ensuite 
on 
développe 
ces 
modules 
les 
uns 
derrières 
les 
autres. 
On 
parle 
de 
cycle 
de 
développement 
itératif 
: 
on 
re-­‐parcours. 
Ø Résoudre 
le 
problème 
en 
plusieurs 
passes 
: 
Deuxième 
approche 
pour 
maitriser 
la 
complexité 
: 
retravailler 
plusieurs 
fois 
le 
système 
ou 
des 
parties 
du 
système. 
Jusqu’au 
moment 
ou 
on 
obtient 
un 
système 
ou 
sous 
système 
qui 
donne 
satisfaction. 
Le 
système 
est 
construit 
en 
plusieurs 
passes 
jusqu’à 
être 
utilisable. 
è 
Prototypage 
(très 
bien) 
Ø le 
choix 
de 
l’approche 
dépend 
de 
la 
complexité 
du 
problème 
mais 
des 
coûts 
s’ajoutent 
en 
termes 
de 
gestion 
de 
projet
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
13 
Possible 
de 
combiner 
ces 
deux 
approches 
mais 
il 
n’y 
a 
pas 
d’approche 
figée, 
universelle. 
Thierry 
Van 
den 
Berghe 
è 
Adaptation 
en 
fonction 
des 
particularités 
etc. 
ITERATION 
L’application 
du 
cycle 
en 
cascade 
sur 
un 
module 
produit 
un 
délivrable 
testable 
et 
dure 
typiquement 
2 
à 
6 
semaines. 
Itération 
: 
c’est 
le 
parcours 
de 
quelques 
phases 
clés 
è 
ce 
parcours 
peut 
être 
répété 
a 
chaque 
itération. 
Les 
itérations 
sont 
répétées 
un 
certain 
nombre 
de 
fois 
en 
fonction 
de 
la 
complexité 
et 
l’importance 
du 
système. 
Les 
premières 
itérations 
portent 
sur 
les 
aspects 
les 
plus 
risqués 
du 
système 
Si 
je 
divise 
mon 
système 
en 
différents 
modules 
je 
vais 
avoir 
une 
itération 
par 
module 
è 
peuvent 
être 
répétées 
si 
on 
veut 
construire 
le 
système 
morceau 
par 
morceau 
ou 
le 
construire 
en 
plusieurs 
passes 
(parce 
que 
super 
compliqué) 
Exemples 
d’activités 
reprises 
dans 
une 
itération 
: 
-­‐ analyse 
(étude 
des 
besoins) 
+ 
conception 
+ 
mise 
en 
oeuvre 
(programmation) 
ou 
-­‐ collecte 
des 
besoins 
+ 
analyse 
+ 
conception 
+ 
mise 
en 
oeuvre 
+ 
test 
On 
répète 
ces 
phases 
au 
sein 
d’une 
itération 
MAITRISE 
PROGRESSIVE 
DES 
RISQUES 
Idée 
: 
en 
travaillant 
par 
itération 
on 
maitrise 
mieux 
les 
risques.
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
L’idée 
du 
cycle 
itératif 
est 
de 
ne 
pas 
développer 
tout 
le 
système 
en 
une 
fois, 
mais 
de 
le 
découper 
en 
plusieurs 
modules 
et 
de 
le 
livrer 
en 
plusieurs 
fois 
14 
CYCLE 
ITERATIF 
Développement 
de 
systèmes 
e-­‐business 
è 
développement 
modulaire 
: 
• le 
système 
est 
décomposé 
en 
modules 
• les 
modules 
sont 
produits 
et 
testés 
à 
sein 
d’une 
itération 
• les 
modules 
sont 
intégrés 
progressivement 
dans 
le 
système 
final 
Les 
itérations 
sont 
organisées 
en 
cascade 
et 
durent 
peu 
de 
temps, 
ce 
qui 
assure 
une 
certaine 
stabilité. 
PROTOTYPAGE
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
On 
peut 
combiner 
décomposition 
et 
prototypage 
et, 
par 
exemple, 
faire 
travailler 
des 
équipes 
en 
parallèle. 
15 
DECOMPOSITION 
+ 
PROTOTYPAGE 
Thierry 
Van 
den 
Berghe 
è 
Exécution 
parallèle 
des 
itérations, 
etc. 
c’est 
très 
bien 
mais 
cela 
a 
un 
cout 
en 
terme 
de 
gestion 
de 
projet.
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
16 
2. 
LANCEMENT 
DU 
PROJET 
Développement 
de 
systèmes 
e-­‐business 
Un 
projet 
est 
souvent 
initié 
par 
les 
utilisateurs 
qui 
éprouvent 
un 
nouveau 
besoin 
ou 
qui 
identifient 
une 
opportunité 
d’affaire. 
Par 
exemple, 
suite 
à 
un 
besoin 
de 
communication 
en 
interne 
on 
lancera 
un 
projet 
intranet 
ou 
encore 
suite 
à 
l’identification 
d’une 
opportunité 
de 
vente 
à 
distance, 
on 
lancera 
un 
projet 
de 
boutique 
Web. 
èEn 
général 
la 
plupart 
des 
initiatives 
proviennent 
des 
collaborateurs 
de 
l’entreprise 
qui 
trouvent 
qu’une 
automatisation 
complémentaire 
serait 
bénéfique. 
Il 
faut 
vérifier 
si 
le 
projet 
réalise 
la 
vision 
et 
la 
stratégie 
de 
l’entreprise. 
Par 
exemple, 
si 
l’objectif 
stratégique 
de 
l’entreprise 
est 
la 
maximisation 
des 
compétences 
internes, 
un 
projet 
qui 
rentre 
dans 
le 
cadre 
serait 
celui 
d’un 
intranet 
sur 
lequel 
partager 
les 
connaissances. 
è 
L’initiateur 
du 
projet 
va 
devoir 
le 
défendre 
devant 
un 
décideur. 
L’alignement 
stratégique 
est 
important 
dans 
ce 
cadre. 
Qu’est 
ce 
qu’implique 
les 
taches 
managériales 
de 
gestion 
de 
projet 
? 
Le 
lancement 
d’un 
projet 
implique 
3 
choses 
: 
Ø cadrer 
le 
système 
(QUOI) 
è 
définition 
de 
la 
portée 
du 
système 
: 
Que 
veut 
on 
exactement 
? 
Ø identifier 
les 
ressources 
(QUI) 
è 
gestion 
des 
acteurs 
: 
Qui 
va 
être 
impliqué 
dans 
le 
développement 
à 
tous 
les 
niveaux 
? 
Ø planifier 
les 
tâches 
(QUAND 
et 
COMMENT) 
è 
gestion 
du 
projet 
è 
La 
planification 
des 
tâches 
va 
déterminer 
l’ordonnancement 
du 
projet 
Les 
activités 
liées 
au 
lancement 
de 
projet 
se 
retrouvent 
dans 
des 
projets 
d’autre 
nature 
que 
projet 
de 
développement 
e-­‐business
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
17 
1. 
DEFINITION 
DE 
LA 
PORTEE 
DU 
SYSTEME 
E-­‐BUSINESS 
Thierry 
Van 
den 
Berghe 
Objectifs 
: 
Ø Montrer 
comment 
le 
projet 
rencontre 
les 
préoccupations 
de 
l’entreprise, 
comment 
le 
système 
réalise 
les 
objectifs 
stratégiques 
de 
l’organisation 
en 
fonction 
des 
contraintes 
Ø Positionner 
le 
futur 
système 
dans 
la 
chaine 
de 
valeur 
de 
l’organisation 
On 
a 
le 
département 
vente 
et 
on 
estime 
qu’un 
site 
de 
vente 
en 
ligne 
pourrait 
améliorer 
la 
valeur 
apportée 
par 
ce 
département. 
Ø Elaborer 
une 
description 
suffisante 
du 
système 
pour 
une 
première 
estimation 
de 
l’effort 
de 
développement 
è 
Imaginer 
le 
futur 
système 
(allure 
du 
futur 
site 
de 
vente 
ou 
autre) 
pour 
pouvoir 
déterminer 
une 
estimation 
de 
cout 
(combien 
cela 
coute 
et 
rapporte 
?) 
Activités 
: 
Ø Décrire 
le 
contexte 
et 
la 
motivation 
du 
système 
(métier 
de 
l’organisation, 
objectifs 
stratégiques, 
etc.) 
Ø Identifier 
les 
objectifs, 
les 
contraintes, 
les 
fonctions 
et 
la 
cible 
du 
système 
Ø Identifier 
la 
valeur 
apportée 
par 
le 
système 
EXEMPLE 
: 
EM2 
Document 
de 
cadrage 
de 
projet, 
on 
veut 
motiver 
notre 
idée 
è 
on 
va 
spécifier 
le 
contexte 
et 
la 
motivation 
Contexte 
et 
motivation: 
Ø un 
détaillant 
d’électroménagers, 
EM2, 
gère 
son 
service 
après-­‐vente 
(SAV) 
manuellement 
et 
sans 
procédures 
claires. 
EM2 
fournit 
peu 
d’informations 
aux 
clients 
après 
la 
vente 
(conseils 
d’utilisation, 
etc.) 
Ø EM2 
a 
pour 
objectif 
stratégique 
de 
fidéliser 
sa 
clientèle. 
Pour 
cela, 
elle 
souhaite 
augmenter 
la 
valeur 
de 
son 
SAV 
en 
proposant 
une 
meilleure 
information 
à 
sa 
clientèle 
et 
en 
coordonnant 
le 
travail 
de 
l’équipe 
SAV 
è 
projet 
de 
développement 
d’un 
système 
e-­‐business 
pour 
le 
SAV 
Ici 
: 
idée 
d’automatisation 
d’un 
service 
après 
vente 
(SAV) 
pour 
une 
chaine 
de 
magasin 
qui 
vend 
de 
l’électroménager. 
On 
précise 
l’objectif 
qui 
est 
augmenter 
la 
valeur 
du 
service 
après 
vente 
en 
proposant 
une 
meilleure 
information 
a 
la 
clientèle 
et 
en 
coordonnant 
mieux 
le 
travail 
de 
l’équipe. 
Cette 
motivation 
s’inscrit 
dans 
un 
objet 
de 
l’entreprise 
qui 
pourrait 
être 
de 
fidéliser 
la 
clientèle. 
Un 
SAV 
de 
meilleure 
qualité 
va 
contribuer 
à 
rendre 
le 
client 
plus 
content 
(è 
fidélisation).
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
18 
Développement 
de 
systèmes 
e-­‐business 
è 
On 
voit 
comment 
ce 
projet 
de 
développement 
rentre 
dans 
ces 
préoccupations 
de 
haut 
niveau 
de 
l’entreprise 
Objectifs 
du 
système 
: 
Qu’est 
ce 
qu’on 
attend 
de 
ce 
système 
dans 
les 
grandes 
lignes 
? 
Ø informer 
le 
client 
après 
l’achat 
Ø formaliser 
la 
gestion 
des 
réparations 
è 
Objectifs 
qui 
restent 
assez 
génériques 
mais 
on 
va 
les 
détailler 
Les 
contraintes 
du 
projet 
: 
Ø budget: 
26000€/délais: 
6mois 
Ø ressources 
internes 
: 
limitées 
au 
responsable 
du 
SAV 
Après 
on 
peut 
passer 
dans 
une 
description 
plus 
détaillée 
de 
ce 
qu’on 
attend 
du 
système, 
ici 
on 
reste 
vague. 
Les 
fonctions 
du 
système 
: 
Ø publier 
les 
modes 
d’emploi 
des 
appareils 
vendus 
Ø publier 
des 
FAQ 
alimentés 
par 
les 
réparateurs 
Ø automatiser 
la 
planification 
des 
demandes 
de 
réparation 
chez 
le 
client 
Ø tracer 
les 
étapes 
des 
réparations 
en 
magasin 
Cible 
: 
Ø réparateur 
SAV 
Ø clients 
è 
On 
veut 
connaitre 
la 
cible 
du 
système 
: 
ici 
les 
clients 
et 
les 
réparateurs 
du 
SAV 
sont 
ceux 
qui 
vont 
exploiter 
cette 
plateforme. 
Il 
faut 
ensuite 
identifier 
des 
catégories 
de 
clients 
pour 
un 
site 
de 
vente 
en 
ligne 
è 
Clients 
dans 
la 
catégorie 
professionnelle 
etc. 
C’est 
important 
pour 
personnaliser 
le 
système 
par 
rapport 
aux 
segments 
de 
clientèle. 
La 
valeur 
du 
système 
est 
attendue 
à 
2 
niveaux 
: 
Ø client 
: 
accompagnement 
après 
l’achat, 
rapidité 
et 
transparence 
dans 
l’organisation 
des 
réparations 
Ø réparateurs 
SAV 
: 
partage 
et 
centralisation 
de 
la 
connaissance 
en 
interne, 
meilleure 
coordination 
des 
réparations
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
Dans 
quelle 
mesure 
le 
système 
va 
contribuer 
à 
apporter 
de 
la 
valeur 
pour 
le 
client 
et 
l’entreprise. 
Exemple 
: 
au 
niveau 
des 
réparateurs 
meilleure 
organisation 
dans 
la 
planification 
des 
réparations. 
19 
Thierry 
Van 
den 
Berghe 
è 
Grâce 
à 
des 
fiches 
de 
suivi 
dans 
les 
réparations. 
2. 
GESTION 
DES 
ACTEURS 
Objectifs 
: 
maximiser 
les 
chances 
de 
réussite 
du 
projet 
en 
mobilisant 
et 
en 
gérant 
les 
ressources 
les 
plus 
adaptées 
Réfléchir 
sur 
les 
acteurs 
: 
Le 
projet 
va 
être 
pris 
en 
charge 
par 
une 
équipe. 
Même 
dans 
un 
projet 
de 
haute 
technologie, 
les 
personnes 
sont 
souvent 
un 
problème 
è 
il 
est 
crucial 
(Facteur 
Clé 
de 
Succès) 
de 
constituer 
une 
équipe 
compétente 
qui 
fonctionne 
bien. 
Pour 
ce, 
il 
y 
a 
des 
tâches 
à 
réaliser 
: 
Ø identifier 
les 
compétences 
et 
rôles 
(lister 
les 
compétences 
nécessaires, 
elles 
sont 
multiples 
è 
Impose 
des 
profils 
techniques 
très 
variés) 
Ø désigner 
les 
acteurs 
du 
projet 
et 
constituer 
une 
équipe 
(une 
fois 
les 
rôles 
à 
remplir 
listés, 
les 
assigner 
à 
des 
personnes 
disponibles) 
Ø gérer 
l’équipe 
du 
projet 
(une 
fois 
l’équipe 
constituée 
il 
faut 
la 
gérer) 
L’EQUIPE 
DE 
PROJET 
: 
UN 
FACTEUR 
CLE 
DU 
SUCCES 
La 
dimension 
humaine 
est 
importante 
dans 
un 
projet 
e-­‐business 
Ø la 
technologie 
n'est 
qu'une 
des 
composantes 
d'un 
projet 
informatique 
Ø les 
problèmes 
humains 
sont 
souvent 
plus 
intenses 
que 
les 
problèmes 
techniques 
Les 
relations 
humaines 
doivent 
être 
soigneusement 
gérées 
Ø construire 
un 
esprit 
d'équipe 
et 
une 
relation 
de 
confiance 
Ø veiller 
à 
la 
bonne 
communication 
entre 
utilisateurs 
et 
informaticiens 
Ø gérer 
pro-­‐activement 
les 
conflits 
Le 
courant 
doit 
passer, 
l’équipe 
doit 
fonctionner 
etc. 
è 
La 
dimension 
humaine 
est 
vraiment 
cruciale. 
On 
tente 
de 
gérer 
pro-­‐activement 
l’équipe, 
gérer 
les 
conflits, 
etc. 
Une 
gestion 
proactive 
des 
ressources 
humaines 
est 
tout 
à 
fait 
essentielle.
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
nombreux 
rôles 
et 
équipe 
La 
particularité 
des 
développements 
e-­‐business 
c’est 
que 
pour 
qu’un 
site 
de 
vente 
en 
ligne 
soit 
attractif 
par 
exemple, 
on 
a 
besoin 
de 
beaucoup 
de 
compétences. 
Des 
spécialistes 
en 
Base 
De 
Données, 
en 
sécurité, 
des 
ergonomes 
sont 
des 
besoins. 
Exemple 
: 
conception 
de 
la 
charte 
graphique, 
design 
d'un 
site, 
20 
EQUIPE 
D’UN 
PROJET 
E-­‐BUSINESS 
Un 
projet 
e-­‐business 
comporte 
de 
nombreuses 
dimensions 
è 
pluridisciplinaire. 
Par 
exemple, 
un 
site 
de 
vente 
doit 
être 
attractif 
è 
besoins 
de 
compétences 
artistiques 
etc. 
Développement 
de 
systèmes 
e-­‐business 
Catégories 
d'acteurs 
: 
Ø utilisateurs 
: 
spécialistes 
métier 
Ø informaticiens 
: 
spécialistes 
des 
TIC 
Ø experts 
: 
apport 
ponctuel 
de 
compétences 
de 
pointe 
Ø sponsor 
: 
apport 
du 
financement 
ACTEURS 
PRINCIPAUX 
D’UN 
PROJET 
E-­‐BUSINESS
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
21 
Catégories 
d’acteurs 
qu’on 
retrouve 
dans 
la 
plupart 
des 
projets 
e-­‐business 
: 
Thierry 
Van 
den 
Berghe 
Ø Utilisateurs 
: 
Compétences 
: 
ils 
connaissent 
parfaitement 
leur 
métier. 
On 
les 
appelle 
les 
spécialistes 
du 
domaine 
d’application 
(métier, 
situation 
concrète 
pour 
lequel 
on 
utilise 
la 
technologie 
de 
l’information) 
Ø Sponsors 
: 
C’est 
celui 
qui 
libère 
les 
fonds, 
pas 
d’implication 
directe 
dans 
le 
projet, 
mais 
il 
donne 
son 
aval 
pour 
l’engagement 
de 
budget. 
Ø Informaticiens 
: 
Ce 
sont 
les 
spécialistes 
des 
technologies. 
On 
a 
pleins 
de 
déclinaisons 
: 
chef 
de 
projet, 
analyste, 
programmeurs, 
designer, 
ergonome, 
etc. 
Ø Experts 
Ils 
apportent 
une 
compétence 
pointue 
à 
un 
moment 
donné. 
L’expert 
en 
sécurité, 
par 
exemple, 
s’assure 
du 
niveau 
de 
sécurité 
raisonnable 
du 
système. 
Le 
qualiticien 
est 
responsable 
qualité, 
c’est 
quelqu’un 
qui 
aide 
le 
chef 
de 
projet 
à 
gérer 
la 
qualité. 
Quel 
peut 
être 
le 
niveau 
d’intervention 
d’un 
juriste 
dans 
un 
projet 
e-­‐business 
? 
Si 
on 
développe 
des 
sites 
qui 
collectent 
des 
données 
à 
caractère 
personnel 
par 
exemple, 
un 
juriste 
sera 
nécessaire. 
Le 
juriste 
sera 
également 
utile 
lors 
de 
la 
rédaction 
d’un 
contrat 
de 
service 
è 
par 
exemple 
dans 
le 
cas 
de 
développement 
IT 
fait 
en 
extérieur, 
il 
est 
important 
de 
rédiger 
un 
contrat 
en 
bonne 
et 
due 
forme. 
CHEF 
DE 
PROJET 
Le 
chef 
de 
projet 
conduit 
le 
projet 
Ø Il 
planifie, 
désigne 
les 
personnes 
et 
assigne 
les 
responsabilités 
Ø Il 
surveille 
le 
déroulement 
et 
prend 
des 
mesures 
correctives 
Ø Il 
rapporte 
au 
management 
Le 
chef 
de 
projet 
dispose 
de 
compétences 
managériales 
plutôt 
que 
techniques 
Ø gestion 
d'équipe, 
coordination 
d’équipe 
Ø facultés 
d'écoute 
et 
de 
compréhension 
Ø esprit 
de 
décision 
Ø sens 
de 
l'organisation 
Ø autorité 
Ø culture 
générale 
de 
la 
technologie
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
22 
EXEMPLE 
DE 
PROFILS 
DE 
CHEF 
DE 
PROJET 
3. 
GESTION 
DE 
PROJET 
Objectif: fournir 
un 
support 
organisationnel 
à 
la 
réalisation 
d'un 
projet 
Tâches 
Développement 
de 
systèmes 
e-­‐business 
principales: 
Ø préparer 
le 
projet 
o identifier 
et 
planifier 
les 
tâches 
du 
projet 
o assigner 
les 
ressources 
o déterminer 
les 
contraintes 
du 
projet 
Ø suivre 
le 
projet 
(pendant 
les 
phases 
ultérieures) 
o contrôler 
l’avancement 
de 
projet 
et 
éventuellement 
prendre 
des 
mesures 
correctives 
o capitaliser 
l’expérience 
RESULTAT 
SOUS 
CONTRAINTES 
Un 
projet 
doit 
fournir 
un 
système 
de 
qualité 
fixée 
sous 
contraintes.
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
23 
TECHNIQUES 
DE 
PLANIFICATION 
Ø Intention 
: 
planifier 
et 
synchroniser 
plusieurs 
tâches 
interdépendantes 
Thierry 
Van 
den 
Berghe 
réalisées 
par 
des 
acteurs 
Ø Diagramme 
de 
Gantt 
(1917) 
è 
présentation 
graphique 
des 
tâches 
dans 
un 
calendrier 
Ø PERT 
: 
Program 
Evaluation 
and 
Review 
Technique 
(US-­‐ 
Navy, 
50') 
o présentation 
graphique 
des 
relations 
entre 
tâches 
o marge 
totale 
: 
intervalle 
de 
temps 
pendant 
lequel 
une 
tâche 
peut 
être 
différée 
sans 
différer 
la 
date 
de 
fin 
du 
projet 
o chemin 
critique 
: 
séquence 
de 
tâches 
pour 
lesquelles 
une 
modification 
de 
durée 
entraîne 
une 
modification 
de 
la 
durée 
du 
projet 
EXEMPLE 
DE 
GANTT 
AVEC 
CHEMIN 
CRITIQUE
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
ne 
peuvent 
être 
rallongées 
ou 
différées 
sous 
peine 
de 
ces 
tâches 
ont 
une 
marge. 
Prenons 
le 
cas 
d’une 
tâche 
avec 
une 
marge 
importante, 
on 
pourra 
la 
réaliser 
plus 
loin 
dans 
le 
processus 
par 
exemple, 
sans 
que 
la 
date 
de 
fin 
du 
projet 
ne 
soie 
impactée. 
24 
Tâches 
en 
rouge 
: 
tâches 
critiques 
è 
retarder 
l’ensemble 
du 
projet. 
Les 
tâches 
critiques 
n’ont 
aucune 
marge. 
Tâches 
en 
bleu 
: 
tâches 
non-­‐critiques 
è 
EXEMPLE 
D’ALLOCATION 
ETUDE 
DE 
CAS 
: 
SPORTS 
D’HIVERS 
Développement 
de 
systèmes 
e-­‐business
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
25 
Thierry 
Van 
den 
Berghe 
Contexte 
et 
motivation: 
Ø la 
promotion 
et 
la 
prise 
d'inscription 
aux 
SH 
prennent 
beaucoup 
de 
temps 
car 
ces 
deux 
opérations 
sont 
complètement 
manuelles. 
Chaque 
année, 
il 
faut 
recommencer 
les 
mêmes 
actions 
sans 
pouvoir 
réutiliser 
les 
acquis 
des 
années 
précédentes 
(affichage, 
etc.) 
Ø le 
cercle 
des 
étudiants 
s'est 
fixé 
comme 
objectif 
stratégique 
de 
soutenir 
davantage 
les 
étudiants 
en 
difficulté 
(scolaire, 
financière, 
etc.). 
Comme 
le 
cercle 
connait 
des 
problèmes 
de 
recrutement 
récurrents, 
il 
compte 
sur 
davantage 
d'automatisation 
pour 
soutenir 
sa 
stratégie 
et 
recentrer 
l'équipe 
sur 
des 
projets 
où 
les 
personnes 
ont 
une 
valeur 
ajoutée 
importante 
Ø l'organisation 
des 
SH 
est 
actuellement 
manuelle 
et 
consomme 
beaucoup 
de 
main 
d'oeuvre 
è 
lancement 
d'un 
projet 
de 
développement 
d’un 
système 
e-­‐business 
pour 
la 
gestion 
des 
SH 
Objectifs 
du 
système 
: 
Ø présenter 
l'offre 
de 
SH 
du 
cercle 
Ø promouvoir 
l'offre 
de 
SH 
du 
cercle 
Ø suivre 
les 
inscriptions 
des 
étudiants 
participants 
Les 
contraintes 
du 
projet 
: 
Ø budget: 
1000€/délais: 
6 
mois 
Ø ressources 
internes 
: 
l'équipe 
du 
cercle 
et, 
ponctuellement, 
le 
service 
informatique 
de 
l'école 
Les 
fonctions 
du 
système 
: 
Ø présentation 
de 
l'offre 
o publication 
des 
informations 
détaillées 
sur 
le 
voyage 
(Exemple 
: 
destination, 
prix, 
service, 
etc.) 
o publication 
des 
conditions 
générales 
/ 
responsabilité 
(Exemple 
: 
modalités 
de 
paiement, 
désistement, 
assurance, 
etc.) 
o publication 
du 
nombre 
de 
places 
disponibles 
et 
de 
la 
liste 
des 
inscrits 
Ø promotion 
de 
l'offre 
o publication 
électronique 
de 
l'affiche 
d'annonce 
o mailing 
de 
prospection 
auprès 
des 
étudiants 
non 
inscrits 
Ø suivi 
des 
inscriptions 
des 
étudiants 
participants 
o enregistrement 
d'une 
inscription 
o enregistrement 
d'un 
désistement 
o suivi 
des 
paiements 
o envois 
de 
mails 
de 
confirmation 
d'inscription 
et 
de 
rappel 
de 
paiement
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
26 
Développement 
de 
systèmes 
e-­‐business 
Cible 
: 
Ø étudiants 
Ø gestionnaires 
du 
voyage 
La 
valeur 
du 
système 
est 
attendue 
à 
2 
niveaux 
: 
Ø étudiants 
: 
o disponibilité 
de 
l'information 
o disponibilité 
de 
la 
procédure 
d'inscription/désistement 
o validation 
et 
confirmation 
de 
l'inscription 
Ø gestionnaires 
du 
voyage 
: 
o automatisation 
de 
la 
gestion 
de 
l'inscription 
o suivi 
centralisé 
et 
organisé 
des 
désistements 
et 
des 
paiements 
o automatisation 
de 
la 
communication 
o réutilisation 
du 
système 
d'année 
en 
année 
Rôles 
et 
compétences 
: 
Ø chef 
de 
projet 
o coordonne 
le 
projet 
et 
rapporte 
au 
sponsor 
o sens 
de 
l'organisation, 
disponibilité, 
maîtrise 
de 
MS-­‐Project 
Ø analyste/programmeur 
o collecte 
les 
besoins 
des 
utilisateurs, 
conçoit 
et 
met 
en 
oeuvre 
le 
système 
o maîtrise 
des 
langages 
de 
modélisation 
et 
des 
outils 
de 
développement 
Ø représentant 
utilisateur 
o formule 
les 
attentes 
des 
utilisateurs 
o expérience 
dans 
l'organisation 
des 
SH 
Ø sponsor 
o veille 
à 
l'alignement 
stratégique 
du 
projet 
et 
décide 
de 
la 
libération 
des 
fonds 
Ø hébergeur 
o déploie 
le 
système 
dans 
une 
infrastructure 
WEB 
o compétences 
techniques 
dans 
la 
gestion 
de 
serveurs 
et 
réseaux 
Equipe 
: 
Ø chef 
de 
projet 
: 
Sophie 
souhaite 
s'investir 
dans 
le 
cercle 
et 
a 
une 
expérience 
de 
coordination 
de 
projets 
(mouvement 
de 
jeunesse) 
Ø analyste/programmeur 
: 
Nabil 
est 
bachelier 
en 
informatique 
et 
adore 
la 
programmation
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
Ø représentant 
utilisateur 
: 
Magali 
a 
organisé 
les 
SH 
les 
deux 
années 
précédentes 
Ø sponsor 
: 
Arnaud 
est 
le 
président 
du 
cercle 
des 
étudiants 
Ø hébergeur 
: 
Eric 
gère 
l'infrastructure 
WEB 
de 
l'école 
et 
est 
prêt 
à 
héberger 
27 
Thierry 
Van 
den 
Berghe 
gratuitement 
le 
système 
Planification 
: 
Etude 
de 
cas 
: 
sports 
d’hiver 
è 
Petite 
synthèse 
: 
On 
va 
voir 
ce 
qu’on 
doit 
produire 
comme 
infos 
pour 
définir 
une 
première 
idée 
du 
projet. 
Ici, 
on 
est 
chef 
du 
projet 
et 
responsable 
d’un 
site 
d’inscription 
en 
ligne. 
Ø 1ère 
étape 
: 
Lancement 
du 
projet 
Essayer 
de 
motiver 
le 
projet 
par 
rapport 
aux 
intentions 
et 
objectifs 
stratégiques 
de 
l’entreprise 
(ici 
le 
cercle 
des 
étudiants) 
Ø Priorité 
du 
cercle 
: 
Aider 
les 
étudiants 
qui 
ont 
des 
difficultés 
Par 
rapport 
à 
cet 
objectif, 
on 
veut 
automatiser 
certaines 
activités 
du 
CDE 
pour 
que 
toute 
une 
série 
de 
taches 
qui 
étaient 
réalisées 
manuellement 
puissent 
être 
automatisées. 
On 
va 
développer 
une 
plateforme 
d’enregistrement 
en 
ligne 
pour 
les 
sports 
d’hivers. 
On 
voit 
un 
alignement 
stratégique 
du 
projet 
par 
rapport 
aux 
objectifs 
du 
cercle. 
Ø Objectifs 
du 
système 
: 
Rappel 
: 
un 
projet 
est 
un 
exercice 
de 
maximisation 
du 
résultat 
et 
de 
sa 
qualité 
sous 
contrainte 
(contraintes 
cf. 
slide 
è 
les 
plus 
évidentes 
sont 
celles 
de 
budget 
et 
de 
délai, 
mais 
il 
y 
a 
également 
des 
contraintes 
légales, 
etc.)
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
On 
va 
essayer 
d 
avoir 
une 
première 
description 
de 
l’équipe 
et 
du 
planning 
On 
va 
détailler 
les 
fonctions 
du 
système, 
quelles 
sont 
les 
facilités 
attendues 
de 
ce 
système 
web. 
Un 
aspect 
super 
important 
des 
projets 
e-­‐business 
est 
l’aspect 
humain. 
Les 
problèmes 
les 
plus 
fréquents 
proviennent 
de 
la 
gestion 
des 
personnes. 
De 
ce 
fait, 
l’identification 
des 
rôles 
et 
personnes 
nécessaires 
est 
préconisée. 
Une 
fois 
qu’on 
a 
listé 
les 
rôles 
et 
compétences 
associées, 
on 
peut 
essayer 
de 
constituer 
notre 
équipe. 
Une 
fois 
qu’on 
a 
identifié 
les 
différents 
rôles 
on 
peut 
passer 
a 
la 
planification 
avec 
un 
logiciel. 
On 
part 
d’une 
série 
de 
taches 
interdépendantes 
dans 
le 
temps 
et 
planifiées. 
On 
a 
assigné 
les 
différentes 
taches 
aux 
membres 
de 
l’équipe. 
On 
a 
décomposé 
le 
système 
en 
différents 
modules 
on 
fait 
souvent 
cela 
en 
informatique 
car 
le 
développement 
d’un 
système 
en 
un 
coup 
c'est 
trop 
compliqué, 
donc 
on 
le 
découpe 
en 
différents 
modules, 
on 
le 
découpe 
dans 
l’espace, 
et 
si 
certains 
modules 
sont 
complexes 
à 
mettre 
au 
point 
on 
applique 
une 
technique 
de 
prototypage 
construction 
du 
système 
par 
28 
Ø Cible 
(à 
préciser) 
: 
à 
qui 
s’adresse 
le 
système 
? 
-­‐ Aux 
étudiants 
-­‐ Aux 
responsables 
du 
CDE 
qui 
gèrent 
le 
voyage 
Il 
faut 
motiver 
la 
valeur 
qu’apporte 
ce 
système 
dans 
la 
chaine 
de 
valeur. 
è 
è 
Développement 
de 
systèmes 
e-­‐business 
itérations 
successives. 
Ø 2eme 
étape 
: 
L’étude 
d’opportunité 
(voir 
chapitre 
suivant)
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
29 
3. 
ETUDE 
D’OPPORTUNITE 
Thierry 
Van 
den 
Berghe 
Objectifs 
-­‐ prendre 
la 
décision 
d'engager 
ou 
non 
le 
projet 
(pass 
or 
fail), 
d’engager 
des 
fonds 
dans 
le 
projet 
en 
considérant 
: 
o l'apport 
du 
projet 
è 
voir 
si 
il 
est 
supérieur 
aux 
investissements 
o la 
faisabilité 
du 
projet 
Tâches 
-­‐ 1ère 
étape 
: 
réaliser 
une 
critique 
de 
l'existant 
pour 
identifier 
les 
lacunes 
que 
le 
futur 
système 
pourrait 
combler. 
Si 
il 
y 
a 
un 
système 
déjà 
existant, 
la 
première 
chose 
à 
faire 
pour 
motiver 
le 
nouveau 
projet 
est 
d’identifier 
les 
lacunes 
du 
système 
existant. 
La 
critique 
doit 
être 
constructive, 
l’objectif 
est 
de 
mettre 
des 
lacunes 
en 
évidence 
qu’on 
évitera 
de 
reproduire 
dans 
un 
futur 
système. 
-­‐ 2ème 
étape 
: 
essayer 
de 
réaliser 
une 
étude 
pour 
évaluer 
l'apport 
du 
futur 
système 
o calcul 
du 
retour 
sur 
investissement 
(ROI) 
o évaluation 
en 
terme 
de 
bénéfices 
intangibles 
-­‐ 
3ème 
étape 
: 
évaluer 
la 
faisabilité 
face 
aux 
risques 
1. 
RETOURS 
D’UN 
SYSTEME 
RENTABILITE 
D’UN 
PROJET 
DE 
DEVELOPPEMENT 
Plusieurs 
techniques 
purement 
financières 
• ROI 
= 
bénéfices 
annuels 
/ 
coûts 
annuels 
• valeur 
actuelle 
nette 
– 
VAN, 
taux 
de 
rentabilité 
interne 
– 
TRI, 
etc.
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
La 
difficulté 
c'est 
que 
l’évaluation 
d’un 
retour 
purement 
financier 
est 
souvent 
défavorable 
parce 
que 
souvent 
l’IT 
participe 
aux 
frais 
de 
structure, 
des 
activités, 
etc. 
C’est 
comme 
la 
GRH, 
le 
département 
IT 
n’a 
pas 
un 
apport 
direct 
au 
chiffre 
d’affaires. 
è 
exemple) 
ce 
ne 
sera 
souvent 
pas 
un 
30 
Si 
on 
utilise 
les 
techniques 
habituelles 
(le 
ROI 
par 
argument 
prédominant 
pour 
motiver 
le 
projet. 
Il 
y 
a 
une 
série 
de 
bénéfices 
indirects 
ou 
intangibles 
à 
considérer 
aussi 
Développement 
de 
systèmes 
e-­‐business 
: 
• les 
bénéfices 
intangibles 
o Exemple 
: 
amélioration 
de 
l’image 
de 
marque 
après 
un 
redesign 
d’un 
site 
• les 
opportunités 
offertes 
par 
l'application 
des 
TIC 
o Exemple 
: 
apports 
de 
clients 
étrangers 
grâce 
à 
la 
vente 
en 
ligne 
Exemple 
: 
on 
a 
une 
nouvelle 
plateforme 
intranet, 
on 
peut 
espérer 
a 
terme 
augmenter 
la 
compétence 
et 
productivité 
des 
collaborateurs. 
è 
Ce 
n’est 
pas 
mesurable 
purement 
financièrement. 
On 
va 
quand 
même 
calculer 
un 
ROI, 
même 
si 
il 
est 
négatif 
mais 
on 
va 
compléter 
grâce 
à 
une 
argumentation 
qui 
liste 
tous 
les 
bénéfices 
intangibles 
ou 
indirects 
qu’on 
espère 
retirer 
du 
projet. 
Ex-­‐post, 
une 
fois 
le 
système 
déployé, 
on 
pourra 
vérifier 
après 
une 
période 
de 
mise 
en 
production, 
le 
gain 
en 
chiffre 
d’affaires, 
etc. 
au 
niveau 
global. 
è 
Il 
faut 
essayer 
d’identifier 
les 
couts 
pcq 
c'est 
la 
première 
chose 
qu’on 
demande 
: 
combien 
cela 
coute 
et 
combien 
ca 
rapporte. 
RETOUR 
SUR 
INVESTISSEMENT 
: 
COUTS 
Coûts 
directs 
è 
ce 
sont 
les 
coûts 
identifiables, 
liés 
directement 
au 
SI 
Il 
faut 
intégrer 
les 
couts 
de 
développement 
et 
de 
maintenance 
lorsque 
le 
système 
est 
en 
exploitation. 
• CAPEX 
(capital 
expenditure) 
: 
développement 
logiciel, 
matériel, 
déploiement, 
formation 
• OPEX 
(operational 
expenditure) 
: 
maintenance, 
hébergement, 
support 
cf. 
métrique 
d'évaluation 
d'ampleur 
et 
d'efforts. 
Coûts 
indirects 
è 
ce 
sont 
les 
coûts 
difficilement 
identifiables 
et 
peu 
prévisibles 
Exemple 
: 
correction 
d'erreurs, 
perte 
de 
productivité 
due 
à 
l'apprentissage 
d'un 
nouveau 
système, 
etc.
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
Les 
couts 
indirects 
sont 
plus 
délicats 
à 
évaluer. 
On 
peut 
s’attendre 
à 
une 
perte 
de 
productivité 
les 
premiers 
jours 
ou 
semaine 
de 
la 
mise 
en 
service 
des 
nouveaux 
systèmes 
parce 
que 
l’utilisateur 
doit 
se 
familiariser 
etc. 
31 
è 
pas 
facile 
à 
évaluer. 
RETOUR 
SUR 
INVESTISSEMENT 
: 
BENEFICES 
Thierry 
Van 
den 
Berghe 
Bénéfices 
tangibles 
è 
quantifiables 
• réductions 
des 
coûts 
ou 
augmentation 
des 
bénéfices 
o Exemple 
: 
réduction 
du 
coût 
des 
transactions 
commerciales 
ou 
nouveau 
canal 
de 
vente 
par 
Internet 
Bénéfices 
intangibles 
è 
difficilement 
quantifiables 
• bénéfices 
pour 
l'organisation 
o Exemple 
: 
meilleure 
communication 
entre 
les 
collaborateurs, 
meilleures 
sources 
d'information 
pour 
la 
prise 
de 
décisions, 
meilleure 
ergonomie 
• bénéfices 
pour 
le 
client 
o Exemple 
: 
meilleure 
disponibilité 
de 
l'entreprise, 
meilleure 
information 
sur 
les 
produits 
et 
services 
è 
On 
va 
avoir 
des 
bénéfices 
chiffrables 
ou 
tangibles, 
par 
contre 
on 
va 
en 
avoir 
des 
intangibles, 
difficilement 
chiffrables, 
ils 
doivent 
être 
mentionnés 
mais 
on 
ne 
peut 
pas 
les 
chiffrer 
précisément. 
Exemple 
: 
L’avantage 
pour 
un 
client 
est 
un 
bénéfice 
intangible 
EXEMPLES 
D’APPORTS 
ATTENDUS 
è 
Quelques 
arguments 
classiques 
pour 
motiver 
un 
projet 
e-­‐business. 
Ces 
arguments 
permettent 
de 
convaincre 
que 
le 
projet 
apporte 
vraiment 
de 
la 
valeur 
Améliorer 
l’efficience 
opérationnelle 
• réduire 
les 
coûts 
de 
production 
des 
biens 
vendus 
o Exemple 
: 
vente 
de 
musique 
en 
ligne 
• réduire 
les 
coûts 
de 
vente 
et 
d’administration 
o Exemple 
: 
suppression 
des 
documents 
papier 
pour 
les 
transactions 
commerciales 
• réduire 
les 
coûts 
de 
gestion 
des 
services 
o Exemple 
: 
self-­‐banking
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
32 
Augmenter 
la 
compétitivité 
• disponibilité 
7/7 
et 
24/24 
• améliorer 
les 
interactions 
avec 
le 
client 
Développement 
de 
systèmes 
e-­‐business 
o Exemple 
: 
informer 
et 
conseiller 
en 
ligne 
• augmenter 
la 
rapidité 
de 
la 
mise 
sur 
le 
marché 
o Exemple 
: 
outil 
de 
production 
largement 
paramétrable 
Améliorer 
la 
gestion 
des 
données 
• augmenter 
la 
fiabilité 
des 
données 
• réduire 
les 
redondances 
• améliorer 
la 
diffusion 
d'information 
o Exemple 
: 
intégration 
électronique 
des 
commandes 
client 
dans 
le 
système 
du 
fournisseur 
Réduire 
les 
risques 
• améliorer 
la 
surveillance 
de 
l’activité 
o Exemple 
: 
tableaux 
de 
bord 
de 
gestion 
produits 
de 
manière 
largement 
automatisée 
o Exemple 
: 
état 
des 
stocks 
en 
temps 
réel 
_ 
moins 
de 
risque 
de 
rupture 
ð Augmenter 
la 
valeur 
des 
actionnaires 
en 
profitant 
de 
l'ensemble 
des 
bénéfices 
apportés 
par 
le 
système 
2. 
FAISABILITE 
D’UN 
PROJET 
L’étude 
de 
faisabilité 
d’un 
projet 
est 
la 
2ème 
chose 
à 
faire 
dans 
le 
cadre 
de 
l’étude 
d’opportunité. 
Parfois 
le 
projet 
n’est 
pas 
réaliste. 
Ø Exemple 
1 
: 
un 
système 
de 
correction 
automatique 
des 
examens 
pour 
les 
professeurs, 
ce 
n’est 
pas 
réaliste, 
les 
technologies 
ne 
suivent 
pas. 
Ø Exemple 
2: 
se 
faire 
soigner 
par 
un 
robot, 
on 
n’est 
peut 
être 
pas 
encore 
prêt 
pour 
cela, 
même 
si 
on 
peut 
démontrer 
que 
cela 
fonctionne.
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
On 
doit 
montrer 
qu’on 
peut 
maitriser 
les 
risques 
liés 
au 
déroulement 
du 
projet, 
les 
risque 
33 
FAISABILITE 
FACE 
AU 
RISQUE 
Le 
projet 
est 
faisable 
si 
les 
risques 
peuvent 
être 
raisonnablement 
maîtrisés. 
Il 
est 
important 
de 
voir 
si 
on 
peut 
maitriser 
les 
risques, 
même 
si 
l’idée 
est 
bonne, 
etc. 
è 
techniques, 
les 
risques 
liés 
à 
la 
viabilité 
du 
logiciel. 
Maîtriser 
les 
risques 
liés 
au 
déroulement 
du 
projet 
Ces 
risques 
impactent 
le 
plan 
du 
projet 
Ø Exemple 
: 
comment 
gérer 
une 
absence 
de 
longue 
durée 
d’un 
acteur? 
Maîtriser 
les 
risques 
techniques 
Ces 
risques 
impactent 
la 
qualité 
du 
logiciel 
Ø Exemple 
: 
faible 
qualité 
d’un 
système 
de 
correction 
automatique 
d'examens 
Ø Exemple 
: 
faible 
performance 
d’un 
système 
de 
distribution 
de 
vidéos 
en 
ligne 
Maîtriser 
les 
risques 
business 
liés 
à 
la 
viabilité 
du 
logiciel 
Thierry 
Van 
den 
Berghe 
(à 
la 
volonté 
des 
utilisateurs 
de 
mettre 
le 
logiciel 
en 
utilisation) 
Ces 
risques 
impactent 
la 
valeur 
attendue 
du 
logiciel 
Ø Exemple 
: 
excellent 
système 
mais 
que 
personne 
n'utilise 
Ø Exemple 
: 
digitaliser 
toute 
la 
communication 
via 
email, 
forum 
et 
WiKi 
Ø Exemple 
: 
vote 
électronique 
(typique) 
: 
Techniquement, 
le 
vote 
électronique 
est 
plus 
ou 
moins 
au 
point, 
il 
existe 
mais 
n’est 
toujours 
pas 
accepté 
pour 
des 
raisons 
indépendantes 
des 
2 
risques 
ci-­‐dessus 
(risques 
techniques 
et 
risques 
liés 
au 
déroulement 
du 
projet) 
è 
manque 
d’adhésion 
des 
utilisateurs. 
ARTICLE 
SUR 
LE 
VOTE 
ELECTRONIQUE 
"Le 
vote 
électronique 
a-­‐t-­‐il 
du 
plomb 
dans 
l’aile 
? 
Selon 
nos 
informations, 
le 
ministre 
de 
l’Intérieur 
a 
toutes 
les 
peines 
du 
monde 
à 
convaincre 
ses 
partenaires 
de 
poursuivre 
dans 
la 
voie 
initiée 
en 
1991, 
lorsque 
les 
premières 
machines 
furent 
installées 
dans 
notre 
pays.... 
Aux 
dernières 
élections, 
le 
vote 
automatisé 
a 
concerné 
44 
% 
des 
électeurs, 
soit 
100 
% 
à 
Bruxelles, 
22 
% 
en 
Wallonie 
et 
49 
% 
en 
Flandre. 
Depuis 
son 
introduction, 
le 
vote 
électronique 
n’a 
cessé 
de 
susciter 
réserves 
et 
critiques. 
Censé 
rendre 
le 
vote 
plus 
fiable, 
le 
dépouillement 
plus 
rapide 
et 
le 
scrutin 
moins 
onéreux, 
il 
n’a 
pas 
fait 
la 
preuve 
de 
son 
efficacité 
jusqu’ici. 
... 
De 
l’aveu 
même 
du 
ministre 
de 
l’Intérieur, 
il 
coûte
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
trois 
fois 
plus 
cher 
(4,5 
euros 
par 
électeur 
contre 
1,5 
pour 
le 
vote 
papier). 
Aux 
législatives 
de 
2007, 
on 
a 
enregistré 
400 
incidents. 
Quantaugaindetemps... 
«A 
Liège 
ou 
Bruxelles, 
totalement 
informatisés, 
on 
a 
eu 
les 
résultats 
après 
minuit», 
rappelle 
Michel 
Staszewski, 
de 
l’association 
Pour 
Eva 
(Pour 
une 
éthique 
du 
vote 
automatisé), 
qui 
milite 
pour 
un 
retour 
au 
vote 
papier, 
seul 
garant 
à 
ses 
yeux 
de 
transparence 
et 
de 
contrôle 
démocratique. 
Tel 
est 
le 
problème 
majeur, 
selon 
les 
détracteurs 
: 
« 
L’exemple 
est 
célèbre 
de 
cet 
élu 
schaerbeekois 
qui 
a 
obtenu 
plus 
de 
voix 
de 
préférence 
qu’il 
n’y 
avait 
de 
votants. 
Il 
y 
en 
a 
eu 
d’autres, 
et 
encore 
ces 
cas 
ne 
sont-­‐ils 
que 
la 
partie 
émergée 
de 
l’iceberg, 
puisque 
sans 
contrôle 
humain, 
les 
erreurs 
peuvent 
passer 
inaperçues 
». 
D’autres 
ont 
fait 
machine 
arrière. 
Les 
Pays-­‐Bas, 
les 
plus 
avancés 
d’Europe, 
ont 
été 
contraints 
par 
la 
justice 
d’abandonner 
le 
vote 
électronique. 
Et 
l’Irlande 
y 
a 
renoncé 
malgré 
de 
lourds 
investissements”. 
Par 
exemple, 
on 
souhaite 
développer 
un 
site 
pour 
gérer 
les 
sports 
d’hivers 
du 
CDE. 
Combien 
cela 
va-­‐t-­‐il 
couter 
? 
Comment 
dégager 
un 
ordre 
de 
grandeur 
? 
Il 
existe 
un 
grand 
nombre 
de 
techniques 
pour 
estimer 
les 
couts 
de 
main 
d’oeuvre 
liés 
au 
développement. 
• 1ère 
estimation 
: 
effort 
* 
coût 
moyen 
mensuel 
d’une 
ressource 
• 2ème 
estimation 
: 
calcul 
du 
coût 
de 
chaque 
tâche 
en 
fonction 
des 
ressources 
• pour 
déterminer 
précisément 
les 
coûts, 
le 
système 
doit 
être 
au 
moins 
la 
suite 
: 
présentation 
simplifiée 
et 
adaptée 
de 
la 
métrique 
des 
points 
de 
fonction 
et 
du 
modèle 
34 
3. 
EVALUATION 
DU 
COUT 
D’UN 
SYSTEME 
ESTIMATION 
DES 
COUTS 
DE 
DEVELOPPEMENT 
But: 
dégager 
des 
ordres 
de 
grandeur 
pour 
décider 
de 
la 
faisabilité 
affectées 
(cf. 
planification) 
complètement 
décrit 
Utilisation 
de 
métriques 
et 
modèles 
pour 
: 
• on 
va 
essayer 
d’estimer 
le 
volume 
du 
système 
à 
développer 
• estimer 
les 
ressources 
humaines 
à 
allouer 
au 
projet 
• dans 
Développement 
de 
systèmes 
e-­‐business 
COCOMO. 
Pour 
une 
discussion 
complète 
: 
Donald 
J. 
Reifer, 
Estimating 
Web 
Development 
Costs: 
There 
Are 
Differences, 
http://www.reifer.com/ 
; 
http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html, 
On 
saura 
si 
le 
système 
va 
couter 
5000, 
500000 
ou 
20000000 
euros. 
On 
pourra 
déjà 
trancher 
sur 
l’opportunité 
du 
projet. 
Cette 
estimation 
n’est 
pas 
précise 
parce 
qu’on 
en 
est 
qu’à 
l’avant-­‐projet, 
on 
n’a 
pas 
encore 
décrit 
complètement 
le 
système. 
Il 
faut 
aller 
plus 
loin 
pour
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
cela, 
par 
exemple 
avoir 
une 
idée 
de 
toutes 
les 
tâches 
a 
déployer 
pour 
faire 
un 
calcul 
très 
précis, 
une 
estimation 
plus 
précise 
du 
cout 
du 
développement. 
Exemple 
: 
construction 
d’une 
maison. 
Grosso 
modo 
on 
sait 
ce 
qu’on 
veut, 
on 
va 
faire 
un 
premier 
dessin 
avec 
l’architecte 
mais 
sans 
trop 
de 
détails. 
On 
va 
dégager 
une 
surface 
(volume 
du 
système). 
Par 
exemple 
: 
maison 
de 
150 
mètres 
carrés. 
A 
partir 
de 
cela, 
on 
va 
regarder 
par 
rapport 
a 
des 
projets 
antérieurs 
(par 
exemple) 
le 
cout 
moyen 
35 
Thierry 
Van 
den 
Berghe 
è 
règle 
de 
trois. 
On 
va 
obtenir 
un 
budget 
(ordre 
de 
grandeur, 
estimation). 
On 
va 
d’abord 
estimer 
le 
volume 
du 
système 
puis 
les 
ressources 
allouées 
au 
projet. 
On 
a 
besoin 
de 
deux 
outils 
: 
le 
point 
de 
fonction 
et 
les 
ressources 
à 
allouer 
au 
projet 
Ici 
on 
va 
voir 
des 
versions 
simplifiées 
des 
modèles 
qu’on 
trouve 
sur 
le 
terrain. 
On 
va 
voir 
les 
grands 
principes 
pour 
voir 
qu’il 
est 
possible 
de 
déterminer 
une 
estimation 
de 
cout 
d’un 
système 
même 
si 
on 
n’est 
pas 
informaticien. 
è 
Objectif 
du 
cours 
: 
faciliter 
le 
dialogue 
entre 
le 
gestionnaire 
et 
le 
spécialiste. 
ANALYSE 
PAR 
POINTS 
DE 
FONCTION 
(FP) 
Principe 
: 
identifier 
les 
éléments 
de 
l'application 
à 
construire 
(paramètres) 
et 
les 
pondérer 
en 
fonction 
de 
leur 
complexité 
Objectif 
: 
dégager 
une 
estimation 
a 
priori 
du 
volume 
de 
l'application
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
Ici 
on 
va 
essayer 
de 
décrire, 
projeter 
le 
futur 
système. 
On 
va 
identifier 
des 
grands 
composants 
du 
système. 
L’utilisateur 
doit 
faire 
une 
démarche 
pour 
imaginer 
le 
système 
auquel 
il 
pense. 
36 
Ici 
on 
va 
projeter 
le 
système 
auquel 
on 
pense 
en 
différents 
paramètres 
Développement 
de 
systèmes 
e-­‐business 
-­‐ les 
entrées 
: 
les 
lots 
d’informations 
rentrant 
dans 
le 
système. 
Ex 
: 
un 
écran 
de 
saisie, 
un 
écran 
pour 
enregistrer 
le 
descriptif 
du 
voyage, 
un 
autre 
pour 
enregistre 
les 
données 
de 
l’élève 
qui 
souhaite 
participer 
au 
voyage, 
etc. 
-­‐ Les 
sorties 
Exemple 
: 
rapport, 
facture, 
graphe 
sur 
écran. 
-­‐ Les 
requêtes 
: 
une 
extraction 
des 
données 
avec 
une 
certaine 
valeur 
ajoutée. 
-­‐ Les 
fichiers 
ou 
tables 
: 
grappes 
principales 
de 
données. 
Exemple 
: 
séjour, 
réservations, 
des 
étudiants 
qui 
veulent 
participer, 
des 
payments 
-­‐ Les 
fichiers 
multimédias 
: 
Exemple 
: 
page 
d 
accueil, 
page 
statique 
etc. 
-­‐ Les 
composants 
Web 
réutilisables 
à 
intégrer 
: 
è 
importés 
en 
tant 
que 
composants 
dans 
le 
système 
qu’on 
est 
en 
train 
de 
développer. 
Exemple 
: 
On 
doit 
développement 
un 
écran 
de 
login 
: 
L’écran 
de 
login 
est 
un 
écran 
avec 
2 
zones 
: 
Ø le 
login 
Ø le 
password. 
Pour 
un 
informaticien 
professionnel, 
ce 
n’est 
pas 
beaucoup 
de 
travail. 
Ce 
sera 
quelque 
chose 
de 
très 
simple 
à 
construire. 
Par 
contre, 
un 
écran 
de 
commande 
avec 
le 
calcul 
de 
livraison, 
de 
TVA 
etc., 
c'est 
plus 
compliqué 
à 
construire 
parce 
qu’il 
y 
a 
des 
calculs, 
de 
nombreuses 
zones, 
etc. 
Dans 
un 
premier 
temps 
on 
va 
surtout 
se 
concentrer 
sur 
le 
principe 
et 
pas 
la 
complexité. 
Chaque 
valeur 
de 
paramètre 
aura 
un 
certain 
poids, 
à 
calculer 
en 
fonction 
des 
différents 
poids 
et 
éléments 
identifiés, 
un 
nombre 
de 
points 
de 
fonction, 
unité 
qui 
représente 
l’ampleur 
du 
système.
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
37 
EXEMPLE 
Thierry 
Van 
den 
Berghe 
Ici 
on 
a, 
par 
exemple, 
un 
écran 
de 
saisie 
client, 
c’est 
simple. 
Un 
écran 
de 
saisie 
de 
facture, 
ou 
de 
saisie 
produit 
c’est 
déjà 
plus 
compliqué, 
plus 
élaboré. 
Ici 
on 
a 
une 
valeur 
abstraite 
de 
106 
points 
de 
fonction. 
Avec 
cela 
on 
n’est 
pas 
très 
avancé. 
Ca 
représente 
un 
certain 
nombre 
de 
points 
de 
fonction 
mais 
qu’est 
ce 
que 
ca 
représente 
en 
terme 
d’hommes/mois 
au 
niveau 
du 
développement? 
PARAMETRES 
• la 
liste 
des 
paramètres 
peut 
évoluer 
è 
La 
liste 
des 
paramètres 
n’est 
pas 
figée, 
il 
y 
a 
des 
variations 
des 
points 
de 
fonction. 
è 
autres 
paramètres 
possibles: 
communication 
inter-­‐systèmes, 
intégration 
de 
composants, 
données 
à 
récupérer, 
etc. 
è 
Cela 
peut 
aussi 
mobiliser 
de 
l’énergie 
des 
développeurs 
et 
donc 
faut 
les 
considérer. 
Ici 
ce 
sont 
des 
exemples 
parmi 
d’autres. 
• un 
besoin 
d’un 
utilisateur 
peut 
conduire 
à 
plusieurs 
valeurs 
de 
paramètres 
o Exemple 
: 
une 
facture 
peut 
nécessiter 
un 
travail 
de 
mise 
en 
forme 
important 
et 
la 
construction 
d’une 
requête 
complexe. 
Si 
je 
demande 
au 
développeur 
d’écrire 
un 
système 
qui 
va 
me 
permettre 
d’encoder 
des 
factures 
=>… 
les 
données 
enregistrées 
a 
travers 
écran 
vont 
devoir 
être 
enregistré 
dans 
des 
tables 
(2eme 
paramètre) 
et 
il 
y 
aura 
peut 
être 
une 
sortie… 
• des 
corrélations 
peuvent 
exister 
dans 
l’évaluation 
des 
paramètres 
(souvent 
il 
y 
a 
des 
corrélation 
au 
niveau 
des 
points 
de 
fonction, 
des 
paramètres, 
et 
souvent 
on 
retrouve 
ces 
paramètres) 
o Exemple 
: 
une 
table 
a 
souvent 
un 
équivalent 
écran 
de 
saisie
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
38 
EXEMPLE 
D’UNITES 
DE 
PARAMETRES 
Ici 
on 
va 
voir 
quelques 
indications 
qui 
permettent 
dévaluer 
la 
difficulté 
de 
tel 
ou 
tel 
écran. 
Développement 
de 
systèmes 
e-­‐business 
• entrée 
: 
écran 
de 
saisie 
è 
permet 
de 
créer 
de 
l’information, 
de 
l’éditer 
o évaluation 
de 
la 
complexité 
: 
§ nombre 
de 
zones 
de 
saisie/affichage 
– 
nombre 
de 
zones 
qui 
doivent 
être 
saisies 
par 
l’utilisateur. 
Si 
j’ai 
juste 
un 
nom 
d’utilisateur 
et 
un 
mot 
de 
passe, 
ce 
n’est 
pas 
un 
écran 
qui 
va 
demander 
beaucoup 
de 
travail 
de 
programmation. 
Un 
écran 
avec 
beaucoup 
de 
zones 
calculées 
contribue 
à 
la 
complexité 
de 
l’écran 
(ex 
: 
calcul 
du 
total 
d’une 
facture 
ou 
autre). 
§ importance 
des 
contrôles 
de 
validité 
des 
données. 
§ importance 
de 
l’automatisme 
dans 
la 
saisie 
(remplissage 
automatique, 
proposition 
de 
données 
à 
l’utilisateur, 
etc.) 
o unité 
alternative 
: 
messages 
digitaux 
en 
provenance 
d’autres 
systèmes 
• sortie 
: 
rapport 
à 
imprimer 
è 
si 
on 
doit 
programmer 
des 
rapports 
papier 
ou 
écran 
avec 
beaucoup 
de 
calculs 
différents, 
ou 
graphiques, 
alors 
cela 
représente 
beaucoup 
de 
travail, 
et 
cela 
fait 
monter 
la 
complexité 
du 
rapport. 
o évaluation 
de 
la 
complexité 
: 
§ difficulté 
de 
la 
mise 
en 
page 
§ variété 
de 
l’information 
à 
représenter 
§ construction 
de 
graphiques 
o unité 
alternative 
: 
messages 
digitaux 
à 
envoyer 
vers 
d’autres 
systèmes 
• requête 
: 
interrogation 
d’une 
base 
de 
données 
è 
il 
y 
a 
des 
requêtes 
plus 
simples 
que 
d’autres 
et 
parfois 
une 
requête 
peut 
impliquer 
plusieurs 
requêtes 
successives. 
o évaluation 
de 
la 
complexité 
: 
§ nombre 
de 
tables 
et 
de 
champs 
à 
accéder 
§ importance 
des 
calculs 
à 
réaliser 
(agrégation, 
etc.) 
o unité 
alternative 
: 
outil 
de 
recherche 
textuelle 
• table 
ou 
fichier 
: 
table 
d’une 
base 
de 
données 
relationnelle 
o évaluation 
de 
la 
complexité 
: 
§ nombre 
de 
champs 
– 
nombre 
de 
colonnes 
§ importance 
des 
contraintes
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
39 
Thierry 
Van 
den 
Berghe 
• fichier 
multimédia 
: 
conception 
d’un 
page 
Web 
type 
è 
un 
peu 
comme 
les 
écrans 
de 
saisie, 
le 
nombre 
de 
zones 
à 
indiquer 
à 
l’écran 
induit 
une 
lourdeur. 
o évaluation 
de 
la 
complexité 
: 
§ nombre 
d’éléments 
d’information 
à 
présenter 
§ difficulté 
de 
la 
mise 
en 
forme 
Exemple 
: 
une 
page 
d'accueil 
avec 
des 
menus 
est 
plutôt 
complexe 
– 
il 
y 
a 
des 
modules 
qu’on 
intègre, 
c'est 
toujours 
complexe 
Exemple 
: 
une 
page 
avec 
des 
graphiques 
est 
plutôt 
de 
difficulté 
moyenne 
• composant 
Web 
à 
intégrer 
o évaluation 
de 
la 
complexité 
: 
§ complexité 
de 
paramétrage 
du 
composant 
§ interactions 
avec 
le 
site 
Web 
-­‐ 
interaction 
entre 
les 
composants 
Exemple 
: 
passage 
de 
paramètre 
vers 
un 
module 
de 
paiement 
est 
plutôt 
complexe 
Exemple 
: 
saisie 
d'information 
par 
le 
composants 
(News, 
forum, 
etc.) 
est 
plutôt 
complexe 
EXEMPLES 
DE 
COMPOSANTS 
WEB
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
Ce 
modèle 
n’a 
pas 
des 
points 
de 
fonction 
comme 
entrée 
mais 
bien 
un 
certain 
nombre 
de 
lignes 
de 
code. 
40 
CONVERSION 
EN 
LIGNES 
DE 
CODE 
Développement 
de 
systèmes 
e-­‐business 
è 
35 
lignes 
de 
code 
en 
Access. 
è 
106 
points 
de 
fonction, 
développés 
avec 
le 
langage 
java 
par 
exemple, 
on 
va 
faire 
106 
x 
63 
et 
on 
va 
arriver 
a 
un 
nombre 
de 
lignes 
de 
code. 
Il 
y 
a 
rien 
de 
plus 
qu’une 
simple 
conversion 
d’unité 
là 
derrière. 
Une 
fois 
qu’on 
a 
ca, 
on 
peut 
appliquer 
des 
métriques 
d’estimation 
d’effort. 
ESTIMATION 
DE 
L’EFFORT 
DE 
DEVELOPPEMENT
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
L’effort 
exprimé 
en 
mois 
homme 
est 
proportionnel 
a 
des 
milliers 
de 
lignes 
de 
code 
avec 
un 
exposant 
c 
relativement 
proche 
de 
1 
(a 
& 
b 
sont 
des 
constantes) 
Cf. 
graphe 
: 
évolution 
de 
l’effort 
en 
fonction 
de 
la 
taille 
41 
è 
Thierry 
Van 
den 
Berghe 
Légèrement 
exponentiel 
et 
non 
linéaire 
pcq 
gérer 
complexité 
gros 
systèmes. 
Il 
y 
a 
des 
facteurs 
qui 
sont 
ici 
multiplicatifs 
qui 
sont 
des 
facteurs 
d’ajustement 
qui 
tiennent 
compte 
de 
propriétés 
générales 
du 
système 
et 
son 
environnement. 
COCOMO 
: 
CONSTRUCTIVE 
COST 
MODEL 
SIMPLIFIE 
Modèle 
d’estimation 
d’effort 
: 
COCOMO 
(un 
modèle 
parmi 
d’autres) 
Ø Effort 
– 
durée 
– 
nombre 
de 
ressources 
à 
affecter 
au 
projet 
Ø Série 
de 
constantes 
: 
a 
; 
b, 
c, 
d 
Ici 
: 
hypothèse 
d’un 
projet 
organique 
simple 
et 
maitrisé 
Légère 
exponentielle 
du 
nombre 
de 
lignes 
de 
code 
On 
a 
les 
formules, 
on 
les 
applique 
(on 
va 
le 
faire 
dans 
des 
exemples 
ici)
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
Qualité 
de 
l’équipe 
IT 
: 
impact 
très 
fort 
sur 
le 
temps 
de 
développement 
et 
l’effort 
de 
42 
EFFORT 
ADJUSTEMENT 
FACTORS 
– 
EAF 
(EXEMPLES) 
Premièrement 
: 
exemples 
de 
facteurs 
d’ajustement 
qui 
sont 
ici 
multiplicatifs 
! 
è 
Développement 
de 
systèmes 
e-­‐business 
développe 
• Pénalité 
de 
46% 
pour 
des 
mauvais 
• Gain 
de 
près 
de 
30% 
pour 
des 
gens 
très 
compétents. 
EXEMPLES 
D’APPLICATION 
Ø Programme 
organique 
de 
32 
KLOC 
: 
o E 
= 
2,4 
x 
321,05= 
91 
hommes-­‐mois 
o D 
= 
2,5 
x 
910,38 
= 
14 
mois 
o N 
= 
!" 
!" 
= 
6,5 
hommes 
Imaginons 
qu’on 
veut 
développer 
un 
programme 
organique 
pour 
une 
PME. 
On 
arrive 
vite 
a 
32000 
lignes 
de 
code 
si 
on 
applique 
la 
technique 
des 
points 
de 
fonction 
(FP) 
ce 
qui 
va 
nous 
donner 
un 
effort 
de 
91 
homme 
mois. 
Si 
on 
connaît 
le 
salaire 
moyen 
d’un 
informaticien, 
on 
le 
multiplie 
par 
le 
nombre 
d’homme-­‐ 
mois 
et 
on 
a 
une 
première 
estimation 
du 
budget. 
Si 
on 
fait 
appel 
à 
un 
informaticien 
extérieur, 
combien 
cela 
va-­‐t-­‐il 
nous 
couter 
? 
Tarif 
journalier 
? 
Il 
travaille 
8h, 
ca 
va 
couter 
environ 
400-­‐600 
euros 
par 
jour.
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
43 
Thierry 
Van 
den 
Berghe 
è 
On 
va 
nous 
facturer 
un 
chef 
de 
projet 
jusque 
800 
à 
900 
euros 
par 
jour 
et 
pour 
des 
spécialistes 
pointus, 
réputés, 
ca 
peut 
monter 
à 
2000 
ou 
3000 
euros 
par 
jour 
+ 
les 
frais 
genre 
hébergement 
etc. 
(Carrière 
informatique 
= 
assez 
rémunératrice). 
Ø Claroline 
: 
460 
KLOC 
o E 
= 
1500 
hommes-­‐mois 
o D 
= 
40 
mois 
o N 
= 
37 
hommes 
Ø Développement 
d’un 
OS 
de 
35 
millions 
de 
lignes 
è 
Système 
d’exploitation 
(OS) 
qui 
fait 
35 
millions 
de 
lignes 
de 
code. 
o E 
= 
1.021.372 
hommes-­‐mois 
o D 
= 
210 
mois 
= 
+/-­‐ 
17 
ans 
o 
N 
= 
4878 
hommes 
Effort 
de 
plus 
de 
1 
million 
d’homme-­‐mois 
= 
17 
ans 
de 
travail 
pour 
5000 
personnes 
pour 
1 
seul 
système 
d’exploitation, 
c'est 
énorme… 
è 
Par 
exemple, 
chez 
SAP, 
l’équipe 
de 
développement 
est 
d’environ 
8000 
personnes 
et 
ils 
existent 
depuis 
plus 
de 
25 
ans. 
Chiffres 
concernant 
les 
équipes 
affectées 
par 
Microsoft 
tous 
des 
versions 
antérieurs 
des 
Windows 
: 
Exemple 
: 
pour 
le 
développement, 
faire 
évoluer, 
Windows 
XP 
à 
Windows 
server 
2003 
: 
4400 
personnes 
pour 
produire 
50 
millions 
de 
lignes 
de 
code. 
Windows 
existe 
depuis 
plus 
de 
20 
ans 
et 
a 
été 
conçu 
à 
partir 
de 
systèmes 
plus 
anciens 
… 
ces 
ordres 
de 
grandeurs 
ne 
sont 
donc 
pas 
si 
délirant 
que 
ca. 
Très 
difficile 
de 
trouver 
des 
chiffres… 
Ø Productivité 
implicite 
du 
modèle 
: 
16 
LOC 
par 
jour 
par 
personne 
Si 
on 
calcule 
la 
productivité 
implicite 
de 
ce 
modèle, 
par 
exemple 
: 
32000 
lignes 
de 
code, 
on 
divise 
ca 
par 
91 
x 
20 
(on 
fait 
travailler 
nos 
personnes 
20 
jours 
par 
mois) 
on 
arrive 
a 
une 
productivité 
d’environ 
16 
lignes 
de 
code 
par 
jour, 
c'est 
faisable, 
même 
confortable 
de 
produire 
16 
lignes 
de 
code 
par 
jour, 
mais 
pas 
réaliste, 
les 
efforts 
dont 
on 
parle 
incluent 
la 
programmation 
mais 
aussi 
la 
gestion 
de 
projet 
etc. 
tout 
rentre 
en 
ligne 
de 
compte 
dans 
l 
effort 
de 
travail, 
on 
ne 
fait 
pas 
que 
programmer.
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
44 
EXEMPLES 
D’APPLICATION 
: 
WINDOWS 
NT 
EXERCICE: 
MAXIMAT 
Développement 
de 
systèmes 
e-­‐business 
Enoncé 
:
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
45 
Thierry 
Van 
den 
Berghe 
Solution 
:
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
• L'entreprise 
de 
restauration 
industrielle 
Cuisigros 
souhaite 
informatiser 
le 
suivi 
de 
• L'intranet 
affichera 
des 
informations 
utiles 
pour 
les 
employés, 
à 
savoir 
: 
une 
page 
dédiée 
à 
l'organigramme, 
une 
page 
dédiée 
aux 
consignes 
à 
respecter 
sur 
le 
lieu 
de 
travail, 
et 
une 
page 
d'accueil 
reprenant 
un 
module 
de 
news, 
un 
module 
météo 
et 
le 
menu 
revoyant 
aux 
pages 
de 
l'intranet 
et 
aux 
fonctions 
de 
l'application 
de 
suivi. 
• L'entreprise 
prépare 
des 
repas 
qu'elle 
livre 
à 
des 
entreprises 
de 
plusieurs 
zonings 
industriels. 
Elle 
compte 
une 
centaine 
de 
clients 
et 
livre 
près 
de 
2500 
repas 
par 
jour. 
Les 
repas 
sont 
essentiellement 
livrés 
le 
midi, 
mais 
Cuisigros 
organise 
également 
des 
réceptions 
en 
soirée, 
ce 
qui 
implique 
des 
prestations 
supplémentaires 
de 
son 
personnel. 
• L'application 
à 
développer 
doit 
supporter 
les 
concepts 
suivants: 
• les 
fournisseurs 
et 
les 
commandes 
fournisseur. 
Les 
informations 
à 
gérer 
sur 
les 
fournisseurs 
sont 
assez 
traditionnelles 
et 
nécessitent 
un 
écran 
d'encodage 
assez 
simple. 
Le 
système 
doit 
proposer 
à 
l'écran 
une 
liste 
de 
commandes 
fournisseur 
basée 
sur 
les 
repas 
à 
préparer; 
cette 
liste 
est 
confirmée 
par 
un 
opérateur. 
Les 
bons 
de 
commande 
doivent 
être 
envoyés 
électroniquement, 
bien 
que 
cela 
soit 
potentiellement 
compliqué 
vu 
la 
diversité 
des 
systèmes 
informatiques 
des 
fournisseurs; 
• les 
clients 
et 
les 
commandes 
client. 
La 
structure 
de 
la 
clientèle 
de 
Cuisigros 
est 
complexe: 
le 
système 
doit 
gérer 
plusieurs 
catégories 
de 
clients 
et 
maintenir 
de 
nombreuses 
données, 
comme 
les 
habitudes 
alimentaires 
et 
culturelles. 
Par 
contre, 
les 
commandes 
client 
sont 
très 
classiques 
et 
comportent 
en 
moyenne 
15 
lignes 
articles 
(menus 
et 
boissons); 
• les 
matières 
premières 
et 
leur 
stockage. 
La 
gestion 
des 
matières 
premières 
consiste 
simplement 
à 
maintenir 
un 
descriptif 
de 
base, 
des 
quantités 
en 
stocks, 
des 
dates 
de 
péremption 
et 
des 
mouvements 
entrants 
et 
sortants. 
Des 
inventaires 
réguliers 
doivent 
être 
imprimés. 
• les 
produits 
finis. 
Cuisigros 
gère 
un 
petit 
nombre 
de 
produit 
finis 
(correspondant 
à 
des 
menus 
type) 
mais 
leur 
description 
est 
relativement 
complexe: 
elle 
inclut 
la 
composition 
d'un 
menu, 
i.e., 
ses 
différentes 
matières 
premières 
et 
leurs 
quantités 
respectives, 
une 
tarification 
par 
quantité 
et 
des 
recommandations 
de 
fabrication. 
L'expédition, 
elle, 
n'est 
pas 
automatisée; 
• le 
planning 
de 
production. 
Il 
est 
établi 
chaque 
semaine 
en 
fonction 
des 
commandes 
client. 
Cette 
partie 
de 
l'application 
est 
la 
plus 
complexe, 
puisqu'il 
faut 
anticiper 
les 
commandes 
fournisseurs 
et 
préparer 
l'horaire 
des 
employés. 
La 
réalisation 
du 
planning 
inclut 
l'édition 
(1) 
d'horaires 
de 
travail 
pour 
les 
employés, 
(2) 
d'un 
tableau 
de 
production 
et 
(3) 
d'une 
liste 
de 
propositions 
de 
commandes 
fournisseur; 
• les 
employés 
et 
le 
suivi 
des 
prestations. 
Le 
système 
gère 
des 
données 
de 
base 
concernant 
les 
employés 
et 
enregistre 
les 
prestations 
de 
chacun 
en 
distinguant 
les 
heures 
régulières 
des 
heures 
supplémentaires. 
Un 
listing 
de 
comparaison 
entre 
les 
horaires 
de 
travail 
issus 
du 
planning 
de 
production 
et 
les 
prestations 
réelles 
est 
à 
édité 
chaque 
fin 
de 
mois. 
Un 
récapitulatif 
des 
toutes 
les 
prestations 
est 
envoyé 
chaque 
semaine 
à 
un 
secrétariat 
social 
pour 
préparer 
le 
calcul 
des 
salaires. 
46 
EXERCICE 
: 
CUISIGROS 
son 
activité 
avec 
une 
application 
web 
greffée 
à 
son 
Intranet. 
Développement 
de 
systèmes 
e-­‐business
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
47 
SOLUTIONS 
Thierry 
Van 
den 
Berghe 
1. Analyse 
de 
l’énoncé 
: 
Enoncé 
Points 
de 
fonction 
L'intranet 
affichera 
des 
informations 
utiles 
pour 
les 
è 
employés, 
à 
savoir 
: 
une 
page 
dédiée 
à 
l'organigramme, 
une 
page 
dédiée 
aux 
consignes 
à 
respecter 
sur 
le 
lieu 
de 
travail, 
et 
une 
page 
d'accueil 
reprenant 
un 
module 
de 
news, 
un 
module 
météo 
et 
le 
menu 
revoyant 
aux 
pages 
de 
l'intranet 
et 
aux 
fonctions 
de 
l'application 
de 
suivi. 
page 
organigramme 
(fichier 
multimédia 
moyen 
car 
graphique) 
è 
page 
consignes 
(fichier 
multimédia 
simple) 
è 
page 
d'accueil 
(fichier 
multimédia 
difficile 
car 
menu 
et 
modules) 
è 
module 
de 
news 
(composant 
moyen 
car 
saisie 
de 
données) 
è 
module 
météo 
(composant 
simple) 
Les 
informations 
à 
gérer 
sur 
les 
fournisseurs 
sont 
assez 
traditionnelles 
et 
nécessitent 
un 
écran 
d'encodage 
assez 
simple 
è 
saisie 
fournisseur 
(entrée 
simple 
– 
rien 
n'indique 
du 
cet 
écran 
soit 
particulièrement 
difficile 
à 
construire) 
è 
table 
fournisseur 
(table 
simple 
– 
les 
données 
saisie 
à 
l'écran 
doivent 
être 
enregistrées 
dans 
une 
structure 
de 
stockage) 
Le 
système 
doit 
proposer 
à 
l'écran 
une 
liste 
de 
commandes 
fournisseur 
basée 
sur 
les 
repas 
à 
préparer; 
cette 
liste 
est 
confirmée 
par 
un 
opérateur. 
è 
saisie 
commande 
fournisseur 
(entrée 
difficile 
– 
entrée 
car 
l'opérateur 
doit 
alimenter 
le 
système 
en 
données 
par 
sa 
confirmation, 
difficile 
car 
un 
travail 
de 
calcul 
de 
la 
liste 
des 
commandes 
fournisseurs 
doit 
être 
réalisé) 
Alternative 
: 
requête 
moyenne 
ou 
difficile 
pour 
calculer 
la 
liste 
des 
commandes 
fournisseur 
+ 
écran 
de 
confirmation 
simple 
è 
table 
commande 
fournisseur 
(table 
simple 
– 
les 
données 
saisies 
à 
l'écran 
doivent 
être 
enregistrées 
dans 
une 
structure 
de 
stockage) 
è 
table 
repas 
(non 
prise 
en 
compte 
car 
correspond 
à 
un 
produit 
fini 
plus 
loin 
dans 
l'énoncé) 
Les 
bons 
de 
commande 
doivent 
être 
envoyés 
électroniquement, 
bien 
que 
cela 
soit 
potentiellement 
compliqué 
vu 
la 
diversité 
des 
systèmes 
informatiques 
des 
fournisseurs 
è 
bon 
de 
commande 
fournisseur 
(sortie 
difficile 
-­‐ 
travail 
technique 
d'envois 
de 
messages 
digitaux 
vers 
des 
systèmes 
différents) 
La 
structure 
de 
la 
clientèle 
de 
Cuisigros 
est 
complexe 
: 
le 
système 
doit 
gérer 
plusieurs 
catégories 
de 
clients 
et 
maintenir 
de 
nombreuses 
données, 
comme 
les 
habitudes 
alimentaires 
et 
culturelles. 
saisie 
client 
(entrée 
difficile) 
table 
client 
(table 
difficile)
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
saisie 
commande 
client 
(entrée 
moyenne 
– 
nombre 
de 
données 
à 
enregistrer 
relativement 
important, 
calculs 
à 
réaliser, 
comme 
le 
total 
de 
la 
commande) 
è 
saisie 
matière 
première 
et 
stock 
(entrée 
moyenne) 
table 
mouvement 
de 
stock 
(table 
simple) 
saisie 
produit 
fini 
(entrée 
difficile 
– 
beaucoup 
de 
listing 
d'horaire 
de 
travail 
(sortie 
difficile 
– 
si 
on 
suppose 
une 
mise 
en 
forme 
graphique 
comme 
un 
calendrier 
de 
travail) 
è 
requête 
horaire 
de 
travail 
(requête 
difficile 
– 
le 
calcul 
de 
l'horaire 
dépend 
des 
commandes 
client 
et 
devrait 
demander 
des 
calculs 
élaborés) 
è 
table 
horaire 
de 
travail 
(table 
simple 
– 
on 
suppose 
que 
les 
données 
sur 
les 
horaires 
doivent 
être 
mémorisées 
après 
calcul) 
è 
listing 
tableau 
de 
production 
(sortie 
simple) 
requête 
tableau 
de 
production 
(requête 
difficile 
– 
le 
calcul 
dépend 
des 
commandes 
client 
et 
devrait 
demander 
des 
calculs 
élaborés) 
è 
table 
production 
(table 
simple 
– 
on 
suppose 
que 
les 
données 
sur 
les 
horaires 
doivent 
être 
mémorisées 
après 
calcul) 
è 
listing 
proposition 
de 
commandes 
fournisseur 
(sortie 
simple 
– 
le 
calcul 
des 
propositions 
est 
déjà 
valorisé 
dans 
l'écran 
de 
saisie 
des 
commandes 
fournisseur) 
listing 
de 
comparaison 
(sortie 
moyenne) 
Listing 
récapitulatif 
des 
prestations 
(sortie 
moyenne) 
48 
Par 
contre, 
les 
commandes 
client 
sont 
très 
classiques 
et 
comportent 
en 
moyenne 
15 
lignes 
articles 
(menus 
et 
boissons) 
è 
table 
commande 
client 
(table 
simple) 
La 
gestion 
des 
matières 
premières 
consiste 
simplement 
à 
maintenir 
un 
descriptif 
de 
base, 
des 
quantités 
en 
stocks, 
des 
dates 
de 
péremption 
et 
des 
mouvements 
entrants 
et 
sortants. 
è 
è 
table 
matière 
première 
(table 
simple) 
è 
Des 
inventaires 
réguliers 
doivent 
être 
imprimés. 
è 
listing 
d'inventaire 
(sortie 
simple) 
Cuisigros 
gère 
un 
petit 
nombre 
de 
produit 
finis 
(correspondant 
à 
des 
menus 
types) 
mais 
leur 
description 
est 
relativement 
complexe 
: 
elle 
inclut 
la 
composition 
d'un 
menu, 
i.e., 
ses 
différentes 
matières 
premières 
et 
leurs 
quantités 
respectives, 
une 
tarification 
par 
quantité 
et 
des 
recommandations 
de 
fabrication. 
L'expédition, 
elle, 
n'est 
pas 
automatisée 
è 
données 
à 
saisir) 
è 
table 
produit 
fini 
(table 
difficile) 
Le 
planning 
de 
production. 
Il 
est 
établi 
chaque 
semaine 
en 
fonction 
des 
commandes 
client. 
Cette 
partie 
de 
l'application 
est 
la 
plus 
complexe, 
puisqu'il 
faut 
anticiper 
les 
commandes 
fournisseurs 
et 
préparer 
l'horaire 
des 
employés. 
La 
réalisation 
du 
planning 
inclut 
l'édition 
(1) 
d'horaires 
de 
travail 
pour 
les 
employés, 
(2) 
d'un 
tableau 
de 
production 
et 
(3) 
d'une 
liste 
de 
propositions 
de 
commandes 
fournisseur; 
è 
è 
Le 
système 
gère 
des 
données 
de 
base 
concernant 
les 
employés 
et 
enregistre 
les 
prestations 
de 
chacun 
en 
distinguant 
les 
heures 
régulières 
des 
heures 
supplémentaires. 
è 
saisie 
employé 
(entrée 
simple) 
è 
table 
employé 
(table 
simple) 
è 
saisie 
prestation 
(entrée 
simple) 
è 
table 
prestation 
(table 
simple) 
Un 
listing 
de 
comparaison 
entre 
les 
horaires 
de 
travail 
issus 
du 
planning 
de 
production 
et 
les 
prestations 
réelles 
est 
à 
édité 
chaque 
fin 
de 
mois. 
è 
Un 
récapitulatif 
des 
toutes 
les 
prestations 
est 
envoyé 
chaque 
semaine 
à 
un 
secrétariat 
social 
pour 
préparer 
le 
calcul 
des 
salaires 
è 
Développement 
de 
systèmes 
e-­‐business
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
49 
Thierry 
Van 
den 
Berghe 
2. Estimations 
chiffrées 
: 
Estimation 
d’effort 
= 
un 
exercice 
possible 
a 
l’examen. 
Comment 
peut 
on 
évaluer 
le 
cout 
de 
développement 
d’un 
système 
e-­‐business 
et 
l’évolution 
métrique. 
Il 
ne 
faut 
pas 
connaître 
les 
formules 
par 
coeur, 
elles 
seront 
fournies 
à 
l’examen 
si 
on 
en 
a 
besoin. 
Cas 
d’application 
qui 
pourrait 
nous 
être 
demandé.
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
50 
4. 
SPECIFICATIONS 
1. 
DEFINITION 
DE 
LA 
SPECIFICATION 
Développement 
de 
systèmes 
e-­‐business 
Objectif 
Ø établir 
une 
première 
spécification 
du 
système 
à 
construire 
sous 
un 
angle 
fonctionnel, 
i.e., 
indépendamment 
de 
choix 
technologiques 
Ø décrire 
le 
«quoi» 
et 
non 
le 
«comment» 
Tâches 
Ø rassembler 
les 
besoins 
détaillés 
des 
utilisateurs 
du 
système 
à 
construire 
en 
termes 
d'informations, 
de 
traitements 
d'informations 
et 
d’interfaces 
Ø sur 
base 
des 
besoins 
exprimés 
par 
les 
utilisateurs, 
décrire 
les 
structures 
de 
données, 
les 
traitements, 
le 
contrôle 
et 
l’interface 
du 
système 
Ø produire 
un 
document 
de 
spécifications 
fonctionnelles 
détaillé 
Formalisme: 
langages 
de 
modélisation 
graphique 
1ère 
question 
: 
« 
Qu'est 
ce 
qu’on 
veut 
exactement 
? 
» 
L’objectif 
est 
de 
spécifier 
le 
futur 
système 
qu’on 
veut. 
Tâches 
: 
Attention 
la 
phase 
de 
spécification 
est 
une 
phase 
fonctionnelle, 
on 
ne 
s’intéresse 
pas 
à 
la 
mécanique. 
Ici 
on 
va 
décrire 
le 
système 
comme 
une 
boite 
noire 
et 
identifier 
les 
fonctionnalités. 
Autrement 
dit, 
on 
décrit 
ce 
que 
le 
système 
va 
faire 
et 
pas 
comment 
il 
va 
rendre 
ses 
services. 
On 
va 
demander 
au 
programmeur 
un 
écran 
qui 
permet 
d’enregistrer 
les 
commandes 
mais 
on 
ne 
va 
pas 
lui 
imposer 
une 
manière 
de 
le 
faire.
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
Objectif 
: 
comprendre 
les 
besoins 
des 
utilisateurs 
et, 
sur 
base 
de 
ces 
besoins, 
décrire 
le 
système 
sous 
différentes 
dimensions. 
A 
l’issue 
de 
cette 
phase 
de 
spécification 
on 
va 
écrire 
un 
document 
fonctionnel 
qui 
décrit 
toutes 
les 
attentes 
des 
utilisateurs 
et 
qui 
peut 
servir 
de 
cahier 
de 
charge. 
On 
va 
l’envoyer 
à 
des 
prestataires 
IP 
potentiels 
(expliqué 
dans 
le 
docu 
sur 
IC) 
Si 
on 
délègue 
le 
développement 
à 
l’extérieur, 
tout 
ce 
qui 
est 
dans 
le 
cahier 
de 
charges 
revêt 
une 
allure 
contractuelle. 
51 
Thierry 
Van 
den 
Berghe 
è 
Enjeu 
vraiment 
important 
!!! 
Formalisme 
: 
plusieurs 
possibilités 
mais 
on 
utilise 
beaucoup 
des 
techniques 
graphiques 
pour 
représenter 
les 
besoins 
de 
l’utilisateur 
(diagramme 
de 
cas 
d’utilisation, 
etc.) 
DIMENSIONS 
CONSTITUTIVES 
Très 
important 
è 
Fait 
le 
lien 
entre 
les 
besoins 
et 
les 
spécifications. 
En 
général 
les 
deux 
sont 
très 
corrélés 
! 
Exemple: 
on 
peut 
dire 
« 
j’ai 
besoin 
d'un 
système 
de 
facturation 
en 
ligne 
» 
et 
donc 
au 
niveau 
des 
spécifications 
je 
pourrais 
dire 
« 
j'ai 
besoin 
d'un 
système 
qui 
permet 
d’enregistrer 
une 
facture, 
de 
la 
diffuser 
et 
d’enregistrer 
son 
paiement 
».
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
52 
TYPES 
DE 
BESOINS 
Quels 
sont 
les 
types 
de 
besoins 
pour 
les 
applications 
e-­‐business 
? 
Développement 
de 
systèmes 
e-­‐business 
Besoins 
informationnels 
è 
site 
vitrine 
Ø recouvrent 
les 
informations 
à 
publier 
Ø identification 
du 
contenu, 
définition 
de 
la 
politique 
de 
mise 
à 
jour, 
etc. 
Exemple 
: 
présentation 
de 
l'entreprise, 
catalogue 
de 
produits, 
etc. 
Quand 
on 
développe 
des 
parties 
de 
sites 
vitrine 
(site 
web 
relativement 
simple 
sans 
beaucoup 
de 
manipulations 
de 
données) 
on 
va 
avoir 
des 
besoins 
informationnels. 
Au 
départ 
internet 
est 
un 
système 
de 
diffusion 
d’information, 
de 
contenu, 
on 
va 
l’utiliser 
pour 
diffuser 
des 
infos 
sur 
notre 
entreprise, 
etc. 
ce 
sont 
des 
infos 
peu 
changeantes 
avec 
une 
dimension 
informationnelle 
forte. 
Besoins 
applicatifs 
è 
application 
Web 
Ø couvrent 
les 
traitements 
à 
réaliser 
par 
l'application 
e-­‐business 
Exemple: 
créer 
une 
commande, 
passer 
des 
ordres 
bancaires, 
etc. 
Ø décrits 
par 
les 
langages 
de 
modélisation 
(cas 
d'utilisation, 
etc.) 
Aujourd'hui, 
il 
y 
a 
de 
plus 
en 
plus 
de 
manipulation 
de 
données 
è 
besoins 
applicatifs 
avec 
des 
appli 
qui 
permettent 
par 
ex 
a 
un 
client 
dune 
banque 
de 
créer 
des 
données, 
par 
exemple, 
des 
ordres 
de 
virement. 
La 
on 
est 
plus 
dans 
l’applicatif 
: 
la 
modification 
de 
traitement 
de 
donnée. 
Besoins 
non 
fonctionnels 
Ø couvrent 
des 
propriétés 
périphériques 
au 
traitement 
de 
l'information 
Exemple 
: 
visuel 
et 
ergonomie, 
performance, 
confidentialité 
des 
données 
On 
va 
devoir 
aussi 
considérer 
les 
besoins 
non 
fonctionnels 
: 
relatifs 
a 
des 
caractéristiques 
globales 
de 
l’application 
pas 
directement 
en 
lien 
avec 
le 
traitement 
des 
données 
mais 
décrivent 
des 
accès 
globaux 
comme 
l’ergonomie, 
la 
performance 
et 
la 
confidentialité 
des 
données 
par 
exemple. 
TYPES 
DE 
SPECIFICATIONS 
On 
va 
décrire 
un 
système 
sous 
différents 
angles 
è 
quelque 
chose 
d'assez 
particulier. 
Si 
on 
veut 
rédiger 
les 
plans 
d’une 
future 
maison, 
avec 
une 
seule 
feuille, 
un 
modèle 
on 
a 
assez. 
Mais 
quand 
on 
veut 
spécifier 
les 
systèmes 
d'information 
c'est 
tellement 
complexe 
qu’il 
faut 
plusieurs 
angles 
pour 
comprendre 
è 
il 
faut 
plusieurs 
modèles, 
points 
de 
vue 
qui 
se 
complètent.
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
53 
Dimensions 
sous 
lesquelles 
on 
va 
décrire 
le 
futur 
système 
: 
Thierry 
Van 
den 
Berghe 
Ø Structures 
Quels 
sont 
les 
types 
de 
données 
que 
le 
système 
doit 
gérer 
? 
Quelles 
sont 
les 
structures 
de 
données 
que 
le 
système 
doit 
prendre 
en 
charge 
? 
Quand 
on 
a 
identifié 
les 
structures 
on 
doit 
encore 
examiner 
d’autres 
choses 
Ø Traitements 
è 
Décrire 
les 
manipulations 
qui 
vont 
avoir 
lieu 
sur 
ces 
structures 
de 
données. 
Quelles 
sont 
les 
opérations 
à 
réaliser 
sur 
ces 
types 
de 
données 
? 
Ces 
traitements 
ont 
lieu 
dans 
un 
certain 
ordre. 
On 
ne 
peut 
pas 
valider 
une 
commande 
si 
on 
n’a 
pas 
d’abord 
validé 
un 
client 
ou 
tous 
les 
articles… 
Ø Dynamique 
Quelles 
sont 
les 
séquences 
d’opérations 
permises 
au 
cours 
du 
temps? 
Quels 
sont 
les 
événements 
qui 
déclenchent 
ces 
séquences? 
La 
dynamique 
du 
système 
décrit 
la 
manière 
dont 
le 
système 
se 
comporte 
au 
cours 
du 
temps. 
Ø Interfaces 
Quelles 
est 
la 
forme 
et 
l’organisation 
de 
l’interface 
homme-­‐machine? 
Quelle 
est 
l’allure 
des 
écrans 
qu’on 
souhaite 
pour 
notre 
site 
web 
? 
Aussi 
un 
travail 
à 
faire 
en 
terme 
de 
spécification. 
è 
Toutes 
les 
dimensions 
sont 
complémentaires 
et 
intégrées 
EXEMPLES 
Ø Structures 
Client, 
commande 
et 
articles 
è 
Au 
niveau 
des 
structures 
on 
va 
préparer 
une 
base 
de 
données 
avec 
au 
minimum 
clients, 
commandes 
et 
articles 
Ø Traitements 
Créer 
un 
compte 
client, 
modifier 
un 
compte 
client, 
saisir 
un 
article, 
créer 
une 
commande, 
etc. 
è 
un 
processus 
d'enregistrement 
de 
nouvelles 
commande 
comportera 
3 
étapes 
qu’on 
va 
spécifier. 
Ø Dynamique 
Passer 
une 
nouvelle 
commande 
= 
1. créer 
une 
compte 
client 
ou 
choisir 
un 
compte 
existant 
2. choisir 
les 
articles 
et 
les 
quantités 
commandées 
3. calculer 
les 
frais 
de 
livraison 
et 
le 
total 
de 
la 
commande
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
54 
Développement 
de 
systèmes 
e-­‐business 
Ø Interfaces 
Lay-­‐out 
design 
d’un 
écran 
de 
commande 
è 
On 
peut 
déjà 
donner 
au 
programmeur 
une 
idée 
du 
lay-­‐out 
général 
d’un 
écran 
de 
commande. 
UML 
ET 
RUP 
Au 
niveau 
des 
formalismes, 
les 
diagrammes 
de 
cas 
d’activité 
ou 
de 
cas 
d’utilisation, 
par 
exemple, 
sont 
en 
fait 
des 
techniques 
intégrées 
dans 
ce 
qu’on 
appelle 
une 
famille 
de 
langage 
de 
modélisation. 
UML 
(Unified 
Modeling 
Language) 
Ø ensemble 
de 
notations 
standardisées 
par 
l'OMG 
(Object 
Management 
Group, 
http://www.omg.org) 
Ø techniques 
de 
modélisation 
graphiques 
Ø cf. 
http://www.uml.org 
RUP 
(Rational 
Unified 
Process) 
Ø processus 
de 
développement 
cohérent 
avec 
UML 
Ø ne 
fait 
pas 
l'objet 
d'une 
standardisation 
UML 
et 
RUP 
: 
produits 
IBM 
Ø soutenu 
pas 
de 
nombreux 
CASE 
Exemple 
: 
http://www-­‐01.ibm.com/software/rational/uml 
Exemple 
: 
http://www.visual-­‐paradigm.com 
Exemple 
: 
Open 
Source: 
http://www.staruml.com 
UML 
reprend 
les 
standards 
de 
notifications 
aujourd’hui 
très 
largement 
utilisés 
par 
les 
professionnels 
de 
l’informatique. 
Les 
concepteurs 
d’UML 
ont 
développé 
un 
processus 
de 
développement 
(voir 
article 
sur 
IC). 
Au 
départ 
l’ULM 
et 
le 
RUP 
ont 
été 
développés 
par 
une 
société 
de 
service 
et 
cette 
société 
a 
été 
rachetée 
par 
IBM 
= 
IBM 
gère 
ces 
2 
technologies.
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
UML 
a 
été 
développe 
par 
3 
gourous 
de 
l’informatique 
des 
années 
90. 
Idée 
de 
départ 
: 
rassembler 
une 
série 
de 
techniques 
existantes 
dans 
un 
ensemble 
cohérent 
et 
dans 
un 
contexte 
commercial 
(intention 
d’universalité). 
Premier 
terme 
: 
Unified 
Modeling 
55 
HISTORIQUE 
D’UML 
è 
Thierry 
Van 
den 
Berghe 
Language 
La 
première 
version 
date 
de 
1995, 
depuis 
ca 
a 
bien 
évolué, 
ca 
a 
été 
nourri 
de 
beaucoup 
d’autres 
technologies 
de 
modélisation 
et 
aujourd’hui 
on 
en 
est 
à 
la 
version 
2.5.
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
On 
retrouve 
beaucoup 
de 
composants 
très 
différents. 
Ces 
composants 
permettent 
de 
décrire 
les 
différents 
aspects 
d'un 
système. 
On 
trouve 
aussi 
des 
diagrammes 
qui 
décrivent 
le 
système 
à 
ses 
différentes 
étapes 
de 
maturation. 
On 
s’intéresse 
au 
diagramme 
de 
cas 
d’activité 
de 
cas 
d’utilisation 
ms 
il 
y 
en 
a 
plein 
d’autre… 
56 
COMPOSANTS 
D’UML 
2. 
DIAGRAMME 
DE 
CAS 
D’UTILISATION 
CAS 
D’UTILISATION 
: 
EXEMPLE 
INTRODUCTIF 
Rappel 
: 
Objectif 
= 
déterminer 
les 
grandes 
fonction 
du 
système 
a 
construire. 
Développement 
de 
systèmes 
e-­‐business
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
Exemple 
: 
on 
veut 
créer 
une 
nouvelle 
génération 
de 
Smartphones 
que 
veut 
on 
prévoir 
? 
Chaque 
grande 
fonction 
va 
être 
décrite 
par 
un 
cas 
d’utilisation. 
4 
types 
d’utilisations 
prévus 
pour 
le 
futur 
système 
: 
57 
Thierry 
Van 
den 
Berghe 
-­‐ téléphoner 
-­‐ envoyer 
des 
SMS 
-­‐ gérer 
un 
agenda 
-­‐ prendre 
des 
photos 
è 
Elles 
vont 
être 
détaillées 
L’idée 
d'un 
cas 
d'utilisation 
c'est 
de 
décrire 
le 
comportement 
du 
système 
du 
point 
de 
vue 
de 
l’utilisateur. 
Après 
l’étude 
d’opportunité, 
on 
décide 
d’engager 
le 
projet 
(ou 
non). 
Il 
va 
s’agir 
de 
décrire 
le 
système 
de 
manière 
relativement 
détaillée 
pour 
expliquer 
aux 
informaticiens 
ce 
qu’ils 
doivent 
produire. 
Les 
utilisateurs, 
les 
personnes 
qui 
connaissent 
le 
business, 
les 
besoins 
etc. 
peuvent 
décrire 
ce 
système. 
Ce 
ne 
sont 
pas 
les 
informaticiens 
qui 
doivent 
faire 
ca. 
CAS 
D’UTILISATION 
Description 
du 
comportement 
du 
système 
du 
point 
de 
vue 
de 
l'utilisateur 
Ø décrit 
le 
comportement 
du 
système 
dans 
son 
ensemble 
(boite 
noire) 
Ø le 
comportement 
est 
détaillé 
sous 
la 
forme 
de 
séquences 
d'actions 
exécutées 
par 
le 
système 
suite 
à 
des 
stimulations 
extérieures 
Ø certaines 
interactions 
peuvent 
ne 
pas 
concerner 
directement 
le 
système, 
mais 
sont 
mentionnées 
pour 
la 
bonne 
compréhension 
de 
l'utilisation 
du 
système 
Les 
cas 
sont 
regroupés 
dans 
un 
diagramme 
de 
cas 
d'utilisation 
Ø représentation 
des 
besoins 
ET 
spécification 
du 
système 
Ø description 
d'un 
processus 
business 
ET 
du 
système 
à 
construire 
Ø les 
cas 
d'utilisation 
servent 
à 
partitionner 
et 
structurer 
les 
besoins
Manon 
Cuylits 
Master 
1 
2012-­‐2013 
Il 
s’agit 
d’identifier 
les 
grandes 
fonctionnalités 
du 
système. 
C’est 
un 
formalisme 
assez 
simple 
intervenant 
dans 
les 
toutes 
premières 
étapes 
de 
la 
spécification. 
On 
essaye 
de 
cerner 
le 
système 
et 
de 
voir 
à 
quoi 
il 
va 
servir. 
è 
Pour 
décrire 
le 
système 
on 
va 
identifier 
les 
grandes 
fonctions 
avec 
le 
concept 
de 
cas 
d’utilisation. 
Un 
cas 
d’utilisation 
se 
représente 
par 
un 
ovale 
et 
cela 
représente 
une 
utilisation 
du 
système 
(vu 
comme 
la 
boite 
noire). 
On 
va 
identifier 
à 
quoi 
sert 
le 
système. 
Exemple 
: 
GSM 
de 
toute 
première 
génération 
: 
On 
a 
au 
moins 
les 
fonctionnalités 
suivantes 
: 
Le 
système 
est 
vu 
comme 
une 
boite 
noire 
qui 
interagit 
avec 
son 
environnement. 
Un 
acteur 
c'est 
un 
utilisateur 
ou 
un 
système 
a 
l'extérieur 
du 
système 
et 
qui 
« 
utilise 
» 
le 
système. 
Ce 
n’est 
pas 
spécialement 
une 
personne, 
ca 
peut 
être 
un 
autre 
système. 
Un 
acteur 
est 
extérieur 
au 
système 
et 
donc 
quand 
on 
décrit 
le 
fonctionnement, 
on 
indique 
la 
limite 
du 
système 
et 
on 
spécifie 
les 
acteurs 
qui 
interagissent 
avec 
le 
système 
et 
la 
connexion 
entre 
un 
acteur 
et 
un 
cas 
d’utilisation. 
C'est 
une 
connexion 
appelé 
« 
utilise 
». 
58 
Ø Premier 
formalisme 
: 
celui 
des 
cas 
d’utilisation 
(Use 
Case) 
Ø appeler 
un 
correspondant, 
Ø rédiger 
un 
SMS, 
Ø lire 
un 
SMS, 
Ø répondre 
à 
un 
appel. 
ACTEUR 
Représente 
un 
rôle 
joué 
par 
une 
entité 
qui 
interagit 
avec 
le 
système 
Ø stimule 
le 
système 
en 
vue 
de 
l'exécution 
d'un 
traitement 
Ø envoie 
et/ou 
reçoit 
de 
l'information 
vers/du 
système 
Développement 
de 
systèmes 
e-­‐business
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement
E-business - développement

Contenu connexe

Tendances

Lição 12 - A Volta do Exílio e a Preservação do Povo de Israel
Lição 12 - A Volta do Exílio e a Preservação do Povo de IsraelLição 12 - A Volta do Exílio e a Preservação do Povo de Israel
Lição 12 - A Volta do Exílio e a Preservação do Povo de IsraelÉder Tomé
 
GEOGRAFIA BÍBLICA - ANTIGO TESTAMENTO
GEOGRAFIA BÍBLICA - ANTIGO TESTAMENTOGEOGRAFIA BÍBLICA - ANTIGO TESTAMENTO
GEOGRAFIA BÍBLICA - ANTIGO TESTAMENTORODRIGO FERREIRA
 
Η Αποκάλυψη του Ιωάννη Εικονογραφημένη
Η Αποκάλυψη του Ιωάννη ΕικονογραφημένηΗ Αποκάλυψη του Ιωάννη Εικονογραφημένη
Η Αποκάλυψη του Ιωάννη ΕικονογραφημένηNikitas Vougiouklis
 
教會歷史(十一) 中國教會史(1)唐朝-清末
教會歷史(十一) 中國教會史(1)唐朝-清末教會歷史(十一) 中國教會史(1)唐朝-清末
教會歷史(十一) 中國教會史(1)唐朝-清末Jian-Yu Fisher Ke
 
教會歷史(二) 國教時期
教會歷史(二) 國教時期 教會歷史(二) 國教時期
教會歷史(二) 國教時期 Jian-Yu Fisher Ke
 
耶穌受洗 與 家譜 (路加福音3:21-38)
耶穌受洗 與 家譜 (路加福音3:21-38)耶穌受洗 與 家譜 (路加福音3:21-38)
耶穌受洗 與 家譜 (路加福音3:21-38)Jian-Yu Fisher Ke
 
彼得後書 第一章 八種屬靈的美德
彼得後書 第一章 八種屬靈的美德彼得後書 第一章 八種屬靈的美德
彼得後書 第一章 八種屬靈的美德查經簡報分享
 
Egito antigo escola com audio
Egito antigo   escola com audioEgito antigo   escola com audio
Egito antigo escola com audioLeticia Ribeiro
 

Tendances (17)

撒母耳記上 第十七章
撒母耳記上 第十七章撒母耳記上 第十七章
撒母耳記上 第十七章
 
Lição 12 - A Volta do Exílio e a Preservação do Povo de Israel
Lição 12 - A Volta do Exílio e a Preservação do Povo de IsraelLição 12 - A Volta do Exílio e a Preservação do Povo de Israel
Lição 12 - A Volta do Exílio e a Preservação do Povo de Israel
 
GEOGRAFIA BÍBLICA - ANTIGO TESTAMENTO
GEOGRAFIA BÍBLICA - ANTIGO TESTAMENTOGEOGRAFIA BÍBLICA - ANTIGO TESTAMENTO
GEOGRAFIA BÍBLICA - ANTIGO TESTAMENTO
 
腓利門書 111214
腓利門書 111214腓利門書 111214
腓利門書 111214
 
Η Αποκάλυψη του Ιωάννη Εικονογραφημένη
Η Αποκάλυψη του Ιωάννη ΕικονογραφημένηΗ Αποκάλυψη του Ιωάννη Εικονογραφημένη
Η Αποκάλυψη του Ιωάννη Εικονογραφημένη
 
教會歷史(十一) 中國教會史(1)唐朝-清末
教會歷史(十一) 中國教會史(1)唐朝-清末教會歷史(十一) 中國教會史(1)唐朝-清末
教會歷史(十一) 中國教會史(1)唐朝-清末
 
REVOLTA DE VILA RICA
REVOLTA DE VILA RICAREVOLTA DE VILA RICA
REVOLTA DE VILA RICA
 
01 pré-história
01   pré-história01   pré-história
01 pré-história
 
Índia e china antigas
Índia e china antigasÍndia e china antigas
Índia e china antigas
 
7 juizes
7   juizes7   juizes
7 juizes
 
明山寺 釋宗順著
明山寺 釋宗順著明山寺 釋宗順著
明山寺 釋宗順著
 
教會歷史(二) 國教時期
教會歷史(二) 國教時期 教會歷史(二) 國教時期
教會歷史(二) 國教時期
 
Portugueses
PortuguesesPortugueses
Portugueses
 
耶穌受洗 與 家譜 (路加福音3:21-38)
耶穌受洗 與 家譜 (路加福音3:21-38)耶穌受洗 與 家譜 (路加福音3:21-38)
耶穌受洗 與 家譜 (路加福音3:21-38)
 
6. mercantilismo e navegações
6. mercantilismo e navegações6. mercantilismo e navegações
6. mercantilismo e navegações
 
彼得後書 第一章 八種屬靈的美德
彼得後書 第一章 八種屬靈的美德彼得後書 第一章 八種屬靈的美德
彼得後書 第一章 八種屬靈的美德
 
Egito antigo escola com audio
Egito antigo   escola com audioEgito antigo   escola com audio
Egito antigo escola com audio
 

Similaire à E-business - développement

RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxtestuser715939
 
Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)David VALLAT
 
Prototype rapport
Prototype rapportPrototype rapport
Prototype rapportInes Ouaz
 
Management de projet 2
Management de projet 2Management de projet 2
Management de projet 2David VALLAT
 
Impacts de l'adoption de Scrum
Impacts de l'adoption de ScrumImpacts de l'adoption de Scrum
Impacts de l'adoption de ScrumPyxis Technologies
 
[MOOC GdP] Spécialisations GdP9
[MOOC GdP] Spécialisations GdP9[MOOC GdP] Spécialisations GdP9
[MOOC GdP] Spécialisations GdP9Bich Van Hoang
 
Chapitre 1:gestion de projet pour les informatiques
Chapitre 1:gestion de projet pour les informatiquesChapitre 1:gestion de projet pour les informatiques
Chapitre 1:gestion de projet pour les informatiquesAbdiKhani
 
conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...Sid Ahmed Benkraoua
 
Soubki projet
Soubki projetSoubki projet
Soubki projets1kor
 
Modèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEVModèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEVPierre
 
Cycle de développement du logiciel
Cycle de développement du logicielCycle de développement du logiciel
Cycle de développement du logicielMajid CHADAD
 
2 relation-acteurs-projet
2 relation-acteurs-projet2 relation-acteurs-projet
2 relation-acteurs-projetbriann_guillaud
 
Génie logiciel - Avant le logiciel
Génie logiciel - Avant le logicielGénie logiciel - Avant le logiciel
Génie logiciel - Avant le logicielJulien Schneider
 
La démarche de projet
La démarche de projetLa démarche de projet
La démarche de projetCHIROUDAKamel
 
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...Pyxis Technologies
 

Similaire à E-business - développement (20)

RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptx
 
Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)
 
Prototype rapport
Prototype rapportPrototype rapport
Prototype rapport
 
Management de projet 2
Management de projet 2Management de projet 2
Management de projet 2
 
Impacts de l'adoption de Scrum
Impacts de l'adoption de ScrumImpacts de l'adoption de Scrum
Impacts de l'adoption de Scrum
 
Up1
Up1Up1
Up1
 
[MOOC GdP] Spécialisations GdP9
[MOOC GdP] Spécialisations GdP9[MOOC GdP] Spécialisations GdP9
[MOOC GdP] Spécialisations GdP9
 
Chapitre 1:gestion de projet pour les informatiques
Chapitre 1:gestion de projet pour les informatiquesChapitre 1:gestion de projet pour les informatiques
Chapitre 1:gestion de projet pour les informatiques
 
Methode Agile
Methode Agile Methode Agile
Methode Agile
 
conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...
 
Soubki projet
Soubki projetSoubki projet
Soubki projet
 
Modèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEVModèle de maturité CMMi-DEV
Modèle de maturité CMMi-DEV
 
Cycle de développement du logiciel
Cycle de développement du logicielCycle de développement du logiciel
Cycle de développement du logiciel
 
Informatisation de projets
Informatisation de projetsInformatisation de projets
Informatisation de projets
 
Audit des projets informatiques
Audit des projets informatiquesAudit des projets informatiques
Audit des projets informatiques
 
2 relation-acteurs-projet
2 relation-acteurs-projet2 relation-acteurs-projet
2 relation-acteurs-projet
 
La Conduite de projet
La Conduite de projetLa Conduite de projet
La Conduite de projet
 
Génie logiciel - Avant le logiciel
Génie logiciel - Avant le logicielGénie logiciel - Avant le logiciel
Génie logiciel - Avant le logiciel
 
La démarche de projet
La démarche de projetLa démarche de projet
La démarche de projet
 
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
 

Plus de Manon Cuylits

L'influence du prix du cannabis sur sa consommation
L'influence du prix du cannabis sur sa consommationL'influence du prix du cannabis sur sa consommation
L'influence du prix du cannabis sur sa consommationManon Cuylits
 
Mémoire: l'approche par les risques - parallèle avec le risque fiscal
Mémoire: l'approche par les risques - parallèle avec le risque fiscalMémoire: l'approche par les risques - parallèle avec le risque fiscal
Mémoire: l'approche par les risques - parallèle avec le risque fiscalManon Cuylits
 
Gestion financière
Gestion financièreGestion financière
Gestion financièreManon Cuylits
 
Analyse des organisations
Analyse des organisationsAnalyse des organisations
Analyse des organisationsManon Cuylits
 
Les compagnies d’assurance et les fonds de pension
Les compagnies d’assurance et les fonds de pensionLes compagnies d’assurance et les fonds de pension
Les compagnies d’assurance et les fonds de pensionManon Cuylits
 
La régulation des institutions financières en matière de risque
La régulation des institutions financières en matière de risqueLa régulation des institutions financières en matière de risque
La régulation des institutions financières en matière de risqueManon Cuylits
 
Management accounting control
Management accounting control Management accounting control
Management accounting control Manon Cuylits
 
Gestion des Ressources Humaines
Gestion des Ressources HumainesGestion des Ressources Humaines
Gestion des Ressources HumainesManon Cuylits
 
Fiscalité d'entreprise partie 2
Fiscalité d'entreprise partie 2Fiscalité d'entreprise partie 2
Fiscalité d'entreprise partie 2Manon Cuylits
 
Fiscalité d'entreprise partie 1
Fiscalité d'entreprise partie 1Fiscalité d'entreprise partie 1
Fiscalité d'entreprise partie 1Manon Cuylits
 
Finances d'entreprise
Finances d'entrepriseFinances d'entreprise
Finances d'entrepriseManon Cuylits
 
Concepts d'économie et & marchés financiers
Concepts d'économie et & marchés financiersConcepts d'économie et & marchés financiers
Concepts d'économie et & marchés financiersManon Cuylits
 
Fed contre BCE: le match des politiques monétaires face à la crise
Fed contre BCE: le match des politiques monétaires face à la criseFed contre BCE: le match des politiques monétaires face à la crise
Fed contre BCE: le match des politiques monétaires face à la criseManon Cuylits
 
Role des autorités monétaires
Role des autorités monétairesRole des autorités monétaires
Role des autorités monétairesManon Cuylits
 
Les indicateurs de croissance économique
Les indicateurs de croissance économiqueLes indicateurs de croissance économique
Les indicateurs de croissance économiqueManon Cuylits
 
Economie et marchés financiers - Les indicateurs de prix
Economie et marchés financiers - Les indicateurs de prixEconomie et marchés financiers - Les indicateurs de prix
Economie et marchés financiers - Les indicateurs de prixManon Cuylits
 
International Auditing Standards (ISA)
International Auditing Standards (ISA)International Auditing Standards (ISA)
International Auditing Standards (ISA)Manon Cuylits
 

Plus de Manon Cuylits (20)

L'influence du prix du cannabis sur sa consommation
L'influence du prix du cannabis sur sa consommationL'influence du prix du cannabis sur sa consommation
L'influence du prix du cannabis sur sa consommation
 
Mémoire: l'approche par les risques - parallèle avec le risque fiscal
Mémoire: l'approche par les risques - parallèle avec le risque fiscalMémoire: l'approche par les risques - parallèle avec le risque fiscal
Mémoire: l'approche par les risques - parallèle avec le risque fiscal
 
Gestion financière
Gestion financièreGestion financière
Gestion financière
 
Analyse des organisations
Analyse des organisationsAnalyse des organisations
Analyse des organisations
 
Les banques
Les banquesLes banques
Les banques
 
Les compagnies d’assurance et les fonds de pension
Les compagnies d’assurance et les fonds de pensionLes compagnies d’assurance et les fonds de pension
Les compagnies d’assurance et les fonds de pension
 
La régulation des institutions financières en matière de risque
La régulation des institutions financières en matière de risqueLa régulation des institutions financières en matière de risque
La régulation des institutions financières en matière de risque
 
Management accounting control
Management accounting control Management accounting control
Management accounting control
 
Gestion des Ressources Humaines
Gestion des Ressources HumainesGestion des Ressources Humaines
Gestion des Ressources Humaines
 
Fiscalité d'entreprise partie 2
Fiscalité d'entreprise partie 2Fiscalité d'entreprise partie 2
Fiscalité d'entreprise partie 2
 
Fiscalité d'entreprise partie 1
Fiscalité d'entreprise partie 1Fiscalité d'entreprise partie 1
Fiscalité d'entreprise partie 1
 
Finances d'entreprise
Finances d'entrepriseFinances d'entreprise
Finances d'entreprise
 
Ethique & RSE
Ethique & RSE Ethique & RSE
Ethique & RSE
 
Concepts d'économie et & marchés financiers
Concepts d'économie et & marchés financiersConcepts d'économie et & marchés financiers
Concepts d'économie et & marchés financiers
 
Fed contre BCE: le match des politiques monétaires face à la crise
Fed contre BCE: le match des politiques monétaires face à la criseFed contre BCE: le match des politiques monétaires face à la crise
Fed contre BCE: le match des politiques monétaires face à la crise
 
Role des autorités monétaires
Role des autorités monétairesRole des autorités monétaires
Role des autorités monétaires
 
Les indicateurs de croissance économique
Les indicateurs de croissance économiqueLes indicateurs de croissance économique
Les indicateurs de croissance économique
 
Economie et marchés financiers - Les indicateurs de prix
Economie et marchés financiers - Les indicateurs de prixEconomie et marchés financiers - Les indicateurs de prix
Economie et marchés financiers - Les indicateurs de prix
 
Audit process
Audit processAudit process
Audit process
 
International Auditing Standards (ISA)
International Auditing Standards (ISA)International Auditing Standards (ISA)
International Auditing Standards (ISA)
 

E-business - développement

  • 1. E-­‐business : stratégie marketing et développement 2012-­‐2013 Manon Cuylits
  • 2. Manon Cuylits Master 1 2012-­‐2013 2 PARTIE 1 : DEVELOPPEMENT DE SYSTEMES E-­‐BUSINESS PLAN • Projet de développement d’un système e-­‐business o Processus de développement o Spécificités des projets e-­‐business o Cycle de développement • Lancement du projet o Définition de la portée du système o Gestion des acteurs o Gestion du projet • Etude d’opportunité • Spécification o Définition de la spécification o Diagramme de cas d’utilisation o Diagramme d’activité o Diagramme de contenu o Diagramme d’interface o Etude de cas Développement de systèmes e-­‐business • Réalisation o Conception et mise en oeuvre o Outils de développement § Outils de développement classiques § Générateurs de sites § Package et content management o Techniques clés § Pages dynamiques § Interopérabilité des systèmes • Mise en production • Test • Exemple : Rational Unified Process • Maintenance et promotion • Sécurité o Etat et enjeux o Solutions o Exemple de procédure de sécurité
  • 3. Manon Cuylits Master 1 2012-­‐2013 Le développement d’un système e-­‐business suit un processus de développement organisé et constitue un projet pour l’organisation. On souhaite créer un système e-­‐business dans notre organisation, (exemple 3 1. PROJET DE DEVELOPPEMENT D’UN SYSTEME D’E-­‐BUSINESS ð Processus de développement ð Spécificités des projets e-­‐business ð Cycle de développement PROJET DE DEVELOPPEMENT E-­‐BUSINESS Thierry Van den Berghe : site de vente en ligne, site communautaire, etc.) il faut que ce projet soit motivé, qu’on puisse démontrer que ce projet produit de la valeur ajoutée. Tout projet doit s’inscrire dans une stratégie et être cohérent. Le développement d’un système e-­‐business suit un processus organisé selon des étapes principales. On construit par étapes. La règle est de réfléchir avant d’agir, essayer d’adopter une approche industrielle dans le développement d’un logiciel. (Cf. ingénierie logicielle plus bas). Le développement d’un système e-­‐business constitue un projet pour l’organisation : -­‐ opérationnaliser la stratégie -­‐ gérer les ressources -­‐ gérer les contraintes de résultat, de budget et de délai L’INGENIERIE LOGICIELLE : DEFINITION & DEMARCHE L’ingénierie logicielle consiste à « appliquer une démarche systématique, disciplinée et quantifiable pour le développement d’un logiciel, un système e-­‐business ». è élaboration de processus de développement. Un projet de développement suit un processus qui est généralement organisé en phases successives. Démarche générique :
  • 4. Manon Cuylits Master 1 2012-­‐2013 4 En général on trouve 4 grandes phases : Réflexion préalable au commencement du projet : Développement de systèmes e-­‐business 1. comprendre le problème Par exemple : quels sont les besoins au niveau logistique pour construire un nouveau bâtiment 2. planifier des solutions. Réalisation concrète de ce qui a été imaginé au préalable : 3. exécuter le plan. 4. Evaluer le résultat : phase de retour sur expérience : quand le projet est terminé on fait un bilan de ce qui a fonctionné ou non On distingue 4 phases et lors de ces phases on réalise une série d’activités (exemple : interview des utilisateurs pour connaître leurs besoins). Certaines activités peuvent avoir lieu à des phases différentes. Les tests de qualité interviennent en permanence par exemple. Ce sont des activités transversales qui ont lieu tout au long du projet. PRINCIPES DE BASE DE L’INGENIERIE LOGICIELLE • L’intention première d'un système est de donner de la valeur aux utilisateurs Un système est souvent développé pour une autre personne è collaborer, communiquer et documenter. Un système, développé par des informaticiens, qui n’est pas directement en connexion avec la demande des utilisateurs ce n’est pas une bonne chose. Tout le projet est guidé par une demande des utilisateurs. Ce n’est pas le cas pour la production d’autres types de bien mais c’est typique du logiciel. • garder le système simple = ligne de conduite intellectuelle Un système simple est plus facile à développer, à maintenir et à utiliser. Néanmoins, travailler à la simplification d'un système prend du temps et est ardu. • rester ouvert au futur et intégrer la flexibilité Les besoins des utilisateurs évoluent è le système doit pouvoir être adapté facilement! Les systèmes informatiques doivent suivre les attentes des utilisateurs et dans le business la manière dont on traite les affaires évolue constamment. Il faut pouvoir évoluer en proportion. Exemple du bug de l’an 2000 : en 1999 les informaticiens se sont rendu compte qu’il fallait gérer le fait qu’on allait passer de 2 chiffres à 4 chiffres, gérer le siècle. Les systèmes informatiques de l’époque étaient très mal prévus pour intégrer des changements. Ce n’est pas facile de construire un système qu’on peut faire évoluer. Un logiciel on le modifie encore une fois qu’il est « fini », ce n’est pas le cas des voitures par exemple.
  • 5. Manon Cuylits Master 1 2012-­‐2013 5 • encourager la réutilisation des composantes Thierry Van den Berghe o Exemple : construire un système en assemblant des composants existants Dans certaines industries, comme celle de l’automobile, on essaye de standardiser les composantes, les intégrer dans des ensembles plus vastes, mais dans le cas des logiciels cette standardisation a du mal à s’imposer et cela représente un cout significatif. 1. PROCESSUS DE DEVELOPPEMENT Le Processus de développement: c’est un canevas qui structure et guide les informaticiens dans la production de logiciels, montre les différentes étapes à parcourir. Si on souhaite construire une maison on va suivre différentes étapes claires et structurées, c’est pareil. La production de la plupart des biens matériels et immatériels suivent un processus d’ingénierie bien précis. Processus Ø Quelles phases & tâches ? Ø Quels délivrables ? Ø Quels rôles ? Ø Etc. Tâches managériales Ø Planification Ø Gestion des ressources Ø Gestion des risques Ø Gestion de la qualité Ø Etc. Tâches techniques Ø Spécification du système Ø Modélisation Ø Programmation Le processus c’est un ensemble d’étapes réalisées pour atteindre un but précis. Dans les processus de développement de système e-­‐business on distingue deux grandes dimensions : une dimension managériale et technique. • Tâches managériales : L’aspect managérial englobe tout ce qui concerne la gestion de projet, on va le retrouver dans les projets de toute nature. On retrouve là dedans des taches de planification, de gestion des risques, de gestion des ressources, et de gestion de la qualité, entre autres. Exemple de tâches managériales : planification des activités, constitution d’une équipe • Tâches techniques : Elles contribuent directement à la production du produit final. On y retrouve par exemple la spécification du système, la modélisation et la programmation.
  • 6. Manon Cuylits Master 1 2012-­‐2013 Parallèle avec la construction d’une maison : tracer des plans pour le bâtiment, le gros oeuvre, etc. sont des taches techniques mais au niveau managérial, on réalise plutôt des activités comme le suivi budgétaire etc. Autrement dit, un processus est un ensemble d’activités coordonnées (tâches techniques et managériales/de gestion de projet) pour atteindre un but : le projet informatique (application d’un processus donné pour développer un système d’information). Le processus va spécifier : • les phases du projet et son cycle de développement ; • les tâches à réaliser au sein de chacune des phases et leur enchaînement dans le 6 Exemple de tâches : modélisation du système à construire, programmation Développement de systèmes e-­‐business temps ; • les produits à produire et fournir et • les différents rôles à assumer TYPES DE PROCESSUS • Processus inexistant Just do it ! Certains projets sont réalisés sans processus. Par exemple si on doit développer un petit site web, on ne va pas mettre en activité un processus long, on va directement produire le site. Dés qu’on s’engage dans un projet plus important, 2 manières de travailler : processus prescriptif ou adaptatif. • Processus prescriptifs o planification complète des activités puis exécution du plan o les activités sont réalisées une seule fois en séquence o vue globale du projet dès le départ mais travail de révision potentiel en cas de changements Analogie avec le blocus: si on travaille selon un processus prescriptif, on va planifier notre blocus et session d’examen de manière précise et jusqu’au bout, on sait combien de temps d’étude on a prévu pour chaque cours, chaque jour. On connait toutes les tâches à réaliser, l’objectif à atteindre, mais ce processus n’intègre pas facilement le changement. Si on est malade et qu’on ne sait pas travailler le 3ème jour, on doit tout re-­‐planifier pour s’adapter au changement.
  • 7. Manon Cuylits Master 1 2012-­‐2013 7 Thierry Van den Berghe • Processus adaptatifs o planification réduite et gestion intégrant le changement o des itérations répètent certaines activités plusieurs fois § Exemple : plusieurs prototypes successifs sont construits et évalués jusqu'à répondre correctement à la demande de l'utilisateur § Exemple : méthodes Agile C’est la tendance ces dernières années. On va avoir une planification générale et peu détaillée, les grandes phases sont détaillées mais la planification détaillée n’intervient qu’à très court terme, pour quelques jours. On se dit qu’on ne sait pas tout connaître dés le départ. C’est donc de la planification à court terme. Pour développer des sites web ca marche super bien car c’est très compliqué d’anticiper précisément les attentes de l’utilisateur, elles se précisent au fur et à mesure. CONTREPIED DE LA PLANIFICATION : METHODES AGILE Principe des méthodes Agile: les besoins des utilisateurs, le processus de développement et le logiciel à produire émergent progressivement au cours du projet • planification peu détaillée • cycles courts • système découpé en différents modules • collaboration étroite avec les utilisateurs et feedback immédiat è accent très important sur la collaboration entre l’utilisateur et l’informaticien • livraison régulière de parties du système (exemple : développement du module « présentation des produits », puis du module « prise de commande », puis du module « suivi des commandes », etc.) http://www.agilealliance.org, http://www.extremeprogramming.org PHASES & ACTIVITES TYPIQUES DE DEVELOPPEMENT
  • 8. Manon Cuylits Master 1 2012-­‐2013 8 PREMIERE PRESENTATION DES ACTIVITES CLES Il y 4 grandes phases qu’on retrouve dans tous les cycles de développement : 1. Comprendre le problème 2. Planifier une solution 3. Exécuter le plan 4. Evaluer le résultat On va détailler les activités pour chacune de ces phases: 1) comprendre le problème : Développement de systèmes e-­‐business • lancer le projet : préciser/déterminer les objectifs principaux du système qu’on veut construire, les contraintes, les ressources et la planification du projet è cadrer le projet • étudier l'opportunité : réfléchir à l’opportunité qu’il y aurait de lancer le projet : retours supérieurs aux investissements è évaluer les apports et décider de la réalisation du projet • spécifier le système (de manière assez détaillée): décrire les facilités attendues du système à partir de besoins exprimés par les utilisateurs 2) Planifier une solution & 3) Exécuter le plan • concevoir et mettre en oeuvre le système (plus technique) : réaliser le système en concevant d'abord la solution technique puis programmant le système (choisir les techniques les plus adaptées) • mettre en production : transférer le système aux utilisateurs (réaliser le système, programmer, le mettre en production) 4) Evaluer le résultat : • tester le système : vérifier la qualité et corriger les défauts (en réalité, cette activité est faite en permanence)
  • 9. Manon Cuylits Master 1 2012-­‐2013 9 2. SPECIFICITES DES PROJETS E-­‐BUSINESS Thierry Van den Berghe • application e-­‐business o logiciel de traitement de données accessible par Internet. Visent à produire et transformer de l’information. § exemple : Web-­‐banking, enregistrement de commandes • site e-­‐business o ensemble de contenus relativement stables accessibles par Internet § exemple : site de présentation d'une entreprise (site vitrine) • système e-­‐business o ensemble de composants accessible par Internet. Ces systèmes visent à diffuser de l’information. Par contre les applications e-­‐business visent à produire et transformer de l’information. § exemple : système combinant un site vitrine et une application de vente EXEMPLES D’EXIGENCES SPECIFIQUES DES APPLICATIONS E-­‐BUSINESS 1. Rendre une application attractive Surtout pour les applications de commerce électronique. Il est très important d’avoir un système attractif. Il faut que les accès soient adaptés à des profils d’utilisateurs variés • Exemple : le designer (ou un graphiste) développe des maquettes de site • Exemple : l'ergonome améliore la facilité d'utilisation d'une application è ergonomie = facilité d’utilisation Exemple ci-­‐dessus : Site a gauche peu attirant et a droite beaucoup plus dynamique, mieux foutu, l’effort d’ergonomie et plus important que pour le site de gauche.
  • 10. Manon Cuylits Master 1 2012-­‐2013 Beaucoup de systèmes de l’internet sont à diffusion mondiale. Il est très important de contrôler l’information diffusée sur les sites web, surtout quand on a une construction collaborative de contenu, comme dans le cas des forums. Pour les sites de diffusion d’informations, il faut définir des mécanismes de validation des contenus, de contrôle des différents messages etc. La qualité d’un système Web dépend en grande partie de son contenu 10 2. prévoir des mécanismes de contrôle collaboratifs des données Développement de systèmes e-­‐business • Exemple : le gestionnaire de contenu met à jour les news d'une page d'accueil • Exemple : le modérateur contrôle le ton des messages postés sur un forum 3. assurer la sécurité L’Internet est un espace public accessible à des hackers. è Au départ les technologies de l’internet n’ont pas été conçues pour être correctement sécurisées. Il existe une série de mécanismes qui sécurisent jusqu’à un certain point les infos qui circulent sur le net mais on est encore loin de la perfection. Internet : on est la cible potentielle de milliers de hackers qui n’ont que ca à faire : attaquer les systèmes etc. On n’a pas droit à l’erreur, si un pirate rentre sur notre système les effets peuvent être désastreux. • Exemple : un expert sécurité met en place des protections contre le piratage 4. assurer la performance Dans le cas des systèmes orientés réseau et massivement multi-­‐utilisateurs, la charge d’un système est imprévisible et peut être très variable au cours du temps, surtout dans le cas d’un site de vente en ligne. On ne sait pas dire combien d’utilisateurs vont utiliser notre système en même temps. Cela peut lancer des problèmes de performance critiques (exemple : on lance une super promo, des tonnes de clients prennent le site d’assaut et cela crée des problèmes, parfois même pour une durée très courte). Faut il investir en infrastructure pour faire face à cela ? Le débat n’est pas évident. • Exemple : un web master adapte l’infrastructure en fonction du trafic
  • 11. Manon Cuylits Master 1 2012-­‐2013 11 3. CYCLE DE DEVELOPPEMENT D’UN LOGICIEL • le développement d’un logiciel est progressif o la complexité impose une découpe o un projet est souvent organisé en phases o une phase est le lieu d’activités Thierry Van den Berghe Le développement est progressif. Pourquoi ? Aujourd’hui les demandes des utilisateurs et les technologies qu’on veut mettre en place sont tellement complexes qu’on doit structurer en différentes phases. • le cycle de développement précise les interrelations entre les phases : o dans quel ordre et à quelle fréquence exécuter les phases? o quels critères pour passer d’une phase à l’autre? o quels délivrables pour chaque phase? Le cycle de développement précise les interrelations entre les différentes phases. Dans quel ordre enchainer les phases ? Faut-­‐il exécuter les phases plusieurs fois ? Qu’est ce qui déclenche le passage d’une phase à l’autre, etc. CYCLE DE DEVELOPPEMENT EN CASCADE Cycle de développement en cascade : On enchaine les différentes phases, une seule fois : l’output est déversé en tant qu’input dans la phase suivante. On enchaine de manière linéaire Ø la spécification du système Ø la conception du système Ø la mise en oeuvre du système Ø le test du système Ø la mise en production du système
  • 12. Manon Cuylits Master 1 2012-­‐2013 1. Ce cycle en cascade, en une seule séquence n’est pas très réaliste, essentiellement parce que la spécification du système (= la description des attentes de l’utilisateur) n’a lieu qu’à la première étape puis qu’on n’y retourne pas. Cela suppose que l’utilisateur connaît exactement ses attentes et qu’elles n’évoluent pas, ça ne se passe pas comme cela dans la réalité. Il est difficile pour les utilisateurs et les spécialistes de cerner les besoins, en outre, dans un environnement changeant, ces besoins sont instables. Pour finir, les systèmes à construire sont complexes. • lourdeur des tests concentrés en fin de cycle • les risques restent présents très tard dans le projet, car peu de tests en début de 12 EVALUATION DU CYCLE EN CASCADE 2. Mise en production selon un mode "big bang" Développement de systèmes e-­‐business projet 3. Limité aux projets réduits en taille et en durée de développement PLUSIEURS APPROCHES POUR MAITRISER LA COMPLEXITE Pour maitriser la complexité d’un développement, il existe plusieurs approches possibles. Ø Diviser le problème : Le projet est subdivisé en sous-­‐projets portant sur le développement d'une partie du système (module). Les modules sont développés dans le cadre d’une itération. è Cycles de développement itératifs. è Quand le problème a résoudre est très ardu, on peut essayer de diviser le système e-­‐ business en différents modules : un module de vente, un module de suivi de commande, un module de facturation, etc. Ensuite on développe ces modules les uns derrières les autres. On parle de cycle de développement itératif : on re-­‐parcours. Ø Résoudre le problème en plusieurs passes : Deuxième approche pour maitriser la complexité : retravailler plusieurs fois le système ou des parties du système. Jusqu’au moment ou on obtient un système ou sous système qui donne satisfaction. Le système est construit en plusieurs passes jusqu’à être utilisable. è Prototypage (très bien) Ø le choix de l’approche dépend de la complexité du problème mais des coûts s’ajoutent en termes de gestion de projet
  • 13. Manon Cuylits Master 1 2012-­‐2013 13 Possible de combiner ces deux approches mais il n’y a pas d’approche figée, universelle. Thierry Van den Berghe è Adaptation en fonction des particularités etc. ITERATION L’application du cycle en cascade sur un module produit un délivrable testable et dure typiquement 2 à 6 semaines. Itération : c’est le parcours de quelques phases clés è ce parcours peut être répété a chaque itération. Les itérations sont répétées un certain nombre de fois en fonction de la complexité et l’importance du système. Les premières itérations portent sur les aspects les plus risqués du système Si je divise mon système en différents modules je vais avoir une itération par module è peuvent être répétées si on veut construire le système morceau par morceau ou le construire en plusieurs passes (parce que super compliqué) Exemples d’activités reprises dans une itération : -­‐ analyse (étude des besoins) + conception + mise en oeuvre (programmation) ou -­‐ collecte des besoins + analyse + conception + mise en oeuvre + test On répète ces phases au sein d’une itération MAITRISE PROGRESSIVE DES RISQUES Idée : en travaillant par itération on maitrise mieux les risques.
  • 14. Manon Cuylits Master 1 2012-­‐2013 L’idée du cycle itératif est de ne pas développer tout le système en une fois, mais de le découper en plusieurs modules et de le livrer en plusieurs fois 14 CYCLE ITERATIF Développement de systèmes e-­‐business è développement modulaire : • le système est décomposé en modules • les modules sont produits et testés à sein d’une itération • les modules sont intégrés progressivement dans le système final Les itérations sont organisées en cascade et durent peu de temps, ce qui assure une certaine stabilité. PROTOTYPAGE
  • 15. Manon Cuylits Master 1 2012-­‐2013 On peut combiner décomposition et prototypage et, par exemple, faire travailler des équipes en parallèle. 15 DECOMPOSITION + PROTOTYPAGE Thierry Van den Berghe è Exécution parallèle des itérations, etc. c’est très bien mais cela a un cout en terme de gestion de projet.
  • 16. Manon Cuylits Master 1 2012-­‐2013 16 2. LANCEMENT DU PROJET Développement de systèmes e-­‐business Un projet est souvent initié par les utilisateurs qui éprouvent un nouveau besoin ou qui identifient une opportunité d’affaire. Par exemple, suite à un besoin de communication en interne on lancera un projet intranet ou encore suite à l’identification d’une opportunité de vente à distance, on lancera un projet de boutique Web. èEn général la plupart des initiatives proviennent des collaborateurs de l’entreprise qui trouvent qu’une automatisation complémentaire serait bénéfique. Il faut vérifier si le projet réalise la vision et la stratégie de l’entreprise. Par exemple, si l’objectif stratégique de l’entreprise est la maximisation des compétences internes, un projet qui rentre dans le cadre serait celui d’un intranet sur lequel partager les connaissances. è L’initiateur du projet va devoir le défendre devant un décideur. L’alignement stratégique est important dans ce cadre. Qu’est ce qu’implique les taches managériales de gestion de projet ? Le lancement d’un projet implique 3 choses : Ø cadrer le système (QUOI) è définition de la portée du système : Que veut on exactement ? Ø identifier les ressources (QUI) è gestion des acteurs : Qui va être impliqué dans le développement à tous les niveaux ? Ø planifier les tâches (QUAND et COMMENT) è gestion du projet è La planification des tâches va déterminer l’ordonnancement du projet Les activités liées au lancement de projet se retrouvent dans des projets d’autre nature que projet de développement e-­‐business
  • 17. Manon Cuylits Master 1 2012-­‐2013 17 1. DEFINITION DE LA PORTEE DU SYSTEME E-­‐BUSINESS Thierry Van den Berghe Objectifs : Ø Montrer comment le projet rencontre les préoccupations de l’entreprise, comment le système réalise les objectifs stratégiques de l’organisation en fonction des contraintes Ø Positionner le futur système dans la chaine de valeur de l’organisation On a le département vente et on estime qu’un site de vente en ligne pourrait améliorer la valeur apportée par ce département. Ø Elaborer une description suffisante du système pour une première estimation de l’effort de développement è Imaginer le futur système (allure du futur site de vente ou autre) pour pouvoir déterminer une estimation de cout (combien cela coute et rapporte ?) Activités : Ø Décrire le contexte et la motivation du système (métier de l’organisation, objectifs stratégiques, etc.) Ø Identifier les objectifs, les contraintes, les fonctions et la cible du système Ø Identifier la valeur apportée par le système EXEMPLE : EM2 Document de cadrage de projet, on veut motiver notre idée è on va spécifier le contexte et la motivation Contexte et motivation: Ø un détaillant d’électroménagers, EM2, gère son service après-­‐vente (SAV) manuellement et sans procédures claires. EM2 fournit peu d’informations aux clients après la vente (conseils d’utilisation, etc.) Ø EM2 a pour objectif stratégique de fidéliser sa clientèle. Pour cela, elle souhaite augmenter la valeur de son SAV en proposant une meilleure information à sa clientèle et en coordonnant le travail de l’équipe SAV è projet de développement d’un système e-­‐business pour le SAV Ici : idée d’automatisation d’un service après vente (SAV) pour une chaine de magasin qui vend de l’électroménager. On précise l’objectif qui est augmenter la valeur du service après vente en proposant une meilleure information a la clientèle et en coordonnant mieux le travail de l’équipe. Cette motivation s’inscrit dans un objet de l’entreprise qui pourrait être de fidéliser la clientèle. Un SAV de meilleure qualité va contribuer à rendre le client plus content (è fidélisation).
  • 18. Manon Cuylits Master 1 2012-­‐2013 18 Développement de systèmes e-­‐business è On voit comment ce projet de développement rentre dans ces préoccupations de haut niveau de l’entreprise Objectifs du système : Qu’est ce qu’on attend de ce système dans les grandes lignes ? Ø informer le client après l’achat Ø formaliser la gestion des réparations è Objectifs qui restent assez génériques mais on va les détailler Les contraintes du projet : Ø budget: 26000€/délais: 6mois Ø ressources internes : limitées au responsable du SAV Après on peut passer dans une description plus détaillée de ce qu’on attend du système, ici on reste vague. Les fonctions du système : Ø publier les modes d’emploi des appareils vendus Ø publier des FAQ alimentés par les réparateurs Ø automatiser la planification des demandes de réparation chez le client Ø tracer les étapes des réparations en magasin Cible : Ø réparateur SAV Ø clients è On veut connaitre la cible du système : ici les clients et les réparateurs du SAV sont ceux qui vont exploiter cette plateforme. Il faut ensuite identifier des catégories de clients pour un site de vente en ligne è Clients dans la catégorie professionnelle etc. C’est important pour personnaliser le système par rapport aux segments de clientèle. La valeur du système est attendue à 2 niveaux : Ø client : accompagnement après l’achat, rapidité et transparence dans l’organisation des réparations Ø réparateurs SAV : partage et centralisation de la connaissance en interne, meilleure coordination des réparations
  • 19. Manon Cuylits Master 1 2012-­‐2013 Dans quelle mesure le système va contribuer à apporter de la valeur pour le client et l’entreprise. Exemple : au niveau des réparateurs meilleure organisation dans la planification des réparations. 19 Thierry Van den Berghe è Grâce à des fiches de suivi dans les réparations. 2. GESTION DES ACTEURS Objectifs : maximiser les chances de réussite du projet en mobilisant et en gérant les ressources les plus adaptées Réfléchir sur les acteurs : Le projet va être pris en charge par une équipe. Même dans un projet de haute technologie, les personnes sont souvent un problème è il est crucial (Facteur Clé de Succès) de constituer une équipe compétente qui fonctionne bien. Pour ce, il y a des tâches à réaliser : Ø identifier les compétences et rôles (lister les compétences nécessaires, elles sont multiples è Impose des profils techniques très variés) Ø désigner les acteurs du projet et constituer une équipe (une fois les rôles à remplir listés, les assigner à des personnes disponibles) Ø gérer l’équipe du projet (une fois l’équipe constituée il faut la gérer) L’EQUIPE DE PROJET : UN FACTEUR CLE DU SUCCES La dimension humaine est importante dans un projet e-­‐business Ø la technologie n'est qu'une des composantes d'un projet informatique Ø les problèmes humains sont souvent plus intenses que les problèmes techniques Les relations humaines doivent être soigneusement gérées Ø construire un esprit d'équipe et une relation de confiance Ø veiller à la bonne communication entre utilisateurs et informaticiens Ø gérer pro-­‐activement les conflits Le courant doit passer, l’équipe doit fonctionner etc. è La dimension humaine est vraiment cruciale. On tente de gérer pro-­‐activement l’équipe, gérer les conflits, etc. Une gestion proactive des ressources humaines est tout à fait essentielle.
  • 20. Manon Cuylits Master 1 2012-­‐2013 nombreux rôles et équipe La particularité des développements e-­‐business c’est que pour qu’un site de vente en ligne soit attractif par exemple, on a besoin de beaucoup de compétences. Des spécialistes en Base De Données, en sécurité, des ergonomes sont des besoins. Exemple : conception de la charte graphique, design d'un site, 20 EQUIPE D’UN PROJET E-­‐BUSINESS Un projet e-­‐business comporte de nombreuses dimensions è pluridisciplinaire. Par exemple, un site de vente doit être attractif è besoins de compétences artistiques etc. Développement de systèmes e-­‐business Catégories d'acteurs : Ø utilisateurs : spécialistes métier Ø informaticiens : spécialistes des TIC Ø experts : apport ponctuel de compétences de pointe Ø sponsor : apport du financement ACTEURS PRINCIPAUX D’UN PROJET E-­‐BUSINESS
  • 21. Manon Cuylits Master 1 2012-­‐2013 21 Catégories d’acteurs qu’on retrouve dans la plupart des projets e-­‐business : Thierry Van den Berghe Ø Utilisateurs : Compétences : ils connaissent parfaitement leur métier. On les appelle les spécialistes du domaine d’application (métier, situation concrète pour lequel on utilise la technologie de l’information) Ø Sponsors : C’est celui qui libère les fonds, pas d’implication directe dans le projet, mais il donne son aval pour l’engagement de budget. Ø Informaticiens : Ce sont les spécialistes des technologies. On a pleins de déclinaisons : chef de projet, analyste, programmeurs, designer, ergonome, etc. Ø Experts Ils apportent une compétence pointue à un moment donné. L’expert en sécurité, par exemple, s’assure du niveau de sécurité raisonnable du système. Le qualiticien est responsable qualité, c’est quelqu’un qui aide le chef de projet à gérer la qualité. Quel peut être le niveau d’intervention d’un juriste dans un projet e-­‐business ? Si on développe des sites qui collectent des données à caractère personnel par exemple, un juriste sera nécessaire. Le juriste sera également utile lors de la rédaction d’un contrat de service è par exemple dans le cas de développement IT fait en extérieur, il est important de rédiger un contrat en bonne et due forme. CHEF DE PROJET Le chef de projet conduit le projet Ø Il planifie, désigne les personnes et assigne les responsabilités Ø Il surveille le déroulement et prend des mesures correctives Ø Il rapporte au management Le chef de projet dispose de compétences managériales plutôt que techniques Ø gestion d'équipe, coordination d’équipe Ø facultés d'écoute et de compréhension Ø esprit de décision Ø sens de l'organisation Ø autorité Ø culture générale de la technologie
  • 22. Manon Cuylits Master 1 2012-­‐2013 22 EXEMPLE DE PROFILS DE CHEF DE PROJET 3. GESTION DE PROJET Objectif: fournir un support organisationnel à la réalisation d'un projet Tâches Développement de systèmes e-­‐business principales: Ø préparer le projet o identifier et planifier les tâches du projet o assigner les ressources o déterminer les contraintes du projet Ø suivre le projet (pendant les phases ultérieures) o contrôler l’avancement de projet et éventuellement prendre des mesures correctives o capitaliser l’expérience RESULTAT SOUS CONTRAINTES Un projet doit fournir un système de qualité fixée sous contraintes.
  • 23. Manon Cuylits Master 1 2012-­‐2013 23 TECHNIQUES DE PLANIFICATION Ø Intention : planifier et synchroniser plusieurs tâches interdépendantes Thierry Van den Berghe réalisées par des acteurs Ø Diagramme de Gantt (1917) è présentation graphique des tâches dans un calendrier Ø PERT : Program Evaluation and Review Technique (US-­‐ Navy, 50') o présentation graphique des relations entre tâches o marge totale : intervalle de temps pendant lequel une tâche peut être différée sans différer la date de fin du projet o chemin critique : séquence de tâches pour lesquelles une modification de durée entraîne une modification de la durée du projet EXEMPLE DE GANTT AVEC CHEMIN CRITIQUE
  • 24. Manon Cuylits Master 1 2012-­‐2013 ne peuvent être rallongées ou différées sous peine de ces tâches ont une marge. Prenons le cas d’une tâche avec une marge importante, on pourra la réaliser plus loin dans le processus par exemple, sans que la date de fin du projet ne soie impactée. 24 Tâches en rouge : tâches critiques è retarder l’ensemble du projet. Les tâches critiques n’ont aucune marge. Tâches en bleu : tâches non-­‐critiques è EXEMPLE D’ALLOCATION ETUDE DE CAS : SPORTS D’HIVERS Développement de systèmes e-­‐business
  • 25. Manon Cuylits Master 1 2012-­‐2013 25 Thierry Van den Berghe Contexte et motivation: Ø la promotion et la prise d'inscription aux SH prennent beaucoup de temps car ces deux opérations sont complètement manuelles. Chaque année, il faut recommencer les mêmes actions sans pouvoir réutiliser les acquis des années précédentes (affichage, etc.) Ø le cercle des étudiants s'est fixé comme objectif stratégique de soutenir davantage les étudiants en difficulté (scolaire, financière, etc.). Comme le cercle connait des problèmes de recrutement récurrents, il compte sur davantage d'automatisation pour soutenir sa stratégie et recentrer l'équipe sur des projets où les personnes ont une valeur ajoutée importante Ø l'organisation des SH est actuellement manuelle et consomme beaucoup de main d'oeuvre è lancement d'un projet de développement d’un système e-­‐business pour la gestion des SH Objectifs du système : Ø présenter l'offre de SH du cercle Ø promouvoir l'offre de SH du cercle Ø suivre les inscriptions des étudiants participants Les contraintes du projet : Ø budget: 1000€/délais: 6 mois Ø ressources internes : l'équipe du cercle et, ponctuellement, le service informatique de l'école Les fonctions du système : Ø présentation de l'offre o publication des informations détaillées sur le voyage (Exemple : destination, prix, service, etc.) o publication des conditions générales / responsabilité (Exemple : modalités de paiement, désistement, assurance, etc.) o publication du nombre de places disponibles et de la liste des inscrits Ø promotion de l'offre o publication électronique de l'affiche d'annonce o mailing de prospection auprès des étudiants non inscrits Ø suivi des inscriptions des étudiants participants o enregistrement d'une inscription o enregistrement d'un désistement o suivi des paiements o envois de mails de confirmation d'inscription et de rappel de paiement
  • 26. Manon Cuylits Master 1 2012-­‐2013 26 Développement de systèmes e-­‐business Cible : Ø étudiants Ø gestionnaires du voyage La valeur du système est attendue à 2 niveaux : Ø étudiants : o disponibilité de l'information o disponibilité de la procédure d'inscription/désistement o validation et confirmation de l'inscription Ø gestionnaires du voyage : o automatisation de la gestion de l'inscription o suivi centralisé et organisé des désistements et des paiements o automatisation de la communication o réutilisation du système d'année en année Rôles et compétences : Ø chef de projet o coordonne le projet et rapporte au sponsor o sens de l'organisation, disponibilité, maîtrise de MS-­‐Project Ø analyste/programmeur o collecte les besoins des utilisateurs, conçoit et met en oeuvre le système o maîtrise des langages de modélisation et des outils de développement Ø représentant utilisateur o formule les attentes des utilisateurs o expérience dans l'organisation des SH Ø sponsor o veille à l'alignement stratégique du projet et décide de la libération des fonds Ø hébergeur o déploie le système dans une infrastructure WEB o compétences techniques dans la gestion de serveurs et réseaux Equipe : Ø chef de projet : Sophie souhaite s'investir dans le cercle et a une expérience de coordination de projets (mouvement de jeunesse) Ø analyste/programmeur : Nabil est bachelier en informatique et adore la programmation
  • 27. Manon Cuylits Master 1 2012-­‐2013 Ø représentant utilisateur : Magali a organisé les SH les deux années précédentes Ø sponsor : Arnaud est le président du cercle des étudiants Ø hébergeur : Eric gère l'infrastructure WEB de l'école et est prêt à héberger 27 Thierry Van den Berghe gratuitement le système Planification : Etude de cas : sports d’hiver è Petite synthèse : On va voir ce qu’on doit produire comme infos pour définir une première idée du projet. Ici, on est chef du projet et responsable d’un site d’inscription en ligne. Ø 1ère étape : Lancement du projet Essayer de motiver le projet par rapport aux intentions et objectifs stratégiques de l’entreprise (ici le cercle des étudiants) Ø Priorité du cercle : Aider les étudiants qui ont des difficultés Par rapport à cet objectif, on veut automatiser certaines activités du CDE pour que toute une série de taches qui étaient réalisées manuellement puissent être automatisées. On va développer une plateforme d’enregistrement en ligne pour les sports d’hivers. On voit un alignement stratégique du projet par rapport aux objectifs du cercle. Ø Objectifs du système : Rappel : un projet est un exercice de maximisation du résultat et de sa qualité sous contrainte (contraintes cf. slide è les plus évidentes sont celles de budget et de délai, mais il y a également des contraintes légales, etc.)
  • 28. Manon Cuylits Master 1 2012-­‐2013 On va essayer d avoir une première description de l’équipe et du planning On va détailler les fonctions du système, quelles sont les facilités attendues de ce système web. Un aspect super important des projets e-­‐business est l’aspect humain. Les problèmes les plus fréquents proviennent de la gestion des personnes. De ce fait, l’identification des rôles et personnes nécessaires est préconisée. Une fois qu’on a listé les rôles et compétences associées, on peut essayer de constituer notre équipe. Une fois qu’on a identifié les différents rôles on peut passer a la planification avec un logiciel. On part d’une série de taches interdépendantes dans le temps et planifiées. On a assigné les différentes taches aux membres de l’équipe. On a décomposé le système en différents modules on fait souvent cela en informatique car le développement d’un système en un coup c'est trop compliqué, donc on le découpe en différents modules, on le découpe dans l’espace, et si certains modules sont complexes à mettre au point on applique une technique de prototypage construction du système par 28 Ø Cible (à préciser) : à qui s’adresse le système ? -­‐ Aux étudiants -­‐ Aux responsables du CDE qui gèrent le voyage Il faut motiver la valeur qu’apporte ce système dans la chaine de valeur. è è Développement de systèmes e-­‐business itérations successives. Ø 2eme étape : L’étude d’opportunité (voir chapitre suivant)
  • 29. Manon Cuylits Master 1 2012-­‐2013 29 3. ETUDE D’OPPORTUNITE Thierry Van den Berghe Objectifs -­‐ prendre la décision d'engager ou non le projet (pass or fail), d’engager des fonds dans le projet en considérant : o l'apport du projet è voir si il est supérieur aux investissements o la faisabilité du projet Tâches -­‐ 1ère étape : réaliser une critique de l'existant pour identifier les lacunes que le futur système pourrait combler. Si il y a un système déjà existant, la première chose à faire pour motiver le nouveau projet est d’identifier les lacunes du système existant. La critique doit être constructive, l’objectif est de mettre des lacunes en évidence qu’on évitera de reproduire dans un futur système. -­‐ 2ème étape : essayer de réaliser une étude pour évaluer l'apport du futur système o calcul du retour sur investissement (ROI) o évaluation en terme de bénéfices intangibles -­‐ 3ème étape : évaluer la faisabilité face aux risques 1. RETOURS D’UN SYSTEME RENTABILITE D’UN PROJET DE DEVELOPPEMENT Plusieurs techniques purement financières • ROI = bénéfices annuels / coûts annuels • valeur actuelle nette – VAN, taux de rentabilité interne – TRI, etc.
  • 30. Manon Cuylits Master 1 2012-­‐2013 La difficulté c'est que l’évaluation d’un retour purement financier est souvent défavorable parce que souvent l’IT participe aux frais de structure, des activités, etc. C’est comme la GRH, le département IT n’a pas un apport direct au chiffre d’affaires. è exemple) ce ne sera souvent pas un 30 Si on utilise les techniques habituelles (le ROI par argument prédominant pour motiver le projet. Il y a une série de bénéfices indirects ou intangibles à considérer aussi Développement de systèmes e-­‐business : • les bénéfices intangibles o Exemple : amélioration de l’image de marque après un redesign d’un site • les opportunités offertes par l'application des TIC o Exemple : apports de clients étrangers grâce à la vente en ligne Exemple : on a une nouvelle plateforme intranet, on peut espérer a terme augmenter la compétence et productivité des collaborateurs. è Ce n’est pas mesurable purement financièrement. On va quand même calculer un ROI, même si il est négatif mais on va compléter grâce à une argumentation qui liste tous les bénéfices intangibles ou indirects qu’on espère retirer du projet. Ex-­‐post, une fois le système déployé, on pourra vérifier après une période de mise en production, le gain en chiffre d’affaires, etc. au niveau global. è Il faut essayer d’identifier les couts pcq c'est la première chose qu’on demande : combien cela coute et combien ca rapporte. RETOUR SUR INVESTISSEMENT : COUTS Coûts directs è ce sont les coûts identifiables, liés directement au SI Il faut intégrer les couts de développement et de maintenance lorsque le système est en exploitation. • CAPEX (capital expenditure) : développement logiciel, matériel, déploiement, formation • OPEX (operational expenditure) : maintenance, hébergement, support cf. métrique d'évaluation d'ampleur et d'efforts. Coûts indirects è ce sont les coûts difficilement identifiables et peu prévisibles Exemple : correction d'erreurs, perte de productivité due à l'apprentissage d'un nouveau système, etc.
  • 31. Manon Cuylits Master 1 2012-­‐2013 Les couts indirects sont plus délicats à évaluer. On peut s’attendre à une perte de productivité les premiers jours ou semaine de la mise en service des nouveaux systèmes parce que l’utilisateur doit se familiariser etc. 31 è pas facile à évaluer. RETOUR SUR INVESTISSEMENT : BENEFICES Thierry Van den Berghe Bénéfices tangibles è quantifiables • réductions des coûts ou augmentation des bénéfices o Exemple : réduction du coût des transactions commerciales ou nouveau canal de vente par Internet Bénéfices intangibles è difficilement quantifiables • bénéfices pour l'organisation o Exemple : meilleure communication entre les collaborateurs, meilleures sources d'information pour la prise de décisions, meilleure ergonomie • bénéfices pour le client o Exemple : meilleure disponibilité de l'entreprise, meilleure information sur les produits et services è On va avoir des bénéfices chiffrables ou tangibles, par contre on va en avoir des intangibles, difficilement chiffrables, ils doivent être mentionnés mais on ne peut pas les chiffrer précisément. Exemple : L’avantage pour un client est un bénéfice intangible EXEMPLES D’APPORTS ATTENDUS è Quelques arguments classiques pour motiver un projet e-­‐business. Ces arguments permettent de convaincre que le projet apporte vraiment de la valeur Améliorer l’efficience opérationnelle • réduire les coûts de production des biens vendus o Exemple : vente de musique en ligne • réduire les coûts de vente et d’administration o Exemple : suppression des documents papier pour les transactions commerciales • réduire les coûts de gestion des services o Exemple : self-­‐banking
  • 32. Manon Cuylits Master 1 2012-­‐2013 32 Augmenter la compétitivité • disponibilité 7/7 et 24/24 • améliorer les interactions avec le client Développement de systèmes e-­‐business o Exemple : informer et conseiller en ligne • augmenter la rapidité de la mise sur le marché o Exemple : outil de production largement paramétrable Améliorer la gestion des données • augmenter la fiabilité des données • réduire les redondances • améliorer la diffusion d'information o Exemple : intégration électronique des commandes client dans le système du fournisseur Réduire les risques • améliorer la surveillance de l’activité o Exemple : tableaux de bord de gestion produits de manière largement automatisée o Exemple : état des stocks en temps réel _ moins de risque de rupture ð Augmenter la valeur des actionnaires en profitant de l'ensemble des bénéfices apportés par le système 2. FAISABILITE D’UN PROJET L’étude de faisabilité d’un projet est la 2ème chose à faire dans le cadre de l’étude d’opportunité. Parfois le projet n’est pas réaliste. Ø Exemple 1 : un système de correction automatique des examens pour les professeurs, ce n’est pas réaliste, les technologies ne suivent pas. Ø Exemple 2: se faire soigner par un robot, on n’est peut être pas encore prêt pour cela, même si on peut démontrer que cela fonctionne.
  • 33. Manon Cuylits Master 1 2012-­‐2013 On doit montrer qu’on peut maitriser les risques liés au déroulement du projet, les risque 33 FAISABILITE FACE AU RISQUE Le projet est faisable si les risques peuvent être raisonnablement maîtrisés. Il est important de voir si on peut maitriser les risques, même si l’idée est bonne, etc. è techniques, les risques liés à la viabilité du logiciel. Maîtriser les risques liés au déroulement du projet Ces risques impactent le plan du projet Ø Exemple : comment gérer une absence de longue durée d’un acteur? Maîtriser les risques techniques Ces risques impactent la qualité du logiciel Ø Exemple : faible qualité d’un système de correction automatique d'examens Ø Exemple : faible performance d’un système de distribution de vidéos en ligne Maîtriser les risques business liés à la viabilité du logiciel Thierry Van den Berghe (à la volonté des utilisateurs de mettre le logiciel en utilisation) Ces risques impactent la valeur attendue du logiciel Ø Exemple : excellent système mais que personne n'utilise Ø Exemple : digitaliser toute la communication via email, forum et WiKi Ø Exemple : vote électronique (typique) : Techniquement, le vote électronique est plus ou moins au point, il existe mais n’est toujours pas accepté pour des raisons indépendantes des 2 risques ci-­‐dessus (risques techniques et risques liés au déroulement du projet) è manque d’adhésion des utilisateurs. ARTICLE SUR LE VOTE ELECTRONIQUE "Le vote électronique a-­‐t-­‐il du plomb dans l’aile ? Selon nos informations, le ministre de l’Intérieur a toutes les peines du monde à convaincre ses partenaires de poursuivre dans la voie initiée en 1991, lorsque les premières machines furent installées dans notre pays.... Aux dernières élections, le vote automatisé a concerné 44 % des électeurs, soit 100 % à Bruxelles, 22 % en Wallonie et 49 % en Flandre. Depuis son introduction, le vote électronique n’a cessé de susciter réserves et critiques. Censé rendre le vote plus fiable, le dépouillement plus rapide et le scrutin moins onéreux, il n’a pas fait la preuve de son efficacité jusqu’ici. ... De l’aveu même du ministre de l’Intérieur, il coûte
  • 34. Manon Cuylits Master 1 2012-­‐2013 trois fois plus cher (4,5 euros par électeur contre 1,5 pour le vote papier). Aux législatives de 2007, on a enregistré 400 incidents. Quantaugaindetemps... «A Liège ou Bruxelles, totalement informatisés, on a eu les résultats après minuit», rappelle Michel Staszewski, de l’association Pour Eva (Pour une éthique du vote automatisé), qui milite pour un retour au vote papier, seul garant à ses yeux de transparence et de contrôle démocratique. Tel est le problème majeur, selon les détracteurs : « L’exemple est célèbre de cet élu schaerbeekois qui a obtenu plus de voix de préférence qu’il n’y avait de votants. Il y en a eu d’autres, et encore ces cas ne sont-­‐ils que la partie émergée de l’iceberg, puisque sans contrôle humain, les erreurs peuvent passer inaperçues ». D’autres ont fait machine arrière. Les Pays-­‐Bas, les plus avancés d’Europe, ont été contraints par la justice d’abandonner le vote électronique. Et l’Irlande y a renoncé malgré de lourds investissements”. Par exemple, on souhaite développer un site pour gérer les sports d’hivers du CDE. Combien cela va-­‐t-­‐il couter ? Comment dégager un ordre de grandeur ? Il existe un grand nombre de techniques pour estimer les couts de main d’oeuvre liés au développement. • 1ère estimation : effort * coût moyen mensuel d’une ressource • 2ème estimation : calcul du coût de chaque tâche en fonction des ressources • pour déterminer précisément les coûts, le système doit être au moins la suite : présentation simplifiée et adaptée de la métrique des points de fonction et du modèle 34 3. EVALUATION DU COUT D’UN SYSTEME ESTIMATION DES COUTS DE DEVELOPPEMENT But: dégager des ordres de grandeur pour décider de la faisabilité affectées (cf. planification) complètement décrit Utilisation de métriques et modèles pour : • on va essayer d’estimer le volume du système à développer • estimer les ressources humaines à allouer au projet • dans Développement de systèmes e-­‐business COCOMO. Pour une discussion complète : Donald J. Reifer, Estimating Web Development Costs: There Are Differences, http://www.reifer.com/ ; http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html, On saura si le système va couter 5000, 500000 ou 20000000 euros. On pourra déjà trancher sur l’opportunité du projet. Cette estimation n’est pas précise parce qu’on en est qu’à l’avant-­‐projet, on n’a pas encore décrit complètement le système. Il faut aller plus loin pour
  • 35. Manon Cuylits Master 1 2012-­‐2013 cela, par exemple avoir une idée de toutes les tâches a déployer pour faire un calcul très précis, une estimation plus précise du cout du développement. Exemple : construction d’une maison. Grosso modo on sait ce qu’on veut, on va faire un premier dessin avec l’architecte mais sans trop de détails. On va dégager une surface (volume du système). Par exemple : maison de 150 mètres carrés. A partir de cela, on va regarder par rapport a des projets antérieurs (par exemple) le cout moyen 35 Thierry Van den Berghe è règle de trois. On va obtenir un budget (ordre de grandeur, estimation). On va d’abord estimer le volume du système puis les ressources allouées au projet. On a besoin de deux outils : le point de fonction et les ressources à allouer au projet Ici on va voir des versions simplifiées des modèles qu’on trouve sur le terrain. On va voir les grands principes pour voir qu’il est possible de déterminer une estimation de cout d’un système même si on n’est pas informaticien. è Objectif du cours : faciliter le dialogue entre le gestionnaire et le spécialiste. ANALYSE PAR POINTS DE FONCTION (FP) Principe : identifier les éléments de l'application à construire (paramètres) et les pondérer en fonction de leur complexité Objectif : dégager une estimation a priori du volume de l'application
  • 36. Manon Cuylits Master 1 2012-­‐2013 Ici on va essayer de décrire, projeter le futur système. On va identifier des grands composants du système. L’utilisateur doit faire une démarche pour imaginer le système auquel il pense. 36 Ici on va projeter le système auquel on pense en différents paramètres Développement de systèmes e-­‐business -­‐ les entrées : les lots d’informations rentrant dans le système. Ex : un écran de saisie, un écran pour enregistrer le descriptif du voyage, un autre pour enregistre les données de l’élève qui souhaite participer au voyage, etc. -­‐ Les sorties Exemple : rapport, facture, graphe sur écran. -­‐ Les requêtes : une extraction des données avec une certaine valeur ajoutée. -­‐ Les fichiers ou tables : grappes principales de données. Exemple : séjour, réservations, des étudiants qui veulent participer, des payments -­‐ Les fichiers multimédias : Exemple : page d accueil, page statique etc. -­‐ Les composants Web réutilisables à intégrer : è importés en tant que composants dans le système qu’on est en train de développer. Exemple : On doit développement un écran de login : L’écran de login est un écran avec 2 zones : Ø le login Ø le password. Pour un informaticien professionnel, ce n’est pas beaucoup de travail. Ce sera quelque chose de très simple à construire. Par contre, un écran de commande avec le calcul de livraison, de TVA etc., c'est plus compliqué à construire parce qu’il y a des calculs, de nombreuses zones, etc. Dans un premier temps on va surtout se concentrer sur le principe et pas la complexité. Chaque valeur de paramètre aura un certain poids, à calculer en fonction des différents poids et éléments identifiés, un nombre de points de fonction, unité qui représente l’ampleur du système.
  • 37. Manon Cuylits Master 1 2012-­‐2013 37 EXEMPLE Thierry Van den Berghe Ici on a, par exemple, un écran de saisie client, c’est simple. Un écran de saisie de facture, ou de saisie produit c’est déjà plus compliqué, plus élaboré. Ici on a une valeur abstraite de 106 points de fonction. Avec cela on n’est pas très avancé. Ca représente un certain nombre de points de fonction mais qu’est ce que ca représente en terme d’hommes/mois au niveau du développement? PARAMETRES • la liste des paramètres peut évoluer è La liste des paramètres n’est pas figée, il y a des variations des points de fonction. è autres paramètres possibles: communication inter-­‐systèmes, intégration de composants, données à récupérer, etc. è Cela peut aussi mobiliser de l’énergie des développeurs et donc faut les considérer. Ici ce sont des exemples parmi d’autres. • un besoin d’un utilisateur peut conduire à plusieurs valeurs de paramètres o Exemple : une facture peut nécessiter un travail de mise en forme important et la construction d’une requête complexe. Si je demande au développeur d’écrire un système qui va me permettre d’encoder des factures =>… les données enregistrées a travers écran vont devoir être enregistré dans des tables (2eme paramètre) et il y aura peut être une sortie… • des corrélations peuvent exister dans l’évaluation des paramètres (souvent il y a des corrélation au niveau des points de fonction, des paramètres, et souvent on retrouve ces paramètres) o Exemple : une table a souvent un équivalent écran de saisie
  • 38. Manon Cuylits Master 1 2012-­‐2013 38 EXEMPLE D’UNITES DE PARAMETRES Ici on va voir quelques indications qui permettent dévaluer la difficulté de tel ou tel écran. Développement de systèmes e-­‐business • entrée : écran de saisie è permet de créer de l’information, de l’éditer o évaluation de la complexité : § nombre de zones de saisie/affichage – nombre de zones qui doivent être saisies par l’utilisateur. Si j’ai juste un nom d’utilisateur et un mot de passe, ce n’est pas un écran qui va demander beaucoup de travail de programmation. Un écran avec beaucoup de zones calculées contribue à la complexité de l’écran (ex : calcul du total d’une facture ou autre). § importance des contrôles de validité des données. § importance de l’automatisme dans la saisie (remplissage automatique, proposition de données à l’utilisateur, etc.) o unité alternative : messages digitaux en provenance d’autres systèmes • sortie : rapport à imprimer è si on doit programmer des rapports papier ou écran avec beaucoup de calculs différents, ou graphiques, alors cela représente beaucoup de travail, et cela fait monter la complexité du rapport. o évaluation de la complexité : § difficulté de la mise en page § variété de l’information à représenter § construction de graphiques o unité alternative : messages digitaux à envoyer vers d’autres systèmes • requête : interrogation d’une base de données è il y a des requêtes plus simples que d’autres et parfois une requête peut impliquer plusieurs requêtes successives. o évaluation de la complexité : § nombre de tables et de champs à accéder § importance des calculs à réaliser (agrégation, etc.) o unité alternative : outil de recherche textuelle • table ou fichier : table d’une base de données relationnelle o évaluation de la complexité : § nombre de champs – nombre de colonnes § importance des contraintes
  • 39. Manon Cuylits Master 1 2012-­‐2013 39 Thierry Van den Berghe • fichier multimédia : conception d’un page Web type è un peu comme les écrans de saisie, le nombre de zones à indiquer à l’écran induit une lourdeur. o évaluation de la complexité : § nombre d’éléments d’information à présenter § difficulté de la mise en forme Exemple : une page d'accueil avec des menus est plutôt complexe – il y a des modules qu’on intègre, c'est toujours complexe Exemple : une page avec des graphiques est plutôt de difficulté moyenne • composant Web à intégrer o évaluation de la complexité : § complexité de paramétrage du composant § interactions avec le site Web -­‐ interaction entre les composants Exemple : passage de paramètre vers un module de paiement est plutôt complexe Exemple : saisie d'information par le composants (News, forum, etc.) est plutôt complexe EXEMPLES DE COMPOSANTS WEB
  • 40. Manon Cuylits Master 1 2012-­‐2013 Ce modèle n’a pas des points de fonction comme entrée mais bien un certain nombre de lignes de code. 40 CONVERSION EN LIGNES DE CODE Développement de systèmes e-­‐business è 35 lignes de code en Access. è 106 points de fonction, développés avec le langage java par exemple, on va faire 106 x 63 et on va arriver a un nombre de lignes de code. Il y a rien de plus qu’une simple conversion d’unité là derrière. Une fois qu’on a ca, on peut appliquer des métriques d’estimation d’effort. ESTIMATION DE L’EFFORT DE DEVELOPPEMENT
  • 41. Manon Cuylits Master 1 2012-­‐2013 L’effort exprimé en mois homme est proportionnel a des milliers de lignes de code avec un exposant c relativement proche de 1 (a & b sont des constantes) Cf. graphe : évolution de l’effort en fonction de la taille 41 è Thierry Van den Berghe Légèrement exponentiel et non linéaire pcq gérer complexité gros systèmes. Il y a des facteurs qui sont ici multiplicatifs qui sont des facteurs d’ajustement qui tiennent compte de propriétés générales du système et son environnement. COCOMO : CONSTRUCTIVE COST MODEL SIMPLIFIE Modèle d’estimation d’effort : COCOMO (un modèle parmi d’autres) Ø Effort – durée – nombre de ressources à affecter au projet Ø Série de constantes : a ; b, c, d Ici : hypothèse d’un projet organique simple et maitrisé Légère exponentielle du nombre de lignes de code On a les formules, on les applique (on va le faire dans des exemples ici)
  • 42. Manon Cuylits Master 1 2012-­‐2013 Qualité de l’équipe IT : impact très fort sur le temps de développement et l’effort de 42 EFFORT ADJUSTEMENT FACTORS – EAF (EXEMPLES) Premièrement : exemples de facteurs d’ajustement qui sont ici multiplicatifs ! è Développement de systèmes e-­‐business développe • Pénalité de 46% pour des mauvais • Gain de près de 30% pour des gens très compétents. EXEMPLES D’APPLICATION Ø Programme organique de 32 KLOC : o E = 2,4 x 321,05= 91 hommes-­‐mois o D = 2,5 x 910,38 = 14 mois o N = !" !" = 6,5 hommes Imaginons qu’on veut développer un programme organique pour une PME. On arrive vite a 32000 lignes de code si on applique la technique des points de fonction (FP) ce qui va nous donner un effort de 91 homme mois. Si on connaît le salaire moyen d’un informaticien, on le multiplie par le nombre d’homme-­‐ mois et on a une première estimation du budget. Si on fait appel à un informaticien extérieur, combien cela va-­‐t-­‐il nous couter ? Tarif journalier ? Il travaille 8h, ca va couter environ 400-­‐600 euros par jour.
  • 43. Manon Cuylits Master 1 2012-­‐2013 43 Thierry Van den Berghe è On va nous facturer un chef de projet jusque 800 à 900 euros par jour et pour des spécialistes pointus, réputés, ca peut monter à 2000 ou 3000 euros par jour + les frais genre hébergement etc. (Carrière informatique = assez rémunératrice). Ø Claroline : 460 KLOC o E = 1500 hommes-­‐mois o D = 40 mois o N = 37 hommes Ø Développement d’un OS de 35 millions de lignes è Système d’exploitation (OS) qui fait 35 millions de lignes de code. o E = 1.021.372 hommes-­‐mois o D = 210 mois = +/-­‐ 17 ans o N = 4878 hommes Effort de plus de 1 million d’homme-­‐mois = 17 ans de travail pour 5000 personnes pour 1 seul système d’exploitation, c'est énorme… è Par exemple, chez SAP, l’équipe de développement est d’environ 8000 personnes et ils existent depuis plus de 25 ans. Chiffres concernant les équipes affectées par Microsoft tous des versions antérieurs des Windows : Exemple : pour le développement, faire évoluer, Windows XP à Windows server 2003 : 4400 personnes pour produire 50 millions de lignes de code. Windows existe depuis plus de 20 ans et a été conçu à partir de systèmes plus anciens … ces ordres de grandeurs ne sont donc pas si délirant que ca. Très difficile de trouver des chiffres… Ø Productivité implicite du modèle : 16 LOC par jour par personne Si on calcule la productivité implicite de ce modèle, par exemple : 32000 lignes de code, on divise ca par 91 x 20 (on fait travailler nos personnes 20 jours par mois) on arrive a une productivité d’environ 16 lignes de code par jour, c'est faisable, même confortable de produire 16 lignes de code par jour, mais pas réaliste, les efforts dont on parle incluent la programmation mais aussi la gestion de projet etc. tout rentre en ligne de compte dans l effort de travail, on ne fait pas que programmer.
  • 44. Manon Cuylits Master 1 2012-­‐2013 44 EXEMPLES D’APPLICATION : WINDOWS NT EXERCICE: MAXIMAT Développement de systèmes e-­‐business Enoncé :
  • 45. Manon Cuylits Master 1 2012-­‐2013 45 Thierry Van den Berghe Solution :
  • 46. Manon Cuylits Master 1 2012-­‐2013 • L'entreprise de restauration industrielle Cuisigros souhaite informatiser le suivi de • L'intranet affichera des informations utiles pour les employés, à savoir : une page dédiée à l'organigramme, une page dédiée aux consignes à respecter sur le lieu de travail, et une page d'accueil reprenant un module de news, un module météo et le menu revoyant aux pages de l'intranet et aux fonctions de l'application de suivi. • L'entreprise prépare des repas qu'elle livre à des entreprises de plusieurs zonings industriels. Elle compte une centaine de clients et livre près de 2500 repas par jour. Les repas sont essentiellement livrés le midi, mais Cuisigros organise également des réceptions en soirée, ce qui implique des prestations supplémentaires de son personnel. • L'application à développer doit supporter les concepts suivants: • les fournisseurs et les commandes fournisseur. Les informations à gérer sur les fournisseurs sont assez traditionnelles et nécessitent un écran d'encodage assez simple. Le système doit proposer à l'écran une liste de commandes fournisseur basée sur les repas à préparer; cette liste est confirmée par un opérateur. Les bons de commande doivent être envoyés électroniquement, bien que cela soit potentiellement compliqué vu la diversité des systèmes informatiques des fournisseurs; • les clients et les commandes client. La structure de la clientèle de Cuisigros est complexe: le système doit gérer plusieurs catégories de clients et maintenir de nombreuses données, comme les habitudes alimentaires et culturelles. Par contre, les commandes client sont très classiques et comportent en moyenne 15 lignes articles (menus et boissons); • les matières premières et leur stockage. La gestion des matières premières consiste simplement à maintenir un descriptif de base, des quantités en stocks, des dates de péremption et des mouvements entrants et sortants. Des inventaires réguliers doivent être imprimés. • les produits finis. Cuisigros gère un petit nombre de produit finis (correspondant à des menus type) mais leur description est relativement complexe: elle inclut la composition d'un menu, i.e., ses différentes matières premières et leurs quantités respectives, une tarification par quantité et des recommandations de fabrication. L'expédition, elle, n'est pas automatisée; • le planning de production. Il est établi chaque semaine en fonction des commandes client. Cette partie de l'application est la plus complexe, puisqu'il faut anticiper les commandes fournisseurs et préparer l'horaire des employés. La réalisation du planning inclut l'édition (1) d'horaires de travail pour les employés, (2) d'un tableau de production et (3) d'une liste de propositions de commandes fournisseur; • les employés et le suivi des prestations. Le système gère des données de base concernant les employés et enregistre les prestations de chacun en distinguant les heures régulières des heures supplémentaires. Un listing de comparaison entre les horaires de travail issus du planning de production et les prestations réelles est à édité chaque fin de mois. Un récapitulatif des toutes les prestations est envoyé chaque semaine à un secrétariat social pour préparer le calcul des salaires. 46 EXERCICE : CUISIGROS son activité avec une application web greffée à son Intranet. Développement de systèmes e-­‐business
  • 47. Manon Cuylits Master 1 2012-­‐2013 47 SOLUTIONS Thierry Van den Berghe 1. Analyse de l’énoncé : Enoncé Points de fonction L'intranet affichera des informations utiles pour les è employés, à savoir : une page dédiée à l'organigramme, une page dédiée aux consignes à respecter sur le lieu de travail, et une page d'accueil reprenant un module de news, un module météo et le menu revoyant aux pages de l'intranet et aux fonctions de l'application de suivi. page organigramme (fichier multimédia moyen car graphique) è page consignes (fichier multimédia simple) è page d'accueil (fichier multimédia difficile car menu et modules) è module de news (composant moyen car saisie de données) è module météo (composant simple) Les informations à gérer sur les fournisseurs sont assez traditionnelles et nécessitent un écran d'encodage assez simple è saisie fournisseur (entrée simple – rien n'indique du cet écran soit particulièrement difficile à construire) è table fournisseur (table simple – les données saisie à l'écran doivent être enregistrées dans une structure de stockage) Le système doit proposer à l'écran une liste de commandes fournisseur basée sur les repas à préparer; cette liste est confirmée par un opérateur. è saisie commande fournisseur (entrée difficile – entrée car l'opérateur doit alimenter le système en données par sa confirmation, difficile car un travail de calcul de la liste des commandes fournisseurs doit être réalisé) Alternative : requête moyenne ou difficile pour calculer la liste des commandes fournisseur + écran de confirmation simple è table commande fournisseur (table simple – les données saisies à l'écran doivent être enregistrées dans une structure de stockage) è table repas (non prise en compte car correspond à un produit fini plus loin dans l'énoncé) Les bons de commande doivent être envoyés électroniquement, bien que cela soit potentiellement compliqué vu la diversité des systèmes informatiques des fournisseurs è bon de commande fournisseur (sortie difficile -­‐ travail technique d'envois de messages digitaux vers des systèmes différents) La structure de la clientèle de Cuisigros est complexe : le système doit gérer plusieurs catégories de clients et maintenir de nombreuses données, comme les habitudes alimentaires et culturelles. saisie client (entrée difficile) table client (table difficile)
  • 48. Manon Cuylits Master 1 2012-­‐2013 saisie commande client (entrée moyenne – nombre de données à enregistrer relativement important, calculs à réaliser, comme le total de la commande) è saisie matière première et stock (entrée moyenne) table mouvement de stock (table simple) saisie produit fini (entrée difficile – beaucoup de listing d'horaire de travail (sortie difficile – si on suppose une mise en forme graphique comme un calendrier de travail) è requête horaire de travail (requête difficile – le calcul de l'horaire dépend des commandes client et devrait demander des calculs élaborés) è table horaire de travail (table simple – on suppose que les données sur les horaires doivent être mémorisées après calcul) è listing tableau de production (sortie simple) requête tableau de production (requête difficile – le calcul dépend des commandes client et devrait demander des calculs élaborés) è table production (table simple – on suppose que les données sur les horaires doivent être mémorisées après calcul) è listing proposition de commandes fournisseur (sortie simple – le calcul des propositions est déjà valorisé dans l'écran de saisie des commandes fournisseur) listing de comparaison (sortie moyenne) Listing récapitulatif des prestations (sortie moyenne) 48 Par contre, les commandes client sont très classiques et comportent en moyenne 15 lignes articles (menus et boissons) è table commande client (table simple) La gestion des matières premières consiste simplement à maintenir un descriptif de base, des quantités en stocks, des dates de péremption et des mouvements entrants et sortants. è è table matière première (table simple) è Des inventaires réguliers doivent être imprimés. è listing d'inventaire (sortie simple) Cuisigros gère un petit nombre de produit finis (correspondant à des menus types) mais leur description est relativement complexe : elle inclut la composition d'un menu, i.e., ses différentes matières premières et leurs quantités respectives, une tarification par quantité et des recommandations de fabrication. L'expédition, elle, n'est pas automatisée è données à saisir) è table produit fini (table difficile) Le planning de production. Il est établi chaque semaine en fonction des commandes client. Cette partie de l'application est la plus complexe, puisqu'il faut anticiper les commandes fournisseurs et préparer l'horaire des employés. La réalisation du planning inclut l'édition (1) d'horaires de travail pour les employés, (2) d'un tableau de production et (3) d'une liste de propositions de commandes fournisseur; è è Le système gère des données de base concernant les employés et enregistre les prestations de chacun en distinguant les heures régulières des heures supplémentaires. è saisie employé (entrée simple) è table employé (table simple) è saisie prestation (entrée simple) è table prestation (table simple) Un listing de comparaison entre les horaires de travail issus du planning de production et les prestations réelles est à édité chaque fin de mois. è Un récapitulatif des toutes les prestations est envoyé chaque semaine à un secrétariat social pour préparer le calcul des salaires è Développement de systèmes e-­‐business
  • 49. Manon Cuylits Master 1 2012-­‐2013 49 Thierry Van den Berghe 2. Estimations chiffrées : Estimation d’effort = un exercice possible a l’examen. Comment peut on évaluer le cout de développement d’un système e-­‐business et l’évolution métrique. Il ne faut pas connaître les formules par coeur, elles seront fournies à l’examen si on en a besoin. Cas d’application qui pourrait nous être demandé.
  • 50. Manon Cuylits Master 1 2012-­‐2013 50 4. SPECIFICATIONS 1. DEFINITION DE LA SPECIFICATION Développement de systèmes e-­‐business Objectif Ø établir une première spécification du système à construire sous un angle fonctionnel, i.e., indépendamment de choix technologiques Ø décrire le «quoi» et non le «comment» Tâches Ø rassembler les besoins détaillés des utilisateurs du système à construire en termes d'informations, de traitements d'informations et d’interfaces Ø sur base des besoins exprimés par les utilisateurs, décrire les structures de données, les traitements, le contrôle et l’interface du système Ø produire un document de spécifications fonctionnelles détaillé Formalisme: langages de modélisation graphique 1ère question : « Qu'est ce qu’on veut exactement ? » L’objectif est de spécifier le futur système qu’on veut. Tâches : Attention la phase de spécification est une phase fonctionnelle, on ne s’intéresse pas à la mécanique. Ici on va décrire le système comme une boite noire et identifier les fonctionnalités. Autrement dit, on décrit ce que le système va faire et pas comment il va rendre ses services. On va demander au programmeur un écran qui permet d’enregistrer les commandes mais on ne va pas lui imposer une manière de le faire.
  • 51. Manon Cuylits Master 1 2012-­‐2013 Objectif : comprendre les besoins des utilisateurs et, sur base de ces besoins, décrire le système sous différentes dimensions. A l’issue de cette phase de spécification on va écrire un document fonctionnel qui décrit toutes les attentes des utilisateurs et qui peut servir de cahier de charge. On va l’envoyer à des prestataires IP potentiels (expliqué dans le docu sur IC) Si on délègue le développement à l’extérieur, tout ce qui est dans le cahier de charges revêt une allure contractuelle. 51 Thierry Van den Berghe è Enjeu vraiment important !!! Formalisme : plusieurs possibilités mais on utilise beaucoup des techniques graphiques pour représenter les besoins de l’utilisateur (diagramme de cas d’utilisation, etc.) DIMENSIONS CONSTITUTIVES Très important è Fait le lien entre les besoins et les spécifications. En général les deux sont très corrélés ! Exemple: on peut dire « j’ai besoin d'un système de facturation en ligne » et donc au niveau des spécifications je pourrais dire « j'ai besoin d'un système qui permet d’enregistrer une facture, de la diffuser et d’enregistrer son paiement ».
  • 52. Manon Cuylits Master 1 2012-­‐2013 52 TYPES DE BESOINS Quels sont les types de besoins pour les applications e-­‐business ? Développement de systèmes e-­‐business Besoins informationnels è site vitrine Ø recouvrent les informations à publier Ø identification du contenu, définition de la politique de mise à jour, etc. Exemple : présentation de l'entreprise, catalogue de produits, etc. Quand on développe des parties de sites vitrine (site web relativement simple sans beaucoup de manipulations de données) on va avoir des besoins informationnels. Au départ internet est un système de diffusion d’information, de contenu, on va l’utiliser pour diffuser des infos sur notre entreprise, etc. ce sont des infos peu changeantes avec une dimension informationnelle forte. Besoins applicatifs è application Web Ø couvrent les traitements à réaliser par l'application e-­‐business Exemple: créer une commande, passer des ordres bancaires, etc. Ø décrits par les langages de modélisation (cas d'utilisation, etc.) Aujourd'hui, il y a de plus en plus de manipulation de données è besoins applicatifs avec des appli qui permettent par ex a un client dune banque de créer des données, par exemple, des ordres de virement. La on est plus dans l’applicatif : la modification de traitement de donnée. Besoins non fonctionnels Ø couvrent des propriétés périphériques au traitement de l'information Exemple : visuel et ergonomie, performance, confidentialité des données On va devoir aussi considérer les besoins non fonctionnels : relatifs a des caractéristiques globales de l’application pas directement en lien avec le traitement des données mais décrivent des accès globaux comme l’ergonomie, la performance et la confidentialité des données par exemple. TYPES DE SPECIFICATIONS On va décrire un système sous différents angles è quelque chose d'assez particulier. Si on veut rédiger les plans d’une future maison, avec une seule feuille, un modèle on a assez. Mais quand on veut spécifier les systèmes d'information c'est tellement complexe qu’il faut plusieurs angles pour comprendre è il faut plusieurs modèles, points de vue qui se complètent.
  • 53. Manon Cuylits Master 1 2012-­‐2013 53 Dimensions sous lesquelles on va décrire le futur système : Thierry Van den Berghe Ø Structures Quels sont les types de données que le système doit gérer ? Quelles sont les structures de données que le système doit prendre en charge ? Quand on a identifié les structures on doit encore examiner d’autres choses Ø Traitements è Décrire les manipulations qui vont avoir lieu sur ces structures de données. Quelles sont les opérations à réaliser sur ces types de données ? Ces traitements ont lieu dans un certain ordre. On ne peut pas valider une commande si on n’a pas d’abord validé un client ou tous les articles… Ø Dynamique Quelles sont les séquences d’opérations permises au cours du temps? Quels sont les événements qui déclenchent ces séquences? La dynamique du système décrit la manière dont le système se comporte au cours du temps. Ø Interfaces Quelles est la forme et l’organisation de l’interface homme-­‐machine? Quelle est l’allure des écrans qu’on souhaite pour notre site web ? Aussi un travail à faire en terme de spécification. è Toutes les dimensions sont complémentaires et intégrées EXEMPLES Ø Structures Client, commande et articles è Au niveau des structures on va préparer une base de données avec au minimum clients, commandes et articles Ø Traitements Créer un compte client, modifier un compte client, saisir un article, créer une commande, etc. è un processus d'enregistrement de nouvelles commande comportera 3 étapes qu’on va spécifier. Ø Dynamique Passer une nouvelle commande = 1. créer une compte client ou choisir un compte existant 2. choisir les articles et les quantités commandées 3. calculer les frais de livraison et le total de la commande
  • 54. Manon Cuylits Master 1 2012-­‐2013 54 Développement de systèmes e-­‐business Ø Interfaces Lay-­‐out design d’un écran de commande è On peut déjà donner au programmeur une idée du lay-­‐out général d’un écran de commande. UML ET RUP Au niveau des formalismes, les diagrammes de cas d’activité ou de cas d’utilisation, par exemple, sont en fait des techniques intégrées dans ce qu’on appelle une famille de langage de modélisation. UML (Unified Modeling Language) Ø ensemble de notations standardisées par l'OMG (Object Management Group, http://www.omg.org) Ø techniques de modélisation graphiques Ø cf. http://www.uml.org RUP (Rational Unified Process) Ø processus de développement cohérent avec UML Ø ne fait pas l'objet d'une standardisation UML et RUP : produits IBM Ø soutenu pas de nombreux CASE Exemple : http://www-­‐01.ibm.com/software/rational/uml Exemple : http://www.visual-­‐paradigm.com Exemple : Open Source: http://www.staruml.com UML reprend les standards de notifications aujourd’hui très largement utilisés par les professionnels de l’informatique. Les concepteurs d’UML ont développé un processus de développement (voir article sur IC). Au départ l’ULM et le RUP ont été développés par une société de service et cette société a été rachetée par IBM = IBM gère ces 2 technologies.
  • 55. Manon Cuylits Master 1 2012-­‐2013 UML a été développe par 3 gourous de l’informatique des années 90. Idée de départ : rassembler une série de techniques existantes dans un ensemble cohérent et dans un contexte commercial (intention d’universalité). Premier terme : Unified Modeling 55 HISTORIQUE D’UML è Thierry Van den Berghe Language La première version date de 1995, depuis ca a bien évolué, ca a été nourri de beaucoup d’autres technologies de modélisation et aujourd’hui on en est à la version 2.5.
  • 56. Manon Cuylits Master 1 2012-­‐2013 On retrouve beaucoup de composants très différents. Ces composants permettent de décrire les différents aspects d'un système. On trouve aussi des diagrammes qui décrivent le système à ses différentes étapes de maturation. On s’intéresse au diagramme de cas d’activité de cas d’utilisation ms il y en a plein d’autre… 56 COMPOSANTS D’UML 2. DIAGRAMME DE CAS D’UTILISATION CAS D’UTILISATION : EXEMPLE INTRODUCTIF Rappel : Objectif = déterminer les grandes fonction du système a construire. Développement de systèmes e-­‐business
  • 57. Manon Cuylits Master 1 2012-­‐2013 Exemple : on veut créer une nouvelle génération de Smartphones que veut on prévoir ? Chaque grande fonction va être décrite par un cas d’utilisation. 4 types d’utilisations prévus pour le futur système : 57 Thierry Van den Berghe -­‐ téléphoner -­‐ envoyer des SMS -­‐ gérer un agenda -­‐ prendre des photos è Elles vont être détaillées L’idée d'un cas d'utilisation c'est de décrire le comportement du système du point de vue de l’utilisateur. Après l’étude d’opportunité, on décide d’engager le projet (ou non). Il va s’agir de décrire le système de manière relativement détaillée pour expliquer aux informaticiens ce qu’ils doivent produire. Les utilisateurs, les personnes qui connaissent le business, les besoins etc. peuvent décrire ce système. Ce ne sont pas les informaticiens qui doivent faire ca. CAS D’UTILISATION Description du comportement du système du point de vue de l'utilisateur Ø décrit le comportement du système dans son ensemble (boite noire) Ø le comportement est détaillé sous la forme de séquences d'actions exécutées par le système suite à des stimulations extérieures Ø certaines interactions peuvent ne pas concerner directement le système, mais sont mentionnées pour la bonne compréhension de l'utilisation du système Les cas sont regroupés dans un diagramme de cas d'utilisation Ø représentation des besoins ET spécification du système Ø description d'un processus business ET du système à construire Ø les cas d'utilisation servent à partitionner et structurer les besoins
  • 58. Manon Cuylits Master 1 2012-­‐2013 Il s’agit d’identifier les grandes fonctionnalités du système. C’est un formalisme assez simple intervenant dans les toutes premières étapes de la spécification. On essaye de cerner le système et de voir à quoi il va servir. è Pour décrire le système on va identifier les grandes fonctions avec le concept de cas d’utilisation. Un cas d’utilisation se représente par un ovale et cela représente une utilisation du système (vu comme la boite noire). On va identifier à quoi sert le système. Exemple : GSM de toute première génération : On a au moins les fonctionnalités suivantes : Le système est vu comme une boite noire qui interagit avec son environnement. Un acteur c'est un utilisateur ou un système a l'extérieur du système et qui « utilise » le système. Ce n’est pas spécialement une personne, ca peut être un autre système. Un acteur est extérieur au système et donc quand on décrit le fonctionnement, on indique la limite du système et on spécifie les acteurs qui interagissent avec le système et la connexion entre un acteur et un cas d’utilisation. C'est une connexion appelé « utilise ». 58 Ø Premier formalisme : celui des cas d’utilisation (Use Case) Ø appeler un correspondant, Ø rédiger un SMS, Ø lire un SMS, Ø répondre à un appel. ACTEUR Représente un rôle joué par une entité qui interagit avec le système Ø stimule le système en vue de l'exécution d'un traitement Ø envoie et/ou reçoit de l'information vers/du système Développement de systèmes e-­‐business