Документирование бизнес-правил

Типы бизнес-правил.

Бизнес-правило - это положение, определяющее или ограничивающее какие-либо стороны бизнеса. Его назначение - защитить структуру бизнеса, контролировать или влиять на его операции[9].

В настоящее время существует ряд методологий, разработанных специально для создания и документирования бизнес-правил и их использования при разработке автоматизированных информационных систем [11;10]. Однако на практике зачастую достаточно выявить и задокументировать относящиеся к системе правила и связать их с конкретными функциональными требованиями к приложению.

Для организации бизнес-правил предлагается множество различных схем классификации. Простейшая из них приведена на рис 3.4, и состоит из пяти типов бизнес-правил.

Рисунок 3.4. Типы бизнес-правил.

Шестая категория - термины: важные для бизнеса слова, фразы и аббревиатуры. Их, согласно рекомендациям Rational Unified Process, следует хранить в отдельном документе под названием «бизнес глоссарий».

Факты (facts) — это верные утверждения о бизнесе. Зачастую они описывают связи и отношения между важными бизнес-терминами. Факты также называют инвариантами — неизменными истинами о сущности данных и их атрибутах. Бизнес-правила во многих случаях могут ссылаться на определенные факты, однако последние обычно не преобразуются напрямую в функциональные требования к программному обеспечению. Сведения о сущности данных, важных для системы, применяют в моделях данных, создаваемых аналитиком или архитектором базы данных.

Примеры фактов:

· на каждый контейнер с реактивом нанесен уникальный штрих-код;

· клиент оплачивает доставку каждого заказа;

· заказ должен содержать не менее одной позиции;

· блиц-цена лота аукциона устанавливается продавцом;

· каждый авиарейс имеет аэропорт вылета и аэропорт прилета;

· автосалон реализует автомобили нескольких производителей (является мультибрэндовым дилером).

Ограничения (constraints) — определяют, какие операции может выполнять система и ее пользователи. Вот некоторые слова и фразы, которые применяются при описании ограничивающего бизнес-правила: должен / не должен, может / не может, только.

Примеры ограничений:

· постоянный посетитель библиотеки может отложить для себя до 10 книг;

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

· все программы должны соответствовать правительственным постановлениям, касающимся использования их людьми с ослабленным зрением;

· экипажи коммерческих авиарейсов должны каждые 24 часа отдыхать не менее 8 часов;

· возраст участника аукциона должен превышать 18 лет;

· автосалон может обменять старый автомобиль клиента на новый с минимальными для клиента финансовыми потерями.

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

Активатором операции (action enabler) называется бизнес-правило, приводящее к выполнению каких-либо действий при определенных условиях. Человек может выполнять эти действия вручную. Иногда правило может управлять некоторыми функциями программы, благодаря которым приложение при выполнении определенных условий реализует нужную модель поведения. Выражение вида «Если <некоторое условие верно или наступило определенное событие>, то <что-то произойдет>»— это ключ, который описывает активатор операции.

Примеры активаторов:

· если на складе имеются контейнеры с запрошенным химикатом, их следует предложить запросившему химикат лицу;

· если срок хранения контейнера с химикатом истек, необходимо уведомить лицо, у которого в данный момент находится контейнер;

· если клиент заказал книгу автора, написавшего несколько книг, клиенту следует предложить другие книги этого автора, прежде чем принять заказ;

· если на запрошенную клиентом дату вылета рейс не выполняется, необходимо предоставить ему расписание вылетов по данному направлению;

· если к моменту проведения расчетов с победителем аукциона его лицевой счет не содержит нужной суммы, право приобретения лота переходит к лицу, сделавшему вторую лучшую ставку;

· если клиент подал корректную заявку на прохождение тест-драйва, необходимо связаться с ним по телефону для согласования деталей.

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

Примеры выводов:

· если поставщик не может поставить заказанный товар в течение пяти дней с момента получения заказа, заказ считается невыполненным;

· считается, что срок хранения контейнеров с химикатами, разлагающимися на взрывоопасные составляющие, истекает через один год c даты изготовления;

· если выставленный участнику аукциона счет не был оплачен в течение трех дней с момента окончания аукциона, счет считается просроченным;

· если привезенный автосалоном под заказ автомобиль не был выкуплен клиентом в течение 10 дней, автомобиль считается находящимся в свободном наличии;

· если в расписании зимнего сезона отсутствуют сведения о рейсе, выполняемом в летний период, рейс считается отмененным на весь период действия нового расписания.

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

· цена единицы товара снижается на 10% при заказе от 6 до 10 единиц, на 20% — при заказе от 11 до 20 единиц и на 30% — при заказе свыше 20 единиц;

· стоимость автомобиля «Opel» в салоне рассчитывается путем сложения стоимости базовой модели, стоимости выбранных покупателем пакетов, стоимости опций, за минусом скидки при повторной покупке в салоне, и скидки корпоративного клиента, но при условии, что продаваемый автомобиль не реализуется по акции «КАСКО в подарок».

Отдельное вычисление может включать множество элементов. Во втором примере для расчета общей стоимости автомобиля использует алгоритм подсчета суммы, скидки и дополнительные условия. Это правило запутанно и сложно для понимания. Чтобы избавиться от данного недостатка, рекомендуется писать бизнес-правила на элементарном уровне, а не объединять множество деталей в одно правило. Сложное правило может ссылаться на используемые в нем отдельные правила. Это сделает их краткими и простыми. Кроме того, появляется возможность их повторного использования и создания различных комбинаций. Чтобы писать вычисления и активирующие операции бизнес-правила на элементарном уровне, не используйте в левой части конструкции «если — то» логику «или», а в правой части этой же конструкции — логику «и» [10]. К элементарным бизнес-правилам, влияющим на вычисление общей стоимости автомобиля из примера выше, относятся следующие:

· если выбранная клиентом комплектация автомобиля содержит пакеты опций, стоимость пакетов добавляется к стоимости базовой комплектации;

· если выбранная клиентом комплектация автомобиля содержит опции, стоимость опций добавляется к стоимости базовой комплектации;

· если клиент совершает повторную покупку, стоимость автомобиля уменьшается пропорционально скидке постоянного клиента;

· если клиент является корпоративным, стоимость автомобиля уменьшается пропорционально скидке корпоративного клиента;

· скидки корпоративного и постоянного клиента суммируются;

· если автомобиль реализуется по акции «КАСКО в подарок», скидки корпоративного и постоянного клиента не действуют.

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

Документирование бизнес-правил

Поскольку бизнес-правила зачастую влияют на множество приложений, организациям следует управлять этими правилами на корпоративном уровне, а не на уровне проектов. Большим организациям, а также компаниям, деловые операции и информационные системы которых в значительной степени регулируются и управляются бизнес-правилами, целесообразно прибегнуть к созданию базы данных таких правил. Целесообразным является использование коммерческих средств сбора и управления требованиями, одним из которых является IBM Rational RequisitePro.

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

Следует отметить, что согласно мнению некоторых авторов [12] бизнес-правила необходимо выражать строго и формально с целью создания основания для последующей автоматизации предприятия. Одним из возможных решений является использование языка объектных ограничений (Object Constraint Language - OCL), определенного в рамках языка UML.

Пример.

Необходимо определить, что размер команды не может превышать 10 человек. Используя язык OCL, можно определить это правило как инвариант: context Team inv: self.numberOfMembers <= 10

Вместе с тем, большинство представителей заинтересованных сторон испытывают трудности при интерпретации выражений, заданных на языке OCL, предпочитая использовать естественный язык. Для решения этой задачи можно определить набор зарезервированных выражений, используемых при определении правил. Грэйди Буч, Айвар Джэйкобсон и Джеймс Румбах в своей работе [12] рекомендуют использовать следующие зарезервированные выражения:

· ЕСЛИ

· ТОЛЬКО ЕСЛИ

· КОГДА

· ТОГДА

· ЕЩЕ

· ВСЕГДА ДОЛЖНО СОДЕЖАТЬ

· КОРРЕКТНО ЗАВЕРШЕН

Придерживаясь этой менее формальной записи бизнес-правил выражение, приведенное выше, можно записать следующим образом:

Команда ВСЕГДА ДОЛЖНА СОЖЕРЖАТЬ меньше либо ровно 10 человек.

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