Le document traite du développement d'un système e-business, en décrivant un processus structuré en plusieurs phases, allant de la réflexion préalable à l'évaluation des résultats. Il souligne l'importance de l'ingénierie logicielle, de la collaboration avec les utilisateurs, ainsi que des exigences spécifiques liées à la sécurité, à l'ergonomie et à la performance. Enfin, il aborde les différentes méthodologies de gestion de projet, y compris les méthodes agiles et les cycles de développement en cascade.

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

59. Manon
Cuylits
Master
1
2012-­‐2013
Exemple
:
internaute,
machine,
un
autre
SI
Exemple
:
une
même
personne
peut
assumer
plusieurs
rôles,
comme
utilisateur
et
administrateur
Ø acteur
clé
:
impliqué
dans
les
fonctions
clés
du
système
Ø acteur
accessoire
:
impliqué
dans
des
utilisations
accessoires
et
souvent
Exemple
:
un
client
est
aussi
un
internaute
et
peut
donc
utiliser
le
système
pour
consulter
le
catalogue
Les
acteurs
interagissent
avec
le
système.
Le
système
répond
à
l’acteur
en
réalisant
une
action
ou
en
renvoyant
une
information.
59
Est
extérieur
au
système
et
donc
situé
dans
son
environnement
L’acteur
utilise
le
système
(use
case)
Pour
décomposer
l'étude
de
gros
systèmes,
on
distingue
:
ponctuelles
(Exemple
:
responsable
de
la
maintenance)
HIERARCHIE
D’ACTEURS
Peut
être
repris
dans
des
structures
de
généralisation/spécialisation
Ø un
acteur
spécialisé
hérite
de
toutes
les
propriétés
de
l'acteur
qui
le
généralise
Ø un
acteur
spécialisé
possède
des
propriétés
spécifiques
(non
héritées)
Thierry
Van
den
Berghe

60. Manon
Cuylits
Master
1
2012-­‐2013
On
verra
qu’on
décrira
la
manière
dont
un
acteur
échange
dans
un
dialogue
bien
déterminé
des
informations
et
des
ordres
a
travers
un
dialogue
«
in
out
».
La
on
identifie
les
facilités
du
système.
Dans
les
utilisateurs
on
peut
avoir
des
sous
catégories.
On
peut
spécialiser
les
acteurs.
Un
cas
fait
appel
à
un
autre
cas
uniquement
si
une
condition
est
vérifiée
Exemple:
le
cas
confirmer
la
commande
étend
le
cas
calcul
de
devis
si
un
devis
est
accepté
Quand
j’appelle
un
correspondant
ou
quand
je
rédige
un
SMS,
dans
ces
deux
utilisations
je
dois
choisir
un
destinataire
à
un
moment
donné.
Je
vais
regarder
dans
mon
répertoire
OU
encoder
un
numéro
qui
n’est
pas
dans
le
répertoire.
Dans
différentes
utilisations
du
système
on
va
avoir
des
comportements
qu’on
retrouve
dans
des
cas
différents.
Si
on
veut
décrire
en
détail
chacun
des
comportements
on
va
devoir
décrire
…
Si
ce
contact
qu’on
veut
appeler
ou
SMSer
n’existe
pas
dans
le
système
on
va
devoir
entrer
le
numéro.
On
peut
extraire,
factoriser,
avec
un
cas
supplémentaire
:
«
choisir
le
correspondant
»
alors
on
peut
connecter
les
cas
d’utilisation
entre
eux
par
une
60
STRUCTURATION
DES
CAS
D’UTILISATION
Un
cas
peut
factoriser
un
comportement
qui
se
répète
dans
plusieurs
autres
cas
Ø Relation
utilise
(include)
Un
cas
fait
toujours
appel
à
un
autre
cas
Exemple:
le
cas
saisir
une
commande
utilise
le
cas
identification
du
client
Ø Relation
étend
avec
condition
(extend)
Les
cas
d'utilisation
peuvent
être
spécialisés
(pour
mention)
Développement
de
systèmes
e-­‐business
relation
qui

61. Manon
Cuylits
Master
1
2012-­‐2013
s’appelle
«
include
».
Include
ca
signifie
donc
qu’à
un
moment
donné,
un
cas
en
cours
d’utilisation
va
brancher
systématiquement
vers
un
autre
cas
61
Thierry
Van
den
Berghe
è
c'est
un
premier
mécanisme
de
structuration
des
cas
d’utilisation.
Cela
allège
la
description
du
système.
Imaginons
qu’on
parcoure
le
répertoire
et
qu’on
ne
trouve
pas
le
correspondant
qui
nous
intéresse.
Si
une
certaine
condition
est
vérifiée
(correspondant
existe
pas),
on
va
devoir
encoder
un
nouveau
correspondant.
A
ce
moment
la
cet
appel
est
facultatif,
lié
a
la
vérification
d’une
condition
è
on
parle
alors
d’une
relation
«
extend»
è
pas
systématique,
on
passe
pas
toujours
par
ce
cas
la.
C’est
la
différence
avec
include.
Identifier
un
cas
n’est
pas
suffisant,
l’informaticien
doit
savoir
comment
le
système
doit
se
comporter
dans
certains
cas
précis.
C'est
un
niveau
de
détail
supplémentaire.
D’abord
on
commence
avec
un
niveau
de
détail
faible
puis
on
enrichit,
jusqu’à
obtenir
le
produit
fini.
SYNTHESE
DES
NOTATIONS

62. Manon
Cuylits
Master
1
2012-­‐2013
En
informatique,
quand
on
veut
construire
quelque
chose,
on
le
fait
rarement
en
une
seule
étape.
Souvent
on
a
une
approche
itérative
ou
on
complète
progressivement
le
travail
par
repasses
successives.
Aller
directement
dans
le
détail
de
tout
n'est
pas
pertinent.
On
ne
va
pas
directement
détailler
toutes
les
fonctionnalités
parce
que
certaines
ne
sont
soit
pas
directement
utiles
pour
la
communauté
des
utilisateurs,
soit
trop
complexes
et
couteuses.
On
va
d’abord
se
mettre
d’accord
sur
ce
qu’on
veut
avant
daller
dans
le
détail.
62
EXEMPLE
DETAILS
D’UN
CAS
D’UTILISATION
Ø Première
description
à
partir
de
rubriques
standard.
Ø Détail
des
interactions
avec
des
séquences
d'événements.
On
va
avoir
plusieurs
niveaux
de
détails
:
Développement
de
systèmes
e-­‐business
1. Premier
niveau
de
détail
:
Compléter
le
nom
du
cas
d’utilisation
avec
quelques
rubriques
standard.
Exemple
:
cas
de
recherche
d’ouvrage
dans
la
bibliothèque
(è
nom
du
cas),
derrière
ca
on
va
préciser
l’objectif
et
décrire
le
fonctionnement
du
système
en
quelques
lignes.
L’idée
n’est
pas
de
rentrer
dans
la
description
exhaustive
mais
de
donner
une
première
idée
du

63. Manon
Cuylits
Master
1
2012-­‐2013
fonctionnement.
C’est
une
description
très
simple
(voir
ci-­‐dessous)
et
abordable
pour
les
utilisateurs.
Rubriques
:
Ø Nom du cas: recherche d'ouvrages dans la bibliothèque
Ø Acteurs: lecteur
Ø Objectif: sélectionner des ouvrages dans le
catalogue sur base
Ø Description: Un lecteur introduit des critères de recherche,
comme un mot dans le titre ou un auteur, puis le système lui
présente les ouvrages correspondants et les nouveautés.
63
de critères de recherche
Thierry
Van
den
Berghe
2. Deuxième
niveau
de
détail
:
séquences
d’évènements.
Dans
un
second
temps
on
va
concevoir
les
interactions
entre
le
système
et
son
environnement
à
travers
des
séquences
déventement.
Ø Séquences
de
stimuli
de
l'acteur
et
de
réponses
du
système
Ø Séquences
alternatives
o Branchement
vers
une
séquence
parmi
plusieurs
en
fonction
du
résultat
d'un
test
Ø Séquences
conditionnelles
o exécution
d'une
séquence
uniquement
si
une
condition
est
satisfaite
èLes
séquences
alternatives
et
conditionnelles
complètent
la
séquence
standard
d'un
cas
d'utilisation
Le
système
est
une
boite
noire
vers
laquelle
l’acteur
envoie
des
signaux
et
en
réponse
à
ces
signaux
le
système
va
réagir
et
renvoyer
un
signal
vers
l’acteur.
On
cherche
les
étapes
du
dialogue
entre
le
système
et
son
environnement
au
cours
du
temps.

64. Manon
Cuylits
Master
1
2012-­‐2013
En
général,
on
commence
par
décrire
la
séquence
d’évènements
standard
ou
tout
se
passe
sans
problème
ET
PUIS
on
réfléchit
à
d’éventuels
problèmes.
On
peut
compléter
la
liste
d'évènements
avec
des
séquences
alternatives
(branchement
soit
à
gauche
soit
à
droite)
ou
conditionnelles
(avec
une
condition).
Exemple
:
alternative
4’
:
si
aucun
ouvrage
trouvé,
alors
on
part
dans
un
scénario
d’utilisation
différente
du
système.
Si
aucun
ouvrage
trouvé
le
système
réaffiche
l’écran
de
recherche
avec
un
message.
64
EXEMPLE
DE
SEQUENCE
D’EVENEMENT
:
RECHERCHE
D’OUVRAGES
DANS
UNE
BIBLIOTHEQUE
On
a
2
colonnes
dans
la
description
:
Ø Colonne
gauche
:
actions
ou
signaux
envoyés
par
l’acteur
vers
le
système
Ø Colonne
droite
:
réponse
du
système
On
regarde
comment
les
évènements
entrants
et
sortants
sont
organisés.
Développement
de
systèmes
e-­‐business

65. Manon
Cuylits
Master
1
2012-­‐2013
65
EVALUATION
DES
CAS
D’UTILISATION
Thierry
Van
den
Berghe
Technique
simple
Ø peu
d'apprentissage
de
la
part
des
utilisateurs
Vue
abstraite
du
système
Ø pas
de
considération
technique
Ø centré
sur
le
quoi
et
le
point
de
vue
utilisateur
Permet
une
découpe
des
fonctionnalités
Ø facilite
la
gestion
du
projet
(itérations
prioritaires,
etc.)
Ø première
description
permettant
d'évaluer
la
charge
de
développement
Description
informelle
des
besoins
Ø faiblesses
du
langage
naturel
(interprétation,
ambiguïté,
etc.)
Ø difficulté
d'évaluer
la
qualité
des
spécifications
(complétude,
non
redondance,
etc.)
è
recours
à
d'autres
langages
plus
formels
DEMARCHE
DE
CONSTRUCTION
Principes
de
base
:
Ø construction
progressive
du
diagramme
de
cas
en
plusieurs
itérations
Ø une
itération
complète
le
diagramme
courant
ou
le
détaille
Voici
un
exemple
de
méthode
qui
permet
la
construction
progressive
d'un
cas
d’utilisation
:
Attention,
Il
faut
travailler
itérativement
et
progressivement
è
Ne
pas
vouloir
tout
faire
en
même
temps.
1. Identifier
les
acteurs
clés
è
ceux
qui
sont
les
principales
cibles
du
système.
Exemple
:
si
on
développe
un
système
de
vente
en
ligne,
l’acteur
principal
auquel
on
pense
c'est
le
client.
Par
rapport
a
ces
acteurs
il
y
en
a
peut
être
qui
utilisent
moins
souvent
le
système
:
acteurs
accessoires
(point
3)
2. Identifier
les
cas
des
acteurs
clés
et
les
décrire
selon
les
rubriques
standard
è
Se
concentrer
sur
le
core
business
et
les
cas
correspondants,
avec
une
première
description
des
cas
des
acteurs
clés
selon
les
rubriques
standards.

66. Manon
Cuylits
Master
1
2012-­‐2013
3. Identifier
les
acteurs
accessoires
4. Identifier
les
cas
des
acteurs
accessoires
et
les
décrire
selon
les
rubriques
standard
66
5. Détailler
les
cas
avec
les
séquences
standard
d’évènements
6. Détailler
les
séquences
alternatives
et
conditionnelles
7. Structurer
les
cas
d’utilisation
en
factorisant
les
comportements
communs
Développement
de
systèmes
e-­‐business
è
On
va
trouver
des
choses
communes
dans
différents
cas
et
après
avoir
détaillé
toutes
les
séquences
possibles
on
va
pouvoir
rassembler
des
comportements
communs.
Exemple
:
Quand
on
a
été
dans
le
détail
on
va
se
rendre
compte
que,
par
exemple,
la
procédure
d’utilisation
se
retrouve
dans
le
cas
d’utilisation
«
passer
une
commande
»
mais
aussi
dans
le
cas
d'utilisation
«
suivre
une
commande
».
GRANULARITE
DES
CAS
D’UTILISATION
Quelle
ampleur
pour
la
fonctionnalité
décrite
par
un
cas?
Cas
d'utilisation
trop
détaillés
:
Ø séquences
d'événements
très
réduites
Ø trop
de
cas
à
gérer
Cas
d'utilisation
trop
larges
:
Ø séquences
d'événements
interminables
Ø modularisation
du
développement
difficile

67. Manon
Cuylits
Master
1
2012-­‐2013
Ø Un
magasin
de
vente
d'articles
pour
animaux
vend
de
la
nourriture
et
des
accessoires
à
des
clients
privés
ou
professionnels.
Deux
modes
de
vente
sont
proposés
:
une
vente
au
comptoir
et
une
commande
Web
pour
les
professionnels
uniquement.
Ø Les
magasiniers
se
chargent
de
la
préparation
des
commandes
et
de
la
facturation.
Ø De
temps
en
temps,
des
délégués
commerciaux
viennent
en
magasin
pour
organiser
67
La
granularité
idéale
doit
produire
:
Ø des
séquences
d'événements
raisonnables
Ø des
cas
correspondant
à
une
itération
du
cycle
de
développement
EXEMPLE
:
ENONCE
SIMPLIFIE
Ils
réassortent
le
stock
et
tiennent
la
caisse.
Thierry
Van
den
Berghe
les
rayons.
1. identifier
les
acteurs
clés
Acteurs
principaux
:
Ø Client
(sous
catégorie
professionnel)
Ø Au
niveau
des
acteurs
de
l’entreprise
on
a
le
magasinier
spécialisé
à
encaisser.
Ce
sont
les
acteurs
cibles
du
système.
On
peut
aller
plus
dans
le
détail
avec
des
cas
d’utilisation
connecté
à
ces
acteurs.

68. Manon
Cuylits
Master
1
2012-­‐2013
Ø Le
caissier
gère
la
vente
au
comptoir
Ø Le
professionnel
peut
utiliser
le
système
pour
enregistrer
des
commandes
web
Ø Le
magasinier
utilise
le
système
pour
la
préparation
de
la
commande,
la
facturation
68
2. identifier
les
cas
clés
et
le
réassort
du
stock.
On
a
une
première
description
de
chaque
cas
–
ici
détail
du
cas
de
la
vente
comptoir
Développement
de
systèmes
e-­‐business
3. Acteurs
4.
cas
accessoires

69. Manon
Cuylits
Master
1
2012-­‐2013
On
a
comme
acteur
le
caissier,
et
le
système.
Ici
on
va
voir
le
fonctionnement
standard,
le
scénario
standard
du
déroulement
dune
vente
comptoir
ensuite
on
verra
qu'il
y
a
des
alternatives
en
grand
nombre.
NB:
de
manière
naturelle,
les
utilisateurs
décrivent
une
interaction
qui
ne
concerne
pas
du
tout
le
système
:
l’échange
de
cash
entre
deux
acteurs
69
Dans
un
deuxième
temps
on
se
concentre
sur
les
acteurs
accessoires
/
secondaires.
Ici
le
délégué
commercial.
5. Détailler
les
séquences
standard
(cas
vente
comptoir)
è
Thierry
Van
den
Berghe
cela
se
déroule
en
dehors
du
système.
C’est
naturel,
quand
on
décrit
le
fonctionnement
d'un
système,
de
décrire
le
processus
business
sous-­‐jacent.
Cela
permet
de
mieux
comprendre
le
cas
d’utilisation.

70. Manon
Cuylits
Master
1
2012-­‐2013
On
peut
définir
à
coté
des
séquences
standard,
des
séquences
alternatives
et
conditionnelles.
70
6. Détailler
les
séquences
alternatives
et
conditionnelles
(cas
vente
comptoir)
On
pourrait
scanner
des
bons
de
réduction
au
lieu
des
articles
par
Développement
de
systèmes
e-­‐business
exemple.
On
pourrait
payer
autrement
qu'en
cash,
par
exemple
avec
des
chèque
repas,
une
carte
de
débit,
ou
de
crédit,
etc.
è
Il
faut
prévoir
des
scénarios
alternatifs
à
ce
déroulement
standard.
Autre
variante
possible
:
on
arrive
avec
25
fois
le
même
article
è
on
ne
va
pas
le
scanner
25
fois
mais
1
fois
et
indiquer
une
quantité
è
Séquence
alternative
qui
consiste
à
encoder
une
quantité
pour
le
même
article.
Très
vite
ce
formalisme
devient
assez
compliqué,
lourd
quand
on
a
des
alternatives
en
grand
nombre
(ce
qui
est
souvent
le
cas)

71. Manon
Cuylits
Master
1
2012-­‐2013
Ø l'interface
homme-­‐machine
doit
intégrer
le
profil
des
utilisateurs
(culture,
goûts,
71
7. Structurer
les
cas
d’utilisation
DETAIL
DES
ACTEURS
Une
application
Web
est
souvent
dépendante
des
caractéristiques
de
ses
utilisateurs
compétences,
etc.)
Exemple
:
les
comptables
préfèrent
les
raccourcis
clavier
que
la
souris
Ø le
contenu
peut
varier
d'un
utilisateur
à
l'autre
Exemple
:
pages
adressées
aux
fournisseurs
ou
pages
adressées
aux
clients
Ø les
fonctionnalités
peuvent
varier
d'un
utilisateur
à
l'autre
Exemple
:
utilisateur
anonyme
versus
gestionnaire
de
contenu
La
description
des
acteurs-­‐utilisateurs
doit
être
suffisamment
complète
Ø pas
de
formalisme
bien
défini
Ø corrélation
avec
une
cible
de
marché
pour
les
applications
e-­‐business
Thierry
Van
den
Berghe

72. Manon
Cuylits
Master
1
2012-­‐2013
L’interface
homme-­‐machine
est
souvent
dépendante
de
la
culture
de
la
nature
des
utilisateurs.
Cela
vaut
la
peine
d’informer
les
programmeurs
sur
les
acteurs
ou
utilisateurs
cibles,
pour
présenter
des
lay-­‐out
ou
contenus
adaptés
aux
différentes
cibles
de
la
plateforme.
72
Développement
de
systèmes
e-­‐business
è
Pas
de
formalisme
prédéfini
ici
donc
on
fait
ce
qu’on
peut.
LAYOUTS
DEVELOPPES
EN
FONCTION
D’UNE
CIBLE
Ici
sites
clairement
définis
pour
des
cibles
assez
diversifiées
Ø Enfants
:
beaucoup
de
graphiques
et
couleurs.
+
Contenus
très
allégés
Ø Amateurs
de
hard
rock
:
couleurs
+
contenu
léger
Ø La
Meuse
les
sports
La
Libre
:
contenu
nettement
plus
austère,
plus
chargé
è
La
Meuse
:
quelque
chose
de
très
épuré,
avec
beaucoup
d’images
et
peu
de
textes
et
La
Libre
:
beaucoup
plus
de
contenus
et
d’informations.
FACILITES
VARIABLES
EN
FONCTION
D’UNE
CIBLE

