méthode de capitalisation mémoire de projet

ISS

N 0

249-

6399

appor t de r ech er ch e

INSTITUT NATIONAL DE RECHERCHE EN INFORMATIQUE ET EN AUTOMATIQUE

Méthodes de capitalisation de mémoirede projet

Nada MATTA, Olivier CORBY, Myriam RIBIERE

N˚ 3819Novembre 1999

THÈME 3

Interaction Homme-Machine, Images,Données et Connaissances

I N S T I T U T N A T I O N A L D E R E C H E R C H E E N I N F O R M AT I Q U E E T E N AU T O M A T I Q U EUnité de recherche INRIA Sophia Antipolis :2004, route de Lucioles- B.P. 93- 06902 Sophia Antipolis cedex (France)

Téléphone : +33 4 93 65 77 77 - Télécopie : (33) 493 65 77 65 - Télex : 970050 F

Établissement public national à caractère scientifique et technologique - Décret No 85.831 du 2 août 1985

Méthodes decapitalisationdemémoire

de projet

NadaMATTA* , Olivier CORBY** ,Myriam RIBIERE***

Thème INRIA 3A : Interaction Homme-Machine,Images, Données et Connaissances

Projet ACACIA

Rapport de recherche n˚3819

Novembre 1999

71 pages

Résumé: L’avènementdestechnologiesdel’information ouvredenouvellesperspectivesde partaged’informationset d’expériencesentreles différentsacteursdel’entreprise.Dansle cadredela conception,le partaged’expérien-cespeutaider les concepteursà résoudreles problèmesde conceptionet àéviter leserreurspassées.Danscecadrenousavonsanalyséun certainnom-bredeméthodesdecapitalisationdeconnaissances,présentesdansla littéra-ture,afin d’offrir un guideméthodologiquepour la constructiondemémoirede projet. Nous présentons cette analyse dans ce rapport.

Mots-clé : Mémoire de projet, Capitalisation des connaissances, conception.

(Abstract: pto)

* Email: [email protected]** Email: [email protected]*** Email: [email protected]

Methods forCapitalization of aProject Memory

Abstract: The advent of information technologies offers new perspectives forinformation sharing and experience sharing among the different actors in acompany. In this framework, experience sharing can help the designers tosolve design problems and to avoid past errors. In this report, we analyse sev-eral knowledge capitalization methods proposed in literature and we definemethodological guidelines for building a design project memory.

Key-words: Project Memory, Knowledge Management, Design.

Méthodes de capitalisation de mémoire de projet 3

Remerciements

Noustenonsà remercierJeanPierreHeckmann,PerrineSegurraetRé-gineNigris de l’Aérospatiale-Aéronautique,pour leur remarquesconstructi-ves qui nous ont été utiles dans la définition du modèle.

NoustémoignonsaussinotregratitudeàRoseDiengetauxmembresdel’équipe Acacia de l’INRIA-Sophia-Antipolis. pour les discussionsfertilesmenées au sein de l’équipe.

4 Nada MATTA, Olivier CORBY, Myriam RIBIERE

Table de MatièresIntroduction 5

Chapitre 1 : Définition de la mémoire de projet 6

Un modèle de mémoire de projet 6Mémoire de caractéristiques de projet 6Mémoire de logique de conception 7

Chapitre 2 : Méthodes de capitalisation dédiées mémoire de projet 8

La méthode IBIS 8

L’approche QOC 11

Le système DRCS 13

Le système DRAMA 19

L’approche EMMA 21

La méthode SAGACE 23

Discussion 26

Chapitre 3 : D’autres méthodes de capitalisation 29

La méthode REX 29

La méthode MKSM 34

La méthode CYGMA 40

L’atelier FX 47

L’approche Componential Framework 49

La méthodologie CommonKADS 52

Discussions 56

Chapitre 4 : Guide de construction de mémoire de projet 59

Capitalisation des caractéristiques de projet 59Capitalisation de l’organisation d’un projet 59Capitalisation des résultats 61

Capitalisation de la logique de conception 61Transcription directe 62Capitalisation après coup 64

Conclusion 66

Bibliographie 67


Introduction

La concurrenceactuellesur le marchéamèneles concepteursà tenterd’augmenterla qualité desproduitsà descoûtstoujoursplus faibles [14].L’avènementdestechnologiesdel’information ouvredenouvellesperspecti-vesdepartaged’informationset d’expériencesentrelesdifférentsacteursdel’entreprise [32].

L’expertiseformeuncapitalimportantdansuneentreprise.La pertedecetypedeconnaissancesapoussélesentreprisesàchercherunmoyendelescapitaliseren vue d’une réutilisationultérieure.Plusieursméthodesont étédéfiniesou adaptéesdel’ingénieriedesconnaissancesà ceteffet.Nousnousintéressonsdanscerapportà la capitalisationdesconnaissancesliéesàla réa-lisation de projets de conception.

Lescaractéristiquesd’un produitsontengénéraldéfiniesdanslesfour-nitures(documentsdespécification,cahiersdescharges,documentstechni-ques,...)[1] produitesà chaqueétapedesondéveloppement.Lesproblèmesrencontrésdansun projet de conceptionainsi queleur résolutionsontrare-mentformalisésenvued’uneutilisationultérieure[17]. Cettepartied’un pro-jet estaussiimportanteàmémoriserquelescaractéristiquesd’un projetetsonorganisation.

Dansle but deproposerun guideméthodologiquepourla constructiond’unemémoiredeprojet,nousavonsanalyséuncertainnombredeméthodesdescapitalisationdeconnaissancesprésentesdansla littérature.Certainesdecesméthodesontétéconçuespouraideràla définitiond’unemémoiredepro-jet, d’autressontplusgénérales.Danscerapport,nousprésentonscetteana-lyse.

Notrecollaborationavecl’Aérospatiale-AéronautiqueàToulouse,nousa permis de valider et d’enrichir notre approche.

Dansle premierchapitre,nousrappelonslesdifférentespartiesàconsi-dérerdansunemémoiredeprojet.Puisnousprésentonsdansle secondcha-pitre lesméthodesdecapitalisationdédiéesà la mémoiredeprojet.Danslechapitre3, nousprésentonsd’autresméthodesdecapitalisation.Dansle cha-pitre 4, nous décrivonsnotre guide méthodologiquepour la constructiond’une mémoire de projet.


Chapitre 1 : Définition de la mémoire deprojet

Nousdéfinissonsunemémoiredeprojetcommeunemémoiredescon-naissances[10] etdesinformationsacquisesetproduitesaucoursdela réali-sationdesprojets.Notre définition rejoint cellesdonnéesdansla littératurecomme:

"Lessonsandexperiencesfrom givenprojects"[26] et "Projectdefini-tion activities, history and results" [31].

Nousnousfocalisonsdanscerapportsur la mémoiredeprojetdansledomaine de la conception.

Unemémoiredeprojetdoit doncdonneraccèsà desinformationsdé-crivantaussibienlescaractéristiquesd’un projetquecellesrelativesà la ré-solutiondesproblèmesrencontréslors dela réalisationdu projet.C’estdansce sens que nous avons défini un modèle de mémoire de projet [21].

1 Un modèle de mémoire de projet

Nousproposonsunmodèledemémoire[21] qui respectela descriptiond’un projet,tout enmettantà jour lesconnaissanceset lesinformationsdontlesconcepteursont besoindansleursactivités.Notremodèlesedécomposedonc en deux parties :

•Mémoire de caractéristiques de projet

•Mémoire de logique de conception ("Design-rationale")

1.1 Mémoire de caractéristiques de projet

Cettemémoirepermetd’indexerlesinformationsqui décriventle con-texte d’un projet, son organisation et ses résultats:

•Contexte:Directiveset méthodesde conception,Exigences,Règle-ments

•Organisation:Tâches(définition et distribution), Participants(sous-groupes, tâches affectées).

•Résultats:Maquettes,Matériel, Logiciel, Documentstechniques,Es-sais


Chaqueélémentdecettemémoiredonneaccèsauxinformationsextrai-tesàpartir desdifférentesressourcesdel’entreprise:Basesdeconnaissancesd’aideàla conception,Basesdedonnées,donnéesextraitesdesoutilsdecon-ception, données extraites des outils de gestion, prototypes, maquettes, etc.

1.2 Mémoire de logique de conception

Cettemémoiremetenavantlesconnaissancesinvestiesdansla prisededécisiondansla réalisationd’un projetainsiquedansla gestiondesincidents,à savoir les problèmes rencontrés et leur résolution:

•Problèmesrencontrés:Sujets(Propositionsdeconception,Exigences,Règlements),Nature,Elémentsdeproblèmes.Notonsqu’un problèmepeutêtreaussibienunobjectifàatteindre,unproblèmedansle proces-susdeconception,dansl’organisationduprojetqu’unproblèmedupro-duit en conception.

•Résolutiondeproblèmes:Participants,Personnesimpliquées,Métho-des de résolution, Choix potentiels.

•Evaluation des solutions: Solution rejetées,Arguments de rejets,Avantages et inconvénients.

•Décision: Solution retenue, Arguments, Avantages et inconvénients.

Afin deproposerun guideméthodologiquepourla constructiondecesdeuxpartiesd’unemémoiredeprojet,nousavonsanalyséaussibiendesmé-thodesdédiéesmémoiredeprojetquedesméthodesplusgénéralesdecapita-lisation des connaissances. Nous présentons dans ce qui suit, cette analyse.


Chapitre 2 : Méthodes de capitalisationdédiées mémoire de projet

Plusieursapprochesdecapitalisationdesconnaissancesdansunemémoiredeprojetont étéproposées.Danscequi suit, nouscitonsun certainnombredecesapprochesqui sontdéfiniessoit pour la conceptionsoit pourd'autresdo-maines.

2 La méthode IBIS

Cetteméthodeaétédéfiniedanslesannées70parHorstRittel etal, ci-téedans[18], [7], [8] et[9]. L'objectifdelaméthodeétaitàl'époquedefournirunestructurepour le dialoguemenélors dela résolutiondeproblèmescom-plexesdeconception.Depuis,la méthodeaévoluéetplusieursoutilssupportont étédéveloppés.La méthodeestactuellementutiliséepour représenterlalogique de conception (Design Rationale) dans un projet.

La méthodeIBIS sebasesur unestructurationde la prisede décisionmenéedansunprojetdeconceptionentroiséléments:Questions(Issues),Po-sitionset Arguments.Dansunediscussion,unequestionprincipaleestgéné-ralementposée«Commentpeut-onréaliser?».Un participantpeut prendreuneposition,enproposantuneréponseà la questionposée.Il défendsaposi-tion avecdesarguments.D'autresparticipantsproposentd'autresmanièresderésoudrele problèmeposéendéfinissantdespositionsalternativesetenénon-çantdesarguments.Les argumentspeuventêtredesargumentsde supportpourla positionoudesargumentsd'objectionpourd'autrespositions.Denou-vellesquestionsapparaissentdansla discussion.Cesquestionspeuventêtreliées aux questions qui les ont suggérées (Figure1).


