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

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

Posts Tagged ‘requirements’

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 комментария »

CMMI DEV v1.3 – Разработка Требований

Posted by Shamrai Alexander на Февраль 21, 2011

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

Инженерная Процессная область уровня зрелости 3

Назначение

Назначением Разработки Требований (РТ) является выявление, анализ и установка требований заказчика, продукта и компонентов продукта.

Вступительный комментарий

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

Все проекты разработки имеют требования. Требования являются основой для проектирования. Разработка требований включает в себя следующие мероприятия:

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

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

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

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

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

Анализ используется, чтобы понять, определить и выбрать требования на всех уровнях от конкурирующих альтернатив. Этот анализ включают следующее:

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

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

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

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

  • Ограничения различных типов
  • Технологические ограничения
  • Затраты и управление затратами
  • Ограничение по времени и управление графиком
  • Риски
  • Рассмотрение вопросов подразумеваемых, но прямо не указанных заказчиком или конечным пользователем
  • Факторы, введенные уникальными бизнес соображениями разработки, правилами и законами

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

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

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

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

Связанные процессы

См. процессную область Интеграция Продукта для получения дополнительной информации об обеспечении совместимости интерфейсов.

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

См. процессную область Валидация для получения дополнительной информации об утверждении продукта или компонента.

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

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

См. процессную область Управление Требованиями для получения дополнительной информации об управлении требованиями.

См. процессную область Управление Рисками для получения дополнительной информации о выявлении и анализе рисков.

Перечень специфических целей и практик

  • СЦ 1 Разработать Требования Заказчика
    • СП 1.1 Выявляйте Потребности
    • СП 1.2 Трансформируйте Потребности Заинтересованных Сторон в Требования Заказчика
  • СЦ 2 Разработать Требования к Продукту
    • СП 2.1 Устанавливайте Требования к Продукту и Компонентам Продукта
    • СП 2.2 Распределите Требования к Компонентам Продукта
    • СП 2.3 Идентифицируйте Требования к Интерфейсам
  • СЦ 3 Выполнить Анализ и Валидацию Требований
    • СП 3.1 Устанавливайте Операционную Концепцию и Сценарии
    • СП 3.2 Устанавливайте Определение Необходимой Функциональности и Атрибутов Качества
    • СП 3.3 Анализируйте Требования
    • СП 3.4 Анализируйте Требования для Достижения Баланса
    • СП 3.5 Выполняйте Валидацию Требования

Специфические практики по целям

СЦ 1 Разработать Требования Заказчика

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

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

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

СП 1.1 Выявляйте Потребности

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

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

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

  • Технологические демонстрации
  • Рабочие группы контроля взаимодействия
  • Рабочие группы технического контроля
  • Промежуточный проектный анализ
  • Анкетирование, интервью и сценарии (операционные, поддержки и разработки), полученных от конечных пользователей
  • Операционный анализ, анализ поддержки и разработки и анализ задач конечных пользователей
  • Семинары с заинтересованными сторонами по выявлению атрибутов качества
  • Прототипы и модели
  • Мозговой штурм
  • Развертывание Функций Обеспечения Качества
  • Исследования рынка
  • Бета-тестирование
  • Извлечение из источников, таких как документы, стандарты или спецификации
  • Наблюдение за существующими продуктами, условиями работы и рабочими моделями
  • Сценарии использования
  • Пользовательские истории
  • Предоставление небольших инкрементальных «вертикальных срезов» функциональности продукта
  • Анализ бизнес сценариев
  • Обратный инжиниринг (для наследуемых продуктов)
  • Исследования удовлетворенности заказчиков

Примеры источников требований, которые могут быть не определены заказчиком, включают следующее:

  • Бизнес-политики
  • Стандарты
  • Предыдущие архитектурные решения проектирования и принципы
  • Бизнес требования среды (например, лаборатории, испытательные и другие средства, инфраструктура информационных технологий)
  • Технологии
  • Наследование продуктов или компонентов (компонентов продукта повторного использования)
  • Нормативные уставы

Примеры рабочих продуктов:

1. Результаты деятельности выявления требований

Подпрактики

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

СП 1.2 Трансформируйте Потребности Заинтересованных Сторон в Требования Заказчика

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

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

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

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

Пример рабочих продуктов

1. Требования заказчиков с установленными приоритетами

2. Ограничения заказчика на проведение верификации

3. Ограничения заказчика на проведение валидации

Подпрактики

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

2. Установите и поддерживайте установку приоритетов для требований для функциональности и атрибутов качества.

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

3. Определите ограничения для верификации и валидации.

СЦ 2 Разработать Требования к Продукту

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

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

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

См. процессную область Управление Требованиями для получения дополнительной информации о поддержке двунаправленной трассировки требований.

СП 2.1 Установите Требования к Продукту и Компонентам Продукта

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

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

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

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

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

См. процессную область Управление Требованиями для получения дополнительной информации об управлении требованиями.

Пример рабочих продуктов

1. Производные требования

2. Требования к продукту

3. Требования к компоненту продукта

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

Подпрактики

1. Разрабатывайте требования в технических терминах, необходимых в отношении продукта и компонента продукта.

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

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

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

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

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

Примеры мер атрибутов качества включают следующее:

  • Время ответа до 1 секунды
  • Доступность системы 99% времени
  • Внедрение изменений не превышает недельные трудозатраты одного сотрудника

4. Установите и поддерживайте связи между требованиями для рассмотрения в ходе управления изменениями и распределения требований.

См. процессную область Управление Требованиями для получения дополнительной информации о поддержке двунаправленной трассировки требований.

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

СП 2.2 Выделите Требования к Компонентам Продукта

Выделите требования для каждого компонента продукта.

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

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

Пример рабочих продуктов

1. Таблицы распределения требований

2. Предварительное распределение требования

3. Ограничения проектирования

4. Производные требования

5. Связи между производными требованиями

Подпрактики

1. Распределяйте требования по функциям.

2. Распределяйте требования по компонентам продукта и архитектуре.

3. Распределяйте ограничения проектирования по компонентам продукта и архитектуре.

4. Распределяйте требования по инкрементам поставки.

5. Документируйте связи между распределенными требованиями.

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

СП 2.3 Идентифицируйте Требования к Интерфейсам

Идентифицируйте требования к интерфейсам

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

См. процессную область Техническое Решение для получения дополнительной информации об обеспечении совместимости интерфейсов.

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

Пример рабочих продуктов

1. Требования к интерфейсам

Подпрактики

1. Определить взаимодействия как внешние, так и внутренние по отношению к продукту (например, между функциональными разделениями или объектами).

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

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

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

2. Разрабатывайте требования для идентифицированных взаимодействий.

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

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

СЦ 3 Выполнить Анализ и Валидацию Требований

Требования проанализированы и провалидированы.

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

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

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

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

СП 3.1 Устанавливайте Операционные Концепции и Сценарии

Установите и поддерживайте операционные концепции и связанные с ними сценарии.

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

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

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

Пример рабочих продуктов

1. Операционная концепция

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

3.Концепции утилизации

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

5. Повременные сценарии

6. Новые требования

Подпрактики

1. Разрабатывайте операционные концепции и сценарии, которые включают эксплуатацию, установку, разработку, обслуживание, поддержку и утилизацию по мере необходимости.

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

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

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

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

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

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

СП 3.2 Устанавливайте Определение Необходимой Функциональности и Атрибутов Качества

Устанавливайте и поддерживайте определение необходимой функциональности и атрибутов качества.

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

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

Пример рабочих продуктов

1. Определение необходимой функциональности и атрибутов качества

2. Функциональная архитектура

3. Диаграммы активности и сценарии использования

4. Объектно-ориентированный анализ с идентифицированными сервисами или методами

5. Архитектурно значимые требования атрибутов качества

Подпрактики

1. Определяйте ключевые направления миссии и бизнеса.

2. Определяйте желательные функциональность и атрибуты качества.

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

3. Определяйте архитектурно значимые атрибуты качества на основе ключевых направлений миссии и бизнеса.

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

Этот анализ может включать рассмотрение последовательности критических по времени функций.

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

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

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

8. Распределяйте требования по функциям и подфункциям (или другим логическим сущностям).

СП 3.3 Анализируйте Требования

Анализируйте требования на предмет необходимости и достаточности.

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

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

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

Пример рабочих продуктов

1. Отчеты по дефектам требований

2. Предлагаемые изменения в требования для исправления дефектов

3. Ключевые требования

4. Меры технических характеристик

Подпрактики

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

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

