Заметки консультанта

Шамрай Александр Владимирович

Posts Tagged ‘сценарий использования’

Use-Case 2.0. Использование Сценария Использования 2.0

Posted by Shamrai Alexander на Сентябрь 5, 2018

Сценарий Использования 2.0 может использоваться во многих различных контекстах для создания многих различных видов систем. В этой главе мы рассмотрим использование сценариев использования для различных видов системы, различных видов требований и различных подходов разработки.

Сценарий Использования 2.0: применим для всех типов систем

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

Сценарий Использования 2.0: не только для приложений интенсивного использования

Фактически сценарий использования полезен как для встраиваемых систем с небольшом или отсутствующим взаимодействием с человеком, так и для систем интенсивного использования. В настоящее время люди используют сценарии использования в разработке всех видов встроенного программного обеспечения в таких разнообразных областях, как разработка двигателей, потребительской электроники, в военной, аэрокосмической и медицинской отраслях. Даже системы управления процессом в режиме реального времени, используемые для химических заводов, могут быть описаны через сценарии использования, где каждый сценарий использования фокусируется на определенной части поведения процесса завода и потребности его автоматизации.

Все, что нужно, чтобы сценарии использования были целесообразными, — система должна взаимодействовать с внешним миром, независимо от того, являются ли пользователи людьми или другими системами. Их применимость гораздо шире, чем большинство людей думает.

Сценарий Использования 2.0: не только для разработки программного обеспечения

Применение сценариев использования не ограничивается разработкой программного обеспечения. Они также могут помочь вам понять ваши бизнес-требования, проанализировать ваш существующий бизнес, разработать новые и более эффективные бизнес-процессы и использовать мощь ИТ для трансформации своего бизнеса. Используя сценарии использования рекурсивно для 1) моделирования бизнеса и его взаимодействия с внешним миром и 2) моделирования систем необходимых для поддержки и улучшения бизнеса, вы можете бесшовно определить, где эти системы будут оказывать влияние на бизнес и какие системы вам необходимы для поддержки бизнеса.

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

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

Сценарий Использования 2.0: обрабатывает все виды требований

Хотя сценарии использования являются одним из самых популярных методов для описания функциональности систем, они также используются для изучения их нефункциональных характеристик. Самый простой способ это сделать – зафиксировать их в рамках самих сценариев использования. Например, связать требования к производительности ко времени между конкретными шагами сценария использования или перечислить уровни ожидаемого обслуживания для сценария использования как часть его самого.

Некоторые нефункциональные характеристики являются более тонкими и применяются для многих, если не для всех, сценариев использования. Это особенно справедливо для многоуровневых архитектур, включая компоненты инфраструктуры, такие как безопасность, управление транзакциями, сервисы сообщений и управление данными. Требования в этих областях по-прежнему могут быть выражены как сценарии использования – отдельный сценарий использования сосредотачивается на техническом использовании системы. Мы называем такие сценарии сценариями использования инфраструктуры, т.к. требования, которые они содержат, будут направлять разработку инфраструктуры, в которой приложение будет работать. Эти сценарии использования и их фрагменты можно рассматривать в качестве сквозных проблем, которые влияют на поведение системы при выполнении более традиционных функциональных сценариев. Например, сценарий использования может быть создан для изучения, как система будет управлять транзакциями базы данных, включая все различные сценарии использования такие, как схемы для блокировки данных, кэширование, фиксация данных и откат. Этот сценарий использования будет применяться каждый раз, когда другой сценарий использования извлекает или хранит данные в системе.

Сочетание таких сценариев использования инфраструктуры с другими методами, например, разделение проблем и аспектно-ориентированного программирования, позволяет решить эти общие требования без необходимости изменения реализации существующих функциональных сценариев использования.

Сценарий использования 2.0: применим для всех подходов разработки

Сценарий Использования 2.0 работает со всеми популярными подходами разработки программного обеспечения, в том числе:

  • Итеративные подходы на основе журналов, такие как Scrum, EssUP и OpenUP
  • На основе потока целых частей, такие как Kanban
  • Подход все-в-одном, такие как традиционный водопад

