Home

Concevoir des services collaboratifs adaptés à des pratiques métier

1. 35 Chapitre 2 Un cas de d veloppement d un outil de TCAO CRTI weB 37 2 1 Description de Texvp rience sise 37 2 2 AE ER 42 2 3 elle O IT 45 eR Chapitre 3 Probl matique et m thode de travail 47 3 1 Construction de la probl matique iii 47 3 2 M thode de r ch rch assises hein ins EE 50 PARTIE 2 THEORIES ET METHODES CONCEVOIR DES SERVICES COLLABORATIFS 53 HM Chapitre 4 De l utilisateur la conception logicielle et d interfaces EE EE ee EE Se 55 4 1 Les m thodes et activit s relatives la conception Jogicielle 55 4 2 La conception d IHM de l utilisateur l interface 69 4 3 Les enjeux de l Ing nierie et de l Architecture Dirig e par les 82 4 4 Conclusion vers une m thode centr e usages ne 87 Chapitre 5 De l entreprise orient e services la conception
2. Acteur simple Groupe d acteurs lt lt enumeration gt gt Type_op ration r cup ration Diffusion Projet Type_certification num ration Activit simple Groupe d activit s besoin d un nouveau service d ja support e par un service service inutile lt lt enumeration gt gt Type_support manipule engendre Message Communication engendre Groupe d artefacts groupe texte lt lt enumeration gt gt Type_op ration diffusion concerne obtenir consulter identifier v rifier partager rendre indisponible lt lt enumeration gt gt Type op ration production lt lt enumeration gt gt Type op ration communication cr er ex cuter modifier r parer Hier inclure mettre jour supprimer contacter valider demander commenter informer 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 valid
3. 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 prouver dans un business model qui se veut comp titif Dans la section suivante nous nous int ressons particuli rement leur conception partir de la mod lisation des processus m tiers 1 14 Dela mod lisation des Processus M tier au Syst me d Information 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 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 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 facon 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
4. PART 3 SERVICE SERVICE SPECIFICATION Insert here the sequence diagram Annexes Designing collaborative services adapted to business practices a usage centered 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 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 info
5. 129 7 3 1 BIM IFC IDM une br ve introduction 129 7 3 2 D finition des objets d change sur la base de processus 130 7 33 Analyse critique et conclusion erret reete 132 7 4 Conclusion et mise en place de la 134 PARTIE 3 GUIDER LA CONCEPTION DE SERVICES COLLABORATIFS ADAPTES AU SECTEUR DE LA CONSTRUCTION ETUDES PROPOSITIONS Chapitre 8 Introduction de la proposition 139 8 1 Enjeux de la nne tn erre AEN 139 8 1 1 Un domaine d application particulier eeseeseseeseeeeneeeneeen eene nnne 139 8 1 2 Le contexte d tude et les obiecnfs enne 140 8 2 pete 141 8 2 1 La caract risation des points de vue 141 8 2 2 Les formalismes et outils utilis s 144 8 3 La m thode PUSH Practice and Usage based Service enlaneement 147 8 3 1 Un processus qui valorise les opportunit s 00000000 00000000000000000000000000000004 147 8 32 Le cahier cahier d exigences 422 redeo fond 149 8 4 iSo SY 151 Table des mati res I 153 9 1 D finitions t Concepts iiie HR COR FREE TRE LR REC OE
6. 283 Analyse des tickets de conception de CRTI WweB ss 283 Cahier d exigences mode d emploi 288 Cahier d exigences partie ditablel sess 294 E E EE E E A E ETIN 299 Sommaire Liste des abr viations et acronymes AIC Architecture Ing nierie et Construction GL G nie Logiciel Graphical Modeling Framework IDM Information Delivery Manual IHM Interface Homme Machine 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 Mode 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 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
7. Chapitre 5 De l entreprise orient e services la conception de Syst mes d Information o 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 systeme tel qu il est percu par les acteurs externes qui appellent cette fonctionnalit de classes Mod lise la partie statique d un systeme 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 quences d int ractions d t t 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
8. Operationalrole CRTI weB classic user Applicationtype Web appheation PHP web services REST SS LE EE DG Qc NN E ee he application specificity Is there already a developed application to adapt Y ou 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 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 veloppeurs 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
9. eee RE90 LES OPERATIONS AUTOUR DU CONCEPT D ESPACE DE TRANSITION RE91 INSTANCIATION DU MMPM PAR UN DIAGRAMME D ACTIVITES UML RE92 INTERFACE DE L EDITEUR GMF D ARBRES HIERARCHIQUES POUR LA MODELISATION DES PRATIQUES EXEMPLE E 171 RE93 LE TABLEAU DE BORD GME iiec ice ede E ERE ea e 172 RE94 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 DE DOCUMENTS MPH 175 RE 96 RELATION ENTRE LES CONCEPTS D USAGE DE PRATIQUE esse 179 RE97 CARACTERISATION DES INTENTIONS ET DES TACHES seen 98 CARACTERISATION DU CONTENU D INTERACTION RE99 CARACTERISATION DU CONTEXTE D USAGE cccccccccccecsessseceeececsesssaeseeececsesesaeceeccecsensasaeeeeeees RE 100 CARACTERISATION DE LA RELATION ENTRE USAGES Table des illustrations FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU RE 101 REPRESENTATION SIMPLIFIEE DU MMU BLEU LIE AU MMPM ROUGE RE 102 ADAPTATION DU FORMALISME DES DIAGRAMMES DE CAS D UTILISATION S RE 103 RAPPEL MODELISATION DE LA PRATIQUE DIFFUSION DES DOCUMENTS 189 RE 104 CONTEXTUAL USE CASE DE LA PRATIQUE
10. fr re de nom texte K type profession num ration 4ge valeur num rique E IL ll nom texte type profession num ration 4ge valeur num rique mari 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 d utilisation de taches ou encore de s quence cf 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 les 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 et l exploitation de nos m ta mod les Le projet Ecl
11. Chapitre 6 Travail Collaboratif Assist par Ordinateur et Services Collaboratifs repr sentent qu une partie du contexte coop ratif c 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 adapteraient 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 compo
12. Dispositif dispositif num ration O5 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 sortie vid o oui nonjinconnu Application application num ration Technologie texte Type_sortie audio oui non inconnu 1 1 1 Outil nom texte ex cute utilise Lx 1 T che outil 1 OI T che m Nom ex cute Type_t che T che utilisateur concr te Lu Intention utilisateur 1 Dom T che utilisateur abstraite 12 0 Op ration supporte LA op ration support 0 4 concerne Dy oa Artefact c ncerne Type_artefact num ration D nomination texte Type_auteur lt type_r le gt Da statut num ration int fagit avec Activit activit num ration repr sente repr sent repr seni id 1 Objet d interaction Nom donn e texte donn e num ration Attributs texte Forme texte Figure 101 Repr sentation simplifi e du MMU bleu li au MMPM 1 33 Les mod les d usage rouge 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
13. File name deg 944 400 dm 30 dwg deg pi Save as type A Files 7 deg dds 400 dm 30 dw 779 36KB Copy of dog dds 400 779 36KB Liaison entre les documents O Les documents sont ind pendants Les document sont li es Pr c dent Suiv Tous les documents Fichierunique O NOM STANDARD vr iQ 12 Fichier ZI 44 ifi IM A APS 00 A 065 04 jpg Sy e 213 EG 00 1 001 01zip F vrier 2013 o V AY PL_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 impl 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 A 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 formalisme 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 p
14. 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 Document Acteur 1 U 1 1 1 I Il 1 I I t n Objet Acteur Artefact Acteur om i Relations Relations gt E j E Ns 89 7 12 9 oo WE ds E e Activit Activit Document Activit Outil H Hanser 2003 2 Bouattour 2005 3 Kubicki 2006 Figure 2 volution 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 fin
15. 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 Qui seul acteur T che utilisateur un type d utilisateur 465__ cr ationdur pertoired uploadd unprojet 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 un mail la suppression d un Oui Avertirles T che syst me de Meilleure compr hension gain de Ajouter 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 un utilisateur un type d utilisateur Cr ation d un SMTP local po
16. 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 taches 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 ceuvre 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 par 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 affic
17. 2 Nom STANDARD Date Avant Projet Sommaire Avant Projet D taill Juillet 2013 Autorisations ferais 7 ji PL_V_AUT_N1_BT_1_001_O1 xisx 12 07 2013 eer Sj LOT F APD N2 BT A 001 Dan 04 07 2013 Ex cution Avril 2013 PL AUT SN AL 1 001 02 pdf Mars 2013 ASB SO 029 01 png 29 03 2013 V jh PL V APD 1 a 154 01 png 29 03 2013 22 1 EXE U1 BT a 098 01 png 27 03 2013 gt Qi A PDE N1 00 A 547 01 pdf 27 03 2013 V V ASB U3 VI A 547 01 png 27 03 2013 H ASB U1 VI 1 123 02 PNG 27 03 2013 PL ASB EG DI A 123 01 PNG 27 03 2013 Pp Figure 11 Interface de CRTI weB service Documents eoo CRTI weB Service Compte rendus e 4 www crti web lu index php 58 2 CompteRendus viewRemarques idCR 11933 B Google Q 3 7 221 chantier d valuation pour le CRP HT_ Gestion de Compte rendu Nouveaut s Compte rendus f Annuaire j Recherche Rubriques _Class es par date de cr ation croissante v SES Liste des compte rendus gt Compte rendu n 4 gt Remarques gt ini G n ralit s N INTITUL RESPONSABLE S Prio Constar D rai Reeg Actions gt A ts Ari 1 4 1 Accord Loeginterin 2 24 01 2013 gt Remarques gt Agenda RAPPEL Accord pour les techniques sp ciales transmettre au plus t t Devis pour PDF 15 1 Genie Guring amp associ s 1 24 01
18. 7 Tableau 2 Les 15 services informatiques composant l outil CRTI weB BP Services 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 Doc1 Nommage de documents et convention de nommage Doc2 Mise jour Doc3 Notifications Doc4 Actions Doc5 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 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 11 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 rc pw SE KE Mes documents f Mes actions B Documents du projet f Coordination B Historique B Annuaire E Convention de nommage Tous les documents
19. 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 Figure 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 Figure 9 Utilisation du dispositif Bureau Virtuel Sketsha au cours du projet SDC photos tir es de Saffin amp Leclercq 2010 1 2 5 L adaptation 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 intenti
20. 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 iis N gociation de troite avecle client Accueil du Documentation changement Processuset outils Figure 27 Valeurs des m thodes agiles face aux concepts des m thodes classiques http www agilemanifesto org iso fr Chapitre 4 De l utilisateur la conception logicielle et d interfaces Plusieurs m thodes int grent ces notions 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 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 client 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
21. 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 et 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
22. num ration Type_r le num ration D nomination texte enumeration 7 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 x enumeration Type dispositif ordinateur 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 ouif non inconnu enumeration sortie audio oui non inconnu TYpe 0S Windows MacOS Linux WindowsPhone 5 autre clavier souris clavier touchpad cran tactile autrefinconnu Figure 99 Caract risation du contexte d usage On attribue un utilisateur un r le op rationnel 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
23. 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 des mod les coh rents assurant ainsi une certaine qualit du produit Quatre principes sont respecter 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 Genera requirements Functional Specifications Conceptual Requirements Specifications of Organizatona and Interactional cqui
24. 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 gr ce notre m thode et par une d finition des usages li s valuation de la pertinence Lorsqu un utilisateur ou un expert m tier propose un service tr s pr 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 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 valuation et
25. DIFFUSE DESIGN DOCUMENTS FOR DESIGNERS TEAM 22 1 isise 189 RE 105 MODELISATION DE LA RELATION AVEC D AUTRES USAGES eese 190 RE 106 LEGENDE DU DIAGRAMME D INTERACTIONS 191 RE 107 DIAGRAMME D INTERACTION DECOMPOSANT L INTENTION UPLOAD MULTIPLE FILES 192 RE 108 MAQUETTAGES DES TACHES CONCRETES LOADING VISUALIZATION ET CLUSTERING MODE SELECTION 5 5 dete dentes edunt eve Reeg e ted deae esee Eege eene EE 193 RE 109 TABLEAU DE SAISIE DES INFORMATIONS SUPPLEMENTAIRES DANS LE CAHIER D EXIGENCES 194 RE 110 LE CHOIX D UN USAGE ET SA 4 2 2 4 1241400000010000000000000000000000000000 195 RE 111 CORRESPONDANCE ENTRE LE DIAGRAMME DE PRATIQUES ET LES MODELES D USAGE DIAGRAMME DE CAS D UTILISATION D INTERACTIONS ET MAQUETTAGES eene 196 RE112 CARACTERISATION DU SERVICE CONCEPTS EN BLEU MATERIALISANT L USAGE CONCEPTS EN ROUGE 201 RE 113 RAPPEL LE MODELE CO MNWVQ enters S EEEE SEAE 202 RE 114 CARACTERISATION DU SERVICE ICT ET SES COMPOSANTS nee 203 RE115 VERSION SIMPLIFIEE DU META MODELE DES SERVICES ADAPTES MMSA COMPOSITION DU MMPM EN ROUGE DU MMU EN BLEU ET DU MMS EN VERT 205 RE 116 RAPPEL DIAGRAMME D INTERACTION DECOMPOSANT L INTENTION UPLOAD MULTIPLE FILES 207 RE 117 DIAGRAMME DE SEQUENCE MODELISANT LE SERVICE ICT DE TELECHARGEMENT DE DOCUMENTS VI
26. Dispositif dispositif num ration Type_OS num ration Type connexion oui non Type_contr leur num ration Type_entr e vid o oui non inconnu entr e audio oui non inconnu Type sortie vid o oui nonfinconnu Service m tier Type_sortie audio oui non inconnu texte description texte LII fournit Nom texte Type_famille num ration Description texte nom texte Donn e texte umm Er Mod le ex cute repr sente pe a T che outil Service ICT m 1 7860 L Mod le partag i oui non nom texte e Pratique Individuelle p technologie texte 5277 LL Nom texte z et vwe Description texte 2 ccl Cl 1 4 execute Concerne Type_artefact num ration D nomination texte Type_acteur num ration Type_auteur lt type_rdle gt Type r le num ration T 4 Type statut num ration D nomination texte repr sente Nom donn e texte S donn e num ration repr sente F ttributs texte Forme texte repr sente Figure 115 Version simplifi e du M ta Modele 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 Chapitre 11 La mod lisation des services le point de vue fonctio
27. 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 maitrise 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 Il 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 l 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 ot elles supporteraient des processus m tiers valides Ce travail d impl mentation implique deux exigences primordiales cibler des cas d utilisat
28. La mod lisation des usages le point de vue op rationnel Etope 1 S l ction du ou des fichiers Parcourir Fichier 1 E 35037 Fichier 3 E 5 5 5 eg Etape 2 Liaison multi fichiers M me document plusieurs fichiers 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 versions du cahier d exigences Ces informations additionnelles prennent la forme d un tableau dont les parties visent 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 p
29. 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 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 taches 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
30. _ Retrouver un document Contenu identification dela compr hension gain de Macc nee ne fichiers existants quand on change la CN au Contenu Changement du nom rendre nouveau disponible Meilleure ergonomie Cr er et partager des CR Modification du format rendu selon demande de l OAI Oui dechantier Contenu donn e temps pouvoir identifier les acteurs qui ont Identifier activit des Meilleure compr hension gain de acc d un compte rendu particulier i collaborateurs T che consult un temps Comptes rendus classer les acteurs _ identifier activit des_ T che classement des acteurs CR classer les remarques par priorit dans i Cr er un CR de chantier T che Classement des Meilleure compr hension gain de CR Pouvoir identifier rapidement les Identifier activit des Identifier remarques Meilleure compr hension gain de nouvelles remarques i collaborateurs T che depuis derni re temps Lors de l ajout d un niveau d historique Identifier les Identifier date de Meilleure compr hension gain de MaJ d une remarque il est n cessaire de i commentaires des contenu remarque 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
31. 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 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 Support des pratiques actuelles de travail sans forcer l interd pendance des acteurs au risque de r duire leur autonomie et leur flexibilit Agr gation de l information 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 acteur
32. 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 interface 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 b timent 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 Evaluation 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 manipul
33. 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 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 industrielle 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
34. 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 Digital 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 S GDOC 09 Bloomington Indiana ACM pp 1 8 Winckler M Palanque P amp CMDS 2004 Tasks and scenario
35. Cela inclut du plus simple mettre en ceuvre au plus compliqu ajout de choix dans une num ration ou le changement d une cardinalit ajout d un attribut une classe d 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 remarquer 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 fa
36. 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 les de t ches sous forme de diagrammes dits dynamiques tel que CTT cf 1 10 3 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 Chapitre 7 Les m thodes de conception de services tudes de cas gt lt g m if Vocal Note Situational Mesh Marker Augmented Expert dispi vison Wa E Figure 70 Description g n rale du contexte mat riel et des donn es 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 a Ensuite on d finit la correspondance translation entre les deux types d objets On parlera d analyse dynamique pour ce
37. List scenarios Text Scenario actions de decomposition Tous les matins le technicien S Actor er Rate 1 Rem Tasks Add Rem Deces Add Rem Scenario Graphe Ajout But ril Figure 65 Utilisation de CBME pour crire les sc narios contextualis s tir 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 H H d des pi ces Contacte 4 quelqu un Fait son 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 10 3 augment d une cat gorisation des taches
38. Pe IER AAEE FE Fe dE idees Da 200 11 3 Mod lisation des services et impl mentation eene 207 TLA t COMCIUSIOM HERE 211 ss Chapitre 12 La m thode PUSH exp rimentations et bilan n 213 12 1 Introduction aux exp rimentations iii 213 12 2 Exp rimentation n 1 L am lioration du service d upload de CRTI weB 217 12 3 Exp rimentation 2 l automatisation du service d upload de CRTI weB 227 12 4 Exp rimentation 3 sp cification d un tableau de bord 235 12 5 Conclusion apports des 241 Conclusion et perspectives eee cites erre ENEE e ener RENE ean aepo saa peek us oa co Ea AEN EEVEE ERE HE EU E eines 247 Concevoir une m thode de conception recul sur une approche orient e design science 247 Les limites de Tapproche iii 248 Betsch ONSE ERN EUR SR se noi 249 Sommaire Sommaire d taill e orario eon nep Error Bookmark not defined Biblio grap ite ee 257 Glossaire PITT OTIO TID TOI 273 Table d s illustrations 277 LES CR EE 277 Liste des tableaux ten 281 m
39. Y m 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 Ainsi 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 mode 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 28 http www eclipse org eclipse index php Chapitre 8 Introduction de la proposition organiser Gr ce au graphical def model nous avons exploit une s rie de param trages basiques mais qui r pondent 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
40. c demment savoir les documents et les objets Les ressources sont les acteurs responsables de ces activit s les outils ainsi que la connaissance utilis s 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 production d une nouvelle information la communication de personne personne diffusion d information 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 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 1 31 1 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
41. 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 lexiste enfin deux types de pr conditions optionnelles ou obligatoires 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 facon 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 LI 22 Hie Views Coton Check Scenanes X Actors GowScenarios Cl Comes artotacts worktow dip Tasks Overview
42. 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 un logiciel comprend non seulement sa conception mais aussi son valuation sa distribution et sa maintenance Tel que Booch et a
43. 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 organisationnel Chaque op ration devient paquet package de cas d utilisation use cases Les paquets des op rations sp cifier sont repr sent s dans le syst me et d compos s Le peut aussi contenir des paquets de cas d utilisation Paquet ne pas sp cifier 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 Operations m tiers quant eux situ s l ext rieur du syst me NE Cas suppl mentaires Le contexte 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 Lr 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
44. 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 facon 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 IDM 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 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 utile
45. e sur l ajustement mutuel Suivant nos premi res remarques ce contexte sert de base la caract risation 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 coll
46. 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 maitre d ceuvre se doit de prendre en compte les remarques des ex cutants en cas de modifications apporter aux plans d ex 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 Maitre d ceuvre Plans d ex cution T ches de construction Coordinateur Documents techniques d valuation et de Maitre d ouvrage et Planning coordination assistants CR de chantier Phase chantier Entreprises PC10 valuation de l ex cution et compte rendu Description l 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 san
47. 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 Maitre d ouvrage et Maitre d ceuvre 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 Maitre d ceuvre 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 Maitre 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 M
48. 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 t ches font parties des mod les adopt s par la communaut l utilisation des arbres hi rarchiques pour la description du m tier diff re quant 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 l
49. gt visualize clustering options r displayClustetingOptions 1 lt lt Output gt gt lt lt interaction task gt gt clustering mode selection 7 lt Ser gt gt jentOption selectoneDocut seq Naming Process lt lt Action gt gt requestUpload Filps lt cActionss sendriles Files lt lt action gt gt createZIP ZIP lt lt action gt gt createCRTIweBdocument document lt lt Action gt gt H creakeLinkDocumentZIP DocID ZiplD 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 cificit 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
50. 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 1 NFR Lapouchnian 2005 et les formalismes varient galement De mani re g n rale lorsqu on mod lise des buts il faut pouvoir distinguer les buts strat giques haut niveau d abstraction relatifs aux objectifs d
51. 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 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 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
52. 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 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 lautre reste une opportunit gr ce l approche par composition de m ta mod
53. level pi ce room l ment de 68 5 of artifacts L 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 Maitre d ouvrage owner Expert Constructeur constructor Coordinateur coordinator Administration Conseiller advisor A 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 s
54. 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 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 av
55. 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 similaires 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
56. n ration de l diteur partir du m ta mod le notamment grace un tableau de bord Figure 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 Be 1 Select Edit Create Select Edit Reload Select Edit Create Select Edit Create Generate diagram editor 2b Sp cification de l apparence de la palette d outils 4 G n ration de l diteur Figure 93 Letableau 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 plus approfondi il nous est possible de modifier sensiblement le m ta mod le et de r percuter ces changements sur l diteur
57. 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 avec 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 indi
58. 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 Figure 118 Exemple de note ajout e 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 concu 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 le 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 prototypag
59. rationnel sera exprim par les concepteurs 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 et des tableaux le maquettage d interfaces utilisateurs 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 taches 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 une 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 sp cifier 1 intention utilisateur Paquet sp cifier 2 intention utilisateur Paquet ne pas sp cifier Op ra
60. 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 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 SC Besoins LU activit Le projet g n raux d Buts 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 riqu
61. 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 technical solution view TSV qui correspond a une phase d analyse et conception logicielle assur e par les experts du g nie logiciel Generic Demain Mosel Existing 2 11 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 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 tier 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 hensi
62. 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 existants et les habitudes de chacun Enfin il a videmment t question travers les exp rimentations de valider la r ponse 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 5066 La conception de CRTI weB La m thode de conception suivie dans ce travail de th se gen R zen N on Les concepts et la m thode de conception de services propos s PARTIE 1 contexte d tude Etudes initiales le contexte tri facettes Pratiques Usages Services 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
63. 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 HM 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 SIGCHI 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 leee pp 375 384 Santos L Lopes J amp Leitao A 2012 Collaborative Digital Design When the architect meets 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 796 New York New York USA ACM Press Saikali 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 Tow
64. scroll arrow scroll cursor scroll bar frame Static OIA abel separ 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 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 li
65. 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 taches 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 mis 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 profes
66. 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 identifier ce qui est de l ordre de l action ou de la sous action au travers de tous les processus mis en ceuvre 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
67. 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 l offre de nouveaux produits et services plus complexes de par la collaboration de plusieurs compagnies am lioration et l expansion des moyens d atteindre le client proposition de nouveaux ordres de prix et de m canismes de revenus 23 http fr wikipedia org wiki Entreprise 22 http fr wikipedia org wiki Fordisme Chapitre 5 De l entreprise orient e services la conception de Systemes d Information Strat gie
68. 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 valuation 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 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 ment
69. 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 tragabilit 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 pour 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 5 d on maa MC A i K Ze Kescht N N 7 4 7 2 N x l x 11 Communication x Mod les Arbres hi rarchiques tableaux diagrammes M1 Pratiques E M1 Usages p M1 Service
70. 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 composants 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
71. 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 manual for AEC projects In CIB 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 794 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 softwar
72. 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 reste l activit de l informaticien cf 1 11 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 reche
73. Assist par Ordinateur et Services Collaboratifs M 105 6 1 Description des outils de TCAO et des services collaboranfs 105 6 1 1 Les dimensions fonctionnelles et spatio temporelles seen 105 6 1 2 Les types de services collaborantfs 106 6 1 3 Description fonctionnelle ss 107 6 2 Vers une r ponse l chec de la solution collecticiel sse 109 6 2 1 Les constats d chec usitate cei e p ER aad dataset 109 6 2 2 Les principes d un collecticiel adapt 110 6 2 3 Loose coupling et conception de services collaboratifs 110 6 3 Conclusion concevoir des services collaboratifs a 111 DEE Chapitre 7 Les m thodes de conception de services tudes de cas A 115 7 1 CoCSys une m thode de conception de collecticiels dirig e par des 115 7 1 1 D roulement de la m thode see 116 74 2 Analyse ele iic ener e Hr n e E e i eats 121 7 2 La m thode Symphony et les mod les pour la collaboranon 000 123 7 2 1 Symphony et symphony tendue 123 7 2 2 La branche fonctionnelle ss 125 7 2 3 La branche technique et la conception enn en enne 127 724 Analyse critique et conclusi n uite rto pee need tacts eae 127 7 3 L IDM Information Delivery Manual pour la conception de services
74. 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 tude de conception particuliers Il se conclut par l vocation des l ments majeurs retenus comme base
75. 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 avec 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 ICT 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 disposition d
76. 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 Remerciements Cette th se est le fruit de l engagement et la confiance de plusieurs personnes et instituts sans lesquels un jeune architecte fraichement 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
77. 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 l 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 forum 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 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 ot l on d finit au pr alable les actions qui seront men es p Aspect r actif
78. Documents 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 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 dans le p
79. ER PE Aspect pr dictif i ER B Supervision directe i Communication t 1 Flux RSS 1 I I l i Ch 1 Wiki i i j I 006 R alit Rroduction Te viriuete _ Gries e e I Tableau blanc I Partage d cran I I f rence I 1 Convefsation Ajustement mutuel I uu uuu ree See us mar uad eee A Figure 55 Positionnement des services par rapport aux caract ristiques d une activit collective Laaroussi 2007 et Guerriero 2009 1 16 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 co
80. 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 Sin fy iis pix e cran de configuration Liste de tests modifier 1 Statut du test imprimer Figure 38 Exemple de prototype abstrait 1 10 4 Constat et conclusion Les m thodes de conception IHM enrichissent la conception logicielle en interrogeant l utilisateur sur ses pr f rences et sur ses t ches afin d habiller les syst mes gr ce des interfaces adapt es Elles pr conisent ainsi l utilisabilit l 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 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 l utilisateur 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
81. 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 Universit 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 Twelfih IEEE International Wor
82. 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 ses futurs utilisateurs Nous pensons que l interaction peut avoir
83. 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 7 3 Voir aussi leur site internet http www service description com index htm Chapitre 5 De l entreprise orient e services la conception de Systemes d Information name Sirin SeniceRequester name String name String description String setvicePraviders honetituantGerices 1 1 MP cenie Property nanFunctienale descritpion String F ag location String Delegation Subcontracting Fang provide Capabillities 0 preconditions name Sting co E definition String Figure 45 M ta mod le du BSDL 2010 1 13 3 Le service informatique ICT En informatique un service est une fonctionnalit mise disposition par un composant logiciel pour assurer une tache 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
84. 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 A 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 Unshare Already supported by a service Already supported by a service Need service development Need service development Creates Uses Uses Targets Creates Targets Design documents produced by students Designer Plans models reports Others students of the group Designer Job Other Status In Progress Status To Modify Status Over Refers to TM Building project type No Certification i 75 university project gathenng groups of students from 2 different universites H 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
85. application enti rement ex cut es par le syst me ex la notification 1 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 tache 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 Un exemple d utilisation de CTTE pour la conception d interface est illustr Figure 34 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 SS Couche op rationnelle gt Ir ges fer e e 22 Qty Totalproduct Totalorder ok cancel gt gt 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 Baro
86. 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 Chapitre 9 La mod lisation des pratiques le point de vue organisationnel Tableau 22 l ments de caract risation de la PC11 Acteurs impliqu s Documents utilis s Activit s Maitre d oeuvre Posters T ches de coordination Maitre d ouvrage Articles Toutes phases Usagers R gles et normes Documents techniques 1 27 3 Enjeux dans l 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
87. base utiliser les moyens en personnel et mat riel mettre en cuvre le niveau du prix des prestations un d coupage en phase Le maitre 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 Documents administratifs T ches 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 Maitre 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 Maitrise 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 Maitrise d ceuvre lors de la conception de l ouvrage Lors de petits projets le Maitre d ouvrage peut n avoir que tr s peu d informations donner c est le Maitre d oeuvre qui fixe alors ces objectifs Chapitre 9 La mod lisation des pratiques le point de vue organis
88. 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 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 p
89. 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 Q enhancement of proficiency retention of learning J user convenience efficiency of interaction d accuracy of input reliability of interaction clarity of presentation user satisfaction 13 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 la 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 ou l activit est ici l interaction avec un syst me 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 e
90. 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 18 http www insee fr fr methodes default asp page definitions services htm Chapitre 5 De l entreprise orient e services la conception de Systemes d Information e 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 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
91. 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 CRAL 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 pour ses conseils avis s Je remercie tout particuli 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 un autre en fonction
92. composed of supported by a service Geometral D Group type Agency Plans du projet au stade APS Designer Author Desgner lt Add here more species if needed gt Status In Progress ADDITIONAL INFORMATION Do you want to add any information about the business context and the practice to perform Do you want to add any information about the informationto manage artifacts activities actors Figure 94 Formalisation de l analyse m tier combinaison d un modele 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 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 i
93. 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 e 5 3 226 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 francais Chapitre 8 Introduction 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
94. construction architecturale La fin de vie d un b timent 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 ceuvre des travaux de requalification ou sa d molition Le concept de tache 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 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 51 coordination est c
95. d avis partag s Se pose aussi la question de la visibilit des r actions vis 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 l outil 1 5 3 Analyse du d veloppement 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 143 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 conceptio
96. de Syst mes d Information 5 1 L entreprise orient e service 5 2 De la mod lisation des Processus M tier au Syst me d Information 96 5 3 Conclusion vers des services adapt s aux pratiques m tiers a 103 M Chapitre 6 Travail Collaboratif Assist par Ordinateur et Services Collaboratifs 105 6 1 Description des outils de TCAO et des services collaboratifs 105 6 2 Vers une r ponse l chec de la solution collecticiel na 109 Sommaire H Chapitre 7 Les m thodes de conception de services tudes de cas M 115 7 1 CoCSys une m thode de conception de collecticiels dirig e par des mode les 115 7 2 La m thode Symphony et les mod les pour la 123 7 3 L IDM Information Delivery Manual pour la conception de services BIM 129 7 4 Conclusion et mise en place de la m thode 134 PARTIE 3 GUIDER LA CONCEPTION DE SERVICES COLLABORATIFS ADAPTES AU SECTEUR DE LA CONSTRUCTION ETUDES PROPOSITIONS ET PERSPECTIVES E 137 EUER Chapitre 8 Introduction de la proposition 139 8 1 Enjeux de laim
97. 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 M1 Pratiques M1 Usages sz 79 ES d t Litt rature Litt rature Litt rature Figure 78 Processus de m ta mod lisation partir de l analyse de cas et de la 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 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 business solution view BSV
98. 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 ira technology Device 8 Choose 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 about 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 E RELATED USAGES You can specify the link between the usage you described and others space ick here to Click here to enter text Choose an item Choose an nter text item enter text item er text item nter text item nter text item
99. 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 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 pr
100. 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 maitrise 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 oeuvre formule une r ponse architecturale technique et conomique la demande du maitre 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 travaux 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 concu 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
101. 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 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 7 2 Ce chapitre d taille trois m thodes de conception dont nous avons pu faire ressortir les avantages et limites Il 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 ca
102. e et sortie Ils sont d finis par une action effectu e et une donn e 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 r le op texte 13 Identification oui non 21 repr sente action texte donn e texte 1 1 Nom donn e texte Interaction donn e num ration 1 ttributs texte EL Forme texte LZ T che utilisateur concr te 1 int ragit avec 0 Tache utilisateur abstraite Been El 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 ICT 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 le
103. 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 none rr 7 Style Bold Underlined Outlined A Underlined pn O Out lined Underlined 1 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 l impl mentation de la solution en fonction de l environnement Enfin les Chapitre 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
104. es ou d centralis es d une part et la mise en place de pratiques collectives maitris 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 processus 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
105. 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 CR5 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 CR8 Rechercher les remarques en cas de litige 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 Maitriser 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 d
106. 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 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 tho
107. gt plans valuer 4 ipule lt lt iffuusion gt gt p engend partage lt lt communication gt gt y peu wf lt lt production gt gt avertit lt lt gt gt requ te d valuation Pratique Individuele gt gt Analyse le rapport et le valide r cup ration gt obtient manipule lt lt document gt gt rapport d valuation n lt lt message gt gt 4A validation Figure 91 Instanciation du MMPM par 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
108. 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 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 surbase du cahierd exigences D veloppements en cours Discussion surbase du cahierd exigences Gestion des cas d chec 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 conception 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
109. 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 notification upload multiple files 15 composed of me Jp then _ upload files in one CRTI weB document fiy T E 24 Choose files and clustering mode stract us Select 1s compose of 1s composed of Abstract user nteracton type Selection 1 n me OT koc ei i name crti web document rotation identification Di e Concrete user interactin type Trigger SP h v e Interact witt N t user interaction type Input Gatki opu _ 8 selection IO Name Documents e Interact wit Concrete
110. 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 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 une conventi
111. 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 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
112. 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 e 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 e 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 Figure 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
113. lier la description d un usage celle de la pratique qu il m diatise 1 34 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 22 http french stackexchange com questions 722 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 quoi il
114. 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 Butdu 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 grace 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 avoir 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 Acronymes et 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 comp
115. lors de 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 tiers 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 lisation notamment au
116. 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 taches d interaction peut paraitre 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 EP validation des choix conceptuels Famly 5 Desgn and reporting Les concepteurs d ffusent leur proposition aupr s des maires d ouvrage qu l valuent mm emm emm P Correspondances entre les mod les P d ts composed of compo sd Add here more speatives ff needed gt Status In Progress Designer choose files and clustering mode Abstract user interaction type Selecbon 1 n cow dom name crti web document Gi Concrete user interactin type Trigge
117. n utilisent des documents rendus obsol tes par des mises jour But Strat gique Bonne ex cution du chantier But de type SE Documents d ex cution atteindre 1 1 prisen compte par 1 l entreprise But de type mainte Enterprise avertie de 1 1 chaque nouveau 1 A A 1 Entreprise avertie de 1 l obsolescence 1 Figure 21 Exemple diagramme de buts Les sc narios sont la repr sentation du monde r el Les m thodes bas es sur les sc narios 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 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
118. 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 projet 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 a 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
119. 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 notre 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 1 24 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 Le M ta Mod le 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
120. outil Conclusion et perspectives Table des mati res Liste des abr viations et 15 Introduction C 17 Une th se la crois e des chemins entre sciences de l architecture et g nie logiciel 18 Probl m tique p n rale m 18 Conceptualiser les m thodes de OT 18 Conceptualiser les pratiques architecturales essen enne nenne 19 Proposer des services informatiques pour le secteur 19 Plan dela th se oo ERREUR USER REINES RM MIU eee 20 Partie 1 assister la collaboration dans les projets de construction 20 Partie 2 th ories et m thodes concevoir des services collaboratifs 20 Partie 3 guider la conception de services collaboratifs adapt s au secteur de la construction 20 PARTIE 1 ASSISTER LA COLLABORATION DANS LES PROJETS DE CONSTRUCTION DEFINITION D UNE PROBLEMATIQUE ET RECUL MEE Chapitre 1 La coordination dans les projets de conception construction architecturale 23 1 1 La caract risation du secteur dans les travaux pr c dents 23 1 1 1 Lesacteurs et leur caract risation eese ette tenete tr teeth tenir neta 24 1 12 eege arts et l
121. 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 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 re
122. pouvant tre utilis s par ment par plusieurs entit s a Wieringa 1998 d finit un syst me 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 Description du service Registre de services Trouver Publier Client du sevice 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
123. 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 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 re s est d roul e en f vrier 2012
124. 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 quengage 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 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 correspon
125. 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 maitrise 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 M hi rarchiques et des d cisions non centralis es particuli rement en phase chantier un s quengage du projet bas sur des prises de d cision sur le tas mais pourtant d terminantes et parfois irr versibles des interactions 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 expl
126. 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 quences 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 gat 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 SEN 212 a n Lf 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 conceptio
127. rationnel operationnal role c d son r le vis vis du syst me ex administrateur utilisateur 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 syst me d exploitation OS Windows macOS linux android 105 WindowsPhone Le type de dispositif d interaction interaction device clavier keyboard souris mouse pav tactile touchpad cran tactile touchscreen 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 conten
128. relative au tr fle fonctionnel les taches 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 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 d
129. retards les malfagons 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 architectes 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
130. 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 l utilisateur la conception logicielle et d interfaces Couts cumulatifs Progression 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 Concept d op rations Planification du d veloppement l Validation des Exigences Planification de l int gration et des tests Validation et v rification de la Conception Int gration et Test Impi mentation Planification des phases suivantes Figure 18 Sch ma de la m thode en spirale 1 9 2 Vers un 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 Unified Software Development Process puis le
131. 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 mod 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 incluon
132. 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 grace 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 de la 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 qui visent expliquer des l m
133. 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 chaque fois 0 des g n ralisations les fils et les filles sont des enfants 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
134. 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 boite blanche On parle ici de d composition fonctionnelle Syst me Syst me boite noire boite blanche EH E 1 Entr e i 2 Entr e i i 13 Ev nement interne 1 5 Activit du syst me 1 b 4 Ev nement interne 2 EU A H 16 Ev nement interne 3 GEES H 7 Sortie 8 Sortie 1 Diagramme 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 t
135. 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 tiers qui sont support s par des services informatiques ICT 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 Partie Entreprise production de Partie Client consommation de biens de services biens owet de services Objectifs production Objectifs vente et productivit gain satisfaction du client Supportent Supportent Business MODEL Services m tiers orchestr s 2 51 Conception Orient e en processus Services focus sur le rendement Supportent G nie Logiciel RUP agilit focus sur les Services web IT m thodes de d veloppement Utilise S IHM Conception Personnel Centr e Utilisateurfusage focus sur l utilisabilit et l adaptabilit Ressources 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 sys
136. thiode se eda als 139 8 2 M thodologie ne ts yr a 141 8 3 La m thode PUSH Practice and Usage based Service 147 8 4 151 M Chapitre 9 La mod lisation des pratiques le point de vue organisationnel 153 9 1 D finitions t concepts su eiie reete tni in Ene Erro ba gua rr ER anres Een 153 9 2 Le M ta Mod le des Pratiques M tier 162 9 3 Le modele de pratiques ee cono ere re HERE RUE LO RU RU OR OI GR DRE 169 9 4 COMGIUSION e M 174 Chapitre 10 La mod lisation des usages le point de vue op rationnel 177 10 1 D finition et concepts iii 177 10 2 Le m ta m od le des Usages sco eer c a o 179 10 3 Les mod les WEE 187 EE e ele ELL MEET 194 Chapitre 11 La mod lisation des services le point de vue fonctionnel M 199 111 D finitions EL CONCEPTS eter a i A re cd C Re e erp a died 199 11 2 M ta mode le d service ruine eerta chr red eng De a de
137. 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 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
138. traiter ces deux concepts distinctement Je 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 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 action Pourtant ces diff rents termes se rapportent 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
139. 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 0 6025 69 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 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 riser ces concepts et les formalismes utilis s pour les d crire sont issus des domaines du G nie Logiciel et de la conception Nous verrons comment nous adaptons ces formalismes pour
140. 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 ga survoler un panel d exp rimentations plus tendu tendre les exp rimentations permettra galement d valuer l appropriation d une telle approche par 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
141. 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 grace un langage nomm WSDL Web Service Description Language et stock dans les serveurs du fournisseur puis publi dans un registre UDDI Figure 47 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 ve
142. un client une capacit technique ou intellectuelle pour supporter un besoin Nous distinguons deux types de services les services m tier et les services 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 l 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 n
143. 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 collective voir 1 28 2 Le framework GMF pr sent en 1 24 2 propose des fonctionnalit s qui assistent la g
144. 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 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 S 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 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 Figure 7 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 nouveaux travail objectifs Figure 7 Processus de concep
145. user interactn type Selection Graphical spec loon label progress bars d EES IO Name Document name Attributes Nsme type G Loading Data type fle Graphical spec text fields and combo boxes Graphical output Attributes pnmtve data Data type text Ime N a E mode selection T din Concrete user interactin type Trigger Ge 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 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 d un syst me 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
146. veloppement d une SOA on retrouve cette distinction travers deux aspects Kohlmann amp Alt 2007 l aspect m tier avec la mod lisation des services m tiers orchestr s en processus Arsanjani 2004 l 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 suivent 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
147. 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 fonctionnalit 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 compone
148. 2013 Compte rendu Draft Test Un syst me de serrure est pr voir pour l ensemble du batiment Des offres de prix seront demand es 16 P incid Exim amp ass 3 03 01 2013 ee Raccordement gaz eau visites seront effectu es aux services concern s pour demande de finalisation expresse Plan d tection P p 2A fie Exim amp ass 2 10 01 2013 y Ra Plan d tection approuver Localisation 212 2 commande amp ass 24 01 2013 15 amp stores 8 Filtrer R initiatiser 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 a
149. 26 1 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 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 practitioner select Canadian Conference on Electrical and Computer Engineering 2005 May 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 39 59 Noran 2000 Business modelling UML vs
150. 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 oeuvre du b timent 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 2011 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 Con
151. 44 4 pp 653 668 Clot Y 2007 De l analyse des pratiques au d veloppement des m tiers ducation et didactique 1 1 Cockburn A 2000 Writing Effective Use Cases Addison Wesley Professional Cockburn amp Jones S 1995 Four principles of groupware design Interacting with Computers 7 2 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 Systems 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 Lockwood 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 Information Systems Design Speci
152. 9 tm wh Cente wer types Topper 4 Jn ce tias W with C upload files in one CRTI weB document dp Zi 10 Name Cocuments tach types F3 te 4 Graphical spec icon label progress bars headbox Geneve aw erecta type Sen Dans flood Data type He 710 Name Document name He 12 22 D I ee Une Figure 116 Rappel Diagramme d interaction d composant l intention upload multiple files Les t ches 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 copie 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 ass
153. 9 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 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 FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU RE 1 CONCEPTUALISATION D UN PROJET DE CONCEPTION ARCHITECTURALE POUR LA SPECIFICATION D UN PROJET DE CONCEPTI
154. A L OUTIL CRTI WEB SERVICE METIER DOCUMENT ener 208 RE 118 EXEMPLE DE NOTE AJOUTEE A UNE INPUT DANS UN DIAGRAMME DE SEQUENCES MODELISANT UN SERVICE sseeeeseenneesneeeensneeesnnneeessneeeeneneeessnneee essences enneneessnneeeenneee 209 RE 119 ILLUSTRATION DU SERVICE DE TELECHARGEMENT MULTI FICHIER UNE FOIS IMPLEMENTE 210 RE 120 REPRESENTATION CONCEPTUELLE DU LIEN ENTRE LES POINTS DE VUE sus 213 RE 121 LES MODELES ET LEURS 4 4 02 200002 24000 110000000 entere enter ener niens 215 RE 122 LE CONTEXTE DE PROJET DE DEVELOPPEMENT LORS DE LA PREMIERE EXPERIMENTATION 216 RE 123 REPARTITION DES EXPERIMENTATIONS DANS LE TEMPS RE 124 DEROULEMENT DE L EXPERIMENTATION cerner RE 125 LES PRATIQUES DE PARTAGE D UN CONCEPTEUR RE 126 DELA PRATIQUE A L USAGE VARIATION DES INTENTIONS D UN UTILISATEUR EN FONCTION DU BESOIN E 221 RE 127 UNE PARTIE DU CONTEXTUAL USE CASE SPECIFIE POUR LE PARTAGE D UN PLAN DWG ET SES XREFS TROISIEME USAGE RE 128 RAPPEL LE SERVICE D UPLOAD MULTIPLE DEVELOPPE RE 129 RAPPEL RELATION ENTRE LES CONCEPTS D USAGE ET DE PRATIQUE TELLE QUE CARACTERISEE PAR LE MMU sess ener 226 RE 130 DEROULEMENT DE suisses 228 RE 131 DIAGRAMME DE LA PRATIQUE ANALYSEE 229 RE 132 CONTEXTU
155. AI 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 conception de CRTI weB La m thode de conception suivie dans ce travail de th se 7 Connaissance Suggestion D veloppement PI Evaluation Conclusion J PARTIE 1 contexte d tude Etudes initiales le contexte tri facettes Les concepts et la m thode de conception de services propos s PARTIE 3 proposition Cas d tudes Exp rimentations Figure 77 Parties de la recherche support es par le contexte d tude Les besoins d adaptat
156. AL USE CASE DU SERVICE D UPLOAD AUTOMATIQUE suisse 231 RE 133 DIAGRAMMES D INTERACTION POUR LES INTENTIONS S IDENTIFIE ET PARTAGE LES FICHIERS DEPUIS UN DOSSIER PARTAGE me 232 RE 134 PARTIE DU DIAGRAMME DE SEQUENCE SPECIFIANT LE SERVICE see 233 RE 135 ILLUSTRATION DU RESULTAT OBTENU AU NIVEAU DE L INTERFACE PAR RAPPORT AUX EE XIG BINGE RS 234 RE 136 DEROULEMENT DE L EXPERIMENTATION 01 0 236 Table des illustrations FIGURE 137 PROPOSITION D UN NOUVEL OUTIL SUR LA BASE DE MAQUETTAGES TIRE DE GUERRIERO ET AL 2012 237 FIGURE 138 DIAGRAMME DE LA PRATIQUE DE SURVEILLANCE DU CHANTIER 238 FIGURE 139 EXTRAIT DU CONTEXTUAL USE CASE POUR L USAGE DU TABLEAU DE BORD NIVEAU OUVRAGE 239 FIGURE 140 DIAGRAMME D INTERACTIONS POUR AJOUT DE REMARQUES eere 240 FIGURE 141 COLLABORATION POUR LA CONCEPTION DE SERVICES AUTOUR DE LA PRODUCTION DE MODELES 242 FIGURE 142 RAPPEL STRUCTURE DE NOTRE RECHERCHE BASEE SUR LA 248 FIGURE 143 GRILLE D ANALYSE DES TICKETS PARTIE 1 4 284 FIGURE 144 GRILLE D ANALYSE DES TICKETS PARTIE 2 4 285 FIGURE 145 GRILLE D ANALYSE DES TICKETS PARTIE 3 AL 286 FIGURE 146 GRILLE D ANALYSE DES TICKETS PARTIE 4 4 287 Liste des tableaux TABLEAU 1 BESOINS METIERS A OUTILLER ET BONNES PRATIQUES LIERS cessere 38 TA
157. BLEAU 2 LES 15 SERVICES INFORMATIQUES COMPOSANT L OUTIL CRTI WEB eee 40 TABLEAU 3 ACTIVITES DE RE TYPE DE BUTS LES SUPPORTANT sus 60 TABLEAU 4 DIFFERENCES MAJEURES ENTRE CC UTILISATEUR ET CC USAGE CONSTANTINE 2003 71 TABLEAU 5 IMPLICATION DE L ACTEUR EN TANT QUE CLIENT ET UTILISATEUR TABLEAU 6 NIVEAU ET PORTEE DES TACHES SELON WINCKLER2004 cesses TABLEAU 7 L ENSEMBLE DES AIO REPARTIS EN 6 FAMILLES eee TABLEAU 8 LES DIAGRAMMES UML ET LEUR POTENTIEL DE MODELISATION DU METIER CESARE amp LYCETT 2003 100 TABLEAU 9 RESUME DES APPROCHES DE CONCEPTION BASEE SUR LE CONCEPT DE LOOSE COUPLING 111 TABLEAU 10 AVANTAGES ET LIMITES DES CHAMPS ETUDIES suisses seen TABLEAU 11 NOTRE APPROCHE PAR RAPPORT AUX CONCEPTS DE LA THEORIE DE L ACTIVITE TABLEAU 12 ELEMENTS DE CARACTERISATION DE LA PCI 0000 TABLEAU 13 ELEMENTS DE CARACTERISATION DE LA PC2 ss TABLEAU 14 ELEMENTS DE CARACTERISATION DE LA TABLEAU 15 ELEMENTS DE CARACTERISATION DE LA PC4 ss TABLEAU 16 ELEMENTS DE CARACTERISATION DE LA PC5 TABLEAU 17 ELEMENTS DE CARACTERISATION DE LA PC6 TABLEAU 18 ELEMENTS DE CARACTERISATION DE LA DCH TABLEAU 19 ELEMENTS DE CARACTERISATION DE LA TABLEAU 20 ELEMENTS DE CARACTERISATION DE LA DCH TABLEAU 21 ELEMENTS DE CARACTERISATION 0 TABLEAU 22 ELEMENTS DE CARACTERISATION DE LA PC11 TABLEAU 23 EXEMPLES
158. C UR T ER teste Ee ai 153 9 1 1 Les pratiques un nouveau d coupage de l activit de projet 153 9 1 2 Les familles de pratiques ou pratiques collectives g n riques 155 9 1 3 Enjeux dans l instrumentation des pratiques m tiers et approches de mod lisation 162 9 2 Le M ta Mod le des Pratiques M tier 162 9 2 1 Les pratiques collectives iei iere nette erii ee Fe e 162 9 2 2 Les pratiques individuelles et les op rations m tiers 165 COMMISION S ror eO eere dabit 168 9 3 Eeanodele de pratiques teh proe eripe e tds rt irit 169 9 3 1 Critique d un formalisme 169 9 32 L dit uret les modeles g n r s s eei reci e ee 171 9 3 3 Int gration dans le cahier d exigences 173 9 4 IM M MEE 174 10 1 D finition et concepts sise 177 10 1 1 Usage et utilisation nie cincti eer P re n e 177 10 1 2 Caract ris tion de l sage iui ie eee teens mineur 178 10 2 Le m ta mod le des Usages ss 179 10 2 1 E interaction eom Grub te Ee tnim 179 10 2 2 Le contenu d interaction eoe RUE ICH RHEINE ERE HARE BER SEE 181 10 2 3 L contextedl EE 183 10 2 4 Conclusion le m ta mod le d usage 186 10 3 Les mod les d usage sisi 187 10 3 1 Le diagramme de cas d utilis
159. 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 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 thod
160. 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 Tache Sauvegader des CN 444 convention de nommage Contenu 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 Tache Ajout d organismes 447 d un projet pas possible dans la partie Contenu e 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 Pontes Suppression 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 limit d utilisateur 451 cr s uniquement par l administrateur gestion men es par un T che d utilisateurs limit un type d utilisateu
161. DE DONNEES ET D ASSOCIATION DE FORMES TABLEAU 24 EVALUATIONS ATTENDUES EN FONCTION DES EXPERIMENTATIONS suis TABLEAU 25 APPORTS DES DIFFERENTES EXPERIMENTATIONS Table des illustrations Table des illustrations Annexes Analyse des tickets de conception de CRTI weB L analyse voqu e au 1 5 3 avait pour but d valuer le nombre de d veloppements sur les services CRTI weB en rapport avec un besoin m tier 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 E Quelle am lioration dans Y a t il une pratique m tier Quelle modification dans l utilisabilit Quel ger de la fonctionnalit Po Ouw no aqellee gmccu tal Partager des groupes de Plus de confort dans l upload gain Chargement des fichiers en arriere plan i documents diff rents G n rale Usage plus rapide de temps D sactiver onglet d archivage G n rale Usage supprim Pas d onglet inutile superflu Etre averti des Modification de la Journalisation des courriels de notification Oui op rations de ses G n rale r gularit Mails moins dispers s Ajouterdate de d p t de l indice
162. E DE NOTRE RECHERCHE BASEE SUR LA CONCEPTION RE 17 STRUCTURE DES METHODES TRADITIONNELLES DE CONCEPTION LOGICIELLE RE 18 SCHEMA DE LA METHODE EN RE 19 PROCESSUS CYCLES PHASES ET ACTIVITES D UN PROJET DE DEVELOPPEMENT LOGICIEL 58 Table des illustrations FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU RE20 EXEMPLE DE MODELE METIER SOUS FORME DE DIAGRAMME E R RE21 EXEMPLE DE DIAGRAMME DE BUTS sise RE22 EXEMPLE DE DIAGRAMME UML DE CAS D UTILISATION RE 23 EXEMPLE DE DIAGRAMME DE SEQUENCE SNSTEME emen nennen nennen RE24 REPRESENTATION DES EVENEMENTS INTERNES AU SYSTEME PAR UN DIAGRAMME DE SEQUENCE TECHNIOUE Ee 63 RE25 EXEMPLE DE REPRESENTATION D UN CONCEPT METIER EN ELEMENT DE MODELE STRUCTUREL 64 26 SCHEMA D UNE ARCHITECTURE LOGICIELLE REPRESENTEE PAR LE MODELE MVC 65 RE27 VALEURS DES METHODES AGILES FACE AUX CONCEPTS DES METHODES CLASSIQUES 66 RE28 CYCLE DE DEVELOPPEMENT DANS LA METHODE AP 67 RE29 PROCESSUS DE LA METHODE SCHUMAN 68 RE 30 LE PROCESSUS DE CONCEPTION EN V REPRIS PAR LAURILLAU 2002 70 RE31 MODELISATION D UN ROLE UTILISATEUR DANS
163. Element Element Element Element 1 t lt lt stereotype gt gt 2 lt gt gt Relation Artefact Artefact BEZUWeepe Relation Acteur Artefact Element Relation Outil Artefact lt lt lt gt gt stereotype gt gt Relation Artefact Acteur EN Artefact mm Relation Artefact Outil Element Element Element lt stereotype gt gt stereotype gt gt Document Objet Element Element lt lt stereotype gt gt stereotype gt GroupeDocuments DocumentUnique Element Element L gende Classe primaire Classe secondaire Relation Figure 3 Extrait du m ta mod 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 sont 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 visualis
164. 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 chapitre 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 l
165. 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 JBM systems 41 2 Greenberg S 1991 Personalizable groupware Accommodating individual roles and group 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 DESRI
166. FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU RE61 REPRESENTATION DES CONTEXTES GEOGRAPHIQUE ET TEMPOREL DANS RE62 REPRESENTATION DE L ARTEFACT DU DISPOSITIF ET DU SYSTEME DANS RE63 REPRESENTATIONS DES RELATIONS DU SCENARIO CONTEXTUALISE DANS RE64 REPRESENTATION DES DEUX TYPES DE PRE CONDITION DU SCENARIO CONTEXTUALISE DANS CBME 118 RE65 UTILISATION DE CBME POUR ECRIRE LES SCENARIOS CONTEXTUALISES TIRE DE INS ERR UH E 118 RE 66 EXEMPLE DE REPRESENTATION DE TROIS PROCESSUS ALTERNATIFS ENCADRES COLORES AVEC LE FORMALISME amp 2FLOW eege eiecit tasas ti tes periit Wi nes Rc rpers EEN 119 RE 67 MIGRATION DES SERVICES VERS LE DISPOSITIF eee 121 RE68 CYCLE DE SYMPHONY ETENDUE urnes rreneeeeneeeeeseneeeensene conne eeneneeeeneneeeeenneeeneneeeenenee 124 RE 69 PROTOTYPAGE DE L IDENTIFICATION D UN DEGAT A TRAVERS UN SYSTEME DE REALITE MIXTE 125 RE 70 DESCRIPTION GENERALE DU CONTEXTE MATERIEL ET DES DONNEES A TRAITER AVEC LE FORMALISME ASUR tx ect Rae exei gege eenegen 126 RE71 L ARCHITECTURE SYMPHONY TIRE DE S DUPUY CHESSA 2011 127 RE 72 INTERVENTION DES DIFFERENTS ACTEURS DE LA METHODE SYMPHONY AU COURS DE LA SPECIFICATION DES BESOINS ISSU DE S DUPUY CHESSA 2011 129 RE 73 VUE D ENSEMBLE D UN PROCESSUS BERARD amp KARLSHOEJ 2012 131 74 CAS D UT
167. ILISATION DU PRODUIT VIRTUEL BERARD amp KARLSHOEJ 2012 131 RE75 VUE D ENSEMBLE DES ETAPES POUR LE DEPLOIEMENT DE SOLUTIONS BASEES SUR L IFC ADAPTE DE HIETANEN 2006 132 RE 76 CONSTRUCTION DE NOTRE METHODE EN FONCTIONS DES APPROCHES ANALYSEES LEURS APPORTS RESPECTIFS s 5rd nip te m rd DP 135 RE 77 PARTIES DE LA RECHERCHE SUPPORTEES PAR LE CONTEXTE D ETUDE 141 RE 78 PROCESSUS DE META MODELISATION A PARTIR DE L ANALYSE DE CAS ET DE LA LITTERATURE DANS DIFFERENTS DOMAINES oov eere 666 656666 66 6666660 66 66 66 6606666 66 nEn ei or esn RE79 LEPROCESSUS DE LA METHODE DEST2CO TIRE DE ZIGNALE ET AL 2011 RE 80 EXEMPLE DE DIAGRAMME DE CLASSES UML CARACTERISANT UNE FAMILLE ete 144 RE81 EXEMPLE D INSTANCIATION D UNE CLASSE DE META MODELE AVEC L EDITEUR EME 145 RE 82 PROCESSUS DE GENERATION D UN EDITEUR DE MODELES AVEC GMF eee RE 83 UNE METHODE DIRIGEE PAR LES MODELES ET FAVORISANT L INNOVATION RE 84 REPRESENTATION ABSTRAITE DE LA METHODE PUSH eee RE 85 GENERATION DU CAHIER D EXIGENCES A PARTIR DES MODELES CREES RE 86 DECOUPAGE EN PHASES ET SOUS PHASES D UN PROJET Al 87 META MODELE DE LA PRATIQUE COLLECTIVE MMPC sese RE 88 META MODELE DE LA PRATIQUE INDIVIDUELLE MM PI eene RE 89 META MODELE COMPLET DES PRATIQUES METIERS MMPM
168. LA CONCEPTION CENTREE USAGE TIRE DE L L CONSTANTINE 2006 74 32 CIO SIMILAIRES DANS DIFFERENTS ENVIRONNEMENTALE 75 33 DIFFERENTES REPRESENTATIONS GRAPHIQUES POUR LA DECOMPOSITION D UN USE CASE TI RE 34 EXEMPLE D ARBRE DE TACHES CTTE DANS PRIBEANU 20051 79 35 LES CINQ TYPES DE TACHES QUI COMPOSENT UN ARBRE K MAD sse 79 RE36 EXEMPLE DE MAQUETTAGE OUTIL BALSAMIQ MOCKUP 37 ET ELEMENTS D INTERACTION ABSTRAITS 38 EXEMPLE DE PROTOTYPE 5 RE 39 ESPACES TECHNIQUES DE L IDM ET NIVEAUX DE MODELISATION seen 83 RE 40 ILLUSTRATION DES TRANSFORMATIONS ENTRE MODELES DANS LE CAS D ETUDE DE SOTTET ET 84 RE41 LES MODELES ET LEUR TRANSFORMATION DANS L APPROCHE MDA DE KALNINS ET AL 2010 86 RE42 POINTS D ENTREE DE LA CONCEPTION LOGICIELLE AU COURS DE L EVOLUTION DES METHODES 87 43 LE CYCLE DE VIE DE DEVELOPPEMENT D UN SERVICE TIRE DE BIRNBAUM 2004 90 RE 44 SERVICES METIER ET ICT DANS LA SOA nier RE45 META MODELE DU BSDL LE 2010 RE 46 ROLES ET INTERACTIONS DANS UNE SOA TIRE DE ENDREI2004 RE47 ROLES ET INTERACTIONS DANS UNE ARCHITECTURE DE SERVICES WEB RE 48 CORRELATION ENTRE BUSINESS MODEL ENVIRONNEMENT STRATEGIE PROCESS
169. OE 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 leur technique mod les 3D Phase conception de Ma tre d ouvrage et Documents techniques l esquisse l envoi des GE documents pour assistants Documents administratifs mp 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 Maitre d ceuvre 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 cess
170. ON LOGICIELLE users eeeeeee rennen essence nennen nene sr erret rennen rennen 19 RE2 EVOLUTION DES CONCEPTS DU CONTEXTE DE L ACTIVITE COLLECTIVE DE 2003 A 2006 ISSU DE GUERRERO 2009 Eee 28 RE3 EXTRAIT DU META MODELE DU CONTEXTE DE L ACTIVITE COLLECTIVE ISSU DE GUERRIERO 2009 28 RE4 DISTINCTION ENTRE COORDINATION HIERARCHIQUE ADHOCRATIQUE ET TRANSVERSALE TIRE DE KUBICKI 2006 T 30 RES CARACTERISATION DES ACTIVITES DE COORDINATION DANS UN PROJET AIC ADAPTE DE KUBICKI 2006 31 RE6 EXEMPLE DE DIAGRAMME DE GANTT is 32 RE7 PROCESSUS DE CONCEPTION ALTERNANT CONCEPTION DISTRIBUEE ET POINTS DE SYNTHESE TIRE DE HANSER 2003 E RE 8 FONCTIONNALITES COLLABORATIVES DANS L OUTIL DE CAO AUTOCAD REY UTILISATION DU DISPOSITIF BUREAU VIRTUEL SKETSHA AU COURS DU PROJET SDC PHOTOS TIREES DE SAFFIN amp LECLERCQ 2010 RE 10 LE CONTEXTE TRI FACETTES SELON KUBICKI 2006 RE 11 INTERFACE DE CRTI WEB SERVICE DOCUMENTS is RE 12 INTERFACE DE CRT WEB SERVICE COMPTES RENDUS RE 13 VERS DES OUTILS DE TCAO ADAPTES AU CONTEXTE TRI FACETTES RE 14 SCHEMA DU PROCESSUS DE CONCEPTION DEVELOPPEMENT ET TRANSFERT DES SERVICES DE EE 45 RE 15 PROCESSUS DE CONCEPTION FLUX DE CONNAISSANCE ET RESULTATS TIRE DE VAISHNAVI amp KUECHLDER EE RE 16 STRUCTUR
171. PIM est le point de vue du Concepteur qui mod lise le syst me Le PSM et l ISM le code sont le point de vue du D veloppeur qui mod lise la solution technologique et la d veloppe Abstractions Columns The Zachman FUNCTION NETWORK MOTIVATION Framework How Where Why Process Location Motivation List of things j List of Business important to the business Business Process Master Schedule BUSINESS MODEL Mods Sytem Conceptual Owner Computation Independent Model CIM Logical Dats Model Processing Structure Business Rule Model SYSTEM MODEL Architecture Architecture Logical Platform Indeperjdent Model PIM TECHNOLOGY Architecture Maer b orm Specifit Model PSM REPRESENTATIONS Out of Context Sub Contractor 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 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 abstract
172. 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 une ou plusieurs activit s dont les principales sont les suivantes voir Figure 19 la mod lisation du m tier la d finit
173. ST 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 19 26 Grudin J 1988 Why CSCW applications fail problems the design and evaluation of organization of organizational interfaces Proceedings of the 1988 ACM conference on Computer supported cooperative work CSCW 88 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 CDVE2012 Osaka Japan Guibert O 2007 Cours d Analyse et Conception des Syst mes d Information d Outils et Modeles pour le G nie Logiciel G ransson 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 Cah
174. UNIVERSIT DE LORRAINE AVERTISSEMENT Ce document est le fruit d un long travail approuv par le jury de soutenance et mis disposition de l ensemble de la communaut universitaire largie ll est soumis la propri t intellectuelle de l auteur Ceci implique une obligation de citation et de r f rencement lors de l utilisation de ce document D autre part toute contrefacon plagiat reproduction illicite encourt une poursuite p nale Contact ddoc theses contact univ lorraine fr LIENS Code de la Propri t Intellectuelle articles L 122 4 Code de la Propri t Intellectuelle articles L 335 2 L 335 10 http www cfcopies com V2 leg leg_droi php http www culture gouv fr culture infos pratiques droits protection htm UNIVERSIT DE LORRAINE cral Centre de Recherche en Architecture et Ing nierie CES de Lorraine UMR n 3495 CNRS Minist re de la Culture et de la Ecole Doctorale IAEM Lorraine C mimunication 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
175. US ET SYSTEMES D INFORMATION OSTWALDER 2004 p 161 96 49 LEFRAMEWORK ZACHMAN ET LES MODELES DE LA MDA FRANKEL 2003 97 RE50 REPRESENTATIONS D UN MEME PROCESSUS AVEC BPMN EN HAUT ET AD UML EN BAS 99 51 UN EXEMPLE DE DIAGRAMME IDEF3 POUR LA DESCRIPTION DES PROCESSUS ese 100 RE52 REPRESENTATION DES APPROCHES DE CONCEPTION DE SERVICES ICT DANS L ARCHITECTURE DE L ENTREPRISE ie EN EROR geen tees 103 RE 53 LE MODELE EVOLUE DU a TREFLE FONCTIONNEL 44 4 40 022 000001006000 106 RE 54 REPARTITION DES TYPES D USAGES DANS LE MODELE 106 55 POSITIONNEMENT DES SERVICES PAR RAPPORT AUX CARACTERISTIQUES D UNE ACTIVITE CIE KE UM 56 LE MODELE D ARCHITECTURE CO MVC POUR DECRIRE UN SERVICE COLLABORATIF RE 57 VERS UN NOUVEAU CHANGEMENT DE PARADIGME DANS LA CONCEPTION LOGICIELLE RE 58 SCHEMA DU PROCESSUS COCS Ys TIRE DE DELOTTE2006 sse RE 59 UN EXEMPLE DE SCENARIO CONTEXTUALISE DANS SON EDITEUR RE 60 REPRESENTATION D UN ACTEUR ET D UNE LIMITE ENTRE DEUX ESPACES DE VIE DANS CBME 117 Table des illustrations FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU FIGU
176. 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 contribuent 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
177. a group indude Designer choose collaborators to inform 3 indude ED pesign phase The end of the design phase particularly called production phase Documents exchange for design sharing pesigner CP Family 5 Design and reporting EATEN OI DS FOREN he leads the project Designers work together to produce project documents Job Architect IP oittuse design documents for designers team Fa ades 3Ds sections are based on plans provided by designer Inform Already supported by a service Targets Plans of the project Author Designer Status Over Designers according to the tasks they have to perform Job Architect Message type Notification notification of shared documents it can contain specific instructions Author Designer Status Over CRTI weB upload multiple files independantly indude choose collaborators to inform lt lt include gt gt Figure 126 De la pratique l usage variation des intentions d un utilisateur en fonction du besoin m tier Chapitre 12 La m thode PUSH exp rimentations et bilan Chapitre 12 La m thode PUSH exp rimentations et bilan Une sp cificit du premier usage concerne le format des documents chang 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 pdf
178. age qui l valuent Indvidual Practice CD cessas Is composed of Operations definition Communication A Designer E Responsable de la diffusion D Production B Removing Artifacts definition Document on Messanae Actors definition Uses Targets Actor Group of Actors Plans du projet au stade APS Designer Frans Author Designer Add here more species if needed amp Activity definition Status In Progress 6 Phase _ Wheusessshah _ 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 vue organisationnel L avantage de l diteur d velopp est de pouvoir formaliser de mani re structur e
179. aires 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 des 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 oeuvre 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 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 lumin
180. ajout T che d ouverture du d historique devrait pouvoir se faire d tail de la remarque directement dans la liste des remarques supprim e Gain de temps plus de confort Les photos devraient pouvoir tre Partager CR de chantier T che Plus d informations partageables int gr es la version PDF du compte Oui avec des photos Contenu Int grer photo Centralisation des informations L ergonomie de la visionneuse de photos Meilleure ergonomie Non Archivage des donn es en fin de projet Oui R cup rer toutes les G n rale Nouvel usage archivage Nouvelle fonctionnalit utile Adaptation des Web Services Non Am lioration des fonctionnalit s Modification des templates Ajout d id Destin aux d veloppeurs N N N Externaliser le code JS d un fichier tpl N N N pour tests automatiques Selenium l e Cr er un web service pour l upload d un ou plusieurs documents pour un projet Destin aux d veloppeurs dens oS enee m 2 chargement d un document Destin aux d veloppeurs Pour sauvegarder la date d ajout d un historique de remarque il manque un N Destin aux d veloppeurs Lorsqu on veut mettre une action sur un Avertir certains Les acteurs document il faut limiter les organismes Oui collaborateurs d un Contenu s lectionn s sont Pas de notifications inutiles Ajout du WebService permettant de checker le nom fonction du chantier et de NIL Destin aux d veloppeurs Lors
181. ant 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 Delotte 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 modeles voir la Figure 58 la phase 0 est la phase d identification des sc narios d utilisation donnant lieu cr ation d un mod le 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 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 MESE mat rielles di Sc nario 1 Acteurs Phase 2 Contextualisation CAB M
182. antier 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 Ceticket distinct correspond la avec des photos Contenu Int grer photo Centralisation des informations Actions sur document filtrage personnes Identifier activit des Tache 283 du groupe sur base de la zone du collaborateurs Contenu jajout une action sur un temps Ajout mise jour de document version o Avertir certains PIRE 284 multi uploads ajout groupe pour les collaborateurs d un Contenu Selectionpargroupe de temps si une personne essaye d ouvrir un fichier auquel ne peut normalement pas acc der afficher un message indiquant que ce Tache systeme 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 acteurs 296 pr alablement compl tement supprim Contenu supprim Gain de temps Importation organismes pr alablement T che Traiter acteurs 299
183. 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 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 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 pa
184. ards 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 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 IEEE Intelligent Systems 17 05 pp 32 41 Simon H A 2004 The sciences of artificial MIT Press Sohlenkamp M Prinz W amp Fuchs L 2000 POLIAwaC Design and evaluation of an awareness enhanced groupware client AJ amp SOCIETY 14 pp 31 47 Sommerville I 2005 Integrated requirements engineering A tutorial Software IEEE 22 1 16 23 Sommerville 1996 Introduction to Software Engineering Sottet J S Calvary G amp Favre J M 2005 Ing nierie de l 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 d
185. articulier 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 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 l IDM mod lisent galement l information qui n est pas chang
186. as 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 utilisateur 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 qu
187. ating 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 amp Morrison E 2010 Definition of a description language for business service 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
188. ation 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 nt 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 des pratiques collectives g n riques Kubicki et al 2009 valuation 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 travers 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
189. ation 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 nous 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 2 1 Pourquoi m diatiser l activit collective Kubicki et al 2006 rel ve l importance de la maitrise des processus de coordination pour assurer le succ s d un projet AIC et par extension la
190. ation contextualis o 187 10 3 2 Les diagrammes d interaction et maquettages 190 10 3 3 Int gration dans le cahier d evugences eene 193 1024 Concl siofi ed beet tei ette rese ec eer En edge tel sen state tases 194 mE Chapitre 11 La mod lisation des services le point de vue fonctionnel M M 199 11 1 D fimitions et concepls i e irte te a ERE e PERDER HR LER Er ete ens Eee e 199 11 1 1 Services m tier et services informatiques ICT 199 11 1 2 Caract risation des services zesin 200 14 22 M ta modele de Service tercie tetro REEL ele 200 11 2 1 Le service mat rialisation de l usage 0 200 11 2 2 Les composants du service ICT 202 11 2 3 Le m ta mod le des services ICT adapt s 203 11 3 Mod lisation des services et mmpl mentaton nennen 207 11 3 1 Le diagramme de s quence ss 207 11 3 2 Int gration dans le cahier d exigences eene 208 11 3 3 D veloppements innne nee tete HER HP dE 209 RE MN eno NEP HU 211 EUER Chapitre 12 La m thode PUSH exp rimentations et bilan 12 1 Introduction aux exp rimentations 12 1 1 Rappel application d une m thode dirig e par les mod les 213 Table de
191. ation 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 ot 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 particuli 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 perspective fonctionnel
192. ationnel Tableau 14 l ments de caract risation de la PC3 Documents utilis s Activit s Acteurs impliqu s Taches conception et coordination Phase d tudes pr alables Phase Conception APS si appel d offres Maitre d ouvrage Assistance la MO Maitre d ceuvre Programme Informations et directives techniques Experts PC4 d termination et gestion du budget Description le Maitre 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 tache est de d finir l enveloppe financi re d un projet en maitrisant 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 Maitre d ouvrage et assistants Maitre d oeuvre Comptable conomiste Enveloppe et documents
193. ations 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 particulier 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 cara
194. ature 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 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 facon dont les acteurs artefacts et activit s sont impliqu s autour du concept de pratique i
195. 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 velopper un service d identification de d g ts travers un syst me de r alit mixte illustration Figure 69 Sept II 2007 6 a Sort Leem ne gt M 1 Ces Figure 69 Prototypage de l identification d un d g t travers un systeme 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
196. butes n me author date zone actons reactions fie Data type document 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 congu 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 illustre 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 velopp
197. 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 de 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 cifierla 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 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 colocalisation lt lt enumeration gt gt type_synchronisation colocalis s s
198. cation Collaborative en AMF Agenda Exemple d IHM int grant les services IK connect s et disponibles isioCorterence _ Prem men 2 Manager 10 34 2 190 Gesbonnare Facture News emai avaiable from al emal avaiable from Main Tasks SestornsireDozurert intervention chez Mme Mendez emer ss R union de planification i Sestionnaire Rappo Prema a tat Aline beens Connexions de la pr sentation vers les Services dans la facette FOR Dees rege gen 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
199. cation 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 cf m thode valuer le besoin des d veloppeurs valuer l importance des points de vue Evaluer l int r t de structurer les exigences cf concepts valuer l analyse m tier et la description de l usage valuer la distinction pratique usages services valuer la description des pratiques et de l usage cf mod les valuer les formalismes des pratiques et des usages valuer les diff rents formalismes valuer les formalismes de pratiques et d usage ainsi que le passage d un l autre cf adaptation valuer l adoption par les utilisateurs lors du transfert du service valuer l adoption des utilisateurs par des tests Non concern 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 au cours des chapitres
200. 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 Constantine amp Lockwood Ltd User Role Checklist for Agile Modeling A user role is a relationship with a system Tasks 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 Exam
201. ces CRTI BOX m une information ou une inscription immediate contacter le numero national 1642 2780 ou de l tranger ie num ro 09 252 26 64 92 43 50 admin Documents and Zem ke Desktop Tohar Url Web Services construction tudor Iu Num ro du projet 5 n du projet w Valider 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 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 co
202. ces collaboratifs sont concus 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 is couvrent un ou plusieurs espaces fonctionnels Ellis amp Wainer 1994 Les trois espaces fonctionnels principaux qui composent ce qu on appelle le tr fle fonctionnel Salber et al 1995 Piquet 2009 sont espace de production supportant l action des acteurs sur l information d espace de coordination supportant la planification des activit s 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 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 propo
203. 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 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 mode les diff rents plut t que d adapter le m me modele 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 ca
204. 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 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 po
205. 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 Figure 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 re Ils apparaissent dans le diagramme sous forme d un rectangle noir aux coins arrondis 52 User intention User Abstract Task Concrete interaction task 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
206. compl tement supprim Contenu supprim Gain de temps Recherche de remarques lien vers les Consulter les Ouvrir document apres 307 remarques trouv es commentaires des T che recherche Gain de temps Figure 144 Grille d analyse des tickets partie 2 4 E 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 de temps Lola qu 1222 71 327 5 CR mod ration commentaires commentaires management facilit ou S NNI 328 Service Document 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 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 beauco
207. computer interaction research Context and consciousness Activity theory and human computer interaction 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 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 Incorpor
208. contexte m tier et finalement 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 stabilit qui est relative 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 Tutilisabilit 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 assure
209. 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 Figure 72 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 interaction par le sp cialiste
210. cratique 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 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 PN Oralit
211. ct 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 1 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 voir 1 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 entreprises voir 1 13 4 l environnement Chapitre 8 Introduction de la proposition l conomie la technique Avec lui varient les autres contextes li s 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
212. ctions ainsi que leur contenu Pour ce qui est de l analyse du d veloppement nous avons pu porter un regard sur l ensemble des taches 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 cise 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 Maitres 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 apparait fiable facile utiliser compatible avec la pratique professionnelle et que l
213. cts 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 1 1 2 Les type artefact document identifi s sont g om tral mod le perspective photo compte rendu rapport exigences sp cifications calendrier planning agenda ToDo Les objets sont relatifs aux ouvrages de construction voir galement 1 1 2 et sont d finis 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 malfagon 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 taches 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 Chapitre 9 La mod lisation des pratiques le point de vue organisationnel Nous n avons pas typ les groupes d artefact la n
214. cupation 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 taches 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 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 GL 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 p
215. d 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 entreprise orient e services la conception de Syst mes d Information 1 15 Conclusion vers des services adapt s aux pratiques m tiers 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
216. de 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 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 ci 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 tho
217. de l ajout d un utilisateur ou de la Impliquer un acteur dans Assignation du r le modification rendre obligatoire la i leprojet Contenu obligatoire Pouvoir reconnaitre les utilisateurs Le but est de supprimer une action via le NIL Destin aux d veloppeurs IL N IL IL IL IL IL IL Figure 143 Grille d analyse des tickets partie 1 4 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 Envoie notification lors suppression Avertir certains le syst amp me envoie une 204 document et changement de zone collaborateurs d une notification Infomration mieux transmise 209 est celle de l OAI et pas celle Rectification d une erreur Mise jour page de garde acc s plaquette Fa a 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 de r union li e d roulement d une G
218. des 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 tragabilit 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 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 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
219. diagramme de classes Chapitre 12 La m thode PUSH exp rimentations et bilan EP validation des choix conceptuels CP Family 5 Design and reporting Les concepteurs dffusent leur proposition aupr s des matres d ouvrage qu l veluent Designer d lt here more species 4 needed Status In Progress e Choose files and clustering mode Abstract user interacton type Selecton Ln composed of E row domo Concrete user niteractn type Tegoer Hen 3 B 10 Name Documents E Graphical spec loon label progress bars checkbox Then Document A 76 Attributes fie um 6 vostra victor Data type fie Graphical spec text fields and combo boxes p x Attributes pnrritve data memo mose section Geen Lime Concrete user interact type 1 Data type text l 1 7 Figure 121 Correspondances entre la mod lisation des pratiques 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
220. 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 deg dds 400 779 36KB Liaison entre les documents O Les documents sont ind pendants Les document sont li es Pr c dent Suiva as Tous les documents Fichier unique Non STANDARD vri 13 Fichier ze M A APS 00 A 065 04 jpg Se r 13 V PL_A_APD_EG_00_1_001_01 zip Fevrier 2013 v H PL L PDE N1 MT A 111 01 jpg Figure 126 Rappel le service d upload multiple d velopp
221. e Standardisation 2 d Ajustement 2 gt Explicite mutuel E Artef ct Supervision dynamique directe 27 30 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 maitriser 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 types 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 con
222. e PUSH exp rimentations et bilan The user want to share multiple documents one CRT1 wgB without opening web browser 7 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 fonctionnalities 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 Anew 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 when the connection will be ponet Does it im a meeste 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 a s identifie en t ches saisit le login et saisit le mot de passe Les objets d interaction concern s login et mo
223. e TCAO Nous adoptons le concept de Services Collaboratifs CD Qu Qe Prendre en compte Prendre en compte Prendre en compte p teh l utilisateur et le les aspects bah is fonctionnels de la d utilisation collaboration Pratiques Collectives et Individuelles Services Collaboratifs Usages 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 tudes 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 suivants 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 valu
224. e 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 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 11 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
225. e 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 8 1 39 3 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 25 Les fl ches rouges symbolisent l volution de la m thode notamment des concepts et formalismes utilis s grace 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 cf m thode En favorisant le transfert des exigences la m thode permet de lever des risques La m thode permet d int grer les d veloppeurs dans le projet et favorise le dialogue avec les concepteurs La m thode permet aux experts m tiers et aux concepteurs de s accorder sur un usage sp cifier en fonction des besoins m tier cf concepts Les descriptions des pratiques et usages sont pertinentes mais ne suffisent pas d crire le service La composition des trois points de vue forme un mod le de d veloppement complet Les concepts p
226. e 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 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 Ma tre d ceuvre 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 PC 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
227. e 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 d 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 des dates relatives de d but strating date de fin ending date d interruption interruption date etc Un type de dur e long long ou court short n Chaque l ment poss de un champ d dition libre destin a 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 Indi
228. e et d interfaces le niveau t che concepts d finit les t ches utilisateurs et les concepts manipul s niveau CIM l interface abstraite AUI 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 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 unit les pi ces cellier ou salon et les t ches ex cuter choisir g rer le 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 Il 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 Temperaturo 91 50 ConceptContenu Gor
229. e l 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 taches 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 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 taches auxquelles ils attribuent un l ment graphique particulier pour cr er leur propre formalisme d arbre de taches 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
230. e 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 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 Pratique Individuelle gt gt Produit documents pour valuation Pratique Individuelle gt gt Soumet les documents pour expertise Pratique Individuele gt gt Ex cute l valuation lt lt groupe d artefacts gt
231. e 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 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 voir 1 1 3 nous avons d compos l activit de projet dans le domaine AIC en phases et sous phases Figure 86 Figure 86 D coupage 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 une autre reste flou il
232. e 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 analyse 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 services informatiques pour le secteur AIC Comme le montre le sch ma suivant Figure 1 ce travail porte essentiellement sur l expression des besoi
233. e 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 Assister 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 e
234. e services tudes de cas 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 Karlshoej 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 EO 1X 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 est 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 constituen
235. e 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 WISME 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 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 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
236. e 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 16 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 d par un v nement une condition it rative ou unique Le maquettage Lors d un maquettage 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 Al L Fo
237. echnique transforme le mod le conceptuel du domaine en un autre mod le relationnel 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 Nm 2 Mot de passe texte Photo objet Courriel hypertexte El ment de mod le du domaine 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 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
238. ective En effet nous supposons que l outil supporte le contexte de l activit collective en le m diatisant 1l 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 comprendre les possibilit s techniques dues 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 e
239. 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 lt Contr leur Utilisateur n Tt Envoie la requ te gt Dimensions spatio q Mod le temporelles et Utilisateur 2 artage fonctionnelles Interagit avec Modele Renseigne Fournit priv Se synchronise Utilisateur 1 l information T S actualise afficher 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 Vers une r ponse 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 ada
240. elatif 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 travail Tableau de bord Premi rer union Pr sentation des rhaquettages Discussions sur leg attentes Deuxi me r uhion Mod lisationides Pratiques et usages gt Formalisatign du cahier d exigences Finalisation du cahier d exigences 1 1 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 u
241. elons qu cette tape de la conception de notre m thode nous connaissons l organisation professionnelle 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 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 l outil lest compos de services informatiques ICT le client de ces services repr sente l utilisateur de l 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
242. ement 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 Business service name documents management Descrption the documents management service of the crti web tool is dedicated to files sharing and traceability in an AEC project Service ICT gt gt Automatic upload lt lt Client gt gt Designer lt lt abstract D TES enter login Eu folder project ui project number H lt lt Input gt gt i enterldeftificationData ID password Folder et web url project number lt lt action gt gt 2 tspecifyChecked Folder folder eL ENIM lt lt gt gt 3 pasn rd crti web URL deen i i lt lt action gt gt 4 verifyData Ib pasword crti web URL project number i i o i i lt lt action gt gt E 5j validsbeData Peer rey p M E E EEEE 6 validsteData 1 K EE lt lt action gt gt lt lt abstract ass copy files in Se folder lt lt Input gt gt 8 addDocumeht Document HTML S lt lt action gt gt lt TET d lt lt action gt gt 9 10 requestUploadDocument Document lt lt action gt gt 11 jendDocument Document p lt lt actio
243. ences permettra de d composer le use case au m me titre que le tableau figure 17 Retrait de billet r serv un guichet Intentions del utilisateur R sponsabilit s du systeme 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 Foumitle 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 3 DonneD tailsBillet 4 ConfirmeBillet 5 FournitBillet Use case diagram 6 PrendBillet gt Repr sentation d un use case sous forme de diagramme 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 l utilisabilit d
244. entified and solved by coordinator and contractors Executes Is composed of Site monitoring Is composed of e Inform The coordinator has to monitor builtin execution while he visits it Need service support Is composed of Targets Is composed of G Ente identity verity consutt roup type Enterprise Contractor N d of t N d of t Need t need or service suppor need or service suppor service suppor Contractors concemed by defects Uses Is composed of Targets Rais TO Uses CV Defect Model Report Message type Reaction Al defects identified dnng the visit Targets Any 3D representation of the bulding Site meethg report New remarks about defects Author Contractor Author Designer Author Contractor Author Designer Status To Modify Status Over Status To Execute Status Over Status In Progress Refers To Buitding Gg 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 s
245. ents 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 cinq phases Connaissance du probl me cette phase
246. er 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 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 e 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 rat
247. er temperature maison Espaceinteracteur Liste Selection G rer Menpersture Seleciiooner pece Figure 40 Illustration des transformations entre mod les dans le cas d tude de Sottet et al 2005 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 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 l
248. er 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 galement 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
249. ers get documents from others ___ Maman Choose an item synchrone asynchrone d ciii pov Figure 105 Mod lisation de la relation avec d autres usages 1 33 2 Les diagrammes d 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 Figure 107 Le choix de ce nouveau formalisme a t guid par deux motivations Tune 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 Eclipse 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
250. es 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 p tisse pas Afin 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 relat
251. es 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 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 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 l volution des exigences En d autres termes identifier un but permettra de d terminer le besoin
252. es 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 z enumeration gt Type donn e bool enne num rique date texte hypertexte fichier m dia objet BIM int ragit avec Type_artefact num ration acteur num ration Activit D nomination texte Type_r le num ration activit num ration auteur type r le kh bt 25 0 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 relation utilise entre l utilisateur et l outil la relation se d roule entre l usage et la temporalit ainsi ou entre l usage et la localisation Chapitre 10 La mod lisation des usages le point de vue op rationnel enumeration gt type lieu sur le chantier au domicile chez le client dans un endroit public autrejinconnu type_lieu num ration Acteur Type_acteur
253. es Outils c eie eerste eren ee 25 EE GE EE 25 MI MEE DUI ERR 27 1 2 Les projets de construction et les outils de TCAO 29 1 2 1 Pourquoi m diatiser l activit collective 7 29 UE NN E E EE 31 1 2 3 L adaptation au comntesgte ss 34 1 3 Conclusione ea EUN eU IER n AERIS 35 Chapitre 2 Un cas de d veloppement d un outil de TCAO CRTI weB 37 Table des mati res 2 1 Description de l exp rience sise 37 2 1 1 Identification des besoins m tiers et bonnes pratiques 000 38 2 1 2 Caract risation des comptes rendus et autres documents 0 20 0 212 0 1 39 243 SELVIC S PrOpOSeS PC c ins 40 2 2 Analyse critique REM 42 2 2 1 Contexte et protocole d analyse seen 42 2 2 2 Analyse d utilisation iini HH dress s 42 2 23 Analyse du d veloppement et conclusion 43 2 3 COT CISION M 45 Chapitre 3 Probl matique et m thode de travail M 47 3 1 Construction de la probl matique sise 47 3 1 1 Objectifs et concepts vis vis du con
254. es 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 5 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 uatcrti web com nde php 58 3 Projet listingDocuments Bi Les plus visit s 2 D buter avec Firefox A la une Free Hotmail Suggested Sites Web Sice Galery E Concepti 2 77 7 CRT Chantier d veluetion pourle CRP HT Gestion de Document Documents du projet gt 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
255. es pratiques collaboratives pour la conception des SI bas s sur les processus m tier Revue des Sciences et Technologies de Il Information 11 3 73 94 Soulier E Lewkowicz M amp Corouge N 2007 Gestion des processus m tier et travail collaboratif myriam lewkowicz free fr p 25 Suchman L 1987 Plans and Situated 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 320 329 Tarpin Bernard F 1997 Travail coop ratif synchrone assist 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
256. est d ailleurs souvent admis qu elles se chevauchent le d but d une phase ne marquant pas tout 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 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 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
257. 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 IDEFO 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 co sers wer Ret Liens br Simple Precedence Link gt 4 Constraint Precedence Link Relational Link Jonctions AND Synchronous AND OR Synchronous OR x 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 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
258. 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 Larelation sp cifie que toutes les t ches d crites doivent tre ex cut es Larelation PUIS ajoute un ordre dans l ex cution des t ches Nous retrouvons ici les concepts manipul s par CTT Patern et al 1997 ou K MAD Baron et al 2006 les langages de mod lisation de taches 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 Constantine 2001 cf 8 1 10 3 Le m ta mod le suivant Figure 97 repr sente ces concepts et leurs relations Chapitre 10 La mod lisation des usages le point de vue op rationnel Relation entre t ches type relation Ftype relation num ration ET ou PUIS ees T che outil Intention utilisateur utilisateur concr te nom Interaction Perception lt lt enumeration gt gt lt lt enumeration gt gt type t che interaction type t che perception criture s lection d clenchement selection manipulation navigation tran
259. eurs 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 Mom texte Description texte EN Objectif texte m diatise EE SEs 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 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 s
260. euses 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 l ments de caract risation de la PC7 Documents utilis 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 ex cution assistants Rapports d expertises 8 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 maitre d ceuvre l
261. euvent tre am lior s et compl t s de mani re r guli re pour raffiner l analyse cf mod les Le diagramme de pratique est utile mais les diagrammes relatifs aux usages restent insuffisants sans plus de pr cisions techniques Le passage d un mod le l autre est explicite et favorise le dialogue entre concepteurs et d veloppeurs Le passage d un mod le l autre est explicite et favorise le dialogue entre expert m tier et concepteur de service cf adaptation Les utilisateurs privil gient l upload multiple et en font l usage pour lequel il a t d velopp Peu de tests on t effectu s ils valident le fonctionnement du service mais pas son adaptation Aucun d veloppement n a t effectu 1 43 2 Les trois 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 veloppeme
262. euxi 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 tapes 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 Figure 67 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 Appli
263. 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 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 Maitre 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 fagades 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 concep
264. fact 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 informations 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 men
265. 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 P R sultats connaissance processus ia Connaissance 1 5 Proposition du probl me i i I I I Suggestion Premier jet ea cs me LA d Circonscription D veloppement Artefact Evaluation Performances Connaissance sur les 1 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 partir des l ments qui composent notre prob
266. 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 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 aes Mettre a jour Update Effacer Delete Ex cuter Execute Lier Link Inclure Include labi Diffusion Availability Partager Share Annuler P Av 24 partage Unshare Recherche Research 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 gg eoo ou agenda planning to do Objet object b timent building lot plot tage
267. fication 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 BM Systems 44 1 pp 81 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 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
268. 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 collecticiel 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 frangais 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 proposit
269. gicielle 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 3 D fini par D fini par 2 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 l organisation dans laquelle il volue Elles permettent alors de r pondre aux besoins de l entreprise en proposant des
270. her 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 EE Chapitre 4 De l utilisateur la conception logicielle et d interfaces Contr leur Envoie la Commande requ te Commande Interagit avec 1 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 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 le
271. icite 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 l 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 acteur 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 um ud vc _ D 4 N E 2 T CN d S 2 E T A 4 IR 1 CF Qc J Hi rarchique Adhocratique Transversale Figure 4 Distinction entre coordination hi rarchique adho
272. iers 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 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 MIS quarterly 28 1 pp 75 105 Hietanen J 2006 ZAI Official IFC Model View Definition Format Hodgson G 2003 Capitalism complexity and inequality Journal of Economic Issues 37 2 471 478 Huang E amp Mynatt E 2006 Secrets to success and fatal flaws The design of large display groupware IEEE 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 104 109 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
273. ig 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 Dubois E et al 2009 Towards a Sustainable Services Innovation in the Construction Sector Advanced Information Systems Engineering pp 319 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 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
274. il de groupe Il rel ve galement le manque de tragabilit 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 difficult 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
275. inition 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 ineo on nono anna inn span spen a yay a nea HERR 15 de Te de RERUM 17 Une th se la crois e des chemins entre sciences de l architecture et g nie logiciel 18 Nels UE ET E EE 18 Plan de lat MGSO EE 20 PARTIE 1 ASSISTER LA COLLABORATION DANS LES PROJETS DE CONSTRUCTION DEFINITION D UNE PROBLEMATIQUE ET RECUL THEORIQUE 21 Chapitre 1 La coordination dans les projets de conception construction architecturale 23 1 1 La caract risation du secteur dans les travaux 23 1 2 Les projets de construction et les outils de TCAO 29 1 3 CONCIUSION c
276. int 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 8 1 2 3 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 d introduire nous pouvons d finir les deux l ments de caract risation d un usage Figure 96 l objectif 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 plusi
277. ion PRACTICE amp USAGE BASED A Figure 64 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 finition 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 cr ation champs d insertion d image afin d importer les mod les graphiques cr ation de champs de choix multiples et de saisie organis s dans des tableaux pour diter les modeles textuels des champs de saisie suppl mentaires qui permettent d ajouter des commentaires et informations additionnelles La premi re page
278. ion 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 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 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 Prat
279. ion 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 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 suivante 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
280. ion 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 _ Etude 25 ivit OSEE Elaboration Construction Transition noe me Phases Mod lisation du m tier 72 mum D 2 Analyseet conception Impl mentation oo OS D ploiement OPA 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 Les activit 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 en d crivant les objets du monde r el On
281. ion 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 1 9 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 le niveau intentionnel qui d crit les besoins et les buts pour en d duire les exigences du syst me 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 ris
282. ionnelle 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 d l efficacit le rendement de leur processus de cr ation de biens ou de services et leur production c 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 apparition du travail la chaine 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
283. ions concrets et int ressants pour les utilisateurs maintenir la compatibilit avec l impl mentation d autres logiciels A Vheure 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 management et le fournisseur supply chain On peut y lire que l quipe de conception Chapitre 7 Les m thodes de conception d
284. ions int rieur ext rieur etc est galement importante Cet objectif concerne la fiabilit structurelle ou encore la qualit des ouvrages dans le temps 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 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 batiments 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
285. ipse 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 ditables partir d une fen tre propri t s I Package Explorer X l Myllibrary 52 org eclipse emf model instance Resource Set src 4 platform resource org eclipse emf model instance model My library BA JRE System Library JavaSE 1 6 Library amp model New Child Book My library Employee Undo Ctri Z E Writer Redo Ctrl
286. ique 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 R le du client du service T che d interaction impl menter Composants du service lt gt 3 0 folder ur protect number lt lt acton gt gt 2 Ok Folder 4 i S actin i 3 requesitataecthcation ID UBL pro shade Inputs Outputs et Actions entre composants DEN ret yo Correo action Lr 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 developmen
287. iques 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 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 22 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 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 document
288. ir 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 service 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 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 7
289. ire 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 CP Family 5 Design and reporting Les concepteurs dffusent leur proposition aupr s des maitres d ouvrage qu l valuent 15 composed of Q vesioner IP Diffusion des documents produits Responsable de diffusion Job Architect Un des concepteurs expose chon conceptuel de l qupe pour vatiaton Is
290. isi 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 l utilisateur S paration de l analyse m tier et de M thodes orient es exigences et non 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 dela 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 un collecticiel doit fournir des services adapt s chacun des utilisateurs en tant qu individus
291. it les actions ou les statuts d un l ment par rapport un autre Par exemple 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 TIT Relation Activit Activit Element stereotype gt vie Relation Acteur Activit Activit Elemen Element Relation Activit Acteur T eren Stereotype gt Relation Activit Outil um Element GroupeActivit s k ActiviteUnique lt lt stereotype gt gt Relation Outil Activite le ment lt lt stereotype gt gt Element eentereotype a stereotype gt Relation Activit Artelact stereotype gt Relation Acteur Acteur gt Relation Outil Outil Element Relation Artefact Activite Nu Elementi stereotype gt Element 7777 Acteur TTT Element Eme emm S Element 1 Outil Acteur Eee i i Eben j 1 stereotype gt lt lt gt gt Ar O lt lt stereotypey gt lt lt stereotype gt gt GroupeActeurs ActeurUnique Element GroupeOuyils OutilUnique
292. ite 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 Figure 17 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 Test du syst me Impl mentation Conception des Test des composants composants V rification Codage des composants Maintenance 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 obtenir un prototype op rationnel d placement vers la droite dans le quart sup
293. iter 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 Windl 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 taches 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 Processus 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
294. kshops 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 25 28 Papazoglou Michael P amp Heuvel W J Van Den 2006 Service oriented design and development methodology International 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 Journal 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 Simposio 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 d
295. l 2007 le d finit une m thode de conception logicielle c est un processus qui vise produire une suite de mod les 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 8 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 taient des m thodes en cascade et suivaient un processus lin aire Figure 17 partie gauche Puis elles adopt rent une structure en 2 tapes d
296. l 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 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 Connaissance Etudes initiales le contexte tri facettes Les concepts et la m thode de conception de services propos s PARTIE 3 proposition La conception de CRTI weB La m thode de conception suivie dans ce travail de th se Suggestion D veloppement Evaluation Conclusion PARTIE 1 contexte d tude
297. 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 vue 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 Figure 87 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
298. l interaction avec le client savoir les taches 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 les fonctionnalit s qu il supporte du type cr er modifier supprimer le d veloppement par composants permettra de grouper ces 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
299. la diffusion et l valuation dans la communaut scientifique cet diteur a t concu en anglais Chapitre 9 La mod lisation des pratiques le point de vue organisationnel 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 Palette s Practices defintion CP validation des choix conceptuels BOE FERE CP Fami 5 Design and reportng CP Les concepteurs diffusent leur proposition aupr s des maitres d ouvr
300. 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 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 ZADIS International Conference Applied 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 EEE 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 Leipz
301. lace 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 A 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 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
302. 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 existantes 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 malfagons 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 r
303. le qui d crit les r gles m tier la perspective comportementale qui d crit le s quen age des activit s 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 mE Chapitre 5 De l entreprise 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 f
304. 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 lt lt enumeration gt gt RoleType Designer M ta mod le enumeration Title architect structure engineer 7 urbanist electrician carpenter Owner Owner assistant Contractor Expert Administration Coordinator Advisor B Actor ActorName EString c Role RoleType Title Title mason other roupActorC mposition SimpleActor lt lt enumeration gt gt 2 GroupActorType Agency 7 Laboratory Public organization ActorComposition Enterprise Association e Other linkActor targetObject GroupActor GroupType GroupActorType 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 MRCP Transform Diagram Editor Gen Model Graphical Def Mode Edit Create Select E Create Generate diagram editor 2b Sp cification de l apparence de la palette d outils 4 G n ration de l diteur AN Messanae Actors definition Actor A Group of Actors 4 Evan mam B Activity definition Ke Mod le oesigner Man architect responsible of plans production Job Architect Figure
305. 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 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 diagramme 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
306. les travaux pr c dents Les travaux de mes pr d cesseurs men s au sein du laboratoire MAP CRAI ont contribu 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 facon 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 gr ce 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 orique 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 Les acteurs et leur caract risation L acteur est identifi comme une pe
307. lle K 4 onception d taill e SJ unitaires Cod R alisation 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 conception centr e usage Constantine amp Wmd 2003 Litt ralement parlant la CCU se concentre sur l utilisateur qui manipule le syst me la CCA sur l activit c d les taches 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 taches R ciproquement l analyse des t ches d un syst me dans la CCA est li e aux t ches de l utilisateur 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 taches et objectifs Il cherche cependant lim
308. lsen 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 JBM developer works January 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 amp R Wagenaar eds Proceedings of the 6th international Conference on Electroinic Commerce pp 1 10 Bain D Chalon 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
309. lue 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 premier 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 17 Voir http www omg org mda Chapitre 4 De l utilisateur la conception logiciell
310. lustraient l interface du service tel qu il allait tre d velopp Au regard de certaines contraintes techniques 1l 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 Premi re r union d quipe Besoins rapport s lors de workshop I I I gt Formalisation du cahier d exigences 1 Deuxi me r union d quipe Discussions surbase des diagrammes de s quence arbres des t ches inutiles Trois me r union d quipe i Premiers maquettages 1 5 Modifications des _ ements i 5 contraintes techniques S 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 consistant partager des plans et autres sp cifications techniques avec le
311. m diatis e Chapitre 12 La m thode PUSH exp rimentations et bilan Transmettre l 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 permettent 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
312. messagerie Connexion par login mdp Les deux acteurs ouvrent leur boite cela inclue la connexion La connexion par login mdp est une sp cialisation de la connexion Acteur 1 lt genet Ouverture boite a E EN x ET Envoi d un message Ng l envoi du message est N E A NECS Y fait par l acteur 1 et destin l acteur 2 message Ce use case p e L acteur 2 lit le Acteur 2 peut tre tendu par un envoi de notification effectu par le syst me vers l acteur 1 Figure 22 Exemple de diagramme UML de cas d utilisation 12 4 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 12 http www agilemodeling com artifacts sequenceDiagram htm Chapitre 4 De l utilisateur la conception logicielle et d interfaces Boite englobant une zone p d d it ration loop Cetexte tablit les conditions de l it ration qui continue jusqu message deretour ce que les conditions soit remplies Lesitems entre parenth ses sont les param tres Receipt total productiD s Laligne P osi pointill e repr sente un Figure 23 Exemple de diagramme de s quence
313. 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 s des documents utilis s et des activit s phases et taches 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 Maitre 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 Maitre 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 c
314. mme celle intervenant dans l exp rimentation n 1 Les d veloppements ont donc t davantage suivis et trac s r Evaluation 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 congu 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 en 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 e
315. mpte 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 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 la Figure 56 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
316. n rale obligatoirement un 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 dela classe stats class php NIL Destin aux d veloppeurs 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 Josue Utilisateur avec 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 jfichiers export s par des liens 270 Favicon petit ic ne pour affichage en NIL D tail graphique 276 Export ch
317. n 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 rennisation 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 t t dans la mesure 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 non adoption dans certains cas des services est due un contexte utilisateur d j trop fourni en outils et solutions largement adopt es Jes 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 pour
318. n de services tudes de cas Business space Translation space Interaction space Manage Y Business Entity Manage p Interactional Entity I Figure 71 L architecture Symphony tir de S Dupuy Chessa 2011 1 20 3 La branche technique et la conception La branche technique consiste d crire la fois l architecture logicielle et l architecture technique L architecture logicielle pr conis e est le mod le MVC cf 1 9 3 Figure 26 Il permet la correspondance avec les objets Symphony d crits pr c demment les objets interactionnels correspondent 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 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
319. n 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 NI Graph Number of remarks buiding on site NZ 3D model position of the user on site NI Graph Number of remarks par Sms M2 Graph Evolution of the number of remarks trom the start of the construction 3D model position of the user on site Highlighting of fe bulding under consideration WL List List of remarks concerning the floor under consideration number titie responsible location priority level date of detection lead time date of closure V2 30 model position of the user on site Highlighting of the floor under consideration Number of remarks for each room of the floor on a 30 model Yi List List of remarks concerning the room under consideration ruimbes title responsible location prionty level date of detection lead time date af closure photo V2 3D model position of The use on Ste Highlighting of the room under consideration Number of remarks for the room under consideration and location of the remarks on a 30 model Building 2 m 2 D 3 m seng O dus Lo dar iteonm rer Quest Mu nome NL List of remarks concerning the building element under consideration number titie respansible location priorty level date of detection lead time date of closure photo commen
320. n 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 l 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 taches K MAD permet de d composer l activit en une t che g n rale des taches interm diaires puis des t ches dites l mentaires le plus fin degr de granularit On retrouve le d coupage en types de taches comme dans CTT en fonction de l ex cutant de la tache 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 t che interactive d clench e par l utilisateur et r alis e sur l quipement at che abstraite contient des sous t ches d ex cutant diff rent t che dont l ex cutant est inconnu est comme son nom l indique ind termin e e E N Racine N Racine Racine H Racine CH I a ES O Q 0 2 4 INTER f INTER INTER EY Utilisateur Syst me Interactif Abstrait inconnu Decomposition Meonmposifion Gm ac T e Figure 35 Les cinq types de t ches qui composent un arbre K MAD Les t ches filles d une m m
321. n gt gt 12 createDacument Documeht a lt lt action gt gt 47 d3 uploadSucess lt lt action gt gt lt lt output gt gt H 14 uploadSucess 1 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 fagon dont 1l 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 dnpu 0 ificationData ID password folder crti web url project number lt lt action gt gt 2 specifyChecked Folder folder E etin 3t restant D 2222 crti web URL proj thumber lt lt action gt gt 4 veriFyData pasword crtiweb URL lt lt action gt gt a JUIN deeg 6 valdbteData 7 not yOf Connexion lt lt action gt gt ware a pri Jb Ue pha vot s Bibie ree Hered end te A Web Glen H Concepten colors Medie Pure on fo CRThyeB sdc construction tudor lu URL de la ET mra Identification e s d B r f ren
322. n plus tre consensuelles Nous retenons ce point de vue par 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 d on admet qu une pratique dite bonne dans un projet pourra ne pas tre adapt e dans un autre Ce contexte est relatif 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 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 Bj rk 1999 divisent le processus de construction d un b timent 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
323. ndividuelle 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 collective 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 partic
324. ndividuellement 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 Figure 95 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 passe 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
325. ngineering 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 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 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
326. nis 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 modele 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 l usage la synchronisation dans le temps synchrone asynchrone et la co localisation co localis distance Dans l exemple ci dessous Figure 105 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 Form ID XX Design
327. nnel 1 37 Mod lisation des services et impl mentation Nous utilisons le diagramme de s quences pour d crire le comportement du client et du 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 y ts composed of nm dian aid H Choose files and clustering mode e name crti web document gt 15 d Abstract ver interaction type Selon 1 J E Abstract uter interaction type Input eat oeren vias ternos type Tepes
328. nnovation 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 l activit collective cf 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 besoi
329. ns 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 conception 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
330. ns des acteurs dans leur globalit Or la qualit percue des outils est troitement li e leur capacit r pondre 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 suivant 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 protot
331. ns 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 tout 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
332. nt 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 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 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 info
333. nt 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 trois points de vue Figure 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 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 nario d utilisation adapt Il nous semble important de n avoir que rarement recours 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 d
334. nt 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 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
335. nte 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 OO WSIL A Publish 12 4 Discover WSDL Discover Provider Requestor Web SOAP Legend References to service descriptors Q Pointers to WSDL documents LC Originates from e 22 Figure 47 R les et interactions dans une architecture de services web 22 http publib boulder ibm com infocenter rtnlhelp v6rOmO index jsp topic 962Fcom ibm etools webservi ce doc 2Fconcepts 2Fcws html EE Chapitre 5 De l entreprise orient e services la conception de Syst mes d Information 1 13 4 La place des services ICT dans un business model comp titif Rappelons qu 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 tradit
336. nts 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 EE Chapitre 5 De l entreprise orient e services la conception de Systemes 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 entrep
337. ocalisation 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 System builds reserv able facility list tem shows reserv able facility list Customer selects change Customer clicks select link System builds reserv able time slot list for facilit tem builds empty reserved slot list Customer selects cancel rejoins 4 Customer selects cancel System shows reserved time slots form Customer clicks select link cw Customer confirms reserved time slot list Customer selects confirm System reserves reserved time slot list for customer Customer selects Mod le RSL alistElementSelections 1 ListSelection 1 alist ReservedTi meSlotsForm Select select reservableTimeSlotList FormElement xs form Facility Reserved FacilityReservation ReservableTi meSlotUst 1 Owned teservedTimeSlotsF orm Reservation 0 1 Listitems items entity Facilities Ti meStot reservableTimeSlotList date Date day String fromDT Date isReserved boolean toDT Date
338. oci 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 chaque 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 d
339. ocie 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 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 service ICT gt gt upload service J lt lt client gt gt lt lt View gt gt lt lt Private Model 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 T lt interaction task gt gt activate new dowload y lt lt Input gt gt SE displayUploaHOptions lt lt input gt gt selectBrowse perception task gt gt visualize files y TT lt lt outpht gt gt H ee i Se eg H alt File selection alternatives interaction task gt gt file selectiort J H lt S i gt gt selectOngFile seq Classical upload process J lt lt interaction task gt gt file selection 2 7 lt lt Input gt gt selectMultipleFiles perception task gt
340. od le comportemental Sp cialisation Phase 3 Application coop rative Composants Patterns d interaction Niveau Appli Collaborative KEN Niveau Infrastructure du Groupware Niveau du Syst me Distribu Nouveaux sc narios a Yv Ke 86 Figure 58 Sch ma du processus CoCSys tir de Delotte2006 1 19 1 D roulement de la m thode La formalisation des sc narios R cit Chez le client le techrucien dite le compte rendu d intervention et pr pare la facture Le technicien dispose d un PDA qui se synchronise r guli re ment 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 mode 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 t
341. oint 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 A 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 tapes 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 resta
342. ojet 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 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 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 la fois orient recherche et d veloppement cr au travers de la collaboration entre le CRAI Nancy et le CRP Henri Tudor Luxembourg nous a permis d valuer et d am liorer la d f
343. ologie 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 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 Modele priv nom texte Donn e texte Mod le sg I 5 Mod le partag p 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 mod le 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 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 mat rialise
344. on 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 1 12 le point de vue de Sophie 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 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 8 1 9 1 appel s objets Les objets interactionnels d crivent l interface et sont sp cifi s partir des objets m tiers
345. on 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 ou d une t che que celui ci doit accomplir vis 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 8 et documents Docl
346. on 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 organisationnel 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 maitre 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 vue 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 d finition du c
347. onception Il est galement n cessaire de recueillir aupr s des services ad quats mairie ou administration communale http assohge org hge http www breeam org http www minergie com home en html http www dgnb de en 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 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 PC1 Documents utilis s Activit s Acteurs impliqu s Maitre d ouvrage Maitre d oeuvre 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 maitrise d uvre Description le maitre d ouvrage engage la Maitrise 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
348. ons 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 Sujet 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 grandement 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 i
349. ontexte de l utilisateur d finition de l outil 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 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 comment 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
350. ontrainte par des r gles grammaticales et des sch mas M2 conformes un m ta sch ma XML M3 de l architecture dirig e par les mod les MDA pour a 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 L ET EMF Eclipse Modelling Framework est similaire 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 Conforme Conforme M ta mod le Grammaire M2 5 UML Sch ma XML JAVA Conforme Conforme Conforme M1 Mod le UML Document XML Langage JAVA Conforme a Conforme a Conforme a 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 vo
351. oop 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 ration est observable lors d activit s de formalisation ou d ex cution comme le montage de l APD par exemple Les t ches comme le dessin des plans des fagades 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
352. ordinateur 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 Les artefacts 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 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
353. ormalisme 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 exceptions Dec de Mare everte Crtaci de 92 pat m 2 2 2264 Zeta 2 gt ege huh ate eo eme pomodori bts esos Y See tes oe rem nda mime te tabat J e b pow ott whe teva ee 2 du Cutis de te Y pers tee apemerta fena T fester tte de f NES nea e o n ce gra up m D TEE 2 2 tt 4 TH ayt m art m rase 4 epee ee e 4 pon t mp cm ome E 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
354. ose 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 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 usager 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 savo
355. osition 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 finit 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 connaitre 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
356. ous caract risons un service par un nom une description un client et un fournisseur La description d un service comprend 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 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 Rapp
357. ous 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 GD vesion phase The end ofthe design phase particulaty caled production phase Documents exchange for execution The main designer of the project he leads the project CP 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 Group type Enterprise Contractor General construction enterprise Plans of the project Author Designer Status Over ga Message type Notification Sp cifications about material and equipment notification of shared documents it can contain specific instructions Author Designer Status Over CRTI weB quim ee imc mm E cmm ea upload multiple files in
358. ov kp reir S e EESNEERY NU nn sn YE NEWS SN rene sense NEEN 247 Concevoir une m thode de conception recul sur une approche orient e design science 247 Les himites de approch ike rep Eti Ure nene tas 248 IN 249 Table dES 5 550 see ses m 251 Bibliographie 257 GOSS AINE ee D 273 Walle ESI e MM 277 List des figures uis cei terree ug e p e eve 2T Taste des tableaux ee Rete Dee EO deese us ae 281 DVD OX OS le M 283 Analyse des tickets de conception de CRTI weB ss 283 Cahier d exigences mode d emploi 288 Cahier d exigences partie ditable seen 294 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 129 149 Andersen P Carstensen P H amp Nie
359. 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 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 A A A A Services collaboratifs Services m tiers et ICT Applications utilisables Applications utiles 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 tro
360. 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 Logicielle 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
361. 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 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 8 1 14 2 Chapitre 4 De l utilisateur la conception logicielle et d interfaces Nom Nombre d employ s Chef d quipe 0 n 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 besoins et en documentant ces informations dans un formulaire p
362. 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 la troisi me s ance ils nous ont propos des maquettages qui il
363. paru 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 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
364. plementations 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 n 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 capter 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 oc
365. ples 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 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 discretionary 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 J 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
366. 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 tragabilit 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 contexte 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 CR
367. ptation 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 outil lui m me choue il demande un travail suppl mentaire des utilisateurs qui n en percoivent pas directement le b n fice conception de l outil choue car elle est bas e sur des intuitions de b n 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 trava
368. que 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 innovation 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
369. r Chapitre 3 Probl matique et m thode de travail rmm l efficacit 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 72 Formulation de la 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 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 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 Notre recherche
370. r 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 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 limit un utilisateur 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 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 Acces tous les Attribution d une fonctionnalit 458 l administrateur projet de voir tous les Oui gestion men es par un T che documentslimit 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
371. r document Chapitre 12 La m thode PUSH exp rimentations et bilan Scan RFID Concrete user nteracti type composte 7 d a uu 6 on element on 30 model Sas Concrete user intecactin type Selection gt ts composed of pt A Select element N Abstract user interaction type selection n n aa Pret weh IO Name Buking element Graphical spec 20 element in the model Attributes name description position Data type BIM cbject D add new remark on element e A L3 create remark S act user nteracton type Input Then De interact with Name Remark about element Graphical spec Icon on the element table n the remarks kt Attributes 10 element description position photo responsible date state 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 j 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
372. 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 Systemes 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 simple Pour Soulier et al 2007 1l 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
373. 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 tapes de conception et de d veloppement logiciels Chapitre 4 De l utilisateur la conception logicielle et d interfaces e Evoluet Tests Analyse des besoins a gonomique 4 d utilisabilit Tests utilisateur Tests du systeme ti Espace IHM Conception Se EE eae ume me pue Fo Conception Conception globale Tests d int gration logicie
374. r res wn Abstract user interaction type Input output Jo men re crn Concrete user interactin type Selection Le 10 Name 1 Document name amp Graphical spec text 69 and combo boxes Graphical output Attributes pamtve data Data type text B mod action mm a Concrete user interactin type Trigger gt 0 M me document plusieurs fichers O Pusieurs documents nd pendants Figure 111 Correspondances entre le diagramme de pratiques et les modeles 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 ser
375. r information AN i 11 For execution General Enterprise O Owner to Gen Ent For reaction a 0 For validation Calendar View Le Comment i CUN 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 t ches et des l ments d interaction sous forme d l ments graphiques des composants abstraits canoniques il cherche mod liser les interfaces travers des prototypes abstraits 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 Chapitre 4 De l utilisateur la conception logicielle et d interfaces Action D bute va Stop fini 5 lt Cr e Supprime vers termine efface Duplique Ex cute Action sur Action sur et retour bouton vue E Modifie D place Y JN x EN Conteneur El ment Notification acteur
376. r 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 RAMEAU Logiciels de groupe Logiciels D veloppement Travail collaboratif Conception centr e sur l utilisateur Design patterns Architecture Informatique Architecture Pratique
377. ra 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 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 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
378. ractices analysis for the adaptation of IT services to AEC projects Case study of design assessment related practices In CIB w076 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 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 ch
379. rait 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 adopt 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 premieres 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 ceuvre bas sur l analyse des besoin
380. raphiste coordinateur maitre d ouvrage constructeur conomiste conseiller expert administration 4 implique 12 Pratique colllective enumeration gt Type statut cours termin pour ex cution ex cut valider valid modifier Artefact simple AN Groupe d artefacts type_groupe texte autre Document Objet Message lt lt gt gt lt enumeration Type acteur Simple Type acteur Groupe enumeration enumeration architecte Fagencejbureau d tudes Type artefact Document Type artefact Objet lt enumeration gt gt urbaniste j TENE po artefact Message urbani entreprise g om tral site ing nieur structure Haboratoire mod le Hot information ingenieur secure organisation publique perspective Fb amp timent requ te aoe Monnens autre photo niveau notification macon T compte rendu rapport pi ce r action lectricien xigences ouvrage validation comptable specifications r servation secr taire calendrier planning mat riau autre agenda chantillon ToDo d faut autre engin ed Figure 87 M ta Modele de la pratique collective MMPC concepts principaux fond bleu sp cifications contours bleus num rations contours verts Enfin nous distinguons trois artefa
381. rche dans ce sens et pourrait faire l objet d une perspective de ce travail 1 25 La m thode PUSH Practice and Usage based Service enHancement 1 25 1 Un processus qui valorise 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 champs 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 2 Usages M2 Services x 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 http www eclipse org atl Chapitre 8 Introduction de la proposition Nous parlons de valorisation des opportunit s m tier lors
382. rements Applicative architecture architecture Requirements ign Implementation Integration ITERATION Figure 68 Cycle de Symphony tendue L extension Symphonie tendue compl te cette approche pour y inclure 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
383. riptive de la plateforme disponible sur ce lien http uat crti web com public Description de la plateforme CRTIweB pdf Chapitre 2 Un cas de d veloppement d un outil de TCAO CRTI weB sens ces pratiques consensuelles sont relatives 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 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 a 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
384. rises Cardoso et al 2004 Utilisent Utilisateurs Fournissent e consomment Services composites m tiers m D composition et Orchestration Processus services m tier Informatis s par Syst me services IT D B D D 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 1 illustre ce BSDL par un m ta mod le UML Figure 45 dont les concepts principaux sont les suivants Je 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 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 lexicalement 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
385. rmation 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 Finally 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 E
386. rmatiques 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 Figure 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
387. roduits 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 here the pre conditions and post conditions of 1 usages considermg the time synchronous asynchronous and the location same location different Click here to enter tex 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 utilisateur et l outil le contenu m diatis manipul les taches 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 conceptualisation 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
388. rojet 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 1 Avril Mal D 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 appli
389. ropice 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 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 moyen de communication entre utilisateurs experts analystes et d veloppeurs De plus l
390. rsonne 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 maitre 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 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 maitri
391. rtage 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 tre 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 boite 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 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 la demande de validations au profit de la recherche de conseils et
392. s 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 la 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
393. s 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 utilisent 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 d j identifier des objectifs relatifs 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 liorati
394. s 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 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 l
395. s de 4 principes maximiser l acceptation personnelle c 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 cotits 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 externe 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
396. s des repr sentations fig es des plans par exemple chaque tage des sp cifications techniques ou d autres documents n cessaires 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 maitre 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 rimentations et bilan DESCRII O Related Individual bier Usage Objective The user want to share multiple files grouped as CRTI weB documert USE CASES Insert here the use case agam MM
397. s 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 CR i T 2 Design phase The end of the design phase particularly called production phase eh N Zen 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 comprised of Executes Is composed of IP Diffuse design documents for construction enterpris Execution is based on plans provided by designer IP Diffuse design documents for designers team Fa ades 3Ds sections are based on plans provided by designer T Tape of 1s comme d Is comes of 1s composed of 1s composed d pu PE ZA Inform RK Share Inform Already supported by a service Need service support Need service support Alread
398. s 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 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 future 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 Simplified 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 JBM Systems Journal
399. s 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 congu 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 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 solution nouvelles fonctionnalit s changement de l 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 p
400. s concret d application Elles ne semblent cependant pas faire leurs preuves dans des cas r els de projet de conception et transfert des services 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 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 techniques 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 ava
401. s de conception par un expert Dans cette PC le concepteur fournit les documents de conception au maitre d ouvrage qui les soumet un expert pour valuation Souvent le maitre d ouvrage d l gue sa pratique un assistant la maitrise d 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 L
402. s donn es et les m thodes pour manipuler ces donn es par exemple ajouter 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 2 Contr leur Utilisateur n Commande _ Dimensions spatio temporelles et Utilisateur 2 fonctionnelles Interagit avec Mod le partag Mod le priv Se synchronise avec Fournit l information S actualise afficher Renseigne Utilisateur 1 Figure 113 Rappel le mod le Co MVC Ainsi le m ta modele 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 techn
403. s et support par les experts m tier C est 7 http www kitrygroup com Chapitre 2 Un cas de d veloppement d un outil de TCAO CRTI weB d ailleurs ce r le que nous avons tenu au cours de notre implication dans le projet ce qui nous a fourni un contexte d observation privil gi CS Transfert 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 dev
404. s mati res 12 1 2 Contexte des exp rimentations 216 12 1 3 Objectifs des exp rimentations 217 12 2 Exp rimentation n 1 L am lioration du service d upload de CRTI weB 217 12 2 1 Introduction et d roulement ss 217 12 2 2 Les pratiques de partage ss 219 12 2 3 Ee Tuer 220 12 2 4 Le choix et la sp cification de la solution impl menter 224 12 2 5 Conn Glens neon I 225 12 3 Exp rimentation 2 l automatisation du service d upload de CRTI weB 227 12 3 1 Introduction et d roulement ss 227 12 3 2 Un nouvel usage 228 12 3 3 Sp cifications techniques et d veloppement 232 12 3 4 eR EE 234 12 4 Exp rimentation 3 sp cification d un tableau de bord 235 12 4 1 Introduction et d roulement sis 235 12 4 2 Analyse des besoins m tier un maquettage comme point de d part 236 12 4 3 Identification et conception de l usage perspectives de d veloppement 238 12 4 4 RE en ertet etim icut d e eL Me rte s s te REA ERE 240 12 5 Conclusion apports des exp rimentations 241 12 5 1 RESUME LIU E E 241 12 5 2 Les trois E EE 244 Conclusion et perspectives everest v
405. s 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 l IDM 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 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 Figure 39 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 XML eXtendable Markup Langage mod lisation de la structure et du type de contenu d un document XML M1 gr ce une syntaxe c
406. s 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 1OS android autre les contr leurs de type clavier souris clavier touchpad cran tactile autre s il y a une connexion internet oui non inconnu s il y a une entr e vid o oui non inconnu s il 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
407. sation 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 taches abstraites acc de 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 apparait Elle saisit Nagoya comme ville de 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 t ches 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 c
408. se 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 oeuvre sont confi es par le maitre d ouvrage un architecte ou un entrepreneur En France la loi MOP loi relative la maitrise d ouvrage publique et ses rapports avec la maitrise d ceuvre priv e r git la nature de ces missions Par d finition le maitre d ceuvre 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 maitre 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 direction de l ex cution du contrat de travaux J rdonnancement 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 dis
409. se 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 distingue galement les usages dans un m me lieu 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
410. sfomation conteneur d filement autre graphique audio mat rielle Figure 97 Caract risation des intentions et des t ches 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 galement 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 arte
411. sid 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 exemple Figure 6 PERT ou Line Of Balance Yamin amp Harmelink 2001 Chapitre 1 La coordination dans les projets de conception construction architecturale Nov 0 Nom de la t che Debut Conception Maquettage Conception Maquetiage Documentation Validation cahier des charges Conception de l architecture technique Conception des d veloppements Ecrans Contr les S cur s Re sttutions Ratrakements Simulations tests techniques R alisation des d veloppements Ecrans Contr les S cunt s Re sttutions Retratements Simulations Rec ette fonctionnelle r alisation et 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 ap
412. sion 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 CRTI weB que de fichiers partag s Mais au regard des usages sp cifiques au m tier n
413. sionnel 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 tache 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 compte 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
414. 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 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 13 L entreprise orient e services 1 13 1 Le concept de service Un service est une prestation qui met 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 cette d finition en parlant de capacit autonome et transformationnelle qui est offerte et consomm e par des clients internes ou externes
415. 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 en cas de limites techniques ou sur la gestion des cas d erreur Consulte Mod lesde gt Produit pratiques Echanges a Utilisateur Expert m tier Concepteurs D veloppeur T on a T a em em Modeles d usages Modelesde services 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
416. struction 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 n 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 Introduction 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 de
417. t v rifient que les normes sont respect es pendant la mise en ceuvre 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 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 Maitre d oeuvre Coordinateur Plans d ex cution Documents techniques T ches de construction d valuation et de coordination Maitre 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 maitres 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 congu et
418. t 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 l IDM 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 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 celle 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 Im
419. t 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 adoptons un point de vue plus technique par la description de leur architecture logicielle Chapitre 5 De l entreprise orient e services la conception de Systemes 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 servi
420. t 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 sentation 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 ensembles 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
421. t de passe sont des donn es primitives Le syst me devra v rifier ces donn es l 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 b compared of composed of BE QA a 6 f Enter login 2 Enter password ks Abstract user interaction type Input els Abstract user interaction type Input ict SS Interact with e Interact with IO Name Logn TO Name Password Graphical spec text field Graphical spec text fied Attributes NIL data Attributes NIL panmibve data Data type text Data type text Properties Properties gt k composed of Is composed of 60 D Copy files in shared ae 4 2 m he Abstract user interacton type Navigation m gt See O Modify files in shared folder Fienema in sfured folder Abstract user mteracton type Command AN composed of Abstract user interaction type Input G t ee e Interact with Interact wath im Name Fle CU IO Name CRTI weB document Graphical spec Icon according to the type name Graphical spec ine n documents ist Attributes name fie type Attri
422. t 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 facon 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 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 a 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
423. t 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 riser 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
424. t 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 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 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 E PART 2 USAGE USAGE DESCRIPTION Related Individual Practice Click here enter text Usage Objective USER INTENTIONS Insert here the use case
425. texte 47 3 1 2 Formulation de la probl matique ss 50 3 2 M thode de recherch epe EEN EEN 50 3 2 1 La science de la conception sise 50 3 2 2 Concevoir une m thode de conception o 52 PARTIE 2 THEORIES ET METHODES CONCEVOIR DES SERVICES COLLABORATIES lt lt M P Chapitre 4 De l utilisateur la conception logicielle et d interfaces 55 4 1 Les m thodes et activit s relatives la conception logicielle sss 55 4 1 1 L volution des processus de coneeption enne 56 4 1 2 un processus it ratif er 57 4 1 3 Les activit s de d veloppement et leurs mod les seen 58 LES ACTIVITES DE TEST ET LE 05 4 14 LOS m thodes ss rec ie er gr E GRE S C cess Ee RERO 66 4 1 5 Constat et conclusion 68 4 2 La conception d IHM de l utilisateur Umterf ce 20200000 101 69 4 2 1 Vers une m thodologie de la conception enrichie seen 69 4 2 2 La mod lisation de l utilisateur et de son contexte 72 4 2 3 La mod lisation des t ches et du conten
426. tinction 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 Maitre 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 architecte 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 ceuvre 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 co
427. tion 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 MINERGIE DGNB autres pas de certification Chapitre 9 La mod lisation des pratiques le point de vue organisationnel certification num ration lt enumeration gt gt lt lt enumeration gt gt Type_certification Type_activit tache HOE 5 enumeration gt BREEAM Hosen Type activit phase MINERGIE coordination pr paration A 15 lt lt enumeration gt gt DGNB 1 conception Groupe d activit s Type_activit projet autre ex cution Hogement individuel de certification tlivraison Hogement collectif T che m tier batiment public lt lt enumeration gt gt Type_famille choix des concepteurs implication des usagers choix et valuation du site 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 SSS lt lt enumeration gt gt Type_r le concepteur maitre d oeuvre dessinateur g
428. tion 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 pour l dition de textes ex avec Google Documents mais aussi plus r cemment pour la cr ation de plans ex Autocad voir 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 9 2 D pu Share Collaborate Document Now Share amp Collaborate SERRE WR PTUS SEE Figure 8 Fonctionnalit s collaboratives dans l outil de CAO Autocad
429. tions m tiers Cas suppl mentaires Figure 102 Adaptation du formalisme des diagrammes de cas d utilisation 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 outil 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
430. tions utiles 11 faudrait mettre l adresse mail de l administrateur projet et non plus 538 info crti webGkitry 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 11 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 l metteur de notre choix lors de Non D tail fonctionnel 554 Cr ation d une page d accueil Non D tail graphique 11 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 E 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
431. 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 facon 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 pr conis d utiliser des repr sentations graphiques simples plut t que des mots ainsi que de simplifier la structure des taches 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 l implication du client a
432. ts history V2 Position of the user on site Highlighting of the buiding element under consideration Number of remarks for the building 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 assister 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 id
433. ts 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 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 Attributs possibles Formes possibles donn e 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 Curseur dans un mur num rique pas d attributs Tyssde hash re 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 c
434. u 75 4 2 4 Constat et conclusions eie HERE 81 4 3 Les enjeux de I Ing nierie et de Architecture Dirig e par les Mod les 82 4 3 1 Introduction l Ing nierie Dirig e par les Mod les DM 82 4 3 2 L architecture dirig e par les mod les 83 4 4 Conclusion vers une m thode centr e usages ss 87 E Chapitre 5 De l entreprise orient e services la conception de Syst mes d Information 89 5 1 L entreprise orient e service ANERER ene ea n e a HELPER 89 5 1 1 Le d Service ere EES 89 5 1 2 L architecture orient e services 90 5 1 3 Le service informatique ICT 5 1 4 La place des services ICT dans un business model comp titif 95 5 2 De la mod lisation des Processus M tier au Syst me 96 Table des mati res 5 2 1 Introduction la conception de Syst mes d Informations GI 96 5 2 2 La mod lisation du m tier et des processus 98 5 2 3 Du service m tier au service informatique 101 5 24 Les limites des approches bas es sur le Business Process Modeling BPM 102 53 Conclusion vers des services adapt s aux pratiques m tiers 103 rc neste ours Chapitre 6 Travail Collaboratif
435. u 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 taches concr tes sont possibles la tache 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 0 Concrete interaction task informer l utilisateur Les t ches syst me qui auront t identifi es dans le use case apparaissent galement amp Concrete perception task Chaque l ment du contexte coop ratif manipul par une op ration ainsi que d fini dans la partie 1 devient un contenu m diatiser Interaction Object lors de l usage 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 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 technolog
436. u 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 Chapitre 4 De l utilisateur 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 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
437. u 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 Model 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 704 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 of 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 HM 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 CAN12 Complexit
438. u 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 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 Groupe de travail But Connaitre les exigences du client Phase tudes pr liminaires Groupe de travail observations Connaitre le domaine d utilisation tudes pr liminaires Groupe de travail observations Connaitre les t ches m tier qu il faut accomplir tudes pr liminaires Interviews et questionnaires Connaitre l utilisateur et ses pr f rences tudes pr liminaires Observations sur site Connaitre le contexte tudes pr liminaires physique d utilisation valuer les alternatives laboration Construction d interaction obtenir des informations suppl mentaires sur les pr f rences Tests simulations 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 informatio
439. udes 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 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 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 Matin N 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 A H B os B A A gt A poss de A acc de B A contacte A et B changent A effectue La t
440. ulier Chapitre 9 La mod lisation des pratiques le point de vue organisationnel concerne implique Pratique Individuelle engendre concerne execute Groupe d artefacts groupe texte Acteur simple Groupe d acteurs 4 EE Figure 88 M ta mod le de la 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 1 1 3 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 1 7 1 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
441. 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 BIM 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 ceuvre 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 cycle de vie du projet travers les disciplines et les applications logicielles
442. 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 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 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 consid 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 ceuvre d activit s de diff rents types ass
443. up 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 Retrouverlesremarques Tache Nouvel usage de Meilleure compr hension gain de 387 decr ation ou par organisme i faites sur un CR contenu des temps Le filtrage des remarques associ es 389 plusieurs organismes ne devrait faire 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 manque les ic nes d action pour Compte D tail graphique Ajouter la date de la mise jour de l indice Mettre jour un Identifier les dates de Meilleure compr hension gain de 435 pour plus de visibilit i document de travail Contenu Mai temps 436 Modifier l image par d faut des projets ne NIL D tail graphique
444. upporte 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 tache dite concr te qui peut tre de l ordre de l 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 11 2 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 d interaction criture choix d clenchement manipulation transformation d filement autre de perception graphique audio mat rielle Trois relations caract risent un processus de t ches 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
445. ur 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 Tache identifier les personnes Meilleure compr hension gain de 521 organisme Oui d un collaborateur Contenu d un organisme temps 11 faudrait ajouter 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 lavisibilit des documents dans CRTI weB 536 R diger les questions mettre dans la FAQ Non G n ral Nouvel usage de Informa
446. usage int interfaces Resevation ReservstionsSenice I 1 Select TimeSiot T click Select lini dem selectT imeSlotFomResenadieTimeS go System adds time ENS reserved time slot lis E G n ration Figure 41 Les mod les et leur transformation dans l approche MDA de Kalnins H otLis TimeSiot 0 served i meSiotL ge served TimeSiotList Add timeSlot reservabie imeSiotLa reservadleTimeSiot_ is Remove timeS ot defectus Le Faolty TT PI M t meSit TimeSict acceptResa vaton Summary vod confirm Reserved T meSictu go vod imvoim changeO spiayCrtena vod reservations vod miec acityFromRemrvysoieF st F aolity void se iectT meSiotF rom Remevesie Ti meSiotu meSiot vod du PIM 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 travers des composants r utilisables Puis le point d entr e de la conception lo
447. vices 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 entre 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
448. viduelle 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 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 communiqu e ex le syst me poss
449. viduels Dans le cas d tude pr sent une soci t de d pannage les processus de travail sont tablis et fig s 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 comment 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
450. vue op rationnel Designer Diffusion des documents produits Responsable de diffusion 22 ct Executes Uh des concepteurs expose les choix conceptuels de l quipe pour valuation Is composed of Is composed of e Share Inform Already supported by a service Already supported by a service Uses Targets 8 Geometral Group type Agency Plans du projet au stade APS Designer Author Designer lt Add here more specifittes if needed Status In Progress Figure 103 Rappel mod lisation de la pratique diffusion des documents USAGE DESCRIPTION Related Individual i 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 include gt gt s USAGE CONTEXT eS USAGE EE emporalit once a day Op CRTI weB classic user Identification ea Ee Figure 104 Contextual Use Case de la pratique diffuse design 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 fi
451. y supported by a service Tages Graphic designer B Geometral Designers according to the tasks they have to perform Plans of the project ges EN CH Message type Notification Specifications N 29 Group type Enterprise Sp ctiications about material and equipment 4 notification of shared documents can contain specf ic instructions 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 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 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 construction Nous observons comment dans un m me projet la diffu
452. ynchrones 4 distance asynchrones Relation entre usages d termine d termine Temporalit type_temporalit num ration Localisation type_lieu num ration Figure 100 Caract risation de la relation entre usages 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 Relation entre usages synchronisation type_colocalisation Usage Pratique colllective Objectif texte Nom texte famille num ration Description texte 1 8 1 1 diatise Utilisateur 14 Pratique Individuelle Nom texte 1 Description texte 1 repr sent 05 1t Acteur ex cute Type_acteur num ration Type_r le num ration D nomination texte Type_r le_op texte Identification oui non 1
453. ypage 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 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 S Plaquette desc
454. yst 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 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 Related Individual Site monitoring Usage Objective se shouid be able to consult remarks about defects on building elements and add new here the use case diagram SHARE eia pee A EE UM LEE 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 chantie

Concevoir des services collaboratifs adaptés à des pratiques métier

Contents

Download Pdf Manuals

Related Search

Related Contents

Concevoir des services collaboratifs adapt&eacute;s &agrave; des pratiques m&eacute;tier

Contents

Download Pdf Manuals

Related Search

Related Contents

Concevoir des services collaboratifs adaptés à des pratiques métier