Modélisation et réalisation d un processus d ingénierie du logiciel

Transcription

1 Modélisation et réalisation d un processus d ingénierie du logiciel Adaptation et simplification du RUP RAPPORT DE STAGE DE TROISIEME ANNEE AVRIL-SEPTEMBRE Etudiant : Olivier DENIZON Responsable entreprise : Claude AUBRY Responsable IUP ISI : Henri MASSIE

2 Remerciements Je tiens à remercier Claude AUBRY pour m avoir accordé sa confiance pour ce stage ambitieux. Je veux également le remercier pour ses qualités de maître de stage et de gestionnaire de projet, ses prises de décisions objectives lors des points d avancement et constat de retard. Je le remercie aussi pour ses qualités humaines, sa sympathie, et pour s être montré conciliant. Je tiens à remercier les professeurs qui se sont impliqués dans ce projet, Messieurs Henri MASSIE et Bernard CHERBONNEAU pour avoir suivi ce projet, avoir fait l effort de relecture des documents produits et de participation a des réunions d avancement.... et sûrement pour l effort sans doute conséquent qu il leur faudra faire pour adapter leur enseignement à ce nouveau processus de développement. Je remercie Monsieur André ARICH de la société Rational de sa collaboration à ce projet, de s être déplacé à Toulouse pour des réunions de présentation et d avancement du projet, et de nous avoir gracieusement fourni une première version de l outil RPW. Je tiens également à remercier mes interlocuteurs du support technique de Rational, en particulier Peter et Sara, pour leur aide concernant l utilisation correcte de l outil RPW. Je remercie aussi Madame Wahiba BAHSOUN qui a bien voulu tolérer ma présence dans son bureau. 2

3 Contenu du document Le document consiste en 8 chapitres : Le premier chapitre introduit le stage et le projet réalisé, Le deuxième chapitre présente la cadre du projet, la société d accueil et l organisation du projet, Le troisième chapitre présente la modélisation des processus d ingénierie du logiciel et le méta-modèle SPEM, Le chapitre suivant présente les principes et éléments du processus réalisé, repris et adaptés du Rational Unified Process (ou RUP), Le chapitre 5 présente le Rational Process Workbench (RPW) : outil de Rational permettant la modélisation et la génération d un site web de processus implémenté à partir d un modèle de processus, Le chapitre 6 détaille le travail effectué pour définir et produire le RUPS (RUP simplifié) qui est le processus produit au cours du stage, Le chapitre 7 montre l exemple réalisé pour illustrer le processus : EasyStage Le dernier chapitre fait le bilan du projet et du stage. Des annexes apportent des compléments à la compréhension du domaine, du travail réalisé : le glossaire, la bibliographie, Chaque chapitre se termine par un paragraphe personnel sur ma participation aux aspects présentés, que ce soit pour montrer les difficultés d apprentissage ou de réalisation ou pour présenter les produits réalisés. 3

4 Table des matières 1 Le sujet du stage Objectif Portée du projet Cible du processus Motivation personnelle pour le sujet Environnement du projet Présentation de la société Organisation du projet Processus du projet Mon rôle dans le projet Modélisation de processsus Méthode et processus Processus et Processus générique Intérêt d un modèle Standard de modélisation Modéliser avec UML SPEM l espoir d un standard Le meta-modèle SPEM Modelisation pour le projet Mon rôle dans la modélisation Principes et éléments du processus Bonnes pratiques d ingénierie Principes Adaptation au développement et à la maintenance Un processus a deux dimensions Cycle itératif et incrémental Phases Eléments du processus Rôle Activité Etapes Guides de travail Produits de travail Plan type Rapport Guides de produit et points de contrôle

5 4.3.9 Workflow Discipline Groupe d'activités Guides outils Concepts Travail personnel sur les principes et éléments Rational Process Workbench (RPW) Pourquoi le RPW? Présentation du RPW Composition du RPW Le modèle de processus Le modèle de composants La "Process Content Library" Travail personnel sur l outil Définition et réalisation du RUPS Gestion de projet Environnement Définition du processus Réalisation du processus Modèle Librairies Génération du site Le déploiement du processus Quelques chiffres Travail personnel sur le RUPS Un exemple d illustration du processus Objectif Contenu Travail personnel sur l exemple Bilans Le projet Le produit Le stage Annexes Bibliographie Glossaire

