I.3. Considération théorique
Comme nous l'avons ci-haut annoncé, nous utilisons la
démarche UP (UnifiedProcess). Dans cette partie, nous expliquons plus ou
moins tout sur cette démarche.
I.3.1. Présentation d'UP
Le Processus Unifié (UP, pour UnifiedProcess) est un
processus de développement logiciel "itératif et
incrémental", centré sur l'architecture, conduit par les cas
d'utilisation et piloté par les risques :
· Itératif et incrémental
: Le projet est découpé en itérations de courte
durée (environ 1 mois) qui aident à mieux suivre l'avancement
global. A la fin de chaque itération, une partie exécutable du
système final est produite, de façon incrémentale.
Un processus définit une séquence
d'étapes, partiellement ordonnées, qui concourent à
l'obtention d'un système logiciel ou à l'évolution d'un
système existant. L'objet d'un processus de développement est de
produire des logiciels de qualité qui répondent aux besoins de
leurs utilisateurs dans des temps et des coûts prévisibles.
Plus simplement, un processus doit permettre de
répondre à la question fondamentale : ?Qui fait quoi et quand
??.
· Centré sur l'architecture :
tout système complexe doit être décomposé en parties
modulaires afin de garantir une maintenance et une évolution
facilitées. Cette architecture (fonctionnelle, logique,
matérielle, etc.) doit être modélisée en UML et pas
seulement documentée en texte.
· Piloté par les risques : les
risques majeurs du projet doivent être identifiés au plus
tôt, mais surtout levés le plus rapidement possible. Les mesures
à prendre dans ce cadre déterminent l'ordre des
itérations.
· Conduit par les cas d'utilisation :
le projet est mené en tenant compte des besoins et des exigences des
utilisateurs. Les cas d'utilisation du futur système sont
identifiés, décrits avec précision et priorisés.
- 13 -
I.3.2 Les phases et les disciplines d'UP
La gestion d'un tel processus est organisée suivant
les quatre phases suivantes : initialisation, élaboration, construction
et transition.
La phase d'initialisation conduit à définir la
« vision » du projet, sa portée, sa faisabilité, son
business case, afin de pouvoir décider au mieux de sa poursuite ou de
son arrêt. La phase d'élaboration poursuit trois objectifs
principaux en parallèle :
· identifier et décrire la majeure partie de besoins
des utilisateurs,
· construire (et pas seulement décrire dans un
document !) l'architecture de base du système,
· lever les risques majeurs du projet.
La phase de construction consiste surtout à concevoir
et implémenter l'ensemble des éléments
opérationnels (autres que ceux de l'architecture de base). C'est la
phase la plus consommatrice en ressources et en effort.
Enfin, la phase de transition permet de faire passer le
système informatique des mains des développeurs à celles
des utilisateurs finaux. Les mots-clés sont : conversion des
données, formation des utilisateurs, déploiement,
béta-tests. Chaque phase est elle-même décomposée
séquentiellement en itérations limitées dans le temps
(entre 2 et 4 semaines). Le résultat de chacune d'elles est un
système testé, intégré et exécutable.
L'approche itérative est fondée sur la croissance et l'affinement
successifs d'un système par le biais d'itérations multiples,
feedback et adaptation cycliques étant les moteurs principaux permettant
de converger vers un système satisfaisant. Le système croît
avec le temps de façon incrémentale, itération par
itération, et c'est pourquoi cette méthode porte également
le nom de développement itératif et incrémental.
Les activités de développement sont
définies par cinq disciplines fondamentales qui décrivent la
capture des exigences, l'analyse et la conception, l'implémentation, le
test et le déploiement. La modélisation métier est une
discipline amont optionnelle et transverse aux projets. Enfin, trois
disciplines appelées de support complètent le tableau : gestion
de projet, gestion du changement et de la configuration, ainsi que la mise
à disposition d'un environnement complet de développement
incluant aussi bien des outils informatiques que des documents et des guides
méthodologiques.
14Pascal Roques, Franck Vallée, UML2 en
action. De l'analyse des besoins à la conception. , Ed. Eyrolles,
4ème édition, page 12
- 14 -
UP doit donc être compris comme une trame commune des
meilleures pratiques de développement logiciel, et non comme l'ultime
tentative d'élaborer un processus universel.
Pascal Roques et Franck Vallée14 disent que
le processus de développement logiciel UP a été construit
sur le langage de modélisation UML (UnifiedModelingLanguage).
| 