В следующих 3 коротких разделах мы проиллюстрируем как Сценарий Использования 2.0 и, в частности, слайсы сценария использования могут помочь в каждом из походов. Эти разделы не являются самодостаточными как остальные части документа, поэтому предполагается, что читатель имеет базовое понимание обсуждаемого подхода. Мы рекомендуем вам прочитать только те разделы, с подходами которых вы знакомы.

Сценарий Использования 2.0 и итеративные подходы на основе журналов

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

Рисунок 1. Концепция журнала

При использовании Сценария Использования 2.0 слайс сценария использования является основным элементом журнала. Использование слайсов гарантирует, что элементы журнала правильно сформированы, т.к. они естественно независимы, значимы и проверяемы. Структурирование повествования сценария использования, которое определяет их, обеспечивает уверенность в том, что они могут быть оценены и по ним могут быть достигнуты договоренности, и механизм нарезки сценария использования позволяет нарезать их настолько малыми, насколько вам необходимо для поддержки работы вашей команды разработки.

Сценарий использования не размещается в упорядоченный список если не ясно, что он будет означать. Означает ли это, что это то, где будет появляться первый или последний слайс из сценария использования? Если вы хотите разместить сценарий использования в список перед его нарезкой, просто создайте фиктивный слайс, который представляет весь сценарий, и вставьте его в список.

Когда вы адаптируете подход на основе журнала, важно понимать, что журнал не является окончательно собранным и завершенным в начале работ. Журнал постоянно обрабатывается и обновляется, что часто называется ухаживанием или поддержкой журнала. Типичная последовательность активностей для итеративных подходов на основе журналов показана на рисунке ниже.

Рисунок 2. Активности для итеративных подходов на основе журналов

Перед началом разработки готовится журнал; «Найти субъекты и сценарии использования» используется для создания первоначальной модели сценария использования и определения масштабов системы, «Разделить сценарии использования» используется для создания начального набора наиболее важных слайсов сценариев использования для заполнения журнала, и «Подготовить слайс сценария использования» используется для получения одного или нескольких слайсов, готовых для разработки в первой итерации.

После того, как журнал будет установлен и запущен, вы можете начать первую итерацию разработки. Каждая новая итерация начинается с некоторого планирования. Во время этого планирования может потребоваться использовать «Разделить сценарии использования» для дальнейшей нарезки слайсов выбранного сценария использования, чтобы убедиться, что они достаточно малы для того, чтобы их можно было выполнить в итерации. Затем команда разработчиков использует «Подготовить слайс сценария использования», «Анализировать слайс сценария использования», «Реализация программного обеспечения (по слайсам)», и «Тестирование системы (по слайсам)» для разработки идентифицированных слайсов и их добавления в систему.

Хоть разработка является постоянной, команда также использует «Изучать и адаптировать сценарии использования», «Разделить сценарии использования» и «Подготовить слайс сценария использования» для поддержки журнала, обработки изменений и обеспечения уверенности в том, что есть достаточно элементов журнала, готовых для следующей итерации. Команде может даже понадобиться использовать «Найти субъекты и сценарии использования» для обработки крупных изменений или поиска большего количества сценариев использования для команды. В Scrum команде рекомендуется тратить 5-10 процентов от их времени для поддержки их журнала. Это незначительные дополнительные расходы для команды, и Сценарий Использования 2.0 обеспечивает рабочие продукты и активности, необходимые для простого и эффективного выполнения этой деятельности.

В конце итерации команда должна продемонстрировать систему и отобразить результаты исполнения их итерации. Команда должна использовать «Тестирование системы (по слайсам)», чтобы понять, где они находятся, и «Изучать и адаптировать сценарии использования», чтобы задуматься о качестве и эффективности их слайсов и сценариев использования.

Сценарий использования 2.0 и поток целых частей

Поток целых частей является подходом, который избегает пакетной обработки требований, что наблюдается в итеративном и водопадном подходах. В подходе поток целых частей каждый элемент требования проходит через процесс разработки. Поток целых частей — это метод, который взят из бережливой разработки. На рисунке ниже показана небольшая команда в потоке целых частей, которая передает каждый элемент непосредственно от рабочей станции A к B и C.

Рисунок 3. Концепция потока целых частей

