Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Структура проектирования, основанная на принятии решений, которая охватывает области инженерного проектирования , обоснования проектирования и анализа решений .
Деталь Древа познания по энциклопедии Дидро и Даламбера, автор Кретьен Фредерик Гийом Рот
Отображение информации
Темы и поля
Подходы между узлами
Смотрите также
  • v
  • т
  • е

Дизайн обоснование явная документация причин позади решений , сделанных при проектировании в систему или артефакт . Первоначально разработанная В. Р. Кунцем и Хорстом Риттелем , логическое обоснование дизайна направлено на обеспечение основанной на аргументации структуры политического, совместного процесса решения серьезных проблем . [1]

Обзор [ править ]

Обоснование дизайна - это явный список решений, принятых в процессе проектирования , и причин, по которым эти решения были приняты. [2] Его основная цель - поддержать дизайнеров , предоставив средства для записи и передачи аргументации и доводов, лежащих в основе процесса проектирования. [3] Следовательно, он должен включать: [4]

  • причины дизайнерского решения,
  • оправдание для этого,
  • другие рассматриваемые альтернативы,
  • оцененные компромиссы, и
  • аргументация, которая привела к решению.

Несколько научных областей участвуют в изучении дизайна обоснованиями, таких как компьютерные науки [2] когнитивная наука , [3] искусственный интеллект , [5] и управление знаниями . [6] Для обоснования обоснования проектирования были предложены различные структуры, такие как QOC, DRCS, IBIS и DRL.

История [ править ]

В то время как форматы аргументация можно проследить , чтобы Тулмин «работы с в 1950 - х годах [7] датумы, претензии, гарантирует, подставки и ответные, происхождение дизайну обоснования могут быть прослежены до WR Кунца и Хорст Риттел » s [1] развития из Issue-информационная система обозначений (IBIS) в 1970 г. Несколько вариантов на IBIS с тех пор были предложены.

  • Первой была «Процедурная иерархия вопросов» (PHI), впервые описанная в докторской диссертации Рэя МакКолла [8], хотя в то время она не была названа.
  • IBIS также был модифицирован, в данном случае для поддержки разработки программного обеспечения, компанией Potts & Bruns. [9] Затем подход Поттса и Брунса был расширен языком представления решений (DRL). [10], который сам был расширен RATSpeak. [5]
  • Варианты и критерии вопросов (QOC), также известные как Анализ пространства дизайна [11] [12], являются альтернативным представлением аргументационного обоснования, как и Win-Win [13] и Модель рекомендаций и намерений решений (DRIM). [14]

Первой системой рационального управления (RMS) была PROTOCOL, которая поддерживала PHI, за которой последовали другие системы на основе PHI - MIKROPOLIS и PHIDIAS. Первой системой, обеспечивающей поддержку IBIS, была STIEC Ганса Делингера. [15] Риттель разработал небольшую систему в 1983 году (также не опубликована), а более известная gIBIS (графический IBIS) была разработана в 1987 году. [16]

Не все успешные подходы к DR включают структурированную аргументацию. Например, подход Кэрролла и Россона к анализу требований к сценариям [17] дает логическое обоснование сценариям, которые описывают, как используется система и насколько хорошо ее функции поддерживают цели пользователя. Подход Кэрролла и Россона к обоснованию дизайна призван помочь разработчикам компьютерного программного и аппаратного обеспечения определить основные компромиссы при проектировании и сделать выводы о влиянии потенциальных вмешательств при проектировании. [18]

Ключевые концепции в обосновании дизайна [ править ]

Есть несколько способов охарактеризовать подходы к DR. Некоторые ключевые отличительные особенности заключаются в том, как он фиксируется, как он представлен и как его можно использовать.

Обоснование захвата [ править ]

Сбор обоснования - это процесс получения информации об обосновании для руководства

