Rational Unified Process

Dimension: px
Commencer à balayer dès la page:

Download "Rational Unified Process"

Transcription

1 Rational Unified Process For Christiane DAVOINE-GUHUR Société GICAB - Vannes

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

Le Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer

Le Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer Le Processus RUP Database Administrator Project Leader H. Kadima Performance Engineer Release Engineer Analyst Designer / Developer Tester Table des matières 1. De l artisanat à l industrialisation de

Plus en détail

Concevoir des applications Web avec UML

Concevoir des applications Web avec UML Concevoir des applications Web avec UML Jim Conallen Éditions Eyrolles ISBN : 2-212-09172-9 2000 1 Introduction Objectifs du livre Le sujet de ce livre est le développement des applications web. Ce n est

Plus en détail

Chapitre I : le langage UML et le processus unifié

Chapitre I : le langage UML et le processus unifié I. Introduction Les méthodes d analyse orientées objet sont initialement issues des milieux industriels. La préoccupation dominante de leurs auteurs est le génie logiciel, c est-àdire les principes et

Plus en détail

MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE»

MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE» MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE» Du cours Modélisation Semi -Formelle de Système d Information Du Professeur Jean-Pierre GIRAUDIN Décembre. 2002 1 Table de matière Partie 1...2 1.1

Plus en détail

basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML

basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML http://olivier-augereau.com Sommaire Introduction I) Les bases II) Les diagrammes

Plus en détail

Analyse,, Conception des Systèmes Informatiques

Analyse,, Conception des Systèmes Informatiques Analyse,, Conception des Systèmes Informatiques Méthode Analyse Conception Introduction à UML Génie logiciel Définition «Ensemble de méthodes, techniques et outils pour la production et la maintenance

Plus en détail

Architecture Logicielle

Architecture Logicielle Architecture Logicielle Chapitre 3: UML pour la description et la documentation d une architecture logicielle Année universitaire 2013/2014 Semestre 1 Rappel L architecture d un programme ou d un système

Plus en détail

Projet : Plan Assurance Qualité

Projet : Plan Assurance Qualité Projet : Document : Plan Assurance Qualité 2UP_SPEC_DEV1 VERSION 1.00 Objet Ce document a pour objectif de définir la démarche d analyse et de conception objet ainsi les activités liées. Auteur Eric PAPET

Plus en détail

Modélisation Principe Autre principe

Modélisation Principe Autre principe Modélisation Principe : un modèle est une abstraction permettant de mieux comprendre un objet complexe (bâtiment, économie, atmosphère, cellule, logiciel, ). Autre principe : un petit dessin vaut mieux

Plus en détail

Le Rational Unified Process

Le Rational Unified Process Le Rational Unified Process Philippe Kruchten, Rational Software Canada Janvier 1999 Note : Ce texte est extrait d u livre Philippe Kruchten, Introduction au Rational Unified Process, Editions Eyrolles,

Plus en détail

IFT2255 : Génie logiciel

IFT2255 : Génie logiciel IFT2255 : Génie logiciel Chapitre 6 - Analyse orientée objets Section 1. Introduction à UML Julie Vachon et Houari Sahraoui 6.1. Introduction à UML 1. Vers une approche orientée objet 2. Introduction ti

Plus en détail

Architecture d'entreprise : Guide Pratique de l'architecture Logique

Architecture d'entreprise : Guide Pratique de l'architecture Logique Guides Pratiques Objecteering Architecture d'entreprise : Guide Pratique de l'architecture Logique Auteur : Version : 1.0 Copyright : Softeam Equipe Conseil Softeam Supervisée par Philippe Desfray Softeam

Plus en détail

Analyse et conception de systèmes d information

Analyse et conception de systèmes d information Analyse et conception de systèmes d information Présentation réalisée par P.-A. Sunier Professeur à la HE-Arc de Neuchâtel http://lgl.isnetne.ch Juin 2005 [SJB-02] Chapitre 3 1 Références Ce document a

Plus en détail

Génie logiciel (Un aperçu)

Génie logiciel (Un aperçu) (Un aperçu) (sommerville 2010) Laurent Pérochon INRA URH 63122 St Genès Champanelle Laurent.perochon@clermont.inra.fr Ensemble d activités conduisant à la production d un logiciel Sur un échantillon de

Plus en détail

Développement itératif, évolutif et agile

Développement itératif, évolutif et agile Document Développement itératif, évolutif et agile Auteur Nicoleta SERGI Version 1.0 Date de sortie 23/11/2007 1. Processus Unifié Développement itératif, évolutif et agile Contrairement au cycle de vie

Plus en détail

Le génie logiciel. maintenance de logiciels.

