Управление большими объемами требований в BI-проектах

23 июль, 2012 - 16:15Дмитрий Зиновьев

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

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

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

Как правило, BI-системы создаются с использованием ряда промышленных инструментов для обработки данных и представления их конечному пользователю. Такие инструменты, как например, SAP Business Objects Edge BI, IBM Cognos BI, MicroStrategy обеспечивают наличие в созданной системе развитого и стабильного пользовательского интерфейса с фиксированным набором функциональных возможностей и технических параметров, которые не требуют дополнительной проработки в ходе проекта.

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

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

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

Управление большими объемами требований в BI-проектах

Рисунок 1. Виды требований и их взаимосвязи

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

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

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

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

На рынке представлено несколько достаточно удачных инструментов управления требованиями, которые обладают более или менее равноценными возможностями. Тем не менее, Power Designer от SAP Sybase можно выделить на фоне остальных за счет развитого и удобного пользовательского интерфейса и возможностей по широкой настройке состава объектов и атрибутов. Наиболее, полезной и уникальной возможностью является действительно полноценная интеграция моделей для управления требованиями, проектирования баз данных и ряда других, достаточно полезных моделей. Речь идет о возможности перейти непосредственно от объекта требований к таблицам и атрибутам в логической или физической модели данных, на которых базируются требования.

Управление большими объемами требований в BI-проектах

Рисунок 2. Просмотр свойств сущности в концептуальной модели данных, связанной с исходным требованием

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