Методы захвата
  • Метод под названием «Реконструкция» [4] фиксирует обоснования в необработанной форме, такой как видео, а затем реконструирует их в более структурированную форму. [19] Преимущество метода реконструкции заключается в том, что можно тщательно фиксировать обоснование, и процесс записи не нарушит работу дизайнера. Но этот метод может привести к высокой стоимости и предвзятости человека, производящего обоснование.
  • Метод «Запись и воспроизведение» [4] просто фиксирует обоснования по мере их раскрытия. Обоснования синхронно фиксируются во время видеоконференции или асинхронно фиксируются через доску объявлений или обсуждение по электронной почте. Если система имеет неформальное и полуформальное представление, метод будет полезен.
  • Метод «Побочный методологический продукт» [4] улавливает логические обоснования в процессе проектирования в соответствии со схемой. Но разработать такую ​​схему сложно. Достоинством этого метода является его невысокая стоимость.
  • Благодаря заранее созданной обширной базе знаний (БЗ), метод «Ученик» [4] собирает обоснования, задавая вопросы, если они сбивают с толку или не соглашаются с действиями дизайнера. Этот метод приносит пользу не только пользователю, но и системе.
  • В методе «Автоматическая генерация» [4] обоснование проекта автоматически генерируется на основе истории выполнения с небольшими затратами. Он способен поддерживать последовательные и актуальные обоснования. Но стоимость составления истории выполнения высока из-за сложности и сложности некоторых задач машинного обучения.
  • Метод «Историка» [20] позволяет человеку или компьютерной программе следить за всеми действиями дизайнера, но не вносит предложений. Обоснования фиксируются в процессе проектирования. [19]

Обоснование представления [ править ]

Выбор представления обоснования дизайна очень важен, чтобы убедиться, что обоснования, которые мы фиксируем, соответствуют нашим желаниям и могут быть использованы эффективно. По степени формальности подходы, которые используются для представления обоснования дизайна, можно разделить на три основные категории: неформальные, полуформальные или формальные. [4]В неформальном представлении обоснования могут быть записаны и зафиксированы, просто используя наши традиционно принятые методы и средства массовой информации, такие как текстовые процессоры, аудио- и видеозаписи или даже рукописные записи. Однако эти описания затрудняют автоматическую интерпретацию или другую компьютерную поддержку. В формальном представлении обоснование должно быть собрано в строгом формате, чтобы его могли интерпретировать и понять компьютеры. Однако из-за строгого формата обоснования, определяемого формальными представлениями, содержание вряд ли может быть понято человеком, и процесс получения логического обоснования дизайна потребует дополнительных усилий для завершения и, следовательно, становится более навязчивым.

Полуформальные представления пытаются объединить преимущества неформальных и формальных представлений. С одной стороны, собранная информация должна обрабатываться компьютерами, чтобы можно было обеспечить больше компьютерной поддержки. С другой стороны, процедура и метод, используемые для сбора информации об обосновании дизайна, не должны быть слишком навязчивыми. В системе с полуформальным представлением предлагается ожидаемая информация, и пользователи могут уловить обоснование, следуя инструкциям, чтобы заполнить атрибуты в соответствии с некоторыми шаблонами или просто ввести описания на естественном языке. [4]

Модели, основанные на аргументации [ править ]

Модель Тулмина
Одним из общепринятых способов полуформального представления обоснования дизайна является структурирование логического обоснования дизайна в качестве аргументации. [5] Самой ранней моделью, основанной на аргументации, используемой многими системами обоснования дизайна, является модель Тулмина. [7] Модель Тулмина определяет правила аргументации обоснования дизайна, состоящие из шести шагов: [21]
  1. Претензия предъявлена;
  2. Предоставляются подтверждающие данные;
  3. Ордер свидетельствует о существующих отношениях;
  4. Ордер может иметь поддержку;
  5. Предоставляются квалификаторы модели (некоторые, многие, большинство и т. Д.);
  6. Также рассматриваются возможные опровержения.
