Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

n1

.pdf
Скачиваний:
14
Добавлен:
17.02.2016
Размер:
14.05 Mб
Скачать

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

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

Продолжение

Проблема

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

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

Описание варианта ис­ пользования должно быть нейтральным по отноше­ нию к технологии

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

 

 

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

Описание

 

одинаковых

Выражайте

общие дей­

 

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

ствия

в виде «включае­

 

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

мых»

вариантов исполь­

 

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

зования

 

 

 

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

 

 

 

 

 

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

 

 

 

 

 

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

 

 

 

 

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

Длинные

или сложные

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

тернатив

описания

альтернатив

вьщеления

сложных аль­

 

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

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

 

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

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

 

заться более

важными,

 

 

 

 

 

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

 

 

 

 

Абстракция

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

Создайте

обобщенный

 

варианте

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

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

 

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

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

 

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

ни одна из

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

 

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

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

 

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

щий абстракцию,

в спе­

 

проблемам

 

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

вари­

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

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

Удаление изли­ шеств

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

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

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

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

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

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

ты, уводит в сторону вни­

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

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]