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

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

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

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

Пример.

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

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

• ЕСЛИ

• ТОЛЬКО ЕСЛИ

• КОГДА

• ТОГДА

• ЕЩЕ

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

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

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

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

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

3. Технологический процесс управления требованиями.

3.1. Цели управления требованиями.

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

В контексте Rational Unified Process управление требованиями является одной из девяти дисциплин, определенных в рамках процесса. Как и для любой другой дисциплины технологическому процессу управления требованиями присущи цели, структура работ, обязанности, налагаемые на задействованных в процессе исполнителей, и артефакты, подлежащие созданию и актуализации.

Технологический процесс управления требованиями призван:

• сформировать единое мнение у заказчиков и пользователей о том, что должна делать система;

• предоставить разработчикам системы наилучшее понимание требований к системе;

• определить границы системы;

• создать базу для планирования технического содержания итераций при работе над проектом;

• создать базу для оценки времени и стоимости реализации проекта;

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

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

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