3 Le Processus 2TUP
2TUP signifie « 2 Track Unified Process ». C'est un
processus qui répond aux caractéristiques du Processus
Unifié. Le processus 2TUP apporte une réponse aux contraintes de
changement continuel imposées aux systèmes d'information de
l'entreprise. En ce sens, il renforce le contrôle sur les
capacités d'évolution et de correction de tels systèmes.
« 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.
FiGuRE 1 - Le système d'information soumis à deux
types de contraintes
La branche gauche (fonctionnelle) capitalise la connaissance du
métier de l'entreprise. Elle
constitue généralement un investissement pour le
moyen et le long terme. Les fonctions du système d'information sont en
effet indépendantes des technologies utilisées. Cette branche
comporte les étapes suivantes:
- La capture des besoins fonctionnels, qui produit un
modèle des besoins focalisé sur le métier des
utilisateurs.
- L'analyse.
La branche droite (architecture technique) capitalise un savoir
faire technique. Elle consti-
tue un investissement pour le court et moyen terme. Les
techniques développées pour le système peuvent
l'être en effet indépendamment des fonctions à
réaliser. Cette branche comporte les étapes suivantes:
- La capture des besoins techniques.
- La conception générique.
La branche du milieu: à l'issue des évolutions
du modèle fonctionnel et de l'architecture technique, la
réalisation du système consiste à fusionner les
résultats des 2 branches. Cette fusion conduit à l'obtention d'un
processus en forme de Y. Cette branche comporte les étapes suivantes:
- La conception préliminaire.
- La conception détaillée.
- Le codage.
- L'intégration.
FiGuRE 2- Le processus de développement en Y
4 Un processus de modélisation avec UML
Le processus 2TUP s'appuie sur UML tout au long du cycle de
développement, car les différents diagrammes de ce dernier
permettent de part leur facilité et clarté, de bien
modéliser le système à chaque étape.
« Unified Modeling Language »: UML se
définit comme un langage de modélisation graphique et textuel
destiné à comprendre et décrire des besoins,
spécifier, concevoir des solutions et communiquer des points de vue.
(Pitman, 2006)
UML unifie à la fois les notations et les concepts
orientés objet.Il ne s'agit pas d'une simple
notation, mais les concepts transmis par un diagramme ont une
sémantique précise et sont porteurs de sens au même titre
que les mots d'un langage, c'est pour ça qu'UML est
présenté parfois comme une méthode alors qu'il ne l'est
absolument pas.
UML unifie également les notations nécessaires aux
différentes activités d'un processus de développement et
offre, par ce biais, le moyen d'établir le suivi des décisions
prises, depuis la définition des besoins jusqu'au codage. (Roques,
2006)
Voici une présentation rapide des différents
diagrammes UML qui vont être utilisés tout au long du projet :
- Le diagramme des cas d'utilisation : représente la
structure des fonctionnalités nécessaires aux utilisateurs du
système. Il est normalement utilisé lors des étapes de
capture des besoins fonctionnels et techniques.
- Le diagramme d'activités : représente les
règles d'enchaînement des activités et actions dans le
système. Il peut être assimilé comme un algorithme mais
schématisé.
- Le diagramme de packages : présent depuis UML 2.0,
ce diagramme modélise des catégories cohérentes entre
elles, pour un souci de partage des rôles. Correspond à
l'étape de modélisation des différents scénarios
d'un cas d'utilisation.
- Le diagramme de classes : sûrement l'un des
diagrammes les plus importants dans un développement orienté
objet. Sur la branche fonctionnelle, ce diagramme est prévu pour
développer la structure des entités manipulées par les
utilisateurs. En conception, le diagramme de classes représente la
structure d'un code orienté objet.
- Le diagramme de séquence : représente les
échanges de messages entre objets, dans le cadre d'un fonctionnement
particulier du système.
- Le diagramme d'états : représente le cycle de
vie d'un objet. Il spécifie les états possibles d'une classe et
leur enchainement. Ce diagramme est utilisé lors des étapes
d'analyse et de conception.
Répartition des tâches
|
Tâches
|
Tâches Partielles
|
Durée
|
Bentatou
|
Sahraoui
|
Errami
|
Bedjaoui
|
Durée Totale
|
|
Etude préliminaire
|
Cahier de charge
|
8
|
V
|
V
|
|
|
15
|
|
Messages / Acteurs
|
4
|
|
|
V
|
|
|
Modelisation contexte
|
3
|
|
|
|
V
|
|
Capture des besoins fonctionnels
|
Identifier C.U
|
6
|
|
V
|
|
|
17
|
|
Organiser C.U
|
5
|
|
|
V
|
V
|
|
Identifier C.C
|
6
|
V
|
|
|
|
|
Capture des besoins techniques
|
'
·
|
0
|
x
|
x
|
x
|
x
|
0
|
|
Découpage en catégories
|
. .
|
1
|
V
|
V
|
V
|
V
|
1
|
|
Developpement du M.S
|
'
·
|
7
|
V
|
|
V
|
|
7
|
|
Developpement du M.D
|
' .
|
10
|
|
V
|
|
V
|
10
|
|
Prototype
|
' .
|
12
|
V
|
V
|
|
|
12
|
| 
