Rational Unified Process

Transcription

1 Rational Unified Process For Christiane DAVOINE-GUHUR Société GICAB - Vannes [email protected]

2 Table des Matières 1 INTRODUCTION LES COMPOSANTS ET LES GRANDS PRINCIPES DU PROCESSUS Les composants du produit RUP Le pilotage par les cas d utilisation Définition Les flots des événements d un cas d utilisation Les cas d utilisation dans le processus de développement Exemple de cas d utilisation «Retirer de l argent» Le processus centré sur l architecture Importance des modèles et de l architecture Définition de l architecture Représentation de l architecture par le modèle à 4+1 vues Architecture et conception architecturale Exemple sur le cas d utilisation «Retirer de l argent» Le processus Itératif et Incrémental Qu est-ce qu une itération? La dimension statique du processus La dimension dynamique du processus LES ENCHAÎNEMENTS D ACTIVITÉS DU PROCESSUS La modélisation métier Pourquoi modéliser le métier? Comment modéliser le métier? Les enchaînements d activités Les outils de modélisation métier La gestion des exigences Définitions Comment exprimer les exigences? Conception de l interface utilisateur Enchaînements d activités Les outils pour la gestion des exigences Exemple des exigences pour le cas d utilisation «Retirer de l argent» L analyse et la conception Objectif Travailleurs et artefacts Enchaînements d activités Exemple d analyse du cas d utilisation «Retirer de l argent» Les outils pour l analyse et la conception L implémentation Objectifs Les activités d implémentation Les types de prototypes Les outils pour l implémentation Les tests Les objectifs Le rôle des tests dans le cycle de vie du logiciel Les travailleurs et artefacts Exemple de tests pour le cas d utilisation «retirer de l argent» Les types de tests Les outils de tests Christiane DAVOINE GUHUR 02/05/02

3 3.6 La gestion de configuration Les objectifs Les définitions Les travailleurs et les artefacts Les enchaînements d activités Les outils support de la gestion de configuration Le déploiement Les objectifs Les travailleurs et les artefacts Exemple de configuration pour le cas d utilisation «Retirer de l argent» Les enchaînements d activités LES ENCHAÎNEMENTS D ITÉRATION, RÔLE DES TRAVAILLEURS DANS LE DÉVELOPPEMENT D UN PROJET AVEC RUP Exemple : Définir la vision du produit Exemple : Construire un prototype architectural Exemple : Implémenter le système Cartographie des enchaînements d activités d un développement de projet avec RUP CONCLUSION BIBLIOGRAPHIE... 1 Christiane DAVOINE GUHUR 02/05/02

4 Table des illustrations Figure 1 : RUP, Les composants Figure 2 : Les cas d'utilisation, la description fonctionnelle des objets[lopez, et al 1998]... 3 Figure 3 : Cas d'utilisation retirer de l'argent[jacobson, et al 1999]... 4 Figure 4 : Les cas d utilisation à travers les différents modèles[kruchten 2000]... 4 Figure 5 : Cas d utilisation retirer de l argent... 5 Figure 6 : Modèle d'analyse "retirer de l'argent"... 6 Figure 7 : Le modèle d architecture à 4+1 vues[int2] Figure 8 : Structure statique de la vue architecturale du modèle de conception pour le système DAB... 9 Figure 9 : diagramme de collaboration du système DAB[Jacobson, et al 1999]... 9 Figure 10 : Le modèle de déploiement du système DAB[Jacobson, et al 1999] Figure 11 : La vue architecturale du modèle de déploiement[jacobson, et al 1999] Figure 12 : Une approche itérative au développement[int1] Figure 13 : Travailleurs, activités et artefacts [Kruchten 2000] Figure 14 : Exemple d enchaînement d activités [Kruchten 2000] Figure 15 : Les quatre phases et jalons du processus itératif[kruchten 2000] Figure 16 : D un cycle de vie séquentiel à un cycle de vie itératif [Kruchten 2000] Figure 17 : Les neufs principaux enchaînements d activités du processus [Kruchten 2000] Figure 18 : Travailleurs et artefacts dans les activités de modélisation métier.[kruchten 2000] Figure 19 : Des modèles métier aux modèles systèmes[kruchten 2000] Figure 20 : Un enchaînement d'activités de modélisation métier.[kruchten 2000] Figure 21 : Différents artefacts de l'ensemble des exigences et leurs relations avec d'autres artefacts[kruchten 2000] Figure 22 : Travailleurs et artefacts dans l'enchaînement des activités de gestion[kruchten 2000] Figure 23 : Enchaînement des activités de gestion des exigences [Kruchten 2000] Figure 24 : comparaison des modèles des cas d'utilisation et d'analyse[jacobson, et al 1999] Figure 25 : Un enchaînement des activités d'analyse et de conception[kruchten 2000] Figure 26 : identification de paquetages d'analyse généraux à partir des classes du domaine[jacobson, et al 1999] Figure 27 : paquetages de services «comptes et de risques» encapsulant chacun des classes fonctionnellement liées[jacobson, et al 1999] Figure 28 : Enchaînement d'activités d'implémentation Figure 29 : point de convergence de l'implémentation [Jacobson, et al 1999] Figure 30 : Travailleurs et artefacts impliqués dans les tests [Jacobson, et al 1999] Figure 31 : Modèle de tests [Jacobson, et al 1999] Figure 32 : Cas, procédures et scripts de test pour un terminal bancaire [Kruchten 2000] Figure 33 : Le cube CCM [Kruchten 2000] Figure 34 : Travailleurs et artefacts dans l'activité de déploiement [Jacobson, et al 1999] Figure 35 : Modèle de déploiement du Cas DAB[Jacobson, et al 1999] Figure 36 : Enchaînement d'activités de l'itération générique [Jacobson, et al 1999] Figure 37 : Répartition du temps de planification par phase [Jacobson, et al 1999] Figure 38 : les "patatoï des" tracées à la main regroupent les principales activités de la phase création Figure 39 : La "patatoï de" tracée à la main regroupe les principalement activités de la phase création[jacobson, et al 1999] Figure 40 : Cartographie d'un projet développé avec RUP[Jacobson, et al 1999] Figure 41 : L'approche typique pour mettre en place un processus et les outils [Jacobson, et al 1999] Christiane DAVOINE GUHUR 02/05/02

5 Préambule «Le Rational Unified Process est un processus de génie logiciel développé et commercialisé par la société Rational Software. Il permet d affecter et de gérer de manière rigoureuse et disciplinée les tâches et les responsabilités au sein d une organisation de développement...»[kruchten 2000] «Le processus unifié a précisément pour but de spécifier les différentes phases d un projet, de l élaboration du cahier des charges au déploiement de l application. Il est le complément idéal du standard UML qui est un langage de modélisation graphique, dont la vocation n est pas de couvrir tous les aspects du génie logiciel.»[jacobson, et al 1999] On remarque dans ces deux citations que RUP 1 est une démarche de développement génie logiciel et dans la deuxième de ces citations l utilisation de sigle UML 2. De fait, la découverte de RUP suppose des pré-requis de modélisation objet et d UML. On considère dans cette bibliographie que ces deux points sont acquis, il n y aura pas de présentation d UML, ni de l approche objet. RUP est un outil de modélisation UML, ses possibilités sont très étendues et sont décrites dans 3200 pages de la documentation de référence de Rational. L objectif de cette bibliographie n est donc pas d être exhaustif. Les chapitres suivants fourniront au lecteur les points importants. Ils porteront sur une présentation de RUP qui sera découpée en trois parties, 1. Le processus, ses composants et ses grands principes 2. Les principaux enchaînements d activité qui composent chaque itération du processus, 3. Les enchaînements d itération, le rôle des travailleurs dans le développement d un projet avec RUP. Les références citées permettront une étude approfondie de ce vaste sujet. Afin de rendre la lecture de cette bibliographie plus agréable, le même exemple servira de fil rouge, tout au long de ces pages, il s agit d un client bancaire qui effectue un retrait d argent sur un automate bancaire. Les références aux ouvrages, sites, documents consultés sont indiqués par une référence entre crochet par exemple [Jacobson, et al 1999]. 1 RUP : Rational Unified Process 2 UML : Unified Modeling Language Christiane DAVOINE GUHUR 02/05/02

6 1 INTRODUCTION RUP est le Rational Unified Process, c est un processus commercial, un produit développé et maintenu par la société Rational Software. Il contient des directives et des conseils sur les techniques modernes pour le développement logiciel. Ce produit est une source de connaissances, toujours à jour, accessible à partir du poste de travail du développeur. Il est parfaitement intégré à l ensemble des outils de développement proposés par la société. Rational Unified Process est aussi un cadre de processus (Process framework), pour une organisation qui l adopte. Cette dernière peut l adapter et l étendre en fonction de ses besoins [Kruchten 2000]. Pour développer des systèmes logiciels modernes, l expérience a mis en évidence six meilleures pratiques à respecter. En les combinant, on s attaque aux causes profondes des problèmes de développement logiciel [INT3]. Les meilleures pratiques pour le développement de logiciel moderne respectent les points suivants : - Développer le logiciel de manière itérative, - Gérer les exigences, - Utiliser des architectures à base de composants, - Modéliser graphiquement le logiciel, - Vérifier la qualité du logiciel, - Contrôler les changements apportés au logiciel. RUP présente ces meilleures pratiques sous une forme adaptée à un grand nombre de projets et d organisations, comme nous allons le découvrir dans la suite de ce document en abordant : les composants et les principes du processus, les principaux enchaînements d activités et le rôle des travailleurs dans le développement d un projet avec le processus unifié. 2 LES COMPOSANTS ET LES GRANDS PRINCIPES DU PROCESSUS 2.1 LES COMPOSANTS DU PRODUIT RUP RUP ne ressemble en rien à la documentation des productions classiques de méthodes de développements qui fournissaient des étagères de classeurs. Ce produit présente les atouts suivants : - Il publie les mises à jour de manière régulière, - Il utilise la technologie du Web, le mettant à portée de souris des développeurs, - Une organisation peut aisément l adapter pour ses besoins, - Il est intégré à un grand nombre d outils de développement logiciel de Rational, de sorte que les développeurs peuvent accéder aux recommandations du processus à partir de l outil qu ils utilisent. Le produit en ligne permet d accéder via intranet : - A la version la plus récente, - Aux informations clés du processus, moteur de recherche, index, table des matières dynamiques, - Aux références externes (comme UML) ou d activer directement l outil ou une tâche. Christiane DAVOINE GUHUR Page /05/02