3. Анализируйте требования на предмет их полноты, осуществимости, реализуемости и возможности верификации.

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

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

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

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

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

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

СП 3.4 Анализируйте Требования для Достижения Баланса

Анализируйте требования для балансировки потребностей заинтересованных сторон и ограничений.

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

Пример рабочих продуктов

1. Оценка рисков, связанных с требованиями

Подпрактики

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

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

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

См. процессную область Управление Рисками для получения дополнительной информации о выявлении и анализе рисков.

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

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

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

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

СП 3.5 Выполняйте Валидацию Требования

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

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

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

  • Анализ
  • Симуляция
  • Построение прототипов
  • Демонстрация

Пример рабочих продуктов

1. Записи по методам и результатам анализа

Подпрактики

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

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

См. процессную область Валидация для получения дополнительной информации об утверждении продукта или компонента.

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

Posted in CMMI, Стандарты и методологии | Отмечено: , , , , | 2 комментария »

CMMI DEV v1.3 – Управление Требованиями

Posted by Shamrai Alexander на Декабрь 2, 2010

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

Процессная область Управления Проектом уровня зрелости 2

Назначение

Назначение Управления Требованиями (УПТР) состоит в управлении требованиями продукта или компонентов продукта в проекте для обеспечения соответствия этих требований с планами проекта и рабочими продуктами.

Вступительный комментарий

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

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

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

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

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

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

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

В среде Agile, требования передаются и связываются через механизмы, такие как журнал продукта, карта истории и макеты экрана. Утверждение требований принимаются коллегиально командой или уполномоченным руководителем группы. Распределение заданий регулярно (например, ежедневно, еженедельно) корректируется на основе достижений прогресса проекта, более глубокого понимания требований и выяснения решения. Трассируемость и согласованность между требованиями и рабочими продцуктами обеспечивается механизмами, которые уже упоминались, а также во время мероприятий начало-итерации или конец-итерации, таких как «ретроспективы» и «дни демонстрации». (См. «CMMI при использовании Agile подходов» в части I.)

Связанные процессные области

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

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

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

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

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

См. процессную область Управление Рисками для получения дополнительной информации о выявлении и анализе рисков.

Перечень специфических целей и практик

  • CЦ 1 Управлять Требованиями
    • CП 1.1 Достигните Понимания Требования
    • CП 1.2 Принимайте Требования на Реализацию
    • CП 1.3 Управляйте Изменениями Требований
    • CП 1.4 Поддерживайте Двухстороннюю Трассируемости Требований
    • CП 1.5 Обеспечивайте Согласованность Между Рабочими Продуктами и Требованиями

Специфические практики по целям

CЦ 1 Управление Требованиями

Требования управляемы и несогласованности с планами проекта и рабочими продуктами идентифицированы

Проект поддерживает набор текущих и утвержденных требований в течение всей длительности проекта, выполняя следующие работы:

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

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

См. практики Разрабатывайте Альтернативные Решения и Критерии Выбора процессной области Техническое Решение для получения дополнительной информации об определении реализуемости требований.

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

CП 1.1 Достигните Понимания Требования

Выработайте общее понимание значения требований с поставщиками требований

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

Пример рабочих продуктов

1. Список критериев, характеризующих соответствующих поставщиков требований

2. Критерии для оценки и приемки требований

3. Результаты анализов по критериям

4. Набор утвержденных требований

Подпрактики

1. Устанавливайте критерии, характеризующие соответствующих поставщиков требований.

2. Устанавливайте объективные критерии для оценки и принятия требований.

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

Примеры критериев оценки и принятия:

  • Четкая и правильная постановка
  • Полнота
  • Соответствие с другими
  • Уникально идентифицированное
  • Соответствие с архитектурным подходом и приоритетами атрибутов качества
  • Уместное для реализации
  • Проверяемое (т. е. тестируемость)
  • Трассируемое
  • Достижимое
  • Связано со значимостью для бизнеса
  • Отмечено как приоритетное для клиентов

3. Выполняйте анализ требований на соответствие установленным критериям.

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

CП 1.2 Принимайте Требования на Реализацию

Получите подтверждение требований на реализацию от участников проекта.

См. процессную область Мониторинг и Контроль Проекта для получения дополнительной информации о мониторинге реализации.

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

Пример рабочих продуктов

1. Оценка влияния требования

2. Задокументированные подтверждения на реализацию требований и изменений требований

Подпрактики

1. Оценивайте влияние требований на существующие работы.

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

2. Согласовывайте и запротоколируйте подтверждения.

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

CП 1.3 Управляйте Изменениями Требований

Управляйте изменениями требований по мере их возникновения в ходе реализации проекта.

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

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

Пример рабочих продуктов

1. Запрос на изменение требования

2. Отчеты о влиянии изменения требования

3. Состояния требований

4. База данных требований

Подпрактики

1. Документируйте все требования и изменения требований, которые поставляются или генерируются проектом.

2. Поддерживайте историю изменения требований, в том числе обоснования для изменения.

Сохранение истории изменений помогает отследить изменчивость требований.

3. Оценивайте воздействие изменения требований с точки зрения заинтересованных лиц.

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

4. Сделайте информацию о требованиях и изменениях доступными для проекта.

CП 1.4 Поддерживайте Двухстороннюю Трассируемость Требований

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

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

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

Пример, какие аспекты трассируемости можно рассматривать:

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

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

Пример рабочих продуктов

1. Матрицы трассировки требований

2. Системы отслеживания требований

Подпрактики

1. Поддерживайте трассируемость требований для гарантирования того, что источник для требования нижнего уровня (т. е. производного) документирован.

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

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

3. Создайте матрицу трассировки требования.

CП 1.5 Обеспечивайте Согласованность Между Рабочими Продуктами и Требованиями

Обеспечивайте соответствие планов проекта и рабочих продуктов с требованиями.

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

Пример рабочих продуктов

1. Документация о несоответствии между требованиями, планами проекта и рабочими продуктами, в том числе источники и условия

2. Корректирующие действия

Подпрактики

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

2. Определяйте источник несоответствия (если есть).

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

4. Инициируйте любые необходимые корректирующие действия.

Posted in CMMI, Стандарты и методологии | Отмечено: , , , , , | 2 комментария »

Руководство по управлению требованиями VS TFS 2010 – Контрольные списки для разработки требований

Posted by Shamrai Alexander на Ноябрь 30, 2010

<<Содержание

  1. Планирование приемочного тестирования
  2. Оценка результатов приемочного тестирования
  3. Запросы на изменения
  4. Декомпозиция работ
  5. Рецензирование проектирования верхнего уровня
  6. Рецензирование детального проектирования
  7. Рецензирование документов
  8. Формальная проверка проекта
  9. Инспекция документации
  10. Приемка продукта
  11. Определение вех проекта
  12. Проверка требований
  13. Стиль требований
  14. Сценарии или процедуры тестирования
  15. Проектирование тестов
  16. Рецензирование плана тестирования
  17. План управления тестированием
  18. Рецензирование вариантов использования

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

Вопрос

1 Решались ли проблемы с предыдущими поставками от этого поставщика, которые могут быть включены при планировании этих приемочных тестов?
2 Определены методы проверки по каждому требованию (инспекции, анализ, демонстрации или тесты)?
3 Критерии принятия задокументированы?
4 Трассировка Требований обеспечена и все требования были учтены? (Пользовательские требования — процедура тестирования)
5 Задокументированы условия испытаний для каждой среды?
6 Определено и согласовано специальное оборудование для тестирования?
7 Если необходимо восстановление данных, то инструменты, оборудование и люди для этого определены и согласованы?
8 Есть ли люди с необходимой специализацией для проведения тестов и люди, которые имеют эту специализацию, согласованы?
9 Разработаны детальные пошаговые процедуры для каждого теста?
10 Если пользователь должен подтвердить процедуру для теста, сделал ли он это?
11 Если необходимо применение QA, запланированы ли работы для отдела QA?
12 Если пользователь (или заказчик) должен заверить тесты, это запланировано?
13 Есть ли ограничения тестирования или результатов тестирования со стороны поставщиков, которые говорят, что специальные тесты должны быть выполнены во время приемочных тестов? Если это так, они включены в план?
14 Были ли определены возможные аномалии тестирования вместе с условиями, при которых они могут возникнуть, и методы работы с ними?
15 Определены процессы работы с отклонениями от тестовых процедур?
16 Определен процесс работы с дефектами до их закрытия?
17 Процедуры и инструменты тестирования позволяют выполнять удобное регрессионное тестирование?
18 Есть ли согласованный процесс для хранения результатов тестирования, в том числе, ответственный за журнал тестирования?
19 Другое

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