Для этого, чтобы работать эффективно, вы должны иметь небольшие, стандартного размера элементы, которые будут быстро проходить через систему. Для разработки программного обеспечения требования являются сырьем, а рабочее программное обеспечения является готовой продукцией. Сценарий использования будет слишком нестандартным и слишком большим, чтобы пройти через систему. Время на станциях A, B и C будет слишком непредсказуемым и элементы начнут застревать. Слайс сценария использования может быть выполнен в нужном размере и доработан под потребности команды. Рисунок ниже иллюстрирует поток целых частей для разработки программного обеспечения со слайсами сценариев использования.

Рисунок 4. Поток целых частей для разработки программного обеспечения со слайсами сценариев использования

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

Поток целых частей не означает, что люди делают только одну вещь и работа выполняется только на одной рабочей станции. Например, может быть больше людей, работающих в области разработки, чем есть в тестировании, и если элементы начинают застревать, то люди должны сделать все возможное, чтобы заставить элементы двигаться снова. Если нет слайса сценария использования, ожидающего тестирования, но есть слайсы, которые застряли в анализе, тестировщики могут предпринять некоторые инициативы и помочь выполнить подготовительную работу. Таким образом вы не ограничены одним человеком на каждой рабочей станции или даже только одним экземпляром каждой рабочей станции.

Доски Kanban — это технология для визуализации потока через производственную линию. Kanban — это знак, флаг или сигнал в пределах производственного процесса для запуска производства и поставки продукции как часть подходов «точно в срок» и бережливого производства. На Kanban доске Kanban карты используются для представления элементов в системе. Рисунок ниже показывает простую Kanban доску для команды разработки, где сначала каждый слайс анализируется, чтобы понять его воздействие, затем разрабатывается и выполняется модульное тестирование для программного обеспечения и, наконец, полученное программное обеспечение независимо тестируется до передачи его в использование.

Рисунок 5. Слайсы сценариев использования на Kanban доске

Лимиты работы показаны красным цветом. Читая слева направо, вы можете увидеть, что слайсы должны быть идентифицированы и определена область прежде, чем они перейдут команде. Здесь лимит выполняемой работы равен 5, и клиенты, владелец продукта или команда бизнес-требований, которые являются источником требований, пытаются все время держать 5 готовых к реализации слайсов сценариев использования.

Слайсы берутся из входной очереди в область подготовки, где проводится анализ влияния, истории уточняются и финализируются тестовые сценарии. Здесь лимит выполняемой работы равен 3 пунктам. Элементы, которые находятся в столбце «on-going», в текущее время обрабатываются. Элементы в столбце «Done» завершены и ждут их принятия разработчиком. Таким же образом, слайсы проходят через команду разработки и, после успешного прохождения независимого тестирования системы, переходят в эксплуатацию. Лимит выполняемой работы покрывает всю работу на станции, включая текущие и выполненные элементы. Лимит выполняемой работы на выходе или ограничение на количество элементов, которые будут выпущены, не устанавливается.

Важный момент о Kanban – не существует определенной Kanban доски или лимита выполняемой работы; структура доски зависит от вашей командной структуры и методов работы. Доску и лимиты выполняемой работы следует настраивать так, как вы адаптировали ваши практики. Дополнительным вспомогательным инструментом для такого рода работы по дизайну являются состояния для слайсов сценария использования. На рисунке ниже показано выравнивание между состояниями и Kanban доской, показанной на рисунке выше. Состояния являются очень мощными, т.к. они четко определяют в каком состоянии слайс должен быть, когда он будет передан в следующую часть цепи.

Рисунок 6. Выравнивание состояний слайсов сценариев использования к Канбан доске

Рисунок ниже показывает, где применяются различные активности Сценария Использования 2.0. Самое интересное здесь то, что за «Изучать и адаптировать сценарии использования» не несет ответственность какая-либо конкретная рабочая станция, а проводится в рамках регулярного контроля качества, выполняемого командой. Эта деятельность поможет команде настроить количество и типы рабочих станций, а также лимиты выполняемой работы.

Рисунок 7. Активности для подхода потока целых частей

Например, в результате оценки эффективности команды можно устранить рабочую станцию подготовки и увеличить лимиты выполняемой работы для разработки и тестирования системы. Тут снова вы используете состояния слайсов сценария использования, чтобы определить, что означает для каждой рабочей станции завершение их работы на Kanban доске, как показано на рисунке ниже.

Рисунок 8. Kanban доска команды, отражающая завершающие состояния