7 Le produit RUP comprend : - Un CD-Rom qui contient la description de tous les éléments du RUP (tâches, activités, recommandations, procédures et exemples), sous forme d un site Web que l usager installe sur sa machine, où sur un serveur de l entreprise, - Le manuel d introduction RUP en ligne propose : - Des guides d utilisation d outils qui établissent des ponts entre les processus et les outils de développement du logiciel et donnent des conseils supplémentaires sur leur usage. Il y a par exemple des guides pour Rational Rose qui aide à la modélisation graphique ou ClearCase qui facilite la gestion de configuration. - Des canevas (templates) pour tous les artefacts importants du processus quel que soit l outil utilisé pour les créer et les gérer. On trouve ainsi : - Rational Rose pour l aide à la modélisation, - Rational SoDA pour automatiser la documentation du logiciel, - RequisitePro pour gérer le cahier des charges, - Adobe FrameMaker et Microsoft Word pour créer la plupart des documents classiques, - ClearCase qui facilite la gestion de configuration, - Microsoft Project pour planifier le processus, - Microsoft FrontPage pour étendre RUP lui-même [Rational, 2000]. Figure 1 : RUP, Les composants. Avant toute chose, le Processus Unifié est un processus de développement logiciel, c est-àdire qu il regroupe les activités à mener pour transformer les besoins d un utilisateur en système logiciel. Mais c est plus qu un simple processus, c est un framework de processus génériques 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étence et à différentes tailles d entreprises. Le Processus Unifié utilise le langage UML pour la création des plans d élaboration et de construction du système logiciel. En fait UML fait partie intégrante du Processus Unifié : l un et l autre ont été développés en parallèle. Néanmoins, les traits distinctifs du Processus unifié tiennent en trois expressions clés : - piloté par les cas d utilisation, - centré sur l architecture, - itératif et incrémental. Voilà ce qui fait toute l originalité du Processus unifié [Jacobson, et al 1999]. Christiane DAVOINE GUHUR Page /05/02

8 2.2 LE PILOTAGE PAR LES CAS D UTILISATION Les cas d utilisation constituent le concept principal de la méthode OOSE de Ivar Jacobson, un des pères d UML. Dans le processus de standardisation des méthodes objet ayant abouti au formalisme UML, le concept des «use cases», cas d utilisation en français, a été repris dans le but d effectuer une bonne délimitation du système et d améliorer la compréhension de son fonctionnement. Figure 2 : Les cas d'utilisation, la description fonctionnelle des objets [Lopez, et al 1998]. Les cas d utilisation représentent le moyen de décrire le caractère fonctionnel des objets. Il se positionne sur trois axes : - La description des objets, leurs propriétés et leurs attributs. Elle représente la vue statique de l objet, - L identification des états et des événements. Elle représente la vue dynamique de l objet, - La traduction du savoir-faire et du métier. Elle met en évidence les exigences, les règles fonctionnelles liées au métier [Lopez, et al 1998] Définition Les cas d utilisation sont un moyen d exprimer les exigences fonctionnelles du système. RUP définit les concepts de cas d utilisation et d acteur de la façon suivante : - Un cas d utilisation est une séquence d actions que réalise un système et qui fournit un résultat observable ayant une valeur pour un acteur particulier. - Un acteur est quelqu un ou quelque chose se situant à l extérieur du système et qui interagit avec lui. Il y a dans ces définitions plusieurs notions importantes : - Action : il s agit d une procédure de traitement quand un acteur envoie un signal au système ou qu un système est activé à l échéance d une temporisation. - Une séquence d actions : la séquence dont parle la définition est un flot spécifique d événements. - Un résultat observable ayant une valeur : une séquence d actions fournit un résultat utile à un acteur du système. On garantit ainsi que le cas d utilisation est pertinent et exprimé à un niveau de granularité que comprend l utilisateur [Kruchten 2000]. Christiane DAVOINE GUHUR Page /05/02

9 Figure 3 : Cas d'utilisation retirer de l'argent [Jacobson, et al 1999]. La description d un cas d utilisation rend compte de ce qui se passe dans le système quand le cas d utilisation se réalise. La fonctionnalité complète est définie par un ensemble de cas d utilisation, chacun d eux représentant un flot spécifique d événements Les flots des événements d un cas d utilisation Du point de vue des activités de gestion des exigences, l élément le plus important de la description d un cas d utilisation est le flot d événements. Un flot décrit une séquence d actions en langage naturel, dans une prose simple et précise [Jacobson, et al 1999] Les cas d utilisation dans le processus de développement RUP est une approche pilotée par les cas d utilisation, cela signifie qu ils servent de base au processus complet de développement. Figure 4 : Les cas d utilisation à travers les différents modèles [Kruchten 2000]. Le modèle de cas d utilisation est le résultat de l enchaînement des activités de gestion des exigences. Durant les activités d analyse et de conception, on se sert du modèle de cas d utilisation pour créer le modèle de conception. On décrit comment les cas d utilisation se réalisent en termes d interactions entre les objets du modèle de conception. On exploite les réalisations des cas d utilisation pour comprendre la dynamique du système et optimiser les performances. Pendant les tests, on recourt aux cas d utilisation pour identifier et organiser des cas et procédures de test. Comme les cas d utilisation décrivent la façon dont un acteur interagit avec le système, ils constituent une base idéale pour la rédaction des manuels utilisateurs. Ils servent également au chef de projet qui peut définir les contenus et les objectifs des itérations. Christiane DAVOINE GUHUR Page /05/02

10 Pour faire évoluer les cas d utilisation, on commence par développer un squelette de cas d utilisation avant d approfondir sa description. Au cours des premières itérations de la phase d élaboration, seuls les cas d utilisation sont décrits en détail Exemple de cas d utilisation «Retirer de l argent». Parmi les cas d utilisation fréquemment rencontrer sur les DAB 3, on retiendra le cas «retirer de l argent» qui est le cas d utilisation le plus important pour le client de la banque. Client de la banque Retirer de l argent Figure 5 : Cas d utilisation retirer de l argent La séquence de cas d utilisation qu on peut établir pour un retrait d argent sur un automate de type DAB pourrait se décomposer de la façon suivante : - Le client de la banque s identifie, - Le client de la banque choisit le compte sur lequel il veut effectuer son retrait et spécifie le montant du retrait. - Le système déduit le montant de son compte et délivre l argent. Ce cas d utilisation met en évidence des exigences de disponibilité, de précision, de sécurité. Un exemple de cas d utilisation «Retirer de l argent» peut s écrire comme suit en établissant le squelette du flot des événements : - Le cas d utilisation se déclenche quand le client insère sa carte bancaire, le système lit la carte et valide l information écrite sur la piste magnétique. - Le système demande le code secret, le client le saisit, le système le valide. - Le système demande quelle opération le client désire effectuer. Le client choisit de retirer de l argent. - Le système demande le montant du retrait. Le client saisit un montant. - Le système demande sur quel type de compte bancaire le retrait doit s effectuer (compte courant ou compte épargne ) - Le système entre en communication avec le réseau de la banque pour vérifier le numéro de compte, le code et la disponibilité du montant demandé. - Le système demande au client s il désire un reçu. Cette étape n est effectuée que s il reste du papier pour l impression. - Le système invite le client à retirer sa carte. Le client s exécute. - Le système fournit la somme d argent demandée. 3 DAB : Distributeur Automatique de Billets Christiane DAVOINE GUHUR Page /05/02

11 - Le système imprime le reçu. - Fin du cas d utilisation. On a décrit un flot d événements précis, il en existe d autres, on peut envisager différents déroulements. Figure 6 : Modèle d'analyse "retirer de l'argent" Ce modèle d analyse indique de quelle façon le cas d utilisation est réalisé par une collaboration, l un et l autre reliés par une dépendance de «traçabilité» et fait apparaître quatre classes qui prennent part à la réalisation du cas d utilisation. Les classes distributeur et interface guichet sont des classes frontières, la classe retrait est une classe de contrôle et la classe compte est une classe entité. 2.3 LE PROCESSUS CENTRE SUR L ARCHITECTURE Cette partie définit le concept d architecture logicielle et explique son rôle central dans RUP. En effet le processus unifié propose des principes et des conseils sur ce qui constitue l essence même d une architecture et UML dispose de puissantes constructions qui permettent de formuler l architecture. L architecte reçoit ainsi dans cette tâche, le soutien d UML et du Processus unifié[jacobson, et al 1999] Importance des modèles et de l architecture Une part importante de RUP est consacrée à la modélisation. En effet les modèles aident à simplifier la réalité et à appréhender les solutions d un nouveau système. Les modèles sont des représentations cohérentes, plus ou moins complètes du système à construire qui regroupés, constituent la description de l architecture du système. Comme on le dit souvent «L architecture est ce qui reste de la description d un système quand on simplifie au maximum et que l on peut encore comprendre ce que fait ce système et comment il fonctionne!» [Kruchten 2000] Définition de l architecture L architecture est un concept complexe qui se représente par des vues architecturales multiples et coordonnées. Elle est l ensemble des décisions prises sur l organisation du système logiciel, les choix des éléments structuraux, la définition des interfaces et leurs comportements. L architecture logicielle s intéresse non seulement à la structure et au comportement du système, mais aussi à son contexte, à ses contraintes économiques et technologiques. Christiane DAVOINE GUHUR Page /05/02

12 2.3.3 Représentation de l architecture par le modèle à 4+1 vues Comme le montre la figure ci-dessous, RUP propose une approche à cinq vues appelée par Philippe Kruchten «Modèle d architecture à 4+1 vues». Figure 7 : Le modèle d architecture à 4+1 vues [INT2]. - La vue logique de l architecture s intéresse aux aspects fonctionnels du système et à ce qu il doit produire pour les utilisateurs finaux. Elle décrit les classes majeures du système et leur organisation en paquetages et sous-systèmes. - La vue d implémentation décrit l organisation des modules statiques du logiciel dans l environnement de développement, en terme de paquetages et de couches. Elle prend en compte la gestion de configuration, la politique de gestion de versions. On trouve par exemple le code source d un plan de vol et la bibliothèque de code pour une base de données d espaces aériens. - La vue des processus définit les tâches, les flots de contrôle ou les processus et leurs interactions. - La vue de déploiement réconcilie l ingénierie du logiciel avec l ingénierie système. Elle s occupe des problèmes de déploiement, d installation, de performances. - La vue des cas d utilisation contient les quelques scénarios et cas d utilisation les plus importants. On les utilise pour guider l étude et la conception de l architecture pendant les phases de création (d inception) et d élaboration et on les exploite ensuite pour valider les différentes vues architecturales[kruchten 2000] Architecture et conception architecturale. Comment l obtient-on? L architecture est développée de façon itérative au cours de la phase d élaboration au travers de l expression des besoins, de l analyse, de la conception, de l implémentation et des tests. Comment la décrit-on? La description de l architecture est une vue des modèles du système : modèles des cas d utilisation, d analyse, de conception, d implémentation et de déploiement. Elle Christiane DAVOINE GUHUR Page /05/02

13 décrit les parties du système qu il est important de comprendre pour les développeurs et les autres intervenants [Jacobson, et al 1999].. La conception architecturale Une fois qu on a choisi une représentation de l architecture adaptée au problème à résoudre, il faut se préoccuper du processus de conception architecturale. RUP définit deux artefacts importants liés à l architecture : - la description de l architecture logicielle pour le projet, - le prototype architectural qui sert à valider l architecture et constitue une référence pour le reste du projet. L intérêt de l architecture porte principalement sur trois points : - Elle permet le contrôle intellectuel sur l ensemble du projet, - Elle situe les composants principaux et les interfaces majeures les uns par rapport aux autres, - Elle permet de raisonner sur la réutilisation interne (identification des parties communes) ou externes (l incorporation de composants logiciels prêts à l emploi). L architecture fournit une base pour la gestion de projet [Kruchten 2000]. On distinguera trois catégories de composants : - Les composants d exécution qu on livre, installe et exécute directement (les DLL, ou les bibliothèques liées dynamiquement). - Les composants de développement, il s agit là de sous-systèmes d implémentation réutilisables, de bibliothèques de logiciels avec une forte cohérence interne. - Les composants métier, il s agit d ensembles cohérents de composants d exécution qui assurent une fonctionnalité identifiée dans un métier donné (gestion des comptes, retirer de l argent ) Il y a d autres concepts architecturaux tels que le style architectural, les mécanismes architecturaux et les pattern [Jacobson, et al 1999]. - Le style architectural impose un certain degré d uniformité dans l architecture au niveau des formes. On le définit par le choix d un framework architectural, une infrastructure logicielle, une technique ou un outil de description architectural (le client-serveur et les styles pilotés par les événements). - Le mécanisme architectural est une classe, un groupe de classes ou un pattern. Il fournit une solution commune à un problème commun. Il donne un comportement spécifique aux classes. - Le pattern architectural représente un savoir-faire de conception éprouvé. Il identifie des abstractions, au-delà des classes, des instances et des composants propres à un système Exemple sur le cas d utilisation «Retirer de l argent». La vue architecturale du modèle de conception. On a vu dans le modèle d analyse l existence de trois sous-systèmes : l interface du DAB, la gestion des transactions et la gestion des comptes. Ces sous-systèmes étant nécessaires à la réalisation du cas d utilisation «retirer de l argent», ils sont donc signifiants sur le plan de l architecture. Christiane DAVOINE GUHUR Page /05/02

14 Figure 8 : Structure statique de la vue architecturale du modèle de conception pour le système DAB. La structure statique ne suffit pas, il faut montrer la façon dont les sous-systèmes réalisent les cas d utilisation signifiants pour l architecture à l aide d un diagramme de collaboration. Les objets des classes appartenant aux sous-systèmes dialoguent les uns avec les autres pour exécuter une instance de cas d utilisation. Ces objets échangent des messages comme l indique le diagramme. Figure 9 : diagramme de collaboration du système DAB [Jacobson, et al 1999].. On explique ici le flot de la réalisation du cas d utilisation. Le texte est presque identique au flot d événement du modèle d analyse, mais il est vu sous l angle des sous-systèmes et non des classes. La vue architecturale du modèle de déploiement. Le modèle de déploiement définit l architecture physique du système en termes de nœuds connectés. Ces nœuds sont des unités matérielles sur lesquelles s exécutent les composants logiciels. Les nœuds et connexions peuvent alors être modélisés dans le modèle de déploiement dès l enchaînement d activités des besoins. Dans notre exemple, le client de la banque accède au système par l intermédiaire d un nœud client du DAB qui accède au serveur d applications du DAB pour effectuer les transactions. Le serveur d applications du DAB utilise à son tour, le serveur de données du DAB pour effectuer des transactions spécifiques sur des comptes. Figure 10 : Le modèle de déploiement du système DAB [Jacobson, et al 1999].. Une fois les nœuds définis, il est possible de déployer les fonctionnalités. On déploie chaque sous-système dans son entier sur un seul nœud. Le sous-système interface du DAB est ainsi déployé sur le nœud client du DAB, le sous-système gestion des Christiane DAVOINE GUHUR Page /05/02

15 transactions sur le nœud serveur d applications du DAB, le sous-système gestion des comptes sur le nœud serveur de données du DAB. Figure 11 : La vue architecturale du modèle de déploiement [Jacobson, et al 1999].. La vue architecturale d implémentation. Le modèle d implémentation présente une correspondance directe avec les modèles de conception et de déploiement. Chaque sous-système de service du modèle de conception se traduit par un composant pour chaque type de nœud sur lequel il doit être installé. 2.4 LE PROCESSUS ITERATIF ET INCREMENTAL La démarche séquentielle ou en cascade est acceptable pour des petits projets qui comportent peu de risques et utilisent une technologie éprouvée. En revanche, elle ne convient pas au projet complexe qui comporte un degré élevé d innovation ou de risque. Partant de ce constat, on peut découper le cycle de vie d un grand projet en une succession de petits projets. On adopte alors l approche itérative. On sélectionne un sous-ensemble réduit d exigences et limité au niveau des risques, on effectue une partie de la conception et de la réalisation, on valide à nouveau et ainsi de suite jusqu à ce que le système soit complet. Pour être efficace on établit une séquence de jalons mineurs et majeurs clairement articulés fournissant aux responsables et à l équipe de développement les critères nécessaires au passage d une phase à l autre du cycle de vie du produit. Figure 12 : Une approche itérative au développement [INT1] Qu est-ce qu une itération? Une itération est un mini-projet, c est-à-dire un déroulement plus ou moins complet des principaux enchaînements d activités, aboutissant à une version livrée en interne. Les itérations respectent les cinq enchaînements principaux «besoins, analyse, conception, implémentation, tests». Chaque itération débute par une activité de planification et se termine par une activité d évaluation. Christiane DAVOINE GUHUR Page /05/02

16 2.4.2 La dimension statique du processus Dans le processus itératif et incrémental, la dimension statique du processus correspond à la partie descriptive de celui-ci, la description du qui fait quoi, comment et quand. C est sur ces quatre éléments primaires de modélisation que RUP a choisi de présenter ses concepts clés : - Le qui le travailleur. Celui-ci fait référence au rôle que doit tenir un individu dans le cadre de son travail et de ses responsabilités. L individu désigné comme travailleur possède un ensemble de compétences. Exemple : un concepteur est un individu qui définit les responsabilités, les opérations, les attributs et les relations de dépendances d une ou plusieurs classes et détermine comment elles s insèrent dans l environnement d implémentation [Kruchten 2000]. - Le comment les activités et les étapes d activité. Une activité est une unité de travail qu un individu agissant en tant que travailleur peut être amené à effectuer. Elle doit apparaître comme un élément de planification et de progression. En terme de modélisation objet, un travailleur est un objet actif et les activités effectuées par ce travailleur sont les opérations faites sur cet objet. Exemples d activités: planifier une itération, trouver des cas d utilisation et des acteurs, exécuter un test de performance. Une activité se subdivise en étapes suivant trois catégories : - étapes de réflexion (trouver les acteurs, les cas d utilisation et leurs interactions avec les acteurs), - étapes d actions (constituer les paquetages, représenter le modèle de cas d utilisation par des diagrammes de cas d utilisation), - étapes d inspection (évaluer les résultats). - Le quoi les artefacts. Un artefact est un élément d information fabriqué, modifié ou utilisé par un processus. Il est le matériau dont se servent les travailleurs pour réaliser une activité. En conception orientée objet, les activités sont les opérations d un objet actif et les artefacts sont les paramètres de ces activités. Ils se présentent sous différentes formes, un modèle, un élément de modèle, un document, du code source, un exécutable. Exemple d artefacts : le modèle de conception, le modèle d architecture. Figure 13 : Travailleurs, activités et artefacts [Kruchten 2000]. Christiane DAVOINE GUHUR Page /05/02

17 - Le quand les enchaînements d activités. Une suite d activités qui produit un résultat observable se nomme un enchaînement d activités. Un enchaînement d activités est représenté dans RUP par un diagramme d activités. Les activités, les étapes et les principes sont des guides généraux mis à la disposition de l utilisateur. Les guides d utilisation d outil sont les seuls documents qui font une référence directe à des outils. Ils expliquent comment effectuer certaines étapes à l aide des outils. Des principes et conseils, des canevas, des guides d utilisation d outils complètent la description du processus en donnant davantage d informations à l utilisateur. Figure 14 : Exemple d enchaînement d activités [Kruchten 2000] La dimension dynamique du processus Un processus itératif subdivise le cycle de développement en une succession d itérations. Chaque itération ressemble à une mini-cascade et comporte les activités de gestions des exigences, de conception, d implémentation et d évaluation. L approche itérative permet la prise en compte des changements dans le cahier des charges et au niveau de la stratégie d implémentation. Elle s attaque aux risques et les réduit dès que possible. Elle permet à l organisation de progresser, d acquérir un savoir et de s améliorer. Elle se concentre sur des objectifs réels et tangibles [Kruchten 2000]. Dans une approche itérative, il est important de mesurer l avancement du projet, de vérifier qu on s achemine réellement vers l objectif final, pour cela le processus itératif est organisé en quatre phases dont chacune d elles est ponctuée par un jalon majeur. Figure 15 : Les quatre phases et jalons du processus itératif [Kruchten 2000]. Christiane DAVOINE GUHUR Page /05/02

