Добавлен: 15.11.2018
Просмотров: 2451
Скачиваний: 15
Здесь требуется другой подход. В основном проблема решается за счет итеративности процесса разработки, но в дополнение к нему иногда требуется постоянное личное общение — ежедневное обсуждение между всеми разработчиками при участии специалиста по предметной области, который уполномочен принимать решения о требованиях к системе. Нужен некто, к кому программисты могут подойти и за несколько секунд снять возникшие у них вопросы. Например, в рамках подхода ХР существует отличный принцип: пользователь должен постоянно находиться среди участников проекта, в том же помещении.
Описание прецедентов, относящихся к интерфейсу пользователя, в свободном стиле
Исследование целей, а не обязанностей и процедур позволяет сосредоточить внимание на основных требованиях. Например, на одном из семинаров кассир может сказать, что одной из его целей является регистрация в системе. При этом он может иметь в виду элементы интерфейса пользователя, соответствующие диалоговые окна, ввод идентификатора и пароля. Однако все это — механизмы достижения цели, а не сама цель. Изучая иерархию целей (отвечая на вопрос "какова цель этой задачи?"), системный аналитик приходит к формулировке, независимой от механизма реализации: "идентифицировать себя и выполнить аутентификацию", или на более высоком уровне — "предотвратить утечку информации".
Такой процесс исследования позволяет получить новые и более эффективные решения. Например, в настоящее время достаточно распространены и недорого стоят клавиатура и мышь с устройствами считывания биометрической информации, в частности отпечатков пальцев. Если целью является идентификация и аутентификация, то почему бы для ее достижения не использовать эффективное и быстрое средство считывания биометрических данных с клавиатуры? Однако отвечая на этот вопрос, следует принимать во внимание удобство использования. В данном случае придется установить профили типичных пользователей. А если их пальцы чем-то испачканы? А если они травмированы?
Базовый стиль описания
Эта идея была сформулирована в различных рекомендациях типа "не уделяйте внимания вопросам интерфейса пользователя, сосредоточьте внимание на содержательной стороне вопроса"
Если описание не содержит подробной информации о реализации пользовательского интерфейса, а основное внимание в нем сосредоточено на содержательных моментах, то такой стиль описания Константин называет базовым (essential).a
Базовый стиль описания предполагает изложение на уровне намерений пользователя и обязанностей системы, а не на уровне их конкретных действий. При таком стиле описания не нужно углубляться в детали технологии и механизма реализации, особенно при рассмотрении вопросов, связанных с интерфейсом пользователя.
Совет. Описывайте прецеденты в базовом стиле. Не уделяйте внимания интерфейсу пользователя, а сосредоточьтесь на содержательной стороне вопроса.
Прецедент Оформление продажи был выдержан в базовом стиле описания.
Заметим, что понятия цель и намерение являются синонимами. Этим подтверждается взаимосвязь между базовым стилем описания и ориентацией на цели (задачи). Действительно, многие намерения исполнителей можно трактовать как вспомогательные цели.
Исполнители
Исполнитель (actor) — это сущность, обладающая поведением. К числу исполнителей может относиться и сама рассматриваемая система, если она вызывает службы других систем. В прецеденте могут участвовать основные и вспомогательные (второстепенные) исполнители. Исполнителями являются не только люди, но и организации, машины и программы. Существует три типа внешних по отношению к разрабатываемой системе исполнителей.
• Основной исполнитель (primary actor) — его задачи выполняются с использованием системы. Примером основного исполнителя является кассир.
- Зачем его идентифицировать? Чтобы определить цели пользователя, на основе которых формулируются прецеденты.
• Вспомогательный исполнитель (supporting actor) — обслуживает систему (например, предоставляет информацию). Примером вспомогательного исполнителя является служба авторизации платежей.
- Зачем его идентифицировать? Чтобы определить внешние интерфейсы и протоколы.
• Закулисный исполнитель (offstage actor) — заинтересован в реализации прецедента, но не является основным или вспомогательным исполнителем. Примером закулисного исполнителя является налоговая служба.
- Зачем его идентифицировать? Чтобы удостовериться, что все интересы определены и удовлетворены. Интересы закулисных исполнителей обычно не очевидны и их легко упустить из виду, если не идентифицировать
Диаграммы прецедентов
На языке UML существует система обозначений для диаграммы прецедентов, иллюстрирующей имена прецедентов, исполнителей и взаимосвязи между ними (рис. 3).
Рис. 3. Фрагмент диаграммы прецедентов
Диаграммы прецедентов и их взаимосвязей имеют второстепенное значение при работе над прецедентами. Прецеденты — это текстовые документы. Работать над прецедентами — значит составлять текстовые описания.
Обычно новички в области моделирования прецедентов начинают с составления диаграмм прецедентов и их взаимоотношений, а не с составления текстовых описаний. Однако специалисты по написанию прецедентов мирового класса, к числу которых относятся Андерсон (Andersen), Фовлер (Fowler), Кокбурн (Cockburn) и др., основное внимание уделяют составлению текстовых описаний, а не диаграмм, В таком ракурсе диаграмма лишь иллюстрирует способы использования системы внешними исполнителями.
Совет. Стройте простые диаграммы прецедентов в соответствии со списком исполнителей и их задач.
Система обозначений для диаграммы прецедентов
Рис. 4. Предлагаемые обозначения
Рис. 5. Другие обозначения исполнителей
Требования и списки низкоуровневых свойств
Основным мотивом описания прецедентов является определение требований в контексте задач (целей) и сценариев использования системы. Это очень хорошо, поскольку позволяет углубить понимание системы. Однако прецеденты — это не единственные артефакты формулировки требований. Некоторые нефункциональные требования, правила и другие элементы лучше описать в дополнительной спецификации, рассмотрению которой будет посвящена следующая глава.
Основная идея — заменить детальные списки низкоуровневых свойств (которые обычно составлялись при использовании традиционного метода формулировки требований) прецедентами (за некоторыми исключениями). Эти списки были сгруппированы по функциональному назначению и выглядели примерно следующим образом.
|
Идентификатор |
Свойство |
|
Свойство 1.9 |
Система будет позволять вводить новые идентификаторы |
|
Свойство 2.4 |
Система будет регистрировать платежи по кредитной карточке в бухгалтерской системе |
Такие списки тоже могут оказаться полезными, однако один подобный список занимает не полстраницы, а десятки или сотни страниц, Это вызывает некоторые проблемы, решить которые позволяют прецеденты. К числу проблем относятся следующие,
-
Длинные, подробные списки функций не отражают требований в общем контексте. Различные функции и свойства организованы в обычный список разрозненных элементов. А при описании прецедентов требования рассматриваются в контексте задач и целей системы.
-
Если используются и описания прецедентов и списки функций, то происходит дублирование информации. На это затрачивается больше труда, требуется больше усилий для их осмысления и согласования.
Совет. Старайтесь заменить подробные списки низкоуровневых свойств описанием прецедентов.
Списки высокоуровневых свойств системы вполне допустимы
Достаточно часто функциональные свойства системы описываются в кратких списках свойств высокого уровня в рамках документа "Видение". Это вполне оправдано. В отличие от списка низкоуровневых свойств, перечисленных на 100 страницах, список основных свойств системы должен включать не более нескольких десятков элементов. В нем перечислены лишь функциональные свойства системы, не упомянутые при описании прецедентов.
Список свойств системы
• Регистрация продаж.
• Авторизация платежей (кредитных, дебитных, чековых).
• Системное администрирование для управления пользователями, безопасностью, таблицами кодов и констант и т.п.
• Автоматическая обработка информации о продажах в фоновом режиме в случае отказа внешних компонентов.
• Взаимодействие в реальном времени с внешними системами (на основе промышленных стандартов), включая систему складского учета, вычисления налоговых отчислений, бухгалтерскую систему, систему управления человеческими ресурсами и службы авторизации платежей.
• Определение и выполнение настраиваемых бизнес-правил в фиксированных точках сценария.
• ...
Когда нужен подробный список свойств?
Иногда прецедентов действительно недостаточно. Для некоторых систем нужно разработать детальный список свойств. Например, серверы приложений, системы управления базами данных и другие базовые системы нужно рассматривать в терминах свойств ("Необходима поддержка следующей версии XML"). Прецеденты не годятся для разработки таких приложений.
Прецеденты в рамках унифицированного процесса
Прецеденты играют жизненно важную роль при реализации унифицированного процесса, поскольку вся разработка в рамках этого подхода осуществляется под управлением прецедентов (use-case driven development). Это означает следующее.
-
Требования в основном формулируются при описании прецедентов (в модели прецедентов). Остальные требования (если таковые существуют) являются либо техническими (например, список функций), либо второстепенными.
-
Прецеденты — важный этап итеративного планирования. На каждой итерации реализуются некоторые сценарии или целые прецеденты. Поэтому описания прецедентов вносят существенный вклад в оценивание результата.
-
Разработка приложения состоит в реализации прецедентов. То есть группа разработчиков продумывает способы взаимодействия объектов или архитектуру подсистем для реализации прецедентов.
В рамках UP выделяют два вида прецедентов: системные и бизнес-прецеденты. Системные прецеденты (system use-case) — это такие, которые рассматривались в этой главе, например Оформление продажи. Они создаются в рамках дисциплины "Требования" и являются частью модели прецедентов.
Бизнес-прецеденты (business use-case) используются гораздо реже. При необходимости они создаются в рамках дисциплины "Бизнес-моделирование" как часть крупномасштабного бизнес-процесса или для облегчения понимания контекста новой системы. Они описывают последовательность действий в целом, выполняемых бизнес-исполнителем (business actor) (исполнителем в бизнес-среде, например, потребителем). В частности, для ресторана можно выделить бизнес-прецедент Приготовление блюда.
Прецеденты и спецификация требований в рамках итеративного процесса
В этом разделе мы вернемся к основной идее UP и итеративной разработки. Рассмотрим временные рамки, выделяемые на формулировку требований на каждой итерации. В табл. 2 представлен пример (не претендующий на рекомендацию) определения требований в процессе реализации стратегии UP.
Обратите внимание, что группа технической разработки приступает к созданию ядра системы в тот момент, когда детализированы лишь 10% требований, далее следует намеренная задержка, и формулировка требований откладывается до конца первой итерации стадии развития.
В этом состоит ключевое отличие от однопроходного процесса — промышленная разработка ядра системы начинается достаточно быстро, задолго до полного завершения формулировки требований.
Обратите внимание, что в конце первой итерации стадии развития проводится второй семинар по формулировке требований, по окончании которого сШ7о прецедентов описаны подробно. При таком планировании можно учесть обратную связь и оценки реализованной части системы. Обратная связь поступает от пользователей, специалистов по тестированию и позволяет "познать непознанное". То есть в процессе разработки системы очень быстро возникают вопросы, требующие немедленного решения.
Прецеденты начальной фазы
На начальной стадии не все прецеденты описываются детально. В этот период для описания прецедентов целесообразно организовать двухдневный семинар. В первой половине первого дня можно определить задачи и круг заинтересованных лиц, а также обсудить, какие задачи относятся к проекту, а какие выходят за его рамки. С помощью компьютерного проектора можно составить и демонстрировать таблицу исполнителей и их задач. Можно приступить к построению диаграммы прецедентов. В течение нескольких часов вполне реально определить порядка 20 задач пользователей (и соответствующих им прецедентов), в том числе прецеденты Оформление продажи, Возврат товара и т.д. За это время большинство интересных, сложных прецедентов с высоким уровнем риска должны быть описаны в сжатом формате. На описание каждого такого прецедента понадобится около 2 минут. Разработчики могут приступить к составлению высокоуровневой схемы функциональности системы.
После этого 10-20% прецедентов, представляющих сложные функции или высокую степень риска, нужно описать подробно. При этом разработчики лучше оценят сложность проекта, его рамки, выявят проблемы, возникающие в процессе разработки. Самыми важными прецедентами являются, пожалуй, Оформление продажи и Возврат товара.
Для описания прецедентов нужно использовать средства управления требованиями со встроенным текстовым процессором, а результаты работы желательно демонстрировать участникам семинара с помощью проектора. Для этих прецедентов нужно составить список заинтересованных лиц и их интересов. Это поможет глубже понять неочевидные функциональные и основные нефункциональные требования, в частности к надежности и производительности системы.
Задачей такого анализа является не исчерпывающее описание прецедентов, а более глубокое понимание проблемы.
Спонсоры проекта должны решить, стоит ли вкладывать деньги в дальнейшие исследования (на стадии развития). На начальной стадии не ставится задача напрямую исследовать целесообразность капиталовложений. На этом этапе нvжно определить масштаб проекта, основные риски, реалистичность этого проекта — т.е. получить исчерпывающую информацию для принятия последующих решений о продолжении или прекращении проекта.