Modélisation et réalisation d un processus d ingénierie du logiciel
|
|
- Angèline Boulet
- il y a 8 ans
- Total affichages :
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
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étailRational 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étailCours 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étailMODELISATION 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étailChapitre 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étailbasé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étailIFT2255 : 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étailDé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étailMé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étailGESTION 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étailMé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étail2. 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étailMé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étailAnalyse,, 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étailINF 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étailGé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étailEclipse 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étailUML 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étailSECTION 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étailIntroduction 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étailFormation : 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étailQu'est-ce que le BPM?
Qu'est-ce que le BPM? Le BPM (Business Process Management) n'est pas seulement une technologie mais, dans les grandes lignes, une discipline de gestion d'entreprise qui s'occupe des procédures contribuant
Plus en détailLes diagrammes de modélisation
L approche Orientée Objet et UML 1 Plan du cours Introduction au Génie Logiciel L approche Orientée Objet et Notation UML Les diagrammes de modélisation Relations entre les différents diagrammes De l analyse
Plus en détailScrum Le guide pratique de la méthode agile la plus populaire 3 e édition Claude Aubry 320 pages Dunod, 2013
Scrum Le guide pratique de la méthode agile la plus populaire 3 e édition Claude Aubry 320 pages Dunod, 2013 Illustration de couverture : Clément Pinçon Dunod, Paris, 2014 ISBN 978-2-10-071038-6 Préface
Plus en détailProcessus 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étailUniversité 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étailFeature Team Primer. par Craig Larman et Bas Vodde. Version 1.2
ÉQUIPE FEATURE par Craig Larman et Bas Vodde Version 1.2 Les Équipes Feature 1 et les Domaines Fonctionnels 2 sont des éléments essentiels pour dimensionner le développement en mode agile et lean. Ces
Plus en détailChapitre 1 : Introduction aux bases de données
Chapitre 1 : Introduction aux bases de données Les Bases de Données occupent aujourd'hui une place de plus en plus importante dans les systèmes informatiques. Les Systèmes de Gestion de Bases de Données
Plus en détailMEGA 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étailLe 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étailProjet Active Object
Projet Active Object TAO Livrable de conception et validation Romain GAIDIER Enseignant : M. Noël PLOUZEAU, ISTIC / IRISA Pierre-François LEFRANC Master 2 Informatique parcours MIAGE Méthodes Informatiques
Plus en détailMéthodes agiles. www.businessinteractif.com CONSEIL & DÉVELOPPEMENT DE SOLUTIONS E-BUSINESS. Jean-Louis Bénard jlb@businessinteractif.
Méthodes agiles www.businessinteractif.com Jean-Louis Bénard jlb@businessinteractif.fr CONSEIL & DÉVELOPPEMENT DE SOLUTIONS E-BUSINESS 0 20 mai 2002 Sommaire Méthodes agiles : une réponse à un malaise?
Plus en détailITIL V2. La gestion des mises en production
ITIL V2 La gestion des mises en production Création : novembre 2004 Mise à jour : août 2009 A propos A propos du document Ce document de référence sur le référentiel ITIL a été réalisé en 2004 et la traduction
Plus en détailMEGA Application Portfolio Management. Guide d utilisation
MEGA Application Portfolio Management Guide d utilisation MEGA 2009 SP5 R7 2ème édition (novembre 2012) Les informations contenues dans ce document pourront faire l objet de modifications sans préavis
Plus en détailNom-Projet MODELE PLAN DE MANAGEMENT DE PROJET
Nom-Projet MODELE PLAN DE MANAGEMENT DE PROJET Glossaire La terminologie propre au projet, ainsi que les abréviations et sigles utilisés sont définis dans le Glossaire. Approbation Décision formelle, donnée
Plus en détailLe 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étailGL - 2 2.2 Processus de développement Cycles de vie
GL - 2 2.2 Processus de développement Cycles de vie Lydie du Bousquet Lydie.du-bousquet@imag.fr En collaboration avec J.-M. Favre, Ph. Lalanda, I. Parissis, Y. Ledru 1 Plan Introduction Modèles en cascade
Plus en détailEnquête 2014 de rémunération globale sur les emplois en TIC
Enquête 2014 de rémunération globale sur les emplois en TIC Enquête 2014 de rémunération globale sur les emplois en TIC Les emplois repères de cette enquête sont disponibles selon les trois blocs suivants
Plus en détailORACLE TUNING PACK 11G
ORACLE TUNING PACK 11G PRINCIPALES CARACTÉRISTIQUES : Conseiller d'optimisation SQL (SQL Tuning Advisor) Mode automatique du conseiller d'optimisation SQL Profils SQL Conseiller d'accès SQL (SQL Access
Plus en détailFiche méthodologique Rédiger un cahier des charges
Fiche méthodologique Rédiger un cahier des charges Plan de la fiche : 1 : Présentation de la fiche 2 : Introduction : les grands principes 3 : Contenu, 1 : positionnement et objectifs du projet 4 : Contenu,
Plus en détailAnnexe : 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étailIntroduction au génie logiciel
Introduction au génie logiciel Guillaume Laurent ENSMM 2007 G. Laurent (ENSMM) Introduction au génie logiciel 2007 1 / 36 Plan du cours 1 Problématique du génie logiciel 2 Méthodes de développement logiciel
Plus en détailAnnexe sur la maîtrise de la qualité
Version du 09/07/08 Annexe sur la maîtrise de la qualité La présente annexe précise les modalités d'application, en matière de maîtrise de la qualité, de la circulaire du 7 janvier 2008 fixant les modalités
Plus en détail1. Considérations sur le développement rapide d'application et les méthodes agiles
Chapitre 1 Introduction 1. Considérations sur le développement rapide d'application et les méthodes agiles 1.1 Rappel Longtemps les méthodes en cascade ou en V ont été opposées aux démarches empiriques
Plus en détailArchitecture 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étailMicrosoft Dynamics AX 2012 Une nouvelle génération de système ERP
Microsoft Dynamics AX 2012 Une nouvelle génération de système ERP Microsoft Dynamics AX 2012 n'est pas seulement la dernière version d'un excellent produit. Cette solution représente en fait un véritable
Plus en détailAnalyse et Conception objet du logiciel Analyse et conception objet du logiciel : Méthode de conception objet et notation UML.
Analyse et conception objet du logiciel : Méthode de conception objet et notation UML Rémy Courdier Email : Remy.Courdier@univ-reunion.fr Rémy Courdier V2.1 1 Plan du cours Introduction au Génie Logiciel
Plus en détailSommaire. G. Pujolle, F. Ravat, C. Soulé-Dupuy, G. Zurfluh
NOTATION UML AVEC RATIONAL ROSE G. Pujolle, F. Ravat, C. Soulé-Dupuy, G. Zurfluh Sommaire 1 GÉNÉRALITES...2 1.1 ENVIRONNEMENT LOGICIEL...2 1.2 LES VUES DU LOGICIEL ROSE...3 1.3 ORGANISATION RECOMMANDÉE...3
Plus en détailWhat s New. HOPEX V1 Release 2. MEGA International Avril 2014. V1R2 What's New 1
What s New HOPEX V1 Release 2 MEGA International Avril 2014 V1R2 What's New 1 Sommaire Sommaire Introduction 7 Nouvelles solutions 8 HOPEX Business Architecture 9 1 Introduction 10 1.1 Description générale
Plus en détailMODALITES DE SUIVI DU PROJET ANNUEL DU MASTER 2 SOLUTIONS INFORMATIQUES LIBRES
MODALITES DE SUIVI DU PROJET ANNUEL DU MASTER 2 SOLUTIONS INFORMATIQUES LIBRES Département Informatique UFR Sciences 2 Boulevard Lavoisier 49045 Angers Cedex 01 Auteur : Jean-Michel Richer Email : jean-michel.richer@univ-angers.fr
Plus en détailSage 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étailDA MOTA Anthony - Comparaison de technologies : PhoneGap VS Cordova
DA MOTA Anthony - Comparaison de technologies : PhoneGap VS Cordova I. Introduction Dans une période où la plasticité peut aider à réduire les coûts de développement de projets comme des applications mobile,
Plus en détailChapitre 9 : Informatique décisionnelle
Chapitre 9 : Informatique décisionnelle Sommaire Introduction... 3 Définition... 3 Les domaines d application de l informatique décisionnelle... 4 Architecture d un système décisionnel... 5 L outil Oracle
Plus en détailmodélisation solide et dessin technique
CHAPITRE 1 modélisation solide et dessin technique Les sciences graphiques regroupent un ensemble de techniques graphiques utilisées quotidiennement par les ingénieurs pour exprimer des idées, concevoir
Plus en détailRapport de Stage Christopher Chedeau 2 au 26 Juin 2009
Rapport de Stage Christopher Chedeau 2 au 26 Juin 2009 «Web. De l intégration de pages statiques HTML à un CMS, à la dynamisation d un site grâce au Javascript et l utilisation de nouvelles technologies
Plus en détailNom 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étailSujet de thèse CIFRE RESULIS / LGI2P
Ecole des Mines d Alès Laboratoire de Génie Informatique et d Ingénierie de Production LGI2P Nîmes Sujet de thèse CIFRE RESULIS / LGI2P Titre Domaine De l ingénierie des besoins à l ingénierie des exigences
Plus en détailMéthodes Agiles et gestion de projets
Méthodes Agiles et gestion de projets Eric LELEU Consultant Solutions Collaboratives Contact ericleleu@nordnet.fr Site Personnel http://home.nordnet.fr/~ericleleu Blog http://ericleleu.spaces.live.fr La
Plus en détailA-t-on le temps de faire les choses?
A-t-on le temps de faire les choses? A-t-on le temps de faire les choses? Un parcours de 25 ans dans le domaine des Systèmes d'information de 6 grandes entreprises Consultante depuis 19 ans Mission / contrats
Plus en détailLe 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étailService de réplication des données HP pour la gamme de disques Continuous Access P9000 XP
Service de réplication des données HP pour la gamme de disques Continuous Access P9000 XP Services HP Care Pack Données techniques Le service de réplication des données HP pour Continuous Access offre
Plus en détailBOOK 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étailMEGA ITSM Accelerator. Guide de démarrage
MEGA ITSM Accelerator Guide de démarrage MEGA 2013 1ère édition (janvier 2013) Les informations contenues dans ce document pourront faire l objet de modifications sans préavis et ne sauraient en aucune
Plus en détailC est quoi le SWAT? Les équipes décrites par James Martin s appellent SWAT : Skilled With Advanced Tools.
1- RAD Quelle sont les avantages que apporte la méthode RAD à l entreprise? Une méthode RAD devrait, d après son auteur, apporter trois avantages compétitifs à l entreprise : Une rapidité de développement
Plus en détailGestion de projet Agile. STS IRIS Module 4.2 - «Gérer et organiser un projet informatique»
Gestion de projet Agile Module 4.2 - «Gérer et organiser un projet informatique» Sommaire Introduction Principes et méthodes Agiles Scrum 2 Introduction Gestion de projet : démarche structurante assurant
Plus en détailPrise en main du BusinessObjects XI R2 Service Pack 2/ Productivity Pack
Prise en main du BusinessObjects XI R2 Service Pack 2/ Productivity Pack A propos de ce guide A propos de ce guide Ce guide contient des informations de prise en main du BusinessObjects XI R2 Service Pack
Plus en détailIndustrialiser 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étailProjet 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étailwww.lafamily.ch en 16 différences
Cas d étude no 3 www.lafamily.ch en 16 différences juin 2003 Le mandat réalisé avec QuickSite de transformation du site existant de Lafamily.ch, centre globale d information pour les familles, à été de
Plus en détail2.DIFFERENTS MODELES DE CYCLE DE VIE
2.DIFFERENTS MODELES DE CYCLE DE VIE 2.1. INTRODUCTION... 1 2.1.1 Notion de cycle de vie... 1 2.1.2 Justification du cycle de vie... 1 2.2. LES DIFFERENTES PHASES DU CYCLE DE VIE... 2 2.2.1 Définition
Plus en détailBrique BDL Gestion de Projet Logiciel
Brique BDL Gestion de Projet Logiciel Processus de développement pratiqué à l'enst Sylvie.Vignes@enst.fr url:http://www.infres.enst.fr/~vignes/bdl Poly: Computer elective project F.Gasperoni Brique BDL
Plus en détailERP5. Gestion des Services Techniques des Collectivités Locales
Gestion des Services Techniques des Collectivités Locales Cte 1 2 P 3 s tio T 4 m ilg h trc c n p.o 5 re u fe ro a le tio c M S tw u aa c e O 2 Relation Citoyen Interventions Patrimoine Core Ressources
Plus en détailBusiness Process Modeling (BPM)
Business Process Modeling (BPM) Mineure SOA Cécile Hardebolle cecile.hardebolle@supelec.fr Programme 8 nov. 15 nov. Introduction. Enjeux, rôle de l'architecte SI Partie n 1 du cas d'étude Architecture
Plus en détailProposition de sujet de thèse CIFRE EUROCOPTER / LGI2P
EUROCOPTER SAS Groupe EADS Marignane Ecole des Mines d Alès Laboratoire de Génie Informatique et d Ingénierie de Production LGI2P Nîmes Proposition de sujet de thèse CIFRE EUROCOPTER / LGI2P Titre Domaine
Plus en détailCisco Unified Computing Migration and Transition Service (Migration et transition)
Cisco Unified Computing Migration and Transition Service (Migration et transition) Le service Cisco Unified Computing Migration and Transition Service (Migration et transition) vous aide à migrer vos applications
Plus en détailCATALOGUE FORMATION. Product Lifecycle Management. Juin 2013
CATALOGUE FORMATION Product Lifecycle Management Juin 2013 s de formation ENOVIA V6 ENOVIA V6 Plateforme Collaborative 5 ENOVIA V6 Installation et Administration 9 ENOVIA V6 Implémentation et Développement
Plus en détailINDUSTRIALISATION 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étailLES CARTES À POINTS : POUR UNE MEILLEURE PERCEPTION
LES CARTES À POINTS : POUR UNE MEILLEURE PERCEPTION DES NOMBRES par Jean-Luc BREGEON professeur formateur à l IUFM d Auvergne LE PROBLÈME DE LA REPRÉSENTATION DES NOMBRES On ne conçoit pas un premier enseignement
Plus en détailGénie logiciel pour le commerce électronique Hiver 2003 Prof.: Julie Vachon
Génie logiciel pour le commerce électronique Hiver 2003 Prof.: Julie Vachon Travail pratique #1 «Réalisation d'une plateforme de vente aux enchères électronique» À réaliser individuellement ou en équipe
Plus en détailLa méthode des cas et le plan marketing : énoncé seul
La méthode des cas et le plan marketing : énoncé seul 12_07_2011 Table des matières Table des matières 3 I - 1. Point méthodologique 7 A. 1.1. Définitions...7 B. 1.2. Plan d'analyse type...8 C. 1.3. Synthèse...13
Plus en détailTopologie du web - Valentin Bourgoin - http://www.valentinbourgoin.net. Méthodes agiles & SCRUM
Méthodes agiles & SCRUM 1/ Pourquoi les méthodes agiles? Définition d une méthode agile. Fondamentaux. Quand les utiliser? 2/ SCRUM En quoi est-ce une méthode agile? Sprints et releases. Le Product Owner.
Plus en détailSommaire. Conduite de projet Méthode d analyse et de conception. Processus unifié. Objectifs d un processus de développement
Conduite de projet Méthode d analyse et de conception Processus unifié G. Picard SMA/G2I/ENS Mines Saint-Etienne gauthier.picard@emse.fr Octobre 2009 Sommaire!!Objectifs d un processus d ingénierie logicielle!
Plus en détailConception d'un système d'information WEB avec UML Par Ass SERGE KIKOBYA
Conception d'un système d'information WEB avec UML Par Ass SERGE KIKOBYA I. Introduction Suite à une demande des étudiants, il m'est apparu intéressant de montrer, à travers un exemple concret, comment
Plus en détailOracle Fusion Middleware Concepts Guide 11g Release 1 (11.1.1) Figure 1-1 Architecture Middleware
1 Introduction Ce chapitre décrit Oracle Fusion Middleware. Il comprend : o Qu'est-ce que Middleware o Les fonction de Middleware o L'architecture de conception Middleware o L'architecture orientée services
Plus en détailLes nouvelles architectures des SI : Etat de l Art
Les nouvelles architectures des SI : Etat de l Art Objectif Mesurer concrètement les apports des nouvelles applications SI. Être capable d'évaluer l'accroissement de la complexité des applications. Prendre
Plus en détail3. SPÉCIFICATIONS DU LOGICIEL. de l'expression des besoins à la conception. Spécifications fonctionnelles Analyse fonctionnelle et méthodes
PLAN CYCLE DE VIE D'UN LOGICIEL EXPRESSION DES BESOINS SPÉCIFICATIONS DU LOGICIEL CONCEPTION DU LOGICIEL LA PROGRAMMATION TESTS ET MISE AU POINT DOCUMENTATION CONCLUSION C.Crochepeyre Génie Logiciel Diapason
Plus en détailIntroduction aux concepts d ez Publish
Introduction aux concepts d ez Publish Tutoriel rédigé par Bergfrid Skaara. Traduit de l Anglais par Benjamin Lemoine Mercredi 30 Janvier 2008 Sommaire Concepts d ez Publish... 3 Système de Gestion de
Plus en détailMaster CCI. Compétences Complémentaires en Informatique. Livret de l étudiant
Master CCI Compétences Complémentaires en Informatique Livret de l étudiant 2014 2015 Master CCI Le Master CCI (Compétences Complémentaires en Informatique) permet à des étudiants de niveau M1 ou M2 dans
Plus en détailNORME INTERNATIONALE D AUDIT 330 PROCÉDURES A METTRE EN ŒUVRE PAR L'AUDITEUR EN FONCTION DE SON ÉVALUATION DES RISQUES
NORME INTERNATIONALE D AUDIT 330 PROCÉDURES A METTRE EN ŒUVRE PAR L'AUDITEUR EN FONCTION DE SON ÉVALUATION DES RISQUES SOMMAIRE Paragraphes Introduction... 1-3 Réponses globales... 4-6 Procédures d'audit
Plus en détailCahier Technique. «Développer une application intranet pour la gestion des stages des étudiants» Antonin AILLET. Remi DEVES
Antonin AILLET Remi DEVES Thibaut AZZOPARDI 2 ème année de DUT Informatique Cahier Technique «Développer une application intranet pour la gestion des stages des étudiants» Encadré par Didier BOULLE Année
Plus en détailGénérer du code à partir d une description de haut niveau
Cedric Dumoulin Générer du code à partir d une description de haut niveau Ce projet vise à fournir un environnement de développement permettant de modéliser des UI Android à un haut niveau d abstraction,
Plus en détailDéveloppement d un interpréteur OCL pour une machine virtuelle UML.
ObjeXion Software Prototyping made easy SA au capital de 500 000 F Siret 421 565 565 00015 APE 722Z Téléphone : 03 89 35 70 75 Télécopie : 03 89 35 70 76 L embarcadère 5, rue Gutemberg 68 800 Vieux-Thann,
Plus en détailAlfresco Guide Utilisateur
Alfresco Guide Utilisateur ATELIER TECHNIQUE DES ESPACES NATURELS - 1 Table des matières Alfresco Guide Utilisateur...1 Accéder à la GED de l'aten...3 Via un client FTP...3 Onglet Général...3 Onglet Avancé...3
Plus en détailclaroline classroom online
de la plate-forme libre d'apprentissage en ligne Claroline 1.4 Manuel Révision du manuel: 06/2003 Créé le 07/09/2003 12:02 Page 1 Table des matières 1) INTRODUCTION...3 2) AFFICHER LA PAGE DE DEMARRAGE...3
Plus en détailCursus Sage ERP X3 Outils & Développement. Le parcours pédagogique Sage ERP X3 Outils et Développement
Cursus Outils & Développement Vous êtes Consultant, Chef de Projets, Directeur des Systèmes d Information, Directeur Administratif et Financier, Optez pour les «formations Produits» Nous vous proposons
Plus en détailMS PROJECT 2000. Prise en main. Date: Mars 2003. Anère MSI. 12, rue Chabanais 75 002 PARIS E mail : jcrussier@anere.com Site : www.anere.
DOCUMENTATION MS PROJECT 2000 Prise en main Date: Mars 2003 Anère MSI 12, rue Chabanais 75 002 PARIS E mail : jcrussier@anere.com Site : www.anere.com Le présent document est la propriété exclusive d'anère
Plus en détailANALYSE D UN SYSTEME D INFORMATION ET EXTENSION DE
Université de Fribourg, Suisse Département d'informatique Bachelor en informatique de gestion ANALYSE D UN SYSTEME D INFORMATION ET EXTENSION DE CELUI-CI PAR DE NOUVELLES FONCTIONNALITES Travail de séminaire
Plus en détailGé 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