Ни для кого не секрет, что грамотно написанные и однозначно трактуемые требования – это первый шаг к успешной реализации любого проекта. Инициативы, связанные с созданием BI-системы, не являются исключением. Однако всегда следует помнить, что одним из возможных путей к «правильным» требованиям может быть их тестирование.
Взглянув на диаграмму, сразу становится очевидным, как важно начать тестирование именно с требований. Цена пропущенной ошибки возрастает экспоненциально с каждым этапом развития проекта, нарастая как снежный ком.
Полагаю, ни для кого не будет открытием, что возможность избежать дополнительных трат – далеко не единственный аспект, который следует учитывать при планировании тестирования BI-проекта. В качестве примера рассмотрим систему здравоохранения. Хранилища данных и BI-системы широко используются при диагностике болезней, назначении лечения и рекомендаций по применению лекарств. Как следствие, в данном случае незамеченная ошибка может привести к дезинформации медперсонала, которая спровоцирует их на неправильные действия и в результате приведет к ухудшению состояния или даже смерти пациента! Весьма наглядные риски существуют и в финансовой сфере. BI-система, разработанная для финансового учреждения, может иметь множество вариантов использования, начиная от отслеживания операций по карточкам и заканчивая перераспределением огромных сумм денег между счетами. Легко представить к чему может привести некорректная информация. В лучшем случае, к вам поступит звонок от недовольного клиента, а в худшем – миллионные иски и уголовная ответственность.
Учитывая примеры, приведенные выше, а также используя опыт, приобретенный за годы работы на BI проектах, я пришла к выводу, что очень важно иметь требования не только в виде описательных документов. Они должны быть дополнены множеством сопутствующих артефактов. Для BI проектов такими артефактами могут быть следующие документы:
— таблицы, которые описывают правила трансформации между источниками данных и итоговыми таблицами, а также специфику отдельных ETL процессов (так называемые STT – Source-To-Target Mappings);
— различные диаграммы (ERD, Data flow);
— матрицы (Requirements Traceability Matrix, Bus Matrix);
— другие дополнительные документы.
Хорошей практикой является детальная проработка начальных требований различными специалистами с последующим сравнением полученных результатов. Это помогает найти двусмысленные или неоднозначные формулировки в требованиях. И, как следствие, своевременно прийти к единой трактовке, которая будет донесена всем участникам проекта. Иными словами, тестируя и проверяя требования под разными углами, мы сможем обнаружить и разрешить большинство ошибок и неясностей еще до начала этапа реализации. Помимо двусмысленности можно разрешить следующие проблемы:
— Выявить неполноту требований;
— Уточнить ошибочные трансформации;
— Согласовать противоречивые требования.
В качестве инструментов мы можем использовать широкий набор приложений. К примеру, для создания ERD диаграмм хорошо подойдет Enterprise Architect. Помимо этого, никто не отменял обширные возможности MS Excel для анализа и детальной проработки требований.
Когда имеешь дело с BI проектом, то начальные требования, как правило, описывают лишь отчеты, которые требуется создать. Поэтому очень важно (и трудоемко) проверить полноту, точность и согласованность предоставленных требований в преломлении на специфику хранилища данных, сопутствующих ETL процессов и затронутых источников данных.
Резюмируя, хочется еще раз сказать, что, по моему глубокому убеждению, грамотно составленные требования — это как минимум 50% успеха всего проекта. Такие требования создают прочный фундамент для всех последующих этапов развития проекта, начиная от проработки модели данных и заканчивая созданием плана тестирования ETL процессов.
Алена Башмакова, Business Intelligence/Data Warehouse Consultant
