Une introduction aux processus unifiés

La complexité croissante des systèmes informatiques a conduit les concepteurs à s’intéresser aux méthodes. Bien que ce phénomène ait plus de 30 ans, nous ne pouvons constater aujourd’hui l’existence d’une règle qui soit à la fois très formelle et commune aux différentes cultures. On a par exemple comptabilisé en 1994 jusqu’à 50 méthodes objets différentes. Chaque méthode se définit par une notation et un processus spécifique, mais la plupart convergent en ce qui concerne la sémantique de leur notation. Néanmoins le travail de définition d’un processus est toujours resté vague et succinct. UML a ouvert le terrain de l’unification en fusionnant les notations et en apportant précision et rigueur à la définition des concepts introduits. L’introduction d’UML a apporté un élan sans précédent à la technologie objet, puisqu’elle y propose un standard de niveau industriel. Il reste cependant à définir le processus pour réellement capitaliser des règles dans le domaine du développement logiciel. Définir un seul processus universel serait une grave erreur car la variété des systèmes et des techniques ne le permet pas. Dans la lancée d’UML, les 3 amigos1 ont donc travaillé à unifier non pas les processus, mais plus exactement les meilleures pratiques de développement orienté objet. Le résultat de ces travaux est actuellement disponible dans [Jacobson 99] et [Kruchten 03] et surtout dans le produit commercial RUP de IBM/Rational. 1. Dénomination de Grady Booch, James Rumbaugh, et Ivar Jacobson qui sont les « pères » d’UML. Processus et architecture 12 UML en action Le processus unifié doit donc être compris comme une trame commune des meilleures pratiques de développement, et non comme l’ultime tentative d’élaborer un processus universel. La définition d’un processus UP est donc constituée de plusieurs disciplines d’activité de production et de contrôle de cette production. Tout processus UP répond aux caractéristiques ci-après. • Il est itératif et incrémental. La définition d’itérations de réalisation est en effet la meilleure pratique de gestion des risques d’ordre à la fois technique et fonctionnel. On peut estimer qu’un projet qui ne produit rien d’exécutable dans les 9 mois court un risque majeur d’échec. Chaque itération garantit que les équipes sont capables d’intégrer l’environnement technique pour développer un produit final et fournit aux utilisateurs un résultat tangible de leurs spécifications. Le suivi des itérations constitue par ailleurs un excellent contrôle des coûts et des délais.

PROCESSUS DE DÉVELOPPEMENT LOGICIEL

Un processus définit une séquence d’étapes, en partie 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. En conséquence, le processus peut se décomposer suivant deux axes de contrôle sur le développement : • l’axe de développement technique, qui se concentre principalement sur la qualité de la production ; • l’axe de gestion du développement, qui permet la mesure et la prévision des coûts et des délais. Nous ne traitons pas cet aspect dans « UML en Action… »

Le processus 2TUP

2TUP signifie « 2 Track Unified Process ».C’est un processus UP qui répond aux caractéristiques que nous venons de citer. 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 informatique. Figure 2-1 : Le système d’information soumis à deux natures de contraintes L’axiome fondateur du 2TUP consiste à constater que toute évolution imposée au système d’information peut se décomposer et se traiter parallèlement, 14 UML en action suivant un axe fonctionnel et un axe technique. Pour illustrer cet axiome, prenons les trois exemples suivants : 1. une agence de tourisme passe des accords avec une compagnie aérienne de sorte que le calcul des commissions change. En l’occurrence, les résultats issus de la branche fonctionnelle qui évoluent pour prendre en compte la nouvelle spécification ; 2. cette même entreprise décide d’ouvrir la prise de commande sur le Web. Si rien ne change fonctionnellement, en revanche, l’architecture technique du système évolue ; 3. cette entreprise décide finalement de partager son catalogue de prestations avec les vols de la compagnie aérienne. D’une part, la fusion des deux sources d’informations imposera une évolution de la branche fonctionnelle, d’autre part, les moyens techniques de synchronisation des deux systèmes conduiront à étoffer l’architecture technique du système. L’étude de ces évolutions pourra être menée indépendamment, suivant les deux branches du 2TUP. À 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 deux branches. Cette fusion conduit à l’obtention d’un processus de développement en forme de Y, comme illustré par la figure 2-2. Figure 2-2 : Le processus de développement en Y La branche gauche (fonctionnelle) comporte : • la capture des besoins fonctionnels, qui produit un modèle des besoins focalisé sur le métier des utilisateurs. Elle qualifie au plus tôt le risque de produire un système inadapté aux utilisateurs. De son côté, la maîtrise d’œuvre consolide les spécifications et en vérifie la cohérence et l’exhaustivité l’analyse, qui consiste à étudier précisément la spécification fonc- Chapitre 2 • Processus et architecture 15 tionnelle 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 droite (architecture 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 des prérequis d’architecture technique ; • la conception générique, qui définit ensuite les composants nécessaires à la construction de l’architecture technique. Cette conception est la moins dépendante possible 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 et écarte la plupart des risques de niveau technique. 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 elle intègre le modèle d’analyse dans l’architecture technique de manière à tracer la 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é. L’ensemble de ces étapes de développement sera illustré tout au long de cet ouvrage par la mise en application du processus 2TUP à l’étude de cas SIVEx. Seules les deux dernières étapes, ne relevant pas de l’utilisation d’UML, ne seront pas abordées dans cet ouvrage.