Justification de la conception

Une justification de conception est une documentation explicite des raisons qui sous-tendent les décisions prises lors de la conception d'un système ou d'un artefact . Telle qu'elle a été initialement développée par WR Kunz et Horst Rittel , la justification de conception vise à fournir une structure basée sur l'argumentation au processus politique et collaboratif de résolution de problèmes complexes .

Une justification de conception est la liste explicite des décisions prises au cours d'un processus de conception , ainsi que les raisons pour lesquelles ces décisions ont été prises. Son objectif principal est d'aider les concepteurs en leur fournissant un moyen d' enregistrer et de communiquer l'argumentation et le raisonnement qui sous-tendent le processus de conception. Elle doit donc inclure :

• les raisons qui sous-tendent une décision de conception,
• la justification de cela,
• les autres alternatives envisagées,
• les compromis évalués, et
• l'argumentation qui a conduit à la décision.

Plusieurs domaines scientifiques sont impliqués dans l'étude des justifications de conception, tels que l'informatique , les sciences cognitives , l'intelligence artificielle et la gestion des connaissances . Pour soutenir la justification de la conception, divers cadres ont été proposés, tels que QOC, DRCS, IBIS et DRL.

Alors que les formats d'argumentation remontent aux travaux de Stephen Toulmin dans les années 1950 , les références, les revendications, les garanties, les supports et les réfutations, l'origine de la justification de la conception remonte au développement par WR Kunz et Horst Rittel de la notation Issue-Based Information System (IBIS) en 1970. Plusieurs variantes de l'IBIS ont depuis été proposées.

• La première était la hiérarchie procédurale des problèmes (PHI), décrite pour la première fois dans la thèse de doctorat de Ray McCall bien qu'elle n'ait pas été nommée à l'époque.
• IBIS a également été modifié, dans ce cas pour prendre en charge l'ingénierie logicielle, par Potts & Bruns. L'approche Potts & Bruns a ensuite été étendue par le langage de représentation de décision (DRL). qui a lui-même été étendu par RATSpeak.
• Questions Options and Criteria (QOC), également connu sous le nom d'analyse de l'espace de conception est une représentation alternative de la logique basée sur l'argumentation, tout comme Win-Win et le modèle de recommandation de décision et d'intention (DRIM).

Le premier système de gestion rationnelle (RMS) était PROTOCOL, qui prenait en charge PHI, suivi par d'autres systèmes basés sur PHI, MIKROPOLIS et PHIDIAS. Le premier système prenant en charge IBIS était le STIEC de Hans Dehlinger. Rittel a développé un petit système en 1983 (également non publié) et le plus connu gIBIS (IBIS graphique) a été développé en 1987.

Les approches DR réussies ne reposent pas toutes sur une argumentation structurée. Par exemple, l'approche Scenario-Claims Analysis de Carroll et Rosson capture la logique dans des scénarios qui décrivent la manière dont le système est utilisé et la mesure dans laquelle les fonctionnalités du système soutiennent les objectifs de l'utilisateur. L'approche de Carroll et Rosson en matière de logique de conception vise à aider les concepteurs de logiciels et de matériel informatique à identifier les compromis de conception sous-jacents et à tirer des conclusions sur l'impact des interventions de conception potentielles.

Il existe plusieurs façons de caractériser les approches DR. Parmi les caractéristiques distinctives clés figurent la manière dont elles sont capturées, représentées et utilisées.

La capture de la logique est le processus d'acquisition d'informations de logique pour une gestion de la logique.

Méthodes de capture

• Une méthode appelée « Reconstruction » capture les justifications sous une forme brute telle qu'une vidéo, puis les reconstruit sous une forme plus structurée. L'avantage de la méthode de reconstruction est que les justifications peuvent être soigneusement capturées et que le processus de capture ne perturbe pas le concepteur. Mais cette méthode peut entraîner des coûts élevés et des biais de la personne qui produit les justifications
• La méthode « Record-and-replay » vidéoconférence ou de manière asynchrone via un tableau d'affichage ou une discussion par courrier électronique. Si le système dispose d'une représentation informelle et semi-formelle, la méthode sera utile.
• La méthode du « sous-produit méthodologique » permet de capturer les logiques au cours du processus de conception en suivant un schéma. Mais il est difficile de concevoir un tel schéma. L'avantage de cette méthode est son faible coût.
• Avec une base de connaissances riche (KB) créée à l'avance, la méthode « Apprentice » capture les logiques en posant des questions lorsqu'on est confus ou en désaccord avec l'action du concepteur. Cette méthode profite non seulement à l'utilisateur mais aussi au système.
• Dans la méthode de « génération automatique » , les justifications de conception sont générées automatiquement à partir d'un historique d'exécution à faible coût. Elle a la capacité de maintenir des justifications cohérentes et à jour. Mais le coût de la compilation de l'historique d'exécution est élevé en raison de la complexité et de la difficulté de certains problèmes d'apprentissage automatique.
• La méthode « Historian » permet à une personne ou à un programme informatique de surveiller toutes les actions du concepteur, mais sans faire de suggestions. Les justifications sont capturées pendant le processus de conception.