Figure 1. Les principaux éléments de la méthode

Neuf liensont étédéfinispourrelier questions,positionset arguments.Il s'agit de:

•Position répond à Question

•Argument supporte Position

•Argument s'oppose à Position

•Question généralise Question

•Question spécialise Question

•Question évoque Question

•Question est suggérée par Question

L'ordre de prisede décisionestaussisuivi aveccetteméthode,puis-qu'ellepermetdereprésenterun historiquedesdécisionstout le long du pro-cessusde conception.En effet, la méthodeestprésentéecommenarrative.Elle permetdeprendrenotedela prisededécisionàchaqueétapeduproces-susdeconception.Pourcela,on l'appelle«approcheorientéeprocessus».LaméthodeIBIS aétéappliquéedansdifférentsdomainesdeconception.Citons,


parexemple,ledéveloppementdescontrôleursdestationsinformatiqueschezNCR.

Un outil desupportgIBIS (Graphicalhypertextsoftwaretool for buil-dingIBIS network)estfourni aveclaméthode.Nousleprésentonsdanscequisuit.

L’outil gIBIS

L'outil gIBIS [9] estdisponiblesurStationSunetexploiteunréseauen-tre différentsutilisateurs.Il exploiteaussiun systèmedegestiondebasededonnées pour gérer les informations sauvées à travers l'outil.

Deux typesde liens ont été ajoutéscommeextensionde la méthodedansl'outil. Il s'agitde"Other"permettantàunutilisateurdespécifiersonpro-prelien et "External"fournissantun accèsversdesdonnéesexternescommedesdocuments,desimages,etc.De même,lesliens"Generalize"et "Specia-lize" peuvent être aussi définis entre les arguments.

L'interface de l’outil gIBIS est formée de quatre fenêtres (Figure2):

•FenêtreGraphique,permettantunaffichagedesélémentsdela métho-de(Questions, Positions, Arguments,...) en noeuds et liens.

•Liste de noeuds ordonnés suivant la date de création des questions.

•Fenêtre de Commandes générales.

•Fenêtrede Description,permettantl'affichagede la descriptiondesnoeuds etde leurs attributs.


Figure 2. L'interface principale de gIBIS.

Desvueslocalessontpermisesàtraversle grapheainsiqu'unevueglo-balede tout le processus.De même,desnotationscomme+, -, ?, etc.dési-gnantdesargumentsdesupport,d'objection,despositionsnonchoisies,etc.sontdéfiniescommeunemarquesurlesliensentrelesnoeuds.Despossibili-tésderecherched'unnoeudsontaussioffertesdansl'outil. Unefenêtredere-quêtepermetdedéterminercertainespropriétésdu noeudrecherchécomme:le typedu noeud,la datedecréation,l'auteur,le label,le sujet,certainsmotsclés,etc.La recherchesefait suivantunsimplefiltrageentrelespropriétésdunoeud recherché et les noeuds du graphe.

3 L’approche QOC

L'approcheQOC«Questions,OptionsandCriteria»[5], [6], [7], [15] et[19] a pourobjectif dereprésenterla logiquedeconception("DesignRatio-nale") nomméeaussianalysede l'espacede conception.Cetteapprochere-commande de représenter cette analyse sous forme de:


•Questions: les questions et problèmes posés lors d’une conception.

•Options: les différentes réponses données à ces questions.

•Critères: les critères qui permettent de discriminer telle ou telle option.

L'approcheQOC ne fournit pasunereprésentationdu processusde conceptionmaisplutôtuneanalysedela prisededécisiondansla conception.Lesauteursdel'approchecon-sidèrentque l'espacede conceptionpeutêtrereprésentépar deschoix de conception.Ceschoix sontstructuréscommeréponseauxquestionsévoquéespar lesproblèmesdeconcep-tion. Descritèressontutilisésdansle choix decertainesoptionscommesolutionet réponseàunequestion.Desargumentspeuventjustifier leschoixd'uneoptionsuivantuncritèredon-né.Un critèrepermetaussiderendreexpliciteuneou plusieursexigencesdissimuléesdansla question.Unestructurationde l'espacedeconceptionpeutalorsêtreobtenuesousformed'association de questions, options et critères (Figure3).

Figure 3. Représentation de la prise de décision selon QOC.

Lesoptionsgénèrentd'autresquestionsauxquelleslesconcepteursrépondentpardesoptions.L'associationdesquestionspourspécifierdesoptionsfournit unestructurecomplé-


mentairede la prisededécision.Cettestructureprésenteunedécompositiond'optionsensous-options (Figure4).

Figure 4. Décomposition d'options en sous options.

4 Le système DRCS

DRCS("DesignRationaleCaptureSystem")[16] estunsystèmequi permetderepré-senterla logiquedeconceptiondansunprojeteningénierieconcourante.Il estimplantéenCommon-Lispet exploiteun réseaudestations.Le systèmepermetun travail collaboratifet utilise des liens hypertextes.


Figure 5. Décomposition de modules en sous modules.

Un artefactdansDRCSestdéfini en modulesinter-connectéssuivantdesinterfaces(Figure 5). Desattributspermettentde décrireceséléments.Notonsquelesressourcesd'unmodulesontmisesenévidenceparuneclasseparticulièred'attributs.Le plandeconceptionestdécritsuivantunesuiteor-donnéedetâches(Figure 6).Desactionsprimairessontassociéesauxtâches.

Figure 6. Représentation des tâches.


DRCS se base sur un langage de représentation «DRCS language».

Figure 7. Modèle synthèse: Représentation de l'artefact.

Le langage DRCS

Le langageDRCSpermetdereprésenterl’artefactet le plansuivi dansla conception.Deuxprincipalesprimitives sontoffertesdansce langage:1-entité,permettantla représentationd'objetset d'assertions,2- relation,per-mettantla définitionderelationsentrelesentités.L’artefactet le plansontre-présentés par des graphes d'entités/relations.


Cinq typesde modèles,dûsaux différentstypesde relationsutiliséesentrelesentités,ontétédéfinispourreprésenterla logiquedeconceptiondansun projet:

•Un modèleSynthèse(«Synthesis»)permettantde mettreà jour destaxinomies(utilisant le lien "is-sub-type-of")une décompositiondel’artefactenmoduleset sous-modules(Figure 7) et l'associationentretâches et modules réalisés par ces tâches (Figure8).

Figure 8. Modèle Synthèse: Description des relations d'une tâche.

•Un modèleEvaluationpermettantdereprésentercommentlesspécifi-cations de l’artefact ont été atteintes (Figure9).

A comme prioritéA une priorité supérieure àA comme sous-tâcheA une relation temporelleEst sous-type de

TâcheAssertion A commeaction

A comme Plan Module

A comme attribut

Attribut A comme valeur Contrainte


Figure 9. Modèle Evaluation.

•Un modèleIntentionpermettantde mettreen évidenceles décisionspriseslorsdela résolutiondesproblèmesainsiquelesstratégiesqui endécoulent (Figure10).

Figure 10. Modèle d'Intention.

A com

me spécification

Est sous-type deA comme importanceEst plus important queA comme attribut

Attribut Spécification

Réalise

Version

A comme sous-spécificationEst plus important queA comme importanceEst sous-type de

A comme prioritéA une priorité plus grande que

Assertion Evoque Question Problème A commeStratégie

Plan stratégiqueTâche de haut niveau


•Un modèleVersionspermettantdemontrerlesalternativesdeconcep-tion et quellessontcellesqui peuventrésoudreun problèmerencontréou trouver une solution à un conflit donné (Figure11).

Figure 11. Modèle de Versions.

•Un modèleArgumentationpermettantdemontrerle typed'argumenta-tion apportée à une alternative (Figure12).

Conflitabandonnéou suspendu

A comme Versionstatut

A comme prioritéA une priorité plusgrande que

Est résolu par

A comme optionEst la meilleure option

Problème


Figure 12. Modèle d'Argumentation.

5 Le système DRAMA

DRAMA [4] estun logiciel défini surPC.Il permetdegarderunetracede la logiquede conception("Design-rationale")d'un projet de conception.DRAMA permetdereprésenterlesbuts,lesoptionsdesolutionsainsiquelechoix d'options,suivantun arbredesolution(Figure 13).Unetabledecritè-res(Figure 14)permetaussid'illustrerle choixd'uneoptioncommesolutionà un but donné.

Question

A comme réponse

Evoque

Recommandation

A com

me résultat

Procédure

Est sous-type deA commesous-procédure

SupporteQualifieDéniePrésuppose

A comme entrée


Figure 13. Arbre de solution.

Des liens hypertextessontofferts dansle logiciel. Ils fournissentdesliensversdesdocuments,desdessinstechniques,dessimulations,etc.DRA-MA permetaussidegénérerd’une façondynamiquedesrapportsen formatHTML, àpartirdesarbresdesolutionetdestablesdedécision.Il permetd'ex-trairedesdonnéesdeBasesdedonnéesetdelesprésenterenexploitantle lan-gage XML.

Uneinterfacegraphiqueestfourniedansle logiciel. Elle permetdedé-finir aussibiendesarbresdesolutionquedestablesdedécision.Elle permetaussid'afficherdifférentstypesdedocuments:textes,dessins,etc.Desfonc-tionnalités de recherche sont aussi présentes dans DRAMA.

Figure 14. Table de décision.

CRITERE OPTION 1 OPTION 2 OPTION 3

Performance 1 2 3

Débit 1 2 3

Coût 3 2 1

Installation 4 1 1

Score 0 -2 -1

Rang 3 2 1

Décision Rejeté Rejeté Accepté


Le systèmeestbasésurunearchitectureclient/serveurqui offre un ac-cèscoopératifàungroupedeconcepteurs.Il estutilisédansdifférentesappli-cationsdeconceptiondansledomainedel'énergiepétrolière.Il peutêtreaussiappliqué dans des domaines autres que la conception.

6 L’approche EMMA

L'approcheEMMA ("EvolutionMemoryManagementAssistant")[22]estuneapprochedereprésentationdesconnaissancesutiliséesdansunprojetdeconceptionde logiciels.Cetteapprochefournit un modèledereprésenta-tion appelé"MetaModel" qui permetde décrirele processusde conceptiond'unlogiciel sousformedebutsàatteindre.Le principedebasedel'approcheconsiste à distinguer dans un processus de conception :

•Les buts à atteindre.

•Les plans définis pour atteindre ces buts.

•Le contexte des plans définis

•Les changements apportés ainsi que l'évolution du processus.

Le processusdeconceptionestdoncreprésentécommeunestructuredesolutionqui metenassociationlesbutsaveclesplansqui leur sontdestinés.Un planestdécomposéensous-butsalternatifs(Figure 15).Un ensembledeprimitives est fourni à cet effet. Notons parmi elles:

•But dela solutionassociée.Il estdéfini parsonnom,sadescriptionetdes références.

•Spécificationdela solutionassociée.Elle estdéfinieparle type,la des-cription et un ensemble de propriétés.

•Contexte.Il estdéfini parlestermesutilisés,leshypothèsesdesolutionet les ressources.

