n1
.pdfМоделирование бизнес-процессов и спецификация требований 261
Существуют два типа интервью: неструктурированное и структурированное. Неструктурированные интервью проводят с одной общей целью, которая явно не высказывается, и с по мощью нескольких общих вопросов. Лицо, проводящее собесе дование, рассчитывает на то, что опрашиваемое лицо должно са мо определять рамки и направление интервью. В таких интервью часто теряется нить рассуждений, и по этой причине они редко используются при проектировании систем.
В структурированных интервью лицо, проводящее собеседо вание, заранее подготавливает конкретный ряд вопросов к опра шиваемому лицу В зависимости от ответов в процессе собеседо вания могут быть заданы дополнительные вопросы для уточне ния или разъяснения некоторых тем. Вопросы без подразумевае мых ответов позволяют опрашиваемому лицу выбрать ответ, на иболее подходящий с его точки зрения. Вопросы, допускающие единственный ответ, Офаничивают выбор возможного ответа или требуют коротких, прямых ответов.
Анкетирование позволяет с помощью анкет получать сведения от большого количества людей, контролируя правильность их от ветов. При работе с большой аудиторией этот метод наиболее эф фективен. Премущества метода анкетирования заключаются в следующем:
•люди могут заполнять и возвращать анкеты в удобное для них время;
•люди склонны сообщать в ответах действительные факты, если анкетирование анонимное;
•это относительно недорогой способ сбора данных с участи ем большого количества людей.
Недостатки метода анкетирования:
•не все могут согласиться ответить на вопросы, анкеты могут возвращаться незаполненными;
•нет возможности пояснить или переформулировать непра вильно понятые вопросы, наблюдать и анализировать реак цию респондента на отдельные вопросы;
•подготовка анкет может потребовать много времени. Мозговой штурм особенно полезен в ситуациях, когда обсуж
даются новые, нестандартные решения незнакомой проблемы. Большинство новаторских идей очень часто бывают результатом комбинации нескольких, на первый взгляд, не связанных друг с другом идей. Мозговой штурм включает в себя генерацию идей и
262 |
Глава 3 |
расстановку приоритетов. Процесс генерации идей обычно под чиняется правилам, соблюдение которых преследует одну цель — выработку как можно большего числа идей. Критика и споры в этот период не поощряются; существующие пределы и ограниче ния снимаются, можно изменять и комбинировать идеи.
Основная идея создания прототипа состоит в быстрой пост ройке модели системы, которая, как предполагается, нужна пользователю. Обычно в прототипах многие детали опускаются, в том числе процедуры контроля входных данных, обработки ошибок, резервного копирования и восстановления данных. Не учитываются также производительность и масштабируемость. Создание прототипа никак не противоречит и не препятствует применению других методов получения требований от пользова теля. Однако иногда только с помощью прототипа удается заста вить клиента начать обсуждение требований, которые при другом подходе кажутся слишком абстрактными. Кроме того, работа с прототипом часто помогает получить требования, которые в про тивном случае так и остались бы неизвестными. Прототип хорош еще и тем, что он является неким осязаемым доказательством (или иллюзией) прогресса в разработке системы. А в некоторых случаях он может даже поддерживать какие-то офаниченные ра бочие возможности системы. К сожалению, как отмечалось в гла ве 1, реальный опыт работы с прототипами свидетельствует, что их создание обычно препятствует любому официальному доку ментированию требований, следовательно, требования формули руются только в виде кода. Детали работы системы, игнорируе мые прототипом (обработка ошибок, резервное копирование и др.), могут так и не появиться в виде требований.
Выявленные в результате применения перечисленных мето дов требования к ПО оформляются в виде ряда документов и мо делей. К основным документам, регламентируемым технологией Rational Unified Process, относятся:
•Концепция - определяет глобальные цели проекта и основ ные особенности разрабатываемой системы. Существенной частью концепции является постановка задачи разработки, определяющая требования к выполняемым системой функ циям.
•Словарь предметной области (глоссарий) — определяет об щую терминологию для всех моделей и описаний требова ний к системе. Глоссарий предназначен для описания тер-
Моделирование бизнес-процессов и спецификация требований 263
минологии предметной области и может быть использован как словарь данных системы.
• Дополнительные спецификации (технические требования)
— содержит описание нефункциональных требований к сис теме, таких, как надежность, удобство использования, про изводительность, сопровождаемость и др.
Примеры документов приведены в подразд. 3.4.2. Функциональные требования к системе моделируются и до
кументируются с помощью вариантов использования (use case), которые в контексте процесса управления требованиями тракту ются следующим образом:
•вариант использования фиксирует соглашение между участ никами проекта относительно поведения системы;
•вариант использования описывает поведение системы при различных условиях, когда система отвечает на запрос одно го из участников, называемого основным действующим ли цом;
•основное действующее лицо инициирует взаимодействие с системой, чтобы добиться некоторой цели. Система отвеча ет, соблюдая интересы всех участников.
Варианты использования — это вид документации, применя емый, когда требуется сконцентрировать усилия на обсуждении принципиальных требований к разрабатываемой системе, а не на подробном их описании. Стиль их написания зависит от масшта ба, количества участников и критичности проекта. Существуют четыре уровня точности^ при описании вариантов использования (расположенные по степени повышения точности):
•Действующие лица и цели (перечисляются действующие лица и все их цели, которые будет обеспечивать система).
•Краткое изложение варианта использования (в один абзац) или основной поток событий (без анализа возможных оши бок).
•Условия отказа (анализ мест возникновения возможных ошибок в основном потоке событий).
•Обработка отказа (написание альтернативных потоков со бытий).
^ Коберн А. Современные методы описания функциональных требова ний к системам: Пер. с англ. -- М.: ЛОРИ, 2002.
264 |
Глава 3 |
Введение перечисленных уровней преследует своей целью фамотное планирование и экономию времени разработки. В итерационном цикле создания системы не следует пытаться за один прием подробно описать все требования, их нужно посте пенно уточнять, повышая уровень точности. Выбор первоочеред ных вариантов использования для уточнения определяется их приоритетами (см. подразд. 1.5).
Методика моделирования вариантов использования в техно логии Rational Unified Process предусматривает специальное сог лашение, связанное с группировкой структурных элементов и диаграмм модели. Это соглашение включает следующие правила:
•Все действующие лица, варианты использования и диафаммы вариантов использования помещаются в пакет с именем Use Case Model.
•Если моделируется сложная многофункциональная систе ма, то совокупность всех действующих лиц и вариантов ис пользования может разделяться на пакеты. В качестве прин ципов разделения могут использоваться:
структуризации модели в соответствии с типами пользовате лей (действующих лиц);
функциональная декомпозиция; разделение модели на пакеты между фуппами разработчиков
(в качестве объектов управления конфигурацией).
Все рекомендации по написанию качественных вариантов ис пользования, включая перечисленные в подразд. 2.5.1, можно из ложить в виде набора образцов, которые перечислены в табл. 3.3.
|
|
Таблица 3.3 |
|
Образцы написания вариантов использования |
|||
Наименование |
Проблема |
Предлагаемое решение |
|
образца |
|||
|
|
||
|
Формирование команды разработчиков |
||
Небольшая |
Участие слишком многих |
Ограничьте число разра |
|
команда разработ |
людей в написании вари |
ботчиков, отрабатываю |
|
чиков |
анта использования не |
щих детали варианта ис |
|
|
эффективно; компромисс |
пользования, двумя или |
|
|
между многими различ |
тремя людьми. Для под |
|
|
ными точками зрения мо |
ключения дополнитель |
|
|
жет привести к неудов- |
ных участников исполь- |
Моделирование бизнес-процессов и спецификация требований 2 6 5
Продолжение
Наименование
образца
Состав сторонних участников
Сбалансированная
команда
Проблема |
Предлагаемое решение |
|
летворительным резуль |
зуйте образец Двухуров |
|
татам при создании сис- |
невое рецензирование |
|
1 темы |
|
|
Невозможно удовлетво |
Активно привлекайте за |
|
рить потребности всех за |
казчиков |
и заинтересо |
интересованных лиц, не |
ванных лиц в вашей орга |
|
обмениваясь информаци |
низации к разработке ва |
|
ей с ними |
риантов использования |
|
Команда из близких по |
Формируйте команду из |
|
роду деятельности, оди |
людей с различными спе |
|
наково мыслящих людей |
циализациями, представ |
|
может создать небольшой |
ляющими |
интересы раз |
набор офаниченных ва |
личных |
заинтересован |
риантов использования, |
ных лиц. Команда долж |
|
не удовлетворяющий об |
на включать как разра |
|
щим потребностям |
ботчиков, так и пользова |
|
|
телей |
|
|
Организация процесса разработки |
|
|
|
||
Глубина после об |
Невозможно продвигать |
Разрабатывайте сначала |
||||
щего представле |
ся вперед и создавать на |
общее |
представление ва |
|||
ния |
бор согласованных вари |
риантов |
использования, |
|||
|
антов использования, ес |
затем |
постепенно добав |
|||
|
ли тратить впустую время |
ляйте |
детали, |
работая с |
||
|
на последовательное на |
группой |
взаимосвязан |
|||
|
писание подробных вари |
ных вариантов использо |
||||
|
антов использования |
вания |
|
|
1 |
|
Итерационная |
| Разработка вариантов ис |
Разрабатывайте варианты |
||||
разработка |
пользования за один про |
использования |
итераци |
|||
|
ход затруднительна, ус |
онно, повышая на каждой |
||||
|
ложняет внесение допол |
итерации |
их точность и |
|||
|
нительной информации и |
корректность |
|
|||
|
затрудняет |
выявление |
|
|
|
|
|
факторов риска |
|
|
|
|
|
Множество форм |
Различные |
проекты тре |
Выбирайте формат вари |
|||
|
буют различную степень |
антов использования, ос |
||||
|
формальности и различ- |
новываясь на |
проектных |
266
Наименование
образца
Двухуровневое ре цензирование
Своевременное
завершение
|
|
|
Глава 3 |
|
|
|
Продолжение |
|
Проблема |
Предлагаемое решение |
|
ные шаблоны. Использо |
рисках и предпочтениях |
||
вать один и тот же шаб |
участников |
|
|
лон вариантов использо- |
|
|
|
1 вания непродуктивно |
|
|
|
Многие |
заинтересован |
Используйте два вида ре |
|
ные лица могут пожелать |
цензирования: первое, |
||
принять участие в рецен |
проводимое |
небольшой |
|
зировании вариантов ис |
группой |
внутренних |
|
пользования. Это слиш участников, может вы |
|||
ком долгое и дорогостоя |
полняться многократно; |
||
щее занятие |
второе, проводимое пол |
||
|
|
ной группой, выполняет |
|
|
|
ся, как правило, один раз | |
|
Разработка модели вари |
Прекращайте |
разработку |
|
антов |
использования |
вариантов |
использова |
сверх потребностей заин |
ния, как только они дос |
||
тересованных лиц и раз |
тигают необходимой пол |
||
работчиков приводит к ноты и удовлетворяют |
|||
напрасным тратам ресур |
потребности |
участников |
|
сов и затягивает проект |
проекта |
| |
Свобода |
Чрезмерное внимание к |
Небольшие |
различия |
в |
|||
творчества |
стилю написания вариан |
стиле написания вариан |
|||||
|
тов использования тор |
тов использования |
несу |
||||
|
мозит работу |
|
щественны. Если вариант |
||||
|
|
|
|
использования достиг не |
|||
|
|
|
|
обходимой полноты, его |
|||
|
|
|
|
автор имеет право на сти |
|||
|
|
|
|
листические отступления |
|||
Организация набора вариантов использования |
|
|
|
||||
Общепринятая |
Недостаточно |
четкое |
Необходимо |
подготовить |
|||
четкая концепция |
представление о системе |
и утвердить |
концепцию |
||||
|
может привести к неуве |
системы, в которой четко |
|||||
|
ренности |
и противопо |
определены |
ее цели |
и |
||
|
ложным |
мнениям |
среди |
роль в деятельности орга |
|||
|
заинтересованных |
лиц и |
низации. Распространите |
||||
|
быстро парализовать про |
концепцию |
среди |
всех |
|||
|
ект |
|
|
участников проекта |
|
|
Моделирование бизнес-процессов и спецификация требований |
2 6 7 |
||||||||||||
|
|
|
|
|
|
|
|
|
|
|
Продолжение |
||
Наименование |
|
|
Проблема |
|
Предлагаемое решение |
||||||||
образца |
|
|
|
||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Видимые границы |
Если |
вы |
не |
определили |
Установите четкую и ви |
||||||||
|
границы |
системы, |
ее |
димую |
границу |
между |
|||||||
|
масштаб будет расти не |
системой и внешней сре |
|||||||||||
|
контролируемым образом |
дой, перечислив людей и |
|||||||||||
|
|
|
|
|
|
|
|
оборудование, |
взаимо |
||||
|
|
|
|
|
|
|
|
действующих с |
данной |
||||
|
|
|
|
|
|
|
|
системой |
|
|
|
||
Ясный состав |
Если |
|
выявлять |
только |
Идентифицируйте |
|
|||||||
действующих лиц |
пользователей системы, |
действующих лиц, с кото |
|||||||||||
|
игнорируя роли, которые |
рыми должна взаимодей |
|||||||||||
|
они |
ифают |
по |
отноше |
ствовать система, и роли, |
||||||||
|
нию |
к |
системе, |
можно |
которые |
они играют по |
|||||||
|
упустить существенную отношению к системе. |
||||||||||||
|
часть поведения системы |
Четко |
опишите |
каждую |
|||||||||
|
или |
ввести |
избыточное |
роль |
|
|
|
|
|
||||
|
поведение |
|
|
|
|
|
|
|
|
|
|
||
Транзакции,зна |
Система |
несовершенна, |
Идентифицируйте |
важ |
|||||||||
чимые для пользо |
если она не может пре |
ные, |
значимые |
услуги, |
|||||||||
вателей |
доставить |
пользователям |
которые система предос |
||||||||||
|
необходимые услуги и не |
тавляет действующим ли |
|||||||||||
|
выполняет цели и задачи, |
цам |
для |
удовлетворения |
|||||||||
|
определяемые ее концеп |
их потребностей |
|
|
|||||||||
|
цией |
|
|
|
|
|
|
|
|
|
|
|
|
Разворачива |
Количество шагов в опи |
Создайте |
иерархическую |
||||||||||
ющееся представ |
сании поведения системы |
организацию набора ва |
|||||||||||
ление |
превышает возможности |
риантов |
использования, |
||||||||||
|
охвата |
и |
интересы |
раз |
которую |
можно |
развер |
||||||
|
личных |
типов читателей |
нуть для большей детали |
||||||||||
|
вариантов использования |
зации, или свернуть, что |
|||||||||||
|
|
|
|
|
|
|
|
бы скрыть детали и пока |
|||||
|
|
|
|
|
|
|
|
зать контекст |
|
|
|||
|
Отдельный вариант использования |
|
|
|
|
||||||||
Законченная |
Неправильно |
заданные |
Каждый вариант исполь |
||||||||||
единственная цель |
цели не дают разработчи |
зования должен иметь за |
|||||||||||
|
кам четко определить, где |
конченную и четко опре |
|||||||||||
|
заканчивается один вари- |
деленную |
цель, |
которая |
268 |
Глава 3 |
Продолжение
Наименование
образца
Имя в виде гла гольной фразы
Сценарий и фраг менты
Исчерпывающие
альтернативы
Перефузка ин формацией
Точность и читае мость
Проблема |
|
Предлагаемое решение |
||||||
ант использования |
и на |
может находиться на лю |
||||||
чинается другой |
|
бом уровне образца Раз |
||||||
|
|
|
ворачивающееся |
предс |
||||
|
|
|
тавление |
|
|
|
|
|
Бессмысленные, |
слиш |
Именуйте |
каждый |
вари |
||||
ком общие имена вариан |
ант использования актив |
|||||||
тов использования не да |
ной глагольной |
фразой, |
||||||
ют читателям правильно |
отражающей цель основ |
|||||||
го представления, на них |
ного действующего лица |
|||||||
сложно ссылаться |
|
|
|
|
|
|
|
|
Читатели |
должны |
иметь |
Основной сценарий дол |
|||||
возможность легкого сле |
жен |
быть |
предельно |
|||||
дования по интересующе |
простым, без анализа воз |
|||||||
му их сценарию, в про |
можных ошибочных си |
|||||||
тивном случае они могут |
туаций. Фрагменты |
сце |
||||||
утратить интерес или по |
нария, |
отражающие аль |
||||||
терять важную информа |
тернативы, должны |
рас |
||||||
цию |
|
|
полагаться под ним |
|
||||
Вариант |
использования |
Описывайте все альтерна |
||||||
может иметь много аль |
тивы и ошибочные ситуа |
|||||||
тернатив. Отсутствие не |
ции, которые могут иметь |
|||||||
которых из них означает, |
место в варианте исполь |
|||||||
что разработчики непра |
зования |
|
|
|
|
|||
вильно понимают поведе |
|
|
|
|
|
|
||
ние системы, и система |
|
|
|
|
|
|
||
может получиться |
несо |
|
|
|
|
|
|
|
вершенной |
|
|
|
|
|
|
|
|
Включение нефункцио |
Включите |
дополнитель |
||||||
нальных требований в ва |
ные позиции |
в |
шаблон |
|||||
риант использования мо |
варианта |
использования |
||||||
жет быстро привести его в |
за пределами текста сце |
|||||||
неопределенное и беспо |
нария, |
чтобы |
отразить |
|||||
рядочное состояние |
|
полезную |
дополнитель |
|||||
|
|
|
ную информацию |
|
|
|||
Варианты |
использова |
Сделайте |
вариант |
ис |
ния, слишком сложные пользования достаточно для нетехнических специ читаемым, чтобы заинте алистов или слишком нересованные лица могли в
Моделирование бизнес-процессов и спецификация требований 2 6 9
1 Наименование образца
Обнаруживаемые
условия
|
|
|
Продолжение |
Проблема |
Предлагаемое решение |
||
точные для разработчи |
нем |
разобраться и оце |
|
ков, несовершенны и мо |
нить |
его, и |
достаточно |
гут привести к созданию |
точным, чтобы разработ |
||
неадекватной системы |
чики |
понимали, что им |
|
|
делать |
|
|
Сценарии и шаги |
|
|
|
Разработчики вариантов |
Включайте только реаль |
||
использования всегда ре |
но обнаруживаемые усло |
||
шают проблему, сколько |
вия. Объединяйте усло |
||
и какие условия включить |
вия, |
которые |
оказывают |
в их описание |
на систему |
одинаковое |
|
|
воздействие |
|
Уровни шагов |
Чрезмерно крупные или |
Оставляйте в сценарии от 1 |
|||
|
мелкие шаги сценария ва |
трех до девяти шагов. В |
|||
|
рианта использования де |
идеальном случае все ша |
|||
|
лают вариант использова |
ги должны быть на близ |
|||
|
ния трудным для воспри |
ких уровнях и на уровне |
|||
|
ятия и понимания |
абстракции, |
следующем |
||
|
|
за целью варианта |
ис |
||
|
|
пользования |
|
|
|
Выполнение цели |
У читателей и разработ |
При |
описании каждого |
||
действующего ли |
чиков возникают пробле |
четко |
указывайте, какое |
||
ца |
мы в понимании поведе |
действующее лицо |
вы |
||
|
ния системы, если неяс |
полняет действие, и что |
|||
|
но, какое действующее |
оно получает по его за |
|||
|
лицо отвечает за выпол |
вершении |
|
|
|
|
нение шага сценария, и |
|
|
|
|
|
что оно делает для его за |
|
|
|
|
|
вершения |
|
|
|
|
Продвижение впе |
Разработчики должны ре |
Исключайте |
или объеди |
||
ред |
шить, как много поведе |
няйте |
шаги, |
которые |
не |
|
ния включить в каждый |
означают никакого дви |
|||
|
шаг. Слишком много де |
жения вперед ЦЛ91 действу |
|||
|
талей делает вариант ис |
ющего лица. Упрощайте |
|||
|
пользования длинным и |
фрагменты, |
которые |
от |
|
|
трудным для чтения |
влекают внимание читате |
|||
|
|
1ля от движения вперед |
|
270 |
Глава 3 |
Наименование 1 образца
Нейтральность к технологии
Продолжение
Проблема |
Предлагаемое решение |
Включение технологи ческих офаничений и де талей реализации в опи сание варианта использо вания увеличивает слож ность и затрудняет пони мание его цели
Описание варианта ис пользования должно быть нейтральным по отноше нию к технологии
Связи между вариантами использования |
|
|
|||||
Общее поведение |
Описание |
|
одинаковых |
Выражайте |
общие дей |
||
|
шагов в различных вари |
ствия |
в виде «включае |
||||
|
антах использования за |
мых» |
вариантов исполь |
||||
|
нимает лишнее время и |
зования |
|
|
|||
|
затрудняет понимание об |
|
|
|
|
||
|
щих процессов в модели |
|
|
|
|
||
|
вариантов использования |
|
|
|
|
||
Перемещение аль |
Длинные |
или сложные |
Рассмотрите возможность |
||||
тернатив |
описания |
альтернатив |
вьщеления |
сложных аль |
|||
|
могут занять доминирую |
тернатив в отдельный ва |
|||||
|
щее положение и пока |
риант использования |
|||||
|
заться более |
важными, |
|
|
|
|
|
|
чем они заслуживают |
|
|
|
|
||
Абстракция |
Попытка описать в одном |
Создайте |
обобщенный |
||||
|
варианте |
использования |
абстрактный вариант ис |
||||
|
две или более различных |
пользования. Поместите |
|||||
|
альтернатив, |
ни одна из |
каждый отдельный вари |
||||
|
которых не является до |
ант сценария, уточняю |
|||||
|
минирующей, приводит к |
щий абстракцию, |
в спе |
||||
|
проблемам |
|
циализированный |
вари |
ант использования
Модификация существующих вариантов использования
Удаление изли шеств
Чрезмерно длинный ва |
Переместите длинный, |
риант использования гро |
громоздкий фрагмент или |
моздок и труден для рабо |
слишком сложное расши |
ты, уводит в сторону вни |
рение в отдельный вари |
мание пользователей |
ант использования |