E-business

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