73. Manon
Cuylits
Master
1
2012-­‐2013
Exemple
d’Ethias
:
3
cibles
explicitées
sur
73
On
peut
même
avoir
des
variations
de
contenu
è
Thierry
Van
den
Berghe
la
page
d’accueil
:
-­‐ particuliers
-­‐ entreprises
-­‐ collectivités
En
fonction
de
la
cible
on
a
des
variations
de
contenus
Ø Pour
l’entreprise
l’emprunt
n’est
pas
disponible
par
exemple.
Ø Intranet
nommé
MyEthias
pour
les
particuliers
et
Ø Extranet
sécurisé
pour
les
entreprises
ou
collectivités
Les
termes
qui
appellent
les
mêmes
fonctionnalités
sont
adaptés
aux
utilisateurs.
CAS
E-­‐LEARNING
:
HIERARCHIE
D’UTILISATEURS
• utilisateurs
:
haut
niveau
de
formation,
environnement
universitaire,
familiarisation
avec
les
TIC
• administrateurs
:
informaticiens
professionnels
ou
assimilés
• gestionnaires
de
cours
et
tuteurs
:
public
formé
à
l'utilisation
de
la
plate-­‐forme;
familiers
à
la
bureautique
• étudiants
:
public
non
formé
à
l'utilisation
de
la
plate-­‐forme;
familiers
à
la
bureautique
et
très
familiers
à
l'Internet

74. Manon
Cuylits
Master
1
2012-­‐2013
• Un
club
de
tennis
souhaite
développer
un
système
de
réservation
des
terrains
en
74
CAS
E-­‐LEARNING
:
DIAGRAMME
DE
CAS
D’UTILISATION
ICHECCAMPUS
par
exemple.
EXERCICE
:
RESERVATION
DE
TERRAINS
DE
TENNIS
Développement
de
systèmes
e-­‐business
ligne.
• Le
système
permet
aux
membres
de
visualiser
les
réservations
déjà
effectuées
et
de
réserver
un
terrain
après
s'être
identifié.
Si
un
membre
ne
peut
enregistrer
qu'une
seule
réservation,
les
professeurs
de
tennis
du
club
peuvent,
eux,
réserver
plusieurs
terrains
à
la
fois.
• Le
secrétaire
administre
le
système
en
définissant
les
terrains
disponibles
et
en
gérant
les
comptes
des
membres
qui
sont
en
ordre
de
cotisation.
Il
peut
aussi
consulter
les
statistiques
de
fréquentation
des
terrains.
• La
consultation
des
réservations
est
accessible
à
tout
internaute
afin
de
stimuler
l'inscription
de
nouveaux
membres.
D'ailleurs,
un
internaute
non
membre
peut
remplir
en
ligne
un
formulaire
d'inscription.

75. Manon
Cuylits
Master
1
2012-­‐2013
75
EXERCICE
Construire
un
diagramme
de
cas
d'utilisation
pour
un
distributeur
automatique
de
billets
• retrait
de
liquide
• gestion
de
la
carte
Proton
• recharge
GSM
pour
plusieurs
opérateurs
• etc.
Thierry
Van
den
Berghe

76. Manon
Cuylits
Master
1
2012-­‐2013
76
3.
DIAGRAMME
D’ACTIVITE
DIAGRAMME
D’ACTIVITE
(UML1.*)
Modèle
de
la
dynamique
du
comportement
Ø représente
des
actions
et
leur
séquence
d'exécution
dans
le
temps
Développement
de
systèmes
e-­‐business
è
Les
diagrammes
d’activité
sont
très
utilisés
pour
représenter
la
dynamique
du
système,
la
manière
dont
le
système
réagit,
travaille,
évolue
au
cours
du
temps.
Ø exemples
d'applications
o spécifier
le
comportement
d'un
SI
o décrire
un
processus
métier
o représenter
la
navigation
entre
les
pages
d'un
site
Web
è
Un
site
est
constitué
de
pages
qui
peuvent
contenir
des
liens
vers
d’autres
pages
du
site,
quels
sont
les
chemins
à
inclure
dans
le
site
?
On
peut
illustrer
cela
avec
des
diagrammes
d’activité
Complète
la
description
des
cas
d'utilisation
Modélise
le
workflow
pour
une
partie
d'un
cas
d'utilisation,
pour
un
cas
d'utilisation
ou
pour
plusieurs
cas
d'utilisation.
Les
diagrammes
d’activité
sont
intéressants
pour
décrire
des
utilisations
complexes
du
système.
On
peut
détailler
des
utilisations
avec
un
seul
diagramme
d’activité.
On
peut
aussi
l’utiliser
pour
représenter
l’enchainement
des
cas
d’utilisation.
Composants
essentiels
Ø des
actions
qui
décomposent
l'activité
Ø des
relations
prédécesseur-­‐successeur
entre
les
actions
Ø éventuellement
l'élément
qui
prend
en
charge
des
actions
(acteur
ou
système)
ou
le
lieu
des
actions

77. Manon
Cuylits
Master
1
2012-­‐2013
77
Exemple
:
On
doit
d’abord
s’identifier
comme
membre
avant
d’utiliser
un
terrain
de
tennis
Thierry
Van
den
Berghe
è
numéro
dans
les
cas
d’utilisation.
è
Diagramme
d’activité
qui
montre
comment
les
différents
cas
d’utilisation
se
succèdent
Dans
un
diagramme
d’activité,
on
décompose
un
processus,
une
utilisation
du
système
en
différentes
actions.
Puis
on
voit
comment
ces
actions
s’enchainent
dans
le
temps.
ACTION
FLUX
DE
CONTROLE
Action
=
unité
fondamentale
de
comportement
Ø manuelle
ou
automatisée
è
En
fonction
de
ce
qu’on
décrit
une
action
peut
être
manuelle
(prise
en
charge
intégralement
par
un
acteur
humain)
ou
automatisée
(prise
en
charge
par
un
acteur
informatique
et
peut
être
prise
en
charge
par
un
acteur
humain
(contrôle))
Ø si
automatisée
:
modifie
l'état
du
système,
les
données
dans
le
système
OU
renvoie
de
l'information
concernant
l'état
du
système
Ø granularité
typique
:
unité
spatio-­‐temporelle
è
Une
action
est
censée
se
dérouler
au
même
moment
au
même
endroit
Quand
on
veut
décrire
une
activité,
il
existe
plusieurs
manières
de
faire.
Un
processus
peut
être
découpé
en
un
grand
nombre
d’actions
très
fines
ou
un
petit
nombres
d’actions
plus
conséquentes.
Flux
de
contrôle
ou
transition
Ø déclenche
l'exécution
d'une
action
ou
d'un
noeud
de
contrôle
Ø action
2
ne
peut
commencer
que
lorsque
action
1
est
terminée
Dynamique
du
système:
On
a
dans
un
diagramme,
des
flux
de
contrôle
(flèches)
Attention
:
il
s’agit
de
flux
de
contrôle
dont
la
signification
est
la
suivant
:
quand
l’action
1
est
terminée,
alors
l’action
2
peut
démarrer.
On
ne
veut
représenter
que
ca,
pas
de
transfert
d’information
de
l’action
1
à
l’action
2.
Pas
un
flux
de
données
mais
de
contrôle
!!!

78. Manon
Cuylits
Master
1
2012-­‐2013
78
NOEUDS
DE
CONTROLE
Développement
de
systèmes
e-­‐business
è
Noeud
initial
è
départ
de
l'activité
è
Noeud
de
fin
d'activité
è
terminaison
de
tous
les
flux
de
contrôle
è
toutes
les
séquences
de
flux
doivent
converger
vers
le
noeud
de
fin
è
Un
seul
noeud
initial
et
de
fin
par
diagramme
d'activité
Flux
de
contrôle
:
//
Une
arrivée
d’eau
dans
maison
:
morcelée
dans
différents
flux,
l’eau
est
utilisée,
récoltée
in
fine
dans
des
tuyaux
de
sortie
(égouts).
Une
entrée
et
une
sortie
vers
laquelle
tous
les
flux
doivent
converger.
Il
n’y
a
pas
une
partie
qui
consomme
l’eau
et
ne
redirige
pas
le
flux
vers
la
sortie.
è
Un
seul
noeud
de
départ
et
un
seul
de
fin
d’activité
donc.
(Logiquement)
Une
activité
a
un
début
et
une
fin
!
Le
diagramme
d’activité
ne
fonctionne
pas
pour
représenter
des
processus
continus.
è
Besoin
de
noeuds
de
contrôles
complémentaires
(voir
suite)
NOEUD
CHOICE
Ø Branchement
conditionnel
en
fonction
de
conditions
de
garde
Ø Après
terminaison
de
l'action
1,
l'action
2
est
exécuté
si
garde
2
est
vrai
OU
action
3
est
exécutée
si
garde
1
est
vrai
Ø 1
flux
entrant,
n
flux
sortants
è
Losange
avec
un
flux
entrant
et
2
flux
sortant.

79. Manon
Cuylits
Master
1
2012-­‐2013
79
Thierry
Van
den
Berghe
è
Quand
l’action
correspondant
au
flux
entrant
est
terminée,
on
a
un
choix,
on
peut
exécuter
l’une
ou
l’autre
action
prédécesseur.
Ce
qui
permet
de
déterminer
l’action
prédécesseur
qu’on
va
exécuter
ce
sont
des
conditions
de
garde.
Exemple
:
Ici
:
action
demander
un
crédit
qui
s’enchaine
conditionnellement
:
Ø si
client
solvable
:
accorder
crédit
Ø si
non
:
refuser
crédit.
Ici
on
a
que
deux
sorties
mais
on
pourrait
en
avoir
plus
avec
des
conditions
de
garde
d'office
mutuellement
exclusives.
Si
on
veut
exécuter
plusieurs
actions
en
parallèle
après
la
première
action
è
alors
un
autre
noeud
est
nécessaire.
NOEUD
MERGE
Ø conjonction
de
flux
Ø action
3
est
exécutée
après
terminaison
de
l'action
1
OU
terminaison
de
l'action
2
Ø n
flux
entrants,
1
flux
sortants

80. Manon
Cuylits
Master
1
2012-­‐2013
Idée
:
pouvoir
exécuter
l’action
si
80
Noeud
avec
plusieurs
flux
rentrant
et
un
seul
sortant.
è
l’une
ou
l’autre
action
qui
rentre
dans
le
noeud
est
réalisée.
Développement
de
systèmes
e-­‐business
Exemple
:
On
peut
expédier
un
article
soit
si
la
fabrication
d'un
article
est
terminée
soit
si
on
a
acheté
l’article
a
un
fournisseur.
Ici
on
a
2
entrées
mais
on
pourrait
en
avoir
plus.
ATTENTION
:
au
niveau
de
l’action
UNE
SEULE
flèche
peut
rentrer.
NOEUD
JOIN
Ø conjonction
synchronisée
de
flux
Ø action
3
est
exécutée
après
terminaison
de
l'action
1
ET
terminaison
de
l'action
2
Contrairement
au
choix,
noeud
représenté
par
une
barre
horizontale
dit
que
l’action
qui
sort
du
noeud
ne
peut
être
exécuté
que
quand
les
2
actions
prédécesseurs
dont
réalisées
(l'un
ET
l’autre,
et
pas
l'un
OU
l’autre
!!!)

81. Manon
Cuylits
Master
1
2012-­‐2013
81
Thierry
Van
den
Berghe
Exemple
:
Ici
on
peut
clôturer
la
commande
si
on
a
expédié
les
articles
ET
envoyé
la
facture.
On
peut
avoir
autant
de
noeud
qu’on
veut
entrant
dans
ce
noeud
de
jointure.
NOEUD
FORK
Ø création
de
flux
concurrents
Ø action
2
ET
action
3
sont
exécutées
après
terminaison
de
l'action
1
Ici
on
déclenche
en
parallèle
plusieurs
actions
qui
succèdent
à
une
action
prédécesseur.
Exemple
:

82. Manon
Cuylits
Master
1
2012-­‐2013
Quand
on
a
terminé
d’inscrire
un
étudiant
on
va
exécuter
en
parallèle
:
choisir
les
cours
et
payer
les
droits
d’inscription.
Exemple
:
post-­‐conditions,
i.e.
affirmations
vérifiées
après
exécution
de
l'action
82
PARTITION
Ø défini
le
contexte
de
l'activité
o qui
exécute
l'action?
o où
l'action
est-­‐elle
réalisée?
Ø partition
horizontale
et
/
ou
verticale
Ø optionnelle
On
peut
partitionner
les
emplacements
d’exécution
en
horizontal
ou
vertical.
DETAIL
DES
ACTIONS
Ø le
fonctionnement
des
actions
peut
être
explicité
Ø pour
une
action
réalisée
par
un
SI
– impact
de
l'action
sur
l'état
des
données
Développement
de
systèmes
e-­‐business

83. Manon
Cuylits
Master
1
2012-­‐2013
– une
commande
est
créée
dans
le
système
et
est
reliée
à
un
client
– les
quantités
disponibles
en
stocks
sont
diminuées
à
concurrence
des
Identifier
les
actions
n'est
pas
suffisant
pour
une
description
fine
du
système
d’information,
chaque
action
doit
être
détaillée.
Il
existe
plusieurs
manières
de
faire.
83
Ø exemple
:
action
«
confirmer
une
commande
»
quantités
commandées
– la
liste
des
commandes
à
préparer
est
mise
à
jour
Ø pour
une
action
qui
représente
l'affichage
d'une
page
Web
– organisation
de
la
page,
attributs
graphiques,
contenu,
etc.
DIAGRAMME
D'ACTIVITES
D'UN
BUSINESS
PROCESS
Thierry
Van
den
Berghe
(TRAITEMENT
DES
COMMANDES)
Ici
:
activité
qui
décrit
une
procédure
de
prise
de
commande.
On
a
Plusieurs
départements.
On
a
un
noeud
de
début
et
de
fin.

84. Manon
Cuylits
Master
1
2012-­‐2013
84
Développement
de
systèmes
e-­‐business
Envoi
d’une
commande
è
Une
fois
quelle
a
été
postée
par
le
client,
2
flux
de
contrôle
lancés
en
parallèle
è
Le
client
paye
la
commande
è
Le
département
logistique
enregistre
la
commande
è
Finalement
le
client
reçoit
la
commande.
Exécuter
la
commande
sera
exécuté
quand
TOUT
ce
qui
précède
aura
été
réalisé
:
quand
préparer
la
commande
et
payer
la
commande
a
été
réalisé.
Et
pr
ce,
il
faut
que
les
actions
précédentes
soient
réalisées.
è
Donc
3
étapes
réalisées.
DIAGRAMME
D'ACTIVITES
D'UN
SI
(CAS
COMMANDE
WEB)
Ici
:
Système
de
commande
par
internet
avec
navigateur
et
serveur
web
et
BDD.
Navigateur
Web:
le
processus
démarre
quand
un
client
arrive
sur
le
site
pour
démarrer
une
nouvelle
commande.
Ce
dernier
ajoute
un
article
dans
son
panier
et
puis
après
1er
article,
l’utilisateur
ou
client
a
un
choix
:
ajouter
un
deuxième
article
ou
continuer
sa
commande
(calculer
total
etc.).
Ici
«
choix
»
permet
de
boucler
ou
répéter
la
même
action
autant
qu’on
veut
:
option
=
ajouter
un
article.
On
retourne
vers
ajouter
un
article
è
action
qu’on
peut
faire
autant
qu’on
veut.
Boucle
!
Quand
client
décide
que
sa
commande
est
complète,
on
le
branche
vers
d’autres
actions.

85. Manon
Cuylits
Master
1
2012-­‐2013
Ensuite
étape
de
confirmation
:
si
confirmé
on
enregistre
définitivement
la
commande
mais
si
client
abandonne,
fin
sans
suite.
On
peut
arriver
au
noeud
de
fin
de
2
manières
différentes.
Normalement
on
ne
peut
pas
avoir
plusieurs
flèches
qui
arrivent
dans
une
même
action
ou
noeud
de
fin.
On
avait
vu
comment
détailler
les
séquences
d'évènement
pour
ce
cas.
Voici
le
diagramme
d’activité.
85
DETAIL
DU
CAS
VENTE
COMPTOIR
EXTENSION
DES
DIAGRAMMES
D’ACTIVITE
UML
2.01
Les
diagrammes
d'activité
ont
été
largement
étoffés
par
UML
2.0
–
2003,
notamment
:
Ø flux
d'objets
Ø gestion
des
exceptions
Ø répétitions
et
exécutions
parallèles
de
groupes
d'actions
Ø événements
Thierry
Van
den
Berghe
1
Pas
utilisé
dans
les
exercices
2
Si
on
tape
balsamiq
on
peut
retrouver
cette
vidéo
(Google)
et
utiliser
en
test
l’outil

86. Manon
Cuylits
Master
1
2012-­‐2013
Ici
on
va
voir
des
constructions
complémentaires
des
diagrammes
d’activité,
apparus
avec
la
version
2
d’UML.
Il
faut
savoir
quelles
existent
et
savoir
les
expliquer
(mais
pas
spécialement
les
utiliser
dans
les
exercices)
souvent
on
voit
que
certains
dossiers
sont
transformés
exemple
:
on
introduit
un
dossier
dans
86
Dans
la
suite
:
illustration
partielle
des
ces
facilités
OBJECT
FLOWS
Ø un
flux
de
contrôle
peut
porter
un
objet
passé
entre
des
actions
Ø le
même
objet
peut
transiter
par
plusieurs
actions
qui
modifient
son
état
Flux
d’objets
:
Important
pour
gestionnaire
è
progressivement
par
un
processus
composé
de
différentes
actions.
Souvent
les
objets
évoluent
et
changent
de
statut
è
unif
étrangère,
ce
dossier
va
passer
par
différentes
instances,
statuts
Développement
de
systèmes
e-­‐business
è
pour
expliciter
cette
procédure
on
peut
utiliser
les
flux
d’objet.
Flux
d'objet
est
représenté
par
un
rectangle.
Objet
:
grappe
de
donnée
Ici
on
voit
comment
une
commande
peut
évoluer
au
cours
du
temps
et
être
transformée
progressivement
par
différentes
actions.
Ø Enregistre
une
nouvelle
commande
è
produire
une
commande
enregistrée
dans
le
système.
Ø On
précise
le
nom
de
l’objet
dans
le
statut.

87. Manon
Cuylits
Master
1
2012-­‐2013
Une
fois
la
commande
placée,
on
enclenche
l’action
de
validation
de
la
commande.
Résultat
:
produire
une
commande
VALIDEE.
Transit
d’actions
en
actions
:
évolution,
changement
de
statut
Ø un
groupe
d'actions
(région
interruptible)
peut
être
interrompu
si
un
événement
se
87
Ø Objet
produit
puis
consommé
par
action
suivante.
Ø Relation
d’entrée
sortie
entre
différentes
actions
INTERRUPTIBLE
ACTIVITY
REGION
(UML
2.0)
Thierry
Van
den
Berghe
produit
Ø le
flux
de
contrôle
est
alors
redirigé
en
dehors
de
la
région
interruptible
On
est
en
train
d’enregistrer
une
commande
sur
un
site
et
à
un
moment
donné
on
peut
abandonner
la
commande,
pendant
que
le
processus
en
cours.
(N’importe
quand)
Exemple
:
après
chaque
action,
on
fait
un
test
:
continuer
ou
abandonner
C’est
très
lourd
si
il
y
a
beaucoup
d’actions
è
Il
faut
tester
à
la
fin
de
chaque
action.
Solution
:
identifier
une
zone
interruptible
:
ensemble
d’actions
qui
s’enchainent
mais
peuvent
être
interrompues
à
n’importe
quel
moment.
è
Délimitée
avec
pointillés
è
Permet
de
casser
la
chaine
de
traitement
en
cours
pour
pointer
vers
d’autres
choses
comme
par
exemple
ici
un
abandon
de
la
commande.
Dans
cette
chaine
on
peut
avoir
une
interruption
à
n’importe
quel
moment.