6 1 LE SUJET DU STAGE Le stage a consisté en une participation à un projet sur les processus d ingénierie du logiciel. Un processus est un ensemble d'étapes partiellement ordonnées dont l'exécution vise à produire un logiciel. 1.1 OBJECTIF Le projet a pour objectif de définir un nouveau processus pour une organisation qui développe des logiciels. Le processus est réalisé par adaptation d un processus générique, le RUP (Rational Unified Process). Plus précisément on cherche à obtenir un processus : conforme aux standards dans le domaine, qui se présente sous forme de site Web, simplifié et en français, adapté à l organisation cible, que l on puisse faire évoluer facilement, avec un exemple en français permettant d'illustrer son utilisation sur un projet. 1.2 PORTEE DU PROJET Le début du stage coïncide avec le début du projet. La fin du stage correspond à la production d une version du processus. Cela constitue la première étape du déploiement d un processus dans une organisation. En effet, pour «implémenter un nouveau processus», il faut d abord évaluer le processus actuel, définir les évolutions, planifier leur réalisation, réaliser le nouveau processus, mais aussi former l organisation à son utilisation, essayer le processus sur un ou plusieurs projets pilote, faire une évaluation de cette utilisation, et puis refaire un ou plusieurs de ces cycles. Evaluation du processus actuel Planifier l implémentation du processus - au niveau organisation Nouveau Processus Evaluer l implémentation du processus Procéder à l implémentation - Configurer le processus - Générer le processus (RPW) - Former les équipes Figure 1 L'implémentation d'un processus Le projet ne prétend pas "implémenter" complètement un processus, et ne prend pas compte ni la 6

7 formation, ni l exécution du processus. Ces activités se dérouleront dans une seconde phase du projet. Pour cette première partie, on se consacre essentiellement à la maîtrise des risques majeurs liés à la modélisation et la réalisation d un processus. 1.3 CIBLE DU PROCESSUS L'organisation qui va utiliser le nouveau processus est celle mise en place pour les projets de bureaux d'études des étudiants de 2 ème et 3 ème année de l'iup ISI. L'IUP ISI est un Institut Universitaire Professionnalisé, spécialisé dans le génie logiciel et l'ingénierie des systèmes informatiques. Les étudiants sont sensibilisés aux processus de développement et mettent en œuvre les techniques enseignées sur des projets de 6 mois. Cette organisation mise en place depuis plus de 5 ans place les étudiants dans un contexte industriel. Le processus utilisé pour le développement des projets évolue d'année en année. Les projets achevés en 2001 utilisaient en partie un processus itératif et guidé par les cas d'utilisation. Tous les projets réalisés, et particulièrement les 8 projets de 2001, sont utilisés pour évaluer le processus actuel, et à définir le nouveau processus. Le RUP, dont l'iup a fait l'acquisition en septembre 2000, a été présenté aux étudiants et il est partiellement utilisé. Cependant le RUP tel quel est trop complexe dans ce contexte. C est pourquoi le processus produit sera un RUP simplifié, appelé RUPS. Il sera adapté à l organisation des bureaux d études. L utilisation du RUPS sur les projets commencera en octobre MOTIVATION PERSONNELLE POUR LE SUJET J ai choisi ce stage car il s inscrit dans mon projet professionnel. Au sein de la formation en IUP ISI, je me suis particulièrement épanoui dans la discipline du génie logiciel et j accorde une grande importance aux aspects qualité et gestion de projet lors d un travail. Ce stage porte sur un sujet qui m est familier : le génie logiciel et les bureaux d études ISI mais il fait aussi appel à des aspects nouveaux ou que j ai envie d approfondir : l utilisation du RUP, la modélisation UML, l utilisation de Rational Rose, les processus de développement logiciel. 7

8 2 ENVIRONNEMENT DU PROJET Le projet est réalisé par AubryConseil, en partenariat avec l IUP ISI, et avec la participation de Rational. 2.1 PRESENTATION DE LA SOCIETE AubryConseil est un cabinet de conseil créé par Claude Aubry, spécialisé dans les techniques d'ingénierie du logiciel et d'ingénierie système. Depuis 8 ans, AubryConseil assiste les entreprises dans l application des meilleures pratiques disponibles, dans les disciplines suivantes : l ingénierie métier, l'expression des besoins et exigences, l'analyse et la conception, la gestion de projet logiciel. Les prestations réalisées consistent le plus souvent en du transfert de technologie, auprès des équipes de développement, des nouvelles approches : les technologies objet, les cas d'utilisation et l ingénierie des exigences, le développement itératif, les architectures à base de composants, les langages de modélisation visuelle (UML en général, SDL pour le temps réel), les outils de modélisation, simulation et génération de code associés. La participation à de nombreux projets a permis de développer une compétence particulière dans les processus. Ces dernières années, les processus modernes liés à UML, et particulièrement le processus unifié (et le RUP) ont été mis en œuvre chez des clients. Cela permet de proposer aux entreprises des services complets autour de composants d un processus. Les services couvrent actuellement les premières phases (lancement, élaboration) et des disciplines dites en amont du développement, c est à dire les parties de processus les plus concernées par la modélisation. L offre comporte également des formations et notamment des formations UML avec de nombreuses formules, adaptées au rôle de chacun dans un projet. Les clients sont des grandes entreprises : Aerospatiale, CNES, Bouygues Telecom, des éditeurs : Rational, Telelogic et plus récemment des structures plus légères désireuses de passer à UML et de mettre en place un processus. 2.2 ORGANISATION DU PROJET Claude Aubry (AubryConseil) est le Responsable du Projet, et le tuteur du stage. L équipe projet est donc constituée de 2 personnes, avec la collaboration épisodique des enseignants de l IUP ISI. La connaissance de l organisation cible est assurée : Claude Aubry participe lui-même aux 8

9 enseignements et aux projets de Bureaux d Etudes de l IUP ISI. Des étudiants ayant participé aux projets 2001 ont également été sollicités, notamment pour l évaluation du processus actuel. Pour faciliter la communication des travaux effectués dans l équipe et à l extérieur, un site projet a été réalisé, à partir d un exemple fourni dans le RUP. Ce site a été régulièrement alimenté avec tous les documents de définition du projet, les documents de gestion du projet, les documents de réalisation et de déploiement du processus, les présentations des travaux effectués, les références bibliographiques. Figure 2 Site d avancement du projet, accessible sur le web 2.3 PROCESSUS DU PROJET Dans la mesure où cela s appliquait, un processus très simplifié reprenant les principes du RUP a été utilisé pour la fabrication du processus : gestion des risques définition des produits, des rôles et des activités, gestion de projet avec des points d avancement réguliers et prise d importantes décisions de changements (disciplines non traitées, stratégie d utilisation du RPW, de traduction des pages web ) cycle itératif, avec une évaluation et une actualisation constante des produits de travail au cours de revues, de réunions Le plan de développement initial comportait 5 itérations, chacune d un mois avec les objectifs suivants : Itération 1 9

10 Itération 2 Itération 3 Itération 4 Itération 5 o évaluation du processus actuel o buts du nouveau processus o liste des risques o projet Web du RUPS en place o utilisation réussie du RPW o un RUPS implémenté avec la discipline d Expression des exigences o un exemple présenté comme projet Web pour Exigences o un RUPS implémenté avec les disciplines Analyse et Conception et Gestion de projet o un exemple présenté comme projet Web pour Analyse et Conception et Gestion de projet o un RUPS implémenté avec les disciplines Implémentation et Test o un exemple présenté comme projet Web pour Implémentation et Test o un RUPS implémenté avec les disciplines Déploiement et Environnement o un exemple présenté comme projet Web pour Déploiement et Environnement 2.4 MON ROLE DANS LE PROJET J interviens principalement sur ce projet en tant qu analyste et développeur : c est moi qui ai la responsabilité d étudier et produire le nouveau processus de développement logiciel. Pour cela, j ai à : o rendre compte de l avancement de ce projet au travers du site projet (à mettre en place) o me familiariser avec les notions liées aux processus de développement logiciel o étudier le processus existant o modéliser le nouveau processus, déterminer quels éléments du RUP reprendre ou non o apprendre à me servir des outils existants pour la modélisation et l implémentation de processus o élaborer un site exemple mettant en application (à un projet de gestion des stages) les principes évoqués dans le processus réalisé o mettre en place le produit sur le site cible (local ou hébergeur web) Pour ces raisons, j interviens également comme quelqu un qui connaît le processus actuel pour avoir assumé différents rôles au cours de projets de bureaux d études ISI : développeur, analyste, responsable qualité 10

