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

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

Рисунок 3. Пример настройки типов требований и их атрибутов

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

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

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

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

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

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

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

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

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

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

За всеми этими настройками и операциями в инструменте есть один существенный вопрос – кто это все должен делать? Исходя из своего опыта – могу сказать: бизнес-аналитики существа возвышенные и достаточно далекие от скрипто-писательства или сложных настроек в моделях. Поэтому для эффективной работы с расширением возможностей PowerDesigner в команде необходим человек с техническим бекграундом, например, системный аналитик или архитектор, который хорошо владеет или способен в короткие сроки разобраться со спецификой системы. Без такого человека вряд ли удастся гибко подстраивать методологию и технологию работы команды под возникающие в проекте изменения и вызовы.

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