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

Positionnement de UP

Positionnement de UP UNIFIED PROCESS Positionnement de UP Unified Process Langage Méthode Outil logiciel UML UP RUP 6 BONNES PRATIQUES développement itératif gestion des exigences architecture basée sur des composants modélisation

Plus en détail

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

Modélisation objet Le langage UML

Modélisation objet Le langage UML Modélisation objet Le langage UML Brahim HAMID La base de contrôle Robot Zone à explorer brahim.hamid@irit.fr brahim.hamid@univ-tlse2.fr http://mass-cara.univ-tlse2.fr/~brahimou/ens/uml 1 Les méthodes

Plus en détail

Modèle d implémentation

Modèle d implémentation Modèle d implémentation Les packages UML: Unified modeling Language Leçon 5/6-9-16/10/2008 Les packages - Modèle d implémentation - Méthodologie (RUP) Un package ou sous-système est un regroupement logique

Plus en détail

Description et illustration du processus unifié

Description et illustration du processus unifié USDP Description et illustration du processus unifié Définit un enchaînement d activités Est réalisé par un ensemble de travailleurs Avec des rôles, des métiers Avec pour objectifs de passer des besoins

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

Processus de développement UP

Processus de développement UP Chapitre 1 Processus de développement UP I. Pourquoi UP? II. Définition III. Activités et phases IV. Modèles mis en place 1. Pourquoi UP? Les notions de base acquises dans le module ACOO1, notamment la

Plus en détail

Processus Unifié de développement de logiciel

Processus Unifié de développement de logiciel Processus Unifié de développement de logiciel Plan 1. SUP : une simplification de RUP 2. Les éléments de modélisation de SUP 3. Description de la dynamique de SUP 4. SUP sur une étude de cas 2 SUP : une

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

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

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 6 Le Processus unifié de développement logiciel Partie I Les concepts Présentation réalisée par P.-A. Sunier Professeur à la HE-Arc de Neuchâtel

Plus en détail

Environnements de Développement

Environnements de Développement Institut Supérieur des Etudes Technologiques de Mahdia Unité d Enseignement: Environnements de Développement Mme BEN ABDELJELIL HASSINE Mouna m.bnaj@yahoo.fr Développement des systèmes d Information Syllabus

Plus en détail

Rational Unified Process

Rational Unified Process Rational Unified Process Hafedh Mili Rational Unified Process 1. Principes de base 2. Les phases 3. Les activités (workflows) Copyright Hafedh Mili 2005 2 1 Rational Unified Process Processus de développement

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

Le génie Logiciel (suite)

Le génie Logiciel (suite) Le génie Logiciel (suite) Lors du cours précédent, on a étudié différents cycles de vie, dont la cascade, ou la spirale. Analyse des besoins L analyse des besoins est une étape menant à l élaboration de

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

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

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

Modélisation des Systèmes d Information Jean-Yves Antoine

Modélisation des Systèmes d Information Jean-Yves Antoine Modélisation des Systèmes d Information Jean-Yves Antoine http://www.info.univ-tours.fr/~antoine Processus de développement logiciel Jean-Yves Antoine U. Bretagne Sud - UFR SSI - IUP Vannes année 2001-2002

Plus en détail

Étude de cas. UML n est pas une méthode

Étude de cas. UML n est pas une méthode Étude de cas UML n est pas une méthode UML n est pas une méthode, mais un simple langage ; l OMG ne préconise pas de processus ; il n existe pas une démarche unique qui fixe l ordre dans lequel les modèles

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

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

TP-1 : Diagramme de Cas d utilisation Diagrammes d interaction