Le choix de la représentation de la logique de conception est très important pour s'assurer que les logiques que nous capturons correspondent à ce que nous souhaitons et que nous pouvons utiliser efficacement. Selon le degré de formalité, les approches utilisées pour représenter la logique de conception peuvent être divisées en trois catégories principales : informelles, semi-formelles ou formelles. Dans la représentation informelle, les logiques peuvent être enregistrées et capturées en utilisant simplement nos méthodes et supports traditionnellement acceptés, tels que les traitements de texte, les enregistrements audio et vidéo ou même les écritures manuscrites. Cependant, ces descriptions rendent difficile l'interprétation automatique ou d'autres supports informatiques. Dans la représentation formelle, la logique doit être collectée sous un format strict afin que la logique puisse être interprétée et comprise par les ordinateurs. Cependant, en raison du format strict de la logique défini par les représentations formelles, le contenu peut difficilement être compris par l'être humain et le processus de capture de la logique de conception nécessitera plus d'efforts pour être terminé, et devient donc plus intrusif.

Les représentations semi-formelles tentent de combiner les avantages des représentations informelles et formelles. D'une part, les informations saisies doivent pouvoir être traitées par ordinateur afin de pouvoir fournir un support informatique plus complet. D'autre part, la procédure et la méthode utilisées pour saisir les informations sur la logique de conception ne doivent pas être trop intrusives. Dans le système avec une représentation semi-formelle, les informations attendues sont suggérées et les utilisateurs peuvent saisir la logique en suivant les instructions pour soit remplir les attributs selon certains modèles, soit simplement saisir des descriptions en langage naturel.

Le modèle Toulmin

Une manière communément acceptée de représenter la logique de conception de manière semi-formelle consiste à structurer la logique de conception sous forme d'argumentation. Le premier modèle basé sur l'argumentation utilisé par de nombreux systèmes de logique de conception est le modèle Toulmin. Le modèle Toulmin définit les règles de l'argumentation de la logique de conception en six étapes :

1. La réclamation est faite ;
2. Des données justificatives sont fournies ;
3. Le mandat fournit la preuve des relations existantes ;
4. Le mandat peut être appuyé par un support ;
5. Des qualificatifs de modèle (certains, plusieurs, la plupart, etc.) sont fournis ;
6. D’éventuelles réfutations sont également envisagées.

L’un des avantages du modèle Toulmin est qu’il utilise des mots et des concepts qui peuvent être facilement compris par la plupart des gens.

Système d'information basé sur les problèmes (IBIS)

Une autre approche importante de l'argumentation de la logique de conception est l'IBIS ( Issue-Based Information System ) de Rittel et Kunz , qui n'est en fait pas un système logiciel mais une notation argumentative. Il a été implémenté sous forme logicielle par gIBIS (IBIS graphique), itIBIS (IBIS basé sur les tests), Compendium et d'autres logiciels. L'IBIS utilise certains éléments de raisonnement (appelés nœuds) tels que les problèmes, les positions, les arguments, les résolutions et plusieurs relations telles que plus général que, successeur logique de, successeur temporel de, remplace et similaire à, pour relier les discussions sur les problèmes.

Hiérarchie procédurale des problèmes (PHI)

La PHI (Procedural Hierarchy of Issues) a étendu l'IBIS aux questions non controversées et a redéfini les relations. La PHI ajoute la relation de sous-question, ce qui signifie que la résolution d'une question dépend de la résolution d'une autre question.

Questions, options et critères (QOC)

Le QOC (Questions, Options et Critères) est utilisé pour l'analyse de l'espace de conception. Similairement à l'IBIS, le QOC identifie les problèmes de conception clés sous forme de questions et les réponses possibles aux questions sous forme d'options. De plus, le QOC utilise des critères pour décrire explicitement les méthodes d'évaluation des options, telles que les exigences à satisfaire ou les propriétés souhaitées. Les options sont liées aux critères de manière positive ou négative et ces liens sont définis comme des évaluations.

Langage de représentation des décisions (DRL)

Le langage DRL (Decision Representation Language) étend le modèle de DR de Potts et Bruns et définit les éléments principaux comme des problèmes de décision, des alternatives, des objectifs, des revendications et des groupes. Lee (1991) a soutenu que le langage DRL est plus expressif que les autres langages. Le langage DRL se concentre davantage sur la représentation de la prise de décision et sa logique plutôt que sur la logique de conception.

RATSpeak

Basé sur DRL, RATSpeak est développé et utilisé comme langage de représentation dans SEURAT (Software Engineering Using RATionale). RATSpeak prend en compte les exigences (fonctionnelles et non fonctionnelles) dans le cadre des arguments pour des alternatives aux problèmes de décision. SEURAT comprend également une ontologie d'arguments qui est une hiérarchie de types d'arguments et inclut les types de revendications utilisées dans le système.

Modèle en spirale WinWin

