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

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

А обоснование дизайна является явной документацией причины позади решения сделано, когда проектирование а система или же артефакт. Первоначально разработанный W.R. Kunz и Хорст Риттель, обоснование дизайна стремится обеспечить аргументация -основанная структура для политического, совместного процесса решения злые проблемы.[1]

Обзор

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

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

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

История

Хотя форматы аргументации можно проследить до Стивен Тулмин работы в 1950-е годы[7] данные, претензии, гарантии, подтверждения и опровержения, происхождение обоснования дизайна можно проследить до W.R. Kunz и Хорст Риттель с[1] развитие Информационная система на основе проблемных вопросов (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 году Риттель разработал небольшую систему (также не опубликованную) и более известную гибис (графический 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 Риттеля и Кунца (Информационная система на основе проблемных вопросов ),[1] что на самом деле не программная система, а аргументированная нотация. Это было реализовано в программной форме компанией гибис (графический IBIS), itIBIS (тестовый IBIS), Компендиум, и другое программное обеспечение.[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 цели каждой заинтересованной стороны определяются как условия победы. Если возникает конфликт между условиями выигрыша, он фиксируется как Проблема. Затем заинтересованные стороны изобретают Варианты и исследуют компромиссы для решения проблемы. Когда проблема решена, достигается Соглашение, которое удовлетворяет условиям выигрыша заинтересованных сторон и фиксирует согласованный вариант. Обоснование дизайна, стоящее за решениями, фиксируется в процессе модели 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]

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

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

  1. ^ а б c Kunz, W .; Риттель, Х. (1970), Проблемы как элементы информационных систем. Рабочий документ 131, Центр городского и регионального развития, Калифорнийский университет в Беркли
  2. ^ а б c Ярчик, Алекс П .; Лёффлер, Питер; Шипман III, Фрэнк М. (1992), «Обоснование разработки программного обеспечения: обзор», 25-я Гавайская международная конференция по системным наукам, 2, с. 577-586
  3. ^ а б Хорнер, Дж .; Этвуд, M.E. (2006), «Эффективное обоснование дизайна: понимание препятствий», в Dutoit, A.H .; McCall, R .; Mistrík, I. et al., Rationale Management in Software Engineering, Springer Berlin Heidelberg, стр. 73-90.
  4. ^ а б c d е ж грамм час я Ли, Дж. (1997). «Системы обоснования дизайна: понимание проблем». Эксперт IEEE 12 (3): 78–85
  5. ^ а б c d Burge, J.E .; Браун, округ Колумбия (2000), «Рассуждение с помощью обоснования дизайна», в Геро, Дж., Искусственный интеллект в дизайне '00, Нидерланды: Kluwer Academic Publ., Стр. 611–629.
  6. ^ Xin, W .; Гуанглэн, X. (2001), «Обоснование дизайна как часть корпоративной технической памяти», Системы, человек и кибернетика, с. 1904 - 1908.
  7. ^ а б Стивен Тулмин (1958). Использование аргументов. Кембридж: Издательство Кембриджского университета.
  8. ^ Макколл Р. (1978), О структуре и использовании систем выдачи в дизайне, Докторская диссертация, Калифорнийский университет, Беркли, университетские микрофильмы
  9. ^ а б Potts, C .; Бернс, Г. (1988), "Запись причин дизайнерских решений", 10-я Международная конференция по программной инженерии (ICSE '1988), стр. 418-427.
  10. ^ Ли, Дж. (1991), «Расширение модели Поттса и Брунса для записи обоснования дизайна», Материалы 13-й Международной конференции по программной инженерии (ICSE '13), Издательство IEEE Computer Society Press, Лос-Аламитос, Калифорния, стр. 114–125.
  11. ^ Maclean, A .; Young, RM .; Моран, Т. (1989), «Обоснование дизайна: аргумент в пользу артефакта», СИГЧИ Бык. 20. С. 247-252114-125.
  12. ^ Maclean, A .; Young, RM .; Беллотти, VME .; Моран, Т. (1996), «Вопросы, варианты и критерии: элементы анализа пространства проектирования», в Moran, T .; Кэрролл, Дж., Обоснование дизайна, концепции, методы и использование, Lawrence Erlbaum Associates, стр. 53-106
  13. ^ Барри Бем, Росс, Р. (1989). «Управление программными проектами Theory-W: принципы и примеры». IEEE Transactions по разработке программного обеспечения 18 (7): 902-916.
  14. ^ а б Пена-Мора, Ф .; Sriram, D .; Логчер, Р. (1993), "ОБЩИЕ ДРИМСЫ: ОБЩИЕ ПРОЕКТНЫЕ РЕКОМЕНДАЦИИ - Система управления намерениями", Труды, обеспечивающие инфраструктуру технологий для совместного предприятия, IEEE Press, Моргантаун, Западная Вирджиния, стр. 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. ^ Кэрролл, Дж. М., и Россон, М. Б. (2003). Обоснование дизайна как теория. Модели, теории и рамки HCI: к мультидисциплинарной науке, 431-461.
  19. ^ а б c Burge, J .; Браун, округ Колумбия (1998), Обоснование дизайна: типы и инструменты, технический отчет, Ворчестерский политехнический институт, факультет компьютерных наук., получено 27 апреля 2007 г.
  20. ^ Chen, A .; McGinnis, B .; Ullman, D .; Диттерих, Т. (1990), «Представление знаний об истории дизайна и его базовая компьютерная реализация», 2-я Международная конференция по теории и методологии дизайна, Чикаго, Иллинойс, стр. 175-185
  21. ^ Рейнольдс, Крис (2000), Что такое модель Тулмина? В архиве 2007-08-25 на Wayback Machine Бумага на сайте hub.com.
  22. ^ Conklin, J .; Якемович, К. (1991). «Процессно-ориентированный подход к обоснованию дизайна». Взаимодействие человека с компьютером 6 (3 & 4): 357–391.
  23. ^ Риттель, Хорст В. Дж.; Благородный, Дуглас (январь 1989 г.). Проблемно-ориентированные информационные системы для проектирования (PDF) (Технический отчет). Беркли, Калифорния: Институт городского и регионального развития, Калифорнийский университет. OCLC  20155825. 492.
  24. ^ Макколл, Р.Дж. (1991). «PHI: концептуальная основа для дизайна гипермедиа». Исследования в области дизайна 12 (1): 30–41.
  25. ^ Maclean, A .; Young, RM .; Беллотти, VME .; Моран, Т. (1996), «Вопросы, варианты и критерии: элементы анализа пространства проектирования», в Moran, T .; Кэрролл, Дж., Обоснование дизайна, концепции, методы и использование, Lawrence Erlbaum Associates, стр. 53-106.
  26. ^ а б Ли, Дж. (1991), «Расширение модели Поттса и Брунса для записи обоснования дизайна», Материалы 13-й Международной конференции по программной инженерии (ICSE '13), IEEE Computer Society Press, Лос-Аламитос, Калифорния, стр. 114-125.
  27. ^ Бердж, Дж. (2005), Программная инженерия с использованием дизайна RATionale, Уорчестерский политехнический институт, факультет компьютерных наук
  28. ^ а б Барри Бем; Китапчи, Х. (2006), «Подход WinWin: использование инструмента согласования требований для обоснования сбора и использования», в Dutoit, A.H .; McCall, R .; Mistrík, I. et al., Обоснование управления в программной инженерии, Springer Berlin Heidelberg, стр. 173-190.
  29. ^ Барри Бем (1998). «Спиральная модель разработки и улучшения программного обеспечения». Компьютер 21 (5): 61–72
  30. ^ Бозе, П. (1995). «Модель для принятия решений в рамках совместной работы WinWin». Разработка программного обеспечения на основе знаний (KBSE '95).
  31. ^ а б Dutoit, A .; McCall, B .; Mistrik et al., Eds. (2006), Обоснование управления в программной инженерии, Springer, стр. 1-48.
  32. ^ О. Циммерманн, К. Миксович, Я. Кюстер, Эталонная архитектура, метамодель и принципы моделирования для управления архитектурными знаниями в службах информационных технологий. Журнал систем и программного обеспечения, Elsevier. Vol. 85, Issue 9, сентябрь 2012 г.
  33. ^ Велтон, Майкл; Баллард, Гленн; Томмелейн, Ирис (2007) Применение систем обоснования проектирования к определению проекта - создание исследовательского проекта. В архиве 2007-09-28 на Wayback Machine Проверено 27 апреля 2007 г.
  34. ^ Moran, T .; Кэрролл, Дж., Ред. (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] ).