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

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

Posts Tagged ‘use case’

Use-Case 2.0. Сценарий использований 2.0 – содержимое

Posted by Shamrai Alexander на Май 23, 2018

Сценарий использования 2.0 состоит из набора элементов, с которыми нужно работать, и набора мероприятий.

С чем работать

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

Рисунок 1. Сценарий использования 2.0 – карта содержимого

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

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

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

Сценарии использования

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

Сценарий использования – это:

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

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

Рисунок 2. Жизненный цикл сценария использования

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

  1. Цель установлена: когда цель сценария использования была выяснена.
  2. Структура истории понятна: когда понимание структуры повествования сценария использования достаточно для команды, чтобы начать работу по выявлению и реализации первого слайса сценария использования.
  3. Простейшая история выполнена: когда система выполняет простейшую историю, которая позволяет пользователю достичь цель.
  4. Достаточно историй выполнено: когда система выполняет достаточно историй для обеспечения полезного решения.
  5. Все истории выполнены: когда система выполняет все истории, рассказываемые сценарием использования.

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

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

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

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

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

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

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

Рисунок 3. Жизненный цикл слайса сценария использования

Как показано на Рисунке 3, слайс сценария использования претерпевает некоторые изменения состояний от его первоначальной идентификации до окончательной приемки. Состояния являются важным методом, указывающим на понимание, реализацию и тестирование слайса сценария использования, отображая:

1) Границы определены: когда границы слайса определены и выявлено количество покрываемых историй.

2) Подготовлен: когда слайс был подготовлен путем улучшения повествования и тестовых сценариев для четкого определения, что значит успешная реализация слайса.

3) Проанализирован: когда слайс проанализирован и понятно его воздействие на компоненты системы, и затрагиваемые части готовы для написания кода и тестирования разработчиком.

4) Реализован: когда программная система была усовершенствована реализацией слайса, и слайс готов к тестированию.

5) Проверен: и, наконец, когда слайс был проверен как завершенный и готов для включения в релиз.

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

Истории

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

История описывается как часть повествования сценария использования, один или более потоков, специальные требования и один или несколько тестовых сценариев. Ключом к поиску эффективных историй — понять структуру повествования сценария использования. Сеть потоков можно рассматривать как карту, которая суммирует все рассказы, необходимые для описания сценария использования. Рисунок 4 иллюстрирует взаимосвязь между потоками повествования сценария использования и историй, которые они описывают.

Рисунок 4. Взаимосвязь между потоками и историями

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

Существует два общих подхода к выявлению историй и созданию повествований сценария использования:

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

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

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

Дефекты и изменения

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

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

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

Рабочие продукты

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

Рисунок 5. Рабочие продукты Сценария использования 2.0

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

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

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

Работа со сценариями использования и слайсами

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

На Рисунке 6 показаны сценарий использования и некоторые из его слайсов, зафиксированные на бумажных заметках.

Рисунок 6. Фиксация свойств сценария использования и его слайсов с помощью бумажных заметок

Отображенный сценарий использования является сценарием использования «7 Просмотр и покупка» для онлайн-покупок приложений. Слайсы 1 и 2 сценария использования основаны на индивидуальных историях, производных от основного потока: «Выбрать и купить 1 продукт» и «Выбрать и купить 100 продуктов». Слайс 3 основан на нескольких историях, покрывающих наличие различных систем поддержки, участвующих в сценарии использования. Эти истории охватывают целый ряд альтернативных потоков.

Основными свойствами сценария использования являются его имя, состояние и приоритет. В этом случае используется популярная схема приоритетов MoSCoW (Must, Should, Could, Would) — (Должен Быть, Стоит Иметь, Может Быть, Может не Быть). Сценарии использования должны также быть оценены. В этом случае используется простая схема оценки их относительного размера и сложности.

