Предупрежден, значит вооружен: топ - 4 ошибок при проектировании хранилищ данных и BI-проектов
Хранилища данных и BI проекты имеют определяющее значение для многих организаций, стремящихся расширить возможности принятия более эффективных решений и действий.
Проекты хранилищ данных очень сложные и рискованны. Среди многочисленных задач руководители проектов, возглавляющие команду по разработке хранилища данных, должны определить все риски, связанные с качеством данных. Основная цель - задокументировать важную информацию, связанную с риском при подготовке и реализации проекте.
Эта статья посвящена тому, как избежать четырех распространенных ошибок, с которыми столкнулись другие проекты по построению хранилищ данных и BI, чтобы Вы смогли спланировать и с успехом внедрить новые функции и возможности.
Неспособность внедрить на ранних стадиях проекта контроль качества
На ранних этапах проектов хранилищ данных/BI основное внимание уделяется требованиям BI и потребностям, связанным с данными, для создания операционного/корпоративного хранилища данных и инфраструктуры отчетности приложений. Почему-то важность сквозного тестирования проектов хранилищ данных и качества данных часто упускается из вида.
Нет сомнений, качество данных ценится всегда. Тем не менее, повышенное внимание к моделированию данных, их сбору, проектированию ETL может привести к тому, что фокус с качества данных сместится, что станет причиной возникновения таких проблем как:
- Целевые данные не совместимы с источниками.
- Изобилие дублируемых данных.
- Агрегирование и детализация отчетов неверны.
Успех хранилища данных зависит от способности планировать, проектировать и применять набор тестов, позволяющих выявлять ранние и текущие проблемы, связанные с несоответствием данных, качеством данных, безопасностью, процессом ETL, точностью, опытом конечного пользователя.
Многие команды DW спорят о том, когда же начинать тестирование при разработке нового программного обеспечения. Для многих проектов DW тестирование ПО должно начинаться сразу же, как только будут определены требование и структура проекта. Раннее начало проверки качества предоставляет несколько преимуществ, которые повысят общую эффективность тестирования ПО. Участие команды QA в начале проекта делает работу тестировщиков более эффективной, так как позволяет им узнать о тестируемом продукте и бизнес-правилах. Это поможет им спроектировать лучшие планы тестирования и тестовые случаи.
На этапе проектирования и определения требований, тестировщики могут работать с разработчиками для определения тестируемых аспектов и областей с высоким риском. Эти знания помогут предотвратить ошибки во время тестирования и лучше вооружить тестировщиков для проектирования тестовых случаев и определения дефектов.
Успешная реализация проекта DW - трудная задача. Она требует соблюдения баланса многих факторов таких, как сильная вовлеченность бизнеса, тщательный анализ данных, масштабируемая система, архитектура данных, комплексная программа, управление данными, высокое качество данных, использование стандартов и процессов, отличная коммуникация и управление проектом.
Отсутствие должного профилирования и проверки достоверности исходных данных перед загрузкой в хранилище
Несоответствующее качество исходных данных - это корень неудач во многих проектах по созданию хранилищ данных. Профилирование и подтверждение всех исходных данных предоставляют значительные преимущества.
Традиционный подход к проектам DW придерживается нескольких основных шагов:
- Анализ бизнеса, пользователя и технических требований к проекту.
- Анализ имеющихся внутренних и внешних источников данных.
- Определение и анализ источников данных из унаследованных систем, операционных систем и внешних источников для определения их релевантности требованиям целевой базы данных.
Главный недостаток традиционного подхода: он подразумевает, что данные, необходимые для приложения, полностью доступны из источников данных. Крупные корпорации потратили миллионы долларов на проекты интеграции данных только для того, чтобы позже узнать, что их исходные данные не поддерживали целевую модель. Профилирование данных должно быть проведено для каждого источника: анализ таблиц, строк и столбцов, кросс-табличный анализ, оценка первичного и внешнего ключей. Профилирование исходных данных должно рассматриваться для обнаружения минимума, максимума, режима, процентилей и повторяющихся значений.
Недостаточное внимание к автоматизации тестирования
С появлением DevOps для работы с хранилищами данных организации выпускают новые приложения быстрее, чем когда-либо. Тем не менее многие компании до сих пор используют ручное тестирование для процессов ETL для клиент-ориентированных приложений. Даже с появлением новых автоматизированных инструментов, тестирование ETL и профилирования данных продолжает осуществляться в основном в ручном режиме.
Автоматизация ETL-тестов позволяет проводить дымовое и регрессионное тестирование без особого вмешательства пользователя. Автоматизированное тестирование доверенного кода после каждой сборки нового хранилища может сэкономить время и деньги.
Решение о внедрении автоматизированных инструментов тестирования зависит от бюджета на дополнительные расходы для удовлетворения требований к тестированию. Если внедрение автоматизации тестирования крайне затратно, важно рассмотреть средства тестирования, созданные и обслуживаемые собственными силами, т.к. они будут иметь значительное преимущество, чем отсутствие автоматизации тестирования вообще.
При разработке сценариев автоматизации тестирования оцените полный набор тестовых сценариев для определения наилучших результатов для автоматизации на основе риска и ценности (ROI): какие типы дефектов могут привести к остановке интеграции или развертывания? Какие типы тестов проверяют критическую, основную функциональность? Какие тесты покрывают области приложений, исторически известные как неудачные? Какие тесты предоставляют информацию, не охваченную другими тестами в конвейере?
Автоматизация тестирования сэкономит время и деньги, и что более важно, бизнес-пользователи оценят качество результатов BI и примут решение, исходя из данных, как единственную версию правды.
Внедрение некорректных средств управленческого контроля изменения проекта
Изменения - постоянный процесс в любом проекте DW. Независимо от отрасли, появляется новые требования. Стремление к постоянному совершенствованию обычно приводит к изменениям объема работ по проектам или результатов.
Управление изменениями - важный компонент успеха инициатив, связанных с DW. Согласно опросу Forrester Global BI Maturity Survey более половина опрошенных, считают, что их управление изменениями не достаточно хорошо отлажено и не функционирует гладко.
Тестировщикам необходимо ссылаться на документы, участвующие во всех изменениях, такие как бизнес-требования, проектные и технические спецификации, документы сопоставления данных и т.д. Способность идентифицировать и связать эти документы с изменениями и подготовить план тестирования - важные моменты в эффективном обеспечении качества.
Изменения для BI часто исходят из различных источников, включая собственников бизнеса или других заинтересованных сторон и влияния изменений исходной системы. Команда QA должна участвовать в регистрации, управлении изменениями, расстановке приоритетов и обновлении, а затем гарантировать, что все изменения проверены. Если в вашей организации уже есть инструмент отслеживания изменений, неплохо воспользоваться им.
Проекты хранилища данных и BI / аналитики, как правило, выделяют бюджетные средства на технологии и их внедрение, но управление изменениями и мероприятия по внедрению после выпуска часто недофинансируются или даже полностью игнорируются.
Когда ваша организация развертывает проект хранилища данных, шансы на успех значительно повышаются, если управление изменениями является неотъемлемой частью.
В заключении
Ошибки, описанные здесь, направлены на то, чтобы помочь организациям избежать проблем контроля качества, с которыми столкнулись многие компании при проектировании хранилищ данных. Эти проверенные временем рекомендации помогут сэкономить деньги, время, кадровые ресурсы и улучшить результаты разрабатываемого приложения хранилища данных.