18 - La phase inception décrit le produit final, et permet de réaliser une étude de rentabilité et de définir les ambitions du projet. Cette phase se conclut par le jalon Objectif de cycle de vie. Dans cette phase on met l accent sur l évaluation de l enveloppe globale du développement. - La phase d élaboration qui permet de planifier les activités et les ressources nécessaires à la réalisation du projet, de spécifier les fonctionnalités et de concevoir l architecture. Elle détermine le jalon de l architecture du cycle de vie. Ici on porte les efforts sur le cahier des charges et sur l élaboration d une maquette exécutable. - La phase construction qui construit le système, en fait évoluer la vision et l architecture jusqu à l obtention d un produit prêt à livrer. Son aboutissement est le jalon de capacité opérationnelle initial. L attention se porte sur la conception détaillée et l implémentation. - La phase transition dont l objectif est de transmettre le produit aux utilisateurs, d assurer le soutien et la maintenance jusqu à ce que l utilisateur soit satisfait. La phase de transition se conclut par le jalon livraison de produit. On s assure ici que le système a un niveau de qualité suffisant pour répondre au cahier des charges. Par rapport à une approche traditionnelle, la démarche itérative atténue les risques, s adapte mieux aux changements et permet aux équipes d acquérir des connaissances pendant le déroulement du projet. Elle offre également un grand niveau de réutilisation et une meilleure qualité globale. Figure 16 : D un cycle de vie séquentiel à un cycle de vie itératif [Kruchten 2000]. 3 LES ENCHAINEMENTS D ACTIVITES DU PROCESSUS Maintenant que nous avons abordé les notions élémentaires qui sous-tendent les pratiques essentielles du Processus unifié, nous allons décrire en détail chacun des enchaînements d activités. Dans RUP, il existe neuf principaux enchaînements d activités : - De modélisation métier - De gestion des exigences - D analyse et de conception - D implémentation - De test - De déploiement Christiane DAVOINE GUHUR Page /05/02

19 - De gestion de projet - De gestion de configuration et des changements - Liés à l environnement. Figure 17 : Les neufs principaux enchaînements d activités du processus [Kruchten 2000]. On peut ajouter des éléments additionnels du processus pour faciliter la compréhension et l utilisation qui sont les principes et conseils, les canevas, les guides d utilisation d outils et les concepts. Chaque enchaînement d activité fait appel au même formalisme dans sa représentation graphique. Chacun d eux est représenté par : - un diagramme «travailleurs et artefacts» qui précise pour un travailleur la responsabilité qui lui incombe dans la production des artefacts. - Un diagramme d enchaînement d activités qui précise la chronologie des activités et le lien de dépendance entre les activités et d autres travailleurs. On reprendra chacun de ces enchaînements en détail dans les paragraphes suivants. C est le diagramme d enchaînement des activités qui permet de passer de la conception vers le modèle système. 3.1 LA MODELISATION METIER Pourquoi modéliser le métier? La modélisation métier est une technique qui permet de comprendre les processus métier d une entreprise. On modélise un métier pour comprendre sa structure et sa dynamique, pour s assurer que tous les intervenants ont une vision commune à l organisation et pour déduire les cahiers des charges des futurs systèmes informatiques de cette organisation. On modélise un métier lorsque le nombre d utilisateurs et la quantité d informations sont importants Comment modéliser le métier? La modélisation du métier est prise en charge par deux types de modèles UML : le modèle des cas d utilisation et le modèle objet : - Le modèle des cas d utilisation est décrit par les diagrammes des cas d utilisation. - Le modèle objet métier est un modèle interne du métier. Il décrit la façon dont chaque cas d utilisation du métier est réalisé par un groupe de travailleurs utilisant un ensemble d entités métier et d unités de travail. Chaque réalisation de cas d utilisation métier peut être montrée sous forme de diagrammes d interactions et de diagrammes d activités [Jacobson, et al 1999]. Christiane DAVOINE GUHUR Page /05/02

20 Figure 18 : Travailleurs et artefacts dans les activités de modélisation métier [Kruchten 2000]. De plus, il existe deux autres artefacts : - Les spécifications métier complémentaires : les définitions, les règles, les procédures et les normes. - Un glossaire qui définit les termes importants utilisés dans le métier. Un avantage de cette approche de la modélisation du métier est qu elle montre bien les dépendances entre les modèles métier et les modèles du système informatique utilisés dans ce métier. Les travailleurs métier deviennent les acteurs du système informatique. Les actions et comportements des travailleurs métiers déterminent les cas d utilisation du système, pour les parties qu on souhaite automatiser. A partir des entités métier on peut déduire les classes d entités du modèle [Kruchten 2000]. Figure 19 : Des modèles métier aux modèles systèmes [Kruchten 2000] Les enchaînements d activités La figure ci-dessous montre un enchaînement typique de modélisation métier. Dans un premier temps, il s agit d identifier les processus métier clés et les acteurs métier concernés, de les décrire sous forme d un modèle de cas d utilisation. Ensuite, il convient de détailler les descriptions des cas d utilisation métier mis en évidence, d identifier les rôles, de définir les responsabilités, les opérations, les attributs et les relations entre les travailleurs et les entités métier. Ces activités relèvent de la compétence du concepteur métier. Une fois ces modèles élaborés, l auditeur du modèle se charge de vérifier qu ils représentent correctement l organisation. Christiane DAVOINE GUHUR Page /05/02

21 Figure 20 : Un enchaînement d'activités de modélisation métier [Kruchten 2000] Les outils de modélisation métier Rational Rose fournit tout ce dont on a besoin pour produire les modèles métiers graphiques. Pour saisir les informations textuelles, on peut utiliser l outil Rational Requesite Pro, comme dans le cadre d un développement logiciel. Avec cet outil, il est possible de gérer les dépendances entre les éléments issus de différents modèles. Pour créer et maintenir automatiquement la documentation des modèles, on dispose de l outil Rational SoDA. 3.2 LA GESTION DES EXIGENCES Définitions Une exigence est une condition à laquelle doit satisfaire un système ou une capacité dont il doit faire preuve [Kruchten 2000]. Dans un système on rencontre les exigences fonctionnelles qui expriment le comportement d un système en spécifiant les conditions d entrée et les conditions de sortie qui doivent en résulter. Les exigences non fonctionnelles sont un ensemble d exigences auquel un logiciel doit répondre en plus des exigences fonctionnelles. On distingue quatre catégories calquées sur la typologie des attributs de qualité : - Les exigences d utilisation basées sur des critères ergonomiques, de cohérence au niveau de l interface utilisateur et de la documentation. - Les exigences de fiabilité qui sont basées sur la précision du résultat. - Les exigences de performance qui s appuient sur les indicateurs de temps de réponse, de charge et de mémoire requise. - Les exigences de maintenance qui évaluent la complexité du logiciel dans le processus de développement Comment exprimer les exigences? Le cahier des charges qui regroupe les demandes des intervenants doit être compris par l équipe de développement. Pour communiquer avec exactitude aux développeurs ce qu ils doivent réaliser, il faut établir un cahier des charges qui contient les exigences détaillées fonctionnelles et non fonctionnelles du système. La modélisation par les cas d utilisation est un moyen efficace de les exprimer. Les différents types d usagers du système sont représentés par des acteurs et les Christiane DAVOINE GUHUR Page /05/02

22 fonctionnalités sont converties en suites d interaction entre ces acteurs et le système [Kruchten 2000]. Pour exprimer les exigences, on collecte les demandes des intervenants, des utilisateurs finaux, des clients, des gens du marketing et on les saisit dans le document de demandes des intervenants (Cf la figure ci-dessous). On utilise cet ensemble de demandes pour décrire le document de vision qui contient les fonctionnalités énumérées, une étude de rentabilité, le coût de la réalisation et le bénéfice escompté. On traduit ces fonctionnalités dans un cahier des charges détaillé suffisant pour concevoir et construire le système et identifier les cas de tests. Ce cahier des charges est constitué de deux artefacts : le modèle des cas d utilisation et les spécifications complémentaires. A partir du cahier des charges détaillé on constitue ensuite le modèle de conception, la documentation pour l utilisateur final et le modèle de test pour vérifier que les exigences sont satisfaites. Figure 21 : Différents artefacts de l'ensemble des exigences et leurs relations avec d'autres artefacts [Kruchten 2000] Conception de l interface utilisateur La conception de l interface utilisateur comprend deux étapes, la mise en forme graphique et la conception en terme de classes de conception. Dans une première étape, à partir du modèle des cas d utilisation et des spécifications supplémentaires, on ébauche l enchaînement des activités de gestion des exigences qui débouche sur l élaboration d un prototype de l interface utilisateur à l aide d un outil de prototypage. Dans la deuxième étape, on construit un prototype de l interface utilisateur à partir des définitions détaillées établies pendant la réalisation des parties des cas d utilisation qui nécessitent une interface avec les utilisateurs. Christiane DAVOINE GUHUR Page /05/02

23 Figure 22 : Travailleurs et artefacts dans l'enchaînement des activités de gestion [Kruchten 2000]. Les principaux travailleurs impliqués sont : - L analyste système qui s attache à délimiter le périmètre du système et les fonctions qu il doit remplir. - Le spécificateur de cas d utilisation qui détaille les exigences fonctionnelles du système. - L architecte qui identifie les cas d utilisation et les exigences architecturales. - Le concepteur d interface utilisateur qui dirige et coordonne la conception et le prototypage. - L auditeur du cahier des charges qui passe en revue les artefacts générés Enchaînements d activités Figure 23 : Enchaînement des activités de gestion des exigences [Kruchten 2000]. Dans un premier temps les analystes système travaillent avec les intervenants, ils doivent identifier ce qu il faut produire et identifier les exigences non fonctionnelles. Ils peuvent alors développer la vision du projet qui comprend la liste des fonctionnalités décrites par les intervenants. A partir du document de vision élaboré par les analystes système, les spécificateurs de cas d utilisation détaillent les cas d utilisation et les spécifications supplémentaires. Christiane DAVOINE GUHUR Page /05/02

24 Les concepteurs d interfaces utilisateur progressent en parallèle des spécificateurs de cas d utilisation pour concevoir l interface utilisateur. Dans les premières itérations, l architecte travaille avec les analystes système et les spécificateurs des cas d utilisation pour extraire un ensemble de scénarios qui va servir à la définition de l architecture Les outils pour la gestion des exigences. L outil de support qui va permettre de saisir les exigences, de les organiser à la fois dans des documents textuels, dans des bases de données, de les gérer et de traiter les demandes de modifications est Rational Requisite Pro de la société Rational. Pour la modélisation graphique des artefacts (modèle des cas d utilisation, classes frontières) on peut utiliser Rational Rose. Rational SoDA aide à automatiser la création d un cahier des charges. Il permet de définir un canevas intelligent pour extraire et assembler des informations de différentes sources, SoDA va regrouper toute l information ayant trait à un artefact pour produire un document unique Exemple des exigences pour le cas d utilisation «Retirer de l argent». Pour analyser les exigences dans le cas «Retirer de l argent», on peut souhaiter que le temps de réponse à un client de la banque soit inférieur à 5 secondes, entre la sélection du montant à retirer et la délivrance des billets. On peut aussi imaginer que pour un client de la banque, lorsque l automate est en mode autonome 4, on délivre au client une somme incluse dans le plafond hebdomadaire inscrit sur sa carte, alors qu en mode connecté ce plafond peut être dépassé en fonction du solde de son compte ou des conditions spéciales dont il peut bénéficier. 3.3 L ANALYSE ET LA CONCEPTION Objectif L objectif de l enchaînement des activités d analyse et de conception est de traduire l ensemble des exigences en une spécification qui décrit comment réaliser le système. Cette traduction suppose de bien comprendre le cahier des charges du système et de choisir la meilleure stratégie d implémentation. Il faut mettre en place une architecture robuste qui permet de concevoir un système facile à construire et à faire évaluer. Le langage employé dans l analyse repose sur un modèle objet conceptuel, appelé modèle d analyse. En fait, dans le modèle d analyse, une ressource interne peut être représentée sous forme d objet, tel le compte d un client auquel accède les cas d utilisation dépôt et retrait [Jacobson, et al 1999]. Pendant cet enchaînement, on exploite les cas d utilisation pour identifier un ensemble d objets à partir desquels on construit des classes, les sous-systèmes et 4 Mode autonome : Mode déconnecté des bases de productions, Christiane DAVOINE GUHUR Page /05/02

