Бизнес правила для приложений

Один из часто задаваемых вопросов, касающихся любого проекта на основе UML [1] — где следует устанавливать бизнес-правила? Размышляя над таким проектом, мы часто думаем о процессе, управляемом сценариями использования (case driven process), в котором применяются понятия класса, последовательности и диаграмм состояний. Наиболее обычным из этих процессов является унифицированный процесс (Unified Process). Однако, как мы увидим далее, методология, которая здесь рассматривается, работает и с другими процессами, например, с процессами Feature Driven Development (функционально-ориентированная разработка программного обеспечения).

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

Риски самостоятельной разработки бизнес-приложений

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

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

Бизнес-требования

Большинство бизнес-правил обнаруживаются в процессе накопления требований. При этом появляется естественное желание добавить еще одну секцию в описания сценариев использования и в нее добавлять бизнес-правила. Однако если бизнес-правило по своему существу не принадлежит к функции, описанной сценарием использования, то оно обычно охватывает несколько сценариев. Так в приведенном выше примере бизнес-правило 10 000 долларов будет охватывать сценарии «Вложение наличных денег» и «Снятие наличных денег».

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

Простой способ планирования

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

Однако большинство бизнес-правил представляет собой простую проверку достоверности, например, обеспечение соответствия почтовых индексов с индексами, имеющимися у штатов США. Мы часто игнорируем бизнес-правила такого сорта, пока пишем сценарии использования, поскольку они — всего лишь незначительная подробность проверки адресов. Впрочем, существует специальное место, где устанавливаются и такие ограничения. Логично предположить, что все они принадлежат классу «Адреса» на диаграмме классов. Размещая бизнес-правила в соответствующем классе на диаграмме классов, мы гарантируем, что эти правила будут многократно использоваться во всех сценариях точно таким же образом, как и класс, к которому они принадлежат, в модели сценариев использования.

Типы правил

В общем случае существует три типа правил. К первому типу принадлежат правила вывода [Francis 2003]. Правило вывода (derivation rule) преобразует полученную информацию в возвращаемые значения. Например, скидки на товары можно вычислить с помощью специального алгоритма, учитывающего размер заказа, рекламную поддержку и значимость клиента, которому будут поставляться товары. Правила этого типа допускают изменения, и поэтому, прежде чем с ними можно было работать, их требуется выделить.

Второй тип правил — правила ограничения [Francis 2003]. Правило ограничения (constraint rule) проверяет значения транзакции или операции на непротиворечивость. Например, чтобы заказчик получил письмо, почтовый индекс на письме должен соответствовать индексу штата, в котором проживает заказчик.

Эти правила могут использоваться для изучения взаимосвязей между объектами, например, когда все клиенты имеют адресующие объекты в интернет-магазине видеоаппаратуры. Кроме того, они могут применяться вместе с Булевыми результатами. Если они не истинны, то мы не сможем продолжить или завершить операцию.

Наконец, существуют инвариантные правила [Francis 2003]. Инвариантные правила (invariant rules) проверяют множественные изменения и обеспечивают непротиворечивость итоговых результатов. Например, баланс сберегательного счета должен быть равен предыдущему балансу плюс сумма прихода или минус сумма расхода. Если у вас что-то не сходится, значит, ваша система теряет деньги, и пришло время поднять исключение на более высокий уровень.

Рис. 1. Быть работником (employee) как сотрудничество

Эти правила могут относиться как к свойствам, так и к сотрудничествам [Nicola 2002]. Нередко свойства одной системы являются сотрудничествами другой. Например, если одна система может моделировать идею «быть работником», исходя из сотрудничества (см. рисунок 1), то другая система может моделировать эту же идею, исходя из свойства (см. рисунок 2). Реализация (implementation) является независимым типом правил.

Изображение правил

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

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

Рис. 2. Быть работником (employee) как атрибут

Реализация

