Только спецификация требований к ПО

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

Преимущества способа с применением вариантов использования

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

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

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

· варианты использования описывают один из основных бизнес-процессов, активизируемых системой;

· многие пользователи часто обращаются к ним;

· их запросил привилегированный класс пользователей;

· они предоставляют возможности, необходимые для соответствия требованиям;

· функции других систем зависят от их наличия.

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

Каких ловушек следует опасаться при способе с применением вариантов использования

Как и любой другой способ разработки ПО, применение вариантов использования чревато возникновением множества проблем (Kulak и Guiney, 2000; Lilly, 2000).

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

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

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

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

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

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

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