С частью 3 можно ознакомиться, перейдя по ссылке

VII Детализируем процессы, включенные в рамки проекта

Нужно усложнять, чтобы в результате все стало проще,
а не упрощать, чтобы в результате все стало сложнее.
Веслав Брудзиньский

Определив основные функции и рамки проекта, можно переходить к детальному описанию алгоритмов функционирования, создаваемой системы. В этом блоке работ мы используем прием, позволяющий «попутно» определить связи между процессами и хранилищами. Это поможет нам плавно перейти от моделей процессов к моделям данных.

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

Для подобных целей удобно использовать графические изображения бизнес процессов при помощи алгоритмических диаграмм (деловое моделирование). Алгоритмизация – это еще один прием дисциплины «Системный анализ». Процессы на диаграммах желательно группировать по бизнес транзакциям, что позволит получить список основных сценариев – возможностей, которыми должен обладать целевой продукт, для его согласования с заказчиком, а также, для обсуждения полноты и логики процессов. То есть каждая бизнес транзакция на диаграмме, соответствует сценарию использования системы пользователем.

Еще одно достоинство этого вида диаграмм, заключается в том, что они исключительно полезны при разработке приемочных тестов. Ну об этом чуть позже.

На рисунке 7.1 изображен процесс формализации требований к целевой системе, дополненный подпроцессом определения сценариев ее использования.


Рисунок 7.1 — модель процесса определения сценариев использования системы

К алгоритмическим диаграммам, описывающим процессы предъявляют следующие требования:

• они должны достаточно подробно и точно описывать логику процесса. Настолько подробно и точно, насколько это нужно в каждом конкретном случае.
• они должны быть одинаково понятны различными группами заинтересованных лиц проекта. Это, в первую очередь, люди бизнеса, чью работу они описывают, а также исполнители: бизнес-аналитики, разработчики и т.п.

1. Используем диаграммы бизнес-процессов

Хочу уточнить, что в данном разделе мы взглянем на предметную область под иным углом и будем рассматривать описание не любых процессов, а именно процессов «уровня бизнеса», которые:

• хорошо понятны заказчику (конечным пользователям разрабатываемого целевого продукта);
• оперируют понятиями предметной области заказчика («документ», «задача», «план» и т.п.);

Напомню основные правила построения диаграмм деятельности. Каждая диаграмма должна иметь начало процесса. В отличие от канонических диаграмм Activity диаграммы бизнес процессов могут иметь несколько элементов начала бизнес транзакции. Прямоугольником обозначается процесс (операция). Процесс может быть снабжен комментариями и выделен стереотипом, классифицирующим деятельность. Стрелками обозначаются переходы между активностями. Ромбами обозначаются условные переходы (ветвление) процесса, в которых обычно показано условие. В каждый элемент условного перехода можно попасть только через один переход (входящая стрелка), а вот выходов может быть множество. С процессами все наоборот, в каждый процесс можно попасть через несколько переходов, а сам процесс может иметь только один переход (стрелка из прямоугольника). Каждая диаграмма должна быть снабжена элементом окончания транзакции. Их может быть несколько, в виде различных результатов выполнения.

Итак освежив теорию, пройдемся дальше по практике.

В качестве примера опишем более подробно функцию системы «А1.1 Сбор потребностей заказчика», выявленную нами на предыдущем этапе. Обратите внимание, что на каждом последующем шаге, мы используем результат (продукт) предыдущего шага. На рисунке 7.2 изображена диаграмма, описывающая бизнес процесс сбора потребностей заказчика. В отличие от диаграмм IDEFO, диаграмма бизнес процессов позволяет моделировать условные переходы, что критично для описания алгоритмов функционирования: «Если выполняется условие – делаем то-то, иначе — следующее».


Рис. 7.2 – Диаграмма Бизнес процесса Сбор потребностей заказчика

Несмотря на то, что мы рассматриваем процессы, связанные с бизнес составляющей разрабатываемого программного продукта, на диаграмме можно и нужно выделить и системные элементы. Например, на рис.7.2 отмечено — хранилище «Пользовательские истории», которое используется для:

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

Таким образом, мы фиксируем: в каких процессах, какое хранилище используется и какими при этом бизнес данными обменивается система с пользователем. Для чего это нужно, Вы увидите чуть позже.

2. Пример использования диаграммы бизнес-процессов для определения ролей и хранилищ данных

Давайте рассмотрим еще один, более сложный пример описания бизнес процесса. На рисунке 7.3 изображена диаграмма, моделирующая процесс Обработки обращений заинтересованных лиц.


Рис. 7.3 – Диаграмма Бизнес процесса Обработка обращений заинтересованных лиц

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

И это еще не все. На диаграмме видно (по направлению стрелок), как одни процессы выполняют запись в хранилища, а другие производят выборку данных из них. Догадались, в чем «фишка»? А это, еще одна полезная функция использования диаграмм сего типа — определение всех «точек» обращения к хранилищам для выборки и записи данных. Анализ этих процессов позволяет например, оптимизировать их для минимизации возникновения взаимных блокировок записей в базе данных.

Диаграммы Бизнес процессов, также помогут нам для определения противоречий в функциях, изменяющих данные в хранилищах. Иными совами: проверка непротиворечивости требований.
Таким образом, происходит последовательное детальное описание всех процессов, реализующих функции, выявленные на предыдущей стадии моделирования, и определение их взаимосвязей с моделью структуры хранилищ данных. Нечто подобное используется в методологии ICONIX, только там за основу взяты диаграммы последовательностей.

3. Используем диаграммы бизнес-процессов для реинжениринга

Моделируя бизнес процессы, существующие у заказчика при помощи диаграмм, зачастую можно натолкнуться на следующие проблемы:

• дублирование функций различными подразделениями;
• неэффективное распределение обязанностей между исполнителями;
• процессы, производящие невостребованные продукты;
• «провисание» зон ответственности на стыке процессов;
• пересечение полномочий в процессах и т.д.

В таких случаях диаграммы могут стать отправной точкой в обсуждении с представителями заказчика вопросов оптимизации или реинжиниринга бизнес процессов. Крайне важно суметь убедить сторону заказчика не выполнять автоматизацию тех процессов, которые существуют, а разработать и автоматизировать новые «правильные» процессы. Но при этом, не стоит утаивать связанные с этим проблемы, как минимум такие как: «ломка» сложившихся на предприятии устоев и необходимость какое-то время, при внедрении системы, поддерживать и старые и новые бизнес процессы. Возможно, Вы примите какой-то третий, временный вариант, который позволит смягчить переход и минимизировать неудобства.

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

Презентовать подобные исследования лучше в виде сравнительных таблиц. В качестве колонок обозначаем процессы: текущий и целевой или несколько вариантов целевого. В качестве строк — утвержденные показатели. На пересечении заполняются значения показателя для процесса.
Например, таблица сравнительного анализа может выглядеть так:



Формирование таких показателей и определение их значений, должно производиться при непосредственном участии представителей заказчика. Количество показателей не должно превышать 20.

4. Просчитываем предварительную ркусрсоемкость проекта

Рассматриваемый нами в этой главе тип диаграмм имеет еще одно очень существенное достоинство. На основании их можно довольно точно оценить предварительную трудоемкость процесса разработки целевого продукта. Если на каждом элементе диаграммы подписать стереотип, например: «Форма списка», «Форма карточки», «Функция», «Отчет» и т.д., то легко подсчитать количество элементов, которые необходимо реализовать. Трудоемкость реализации каждого типа элемента, при использовании устоявшихся в команде технологий, в общем известна. Для повышения точности можно использовать коэффициент сложности.

Например, таблица предварительного расчета трудоемкости может выглядеть так:



Для удобства, коэффициенты могут использоваться трех типов “сложный”, “средний” и “простой” и для каждого типа элементов иметь свои значения. Например:

• для Сущностей: 0,3 — простой; 0,7 — средний; 1 – сложный;
• для Выборки: 1 — простой; 1,5 — средний; 2 – сложный;
• для Форм: 0,7 — простой; 1,5 — средний; 2 – сложный;
• для Процедур: 1 — простой; 3 — средний; 6 – сложный;
• для Отчетов: 0,5 — простой; 1 — средний; 3 – сложный;

Разработав на начальной стадии подобную таблицу, ею можно пользоваться и в дальнейшем на протяжении проектирования, внося в нее изменения при уточнении и доработке требований. Это очень эффектно, когда “легким движением руки” аналитик предоставляет менеджеру проекта обновленные и уточненные прогнозы ресурсных затрат для свежих, только что доработанных требований.

5. Пересматриваем границы проекта (при необходимости)

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

На диаграмме функциональной модели системы, рассмотренной в прошлой главе, мы добавили новый процесс: «Управление совещаниями» см. Рисунок 7.3, он выделен сиреневым цветом.
На вход процессу поступает информация о реализации ранее сформулированных требований, а результатом выполнения функций могут стать планы проведения совещаний, итераций и т.п., Например, этот модуль может рассылать письма приглашенным участникам с информацией о совещаниях.


Рис. 7.4 – Изменения в функциональной модели системы Управления требованиями

6. Подведем итоги использования процессных моделей

На этапе детального уточнения функций системы и сценариев ее использования, часто возникает ощущение потери нити понимания того, как же всё-таки должна работать система. Не стоит этого бояться и отчаиваться. Продолжайте уточнять требования и переосмысливать начальное представление о системе – это нормально. Постепенно все само встанет на свои места.

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

В моей практике был проект, в котором при помощи высшего руководства, диаграммы делового моделирования были популяризированы среди среднего звена менеджмента. Люди втянулись и уже активно соревновались друг с другом в умении их использовать. Это стало не только модно, но и очень полезно, при обсуждении текущих деловых процессов, а также моделировании новых.

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

Эту аналогию желательно донести до всех участников проекта. Идеальный вариант, свидетельствующий о качестве подготовленных диаграмм и грамотной их презентации всем заинтересованным лицам, выглядит как митинг членов команды, сгрудившихся над диаграммами и водящим по ним указками, подобно генералам, склонившимся над стратегическими картами наступлений. Развивая аналогии дальше, вышеупомянутые диаграммы IDEFO, можно сравнить с Атласами карт, группирующими их по областям (в данном случае — предметным).

В следующей части мы будем выявлять сущности предметной области ссылка.