Большинство продуктов с модельной архитектурой Model Driven Architecture (MDA) использует язык OCL для порождения программной логики. При разработке приложений в среде MDA важную роль играет преобразование бизнес-правил в ограничения на диаграммах класса. Эта логика преобразуется с языка OCL платформенно-независимой модели (Platform Independent Model, PIM) на язык высокого уровня платформенной модели (Platform Specific Model, PSM). Платформенная модель может быть языком программирования, таким как Java, C#, C++ или Delphi.

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

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

Заключение

Живой бизнес требует гибких, расширяемых систем, которые могут оперативно реагировать на изменения деловой конъюнктуры. Сегодняшняя скидка завтра может оказаться премией. Моделирование и выделение бизнес-правил — необходимая часть разработки такой среды. Моделирование обеспечивает проверку бизнес-правил на достоверность еще до создания системы. Технология UML поддерживает моделирование бизнес-правил с помощью сценариев использования и диаграмм класса.

Библиография

[Francis 2003] Francis, Tim, et al. Professional IBM WebSphere 5.0 Application Server, Wrox, 2003

[Nicola 2002] Nicola, Jill, Mark Mayfield, and Mike Abney, Streamling Object Models, Prentice Hall, 2002 Фрагмент в The Coad Letter 89

[1] Unified Modeling Language (Унифицированный язык моделирования)

Ссылки по теме

Статьи по средствам разработки ПО
Статьи по средствам моделирования (CASE)
Обратиться в Interface Ltd. за дополнительной информацией/по вопросу приобретения продуктов

10.2003

Источник: www.interface.ru

Простое управление бизнес-правилами (Business Rules Management)

Бизнес-правила (Business Rules Management) — это методические указания, которые обеспечивают правильность принятых решений при выполнении задач за счет того, что, устанавливают четкий порядок действий для заранее известных условий.

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

Большинство решений, принимаемых в бизнесе, не столь драматичны, но от это они не перестают быть менее комплексными. Даже бизнес-процесс найма сотрудников подразумевает несколько сценариев. Может ли чат-бот ответить на вопросы соискателя или нужна консультация HR-менеджера? Если HR-менеджер вынужден вмешаться, какие действия он должен совершить? Как соискатель и сотрудник отдела кадров должны взаимодействовать друг с другом, чтобы прийти к обоюдовыгодному результату?

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

Основой автоматизации выступают бизнес-правила — BRM (Business Rules Management). Для моделирования таких правил существуют специальные методологии и системы, т.н. BRMS (Business Rules Management Systems). Международный консорциум OMG даже предложил свой стандарт для описания бизнес-правил на основе семантики естественного языка — Semantics of Business Vocabulary and Business Rules.

Как бизнес-правила устроены изнутри?

С формальной точки зрения бизнес-правила состоят из двух элементов:

Условия— описывают ситуацию, в которой нужно предпринять определенные действия.
Действия— описывают, что должно произойти в ответ на заданные условия.

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

условия — сумма товаров в корзине меньше 1000 рублей;
действия — оформить платную доставку.

условия — сумма товаров в корзине больше 1000 рублей;
действия — оформить бесплатную доставку.

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

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

Поэтому появилась потребность в отдельных системах или инструментах для создания бизнес-правил с учетом их повторяемости, достоверности и применимости в системах автоматизации. Достоинство Comindware Business Application Platformкак раз в том, что платформа поддерживает функциональность систем для управления бизнес-правилами на уровне сценариев. Их можно создавать в простом визуальном редакторе.

Что такое BRMS?

BRMS — это система, которая управляет бизнес-правилами. Система упрощает поддержку полного жизненного цикла таких правил, начиная от проектирования и хранения до управления изменениями на уровне бизнес-архитектуры.. Когда чаще всего используют отдельную BRMS? Вот несколько типовых ситуаций.

самописные решения— не все BPMS поддерживают инструменты для работы с бизнес-логикой. Camunda — это по сути один процессный движок для программистов, к нему нужно еще добавить базу данных и процессную логику. Каждый раз переписывать строки кода, чтобы изменить алгоритм принятия решений, неудобно, поэтому можно взять готовый инструмент из репозитория.
«лоскутная автоматизация»— функции автоматизации выполняют разные системы — CRM, SRM, RPA и далее по списку. Если логика процесса изменилась, то программисту придется лезть в каждую из этих систем по отдельности, что тоже неудобно.
«убийственная сложность»— бизнес-правил может быть банально слишком много, как в случае с тем же андеррайтингом и скорингом, тогда не имеет смысла прятать бизнес-логику глубоко в программный код.

BRMS часто выступают в связке с BPMS, и еще в 2012 году считалось, что одно невозможно без другого. BPMS служили для проектирования процессов, а BRMS использовались для автоматизации отдельных задач. В Comindware Business Application Platform BRM изначально является частью платформы. Все сценарии автоматизации рассматриваются в контексте сквозных бизнес-процессов, а элементы управления бизнес-логикой реализованы в том числе на уровне Low-code настроек.

Преимущества Low-code автоматизации

В Comindware Business Application Platform бизнес-правила можно создавать без навыков программирования с помощью инструмента «Сценарии». Поэтому уже на этапе создания MVP, часть задач можно автоматизировать на основе алгоритмов, созданных самими пользователями.

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

BRM и пользователи-вандалы

Логично услышать возражение от ИТ-отдела:«А что если пользователи возьмут и все сломают. Ведь у нас бизнес-правила действуют по всей организации, поэтому меняя их только на локальном участке можно разрушить вообще всю бизнес-архитектуру». В этом есть доля правды, но Comindware Business Application Platform рассчитана на автоматизацию сквозных бизнес-процессов, за которые раньше отвечали разные системы. Это позволяет постепенно отказаться от BRMS (хотя бы на некоторых участках) и не хранить бизнес-правила отдельно от процессов. Вы можете сразу изменить алгоритм автоматизации и, протестировав процесс от начала до конца, увидеть результат.

В таком случае локальные изменения будут менее критичными, но более предсказуемыми и контролируемыми. В то же время ИТ-отдел сохраняет контроль над изменениями на уровне пользовательских ролей. Вы сами решаете, кому из сотрудников можно редактировать бизнес-правила.

Сделайте автоматизацию более прозрачной и управляемой с помощью Comindware Business Application Platform

Елена Гайдукова, маркетолог-аналитик. Работает в сфере BPM и автоматизации процессов с 2014 года. В настоящее время является бренд-менеджером решений на базе Comindware Business Application Platform.

Источник: www.comindware.ru

Анализ бизнес-правил: техника BABOK®Guide для документирования операций и разработки требований

В этой статье рассмотрим, что такое бизнес-правила, какие они бывают, зачем их определять, анализировать и документировать при описании процессов, а также спецификации требований. Анализ бизнес-правил как техника BABOK®Guide и метод фиксации особенностей предметной области при разработке технического задания (ТЗ).

Что такое бизнес-правила: определение BABOK®Guide и примеры

Анализ бизнес-правил является одной из 50 техник BABOK®Guide и используется для выявления, определения, описания, проверки и организации ежедневных операций, а также условий принятия операционных решений. Если бизнес-правила являются основанием для принятия решений, с ними можно дальше работать в технике «Моделирование решений», структурировав в виде таблицы или дерева, что мы рассматриваем в отдельной статье. А сегодня сфокусируемся именно на технике «Анализ бизнес-правил» (Business Rules Analysis).

Бизнес-правила не стоит путать с организационными (деловыми) политиками, область действия которых шире чем у правил и направлена больше на предприятие в целом, чем на отдельные процессы и управленческие решения. Бизнес-правило— это конкретная проверяемая директива как условие или критерий управления поведением/процессом или принятия рутинных (операционных) решений. Оно всегда практически осуществимо, контролируемо и не требует дополнительной интерпретации для применения в бизнесе. BABOK выделяет 2 категории бизнес-правил:

