Вендров А.М. Проектирование программного обеспечения экономических информационных систем

Подождите немного. Документ загружается.

Моделирование бизнес-процессов и спецификация требований 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

Образцы написания вариантов использования

Наименование

образца

Проблема Предлагаемое решение

Формирование команды разработчиков

Небольшая

команда разработ-

чиков

Участие слишком многих

людей в написании вари-

анта использования не-

эффективно; компромисс

между многими различ-

ными точками зрения мо-

жет привести к неудов-

Ограничьте число разра-

ботчиков, отрабатываю-

щих детали варианта ис-

пользования, двумя или

тремя людьми. Для под-

ключения дополнитель-

ных участников исполь-

Моделирование бизнес-процессов и спецификация требований 265

Продолжение

Наименование

образца

Состав сторонних

участников

Сбалансированная

команда

Проблема

летворительным резуль-

татам при создании сис-

темы

Невозможно удовлетво-

рить потребности всех за-

интересованных лиц, не

обмениваясь информаци-

ей с ними

Команда из близких по

роду деятельности, оди-

наково мыслящих людей

может создать небольшой

набор офаниченных ва-

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

не удовлетворяющий об-

щим потребностям

Предлагаемое решение

зуйте образец Двухуров-

невое рецензирование

Активно привлекайте за-

казчиков и заинтересо-

ванных лиц в вашей орга-

низации к разработке ва-

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

Формируйте команду из

людей с различными спе-

циализациями, представ-

ляющими интересы раз-

личных заинтересован-

ных лиц. Команда долж-

на включать как разра-

ботчиков, так и пользова-

телей

Организация процесса разработки

Глубина после об-

щего представле-

ния

Итерационная |

разработка

Множество форм

Невозможно продвигать-

ся вперед и создавать на-

бор согласованных вари-

антов использования, ес-

ли тратить впустую время

на последовательное на-

писание подробных вари-

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

Разработка вариантов ис-

пользования за один про-

ход затруднительна, ус-

ложняет внесение допол-

нительной информации и

затрудняет выявление

факторов риска

Различные проекты тре-

буют различную степень

формальности и различ-

Разрабатывайте сначала

общее представление ва-

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

затем постепенно добав-

ляйте детали, работая с

группой взаимосвязан-

ных вариантов использо-

вания 1

Разрабатывайте варианты

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

онно,

повышая на каждой

итерации их точность и

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

Выбирайте формат вари-

антов использования, ос-

новываясь на проектных

266

Глава 3

Продолжение

Наименование

образца

Двухуровневое ре-

цензирование

Своевременное

завершение

Свобода

творчества

Проблема

ные шаблоны. Использо-

вать один и тот же шаб-

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

вания непродуктивно

Многие заинтересован-

ные лица могут пожелать

принять участие в рецен-

зировании вариантов ис-

пользования. Это слиш-

ком долгое и дорогостоя-

щее занятие

Разработка модели вари-

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

сверх потребностей заин-

тересованных лиц и раз-

работчиков приводит к

напрасным тратам ресур-

сов и затягивает проект

Чрезмерное внимание к

стилю написания вариан-

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

мозит работу

Предлагаемое решение

рисках и предпочтениях

участников

Используйте два вида ре-

цензирования: первое,

проводимое небольшой

группой внутренних

участников, может вы-

полняться многократно;

второе, проводимое пол-

ной группой, выполняет-

ся,

как правило, один раз |

Прекращайте разработку

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

ния, как только они дос-

тигают необходимой пол-

ноты и удовлетворяют

потребности участников

проекта |

Небольшие различия в

стиле написания вариан-

тов использования несу-

щественны. Если вариант

использования достиг не-

обходимой полноты, его

автор имеет право на сти-

листические отступления

Организация набора вариантов использования

Общепринятая

четкая концепция

Недостаточно четкое

представление о системе

может привести к неуве-

ренности и противопо-

ложным мнениям среди

заинтересованных лиц и

быстро парализовать про-

ект

Необходимо подготовить

и утвердить концепцию

системы, в которой четко

определены ее цели и

роль в деятельности орга-

низации. Распространите

концепцию среди всех

участников проекта

Моделирование бизнес-процессов и спецификация требований 267

Продолжение

Наименование

образца

Видимые границы

Ясный состав

действующих лиц

Транзакции,зна-

чимые для пользо-

вателей

Разворачива-

ющееся представ-

ление

Проблема

Если вы не определили

границы системы, ее

масштаб будет расти не-

контролируемым образом

Если выявлять только

пользователей системы,

игнорируя роли, которые

они ифают по отноше-

нию к системе, можно

упустить существенную

часть поведения системы

или ввести избыточное

поведение

Система несовершенна,

если она не может пре-

доставить пользователям

необходимые услуги и не

выполняет цели и задачи,

определяемые ее концеп-

цией

Количество шагов в опи-

сании поведения системы

превышает возможности

охвата и интересы раз-

личных типов читателей

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

Предлагаемое решение

Установите четкую и ви-

димую границу между

системой и внешней сре-

дой, перечислив людей и

оборудование, взаимо-

действующих с данной

системой

Идентифицируйте

действующих лиц, с кото-

рыми должна взаимодей-

ствовать система, и роли,

которые они играют по

отношению к системе.

Четко опишите каждую

роль

Идентифицируйте важ-

ные,

значимые услуги,

которые система предос-

тавляет действующим ли-

цам для удовлетворения

их потребностей

Создайте иерархическую

организацию набора ва-

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

которую можно развер-

нуть для большей детали-