Сценарий Использования 2.0 и водопад

По различным причинам вы можете обнаружить, что вам необходимо разрабатывать ваше программное обеспечение в ограничениях в виде некоторой формы модели управления водопад. Это обычно означает, что будут предприниматься некоторые попытки предварительно зафиксировать все требования, прежде чем они будут переданы третьей стороной для разработки.

Когда вы адаптируете подход водопад, над сценариями использования постоянно не работают и их не обновляют до появления окончательной системы, т.к. они все за один раз определены на старте работ. Затем в идеальной синхронизации они переходят через другие этапы разработки, которые сосредоточиваются над одним видом деятельности в одно время. Типичная последовательность активностей для подхода водопад показана на рисунке ниже.

Рисунок 9. Активности для подхода водопад

Даже в условиях строжайшего водопада существуют изменения, происходящие в ходе разработки самого программного обеспечения. Вместо того, чтобы принять и поощрять изменения, проекты водопада пытаются контролировать изменения. Они будут время от времени применять «Изучать и адаптировать сценарии использования», когда появляется запрос на изменение, который не может быть отложен, и они будут готовить дополнительные слайсы сценария использования для обработки любых изменений, которые принимаются. Они вряд ли найдут какие-либо дальнейшие сценарии использования после этапа требований, т.к. это будет считаться слишком большим изменением границ.

Характер подхода водопад «одна активность в одно время» означает, что состав команды постоянно меняется с течением времени, и, таким образом, возможность использования личного общения, чтобы поделиться историями, является весьма ограниченной. Чтобы справиться с этим, вам нужно поднять уровень детализации рабочих продуктов, далеко выходя за пределы простых сущностей. Рисунок ниже показывает уровень детализации, который, как правило, используется в проектах водопада.

Рисунок 10. Уровни детализации для рабочих продуктов в подходе водопад

В рамках каждой из фаз разработки один или несколько рабочих продуктов достигают весьма высокого уровня детализации для того, чтобы обеспечить их полноту 1) и 2) ответить на любые вопросы, которые могут возникнуть на более поздних этапах. В фазе требований постоянно обрабатывается модель сценариев использования, чтобы убедиться, что были обнаружены все сценарии использования, все повествования сценариев использования полностью описаны и вспомогательная информация всесторонне определена. На этом этапе закладываются некоторые мысли для тестирования и формулируются тестовые идеи. Тестовые сценарии затем откладываются в сторону, пока не будет достигнут этап тестирования.

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

Последовательный характер этого подхода работы может вас заставить задуматься о том, что нет никакого смысла в слайсе сценария использования, и что просто обработки всего сценария использования будет достаточно. Это не так, т.к. мелкозернистый контроль, реализованный через слайсы сценариев использования, позволяет команде требований быть гораздо более конкретными о фактических границах системы, которая будет разработана. Даже в проектах водопада маловероятно, что вам нужны все истории из всех сценариев использования. Они также помогут вам обрабатывать любые изменения границ, которые вносятся в последнюю минуту и вызваны проблемами графика или качества.

Сценарий Использования 2.0 не только для одного типа команд

Другим важным аспектом Сценария использования 2.0 является его способность адаптироваться к существующим командным структурам и рабочим функциям, одновременно способствуя команде в устранении потерь и повышении эффективности. В этом случае Сценарий Использования 2.0 не предопределяет каких-либо конкретных ролей или структуру команды, но он определяет набор состояний для каждого из центральных элементов (сценарий использования и слайс сценария использования).

Как проиллюстрировано в разделе «Сценария Использования 2.0 и поток целый частей», состояния указывают, когда элементы находятся в состоянии покоя и могут быть переданы от одного человека или группы к другой. Это позволяет использовать практику командами всех форм и размеров, начиная с малых кросс функциональных групп с небольшой или отсутствующей передачей ответственности до больших сетей групп специалистов, где за каждое изменение состояния отвечает отдельный специалист. Отслеживание состояния и передачи элементов позволяет отслеживать поток работы через команду (или команды), а команды могут адаптировать их способы работы для постоянного улучшения их производительности.

Сценарий Использования 2.0: масштабирование под ваши потребности

Никогда предопределенные подходы не подойдут всем сразу, поэтому нам необходимо иметь возможность масштабировать наш Сценарий Использования 2.0 в ряде различных измерений:

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

