stringtranslate.com

Обоснование дизайна

Структура проектирования, основанная на принятии решений, которая охватывает области инженерного проектирования , обоснования проекта и анализа решений .

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

Обзор

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

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

История

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

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

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

Ключевые понятия в обосновании дизайна

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

Обоснование

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

Методы захвата

Представление обоснования

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

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

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

Модель Тулмина
Одним из общепринятых способов полуформального представления обоснования проекта является структурирование обоснования дизайна в виде аргументации. [5] Самая ранняя модель, основанная на аргументации, используемая во многих системах обоснования дизайна, — это модель Тулмина. [7] Модель Тулмина определяет правила аргументации обоснования проекта, состоящие из шести шагов: [21]
  1. Претензия подана;
  2. Предоставляются подтверждающие данные;
  3. Ордер предоставляет доказательства существующих отношений;
  4. Варрант может быть подкреплен обеспечением;
  5. Предоставляются квалификаторы модели (некоторые, многие, большинство и т. д.);
  6. Также рассматриваются возможные опровержения.
Одним из преимуществ модели Тулмина является то, что в ней используются слова и понятия, которые легко понять большинству людей.
Тематическая информационная система (IBIS)
Еще одним важным подходом к аргументации обоснования дизайна является IBIS ( проблемно-ориентированная информационная система ) Риттеля и Кунца [1] , которая на самом деле является не программной системой, а аргументативной нотацией. Он был реализован в виде программного обеспечения gIBIS (графический IBIS), itIBIS (тестовый IBIS), Compendium и другим программным обеспечением. [22] [23] IBIS использует некоторые элементы обоснования (обозначенные как узлы), такие как проблемы, позиции, аргументы, резолюции и некоторые отношения, такие как более общее, логический преемник, временный преемник, заменяет и аналогичные, чтобы связать обсуждение проблем.
Процедурная иерархия проблем (PHI)
PHI (Процедурная иерархия проблем) [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, которая используется в подходе WinWin, [28] добавляет переговорные действия WinWin, включая идентификацию ключевых заинтересованных сторон систем, а также определение условий победы для каждой заинтересованной стороны и переговоров, в начале каждого цикла спирали . модель разработки программного обеспечения [29] с целью достижения взаимовыгодного (winwin) соглашения для всех заинтересованных сторон проекта.
В спиральной модели WinWin цели каждой заинтересованной стороны определяются как условия Win. Если возникает конфликт между условиями победы, это фиксируется как Проблема. Затем заинтересованные стороны придумывают варианты и изучают компромиссные варианты решения проблемы. Когда проблема решена, достигается соглашение, которое удовлетворяет условиям победы заинтересованных сторон и фиксирует согласованный вариант. Обоснование дизайна, лежащее в основе решений, фиксируется в процессе создания модели WinWin и будет использоваться заинтересованными сторонами и проектировщиками для улучшения их последующего принятия решений. [28] Модель WinWin Spiral снижает затраты на сбор обоснования проекта, предоставляя заинтересованным сторонам четко определенный процесс переговоров. В [30] определена онтология обоснования решений, и их модель использует эту онтологию для решения проблемы поддержки поддержки решений в среде совместной работы WinWin.
Рекомендации по проектированию и модель намерений (DRIM)
DRIM (Рекомендации по проектированию и модель намерений) используются в SHARED-DRIM. [14] Основная структура DRIM представляет собой предложение, которое состоит из намерений каждого проектировщика, рекомендаций, соответствующих намерениям, и обоснований рекомендаций. Переговоры также необходимы, когда существуют конфликты между намерениями разных дизайнеров. Принятая рекомендация становится проектным решением, а обоснование непринятых, но предложенных рекомендаций также записывается в ходе этого процесса, что может быть полезно во время итеративного проектирования и/или обслуживания системы.

Приложения

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

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

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

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

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

Смотрите также

Рекомендации

  1. ^ abc Кунц, В.; Риттель, Х. (1970), Проблемы как элементы информационных систем . Рабочий документ 131, Центр городского и регионального развития, Калифорнийский университет в Беркли.
  2. ^ abc Ярчик, Алекс П.; Леффлер, Питер; Шипман III, Фрэнк М. (1992), «Обоснование разработки программного обеспечения: обзор», 25-я Гавайская международная конференция по системным наукам , 2, стр. 577-586.
  3. ^ Аб Хорнер, Дж.; Этвуд, Мэн (2006), «Обоснование эффективного дизайна: понимание барьеров», в Дютуа, Ага; МакКолл, Р.; Мистрик И. и др., Обоснование управления в разработке программного обеспечения, Springer Berlin Heidelberg, стр. 73–90.
  4. ^ abcdefghi Ли, Дж. (1997). «Системы обоснования проектирования: понимание проблем». Эксперт IEEE 12 (3): 78–85.
  5. ^ abcd Бердж, JE; Браун, округ Колумбия (2000), «Рассуждения с обоснованием дизайна», Геро, Дж., Искусственный интеллект в дизайне '00 , Нидерланды: Kluwer Academic Publ., стр. 611–629.
  6. ^ Синь, В.; Гуанглэн, X. (2001), «Обоснование проектирования как часть корпоративной технической памяти», Systems, Man and Cybernetics , стр. 1904–1908.
  7. ^ AB Стивен Тулмин (1958). Использование аргумента . Кембридж: Издательство Кембриджского университета.
  8. ^ МакКолл, Р. (1978), О структуре и использовании проблемных систем в дизайне , Докторская диссертация, Калифорнийский университет, Беркли, Университетские микрофильмы
  9. ^ аб Поттс, К.; Бернс, Г. (1988), «Запись причин проектных решений», 10-я Международная конференция по разработке программного обеспечения (ICSE '1988), стр. 418-427.
  10. ^ Ли, Дж. (1991), «Расширение модели Поттса и Брунса для записи обоснования дизайна», Труды 13-й Международной конференции по разработке программного обеспечения (ICSE '13) , IEEE Computer Society Press, Лос-Аламитос, Калифорния, стр. 114 -125
  11. ^ Маклин, А.; Янг, РМ.; Моран, Т. (1989), «Обоснование дизайна: аргумент в пользу артефакта», SIGCHI Bull . 20, стр. 247-252114-125.
  12. ^ Маклин, А.; Янг, РМ.; Беллотти, VME.; Моран, Т. (1996), «Вопросы, варианты и критерии: элементы анализа пространства дизайна», в Моран, Т.; Кэрролл Дж., « Обоснование концепций, методов и использования дизайна», Lawrence Erlbaum Associates , стр. 53–106.
  13. ^ Барри Бём , Росс, Р. (1989). «Управление программными проектами Theory-W: принципы и примеры». Транзакции IEEE по разработке программного обеспечения 18 (7): 902-916.
  14. ^ аб Пена-Мора, Ф.; Шрирам, Д.; Логчер, Р. (1993), «SHARED-DRIMS: SHARED Design Рекомендации-Система управления намерениями», Proceedings Enabling Technologies Infrastructure для совместного предприятия , IEEE Press, Моргантаун, Западная Вирджиния, стр. 213-221
  15. ^ Делингер, Х. (1978), Проект STIEC: Системный анализ создания и распространения научной и технологической информации в Европейском сообществе», Отчет № 26: Отчет о партии - версия STIEC , Гейдельберг / Штутгарт
  16. ^ Конклин, Дж.; ЯкемБегеманович, М. (1988). «ГИБИС: гипертекстовый инструмент для исследовательского обсуждения политики». Транзакции ACM в офисных информационных системах 6 (4): 303-331.
  17. ^ Кэрролл, Дж. М.; Россон, М. (1992). «Обход цикла задача-артефакт: как предъявлять претензии и проектировать по сценарию». АКМ Транс. Инф. Сист . 10 (2): 181-212
  18. ^ Кэрролл, Дж. М., и Россон, М.Б. (2003). Обоснование дизайна как теория. Модели, теории и структуры HCI: к междисциплинарной науке, 431-461.
  19. ^ abc Бердж, Дж.; Браун, округ Колумбия (1998), Обоснование конструкции: типы и инструменты, Технический отчет, Вустерский политехнический институт, факультет компьютерных наук, получено 27 апреля 2007 г.
  20. ^ Чен, А.; Макгиннис, Б.; Ульман, Д.; Диттерих, Т. (1990), «Представление знаний об истории проектирования и его базовая компьютерная реализация», 2-я Международная конференция по теории и методологии проектирования, Чикаго, Иллинойс, стр. 175-185.
  21. ^ Рейнольдс, Крис (2000), Что такое модель Тулмина? Архивировано 25 августа 2007 г. в Wayback Machine Paper на сайте concentric.net.
  22. ^ Конклин, Дж.; Якемович, К. (1991). «Процессно-ориентированный подход к обоснованию проектирования». Взаимодействие человека и компьютера 6 (3 и 4): 357–391.
  23. ^ Риттель, Хорст WJ ; Ноубл, Дуглас (январь 1989 г.). Тематические информационные системы для проектирования (PDF) (Технический отчет). Беркли, Калифорния: Институт городского и регионального развития Калифорнийского университета . OCLC  20155825. 492.
  24. ^ МакКолл, Р.Дж. (1991). «PHI: Концептуальная основа для гипермедиа дизайна». Исследования дизайна 12 (1): 30–41.
  25. ^ Маклин, А.; Янг, РМ.; Беллотти, VME.; Моран, Т. (1996), «Вопросы, варианты и критерии: элементы анализа пространства дизайна», в Моран, Т.; Кэрролл Дж., « Обоснование концепций, методов и использования дизайна» , Lawrence Erlbaum Associates, стр. 53–106.
  26. ^ Аб Ли, Дж. (1991), «Расширение модели Поттса и Брунса для записи обоснования дизайна», Труды 13-й Международной конференции по разработке программного обеспечения (ICSE '13), IEEE Computer Society Press, Лос-Аламитос, Калифорния, стр. 114-125
  27. ^ Бердж, Дж. (2005), Разработка программного обеспечения с использованием дизайна RATionale, Вустерский политехнический институт, факультет компьютерных наук
  28. ^ аб Барри Бём ; Китапчи, Х. (2006), «Подход WinWin: использование инструмента согласования требований для сбора и использования обоснований», в Дютуа, АХ; МакКолл, Р.; Мистрик И. и др., Обоснование управления в разработке программного обеспечения , Springer Berlin Heidelberg, стр. 173–190.
  29. ^ Барри Бём (1998). «Спиральная модель разработки и улучшения программного обеспечения». Компьютер 21 (5): 61–72
  30. ^ Бозе, П. (1995). «Модель поддержки решений в системе сотрудничества WinWin». Разработка программного обеспечения, основанная на знаниях (KBSE '95).
  31. ^ аб Дютуа, А.; МакКолл, Б.; Мистрик и др., ред. (2006), Обоснование управления в разработке программного обеспечения , Springer, стр. 1–48.
  32. ^ О. Циммерманн, К. Миксович, Дж. Кюстер, Эталонная архитектура, метамодель и принципы моделирования для управления архитектурными знаниями в службах информационных технологий. Журнал систем и программного обеспечения, Elsevier. Том. 85, выпуск 9, сентябрь 2012 г.
  33. ^ Велтон, Майкл; Баллард, Гленн; Томмелейн, Ирис (2007) Применение систем обоснования проектирования для определения проекта – создание исследовательского проекта. Архивировано 28 сентября 2007 г. на Wayback Machine . Проверено 27 апреля 2007 г.
  34. ^ Моран, Т.; Кэрролл, Дж., ред. (1996), «Концепции, методы и использование обоснования проектирования» , Lawrence Erlbaum Associates,
  35. ^ Дютуа, Обоснование управления в разработке программного обеспечения

дальнейшее чтение

Книги
Специальные выпуски
Мастерские

Внешние ссылки