11 3 MODELISATION DE PROCESSSUS 3.1 METHODE ET PROCESSUS Avant de parler de modélisation, notons que le terme processus est relativement nouveau dans le domaine du logiciel : il y a quelques années on parlait de méthode. SADT, SA/RT, Hood et OMT se présentaient comme des méthodes, parfois restreintes à l analyse ou la conception. Si on revient aux débuts d UML, on se rappelle d ailleurs que les premiers travaux en 1995 portaient sur UM, la méthode unifiée, et que ce n est qu au bout de quelques mois que la décision de se consacrer uniquement au langage de modélisation et d abandonner le côté méthode a été prise. Cette décision est à l origine du succès d UML et de sa diffusion rapide. La raison évoquée pour séparer langage et méthode vaut toujours : il n est pas possible, il n est pas question d avoir une méthode unique utilisable sur tous les projets dans tous les domaines. C est comme pour la mondialisation : on peut faciliter les échanges, mais chacun doit conserver sa culture et son savoir-faire. Un processus intellectuel comme celui des développements de logiciel est un bien culturel d une organisation. Donc pas de méthode universelle, et même pas de méthode unique liée à la technologie objet et au langage UML. Les processus dits modernes sont apparus après la standardisation d UML qui a débarrassé la communauté du génie logiciel des problèmes de langage. Le processus unifié et le RUP, Fusion, OPEN, à un degré moindre Catalysis, plus récemment et différemment XP et les processus «agiles» se présentent comme des processus pour l ingénierie du logiciel. La notion de processus est plus large que celle de méthode, elle se rapproche plutôt de méthodologie, c est-à-dire d un tout couvrant l ensemble des activités d un projet logiciel. Les processus modernes englobent par exemple la gestion de projet, et ne se cantonnent pas au développement. 3.2 PROCESSUS ET PROCESSUS GENERIQUE Puisqu il n y a pas de méthode unifiée, pourquoi y aurait-il un processus unifié? Les processus évoqués plus haut ne sont pas applicables directement : ils définissent des principes et une architecture, mais doivent être adaptés à l organisation et au projet visés. Ce sont des processus génériques. C est le cas du RUP, qui est d ailleurs présenté comme un "framework". Nous utiliserons le terme processus générique plutôt que processus unifié. Le processus que nous avons développé, le RUPS, a été créé à partir du processus générique RUP. 3.3 INTERET D UN MODELE On ne débat pas ici de savoir s il faut un processus pour développer du logiciel. Ni même de savoir si le processus doit être lourd ou léger : c est le travail nécessaire pour l adaptation qui doit le dire, 11

12 notamment l évaluation de l organisation actuelle. Les arguments pour modéliser un processus sont les mêmes que ceux utilisés pour modéliser un logiciel. Il y a des inconvénients : Modéliser, c est toujours difficile. Modéliser un processus, ça l est encore plus : on s attaque à des activités humaines. Modéliser prend du temps et le cycle de validation est très long : il faut essayer le processus sur un projet. Le premier bénéfice est que le fait de réfléchir à un modèle permet de se poser des questions bien plus précises. Les autres bénéfices viennent des facilités apportées pour la communication et la mise à jour du processus, et sa génération automatique à partir du modèle. Ces bénéfices sont liés à l existence d un langage standard pour décrire les processus et d outils pour automatiser sa fabrication. 3.4 STANDARD DE MODELISATION MODELISER AVEC UML La communauté du logiciel a très vite adopté UML comme standard de modélisation pour le logiciel. Il est tentant d utiliser UML pour modéliser les processus d ingénierie du logiciel. Le langage est riche et permet d être étendu facilement aux besoins d un domaine avec les stéréotypes. Cependant UML n a pas été conçu pour cela. Il peut donc y avoir une grande diversité dans les éléments de modélisation UML employés, et les stéréotypes mis en œuvre. Bref il y a un besoin d une certaine forme de standardisation sur l adaptation d UML à la modélisation des processus SPEM L ESPOIR D UN STANDARD L OMG (Object Management Group), à l origine d UML, a fait une RFP (Request For Proposal) sur le «Software Process Engineering Management» en novembre Le résultat est le SPEM (Software Process Engineering Metamodel). Nous faisons référence ici à la version ad diffusée le 2 avril Les travaux de l OMG ont été réalisés avec la collaboration des sociétés spécialistes des processus de génie logiciel tels qu IBM, Fujitsu, Unisys, Alcatel et bien entendu Rational. Ce qui explique que le RUP soit déjà largement conforme au SPEM. Le résultat des travaux est un méta-modèle pour la description des processus. Il présente l utilisation d UML avec une approche orientée objet pour décrire des processus de logiciel. Cette utilisation d UML correspond à la notion de profil, qui sera un des axes d évolution de la version 2.0. L objectif du SPEM est de définir un langage commun pour décrire des processus, mais aussi de faciliter la communication entre les différents outils de fabrication de processus. Le SPEM permet d unifier le vocabulaire utilisé pour décrire les processus. Entre deux processus, bien souvent le même terme est utilisé et compris de façon différente. Par exemple : activité, phase, itération. 12

13 Le glossaire fourni en annexe traduit et enrichit les définitions du SPEM LE META-MODELE SPEM L idée centrale du SPEM est qu un processus est la collaboration entre des entités actives et abstraites appelées Rôles qui réalisent des opérations appelées Activités sur des entités concrètes et tangibles appelées Produits de travail. La figure 3 ci-dessous montre ce concept fondamental avec la notation UML de la classe. Role activity1(workproduct1) activity2(workproduct2) Figure 3 Description d un rôle dans le SPEM au moyen de classe UML A partir de ce modèle, on peut "réifier" activité et produit, pour aboutir au simple modèle (incomplet) de la figure ci-dessous, base du méta-modèle. Role 1 IsResponsibleFor 0..* WorkProduct 1 input 0..* output 0..* Performs Uses Produces 0..* 0..* Activity 0..* Figure 4 Diagramme UML montrant les interactions existant entre rôles, activités et produits Plusieurs rôles peuvent collaborer par l échange de produits et le déclenchement de l exécution de certaines activités. Le but global de l exécution d un processus est de fournir un ensemble de produits de travail dans un état bien défini. Nous n irons pas plus loin dans la description du méta-modèle. La plupart des concepts sont repris dans la présentation du RUPS. 3.5 MODELISATION POUR LE PROJET Notre objectif est de réaliser un processus à partir du RUP générique, et conforme aux standards. Le SPEM est supporté par le Rational Process Workbench (RPW), qui est un outil de fabrication de processus basé sur UML. 13

14 Méta-modèle de processus Modèle de processus Exécution de processus SPEM conforme à RUP adapté de RUPS guidé par RUPS mis en oeuvre Figure 5 Les niveaux de modèles Nous avons décidé d utiliser le RPW qui fournit le modèle du RUP, conforme au SPEM. Une partie du travail nécessaire pour produire le RUPS peut ainsi se faire au niveau du modèle. Notre travail de modélisation a consisté à définir notre processus en supprimant, en réutilisant, ou en spécialisant des parties du modèle du RUP. Notons que le RUPS est lui-même un modèle de processus pouvant être «instancié» sur des projets. 3.6 MON ROLE DANS LA MODELISATION Je me suis penché sur la modélisation de processus en étudiant d abord les travaux de l OMG sur la méta-modélisation, qui m ont permis de mieux comprendre les relations entre les divers éléments constituant un processus (desquels nous avons tiré un glossaire en français, fourni en annexe, des termes utilisés pour la modélisation de processus). Pour en revenir à la modélisation, j ai eu à modéliser notre processus au travers de l outil RPW au moyen de nombreux diagrammes UML : diagrammes de classes, diagrammes d activités, diagrammes de composants organisés en paquetages. Pour cela, j ai utilisé les nombreux stéréotypes permettant de définir les différents éléments constituant un processus : rôle, activité, modèles, documents... La figure 6 ci dessous montre un des nombreux diagrammes UML réalisés. Il s agit d un diagramme de classe, avec des associations entre rôles et documents et des généralisations entre les rôles. 14

15 Figure 6 Les rôles participant à une discipline 15

