Сценарий (вычисления)

В вычислениях сценарий ( Великобритания : / s ɪ ˈ n ɑː rioʊ oʊ / , США : / s ə ˈ n ɛər i oʊ / ; заимствовано из итальянского сценария ( произносится [ʃeˈnaːrjo] ), от латинского scena «сцена» ^[1]) — это описание предсказуемых взаимодействий ролей пользователей (известных в унифицированном языке моделирования как « актеры ») и технической системы, которая обычно включает в себя компьютерное оборудование и программное обеспечение .

У сценария есть цель , которая обычно функциональна. Сценарий описывает один из способов использования или предполагаемого использования системы в контексте деятельности в определенный период времени. Временными рамками сценария может быть (например) одна транзакция; коммерческая операция; день или другой период; или весь срок эксплуатации системы. Аналогично, областью действия сценария может быть (например) одна система или часть оборудования; оснащенная команда или отдел; или целая организация.

Сценарии часто используются как часть процесса разработки системы. Обычно они создаются специалистами по юзабилити или маркетингу , часто работающими совместно с конечными пользователями и разработчиками. Сценарии написаны простым языком с минимальными техническими деталями, чтобы заинтересованные стороны (дизайнеры, специалисты по юзабилити, программисты, инженеры, менеджеры, специалисты по маркетингу и т. д.) могли иметь общую основу для обсуждения.

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

Типы сценариев при разработке системы

При разработке системы используются многие типы сценариев. Александр и Мейден ^[3] перечислить следующие виды:

История : «рассказанное описание причинно связанной последовательности событий или предпринятых действий». ^[3] ^: 8–10 Краткие пользовательские истории написаны в гибком стиле разработки программного обеспечения. ^[4]
Ситуация, Альтернативный мир : «прогнозируемая будущая ситуация или снимок». Это значение распространено при планировании, но менее распространено при разработке программного обеспечения. ^[3] ^: 10
Моделирование : использование моделей для исследования и анимации «Историй» или «Ситуаций», чтобы «дать точные ответы о том, может ли такой сценарий быть реализован с помощью любого правдоподобного дизайна» или «чтобы оценить последствия альтернативных возможных миров или ситуаций». ^[3] ^: 10–11
Раскадровка : рисунок или последовательность рисунков, используемый для описания пользовательского интерфейса или для рассказа истории. Это значение часто используется во взаимодействии человека с компьютером и определяет, что пользователь увидит на экране. ^[3] ^: 12
Последовательность : список интерактивных шагов, выполняемых людьми или машинными агентами, играющими системные роли. Многие формы сценариев, записанные как последовательности шагов, включают операционные сценарии, концепции операций и тестовые сценарии. ^[3] ^: 12–14
Структура : любое более тщательно структурированное представление сценария, включая блок-схемы , UML «диаграммы последовательностей» /ITU, особенно в сценариях использования при разработке программного обеспечения . ^[3] ^: 14–17

Негативные сценарии или случаи неправильного использования могут быть записаны для обозначения вероятных угроз, которым следует противостоять, чтобы гарантировать, что системы имеют достаточную безопасность , безопасность и надежность . Они помогают выявить нефункциональные требования . ^[5]

Использование в разработке системы

Сценарии имеют множество возможных применений при разработке систем. Кэрролл (1995) перечисляет 10 различных «ролей сценариев в жизненном цикле разработки системы»: ^[6]

Анализ требований : сценарии описывают «современное состояние» (часто называемое «как есть»); Действующие сценарии помогают выявить требования, поскольку аналитики «моделируют рабочую ситуацию».
Общение между пользователем и дизайнером : пользователи рассказывают важные для них сценарии или ситуации, которые они хотят испытать или избежать. ^[6]
Обоснование дизайна : обоснование может объяснить дизайн «в отношении конкретных сценариев взаимодействия с пользователем». ^[6]
Представление : сценарии «могут быть средством разработки того, как проектируемая система должна выглядеть и работать». В этой роли сценарии могут представлять собой «графические макеты, такие как раскадровки или моделирование на основе видео», и могут образовывать ранние прототипы проектируемой системы. ^[6]
Проектирование программного обеспечения : «сценарии могут быть проанализированы для выявления необходимых основных объектов проблемной области»; одни и те же сценарии могут быть разработаны для описания состояния, поведения и взаимодействия объектов. ^[6]
Реализация : программное обеспечение может создаваться по одному сценарию за раз, что помогает «сосредоточить внимание разработчиков» и «создавать код, который более полезен в целом». [6]
Документация и обучение : «сценарии взаимодействия, значимые для пользователей», могут устранить разрыв между построенной системой «и задачами, которые пользователи хотят выполнить с ее помощью». ^[6]
Оценка и тестирование : поскольку «систему необходимо оценивать с точки зрения конкретных пользовательских задач, которые она должна поддерживать», сценарии идеально подходят для оценки. ^[6]
Абстракция : общие правила, применимые к различным задачам (или системам), можно определить путем сравнения сценариев. ^[6]
Формирование команды : «набор пробных историй является важным связующим элементом в любой социальной системе». ^[6]

В разных стилях разработки системы

Выбор представления сценария широко варьируется в зависимости от стиля разработки, связанного с промышленным контекстом.

Сценарии в различных контекстах проекта
Контекст проекта	Пример	Стиль сценария	Стиль разработки
Крупный военный проект	Истребительная авиация	Оперативный обзор , Концепция операций	Поэтапный жизненный цикл, подробная документация (см. DoDAF ).
Комбинированный аппаратно-программный продукт	Машина	Вариант использования ^[7]	РУП
Программное обеспечение для бизнеса	Приложение для мобильного телефона	История пользователя ^[4]	Гибкая разработка программного обеспечения

См. также

Ссылки

^ etymonline.com
^ Александр и Беус-Дукич, 2009. Страница 120.
^ Jump up to: ^а ^б ^с ^д ^и ^ж ^г Александр и Мейден, 2004. Глава 1.
^ Jump up to: ^а ^б Кон, 2004.
^ Александр и Мейден, 2004. Глава 7.
^ Jump up to: ^а ^б ^с ^д ^и ^ж ^г ^час ^я ^дж Кэрролл, 1995. Страницы 7–8.
^ Кокберн, 2011.

Библиография

Александр, Ян и Беус-Дукич, Льерка. Выявление требований: как определять продукты и услуги . Уайли, 2009.
Александр, Ян Ф. и Мейден, Нил. Сценарии, истории, варианты использования . Уайли, 2004.
Кэрролл, Джон М. (редактор) Использование: проектирование взаимодействий человека и компьютера на основе сценариев . МИТ Пресс, 2000.
Кэрролл, Джон М. (редактор) Проектирование на основе сценариев: представление о работе и технологиях при разработке систем . Уайли, 1995.
Кокберн, Алистер. Написание эффективных сценариев использования . Аддисон-Уэсли, 2001.
Кон, Майк. Применение пользовательских историй: для гибкой разработки программного обеспечения . Аддисон-Уэсли, 2004 г.
Фаулер, Мартин. UML Дистиллированный . 3-е издание. Аддисон-Уэсли, 2004 г.

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

Заметки о практике проектирования: истории и прототипы как катализаторы коммуникации. Томас Эриксон, в Кэрролле, 1995.

[1] tymonline.com

[2] Александр и Беус-Дукич, 2009. Страница 120.

[AlexMaid-3] Jump up to: ^а ^б ^с ^д ^и ^ж ^г Александр и Мейден, 2004. Глава 1.

[Cohn,_2004-4] Jump up to: ^а ^б Кон, 2004.

[Negative-5] Александр и Мейден, 2004. Глава 7.

[Carroll1995-6] Jump up to: ^а ^б ^с ^д ^и ^ж ^г ^час ^я ^дж Кэрролл, 1995. Страницы 7–8.

[7] Кокберн, 2011.

[1]

[2]

[3]

[4]

[5]

[6]

[7]