Вопрос

1 Все тестовые процедуры выполнены?
2 Аномалии были проанализированы, чтобы подтвердить правильность тестов?
3 Тесты были проведены при надлежащих условиях?
4 Тесты были заверены соответствующими людьми?
5 Восстановление данных было выполнено и проверено соответствующими лицами?
6 Отклонения были проанализированы и адресованы соответствующим лицам?
7 Все необходимые повторные тесты были выполнены без ошибок?
8 Если продукт был изменен в период тестирования, соответствующие лица проверили изменения на необходимость регрессионного тестирования?
9 ПО правильно работает с ограничениями других систем или платформ?
10 Приемочные тесты демонстрируют адекватность пользовательской документации?
11 Приемочные тесты демонстрируют адекватность обучения поставщика?
12 Приемочные тесты демонстрируют все необходимые характеристики качества?
13 Другое

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

Вопрос

Информация, предоставляемая поставщиком Запроса на Изменение
1 Уникальный идентификатор для запроса
2 Дата запроса
3 Кто внес запрос?
4 Тип запроса (например, дефект, улучшение, проблема и т.д.)
5 Запрос для какого продукта?
6 Запрос для какой версии?
7 Во время какой фазы обнаружен? (например, сборка, тестирование, внедрение, эксплуатация и т.д.)
8 Описание запроса
9 Важность для пользователя (пользовательский приоритет и уровень важности)
10 Другие
Информация, заполняемая экспертом
11 Имя эксперта
12 Дата экспертизы
13 Описание экспертизы
14 Если это дефект, наименование части жизненного цикла, в которую дефект был вставлен.
15 Если это дефект, наименование части жизненного цикла, в которой дефект был обнаружен.
16 Описание исправления
17 Время на исправление
18 Основные причины
19 Влияние изменения (описать все применяемые области)
Влияние на размер
Влияние на границы
Влияние на бюджет
Влияние на разработку
Влияние на график
Влияние на качество
Другое влияние
20 Влияние, если не будет исправлено
21 Приоритет разработки (приоритет для разработчика)
22 Рекомендуемая реализация
23 Рекомендуемое распоряжение
24 Другое
Параметры отслеживания запроса
25 Состояние запроса (например, открыт, на экспертизе, утвержден/отклонен, в процессе, завершен, закрыт и т.д.)
25 Дата утверждения/отклонения
25 Кем утвержден
25 Дата завершения
25 Дата закрытия
25 Кем закрыт
25 Другое

Структура декомпозиции работ
Предполагаемое использование списка Для команды проекта, менеджера и/или наставника для разработки или проверки структуры декомпозиции работ.
Руководства декомпозиции работ Декомпозиция работ предполагает разделение основных работ проекта на небольшие, более управляемые компоненты до тех пор, пока эти работы не будут достаточны для поддержки задач будущего проекта (планирование, исполнение, контроль и закрытие)
ID

Вопрос

1 Все работы представлены в плане?
2 Каждый рабочий элемент связан с одной задачей в плане?
3 Каждая задача имеет определенные критерии окончания?
4 Каждая задача имеет единственный связанный рабочий элемент?
5 Каждая задача требует небольшое количество людей для реализации?
6 Каждая задача настолько мала, что позволяет быстро обнаружить проблему для ее быстрого исправления?
7 Декомпозиция задач уточняется при выполнении проекта?
8 Задачи были декомпозированы корректно?
Элементы нижнего уровня необходимы и достаточны для выполнения декомпозируемого элемента? Если нет, составные элементы должны быть модифицированы (добавлены к, удалены из или пересмотрены).
Каждый элемент четко и полностью определен? Если нет, то описания должны быть модифицированы или расширены.
Возможно ли на каждый элемент надлежащим образом определены плановые сроки и бюджет? Возможно ли на каждый элемент соответствующим образом назначить специальную организационную единицу (например, отдел, группа или лицо), которая будет нести ответственность за удовлетворительное завершение этого элемента? Если нет, то необходимо внести изменения, чтобы обеспечить адекватный контроль для управления.
9 Элементы декомпозиции часто забываются
Верификация и валидация включены?
Управление проектом и администрирование включены?
Анализ обеспечения качества включен?
Управление конфигурациями включено?
Документация (руководства, процедуры) включены?
Разработка тренингов и тренинги включены?

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

Тип дефекта

Вопрос

Организация и Структура Документации
1 Стандарты Каждый компонент спецификации соответствует стандартам организации?
2 Стандарты Целевая аудитория определена?
Полнота и корректность
3 Неполный Все элементы проекта верхнего уровня включены?
4 Неполный Все предложения проектирования включены в спецификацию?
5 Некорректный Документ не имеет фактических ошибок?
6 Неполный Основные альтернативные пути и их оценки представлены? Компромиссные проекты и критерии выбора задокументированы?
7 Неполный Критерии или условия, необходимые для разработки эффективного решения, адекватно описаны? Разумны ли они?
8 Неполный Проект отражает действительную операционную среду, аппаратное и программное обеспечение?
9 Неполный Вопросы производительности затронуты?
10 Неполный Все возможные состояния и сценарии рассмотрены?
11 Неполный Требования к хранению данных определены?
12 Неполный Проект описывает обнаружение ошибок и восстановление?
13 Неполный Есть ли модель пользовательского интерфейса?
14 Неполный Есть ли модели для других интерфейсов?
15 Неполный Количество и сложность интерфейсов задокументированы?
16 Неполный Есть ли функциональная модель высокого уровня?
17 Неполный Есть ли концептуальное представление для всех составных элементов данных?
18 Неполный Управление и использование общих данных описано?
Последовательность и прозрачность
19 Неоднозначный Документ имеет неоднозначные и слова, имеющие различные варианты интерпретации?
20 Непоследовательный Документ последователен между своими компонентами?
21 Неоднозначный Границы и ограничения проекта ясны, и в документе четко указано, какие функции будут (и не будут) обеспечены и какие ожидания будут (и не будут) удовлетворены?
22 Неоднозначный Существуют ли ограничения и последствия, если таковые имеются, в этом решении ясно описано?
23 Непроверяемый Может проект быть поэтапно протестирован и интегрирован?
24 Непоследовательный Проект соответствует установленным бизнес практикам и стандартам?
Трассируемость
25 Другое — Трассируемость Проект имеет связь с требованиями?
26 Другое — Трассируемость Требования имеют связь с проектом?
Интерфейсы
27 Другое – Качество Дизайна Документ удовлетворяет потребности аудитории?
28 Другое – Качество Дизайна Проект адаптивен к будущим изменениям?
29 Другое – Качество Дизайна Проект модульный?
30 Другое – Качество Дизайна Модули имеют сильное зацепление и слабую связанность?
31 Другое – Качество Дизайна Проект отражает систему, которую просто поддерживать?
32 Другое – Качество Дизайна Есть разумные доводы того, что люди, которые разработали проект, задали правильные вопросы и действительно поняли потребности и проблемы клиентов?

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

Тип дефекта

Вопрос

Организация и Структура Документации
1 Стандарты Каждый компонент спецификации соответствует организационным стандартам?
2 Стандарты Документ прост в использовании и поддержке?
Полнота и корректность
3 Неполный Все компоненты или интерфейсы, которые необходимы для этой части архитектуры системы, выявлены и полны?
4 Неполный Каждый компонент проектной спецификации внутренне полон? Это задокументировано адекватно?
Последовательность и прозрачность
5 Непроверяемый Каждый элемент дизайна тестируемый или как-то иначе проверяемый?
6 Непроверяемый Каждый элемент может быть протестирован, продемонстрирован или проанализирован на соответствие требованиям и, следовательно, проверен?
7 Непоследовательный Детализируемые компоненты и их интерфейсы согласованы с друг с другом?
8 Непоследовательный Спецификация каждого компонента последовательна внутри?
Данные
9 Данные Все внутренние данные, которые необходимы для каждого компонента, определены?
10 Данные Все элементы данных имеют наименование и используются согласовано в проекте?
11 Данные Все внешнее использование общих данных идентифицировано?
12 Данные Все внешнее использование общих данных определено?
13 Данные Существуют какие-либо конфликтные использования данных?
14 Данные Переменные инициализируются и их значения проверяются перед использованием?
Интерфейсы
15 Интерфейс Детальный проект связан с проектом высокого уровня?

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

Тип дефекта

Вопрос

