L e s s y s t è me s d ' i n f o r ma t i o n p r é s e n t ent des besoins plus en plus croissants en termes d' o u v e r t u r e à l ' e x t é r i e u r ( c l i e n t s , p a r t e n a i r e s , f o u r n i s s e u r s ) e t d ' é v o l u t i v i t é ( t e c h n i q u e e t o r g a n i s a t i o n ) . 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 o n s t i t u e l ' u n d e s p r i n c i p a u x c h a l l e n g e s p o u r les concepteurs des SI. Dans cet article, nous proposons un nouveau processus de développement construit à p a r t i r d ' UML qui prend en considération, en plus des besoins fonctionnels, les contraintes de sécurité et aussi le changement et l ' é v o l u t i o n d e l ' a r c h i t e c t u r e t e c h n i q u e d e s s y s t è me s d ' i n f o r ma t i o n . Ce processus vérifie les caractéristiques des processus unifiés et est b a s é s u r l ' Extreme Programming (XP).
L e s é v o l u t i o n s r é c e n t e s e t r a p i d e s d e l ' i n f o r ma t i q u e o n t c o n t r i b u é à l ' a c c é l é r a t i o n d e s é c h a n g e s d ' i n f o r ma t i o n s . E n e f f e t , l e s r é s e a u x d e l ' e n t r e p r i s e me t t e n t e n oeu v r e 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 e d e v r a i t ma l h e u r e u s e me n t p a s s ' i n f l é c h i r . L e s e n t r e p r i s e s se trouvent désormais c o n f r o n t é e s a u c o n t r ô l e e f f i c a c e d e l a c o n f i d e n t i a l i t é , d e l ' i n t é g r i t é e t d e l a d i s p o n i b ilité 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 dehors du code métier peuvent donner des résultats mais elle ne constitue pas une véritable politique de sécurité. No u s p e n s o n s q u e l ' é l a b o r a t i o n d ' u n e p o l i t i q u e d e s é c u r i t é 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é. sé comme le langage standard pour la modélisation d e s v u e s mu l t i p l e s d ' u n s y s t è me à l ' a i d e d e mé c a n i s me s c o mme l e s s t é r é o t y p e s , l e s é tiquettes, les notes, les contraintes, etc. UML s e c e s t u n e e x t e n s i o n d ' UML p r o p o s é e p a r J a n J ü r j e n s ( Munich University of Technology). C e t t e v e r s i o n d ' UML u t i l i s e l e s d i f f é r e n t s mé c a n i s me s d ' e x t e n s i o n 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 ' u n s e u l p r o c e s s u s s e r a i t u n e g r a v e e r r e u r c a r l a v a r i é t é d e s s y s t è me s e t d e s techniques ne le permet pas. Le présent article propose un nouveau processus de développement permettant l ' i n t é g r a t i o n d e s c o n t r a i n t e s d e s é c u r i t é d a n s l a mo d é l i s a t i o n d e s s y s t è me s d ' i n f o r ma t i o n . E n t e n a n t compte de s é v o l u t i o n s d e l ' a r c h i t e c t u r e t e c h n ique 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 s s e s e t d ' o b j e t s , et la vue technique qui se préoccupe de la spécification de l ' a r c h i t e c t u r e t e c h n i q u e d u s y s t è 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, simplicité, feedback et courage. No u s a v o n s e s s a y é d ' i n t é g r e r c e s d e r n i e r s p r i n c i p e s d ans notre processus de développement.
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 car a c t é r i s t i q u e s d ' u n p r o c e s s u s UP e t i l e s t b a s é s u r u n e a p p r o che disciplinée focalisée s u r l ' Extreme Programming afin de bien maîtriser, tout au long du cycle de développement du logiciel, l'assignation des tâches et la responsabilisation des différents acteurs 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 c h a n g e me n t s i mp o s é s a u s y s t è me d ' i n f o r ma t i o n: i l s ' a g i t d e l a v u e l o g i q u e o u d e conception qui décrit les aspects statiques et dynamiques du système en termes de classes et d ' o b j e t s et la vue technique qui se préoccupe de la spécification de l ' a r c h i t e c t u r e t e c h n i q u e d u s y s t è me .
Le processus en X est basé sur les deux axiomes suivants: 1) L a s p é c i f i c a t i o n f o n c t i o n n e l l e d e s s y s t è me s d ' i n f o r ma t i o n n ' e s t p a s s u f f i s a n t epour 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 ' i n f o r ma t i o ndoivent tenir compte, en plus des besoins fonctionnels, 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é ».
L a f i g u r e s u i v a n t e p r é s e n t e l e s c h é ma g é n é r a l d u p r o c e s s u s e n X. D' u n c ô t é , l a spécification parallèle des besoins fonctionnels et des contraintes de sécurité et, de l ' a u t r e c ô t é , l a c o n c e p t i o n l o g i q u e e t c e l l e d e l ' a r c h i t e c t u r e t e c h n i q u e d u s y s t è me , q u i donne au processus une forme en X.
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écurit é ) , e t d e s d i a g r a mme s s i mp l e s p o u r v i s u a l i s e r l e c o n t e x t e d u s y s t è me . L ' o b j e c t i f 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é.
Cette phase a pour objectifs de compléter le recueil initial des besoins fonctionnels 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 utilisateurs 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 ' u t i l i s a t i o n e s t l a p i e r r e a n g u l a i r e d e c e t t e é t a p e . E l l e p e r me t d e s p é c i f i e r l ' e n s e mb l e d e s s é q u e n c e s d ' i n t e r a c t i o n s e n t r e l e s y s t è me e t s e s a c t e u r s . C e t t e p h a s e c o n s i s t e a u s s i
Collaboration et validation Fig. 3. Les phases du processus de développement en X à d é c r i r e l a d y n a mi q u e d e s c a s d ' u t i l i s a t i o n e n u t i l i s a n t l e t e x t e e t l e s d i f f é r e n t s mo d èles dynamiques.
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 r i r e l e s s c é n a r i o s c r i t i q u e s à l ' a i d e d e s différents modèles dynamiques, ainsi que l ' i d e n t i f i c a t i o n d e s a t t a q u e s p o s s i b l e s .
Cette phase consiste à coordonner entre les modèles de deux branches de spécification, puis de valider les besoins fonctionnels et les contraintes de sécurité avec le client. Da n s l e c a r d e d ' u n p r o c e s s u s i t é r a t i f , i n c r é me n t a l e t p i l o t é p a r l e s r i s q u e s , c e t t e étape permet aussi de partager le projet en itérations en affectant des niveaux de risq u e à c h a q u e c a s d ' u t i l i s a t i o n e t s e s c o r r e s p o n d a n t s d e s é c u r i t é , e t e n c o mme n ç a n t p a r l e s c a s l e s p l u s c r i t i q u e s e n t e r me s d e g e s t i o n d e p r o j e t a f i n d ' a n n u l e r l e s r i s q u e s d ' é c h e c .
Cette phase décrit les aspects statiques et dynamiques du système en termes de c l a s s e s e t d ' o b j e t s , a i n s i q u e l e s c o l l a b o r a t i o n s e t l e s i n t e r a c t i o n s e n t r e c e s o b j e t s . E l l e 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é.
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.
C e t t e p h a s e c o n s i s t e à i n t é g r e r l e mo d è l e l o g i q u e d a n s l ' a r c h i t e c t u r e t e c h n i q u 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é.
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. L a f i g u r e s u i v a n t e mo n t r e l e s d i f f é r e n t s n i v e a u x d ' a v a n c e me n t d u 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 :
Les « enchaînements de description » consistent à établir une description des cas d ' u t i l i s a t i o n i d e n t i f i é s au n i v e a u p r é c é d e n t , e n p r é s e n t a n t l ' e n s e mb l e d e s i n t e r a c t i o n s entre les acteurs et le système considéré comme une boîte noire. La description des
Codage et recette c a s d ' u t i l i s a t i o n e s t i n d i s p e n s a b l e , c a r e l l e p e r me t de 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érentes exigences de sécurité identifiées au niveau contexte. Les cas de sécurité sont absol u me n t d i s t i n c t s d e s c a s d ' u t i l i s a t i o n; ils ne produisent pas une valeur ajoutée fonctionnelle mais ils recouvrent en effet tous service de sécurité dont un utilisateur bénéficie. Par exemple : As s u r e r l ' a u t h e n t i f i c a t i o n d ' u n utilisateur, As s u r e r l ' i n t é g r i t é et la confidentialité des informations échangées, Assurer la non rép u d i a t i o n d ' u n e 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 s s u r 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 p e r me t t a n t l ' é c h a n g e d e s i n f o r ma t i o n s c r i t i q u e s ( n é c e s s i t e l a c o n f i d e n t i a l i t é e t l ' i n t é g r i t é ) * P o u r l a p h a s e d ' analyse et conception :
Les « classes statiques » sont identifiées à partir des concepts métier extraits des s c é n a r i o s d e d e s c r i p t i o n d e s c a s d ' u t i l i s a t i o n e t d e s s c é n a r i o s c r i t i q u e s . Ces concepts seront e n s u i t e f o r ma l i s é s s o u s f o r me d e c l a s s e s e t d ' a s s o c i a t i o n s r a s s e mb l é e s d a n s u n 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, p a r u n e n s e mb l e d ' o b j e t s . Le niveau « interaction » consiste donc à représenter la collaboration entre ces objets à partir des s c é n a r i o s d é c r i v a n t l ' e x é c u t i o n d e s c a s d ' u t i l i s ation ou de sécurité Le niveau « classe de conception » consiste à optimiser les modèles statiques en affinant les classes, les associations et les attributs, et en ajoutant les opérations identif i é e s g r â c e à l ' a n a l y s e d y n a mi q u e d e s s c é n a r i o s d ' 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é. * P o u r l a p h a s e d ' a r c h i t e c t u r e t e c h n i q u e :
Le niveau « choix technique » permet de spécifier les pré-requis et les stratégies techniques, a i n s i q u e l e s t y l e d ' a r c h i t e c t u r e e n t e n a n t c o mp t e des contextes fonctionnel et de sécurité.
Après la spécification des choix techniques, le niveau « composants d ' e x p l o i t a t i o n» définit la façon dont sera organisé les différents composant du système ( B a s e d e d o n n é e s , S e r v e u r s , Ap p l i c a t i o n s , …) .
Le niveau « spécification matérielle » p e r me t d e d é f i n i r l ' o r g a n i s a t i o n p h y s i q u e e n termes de machines connectées par des moyens divers. En effet, les machines et les connexions sont toutes en r e l a t i o n d i r e c t e a v e c l e s c o mp o s a n t s d ' e x p l o i t a t i o n . L e modèle matériel doit intégrer les dispositions de prévention pour répondre aux contraintes 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épartition des fonctions du système, ainsi que la localisation des composants d ' e x p l o i t a t i o n s u r l e r é s e a u p h y s i q u e .
Le « modèle de données » permet la conception du stockage des données en étudiant 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é.
Après le recueil initial des besoins et la définition des cahiers des charges fonctionnel 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 effet, 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. Ap r è s l ' i d e n t i f i c a t i o n d e s c a s d ' u t i l i s a t i o n e t d e s é c u r i t é , l e c h e f d e p r o j e v a l i d e c e s c a s a v e c l e c l i e n t o u l e s a c t e u r s c o n c e r n é s . S i l ' e n s e mb l e d e s e x i g e nc e s a s s u r é e s p a r l e s c a s d ' u t i l i s a t i o n e t d e s é c u r i t é n e répond pas aux besoins des cah i e r s d e s c h a r g e s , l ' é q u i p e d e s p é cification doit reprendre la spécification et corriger les erreurs. Ap r è s l a v a l i d a t i o n d e s c a s d ' u t i l i s a t i o n e t d e s c a s d e s é c u r i t é d u p a c k a g e métier correspondant à une itération, on devra associer des niveaux de risque à chaque cas. A cet effet, il faudr a c o mme n c e r p a r l e s c a s d ' u t i l i s a t i o n e t d e s é c u r i t é l e s p l u s critiques en termes de gestion de projet afin de lever les risques majeurs. Une fois l ' a f f e c t a t i o n d e s n i v e a u x d e r i s q u e é t a b l i e , o n p r o c è d e a u d é c o u p a g e d u p r o j e t e n i t érations. Chaque itératio n i n c l u t u n e n s e mb l e d e c a s d ' u t i l i s a t i o n e t de cas de sécurité.
La progression de la conception logique et technique est aussi de type itératif. L ' a n a l y s e e t l a c o n c e p t i o n l o g i q u e c o mme n c e n t p a r l ' i d e n t i f i c a t i o n d e s c l a s s e s c a n d idates à partir des cas d' u t i l i s a t i o n d e l a mê me i t é r a t i o n . C e s c l a s s e s s e r o n t e n s u i t e d ét a i l l é e s , c o mp l é t é e s e t o p t i mi s é e s . L e t r a v a i l d ' a f f i n e me n t c o n s i s t e à a j o u t e r , à mo d ifier 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 ' a n a l y s e d y n a mi q u e p o u r l ' a j o u t d e s o p é r a t i o n s . Ap r è s l ' é l a b o r a t i o n d u mo d è l e l o g iq u e d ' u n e i t é r a t i o n , o n s p é c i f i e l ' a r c h i t e c t u r e t e c h n i q u e p e r me t t a n t l ' e x p l o i t a t i o n d e ce modèle. Si le mo d è l e l o g i q u e e t s o n c o r r e s p o n d a n t t e c h n i q u e d ' u n e i t é r a t i o n a t t e ig n e n t l e s o b j e c t i f s f i x é s , o n p a s s e à l ' i mp l é me n t a t i o n . Les taches d ' i n d u s t r i a l i s a t i o n du logiciel concernent la mise en place des moyens et des outils qui vont permettre la livraison (release) d ' u n e itération.
Dé p a r t e me n t d ' I n f o r ma t i q u e , Université d ' Or a n Es-Sénia, Algérie
La phase de spécification des besoins fonctionnels produit des modèles pour le moyen et long terme, a f i n d e c a p i t a l i s e r l e mé t i e r d e l ' e n t r e p r i s e e t l e f o n c t i o n n e me n t d e s o n s y s t è me d ' i n f o r ma t i o n . 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 é c u r i t é s i mp o s é e s a u x s y s t è me s d ' i n f o r ma t i o n a p r è s l a c a p t u r e d e s me n a c e s p r o v enant d e l ' e n v i r o n n e me n t d e l ' e n t r e p r i s e . S i l ' e n v i r o n n e me n t e x i g e d e n o u v e l l e s d o nnes en matière de sécurité, il suffira d ' i n t é g r e r l a s p é c i f i c a t i o n d e s n o u v e l l e s c o n t r a i nt e s d e s é c u r i t é d a n s l e mo d è l e l o g i q u e e t d ' a r c h i t e c t u r e t e c h n i q u e p o u r me t t r e à j o u r l 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' u n autre côté, la phase d' a r c h i t e c t u r e t e c h n i q u e p e r me t d e d é v e l opper 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 é p e n d a n t d e l ' a r c h i t e c t u r e t e c h n i q u e , on peut donc réaliser le même modèle logique en utilisant les différentes technologies dépendantes des mêmes exigences fonctionnelles et de sécurité.
Un processus unifié est un processus de développement logiciel construit sur UML, i l e s t i t é r a t i f e t i n c r é me n t a l , c e n t r é s u r l ' a r c h i t e c t u r e e t p i l o t é p a r l e s e x i g e n c e s d e s u t il i s a t e u r s . L e p r o c e s s u s e n X v é r i f i e l e s c a r a c t é r i s t i q u e s d ' u n p r o c e s s u s u n i f 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.
P o u r c h a q u e c a s d ' u t i l i s a t i o n , o n p r o c è d e à l a d e s c r i p t i o n d e l ' e n s e mb l e d ' i n t e r a c t i o n s e n t r e l e s u t i l i s a t e u r s e t l e s y s t è me . L e s c o n c e p t s u t i l i s é s d a n s c e t t e d e scription mets en évid e n c e l e s d i f f é r e n t e s c l a s s e s e t o b j e t s d u s y s t è me . Da n s l ' a u t r e c ô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 i o n d ' a r c h i t e c t u r e , l e s c h o i x t e c h n i q u e s d o i v e n t ê t r e p i l o t é s p a r l e s b e s o i n s fonctionnels et les contraintes de sécurité. Le modèle de déploiement exprime généralement la répartition physique des fonctions métier sur les différents acteurs. Ce modèle doit prendre en considération les fonctions du système spécifiées par les cas d ' u t i l i s a t i o n p o u r l ' i d e n t i f i c a t i o n d e s p o s t e s d e t r a v a i l , et les contraintes de sécurité pour montrer les conditions de sécurité sur les connexions. La configuration maté-rielle doit i n t é g r e r l e s d i s p o s i t i f s p r é v e n t i f s e t l e s c o mp o s a n t s d ' e x p l o i t a t i o n d o i v e n t satisfaire les exigences fonctionnelles et de sécurité. Le processus en X itératif et incrémental L e c h o i x d ' u n e i t é r a t ion repose sur deux facteurs: -Une itération prend en comp t e u n c e r t a i n n o mb r e d e c a s d ' u t i l i s a t i o net ses correspondants de sécurité -L ' i t é r a t i o n t r a i t e e n p r i o r i t é l e s r i s q u e s ma j e u r s . A c h a q u e i t é r a t i o n , l e s d é v e l o p p e u r s i d e n t i f i e n t e t s p é c i f i e n t l e s c a s d ' u t i l i s a t i o n s e t 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 a s d ' u t i l i s a t i o net aux cas de sécurité. Dè s q u ' u n e i t é r a t i o n r é p o n d a u x o b j e c t i f s fixés, l e d é v e l o p p e me n t p a s s e à l ' i t é r ation suivante.
Dans le cadre de la livraison des parties de système prioritairement demandées, notre 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éd u c t i o n d e s r i s q u e s d ' é c h e c , i l c o n v i e n t d ' a s s o c i e r d e s n i v e a u x d e r i s q u e p o u r c h a q u e c a s d ' u t i l i s a t i o n e t d e s é c u r i t é , afin de commencer par les cas les plus critiques en termes de gestion de projet. Le processus en X centré sur l' a r c h i t e c t u r e L ' a r c h i t e c t u r e d ' u n s y s t è me l o g i c i e l p e u t ê t r e d é c r i t e c o mme l e s d i f f é r e n t e s v u e s d u s y s t è me . L ' a r c h i t e c t u r e « 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.
Extreme Programming est une méthode « Agile » basée sur un ensemble de pratiques destinées à organiser le travail d'une équipe de développement. Plus généralement, les pratiques XP sont sous-tendues par les quatre principes suivants [6] : * La Communication : XP favorise le contact humain, la communication directe, plutô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 feedback sur le déroulement du projet afin de corriger la trajectoire au plus tôt. En particulier, 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 f a b r i q u é e t l a c o n c e p t i o n d e l ' a p p l i c a t i o n . * 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 e p r o c e s s u s e n X me t e n oeu v r e l e s p r a t i q u e s suivantes : Travail en éq u i p e e t l ' i mp l i c a t i o n d u c l i e n t :
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 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ération. Cette réunion se présente comme une réelle séance de travail, qui donne aux différents intervenants l'occasion d'aligner leur compréhension de ce qui doit être réalisé.
Le processus e n X v é r i f i e l e s c a r a c t é r i s t i q u e s d ' u n p r o c e s s u s u n i f i é e t p e r met la mi s e e n oeu v r e d e s d i f f é r e n t e s p r a t i q u e s d e l ' Extreme Programming. Il constitue une trame pour intégrer les meilleures pratiques dans les différents cycles de développement. Ce processus permet une spécification parallèle des besoins fonctionnels et des contraintes de sécurité, a i n s i q u ' une conception parallèle de la vue logique et techniq u e d ' u n s y s t è me . C e d é c o u p a g e f a v o r i s e l e t r a v a i l e n é q u i p e e t r é p o n d a u x b e s o i n s d ' é v o l u t i o n d e s s y s t è me s . L e p r o c e s s u s e n X d é f i n i t u n e b o n n e p o l i t i q u e d ' i t é r a t i o n pilotée par les risques et les priorités du client, a i n s i q u ' u n ebonne tactique de progression définissant les objectifs à atteindre à chaque phase.