Notre approche projet : le Processus Unifié

Afin de répondre au mieux aux exigences fonctionnelles, nous utilisons une instance du Processus Unifié, avec des livraisons successives de versions de l'application. Les motivations et le principe de fonctionnement sont résumés ci-dessous.

L'ossature du Processus Unifié s'exprime ainsi :

• Cycle fortement itératif (livraison possible du projet partiel toutes les deux semaines pour maximiser les feedbacks fonctionnels et/ou techniques du client)
• Pilotage du planning par la réduction des risques fonctionnels et techniques (on planifie les tâches les plus risquées au plus tôt dans le projet)
• Processus centré sur l'architecture (construction en début de projet d'une architecture exécutable, progressivement enrichie par les fonctionnalités du système)
• Modélisation visuelle du système UML (cas d'utilisation, diagrammes dynamiques et statiques), garante d'une bonne traçabilité depuis le cahier des charges jusqu'au code et génératrice de gain de temps pour la conception et l'implémentation
• Vérification continue de la qualité du système (conséquence directe de la livraison itérative)

Le schéma suivant positionne les activités au cours du projet.

Activités au cours du projet

Dans le processus unifié, les deux branches de départ (fonctionnelle et architecture) sont des branches de réduction des risques.

A l'issue de ces étapes, la production de la conception et du code se base d'une part sur un ensemble fonctionnel et ergonomique maîtrisé (bien que sujet à modifications pendant les itérations), et une architecture complètement spécifiée et exécutable (production du prototype d'architecture).

Plus précisément, le Y d'ensemble est découpé en n itérations, de la façon suivante :

Enchainement des itérations

• Chaque petit Y traite un sous-ensemble de chaque activité du Y global (analyse partielle, architecture partielle, codage partiel ...), sur un sous-ensemble fonctionnel (UC = Use-Case = cas d'utilisation du logiciel), comme le montre le diagramme ci-dessous
• Chaque petit Y conduit à la livraison d'une version de la documentation utilisateur, du cahier de recette, des modèles d'analyse, et surtout d'une version installable et exécutable du produit, sur le sous-ensemble fonctionnel couvert par l'itération
• Le premier Y possède des caractéristiques particulières : analyse fonctionnelle en largeur d'abord (sur l'ensemble du fonctionnel, avec une granularité forte), et analyse fonctionnelle détaillée sur un à deux use-cases seulement, élus pour leur impact sur l'ensemble de l'architecture ; branche architecture particulièrement importante en charge (elle structure les développements des itérations suivantes) ; activité de mise en place des plateformes d'intégration et déploiement importante également.

Afin de garantir l'adéquation au besoin, chaque itération intègre une étape de validation des modèles avec les équipes du client au cours de réunions de travail.

Les points clés du fonctionnement

Notre expérience sur de nombreux projets exploitant le Processus Unifié a démontré qu'il permet une grande maîtrise technique des phases de codage, d'intégration et de déploiement, une bonne maîtrise du planning et enfin une convergence rapide de l'application vers les réels besoins des clients. Ces bénéfices sont obtenus au prix d'un ensemble de contraintes qu'il convient d'énumérer :

• La disponibilité des représentants des utilisateurs et leur réactivité à chaque livraison d'une version du produit.
• Une convergence entre maîtrise d'ouvrage et maîtrise d'oeuvre sur les grands choix techniques (plateforme, langage, architecture technique, connexion aux systèmes externes), qui doit intervenir très tôt dans le projet : ces choix conditionnent la mise en oeuvre de la plateforme d'intégration et déploiement, dont il est essentiel qu'elle soit à disposition dès la première itération.
• La collaboration de la maîtrise d'ouvrage, suite aux livraisons, pour dissocier les demandes d'évolution qui entrent dans le cadre du processus itératif, versus celles qui correspondent à un écart manifeste vis à vis du périmètre initial.
• La sensibilisation des utilisateurs à l'importance de la convergence rapide de l'ergonomie et des cas d'utilisation du logiciel vers la cible que représente le produit final (les remises en cause font partie du déroulement normal d'un cycle itératif, cependant une oscillation permanente des demandes de modification est une cause d'échec dans le respect de la charge ou des délais).