Home

Concevoir des services collaboratifs adaptés à des - MAP-CRAI

1. lt lt interaction task gt gt file selection J 5 lt lt Input gt gt selectMultipleFiles lt lt perception task gt gt visualize clustering options r displayClustedingOptions H lt lt Output gt gt lt lt interaction task gt gt clustering mode selection J lt at gt gt EnFOpHON selectOneDocui seq Naming Process lt lt Action gt gt requestUpload Filps lt cActionss sendFiles Files lt lt action gt gt H r createZIP ZIP lt lt action gt gt createCRTIweBdocument document lt lt Action gt gt H creakeLinkDocumentZIP DocID Zip D Figure 117 Diagramme de s quence mod lisant le service ICT de t l chargement multi fichiers via l outil CRTI weB service m tier document 1 37 2 Int gration dans le cahier d exigences La derni re partie du cahier d exigences est dit e lors de l expression du point de vue fonctionnel par la mod lisation des services Cette phase est directement suivie par les premi res activit s de d veloppement et se r it re pendant celles ci En effet m me si le service a t sp cifi correctement il est courant que les d veloppeurs et les concepteurs doivent revoir certains d tails comme la gestion des cas d erreurs par exemple L ajout de remarques et commentaires sur les diagrammes de s quences permettra de rendre compte des sp cifici
2. Doc1 Standardiser le nommage des documents Doc2 D crire et localiser les modifications effectu es sur un document Doc3 Informer les personnes concern es d un d p t ou de la de la modification d un document Diffusion de documents Doc4 Transmettre et enregistrer les requ tes relatives chaque document Doc5 R agir concernant un document et tracer les r actions Doc6 Ma triser la visibilit des documents Doc7 Superviser et g rer l change des documents Ces bonnes pratiques sont exerc es par un ou plusieurs acteurs en fonction de leur r le la fois organisationnel et op rationnel Par exemple la r daction d un compte rendu est attribu e au coordinateur r le organisationnel qui est alors consid r comme seul diteur r le op rationnel Chapitre 2 Un cas de d veloppement d un outil de TCAO CRTI weB de ce type de documents alors que le partage de plans se fait par tous les concepteurs impliqu s dans la production plans 1 4 2 Caract risation des comptes rendus et autres documents La mod lisation du contexte de l activit collective dans un projet AIC a permis de d finir un certain nombre de concepts dont celui de documents L tude des besoins a montr que le compte rendu faisait l objet d une caract risation particuli re poss dant une structure propre consid rer dans la d finition d un service d di
3. Les concepts et la m thode de conception de services propos s He PARTIE 3 proposition Cas d tudes Exp rimentations Figure 77 Parties de la recherche support es par le contexte d tude Les besoins d adaptation des services pour le domaine AIC et par cons quent le besoin d une m thode de conception ont t identifi s dans la litt rature et par l observation de cas concrets d utilisation de services notamment ceux de l outil CRTI weB cf 1 5 En remettant en cause les services qui paraissent peu adapt s de par les retours des utilisateurs nous nous sommes servis de CRTI weB et de l analyse de projets de construction h berg s sur cette plateforme comme point de d part de notre tude A la lumi re des th ories analys es au cours de notre tat de l art sur les m thodes de conception logicielle nous avons d ploy notre propre m thode en l appliquant dans ce contexte sp cifique Les d veloppeurs sont actuellement responsables des ateliers de formation avec les utilisateurs de CRTI weB et recueillent galement leurs retours r guliers Au cours d changes avec eux nous avons relev deux enjeux majeurs faciliter le dialogue et viter les incompr hensions afin de lever le risque de d velopper des services couteux mais s av rant inadapt s garder en m moire les d cisions prises afin de tracer l volution du projet d veloppement La section su
4. SI Conception Orient e at Analyse Services focus sur le Supportent G nie Logiciel RUP agilit focus sur les m thodes de gt gt d veloppement p r IHM Conception E Peon Pare Centr e Utilisateurfusage Pe lyse focus sur l utilisabilit gt ed et l adaptabilit Figure 52 Repr sentation des approches de conception de services ICT dans l architecture de l entreprise La mod lisation des processus m tiers est largement adopt e par les concepteurs de syst mes d information dans le domaine de l entreprise et ce travers diff rents formalismes Pourtant elle semble comporter quelques limites quant la mod lisation de du contexte organisationnel d un projet AIC En effet le travail de chacun est compos dans un cadre alternant supervision directe et ajustement mutuel Kubicki 2006 parle de coordination flexible Or nous pensons la mani re de Marjanovic et al 2007 que la communaut BPM est rest e concentr e sur une coordination inflexible Devant ces pr occupations nous avons men une premi re r flexion sur le concept de pratique m tier Le chapitre suivant oriente notre tude vers le domaine du TCAO Nous d crivons ces outils en introduisant le concept de service collaboratif Nous consid rons ensuite les grands principes de conception de collecticiels et donc de services collaboratifs dits adapt s puis nous ad
5. Chapitre 9 La mod lisation des pratiques le point de vue organisationnel Tableau 22 El ments de caract risation de la PC11 Acteurs impliqu s Documents utilis s Activit s Maitre d ceuvre Posters Taches de coordination Maitre d ouvrage Articles Toutes phases Usagers R gles et normes Documents techniques 1 27 3 Enjeux dansl instrumentation des pratiques m tiers et approches de mod lisation Comme introduit pr c demment l objectif de cette tape de notre m thode est de concevoir des services supports aux activit s collectives de projet dans le domaine AIC Ce premier travail d analyse m tier sur les familles de pratiques nous permet d appr hender de mani re globale l activit de projet et de la diviser en sous ensembles compr hensibles Cependant pour mener une analyse m tier qui servira de base la conception de services collaboratifs adapt s il est n cessaire d aller au del de ces grands principes il nous faut pouvoir d crire finement les pratiques observ es en situation r elle de projet Dans notre approche nous distinguons deux types de pratiques les pratiques collectives relatives aux objectifs d un groupe d acteurs aux minimum deux acteurs collaborant les pratiques individuelles effectu es individuellement par chacun des acteurs de ce groupe pour atteindre l objectif identifi en commun Sur la base de l analyse des onze familles pr c dentes no
6. Family 5 Design and reporting Les concepteurs diffusent leur proposition aupr s des maitres d ouvrage qui l valuent gt Correspondances entre les mod les Is composed of LL Diffusion des documents produits Executes Uh des concepteurs expose les choix conceptuels de l quipe pour valiation A iB composed of Is composed of A l inform l Already supported by a service Targets i E Geometral A Group type Agency Plans du projet au stade APS Designer Author Designer lt Add here more specifites if needed gt Status In Progress Designer ae INFORM choose collaborators to inform lt lt include gt gt s Vo mem Ls Gen Is composed of linen Choose files and clustering mode Abstract user interaction type Selection 1_n Is composed of gt Is composed of Then new dowload activation name crti web document Q notification identification Concrate user interactin type Trigger Interact with Abstract user interaction type Input Graphical output I Then Fle selection So Name Documents iterat wih Concrete user interactin type Selection J Graphical spec Icon label progress bars checkbox o then s So Name Document name Attributes Name file type Ep zation Data type fie Graphical spec text fields and combo boxes Graphical output gt Attributes primitive data I bl tes Data type text Cl
7. le niveau intentionnel qui d crit les besoins et les buts pour en d duire les exigences du systeme le niveau organisationnel qui d crit l organisation mettre en place pour r pondre aux objectifs le niveau op rationnel qui d crit les solutions informatiques On retrouve au travers de ces trois niveaux non pas les phases du RUP mais plut t la caract risation des diff rentes activit s Aux niveaux intentionnel et op rationnel se d roulent les activit s de mod lisation du domaine d ing nierie des exigences et de d veloppement au travers des diff rents mod les pr sent s pr c demment Le changement de paradigme apparait au niveau organisationnel au cours des activit s d analyse et de conception l o les domaines du GL et des IHM d finissent des cas d utilisation et des t ches relatives un acteur l ing nierie des SI requiert la mod lisation des activit s de chacun des acteurs impliqu s dans des processus relatifs une organisation La section suivante pr sente les formalismes utilis s pour la mod lisation d une organisation et des processus Nous nous int ressons ensuite au d roulement de cette phase d analyse et conception 1 14 2 La mod lisation du m tier et des processus Nous avons d j parcouru un ensemble de mod les utilis s pour repr senter l architecture d un syst me dans les m thodes de GL et IHM Nous nous int resserons ici plus pa
8. Ajouter un document Ajouter un fichier Chargement d un ou plusieurs documents Pour importer un ou plusieurs fichiers cliquer sur Parcourir selectionner un ou plusieurs fichiers maximum 70 Mo Parcourir File name dwa_dds_400_dm_30 dwg dwg ipo de Save as type All Files dwg_dds_400_dm_30 dw 779 36KB e Copy of dwg_dds_400_ 779 36KB Liaison entre les documents Les documents sont ind pendants Les document sont li es Pr c dent Suiv Tous les documents Fichier unique O Nom STANDARD 13 rena TE a 1 IM_A_APS_AN_00_A_065_04 jpg G PL_A_APD_EG_00_1_001_01 zip F vrier 2013 o HHPL L PDE N1_MT_A_111_01 jpg Figure 119 Illustration de l utilisation du service ICT de t l chargement multi fichier une fois imol ment cf diagramme de s quences Figure 117 Chapitre 11 La mod lisation des services le point de vue fonctionnel 1 38 Conclusion Le m ta mod le des services caract rise la partie fonctionnelle qui servira de base au d veloppement partir des besoins identifi s en termes de pratiques et d usages cette troisi me phase de mod lisation sp cifie le service qui sera le plus adapt Les liens entre le m ta mod le de services et le m ta mod le d usages assurent l adaptation des services d velopp s par rapport aux attentes des concepteurs Le diagramme de s quence est un for
9. E E Tous les documents Fichier unique v Fichier zap NN r a H PL_A_APD_EG_00_1_001_01 zip F vrier 2013 a H PL_L_PDE_N1_MT_A_111_01 jpg Figure 128 Rappel le service d upload multiple d velopp 1 40 5 Conclusion Cette exp rimentation a permis de d rouler un processus entier de d veloppement de service informatique dans un cadre professionnel et sur la base de besoins identifi s avec des de vrais utilisateurs de la plateforme CRTI weB La collaboration entre notre quipe et les d veloppeurs s est effectu e autour de plusieurs r unions majeures d di es l analyse des besoins et aux choix conceptuels Les d veloppements qui ont suivi ont ainsi pu tre men s sans sp cifications suppl mentaires Chapitre 12 La m thode PUSH exp rimentations et bilan Evaluation de la pertinence Nos premiers entretiens avec l quipe de la soci t de services Kitry Consulting ont mis en avant la n cessit de maitriser les risques comme une pr occupation importante Les risques sont d finis comme la possibilit qu un projet ne soit pas ex cut conform ment aux pr visions de dates de co ts ou que le r sultat ne satisfasse pas les besoins exprim s Les utilisateurs de CRTI weB qui se projettent dans leur activit expriment des besoins tr s particuliers li s au contexte de collaboration dans lequel ils utilisent l outil type de projet quantit d
10. la colocalisation qui d termine s ils sont effectu s au m me endroit colocalis s ou distance On dira que la temporalit et la localisation de chaque usage d terminent la relation entre plusieurs usages Figure 100 Chapitre 10 La mod lisation des usages le point de vue op rationnel lt lt enumeration gt gt type_synchronisation synchrones asynchrones d termine d termine Localisation type_lieu num ration Figure 100 Caract risation de la relation entre usages Temporalit type_temporalit num ration se d roule se d roule 1 32 4 Conclusion le m ta mod le d usage MMU L association des m ta mod les que nous venons de d finir compose le m ta mod le d usage MMU Figure 101 Le MMU est li au m ta mod le de pratiques m tiers MMPM par les diff rentes relations que nous avons galement d finies Conceptuellement nous caract risons ainsi la m diatisation des pratiques par les usages Comme le montre la section suivante l instanciation de ce m ta mod le se fait en plusieurs temps et travers plusieurs formalismes Chapitre 10 La mod lisation des usages le point de vue op rationnel Pratique colllective Nom texte Type_famille num ration Description texte Nom texte Description texte Pratique Individuelle Relation entre usages
11. la priorit la collaboration avec les clients plus qu la n gociation contractuelle avec eux impliquant ceux ci tout le long du cycle de d veloppement afin d assurer la prise en compte continue de leurs exigences et plus uniquement au d but du projet pour la d finition du contrat la priorit l adaptation au changement plus qu au suivi d un plan autorisant l volution du processus Ressources humaines et communication Applications fonctionnelles Planification rigide Collaboration as N gociation de troite avecle Conrat client Accueil du Documentation changement Processus et outils Figure 27 Valeurs des m thodes agiles face aux concepts des m thodes classiques 13 http www agilemanifesto org iso fr Chapitre 4 De l utilisateur la conception logicielle et d interfaces Plusieurs m thodes int grent ces notions a leur mani re deux d entre elles sont d crites dans la section qui suit XP et SCRUM La m thode extreme programming XP Parmi les m thodes de d veloppement agile l XP Beck 2006 pousse l extr me les bonnes pratiques de d veloppement classique Cette m thode pr conise des cycles de d veloppement tr s courts de 2 3 semaines bas s sur des user stories fournis par le client Alors que le use case d crit l utilisation du syst me de mani re g n rale et formalise de fa on permanente l accord entre le cli
12. Figure 120 Repr sentation conceptuelle du lien entre les points de vue Chacun des concepts pratique usage et service est d crit par son propre m ta mod le le MMPM le MMU et le MMS Les liens conceptuels m diatise et mat rialise Figure 120 sont d finis par plusieurs correspondances entre ces trois m ta mod les et forment le M ta Mod le des Services Adapt s MMSA cf Figure 115 page 197 Ces correspondances sont identifiables graphiquement lors de l instanciation du MMSA par l adaptation des formalismes utilis s Figure 121 Ces formalismes sont le diagramme hi rarchique pour le mod le de pratiques le diagramme de cas d utilisation puis l arbre de t ches pour mod liser l usage et enfin les diagrammes de s quences pour le service Les transformations sont les suivantes Chapitre 12 La m thode PUSH exp rimentations et bilan L acteur de la pratique diagramme de pratiques devient utilisateur du syst me diagramme de cas d utilisation Une op ration m tier diagramme de pratiques devient un ensemble d intentions utilisateurs package de cas d utilisation dans le diagramme Une intention utilisateur diagramme de cas d utilisation devient la racine d un arbre de t ches utilisateurs diagramme d interactions Les t ches outils identiques dans le diagramme de cas d utilisation et le diagramme d interactions sont d compos es en actions des composa
13. MO Figure 39 Espaces techniques de l IDM et niveaux de mod lisation Parmi les Espace Techniques de l IDM nous nous int resserons particuli rement la MDA qui s applique au d veloppement de syst mes informatiques 1 11 2 L architecture dirig e par les mod les L architecture dirig e par les mod les MDA pour Model Driven Architecture est un standard industriel qui consiste structurer la conception en mod lisant le besoin m tier ind pendamment de toute plateforme technique puis de transformer ce mod le en une architecture technique qui pourra voluer Cette approche est issue du constat que le m tier volue moins vite que la technique et que l on doit pouvoir changer de plateforme technique ou en utiliser plusieurs pour un contexte m tier qui lui ne change pas ou peu Le processus de d veloppement se fait travers quatre mod les UML chacun tant propos par un acteur diff rent Brown et al 2005 Favre amp Pereira 2007 le CIM Computation Independant Model c est le mod le du domaine qui d crit l environnement d utilisation du syst me et fait notamment ressortir les contraintes et les exigences le PIM Plateform Independant Model d crit l architecture du syst me en repr sentant le processus d utilisation et les donn es manipul es le PSM Plateform Specific Model est cr pour impl menter la solution C est en fait un ensemble de mod les le pre
14. 1 29 2 L diteur et les mod les g n r s La Figure 92 illustre un exemple de mod le de pratique tel que nous l avons con u accompagn de la palette de l diteur utilis pour le d crire Le cas choisi est le m me que pr c demment il concerne une pratique collective d change de plans pour leur expertise Le mod le se focalise cependant sur la PI du concepteur Cela permet comme nonc pr c demment de g n rer un mod le relativement simple et facile lire rapidement Comme nous pouvons le voir ce mod le repr sente couche apr s couche la PC consid r e d finie par son nom sa famille une description acteur type auquel on s int resse d crit par son r le sa d nomination son m tier ainsi que la PI de cet acteur d finie par un nom et une description les op rations pour lesquelles on renseigne le type et le besoin de service et enfin un artefact d fini par un type une d nomination un auteur un tat manipul ainsi que le groupe d acteurs concern nature du groupe r le sp cificit 3 Palette N Q D Practices defintion CP validation des choix conceptuels Os Practice Family 5 Design and reporting Les concepteurs diffusent leur proposition aupr s des maitres d ouvrage qui l valuent Indvidual Practice 2 CO ASS Is composed of Operations definition B Communication Designer IP oiffusion des documents produits Production
15. pasword crti web URL is number i lt lt action gt gt y i lt lt output gt gt RE sees Laisse neesoben lacs ses Ah ET 5 validateData DORE fee dee o PR EEEE EEEE 6 validateData 3 7 nalfyOfComedon H lt lt action gt gt lt lt abstract ass k gt gt copy files in shared Folder lt lt Input gt gt 8 addDocume ht Document ee eee lt lt action gt gt r i 9 identifyNewDocument i lt lt action gt gt i A 10 requestUploadDocument Docyment lt lt action gt gt 11 fendDocument Document e AEEA ARETE Rion a ee lt lt action gt gt 12 createDacument Documeht a lt lt action gt gt H tO 13tuploadSucess H lt lt action gt gt i Le EE T A R lt lt output gt gt i 14 uploadSucess 15 notifyOfUpload Figure 134 Partie du diagramme de s quence sp cifiant le service Au fil des it rations nous avons pu d tailler les exigences comme par exemple la sp cification d un message de notification pour avertir du d marrage de l application apr s la phase identification La figure suivante Figure 135 illustre le service d velopp et la fa on dont il r pond aux exigences ici repr sent es par une version simplifi e du diagramme d interactions Chapitre 12 La m thode PUSH exp rimentations et bilan lt lt lt Input gt gt deatificationD4ta ID password folder rti web url project
16. 391 Modifier ergonomie de l ajout de PDFs NIL Meilleure ergonomie r cup rer les notes introduites dans le Partie du document 398 pr c dent CR Contenu r cup r e par le Gain de temps 403 __ IIl manque les ic nes d action pour Compte D tail graphique Ajouter la date de la mise jour de l indice Mettre jour un a Identifier les dates de Meilleure compr hension gain de 435 pour plus de visibilit i document de travail Contenu MaJ temps 436 Modifier l image par d faut des projets ne NIL D tail graphique Consulter les documents Contenu Utilisation de Adaptation l utilisation d un 440 Int gration avec AutoCAD WS i partag s Contexte l explorateur web pour terminal mobile PROMOBE Cr er des templates de T che Sauvegader des CN 444 convention de nommage Contenu types Gain de temps PROMOBE Cr ation du r le Administrateur Plusieurs pratiques de Nouveau role 445 projet gestion men es par un Contexte op rationnel nouveau type d utilisateur PROMOBE Ajout de nouveaux organismes disponible uniquement dans la gestion T che Ajout d organismes 447 __ d un projet pas possible dans la partie Contenu lane Modification d une fonctionnalit PROMOBE Possibilit d diter les Attribution d une fonctionnalit 448 informations des organismes cr s gestion men es par un T che limit un utilisateur un type d utilisateur PROMOBE Suppression des organismes Plusieurs pratiques de ne Supp
17. Dubois E et al 2009 Towards a Sustainable Services Innovation in the Construction Sector Advanced Information Systems Engineering pp 3 19 333 Kubicki S Guerriero A amp Johannsen L 2009 A service based innovation process for improving cooperative practices in AEC Tcon Electronic Journal of Information Technology in Construction XX January pp 1 21 Kurtev I B zivin J amp Aksit M 2002 Technological spaces An initial appraisal p 6 Kuutti K 1996 Activity theory as a potential framework for human computer interaction research Context and consciousness Activity theory and human computer interaction pp 9 22 Bibliographie Kvan T 2000 Collaborative design what is it Automation in Construction 9 4 pp 409 415 Laaroussi A 2007 Assister la conduite de la conception en architecture vers un syst me d information orient pilotage des processus Institut National Polytechnique de Lorraine Lamsweerde A Van 2001 Goal oriented requirements engineering A guided tour Requirements Engineering 2001 Lamsweerde A Van 2003 Goal oriented requirements engineering From system objectives to UML models to precise software specifications Conference on Software Engineering May pp 1 81 Lapouchnian A 2005 Goal oriented requirements engineering An overview of the current research Laurillau Y 2002 Conception et r alisation logicielles pour les collecticiels centr
18. Fielding R 2000 Architectural styles and the design of network based software architectures University of California Irvine Frankel D et al 2003 The Zachman Framework and the OMG s Model Driven Architecture Business Process pp 1 14 Bibliographie Front A Rieu D amp Giraudin J P 2009 Une vision sur les probl matiques actuelles de la recherche en Syst mes d Information sigma imag fr p 27 Gabay J amp Gabay D 2008 UML 2 Analyse et conception Mise en oeuvre guid e avec tudes de cas Paris Dunod Gifford B amp Enyedy N 1999 Activity centered design Towards a theoretical framework for CSCL In Proceedings of the 1999 conference on Computer support for collaborative learning Giraldo W Molina A amp Collazos C 2008 A Model Based Approach for GUI development in groupware systems In R Briggs ed CRIWG Springer Verlag Berlin Heidelberg 2008 pp 324 339 Godart C et al 2001 Implicit or explicit coordination of virtual teams in building design In Computer Aided Architectural Design Research In Asia CAADRIA 01 Gordijn J Akkermans H amp Van Vliet H 2000 Business modelling is not process modelling Conceptual Modeling for E Business and the Web pp 40 51 Gottschalk K Graham S amp Kreger H 2002 Introduction to web services architecture BM systems 41 2 Greenberg S 1991 Personalizable groupware Accommodating individual roles and grou
19. L incertitude du processus d cisionnel dans un projet AIC conduit les acteurs devoir s adapter tout instant tout en tant peu dans une logique de planification c est un processus dit ad hoc Kubicki 2006 L action est en effet troitement li e son contexte social et physique plus qu a une directive strat gique g n rale Suchman 1987 introduit le concept d action situ e On peut galement lire dans Hanser 2003 qu un projet architectural n est jamais monotone car chaque nouveau projet correspond un contexte particulier il serait donc illusoire de tenter de d gager un processus pr cis et reproductible d un projet un autre Tout comme le font Sierhuis amp Clancey 2002 ou Soulier amp Lewkowicz 2006 nous pr f rons parler de pratiques En effet le terme pratique est synonyme de m thode de mani re de faire mais aussi d accomplissement on parle de pratique ing nieuse ou de bonne pratique La pratique se r f re galement une exp rience une habitude et une am lioration continue cf acqu rir de la pratique On conf re alors au concept de pratique une certaine souplesse qui favorise l am lioration Dans la caract risation des besoins m tiers relatifs au projet AIC nous adoptons donc le concept de pratique m tier plut t que celui de processus pour caract riser l activit collective et individuelle Chapitre 5 De l
20. Pour pallier ces limites dans la compr hension des processus m tiers nous nous orientons vers un nouveau d coupage des processus de projet AIC d abord assez g n rique puis en op rant plusieurs raffinements afin d appr hender les sp cificit s et variabilit s du processus de chaque projet Nous cherchons alors exprimer des objectifs pr cis relatifs des acteurs particuliers et pouvant varier d un projet un autre exprimer des flux d information qui concernent plusieurs phases voire qui peuvent tre interrompus et repris au cours du projet Dans notre tude et pour cette dimension m tier nous adoptons le terme de pratique Nous essayons travers ce concept de pratique de prendre de la distance par rapport aux descriptions de processus trop fig s cherchant d crire le caract re par nature flexible de l activit de projet AIC Nous retrouvons d ailleurs ce concept dans plusieurs tudes que nous voquons ci dessous Pratique d finition Nous avons introduit ce concept en quelques lignes dans le chapitre 3 de ce m moire La pratique peut tre litt ralement d finie comme l exercice d un m tier une mani re de travailler un comportement habituel avec une finalit En d autres termes c est un comportement adopt par une plusieurs personnes dans le but d atteindre un objectif m tier D apr s Schmidt amp Wagner 2004 le travail coop ratif dans un pro
21. Rechercher Look for Obtenir Get Consulter Consult Identifier Identify V rifier Verify Les artefacts artifacts l ments produits utilis s r f r s lors d une op ration sont de type Document Document g om tral geometral mod le model perspective perspective photos Object photos rapport report exigences requirements sp cifications specifications req Sp sp ou agenda planning to do Objet object b timent building lot plot tage level pi ce room l ment de QB Sa of artifacts sue construction element r servation reservation mat riau material chantillon de mat riau material sample v hicule vehicle d faut defect Message Information R action Reaction Notification Requ te request Validation Groupe d artefacts group of artifacts Les artefacts sont galement d finit par Une description plus sp cifique Un statut status en cours ongoing final valider to validate valid valid ex cuter to execute ex cut executed modifier to modify Un auteur author d fini par son r le role Un acteur actor peut tre responsable d une pratique individuelle ou simplement impliqu c est dire concern par l op ration d un autre acteur Dans tout les cas il est d finit par Un r le organisationnel organizational role Concepteur designer Ma tre d
22. Remerciements Cette th se est le fruit de l engagement et la confiance de plusieurs personnes et instituts sans lesquels un jeune architecte fra chement dipl m n aurait pu mener un tel projet Je tiens leur adresser toute ma gratitude Je dois tr s probablement les fondations de ce projet M Sylvain Kubicki qui a su piquer ma curiosit et veiller mon int r t pour la recherche alors m me que j effectuais mon stage de Master 2 C est gr ce sa motivation que j ai eu la volont et la possibilit d entreprendre ce parcours qu il a galement su encadrer avec s rieux mais aussi sympathie Je dois galement le bon d roulement de cette tude M Gilles Halin directeur de ce travail de th se et cl de voute de cette structure multidisciplinaire entre architecture et informatique Je lui suis reconnaissant pour sa p dagogie la pertinence de ses propos son s rieux et sa bonne humeur tout au long de la direction de mes travaux Je suis heureux d avoir pu b n ficier du contexte professionnel offert par le CRP Henri Tudor et le CRAI Je remercie ric Dubois directeur du d partement SSI S verine Mignon coach de l unit SISE et Fabrice Absil manageur du programme construction pour leur confiance et leur soutien Je remercie galement Jean Claude Bignon professeur l cole d architecture de Nancy et directeur de recherche au CRAI pour ses conseils avis s Je remercie tout particuli
23. des usages distance R partition temporelle Usages Usages asynchrones dans asynchrones a un m me lieu distance Usages Usages synchrones dans synchrones a un m me lieu distance R partition spatiale Figure 54 R partition des types d usages dans le mod le spatio temporel 1 16 2 Les types de services collaboratifs R partis dans les trois espaces fonctionnels et les quatre espaces spatio temporels les collecticiels offrent un certain nombre de ces services collaboratifs utilis s diff rents moments de la collaboration Laurillau 2002 Dewan 2001 Gerosa amp Pimentel 2006 tels que les services de gestion de l emploi du temps les services de partage et contr le de l information qui permettent de g rer l acc s des utilisateurs l information partag e cela implique la consultation mais aussi la modification par un groupe comme la comparaison et la fusion des ditions annulation les services de gestion d interface qui permettent de propager les l ments graphiques entre les utilisateurs de mani re synchrone tout le monde voit la m me chose ou de mani re r partie chacun a sa propre visualisation Chapitre 6 Travail Collaboratif Assist par Ordinateur et Services Collaboratifs les services de notification qui informent les diff rents utilisateurs des changements d tat du systeme les services de courrier lectronique de tchat de f
24. du terrain et notamment les acc s possibles et les diff rents r seaux d alimentation et d vacuation Tableau 12 l ments de caract risation de la PCI Documents utilis s Activit s Acteurs impliqu s Ma tre d ouvrage Ma tre d uvre Ing nieurs g ologues Administration commune Plans APS Plan Local d Urbanisme Rapports d tudes T ches d expertise et coordination Phase Montage tudes pr alables Phase Conception APS PC2 choix de la ma trise d uvre Description le maitre d ouvrage engage la Ma trise d ceuvre qui devra concevoir l ouvrage Dans le cas de projets de grande envergure la consultation passe par les phases d un appel d offres appel public dossier de consultation clauses de l engagement du CCAP CCTP crit res de choix sur les comp tences choix et notifications des march s Chaque titulaire de march renseignera les buts et performances atteindre les techniques de base utiliser les moyens en personnel et mat riel mettre en uvre le niveau du prix des prestations un d coupage en phase Le ma tre d ouvrage peut ainsi valuer leur capacit mener bien son projet dans des conditions et avec des performances optimales Tableau 13 l ments de caract risation de la PC2 Acteurs impliqu s Documents utilis s Activit s Maitre d ouvrage Maitre d ceuvre Dossier de consultation Plans APS
25. gt Is composed of create update crti web document System task type Data 15 composed of A Copy files in shared folder gt Is composed of Abstract user interaction type Navigation Modify files in shared folder Rename files in shared folder Abstract user interaction type Command Abstract user interaction type Input mera with itaat wh Interact with 10 Name File 10 Name CRTI weB document Graphical spec Icon according to the fle type name Graphical spec ine in documents list Attributes location narne fle type Is composed of Attributes name author date zone actions reactions file Data type docurnent Data type document Properties Properties Figure 133 Diagrammes d interaction pour les intentions s identifie et partage les fichiers depuis un dossier partag 1 41 3 Sp cifications techniques et d veloppements Une application nomm e CRTI box compos e d une interface JAVA et d un daemon logiciel permettant de surveiller les flux de fichiers dans un dossier a t d velopp e pour impl menter le service con u Celle ci sert de passerelle entre les services web et l utilisateur ainsi que le dossier partag Elle devra tre param tr e la premi re fois pour effectuer les t ches d identification premier package puis participera en t che de fond l ex cution des t ches suivantes Le diagramme de s quence suivant illust
26. ression indicator contextual cursor On distingue ces niveaux d abstraction dans les diff rentes m thodes de mod lisation Les paragraphes suivants illustrent comment le sc nario et le use case utilis s dans les activit s de d veloppement logiciel peuvent supporter la caract risation des interactions avec plusieurs niveaux d abstraction Nous y pr sentons ensuite un type de mod lisation sp cifique et plus adapt les arbres de t ches Enfin nous montrons comment illustrer une interface travers des maquettages ici aussi de fa on concr te ou abstraite Les mod lisations du GL La mod lisation par sc nario que nous avons introduite avec l activit d ing nierie des exigences voir 4 1 2 est utilis dans les approches CCU CCA et CDB pour d crire le comportement d un persona D apr s Cohn 2003 il se veut plus pr cis qu une user story Comme on peut le voir dans l exemple ci dessous inspir de l exemple de Cohn 2003 un sc nario peut d crire litt ralement des intentions veut y planifier un voyage des t ches abstraites acc de a notre site des t ches d interaction click saisit et des repr sentations visuelles un formulaire de saisie Amy est int ress e par la culture japonaise et veut y planifier un voyage Elle acc de notre site internet et click sur le lien Hotels Un formulaire de saisie appara t Elle saisit Nagoya comme ville de
27. type_synchronisation type_colocalisation Usage Objectif texte Dispositif Type_dispositif num ration Type_OS num ration Type_connexion oui non Type_contr leur num ration Type_entr e _vid o oui non inconnu Type_entr e _audio oui non inconnu Type_sortie _vid o oui nonjinconnu Type_sortie _audio oui non inconnu Application Type_application num ration Technologie texte 1 1 Outil 1 A nom texte execute utilise 1 1 T che outil i 1 diatise Utilisateur 1 Lx Type_r le_op texte 7 Identification oui non T che 1 1 A Nom i execute Type_t che T che utilisateur concr te 1 Intention utilisateur 1 nom T che utilisateur abstraite 1 Le 0 Op ration supporte 1 i represent Type_op ration ncerne Type_support concerne 1 0 Lt GE 0 oa Artefact Acteur l x cute cancerne Type_artefact num ration D nomination texte Type_acteur num ration Type_auteur lt type_rdle gt Type_r le num ration 0 Type_statut num ration D nomination texte x EE int fagit avec a Activit 4 Type_activit num ration repr sente repr sent repr seni 0 Lg Objet d interaction Nom donn e texte Type_donn e num ration o gt Attributs texte Forme texte Figure 101 Repr sentation s
28. un label Le Maitre d ouvrage doit tre inform du d roulement et des r sultats de chaque intervention Tableau 21 l ments de caract risation de la PC10 Acteurs impliqu s Documents utilis s Activit s Ma tre d ceuvre Coordinateur Plans d ex cution Documents techniques T ches de construction d valuation et de A coordination Ma tre d ouvrage R f rentiels normes CR d expertise CR de chantier Phase construction pendant le chantier et avant la livraison Entreprises Experts PC11 implication des usagers Description L implication des usagers n est pas syst matique surtout lorsqu ils ne sont pas directement les ma tres de l ouvrage Le cas le plus typique est l ajustement de certaines d cisions de conception ou d am nagement pi ces mobilier quipements notamment dans des op rations de construction grande chelle lotissement logement collectif En ce qui concerne les b timents publics l implication des futurs usagers durant le projet consiste essentiellement la communication d informations Une fois le b timent con u et au regard des pr occupations environnementales son usage doit tre encadr par un ensemble de bonnes pratiques qui doivent tre transmises aux usagers r duction de la consommation d nergie gestion des d chets logique dans l utilisation des quipements de chauffage ventilation
29. utilisateur et l outil la relation se d roule entre l usage et la temporalit ainsi qu entre l usage et la localisation Chapitre 10 La mod lisation des usages le point de vue op rationnel lt lt enumeration gt gt type_lieu sur le chantier au domicile chez le client dans un endroit public autrejinconnu type_lieu num ration Acteur Type_acteur num ration Type_r le num ration D nomination texte lt enumeration gt gt Temporalit Type_temporalit plusieurs fois par jour tout les jours tout les 2 3 jours type_temporalit num ration repr sente une fois par semaine une Fois par mois moins d une fois par moins apr s chaque r union autrefinconnu utilise lt lt enumeration gt gt Type_dispositif tablette Type_dispositif num ration Type_application num ration smartphone Type_OS num ration autre Type_connexion oui non Type_contrdleur num ration Type_entr e _ vid o oui nonfinconnu Type_entr e _audio oui non inconnu Type_sortie _vid o oui nonfinconnu lt lt enumeration gt gt Type_sortie _audio oui nonjinconnu TYpe_0S oo Windows MacOS Linux WindowsPhone 05 Android autre clavier souris clavier touchpad cran tactile autrefinconnu Figure 99 Caract risation du contexte d usage On attribue un utilisateur un r le op ration
30. Birnbaum 2004 Selon O Farrell 1991 un service est valu par 1 sa qualit d finie par la proportion dans laquelle il r pond aux attentes du client et 2 son utilit qui est justifi e par l impact positif qu aura ce service sur l activit du client Notons que ces deux caract ristiques sont ind pendantes En effet de m me que l ex cution parfaite d un bien n implique pas de mani re vidente qu on en ait besoin la qualit d un service on parlera de QoS pour Quality of Service n est pas non plus synonyme d utilit ex un soin prodigu sur une personne saine reste inutile m me si r alis la perfection Dans la pratique on retrouve la notion service dans plusieurs sciences comme la business science l information science ou la computer science Baida et al 2004 Dans la business science on parle de service comme nous venons de le d finir savoir comme d une activit m tier qui donne lieu des r sultats intangibles et ou des b n fices Le terme e service repr sente un service fourni par le biais d internet Dans la computer science le terme service d crit une fonctionnalit d une application d un logiciel le web service est une fonctionnalit accessible via internet Dans l information science on retrouve les termes relatifs aux deux autres sciences le service dit informatique la fonctionnal
31. Description du service Registre de services Trouver Publier Client du MK i service Joindre et du service Description du invoquer service Figure 46 R les et interactions dans une SOA tir de Endrei2004 L approche de d veloppement bas e sur les services a t guid e par la volont de structurer d velopper et d ployer les logiciels de mani re plus flexible tout en r duisant les co ts et la dur e En 2000 Bennett amp Layzell 2000 faisait merger plusieurs enjeux relatifs un d veloppement logiciel souple la r ponse aux exigences de l utilisateur la personnalisation l adaptation une structure simple la transparence ou encore la confiance Ils introduisaient alors une approche permettant aux consommateurs de choisir la combinaison de services la plus appropri e tout moment on parlera du concept de late binding Dans cette id e Sommerville 2005 red finit le concept d ing nierie des exigences introduit en 4 1 2 comme la d finition du syst me en termes de services fournis et utilis s Il encourage ainsi la construction par la configuration de services existants permettant d augmenter la rapidit de la formulation des exigences mais aussi de leur interpr tation et du d veloppement Tout comme d un point de vue organisationnel la SOA encourage le d veloppement de l entreprise par sa r organisation elle permet d un point de vue Ing nierie L
32. Il est d finit sous forme de tableaux Le contexte g n ral rappelle le nom de la Pratique Individuelle Individual Practice outiller et r sume le but de l usage ex partager des documents l aide d une plateforme d change sharing documents with a groupware Il d finit galement ne La fr quence de l usage frequency rarement rare souvent often tr s souvent very often la localisation de l usage location au bureau at office sur le chantier on site au domicile at home chez le client at customer dans un lieu public in public location Le contexte de l acteur rappelle le m tier de l acteur et d finit son r le op rationnel operationnal role c a d son r le vis vis du syst me ex administrateur utilisateur Il d termine aussi si l utilisateur doit tre identifi Le contexte logiciel software d finit l application sp cifier type et description et les technologies utiliser pour cela Le contexte mat riel hardware d finit le support physique utilis savoir le type d appareil device ordinateur personnel computer ordinateur portable laptop smartphone smartphone tablette tactile tablet Le syst me d exploitation OS Windows macOS linux android iOS WindowsPhone Le type de dispositif d interaction interaction device clavier keyboard souris mouse pav tactile touchpad cran tactile to
33. Nous l identifions alors par son r le c est pourquoi dans le m ta mod le l attribut type_auteur est reli l num ration type r le Le statut d un artefact est un attribut important dans la mod lisation des pratiques car il permet de suivre l tat d avancement des t ches qui leur sont li es et donc du projet Le statut le plus r pandu dans un projet de construction est le statut bon pour ex cution qui est attribu aux plans envoyer sur le chantier pour ex cution des travaux Il est primordial que les plans bons pour ex cution soient jour et sans erreur afin d assurer la constructibilit et la qualit des ouvrages La liste des statuts d un artefact type statut est en cours termin pour ex cution ex cut valider valid modifier Un artefact peut avoir plusieurs statuts ex un plan termin et valider Conclusion Cette section pr sente la m ta mod lisation autour du concept de pratique et s appuie sur les concepts m tiers du M ta Mod le du Contexte Coop ratif La section suivante consiste d tailler la fa on dont les acteurs artefacts et activit s sont impliqu s autour du concept de pratique individuelle puis d op ration 1 28 2 Les pratiques individuelles et les op rations m tiers Les pratiques individuelles PI peuvent tre d finies comme le comportement isol de chaque acteur impliqu dans une pratique collectiv
34. R actions Doc6 Zones de visibilit Doc7 Tableau de bord des changes L ensemble de ces services informatiques fut impl ment sur base des technologies PHP MySQL dans une architecture client serveur et sont accessibles a travers une interface web Ces services dits services web sont d crits dans le protocole REST Fielding 2000 Le chapitre 5 de ce manuscrit apporte plus de pr cisions sur le concept de service Nous le r interpr tons galement dans le cadre de notre proposition chapitre 11 Les deux figures suivantes illustrent l interface des services m tiers documents Figure et comptes rendus Figure 12 Chapitre 2 Un cas de d veloppement d un outil de TCAO CRTI weB 4 www crti web lu index php 58 3 Projet listingDocuments Ci AORA L CRTI weB Chantier d valuation pour le CRP HT 7E Mes documents f Mesactions f Documents du projet f Coordination f Historique f Annuaire Convention de nommage Tous les documents 3 NOM STANDARD Date D POT Avant Projet Sommaire gt Avant Projet D taill Juillet 2013 Autorisations di penake M jH PL_V_AUT_N1_BT_1_001_01 xisx 12 07 2013 Gal E iti DT_F_APD_N2_BT_A_001_01 zip 04 07 2013 Ex cution Avril 2013 A PL_A_AUT_SN_AL_1_001_02 pdf Mars 2013 if IM_L_ASB_U3_SO_F_029_01 png 29 03 2013 PL_V_APD_N1_CF_a_154_01 png 29 03 2013 H PL_L_EXE_U1_BT_a_098_01 png 27 03 2013 gt L PL A PDE_N1_00_A_547_
35. Secrets to success and fatal flaws The design of large display groupware EEE Computer Graphics and Applications 26 1 pp 37 45 Hussain S et al 2010 Mapping of SOA and RUP DOA as Case Study Journal of computing 2 1 pp 104109 Ibrahim M amp Krawczyk R 2003 The level of knowledge of CAD objects within the building information model In Association for Computer Aided Design in Architecture pp 172 177 Idoughi D amp Kolski C 2009 Vers un d veloppement orient services des applications interactives dans le domaine de la logistique tude de cas In Workshop International IEEE Logistique et Transport Sousse Tunisie Jackson M amp Zave P 1995 Deriving specifications from requirements an example In Proceedings of the 17th international conference on Software engineering ACM pp 15 24 Bibliographie Kaindl H amp Jezek R 2002 From usage scenarios to user interface elements in a few steps In C Kolski amp Jean Vanderdonckt eds Computer Aided Design of User Interfaces 111 Valenciennes France pp 91 102 Kalnins A et al 2010 From requirements to code in a model driven way In D Grundspenkis ed Advances in Databases and Information Systems Springer Verlag Berlin Heidelberg 2010 pp 161 168 Kaner C amp Falk J 1999 Testing Computer Software Katsumata M 2007 Personalized groupware service for collaborative communities In ADIS International Conference Ap
36. Yang H 2005 Service identification and packaging in service oriented reengineering In Proceedings of the 17th International Conference on Software Engineering and Knowledge Management pp 219 226 Zignale D Kubicki S Ramel S et al 2011 A model based method for the design of services in collaborative business environments In Proceedings of IESS 1 1 Second International Conference on Exploring Services Sciences Geneva Switzerland p 15 Zignale D Kubicki S amp Halin G 2011 Business practices analysis for the adaptation of IT services to AEC projects Case study of design assessment related practices In CIB w078 w102 2011 Sophia Antipolis France Zimmermann O 2004 Elements of service oriented analysis and design BM developerworks Bibliographie Glossaire Activit L activit humaine est un ensemble de t ches dirig es vers une finalit et organis es au sein d un processus notamment dans le cadre de l exercice d une fonction d un m tier La th orie de l activit la d compose en trois sous ensembles l activit l action et l op ration Le projet AIC est une activit c est un double processus compos d une tape pr paratoire li e la conception et d une tape op ratoire li e la construction Artefact L artefact est un produit artificiel r alis par l homme Dans cette tude il regroupe les documents relatifs au domaine AIC les
37. collective voir 1 28 2 Le framework GMF pr sent en 1 24 2 propose des fonctionnalit s qui assistent la g n ration de l diteur partir du m ta mod le notamment gr ce un tableau de bord 93 Ces fonctionnalit s nous ont permis d entreprendre la conception de cet diteur sans connaissances en mati re de d veloppement et travers un apprentissage rapide Le b mol de ces fonctionnalit s est qu une fois l diteur g n r et personnalis couleurs formes des l ments types de traits toute r g n ration automatique aura pour effet d effacer la personnalisation Il est donc important de d finir le m ta mod le de mani re tr s pr cise avant de commencer la sp cification d un diteur qui sera pertinent 2a Sp cification de l apparence des l ments du mod le 1 Construction du M ta mod le 3 Combinaison du M2 et des sp cifications graphiques de l diteur Select Edit Create el n Select Edit Create 8 Select Edit Reload Select Edit Create Select Edit Create Generate diagram editor 2b Sp cification de Vapparencedela palette d outils 4 G n ration de l diteur Figure 93 Le tableau de bord GMF Chapitre 9 La mod lisation des pratiques le point de vue organisationnel Bien videmment il est toujours possible de reg n rer manuellement et par parties Apr s un apprentissage p
38. dent leur propre zone de d finition sur le graphique appel e espace de vie dont les limites sont repr sent es par des lignes en pointill s Technicien R le Limite entre 2 espaces de vie Figure 60 Repr sentation d un acteur et d une limite entre deux espaces de vie dans CBME Le contexte g ographique et le contexte temporel localisent l acteur dans l espace et dans le temps Q QU Contexte Contexte g ographique temporel Figure 61 Repr sentation des contextes g ographique et temporel dans CBME L artefact est un objet cr manipul ou d truit par une t che tandis que le dispositif et le syst me sont respectivement le support interactif et le logiciel utilis s Facture Artefact Dispositif Syst me informatique Figure 62 Repr sentation de l artefact du dispositif et du syst me dans CBME Les relations sont de type Poss de Acc de Contacte Synchronisation de donn es Ex cute une t che Ordonnancement de t che A B ao B At B os B A B A lt gt B A poss de B A acc de B A contacte B A et B changent A effectue La t che est des informations une t che et effectu en synchronisation influe sur B ni me position Figure 63 Repr sentations des relations du sc nario contextualis dans CBME Chapitre 7 Les m thodes de conception de services tudes de cas Il existe enfin deux types de pr conditions optionnelles ou ob
39. elle est m diatis e par des artefacts Kuutti 1996 Engestr m 1987 Hanser 2003 Comme le souligne Hanser 2003 un artefact peut galement tre un produit En effet au cours d un projet AIC le document plan est dans un premier lieu un produit de conception puis est utilis comme support lors de la construction de l ouvrage Originellement donc l artefact est assimil un outil les outils machines les outils documents les outils m thodes les outils logiciels Kubicki 2006 propose cependant de traiter ces deux concepts distinctement le concept d outil h rite du caract re instrumental et contient aussi bien les outils mat riel que les outils logiciel artefact est quant lui ramen sa d finition premi re savoir un produit artificiel r alis par l homme et regroupe les documents les plans les descriptifs textes les photos et les objets les ouvrages ou l ments d ouvrages architecturaux 1 1 3 L activit De mani re g n rale l activit est d finie comme un ensemble d op rations humaines dirig es vers une finalit l exercice d une fonction d un m tier ou un ensemble de t ches gt http www linternaute com dictionnaire fr definition activite Chapitre 1 La coordination dans les projets de conception construction architecturale organis es au sein d un processus L activit peut galement tre synonyme d a
40. es Lorsqu il s agit de la production d un ouvrage ex cution celle ci se fait la plupart du temps sur le chantier et donc de mani re partag e Par contre si l on consid re des ouvrages pr fabriqu s le processus se rapproche de celui des plans production puis diffusion dans un deuxi me temps L attribut type support servira identifier si l op ration analys e doit faire l objet du d veloppement d un service ou pas Les type support utilis s sont besoin de d veloppement d un service d j support par un service et service inutile En effet dans le cadre de l adaptation de services il ne s agira pas de tout reconcevoir mais au contraire de tenir compte des solutions existantes Savoir quand red velopper une solution ou au contraire quand r utiliser une solution existante est le premier enjeu afin viter d engager des co ts inutiles Cela permet ainsi de diminuer les risques d chec du projet et ceci d s ses premi res tapes 1 28 3 Conclusion Le M ta Mod le du Contexte Coop ratif MMCC issu de travaux ant rieurs a t r utilis et transform pour cr er le M ta Mod le des Pratiques M tier MMPM Outre les concepts m tiers du MMCC ce dernier a t cr sur la base de trois autres concepts centraux les pratiques collectives les pratiques individuelles et les op rations m tier Ce MMPM doit nous permettre de d crire les pratiques
41. fices sans pr voir l impact r el qu aura l outil les concepteurs chouent car ils ne capitalisent pas d exp rience dans la conception les outils tant trop complexes et ne permettant pas une analyse et une valuation g n ralisable Selon Greenberg 1991 l chec vient du fait que les m thodes de conception logicielle ciblent les utilisateurs individuellement sans les consid rer comme membres d un groupe L insatisfaction de certains utilisateurs fait partie des limites acceptables dans le d veloppement d un outil logiciel classique Or dans le cas d un collecticiel cette insatisfaction s av re plus pr judiciable elle a un impact n gatif sur le travail de toute l quipe entrainant l abandon g n ral de l outil Cockburn amp Jones 1995 ajoute que les strat gies de conception ne r ussissent pas prendre en compte les facteurs sociaux dans le travail de groupe I rel ve galement le manque de tra abilit des approches les erreurs de conception tant sans cesse r p t es Greenberg reste tr s critique quinze ans apr s dans Greenberg 2006 selon lui les besoins et les possibilit s sont grands concernant la suppression des barri res dues la distance et l augmentation du travail de groupe mais l adoption des collecticiels reste limit e mis part pour les services de messagerie instantan e qui sont maintenant largement impl ment s Il rel ve notamment la difficu
42. g n ral que d un point de vue technique 1 4 1 Identification des besoins m tiers et bonnes pratiques Les premi res phases d analyse sous la forme de brainstorming ont conduit l identification de deux enjeux ou besoins relatifs l outillage num rique de la conduite d un projet AIC la r daction et la diffusion de comptes rendus de chantier en prenant en compte les sp cificit s et la structure de ce document la diffusion de documents diverses durant le projet que ce soit des plans des textes des tableaux Relativement ces besoins les professionnels ont pu identifier certaines bonnes pratiques g n ralement adopt es dans le cadre de leur travail Tableau 1 Une bonne pratique est caract ris e par une action ex r diger consulter qui cible une information ex le compte rendu les requ tes sur un plan Tableau 1 Besoins m tiers outiller et bonnes pratiques li es Besoins Bonnes Pratiques CR1 R diger un compte rendu selon un mod le pr d fini CR2 Animer la r union de chantier et prise de notes CR3 Consulter le compte rendu CR4 Lire les remarques qui nous concernent R daction et CRS R actions sur les points particuliers du CR diffusion de CR CR6 Se tenir au courant de l avancement des t ches de construction CR7 Archiver un compte rendu valeur contractuelle non modifiable CR3 Rechercher les remarques en cas de litige
43. g om tral mod le perspective photo compte rendu rapport calendrier planning agenda ToDo Les objets sont relatifs aux ouvrages de construction voir galement 1 1 2 et sont d finis a plusieurs chelles Ainsi les type_artefact objet identifi s sont du plus grand au plus petit le site le lot le b timent le niveau la pi ce l ouvrage la r servation le mat riau et l chantillon On y ajoute le d faut notion de malfa on sur un ouvrage et le v hicule de chantier Les messages qu ils soient formalis s ou pas sont les traces de toute communication qui s instaure au cours des diff rentes t ches Parmi les type_artefact message on distingue les messages d information classiques d autres types plus sp cifiques comme les requ tes qui impliquent un retour une r ponse les notifications pour avertir les r actions qui ciblent quelque chose en particulier et enfin les validations qui permettent de donner son approbation sur quelque chose exigences sp cifications Chapitre 9 La mod lisation des pratiques le point de vue organisationnel Nous n avons pas typ les groupes d artefact la nature pouvant tre tr s vari e selon le contenu ensemble des plans ensemble des rapports permis de construire cahier des charges L auteur d un artefact simple ou groupe est un acteur du contexte coop ratif tel que nous l avons d fini pr c demment
44. information chang e autres acteurs en pr sence D s lors les risques qui peuvent tre rencontr s sont une demande impossible r aliser techniquement car incompatible avec le d veloppement d j en place ou demandant trop de temps l impl mentation une demande incomprise par les d veloppeurs menant des choix erron s qui ne satisferont pas l utilisateur et dont la correction sera co teuse C est pourquoi la bonne gestion d un tel projet en s assurant que les besoins identifi s sont les bons d s les premi res phases est primordiale Dans un secteur comme celui de la construction nous avons vu que les besoins peuvent tre tr s sp cifiques Ils sont d pendant du contexte m tier aussi bien d un point de vue organisationnel qu op rationnel Au cours de cette exp rimentation nous avons pu valider l int r t d une m thode permettant de prendre en compte ces points de vue l int r t d un document tra ant le suivi de cette m thode L approche de conception par services est de plus tout fait appropri e l outil CRTI weB lui m me ayant t d fini comme un ensemble de services m tiers r pondant a des pratiques collectives g n riques Kubicki et al 2009 Evaluation et volution des concepts m ta mod les et des mod les Cette premi re exp rimentation a permis de valider la distinction faite entre point de vue organisationnel et op rationnel tr
45. l volution des exigences En d autres termes identifier un but permettra de d terminer le besoin l exigence pour atteindre ce but Le tableau suivant Tableau 3 tir de Kavakli 2002 montre les diff rents apports de l analyse des buts dans les activit s d ing nierie des exigences identifi es pr c demment Tableau 3 Activit s de RE et type de buts les supportant Activit de RE Type de but Apport Elicitation Buts courants Compr hension de la situation organisationnelle existante Buts changeants Compr hension du besoin de changement Sp cification Buts futurs Laison des buts m tiers avec des composants syst me fonctionnels et non fonctionnels Validation Buts d valuation Validation de la conformit des sp cifications du syst me avec les buts du client Kavakli 2002 ajoute que le processus d ing nierie des exigences peut tre vu comme une progression travers quatre tats de mod lisation de la connaissance d crits par ces quatre types de buts l tat tel quel l tat de changement l tat d valuation et l tat tre Il pr cise que le cheminement travers ces quatre tats n est pas fig et qu il pourra varier en fonction du projet Il existe plusieurs m thodes d ing nierie des exigences orient e buts ex KAOS i NFR Lapouchnian 2005 et les formalismes varient galement De mani re g n rale lors
46. l identification d un nouveau d g t qui est alors cr dans le mod le et repr sent par le rep re correspondant dans la vue 1 20 4 Analyse critique et conclusion L approche de l quipe de Sophie Dupuy Chessa Dupuy Chessa 2011 et les travaux associ s aboutissent la proposition d une m thode de conception bas e sur la mise en commun des pr occupations de l IHM et des SI pour la conception logicielle Plusieurs points attirent notre attention au regard de nos pr occupations D s la phase d analyse pr liminaire le m tier est d crit tel qu il est pratiqu Nous pensons qu il y a un r el enjeu dans cette phase notamment concernant la description d un projet AIC Nous cherchons en effet tenir compte des variations d un contexte de projet un autre variations qui pourront se retranscrire dans la fa on de pratiquer un m tier Le formalisme Chapitre 7 Les m thodes de conception de services tudes de cas utilis est le sc nario en langage naturel L dition est libre sans structure qui soit d termin e par le contexte m tier analys Nous pensons qu assister cette analyse par l utilisation de concepts m tier s clairement d finis tels que nous les avons introduits dans le premier chapitre et un formalisme ad quat puissent contribuer l am liorer Dans un deuxi me temps nous proposons d exploiter la correspondance entre les mod les pour guider la mod
47. la sp cification du syst me utilisabilit IHM Prise en compte approfondie de Point de vue mono utilisateur l utilisateur de ses pr f rences et de son contexte T ches interactives clairement d finies SI Point de vue organisationnel Processus rigides guid s par une Prise en compte des besoins de strat gie peu adapt s des situations l entreprise accent sur l efficacit collaboratives particuli res et la productivit L individu est mis de c t R utilisation de services existants Collecticiels Bas s sur des grands principes de la Les principes de collaboration ne sont collaboration pas sp cifiques un domaine Points de vue aussi bien individuels Les approches sont trop th oriques et que collectifs manquent de m thode Chapitre 6 Travail Collaboratif Assist par Ordinateur et Services Collaboratifs Au travers des diff rentes analyses nous pouvons conclure que uncollecticiel doit fournir des services adapt s chacun des utilisateurs en tant qu individus mais aussi en tant que membres d un groupe de travail et l ments du contexte coop ratif dans lequel ils sont impliqu s la conception des services collaboratifs se doit d tre m thodique et outill e au regard des m thodes classiques de conception logicielle tout en prenant en compte les grands principes de la conception de services collaboratifs mais aussi les sp cificit s fonctionnelles
48. le partir du mod le pr c dent Cela r duira le temps de mod lisation et assurera la bonne correspondance entre les mod les La g n ration automatis e et incr mentale des versions du cahier d exigences pour chaque cas trait Au fur et mesure des applications nous pourrons b n ficier d un r pertoire de pratiques pr d finies et outill es sur laquelle nous pourrons nous appuyer pour d autres d veloppements L objectif long terme est de pouvoir associer de plus en plus d analyses m tier des besoins d j trait s pour r utiliser ne serait ce qu en partie le travail de conception d j effectu Par la s paration des points de vue et la transformation des mod les d un point de vue un autre cette m thodologie s inspire des approches MDA dont nous avons pr sent les caract ristiques pr c demment voir 1 11 2 Nous n avons pas explor pour la m thode PUSH les possibilit s de transformation automatis e Cependant assister le passage d un mod le l autre reste une opportunit gr ce l approche par composition de m ta mod les Une perspective serait d automatiser la cr ation du squelette d un mod le partir du mod le pr c dent Par exemple la base du diagramme de cas d utilisations l utilisateur le syst me et les packages pourrait tre cr e partir du diagramme de pratiques ne laissant au concepteur qu sp cifier les cas d utilisation
49. les de t ches sous forme de diagrammes dits dynamiques tel que CTT cf des diagrammes dits statiques comme le mod le ASUR Dubois et al 2002 qui d crit le contexte mat riel de mani re g n rale et les donn es traiter illustr Figure 70 et des maquettes 4 Chapitre 7 Les m thodes de conception de services tudes de cas EON Vocal s 8 Mesh Mae Augmented Expert vision display A J Figure 70 Description g n rale du contexte mat riel et des donn es a traiter avec le formalisme ASUR Si l on reprend l exemple illustr Figure 69 l objet m tier d g t damage est repr sent par une cible rouge qui est l objet interactionnel correspondant L analyse des sp cifications Il s agit ici d assurer la correspondance entre les objets m tiers et les objets interactionnels Figure 71 Pour cela ces objets sont structur s de mani re identique en objets processus business process et interactionnal process et objets entit s business entity et interactionnal entity Ensuite on d finit la correspondance translation entre les deux types d objets On parlera d analyse dynamique pour ce qui est de la description des processus et d analyse statique pour ce qui est des entit s En ce qui concerne l espace m tier les cas d utilisation identifi s par le sp cialiste GL sont raffin s en diagrammes de s qu
50. nario d utilisation adapt Il nous semble important de n avoir que rarement recours a l utilisateur Nous adoptons le concept d Usage Le point de vue fonctionnel Notre objectif est de sp cifier des nouveaux services ou d adapter des services existants pour am liorer l utilit et l utilisabilit des outils de TCAO Nous adoptons le concept de Services Collaboratifs C2 Ce ro Prendre en compte Prendre en compte Prendre en compte p l teh l utilisateur et le les aspects pi in 2 I contexte fonctionnels de la bi tials d utilisation collaboration Pratiques Collectives et Individuelles Services usages Collaboratifs Structurer la conception logicielle au travers d activit s clairement d finies bas es sur des mod les Une m thode de conception de services adapt s Figure 76 Construction de notre m thode en fonctions des approches analys es et leurs apports respectifs Chapitre 7 Les m thodes de conception de services tudes de cas PARTIE 3 Guider la conception de services collaboratifs adapt s au secteur de la construction Etudes propositions et perspectives Nous montrons dans cette derni re partie la construction de notre m thode d analyse et conception pour la proposition de services collaboratifs adapt s sur la base des hypoth ses d gag es et de l approche introduite Le premier chapitre d crit la m thodologie adopt e et les su
51. nerg tiques sur la base du recueil de donn es de la simulation et la g n ration d une valuation relative ou absolue Les outils de maquettage num rique sont une volution des outils de Conception Assist e par Ordinateur CAO classiques Ils permettant d ajouter un mod le 3D des informations relatives aux l ments de l ouvrage tel que la composition les propri t s la technique de montage employer Les divers outils comme le t l phone le mail la messagerie instantan e supportent la communication On parle d outil 4D puis nD lorsqu il s agit de repr senter un mod le 3D ou une maquette num rique et de lier les ouvrages des t ches dans une vue planning qui apparait alors comme une quatri me dimension puis d autres informations comme la repr sentation des co ts etc Le tableau de bord est un outil particulier que l on peut qualifier d outil d agr gation et de synth se vis vis des autres outils que nous venons de pr senter Il apparait comme un instrument de mesure Fernandez 2010 en fournissant des valeurs synth tiques relatives l information trait e ex le statut d une t che le nombre de remarques dans un rapport Dans un 2 Image tir e de http www gestiondeprojet net articles gantt html Chapitre 1 La coordination dans les projets de conception construction architecturale second temps il peut sugg rer des compositions de vues contenant
52. qu on appelle le tr fle fonctionnel Salber et al 1995 Piquet 2009 sont l espace de production supportant l action des acteurs sur l mformation l espace de coordination supportant la planification des activit s l espace de communication supportant l change d information On parle aussi du mod le 3C Gerosa amp Pimentel 2006 pour Communication Coordination et Coop ration o le terme Coop ration est utilis pour parler de la production conjointe des membres d un groupe au sein d un espace partag David 2001 propose une volution du tr fle fonctionnel int grant un nouvel espace de conversation Cet espace comprend les outils permettant la communication entre les acteurs mais ne produisant pas d information persistante au contraire de l espace de communication Figure 53 Chapitre 6 Travail Collaboratif Assist par Ordinateur et Services Collaboratifs Figure 53 Le mod le volu du tr fle fonctionnel Lors de l usage d un collecticiel les interventions des diff rents utilisateurs peuvent tre conceptuellement r parties dans deux contextes diff rents le contexte temporel et le contexte de localisation Piquet 2009 on parle d usages synchrones lorsque plusieurs utilisateurs agissent en m me temps et d usages asynchrones lorsqu ils interviennent des moments diff rents on distingue galement les usages dans un m me lieu
53. ration gt gt requ te d valuation lt lt Pratique Individuele gt gt Analyse le rapport et le valide lt lt r cuperation gt gt obtient manipule lt lt document gt gt rapport d valuation s lt lt message gt gt LA validation lerjgendre Figure 91 Instanciation du MMPM par un diagramme d activit s UML modifi Vers une mod lisation par des arbres hi rarchiques Il nous parait n cessaire d introduire un nouveau formalisme pour instancier notre MMPM plut t que de r utiliser le diagramme d activit s L objectif est de pouvoir manipuler les concepts introduits afin de guider la mod lisation en utilisant une palette d outils adapt e et les diff rentes num rations du m ta mod le Nous avons utilis le Framework GMF d Eclipse pr sent en 1 24 1 afin de cr er un diteur permettant d instancier notre m ta mod le de pratiques sous forme d un arbre hi rarchique Ce mode de visualisation est utile pour repr senter des syst mes relationnels organis s en couches comme par exemple la structure d une entreprise ou d une famille cf arbre g n alogique Nous verrons qu il s av re plut t adapt pour instancier le m ta mod le de pratiques Afin d en faciliter la diffusion et l valuation dans la communaut scientifique cet diteur a t con u en anglais Chapitre 9 La mod lisation des pratiques le point de vue organisationnel
54. re Ils apparaissent dans le diagramme sous forme d un rectangle noir aux coins arrondis CQ User intention A User Abstract Task 5 Concrete interaction task e9 Concrete perception task Interaction Object Figure 106 L gende du diagramme d interactions Le diagramme suivant Figure 107 sp cifie le use case mod lis pr c demment qui formalise l usage de CRTI weB dans lequel l utilisateur souhaite partager plusieurs fichiers et attend du l outil qu il groupe les fichiers choisis en un seul document Cette intention envoyer plusieurs fichiers upload multiple files est d compos e en deux t ches abstraites 1 le choix des Chapitre 10 La mod lisation des usages le point de vue op rationnel fichiers incluant le choix du regroupement puis 2 le nommage Le choix des fichiers se d finit par le suivi des t ches concr tes suivantes rectangles gris sur la figure activation de la fonction nouveau chargement s lection des fichiers visualisation du chargement s lection du regroupement et enfin de validation de la s lection La t che outil est sp cifi e par une t che concr te de perception identification de la upload multiple files Is composed of notification upload files in one CRTI weB document System task type Processing gt then A Choose files and clustering mode Abstract user
55. re s est d roul e en f vrier 2012 partir des besoins exprim s lors des ateliers nous avons pr sent notre tude des pratiques relatives ces besoins et de l usage concevoir pour y r pondre point de vue organisationnel et op rationnel Les mod les pr sent s taient un diagramme de pratiques un diagramme de cas d utilisations et un diagramme de t ches exprim en K MAD Ces mod les ont permis respectivement de justifier le besoin m tier en montrant qu il rel ve de pratiques courantes et de d finir les sc narios d usage id aux Trois sc narios ont t identifi s Ils taient consign s dans une premi re version du cahier d exigences Au terme de cette r union les d veloppeurs nous ont demand de pr ciser le service d velopper point de vue fonctionnel Un diagramme de s quences serait plus pertinent que le diagramme de t ches qui n apporte pas assez de pr cisions fonctionnelles La seconde s ance mars 2012 a fait l objet de discussions autour des diagrammes de s quence propos s Il tait question de repenser le service de partage de documents en fonction des trois sc narios d usage imagin s et en sp cifiant la gestion des cas d erreurs L objet de la r union tait de valider les diagrammes propos s en y apportant ventuellement des modifications Les d veloppeurs ont ensuite pu appr hender les possibilit s d impl mentation du service sp cifi Au cours de
56. s Les plans sont partag s sous la forme d un fichier dwg format d enregistrement d un plan ditable avec le logiciel autocad et plusieurs autres fichiers souvent sous forme de pdfs des repr sentations fig es des plans par exemple chaque tage des sp cifications techniques ou d autres documents n cessaires a la mise en ceuvre Ici le format des fichiers n est pas une information d terminante mais nous verrons qu elle peut avoir un impact non n gligeable Elle doit donc apparaitre dans notre mod le Vers un troisi me usage Nous avons identifi une variante de l usage de chargement group au cours duquel le format des fichiers est particuli rement important Il s agit du partage de plusieurs documents au format dwg parmi lesquels il y a un fichier maitre et des fichiers li s qui correspondent des parties du fichier maitre fichiers identifi s comme des xrefs auxquels fait r f rence le fichier ma tre Le service de partage de ces fichiers devra permettre de les grouper mais ne devra pas les renommer afin que le lien soit conserv techniquement Ces informations sont typiquement le genre d informations consigner dans un cahier d exigences pour garder traces des besoins identifi s Tel que nous l avons d crit dans le chapitre 10 notre m thode propose de les mod liser dans le contextual use case Figure 127 Chapitre 12 La m thode PUSH exp rimentat
57. the software engineer In H Achten et al eds 30th eCAADe conference vol 2 physical digitality Prague pp 87 97 Satyanarayanan M 1996 Fundamental challenges in mobile computing In Proceedings of the fifteenth annual ACM symposium on Principles of distributed computing PODC 96 New York New York USA ACM Press Sa kali K 2001 Flexibilit des Workflows par l approche objet 2FLOW un framework pour Workflows flexibles Ecole centrale de Lyon Schmidt K amp Simone C 1996 Coordination mechanisms Towards a conceptual foundation of CSCW systems design Computer Supported Cooperative Work CSCW 5 2 3 pp 155 200 Bibliographie Schmidt K amp Wagner I 2004 Ordering Systems Coordinative Practices and Artifacts in Architectural Design and Planning Computer Supported Cooperative Work CSCW 13 5 6 pp 349 408 Schwaber K amp Sutherland J 2011 The scrum guide Schwaber Ken amp Beedle M 2001 Agile Software Development with Scrum Prentice Hall Seffah A Kolski C amp Idoughi D 2009 Persona comme outil de design de services interactifs principes et exemple en e maintenance In JHM 09 Grenoble France ACM pp 13 16 Sierhuis M amp J Clancey W 2002 Modeling and Simulating Work Practice A Method for Work Systems Design EEE Intelligent Systems 17 05 pp 32 41 Simon H A 2004 The sciences of artificial MIT Press Sohlenkamp M Prinz W amp Fuchs
58. uvre Le concepteur extrait du programme les l ments n cessaires et les formalise en aide m moires organigrammes de services ou fonctions Les principaux l ments retenir sont les objectifs du Maitre d ouvrage les consid rations touchant l int gration de l ouvrage dans son environnement et l organisation spatiale L organisation g n rale des volumes doit tre affin e en fonction du programme du Maitre d ouvrage Le choix de la structure doit se faire par la collaboration du Ma tre d uvre et de l ing nieur structure avec l accord final du contr leur technique Cette phase comprend aussi les choix relatifs au confort thermique et acoustique Une notice descriptive r sume les principaux choix effectu s ainsi que les principales options retenues C est sur la base de ces descriptifs en compl ment des plans de l avant projet d taill APD et apr s accord du Ma tre d ouvrage que les cahiers des clauses techniques particuli res CCTP seront r dig s La demande de permis de construire se fait aupr s de la mairie Le MOE doit assistance au MO durant toute la dur e de l instruction du permis de construire Chapitre 9 La mod lisation des pratiques le point de vue organisationnel Tableau 16 l ments de caract risation de la PC5 Acteurs impliqu s Documents utilis s Activit s Maitre d uvre Programme T ches de conception et Ing nieurs Plans de conception de coordination Contr
59. 2011 Cette m thode propose un processus qui int gre trois tapes appel es vues Figure 79 la business requirements view BRV relative au point de vue des experts m tiers qui contient les mod les d crivant les exigences g n rales du domaine sous forme de pratiques collectives la business solution view BSV relative au point de vue des experts en services qui d crit la solution en termes de services m tiers sans aucune consid ration technique la technical solution view TSV qui correspond a une phase d analyse et conception logicielle assur e par les experts du g nie logiciel Eris rg Generic Domain Mosel Figure 79 Le processus de la m thode Dest2Co tir de Zignale et al 2011 Chapitre 8 Introduction de la proposition En comparant le projet de conception de service a un projet architectural nous pouvons galement cr er un parall le avec le concept de points de vue trait dans Hanrot 2005 On peut y lire que le point de vue porte sur certains aspects de l objet ici architectural mais dans notre cas nous parlons de service L auteur ajoute que le point de vue d pend de l expertise de l acteur et de sa connaissance des autres domaines Cette description du concept de point de vue correspond celle que nous lui conf rons dans notre tude Il s agit en effet de faire intervenir des acteurs aux expertises diff rentes expert m ti
60. 206 207 208 213 214 292 305 service m tier 46 97 98 99 107 206 207 213 214 222 248 292 Symphony 128 129 130 132 187 T th orie de l activit 32 148 173 181 285 U use case 68 73 82 83 118 186 193 194 197 220 231 232 235 238 239 243 247 250 303 304 276 Table des illustrations Liste des figures FIGURE 1 CONCEPTUALISATION D UN PROJET DE CONCEPTION ARCHITECTURALE POUR LA SPECIFICATION FIGU RE 14 SCHEMA DU PROCESSUS DE CONCEPTION DEVELOPPEMENT ET TRANSFERT DES SERVICES DE RE 15 PROCESSUS DE CONCEPTION FLUX DE CONNAISSANCE ET RESULTATS TIRE DE VAISHNAVI amp Table des illustrations FIGURE 40 ILLUSTRATION DES TRANSFORMATIONS ENTRE MODELES DANS LE CAS D ETUDE DE SOTTET ET FIGURE 42 POINTS D ENTREE DE LA CONCEPTION LOGICIELLE AU COURS DE L EVOLUTION DES METHODES FIGURE 48 CORRELATION ENTRE BUSINESS MODEL ENVIRONNEMENT STRATEGIE PROCESSUS ET FIGURE 52 REPRESENTATION DES APPROCHES DE CONCEPTION DE SERVICES ICT DANS L ARCHITECTURE FIGURE 55 POSITIONNEMENT DES SERVICES PAR RAPPORT AUX CARACTERISTIQUES D UNE ACTIVITE FIGURE 60 REPRESENTATION D UN ACTEUR ET D UNE LIMITE ENTRE DEUX ESPACES DE VIE DANS CBME 117 Table des illustrations FIGU REPRESENTATION DES CONTEXTES GEOGRAPHIQUE ET TEMPOREL DANS CBME RE 62 REPRESENTATION DE L ARTEFACT DU DISPOSITIF ET DU SYSTEME DANS CBME
61. 4 De l utilisateur la conception logicielle et d interfaces AIO sont la cl de la g n ration automatique d interfaces dirig e par les mod les voir la section suivante 1 11 Bodart amp Vanderdonckt 1996 r partissent les AIO en six familles les objets d action de d filement statiques de contr le de dialogue et de r action feedback Tableau 7 L ensemble des AIO r partis en 6 familles extrait de Bodart amp Vanderdonckt 1996 Action AIO menu menu item menu bar pull down menu pop up menu cascading menu submenu embedded menu removable menu expandable menu com pound menu scroll arrow scroll cursor scroll bar frame abel separe x prompt static icon Control AIO single line edit box multi line edit box profiled edit box command box scale thermometer gauge jogger check box switch option box radio but ton radio icon dynamic icon spin button push button drawn button cyclic button 2D and 3D tool boxes list box unitary list box Boolean list box file selection list box drop down list box scrolling list box combination box drop down combination box scrolling combination box normal table ex tended table value set Dialogue AIO window help window logo window edit windows dialogue box expand able dialogue box repetitive dialogue box radio dialogue box panel control panel Feedback OIA information message warning message help message error message pro
62. Dupuy Chessa Dupuy Chessa 2011 quant la crois e des chemins entre la mod lisation des Interfaces Homme Machine IHM et des Syst mes d informations SI pour la conception logicielle Nous pr sentons ici la m thode de d veloppement propos e par son quipe et bas e sur la sp cification d exigences a la fois organisationnelles et interactionnelles Nous nous int ressons tout particuli rement aux activit s collaboratives mises en place au cours de ce processus 1 20 1 Symphony et symphony tendue Symphony est une m thode de d veloppement de syst me interactif it rative et incr mentale Un syst me interactif est compos de deux parties l interface utilisateur et le noyau fonctionnel L interface utilisateur contient les l ments logiciels et mat riels d di s la capture des entr es de l utilisateur et la restitution des sorties du syst me Le noyau fonctionnel contient le reste du syst me c est dire ses composants de calcul et de stockage de l information La m thode Symphony est une m thode bas e sur l utilisation de composants cf 1 9 1 appel s objets Les objets interactionnels d crivent l interface et sont sp cifi s partir des objets m tiers qui eux d crivent le noyau fonctionnel Le but est de faciliter la collaboration entre les acteurs d un projet de conception logicielle particuli rement entre ceux de l IHM et du GL et de permettre aux concepteurs de produire
63. E Designer IP Diffusion des documents produits Responsable de la diffusion CONCEPTES expose ES ci conceptuel de l 7 2 Job Architect Un des concepteurs expose les choix conceptuel de l qupe pour valiston Mar type Agency Plans du prot au stade APS Designer Author Designer lt Add here more speciites f needed gt Status In Progress ADDITIONAL INFORMATION Do you wantto add any information about the business context and the practice to perform Do you want to add any information about the information to manage artifacts activities actors Figure 94 Formalisation de l analyse m tier combinaison d un mod le et de remarques 1 30 Conclusion Les tudes sur le contexte coop ratif la th orie de l activit ou encore les processus de l information c f 1 1 puis 1 28 2 nous ont permis de conceptualiser nos propres analyses port es sur le d roulement de la coordination au cours d un projet AIC Nous avons construit un m ta mod le des pratiques de projet autour de trois concepts les pratiques collectives les pratiques individuelles et les op rations Nous avons ensuite d velopp un diteur pour instancier ce m ta mod le afin de d crire des pratiques observ es Les pratiques collectives analys es dans ce chapitre ont t r parties en onze familles qui apportent une structuration du projet plus fine que les traditionnelles phases Elles d finissent des objectifs g n raux relatifs
64. Kaner amp Falk 1999 Durant les phases de planification c d d tudes pr liminaires et d laboration il est n cessaire d valuer les exigences de par l analyse du SRD et les d finitions fonctionnelles apport es par les activit s de conception Les exigences doivent tre estim es coh rentes vis vis des besoins identifi s le produit exig est il utile Pendant combien de temps le sera t il mais aussi des possibilit s de d veloppement quels sont les moyens personnels techniques financiers disposition Est ce raisonnable d entamer le d veloppement Le produit con u et propos doit r pondre aux exigences savoir aux besoins mais cela signifie aussi qu il doit tre r alisable techniquement en fonction des performances du dispositif qui l ex cutera L valuation de la solution impl ment e se fait au travers de tests d utilisation ex cut s en interne dans l quipe de d veloppement identification des bugs majeurs puis aupr s des clients qui valueront son utilit test de l acceptation Le produit ne peut tre test qu partir du moment o il est en partie fonctionnel Lors du d ploiement c est dire lors de la livraison du produit il peut tre n cessaire d en assister l installation Le produit doit ensuite tre maintenu travers l assistance technique la correction de bugs persistants ventuels voire l volution de la
65. L 2000 POLIAwaC Design and evaluation of an awareness enhanced groupware client Al amp SOCIETY 14 pp 31 47 Sommerville I 2005 Integrated requirements engineering A tutorial Software IEEE 22 1 pp 16 23 Sommerville I 1996 Introduction to Software Engineering Sottet J S Calvary G amp Favre J M 2005 Ing nierie de Interaction Homme Machine Dirig e par les Mod les JDM Premi res Journ es sur l Ing nierie Dirig e par les Mod les Soulier E amp Lewkowicz M 2006 Simulation des pratiques collaboratives pour la conception des SI bas s sur les processus m tier Revue des Sciences et Technologies de Il Information 11 3 pp 73 94 Soulier E Lewkowicz M amp Corouge N 2007 Gestion des processus m tier et travail collaboratif myriamlewkowiczfreefr p 25 Suchman L 1987 Plans and Gtuated Actions The Problem of Human Machine Communication Learning in Doing Social Cognitive and Computational Perspectives Cambridge University Press Sutcliffe A 2005 Applying small group theory to analysis and design of CSCW systems ACM SIGSOFT Software Engineering Notes pp 1 6 Sutcliffe A 2007 Requirements Engineering from an HCI Perspective In Requirements Engineering Activities and Processes pp 1 39 Sutcliffe A 2003 Scenario based requirements engineering Journal of Lightwave Technology pp 320 329 Tarpin Bernard F 1997 Travail coop ratif synchrone ass
66. L utilit de mod liser les objets d interaction n a pas t valid e ici tant donn la simplicit de ces derniers Enfin les diagrammes de s quences ont t enti rement sp cifi s par le d veloppeur lui m me Ainsi il a pu rendre compte de sa production mais aussi des difficult s techniques auxquelles il tait confront Les concepteurs sont bien souvent trop attach s leurs choix conceptuels sans consid rer les limites techniques Nous concluons que la discussion autour de ces diagrammes permet de faciliter la compr hension entre ces deux mondes C est partir de ces diagrammes de s quence techniques que nous avons pu sp cifier le m ta mod le de services qui guide maintenant leur cr ation au cours de l application de la m thode PUSH 1 42 Exp rimentation 3 sp cification d un tableau de bord 1 42 1 Introduction et d roulement Au cours de cette troisi me exp rimentation la m thode n a t appliqu e que partiellement L enjeu portait essentiellement sur la sp cification d usages et les liens avec des pratiques et non sur le d veloppement des services proprement dit C est un travail qui a t men par deux Chapitre 12 La m thode PUSH exp rimentations et bilan personnes jouant l une jouant le r le de concepteur l autre et d expert m tier Dans cette exp rimentation la volont tait de proposer un nouvel outil qui r ponde des pratiques existant
67. La responsabilit de l outil est appel e t che outil Chapitre 10 La mod lisation des usages le point de vue op rationnel L intention rel ve d un objectif g n ral ex s identifier Certaines des intentions sont d duites des op rations m tiers qui ont t d finies dans le m ta mod le des pratiques Cela est formalis par la relation supporte D autres intentions sont ind pendantes des op rations m tiers et rel ve plus d une contrainte technique Par exemple s identifier qui est n cessaire pour beaucoup d applications mais que l on n associe pas une op ration m tier particuli re Les t ches utilisateurs sont dans un premier temps consid r es comme abstraites C est dire qu elles d crivent une action pr cise ex entrer login et non comment cette action est ex cut e ex taper login dire le login Cela rel ve de la t che dite concr te qui peut tre de l ordre de P interaction ou de la perception seulement Les m thodes de conception d IHM et plus particuli rement dans les approches g n ratives de MDA voir 1 112 introduisent des types de t ches abstraites que nous r utilisons Cela nous permet d envisager des perspectives d int gration de notre m thode dans de telles approches Ces types sont entr e sortie commande s lection navigation conteneur De la m me mani re nous typons les t ches concr tes interaction cr
68. Les remarques poss dent leurs attributs propres tels qu un num ro un intitul une description litt rale une priorit une date de constat Ces remarques peuvent faire l objet de rappels au fil des semaines ou encore tre illustr es par des croquis ou des photos de chantier L avancement d crit la progression du chantier il est notamment compar au planning de chantier qui aura t fix L agenda pr cise la date et l heure dont on aura convenu pour la prochaine r union Les autres documents sont les plans de tout type les fiches techniques les tableurs les mod les etc c est dire tout document supportant l change d information entre les acteurs du projet Un certain nombre d attributs les d finissent et permettent leur gestion dans une base de donn es comme travers l outil CRTI weB un nom qui lors de l exp rience crti web a fait l objet d un travail particulier donnant lieu a une convention de nommage bien d finie Ainsi le nom de chaque document est la composition de plusieurs acronymes permettant d identifier la phase de projet le type de document sa version etc un auteur qui est identifi lors du partage du document apr s avoir t identifi une zone de visibilit qui permet de restreindre l acc s certains types d acteurs des actions et des r actions qui permettent d avertir un ou plusieurs acteurs de la disponibilit d un document
69. REPRESENTATIONS DES RELATIONS DU SCENARIO CONTEXTUALISE DANS CBME RE 64 REPRESENTATION DES DEUX TYPES DE PRE CONDITION DU SCENARIO CONTEXTUALISE DANS CBME 118 RE65 UTILISATION DE CBME POUR ECRIRE LES SCENARIOS CONTEXTUALISES TIRE DE FIGU RE72 INTERVENTION DES DIFFERENTS ACTEURS DE LA METHODE SYMPHONY AU COURS DE LA RE 76 CONSTRUCTION DE NOTRE METHODE EN FONCTIONS DES APPROCHES ANALYSEES ET LEURS RE 78 PROCESSUS DE META MODELISATION A PARTIR DE L ANALYSE DE CAS ET DE LA LITTERATURE RE92 INTERFACE DE L EDITEUR GMF D ARBRES HIERARCHIQUES POUR LA MODELISATION DES RE 94 FORMALISATION DE L ANALYSE METIER COMBINAISON D UN MODELE ET DE REMARQUES 174 RE95 DES USAGES DIFFERENTS POUR UNE MEME PRATIQUE EXEMPLE D UNE PRATIQUE DE PARTAGE RE 100 Table des illustrations FIGURE 109 TABLEAU DE SAISIE DES INFORMATIONS SUPPLEMENTAIRES DANS LE CAHIER D EXIGENCES FIGURE 112 CARACTERISATION DU SERVICE CONCEPTS EN BLEU MATERIALISANT L USAGE CONCEPTS EN ROUGE 201 FIGURE 116 RAPPEL DIAGRAMME D INTERACTION DECOMPOSANT L INTENTION UPLOAD MULTIPLE FILES 207 FIGURE 117 DIAGRAMME DE SEQUENCE MODELISANT LE SERVICE ICT DE TELECHARGEMENT DE Table des illustrations FIGURE 137 PROPOSITION D UN NOUVEL OUTIL SUR LA BASE DE MAQUETTAGES TIRE DE GUERRIERO ET RE 138 DIAGRAMME DE LA PRATIQUE DE SURVEILLANCE DU CHANTIER FIGURE 139 EXTRAIT DU CONTEXTUAL USE CASE POU
70. Receiptitotal productiD s La ligne A pointill e repr sente un message de retour Figure 23 Exemple de diagramme de s quence syst me Alors que l analyse d crit le quoi faire apr s avoir d fini le pourquoi avec les exigences la conception d finit le comment faire Cette activit implique l interpr tation du concepteur c est l activit cr ative du processus et la plus subjective Elle consiste interpr ter l analyse pour proposer une solution dans une architecture logicielle et mat rielle travers des classes et des abstractions d objet c est ce qu on appelle l architecture conceptuelle Bass et al 2003 Elle repr sente la fois l ensemble des v nements et l ensemble des donn es Guibert 2007 Le concepteur tend le diagramme de s quences syst me en un diagramme de s quences technique dans lequel il y ajoute les v nements internes au syst me qui est alors d crit plus pr cis ment sous forme d entit s logicielles ou de composants il est qualifi de bo te blanche On parle ici de d composition fonctionnelle Syst me Syst me boite noire boite blanche ES eB 1 Entr e gt i 2 Entr e i 1 3 Ev nement interne 1 5 Activit du syst me 4 Ev nement interne 2 H 16 Ev nement interne 3 DER a seit i i H 7 Sortie i 5 8 Sortie Diagram
71. Un exemple d utilisation de CTTE pour la conception d interface est illustr Figure 34 5 L outil CTTE et les informations relatives au formalisme CTT sont disponibles cette adresse http giove isti cnr it tools CTTE home Chapitre 4 De l utilisateur la conception logicielle et d interfaces Couche fonctionnelle _ fa Couche op rationnelle es jii P gt s gt oe Qty Totalproduct Totalorder ok cancel gt gt gt SS gt gt SS Category Productname Showcode Show price Figure 34 Exemple d arbre de t ches CTTE extrait de dans Pribeanu 2005 Relativement proche de l diteur CTTE l outil K MADe Kernel of Model for Activity Description environnement Baron et al 2006 permet de repr senter l activit de l utilisateur sous forme d arbres de t ches sur la base d une structure nomm e N MDA Noyau du Mod le de Description de l Activit Lucquiaud 2005 Il est compos de trois diteurs diteur graphique pour construire des arbres de t ches diteur de caract ristiques pour caract riser ces t ches travers diff rents attributs l diteur des objets manipul s par l utilisateur L arbre de t ches K MAD permet de d composer l activit en une t che g n rale des t ches interm diaires puis des t ches dites l mentaires le plus fin degr de granularit On retrouve le d coupage en types de t ches comme d
72. alourdit la lecture et nous parait superflue Le s quen age des pratiques fl ches rouges dans le mod le n est d ailleurs pas d crit par notre m ta mod le le but tant en premier lieu de comprendre ce que chacun fait et non d optimiser un processus qui devra tre suivi Il ne doit donc pas tre mod lis Par contre r partir la mod lisation de chaque PI dans des diagrammes ind pendants permettra alors d isoler les besoins de chacun et en facilitera la lecture Nous pensons qu un formalisme de mod lisation doit r pondre aux questions que le concepteur se pose lors de la mod lisation Dans notre cas il est question de cr er un formalisme qui soit utilisable et compr hensible par les analystes m tiers et donc partir des concepts m tiers d finis par le MMPM De plus nous pr conisons un formalisme simple d acc s autant par la lecture que par l dition Chapitre 9 La mod lisation des pratiques le point de vue organisationnel lt lt Pratique Individuelle gt gt Produit documents pour valuation lt lt Pratique Individuelle gt gt Soumet les documents pour expertise lt lt Pratique Individuele gt gt Ex cute l valuation lt lt groupe d artefacts gt gt plans valuer 4 ipule lt lt iffuusion gt gt p engend partage a lt lt communication gt gt y ns wf lt lt production gt gt avertit cr e lt lt op
73. alt rer ainsi que l efficacit c d la capacit r duire les efforts induits par certaines t ches Ces principes ou approches ne restent pourtant que des lignes directrices sans tre vraiment des sp cifications pour la conception de services collaboratifs adapt s Chapitre 6 Travail Collaboratif Assist par Ordinateur et Services Collaboratifs Un nouveau paradigme GL GL 4 4 4 4 Applications Applications Services m tiers Services utiles utilisables et ICT collaboratifs Figure 57 Vers un nouveau changement de paradigme dans la conception logicielle Au terme des analyses men es dans les chapitres 4 et 5 nous avons pu observer comment le domaine des IHM et des SI alimentaient le G nie Logiciel pour concevoir respectivement des Interfaces adapt es aux utilisateurs et des Services Informatiques r pondant aux besoins d une organisation La conception de services collaboratifs tudi e dans ce chapitre 6 peut tre vue comme une nouvelle branche un troisi me paradigme de la conception logicielle Figure 57 Le tableau ci dessous r sume les avantages et les limites des diff rentes approches Tableau 10 Tableau 10 Avantages et limites des champs tudi s Domaines Avantages Limites GL M thodes structur es bas es sur des Pas de prise en compte du contexte de mod les Putilisateur S paration de l analyse m tier et de M thodes orient es exigences et non
74. are performed by users within roles Tasks are about what users do roles are about how they do it The key to succinct characterization of user roles is differential description How is this role not like other roles What is distinctive or salient about it in comparison to other roles Listed below are typical factors for consideration as potentially relevant and useful for characterizing a user role They may or may not apply to a given role Context within which role is played Is there anything special or distinguishing about this role in terms of P Examples overall job workflow or activity within which role is played Follow up of prior purchase physical environment in which role is played Typical noisy office social situation in which role is played With field research partners relationships with indirect users in role Customer on telephone external sources of information such as paper forms Phone review of packing slip telephone visual observation in person interview ENVIRONMENT background of role incumbents in terms of training Cursory OTJ training education or experience system knowledge expected or required within role Fully familiar from long use domain knowledge expected or required within role No retail management knowledge distribution of user skills in terms of novice intermediate Mostly perpetual novices or expert usage patterns required or discre
75. bonne ex cution du chantier en faisant en sorte que les entreprises de construction acc dent aux documents ex cuter tout en vitant qu ils n utilisent des documents rendus obsol tes par des mises jour But Strat gique But de type SE yr eseretrr m r Documents d ex cution 3 atteindre j 1 prisen compte par eA ee Bonne ex cution du chantier ET O maintenir 7 Enterprise avertie de I 1 chaque nouveau i 1 A A i Entreprise avertie de H I l obsolescence 1 Figure 21 Exemple de diagramme de buts Les sc narios sont la repr sentation du monde r el Les m thodes bas es sur les sc narios x compl tent les buts en rendant les intentions plus claires travers des descriptions de fonctionnement qui satisfassent ces buts ScenIC et SCRAM en sont deux exemples Misra amp Kumar 2005 On retrouve dans les typologies de sc narios un d coupage similaire celui observ pr c demment pour les buts voir tableau 1 savoir les sc narios de d claration du probl me qui expliquent en quoi le syst me actuel n est pas satisfaisant les sc narios de vision d crivent comment le syst me devrait op rer les sc narios d usage ou comportementaux d crivent les comportements des utilisateurs et du syst me actuel ainsi que leur contexte physique et social Ils sont aussi utilis s comme donn e de test pour la validation des exigences Les buts et les sc
76. cis travers un maquettage le risque majeur est qu il ne per oive pas les limites du r alisable dans le contexte technologique dans lequel il se trouve Il ne peut pas non plus valuer les co ts et le temps requis pour mener le projet de d veloppement bien D un point de vue collaboratif une proposition sur simple maquettage ne pourra donc pas suffire aupr s d une soci t de services car avant tout d but de projet il faudra v rifier qu il y ait de r els besoins m tiers outiller il faudra valuer l impact d une telle proposition en termes de d veloppements La m thode PUSH permet par la mod lisation d ancrer une volont d innovation dans un processus de conception justifi Elle encourage ainsi l amorce d un projet de d veloppement aupr s de ses acteurs Chapitre 12 La m thode PUSH exp rimentations et bilan Evaluation et volution des concepts Nous avons d faire voluer les m ta mod les afin de pouvoir d crire les situations de la mani re la plus fid le Nous avons par exemple ajout l objet d faut n cessaire ici dans la caract risation de la pratique Par extension en nous questionnant sur les l ments relatifs au chantier qui n taient pas encore caract ris s nous avons galement ajout les engins de chantier les mat riaux et les chantillons L approche dirig e par les mod les et en particulier la g n ration de notre propre interf
77. composent notre probl matique voir 1 7 2 nous constatons que celle ci rel ve de la science de la conception sous tous ses aspects nous voulons concevoir des services informatiques pour le Travail Collaboratif Assist par Ordinateur le produit souhait est une instanciation Nous voulons que ces services soient adapt s a un domaine ce qui n cessite d en construire les concepts Nous voulons concevoir une m thode qui supporte les objectifs pr c dents Nous voulons construire des mod les sur lesquels s appuie la m thode La figure suivante Figure 16 illustre notre approche et la structure des prochains chapitres de cet ouvrage La partie 2 chapitres 4 5 6 et 7 propose une analyse des m thodes de conception dans divers domaines du d veloppement logiciel et ce que nous en retenons pour concevoir notre propre m thode de conception La description de cette m thode et son application dans divers cas d tude font l objet de la partie 3 chapitres 8 9 10 11 et 12 PARTIE 2 tat de l art Les m thodes de conception dans divers domaines o B La conception de CRTI weB Connaissance La m thode de conception suivie dans ce travail de th se Evaluation Conclusion Suggestion D veloppement PARTIE 1 contexte d tude Etudes initiales le contexte tri facettes Les concepts et la m thode de conception de servic
78. concepteurs responsable de la production des plans et autres documents qui sp cifient le b timent la fois formellement et techniquement Les constructeurs qui mettent en uvre le b timent partir des documents de conception Le coordinateur responsable du bon d roulement du projet notamment par l identification des probl mes et le suivi de l information L expert qui est relatif un r le de conseiller comme l assistant la ma trise d ouvrage mais aussi d analyste comme les bureaux de contr le Enfin nous regroupons toutes les institutions externes aux projets mais ayant un r le d cisionnel sous le r le d administration La notion de mission contractuelle d finit les responsabilit s attribu es un acteur et ses objectifs atteindre Par exemple les missions de ma trise d uvre sont confi es par le ma tre d ouvrage un architecte ou un entrepreneur En France la loi MOP loi relative la ma trise d ouvrage publique et ses rapports avec la ma trise d uvre priv e r git la nature de ces missions Par d finition le ma tre d uvre est la personne de droit priv ou le groupement de personnes de droit priv qui doit permettre d apporter une r ponse architecturale technique et conomique au programme Les missions de ma trise d ceuvre sont les tudes d esquisse les tudes d avant projets les tudes de projet l assistance apport e au ma tr
79. contexte instanciation d un m ta mod le du contexte MMC qui d crit l environnement de l utilisateur compos de l ensemble des informations qui ont une influence sur les besoins et les capacit s de l utilisateur communiquer et des dispositifs qu il utilise Le m ta mod le comportemental est une agr gation de ces 3 m ta mod les MMWf MMT MMC et d crit aussi les mod les de r le et d artefact La cr ation de l application Pour l application de cette m thode Delotte 2006 d compose l architecture logicielle d un syst me coop ratif en trois niveaux Le CUO M Collaborative User Oriented Model supervise les interactions et propose les interfaces de pr sentation Il est d crit dans le formalisme AMF C une volution du mod le Chapitre 7 Les m thodes de conception de services tudes de cas d architecture logicielle multi agents AMF Agent Multi Facettes Masserey amp Samaan 2006 Le CSA M Collaborative System Architecture Model contr le les sessions les utilisateurs et les groupes Le DSI M Distributed System Infrastructure Model distribue les messages et contr le le contenu La deuxi me phase de transformation assure le passage de mod le comportemental CAB au mod le d architecture logicielle Les patrons de t ches les composants logiciels et les patrons d interaction forment des catalogues dans lesquels vont s alimenter chacune des trois t
80. contexte collectif Pourtant l chelle du projet l objectif est unique la cr ation d un ouvrage construit unique et remarquable qui sera parcouru v cu et adopt Les mauvais choix les changements dans la conception les retards les malfa ons ont des impacts financiers consid rables dans un contexte conomique d j particulier l erreur individuelle se r percutant sur le travail global Il est donc de la responsabilit de chacun de mener bien son activit Mais souvent la mani re dont les acteurs collaborent est une source de probl mes suppl mentaires mauvaise compr hension mauvaise transmission d informations absence de suivi des demandes des collaborateurs etc La gestion de ces risques issus de la collaboration est un enjeu important Pour assister l implication des acteurs dans leur collaboration avec les autres membres du projet il est profitable d utiliser les outils technologiques aujourd hui disponibles De plus en plus performants et accessibles ces outils sont souvent la cl d une bonne gestion du projet diminuant les risques d erreur et r duisant le temps de certaines activit s de coordination Les approches orient es services ambitionnent de rendre ces outils modulaires et flexibles L enjeu auquel nous essayons de r pondre au cours de ce travail est alors d assurer une bonne ad quation de ces services afin que la r ponse aux besoins soit r elle Bien des arch
81. currente de d cisions et l auto organisation du travail pond r e par des ajustements mutuels Nous constatons galement travers ce sch ma que les artefacts manipul s les plans en sont le meilleur exemple sont en constante volution lors des activit s pr paratoires artefacts dynamiques alors qu ils sont finalis s lors des activit s op ratoires artefacts statiques Chapitre 1 La coordination dans les projets de conception construction architecturale Activit s pr paratoires Activit s op ratoires Artefact Statique aN Oralit i i I i I 3 l Eh N _ Implicite solos 4 ae 3 5 Ajustement Explicite I oO mutuel b Ja l v TET EET gt I Artefact Supervision f dynamique directe i o Organisation de type hi rarchique Organisation de type adhocratique Organisation de type transversale Figure 5 Caract risation des activit s de coordination dans un projet AIC adapt de Kubicki 2006 La volont de ma triser la coordination et de faciliter l auto coordination a motiv l utilisation d outils m diatisant celle ci Pour cela il a fallu am liorer notre compr hension de cette activit collective et d finir celle ci sous toutes ses formes Parall lement l innovation constante en mati re de technologies ouvre le panel des possibles et favorise la cr ation de nouveaux outils Nous en pr sentons quelques typ
82. d Information 1 14 3 Du service m tier au service informatique Comme nous l avons dit les activit s du niveau organisationnel support es par les processus dans le d veloppement d une SOA correspondent aux activit s d analyse et conception au cours d un d veloppement logiciel Rappelons que dans le RUP l analyse consiste mod liser le quoi faire puis lors de la conception on mod lise le comment faire Dans le d veloppement d une SOA on retrouve cette distinction travers deux aspects Kohlmann amp Alt 2007 aspect m tier avec la mod lisation des services m tiers orchestr s en processus Arsanjani 2004 aspect technique avec la mod lisation du syst me d compos en services informatiques qui sont li s des fonctionnalit s logicielles d finir ou r utiliser Zhang et al 2005 Certaines m thodes de conception ou re conception de services cherchent couvrir ces deux aspects Quartel et al 2004 mais nombre d entres elles ne se focalisent que sur l un ou l autre de ces aspects C est notamment le constat que fait Kohlborn et al 2009 apr s une analyse d taill e d une trentaine de ces m thodes Au del de cette analyse il propose de d finir une approche consolid e pour l identification de nouveaux services qui pourront tre fournis aussi bien un niveau m tier qu un niveau technique Dans les paragraphes qui su
83. d introduire nous pouvons d finir les deux l ments de caract risation d un usage Figure 96 Vobjectif atteindre en tant qu attribut de l usage la relation m diatise qui relie conceptuellement un usage une pratique individuelle Nous pouvons d s pr sent sp cifier au travers des cardinalit s que plusieurs usages peuvent m diatiser la m me pratique par exemple si il y a changement d outil de lieu un m me usage peut r pondre plusieurs pratiques si le d roulement des ces pratiques est similaire Pratique Individuelle E IRC Nom texte Description texte ou Objectif texte m diatise N e Figure 96 Relation entre les concepts d usage et de pratique Nous composons le M ta Mod le d Usage MMU par parties comme nous l avons fait pour caract riser les pratiques Les sections suivantes montrent comment cette relation m diatise entre usage et pratique se r percute sur les l ments relatifs aux deux concepts entre les t ches et les op rations m tier entre le contenu d interaction et les informations manipul es par ces op rations entre l utilisateur dans son contexte et l acteur 1 32 1 L interaction Nous d composons l interaction de l utilisateur avec le syst me en deux phases l action cognitive nomm e l intention utilisateur et l action physique qui elle est appel e la t che utilisateur
84. dans la partie 1 devient un contenu m diatiser Interaction Object lors de Pusage d un service informatique sous forme d objet d interaction Ce contenu est alors identifi par un nom une sp cificit graphique des attributs un type de donn e et des propri t s Les relations entre t ches peuvent tre de composition is composed of Then ou de processus AND OR THEN Une relation tache objet se nomme or interagit avec interact with And La description de l interaction peut tre compl t e par des maquettages abstraits ou concrets Ay Annexes Partie 3 Sp cification du service La sp cification du service apporte la r ponse technologique aux usages d finis dans l tape pr c dente Le formalisme utilis est le diagramme de s quences L gende et pr cisions Les diagrammes de cette partie d crivent l utilisation d un service ICT par un client l architecture de ce service chaque composant ayant un st r otype mod le priv mod le partag vue ou contr leur et les flux de donn es inputs du client vers la vue outputs de la vue vers le client et actions entre les composants du service Ces diagrammes prennent en compte des sc narios id aux et les cas d checs possibles Ils pourront voluer en fonction de l avancement du projet Nom de l outil nom et description du service m tier Nom du service ICT X lt gt
85. dans le projet et visait automatiser le service d envoi de fichiers sur la plateforme CRTI weB La derni re tait une exp rience de conception seule sans objectif de d veloppement court terme visant sp cifier un service de surveillance de chantier support par un tableau de bord num rique sur tablette tactile D roulement des exp rimentations Upload multiple crti web milieu professionnel Upload automatique crti web milieu tudiant Tableau de bora Mai F vrier Mars Avril Juillet Figure 123 R partition des exp rimentations dans le temps Chapitre 12 La m thode PUSH exp rimentations et bilan 1 39 3 Objectifs des exp rimentations Comme nous venons de l expliquer ci dessus nous avons men trois exp rimentations de nature et de dur es diff rentes Elles ont permis de construire valuer et am liorer notre approche Les objectifs atteindre travers les exp rimentations taient justifier la m thode en identifiant si au cours des exp rimentations un r el besoin tait ressenti et si la m thode y r pondait valuer et am liorer la compr hension et l utilisation des concepts introduits pour d finir les tapes de la m thode pratiques usages services valuer et am liorer la compr hension et l utilisation des mod les travers les outils et formalismes propos s valider la r elle adaptation des services d velopp s gr ce l
86. de ce type de services Le chapitre suivant propose une description de trois m thodes particuli res de conception de services collaboratifs pour assister des besoins m tiers Ces tudes nous ont permis de d gager les points d int r t et les limites de telles approches afin de construire notre propre m thode Chapitre 6 Travail Collaboratif Assist par Ordinateur et Services Collaboratifs 114 Chapitre 7 Les m thodes de conception de services tudes de cas Ce chapitre d veloppe trois m thodes de conception de services particuli res L objectif est de montrer l int r t et la mani re d utiliser des mod les pour mener un projet de d veloppement de services adapt s Les bases de notre proposition sont d finies en fin de chapitre en mettant en vidence les points d int r t et les limites de ces trois m thodes La premi re illustre particuli rement bien l utilisation d outils de mod lisation d di s pour diter les diff rents mod les et le passage d un mod le l autre La deuxi me met en avant la correspondance entre mod les et leurs transformations dans un cadre de r f rence d ing nierie dirig e par les mod les Enfin la troisi me est une m thode d di e au projet AIC notamment par la sp cification d objets de mod lisation du b timent 1 19 CoCSys une m thode de conception de collecticiels dirig e par des mod les Dans sa th se Olivier Delotte Delo
87. de texte dans un langage particulier et via un diteur Au travers des g n rations les langages de programmation O Regan 2008 se sont loign s du langage machine fait de 1 et de 0 pour devenir plus conceptuels et ainsi tre plus facilement manipulables et compr hensibles par les humains On parle de langages haut niveau qui peuvent tre cr s ind pendamment de la machine partir de librairies puis compil s pour diff rentes plateformes Les langages orient s objet en font partie et ont la particularit de diviser les t ches de programmation en objet ex Java C UML propose de mod liser le syst me sous forme de diagrammes de composants qui permet de montrer les composants du syst me d un point de vue physique tel qu ils sont mis en uvre Il existe plusieurs mod les qui d crivent une architecture logicielle introduisant diff rents concepts Bass et al 2003 Le mod le MVC Mod le Vue Contr leur offre un point de vue simple au travers de trois classes Figure 26 Le Mod le contient les donn es mais aussi les m thodes pour manipuler ces donn es c d ajouter supprimer r cup rer C est en quelque sorte le c ur de l application La Vue est ce avec quoi l utilisateur interagit Symboliquement parlant une vue est une fen tre sur le mod le elle pr sente une partie du contenu de celui ci La vue a aussi pour r le de capter les interactions de l utilisateur pa
88. e nous pouvons d finir les pratiques comme des actions individuelles ou collectives mais toujours dirig es vers un but conscient Bourguin amp Derycke 2005 Une action est en effet d finie comme fortement d pendante de l activit de laquelle elle d coule N B elle peut d couler de plusieurs activit s Elle est planifi e en fonction d un objectif et d une finalit Enfin elle g n re de la connaissance Tableau 11 Notre approche par rapport aux concepts de la Th orie de l Activit Th orie de Concepts Notre l activit manipul s approche de Besoins L activit ae Le projet g n raux 3 Buts F Les actions Les pratiques conscients Pour comprendre la nature de ces pratiques dans un projet AIC nous en faisons une premi re description g n rale r partie en 11 familles de pratiques 1 27 2 Les familles de pratiques ou pratiques collectives g n riques Le domaine des projets de conception construction AIC a pris ces derni res ann es un tournant important faisant l objet de nombreuses volutions Parmi celles ci il faut tout d abord prendre en compte le contexte conomique sans cesse plus contraignant La performance environnementale est galement devenue une dimension essentielle et complexe poussant les concepteurs mais aussi les techniciens innover se renouveler dans leurs pratiques Enfin il faut s assurer que la qualit architecturale du b timent n en patisse pas A
89. en adoptant plusieurs points de vue le point de vue du planificateur dans laquelle sont d finis les objectifs le point de vue du maitre d ouvrage qui d crit le contexte m tier de fa on conceptuelle le point de vue du concepteur qui d crit le syst me d information de fa on pr cise le point de vue de l ing nieur qui d crit les contraintes techniques le point de vue du constructeur qui d crit les consignes de d veloppement le point de vue machine savoir le code impl ment Zachman introduit galement une s rie de questions se poser pour d crire SI Ce questionnement est men pour chaque point de vue et donne lieu un ensemble de mod les descriptifs pour chacun d eux Il obtient ainsi un sch ma de classification en 2 dimensions pour la repr sentation descriptive d une entreprise figure 25 Les l ments qu il cherche d terminer et leurs questions relatives sont le Quoi qui d finit les donn es le Comment qui interroge les processus fonctionnels le O et le Quand qui d terminent le contexte de localisation et temporel le Qui qui d finit les acteurs et leurs responsabilit s dans l organisation et le Pourquoi qui a pour but d identifier le but les motivations Chapitre 5 De l entreprise orient e services la conception de Syst mes d Information Comme l illustre Frankel et al 2003 voir Fi
90. en cas de limites techniques ou sur la gestion des cas d erreur gt Consulte Mod les de services Mod lesde Mod les gt Produit pratiques d usages _ oy Echanges a Utilisateur Expert m tier Concepteurs D veloppeur OO a TR a Ne a _ _ Figure 141 Collaboration pour la conception de services autour de la production de mod les L importance des formalismes Notre choix s est port sur une association des mod les graphiques et des mod les textuels pour une expression des points de vue alliant synth se et pr cision Les diagrammes sont adapt s pour d crire les comportements en pr sentant de mani re synth tique les acteurs et les entit s manipul es que ce soit au niveau des pratiques m tiers comme au niveau de l usage ou encore pour la description du service Leur lecture est simple si peu d l ments les composent Afin de limiter la d t rioration de la lecture il faudra donc privil gier la d composition des cas trop Chapitre 12 La m thode PUSH exp rimentations et bilan complexes en cas simples L avantage d une approche graphique est de pouvoir lier visuellement les mod les entre eux et repr senter ainsi les liens conceptuels entre les points de vue Si les diagrammes de cas d utilisation ou de taches font parties des mod les adopt s par la communaut l utilisation des arbres hi rarchiques pour la description du m tier diff re quan
91. ensuite comment ce m ta mod le permet la mod lisation des pratiques m tiers notamment gr ce un diteur d di Elle conclut ce chapitre par l int gration de ce mod le dans un cahier d exigences Le framework pour la g n ration de l diteur partir du MMPM et la nature du cahier d exigences ont tous deux t introduits dans le chapitre pr c dent 1 27 D finitions et concepts 1 27 1 Les pratiques un nouveau d coupage de l activit de projet Au cours du 0 voirl 1 1 3 nous avons d compos l activit de projet dans le domaine AIC en phases et sous phases Figure 86 Figure 86 Figure 86 en phases et sous phases d un projet AIC Chapitre 9 La mod lisation des pratiques le point de vue organisationnel Cependant le passage d une phase a une autre reste flou il est d ailleurs souvent admis qu elles se chevauchent le d but d une phase ne marquant pas tout a fait la fin de la pr c dente De plus m me si l on connait les objectifs g n raux relatifs chaque phase il est difficile de se repr senter le d roulement exact de celles ci la combinaison des t ches tant particuli re a chaque op ration Comme on peut le lire dans Bignon et al 2009 la lisibilit des processus en cours n est pas ais e et elle est peu partag e la tra abilit des volutions du projet et des d cisions est difficile les flux d informations sont souvent interrompus
92. enter text enter a date V X X Click here to Click here to enter text enter a date V X X Click here to Click here to enter text enter a date V X X Click here to Click here to enter text enter a date PART 1 BUSINESS PRACTICES PRACTICES DIAGRAM Insert here the diagram illustrating the business practices ADDITIONAL INFORMATION Do you want to add any information about the business context and the practice to perform Click here to enter text Do you want to add any information about the information to manage artifacts activities actors Click here to enter text De PART 2 USAGE USAGE DESCRIPTION Related Individual Practice Click here to enter text Usage Objective USER INTENTIONS Insert here the use case diagram USAGE CONTEXT Temporality Choose an item User Application Click here to enter Application Choose an item Operational role text type Identification Choose an item ee PEK ere CO SNRA PENE technology Device Devisi Choose an item S Choose an item Interaction device Choose an item Connection Choose an item Annexes ADDITIONAL INFORMATION ABOUT CONTEXT Do you want to add any functional or non functional requirements about The general context of the usage You can describe here the pre conditions and post conditions of the usage It can refer to the relations with other usages Click here to enter text What do you know ab
93. entreprise orient e services la conception de Syst mes d Information 1 15 Conclusion vers des services adapt s aux pratiques m tier s Comme on peut le lire dans Emig amp Weisser 2006 la conception orient e processus m tier est la prochaine tape dans l volution de la conception logicielle elle ne remplace pas mais compl te les approches existantes Elle permet en effet de relier les aspects techniques aux besoins m tiers de l entreprise afin que ces derniers conditionnent le d veloppement logiciel En d autres termes elle apporte aux approches de GL la dimension organisationnelle de l entreprise aux besoins m tiers analys s tout comme la conception IHM apportait la dimension interactionnelle Dans les approches de conception orient es services l organisation est d compos e en services m tier squi sont support s par des servicesinfor matiquesiCT C est ce que r sume la figure suivante Figure 52 en resituant ces diff rentes approches par rapport aux diff rentes couches d une architecture d entreprise On y distingue galement les diff rents mod les qui les supportent bulles vertes n Partie Entreprise production de biens oujet de services Objectifs production Objectifs vente et productivit gain satisfaction du client Supportent Supportent Partie Client consommation de biens owet de services Business MODEL
94. existants et les habitudes de chacun Enfin il a videmment t question a travers les exp rimentations de valider la r ponse a la probl matique initiale savoir l adaptation de services propos s aux besoins m tiers PARTIE 2 tat de l art Les m thodes de conception dans divers domaines goga La conception de CRTI weB La m thode de conception suivie dans ce travail de th se Pies e dan Les concepts et la m thode de conception de services propos s Bonnes pratiques Services m tiers PARTIE 1 contexte d tude Etudes initiales le contexte tri facettes Pratiques Services Usages PARTIE 3 proposition Cas d tudes Exp rimentations Figure 142 Rappel D marche suivie dans notre recherche bas e sur la conception L approche fait preuve cependant de quelques lacunes sur plusieurs points C est ce dont nous discuterons dans les paragraphes suivants Les limites de l approche Les premi res limites sont d ordre th orique et sont relatives l exploration des divers champs de recherche Malgr une tude approfondie des m thodes de conception de service le manque d expertise initiale dans ce domaine pourra se refl ter dans l tat de l art propos Notre approche non experte a permis de prendre du recul par rapport aux r f rences du domaine et de th oriser celles ci pour en extraire une m
95. gi sur le d roulement actuel de cette exp rience Cela nous a permis d analyser l utilisation de l outil ainsi que le travail de d veloppement men pour l am liorer 1 4 Description de l exp rience L approche men e a suivi une trame de d veloppement bas e sur la notion de bonnes pratiques outiller que l on peut d couper ainsi identification des besoins m tiers et bonnes pratiques caract risation de l information manipuler proposition et d finition des services propos s par l outil pour chaque bonne pratique et d veloppement Devant la difficult de d terminer pr cis ment les fonctionnalit s utiles la collaboration consid rant les facteurs risques du projet cit s plus t t en 1 2 1 la d finition finale des bonnes pratiques mettre en place a fait l objet d un consensus entre le CRP HT et le CRTI B En ce Plaquette descriptive de la plateforme disponible sur ce lien http uat crti web com public Description de la plateforme CRTlweB pdf Chapitre 2 Un cas de d veloppement d un outil de TCAO CRTI weB sens ces pratiques consensuelles sont relatives 4 des comportements g n ralement observ s dont les deux organisations ont jug l outillage n cessaire Nous introduisons ici le concept de service jusque l non voqu Cette notion que nous d taillerons plus tard permet de d finir les fonctionnalit s d un outil aussi bien d un point de vue
96. interaction type Selection 1_n Is composed of Is composed of gt then dowload activati a SR name crti web document notification identification Concrete user interactin type Trigger P terat with Abstract user interaction type Input Ociok J then Fie selection Name Documents P interact with Concrete user interactin type Selection lan ypo Graphical spec Icon label progress bars checkbox tren So Name Document name Attributes Name file type Loading visualization Data type fie Graphical spec text fields and combo boxes Attributes primitive data Graphical output Data type text gt then Clustering mode selection Validation gt then Concrete user interactin type Trigger Concrete user interactin type Trigger Figure 107 Diagramme d interaction d composant l intention upload multiple files Les maquettages Le maquettage permet de repr senter l interface attendue a un instant pr cis sans perdre de temps dans les d tails graphiques Le maquettage est un mode de mod lisation compl mentaire au diagramme d interactions pour instancier une partie de notre m ta mod le d usage Il permet en effet d illustrer les t ches concr tes qui ont t sp cifi es comme le montre la Figure 108 Le risque li maquettage est de le faire intervenir trop t t dans le processus de conception Cela a pour cons quence de limiter la conception
97. introduites Cependant il est possible que la perte d information ou une m sinterpr tation puisse engendrer un manque d adaptation de la solution par rapport au besoin voire un chec du projet de d veloppement Le but de I IDM est de pouvoir automatiser l impl mentation c d la g n ration du code en r duisant au maximum l intervention humaine dans l interpr tation de l analyse et la conception L IDM se distingue des m thodes de mod lisation traditionnelles par la pr occupation constante de rendre les mod les productifs plut t que contemplatifs Favre 2004 Les mod les qualifi s de contemplatifs sont utiles pour la communication et la compr hension mais ne sont pas utilis s pour produire du code ce qui reste l activit de l informaticien Un mod le devient productif lorsqu il est rendu interpr table et manipulable par une machine Ainsi PIDM simplifie le travail des ing nieurs du d veloppement logiciel en leur permettant de ne plus manipuler du code impl menter mais des mod les de code savoir des descriptions crites dans un langage adapt On dira que le niveau de mod lisation du code est le niveau 0 ou MO Il peut tre conforme plusieurs mod les de niveau M1 eux m mes d finis par des m ta mod les le niveau M2 qui s appuient enfin sur un m ta m ta mod le le niveau M3 L IDM englobe plusieurs contextes de travail avec leurs propres concepts et langages ainsi que
98. l activit collective c 1 1 4 nous avons introduit le fait que celle ci puisse servir la conception des outils qui le m diatise Pour cela nous avons choisi d isoler l analyse et la caract risation de ces outils pour ensuite identifier ce qui d finit la mani re dont ils s adaptent au contexte Chapitre 1 La coordination dans les projets de conception construction architecturale Des tudes ont montr qu ce contexte de l activit collective se greffent deux autres contextes relatifs aux actions individuelles de l acteur le contexte acteur et le contexte utilisateur Nous parlons alors d un contexte tri facettes C est par rapport l ensemble du contexte tri facettes que nous devons consid rer la conception d un outil car c est cette combinaison qui d finit le mieux les besoins des acteurs dans leur globalit Or la qualit percue des outils est troitement li e a leur capacit a r pondre a ces besoins D s lors deux approches de conception se distinguent une approche top down selon laquelle on cr e les outils en fonction des besoins c est un processus d ing nierie classique une approche bottom up pour laquelle les outils sont cr s dans un processus d innovation technologique puis transf r s vers un ou plusieurs secteurs d utilisation avec une ventuelle adaptation on parle de r tro ing nierie Au cours du chapitre suiv
99. l adaptation des services de DropBox Chapitre 12 La m thode PUSH exp rimentations et bilan Le push innovation Le push innovation est bas sur la cr ation de nouveaux contextes que ce soit d un point de vue m tier ou technologique En d autres termes on cherchera a faire merger de nouvelles pratiques ou de nouveaux usages par la conception de services La proposition d un Tableau de bord sur tablette tactile et profitant de la g olocalisation pour assister la coordination d un chantier tait typiquement synonyme d une volont d innovation Le risque dans un tel cas de figure est cependant de ne pas mesurer les limites qu il faudra franchir pour d velopper le service voulu Chapitre 12 La m thode PUSH exp rimentations et bilan 246 Conclusion et perspectives Le travail d crit dans cette th se a port sur deux points essentiels l analyse m tier et la conception de services informatiques Nous avons mis en avant les relations qui existaient entre ces deux points travers la mod lisation et afin de r pondre une probl matique la conception de services collaboratifs adapt s aux pratiques d un projet AIC Concevoir une m thode de conception recul sur une approche orient e design science Le cycle it ratif compos des phases connaissance suggestion d veloppement valuation et conclusion a t suivi dans la conception de la m thode propos e Fi
100. l information g n r e par les autres outils et faisant tat du d roulement du projet La m diatisation de la coordination dans les activit s pr paratoires Comme nous l avons d fini les activit s pr paratoires sont relatives la conception et sont essentiellement bas es sur la mise en commun d information Le sch ma suivant issu de Hanser 2003 illustre cela par les ph nom nes de conception distribu e et de co conception Co conception Co conception Etape d un processus Conception distribu e Dur e du projet D finition des Synth se et objectifs et d finition des d coupage du N nouveaux travail objectifs Figure 7 Processus de conception alternant conception distribu e et points de synth se tir de Hanser 2003 Malgr l ajustement mutuel qui caract rise la conception la tra abilit des choix et des activit s reste un atout et un besoin notamment lors de la mise en commun et la synth se des propositions Les outils qui assistent la coordination en phase chantier r pondent galement aux besoins de la conception Les outils de calendrier partag permettent de fixer des dates limites des rendez vous d organiser des v nements et notamment planifier les points de synth se Les outils de partage permettent de diffuser des documents L int gration dans les outils de production permet l dition par plusieurs acteurs On trouve ce genre de fonctionnalit s p
101. l utilisateur mais du syst me qui r pond son besoin Les concepts introduits et leur caract risation permettent individuellement de cadrer et formaliser par des mod les graphiques la description des diff rents comportements a des fins analytiques Dans un but productif nous proposons la m thode PUSH Practices and Usages based Services enHancement qui orchestre ces diff rents points de vue et permet de g n rer un ensemble d exigences pour le d veloppement de services dits adapt s Communication et tra abilit sont les maitres mots de cette m thode de conception Le contexte d tude a la fois orient recherche et d veloppement cr au travers de la collaboration entre le CRAI a Nancy et le CRP Henri Tudor Luxembourg nous a permis d valuer et d am liorer la d finition des concepts mis en avant ainsi que la mise en place de la m thode PUSH L am lioration des services du collecticiel CRTI weB a fait l objet de deux cas d tude Un troisi me cas concernait le d veloppement d un tableau de bord de gestion de chantier sur interface mobile Mots cl s Construction Collaboration Services informatiques G nie Logiciel Interfaces Homme Machines Conception centr e usages Science de la conception Sommaire Liste des abr viations et acronymes Introduction Une th se a la crois e des chemins entre sciences de l architecture et g nie logiciel Probl matique g n rale Plan de la
102. l ments du r cit pour avoir une homog n isation lexicale processus de transformation Par exemple le verbe recevoir dans le premier sc nario devient t l charger Nous retrouvons ici au travers des propos de l auteur la n cessit d op rer une transformation entre une description m tier recevoir et relative un outil t l charger Nous pensons qu il est n cessaire de traiter deux mod les diff rents plut t que d adapter le m me mod le La m thode CoCsys propose des phases de transformation structur es qui de l analyse des besoins la sp cification de l architecture de l outil permettent de justifier chaque tape en retra ant le processus de d veloppement Pourtant le passage des sc narios au mod le comportemental n est pas syst matique Les mod les de sc nario contextualis et comportemental sont instanci s partir de m ta mod les le MMSC et le MMC Cependant on ne distingue pas le lien entre ces deux m ta mod les Il aurait t int ressant de pouvoir mettre en correspondance le MMSC au MMC pour formaliser le passage d un mod le un autre Chapitre 7 Les m thodes de conception de services tudes de cas En ce qui concerne la deuxi me phase de transformation son applicabilit dans divers cas n est pas v rifi e dans la th se analys e Des travaux scientifiques ult rieurs la th se analys e comme Yin 2010 ou Bain et al 2009 r utilisen
103. la conception de Syst mes d Information de mettre les capacit s au service des besoins L valuation de la QoS contribue l valuation globale de l entreprise elle fait partie int grante de la gestion des entreprises Cardoso et al 2004 Utilisent Utilisateurs Fournissent consomment Services composites m tiers D composition et Orchestration Processus services m tier Informatis s par ccom GBB BRR Support s par Infrastructures et applications Figure 44 Services m tier et ICT dans la SOA D finition d un service m tier L et al 2010 propose un langage de description des services m tiers nomm BSDL pour Business Service Description Language inspir des travaux de Justin O Sullivan et son quipe sur la description des capacit s et propri t s d un service O Sullivan 2006 Oaks et al 2003 Il illustre ce BSDL par un m ta mod le UML dont les concepts principaux sont les suivants le fournisseur ou prestataire entit m tier entreprise organisation individu produisant et fournissant le service le demandeur ou client ou consommateur entit m tier entreprise organisation individu demandant le service la capacit c est ce que le service fait Les capacit s d un service ont des r gles savoir des effets et des pr conditions Elles poss dent une dur e et une date d ex cution Elles sont d crites lexic
104. la gestion des d pendances entre les activit s Dans le cas d une coordination dite collaborative le livrable d une t che est une version du produit final Dans ce cas chaque acteur participe pleinement la r solution de l objectif c est un travail d gal gal Lors de la mise en commun l change entre les diff rents acteurs est fort et le travail individuel devient difficilement identifiable Le travail collaboratif ne rel ve pas d une r partition priori des r les Piquet 2009 il s agit de la r solution commune d un probl me Sylvain Kubicki 2006 Si la coordination est coop rative chaque t che donne lieu une partie du produit final ces parties tant ensuite assembl es Cela n cessite une attribution pr cise de chaque t che un acteur en fonction de son r le voir 1 1 1 L change est faible et chacun est responsable de sa t che dans un groupe hi rarchiquement organis Les ressources sont galement attribu es ind pendamment pour chaque t che Le passage d une situation collaborative une situation coop rative est d ailleurs perceptible au cours des phases d un projet AIC La collaboration est relative aux activit s conceptuelles on l observe par exemple en phase esquisse lorsqu une quipe de concepteurs con oit le b timent partir du programme Chacun en fait sa propre interpr tation et propose sa version du b timent envisag La coop
105. les de t ches utilisateurs bas s sur des arbres hi rarchiques CTT et K MAD D apr s Mori et al 2002 une t che d finit comment l utilisateur peut atteindre un but dans un domaine sp cifique d application le but tant une modification d sir e de l tat d un syst me ou une requ te ce syst me Les auteurs distinguent quatre types de t ches auxquelles ils attribuent un l ment graphique particulier pour cr er leur propre formalisme d arbre de t ches nomm CTT ConcurTaskTree et support par un diteur d di CTTE les t ches utilisateur cognitives ou physiques enti rement ex cut es par l utilisateur sans interaction avec le syst me les t ches application enti rement ex cut es par le syst me ex la notification les t ches d interaction ex cut es par l utilisateur en interaction avec le syst me les t ches abstraites qui ne sont aucune des autres t ches mais sont d composables en plusieurs d entre elles Les diff rentes t ches sont li es entre elles de mani re repr senter leur chronologie Ainsi deux t ches peuvent tre ind pendantes ou synchronis es une t che peut autoriser la suivante ou d sactiver la pr c dente elle peut tre it rative r cursive voire optionnelle Pribeanu 2005 y ajoute galement la notion de couche fonctionnelle ind pendante de la plateforme et de couche op rationnelle d pendante de la plateforme
106. les services sp cifier c est le point de vue fonctionnel attribu aux d veloppeurs Il s agit de tirer profit du contexte acad mique et professionnel de cette tude pour d finir ces concepts puis de fournir les outils pour les d crire Ces descriptions sont conformes un m ta mod le le M ta Mod le des Services Adapt s MMSA Elles sont consign es dans un cahier d exigences qui assure le suivi du processus et la tra abilit des choix pendant et apr s le projet de d veloppement Les chapitres suivants Chapitres 9 10 et 11 d taillent chacun des trois points de vue les concepts associ s leur m ta mod le et leur description selon des formalismes adapt s Chapitre 8 Introduction de la proposition Chapitre 9 La mod lisation des pratiques le point de vue organisationnel Ce chapitre est compos de trois sections La premi re pr sente le concept de pratique tel que nous le d finissons pour repr senter les comportements de professionnels dans leur contexte de travail collaboratif et observ s lors d une analyse m tier La caract risation de ces pratiques est li e au domaine AIC qui est le domaine d application de cette tude La deuxi me section pr sente la construction du m ta mod le des pratiques m tier MMPM qui supporte cette caract risation par diff rents concepts Le formalisme utilis pour le MMPM est le diagramme de classes UML La troisi me section montre
107. lisation notamment au cours des deux phases de sp cification des besoins de la branche fonctionnelle sp cification conceptuelle des besoins sp cification organisationnelle et interactionnelle des besoins Ce lien n est en effet pas explicite dans la m thode Symphony Typiquement si l on reprend la description faite pr c demment de la sp cification organisationnelle et interactionnelle il est question par exemple de d finir comment le sp cialiste GL identifie des cas d utilisation partir des descriptions pr c dentes des processus m tiers puis raffine les concepts m tiers en composants fonctionnels Cette correspondance est voqu e mais n est pas d taill e L enjeu est d utiliser les mod les ad quats adapt s aux besoins de repr sentation correspondants au point de vue de chaque sp cialiste Nous pensons que la collaboration des diff rents sp cialistes mise en avant dans la m thode Symphony est un point important consid rer La illustre cette collaboration au cours de la phase sp cification organisationnelle et interactionnelle Elle d bute par une activit commune de d composition des processus m tiers pendant laquelle les acteurs d crivent l tat de la situation aussi bien d un point de vue m tier que technique Puis les sp cialistes de chaque domaine mod lisent leurs pr occupations ensemble ou s par ment les besoins fonctionnels par le sp cialiste GL et les besoins en termes d
108. m tier par l emploi d un outil nous utilisons le terme d usage plut t qu utilisation car il couvre une d finition plus large que celle du simple emploi On cherche retrouver en plus de la notion d emploi les notions d habitude d objectif et d appropriation par les acteurs Glossaire Index A architecture dirig e par les mod les 88 89 C cahier d exigences 154 155 156 159 180 196 199 200 214 215 224 231 235 243 244 251 300 CoCSys 121 122 127 collecticiel 112 114 115 116 117 118 139 154 191 285 conception centr e usage 75 76 79 80 contexte acteur 41 42 53 contexte coop ratif 33 34 114 115 171 174 179 181 187 188 206 253 304 contexte de l activit collective 54 contexte tri facettes 42 53 56 contexte utilisateur 41 42 49 54 127 130 146 189 D diagramme de s quences 83 220 305 E entreprise orient e service 95 G GMF 21 151 152 176 177 178 179 197 Information Delivery Manual 134 135 M maquettage 38 86 198 244 248 249 mod le de pratiques 176 177 179 192 251 mod le de t ches 81 MVC 70 71 118 119 120 132 208 P pratiques m tiers 1 25 149 153 159 183 184 186 198 199 205 219 222 248 249 250 253 300 301 Processus m tier 102 push PUSH 154 184 252 R RUP 63 84 103 104 107 117 118 154 203 S scenario 66 82 83 service ICT 98
109. management et le fournisseur supply chain On peut y lire que l quipe de conception Chapitre 7 Les m thodes de conception de services tudes de cas con oit son b timent en utilisant des produits qui sont d velopp s par les fabricants qui valident et estiment le prix de ces derniers Le coordinateur doit assister ce processus Figure 73 Vue d ensemble d un processus Berard amp Karlshog 2012 Dans le cadre de l utilisation d un service d ouvrages virtuels Virtual Building Product VBP travers le BIM les actions m tiers identifi es dans le processus sont d compos es pour former un nouveau processus qui d crit le service utilis Charles Eastman amp Sacks 2010 utilise le terme cas d utilisation Dans l exemple d crit ci dessous Figure 73 l action Design Building est d compos e en cinq actions load VBP Choose size and type Validate ease of manufacturing Insert into model et Update design model Figure 74 Notons que l action validate ease of manufacturing se fait automatiquement l acteur responsable est le service virtual building product lui m me en fonction de r gles pr d finies E01 Virtual Building Conceptual Design Products Figure 74 Cas d utilisation du produit virtuel Berard amp Karlshoej 2012 Chapitre 7 Les m thodes de conception de services tudes de cas L enjeu es
110. manipul e Les inputs correspondent aux t ches concr tes d interaction et les outputs aux t ches de perception La donn e a t d finie au travers du concept d objet d interaction ObjectiF texte C mat rialise Service m tier Type_r le_op texte 1 Identification oui non a repr sente action texte donn e texte 1 1 cofespand Nom donn e texte Interaction tl EE Type_donn e num ration ttributs texte EL Forme texte 1 QS Tache utilisateur concr te 1 int ragit avec pe Tache utilisateur abstraite Figure 112 Caract risation du service concepts en bleu mat rialisant l usage concepts en rouge Chapitre 11 La mod lisation des services le point de vue fonctionnel 1 36 2 Les composants du service CT Nous d crivons le service ICT comme un ensemble de composants logiciels qui communiquent entre eux Cette architecture peut tre caract ris e par un mod le d architecture logicielle Nous avons introduit pr c demment les mod les d architecture logicielle et particuli rement ceux d di s aux collecticiels cf 1 16 3 Nous avons tendu l un deux le mod le MVC pour y inclure la composante collaborative cr ant ainsi le mod le Co MVC Figure 113 Ainsi dans la caract risation du service le Mod le caract rise les donn es et les m thodes pour manipuler ces donn es par exemple ajout
111. mod ration r actions commentaires management facilit Convention de 329 CN ajout par chargement contenu fichier Contenu nommage import e par Proposition de l upload multiple Partage de documents Choix entre Fichier ou Choix accord entre 2 335 optionnelle tant t individuellement Contenu groupe de fichier fonctionnalit s Ajout librairie PHPExcel n cessaire pour 345 importation m tadonn es en lot depuis Destin aux d veloppeurs A la cr ation d une remarque le cadre de 351 description est beaucoup trop petit D tail graphique Lorsqu une personne est ajout e pour la diffusion du compte rendu elle est Partager un CR avec les obligatoirement Pr sente Absente ou collaborateurs de son Limiter l information Suppression d une fonctionnalit 352 Excus e nous voudrions qu il soit choix Contenu apport e la diffusion inutile Suppression priorit par d faut d une Limiter l information Suppression d une fonctionnalit 353 remarque Contenu apport e une inutile Cacher l administrateur de la listes des 369 personnes pr sentent dans l annuaire des NIL Suppression d une information Permettre de trier les remarques par date Retrouver les remarques Tache Nouvel usage de Meilleure compr hension gain de 387 de cr ation ou par organisme i faites sur un CR contenu recherche des temps Le filtrage des remarques associ es 389 plusieurs organismes ne devrait faire
112. observ es dans des projets de conception construction collaborative gr ce aux concepts qu il d finit leurs attributs et aux relations qui les relient Il s agit en d autres termes d instancier ce m ta mod le unique en autant de mod les de pratiques que de d analyses effectu es Chapitre 9 La mod lisation des pratiques le point de vue organisationnel Pour cela il s agit d utiliser des formalismes adapt s et les outils d dition qui conviennent Tel que cela a t introduit en 1 24 1 nous avons utilis le framework GMF de l outil de d veloppement Eclipse pour cr er notre propre diteur de mod les 1 29 Le mod le de pratiques Le mod le de pratiques est une repr sentation conceptuelle de pratiques observ es au travers d une analyse m tier Il utilise les concepts du MMPM qu il repr sente dans un formalisme particulier Nous proposons pour cela notre propre formalisme et notre propre diteur 1 29 1 Critique d un formalisme existant La Figure 91 issue de travaux pr liminaires Zignale et al 2011 illustre un premier essai de mod lisation d une pratique collective PC que nous avons r alis e celle de l valuation des documents de conception par un expert Dans cette PC le concepteur fournit les documents de conception au ma tre d ouvrage qui les soumet un expert pour valuation Souvent le ma tre d ouvrage d l gue sa pratique un assistant la ma trise d
113. ouvrage qui poss dera davantage de comp tences pour cela Le formalisme qui a t utilis ici est le diagramme d activit s UML PC PI et op rations sont des actions que l on distingue graphiquement La PC couvre tous les acteurs alors que chaque Pratique Individuelle PI qui la compose se situe dans la swimlane d un acteur en particulier Il en va de m me pour les op rations Ce diagramme illustre galement les flux d artefacts engendr s ou simplement manipul s par les op rations Suite cette exp rimentation nous constatons que le diagramme d activit s n instancie qu une partie notre m ta mod le de pratiques tous les attributs de chaque classe ne sont pas trait s ex les types d artefacts les familles de pratiques et les types num r s ne sont pas utilis s De plus la distinction entre certains l ments doit se faire manuellement Par exemple les PC les PI et les op rations sont ici toutes repr sent es par des actions en langage UML Il est n cessaire pour les distinguer lors de leur mod lisation de sp cifier leur st r otype et de modifier leur aspect graphique Il en va de m me pour les artefacts qui sont tous indistinctement des objets Le m ta mod le du diagramme d activit s et le MMPM tant diff rents le diagramme d activit s ne permet donc pas une bonne instanciation du MMPM La mod lisation des pratiques de chaque acteur dans un m me mod le en
114. par deux classes l acteur simple et le groupe d acteur Le type d acteur simple type acteur simple est relatif son m tier Les choix possibles sont architecte urbaniste ing nieur structure ing nieur s curit ing nieur sant chef d entreprise ma on lectricien comptable secr taire autre Le type de groupe type acteur groupe est relatif au statut administratif du groupe agence bureau d tudes entreprise laboratoire organisation publique autre Tout acteur simple ou groupe joue un r le dans le projet c est ce qui a t d fini comme le r le organisationnel type r le On distingue les r les suivant Concepteur Dessinateur Graphiste Coordinateur Ma tre d ouvrage Constructeur conomiste Conseiller Expert Administration autre L attribut d nomination servira apporter des distinctions entre acteurs comme par exemple entre le dessinateur des fa ades et le dessinateur des plans Sous le concept d activit on retrouve les t ches de type type activit t che conception construction et coordination les phases de type type activit phase pr paration conception ex cution et livraison ainsi que la caract risation du projet lui m me par son type type _activit projet logement individuel logement collectif ou b timent public ainsi qu une ventuelle certification vis e HQE BREEAM MI
115. par un service service inutile manipule engendre Message engendre f Communication Groupe d artefacts type_groupe texte concerne Acteur simple Groupe d acteurs Diffusion lt lt enumeration gt gt lt lt enumeration gt gt lt lt enumeration gt gt lt lt enumeration gt gt Type_op ration r cup ration Type_op ration diffusion Type_op ration production Type_op ration communication obtenir partager cr er contacter consulter rendre indisponible ex cuter valider identifier modifier demander v rifier r parer commenter Hier informer inclure mettre jour supprimer Figure 89 M ta mod le complet des pratiques m tiers MMPM A ce niveau de d tail nous avons souhait manipuler une suite exhaustive d op rations types pouvant d finir un maximum de situations Les diff rentes op rations que nous avons identifi es dans chacune des familles sont pour les op rations de communication contacter demander valider commenter informer pour les op rations de production cr er ex cuter modifier r parer lier inclure mettre jour supprimer pour les op rations de diffusion partager et rendre indisponible pour les op rations de r cup ration obtenir consulter identifier v rifier
116. plans les descriptifs textes les photos ainsi que les objets c d les ouvrages ou l ments d ouvrages architecturaux Collecticiel Le collecticiel est un logiciel d di au support de l activit collective que ce soit par l assistance la communication la coordination ou la co production de mani re synchrone ou asynchrone co localis e ou distance Contexte Le contexte est un ensemble de circonstances d termin es par un environnement ou une situation et d terminantes dans le comportement de quelque chose ou quelqu un M thode de conception Une m thode de conception est un processus cr atif it ratif compos de plusieurs tapes la connaissance du besoin la suggestion la proposition la validation et la conclusion Elle est support e par mod les et des outils et associe plusieurs points de vue Glossaire Mod le Un mod le est la repr sentation de quelque chose travers sous forme d objet physique ex une maquette ou de description un texte un dessin Un mod le peut servir a la description ex le plan d une ville comme la conception ex le plan d une maison construire Un mod le abstrait ce qu il repr sente travers des concepts Outil Physique ou num rique l outil assiste son usager dans l ex cution d une ou plusieurs t ches L adaptation d un outil se mesure par son utilit sa capacit r pondre au besoin de l usage
117. pour chaque package La cr ation du diagramme d interactions pourrait tre assist e de la m me fa on Dans une derni re tape la m thode PUSH pourra ainsi servir d input une approche g n rative comme Cam l on Calvary et al 2003 Il s agira alors de r duire la phase 3 de sp cification du service par la g n ration automatique de code avec une intervention limit e des d veloppeurs Conclusion et perspectives D un autre cot la prise en compte des exigences non fonctionnelles et leur int gration dans le processus d dition des diff rents mod les est galement envisager pour parvenir a des sp cifications qui soient contractuellement pertinentes Il en va de m me pour les crit res ergonomiques qui seront int grer pour proposer des solutions satisfaisantes en termes d utilisabilit La m thode trouvera aussi sa place dans la tendance actuelle de gestion de projets de construction bas e sur la maquette num rique BIM Comme abord e dans le chapitre 7 section 1 21 l approche BIM a deux composantes l utilisation partag e d outils de maquettes num riques centralis es ou d centralis es d une part et la mise en place de pratiques collectives ma tris es et am lior es d autre part L effort de standardisation entrepris depuis une quinzaine d ann es a conduit la normalisation d un standard de description des ouvrages IFC ISO 16739 2013 Cependant la description des p
118. pr conis d utiliser des repr sentations graphiques simples plut t que des mots ainsi que de simplifier la structure des t ches afin de limiter le recours de l utilisateur sa m moire Toute erreur dans un processus de t ches doit pouvoir tre corrig e Un syst me dit centr utilisateur ne n cessite pas de manuel d utilisation tr s toff il se veut intuitif Le tableau suivant Tableau 5 pr sente quelques techniques et objectifs relatifs a l implication du client au travers des phases d un cycle de projet de d veloppement logiciel Sont signal s en rouge les apports des m thodes enrichies par rapport aux m thodes traditionnelles de G nie Logiciel GL 14 Le terme affordance vient du verbe to afford offrir fournir procurer est d signe la capacit d un objet sugg rer sa propre utilisation Chapitre 4 De l utilisateur la conception logicielle et d interfaces Tableau 5 Implication de l acteur en tant que client et utilisateur Technique But Phase Groupe de travail Connaitre les exigences du tudes pr liminaires client Groupe de travail Connaitre le domaine tudes pr liminaires obser vations utilisation Groupe de travail Connaitre les taches m tier Etudes pr liminaires obser vations qu il faut accomplir Interviews et Connaitre l utilisateur et ses Etudes pr liminaires questionnaires pr f rences Obser vations sur site Connaitre le context
119. qui visent expliquer des l ments existants de la nature ou de la soci t La science de la conception consiste en la construction et l valuation de produits de quatre types des concepts des mod les des m thodes et des instanciations March 1995 Chapitre 3 Probl matique et m thode de travail les concepts forment le vocabulaire d un domaine un mod le d crit une situation en exprimant les relations entre les concepts une m thode est une suite d tapes suivies pour accomplir une t che une instanciation est la r alisation d un artefact dans son environnement Atteindre un but un objectif ne se fait pas sans contraintes qu elles soient physiques contraintes techniques g ographiques m t orologiques ou morales en termes de qualit de d lai de prix Concevoir c est donc obtenir une solution qui satisfasse un maximum de ces contraintes ce qui implique de les connaitre de les valuer voire de les prioriser Comme on peut le voir dans Peffers et al 2007 les mod lisations de l activit de conception sont vari es mais suivent une trame commune Nous retenons l approche de Vaishnavi amp Kuechler 2007 qui nous apprend que la conception est non seulement bas e sur un processus mais aussi sur la production d information et d artefacts et la g n ration de flux de connaissances Figure 15 Le processus d fini par Vaishnavi amp Kuechler 2007 contient
120. ration est observable lors d activit s de formalisation ou d ex cution comme le montage de APD par exemple Les t ches comme le dessin des plans des fa ades des coupes la r alisation des perspectives etc sont alors r parties individuellement selon les r les de chacun Le concepteur alors sup rieur hi rarchique supervise les t ches Il en va de m me sur le chantier chacun tant responsable d un l ment de l ouvrage construire Qu elles s inscrivent dans une collaboration ou une coordination les t ches peuvent tre typ es en fonction de leur nature et de ce qu elles servent accomplir Hanser 2003 identifie trois types les t ches de production qui consistent la manipulation d objets en conception les t ches de synth se qui sont de l ordre du d cisionnel comme la validation ou le vote les t ches de coordination qui sont de l ordre de l organisationnel avec la gestion des ressources des phases de travail du personnel 1 1 4 Conclusion Le sch ma suivant Figure 2 issu de Guerriero 2009 retrace l volution des concepts que nous venons de d crire composant le contexte coop ratif dans les travaux pr c demment men s au sein du laboratoire CRAI Chapitre 1 La coordination dans les projets de conception construction architecturale 1 i l I I Document _ Acteur Objet Acteur Artefact Acteur anis Relations Relations CC a B
121. rement mon coll gue et ami Conrad Boton pour sa bonne humeur mais aussi son soutien et son aide pr cieuse Les longues discussions qui ont r guli rement ponctu nos travaux de th se respectifs ont toujours t tr s enrichissantes Nombreux sont mes coll gues avec qui j ai pu partager de tr s bons moments au cours de cette th se et qui y ont contribu m me indirectement Quelques noms parmi tant d autres qui ont ma reconnaissance et ma sympathie Jean S bastien Thomas Alain Gerald C dric Jocelyn Elio Carine K vin Anis R sum Dans le domaine du projet de conception construction architecturale la gestion de la collaboration entre les diff rents acteurs d un projet est un enjeu important D un projet a un autre en fonction du projet mais aussi des acteurs qui y interviennent les pratiques de travail varient Parall lement de nombreux services sont propos s et utilis s pour assister la collaboration certains sur un mod le grand public et d autres plus orient s vers un usage professionnel L exp rience CRTI weB est un projet de d veloppement d un collecticiel men avec et pour les professionnels du secteur au Luxembourg Il propose actuellement deux services dans sa version commerciale le service d changes et gestion de documents plans documents techniques et le service de r daction et gestion des rapports de chantier Malgr l tude des besoins m tiers men e en amont du d
122. rent tant donn que le d veloppeur ne connaissait pas du tout l outil La collaboration s est galement effectu e autour de r unions de synchronisation pour l analyse des besoins et les choix conceptuels Ce contexte a donc favoris l application de la m thode dans son ensemble en prenant le temps de r aliser tous les mod les attendus En effet cette demande faisait partie des exigences de l quipe vis vis du d veloppeur stagiaire et n aurait pas pu tre attendue d une quipe de d veloppement soumise Chapitre 12 La m thode PUSH exp rimentations et bilan des objectifs de rentabilit comme celle intervenant dans l exp rimentation n 1 Les d veloppements ont donc t davantage suivis et trac s valuation de la pertinence L int r t de la m thode r side pour ce cas d tude dans la possibilit d identifier et sp cifier un nouvel usage plausible et qui illustre bien l impact de la variation du contexte m tier Apr s avoir identifi les op rations essentielles m diatiser autrement que par l usage classique CRTI weB par l interface web un usage alternatif plus simple a t con u Lors de l implication d un nouveau membre dans un projet de d veloppement ici le d veloppeur les risques li s au manque d information et l incompr hension des besoins sont plus importants L application de la m thode pour mener ce projet a permis de r duire ces risques e
123. s des documents utilis s et des activit s phases et t ches dans lesquelles la pratique s inscrit Nous nous sommes inspir de l ouvrage 140 s quences pour mener une op ration de construction des tudes pr alables l ach vement de l ouvrage actions techniques et d marches administratives Armand 1997 pour mener cette synth se PCI choix et valuation du site Description le Ma tre d ouvrage MO d finit la nature de l ouvrage et justifie le choix du terrain de par l impact physique et social qu aura l ouvrage mais aussi en analysant le contexte urbain quipements services Il s interroge galement sur les quipements compl mentaires n cessaires Le site doit faire l objet de plusieurs analyses de la part du Ma tre d Ouvrage nuisances risques d inondation possibilit s d alimentation et d vacuation nature du sol acc s qui se d roulent avant et pendant les premi res phases de la conception Il est galement n cessaire de recueillir aupr s des services ad quats mairie ou administration communale http www minergie com home_en html http assohge org hqe Jhttp www breeam or http www dgnb de _en ET Chapitre 9 La mod lisation des pratiques le point de vue organisationnel services techniques op rateur de t l phonie fournisseurs d lectricit de gaz compagnie des eaux l ensemble des renseignements concernant la viabilit
124. s jour et les dates du 14 au 19 novembre Elle s lectionne parmi une liste d h tels le Royal Park Inn Chapitre 4 De l utilisateur la conception logicielle et d interfaces Ce type de mod lisation litt rale semble cependant plus adapt e pour d crire des buts des intentions et des taches relativement abstraites que des taches d interaction ce qui parait long et fastidieux De plus alors qu un sc nario s int resse un utilisateur en particulier il serait plus int ressant d abstraire un sc nario type relatif un type d utilisateur que l on aura identifi A cet effet Constantine utilise le cas d utilisation use case Dans Constantine 2001 il en distingue deux types le cas d utilisation concret concrete use case et le cas d utilisation essentiel essential use case aussi appel task case Le concrete use case introduit un premier niveau d abstraction ainsi on ne dira plus Paul crit son pseudo et son mot de passe dans les champs du formulaire et clique sur soumettre mais l utilisateur renseigne ses identifiants l aide d un formulaire et les soumet L essential use case est encore plus abstrait il est compos de t ches du type donne son identification Comme on peut le voir dans Constantine 2001 un essential use case est d fini comme repr sentant des petits morceaux d ex cution d un r le utilisat
125. sa gestion Comme nous pouvons le lire dans Guerriero 2009 un mod le sp cifique a t d fini prenant en compte les concepts particuliers de gestion de chantier autour du compte rendu et de la gestion documentaire Un compte rendu est li une r union de chantier r sumant les informations relatives celle ci et permettant de garder trace de ce qui s y est dit Une r union de chantier est en g n ral pr c d e d une visite de celui ci permettant de relever les l ments dont il faudra discuter Ainsi le compte rendu de chantier contient un ensemble d informations structur es sous la forme de rubriques Les r f rences servent l identification d un compte rendu comme un num ro une date de cr ation le nom de l auteur Ces r f rences sont notamment tr s utiles lors d une recherche par filtrage de m tadonn es La liste de pr sence et de diffusion contient les personnes pr sentes la r union de chantier et qui il faudra diffuser ce rapport Les g n ralit s font tat de la situation du chantier et des ressources sur le site Elles identifient notamment les interruptions dues aux conditions m t orologiques Les notes sont des r gles suivre et des clauses qui s appliquent chacun elles sont d finies en d but de projet et ne changent en g n ral pas en cours de projet La liste des remarques soul ve les points particuliers dont on aura parl pendant la r union
126. ses futurs utilisateurs Nous pensons que l interaction peut avoir un r le majeur dans la conception de services La troisi me et derni re approche consid r e dans ce chapitre sur les m thodes de conceptions concerne la conception de services sp cifiques au secteur AIC bas e sur l change d information et l utilisation de maquettes num riques BIM 1 21 L IDM Information Delivery Manual pour la conception de services BI M 1 21 1 BIM IFC IDM une br ve introduction La mod lisation des informations du b timent plus commun ment maquette num rique ou BIM Building Information Modeling a pour but d agr ger les donn es relatives un b timent en un mod le unique orient objets les ouvrages du b timent Ibrahim amp Krawczyk 2003 Le BIM permet ainsi d am liorer la compr hension du b timent nature des ouvrages quantit de mat riaux et des processus mis en uvre Les outils associ s supportent les changes d information dans les activit s de conception et construction architecturale Le mod le IFC Chapitre 7 Les m thodes de conception de services tudes de cas Industry Foundation Classes r cemment renomm Information For Construction est un format de donn es standardis et ouvert d velopp pour favoriser l interop rabilit dans les approches BIM Chaque objet IFC propose une sp cification de l information relative au projet consid r tout au long du c
127. thodologie g n rale Cependant on pourra reprocher cette tude de ne pas entrer dans les d tails notamment techniques et relatifs au d veloppement Il est important de rappeler que l approche propos e n a pas la pr tention de vouloir g n rer des services adapt s la mani re des approches MDA La mani re de typer les t ches et les donn es que nous proposons est une premi re tape dans cette optique mais cette r flexion n a pas t prouv e Notre approche fournit par contre les l ments n cessaires en vue d am liorer la sp cification de services dans le cadre d un projet de conception logicielle classique L attention a notamment t port e sur la gestion et la coordination des diff rents points de vue au cours du processus de conception de services Trois exp rimentations ont t men es afin de valider la proposition formul e Cependant on pourra se demander dans quelle mesure les m ta mod les ne seraient pas perfectibles et am liorables par leur instanciation dans d autres cas d tudes Il serait int ressant de les tester de Conclusion et perspectives mani re tendue jusqu ce qu ils se stabilisent pour ainsi valider leur pertinence de mani re repr sentative pour l ensemble des projets Il faudra pour a survoler un panel d exp rimentations plus tendu tendre les exp rimentations permettra galement d valuer l appropriation d une telle approche pa
128. travers des composants r utilisables Puis le point d entr e de la conception logicielle s est d plac des niveaux de plus en plus lev s Les concepteurs ont ainsi cherch d abord d finir les besoins et exigences de l utilisateur puis l utilisateur lui m me au travers de diff rents mod les Nous retenons de cette tude l importance de la mod lisation Un concept fort merge galement il s agit du concept d usage et de la conception centr e usages Utilisateur S D fini par lt D fini par D fini par 2 D fini par Langage machine Figure 42 Points d entr e de la conception logicielle au cours de l volution des m thodes Evolution des m thodes Le chapitre suivant montre comment les approches plus r centes montent d un niveau par rapport l utilisateur et s int ressent son contexte m tier Dupuy Chessa 2011 voque diff rents paradigmes dont elle r sume les apports respectifs en ces termes le GL fournit des techniques et outils c d des m thodes pour mener bien un projet de conception logicielle le domaine des IHM nous apprend consid rer l utilisateur final d s les premi res phases d un projet logiciel le domaine des SI prend en compte le contexte organisationnel En effet les approches de d veloppement dites orient es services ne s int ressent plus l utilisateur en tant que tel mais
129. un Accessibilit aux utilisateurs 257 Version en Allemand de CRTI weB Contexte language diff rent d autre nationalit Dans un compte rendu les sections Rectification de fonctionnalit s non 258 Documents jour et Echange de NIL op rationnelles Rajouter dans l export tous les fichiers n cessaire pour le client reader 259 index html SRC de fa on ce que l on NIL Destin aux d veloppeurs Export Chantiers Remplacer la copie des 260 fichiers export s par des liens 270 Favicon petit ic ne pour affichage en NIL D tail graphique 276 Export chantier prendre en compte les R cup rer toutes les Contenu D finition du contenu Nouvelle fonctionnalit utile Export CR modification m thode 277 genererPDF pour permettre sauvegarde Destin aux d veloppeurs 278 Int grer l export des CR dans le Archives NIL Destin aux d veloppeurs Le 120 concernait l tude de faisabilit Partager CR de chantier Tache Plus d informations partageables 280 Ce ticket distinct correspond la avec des photos Contenu Int grer photo Centralisation des informations Actions sur document filtrage personnes rea Identifier activit des Tache 283 du groupe sur base de la zone du collaborateurs Contenu ajout une action sur un temps Ajout mise jour de document version o Avertir certains RE PE 284 _ multi uploads ajout groupe pour les collaborateurs d un Contenu Selection par groupe Gain de temps si une personne ess
130. utilis s par des acteurs diff rents tout au long des processus Ces mod les peuvent tre concrets c d tr s repr sentatifs de la future utilisation du logiciel ou abstraits Nous constatons d ailleurs que si les formalismes proposent diverses fa ons de repr senter graphiquement les t ches abstraites comme concr tes il est rare de trouver une repr sentation des objets d interaction de mani re abstraite Chapitre 4 De Putilisateur la conception logicielle et d interfaces Les professionnels du domaine s accordent dire que le passage d un mod le l autre reste peu structur du fait du caract re manuel de cette op ration Nous traitons dans la section suivante d une approche qui pour pallier cela vise la g n ration la transformation et l utilisation de mod les de fa on automatis e 1 11 Les enjeux de l Ing nierie et de l Architecture Dirig e par les Mod les 1 11 1 Introduction l Ing nierie Dirig e par les Mod les I DM D un point de vue op rationnel la conception classique d un logiciel consiste comprendre et abstraire son contexte d utilisation la fois professionnel et technique puis transf rer cette analyse au d veloppeur qui se chargera de la programmation selon son interpr tation C est la base des m thodes de conception orient es logiciel et utilisateur pr sent es dans les sections pr c dentes diff rentes formes de mod les ont t
131. utilisateurs et les concepts qui gravitent autour qui sont utilis s pour la conception 1 10 1 Vers une m thodologie de la conception enrichie Les m thodes de GL et notamment les m thodes agiles visent la satisfaction du client consid r comme celui qui a besoin du logiciel Le client est alors impliqu dans la formulation des exigences puis dans l valuation de la r ponse ces exigences Nous consid rons pr sent le client comme le futur utilisateur En d autres termes il ne s int resse plus seulement ce que va lui apporter le logiciel c d la mani re dont il r pondra ses besoins mais il attend en plus une utilisation simple et efficace travers une interface adapt e on parle d utilisabilit La capacit d une IHM s adapter aux contraintes la fois mat rielles et environnementales dans le respect de son utilisabilit est d finie comme sa plasticit Thevenin 2001 Laurillau 2002 illustre l enrichissement des m thodes de conception logicielle travers l exemple de la m thode en V Figure 30 Il r organise les tapes de ce cycle selon deux cat gories les tapes relevant de l espace IHM c est dire les tapes de conception ergonomique du syst me et d laboration d un mod le d interaction r pondant des requis identifi s l issue de l tape d analyse des besoins et les tapes relevant de l espace logiciel c est dire les t
132. veloppement l outil pr sente cependant des manques d adaptation Ce constat d inadaptation n est pas un cas isol il refl te une lacune g n rale de ce genre d outils satisfaire pleinement les attentes des professionnels C est pourquoi ce travail doctoral propose un cadre d analyse support par la mod lisation des comportements des utilisateurs Nous adoptons alors plusieurs points de vue relatifs diff rents champs de recherches le g nie logiciel la conception d interfaces homme machine l entreprise orient e services et la conception de syst me d information et enfin le travail collaboratif assist par ordinateur TCAO D un point de vue organisationnel nous identifions les pratiques collectives exerc es par les groupes d acteurs impliqu s dans le projet Nous en d duisons ensuite les pratiques individuelles savoir les responsabilit s de chacun en fonction de son r le dans le groupe D un point de vue op rationnel nous nous int ressons la m diatisation de ces responsabilit s par l usage de diff rentes solutions technologiques La caract risation de ces usages est li e la notion de contexte le contexte technique mat riel logiciel le contexte spatial localisation environnement le contexte temporel fr quence r gularit synchronisation Enfin le point de vue fonctionnel vise d finir le service utilis c est dire le comportement non plus de
133. vue organisationnel L avantage de l diteur d velopp est de pouvoir formaliser de mani re structur e une analyse m tier en cr ant un mod le adapt Nous tirons pour cela profit de la caract risation du contexte coop ratif et de celle des pratiques au travers de m ta mod les L objectif est de permettre une mod lisation qui soit coh rente avec le domaine analys savoir le projet de conception construction architecturale Ainsi partir de chaque classe du m ta mod le de pratiques un l ment de diagramme est cr et peut tre ajout dans le diagramme via la palette On instancie ainsi chaque classe puis ses attributs de la mani re qui a t d finie dans le m ta mod le savoir par choix dans une liste attributs de type num ration ou par saisie de texte attributs de type texte Un attribut peut tre instanci plusieurs fois si cela a t sp cifi dans le m ta mod le gr ce aux cardinalit s La cr ation de relation entre l ments est contrainte par les relations du m ta mod le et galement par leurs cardinalit s Par exemple la cardinalit 0 1 sur la relation ex cute entre un acteur et une pratique individuelle implique qu un seul l ment acteur pourra tre reli chaque l ment pratique individuelle dans le mod le Cela permet de respecter la d finition d une pratique individuelle qui est le comportement isol de chaque acteur impliqu dans une pratique
134. 01 pdf 27 03 2013 PL V_ASB_U3 VI A _547_01 png 27 03 2013 Hi IM_H_ASB_U1_VI_1_123_02 PNG 27 03 2013 i PL_A_ASB_EG_DI_A_123_01 PNG 27 03 2013 P P Ple Pele Ee dede x x Figure 11 Interface de CRTI weB service Documents 60e CRTI weB Service Compte rendus 4 www crti web lu index php 58 2 CompteRendus viewRemarques idCR 11933 vr e KE Coogle Q LL A r Sa 1 Annie Guerriero CRTI LL R chanter d valuation pour le CRP HT Gestion de Compte rendu HK a Nouveaut s F R unions f Compte rendus f Annuaire j Recherche Rubriques _Class es par date de cr ation croissante gt R f rences gt Pr sents gt G n ralit s N INTITUL RESPONSABLE S Prio Constar D rai R GL Actions Avancements z z Notes 1 4 1 Accord Loeginterin 2 24 01 2013 a R Remarques Agenda RAPPEL Accord pour les techniques sp ciales transmettre au plus t t rendus gt Compte rendu n 4 gt Remarques i Devis pour PDF 0 15 1 SES Guring amp associ s 1 24 01 2013 Compte rendu Draft Test test test Un syst me de serrure est pr voir pour l ensemble du b timent Des offres de prix seront demand es 1 6 Raccordement Exim amp ass 3 03 01 2013 QA 2a gaz Raccordement gaz eau visites seront effectu es aux services concern s pour demande de finalisation expresse Plan d tection a 21 E jie Exim amp ass 2 10 01 2013 rg QA Ra Plan d
135. 12 Osaka Japan Guibert O 2007 Cours d Analyse et Conception des Syst mes d Information d Outils et Mod les pour le G nie Logiciel Goransson B Lif M amp Gulliksen J 2003 Usability Design Extending Rational Unified Process with a New Discipline In nteractive Systems Design Specification and Verification 10th International Work shop DSV IS 2003 Madeira Island Portugal Springer Verlag Berlin Heidelberg 2003 pp 316 330 Hanrot S 2005 Une valuation de la qualit architecturale relative aux points de vue des acteurs Cahiers RAMAU 5 pp pp 111 126 Hanser D 2003 Proposition d un mod le d auto Coordination en situation de conception application au domaine du b timent Institut National Polytechnique de Lorraine He H 2003 What is service oriented architecture Publica o eletr nica em 30 pp 1 5 Henri F amp Lundgren Cayrol K 2001 Apprentissage collaboratif distance pour comprendre et concevoir les environnements d apprentissage virtuels Heuvel W 2009 Software service engineering Tenets and challenges In PESOS 09 Vancouver Canada IEEE pp 26 33 Hevner A et al 2004 Design science in information systems research M Squarterly 28 1 pp 75 105 Hietanen J 2006 Al Official IFC Model View Definition Format Hodgson G 2003 Capitalism complexity and inequality Journal of Economic Issues 37 2 pp 471 478 Huang E amp Mynatt E 2006
136. 22 usages dusage et dutilisation quel mot utiliser Chapitre 10 La mod lisation des usages le point de vue op rationnel parler d usage d tourn lorsqu il s agit d un outil qui sert autre chose que ce a quoi il a t destin Pour caract riser la m diatisation d une pratique m tier par l emploi d un outil nous privil gions donc le terme d usage plut t qu utilisation car il couvre une d finition plus large que celle du simple emploi Nous cherchons en effet retrouver en plus de la notion d emploi les notions d habitude qui d coule du concept de pratique que l on veut outiller qui est par nature une mani re de travailler r currente d objectif relatif l objectif m tier le but tant de se servir des outils pour les atteindre et d appropriation par les acteurs notamment en fonction de leur r le duquel d coulent leurs besoins En gardant l id e ces acceptions des termes usage et utilisation on remarque galement que l volution de l usage peut tre d pendante de celle de l utilisation On dira par exemple que l usage des plateformes collaboratives ou encore des applications mobiles a volu dans le domaine AIC car leur utilisation est devenue plus intuitive On retrouve ici la notion de push technologique introduite pr c demment Les avanc es technologiques permettent en effet de supporter une charge de travail toujours plus soutenue et con
137. 5 Les fl ches rouges symbolisent l volution de la m thode notamment des concepts et formalismes utilis s gr ce aux exp rimentations Les symboles montrent que les exp rimentations se compl tent dans la validation de la m thode chacune apportant un l ment diff rent Chapitre 12 La m thode PUSH exp rimentations et bilan Tableau 25 Apports des diff rentes exp rimentations i La m thode permet La m thode permet aux En favorisant le Dipp ie d int grer les experts m tiers et aux re d veloppeurs dans le concepteurs de cf m thode exigences la m thode OPP P projet et favorise le s accorder sur un usage permet de lever des SE dialogue avec les sp cifier en fonction risques r concepteurs des besoins m tier Les descriptions des La composition des Les concepts peuvent pratiques et usages trois points de vue tre am lior s et cf concepts sont pertinentes mais forme un mod le de compl t s de mani re ne suffisent pas d veloppement r guli re pour raffiner d crire le service complet Panalyse k ae utile a ee mas Pe peace sun ics dia rammes relatifs oe aens Rate N 8 explicite et favorise explicite et favorise le cf mod les aux usages restent le dial dalos enire cece insuffisants sans plus e dialogue entre sti 8 i P d de pr cisions concepteurs et metier concep eur de i service techniques d veloppeurs Les utilisate
138. 6 3 Description fonctionnelle Nous proposons l tude de plusieurs mod les d architecture logicielle sp cifiques la description de services collaboratifs Ces mod les font voluer le mod le MVC qui a retenu notre attention au 1 9 3 cf Figure 26 Le mod le Arch L Bass et al 1992 est une volution directe du mod le MVC Dans ce mod le un adaptateur abstrait les objets du domaine en objets conceptuels lors de l interaction entre le Mod le appel Noyau fonctionnel et le Contr leur appel Contr leur de dialogue De m me les objets d interaction de la Vue le Composant Physique d Interaction sont abstraits en objets de pr sentation par un Composant Logique d Interaction Chapitre 6 Travail Collaboratif Assist par Ordinateur et Services Collaboratifs Le mod le Daewan introduit la prise en compte de plusieurs utilisateurs en faisant voluer le mod le Arch Chaque branche est dupliqu e pour chaque utilisateur et une partie partag e assure la mise en correspondance de ces branches Les utilisateurs et les services communiquent entre eux l aide de deux types d v nements les v nements d interaction refl tant l interaction de l utilisateur avec le service et les v nements de la collaboration refl tant l interaction entre les services Laurillau 2002 Les mod les PAC Amodeus et Clover Laurillau amp Nigay 2002 d veloppent encore ces architectures
139. CES COLLABORATIFS ADAPTES AU SECTEUR DE LA CONSTRUCTION ETUDES PROPOSITIONS Table des mati res Table des mati res Table des mati res Bibliographie Aalst W 1998 The application of Petri nets to workflow management Journal of circuits systems and computers pp 1 53 Abras C amp Maloney Krichmar D 2004 User centered design Bainbridge W Encyclopedia of pp 1 14 Aguilar Sav n R S 2004 Business process modelling Review and framework International Journal of Production Economics 90 2 pp 129 149 Andersen P Carstensen P H amp Nielsen M 2000 Dimensions of coordination In M Schoop amp C Quix eds LAP 2000 The fifth International Workshop on the Language Action Perspective on Communication Modelling Aachen Germany pp 41 60 Anderson R 1994 Representations and requirements The value of ethnography in system design Human computer interaction Armand J 1997 140 s quences pour mener une op ration de construction Des tudes pr alables l ach vement de l ouvrage actions techniques et d marches administratives Le Moniteur Arsanjani A 2004 Service oriented modeling and architecture IBM developer works January pp 1 15 Avignon L et al 2002 Architectures de Syst mes d Information Livre blanc Baida Z Gordijn J amp Omelayenko B 2004 A shared service terminology for online service provisioning In M Janssen H Sol a
140. Cultura UNIVERSIT DE LORRAINE cral Centre de Recherche en Architecture et Ing nierie S amp ih r 5 S Universite de Lorraine UMR n 3495 CNRS Minist re de la Culture et de la Ecole Doctorale IAEM Lorraine Communteation D partement de Formation Doctorale en Informatique cole Nationale Sup rieure d Architecture de Nancy Th se pour l obtention du titre de Docteur de l Universit de Lorraine en Sciences de l Architecture par Daniel Zignale Concevoir des services collaboratifs adapt s des pratiques m tiers une m thode centr e usages Application au domaine de la construction Soutenance publique le 17 juillet 2013 Membres du Jury Mme Sophie DUPUY CHESSA Rapporteur Ma tre de conf rences en informatique HDR Grenoble M St phane HANROT Rapporteur Architecte Professeur en architecture HDR Marseille M Eric DUBOIS Examinateur Professeur en informatique Namur M Pierre LECLERQ Examinateur Ing nieur Architecte Professeur en sciences appliqu es Li ge M Gilles HALIN Directeur Ma tre de conf rences en informatique HDR Universit de Lorraine M Sylvain KUBICKI Co directeur Architecte Docteur en sciences de l architecture Luxembourg Avec le support du CRP Henri Tudor et du Fonds National de la Recherche Luxembourgeois tugor PUBLIC RESEARCH CENTRE HENRI TUDOR Fonds National de la Recherche Luxembourg A Angelo et Tina
141. D ow ES Activit Activit Document Activit Outil 1 Hanser 2003 2 Bouattour 2005 3 Kubicki 2006 Figure 2 Evolution des concepts du contexte de l activit collective de 2003 2006 issu de Guerriero 2009 La derni re caract risation du contexte coop ratif est repr sent e par le diagramme relationnel qui suit Figure 3 Les relations entre chacun des concepts principaux classes primaires caract risent ce que nous appellerons la dynamique du projet Une relation entre deux l ments d finit les actions ou les statuts d un l ment par rapport un autre Par exemple la relation acteur artefact est relative l dition de documents ou encore l laboration d un ouvrage et peut en d finir la nature ex un acteur r dige un document la relation activit activit d termine l ordonnancement des t ches ex une t che succ de une autre t che Relation Activit Activit Element lt lt stereotype gt gt lt lt stereotype gt gt lt lt stereotype gt gt TEitereatype gt gt Relation Acteur Activit Activit fats Outil Activit Elemen J stereotype gt gt Element i lt Siterectype gt gt emend Relation Activit Acteur gt r Relation Activite Outil Element X Element lt stereotype gt gt lt stereotype gt gt ActiviteUnique GroupeActivit s Element tement ES lt lt
142. Documents administratifs Taches conception et coordination Phase d tudes pr alables et contractuels Phase Conception APS si appel d offres PC3 d termination des objectifs Description il appartient au Ma tre de l ouvrage de d finir le programme de l op ration Il d finit le processus de construction qui comprend des l ments quantifiables et techniques ainsi que des l ments fonctionnels qualitatifs et volutifs L assistance la Ma trise d ouvrage a pour r le de l assister dans cette t che S il veut pr tendre l attribution d un label environnemental il peut se r f rer des experts du domaine Il fixe ainsi les objectifs avec lesquels devra travailler la Ma trise d uvre lors de la conception de l ouvrage Lors de petits projets le Ma tre d ouvrage peut n avoir que tr s peu d informations donner c est le Ma tre d uvre qui fixe alors ces objectifs Chapitre 9 La mod lisation des pratiques le point de vue organisationnel Tableau 14 El ments de caract risation de la PC3 Documents utilis s Activit s Acteurs impliqu s Ma tre d ouvrage Assistance la MO Ma tre d uvre Programme T ches conception et coordination Phase d tudes pr alables Phase Conception APS si appel d offres Informations et directives techniques Experts PCA d termination et gestion du budget Descript
143. I weB que de fichiers partag s Mais au regard des usages sp cifiques au m tier nous avons pu proposer une solution alternative adapt e diff rents sc narios de pratique valid s Deux pratiques deux usages partir de l analyse des pratiques nous avons pu mettre en vidence que les professionnels peuvent vouloir diffuser des documents ind pendants PI diffusion aux autres concepteurs ou pr f rer partager un groupe de documents avec un seul objectif PI diffusion des plans d ex cution avec l entreprise ces deux pratiques correspondent deux intentions en termes de m diatisation par un outil et donc deux usages Chapitre 12 La m thode PUSH exp rimentations et bilan ED pesign phase i i The end of the design phase particularly called production phase i Designer CP Documents exchange for execution The main designer of the project he leads the project Family 9 Execution preparation and management Job Architect Contractors get the documents from designers who share it for execution for execution Diffuse design documents for construction enterprise Execution is based on plans provided by designer ANNEE type Enterprise Contractor General construction enterprise Plans of the project Author Designer Status Over qe Message type Notification Sp cifications about material and equipment notification of shared documents it can contain specific instructions Author Designe
144. L mais qui n est pas formalis par le diagramme UML correspondant le diagramme de cas d utilisation Vis vis de l analyse m tier nous pensons que les mod les de processus sont inadapt s pour la description du contexte particulier d un projet AIC cf 1 14 4 Berard amp Karlshoej 2012 partage notre avis argumentant en ces termes les processus de projet de construction sont tr s flexibles et avec les pratiques d aujourd hui il est difficile de mod liser un processus tr s d taill afin de le standardiser Il ajoute non seulement l ordre de l ex cution des t ches est diff rent d un projet un autre mais l interaction entre organisations peut aussi diff rer l int rieur m me d un projet L objectif est donc d viter d investir du temps en se perdant dans de la surmod lisation et de trouver l quilibre entre mod lisations g n rique et sp cifique afin de couvrir diff rents besoins tout en restant pertinent Nous pensons qu il est important de privil gier des mod les simples autour de concepts clairement d finis Dans le cadre du d veloppement d un ensemble complet de services bas s sur le BIM PIDM d crit non pas un seul mais de multiples processus qui composent l activit globale de projet Au final un IDM se pr sente comme une checklist de plus de 50 pages Nous pensons qu il serait utile de d composer cette approche en cr ant des IDM plus
145. Les relations qui lient les op rations avec les l ments du contexte coop ratif c d les acteurs artefacts et activit s sont les m mes que pour les pratiques engendre manipule et concerne Dans le MMO les couples op rations l ments sont d taill s et suivent le sch ma suivant Figure 90 Chapitre 9 La mod lisation des pratiques le point de vue organisationnel Communication Message Acteur D Acteur ex cutant concern Production Doc Objet Diffusion Doc Objet R cup ration Production Diffusion Espace de transition Espace priv Figure 90 Les op rations en rouge et artefacts manipul s rectangles bleus autour des concepts d espace de transition et d espace priv Les op rations de communication g n rent des messages pour les acteurs concern s Par exemple une op ration demander va g n rer une requ te laquelle va acc der la personne qui l on fait cette requ te Les op rations de production g n rent ou manipulent des documents et des objets Ceux ci peuvent dans un premier temps rester priv s et ou tre partag s par une op ration de diffusion Ils passent alors par un espace de transition qui sera d fini par l usage voir chapitre suivant C est par exemple le processus habituel suivi pour les plans ils sont produits par le concepteur puis une fois bons pour ex cution ils sont diffus s aux entreprises concern
146. NERGIE DGNB autres pas de certification Chapitre 9 La mod lisation des pratiques le point de vue organisationnel T che m tier 7 Type_certification num ration Cemaran lt lt enumeration gt gt Type_certification Type_activit tache HOE F lt lt enumeration gt gt ti bit BREEAM Hs Type_activit phase al IX MINERGIE coordination pr paration be T Er 9 DGNB et conception ype_activite projel autre ex cution Hivraison Groupe d activit s logement individuel logement collectif batiment public pas de certification lt lt enumeration gt gt Type_famille lt lt enumeration gt gt Type_statut 4 implique 1 Pratique colllective choix et valuation du site choix des concepteurs d termination des objectifs d termination et gestion du budget conception et compte rendu de la conception choix des entreprises de construction yaluation de la conception et compte rendu organisation des r unions et compte rendu pr pration et gestion de l ex cution valuation de l ex cution et compte rendu implication des usagers lt lt enumeration gt gt Type_r le concepteur maitre d oeuvre dessinateur graphiste coordinateur maitre d ouvrage en cours termin pour ex cution ex cut valider valid modifier implique AN Groupe d artefact
147. On pourra trouver dans Sohlenkamp et al 2000 ou Sutcliffe 2005 des s ries d exigences plus sp cifiques relatives la conception d un service de notification Chapitre 6 Travail Collaboratif Assist par Ordinateur et Services Collaboratifs Tableau 9 R sum des approches de conception bas e sur le concept de loose coupling Approches de conception Descriptions Support de l autonomie et de la flexibilit Agr gation de V information Support des pratiques actuelles de travail sans forcer l interd pendance des acteurs au risque de r duire leur autonomie et leur flexibilit D placement de parties d information depuis des espaces tampons vers un unique repository pour am liorer la coordination et la conscience des activit s du monde r el Support des espaces de Le partage d information avec un ou plusieurs membres travail individuels et du partage discret de l quipe doit pouvoir se faire la discr tion des autres acteurs Int gration de la collaboration avec des quipements du travail individuel Les quipements collaboratifs ne doivent pas interf rer avec l utilisation d autres quipements plus g n ralement utilis s Facilit de la conscience asynchrone Support de la conscience des activit s des autres et persistance de l information avec le temps Support de la coordination l che Minimiser les efforts de coordination et l
148. Premera Geshonnaire Facture GeshonnaireDooumert Prour ze Sew an rere Sestionnaire Rappo Promo atat ioe Aine Fay hong Connexions de la pr sentation Armes vers les Services dans la facette Contr le Figure 67 Migration des services vers le dispositif 1 19 2 Analyse critique La m thode de conception CoCSys est bas e sur les approches MDA de transformation de mod les et se d roule en plusieurs phases l identification d un sc nario contextuel d crivant des cas d utilisation la sp cification d un mod le comportemental puis le d veloppement d une architecture logicielle Elle supporte la prise en compte des besoins relatifs au r le d une personne dans son organisation pour lui proposer des services informatiques adapt s La m thode permet en plus de consid rer le contexte utilisateur de cette personne L auteur propose une m thode de conception d applications savoir un processus de conception suivre ainsi que les formalismes et les outils de mod lisation supportant ce processus notamment CBME et KMDEg Le but de cette m thode est de g n rer une interface qui permet d acc der des services qui ont t identifi s comme n cessaires l ex cution d un processus m tier Chapitre 7 Les m thodes de conception de services tudes de cas Le m ta mod le des sc narios contextualis s MMSC d crit les sc narios m tier av
149. R L USAGE DU TABLEAU DE BORD NIVEAU RE 140 DIAGRAMME D INTERACTIONS POUR L AJOUT DE REMARQUES RE 141 COLLABORATION POUR LA CONCEPTION DE SERVICES AUTOUR DE LA PRODUCTION DE RAPPEL STRUCTURE DE NOTRE RECHERCHE BASEE SUR LA CONCEPTION GRILLE D ANALYSE DES TICKETS PARTIE 1 4 GRILLE D ANALYSE DES TICKETS PARTIE 2 4 GRILLE D ANALYSE DES TICKETS PARTIE 3 4 GRILLE D ANALYSE DES TICKETS PARTIE 4 4 Liste des tableaux TABLEAU TABLEAU TABLEAU TABLEAU TABLEAU TABLEAU 200 TABLEAU Table des illustrations Table des illustrations Annexes Analyse des tickets de conception de CRTI weB L analyse voqu e au 1 5 3 lavait pour but d valuer le nombre de d veloppements sur les services CRTI weB en rapport avec un besoin m tier a savoir une exigence issue du domaine professionnelle et non li e des probl mes d utilisabilit D apr s l analyse men e la moiti des d veloppements initi s ont pour origine un besoin m tier clairement identifi Nous avons galement pu valuer les modifications impliqu es dans l usage g n rale sur les t ches sur le contexte ou sur le contenu De Y a t il une pratique m tier Quelle modification dans Quelle am lioration dans l utilisabilit Quel apport de la fonctionnalit Po ui non Laquelle G T c cu p tail Chargement des fichiers en arri re plan Partager des groupes de doc
150. Remark about element Graphical spec 3D element in the model Graphical spec Icon on the element table in the remarks list Attributes name description position Attributes ID name_element description position photo responsible date state Data type BIM_object Data type BIM_object document Properties Properties Figure 140 Diagramme d interactions pour l ajout de remarques Recommandations et pistes pour le d veloppement du service Les remarques sur le chantier sont les informations cl s de cet usage et sont comme nous venons de le dire des l ments du rapport de chantier Sachant que le service m tier comptes rendus de CRTI weB propose d ja des services informatiques pour la gestion de ces rapports et des remarques nous pourrions les int grer dans l impl mentation du nouveau service Ce service m tier de surveillance de chantier devra aussi contenir des services relatifs au BIM 1 42 4 Conclusion Cette exp rimentation nous a permis d appliquer la m thode de mani re diff rente et pour un type de service diff rent L id e innovante initiale un tableau de bord utilisant les remarques des comptes rendus CRTI weB a pu tre en partie concr tis e en r ponse des pratiques m tiers mod lis es grace notre m thode et par une d finition des usages li s Evaluation de la pertinence Lorsqu un utilisateur ou un expert m tier propose un service tr s pr
151. Responsable de la diffusion M Executes Uh des concepteurs expose les choix conceptuels de l quipe pour valuaton Job Architect B Rerievina Is composed of Artifacts definition Is composed of Document om Alre supported by a service Already supported by a service acy y gt Messanae Actors definition Uses Targets Actor Group of Actors ceometral Bear type Agency Plans du projet au stade APS Designer 2 Frere Author Designer lt Add here more species if needed gt amp Activity definition Status In Progress rr W Euspess Task Figure 92 Interface de l diteur GMF d arbres hi rarchiques pour la mod lisation des pratiques exemple Chacun de ces l ments est introduit dans le mod le partir de la palette droite Ces l ments sont donc des concepts du m ta mod le propos et permettent d homog n iser les analyses Chaque l ment est ensuite ditable notamment par le choix d attributs dans des num rations pr d finies L expression litt rale permet de faire des descriptions qui vont au del de ces listes et qui permettent notamment d apporter de l information suppl mentaire C est notamment ce type d dition que nous utilisons pour les attributs nom ou description La combinaison des deux modes d dition offre une description la fois g n ralisable et sp cifique Chapitre 9 La mod lisation des pratiques le point de
152. The CRTI weB experience is a groupware development project lead with and for professionals of the Luxembourgish sector It actually proposes two services in its commercial version the documents exchange and management service plans technical documents and the site meeting report redaction and management service Despite the analysis of business needs lead before development the tool has some lacks of adaptation This statement isn t isolated in general this type of tools doesn t fully satisfy professionals expectations This doctoral work proposes an analysis framework supported by users behaviors modeling We adopt several viewpoints related to several research fields software engineering human computer interactions design service oriented enterprise and information system design and finally computer supported collaborative work CSCW From an organizational viewpoint we identify collective practices performed by groups of actors involved in the project Then we deduce the individual practice i e the responsibilities of each actor considering his role in the group From an operational viewpoint are interested in the mediation of these responsibilities by the usages of different technological solutions The definition of these usages is linked to the concept of context the technical context hardware software the place context location environment and the temporal context frequency regularity synchronization F
153. a conception centr e usage tir de L L Constantine 2006 Chapitre 4 De l utilisateur la conception logicielle et d interfaces 1 10 3 La mod lisation des t ches et du contenu Nous adoptons le point de vue de Kaindl amp Jezek 2002 qui d finit la tache comme un fragment d activit qu une personne doit effectuer o l activit est ici l interaction avec un systeme Il existe plusieurs niveaux d abstraction de t ches de l intention guid e par une r flexion on pourra parler de t che cognitive l interaction physique proprement dite Winckler et al 2004 en donne par exemple 4 niveaux voir Tableau 6 Tableau 6 Niveau et port e des t ches selon Winckler2004 Niveau Port e But Buts et intentions de l utilisateur Abstrait D composition des buts en t ches g n riques Interaction Actions de l utilisateur et du syst me Pr ntation visuelle Rendu des fonctions ex cut es par l application Samaan 2006 prend en compte deux niveaux pour le mod le de t ches Le mod le abstrait de t ches repr sente une vue g n rique du syst me mod lis et cela ind pendamment du contexte d utilisation en g n ral et plus sp cifiquement ind pendamment de la plate forme Une t che dite abstraite peut alors suivre plusieurs patterns d interaction c est dire qu elle peut tre r alis e de plusieurs fa ons travers des ense
154. a n gociation directe des utilisateurs Support de la communication l che Minimiser les efforts requis pour initier une communication Support du changement Supporter des interactions et communications directes ou vers un couplage plus du moins en supporter l organisation rigide Pr servation d une organisation flexible Laisser les acteurs d terminer leur niveau d implication dans les situations collaboratives 1 18 Conclusion concevoir des services collaboratifs Les tudes sur le TCAO coupl es notre exp rience dans le domaine avec l outil CRTI weB nous ont permis d identifier un certain nombre de services collaboratifs qui composent un collecticiel Ces services supportent la communication la coop ration et la coordination et ceci dans des contextes de localisation et temporel diff rents Nous avons d fini un mod le d architecture logicielle qui d crit un service collaboratif d un point de vue fonctionnel Pour pallier aux manques d adaptation des collecticiels les approches de conception se sont tourn es vers l analyse de grand principes ou caract ristiques propres au travail collaboratif Nous pouvons assumer partir des quelques exemples donn s que la cl de cette adaptation r side dans le respect de l utilisateur c d la capacit du collecticiel respecter les pratiques de travail et la discr tion des utilisateurs sans les
155. ace de mod lisation permet donc une volution qui sera s rement n cessaire au fil d autres applications de la m thode Dans cette exp rimentation nous avons pu exploiter le concept d objet d interaction et d crire ainsi les ouvrages du batiment et les remarques du compte rendu comme de r els l ments m tiers m diatis s Cela nous permet de d finir un usage au plus proche des pratiques m tiers identifi es en amont valuation des formalismes Nous avons constat que lorsqu une situation devient plus complexe avec de multiples op rations des liens entre les artefacts le diagramme de pratiques perd en lisibilit Cela fait ressortir l importance de traiter les exigences au cas par cas sans d finir des processus trop complets Les correspondances graphiques entre mod les permettent de tenir un discours coh rent avec un collaborateur qui n a pas l habitude de manipuler autant de mod les Les diagrammes d interactions gagnent galement tre divis s en plusieurs entit s pour une meilleure lisibilit 1 43 Conclusion apports des exp rimentations 1 43 1 R sum La premi re exp rimentation nous a permis de mettre en vidence l importance de la sp cification des besoins m tiers et les diff rences entre les usages qui peuvent en d couler Elle a montr l importance de la collaboration entre experts m tiers concepteurs et d veloppeurs autour de mod les appropri s Elle a galeme
156. actions manipulant des donn es au m me titre que les Inputs et Outputs Chapitre 11 La mod lisation des services le point de vue fonctionnel Mod le priv E Ee nom texte Donn e texte 7 SSS K a Mod le partag ee Mod le Composant Service ICT nom texte nom texte technologie texte Figure 114 Caract risation du service ICT et ses composants 1 36 3 Le m ta modele des services ICT adapt s Par la composition des deux m ta mod les pr sent s dans cette section nous cr ons notre M ta Mod le de Services ICT MMS de la m me fa on que nous avons compos les m ta mod les de pratiques et d usages MMPM et MMU Ce que nous appelons M ta Mod le des Services Adapt s MMSA est l association de ces trois m ta mod les En effet partant du postulat qu un service est adapt s il r pond a des besoins m tiers cette association qui caract rise la m diatisation des pratiques par les usages eux m mes mat rialis s par les services caract rise donc cette adaptation Chapitre 11 La mod lisation des services le point de vue fonctionnel Chapitre 11 La mod lisation des services le point de vue fonctionnel Relation entre usages 7 mat rialise Dispositif Type_dispositif num ration Type_OS num ration Type_connexion oui non Type_contr leur num ration Type_entr e _vid
157. ad files in one CRTI weB document Graphical output 10 Name Documents System task type Processing E Fe selection ofrhen Graphical spec Icon label progress bars checkbox Concrete user interactin type Selection Attributes Name file type Is composed of r z f LR Data type file 10 Name Document name ED n tenn Graphical spec text fields and combo boxes Graphical output a then hl Attributes primitive data of then Data type text visualize loading Graphical output Figure 116 Rappel Diagramme d interaction d composant l intention upload multiple files Les taches concr tes d interaction et de perception rectangles gris guident la sp cification des changes client service Il s agit alors de d finir le comportement du service ICT en d crivant les actions de ses composants Figure 117 Nous sommes dans un cas d adaptation d un service d j existant La solution technique adopt e est donc d pendante de la technologie utilis e et s inscrit dans les d veloppements d j effectu s Les d veloppeurs responsables de ces d veloppements sont m me d exprimer ce point de vue fonctionnel pour d crire ce qu ils vont impl menter L utilisateur manipule des fichiers physiques stock s sur son ordinateur et qu il souhaite copier sur un serveur externe Lorsqu il a choisi les fichiers qu il veut partager le service informatique les cop
158. add new remarks SHARE On site building element level Operatonal ole monitor Applicaton tve Hird application fon per Demos ee PHP web serves BEST as LT e am n EEE OE Figure 139 Extrait du contextual use case pour l usage du tableau de bord niveau ouvrage Le diagramme d interactions suivant d taille l intention ajoute une nouvelle remarque La t che de s lection de l ouvrage t che abstraite est ici sp cifi e par un click sur l ouvrage dans le mod le ou un scan de la puce RFID t ches concr tes tel que nous l avons d crit plus haut Les objets d interaction sont l ouvrage et la remarque d crivant le d faut sur cet ouvrage L ouvrage est un objet du mod le qu on caract rise comme objet BIM la remarque est la fois l ment du mod le objet BIM et l ment du rapport de chantier document Chapitre 12 La m thode PUSH exp rimentations et bilan Scan RFID Concrete user interactin type composite Qada new remark on element O save remark Vo System task type Processing gt Then Click on element on 30 model gt Is composed of Concrete user interactin type Selection gt Then Is composed of Is composed of Select element A create remark Abstract user interaction type selection n_n Abstract user interaction type Input A Interact with P rea with go Name Building element 10 Name
159. al of Management Information Systems 24 3 pp 45 77 Peixoto D Batista V amp Atayde A 2008 A comparison of bpmn and uml 2 0 activity diagrams In VII Gmposio Brasileiro de Qualidade de Software Pereira CM 2004 A method to define an Enterprise Architecture using the Zachman Framework In Proceedings of the 2004 ACM symposium on Applied computing ACM Pinelle D amp Gutwin C 2005 A groupware design framework for loosely coupled workgroups In ECSCW 2005 pp 65 82 Piquet A 2009 Guide pratique du travail collaboratif Th ories m thodes et outils au service de la collaboration Pribeanu C 2005 An Approach to Task Modeling for User Interface Design World Academy of Science Engineering and Technology 5 pp 5 8 Pruitt J amp Grudin J 2003 Personas practice and theory In Proceedings of the 2003 conference on Designing for user experiences ACM P rochon L 2008 Ing nierie dirig e par les mod les Mode Driven Architecture Bibliographie Quartel D Dijkman R amp Van Sinderen M 2004 Methodological support for service oriented design with ISDL Proceedings of the 2nd international conference on Service oriented computing ICSOC 04 Rameau G amp Samyn E 2006 LE TRAVAIL COLLABORATIF ASSISTE PAR ORDINATEUR TCAO Exemple d une solution technologique avec X TEK In 23 me congr s de l AIPU Monastir pp 1 22 Ramollari E amp Dranidis D 2007 A survey o
160. alement par des verbes La signature c est un ensemble de param tres repr sentant les inputs et outputs d une capacit et donc d un service Ces param tres sont d crits lexicalement par des noms Les propri t s non fonctionnelles ce sont les obligations telles que le paiement ou le programme devant tre assum es par le fournisseur et le demandeur engendrant dans le cas contraire une p nalit Le prix et la qualit sont galement des propri t s non fonctionnelles 1 http www ibm com developerworks webservices library ws WSBFoverviewpart1 index html 20 A A k r P P P 2 Voir aussi leur site internet http www service description com index htm Chapitre 5 De l entreprise orient e services la conception de Syst mes d Information 4 name Sirin sericeRequesier sericePraviders a honetituantGerices 4 centa 1 1 MP cenie ul Decomposition description String 2 rnfanctenal Gescritpion String ag location String A Delegation Subcontracting canoe pans LA prowdedCapabillities Capability preconditions language String 1 Phrase r i Lexical Term definition String Ontological Source url Sting Figure 45 M ta mod le du BSDL L 2010 1 13 3 Le service informatique CT En informatique un service est une fonctionnalit mise a disposition par un composant logiciel pour assurer une t c
161. ans CTT en fonction de l ex cutant de la t che la t che utilisateur ex cut e par un individu ou une organisation la t che syst me ex cut e compl tement par un quipement la t che interactive d clench e par l utilisateur et r alis e sur l quipement la t che abstraite contient des sous t ches d ex cutant diff rent la t che dont l ex cutant est inconnu est comme son nom l indique ind termin e a o s a W Racine fr Racine N Racine NeRecine a y gt wer CD inrer INTER wa INTER A inter Utilisateur Syst me Interactif Abstrait Inconnu D composit on D compo sikon n Figure 35 Les cing types de t ches qui composent un arbre K MAD Les t ches filles d une m me t che m re peuvent tre ordonnanc es de fa on s quentielle une apr s l autre parall le en m me temps alternative une ou l autre ou sans ordre C est ce qu on appelle la d composition d une t che une t che sans d composition sera qualifi e 1 L outil K MADe et le manuel utilisateur sont disponibles cette adresse http kmade sourceforge net download php Chapitre 4 De l utilisateur la conception logicielle et d interfaces d l mentaire Une t che quelle qu elle soit peut tre obligatoire ou facultative interruptible ou pas contrainte ou pas c a d par un v nement une condition it rative ou unique Le maquettage Lors d un ma
162. ant nous nous penchons sur l analyse du d veloppement d une plateforme d change de documents particuli re L objectif est de pouvoir en valuer la m thode de conception afin de comprendre les points forts capitaliser mais aussi les limites surmonter Chapitre 1 La coordination dans les projets de conception construction architecturale Chapitre 2 Un cas de d veloppement d un outil de TCAO CRTI weB Le projet de recherche Build IT fut men par le Centre de Recherche Public Henri Tudor CRP HT et le Centre de Ressources des Technologies et de l Innovation pour le b timent CRTI B pour guider le secteur luxembourgeois de la construction vers l utilisation d outils num riques d assistance la coop ration Guerriero 2009 Bas sur l analyse des bonnes pratiques du secteur ce projet aboutit au prototypage d un outil CRTI weB Cet outil est compos de deux services m tier un service d change de documents et un service de gestion dition et partage de compte rendu de chantier Ce que nous appelons exp rience CRTI weB comprend ce projet de recherche mais aussi les d veloppements le transfert et les valuations de l outil qui ont suivi Elle comprend galement les travaux actuels pour l am lioration de l outil par la proposition de nouvelles fonctionnalit s Le contexte de travail au sein du CRP Henri Tudor offre un statut d observateur privil
163. apes de cette phase 2 tape 1 les patrons de t ches permettent de choisir dans une biblioth que le d roulement souhait de certaines t ches utilisateurs en une suite pr d termin e de t ches concr tes d interaction et syst me d pendante du contexte tape 2 les composants sont les l ments logiciels disponibles pour tre int gr s lors de l adaptation Si un composant n existe pas une demande de d veloppement est formul e Ces composants peuvent tre des applications sp cifiques dont la portabilit doit tre g r e en amont Le processus KMDE Knowledge Model Driven Engineering r alise le passage entre le workflow du mod le CAB et son impl mentation par l identification et l int gration des composants fonctionnels souhait s L outil KMDEg supporte ce passage Il pr s lectionne les services susceptibles de r pondre aux besoins identifi s et permet au concepteur de valider ou modifier le choix tape 3 la figure suivante illustre la g n ration de l application par la migration des services formalis s en AMF vers le dispositif Chapitre 7 Les m thodes de conception de services tudes de cas Exemple d IHM int grant les services connect s et disponibles 10 34 fok rae CocSys Manager Services avatable Main Tasks intervention chez Mme Mendez exe R union de plannifcation ja Application Collaborative en AMF lt i MisioCorference _
164. apes de conception et de d veloppement logiciels Chapitre 4 De l utilisateur la conception logicielle et d interfaces EM Evoluet on N AN Tests Analyse des besoins rS gonomique d utilisabilit Tests utilisateur Tests du syst me ti Espace IHM Conception Se en eae eae pace ke Conception Conception globale Tests d int gration logicielle nn 4 onception as d taill e Va unitaires Cod R alisation ocage et tests logiciels jure 6 Figure 30 Le processus de conception en V repris par Laurillau 2002 Plusieurs approches visent pr coniser l utilisabilit La conception centr e utilisateur Norman 1986 La conception centr e activit Gifford amp Enyedy 1999 La conception dirig e par les buts Cooper 1996 La conception centr e usage Constantine amp Windl 2003 Litt ralement parlant la CCU se concentre sur l utilisateur qui manipule le syst me la CCA sur l activit c d les t ches qui doivent tre propos es par le syst me et la CDB sur les buts li s l utilisation de syst me Elles semblent donc tre des approches diff rentes Pourtant la d finition de l utilisateur dans les m thodes de CCU s est tendue de sorte qu elle couvre aussi l identification des ses motivations et de ses t ches R ciproquement l analyse des t ches d un syst me dans la CCA est li e aux t ches de l utilisa
165. application de la m thode Comme le montrent les sections suivantes chaque exp rimentation ne portait pas sur l ensemble de ces objectifs mais a fait ressortir des points d int r t particuliers sur lesquels s appuyer pour valuer et am liorer l approche Le tableau ci dessous r sume les attentes en termes d valuation que nous avions vis vis de chaque exp rimentation en fonction de leur nature Tableau 24 valuations attendues en fonction des exp rimentations valuer le besoin des valuer l importance valuer l int r t de cf m thode d veloppeurs des points de vue structurer les exigences valuer l analyse valuer la distinction valuer la description cf concepts m tier et la description pratique usages des pratiques et de de l usage services l usage valuer les formalismes Sere Evaluer les diff rents de pratiques et d usage cf mod les formalismes des prang 8 formalismes ainsi que le passage pratiques et des usages a d un l autre valuer l adoption par valuer l adoption des cf adaptation les utilisateurs lors du utilisateurs par des Non concern transfert du service tests 1 40 Exp rimentation n 1 L am lioration du service d upload de CRTI weB 1 40 1 Introduction et d roulement Nous revenons ici plus en d tail sur l exemple fil rouge de conception d un service d upload multiple pr sent
166. aque projet Conceptualiser les m thodes de GL Les m thodes de conception logicielle ont volu avec le temps pour r pondre la complexit croissante des applications informatiques en s orientant de la programmation proprement dite vers l analyse et la mod lisation La premi re tape fut de pouvoir d finir des parties de codes sous forme d l ments r utilisables facilitant ainsi la reprise de solutions informatiques pr d velopp es Les tapes suivantes permirent de prendre de plus en plus de recul et de capitaliser les d veloppements cherchant sp cifier un syst me partir de concepts externes relatifs aux utilisateurs leurs t ches leur m tier leur organisation Nous avons analys et cherch tirer parti de ces approches de conception dites dirig es par les mod les Introduction Conceptualiser les pratiques architecturales Malgr des bases fondamentales ancestrales les pratiques de conception et de construction architecturales ne cessent d voluer Elles sont pouss es par l innovation dans les techniques constructives et les mat riaux mais aussi par un contexte conomique d licat qui demande d tre sans cesse plus productif et efficace La volont et surtout la n cessit d atteindre des performances environnementales lev es se montre galement particuli rement g n ratrice de changements Une partie du pr sent travail de doctorat se tourne vers l analy
167. arte n she 4 a t t astu amp sms ot 0 Figure 50 Repr sentations d un m me processus avec BPMN en haut et AD UML en bas Comme cit pr c demment le langage UML doit tre tendu pour correspondre aux besoins de repr sentations du m tier De mani re g n rale sept diagrammes UML peuvent tre tendus et utilis s pour repr senter des l ments d un business model Cesare amp Lycett 2003 Tableau 8 Chapitre 5 De l entreprise orient e services la conception de Systemes d Information EM Tableau 8 Les diagrammes UML et leur potentiel de mod lisation du m tier Cesare amp Lycett 2003 Potentiel de mod lisation du m tier Diagramme Descriptions R les Acteurs Activit s int ractions Buts Entit s de cas d utilisations Mod lise la fonctionnalit d un syst me tel qu il est per u par les acteurs externes qui appellent cette fonctionnalit de classes Mod lise la partie statique d un syst me en termes de classes relations entre classes et d aggr gation de celles ci d objets Mod lise la repr sentation des instances des mod les de classes de collaboration Mod lise les objets d int raction travers des transfert de messages mettant l accent sur les roles dans l interaction et les liens entre chaques de s quence Mod lise les objets d int raction travers des transfert de messages mettant l accent sur les s quen
168. asse de la main d un acteur celle d un autre Dans le deuxi me cas usage 2 c est un service de courrier comme la Poste qui assure cette transition Enfin le troisi me cas introduit l usage de services informatiques qui m diatisent le partage d information sous forme num rique usage 3 C est ce type d usage que nous nous int ressons particuli rement dans la suite de ce manuscrit en cherchant le caract riser de la m me mani re que nous venons de le faire avec les pratiques fa 1353 Usage 1 de main main Usage 2 par la poste Usage 3 sur le cloud partage non m diatis partage m diatis physiquement partage m diatis num riquement Figure 95 Des usages diff rents pour une m me pratique exemple d une pratique de partage de documents Chapitre 9 La mod lisation des pratiques le point de vue organisationnel Chapitre 10 La mod lisation des usages le point de vue op rationnel Ce chapitre introduit le concept d usage que nous avons adopt pour caract riser la m diatisation des pratiques m tiers par des outils num riques Concevoir un usage consiste consid rer l acteur d un projet comme utilisateur d un outil puis d finir l interaction entre les deux la mani re dont est trait e l information m tier num ris e ainsi que le contexte de l usage La construction d un m ta mod le d usage nous permet de caract ri
169. assurer Chapitre 3 Probl matique et m thode de travail EM Vefficacit et la tra abilit des changes Nous introduisons les services collaboratifs dans le chapitre 6 et les int grons dans notre approche dans le chapitre 11 1 7 2 Formulation dela probl matique A partir des l ments introduits dans les chapitres pr c dents nous sommes en mesure de d terminer les axes de recherche investiguer dans la suite de ce travail l analyse des besoins et la conception logicielle La question que nous nous posons est la suivante Pouvons nous proposer une m thode structur e et bas e sur l analyse du contexte tri facettes pour le d veloppement ou la mise a jour de services informatiques supportant les besoins de collaboration ou services collaboratifs propres au projet AIC Avant de nous pencher vers l tat de l art sur les m thodes et les cas pratiques de conception logicielle et plus particuli rement de services collaboratifs nous pr sentons dans le sous chapitre suivant notre m thode de recherche introduite par une approche th orique sur la conception Nous souhaitons en effet nous inscrire dans une d marche scientifique qui nous permette de g n raliser notre approche notamment vis a vis des ventuels besoins d autres domaines que le projet AIC 1 8 M thode de recherche Au regard de la probl matique formul e nous avons men une tude sur les processus de conception Not
170. ations trait es Parmi les formes que prennent les objets on retrouve les objets d interface communs comme les ic nes les fen tres les curseurs les boutons On trouve ce type d objet dans toute interface graphique D autres formes sont relatives au domaine li et notamment la nature des changes dans le m tier consid r comme par exemple les l ments de dessin compos s de points de lignes de surfaces de formes d espaces Vu les multiples moyens possibles pour d finir ces l ments de dessin l attribut forme est ditable par un texte libre Les couples donn e forme sont vari s et permettent de traiter de multiples cas de figure dans la sp cification de l information m diatis e avec laquelle l utilisateur interagit Le Tableau 23 illustre trois exemples de donn es d finies conform ment a la caract risation que nous venons de faire par leur nom leur type leurs attributs si non primitive et dans le cas pr sent deux formes ou repr sentations possibles Tableau 23 Exemples de donn es et d association de formes Type de donn e Attributs possibles Formes possibles Donn e manipul e Document Fichier Nom type fichier Ligne dans un tableau taille date cr ation Ic ne texte Mur Building Longueur largeur Dessin 2D surface Information composition Dessin 3D forme coefficient thermique Quantit de b ton Valeur Donn e primitive Curseu
171. atiques de travail varient Parall lement de nombreux services sont propos s et utilis s pour assister la collaboration certains sur un mod le grand public et d autres plus orient s vers un usage professionnel L exp rience CRTI weB est un projet de d veloppement d un collecticiel men avec et pour les professionnels du secteur au Luxembourg Il propose actuellement deux services dans sa version commerciale le service d changes et gestion de documents plans documents techniques et le service de r daction et gestion des rapports de chantier Malgr l tude des besoins m tiers men e en amont du d veloppement l outil pr sente cependant des manques d adaptation Ce constat d inadaptation n est pas un cas isol il refl te une lacune g n rale de ce genre d outils satisfaire pleinement les attentes des professionnels C est pourquoi ce travail doctoral propose un cadre d analyse support par la mod lisation des comportements des utilisateurs Nous adoptons alors plusieurs points de vue relatifs diff rents champs de recherches le g nie logiciel la conception d interfaces homme machine l entreprise orient e services et la conception de syst me d information et enfin le travail collaboratif assist par ordinateur TCAO D un point de vue organisationnel nous identifions les pratiques collectives exerc es par les groupes d acteurs impliqu s dans le projet Nous en d duisons ensuit
172. au contexte Les outils propos s pour assister les activit s des acteurs d un projet AIC sont d velopp s de mani re tre adapt s au secteur L adaptation d un outil est la mani re dont celui ci r pond aux besoins de ses utilisateurs Nous verrons que ces besoins sont troitement li s la notion de contexte Kubicki 2006 pr sente le concept de contexte tri facettes compos des trois contextes d finissant le rapport d un acteur son activit au travers des outils qu il manipule Ces trois contextes sont Figure 10 Chapitre 1 La coordination dans les projets de conception construction architecturale le contexte acteur qui caract rise les intentions et les pr f rences de l acteur qui appr hende l outil le contexte utilisateur qui caract rise l interaction avec l outil l outil lui m me mais aussi son environnement le contexte de l activit collective caract risant le projet 2 Contexte Acteur Dimension cognitive a H pe 1 Contexte de l activit Dimension collective Outil Figure 10 Le contexte tri facettes selon Kubicki 2006 Afin d tre m diatis par l outil le contexte de l activit doit tre connu et caract ris Cela fait l objet des tudes cit es pr c demment cf 1 1 Les r les et exp riences dites m tier de l acteur sont les facteurs d terminants de son contexte Ils vont grand
173. au cours des chapitres pr c dents pour illustrer nos propos Initi tr s t t dans les phases de proposition de ce travail de recherche il nous a servi composer les m ta mod les choisir les formalismes pour les mod les et d finir la structure de la m thode PUSH Le besoin remont au travers des ateliers avec des utilisateurs tait celui de pouvoir partager plusieurs documents la fois sur la plateforme CRTI weB sans r p ter le processus de d p t d un document depuis le d but Il s agissait donc d un besoin d optimisation de la mani re dont les Chapitre 12 La m thode PUSH exp rimentations et bilan utilisateurs travaillent avec leur outil De nombreux services de partage de documents permettent actuellement ce genre de manipulation Cependant il s est r v l pertinent de mettre en place notre m thode afin d identifier des exigences plus sp cifiques au secteur que celles relatives a des services informatiques plus g n ralistes Dans un contexte march avec une approche commerciale la d marche propos e devait permettre de lever le risque d engager des co ts de d veloppement dans une solution qui pourrait s av rer inadapt e Cet argumentaire a convaincu notre partenaire priv la soci t de services externe qui s est pr t au jeu de l exp rimentation travers notamment trois s ances de travail Figure 124 Objet des s ances de travail La premi
174. aux La construction qui contient la mise en chantier et le chantier pendant laquelle les diff rents corps de m tiers r alisent les travaux et rigent le b timent con u Les constructeurs sont engag s par le moyen d appels d offres Il est de la responsabilit du coordinateur de r partir les diff rentes interventions et de suivre le d roulement du chantier L exploitation qui fait suite la r ception du b timent et comprend la v rification la gestion et la maintenance de celui ci http fr wikipedia org wiki Activit Chapitre 1 La coordination dans les projets de conception construction architecturale La fin de vie d un batiment est souvent vue comme la derni re phase du projet Nous pr f rons la consid rer comme un nouveau projet en soi avec sa propre tape pr paratoire support e par l tude de l existant et des solutions adopter suivie d une tape op ratoire la mise en uvre des travaux de requalification ou sa d molition Le concept de t che Lorsqu on parle de la r partition du travail dans un projet aussi appel e coordination du projet on utilise plus commun ment le terme t che Une t che est une fraction d activit attribu e un membre du projet Ce fractionnement diff re selon la nature de la r partition Kvan 2000 Henri amp Lundgren Cayrol 2001 Kubicki 2006 Piquet 2009 Malone amp Crowston 1994 la d finissent de mani re g n rale comme
175. aux aspects d accessibilit et de s curit Assurer le rendement conomique les acteurs et particuli rement les concepteurs doivent contr ler le budget du projet en maitrisant les co ts qu impliquent leurs choix Ils chercheront aussi rendre le b timent construit plus rentable dans le temps en assurant sa flexibilit et son adaptabilit plusieurs usages surtout pour les b timents publics Assurer la qualit du site en accordant de l importance sa localisation et aux divers risques li s la qualit de l environnement l acc s aux transports aux services et infrastructures pr sentes Assurer la qualit socioculturelle du projet en mesurant et en prenant en compte son impact sur la population environnante sur les administrations particuli rement pour les projets de grande envergure ou caract re exceptionnel Nous avons cherch identifier les pratiques g n ralement mises en place pour atteindre ces cinq objectifs au cours d un projet Ce travail s est d roul sur la base de deux brainstormings avec respectivement 3 et 2 architectes Pour chaque objectif il tait question de recueillir leurs exp riences habitudes et anecdotes Nous avons synth tis ces informations en 11 familles de pratiques distinctes La description qui suit comprend pour chaque famille de pratique un texte explicatif d crivant son d roulement puis un tableau comprenant un r sum des r les impliqu
176. avers les concepts de pratiques et usages La correspondance entre pratiques et usages peut suivre plusieurs sc narii qui ont t envisag s lors de la conception du m ta mod le d usages MMU Nous montrons ainsi que trois relations ont un sens dans un contexte de collaboration outill par les services informatiques Figure 129 un usage est d fini par pratique plusieurs usages ou variantes d usage sont envisag s pour une m me pratique le m me usage m diatise plusieurs pratiques Pratique Individuelle 1 m diatise Figure 129 Rappel relation entre les concepts d usage et de pratique telle que caract ris e par le MMU Chapitre 12 La m thode PUSH exp rimentations et bilan Le concept de pratique permet d associer les requ tes de la part des utilisateurs a des besoins m tiers g n ralisables et ainsi de les justifier aupr s des d veloppeurs A ce propos le diagramme de pratiques propos 1 40 2 pour retranscrire les besoins s est av r compr hensible et utile La d finition pr cise du contexte de l usage avait peu d int r t ici car le contexte tait connu des d veloppeurs qui assurent d j la commercialisation de l outil les ateliers de formation et le recueil des retours des utilisateurs Il permet cependant a posteriori de garder une trace des choix effectu s Le contextual use case tait compr hensible mais s est av r peu utile Seule la partie dia
177. avons pu faire ressortir les avantages et limites I compl te notre analyse men e au travers des chapitres 4 5 et 6 sur le GL les IHM les SI et le TCAO De mani re g n rale ces m thodes nous permettent de comprendre le d roulement d un processus de conception dans un cas concret d application Elles ne semblent cependant pas faire leurs preuves dans des cas r els de projet de conception et transfert des services a savoir dans le but de r pondre aux besoins sp cifiques d un domaine professionnel et dans des conditions r elles de d veloppement De plus chacune couvre un contexte technologique tr s pr cis ce qui limite leur extension dans des domaines vari s Pour approfondir certains des points d int r ts voqu s ou pallier a certaines des limites percues nous proposons de d finir le cadre de notre approche sur la base des hypoth ses suivantes Une analyse m tier doit tre bas e sur la mod lisation de situations collaboratives pr cises et non sur la surmod lisation de processus complexes Les mod les graphiques favorisent la synth se et la compr hension ils sont particuli rement adapt s la mise en correspondance de concepts entre plusieurs mod les Les mod lisations litt rales fournissent quant elles de l information pr cise et en grande quantit Il sera judicieux de combiner les deux en fonction de l information mod liser Le couplage tardif entre exigences et aspects te
178. aye d ouvrir un fichier auquel ne peut normalement pas acc der afficher un message indiquant que ce T che syst me 285 document n est pas ou plus accessible et T che d avertissement Meilleure compr hension faire appara tre une liste des organismes 287 supprim s pour r activation 293 croix si organisme non vide NIL Suppression d une ic ne inutile Permettre importation utilisateur T che Traiter acteurs 296 pr alablement compl tement supprim Contenu supprim Gain de temps Importation organismes pr alablement T che Traiter acteurs 299 compl tement supprim Contenu supprim Gain de temps Recherche de remarques lien vers les Consulter les Ouvrir document apr s 307 remarques trouv es commentaires des T che recherche Gain de temps Figure 144 Grille d analyse des tickets partie 2 4 De Annuaire des participants au projet au Consulter la liste des Nouvel usage d export Information dans un format 320 format PDF Oui collaborateurs G n ral au format pdf appropri l change D p t document possibilit d p t au Partager des 322 niveau sup rieur i informations avec un Cr ation import organisme associer la CN Impliquer un acteur ou Tache Convention de 326 OAl par d faut un groupe dans le projet Contenu nommage pr d finie Gain de temps ER PS eee ee 327 Service CR mod ration commentaires commentaires management facilit issie non ou nn a 328 Service Document
179. bel progress bars checkbox go Name Document name Attributes Name file type Graphical spec text fields and combo boxes Attributes primitive data Data type text jn Oven ESS er me ps 4 a Concrete user interactin type Trigger lt lt Qutil gt gt nom CRTI we8 Etope 1 S l ction du ou des fichiers L lt lt Sarvics m tier gt gt nom documents Description le service m tier documents de la plateforme CRTI we permet la l change la tra abilit et la gestion des documents d un projet de struction men L lt lt perception task gt gt vue fies J x C M me document plusieurs fichiers Files size must not exceed 70Mo O Phisieurs documents ind pendants lt lt action gt gt createziPCIP i lt lt action gt gt i credecnTineb nconert deceit Figure 121 Correspondances entre la mod lisation des Pe des usages et des services Chapitre 12 La m thode PUSH exp rimentations et bilan 1 39 2 Contexte des exp rimentations Pour rappel notre travail s est inscrit dans le cadre du d veloppement de la plateforme de gestion documentaire CRTI web Les exp rimentations men es se sont inscrites dans ce contexte technologique particulier les deux premi res exp rimentations concernent l am lioration du service m tier Doc
180. besoins et en documentant ces informations dans un formulaire propice l analyse la communication et une ult rieure impl mentation Yeh amp Zave 1980 identifiaient d j il y a 30 ans que la plupart des probl mes de d veloppement de syst mes informatiques pourraient tre assign s a une mauvaise compr hension ou sp cification de ce que le syst me est suppos faire Ils soulevaient ainsi l importance de traiter avec attention la phase de connaissance du besoin ou phase d expression des exigences compos e de l identification du besoin il s agit d identifier et d crire les objectifs qui requi rent l utilisation d un syst me sous diff rentes formes interviews groupes de travail la compr hension du besoin il s agit de collecter et d analyser de l information propos du syst me de son environnement et des interactions entre les deux la sp cification du besoin il faut alors d crire le comportement d sir du syst me On pourra rencontrer le terme requirements elicitation pour ce qui est de l identification et la compr hension de l existant Loucopoulos amp Karakostas 1995 La formalisation des exigences sp cifications y comprises se fait travers un Document d Exigences Logicielles SRD pour Software Requirements Document Le SRD exprime ce que le syst me doit faire mais pas comment cette question tant relative la conception Il est le moy
181. cas d utilisations use cases une d finition du contexte travers des tableaux des mod les de t ches IHM d taillant chaque use case et si besoin des maquettages pour les illustrer une d finition du contenu travers des tableaux d crivant l information produite et ou utilis e NB Dans le cas ou une caract ristique ne peut tre d finie cela sera pr cis par une des 2 mentions suivantes NIL pas de r ponse possible ex le syst me ne poss de pas de type d entr e vid o NC r ponse non communiqu e ex le syst me poss de peut tre un type d entr e vid o mais on ne sait pas laquelle L gende et pr cisions Le diagramme de cas d utilisation use case diagram L acteur est d finit par son r le aa organisationnel Chaque op ration devient Q f _1 un paquet package de cas d utilisation use A PK intention utisateur gt i lie ur cases Les paquets des op rations a NTT sp cifier sont repr sent s dans le syst me et d compos s Le syst me peut aussi Y D C_ intention utilisateur gt Paquet ne pas ee a contenir des paquets de cas d utilisation issus d aucune op ration m tier mais _ n anmoins n cessaires et donc d finir Les paquets des op rations non trait es sont a Op rations m tiers quant eux situ s l ext rieur du syst me S Cas suppl mentaires Le contexte
182. ces d int ractions d 6tat Mod lise les tats et les transitions d un objet d une classe donn e d activit Mod lise les flux d activit pour une proc dure donn e Noran 2000 confronte UML et IDEF ICAM DEFinition qui est aussi une suite de m thodes de mod lisation et supporte la conception de syst mes et l analyse m tier en 3 tapes 25 IDEF3 pour la description de processus et des objets et IDEFS pour la description d ontologies mod lisent le monde r el et les relations entre les acteurs les v nements IDEF0 mod lisation des fonctions et IDEF1 mod lisation de l information mod lisent les exigences relatives la gestion de l information IDEF1x mod lisation des donn es IDEF2 mod lisation de la dynamique des syst mes et IDEF4 Conception Orient e Objet supportent la conception du syst me r pondant aux besoins identifi s pr c demment Symboles UOB Labels Nose Rete wer Ret Liens y Simple Precedence Link gt 4 Constraint Precedence Link __ Relational Link Jonctions AND I amp I Synchronous AND o OR fol Synchronous OR Figure 51 Un exemple de diagramme IDEF3 pour la description des processus Noran 2000 Pour Integrated Computer Aided Manufacturing un programme de l US Air Force Chapitre 5 De l entreprise orient e services la conception de Syst mes
183. chniques assure la possibilit d tendre l approche diff rents domaines m tiers comme diff rents contextes technologiques Se concentrer sur la notion d information manipul e travers le concept d objet permet de traduire l espace organisationnel en espace interactionnel avant de d finir les services d un point de vue fonctionnel Plusieurs espaces interactionnels et fonctionnels peuvent correspondre plusieurs espaces organisationnels en fonction des variations de contexte que ce soit celui de l activit de l acteur ou de l utilisateur Chapitre 7 Les m thodes de conception de services tudes de cas A partir des diff rents concepts qui mergent de nos analyses nous proposons une approche structur e bas e sur un cheminement d tapes relatives a trois points de vue Figure 76 76 Le point de vue organisationnel Nous souhaitons tre plus pr cis que lors de l nonc de besoins ou de principes g n raux relatifs a la collaboration mais sans atteindre la rigidit des processus Nous nous concentrons sur l analyse des r les et activit s m tiers des utilisateurs dans une quipe de projet AIC Nous adoptons le concept de Pratiques m tiers Collectives et Individuelles Le point de vue op rationnel Nous consid rons ici les personnes en tant qu utilisateurs de diverses technologies et dans des contextes d utilisation relatifs au projet AIC pour concevoir un sc
184. cibl s Il s agit de mener des processus de d veloppement plus courts afin d en faciliter le d roulement et la tra abilit Nous remarquons dans Eastman amp Sacks 2010 que les processus de PIDM mod lisent galement l information qui n est pas chang e travers des mod les Cela permettrait d tendre le champ d application en dehors du BIM et nous y voyons un int r t pour la sp cification de services IT plus vari s relatifs d autres technologies collecticiels applications mobiles L approche IDM ne s tend pas sur la proposition de services autres que le BIM pourtant elle pourrait y contribuer En effet elle fournit une analyse m tier coh rente et compl te qui pourrait tre int gr e aux m thodes plus g n rales de G nie Logiciel et de conception de services Cela Chapitre 7 Les m thodes de conception de services tudes de cas serait notamment profitable aux professionnels du secteur a court terme en attendant la d mocratisation du BIM et des IFC qui se fait lentement 1 22 Conclusion et mise en place de la m thode Le but de cette partie tait d introduire la conception de services collaboratifs pour comprendre la d marche suivre dans le d veloppement de notre propre m thode de conception Notre objectif est de r pondre aux probl matiques sectorielles d taill es au chapitre 3 notamment au 1 72 Ce chapitre d taille trois m thodes de conception dont nous
185. cinq phases Connaissance du probl me cette phase fait ressortir un besoin et fixe les objectifs et les contraintes Suggestion c est la phase cr ative qui suit directement l expression de l id e En ressortent un premier essai une esquisse de solution D veloppement la suggestion est approfondie et impl ment e Les techniques utilis es et les artefacts cr s sont d pendants du domaine valuation l artefact cr la phase pr c dente est valu en fonction des objectifs fix s en premi re phase Conclusion il s agit de dresser le bilan et de capitaliser les r sultats Flux de Etapes du R sultats connaissance processus p7 S Connaissance t ga 1 p Proposition i du probl me I i H i l I I i l I Suggestion I Premier jet LS mn mu ns me LA d Circonscription D veloppement Artefact Evaluation Performances Connaissance sur les Mesures op rations et objectifs Conclusion R sultats Figure 15 Processus de conception flux de connaissances et r sultats tir de Vaishnavi amp Kuechler 2007 Nous remarquons que chaque tape d un processus de conception g n re un flux de connaissance qui alimente la connaissance globale du probl me encourageant le raffinement des choix au fur et mesure des it rations de ce processus Chapitre 3 Probl matique et m thode de travail 1 8 2 Concevoir une m thode de conception A partir des l ments qui
186. clure les pratiques de conception des syst mes de r alit mixte comprenant les syst mes de r alit augment e et les interfaces tangibles Elle propose ainsi une m thode de d veloppement compl te et appliqu e un contexte technique particulier Nous nous sommes particuli rement concentr s sur la branche fonctionnelle branche gauche en cherchant identifier comment elle allie des pr occupations la fois logicielles et interactionnelles pour r pondre des besoins m tiers La branche technique nous apporte en outre des l ments de description du contexte utilisateur Chapitre 7 Les m thodes de conception de services tudes de cas Une phase pr liminaire a pour but d analyser le m tier tel qu il est pratiqu par le client demandeur d une solution logicielle afin d identifier les processus m tier et leurs participants Ces processus sont compos s d activit s d clench es par un input ou un v nement La m thode Symphony propose une description de ces processus sous forme de sc narios en langage naturel Cette phase est la responsabilit des experts m tier et des experts en utilisabilit qui collaborent pour capturer les prescriptions bas es sur l impl mentation actuelle du processus m tier et pour la d finition d un cadre de r f rence de l utilisateur de l application Dans le cas d application illustr dans Dupuy Chessa et al 2010 l objectif est de d velo
187. conception logicielle par l analyse de trois l ments principaux les t ches le contenu et le contexte Nous nous servirons de ces trois concepts pour caract riser l usage la lumi re des diff rentes tudes de l tat de l art analys Chapitre 10 La mod lisation des usages le point de vue op rationnel Les t ches d finissent l interaction entre l utilisateur et l outil Elles d taillent cette m diatisation en d crivant le comportement de l utilisateur et de l outil lors de l usage Nous utiliserons plusieurs niveaux d abstraction pour d finir ces t ches L information manipul e lors de l ex cution des pratiques est aussi m diatis e par l outil travers son usage C est ce que nous appelons le contenu d interaction Il est compos d objets les objets d interaction qui sont d finis par une donn e ce qui est manipul et une forme comment il est repr sent Le contexte de l activit collective et le contexte de l acteur deux des trois parties du contexte tri facettes cf 123 sont caract ris s par le M ta Mod le des Pratiques M tier au travers des concepts de Pratique Collective et Individuelle Il s agit pr sent de caract riser la troisi me partie qui correspond au contexte utilisateur Conform ment notre terminologie nous l appellerons ici le contexte d usage 1 32 Le m ta mod le des Usages partir des d finitions que nous venons
188. cours de notre implication dans le projet ce qui nous a fourni un contexte d observation privil gi Conception Transfert Experts m tier Utilisateurs lt services CRP Henri Tudor Kitry Consulting Professionnels Figure 14 Sch ma du processus de conception d veloppement et transfert des services de CRTI weB Nous nous questionnons d s lors sur la d pendance entre la qualit des solutions d velopp es et la qualit de la coordination au sein de ce processus de conception De mani re g n rale la qualit d une solution en termes de services informatiques sera valu e par les utilisateurs qui jugeront de la r ponse de la capacit de ce service r pondre leur besoin la qualit de la coordination sera d termin e par la capacit des diff rents acteurs du projet exprimer leur point de vue Hanrot 2005 et r pondre aux attentes de chacun 1 6 Conclusion Les observations que nous venons de faire et les remarques soulev es nous permettent pr sent de cadrer les objectifs relatifs l am lioration de CRTI weB et de mani re g n rale au d veloppement d un outil de TCAO Ce type de d veloppement doit tre guid par des exigences clairement identifi es et justifi es En effet il ne s agit pas de d velopper des services que l on devra modifier voir supprimer dans un second temps car ils seront inutilis s Ce genre de m thode s av re trop longue et couteuse La
189. ction Pourtant ces diff rents termes se rapportent a des concepts sensiblement diff rents Nous pouvons trouver des premiers l ments de d finition plus distinctifs dans la th orie de l activit Elle tire ses origines des travaux du psychologue Lev Vygotsky sur la dynamique de l activit humaine et fut reprise par Leontiev 1978 qui distingue trois concepts l activit l action l op ration voir Hanser 2003 L activit est un processus de transformation visant atteindre un objectif g n ral et d coup en plusieurs tapes ou phases Les actions sont la d composition d une ou plusieurs activit s en processus conscients et r fl chis En d autres termes une action est la mat rialisation d une volont d atteindre un objectif ou une partie d objectif au travers d un processus dans lequel on value l objectif on ex cute l action et contr le si l objectif t atteint Les op rations sont les m canismes qui composent l action et qui sont r alis s de mani re inconsciente Cependant comme le soul ve Hanser 2003 il est difficile de cerner les limites entre ces trois concepts Par exemple selon ces d finitions le projet de construction d un b timent est lui m me identifi comme activit Il est cependant d coup en sous activit s relatives des sous objectifs comme r duire les couts ou atteindre une performance thermique De m me il est difficile d
190. ctivit collective en le m diatisant il aide les acteurs r aliser leurs activit s et g rer les artefacts du projet Il est vu comme un moyen et non comme un devoir Prendre en compte le contexte utilisateur consistera donc 4 comprendre les possibilit s techniques dues a l outil et son environnement et percevoir en quoi il supporte une activit et dans quelle mesure il est perfectible ou rempla able D s lors plusieurs concepts apparaissent comme importants En voici une br ve introduction nous les approfondissons dans les diff rents chapitres de l tat de l art chapitres 4 7 pour ensuite les int grer dans notre approche chapitres 8 11 Le concept de pratique Les activit s de projet sont des activit s cr atrices En d autres termes elles ne rel vent pas de la th orie mais de la pratique Nous venons d introduire lors de la description de l exp rience CRTI weB le concept de bonnes pratiques Elles font r f rence ici des astuces Chen 2009 des pratiques qui ont fait leurs preuves comme par exemple la r union hebdomadaire de chantier suivie de la r daction d un rapport de chantier Selon Clot 2007 la bonne pratique serait la transformation collective institutionnellement second e de l activit en instrument d une autre activit Dans CRTI weB ces bonnes pratiques devaient en plus tre consensuelles Nous retenons ce point de vue pa
191. cution Beaucoup d ajustements sur chantier sont informels ces modifications de petite Chapitre 9 La mod lisation des pratiques le point de vue organisationnel envergure ne sont pas consign es dans les plans ou les comptes rendus mais sont effectu es partir de remarques orales Le Maitre d ouvrage peut galement intervenir en cas de litiges Tableau 20 l ments de caract risation de la PC9 Acteurs impliqu s Documents utilis s Activit s Ma tre d uvre Plans d ex cution T ches de construction Coordinateur Documents techniques d valuation et de Ma tre d ouvrage et Planning coordination assistants CR de chantier Phase chantier Entreprises PC10 valuation de l ex cution et compte rendu Description valuation du b timent en cours d ex cution et juste avant la livraison revient au coordinateur et aux divers experts Le coordinateur rel ve les malfa ons en cours de chantier et les transmet aux entreprises responsables ils pourront tre sujet de discussion lors des r unions de chantier Les experts en s curit et sant v rifient que les normes sont respect es pendant la mise en uvre port du casque filets de s curit etc et lors de la livraison garde corps sorties de secours Les experts en thermique ou acoustique effectuent les tests n cessaires pour valuer les performances du b timent en particulier en cas d attribution d
192. d un syst me a celle d une interface graphique compos e de fonctionnalit s souhait es mais dont l adaptation aux besoins ne peut tre valid e L int gration du maquettage apr s une tude des pratiques m tiers suivie d une identification des intentions et t ches utilisateurs li es permet de limiter les propositions ce qui est n cessaire Chapitre 10 La mod lisation des usages le point de vue op rationnel Etape 1 S l ction du ou des fichiers Fichier 1 a OOOO 7 Fichier 3 Saas OOO o Etape 2 Liaison multi fichiers C M me document plusieurs fichiers C Plusieurs documents ind pendants Figure 108 Maquettages des t ches concr tes loading visualization et clustering mode selection 1 33 3 Int gration dans le cahier d exigences La mod lisation de l usage est formalis e dans la seconde partie du cahier d exigences Le diagramme de cas d utilisation contextualis et le tableau sp cifiant les relations avec d autres usages sont ins r s dans un premier temps Comme lors de l analyse des pratiques m tiers il est galement possible d ajouter de l information additionnelle Le but est de laisser aux concepteurs la possibilit de consigner les informations qu ils jugeront utiles mais que les mod les formalis s n auraient pas permis de prendre en compte Ces informations suppl mentaires pourront tre raffin es au fur et mesure des vers
193. de de conception particuliers Il se conclut par l vocation des l ments majeurs retenus comme base de notre propre m thode Chapitre 4 De l utilisateur la conception logicielle et d interfaces Ce premier chapitre retrace l volution de la conception logicielle et en d crit les activit s relatives Il a notamment pour but de souligner l importance de l analyse des besoins des utilisateurs pour la sp cification de logiciels et d interfaces homme machine IHM et d illustrer la place des mod les dans une telle approche 1 9 Les m thodes et activit s relatives la conception logicielle La conception logicielle s inscrit dans une approche classique de conception telle que d crite pr c demment Chaque phase apporte un l ment important dans le processus de la conception et sera d terminante dans la qualit du r sultat et l atteinte des objectifs Comme le dit Sommerville 1996 cit dans Dibbern et al 2009 p 13 l enjeu de l ing nierie logicielle est de permettre la conception de logiciels de qualit par l utilisation de techniques ou processus et d outils appropri s Dans le cadre d une organisation la conception logicielle consiste aussi comprendre comment les syst mes homme machine produisent et diffusent de l information et influencent les organisations dans lesquelles ils sont int gr s Vaishnavi amp Kuechler 2007 Le cycle de vie du d veloppement d u
194. de la proposition chapitres suivants d taillant ces trois concepts et leur mod lisation se terminera par une section illustrant l insertion des mod les dans le cahier d exigences Enjeux et utilisation du document Dans la composition de notre document nous avons souhait pallier deux probl mes galement reconnus dans Paetsch et al 2003 la constitution d un tel document dans les m thodes agiles est souvent jug e trop compliqu e voire infaisable les mod les produits sont ph m res et ne rentrent pas dans la documentation du syst me Le cahier d exigences que nous proposons se veut simple lire et diter de par la pr sentation d information sous forme graphique et structur e dans un format de document court environ 10 pages Ce document a t pens comme une source d informations qui alimente les travaux de d veloppement lors de la proposition de services adapt s au contexte m tier I doit permettre galement la justification de ces d veloppements posteriori Les enjeux de ce document sont le transfert vers les d veloppeurs et la tra abilit des choix Il est destin Aux analystes m tier pour consigner les mod les des pratiques tudi es aupr s des futurs utilisateurs L quipe actuelle ou une future de d veloppement s y r f rera en cas de doute sur les origines m tier des d veloppements Aux concepteurs en collaboration avec les analystes p
195. de paradigme dans l ing nierie logicielle dans lequel le service est une abstraction utilis e pour supporter le d veloppement rapide et peu on reux d applications travers la composition de services Nous comprenons ici que la conception d un SI est une activit de conception logicielle qui suit les principes de d veloppement utilisant des techniques d abstraction par les mod les Loniewski et al 2011 mais qu elle adopte un autre point de vue Selon Papazoglou amp Van Den Heuvel 2006 la m thodologie de la conception et du d veloppement orient e services SODD se base sur les mod les de d veloppement logiciel tels que le d veloppement orient composant et le RUP voir 2 1 1 tout en se concentrant sur la mod lisation des processus m tiers dans le domaine de l entreprise Dans le m me ordre d id e Hussain et al 2010 effectue galement un mapping entre le framework de d veloppement de service SOMA Service Oriented Modeling and Architecture Arsanjani 2004 et le RUP cf en mettant en parall le les phases de conception de service du framework Identification Chapitre 5 De l entreprise orient e services la conception de Systemes d Information Sp cification R alisation D ploiement et les phases de conception logicielle du RUP Inception Elaboration Construction Transition Trois niveaux d abstraction de la conception de SI sont pr sent s dans Front et al 2009
196. der consideration Number of remarks for each room of the floor on a 30 modal YI List List of remarks concerning the room under corsideration number litle responsible location prionty level date of detection lead time date of closure photo V2 30 model position of The user on site Highlighting of the room under consideration Number of remarks for the room under consideration and location of the remarks on a 30 model Building Room gt tariteom mr rm dome Comers a baranem Aro Sanr Ome tt a des x C itf YIL List of remarks concerning the building element under consideration mumber tite responsible location prionty level date of detection land time date of closure photo comments history V2 Position of the user on site Highlighting of the building element under consideration Number of remarks for the buikiing element under consideration on a 3D model Building element Figure 137 Proposition d un nouvel outil sur la base de maquettages tir de Guerriero et al 2012 Ces maquettages sont des vues de l outil telles qu elles devraient se composer en fonction de l chelle consid r e ou niveau de d tail savoir le site le b timent l tage la pi ce et l ouvrage Ils sont compl t s par une description litt rale de l information afficher dans chacune de ces vues chacun de ces niveaux Du point de vue organisationnel il s agit d assist
197. des mod les coh rents assurant ainsi une certaine qualit du produit Quatre principes sont respecter ne pas bouleverser les pratiques des acteurs d un projet de d veloppement ce qui implique leur laisser leurs outils et leurs mod les permettre la synchronisation de ces acteurs sur des objectifs ou des mod les communs assurer la tra abilit et la coh rence entre les mod les Chapitre 7 Les m thodes de conception de services tudes de cas fournir des outils de support la m thode Chaque it ration dans l application de la m thode donne la priorit un processus m tier et suit un cycle en Y Figure 68 La branche fonctionnelle de gauche correspond la traditionnelle mod lisation des besoins du domaine travers des diagrammes de cas d utilisation et des sc narios et des utilisateurs diagrammes de t ches modalit s d interactions et maquettes La branche technique de droite permet aux concepteurs de concevoir les architectures techniques et logicielles Dupuy Chessa et al 2010 General requirements Functional Specificatons of Conceptual Requirements Specitications of Organizatonal and interactional Applicatrve architecture Technical architecture implementation Integration TERATION Figure 68 Cycle de Symphony tendue L extension Symphonie tendue compl te cette approche pour y in
198. des groupes de projet impliqu dans des t ches collaboratives Les pratiques individuelles raffinent ces objectifs du point de vue de chaque acteur consid r individuellement Elles sont davantage pr cis es par des op rations r parties en quatre familles et dont l ex cution a pour but de remplir l objectif identifi pour chaque acteur Chapitre 9 La mod lisation des pratiques le point de vue organisationnel Les pratiques et op rations d crivent finement le d roulement d une activit m tier mais elles sont pens es ind pendamment des outils qui seront utilis s pour effectuer cette activit que ce soient des outils mat riels ou logiciels Notre postulat est que cet outillage doit tre d fini posteriori L outillage consiste m diatiser chaque op ration acteur artefact ainsi que les espaces priv et de transition qui leur sont associ s rappel voir Figure 90 Les tudes sur le TCAO et notamment les dimensions fonctionnelles distance et temporalit nous permettront de cat goriser ces moyens de m diatisation Les trois sc narios illustr s dans la figure suivante montrent comment une m me pratique m tier peut tre m diatis e diff remment nous parlerons alors d usages diff rents L espace de transition y prend alors plusieurs formes et dimensions Par exemple dans le premier cas usage 1 il s agit de l entre deux dans le tr s court instant pendant lequel le document p
199. documents for designers team Chapitre 10 La mod lisation des usages le point de vue op rationnel La temporalit de l usage est identifi e comme effectu environ une fois par jour On imagine en effet qu la fin d une journ e de travail un concepteur veille partager ce qu il a produit Le lieu de l usage est l agence dans laquelle il travaille Il y a plusieurs r les op rationnels d finis sur la plateforme CRTI weB service document utilisateur classique qui peut utiliser tous les services de l outil partage de documents t l chargement ajout d actions etc le superviseur projet il peut en plus relancer des actions par exemple les demandes de validation auxquelles on n a pas r pondu administrateur du projet il peut ajouter des nouveaux utilisateurs au projet et cr er des nouveaux projets Ici nous consid rons l utilisateur comme un utilisateur classique classic user dont le r le organisationnel est celui de concepteur designer L usage de la plateforme demande que l utilisateur s identifie L application et le dispositif sont galement d finis conform ment la caract risation du m ta mod le Les relations entre usages La mod lisation des relations entre l usage sp cifi et d autres usages prend la forme d un tableau dans lequel on renseigne pour chacun d eux l identifiant du cahier d exigences qui les sp cifie l objectif de
200. du contexte m tier mais n cessaires la sp cification du service Ces use case non m tier sont relatifs ici l identification de l utilisateur le choix du dossier qui sera partag et le choix du projet CRTI weB sur lequel les documents seront envoy s Les deux autres packages d finissent le chargement et la suppression de fichiers sur CRTI weB partir du dossier partag Chapitre 12 La m thode PUSH exp rimentations et bilan Related Individual Practi Generate and share design ideas Usage Objective The user want to share multiple documents one CRTI weB without opening web browser yes Der technology JAVA interface PHP web services REST What do you know about the actor using the system Eventually precise here his skills knowledge abilities preferences The user is a student he has good skills in information technologies Considering CRTI web he doesn t need all Lenctionnalities but prefers a simple and quick sharing service What about the services to adapt Naming service must be simplified autor_name 8 letters _version What about the new services to develop A new application must be developed to check document addition modification suppression on shared folder This application requires some identification from the user When a document is put of shared folder while the computer is not connected to internet the system should memorize sharing and share the document whe
201. e tudes pr liminaires physique d utilisation Tests Smulations valuer les alternatives laboration Construction d interaction obtenir des informations suppl mentaires sur les pr f rences Tests et valuer l utilit Transition questionnaires Tests et valuer l utilisabilit Transition questionnaires 1 10 2 La mod lisation de l utilisateur et de son contexte Selon Dey 2001 le contexte regroupe toutes les informations qui peuvent tre utilis es pour caract riser la situation d une entit Une entit est une personne un endroit ou un objet qui rel ve de l interaction entre un utilisateur et une application eux m mes inclus Le mod le contextuel de Tazari 2003 contient par exemple le profil de ressources mat rielles et logicielles le profil de localisation c est dire la position de l utilisateur l instant pr sent heure date courante le profil de l utilisateur expert confirm novice dans l activit les pr f rences sur les applications param trage de la position des menus donn es sp cifiques aux applications les buts de l utilisateur Calvary et al 2003 regroupe ces informations travers trois concepts majeurs l utilisateur la plateforme logicielle et mat rielle et l environnement Dans le processus de conception des IHM la prise en compte d un ou plusieurs l ment s du contexte peut tre d terminante tou
202. e Elles peuvent tre propres un ou plusieurs r les mais toujours ex cut es de mani re ind pendante Celles ci sont caract ris es par les m mes attributs que les PC un nom et une description Une des PI qui composent la PC illustr e dans la section pr c dente peut par exemple tre d crite ainsi le concepteur partage des plans avec l ing nieur pour qu il v rifie la structure On peut la nommer plus simplement partage des plans Ainsi le m ta mod le des pratiques individuelles MMPI Figure 88 est une volution du m ta mod le des pratiques collectives ne figurent plus les diff rentes num rations pour faciliter la lecture Comme on peut le voir les relations implique dans le MMPC sont d taill es par des relations plus sp cifiques L acteur ex cute une pratique individuelle ex la production de plan d ex cution par le concepteur Une PI peu aussi concerner un ou plusieurs autres acteurs ex le partage de plans avec l entreprise Une PI produit des artefacts ou manipule ceux d j existants Une PI peut concerner une activit particuli re c est dire une t che dans une phase lors d un projet particulier Chapitre 9 La mod lisation des pratiques le point de vue organisationnel concerne implique Pratique Individuelle engendre concerne Groupe d artefacts type_groupe te
203. e compte rendu des d veloppements par les concepteurs et d veloppeurs peuvent se faire sur base du cahier d exigences cf section pr c dente Au fil des d veloppements des prototypages et d monstrations peuvent tre pr sent s pour tester le service en cours d impl mentation Des tests du service final sont effectu s par les concepteurs voire par les futurs utilisateurs avant le transfert du service La gestion des tests n est pas d crite dans la m thode PUSH Certaines m thodes agiles pr conisent la r daction des tests en m me temps que les besoins cf g 1 9 4 La figure suivante pr sente quelques captures d cran du service d crit pr c demment une fois impl ment Y sont repr sent s le choix d un nouveau partage cliquer sur ajouter un nouveau document le parcours des fichiers cliquer sur parcourir puis s lectionner les fichiers le choix du lien cocher l option les documents sont li s Le r sultat est comme sp cifi le partage d un fichier zip contenant les documents Chapitre 11 La mod lisation des services le point de vue fonctionnel uat crt web com index php 58 3 Projet istingDocuments Bj Les plus visit s _ D buter avec Firefox Aj la une Free Hotmail _ Suggested Sites J Web Slice Gallery EJ Conception col lt KP CERTE wyeB Chantier d valuation pour le CRP HT Y Gestion de Document Documents du projet
204. e de l ouvrage pour la passation du contrat de travaux les tudes d ex cution ou l examen de la conformit au projet et le visa de celles qui ont t faites par l entrepreneur la direction de l ex cution du contrat de travaux l ordonnancement le pilotage et la coordination du chantier l assistance apport e au maitre de l ouvrage lors des op rations de r ception et pendant la p riode de garantie de parfait ach vement Le r le op rationnel permet une distinction plus fine des acteurs dans le sens o il ne rel ve plus d une responsabilit vis vis du projet mais vis vis de l information Le r le op rationnel conditionne comme son nom l indique les op rations des acteurs sur les documents et sur l ouvrage Par exemple en ce qui concerne le document rapport de chantier le r le http www marche public fr Marches publics Textes Lois loi 85 704 MOP htm http www marche public fr Marches publics Definitions Entrees Ma tre oeuvre htm Chapitre 1 La coordination dans les projets de conception construction architecturale op rationnel de r daction est attribu au coordinateur alors les autres acteurs n auront qu un r le de consultation voire de commentaire D un point de vue administratif les acteurs en tant qu individus et organisations sont identifi s par un titre En ce qui concerne l individu ce titre d pend de sa formation et correspond son m tier ex architec
205. e des d veloppements men s en fonction des exigences Elle a permis d exprimer les choix effectu s en termes d impl mentation mais aussi de se questionner sur la gestion de certains cas d erreurs En effet si le point de vue op rationnel exprime des sc narios id aux d usage le point de vue fonctionnel doit prendre en compte toutes les possibilit s a impl menter y compris les manipulations non pr vues Au cours des d veloppements ces phases de pr cision se sont r it r es jusqu a obtenir un service qui r ponde soit fonctionnel en plus de r pondre aux exigences initiales Upload automatique crti web milieu tudiant Premi re r union d quipe Pr sentation du contexte g n ral gt D couverte de la technologie Deuxi me r union d quipe Discussions sur base du cahier d exigences D veloppements en cours Discussion sur base du cahier d exigences Gestion des cas d chec l l l l Trois me r union d quipe l l D veloppements finalisation Mars Figure 130 D roulement de l exp rimentation 1 41 2 Un nouvel usage d upload La pratique analys e dans cette exp rimentation est une pratique de partage de documents proche de celles que nous avons d crites dans l exemple pr c dent Sa sp cificit est qu elle se d roule dans un milieu universitaire et non dans un contexte professionnel habituel Figure 131 Il s agit en effet d un projet universitaire de conc
206. e en tant qu expert m tier Ce r le d expert a pour but d analyser et comprendre les besoins des professionnels d un domaine afin de les capitaliser et les transf rer pour la conception de solutions adapt es 1 5 2 Analyse de l utilisation L outil CRTI weB a fait l objet de plusieurs tests du cadre d valuation de prototype celui de feedbacks utilisateurs en utilisation r elle dans des projets AIC ou lors d ateliers de formation Le public valuateur est compos la fois de professionnels du secteur architectes entreprises de construction et Ma tres d ouvrage et des tudiants en architecture des universit s de Nancy et Li ge les tudiants ont valu uniquement le service documents Les premiers r sultats sont publi s dans Guerriero 2009 Kubicki et al 2009 mais d autres enqu tes ont donn lieu de plus r cents constats sachant que l outil fait l objet d am liorations constantes L valuation du service Comptes rendus en situation d atelier montre que l outil appara t fiable facile utiliser compatible avec la pratique professionnelle et que l apprentissage ne n cessite pas d investissement personnel important Pourtant en situation r elle il ne trouve pas sa place Une des r ponses formul es est largement li e la difficult de modifier les usages internes En effet il semble que les personnes aient adopt l utilisation syst matique des mod les
207. e les pratiques individuelles savoir les responsabilit s de chacun en fonction de son r le dans le groupe D un point de vue op rationnel nous nous int ressons la m diatisation de ces responsabilit s par l usage de diff rentes solutions technologiques La caract risation de ces usages est li e la notion de contexte le contexte technique mat riel logiciel le contexte spatial localisation environnement le contexte temporel fr quence r gularit synchronisation Enfin le point de vue fonctionnel vise d finir le service utilis c est dire le comportement non plus de l utilisateur mais du syst me qui r pond son besoin Nous proposons la m thode PUSH Practices and Usages based Services enHancement qui orchestre ces diff rents points de vue et permet de g n rer un ensemble d exigences pour le d veloppement de services dits adapt s Communication et tra abilit sont les maitres mots de cette m thode de conception Le contexte d tude la fois orient recherche et d veloppement nous a permis d valuer et d am liorer la d finition des concepts mis en avant ainsi que la mise en place de la m thode PUSH travers trois exp rimentations Mots cl s Construction Pratiques m tiers Services collaboratifs G nie Logiciel Interfaces Homme Machines Conception centr e usages Science de la conception Mots cl s RAM EAU Logiciels de groupe Logiciels D velop
208. e op ration m tier comme par exemple les cas de configuration s identifier param trer Ces cas d utilisation qui doivent pourtant tre sp cifi s sont distingu s par un package bleu Paquet 4 sp cifier 1 i intention utilisateur Paquet sp cifier 2 intention utilisateur Paquet ne pas sp cifier E Op rations m tiers H Cas suppl mentaires Figure 102 Adaptation du formalisme des diagrammes de cas d utilisation A ce niveau d analyse nous d crivons galement le contexte de l usage Ici le formalisme utilis est un tableau ditable par listes de choix multiples ou par champs d dition libres La composition de ces deux mod les c est dire le diagramme de cas d utilisation et le tableau forme ce que l on a appel le diagramme de cas d utilisation contextualis s en anglais contextual use case Le cas d utilisation contextualis illustr ci apr s Figure 104 repr sente un exemple d usage particulier d un utilisateur de CRTI weB pour accomplir une pratique que nous avons mod lis e dans le chapitre pr c dent La pratique consid r e ici est diffuse les documents de conception l quipe de conception Figure 103 Au cours de cet usage l utilisateur souhaite partager plusieurs fichiers intention upload multiple files mais attend de l outil qu il groupe les fichiers choisis en un seul document CRTI weB t che ou
209. e op rationnel prend en consid ration la m diatisation des pratiques par les usages d outils d di s Les outils qui nous int ressent particuli rement sont les outils d assistance la collaboration dont notamment les plateformes d change de document Les questions relatives l usage concernent la d finition du contexte de l utilisateur la d finition de l outil la d finition de l interaction entre l utilisateur et l outil la d finition de l information manipul e travers l outil Enfin d un point de vue fonctionnel il est n cessaire de tenir compte des caract ristiques techniques de l outil utilis tout en impl mentant au mieux les services sp cifi s L ensemble de l tat de l art sur les approches et m thodes de conception Partie 2 nous permet de comprendre les concepts manipuler pour l analyse des usages et la sp cification des services collaboratifs Cela nous m ne la construction de deux autres m ta mod les le M ta Mod le d Usages MMU et le M ta Mod le de Services MMS Il s agit notamment de choisir les l ments les plus pertinents afin d avoir assez d information sans pour autant en surcharger les destinataires des analyses le concepteur pour l usage et le d veloppeur pour le service Par l association des trois m ta mod les MMPM MMU et MMS nous cr ons le M ta Mod le de Services Adapt s MMSA Il s agit de d crire commen
210. ec des concepts particuliers Nous constatons que ce m ta mod le est tr s g n ral et qu il n entre pas dans le d tail des l ments d crits quel type de technicien est ce Quels sont les attributs de la facture etc Si cela peut suffire dans un contexte professionnel simple nous pensons qu un tel m ta mod le devra apporter plus d l ments de description pour un contexte plus complexe comme celui du projet AIC Le formalisme de mod lisation des sc narios est la fois graphique et textuel L approche par cr ation d un m ta mod le et d un formalisme d di nous semble par ailleurs int ressante En ce qui concerne l utilisation de ce formalisme nous notons que les utilisateurs eux m mes n utilisent pas l diteur de sc narios afin d exprimer leur besoin La description de leurs pratiques habituelles est retranscrite a posteriori par les concepteurs La m thode est une m thode de conception d outils collaboratifs pourtant la description des sc narios est toujours individuelle Elle n est pas rattach e un comportement un besoin collaboratif plus g n ral qui implique la mise en place de ces sc narios individuels Dans le cas d tude pr sent une soci t de d pannage les processus de travail sont tablis et fig s Il n est pas n cessaire de retracer les objectifs g n raux Mais dans un contexte plus complexe on peut pressentir qu il faudra chercher davantage comprendre comme
211. ec le m ta mod le d usage MMU Cette correspondance d finit la mat rialisation des usages par les services tout comme la correspondance entre le MMU et le MMPM M ta mod le des pratiques m tiers caract rise la m diatisation des pratiques par les usages Dans un projet de conception et d veloppement de service le point de vue fonctionnel est celui port par les d veloppeurs qui impl mentent la solution pour atteindre l usage attendu Cette solution est mod lis e par instanciation du MMS et de fa on supporter le dialogue avec les concepteurs notamment lorsqu il s agit de rendre compte des limites et contraintes techniques rencontr es Les changes entre concepteurs et d veloppeurs peuvent avoir un impact sur le point de vue op rationnel g n rant ainsi des it rations dans le d roulement de la m thode 1 35 D finitions et concepts 1 35 1 Services m tier et services informatiques CT La premi re partie du chapitre 5 de cette th se a t d di e l tude du concept de service Sur la base des d finitions introduites alors nous exprimerons le sens qu adopte le concept de service dans notre m thode Nous pourrons ensuite le caract riser Pour rappel nous avons d fini de mani re g n rale un service comme une prestation qui met a disposition d un client une capacit technique ou intellectuelle pour supporter un besoin Nous distinguons deux types de services les services m tier et les se
212. ement influencer son besoin d information et donc la mani re dont il voudra et devra percevoir les l ments m diatis s Par exemple un ing nieur voudra avoir un acc s aux documents plans afin de les consulter les analyser voire les modifier alors qu un coordinateur cherchera avant tout savoir s ils ont bien t diffus s dans les d lais convenus etc Enfin le contexte utilisateur c est la combinaison des fonctionnalit s techniques offertes par un outil et de l environnement dans lequel se trouvent l utilisateur et cet outil Le projet AIC est un cas typique d activit environnements multiple l agence le chantier les partenaires les lieux de r unions diverses Les technologies disposition sont de plus en plus performantes et accessibles et les possibilit s d innovation sont croissantes comme le d montre l exp rience SDC que nous venons d illustrer Cela s applique galement et tout particuli rement aux technologies mobiles Les performances des ordinateurs portables des tablettes tactiles et Smartphones ont augment tout comme leur autonomie et leur connectivit r duisant ainsi le nombre de contraintes que l on pouvait assigner la mobilit il y a quelques ann es Satyanarayanan 1996 1 3 Conclusion Nous avons dans ce chapitre caract ris la coordination d un projet AIC et les outils qui la supportent En conclusion de la premi re partie sur la caract risation du contexte de
213. en de communication entre utilisateurs experts analystes et d veloppeurs De plus les 10 Selon Jackson amp Pamela Zave 1995 l exigence d crit une relation souhait e parmi les ph nom nes de l environnement puis la sp cification d crit quant elle le comportement souhait du syst me dans cet environnement Il nous pr cise que l exigence devient sp cification lorsque la relation souhait e est partag e avec le syst me et contr l e par ce dernier Chapitre 4 De l utilisateur la conception logicielle et d interfaces exigences ne doivent pas limiter la libert de d cision des concepteurs qui ont une connaissance plus approfondie des technologies et techniques d impl mentation W Davis 1999 Permettant la tra abilit des choix effectu s en termes d exigences le SRD supporte galement la validation par les utilisateurs en phase exigences mais aussi en phase transition c a d apr s la conception Parmi les approches d ing nierie des exigences on pourra relever celles orient es buts Goal Oriented Requirement Engineering Cooper 1996 Kavakli 2002 Lamsweerde 2001 Lamsweerde 2003 et celles bas es sur les sc narios scenario based RE Salinesi 2004 Sutcliffe 2003 Les buts goals selon Lamsweerde 2001 sont sp cifi s afin de supporter l expression et la validation des exigences ainsi que la gestion des conflits la n gociation l explication et
214. ences pour identifier les processus analyse dynamique Les entit s sont ensuite d crites en termes de m thodes et attributs analyse statique Pour ce qui est de l analyse dynamique de l espace interactionnel la sp cification est compl t e par des diagrammes d tats qui d crivent le cycle de vie des objets Un exemple de passage d tat pour l objet d g t est le passage de d verrouill ditable verrouill non ditable L analyse statique se fait de la m me fa on que pour l espace m tier Enfin les objets translation servent comme leur nom l indique g rer la correspondance entre les objets m tiers et les objets interactionnels ils transforment par exemple les coordonn es en pixels d un rep re objet interactionnel en la position d un d g t objet m tier dans un mod le 3D Un diagramme de s quence illustre ce processus de transformation 26 mer 212 i A P i rF F Un troisi me l ment compose les objets dits tripartites il s agit de la donn e de r f rence servant la nomenclature pour ce qui est de l objet m tier et repr sentant les donn es de base comme les codes couleurs pour les objets interactionnels Chapitre 7 Les m thodes de conception de services tudes de cas Business space Transiation space Interaction space Business Process interactional Process I l Manage y Data Translation al Busin
215. ent et le d veloppeur les user stories histoires d utilisateurs supportent une collaboration continue entre ces deux acteurs en d crivant des sc narios d utilisation pr cis Chaque user story est ph m re et faite pour tre oubli e d s lors que la solution a t impl ment e et valid e Cohn 2003 L utilisateur est ainsi fortement impliqu dans le processus En fonction des user stories et it rativement jusqu ce que tous les cas de figure soient trait s et valid s les d veloppeurs suivent le processus suivant ils d terminent et attribuent les t ches de d veloppement ainsi que les tests mener ils r alisent leurs t ches de d veloppement en bin me ils testent le code d velopp et l int grent continuellement dans le syst me final Toutes les 2 ou 3 semaines Ecriture des tests D veloppement par pairs D veloppement pilot par les tests Release Int gration Int gration continue chaque jour Figure 28 Cycle de d veloppement dans la m thode XP Cette m thode ne s inscrit pas du tout dans la m thodologie pr sent e pr c demment car elle est clairement orient e programmation pas de phase de conception et n est pas support e par des mod les Elle pr sente cependant l avantage de g rer continuellement l volution des besoins et des risques Le fonctionnement par petites quipes et l autonomie des bin mes de d veloppeurs
216. eption en situation de collaboration distance entre des tudiants de Nancy et de Li ge le Studio Digital Collaboratif Kubicki Guerriero Leclercq et al 2009 Les r les dans ce projet de d veloppement ont t attribu s de la mani re suivante Utilisateurs les tudiants Experts m tiers les encadrants acad miques ils poss dent le recul n cessaire l analyse du travail Concepteurs notre quipe D veloppeur un stagiaire informaticien int gr l quipe pour le projet Chapitre 12 La m thode PUSH exp rimentations et bilan Design production and exchange Designer CP Family 5 Design and reporting Student of the project group Students of the group design the project together discussing about differents documents Job Other Executes Is composed oj Generate and share design ideas Each student has to propose his own design ideas to his group Is composed of Is composed of Is composed of Is composed of D Create i P Unshare Already supported by a service Already supported by a service Need service development Need service development Creates Uses Uses Targets Creates Targets Targi 6A Design documents produced by students A Designer Plans models reports Others students of the group Designer Job Other Status In Progress Status To Modify Status Over Refers to rwi Building project type No Certification i Ths is a universi
217. er Notre probl matique d adaptation des services informatiques est issue d un constat initial que nous avons introduit dans les premiers chapitres de cet ouvrage un domaine particulier implique des services particuliers les services g n riques ne r pondant pas totalement aux besoins des professionnels Un domaine collaboratif caract ris par le travail coordonn de plusieurs acteurs n cessite des services de support la coproduction la communication et la coordination dans un contexte de travail souvent distant et r parti dans le temps cf L 16 1 Pour tudier comment la sp cificit d un domaine peut influencer le d veloppement de services nous nous sommes concentr s sur le domaine AIC Rappelons que le projet de conception et construction architecturales diff re d un processus industriel notamment car l objet produit c est dire le b timent est unique Il est galement soumis des garanties d cennales qui impliquent la responsabilit des concepteurs quant la qualit de l ouvrage dans le temps Les t ches m tier en conception et construction sont non r p titives et sans cesse ajust es de par le contexte de projet Ce contexte appel contexte de l activit collective dans les travaux ant rieurs voif 1 volue d un projet un autre mais aussi au cours m me du projet sous des influences ext rieures pareilles celles qui op rent sur le business model des entrepris
218. er concepteur en g nie logiciel et IHM d veloppeur non pas pour valuer mais pour assurer la qualit du service La mod lisation activit principale dans le projet architectural est galement au c ur de notre approche de conception Elle doit permettre d viter des ambiguit s et augmenter la compr hension que les intervenants ont du travail r alis par les autres intervenants d un projet de conception de services Notre tude s appuie sur cette notion de point de vue en proposant galement un processus compos de trois tapes Le point de vue organisationne porte sur les pratiques des acteurs d un projet AIC en fonction de leur r le ayant des besoins sp cifiques d riv s des pratiques collectives qui se mettent en place au cours du projet De par le contexte professionnel dans lequel se trouve notre tude nous nous sommes essentiellement int ress s aux besoins li s au partage de documents des architectes avec d autres acteurs dont notamment les entreprises les ing nieurs et le ma tre d ouvrage et la visite de chantier L analyse de pratiques a contribu am liorer notre compr hension des aspects m tiers relatifs la mod lisation de la collaboration Les travaux pr c dents sur la m ta mod lisation du contexte coop ratif chapitre 1 et notre tude sur les processus m tiers chapitre 5 nous servent de base la cr ation du m ta mod le des pratiques m tiers MMPM Le point de vu
219. er supprimer r cup rer Le mod le priv concerne la gestion des donn es pour chaque utilisateur ex sur son ordinateur personnel Il se synchronise avec le mod le partag qui met en commun les donn es pour tous les utilisateurs la Vue est l interface avec laquelle l utilisateur interagit Par le biais de fen tres d ic nes etc elle capte les interactions de l utilisateur par exemple les clicks et lui renvoie des informations le Contr leur caract rise les composants logiciels qui transmettent les requ tes depuis la vue transmettent les donn es interrogent les bases de donn es r actualisent la vue Ce sont des applications des services web On peut parler ici de sous services lt 3 Contr leur Utilisateur n Dimensions spatio EEE temporelles et Utilisateur 2 z l artag fonctionnelles partag Mod le Fournit priv synchronise Utilisateur 1 avoc k l information S actualise afficher Figure 113 Rappel le mod le Co MVC Ainsi le m ta mod le de services Figure 114 caract rise le service ICT comme un ensemble de ces trois types de composants la Vue le Contr leur le Mod le sp cifi par le mod le priv et le mod le partag Chacun d eux est caract ris par un nom et la technologie de d veloppement utilis e ex une interface JAVA vue un web service REST contr leur Les changes qui s op rent entre eux sont des
220. er ce secteur sur la base des diff rents concepts que sont l acteur l artefact et l activit Ces concepts sont issus de travaux pr c dents sur la mod lisation de l activit collective dans un projet AIC Le chapitre introduit dans un second temps les outils de Travail Collaboratif Assist par Ordinateur TCAO leur buts leur nature leurs enjeux 1 1 La caract risation du secteur dans les travaux pr c dents Les travaux de mes pr d cesseurs men s au sein du laboratoire MAP CRAI ont contribu a faire voluer de mani re continue une mod lisation du contexte d un projet AIC L objectif de Damien Hanser Hanser 2003 tait de repr senter des situations collaboratives particuli res au travers de trois concepts l acteur l activit et le document Mouhamed Bouattour Bouattour 2005 y ajouta le concept d objet pour introduire la caract risation des ouvrages et l ments d ouvrages et des espaces b tis Sylvain Kubicki Kubicki 2006 porta son attention sur le concept d outil et la fa on dont il s int grait dans le contexte du projet L objectif tait alors d utiliser la repr sentation de la collaboration afin de mener une tude sur l assistance de la collaboration grace a des outils logiciels d di s La th se de Annie Guerriero Guerriero 2009 consid ra la repr sentation d un aspect particulier de la collaboration savoir la confiance L ensemble de ces travaux forme la base th or
221. er une pratique du coordinateur qui souhaite analyser l avancement du chantier en visitant le b timent lui m me mais aussi au travers des comptes rendus de chantier et des remarques faites sur le b timent S il identifie des d fauts il voudra en informer les entreprises concern es au travers de remarques Nous avons pu caract riser cette pratique gr ce au diagramme de pratiques Il aura fallu compl ter le m ta mod le afin de pouvoir d ajouter des l ments de description comme par exemple les d fauts Chapitre 12 La m thode PUSH exp rimentations et bilan Coordinator Problems identification and solving The coordinator of the project CP Family 9 Execution preparation and management Job Architect Problems on site must be identified and solved by coordinator and contractors Executes Is composed of Site monitoring Is composed of Inform The coordinator has to monitor buildin execution while he visits it Need service support Is composed of Targets Is composed of G Ente identify Q verity consutt A roup type Enterprise Contractor N d of t No need of t Need t oO need of service suppor oO need of service suppor eed service suppor Contractors concemed by defects Uses Is composed of Targets Rais TO Uses Defect Model Report Message type Reaction Al defects identified duning the visit Targets Any 3D representation of the bulding Site meetng report New remarks about defects A
222. eraient aux r les de chacun Il d finit un collecticiel personnalisable comme un collecticiel dont le comportement peut tre param tr pour r pondre aux besoins particuliers des participants d un groupe ou du groupe lui m me Le collecticiel personnalisable s adapte d un point de vue social en prenant en compte les diff rences des utilisateurs au sein de leur groupe et d un point de vue technique en permettant l utilisateur de choisir la solution qui r pond le plus ses besoins Selon Katsumata 2007 il d ploie un m canisme orient par les t ches qui pr dit les intentions et les demandes de l utilisateur en fonction de sa situation dans le groupe et de son contexte d utilisation Cockburn amp Jones 1995 pr sente un guide pour le d veloppement d outils support au travail collaboratif Ici encore l utilisateur et son contexte m tier et technologique sont mis au centre des pr occupations Ce guide est compos de 4 principes maximiser l acceptation personnelle c a d encourager les individus adopter le syst me en explicitant ce qu il leur apporterait minimiser le recours aux exigences de l utilisateur et ainsi r duire la disparit entre les co ts et les b n fices minimiser les contraintes c d laisser l utilisateur libre de g rer son travail de la mani re qui lui parait la plus adapt e et non pas comme le syst me lui impose maximiser l int gration exte
223. ersit de Lausanne Bibliographie O Farrell P 1991 An interaction model of business service production and consumption British Journal of Management O Regan G 2008 Computer Programming Languages In A Brief History of Computing O Sullivan J J 2006 Towards a precise understanding of service properties Queensland University of Technology Paetsch F Eberlein a amp Maurer F 2003 Requirements engineering and agile software development WET ICE 2003 Proceedings Twelfth IEEE International Workshops on Enabling Technologies Infrastructure for Collaborative Enterprises 2003 pp 308 313 Papazoglou M P amp Georgakopoulos D 2003 Service oriented computing Communications of the ACM 46 10 pp 25 28 Papazoglou Michael P amp Heuvel W J Van Den 2006 Service oriented design and development methodology nternational Journal of Web Engineering and Technology 2 4 p 412 Paterno F 2001 Towards a UML for interactive systems In M Reed Little amp L Nigay eds Engineering for human computer interaction Springer Verlag Berlin Heidelberg 2001 pp 7 18 Paterno F Mancini C amp Meniconi S 1997 ConcurTaskTrees A diagrammatic notation for specifying task models In Proceedings of the IFIP TC13 Interantional Conference on Human Computer Interaction Citeseer pp 362 369 Peffers K et al 2007 A Design Science Research Methodology for Information Systems Research Journ
224. ervice Need service support Need service support Already supported by a service Targets ts es ests Graphic designer Geometral Designers according to the tasks they have to perform Plans of the project gts Specifications Sp ctiications about material and equipment van Message type Notification wy ge typ VAN Group type Enterprise notification of shared documents it can contain speciic instructions af Author Designer Status Over Contractor General construction enterprise Job Architect Author Designer Status Over Author Designer Status Over Figure 125 Les pratiques de partage d un concepteur Le mod le r alis partir de cette analyse m tier Figure 125 repr sente cette situation collaborative la phase de projet est la phase de conception les 2 PC consid r es change de documents pour le partage de la conception et pour l ex cution l acteur concepteur auquel on s int resse ses PI diffuse les documents de conception pour l quipe de concepteurs et pour l entreprise de construction les op rations partage et informe pour chaque PI et enfin les artefacts manipul s savoir les documents de type g om tral ex les plans et de type sp cifications ex cahier des charges les messages de notifications ainsi que les autres acteurs impliqu s le dessinateur et l entreprise de cons
225. es partir d une fen tre propri t s Package Explorer X ES l My library 3 org eclipse emf model instance Resource Set amp src 4 platform resource org eclipse emf model instance model My library BA JRE System Library JavaSE 1 6 Library amp model New Child r Book amp My library Tae Ctrl Z Employee HS p Writer Redo Ctri Y Figure 81 Exemple d instanciation d une classe de m ta mod le avec l diteur EMF Le framework GMF Graphical Modeling Framework est n de l association d EMF un autre framework GEF Graphical Editor Framework Ce dernier permet la cr ation d diteurs graphiques riches A nsi GMF permet l instanciation d un m ta mod le ecore par des diagrammes par la g n ration de ce genre d diteurs enti rement personnalisables Le processus de cr ation et personnalisation de l diteur est assist par un dashboard Figure 82 Apr s la cr ation du m ta mod le ecore et la g n ration des classes java deux mod les sont cr s pour d crire l aspect graphique des diagrammes et la palette de l diteur le graphical def model et le tooling def model Dans le tooling def model il est par exemple possible d agr ger les outils de la palette dans des sous menus ou de les s parer par des traits afin de mieux les 2 http www eclipse org eclipse index php Chapitre 8 Introduct
226. es voir l environnement Chapitre 8 Introduction de la proposition l conomie la technique Avec lui varient les autres contextes li s a l usage des outils pour assister le projet le contexte utilisateur physique et mat riel et le contexte de l acteur cognitif cf 1 2 3 Aujourd hui les solutions logicielles pour le partage d information sont nombreuses Elles existent par exemple sous la forme pi ces jointes dans un mail ou via un message instantan ou de stockage dans le cloud GoogleDrive Microsoft SkyDrive DropBox Cependant dans le contexte professionnel d un projet de construction ces outils trouvent rapidement leurs limites malgr des versions d di es entreprises Le manque d espace disponible d archivage de s curit et de tra abilit ou encore les r gles de confidentialit inadapt es limitent leur adoption par les professionnels qui privil gient pour certains des solutions priv es d velopp es en interne Les outils tels que CRTI weB et plus particuli rement son service documents cf 1 4 3 se d marquent par des fonctionnalit s pens es pour les activit s et par les acteurs du domaine de la construction telles que l utilisation d une convention de nommage m tier le filtrage par metteur de plans les commentaires la validation Ils pr sentent aussi d autres qualit s comme la s curit et la confidentialit 1 23 2 Le cont
227. es dans la section suivante certains fr quemment utilis s et int gr s aux projets d autres plus innovants et prospectifs 1 2 2 Les types d outils De mani re g n rale les outils supportant la coordination permettent d tendre les fonctionnalit s de nos outils classiquement utilis s pour g rer nos activit s dans un cadre pluri utilisateur L exemple le plus courant est le calendrier que nous pouvons utiliser seul ou a plusieurs Les outils dont nous parlerons sont des outils num riques et non pas des outils dits physiques comme l engin de chantier M diatiser la coordination dans les activit s op ratoires Les activit s consid r es ici sont relatives la construction du b timent et plus particuli rement sa gestion son organisation son contr le Plusieurs types d outils sont g n ralement adopt s pour m diatiser ces activit s op ratoires Guerriero 2009 Les outils de planification permettant de coordonner les diff rentes t ches dans le temps Il existe plusieurs m thodes de planification comme les diagrammes de Gantt Ca bielrienes 6 PERT ou Line Of Balance Yamin amp Harmelink 2001 Chapitre 1 La coordination dans les projets de conception construction architecturale Nov 05 Nom de la 1 ohe D but Conception Hsquettage Conception Maquetiage Documentation Validation cahier des charges Conception de l arohitecture technique Concep
228. es de la m thode chapitres 9 10 11 est un cas simple qui nous a permis de pr senter l approche et les concepts d velopp s Cet exemple ne refl te cependant pas un besoin m tier tr s particulier l usage associ et le service d velopp restant donc relativement communs Nous illustrons plus pr cis ment l int r t de cette m thode au cours du chapitre suivant travers trois exp rimentations d faut de valider le processus entier chaque fois chacune de ces exp rimentations nous permettra d valuer un aspect particulier de la m thode Nous essaierons d en tirer parti pour mener une analyse critique g n rale de l approche Chapitre 11 La mod lisation des services le point de vue fonctionnel 212 Chapitre 12 La m thode PUSH exp rimentations et bilan 1 39 Introduction aux exp rimentations 1 39 1 Rappel application d une m thode dirig e par les mod les Au travers les pr c dents chapitres 9 10 11 nous avons cherch caract riser plusieurs points de vue diff rents port s sur le travail collaboratif Adopter chacun de ces points de vue permet de construire pas pas un m ta mod le qui d crit des services adapt s aux besoins m tiers le point de vue organisationnel porte sur les pratiques m tiers le point de vue op rationnel porte sur les usages qui m diatisent ces pratiques le point de vue fonctionnel porte sur les services qui mat rialisent ces usages
229. es fonctionnalit s en composants et d ainsi recomposer les services informatiques les inputs et les outputs de chaque fonctionnalit Comme nous l avons vu dans les approches IHM il existe des approches visant automatiser cette d rivation des services m tiers en services informatiques Par exemple Touzi et al 2009 automatise la proposition de services collaboratifs dans une approche MDA partir de mod les de processus collaboratifs Il d veloppe pour cela des r gles de transformation pour traduire les mod les m tier en mod le technique La m thode est support e par une suite d outils On retrouve le m me genre d approche dans Bispo et al 2010 ou encore Delgado 2010 Chapitre 5 De l entreprise orient e services la conception de Syst mes d Information Le d veloppement de SI est donc support par la mod lisation de processus qui d finissent l activit m tier un niveau organisationnel Cependant la mod lisation des processus m tier comporte certaines limites 1 14 4 Les limites des approches bas es sur le Business Process Modeling BPM M me si les mod les de processus peuvent servir de support au d veloppement automatis par des approches de MDA il semble que dans un certain niveau de d tail l intervention d un analyste et d un d veloppeur soit n cessaire Noran 2000 affirme que la traduction d un mod le m tier en un mod le logiciel n est pas un processus s
230. es formalismes existants ne permettent pas d instancier enti rement notre MMSA Nous avons donc cr nos propres formalismes en utilisant l environnement de d veloppement Eclipse et plus particuli rement le framework GMF Graphical Modelling Framework extension d un autre framework qu est EMF Le framework GMF et l exploitation de nos m ta mod les Le projet Eclipse est un ensemble de projets de d veloppement logiciel autour de la plateforme Eclipse un environnement de d veloppement int gr principalement crit en Java Le projet Eclispe Modeling a t lanc par IBM dans le but d unifier leurs outils de d veloppement utilisant des mod les Comme nous l avons vu dans la section introduisant l ing nierie dirig e par les mod les cf 1 11 1 l espace technique EMF Eclispe Modeling Framework est similaire celui de l architecture dirig e par les mod les MDA Ainsi un projet EMF permet de cr er des m ta mod les ecore M2 bas sur le langage EMOF Essential Meta Object Facility puis les mod les M1 conformes ce langage Pour repr senter le m ta mod le le framework propose le formalisme ecorediag proche de celui du diagramme de classes UML Nous pouvons donc impl menter nos propres m ta mod les en EMF sans changement de formalisme Les l ments de mod le M1 cr s partir des concepts du M2 sont repr sent s sous forme d une liste leurs attributs tant ditabl
231. es mais peut tre peu ou pas encore m diatis es Ce cas rel ve donc plut t d une volont d innovation par la technologie plut t que d une r ponse un besoin m tier observ Il nous permet d valuer le potentiel de notre m thode et nos m ta mod les dans un autre type de projet de conception de services Le tableau de bord envisag ici est un outil de collaboration dont l objectif est de fournir une information synth tique sur le projet de construction au cours des diff rentes tapes de chantier mat riaux t ches d ex cution malfacons Il est destin assister le r le de coordinateur au cours des visites de chantier r guli res L usage que nous introduisons ici est donc relatif un contenu et un contexte spatio temporel particulier Il est galement li un mat riel particulier savoir une tablette tactile pouvant tre g olocalis e L exp rimentation beaucoup plus courte que les deux pr c dentes a t compos e de deux s ances de travail La premi re avait pour but d initier le projet partir de maquettages illustrant les attentes de l expert m tier Ce dernier avait donc une id e plut t formalis e du service concevoir Lors de la deuxi me s ance de travail les diff rents mod les pr conis s par la m thode ont t compos s Le concepteur a ensuite pu formaliser le cahier d exigences partir des mod les et des notes prises au cours de la s ance de trava
232. es propos s Pratiques Usages Services PARTIE 3 proposition Cas d tudes Exp rimentations Figure 16 D marche suivie dans notre recherche bas e sur la conception Chapitre 3 Probl matique et m thode de travail PARTIE 2 Th ories et m thodes Concevoir des services collaboratifs adapt s La pr c dente partie fait merger la n cessit de concevoir et proposer des solutions informatiques adapt es aux pratiques d un m tier en nous int ressant plus particuli rement aux pratiques de collaboration dans un projet AIC L enjeu de cette tude est de d finir une m thode qui puisse guider cette conception La partie 2 de ce manuscrit pr sente les th ories et m thodes que nous avons explor es pour constituer notre base de connaissance sur le sujet Nous avons notamment port notre attention sur l importance de la mod lisation les diff rentes approches relatives Nous nous sommes tout d abord int ress s aux m thodes de conception logicielle et d IHM chapitre 4 Nous avons ensuite explor le concept de services et la conception des services informatiques dits de technologies de l information et de la communication ICT dans l entreprise chapitre 5 Nous avons enfin tudi des principes de conception de collecticiels et services collaboratifs chapitre 6 Le dernier chapitre de cette partie chapitre 8 illustre l analyse et la critique de trois cas d tu
233. es sur l activit de groupe le mod le et la plate forme Clover Laurillau Y amp Nigay L 2002 Clover architecture for groupware Proceedings of the 2002 ACM conference on Computer supported cooperative work CSCW 02 p 236 Leontiev A 1978 Activity consciousness and personality Prentice Hall List B 2006 An evaluation of conceptual business process modelling languages In Proceedings of the 2006 ACM symposium on Applied computing Dijon France ACM Loniewski G Armesto A amp Insfran E 2011 Incorporating Model Driven Techniques into Requirements Engineering for the Service Oriented Development Process In Engineering Methods in the Service Oriented Context IFIP International Federation for Information Processing pp 102 107 Loucopoulos P amp Karakostas V 1995 System Requirements Engineering McGraw Hill Inc New York NY USA 1995 Lovelock C amp Wirtz J 1981 Services marketing Prentice Hall Englewood Cliffs New Jersey Lu S amp Paris C 1999 Towards the automatic generation of task models Engineering for Human Computer Interaction Lucquiaud V 2005 Proposition d un noyau et d une structure pour les mod les de t ches orient s utilisateurs Proceedings of the 17th conference on 17 me Conf rence Francophone sur l Interaction Homme Machine IHM 2005 pp 83 90 L L S Ghose A amp Morrison E 2010 Definition of a description language for business se
234. ess Entity update Business to Interaction Interactional Entity i Pia sii sei en is Translation teraction l Interaction to Business Figure 71 L architecture Symphony tir de S Dupuy Chessa 201 1 1 20 3 La branche technique et la conception La branche technique consiste d crire a la fois l architecture logicielle et l architecture technique L architecture logicielle pr conis e est le mod le MVC cf deal Figure 26 Il permet la correspondance avec les objets Symphony d crits pr c demment les objets interactionnels correspondent a la Vue les objets m tiers correspondent au Mod le les objets translation correspondent au Contr leur L analyse technique est quant elle compos e de la sp cification des dispositifs choisis plus t t cf mod le ASUR Dubois et al 2002 et de la description de ces dispositifs ex le mod le du dispositif la r solution de l cran la qualit d image A partir de l la combinaison de l analyse fonctionnelle avec les choix techniques et le d ploiement dans l infrastructure technique peut tre effectu e Ici un nouvel l ment sert de charni re savoir le r le Toujours d apr s Sophie Dupuy Chessa et al 2010 ce r le commande l objet translation contr leur la cr ation d un nouvel objet m tier mod le et son instanciation en tant qu objet interactionnel vue C est ce qui se passe techniquement lors de
235. est la prise en compte des utilisateurs et de leurs interactions avec le syst me Constantine 2002 En effet pour une bonne appropriation d un outil par un utilisateur il est n cessaire d en d finir non seulement le fond c d les fonctionnalit s mais au aussi la forme l interface on parle alors d interface homme machine IHM Booth 1989 Les m thodes agiles n offrent cependant pas de r els guides pour les concepteurs et les d veloppeurs en ce qui concerne les IHM Les m thodes dites enrichies apportent cette composante interface en orientant le d veloppement sur Putilisabilit 1 10 La conception d IHM de l utilisateur l interface Si les m thodes classiques de G nie Logiciel sont bas es sur l tude de ce que le logiciel fait les m thodes enrichies de conception d IHM s int ressent en plus comment il doit le faire Cette question jusque l laiss e au libre choix du d veloppeur pendant le d veloppement est d sormais trait e d s l analyse et la conception travers plusieurs approches la conception centr e utilisateur CCU la conception centr e activit CCA la conception dirig e par les buts CDB et la conception centr e usage CCUs Cette section illustre comment ces approches combinent tudes de terrain et implications diverses de l utilisateur dans le processus de conception Nous y pr sentons plusieurs types de mod les caract risant les t ches
236. ette d finition en parlant de capacit autonome et transformationnelle qui est offerte et consomm e par des clients internes ou externes c d l entreprise pour leur b n fice voir aussi Lovelock amp Wirtz 1981 La production d un service ne fournit donc pas un bien tangible stockable et consommable a posteriori elle est immat rielle Cette production fournit une aide une ou plusieurs personnes avec ou sans profit vis on parlera de services marchands et non marchands et en fonction d un contexte m tier ex les soins m dicaux les transports la restauration la vente On pourra r sumer la d finition d un service comme le fait O Sullivan 2006 par trois caract ristiques c est une action qui a une valeur et qui peut composer d autres services dits services composites ou m ta services Crawford et al 2005 Au del de l identification des besoins et de la proposition le cycle de vie de d veloppement d un service comprend sa vente et sa distribution ainsi qu un support ventuel Figure 43 http www insee fr fr methodes default asp page definitions services htm Chapitre 5 De l entreprise orient e services la conception de Syst mes d Information fs D finition et d veloppement du service Identification des besoins du client Distribution et Commercialisation support et Vente Figure 43 Le cycle de vie de d veloppement d un service tir de
237. ettent aux experts m tier de d crire de mani re simple une situation observ e Les utilisateurs eux m mes ne peuvent tre impliqu s dans une description compl te de leur travail Cependant lorsqu il s agit de proposer ou d am liorer un service pour les assister ils peuvent mettre en avant des probl mes particuliers auxquels ils sont confront s Un mod le de pratique devra permettre de formaliser de telles situations particuli res tout en les conceptualisant afin de pouvoir associer ce mod le d autres cas observ s L expert m tier cr e ce mod le et le communique aux concepteurs de services Les concepteurs font tat du contexte de l usage travers le contextual use case Celui ci est pr sent aux experts m tier pour une description g n rale de la solution qui sera impl ment e et permet une premi re phase de validation Dans un deuxi me temps il est compl t de diagrammes d interaction voire de maquettages et soumis aux d veloppeurs pour ouvrir la discussion sur les aspects techniques Un premier ensemble de diagrammes de s quences non technique sans d tail de l architecture du service pr sentant un sc nario id al peut galement tre propos par les concepteurs Les d veloppeurs m nent la production du service et produisent de mani re ponctuelle une version d taill e des diagrammes afin de supporter la discussion Il s agit alors d changer sur les alternatives proposer
238. eur Il se veut essentiel savoir simple et abstrait en contraste avec le sc nario qui est complet et r aliste ainsi qu ind pendant de la technologie Constantine 2006 On parle alors des intentions de l utilisateur et des responsabilit s du syst me Il est repr sent par Constantine sous forme litt rale structur e savoir d un tableau en 2 colonnes voir Figure 33 Tout comme nous l avons vu au travers de l analyse des activit s de conception logicielle le use case peut tre repr sent graphiquement Le diagramme de cas d utilisation permet d illustrer un ensemble de use cases pour un syst me donn le diagramme de s quences permettra de d composer le use case au m me titre que le tableau figure 17 Retrait de billet r serv un guichet Intentions de l utilisateur R sponsabilit s du syst me 1 Demande au client son identification 2 Donne son identification 3 Donne les d tails a propos du billet 4 Confirme le billet voulu 5 Fournit le billet et infomme l utilisateur 6 Prend le billet Repr sentation d un use case sous forme de tableau Utilisateur Guichet i 1 Demandeldentification i 2 Donneldentification id mdp Utilisateur y 3 DonneD tailsBillet 4 ConfirmeBillet 5 FournitBillet y Use case diagram 6 PrendBillet gt Repr sentation d un use case sous forme de diag
239. eur acteur au sein du projet alors que la coordination transversale ou extra acteurs met en relation un acteur du projet avec un acteur dit externe comme un expert ou un sous traitant sp cialis Dans les deux cas inter extra on observe plut t un ph nom ne de mise en commun de l information bas e sur l change diff rent de la diffusion sens unique dont les droits reviennent une entit hi rarchique Figure 4 ib 2 Ery E Hi rarchique Adhocratique Transversale Figure 4 Distinction entre coordination hi rarchique adhocratique et transversale tir de Kubicki 2006 Enfin partir des travaux de Mintzberg Mintzberg 1989 on distingue les m canismes de coordination d ajustement mutuel bas s sur la communication informelle de la supervision bas e sur des ordres et des instructions et de la standardisation c d de la sp cification des proc d s des r sultats obtenir ou encore des qualifications avoir Le sch ma suivant Figure 5 illustre la corr lation entre les caract res de la coordination dans un projet AIC Les activit s impliquant un grand nombre d acteurs typiquement les activit s op ratoires comme celles de construction en phase chantier sont en g n ral de nature coop rative et n cessite d tre organis es de mani re explicite Les activit s pr paratoires relatives la conception en collaboration reposent quant elles sur la prise r
240. eur puis publi dans un registre UDDI qui pointera le bon service en fonction de la demande du client Le client acc de alors au service via un protocole SOAP http On distingue 3 cat gories de services web les services web d int gration donnent acc s aux services de transactions le client acc de directement aux services de vente ex amazon itunes de gestion de ses comptes bancaires d organisation de ses voyages ex booking lastminute les services web d information tendent la port e des structures fournissant de l information actualit s m t o finances les services web d externalisation permettent plusieurs structures d associer leurs processus en les faisant sortir de leur propre architecture pour par exemple combiner la manufacture l assemblage la distribution UDDI i gt Publish 1 lt 1 Discover WSDL Discover Provider i Requestor w Web SOAP Legend References to service descriptors O Pointers to WSDL documents EA Originates from Figure 47 R les et interactions dans une architecture de services web 22 http publib boulder ibm com infocenter rtnihelp v6rOm0 index jsp topic 2Fcom ibm etools webservi ce doc 2Fconcepts 2Fcws html oa Chapitre 5 De l entreprise orient e services la conception de Syst mes d Information 1 13 4 La place des services CT dans un business mode comp titif Rappelons q
241. exte d tude et les objectifs Le double contexte offert par le CRAI Centre de Recherche en Architecture et Ing nierie de Nancy et le CRP Centre de Recherche Public Henri Tudor Luxembourg a permis d inscrire des objectifs de recherche dans la continuit de travaux th oriques et dans des cas d tudes r els et pertinents La th matique de recherche du CRAI est la proposition de m thodes et outils pour l assistance la conception la construction et la coordination dans le domaine AIC C est avant tout un contexte acad mique Les objectifs du CRP Henri Tudor sont quant eux relatifs la recherche et au d veloppement de services innovants pour le transfert vers les professionnels Un des programmes de l organisation est d di au domaine de la construction Par rapport la structure de notre recherche introduite au 1 8 2 et comme le rappelle la Figure 77 ce contexte a donc aliment la fois notre base de connaissances en jaune sur la figure cf Partie 1 et notre terrain d exp rimentation en bleu pr sent au Chapitre 12 de ce manuscrit Il a permis d allier pr occupations m tiers et opportunit s d innovation Chapitre 8 Introduction de la proposition PARTIE 2 tat de l art Les m thodes de conception dans divers domaines La m thode de conception suivie dans ce travail de these J Etudes initiales le contexte tri facettes
242. f service oriented development methodologies In Workshop on Service Oriented pp 75 80 Rosemann M et al 2009 Business Service Management Service Management p 16 Saffin S amp Leclercq P 2010 Studio digital collaboratif un environnement multimodal de conception collaborative a distance application et perspectives In JHM 10 Atelier Collecticiels pp 16 18 Safin S Kubicki S amp Hanser D 2012 Enseigner la co conception distance Retour sur cinq ann es d exp rience In SCAN12 Complexit s des mod les de l architecture num rique Presses Universitaires de Nancy Salber D et al 1995 De l observabilit et de l honn tet le cas du controle d acc s dans la Communication Homme Homme M diatis e In JHM 95 Salinesi C 2004 Authoring Use Cases Scenarios and Use Cases Stories through the System Life Cycle Salvador T Scholtz J amp Larson J 1996 The Denver model for groupware design ACM GQGCHI Bulletin 28 1 pp 52 58 Samaan K 2006 Prise en Compte du Mod le d Interaction dans le Processus de Construction et d Adaptation d Applications Interactives Ecole dentrale de Lyon Sandkuhl K 2010 Supporting Collaborative Engineering with Information Supply Patterns In 18th Euromicro Conference on Parallel Distributed and Network based Processing Ieee pp 375 384 Santos L Lopes J amp Leitao A 2012 Collaborative Digital Design When the architect meets
243. fants relations travers lesquelles les sous classes h ritent des attributs de la classe au dessus lt lt enumeration gt gt type_profession artisans commergants et chefs d entreprise agriuclteurs exploitants cadres et professions intellectuelles sup rieures professions interm diaires employ s ouvriers retrait s sans activit professionnelle fr re de nom texte nom texte type_profession num ration type_profession num ration 4ge valeur num rique 4ge valeur num rique i i i En couple avec mari oui non Figure 80 Exemple de diagramme de classes UML caract risant une famille Ces m ta mod les sont instanci s par des mod les dont la forme est d crite par un formalisme particulier selon le besoin de repr sentation Nous utilisons notamment les diagrammes de cas utilisation de t ches ou encore de s quence cf g 1 9 3 qui sont des formalismes adapt s et adopt s dans les domaines de la conception logicielle Le tableau est un formalisme simple qui permet de repr senter de mani re claire et structur e des donn es litt rales de type texte court ou num riques Il est ainsi suffisant pour mod liser certains concepts qui ne demandent pas une repr sentation Chapitre 8 Introduction de la proposition graphique particuli re Le tableau repr sente les donn es sous forme de cases align es dans des colonnes et des lignes Cependant l
244. fin d augmenter la performance environnementale des b timents construits et r nov s mais aussi afin d valuer ces performances des institutions proposent des guides et r f rentiels Chapitre 9 La mod lisation des pratiques le point de vue organisationnel destin s aux professionnels du secteur Leur analyse nous a permis d identifier et d finir 5 objectifs principaux atteindre Les r f rentiels analys s sont HQE France BREEAM Royaume Uni MINERGIE Suisse et DGNB Allemagne Ce dernier le r f rentiel allemand DGNB est le plus pr cis et le plus complet De la revue des ces r f rentiels environnementaux nous avons identifi les cinq objectifs suivants Zignale Sylvain Kubicki amp Gilles Halin 2011 Assurer la qualit du b timent cela inclut les choix conceptuels et les choix techniques La qualit architecturale comme l agencement des espaces les relations int rieur ext rieur etc est galement importante Cet objectif concerne la fiabilit structurelle ou encore la qualit des ouvrages dans le temps Il comprend aussi des exigences plus sp cifiques comme un impact limit sur l environnement par la r duction des consommations nerg tiques par l utilisation de mat riaux cologiques Assurer le confort des habitants les choix conceptuels et techniques sont galement questionn s au regard du confort thermique acoustique et visuel Le confort est aussi relatif
245. gestion du projet de d veloppement est galement un enjeu important Il s agit de bien transmettre l information n cessaire la r ponse du besoin et d adopter une approche m thodique pour le d veloppement de la solution Le chapitre suivant approfondit ces deux enjeux pris comme point de d part pour la d finition de notre probl matique de recherche ainsi que l identification des axes d tude analyser Chapitre 2 Un cas de d veloppement d un outil de TCAO CRTI weB Chapitre 3 Probl matique et m thode de travail Nous d finissons dans ce chapitre la probl matique qui merge des contextes d tude et objectifs relatifs identifi s pr c demment la proposition d une m thode de conception de services adapt s au secteur de la construction La m thode de travail suivie pour r pondre cette probl matique est pr sent e sur la base d un recul th orique sur la science de la conception 1 7 Construction de la probl matique 1 7 1 Objectifs et concepts vis a vis du contexte tri facettes Notre probl matique se construit dans un premier temps autour de l analyse et la critique du contexte tri facettes introduit par Kubicki 2006 L objectif de ce travail tait la multi visualisation du contexte de l activit dans le but de favoriser les conditions d une coordination bas e sur l ajustement mutuel Suivant nos premi res remarques ce contexte sert de base la caract risa
246. gramme tait int ressante pour r sumer de mani re g n rale les intentions outiller Nous avions propos des diagrammes de t ches K MAD la conception de notre propre diteur de t ches particulier n a t entreprise que plus tard La description des t ches utilisateur et syst me dans l usage tait utile dans un premier temps premi re r union mais insuffisante pour la suite des discussions Les besoins en termes de description taient plus importants que ceux support s par les arbres de t ches C est pourquoi nous avons introduit le diagramme de s quence qui s est av r le mod le le plus utile pour la discussion avec les d veloppeurs Cela ne remet pas en cause l int r t d un arbre de t ches dans la m thode mais il s av re plus utile lorsque l interaction occupe une place plus importante dans l usage Notons enfin que les diff rences entre les formats de documents dwg xref pdf manipul s auraient pu tre mod lis es par le concept d objet d interaction cf 1 32 2 Ce concept n a t introduit que plus tard mais cette exp rimentation en a motiv la cr ation 1 41 Exp rimentation 2 l automatisation du service d upload de CRTI weB 1 41 1 Introduction et d roulement Lors de cette deuxi me exp rience nous avons collabor avec un nouveau d veloppeur int gr dans l quipe de conception pour une courte dur e Les changes ont ainsi t favoris s et nous avons m
247. gure 142 Les paragraphes suivants en r sument succinctement le contenu La connaissance multidisciplinaire a t construite autour de trois axes de recherche principaux des tudes initiales sur le contexte coop ratif d un projet AIC du projet de conception des services de la plateforme CRTI weB et d un tat de l art sur les m thodes de conception logicielle selon plusieurs approches partir de ces connaissances plusieurs processus de conception et d veloppement ont t men s et valu s au cours de trois exp rimentations Nous avons ainsi propos une mod lisation des pratiques m tiers qui compl te les tudes ant rieures sur le contexte coop ratif et l int gration de cette mod lisation dans un processus de conception de services inspir des m thodes analys es et appliqu pour l am lioration des services de CRTI weB Les exp rimentations ont galement permis de prendre un certain recul sur le d roulement d une m thode de conception de services en concluant sur divers points il est important de supporter chaque point de vue apport dans un processus de conception en distinguant les concepts manipul s par chacun d eux et en facilitant le transfert de l information essentielle entre ces points de vue Conclusion et perspectives il est important d utiliser des langages et formalismes qui soient adapt s aux diff rents points de vue en consid rant les langages
248. gure 49 les m thodes de g nie logiciel et notamment l architecture dirig e par les mod les MDA peuvent tre int gr es cette approche le passage d un point de vue l autre permettant de guider le processus de conception des technologies de l information CM Pereira 2004 Le CIM Computation Independant Model est le point de vue de l Analyste M tier qui mod lise le m tier Le PIM est le point de vue du Concepteur qui mod lise le syst me Le PSM et PISM le code sont le point de vue du D veloppeur qui mod lise la solution technologique et la d veloppe 4 Abstractions Columns __________titmtmimiy The Zachman FUNCTION NETWORK MOTIVATION Framework How Where Why Process Location Motivation List of things j jr List of Business important to the business Master Schedule BUSINESS MODEL Model 3 Conceptual Owner pl CIM Logical Data Model Processing Structure Business Rule Model SYSTEM MODEL Architecture Architecture Logical Platform Independent Model PIM Presentation Control Structure TECHNOLOGY fer Architecture orm Specifit Model PSM REPRESENTATIONS Out of Context Sub Contractor lt Perspectives Rows _ gt Figure 49 Le Framework Zachman et les mod les de la MDA extrait de Frankel 2003 Un nouveau paradigme Comme on peut le lire dans Ramollari amp Dranidis 2007 le d veloppement orient service est un changement
249. hamps d tudes analys s dans notre tat de l art illustrent cette double valorisation M ta mod les sous forme de diagrammes UML M2 Pratiques M2 Usages M2 Services S V V Mod les Arbres hi rarchiques tableaux diagrammes M1 Pratiques M1 Usages M1 Services Valorisation des opportunit s technologiques Valorisation des opportunit s du m tier Proposition d un service adapt Monde r el les projets AEC Figure 83 Une m thode dirig e par les mod les et favorisant l innovation i http www eclipse org atl Chapitre 8 Introduction de la proposition Nous parlons de valorisation des opportunit s m tier lorsque la m thode permet d utiliser les analyses d un domaine comme source d innovation dans le d veloppement de solutions informatiques adapt es Le RUP est un processus de r f rence de ce type Parall lement des exp riences ant rieures ont montr que la d marche de conception peut galement tre initi e par une opportunit au niveau technologique C est souvent le cas dans le domaine des IHM avec le d veloppement de nouveaux modes d interaction qui ouvrent le champ des possibles en termes d usage par exemple l interface gestuelle Kinect Cependant ces moyens ne sont que rarement utilis s pour r pondre de r els besoins Mal exploit s ils ne g n rent alors rien au del de l engouement initial que l on conf re l innova
250. he particuli re il peut tre r utilis ou recompos en fonction des besoins m tiers Dans une architecture d entreprise un service ICT supporte l ex cution d un service m tier Kohlborn et al 2009 un service ICT est d livr par un syst me informatique pouvant tre utilis s par ment par plusieurs entit s Wieringa 1998 d finit un systeme comme un ensemble d l ments interactifs incluant le mat riel hardware et le logiciel software Le syst me informatique n est autre que le support technologique du syst me d information d une entreprise Chapitre 5 De l entreprise orient e services la conception de Syst mes d Information Un service informatique au m me titre qu un service m tier est d fini par un client un fournisseur et une description comprenant Capacit s Param tres et Propri t s non fonctionnelles La description n est plus lexicale mais adopte un langage informatique compris par les syst mes La distribution d un service informatique se fait telle qu illustr e dans la figure 46 suivant le paradigme trouver joindre invoquer Endrei et al 2004 Papazoglou amp Georgakopoulos 2003 le fournisseur publie le service dans un registre qui permet au client de le trouver et ainsi d y acc der Le client y acc de gr ce un programme install sur un dispositif et proposant une interface logicielle adapt e Figure 46
251. hode La formalisation des sc narios R cit Chez le client le technicien dite le compte rendu d intervention et pr pare Ja facture Le technicien dispose d un PDA qui se synchronise r guli rement avec le syst me de l entreprise Figure 59 Un exemple de sc nario contextualis dans son diteur Le sc nario est dans cette approche une vision partielle des besoins des utilisateurs dans un certain contexte Afin de formaliser ces sc narios contextualis s les auteurs ont cr un formalisme de mod lisation hybride supportant une description textuelle sous forme d histoires courtes et une description graphique proche du cas d utilisation voir Figure 59 Ce mod le est l instanciation d un m ta mod le le MMSC m ta mod le du sc nario contextualis il est dit par l outil CBME Contextual Behaviour Model Environment Figure 65 Voici les concepts d finis par le MMSC et leurs repr sentations respectives avec le formalisme de CBME Figure 60 Figure 61 Figure 62 Figure 63 Figure 64 Chapitre 7 Les m thodes de conception de services tudes de cas Un acteur est d fini par son r le dans l activit et par un identifiant qui permet de le d finir comme 1 l acteur principal qui r alise les t ches d crites 2 un acteur secondaire impliqu mais non responsable ou un acteur passif qui est pr sent mais non concern par l action Chaque acteur et le syst me poss
252. i est g r par des cycles courts conclus par la mise en commun du travil et des discussions entre d veloppeurs et utilisateurs Backlog du Backlog du produit sprint Figure 29 Processus de la m thode SCRUM 1 9 5 Constat et conclusion Le projet de d veloppement logiciel suit un cycle de vie structur et formalis Les m thodes modernes s appuient sur des mod les qui rendent compte des activit s men es et servent de point de d part aux activit s qui suivent ce qui assure la coh rence des r sultats tout au long du processus mais aussi la tra abilit des choix Les formalismes utilis s sont admis par la communaut et sont compris par chacun L agilit apporte aux m thodes de d veloppement une organisation rigoureuse des cycles de d veloppement L alternance de cycles courts exigences d veloppement bilan permet de construire une solution logicielle petit petit et toujours dans le respect des attentes du client Ce dernier peut exprimer ses besoins de mani re simple travers des mod les adapt s principalement les user stories et les d veloppeurs peuvent alors s auto organiser pour produire une solution fonctionnelle qui sera rapidement valu e Ces m thodes assurent alors l utilit du produit final propos ss Chapitre 4 De l utilisateur la conception logicielle et d interfaces Ce que l agilit n apporte pas et qui reste la lacune des m thodes de g nie logiciel c
253. iciel global non pas seulement par des grands principes mais bien par une d marche scientifique de conception Cette m thode que nous nommons PUSH pour Practice and Usage based Service enHancement traduit en fran ais par am lioration des services sur la base des pratiques et usages supporte la collaboration entre les experts du domaine AIC et les experts du g nie logiciel Santos et al 2012 Dans la section suivante nous nous interrogeons sur l intervention de ces diff rents acteurs d un projet de d veloppement de services en fonction de leur activit Nous pr sentons le support documentaire de cette collaboration le cahier d exigences Chapitre 8 Introduction de la proposition PRACTICE amp USAGE BASED Figure 84 Repr sentation abstraite de la m thode PUSH 1 25 2 Le cahier cahier d exigences D apr s Paetsch et al 2003 un bon document d exigences est non ambigu complet correct consistant concis et r alisable En fonction de la relation entre le client et le fournisseur la sp cification des exigences peut tre contractuelle Le cahier d exigences pour la conception et sp cification de services ICT adapt s a t cr pour y consigner les mod les et donc les diff rents points de vue exprim s au cours de l application de la m thode PUSH Il est compos de deux documents distincts le mode d emploi et le formulaire de d finit
254. id r Par exemple le plan ou l ouvrage sont des artefacts de la conception architecturale alors que les mod les UML et le code impl ment comptent parmi ceux de la conception logicielle Les processus quant eux sont la mise en uvre d activit s de diff rents types associ es des acteurs responsables de l ex cution de ces activit s Les projets d architecture et ceux du g nie logiciel peuvent tre appr hend s comme deux processus de conception similaires qui associent des points de vue diff rents Ces points de vue peuvent comme identifi plus haut tre source de divergences Analyser ces projets c est alors consid rer plus que l artificiel nous verrons qu un contexte de projet est aussi d fini par des facteurs humains C est la crois e des chemins entre ces deux domaines que cette th se trouve sa source L objectif est en effet de tirer parti d une analyse des pratiques de conception dans le domaine AIC pour sp cifier celles d un projet de GL pour la conception de services adapt s au secteur Cette probl matique de double conceptualisation et de mise en correspondance sera au c ur de ce travail Probl matique g n rale Notre analyse de la conception logicielle s est particuli rement port e sur son aspect m thodique et structur En ce qui concerne l analyse des pratiques architecturales nous avons au contraire voulu garder l esprit le caract re unique et peu pr dictif de ch
255. identifier ce qui est de l ordre de l action ou de la sous action au travers de tous les processus mis en uvre dans un tel projet Enfin le caract re inconscient d une op ration est fortement d pendant de l apprentissage de l acteur qui l ex cute Sous le m me concept d activit les travaux de nos pr d cesseurs regroupent le projet les phases de projet et les t ches Le projet et les phases de projet Il est admis de consid rer un projet AIC comme un double processus compos d une tape pr paratoire li e la conception et d une tape op ratoire li e la construction Plus largement ces deux tapes s inscrivent dans un ensemble de phases du cycle de vie d un b timent dont la granularit varie selon les tudes Bobroff et al 1993 Armand 1997 Hanser 2003 Kubicki 2006 Nous retenons dans cette th se les phases suivantes le montage pendant lequel la ma trise d ouvrage acquiert le terrain d finit le programme du b timent construire tablit le budget et choisit les concepteurs ventuellement par le moyen d un concours la conception aussi appel e phase tudes pendant laquelle la ma trise d uvre formule une r ponse architecturale technique et conomique la demande du ma tre d ouvrage Selon la loi MOP elle comprend les sous phases Esquisse Avant Projet Sommaire APS Avant Projet D taill APD Projet et Assistance aux contrats de trav
256. ie sur le serveur sous forme d un fichier ZIP Puis il cr e dans la base de donn es un document CRTI weB auquel il associe le fichier ZIP qu il vient de cr er Chapitre 11 La mod lisation des services le point de vue fonctionnel Techniquement cette association se fait par la d finition de l attribut localisation du document CRTI weB avec l URL du fichier ZIP cr sur le serveur lt lt Outil gt gt nom CRTI weB lt lt Service m tier gt gt nom documents Description le service m tier documents de la plateforme CRTI weB permet la l change la tra abilit et la gestion des documents d un projet de conception construction architecturale lt lt service ICT gt gt upload service J lt lt client gt gt lt lt View gt gt lt lt Private Model gt gt lt lt Controler gt gt lt lt Shared Model gt gt Designer CRTI weB brower PHP file explorer personal drive web service REST database file server r lt lt interaction task gt gt activate new dowload D lt lt Input gt gt can displayUploaHOptions lt lt input gt gt selectBrowse lt lt perception task gt gt visualize files J lt lt outpht gt gt i RS dr nee ecco noes 3 Ce ta alt File selection alternatives i lt lt interaction task gt gt file selection lt lt Inpuf gt gt selectOndeQ seq Classical upload process J
257. ified Software Development Process puis le RUP pour Rational Unified Process se sont bas es sur un processus d ployant plusieurs cycles de d veloppement dans le temps du projet de conception un processus it ratif et incr mental dont le nombre d it rations pourra varier selon le type et l ampleur du projet Chaque cycle de ce processus comprend quatre phases de d veloppement Kruchten 2001 Kroll amp Kruchten 2003 et se termine par un jalon savoir sa propre valuation Les tests qui supportent ces valuations peuvent tre d termin s en d but de cycle comme le pr conise le processus de d veloppement dirig par les tests K Beck 2003 L tude pr liminaire ou inception a pour but d avoir une vue d ensemble des objectifs des couts des risques L laboration vise d crire plus pr cis ment les besoins d crire le syst me lever les risques et planifier le projet La construction n est autre que la proposition de la solution sous forme fonctionnelle ou sous forme de documentation selon le moment dans le projet La transition vise d ployer et tester la proposition voire la livrer si le cycle se situe en fin de projet auquel cas cela comprend aussi la formation des utilisateurs et la maintenance Chapitre 4 De l utilisateur la conception logicielle et d interfaces Chaque phase fait appel a une ou plusieurs activit s dont les principales sont les suivantes vo
258. il Tableau de bord Premi re r union l Pr sentation des Maquettages Discussions sur leg attentes Deuxi me r uhion Mod lisationdes Pratiques et usages gt Formalisatign du cahier d exigences Finalisation du cahier d exigences Avril Mai Figure 136 D roulement de l exp rimentation 1 42 2 Analyse des besoins m tier un maquettage comme point de d part L id e de d part propos e par l expert m tier tait de concevoir un tableau de bord proposant un certain nombre de services li s la localisation du coordinateur sur le chantier pendant sa visite partir de ses connaissances du domaine et de ses attentes quant l usage d un tel outil l expert m tier a propos un ensemble de maquettages qui pourraient servir de premi re impulsion un projet de d veloppement Chapitre 12 La m thode PUSH exp rimentations et bilan View V1 Graph Number of remarks par bulding on site Y2 3D model position of the user on site YJ Graph Number of remarks per rms V2 Graph Evolution of the number of remarks trom the start of the construction YF 3D model position of the user on site Mighighting of he bulding under consideration WL List List of remarks concerning the floor under consideration number titie responsible Floor location prionty level date of detection Jead time date of closure V2 3D model position of the user on site Highlighting of the floor un
259. il Non D tail graphique Il faudrait pouvoir sauvegarder les et r cup ration 556 recherches Oui d infromation de filtre Fonctionnalit utile Figure 146 Grille d analyse des tickets partie 4 4 De Cahier d exigences mode d emploi Les pages qui suivent constituent le mode d emploi du cahier d exigences tel qu il est actuellement propos Il a pour but d assister les experts m tier concepteurs et d veloppeurs dans leurs phases de mod lisation respectives et dans la lecture g n rale du document Cahier d exigences pour le d veloppement de services informatiques sp cifiques Mode d emploi 1 Description du document a But du document Ce document a pour but de d finir les exigences qui guideront le d veloppement de services informatiques Il devra d crire synth tiquement les pratiques m tiers du client ainsi que les usages induits qu il adoptera en tant qu utilisateur du syst me d velopper ou am liorer Ces l ments auront t identifi s par l analyste m tier gr ce l implication de l utilisateur lui m me dans la phase d tude La combinaison de ces exigences donnera lieu une sp cification technique du service sous forme d un diagramme UML b Port e du document Ce cahier des charges servira de base la conception de services sp cifiques Il est destin guider le d veloppeur dans son travail de conception sans qu il n ait besoin d avo
260. imple Pour Soulier et al 2007 il parait illusoire de croire pouvoir se passer d une phase d impl mentation De plus le BPM suscite des questions quant sa capacit repr senter des situations collaboratives particuli res Van der Aalst 1998 nous dira que les processus collaboratifs sont hors de la port e de la d finition des workflows Dans un processus collaboratif l accent est mis sur la communication et le partage de l information plus que sur la d finition d un processus qu il n est alors pas n cessaire d expliciter Berard amp Karlshoej 2012 citant Curtis 1992 et List 2006 fait ressortir le fait que les langages de mod lisation de processus impl mentent bien les aspects fonctionnels et comportementaux c est dire les r gles m tiers et leur s quen age Par contre ils sont limit s en termes de perspective organisationnelle la mod lisation des acteurs et informationnelle la mod lisation des l ments d information trait s Cela s av re d autant plus vrai en qui concerne notre domaine d application le projet AIC pour lequel la repr sentation sous la forme de processus m tiers rigoureux tels que ceux utilis s dans la mod lisation d entreprise semble trop rigide En effet les quipes de projet de conception architecturale ne sont pas dirig es par une couche strat gique qui cherche maximiser le rendement de l entreprise par un processus optimis
261. implifi e du MMU bleu li au MMPM rouge 1 33 Les mod les d usage Le MMU est un m ta mod le qui caract rise des concepts tir s du domaine du G nie Logiciel et de la conception d IHM Les formalismes utilis s pour l instancier seront eux aussi relatifs ces deux domaines Ainsi le point de vue op rationnel sera exprim par les concepteurs a travers des concepts et des formalismes qu ils comprennent et qu ils ont l habitude de manipuler Ces formalismes sont les suivants le diagramme de cas d utilisation le diagramme de t ches le maquettage d interfaces utilisateurs et des tableaux 1 33 1 Le diagramme de cas d utilisation contextualis Nous utilisons le diagramme de cas d utilisation Figure 102 pour mod liser dans un premier temps toutes les intentions de l utilisateur et les r ponses attendues de l outil les t ches outil Elles sont mod lis es par des use case diff renci s graphiquement Les paquets rouges sont Chapitre 10 La mod lisation des usages le point de vue op rationnel utilis s pour repr senter l op ration dont sont d duites les intentions utilisateurs Les paquets situ s hors du cadre de l outil repr sentent les op rations qui ont t identifi es dans la pratique mais qui ne sont pas l objet du travail de conception en cours Comme nous l avons dit pr c demment tout cas d utilisation n est pas directement li un
262. inally the functional viewpoint aims at defining the business service i e the behavior of the system that answers to one business need We propose the PUSH method Practice and Usages based Service enhancement that orchestrates the different viewpoints to generate an amount of requirements for the development of adapted services The communication and the traceability are supported by this design method The context of study both research and development oriented through the collaboration of the MAP CRAI laboratory in Nancy and the CRP Henri Tudor in Luxembourg allows us evaluating and enhancing the definition of our concepts and the applicability of the PUSH method through three experimentations Keywords Construction Business Practices Collaborative services Software Engineering Human Computer Interactions Usage centered design Design science RAMEAU Keywords Groupware Software Development Collaborative work User centered design Design patterns Architecture Software engineering Architecture Practices Concevoir des services collaboratifs adapt s des pratiques m tiers une m thode centr e usages Application au domaine de la construction R sum Dans le domaine du projet de conception construction architecturale la gestion de la collaboration entre les diff rents acteurs d un projet est un enjeu important D un projet un autre en fonction du projet mais aussi des acteurs qui y interviennent les pr
263. interaction par le sp cialiste IHM et l ergonome L enjeu est de permettre chacun de formaliser son analyse puis de les lier dans un processus de conception coh rent Cela pourra pallier au risque pr c demment analys dans Delotte 2006 de ne pas faire la part des choses entre le travail des acteurs d un domaine et le futur dispositif technologique qui va m diatiser ce travail Ici la sp cification organisationnelle et interactionnelle est men e parall lement une sp cification technique pour ensuite lors de la conception aboutir une ou plusieurs solutions adapt es Chapitre 7 Les m thodes de conception de services tudes de cas Expert m tier Sp cialiste GL Sp cialiste IHM Ergonome Figure 72 Intervention des diff rents acteurs de la m thode Symphony au cours de la sp cification des besoins issu de S Dupuy Chessa 2011 Dupuy Chessa 2011 voque l volution de l espace m tier d clench e par l int gration des choix d interaction adopt s par l ergonome et le sp cialiste IHM Nos contributions des projets appliqu s de d veloppement de services pour le secteur AIC nous permettent d argumenter dans ce sens En effet l implication des acteurs m tiers dans un processus de d veloppement d un nouvel outil passe fortement par la confrontation des prototypages d interfaces Cette d marche favorise probablement tr s t t l appropriation de la technologie par
264. ion le Ma tre d ouvrage arr te l enveloppe financi re lors du programme Les documents financiers du projet depuis la proposition de prix jusqu au solde de tout compte constituent l une des composantes majeures du march entre le MO et les organismes engag s Les documents labor s au cours du projet plans descriptifs avant m tr qui serviront la consultation des entreprises permettent d tablir un co t pr visionnel des travaux par corps d tat ou par lot Il y a une demande tr s forte aupr s des conomistes de la construction qui sont capables de faire le pont entre les bureaux d tudes et les entreprises Sa t che est de d finir l enveloppe financi re d un projet en ma trisant les aspects mat riaux et nergie dans une construction tout en respectant les r gles impos es Tableau 15 l ments de caract risation de la PC4 Acteurs impliqu s Documents utilis s Activit s T ches de coordination Ma tre d ouvrage et assistants Maitre d oeuvre Comptable conomiste Enveloppe et documents financiers Plans et descriptifs li s la conception Toutes phases Tout contractant PCS conception et compte rendu de la conception Description l esquisse constitue la premi re tape de la r ponse architecturale et technique au programme C est la formalisation graphique des premiers choix du concepteur Elle instaure un dialogue entre Ma tre d ouvrage et Ma tre d
265. ion de la proposition organiser Grace au graphical def model nous avons exploit une s rie de param trages basiques mais qui r pondent a nos besoins de personnalisation des formalismes changement des formes utilis es pour repr senter les l ments rectangles rectangles arrondis ellipses et variations du trait utilis style paisseur couleur variations des traits utilis s pour les relations variations des polices pour chaque attribut utilis ajout d un titre pour chaque attribut affichage d un ic ne pour chaque l ment 5 lt lt enumeration gt gt M ta mod le TRETAS Designer Owner Owner _assistant Contractor Expert Administration Coordinator Advisor lt lt enumeration gt gt Title architect structure_engineer urbanist electrician carpenter mason other ActorName EString Role RoleType a Title Title roupActorCamposition B SimpleActor lt lt enumeration gt gt GroupActorType Agency targetObject Laboratory Public_organization T j H GroupActor Enterprise GroupType GroupActorType Association lt _ Other linkActor 2a Sp cificationde Vapparence des l ments du mod le 1 Construction du M ta mod le 3 Combinaison du M2 et Graphical Def Model fl des sp cifications gt graphiques de l diteur Select Edit Create
266. ion des exigences Le mode d emploi donne les l ments n cessaires la compr hension et l dition du formulaire voir annexes Il r sume notamment la description des concepts d taill e dans les chapitres suivants Le formulaire est un document dont l dition est structur e et guid e Nous en avons r alis le mod le avec les fonctionnalit s de d veloppement internes Microsoft Word comme la cr ation champs d insertion d image afin d importer les mod les graphiques la cr ation de champs de choix multiples et de saisie organis s dans des tableaux pour diter les mod les textuels des champs de saisie suppl mentaires qui permettent d ajouter des commentaires et informations additionnelles La premi re page comprend le titre donn au service d velopper les acteurs impliqu s dans la conception de ce service selon leur r le parmi l utilisateur l analyste m tier concepteur et le d veloppeur et un suivi des versions avec num rotation date et description des changements Le plan du formulaire suit ensuite la trame de notre approche comprenant ainsi une partie 1 pratiques m tier une partie 2 usages et une partie 3 sp cification du service Chacun des 30 a 7 a ey Le formulaire et les mod les qu il comprend sont en anglais afin d tre plus facilement publi s Le mode d emploi est cependant en fran ais Chapitre 8 Introduction
267. ioner select Canadian Conference on Electrical and Computer Engineering 2005 May pp 2288 2292 Mori G Paterno F amp Santoro C 2002 CTTE support for developing and analyzing task models for interactive system design EEE Transactions on Software Engineering 28 8 pp 797 813 Nitithamyong P amp Skibniewski M J 2007 Key success failure factors and their impacts on system performance of web based project management systems in construction Tcon pp 39 59 Noran O 2000 Business modelling UML vs IDEF School of CIT Griffith University Available at http scholar google com scholar hl en amp btnG Search amp q intitle Business Modelling U ML vs IDEF 0 Accessed June 20 2012 Norman D 1986 User centred System Design New Directions in Human Computer Interaction Nuseibeh B amp Easterbrook S 2000 Requirements engineering a roadmap In Proceedings of the Conference on the Future of Software Engineering ACM pp 35 46 Oaks P Ter Hofstede A H M amp Edmond D 2003 Capabilities Describing what services can do In Service Oriented Computing ICSOC 2003 Springer Olsen G 2004 Personas creation and usage toolkit Olson J 1996 Groupware in the wild lessons learned from a year of virtual collocation In Proceedings of the 1996 ACM conference on pp 419 427 Osterwalder A 2004 The business model ontology A proposition in a design science approach Ecole des HEC de l Univ
268. ions du cahier d exigences Ces informations additionnelles prennent la forme d un tableau dont les parties visent a compl ter la description du contexte de l usage de l utilisateur et de l outil application dispositif On inclut de la m me mani re dans la deuxi me partie du cahier d exigences le diagramme d interaction et les maquettages produits Chapitre 10 La mod lisation des usages le point de vue op rationnel ADDITIONAL INFORMATION ABOUT CONTEXT Do you want to add any functional or non functional requirements about sage he pre conditions and post conditions of the usage It can refer to the relation usages considering the time synchronous asynchronous and the location same location different location Click here to enter tex Click here to enter text Figure 109 Tableau de saisie des informations suppl mentaires dans le cahier d exigences 1 34 Conclusion La caract risation des pratiques permettait d appr hender ce que les acteurs d un projet font celle de l usage est d di e la compr hension de comment ils le font Il s agit ici de d crire l utilisateur et l outil le contenu m diatis manipul les t ches effectu es autour de ce contenu par les utilisateurs et l outil Chapitre 10 La mod lisation des usages le point de vue op rationnel Figure 110 Le choix d un usage et sa d finition La conceptualisati
269. ions et bilan USAGE DESCRIPTION Diffuse design documents The user want to share multiple files grouped as one CRTI weB document USE CASES sag Insert here the use case dagam Related Individual Practice USAGE CONTEXT DP Operationalrole _ CRTI weB classic user__ Apphcationtype Web apphcation identification yes Dev technology CEachone Audio Output Conde 7 autompu he application specificity Is there already a developed application to adapt You can describe it here CRTI weB propose a document sharing service with a specific naming convention What about the new services to develop We want to share files in a same document Shared files must not be renamed Figure 127 Une partie du contextual use case sp cifi pour le partage d un plan dwg et ses xrefs troisi me usage 1 40 4 Le choix et la sp cification de la solution a impl menter Une fois que les usages ont t identifi s et sp cifi s il s agit de choisir ce qu il faut impl menter et comment cela peut tre r alisable Dans un cas d am lioration de services comme ceux de CRTI weB qui fait l objet de cette premi re exp rimentation les choix sont fortement conditionn s par les sp cificit s techniques de l existant Chapitre 12 La m thode PUSH exp rimentations et bilan La phase de sp cification du service se fait travers l association du point de vue de concepteur avec celui des d ve
270. ique sur laquelle s appuie ce travail de th se Au cours des paragraphes suivants nous pr senterons les concepts importants qui en mergent et qui caract risent ce qui est d fini comme le contexte de l activit collective d un projet AIC Chapitre 1 La coordination dans les projets de conception construction architecturale 1 1 1 Lesacteurset leur caract risation L acteur est identifi comme une personne ou un groupe de personnes impliqu dans un projet Les responsabilit s mais aussi la confiance qu on accorde un acteur dans un projet sont port es par le r le qu il endosse Selon Hanser 2003 les r les sont le point fondamental de tout mod le destin repr senter l activit de groupe car le r le mat rialise la participation d un acteur une activit p 130 Il en identifie deux types les r les organisationnels et les r les op rationnels Le r le organisationnel est d pendant du projet et du cadre contractuel qui y est tabli il est donc d fini en d but de projet Il peut tre assimil au r le de l acteur dans le domaine cin matographique savoir qu un acteur peut jouer des r les diff rents d un projet un autre voire au sein d un m me projet Les r les les plus commun ment reconnus sont Le ma tre d ouvrage qui est le commanditaire de l ouvrage concevoir Les architectes et ing nieurs que l on regroupera sous le r le commun de
271. ir de Delotte2006 Chapitre 7 Les m thodes de conception de services tudes de cas Le mod le comportemental CAB Contextual Application Behavior Le mod le comportemental CAB a pour but de synth tiser les besoins des utilisateurs Il est cr partir des mod les de sc narios Ce mod le doit tre utilisable pour l int gration des services et outils n cessaires la r alisation des t ches Le CAB est en r alit un ensemble de mod les ayant chacun leur propre formalisme Le workflow bas sur le framework 2flow Sa kali 2001 qui s appuie sur un m ta mod le du workflow flexible MMWf Consulte ses messages Visualise son planning Va sur le lieu d une intervention R pond ses messages Commande ff a 5 des pi ces h Contacte quelqu un Fait son l rapport Figure 66 Exemple de repr sentation de trois processus alternatifs encadr s color s avec le formalisme 2flow Le mod le de t ches instanciation d un m ta mod le de t ches MMT est exprim avec le formalisme CTT Mori et al 2002 cf 1 103 augment d une cat gorisation des t ches relative au tr fle fonctionnel les t ches de Production de Communication et d Organisation Piquet 2009 Les arbres de t ches du CAB sont compos s de t ches abstraites qui seront sp cifi es ensuite en fonction de la configuration mat rielle et du dispositif d interaction Le mod le du
272. ir Figure 19 la mod lisation du m tier la d finition et la gestion des exigences l analyse et la conception l impl mentation les tests et le d ploiement Kruchten 2001 Ces activit s sont relatives des disciplines diff rentes qui impliquent des acteurs diff rents Cycle 1 Cycle 2 Z _ Etude 2 a ivit ae Elaboration Construction Transition oe me Phases Mod lisation du m tier A p VE D o Analyseet conception Impl mentation i oo OS D ploiement D Figure 19 Processus cycles phases et activit s d un projet de d veloppement logiciel Ces activit s s appuient en partie sur la r alisation et l utilisation de diff rents mod les dont les mod les UML pour Unified Modeling Language Ces mod les d crivent le syst me selon diff rents points de vue 1 9 3 Lesactivit s de d veloppement et leurs mod les La mod lisation m tier Comme on peut le lire dans Gabay amp Gabay 2008 la mod lisation du domaine ou mod lisation m tier permet de mieux comprendre la structure et la dynamique de l organisation tudi e Elle assure au client que les utilisateurs finaux et les d veloppeurs partagent une vision commune de l organisation Un mod le du domaine sous forme de diagramme de classes UML ou de diagramme Entit Relations E R repr sente graphiquement tout les objets ou entit s du domaine et leurs relations En d autres termes il d finit le contexte e
273. ir un recours ult rieur aux futurs utilisateurs Des premiers maquettages serviront de support la discussion avant de passer au prototypage de la solution c D finitions Acronymeset Abr viations PC Pratique Collective comportement d un groupe adopt dans le but de r pondre un besoin m tier r current PI Pratique Individuelle comportement d un individu impliqu dans une PC adopt dans le but d apporter sa contribution la r ponse au besoin m tier Op ration d composition d une PI visant d crire ce que fait r ellement l acteur Artefact l ment produit utilis ou r f r lors d une op ration que ce soit un document un message un objet physique une t che ou tout autre l ment support du travail collaboratif Usage m diatisation des pratiques travers l utilisation d une technologie Tache d composition d un usage visant d crire ce que font r ellement l utilisateur et le syst me 2 Organisation du document Afin de d finir les exigences du service d velopper le document mod lisera travers des formalismes diff rents diagrammes tableaux textes maquettages Partie 1 Une analyse m tier d crivant les pratiques collectives et individuelles outiller Partie 2 Une analyse fonctionnelle d crivant les usages relatifs aux pratiques Partie 3 La sp cification technique du service Partie 1 pratiques m tiers Le diagramme d fi
274. is en place une collaboration troite entre analystes m tiers concepteurs et d veloppeurs la plupart tant localis s au m me endroit Nous avons ainsi pu valuer les capacit s de l approche transmettre les informations n cessaires au bon d veloppement d un service et ce sans connaissance initiale du contexte la fois professionnel et technique Malgr les changes informels r guliers nous avons men s trois s ances de travail particuli res ayant leurs objectifs respectifs La premi re s ance mars 2012 consistait pr senter le contexte professionnel l outil CRTI weB et les services m tiers et informatiques qu il propose L objectif g n ral du projet a t pr sent afin que le d veloppeur puisse rechercher une technologie qui lui permette d impl menter le futur service Au cours de la deuxi me s ance quelques jours apr s nous avons pr sent les points de vue organisationnel et op rationnel au travers du cahier d exigences c est dire les pratiques et usages Au terme de cette r union la t che demand e au d veloppeur a t de formaliser le point de vue fonctionnel sous forme de diagrammes de s quences comme le pr conise la m thode en m me temps qu il d velopperait le service Chapitre 12 La m thode PUSH exp rimentations et bilan De la m me mani re que lors de la premi re exp rimentation la s ance suivante mai 2012 avait pour but de rendre compt
275. ist par ordinateur Approche AMF C Ecole centrale de Lyon Tazari M Grimm M amp Finke M 2003 Modelling user context Proceedings of 10th International Conference on Human Computer Interaction Bibliographie Tellioglu H 2006 Coordination Design In Proceedings of the 20th International Conference on Advanced Information Networking and Applications 1 IEEE Computer Society pp 425 432 Thevenin D 2001 Adaptation en Interaction Homme Machine le cas de la Plasticit Touzi J et al 2009 A model driven approach for collaborative service oriented architecture design International Journal of Production Economics 121 1 pp 5 20 Vaishnavi V amp Kuechler W 2007 Design science research methods and patterns innovating information and communication technology Auerbach Publications Vanderdonckt JM amp Bodart F 1993 Encapsulating knowledge for intelligent automatic interaction objects selection Proceedings of INTERACT 93 Veer G Van Der et al 2000 Task based groupware design putting theory into practice In Proceedings of the 3rd conference on Designing interactive systems processes practices methods and techniques New York NY USA ACM pp 326 337 Veer G van der 1996 The Design of Computer Supported Cooperative Work and Groupware Systems North Holland Elsevier Science Vissers C Lankhorst M amp Slagter R 2004 Reference models for advanced e services In Dig
276. it outille le service dit m tier la prestation 1 13 2 L architecture orient e services Cherbakov et al 2005 d compose les entreprises en partie op rantes nomm s business components c est dire des composants m tier qui regroupent des personnes des ressources du savoir faire et de la technologie et caract ris es par un objectif atteindre de par des activit s men es misent en place sous une gouvernance On parlera de services m tier pour d crire les services chang s entre ces parties op rantes savoir tant t offerts tant t consomm s en interne et ou par des clients externes Une fois orchestr s en processus les services m tier sont support s par un ensemble de services ICT Services informatiques de Technologies de l Information et de la Communication qui composent le syst me informatique de l entreprise c est ce qu on appelle l Architecture Orient e Service SOA pour Service Oriented Architecture voir Figure 44 La SOA supporte la proposition de solutions m tier et techniques qui pourront voluer avec le contexte de l entreprise en fonction des opportunit s de d veloppement ou au contraire des menaces Zimmermann 2004 MacKenzie et al 2006 dira que dans la SOA les services sont les moyens par lesquels les besoins et les capacit s sont rapproch s Autrement dit elle permet oo Chapitre 5 De l entreprise orient e services
277. ital Communities in A Networked Society Springer pp 369 393 White S 2004 Introduction to BPMN Wieringa R 1998 A survey of structured and object oriented software specification methods and techniques ACM Computing Surveys CSUR 30 4 p 69 Williams A 2009 User centered design activity centered design and goal directed design a review of three methods for designing web applications In JGDOC 09 Bloomington Indiana ACM pp 1 8 Winckler M Palanque P amp CMDS 2004 Tasks and scenario based evaluation of information visualization techniques Proceedings of the 3 conference on Task models and diagrams pp 165 172 Yamin R amp Harmelink D 2001 Comparison of linear scheduling model LSM and critical path method CPM Journal of Construction Engineering And Management 127 5 pp 374 381 Yeh R T amp Zave P 1980 Specifying software requirements Proceedings of the IEEE 68 9 pp 1077 1085 Yin C 2010 Samcco un Syst me d Apprentissage Mobile Contextuel et Collaboratif dans des Situations Professionnelles Ecole Centrale de Lyon Zachman J a 1987 A framework for information systems architecture BM Systems Journal 26 3 pp 276 292 Bibliographie Zhang J et al 2012 Development and Implementation of an Industry Foundation Classes Based Graphic Information Model for Virtual Construction Computer Aided Civil and Infrastructure Engineering Zhang Z Liu R amp
278. itectes pr f rent que leurs graphistes aient eux m mes une formation d architecte pour faciliter le dialogue entre eux De m me profiter d une connaissance accrue du m tier pour sp cifier des services peut tre consid r comme un r el atout bien qu une quipe de conception doive s entourer galement des meilleures comp tences techniques et ergonomiques La caract ristique de ce travail de doctorat fruit de la collaboration entre le Centre de Recherche en Architecture et Ing nierie de Nancy et le Centre de Recherche Public Henri Tudor Luxembourg et plus particuli rement son d partement Service Science and Innovation est Introduction justement de placer les pr occupations m tiers au centre des projets de conception de services pour Architecture l Ing nierie et la Construction AIC Une th se a la crois e des chemins entre sciences de l architecture et g nie logiciel Les travaux universitaires men s en sciences de l architecture couvrent plusieurs champs de recherche Cette th se en d veloppera deux particuliers la conception collaborative dans les projets d Architecture Ing nierie et Construction AIC la conception collaborative dans les projets de G nie Logiciel visant assister les pratiques de projet AIC La conception est une science de l artificiel c est un processus it ratif de cr ation et utilisation d artefacts dont la nature est li e au domaine cons
279. its Constantine 1998 d crits en termes de forme et de fonction mais ind pendamment de toute apparence Figure 38 Notons que dans la composition de plusieurs vues l auteur n illustre pas le lien d entre les vues Il s agit d illustrer une interface un instant pr cis J Chapitre 4 De l utilisateur la conception logicielle et d interfaces Action D bute va Stop fini setectionne Cr e Supprime vers termine efface Duplique Ex cute Action sur Action sur et retour bouton vue X X Modifie D place EN lis DE EN Conteneur El ment Notification acteur Entr e El ment Ensemble accepteur ditable ditable Ensemble S rie d actions S rie de vues s lectionnable s lectionnables s lectionnables Figure 37 T ches et l ments d interaction abstraits wio UN in fix IN i O cran de configuration Liste de tests modifier Statut du test Figure 38 Exemple de prototype abstrait 1 10 4 Constat et conclusion Les m thodes de conception IHM enrichissent la conception logicielle en interrogeant Putilisateur sur ses pr f rences et sur ses t ches afin d habiller les syst mes gr ce a des interfaces adapt es Elles pr conisent ainsi l utilisabilit l o les m thodes de GL traditionnelles se limitent l utilit De mani re g n rale la m thodologie de la conception logicielle s appuie sur des mod les qui sont tant t produits tant t
280. iture choix d clenchement manipulation transformation d filement autre de perception graphique audio mat rielle Trois relations caract risent un processus de taches Cette dynamique tait absente dans la caract risation des pratiques m tiers Nous partions en effet du postulat que l ordre des op rations m tiers n importe pas car il peut varier d une situation une autre et selon la mani re dont ces op rations seront outill es Cependant dans la caract risation de l usage et des t ches qui le composent il est n cessaire d int grer cette notion afin de composer la relation entre les interfaces d velopp es Les relations identifi es sont La relation OU sp cifie que l on ex cute une des t ches d crites La relation ET sp cifie que toutes les t ches d crites doivent tre ex cut es La relation PUIS ajoute un ordre dans l ex cution des t ches Nous retrouvons ici les concepts manipul s par CTT Paterno et al 1997 ou K MAD Baron et al 2006 les langages de mod lisation de t ches d interaction en m me temps que les concepts d intention de l utilisateur et de responsabilit du syst me dans les essential use case de la conception centr e usages L Constantine 2001 cf 11 10 3 Le m ta mod le suivant repr sente ces concepts et leurs relations Chapitre 10 La mod lisation des usages le point de vue op rationnel Relation ent
281. ivante montre comment la caract risation des trois points de vue organisationnel op rationnel et fonctionnel d finie en conclusion du chapitre pr c dent permet de r pondre ces enjeux 1 24 M thodologie 1 24 1 La caract risation des points de vue Notre approche de conception de services adapt s est bas e sur l expression des points de vue organisationnel op rationnel et fonctionnel par la mod lisation des pratiques m tiers des usages d une technologie et des services Ces mod les M1 d crivent des cas r els sur base de concepts d crits dans trois M ta Mod les M2 qui sont agr g s en un seul le M ta Mod le des Services Chapitre 8 Introduction de la proposition Adapt s MMSA Les mod lisations successives nous permettent de raffiner les m ta mod les propos s dans un premier temps partir de la litt rature analys e Figure 78 Cas r els Cas r els Cas r el 4 v M1 Pratiques M1 Usages M2 MMPM M2 MMU M ta Mod le des Services Adapt s MMSA ft Tt Litt rature Litt rature Litt rature Figure 78 Processus de m ta mod lisation partir de l analyse de cas et dela litt rature dans diff rents domaines Dans des travaux de recherche ant rieurs men s dans le cadre du projet de recherche Dest2Co par le CRP Henri Tudor les points de vue et les mod les sont la base d une m thode de conception de services la m thode Dest2Co Zignale et al
282. ivants pr sentent chaque tape de l approche autour de la m ta mod lisation et mod lisation des pratiques des usages et des services Rappelons qu une approche qui s inscrit dans une d marche scientifique de conception se distingue d une approche d ing nierie classique car elle m le propositions et valuations dans un processus continu depuis la premi re id e jusqu la r alisation Nous accordons autant d importance la description des concepts introduits qu aux cas d tudes qui ont permis de les identifier et les valider Un dernier chapitre fait tat de ces cas d tudes nous permettant de tirer des conclusions sur la pertinence et l applicabilit de cette m thode 138 Chapitre 8 Introduction de la proposition Ce chapitre d gage dans un premier temps les enjeux et objectifs de cette tude Ils sont issus des contextes de d veloppement de notre m thode de conception savoir le contexte d application le domaine AIC et le contexte d tude cr par les deux laboratoires encadrant cette tude le MAP CRAI et le CRP Henri Tudor Il pr sente ensuite la m thodologie adopt e les outils utilis s et le processus mis en ceuvre pour d ployer une m thode de conception favorisant les opportunit s m tier et technologique la m thode que nous nommons PUSH pour Practice and Usage based Service enHancement 1 23 Enjeux dela m thode 1 23 1 Un domaine d application particuli
283. ivent nous synth tisons son approche en l illustrant par l exemple d un service de devis A partir du mod le du domaine et des exigences les services m tiers sont d finis par les ressources savoir le prestataire du service ex le responsable des devis le contrat relatif au service et les informations n cessaires l ex cution du service ex la demande du client la faisabilit le devis le mod le interactionnel qui caract rise l interaction avec le client savoir les t ches de celui ci qui m nent l ex cution du service et qui lui succ dent ex un service de devis est appel par une requ te du client il est suivi par l acceptation ou le refus du devis par le client le mod le op rationnel qui d compose le service en un processus de sous services ex recevoir la requ te du client clarifier la faisabilit cr er le devis Chaque sous service est de nouveau d compos en services atomiques c d ayant le plus bas niveau de granularit un service informatique tant alors assign chacun de ces services atomiques L analyse du syst me existant permettra d identifier si un service informatique adapt existe d j c d est d j impl ment et peut tre r utilis Sinon il est n cessaire de le d finir par les fonctionnalit s qu il supporte du type cr er modifier supprimer le d veloppement par composants permettra de grouper c
284. jet AIC ne peut pas tre d fini comme un processus complet car les acteurs agissent de mani re hautement distribu e travers de nombreuses pratiques et artefacts Pour Marjanovic et al 2007 les outils de TCAO sont souvent con us pour supporter des t ches individuelles sans les placer dans le contexte d un processus fig Les auteurs ajoutent que le champ du TCAO consid re des activit s hors des limites organisationnelles formelles gouvern es par des r gles et politiques Ils introduisent les processus m tiers orient s pratiques qu ils distinguent des processus orient s proc dures Les pratiques sont dans le domaine de la gestion des connaissances knowledge management relatives une connaissance tacite alors que les proc dures rel vent d une connaissance explicite Les processus orient s pratiques servent mod liser la coordination au travers de t ches bas niveau de granularit d pendantes des d cisions humaines et peu pr dictibles Ces t ches se distinguent donc des t ches des processus m tiers classiques orient s proc dure car elles mergent avec l ex cution du processus Nous retiendrons galement de cette tude le r le particulier de l expert m tier qui analyse ces processus et est m me de les comprendre et les formaliser Chapitre 9 La mod lisation des pratiques le point de vue organisationnel D autres concepts simi
285. l organisation dans laquelle il volue Elles permettent alors de r pondre aux besoins de l entreprise en proposant des solutions logicielles d compos es en services l mentaires pouvant tre combin s et r utilis s Boucher 2009 Nous nous int ressons notamment la notion de processus m tier qui d crit l orchestration des services dans une entreprise afin d orienter la conception des syst mes informatiques Chapitre 4 De l utilisateur la conception logicielle et d interfaces Chapitre 4 De l utilisateur la conception logicielle et d interfaces Chapitre 5 De l entreprise orient e services a la conception de Syst mes d Information Ce chapitre pr sente le concept de service dans le monde de l entreprise puis d un point de vue informatique Les services informatiques des technologies de l information et de la communication ICT supportent les processus m tiers dans les organisations Nous nous int ressons leur conception de l analyse de ces processus la sp cification des services 1 43 L entreprise orient e services 1 13 1 Le concept de service Un service est une prestation qui met a disposition d un client une capacit technique ou intellectuelle selon la d finition INSEE pour supporter un besoin Maglio amp Spohrer 2007 le d finit comme l application de comp tences pour le b n fice des autres Rosemann et al 2009 pr cise c
286. l usage la synchronisation dans le temps synchrone asynchrone et la co localisation co localis distance Dans l exemple ci dessous on consid re l usage qui consiste r cup rer les documents partag s Par rapport l usage que nous venons de d crire l ex cution peut se faire de mani re asynchrone et diff rents endroits RELATED USAGES You can specify the link between the usage you described and others Choose an item synchrone asynchrone CUVE oer Figure 105 Mod lisation de la relation avec d autres usages 1 33 2 Les diagrammesd interaction et maquettages d interfaces Pour mod liser les autres niveaux de t ches nous nous sommes inspir s des mod les de t ches r f rences CTT et K MAD Apr s avoir utilis K MAD dans une premi re exp rimentation nous avons identifi la n cessit de proposer un formalisme personnalis 107 Le choix de ce nouveau formalisme a t guid par deux motivations l une tait relative l aspect graphique pour assurer la correspondance avec les mod les pr c dents nous voulions pouvoir d terminer notre propre charte graphique l autre tait relative au contenu nous voulions mod liser en plus des t ches les objets d interactions caract ris s dans notre m ta mod le d usage Chapitre 10 La mod lisation des usages le point de vue op rationnel Nous nous sommes nouveau servis du framework GMF d Ec
287. l faut limiter les organismes Oui ion ui cup on e R cup rer toutes les G n rale Nouvel usage archivage Nouvelle fonctionnalit utile N Am lioration des fonctionnalit s Avertir certains collaborateurs d un N N Les acteurs s lectionn s sont IL N IL IL IL IL IL IL Contenu Destin aux d veloppeurs Destin aux d veloppeurs Destin aux d veloppeurs Destin aux d veloppeurs Destin aux d veloppeurs Pas de notifications inutiles Ajout du WebService permettant de checker le nom fonction du chantier et de NIL Destin aux d veloppeurs Lors de l ajout d un utilisateur ou de la modification rendre obligatoire la Impliquer un acteur dans le projet Assignation du r le Contenu obligatoire Pouvoir reconnaitre les utilisateurs Le but est de supprimer une action via le NIL Figure 143 Grille d analyse des tickets partie 1 4 Destin aux d veloppeurs 199 Retour en fin de page apr s avoir ajout un Non NIL Gain de temps plus de confort Dans les vues affichant les remarques il manque une ic ne pour remplacer le 201 libell Cl turer qui indique qu une Non NIL Meilleure lecture de l information 202 Affectation r le un utilisateur lors de Oui Impliquer un acteur dans Contenu Assignation du r le Pouvoir reconnaitre les utilisateurs Env
288. la possibilit d attacher un Partager des documents T che Ajouter un document Transmission d informations 483 document dans le detail d un projet Oui du projet contenu accessible depuis le suppl mentaires Emp cher la modification d un organisme Plusieurs pratiques de Contexte Edition d organisme Attribution d une fonctionnalit 493 parun utilisateur simple Oui gestion men es par un T che _ limit aun utilisateur un type d utilisateur Cr ation d un SMTP local pour forwarder 495 les non delivery failure l envoi de mail Non Destin aux d veloppeurs 496 Cr ation d une partie Statistiques CRTI Non Destin aux d veloppeurs G n ration d un fichier Excel permettant Partager des Nouvel usage d export 510 de faciliter la facturation en fin de mois de Oui informations n cessaires G n ral au format excel Nouvelle fonctionnalit utile Partager des Choix d un type de 511 Rajouter une option Type de facturation Oui informations n cessaires Contenu facturation Gain de temps fonctionnalit utile Afficher les projets auquels appartiennent Consulter les activit s Tache Identifier les projets Meilleure compr hension gain de 520 une personne Oui d un collaborateur Contenu d un acteur temps Afficher les personnes qui sont contenues Consulter les activit s T che identifier les personnes Meilleure compr hension gain de 521 dans un organisme Oui d un collaborateur Contenu d un organisme temps Il faudrait ajoute
289. la troisi me s ance ils nous ont propos des maquettages qui illustraient l interface du service tel qu il allait tre d velopp Au regard de certaines contraintes techniques il y aurait quelques diff rences entre le service d velopp et sa sp cification Apr s validation des choix par tout le monde le projet est entr en phase de d veloppements Le service de partage ainsi modifi a t impl ment sur une plateforme de tests dans un premier temps puis sur la version commercialis e Upload multiple crti web milieu professionnel l Premi re r union d quipe l Besoins rapport s lors de workshop I gt Formalisation du cahier d exigences I l Deuxi me r union d quipe l Discussions sur base des diagrammes de s quence arbres des t ches inutiles I I l I Trois me r union d quipe l Premiers maquettages D vel t 2 Modifications des sp c car _ eve oppements 3 z contraintes techniques Suivis des d veloppements Tests Figure 124 D roulement de l exp rimentation Chapitre 12 La m thode PUSH exp rimentations et bilan 1 40 2 Les pratiques de partage Nous avons pu distinguer deux pratiques individuelles diff rentes r alis es par le r le de concepteur g n ralement l architecte chacune issue d une pratique collective particuli re pendant la phase de conception du projet une premi re c
290. laires sont trait s dans la litt rature Par exemple les m canismes de coordination Schmidt amp Simone 1996 sont des protocoles qui d terminent et m diatisent la coordination d activit s distribu es afin de r duire la complexit du travail Tellioglu 2006 Dans Sandkuhl 2010 les patrons d information Information Supply Pattern ont pour but de capturer la connaissance sur des solutions prouv es pour en faciliter la r utilisation De tels patrons concernent des probl mes d informations r currents qui surviennent pour des r les et dans des situations sp cifiques et pr sentent des solutions conceptuelles ces probl mes Ils sont d finis par un nom un contexte organisationnel un probl me une solution conceptuelle les effets de cette solution et enfin les actions li es l information produite Bourguin amp Derycke 2005 rel vent la n cessit de transformer adapter les pratiques et les m thodes de travail pour satisfaire les besoins volutifs de l organisation Nous retrouvons galement ici le caract re flexible soulign pr c demment Ils font merger les apports de la Th orie de l Activit TA pour la caract risation des pratiques caract risation que nous adopterons Rappelons que la TA d crit une structure hi rarchique compos e de 3 niveaux l activit l action et l op ration Consid rant le projet et ses phases comme une activit structur
291. les contr leurs de type clavier souris clavier touchpad cran tactile autre s il y a une connexion internet oui non inconnu sil y a une entr e vid o oui non inconnu sil y a une entr e audio oui non inconnu s il y a une sortie vid o oui non inconnu s il y a une sortie audio oui non inconnu Chaque usage pour un collecticiel comme pour tout autre outil est caract ris par sa temporalit c d ex cut des dates pr cises souvent ou pas intervalles r guliers et sa localisation qui peut d terminer certaines conditions d usage comme un environnement bruyant par exemple Consid rant les usages pendant un projet collaboratif de conception construction architecturale nous pouvons typer ces caract ristiques par des valeurs connues qui pourront tre toff es au fil de l volution de l approche le type de temporalit plusieurs fois par jour tous les jours tous les 2 3 jours une fois par semaine une fois par mois moins d une fois par mois apr s chaque r union autre inconnu le type de localisation au bureau sur le chantier au domicile chez un client dans un endroit public autre inconnu Les relations entre usages En comparant plusieurs usages on pourra sp cifier la relation entre les deux par ses dimensions spatio temporelles la synchronisation qui d termine s ils sont effectu s en m me temps synchrones ou pas asynchrones
292. les outils et comp tences relatives c est ce qu on appelle des espaces techniques ET Kurtev et al 2002 Favre 2004 P rochon 2008 B zivin amp Kurtev 2005 On distingue par exemple voir aussi VET de la Syntaxe Abstraite mod lisation de programmes ex cutables par un langage de programmation M1 dont la syntaxe est d finie dans une grammaire M2 elle m me conforme une famille de m talangages M3 ex le langage JAVA la grammaire JAVA et EBNF Extended Backus Naur Form VET XML eXtendable Markup Langage mod lisation de la structure et du type de contenu d un document XML M1 gr ce une syntaxe contrainte par des r gles grammaticales et des sch mas M2 conformes un m ta sch ma XML M3 VET de l architecture dirig e par les mod les MDA pour Model Driven Architecture mod lisation d un syst me d information et du contexte m tier par des mod les et m ta mod les UML conformes au MOF Meta Object Facility L7ET EMF Eclipse Modelling Framework est similaire 4 MDA selon Jean B zivin amp Kurtev 2005 ils pourraient tre consid r s comme un seul ET Chapitre 4 De l utilisateur la conception logicielle et d interfaces M3 M ta sch ma XML Conforme a Conforme a Conforme a M ta mod le Grammaire M2 UML Sch ma XML JAVA Conforme Conforme Conforme M1 Mod le UML Document XML Langage JAVA Conforme Conforme Conforme
293. leur technique mod les 3D Phase conception de Ma tre d ouvrage et Documents techniques l esquisse l envoi des i te documents pour assistants Documents administratifs ae ex cution PC6 Choix des entreprises de construction Description Le dossier de consultation est remis aux entreprises par le Maitre d ceuvre afin qu elles puissent tablir leurs offres en vue de l attribution des march s Il contient les cahiers des clauses administratives et techniques particuli res le CCAP et le CCTP les dossiers des plans d architecture et techniques les pi ces financi res et ventuellement le rapport de sol les plans parcellaires les plans des r seaux les notes de calculs etc Les entreprises soumettent alors leur dossier lors de l appel de candidature de l appel d offres Les documents n cessaires la consultation tant tablis il reste organiser la remise par le Ma tre d uvre de ces documents et en assurer la diffusion aupr s des entrepreneurs Apr s avoir tabli le dossier des pi ces qui lui sont n cessaires pour faire acte de candidature l entrepreneur doit transmettre son offre Qu il soit engag directement ou la suite d un appel d offres l entrepreneur retenu doit tre reconnu comme comp tent pour r aliser l ouvrage ou un lot de l op ration Il devra satisfaire certains crit res v rifiables tels que le prix des services fournis ou les qualifications obtenues par de
294. ligatoires Connexion Internet Pr condition optionelle Pr condition obligatoire Figure 64 Repr sentation des deux types de pr condition du sc nario contextualis dans CBME Les sc narios contextualis s sont exprim s de fa on textuelle par les utilisateurs puis interpr t s et formalis s graphiquement par les concepteurs qui en d gagent un objectif et peuvent galement proposer des sc narios alternatifs L tude ne donne pas de retours quant l criture de ces mod les que ce soit par rapport l utilisabilit de l outil ou la compr hension des concepts D un point de vue externe et sur la base des l ments illustr s les l ments utilis s semblent clairs m me s ils gagneraient peut tre tre davantage distingu s graphiquement Ils ne refl tent par contre pas beaucoup le domaine d application du fait du peu d information donn e pour chacun d eux quel type de technicien est ce Quels sont les attributs de la facture etc GR alma file Views Comral Check Sconanes amp Actors ES Roes E GoaScenarios gif Comexts B Artefacts y Worktow Gp tasks overtew List scenarios Text Scenario actions de decompesition Storyfioard D Scenarios Tous les matins le technicien A Actor of Rote de travat Add 1 Rem Tasks Add Rem Deaces Add Rem p Scenario Gi aphe Ajout But p i Figure 65 Utilisation de CBME pour crire les sc narios contextualis s t
295. lipse pour g n rer l diteur de ce nouveau diagramme que nous appelons diagramme d interactions Un diagramme d interactions d compose un contextual use case Dans ce formalisme chacune des intentions de l utilisateur identifi es dans le use case devient la racine 1 niveau d un arbre compos de t ches utilisateurs abstraites 2e niveau puis concr tes 3e niveau Les t ches outils apparaissent galement Elles sont d finies comme des t ches abstraites et sont galement d compos es en t ches concr tes Ces t ches concr tes sont relatives la perception du feedback qui rend compte de l ex cution de la t che outil ex l affichage d une notification ou l mission d un son Les propri t s graphiques des intentions utilisateurs et t ches outil sont identiques celles utilis es dans le diagramme de cas d utilisation ellipse au contour rouge pour l intention et ellipse au fond jaune pour la t che outil Cela permet d assurer visuellement la correspondance entre les concepts d un mod le un autre Les t ches utilisateurs sont repr sent es par des ellipses au contour jaune Les t ches concr tes sont repr sent es par des rectangles gris 106 Nous compl tons cette structure traditionnelle de l arbre des t ches par les objets d interaction d finis pr c demment L objet d interaction caract rise la donn e manipul e ainsi que la forme que prend cette derni
296. lle ci est impl ment e D finition du par l utilisateur Exigences en termes not IFC Exchange requirements not IFC d changes de donn es Implementation dans IFC Implementations labase de donn es IFC Figure 75 Vue d ensemble des tapes pour le d ploiement de solutions bas es sur l IFC adapt de Hietanen 2006 Le mod le IFC est aujourd hui enti rement certifi ISO ce qui va encourager sa standardisation et son adoption par le secteur La port e de cette approche est de pouvoir crire des processus m tiers autour du BIM de mani re standardis e galement afin d en cr er des catalogues A termes cela permettra d impl menter des services BIM par la composition de processus standards li s aux besoins des utilisateurs 1 21 3 Analyse critique et conclusion Le BIM et la centralisation des donn es du b timent autour d un mod le unique est un contexte technologique innovant et plein d int r t pour le secteur AIC Il est support par la cr ation de donn es dans un format d change standard l IFC 27 A x on pourrait d ailleurs parler de m ta mod le IFC Chapitre 7 Les m thodes de conception de services tudes de cas Cependant comme l voque Eastman amp Sacks 2010 le sch ma IFC ne capture pas la mani re dont l information est cr e et partag e par les professionnels Pour cela il est n cessaire d interroger les professionnels et de cap
297. loppeurs En tant que concepteurs nous avons propos un diagramme de s quences non technique consign en annexes c est dire ne d taillant pas l architecture du service mais sur la base duquel nous avons pu collaborer avec les d veloppeurs Cette tape doit permettre de lever deux risques majeurs celui de rencontrer des probl mes techniques qui emp chent le bon d veloppement de la solution sp cifi e celui de s engager dans des d veloppements d envergure longs et on reux au lieu de privil gier une solution plus simple mais qui r pondrait au besoin identifi Dans cette optique il a finalement t choisi de ne jamais renommer les fichiers qui sont partag s sous la forme d un seul document mat rialisant ainsi en un m me service l usage d upload group g n ral et celui plus sp cifique avec les xrefs C est ainsi qu a t propos un service d upload multiple sous forme de deux sous services l un pour l envoi de documents ind pendants et l autre pour l envoi group sous la forme d un document unique Nous rejoignons ici le cas illustr dans le chapitre 11 d crivant la cr ation d un fichier zip agr geant tous les fichiers sous un m me document Figure 128 dwg_dds_400_dm_30 dw 779 36KB Copy of dwg_dds_400_ 779 36KB Liaison entre les documents Les documents sont ind pendants Les document sont li es Precedent II Suiva
298. lt technique de d veloppement des solutions li e au manque d outils pour la conception En ce qui concerne les projets AIC Nitithamyong amp Skibniewski 2007 rel ve au travers d une tude sur 82 projets et 14 syst mes que l usage des collecticiels r duit les temps et les co ts induits par la collaboration mais n a pas d impact significatif sur l am lioration de la qualit du projet la s curit et la satisfaction du client Kubicki et al 2009 constate que les collecticiels sont trop orient s m tier unique savoir qu ils supportent l activit d un m tier en particulier mais pas les activit s d un projet AIC dans ses dimensions coop ratives pr sentent un manque d interop rabilit de par la diff rence de format dans les donn es traiter particuli rement en ce qui concerne les repr sentations graphiques et la multitude d outils utilis s cet effet Chapitre 6 Travail Collaboratif Assist par Ordinateur et Services Collaboratifs ne repr sentent qu une partie du contexte coop ratif c a d de l activit globale de projet au travers d informations classiques comme le planning les rapports les listes de documents 1 17 2 Les principes d un collecticiel adapt Devant les divers constats d chec de la solution des collecticiels Greenberg 2006 rel ve l int r t de d velopper des solutions personnalisables qui s adapt
299. lus approfondi il nous est possible de modifier sensiblement le m ta mod le et de r percuter ces changements sur l diteur Cela inclut du plus simple mettre en uvre au plus compliqu ajout de choix dans une num ration ou le changement d une cardinalit ajout d un attribut une classe l ajout d une classe et ou d une relation Cette possibilit d adapter l diteur est tr s importante vis vis des perspectives exp rimentales de notre travail En effet au fil d applications futures de notre m thode il est possible que les concepts voluent voire que de nouveaux soient introduits au fil des analyses m tier qui seront men es Cela a d j t le cas au travers des trois exp rimentations que nous avons men es voir chapitre 12 L exemple le plus typique est l ajout dans une num ration d un l ment qui n aurait pas t sp cifi dans un premier temps mais qui est rencontr dans plusieurs cas Ainsi les allers retours entre mod lisation et m ta mod lisation assureront une analyse m tier toujours plus pertinente 1 29 3 Int gration dans le cahier d exigences Le cahier d exigences a t introduit comme un moyen de rassembler les mod les de chaque point de vue organisationnel op rationnel et fonctionnel Le point de vue organisationnel formalis au travers des diagrammes de pratiques compose donc la premi re partie de ce document Comme nous venons de le rema
300. malisme utilis par les d veloppeurs et constitue le support du dialogue entre ces derniers et les concepteurs L volution des sp cifications report e dans les cahiers d exigences trace les choix de d veloppement point de vue fonctionnel et ventuellement les retours sur la conception de l usage point de vue op rationnel L approche de conception de services orient e usage permet des sp cifications pr cises qui ciblent des besoins clairement identifi s C est une approche qui s applique particuli rement bien dans le cadre de l am lioration d un outil existant La base du d veloppement est en effet d j construite ce qui permet de limiter les sp cifications techniques en r utilisant l existant Cependant cette base existante peut galement devenir une limite car elle rend certains choix impossibles impl menter L it ration du processus est n cessaire pour adapter ces choix aux limites C est pourquoi il est important de privil gier la collaboration et le dialogue entre concepteurs et d veloppeurs pour contourner les probl mes qui pourraient se pr senter lors d une phase plus avanc e du projet terme nous pensons que la combinaison d un ensemble d exigences ainsi sp cifi es permettra de concevoir un syst me entier L uniformisation des choix par des concepts r currents et structur s est la cl de cette combinaison L exemple utilis pour illustrer les trois tap
301. mbles de t ches du mod le concret comme par exemple s lectionner un l ment avec la souris ou avec le clavier Ainsi dans le mod le concret les t ches repr sentent des interactions concr tes avec des objets de la pr sentation manipul e Le contenu d une interface est compos d objets d interaction qui peuvent galement tre sp cifi s de mani re concr te CIO pour Concrete Interaction Object ou abstraite AIO pour Abstract Interaction Object Selon Bodart amp Vanderdonckt 1996 le CIO repr sente tout objet d interface visible et manipulable qui peut tre utilis en entr e ou en sortie d information relative une t che d interaction Le manque d uniformisation et de standardisation dans les CIO limite la compatibilit avec la programmation orient e objets qui manipule des concepts abstraits Cela les rend difficiles r utiliser et maintenir Style Mende Ve Bod Style EN Outined A Underlined i pie O Out lined Underlined g Outlined Figure 32 CIO similaires dans diff rents environnements Un AIO consiste en un ensemble de CIOs d une m me cat gorie mais d finis ind pendamment de leur environnement d impl mentation La manipulation d objets abstraits permet de d finir une interface qui sera r utilisable Elle permet aussi de laisser libres les d veloppeurs quant a l impl mentation de la solution en fonction de l environnement Enfin les Chapitre
302. me de s quences Diagramme de s quences syst me technique Figure 24 Repr sentation des v nements internes au syst me par un diagramme de s quence technique Il transforme le mod le conceptuel du domaine en un autre mod le relationnel E R ou de classes UML qui mod lise quant lui toutes les informations et leurs structures devant tre Chapitre 4 De l utilisateur la conception logicielle et d interfaces manipul es et donc stock es afin de connaitre leur nature et donc le moyen de les traiter Les structures de donn es sont typ es texte lien hypertexte donn e num rique date heure objet multim dia valeur bool enne C est ce qu on appelle l organisation structurelle Cette structure sera utilis e par le d veloppeur pour impl menter la solution dans son environnement de d veloppement sp cifique Plus cette structure contient d l ments d j d finis et cod s plus le d veloppeur pourra gagner de temps en r utilisant ce code Architecte Nom ext Nom Fan Mot de passe texte El ment de mod le du oe objet eras Courriel hypertexte El ment de mod le structurel Figure 25 Exemple de repr sentation d un concept m tier en l ment de mod le structurel Les activit s de l impl mentation L impl mentation d un logiciel est l criture du code interpr t par le dispositif qui l ex cute C est donc originellement une saisie
303. ment et conclusion Les tudes sur CRTI weB nous permettent de relever plusieurs l ments importants relatifs quant au d veloppement d outils logiciels et plus particuli rement d assistance au travail collaboratif coop ratif Les exigences Comme nous avons pu le v rifier en analysant les t ches de d veloppement initi es sur la plateforme apr s son transfert 120 t ches analys es voir en annexes Figure 1431 Figure 144 Figure 145 Figure 146 la moiti d entre elles ont pour point de d part un besoin m tier comme partager des comptes rendus de chantier avec photo connaitre l activit d un collaborateur ou r cup rer toutes les donn es en fin de projet L autre moiti des d veloppements rel ve de l impl mentation de fonctionnalit s ou de l am lioration des fonctionnalit s existantes pour une utilisation plus rapide ou confortable Consid rant aujourd hui l adoption grandissante de CRTI weB dans les projets de construction luxembourgeois la d finition et l outillage des bonnes pratiques taient un premier pas coh rent et n cessaire Mais nous comprenons que malgr la rigueur du travail de conception bas sur l tude de ces bonnes pratiques et du fait du consensus autour des sp cifications fonctionnelles mettre en place tous les besoins n ont pu tre pris en compte et devront l tre au fur et mesure pour assurer l adoption et la p rennisatio
304. ment l outil lui m me comme m diateur de l activit Les services Comme l illustre l exp rience CRTI weB un outil peut tre d compos en plusieurs niveaux de services La qualit de ces services au regard des professionnels d un secteur conditionne l adoption d un outil par ces derniers Le mod le de qualit de services propos dans Bjekovic amp Kubicki 2011 repose sur six crit res la correspondance au m tier qui implique la r ponse une probl matique m tier avec une am lioration des pratiques et par extension la bonne r putation du service dans le milieu la stabilit qui est relative a la justesse du service la pertinence de l information produite sa pr cision et sa disponibilit la performance en termes de temps de r ponse et d utilisation des ressources la s curit assur e par le respect de la confidentialit l int grit c d la pr vention des acc s et modifications la tra abilit et l authenticit lutilisabilit synonyme de compr hension d intuitivit de facilit d utilisation et de pr vention des erreurs vis vis de l utilisateur le respect de l existant de par le support des standards et l interop rabilit avec les services existants Afin d atteindre ces crit res il est n cessaire de structurer le processus de conception des services Il s agit typiquement de fournir une information pertinente aux quipes et d
305. mier tant issu du PIM mais prenant en compte les sp cificit s de la plateforme les autres tant le fruit de transformations successives jusqu l obtention de PISM L ISM Implementation Specific Model est la sp cification du syst me dans son code source Le cadre de r f rence Cam l on Calvary et al 2003 d crit un processus de conception d interfaces adaptables au contexte d usage bas sur la MDA Il associe chaque mod le un niveau d abstraction de l interface tel que nous l avons notamment introduit au 1 10 3 Ces niveaux sont les suivants 1 Voir http www omg org mda Chapitre 4 De l utilisateur la conception logicielle et d interfaces le niveau t che concepts d finit les t ches utilisateurs et les concepts manipul s niveau CIM interface abstraite AUT d finit l interface en espaces de travail li s entre eux niveau PIM interface concr te CUI pr cise chaque espace en termes de fen tres et d objets d interaction niveau PSM PIHM finale FUI ex cutable niveau ISM Sottet et al 2005 illustre un exemple de proposition d interface bas e sur la transformation de mod les Dans son exemple il cherche configurer une interface de gestion de temp rature dans plusieurs pi ces d une maison En suivant les tapes d finies plus haut il d crit le CIM par les concepts manipul s comme la temp rature avec ses valeurs min max et son uni
306. mp R Wagenaar eds Proceedings of the 6th international Conference on Electroinic Commerce pp 1 10 Bain D Chalon R amp David BT 2009 R alit Mixte de la conception l impl mentation m thodologie de transformation de mod lisations IRVO vers la plateforme WComp In Actes des quatri mes journ es de l AFRV Lyon France Bibliographie Baron M et al 2006 K MADe un environnement pour le noyau du mod le de description de l activit In JHM 06 Proceedings of the 18th International Conferenceof the Association Francophone d Interaction Homme Machine pp 287 288 Bass L Faneuf R amp Little R 1992 A metamodel for the runtime architecture of an interactive system ACM SIGCHI Bass L Clements P amp Kazman R 2003 Software Architecture in Practice Addison Wesley Professional Beck K 2003 Test Driven Development by Example Addison Wesley Professional Beck K 2006 Extreme Programming Explained Bennett K amp Layzell P 2000 Service based software the future for flexible software In Software Engineering Conference 2000 APSEC 2000 Proceedings Seventh Asia Pacific pp 214 221 Berard O amp Karlshoej J 2012 Information delivery manuals to integrate building product information into design Tcon Electronic Journal of Information Technology in Construction 17 pp 64 74 Bignon J C Halin G amp Kubicki S 2009 Qualit et processus de mise en oeuv
307. n d crivant les objets du monde r el On parle alors d analyse orient e objet point de d part de la construction ou programmation orient e objets Booch et al 2007 Selon Gordijn et al 2000 le mod le du domaine Business Model d finit ce qui est offert par qui qui et ce qui est attendu en retour Il est important de distinguer le Business Model du Business Process Model c a d le mod le de processus m tier ce dernier d finissant la dynamique du Business Model le comment pour comprendre comment sont orchestr s les services dans une entreprise voir 1 14 2 Chapitre 4 De l utilisateur la conception logicielle et d interfaces Nom Nombre d employ s Chef d quipe On Nom Adresse Propri taire Plan d ex cution Nom Auteur Version Figure 20 Exemple de mod le m tier sous forme de diagramme E R N B Dans les projets de d veloppement d di s des utilisateurs hors d un contexte m tier pr cis ex un guichet de retrait d argent il n est pas n cessaire de mener cette activit L ing nierie des exigences requirements engineering L ing nierie des exigences a pour but de guider la conception du logiciel Nuseibeh amp Easterbrook 2000 cit s dans Sutcliffe 2007 la d finissent pour les syst mes informatiques comme le processus de d couverte d un objectif en identifiant les clients et leurs
308. n de l outil Nous constatons galement que au del de r pondre des besoins m tiers l outil doit tre agr able et simple utiliser Guerriero 2009 cite Davis 1989 en disant que l appropriation d une nouvelle technologie repose sur deux dimensions l utilit per ue et la facilit d usage Notre analyse confirme l ad quation entre ces deux dimensions Chapitre 2 Un cas de d veloppement d un outil de TCAO CRTI weB L tude des usages de la plateforme nous montre que l utilit per ue n est pas absolue Elle fait ressortir la relativit de cette utilit par rapport aux contextes identifi s plus t6t dans la mesure O les utilisateurs ont reconnu pour la plupart la pertinence des services propos s montrant que l analyse du contexte de l activit a permis de r pondre des besoins existants lanon adoption dans certains cas des services est due un contexte utilisateur d j trop fourni en outils et solutions largement adopt es les variations entre professionnels et tudiants montrent l influence du contexte de l acteur sur l appr hension d un outil Au regard de cette analyse nous nous questionnons alors sur la mani re dont on pourrait pr sent am liorer l analyse des besoins afin de pr dire les futures demandes de d veloppement et prendre en compte les contextes utilisateur et acteur pour sp cifier des services r ellement adapt s et ad
309. n favorisant la collaboration autour des diff rents mod les et donc le partage de connaissances explicites valuation et volution des concepts m ta mod les et des formalismes Nous avons pu valuer l int r t d un diagramme de pratiques pour expliquer rapidement comment se positionnent les exigences m tiers du point de vue organisationnel Apr s la deuxi me r union de discussion autour du cahier d exigences le contexte m tier tait compris et le diagramme de pratiques servait de rappel en cas de doutes Son caract re synth tique et cibl sur un cas pr cis est un atout L approche de mod lisation par contextual use case et diagrammes d interaction et l association des deux permet d exprimer ce qui est attendu en terme d interaction Choisissant de nous affranchir du formalisme de K MAD nous avons g n r notre propre diteur partir du m ta mod le d usage MMU tant ainsi plus libres nous avons pu faire voluer le MMU pour qu il d crive exactement les concepts que nous voulions manipuler Pour cette exp rimentation ces mod les se sont montr s plus utiles que pr c demment car il tait n cessaire d introduire une nouvelle fa on d interagir avec le syst me Alors que l exp rimentation pr c dente tait un travail portant essentiellement sur l architecture du service les exigences portaient ici la fois sur le fond et la forme de celui ci fonctionnalit s et interactions
310. n logiciel comprend non seulement sa conception mais aussi son valuation sa distribution et sa maintenance Tel que Booch et al 2007 le d finit une m thode de conception logicielle c est un processus qui vise produire une suite de mod le d crivant avec une notation ou formalisme propre diff rents aspects d un logiciel en cours de d veloppement Il ne s agit pas dans cette tude de d crire toutes les m thodes de conception logicielle mais plut t d en comprendre les concepts importants En d autres termes nous cherchons davantage ici comprendre la m thodologie de la conception logicielle afin d y positionner notre propre m thode en nous demandant notamment Un mod le est la repr sentation de quelque chose sous forme d objet physique ex une maquette ou de description un texte un dessin Un mod le peut servir la description ex le plan d une ville comme la conception ex le plan d une maison construire Chapitre 4 De l utilisateur la conception logicielle et d interfaces comment se d roulent les processus Quels sont les mod les cr s et utilis s 1 9 1 L volution des processus de conception Les m thodes traditionnelles de conception logicielle ont connu leur essor dans les ann es 60 70 p riode de d mocratisation gr ce la baisse des prix mais aussi de croissance en termes de performances des outils informatiques Les premi res taie
311. n the connection will be provided cificih Does it have a particularity in terms of mobility performance autonomy capacity Do you think about a specific model Must be able to connect to internet Figure 132 Contextual use case du service d upload automatique Chapitre 12 La m thode PUSH exp rimentations et bilan Les diagrammes d interaction suivants Figure 133 d composent L intention s identifie en t ches saisit le login et saisit le mot de passe Les objets d interaction concern s login et mot de passe sont des donn es primitives Le syst me devra v rifier ces donn es intention charge les fichiers partir du dossier partag en Copie modifie et renomme les fichiers dans le dossier Les objets avec lesquels interagissent ces t ches sont des fichiers partir de ces fichiers le syst me devra cr er un autre objet document crti web gt Is composed of Is composed of Enter login Enter password Abstract user interaction type Input Abstract user interaction type Input Interact with Interact with 10 Name Logn 10 Name Password Graphical spec text field Graphical spec text field Attributes NIL primitive data Attributes NIL primitive data Data type text Data type text Properties Properties lt Share files from shared folder in OS browser
312. narios servent de base la mod lisation du syst me tant t transform s en mod les conceptuels tant t utilis s comme source d inspiration pour le d veloppement via prototypage voir section suivante tant issus des t moignages des utilisateurs ils pr sentent des limites relatives la subjectivit oubli d information ou au contraire exag ration des probl mes diff rences d opinions Chapitre 4 De l utilisateur la conception logicielle et d interfaces Alors que les buts traduisent des intentions peut tre trop vagues et que les sc narios paraissent au contraire trop sp cifiques il semblerait pertinent selon Misra amp Kumar 2005 de combiner ces deux approches qui s av rent compl mentaires Les activit s de l analyse et de la conception analysis and design L analyse est d finie comme le fait de poser et comprendre le probl me et son domaine en faisant abstraction de l impl mentation Les inputs des activit s d analyse sont donc le mod le du domaine et les exigences que l on aura d finies pr c demment Elles d finissent elles m mes les inputs n cessaires la conception au travers de plusieurs mod les cr s l aide d outils d di s un diagramme UML de cas d utilisation use case diagram Alistair Cockburn 2000 d crivant de mani re graphique un ensemble d v nements ayant lieu entre un ou plusieurs acteurs et le syst me pour accomplir un but
313. nd normalement la fois les propri t s fonctionnelles capacit s du service param tres pouvant varier et les propri t s non fonctionnelles qualit dans la fourniture du service prix Ces derni res ne faisant pas l objet de ce travail notre description concernera essentiellement les capacit s et param tres du service Le fournisseur propose au client le service dont il a besoin Dans notre cas le fournisseur n est autre que l outil consid r le client repr sentant alors l utilisateur de cet outil Kohlborn et al 2009 voque deux caract risations des relations qui ont lieu au cours de l ex cution du service le mod le interactionnel qui caract rise l interaction avec le client par des entr es et des sorties de donn es les Inputs et les Outputs le mod le op rationnel qui d compose le service en un processus d actions ou sous services Le m ta mod le propos dans la section suivante formalise ces quelques l ments de caract risation du service Nous y incluons la caract risation de la mat rialisation d un usage par un service m tier la composition d un service m tier en services informatiques ICT la d composition d un service ICT suivant un mod le architecture logicielle 1 36 M ta mod le de service 1 36 1 Le service mat rialisation de l usage Rappelons qu cette tape de la conception de notre m thode nous connaissons l organisation professi
314. ndustrielle au niveau d un groupe agro alimentaire Seffah et al 2009 Certains feront le choix de tout dire puis de piocher l information n cessaire dans ces donn es d autres limiteront la description ce qui sera utile en omettant les informations superflues Cette information pourra tre d ordre personnel comme professionnel et d finir via diff rents attributs une identit une activit une exp rience une motivation un contexte physique un contexte social etc Constantine dans son approche de conception centr e usage utilise des r les utilisateur user role pour informer le processus de conception propos de l utilisateur Constantine 2006 Le r le utilisateur est d fini comme un ensemble de besoins caract ristiques d int r ts d attentes et de comportements en relation avec un syst me particulier Sa mod lisation se fait par une checklist au travers de trois concepts principaux le contexte les caract ristiques les crit res Figure 31 En fonction des approches l utilisateur arbore donc diff rentes caract risations La section suivante montre qu il en va de m me pour l ensemble des t ches qu il effectue en interaction avec le syst me Chapitre 4 De l utilisateur la conception logicielle et d interfaces C Constantine amp Lockwood Ld i User Role Checklist for Agile Modeling A user role is a relationship with a system Tasks
315. nel type r le op qui d terminera l acc s ou non certains services Ce r le op rationnel est ainsi d pendant du type de service vis dans le projet de d veloppement Il peut tre attribu en fonction du r le organisationnel qui est d fini dans le M ta Mod le des Pratiques M tier MMPM En d autres termes cela implique qu un acteur respecte les usages qui lui auront t attribu s Par exemple le r le op rationnel de r dacteur d un compte rendu de r union chantier est en g n ral attribu au coordinateur du chantier r le organisationnel Cette assignation de r le permet lors de l usage d un outil comme CRTI weB de rendre disponibles aux personnes concern es les services de r daction de compte rendu en ligne propos s service comptes rendus Concernant le service documents les r les organisationnels sont utilisateur administrateur projet et superviseur projet Le choix actuellement limit aux r les op rationnels de CRTI weB pourra tre tendu notamment si l on consid re les outils BIM ex BIM manager Actuellement nous ne proposons donc pas d num ration des types de r le op rationnels possibles mais le m ta mod le pourra voluer Par contre nous jugeons important de sp cifier si l utilisateur aura besoin de s identifier identification oui non pour acc der l usage consid r le mode d identification le plus Chapitre 10 La m
316. nir un prototype op rationnel d placement vers la droite dans le quart sup rieur gauche on parle alors de conception dirig e par les risques Cependant si une des phases pr c dentes de prototypages permet de lever les risques majeurs les prochaines tapes suivent le cheminement classique du d veloppement en cascade quart inf rieur gauche Chapitre 4 De utilisateur la conception logicielle et d interfaces Couts cumulatifs Progression a travers les tapes Evaluation des D termination des alternatives identification objectifs des alternatives et r solution des risques des contraintes Prototype Op rationnel Planification des exigences et du cycle de vie Planification du d veloppement l Validation des Exigences Validation et v rification de la Conception Planification de l int gration et des tests Int gration et Test Impl mentation Planification des phases suivantes Figure 18 Sch ma de la m thode en spirale 1 9 2 Versun processus it ratif Lors d une validation ayant lieu en fin de projet toute valuation n gative aura un co t cons quent car impliquant un retour la case d part dans le processus de conception C est pourquoi les m thodes plus r centes de d veloppement logiciel dites livr cl en main tel que le Processus Unifi de D veloppement Logiciel USDP pour Un
317. nit d finir ici sch matise une Pratique Collective Collective Practice CP d compos e en une ou plusieurs Pratiques Individuelles Individual Practices IP adopt es par le client ou dans un cas similaire Identifier les Pratiques Individuelles d un acteur d un projet de construction permettra de conna tre ses besoins L gende et pr cisions La pratique collective Collective Practice CP est d finie par Un nom name d crivant en quelques mots en quoi elle consiste Colective Practice Une famille family choisie parmi un ensemble d finit 11 familles possibles Une description ayant pour but d expliquer plus Individual Practice pr cis ment la nature de la pratique La pratique individuelle Individual Practice IP est d finie par Unnom name d crivant en quelques mots en quoi elle consiste Une description ayant pour but d expliquer plus pr cis ment la nature de la pratique Les op rations Operations qui composent une pratique Communication individuelle sont de type Communication Contacter Contact Avertir Advertise Demander Ask for Valider Validate D Production Commenter Comment Production Cr er Create Modifier Modify Arren Mettre jour Update Effacer Delete Ex cuter Execute Lier Link Inclure Include labi Diffusion Availability Partager Share Annuler P Av si partage Unshare Recherche Research
318. non conformes de d celer les difficult s qui risquent de resurgir afin de conduire la r union avec un maximum d efficacit En cas de contentieux le compte rendu de chantier constituera toujours une pi ce importante d expertise Tableau 19 l ments de caract risation de la PC8 Documents utilis s Activit s Acteurs impliqu s Maitre d uvre Experts Tout document servant de base la discussion CR de r union T ches d valuation et de coordination Toutes phases plus Ma tre d ouvrage et assistants formelles et structur e Entreprises pendant le chantier PC9 pr paration et gestion du chantier Description l organisation du chantier doit prendre en compte la mise en place d un planning dans lequel seront r parties toutes les interventions de construction Ce planning pourra et devra tre ajust en cas de changements de retards Cela implique galement la livraison et le stockage des mat riaux la mise en place et la gestion des engins la gestion de la s curit Les entreprises qui interviennent sont charg es d ex cuter leurs t ches dans les d lais impartis en respectant l ordonnancement d crit dans le planning C est le coordinateur qui s assure du bon d roulement du chantier et prend note des probl mes rencontr s Le ma tre d uvre se doit de prendre en compte les remarques des ex cutants en cas de modifications apporter aux plans d ex
319. notamment en d composant le c ur fonctionnel en agents savoir des programmes qui ex cutent les requ tes Nous ne souhaitons pas dans notre tude atteindre un niveau de description technique aussi avanc Nous proposons au contraire de synth tiser ces informations pour d crire un mod le d architecture simple que nous pourrons r utiliser pour d crire un service collaboratif Du mod le MVC au mod le Co MVC Nous proposons de repartir de l architecture MVC que nous avons pr sent e pr c demment cf 1 9 3 Figure 26 et d y ajouter la dimension collective introduite dans ce chapitre Nous appelons ce mod le Co MVC Figure 56 Comme l illustre a le Mod le ou Noyau Fonctionnel est divis en un mod le partag ou public et un mod le priv r pliqu pour chaque utilisateur On comprend ici que lorsque le mod le du groupe effectue une requ te ou se met jour cela se r plique chez les utilisateurs qui sont concern s On parle alors de synchronisation Nous r introduisons galement les deux dimensions analys es au d but de ce chapitre en rouge sur la figure la dimension fonctionnelle qui nous permet de distinguer les services de Communication de Coordination et de Coop ration la dimension spatio temporelle qui permet de d finir si des services agissent de mani re synchrone ou asynchrone colocalis e ou distance gt 1 i Contr leur Utilisate
320. nt consid r les objets IFC dans le BIM J Zhang et al 2012 et dans les m thodes de conception bas es sur PIDM CM Eastman amp Jeong 2010 Le nom d un OI est relatif la donn e qu il repr sente Cette donn e pouvant tre d finie par plusieurs attributs peut tre un l ment du contexte coop ratif comme un artefact que ce soit un document ex un rapport m diatis par un fichier texte un objet ex un ouvrage m diatis par un dessin num rique ou un message ex une r action m diatis e par un commentaire sur un fichier un acteur sous la forme d un contact dans un annuaire par exemple ou une activit comme une t che que l on manipule dans un diagramme de gantt Chapitre 10 La mod lisation des usages le point de vue op rationnel Il peut s agir galement d une donn e dite primitive comme par exemple le nom d un document la dur e d une t che dans un planning l identifiant d un acteur Une donn e primitive peut tre l attribut d une autre donn e mais ne poss de pas d attributs elle m me Les types de donn es retenus pour la caract risation des OI sont pour les donn es primitives bool enne num rique date texte et hypertexte pour les autres donn es le fichier le m dia et l ouvrage num rique building information qui est un type de donn e propre au m tier et qui nous permettra de typer plus pr cis ment les inform
321. nt des m thodes en cascade et suivaient un processus lin aire partie gauche Puis elles adopt rent une structure en 2 tapes dite en V le processus de d veloppement dans une approche top down se d roulant de l analyse des besoins vers le code impl ment et le processus de test qui remontait du code vers les besoins partie droite On les a aussi qualifi es de m thodes orient es composants car elles introduisaient le d veloppement par assemblage de composants logiciels pr fabriqu s s inspirant des domaines de l lectronique ou de la m canique Crnkovic et al 2005 Bose 2002 Impl mentation Conception des Test des composants k composants Codage des composants Figure 17 Structure des m thodes traditionnelles de conception logicielle D finition des besoins Conception du syst me Le mod le en spirale Boehm 1988 introduit une variante dans les m thodes de d veloppement pr c demment pr sent es Figure 18 En effet apr s une phase de d termination des objectifs contraintes et alternatives quart sup rieur gauche on identifie et cherche r soudre les risques relatifs aux objectifs Cela se traduit par un premier prototypage et une valuation de celui ci quart sup rieur droit Si ce premier prototypage ne permet pas de lever les risques alors on planifie une seconde phase quart inf rieur gauche et r it re le prototypage jusqu obte
322. nt pas clairement d finies De plus la description d une situation collaborative de par ces relations reste ambigu s Par exemple si un document est cr par un acteur il est aussi le fruit d une activit et galement produit par un outil Il faudrait pouvoir d finir clairement la nature de ces relations Nous constatons donc un besoin de restructurer ce mod le Rappelons galement que la caract risation du contexte de l activit collective a jusqu pr sent t men e afin de visualiser et comprendre de celui ci On parle d ailleurs de multi visualisation le but tant de lier entre elles des repr sentations diff rentes comme le font par exemple les outils Bat iViews Kubicki 2006 et Bat iTrust Guerriero 2009 Nous montrons dans ce travail que cette repr sentation peut aussi servir une approche plus productive en devenant la base de la conception d outils On note ce propos que dans sa th se Annie Guerriero ne consid re pas l outil lorsqu elle traite de la confiance vis vis du contexte d un projet Ce concept suscite en effet l interrogation l outil fait il partie du contexte d un projet ou est ce qu il l instrumente Doit il tre consid r en m me de temps ou a posteriori des caract risations du projet Nous choisissons de consid rer l outil comme un moyen de m diatiser le contexte de l activit collective d un projet et non pas comme un l ment de celui ci Cela n
323. nt permis de valider les concepts de pratique usage et service comme concepts cl s des tapes de conception d un service La deuxi me exp rimentation a montr un autre cas d am lioration de service en se concentrant sur la simplification de l interaction au niveau de l usage Elle a fait ressortir l importance de d crire le contexte m tier et l utilit de la mod lisation de pratique de d crire le contexte technique ce qui est attendu et l utilit de la mod lisation de l usage de d crire ce qui est propos et l utilit de la mod lisation du service La troisi me exp rimentation a valid l int r t de la m thode en tant que moyen de formaliser un processus de conception partir d une id e de service d crite par un maquettage Elle a permis de pr ciser les concepts utilis s et d introduire les objets d interaction en tant qu l ment de description de l information m tier m diatis e Chapitre 12 La m thode PUSH exp rimentations et bilan Transmettre information le r le des mod les Un projet de conception de services est un projet collaboratif en lui m me ce qui implique l intervention de plusieurs points de vue sur le processus Nous avons associ ces points de vue plusieurs mod les qui permettent de les exprimer Figure 141 Les exp rimentations ont permis d observer le r le de ces mod les Les mod les de pratiques perm
324. nt se d roule la collaboration afin d identifier les pratiques de chacun les unes vis vis des autres Cela permettrait de mieux d crire ces pratiques mais aussi de pouvoir les optimiser dans une probl matique d am lioration de la collaboration Nous pouvons nous poser la question de la s paration entre ce qui rel ve de la pratique m tier autrement dit ce qui doit tre fait par des professionnels quel qu en soit le moyen et ce qui rel ve de l usage du dispositif pour assister cette pratique m tier Dans l exemple propos la diff rence apparait clairement la phrase le technicien dite le compte rendu et pr pare la facture d crit une pratique li e au r le et la mission du technicien alors que des informations telles que tous les matins chez le client ou avec un PDA sont des informations contextuelles relatives un usage particulier Dans ce contexte m tier les sc narios de travail et les usages qui les assistent sont r p titifs et pr d finis Aussi il n est pas r ellement n cessaire de s parer leur mod lisation Ici encore dans un contexte plus complexe comme celui du projet AIC nous pressentons la n cessit d aller plus loin dans la mod lisation en identifiant des variations d usage pour une m me pratique sur le chantier avec un smartphone et au bureau avec un ordinateur par exemple Comme nous pouvons le lire p 149 il est n cessaire de reformuler certains
325. nts du service diagramme de s quences Les informations m tiers diagramme de pratique deviennent des objets d interaction diagramme d interaction Les objets d interaction diagramme d interaction servent sp cifier les donn es chang es lors de l ex cution du service diagramme de classes Chapitre 12 La m thode PUSH exp rimentations et bilan l 4 CP validation des choix conceptuels CP Family 5 Design and reporting Les concepteurs diffusent leur proposition aupr s des maitres d ouvrage qui l valuent gt Correspondances entre les mod les SHARE G upload multiple files lt lt include gt gt Plans du projet au stade APS Designer Author Designer lt Add here more specifites if needed gt Status In Progress choose collaborators to inform Pres Le en i composed of fen A Choose files and clustering mode Abstract user interaction type Selection 1_n Rany Jp Tren N L new dowload activation name crti web document notification ental Concrete user interactin type Trigger merc with Abstract user interaction type Input Graphical output omen Fie selection ro Name Documents F interact wih Concrete user interactin type Selection me 9 Loading visuaization Data type fie p br arsterina mode selection Graphical spec Icon la
326. number lt lt action gt gt 2 gpedfyChecked Folder folder names lt lt action gt gt 3 requestDataVerification ID pasword crti web URL project number lt lt action gt gt 4 verifyData Ib pasword crti web URL project number lt lt action gt gt A N E See O N EE 6 validpteData 7 notfyOfConnexion H lt lt action gt gt 66 vue ween a A Du Les pha vanis D buter avec Frey Gi la une Free Hotmail Suggested Sans Vad Se Galery E Conception colsborstve part o Mdi C Dare on Sod CRThiueB sdc construction tudorlu tt URL de la plateforme Identification r f rences CRTI BOX une information ou une inscription immediate contacter le numero national 8692 2780 ou de l tranger le num ro 08 352 26 64 3 43 50 admin Url Web Services NNW isde construction tudor lu Num ro du projet 5 T n du projet Q rie Valider X Annuler Notifications sur la barre des t ches Figure 135 Illustration du r sultat obtenu au niveau de l interface par rapport aux exigences 1 41 4 Conclusion Cette exp rimentation a permis de mener un processus de d veloppement de service pour CRTI weB mais dans un contexte diff rent de l exp rimentation n 1 Les utilisateurs taient diff rents puisqu ils taient tudiants et non des professionnels ce qui avait un impact sur leurs usages De plus le contexte de d veloppement tait galement diff
327. o oui nonfinconnu Type_applicatioi Type_entr e _audio oui nonjinconnu Technologie texte Type_sortie _vid o oui nonfinconnu Type_sortie _audio oui nonfinconnu Pratique colllective td Nom texte Type_famille num ration Description texte Service m tier nom texte description texte EE fournit S ex cute repr sente nom texte Donn e texte A Mod le commet A lt I oui non Pratique Individuelle T che outil Nom texte Description texte Service ICT nom texte technolo texte 2 JR execute Concerne Type_artefact num ration D nomination texte Type_acteur num ration Type_auteur lt type_rdle gt Type_r le num ration D nomination texte iad Type_statut num ration repr sente Nom donn e texte Type_donn e num ration Attributs texte Forme texte repr sente repr sente Figure 115 Version simplifi du M ta Mod le des Services Adapt s MMSA composition du MMPM en rouge du MMU en bleu et du MMS en vert Chapitre 11 La mod lisation des services le point de vue fonctionnel res Mod le partag Chapitre 11 La mod lisation des services le point de vue fonctionnel 1 37 Mod lisation des services et impl mentation Nous utilisons le diagramme de s quences pour d crire le comportement du client et d
328. od L a D 2003 Usage centered software engineering an agile approach to integrating users user interfaces and usability into software engineering practice In Software Engineering IEEE Computer Society pp 746 747 Constantine L amp Windl H 2003 Usage Centered Design Scalability and Integration with Software Engineering Human Computer Interaction theory and Practice Constantine L 2003 Canonical abstract prototypes for abstract visual and interaction design In J Jorge N Jardim Nunes amp J Falc o e Cunha eds nformation Systems Design Specification and Verification Springer Verlag Berlin Heidelberg 2003 pp 1 15 Constantine L 1998 Rapid abstract prototyping In Software Development pp 1 9 Cooper A 1996 Goal directed design Crawford C Bate G amp Cherbakov L 2005 Toward an on demand service oriented architecture IBM Systems 44 1 pp 8 1 107 Crnkovic I Larsson S amp Chaudron M 2005 Component based development process and component lifecycle Computing and Information Technology CIT 13 4 pp 321 327 Curtis B 1992 Process modeling Communications of the ACM 35 9 pp 75 90 David B 2001 IHM pour les collecticiels R seaux et syst mes r partis Herm s Paris 13 pp 169 206 Davis F 1989 Perceived usefulness perceived ease of use and user acceptance of information technology MIS quarterly 13 3 pp 319 340 Davis W 1999 The requirements
329. od lisation des usages le point de vue op rationnel fr quent est l attribution d un nom d utilisateur et d un mot de passe En effet la reconnaissance du r le op rationnel passe par cette phase d identification Nous consid rons l outil comme l agr gation de deux l ments le dispositif mat riel et l application logicielle Comme nous l avons fait dans le m ta mod le pr c dent MMPM nous incluons un type autre dans chaque num ration dans l ventualit ou celles ci ne suffiraient pas d finir l information voulue Nous distinguons plusieurs types d application Les applications dites natives sont d pendantes du syst me d exploitation OS sur lequel elles sont ex cut es alors que les applications web sont ex cut es sur serveur et accessibles via un navigateur web depuis n importe quel dispositif Les applications hybrides utilisent les deux modes de fonctionnement Dans tous les cas il sera n cessaire de d terminer la technologie de d veloppement utilis e Nous d finissons le dispositif mat riel par plusieurs l ments Nous pouvons inclure ici le type inconnu car il se peut que l information ne soit pas accessible dans un cas de figure particulier On identifie donc un type dispositif ordinateur tablette smartphone autre un ou plusieurs type OS fonction du type de dispositif windows macOS linux windowsphone iOS android autre
330. ogicielle de r organiser et red ployer des processus m tiers des composants fonctionnels et des informations sous forme de services autonomes Van Den Heuvel 2009 He 2003 En effet la r duction de l interd pendance entre les services le loose coupling permet de r duire les risques induits par le changement d un l ment sur le reste du syst me Ainsi l volution partielle du contexte organisationnel d une entreprise n aura d impact que sur les services concern s et non sur l int gralit du syst me Chapitre 5 De l entreprise orient e services la conception de Syst mes d Information Le cas particulier des services web Avec la g n ralisation de l utilisation des r seaux et plus largement d internet autant dans le milieu professionnel que dans les foyers l acc s aux services m tiers par le biais des services ICT est d sormais commun Le client d un service peut aujourd hui o qu il soit tre int gr dans l architecture d entreprise et trouver son service en tant qu utilisateur de services informatiques connect s via le web on parle alors de services web Le service web peut tre d fini litt ralement comme une interface qui d crit une collection d op rations qui sont accessibles par un r seau Gottschalk et al 2002 Il est d crit gr ce un langage nomm WSDL Web Service Description Language et stock dans les serveurs du fourniss
331. oie notification lors suppression Avertir certains le syst me envoie une 204 document et changement de zone collaborateurs d une notification Infomration mieux transmise 209 CN affich e est celle de l OAI et pas celle Rectification d une erreur Mise jour page de garde acc s plaquette Fa er Nouvel usage Acc s une information utile 211 et mise en valeur du contact G n rale consultation des infos Meilleure lisibilit Interdire la cr ation d un compte rendu si R diger un CR apr s le Usage succ dant Pas d incoh rence dans 227 pas de r union li e d roulement d une G n rale obligatoirementaun l information 231 Ajout support GIF dans clearbircks Contenu Format de fichier Plus de possibilit s de partage statistique mesurer le temps de r action 237 un document suite sa mise en ligne NIL Destin aux d veloppeurs statistiques sur temps d acc s aux 238 documents et actions suite au d pot de NIL Destin aux d veloppeurs Statistiques int gration des informations 240 jde la classe stats class php NIL Destin aux d veloppeurs Pa Utilisateur avec un Accessibilit aux utilisateurs 241 Traductions Contexte language diff rent d autre nationalit export d un chantier complet de CRTI weB hors gestion CR sous format XML pour R cup rer toutes les D finition du format de 246 futur r import et format HTML pour les donn es en fin de projet Contenu donn es Nouvelle fonctionnalit utile Fe ee Utilisateur avec
332. ompagnies am lioration et l expansion des moyens d atteindre le client la proposition de nouveaux ordres de prix et de m canismes de revenus 3 http fr wikipedia org wiki Entreprise http fr wikipedia org wiki Fordisme Chapitre 5 De l entreprise orient e services la conception de Syst mes d Information SaAl edWoo Strat gie Model Environnement social Changement technologique Processus Figure 48 Corr lation entre Business model Environnement Strat gie Processus et Syst mes d Information Ostwalder 2004 p 16 La valeur des services ICT n est donc plus a prouver dans un business model qui se veut comp titif Dans la section suivante nous nous int ressons particuli rement leur conception a partir de la mod lisation des processus m tiers 1 14 Dela mod lisation des Processus M tier au Syst me d I nfor mation 1 14 1 Introduction la conception de Syst mes d Informations SI Un syst me d information est la combinaison des activit s des membres d une entreprise c a d qui supportent les op rations m tiers la gestion et la prise de d cision et des technologies de l information qu ils utilisent c d pour stocker r cup rer et transmettre de l information Zachman 1987 s est inspir du domaine de la construction pour conceptualiser l architecture des syst mes d information Son framework permet de d crire un SI
333. on architecturale Projet de conception de services Figure 1 Conceptualisation d un projet de conception architecturale pour la sp cification d un projet de conception logicielle Introduction Plan de la th se Trois parties composent ce manuscrit et int grent les l ments de la probl matique que nous venons de d gager Elles d crivent une approche qui est elle m me une approche de conception la conception d une m thode pour l adaptation de services au contexte collaboratif d un projet AIC Partie 1 assister la collaboration dans les projets de construction La premi re partie compos e de trois chapitres d crit les deux contextes de l tude Le premier est le contexte scientifique une lign e d tudes et notamment de th ses sur la coordination dans les projets de construction son analyse sa visualisation Le deuxi me est le contexte d application le d veloppement de services d assistance la collaboration pour le secteur luxembourgeois de la construction La probl matique y est alors d taill e suivie de la m thodologie adopt e dans le chapitre trois Partie 2 th ories et m thodes concevoir des services collaboratifs adapt s Quatre chapitres composent cette partie et explorent des champs d tudes parall les relatifs la conception de services informatiques Nous les pr sentons au travers de plusieurs paradigmes de la conception logicielle Le premier chapitre chapi
334. on formalis e par des m ta mod les sous forme de diagrammes de classes UML nous a permis de lier conceptuellement les aspects organisationnels relatifs aux pratiques aux aspects op rationnels relatifs aux usages Ce lien se retrouve dans l instanciation de ces m ta mod les travers l adaptation des formalismes utilis s cet effet Figure 111 Ainsi le diagramme de cas d utilisations est directement con u pour r pondre aux op rations m tiers identifi es Il est compl t par diverses informations de contexte ce qui en fait un mod le pertinent pour d crire la m diatisation d une pratique par l usage Le travail sur les t ches d interaction peut para tre superflu sur un cas simple comme celui pr sent Le diagramme de cas d utilisation aurait suffi d crire l usage attendu Il pourra cependant tre plus utile dans d autres cas d tude comme nous le verrons dans le chapitre 12 de ce manuscrit Dans un Framework de MDA Model driven Architecture comme Cam l on introduit au 1 11 2 le premier niveau du processus le CIM d finit les t ches utilisateurs et les concepts manipul s M me si cela n est pas exploit ici la d finition du diagramme d interactions pourra donc s inscrire dans ce genre d approches g n ratives Cela pourra faire l objet de travaux futurs Chapitre 10 La mod lisation des usages le point de vue op rationnel CP validation des choix conceptuels
335. on gain de temps Lors de l ajout d un niveau d historique MaJ d une remarque il est n cessaire de Identifier les commentaires des T che contenu Identifier date de remarque Meilleure compr hension gain de temps Lors de l ajout d un niveau d historique il est n cessaire de pouvoir modifier les Lorsqu on effectue un enregistrement et que l on revient dans la liste des remarques il faut repositionner la fen tre Gain de temps plus de confort la modification d une remarque ajout d historique devrait pouvoir se faire directement dans la liste des remarques Les photos devraient pouvoir tre int gr es la version PDF du compte Oui Partager CR de chantier avec des photos T che d ouverture du d tail de la remarque supprim e T che Contenu Int grer photo Gain de temps plus de confort Plus d informations partageables Centralisation des informations L ergonomie de la visionneuse de photos N Archivage des donn es en fin de projet Meilleure ergonomie Adaptation des Web Services Modification des templates Ajout d id pour tests automatiques Selenium Externaliser le code JS d un fichier tpl Cr er un web service pour l upload d un ou plusieurs documents pour un projet Externaisation m thode v rification CN au chargement d un document Pour sauvegarder la date d ajout d un historique de remarque il manque un Lorsqu on veut mettre une action sur un document i
336. on To Human Computer Interaction Lawrence Erlbaum Associates Bose D 2002 Component Based Development Application in software engineering Bouattour M 2005 Assistance la conception coop rative fond e sur la s mantique des ouvrages Application au domaine du bois Nancy Universit Boucher E 2009 Software as a Service Quelle est la maturit de ce march et les possibilit s d utilisation par les entreprises HEC Paris Bourguin G amp Derycke A 2005 Syst mes Interactifs en Co volution R flexions sur les apports de la Th orie de l Activit au support des Pratiques Collectives Distribu es Revue d Interaction Homme Machine 6 1 pp 1 31 Brown A Conallen J amp Tropeano D 2005 Introduction Models modeling and model driven architecture mda In S Beydeda M Book amp V Gruhn eds Model driven Software Development Springer pp 1 16 B zivin J amp Kurtev I 2005 Model based technology integration with the technical space concept In Metainformatics Symposium Springer Verlag Calvary G et al 2003 A unifying reference framework for multi target user interfaces Interacting with Computers 15 3 pp 289 308 Cardoso J et al 2004 Quality of service for workflows and web service processes Web Semantics Science Services and Agents on the World Wide Web 1 3 pp 281 308 Cesare S amp Lycett M 2003 Business modelling with UML distilling directions for futu
337. onnalit 458 _ l administrateur projet de voir tous les Oui gestion men es par un T che documents limit un un type d utilisateur PROMOBE Possibilit pour Plusieurs pratiques de Contexte Acc s tous les CR Attribution d une fonctionnalit 459 l administrateur projet de voir tous les CR Oui gestion men es par un T che limit un utilisateur un type d utilisateur 463 Prise en compte du dans les adresses Non NIL D tail fonctionnel Actuellement l administrateur CRTI weB peut ajouter autant de groupes qu il veut Plusieurs pratiques de Edition et modifications mais ne peut pas les diter o les gestion men es parun Contexte d e groupes par un Attribution d une fonctionnalit 464 supprimer Il faut d velopper Oui seul acteur T che utilisateur un type d utilisateur 465 _ cr ation du r pertoire d upload d un projet non nu pestin aux d veloppeurs Possibilit d annuler l abonnement sur un V rifier ou pas Possibilit d annuler 466 groupe de documents Oui l volution d un T che une t che Consulter la liste des Nouvel usage d export Information dans un format 471 Export PDF d une liste des documents Oui _ documents partag s G n ral au format pdf appropri l change 478 Envoyer un mail la suppression d un Oui Avertirles T che _ T che syst me de Meilleure compr hension gain de Ajouter
338. onnelle d un projet AIC caract ris e par le m ta mod le du contexte coop ratif MMCC nous avons caract ris les comportements m tiers sous forme de pratiques collectives et individuelles et d op rations partir des concepts de ce MMCC et en cr ant le m ta mod le des pratiques m tiers MMPM nous avons caract ris la m diatisation de ces pratiques par les usages d outil d di s d finissant l outil l utilisateur et l interaction qui a lieu entre les deux dans leur contexte particulier en cr ant le m ta mod le d usage MMU partir des concepts du MMPM Chapitre 11 La mod lisation des services le point de vue fonctionnel Il s agit maintenant de caract riser la mat rialisation des usages par les services en cr ant le m ta mod le de services MMS Figure 112 d riv du MMU Conform ment a la description que nous en avons faite plus haut le service m tier materialise l usage il est caract ris par un nom et une description son fournisseur repr sente outil il est compos de services informatiques ICT le client de ces services repr sente l utilisateur de outil la relation client service n est autre que l interaction entre l utilisateur et outil pr c demment d finie par les t ches et objets d interaction Les inputs et outputs sont des flux de donn es en entr e et sortie Ils sont d finis par une action effectu e et une donn e
339. ons entre acteurs informelles peu trac es et peu pr dictives Chapitre 1 La coordination dans les projets de conception construction architecturale Nous avons pr c demment distingu coordination collaborative et coordination coop rative Pour rappel on peut dire que lors d une coop ration on sait pr cis ment ce qu on va faire alors que dans la collaboration on a l id e de ce vers quoi on va sachant que cela peut voluer Rameau amp Samyn 2006 Afin de mieux comprendre la nature des processus de coordination Kubicki 2006 op re trois autres distinctions entre coordination explicite bas e sur les artefacts et implicite orale entre coordination hi rarchique multi acteurs adhocratique inter acteurs et transversale extra acteurs entre ajustement mutuel supervision et standardisation La coordination explicite se base sur une ligne de progression bien tablie et la r solution des probl mes par anticipation Cependant anticipation des probl mes n est pas toujours possible et il est n cessaire d adapter le processus aux changements on parle alors de coordination implicite Andersen et al 2000 C Godart et al 2001 La coordination hi rarchique ou multi acteurs repose sur le partage de l information pour le groupe et la conscience de celui ci en ce qui concerne le d roulement du projet La coordination adhocratique ou inter acteurs caract rise un travail d act
340. onsistant partager des plans et autres sp cifications techniques avec les dessinateurs de l agence pour cr er les diff rentes vues du b timent dans la Pratique Collective changes de document pour le partage de la conception une deuxi me consistant partager les plans et documents techniques avec l entreprise de construction dans la PC change des documents pour ex cution Une pratique individuelle similaire serait celle du partage de documents avec l conomiste charg de d terminer les co ts du b timent A Vr Design phase The end of the design phase particularly called production phase CP Documents exchange for design sharing A Designer CP Documents exchange for execution CP Family 5 Design and reporting The main designer of the project he leads the project CP Family 9 Execution preparation and management Designers work together to produce project documents Job Architect Contractors get the documents from designers who share it for execution for execution 1s comput of Executes Exacta Is compcse of 1P Diffuse design documents for designers team 1P Diffuse design documents for construction enterpris Execution is based on plans provided by designer Fa ades 3Ds sections are based on plans provided by designer Ty Campuses of 1s comme d Is comme of 1s compas of 1s compmed d N gt gt N Inform Share W Share Inform Already supported by a s
341. opt s par chacun Sujet Outil Outils de TCAO adapt s Figure 13 Vers des outils de TCAO adapt s au contexte tri facettes La m thode de d veloppement Les premi res versions de l outil ont t d velopp es en interne au CRP Henri Tudor qui a galement assur un r le d expert m tier en troite collaboration avec les praticiens du domaine D s le transfert vers le secteur professionnel les d veloppements furent confi s une soci t de services externe Kitry Consulting D s lors le processus est pass dans un sch ma collaboratif avec une r elle r partition des t ches de conception d veloppement et d valuation entre acteurs diff rents Dans cette activit de d veloppement qui n est pas sans rappeler l activit collective d un projet AIC la coordination est galement un enjeu Depuis 2009 la soci t externe commercialise la solution et se charge galement de la formation et du support des utilisateurs Lorsque des modifications purement fonctionnelles doivent tre r alis es ils d veloppent directement une solution mais lorsque cela rel ve d un probl me m tier un processus de conception est de nouveau mis en uvre bas sur l analyse des besoins et support par les experts m tier C est 7 http www kitrygroup com aa Chapitre 2 Un cas de d veloppement d un outil de TCAO CRTI weB d ailleurs ce r le que nous avons tenu au
342. optons un point de vue plus technique par la description de leur architecture logicielle Chapitre 5 De l entreprise orient e services la conception de Syst mes d Information Chapitre 6 Travail Collaboratif Assist par Ordinateur et Services Collaboratifs Ce chapitre introduit dans un premier temps les notions propres la description des outils de Travail Collaboratif Assist par Ordinateur TCAO et tend cette description aux services qu ils proposent les services collaboratifs Pour Vissers et al 2004 les services collaboratifs sont con us pour supporter les groupes de personnes qui interagissent entre elles dans leurs t ches collaboratives Nous mettons ensuite en avant les raisons d chec de ce genre de services et les principes pour y rem dier D apr s Veer 1996 la conception des collecticiels forme une nouvelle branche dans les m thodes de conception Dans la continuit des propos tenus dans les chapitres pr c dents nous consid rons cette branche comme un nouveau paradigme 1 16 Description des outils de TCAO et des services collaboratifs 1 16 1 Les dimensions fonctionnelles et spatio temporelles Les outils de TCAO aussi appel s collecticiels supportent les pratiques collectives de leurs utilisateurs de plusieurs mani res on dira qu ils couvrent un ou plusieurs espaces fonctionnels Ellis amp Wainer 1994 Les trois espaces fonctionnels principaux qui composent ce
343. orum etc Le sch ma suivant recompos partir de Laaroussi 2007 et Guerriero 2009 illustre une r partition de ces services supportant la conception architecturale en fonction des dimensions fonctionnelles pr sent es pr c demment Figure 55 L aspect r actif est relatif 4 une activit qui volue et s adapte dont le contenu change avec l environnement avec la personnalit des acteurs Une activit pr dictive doit quant elle tre planifi e et instrument e o l on d finit au pr alable les actions qui seront men es ne me mn ne en Aspect r actif pet aay ae Aspect predictif rvision directe Commuhication Peers GB nm l l l l l l l l l l i l t I l l wad To do list l l CAO Workflow i s I Plateforme Compte rendu Pianification DOE l 1 l F taie Evaluation pertormance 7 Rroduction Free 1 fn su Coordination Simulation w PUITIGFIQUG j om of eee eee ee 4q i a I Pa Visualiseur l Tableau blanc de contexte 1 _ eS bes l Partage dicen l l 1 1 I l at 1 LI I Visio Coh rence l T f l I 1 l Convefsation Ajustement mutuel i e eee un un un un ue ue de le ln fe _ _ i a re E ER ee ees 4 Figure 55 Positionnement des services par rapport aux caract ristiques d une activit collective Laaroussi 2007 et Guerriero 2009 1 1
344. ou d une t che que celui ci doit accomplir vis a vis de ce document Ces attributs servent organiser l information dans l espace partag et au m me titre que les r f rences du compte rendu les rechercher Chapitre 2 Un cas de d veloppement d un outil de TCAO CRTI weB 1 4 3 Services propos s Les fonctionnalit s de l outil propos sont regroup es en deux services dits services m tier que sont le service d dition et diffusion de comptes rendus et le service de partage de document conform ment aux deux besoins identifi s Le concept de service m tier est ici utilis pour d composer l outil avec un haut niveau d abstraction Chaque bonne pratique est ensuite outill e par un service informatique une solution fonctionnelle pour effectuer cette pratique Le tableau suivant d crit les services informatiques propos s pour chaque bonne pratique dans les services m tier compte rendu CR1 8 et documents Docl 7 Tableau 2 Les 15 services informatiques composant l outil CRTI weB BP Ser vices informatiques CR1 R daction CR2 G n ration d un brouillon pdf CR3 Consultation CR4 Tri des remarques par organisme CR5 R actions CR6 Notifications CR7 G n ration d un Pdf s curis CR8 Recherche Doc Nommage de documents et convention de nommage Doc2 Mise a jour Doc3 Notifications Doc4 Actions Docs
345. our l dition de textes ex avec Google Documents mais aussi plus r cemment pour la cr ation de plans ex Autocad voin Figure 8 La maquette num rique peut aussi tre utilis e en situation de conception l ing nieur pouvant par exemple r cup rer le mod le tabli par l architecte en vue de dimensionner les structures ou encore de r aliser des simulations Guerriero 2009 Chapitre 1 La coordination dans les projets de conception construction architecturale AP ll D A AR Oe Share Collaborate Document Now Share amp Collaborate igs OEE E LISE en Eml Figure8 Fonctionnalit s collaboratives dans l outil de CAO Autocad L association de deux outils que sont le bureau virtuel une table dessin num rique coupl e un syst me de visioconf rence et le logiciel Sketsha un logiciel de croquis distribu s 9 est un exemple de dispositif de m diatisation de la conception collaborative par l esquisse Il permet deux quipes distantes de collaborer dans des conditions reproduisant la copr sence de collaborateurs g ographiquement dispers s Il est notamment utilis dans un projet de co conception en milieu universitaire nomm le Studio Digital Coop ratif SDC Safin et al 2012 Figure9 Utilisation du dispositif Bureau Virtuel Sketsha au cours du projet SDC photos tir es de Saffin amp Leclercq 2010 1 23 L adaptation
346. our consigner les mod les des usages imagin s et outiller Les d veloppeurs tudieront les choix formalis s pour proposer une solution qui corresponde Ici encore l quipe actuelle ou une future de d veloppement pourra s y r f rer en cas de doute sur les choix de d veloppements Aux d veloppeurs avec les concepteurs pour sp cifier et consigner les mod les de l architecture du service propos Cette formalisation s av rera tr s utile pour la p rennisation du service en cas de changement d quipe de d veloppement Utilisateur Expert m tier Concepteurs D veloppeur or j on maa Me v a aan ni Pr N N r NS 7 N l x l x 1 I Communication bd VV Mod les Arbres hi rarchiques tableaux diagrammes M1 Pratiques _ M1 Usages ma M1 Services Monde r el les projets AEC Cahier d exigences CA Figure 85 G n ration du cahier d exigences partir des mod les cr s Chapitre 8 Introduction de la proposition 1 26 Conclusion Nous proposons une m thode pour concevoir de services informatiques adapt s aux pratiques m tiers d un projet de conception construction architecturale Elle est bas e sur la description de trois concepts les pratiques m tiers identifi es c est ce qu on appelle le point de vue organisationnel dont est responsable l expert m tier les usages associ s choisis c est le point de vue op rationnel exprim par le concepteur
347. ous permet en effet de traiter leur description de mani re s par e d abord le m tier puis l outillage cherchant ensuite caract riser le lien qui s op re entre activit collective et outils travers cette m diatisation Le sous chapitre suivant justifie le besoin d une telle m diatisation et pr sente ensuite des exemples d outils 1 2 Les projets de construction et les outils de TCAO 1 21 Pourquoi m diatiser l activit collective Kubicki et al 2006 rel ve l importance de la ma trise des processus de coordination pour assurer le succ s d un projet AIC et par extension la qualit du b timent construit Certains facteurs li s la nature du projet AIC et porteurs de risques c d susceptibles de s opposer son bon d roulement font merger l importance de cette ma trise de nombreuses contraintes fonctionnelles techniques conomiques et esth tiques qui varient d un projet un autre de nombreux acteurs avec leurs propres connaissances et m thodes de travail certains parfois r fractaires adapter celles ci un projet particulier des quipes ph m res qui se recomposent tout au long du projet des relations contractuelles non hi rarchiques et des d cisions non centralis es particuli rement en phase chantier un s quen age du projet bas sur des prises de d cision sur le tas mais pourtant d terminantes et parfois irr versibles des interacti
348. out the actor using the system Eventually precise here his skills knowledge abilities preferences Click here to enter text The application specificity Is there already a developed application to adapt You can describe it here Click here to enter text What about the new services to develop Click here to enter text The device specificity Does it have a particularity in terms of mobility performance autonomy capacity Do you think about a specific model Click here to enter text De RELATED USAGES You can specify the link between the usage you described and others space ick here to Click here to enter text Choose anitem Choose an nter text item enter text item er text item nter text item nter text item PART 3 SERVICE SERVICE SPECIFICATION Insert here the sequence diagram Annexes Designing collaborative services adapted to business practices a usage center ed method Application to the construction sector Abstract In the sector of the architectural design construction project the management of the collaboration between the different actors of a project is an important issue From a project to another considering the project type and also the actors involved business practices vary In parallel many services are proposed and used to assist the collaboration some of them being generic and others more specific to professional usage
349. ouvrage owner Expert Constructeur constructor Coordinateur coordinator Administration Conseiller advisor Actor autre other Un m tier job architecte architect ing nieur A Group of Actors structure sant s curit structure safety health engineer urbaniste urbaniste Ma on Mason Electricien Electrician Charpentier Carpenter autre other Une description plus sp cifique Les groupes d acteur sont d finit par les m mes attributs et par un type de groupe Le projet project dans lequel se d roule la pratique collective est d fini par Project Un type Habitat individuel Individual Housing Habitat collectif Mass Housing B timent public Public Phase building Une certification environnementale certification type La phase de projet dans laquelle se d roule la pratique Business Task collective est d finie par Un type Pr paration Conception Design Ex cution Livraison Delivery La T che m tier est d finie par Un type de conception design d ex cution execution d valuation assessment de ynth se synthesis de coordination coordination Un auteur d fini par son r le organisationnel Le projet les phases et les t ches sont consid r es comme des activit s et sont galement d finie par des dates relatives de d but strating date de fin ending date d interruption interruption date etc Un ty
350. p differences In Proceedings of the second conference on European Conference on Computer Supported Cooperative Work Kluwer Academic Publishers pp 17 32 Greenberg S 2006 Toolkits and interface creativity Multimedia Tools and Applications 32 2 pp 139 159 Greer D amp Hamon Y 2011 Agile software development In Software Practice and experience pp 943 944 Gregor S 2009 Building theory in the sciences of the artificial Proceedings of the 4th International Conference on Design Science Research in Information Systems and Technology DESRIST 09 Grinter R Herbsleb J amp Perry D 1999 The geography of coordination dealing with distance in R amp D work In Proceedings of the international ACM SIGGROUP conference on Supporting group work Grudin J 1994 Computer supported cooperative work History and focus Computer 27 5 pp 19 26 Grudin J 1988 Why CSCW applications fail problems in the design and evaluation of organization of organizational interfaces Proceedings of the 1988 ACM conference on Computer supported cooperative work CSCW 88 pp 85 93 Guerriero A 2009 La repr sentation de la confiance dans l activit collective Application la coordination de l activit de chantier de construction Universit Henri Poincar Nancy 2 Bibliographie Guerriero A Zignale D amp Halin G 2012 A Zoomable Location Based Dashboard for Construction Management In CDVE20
351. pe de dur e long long ou court short n Chaque l ment poss de un champ d dition libre destin en compl ter la d finition par toute information suppl mentaire jug e utile la description de la pratique On retrouve plusieurs types de relations liant les diff rents l ments pr sent s ci dessus Les relations de composition is composed of une Pratique Collective est compos e de Pratiques Individuelles une PI tant compos e d Op rations La relation ex cute executes relie un acteur une Pratique Individuelle La relation produit creates relie une op ration un artefact lorsque ce dernier est le fruit de l op ration qui le manipule ex cr er un document La relation utilise uses relie une op ration un artefact lorsque ce dernier n est pas le fruit de l op ration qui le manipule ex partag un document cr La relation cible targets relie une op ration un acteur auquel elle a recours ex avertir le concepteur Partie 2 Usages Comme introduit dans la description de l analyse m tier voir 1 il s agit pr sent de d crire la m diatisation des Pratiques m tier Individuelles PI et donc des Op rations qui les composent travers l Usage d un service informatique adapt La d finition de l usage se fait travers un diagramme de cas d utilisation use case diagram dans lequel chaque op ration operation sera d compos e en
352. pement Travail collaboratif Conception centr e sur l utilisateur Design patterns Architecture Informatique Architecture Pratique
353. permet aussi de simplifier l activit de gestion du projet Chapitre 4 De l utilisateur la conception logicielle et d interfaces La m thode SCRUM Le nom scrum se rapporte au domaine du rugby c est cette mani re de recommencer le jeu r p titivement tout au long d une partie La m thode de d veloppement agile SCRUM Schwaber amp Sutherland 2011 Schwaber amp Beedle 2001 est galement bas e sur le fractionnement du d veloppement en cycles courts 1 4 semaines qui sont ici nomm s les sprints Les phases de backlog servent a d terminer les exigences sous forme de user stories pour le produit en g n ral puis plus pr cis ment pour le sprint qui suit La particularit de la m thode SCRUM est qu une fois le sprint commenc il n est pas interruptible L quipe de d veloppement travaille alors sans contact avec le client et s organise elle m me Les exigences restent donc inchang es durant chaque cycle et c est le ScrumMaster qui s assure du bon d roulement du d veloppement et que l quipe n est pas interrompue Au cours du sprint des r unions journali res les m l es servent faire le point sur l avancement A la fin de chaque sprint une d mo de ce qui a t produit est pr sent e et l quipe effectue une r trospective de ce qui a t fait et pas fait Ici encore la gestion du projet est une consid ration importante Celui c
354. plied Computing pp 510 514 Kavakli E 2002 Goal Oriented Requirements Engineering A Unifying Framework Requirements Engineering 6 4 pp 237 251 Kohlborn T et al 2009 Identification and Analysis of Business and Software Services A Consolidated Approach IEEE Transactions on Services Computing 2 1 pp 50 64 Kohlmann F amp Alt R 2007 Business driven service modeling a methodological approach from the finance industry In L Maciaszek amp W Abramovic eds Business Process and Services Computing BPSC 07 Leipzig Germany pp 180 193 Kroll P amp Kruchten P 2003 The rational unified process made easy a practitioner s guide to the RUP Addison Wesley Professional Kruchten P 2001 What Is the Rational Unified Process p 11 Kubicki S et al 2006 Assistance to building construction coordination towards a multi view cooperative platform Tcon Vol 11 11 December 2005 pp 565 586 Kubicki S 2006 Assister la coordination flexible de l activit de construction de b timents Une approche par les mod les pour la proposition d outils de visualisation du contexte de coop ration Universit Henri Poincar Nancy 2 Kubicki S Guerriero A Leclercq P et al 2009 Cooperative design studios in education Lessons learnt from two experiments In 13th Congress of Iberoamerican Society of Digital Graphics From Modern to Digital the Challenges of a Transition Brazil Kubicki S
355. pourrait se traduire par l ajout d un type de pi ce ou encore la modification des valeurs min et max de la temp rature Les approches de MDA peuvent prendre diff rentes formes Par exemple Kalnins et al 2010 utilise RSL Requirements Specification Language un sc nario dans un langage semi formel pour la sp cification des exigences pour un syst me informatique dont il d duit le mod le d analyse sous forme de diagrammes de classes UML et ce par analyse des mots cl s du sc nario Il constitue ainsi le CIM Le PIM est cr par l analyse r cursive de tout les cas d utilisation du sc nario et partir des donn es du mod le d analyse La Figure 41 illustre cette transformation Les approches r centes de MDA prennent en compte nombre d l ments du contexte relatifs l utilisateur sa localisation son mat riel etc pour g n rer des interfaces adapt es au contexte d utilisation En ce sens les premiers mod les ne sont pas r ellement ind pendants de la technologie Les contraintes et exigences mod lis es par le CIM sont en effet li es l usage de technologies ce qui implique que la g n ration du PIM soit d pendante de cet usage Chapitre 4 De l utilisateur la conception logicielle et d interfaces Geom ows sn te By Comme sance eit Customer clicks select link Customer selects cancel rejoins failure Customer selects cancel listElementSelection ali
356. pper un service d identification de d g ts travers un syst me de r alit mixte illustration Figure 69 Sept 1182007 Sori Ison S Sape J0th 2057 Sat Lihn Figure 69 Prototypage de l identification d un d g t travers un syst me de r alit mixte 1 20 2 La branche fonctionnelle La sp cification conceptuelle des besoins Les processus m tier et les acteurs qui y interviennent sont ici d taill s sous forme de diagrammes de s quences et d autres sc narios L intervention de sp cialistes en IHM permet de typer les interactions envisager pour l application partir des prescriptions g n r es lors de la phase pr c dente La sp cification organisationnelle et interactionnelle des besoins Cette phase d termine qui fera quoi et quand avec le syst me concevoir Le sp cialiste G nie Logicel GL identifie pour chaque utilisateur des cas d utilisation partir des descriptions pr c dentes des processus m tiers puis raffine les concepts m tiers en composants fonctionnels appel s objets m tiers La collaboration entre sp cialistes du GL et de l IHM se formalise ensuite par la transposition de ces objets m tiers en objet interactionnels Il s agit ici de d finir ce qui va repr senter un concept m tier dans l interface Cette tape inclut Dupuy Chessa 2011 des sc narios d interaction abstraits puis concrets en langage naturel des mod
357. pr cis Notez que le diagramme de cas d utilisation peut aussi tre utilis pour mod liser des buts on parle alors de business use case System Syst me de messagerie R lt lt ndude gt NN N 7 Envoi d un message KR Les deux acteurs ouvrent leur boite cela inclue la connexion La connexion par login mdp est une sp cialisation de la connexion A jr 7 L envoi du message est fait par l acteur 1 et destin l acteur 2 L acteur 2 lit le message Ce use case peut tre tendu par un envoi de notification effectu par le syst me vers l acteur 1 C tecture d un message Envoi d une notification Figure 22 Exemple de diagramme UML de cas d utilisation Acteur 2 r 12 4 r Un diagramme UML de s quences d composant chaque use case en montrant les changes de messages entre un acteur et le syst me ainsi que des indications en cas d it ration Le syst me est alors vu comme une boite noire sans d tail de ce qui le compose ae http www agilemodeling com artifacts sequenceDiagram htm Chapitre 4 De l utilisateur la conception logicielle et d interfaces Boite englobant une zone Pd d it ration loop Ce texte tablit les conditions de l it ration qui continue jusqu ce que les conditions soit remplies n Les items entre parenth ses sont les param tres
358. qu on mod lise des buts il faut pouvoir distinguer les buts strat giques haut niveau d abstraction relatifs aux objectifs du domaine ex assurer la prise en charge des patients et les buts op rationnels bas niveau d abstraction plus sp cifiques ex signaler la prise en charge du patient sur le tableau Il peut exister plusieurs niveaux de buts strat giques et op rationnels On dira qu un but contribue l atteinte du but qui lui est sup rieur voir figure 6 1 http www utdallas edu supakkul tools RE Tools 60 Chapitre 4 De l utilisateur a la conception logicielle et d interfaces les buts fonctionnels ce qu il faut faire et les buts non fonctionnels qui sont des qualit s suppl mentaires souhait es s curit co ts usabilit les buts g n ratifs atteindre cesser restrictifs maintenir viter et les softgoals qui sont relatifs des pr f rences et valu s de mani re qualitative et subjective contrairement aux deux autres types les relations entre les buts ET plusieurs buts contribuent l atteinte du but sup rieur ET complet plusieurs buts contribuent et suffisent l atteinte du but sup rieur OU le but inf rieur est une alternative au but sup rieur La figure suivante Figure 21 est un exemple de diagramme de buts fonctionnels dans le domaine du projet AIC Elle illustre un besoin courant mais crucial qui est d assurer la
359. quettage il s agit de repr senter graphiquement les fonctions pourvues par le syst me Le maquettage repr sente l interface un instant unique Un maquettage peut tre tr s pr cis avec des l ments graphiques particuliers un agencement d j pens une gestion de la navigation etc Il est un l ment important dans les m thodes de conception d IHM CCU CCA CDB car il supporte le dialogue entre utilisateurs et concepteurs en leur permettant de repr senter la future interface de mani re concr te par la composition d l ments graphiques les CIO Concrete Interaction Objects ex Figure 36 Buil IT Designer s view Sharing documents with related messages Name document Colaboratore browser Ty Select Al Calendar View Comment Figure 36 Exemple de maquettage outil Balsamiq Mockup Ici encore Constantine se d marque par sa volont d abstraction en proposant une m thode pour d crire de mani re graphique une maquette compos e d objets abstraits les Abstract Interaction Objects AIO Dans Constantine 2003 il d termine 12 familles de t ches interactives relatives l utilisateur ainsi que 11 l ments d interfaces des conteneurs et des interacteurs Figure 37 En composant ces taches et des l ments d interaction sous forme d l ments graphiques des composants abstraits canoniques il cherche a mod liser les interfaces travers des prototypes abstra
360. r dans un mur num rique pas d attributs Pynsdehashire dans un dessin Le diagramme de classes UML suivant Figure 98 repr sente la partie du m ta mod le d usage caract risant les objets d interaction Les relations repr sente entre l objet d interaction et chaque l ment du contexte coop ratif caract risent la fois la repr sentation de ces l ments en tant que donn es compl tes ou en en tant que donn es primitives Chapitre 10 La mod lisation des usages le point de vue op rationnel lt lt enumeration gt gt Type_donn e bool enne num rique date texte hypertexte fichier m dia objet BIM int ragit avec i Type_artefact num ration Type_acteur num ration Activit D nomination texte Type_ r le num ration Type_activit num ration Type_auteur lt type_rdle gt ne Type_statut num ration FDenomination tezte Figure 98 Caract risation de l objet d interaction 1 32 3 Le contexte d usage D finir le contexte dit contexte d usage n est autre que consid rer un acteur du projet en tant qu utilisateur d un outil particulier Il convient alors de les d finir tous deux ainsi que la temporalit et la localisation de l usage Figure 99 Les liens conceptuels cr s cet effet sont la relation repr sente entre l utilisateur et l acteur la relation utilise entre l
361. r et son utilisabilit relative la facilit la rapidit d utilisation ou encore le besoin d apprentissage r duit Paradigme Point de vue Le paradigme ou point de vue est la mani re de voir ou de consid rer quelque chose Il est relatif l interpr tation d un contenu et au rapport entre l acteur qui a ce point de vue et l objet de son tude Pratique collective et individuelle La pratique est l exercice d un m tier une mani re de travailler un comportement habituel avec une finalit Les pratiques dites collectives PC savoir relatives un objectif commun plusieurs personnes sont d compos es en pratiques individuelles PI ex cut es par chacune de ces personnes L ex cution de toutes les PI qui composent une PC doit permettre d atteindre l objectif de cette derni re Service et ser vice informatique Un service est une prestation qui met disposition d un client une capacit technique ou intellectuelle pour supporter un besoin En informatique un service est une fonctionnalit ou partie de fonctionnalit mise disposition par un composant logiciel pour assurer une t che particuli re Usage Le terme usage d finit une utilisation commune normale pr vue alors que l utilisation se rapporte plut t un point particulier une situation donn e Par extension l usage se r f re l appropriation Pour caract riser la m diatisation d une pratique
362. r Author Designer Status Over Status Over CRTI weB qe en a es upload multiple files in a group lt lt include gt gt Designer choose collaborators to inform lt lt include gt gt s ED pesign phase i The end of the design phase particularly called production phase i CP Documents exchange for design sharing Designer CP Family 5 Design and reporting The main designer of the project he leads the project Designers work together to produce project documents Job Architect IP oirtuse design documents for designers team Fa ades 2Ds sections are based on plans provided by designer CO Inform Need service support Already supported by a service Graphic designer Designers according to the tasks they have to perform Job Architect Plans of the project Author Designer Status Over Message type Notification notification of shared documents it can contain specific instructions Author Designer Status Over CRTI weB upload multiple files independantly lt lt include gt gt choose collaborators to inform lt lt include gt gt Figure 126 De la pratique a l usage variation des intentions d un utilisateur en fonction du besoin m tier Chapitre 12 La m thode PUSH exp rimentations et bilan 221 Chapitre 12 La m thode PUSH exp rimentations et bilan Une sp cificit du premier usage concerne le format des documents chang
363. r des quipes diff rentes Actuellement nous n avons pu soumettre l approche d autres experts m tiers ou concepteurs que ceux impliqu s dans le projet CRTI weB et les services parall les Le projet CRTI box a introduit un nouveau d veloppeur mais cela ne permet pas de valider l application de la m thode de mani re tendue On pourra remarquer galement que au contraire des approches d ing nierie des exigences classiques cette m thode ne prend pas en compte de mani re explicite les exigences non fonctionnelles Compar e aux m thodes de conception d IHM elle ne permet pas non plus d inclure des crit res d valuation ergonomique Perspectives Les champs de recherche couverts ouvrent des perspectives multiples ce travail notamment par rapport aux limites identifi es ci dessus Il a d j t voqu la n cessit d tendre l application de cette m thode de plus nombreux cas d tudes pour en valuer la pertinence la fois th orique et pratique Pour cela il sera indispensable d am liorer l dition des diff rents mod les par les acteurs concern s Plusieurs pistes sont suivre int grer les diteurs de mod les dans un seul outil qui permettra de les faire voluer de mani re homog ne sans avoir g rer de nombreuses applications automatisation des transformations de mod les notamment lorsque c est possible par la g n ration automatique des l ments d un mod
364. r exemple les clicks Le Contr leur synchronise la vue et le mod le en les mettant jour Typiquement il analyse les requ tes envoy es par l utilisateur depuis la vue ex afficher des donn es particuli res comme l emploi du temps d un jour particulier il demande au mod le appropri d ex cuter la requ te ex au mod le d emplois de temps de r cup rer celui du jour demand puis la vue de s actualiser avec les informations envoy es par le mod le a Chapitre 4 De l utilisateur la conception logicielle et d interfaces Contr leur Envoie la Commande requ te Renseigne Commande Interagit avec lt Mod le Renseigne Fournit Utilisateur l information S actualise afficher Ex cute la requ te Figure 26 Sch ma d une architecture logicielle repr sent e par le mod le MVC Le kit de d veloppement logiciel SDK pour software development kit est l ensemble des outils de d veloppement qui seront fournis au d veloppeur et permettront la cr ation du logiciel codage et compilation dans un environnement mat riel et logiciel sp cifique Les SDKs contiennent galement des notes techniques et autres documentations pour assister le d veloppeur Les activit s de test et le d ploiement Un cycle de d veloppement qu il soit global ou qu il fasse partie d un processus it ratif est valu travers l valuation de ses diff rentes phases
365. r la possibilit pour Tache modifier auteur d un 525 l administrateur voir l administrateur Non Contenu document Modification d information Pour r pondre aux questions r currentes Nouvel usage de 533 des utilisateurs il serait bien de cr er une Non consultation d une FAQ Informations utiles Renommer les zones permettant de g rer 534 la visibilit des documents dans CRTI weB 536 R diger les questions mettre dans la FAQ Non G n ral_ Nouvel usage de Informations utiles Il faudrait mettre l adresse mail de l administrateur projet et non plus 538 info crti web kitry lu dans le From Non NIL D tail fonctionnel 539 Ajouter Ic ne Modifier le propri taire Non NIL D tail graphique L ic ne Ajouter un planning global ou 540 semaine n est pas joli il faudrait en cr er Non D tail graphique T ches de sauvegarde 544 Sauvegarder un filtrage de documents Oui et r cup ration Fonctionnalit utile Il faut envoyer un mail l utilisateur et au T che syst me de 545 chef de projet lorsqu une personne est Oui notification Information mieux transmise PROMOBE Lors de la cr ation d un T che syst me de 546 utilisateur envoyer une copie de l email Oui notification Information mieux transmise Envoi d un mail au chef de projet lors du T che syst me de 547 d p t d un document Oui notification Information mieux transmise 548 mettre l metteur de notre choix lors de Non D tail fonctionnel 554 Cr ation d une page d accue
366. r lequel l activit de projet est instrument e par d autres activit s que sont les pratiques Cependant le concept de bonne pratique n est pas universel car il peut tre d pendant du contexte du projet c a d on admet qu une pratique dite bonne dans un projet pourra ne pas tre adapt e dans un autre Ce contexte est relatif a la nature du projet et un ensemble de contextes que sont le contexte g ographique culturel conomique social technologique autant de facteurs qui influenceront la mani re d appr hender le projet et donc ses pratiques Cela nous am ne op rer une distinction entre les pratiques g n riques que l on retrouve dans tous les projets AIC et les pratiques sp cifiques qui sont propre un contexte de projet particulier Nous distinguons galement les pratiques collectives effectu es a plusieurs des pratiques individuelles Les chapitres 5 et 9 illustrent notre acception et le positionnement de notre approche par rapport au concept de pratique Les processus de l information et du mat riel Bjork 1999 divisent le processus de construction d un batiment en deux sous processus relatifs au cheminement de l information et du mat riel dans un projet Un sous processus aussi appel activit est caract ris par des Inputs des Outputs des Ressources On retrouve en tant qu inputs et outputs les artefacts d finis pr c demment savoir les documents et les obje
367. r r D Domain Model Mapping Model FRCP Select Edit Create Select Edit Create Tooling Def Model Diagram Editor Gen Mode B Domain Gen Model Select Edit Reload Select Edit Create Select Edit Create Generate diagram editor 2b Sp cification de l apparence de la 4 G n ration de palette d outils l diteur lt 7 Mod le Qpesigner Man architect responsible of plans production Job Architect Coordinator EN Massaan Actors definition Actor Architect responsble of the coordinaton Job Architect ee of Actors Frans Activity definition Proen Figure 82 Processus de g n ration d un diteur de mod les avec GMF Chapitre 8 Introduction de la proposition Positionnement par rapport l architecture dirig e par les mod les Le cadre de notre tude ne couvre pas les d veloppements et d ploiements automatis s des services informatiques couverts par certaines approches de MDA architecture dirig e par les mod les Nous nous concentrons sur la sp cification de ces services et leur d veloppement dans le cadre d exp rimentations en collaboration avec des d veloppeurs Aussi nous prenons le parti de proposer des mod les contemplatifs et non productifs Favre 2004 Nous rappelons que les mod les contemplatifs sont utiles pour la communication et la compr hension mais ne sont pas utilis s pour la production du code qui res
368. ramme de s quences Figure 33 Diff rentes repr sentations graphiques pour la d composition d un use case Constantine nous met cependant en garde concernant l utilisation des diagrammes de s quences car elle introduit la consid ration pr matur e de la conception interne du syst me plut t Chapitre 4 De l utilisateur la conception logicielle et d interfaces que d encourager se concentrer sur la nature essentielle des t ches Nous retiendrons l importance de consid rer les tapes de la conception une une en utilisant des formalismes adapt s C est ce que fait par exemple G ransson et al 2003 en int grant la conception de Putilisabilit de anglais Usability Design dans les activit s du RUP avant les activit s d analyse et conception Il rel ve galement les limites du langage UML et plus particuli rement des use cases dans cette activit car ils portent l attention sur le syst me et sont de plus difficiles comprendre par les utilisateurs D autres mod lisations ont vu le jour ind pendamment des m thodes de conception logicielle mais visant plut t outiller celles ci a posteriori en caract risant les t ches IHM les arbres de t ches Les arbres de t ches La repr sentation travers des arbres hi rarchiques permet de d crire tous les niveaux d abstraction des t ches de la plus abstraite la plus pr cise Nous pr sentons ici deux mod
369. re research In Enterprise information systems IV Kluwer Academic Publishers pp 153 162 Chang Y Lim Y amp Stolterman E 2008 Personas from theory to practices In Proceedings of the 5th Nordic conference pp 439 442 Chen G 2009 Architectural Practice Smplified A Survival Guide and Checklists for Building Construction and Site Improvements as Well as Tips on Architecture Building Design Construction and Project Management Denver Colorado Outskirts Press Cherbakov L et al 2005 Impact of service orientation at the business level IBM Systens Journal 44 4 pp 653 668 Clot Y 2007 De l analyse des pratiques au d veloppement des m tiers Education et didactique 1 1 Cockburn A 2000 Writing Effective Use Cases Addison Wesley Professional Cockburn A amp Jones S 1995 Four principles of groupware design Interacting with Computers 7 2 pp 195 210 Cohn M 2003 User stories applied For agile software development Bibliographie Constantine L 2001 Structure and style in use cases for user interface design In Object Modeling and User Interface Design Designing Interactive Systens Addison Wesley Professional Constantine L 2002 Process Agility and Software Usability Toward Lightweight Usage Centered Design Development 1 June 2001 pp 1 10 Constantine L 2006 Users Roles and Personas In The Persona Lifecycle Morgan Kaufmann Constantine L amp Lockwo
370. re adopt e par tout le monde Les tudiants sont l inverse r fractaires ce syst me vis vis du temps suppl mentaire pass nommer chaque document ils ne per oivent pas de plus value car le petit nombre de documents partag s ne requiert pas une telle structuration Il en va de m me pour le service zones Les notifications par mail permettent d viter la consultation syst matique de la plateforme pour surveiller les partages mais peuvent vite devenir probl matiques en cas de nombreux partages surcharge de la bo te mail particuli rement donc en milieu professionnel Cela soul ve la question de les regrouper dans des mails r sum intervalles r guliers Les r actions sur documents sont parfois d tourn es pour simplement stipuler que le document a t consult ou pour faire r f rence a un autre document cf besoin de lier les documents entre eux Les validations sont parfois faites informellement en r union au t l phone et non trac es sur la plateforme Chez les tudiants le caract re non hi rarchique du projet ne pousse pas a la demande de validations au profit de la recherche de conseils et d avis partag s Se pose aussi la question de la visibilit des r actions vis a vis de tous les utilisateurs Ces l ments peuvent tre interpr t s comme des contre exemples t moignant des lacunes de l outil dans l adaptation de outil 1 5 3 Analyse du d veloppe
371. re du batiment In Ramau 5 La qualit architecturale Acteurs et enjeux pp 127 142 Bispo C P et al 2010 Applying a model driven process for a collaborative service oriented architecture The 2010 14th International Conference on Computer Supported Cooperative Work in Design pp 378 383 Bjekovic M amp Kubicki S 2011 Service quality description a business perspective In 2071 Federated Conference on Computer Science and Information Systems pp 513 520 Bj rk B C 2002 A formalised model of the information and materials handling activities in the construction process Construction Innovation Information Process Management 2 3 pp 133 149 Bjork B C 1999 Information Technology in Construction domain definition and research issues International Journal of Computer Integrated Design And Construction 1 1 pp 3 16 Bobroff J et al 1993 Les formes d organisation des projets In Ecosip Pilotages de projet et entreprises diversit et convergences Paris France pp 35 39 Bodart F amp Vanderdonckt J 1996 Widget standardisation through abstract interaction objects In In Advances in Applied Ergonomics USA publishing pp 300 305 Boehm B 1988 A spiral model of software development and enhancement Computer 21 5 pp 61 72 Booch G et al 2007 Object Oriented Analysis amp Design with Application Addison Wesley Professional Bibliographie Booth P A 1989 An Introducti
372. re les mod les propos s Cette tape n est autre que la fin du processus de conception de services alors qu travers l usage on per oit l outil comme une boite noire en d crivant abstraitement les t ches de l outil en r ponse aux t ches de l utilisateur la description des services propos s d taille la solution telle qu elle devra tre impl ment e Tel que nous l avons introduit plusieurs usages alternatifs peuvent correspondre une m me pratique La prise en compte de cette variation dans les usages nous permet de r percuter cette diversit dans les services propos s pour convenir ainsi une majorit des utilisateurs finaux Atteindre ce niveau de d tail est n cessaire pour les d veloppeurs En effet cela permet de percevoir toutes les limites qu il faudra surmonter pour d velopper la solution ce qui pourra faire varier la conception de celui ci Le dialogue et la compr hension entre concepteurs et d veloppeurs sont la cl de cette troisi me tape Chapitre 10 La mod lisation des usages le point de vue op rationnel Chapitre 11 La mod lisation des services le point de vue fonctionnel Le point de vue fonctionnel porte sur la description des services qui mat rialisent les usages d finis pr c demment Ce chapitre d finit le concept de service tel qu utilis dans notre m thode et le caract rise par un m ta mod le de service MMS qui est mis en correspondance av
373. re recherche s est bas e sur des allers retours entre th orie et cas concrets qui sont justifi s par les contextes d tudes pr sent s au cours des deux premiers chapitres En effet ce travail poss de un caract re appliqu gr ce au contexte de d veloppement de CRTI weB et son transfert il appartient un contexte scientifique particulier entre le monde acad mique savoir les th matiques du CRAT et les projets d innovation enjeux du CRP Henri Tudor partir d une tude sur les diff rentes approches de mod lisation d un processus de conception Laaroussi 2007 d crit un processus g n rique qui en tant que processus cognitif de r solution de probl mes s articule autour de trois activit s primitives l analyse du probl me la proposition d une solution et l valuation de cette solution Nous nous sommes tourn s vers les th ories de la science de la conception pour comprendre la nature de ce processus 1 8 1 La science dela conception On d finit la science de la conception comme science de l artificiel Simon 2004 ou science de la pratique Gregor 2009 Elle traite de la cr ation d objets et de savoirs par l Homme pour atteindre certains buts ex l ing nierie l architecture contrairement aux sciences comportementales Hevner et al 2004 savoir les sciences naturelles ex la physique la chimie et humaines ex l histoire la linguistique
374. re taches type_relation num ration ET 0U PUIS ees type_relation Interaction Perception lt lt enumeration gt gt lt lt enumeration gt gt type_tache interaction type_tache perception criture graphique s lection audio d clenchement selection manipulation navigation transfomation conteneur d filement autre mat rielle Figure 97 Caract risation des intentions et des taches 1 32 2 Le contenu d interaction Le contenu d interaction est compos d objets d interaction OI qui repr sentent les l ments du contexte coop ratif manipul s au cours d une pratique et m diatis s par un usage Ce sont les l ments avec lesquels l utilisateur devra interagir lors de l ex cution d une t che Un OI est la combinaison d une donn e et d une repr sentation Il a un niveau de description abstrait mais devra contenir assez d information pour en faire un objet concret lors du d veloppement du syst me partir de la litt rature dans le domaine des IHM nous nous sommes inspir s des objets d interaction de la m thode Symphony S Dupuy Chessa 2011 mais aussi du concept d objet d interaction abstrait d crit dans JM Vanderdonckt amp F Bodart 1993 ou illustr dans LL Constantine 2003 voir 1 10 3 Afin de pouvoir d finir des objets d interaction pertinents par rapport au domaine AIC nous avons galeme
375. re une partie de l ex cution du service et galement un cas d erreur Le service web de nommage existant sur la plateforme CRTI weB a d tre modifi pour r pondre l exigence de nommage automatique selon la convention Initiales Chapitre 12 La m thode PUSH exp rimentations et bilan Auteur _ 8 premi res lettres du nom du fichier _ version Le contenu de la base de donn es CRTI web n a pas chang Au cours de cette exp rimentation nous avons confi l dition des diagrammes de s quence au d veloppeur afin d valuer leur utilit rendre compte des choix de d veloppement aupr s des concepteurs et les capitaliser pour les futurs d veloppeurs La figure suivante en repr sente un extrait Figure 134 lt lt Tool gt gt name CRTI weB lt lt Business service gt gt name documents management Descrption the documents management service of the crti web tool is dedicated to files sharing and traceability in an AEC project lt lt Service ICT gt gt Automatic upload service J lt lt Client gt gt Designer lt lt abstract task enter login folder project Ti i project number lt lt Input gt gt 1 enterldeftificationData ID password Folder et web url project number lt lt action gt gt 2 TspecifyChecked Folder folder A lt lt actijn gt gt 3 rues erfcaten D pasn rd crti web URL Etes lt lt action gt gt 4 ne
376. ression Attribution d une fonctionnalit 449 cr s uniquement par l administrateur i gestion men es par un d organisme limit un un type d utilisateur PROMOBE L administrateur projet doit Plusieurs pratiques de Contexte Ajout et import Attribution d une fonctionnalit 450 pouvoir ajouter des utilisateurs et gestion men es par un lee limit jun type d utilisateur 451 cr s uniquement par l administrateur gestion men es par un T che d utilisateurs limit un type d utilisateur PROMOBE Possibilit d diter les Plusieurs pratiques de Contexte Edition d utilisateurs Attribution d une fonctionnalit 452 informations des utilisateurs cr s i gestion men es par un a limit un utilisateur jun type d utilisateur PROMOBE L administrateur d un projet Plusieurs pratiques de Contexte Modifications des zones Attribution d une fonctionnalit 453 doit pouvoir modifier les zones d un projet i gestion men es par un a limit un utilisateur un type d utilisateur PROMOBE L administrateur projet doit Plusieurs pratiques de Contexte Renvoi de mot de passe Attribution d une fonctionnalit 454 pouvoir renvoyer un mot de passe i gestion men es par un a limit un utilisateur jun type d utilisateur Figure 145 Grille d analyse des tickets partie 3 4 PET Annexes PROMOBE Possibilit pour Plusieurs pratiques de Contexte Acc s tous les Attribution d une foncti
377. rne c d l int gration dans l environnement technologique actuel de l utilisateur 1 17 3 Loose coupling et conception de services collaboratifs Le terme loose coupling litt ralement couplage l che ou faible est utilis pour d crire la relation entre des personnes ou groupes de personnes dans laquelle les v nements de chacun sont coupl s et r actifs c d aux actions des autres mais pr servent leur propre identit et leur propre contexte Pinelle amp Gutwin 2005 On distingue le loose coupling dans lequel les besoins de communication sont r duits et les personnes ont seulement besoin d tre au courant de l activit d autrui du tight coupling couplage rigide ou fort caract ris par une communication une d pendance et une interaction fortes entre personnes et ou groupes Olson 1996 Grinter et al 1999 Le concept de loose coupling s applique particuli rement aux organisations compos es d quipes multidisciplinaires dans lesquelles chaque acteur poss de une certaine autonomie sa propre expertise et les pratiques qui lui sont li es comme c est le cas pour les quipes de projet AIC Pinelle amp Gutwin 2005 pr sente une suite d approches de conception de collecticiel supportant un travail collaboratif bas sur ce concept de loose coopling Tableau 9 Ces approches sont g n rales s appliquant au d veloppement de tous types de services
378. rocessus sous la forme d Information Delivery Manuals en reste aujourd hui ses d buts et les chercheurs reconnaissent une certaine lourdeur de ces mod les et une difficult d finir des processus reproductibles Notre proposition pourrait donc certainement apporter un nouveau point de vue ces travaux Nous avons envisag l applicabilit de cette m thode un autre secteur que celui du projet AIC En effet d autres contextes de projet de conception collaborative pourraient tre analys s gr ce aux outils propos s afin de concevoir des services adapt s leurs pratiques comme par exemple les pratiques d ing nierie civile ou encore de conception automobile Cependant il sera n cessaire d valuer dans quelle mesure les m ta mod les et formalismes devront voluer afin de permettre la description de ces contextes diff rents Leur structure est g n rique on pourra ainsi r utiliser les concepts introduits acteurs artafects outils Cependant il faudra adapter l instanciation de ces concepts en fonction du domaine analys notamment travers les types num r s type d acteur type de document type d outil Conclusion et perspectives Table des mati res PARTIE 1 ASSISTER LA COLLABORATION DANS LES PROJETS DE CONSTRUCTION DEFINITION D UNE PROBLEMATIQUE ET RECUL 1 2 1 3 Table des mati res Table des mati res PARTIE 3 GUIDER LA CONCEPTION DE SERVI
379. rquer la justesse des mod les pourra voluer au fil des analyses travers l am lioration du m ta mod le Pourtant il est important de pouvoir faire des analyses pertinentes m me si la maturit des mod les ne le permet encore pas C est pourquoi comme nous l avons introduit dans le paragraphe pr sentant le cahier d exigences 1 25 2 celui ci comprend des champs d dition libre qui permettent de pallier les manques du m ta mod le De mani re g n rale les champs libres du cahier d exigences seront un support d expression pour les acteurs du projet de d veloppement quelque soit leur point de vue Nous partons du postulat que toute id e ou remarque au cours du processus peut avoir un impact sur la pertinence du r sultat savoir l adaptation du service d velopper Le cahier d exigence supporte ainsi la formalisation de ces remarques et assure leur capitalisation et leur prise en compte par les diff rents participants potentiellement concern s La repr sentation du mod le et de ces informations additionnelles prend la forme d un tableau Figure 94 Chapitre 9 La mod lisation des pratiques le point de vue organisationnel PRACTICES DIAGRAM Insert here the diagram illustrating the business practices CP Validation des choix conceptuels Famiy 5 Design and reporting Les concepteurs dffusent leur proposition aupr s des maitres d ouvrage qu l vaiuent Is composed of
380. rticuli rement la mod lisation des processus m tiers qui est la cl des m thodes orient es services Les processus m tiers sont consid r s comme des blocks r utilisables ind pendants de l application et de la plateforme qui la supporte Papazoglou amp Van Den Heuvel 2006 Un processus peut tre d crit travers quatre perspectives Curtis 1992 la perspective fonctionnelle qui d crit les r gles m tier la perspective comportementale qui d crit le s quen age des activit s la perspective organisationnelle qui d crit les acteurs la perspective informationnelle qui d crit les l ments d information List 2006 ou encore Aguilar Sav n 2004 d crivent et valuent plusieurs langages de mod lisation des processus m tiers BPMLs Les plus largement r pandus sont les diagrammes d activit s UML BPMN et IDEF3 Les diagrammes d activit UML AD UML et les diagrammes BPMN Business Process Modelling notation sont souvent compar s et confront s dans la litt rature White 2004 Eloranta amp Kallio 2006 Peixoto et al 2008 BPMN et AD sont deux vues ou instances du m me m ta model le BPDM Business Process Definition Metamodel Ces diagrammes repr sentent dans des swimlanes les activit s de diff rents acteurs sous forme d v nements d tats et de donn es manipul es Ces deux formalismes sont tr s similaires malgr que le diagramme Se Chapitre 5 De l en
381. rvice decomposition In Proceedings of First International Conference on Exploring Services Sciences IESS 1 0 Geneva Switzerland Springer pp 96 110 MacKenzie C M et al 2006 Reference Model for Service Oriented Architecture 1 0 Architecture 2006 October pp 1 31 Maglio P P amp Spohrer J 2007 Fundamentals of service science Journal of the Academy of Marketing Science 36 1 pp 18 20 Bibliographie Malone T W amp Crowston K 1994 The interdisciplinary study of coordination ACM Computing Surveys 26 1 pp 87 119 March S 1995 Design and natural science research on information technology Decision support systems Marjanovic O et al 2007 Collaborative practice oriented business processes Creating a new case for business process management and CSCW synergy 2007 International Conference on Collaborative Computing Networking Applications and Worksharing CollaborateCom 2007 pp 448 455 Martin R C 2003 Agile Software Development Principles Patterns and Practices Prentice Hall PTR Masserey G amp Samaan K 2006 Impl mentation du mod le AMF In JHM 06 Proceedings of the 18th International Conferenceof the Association Francophone d Interaction Homme Machine Mintzberg H 1989 Le management voyage au centre des organisations Paris Lavoisier Misra S amp Kumar V 2005 Goal oriented or scenario based requirements engineering technique what should a practit
382. rvices informatiques ICT Services informatiques de Technologies de l Information et de la Communication Nous avions d j voqu cette distinction au chapitre 2 lors de la description de outil CRTI weB En effet celui ci propose deux services dits m tiers que sont le service documents et le Chapitre 11 La mod lisation des services le point de vue fonctionnel service comptes rendus d compos s en services informatiques ICT comme la r daction la g n ration d un pdf la consultation cf 1 4 3 Le terme service m tier est ici emprunt au domaine de l entreprise et r interpr t il n est plus chang entre deux parties op rantes d une entreprise mais il est offert par un outil pour r pondre un besoin m tier L utilisation du terme service informatique respecte quant lui le sens qu on a pu lui associer notamment dans Kohlborn et al 2009 c est une fonctionnalit logicielle qui supporte l ex cution d un service m tier Nous garderons ces deux d finitions l esprit pour caract riser le point de vue fonctionnel troisi me et derni re tape de la m thode PUSH pour la proposition de services adapt s 1 35 2 Caract risation des services En respectant le vocabulaire utilis dans le domaine de l entreprise orient e services nous caract risons un service par un nom une description un client et un fournisseur La description d un service compre
383. s type_groupe texte constructeur conomiste conseiller expert administration autre Message Acteur simple Groupe d acteurs lt lt enumeration gt gt lt lt enumeration gt gt Tyne pe rene Type_acteur Groupe lt lt enumeration gt gt lt lt enumeration gt gt architecte agence bureau d tudes Type_artefact Document Type_artefact Objet lt lt enumeration gt gt urbaniste je T peaa Type_artefact Message aia entreprise g om tral site o rls laboratoire mod le lot information ing nieur s curit organisation publique perspective b tinent registre aoe Monnens autre photo niveau notification ma on TT compte rendufrapport pi ce r action lectricien xigences ouvrage validation comptable specifications r servation secr taire calendrier planning mat riau autre agenda chantillon ToDo d faut l iie engin EE Figure 87 M ta Mod le de la pratique collective MMPC concepts principaux fond bleu sp cifications contours bleus num rations contours verts Enfin nous distinguons trois artefacts pouvant tre typ s type artefact document objet message et caract ris s par leur auteur et leur statut Les documents sont les produits physiques ou num riques des t ches de conception et de coordination voir Les type artefact document identifi s sont
384. s formations reconnues Il pourra galement fournir des garanties suppl mentaires quant la qualit et la fiabilit de l entreprise au travers par exemple de la qualit des prestations ant rieures ou des recommandations d autres professionnels Tableau 17 l ments de caract risation de la PC6 Acteurs impliqu s Documents utilis s Activit s Maitre d ceuvre Plans divers Tache de coordination Entreprises Documents administratifs Phase conception a partir de Maitre d ouvrage et Pi ces financi res la realisation de plans assistants communicables PC7 valuation de la conception et compte rendu Description lors des derni res phases de la conception il est n cessaire d en valuer certains crit res comme ceux relatifs la sant la s curit l hygi ne l accessibilit et des sp cialistes de chaque domaine sont impliqu s pour mener leur valuation Dans des cas particuliers dont les projets d architecture environnementale ou durable les experts valuent galement les performances nerg tiques acoustiques ou lumineuses de l ouvrage En fonction de la nature du projet et des objectifs fix s au d but de son cycle de vie les r sultats de ces valuations conditionnent les choix d finitifs ainsi que l ex cution du projet Chapitre 9 La mod lisation des pratiques le point de vue organisationnel Tableau 18 El ments de caract risation de la PC7 Documents utili
385. s s Activit s Acteurs impliqu s T ches d valuation et de coordination Plans d ex cution Mod les 3D Documents techniques Ma tre d uvre Experts Phase conception avant Maitre d ouvrage et k ex cution assistants Rapports d expertises PCS8 organisation de r unions et compte rendu Description pendant le montage et la conception un certain nombre de rencontres sont organis es entre le maitre d ouvrage le maitre d ceuvre mais aussi les experts le personnel administratif les lus La personne qui tient le r le de coordinateur organise ces r unions et formalise un rapport qui contiendra tous les l ments importants voqu s ordre du jour objectifs avancement depuis la derni re r union d cisions Lors du chantier et de sa pr paration le coordinateur doit organiser en concertation avec les entreprises un ensemble de r unions de coordination technique Le responsable est celui qui est d fini comme animateur de la r union On devra toujours y trouver une des personnes suivantes le ma tre d uvre le coordinateur d sign pour cette mission l entrepreneur titulaire d un march unique le mandataire ou entrepreneur g n ral Avant une r union de chantier il est souhaitable que le MOE ventuellement en compagnie du coordinateur effectue une visite de chantier m me rapide afin de visualiser l avancement du chantier de noter les travaux d fectueux ou
386. se et la description de ces pratiques Ce travail met en avant les objectifs g n riques et les sp cificit s d un contexte de projet et ses variations Proposer des ser vices informatiques pour le secteur AIC Comme le montre le sch ma suivant Taea ce travail porte essentiellement sur l expression des besoins ou exigences l origine d un projet de conception de services partir de la description d un projet de conception architecturale En d autres termes nous proposons une approche qui int gre l analyse des pratiques m tiers dans le contexte AIC une m thode de conception de services adapt s Le concept d usage m diatisant ces pratiques et mat rialis par les services est au centre de cette approche Cette m thode suit donc un processus en plusieurs tapes analytiques et conceptuelles Ces tapes sont d crites par divers mod les qui formalisent l expression de points de vue diff rents relatifs aux diff rents intervenants dans un projet de d veloppement de services l utilisateur l expert m tier le concepteur le d veloppeur Le passage d un mod le l autre d finit l volution d un point de vue vers un autre jusqu la d finition du service demand Cette volution est d finie par un m ta mod le qui conceptualise les points de vue et les correspondances entre chacun d entre eux Le plan de cette th se d coule des probl matiques ici mises en avant Projet de concepti
387. ser ces concepts et les formalismes utilis s pour les d crire sont issus des domaines du G nie Logiciel et de la conception d IHM Nous verrons comment nous adaptons ces formalismes pour lier la description d un usage celle de la pratique qu il m diatise 1 31 D finition et concepts 1 31 1 Usage et utilisation Au travers du point de vue op rationnel on cherchera exprimer la mani re dont est m diatis e une pratique m tier par l introduction d un outil num rique M diatiser signifie litt ralement avoir une fonction d interm diaire Nous d finirons dans quelle mesure l outil assure cette fonction d interm diaire travers le concept d usage Les termes usage et utilisation sont deux synonymes qui peuvent tous deux signifier l emploi de quelque chose On conf re cependant l usage plus d acceptions Il est par exemple relatif une habitude ex l usage du chapeau ou des r gles tablies ex il est d usage de mettre une cravate ici Ainsi le terme usage d finit une utilisation commune normale pr vue alors que l utilisation se rapporte plut t un point particulier une situation donn e Par exemple on dit que l usage d une chaine hifi est de lire de la musique mais que l utilisation de celle ci en ext rieur n est pas recommand e Par extension l usage se r f re l appropriation on peut par exemple 3 http french stackexchange com questions 7
388. sister la collaboration dans les projets de construction D finition d une probl matique et recul th orique Dans cette premi re partie notre tude sera resitu e dans son double contexte entre enjeux m tiers et d marche scientifique Le chapitre 1 introduira le contexte m tier savoir le domaine Architecture Ing nierie et Construction AIC ses caract ristiques et les l ments qui le composent Puis il approfondira plus particuli rement la th matique du Travail Collaboratif Assist par Ordinateur TCAO dans ce contexte particulier Le chapitre 2 d crira une exp rience de conception de services d un outil de TCAO particulier Il nous permettra de tirer quelques conclusions quant la nature et aux enjeux d un tel travail de conception de services partir de ces analyses nous d finirons nos objectifs et notre probl matique au cours du chapitre 3 Un premier recul th orique sur la science de la conception conclura ce chapitre et servira de point de d part l tat de l art propos dans la deuxi me partie de cette th se Chapitre 1 La coordination dans les projets de conception construction architecturale Ce premier chapitre fait le point sur les tudes men es autour de la coordination dans les projets de conception construction architecturale aussi appel s projets AIC pour Architecture Ing nierie et Construction Il aborde un point de vue d abord th orique visant caract ris
389. solution nouvelles fonctionnalit s changement de interface Chapitre 4 De l utilisateur la conception logicielle et d interfaces 1 9 4 Les m thodes agiles Au del des activit s identifi es l activit de gestion du projet occupe une place tr s importante Comme dans tout travail collaboratif il est crucial de 1 pouvoir coordonner et superviser les t ches de chacun et 2 assurer la communication et le transfert d informations entre les diff rents acteurs de l quipe et tous les stades du d veloppement la fin du 20 si cle nombre de chercheurs estim rent que les cycles de d veloppement traditionnel ne r pondaient pas ces besoins et propos rent leurs propres m thodes visant am liorer le d veloppement logiciel Afin de les unifier ils instaur rent les principes fondamentaux d un d veloppement adapt des logiciels le d veloppement agile Les principes Le manifeste pour le d veloppement agile de logiciels Greer amp Hamon 2011 Martin 2003 r dig en 2001 d finit 12 principes d clin s des quatre valeurs fondamentales suivantes voir aussi Figure 27 la priorit des individus et des interactions sur les proc dures et les outils en encourageant l auto organisation et la motivation la priorit aux logiciels op rationnels qui seront plus utiles aux clients pour valuer le travail en cours et donc mieux accueillis que des documentations exhaustives
390. specification Delgado A 2010 Tool support for Service Oriented development from Business Processes In 2nd International Workshop on Model Driven Service Engineering MOSE 10 Delotte O 2006 CoCSys une approche bas e sur la construction d un mod le comportemental pour la conception de syst mes collaboratifs mobiles Ecole Centrale de Lyon Dewan P 2001 An integrated approach to designing and evaluating collaborative applications and infrastructures In Computer Supported Cooperative Work CSCW Kluwer Academic Publishers pp 75 111 Dey A 2001 Understanding and using context Bibliographie Dibbern J et al 2009 Design implementation and evaluation of an ICT supported collaboration methodology for distributed requirements determination Dubois E Gray P amp Nigay L 2002 ASUR a Design Notation for Mobile Mixed Systems In Proceedings of the 4th International Symposium on Mobile Human Computer Interaction Springer Verlag London UK pp 123 139 Dupuy Chessa S 2011 Mod lisation en Interaction Homme Machine et en Syst me d Information A la crois e des chemins Laboratoire d Informatique de Grenoble Dupuy Chessa S et al 2010 A software engineering method for the design of mixed reality systems In The Engineering Of Mixed Reality Systems Springer London pp 313 334 Eastman C amp Sacks R 2010 Introducing a new methodology to develop the information delivery man
391. ssus vari s et souvent informels Processus syst matiques et enti rement sp cifi s volution travers la r solution volution travers l ing nierie d erreurs Ici encore notre objectif n est pas de d crire les m thodes pour ce qu elles sont mais plut t de comprendre les concepts qui caract risent la conception Nous pr f rerons parler plus g n ralement de la m thodologie de la conception enrichie en la d finissant au travers de ses m thodes Nous adoptons la d finition de Abras amp Maloney Krichmar 2004 qu il propose originellement pour la conception centr e utilisateur un ensemble de processus dans lesquels les utilisateurs finaux influencent d une fa on ou d une autre la mise en forme de la conception Ainsi selon Norman 1986 l utilisateur d une interface adapt e devra savoir ce qu il doit faire en fonction de ce qu il veut faire ex si il veut retourner l accueil d un site si il veut valider et payer sa commande Cela implique que les fonctionnalit s soient visibles et compr hensibles on parlera alors d affordance Maier 2009 Le concepteur pourra galement utiliser les contraintes pour limiter les choix de l utilisateur et le guider vers la solution Savoir ce qu il se passe et ce qu il va se passer ex le fichier est en cours de t l chargement ou si je clique sur annuler la transaction s arr tera Il est
392. st ReservedTimeSlotsForm Facility Reservation Select ReservableTimeSlotlist date Date select day String fromDT Date isReserved boolean toDT Date usage int etom FacilityReservation Reserved i Select TimeSia Pl M i g gt y l l click Select link 1 selectT imeSlotFomReserableTimeSlotLis t imeSiot servadielimeSiotLa rvsbleTimeSlotist Remove timeSlot 1 ity Feolty bieFsclittit Lat lt Feolty gt poren eke Lis lt TimeSio ume g ect timeSiot TimeSiat ecc9eptReservatonSummeary vod confirmReservedTimeSiotlia void invoie_chengeDimisyCntene void reservations void selec scltyFromRemrvadieF sciityUs Faolity void _slectT imeSictFromRemrvetieTimeSotUm T meSiot void G n ration du PIM Figure 41 Les mod les et leur transformation dans l approche MDA de Kalnins et al 2010 Chapitre 4 De l utilisateur la conception logicielle et d interfaces 1 12 Conclusion vers une m thode centr e usages Les th ories et m thodes de la conception appliqu es au d veloppement logiciel se sont formalis es au cours de la deuxi me moiti du si cle dernier Aux vues des analyses men es dans ce premier chapitre de la partie 2 le mot cl qui ressort de l volution de la conception logicielle est conceptualisation Comme l illustre le sch ma suivant Figure 42 la premi re tape fut de conceptualiser le code lui m me
393. stereotype gt gt lt lt stereotype gt gt Relation Activit Artelact lt lt stereotype gt gt Relation Acteur Acteur le Sa cstareatype gt gt Relation Outit Outit Element _ 7 Relation Artefact Activite Ai Element t lt lt stereotype gt gt Element lt lt stereotype gt gt Acteur 7 Outil Element e gt Element l l Relation Outil Acteur gt l Coenen __Jrreotype gt gt I lt stereotype lt lt itereorype gt gt Ralation Acteur Outil lt lt stereotypey gt lt lt stereotype gt GroupeActeurs ActeurUnique Element GroupeOurlls OutilUnique Element Element Element Element j lt lt stereotype gt gt lt lt stereotype gt gt Relation Artefact Artefact lt lt stereotype gt gt Relation Acteur Artefact Element Relation Outil Artefact Testereotype gt gt e lt stereotype gt gt Elen stereotype gt gt Relation Artefact Acteur Artefact Relation Artefact Outil Element Element Element lt lt stereotype gt gt stereotype Document Objet Element Element stereotype gt stereotype GroupeDocuments DocumentUnique Element Element L gende Classe primaire Classe secondaire Relation Figure 3 Extrait du m ta mode le du contexte de l activit collective issu de Guerriero 2009 Chapitre 1 La coordination dans les projets de conception construction architecturale Cependant ces relations ne so
394. t les pi ces cellier ou salon et les t ches ex cuter choisir g rer le PIM par le processus d utilisation suivre d riv des concepts choisir pi ce puis r gler temp rature le PSM par l interface sous forme de conteneurs et d int racteurs li s aux actions du processus I s agit ici d une fen tre contenant une liste de s lection de pi ces pour choisir pi ce une liste de s lection de valeurs num riques pour r gler temp rature et un conteneur affichant l unit de temp rature utilis e L ISM savoir le code n est pas dit il est g n r automatiquement OpUnaire Enchainement S tecsonner pen ConceptContenu Gorer temperature PER e N EA ecto Espaceinteracteur Nevosson j Selection x ae ES or Selectionner ES alure Espaceinteracteur opece pi ce j Fenetreframe FE Mozilla DBR b Selon 24 C Figure 40 Illustration des transformations entre mod les dans le cas d tude de Sottet et al 2005 8a Chapitre 4 De l utilisateur la conception logicielle et d interfaces L automatisation des transformations entre les concepts de chaque tape permet de g n rer rapidement une solution op rationnelle De plus tout changement des concepts du CIM induit une potentielle adaptation de la solution g n r e Dans l exemple de Sottet et al 2005 que nous venons de d crire cela
395. t elle des habituels diagrammes de processus comme BPMN Instanci s partir d un m ta mod le de pratiques construit sur la base d une tude du contexte d un projet AIC ils permettent cependant une description la fois sp cifique et pertinente du m tier La description textuelle qui compl te les mod les dans le cahier d exigences permet quant elle de d tailler certains l ments sur lesquels il sera important de s attarder Les l ments d crire sont pr cis s et format s dans des tableaux Leur dition est guid e par choix multiple ou totalement libre Les choix multiples doivent permettre de couvrir tous les cas de figure ou d faut d tre compl t s si besoin L dition libre pr sente l int r t de pouvoir s exprimer librement sans contrainte Il peut n anmoins tre difficile dans certains cas de savoir quoi r pondre Vis vis des exp rimentations men es nous pensons qu un mod le pertinent n est pas forc ment un mod le complet dans lequel on aura utilis et d fini tout les concepts mais un mod le concis qui reprendra l information strictement n cessaire la conception du service final R sum des r ponses des exp rimentations Le d but de ce chapitre cf 1 39 3J Tableau 24 voquait nos attentes en termes de validation vis vis des exp rimentations Nous pouvons pr sent conclure sur les apports r els de ces exp rimentations Tableau 2
396. t s du service Les outils d dition de mod les UML comme StarUML Chapitre 11 La mod lisation des services le point de vue fonctionnel permettent cette expression de commentaires sous forme de notes qui peuvent tre associ es des l ments du diagramme Files size must not exceed 70Mo S Figure 118 Exemple de note ajout e a un Input dans un diagramme de s quences mod lisant un service Dans certains cas si par exemple le concepteur n avait pas r ellement conscience des limites techniques de l outil il se peut que le sc nario d usage ne puisse pas tre mat rialis tel qu il a t con u La mod lisation d un service alternatif permettra de supporter le dialogue entre les d veloppeurs et les concepteurs qui devront terme repenser leur usage Lors des modifications qu elles soient relatives aux mod les de services ou aux mod les d usage la cr ation d une nouvelle version mise jour du cahier d exigences permettra de formaliser les d cisions prises afin de pouvoir s y r f rer et de garder une trace de l volution du projet et ainsi justifier posteriori les changements entrepris 1 37 3 D veloppements Le processus li l impl mentation des services sp cifi s ne fait pas l objet de cette tude l objectif de la m thode propos e tant de formaliser des exigences qui serviront de base aux d veloppements Le suivi et l
397. t alors de pouvoir d finir les exigences d change en identifiant les objets d change E O et les mod les d change E M qu ils constituent Les E O voluent en fonction du mod le auquel ils appartiennent Par exemple un poteau pourra tre un simple volume g om trique dans un mod le conceptuel ou tre plus finement d crit lors des phases ult rieures Eastman amp Jeong 2010 Ces objets sont soumis des r gles m tiers comme par exemple des dimensions r glementaires L impl mentation La cr ation de PIDM autour de la mod lisation des processus et des objets d change permet de formaliser les besoins des professionnels tels qu ils les communiquent C est une mod lisation ind pendante du format utilis car les professionnels n ont g n ralement pas les comp tences n cessaires pour d finir cela En revanche la correspondance de l ensemble d informations avec une structure de donn es est la responsabilit du d veloppeur du syst me Berard amp Karlshoej 2012 Comme le montre le sch ma suivant Figure 75 il s agit d appliquer le sch ma IFC et sa documentation IFC model specification aux exigences d change pour impl menter une solution Les Model View Definitions MVD qui sont des sous ensembles de mod le IFC documentent la mani re dont ces sp cifications sont appliqu es pour l impl mentation d une solution IFC Hietanen 2006 Enfin ce
398. t comme elle peut tre inutile Il est donc important de savoir d terminer quel r le joue le contexte et comment le prendre en compte En 1999 Cooper introduisait la CDB et une mod lisation innovante de l utilisateur et son contexte dans le domaine des IHM le persona Cooper 1999 Le persona est une description pr cise des caract ristiques d un utilisateur et de ce qu il veut accomplir Il peut repr senter un utilisateur particulier ou un ensemble d utilisateurs un profil Chang et al 2008 On apprend galement de Chang et al 2008 que le persona est cr en phase d tudes puis compl t si de nouvelles informations sont acquises lors des tests Il peut ventuellement tre imagin l issue Chapitre 4 De l utilisateur la conception logicielle et d interfaces d une id e de conception particuli rement innovante auquel cas l utilisateur type n existe pas encore Le persona a aussi t adopt dans les m thodes de CCU En fonction des cas d tudes il arbore diff rentes formes et diff rents contenus Pruitt amp Grudin 2003 Olsen 2004 Seffah et al 2009 De mani re g n rale la description de l utilisateur au travers d un persona doit apporter toute information qui pourra s av rer utile dans la conception du logiciel qu il devra appr hender ex les principales t ches de maintenance d un m thodiste qui sont utilis es pour concevoir un syst me de e maintenance i
399. t la m thode CoCsys comme base de leurs travaux scientifiques Cependant la r elle applicabilit de la m thode dans un contexte professionnel n est pas valu e et montrerait peut tre ses limites Nos exp riences dans le secteur AIC et notamment l exp rience CRTI weB cf Chapitre 2 soulignent le risque de proposer des services inadapt s malgr un processus de conception guid par l analyse m tier Du fait que cette m thode a t pens e pour la conception de syst mes mobiles et pour des processus m tiers fig s elle trouvera certainement ses limites dans d autres contextes professionnels plus complexes comme le Contexte Coop ratif d un Projet de Construction voir 1 1 Cependant en nous inspirant de CoCsys nous pouvons deja identifier des objectifs relatifs a la conception de notre propre m thode qui puisse tre fonctionnelle dans ce contexte Nous souhaitons analyser les pratiques existantes en utilisant des concepts et formalismes adapt s au domaine assurer le passage de l analyse m tier la proposition de services par la mise en correspondance de m ta mod les les d finissant supporter le d veloppement de nouveaux services ou leur am lioration dans des contextes d usage diff rents mais r pondant aux pratiques analys es 1 20 La m thode Symphony et les mod les pour la collaboration Nous avons voqu plus t t dans ce manuscrit cf g 1 12 le point de vue de Sophie
400. t le temps d attente li au processus d upload en lui m me Pour franchir ces limites un nouvel usage a t propos dans le cadre de l exp rimentation Le travail de conception tait bas sur l interpr tation travers les concepts de la m thode PUSH d un usage qui nous semblait r pondre certaines de ces limites celui de l outil dropbox et son adaptation notre contexte Chapitre 12 La m thode PUSH exp rimentations et bilan Aussi nous avons propos un service d upload automatique li CRTI weB dont les caract ristiques principales sont la surveillance d un dossier particulier avec la d tection de tout nouveau fichier ajout dans ce dossier le chargement automatique des fichiers d tect s sur la plateforme avec nommage automatique selon une convention de nommage volontairement simplifi e initiales de l auteur _ 8 premi res lettres du nom du fichier _ indice la mise jour automatique avec incr mentation de l indice en cas de nouvelle version d un fichier le report de l ajout d actions un document vers un usage ult rieur qui n cessitera de repasser par l interface web La figure suivante illustre le contextual use case qui d crit cette proposition Figure 132 C est au cours de cette exp rimentation que nous avons introduit dans la mod lisation sous forme du package bleu la distinction des sp cifications fonctionnelles ind pendantes
401. t les usages m diatisent les pratiques Chapitre 8 Introduction de la proposition m tiers puis comment ils sont mat rialis s par des services C est pourquoi les services d crits sont dits adapt s sous entendu adapt s aux pratiques m tiers tudi es 1 24 2 Les formalismes et outils utilis s Nos m ta mod les sont repr sent s sous la forme de diagrammes de classes UML Nous avons utilis l outil StarUML pour les diter Comme l illustre l exemple de la Figure 80 nous retrouvons dans ce type de diagrammes des classes famille parents et les attributs qui les caract risent nom ge profession Les attributs peuvent tre d termin s par la saisie d un texte libre ex nom ou par un choix parmi une suite de valeurs ex type profession Le choix entre oui et non ex mari est une num ration particuli re Le choix d une valeur num rique peut tre sp cifi par une plage de valeurs Des associations entre concepts avec les cardinalit s qui les d finissent ex le p re est en couple avec une seule m re et r ciproquement relation 1 1 les fils sont fr res de aucun ou plusieurs autres enfants relation 0 des compositions une famille est compos e de parents et d enfants pour lesquelles nous ne d finissons pas de cardinalit s en consid rant le cas le plus g n ral a chaque fois 0 des g n ralisations les fils et les filles sont des en
402. tame Gin Composants du service management fles sharing ard traceability in an AEC project R le du client du service T che te paan tale d ut pro naag d interaction see impl menter H pn gt gt Damme atved LAL project humer camo 4 verFyDakallb pasword owed URL protect mmber ee Le Inputs Outputs et Actions entre composants lt lt action gt gt i S vakdateOote 6 vohdteDsts lt lt antien gt gt as Cahier d exigences partie ditable Requirements Specification Form for adapted ICT services design and development Requirement Form ID Click here to enter text Name of the service to develop Click here to enter text Actors of the development project Service designer Click here to enter text Business analyst Click here to enter text Developer Click here to enter text Service consumer Click here to enter text Versioning Versions Dates Description of the project phase V X X Click here to Click here to enter text enter a date V X X Click here to Click here to enter text enter a date V X X Click here to Click here to enter text enter a date V X X Click here to Click here to enter text enter a date V X X Click here to Click here to enter text enter a date V X X Click here to Click here to enter text enter a date V X X Click here to Click here to
403. te urbaniste lectricien menuisier Pour une organisation on parlera de type d organisation ex une agence d architecture un bureau d tudes une entreprise de gros uvre Hanser 2003 Un acteur reconnu par son m tier peut endosser plusieurs r les et donc missions C est souvent le cas pour un architecte qui peut tre la fois concepteur et coordinateur R ciproquement un r le peut tre jou par plusieurs personnes aux m tiers diff rents Par exemple le m me r le de coordinateur jou dans un cas par l architecte du projet peut aussi bien tre attribu un coordinateur pilote d di qui fait de la coordination son activit principale Gr ce une attribution des r les ainsi plus tendue les t ches sont plus finement r parties ce qui permet chacun de mieux concentrer son travail Cela s av re particuli rement n cessaire dans un projet de grande envergure du fait de la complexit des missions De mani re g n rale le titre poss de plus un caract re distinctif et t moigne de la formation ant rieure d un acteur Le concept de r le est beaucoup plus important t moignant de l activit r elle d un acteur dans un contexte de projet particulier et du d roulement de celui ci 1 1 2 Lesartefacts et les outils Une interaction entre un acteur et ce qu il produit est support e instrument e par des documents des logiciels des machines des m thodes des lois on dira qu
404. te l activit de l informaticien cf L11 1 Ce champ d tudes fait l objet de plusieurs travaux de recherche cf 1 11 2 qui le font voluer Dans la pratique la g n ration n est pas encore enti rement automatis e et les cas d applications restent des cas relativement simples Cependant il serait int ressant d inclure notre approche dans une telle d marche pour en explorer les enjeux cela consisterait automatiser le passage de la mod lisation des pratiques m tiers la g n ration de services qui les supportent Eclipse propose des outils de transformation de mod les comme ATL qui pourraient nous permettre d investir une recherche dans ce sens et pourrait faire l objet d une perspective de ce travail 1 25 La m thode PUSH Practice and Usage based Ser vice enH ancement 1 25 1 Un processus qui valori les opportunit s Notre approche de conception de services adapt s pr conise l expression de trois points de vue distincts mais conceptuellement li s le point de vue organisationnel le point de vue op rationnel et le point de vue fonctionnel Des m ta mod les caract risent les concepts manipul s dans ces trois points de vue et diff rents outils et formalismes permettent de les exprimer Comme l illustre la Figure 83 le processus de conception support par l expression de ces points de vue devra favoriser la valorisation des opportunit s aussi bien m tier que technologiques Les c
405. tection approuver Localisation 2 2 2 commande Exim amp ass 24 01 2013 15 Q amp amp stores 6 Filtrer R initialiser RAPPEL TRES URGENT MAINTENANT Transmettra Scheur localisation commande stores ext rieurs Figure 12 Interface de CRT weB service Comptes Rendus Chapitre 2 Un cas de d veloppement d un outil de TCAO CRTI weB 1 5 Analyse critique 1 5 1 Contexte et protocole d analyse Comme nous l avons introduit plus t t ce travail de th se s est inscrit dans un contexte d analyse et de d veloppement autour de l outil CRTI weB En ce qui concerne l analyse des utilisations les retours d exp rience rassembl s par mes pr d cesseurs ont compos un premier corpus d l ments d analyse Nous les avons compl t s en acc dant en tant qu observateurs aux diff rents projets sur la plateforme afin d analyser pr cis ment les partages Nous avons notamment port notre attention sur l objectif de ces partages les auteurs en fonction des types de documents l utilisation des actions et l utilisation des r actions ainsi que leur contenu Pour ce qui est de l analyse du d veloppement nous avons pu porter un regard sur l ensemble des t ches de d veloppement pr vues et men es sous forme de tickets g r s par un outil en ligne et identifier la nature de ceux ci En plus de cela nous avons t impliqu s dans une t che de d veloppement pr cis
406. templates Word ou Excel et que bien qu elles soient conscientes du potentiel de l outil CRTI weB Compte rendu elles se satisfont de leur outil actuel Le service Documents a fait l objet d une analyse plus d taill e avec un retour sur chacun des services informatiques qui le composent Des exp rimentations ont permis d observer les diff rences d appr hension d un public un autre savoir entre professionnels et tudiants Le premier contexte est bas sur des relations contractuelles et une rigueur appliqu e un grand nombre d acteurs et de documents tandis que le deuxi me est informel et bas sur l ajustement mutuel d un petit groupe produisant peu d information De mani re g n rale le partage de documents doit tre am lior afin de prendre en compte la pluralit des formats d un document ex un plan aux format dwg et pdf et les liens qui Chapitre 2 Un cas de d veloppement d un outil de TCAO CRTI weB peuvent exister entre plusieurs documents Le partage de documents un par un trouve vite ses limites dans des situations comme les rendus de projet dans lesquelles on partage beaucoup d information que ce soit dans le domaine professionnel ou tudiant Le service de nommage est pertinent par rapport aux habitudes g n rales des professionnels Il doit tre cependant flexible car la convention de l Ordre de Architectes et Ing nieurs OAT peut ne pas t
407. ter les processus qu ils mettent en ceuvre dans leur contexte de travail sp cifique L IDM est con u cet effet il rassemble les processus et les exigences en termes d changes en dehors de toute pr occupation sur l impl mentation Les processus de l IDM sont cr s en plusieurs temps Dans un premier temps c est le point de vue m tier qui est mod lis Figure 73 avec l analyse des processus collaboratifs mis en place au cours de phase sp cifique du projet Bas sur le BPMN ces processus d crivent les t ches de chacun sous forme de swimlanes Le deuxi me point de vue porte sur des cas d utilisation au cours desquels les t ches m tiers sont d compos es en t ches utilisateur sur le syst me Figure 74 Le formalisme utilis est le m me et la d composition des t ches est identifiable par le nommage de celles ci ex les t ches 1 2 1 et 1 2 2 sont les t ches utilisateurs qui composent la t che m tier 1 2 L tude ne nous dit cependant pas qui exprime ces points de vue et comment Il serait int ressant d identifier la place des utilisateurs des analystes m tiers ou encore des d veloppeurs dans un tel processus ainsi que la mani re dont ils collaborent autour des langages utilis s Concernant le formalisme on ne retrouve par contre pas de formalismes propres au g nie logiciel GL Par exemple les auteurs utilisent le terme cas d utilisation qui est emprunt au G
408. teur et donc la connaissance de celui ci Il en est de m me pour l analyse des buts dans la CDB Ces conclusions sont notamment celles de l tude men e dans Williams 2009 qui souligne que la limite qui s pare ces approches est floue et difficile d terminer Constantine l origine de la conception centr e usage se base aussi sur l analyse de l utilisateur de ses t ches et objectifs Il cherche cependant limiter l intervention de l utilisateur en donnant la priorit l abstraction par les mod les sur 1 les donn es brutes propos des utilisateurs et 2 les prototypages r alistes et it ratifs Constantine amp Windil 2003 Chapitre 4 De l utilisateur la conception logicielle et d interfaces Tableau 4 Diff rences majeures entre CC Utilisateur et CC Usage Constantine 2003 Conception centr e utilisateur Conception centr e usage Concentration sur l utilisateur son exp rience sa satisfaction Concentration sur l usage et sur l outillage des t ches Dirig e par les donn es sur l utilisateur Dirig e par les mod les Implication importante de l utilisateur Implication s lective de l utilisateur Description des utilisateurs de leurs caract ristiques Mod les de relations entre l utilisateur et le syst me Maquettages r alistes Maquettages abstraits Conception par prototypage it ratif Conception par mod lisation Proce
409. th se PARTIE 1 ASSISTER LA COLLABORATION DANS LES PROJETS DE CONSTRUCTION DEFINITION D UNE PROBLEMATIQUE ET RECUL THEORIQUE Sommaire PARTIE 3 GUIDER LA CONCEPTION DE SERVICES COLLABORATIFS ADAPTES AU SECTEUR DE LA CONSTRUCTION ETUDES PROPOSITIONS ET PERSPECTIVES ne suicancnahinsnaacannssiesann diaidsrsnuadigrnddatuseunauessn tialieucabeansabasivanusncsienniotinn 137 Sommaire Sommaire Liste des abr viations et acronymes AIC Architecture Ing nierie et Construction GL G nie Logiciel GMF Graphical Modeling Framework IDM Information Delivery Manual THM Interface Homme Machine MDA Model Driven Architecture MDE Model Driven Engineering MO Maitre d ouvrage MOE Maitre d ceuvre MMPM M ta Mod le des Pratiques M tiers MMPU M ta Mod le des Usages MMS M ta Mod le des Services MMSA M ta Mod le des Services Adapt s MVC Model View Controller PUSH Practice and Usage based Service enhancement SOA Service Oriented Architecture TCAO Travail Collaboratif Assist par Ordinateur Liste des abr viations et acronymes Liste des abr viations et acronymes Introduction Au cours d un projet de conception construction architecturale le contexte de travail les comp tences et les missions de chacun des intervenants sont diff rents Cela rend difficiles la gestion et l optimisation du travail et des changes d information dans un
410. til upload files as one CRTI weB document Ce nouvel usage varie de l usage traditionnel qui consiste cr er un document CRTI weB pour chaque fichier partag Il s agit d un cas simple mais qui refl te bien l adaptation un besoin en termes d usage de la part d utilisateurs dans leur contexte de projet Chapitre 10 La mod lisation des usages le point de vue op rationnel Designer IP Diffusion des documents produits Responsable de ia alffusion Job Architect Executes Lh des concepteurs expose les choix conceptuels de l quipe pour vatuation Is composed of Is composed of P Share Inform Already supported by a service Already supported by a service Uses Targets Geometral A Group type Agency Plans du projet au stade APS Designer Author Designer lt Add here more specifittes if needed gt Status In Progress Figure 103 Rappel mod lisation de la pratique diffusion des documents USAGE DESCRIPTION Related Individual mer Usage Objective The user want to share multiple files grouped as one CRTI weB document USE CASES Insert here the use case diagram CRTI weB SHARE upload multiple files INFORM choose collaborators to inform lt lt indude gt gt s USAGE CONTEXT EEA E CONTE eee SS emporali once a day Applicationtype Web application Figure 104 Contextual Use Case de la pratique diffuse design
411. tion des besoins m tiers des acteurs Les artefacts regroupant documents du projet et ouvrages y sont bien d finis mais nous constatons que la d finition des activit s reste g n rique Les relations acteurs artefacts et acteurs activit s caract risent les actions de chacun que ce soit d un point op rationnel acteur artefact ou organisationnel acteur activit cependant ces concepts ne sont pas mis en avant Il n y a d ailleurs pas de liste exhaustive des types de ces relations ou d attributs d terminants les caract risant Nous avons donc cherch am liorer notre perception du contexte de l activit en am liorant la d finition de ces relations Vis vis des analyses sur la coordination nous partons du postulat que l activit de projet doit aussi bien tre d finie d un point de vue collectif qu individuel Pour cela il nous semble important de prendre galement en compte le profil m tier et les pr f rences d un acteur ou en d autres termes le contexte acteur qui est d terminant dans la r alisation d une activit individuelle Chapitre 3 Probl matique et m thode de travail Le troisi me contexte prendre en compte est le contexte utilisateur Nous devons donc aborder un point de vue technique Ici nous remettons directement en cause la place de l outil dans le contexte de l activit collective En effet nous supposons que l outil supporte le contexte de l a
412. tion des d veloppements Ecrans Contr les S cur s Re strutions Ratrakements Simulations tests techniques R alisation des d veloppements Ecrans Controles S curit s Re sttutions Retratements Simulations Recette fonctionnelle r alisation e validati Formation utilisateurs d ploiement Pilotage Figure 6 Exemple de diagramme de GANTT Les outils de compte rendu permettent de r diger les comptes rendus de r union et autres rapports relatifs au chantier Les outils de traitement de texte sont les plus couramment utilis s mais le d veloppement d outils num riques d di s afin de structurer le contenu d un document est apparu comme une perspective int ressante pour faciliter tant l dition que la diffusion et la consultation du compte rendu Guerriero 2009 Les outils de gestion des co ts et des ressources souvent sous la forme de tableurs ont pour but d anticiper le budget lors des prises de d cisions mais aussi de g rer les paiements durant la construction de l ouvrage Les plateformes d change de documents permettent de centraliser les documents dans un espace partag et de g rer l acc s des diff rents acteurs Ils poss dent des fonctionnalit s compl mentaires telles que l ajout de commentaires sur un document partag la notification par mail lors d un partage Les outils de mesure permettent d valuer les performances du b timent ex les performances
413. tion du travail la cha ne ou la standardisation des pi ces favorisant la production en s rie Mais actuellement l optimisation des processus ne suffit plus la croissance dans un environnement toujours plus demandeur doubl d un contexte conomique concurrentiel et changeant il faut vendre plus moins cher en d pensant moins Dans son tude sur la place du business model dans la compagnie Osterwalder 2004 montre que l volution de ce dernier est d pendante non seulement de l organisation c d des processus m tier comme d crit plus haut mais aussi de la strat gie adopt e d finie par une position des objectifs et des Syst mes d Information utilis s La Figure 48 illustre cette corr lation ainsi que l influence de ce que l auteur appelle forces ext rieures relatives l environnement comp tition changements sociaux l gaux technologiques ou dans la demande des clients D un point de vue strat gique la comp titivit est assur e par la conqu te de nouveaux march s et par l adoption de nouvelles comp tences D un point de vue technologique c est l adoption de nouvelles solutions en termes de services ICT qui aura un impact positif Osterwalder 2004 le justifie travers les quatre apports suivants la r duction des co ts de transaction et de coordination offre de nouveaux produits et services plus complexes de par la collaboration de plusieurs c
414. tion technologique Avec la m thode propos e dans cette th se nous voulons favoriser ce push technologique en identifiant les pratiques susceptibles d tre outill es et am lior es par les technologies Dans un deuxi me temps nous pourrons voir comment les dites technologies guid es par ces pratiques pourront offrir des services adapt s Cette double approche caract rise les d marches SOA Architecture Orient e Services Comme le dit Idoughi amp Kolski 2009 citant Avignon et al 2002 une d marche SOA peut tre motiv e et pilot e par les m tiers qui imposent l informatique ou au syst me d information d une organisation d voluer suite aux changements incessants et fr quents des besoins m tiers Elle peut aussi tre pilot e par les technologies o il s agit d offrir des opportunit s aux diff rents m tiers travers l mergence de nouveaux besoins suite l volution de l offre technologique Internet t l phonie mobile Franchir l cart entre les domaines Notre positionnement par rapport aux approches SOA favorisant la fois le push m tier et le push technologique nous permet de cr er un lien entre le m tier et la technologie Les concepts de pratique et d usage supportent ces deux dimensions Ils s inscrivent ainsi dans une m thode de conception de services collaboratifs qui devrait permettre de pallier l chec de la solution collect
415. tionary nature of role Part of regular job INCUMBENTS Characteristics of performance of role Is there anything special or distinguishing about this role in terms of orientation attitude or emotional state typical within role Harried under pressure frequency with which role is played Less than once a month regularity with which role is played Impulse buy after infomercial runs intensity of interaction in the role Sporadic bursts of calls duration of interaction in the role Full 8 hour shift complexity of interaction in the role No brainer predictability of interaction in the role Scripted sales protocol volume of information handled in the role Limited items available direction of information flow to or from system Data entry Criteria for support of role Are there any design objectives that are particularly important for this role such as ease of learning J enhancement of proficiency retention of learning J user convenience efficiency of interaction J accuracy of input reliability of interaction clarity of presentation user satisfaction J comprehensibility of presentation Are there any specific functions features facilities capabilities or content that are particularly important for this role to be performed effectively Contact constamine foruse com 2004 Constantine amp Lockwood Lid Figure 31 Mod lisation d un r le utilisateur dans l
416. tre 4 d crit l volution des m thodes du GL leur enrichissement par l tude de l utilisateur et introduit l ing nierie dirig e par les mod les Le deuxi me chapitre 5 explore le concept de service avec une tude sur la mod lisation des processus m tier dans une entreprise et la conception des syst mes d information pour l entreprise Le troisi me et le quatri me chapitres 6 et 7 introduisent de mani re th orique puis par des cas d tudes la conception de services collaboratifs Partie 3 guider la conception de services collaboratifs adapt s au secteur de la construction Les chapitres huit douze forment la troisi me et derni re partie de cette th se Le premier chapitre 8 introduit notre approche pour l adaptation de services collaboratifs aux pratiques du secteur AIC Les suivants la d crivent selon le d coupage suivant mod lisation des pratiques chapitre 9 mod lisation des usages chapitre 10 mod lisation des services et capitalisation de l tude sous forme d exigences chapitre 11 Le dernier chapitre chapitre 12 pr sente trois exp rimentations qui ont t men es pour construire parfaire et valider partiellement cette approche Une conclusion propose un bref r capitulatif du travail effectu Nous essayons notamment d en faire ressortir les limites et d en d gager des perspectives qui pourront tre abord es dans des travaux futurs Introduction PARTIE 1 As
417. tre d marche scientifique se poursuit en proposant une conceptualisation de ces pratiques travers un m ta mod le dont le principe d instanciation assurera une description structur e et uniforme d un projet de conception un autre tel qu introduit dans la d finition de notre m thodologie cf m Les travaux pr c dents sur le M ta Mod le du Contexte Coop ratif MMCC d crit en 1 1 d finissent d j un ensemble de concepts servant de base cette description Nous utilisons les diagrammes de classe UML pour mod liser les concepts utiles la description de ces pratiques leurs attributs et les relations s mantiques qui les relient Le M ta Mod le des Pratiques M tier MMPM est ainsi construit partir de deux m ta mod les le M ta Mod le des Pratiques Collectives MMPC le M ta Mod le des Pratiques Individuelles MMPI 1 28 LeM ta Modele des Pratiques M tier 1 28 1 Les pratiques collectives Nombreuses sont les pratiques collectives qui peuvent tre identifi es lors de l observation d un projet Par exemple la pratique suivante est extraite de la famille 5 Le choix de la structure doit se faire par la collaboration de l architecte et de l ing nieur structure avec l accord final du contr leur technique Un nom pour identifier la pratique peut tre isol de cette description comme par exemple choix de structure Chapitre 9 La mod lisation des pratiques le point de v
418. treprise orient e services la conception de Syst mes d Information d activit s UML reste plus technique et donc moins accessible aux business analystes En effet si BPMN est un langage qui fut d velopp exclusivement pour la repr sentation des processus m tier les diagrammes d activit UML d crivent originellement les activit s et actions d un syst me C est pourquoi il aura fallu tendre ce formalisme en st r otypant les activit s en processus il s agit de cr er un l ment nouveau d riv de celui qui existe d j mais qui a des propri t s sp cifiques adapt es un usage sp cialis ici la repr sentation des processus m tier BPMN et AD suivent tout deux les patterns des workflow de Huang amp Mynatt 2006 que l on peut regrouper en quatre familles les contr les de flux les donn es les ressources les r mm r Secretar a de Mare everte Cake co Ertaa ae 143 D phe pat Le v der lt gt A t En Di CA De MALTA 22 Letieteyde Ge tonus and 4Pu 80 4 beter da cum arte 194 de NUN BO 6 gene pw edenebte i Di on gh Yy Beane de manti RB pme te datar g 1 x ob Mewes sentebugde peu im be towers tatagi poe nit Cetewlegae de Codie de tower te Y oe ornp pers tee s agite tons teeter aetb f 1 EG pe Gente AA wee e o n cms re ae 40 ames re to ee trad re nre 4 rapes ee e rtt pon aeae g me a Mle pus ee i TE mi a C
419. tribuent ainsi l volution des usages Si du point de vue de la terminologie notre choix se tourne donc vers l adoption du concept d usage la litt rature relative la conception d HM valide galement ce choix D apr s la description qui a t faite au chapitre 4 au 1 10 1 Tableau 4 les enjeux de l approche de conception centr e usage de L L Constantine amp Lockwood 2003 semblent en effet correspondre aux n tres la concentration sur l outillage des pratiques m tiers une approche dirig e par les mod les une implication s lective de l utilisateur des processus syst matiques et enti rement sp cifi s une adaptation assur e par l ing nierie et non par la r solution it rative d erreurs 1 31 2 Caract risation de l usage L usage est donc relatif un objectif qui le motive Cet objectif est d riv de la pratique m tier qu il m diatise on d taillera par l usage la mani re de r aliser cette pratique Nous chercherons d finir les usages pour chaque acteur ainsi c est la pratique individuelle que l on fait r f rence ici Par exemple pour la pratique diffuser les documents l usage pourra consister diffuser les documents par mail En d autres termes on pourra dire qu il s agit de faire l usage du mail pour diffuser les documents Tel que nous l avons vu dans le chapitre 4 la conception d IHM enrichit la
420. truction Nous observons comment dans un m me projet la diffusion d informations n est pas un processus unique mais peut se d cliner en plusieurs pratiques Seules les observations faites en collaboration avec les professionnels du secteur permettent de capter ces sp cificit s Il s agit ici de les repr senter au travers de cas r els et non pas de mod liser un processus g n ral Le formalisme utilis supporte cette repr sentation Ce diagramme permet donc de comprendre comment se d roule un projet avec un certain degr de d tail Mais l int r t de cette distinction des pratiques r side dans la mani re dont on va les m diatiser En effet nous verrons que les usages peuvent varier en fonction de la pratique Chapitre 12 La m thode PUSH exp rimentations et bilan Hors ces variations qui assurent l adaptation d un outil et son appropriation par les utilisateurs ne sont souvent pas prises en compte dans les d marches de conception classiques 1 40 3 Les variantes d usage Les professionnels utilisant CRTI weB avaient relev la n cessit de partager plusieurs documents d un coup en simplifiant le processus d envoi d j contraignant de par les multiples saisies relatives au nommage des documents et au choix de la zone et des actions La premi re solution tait d impl menter un service g n rique permettant de choisir plusieurs fichiers partager et de cr er autant de documents CRT
421. ts Les ressources sont les acteurs responsables de ces activit s les outils ainsi que la connaissance utilis s aa Chapitre 3 Probl matique et m thode de travail En ce qui concerne les sous processus d information Bj rk consid re ces activit s dites primaires comme des r gles support es par des activit s secondaires dont il en distingue quatre types la production d une nouvelle information la communication de personne personne la diffusion d information la recherche et la r cup ration d information Le chapitre 10 pr sente comment nous int grons ces concepts afin d approfondir notre description du m tier Le concept d usage Nous pr f rerons utiliser le concept d usage plut t que celui d utilisation lorsque nous voudrons consid rer le rapport d un acteur vis a vis de l outil Cette distinction va au del d un choix s mantique et trouve notamment sa justification dans le domaine du g nie logiciel Constantine amp Lockwood 2003 Le chapitre 4 introduit les diff rentes approches de conception logicielles dont la conception centr e usages Le chapitre 10 et particuli rement le L311 approfondit la distinction entre usage et utilisation et positionne notre approche par rapport ce concept L objectif au travers du concept d usage et de d crire l acteur en tant qu utilisateur le contexte d utilisation d riv du contexte m tier et finale
422. tte 2006 pr sente CoCSys un processus d assistance la construction et l volution d applications mobiles en s appuyant sur une architecture et des m canismes base de mod les Il s agit d un processus it ratif bas sur la transformation de mod les voir la Figure 58 la phase 0 est la phase d identification des sc narios d utilisation donnant lieu cr ation d un modele de sc narios la phase 1 consiste cr er un mod le comportemental sur la base des sc narios la phase 2 transforme le mod le comportemental en mod le d architecture logicielle la phase 3 supporte l it ration par la prise en compte des nouveaux sc narios d utilisation dans le mod le comportemental Cette section en pr sente dans un premier temps le principe de fonctionnement th orique puis une analyse critique qui questionne notamment l applicabilit de cette m thode Chapitre 7 Les m thodes de conception de services tudes de cas Configurations mat rielles Adaptation Phase 2 Contextualisation CAB Mod le comportemental Sp cialisation Phase 3 S AN Niveau Appli Collaborative Gone id Niveau Infrastructure du Groupware Niveau du Syst me Distribu F LE Nouveaux sc narios RB v 71 te 66 Figure 58 Sch ma du processus CoC Sys tir de Delotte2006 Application coop rative Composants Patterns d interaction 1 19 1 D roulement de la m t
423. ty project gathenng groups of students from 2 different universities Figure 131 Diagramme de la pratique analys e Les tudiants disposent pour se coordonner au cours de ce projet du service de partage de documents de CRTI weB et du syst me de Bureau Virtuel pr sent s pr c demment voir 1 2 2 Ils peuvent galement utiliser tout autre outil qu ils jugeront utile la gestion de leur travail Les tudiants sont habitu s utiliser les services de Dropbox ou Facebook pour travailler en groupe car ils ne sont pas soumis aux restrictions du milieu professionnel en particulier les clauses de confidentialit et ces outils font partie de leurs usages personnels r guliers Ainsi nous avons pu constater dans les ann es ant rieures qu ils jugent souvent CRTI weB trop complexe et dans la plupart des cas abandonnent son usage au profit de solutions plus simples Des requ tes d utilisateurs d finies en termes de nouveaux services n ont pas t formalis es comme c tait le cas pour lors de l exp rimentation pr c dente Cependant les professeurs encadrant le projet et jouant le r le d expert m tier nous ont rapport une analyse de ces limites actuelles de CRTI weB la lourdeur des tapes d identification login oubli r gulier des mots de passe le temps n cessaire la phase de nommage des documents envoy s trop contraignant dans un tel contexte et peu adapt e la nature des documents envoy s e
424. u une entreprise est d finie comme une structure qui combine en interne des moyens humains mat riels immat riels services et financiers afin de cr er et fournir en externe des biens ou d autres services On distinguera alors entreprises de manufacture et entreprises administratives tout comme on pourra parler d industrie traditionnelle et d industrie de services Mais quelle que soit leur nature elles adoptent toutes un Business Model particulier Afin de rester comp titives les entreprises doivent maintenir voire augmenter leur productivit c a d l efficacit le rendement de leur processus de cr ation de biens ou de services et leur production c a d l apport de valeur ajout e cette cr ation Pour cela la restructuration de leur mod le le Business Model est parfois n cessaire D un point de vue organisationnel cela implique l adoption de nouveaux produits et processus Hodgson 2003 Les impacts respectifs du Taylorisme fin du 19e si cle et du Fordisme d but du 20e sur la croissance du secteur de la sid rurgie et de l automobile en sont un exemple connu Les mod les furent en effet boulevers s de par l volution des processus de travail et des produits avec l application de plusieurs principes tels que la division du travail la fois verticale c d la s paration de la conception et de la r alisation et horizontale c d la r partition des t ches avec l appari
425. u service Cette description doit tre conforme au M ta Mod le de Services qui mt gre le mod le d architecture Co MVC Nous adoptons pour cela le diagramme de s quences UML un formalisme utilis en conception logicielle pour d crire la solution dans une architecture logicielle et mat rielle Len Bass et al 2003 cf 1 9 3 Figure 24 1 37 1 Le diagramme de s quence Il s agit d instancier ici le M ta Mod le des Services Nous repr sentons sur la base d un diagramme de s quences UML l outil qui fournit le service m tier la description de ce service m tier le client le service ICT consid r ses composants et enfin les changes inputs outputs et actions qui s op rent Reprenons l exemple du partage de documents pour illustrer cette tape Il s agit d effectuer ce partage via l outil CRTI weB service m tier documents voir 1 33 Le diagramme de t ches qui a t cr lors de la d finition de l usage est repris ci dessous Figure 116 Q Upload multiple files ls composed of ren choose files and clustering mode gt then D name crti web document gt Is composed of Abstract user interaction type Selection 1_n Validation Abstract user interaction type Input Y Concrete user interactin type Tigger P GP imerac with bm Com ser interactin type Trigger ac ven EL 69 Yea BQ Ed visualize fles PEN P intera wih uplo
426. ual for AEC projects In C B W78 2010 Cairo Egypt pp 16 18 Eastman CM amp Jeong Y 2010 Exchange model and exchange object concepts for implementation of national BIM standards Journal of Computing in Civil Engineering 27 pp 25 34 Ellis C amp Wainer J 1994 A conceptual model of groupware Proceedings of the 1994 ACM conference on Computer supported cooperative work CSCW 94 pp 79 88 Eloranta L amp Kallio E 2006 A Notation Evaluation of BPMN and UML Activity Diagrams Emig C amp Weisser J 2006 Development of SOA based software systems an evolutionary programming approach In Advanced International Conference on Telecommunications and International Conference on Internet and Web Applications and Services AICT ICIW 2006 IEEE Computer Society Endrei M et al 2004 Patterns Service Oriented Architecture and Web Services IBM Corp International Technical Support Organization Engestr m Y 1987 Learning by Expanding An Activity theoretical approach to developmental research Favre J M 2004 Towards a Basic Theory to Model Model Driven Engineering In Workshop on Software Model Engineering WI SME 2004 Lisboa Portugal Favre L amp Pereira C 2007 Improving MDA based Process Quality through Refactoring Patterns In Proc of the 1st International Workshop on Software Patterns and Quality Citeseer Fernandez A 2010 Les nouveaux tableaux de bord des managers Eyrolles ed
427. uchscreen La connexion internet connect online d connect offline Le type de sortie vid o video output cran screen projecteur projector Le type de sortie audio audio output haut parleurs speakers couteurs earspeakers Le type d entr e vid o video input cam ra video camera appareil photo num rique photo camera Le type d entr e audio audio input microphone microphone Chaque l ment du contexte peut tre pr cis dans un deuxi me tableau additional information about context le but tant d apporter toute information qui pourra s av rer utile au d veloppement de la solution Les t ches et le contenu d interaction Chaque intention utilisateur sera d compos e pour former un arbre de t ches comprenant plusieurs niveaux d abstraction La t che abtsraite d crit l interaction de mani re g n rale et ind pendante de la technologie Elle est d finie par un nom et un type Deux types de t ches concr tes sont possibles la t che d interaction action physique de l utilisateur sur le syst me et la t che de perception retour visuel ou sonore du syst me pour Concrete interaction task informer l utilisateur Les t ches syst me qui auront t identifi es dans le use case apparaissent galement Concrete perception task Chaque l ment du contexte coop ratif manipul par une op ration ainsi que d fini
428. ue organisationnel Nous pourrions d crire de cette mani re toutes les pratiques identifi es Ainsi le nom la description et la famille seront les attributs permettant de caract riser une pratique collective La classe Pratique collective dans le diagramme de classes UML suivant repr sente cette caract risation La d termination du nom et de la description se fait par saisie de texte alors que la famille est choisie dans une num ration voir le paragraphe la mod lisation et ses outils en 1 24 1 Il s agit ensuite de d finir les acteurs les artefacts et les activit s impliqu s dans la pratique Certaines des possibilit s auront peut tre d j t identifi es dans la description comme par exemple ici les acteurs l architecte l ing nieur structure et le contr leur technique Ces concepts ont t d finis au cours des tudes pr c dentes du laboratoire MAP CRAI dans le MMCC M ta Mod le du Contexte Coop ratif Le MMPC que nous proposons a pour but de mod liser l implication de ces concepts dans une pratique collective Il faut souligner que les num rations d crites dans les m ta mod les suivants ne sont pas toujours exhaustives et pourraient tre compl t es cet effet un champ autre est inclus comme choix lors de l instanciation Il faut alors renseigner l information voulue sous forme de remarque et compl ter si besoin le m ta mod le La classe acteur est sp cifi e
429. uments tandis que la troisi me consiste proposer un nouveau service m tier mais utilisant l information trait e par le service m tier Comptes rendus La nature de la premi re exp rimentation tait l application de la m thode PUSH pour le transfert d exigences vers une soci t externe Kitry consulting qui est en charge de deux activit s les d veloppements informatiques sur la plateforme le transfert vers les professionnels et l accompagnement au travers d ateliers Ce contexte partenarial nous a permis d identifier les besoins en termes d changes entre l utilisateur le concepteur et le d veloppeur dans un projet de d veloppement logiciel d di aux professionnels du secteur de la construction Figure 122 Il nous a galement donn mati re r flexion sur l analyse des besoins en termes de pratiques m tiers et d usages des utilisateurs dans la recherche de solutions des probl mes rencontr s par des professionnels Analyse des besoins Observation des besoins we Si so Notre quipe Kitry Consulting Professionnels DL Sp cification de l outil Transfert de l outil Figure 122 Le contexte de projet de d veloppement lors de la premi re exp rimentation Deux autres exp rimentations ont permis d valuer les hypoth ses faites au cours de la premi re La deuxi me exp rimentation a t men e en collaboration avec un autre informaticien jouant le r le de d veloppeur
430. uments diff rents G n rale Usage plus rapide Plus de confort dans l upload gain de temps D sactiver onglet d archivage Journalisation des courriels de notification Oui Ajouter date de d p t de l indice ou Etre averti des op rations de ses G n rale Usage supprim Modification de la G n rale r gularit M o ea con fon fichiers existants quand on change la CN au Contenu Changement du nom RS E rendre nouveau disponible rendu selon demande de l OAI Oui pouvoir identifier les acteurs qui ont acc d un compte rendu particulier Comptes rendus classer les acteurs ou CR classer les remarques par priorit dans Cr er et partager des CR de chantier Identifier activit des collaborateurs Identifier activit des Cr er un CR de chantier Modification du format Contenu de la donn e T che ayant consult un T che Classement des acteurs T che Classement des Pas d onglet inutile superflu Mails moins dispers s Retrouver un document Contenu identification de la Meilleure compr hension gain de Meilleure ergonomie Meilleure compr hension gain de temps Meilleure compr hension gain de temps Meilleure compr hension gain de Meilleure compr hension gain de CR Pouvoir identifier rapidement les nouvelles remarques Identifier activit des collaborateurs Identifier remarques T che depuis derni re Meilleure compr hensi
431. ur n _ gt Envoie la e 1 a Dimensions spatio ORE Mod le temporelles et Utilisateur 2 Ase arta fonctionnelles Interagit avec partag Mod le A R Fournit priv Se synchronise Utilisateur 1 b l information E eee S actualise afficher requ te Figure 56 Le mod le d architecture Co MVC pour d crire un service collaboratif Chapitre 6 Travail Collaboratif Assist par Ordinateur et Services Collaboratifs 1 17 Versune r ponse a l chec de la solution collecticiel 1 17 1 Les constats d chec Nous avons pr sent dans la premi re partie de ce manuscrit l exp rience men e dans la conception d un collecticiel particulier CRTI weB Cet outil offre un certain nombre de services collaboratifs qui ont t d finis pour le domaine particulier du projet AIC Pourtant nous avons pu identifier des manques d adaptation de l outil entrainant certains freins son utilisation par les professionnels du domaine CRTI weB n est pas un cas isol la litt rature nous montre que ces manques g n raux d adaptation trouvent leur source dans le processus de conception lui m me Jonathan Grudin Grudin 1988 Grudin 1994 identifie trois cas d checs majeurs l outil lui m me choue car il demande un travail suppl mentaire des utilisateurs qui n en per oivent pas directement le b n fice la conception de l outil choue car elle est bas e sur des intuitions de b n
432. urs Peu de tests on t E ae lident 1 d privil gient Pupload effectu s ils valident le Aberdeen 4 multiple et en font fonctionnement du DA RE z adaptation 3 gt n a t effectu l usage pour lequel il a service mais pas son t d velopp adaptation 1 43 2 Lestrois push Les trois exp rimentations men es nous ont permis d identifier trois impulsions possibles pour le d veloppement d un service adapt c est ce que nous d finissons comme les trois push de la m thode Le push m tier Le push m tier c est l impulsion issue d un besoin d assistance des pratiques ex cut es dans un contexte m tier particulier Cette assistance devra permettre d atteindre les objectifs m tiers identifi s en assurant la satisfaction des utilisateurs lors de la cr ation ou l adaptation de services La cr ation de CRTI weB ainsi que les phases ult rieures de d veloppement comme celle constituant notre premi re exp rimentation sont issues d une telle impulsion Le push technique Le push technique permet d assister une pratique de mani re diff rente par une r ponse technologique alternative des solutions existantes Il s agit de d finir un autre usage qui sera per u comme plus simple par les utilisateurs tout en assurant l ex cution de leur pratique m tier La d finition de CRTI box deuxi me exp rimentation est issue d une telle impulsion bas e sur l tude et
433. ustering mode selection TT TO ar Concrete user interactin type Trigger ph ou Etope 1 S l ction du ou des fichiers Etope 2 muti fichiers gt O M me document plusieurs fichiers C Pusieurs documents ind pendants Figure 111 Correspondances entre le diagramme de pratiques et les mod les d usage diagramme de cas d utilisation d interactions et maquettages Chapitre 10 La mod lisation des usages le point de vue op rationnel Alors que le travail sur les pratiques est un travail d analyse s amorce ici le travail de conception En effet nous caract risons le contexte attendu les intentions ainsi que les sc narii d interactions id aux En d autres termes il s agit ici de concevoir l usage id al sans pr occupations d ordre technique et donc sans pour l instant appr hender les cas d erreurs et les limites technologiques possibles Les soci t s de services jouent ce r le de concepteur en tirant parti du travail des experts m tiers qui interviennent dans l analyse des pratiques Le passage d un point de vue un autre sur la base de mod les doit assister cette collaboration La section suivante illustre comment la description de l usage nous guide vers la sp cification de services d un point de vue purement fonctionnel Dans la continuit de notre approche nous conceptualisons le service en fonction des concepts de l usage pour assurer la correspondance ent
434. uthor Contractor Author Designer Author Contractor Author Designer Status To Modify Status Over Status To Execute Status Over Status In Progress Refers To Buitding Message type Reaction The bulding in its state of execution Remarks on the last meetng report Author Contractor Author Other Status In Progress Status Over Figure 138 Diagramme de la pratique de surveillance du chantier 1 42 3 Identification et conception de l usage perspectives de d veloppement D un point de vue op rationnel l intention de l utilisateur est dans un premier temps d acc der aux l ments du compte rendu et aux remarques en fonction de sa localisation dans le b timent l chelle du site du b timent de la pi ce et de l ouvrage Le syst me sera charg d afficher la bonne information en fonction de la localisation Nous imaginons qu identifier un ouvrage pour en afficher les informations relatives pourrait se faire de deux fa ons en s lectionnant l ouvrage dans le mod le 3D ou en scannant un QR Code voire une puce RFID sur l ouvrage On pourra d finir ainsi deux variantes de l usage A l chelle de l ouvrage il sera alors possible de recenser tout nouveau d faut remarqu et pas encore r f renc afin d en informer les entreprises Chapitre 12 La m thode PUSH exp rimentations et bilan The user should be able to consult remarks about defect on building element and
435. valides Ce travail d impl mentation implique deux exigences primordiales cibler des cas d utilisations concrets et int ressants pour les utilisateurs maintenir la compatibilit avec l impl mentation d autres logiciels A l heure actuelle les v ritables utilisateurs et concepteurs de ces manuels sont des chercheurs Une volont de standardisation des processus de conception construction existe mais la port e de l approche permet aussi d envisager ce formalisme pour d crire le processus collaboratif d un projet donn 1 21 2 D finition des objets d change sur la base de processus L IDM est comme son nom l indique un manuel c est dire un document qui regroupe des informations n cessaires l impl mentation de mod les IFC Mais c est galement selon la d finition de Berard amp Karlshoej 2012 un langage de mod lisation des processus m tier qui tend BPMN une mani re de mod liser et reconcevoir le processus lui m me Les MVD Model View Definition traduisent l IDM en un document pour le d veloppement logiciel Hietanen 2006 Il s agit de sous ensembles du mod le IFC global et contenant la structure des donn es pour l change Le processus et les exigences d change Le processus illustr dans la figure suivante Figure 73 repr sente la collaboration entre plusieurs r les organisationnels que portent les concepteurs design team le coordinateur project
436. xte Acteur simple Groupe d acteurs EE Figure 88 M ta mod le dela pratique individuelle MMPI Caract risation des op rations finalisation du MMPM Dans la th orie de l activit pr sent e pr c demment au R l op ration est le troisi me niveau d fini apr s l activit et l action Les op rations sont les m canismes qui composent l action et qui sont r alis s de mani re inconsciente Nous nous servons de ce m me concept pour d tailler les pratiques individuelles Afin de d finir ces op rations nous avons adopt les sous processus de l information d finis par BO Christopher Bj rk B C Bj rk 1999 B C Bj rk 2002 et introduit pr c demment au la production la communication la diffusion la r cup ration En tant que familles d op rations ces quatre sous processus couvrent l ensemble des op rations au m me titre que les onze familles de pratiques collectives pour les besoins m tiers Le m ta mod le des pratiques m tiers MMPM est une volution du MMPI par l ajout et la caract risation des op rations m tier qui composent une PI Chapitre 9 La mod lisation des pratiques le point de vue organisationnel Projet Type_certification num ration ka Activit simple Groupe d activit s lt lt enumeration gt gt Type_support besoin d un nouveau service d ja support e
437. ycle de vie du projet travers les disciplines et les applications logicielles Eastman amp Sacks 2010 Les probl matiques actuelles dans l impl mentation du format IFC sont proches de celles qui se posent pour la conception de services et SI savoir la ma trise de la s curit des changes la fiabilit de l utilisation Le format IFC est surtout utilis aujourd hui pour rendre interop rables des logiciels de CAO Conception Assist e par Ordinateur c est dire permettre l change de maquettes num riques d un logiciel l autre Cependant ces changes bas s sur l interop rabilit des donn es ne sont pas structur s Comme on peut galement le lire dans Eastman amp Sacks 2010 le sch ma IFC ne capture pas la mani re dont l information est cr e et partag e par les professionnels I ne d finit pas non plus les exigences relatives ces changes ce qui rend difficile la conception de v ritables logiciels de collaboration bas e sur IFC Pour r pondre cela l approche IDM soutenue par l association BuildingSMART a pour objectif de d finir des mod les d changes La r alisation de manuels IDM Information Delivery Manual d finit les sp cifications pour faire correspondre les changes d information avec les objets du mod le IFC pour l impl mentation d interfaces logicielles r ellement collaborative dans le sens o elles supporteraient des processus m tiers

Concevoir des services collaboratifs adaptés à des - MAP-CRAI

Contents

Download Pdf Manuals

Related Search

Related Contents

Concevoir des services collaboratifs adapt&eacute;s &agrave; des - MAP-CRAI

Contents

Download Pdf Manuals

Related Search

Related Contents

Concevoir des services collaboratifs adaptés à des - MAP-CRAI