=Paper=
{{Paper
|id=Vol-547/paper-44
|storemode=property
|title=Proposition d'un processus de développement pour la modélisation sécurisée des systèmes d'information
|pdfUrl=https://ceur-ws.org/Vol-547/118.pdf
|volume=Vol-547
|dblpUrl=https://dblp.org/rec/conf/ciia/ChehidaR09
}}
==Proposition d'un processus de développement pour la modélisation sécurisée des systèmes d'information==
https://ceur-ws.org/Vol-547/118.pdf
Proposi
ti
ond’ unpr oces
susde
développement pour la modélisation
sé
cur i
séedessystème sd’ i
nformat ion
Salim CHEHIDA 1, Mustapha kamel RAHMOUNI 2
1
Dépa
rteme ntd’
Inf
or ma t
ique,Université de Mostaganem, Algérie
salimchehida@yahoo.fr
2
Dé
parte
me ntd’
Inf
orma t
iqu
e,Université d’Or a
nEs-Sénia, Algérie
kamel_rahmouni@yahoo.fr
Abstract. Le ss ystème sd’ informa t
ion pr ése ntent des besoins plus en plus
croissants en termes d’ ouv ertureàl ’extéri
eur( clients
,pa r
tenair
es,f ournisseur s)
etd’ é voluti
v i
té(tech niquee torg anisation).Ouverture et évolutivité engendrent
des gains de productivité et de compétitivité mais elles exposent aussi de plus
en plus les systèmes aux actes de malveillance. La prise en compte des
contraintes de sécurité (intégrité, confidentialité, non répudiation, disponibilité,
etc.) au niveau de la modélisation c onstit
uel ’u nde sprincipauxc ha l
lengespour
les concepteurs des SI. Dans cet article, nous proposons un nouveau processus
de développement construit àpa rtird’ UML qui prend en considération, en plus
des besoins fonctionnels, les contraintes de sécurité et aussi le changement et
l’évol uti
o ndel ’architec t
ur etec hniq uede ss ys tème sd’ informa t
ion.Ce proces-
sus vérifie les caractéristiques des processus unifiés et est ba sés url ’
Extreme
Programming (XP).
Mots clés : Modélisation, UML, Sécurité, Processus de développement,
Processus Unifié, Extreme Programming.
1. Introduction
Lesé v olut
ion sr éce ntesetr apide sdel ’i
nf or
ma t
iqu eon tcontribu éàl ’
acc élération
de sé chang esd’ informa ti
ons .Ene ff
e t
,l e
sr éseauxdel '
entrepriseme tt
ente nœu v re
des données sensibles, les stockent, les partagent en interne et les communiquent à
d'autres entreprises ou personnes. Parallèlement, le nombre de problèmes de sécurité a
augmenté de manière très important ces dernières années, et cette courbe ascendante
n ede vraitma lhe ureu seme ntpa ss ’infléchi
r .Lese ntre pri
s esse trouvent désormais
c on f
r ont
é esa uc on trôlee ffic
a cedel ac onfide nt
ial
i t
é,del ’intégritée tdeladi spon ibi-
lité de ces informations. La sécurité à posteriori des SI (Firewall, Antivirus, etc.) et les
nouvelles technologies n tiers qui tiennent en charge le problème de sécurité en de-
hors du code métier peuvent donner des résultats mais elle ne constitue pas une véri-
table politique de sécurité. Nou spe nson squ el’él
a bora t
iond’ unepol it
iquedes éc urité
doit se faire en même temps que la modélisation fonctionnelle, et que le modèle final
doit intégrer à la fois les spécifications fonctionnelles et de sécurité. UMLs ’esti mpo-
sé comme le langage standard pour la modélisation de sv uesmu l
tiplesd’ uns y st
è meà
l’aidedemé canisme sc ommel e
ss téréotype s
,le sé tiquettes, les notes, les contraintes,
etc. UMLs ece stun ee xtensiond’ UMLpr oposé epa rJ a
nJ ü rj
e ns( Munich University
of Technology). Ce tt
ev ersiond’ UMLu tilis
el e sdi ffér
e ntsmé canisme sd’ extension
pour la modélisation des aspects de sécurité. Dans le cadre de la modélisation avec
UML, une famille de processus unifiés (Unified Processes) a été proposée. Concevoir
à partir d’uns e ulproc essuss erai
tun eg r
a vee rreurc arlava riétéde ss y stèmese tde s
techniques ne le permet pas. Le présent article propose un nouveau processus de dé-
veloppement permettant l ’i
n tégra
tionde sc ontr
a int
e sdes éc u r
itéda nsl amodé li
s at
ion
de ss ystème sd’ inf
orma ti
on .Ent ena ntcompte de sé voluti
onsdel ’arch itectur
et ec hni-
que des systèmes, ce processus définit deux axes de conception : la vue logique ou de
conception qui décrit les aspects statiques et dynamiques du système en termes de
c l
a ssese td’ obj et
s, et la vue technique qui se préoccupe de la spécification de
l’arc hi
tecturet echn i
qu edus y
stème .Pour augmenter le niveau de satisfaction des
clients tout en rendant le développement plus facile en favorisant le travail en équipe,
la communication avec le client, et en livrant de façon itérative le produit logiciel, une
famille de méthodes appelées « Agile » a été proposée. Extreme Programming (XP)
est une méthode de type « Agile » basée sur les principes de communication, simplici-
té, feedback et courage. Nou savon sessay éd’ i
n tégr erce sd ern i
e r
spr in cipesdans no-
tre processus de développement.
2. Présentation générale du processus
Le processus en X ou XUP « X Unified Process » est un nouveau processus de
développement que nous proposons dans cet article. Ce processus répond bien aux ca-
ractérist
iqu esd’ unpr oc essusUPe ti le stba sésurun ea pproche disciplinée focalisée
surl ’Extreme Programming afin de bien maîtriser, tout au long du cycle de dévelop-
pement du logiciel, l'assignation des tâches et la responsabilisation des différents ac-
teurs participants. Le « X » signifie littéralement que le processus suit deux chemins
en haut et deux chemins en bas ce que donne une forme en X. Les deux chemins du
haut sont utilisés pour la spécification parallèle des besoins fonctionnels et des
contraintes de sécurité, et les deux chemins du bas correspondent aux deux axes des
cha ngeme ntsimpos ésa us ystèmed’ inf orma t
ion: ils ’agitdel av uel og i
qu eoude
conception qui décrit les aspects statiques et dynamiques du système en termes de
classes et d’ objetset la vue technique qui se préoccupe de la spécification de
l’archit
e cturetec hniquedus ystème.
3. Axiomes fondateurs
Le processus en X est basé sur les deux axiomes suivants:
1) Las péc i
ficationfon ctionne l
lede ss ystème sd’ informa ti
onn’ estpass uffisa
ntepour
résoudre les différentes problématiques liées à l ’intégration des réseaux informatiques
dans ces systèmes, comme, entre autres, les problèmes de sécurité. La conception et la
réalisation des systèmes d’ informa ti
ondoivent tenir compte, en plus des besoins fonc-
tionnels, des différentes contraintes de sécurité. On peut procéder donc à une spécifi-
cation parallèle, suivant un axe gauche « fonctionnel » et un axe droite « de sécurité ».
Al ’
issuede sé volu t
ionsde sspé cifi
ca t
ionsf on ctionn ell
e setde sécurité, la conception
du système consistera à fusionner les résultats de ces deux branches du processus.
Par exemple: Lorsque un client veut effectuer un paiement des factures par Internet
pour une entreprise commerciale, la branche gauche consiste à spécifier et à traiter les
différents besoins fonctionnelst elqu el ’
ide ntificationdel ac art
edec rédit
,las pé ci
fi-
ca t
ionde sfa cturesi mpa yée se tl’affect
a t
ionde sf act
u r
e sàpa yer.Pa rc ontrel abr an-
che droite consiste à spécifier et analyser les différentes contraintes de sécurité liées à
l’opé r
ationdepa i
e mentt elqu el ’intégri
tée tlac on f
iden t
ial
itéde sfactu r
ese tde si n-
formations de paiement et aussi la non répudiation de paiement. En fin, les résultats
issusde sde uxbr an chespe rme ttentd’a ss
u rerun eopé rationdepa ieme n tsécurisé e.
Besoins Contraintes
fonctionnels de sécurité
Conception du
Système d’
Infor
mat i
on
Fig. 1. Lac
oncept i
ond’ uns ystèmed’ informa tions ujetàde
sbe
soi
ns
fonctionnels et à des contraintes de sécurité
2) L’ or ga ni
sa t
ionlogique, qui décrit les aspects statique et dynamique du système en
terme sdec lassese td’ obj
ets
, est en effet indépendante des technologies et architectu-
res techniques utilisées pou rl edé v eloppe me ntd’u npr odu itlogici
e l. Le deuxième
axiome fondateur du processus en X consiste à décomposer et à traiter parallèlement
les vues logique et technique du système à partir des besoins fonctionnels et de sécuri-
té spécifiés précédemment. Enfin, la réalisation du système consiste à intégrer le mo-
dè lel og iqueda n sl ’archit
ect
ur et echniqu e .La branche logique consiste en effet à dé-
finir la structure et la dynamique des classes et des objets de système, à l'autre côté, la
branche technique spécifie l'architecture technique et la configuration matérielle du
système.
Spécification des Spécification des
besoins fonctionnels contraintes de sécurité
Conception Conception
logique technique
Fig. 2. La conception des systèmes se fait suivant un axe logique et
technique
4. Architecture et description des phases
Laf igures uiva ntepré s
en t
el es chémag énéraldupr oce ssuse nX.D’ unc ôté ,la
spécification parallèle des besoins fonctionnels et des contraintes de sécurité et, de
l’
autrec ôté,lacon ce pti
onl ogiquee tcelledel ’arch i
tecturetech niquedus ystème ,qui
donne au processus une forme en X.
Recueil initial des besoins
Spécification des Spécification des
besoins fonctionnels contraintes de sécurité
Collaboration et validation
Analyse et Architecture
conception technique
Intégration, codage
et tests
Fig. 3. Les phases du processus de développement en X
4.1. Recueil initial des besoins
Le recueil initial des besoins est la première phase du processus en X. Cette étape
joue un rôle très important car elle constitue le point de départ de la modélisation du
système. Elle consiste à effectuer un premier repérage des besoins fonctionnels et de
sécurité en utilisant le texte pour définir les cahiers des charges (fonctionnel et sécuri-
té),e tde sdi ag r
amme ss i
mpl espou rv isua l
iserl ec on t
ex t
edus ystè me.L’ objectif
principal de cette phase est donc de préparer le terrain aux phases de spécification des
besoins fonctionnels et des contraintes de sécurité.
4.2. Spécification des besoins fonctionnels
Cette phase a pour objectifs de compléter le recueil initial des besoins fonction-
nels effectué durant la phase précédente, et de définir la frontière fonctionnelle entre
le système et son environnement en précisant les activités attendues des différents uti-
lisateurs du système. Cette étape produit un modèle qui permet de contrôler la bonne
adéquation des besoins fonctionnels avec ceux des utilisateurs. La technique des cas
d’ util
isati
one stl apierrea ngulairedec etteé tape.El lepe rme tdes péci
fierl’ens embl e
de ss équenc esd’ i
nteracti
on se nt
reles ystèmee tsesa c t
e urs.Ce tteph asec onsistea ussi
àdé c
rir
elady na mi
quede
sca
sd’
uti
li
sat
ione
nut
il
is
antl
ete
xtee
tle
sdi
ff
ére
ntsmodè-
les dynamiques.
4.3. Spécification des contraintes de sécurité
Cette phase consiste à compléter la spécification des différentes contraintes de
sécurité recensées dans la phase de recueil initial des besoins, et qui dimensionnent la
conception logique et technique du système. Dans cette phase, nous introduisons les
notions de cas de sécurité et de diagramme de cas de sécurité. Un cas de sécurité est
utilisé pour représenter les services de sécurité fournis par le système pour les diffé-
rents acteurs. Cette phase consiste aussi à déc rirel ess cénariosc r
itiquesàl ’ai
dede s
différents modèles dynamiques, ainsi que l ’
ide ntificati
onde sa t
ta quespos s
ibles.
4.4. Collaboration et validation
Cette phase consiste à coordonner entre les modèles de deux branches de spécifi-
cation, puis de valider les besoins fonctionnels et les contraintes de sécurité avec le
client. Dansl ecarded’ unpr ocessusi t
ératif,i
n créme nta letpilotépa rlesr i
squ es,cette
étape permet aussi de partager le projet en itérations en affectant des niveaux de ris-
qu eàc haquec asd’ uti
lisatione tsesc orr
e sponda ntsdes écurit
é ,ete ncomme nçantpa r
lesc a slespl usc riti
qu ese nterme sdeg est
iondepr oje
ta f
ind’ annulerl esr is
qu es
d’é che c.
4.5. Analyse et conception
Cette phase décrit les aspects statiques et dynamiques du système en termes de
classe
se td’obj e
ts ,ainsiqu elesc ollaborationse tl esinte rac
tion
sentrecesobj ets.Elle
produit un modèle de conception du domaine qui définit la structure et la dynamique
des objets connus dans le métier des utilisateurs du système dans le cadre de la mise
en application de leurs besoins fonctionnels et de sécurité.
4.6. Architecture technique
Cette phase consiste à recenser toutes les contraintes et les choix techniques. Elle
produ itde smodè les pe rme ttantd’expr i
me rl escon traintesdemi see nœuv rea un i-
veauphy s
iqu e(lesnœu dse tlesc onn ex i
onsphy sique sdus ystè me),e tdedé fi
nirun e
architecture basée sur des dispositions préventives prenant en considération les
contraintes fonctionnelles et de sécurité pour assurer la sécurité du système contre les
menaces potentielles.
4.7. Intégration, codage et tests
Cetteph asec on sisteài ntégrerl emodè lel og
iqueda nsl’ar
ch it
e cturet ech niqu e
,
en spécifiant le modèle de déploiement et le modèle de données de système ainsi que
le codage et la réalisation du système. Cette phase permet aussi de tester les unités de
code réalisées et de valider les fonctions du système développé.
5. Tactiques de progression
XUP passe par un ensemble d’ étapes successives de plus en plus détaillées, une
telle progression organise le volume des informations collectées et définit les objectifs
à atteindre pour chaque étape suivant un découpage en niveaux de détail croissants.
Laf iguresu i
v antemon trel esdi ff
ére
n tsn i
v eauxd’a vanceme ntduprocessus en X.
Contexte
Cas d’
uti
li
sat
ion Cas de sécurité
Enchaînements de description Scénarios critiques
Classes statiques Choix technique
Interaction des objets Composants d’
expl
oit
ati
on
Classes de conception Spécification matérielle
Modèle de déploiement
Modèle de données
Codage et recette
Fig. 4. Niveaux de progression du processus en X
* Pour la phase de recueil initial de besoins :
Le niveau « contexte » consiste à définir la frontière fonctionnelle et les différents
services de sécurité attendus du système considéré comme une boîte noire.
* Pour la phase de spécification des besoins fonctionnels :
Le niveau « c asd’ util
isation» a pour objet de montrer les différentes possibilités
d’utili
sationdus ystèmeàpa r t
irdumodè l
edec ontextea find’ i
denti
fierl ec ompor te-
ment de ce système sans spécifier sa structure interne. Le scasd’ ut
il
isationpe rme t
tent
aussidef orcerl’utilisateuràdé finircequ ’ila t
tenddus y stè
me .
Les « enchaînements de description » consistent à établir une description des cas
d’utili
sationi den t
ifiésau n ive aupr écédent,e nprésentan tl’
e n semblede sin t
e racti
on s
entre les acteurs et le système considéré comme une boîte noire. La description des
c asd’ util
isati one stin dis
pe nsabl e,c are ll
epe rme tde communiquer facilement et de
manière précise avec les utilisateurs.
* Pour la phase de spécification des contraintes de sécurité :
Le niveau « cas de sécurité » permet de définir les services de sécurité fournis par
le système (toujours envisagé comme une boite noire) afin de répondre aux différen-
tes exigences de sécurité identifiées au niveau contexte. Les cas de sécurité sont abso-
lume ntdi st
in c t
sde sc a sd’u ti
lisation; ils ne produisent pas une valeur ajoutée fonc-
tionnelle mais ils recouvrent en effet tous service de sécurité dont un utilisateur
bénéficie. Par exemple : As surerl ’authent i
f i
c at
iond’ unutilisateur, As surerl’intégrité
et la confidentialité des informations échangées, Assurer la non répu diati
ond’ une
transaction,...
Les « scénarios critiques » consistent à décrire les interactions ou les actions qui
incluent un risque en mettant en jeu les différentes services ou propriétés de sécurité
spécifiées par les cas de sécurité. Par exemple : les scénarios qui permettent d’ a ssur
e r
la non répudiation dans les transactions; il garantir que si une action est exécutée, elle
ne peut pas être niée (elle est prouvée), les scénarios qui permettent d’ assurer un
échange équitable lors d'une transaction, les scénarios qui spécifient les interactions
pe rme tt
a ntl ’ échang e de si nfor mations c rit
iqu es( nécessitel ac onfidentiali
tée t
l’intégrité)
* Pou rl aph a sed’ analyse et conception :
Les « classes statiques » sont identifiées à partir des concepts métier extraits des
sc énariosdede sc ri
ptionde sc asd’ u
tili
sa t
ione tde ss cén ari
osc ri
ti
qu es.Ces concepts
seront e nsuitef or maliséss ousf or medec lassese td’ assoc iat
ion srassembl éesda nsun
diagramme statique.
Après le développement du modèle statique, nous remplaçons le système, considé-
ré comme une boite noire lors de la spécification, pa rune nsembl ed’obj ets
.Le niveau
« interaction » consiste donc à représenter la collaboration entre ces objets à partir des
sc énariosdé c rivantl’ex écutionde sc asd’ utili
sation ou de sécurité
Le niveau « classe de conception » consiste à optimiser les modèles statiques en af-
finant les classes, les associations et les attributs, et en ajoutant les opérations identi-
fiéesg râceàl ’analys edy n ami qu ede ss cén ari
osd’ interaction. Dans le modèle de
conception, on doit spécifier les propriétés de sécurité sur les données en profitant de
la spécification des contraintes de sécurité.
* Pou rl aph a sed’ architect
u rete ch ni
qu e:
Le niveau « choix technique » permet de spécifier les pré-requis et les stratégies
techniques, a insiqu el esty l
ed’ architecturee nte na ntc ompt edes contextes fonction-
nel et de sécurité.
Après la spécification des choix techniques, le niveau « composants
d’ exploitati
on» définit la façon dont sera organisé les différents composant du sys-
tème ( Ba sededon nées,Ser veurs ,Appl ication s,
…) .
Le niveau « spécification matérielle » pe rme tdedé finirl’organisati
onphy siquee n
termes de machines connectées par des moyens divers. En effet, les machines et les
connexions sont toutes en r elat
iondi r
e ctea v ecle sc ompos a
n tsd’exploitati
on .Lemo-
dèle matériel doit intégrer les dispositions de prévention pour répondre aux contrain-
tes de sécurité.
* Pour la phase Intégration, codage et tests :
Le « modèle de déploiement » permet de représenter les postes de travail, la répar-
tition des fonctions du système, ainsi que la localisation des composants
d’ exploitat
ions urlerés eauphy s
ique.
Le « modèle de données » permet la conception du stockage des données en étu-
diant sous quelle forme les instances sont sauvegardées sur un support physique.
Le niveau « Codage et recette » permet de produire et tester les unités de code puis
de valider les fonctions de système développé.
6. Pol
it
iqued’
it
érat
ione
tdege
sti
ondeprojets
Après le recueil initial des besoins et la définition des cahiers des charges fonc-
tionnel et de sécurité avec le client, le système est découpé en packages fonctionnels
fortement cohérents (en termes métier) et faiblement couplés (indépendants). A cet ef-
fet, il convient de spécifier les packages de sécurité permettant la structuration des
contraintes de sécurité liées à chaque package fonctionnel. Un package fonctionnel et
son correspondant de sécurité sont appelés package métier. Il sera ensuite demandé au
client de définir des niveaux de priorité pour chaque package métier afin de livrer les
fonctions les plus demandées.
La phase de spécification se fait par itération : chaque itération correspond à un
package métier. Apr è
sl ’iden t
ifi
c ationde sca sd’ uti
lisat
ione tdes écurité,lec he fde
pr ojetv alidecesc asa vecl ec li
en toul esa cteursc onc ernés
.Sil ’
e nsembl edese x i
g en-
c esa ssurée sparl esc asd’ u til
is
a t
ione tdes écuriténerépond pas aux besoins des ca-
h i
e rsde sc h
arge s,l’équipedes pé cification doit reprendre la spécification et corriger
les erreurs. Apr èsl av al
ida tionde sc asd’ uti
lis
atione tdesc asdes é curitédupa ck age
métier correspondant à une itération, on devra associer des niveaux de risque à chaque
cas. A cet effet, il faudrac omme n ce rpa rl esca sd’ util
isa
tione tdes éc ur
itél espl us
critiques en termes de gestion de projet afin de lever les risques majeurs. Une fois
l’affe ctat
ionde sn i
v eauxder i
squ eé tablie,onpr ocèdea udé coupa gedupr ojeteni té-
rations. Chaque itérationi n clutu ne n sembl edec a sd’u t
il
isatione tde cas de sécurité.
La progression de la conception logique et technique est aussi de type itératif.
L’ an alysee tlac on cepti
onl ogiqu ec omme n centpa rl’identifi
cationde sc lassesc andi-
dates à partir des cas d’utilisati
ondel amê mei térati
on .Cesc l
asse ss eronte nsuitedé-
taillées,c ompl étéese topt imi sées.Let r
a vaild’a ff
ineme ntc on si
steàa jou t
e r
,àmodi-
fier ou à supprimer des classes, des associations ou des attributs. On profite ensuite de
la branche de sécurité pour définir les contraintes de sécurité sur les données, et de
l’an alysedy namiqu epou rl’a j
ou tde sopé r
a t
ions.Apr èsl’élaborationdumodè l
el og i-
qu ed’ unei téra
tion ,ons péc if
iel ’ar chitecturete chniqu epe rme t
ta ntl’e xploitat
ionde
ce modèle. Si lemodè lelog iqu ee ts onc orrespon dan ttechniqued’ unei t
érat
iona tt
e i-
g nen tl e
sobj e c
tifsf ixés,onpa sseàl ’i
mpl ément at
ion .Les taches d’ in dustr
ia l
isation
du logiciel concernent la mise en place des moyens et des outils qui vont permettre la
livraison (release)d’ uneitération.
7. Réutilisation et maintenance
La phase de spécification des besoins fonctionnels produit des modèles pour le
moyen et long terme, a findec apitalis
erlemé t
ierdel ’e
ntrepris
ee tlefon ct
ion n
e ment
des ons ystèmed’ informa ti
on.La phase de spécification des contraintes de sécurité,
quant à elle, produit des modèles pour le court terme, afin de définir les exigences de
sécu rit
ési mpos éesa uxs y stème sd’ i
nformationa pr èslac apturede sme n a
c esprove-
nantdel ’env ironn eme ntdel ’en t
re pri
se.Sil’env ironn e
me nte xig eden ou vell
esdon-
nes en matière de sécurité, il suffira d’i
n t
égrerlas péc i
fic
a t
ionde sn ouvell
esc ontra
in-
tesdes écuritéda nslemodè lel og iquee td’a
rchitecturetec hniquepou rme tt
reàj ourl e
système sans passer par la spécification fonctionnelle.
La phase d’ analyse et de conception produit des modèles pour le moyen et long
terme afin de représenter la vue logique de système en termes de classes et objets.
D’ unautre côté, la phase d’ archite ct
uretechniquepe rme tdedé v e lopper des modèles
pour le court et le moyen terme afin de visualiser la conception technique du système.
Le modèle logique étant i n dé penda ntdel ’ar
c hi
tectu retechnique , on peut donc réali-
ser le même modèle logique en utilisant les différentes technologies dépendantes des
mêmes exigences fonctionnelles et de sécurité.
8. Le processus en X, Processus Unifié et Extreme Programming
8.1. Lepr
oce
ssuse
nXvé
rif
iel
esc
arac
tér
ist
ique
sd’
unpr
oce
ssusuni
fi
é
Un processus unifié est un processus de développement logiciel construit sur UML,
ile stitératife tincréme ntal,cen t
rés u rl’ar
c hit
ecturee tpi lotépa rlese xi
ge ncesde su ti-
lisa t
eu rs.Lepr ocessu se nXvé ri
fiel esc aractér
isti
que sd’ unpr ocess usu nif
ié.
Le processus en X piloté par les exigences des utilisateurs :
Les exigences des utilisateurs sont donc prioritairement abordées dans ce processus en
considérant deux types de besoins :
1. Les besoins fonctionnels qui correspondent aux fonctions métiers du système.
2. Les besoins de sécurité qui correspond aux services de sécurité qui doivent être
rendu par le système.
Pou rc haqu ec a s d’ util
isation ,on pr ocède à l a de scripti
on de l ’ensembl e
d’i nteractionse nt
rel esu t
ilis
a t
e urse tles ystème .Lesc on ceptsu til
isé sdansc e
ttede s-
cription mets en évide ncel esdi f
fé rentesc l
a ss
ese tobj etsdus y st
ème .Da nsl’autrec ô-
té, les cas de sécurité et scénarios critiques permettant de définir les sous systèmes, les
objets et les classes critiques ainsi que des niveaux de sécurité sur les données. Pour la
concept iond’ architectu re,lesc h oixt echn iquesdoi ve n tê tr
epi l
oté spa rlesbe s oins
fonctionnels et les contraintes de sécurité. Le modèle de déploiement exprime généra-
lement la répartition physique des fonctions métier sur les différents acteurs. Ce mo-
dèle doit prendre en considération les fonctions du système spécifiées par les cas
d’u tili
s at
ionpou rl ’ide ntif
icationde spos tesdet ravail, et les contraintes de sécurité
pour montrer les conditions de sécurité sur les connexions. La configuration maté-
rielle doit inté gr
e rlesdi s
pos it
ifspr éven ti
fse tle sc omposantsd’ ex ploitati
ondoi v ent
satisfaire les exigences fonctionnelles et de sécurité.
Le processus en X itératif et incrémental
Lec h oixd’ u neitérat
ion repose sur deux facteurs:
- Une itération prend en compt eu nc erta i
nn ombr edec asd’utili
sationet ses corres-
pondants de sécurité
- L’ i
té r
ationt ra i
teenpr iori
tél esrisque sma jeurs.
Ac haqu ei térati
on,le sdév el
oppe u rside ntif
iente ts pécif
ientlesc a sd’ uti
li
sa t
ionset
de sécurité, créent une conception logique et technique, intègrent et implémentent ces
conceptions sous forme de composants et vérifient que ceux-ci sont conformes aux
c asd’ uti
lisationet aux cas de sécurité.Dè squ’ un eit
é r
ati
onr épon da uxobj ec t
if
s
fixés, ledé veloppe mentpa sseàl ’itér
ation suivante.
Dans le cadre de la livraison des parties de système prioritairement demandées, no-
tre politique de gestion de projet consiste à définir de niveaux de priorité pour chaque
package métier afin de livrer les parties les plus demandées. Dans le cadre de la ré-
du ctionde sr isquesd’ échec,ilc onv i
en td’ associerde sniveauxder isqu epou rc haque
c asd’ u
tilisatione tdes écurité
, afin de commencer par les cas les plus critiques en
termes de gestion de projet.
Le processus en X centré sur l’ arch i
tec t
u re
L’ architectu r
ed’ uns ystèmel og i
c i
elpe utê t
redé c rit
ec ommel esdi ff
é rent
esv uesdu
sy stème .L’ architect
ure« 4+1 » vues proposée par Ph. Kruchten présente cinq vues
imbriquées : la vue des besoins des utilisateurs, la vue logique ou de conception, la
vue des processus, la vue des composants ou de réalisation et la vue de déploiement.
Chaque vue est une projection dans l'organisation et la structure du système qui s'inté-
resse à un aspect particulier de ce système. Les différentes vues sont abordées par le
processus en X.
La vue des besoins des utilisateurs
La vue des processus
La vue des Composants
La vue logique
La vue de déploiement
sv
Fig. 5. Le ue
sd’
arc
hit
ect
ured
ansl
epr
oce
ssuse
nX
8.2. Le processus en X est basé sur XP (Extreme Programming)
Extreme Programming est une méthode « Agile » basée sur un ensemble de prati-
ques destinées à organiser le travail d'une équipe de développement. Plus générale-
ment, les pratiques XP sont sous-tendues par les quatre principes suivants [6] :
* La Communication : XP favorise le contact humain, la communication directe, plu-
tôt que le cloisonnement des activités et les échanges de documents formels. Les dé-
veloppeurs travaillent directement avec le client et les testeurs sont intégrés à l'équipe
de développement.
* Le Feedback : Les pratiques XP sont conçues pour donner un maximum de feed-
back sur le déroulement du projet afin de corriger la trajectoire au plus tôt. En particu-
lier, les points de début d'itération offrent à l'équipe le moyen de prendre du recul sur
son fonctionnement et de l'améliorer sans cesse au fil des itérations.
* La Simplicité: XP relève le défi suivant : « que pouvons-nous arrêter de faire tout
en continuant à créer efficacement un logiciel qui réponde aux besoins réels du client
? ». Cette recherche de simplification touche le processus lui-même, mais aussi l'outil
fabr iqu ée tlac oncepti
ondel ’
a pplication.
* Le Courage: il s'agit principalement du courage d'honorer les autres valeurs –celui
de maintenir une communication franche et ouverte, d'accepter et de traiter de front
les mauvaises nouvelles, etc.
Pour vérifier ces quatre principes,l epr oces suse nX me tenœuv r
el espr a t
iqu es
suivantes :
Travail en équ ipee tl’impl icationduc l
ient:
Le processus en X partage le travail de développement en plusieurs équipes
(équipe de spécification fonctionnelles, équipe de spécification de sécurité, équipe de
conception logique, équipe technique, équipe de codage et réalisation et testeurs) et
favorise la communication entre les différentes équipes ainsi que la communication
avec le client ou les utilisateurs.
Programmation pilotée par les tests :
Pour chaque scénario planifié, un ensemble de tests de recette est élaboré. Ces tests
consistent à vérifier chacune des fonctionnalités demandées par le client. Le client
doit donc participer à ces tests. En complément des tests de recette, qui servent à
prouver au client que le logiciel remplit ses objectifs, Le processus en X réalise des
tests unitaires. Ces tests permettent de spécifier et valider le comportement de chaque
portion de code ajoutée.
Cycles itératifs pilotés par le client :
L'équipe livre régulièrement des versions du logiciel, les livraisons de nouvelles
versions s'enchaînent à un rythme soutenu pour obtenir un feedback maximal sur
l'avancement des développements. Au début de chaque itération, le client et les diffé-
rentes équipes de développement se réunissent pour la planification de chaque itéra-
tion. Cette réunion se présente comme une réelle séance de travail, qui donne aux dif-
férents intervenants l'occasion d'aligner leur compréhension de ce qui doit être réalisé.
9. Conclusion
Le processus e nX v érif
iel esc arac t
éri
stiquesd’ u npr oc essusun ifiée tpermet la
mi see nœu vrede sdi ffé
rentespr ati
qu esdel ’Extreme Programming. Il constitue une
trame pour intégrer les meilleures pratiques dans les différents cycles de développe-
ment. Ce processus permet une spécification parallèle des besoins fonctionnels et des
contraintes de sécurité,ai
n s
iqu ’une conception parallèle de la vue logique et techni-
qu ed’u ns ystème .Cedé coupa gef avor i
selet rava i
le né qu ipee trépon da uxbe soins
d’év olut
ionde ss ys
tè me s
.Lepr oce ssuse nX dé fi
n i
tu nebon nepolitiqued’ it
ération
pilotée par les risques et les priorités du client,a insiqu ’
un ebonne tactique de pro-
gression définissant les objectifs à atteindre à chaque phase.
10. Références
Bibliographie
1. P. ROQUES et F. VALLEE, « UML en action », Eyrolles, (2002).
2. J.L. BENARD, L. BOSSAVIT, D.WILLIAMS, « L’ Extr emePr ogrammi ng
avec deux études de cas », Eyrolles, (2002).
3. I.JACOBSON, G.BOUCH, J.RAMBAUGH, « Le processus unifié de déve-
loppement logiciel », Eyrolles, (2000).
4. A.COCKBURN, « Ré dige r de sc as d’uti
li
sat
ion efficaces », Eyrolles,
(2001).
5. P.ROQUES, « UML par la Pratique », Eyrolles, 2ème édition (2003).
6. R.MEDINA, « L’ Ex tremeProgramming », Cours Crossbow Labs, (2008).
7. P. KRUCHTEN , « The Rational Unified Process : An Introduction », Addi-
son-Wesley, Second Edition (2000).
8. P. KRUCHTEN et K. PER, « Guide pratique du RUP », Campus Press,
(2003).
9. S. MENG « Security Requirements Analysis and Modeling of Distributed
System »s, Master´s Thesis , Munich University of Technology Department
of Informatics, Software & Systems Engineering, (2004).
10. E.MAIWALD, « Sécurité des réseaux », Campus Press, (2001).
11. J.JURJENS, « Secure Systems Development with UML: a Foundation »,
(2003).
12. S.CHEHIDA, « Modélisation sécurisée des systèmes d'information Etude de
cas: ANPE », Mini-projet (2007).
13. P. ROQUES, « UML est-il soluble dans les méthodes agiles ? », Eyrolles,
(2007).
14. B.DEBBABI, M.S.BOUDJELDA, « Le processus unifié de développement
logiciel RUP », (2007).
15. G. PICARD, «le processus unifié», Cours ENS Mines Saint-Etienne, (2008).
16. P. ROQUES, « Modéliser un site e-commerce», Eyrolles, (2002).
17. K.SCOTT, «Unified Process Explained », Addison-Wesley, (2002).
18. C.LARMAN, « UML et les Design Patterns », Campus Press, (2002).
Webographie
1. http://www.xprogramming.com/software.htm
2. http://www.agilealliance.org
3. http://en.wikipedia.org/wiki/Rational_Unified
4. www.extremeprogramming.org,
5. www.xpdeveloper.com
6. www.xprogramming.com
7. www.xp123.com