Независимо от сложности системы, которую вы разрабатываете, вы всегда начинаете с выявления наиболее важных сценариев использования и создания большой картины, отображающей, что должно быть построено. Затем вы можете адаптировать Сценарий Использований 2.0 для удовлетворения возникающих потребностей команды. На самом деле Сценарий Использования 2.0 настаивает на том, чтобы вы постоянно его оценивали и адаптировали для ликвидации потерь, увеличения пропускной способности и соответствия постоянно меняющимся требованиям команды.

Реклама

Posted in Стандарты и методологии, Управление требованиями | Отмечено: , , , | Leave a Comment »

Советы для написания хороших сценариев использования

Posted by Shamrai Alexander на Март 2, 2011

James Heumann, Requirements Evangelist,

IBM Rational Software

Оригинал: Tips for writing good use cases

Перевод Шамрай А.В.

Содержание
Введение
 

Что такое сценарий использования (и что не является им)

Сценарии использования – это программные требования, которые определяют функциональность

Ссылки позволяют пользователям восстановить всю историю

Заключение

Введение

Написание хороших сценариев использования в большей степени искусство, чем наука. И, как в любом искусстве, нет абсолютных правил для создания ваших шедевров. В конечном счете, сценарии использования четко предоставляют подробную информацию для очень широкой аудитории и достижения целей создания успешных проектов разработки.

Ивар Якобсон ввел сценарии использования. Мария Эриксон работала с Якобсоном и была соавтором одной из его книг. Курт Биттнер и Ян Спенс также написали популярную книгу по использованию сценариев использования. Эти пионеры и многие другие люди в IBM, которые имеют многолетний опыт работы с заказчиками в разработке хороших сценариев использования, внесли свой вклад в технологии, описанные в этой статье. Дать хороший сценарий использования не легко, но, к счастью, наш опыт может быть Вашим руководством. Концепций и принципы, собранные здесь, представляют опыт многих людей в IBM, и они образуют основу проверенных передовых методов. Многие советы, приведенные в данном документе, являются частью методологии IBM Rational® Unified Process® (RUP®), другие являются новыми и не представлены в RUP.

Что такое сценарий использования (и что не является им)

Сценарии использования стали очень популярными для изложения бизнес логики проектов разработки. Эта популярность, к сожалению, также может привести к путанице и разным мнениям о том, что они такое и как они должны быть структурированы и написаны. Без стандартного стиля и набора руководств для написания сценариев использования, авторы сценариев использования в Вашей организации будут писать сценарии использования по своему пониманию, возможно, введут в заблуждение их потребителей и поставят под угрозу проекты, а также желаемый качественный результат решения, которое обеспечивает немедленную значимость для бизнеса.

Сценарий использования – это история о том, как бизнес или система и пользователи взаимодействуют. Варианты использования являются частью стандарта Object Management Group (OMG) Unified Modeling Language (UML). Этот стандарт говорит нам, что части сценария использования выражается диаграммами – рисованные фигуры, овалы и линии – и это дает нам определение сценария использования. Но это не говорит нам, как структурировать или писать. Поэтому нам остается читать книги или статьи (подобной этой), чтобы попытаться выяснить правильные методы.Итак, какой правильный путь? Лучший способ – это способ, который работает на Вас, не отходя слишком далеко от определения, что такое вариант использования: 

Вариант использования – это спецификации набора действий, выполняемых системой, который дает заметный результат, который, как правило, значим для одного или нескольких субъектов или других заинтересованных сторон системы (UML 2).

Менее формальное определение может быть таким: сценарий использования – это список шагов, который определяет, как пользователь взаимодействует с бизнесом или системой, имея в виду значение, которое это взаимодействие обеспечивает пользователю или другим заинтересованным сторонам. Еще проще: сценарий использования – это история о том, как бизнес или система и пользователи взаимодействуют.

Сценарии использования – это формальные требования, которые четко определяют результирующее значение. Сценарий использования не следует путать с пользовательской историей, требованием к программной системе, сформулированном в виде одного или двух предложений на повседневном языке пользователя. Сценарии использования – это формальные требования с контекстом и структурой, которые четко определяют результирующее значение.Это доставляет авторам сценариев использования много хлопот – выяснить лучший способ для написания сценария использования, учитывая значительную двусмысленность, находящуюся в определении. Цель этой статьи состоит в том, чтобы помочь Вам сделать правильные решения для того, чтобы Вы могли успешно выполнять эту задачу. 

