Практика формирования требований в ИТ проектах от А до Я. Часть 4. Бизнес процессы, автоматизируемые системой

Об авторских тренингах на тему: «Обучение проектированию ПО» подробнее можно узнать на моем YouTube канале

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

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

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

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

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

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

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



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

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

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

Диаграммы бизнес процессов основаны на канонических нотациях Activity (диаграммы деятельности), но имеют дополнительные особенности, о которых я поведаю в этой главе.

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

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

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

Процессы на диаграммах желательно разбивать на бизнес транзакции (business transaction) см. рис.7.2, что позволит получить список основных сценариев – возможностей, которыми должен обладать целевой продукт, для его согласования с заказчиком, а также, для обсуждения полноты и логики процессов. То есть каждая бизнес транзакция на диаграмме, должна соответствовать одной конечной операции, представленной в виде сценария использования системы пользователем.

На рисунке 7.2 приведен пример контейнера диаграмм, группирующий диаграммы процессов, разбитые по бизнес транзакциям.



Рисунок 7.2 – Деление процессов на бизнес транзакции

Как на любой диаграмме деятельности, должно быть указано начало процесса и его окончание (варианты завершения). Например на рис. 7.4 представлено два варианта завершения процесса «Потребность зафиксирована» или «Потребность отклонена». Но в отличие от канонической диаграммы, на диаграммах данного типа, процесс может начинаться с нескольких событий, см. рис.7.3



Рисунок 7.3 – Фрагмент диаграммы с 2_умя точками входа в процесс

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



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

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

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

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

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

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



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

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

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

Например, на рис. 7.6 Хранилище «Элементы архитектуры», может использоваться в нескольких бизнес транзакциях и в нескольких процессах.



Рис. 7.6 – Использование диаграммы для формализации хранилищ

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



Рис. 7.7 – Таблица зависимостей ресурса

Диаграммы Бизнес процессов, также помогут нам для определения противоречий в функциях, изменяющих данные в хранилищах. Иными совами: проверка непротиворечивости требований. Таким образом, происходит последовательное детальное описание всех процессов, реализующих функции, выявленные на предыдущей стадии моделирования, и определение их взаимосвязей с моделью структуры хранилищ данных. Нечто подобное используется в методологии 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.8, он выделен сиреневым цветом.
На вход процессу поступает информация о реализации ранее сформулированных требований, а результатом выполнения функций могут стать планы проведения совещаний, итераций и т.п., Например, этот модуль может рассылать письма приглашенным участникам с информацией о совещаниях.



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

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

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

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

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

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

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

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