Организация и структура документации
1 Стандарты Цели документа определены?
2 Стандарты Технический уровень соответствует выбранной аудитории и целям?
3 Стандарты Формат документа последователен?
4 Стандарты Документ отвечает стандартам документации?
5 Стандарты Организация документа способствует простому поиску информации?
Полнота и корректность
6 Неполный Все фазы жизненного цикла документа были пройдены?
7 Неполный Отзывы пользователей были получены?
8 Неполный Адекватны ли условия для поставки документации и последующих изменений?
9 Неполный Все содержание документа адекватно?
10 Неполный Все важные темы присутствуют?
11 Некорректный Документация не имеет актуальных ошибок?
12 Неполный Есть ли глоссарий, если необходимо? Он полон?
13 Некорректный Определения верны?
14 Неполный Есть ли лист содержания, если необходимо?
15 Некорректный Лист содержания корректный и легкодоступен?
16 Неполный Разделы руководства включены, если необходимо?
17 Некорректный Примеры, диаграммы, рисунки и другие визуальные материалы корректны?
18 Неполный Есть ли индекс, если необходимо? Он легкодоступен?
19 Неполный Индекс адекватно детализирован
20 Некорректный Номера страниц в индексе совпадают?
21 Неполный Все ли элементы, которые могут искать различные пользователи, включены в индекс?
Последовательность и прозрачность
22 Неоднозначный Цели документа четко определены?
23 Непоследовательный В документе отсутствуют противоречия?
24 Неоднозначный Верна ли терминология? Она соответствует аудитории и целям?
25 Непоследовательный Терминология непротиворечива в документе?
26 Неоднозначный Стиль написания понятен? Отдельные параграфы отражают только одну мысль или связанные мысли?
27 Неоднозначный Примеры, диаграммы, рисунки и другие визуальные материалы понятны?
28 Непоследовательный Примеры, диаграммы, рисунки и другие визуальные материалы необходимы и относятся к тому месту, где используются?
29 Непоследовательный Индексы находятся под правильными разделами?

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

Вопрос

Статическая документация
1 Описание проекта (назначение, границы и цели)
2 Основные заинтересованные лица, включая спонсоров
3 Основные поставки, включая бизнес цели и выгоду
4 Архитектурные диаграммы высокого уровня, отражающие организационные и системные интерфейсы
5 Команда проекта
Промежуточная версия документации
6 Описание проекта (назначение/границы/цели)
7 Основные заинтересованные лица, включая спонсоров
8 Основные поставки, включая бизнес цели и выгоду
9 Архитектурные диаграммы высокого уровня, отражающие организационные и системные интерфейсы
10 Команда проекта
Документация по рискам
11 Основные проблемы и вопросы
12 Основные риски
13 Основные зависимости, особенно которые в ожидании или в риске
Планируемая на последующие шаги документация
14 Основные промежуточные корректировки, связанные с требованиями, кадровым обеспечением и зависимостью изменений
15 Основной план рисков (стратегия снижения и план последствий)
16 Следующие шаги
17 Запрос помощи от исполнителей, если требуется
18 Специализированная отчетность только по этому проекту (добавление любых необходимых отчетов для последующего использования)

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

Тип дефекта

Вопрос

1 Прозрачность Некоторые элементы документа сложны восприятия или весь документ сложно читать.
2 Полнота Некоторые необходимые компоненты пропущены.
3 Сложность Некоторые части документа необходимо упростить для целевой аудитории.
4 Последовательность Некоторые части документа конфликтуют с другими связанными документами.
5 Корректность Документ имеет ошибки.
6 Определение Определения пропущены, ошибочны или лишние.
7 Формат Документ не соответствует предопределенному формату организации для этого типа документа.
8 Грамматика Присутствуют грамматические ошибки в документе
9 Организация Порядок, в котором представлен документ, неудобен и неэффективен.
11 Излишество Некоторые части документа избыточны и не соответствуют целям документа.
12 Пунктуация Присутствуют несоответствия в пунктуации и выделениях в документе.
13 Стандарты Документ не соответствует стандарту документации для этого типа документа.
14 Стиль Документ в некоторых моментах не соответствует руководству организации по стилям документации.
15 Версия Нигде нет информации о версии или она не соответствует стандартам организации.

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

Вопрос

1 Результаты приемочных тестов проанализированы?
2 Поставляемые материалы соответствуют всем функциональным требованиям?
3 Поставляемые материалы соответствуют всем требованиям к продукту?
4 Готова ли документация по эксплуатации?
5 Соответствующие люди проверили и утвердили документацию (заказчик, покупатель и поставщик)?
6 Документация соответствует конечному продукту?
7 Информация о релизе описывает дефекты и методы их обхода?
8 Если существуют требования обязывающие принять продукт «как есть», соответствующие документы были оформлены и утверждены?
9 Все ли поставки, описанные в контракте, были предоставлены поставщиком?
10 Все ли поставки, описанные в контракте, были обновлены до последней версии?
11 Описаны ли процедуры обработки ошибок после поставки продукта?
12 Если предусмотрено контрактом, программное обеспечение и другие необходимые артефакты были помещены под условное хранение?
13 Если продукт будет поддерживаться поставщиком, существует ли соответствующие последующее соглашение, которое позволяет закрыть текущее соглашение?
14 Все ли нерешенные вопросы, связанные с продуктом или контрактом, были обработаны и закрыты?
15 Другое

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

Вопрос

Документ Границы Проекта на достаточном уровне описывает, что проект должен достичь и в какой среде? Следующие пункты должны быть определены:
1 Общие Границы Проекта
2 Элементы вне границ
3 Бизнес Цели/Потребности
4 Бизнес и Технические Ограничения
5 Разделы по Изменениям в Бизнес Процессе/Получение Подтверждения Изменений
6 Основные Интерфейсы/Интеграционные Требования
7 Основные Системные Возможности и Функции с указанными потенциальными релизами продукта
8 Затрагиваемые Организации и Подразделения
Альтернативы Продукта определены и рассмотрены? Компоненты могут включать:
9 Технико-экономическое обоснование
10 Оценка Альтернативных Решений (включая существующие приложения и/или компоненты)
11 Потенциальные Продукты Поставщика
12 Анализ необходимости Покупки или Разработки
Условия Развертывания были задокументированы и рассмотрены соответствующими участниками?
13 Все основные вопросы, поступившие от рецензентов, были решены?
План проекта это включает?
14 Высокоуровневую оценку по стоимости и трудозатратам для всего проекта
15 Детальную оценку стоимости трудозатрат, стоимости, плана и планируемых трудовых ресурсов для фазы Анализа
16 Предлагаемый жизненный цикл
17 Проектные роли и ответственности
18 Начальный набор проектных рисков и планы снижения
Анализ оценки рентабельности выполнен?
19 Какой приоритет у проекта по сравнению с другими проектами, которые находятся в очереди ожидающих разработку проектов?

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

Тип дефекта

Вопрос

Организация и структура документа
1 Стандарты Соответствующие стандарты документирования требований выдержаны?
2 Стандарты Все рисунки, таблицы и диаграммы подписаны и имеют ссылку?
3 Стандарты Все термины и единицы измерений определены?
4 Стандарты Все требования описаны последовательно и на соответствующем уровне детализации?
5 Стандарты Отдельные требования имеют ранг с описанием установленного приоритета?
6 Непроверяемое Требования обеспечивают адекватный базис для разработки и системного тестирования?
Полнота и корректность
7 Корректность Все ли внутренние перекрестные связи с другими требованиями корректны? (Для модифируемости минимизируйте перекрестные связи)
8 Неполное Все классы пользователей описаны? Все пользовательские характеристики описаны?
9 Неполное Спецификация включает все известные потребности заказчика или системы? Все ли задачи, которые необходимо выполнять пользователям, указаны?
10 Неполное Каждое функциональное требование описывает вход, выход и функцию, если это необходимо?
11 Неполное Все зависимости от других систем определены? Включены другие приложения или интерфейсы приложений, базы данных, связующие подсистемы, сеть и т.д.
12 Неполное Требования к документации и обучению определены?
13 Неполное Аппаратная и программная среда указана?
14 Неполное Все поставляемые требования были включены? Здесь включаются те, которые подразумевают системные и программные требования, которые в основном ограничивают разработку или верификациию.
15 Неполное Полный жизненный цикл определен, включая поддержку?
16 Неполное Какие либо ограничения разработки и реализации описаны?
17 Неполное Все требования к надежности, восстанавливаемости (непрерывности бизнеса) и производительности правильно указаны??
18 Неполное Все требования к безопасности правильно указаны?
19 Неполное Все требования к защищенности правильно указаны?
20 Неполное Все требования к конфиденциальности данных указаны?
21 Неполное Определены ли критичные ко времени/длительности функции, и критерии определения времени указаны для них?
22 Неполное Нормативные, законодательные и требования на основе стандартов были указаны?
23 Неполное Все атрибуты (характеристики) качества были правильно указаны (например, эффективность, гибкость, совместимость, возможность поддержки, мобильность, возможность многократного использования, удобство и доступность)?
24 Неполное Требования к непрерывности бизнес процесса и восстановлению после сбоев были учтены?
25 Интерфейс Требования к интерфейсам взаимодействия с пользователем были учтены? Они корректны?
26 Интерфейс Все внешние аппаратные, программные и коммуникационные интерфейсы определены? Они корректны?
Последовательность и прозрачность
27 Противоречивое Спецификация согласуется с соответствующими документами верхнего уровня?
28 Противоречивое Требования имеют дубликаты или конфликты с другими требованиями?
29 Противоречивое Все требования написаны последовательно, понятно и лаконично?
30 Неоднозначное Каждое требование имеет только одну интерпретацию? Если термины имеют несколько значений, это указано?
31 Непроверяемое Каждое требование может быть проверено через тест, демонстрацию, рецензию или анализ?
32 Непроверяемое Существуют измеряемые критерии приемки для каждого функционального или нефункционального требования?
Трассируемость
33 Интерфейс Каждое требование уникально и корректно идентифицировано?
34 Интерфейс Каждое требование имеет связь с его источником (включая производные требования)?
35 Другое Каждое требования в границах проекта?

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