TP-1 : Diagramme de Cas d utilisation Diagrammes d interaction EFREI - L2 Année : 2013/2014 A. Lahlou TP-1 UML TP-1 : Diagramme de Cas d utilisation Diagrammes d interaction I Introduction Durant la première séance de TP, vous partez à la découverte de l AGL (Atelier

Plus en détail

GÉNIE LOGICIEL (SOFTWARE ENGINEERING)

GÉNIE LOGICIEL (SOFTWARE ENGINEERING) GÉNIE LOGICIEL (SOFTWARE ENGINEERING) 5ÈME PARTIE UML (UNIFIED MODELING LANGUAGE) Faculté des Sciences et Techniques http://labh-curien.univ-st-etienne.fr/~fj/gl Francois.Jacquenet@univ-st-etienne.fr Plan

Plus en détail

Projets Logiciels: Processus de développement pratiqué à TELECOM ParisTech

Projets Logiciels: Processus de développement pratiqué à TELECOM ParisTech Projets Logiciels: Processus de développement pratiqué à TELECOM ParisTech INF380-2013! Sylvie.Vignes@telecomParistech.fr Département INFRES, groupe S3 Cadre du processus 2! q Basé sur un processus incrémental:

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

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

Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005

Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005 MDA : Un Tutoriel Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005 1 Sommaire Table des matières 1 Sommaire 1 2 Introduction 2 2.1 A qui s adresse ce tutoriel......................

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

1. Introduction. 2. Diagramme des exigences

1. Introduction. 2. Diagramme des exigences 1. Introduction La complexité des systèmes techniques est telle que, sans outils de représentations abstraites et progressivement enrichies, les intervenants d un projet auraient de nombreuses difficultés

Plus en détail

Éléments d UML pour le projet (Unified Modeling Language)

Éléments d UML pour le projet (Unified Modeling Language) Éléments d UML pour le projet (Unified Modeling Language) C Crochepeyre UML 1 PLAN 1. Introduction 2. Préliminaires 3. Les règles UML 4. Les diagrammes UML 5. Outils de modélisation UML 6. L étude préalable

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

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

Yannick Prié UFR Informatique Université Claude Bernard Lyon 1 M1 MIAGE SIMA / M1 Informatique MIF17 2008 2009

Yannick Prié UFR Informatique Université Claude Bernard Lyon 1 M1 MIAGE SIMA / M1 Informatique MIF17 2008 2009 Yannick Prié UFR Informatique Université Claude Bernard Lyon 1 M1 MIAGE SIMA / M1 Informatique MIF17 2008 2009 Notion de méthode de conception de SI Méthodes OO de conception Généralités sur les méthodes

Plus en détail

IFT2251 : Génie logiciel

IFT2251 : Génie logiciel 4.1. Introduction à UML IFT2251 : Génie logiciel 1. Approches de développement 2. Introduction à UML (une méthodologie basée sur l approche orientée aspect) 3. Rappel de quelques concepts objets Chapitre

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

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

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

Méthodes de conception pour les Systèmes d Information (UP)

Méthodes de conception pour les Systèmes d Information (UP) www.lisyc.univ-brest.fr/pages_perso/babau/ Méthodes de conception pour les Systèmes d Information (UP) Jean-Philippe Babau Département Informatique, UFR Sciences, Laboratoire LISyC 2 1 Modèles et méta-modèles

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

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

[ Hornet ] Charte de méthodologie

[ Hornet ] Charte de méthodologie [ Hornet ] Hornet Cette création est mise à disposition selon le Contrat Paternité - Pas d'utilisation Commerciale - Partage des Conditions Initiales à l'identique disponible en ligne http://creativecommons.org/licenses/by-nc-sa/2.0/fr/

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

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

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

ACube. Charte méthodologique. Version 1.2 du 22/02/2010. Etat : Validé

ACube. Charte méthodologique. Version 1.2 du 22/02/2010. Etat : Validé Charte méthodologique Version 1.2 du 22/02/2010 Etat : Validé Communauté Adullact Projet SUIVI DES MODIFICATIONS Version Rédaction Description Vérification Date 1.0 S. Péguet Initialisation 20/03/07 1.1

Plus en détail

UML. en action. De l analyse des besoins à la conception en Java. Pascal ROQUES Franck VALLÉE. Deuxième édition 2003

UML. en action. De l analyse des besoins à la conception en Java. Pascal ROQUES Franck VALLÉE. Deuxième édition 2003 UML en action De l analyse des besoins à la conception en Java Pascal ROQUES Franck VALLÉE Deuxième édition 2003 Groupe Eyrolles, 2003 ISBN : 2-212-11213-0 Chapitre 2 Processus et architecture Une introduction

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

GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009

GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009 GPA 789 : Analyse et Conception Orientées Objet ETS Mickaël Gardoni Bureau A 3588 tel 84 11 Mise en œuvre UML 1/ 25 Introduction Mise en œuvre d UML UML n est pas une méthode 2/ 25 1 UML n est qu un langage

Plus en détail

SYSTEMES D INFORMATION & CONCEPTION de BdD

SYSTEMES D INFORMATION & CONCEPTION de BdD SYSTEMES D INFORMATION & CONCEPTION de BdD PLAN CONCEPT DE SYSTEME D INFORMATION MODELISATION D UN SYSTEME D INFORMATION MODELISATION CONCEPTUELLE : les METHODES METHODE SYSTEMIQUE METHODE OBJET L3 Informatique

Plus en détail

UML : Les cas d utilisation

UML : Les cas d utilisation UML : Les cas d utilisation 2014 tv - v.1.0 Point de vue fonctionnel L expression préliminaire des besoins donne lieu à une modélisation par les cas d utilisation. Le concept de cas d

Plus en détail

Programmation Orientée Objet. Ecrire beaucoup de lignes de code, même très propres, ne suffit pas

Programmation Orientée Objet. Ecrire beaucoup de lignes de code, même très propres, ne suffit pas 2 Modélisation Construire un bon logiciel : Répondre aux objectifs fixés (satisfaire le client) Avoir une base architecturale solide qui permette l évolution Mettre en place un processus de développement

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

PASCAL ROQUES. UML par. la pratique. Groupe Eyrolles, 2001, 2002, 2004, 2005, 2006, 2009. ISBN : 978-2-212-12508-5

PASCAL ROQUES. UML par. la pratique. Groupe Eyrolles, 2001, 2002, 2004, 2005, 2006, 2009. ISBN : 978-2-212-12508-5 est f o E Y R O L L E S PASCAL ROQUES UML par la pratique Groupe Eyrolles, 2001, 2002, 2004, 2005, 2006, 2009. ISBN : 978-2-212-12508-5 Sommaire Introduction 9 Objectifs du livre... 9 Structure de l ouvrage...

Plus en détail

Le Processus Unifié appliqué au projet MOOCS

Le Processus Unifié appliqué au projet MOOCS Le Processus Unifié appliqué au projet MOOCS Violaine Louvet GTN, 7 mai 2003, Orsay Le Processus Unifie applique au projet MOOCS p. 1 L objet Objet = entité regroupant des données (attributs) et des services

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

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

Un peu d'organisation. Conception et Programmation par Objets HLIN406. Sommaire. Pourquoi vous parler de conception par objets? Notion de modélisation

Un peu d'organisation. Conception et Programmation par Objets HLIN406. Sommaire. Pourquoi vous parler de conception par objets? Notion de modélisation Un peu d'organisation Conception et Programmation par Objets HLIN406 Marianne Huchard, Clémentine Nebut LIRMM / Université de Montpellier 2 Premières semaines Contrôle des connaissances Supports 2015 Sommaire

Plus en détail

Méthodes de conception pour les logiciels

Méthodes de conception pour les logiciels labsticc.univ-brest.fr/pages_perso/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

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

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

<< Crédit Club Auto >>

<< Crédit Club Auto >> Abbas Ahmad Année 2010/2011 Matin Bayramov Analyse et Modélisation des Systèmes Informatique (AMSI) Projet de Modélisation UML > Professeur encadrant : M. GUILLAUME PAQUETTE Projet

Plus en détail

Les formations. Développeur Logiciel. ENI Ecole Informatique

Les formations. Développeur Logiciel. ENI Ecole Informatique page 1/8 Titre professionnel : Inscrit au RNCP de Niveau III (Bac + 2) (J.O. du 19/02/13) 24 semaines + 8 semaines de stage (uniquement en formation continue) Développer une application orientée objet

Plus en détail

Module B9-1 : sensibilisation à l UML

Module B9-1 : sensibilisation à l UML Module B9-1 : sensibilisation à l UML Session 5 : Conception et adaptation à l entreprise Olivier Habart : habart.olivier@gmail.com ENSTA B9-1 UML (Olivier Habart) Novembre 14 Diapositive N 1 Session 5

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 et Gestion de Projet

Conduite et Gestion de Projet /43 Conduite et Gestion de Projet Thierry Hamon Bureau H202 - Institut Galilée Tél. : 33 1.49.40.35.53 Bureau 150 LIM&BIO EA 3969 Université Paris 13 - UFR Léonard de Vinci 74, rue Marcel Cachin, F-93017

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

Management des processus opérationnels

Management des processus opérationnels Ecole Nationale Supérieure de Management Master Management des organisations Management des processus opérationnels Dr TOUMI Djamila Cours n 4: l approche processus et le management du système d informations

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

Quelques transparents de cours sur la méthode SADT (Structured Analysis and design Technics) Université du Havre

Quelques transparents de cours sur la méthode SADT (Structured Analysis and design Technics) Université du Havre Quelques transparents de cours sur la méthode SADT (Structured Analysis and design Technics) 1995 1996 Université du Havre B. Sadeg SADT (Structured Analysis and design Technics) Analyse Structurée et

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

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

Mongi TRIKI Docteur en Informatique Université Paris Dauphine

Mongi TRIKI Docteur en Informatique Université Paris Dauphine Université Méditerranéenne Libre de Tunis Faculté Méditerranéenne Privée des Sciences Informatiques, Economiques et de Gestion de Tunis Département d Informatique LICENCE INFORMATIQUE Guide du Stagiaire

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

Les expériences d ERNI dans l univers du management, des processus et des technologies. Experience N 52. Toucher juste. Mars 2012

Les expériences d ERNI dans l univers du management, des processus et des technologies. Experience N 52. Toucher juste. Mars 2012 Les expériences d ERNI dans l univers du management, des processus et des technologies Experience N 52 Mars 2012 RequIREments EngINEERINg Toucher juste TouchER juste L ingénierie des exigences: les bases

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

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

MODÉLISATION DES BESOINS

MODÉLISATION DES BESOINS MODÉLISATION DES BESOINS Diagrammes de cas d utilisation Cas d'utilisation : Use Case (Jacobson) Permettent déxprimer les attentes/besoins des utilisateurs Permettent de définir les limites du système

Plus en détail

Objectifs de ce cours Processus de conception de SI

Objectifs de ce cours Processus de conception de SI Objectifs de ce cours Processus de conception de SI M1 MIAGE - SIMA - 2005-2006 Yannick Prié UFR Informatique - Université Claude Bernard Lyon 1 Notion de méthode de conception de SI Méthodes OO de conception

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

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

VALIDATION DES ACQUIS DE L EXPERIENCE (VAE) Expert en ingénierie du logiciel. 1) Conditions de recevabilité de la demande des candidats

VALIDATION DES ACQUIS DE L EXPERIENCE (VAE) Expert en ingénierie du logiciel. 1) Conditions de recevabilité de la demande des candidats VALIDATION DES ACQUIS DE L EXPERIENCE (VAE) Expert en ingénierie du logiciel 1) Conditions de recevabilité de la demande des candidats Le candidat souhaitant acquérir le titre professionnel d Expert en

Plus en détail

Page 1 2 La présente invention concerne le domaine des architectures informatiques, et en particulier un procédé pour le développement d applications destiné à un fonctionnement en réseau, par exemple

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

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

Introduction aux Composants Logiciels

Introduction aux Composants Logiciels Introduction aux Composants Logiciels Christian Pérez LIP/INRIA Année 2010-11 Plan Introduction aux composants logiciels Pourquoi des composants logiciels Notions de composants logiciels Conclusion Survol

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

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

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

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

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

Rédaction du Document de Spécifications Logiciel

Rédaction du Document de Spécifications Logiciel Rédaction du Document de Spécifications Logiciel Instruction Générale Qualité Version : 1.1 Nombre de pages : 12 Référence : referentiel_qualite/dsl.plan_type.doc UV UMLP Département ASI INSA-ROUEN BP

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

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

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

Gestion projets des Systèmes d informations

Gestion projets des Systèmes d informations Gestion projets des Systèmes d informations Résumé du cours par Ahmet Gyger GESTION PROJETS DES SYSTEMES D INFORMATIONS... 1 Définitions de systèmes d informations...5 Objectif des SI...5 Données versus

Plus en détail

Introduction ( ) Source ( ) Introduction Source

Introduction ( ) Source ( ) Introduction Source Réutilisation, livraison pour la réutilisation, Biens logiciels, Bibliothèque de biens logiciels, Référentiel logiciel Patterns, frameworks, architectures à base de composants Introduction Source La notion

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

Rappels. Génie logiciel. Rappels. Règles métier. RUP, phases milestones, disciplines. Processus itératif & incrémental? Certification, CMM?

Rappels. Génie logiciel. Rappels. Règles métier. RUP, phases milestones, disciplines. Processus itératif & incrémental? Certification, CMM? Rappels Génie logiciel RUP, phases milestones, disciplines Philippe Dugerdil 09.10.2008 Rappels Règles métier Processus itératif & incrémental? Certification, CMM? Modification des specification en cours

Plus en détail

CSC4002 : Introduction à la conception et à la programmation orientées objet illustrées avec UML et JAVA

CSC4002 : Introduction à la conception et à la programmation orientées objet illustrées avec UML et JAVA CSC4002 : Introduction à la conception et à la programmation orientées objet illustrées avec UML et JAVA Denis Conan et Jean-Luc Raffy CSC 4002 Octobre 2015 CSC4002 : Introduction à la conception et à

Plus en détail