определительные, которые относятся не к людям, а отражают операционные знания организации. Например, обращения привилегированных клиентов получают наивысший приоритет. Определительные бизнес-правила невозможно нарушить, но можно неправильно применить. При разработке функциональных требований и их спецификации в ТЗ или SRS такие правила являются основанием для вычислений и изменения поведения/состояний объектов в ходе бизнес-процессов. Например, атрибуту «Статус» объекта «Клиент» задать значение «Привилегированный», если значение атрибута «Сумма заказа» больше 1 млн.
поведенческие, которые относятся к людям, даже если их поведение автоматизировано. Они используются для организации и регулирования ежедневной деятельности в качестве обязательств или запретов на способы выполнения операций, действия, практики или процедуры. Часто поведенческие бизнес-правила закреплены в политики организации для снижения рисков или повышения продуктивности. Они могут использовать информацию из определительных правил, чтобы направлять действия людей, обязывая их решать рабочие задачи определённым образом, запрещать какие-то действия или описывать условия корректного выполнения процессов и процедур. Поскольку поведенческие бизнес-правила относятся к людям, они могут быть нарушены. Например, обращение привилегированного клиента должно быть обработано оператором в течение 1-го часа после его поступления независимо от дня недели и времени суток.

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса

TTIS

Ближайшая дата курса

24 июля, 2023

Длительность обучения

12 ак.часов

Стоимость обучения

20 000 руб.

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

Как анализировать бизнес-правила: рекомендации BABOK®Guide

BABOK отмечает, что техника анализа бизнес-правил включает следующие действия:

сбор из явных и неявных источников(организационные регламенты и другие внутренние документы, договоры, контракты, деловые политики, отраслевые стандарты, эксперты предметной области и другие стейкхолдеры, а также негласные, но общепринятые практики и нормы корпоративной культуры);
описаниев виде текстовых определений (для определительных бизнес-правил) или наглядных схем бизнес-процессов в формальных нотаций моделирования (IDEF0, BPMN, EPC или UML) для поведенческих бизнес-правил;
валидация описанных бизнес-правил, т.е. их проверка на соответствие реальности со стейкхолдерами, которые могут это подтвердить или опровергнуть;
уточнениеописанных и проверенных бизнес-правил, чтобы они лучше соответствовали реальности и бизнес-целям;
организацияописанных и проверенных бизнес-правил так, чтобы их было удобно использовать и администрировать по мере необходимости, т.е. изменять, создавать их новые версии, выводить из эксплуатации (объявлять устаревшими).

Все эти действия направлены на то, чтобы сделать бизнес-правила явными, конкретными, ясными, доступными и централизованными. Если по результатам сбора информации из явных и неявных источников бизнес-аналитику необходимо сформулировать правило самостоятельно, BABOK®Guide рекомендует придерживаться следующих принципов:

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

Таким образом, можно сказать, что бизнес-правила являются своеобразной структурой регулирования поведения, а их ясное определение и администрирование позволяет организации корректировать свои деловые политики без изменения процессов или систем. Однако, если бизнес-правил слишком много, они описаны некорректно, сформулированы непонятно, не соответствуют действительности или противоречат друг другу, то ценность этого артефакта невелика. Впрочем, одной из рабочих обязанностей бизнес-аналитика является как раз наведение порядка в бизнес-правилах. Однако, разработка и улучшение организационных регламентов с помощью анализа бизнес-правил – не единственное приложение этой техники BABOK. BABOK®Guide рекомендует применять ее для решения следующих задач:

планирование вовлечения стейкхолдеров из области знаний «Планирование и мониторинг бизнес-анализа»;
проведение выявления из области знаний «Выявление и сотрудничество»;
поддержание требований из «Управление жизненным циклом требований»;
оценка изменений требований из «Управление жизненным циклом требований»;
спецификация и моделирование требований из области знаний «Анализ требований и определение дизайна»;
оценка ограничений решения из области «Оценка решения».

Как именно бизнес-правила связаны со спецификацией требований в ТЗ и SRS мы рассмотрим далее.

Источник: babok-school.ru