Le modèle en spirale WinWin, qui est utilisé dans l'approche WinWin, ajoute les activités de négociation WinWin, y compris l'identification des principales parties prenantes des systèmes et l'identification des conditions gagnantes de chaque partie prenante et de chaque négociation, au début de chaque cycle du modèle de développement logiciel en spirale afin de parvenir à un accord mutuellement satisfaisant (gagnant-gagnant) pour toutes les parties prenantes du projet.

Dans le modèle WinWin Spiral, les objectifs de chaque partie prenante sont définis comme des conditions gagnantes. Lorsqu'il existe un conflit entre les conditions gagnantes, il est capturé comme un problème. Ensuite, les parties prenantes inventent des options et explorent des compromis pour résoudre le problème. Lorsque le problème est résolu, un accord qui satisfait les conditions gagnantes des parties prenantes et capture l'option convenue est atteint. La logique de conception derrière les décisions est capturée pendant le processus du modèle WinWin et sera utilisée par les parties prenantes et les concepteurs pour améliorer leur prise de décision ultérieure. Le modèle WinWin Spiral réduit les frais généraux de capture de la logique de conception en fournissant aux parties prenantes un processus bien défini pour négocier. Dans une ontologie de la logique de décision est définie et leur modèle utilise l'ontologie pour résoudre le problème de la prise en charge de la maintenance des décisions dans le cadre de collaboration WinWin.

Modèle de recommandation et d'intention de conception (DRIM)

Le DRIM (Design Recommendation and Intent Model) est utilisé dans SHARED-DRIM. La structure principale du DRIM est une proposition qui comprend les intentions de chaque concepteur, les recommandations qui satisfont les intentions et les justifications des recommandations. Des négociations sont également nécessaires lorsque des conflits existent entre les intentions des différents concepteurs. La recommandation acceptée devient une décision de conception, et la justification des recommandations non acceptées mais proposées est également enregistrée au cours de ce processus, ce qui peut être utile lors de la conception itérative et/ou de la maintenance du système.

La logique de conception peut être utilisée de nombreuses façons différentes. Un ensemble d'utilisations, défini par Burge et Brown (1998), est le suivant :

• Vérification de la conception — La justification de la conception peut être utilisée pour vérifier si les décisions de conception et le produit lui-même reflètent ce que les concepteurs et les utilisateurs voulaient réellement.
• Évaluation de la conception — La justification de la conception est utilisée pour évaluer les différentes alternatives de conception discutées au cours du processus de conception.
• Maintenance de la conception — La justification de la conception permet de déterminer les changements nécessaires pour modifier la conception.
• Réutilisation de la conception — La justification de la conception est utilisée pour déterminer comment la conception existante pourrait être réutilisée pour une nouvelle exigence avec ou sans modifications. S'il est nécessaire de modifier la conception, la DR suggère également ce qui doit être modifié dans la conception.
• Enseignement de la conception — La justification de la conception pourrait être utilisée comme une ressource pour enseigner aux personnes qui ne connaissent pas la conception et le système.
• Communication de conception — La justification de la conception facilite une meilleure communication entre les personnes impliquées dans le processus de conception et aide ainsi à proposer une meilleure conception.
• Aide à la conception — La justification de la conception pourrait être utilisée pour vérifier les décisions de conception prises au cours du processus de conception.
• Documentation de conception — La justification de la conception est utilisée pour documenter l'ensemble du processus de conception qui implique les délibérations en salle de réunion, les alternatives discutées, les raisons derrière les décisions de conception et la présentation du produit.

La DR est utilisée par les communautés de recherche en génie logiciel, conception mécanique, intelligence artificielle, génie civil et recherche sur l'interaction homme-machine. En génie logiciel, elle peut être utilisée pour soutenir les idées des concepteurs lors de l'analyse des besoins, capturer et documenter les réunions de conception et prédire les problèmes possibles dus à une nouvelle approche de conception. Dans l'architecture logicielle et la conception de solutions d'externalisation, elle peut justifier le résultat des décisions architecturales et servir de guide de conception. En génie civil, elle permet de coordonner la variété de travaux que les concepteurs effectuent en même temps dans différents domaines d'un projet de construction. Elle aide également les concepteurs à comprendre et à respecter les idées de chacun et à résoudre tout problème éventuel.

Le DR peut également être utilisé par les chefs de projet pour tenir à jour leur plan de projet et l'état d'avancement du projet. De plus, les membres de l'équipe de projet qui ont manqué une réunion de conception peuvent se référer au DR pour savoir ce qui a été discuté sur un sujet particulier. Les problèmes non résolus capturés dans le DR pourraient être utilisés pour organiser d'autres réunions sur ces sujets.

La logique de conception aide les concepteurs à éviter les mêmes erreurs commises lors de la conception précédente. Cela peut également être utile pour éviter la duplication du travail. Dans certains cas, la DR peut permettre d'économiser du temps et de l'argent lorsqu'un système logiciel est mis à niveau à partir de ses versions précédentes.

Il existe plusieurs livres et articles qui fournissent d'excellentes études sur les approches rationnelles appliquées à l'IHM, à la conception technique et à l'ingénierie logicielle.