Одним из преимуществ модели Тулмина является то, что в ней используются слова и концепции, которые могут быть легко понятны большинству людей.
Информационная система, основанная на проблемах (IBIS)
Другой важный подход к аргументации обоснования дизайна - это IBIS Риттеля и Кунца ( Issue-Based Information System ) [1], которая на самом деле является не программной системой, а аргументативной нотацией. Он был реализован в виде программного обеспечения с помощью gIBIS (графический IBIS), itIBIS (тестовый IBIS), Compendium и других программ. [22] [23] IBIS использует некоторые элементы обоснования (обозначенные как узлы), такие как проблемы, позиции, аргументы, решения и несколько отношений, таких как более общий, чем, логический преемник, временный преемник, заменяет и аналогичные, чтобы связать обсуждение вопросов.
Процедурная иерархия вопросов (PHI)
PHI (Procedural Hierarchy of Issues) [24] расширил IBIS на не вызывающие разногласия вопросы и переопределил отношения. В PHI добавлена ​​взаимосвязь подвыпуска, что означает, что решение одной проблемы зависит от решения другой проблемы.
Вопросы, варианты и критерии (QOC)
QOC (вопросы, варианты и критерии) [25] используется для анализа пространства проектирования. Подобно IBIS, QOC определяет ключевые проблемы проектирования как вопросы, а возможные ответы на вопросы как варианты. Кроме того, QOC использует критерии для явного описания методов оценки вариантов, таких как требования, которые должны быть удовлетворены, или желаемые свойства. Варианты связаны с критериями положительно или отрицательно, и эти связи определяются как оценки.
Язык представления решений (DRL)
DRL (язык представления решений) [26] расширяет модель Поттса и Брунса DR [9] и определяет основные элементы как проблемы принятия решений, альтернативы, цели, утверждения и группы. Ли (1991) утверждал, что DRL более выразителен, чем другие языки. [26] DRL больше фокусируется на представлении процесса принятия решений и его обосновании, а не на обосновании дизайна.
RATSpeak
На основе DRL разработан RATSpeak, который используется в качестве языка представления в SEURAT (Разработка программного обеспечения с использованием RATionale). [27] RATSpeak принимает во внимание требования (функциональные и нефункциональные) как часть аргументов в пользу альтернатив решения проблем. SEURAT также включает онтологию аргументов, которая представляет собой иерархию типов аргументов и включает типы утверждений, используемых в системе.
Модель спирали WinWin
Модель WinWin Spiral, которая используется в подходе WinWin [28], добавляет в начало каждого цикла спирали действия по переговорам WinWin, включая определение ключевых заинтересованных сторон систем и определение условий победы каждой заинтересованной стороны и переговоров. модель разработки программного обеспечения [29] для достижения взаимоприемлемого (winwin) соглашения для всех заинтересованных сторон проекта.
В спиральной модели WinWin цели каждой заинтересованной стороны определяются как условия победы. Если возникает конфликт между условиями выигрыша, он фиксируется как Проблема. Затем заинтересованные стороны изобретают Варианты и исследуют компромиссы для решения проблемы. Когда проблема решена, достигается Соглашение, которое удовлетворяет условиям выигрыша заинтересованных сторон и фиксирует согласованный вариант. Обоснование дизайна, стоящее за решениями, фиксируется в процессе модели WinWin и будет использоваться заинтересованными сторонами и дизайнерами для улучшения их последующего принятия решений. [28] Модель WinWin Spiral снижает накладные расходы на сбор обоснования дизайна, предоставляя заинтересованным сторонам четко определенный процесс переговоров. В [30] определяется онтология обоснования решений, и их модель использует онтологию для решения проблемы поддержки принятия решений в рамках совместной работы WinWin.
Рекомендации по проектированию и модель намерений (DRIM)
DRIM (рекомендация по дизайну и модель намерения) используется в SHARED-DRIM. [14] Основная структура DRIM - это предложение, которое состоит из намерений каждого проектировщика, рекомендаций, удовлетворяющих намерениям, и обоснования рекомендаций. Переговоры также необходимы, когда существуют конфликты между намерениями разных дизайнеров. Принятая рекомендация становится проектным решением, и обоснование непринятых, но предлагаемых рекомендаций также записывается в ходе этого процесса, что может быть полезно во время итеративного проектирования и / или обслуживания системы.

Приложения [ править ]

Обоснование дизайна может быть использовано по-разному. Один набор применений, определенных Берджем и Брауном (1998), [19] :

  • Проверка дизайна - обоснование дизайна может использоваться для проверки того, являются ли проектные решения и сам продукт отражением того, чего на самом деле хотели дизайнеры и пользователи.
  • Оценка дизайна - Обоснование дизайна используется для оценки различных вариантов дизайна, обсуждаемых в процессе проектирования.
  • Сопровождение дизайна - Обоснование дизайна помогает определить изменения, необходимые для модификации дизайна.
  • Повторное использование дизайна - обоснование дизайна используется для определения того, как существующий дизайн может быть повторно использован для нового требования с любыми изменениями или без них. Если есть необходимость изменить дизайн, то DR также предлагает то, что необходимо изменить в дизайне.
  • Обучение дизайну - обоснование дизайна можно использовать в качестве ресурса для обучения людей, незнакомых с дизайном и системой.
  • Коммуникация дизайна - обоснование дизайна способствует лучшему общению между людьми, участвующими в процессе дизайна, и, таким образом, помогает придумать лучший дизайн.
  • Помощь в проектировании - обоснование проектирования может использоваться для проверки проектных решений, принятых в процессе проектирования.
  • Проектная документация - Обоснование дизайна используется для документирования всего процесса проектирования, который включает обсуждения в конференц-зале, обсуждаемые альтернативы, причины проектных решений и обзор продукта.