Другой тип сценария использования – бизнес сценарий использования, который используется для разработки моделей, которые описывают, как бизнес будет взаимодействовать со своими заказчиками и другими внешними сторонами и представляет значимость для этих субъектов. Эта статья не затрагивает бизнес сценарии использования и фокусируется исключительно на сценариях использования системы.

Сценарии использования преобразуют выражения «должен» на группы, которые обеспечивают наблюдаемое значение и контекст, организованные с точки зрения пользователя.

Сценарии использования – это программные требования, которые определяют функциональность

Люди часто говорят о требованиях и сценариях использования, подразумевая, что это разные вещи. Прецеденты просто другой способ для организации функциональных требований; они по-прежнему требованиям. Традиционно требования описывают функциональность системы, используя длинный список с выражением «должен», иногда их тысячи. Целью создания сценариев использования является преобразование этих многих выражений на более мелкие группы, которые обеспечивают наблюдаемое значение и контекст, организованные с точки зрения пользователя.

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

Сценарии использования описывают и функциональность и результаты. Сценарий использования описывает функциональные возможности, но он также должен описывать результат. Это важно, и это отражается в первом определении, которое говорит, что прецеденты обеспечивают «значимый результат для одного или нескольких субъектов или других заинтересованных сторон системы». Одна из общих проблем, наблюдаемых в организациях, которые только начали использовать сценарии использования, является то, что они не понимают этот фокус на значимости. И в результате они делают много небольших сценариев использования, которые не дотягивают до полной истории. Они не нацелены на взаимодействие, определяющие значимость и интересы для субъектов, участвующих в сценарии использования.
Распространенной ошибкой является путать требования со спецификациями проектирования. Этот подход часто можно увидеть в его воздействии на этапе тестирования проекта. Если тесты, основанные на сценариях использования, отражают юнит-тесты, а не приемочные испытания пользователя, их может быть, возможно, слишком много и они на слишком низком уровне.Как, например, один клиент IBM взаимодействовал с около 10 людьми, работающими над проектом, который должен был длиться около года. Первоначально в организации было около 150 сценариев использования, потому что было непонимания их цели. После глубокой экспертизы, было установлено, что многие из их вариантов использования были действительно спецификациями проектирования, а не требованиями, и другие были слишком сосредоточены на настолько незначительных взаимодействиях, что они не показывали никакой значимости для субъекта или заинтересованных сторон. 

Была предпринята попытка сделать шаг назад и сосредоточиться на пересмотре их сценариев использования. После удаления неуместных сценариев и комбинирования других, клиент получил менее чем 10 сценариев использования, каждый из которых сосредоточен на дополняющих и всеобъемлющих частях общей концепции и показывает важную значимость для каждого субъекта или заинтересованных сторон. Для этого клиента это был момент удивления, когда разработчики компании увидели, как эти новые, большие, более полные сценарии использования были и проще для понимания и более удобны для использования в проектировании, разработке и тестировании своей системы.

Диаграммы обеспечивают визуальный вспомогательный материал для сценария использования.

Совет: Не забывайте о диаграммах

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

Люди являются наиболее важным элементом сценария использования

Совет: Люди-субъекты являются наиболее важным элементом

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

Если система, которую Вы разрабатываете, не имеет сильную зависимость от других систем или устройств, Ваше время и усилия, гораздо лучше потратить на удовлетворения потребностей людей-субъектов.

Создание стиля для сценария использования позволяет писать и читать их быстрее и проще.

Совет: Идите за потоком

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

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

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

Рисунок 1. Хорошо написанный сценарий использования, который рассказывает, как студент регистрируется на курсы.

Альтернативные потоки объясняют отклонение от основного потока. Альтернативные потоки (см. рисунок 2) объясняют, что происходит, когда по каким-то причинам происходит отклонение от основного потока. Эти отклонения могут или не могут быть помечены как исключения или ошибки. В любом случае, они не встречаются так часто, или не так важны, как основной поток. В документе сценария использования каждый тип потока описывается в своем собственном разделе. Иногда альтернативные потоки разбиты на более подробные категории такие, как пользовательские ошибки и исключения. Отметим, что низкоуровневые коды ошибок выходят за рамки альтернативных потоков. 