88. Manon
Cuylits
Master
1
2012-­‐2013
Exemple
:
itération
de
la
fabrication
d'un
produit
fini
à
partir
d'une
matière
première
Dans
certaines
situations
on
peut
être
amené
a
répéter
une
série
d’actions
pour
traiter
des
matières
premières
ou
des
dossiers
rentrant
ou
autre
:
des
objets
rentrant
dans
un
processus.
Ici
:
zone
interruptible
répétée
autant
de
fois
qu’on
a
d’objets
rentrant
dans
ce
process
délimité
par
les
pointillés
«
zone
interruptible
».
On
a
l’action
de
démarrage
de
la
production,
puis
les
matières
premières
à
traiter.
Pour
chaque
objet
rentrant
dans
processus
itératif
on
a
des
produits
finis.
Si
jamais
le
produit
fini
est
correct,
qu’il
fonctionne
bien,
on
va
le
stocker
et
il
va
être
emmagasiné
dans
un
stock
d’objets
sortant
de
ce
processus.
Ici,
une
interruption
peut
être
appelée
au
niveau
de
l’itération
même.
Ce
n’est
pas
vraiment
un
noeud
de
fin
de
l’activité
mais
un
noeud
de
fin
de
l’itération.
Idée
:
traiter
de
manière
itérative
des
actions
de
la
zone
interruptible
en
fonction
des
objets
rentrant.
Cas
précédent
:
on
faisait
une
fois
et
on
pouvait
interrompre
a
n’importe
quel
moment.
88
EXPANSION
REGION
(UML
2.0)
Ø un
groupe
d'actions
(région
d'expansion)
peut
être
exécuté
plusieurs
fois
en
séquences
itératives
ou
en
parallèle
Ø consommation
d'objets
entrants
et
production
d'objets
sortants
Développement
de
systèmes
e-­‐business

89. Manon
Cuylits
Master
1
2012-­‐2013
89
WAIT
TIME
ACTION
(UML
2.0)
On
peut
représenter
une
échéance
précise
dans
le
temps
dans
un
diagramme
d’activité.
Ici
:
Commandes
préparées
Thierry
Van
den
Berghe
è
il
faut
qu’il
soit
16h
et
à
ce
moment
là,
on
peut
expédier
la
commande.
«
Wait
Time
Action
»
est
considéré
comme
accompli
à
partir
de
16h.
Si
les
commandes
sont
préparées
à
16h30,
l’expédition
démarrera
à
16h30,
mais
à
partir
de
16h
c'est
bon.
(Considéré
accompli)
è
2
processus
doivent
être
terminés
avant
d’enclencher
l’expédition.
ERREURS
FREQUENTES
Ø oubli
du
sens
des
flux
Ø action
sans
flux
sortant
Ø condition
de
garde
présentée
comme
une
action
Ø acteur
représenté
comme
action

90. Manon
Cuylits
Master
1
2012-­‐2013
Ø «
Vendeur
magasin
»
représente
une
action
ici,
mais
«
vendeur
magasin
»
ce
n’est
pas
une
action,
c'est
un
acteur.
Attention
de
pas
tout
mettre
dans
le
même
sac
!
Pas
tout
mettre
dans
des
rectangles.
2
conditions
de
garde
qui
ne
sont
pas
représentées
ici
pas
comme
des
conditions
de
garde
mais
comme
des
actions
or
ce
sont
des
tests,
pas
des
actions
Ø Pas
oublier
le
sens
des
flèches
!!!!
Mettre
des
sens
!!!
Ø On
a
oublié
de
connecter
un
flux
sortant
vers
un
noeud
de
fin
or
tous
flux
sortant
90
Ø Créer
une
vente
peut
déboucher
sur
2
choses
ici
è
doivent
converger
vers
un
noeud
de
fin.
DIAGRAMMES
D’ACTIVITE
ET
SITES
WEB
Dernière
application
:
représentation
de
la
navigation
au
sein
d'un
site
web
Ø reprend
les
séquences
de
navigation
entre
les
pages
Développement
de
systèmes
e-­‐business
– action
è
afficher
une
page
– transition
è
hyperlien
Ø nécessite
d'identifier
les
pages
–
informationnelles
–
applicatives
Ø la
logique
de
certaines
pages
(surtout
les
pages
applicatives)
doit
être
explicitée
– formalisme
:
diagrammes
d'activité
Exemple
:
home
banking
Ici
le
flux
de
contrôle
représentent
des
hyperliens
et
les
actions
correspondent
à
l’affichage
d’une
page
du
site.

91. Manon
Cuylits
Master
1
2012-­‐2013
91
Attention
:
dans
un
système
e-­‐business
il
existe
2
catégories
de
pages
:
les
Thierry
Van
den
Berghe
pages
statiques
et
les
pages
applicatives.
Ce
dernier
type
de
page
modifie
les
données
du
système
(exemple
:
permet
d’enregistrer
un
nouveau
virement,
transforme
les
données
è
mécanisme
peut
être
décrite
avec
diagramme
d’activité
traditionnel).
è
Utilisation
traditionnelle
pour
décomposer
un
processus
ou
application
plus
spécifique
EXEMPLE
DE
NAVIGATION
Ici
un
noeud
de
départ
pointe
vers
une
page
d’accueil.
A
partir
de
la
page
d’accueil,
on
peut
naviguer
vers
différentes
pages.
Chaque
fois,
il
y
a
des
conditions
de
garde
qui
déterminent
le
chemin
a
suivre
au
niveau
des
connections
(niveau
des
hyperliens).
Une
action
symbolise
l’affichage
dune
page.
Souvent
on
part
de
la
page
d’accueil,
on
visite
d’autre
page
et
à
la
fin
de
chacune
de
ces
pages
on
converge
vers
un
retour
vers
la
page
d’accueil.
Plein
d’autres
modèles
sont
possibles.

92. Manon
Cuylits
Master
1
2012-­‐2013
Ø Une
entreprise
de
vente
de
PC
par
Internet
organise
son
activité
comme
suit.
Ø Un
client
enregistre
une
commande
sur
le
site
de
l'entreprise.
Le
département
ventes
vérifie
alors
la
commande.
Si
le
solde
des
paiements
en
cours
du
client
est
supérieur
1000,
alors
la
commande
est
annulée.
Sinon
le
traitement
de
la
commande
se
poursuit
en
vérifiant
les
stocks
disponibles
pour
les
articles
de
la
commande.
Ø Si
les
stocks
sont
suffisants,
le
département
ventes
édite
une
facture
et
le
service
expédition
prépare
la
commande.
Ensuite,
ce
même
service
expédie
la
commande
en
joignant
la
facture
au
colis.
Ø Si
les
stocks
sont
insuffisants,
le
département
ventes
met
la
commande
en
attente
92
DETAIL
DE
PAGE
APPLICATIVE
On
peut
représenter
le
fonctionnement
dune
page
applicative
è
exemple
de
la
page
de
contact
:
enregistre
une
demande
de
contact
EXERCICES
LIVRAISON
DE
COMMANDE
et
enregistre
une
nouvelle
commande
fournisseur
pour
les
articles
concernés.
Développement
de
systèmes
e-­‐business

93. Manon
Cuylits
Master
1
2012-­‐2013
Ø Un
système
de
commande
sur
le
Web
est
pensé
comme
suit:
Ø le
système
affiche
une
page
d'accueil
à
partir
de
laquelle
l'internaute
peut
choisir
Ø au
sein
d'une
rubrique,
l'internaute
sélectionne
un
ou
plusieurs
articles
à
93
SAISIE
DE
COMMANDE
VIA
LE
WEB
une
rubrique
de
produits
en
s'identifiant
éventuellement
au
préalable;
Thierry
Van
den
Berghe
commander;
Ø l'internaute
peut
naviguer
vers
une
autre
rubrique
pour
sélectionner
d'autres
articles;
Ø si
l'internaute
a
sélectionné
tous
les
articles
qui
l'intéressent
et
ne
souhaite
plus
consulter
d'autres
rubriques,
le
système
lui
montre
alors
le
récapitulatif
de
sa
commande
et
l'invite
à
s'identifier
si
ce
n'est
déjà
fait;
Ø l'internaute
clôture
la
transaction
en
confirmant
la
commande.
WEB
BANKING
Ø DuoDos
est
une
nouvelle
banque
durable
qui
souhaite
développer
un
système
de
Web-­‐banking.
Monsieur
Janssens,
qui
n’est
pas
informaticien,
a
une
idée
plus
ou
moins
précise
du
fonctionnement
du
système
qu’il
a
tenté
de
décrire
ci-­‐dessous.
Ø Un
client
arrive
sur
le
site
et
commence
par
s’identifier.
S’il
n’y
parvient
pas
après
trois
tentatives
successives,
l’accès
au
Web-­‐banking
est
bloqué
et
le
système
affiche
un
message
demandant
au
client
de
contacter
son
agence.
Ø En
cas
d’identification
fructueuse,
le
client
peut
soit
consulter
des
comptes,
soit
ajouter
un
bénéficiaire
d’un
(futur)
virement,
soit
demander
d’ouvrir
un
nouveau
compte.
Ø Lors
de
la
consultation
des
comptes,
le
client
peut
soit
visualiser
le
détail
des
mouvements
d’un
compte
particulier,
soit
enregistrer
un
virement.
Pendant
la
consultation
des
mouvements,
le
client
peut
visualiser
des
opérations
plus
anciennes
en
cliquant
autant
de
fois
qu’il
le
souhaite
sur
un
bouton
«
opérations
antérieures
».
Ø Pour
enregistrer
un
nouveau
virement,
le
client
doit
en
même
temps
préciser
le
montant
ainsi
que
la
communication
et
choisir
un
bénéficiaire
dans
une
liste.
Quand
ces
deux
opérations
sont
terminées,
il
peut
alors
confirmer
ou
abandonner
le
virement.
Ø Pour
ouvrir
un
compte,
le
client
doit
remplir
un
formulaire
en
ligne.

94. Manon
Cuylits
Master
1
2012-­‐2013
94
4.
DIAGRAMME
DE
CONTENU
Ø les
contenus
ont
des
formes
très
variées
– données
structurées
régulières
(données
bibliographiques)
– images,
textes
non
structurés,
audio,
vidéo,
etc.
– contenus
importés
d'autres
applications
(Exemple
:
prévisions
Développement
de
systèmes
e-­‐business
météo)
Ø la
représentation
des
données
structurées
est
spécifiée
avec
les
modèles
de
données
classiques
(Exemple
:
entité/association)
– les
données
structurées
sont
le
plus
souvent
gérées
par
un
SGBD
– autres
formes
de
contenus
:
pas
de
représentations
standard
au
niveau
conceptuel
Pour
le
contenu
à
poster
sur
le
site,
pas
de
formalisme.
On
les
communique
brutes
aux
informaticiens.
L’interface
homme-­‐machine
est
très
importante,
surtout
dans
commerce
électronique.
Spécifier
allure
d’un
futur
peut
se
faire
de
plusieurs
manières
:
Ø utiliser
des
outils
de
maquettage
Ici
démonstration
d’un
système
è
balsamiq2
:
En
quelques
clics
on
peut
nous
même
donner
une
idée
a
l’informaticien
de
l’allure
souhaitée
de
notre
future
site
(Cf.
vidéo).
Ici
il
s’agit
de
créer
une
interface.
On
ne
crée
pas
un
système
ici.
Ici
on
a
une
idée
de
ce
qu’on
veut
et
on
crée
l’allure
dune
page.
Ce
n’est
pas
un
site
mais
juste
une
maquette
graphique.
On
peut
l’envoyer
aux
programmeurs.
2
Si
on
tape
balsamiq
on
peut
retrouver
cette
vidéo
(Google)
et
utiliser
en
test
l’outil
disponible
en
ligne.

95. Manon
Cuylits
Master
1
2012-­‐2013
95
EXEMPLES
DE
REPRESENTATIONS
DE
CONTENUS
Thierry
Van
den
Berghe

96. Manon
Cuylits
Master
1
2012-­‐2013
Ø fait
intervenir
des
graphistes,
des
ergonomes,
etc.
qui
s'assurent
de
la
lisibilité
et
de
96
5.
DIAGRAMME
D’INTERFACE
l'ergonomie
du
site
Ø composants
typiques
:
– schéma
de
structure
de
page
– charte
graphique
Ø la
charte
graphique
détermine
les
attributs
visuels
du
site
– couleurs
des
contenus
et
des
fonds
– styles
de
textes
(polices,
fontes,
etc.)
– styles
des
boutons
de
navigation
et
des
hyperliens
– format
des
images,
etc.
Ø le
schéma
de
structure
représente
les
pages
de
manière
abstraite
– indépendamment
d'une
technologie
cible
EXEMPLE
DE
SCHEMA
DE
STRUCTURE
DE
PAGE
Ø formalisme
libre
et
non
standard
Ø les
outils
de
développement
Web
proposent
des
structures
génériques
Développement
de
systèmes
e-­‐business

97. Manon
Cuylits
Master
1
2012-­‐2013
97
EXEMPLE
DE
STRUCTURE
GENERIQUE
DE
PAGE
EXEMPLE
DE
CHARTE
GRAPHIQUE
Thierry
Van
den
Berghe

98. Manon
Cuylits
Master
1
2012-­‐2013
Ø un
document
de
cadrage
du
projet
où
on
décrit
des
intentions,
on
motive
le
projet,
98
6.
ETUDE
DE
CAS
On
en
est
à
l’issue
de
l’activité
de
spécification
Quand
on
enclenche
un
projet
e-­‐business
il
y
a
2
étapes
clés
a
produire.
Développement
de
systèmes
e-­‐business
etc.
Ø quand
le
projet
est
confirmé
:
rédaction
d’un
document
de
spécification
ou
on
décrit
l’ensemble
du
système
Si
on
souhaite
externaliser
le
développement,
faire
appel
à
une
société
de
service
pour
le
prendre
en
charge,
la
document
de
spécification
prend
l'allure
d’un
cahier
de
charge.
Idée
:
définir
un
document
qui
va
servir
après
de
base
contractuelle
pour
les
échanges
avec
la
société
de
service.
EXEMPLE
DE
CAHIER
DE
CHARGES
Ici
on
s’adresse
à
des
fournisseurs
qui
ne
connaissent
pas
nos
attentes
etc.
donc
en
premier
lieu,
il
convient
de
présenter
l’entreprise
(premier
chapitre)
Ici
c’est
EDIBOOK,
une
petite
maison
d’édition.
Ø On
a
dans
le
premier
chapitre
(de
présentation
de
la
société),
un
historique,
la
structure
et
l’organigramme,
les
produits
et
une
critique
de
l’existant)
Ø Ensuite,
dans
un
deuxième
chapitre,
on
a
l’appel
d’offre.
è
Contexte
?
Motivation
?
Ø Dans
un
troisième
chapitre,
on
mettra
les
spécification
du
système,
des
besoins
des
utilisateurs
:
repérer
les
différents
modèles,
langages
de
modélisation.
Ø Dans
un
quatrième
chapitre,
on
trouvera
les
besoins
non
fonctionnels.
Ø Finalement,
dans
un
dernier
chapitre,
il
est
bon
de
spécifier
l’offre
de
service
qu’on
attend
du
fournisseur.
On
envoie
ce
cahier
de
charge
à
une
dizaine
de
fournisseurs
è
l’analyse
est
plus
simple
si
on
impose
une
certaine
structure
dans
les
réponses.
On
peut
demander
au
fournisseur
de
préciser
le
planning,
etc.

99. Manon
Cuylits
Master
1
2012-­‐2013
Le
cahier
des
charges
doit
permettre
au
fournisseur
de
réaliser
une
estimation
des
coûts
de
développement.
Il
sera
intégré
dans
le
contrat
de
service
passé
avec
le
fournisseur
choisi.
moyennant
accord,
si
le
fournisseur
propose
une
solution
progicielle
existante,
par
exemple
une
plate-­‐forme
open
source
ou
un
outil
développé
par
le
fournisseur
lui-­‐même.
EDIBOOK
n'impose
aucun
standard
technologique
99
CONTENU
APPEL
D’OFFRE
EDIBOOK
est
prêt
à
adapter
légèrement
ses
attentes,
Thierry
Van
den
Berghe
pour
le
développement.
La
fonctionnalité
du
système,
la
qualité
de
la
solution,
son
coût
et
l'expertise
du
fournisseur
sont
les
principaux
critères
de
choix.
Après
une
première
sélection
sur
la
base
de
l'analyse
des
offres
écrites,
les
fournisseurs
potentiels
retenus
seront
contactés
pour
un
approfondissement
de
leur
offre.
La
propriété
de
tous
les
éléments
du
système
conçus
sous
la
responsabilité
du
fournisseur
(développements
spécifiques,
charte
graphique,
dessins
d'écran,
etc.)
est
transférée
sans
exception
ni
réserve
au
client.
Le
fournisseur
assumera
seul
la
responsabilité
de
l'offre
et
du
développement.
En
cas
de
sous-­‐traitance,
il
restera
seul
maître
d'oeuvre.
La
réception
provisoire
sera
réalisée
quand
:
Ø tous
les
matériels
et
logiciels
seront
installés,
testés
et
mis
en
oeuvre
conformément
aux
spécifications
du
présent
cahier
des
charges
;
Ø la
formation
aura
été
dispensée.

100. Manon
Cuylits
Master
1
2012-­‐2013
100
Développement
de
systèmes
e-­‐business
La
réception
définitive
sera
réalisée
au
plus
tôt
6
mois
après
la
réception
provisoire.
CAS
D’UTILISATION

101. Manon
Cuylits
Master
1
2012-­‐2013
101
ACTIVITE
Thierry
Van
den
Berghe

102. Manon
Cuylits
Master
1
2012-­‐2013
102
ENTITE/ASSOCIATION
INTERFACE
Développement
de
systèmes
e-­‐business

103. Manon
Cuylits
Master
1
2012-­‐2013
On
peut,
par
exemple,
imposer
des
minimums
de
performance
ou
de
sécurité,
ou
encore
des
compatibilité
avec
un
existant
(exemple
:
travailler
avec
environnement
Apple,
Mac,
on
103
BESOINS
NON
FONCTIONNELS
peut
imposer
que
le
système
puisse
communiquer
avec)
OFFRE
DE
SERVICE
On
dit
quelles
sont
nos
attentes
par
rapport
à
une
offre
de
service.
Thierry
Van
den
Berghe

104. Manon
Cuylits
Master
1
2012-­‐2013
104
Développement
de
systèmes
e-­‐business
è
Spécifier
un
niveau
de
service
(fréquent)
Ø On
impose
par
exemple
des
délais
d’intervention
en
cas
de
panne.
Ø On
impose
que
les
problème
soient
résolus
dans
les
8h
ouvrables
maximum
sous
peine
de
pénalités
de
retard.
è
Table
des
matières
qui
va
faciliter
largement
la
réponse