16 4 PRINCIPES ET ELEMENTS DU PROCESSUS Le RUPS est adapté du RUP. Il s appuie sur les mêmes pratiques d ingénierie, reprend la plupart de ses principes et est composé des mêmes types d éléments. 4.1 BONNES PRATIQUES D INGENIERIE Le RUP repose sur 6 «piliers» : développement itératif, gestion des exigences, modélisation visuelle, architecture basée sur des composants, vérification continuelle de la qualité, gestion des modifications et de la configuration. 4.2 PRINCIPES ADAPTATION AU DEVELOPPEMENT ET A LA MAINTENANCE Un processus est un ensemble d'étapes partiellement ordonnées dont l'exécution vise à atteindre un objectif ; dans le domaine de l'ingénierie du logiciel cet objectif est la réalisation d'un produit logiciel ou sa maintenance. Exprimé en terme de modélisation, un processus d'ingénierie du logiciel est un processus métier dont l'objectif est d'améliorer l'organisation qui développe des logiciels; le Rational Unified Process (RUP) est un processus métier générique pour le développement logiciel orienté objet. Le processus a pour but d'assurer la production d'un logiciel de qualité qui réponde aux besoins des utilisateurs finaux, dans le respect des coûts et des délais; pour cela il repose sur des principes : il fournit une approche "disciplinée" de l affectation des tâches et responsabilités à l'intérieur de l'organisation de développement. il inclut ce qu'on appelle la maintenance. Lorsqu'un système logiciel est développé de bout en bout, le développement est le processus de création d'un système à partir des exigences. Mais une fois que le système a pris forme ( dès qu'il a dépassé le cycle de développement initial), tout développement ultérieur est un processus de conformité du système à de nouvelles exigences ou des exigences qui ont été modifiées. Ceci s'applique tout au long du cycle de vie du système. Figure 7 Objectif d un processus 16

17 4.2.2 UN PROCESSUS A DEUX DIMENSIONS Figure 8 La présentation schématique du processus selon deux axes, dite graphe à bosses Ce processus se décline sur deux axes : l axe horizontal représentant la séquence de travail dans le temps : le cycle de vie du processus, et l'exprime en termes de phases, itérations, et jalons l axe vertical représentant l organisation du travail en termes de composants de processus (disciplines, workflows, groupes d activités, produits de travail, activités, rôles ) Cette distinction est fondamentale : elle permet de mettre réellement en place des itérations CYCLE ITERATIF ET INCREMENTAL Le principal problème de cycle "en V" est qu on repousse la gestion des risques très tard dans le développement, de telle sorte que leur occurrence est très coûteuse parce qu il s agit de réparer des erreurs des phases précédentes. Ceci conduit à des retards, des surcoûts, voire l annulation du projet. L alternative est le cycle itératif et incrémental. Inspiré du modèle en spirale de Barry BOEHM, il est basé sur l identification des risques sur le projet très tôt dans le cycle de vie, lorsqu il est encore possible de les contenir, les atténuer, les contourner. Une autre caractéristique de ce cycle est l élaboration de produits tangibles (itérativement jusqu à leur complétude) lors de chaque phase : documents, prototypes, modèles, code, exécutables... Cela permet de régler certains problèmes actuels du développement logiciel : Pas d effet tunnel : on ne s aperçoit plus trop tard que l on n était pas d accord sur un point car les éléments sont produits très tôt et vérifiés en fin d itération ou de phase en non en fin de projet. Meilleure communication entre les développeurs et les utilisateurs finaux du logiciel au travers de la discipline d Expression des exigences. L équipe de développement ne se concentre à un moment donné que sur les risques les plus critiques. 17

18 Le test continuel des produits élaborés permet d évaluer objectivement l avancement du projet. (ce qui d ailleurs diminue la charge du test en fin de projet puisque le test est réparti sur toute la longueur du projet) Les incohérences entre les exigences, la conception et l implémentation sont détectées très tôt. L équipe de développement améliore continuellement le processus au travers de son expérience et des leçons tirées de ses projets passés. Les intervenants sur le projet sont mieux pris en considération. La souplesse de ce cycle de développement permet de gérer plus facilement et à tout moment les demandes de modification ou l occurrence des risques. Pas de «big bang» final ; l effort de développement est relativement constant tout au long du développement ; les éléments produits sont intégrés au fur et à mesure. Facilité de réutilisation par l approche de décomposition en composants PHASES Les itérations s exécutent dans le cadre de phases. Toutes les phases ne sont pas identiques en termes de durée ou d'effort. Le cycle de vie est composé de 4 phases : lancement («inception»), élaboration, construction et transition. Selon une perspective de gestion de projet, chacune de ces 4 phases séquentielles est conclue par un jalon important. Figure 9 L enchaînement des phases et des jalons PHASE DE LANCEMENT Le Lancement est la phase au cours de laquelle on décide de l opportunité de réaliser ou non le projet. Les objectifs principaux de la phase de Lancement sont de : définir une vision partagée du projet, avec ce que contient ou non le produit, et les critères d'acceptation. déterminer les cas d'utilisation critiques du système, les scénarios donnant lieu aux principaux points d'interrogation sur la conception. montrer, voire démontrer, au moins une architecture qui se plie à ces différents scénarios. estimer globalement les coûts et les délais du projet (plus de détails à venir en phase d'élaboration) estimer les risques potentiels (les sources de l'imprévisibilité). 18

19 préparer l'environnement de développement du projet PHASE D ELABORATION L élaboration est la phase au cours de laquelle on vise à obtenir une architecture stable du système pour avoir une base solide lors de l'effort de conception et d'implémentation en phase de Construction. L'architecture dépend : des exigences qui ont le plus d'impact sur l'architecture du système, de l'évaluation des risques. La stabilité de l'architecture est démontrée au moyen d'un ou plusieurs prototypes d'architecture. Les objectifs principaux de la phase d'élaboration sont de : s'assurer que l'architecture (à partir de scénarios significatifs), les exigences et les plans sont assez stables, que les risques significatifs du point de vue de l'architecture sont suffisamment atténués pour qu'on puisse élaborer des prévisions fiables pour les coûts et la durée du développement restant. produire un prototype évolutif avec des composants de qualité, de même qu'un ou plusieurs prototypes "exploratoires" jetables pour atténuer les risques (changements de conception, d'exigences, réutilisation de composants, faisabilité du produit) ou faire des démonstrations à des investisseurs, des clients ou de futurs utilisateurs démontrer que l'architecture supportera les exigences du système (dans des coûts et des délais raisonnables). définir et mettre en place l'environnement de développement (rédaction d'un plan de cycle de vie du projet, de plans types, de guides, et pré-configurer les outils) PHASE DE CONSTRUCTION La construction est la phase au cours de laquelle on réalise le système à partir de l'architecture stabilisée. La phase de construction est en un sens l étape de production, où l'accent est mis sur la gestion des ressources et le contrôle des opérations pour optimiser les coûts, les délais et la qualité. Les objectifs principaux de la phase de construction sont de: minimiser des coûts de développement par l'optimisation des ressources. Il est essentiel de disposer d'une architecture robuste si l'on veut atteindre un haut degré de parallélisme de ces ressources. atteindre la qualité adéquate rapidement. produire des versions utilisables (alpha, bêta, et autres versions de test) aussi vite que possible. compléter l'analyse, la conception, le développement et le test de toutes les fonctionnalités. développer itérativement et de façon incrémentale un produit complet prêt à la transition vers la communauté des utilisateurs (cela implique la description des cas d'utilisation restants, d'étoffer la conception, de compléter l'implémentation, et tester le logiciel). 19

20 décider si le logiciel, les sites et les utilisateurs sont prêts au déploiement de l'application PHASE DE TRANSITION Lors de la phase de transition on s'assure que le logiciel est disponible pour les utilisateurs finaux. La phase de transition peut s'étaler sur plusieurs itérations, inclure le test du produit avant sa sortie et les ajustements mineurs basés sur les remarques faites par les utilisateurs (pour de petites améliorations de la configuration, l'installation et les problèmes d'utilisation). A la fin de la phase de transition, les objectifs doivent avoir été atteints et le projet doit être sur le point d'être clos. Les objectifs principaux de la phase de Transition sont : l'accord des intervenants sur le fait que le déploiement de la version de référence est terminé et conforme aux critères d'acceptation du produit. le bêta test pour valider le nouveau système en fonction des attentes des utilisateurs. l'installation des bases de données opérationnelles. la formation des utilisateurs et responsables de la maintenance. la correction des bugs, l'amélioration des performances et de l'utilisabilité. Il est aussi important d'atteindre l'autonomie de l'utilisateur sur le logiciel. 4.3 ELEMENTS DU PROCESSUS Figure 10 Eléments du Rational Unified Process repris pour le RUPS 20