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