105. Manon
Cuylits
Master
1
2012-­‐2013
Ici
on
aborde
l’activité
de
réalisation
du
système.
D’abord
on
détaillera
les
activités
de
conception
et
de
mise
en
oeuvre
puis
nous
verrons
les
outils
de
mise
en
oeuvre
employés
par
les
informaticiens
pour
la
création
des
systèmes
e-­‐
business,
et
pour
finir
nous
verrons
les
techniques
clés
qui
interviennent
le
plus
fréquemment
dans
le
développement
de
ces
applications.
La
réalisation
du
système
couver
des
tâches
essentiellement
techniques,
prises
en
charge
par
les
informaticiens.
La
réalisation
du
système
implique
au
premier
chef
les
informaticiens.
Même
si
les
utilisateurs
sont
mis
à
contribution
de
temps
en
temps
pour
par
exemple
spécifier
leur
demande
ou
évaluer
des
prototypes
intermédiaires.
La
réalisation
du
système
implique
2
choses
:
1. Conception
:
établir
les
plans
détaillés
du
système
sous
un
angle
technique
et
non
105
5.
REALISATION
Thierry
Van
den
Berghe
plus
fonctionnel.
2. A
partir
de
ca
il
sera
possible
au
programmeur
de
créer
concrètement
le
système
en
produisant
le
code
des
programmes
qui
feront
partie
de
ce
système.
è
créer
concrètement
le
système
Ces
activités
techniques
de
conception
et
mise
en
oeuvre
s’appuie
sur
des
outils
de
développement,
qu’on
appelle
parfois
aussi
des
outils
de
génie
logiciel,
et
la
mise
en
oeuvre
(fabrication
concrète)
font
appel
à
des
technologies
spécifiques
(ex
:
XML).
1.
CONCEPTION
ET
MISE
EN
OEUVRE
CONCEPTION
Jusqu’à
présent
on
a
toujours
considéré
le
système
comme
une
boite
noire
en
se
concentrant
sur
ses
facilités
et
les
fonctionnalités
;
mais
on
ne
s’est
jamais
concentré
sur
la
structure
et
son
organisation
interne.
Ex
:
quel
serait
le
schéma
de
la
base
de
donnée
sous-­‐
jacente
au
système
et
les
programmes
d’application
qui
vont
permettre
de
traiter
ces
données.
C’est
justement
l’objectif
de
la
conception.
Objectif
de
la
conception
:
-­‐ établir,
à
l’intention
des
programmeurs,
les
spécifications
du
système
à
construire
sous
un
angle
technique,
par
exemple
en
fonction
de
choix
technologiques
établis
è
établir
des
plans
techniques,
des
spécifications
techniques,
qui
seront
des
lignes
de
conduite
pour
les
programmeurs.
-­‐ On
dit
souvent
que
la
conception
décrit
le
«
comment
»
plutôt
que
le
«
quoi
».
-­‐ Dégager
une
réponse
aux
besoins
par
l’application
des
TIC

106. Manon
Cuylits
Master
1
2012-­‐2013
-­‐ choisir
les
TIC
(technologies)
les
plus
adaptés
aux
spécifications,
aux
attentes
des
utilisateurs.
Ex
:
choisir
un
système
de
gestion
de
BDD
ou
un
langage
de
programmation
plutôt
qu’un
autre.
Le
travail
de
conception
va
décrire
le
système
sous
un
angle
technique,
et
comme
toujours,
pour
représenter
le
système,
on
va
faire
appel
à
des
formalismes.
Cependant,
ici
les
techniques
de
représentation
du
système
seront
relativement
techniques
(parce
qu’on
se
rapproche
de
la
machine)
et
très
spécifiques
au
technologies
(TIC)
qui
ont
été
choisies
pour
développer
le
système.
Cependant,
les
représentations
restent
essentiellement
graphiques
comme
on
va
le
voir
ci-­‐dessous.
Même
dans
ce
travail
fort
technique,
les
utilisateurs
doivent
toujours
rester
actifs,
par
exemple
pour
préciser
leurs
besoins
ou
valider
certaines
parties
du
système
en
développement.
106
Quelques
exemples
de
tâches
qui
interviennent
dans
l’étape
de
conception
-­‐ spécifier
l’architecture
et
les
composants
du
système
-­‐ concevoir
un
schéma
de
base
de
données
-­‐ imaginer
et
décrire
les
interfaces
du
système
-­‐ identifier
l’ensemble
des
programmes
à
écrire
Développement
de
systèmes
e-­‐business
è
Contribution
ponctuelle
des
utilisateurs
(précisions,
besoins
non
fonctionnels).
Exemple
:
validation
de
la
maquette
graphique
Raffinement
de
la
description
du
système
décrit
lors
de
l'analyse
en fonction
d'un
contexte
technologique
EXEMPLE
DE
REPRESENTATION
Voici
quelques
exemples
de
représentation
au
niveau
de
la
phase
de
conception.
Exemple
:
Conception
d'un
schéma
de
base
de
données
relationnelle
à
partir
des
spécifications
entité/association.

107. Manon
Cuylits
Master
1
2012-­‐2013
La
mise
en
oeuvre
a
pour
objectif
de
construire,
ou
programmer
le
système.
C’est
le
gros
d’un
projet
de
développement
informatique.
Au
niveau
de
la
mise
en
oeuvre,
on
produit
la
description
la
plus
fine,
la
plus
ultime
du
système,
à
savoir
du
code
interprétable
par
les
machines.
Ici,
on
voit
un
exemple
d’inscription
SQL
pour
créer
une
base
de
donnée,
c’est
le
niveau
de
détail
le
plus
fin
qu’on
puisse
imaginer
pour
une
base
de
donnée.
107
MISE
EN
OEUVRE
Exemples
de
tâches
réalisées
lors
de
cette
activité
de
mise
en
oeuvre
:
-­‐ génération
et
configuration
de
la
base
de
données
-­‐ écriture
du
code
des
pages
d’un
site
WEB
ou
d’un
programme
d’application
-­‐ paramétrage
et
intégration
de
composants
standard
Formalisme
:
langages
informatiques
EXEMPLE
DE
REPRESENTATION
Thierry
Van
den
Berghe

108. Manon
Cuylits
Master
1
2012-­‐2013
Pour
avoir
une
idée
de
la
manière
dont
les
programmeurs
produisent
effectivement
le
système,
on
va
voir
quelques
exemples
d’outils
de
développement
largement
utilisés
pour
la
production
d’applications
e-­‐business.
On
va
voir
essentiellement
3
exemples
:
Tout
programme
informatique
est
composé
d’une
série
d’instructions
qui
peuvent
être
exécutées
par
un
ordinateur.
Il
est
nécessaire
de
disposer
d’éditeurs
de
code
pour
permettre
au
programmeur
de
créer
les
lignes
d’instruction
à
exécuter
par
l’ordinateur.
Pour
développer
des
systèmes
e-­‐business
très
spécifiques,
on
utilise
des
éditeurs
adapter,
pour
développer
des
sites
web,
des
chartes
graphiques,
ou
des
animations
graphiques
qui
vont
enjoliver
un
site
de
vente
en
ligne
par
exemple.
è
Le
système
est
explicitement
programmé
par
les
informaticiens
à
l'aide
d'outils
comme
:
Ø des
éditeurs
de
code
pour
créer
des
pages
WEB.
Exemple
:
Macromedia
Ø des
logiciels
de
graphisme
et
d'animation.
Exemple
:
Adobe
Photoshop
et
Illustrator,
Construire
un
système
e-­‐business
de
cette
manière
permet
de
coller
à
des
besoins
très
spécifiques
des
utilisateurs,
si
ceux-­‐ci
ne
trouvent
pas
leur
bonheur
dans
une
offre
progicielle
déjà
existante.
Malheureusement,
si
c’est
un
projet
très
personnalisé,
cela
a
un
cout
:
essentiellement
le
cout
de
main
d’oeuvre
lié
à
l’écriture
des
programmes.
En
plus
l’écriture
d’instruction
d’un
système
e-­‐business
n’est
pas
à
la
portée
du
premier
venu,
il
faut
une
formation,
un
bagage
technique,
parce
qu’il
faut
en
général
combiner
des
technologies
diverses
et
parfois
complexes.
108
2.
OUTILS
DE
DEVELOPPEMENT
-­‐ les
outils
de
développement
classiques
-­‐ les
générateurs
automatiques
de
sites
web
-­‐ les
package
et
plus
particulièrement
un
exemple
d’outil
de
content
management
OUTILS
DE
DEVELOPPEMENT
CLASSIQUES
Dreamweaver,
Adobe
Golive,
Microsoft
Visual
Studio
Macromedia
Fireworks
et
Flash
Avantages
Inconvénients
Ø développement
de
systèmes
bien
adaptés
à
la
demande
Ø coût
du
développement
Ø besoin
de
compétences
professionnelles
Développement
de
systèmes
e-­‐business

109. Manon
Cuylits
Master
1
2012-­‐2013
Le
marché
propose
toute
une
série
d’outils
de
développement
pour
des
systèmes
e-­‐business
et
sites
web
en
particulier,
par
exemple
:
Dreamweaver
qui
est
une
des
références
du
secteur,
ou
Microsoft
Visual
Studio
(printscreen
ci-­‐dessous).
On
peut
voir
du
code,
produit
par
les
programmeurs
et
en-­‐dessous,
une
prévisualisation
du
site.
109
EXEMPLE
:
DREAMWEAVER
EXEMPLE
:
MICROSOFT
VISUAL
STUDIO
Thierry
Van
den
Berghe

110. Manon
Cuylits
Master
1
2012-­‐2013
Une
autre
manière
de
générer
des
sites
web
est
d’utiliser
des
logiciels
spécialisés
pour
créer
des
sites
web.
Le
système
est
créé
par
un
logiciel
spécialisé
sur
base
des
directives
de
l'utilisateur
Ø pas
de
programmation,
mais
utilisation
d'assistants
électroniques
pour
créer
des
110
GENERATEURS
DE
SITES
Développement
de
systèmes
e-­‐business
pages
WEB
Ø Exemple
:
http://www.weebly.com/,
MS-­‐Publisher,
Google
Site
Avantages
Inconvénients
Ø accessibles
à
des
non-­‐informaticiens
Ø développement
rapide
Ø coût
faible
Ø limites
fonctionnelles
rapidement
atteintes
Ø réaliste
essentiellement
pour
des
sites
basiques
ou
standard
L’avantage
de
cette
approche
est
qu’elle
consomme
très
peu
d’énergie,
elle
est
relativement
accessible
à
des
non-­‐informaticiens
puisqu’il
s’agit
simplement
de
spécifier
l’allure
du
site,
son
organisation,
et
à
travers
des
assistants
électronique,
ce
système
de
production
automatique
va
créer
un
site
avec
un
certain
nombre
de
fonctionnalités
standards.

111. Manon
Cuylits
Master
1
2012-­‐2013
C’est
très
intéressant
pour
des
sites
très
simples
mais
malheureusement,
dés
qu’on
tombe
dans
des
demandes
un
peu
plus
spécifiques,
on
atteint
très
vite
les
limites
fonctionnelles
de
ces
outils.
Le
système
Weebly
en
ligne
est
un
exemple
de
créateur
automatique
de
site.
Cf.
la
démonstration
sur
Icheccampus.
Une
troisième
approche
pour
développer
des
systèmes
e-­‐business
est
le
recours
au
package.
Un
package
est
un
ensemble
logiciel
avec
toute
une
série
de
fonctionnalités
cohérentes,
par
exemple
pour
gérer
un
magasin
en
ligne
ou
pour
développer
une
plateforme
e-­‐learning.
Ces
solutions,
relativement
riches
au
niveau
fonctionnel
ont
l’énorme
avantage
d’être
paramétrables
(du
moins,
dans
une
certaine
mesure).
111
EXEMPLES
PACKAGE
ET
CONTENT
MANAGEMENT
PACKAGE
Thierry
Van
den
Berghe
è
Solutions
complètes
et
paramétrables
Ø souvent
développées
pour
des
métiers
ou
des
fonctions
spécifiques
Ø Exemple
:
magasin
en
ligne,
gestionnaire
de
contenus,
ERP
Ø solutions
propriétaires
ou
libres
Ø Exemple
:
OS
Commerce,
Joomla,
Compiere,
Open
ERP

112. Manon
Cuylits
Master
1
2012-­‐2013
Cela
permet
d’éviter
un
redéveloppement
ou
un
développement
complet
du
système
puisqu’on
part,
en
quelques
sortes,
d’un
costume
prêt
à
porter
qu’on
personnalise
légèrement.
Les
couts
de
développement
sont
fort
réduits
et
cette
solution
fonctionne
bien
si
les
utilisateurs
s’y
retrouvent
dans
les
fonctionnalités
proposées
par
ces
packages.
Si
ce
n’est
pas
le
cas,
il
faut
réaliser
des
extensions
parfois
couteuses
et
complexes
à
ces
packages,
et
si
vraiment
les
besoins
des
utilisateurs
sont
trop
éloignés
de
ce
que
peut
offrir
un
package,
alors
on
préférera
un
développement
traditionnel.
Certains
de
ces
packages
sont
en
(en
accès
libre),
dés
lors
ces
packages
sont
soutenus
par
des
communautés
de
programmeurs
qui
font
évoluer
le
système.
D’autres
packages
sont
développés
par
des
sociétés
commerciales
qui
ne
distribuent
pas
leurs
sources,
on
parle
alors
de
propriétaires.
L’utilisateur
qui
s’engage
dans
une
solution
propriétaire
doit
être
conscient
qu’il
est
relativement
dépendant
de
l’éditeur
de
ce
package
propriétaire
et
il
doit
donc
s’assurer
que
ce
fournisseur,
cet
éditeur
est
fiable,
notamment
au
niveau
du
service
et
de
sa
disponibilité
sur
le
long
terme.
Un
des
premiers
besoins
qu’on
a
rencontré
dans
l’internet,
c’est
de
pouvoir
publier
de
manière
très
facile,
différents
contenus
à
destination
des
internautes.
Le
problème
pour
publier
de
l’information
sur
internet,
c’est
que
cette
information
doit
être
formatée/présentée/organisée
avec
un
langage
qui
s’appelle
le
HTML
(on
en
parlera
plus
tard).
Par
conséquent,
un
utilisateur
lambda
qui
veut
publier
le
moindre
document
doit
connaître
le
langage
HTML
pour
la
mise
en
forme
de
ce
contenu.
Avec
les
systèmes
de
content
management,
on
peut
séparer
contenu
et
mise
en
forme.
Plus
précisément,
grâce
à
ces
outils
CMS
(Content
Management
System),
l’utilisateur
peut
simplement
déclarer
un
contenu
à
publier,
la
mise
en
forme
sur
le
site
web
sera
prise
en
charge
automatiquement
par
le
CMS.
Par
conséquent,
les
CMS
sont
des
exemples
de
package
très
populaires
aujourd’hui.
Exemples
de
CMS
disponibles
en
open
source
sur
le
marché
:
Joomla,
Xoops,
Typo3,
Open
CMS,
SPIP
(regarder
la
démonstration
de
Joomla
pour
découvrir
les
fonctionnalités
offertes
par
ce
système
CMS)
112
Avantages
Inconvénients
Ø réutilisation
de
solutions
existantes
Ø développement
relativement
rapide
Ø coût
du
développement
pour
les
fonctions
non
couvertes
Ø besoin
de
compétences
Ø dépendance
dans
le
cas
d'une
solution
propriétaire
open
source
solutions
SYSTEMES
CMS
-­‐
EXEMPLES
DE
PACKAGES
Développement
de
systèmes
e-­‐business

113. Manon
Cuylits
Master
1
2012-­‐2013
113
Thierry
Van
den
Berghe
è
Content
Management
System
(CMS)
=
système
de
gestion
de
contenu
Ø outils
de
développement
et
mise
à
jour
de
sites
Ø principe
:
séparer
le
contenu
de
sa
présentation
o un
utilisateur
peut
agir
sur
le
contenu
d'une
page
sans
se
soucier
de
sa
mise
en
forme
o indépendance
de
l'utilisateur
vis-­‐à-­‐vis
de
l'informaticien
pour
mettre
le
site
à
jour
(la
mise
en
forme
d'un
page
nécessite
des
compétences
techniques,
comme
la
connaissance
du
HTML)
Les
systèmes
CMS
offrent
de
très
nombreuses
facilités,
en
voici
quelques
exemples
:
Ø import
de
données
de
sources
variées
è
la
gestion
de
données
en
format
très
variés
(du
textes,
des
images
animées,
des
worksheets,
…)
Ø ces
contenus
peuvent
être
rangés
dans
des
catégories
et
puis
des
sous-­‐catégories
è
catégorisation
de
contenus
(par
Exemple
à
travers
des
FAQ
ou
forums)
Ø d’autres
facilités
sont
liées
au
contrôle
des
différents
contenus.
è
workflow
management
pour
l'édition
et
la
mise
en
ligne
de
contenus
Ø exemple
ci-­‐dessous:
un
auteur
déclaré
dans
la
plateforme
CMS
pourrait
poster
un
nouvel
article
et
avant
publication,
on
pourrait
imaginer
que
cet
article
soit
validé
par
un
administrateur
ou
un
gestionnaire
du
site.
Le
diagramme
d’activité
nous
montre
un
exemple
de
procédure
réalisable
et
contrôlable
avec
ces
systèmes
de
content
management.

114. Manon
Cuylits
Master
1
2012-­‐2013
114
EXEMPLE:
JOOMLA
(VOIR
SLIDES)
Le
contenu
est
inséré
sans
tenir
compte
de
sa
disposition
sur
le
site
Ø mise
en
forme
du
site
automatique
et
indépendante
du
contenu
Développement
de
systèmes
e-­‐business
è
Indépendance
entre
mise
en
forme
et
contenu
Joomla
fournit
des
facilités
pour
:
Ø classifier
les
articles
en
sections
puis
en
catégories
Ø imprimer
un
contenu,
télécharger
un
contenu
en
PDF
ou
envoyer
le
contenu
par
email
Ø rechercher
des
contenus,
notamment
sur
base
des
métadonnées
Ø valider
des
contenus
d'un
utilisateur
auteur
par
un
utilisateur
éditeur
EXEMPLE
:
OPEN
ERP
(VOIR
SLIDES)
3.
TECHNIQUES
CLES
Ici
on
va
voir
les
principales
technologies
utilisées
par
les
informaticiens
professionnels
pour
développer
des
systèmes
e-­‐business.
PAGES
DYNAMIQUES
HTML
(HYPERTEXT
MARKUP
LANGUAGE)
Une
des
technologies
fondatrices
de
l’internet,
c’est
le
langage
HTML.
Dés
le
début
de
cette
technologie,
la
plupart
des
contenus
qui
circulaient
(et
circulent
toujours)
sur
l’internet,
sont
formatées
dans
ce
langage.
Format
è
le
langage
a
pour
objectif
de
mettre
en
forme
du
contenu
à
afficher
dans
un
navigateur.
Le
fonctionnement
de
ce
langage
est
le
suivant
:
le
contenu
brut
est
encadré
de
balises
ou
signaux
qui
indiquent
au
navigateur
quelle
mise
en
forme
il
faut
appliquer
au
contenu.
Exemples
de
balises
Ø Btexte
en
gras/B
è
contenu
encadré
par
des
balises
«
B
»
et
«
End
B
»
pour
«
bold
»
et
«
end
bold
»
ou
«
/bold
».
Le
résultat
sera
l’affichage
en
gras
de
ce
texte
dans
un
navigateur.
Ø Une
autre
balise
super
importante,
liée
à
la
nature
hypermédia
et
hyperlien
de
l’internet
est
la
balise
HREF
qui
permet
de
définir
au
sein
d’une
page
web
un
pointeur
vers
une
autre
page
:
A
HREF
=
'URL
du
document
pointé'

