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

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

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

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

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

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

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

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

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

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

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

Plus en détail

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

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

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

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

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

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

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

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

Unified Modeling Langage UML. Laurent Pérochon, 28-30 avril 2008, RMT Modelia, modélisation conceptuelle, formation UML, INRA Castanet Tolosan

Unified Modeling Langage UML. Laurent Pérochon, 28-30 avril 2008, RMT Modelia, modélisation conceptuelle, formation UML, INRA Castanet Tolosan Unified Modeling Langage UML Modèle musical Langage En avant la musique http://partitions.metronimo.com http://fr.wikipedia.org/ Méthode Créateur Outil En avant l informatique Modèle informatique public

Plus en détail

1. Mise en contexte. 2. Descripteur du cours. Cours : INF 727 Analyse des besoins en TI Trimestre : Hivers 2014 Enseignant : Michel Céré

1. Mise en contexte. 2. Descripteur du cours. Cours : INF 727 Analyse des besoins en TI Trimestre : Hivers 2014 Enseignant : Michel Céré Faculté des sciences Centre de formation en technologies de l information Cours : INF 727 Analyse des besoins en TI Trimestre : Hivers 2014 Enseignant : Michel Céré 1. Mise en contexte Les activités d

Plus en détail

Introduction. Règlement général des TPs - Rappel. Objectifs du cours. Génie logiciel. Génie logiciel

Introduction. Règlement général des TPs - Rappel. Objectifs du cours. Génie logiciel. Génie logiciel Introduction Génie logiciel Philippe Dugerdil Génie logiciel «The disciplined application of engineering, scientific and mathematical principles, methods and tools to the economical production of quality

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

Méthodologies de développement de logiciels de gestion

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

Plus en détail

[ Hornet ] Charte de méthodologie

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

Plus en détail

Gestion de la configuration et contrôle du code source

Gestion de la configuration et contrôle du code source MGL7460 Automne 2015 Gestion de la configuration et contrôle du code source Guy Tremblay Professeur Département d informatique UQAM http://www.labunix.uqam.ca/~tremblay 10 septembre 2015 Parmi les premières

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

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

GÉNIE LOGICIEL (SOFTWARE ENGINEERING)

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

Plus en détail

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

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

Plus en détail

Génie Logiciel et Gestion de Projets

Génie Logiciel et Gestion de Projets Génie Logiciel et Gestion de Projets INFO-F-407 Ragnhild Van Der Straeten 2008-2009 ULB 1 Génie Logiciel et Gestion de Projets Organisation 2 Ragnhild Van Der Straeten VUB, 4K209 Campus Etterbeek rvdstrae@vub.ac.be

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

Forthcoming Database

Forthcoming Database DISS.ETH NO. 15802 Forthcoming Database A Framework Approach for Data Visualization Applications A dissertation submitted to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZURICH for the degree of Doctor of

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

Concepts et langages du cadre RM-ODP de l'iso pour analyser et articuler les pratiques de projets libres de système de formation

