Описание предполагаемых взаимодействий между пользователями и технической системой
В вычислительной технике сценарий ( . scenario, UK: /sɪˈnɑːrioʊ/, США: /səˈnɛərioʊ/; заимствовано из итальянского scenario (произносится [ латинского 1 ] ) — это повествование взаимодействиях ролей пользователей известных унифицированном моделирования » технической системы , обычно включает в себя оборудование и программное обеспечение .
У сценария есть цель , которая обычно функциональна. Сценарий описывает один способ, которым система используется или предполагается к использованию в контексте деятельности в определенных временных рамках. Временные рамки для сценария могут быть (например) отдельной транзакцией; бизнес-операцией; днем или другим периодом; или всей эксплуатационной жизнью системы. Аналогично областью действия сценария могут быть (например) отдельная система или часть оборудования; оснащенная команда или отдел; или целая организация.
Сценарии часто используются как часть процесса разработки системы. Обычно они создаются специалистами по юзабилити или маркетингу , часто работающими совместно с конечными пользователями и разработчиками. Сценарии пишутся простым языком, с минимальными техническими подробностями, чтобы заинтересованные стороны (дизайнеры, специалисты по юзабилити, программисты, инженеры, менеджеры, специалисты по маркетингу и т. д.) могли найти общую почву для обсуждения.
Все чаще сценарии используются напрямую для определения желаемого поведения программного обеспечения: замены или дополнения традиционных функциональных требований . Сценарии часто определяются в вариантах использования , которые документируют альтернативные и перекрывающиеся способы достижения цели. [2]
Типы сценариев в разработке систем
При разработке систем используются многие типы сценариев. Александр и Мейден [3] перечисляют следующие типы:
- История : «повествовательное описание причинно-следственной последовательности событий или предпринятых действий». [3] : 8–10 Краткая пользовательская история написана в стиле Agile разработки программного обеспечения. [4]
- Ситуация, Альтернативный Мир : «проецируемая будущая ситуация или снимок». Это значение распространено в планировании, но менее распространено в разработке программного обеспечения. [3] : 10
- Моделирование : использование моделей для исследования и анимации «Историй» или «Ситуаций», чтобы «дать точные ответы о том, может ли такой сценарий быть реализован с помощью любого правдоподобного дизайна» или «оценить последствия альтернативных возможных миров или ситуаций». [3] : 10–11
- Storyboard : рисунок или последовательность рисунков, используемых для описания пользовательского интерфейса или для рассказа истории. Это значение распространено во взаимодействии человека с компьютером, чтобы определить, что пользователь увидит на экране. [3] : 12
- Последовательность : список интерактивных шагов, предпринимаемых людьми или машинами-агентами, играющими системные роли. Многие формы сценария, записанные как последовательности шагов, включают операционные сценарии, концепции операций и тестовые случаи. [3] : 12–14
- Структура : любое более сложно структурированное представление сценария, включая блок-схемы , «диаграммы последовательности» UML /ITU и, особенно, варианты использования в разработке программного обеспечения . [3] : 14–17
Негативные сценарии или случаи неправильного использования могут быть написаны для указания вероятных угроз, которым следует противостоять, чтобы гарантировать, что системы имеют достаточную безопасность , защищенность и надежность . Они помогают обнаружить нефункциональные требования . [5]
Использование в разработке систем
Сценарии имеют многочисленные возможные применения в разработке систем. Кэрролл (1995) перечисляет 10 различных «ролей сценариев в жизненном цикле разработки систем»: [6]
- Анализ требований : сценарии описывают «современное состояние» (часто называемое «как есть»); сценарии действий помогают обнаружить требования, поскольку аналитики «моделируют рабочую ситуацию».
- Коммуникация пользователя и дизайнера : пользователи предлагают важные для них сценарии или ситуации, которые они хотели бы пережить или избежать. [6]
- Обоснование дизайна : обоснование может объяснить дизайн «в отношении конкретных сценариев взаимодействия с пользователем». [6]
- Представление : сценарии «могут быть средством для разработки того, как должна выглядеть и что должна делать проектируемая система». В этой роли сценарии могут быть «графическими макетами, такими как раскадровки или видеомодели», и могут формировать ранние прототипы проектируемой системы. [6]
- Проектирование программного обеспечения : «сценарии могут быть проанализированы для определения необходимых объектов центральной проблемной области»; те же сценарии могут быть разработаны для описания состояния, поведения и взаимодействия объектов. [6]
- Реализация : программное обеспечение может быть создано по одному сценарию за раз, помогая «сохранять сосредоточенность разработчиков» и «создавать код, который более полезен в целом». [6]
- Документация и обучение : «сценарии взаимодействия, имеющие смысл для пользователей» могут сократить разрыв между системой в том виде, в котором она создана, «и задачами, которые пользователи хотят выполнить с ее помощью». [6]
- Оценка и тестирование : поскольку «система должна оцениваться с точки зрения конкретных пользовательских задач, для поддержки которых она предназначена», сценарии являются идеальными для оценки. [6]
- Абстракция : общие правила, которые применяются к различным задачам (или системам), можно определить путем сравнения сценариев. [6]
- Формирование команды : «набор контрольных историй является важным связующим элементом в любой социальной системе». [6]
В разных стилях разработки системы
Выбор представления сценария существенно различается в зависимости от стиля разработки, который связан с промышленным контекстом.
Смотрите также
Ссылки
- ^ etymonline.com
- ^ Александр и Беус-Дукич, 2009. Страница 120.
- ^ abcdefg Александр и Мейден, 2004. Глава 1.
- ^ ab Cohn, 2004.
- ↑ Александр и Мейден, 2004. Глава 7.
- ^ abcdefghij Кэрролл, 1995. Страницы 7-8
- ^ Кокберн, 2011.
Библиография
- Александр, Ян и Беус-Дукич, Льерка. Выявление требований: как специфицировать продукты и услуги . Wiley, 2009.
- Александр, Ян Ф. и Мейден, Нил. Сценарии, истории, варианты использования . Wiley, 2004.
- Кэрролл, Джон М. (ред.) Использование: проектирование человеко-компьютерных взаимодействий на основе сценариев . MIT Press, 2000.
- Кэрролл, Джон М. (ред.) Проектирование на основе сценариев: представление работы и технологий в разработке систем . Wiley, 1995.
- Кокберн, Алистер. Написание эффективных вариантов использования . Эддисон-Уэсли, 2001.
- Кон, Майк. Истории пользователей: применение для гибкой разработки программного обеспечения . Эддисон-Уэсли, 2004.
- Фаулер, Мартин. UML Distilled . 3-е издание. Эддисон-Уэсли, 2004.
Внешние ссылки
- Заметки о практике дизайна: истории и прототипы как катализаторы коммуникации. Томас Эриксон, в Кэрролле, 1995.