SECTION 2 : CADRE
METHODOLOGIQUE
I.2.1. Processus unifié
Le processus unifié est un processus de
développement logiciel itératif, centré sur
l'architecture, piloté par des cas d'utilisation et orienté vers
la diminution des risques. C'est un patron de processus pouvant être
adapté à une large classe de systèmes logiciels, à
différents domaines d'application, à différents types
d'entreprises, à différents niveaux de compétences et
à différentes tailles de l'entreprise.[4]
Un processus unifié se distingue par ses
caractéristiques suivantes :
? Itératif : le logiciel nécessite une
compréhension progressive du problème à travers des
raffinements successifs et permet de développer une solution effective
de façon incrémentale par des itérations multiples.
? Piloté par les risques : les causes majeures
d'échec d'un projet logiciel doivent être écartées
en priorité.
? Centré sur l'architecture : le choix de
l'architecture logicielle est effectué lors des premières phases
de développement du logiciel. La conception des composants du
système est basée sur ce choix.
? Conduit par les cas d'utilisation : le processus est
orienté par les besoins utilisateurs représentés par des
cas d'utilisation. Les activités de modélisation reposent sur
UML. Ce langage de modélisation couvre les aspects structurels et
dynamiques de l'architecture et de la conception des logiciels. Il facilite une
modélisation par composants en utilisant une approche orientée
objet.
Dans la communauté objet, il existe plusieurs
processus unifiés en vogue comme eXtreme Programming (XP) et Rational
Unified Process (RUP). Dans notre étude, on a choisi de travailler avec
le processus 2TUP ; parce qu'il couvre des projets de toute taille et il a pu
faire une large place dans le domaine de la technologie et les risques des
projets.[1]
I.2.2. Processus 2TUP
« 2 Track » signifie littéralement que le
processus suit deux chemins. Il s'agit des « chemins fonctionnels »
et « d'architecture technique », qui correspondent aux deux axes de
changement imposés au système d'information.
Le 2TUP propose un cycle de développement en Y, qui
dissocie les aspects techniques des aspects fonctionnels. Il commence par une
étude préliminaire qui consiste essentiellement à
identifier les acteurs qui vont interagir avec le système à
construire, les messages qu'échangent les acteurs et le système,
à produire le cahier des charges et à modéliser le
contexte (le système est une boîte noire, les acteurs l'entourent
et sont reliés à lui, sur l'axe qui lie un acteur au
système on met les messages que les deux s'échangent avec le
sens).
Le processus s'articule ensuite autour de trois phases
essentielles :
? une branche technique ;
? une branche fonctionnelle ;
? une phase de réalisation.
La branche fonctionnelle comporte :
· la capture des besoins fonctionnels, qui produit un
modèle des besoins focalisé sur le métier des
utilisateurs. Cette capture des besoins permet d'éviter au plus
tôt le risque de produire un système inadapté aux
utilisateurs.
· l'analyse, qui consiste à étudier
précisément la spécification fonctionnelle de
manière à obtenir une idée de ce que va réaliser le
système en termes de métier. Les résultats de l'analyse ne
dépendent d'aucune technologie particulière.
La branche technique comporte :
· la capture des besoins techniques, qui recense
toutes les contraintes et les choix dimensionnant la conception du
système. Les outils et les matériels sélectionnés
ainsi que la prise en compte de contraintes d'intégration avec
l'existant conditionnent généralement cette capture ;
· la conception générique, qui
définit ensuite les composants nécessaires à la
construction de l'architecture technique. Cette conception est
complètement indépendante des aspects fonctionnels. Elle a pour
objectif d'uniformiser et de réutiliser les mêmes
mécanismes pour tout un système. L'architecture technique
construit le squelette du système informatique. L'importance de sa
réussite est telle qu'il est conseillé de réaliser un
prototype pour assurer sa validité.
La branche du milieu comporte :
· la conception préliminaire, qui
représente une étape délicate, car elleintègre le
modèle d'analyse dans l'architecture technique de manière
à tracerla cartographie des composants du système à
développer ;
· la conception détaillée, qui
étudie ensuite comment réaliser chaque composant ;
· l'étape de codage, qui produit ces
composants et teste au fur et à mesure les unités de code
réalisées ;
· l'étape de recette, qui consiste enfin
à valider les fonctions du système développé.
| 