Вопрос

1 Каждое требование должно включать слова должно быть или должно.
2 Каждое требование должно быть написано в кратком предложении и с использованием простых терминов.
3 Каждое предложение должно включать только одно требование.
4 Каждое требование должно четко совпадать с содержанием, приведенным в предложении.
5 Обобщающие термины (такие как все, каждый, никогда и всегда) не должны использоваться в требованиях, если требование должно быть проверяемым.
6 Неопределенные термины (такие как будет определено в дальнейшем, будет описано в дальнейшем и т.д.) не должны использоваться в требованиях, кроме случаев, когда будут выполнены согласования и утверждения для каждого такого термина.
7 Каждое требование должно быть написано в утвердительной форме.
8 Каждое требование должно быть грамматически правильным.
9 Объединение И показывает, что все элементы в требовании должны быть в значении «истина», чтоб удовлетворять назначению требования.
10 Каждое требование, которое включает объединение ИЛИ должно четко показывать где «включаемое или» или «исключаемое или». «Включаемое или» позволяет одному или обеим альтернативам быть в значении «истина», а «исключаемое или» позволяет только одной альтернативе быть в значении «истина».
11 Использование косой черты , например, и/или или проводник/земля не должны использоваться в требованиях.
12 Каждое требование должно быть в границах проекта.
13 Термины и сокращения должны быть определены в глоссарии, списке или в тексте.

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

Тип дефекта

Вопрос

Организация и стандарты
1 Стандарты Соответствующие заинтересованные лица были вовлечены в разработку и утверждение сценариев тестирования и процедур тестирования?
2 Стандарты Люди, которые разрабатывают тестовые сценарии или процедуры, имеют глубокий опыт в области приложений, технической среды и техник тестирования, чтоб быть достаточно способными для разработки адекватных тестов?
3 Стандарты Тестовые процедуры или сценарии отвечают стандартам организации?
Полнота и корректность
4 Неполный Когда выполняется оценка всего пакета тестов, сценарии или процедур тестирования охватывают все типы необходимых тестов (например, тестирование функциональности приложения, тестирование производительности, тестирование удобства использования, тестирование на нескольких платформах, он-лайн помощи, тестирование документации пользователя и т.д.)
5 Неполный В каждом тесте полностью указаны все необходимые входные параметры, альтернативные пути и ожидаемый результат?
6 Другое Отдельные тесты возможны и выполнимы?
7 Неполный Описание целей каждого теста полное?
8 Другое Описание целей каждого теста точное?
9 Неполный Ожидаемый результат для каждого шага каждого теста описан, даже если входные параметры вне требуемого диапазона?
10 Неполный Тестовые сценарии демонстрируют реакцию системы на неправильные или конфликтующие входные параметры?
11 Неполный Зависимости тестовых процедур идентифицированы?
12 Неполный Каждая процедура тестирования определяет предшествование вовлеченных тестов?
Последовательность и прозрачность
13 Другое Пользовательские инструкции подробны и понятны для выполнения каждого тестового сценария?
14 Другое Инструкции для каждого теста представляют пошаговое и упорядоченное выполнение?
15 Неоднозначный Критерии успешного выполнения или провала теста понятны и однозначны?
16 Противоречивый Глубина и основательность тестирования (т.е. процент детального покрытия, которые обеспечивает тест) для каждой возможности совпадает с операционным профилем этой возможности?
17 Противоречивый Величина функционального покрытия соответствует рискам продукта?
18 Противоречивый Процедуры тестирования совместимы с возможностями средств тестирования?
Трассируемость
19 Интерфейс Тестовые сценарии обратно связанны с требованиями?
20 Интерфейс Есть ли перекрестная связь между сценариями тестирования и тестируемыми возможностями?

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

Тип дефекта

Вопрос

Организация и стандарты
1 Стандарты Соответствующие заинтересованные лица были вовлечены в разработку и утверждение?
2 Стандарты Люди, которые разрабатывают тесты, имеют глубокий опыт в области приложений, технической среды и техник тестирования, чтоб быть достаточно способными для разработки адекватных тестов?
3 Стандарты Тестовые процедуры или сценарии отвечают стандартам организации?
Полнота и корректность
4 Неполный Границы проекта тестирования охватывают все типы тестов, которые необходимы, как указано в плане тестирования?
5 Неполный Проект тестирования включает методы определения ответа системы на неправильные и конфликтующие входные параметры?
6 Неполный Проект тестирования содержит критерии успешного выполнения или провала теста для каждой тестируемой возможности
7 Неполный Все ли поддерживаемые тестовые сценарии перечислены в спецификации проекта тестирования?
8 Неполный Каждый перечисленный тестовый сценарий имеет процедуры, определяющие его использование?
Последовательность и прозрачность
9 Противоречивый Глубина и основательность методов тестирования для каждой возможности совпадает с операционным профилем этой возможности?
10 Непонятный Критерии для теста «успешен-провален» понятны и однозначны?
11 Противоречивый Элементы, которые будут тестироваться, непротиворечивы с тестируемыми возможностями?
12 Противоречивый Величина функционального покрытия соответствует рискам продукта?
13 Противоречивый Возможности (или комбинация возможностей), которые будут тестироваться в этом проекте, совпадают с теми, которые были указаны в плане тестирования для этого теста?
14 Противоречивый Все тестовые элементы этого проекта тестирования соответствуют тем, которые идентифицированы в плане или планах тестирования?
15 Противоречивый Этот проект связывает каждую возможность (или комбинацию возможностей), которая будет тестироваться в этом проекте тестирования, с одним или более описанием требований или дизайна?
16 Противоречивый Этот проект связывает каждую возможность (или комбинацию возможностей), которая будет тестироваться в этом проекте тестирования, со всеми связанными описаниями требований или дизайна?

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

Тип дефекта

Вопрос

