Daylight. Démarche ergonomique et RUP. Daylight 2001 Démarche ergonomique et RUP 1/1 07/03/02 CSI_RUPERGO02

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

Download "Daylight. Démarche ergonomique et RUP. Daylight 2001 Démarche ergonomique et RUP 1/1 07/03/02 CSI_RUPERGO02"

Transcription

1 Daylight Démarche ergonomique et RUP Daylight 2001 Démarche ergonomique et RUP 1/1

2 Synthèse Ce document est une synthèse des travaux effectués par Daylight, sur la prise en compte des problématiques ergonomiques dans le Processus Unifié (UP) et plus particulièrement dans l outil associé Rational Unified Process (RUP). Etat Juillet Document de travail version ère version Sept Document de travail version 0.06 axes d évolution RUP intégrant l ergonomie Oct Validée version 0.07 intégration des évolutions RUP V 2001A Diffusion La diffusion ou reproduction de ce document est autorisées sous réserve que le document soit conservé en l état, notamment pour les mentions relatives aux auteurs et copyright. Mots clés Processus Unifié, UP, RUP, Ergonomie, Utilisabilité, démarche centrée utilisateur, UML, Cas d'utilisation, Use-case. Auteurs Dominique Causse - Daylight. Contributeurs Christian Pian - Daylight, Odile Carron - Daylight. Daylight 2001 Démarche ergonomique et RUP 2/2

3 Table de matière 1. Introduction Objet du document Terminologie utilisée dans ce document Avertissement Utilisation et reproduction Contact, remarques 4 2. Conception d interfaces utilisateurs et RUP Conception d interface utilisateur dans RUP Problèmes soulevés par l approche mise en oeuvre dans RUP RUP, un processus centrée architecture plutôt qu utilisateur Les concepts de l approche centrée utilisateur Vers un renforcement de l approche centrée utilisateur dans RUP? 7 3. Les «use-case» Des définitions multiples Un point de vue qui a évolué Des cas d utilisation «essentiels» 8 4. Prise en compte de l approche ergonomique dans RUP Définir une démarche centrée utilisateur Un nouveau rôle Etendre le champ d intervention Vue synthétique du rôle d ergonome Un niveau de guidage à renforcer Mise en œuvre progressive Annexe Bibliographie Traduction française de la terminologie utilisée 16 Daylight 2001 Démarche ergonomique et RUP 3/3

4 1. Introduction 1.1 Objet du document Ce document est une synthèse des travaux effectués par Daylight, sur la prise en compte des problématiques ergonomiques dans le Processus Unifié (UP) et plus particulièrement dans l outil associé Rational Unified Process (RUP). Les points abordés sont : - analyse des activités de conception d interfaces utilisateurs dans RUP ; - problématique de mise en œuvre des cas d utilisation pour la conception d interface ; - axes d adaptations de RUP pour mieux prendre en compte la dimension ergonomique de la conception d interface logicielle. 1.2 Terminologie utilisée dans ce document Démarche centrée utilisateur Une démarche centrée utilisateur englobe tous les aspects d une démarche de conception en les articulant autour du besoin des utilisateurs. Elle implique généralement une approche itérative et la mise en œuvre de techniques ergonomiques. Utilisabilité L utilisabilité est définie dans L ISO 9241[ISO 9241] comme «la mesure dans laquelle un produit peut être utilisé par des utilisateurs particuliers pour réaliser un objectif définit avec efficacité, efficience, et satisfaction dans un contexte précis d utilisation». Le terme d utilisabilité est beaucoup plus employé que celui d ergonomie dans le monde anglosaxon. Autres termes Ce document utilise abondamment la terminologie RUP. La documentation RUP étant pour le moment uniquement disponible en anglais, une traduction des termes les plus utilisés dans ce document est donnée en annexe. Les autres termes sont définis dans le glossaire de RUP. 1.3 Avertissement Ce document est réalisé par les consultants de Daylight. Il est appelé à évoluer en fonction des différents apports et retour d expérience et n a rien «d officiel». Il n engage en rien Rational ni Daylight. Ses sociétés ne seraient être tenues pour responsable de la mise en œuvre des démarches présentées dans ce document. RUP est un produit développé et commercialisé par Rational Software. La version actuelle de ce document se base sur la version 2001A de RUP et n intègre pas les dernières évolutions. Ce sera l objet d un autre document. 1.4 Utilisation et reproduction La diffusion ou reproduction de ce document est autorisées sous réserve que le document soit conservé en l état, notamment pour les mentions relatives aux auteurs et copyright. 1.5 Contact, remarques Pour toutes vos remarques, contributions, informations complémentaires, ou pour une mise à jour du présent document vous pouvez contacter l auteur à l adresse Daylight 2001 Démarche ergonomique et RUP 4/4

5 2. Conception d interfaces utilisateurs et RUP Ce chapitre donne un éclairage sur la prise en compte des problématiques ergonomiques dans RUP. 2.1 Conception d interface utilisateur dans RUP Krutchen, principal architecte du produit Rational Unified Process (RUP), définit plusieurs activités liées à la conception des interfaces utilisateurs ([Kruchten 2000] et le chapitre 5 de [Harmelen 2001]) : développer la charte ergonomique de projet (user-interface-guidelines) ; modéliser l interface utilisateur ; prototyper l interface utilisateur ; Il définit aussi un rôle, le concepteur d interface utilisateur (user interface designer). Ce dernier est responsable de plusieurs artefacts : lesacteurs; le «use-case storyboard» ; un prototype de l interface utilisateur ; les classes frontières ; la charte ergonomique de projet ; [RUP] Dans la version actuelle de RUP, les activités de conception d interface sont regroupées dans deux enchaînements de tâches (workflow) : le recueil des besoins (requirement workflow) et plus précisément la dernière étape de ce dernier, pour affiner la définition du système (Refine the System Definition). Cette étape permet de modéliser et prototyper l interface, des spécifications supplémentaires permettent de plus de préciser les contraintes d utilisabilités mais cet artefact n est pas sous la responsabilité directe du concepteur d interface ; la gestion des environnements pour la charte ergonomique du projet ; 2.2 Problèmes soulevés par l approche mise en oeuvre dans RUP La conception d interface limitée à l expression des besoins Une des critiques qui revient souvent sur la mise en oeuvre dans RUP de la conception d interface utilisateur est la restriction des activités de conception d interface au workflow recueil des besoins. Une démarche centrée utilisateur se doit en effet, de couvrir l ensemble des étapes du processus. Daylight 2001 Démarche ergonomique et RUP 5/5

6 Kruchten argumente que cette restriction ne limite pas le rôle de concepteur d interface à une phase particulière du projet, du fait de la nature itérative du processus. Cependant l expérience montre que les problématiques d utilisabilité apparaissent tout le long du processus à différentes étapes d une même itération. Pour certain auteur, le positionnement du prototype dans le cadre du workflow recueil des besoins pose un autre problème. En effet, l expression des besoins vient généralement avant l élaboration d une solution dont le prototype fait partie. Le risque est de se fermer trop tôt dans une solution. Il faut cependant noter que dans RUP, le prototype est l une des dernières étapes de ce workflow. Remarque : La dernière version de RUP V. 2001A comprend un nouveau roadmap «Usability Engineering». Cependant ce document ne remet pas en cause la discussion ci-dessus. Pour une discussion plus complète se reporter au chapitre suivant. Un rôle qui ne couvre que partiellement les aspects d utilisabilités Dans RUP, le rôle de concepteur d interface utilisateur est plus proche d un «ingénieur IHM» dans la terminologie française que d un ergonome. Il doit modéliser et définir visuellement l interface, mais pas nécessairement fournir des compétences en ergonomie et en utilisabilité sauf éventuellement dans le cas du prototypage. Un des rares documents qui répertorie les critères d utilisabilité de l interface, l artefact spécifications supplémentaires, est sous la responsabilité de l analyste système, le concepteur d interface utilisateur n est même pas cité dans les rôles amenés à intervenir sur ce document. Dans une 1ère approche pour couvrir les développements d application Web [Rational WP 99], un rôle de directeur artistique (creative designer) avait été ajouté, mais toujours pas de rôle ayant en charge les aspects d utilisabilité. De ce fait, il n existe pas de rôle clairement définit pouvant prendre en charge les aspects liés à l utilisabilité d une interface. Remarque : La dernièreversionderup V. 2001A comprend un nouveau roadmap «Usability Engineering». Cependant ce document ne modifie pas le rôle du concepteur d interface et ne remet pas en cause la discussion ci-dessus. Pour une discussion plus complète se reporter au chapitre suivant. 2.3 RUP, un processus centrée architecture plutôt qu utilisateur UP est un processus «centré-architecture»,itératif, se basant largement sur la modélisation UML et faisant référence à un ensemble de «meilleures pratiques» issus de l expérience Rational dans le domaine du génie logiciel. Mais les concepts d'utilisabilité ou d approche centrée utilisateur ne sont que très partiellement intégrés Les concepts de l approche centrée utilisateur Il existe un document dans RUP décrivant les «concepts» de l approche centrée utilisateur[rup User-Center-Design], qui reprend de façon théorique cette dernière. Mais elle n est mise en œuvre que partiellement dans la version actuelle de RUP. Le document s appuie sur quatre concepts issus de Gould [Gould 1988] : réflexion centrée sur les utilisateurs ; intégration avec le design ; tester l interfaceauplustôt; conception itérative. Ces quatre points sont analysés ci-dessous. Réflexion centrée sur les utilisateurs,l intégration des utilisateurs dans le processus est peu développée dans RUP et plusieurs techniques ergonomiques doivent venir compléter les «workshop» existant (Requirement Workshop, Use-Case-Analysis Workshop,..) dont aucun ne fait explicitement référence aux problématiques d utilisabilité : RUP reconnaît clairement cet aspect Daylight 2001 Démarche ergonomique et RUP 6/6

7 «In the Rational Unified Process, workshops are used at several key stages, but these must be complemented by the kinds of activities Gould describes if an accurate picture is to be formed.» [RUP User-Centered-Design] Intégration avec le design, RUP propose de créer un modèle du domaine reprenant les concepts et la terminologie des utilisateurs lors de l expression des besoins. Certaines des classes du domaine deviendront des classes frontières du système. Cependant cette approche est difficile à mettre en œuvre. Dans la pratique les modèles du domaine réalisés par les analystes sont souvent éloignésdumodèle conceptuel des utilisateurs. Au sens de l ergonomie cognitive, le modèle conceptuel de l utilisateur est la façon dont ce dernier se représente le comportement d un système tandis que le modèle du domaine se concentre sur l organisation ou la façon dont le système fonctionne - ensemble de classes et d objets du système favorisant la réutilisation, nécessaires au bon fonctionnement du logiciel. Cette difficulté est mise en avant par William Hudson [Harmelen 2001]. Tester l interface au plus tôt dans RUP ce point est pris en compte dans l activité prototypage de l interface utilisateur dans le cadre du workflow recueil des besoins. C est un des rares moments ou l on envisage explicitement l intervention d un expert en utilisabilité, mais uniquement en tant qu expert externe au projet pouvant donner un avis sur l interface (ce point n est d ailleurs pas développé dans RUP). Mais en dehors de l activité de prototypage, RUP ne précise pas à quel moment mettre en oeuvre les tests d utilisabilité: «Each project team needs to consider these challenges against the unique project environment they are working within, and arrive at the appropriate timing, method and approach to usability testing» [RUP Usability Testing]. Remarque : Cette imprécision est en partie corrigée dans le roadmap «Usability Engineering» [RUP Usability Engineering], qui fait référence à ces tests d utilisabilité dans les dernières phases de construction et de transition, mais en dehors de document ce point n'est pas développé. Conception itérative, Cet aspect ne pose pas de problème avec RUP qui s appuie largement sur une démarche itérative. Pour une analyse complémentaire de la mise en œuvre de démarches ergonomiques ou de techniques favorisant l utilisabilité des logiciels développés dans RUP, on peut se référer à la série d article de David Anderson [Anderson 2001, 10/1999, 2/1999] ou aux travaux de Constantine et Lockwood [Constantine 1999] Vers un renforcement de l approche centrée utilisateur dans RUP? L avant dernière version de RUP avait était l occasion de l ajout d un document «concept d utilisabilité»associé au workflow recueil des besoins [RUP User-Centered-Design]. La dernière versionderup V. 2001A comprend quant à elle un nouveau roadmap «Usability Engineering» [RUP Usability Engineering]. Ce dernier document développe comment les techniques ergonomiques sont mises en œuvre dans RUP. Il a deux mérites importants à nos yeux : La 1 ère est de mettre en avant les problématiques ergonomiques. Dans la version précédente le document concepts d utilisabilitéétait associé au workflow recueil des besoins, alors que ce dernier document apparaîtdèslaprésentation du Processus, rubrique «Overview». La deuxième est d envisager explicitement le rôle des techniques d utilisabilité dans tous les workflow et phase du processus. Cependant ce document ne remet pas en cause l analyse précédente. En effet il n y a toujours pas de rôle dédiéàl utilisabilité et si l impact des techniques ergonomiques dans les autres workflow est envisagé,iln induit pas de modification dans les activités actuelles du processus ou dans les rôles, voir même dans les artefacts. Daylight 2001 Démarche ergonomique et RUP 7/7