Основными свойствами слайса сценария использования являются 1) перечень его историй, 2) ссылки на сценарий использования и потоки, которые определяют истории, 3) ссылки на тесты и тестовые сценарии, которые будут использоваться для проверки его выполнения и 4) оценку работы, необходимой для имплементации и тестирования слайса. В этом примере истории используются для наименования слайса и ссылки на сценарий использования, скрытой в номере слайса, и на список потоков. Оценки были добавлены позднее после консультаций с командой. Это большие цифры в нижней правой части каждой бумажной заметки. В этом случае команда играет в покер планирования для создания относительных оценок с помощью баллов историй; 5 баллов историй для слайсов 7.1 и 7.2 и 13 баллов описаний для слайса 7.3, который, как команда считает, будет занимать более чем вдвое большее усилий в сравнении с другими слайсами. В качестве альтернативы могут использоваться идеальные дни, размеры футболки (XS, S, M, L, XL, XXL, XXXL) или любой другой популярный метод оценки.

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

Рисунок 7. Использование сценариев использования и слайсов для построения журнала продукта

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

Рисунок 8. Рабочий лист сценариев использования из простого инструмента отслеживания

Рисунок 9. Рабочий лист слайсов сценариев использования из простого инструмента отслеживания

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

Завершая рабочие продукты

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

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

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

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

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

Для получения дополнительной информации о рабочих продуктах и их уровней детализации см. Приложение 1: Рабочие продукты.

Что делать

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

Рисунок 11. Активности Сценария Использования 2.0

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

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

Найти субъекты и сценарии использования

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

  • Согласовать цели системы.
  • Договориться о новом поведении системы.
  • Ограничить релизы системы.
  • Согласовать значение, которое система обеспечивает.
  • Определить пути использования и тестирования системы.

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

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

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

СОВЕТ: МОЗГОВОЙ ШТУРМ МОДЕЛИРОВАНИЯ ЗАПУСТИТ ВАШУ МОДЕЛЬ СЦЕНАРИЕВ ИСПОЛЬЗОВАНИЯ

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

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

Разделить сценарии использования

Далее, вам нужно создать свой первый слайс сценария использования. Вы делаете это для:

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

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

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

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

Повторяйте эту активность всякий раз, когда требуются новые слайсы.

СОВЕТ: ВАМ НУЖЕН ТОЛЬКО ОСНОВНОЙ ПОТОК САМОГО ВАЖНОГО СЦЕНАРИЯ ИСПОЛЬЗОВАНИЯ ДЛЯ СОЗДАНИЯ ВАШЕГО ПЕРВОГО СЛАЙСА

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

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

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

Подготовить слайс сценария использования

После выбора слайса для разработки потребуются дополнительные действия для:

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

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

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

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

СОВЕТ: ЕСЛИ СЛАЙС НЕ ИМЕЕТ ТЕСТОВЫЕ СЦЕНАРИЕВ, ТО ОН НЕ ПОДГОТОВЛЕН ДОЛЖНЫМ ОБРАЗОМ

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

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

Анализировать слайс сценария использования

Перед началом создания кода следует проанализировать слайс для:

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

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

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

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

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

СОВЕТ: ХРАНИТЕ АНАЛИЗ ДОСТУПНЫМ И ЛЕГКИМ

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

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

Реализация программного обеспечения (по слайсам)

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

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

Тестирование системы (по слайсам)

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

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

Тестирование системы целиком

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

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

Изучать и адаптировать сценарии использования

Вам также нужно постоянно подстраивать и оценивать сценарии использования и слайсы сценария использования для:

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

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

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

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

СОВЕТ: НЕ ЗАБУДЬТЕ ПОДДЕРЖИВАТЬ ВАШ ЖУРНАЛ СЛАЙСОВ СЦЕНАРИЕВ ИСПОЛЬЗОВАНИЯ

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

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

Реклама

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

USE-CASE 2.0. Базовые принципы

Posted by Shamrai Alexander на Май 18, 2018