зации, или свернуть, что-

бы скрыть детали и пока-

зать контекст

Отдельный вариант использования

Законченная

единственная цель

Неправильно заданные

цели не дают разработчи-

кам четко определить, где

заканчивается один вари-

Каждый вариант исполь-

зования должен иметь за-

конченную и четко опре-

деленную цель, которая

268

Глава 3

Продолжение

Наименование

образца

Проблема Предлагаемое решение

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

чинается другой

может находиться на лю-

бом уровне образца Раз-

ворачивающееся предс-

тавление

Имя в виде гла-

гольной фразы

Бессмысленные, слиш-

ком общие имена вариан-

тов использования не да-

ют читателям правильно-

го представления, на них

сложно ссылаться

Именуйте каждый вари-

ант использования актив-

ной глагольной фразой,

отражающей цель основ-

ного действующего лица

Сценарий и фраг-

менты

Читатели должны иметь

возможность легкого сле-

дования по интересующе-

му их сценарию, в про-

тивном случае они могут

утратить интерес или по-

терять важную информа-

цию

Основной сценарий дол-

жен быть предельно

простым, без анализа воз-

можных ошибочных си-

туаций. Фрагменты сце-

нария, отражающие аль-

тернативы, должны рас-

полагаться под ним

Исчерпывающие

альтернативы

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

может иметь много аль-

тернатив. Отсутствие не-

которых из них означает,

что разработчики непра-

вильно понимают поведе-

ние системы, и система

может получиться несо-

вершенной

Описывайте все альтерна-

тивы и ошибочные ситуа-

ции, которые могут иметь

место в варианте исполь-

зования

Перефузка ин-

формацией

Включение нефункцио-

нальных требований в ва-

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

жет быстро привести его в

неопределенное и беспо-

рядочное состояние

Включите дополнитель-

ные позиции в шаблон

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

за пределами текста сце-

нария, чтобы отразить

полезную дополнитель-

ную информацию

Точность и читае-

мость

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

ния, слишком сложные

для нетехнических специ-

алистов или слишком не-

Сделайте вариант ис-

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

читаемым, чтобы заинте-

ресованные лица могли в

Моделирование бизнес-процессов и спецификация требований 269

Продолжение

1 Наименование

образца

Проблема

точные для разработчи-

ков,

несовершенны и мо-

гут привести к созданию

неадекватной системы

Предлагаемое решение

нем разобраться и оце-

нить его, и достаточно

точным, чтобы разработ-

чики понимали, что им

делать

Сценарии

шаги

Обнаруживаемые

условия

Уровни шагов

Выполнение цели

действующего ли-

ца

Продвижение впе-

ред

Разработчики вариантов

использования всегда ре-

шают проблему, сколько

и какие условия включить

в их описание

Чрезмерно крупные или

мелкие шаги сценария ва-

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

лают вариант использова-

ния трудным для воспри-

ятия и понимания

У читателей и разработ-

чиков возникают пробле-

мы в понимании поведе-

ния системы, если неяс-

но,

какое действующее

лицо отвечает за выпол-

нение шага сценария, и

что оно делает для его за-

вершения

Разработчики должны ре-

шить, как много поведе-

ния включить в каждый

шаг. Слишком много де-

талей делает вариант ис-

пользования длинным и

трудным для чтения

Включайте только реаль-

но обнаруживаемые усло-

вия. Объединяйте усло-

вия, которые оказывают

на систему одинаковое

воздействие

Оставляйте в сценарии от

трех до девяти шагов. В

идеальном случае все ша-

ги должны быть на близ-

ких уровнях и на уровне

абстракции, следующем

за целью варианта ис-

пользования

При описании каждого

четко указывайте, какое

действующее лицо вы-

полняет действие, и что

оно получает по его за-

вершении

Исключайте или объеди-

няйте шаги, которые не

означают никакого дви-

жения

вперед ЦЛ91

действу-

ющего лица. Упрощайте

фрагменты, которые от-

влекают внимание читате-

ля

от

движения вперед

270

Глава 3

Продолжение

Наименование

1 образца

Нейтральность к

технологии

Проблема

Включение технологи-

ческих офаничений и де-

талей реализации в опи-

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

вания увеличивает слож-

ность и затрудняет пони-

мание его цели

Предлагаемое решение

Описание варианта ис-

пользования должно быть

нейтральным по отноше-

нию к технологии

Связи между вариантами использования

Общее поведение

Перемещение аль-

тернатив

Абстракция

Описание одинаковых

шагов в различных вари-

антах использования за-

нимает лишнее время и

затрудняет понимание об-

щих процессов в модели

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

Длинные или сложные

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

могут занять доминирую-

щее положение и пока-

заться более важными,

чем они заслуживают

Попытка описать в одном

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

две или более различных

альтернатив, ни одна из

которых не является до-

минирующей, приводит к

проблемам

Выражайте общие дей-

ствия в виде «включае-

мых» вариантов исполь-

зования

Рассмотрите возможность

вьщеления сложных аль-

тернатив в отдельный ва-

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

Создайте обобщенный

абстрактный вариант ис-

пользования. Поместите

каждый отдельный вари-

ант сценария, уточняю-

щий абстракцию, в спе-

циализированный вари-

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

Модификация существующих вариантов использования

Удаление изли-

шеств

Чрезмерно длинный ва-

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

моздок и труден для рабо-

ты,

уводит в сторону вни-

мание пользователей

Переместите длинный,

громоздкий фрагмент или

слишком сложное расши-

рение в отдельный вари-

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