8 3. Les «use-case» RUP s appuie largement sur la modélisation UML et notamment sur les cas d utilisation (use-case) qui permettent d assurer la tracabilité entre l ensemble des modèles. Ces derniers sont notamment utilisés dans l enchaînement des tâches liés au recueil des besoins lors du quel la majeure partie des activités de conception d interface prennent place dans RUP. Les cas d utilisations comme support à la modélisation d une interface utilisateur posent cependant de nombreux problèmes. Ces différents points sont revus rapidement ci-dessous. 3.1 Des définitions multiples Les cas d utilisations ont été mis en œuvre par Ivar Jacobson à la fin des années 80, pour décrire le comportement d un système du point de vue de l utilisateur. Mais le flou sur la description de leur mise en œuvre a permis un nombre important d interprétation. Une des 1ère définition est donnée par Jacobson : «Un cas d utilisation est une façon spécifique d utiliser le système en utilisant certaine partie des fonctionnalités. Un cas d utilisation constitue une séquence complète d interaction qui prennent place entre un acteur et le système» [Jacobson 1992] UMLtentedepréciser cette définition: «la spécification d une séquence d actions, incluant des variantes et séquences d erreurs, qu un système, un sous-système ou une classe réalisent en interagissant avec des acteurs externes (au système)» [Rumbaugh 1999].» UP met l accent sur la valeur ajouté pour l utilisateur «Un cas d utilisation spécifie une séquence d actions, avec ses variantes, pouvant être effectuée par le système et produisant un résultat satisfaisant pour un acteur particulier» [Jacobson al. 2000] 3.2 Un point de vue qui a évolué Malgré l accent mis sur la «satisfaction d un acteur» dans UP, les cas d utilisation se sont progressivement éloignésdel approche originelle centréesur«l usage» pour aller vers une approche plus centréesurl architecture (system-centric). Les auteurs de UP mettent surtout en avant le système : «le modèle des cas d utilisation saisit tous les besoins fonctionnels du système» [Jacobson al. 2000] et non de l utilisateur! Cela peut apparaître anodin, mais le point de vue pris a des impacts importants pour l emploi des cas d utilisation lors de la réalisation des interfaces utilisateurs. Un des problèmes rencontrés vient de l introduction de la notion d acteur, - «Someone or something, outside the system that interacts with the system» [Glossaire RUP] - qui a entraîné un nombre important de confusion entre les différents concepts : utilisateurs, rôles et acteurs. Le fait notamment qu un acteur peut être un utilisateur ou un autre systèmefaitperdredevulerôle pouvant être joué par un utilisateur humain. Pour cette raison Constantine et Lockwood préfèrent parler de «rôle utilisateur» i.e. un rôle joué par un «acteur humain», à distinguer d un «acteur système» [Constantine 1999]. 3.3 Des cas d utilisation «essentiels» Constantine et Lockwood ont par ailleurs développé une nouvelle forme de cas d utilisation les cas d utilisation essentiels (essentiel use-case) [Constantine 1999]. L idée et de prendre un point de vue différent lors de l élaboration des use-case en mettant l accent sur les intentions de l utilisateur - plutôt que la liste des actions effectuées par l utilisateur et les responsabilités du système - plutôt que les réponses du système. L objectif est de mettre l accent sur les besoins des utilisateurs et de ne pas prendre en comptes les contraintes d implémentation afin de ne pas figer à priori l interface utilisateur. Daylight 2001 Démarche ergonomique et RUP 8/8

9 «A single, discrete, complete, meaningful, and well-defined task of interest to an external user in some specific role or roles in relationship to a system, comprising the user intentions and system responsibilities in the course of accomplishing that task, described in abstract, technology-free, implementation-independent terms using the language of the application domain and of external users in role.» [Constantine 1999] Cette approche est citée rapidement dans UP [Jacobson al. 2000] et dans les concepts RUP [RUP User-Centered-Design] ainsi que dans le guide RUP pour la réalisation des «storyboard» : «Start by clarifying the use case itself - not its user interface. Start by keeping the description independent of the user interface, especially if the use case is unexplored. This will help you capture the essence of the use case, similar to the "essential use cases" described in Concepts: User-Centered Design. Then, later on, as the use case is understood, the flow of events - storyboard can be augmented with user interface and usability aspects» [RUP Guidelines: Use- Case Storyboard ] Mais la description de la mise en œuvre des cas d utilisation essentiels reste limitée et peut facilement passer inaperçue par les concepteurs utilisant RUP. 4. Prise en compte de l approche ergonomique dans RUP Il existe des possibilitésréelles de mettre en oeuvre une approche centrée utilisateur en s appuyant sur RUP, mais cette approche n est que partiellement intégrée rendant difficile sa mise en œuvre systématique. Gulliksen, Göransson et Lif [Harmelen 2001] ont analysé plusieurs grands projets utilisant RUP. Leur conclusion est que dans l état actuel, les seuls projets ayant réussis à prendre en compte correctement les aspects d utilisabilité sont ceux ayant intégré un expert en utilisabilité rompu aux différentes techniques ergonomiques. A l opposé les projets ayant eu des problèmes importants d utilisabilité ne disposaient pas d un support de la méthode suffisant. L utilisabilité d une interface a été reconnue comme un enjeu important pour la réussite d une application, notamment dans le cas des sites web, tant pour des aspects de coût, de manque à gagner, que de risque, par l ensemble des acteurs du marché. Après ce constat deux orientations peuvent être prises, développer une nouvelle méthode tels que User Interface Modeling - UIM de Gulliksen, Göransson et Lif [Harmelen 2001] ou Usage Center Design développé par Constantine et Lockwood [Constantine 1999], ou tenter de s appuyer sur les méthodes existantes pour qu elles prennent mieux en compte les approches centrés-utilisateur. De part les possibilités existantes dans RUP permettant de mettre en œuvre des démarches centréutilisateur même si elles sont insuffisantes, et des évolutions actuelles de RUP, il nous semble plus intéressant dans l état d adopter la 2 ème approche. La mise en œuvre dans RUP des évolutions proposées ci-dessous, peut se faire progressivement. L évolution d un processus de développement pose en effet de nombreux problèmes tels que la disponibilité des ressources, la formation ou tout simplement l évolution d une culture d entreprise. 4.1 Définir une démarche centrée utilisateur L ISO 13407, Human-Centered Design Process for Interactive Systems - [ISO 13407], définit quatre principes de bases, devant être respectés par les approches centrées-utilisateur : - une répartition appropriée des fonctions entre système et utilisateurs, -l implication active des utilisateurs, - des solutions interactives de Design, -lamiseenœuvre de groupes interdisciplinaires Daylight 2001 Démarche ergonomique et RUP 9/9

10 Une des problématiques relevéslorsdel analyse précédente est que, malgré un grand nombre de possibilités de support de ces différents aspects d une démarche centréesurl utilisateur, il n existe pas d approche clairement définie, guidant suffisamment les équipes de projet pour mettre en œuvre ces techniques. Nous explorerons ci-dessous les solutions pouvant permettre d améliorer la prise en comptes d une démarche ergonomique dans RUP. Certaines de ces solutions sont inspirés des auteurs tels que William Hudson, d autres sont issues de l expérience des consultants Daylight dans la réalisation de projets internet ou intranet faisant intervenir systématiquement des ergonomes. Les axes explorés sont : l intégration d un rôle prenant en charge clairement les aspects d utilisabilité dans les équipes de projets ; étendre le champ d intervention de ce nouveau rôle au-delà du recueil des besoins ; l introduction explicite de nouvelles activités et techniques liées aux problématiques d utilisabilité ; la mise en œuvre systématique des cas d utilisation essentiels ; Ces évolutions sont en cours de test sur des projets pilotes et évolueront selon les retours d expériences et les remarques sur le présent document. 4.2 Un nouveau rôle Un 1er axe de travail pour mieux intégrer la problématique ergonomique dans RUP est de définir un nouveau rôle, distinct du concepteur d interface utilisateur (UIDesigner) actuellement présent dans RUP : Le rôle doit avoir des compétences reconnues en ergonomie que ce soit en terme de maîtrise des standards et pratiques (bonnes et mauvaises) du marché, de connaissance de la charte ergonomique de l entreprise mais surtout des techniques ergonomiques tels que l analyse à partir de grille de critères, l observation des utilisateurs en contexte,. permettant de faciliter l élaboration d une interface répondant aux critères d utilisabilité ; Il peut reprendre certaines activités du concepteur d interface à sa charge tels que le prototypage et la rédaction de la charte ergonomique de projet, par contre il laisse au concepteur d interface ou à l analyste la responsabilité des cas d utilisation et de l identification des classes frontières ; il intervient en tant que support aux équipes de projet tout le long du processus. Généralement ce type de rôle ne travaille pas en solitaire mais plutôt dans le cadre d équipe pluridisciplinaire : ergonomes, analyste, directeur artistique, utilisateur final et stakeholder (commanditaire ou intervenants tel que traduits dans [Jacobson al. 2000]). Ce dernier point nous paraît particulièrement important, l expérience nous a montré que les problèmes de choix sur la mise en œuvre d une fonctionnalité en terme d interface ne sont pas tous régléslorsdel expression des besoins. Ce profil est proche de celui donnéélaboré par Gulliksen, Göransson et Lif [Harmelen 2001]. Il correspond aussi à la réalité du terrain. C est le cas des projets internet réalisés par Daylight mais aussi par de nombreuse société que se soit en France ou aux Etats Unis. La dénomination de ce rôle (ou travailleur tel que traduit dans [Jacobson al. 2000] ) peut rester concepteur d interface utilisateur, mais il nous semble que cela risque de porter à confusion et n insiste pas suffisamment sur la compétence en utilisabilité ou en ergonomie. Nous proposons donc de dénommer ce rôle simplement «ergonome» ou «usable expert» en anglais tels que généralement dénommé sur le marché actuel. Daylight 2001 Démarche ergonomique et RUP 10/10

11 4.3 Etendre le champ d intervention Le concepteur d interface intervient dans RUP uniquement lors de l enchaînement d activité liée à l expression des besoins et de façon plus sommaire dans le cadre des environnements. Le concepteur d interface utilisateur dans RUP aujourd hui : Disciplines Requirements Environment Objectif de la Disciplines Expression des besoins pour le système à réaliser Préparation de l environnement projet Activité du concepteur d interface utilisateur Modéliser l interface Prototyper l interface Rédiger la charte ergonomique Remarques : Dans la dernière version de RUP [RUP Usability Engineering] les activitésetles artefacts important pour l utilisabilité d une application sont développés pour l ensemble des disciplines, mais ne sont pas sous la responsabilité directe ou indirecte du concepteur d interface utilisateur. Nous proposons dans le paragraphe suivant d étendre le périmètre d action de l ergonome à l ensemble du processus de développement. Son rôle peut être plus ou moins important selon les différents workflow, mais sa disponibilité notamment en support aux équipes de projet nous paraît indispensable pour assurer la réussite des projets ayant une forte composante d interactivité et en particulier des projets internet ou intranet. De nombreuses techniques ergonomiques peuvent être déployées sur un projet. Leur mise en œuvre dépend de facteurs tels que : L ampleur du projet ; Les enjeux ; La cible utilisateur (disponibilité par exemple) ; Les contrainte en délais et coût La disponibilité en terme de support (ergonome, techniques documentées, ) ; Une analyse des différentes techniques mise en œuvres et des fréquences d utilisation est donné par William Hudson dans [Harmelen 2001]. Elles vont de l évaluation d expert, au prototypage en passant par l observation des utilisateurs, l analyse des tâches, l analyse de contexte, l analyse critériologiques, la mise en œuvre de «focus group»,lescasd utilisation essentiels, la rédaction de charte ergonomique,. Certaines de ces techniques peuvent donner lieu à une activitéàpart entière, mais la plupart viennent s intégrer dans des activités existantes de RUP. La mise en œuvre de ces activités dans les différents workflow est présentée ci-dessous. Daylight 2001 Démarche ergonomique et RUP 11/11

12 L ergonome, un champ d intervention plus étendu : Disciplines Business modeling Requirements Objectif de la Discipline Elaboration de la vision Objectif et Cible Rentabilité Expression des besoins pour le système à réaliser Activités et techniques mises en œuvre par l ergonome Définir le profil et le contexte utilisateur en mettant à jour les artefacts : "business vision, business actor, glossary " Affiner la cible et profils des utilisateurs, observation sur site Si besoin mise en œuvre de focusgroup en relation avec le marketing Analyse critériologique d applications ou de sites existant Valider les principales règles et orientations devant être respectées par l interface en mettant à jour les artefacts : "actors, supplementary specification, storyboard, charte ergonomique, " Analyse des tâches Storyboard Intégration avec le design graphique Prototypage de l interface (papier et électronique) Définition du système de navigation (pour les applications web notamment) Analysis and design Spécification du système Support aux analystes et validation des spécifications de l interface Implementation Code exécutable Support aux équipes de développements Test Recette Tester l utilisabilité Analyse d application existante pour identifier les points à améliorer Observation et expérimentation sur le prototype check-list / analyse critériologique évaluation d experts sur l exécutable finalisé Environment Préparation de l environnement projet Rédiger la charte ergonomique et éventuellement préciser le rôle de l ergonome et la mise en œuvre des techniques ergonomique dans l artefact "Development case" Il nous semble aussi intéressant de systématiser l utilisation des «cas d utilisation essentiels» [Constantine 1999] afin de limiter les problèmes identifiés au chapitre précédent. L objectif est en effet de ne pas imposer un mode d implémentation à priori. Cependant cette activité n est pas nécessairement sous la responsabilité de l ergonome, même s il peut y participer. Daylight 2001 Démarche ergonomique et RUP 12/12

13 4.4 Vue synthétique du rôle d ergonome Le schéma suivant représentelerôle d ergonome, les activités et les artefacts associésdécrits cidessus. Charte ergonomique d'entreprise glossaire de projet cas d'utilisation essentiel analyste directeur artistique développeur Ergonome Définir le profil utilisateur Tester l'utilisabilité Prototyper l'interface Rédiger la charte ergonomique de projet Support aux équipes de projet stakeholder modifie utilisateur O O O acteurs spécifications complémentaires d'utilisabilité prototype dossier de test d'utilisabilité charte ergonomique de projet Daylight 2001 Démarche ergonomique et RUP 13/13

14 4.5 Un niveau de guidage à renforcer Au-delà de l intégration d un nouveau rôle et l identification d activités ou de techniques ergonomiques devant ou pouvant être mises en œuvre, il est nécessaire d améliorer le support de ces approches par un guidage plus explicite dans le processus. C est en effet un des points faibles identifiés lors des chapitres précédents. Ce-ci revient à adapter RUP pour : ajouter explicitement le rôle d ergonome (ainsi que directeur artistique et infographiste pour les sites web) ; faire apparaître clairement son rôle dans les différentes activités dont il est responsable ou dans les quels il intervient ; identifiés ces activités dans les workflow correspondant ; compléter les artefacts ou les mettre à jours ; ajouter des guides expliquant les techniques ergonomiques pouvant être mises en œuvre ; Ce travail est en cours au sein de Daylight, l objectif étant d obtenir un «canevas» associéàun «road map» permettant d intégrer rapidement cette approche dans RUP. 5. Mise en œuvre progressive L adaptation d un processus de développement logiciel se fait généralement progressivement. C est d ailleurs la préconisation de Rational pour la mise en œuvre de RUP dans une organisation. Les axes d évolution cité ci-dessus peuvent facilement être mis en œuvre en plusieurs étapes. Un exemple de déploiement progressif est le suivant. L identification du rôle d ergonome est un bon début et même si son niveau d intervention est relativement réduit dans un 1 er temps, il permet de mettre l accent sur les aspects d utilisabilité d une interface et peut jouer efficacement le rôle de support auprès des équipes de projet ; Progressivement, son rôle peut être mieux identifié dans RUP et son intégration aux équipes de projet plus naturelle ; Le niveau de guidage peut être lui aussi progressivement renforcé dans RUP, afin de ne pas reposer uniquement sur l intervention de l ergonome, mais plutôt de sensibiliser progressivement et toujours les équipes de projets aux problématiques d utilisabilités; Des formations de type sensibilisation aux problématiques d utilisabilité (enjeux, risques, coûts ), ou de mise en œuvre des cas d utilisation essentiels doivent venir renforcer ce dispositif ; Comme pour toute mise en œuvre de RUP, l adaptation du processus doit aussi prendre en compte les spécificités des projets et la culture d entreprise. Daylight 2001 Démarche ergonomique et RUP 14/14

15 6. Annexe 6.1 Bibliographie Ouvrages et articles [Armour al.2001] Advanced Use Case Modeling F Armour, G Miller Addison Wesley 2001 [Constantine1999] Software for Use Larry L. Constantine, Lucy A.D. Lockwood Addison Wesley 1999 [Gould 1988] How to Design Usable Systems J. D. Gould Handbook of Computer Interaction 1988 [Harmelen 2001] Object Modeling and User Interface Design M.V. Harmelen Addison Wessley 2001 [ISO 13407] Human-Centered Design Process for Interactiv Systems ISO [ISO 9241] Software Ergonomics for office work with visual display terminals ISO [Jacobson 1992] Object-Oriented Software Engineering: A Use Case Driven Approach I.Jacobson, M Christerson, P Jonsson, G. Övergaard Addison-Wesley 1992 [Jacobson al. 2000] Le Processus Unifié de développement logiciel I.Jacobson, G. Booch, J.Rumbaugh Ed.Eyrolles 2000 [Kruchten 2000] The Rational Unifed Process an Introduction, Second Edition P. Kruchten Addison Wesley 2000 [Pian et co. 2002] Techniques ergonomiques pour la conception d interfaces Christian Pian et co. Daylight 2002 [Rumbaugh 1999] The unified Modeling Language Reference Manual J.Rumbaugh I.Jacobson, E. Booch, Addison-Wesley 1999 Ressources en lignes [Anderson 2001] UI Rupture Uidesign.net David Anderson jan [Anderson 10/1999] Use Cases still considered Dangerous David Anderson oct [Anderson 2/1999] Are Use Cases the death of good UI Design? David Anderson feb [Foruse-1] The Usability Challenge: Can UML and the Unified Process Meet It? Larry Constantine [Foruse-2] Structure and Style in use cases for user interface design Larry Constantine Daylight 2001 Démarche ergonomique et RUP 15/15

16 (un des chapitres du livre "Object Modeling and User Interface Design") [Ratioanl Edge Rational Edge Magazine en ligne qui aborde un certain nombre de sujets complémentaires. [RUP User-Centered-Design] Concept : User-Centered Design RUP, rubrique Concepts du Requirement Discipline v et suivant [RUP Usability Testing] Concept : Usability Testing RUP, rubrique Concepts de Testing Discipline v et suivant [RUP Usability Engineering] Roadmap : Usability Engineering RUP, rubrique Roadmap de Overview v. 2001A [Rational WP 99] Building Web Solution with the Rational Unified Process White paper Traduction française de la terminologie utilisée La plupart de ces traductions sont issues du livre «Le Processus Unifié de développement logiciel» [Jacobson al. 2000]. Boundary classes - classes frontières Essential Use case cas d utilisation essentiel Requirements recueil des besoins Usability utilisabilité Use case cas d utilisation User interface designer - concepteur d interface utilisateur Workflow enchaînement des tâches. Dans la dernière version de RUP, pour les principaux workflow le terme est devenu disciplines. Daylight 2001 Démarche ergonomique et RUP 16/16

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

Use Cases. Introduction

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

Plus en détail

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

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

Projet : Plan Assurance Qualité

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

Plus en détail

Les Bonnes PRATIQUES DU TEST LOGICIEL

Les Bonnes PRATIQUES DU TEST LOGICIEL Les Bonnes PRATIQUES DU TEST LOGICIEL SOMMAIRE Qu est-ce que le test logiciel? Pourquoi le test est-il un maillon crucial de l ingénierie logicielle? Quels sont les différents types de tests? Qu est-ce

Plus en détail

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

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

Plus en détail

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

TCH053 Manipulation d objets multimédias et conception de sites Web non transactionnels

TCH053 Manipulation d objets multimédias et conception de sites Web non transactionnels TCH053 Manipulation d objets multimédias et conception de sites Web non transactionnels Présentation du plan de cours Introduction à la norme ISO 13407 Lévis Thériault, hiver 2009 Plan de cours Consulter

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

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

Daylight. Management des projets, facteur humain et réussite des projets interactifs

Daylight. Management des projets, facteur humain et réussite des projets interactifs Daylight Management des projets, facteur humain et réussite des projets interactifs Daylight 2004 Management des projets, facteur humain et réussite de projets interactifs 1/5 Synthèse La prise en compte

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

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

Forum AMOA ADN Ouest. Présentation du BABOK. 31 Mars 2013 Nadia Nadah

Forum AMOA ADN Ouest. Présentation du BABOK. 31 Mars 2013 Nadia Nadah Forum AMOA ADN Ouest Présentation du BABOK 31 Mars 2013 Nadia Nadah Ce qu est le BABOK Ce que n est pas le BABOK Définition de la BA - BABOK version 2 Le processus de Business Analysis La structure du

Plus en détail

LOG2420 Analyse et conception d interfaces utilisateur

LOG2420 Analyse et conception d interfaces utilisateur LOG2420 Analyse et conception d interfaces utilisateur Processus de développement centré utilisateur 1/36 LOG2420 Analyse et conception d interfaces utilisateur Processus de développement centré utilisateur

Plus en détail

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

Formations Méthode et conduite de projet

Formations Méthode et conduite de projet Formations Méthode et conduite de projet Présentation des formations Qualité et Conduite de projets Mettre en place et gérer un projet SI nécessite diverses compétences comme connaître les acteurs, gérer

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

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

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

Plus en détail

Méthode de tests MODE D EMPLOI POINTS IMPORTANTS

Méthode de tests MODE D EMPLOI POINTS IMPORTANTS Méthode de tests MODE D EMPLOI Cette première partie est destinée à ceux qui débutent en tests et permet une approche progressive et simple de la méthodologie des tests. L introduction vous aura permis

Plus en détail

IAFACTORY. sommaire MATERIALIZE YOUR NEXT SUCCESS. étude marketing, expérience utilisateur, ergonomie étude des bonnes pratiques. principes.

IAFACTORY. sommaire MATERIALIZE YOUR NEXT SUCCESS. étude marketing, expérience utilisateur, ergonomie étude des bonnes pratiques. principes. sommaire principes p objectifs méthode prestation, livrable, tarif aperçu visuel à propos d MATERIALIZE YOUR NEXT SUCCESS conseil en architecture de l information www.iafactory.fr contact@iafactory.fr

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

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

Environnements de Développement

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

Plus en détail

Cas d étude appliqué à l ingénierie logicielle

Cas d étude appliqué à l ingénierie logicielle ypbl : une méthodologie pédagogique pour la professionnalisation d une formation Cas d étude appliqué à l ingénierie logicielle Ernesto Exposito 1,2, Anne Hernandez 2 1 CNRS ; LAAS ; 7 av. du Colonel Roche,

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

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

Retour d expérience. Le rôle du Business Analyst chez Orange. Nadia Magarino & Christophe Dufour 29 avril 2015

Retour d expérience. Le rôle du Business Analyst chez Orange. Nadia Magarino & Christophe Dufour 29 avril 2015 Retour d expérience Le rôle du Business Analyst chez Orange Nadia Magarino & Christophe Dufour 29 avril 2015 Plus de 161 000 salariés à votre service mobile entreprises internet et fixe Plus de 161 000

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

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

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

Plus en détail

Management par les processus les éléments structurants. Lionel Di Maggio Master 1 MIAGE

Management par les processus les éléments structurants. Lionel Di Maggio Master 1 MIAGE Management par les processus les éléments structurants Lionel Di Maggio Master 1 MIAGE 1 1. Objectifs et définitions 2. Le retour sur investissement des démarches 3. Les éléments structurants 4. Mise en

Plus en détail

ReNo, le référentiel r rentiel de normalisation Web du Gouvernement luxembourgeois. Gautier Barrère

ReNo, le référentiel r rentiel de normalisation Web du Gouvernement luxembourgeois. Gautier Barrère ReNo, le référentiel r rentiel de normalisation Web du Gouvernement luxembourgeois (adopté le 25 octobre 2007) Gautier Barrère re Paris Web 2008 1 Qui suis-je? Gautier Barrère Ergonome «Human factor» -

Plus en détail

Mémoire de Projet Professionnel TITRE DU PROJET

Mémoire de Projet Professionnel TITRE DU PROJET République Tunisienne Ministère de l Enseignement Supérieur et de la Recherche Scientifique Université de Sfax Institut Supérieur d Informatique et de Multimédia de Sfax Sigle de l ISIMS Mastère Professionnel

Plus en détail

Projet PHARES. Note de cadrage sur la production de livrables en phase finale du projet

Projet PHARES. Note de cadrage sur la production de livrables en phase finale du projet Projet PHARES Note de cadrage sur la production de livrables en phase finale du projet L.Brami, S.Damart, M. Detchessahar, M. Devigne, J. Habib, F. Kletz, C. Krohmer. Document joint à l avenant au contrat

Plus en détail

Chef de projet H/F. Vous avez au minimum 3 ans d expérience en pilotage de projet de préférence dans le monde du PLM et de management d équipe.

Chef de projet H/F. Vous avez au minimum 3 ans d expérience en pilotage de projet de préférence dans le monde du PLM et de management d équipe. Chef de projet H/F Dans le cadre de nos activités pour un de nos clients, CIMPA recherche un chef de projet H/F. - Planifier l ensemble des phases du projet - Piloter l équipe dédiée au projet - Garantir

Plus en détail

Evaluer des logiciels éducatifs

Evaluer des logiciels éducatifs DES-TEF 2001-2002 Evaluer des logiciels éducatifs Bernadette Charlier Cellule d Ingénierie Pédagogique Département Education et Technologie FUNDP 1 Evaluer des logiciels éducatifs hyper et multimédias

Plus en détail

SYSTEMES D INFORMATION & CONCEPTION de BdD

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

Plus en détail

de la réflexion r choix d un d

de la réflexion r choix d un d www.effigen.com Les étapes clés de la réflexion r au choix d un d ERP avec la présence du chef de Projet Grégoire Besson sur le stand Effigen Les grandes étapes pour un avant-déploiement réussir Le quarté

Plus en détail

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

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

Plus en détail

UML 1ère partie. Référence: http://uml.developpez.com/lp/cours/uml_free_fr_cours.html UML

UML 1ère partie. Référence: http://uml.developpez.com/lp/cours/uml_free_fr_cours.html UML UML UML 1ère partie Référence: http://uml.developpez.com/lp/cours/uml_free_fr_cours.html LOG2000 Éléments du génie logiciel 2002 Bayomock André-Claude PLAN Définition et historique Vue générale A quoi

Plus en détail

Logiciel de gestion desressources numériques Plan developpement logiciel FANTASTIC FIVE

Logiciel de gestion desressources numériques Plan developpement logiciel FANTASTIC FIVE Logiciel de gestion desressources numériques Plan developpement logiciel FANTASTIC FIVE 03/06/2015 Historique des révisions Date Version Description Auteur 03/06/2015 Plan de Développement logiciel

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

La direction artistique web

La direction artistique web La direction artistique web Introduction La partie design est une étape délicate à gérer dans le processus de création d un site web car le client est toujours impatient de voir le résultat visuel de son

Plus en détail

Quelques éléments sur la conception et l ingénierie des EIAH

Quelques éléments sur la conception et l ingénierie des EIAH Quelques éléments sur la conception et l ingénierie des EIAH Lium Université du Maine Pierre.Tchounikine@lium.univ-lemans.fr EIAH : définition EIAH = Environnement Informatique pour l Apprentissage Humain

Plus en détail

Les apports de Praxeme et son articulation avec les référentiels de pratiques

Les apports de Praxeme et son articulation avec les référentiels de pratiques Les apports de Praxeme et son articulation avec les référentiels de pratiques Praxeme dans le paysage de la méthodologie Référence PxSLB-SYD-06 Version 1.0 www.praxeme.org info@praxeme.org Objectif de

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

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

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

La Gestion d'affaires

La Gestion d'affaires Chapitre 1 - COMPRENDRE LE MARCHÉ La Gestion d'affaires Copyright 2009 CXP. 1 All rights reserved. Reproduction or distribution of this document, in any form, is expressly prohibited without the advance

Plus en détail

Conception des interfaces. 1. Le maquettage 2. La loi de Fitts 3. La méthode RITE 4. La conception des icones 5. La norme ISO 16982

Conception des interfaces. 1. Le maquettage 2. La loi de Fitts 3. La méthode RITE 4. La conception des icones 5. La norme ISO 16982 Conception des interfaces 1. Le maquettage 2. La loi de Fitts 3. La méthode RITE 4. La conception des icones 5. La norme ISO 16982 Conception des interfaces 1. Le maquettage Comprendre comment et pourquoi

Plus en détail

DOCUMENTATION ASSOCIEE A UN PROJET LOGICIEL

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

Plus en détail

Stratégie projet pour valoriser l'apport des technologies mobiles. Fréderic FADDA. Mobility GBS Leader, IBM

Stratégie projet pour valoriser l'apport des technologies mobiles. Fréderic FADDA. Mobility GBS Leader, IBM Stratégie projet pour valoriser l'apport des technologies mobiles Fréderic FADDA Mobility GBS Leader, IBM L introduction des technologies Mobiles, un accélérateur Business, Opérationnel et IT L introduction

Plus en détail

Chapitre 2 : Cycles de vie logiciel et méthodes de développement G L & A G L 2 0 1 4 / 2 0 1 5

Chapitre 2 : Cycles de vie logiciel et méthodes de développement G L & A G L 2 0 1 4 / 2 0 1 5 Chapitre 2 : Cycles de vie logiciel et méthodes de développement G L & A G L 2 0 1 4 / 2 0 1 5 Plan Chapitre 2 Modèles de cycles de vie Méthodes de développement : Méthode lourde Méthode agile Exemple

Plus en détail

Réussir un projet Intranet 2.0

Réussir un projet Intranet 2.0 Frédéric Créplet Thomas Jacob Réussir un projet Intranet 2.0 Écosystème Intranet, innovation managériale, Web 2.0, systèmes d information, 2009 ISBN : 978-2-212-54345-2 Sommaire Démarche générale de l

Plus en détail

IAFACTORY. sommaire MATERIALIZE YOUR NEXT SUCCESS. offres en conception de dispositif e-commerce cadrage du projet e-commerce. principes.

IAFACTORY. sommaire MATERIALIZE YOUR NEXT SUCCESS. offres en conception de dispositif e-commerce cadrage du projet e-commerce. principes. sommaire principes p objectifs méthode prestation, livrable, tarif aperçu visuel à propos d MATERIALIZE YOUR NEXT SUCCESS conseil en architecture de l information www.iafactory.fr contact@iafactory.fr

Plus en détail

ANGULAR JS AVEC GDE GOOGLE

ANGULAR JS AVEC GDE GOOGLE ANGULAR JS AVEC GDE GOOGLE JUIN 2015 BRINGING THE HUMAN TOUCH TO TECHNOLOGY 2015 SERIAL QUI SUIS-JE? ESTELLE USER EXPERIENCE DESIGNER BUSINESS ANALYST BRINGING THE HUMAN TOUCH TO TECHNOLOGY SERIAL.CH 2

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

EXPRESSION DES BESOINS

EXPRESSION DES BESOINS OUTIL DE GESTION DE PROJET EXPRESSION DES BESOINS Date : 18/11/2015 MISE EN ŒUVRE D UN OUTIL DE GESTION DE PROJET: Expression des besoins Page : 1/8 SOMMAIRE I. Contexte... 3 II. Rappels de l'existant...

Plus en détail

Urbanisation de Système d'information

Urbanisation de Système d'information Urbanisation de Système d'information L'approche Togaf 2008 The Open Group 1 TOGAF : The Open Group Framework Architecture «The Open Group Architecture Framework, également connu sous l'acronyme Togaf,

Plus en détail

Projet «RENNES FESTIVAL» Plan d action

Projet «RENNES FESTIVAL» Plan d action Projet «RENNES FESTIVAL» Plan d action Manal Afif Patrick Douchement David Laisné Elodie Lecoq Florent Martin Nicolas Poulain Mickaël Theraud V1.0 Date : 01/02/2013 1/34 GESTION DU DOCUMENT SUIVI DES VERSIONS

Plus en détail

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

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

Plus en détail

Banque Accord redonne de l agilité à son système d information avec l aide de MEGA

Banque Accord redonne de l agilité à son système d information avec l aide de MEGA redonne de l agilité à son système d information avec l aide de MEGA À propos de Banque Accord : Filiale financière du groupe Auchan Seule banque française détenue à 100% par un distributeur 3 activités

Plus en détail

PARTIE I : ÉCRIRE POUR APPRENDRE

PARTIE I : ÉCRIRE POUR APPRENDRE Table des matières Introduction! L écriture à travers le curriculum! Motiver les élèves à écrire! Le processus d écriture! L enseignement de l écriture! Comment utiliser cet ouvrage! Déterminer les objectifs

Plus en détail

Valoriser vos bases de connaissances avec AMI Help Desk. AMI Enterprise Discovery version 3.9

Valoriser vos bases de connaissances avec AMI Help Desk. AMI Enterprise Discovery version 3.9 Valoriser vos bases de connaissances avec AMI Help Desk AMI Enterprise Discovery version 3.9 Février 2005 Sommaire 1 Objectifs d AMI Help Desk...3 2 Principes de fonctionnement...3 2.1 Mode de travail

Plus en détail

Rédaction de cas d utilisation (Use Case)

Rédaction de cas d utilisation (Use Case) labsticc.univ-brest.fr/pages_perso/babau/ Rédaction de cas d utilisation (Use Case) Jean-Philippe Babau Département Informatique, UFR Sciences, Laboratoire Lab-STICC 2 1 Plan Objectif des Cas d Utilisation

Plus en détail

- Couches - Éléments - Domaines - ArchiMate et les techniques du BABOK

- Couches - Éléments - Domaines - ArchiMate et les techniques du BABOK ArchiMate et l architecture d entreprise Par Julien Allaire Ordre du jour Présentation du langage ArchiMate - Couches - Éléments - Domaines - ArchiMate et les techniques du BABOK Présentation du modèle

Plus en détail

[2016][AA1] Consignes

[2016][AA1] Consignes [2016][AA1] Consignes Consignes pour le bilan architecture d'août 2014 {EPITECH.} 2016_AA1_Consignes.docx Description du document Titre [2016][AA1] Consignes Date 07/12/2014 Auteur Responsable E-Mail Julien

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

Visual Paradigm Contraintes inter-associations

Visual Paradigm Contraintes inter-associations Visual Paradigm Contraintes inter-associations Travail de Bachelor d'informaticien de gestion Partie C Présentation de Visual Paradigm 1 Présentation de Visual Paradigm For UML L objet du travail de Bachelor

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

Projet : Plan Assurance Qualité

Projet : Plan Assurance Qualité Projet : Document : Plan Assurance Qualité 2UP_ARCHI_DEV1 VERSION 1.00 Objet Ce document a pour objectif de définir la démarche TOW TRACK UNIFIED PROCESS. Auteur Eric PAPET Vérifié par: Dominique MASSON

Plus en détail

Travaux soutenus par l ANR. Jean-François CAPURON (DGA) Bruno LEGEARD (Smartesting)

Travaux soutenus par l ANR. Jean-François CAPURON (DGA) Bruno LEGEARD (Smartesting) Travaux soutenus par l ANR Jean-François CAPURON (DGA) Bruno LEGEARD (Smartesting) 03 Avril 2012 1. Test de sécurité et génération de tests à partir de modèle 2. Le projet SecurTest à DGA Maîtrise de l

Plus en détail

Management par les processus Les facteurs clés de succès. Lionel Di Maggio Master 1 MIAGE

Management par les processus Les facteurs clés de succès. Lionel Di Maggio Master 1 MIAGE Management par les processus Les facteurs clés de succès Lionel Di Maggio Master 1 MIAGE 1 1. Objectifs et définitions 2. Le retour sur investissement des démarches 3. Les éléments structurants 4. Mise

Plus en détail

Projets informatiques S'approprier le Guide PMBOK pour réussir sa gestion de projet

Projets informatiques S'approprier le Guide PMBOK pour réussir sa gestion de projet Avant-propos 1. Introduction 13 2. Objectifs 14 3. Réserves 15 4. Contenu du livre 15 Concepts et définitions 1. Qu'est-ce qu'un projet? 17 1.1 Définition 17 1.2 Quelques exemples 18 2. Qu'est-ce qu'un

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

Gouvernance SharePoint

Gouvernance SharePoint Gouvernance SharePoint Club SharePoint France Erol GIRAUDY Benoit HAMET 2010 Quest Software, Inc. tous droits reserves. Agenda Présentation du Club SharePoint Qu est que la gouvernance? La gouvernance

Plus en détail

Approche organisationnelle basée sur le paradigme agent pour la synthèse & la réutilisation des connaissances en ingénierie collaborative

Approche organisationnelle basée sur le paradigme agent pour la synthèse & la réutilisation des connaissances en ingénierie collaborative Approche organisationnelle basée sur le paradigme agent pour la synthèse & la réutilisation des connaissances en ingénierie collaborative Hind Darwich, doctorante en thèse CIFRE au sein de la société TDC

Plus en détail

Système d Information du CNRST - SIC -

Système d Information du CNRST - SIC - 1 Contre National pour la Recherche Scientifique et Technique Système d Information du CNRST - SIC - Nabil Talhaoui Service système d information talhaoui@cnrst.ma 2 Plan Introduction Projet SIC : Contexte

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

ITIL. optimal. pour un service informatique. 2 e édition C H R I S T I A N D U M O N T. Préface de Patrick Abad

ITIL. optimal. pour un service informatique. 2 e édition C H R I S T I A N D U M O N T. Préface de Patrick Abad C H R I S T I A N D U M O N T Préface de Patrick Abad ITIL pour un service informatique optimal 2 e édition Groupe Eyrolles, 2006, 2007, ISBN : 978-2-212-12102-5 Introduction..................................................

Plus en détail

IFT2255 - Génie logiciel. Cycle de vie du logiciel. Activités de développement. Planification (étude préliminaire) Processus de développement

IFT2255 - Génie logiciel. Cycle de vie du logiciel. Activités de développement. Planification (étude préliminaire) Processus de développement IFT2255 - Génie logiciel Processus de développement Cycle de vie du logiciel Bruno Dufour dufour@iro.umontreal.ca Activités de développement 3 Planification (étude préliminaire) 4 Planification du projet

Plus en détail

Modélisation comportementale pour l ingénierie système

Modélisation comportementale pour l ingénierie système Modélisation comportementale pour l ingénierie système Contexte étude Système à spécifier L inverseur de source Objectif Capter et formaliser les besoins Produire les spécifications du système Valider

Plus en détail

--Séance 2 Analyse du problème et élicitation des exigences

--Séance 2 Analyse du problème et élicitation des exigences --Séance 2 Analyse du problème et élicitation des exigences Objectifs: Être en mesure de comprendre le processus d élicitation des exigences. Prendre conscience des défis de l élicitation. Comprendre le

Plus en détail

Testing : A Roadmap. Mary Jean Harrold. Présentation de Olivier Tissot

Testing : A Roadmap. Mary Jean Harrold. Présentation de Olivier Tissot Testing : A Roadmap Mary Jean Harrold Présentation de Olivier Tissot Testing : A Roadmap I. L auteur II. Introduction sur les test : les enjeux, la problématique III. Les tests : roadmap IV. Conclusion

Plus en détail

Processus et Outils S&OP

Processus et Outils S&OP Technical paper Processus et Outils S&OP 1. Processus et Outils S&OP 1.1 Vocabulaire S&OP désigne «Sales and Operations Planning» en anglais. L équivalent Français est le PIC «Plan Industriel et Commercial».

Plus en détail

MICHEL MAZEAU IPST/INP de Toulouse, EURESPACE, Toulouse, France

MICHEL MAZEAU IPST/INP de Toulouse, EURESPACE, Toulouse, France INTÉGRATION DU FACTEUR HUMAIN DANS LA CONDUITE ET LE DÉROULEMENT DE PROJETS SPATIAUX AUTIER THOMAS EURESPACE, Immeuble Thalès, 17 avenue Didier Daurat 31700 Blagnac, France. t.autier@eurespace.com TOMASINI

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

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

IFT2255 - Génie logiciel. Processus de développement

IFT2255 - Génie logiciel. Processus de développement IFT2255 - Génie logiciel Processus de développement 1 Cycle de vie du logiciel 2 Activités de développement 3 Planification du projet Analyse et spécification Conception Implémentation Vérification Installation

Plus en détail

NET@XIS OFFRE DE SERVICES OFFSHORE SAP

NET@XIS OFFRE DE SERVICES OFFSHORE SAP NET@XIS OFFRE DE SERVICES OFFSHORE SAP SOMMAIRE Introduction... 3 Scénarii & tendances...4 Offre de services Netaxis.8 Méthodologie... 9 Infrastructure Technique...11 Livrables...12 Management de Project...13

Plus en détail

Etude relative aux rapports des présidents sur les procédures de contrôle interne et de gestion des risques pour l exercice 2011

Etude relative aux rapports des présidents sur les procédures de contrôle interne et de gestion des risques pour l exercice 2011 Etude relative aux rapports des présidents sur les procédures de contrôle interne et de gestion des risques pour l exercice 2011 SOMMAIRE Synthèse et Conclusion... 1 Introduction... 4 1. La description

Plus en détail

<< Crédit Club Auto >>

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

Plus en détail

Act Tournai FICHE ECTS bachelier 3

Act Tournai FICHE ECTS bachelier 3 Code ECTS : A (Artistique) FICHE ECTS bachelier 3 Crédits ECTS : 20 ECTS = 10 + 10 ECTS (par quadrimestre) Enseignant responsable de l UF : Sébastien Verbièse Libellé du cours Libellé du cours (anglais)

Plus en détail

CARACTERISTIQUES DES TPE

CARACTERISTIQUES DES TPE Une démarche inscrite dans la durée... CARACTERISTIQUES DES TPE Les TPE fournissent aux élèves le temps de mener un véritable travail, en partie collectif, qui va de la conception à la production achevée.

Plus en détail

Cours 7: Conception des systèmes interactifs (partie 2)

Cours 7: Conception des systèmes interactifs (partie 2) Cours 7: Conception des systèmes interactifs (partie 2) Anastasia.Bezerianos@lri.fr (plusieurs slides sont basés sur des slides de T. Tsandilas, W. Mackay, M. Beaudouin Lafon, D. Vogel et S. Greenberg)

Plus en détail

Autres appellations du métier

Autres appellations du métier Le métier aujourd'hui Autres appellations du métier Chef de projet informatique Chef de projet fonctionnel Chef de projet maîtrise d œuvre Chef de projet maîtrise d ouvrage (ou AMOA) Description synthétique

Plus en détail

EPREUVE INTEGREE DE LA SECTION : BACHELIER EN INFORMATIQUE DE GESTION

EPREUVE INTEGREE DE LA SECTION : BACHELIER EN INFORMATIQUE DE GESTION MINISTERE DE LA COMMUNAUTE FRANCAISE ADMINISTRATION GENERALE DE L ENSEIGNEMENT ET DE LA RECHERCHE SCIENTIFIQUE ENSEIGNEMENT DE PROMOTION SOCIALE DE REGIME 1 DOSSIER PEDAGOGIQUE UNITE DE FORMATION EPREUVE

Plus en détail