В основе любого успешного применения сценариев использования находятся шесть основных принципов:

  1. Сохранять их простыми, рассказывая истории
  2. Понимать общую картину
  3. Сосредотачивать внимание на значении
  4. Строить систему слайсами
  5. Поставлять систему инкрементами
  6. Адаптировать под потребности команды

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

Принцип 1: Сохранять их простыми, рассказывая истории

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

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

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

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

Принцип 2: Понимать общую картину

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

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

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

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

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

Принцип 3: Сосредотачивать внимание на значении

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

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

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

На Рисунке 2 показано повествование сценария использования, структурированное подобным образом. Самый простой способ достижения цели описывает основной поток. Другие представлены как альтернативные потоки. Таким образом вы создаете набор потоков, который структурирует и описывает истории, и помогает нам найти тестовые сценарии, которые дополняют их определение.

ОСНОВНОЙ ПОТОК АЛЬТЕРНАТИВНЫЕ ПОТОКИ
1. Вставить карту А1. Неправильная карта
2. Выполнить валидацию карты А2. Нестандартный сумма
3. Выбор получения наличных денег А3. Требуется квитанция
4. Выбор счета А4. Недостаточно средств в банкомате
5. Подтверждение доступности средств А5. Недостаточно средств на счету
6. Возврат карты А6. Возможен перерасход
7. Выдача наличных А7. Карта застряла
А8. Карта забыта
И т.д.

Рисунок 2. Структура рассказов сценариев использования

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

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

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

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

Принцип 4: Строить систему слайсами

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

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

Это подход, принятый в сценариях использования 2.0, где сценарии использования нарезаны для предоставления подходящего размера рабочих элементов, а сама система развивалась слайс за слайсом.

Нарезка сценариев использования

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

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

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

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

Слайсы – это больше, чем просто требования и тестовые сценарии

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

Рисунок 3. Слайс сценария использования больше, чем просто нарезка требований

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

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

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

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

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

Принцип 5: Поставлять систему инкрементами

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

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

Рисунок 4 показывает инкрементальную разработка версии системы. Первый инкремент содержит только один слайс: первый слайс от сценария использования 1. Второй инкремент добавляет еще один слайс из сценария использования 1 и первый слайс от сценария использования 2. Для создания третьей и четвертой частей добавляются дополнительные слайсы. Четвертый инкремент считается завершенным и достаточно полезным для реализации.

Рисунок 4. Сценарии использования, слайсы сценариев использования, инкременты и релизы

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

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

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

Принцип 6: Адаптировать под потребности команды

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

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

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

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

USE-CASE 2.0. Что такое сценарий использования 2.0?

Posted by Shamrai Alexander на Май 17, 2018

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

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

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

  • Легковесный
  • Масштабируемый
  • Универсальный
  • Простой в использовании

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

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

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

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

USE-CASE 2.0. Об этом руководстве

Posted by Shamrai Alexander на Май 16, 2018

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

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

Как читать это руководство

Руководство состоит из четырех основных глав:

  • Что такое сценарий использования 2.0? – одна страница введения в практику.
  • Базовые принципы – введение в сценарии использования, основанное вокруг 6-ти принципов, которые выступают в качестве основы для практики.
  • Сценарий использования 2.0 – содержимое – практика, представленная как набор ключевых концепций, деятельностей, рабочих продуктов и правил, которые связывают их вместе.
  • Использование сценариев использования 2.0 – резюме, когда и как применять практику.

Также есть краткое вступление, которое описывается этой главой, и короткое заключение.

Если вы новичок в теме сценариев использования, то вы можете прочитать главы «Что такое сценарий использования 2.0?», «Базовые принципы» и «Использование сценариев использования 2.0», чтобы понять основные концепции. Затем вы можете погрузиться в «Сценарий использования 2. 0 – содержимое» для понимания, как и когда вы начинаете применять практику.

Если вы знакомы с основами сценариев использования, то вы можете нырять прямо в главы «Сценарий использования 2. 0 – содержимое» и «Использование сценариев использования 2.0» после прочтения главы «Что такое сценарий использования 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 такие блоггеры, как: