© Лысенко М.А., Осипов М.Г. (ЗАО "Кворум")
Статья была опубликована в журнале "Нефть и капитал"
(публикуется на сайте с согласия авторов)

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

В качестве примера рассмотрим упрощенный бизнес-процесс "Контроль исполнения планов", в той или иной форме встречающийся во многих организациях.

Неформализованное описание примера

Объект

Будем считать, что организация состоит из центрального офиса, выполняющего руководящие и координирующие функции, и территориально удаленных филиалов, исполняющих задания центра (рис. 7).

Задачи.

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

В течение года филиалы исполняют план, отчитываются по фактическим срокам и объемам выполненных работ перед центром.

Центральный офис в течение года контролирует исполнение плана филиалами и, при необходимости корректирует план.

Рис. 7. Моделируемая организация.

Формализованное описание примера

В данном разделе приведено формализованное описание процессов "как есть" примера. Бизнес-процессы описаны спецификациями юзкейсов.

Функциональная схема примера

Рис. 8. Структура юзкейсов примера.

На диаграмме можно увидеть актеров, участвующих в бизнес-процессе, а также юзкейсы, в которых они задействованы или в которых происходит пересечение (столкновение) их интересов как стейкхолдеров. Также изображены наиболее значимые информационные сущности.

Формировать годовой план
Context of use

Центральный офис выпускает шаблон плана и рассылает его в филиалы. Филиалы вносят свои предложения и утверждают свои разделы плана в центральном офисе. Центральный офис выпускает годовой план филиалов.

Scope
Бизнес-процесс "Контроль исполнения планов".
Level
User Goal.
Primary actor
Центральный офис.
Stakeholders & Interests

Main Success Scenario

1. Центральный офис выпускает шаблон плана (составляет список работ и их планируемые объемы) для каждого филиала.
2. Центральный офис рассылает шаблоны плана в филиалы.
3. Филиал получает соответствующий ему шаблон плана.
4. Филиал корректирует шаблон плана (вносит предложения, то есть добавляет свои работы и их объемы).
5. Филиал отсылает шаблон плана с корректировками в центральный офис.
6. Центральный офис принимает шаблонов плана с корректировками от филиалов и утверждает их.
7. Центральный офис выпускает годовой план.
8. Центральный офис рассылает годовой план в филиалы.
9. Филиал получает годовой план.

Extensions

6а. Центральный офис не утверждает корректировки филиалов в шаблоне плана.
6а1. Центральный офис корректирует шаблон плана. Переход на шаг 2.

Исполнять годовой план
Context of use

Филиал исполняет годовой план, возможно внесение предложений на изменение плана. Центральный офис принимает или отклоняет предложения. Филиал ежемесячно отчитывается об исполнении плана.

Scope
Бизнес-процесс "Контроль исполнения планов".

Level
User Goal.

Primary actor
Филиал.
Stakeholders & Interests

Main Success Scenario

1. Филиал ежемесячно исполняет работы, указанные в годовом плане.
2. Филиал по факту исполнения работы отражает в годовом плане факты исполнения работ (фактические сроки и объемы).
3. Филиал ежемесячно отправляет отчет по исполнению плана в отчетном месяце в Центральный офис.
4. Центральный офис ежемесячно получает отчеты по исполнению плана в отчетном месяце из Филиалов.

Extensions

1а. Филиал вносит предложение по изменению плана в Центральный офис.
1а1. Центральный офис получает предложения по изменению плана от Филиала.
1а2. Центральный офис рассматривает предложение и вносит исправления в план филиала. Вернуться на шаг 1.
1а2а. Центральный офис рассматривает предложение и отказывает в исправлениях в плане филиала. Вернуться на шаг 1.

Контролировать исполнение годового плана
Context of use

Центральный офис сравнивает план и факт и может корректировать дальнейший план в случае расхождений. Отчетный месяц закрывается.

Scope
Бизнес-процесс "Контроль исполнения планов".

Level
User Goal.

Primary actor
Центральный офис.
Stakeholders & Interests

Main Success Scenario

1. Центральный офис ежемесячно сравнивает плановые и фактические показатели плана.
2. Центральный офис делает заключение о соответствии плана и факта.
3. Центральный офис закрывает отчетный месяц (переводит его в состояние "только чтение").

Extensions

2а. Центральный офис делает заключение о несоответствии плана и факта.
2а1. Центральный офис вносит коррективы в план на следующие месяцы.
2а2. Центральный офис отправляет откорректированный план в Филиал.
2а3. Филиал получает откорректированный план из Центрального офиса. Переход на шаг 3.

Необходимые пояснения к примеру

На данном примере можно представить, как строится текстовое описание юзкейсов. Структура шаблона полноформатного (fully dressed) юзкейса в зависимости от потребностей разработчиков может сокращаться, или наоборот расширяться. В примере приведены не полноформатные юзкейсы.

Раздел Context of Use применяется для краткого описания юзкейса, он вводит читателя в содержание юзкейса и формирует его представление о нем.

Раздел Scope применяется для позиционирования юзкейса - бизнес юзкейс или же юзкейс информационной системы.

Раздел Level показывает, на каком уровне - суммарном (summary), цели пользователя (user goal) или субфункциональном (subfunction) - написан юзкейс.

Основным и наиболее значимым разделом юзкейса по А. Кобурну является раздел Stakeholders & Interests. Его проработке необходимо уделять самое пристальное внимание. При написании данного раздела сначала надо перечислить всех стейкхолдеров (заинтересованных лиц), назвать их интересы по отношению к операциям юзкейса (при этом будут выделены противоречия в интересах стейкхолдеров, которые должны быть учтены и не забыты при проектировании системы). Данный раздел позволяет уже на этапе описания бизнес-процессов зафиксировать интересы стейкхолдеров к юзкейсу. Интерес существует объективно, стейкхолдер может и не догадываться о нем. Цель данного раздела - породить у экспертов предметной области дискуссии, в ходе которых будут вскрыты и зафиксированы столкновения интересов. Это тем более важно, поскольку при переходе от бизнес-сценариев к проекту системы происходит разрыв интересов - ведь люди работают с системой, а не напрямую друг с другом. Данный раздел, не позволяет забыть об интересах стейкхолдеров, заставляет учесть их в системе - тогда система действительно будет работать для всех и удовлетворять всех.

Каждый юзкейс включает в себя совокупность сценариев, одни из которых заканчиваются успешно (достижением цели), другие завершаются неуспешно (в процессе их выполнения цель не может быть достигнута). Каждый сценарий или фрагмент сценария включает условие, при выполнении которого он начинает выполняться до своего успешного или неуспешного завершения. Среди всех сценариев юзкейса рекомендуется выделить один наиболее типичный сценарий - Главный Успешный Сценарий (раздел Main Success Scenario), в котором достигается цель основного актера и, кроме того, удовлетворяются все интересы стейкхолдеров. Главный успешный сценарий является безальтернативным сценарием - в нем пишутся действия, прямо приводящие к достижению цели. Тогда, все другие сценарии описываются как расширения основного успешного сценария (раздел Extensions). Главный успешный сценарий и его расширения базируются на одной и той же структуре, которая включает следующие компоненты.

• Цель, которую надо достигнуть. Для главного успешного сценария это в точности имя юзкейса. Для сценариев расширения цель состоит в том, чтобы либо завершить юзкейс, либо после обработки условия продолжить выполнение основного успешного сценария;
• Совокупность шагов, определяющих действия в сценарии. Они удовлетворяют одним и тем же правилам для каждого фрагмента каждого сценария;
• Условие завершения. Цель достигается в конце основного успешного сценария. Фрагмент сценария может завершиться как успешно, так и неуспешно;
• Возможный набор расширений, записанных как фрагменты сценариев. Расширения основного успешного сценария размещаются в разделе Extensions. Расширения к расширениям размещаются непосредственно внутри тела основного расширения.

Каждый сценарий или его фрагмент записывается как последовательность действий по достижению цели со стороны различных актеров - по принципу передачи мяча - от игрока к игроку. Каждое действие может быть отнесено к одному из трех возможных типов:

• взаимодействие между двумя актерами (один актер передает информацию другому актеру и активизирует его);
• действие, гарантирующее защиту интересов стейкхолдера;
• действие, порождающее изменение внутри системы в контексте интересов стейкхолдера.

В Главном Успешном Сценарии (Main Success Scenario) шаги перенумеровываются естественным образом.

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

Другие возможности использования методики А. Кобурна

Размер статьи не позволяет подробно остановиться на всех вариантах применения методики, однако следует упомянуть их. Кроме этапа анализа бизнес-процессов, комбинацию диаграмм языка UML и текстовых спецификаций юзкейсов по методике А. Кобурна можно использовать на следующих стадиях разработки корпоративных информационных систем.

• Стадия формирования архитектуры и требований к КИС. На данной стадии в качестве входных данных используются результаты анализа бизнес-процессов. Описанные юзкейсы, в результате анализа группируются в компоненты (подсистемы) КИС. С помощью юзкейсов описывается функционал КИС, на основе которого формируются требования к компонентам и интерфейсам взаимодействия между ними.
• Стадия подготовки технического задания, технического проектирования подсистем КИС. Основу ТЗ и ТП составляет набор системных юзкейсов (в которых актеры взаимодействуют с системой). Системные юзкейсы являются более подробными, нежели бизнес-юзкейсы.
• Стадия тестирования подсистем КИС. На данной стадии, на основе юзкейсов из ТП пишется набор тесткейсов, по которым производится тестирование системы.
• Стадия внедрения подсистем КИС. Юзкейсы небесполезны и в этом случае - они войдут в функциональное описание подсистем.

Выводы

Анализ показывает, что комбинация средств языка UML и текстовых спецификаций юзкейсов по методике А. Кобурна является мощным инструментом при разработке корпоративных информационных систем. Данная методика, в отличие от большинства распространенных методик структурного анализа и проектирования, может применяться на всех этапах разработки КИС и обладает такими преимуществами, как:

• удобство и простота понимания для всех сторон, участвующих в процессе создания КИС;
• стройность и логичность методологии;
• возможность применения на всех этапах создания КИС.

Методика опробована на практике и в настоящее время применяется фирмой "Кворум".

Литература

1. Вендров А. М. CASE-технологии. Современные методы и средства проектирования информационных систем. - М.: Финансы и статистика, 1998.
2. Калянов Г. Н. Консалтинг при автоматизации предприятий. - М.: СИНТЕГ, 1997.
3. Липаев В. В. Системное проектирование сложных программных средств для информационных систем. - М.: СИНТЕГ, 1999.
4. Фридман А. Л. Основы объектно-ориентированной разработки программных систем. - М.: Финансы и статистика, 2000.
5. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. - М.: ДМК, 2000.
6. Alistair Cockburn. Writing effective use cases. Addison-Wesley Pub Co. ISBN 0201702258.

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Обсудить на форуме
Отправить ссылку на страницу по e-mail