Организация и стандарты
1 Стандарты План тестирования соответствует шаблону плана тестирования или каким-то другим стандартам?
2 Стандарты Существуют ли перекрестные ссылки между планом тестирования и планом проекта для проекта, продукт которого будет тестироваться?
3 Стандарты Все ли заинтересованные лица вовлечены в разработку и утверждение плана тестирования?
Полнота и корректность
4 Неполный План определяет, что нужно тестировать и что не нужно тестировать?
5 Неполный План определяет критерии приемки?
6 Неполный Результирующие артефакты тестирования определены в плане?
7 Неполный Стратегия тестирования явно описана?
8 Неполный Все необходимые фазы тестирования указаны в плане тестирования?
8 Неполный План описывает ресурсы необходимые для выполнения плана?
9 Неполный Ресурсы назначены рационально по объему, доступности и уровню?
10 Неполный Риски, связанные с качеством продукта, определены в плане тестирования?
11 Неполный План содержит мероприятия по управлению рисками?
Последовательность и прозрачность
12 Противоречивый Заданные границы трассируются с требованиями к продукту?
13 Противоречивый Если некоторые возможности не тестируются или тестируются незначительно, это оправдано?
14 Противоречивый Если тест для нового релиза или обновления существующей системы, регрессионное тестирование не противоречит этой частной ситуации?
15 Противоречивый Логистика соответствует стратегии и ресурсам, определенным в плане?
16 Противоречивый Планируемый объем работ по тестированию пропорционален объему трудозатрат разработки и поддержки проекта?
Элементы, связанные с План Управления Тестированием
Полнота и корректность
17 Неполный План тестирования определяет критические факторы успешности продукта?
18 Неполный Документ явно определяет пользовательские (заказчика) критерии приемочного тестирования?
19 Неполный Общие цели тестирования явно определены?
20 Неполный План включает мероприятия по обеспечению качества для работ по тестированию?
21 Неполный План включает или ссылается на процессы управления конфигурацией?
22 Неполный План включает описание организации команды тестирования, включая структуру отчетности?
23 Неполный План явно идентифицирует какие фазы и цели тестирования должны быть выполнены?
24 Неполный Если тест для нового релиза или обновления существующей системы, опыт взаимодействия с системой и ее история предыдущих ошибок отражена в плане для тестовых сценариев?
Элементы, связанные с Детальным Планом Тестирования
Полнота и корректность
25 Неполный Задачи тестирования указаны в плане тестирования?
26 Неполный План описывает инструменты, которые должны использоваться для тестирования продукта?
27 Неполный План обучения инструментам (если необходимо) оговариваются планом?
28 Неполный Задачи по подготовке среды тестирования включены в план?
Последовательность и прозрачность
29 Противоречивый Глубина и основательность тестирования (например, процент детального покрытия, которые обеспечивает тест) совпадает с рисками продукта?
30 Неоднозначный Критерии успешного выполнения или провала теста понятны и однозначны?

План управления тестированием
Предполагаемое использование списка Для команды тестирования при оценке их программных (или системных) планов тестирования для определения или соответствующие элементы покрыты.
ID

Вопрос

1 План тестирования соответствует общему плану проекта?
2 Главные функции запланированы для тестирования на ранних стадиях цикла тестирования?
3 График тестирования явно определен?
4 Ресурсы тестирования (свободное место, оборудование и персонал) уже доступны или планируется их доступность, когда это необходимо?
5 Инструменты тестирования уже доступны или они будут доступны, когда будет необходимо?
6 Механизм хранения результатов тестирования установлен?
7 Все соответствующие фазы тестирования, роли и ответственности в плане установлены (тесты модульные, системные, альфа, беты, приемочные и т.д.)?
8 Если необходимо, указаны и запланированы тесты по миграции данных, больших объемов данных, нагрузочному и стрессовому тестированию?
9 Если необходимо, производительность будет выполняться согласно спецификации продукта?
10 Все требования тестирования, которые указаны в документе по требованиям, затронуты?
11 Критерии приемки для продукта были определены?
12 Риски для плана тестирования определены, и планы смягчения разработаны?
13 Существует ли планы реакции для рисков, которые могут осуществиться?
14 Мероприятия по управлению рисками отслеживаемы?
15 Есть ли полный список того, что не будет тестироваться?
16 Другое

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

Тип дефекта

Вопрос

Организация и стандарты
1 Стандарты Вариант использования самостоятельная, дискретная задача?
2 Стандарты Вариант использования написан на необходимом уровне, а не как конкретные сценарии?
3 Стандарты Вариант использования не имеет описания разработки или реализации?
4 Стандарты Вариант использования ограничен 10 шагами или менее?
5 Стандарты Варианты использования именуются фразой в виде глагола целевого действия, что указывает на цель основного актора?
Полнота и корректность
6 Неполный Цели всех акторов затронуты?
7 Неполный Все акторы представлены (прямо или косвенно)?
8 Неполный Все ожидаемые альтернативные варианты задокументированы?
9 Неполный Все известные условия исключений задокументированы?
10 Неполный Последовательности диалога для каждого курса полны?
11 Некорректный Главный актор в каждом варианте использования подходит для выполнения этой задачи?
12 Некорректный Описанный курс в варианте использования выполним?
13 Некорректный Каждый шаг в варианте использования подходит для достижения цели варианта использования?
14 Некорректный У основного актора есть верное поведение?
Последовательность и прозрачность
15 Неоднозначный Цели или измеряемое значение варианта использования понятны?
16 Неоднозначный Понятно какой атор или акторы получают выгоду от варианта использования?
17 Неоднозначный Всевозможные общие последовательности действий были заложены в отдельные варианты использования?
18 Неоднозначный Последовательность диалога для каждого курса описана понятно и однозначно?
19 Непроверяемый Каждый курс, описанный в варианте использования, проверяем?

Posted in Стандарты и методологии, Управление требованиями, Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , | 1 Comment »

Руководство по управлению требованиями VS TFS 2010

Posted by Shamrai Alexander на Июль 27, 2010

Перевел очередное руководство проекта Visual Studio ALM Rangers «Visual Studio 2010 Team Foundation Server Requirements Management Guidance«, которое рассказывает о возможностях TFS 2010 для организации эффективного процесса управления требованиями. Изначально это руководство готовилось для реализации процесса на TFS 2010 Beta1, поэтому есть один момент, который будет отличаться для релизной версии TFS 2010. Этот момент заключается в использовании рабочего элемента Возможность (Feature): в TFS 2010 Beta1 это был отдельный рабочий элемент, а уже в окончательной редакции он является просто отдельным типом Возможность рабочего элемента Требование. Поэтому при реализации у себя в организации изложенных в этом руководстве практик, учтите этот момент.

Содержание руководства:

  1. Введение в Управление требованиями с использованием Team Foundation Server. Целью данного руководства является предоставление формализованного опыта Microsoft в виде рекомендованных процедур и процессов, конфигураций Visual Studio Team System и Team Foundation Server, а также развитие навыков по дисциплине Инженерия требований вашего жизненного цикла разработки ПО. Ввиду изменчивости и вопреки методик, используемых в индустрии, в этом руководстве эти задачи приведены тремя способами.
    • Общие Руководство по Разработке
    • Традиционная разработка
    • Гибкая разработка
  2. Планирование управления требованиями. План управления требованиями должен быть разработан для определения и механизмов контроля информации, которая будет собираться и использоваться для сбора метрик, отчетности и контроля изменений требований к продукту.
  3. Трассировка Требований. Трассировка, вероятно, наиболее важный аспект в инженерии требований, который обеспечивает подотчетность команды разработки. Кроме этого, она помогает:
    • Идентифицировать источник и важность требований
    • Управлять масштабом проекта
    • Управлять изменениями требований
    • Оценить воздействие на проект изменения требований или других элементов проекта
    • Оценить влияние провала тестирования требований (например, не пройденный тест может означать, что требование не выполнено)
    • Убедиться, что все требования к системе будут выполнены при реализации
    • Убедиться, что приложение делает то, для чего оно предназначено
    • Дать разработчику контекст требований для задачи
  4. Анализ и Декомпозиция. Анализ и Валидация выполняются для:
    • Установки рабочей концепции и сценариев (требования продукта – например, пользовательские цели и контекстные диаграммы; требования компонента продукта – например, технические ограничения и рабочая концепция)
    • Установки и поддержки определения необходимых функциональных возможностей (функциональная архитектура, диаграммы деятельности и сценарий использования, объектно-ориентированный анализ с идентифицированными сервисами)
    • Анализа требований (дефекность/изменчивость требований, изменения требований, технические критерии качества выполнения, оценка рисков)
    • Валидации требований со всесторонними методами (Отчет о методах анализа и результатах)
  5. Выявление требований. Этот документ описывает выявление требований на каждом из своих эволюционных уровней в рамках параметров двух различных методологий: традиционной разработки приложений и гибкой методологии. Visual Studio и Team Foundation Server обеспечивают общую технологию для двух типов методологий и служат для планирования, хранения, отслеживания и отчетности в хранилище для всех стадий выявления.
  6. Спецификация требований. Независимо от уровня иерархии при выявлении требований (бизнес, системные или реализация), существуют некоторые основные свойства Team Foundation Server 2010, которые необходимо понимать для определения требований и их проверки. Этот раздел рассказывает о документировании различных элементов требований в виде рабочих элементов и использовании других методов.
  7. Валидация требований. Валидация представляет собой процесс оценки, будет ли конечный продукт удовлетворять требованиям заказчика, и помогает удостовериться, что требования были правильно поняты. Такой подход к поставке в последнее время называют «Test-First Development» или «Requirements-Based Testing».
  8. Управление изменениями и утверждение требований. Управление изменениями требований и утверждение описывает, как участник процесса формально получает утверждение для новых требований или изменений/расширений существующих требований. Фокус в этом разделе будет сделан на описании действий процесса изменения требований, управления базовыми линиями требований и разрешения на продолжение работ по реализации требования. Также будет уделяться большое внимание к соблюдению промышленных стандартов таких, как CMMI и ITIL, соответствие отраслевым нормам такие, как FDA CFR-21, Часть 11 и закону Сарбейнса-Оксли.
  9. Анализ влияния. Анализ влияния выполняется для:
    • Оценки в рамках задач, которые обеспечивают соответствие изменений всем техническим и проектным требованиям
    • Оценки влияния изменений за пределами непосредственного проекта или контракта требований (изменения в элементах, использующихся в нескольких продуктах, может решить текущую проблему, но вызывать проблему в других приложениях)
    • Определение влияния, которое изменения будут иметь для рабочих продуктов, связанных рабочих продуктов, рабочих графиков и стоимости проекта
  10. Дополнительные интеграции. Различные производители программного обеспечения и партнеры Microsoft разработали интеграции с Visual Studio, которые предоставляют возможности не очень хорошо реализованные в Visual Studio Team Suite. В частности, они имеют встроенные возможности в следующих областях: выявление, спецификации, валидации и управления изменениями. Тут список некоторых из наиболее тесно интегрированных решений.
  11. Контрольные списки для разработки требований. Контрольные списки, которые помогают улучшить качество разрабатываемых требований.

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

  • Visual Studio TFS Branching Guide 2010 – руководство по ветвлению для Team Foundation Server 2010 разработанное сообществом VSTS Rangers. Это руководство основано на практике использования для Team Foundation Server различных моделей ветвления и слияния.
  • TFS 2008 Branching Guide 2.0 – руководство по ветвлению для Team Foundation Server 2008 разработанное сообществом VSTS Rangers. Это руководство основано на практике использования для Team Foundation Server различных моделей ветвления и слияния.

