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

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

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

Transcription

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Rational Unified Process

Rational Unified Process Rational Unified Process For Christiane DAVOINE-GUHUR Société GICAB - Vannes Christiane.Davoine@CA-GICAB.fr Table des Matières 1 INTRODUCTION... 1 2 LES COMPOSANTS ET LES GRANDS PRINCIPES DU PROCESSUS...

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

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

touscours.net Rapport de Synthèse Cycle en V, UP et SCRUM

touscours.net Rapport de Synthèse Cycle en V, UP et SCRUM Rapport de Synthèse Cycle en V, UP et SCRUM Réalisé par : BELLINI Quentin GNANAKULENTHIRAN Anitha GOVINDEN Johana MEZINE Ahcene TIMZOUERT Chabane 19/10/2011 www.sup-galilee.univ-paris13.fr Table des matières

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

É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

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

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

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

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

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

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

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

2009 IBM Corporation. Des besoins métiers aux spécifications logicielles avec Rational Partie 2

2009 IBM Corporation. Des besoins métiers aux spécifications logicielles avec Rational Partie 2 Des besoins métiers aux spécifications logicielles avec Rational Partie 2 Objet de la session Processus Agile de Recueil des Besoins et Gestion des Exigences. Cette démonstration de RRC présente un exemple

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

Cours de Génie Logiciel

Cours de Génie Logiciel Cours de Génie Logiciel Sciences-U Lyon Gestion de Projet Informatique http://www.rzo.free.fr Pierre PARREND 1 Mars 2005 Sommaire Gestion de projet informatique Cycle de vie du logiciel Modèles de Méthodes

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

5.1.1 La procédure pour la description d'une situation-problème

5.1.1 La procédure pour la description d'une situation-problème 5 LE CHOIX DES PARTIES DE COURS : UNE PROGRESSION DES APPRENTISSAGES Éléments du cinquième chapitre 5.1 La description de la situation-problème finale 5.1.1 La procédure pour la description d'une situation-problème

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

1 / 9. Méthodes de développement. Introduction

1 / 9. Méthodes de développement. Introduction 1 / 9 Méthodes de développement Introduction 1 - Objectifs... 2 2 - Risques d'un projet logiciel... 2 3 - Préparation et conduite de projet... 3 4 - Caractères particuliers du logiciel et conséquences...

Plus en détail

Les évolutions des méthodes de développement de logiciels. Depuis Merise de l'eau est passée sous les ponts

Les évolutions des méthodes de développement de logiciels. Depuis Merise de l'eau est passée sous les ponts Les évolutions des méthodes de développement de logiciels Depuis Merise de l'eau est passée sous les ponts Programmation Orientée Objets Encapsulation des données et des traitements Polymorphisme Modularité

Plus en détail

GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET

GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET 1 Tianxiao LIU Licence Professionnelle Réseaux & Sécurité Université de Cergy-Pontoise http://depinfo.u-cergy.fr/~tliu/lpg.php PLAN Objectif et

Plus en détail

Modélisation Orientée Objet / UML

Modélisation Orientée Objet / UML Modélisation Orientée Objet / UML Laurent Henocque http://laurent.henocque.free.fr/ Enseignant Chercheur ESIL/INFO France http://laurent.henocque.perso.esil.univmed.fr/ mis à jour en Octobre 2006 Licence

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

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

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

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

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

Examen final LOG3000 Hiver 2014

Examen final LOG3000 Hiver 2014 Examen final LOG3000 Hiver 2014 Lundi le 28 avril 2014. Durée : 13h30 à 16h00 (total 2h30). Local : A-532. Total des points : 20. Pondération de l'examen dans la note finale : 40%. Sans documentation.

Plus en détail

Méthodes de développement

Méthodes de développement 1 / 9 Méthodes de développement Méthodes agiles 1 - Introduction... 2 2 -Le manifeste agile et les méthodes agiles... 2 2.1 Le manifeste agile... 2 2.2 Les méthodes agiles... 3 3 - Caractéristiques communes

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

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

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

Plan de Validation du Logiciel. Version 3.0

Plan de Validation du Logiciel. Version 3.0 Date : 24/01/2004 Groupe : Is3be2 Isi Engineering Process Publisher Plan de Validation du Logiciel Version 3.0 Superviseurs de projet : Claude Aubry Nombre de pages : 19 Bernard Cherbonneau Responsable

Plus en détail

Formation Conception orientée objet

Formation Conception orientée objet Objectif La programmation orientée objet (POO) est un paradigme de programmation informatique qui consiste en la définition et l'interaction de briques logicielles appelées objets. Un objet représente

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

Introduction à l'analyse et à la modélisation des processus. Eric Papet Co-fondateur SSII DEV1.0 Architecte Logiciel & Sécurité Lead Auditor 27001

Introduction à l'analyse et à la modélisation des processus. Eric Papet Co-fondateur SSII DEV1.0 Architecte Logiciel & Sécurité Lead Auditor 27001 Introduction à l'analyse et à la modélisation des processus Eric Papet Co-fondateur SSII DEV1.0 Architecte Logiciel & Sécurité Lead Auditor 27001 Les composants d'une méthode d'analyse La conception d'un

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

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

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

INTRODUCTION GENERALE

INTRODUCTION GENERALE INTRODUCTION GENERALE Chaque année, les entreprises ont de nombreux challenges à relever; adaptation à des contraintes légales nationales, européennes ou internationales, lancement de nouveaux services

Plus en détail

UML est-il soluble dans les méthodes agiles?

UML est-il soluble dans les méthodes agiles? Pascal ROQUES Valtech Training UML est-il soluble dans les méthodes agiles? octobre 07 Résumé On entend beaucoup parler actuellement de deux approches ayant l'air fondamentalement opposées : l'approche

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

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

SOMMAIRE. I. Introduction 02. II. Glossaire 03 a. Glossaire technique 03 b. Glossaire fonctionnel 04

SOMMAIRE. I. Introduction 02. II. Glossaire 03 a. Glossaire technique 03 b. Glossaire fonctionnel 04 SOMMAIRE I. Introduction 02 II. Glossaire 03 a. Glossaire technique 03 b. Glossaire fonctionnel 04 III. Présentation de l'association 05 a. Présentation juridique et géographique 05 b. Présentation de

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

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

É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

Cisco Data Center Facilities Planning and Design Service (Service de conception et de planification des installations de centre de données Cisco)

Cisco Data Center Facilities Planning and Design Service (Service de conception et de planification des installations de centre de données Cisco) Cisco Data Center Facilities Planning and Design Service (Service de conception et de planification des installations de centre de données Cisco) Concevez un centre de données flexible à même de répondre

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

Annexe : La Programmation Informatique

Annexe : La Programmation Informatique GLOSSAIRE Table des matières La Programmation...2 Les langages de programmation...2 Java...2 La programmation orientée objet...2 Classe et Objet...3 API et Bibliothèque Logicielle...3 Environnement 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

[ 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

Qu est-ce qu une milestone (jalon)? Tâche de durée nulle, sans ressource. Elle est destinée à marquer des moments clés dans un projet.

Qu est-ce qu une milestone (jalon)? Tâche de durée nulle, sans ressource. Elle est destinée à marquer des moments clés dans un projet. Cours Ephec Niv. 2 : Technique et gestion de projet Par Monsieur Bertieaux Année Académique 2014-2015 Réponse aux questions du cours, slide Cours 2_1_Planification Vous avez un projet classique qui se

Plus en détail

PLANIFICATION ET SUIVI D'UN PROJET

PLANIFICATION ET SUIVI D'UN PROJET Centre national de la recherche scientifique Direction des systèmes d'information REFERENTIEL QUALITE Guide méthodologique PLANIFICATION ET SUIVI D'UN PROJET Référence : CNRS/DSI/conduite-projet/developpement/gestion-projet/guide-planfi-suivi-projet

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

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

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

Conventions communes aux profils UML

Conventions communes aux profils UML Conventions communes aux profils UML Auteur : Projet ACCORD (Assemblage de composants par contrats en environnement ouvert et réparti)* Référence : Livrable 2.1 Date : Juin 2002 * : Les partenaires du

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

MASTER 2 PROFESSIONNEL INTERACTION HOMME MACHINE (IHM) Etablissements co-habilités : l'université Toulouse I, l'enac, et l'université Toulouse III

MASTER 2 PROFESSIONNEL INTERACTION HOMME MACHINE (IHM) Etablissements co-habilités : l'université Toulouse I, l'enac, et l'université Toulouse III MASTER 2 PROFESSIONNEL INTERACTION HOMME MACHINE (IHM) MENTION INFORMATIQUE Etablissements co-habilités : l'université Toulouse I, l'enac, et l'université Toulouse III «SYLLABUS» Année 2005 2006 OBJECTIFS

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

Elaboration d un cahier des charges Ch. 6

Elaboration d un cahier des charges Ch. 6 Elaboration d un cahier des charges Ch. 6 «Le cahier des charges opérationnel est un document qui permet de dégager les orientations structurantes et de fixer le cadre des travaux à venir d un projet.

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

Plan d'assurance et contrôle qualité

Plan d'assurance et contrôle qualité IUP MIAGE Master 1 année 2008-2009 IPROmaix Plan d'assurance et contrôle qualité Référence : IPROmaix/documentOfficiel/PACQ Date de dernière mise àjour : 29/04/2009 Indice de révision du document : 00

Plus en détail

RAPPORT DE STAGE D ETE

RAPPORT DE STAGE D ETE UNIVERSITE DE SOUSSE INSTITUT SUPERIEUR DES SCIENCES APPLIQUEES ET DE TECHNOLOGIE DE SOUSSE ALFA COMPUTERS & CONSULTING RAPPORT DE STAGE D ETE Développement d une application de gestion de trésorerie d'entreprise

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

Livret Mind Mapping pour le Pilotage & la Gestion Projet avec MindManager - Mindjet

Livret Mind Mapping pour le Pilotage & la Gestion Projet avec MindManager - Mindjet Livret Mind Mapping pour le Pilotage & la Gestion Projet avec MindManager - Mindjet MIND MAPPING : LE COMPAGNON DE VOTRE PILOTAGE PROJET Les apports du Mind Mapping pour les projets sont vus ici sous 2

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

Introduction MOSS 2007

Introduction MOSS 2007 Introduction MOSS 2007 Z 2 Chapitre 01 Introduction à MOSS 2007 v. 1.0 Sommaire 1 SharePoint : Découverte... 3 1.1 Introduction... 3 1.2 Ce que vous gagnez à utiliser SharePoint... 3 1.3 Dans quel cas

Plus en détail

CONSIGNES POUR LA REDACTION DU RAPPORT DE STAGE DU MASTER 2 SOLUTIONS INFORMATIQUES LIBRES

CONSIGNES POUR LA REDACTION DU RAPPORT DE STAGE DU MASTER 2 SOLUTIONS INFORMATIQUES LIBRES CONSIGNES POUR LA REDACTION DU RAPPORT DE STAGE DU MASTER 2 SOLUTIONS INFORMATIQUES LIBRES Département Informatique UFR Sciences 2 Boulevard Lavoisier 49045 Angers Cedex 01 Auteur : Jean-Michel RICHER

Plus en détail

1. INFORMATIQUE DANS LES DISCIPLINES, INFORMATIQUE DISCIPLINE

1. INFORMATIQUE DANS LES DISCIPLINES, INFORMATIQUE DISCIPLINE 29 UN PLAN DE FORMATION À L'INFORMATIQUE DE TOUS LES ÉLÈVES, DE L'ÉCOLE PRIMAIRE AU LYCÉE Note n 8 du groupe technique disciplinaire informatique - décembre 1991 - (principaux extraits) 1. INFORMATIQUE

Plus en détail

Gestion de Projet Informatique

Gestion de Projet Informatique Gestion de Projet Informatique Partie 3 : Cycles de vie de projet Licence d'informatique 3 ième Année Tianxiao Liu Université de Cergy-Pontoise 1 GPI T. LIU The earliest moment is when you think it is

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

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

IFT6803: Génie logiciel du commerce électronique. Chapitre 1: Introduction Section 3: Processus de développement

IFT6803: Génie logiciel du commerce électronique. Chapitre 1: Introduction Section 3: Processus de développement IFT6803: Génie logiciel du commerce électronique Chapitre 1: Introduction Section 3: Processus de développement Julie Vachon, Hiver 2003 Sommaire Chapitre 1, Section 3 «Processus de développement» 1.3.1

Plus en détail

MEGA Process. Guide d utilisation

MEGA Process. Guide d utilisation MEGA Process Guide d utilisation MEGA 2009 SP4 1ère édition (juin 2010) Les informations contenues dans ce document pourront faire l objet de modifications sans préavis et ne sauraient en aucune manière

Plus en détail

FICHE JANVIER 2009 THÉMATIQUE. Direction de projets et programmes

FICHE JANVIER 2009 THÉMATIQUE. Direction de projets et programmes FICHE JANVIER 2009 THÉMATIQUE Direction de projets et programmes La représentation par les processus pour les projets Système d Information (SI) La modélisation de l'entreprise par les processus devient

Plus en détail

MEGA ITSM Accelerator. Guide de Démarrage

MEGA ITSM Accelerator. Guide de Démarrage MEGA ITSM Accelerator Guide de Démarrage MEGA 2009 SP4 1ère édition (juin 2010) Les informations contenues dans ce document pourront faire l objet de modifications sans préavis et ne sauraient en aucune

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 de Diplôme Bachelor (PDB) HEIG-VD

Projets de Diplôme Bachelor (PDB) HEIG-VD Projets de Diplôme Bachelor (PDB) HEIG-VD Kick-off Février 2011, v 1.6 christian.buchs@heig-vd.ch 1 Contenu 1. Gestion de projet 2. Bilans hebdomadaires 3. Le rapport 4. Activités de test 5. Évaluation

Plus en détail

Sage CRM. 7.2 Guide de Portail Client

Sage CRM. 7.2 Guide de Portail Client Sage CRM 7.2 Guide de Portail Client Copyright 2013 Sage Technologies Limited, éditeur de ce produit. Tous droits réservés. Il est interdit de copier, photocopier, reproduire, traduire, copier sur microfilm,

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

Les méthodes de conduite de projets

Les méthodes de conduite de projets M1 Miage & Informatique - Conduite de projets - D. Leclet Page 1 Les méthodes de conduite de projets I - Introduction Les seules véritables causes d échec d un projet, résident dans l incapacité à communiquer

Plus en détail

Introduction à la conduite de projet "systèmes d'information"

Introduction à la conduite de projet systèmes d'information Centre national de la recherche scientifique Direction des systèmes d'information REFERENTIEL QUALITE Guide méthodologique Introduction à la conduite de projet "systèmes d'information" Référence : CNRS/DSI/conduite-projet/principes/guide-introduction

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

Une solution PLM efficace pour les entreprises de taille moyenne : Personnalisée, agile et souple

Une solution PLM efficace pour les entreprises de taille moyenne : Personnalisée, agile et souple cenitspin Une solution PLM efficace pour les entreprises de taille moyenne : Personnalisée, agile et souple CONFIGURE YOUR PLM STANDARD www.cenit.com/fr/cenitspin Tout à portée de main grâce au PLM Desktop.

Plus en détail

INDUSTRIALISATION ET RATIONALISATION

INDUSTRIALISATION ET RATIONALISATION INDUSTRIALISATION ET RATIONALISATION A. LA PROBLEMATIQUE La mission de toute production informatique est de délivrer le service attendu par les utilisateurs. Ce service se compose de résultats de traitements

Plus en détail

Améliorer votre approche processus

Améliorer votre approche processus Améliorer votre approche processus Décrire de manière complète les processus, Mettre en place des tableaux de bord de manière à en surveiller le fonctionnement et à en déterminer l efficacité, Réaliser

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 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