115. Manon
Cuylits
Master
1
2012-­‐2013
115
Le
contenu
et
mise
en
forme
sont
intimement
mêlés
dans
une
page
HTML
Thierry
Van
den
Berghe
è
lourdeur
de
la
mise
à
jour
:
mettre
à
jour
un
élément
d’information
à
véhiculer
sur
le
web,
ou
à
publier
à
travers
un
site
web,
nécessite
la
maitrise
de
ce
langage
HTML
puisque
le
contenu
et
la
mise
en
forme
sont
ici
intimement
mêlés.
Sert
à
coder
des
contenus
stables
à
échanger
via
Internet
Ø page
Web
statiques
Ø Exemple
:
présentation
d'entreprise
EXEMPLE
DE
PAGE
STATIQUE
Fenêtre
de
droite
:
exemple
de
code
HTML.
Le
contenu
apparaît
en
noir
et
les
balises
apparaissent
en
bleu
avec
des
délimiteurs
et
.
Fenêtre
de
gauche
:
rendu
de
ce
code
HTML.
On
peut
facilement
faire
la
connexion
entre
la
nature
des
balises
et
la
manière
dont
le
texte
est
rendu
à
l’affichage.
XML
(EXTENDED
MARKUP
LANGUAGE)
Une
évolution
du
HTML
est
le
XML.
Il
s’agit
toujours
d’un
langage
à
balise
dont
l’objectif
est
de
transférer
via
l’internet
des
données
semi-­‐structurées,
mais
ici
les
balises
décrivent
la
structure
de
l’information
et
non
plus
sa
mise
en
forme.
Grâce
à
des
standards
complémentaires
au
XML
on
arrive
à
une
meilleure
séparation
entre
contenu
et
mise
en
forme
et
surtout
on
introduit
dans
les
informations
du
web
une
notion
de
schéma
de
donnée,
ce
qui
facilite
par
exemple
la
recherche
d’informations
sur
internet
ou
l’interprétation
automatique
des
contenus
par
des
ordinateurs.
è
XML
=
Language
de
balisage
standard
pour
l'échange
de
données
Ø transmission
d'information
(semi-­‐)
structurée
dans
un
mode
texte
Ø les
balises
sont
libres
et
décrivent
la
structure
du
contenu

116. Manon
Cuylits
Master
1
2012-­‐2013
116
Développement
de
systèmes
e-­‐business
Avantages
Ø séparation
entre
contenu
et
mise
en
forme,
contrairement
au
HTML
Ø notion
de
schéma
:
les
balises
décrivent
les
structures
d'information
XSL
(eXtensible
Stylesheet
Language)
è
spécifications
de
mise
en
forme
des
données
EXEMPLE
DE
DOCUMENT
XML
Voici
un
premier
exemple
de
document
XML,
ou
les
balises
apparaissent
délimitées
par
des
et
des
.
Les
balises
ici
sont
libres
et
l’information
est
organisée
de
manière
hiérarchique.
Par
exemple,
on
a
ici
la
description
de
deux
restaurants,
et
chaque
restaurant
est
délimité
par
les
balises
restaurant
et
/restaurant.
On
constate
aussi
qu’on
n’est
pas
obligé
de
mentionner
le
même
nombre
d’informations
pour
chaque
restaurant.
Pour
«
Fritkot
»
on
n’a
que
le
nom
et
le
téléphone
alors
que
pour
«
comme
chez
lui
»
on
a
aussi
la
rue
et
le
chef.
Cette
manière
d’organiser
et
de
véhiculer
l’information
est
très
intéressante
pour
les
moteurs
de
recherche
car
maintenant,
par
exemple,
FritKot
est
interprétable
par
un
moteur
de
recherche
comme
étant
un
nom
de
restaurant.
Donc
si
un
internaute
veut
connaître
la
liste
de
tous
les
restaurants
dont
le
nom
est
«
FritKot
»,
cette
recherche
sera
nettement
plus
efficace
grâce
à
ces
méta-­‐informations
qui
sont
incluses
dans
les
documents
XML.
Cette
exemple
montre
que
le
XML
comprend
données
et
structures,
c’est
encore
le
cas
pour
le
fichier
XML
représenté
dans
la
fenêtre
de
gauche
de
l’écran
ci-­‐dessous
(ou
des
ouvrages

117. Manon
Cuylits
Master
1
2012-­‐2013
117
sont
documentés
par
rapport
à
des
auteurs,
des
maisons
de
publication,
etc.)
Thierry
Van
den
Berghe
è
l’organisation
est
de
nouveau
hiérarchique
dans
les
balises
XML.
Pour
contrôler
la
mise
en
forme
de
ces
informations,
on
peut
joindre
au
fichier
XML
une
feuille
ou
un
fichier
XSL,
comme
dans
la
fenêtre
de
droite
ci-­‐dessous.
Combiné
avec
le
fichier
XML,
le
rendu
est
celui
affiché
dans
la
fenêtre
«
Bibliographie
XML
»
è
l’intérêt
des
feuilles
XSL
est
qu’il
est
possible,
en
fonction
de
l’équipement
sur
lequel
on
souhaite
consulter
le
document
XML,
de
moduler
l’affichage
et
par
exemple
de
contrôler
l’affichage
pour
un
écran
d’ordinateur
portable,
ou
de
moduler
autrement
l’affichage
de
la
même
information,
du
même
fichier
XML,
mais
cette
fois-­‐ci
pour
un
smartphone,
dont
les
possibilités
d’affichage
sont
assez
différentes
de
celle
de
l’ordinateur
portable.
INTEROPERABILITE
DES
SYSTEMES
Aujourd’hui,
les
systèmes
d’information
des
entreprises
sont
très
massivement
connectés
grâce
à
l’internet.
C’est
donc
l’occasion
d’informatiser
d’avantage
encore
les
échanges
entre
ces
systèmes,
pour
réduire
les
interventions
humaines
par
exemple
dans
un
processus
de
commande.
Exemple
:
un
client
voit
son
stock
décroitre,
et
veut
donc
envoyer
une
commande
de
réassortiment
auprès
de
son
fournisseur
è
tout
ce
processus
pourrait
être
entièrement
pris
en
charge
par
des
systèmes
d’information,
si
le
système
d’information
du
client
et
celui
du
fournisseur
sont
capables
de
se
comprendre,
d’échanger
des
données
compréhensibles
et
d’automatiser
des
traitements
de
re-­‐commande.
è
Comment
faire
interagir
des
systèmes
hétérogènes
?

118. Manon
Cuylits
Master
1
2012-­‐2013
Ø Exemple
:
le
système
d'un
client
envoie
une
commande
à
un
système
d'un
118
Développement
de
systèmes
e-­‐business
fournisseur
Ø Exemple
:
paiement
en
ligne
délégué
à
un
système
spécialisé
extérieur
Problème
historique
en
informatique:
cf.
EDI
(Electronic
Data
Interchange)
Aujourd’hui,
après
avoir
beaucoup
travaillé
sur
des
techniques
comme
l’EDI
(Electronic
Data
Interchange),
notamment
dans
la
grande
distribution,
plusieurs
standards
se
dégagent
pour
rendre
les
systèmes
d’information
plus
inter-­‐opérables,
notamment
le
XML
et
l’architecture
orientée
service.
Pistes
de
solutions
Ø échange
de
données
:
XML
(eXtensible
Markup
Language)
Ø échange
de
services
:
SOA
(Service
Oriented
Architecture)
Ø intégration
des
systèmes
Grâce
au
XML,
on
peut
transférer
via
l’internet
des
données
avec
un
descriptif
de
celles-­‐ci,
ce
qui
rend,
par
exemple,
un
bon
de
commande
parfaitement
interprétable
par
un
système
informatique
d’un
fournisseur
qui
recevrait
un
fichier
XML
avec
les
éléments
de
la
commande.
QUELQUES
APPLICATIONS
DE
L’INTEROPERABILITE
L’interopérabilité
des
systèmes
a
énormément
d’applications,
par
exemple
pour
les
entreprises
commerciales
qui
peuvent
échanger
plus
facilement
et
automatiquement
des
informations
avec
leurs
tiers,
leurs
partenaires
internes
ou
externes,
par
exemple
pour
externaliser
la
logistique.

119. Manon
Cuylits
Master
1
2012-­‐2013
Voici
un
exemple
concret
d’échange
de
données
qui
illustre
le
besoin
d’interopérabilité
entre
le
back-­‐office
et
le
front-­‐office.
Front
office
:
interface
de
l’entreprise
par
rapport
à
ses
tiers
(clients
ou
fournisseurs)
Back
office
:
prend
plutôt
en
charge
les
opérations
internes.
Ici,
dans
le
schéma,
on
peut
suivre
tous
les
échanges
de
données
entre
le
client,
le
site
web
de
vente
en
ligne
qui
joue
le
rôle
de
front
office
ici,
et
le
reste
du
système
d’information
qui
joue
le
rôle
de
back
office.
119
Autre
exemple
:
l’échange
de
connaissances,
par
exemple,
au
niveau
fiscal.
EXEMPLE
D’ECHANGES
DE
DONNEES
SOA
(SERVICE
ORIENTED
ARCHITECTURE)
Thierry
Van
den
Berghe
è
Standard
d'invocation
de
services
Ø un
système
client
invoque
un
système
producteur
pour
lui
fournir
un
service
Ø un
service
correspond
à
l'exécution
d'un
composant
logiciel
Ø Exemple
:
calcul
d'une
prime
d'assurance,
enregistrement
d'un
paiement
L’idée
des
architectures
orientées
service
est
de
décomposer
un
logiciel
en
un
ensemble
de
composants,
chacun
de
ces
composants
rendant
un
certain
service.
Le
service
d’un
composant
peut
être
invoqué
soit
à
l’intérieur,
soit
à
l’extérieur
de
l’entreprise.
Dans
l’architecture
orientée
service,
on
a
une
idée
de
client-­‐serveur
à
une
échelle
logicielle,
relativement
microscopique.

120. Manon
Cuylits
Master
1
2012-­‐2013
Exemple
:
en
tant
que
courtier
d’assurance,
on
pourrait
vouloir
réaliser
un
calcul
de
prime,
si
on
ne
dispose
pas
sur
son
ordinateur
personnel
de
la
routine
permettant
de
calculer
une
prime,
on
peut
alors
invoquer
un
calcul
de
prime
sur
un
serveur
de
la
compagnie
d’assurance
pour
laquelle
on
travaille,
éventuellement
à
distance
120
Développement
de
systèmes
e-­‐business
è
bonne
démonstration
de
l’interopérabilité
fonctionnelle
entre
le
PC
personnel
du
courtier
et
le
système
d’information
de
la
compagnie
d’assurance.
è
Standard
d'architecture
Ø architecture
=
description
des
composants
d'un
système
et
de
leurs
interactions
Ø SOA
mène
à
la
fois
l'interopérabilité
et
la
modularité
Plus
généralement,
un
standard
d’architecture
décrit
une
manière
dont
on
va
décomposer
un
système
en
un
ensemble
de
composants
qui
interagissent
les
uns
avec
les
autres.
Grâce
à
l’architecture
orientée
services,
on
arrive
à
augmenter
l’interopérabilité
des
services
(puisque
cette
architecture
est
basée
sur
l’invocation
de
services),
on
augmente
aussi
la
modularité,
et
donc
la
facilité
qu’il
y
a
à
modifier
les
différents
composants,
puisqu’en
général,
c’est
plus
simple
de
modifier
un
composant
logiciel
de
taille
réduite
qu’un
grand
ensemble.
WEB
Services
Ø transposition
des
principes
SOA
à
l'Internet
è
émergence
du
WOA
(Web
Oriented
Architecture)
Cette
invocation
de
service
est
aujourd’hui
possible
à
travers
l’internet,
les
standards
de
l’internet
le
permettent,
on
parle
donc
d’architecture
orientée
service
dans
le
contexte
du
web.
SOA
:
VERS
UNE
ARCHITECTURE
MODULAIRE
ET
FLEXIBLE