25 les paquetages. Le but de l analyse est de traduire les exigences du système en ensemble de classes et de sous-systèmes. L objet de la conception est d adapter le résultat de l analyse aux contraintes imposées par les exigences non fonctionnelles. La conception doit définir le système de façon à ce qu il puisse être implémenté sans ambiguï té. Ces deux grandes activités «analyse et conception» sont regroupées dans cette présentation, car la deuxième reprend les artefacts de l activité d analyse en détaillant plus finement les cas d utilisation afin d atteindre un niveau suffisant pour assurer son implémentation. Le rôle de la conception dans le cycle de vie du logiciel est sa contribution à la mise en place d une architecture saine et stable. Entre autre, il permet de créer un plan d élaboration et de construction pour le modèle d implémentation. Le modèle de conception est proche de l implémentation, il est naturel de le conserver et de l actualiser tout au long du cycle de vie du logiciel. Figure 24 : comparaison des modèles des cas d'utilisation et d'analyse [Jacobson, et al 1999] Travailleurs et artefacts La responsabilité de l analyste est partagée entre : - l architecte qui gère les problèmes d ensemble, - le concepteur qui prend en charge les détails, - le concepteur de base de données qui s occupe des détails dans le traitement de la persistance, - l auditeur du modèle architectural et du modèle de conception qui passe en revue les artefacts clés fabriqués pendant l enchaînement d activités. Au cours de l analyse et de la conception, on élabore un modèle de conception de plusieurs vues architecturales, qui sont des abstractions. La vue logique présente la décomposition du système en un ensemble d éléments logiques (classes, soussystèmes, paquetages, et collaborations). La vue des processus établit une correspondance entre ces éléments et les processus ou les «Threads» dans le système. Christiane DAVOINE GUHUR Page /05/02

26 3.3.3 Enchaînements d activités La figure ci-dessous illustre un enchaînement typique d analyse et de conception qui est centré d une part sur l architecture et d autre part sur la conception détaillée de classes et de sous-systèmes. Examinons les activités ayant trait à l architecture. - L architecte identifie les patterns architecturaux. Les mécanismes clés définissent les couches, les principes d organisation des sous-systèmes et la stratégie de réutilisation. - L analyste des cas d utilisation produit des classes. Il identifie les classes significatives, les regroupe dans des paquetages et des sous-systèmes de conception que l on organise en couches. - Le concepteur utilise l architecture et les résultats de l analyse des cas d utilisation pour identifier les caractéristiques des classes, leurs relations et affiner leurs spécifications. On poursuit la conception des cas d utilisation en spécifiant chaque réalisation en terme d opérations sur les classes et soussystèmes, dans les diagrammes de séquence ou diagrammes de collaboration. Figure 25 : Un enchaînement des activités d'analyse et de conception [Kruchten 2000] Exemple d analyse du cas d utilisation «Retirer de l argent» On reprend l exemple des clients de la banque dans l identification des paquetages d analyse généraux à partir du modèle du domaine. Chacune des classes représente des entités importantes et complexes. Les paquetages gestion des comptes et gestion des clients de la banque contiendront probablement de nombreuses classes d analyse, notamment des classes de contrôle et des classes frontières liées respectivement à la gestion des comptes et des clients de la banque [Jacobson, et al 1999]. Christiane DAVOINE GUHUR Page /05/02

27 Figure 26 : identification de paquetages d'analyse généraux à partir des classes du domaine [Jacobson, et al 1999]. Le paquetage gestion des comptes comprend un paquetage de service général appelé comptes, qui permet d accéder aux comptes pour des activités telles que le transfert d argent et l extraction d historique des transactions. Ce paquetage contient également un paquetage de service appelé risques, consacré à l estimation des risques associés à un compte particulier. Figure 27 : paquetages de services «comptes et de risques» encapsulant chacun des classes fonctionnellement liées [Jacobson, et al 1999] Les outils pour l analyse et la conception. UML est le langage qui convient le mieux pour représenter les modèles de cet enchaînement. Les principes et conseils de modélisation associés aux différents artefacts du RUP sont tous exprimés selon le formalisme d UML. Rational Rose est le meilleur outil pour saisir, gérer et présenter les modèles. Rose permet de faire du round-trip engineering avec certains langages de programmation. On peut garder synchronisés le modèle de conception et le code et faire évoluer le système à partir de l un ou de l autre. Avec ObjectTime Developper et Rose for Real-Time, il est possible de construire un modèle de conception exécutable. Avec SoDA on crée automatiquement des documents et des rapports en extrayant et mettant en forme des informations provenant de plusieurs sources, telles que Rose et Requisite Pro. 3.4 L IMPLEMENTATION L implémentation part des résultats de la conception pour implémenter le système sous forme de composants, c est-à-dire de code source, de scripts, de binaires, et d exécutables. Christiane DAVOINE GUHUR Page /05/02

28 3.4.1 Objectifs Le principal objectif de l implémentation est donc d étoffer l architecture et le système dans son ensemble. Pour être plus précis, on voit que l enchaînement des activités d implémentation a de multiples objectifs : - Définir l organisation du code en termes de sous-systèmes d implémentation en couches, - Transformer les classes et les objets en composants (fichiers source, binaires, exécutables ), - Procéder aux tests unitaires des programmes, - Intégrer en un système exécutable les unités produites par les implémenteurs. Figure 28 : Enchaînement d'activités d'implémentation Le rôle de l implémentation dans le cycle de vie du logiciel est important dans deux phases principalement. Dans la phase de l élaboration, il est pour la création de l architecture exécutable de référence. Dans la phase de construction, son rôle est majeur dans le développement des composants exécutables du logiciel. Les activités d implémentation trouvent un rôle dans la phase de la transition pour la correction des anomalies. Figure 29 : point de convergence de l'implémentation [Jacobson, et al 1999] Les activités d implémentation Cet enchaînement comprend le test unitaire des composants individuels, chaque implémenteur est responsable du test des unités de code qu il produit. Pour expliquer les activités d implémentation définies dans RUP, on présente les trois concepts clés suivants, les constructions, l intégration, les prototypes. Christiane DAVOINE GUHUR Page /05/02

29 Le concept de construction est une version exécutable d un système ou d une partie d un système qui réalise un sous-ensemble des fonctionnalités du produit final. Tous les éléments d une construction sont soumis au contrôle de configuration. Le concept d intégration est une activité de développement logiciel au cours de laquelle on combine des composants logiciels distincts en un tout. Il existe deux niveaux d intégration, on procède à l assemblage des éléments constituant le sous système avant de le livrer aux intégrateurs du système ou on les assemble pour former le système complet. RUP recommande une approche incrémentale de l intégration. La démarche consiste à écrire des parties de code, à les tester et à les combiner graduellement dans un ensemble exécutable, en ajoutant une partie à la fois. Le concept de prototype permet de faire face aux risques et de lever l incertitude sur : la viabilité commerciale du produit, son utilisation, son financement et la compréhension des exigences Les types de prototypes Les prototypes peuvent être définis selon leur finalité. - Les prototypes exploratoires qu on jette une fois qu ils ont rempli leur mission. - Les prototypes évolutifs qui évoluent d une itération à l autre pour devenir le système final. - Les prototypes comportementaux qui examinent un comportement spécifique du système vu de l extérieur par l utilisateur. Ici on ne se soucie pas de la qualité ni des normes du projet. - Les prototypes structurels qui explorent les aspects architecturaux et technologiques du système, vu de l intérieur. Ce sont des prototypes en général évolutifs qui utilisent et testent l infrastructure du système final, son ossature Les outils pour l implémentation C est dans le domaine de l implémentation que l on trouve tous les outils de développement logiciel classiques tels que les éditeurs, les compilateurs, les éditeurs de liens et les débogueurs. Aujourd hui, ces outils de gestion se trouvent dans des environnements de développement intégrés où ils partagent une même base de données (exemple : l environnement de développement Rational APEX pour ADA et C++). Rational Rose permet de faire du round-trip engineering, en liant étroitement les activités de conception et d implémentation. Des outils d analyse syntaxique comme Purify et Quantify facilitent la détection d anomalies dans le code. Le gestionnaire de configuration ClearCase offre des espaces de travail individuels, des espaces d intégration des sous-systèmes et du système. ClearQuest est l outil idéal pour le suivi des demandes de changement et des anomalies, jusqu au code source. 3.5 LES TESTS L enchaînement d activités de tests s attache à la vérification des résultats de l implémentation en testant chaque construction, aussi bien les constructions internes et intermédiaires que les versions finales du système, livrables à l extérieur. Cet enchaînement d activité concourt à la qualité du produit et de tous les éléments qui ont servi à le fabriquer. Christiane DAVOINE GUHUR Page /05/02

30 3.5.1 Les objectifs L enchaînement des tests a pour but principal d évaluer la qualité d un produit. Pour cela il faut vérifier la bonne intégration des composants, les fonctionnalités et les performances du produit. Les divers objectifs que poursuit la phase de tests sont de planifier les tests nécessaires pour chaque itération, concevoir et implémenter les tests en créant les cas de tests et en spécifiant ce qui doit être testé. Ils sont également d effectuer les divers tests et prendre systématiquement les résultats de chacun d eux Le rôle des tests dans le cycle de vie du logiciel Le rôle des tests dans le cycle de vie du logiciel se situe dans les quatre phases du développement. Dans la phase de conception, on planifie les tests pour délimiter la portée du système, mais ils interviennent avant tout au moment où chaque construction doit subir des tests d intégration et des tests système. Cela signifie que les tests mobilisent l attention pendant la phase d élaboration lors du test de l architecture de référence exécutable et pendant la phase de construction, lors de l implémentation de la masse du système. Pendant la phase de transition, l attention se porte principalement sur la correction des anomalies détectées au cours des premières utilisations et sur les tests de non-régression Les travailleurs et artefacts Les principaux travailleurs impliqués dans cette phase de test sont : - Le concepteur de test qui est responsable de la planification des tests, de leur conception, de l implémentation des procédures et de l évaluation de la couverture, des résultats et de l efficacité des tests, - Le testeur système qui est responsable de la préparation, de l exécution, de l évaluation des résultats, - Le testeur de performance qui est responsable de l exécution des tests de performance. Figure 30 : Travailleurs et artefacts impliqués dans les tests [Jacobson, et al 1999]. Ce plan d enchaînement produit quatre artefacts principaux : - Le plan de test décrit les stratégies de tests, ainsi que leur calendrier et les ressources mises à leur disposition. - Le modèle de test décrit les conditions dans lesquelles les composants exécutables du modèle d implémentation subissent des tests d intégration et des tests système. Ce modèle se compose d un ensemble de cas de test, de procédures et de composants de test. - Un cas de test correspond à l ensemble des données de test, les conditions d exécution et les résultats attendus, Christiane DAVOINE GUHUR Page /05/02

31 - Une procédure de tests spécifie les conditions d exécution d un ou de plusieurs cas de test. - - Un composant de test automatise tout ou partie d une ou de plusieurs procédures de test. Il peut être représenté par un script, soient des instructions qui automatisent l exécution des procédures de tests. Figure 31 : Modèle de tests [Jacobson, et al 1999] - Le modèle de charge de travail pour les tests de performance identifie les variables de la charge et définit les valeurs à utiliser, en fonction des caractéristiques des acteurs, des cas d utilisation. - Les anomalies identifiées à la suite des tests Exemple de tests pour le cas d utilisation «retirer de l argent» Dans l exemple sur le retrait d argent au DAB (cf. la figure ci-dessous), on va prendre deux cas de test, retirer un montant prédéfini et retirer un montant défini par le client. Figure 32 : Cas, procédures et scripts de test pour un terminal bancaire [Kruchten 2000]. Dans les deux cas, on déroule les procédures spécifiques suivantes : - le démarrage de la session, Christiane DAVOINE GUHUR Page /05/02

32 - la procédure effectuer le retrait, - le choix de l option «montant prédéfini ou sélection du montant», - la procédure clôturer la session. Ces procédures peuvent être déroulées sur un automate de tests ou sur un poste de travail qui simule le mécanisme par l intermédiaire de scripts de test individuels pour assurer le même déroulement que sur un DAB. Si tout est correct, on enchaîne sur les scripts de test pour effectuer l opération «retirer le montant», on vérifie que tous les résultats sont corrects Les types de tests Les types de test sont nombreux : - Le test de «benchmark» compare les performances du sujet testé à une référence standard, - Le test de configuration vérifie que le sujet testé fonctionne correctement, - Le test d installation vérifie que le sujet testé peut être installé avec succès sur les différentes configurations matérielles et logicielles prévues, - Le test d intégrité mesure la robustesse, - Le test de charge vérifie que les performances comportementales du sujet testé restent acceptables lorsqu on modifie les configurations, en maintenant stables les conditions opérationnelles Les outils de tests Les tests constituent un effort itératif étalé tout au long du cycle de développement. Pour qu ils aient une efficacité maximale, il faut les automatiser en utilisant les outils adéquats. Voyons comment les outils de développement logiciel de Rational permettent l automatisation des tests. TestStudio est une suite d outils qui prend en charge l implémentation et l évaluation des tests. Ils permettent aux testeurs de créer et d exécuter des scripts de tests à base d interface utilisateur graphique sensés évaluer les fonctionnalités et les performances de l application. TestStudio comprend les outils suivants : - Robot s occupe de l implémentation et de l exécution des tests. Avec cet outil les testeurs créent et exécutent des scripts de tests à base d interface utilisateur, - LogViewer récupère les résultats des tests et génère un rapport qui permet d évaluer leur exécution, - TestManager est utilisé pour la planification, la conception et l évaluation des tests. Il founit des comptes rendus de l état d avancement des tests et du taux de couverture du cahier des charges, - TestFactory vérifie la fiabilité de l application. Il génère et exécute automatiquement des scripts de test. Il génère un compte rendu de couverture du code. PerformanceStudio implémente et exécute des scripts de test d un utilisateur virtuel dans le cadre de test de performance et de certains tests fonctionnels limités. 3.6 LA GESTION DE CONFIGURATION Les objectifs Christiane DAVOINE GUHUR Page /05/02

33 L objectif de la gestion de configuration et des changements est de garder une trace de tous les éléments qui participent au développement. Le but est de suivre leur évolution puisqu ils sont susceptibles de faire l objet de demandes de modification. Tout au long du cycle de vie d un produit, l équipe de développement crée, modifie maintes fois de nombreux artefacts. Ceci représente un investissement très lourd, les artefacts constituent de ce fait un capital qu il faut rendre accessible à la réutilisation Les définitions La gestion de configuration et des changements recouvre trois fonctions interdépendantes : la gestion de configuration, la gestion des demandes de changements, le suivi de l état d avancement et les mesures. On utilise le cube CCM 5 (Configuration and Change Management) pour représenter cette triple orientation. Figure 33 : Le cube CCM [Kruchten 2000]. - La gestion de configuration consiste à identifier les artefacts et à leur attribuer un numéro de version. Elle gère les dépendances entre les artefacts, les constructions et la hiérarchie de dépendance des composants. Elle fournit aux développeurs des espaces indépendants afin d éviter les conflits dans la phase d intégration - La gestion des demandes de changements se focalise sur la structure du processus. Il s agit d organiser et de traiter les modifications du système sollicitées par les intervenants internes et externes, d analyser les conséquences de ces interventions sur le produit et de suivre les demandes de changements jusqu à leur accomplissement. Les raisons des demandes de changements peuvent porter sur la correction d une anomalie, l amélioration de la qualité du produit ou de ces performances, l ajout d une exigence ou d une évolution du produit d une itération à l autre. - Le suivi de l état d avancement et les mesures porte sur le contrôle du projet. Il s agit de fournir des informations aux responsables de projet, en utilisant des outils de gestion de configuration. A partir de cette base de données, on peut fournir des mesures sur l état d avancement du projet, des mesures de distribution des changements et des mesures de tendance Les travailleurs et les artefacts Les travailleurs Les principaux travailleurs qui interviennent dans cette gestion de configuration sont : - Le chef de projet qui est responsable du plan de gestion de la configuration, 5 CCM : Configuration and Change Management Christiane DAVOINE GUHUR Page /05/02

34 - Le responsable de la configuration qui est chargé d établir la structure du produit dans le système de gestion de configuration, de la définition et de l allocation des espaces de travail privés. - Les implémenteurs qui sont chargés des évolutions du produit dans un espace de travail qui leur est attribué, - Les intégrateurs qui acceptent les éléments modifiés dans un espace de travail d intégration, ceux-ci assemblent également le produit. - L architecte qui fournit des informations pour la création de la structure du produit en établissant la vue d implémentation Les artefacts Les artefacts clés de la gestion de configuration sont les suivants : - Le plan de gestion de la configuration décrit les versions, les variantes, les espaces de travail et les procédures à utiliser. - Les demandes de changements sont émises par un initiateur et pour une cause à l origine de la demande. On enregistre ces informations ainsi que les résultats de l analyse d impact, le coût, les délais des opérations. - Le modèle d implémentation utilisé par le responsable de la configuration pour mettre en place l environnement. - Les mesures sur l état d avancement, que l on inclut dans les rapports d évaluation de l état d avancement Les enchaînements d activités Les enchaînements d activités de gestion de configuration peuvent être vus de la façon suivante : - Le chef de projet établit les procédures de gestion de configuration à utiliser dans le projet, définit les exigences pour les rapports sur l état d avancement et les références de base. - Le responsable de configuration définit la structure du produit, crée et alloue les espaces de travail nécessaires aux développeurs et aux intégrateurs. - Les travailleurs modifient les artefacts dans leurs espaces de travail privés, - Les intégrateurs acceptent les éléments modifiés dans les espaces d intégration et assemblent les produits partiels à tester. - Une nouvelle version de référence est établie à la fin d une itération Les outils support de la gestion de configuration La gestion de tous les changements est complexe. C est une tâche fastidieuse et ingrate qui demande beaucoup d effort et de rigueur. On a tout intérêt à l automatiser en utilisant des outils disponibles à cet effet. Dans la panoplie des outils de développement de Rational figurent : - ClearCase qui s occupe de la gestion de configuration, - ClearQuest qui se charge de gérer les demandes de changements et fournit des mesures sur l état d avancement du produit. 3.7 LE DEPLOIEMENT Les objectifs Le but de l enchaînement des activités de déploiement est de livrer le produit aux utilisateurs finaux. Le déploiement dépend essentiellement du domaine et du contexte commercial dans lequel s inscrit le logiciel. Christiane DAVOINE GUHUR Page /05/02

35 3.7.2 Les travailleurs et les artefacts L enchaînement des activités de déploiement s occupe de tous les artefacts qui sont livrés aux utilisateurs finaux, aux clients et aux organisations de soutien (marketing, distribution et vente). Figure 34 : Travailleurs et artefacts dans l'activité de déploiement [Jacobson, et al 1999] Les travailleurs Dans cette phase de déploiement, les travailleurs suivants sont susceptibles d intervenir : - Le responsable de déploiement qui planifie et organise le déploiement, - L implémenteur qui produit la partie logicielle de la livraison, - Le rédacteur technique qui rédige le manuel utilisateur, les notes d installation - Le développeur et l utilisateur qui rédigent les supports de formation Les artefacts Parmi les artefacts figurent éventuellement : - Le plan de déploiement, - Le manuel utilisateur, - Les supports de formation Exemple de configuration pour le cas d utilisation «Retirer de l argent» L exemple ci-dessous montre le découpage du déploiement qu il faudra effectuer sur l architecture matérielle identifiée. Figure 35 : Modèle de déploiement du Cas DAB [Jacobson, et al 1999]. Christiane DAVOINE GUHUR Page /05/02