Posted in Стандарты и методологии, Управление требованиями, Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , | 2 комментария »

Руководство по управлению требованиями VS TFS 2010 – Введение в Управление требованиями с использованием Team Foundation Server

Posted by Shamrai Alexander на Июль 13, 2010

<<Содержание

Добро пожаловать в Руководство по управлению требованиями Team Foundation Server! На TechReady7 (внутренние технические встречи Microsoft) в июле 2008 года, практики проголосовали за проекты Visual Studio ALM Rangers, в которых, по их мнению, они больше всего нуждаются. Разработка требований была признана одним из двух самых важных. В этом документе будут рассмотрены люди, процессы и руководство по технологиям для Разработки требований с использованием Team Foundation Server.

Целью данного руководства является предоставление формализованного опыта Microsoft в виде рекомендованных процедур и процессов, конфигураций Visual Studio Team System и Team Foundation Server, а также развитие навыков по дисциплине Инженерия требований вашего жизненного цикла разработки ПО. Ввиду изменчивости и вопреки методик, используемых в индустрии, в этом руководстве эти задачи приведены тремя способами.

  • Общие Руководство по Разработке Требований – есть практики инженерии требований, которые реализуются, независимо от используемой методологии. Например, общее развитие представления бизнес уровня к функциональным возможностям, качеству обслуживания определено в любом случае, выполняет разработку организация по традиционному водопаду в соответствии со стандартами института инженеров по электротехнике и радиоэлектронике (IEEE) или выполняется экстремальное программирование с гибкими методами. Руководство приведено на концептуальном уровне, по возможности с использованием конкретных примеров на Visual Studio/Team Foundation Server.
  • Традиционная разработка – руководство будет приведено в основном в соответствии со стандартами IEEE по инженерии требований. В руководстве будут описаны конкретные указания по выявлению бизнес требований, спецификации, а также валидации спецификаций функциональных и технических требований.
  • Гибкая разработка – даже в рамках гибких методов есть несколько методологий, которые подчеркивают или выделяют различные практики в рамках этой темы. Руководство сосредоточено в основном на Scrum в качестве выбранной методологии и ссылается при необходимости на другие методологии.

Сценарий Разработки Требований

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

  • Бизнес-требования и их приемо-сдаточные испытания;
  • Функциональные требования и их тестовые сценарий;
  • Технические требования и их нефункциональные ограничения, качество обслуживания;
  • Разработка спецификации и их тесты компонентов архитектуры приложения;
  • Исходный код и его модульные тесты;
  • Документация пользователя.

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

Этот сценарий будет служить основой для описания на протяжении всего этого руководства, и мы будем на него ссылаться при описании альтернатив на основе Общей, Традиционной и Agile практик, используемых в Microsoft и в индустрии в целом. В каждом шаге сценариев, описанных ниже, указано в какой части руководство можно найти более детальную информацию о его поддержке в Visual Studio Team System и Team Foundation Server.

  1. Анализ Проблемы и Целей и определение Видения – бизнес-руководители спонсируют проект для решения некоторых бизнес-проблем и достижения бизнес-цели. Бизнес-аналитик будет выявлять их в качестве требований к продукту в виде набора возможностей или бизнес-требований. Мы можем хранить их в Team Foundation Server в виде рабочего элемента «Возможность».
    1. Первоначально выявление будет направлено на бизнес-руководителей. После того, как возможности продукта будут выявлены, специалисты по бизнес-областям будут дополнять этот набор функций. (Разделы Планирование управления требованиями и Выявление)
    2. Валидация на этом уровне будет проверять не только точность описанных функции, но и определять их влияние на решение проблем бизнеса и достижения бизнес-целей. (Раздел Валидация требований)
    3. Проблемы и цели, как правило, хранятся в виде документа бизнес-сценарий, где, в нормальной ИТ организации спонсируемой CIO, менеджер проекта собирает предварительную смету расходов на решение этой проблемы в проекте разработки и выполняет анализ экономических выгод. Этот вид деятельности находится вне области инженерии требований этого руководства. Анализа экономического обоснования и дальнейшего выявление спонсоров и экспертов в этой области приводит к бизнес-требованиям или возможностям продукта, которые будут определены в документах по проекту; обычно в документе Спецификация бизнес требований. (Разделы Планирование управления требованиями и Спецификация требований)
  2. Переход к функциям – выполняя анализ возможностей, аналитик получает функциональную контекстную модель или диаграмму вариантов использования для всех функциональных сценариев, реализующих функции. Мы можем хранить их в качестве рабочего элемента «Пользовательское описание функциональности» (MSF для Agile) или «Требование» с типом «Функциональное» (MSF для CMMI) и связать их с каждой возможностью, которую они реализуют.
    1. Планирование требований – описано в разделе Планирование управления требованиями
    2. Аналитик анализирует возможности и готовится к выявлению функциональных требований пользователей заинтересованных сторон и бизнес экспертов по конкретным областям. Их анализ поможет им выявить правильные функциональные требования, задокументировать и выполнить их валидацию на точность. (Разделы Выявление, Анализ и Валидация требований)
    3. Полученные функциональные требования и возможности связываются – описано в разделе Трассировка требований
  3. Переход к качеству обслуживания и нефункциональным требованиям – проводится дальнейший анализ возможностей и функциональных требований. Аналитик, работая с другими составляющими продукта (инфраструктура, операции, архитектура и администраторы баз данных, удобство использования, эксперты по безопасности, управление и обеспечение соблюдения требований и т.д.), определяет нефункциональные требования и качества обслуживания. Опять же, мы можем хранить их в качестве рабочих элементов в Team Foundation Server и привязать их к каждой возможности или функции, из которых они получены.
    1. Анализ функциональных требований для получения качества обслуживания и нефункциональные требований – разделы Выявление, Анализ и Спецификация требований
    2. Валидация свойств и нефункциональных требований на точность (Раздел Валидация требований)
    3. Полученные требования и функциональные требования связываются – описано в разделе Трассировка требований
  4. Планирование работ – менеджер проекта определяет с командой разработчиков задачи разработки (будь то гибкий проект или водопад или что-нибудь между ними, задачи определяются и по-прежнему с оценкой трудозатрат определенным образом) на функциональные и нефункциональные требования. Их можно хранить как рабочие элементы «Задача» и связывать с функциональными или нефункциональным требованиям, для которых они были запланированы.
    1. Планирование разработки и тестирования – описано в разделе Анализ
  5. Разработка Приложения и Тестов — команда разработчиков может разрабатывать код проекта приложения и модульные тесты (и тесты производительности) и связать их с исходным кодом. Во время регистрации (check-in) изменений, они связывают их с задачей, и мы можем даже заставить их это делать.
    1. Наборы изменений (Change Sets) связываются с задачами и требованиями – описано в разделе Трассировка требований
  6. Проверка качества приложения — Мы выполняем модульные тесты, и мы с помощью отчета, который связан со сборкой, можем продемонстрировать, какие наборы изменений вошли в эту сборку и какие рабочие элементы были связаны с этими зарегистрированными наборами изменений. И мы можем это сделать с помощью Team Foundation Server. Мы выполняем Ручные или Web функциональные тесты, а также можно использовать общие тесты, которые доступны из внешних систем функционального тестирования (например, Quick Test Professional) и опубликовать результаты. Отчеты будут демонстрировать, что рабочие элементы покрыты всеми видами тестов, с использованием Team Foundation Server Data warehouse.
    1. Выполнить тесты, публиковать результаты, сгенерировать отчеты покрытия – описано в разделе Трассировка требований
  7. Планирование тестирования – почему планирование тестирования включено в темы инжиниринга требования? Что ж, планирование тестирования гарантирует, что валидация имеет место. Влидация предусматривает проверку, которая позволяет убедиться, что команда проекта понимает цели требований и может достичь согласования с источником требования (бизнес-спонсором или заинтересованным лицом). Проверка предусматривает тесты, которые команда предоставила и согласовала для поставки. Планирование тестирования обеспечивает хранилище и трассируемость всех работ, связанных с управлением тестирования. Таким образом, после шага (1), но до шага (2), мы теперь имеем надежный механизм для планирования приемо-сдаточных тестов для функциональных требований. На самом деле, планирование тестирования на каждом уровне может быть выполнено с помощью Visual Studio 2010 Test and Lab Manager edition. Таким образом, мы можем создать несколько тестовых планов и тестовых наборов в Test and Lab Manager, которые обеспечивают разработку устойчивого отчета плана тестирования, который показывает, какие тесты не были запланированы, какие были запланированы, но не реализованы, какие были реализованы, но не выполняются, какие были выполнены, но провалены и какие были выполнены и прошли. Все эти данные есть, а у нас теперь есть возможность получить такой отчет и сортировать результаты по рабочим элементам, к которым они принадлежат.
    1. Планирование тестирования для системных требований — описано в разделах Трассировка требований, Валидация требований и Спецификация требований

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