Le génie logiciel. maintenance de logiciels. Le génie logiciel Définition de l IEEE (IEEE 1990): L application d une approche systématique, disciplinée et quantifiable pour le développement, l opération et la maintenance de logiciels. Introduction

Plus en détail

Méthodologies de développement de logiciels de gestion

Méthodologies de développement de logiciels de gestion Méthodologies de développement de logiciels de gestion Chapitre 5 Traits caractéristiques des deux approches de méthodologie Présentation réalisée par P.-A. Sunier Professeur à la HE-Arc de Neuchâtel http://lgl.isnetne.ch

Plus en détail

UML Mise en œuvre dans un projet. Emmanuel Pichon 2013

UML Mise en œuvre dans un projet. Emmanuel Pichon 2013 UML Mise en œuvre dans un projet 2013 Introduction Rôles et activités dans un projet Définir la méthode de votre projet Adapter la modélisation à la méthode de votre projet Conseils de mise en œuvre de

Plus en détail

Direction Générale des Études Technologiques. Institut Supérieur des Etudes Technologiques de Djerba Département Technologies de l informatique

Direction Générale des Études Technologiques. Institut Supérieur des Etudes Technologiques de Djerba Département Technologies de l informatique Direction Générale des Études Technologiques Institut Supérieur des Etudes Technologiques de Djerba Département Technologies de l informatique Génie Logiciel Mejdi BLAGHGI m.blaghgi@gmail.com Chapitre

Plus en détail

Génie logiciel. Concepts fondamentaux. Bruno MERMET, Université du Havre 1

Génie logiciel. Concepts fondamentaux. Bruno MERMET, Université du Havre 1 Génie logiciel Concepts fondamentaux Bruno MERMET, Université du Havre 1 Nécessité du Génie Logiciel Bruno MERMET, Université du Havre 2 Développement d un logiciel Caractéristiques souhaitées : Adéquation

Plus en détail

FILIÈRE METHODOLOGIE & PROJET

FILIÈRE METHODOLOGIE & PROJET FILIÈRE METHODOLOGIE & PROJET 109 Gestion de projet METHODOLOGIE ET PROJET Durée 3 jours Conduite de projet COND-PRO s Intégrer les conditions de réussite d une démarche de management par projet. Impliquer

Plus en détail

Aligner Stratégie d Entreprise et Infrastructure Informatique

Aligner Stratégie d Entreprise et Infrastructure Informatique Logiciels IBM Rational Janvier 2005 Aligner Stratégie d Entreprise et Infrastructure Informatique IBM Rational Software Development Platform & Business-Driven Development Page 2 Table des matières 1 L

Plus en détail

Méthodes de conception pour les logiciels

Méthodes de conception pour les logiciels lab-sticc.univ-brest.fr/~babau/ Méthodes de conception pour les logiciels Jean-Philippe Babau Département Informatique, UFR Sciences, Laboratoire Lab-STICC 2 1 Plan Introduction Pourquoi une méthode? Objectifs

Plus en détail

Cycle de vie du logiciel. Unified Modeling Language UML. UML: définition. Développement Logiciel. Salima Hassas. Unified Modeling Language

Cycle de vie du logiciel. Unified Modeling Language UML. UML: définition. Développement Logiciel. Salima Hassas. Unified Modeling Language Unified Modeling Language UML Salima Hassas Version Cycle de vie du logiciel Client Besoins Déploiement Analyse Test Conception Cours sur la base des transparents de : Gioavanna Di Marzo Serugendo et Frédéric

Plus en détail

CONCEPTS ET MISE EN PRATIQUE POUR LA VALIDATION DE GRANDS SYSTÈMES

CONCEPTS ET MISE EN PRATIQUE POUR LA VALIDATION DE GRANDS SYSTÈMES MODEL-BASED TESTING (MBT) CONCEPTS ET MISE EN PRATIQUE POUR LA VALIDATION DE GRANDS SYSTÈMES Le Model-Based Testing est une pratique de test en plein développement dans l'industrie pour accroitre l'efficacité

Plus en détail

Industrialiser la chaîne complète de fabrication 1ère partie - Les bénéfices de la solution logicielle IBM VisualAge Pacbase / Rational

Industrialiser la chaîne complète de fabrication 1ère partie - Les bénéfices de la solution logicielle IBM VisualAge Pacbase / Rational IBM Software Group Industrialiser la chaîne complète de fabrication 1ère partie - Les bénéfices de la solution logicielle IBM VisualAge Pacbase / Rational Fernard Bonaguidi fernand.bonaguidi@fr.ibm.com

Plus en détail

Processus d Informatisation

Processus d Informatisation Processus d Informatisation Cheminement de la naissance d un projet jusqu à son terme, deux grandes étapes : Recherche ou étude de faisabilité (en amont) L utilisateur a une idée (plus ou moins) floue

Plus en détail

Aperçu général sur la technologie des Workflows

Aperçu général sur la technologie des Workflows Aperçu général sur la technologie des Workflows Zakaria Maamar Groupe Interfonctionnement Section Technologie des systèmes d'information Centre de recherches pour la défense Valcartier 2459 boul. Pie-XI

Plus en détail

Conduite de projets et architecture logicielle

Conduite de projets et architecture logicielle s et architecture logicielle ABCHIR Mohammed-Amine Université Paris 8 15 février 2011 1/36 ABCHIR Mohammed-Amine (Université Paris 8) Conduite de projets et architecture logicielle 15 février 2011 1 /

Plus en détail

Conception, architecture et urbanisation des systèmes d information

Conception, architecture et urbanisation des systèmes d information Conception, architecture et urbanisation des systèmes d information S. Servigne Maître de Conférences, LIRIS, INSA-Lyon, F-69621 Villeurbanne Cedex e-mail: sylvie.servigne@insa-lyon.fr 1. Introduction

Plus en détail

Quatrième partie IV. La documentation

Quatrième partie IV. La documentation Quatrième partie IV Les différents types de Constat Il n y a pas de logiciel de qualité sans une documentation de qualité est un outil de communication Les paroles s envolent, les écrits restent Exemple

Plus en détail

Business Project Management : Cycle de vie des documents et workflow

Business Project Management : Cycle de vie des documents et workflow Business Project Management : Cycle de vie des documents et workflow Iut de Tours Département Information-Communication Option Gestion de l Information et du Document dans les Organisations Page 1 sur

Plus en détail

Génie logiciel avec UML. Notions sur le langage UML adapté pour les cours du programme Techniques de l informatique

Génie logiciel avec UML. Notions sur le langage UML adapté pour les cours du programme Techniques de l informatique Génie logiciel avec UML Notions sur le langage UML adapté pour les cours du programme Techniques de l informatique Claude Boutet Session hiver 2008 Modélisation de systèmes Table des matières TABLE DES

Plus en détail

Identification du module

Identification du module Identification du module Numéro de module 475 Titre Développer une analyse pour une application Compétence Développer à partir des exigences fonctionnelles et non fonctionnelles pour une application, les

Plus en détail

O RMATION. Ingénierie Système Management de Projet Évaluation de la Maturité

O RMATION. Ingénierie Système Management de Projet Évaluation de la Maturité PLANS F de O RMATION Ingénierie Système Management de Projet Évaluation de la Maturité O R G A N I S A T I O N ACTEURS CONCERNÉS Les concepteurs de systèmes doivent détecter, analyser les besoins des utilisateurs,

Plus en détail

Vérifier la qualité de vos applications logicielle de manière continue

Vérifier la qualité de vos applications logicielle de manière continue IBM Software Group Vérifier la qualité de vos applications logicielle de manière continue Arnaud Bouzy Kamel Moulaoui 2004 IBM Corporation Agenda Analyse de code Test Fonctionnel Test de Performance Questions

Plus en détail

Cours Gestion de projet

Cours Gestion de projet Cours Gestion de projet Méthodes de conduite de projet Version Date Auteur V1.8 Septembre 2007 Pascal HEYER 1 Méthodes de conduite de projet Ce document est publié sous la licence libre Creative Commons-BY-NC-SA

Plus en détail

Université de Bangui. Modélisons en UML

Université de Bangui. Modélisons en UML Université de Bangui CRM Modélisons en UML Ce cours a été possible grâce à l initiative d Apollinaire MOLAYE qui m a contacté pour vous faire bénéficier de mes connaissances en nouvelles technologies et

Plus en détail

Gé nié Logiciél Livré Blanc

Gé nié Logiciél Livré Blanc Gé nié Logiciél Livré Blanc Version 0.2 26 Octobre 2011 Xavier Blanc Xavier.Blanc@labri.fr Partie I : Les Bases Sans donner des définitions trop rigoureuses, il faut bien commencer ce livre par énoncer

Plus en détail

2. Activités et Modèles de développement en Génie Logiciel

2. Activités et Modèles de développement en Génie Logiciel 2. Activités et Modèles de développement en Génie Logiciel Bernard ESPINASSE Professeur à l'université d'aix-marseille Plan Les Activités du GL Analyse des besoins Spécification globale Conceptions architecturale

Plus en détail

UML Diagramme de communication (communication diagram) Emmanuel Pichon 2013

UML Diagramme de communication (communication diagram) Emmanuel Pichon 2013 UML Diagramme de communication (communication diagram) 2013 Diagramme de communication (communication diagram) Utilisation / objectifs Sens Ce diagramme présente des objets, des acteurs, des liens et des

Plus en détail

INF 1250 INTRODUCTION AUX BASES DE DONNÉES. Guide d étude

INF 1250 INTRODUCTION AUX BASES DE DONNÉES. Guide d étude INF 1250 INTRODUCTION AUX BASES DE DONNÉES Guide d étude Sous la direction de Olga Mariño Télé-université Montréal (Québec) 2011 INF 1250 Introduction aux bases de données 2 INTRODUCTION Le Guide d étude

Plus en détail

Projet 2. Gestion des services enseignants CENTRE D ENSEIGNEMENT ET DE RECHERCHE EN INFORMATIQUE. G r o u p e :

Projet 2. Gestion des services enseignants CENTRE D ENSEIGNEMENT ET DE RECHERCHE EN INFORMATIQUE. G r o u p e : CENTRE D ENSEIGNEMENT ET DE RECHERCHE EN INFORMATIQUE Projet 2 Gestion des services enseignants G r o u p e : B E L G H I T Y a s m i n e S A N C H E Z - D U B R O N T Y u r i f e r M O N T A Z E R S i

Plus en détail

Use Cases. Introduction

Use Cases. Introduction Use Cases Introduction Avant d aborder la définition et la conception des UC il est bon de positionner le concept du UC au sein du processus de développement. Le Processus de développement utilisé ici

Plus en détail

RAPPORT DE CONCEPTION UML :

RAPPORT DE CONCEPTION UML : Carlo Abi Chahine Sylvain Archenault Yves Houpert Martine Wang RAPPORT DE CONCEPTION UML : Bamboo Ch@t Projet GM4 Juin 2006 Table des matières 1 Introduction 2 2 Présentation du logiciel 3 2.1 Précisions

Plus en détail

Guichet automatique de banque

Guichet automatique de banque Guichet automatique de banque Mastère 2004 1 Guichet automatique de banque : GAB Objectif : Illustrer la vue fonctionnelle et particulièrement la définition des cas d utilisation. 1. Spécification du problème

Plus en détail

Concevoir des applications Web avec UML

Concevoir des applications Web avec UML Concevoir des applications Web avec UML Jim Conallen Éditions Eyrolles ISBN : 2-212-09172-9 2000 9 Analyse C est au travers des activités d analyse et de conception qui peuvent être menées séparément ou

Plus en détail

Eclipse Process Framework et Telelogic Harmony/ITSW

Eclipse Process Framework et Telelogic Harmony/ITSW Eclipse Process Framework et Telelogic Harmony/ITSW Boris Baldassari 1 Résumé Une introduction à Eclipse Process Framework (EPF) et au processus OpenUP, et comment tirer profit de ces initiatives dans

Plus en détail

Master MIDO 2ème année. Spécification et Conception en UML Maude Manouvrier

Master MIDO 2ème année. Spécification et Conception en UML Maude Manouvrier Master MIDO 2ème année Spécification et Conception en UML Maude Manouvrier Spécifications initiales Analyse Conception du système Conception des classes Bibliographie Modélisation et conception orientées

Plus en détail

ADELFE : Atelier de développement de logiciels à fonctionnalité émergente

ADELFE : Atelier de développement de logiciels à fonctionnalité émergente ADELFE : Atelier de développement de logiciels à fonctionnalité émergente Gauthier Picard*, Carole Bernon*, Valérie Camps**, Marie- Pierre Gleizes* * Institut de Recherche en Informatique de Toulouse Université

Plus en détail

Thèmes. Modélisation d applications industrielles avec UML. Motivations à l origine d UML. Introduction au formalisme UML.

Thèmes. Modélisation d applications industrielles avec UML. Motivations à l origine d UML. Introduction au formalisme UML. Modélisation d applications industrielles avec UML ACOO Analyse, Conception et développement Orientés Objet de logiciels de commande Thèmes Motivations à l origine d UML. Introduction au formalisme UML.

Plus en détail

Sommaire. Conduite de projet Méthode d analyse et de conception. Processus unifié. Objectifs d un processus de développement

Sommaire. Conduite de projet Méthode d analyse et de conception. Processus unifié. Objectifs d un processus de développement Conduite de projet Méthode d analyse et de conception Processus unifié G. Picard SMA/G2I/ENS Mines Saint-Etienne gauthier.picard@emse.fr Octobre 2009 Sommaire!!Objectifs d un processus d ingénierie logicielle!

Plus en détail

Le Guide Pratique des Processus Métiers

Le Guide Pratique des Processus Métiers Guides Pratiques Objecteering Le Guide Pratique des Processus Métiers Auteur : Version : 1.0 Copyright : Softeam Equipe Conseil Softeam Supervisée par Philippe Desfray Softeam 21 avenue Victor Hugo 75016

Plus en détail

OFFRE DE FORMATION L.M.D.

OFFRE DE FORMATION L.M.D. REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE MINISTERE DE L ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE OFFRE DE FORMATION L.M.D. MASTER PROFESSIONNEL ET ACADEMIQUE Systèmes d Information

Plus en détail

GL - 2 2.1 Le Génie Logiciel

GL - 2 2.1 Le Génie Logiciel GL - 2 2.1 Le Génie Logiciel Lydie du Bousquet Lydie.du-bousquet@imag.fr En collaboration avec J.-M. Favre, I. Parissis, Ph. Lalanda 1 Rappels La production logicielle est une activité complexe de façon

Plus en détail

Nom de l application

Nom de l application Ministère de l Enseignement Supérieur et de la Recherche Scientifique Direction Générale des Etudes Technologiques Institut Supérieur des Etudes Technologiques de Gafsa Département Technologies de l Informatique

Plus en détail

SECTION 5 BANQUE DE PROJETS

SECTION 5 BANQUE DE PROJETS SECTION 5 BANQUE DE PROJETS INF 4018 BANQUE DE PROJETS - 1 - Banque de projets PROJET 2.1 : APPLICATION LOGICIELLE... 3 PROJET 2.2 : SITE WEB SÉMANTIQUE AVEC XML... 5 PROJET 2.3 : E-LEARNING ET FORMATION

Plus en détail

URBANISME DES SYSTÈMES D INFORMATION

URBANISME DES SYSTÈMES D INFORMATION FAYCAL AYECH GL2. INSAT 2010/2011 INTRODUCTION AUX SYSTÈMES D INFORMATIONS URBANISME DES SYSTÈMES D INFORMATION De l Urbanisme à L Urbanisation des SI Urbanisme : Mise en œuvre des politiques urbaines

Plus en détail

Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION

Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION Classe de terminale de la série Sciences et Technologie du Management et de la Gestion Préambule Présentation Les technologies de l information

Plus en détail

Formation : Modélisation avec UML 2.0 et Mise en pratique

Formation : Modélisation avec UML 2.0 et Mise en pratique Formation : Modélisation avec et Mise en pratique Durée : sur 4 Jours soit 28 heures ou sur 5 Jours soit 35 heures Présentation Stage UML (Unified Modeling Language) est la notation standard qui s'est

Plus en détail

Licence en Informatique à Horraire Décalé. Cours Gestion de projet informatique Première partie

Licence en Informatique à Horraire Décalé. Cours Gestion de projet informatique Première partie Licence en Informatique à Horraire Décalé Cours Gestion de projet informatique Première partie 1 PLAN Introduction 1. Les concepts de base en management de projet : 3-33 2 Les processus du management de

Plus en détail

UML (Paquetage) Unified Modeling Language

UML (Paquetage) Unified Modeling Language UML (Paquetage) Unified Modeling Language Sommaire Introduction Objectifs Paquetage Espace de nommage d un paquetage Dépendances entre paquetages 2 Notion introduite véritablement par UML car superficiellement

Plus en détail

PTSI PT ÉTUDE DES SYSTEMES

PTSI PT ÉTUDE DES SYSTEMES PTSI PT ÉTUDE DES SYSTEMES Table des matières 1 - PRESENTATION GENERALE... 1 1.1 - Définition d'un système... 1 1.2 - Exemples... 1 1.3 - Cycle de vie d'un système... 1 1.4 Langage de description SysML...

Plus en détail

Analyse et modélisation de tâches

Analyse et modélisation de tâches Analyse et modélisation de tâches 1. Introduction La conception de logiciel interactif (ou conception d'interface homme-machine [IHM], ou conception d'interface) est l'activité qui vise à définir le fonctionnement

Plus en détail

MÉTHODOLOGIES DE CONCEPTION ET NOTATION GRAPHIQUE

MÉTHODOLOGIES DE CONCEPTION ET NOTATION GRAPHIQUE MÉTHODOLOGIES DE CONCEPTION ET NOTATION GRAPHIQUE m Notations : diagrammes m Diagrammes de transition d'états m Méthodes d'analyse de flot de m Conventions pour diagrammes données objet m Diagrammes de

Plus en détail

Génie logiciel pour le commerce électronique Hiver 2003 Prof.: Julie Vachon

Génie logiciel pour le commerce électronique Hiver 2003 Prof.: Julie Vachon Génie logiciel pour le commerce électronique Hiver 2003 Prof.: Julie Vachon Travail pratique #1 «Réalisation d'une plateforme de vente aux enchères électronique» À réaliser individuellement ou en équipe

Plus en détail

Le Processus Unifié. Une Démarche Orientée Modèle. IUP NTIE - Master 1 - Jérémie Guiochet - 4/11/09

Le Processus Unifié. Une Démarche Orientée Modèle. IUP NTIE - Master 1 - Jérémie Guiochet - 4/11/09 Le Processus Unifié Une Démarche Orientée Modèle IUP NTIE - Master 1 - Jérémie Guiochet - 4/11/09 1 Sommaire Partie 1 : UML et processus unifié Partie 2 : Artefacts Partie 3 : Enchaînement d itérations

Plus en détail

Brique BDL Gestion de Projet Logiciel

Brique BDL Gestion de Projet Logiciel Brique BDL Gestion de Projet Logiciel Processus de développement pratiqué à l'enst Sylvie.Vignes@enst.fr url:http://www.infres.enst.fr/~vignes/bdl Poly: Computer elective project F.Gasperoni Brique BDL

Plus en détail

Plateforme STAR CLM. Gestion intégrée des réseaux multilingues d entreprise

Plateforme STAR CLM. Gestion intégrée des réseaux multilingues d entreprise Plateforme STAR CLM Gestion intégrée des réseaux multilingues d entreprise Groupe STAR Your single-source partner for corporate product communication Chaque plan de vol est unique... Chaque vol est un

Plus en détail

Université du Québec à Montréal CALCUL AVEC ISO 19761 DE LA TAILLE DE LOGICIELS DEVELOPPES SELON RATIONAL UNIFIED PROCESS

Université du Québec à Montréal CALCUL AVEC ISO 19761 DE LA TAILLE DE LOGICIELS DEVELOPPES SELON RATIONAL UNIFIED PROCESS Université du Québec à Montréal Sujet CALCUL AVEC ISO 19761 DE LA TAILLE DE LOGICIELS DEVELOPPES SELON RATIONAL UNIFIED PROCESS PAR SAADI AZZOUZ JUILLET 2003 2 Remerciements Je tiens à remercier le Dr

Plus en détail

Optimiser vos méthodes d organisation (ITIL, COBIT, PRINCE2, ) par la mise en place d un processus de Gestion & Publication des connaissances adapté

Optimiser vos méthodes d organisation (ITIL, COBIT, PRINCE2, ) par la mise en place d un processus de Gestion & Publication des connaissances adapté Optimiser vos méthodes d organisation (ITIL, COBIT, PRINCE2, ) par la mise en place d un processus de Gestion & Publication des connaissances adapté 25/07/06 JJ Mois Année Présentation générale & Présentation

Plus en détail

LANGAGUE JAVA. Public Développeurs souhaitant étendre leur panel de langages de programmation

LANGAGUE JAVA. Public Développeurs souhaitant étendre leur panel de langages de programmation ING 01 LANGAGUE JAVA Durée : 21 heures 1090 HT / jour Dates : à définir en 2012 Concevoir et développer des programmes en langage Java Comprendre le fonctionnement de la machine virtuelle S approprier

Plus en détail

Projet Informatique. Philippe Collet. Licence 3 Informatique S5 2014-2015. http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415

Projet Informatique. Philippe Collet. Licence 3 Informatique S5 2014-2015. http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415 Projet Informatique Philippe Collet Licence 3 Informatique S5 2014-2015 http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415 Réalisation d'un développement de taille conséquente? r Firefox? Ph.

Plus en détail

Techniques de Développement

Techniques de Développement Techniques de Développement Quelques définitions relatives au développement de logiciel Sébastien Faucou Université de Nantes (IUT de Nantes, département Informatique) Licence Professionnelle Systèmes

Plus en détail

Besoins utilisateurs. Quelle démarche pour passer des besoins au code? Code. chapitre1 UNIFIED MODELING LANGUAGE. package LogiqueMetier.

Besoins utilisateurs. Quelle démarche pour passer des besoins au code? Code. chapitre1 UNIFIED MODELING LANGUAGE. package LogiqueMetier. chapitre1 Besoins utilisateurs Quelle démarche pour passer des besoins au code?? UNIFIED MODELING LANGUAGE package LogiqueMetier.Gestion; import LogiqueMetier.Catalogue.Livre; import java.util.*;public

Plus en détail

Introduction au génie logiciel

Introduction au génie logiciel Introduction au génie logiciel Guillaume Laurent ENSMM 2007 G. Laurent (ENSMM) Introduction au génie logiciel 2007 1 / 36 Plan du cours 1 Problématique du génie logiciel 2 Méthodes de développement logiciel

Plus en détail

IBM Cognos TM1. Fiche Produit. Aperçu

IBM Cognos TM1. Fiche Produit. Aperçu Fiche Produit IBM Cognos TM1 Aperçu Cycles de planification raccourcis de 75 % et reporting ramené à quelques minutes au lieu de plusieurs jours Solution entièrement prise en charge et gérée par le département

Plus en détail

IKAN ALM et HP ALM/HP Quality Center Enterprise Pour que les Equipes de Développement, de Test et de Production se rejoignent

IKAN ALM et HP ALM/HP Quality Center Enterprise Pour que les Equipes de Développement, de Test et de Production se rejoignent IKAN ALM et HP ALM/HP Quality Center Enterprise Pour que les Equipes de Développement, de Test et de Production se rejoignent Table of contents Sommaire...3 Définition du problème...4 Solution Description...5

Plus en détail

DOCUMENTATION ASSOCIEE A UN PROJET LOGICIEL

DOCUMENTATION ASSOCIEE A UN PROJET LOGICIEL DOCUMENTATION ASSOCIEE A UN PROJET LOGICIEL 31 août 2004 Plate-Forme Opérationnelle de modélisation INRA ACTA ICTA http://www.modelia.org FICHE DU DOCUMENT 10 mai 04 N.Rousse - : Création : version de

Plus en détail

Business Process Design Max Pauron

Business Process Design Max Pauron Business Process Design Max Pauron 2005 Max Pauron - Reproduction and communication, even partial, are strictly prohibited without written permission. Unauthorized photocopying is a crime. Contexte Les

Plus en détail

Objectif : Passer de l analyse métier et fonctionnelle à la définition des applications qui

Objectif : Passer de l analyse métier et fonctionnelle à la définition des applications qui Formation PARTIE 1 : ARCHITECTURE APPLICATIVE DUREE : 5 h Objectif : Passer de l analyse métier et fonctionnelle à la définition des applications qui automatisent les fonctions Définir une architecture

Plus en détail

INTRODUCTION AUX TECHNOLOGIES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES

INTRODUCTION AUX TECHNOLOGIES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES INTRODUCTION AUX TECHNOLOGIES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES Les contenus de ce document sont la propriété exclusive de la société REVER. Ils ne sont transmis qu à titre d information

Plus en détail

LECTURE CRITIQUE. Accompagner les enseignants et formateurs dans la conception d une formation en ligne

LECTURE CRITIQUE. Accompagner les enseignants et formateurs dans la conception d une formation en ligne LECTURE CRITIQUE Accompagner les enseignants et formateurs dans la conception d une formation en ligne Christian Ernst E-learning. Conception et mise en œuvre d un enseignement en ligne Guide pratique

Plus en détail

BOOK REFERENCES ERGONOMIQUES Gfi Informatique

BOOK REFERENCES ERGONOMIQUES Gfi Informatique 2014 BOOK REFERENCES ERGONOMIQUES Gfi Informatique SECTEUR INDUSTRIE-SERVICE CHORUS 2 : Refonte du référentiel des process Groupe Refondre le réferentiel des process Groupe grâce à la réalisation d un

Plus en détail

Les diagrammes de modélisation

Les diagrammes de modélisation L approche Orientée Objet et UML 1 Plan du cours Introduction au Génie Logiciel L approche Orientée Objet et Notation UML Les diagrammes de modélisation Relations entre les différents diagrammes De l analyse

Plus en détail

IBM Business Process Manager

IBM Business Process Manager IBM Software WebSphere Livre blanc sur le leadership en matière d innovation IBM Business Process Manager Une plateforme de BPM complète, unifiée et facilement adaptable aux projets et aux programmes d

Plus en détail

Projet en entreprise Cadrage du Projet de Fin d Etudes «Un projet informatique.»

Projet en entreprise Cadrage du Projet de Fin d Etudes «Un projet informatique.» Projet en entreprise Cadrage du Projet de Fin d Etudes «Un projet informatique.» Projet de fin d études 2 Sommaire OBJET DU DOCUMENT... 3 LES ETAPES DU PROJET... 4 ETUDE PREALABLE...5 1 L étude d opportunité...

Plus en détail

Analyse et Conception objet du logiciel Analyse et conception objet du logiciel : Méthode de conception objet et notation UML.

Analyse et Conception objet du logiciel Analyse et conception objet du logiciel : Méthode de conception objet et notation UML. Analyse et conception objet du logiciel : Méthode de conception objet et notation UML Rémy Courdier Email : Remy.Courdier@univ-reunion.fr Rémy Courdier V2.1 1 Plan du cours Introduction au Génie Logiciel

Plus en détail

ANALYSE D UN SYSTEME D INFORMATION ET EXTENSION DE

ANALYSE D UN SYSTEME D INFORMATION ET EXTENSION DE Université de Fribourg, Suisse Département d'informatique Bachelor en informatique de gestion ANALYSE D UN SYSTEME D INFORMATION ET EXTENSION DE CELUI-CI PAR DE NOUVELLES FONCTIONNALITES Travail de séminaire

Plus en détail

Concevoir et déployer un data warehouse

Concevoir et déployer un data warehouse Concevoir et déployer un data warehouse Ralph Kimball Éditions Eyrolles ISBN : 2-212-09165-6 2000 2 Le cycle de vie dimensionnel Avant d étudier de plus près les spécificités de la conception, du développement

Plus en détail

Impartition réussie du soutien d entrepôts de données

Impartition réussie du soutien d entrepôts de données La force de l engagement MD POINT DE VUE Impartition réussie du soutien d entrepôts de données Adopter une approche globale pour la gestion des TI, accroître la valeur commerciale et réduire le coût des

Plus en détail

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

Modélisation et réalisation d un processus d ingénierie du logiciel 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 2001 www.aubryconseil.com Etudiant : Olivier

Plus en détail

Méthodes de développement. Analyse des exigences (spécification)

Méthodes de développement. Analyse des exigences (spécification) 1 / 16 Méthodes de développement Analyse des exigences (spécification) 1 -Objectifs de l'analyse des exigences... 2 2 - Approfondissement et formalisation du besoin... 2 2.1 Séparation des besoins, contraintes

Plus en détail

Business Process Modeling (BPM)

Business Process Modeling (BPM) Business Process Modeling (BPM) Mineure SOA Cécile Hardebolle cecile.hardebolle@supelec.fr Programme 8 nov. 15 nov. Introduction. Enjeux, rôle de l'architecte SI Partie n 1 du cas d'étude Architecture

Plus en détail

EXERCICES UML. Modéliser cette situation par un diagramme de cas d utilisation. Consulter planning

EXERCICES UML. Modéliser cette situation par un diagramme de cas d utilisation. Consulter planning EXERCICES UML 1 ) Dans un établissement scolaire, on désire gérer la réservation des salles de cours ainsi que du matériel pédagogique (ordinateur portable ou/et Vidéo projecteur). Seuls les enseignants

Plus en détail

Brevet de technicien supérieur Conception et Réalisation en Chaudronnerie Industrielle

Brevet de technicien supérieur Conception et Réalisation en Chaudronnerie Industrielle Brevet de technicien supérieur Conception et Réalisation en Chaudronnerie Industrielle ACTIVITÉS ET TÂCHES PROFESSIONNELLES Les activités professionnelles décrites ci-après, déclinées à partir des fonctions

Plus en détail

Cisco Unified Computing Migration and Transition Service (Migration et transition)

Cisco Unified Computing Migration and Transition Service (Migration et transition) Cisco Unified Computing Migration and Transition Service (Migration et transition) Le service Cisco Unified Computing Migration and Transition Service (Migration et transition) vous aide à migrer vos applications

Plus en détail

Systèmes et réseaux d information et de communication

Systèmes et réseaux d information et de communication 233 DIRECTEUR DES SYSTÈMES ET RÉSEAUX D INFORMATION ET DE COMMUNICATION Code : SIC01A Responsable des systèmes et réseaux d information FPESIC01 Il conduit la mise en œuvre des orientations stratégiques

Plus en détail

Programme «Analyste Programmeur» Diplôme d état : «Développeur Informatique» Homologué au niveau III (Bac+2) (JO N 176 du 1 août 2003) (34 semaines)

Programme «Analyste Programmeur» Diplôme d état : «Développeur Informatique» Homologué au niveau III (Bac+2) (JO N 176 du 1 août 2003) (34 semaines) Programme «Analyste Programmeur» Diplôme d état : «Développeur Informatique» Homologué au niveau III (Bac+2) (JO N 176 du 1 août 2003) (34 semaines) Module 1 : Programmer une application informatique Durée

Plus en détail

COMMENT DÉFINIR L ORIENTÉ OBJET

COMMENT DÉFINIR L ORIENTÉ OBJET COMMENT DÉFINIR L ORIENTÉ OBJET De manière superficielle, le terme «orienté objet», signifie que l on organise le logiciel comme une collection d objets dissociés comprenant à la fois une structure de

Plus en détail