•Elaboration.Elle estdéfinieparlesplansalternatifs,unplanactif choi-si etlesjustificationsduchoix.Cesjustificationspeuventavoirdesliensavecdesdocumentshypertextesouavecunestructured'argumentspro-venantd'autrestypesde représentationcommecellesdéfiniesdanslaméthode IBIS.

•Informationssur la collaboration.Elles mettenten évidenceles pro-priétairesd'un but et les sous-traitantsfournisseurdu plan qui permetd'atteindre le but.


•Informationssur l'évolution du but. Il s’agit d’une descriptiondeschangements qui affectent le but.

•Cesprimitives sontassociéesà la descriptiond'un but. De mêmeunplan peut être défini par:

•Elaborationqui metenévidencele butdu travail (unespécificationdubutpère)etunensembledesousbutspermettantd'atteindrele butprin-cipal.

•Informationssur la collaboration.Ellesprésententles sous-traitants,auteurs du plan.

•Informationssurl'évolutionduplan.Ellessontdécritespar:- desévé-nementsdechangement,émisparle planousouscritsparlesbutspères,- desréponsesanticipéesaux changements,- desenregistrementsdeschangementsoud'exceptions(ils sontdécritsparle nom,la description,les circonstances et les actions).

Figure 15. Représentation en buts/Plans.

Un événementde changementestdécrit par un nom,unedescription,descirconstanceset éventuellementdesdescriptionsdeschangementsà ap-porter au processus.


Uneexceptionprovientd'uneconstatationqu'unbutnepeutpasêtreat-teint,dansuncontextedonné.Elle estdécritepar:unnom,unedescription,lenomdu sous-traitantémetteurdel'exception,le nomdu but pourlequell'ex-pressionaétéémiseetéventuellementleschangementsàapporterauproces-sus. Les exceptions peuvent être définies dans le plan de travail d'un but.

L’outil EMMA estdéveloppéenJava.Il estbasésurdesinterfaceshy-pertextes.Il permetauxconcepteursetauxgestionnairesdelogicielscomple-xesd'explorer,dechoisiret dedocumenterdemanièrecoopérativelessolu-tions envisagées.

7 La méthode SAGACE

La méthodeSAGACE[23] et [24], développéeauseinduCEA acom-meprincipedebasela modélisationdesconnaissancesstatiquesdécrivantunsystèmedeproduction.Cettemodélisationfournit unebasededialogueentrelesdifférentsacteursdansunprojetetuneaideauchoixdesmoyensd'actions.Elle peutêtreainsiexploitéepourmémoriserla réalisationd'unprojetdepro-ductiond'unsystème.Le systèmeproduitpeutêtreà"forte automatisation",à"fortecomposantehumaine"ouà"forte identité"commeparexemple,unsys-tème à base de connaissances.

Figure 16. Les trois visions définies dans SAGACE.


Cettemodélisationsebasesurtroistypesdevisions: Fonctionnelle,or-ganiqueet opérationnelle(Figure 16). Les visionssontdécritesà l'aide detrois principaux éléments: Processeur, Flux et Observateur (Figure17).

Un Processeurdécrit une activité qui réagit avecson environnementsousformed'unFlux.CertainescaractéristiquesduFlux sontobservables.El-les sont appelées Observateurs.

Figure 17. Trois éléments qui représentent les données dans les visions.

Un processeur change de statut d'une vision l'autre :

•Dansla vision fonctionnelle,un processeurdécrit : unefonction, lescontraintesdeconception,lesobjectifset lesactivitésmisesenoeuvre.

Processeur

Mission

Processus

Information Conditionnelle

Information de représentation

Observe


•Dans la vision organique, un processeur décrit : les ressources et lesmoyens.

•Dans la vision opérationnelle, il décrit la tâche et les acteurs.

Par exemple, dans les systèmes technologiques, les trois visionsreprésentent:

•les fonctions de service (vision fonctionnelle),

•les composants (vision organique),

•l'activité des utilisateurs (vision opérationnelle).

Dansuneorganisation,la visionorganiquedécritlesacteurshumainsetla vision opérationnelledécrit lesconditionsde leur coopérationcommelesrèglesinstauréeset lesobjectifssous-jacents.Dansunsystèmeàbasedecon-naissances,la vision fonctionnellereprésentela stratégiede résolutionalorsquelavisionorganiquedécritlesinférences.Lavisionopérationnellecontientles tâches contrôlant le raisonnement.

Un élémentduFlux estreprésentéparsonnometsonsupportousafor-me. Ces éléments sont classés en quatre types:

•Entrée (axe horizontal et flèche de gauche)

•Sortie (axe horizontal et flèche de droite)