36 3.7.4 Les enchaînements d activités Il convient de respecter la réalisation des activités énumérées ci-dessous en fonction du contexte de l application. Examinons quelques activités typiques qui ont lieu pendant le déploiement : - Produire le logiciel : on associe des scripts d installation aux exécutables, on établit une documentation utilisateur et on fournit les paramètres de configuration ainsi que les programmes pour convertir des données existantes dans le nouveau format. - Conditionner le logiciel : les divers artefacts sont conditionnés sur des supports variés, disquettes, CD-Rom, bandes magnétiques, fichiers sur un serveur, cassettes vidéo. On doit les étiqueter correctement. - Distribuer le logiciel : plusieurs solutions sont envisagées, depuis l empaquetage dans des boîtes jusqu à l utilisation d un réseau de distributeurs en passant par l Internet. - Installer le logiciel : des outils d installation et des procédures fournis avec l application facilitent la tâche. L installation est généralement plus complexe quand le système est distribué, l installation se fait alors de façon coordonnée et elle est réalisée par de multiples procédures. - Fournir l aide aux utilisateurs : l assistance aux utilisateurs peut prendre plusieurs formes, cours de formation, instruction assistée par ordinateur, aide en ligne, assistance téléphonique ou par Internet, la mise en place de procédures de suivi et de résolution des problèmes. - Obtenir l acceptation formelle : dans certains contrats de développement, le déploiement comprend une étape d acceptation formelle par le client pour le logiciel livré. - Planifier et effectuer des tests bêta : on livre, aux personnes qui ont déjà effectué les tests pendant le développement, un sous-ensemble du produit et on met en place des procédures pour enregistrer, regrouper et analyser leurs réactions. 4 LES ENCHAINEMENTS D ITERATION, ROLE DES TRAVAILLEURS DANS LE DEVELOPPEMENT D UN PROJET AVEC RUP La présentation des différents enchaînements d activités comme on les a présentés, peuvent donner l impression que RUP est un processus en cascade, il n en est rien. Il s agit de modèles idéalisés d enchaînements conçus pour donner un aperçu des activités réalisées au cours du développement. Christiane DAVOINE GUHUR Page /05/02

37 Figure 36 : Enchaînement d'activités de l'itération générique [Jacobson, et al 1999]. Dans un projet, les enchaînements des activités effectuées à chaque itération dépendent beaucoup de la nature du logiciel développé et de la phase du cycle de vie où on se trouve. Ce sont des enchaînements concrets susceptibles d être effectués au cours d une itération. Ils sont de la responsabilité d une personne qui doit assurer la cohérence avec les autres travailleurs dans l élaboration des artefacts pendant toute l itération. On va voir les enchaînements d activités de manière non exhaustive dans les trois exemples suivants : - Le premier qui se déroule dans la phase de création a pour objectif de définir la vision du produit, - Le deuxième est réalisé au début de la phase d élaboration, le but est de construire un prototype architectural, - Le troisième est effectué en fin de construction et vise à l implémentation du système. 4.1 EXEMPLE : DEFINIR LA VISION DU PRODUIT Pour définir la vision du produit et préparer l étude d opportunité, il faut effectuer un certain nombre d enchaînements d activités dans la phase de création, dite d inception. L enchaînement d activités qui va être décrit dans ce point s inscrit dans le cycle de développement initial d un produit, il serait différent s il s agissait d un cycle d évolution. - Dans l activité de démarrage on va définir la vision et la portée du système. Les intervenants travaillent avec les analystes système pour définir les ambitions du projet, les contraintes et les interfaces externes. A partir de la vision, le groupe commence à préparer une étude de rentabilité et une liste de risques. - Dans l activité de gestion des exigences on détermine et clarifie les fonctionnalités du système. Les analystes systèmes font une ébauche du modèle de cas d utilisation du système. Ils créent un glossaire pour simplifier la maintenance du modèle et assurer sa cohérence. - Dans l activité de gestion de projet on précise le plan de projet, on examine la faisabilité du projet et on établit le plan du projet. Après la réalisation de l ébauche du modèle de cas d utilisation, on traduit la vision en intégrant les aspects économiques, les coûts d investissement du projet, les ressources estimées, l environnement de développement, les critères de réussite et on commence l étude de rentabilité. A ce stade, on établit un ordre de priorité entre les fonctionnalités et les cas d utilisation, le chef de projet peut alors détailler le plan de projet. On définit un ensemble provisoire d itérations et on fixe les objectifs de chacune d elles. Le chef de projet construit un planning de phase qui Christiane DAVOINE GUHUR Page /05/02

38 contient les dates provisoires des phases de création, de construction, de transition et leurs jalons principaux. Les résultats de cette itération initiale sont les premières ébauches de la vision, de la portée et du plan du projet, ainsi que l étude d opportunité. Les délais évalués dans la phase de création ne sont donnés qu à titre indicatif. Les estimations du plan de projet initial sont grossières et deviennent plus réalistes au fur et à mesure que le projet avance [Kruchten 2000]. Figure 37 : Répartition du temps de planification par phase [Jacobson, et al 1999]. 4.2 EXEMPLE : CONSTRUIRE UN PROTOTYPE ARCHITECTURAL Nous allons voir ci-dessous les enchaînements d activités à dérouler dans le début de la phase d élaboration pour construire le prototype architectural ainsi que les travailleurs impliqués dans cette phase. La phase de création est terminée et le projet a passé le jalon de l objet du cycle de vie. L organisation possède une ébauche du modèle de cas d utilisation ainsi qu une version initiale du plan de projet. - Dans l activité de démarrage on ébauche le plan d itération, des risques et des objectifs architecturaux. En se basant sur le plan de projet, le chef de projet démarre le plan d itération avec l itération courante. Avec l architecte il établit les critères d évaluation de l architecture en considérant les risques architecturaux à éliminer. - Dans l activité de gestion des exigences on choisit les cas d utilisation et les scénarios qui piloteront le développement architectural. L architecte et le chef de projet définissent une vue initiale des cas d utilisation qui spécifie les scénarios à prendre en compte pendant l itération. Ces cas d utilisation et ces scénarios piloteront le développement architectural. Un certain nombre de spécificateurs de cas d utilisation décrivent en détail les cas d utilisation et les scénarios qui sont les plus critiques et les plus complexes. L analyste système peut avoir à restructurer le modèle de cas d utilisation dans son ensemble. Un concepteur d interface complète les cas d utilisation détaillés et construit l interface qu il soumet pour validation aux utilisateurs. - Dans l activité de gestion de projet on revoit les cas d utilisation et les risques. L architecte révise la vue des cas d utilisation à partir des nouvelles descriptions et éventuellement de la nouvelle structure du modèle des cas d utilisation. Le chef de projet met à nouveau à jour le plan d itération et reconsidère la gestion des risques si de nouveaux risques sont révélés. Christiane DAVOINE GUHUR Page /05/02

39 - Dans l activité d analyse et conception on détermine les classes évidentes, pour faire une répartition initiale des sous-systèmes et on examine en détail les cas d utilisation. Pour se faire une idée générale des classes évidentes et établir un début d organisation des sous-systèmes, l architecte prend en compte le cahier des charges, le glossaire, la vue des cas d utilisation et la connaissance générale que l équipe a du domaine. L architecte identifie les mécanismes d analyse qui forment une solution commune à un problème découvert pendant l analyse. On commence à écrire un document d architecture logicielle. En parallèle, une équipe de concepteurs, éventuellement aidée de l architecte, détermine les classes et les objets pertinents. Certains concepteurs définissent les responsabilités des classes, mettent en évidence leurs relations et leurs attributs. Puis l architecte identifie les classes architecturales significatives et les inclut dans la vue logique (document d architecture logicielle). L architecte organise, dans des paquetages des couches basses de l architecture, les classes qui offrent des services et les relient aux sous-systèmes qui les invoquent. Il traduit également les mécanismes de conception qui prennent en compte les contraintes et les services offerts par l environnement d implémentation ( système d exploitation, middleware, base de données). Les concepteurs instancient les classes de ces mécanismes, ils traduisent l ensemble des exigences détaillées pour chaque classe. L architecte s occupe des exigences. L architecte définit les tâches et les processus nécessaires ainsi que le réseau physique. Le résultat est le document d architecture logicielle. L architecte passe ensuite en revue l architecture. - Dans l activité d implémentation on s occupe de l organisation du code. L architecte considère l impact de la conception architecturale sur le modèle d implémentation et définit la vue d implémentation. Un intégrateur système définit dans quel ordre on doit implémenter les soussystèmes et les intégrer dans un prototype architectural. Le résultat de cette planification figure dans le plan de projet. Les implémenteurs écrivent le code et font les tests unitaires des classes. Les classes sont contenues dans les composants et les sous-systèmes du modèle d implémentation. Les testeurs d intégration testent ces sous-systèmes et les implémenteurs les livrent en vue de leur intégration. - Dans l activité de test on planifie les tests d intégration et les tests système. Le concepteur de test détermine et implémente les cas de test et les procédures de tests correspondants. Les tests d intégration permettent de vérifier la capacité du système à exécuter un scénario dans un certain délai ou sous une charge spécifiée. On évalue le prototype architectural. Une fois intégré, le système est testé par le testeur système. Le concepteur de test analyse les résultats pour vérifier que les buts sont atteints. L architecte évalue ensuite ces résultats au regard des risques identifiés. - Dans l activité de gestion de projet on évalue l itération. Le chef de projet compare les coûts, les délais et le contenu réel de l itération à ceux du plan d itération. Il détermine les éventuels éléments du système à reprendre. Il met à Christiane DAVOINE GUHUR Page /05/02

40 jour le plan de projet, il décrit sommairement le plan d itération dans l itération suivante [Kruchten 2000]. Le résultat de cette itération est une première version de l architecture, qui consiste en des vues architecturales assez bien décrites : la vue des cas d utilisation, la vue logique et la vue d implémentation et en un prototype architectural exécutable. Figure 38 : les "patatoï des" tracées à la main regroupent les principales activités de la phase création. 4.3 EXEMPLE : IMPLEMENTER LE SYSTEME L enchaînement d activités décrit dans cette section se déroule vers la fin de la phase de construction. Le cahier des charges est stable et une grande partie des fonctionnalités sont implémentées et intégrées prêtes à être testées. Le projet se prépare à passer le jalon de la capacité opérationnelle initiale. - Dans l activité de gestion de projet on planifie l itération. Le chef de projet met à jour le plan d itération en tenant compte des fonctionnalités à ajouter et des risques à atténuer au cours de cette nouvelle itération. - Dans l activité d implémentation on planifie l intégration au niveau système. L intégrateur système prend en considération l ordre dans lequel les soussystèmes doivent être assemblés pour former une configuration qui fonctionne et que l on puisse tester. Le plan d intégration dépend des fonctionnalités déjà implémentées et de la stratégie générale d intégration et de test à suivre. - Dans l activité de test on planifie et on conçoit les tests au niveau système. Le concepteur de test détermine et décrit les cas et les procédures de test dans le Christiane DAVOINE GUHUR Page /05/02