DR используется исследовательскими сообществами в области разработки программного обеспечения, машиностроения, искусственного интеллекта, гражданского строительства и исследований взаимодействия человека с компьютером. В разработке программного обеспечения его можно использовать для поддержки идей дизайнеров во время анализа требований, регистрации и документирования совещаний по проектированию и прогнозирования возможных проблем из-за нового подхода к проектированию. [31] В архитектуре программного обеспечения и разработке решений для аутсорсинга он может служить подтверждением результатов архитектурных решений и служить руководством по проектированию. [32]В гражданском строительстве это помогает координировать различные работы, которые проектировщики выполняют одновременно в разных областях строительного проекта. Это также помогает дизайнерам понимать и уважать идеи друг друга и решать любые возможные проблемы. [33]

DR также может использоваться менеджерами проектов для поддержания своего плана проекта и статуса проекта в актуальном состоянии. Кроме того, члены проектной группы, пропустившие совещание по проектированию, могут снова обратиться к DR, чтобы узнать, что обсуждалось по конкретной теме. Неразрешенные вопросы, зафиксированные в DR, могут быть использованы для организации дальнейших встреч по этим темам. [31]

Обоснование дизайна помогает дизайнерам избежать ошибок, допущенных в предыдущем дизайне. Это также может помочь избежать дублирования работы. [5] В некоторых случаях DR может сэкономить время и деньги при обновлении системы программного обеспечения с ее предыдущих версий. [2]

Есть несколько книг и статей, в которых дается отличный обзор подходов к обоснованию, применяемых к HCI, [34] инженерному проектированию [4] и разработке программного обеспечения. [35]

См. Также [ править ]

  • Обозначение структурирования цели
  • IDEF6
  • Методология
  • Методы структурирования проблемы
  • Теория оправдания

Ссылки [ править ]

  1. ^ a b c Kunz, W .; Риттель, Х. (1970), Проблемы как элементы информационных систем . Рабочий документ 131, Центр городского и регионального развития, Калифорнийский университет в Беркли
  2. ^ a b c Ярчик, Алекс П .; Леффлер, Питер; Шипман III, Франк М. (1992), «Обоснование дизайна для разработки программного обеспечения: обзор», 25-я Гавайская международная конференция по системным наукам , 2, стр. 577-586
  3. ^ а б Хорнер, Дж .; Этвуд, Мэн (2006), «Эффективное обоснование дизайна: понимание препятствий», в Дютуа, АХ; McCall, R .; Мистрик И. и др., Rationale Management in Software Engineering, Springer Berlin Heidelberg, стр. 73-90.
  4. ^ Б с д е е г ч я Lee, J. (1997). «Системы обоснования дизайна: понимание проблем». Эксперт IEEE 12 (3): 78–85
  5. ^ а б в г Бердж, Дж. Э .; Браун, округ Колумбия (2000), «Рассуждения с обоснованием дизайна», в Геро, Дж., Искусственный интеллект в дизайне '00 , Нидерланды: Kluwer Academic Publ., Стр. 611–629
  6. ^ Xin, W .; Гуангленг, X. (2001), «Обоснование дизайна как часть корпоративной технической памяти», « Системы, человек и кибернетика» , стр. 1904–1908.
  7. ^ a b Стивен Тулмин (1958). Использование аргумента . Кембридж: Издательство Кембриджского университета.
  8. ^ Макколл Р. (1978), О структуре и использовании систем задач в дизайне , докторская диссертация, Калифорнийский университет, Беркли, университетские микрофильмы
  9. ^ а б Поттс, С .; Бернс, Г. (1988), "Запись причин дизайнерских решений", 10-я Международная конференция по разработке программного обеспечения (ICSE '1988), стр. 418-427
  10. ^ Ли, Дж. (1991), «Расширение модели Поттса и Брунса для записи обоснования дизайна», Труды 13-й Международной конференции по разработке программного обеспечения (ICSE '13) , IEEE Computer Society Press, Лос-Аламитос, Калифорния, стр. 114 -125
  11. ^ Maclean, A .; Янг, RM; Моран Т. (1989), «Обоснование дизайна: аргумент в пользу артефакта», SIGCHI Bull . 20. С. 247-252114-125.
  12. ^ Maclean, A .; Янг, RM; Беллотти, VME .; Моран, Т. (1996), «Вопросы, варианты и критерии: элементы анализа пространства проектирования», в Moran, T .; Кэрролл, Дж., Обоснование концепций, методов и использования дизайна, Lawrence Erlbaum Associates , стр. 53-106.
  13. ^ Барри Бой , Росс, R (1989). «Управление программными проектами Theory-W: принципы и примеры». IEEE Transactions по разработке программного обеспечения 18 (7): 902-916.
  14. ^ а б Пена-Мора, Ф .; Sriram, D .; Логчер, Р. (1993), «ОБЩИЕ ДРАЙМЫ: ОБЩАЯ ИНФОРМАЦИЯ ПО ПРОЕКТИРОВАНИЮ - Система управления намерениями», Proceedings Enabling Technologies Infrastructure for Collaborative Enterprise , IEEE Press, Morgantown, WV, стр. 213-221
  15. ^ Делингер, Х. (1978), Проект STIEC: Системный анализ создания и распространения научной и технологической информации в Европейском сообществе » Отчет № 26: Отчет о партии - Версия STIEC , Гейдельберг / Штутгарт
  16. ^ Conklin, J .; Якем Бегеманович, М. (1988). «Гибис: гипертекстовый инструмент для исследовательского обсуждения политики». Операции ACM по офисным информационным системам 6 (4): 303-331.
  17. ^ Кэрролл, JM; Россон, М. (1992). «Обойти цикл задача-артефакт: как делать заявления и проектировать по сценарию». ACM Trans. Инф. Syst . 10 (2): 181-212
  18. Перейти ↑ Carroll, JM, & Rosson, MB (2003). Обоснование дизайна как теория. Модели, теории и структуры HCI: к междисциплинарной науке, 431-461.
  19. ^ a b c Burge, J .; Браун, округ Колумбия (1998), Design Rationale: Types and Tools, Technical Report , Worchester Polytechnic Institute, Dept. Computer Science , получено 27 апреля 2007 г.
  20. ^ Чен, А .; McGinnis, B .; Ullman, D .; Диттерих, Т. (1990), «Представление знаний об истории дизайна и его базовая компьютерная реализация», 2-я Международная конференция по теории и методологии дизайна, Чикаго, Иллинойс, стр. 175-185.
  21. ^ Рейнольдс, Крис (2000), Что такое модель Тулмина? Архивировано 25 августа 2007 г. на сайте Wayback Machine Paper на сайте concentric.net.
  22. ^ Conklin, J .; Якемович, К. (1991). «Процессно-ориентированный подход к обоснованию дизайна». Взаимодействие человека и компьютера 6 (3 и 4): 357–391.
  23. ^ Риттель, Хорст WJ ; Благородный, Дуглас (январь 1989 г.). Тематические информационные системы для проектирования (PDF) (Технический отчет). Беркли, Калифорния: Институт городского и регионального развития Калифорнийского университета . OCLC  20155825 . 492.
  24. Перейти ↑ McCall, RJ (1991). «PHI: концептуальная основа для дизайна гипермедиа». Исследования дизайна 12 (1): 30–41.
  25. ^ Maclean, A .; Янг, RM; Беллотти, VME .; Моран, Т. (1996), «Вопросы, варианты и критерии: элементы анализа пространства проектирования», в Moran, T .; Кэрролл, Дж., Обоснование концепций, методов и использования дизайна , Lawrence Erlbaum Associates, стр. 53-106.
  26. ^ a b Ли, Дж. (1991), «Расширение модели Поттса и Брунса для записи обоснования дизайна», Труды 13-й Международной конференции по разработке программного обеспечения (ICSE '13), IEEE Computer Society Press, Лос-Аламитос, Калифорния, стр. . 114-125
  27. ^ Бердж, Дж. (2005), Разработка программного обеспечения с использованием дизайна RATionale , Ворчестерский политехнический институт, Департамент компьютерных наук
  28. ^ a b Барри Бём ; Китапчи, Х. (2006), «Подход WinWin: использование инструмента согласования требований для обоснования и использования», в Дютуа, АХ; McCall, R .; Мистрик И. и др., Обоснование управления в разработке программного обеспечения , Springer Berlin Heidelberg, стр. 173-190.
  29. ^ Барри Бем (1998). «Спиральная модель разработки и улучшения программного обеспечения» . Компьютер 21 (5): 61–72
  30. Перейти ↑ Bose, P. (1995). «Модель для принятия решений в рамках совместной работы WinWin». Разработка программного обеспечения на основе знаний (KBSE '95).
  31. ^ a b Dutoit, A .; McCall, B .; Mistrik et al., Eds. (2006), Rationale Management in Software Engineering , Springer, стр. 1-48.
  32. ^ О. Циммерманн, К. Миксович, Дж. Кюстер, Эталонная архитектура, метамодель и принципы моделирования для управления архитектурными знаниями в службах информационных технологий . Журнал систем и программного обеспечения, Elsevier. Vol. 85, Issue 9, сентябрь 2012 г.
  33. ^ Велтон, Майкл; Баллард, Гленн; Томмелейн, Ирис (2007) Применение систем обоснования дизайна для определения проекта - создание исследовательского проекта . Архивировано 28 сентября 2007 г.на Wayback Machine. Проверено 27 апреля 2007 г.
  34. ^ Моран, Т .; Кэрролл, Дж., Ред. (1996), Концепции, методы и использование обоснования дизайна , Lawrence Erlbaum Associates,
  35. ^ Дютуа, Обоснование управления в программной инженерии

Дальнейшее чтение [ править ]

Книги
  • Бердж, Дж. Э .; Кэрролл, JM; McCall R; Мистрик I (2008). Разработка программного обеспечения на основе обоснований . Гейдельберг: Springer-Verlag.
  • Дютуа, AH; McCall R; Mistrík I; Paech B (2006). Обоснование управления в программной инженерии . Гейдельберг: Springer-Verlag.
  • Конклин, Дж (2005). Отображение диалогов . Weinheim: Wiley-VCH Verlag.
  • Киршнер, Пенсильвания; Букингем-Шум SJ; Карр С.С. (2003). Визуализация аргументации: программные инструменты для совместной работы и создания образовательного смысла . Лондон: Springer-Verlag.
  • Моран, Т; Кэрролл Дж. (1996). Обоснование дизайна, концепции, методы и использование . Нью-Джерси: Лоуренс Эрлбаум Ассошиэйтс.
Особые вопросы
  • Искусственный интеллект для инженерного проектирования, анализа и производства (AIEDAM), специальный выпуск: осень 2008 г., том 22 № 4 «Обоснование дизайна» http://web.cs.wpi.edu/~aiedam/SpecialIssues/Burge-Bracewell.html
  • Искусственный интеллект для инженерного проектирования, анализа и производства (AIEDAM), специальный выпуск о представлении и использовании обоснования дизайна, 1997, том 11, № 2, Cambridge University Press
Мастерские
  • Второй семинар по совместному использованию и повторному использованию архитектурных знаний - архитектура, обоснование и замысел дизайна (SHARK / ADI 2007), ( RC.rug.nl ) в рамках 29-й Международной конференции. Конф. по программной инженерии (ICSE 2007) ( CS.ucl.ac.uk )
  • Семинар по обоснованию дизайна: проблемы и прогресс ( Muohio.edu )
  • Председатели семинара: Джанет Бердж и Роб Брейсвелл, проведенный 9 июля 2006 г. в рамках выставки Design, Computing, and Cognition '06. Эйндховен, ( wwwfaculty.arch.usyd.edu.au ) Нидерланды

Внешние ссылки [ править ]

  • Bcisive.austhink.com : коммерческий программный пакет, разработанный для обоснования дизайна и принятия решений в более широком смысле. Графический интерфейс, возможности обмена.
  • Компендиум : инструмент гипермедиа, который предоставляет возможности визуального управления знаниями на основе IBIS. Бесплатное приложение Java, двоичное и исходное, с активным сообществом пользователей, которые встречаются ежегодно.
  • designVUE : инструмент для визуального сбора знаний, основанный на IBIS и других методах. Бесплатное приложение Java.
  • SEURAT : подключаемый модуль Eclipse, который объединяет сбор обоснования и использование со средой разработки программного обеспечения. SEURAT доступен как проект с открытым исходным кодом в github ( [1] ).