•Informationconditionnelle(axeverticalet flèched'enhaut);cesinfor-mationsreprésententuneconditiond'exécution,unecontraintedepilo-tage ou une contrainte de sélection de moyens

•Information de représentation (axe vertical et flèche vers le bas); cesinformationspeuventdécrirel'exécutiondela mission,le déroulementdu processus et une configuration du processeur.

Un Observateurmet en avantunecaractéristiqueobservabled'unélé-mentduFlux. Il estreprésentéparuneellipseavecunnomreflétantla naturedela caractéristique,(parexemple,Débit,etc.).Il estprésentésurla flècheduFlux. Un observateura desattributscommedéfaut,alarme,tendance,etc.L'ensembledesobservateursdéfinispourunsystèmereflètele comportementdu système, son évolution et sa réaction avec son environnement.


Lesélémentsainsimodélisés,formentunréférentieltechniquequi peutêtrereprésentédansunebasededonnéesrelationnellesouobjets.Ceréféren-tiel estaucoeurdu systèmed'informationsupportantla réalisationtechniqued'un projet.

Un atelier"Systémographe"développépar la sociétéACTION permetla représentation des éléments modélisés.

8 Discussion

Nousavonsprésentédanscettepartieun ensembledeméthodeset desystèmesproposéspouraiderà la capitalisationdesconnaissancesdansunemémoiredeprojet.Certainesdecesméthodessontdéfiniespourreprésenterles connaissancesrelativesà la prisede décisionissuesdesréunionset desdiscussionsmenéesdansunprojet.D'autresméthodesfournissentdesforma-lismespour décrireles résultatsintermédiaireset pour supporterla gestiond'un projet (l'organisation, le planning, etc.).

La plupart des méthodessont dédiéesà des projets de conception.D'autressontplusgénérales.Le tableausuivantfournit unrécapitulatifdesca-ractéristiques des méthodes présentées.

Approche Représen-tation delaprise dedécision

Représentation desrésultats

d’un pr ojet

Représen-tation delagestion duprojet

Outils défi-nis

Typed’applica-tion

IBIS Arbre:Question/Position/Argument

gIBIS Conception

QOC Arbre:Question/Option/Cri-tère

Conception


DRCS Graphe:Entité/Rela-tion

Modèles:Synthèse,Evaluation,Intention,versions etArguments

Graphe:Entité/Rela-tion

Décomposi-tion ensousmodules

Planning:Suite detâchesordonnées

SystèmeDRCS

Concep-tion, sur-tout dansl’Ingénierieconcourante

DRAMA Arbre desolution:But/Option

Table decritères

DRAMA Conception+ autres

EMMA Méta-Modèle:But/Plan

Attributs:Contexte,Elabora-tion, Colla-boration,Evolution

EMMA Conceptionde logiciels

SAGACE Graphe:Processeur/Flux/Obser-vateur

Fonction-nelle, Orga-nique etOpération-nelle

Systémo-graphe

Tout typed’applica-tions



d’un pr ojet


Outils défi-nis



D'autresapprochesont aussiétédéveloppéespour capitaliserles con-naissancesàpartirdedocumentstextuels,d'expertsoud'autrestypesdesour-ces. Nous présentons de telles approches dans le prochain chapitre.


Chapitre 3 : D’autres méthodes decapitalisation

Plusieursméthodesontétédéfiniesparticulièrementpouraiderla capi-talisationdesconnaissances.D'autresméthodesont étéempruntéesà l'ingé-nierie desconnaissanceset adaptéespour aiderà la définition de mémoiresd'entreprise.Nousprésentonsdanscechapitreunpanoramadecesméthodes,afin dedonnerunevisionglobalesurlesdifférentessortesdeméthodesdeca-pitalisation de connaissances existantes.

9 La méthode REX

La méthodeREX [20] a étédéfinieaudépartdansle but decapitaliserlesexpériencesdeconceptionderéacteursnucléairesauseinduCEA.La mé-thodeaétéensuiteutiliséedansdiverstypesd'applicationstelsquela spécifi-cationdesystèmesdecontrôledansle domaineélectrique,la conceptiondegénérateurs électriques, la conception aéronautique, etc.

Le principedebasede la méthodeconsisteà constituerdes«élémentsd’expériences»,extraitsd'uneactivitéquelconqueet à restituercesélémentspourqu'unutilisateurpuisselesvaloriser.Lesélémentsd'expérienceainsidé-finis sontstockésdansunemémoired'expérienceappelée(CEMem)avantd'être restitués (Figure18).


Figure 18. Principe de base de la méthode REX.

Il s’agit d’un cycle de constitution d’élémentsd’expérienceà partir del’expérienceacquisependantla réalisationdesactivités dansuneorganisa-tion, ainsiquede l’extractiondecesélémentsdansuneoptiquedevalorisa-tion de l’expérience en un savoir-faire, utile dans la réalisation des activités.

Eléments d'expérience

Un élément d'expérience (Figure19) est typiquement défini par:

- un entête,

- une description ou corps,

- une liste de références.

Le corps est décomposé lui même en trois parties:

- une description neutre d'un fait,

- une opinion propre et des commentaires,

- des recommandations


Les élémentsd'expériencesontconstruitsprincipalementà l'issuedesentretiensauprèsd'expertsetàpartir desdocumentsrelatantuneactivité(i.e.documents de synthèse, bases de données).

Unquestionnairedoit êtreélaboré.Il formeunebasepourlecogniticiendansunentretienavecunexpert.Il permetd'éluciderlesélémentsd'expérien-ceset leur description.Trois entretiensd'unedemiejournéechacunsontre-commandés à ce propos.

Le premierentretienestmenéd'unemanièrelibre etviseàidentifier lespersonnesconcernéesparunthèmeparticulieretàcollecterleuravis.Le texterecueilli à l'issuedecetentretiensertà identifier plusieursélémentsd'expé-rience correspondant aux différents faits cités.

Au coursdu deuxièmeentretien,un ensembleprovisoired'élémentsd'expérienceestprésentéà l'expertqui peutmodifier leurcontenuet lesenri-chir.

L'objectif du troisièmeentretienestde vérifier si toutesles modifica-tionsapportéesauxélémentsd'expérienceont étéconsidérées.D'éventuellescorrections sont alors introduites.

Entête

Nom: Traversée d’un carrefourOrigine: Expert1, Référence entretien N.3Auteur: Cogniticien1Date d’émission: Janvier 1996Domaine: PsychologieContexte: Analyse de stratégies adoptées par un conducteur pour traverser un carrefour


Figure 19. Exemple d'un élément d'expérience dans le domaine de l'analysed'accident.

Les élémentsd'expériencepeuventêtre égalementextraitsdesdocu-mentstechniques,desstandards,desprocédures,descodesdecalcul,etc.Parexemple,chaqueparagraphedansundocumentpeutêtreconsidéréparunélé-ment d'expériencede la mêmefaçon qu'unepartie d'un entretien.Les élé-mentsd'expérienceainsiconstituéssontensuiteorganisésdefaçonà êtrefa-cilement réutilisables.Cetteorganisationest spécifiqueà chaquedomained’activité.

Mémoire d’expérience

Dansle butdeconsidérerla diversitédevocabulaireet lespointsdevueutilisésdansuneentreprise,unmodèledescriptifetunréseauterminologiquesont également définis pour constituer une mémoire d'expérience.

Le modèle descriptif

Le modèledescriptifpermetdereprésenterlesdifférentspointsdevueidentifiésdansuneentreprise.Généralement,unedouzainedepointsdevuesembleraisonnable,audelàdedouze,le réseaudéfini parcespointsdevueserainexploitable.Parexemple,nouspouvonsdistinguerpointdevuegéogra-phique, topologique, etc. dans une activité de conception.

Corps

Observation: Le choix de la stratégie (traverser en une seule fois, versus, traverser enplusieurs fois) dépend d’un certain nombre d’attentes liées au volume du trafic. Si le tra-fic estfaible,il y adetrèsgrandeschancesquele conducteurn’ai pasbesoindes’arrêterau milieu. Donc, quelqu’un qui arrive et voit que le trafic est faible, pense n’avoir pasbesoin de s’arrêter au milieu et choisit la stratégie de traverser sans arrêt. Et comme ils’attend à pouvoir traverser sans arrêt, on peut faire l’hypothèse qu’il est préparé à cequ’il n’y ait personne.Hypothèse: trafic faible implique une stratégie de traversée sans arrêt au milieu.Trafic dense implique une stratégie de traversée avec arrêt au milieu.Commentaires: Les attentes du conducteur sont différentes selon la stratégie choisie: -Stratégie de traversée en deux coups: le conducteur simplifie le problème en s’occupantd’abord du flux de gauche, puis du flux de droite.- Stratégie de traversée en un coup: la solution la plus difficile. La plus dure, parce qu’ilfaut évaluer le créneau, simultanément de chaque côté, avec des durées de validitéd’informations qui se conditionnent mutuellement, et qui supposent que l’on va mêmefaire vite pour traverser.


Chaquepoint devueestreprésentéparun réseaud'objets(définissousformedeconcepts),reliésentreeux,suivantunréseausémantique.Unensem-ble decatégoriesdeliensestaussidéfini comme:«ensemble/élément»,«gé-néral/spécifique», «proximité», «Self évolution».

Lemodèledescriptifpeutnepasêtredéfinid'unemanièreexhaustive.Ilsera enrichi au fur et à mesure.

Figure 20. Modèle d'une mémoire d'expérience.

Cemodèleestconstituédequatreparties: réseauterminologiqueou lexique,modèle descriptif, éléments d'expérience et documents.

Le réseau terminologique

Un réseauterminologiquenomméaussilexiqueestconstruitpourper-mettredesrequêtesprochesde la languenaturelle.Ce réseauestconstituéd'objetsqui peuventêtredesmotsou desphrasesnominales,appartenantauvocabulairedu domaineconsidéré.Le réseaueststructuréavecdesrelationssyntaxiques de type "sorte-de" et "concerne".


Un élémentd'expérienceestconsidérécommeélémentairedansla mé-moire. Il estrattachéà un ensembled'objetsdéfinisdanslespointsdevues.Cetteopérationpeutêtreautomatique.Elle estbaséesurunereconnaissancelexicaledestermesidentifiésdansle textedel'élémentd'expérience.Mais lechoixfinal dulien àétablirestlaisséaucogniticien.Cetyped'associationper-met une vue descriptive du domaine.

La représentationtextuelled'unélémentd'expériencepeutêtreindexéeautomatiquementenreliantlestermesidentifiésdansle texteauréseautermi-nologiquedéfini. La Figure20.montreunmodèled'unemémoired'expérien-ce.

Un outil informatiqueestassociéà la méthodeREX. Il permetd'unepartdemémoriserlesélémentsd'expérienceet fournit d'autrepart,uneinter-faced'accèsà ceséléments.L'interfacedu systèmeestconçuedemanièreàpermettredesrequêtesenlangagenaturel.La requêteainsiformuléeseraana-lyséeparle système,qui enréponse,proposeà l'utilisateurunensembled'ob-jetscandidatscorrespondantauxtermesidentifiésdansle réseauterminologi-que.La descriptiond'unobjetchoisi,correspondantà sadescriptiondanslemodèledescriptif,ainsi que les élémentsd'expériencequi y sont rattachés,sont alors présentés.

10 La méthode MKSM

MKSM (Methodologyfor KnowledgeSystemManagement)[11] et[12] estuneméthodequi aétédéveloppéeauCEA avecunobjectifdegestiondesconnaissances.La méthodesebaseprincipalementsurun trianglesémio-tique(Figure 21)oùtroisdimensionssontprisesencompte:la syntaxe,la sé-mantiqueet la pragmatique.L'analysedesconnaissancesdansuneorganisa-tion suivantces trois dimensionsconsisteà considérerl'information (syn-taxe),la signification(sémantique)et le contexte(pragmatique).L'analysedecesdimensionsestguidéeparl'étudedutraitementdesdonnées,destâchesetde l'activité du domaine (Figure21).


Figure 21. Le triangle sémiotique.

Unemodélisationdu systèmedesconnaissancesdoit êtreaussiconsidérée.Cettemo-délisationmetenévidencelesflotsdeconnaissancesetd'informations,lesacteurs(ouagents)producteursetconsommateursdela connaissance.Chaqueagentestdéfini parsonrôledansl'entreprise,lesinformationsconsommées,lesinformationsproduites,lesconnaissancescon-somméeset lesconnaissancesproduites.Cettemodélisation(Figure 22) peutêtrereprésen-téesousformed'undiagrammeSADT danslequelle systèmeopérantreprésentedesinfor-mationssurlesagents,le systèmededécisiondéfinit l'environnementet la capacitéd'organi-sationetdestructurationet le systèmed'informationrassemblelesdocumentset lesbasesdedonnées de l'entreprise.


Figure 22. Modélisation du système de connaissances.

Le patrimoinedeconnaissancescomportedeuxélémentsprincipaux: lelivre deconnaissancesetlesystèmeopérationneldegestiondeconnaissances.Cedernierpeutêtredéfini sousformedesystèmesdesupervision,d'aideà ladécision,d'informationet dedocumentation,deformation,deveille techno-logiqueou stratégiqueet degestionde la qualité.Le livre deconnaissancesrassembledesmodèlesde connaissancesen complémentdesdocumentsdel'entreprisecommelesfiches,lesplans,lesdocumentstechniques,lesimages,lesréférences,etc.La méthodeMKSM préconisedestechniquespourrepré-senterdesmodèlesdeconnaissancessuivantle trianglesémiotiquedéfini ci-dessus (Figure21). Nous décrivons dans ce qui suit cette modélisation.

Système décisionnel

Système d’information

Système opératoire

Flotcognitif

Stock deconnaissances

compétencesFlot de

Flot d’entrées Flot de sorties


Les modèles de connaissances

Modélisation du contexte

Deuxmodèlessontdéfinispour représenterle contexte:un modèledudomaine et un modèle de l'activité.

•Le modèledu domaine:Deuxtypesdeconnaissancessontmis enévi-dencedansle modèledu domaine:1- le typedu flot desconnaissances(matériel,énergie,information,etc.)et2- lessourceset ciblesdescon-naissances(Figure 23).Danscemodèle,unesourceestdéfinieparuneaction(peutêtredécomposéeen plusieursactions),qui créele flux etparun ensembled'événementsqui activentle processus.De même,lacible est décrite par une action qui représente l'effet du flux.

Figure 23. Modèle du domaine

•Le modèledel'activité: Il représentele flot dedonnéesdanslesactivi-tés.Il estdéfini sousuneformeproched'unactigrammeSADT (Figure24).Ceflux décrit lesentrées,sorties,ressourceset acteursd'uneacti-vité.Uneactivitépeutêtredécomposéeenplusieursactivités,représen-tées par plusieurs diagrammes.


Figure 24. Modèle de l'activité.

Modélisation de la signification

La significationestmodéliséeavecdeuxtypesdemodèles: unmodèlede concepts et un modèle de tâches.

•Le modèledeconcepts:Un conceptreprésenteunecatégoried'objetsqui partagentlesmêmespropriétésqui sontdéfiniescommeattributsduconcept.Un conceptpeutavoir desinstances.Une hiérarchiede con-ceptspeutêtredéfinie en utilisant la relationde "spécialisation".Uneautre relation "Valeur" permet de définir les valeurs d'un concept.D'autrestypesderelationssontaussidéfinisentrelesconceptscommeles liens de cardinalité.Le réseaude conceptset relationsestproched'unréseausémantiqueoùunesémantiquepeutêtreattribuéeàun lien.(Figure 25)


Figure 25. Modèle de concepts.

•LemodèledeTâches:Il s'agitd'une"représentationdelastratégiemiseenoeuvrepourrésoudrelesproblèmes".On y distinguedeuxaspects:1- la résolutiondeproblèmes,qui doit êtremodéliséeenseposantlesquestionssuivantes"Quel type de tâchedoit-on résoudre?" et "Com-mentrésout-ongénéralementcetypedetâche?", 2- la manipulationdela connaissancestatiquequi doit êtredéfinie en évoquantla questionsuivante:"commentutilisercetteconnaissancestatiquepourrésoudreleoulesproblèmesposés?".Un modèledetâchesestreprésentésousfor-me d'unehiérarchiede tâches.Le type d'unetâchedonnéeexprimelecontrôleexercésurlessous-tâchesqui la décomposent.Différentstypesdecontrôlepeuventêtreexpriméscomme:exécutionséquentielle,alter-native,enparallèleet répétitive.L'arbrededécompositiondetâchesensous tâches est appelé "flot de contrôle" (Figure26).


Figure 26. Modèle de tâches

Un outil supportdela méthodepermetdereprésenterlesdiagrammesetréaliserdesrecherchessurlesconnaissances.La méthodeMKSM aétéappli-quéeauseindu CEA dansdifférentstypesd'applicationallantdela biologiejusqu'auxtechnologiesnucléaires.Elle a étéégalementutiliséedansdesap-plications dans le domaine de l'électricité et de la gestion bancaire.

11 La méthode CYGMA

CYGMA (CYcledevie etGestiondesMétiersetdesApplications)[13]aétédéfinieparla sociétéKADE-TECH.Cetteméthodeaétéappliquéedansles industriesmanufacturièreset spécialementdansl'activité de conception(bureau d'études, de méthodes et d'industrialisation).

CYGMA prévoit6 catégoriesdeconnaissancesindustrielles: Connais-sancessingulières,terminologiques,structurelles,comportementales,straté-giqueset opératoires.La méthodepermet,ensebasantsurcescatégories,dedéfinir desréférentielsmétiersappelés"Bréviairedeconnaissancesdefilièremétier"etdeBasesdeConnaissances,exploitablespardesalgorithmesderai-sonnementdéductif.CesBasesdeconnaissancessontappeléesAMI (Appli-


cationsMétier IndustriellesouAssistantsMétierdel'Ingénieur).Plusieursty-pesdeBasesdeconnaissancesréférentielsdemétiersontétédéfinis.Citons:

- NETTFORM: AMI forgeron pour Rolls-Royce

- ATOU-TOUR: AMI tourneur pour Eurocopter

- HERACLES: AMI automaticien pour FIAT Group

- ACCORD: AMI tôlier pour Aérospatiale

La méthodeCYGMA préconisedesentretiensavecles expertset uneétudedela documentationdel’entrepriseafin dedéfinir un"bréviairedecon-naissances".Cebréviaireseraensuitevalidéaveclesexperts.Lesconnaissan-cesdanscebréviairesontstructuréesenquatredocuments: le glossairemé-tier, le livret sémantique, le cahier de règles et le manuel opératoire.

Le glossaire métier

Le glossaire métier (Figure27) contient:

Figure 27. Extrait d'un glossaire.

- Desconnaissancessingulières;recueilde casparticuliers,apportantdesélémentsdedéfinitiondeslimitesdudomaine.Danschaquecas,l’artefactainsi que son développement sont décrits.

- Desconnaissancesterminologiques,sousforme de listesalphabéti-ques de termes utilisés dans le domaine métier.

Chaqueélémentdu vocabulaireestdécritdansle glossaireparsadéfi-nition, sa traduction, sa source et des références.

Glossaire Métier: Analyse des accidents de la route

Terme: DéfaillanceFrançais: DéfaillanceAnglais: FailureDéfinition: Défaillance du conducteur. Cette défaillance peut être une cause d’un acci-dentSource: Enquêteur psychologueVoir aussi: perte de contrôle, erreur.


Le livret sémantique

Dansle livret sémantiquesontdéfinieslesconnaissancesstructurelles.Ces connaissances sont décrites sous forme de:

- Connaissancesontologiques,uneorganisationhiérarchiqueenclassesd'objetsdesconnaissancesterminologiques.Cesclassessontorganiséesainsi,grâceà desopérateurslogiquescommeET et OU, desvaleursbooléennesVRAI et FAUX et de listes énumérées de classes.

- Connaissancesfactuelles,un ensembled'instances("Basede faits")desclassesd'objets.Une connaissancefactuellepeutêtredéfinie explicite-mentavecunevaleurouimplicitement.Danscederniercas,la valeurseragé-nérée ultérieurement.

- Connaissancesfaits initiaux,unsous-ensembledesconnaissancesfac-tuelles explicites, définissant le problème à résoudre.

- Connaissancesbutsinitiaux,unsous-ensembledesconnaissancesfac-tuelles implicites, décrivant la solution du problème à résoudre.

Le livret sémantiqueestdécritsousformed'unarbremettantenéviden-ce les opérateurs logiques qui existent entre les classes d'objets (Figure28).


Figure 28. Exemple d'un livret sémantique

Le cahier de règles

Le cahierde règlescomportantdesconnaissancescomportementalesqui sont définies par:

- Connaissancesd'intégrité,ensembledecontraintesassociéesàuneouà plusieurspropriétésd'uneclassed'objets.Cetypedecontraintespeutaussimettre en relation plusieurs classes d'objets.

- Connaissancesexistentielles,ensemblederèglesdétectantl'existenced'un objet métier.

- Connaissancessynthétiques,ensemblede connaissances(définiessousformederèglesdeproductionpermettantd'écriredesfaitssynthétiques).


Le cahierderèglesestdéfini d'unefaçontextuelledansundocumentenlanguenaturelle(Figure 29).Chaquerègleestdéfiniesuivantunefichedontl'entêtemetenavant: le projet,la référence,la date(del'avant-dernièremo-dificationetdela dernièremodification),le typedela règleet le titre, etdontle corpspermetdedécrirel'historique(raisondela dernièremodification),lessources(auteurdela règle,document,norme,service),la genèsedela règle,sonobjectif,sadescriptionetdesremarquesainsiqu'unschémapermettantdel'illustrer.

Figure 29. Extrait du cahier de règles.

Le manuel opératoire

Le manuelopératoire,rassemblant:- lesconnaissancesstratégiquesouméta-connaissances,qui permettentl'emploioptimisédesconnaissancesstructurel-lesetcomportementales- et lesconnaissancesopératoires,qui sontreprésen-téessousformed'enchaînementd'activitésdécrivantle processusderésolu-tion.

Le manuel opératoire comporte trois parties:

Projet: Enquête Ref. Visi-Infra-2 Date-1:23/9/95 Date-d: 1/1/96

Type de règle: -- Privé-X- Publique

Version: 1.0

Titr e: Règle concernant une gêne à la visibilité

Historique: L’analyse de certains accidents a relevé qu’une des causes d’accidents peutêtre une gêne à la visibilité.Source: Enquêteur InfrastructureGenèse: La visibilité est un facteur important à prendre en compte dans l’analyse d’unaccident.Objectif: Gêne à la visibilitéDescription: L’état de l’habitacle du véhicule, comme par exemple: encombré, avec desvitres sales, avec des objets suspendus, des rétroviseurs cassés, peut entraîner une gêne àla visibilité. De même, la nature des abords de la route (arbres, arbustes, talus, haie,poteaux, etc.) peut gêner la visibilité du conducteur.


- La carte,décrivantl'enchaînementdesphasesduprocessusderésolu-tion.LesdiagrammesSADT sontutiliséspourreprésentercesphases(Figure 30).

Figure 30. Exemple de la carte extraite du manuel opératoire.

- Le parcoursdécrivantgraphiquementlesmultiplescheminspossiblesd'enchaînements des étapes (Figure31).


Figure 31. Exemple d'un parcours extrait du manuel opératoire.

- Lesétapes(Figure 32),mettantà jour: lesagents(opérateurs,règles,outils d'assistance,etc.), les actionsmisesen oeuvreet les moyensutilisés(succession de choix, référence aux règles, nom d'outils, etc.).

Etape Elémentaire: "Reconstituer la trajectoire"

Figure 32. Exemple d'une étape extraite du manuel opératoire.

Agent Action Moyen

Opérateur Calculer la trajectoire du véhiculependant l’accident

Logiciel de simulation destrajectoires de véhicules

Règle Gêne de circulation causée par letraficenfonctiondutypedela zone(commerciale, industrielle, etc.)

Circulation-001

Règle Visualiser le plan de la route Plan-002


12 L’atelier FX

AtelierFX [13] et[25] estbasésuruneméthodeappeléeM3A, qui s'ins-pire detravauxissusdessciencessocialespourdéfinir unemémoired'entre-prise.Elle sebasesurla technique"observateur-apprenti"pourcapitaliserlesconnaissances relatives à une activité quelconque.

Technique de l'observateur-apprenti

La premièreétapedecettetechniqueconsisteà choisirun observateurapprentiparmile personneldel'entreprise.Il s'agitenfait dechercherunpra-ticien observéet soncollègueobservateur.L'observateurestensuiteforméàdestechniquesd'observationd'entretienset dedescriptiondesconnaissancespréconiséespar la méthodeM3A. La tâchede l'observateurestd'enregistrerla conduitedupraticienduposteàanalyser,jusqu'aupointoù il peutsemon-trer lui-même capable d'accomplir ces activités d'une manière convenable.

L'observateurapprentirédigealorsunenoticed'instruction,décrivantlesconnaissancesqu'il vient d'acquérir.Un troisièmemembredel'entrepriseestalorssollicité pour réaliserlesopérationsdécritesdansle documentafindelesvalider.Cettenoticeseraensuiteverséeàla documentationexistantap-pelée "Base technologique".

Atelier FX a étédéfini afin d'offrir un accèsà la basedocumentairedel'entrepriseet,parlà àla basetechnologiquedéfinie.Le logiciel NOMINO estexploitédanscetatelierpourindexerlesdocuments.Eneffet,NOMINO per-met uneanalysemorpho-syntaxiqued'uncorpusde texte.Il sebasesur desrèglesmorpho-syntaxiquesde la languefrançaise.Cetteanalysedécoupeletexte en phraseset met en évidencedanschaquephrasedescatégoriesdenoms,verbes,adjectifs,adverbeset termescomplexes(groupesnominaux).Un lexiquede termesestainsiproduit.Ce lexiquepeutêtrerangéparordrealphabétiqueou suivantla fréquenced'apparitiondestermesdansle texte.Deslienshypertextessontaussiétablisentrelestermeset lespartiesdedocu-ments à partir desquelles ils ont été extraits.

Le lexiqueainsidéfini fait partied'uncataloguedescriptifappelé"cata-logue raisonné", défini pour offrir un accès à la base technologique.


Le catalogue raisonné

Ce catalogue contient trois dossiers:

- Un inventairededocumentsdel'entreprise.Chaquedocumentestré-pertoriépar sonorigine, sesauteurset leursadresses,un historique(docu-mentsprécédents),lesdonnéeset lesconceptsauxquelsle documentfait ré-férence(Figure 33).Cesderniersélémentssontidentifiésenexploitantle lo-giciel NOMINO.

Inventaire des documents

Figure 33. Extrait d'un inventaire de documents.

- Dossierdonnées.Il s'agitdesdonnéesétabliesparle personneldel'en-trepriseet jugéesutiles.Chaquedonnéeestenregistréeparsonnom(un iden-tificateur),la catégorieà laquelleelle appartient,desextraitsdanslesquelsladonnéea étémentionnée,les référencesverslesdocumentsqui contiennentlesextraitsmentionnésetdesmotsclésqui peuventêtredesconceptsextraitsdu lexique.Desfichessontainsiélaboréespourrépertorierlesdonnéesutili-sées dans une entreprise.

- Lexique,défini commeundictionnaireinternedestermesutilisésdansl'entreprise.Chaquetermeestdécritpar: unedéfinition,uneliste denotionscorrespondanteset uneliste denotionsassociées(Figure 34).Chaquetermeest lié à l'aide d'une référence au document dans lequel il apparaît.

Document Méthode

Origine: Définition d’une méthode d’analyse des accidents de la routeAuteurs: Expert1, Expert2Historique: Article N.304, Rapport N.96-607Données: Analyse d’un accident, Modèle du fonctionnement d’un conducteur

Document Scénarios Génériques

Origine: Analyse des accidentsAuteurs: Expert3, Expert2Historique: rapport N.97-307Données:Scénarios génériques d’accident, Facteurs causaux


Lexique

Figure 34. Extrait du lexique.

13 L’approche Componential Framework

La méthode"ComponentialFramework"[30] aétéproposéedansle ca-dredel'acquisitiondesconnaissancespourdévelopperdessystèmesàbasedeconnaissances.Cetteméthodea étéensuiteadaptéepoursupporterla gestiondesconnaissancesdansuneentreprise.Danscetteméthode,uneactivitépeutêtredéfinie selontrois perspectives:tâche,informationet méthode(Figure35).

Figure 35. Trois perspectives tâche, méthode et information

Terme: Défaillance

Définition: Il s’agit d’une défaillance d’un conducteur. Cette défaillance peut être unecause de l’accidentListe de notions: perte de contrôleListe de notions associées: manoeuvres origine de l’accident, mauvaise perception desindices

Tâche

Méthode Information


La perspective"tâche"décritlesobjectifsàatteindre,la perspective"in-formation" met en avantles informationset les connaissancesconsultéesetconstruitespourréaliserlestâcheset la perspective"méthode"metenéviden-cecommentlesinformationsont étéutiliséespourréaliserlestâches.La dé-finition decestrois perspectivesformeun cycledanslequelchaqueperspec-tive évoque des connaissances à définir dans une autre perspective.

Perspective Information

Différentstypesd'informationsontutilisésdansuneactivité (basededonnées,entrées/sortiesde résolutionde problèmes,etc.).Cesinformationssontorganiséesdans"ComponentialFramework"sousformededeuxsortesdemodèles: le modèledudomaineet le modèledecas.Le modèledudomai-nedécrit les informationset lesconnaissancesémanantdu domainede l'ap-plicationalorsqu'unmodèledecasdéfinit les informationsutiliséesdansuncasprécis.Le modèledecasestdoncunespécialisationdecertainesinforma-tionsdumodèledudomaine,évoquéesdansla résolutiond'unproblèmedon-né.Dansla perspectiveinformation,on développeégalementuneontologiequi décrit le vocabulaire du domaine.

Perspective Tâche

Unetâcheestdéfinieparunbutàatteindre.Cebutestconcrétiséparunétat"cible". Il s'agitd'uneou plusieursinformationsà construireou à modi-fier. Lesinformationsutiliséesetconsultéespendantla réalisationdela tâchesontappelées"sources".Une tâchepeutaussiutiliser ou produiredesinfor-mationsextraitesou destinéesà une"interface"donnée.Elle peutêtreaussidécomposée en sous-tâches.


Figure 36. Diagramme de dépendance

Un "diagrammede dépendance"permetde représenterle flot de don-néesentreles informations"sources",les tâcheset les informations"cibles"(Figure 36).La décompositionensous-tâchesestdécritegraphiquementgrâ-ce à un arbre de tâches appelé "structure de tâches" (Figure37).

Figure 37. Structure de tâches

Chercher trajectoirelors de l’accident

Chercher stratégiede freinage

Chercher distancede freinage


Perspective Méthode

Uneméthodedéfinit commentuneouplusieurstâchespeuventêtreréa-lisées.Uneméthodeestalorsdécriteparunflot decontrôlequi gèreunesériedetâches.Lesmodèleset lesinterfacesE/Sdestâchesjouentdesrôlesparti-culiersdansuneméthode.Cesrôlessontillustréssurlesarcsqui lient lesmo-dèleset lesinterfacesauxtâches.Uneméthodepeutêtrecomposite(decom-positionmethod)si ellegèreplusieurstâches.Elle peutêtreégalementatomi-que (solution method) et gère une seule tâche.

Un "diagrammedecontrôle"permetdedécriregraphiquementun flotdecontrôlesousformed'unautomatefini, auquelestattribuéun étatinitial,un état de succès et un état d'échec.

Le logiciel KRESTa étédéveloppécommesupportdela méthode.Celogiciel permetde représenterles différentesperspectivesainsi queles dia-grammesderelationsentrecesperspectives.Deslienshypertextespermettentunenavigationentrelesdescriptionsgraphiqueset textuellesainsiqueleslo-gicielsassociés.Deslogicielspeuventêtredéveloppéspouruneapplicationparticulière afin de décrire les tâches et les méthodes.

14 La méthodologie CommonKADS

La méthodologieCommonKADS[3] et [29] présenteun certainnom-bre de caractéristiquesintéressantespour la mémoired’entreprise,qui fontqu'elle mérite d'être mentionnéedans ce rapport. Deux projets ESPRIT:KADS-I (démarréen1983)et KADS-II ont aboutià la méthodologieCom-monKADS. Celle-ci a évolué encore récemment pour être industrialisée.

Elle a enparticulierévoluépourprendreencomptelesaspectsgestiondesconnaissancesenplusdel'ingénieriedesconnaissances.Elle reposesurlepostulatquele partagedela connaissancereposesur la communicationet lacréationdeconnaissance.La gestiondesconnaissancesc'estfaireensortequelesgenspartagentla connaissance.Elle reposesur le constatde l'apparitiondestravailleursde la connaissance(KnowledgeWorkers)et de la nécessitéd'avoiruneapprochestructuréedela gestiondesconnaissances.Elle permetdefaire del'analysedesconnaissanceset d'aideraudéveloppementdesystè-mes fortement basés sur les connaissances.

La méthodologieprenden comptel'évolution de l'extractiondescon-naissancesdel'expertversla constructiondemodèlesdesconnaissances.Elle


reposeégalementsurle principeduKnowledgeLevel(ouniveaudesconnais-sances)qui stipulequel'on peutmodéliserdemanièrepertinenteun systèmeenrestantàunniveauconceptuel,ens'exprimantentermed'agents,debut,detâcheet deconnaissances.On sefocalised'abordsur lesaspectsconceptuelsetl'onprogramme(éventuellement)plustard.Laconnaissanceaunestructureque l'on peut analyser à travers des types de connaissances et des rôles.

Entantqueméthodologiededéveloppementdeprojet,CommonKADSproposeun modèlede gestionde projet en spirale,inspiréde la SpiraledeBoehm.

Les six modèles

CommonKADSproposele développementdesix modèlespouranaly-serla connaissance:organisation,tâche,agent,communication,connaissanceet conception.Les quatrepremiersmodèlesprésententun intérêtparticulierpour l'analyse préalable à la capitalisation des connaissances.

- Lemodèledel'organisationdécritl'entreprisedanssonensembleavecles grandes fonctions.

- Le modèledetâchedécritlestâchesréalisantlesfonctionsidentifiéesdans le modèle d'organisation.

- Le modèled'agentdécritlesagents,humainsou informatiques,impli-qués dans la réalisation des tâches.

- Le modèledecommunicationrendcomptedela communicationhom-me-machine.

- Le modèledesconnaissancespermetdemodéliserl'expertisenéces-saireàla réalisationdestâchesparlesagents.Il permetdeclarifier la structuredestâches(Figure 38) à basedeconnaissances.Lesmodèlesdeconnaissan-cesdeCommonKADSsontplutôtdestinésàmodéliserunefutureapplicationet non paspour rendrefidèlementcomptede la connaissancehumaine.Lesfonctionssontdécritesindépendammentdela structuredesdonnées,pourfa-voriserla réutilisabilité.Lesfonctionss'exprimententermederôlesorientéstâche,c'estàdired'uneontologiedesobjetsmanipulésparla tâche,expriméede manièreindépendantedu domained'application.Ainsi, en diagnosticonparleradepanne,desymptôme,d'observable,etc.,sansfaire référenceà undomaine particulier.


- Le modèledeconceptiontraiteplusspécifiquementdela conceptiond'unsystèmeà basedeconnaissancesdestinéà implémenterlesconnaissan-ces modélisées.

Figure 38. Exemple de structure de tâches

La réutilisation

La méthodologieproposeunetypologiestandardde tâchesà basedeconnaissance,ainsi qu'unedécompositionfonctionnellede cestâches.On ytrouvepar exempledesmodèlespour les tâchesde diagnostic,conception,planification,etc.Unebibliothèqueapportantuneaideà la modélisationestainsi fournit. Elle permetde s'inspirerdesmodèlesde la bibliothèquelors-qu'on démarre une nouvelle application, plutôt que de repartir de zéro.

La bibliothèqueseprésentesousformede"tasktemplate",oupatrondetâches,sur le modèledes"designpatterns",lespatrondeconceptionenpro-grammation par objets.

La bibliothèquedistinguelestâchesd'analyseet lestâchesdesynthèse.Elle propose de réutiliser des combinaisons d'éléments de modèles.

Identifier sourcede rupture

Identifier état duconducteur

Identifier gêne devisibilité de circulation

Recueillirdéclarations

Identifierluminosité

Chercherhomogénéité ouhétérogénéité

chercherobstacles

Identification gêne


CommonKADSutilise maintenantlesconventionsgraphiquesd'UMLpour représenter les modèles.

Pourla réutilisabilitédesconnaissancesdudomaine,onpassedela no-tion deschémadedomaineàla notiond'ontologie.PourCommonKADS,uneontologie est un point de vue sur un domaine.

La visionCommonKADSconsisteàexpliciter,àrendrecomptedesdif-férentspointsdevuequi sous-tendentla modélisationdu domainepourper-mettre la réutilisation ultérieure si le contexte est le même (ou compatible).

Lespointsdevuerendentcompteet dépendentdu contextedemodéli-sationet d'utilisationd'unobjet.On nepeutpasénumérerà l'avancetouslespoints de vue sur un objet.

Modèle de gestion en spirale

CommonKADSprôneunmodèleenspirale[2] pourle managementdeprojetà basedeconnaissances.Le modèledegestiondeprojetseconcentresurlesproductionset lesrésultatsplutôtquesurlesactivitéset lesphases.Saprincipaleoriginalitérésidedansla focalisationsurl'évaluationet la préven-tion des risques du projet et sur l'assurance qualité.

Le cycle de management de projet comporte quatre activités:

1. Revue(review):évaluerl'étatcourantdu projet,établir lesobjectifsdu prochain cycle (2 3 4 1)

2. Evaluationdesrisques(risk): identifieretévaluerlesrisques,prévoirles actions pour les éviter

3. Planification(plan):planifier le travail à partir desétapes1 et 2, dé-couperen tâcheset faire un planning,allouerles ressources,et enfin établirdes critères d'acceptation du cycle

4.Supervision(monitor):supervisiondutravailspécifiédanslesphasesprécédentes, préparation de l'évaluation à la prochaine étape 1.

CommonKADSa étéutiliséedansde nombreusesapplications,tellesque: la détectiondefraudedecartedecrédit,la conceptionnavale,l'aideaudiagnosticmédical,lesservicesfinanciers,évaluationetconseildequalité,re-couvrement de pannes dans les réseaux électriques, etc.


15 Discussions

Nousavonsprocédéàunecomparaisondesméthodescitéesdanscedo-cument.Cettecomparaisonestbaséesurdescritèresrelevantdesmodesdecapitalisationpréconisés,desconnaissancesmanipuléesetdesmémoirespro-duitesainsiquedesapplicationsdesméthodes.Nousavonsainsidéfini deuxgrilles que nous décrivons dans ce qui suit.

Comparaison suivant les modes de capitalisation

Nousy distinguonsquatrecritèresprincipaux: modesderecueiletsour-cesdeconnaissances,aspectdecapitalisation,typesdemodèlesdéfiniseten-fin outilsdéveloppés.Nousrelatonscettecomparaisondansle tableauci-con-tre.

Méthodes Modes deRecueil etSources de

connaissances

Aspect deCapitalisation

Types demodèlesproduits

Outils

REX Entretiens avecexperts + Ana-lyse des docu-ments

Dédiée capitali-sation de con-naissances

Lexique, Vues,Elémentsd’expérience

L’outil REX

MKSM Entretiens avecexperts+ Ana-lyse des docu-ments

Adaptée del’Ingénierie desconnaissances

Modèles du con-texte, dudomaine, d’acti-vités, de con-cepts et detâches

L’outil MKSM

CYGMA Entretiens avecexperts+ Ana-lyse des docu-ments


Glossaire, livretsémantique,cahier de règles,manuel opéra-toire

Atelier FX Observation desactivités desexperts+ Extrac-tion semi-auto-matique desdocuments


Lexique, Inven-taire de docu-ments et Fichierde données

Atelier FX


Comparaison suivant les connaissances manipulées et les applications

Nousavonsprivilégié quatrecritèrespourcomparerlesméthodessui-vant les connaissancesqu'ellesmanipulent: les aspectsdesconnaissancesétudiées,lestypologiesdeconnaissancesconstruites,typesdemémoiresdé-finies et modesdereprésentationdesconnaissanceset enfin typesd’applica-tion des méthodes. Le tableau ci-contre présente cette comparaison.

ComponentialFramework

Entretiens avecexperts + Ana-lyse des docu-ments


Modèle de réso-lution de problè-mes, modèle dudomaine,modèle de cas

KREST

CommonKADS Entretiens avecexperts


Modèles d’orga-nisation, detâche, d’agent,d’expertise et decommunication,modèle de réso-lution de problè-mes, modèle dudomaine

KADS-Work-bench, KADS-Tools, Open-KADS,Cokace,...

Méthodes Aspects deconnaissances

étudiées

Typologie deconnaissances

définies

Types demémoires etModes de

représentation

Typesd’application

REX Résolution deproblèmes +Vocabulaire

Objet descriptif,Point de vue,terme

Mémoire indivi-duelle d’expé-riences

Nucléaire, aéro-nautique, électri-que,...

MKSM Activité +Domaine

Triangle sémio-tique: Informa-tion, Contexte,Signification

Mémoire d’acti-vités: Modèlesdeconnaissances

Nucléaire, ges-tion bancaire

Méthodes Modes deRecueil etSources de

connaissances

Aspect deCapitalisation

Types demodèlesproduits

Outils


CYGMA Activité +Domaine

Connaissancessingulières, ter-minologiques,ontologiques,factuelles, faitsinitiaux, debuts,d’intégrité, exis-tentielles, syn-thétiques,stratégiques,structurelles,comportementa-les, opératoires.

MémoireMétiers: référen-tiels Métiers

Automatique,tôlerie, forge,aéronautique

Atelier FX Activité + Voca-bulaire

Terme, Donnée Mémoire docu-mentaire: Cata-logues raisonnés

Electrique

ComponentialFramework

Résolution deproblèmes +Domaine

Tâche,Méthode,Information


Gestion de pro-duction

CommonKADS Résolution deproblèmes +Domaine

Tâche, Infé-rence, Concept,relation, Expres-sion


Méthodes Aspects deconnaissances

étudiées

Typologie deconnaissances

définies

Types demémoires etModes de

représentation

Typesd’application


Chapitre 4 : Guide de constructionde mémoire de projet

Nousnoussommesinspirésdesméthodesanalysées,surtoutcellesdé-diéesà la mémoirede projet pour proposerun guidede constructiond’unemémoiredeprojet.Nousavonsvouluprendreencompteaussibienla défini-tion d’un projet,sagestion,l’artefactproduitquela prisededécisiondansleprojet.Nousproposonsdoncdedécrireceguideendeuxprincipalespartiescorrespondantauxpartiesdécritesdansle modèledemémoiredeprojet[21](Cf. Chapitre1 : Définition dela mémoirede),à savoir: caractéristiquesdeprojet et logique de conception.

16 Capitalisation des caractéristiques de projet

Dansle domainede la conception,il existeplusieurstechnologiesetmodesdereprésentationclassiquesdanslesmétiersconcernés.Notreobjectifestderespectercesreprésentationset denepasenproposeruneentièrementnouvellequi poseraitdesproblèmesdecompréhensionouqui seraitincompa-tible avecles techniquesutilisées.Nousproposonsalorsd’établir desliensverscesreprésentationstout enlesorganisantdefaçonà mettreenavantlestraits caractéristiquesd’un projet. La capitalisationdescaractéristiquesdeprojetpeutdoncseréaliserenétablissantdesliensverslesdocuments,lesba-sesdedonnées,etc,définisdansunprojet.La définitiondecesliens,unefois,spécifiés,et fournisàtraversun logiciel support,peutêtreréaliséeparunres-ponsable de la gestion d’un projet.

16.1 Capitalisation de l’organisation d’un projet

L’organisationd’un projet,à traverslaquellela relationtâches-partici-pantsestmiseenavant,peutêtrereprésentéeselonun arbre(Figure 39) oùdesliensversdesbasesdedonnéesetdesdocumentsspécifiquessontétablis.Pourdéfinir cetarbre,nousnoussommesinspirésdel’approcheEMMA [22]danslaquellelesactions,leur élaboration,leur planificationainsiquela col-laborationdesparticipantspourleur réalisationsontmis enévidence(Figure39).

Desliensserontalorsétablisversla planificationd’uneactionqui peutêtrereprésentéeselonlestechniquesutiliséesparl’équipedegestionduprojet(tableau,graphe,etc.).Demême,pourla descriptiond’unepropositionoùdesliens vers des bases de données et des documents, dessins,... seront définis.


Figure 39. Arbre de support de la capitalisation de l’organisation d’un projet.

La réalisationd’une propositionpeutêtredécriteà traversdesdocu-mentsou pardesmaquettes,etc.Cecipermetd’établir un lien versla partierésultatsde la mémoire,si la propositiona étéadoptéecommeunesolution.Demême,nouspouvonsavoirun lien versla mémoiredelogiquedeconcep-tion, à traversle champ"option ou choix potentiels",quenousdécrivonsul-térieurement.

Lesgrapheset techniquesutilisésdansla gestiondeprojetpermettentdedécrirel’allocation desactionsà desgroupesou sous-groupesde l’entre-priseoud’autresentreprise.Il estalorsintéressantd’établirdeslienspourdé-crire d’unemanièrebasiquela collaborationdansla réalisationd’actions.Eneffet,nouspouvonsobtenirdesinformationssurlesgroupesdesparticipantset leurstâchesou actionsallouées.Il estaussiimportantd’avoir unerelationverslescompétencesdechaqueparticipantquenouspouvonsengénéralob-tenir destechniquesutiliséespar la gestiondu personnelet del’organisationdel’entreprise.Unedescriptionplusapprofondiedela collaborationentrelesparticipantsdansla réalisationd’un projet,estaussinécessaire.La techniqued’"observateur/apprenti",proposéepar la méthodeM3A [25], ainsi qued’autrestechniquesempruntéesà la sociologieet auxsciencesdela commu-nicationpourrontêtreutiles danscettecapitalisation.Nousn’avonspasap-profondi cet aspect dans ce rapport.


16.2 Capitalisation des résultats

Deslienspeuventêtreétablisverslesdocuments,lesmaquettes,lesba-sesdedonnées,lesdessinstechniques,etc.,qui décriventle produit réalisé.Deplus,unereprésentationenpointsdevuepermetdemettreenavantla des-cription de l’artefactselonlesdiversesperspectiveset domainesimpliquéesdansle projet.Nousétudionsunereprésentationenpointsdevued’unartefact[27] et [28]. Lesfigures40 et 41 présententun exempledecetteétude.Cettereprésentationmérited’êtreanalyséed’unemanièreplusapprofondieet con-frontée avec les besoins industriels de l’Aérospatiale.

Figure 40. Exemple de différents points de vue d’un élément.

Figure41.Description d’un point devuepar un point de focalisationsur l’objet et unangle de vue.

Un cogniticienpeutêtrechargédela descriptiondel’artefactenpointsde vue.

17 Capitalisation de la logique de conception

La résolutiondeproblèmesgénèreengénéraldesconnaissancesvolati-lesdansun projetdeconception.En fait, lescompte-rendusdesréunionset

Poutre

Pdv:mécanique

Pdv:forme

Pdv:géométrique

Flèche

Elément-structurel

Parallélipède

Vue Conception: vue matériauTâche: construction composant freinEtape: 4

Participant: Ingénieur1Domaine de compétence, niveau: mécanique, expertObjectif: Description

Point defocalisation

Angle devue


desdiscussionsnerelatentpasréellementla manièredont lesproblèmesontétérésolus,leschoixproposésetlesjustificationsavancées.Nousavonsmon-tré dansle "Chapitre2 : Méthodesdecapitalisationdédiéesmémoiredepro-jet", un certainnombredeméthodesproposéespouraiderà la capitalisationde cette partie de la mémoire.

La confrontationde cesméthodesavecles étudesmenéesau seindel’Aérospatiale,nousa poussésà adaptercertainesd’ellescommeIBIS, QOCet EMMA. Nousproposonsdoncunecapitalisationdela logiquedeconcep-tion endeuxtemps:1- transcriptiondirected’unerésolutiondeproblèmeset2- capitalisation après coup.

17.1 Transcription directe

Il s’agit d’unetranscriptiondirectedela résolutiondeproblèmeset dela prisededécision.Cettetranscriptionpeutêtrefait parun scribe qui, dansl’idéal, estunmembreactif duprojetouencadrele projet.Cettetranscriptionestaidéeparun arbre(Figure 42) inspirédesméthodesIBIS [8] et EMMA[22] (Cf. Chapitre2 : Méthodesdecapitalisationdédiéesmémoiredeprojet).

Danscetarbre,le problèmediscutédansuneréunionou abordéparunconcepteurestdécrit(sujet,typeetélémentsduproblème).Plusieursoptionsetchoixsontassociésàceproblèmeenvuedele résoudre.Cesoptionsrepré-sententdespropositionsdeconceptionou autre.Ellespeuventêtredécritesàtraversun lien établiversdesdocumentsetdesbasesdedonnéesspécifiques,définissantaussibien lesélémentsqui lesdécomposentqueleur réalisation.La justificationdesoptionsestrelatéepardesargumentsd’appui(+) oudené-gation(-). Cesargumentsmettentenavantlesavantageset lesinconvénientsde ces options.


Figure42.Arbr edesupport dela transcription dir ected’une résolutiond’un problème.

Demême,si uneoptionestrejetée,lesargumentsderejetpeuventaussiêtrereprésentés.Si uneoptionestprivilégiéecommesolution,sadescription(qui peutcontenirdespartiesd’autresoptions)seramiseenévidence.Lesef-fetsdecettesolutionsurl’ensembleduprojetsontillustrésparunarbred’ac-tions(Figure 43).Desdescriptionsdeschangementssontmis enavantà tra-vers les arcs illustrant ces effets.

Figure 43. Arbre illustrant les effets d’une décision sur les actions.


Les membresdu projet qui ont participéà la résolutiondu problème,ainsiquelespersonnesconcernéesparcetterésolutionet lesméthodesutili-séessontaussidécrits.Desliens pourrontêtreétablisversdesdescriptionsplusdétailléescommeparexempleverslescompétences,lesrôlesdesparti-cipantsdansle projet,la descriptiondesméthodes,etc.Un ordrechronologi-quedesoptionsestaussiimportantà signaler.Il estreprésentéindirectementsuivant un axe vertical par l’ordre d’apparition des options.

Vu la complexitédecesarbres,noussuggéronsleur exploitation(édi-tion et consultation)à traversun logiciel qui permetun accèsfacile d’unnoeudàunautreetauxfenêtresdedescriptioncorrespondantes.Leslienshy-pertextesdoiventêtreprivilégiésdansce type de logiciel. Nousproposonsaussiunedescriptiontextuelle,encomplémentdeslistesdechoix devaleurs(par exemple, pour les participants, etc...).

17.2 Capitalisation après coup

La transcriptiondirectedela prisededécision,relatele processusderé-solutiondeproblèmes,maisnemetpasenavantlescritèressous-jacentsàcet-te prisede décision[5]. Pourcela,noussuggéronsuneautrereprésentationcomplémentaire(inspiréedela méthodeQOC[19]), qui permetdecaractéri-serlesoptionsparun ensembledecritères(Figure 44).Cettecaractérisationn’étantpasévidentependantunetranscriptiondirecte,nousproposonssades-criptionaprèscoup,c’estàdireunefois la décisionpriseet le problèmeréso-lu. Le scribepeutalorsanalysercetterésolutionet/oudemanderauxpartici-pantsdescritèresqui caractérisentleuroption,ainsiquela décision.Cetteca-ractérisation permet une vue globale et abstraite d’une résolution deproblèmes.Elle esttrèsutile pour la réutilisationdela mémoire,puisquelescritèresdéfinisdanslesarbresfournissentun accèsprivilégié à la logiquedeconception,aumêmeniveauquelestypesdesproblèmestraités.Enfait, àtra-verscettecaractérisation,unconcepteurpeutreconnaîtredessituationssimi-laires à son problème courant et peut apprendre de leur résolution.


Figure 44. Arbre de support à la capitalisation après coup.


ConclusionNousavonsanalysédanscerapportun certainnombredeméthodesde

capitalisationdesconnaissancesafin d’en adapteruneméthodedeconstruc-tion demémoiredeprojet.Notreobjectifprincipalestderespecterd’unepartla descriptiond’un projet de conceptionet d’autrepart l’environnementdetravaildesconcepteurs.La méthodequenousavonsproposéeestdoncorien-téeversuneréutilisationdesconnaissanceset nonpasunesimplecapitalisa-tion du patrimoine.Nousavonsplanifié la méthodede façonà permettredecapitaliserlesdifférentespartiesd’un projet(Figure 45)mêmesi certainsas-pectscommelesrésultatsoule contexted’un projetn’ont pasétéapprofondisdanscerapport.Nousplanifionsde lesanalyseret d’en spécifierunerepré-sentation plus complète.

Figure 45. Représentation des différentes parties d’un projet.

Unevalidationdela méthodesuruneapplicationréelleresteà prévoir.Il estimportantd’étudierl’exploitationdela méthodeauseind’uneéquipedeconception afin de la modifier en conséquences et de l’enrichir.



d’un pr ojet


Outils défi-nis


Méthodede défini-tion demémoirede projet

Arbres:1)Problème/Option/Argument2)Problème/Option/Critère

Points devue

Arbre:Action/Pro-position/Change-ments

A définir Conception


Bibliographie[1] BallayJ.F. - Capitaliseret transmettrelessavoir-fairedel'entreprise,Eds.Eyrolles,1997.

[2] BoehmB. A Spiralmodelof softwaredevelopmentandenhancement.Computer, p. 61-72, 1988.

[3] Breuker J. , VandeVeldeW., CommonKADSLibrary for expertisemodelling, Reusableproblemsolvingcomponents,Frontiers in Artificial IntelligenceandApplications,J.Breukerand W. Van de Velde (EDS), Amsterdam: IOS.Press 1994.

[4] Brice A. - Design Rationale Management (DRAMA), http://www.quantisci.co.uk/drama

[5] BuckinghamShumS. - AnalyzingtheUsability of a DesignRationaleNotation,DesignRationale,Concepts,TechniquesandUse,MoranT.P. etCarroll J.M. (eds).p.185-215,Law-rence Erlbaum Associates, New Jersey, 1996.

[6] BuckinghamShumS.- Negotiatingtheconstructionandreconstructionof organisationalmemories, Journal of Universal Computer Science,3(8):899-928, 1997.

[7] BuckinghamShumS. - RepresentingHard-to-Formalise,Contextualised,Multidiscipli-nary, OrganisationalKnowledge.Proceedingsof AAI SpringSymposiumonArtificial Intel-ligence in Knowledge Management,p.9-16, 1997. http://ksi.cpsc.ucalgary.ca/AIKM97/AIKM97Proc.html

[8] Conklin J.E.et Yakemovic KC.B. - A Process-OrientedApproachto DesignRationale,Human-Computer Interactions, Vol.6, 1991.

[9] ConklinJ.E.et BegemanM.L. - gIBIS: A Hypertext Tool for exploratoryPolicy Discus-sion, ACM Transactions on Office Informations Systems,6:303-331, 1998.

[10] Dieng R., Corby O., Giboin A. et Ribière M. - Methodsand Tools for CorporateKnowledgeManagement.InternationalJournalof Human-ComputerStudies,51:567-598,Academic Press, 1999.

[11] Ermine J.L. - Les systèmes de connaissances, Eds. Hermès 1996.

[12] ErmineJ.L., Chaillot M., BigeonP., CharentonB. et Malavielle D., MKSM a methodfor knowledge management,Knowledge management: Organization, CompetenceandMethodology, Proceedingsof ISMICK'96, Schreimenmakersed.,Rotterdam,1996,p. 288-302.

[13] FouetJ.M. - Connaissanceset savoir-faire en entreprise,intégrationet capitalisation,Eds. Hermès 1997.

[14] J.Herbst,J.Bumiller, TowardsEngineeringProcessManagementSystems,In Proceed-ings of CEE: Building Tomorrow’s Virtual Enterprise, Germany, April 1997.

[15] KarsentyL. - An EmpiricalEvaluationof DesignRationaleDocuments,ProceedingsofCHI, R. Bilger, S. Guest,andM. J. Tauber(Eds),1996,http://www.acm.org/sigchi/chi96/proceedings/papers/Karsenty/lk_txt.htm

[16] Klein M. - CapturingDesignRationalein ConcurrentEngineeringTeams,IEEE,Com-puter Support for Concurrent Engineering, January 1993.


[17] Kühn O. , Abecker A. , CorporateMemoriesfor Knowledge Managementin IndustrialPractice: Prospectsand Challenges. Journalof UniversalComputerScience,3(8), p. 929-954, 1997.

[18] LeeJ.,et Lai K. - What'sin DesignRationale?InternationalJournalof Human-Com-puter Interaction, vol. 6, N. 3&4, 251-280, 1991.

[19] MacLeanA., YoungR.M., Bellotti V.M.E.,MoranT.P., - Questions,Options,andCrite-ria: Elements of Design Space Analysis, Human-Computer Interaction, Vol.6, 1991.

[20] MalvacheP. etPrieurP. - MasteringCorporateExperiencewith theREX Method,Man-agementof Industrial and CorporateMemory, Proceedingsof ISMICK'93, Compiègne1993, p. 33-41.

[21] MattaN., RibièreR., CorbyO. Définitiond’un modèledemémoire deprojet, Rapportde Recherche INRIA N. 3720, Juin 1999.

[22] McCulloughD., Korelsky T. etWhiteM. - InformationManagementfor Release-basedSoftware Evolution Using EMMA, Software Engineeringand Knowledge Engineering,1998.

[23] Penalva J.M. - SAGACE: unereprésentationdesconnaissancespour la supervisiondeprocédés, Systèmes Experts de deuxième génération, EC2 (Ed.), Avignon, 1990.

[24] Penalva J.M. - SAGACE, la modélisationdessystèmesdont la maîtriseestcomplexe,ILCE, EC2 (Ed), Montpellier, 1994.

[25] PoitouJ.P. - Documentationis Knowledge:An AnthropologicalApproachto CorporateKnowledgeManagement.Proceedingsof ISMICK'95,Compiègne,France,1995,p. 91-103.

[26] PomianJ. - Mémoired'entreprise,techniqueset outils dela gestiondu savoir. Ed Sapi-entia, 1996.

[27] RibièreM. etMattaN. - Virtual EntrepriseandCorporateMemory, Proc.of theECAI-98 Workshopon Building, Maintaining and Using OrganizationalMemories,Brighton,August, 1998.

[28] RibièreM. - Représentationet gestionde multiplespointsde vuedansle formalismedes graphesconceptuels, Thèsede doctoraten informatique,université de Nice-SophiaAntipolis, Avril, 1999.

[29] SchreiberG., AkkermansH., AnjewierdenA., deHoogR., ShadboltN., VandeVeldeW. et Wielinga B. - KnowledgeEngineeringandManagement,TheCommonKADSMeth-odology, MIT Press, 1999.

[30] SteelsL. - CorporateKnowledgeManagement,Managementof IndustrialandCorpo-rate Memory, Proceedings of ISMICK'93, Compiègne 1993.

[31] TourtierP.A. - Analysepréliminairedesmétierset de leursinteractions.Rapportinter-médiaire, projet GENIE, INRIA-Dassault-Aviation, 1995.

[32] WallaceK. , MathesonJ. , HoguC., Isgrove D., ThreeYears of Runningan IntegratedDesign Project at Cambridge, Proceedings of ICED, Tampere, August 1997.



Unité de recherche INRIA Lorraine, technopôle de Nancy-Brabois, 615 rue du jardin botanique, BP 101, 54600 VILLERS-LÈS-NANCYUnité de recherche INRIA Rennes, IRISA, Campus universitaire de Beaulieu, 35042 RENNES Cedex

Unité de recherche INRIA Rhône-Alpes, 46 avenue Félix Viallet, 38031 GRENOBLE Cedex 1Unité de recherche INRIA Rocquencourt, domaine de Voluceau, Rocquencourt, BP 105, LE CHESNAY Cedex

Unité de recherche INRIA Sophia-Antipolis, 2004 route des Lucioles, BP 93, 06902 SOPHIA-ANTIPOLIS Cedex

Éditeur

INRIA, Domaine de Voluceau, Rocquencourt, BP 105 LE CHESNAY Cedex (France)

ISSN 0249-6399