Примечание: руководство для анализа требований этого раздела предполагает, что требование на уровне бизнеса реализованы с использованием рабочего элемента «Возможность» в Team Foundation Server. Авторы не настаивают на использовании рабочего элемента «Возможность» для этой цели и признают, что это добавляет элемент формальности, который можно легко избежать для небольших и гибких команд.

Отступление

В 20-тилетней карьере лидера в области разработки, практик, внедрения передового опыта, обучения, коучинга по управлению жизненным циклом разработки для своих клиентов, мы установили, что Инженерия требования, как правило, наиболее сложная дисциплина в рамках программного обеспечения и сообществ разработки систем. Таким образом, это руководство было разработано с подходом, который напрашивается на критику и изменение. Команда из более 20 практиков из Microsoft Consulting Services, Product Management и программы MVP собрались вместе для обсуждения и определения предложения руководства, которое учитывает передовые практики индустрии и лучшие практики Microsoft в дисциплине разработки требований.

Visual Studio ALM Rangers

Эта руководство было разработано в проекте Visual Studio ALM Ranger. Visual Studio ALM Rangers особая группа в составе представителей Visual Studio Product group и Microsoft Services. Их миссия заключается в предоставлении решений для отсутствующих возможностей или руководств.

Целевая аудитория этого руководства это Microsoft пользователи Team Foundation Server «уровня 200-300». Целевая группа рассматривается как промежуточная к опытным пользователям Team Foundation Server, глубоко понимающим возможности продукта в реальном мире. Части этого руководства могут быть полезными для новичков и экспертов Team Foundation Server, но пользователи этих уровней не фокусируются во внимание этого руководства.

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

Мы надеемся, что данное руководство охватывает более 80% нужд сегмента инженерии требований. В дополнение к этому руководство вы найдете отдельные методологические сценарии, Q&A, учебные пособия и обновление трассировки и документацию по стратегии. Мы призываем участников нашего сообщества предоставлять идеи для новых сценариев, которые мы будем добавлять в пакеты. Эти новые пакеты будут доступны на CodePlex или MSDN и будут обновлены на основе отзывов пользователей.

Словарь

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

Термин Определение
Анализ требований

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

Активный дизайн (Participatory Design)

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

Аппаратное требование

Требование, которым должно соответствовать аппаратное обеспечение.

Артефакт (рабочий продукт)

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

Атрибуты

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

Базовая линия

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

Базовая линия требований

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

Бизнес-правила

Правила и ограничения, регулирующие отдельные бизнес-процессы и работы.

Валидация требований

Валидация фокусирует внимание на определении, работает ли продукт как ожидалось. Валидация требований предусматривает проверку связи между тестами (и результаты тестов) и тестируемой системой. Удовлетворяет ли построенная система требованиям?

Вариант использования

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

Взаимодействие

Атрибут: возможность взаимодействия одной программной системы с другой.

Гибкость

Атрибут: возможность изменения миссии, функции, данных для удовлетворения других требований.

Группа контроля за изменениями

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

Группа пользователей

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

Двунаправленная трассировка

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

Дефектное требование

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

Диаграммы взаимодействия

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

Доступность

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

Жизненный цикл разработки программного обеспечения

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

Заинтересованное лицо

Лицо, которое будет затронуто продуктом и имеет прямое или косвенное влияние на требования к продукту.

Интервью

Сессия один на один с пользователем на его рабочем месте.

Контекстно-независимые вопросы

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

Коробочное решение

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

Корректность

Атрибут: соответствие стандартам и техническим условиям.

Круг пользователей

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

Мета-вопрос

Вопрос о вопросах. Обычно используется в интервью, чтобы определить или собеседник понимает цель собеседования. Пример мета-вопроса: Мои вопросы актуальны? Понятны ли Вам мои вопросы? Ваши ответы официальны?

Моделирование требований

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

Надежность

Атрибут: работа без сбоев в течение определенного периода времени.

Нетехнические ограничения

Требования, связанные с продуктом, поставкой и выпуском (например, стоимость и сроки).

Однозначное требование

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

Повторное использование

Атрибут: возможность переработки для использования в другом приложении.

Покупатель

Тот, кто приобретает продукт для пользователей.

Пользователь

Тот, кто будет использовать продукт.

Пользовательские требования

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

Портативность

Атрибут: возможность перемещения для использования в другой среде.

Представитель пользователей

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

Приемочные тесты

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

Приоритетность требований

Метод ранжирования важности требований на более и менее важные.

Проверяемое требование

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

Прототип

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

Разработка программного продукта

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

Разработка требований

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

Раскадровка

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

Сбор требований

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

Сессия совместного дизайна приложения (Joint Application Design (JAD))

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

Сценарий

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

Системные требования

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

Спецификация требований

Документация, определяющая, как продукт будет построен, и описывающая ее внешнее поведение.

Спонсор

Лицо, которое выполняет финансирование этого проекта.

Тестируемость

Атрибут: возможность проверить (протестировать) указанную операцию и производительность.

Тестируемое требование

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

Техника Фокус-группы

Техникой сбора требований, которая следует сценарию, и организована из набора вопросов для интервью с группой людей. Группа состоит из 3 — 10 пользователей, экспертов или клиентов, нескольких разработчиков или маркетологов.

Технические ограничения

Характеристики среды продукта, которые влияют на выполнение и/или дизайн продукта.

Техническая рецензия

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

Техническое требование

Свойства продукта для условий, в которых разрабатывается продукт.

Трассировка требования

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

Трассируемое требование

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

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

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

Требование к системным интерфейсам

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

Удобство использования

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

Управление изменениями

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

Управление требованиями

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

Функциональное требование

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

Целостность

Атрибут: (использование) безотказная работа при несанкционированном доступе; (данные) сохранение содержания и порядка данных и артефактов.

Эффективность

Атрибутов: относительное использование ресурсов (памяти, времени, пропускной способности сети).

Эксплуатационная надежность

Атрибут: простота обнаружения и исправления неисправности в период времени (во время использования).

Unified Modeling Language (UML)

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

<<Содержание

Posted in Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , | Leave a Comment »

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