Concepts et langages du cadre RM-ODP de l'iso pour analyser et articuler les pratiques de projets libres de système de formation Concepts et langages du cadre RM-ODP de l'iso pour analyser et articuler les pratiques de projets libres de système de formation Système de formation fédérant trois projets du logiciel libre (Moodle, OpenGLM

Plus en détail

Plans Architecturaux Le Modèle d Architecture Logicielle à «4+1» Vues

Plans Architecturaux Le Modèle d Architecture Logicielle à «4+1» Vues Traduit avec l'accord de l'ieee, à partir de la version originale en Anglais paru dans l'ieee Software, Volume 12 (6) pp 42-50, Novembre 1995 Plans Architecturaux Le Modèle d Architecture Logicielle à

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

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

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

Software Design Description

Software Design Description Software Design Description ABSTRACT: KEYWORDS: APPROVED: AUTHOR PROJECT MANAGER PRODUCT OWNER General information/recommendations A SDD provides a representation of a software system created to facilitate

Plus en détail

Systèmes d information dans les entreprises

Systèmes d information dans les entreprises Systèmes d information dans les entreprises Chargé: JF Couturier Cours # 4 MTI515 Automne 2013 JF Couturier 1 Retour sur les derniers cours Le document de vision Petit retour sur les diagrammes d activité

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

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

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

Plus en détail

Systèmes d information dans les entreprises

Systèmes d information dans les entreprises Systèmes d information dans les entreprises Chargé: JF Couturier Cours # 5 MTI515 Automne 2013 JF Couturier 1 Retour sur le dernier cours Le diagramme des cas d utilisation Les cas d utilisation Le SRS

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

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

Chapitre I : le langage UML et le processus unifié

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

Plus en détail

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

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

Plus en détail

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

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

É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

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

les Design Patterns 11/02/2013 labsticc.univ-brest.fr/pages_perso/babau/ Département Informatique, UFR Sciences, UBO Laboratoire Lab-STICC

les Design Patterns 11/02/2013 labsticc.univ-brest.fr/pages_perso/babau/ Département Informatique, UFR Sciences, UBO Laboratoire Lab-STICC labsticc.univ-brest.fr/pages_perso/babau/ les Design Patterns Jean-Philippe Babau Département Informatique, UFR Sciences, Laboratoire Lab-STICC 2 1 Plan Introduction aux Design patterns Quelques Design

Plus en détail

La prise en compte du contexte dans le développement d un système logiciel interactif : Apports de la Systémique et nouvelles perspectives

La prise en compte du contexte dans le développement d un système logiciel interactif : Apports de la Systémique et nouvelles perspectives La prise en compte du contexte dans le développement d un système logiciel interactif : Apports de la Systémique et nouvelles perspectives Françoise ADREIT Groupe de Recherche en Informatique et Mathématiques

Plus en détail

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

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

Plus en détail

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

Applications du processus unifié

Applications du processus unifié 2TUP : Two Tracks Unified Process Applications du processus unifié Processus proposé par Valtech (consulting) Ref. : UML2 en action Objectif prendre en compte les contraintes de changement continuel imposées

Plus en détail

Quick Start Guide This guide will help you install a base configuration of IBM Tivoli Key Lifecycle Manager.

Quick Start Guide This guide will help you install a base configuration of IBM Tivoli Key Lifecycle Manager. IBM Tivoli Key Lifecycle Manager Version 2.0.1 Quick Start Guide This guide will help you install a base configuration of IBM Tivoli Key Lifecycle Manager. National Language Version: To obtain the Quick

Plus en détail

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

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

Plus en détail

RAPID 3.34 - Prenez le contrôle sur vos données

RAPID 3.34 - Prenez le contrôle sur vos données RAPID 3.34 - Prenez le contrôle sur vos données Parmi les fonctions les plus demandées par nos utilisateurs, la navigation au clavier et la possibilité de disposer de champs supplémentaires arrivent aux

Plus en détail

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

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

Plus en détail

Le Rational Unified Process et Hermes

Le Rational Unified Process et Hermes Université de Fribourg, Suisse Département d informatique Systèmes d information 2010 Le Rational Unified Process et Hermes Description et comparaison. Cindy Zbinden Village 100, 1532 Fétigny cindy.zbinden@unifr.ch

Plus en détail

IFT2251 Introduction au génie logiciel Hiver 2006 (4 crédits) Prof. : Julie Vachon. Plan de cours

IFT2251 Introduction au génie logiciel Hiver 2006 (4 crédits) Prof. : Julie Vachon. Plan de cours IFT2251 Introduction au génie logiciel Hiver 2006 (4 crédits) Prof. : Julie Vachon ** Début des cours : le lundi 9 janvier 2006 ** Plan de cours 1. Introduction Les exigences et les attentes à l égard

Plus en détail

Modélisation Orientée Objet / UML

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

Plus en détail

Le projet de développement logiciel avec UML

Le projet de développement logiciel avec UML Le projet de développement logiciel avec UML Résumé de la formation UML UML UML UML UML UML UML UML 1 Plan Introduction Modélisation du métier Expression des exigences Conception PIM Conception PSM Conclusion

Plus en détail

Réinventons la Proximité! L Agilité au service des! Startup innovantes!

Réinventons la Proximité! L Agilité au service des! Startup innovantes! Réinventons la Proximité! L Agilité au service des! Startup innovantes! Thomas Van de Velde http://www.webinage.fr Florent Garin http://www.docdoku.com David Brocard http://davidbrocard.org I - Le contexte

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

AINoE. Rapport sur l audition d AINoE Paris, 18 juin 2003

AINoE. Rapport sur l audition d AINoE Paris, 18 juin 2003 AINoE Abstract Interpretation Network of Excellence Patrick COUSOT (ENS, Coordinator) Rapport sur l audition d AINoE Paris, 18 juin 2003 Thématique Rapport sur l audition d AINoE Paris, 18 juin 2003 1

Plus en détail

IFT2251 : Génie logiciel

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

Plus en détail

LISTE DES FORMATIONS. Mai 2015

LISTE DES FORMATIONS. Mai 2015 Gestion de projet Analyse d affaires Formation Évaluation de performance +1.514.826.5534 info@lcgsolution.com www.lcgsolution.com LCG Solution se distingue par la qualité du matériel de formation, la qualité

Plus en détail

IFT2251 Introduction au génie logiciel Plan de cours. 2. Description du cours et objectifs généraux

IFT2251 Introduction au génie logiciel Plan de cours. 2. Description du cours et objectifs généraux IFT2251 Introduction au génie logiciel Plan de cours Été 2008 Yann-Gaël Guéhéneuc 1. Introduction Les exigences et les attentes à l égard de la qualité logicielle sont de plus en plus grandes. La taille

Plus en détail

VISUAL PARADIGM. C. Présentation de Visual Paradigm For UML TRANSFORMATION DE MCD EN MLD ITÉRATIVE. Document version 1

VISUAL PARADIGM. C. Présentation de Visual Paradigm For UML TRANSFORMATION DE MCD EN MLD ITÉRATIVE. Document version 1 HEG Arc - Haute école Arc Gestion Travail de Bachelor d'informaticien de gestion VISUAL PARADIGM TRANSFORMATION DE MCD EN MLD ITÉRATIVE C. Document version 1 Créé le : 17.06.2012 Modifié le : 01.07.2012

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

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

Développement de logiciel

Développement de logiciel approche formelle et approche à objets Pascal ANDRE Université de Nantes Master Miage M1 Plan Introduction Développement formel du logiciel Développement du logiciel à objets Projection Développement du

Plus en détail

Niveau débutant/beginner Level

Niveau débutant/beginner Level LE COFFRE À OUTILS/THE ASSESSMENT TOOLKIT: Niveau débutant/beginner Level Sampler/Echantillon Instruments d évaluation formative en français langue seconde Formative Assessment Instruments for French as

Plus en détail

W4 - Workflow La base des applications agiles

W4 - Workflow La base des applications agiles W4 - Workflow La base des applications agiles, W4 philippe.betschart@w4global.com Vous avez dit «workflow»? Processus : Enchaînement ordonné de faits ou de phénomènes, répondant à un certain schéma et

Plus en détail

Processus de développement Objet : Best Practices

Processus de développement Objet : Best Practices 1/12 Processus de développement Objet : s SI LES NOUVELLES TECHNOLOGIES FONT BRILLER LES YEUX DES DEVELOPPEURS, LE CHEF DE PROJET SE TROUVE QUANT A LUI EN PROIE A DE NOMBREUSES INTERROGATIONS : MON PROCESSUS

Plus en détail

Formation continue BNF // Programme des cours 2015

Formation continue BNF // Programme des cours 2015 Formation continue BNF // Programme des cours 2015 Du 03 septembre 2015 Août Molecular Biology // Widely used methods in research laboratories Introduction and history / Principles, methods and applications

Plus en détail

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

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

Plus en détail

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

Yphise optimise en Coût Valeur Risque l informatique d entreprise

Yphise optimise en Coût Valeur Risque l informatique d entreprise Réussir le Service Management avec ISO 20000-1 Novembre 2007 Xavier Flez yphise@yphise.com Propriété Yphise 1 Introduction (1/2) Il existe une norme internationale sur le Service Management en plus d ITIL

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

Model-Based Testing dans l'industrie Usages et dissémination Bruno Legeard

Model-Based Testing dans l'industrie Usages et dissémination Bruno Legeard Model-Based Testing dans l'industrie Usages et dissémination Bruno Legeard Séminaire Test & Méthodes formelles LAAS-CNRS Toulouse 16 juin 2015 400 000 Testeurs certifiés 2 Les multiples facettes du MBT

Plus en détail

Business Process Design Max Pauron

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

Plus en détail

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

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

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

Plus en détail

Développement logiciel pour l Architecture Orientée Services avec IBM Rational Software Development Platform

Développement logiciel pour l Architecture Orientée Services avec IBM Rational Software Development Platform IBM Software Group Développement logiciel pour l Architecture Orientée Services avec IBM Rational Software Development Platform Thierry Bourrier, Techical Consultant thierry.bourrier@fr.ibm.com L Architecture

Plus en détail

Editing and managing Systems engineering processes at Snecma

Editing and managing Systems engineering processes at Snecma Editing and managing Systems engineering processes at Snecma Atego workshop 2014-04-03 Ce document et les informations qu il contient sont la propriété de Ils ne doivent pas être copiés ni communiqués

Plus en détail

REMOTE DATA ACQUISITION OF EMBEDDED SYSTEMS USING INTERNET TECHNOLOGIES: A ROLE-BASED GENERIC SYSTEM SPECIFICATION

REMOTE DATA ACQUISITION OF EMBEDDED SYSTEMS USING INTERNET TECHNOLOGIES: A ROLE-BASED GENERIC SYSTEM SPECIFICATION REMOTE DATA ACQUISITION OF EMBEDDED SYSTEMS USING INTERNET TECHNOLOGIES: A ROLE-BASED GENERIC SYSTEM SPECIFICATION THÈSE N O 2388 (2001) PRÉSENTÉE AU DÉPARTEMENT D'INFORMATIQUE ÉCOLE POLYTECHNIQUE FÉDÉRALE

Plus en détail

Cours Gestion de projet

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

Plus en détail

RÉSUMÉ DE THÈSE. L implantation des systèmes d'information (SI) organisationnels demeure une tâche difficile

RÉSUMÉ DE THÈSE. L implantation des systèmes d'information (SI) organisationnels demeure une tâche difficile RÉSUMÉ DE THÈSE L implantation des systèmes d'information (SI) organisationnels demeure une tâche difficile avec des estimations de deux projets sur trois peinent à donner un résultat satisfaisant (Nelson,

Plus en détail

Guide d exploitation User s manual. Adaptateur USB, USB Adapter

Guide d exploitation User s manual. Adaptateur USB, USB Adapter Guide d exploitation User s manual Adaptateur USB, USB Adapter 88 970 110 15000336 Bluetooth Adaptateur USB Bluetooth Page 2 Configuration matérielle 2 Configuration logicielle 3 Remarques 8 USB Bluetooth

Plus en détail

UML : Unified Modeling Language

UML : Unified Modeling Language UML : Unified Modeling Language Recommended: UML distilled A brief guide to the standard Object Modeling Language Addison Wesley based on Frank Maurer lecture, Univ. of Calgary in french : uml.free.fr/index.html

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

Experiences TCM QUALITY MARK. Project management Management systems ISO 9001 ISO 14001 ISO 22000

Experiences TCM QUALITY MARK. Project management Management systems ISO 9001 ISO 14001 ISO 22000 TCM QUALITY MARK Jean-Marc Bachelet Tocema Europe workshop 4 Project management Management systems ISO 9001 ISO 14001 ISO 22000 + lead auditors for certification bodies Experiences Private and state companies,

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

DOCUMENT DE SYNTHESE

DOCUMENT DE SYNTHESE E L A B O R A T I O N D U N P R O C E S S DE P I L O T A G E ET DE S U I V I Société d accueil : ELAN, MANAGEMENT DE PROJETS PFE présenté par : FOURREY Maxime Tuteur industriel : M. Julien DUBREUIL, Responsable

Plus en détail

Quatre axes au service de la performance et des mutations Four lines serve the performance and changes

Quatre axes au service de la performance et des mutations Four lines serve the performance and changes Le Centre d Innovation des Technologies sans Contact-EuraRFID (CITC EuraRFID) est un acteur clé en matière de l Internet des Objets et de l Intelligence Ambiante. C est un centre de ressources, d expérimentations

Plus en détail

MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE»

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

Plus en détail