121. Manon
Cuylits
Master
1
2012-­‐2013
Ici
on
voit
deux
figures
qui
nous
aident
à
comprendre
mieux
comment
une
architecture
orientée
service
s’organise.
Fenêtre
de
gauche
:
exemple
de
système
structuré
en
3
grands
programmes.
è
Celui
du
milieu
:
le
traitement
d’une
commande
(order
processing)
:
dans
ce
traitement
de
commande
on
voit
qu’il
y
a
différentes
étapes
qui
sont
réalisées
successivement,
au
sein
d’un
gros
programme
monolithique.
Dans
une
architecture
orientée
service,
comme
celle
illustrée
dans
la
fenêtre
de
droite,
on
constate
que
ce
processus
de
traitement
de
commande
est
recomposé
à
partir
de
modules
nettement
plus
réduits
en
taille
(intitulés
ici
:
service
réutilisable.
L’avantage
de
cette
architecture
est
qu’un
même
composant,
un
même
service,
peut
être
intégré
dans
plusieurs
processus
plus
larges.
Une
solution
radicale
pour
éliminer
les
problèmes
d’interopérabilité
serait
de
fonctionner
avec
un
seul
système.
A
ce
moment
là,
il
faudrait
encore
prévoir
l’interconnexion
entre
le
système
d’une
entreprise
(un
ERP
par
exemple)
et
les
systèmes
des
partenaires
de
cette
entreprise.
Donc,
les
problèmes
d’interopérabilité
sont
toujours
présents
et
de
toute
façon,
les
ERP
aujourd’hui
sont
majoritairement
développés
selon
une
architecture
orientée
service.
121
INTEGRATION
DES
SYSTEMES
Développement
de
systèmes
intégrés
è
plus
de
besoins
d'interopérabilité
Ø Exemple
:
ERP
de
gestion
Ø Exemple
:
intégration
du
front
office
et
du
back
office
Ø solution
limitée
aux
systèmes
internes
à
l'organisation
Thierry
Van
den
Berghe

122. Manon
Cuylits
Master
1
2012-­‐2013
Les
deux
dernières
activités
d’un
cycle
de
développement
d’un
système
e-­‐business
sont
la
mise
en
production
et
les
tests.
Les
objectifs
de
la
mise
en
production
consistent
à
basculer
le
SI
(système
e-­‐business)
d'un
environnement
de
développement
et/ou
de
test
vers
un
environnement
de
production
(ou
d'utilisation).
Après
ce
basculement,
les
utilisateurs
vont
exploiter
régulièrement
le
système
qui
vient
d’être
développé.
le
support
doit
être
particulièrement
Nom
de
domaine
=
identification
unique
de
l'Internet
pour
une
entité
proposant
plusieurs
services
Ø Exemple
d'entité
:
entreprise
avec
un
réseau
de
serveurs
Ø Exemple
de
services
:
site
Web,
messagerie
électronique
Ø l'identification
correspond
souvent
au
nom
de
l'organisation
proposant
ces
services
Ø Exemple
:
www.post.be,
smtp.skynet.be,
ftp.entreprise.be
On
va
maintenant
aborder
quelques
aspects
pratiques
du
déploiement
et
de
la
mise
en
production
d’un
système
e-­‐business.
La
première
chose
à
faire
:
être
connu
et
identifié
122
6.
MISE
EN
PRODUCTION
Exemples
de
tâches
de
l’activité
de
mise
en
production
:
Ø configurer
le
matériel
et
les
logiciels
Ø acquérir
un
nom
de
domaine
Ø choisir
l'hébergement
Ø offrir
un
support
privilégié
aux
utilisateurs
è
important
au
début
de
la
mise
en
production
d’un
nouveau
système.
ACQUERIR
UN
NOM
DE
DOMAINE
Top
Level
Domains
(TLD)
–
gérés
au
niveau
international.
Exemple
:
.com,
.edu,
.org
Domaines
nationaux
Ø Exemple
:
.be,
.fr
Ø gestion
en
Belgique
:
dns.be
Ø redevance
annuelle
Développement
de
systèmes
e-­‐business
è
pour
cela
il
faut
un
nom
de
domaine.
Ce
nom
de
domaine
correspond
souvent
au
nom
de
l’organisation
qui
propose
des
services
comme
un
site
web,
de
la
messagerie
électronique
ou
encore
de
l’échange
de
fichiers.

123. Manon
Cuylits
Master
1
2012-­‐2013
Les
domaines
sont
organisés
de
manière
hiérarchique,
par
exemple
:
tous
les
domaines
d’extension
«
.com
»
font
référence
aux
entreprises
à
vocation
commerciale
;
d’autres
classifications
par
pays,
par
exemple,
font
référence,
pour
«
.be
»
par
exemple
à
un
ensemble
de
sites
qui
sont
localisés
en
Belgique.
Concrètement,
en
Belgique
en
tous
cas,
pour
réserver
un
nom
de
domaine,
il
faut
aller
sur
le
site
www.dns.be,
pour
enregistrer
le
nom
de
domaine,
pour
autant
qu’il
soit
unique
et
payer
une
redevance
annuelle,
relativement
modeste.
123
.BE
HEBERGEMENT
D’UN
SITE
Une
autre
question
pratique
à
régler
est
la
localisation
de
l’hébergement
du
système.
Thierry
Van
den
Berghe
è
où
héberger
son
site
Web?
2
possibilités
:
Ø soit
le
système
est
localisé
sur
les
propres
équipements
de
l'organisation
(housing)
:
au
sein
même
de
l’entreprise,
sur
ses
propres
serveurs,
sur
sa
propre
infrastructure
Ø soit
le
système
est
hébergé
auprès
d'un
hébergeur
externe
dont
c’est
le
métier
(hosting)

124. Manon
Cuylits
Master
1
2012-­‐2013
Exemple
:
protection
contre
les
pannes
matérielles,
Aujourd’hui,
avec
l’avènement
du
cloud
computing,
de
plus
en
plus
d’entreprises
préfèrent
héberger
leur
système
à
l’extérieur
pour
bénéficier
d’un
niveau
de
service,
d’une
disponibilité
qu’elles
ne
peuvent
parfois
pas
s’offrir
elle-­‐même
de
manière
autonome.
L’offre
d’hébergement
croit
sans
cesse
et
les
tarifs
diminuent
constamment,
ce
qui
est
une
bonne
nouvelle
pour
les
utilisateurs.
Aujourd’hui,
les
espaces
d’hébergement
deviennent
très
importants,
relativement
flexibles,
notamment
grâce
au
cloud
computing.
Certains
acteurs
de
l’industrie
de
l’internet
mettent
à
disposition
des
data
centers
qui
sont
constitués
d’un
grand
nombre
de
serveurs
très
puissants
qui
peuvent
être
configurés
en
fonction
des
demandes
des
clients.
124
Dans
tous
les
cas
de
figure,
on
attend
d’un
système
web
Ø une
grande
disponibilité
(7/7,
24/24)
Ø une
grande
sécurité
è
l'incendie,
le
vol,
l'intrusion,
etc.
Ø un
certain
support
concernant
les
technologies
utilisées
par
le
site
EXEMPLE
D’OFFRE
D’HEBERGEMENT
Développement
de
systèmes
e-­‐business

125. Manon
Cuylits
Master
1
2012-­‐2013
La
vérification
de
la
qualité,
et
donc
le
test
de
qualité
des
produits
intermédiaires
est
permanent
et
s’étale
tout
au
long
du
cycle
de
développement.
L’activité
de
test
vise
à
une
vérification
permanente
de
la
qualité
et
ce,
à
tous
les
stades
du
cycle
de
développement.
L’idée
est
de
voir
si
la
correction
des
erreurs
qui
ont
été
identifiées
lors
des
tests,
fait
partie
intégrante
de
cette
activité
de
test.
Des
petites
erreurs
qui
peuvent
être
corrigée
rapidement
peuvent
être
intégrées
et
donc
budgétées
au
niveau
de
l’activité
de
test,
par
contre,
si
des
défauts
majeurs
sont
identifiés
alors,
peut
être
qu’un
nouveau
sous-­‐projet
de
correction
d’erreur
doit
être
mis
en
place.
125
7.
TEST
Thierry
Van
den
Berghe
Objectifs
:
Ø vérifier
continuellement
la
qualité
Ø identifier
les
défauts
de
qualité
et
y
remédier
Exemples
de
tâches
:
Ø planifier
les
tests
tout
au
long
du
cycle
de
développement
et
vérifier
la
qualité
des
délivrables
intermédiaires
Ø établir
des
scénarios
d’utilisation
à
confronter
au
système
Ø documenter
les
erreurs
et
planifier
les
corrections
èL’activité
de
test
est
vue
par
la
plupart
des
gens
comme
contraignante
et
peu
productive,
ce
qui
pousse
à
systématiser
cette
activité
de
test
dans
le
cycle
de
développement,
avec
une
planification
soignée,
ou
on
a
bien
identifié
des
jours
et
des
acteurs
pour
réaliser
ces
phases
de
test.
On
peut
aussi
s’appuyer
sur
des
scénarios
d’utilisation
les
plus
complexes
possibles
pour
vérifier
la
qualité
du
système,
et
finalement,
on
suggère
aussi
de
bien
documenter
les
erreurs
rapportées
pour
les
mettre
dans
un
pipeline
de
tâches
de
correction.
La
phase
de
test
est
présentée
après
la
mise
en
production,
mais
elle
s'étend
pendant
tout
le
développement
QUALITE
D’UN
SYSTEME
E-­‐BUSINESS
A
TESTER
La
qualité
d’un
système
e-­‐business
recouvre
de
très
nombreuses
dimensions.
Il
y
en
a
en
tous
cas
au
moins
3
qu’on
peut
clairement
identifier
:
-­‐ les
facteurs
de
qualité
techniques
-­‐ les
facteurs
de
qualité
fonctionnels
-­‐ les
facteurs
de
qualité
ergonomiques
Exemple
de
facteurs
de
qualité
qu’il
faut
évaluer
à
l’issue
d’un
développement

126. Manon
Cuylits
Master
1
2012-­‐2013
126
Développement
de
systèmes
e-­‐business
Technique
Ø conformité
:
respect
des
standards
Ø performance
:
temps
de
réponse
acceptables
à
pleine
charge
Ø sécurité
:
résistance
face
aux
(potentiellement
nombreuses)
attaques
Ø compatibilité
:
fonctionnement
correct
dans
différents
environnements
Ø interopérabilité
:
interaction
correcte
avec
d'autres
systèmes
Au
niveau
technique,
il
faut
par
exemple
vérifier
que
le
système
respecte
les
standards
de
l’internet
è
par
exemple
:
que
les
sites
web
respectent
à
la
lettre
près
les
spécifications
du
HTML.
On
attend
aussi
d’un
système
web,
une
performance
raisonnable,
et
cela
pose
parfois
problème
dans
des
environnements
massivement
multi-­‐utilisateurs,
avec
un
nombre
d’utilisateurs
difficile
à
anticiper
(il
peut
s’agir
d’une
population
d’internautes
très
vaste
à
certains
moments,
par
exemple
lorsqu’une
entreprise
réalise
une
action
promotionnelle
forte,
on
peut
avoir
des
pics
qui
sont
difficiles
à
supporter
par
l’infrastructure
en
place.)
Fonctionnalité
(facteur
de
qualité
lié
à
la
fonctionnalité
Ø réponse
aux
besoins
en
termes
de
contenus
et
de
traitements
Ø validité
des
contenus
(exactitude,
complétude,
etc.)
Ø flexibilité
:
contenus
et
traitements
modifiables
et
extensibles
Un
exemple
de
facteur
de
qualité
lié
à
la
fonctionnalité
c’est
la
réponse
aux
besoins
des
utilisateurs
en
terme
de
fonctionnalité
mais
aussi
(et
ce
n’est
pas
toujours
évident
à
valider)
la
qualité
des
contenus
postés
sur
un
site
web,
notamment
si
plusieurs
acteurs
peuvent
alimenter
le
site
web.
Exemple
:
Wikipédia
avec
son
système
de
validation
et
son
grand
nombre
d’auteurs
potentiels
è
la
validation
de
ces
informations
nécessite
des
procédures
assez
strictes.
Ergonomie
Ø facilité
d'utilisation
Ø clarté
de
la
navigation
Un
bon
site
web
commercial
doit
être
attractif
:
le
concurrent
n’est
jamais
très
loin
dans
la
sphère
de
l’internet.
TESTS
AUTOMATIQUES
Nous
allons
maintenant
voir
quelques
exemples
de
test,
en
commençant
par
des
techniques
de
tests
automatiques.
On
trouve
sur
le
marché,
et
entre
autre
sur
internet,
de
manière
parfois
gratuite,
des
outils
qui
peuvent
valider
certains
aspects
d’une
application
e-­‐business,
au
niveau
par
exemple
de
sa
compatibilité
avec
différents
navigateurs,
différents
environnements
d’exécution.
On
peut
aussi
tester
de
manière
plus
ou
moins
automatique
la
résistance
d’un
site
web
à
des
attaques
classiques
réalisées
par
des
hackers.

127. Manon
Cuylits
Master
1
2012-­‐2013
127
Thierry
Van
den
Berghe
è
Applications
spécialisées
pour
tester
:
la
compatibilité,
la
performance
et
certains
aspects
de
la
sécurité.
Par
exemple
:
logiciels
d'attaques
utilisés
par
les
hackers
Exemple
:
rendu
de
la
page
d'accueil
dans
différents
environnements
è
http://browsershots.org
Ci-­‐dessous
on
peut
voir
un
exemple
d’outil
qui
affiche
le
rendu
d’un
site
dans
toute
une
série
de
plateformes
sélectionnées
par
l’utilisateur.
DELEGATION
DE
TESTS
MANUELS
Cependant,
de
nombreux
aspects
des
tests
d’un
système
e-­‐business
ne
peuvent
pas
être
automatisés
et,
concrètement,
rien
ne
remplace
l’avis
d’un
acteur
humain
qui
teste
un
système
et
qui
essaye
de
s’y
retrouver
et
d’évaluer
la
facilité
d’utilisation,
la
disponibilité
de
l’information,
la
clarté
des
écrans,
l’ergonomie,
etc.
Il
existe
d’ailleurs
des
sociétés
spécialisées
dans
l’audit
de
tests
qu’ils
réalisent
avec
des
pannels
d’utilisateurs
représentatifs
de
la
cible
è
des
tests
de
l’usabilité
des
applications.
è
La
plupart
des
aspects
d'un
système
Web
doivent
être
testés
manuellement è
sociétés
spécialisées
dans
l'audit
de
sites
(Exemple
:
www.usabilis.com
)

128. Manon
Cuylits
Master
1
2012-­‐2013
En
marge
de
la
qualité
intrinsèque
du
système,
et
c’est
une
catégorie
de
test
un
peu
particulière,
il
est
bon
après
quelques
mois
ou
semaines
de
mise
en
production
d’un
système
e-­‐business
d’essayer
d’évaluer
les
retours
de
ce
système
sur
le
business.
Il
existe
de
très
nombreux
outils
et
indicateurs
pour
évaluer
le
succès
d’un
système.
Par
exemple,
la
mesure
la
plus
évidente
est
la
fréquentation
ou
encore
la
popularité,
à
savoir
le
nombre
de
sites
faisant
référence
à
notre
système,
ou
encore,
la
part
de
chiffre
d’affaires
réalisé
par
un
système
de
vente
en
ligne
par
rapport
au
chiffre
d’affaires
global
de
l’entreprise.
128
RETOUR
E-­‐BUSINESS
Développement
de
systèmes
e-­‐business
è
Evaluation
de
l'apport
d'un
système
e-­‐business
pour
l'organisation
Ø au-­‐delà
des
tests
de
la
qualité
intrinsèque
du
système
Exemples
d'indicateurs
:
Ø fréquentation
Ø popularité
:
nombre
de
liens
faisant
référence
à
un
site
Ø nombre
de
transactions
commerciales/périodes

129. Manon
Cuylits
Master
1
2012-­‐2013
Un
outil
très
populaire
pour
surveiller
la
fréquentation
d’un
site
s’appelle
Google
Analytics.
C’est
un
outil
gratuit
qui
nous
donne
des
statistiques
de
fréquentation
selon
toute
une
série
de
critères
:
le
critère
temporel,
mais
aussi
des
critères
géographiques
ou
des
critères
techniques
(par
exemple
:
quelle
proportion
d’accès
au
site
ont
été
réalisées
avec
un
navigateur
comme
Firefox).
129
Ø %
de
clients
Web
par
rapport
au
nombre
total
de
clients
Ø etc.
EXEMPLE
D’INDICATEURS
DE
FREQUENTATION
Thierry
Van
den
Berghe

130. Manon
Cuylits
Master
1
2012-­‐2013
130
8.
EXEMPLE
:
RATIONAL
UNIFIED
PROCESS
Cycle
de
développement
proposé
par
la
société
Rational
(maintenant
IBM)
Cadre
méthodologique
plutôt
qu’un
processus
rigide
Ø flexibilité
en
fonction
du
problème
à
résoudre
Développement
de
systèmes
e-­‐business
Organisation
Ø dans
le
temps
:
phases
et
itérations
Ø du
contenu
:
disciplines
ORGANISATION
DU
RUP
DANS
LE
TEMPS
QUATRE
PHASES
Inception
Elaboration
Construction
Transition

131. Manon
Cuylits
Master
1
2012-­‐2013
131
1. Inception
:
définir
la
portée
du
projet,
réfléchir
sur
l’opportunité.
Thierry
Van
den
Berghe
è
Première
description
du
système,
on
délimite
le
système
et
on
définit
ses
utilisations
pour
essayer
de
faire
une
première
estimation
des
coûts,
des
délais
et
des
risques.
2. Elaboration
:
planifier
le
projet
et
décrire
le
système
è
comprendre
la
demande
des
utilisateurs.
On
modélise
le
système
avec
le
diagramme
d’activité,
l’entité
association,
etc.
è
Définir
le
système
à
construire
è
Préciser
les
coûts
et
les
délais
3. Construction
:
réaliser
le
système
è
quand
on
a
compris
la
demande
des
utilisateurs,
on
peut
commencer
à
y
répondre
;
par
exemple
en
choisissant
les
technologies
et
en
produisant
les
prototypes
successifs.
è
Produire
les
premières
versions
è
Tester
les
prototypes
jusqu’à
maturité
4. Transition
:
livraison
du
système
aux
utilisateurs
(une
fois
que
l’on
dispose
de
la
solution)
è
Assurer
l’autonomie
des
utilisateurs
DISCIPLINES
Business
Modeling
Ø comprendre
la
structure
et
la
dynamique
de
l'organisation
Ø définir
les
besoins
du
système
de
support
à
l'organisation
Requirements
Ø définir
et
maintenir
un
consensus
sur
les
besoins
avec
tous
les
interlocuteurs
Ø faire
comprendre
les
besoins
aux
développeurs
Ø délimiter
le
système
Ø établir
un
premier
découpage
en
itérations
Ø estimer
les
coûts
et
délais
Analysis
Design
Ø concevoir
le
système
à
partir
des
besoins
Ø établir
l'architecture
Ø intégrer
l'environnement
de
développement

132. Manon
Cuylits
Master
1
2012-­‐2013
132
Développement
de
systèmes
e-­‐business
Implementation
Ø organiser
l'implémentation
Ø implémenter
et
tester
Ø intégrer
les
modules
développés
par
des
équipes
différentes
Test
Ø identifier
et
documenter
les
erreurs
Ø valider
le
logiciel
Deployment
Ø s'assurer
que
le
logiciel
est
disponible
pour
les
utilisateurs
Configuration
Change
Management
Ø identifier
et
mesurer
l'impact
des
changements
à
apporter
Project
Management
Ø planifier,
allouer
les
ressources
et
suivre
le
projet
Ø gérer
les
risques
Environment
Ø mettre
à
disposition
des
développeurs
un
cadre
de
travail
(outils,
ligne
de
conduite,
processus,
etc.)
Ø configurer
un
processus
de
développement
adapté
au
problème
RUB
«
BEST
PRACTICES
»
Développement
itératif
Ø chaque
itération
produit
du
logiciel
exécutable
Ø les
premières
itérations
prennent
en
charge
les
développements
les
plus
risqués
Ø les
besoins
sont
actualisés
à
chaque
itération

133. Manon
Cuylits
Master
1
2012-­‐2013
133
Thierry
Van
den
Berghe
Gestion
des
besoins
Ø répertoire
organisé
des
besoins
et
accord
de
toutes
les
parties
Ø priorités
sur
les
besoins
instables
et
primordiaux
Ø gestion
des
changements
des
besoins
Architecture
de
composants
Ø architecture
:
ensemble
d'éléments
inter-­‐reliés
Ø construction
du
logiciel
par
composants
Ø réutilisation
de
composants
Modélisation
visuelle
Ø les
spécifications
sont
exprimées
à
travers
différents
modèles
(graphiques)
complémentaires
Ø formalisme
graphique
expressif
et
rigoureux
Vérification
continue
de
la
qualité
Gestion
du
changement
du
logiciel
Ø historique
des
versions
Ø impact
et
documentation
des
modifications

134. Manon
Cuylits
Master
1
2012-­‐2013
134
9.
MAINTENANCE
ET
PROMOTION
MAINTENANCE
Développement
de
systèmes
e-­‐business
è
Pour
un
système
en
production
(après
le
cycle
de
développement)
Remarque
:
nous
sommes
maintenant
au
delà
du
cycle
de
développement
du
système
e-­‐
business.
On
suppose
que
le
système
est
rentré
en
production
è
comment
faire
pour
le
maintenir
à
jour
et
le
promouvoir
dans
le
monde
très
concurrentiel
qu’est
celui
de
l’e-­‐
business
?
Objectifs
:
Ø faire
évoluer
le
système
pour
augmenter
sa
qualité
et
l’adapter
à
l’évolution
des
besoins
Ø dynamiser
le
contenu
Améliorer
la
qualité
du
système
:
c’est
important
car
développer
du
logiciel
exempt
d’erreur
est
quasiment
chose
impossible,
on
peut
détecter
des
erreurs
parfois
après
des
mois
ou
des
années
de
mise
en
production.
Et
surtout,
dans
un
environnement
d’affaires
très
changeant,
les
attentes
des
utilisateurs,
les
modes,
les
besoins
des
consommateurs
évoluent
très
vite,
et
donc
les
systèmes
e-­‐business
qui
automatisent
les
activités
humaines
doivent
suivre
inévitablement
cette
évolution.
Plus
particulièrement
pour
les
systèmes
commerciaux,
il
faut
veiller
à
dynamiser
le
contenu
pour
que
le
système
reste
attractif
par
la
nouveauté
et
attire
des
clients
ou
des
internautes
non-­‐clients
à
revenir.
Exemples
de
tâches
:
Ø maintenance
technique
du
système
:
Un
travail
technique
d’amélioration
du
code.
On
peut
d’ailleurs
distinguer
la
maintenance
corrective
de
la
maintenance
évolutive.
La
maintenance
corrective
consiste
simplement
à
corriger
les
erreurs
qu’on
aurait
détectées,
tandis
que
la
maintenance
évolutive
vise
à
adapter
le
système
à
de
nouvelles
demandes,
à
de
nouveaux
besoins.
Ø Finalement,
la
tâche
de
mise
à
jour
du
contenu
vise
à
moderniser,
faire
évoluer
en
permanence
l’offre
d’information
d’un
système
e-­‐business.
è
Exemple
:
news
sur
la
page
d'accueil,
présenter
les
nouveaux
articles

135. Manon
Cuylits
Master
1
2012-­‐2013
Ici
nous
allons
parler
de
la
promotion
d’un
site
web
à
vocation
commerciale,
comme
un
site
de
vente
en
ligne
par
exemple.
Lorsqu’on
veut
faire
la
promotion
d’un
tel
système,
on
vise
d’abord
à
maximiser
la
fréquentation
du
site
(objectif).
Cela
passe
par
2
choses
:
Ø assurer
la
réputation
et
la
visibilité
du
site.
Ø fidéliser
les
visiteurs
pour
essayer
de
transformer
en
les
clients
potentiels
en
clients
135
PROMOTION
LA
PROMOTION
D’UN
SITE
WEB
COMMERCIAL
réels,
en
acheteurs
réguliers.
Thierry
Van
den
Berghe
Réputation
sur
internet:
Ø construction
de
la
puissance
de
la
marque
Ø crédibilité
sur
Internet
Ø non
traité
dans
la
suite
La
réputation
sur
internet
est
quelque
chose
qui
se
construit
avec
toute
une
série
de
techniques
(que
nous
n’allons
pas
détailler),
mais
la
puissance
de
la
marque,
la
réputation
de
l’entreprise
contribue
à
la
réputation
sur
internet
notamment.
Visibilité
d’un
site
:
Ø Comment
placer
le
site
à
la
portée
des
internautes,
pour
qu’il
soit
accessible
?
Ø Comment
faciliter
la
découverte
du
site
et
son
accès
?
Exemples
de
tâches
pour
augmenter
la
visibilité
Ø la
présence
dans
le
monde
physique
(cartes
de
visite,
publicité
dans
les
médias
classiques)
Ø le
référencement
dans
des
annuaires,
moteurs
de
recherche
et
comparateurs
Ø l'E-­‐Mailing
Ø la
publicité
en
ligne
Ø la
mise
en
place
de
partenariats
Ø les
relations
publiques
en
ligne
Comment
faire
pour
promouvoir
un
nouveau
site
web
de
vente
en
ligne
par
exemple
?
Il
y
a
toute
une
série
de
choses
à
faire
dans
le
monde
physique
(en
dehors
de
l’internet).
Par
exemple
:
démontrer
son
existence
dans
les
médias
traditionnels,
que
ce
soit
dans
la
presse
écrite
ou
dans
les
publicités
qui
passent
sur
la
radio
ou
à
la
télévision,
comme
cela
se
fait
très
fréquemment
(on
entend
souvent
des
URL
qui
sont
mentionnés),
ainsi
que
toute
une
série
d’autres
actions
possibles
dans
la
sphère
des
médias
électroniques
(c’est
ce
qui
va
être
détaillé
dans
la
suite).

136. Manon
Cuylits
Master
1
2012-­‐2013
Le
point
d’accès
privilégié
pour
accéder
à
un
site,
c’est
le
moteur
de
recherche.
Il
est
donc
essentiel
qu’un
nouveau
site
soit
connu
et
indexé
par
ces
moteurs.
Au
minimum,
au
niveau
technique,
on
peut
spécifier
dans
un
site,
des
métadonnées
ou
des
informations
spécifiquement
destinées
aux
moteurs
de
recherche.
Cela
leur
permettra
d’établir
des
connexions
entre
des
mots
recherchés
par
un
internaute
et
le
site
qu’on
souhaite
faire
connaître.
Certains
sites
de
moteur
de
recherche
offrent
des
services
complémentaires
moyennant
rémunération.
Par
exemple,
on
peut
agir
sur
l’ordre
de
priorité
de
l’affichage
du
site
ou
encore,
rémunérer
pour
un
affichage
publicitaire
au
sein
d’un
moteur
de
recherche.
136
REFERENCEMENT
DANS
LES
MOTEURS
DE
RECHERCHE
EXEMPLE
DE
REFERENCEMENT
–
MOTEURS
Développement
de
systèmes
e-­‐business

137. Manon
Cuylits
Master
1
2012-­‐2013
Dans
l’exemple
du
moteur
de
Google,
il
est
possible,
gratuitement,
de
spécifier
à
Google
un
nouvel
URL
d’un
site
qui
vient
d’être
mis
en
ligne
pour
que
Google
l’indexe
et
le
répertorie
dans
les
résultats
de
recherche.
Avec
Google
AdWords,
on
peut
rémunérer
Google
pour
être
prioritaire
dans
l’affichage
d’un
résultat
de
recherche
correspondant
à
un
terme
qu’on
juge
pertinent
par
rapport
à
notre
activité
ou
à
notre
site.
137
EXEMPLE
D’ACHAT
DE
MOTS-­‐CLES
DANS
UN
MOTEUR
Thierry
Van
den
Berghe

138. Manon
Cuylits
Master
1
2012-­‐2013
Une
autre
technique
très
classique
pour
atteindre
les
internautes
et
donc
faire
connaître
son
site
ou
son
activité
est
l’e-­‐mailing.
Il
y
a
deux
conditions
pour
que
cela
fonctionne
:
-­‐ les
destinataires
de
l’e-­‐mailing
doivent
avoir
à
un
moment
donné
marqué
leur
Il
existe
des
sites
spécialisés
dans
l’achat
ou
la
location
d’adresses
e-­‐mail
qui
peuvent
nous
aider
à
cibler
un
e-­‐mail
correctement.
è
Envoi
à
des
adresses
e-­‐mail
pour
lesquelles
les
propriétaires
ont
marqué
leur
accord
138
E-­‐MAILING
DIRECT
accord
pour
recevoir
des
promotions
-­‐ il
faut
que
les
destinataires
de
l’e-­‐mailing
soient
dans
la
cible
de
notre
activité
concernant
une
utilisation
promotionnelle
(opt-­‐in)
Ciblage
des
internautes
Ø Achat/location
d’adresses
sélectionnées
à
des
sociétés
spécialisées
Ø fichiers
internes
Développement
de
systèmes
e-­‐business
Avantages
Ø ciblage
Ø retour
rapide
Ø traçabilité
(réception
≈
90%,
ouverture
≈
30%,
clic
≈
8%,
etc.)
Un
e-­‐mailing
c’est
relativement
facile
à
faire
techniquement,
le
retour
est
rapide
et
on
peut
assez
facilement
tracer
la
réaction
des
destinataires
suite
à
l’envoie
d’un
mailing
de
promotion.
Il
existe
des
logiciels
spécialisés
de
Customer
Relationship
Management
pour
tracer
les
réactions
de
ces
internautes
suite
à
l’envoi
de
différents
e-­‐mails
è
exemple
:
SugarCRM

139. Manon
Cuylits
Master
1
2012-­‐2013
Une
autre
manière
de
se
faire
connaître
dans
le
monde
de
l’internet
est
de
louer
un
espace
publicitaire
sur
un
site
susceptible
d’intéresser
des
futurs
clients
ou
les
internautes
concernés
par
notre
activité.
139
Voici
un
exemple
de
société
spécialisée
dans
l’e-­‐mailing.
PUBLICITE
–
BANNERING
Thierry
Van
den
Berghe
è
Location
d'un
espace
publicitaire
sur
un
site
pour
y
afficher
un
banner.
On
va
nous
demander
de
rémunérer
le
site
d’appel
qui
va
mentionner
une
bannière
publicitaire
faisant
référence
à
notre
site.
è
Plusieurs
techniques
sont
possibles
pour
calculer
la
rémunération
de
cet
espace
publicitaire
:
Ø exposition
(on
peut
faire
un
calcul
à
partir
du
nombre
d’affichages
de
la
bannière)
Ø interaction
(calcul
à
partir
du
nombre
de
clics
sur
la
bannière,
moins
de
1%
de
l’exposition)
Ø performance
(essayer
de
calculer
le
nombre
de
ventes
déclenchées
par
des
internautes
provenant
du
site
d’appel)
Il
faut
veiller
à
ce
que
ces
sites
d’appel
contenant
les
bannières
soient
consistants
et
cohérents
avec
notre
cible.
Par
exemple,
on
voit
mal
une
école
de
commerce
afficher
des

140. Manon
Cuylits
Master
1
2012-­‐2013
Indispensable
affinité
entre
le
Exemple
:
proposer
une
assurance
funéraire
à
des
étudiants
Aujourd’hui,
tout
internaute
sait
que
les
techniques
d’annonce
publicitaire
sont
très
sophistiquées
sur
internet
notamment
à
partir
de
techniques
de
datamining,
certains
sites
offrent
des
affichages
publicitaires
personnalisés
qui
intègrent
par
exemple
la
navigation
antérieure
de
l’internaute.
Si
on
va
par
exemple
rechercher
des
articles
de
telle
nature
dans
un
catalogue,
plus
tard,
en
un
site
de
météo
par
exemple,
des
bannières
publicitaires
concernant
des
articles
similaires
nous
seront
présentées.
140
bannières
publicitaires
pour
des
entreprises
funéraires.
è
support
et
la
cible
de
l’annonceur
è
è
Développement
de
systèmes
e-­‐business
è
Techniques
de
bannering
dynamique
è
banners
sélectionnées
en
fonction
du
profil
et
ou
de
l’historique
de navigation
Aujourd’hui,
des
régies
publicitaires
qui
gèrent
des
espaces
de
promotion
se
sont
développées
uniquement
pour
l’internet.
Exemple
:
http://www.beweb.be
è
propose
des
espaces
publicitaires
dans
toute
une
série
de
médias.
MISE
EN
PLACE
DE
PARTENARIATS
Comme
dans
le
monde
réel,
certaines
entreprises
vont
développer
des
partenariats
mais
dans
le
monde
virtuel
ici
et
ces
partenariats
lient
souvent
des
entreprises
avec
des
affinités
stratégiques
ou
des
affinités
en
terme
de
produit.
è
Partenariats
entre
alliés
stratégiques
,
complémentaires
et
de
taille
comparable.
Nature
du
partenariat
:
Ø échange
d’espaces
de
promotion
Ø échange
de
bases
de
données
de
clients
Ø échange
de
ressources
logistiques

141. Manon
Cuylits
Master
1
2012-­‐2013
La
nature
de
ce
partenariat
peut
porter
sur
des
publicités
ou
des
promotions
croisées,
mais
aussi
à
des
échanges
de
base
de
données
de
contacts
pour
des
mailings
croisés,
voire,
des
mises
en
commun
de
ressources
logistiques.
Ci-­‐dessous,
un
exemple
de
partenariat
croisé
entre
Intel
et
Toshiba
:
on
voit
clairement
que
les
sites
des
2
partenaires
renvoient
respectivement
à
la
marque
associée.
Il
est
important
de
mentionner
l’importance
croissante
que
prennent
les
relations
publiques
en
ligne
parce
qu’aujourd’hui,
l’internet
a
pris
un
espace
très
important
(et
de
plus
en
plus
important)
dans
la
communication
entre
les
entreprises
et
les
consommateurs,
et
donc,
certaines
entreprises/marques
sont
très
vigilantes
concernant
leur
image
qui
est
véhiculée
dans
différents
médias
de
l’internet.
Certaines
ressources
sont
donc
consacrées
à
surveiller
les
messages
négatifs
qui
circulent
sur
les
réseaux
sociaux
par
exemple,
ou
encore,
être
justement
présent
sur
des
réseaux
comme
Facebook
ou
Twitter.
Ø ensemble
des
moyens
déployés
pour
faire
parler
de
l’entreprise
dans
les
(e-­‐)médias
Ø recherche
de
relais
écoutés
par
l’opinion
Ø présence
sur
les
réseau
sociaux,
les
blogs
personnels,
etc.
Ø contrôler
les
messages
négatifs
Ø corrélation
avec
le
réputation
141
RELATIONS
PUBLIQUES
EN
LIGNE
Thierry
Van
den
Berghe

142. Manon
Cuylits
Master
1
2012-­‐2013
Au
départ,
l’internet
a
été
conçu
pour
échanger
des
données
scientifiques
et
les
concepteurs
de
l’époque
n’ont
pas
vraiment
songé
ni
à
l’énorme
quantité
d’information
qu’on
aurait
pu
véhiculer
via
ce
média,
ni
à
toutes
les
applications
grand
public
qu’on
aurait
pu
faire
de
cet
internet.
Donc,
ils
n’ont
pas
à
l’époque,
intégré
dés
le
départ
une
dimension
sécuritaire
dans
cette
technologie.
En
outre,
aujourd’hui,
malgré
les
enjeux
et
l’utilisation
massive
d’internet,
on
se
retrouve
sans
système
de
régulation
du
moins
à
l’échelle
mondiale.
142
10.
SECURITE
ETAT
ET
ENJEUX
L’ETAT
DES
SYSTEMES
Développement
de
systèmes
e-­‐business
è
Avec
internet
on
fait
de
tout,
sans
beaucoup
de
contrôle
et
avec
des
technologies
qui
ne
sont
pas
ultra-­‐
sécurisées.
è
Internet
=
Ø espace
publique
planétaire
Ø sans
régulation
à
l’échelle
mondiale
Ø non
conçu
à
la
base
pour
être
sécurisé
Connexion
de
systèmes
d’entreprise
Ø autrefois
isolés
de
l’extérieur
Ø contenant
le
patrimoine
de
données
de
l’entreprise
Mise
en
ligne
de
services
sensibles
Ø amenant
les
internautes
à
alimenter
l’Internet
avec
des
données
personnelles
Ø Exemple
:
paiement
en
ligne
Ces
problèmes
deviennent
d’autant
plus
aigus
que
aujourd’hui,
la
plupart
des
systèmes
d’information
des
entreprises
qui
étaient
auparavant
totalement
isolés
sur
monde
extérieur
sont
aujourd’hui
en
lien/connexion
direct
avec
le
reste
du
monde,
avec
l’internet,
puisque
aujourd’hui,
les
systèmes
Front
Office
par
exemple
permettent
à
des
internautes
d’enregistrer
des
données
directement
dans
les
systèmes
d’information
des
entreprises
de
vente
en
ligne,
par
exemple.
Techniquement,
on
a
donc
créé
des
canaux/chemins
de
communication
qui
peuvent
être
potentiellement
piratés
pour
accéder
à
des
données
internes
de
l’entreprise
qui
devraient
rester
confidentielles.
Une
dernière
difficulté
qui
se
combine
aux
précédentes
est
que
certaines
applications
de
l’internet
sont
utilisées
pour
encoder,
modifier,
visualiser
des
données
personnelles
et
sensibles.
Exemple
:
les

143. Manon
Cuylits
Master
1
2012-­‐2013
applications
de
webbanking
qui
permettent
aux
utilisateurs
d’enregistrer
des
paiements
mais
permettent
aussi
à
d’éventuels
pirates
de
collecter
de
manière
détournée
et
sophistiquée,
certaines
informations
confidentielles.
Nombreux
internautes
utilisent
massivement
les
applications
de
l’internet
pour
alimenter
certains
systèmes
en
données
qui
peuvent
être
personnelles,
ou
en
tous
cas
devraient
rester
confidentielles,
mais
certains
systèmes
sont
capables
de
produire
automatiquement
des
données
qu’on
pourrait
considérer
comme
personnelles
et
qui
doivent
être
protégées.
Exemple
:
Smartphones
équipés
de
système
GPS
et
de
connexion
à
l’internet,
on
pourrait
concevoir
que
certaines
applications
tracent
littéralement
les
déplacements
d’un
internaute
et
exploite
ces
informations
à
des
fins
publicitaires
par
exemple.
143
DEPENDANCE
ACCRUE
DES
INTERNAUTES
Thierry
Van
den
Berghe

144. Manon
Cuylits
Master
1
2012-­‐2013
Les
exemples
de
piratage
ne
manquent
pas.
On
retiendra
que
certains
acteurs
de
l’industrie
informatique
même,
peuvent
parfaitement
être
victimes
d’attaques
de
la
part
de
pirates
sans
scrupules.
Exemple
ci-­‐dessus
:
site
de
Microsoft
qui
a
été
détourné
par
des
pirates
144
EXEMPLES
DE
MENACES
Exemple
ci-­‐dessus
:
site
de
la
police
fédérale
qui
a
été
hacké
par
un
internaute
de
17
Développement
de
systèmes
e-­‐business
ans.
Cela
montre
qu’avec
un
peu
de
temps,
un
minimum
de
compétences
et
l’ensemble
des
outils
et
trucs
mis
à
disposition
des
pirates
par
l’internet
lui
même,
cela
devient
relativement
facile
de
pirater
des
applications,
des
systèmes
qui
n’ont
pas
été
correctement
protégés.

145. Manon
Cuylits
Master
1
2012-­‐2013
Dans
les
exemples
précédents
on
voyait
que
certains
sites
pouvaient
avoir
été
piratés
en
modifiant
leur
page
d’accueil,
en
éliminant
le
contenu
officiel
du
site
et
en
le
remplaçant
par
un
contenu
pirate.
Une
autre
forme
de
fraude
par
internet
consiste
à
recueillir
de
manière
totalement
illégale
des
informations
confidentielles
comme
des
numéros
de
carte
de
crédit.
C’est
inquiétant
surtout
étant
donné
qu’actuellement
on
peut
acheter
des
articles
sur
internet
en
fournissant
quelques
coordonnées
un
numéro
de
carte
de
crédit
et
un
numéro
de
vérification
par
exemple,
mais
on
peut
ne
pas
disposer
physiquement
de
la
carte.
Une
autre
forme
d’attaque
consiste
à
mettre
un
site
hors
service
en
le
surchargeant.
L’idée
est
de
contrôler
à
distance
et
à
leur
insu,
des
machines
appartenant
à
des
utilisateurs
sur
lesquelles
un
pirate
a
installé
un
programme
qu’il
peut
contrôler
à
distance
et
au
moment
venu,
le
pirate
peut
lancer
l’instruction
auprès
d’un
grand
nombre
de
machines
affectées
pour
que
celles
ci
accèdent
toutes
en
même
temps
à
un
même
site.
Les
serveurs
hébergeant
ce
site
adressé
massivement
deviennent
alors
l’objet
d’un
très
grand
nombre
de
requêtes
145
è
Thierry
Van
den
Berghe

146. Manon
Cuylits
Master
1
2012-­‐2013
auxquelles,
techniquement,
il
ne
peut
répondre.
Par
conséquent,
le
site
sera
indisponible
pendant
une
certaine
période.
Mais
aussi…
On
voit
donc
le
grand
nombre
d’informations
stockées
par
les
sites
internet
à
propos
des
activités
des
utilisateurs.
Sur
ICHECCAMPUS
par
exemple,
il
est
possible
de
tracer
de
manière
très
précise
l’activité
des
étudiants
sur
la
plateforme.
146
Voici
quelques
exemples
de
clauses
d’utilisation
de
Facebook
à
lire.
Et
encore…
Développement
de
systèmes
e-­‐business

147. Manon
Cuylits
Master
1
2012-­‐2013
La
plupart
des
attaques
ne
sont
pas
rapportée
=
seulement
20%
des
attaques
déclarées
(une
faible
proportion)
Pourquoi?
Une
entreprise
qui
voit
son
système
d’information
attaqué
avec
succès
ne
souhaite
pas
spécialement
en
faire
la
publicité
car
cela
pourrait
nuire
à
sa
réputation.
Symantec
a
consulté
3
300
entreprises
de
trente-­‐six
pays.
Intrusion
dans
les
méandres
informatiques
de
l'entreprise,
vols
de
données
confidentielles,
usurpation
d'identités
d'employés,
piratage
et
paralysie
des
systèmes
informatiques,
les
opérations
des
pirates
provoquent
des
dommages
qui
peuvent
coûter
cher.
Ainsi,
au
niveau
international,
147
AMPLEUR
DU
PHENOMENE
Ø mise
en
avant
de
faiblesses,
image
de
marque
Ø attaque
non
détectée
Ø manque
de
maturité
en
termes
de
conscience
et
de
solutions
Thierry
Van
den
Berghe
Exemple
:
une
banque
dont
les
comptes
auraient
été
piratés
perdrait
la
confiance
de
ses
clients.
ENJEUX
DE
LA
SECURITE
Ci-­‐après,
quelques
chiffres
concernant
les
impacts
potentiels
d’attaques
informatiques
graves.
Dans
certains
cas
c’est
l’activité
entière
de
l’entreprise
qui
peut
être
mise
en
péril
suite
à
une
attaque
informatique.
Ø 43%
des
organisations
doivent
fermer
suite
à
une
perte
de
données
majeure
Ø indisponibilité
de
plus
de
10
jours
=
fin
de
l’entreprise
Ø dans
45%
des
cas
:
perte
des
données
due
à
une
erreur
humaine
«
20
%
des
entreprises
évaluent
les
pertes
annuelles
causées
par
ces
attaques
à
au
moins
140
000
euros,
imputables
notamment
à
un
ralentissement
de
la
productivité
et
à
la
perte
de
données
sensibles.
»
DIMENSIONS
CLES
DE
LA
SECURITE
Voici
les
principales
dimensions
de
la
sécurité
des
systèmes
d’information
qui
sont
mises
en
péril
par
les
pirates.
1. La
confidentialité
è
accès
autorisé
à
l’information
Un
pirate
pourrait
accéder
de
manière
illégale
à
des
informations
qu’il
n’est
pas
censé
visualiser.

148. Manon
Cuylits
Master
1
2012-­‐2013
148
Développement
de
systèmes
e-­‐business
2. L’intégrité
è
caractère
exact
de
l’information
L’intégrité
touche
au
caractère
exact
de
l’information.
Un
pirate
pourrait
casser
cette
intégrité
en
introduisant
dans
un
système
des
données
erronées
par
exemple.
3. La
disponibilité
è
information
accessible
et
utilisable
La
disponibilité
de
l’information
qui
peut
aussi
être
mise
en
péril
par
exemple
par
des
attaques
massives
de
PC
infectés
qui
mettent
un
site
hors
service
pour
une
période
déterminée
4. L’authenticité
è
la
garantie
de
l’identité
d’une
entité
Comment
garantir
qu’une
information
disponible
dans
un
système
d’information
est
bien
authentique,
n’a
pas
été
falsifiée
par
un
pirate.
SOLUTIONS
Ici
nous
allons
voir
quelques
solutions
possibles
pour
gérer
la
sécurité
des
systèmes
d’information.
Un
préalable
à
la
mise
en
place
de
mesures
sécuritaires
pour
un
système
d’information
est
de
se
convaincre
des
problèmes
et
menaces
potentielles
et
surtout
des
enjeux
et
des
impacts
que
des
risques
de
sécurité
peuvent
avoir
sur
le
système
d’information
et
sur
l’activité
de
l’entreprise.
è
prendre
conscience
des
problèmes
et
des
enjeux.
Après
cette
prise
de
conscience,
on
peut
penser
à
déployer
une
gestion
proactive
de
la
sécurité.
Cela
implique
au
minimum
3
choses.
-­‐ il
faut
tout
d’abord
songer
à
une
gestion
intégrée
de
la
sécurité
parce
que
la
sécurité
d’un
système
d’information
correspond
au
niveau
de
sécurité
du
maillon
le
plus
faible.
Tous
les
éléments
du
système
et
de
l’infrastructure
doivent
être
protégés
contre
des
attaques
potentielles,
que
ce
soit
les
bâtiments,
le
logiciel
ou
le
matériel.
è
accès
aux
bâtiments,
gestion
des
mots
de
passe,
sécurisation
des
infrastructures,
sécurisation
du
logiciel,
etc.
-­‐ deuxièmement,
la
gestion
de
la
sécurité
doit
être
intense,
en
profondeur,
et
donc
ce
que
les
spécialistes
suggèrent,
c’est
de
multiplier
les
obstacles
pour
qu’en
cas
de
rupture
d’une
digue
de
sécurité,
un
autre
rempart
se
dresse
devant
les
hackers.
-­‐ Troisièmement,
la
gestion
de
la
sécurité
doit
être
permanente
et
dynamique
parce
que
les
types
et
techniques
d’attaque
évoluent
sans
cesse,
il
faut
donc
rester
vigilant
face
à
l’imagination
débordante
des
pirates.

149. Manon
Cuylits
Master
1
2012-­‐2013
Pour
sécuriser
un
système
d’information
on
va
d’abord
essayer
de
renforcer
son
niveau
de
sécurité
(prévenir)
en
évitant
les
points
faibles,
les
vulnérabilités
du
système.
Une
fois
qu’un
système
est
mis
en
exploitation,
on
va
mettre
en
place
une
surveillance,
un
monitoring
pour
149
Thierry
Van
den
Berghe
détecter
les
menaces
et
les
incidents
de
manière
à
pouvoir
les
contrer.
Si
une
menace
a
un
impact
négatif
sur
le
système,
il
faut
gérer
ces
attaques
et
leurs
effets
en
corrigeant
les
effets
de
cette
attaque
selon,
si
possible,
un
plan
d’action
déjà
rédigé,
déjà
pensé
au
préalable.
APPROCHE
MULTIDIMENSIONNELLE
DE
LA
SECURITE
La
sécurité
ou
la
sécurisation
d’un
système
d’information
a
plusieurs
dimensions
:
-­‐ Dimension
technique
:
il
s’agit
au
niveau
technique
de
protéger
des
systèmes
par
des
mesures
techniques
de
sécurité.
-­‐ Dimension
économique
:
ces
technologies/techniques
sécuritaires
ont
un
cout,
par
exemple,
si
je
souhaite
assurer
la
disponibilité
de
mon
système
d’information,
on
peut
par
exemple
développer
un
système
totalement
redondant
de
manière
à
ce
que
si
un
système
tombe
en
panne
on
puisse
en
temps
réel
travailler
sur
le
système
redondant
;
mais
cela
a
un
cout,
il
faut
en
permanence
essayer
de
trouver
le
bon
équilibre
entre
d’une
part
les
couts
de
déploiement
des
mesures
de
sécurité,
et
d’autre
part,
l’impact
en
terme
financier
des
risques
pouvant
survenir.
-­‐ Dimension
humaine
:
même
si
un
système
est
techniquement
bien
sécurisé,
il
faut
que
les
utilisateurs
soient
conscients
et
responsables
des
problèmes
de
sécurité.
Par
exemple
:
cela
ne
sert
à
rien
de
sécuriser
à
outrance
un
système
si
des
utilisateurs
peu
fiables
décident
de
leur
propre
chef
de
communiquer
des
informations
à
l’extérieur
via
d’autres
moyens
que
le
système
en
place.

150. Manon
Cuylits
Master
1
2012-­‐2013
-­‐ Dimension
managériale
:
finalement,
déployer
un
projet
de
sécurité
doit
être
géré,
il
y
a
donc
une
dimension
managériale
dans
la
sécurité
parce
qu’un
projet
de
sécurité
implique
de
nombreux
acteurs,
des
budgets,
des
délais,
etc.
bref,
tout
ce
qui
fait
un
projet.
Pour
gérer
la
sécurité
d’un
système
d’information,
on
part
souvent
d’une
étude
de
risque
qui
répertorie
les
menaces
sur,
par
exemple,
la
disponibilité
ou
la
fiabilité
de
l’information.
A
partir
de
cette
étude
de
risque
on
tente
de
mettre
en
place
toute
une
série
de
contre-­‐
mesures
pour
essayer
soit
d’amoindrir
la
probabilité
de
survenance
des
risques
ou
encore,
une
série
de
mesures
pour
réagir
en
cas
de
survenance
de
ces
risques.
Toutes
ces
mesures
ou
contre-­‐mesures
sont
répertoriées
dans
ce
qu’on
appelle
un
plan
de
sécurité.
Heureusement,
pour
guider
les
informaticiens
et
les
gestionnaires
dans
la
rédaction
d’un
tel
plan
de
sécurité,
il
existe
plusieurs
approches
disponibles
dans
la
littérature.
150
SECURITE
DE
LA
BD
=
PROCEDURES
+
TECHNIQUES
METHODE
DE
GESTION
DE
LA
SECURITE
Démarche
générique
pour
déployer
un
plan
de
sécurité
à
partir
d'une
études
des
risques
Développement
de
systèmes
e-­‐business

151. Manon
Cuylits
Master
1
2012-­‐2013
151
Thierry
Van
den
Berghe
Exemples
:
-­‐ CRAMM
:
CCTA
Risk
Analysis
and
Management
Method
développée
par
la
Central
Computer
and
Telecommunications
Agency
(CCTA)
-­‐
UK
government
agency
-­‐ OCTAVE
:
Operationally
Critical
Threat,
Asset,
and
Vulnerability
Evaluation
développée
par
la
Computer
Emergency
Response
Team
(CERT)
localisée
à
la
Canergie
Mellon
University
-­‐ EBIOS
:
Expression
des
Besoins
et
Identification
des
Objectifs
de
Sécurité
développée
par
l'Agence
nationale
française
de
la
sécurité
des
systèmes
d'information
-­‐
http://www.ssi.gouv.fr/fr/bonnes-­‐pratiques/outils-­‐
methodologiques/ebios-­‐
expression-­‐des-­‐besoins-­‐et-­‐identification-­‐des-­‐objectifs-­‐de-­‐
securite.html
EBIOS
(EXEMPLE)
EBIOS
est
une
des
méthodes
dont
on
a
parlé
ci-­‐dessus.
Ce
n’est
pas
la
méthode
la
plus
légère
mais
il
est
intéressant
d’y
jeter
un
coup
d’oeil.
STANDARDS
En
plus
de
ces
méthodes
de
gestion
de
la
sécurité,
il
existe
toute
une
série
de
réglementations
et
de
normes
qui
peuvent
soit
contraindre
les
responsables
de
sécurité
à
atteindre
un
degré
de
sécurité
fixé
par
ces
réglementations
ou
normes,
mais
l’avantage
de
ces
outils
(réglementations
ou
normes)
est
aussi
de
suggérer
un
ensemble
de
contre-­‐
mesures
typiques
face
à
des
problèmes
de
sécurité
récurrents.
Notons
que
certaines
réglementations
sont
orientées
vers
des
secteurs
d’activité,
comme
par
exemple
Bâle
II,
orienté
vers
la
finance.

152. Manon
Cuylits
Master
1
2012-­‐2013
152
Développement
de
systèmes
e-­‐business
è
Règlementations
-­‐ prescrits
légaux
-­‐ Sarbanes-­‐Oxley,
Bâle
II,
HIPAA,
directives
européennes
è
Normes
-­‐ développées
par
un
organisme
national
ou
international
indépendant
des
industriels
-­‐ Exemple
:
ISO
27002
:
code
de
bonnes
pratiques
pour
la
gestion
de
la
sécurité
de
l’information
EXEMPLE
DE
PROCEDURE
DE
SECURITE
Pour
clôturer,
nous
allons
voir
un
exemple
concret
de
contre-­‐mesure
de
sécurité.
CHOIX
DE
MOTS
DE
PASSE
FORTS
Exemple
de
menace
:
un
attaquant
découvre
un
nom
d’utilisateur
et
son
mot
de
passe
puis
se
connecte
illégalement
à
un
système
d’information.
Par
ce
biais,
l’attaquant
peut
avoir
accès
à
des
informations
qui
ne
le
concernent
pas
et
qu’il
n’aurait
pas
le
droit
de
voir
en
temps
normal,
mais
il
peut
aussi
réaliser
sous
notre
nom
des
actions
inquiétantes,
comme
par
exemple
:
commander
et
se
faire
livrer
des
articles
que
l’on
devrait
payer.
Cette
menace
est
tout
à
fait
réelle,
par
exemple
avec
certains
systèmes
comme
ceux
de
gestion
de
BDD,
qui
sont
installés
par
défaut
avec
des
mots
de
passe
standards,
connus
de
tous
ceux
qui
ont
déjà
installé
ce
système
de
gestion
de
base
de
données.
Autre
exemple
:
permutation
des
lettres
du
nom
d'utilisateur
Autre
manifestation
de
cette
menace
:
des
outils
de
soumission
automatique
de
mots
de
passe
naïfs
:
aujourd’hui
sur
internet
il
est
très
facile
de
trouver
des
logiciels
qui
tentent
de
s’identifier
auprès
de
systèmes,
de
sites
web
à
partir
de
listes
standards
de
mots
de
passe,
et
ce
n’est
pas
toujours
très
compliqué
de
connaître
les
noms
d’utilisateur
(soit
l’e-­‐mail,
soit
un
numéro
séquentiel,
…)
et
donc
la
probabilité
pour
un
attaquant
de
rentrer
dans
un
système
est
malheureusement
loin
d’être
nulle.

153. Manon
Cuylits
Master
1
2012-­‐2013
Souvent,
par
facilité
ou
par
naïveté,
les
utilisateurs
consacrent
peu
d’efforts
à
choisir
des
mots
de
passe
qui
soient
«
forts
».
Par
exemple,
dans
la
liste
de
droite,
on
retrouve
une
liste
de
toute
une
série
de
mots
de
passe
que
les
utilisateurs
choisissent
régulièrement,
qui
sont
connus,
et
qui
peuvent
être
soumis
par
des
outils
de
cracking
automatique.
Autre
exemple
qui
vient
d’une
plateforme
e-­‐learning
bien
connue
:
motdepasse,
bidule,
etc.
qui
sont
des
exemples
tout
à
fait
naïfs
ce
n’est
pas
très
compliqué
de
craquer
des
Malheureusement,
les
utilisateurs
ne
sont
pas
toujours
conscients
des
risques
encourus
lorsqu’ils
laissent
trainer
sur
leur
bureau
ou
dans
un
tiroir
une
liste
manuscrite
de
mots
de
passe.
Imaginons
par
exemple
un
personnel
de
nettoyage
mal
intentionné,
qui
en
quelques
secondes
pourrait
trouver
des
informations
d’identification
tout
à
fait
confidentielles.
Voici
pour
terminer,
un
exemple
de
quelques
contre-­‐mesures
qui
peuvent
aider
à
parer
la
menace
d’identification
illégale
153
EXEMPLE
DE
MOTS
DE
PASSE
NAIFS
è
systèmes
avec
un
niveau
d’identification
et
d’authentification
aussi
faible.
EXEMPLE
DE
BETISE
Thierry
Van
den
Berghe

154. Manon
Cuylits
Master
1
2012-­‐2013
1. Première
contre-­‐mesure
:
imposer
des
mots
de
passe
forts
(devient
très
courant
154
Développement
de
systèmes
e-­‐business
actuellement)
è
mots
de
passe
forts
qui
respectent
par
exemple
un
certain
nombre
de
règles
en
terme
de
mélange
de
chiffres/caractères,
en
terme
de
taille,
etc.
(èvariation
dans
la
casse;
mélange
de
chiffres,
de
lettres
et
de
caractères
spéciaux
autorisés;
6
positions
au
minimum,
etc.).
On
veillera
aussi
à
modifier
systématiquement
les
mots
de
passe
installés
par
défaut
par
différents
logiciels.
2. Deuxième
contre-­‐mesure
:
vérifier
automatiquement
la
solidité
des
mots
de
passe
choisis
par
les
utilisateurs
;
par
exemple,
en
exécutant
les
outils
bien
connus
qu’utilisent
les
pirates
pour
essayer
de
s’introduire
illégalement
dans
des
systèmes.
è
Exécution
des
outils
des
attaquants/
exécution
d'outils
dédiés
à
l'audit
des
mots
de
passe
3. Troisième
contre-­‐mesure
:
communiquer
et
responsabiliser
l'utilisateur
quant
aux
impacts
de
la
sécurité
des
systèmes
d’information,
et
lui
donner
à
travers
un
plan
de
sécurité
des
lignes
de
conduite
pour
améliorer
la
sécurité
du
système
è
responsabiliser
l’utilisateur
quant
à
la
confidentialité
de
ses
données
de
connexion.

155. Manon
Cuylits
Master
1
2012-­‐2013
PLAN
2
1.
PROJET
DE
DEVELOPPEMENT
D’UN
SYSTEME
D’E-­‐BUSINESS
3
PROJET
155
TABLE
OF
CONTENTS
Thierry
Van
den
Berghe
DE
DEVELOPPEMENT
E-­‐BUSINESS
3
L’INGENIERIE
LOGICIELLE
:
DEFINITION
DEMARCHE
3
1.
PROCESSUS
DE
DEVELOPPEMENT
5
TYPES
DE
PROCESSUS
6
CONTREPIED
DE
LA
PLANIFICATION
:
METHODES
AGILE
7
PHASES
ACTIVITES
TYPIQUES
DE
DEVELOPPEMENT
7
2.
SPECIFICITES
DES
PROJETS
E-­‐BUSINESS
9
3.
CYCLE
DE
DEVELOPPEMENT
D’UN
LOGICIEL
11
CYCLE
DE
DEVELOPPEMENT
EN
CASCADE
11
2.
LANCEMENT
DU
PROJET
16
1.
DEFINITION
DE
LA
PORTEE
DU
SYSTEME
E-­‐BUSINESS
17
2.
GESTION
DES
ACTEURS
19
3.
GESTION
DE
PROJET
22
RESULTAT
SOUS
CONTRAINTES
22
TECHNIQUES
DE
PLANIFICATION
23
ETUDE
DE
CAS
:
SPORTS
D’HIVERS
24
3.
ETUDE
D’OPPORTUNITE
29
1.
RETOURS
D’UN
SYSTEME
29
RENTABILITE
D’UN
PROJET
DE
DEVELOPPEMENT
29
RETOUR
SUR
INVESTISSEMENT
:
COUTS
30
RETOUR
SUR
INVESTISSEMENT
:
BENEFICES
31
2.
FAISABILITE
D’UN
PROJET
32
FAISABILITE
FACE
AU
RISQUE
33
3.
EVALUATION
DU
COUT
D’UN
SYSTEME
34
ESTIMATION
DES
COUTS
DE
DEVELOPPEMENT
34
ANALYSE
PAR
POINTS
DE
FONCTION
(FP)
35
PARAMETRES
37
CONVERSION
EN
LIGNES
DE
CODE
40
4.
SPECIFICATIONS
50
1.
DEFINITION
DE
LA
SPECIFICATION
50
DIMENSIONS
CONSTITUTIVES
51
TYPES
DE
BESOINS
52
TYPES
DE
SPECIFICATIONS
52
UML
ET
RUP
54
2.
DIAGRAMME
DE
CAS
D’UTILISATION
56
EVALUATION
DES
CAS
D’UTILISATION
65
DEMARCHE
DE
CONSTRUCTION
65
GRANULARITE
DES
CAS
D’UTILISATION
66
3.
DIAGRAMME
D’ACTIVITE
76
DIAGRAMME
D’ACTIVITE
(UML1.*)
76
ACTION
FLUX
DE
CONTROLE
77

156. Manon
Cuylits
Master
1
2012-­‐2013
NOEUDS
DE
CONTROLE
78
PARTITION
82
DETAIL
DES
ACTIONS
82
EXTENSION
DES
DIAGRAMMES
D’ACTIVITE
UML
2.0
85
OBJECT
156
Développement
de
systèmes
e-­‐business
FLOWS
86
INTERRUPTIBLE
ACTIVITY
REGION
(UML
2.0)
87
EXPANSION
REGION
(UML
2.0)
88
WAIT
TIME
ACTION
(UML
2.0)
89
ERREURS
FREQUENTES
89
DIAGRAMMES
D’ACTIVITE
ET
SITES
WEB
90
DETAIL
DE
PAGE
APPLICATIVE
92
EXERCICES
92
4.
DIAGRAMME
DE
CONTENU
94
5.
DIAGRAMME
D’INTERFACE
96
6.
ETUDE
DE
CAS
98
5.
REALISATION
105
1.
CONCEPTION
ET
MISE
EN
OEUVRE
105
CONCEPTION
105
MISE
EN
OEUVRE
107
2.
OUTILS
DE
DEVELOPPEMENT
108
OUTILS
DE
DEVELOPPEMENT
CLASSIQUES
108
GENERATEURS
DE
SITES
110
PACKAGE
ET
CONTENT
MANAGEMENT
111
3.
TECHNIQUES
CLES
114
PAGES
DYNAMIQUES
114
INTEROPERABILITE
DES
SYSTEMES
117
6.
MISE
EN
PRODUCTION
122
ACQUERIR
UN
NOM
DE
DOMAINE
122
HEBERGEMENT
D’UN
SITE
123
7.
TEST
125
QUALITE
D’UN
SYSTEME
E-­‐BUSINESS
A
TESTER
125
TESTS
AUTOMATIQUES
126
DELEGATION
DE
TESTS
MANUELS
127
RETOUR
E-­‐BUSINESS
128
8.
EXEMPLE
:
RATIONAL
UNIFIED
PROCESS
130
ORGANISATION
DU
RUP
DANS
LE
TEMPS
130
DISCIPLINES
131
RUB
«
BEST
PRACTICES
»
132
9.
MAINTENANCE
ET
PROMOTION
134
MAINTENANCE
134
PROMOTION
135
LA
PROMOTION
D’UN
SITE
WEB
COMMERCIAL
135
REFERENCEMENT
DANS
LES
MOTEURS
DE
RECHERCHE
136
E-­‐MAILING
DIRECT
138

157. Manon
Cuylits
Master
1
2012-­‐2013
157
Thierry
Van
den
Berghe
PUBLICITE
–
BANNERING
139
MISE
EN
PLACE
DE
PARTENARIATS
140
RELATIONS
PUBLIQUES
EN
LIGNE
141
10.
SECURITE
142
ETAT
ET
ENJEUX
142
L’ETAT
DES
SYSTEMES
142
AMPLEUR
DU
PHENOMENE
147
ENJEUX
DE
LA
SECURITE
147
DIMENSIONS
CLES
DE
LA
SECURITE
147
SOLUTIONS
148
APPROCHE
MULTIDIMENSIONNELLE
DE
LA
SECURITE
149
SECURITE
DE
LA
BD
=
PROCEDURES
+
TECHNIQUES
150
METHODE
DE
GESTION
DE
LA
SECURITE
150
STANDARDS
151
EXEMPLE
DE
PROCEDURE
DE
SECURITE
152
CHOIX
DE
MOTS
DE
PASSE
FORTS
152