Рисунок 2. Альтернативные потоки описывают возможные результаты, когда они начинаются и когда они заканчиваются.

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

Ссылки позволяют пользователям восстановить всю историю

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

Совет: Помещайте ссылки в альтернативных потоках, а не основных потоках

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

Рекомендуется не использовать ссылки в основном потоке, который будет переносить пользователя в альтернативный поток или в другой сценарий использования, если происходят специфические условия. Сосредоточение внимания на верном пути оставляет поток простым и легким для чтения, и он четко говорит, что происходит при успешном сценарии использования. Некоторые стили сценариев использования используют ссылки в основном потоке, который часто показывают как операторы «если, то» и ответвляются во многие другие места в сценарии использования или за его пределы. Но эти методы могут привести к путанице, и рекомендуется, чтобы все ссылки выполнялись в альтернативных потоках.

Ссылки указывают на то, что является причиной для начала альтернативного потока и что система делает в ответ. Альтернативные потоки содержат ссылки (Альтернативные потоки объясняют, что происходит при возникновении ошибки или когда происходят ожидаемые результаты, но они не столь важны как основной поток). Это то, где проявляется важность ссылок. Каждый альтернативный поток начнется где-то в сценарии использования. Он может отходить от одного из шагов в основном потоке или расширяться от другого альтернативного потока. И когда альтернативный поток заканчивается, сценарий использования, как правило, продолжается в другом месте.Альтернативный поток объясняет, что явилось причиной для старта и что система делает в ответ на альтернативный поток. Альтернативные потоки не только содержат ссылки на то, где они начинаются и где они возобновятся, они также говорят, что заставило их начаться и что система делает в ответ. Смотря ниже в процесс разработки, эта информация будет полезна для написания тестов. 

Совет: Сценарии описывают полную историю

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

Удобочитаемость может пострадать, если присутствует оператор «если» в потоке, потому что это обычно означает множественные требования.

Совет: Будьте осторожны с операторами «если»

ИТ-специалисты, в частности, с опытом программирования знакомы с оператором «если», и Вы будете часто видеть использование таких операторов в сценариях использования. «Если» в языке программирования указывает условное поведение, и это правило справедливо в сценариях использовании. Проблемы возникают, когда есть один или больше операторов «если» в потоке, потому что это обычно означает, что вы устанавливаете несколько требований. Это может быть отрицательным для удобства чтения, т.к. может быть сложно отследить поток после нескольких операторов «если» в тексте. Это также отрицательно для проектирования и тестирования системы. Лучше и для читателя, и для проекта, если Вы прервете каждый «если» в его собственный поток. Это сделает больше потоков, но такой компромисс стоит того.

Выбор единственного варианта для субъекта и создание альтернативных потоков для другого варианта может упростить главный поток.

Совет: Укажите выбор для субъекта

Субъекты часто делают выбор в сценарии использовании. Рассмотрим пример системы регистрации университета определенного в сценарии использования «Регистрация на курсы». В этом примере шаг главного потока может спросить субъекта: 1) создать график, 2) изменить график и 3) удалить график. Часто авторы сценария использования пытаются использовать оператор «если», чтобы показать, субъект делает выбор, но по причинам, указанным выше, это может быть не лучшая идея. Лучшей альтернативой для того, чтобы все возможности выборы субъекта были перечислены в соответствующем месте и был один выбранный вариант, направляющий в текущий поток, а другие рассматривались в альтернативных потоках. Этот метод сохраняет каждый поток простым и снижает ветвления.

Совет: Убирайте СЧОУ

Часто мы замечаем, что авторы дают субъектам выбирать путем создания отдельных сценариев использования для каждого варианта. Это заманчивое решение, но и опасное. Опасность заключается в необходимости управлять экспоненциальной сложностью, которую часто создается в результате излишне повторяющихся моделей поведения и, в конечном счете, сценариев использования с минимальной значимостью.

Вместо этого, попробуйте сосредоточиться на вещах, которые субъект действительно хочет сделать, что, как правило, не в действиях создание, чтение, обновление и удаление (СЧОУ).