41 modèle de test. Il s assure que les procédures permettent d évaluer la satisfaction des exigences. - Dans l activité d analyse et conception on complète les réalisations de cas d utilisation. Les concepteurs donnent des responsabilités au cours des itérations précédentes et mettent en évidence leurs relations et leurs attributs. - Dans l activité de test on planifie et conçoit les tests d intégration au niveau des sous-systèmes et du système. Les tests d intégration s intéressent à la façon dont les composants sont connectés et fonctionnent ensemble. Le concepteur de test suit la stratégie générale de test définie dans le plan de test. - Dans l activité d implémentation on développe le code, les classes du modèle d implémentation en suivant les règles de programmation du projet et on fait les tests unitaires, on corrige les éventuelles anomalies. - L implémenteur conçoit des tests unitaires pour vérifier ce que fait l unité ( boîte noire) et comment elle le fait ( boîte blanche). Les tests en boîte noire s assurent que l unité dans les différents états est conforme aux spécifications. Les tests en boîte blanche s assurent que la conception est correctement implémentée. - Les tests unitaires portent sur les plus petits composants logiciel testables. L implémenteur de l unité les conçoit, les implémente et les exécute. Le but principal d un test unitaire est de s assurer que les tests en boîte blanche produisent les résultats attendus et soient aux normes de qualité du projet. - L implémenteur intègre un sous-système, il combine des classes complètement ou partiellement implémentées pour constituer une construction exécutable. - Les testeurs exécutent les procédures de test préalablement développées, ils font un rapport sur les anomalies qui devront être corrigées. - Quand le sous-système est suffisamment testé et prêt à être intégré au niveau du système, l implémenteur le livre. - L intégrateur système combine de façon incrémentale des sous-systèmes pour créer une construction complète. - Dans l activité de test du système on fait les tests d intégration. Les testeurs d intégration exécutent les tests d intégration préalablement développés et examinent les résultats. Une fois que le système complet est intégré, le testeur système le teste. Le concepteur de test analyse les résultats pour s assurer que les buts sont atteints. - Dans l activité de gestion de projet on évalue l itération. Le chef de projet compare les coûts, les délais et le contenu réels de l itération à ceux du plan d itération. Il détermine les éléments à reprendre et les itérations au cours desquelles il faudra le faire. Il met à jour la liste des risques et le plan de projet [Kruchten 2000]. Christiane DAVOINE GUHUR Page /05/02

42 Figure 39 : La "patatoï de" tracée à la main regroupe les principalement activités de la phase création [Jacobson, et al 1999]. 4.4 CARTOGRAPHIE DES ENCHAINEMENTS D ACTIVITES D UN DEVELOPPEMENT DE PROJET AVEC RUP. La cartographie générale d un projet avec RUP permet de voir qu à chaque itération, on fera intervenir les mêmes travailleurs et on produira les mêmes type d artefacts propres à la partie du système développée dans l itération. L objectif des itérations est d ajouter de nouvelles fonctionnalités au prototype et de produire un système plus complet. Les résultats de l itération constituent la base du développement pour l itération suivante et sont mis à disposition de tous les développeurs. Christiane DAVOINE GUHUR Page /05/02

43 Figure 40 : Cartographie d'un projet développé avec RUP [Jacobson, et al 1999]. Pour faire adopter le Processus unifié dans une société, il est recommandé de construire un prototype, afin de tester la démarche et l organisation indispensable pour sa réalisation. Figure 41 : L'approche typique pour mettre en place un processus et les outils [Jacobson, et al 1999]. Christiane DAVOINE GUHUR Page /05/02

44 5 CONCLUSION Le processus unifié est une démarche de développement adaptée au projet orienté objet. L utilisation d UML en est le garant. Ce processus préconise le déroulement d un cycle en quatre phases avec des jalons majeurs à chaque phase. Ceux-ci permettent une parfaite maîtrise des risques dans la gestion de projet du logiciel. Les sociétés qui adoptent ce processus doivent intégrer le changement d organisation et des méthodes de travail. En effet celui-ci à des impacts non négligeables sur l organisation rigoureuse des projets, la gestion des ressources et l identification des compétences. Ce processus a un avantage certain, c est qu il permet aux différentes ressources de développement d acquérir de nouvelles compétences dans les développements sur les technologies nouvelles. D autre part, la direction doit vendre le processus à ses clients. Celui-ci modifie la démarche d élaboration du système entre les utilisateurs qui expriment leurs besoins, l architecte qui assure sa conception et le chef de projet qui pilote la gestion du projet. La charge de travail des utilisateurs pour leur intervention plus régulière à la validation du système à chaque itération du cycle de vie est accrue et doit être bien évaluée. En revanche la sécurité procurée par l analyse des risques sur le système doit rassurer les directions concernées. Dans cette étude, il n a été abordé que le processus et l utilisation des produits Rational sans en évoquer le coût. Il apparaît évident que l utilisation du processus unifié et des outils de Rational ne peuvent concerner que des sociétés qui ont à développer des logiciels complexes et peuvent supporter une structure de développement importante. Il est toutefois envisageable pour des PME d utiliser le processus unifié et d utiliser ses propres outils de gestion de projet, de demande d évolution et de développement de logiciel pour répondre à la problématique des projets qui utilisent les technologies modernes, par exemple, basées sur les développements pour le Web. Ces sociétés doivent prévoir alors les interfaces entre les différents outils utilisés dans leurs sociétés et le processus unifié. Christiane DAVOINE GUHUR Page /05/02

45 6 BIBLIOGRAPHIE Ouvrages, publications diverses [Jacobson, et al 1999] Résumé [Kruchten 2000] Résumé [Lopez, et al 1998] Résumé [Muller, et al 2000] Résumé [Quatrani, 2000] Résumé [Rational, 2000] [Roques, et al 2000] Yvar Jacobson, Grady Booch et James Rumbaugh, de 1999 «Le Processus unifié de développement logiciel» Edition 2000 Eyrolles Cet ouvrage montre comment le processus unifié a précisément pour but de spécifier les différentes phases d un projet, de l élaboration du cahier des charges jusqu au déploiement de l application. C est un bon ouvrage un peu confus, mais les études de cas permettent un bon éclairage du processus. Philippe Kruchten «Introduction RUP» éditions 2000 Eyrolles Ce livre est à découvrir, il présente une autre approche du processus de développement logiciel, le processus (RUP) présenté par le fondateur du processus chez Rational. Il est compréhensible et méthodique, en complément l ouvrage «Le processus Unifié» de Ivar Jacobson est à utiliser pour approfondir certaines phases du développement. Ces deux ouvrages peuvent être considérés comme référence pour le développement de logiciel s appuyant sur le langage de modélisation graphique UML. Nathalie Lopez, Jorge Migueis et Emmanuel Pichon «Intégrer UML dans vos projets» éditions 1998 Eyrolles Ce livre apporte une réponse à l intégration d UML dans un projet. Il aborde les quatre phases de la modélisation UML, l analyse à l aide de uses cases, le modèle statique, le modèle dynamique et le modèle de conception sont expliqués à travers une étude de cas. Une analyse critique et constructive des principaux AGL est proposée également dans cet ouvrage. Pierre-Alain Muller et Nathalie Gaertner «Modélisation objet avec UML» éditions 2000 Eyrolles Ce livre est un très bon ouvrage par son approche à la modélisation objet dans une démarche globale de gestion de projet. Il est de plus illustré par deux études de cas. Terry Quatrani «Modélisation UML avec Rational Rose 2000» éditions 2000 Eyrolles Ce livre est un très bon ouvrage, facile d utilisation grâce à ses études de cas, il donne une réponse à tout utilisateur de Rational Rose pour mener un projet et décliner les différentes étapes de ce projet. Rational the e-development company «La solution d e-development de Rational» Octobre Décembre Pascal Roques et Franck Vallée «UML en action» éditions 2000 Eyrolles Christiane DAVOINE GUHUR 02/05/02

46 Résumé Ce livre est à découvrir, il présente une autre approche du processus de développement logiciel, le processus en Y (2TUP). Il apporte une réponse aux contraintes de changements continuels imposés aux systèmes d information de l entreprise. Il intègre en permanence l évolution fonctionnelle des métiers de l entreprise avec les contraintes de l architecture technique. Internet [INT1] [INT2] [INT3] Résumé Résumé Résumé Site UML francophone Ce site m a permis d accéder à la bibliographie UML et d obtenir une synthèse sur la démarche de modélisation graphique. Site RUP toutes langues Ce site m a permis de découvrir les deux processus unifiés. RUP (RUP) et 2TUP (Two Track Unified Process). Site Internet du Software Program Manager Network Ce site permet de consulter les meilleures pratiques de développement logiciel. Christiane DAVOINE GUHUR 02/05/02

47 RESUME Le Rational Processus Unifié (RUP) est un processus commercial produit et développé par la société Rational Software. Il s intègre à l ensemble des outils de développement proposés par Rational. Ce produit est une source de connaissances, toujours à jour, accessible en ligne sur le Web à partir du poste de travail du développeur. C est un cadre de processus et aussi un framework de processus génériques pouvant être adapté à une large classe de systèmes logiciels, à différents domaines d application et à différentes tailles de projet. Il utilise le langage de modélisation graphique UML (Unified Modelisation Language) pour la création des plans d élaboration et de construction d un système logiciel. Le processus unifié est un processus de développement logiciel qui regroupe les activités à mener pour transformer les besoins d un utilisateur en système logiciel. Les traits distinctifs de celui-ci tiennent en trois expressions clés : il est piloté par les cas d utilisation, centré sur l architecture, itératif et incrémental. Le processus unifié répète un certain nombre de cycles constituant la vie du système. L approche itérative recommandée par RUP permet de prendre en compte les changements qui interviennent souvent dans le cahier des charges. Elle permet de contrôler les risques plus rapidement dans le projet, puisque c est généralement au moment de l intégration qu ils apparaissent. Tout cycle se déroule en quatre phases, la création, l élaboration, la construction et la transition et un certain nombre d enchaînements d activités dont les principaux sont : l expression des besoins, l analyse, la conception, l implémentation, les tests, la gestion de configuration et le déploiement. Tout cycle aboutit à la livraison d une version de produit aux clients. Pour mener efficacement chaque cycle, les développeurs utilisent toutes les représentations du produit logiciel : un modèle de cas d utilisation, un modèle d analyse et de conception, un modèle d implémentation, de déploiement, un modèle de tests et un modèle d architecture du système. Tous ces modèles illustrent le système logiciel, pour les clients, les utilisateurs, les développeurs et facilitent ainsi leur compréhension pendant le cycle de vie du système. Mots clés : Processus unifié cas d utilisation architecture itératif incrémental enchaînement d activités phase exigence risque -