В нашем примере системы регистрации университета, есть варианты для 1) создания графика, 2) изменения графика и 3) удаления графика. Все они находятся в сценарии использования «Регистрация на курсы», поскольку студент не заботится о создании и изменении графиков; студент хочет только зарегистрироваться. Выбор легкого пути и составление списка всех деятельностей СЧОУ в результате даст в три или в четыре раза больше сценариев использования, чем необходимо и может быстро сделать процесс сложным и трудно управляемым.

Для примера модели сценария использования с большим количеством СЧОУ, рассмотрим в приведенном ниже рисунке из проекта по обновлению баз данных администрирования для программ жилья местного управления. Если взять все деятельности типа СЧОУ, каковы реальные выгоды для бизнеса, производимые от всех усилий для определения этой конкретной модели?

Плохо написанный сценарий использования имеет слишком много действий создания, чтения, обновления и удаления, уменьшая ясность. Рисунок 3. У плохо описанного варианта использования есть слишком много включенных действий типа СЧОУ.
Удаление деятельностей СЧОУ упрощает документ. Рисунок 4. Хорошо написанный сценарий использования четко указывает на пути и значимость.
Упорядочивание событий в потоке не всегда необходимо для достижения ясности.

Совет: Последовательность событий может быть опциональной

Мы говорим, что шаги в сценарии использования, как правило, упорядочены по времени, но следует учитывать, является ли порядок шагов требованием. Например, субъект должен пройти четыре шага до завершения пятого шага? Обычно ответ будет да, но не всегда. Это очень просто, при разработке текстового описания для сценария использования, уточнить любые временные ограничения и добавить в предложение комментарии такие как «Этот шаг может выполняться в любом порядке» или «Этот шаг может выполняться в любое время перед этим шагом». Дело в том, Вы не хотите ограничивать разработчиков системы наличием неявных временных требований, когда они не являются необходимыми.

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

Совет: Используйте правильный уровень детализации

Один из наиболее часто задаваемых вопросов: «На сколько детально описывать сценарий использования?» Помните, что сценарий использования – это требования. Это не документация по проектированию, и они, конечно, не проект пользовательского интерфейса. Сценарии использования никогда не должны ссылаться на элементы пользовательского интерфейса, такие как домашние страницы, экраны входа или нажатие кнопки.

Кроме того, следует избегать архитектурной детализации. Например, в примере регистрации на курсы, выражение «график сохраняется в базе данных SQL Server» не должно быть в сценарии использования. Часть о сохранении графика необходима, но то где он сохраняется является архитектурной деталью, которая должна быть изменена позже, если администратор базы данных решит, что график должен быть сохранен в другой базе данных.

Совет: Поставьте себя на место субъекта

Сценарии использования отличаются использованием выражения «должен». Так как они указывают упорядоченные по времени шаги, они создают больше контекста, чем автономные выражения «должен», которые не являются зависимыми от времени. Поэтому они в большей степени соответствуют предназначению для пользователей. Имейте это в виду. Если сценарии использования это требования (а они и есть), проектировщики и разработчики будут ограничены тем, что они говорят. Помните об этом, пожалейте субъектов и пишите сценарии использования с помощью методов, которые сделают систему максимально удобной для пользователя.

Соглашение по структуре сценария использования и процессов важно для достижения качества и последовательности.

Заключение

При хорошем описании и последовательном подходе, сценарии использования могут быть отличным инструментом для описания требований таким образом, который вполне понятен для пользователей и заинтересованных сторон и, в то же время, готов к использованию в команде разработки. Но качество и согласованность может быть достигнута только при наличии согласования структуры сценария использования и процессов. Итак, последний совет: Документируйте решения Ваши и Вашей организации, сделанные на предмет того, как писать хорошие сценарии использования. Создайте документ руководство по стилю сценария использования или презентацию, обеспечьте авторов большим количеством примеров хороших сценариев использования и затем следуйте установленным руководящим принципам.

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

Дополнительная информация

Чтобы узнать больше о том, как писать эффективные сценарии использования и как IBM Rational Software может помочь, пожалуйста, обращайтесь к представителю компании или бизнес-партнеру IBM или посетите:

ibm.com/software/rational/offerings/irm

Posted in Полезное, Разное, Требования | Отмечено: , , , | 2 комментария »

 
%d такие блоггеры, как: