ГЛАВА 3 – Методология Data Vault 2.0

Аннотация

Методология Data Vault 2.0 представляет собой уникальный подход к разработке хранилищ данных и основана на нескольких гибких методологиях и техниках построения хранилищ данных, включая CMMI, Six Sigma, TQM, SDLC и анализ функциональных точек (Function Point Analysis). В этой главе рассматриваются основы этих стандартов и объясняется, как методология Data Vault 2.0 объединяет их.

Основное внимание в главе уделяется практическим аспектам ведения проектов в рамках методологии Data Vault 2.0.

Ключевые слова

• данные
• CMMI
• Six Sigma
• TQM
• SDLC
• анализ функциональных точек
• методология

Стандарт Data Vault 2.0 представляет собой наилучшую практику управления проектами, называемую «методология Data Vault 2.0». Она основана на ключевых стандартах разработки программного обеспечения и адаптирует их для использования в области хранилищ данных. На Рисунке 3.1 показаны стандарты, которые повлияли на формирование методологии Data Vault 2.0.

Рисунок 3.1 Компоненты методологии Data Vault 2.0

Объединяя эти стандарты, методология Data Vault 2.0 становится одной из лучших практик управления проектами в сфере хранилищ данных. Для координации работы команды и выполнения повседневных задач проекта применяется Scrum. В рамках двух- или трехнедельного спринта команда использует мини-водопад, основанный на жизненном цикле разработки программного обеспечения (SDLC). Целью такого подхода является завершение всех необходимых поставляемых компонентов по итогам итерации, чтобы они могли быть внедрены в промышленную эксплуатацию.

Методы управления проектами из PMI Project Management Body of Knowledge (PMBOK), признанные в сертификации Project Management Professional (PMP), используются для определения и выполнения проектного плана на физическом уровне проекта.

Capability Maturity Model Integration (CMMI) применяется для общего управления и контроля проекта, а также используется при проведении обзоров и сессий по улучшению процессов.

Всеобщее управление качеством (TQM) реализуется в рамках замкнутого цикла, обеспечивая непрерывное улучшение как самого процесса, так и обрабатываемых данных. Когда бизнес-пользователи участвуют в согласовании наборов данных из разных источников и исправлении ошибок в системах-источниках, они следуют принципам TQM. В разделе 3.3.2 мы обсудим, почему такой подход требует большего числа мероприятий по сравнению с традиционными методами управления качеством данных (DQ).

Принципы и правила Six Sigma применяются для достижения максимальной оптимизации и гибкости в процессе построения и внедрения хранилищ данных в стиле Data Vault 2.0. Этот процесс основан на метриках (сравнение оценок с фактическими значениями) и ключевых показателях эффективности (KPI), которые рассматриваются в разделе 3.1.4.

Методология Data Vault 2.0 состоит из трех основных видов деятельности, в рамках которых применяются методы, представленные на Рисунке 3.1:

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

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

Планирование проекта

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

Методология Data Vault 2.0 заимствует свои возможности по планированию проектов из PMP. В отличие от гибкой методологии Scrum, в Data Vault 2.0 делается акцент на наличие формального плана проекта в рамках спринта. Каждый проект имеет проектный план, который включает:

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

В зависимости от типа проекта роли могут различаться. Ниже приведен список ролей и их обязанностей:

• Бизнес-спонсор (Business Sponsor): Бизнес-спонсоры должны обеспечивать соответствие проекта бизнес-целям и культурным целям организации; представлять проект, особенно перед высшим руководством; быть его ключевыми защитниками и привлекать к нему внимание других ключевых заинтересованных сторон; организовывать ресурсы для обеспечения успешности проекта; способствовать решению проблем, обеспечивая их эскалацию на уровень организации для эффективного устранения; поддерживать руководителя проекта, оказывая менторскую, коучинговую и лидерскую поддержку; а также создавать устойчивость результатов проекта, чтобы обеспечить их долгосрочную применимость.
• Технический бизнес-аналитик (Technical Business Analyst): Технические бизнес-аналитики устанавливают стандарты и списки управления доступом; приоритизируют запросы на изменения; определяют новые требования; создают новые отчеты для широкой аудитории бизнес-пользователей; помогают команде в отладке альфа-версий; участвуют в разработке и проектировании информационных витрин; а также создают учебные материалы для пользователей. Технический бизнес-аналитик является продвинутым пользователем, который подчиняется бизнесу, но обладает техническими навыками, включая понимание моделей данных и способность использовать или писать SQL напрямую.
• Руководитель проекта (Project Manager): Эта роль отвечает за то, чтобы команда проекта завершила выполнение проекта. Руководитель проекта разрабатывает план проекта, управляет выполнением проектных задач командой и обеспечивает принятие и одобрение результатов проекта со стороны спонсора и других заинтересованных сторон. Кроме того, данная роль отвечает за коммуникацию, включая отчеты о статусе, управление рисками и эскалацию проблем, которые не могут быть решены внутри команды проекта.
• ИТ-менеджер (IT Manager): Менеджеры информационных технологий (IT) обеспечивают непрерывность бизнеса и его успешность. По этой причине они курируют проекты и следят за эффективным использованием ресурсов. IT-менеджеры объективно консультируют руководство по вопросам того, где IT может принести пользу бизнесу; согласовывают затраты, сроки и стандарты, которым необходимо соответствовать, а также контролируют их выполнение в ходе проекта; помогают организации плавно переходить от устаревших систем к новым; и держат руководство в курсе хода текущих проектов.
• ETL-разработчик (ETL Developer): Участники команды, назначенные на роль Extract, Transform, Load (ETL), реализуют процессы загрузки данных и управления потоками данных, включая загрузку данных из систем-источников в промежуточное хранилище (staging), из промежуточного хранилища в структуры Data Vault, а затем в Business Vault и информационные витрины. Они также отвечают за создание виртуальных витрин данных или реализацию «мягких» бизнес-правил в ETL по запросу бизнеса.
• Разработчик отчетов (Report Developer): Разработчики отчетов создают отчеты, ориентированные на бизнес, на основе информационных витрин, таблиц Business Vault или (в редких случаях) напрямую на Raw Data Vault. В большинстве случаев им не требуется реализовывать бизнес-правила для этой задачи, однако в редких случаях создание бизнес-отчета может потребовать реализации ограниченного количества бизнес-правил прямо в отчете. Это следует избегать, так как это негативно сказывается на производительности и снижает возможность повторного использования.
• Архитектор данных / Архитектор информации (Data Architect / Information Architect): Архитекторы информации (в отрасли они известны как архитекторы данных, однако, по нашему мнению, этот термин вводит в заблуждение, так как они должны работать с информацией, а не только с данными; см. Главу 2, Масштабируемая архитектура хранилища данных) отвечают за информационную архитектуру и интеграцию данных.
• Менеджер метаданных (Metadata Manager): Эта роль отвечает за планирование проектирования метаданных; обеспечивает основу для разработки метаданных; координирует деятельность и коммуникацию с другими ролями и проектами; управляет уровнями доступа к метаданным для всех участников и внешних сотрудников, которым требуется работать с метаданными.
• Менеджер изменений (Change Manager): Менеджер изменений гарантирует, что новая функциональность не приведет к сбоям в других ИТ- или бизнес-сервисах при развертывании. Также эта роль отвечает за обеспечение возможности развертывания в рабочей среде и за предотвращение блокировки развертывания другими проектами.

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

Большинство представленных ролей уже известны проектным командам, работающим с хранилищами данных. Исключением является технический бизнес-аналитик. Эта роль выполняет промежуточную функцию между бизнесом и IT. Характеристики и дополнительная информация об обязанностях данной роли представлены на Рисунке 3.2.

Рисунок 3.2 Характеристики и обязанности технического бизнес-аналитика

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

Именно поэтому в командах Data Vault 2.0 рекомендуется не разделять бизнес и IT-ролей. Вместо этого обе группы должны работать совместно, сосредотачиваясь на своих обязанностях. Если возможно, команда должна быть расположена в одном месте, чтобы повысить эффективность. Важно создать уровень сотрудничества и взаимопонимания между бизнесом, IT и каждой индивидуальной ролью, чтобы избежать ситуаций, описанных в предыдущем абзаце. Это является обязанностью руководителя проекта и требует постоянных действий, если группы начинают отдаляться друг от друга по ходу проекта.

Часть необходимого взаимопонимания со стороны бизнеса заключается в осознании того, что IT-команда должна иметь возможность работать без постоянных отвлечений на повседневные проблемы в течение своих двухнедельных спринтов. Вопросы, возникающие в операционной деятельности, должны быть запланированы на один из следующих спринтов. Для достижения этого IT также должно изменить свое мышление: их задача — не просто решать проблемы бизнеса, а создавать условия, при которых бизнес сможет решать часть, а в идеале большинство своих проблем самостоятельно, без вовлечения IT. Именно здесь на первый план выходит концепция «управляемого» (managed) самообслуживания в бизнес-аналитике (BI).

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

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

Рисунок 3.3 Определенные процессы, показывающие каналы коммуникации в методологии Data Vault 2.0

Новые запросы на изменения часто исходят от бизнес-стороны проекта. IT необходимо оценить риски и влияние на текущую систему в продакшене. Поэтому запросы на изменения проходят через следующих участников:

бизнес-пользователей → спонсора проекта (который определяет приоритетность запросов) → технического бизнес-аналитика (который помогает перевести бизнес-требования в технические термины) → IT-менеджера и руководителя проекта (которые отвечают за планирование).

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

Когда разрабатываются новые релизы системы хранилища данных, команды разработки используют тот же подход, что и в традиционной разработке ПО. Они выпускают Alpha-версии для раннего тестирования, Beta-версии для тестирования на ограниченной бизнес-аудитории и Gamma-версии для продакшена. Alpha-релизы должны затрагивать только технических участников команды, включая технического бизнес-аналитика, как показано на Рисунке 3.4.

Рисунок 3.4 Зона охвата Alpha-релиза в методологии Data Vault 2.0

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

Обычно Alpha-релиз распространяется среди технических бизнес-аналитиков после первых двух или трех спринтов проекта хранилища данных.

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

Рисунок 3.5 Зона охвата Beta-релиза в методологии Data Vault 2.0

Beta-релиз был тщательно протестирован IT-отделом и представителями бизнеса и больше не содержит явных или известных ошибок. Однако сгенерированные отчеты все еще не предназначены для распространения, поскольку релиз находится в промежуточном состоянии. Вместо этого отчеты используются ограниченной командой для выявления проблем, которые до сих пор не были обнаружены в процессе разработки и тестирования техническими бизнес-аналитиками. Если ограниченная команда соглашается с тем, что релиз готов к продакшену, система хранилища данных переходит в Gamma-стадию, как показано на Рисунке 3.6.

Рисунок 3.6 Зона охвата Gamma-релиза в методологии Data Vault 2.0

Gamma-релиз (или продакшен-релиз) развертывается и становится доступным для всех бизнес-пользователей. Этот подход тесно связан с CMMI, который является частью методологии Data Vault 2.0.

Capability Maturity Model Integration

Capability Maturity Model Integration (CMMI) — это модель улучшения процессов, разработанная более 20 лет назад и управляемая Институтом программной инженерии (SEI) при Университете Карнеги-Меллона (США). CMMI спонсируется правительством США (в частности, Министерством обороны США) и используется организациями всех размеров по всему миру. Данная модель помогла оптимизировать затраты, сократить доработки и уровень дефектов, а также улучшить сроки выполнения работ и качество.

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

• CMMI for Development — модель управления и улучшения процессов для организаций, занимающихся разработкой программного обеспечения;
• CMMI for Acquisition — модель для организаций, которым необходимо инициировать и управлять закупками продуктов и услуг;
• CMMI for Services — модель процессов для организаций, помогающая им развертывать и управлять услугами.

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

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

CMMI можно интегрировать с другими фреймворками и лучшими практиками, такими как гибкая разработка (agile development), PMP и Six Sigma. Это возможно потому, что CMMI не определяет, как должна выполняться разработка программного обеспечения, а вместо этого указывает, что должно быть сделано для улучшения процессов разработки. Таким образом, CMMI поддерживает принципы agile, предоставляя референсную модель для успешных сред разработки.
CMMI также поддерживает интеграцию с Six Sigma, позволяя реализовывать области процессов CMMI в виде проектов Six Sigma (например, DMAIC). PMP также совместим с CMMI, поскольку существует перекрытие между областями знаний PMBOK (Project Management Body of Knowledge) и процессными областями CMMI.

Существуют две разные представления CMMI:

1. Непрерывное представление (continuous representation)
2. Поэтапное представление (staged representation)

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

Поэтапная модель (staged model) ориентирована на организацию в целом и предлагает дорожную карту в виде последовательности этапов (stages), отсюда и название. Эти этапы называются уровнями зрелости (maturity levels) и отражают степень зрелости организации в рамках набора процессных областей.
По мере продвижения организации по уровням зрелости она внедряет все больше практик из различных процессных областей. Как только организация удовлетворяет целям всех процессных областей на одном уровне зрелости, она может перейти на следующий уровень для дальнейшего улучшения своих процессов.

Непрерывная модель (continuous model) отличается от поэтапной модели, поскольку не задает четкий порядок внедрения процессных областей, которые должны быть улучшены. Вместо этого она сосредотачивается на каждой процессной области отдельно и на том, как ее можно улучшить. Каждая процессная область имеет свой собственный уровень возможностей (capability level). При этом группировка процессных областей в данной модели отсутствует.

Следующие разделы более подробно представляют уровни возможностей и уровни зрелости CMMI.

Уровни возможностей (Capability Levels)

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

• 0. Неполный (Incomplete)
• 1. Выполняемый (Performed)
• 2. Управляемый (Managed)
• 3. Определенный (Defined)
• 4. Количественно управляемый (Quantitatively Managed)
• 5. Оптимизируемый (Optimizing)

Организация начинает с уровня возможностей 0: неполный (Incomplete). Этот уровень указывает, что процессы либо не выполняются, либо выполняются частично. Он также означает, что по крайней мере одна конкретная цель в данной процессной области не достигнута. Общих целей для этого уровня не существует, так как частично выполняемые процессы не должны быть институционализированы.

Организация может перейти на уровень возможностей 1: выполняемый (Performed), если все общие цели уровня 1 выполнены. Этот уровень требует, чтобы процессы выполнялись и давали необходимый результат. Однако он не требует институционализации процесса, что означает, что улучшения могут быть утеряны со временем.

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

Следующий уровень возможностей, которого может достичь организация, — это уровень возможностей 3: определенный (Defined).
Он характеризуется определенным процессом, который представляет собой управляемый процесс, созданный на основе набора стандартных процессов организации и адаптированный к конкретным условиям.
Процесс был настроен в соответствии с руководящими принципами организации и включает описание процесса. Кроме того, он вносит процессный опыт обратно в общую процессную организацию.

Уровень возможностей 4: количественно управляемый (Quantitatively Managed) — это определенный процесс (см. уровень 3), который использует статистические и другие количественные методы для управления выбранными подпроцессами. Эти методы используются для выявления процессов, которые дают больше дефектных результатов или обладают более низким качеством.

Наивысший уровень возможностей, которого может достичь организация, — это уровень возможностей 5: оптимизируемый (Optimizing). Он сосредоточен на институционализации процесса оптимизации. Этот процесс требует, чтобы организация постоянно измеряла свои (количественно управляемые) процессы, анализировала тренды, изучала технические практики, устраняла общие причины вариативности процессов и затем адаптировала процессы к изменяющимся бизнес-потребностям.

Уровни зрелости

Уровни зрелости отличаются от уровней способности, так как они применяются к наборам областей процессов, в которых необходимо достичь совокупного набора целей (в отличие от уровней способности, которые применяются к отдельным областям процессов). В модели CMMI используются следующие уровни зрелости, которые объясняются в этом разделе:

1. Начальный (Initial)
2. Управляемый (Managed)
3. Определенный (Defined)
4. Количественно управляемый (Quantitatively Managed)
5. Оптимизируемый (Optimizing)

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

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

Уровень зрелости 3: определенный характеризуется четко описанными и понятными процессами, которые документированы в стандартах, процедурах, инструментах и методах. Организационные стандартные процессы устанавливаются и совершенствуются со временем. Ключевое отличие между уровнями зрелости 2 и 3 заключается в том, что на уровне 2 стандарты, описания процессов и процедуры могут различаться для каждой конкретной реализации процесса. Однако на уровне 3 стандарты, описания процессов и процедуры адаптируются из стандартных процессов организации.

На уровне зрелости 4: количественно управляемый организации используют количественные цели по качеству и производительности процессов для управления своими проектами. Отдельные подпроцессы измеряются путем сбора и статистического анализа конкретных метрик производительности процессов.

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

Переход на уровень зрелости 5

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

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

Интеграция CMMI в методологию Data Vault 2.0

Методология Data Vault 2.0 позволяет организациям достичь уровня зрелости 5 по CMMI, решая следующие задачи:

• Измеримость (Measurable): Раздел 3.1.4 опишет, как процесс оценки в методологии Data Vault 2.0 основан на сравнении оценочного и фактического объема работ. Для этого необходимо фиксировать соответствующую информацию на протяжении всего процесса.
• Повторяемость (Repeatable): Для оценки будущих затрат важно иметь повторяемые процессы. Модель Data Vault 2.0 помогает в этом благодаря шаблонным, основанным на паттернах процессам моделирования и загрузки данных в корпоративное хранилище данных.
• Определенность (Defined): Data Vault 2.0 поддерживает четко определенные стандарты, правила, процедуры и готовые шаблоны, включая проектную документацию. Пример такого определения процессов представлен на рисунке 3.3. Определенность также способствует повторяемости процессов.
• Гибкость (Flexible): Методология поддерживает быстрые последовательные развертывания (от двух до трех недель, в зависимости от возможностей или предпочтений организации). Также возможны изменения в размерах команды в зависимости от потребностей. Это соответствует определенным паттернам Data Vault 2.0, которые помогают новым членам команды быстро понять процессы и включиться в реализацию или тестирование.
• Масштабируемость (Scalable): После развертывания хранилища данных на основе Data Vault 2.0 в одной части предприятия можно добавлять дополнительную функциональность, необходимую другим подразделениям. Это возможно благодаря органическому росту моделей Data Vault 2.0 — характеристике, которая не только уникальна для Data Vault, но и была заложена в подход к моделированию с самого начала.
• Мониторинг (Monitored): Регулярные командные обзоры, как в Scrum (например, на встречах ретроспективы), и постоянные релизы в каждом спринте гарантируют, что бизнес-пользователи не теряют интерес к проекту и его деятельности. Напротив, это поддерживает высокий уровень вовлеченности, что ускоряет реакцию бизнеса, если ИТ не предоставляет ожидаемых результатов.
• Управляемость (Governed): Мониторинг также включает в себя управление. Если релизы не соответствуют (или не превышают) задокументированные стандарты, проект приостанавливается и пересматривается, чтобы в будущем соответствовать требованиям. Это осуществляется в рамках двух- или трехнедельных спринтов.
• Оптимизация (Optimized): Процессы Data Vault 2.0 способствуют оптимизации благодаря низкой сложности: чем ниже сложность процессов разработки, тем меньше зависимостей необходимо учитывать при постоянном совершенствовании процессов.

Таблица 3.1 показывает действия и задачи методологии Data Vault 2.0 и их связь с уровнями зрелости CMMI.

Таблица 3.1 — Соответствие методологии Data Vault 2.0 уровням зрелости CMMI

Организации могут использовать эту таблицу, чтобы сосредоточиться на определенных действиях Data Vault при продвижении по уровням зрелости. Например, параллельные команды должны становиться объектом внимания организации только после достижения уровня зрелости CMMI 4 (количественно управляемый) и при переходе на уровень 5 (оптимизируемый). Это соответствует ранее описанной рекомендованной практике продвижения по уровням зрелости, а не попытке сразу достичь статуса оптимизируемой организации. Хотя первый подход требует больше времени и тщательной проработки организационных возможностей, он сопряжен с гораздо меньшими рисками по сравнению с прямым стремлением к уровню зрелости 5.

Управление проектом

Как описано в разделе 3.1, методология Data Vault 2.0 способствует развитию процессов, которые являются определенными, повторяемыми и управляемыми, наряду с другими характеристиками. Однако это не означает, что цель состоит в чрезмерном определении или ограничении процесса разработки. Цель заключается в использовании структурированного, но гибкого подхода к разработке решений в области бизнес-аналитики.

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

Исключением из этого правила является долгосрочное (или общее) планирование, необходимое на программном или корпоративном уровне организации.

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

Так как модель Data Vault 2.0 была создана на основе модели сети с центральным узлом и подключенными элементами (hub-and-spoke network model, подробнее об этом в главе 5 «Промежуточное моделирование Data Vault»), она изначально разработана для поддержки такого эволюционного подхода.

Создание модели Data Vault — это естественная эволюция. Наилучший подход к реализации хранилища данных на основе Data Vault 2.0 — сосредоточиться на четко определенной, узконаправленной задаче, где бизнес-ключи охватывают несколько функциональных областей. Следует избегать попыток смоделировать всю организацию сразу, как это обычно делается в традиционных архитектурах, представленных в главе 1 «Введение в хранилища данных». В этих устаревших архитектурах моделирование всей организации требуется, поскольку внесение изменений в исходную модель (нормализованную до третьей нормальной формы или в виде звездной схемы) слишком затратно. Поэтому разработчики пытаются внедрить в исходную модель как можно больше функций, чтобы минимизировать будущие изменения. Однако, учитывая изменчивость бизнес-среды, такой подход нереалистичен.

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

Однако гибкость зависит не только от модели Data Vault или архитектуры. Она также зависит от людей: участников проекта внутри команды и внешних специалистов, поддерживающих основную команду разработки. Успешный гибкий проект требует хорошо обученных специалистов, которые следуют дисциплинированному, совместному подходу (как описано в предыдущем разделе). Также важно привлекать всех заинтересованных лиц, которые вовлечены в создание хранилища данных. Это не только бизнес-пользователи. Команды разработки часто забывают вовлекать операционные и службы поддержки на ранних этапах процесса.

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

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

В конечном итоге цели гибкой (agile) поставки заключаются в следующем:

• Масштабирование agile: Это касается не только увеличения размера команды, но также распределения команды по разным локациям, соответствия нормативным требованиям, управления сложностью (доменной, технической и организационной) и интеграции в корпоративную среду.
• Избегать хаоса: Плохо управляемые проекты сталкиваются с теми же проблемами, что и неуправляемые. Нельзя просто «быть agile» без дисциплины agile. Учитесь на ошибках прошлых спринтов и постоянно улучшайте свои процессы.
• Эффективное начало: Прежде чем приступить к разработке системы, необходимо прояснить бизнес-проблемы, определить жизнеспособное техническое решение, спланировать подход, настроить рабочую среду и собрать команду. Также важно заручиться поддержкой заинтересованных сторон в отношении выбранного подхода и стратегии внедрения.
• Переход от отдельных специалистов к agile-командам: Каждый член команды должен сосредоточиться на совместной работе для достижения целей проекта, а не на индивидуальных выгодах.
• Постепенное наращивание решения: Каждый спринт должен давать результат, который может быть использован бизнес-пользователями. Только в этом случае они смогут дать реалистичную и ценную обратную связь о текущем решении. Цель — не просто продемонстрировать что-то, а ввести в реальную эксплуатацию.
• Развертывание гибких решений: Современная бизнес- и технологическая среда сложна. Agile-решение должно быть развернуто с учетом этой сложности.
• Использование корпоративных методологий: Методология Data Vault 2.0 уже включает в себя проверенные корпоративные методологии, такие как CMMI, Scrum, Six Sigma, PMP и др. Существуют и другие дисциплины, помогающие развертывать, сопровождать и поддерживать решения, например, ITIL (Библиотека инфраструктуры информационных технологий). Используйте эти проверенные подходы, особенно если они уже применяются в вашей организации.
• Адаптация стратегии управления (governance): Управление agile-проектами должно быть встроено в процесс спринтов. Поскольку решение поставляется к концу каждого спринта, необходимо проверять соответствие установленным в организации стандартам и правилам.

Эти цели заимствованы из Disciplined Agile Delivery (DAD), который применяется в корпоративных организациях для гибкой поставки программного обеспечения. Это гибридный подход, который расширяет Scrum за счет проверенных стратегий Agile Modeling (AM), Extreme Programming (XP) и Unified Process (UP). Таким образом, он следует схожей стратегии с методологией Data Vault 2.0, но с четкой ориентацией на хранилища данных и бизнес-аналитику.

Scrum

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

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

В результате были разработаны гибкие методологии (agile), чтобы сделать процесс разработки программного обеспечения более адаптивным и успешным в целом. Scrum является одним из примеров такой гибкой методологии, и он описан в следующих разделах. Он был введен в конце 1990-х годов и стал «подавляющим [agile] фаворитом».

В Scrum пользовательские требования хранятся в виде пользовательских историй (user stories) в бэклоге продукта (product backlog). Они расставляются по приоритету с учетом бизнес-ценности и включают требования, касающиеся запросов клиентов, новых функций, улучшения удобства использования, исправления ошибок, повышения производительности, переработки архитектуры и т. д.

Пользовательские истории реализуются в итерациях, называемых «спринтами» (sprints), которые обычно длятся от двух до четырех недель. В ходе спринта пользовательские истории извлекаются из бэклога продукта в соответствии с их приоритетом и реализуются командой.

Цель Scrum — создавать потенциально готовый к выпуску инкремент (potentially shippable increment) в каждом спринте, представляющий собой новую версию системы, которую можно продемонстрировать бизнес-пользователям и потенциально выпустить в продакшн (Рисунок 3.7).

Рисунок 3.7 Поток требований в процессе Scrum

Это требует, чтобы пользовательская история была реализована и протестирована полностью, включая всю бизнес-логику, относящуюся к этой истории. Все заинтересованные стороны, такие как бизнес-пользователи и команда разработки, могут проверить новую, работающую функцию и предоставить обратную связь или рекомендовать изменения в пользовательской истории до начала следующего спринта. Scrum поддерживает изменение приоритетов в бэклоге продукта и приветствует изменяющиеся бизнес-требования между спринтами (Рисунок 3.8).

Рисунок 3.8 Быстрые итерации в Scrum

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

Следующие разделы объясняют элементы Scrum более подробно.

Итеративный подход

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

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

Рисунок 3.9 Управление проектом в Scrum

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

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

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

Бэклог продукта и спринта

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

Перед добавлением в бэклог продукта каждая пользовательская история приоритизируется. Разработчики должны строго выбирать пользовательские истории из бэклога в порядке их приоритета. В начале каждой итерации пользовательские истории, которые должны быть реализованы, извлекаются из бэклога продукта и перемещаются в бэклог спринта (см. Рисунок 3.7 для деталей). Пользовательская история проектируется, реализуется, тестируется и интегрируется в продукт целиком. Проблемы устраняются немедленно, чтобы поддерживать продукт в состоянии «потенциально готового к выпуску».

Рисунок 3.10 Бэклог и приоритет

Рабочие элементы, имеющие высокий приоритет (и, следовательно, выбираемые следующими членами команды), должны быть детализированы и четко определены, поскольку они описывают предстоящую задачу для разработчика. С другой стороны, пользовательские истории с более низким приоритетом могут быть менее детализированы. Эти пользовательские истории часто недостаточно проработаны бизнес-пользователем и требуют более четкого определения.

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

Интеграция Scrum с методологией Data Vault 2.0

Чтобы стать гибкой проектной командой и достичь целей, представленных в начале этого раздела, команда должна развиваться через различные уровни CMMI. Слишком многие команды и организации просто решают быть «гибкими», не применяя корректно принципы выбранной методологии. Все гибкие подходы, включая Scrum, следуют набору принципов, которые необходимы для того, чтобы команда могла стать гибкой. Без правильного следования этим принципам команда попадает в число тех, кто лишь делает вид, что «разрабатывает по Agile», но на самом деле отказывается от большинства управленческих процессов проекта. Однако Agile-проектное управление не означает «отсутствие управления проектом». Это другой подход к управлению проектом, требующий, чтобы члены команды знали принципы и умели их применять.

Члены команды, которые никогда ранее не работали в гибком проекте, часто не знают этих принципов. Они должны изучить их либо на обучении, либо у более опытных членов команды, чтобы стать успешными участниками Agile-команды.

Более того, для ведения гибких проектов необходима гибкая организация. Если организация мыслит в стиле водопадной модели с передачей артефактов «через забор» между отделами (например, от разработки к тестированию, затем к бизнесу) и внесение изменений в промышленную эксплуатацию требует минимум 3 недель, ваша команда не сможет работать эффективно с точки зрения гибкой методологии. Как уже упоминалось в этой главе, цель состоит в том, чтобы изменения, разрабатываемые в одной итерации, вводились в промышленную эксплуатацию в том же спринте. Эта цель может не всегда быть достижимой, например, если невозможно сократить изменение до управляемого объема, который можно разработать и развернуть в рамках одного спринта. В этом случае артефакт может дорабатываться в нескольких спринтах, пока он не будет готов к развертыванию. Однако стандартной практикой должно быть развертывание в том же спринте, в котором разрабатывается артефакт.

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

CMMI может помочь в развитии как команды, так и организации для достижения гибкости. Следуя рекомендациям, изложенным в разделе 3.1.1 (подраздел «Продвижение к уровню зрелости 5»), организации со временем развивают эти навыки, давая членам команды возможность учиться, применять и совершенствовать свои Agile-навыки. Фактически, Scrum строится на уровне 5 CMMI (оптимизация), где команды стремятся улучшать свои способности со временем. Мы рассмотрим это более подробно в разделе 3.3.

Большинство гибких проектов имеют общую основу в понимании того, что для достижения представленных целей команда бизнес-аналитики (BI) должна взять на себя несколько обязанностей:

• Удовлетворение потребностей заказчика: Для выполнения этой обязанности команда должна быстро и непрерывно доставлять не просто работающее программное обеспечение, а полезное программное обеспечение. Под этим мы понимаем, что инкремент должен приносить ценность пользователю (и работать).
• Частые поставки: Чтобы демонстрировать прогресс бизнес-пользователям и другим заинтересованным сторонам, команда BI должна поставлять работающее программное обеспечение на регулярной основе (в течение недель, а не месяцев).
• Измерение прогресса: Разработчики часто измеряют свой прогресс количеством затраченных человеко-часов и сравнивают его с первоначальным или обновленным планом. В гибких методах разработки, таких как методология Data Vault 2.0, прогресс измеряется работающим программным обеспечением, а именно реализованными функциями.
• Готовность к изменениям: Гибкие BI-команды не должны избегать поздних изменений в изначальных требованиях. Чтобы соответствовать бизнес-требованиям и поддерживать удовлетворенность пользователей результатами, процесс сбора требований в Data Vault 2.0 является непрерывным.
• Тесное сотрудничество: Бизнес-пользователи и разработчики должны ежедневно работать над новыми функциями хранилища данных. Однако цель не в том, чтобы оперативно исправлять проблемы в продакшене. Они должны совместно разрабатывать новые функции в рамках текущего спринта. Оперативные исправления должны выполняться отделом эксплуатации, поэтому хранилище данных должно разрабатываться так, чтобы бизнес мог самостоятельно его поддерживать без вовлечения IT.
• Личное общение: Команды BI должны избегать переписки по электронной почте и вместо этого встречаться лично для решения текущих вопросов.
  Мотивация сотрудников: Мотивация часто основана на доверии и является двусторонним процессом.
• Техническое совершенство: Чтобы обеспечить долгосрочную удовлетворенность бизнес-пользователей, необходимо технически совершенное решение. Однако IT не должно стремиться достичь этого сразу. Вместо этого следует сфокусироваться на хорошем дизайне, который в конечном итоге приведет к созданию отличного продукта в гибкой манере. В этом помогает модель Data Vault 2.0, так как она обеспечивает расширяемость модели для добавления новых функций в будущих спринтах.
• Простота: Настоящие инженеры любят простые решения. Не добавляйте функции, которые не нужны бизнесу. Не модифицируйте модель Data Vault 2.0 системными атрибутами, если в этом нет реальной необходимости. Всякий раз, когда в решение добавляется сложность, для этого должна быть веская причина. Это упрощает поддержку конечного решения.
• Самоорганизующиеся команды: Члены команды несут ответственность за самоорганизацию вокруг поставленных задач.
• Регулярная адаптация: Команда BI несет ответственность за пересмотр прошлых решений и проверку их актуальности в изменившихся условиях или обстоятельствах. Эта обязанность может быть самой сложной, поскольку людям трудно признать ошибки. Однако решение, принятое шесть месяцев назад в тех условиях, не было ошибкой. Ошибкой было бы продолжать его придерживаться, если обстоятельства изменились.

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

Определение проекта

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

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

Зачастую архитекторы пытаются строить хранилище данных слой за слоем: они определяют начальный набор источников данных для генерации всех требуемых отчетов или OLAP-кубов (online analytical processing). Затем они реализуют весь слой стейджинга, загружая туда все исходные таблицы, включая ETL-процессы для их загрузки. После завершения слоя стейджинга они начинают моделировать корпоративное хранилище данных в максимально полном виде, поскольку дорабатывать его позже слишком дорого. После реализации ETL-пакетов создаются витрины данных, чтобы наконец удовлетворить потребности бизнес-пользователей. Такой подход обычно занимает месяцы, если не годы, включая несколько этапов отладки и исправления ошибок.

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

Благодаря расширяемой модели и архитектуре, а также гибкой методологии стандарта Data Vault 2.0, архитекторам хранилищ данных больше не нужно следовать такому подходу. Вместо горизонтального построения хранилища данных слой за слоем хранилище создается вертикально, функция за функцией. Общая цель инициативы по хранилищу данных остается прежней, но теперь она достигается путем инкрементных поставок функциональности.

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

Рекомендуемый подход для достижения этой цели — использовать ограниченный (scoped) подход к инжинирингу требований и реализации отдельных функций, как показано на рисунке 3.11.

Рисунок 3.11 Определение границ отчета

Функция, реализуемая в примере, представленном на этом рисунке, — это отчет, но она может быть и любым другим артефактом, требуемым пользователем. Например, это может быть новое измерение или атрибут в OLAP-кубе, новый OLAP-куб сам по себе (с минимальным количеством измерений) или корпус данных для текстового анализа.

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

При следовании этой процедуре в Data Vault загружаются и моделируются все данные из исходных таблиц, а не частичные наборы атрибутов. Таким образом, к исходной таблице обращаются только один раз, а не многократно. Чтобы оценить доступность данных, должна быть возможность отслеживать, какие данные уже загружены в корпоративное хранилище. Частично загруженные данные усложняют этот процесс, чего следует избегать. Кроме того, загрузка только части данных из исходных таблиц приводит к усложнению спутников (satellites) Data Vault.

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

Благодаря модели Data Vault 2.0 команды теперь могут разрабатывать свои решения инкрементно в разных бизнес-областях, что позволяет им быть гибкими в определении границ реализации.

Следует отметить два распространенных возражения.

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

Часто затраты на интеграцию всех таблиц перевешивают сложность оценки уже загруженных данных в Data Vault (что становится проще при фокусе на таблицах).

Вторая проблема заключается в том, что при загрузке таблиц-источников в стейджинг-область хорошей практикой является их последующая интеграция в Data Vault. В противном случае может возникнуть дополнительная сложность при оценке актуального состояния хранилища данных, если оба слоя (стейджинг и Data Vault) окажутся несинхронизированными. Если следовать этой практике, загрузка всех таблиц-источников должна сопровождаться полной моделированием и загрузкой соответствующих таблиц Data Vault.

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

Этот вертикальный подход к предоставлению информации выполняется в течение одного спринта. В зависимости от возможностей организации его продолжительность может составлять две или три недели. Поэтому моделирование Data Vault не должно занимать месяцы. Напротив, модель должна быть создана в течение продолжительности спринта. Если на это уходит больше времени, это хороший индикатор того, что объем работы спринта слишком велик. В таком случае функциональность следует исключить из спринта. Исключите все, что не обязательно для поставки вместе с единственной функцией, на которой сосредоточен этот спринт. Убедитесь, что бизнес-пользователи понимают, что эта функциональность все еще будет реализована — но в последующих спринтах.

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

Гибкий сбор требований

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

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

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

Задача состоит в том, чтобы показать эти отчеты пользователям и спросить их: «Что не так с этим отчетом?» Оказывается, что бизнес-пользователи могут легко указать на проблемы в отчете и, таким образом, предоставить все бизнес-правила, которые IT необходимо внедрить для создания финального отчета.

Процедура данного подхода к сбору требований включает следующие шаги:

• Идентификация необходимых данных: Как описано в предыдущем разделе, первый шаг — определить источники данных для Raw Mart и его отчета. Опять же, только данные, относящиеся к данному контексту, должны быть загружены в промежуточную область (staging area) и в корпоративное хранилище данных (enterprise data warehouse). Если возможно, объем данных следует уменьшить для ускоренного вывода. Например, данные, которые нужны только для финального отчета, но не для промежуточного необработанного отчета, следует исключить на этом этапе.
• Создание Raw Mart: После загрузки данных в Raw Data Vault на их основе создается Raw Mart. При загрузке Raw Mart не реализуются никакие бизнес-правила. Вместо этого данные просто переводятся из модели Data Vault в измерительную модель. Лучший подход для этого — использование виртуальных представлений (virtual views), так как их легко создавать.
• Создание Raw Reports: Как только данные попадают в измерительный Raw Mart, можно создавать Raw Reports (необработанные отчеты). Поскольку к данным не применены бизнес-правила, отчет содержит как хорошие, так и плохие, и проблемные данные.
  До этого момента IT контролирует время поставки. Они отвечают за то, чтобы быть гибкими до данного этапа. Следующие шаги выполняются уже со стороны бизнеса:

• Размещение Raw Reports на стене: Когда Raw Reports созданы на основе Raw Mart, они представляются участникам встречи по сбору требований. Хороший способ — распечатать их и повесить на одной стороне комнаты. Если это невозможно или непрактично, можно использовать LCD-проектор для демонстрации отчетов группе. Однако преимущество печатных отчетов на стене в том, что участники могут потратить столько времени, сколько им нужно, чтобы изучить отчет и добавить комментарии или исправления непосредственно на бумажную версию. Большинство проблем с отчетом становятся очевидными для участников. Они могут объяснить IT, в чем проблемы отчетов и почему их нельзя использовать в текущем виде.
• Сбор бизнес-правил и других требований: IT должно напрямую спрашивать участников, что делает отчет непригодным и как его можно сделать полезным для бизнеса. Какие изменения в данных необходимы, чтобы сделать их корректными? Ответы бизнес-пользователей содержат недостающие бизнес-правила, которые необходимо задокументировать в документе требований и применить к данным, загружаемым в Raw Report. Важно отметить, что следует меньше фокусироваться на оформлении отчета, поскольку этот вопрос должен решаться бизнесом и, в идеале, не должен зависеть от IT.
  Как только требования хотя бы частично собраны, IT снова берет на себя управление проектом, реализуя бизнес-правила и другие требования:
• Трансформация бизнес-правил и других требований: Последний шаг в этом цикле — перевод бизнес-правил и других требований, полученных от бизнеса и задокументированных в документе требований, в программную логику. Это можно сделать либо через ETL-потоки, либо виртуально в SQL-представлениях. Бизнес-правила превращают необработанные данные в информацию на пути от Raw Data Vault к Business Vault или Information Mart.

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

Рекомендуемая практика — записывать эти встречи по сбору требований и создавать Wiki или другой веб-ресурс с поддержкой Web 2.0, доступный для всех сотрудников организации. Записи встреч, включая описание выявленных бизнес-правил, должны быть опубликованы на этом веб-ресурсе, чтобы обеспечить прозрачность процесса сбора требований. Механизмы Web 2.0 позволяют участникам оставлять комментарии или даже модифицировать бизнес-правила в соответствии со своим пониманием. Такой подход гарантирует, что требования изначально будут корректными.

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

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

Оценка проекта

Процесс оценки в методологии Data Vault 2.0 основан на анализе функциональных точек (Function Point Analysis, FPA). Этот подход рекомендуется по сравнению с другими методами оценки, так как он предполагает разбиение функциональности на отдельные элементы, что в Data Vault 2.0 делать достаточно просто (благодаря стандартизированным артефактам). Используя FPA, члены команды оценивают необходимую функциональность хранилища данных, рассчитывая функциональные точки для отдельных элементов и оценочные часы, требуемые для их реализации.

Анализ функциональных точек

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

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

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

Например, одна и та же функциональность, запрашиваемая бизнес-пользователем, может потребовать 100 строк кода на C#, но 500 строк кода на C. Однако функциональные точки измеряют именно функциональность, предоставленную конечному пользователю, или ту, что будет предоставлена в будущем.

На рисунке 3.12 показаны функциональные характеристики программного обеспечения в индустрии авиаперевозок.

Рисунок 3.12 Функциональные характеристики программного обеспечения

Функциональные характеристики программного обеспечения включают:

• Внешние входы (EI, External Inputs) – данные, поступающие в систему.
• Внешние выходы (EO, External Outputs) и внешние запросы (EQ, External Inquiries) – данные, покидающие систему тем или иным образом.
• Внутренние логические файлы (ILF, Internal Logical Files) – данные, созданные и хранящиеся внутри системы.
• Файлы внешнего интерфейса (EIF, External Interface Files) – данные, которые поддерживаются вне системы, но необходимы для выполнения задач.

Оценка функциональных точек также включает оценку сложности системы в целом.

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

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

Измерение с использованием функциональных точек

Для измерения размера программной системы каждый из ее компонентов анализируется по характеристикам, описанным в предыдущем разделе. International Function Point User Group (IFPUG), организация, ответственная за анализ функциональных точек, рекомендует следующий порядок действий для выполнения измерения:

Шаг 1: Определение типа подсчета функциональных точек

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

• Подсчет функциональных точек для проекта разработки (Development project function point count)
• Подсчет функциональных точек для проекта улучшения (Enhancement project function point count)
• Подсчет функциональных точек для приложения (Application function point count)

Шаг 2: Определение границы подсчета

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

Шаг 3: Определение и подсчет типов функций данных

В предыдущем разделе были представлены два типа функций данных:

• Внутренние логические файлы (ILF, Internal Logical Files)
• Файлы внешнего интерфейса (EIF, External Interface Files)

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

Шаг 4: Определение и подсчет типов транзакционных функций

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

• Внешний ввод (EI, External Input)
• Внешний вывод (EO, External Output)
• Внешние запросы (EQ, External Inquiries)

Шаг 5: Определение необработанного количества функциональных точек

Количество функциональных типов, полученных на этапах 3 и 4, корректируется с учетом сложности.

Шаг 6: Определение коэффициента корректировки значений

Коэффициент корректировки значений (Value Adjustment Factor, VAF) отражает общую ценность системы для пользователя, оценивая ее общую функциональность. Величина VAF определяется по 14 характеристикам системы.

Шаг 7: Расчет итогового количества функциональных точек

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

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

Анализ функциональных точек для хранилищ данных

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

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

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

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

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

Границы в хранилищах данных

Первый этап адаптации процесса – это определение границ компонента в хранилищах данных. Из-за многоуровневой архитектуры в этой области каждая функция должна быть реализована на нескольких уровнях системы. Компонент включает в себя все эти изменения (Рисунок 3.13).

Рисунок 3.13. Границы приложения хранилища данных

На Рисунке 3.13 показано, что каждая функция включает:

• Таблицы промежуточного слоя (staging tables)
• Объекты в ядре хранилища данных
• Объекты витрины данных (data mart)

Это также включает всю логику, реализованную в ETL, такую как бизнес-правила. Дополнительно в состав входят графические элементы, например:

Отчеты

• Размерности и показатели в OLAP-кубе
• Элементы на панели мониторинга

Оценка размера

Второй этап трансформации — это определение типов функций, используемых для оценки в проектах хранилищ данных. Поскольку архитектуры хранилищ данных часто следуют структурам, описанным в Главе 2, во время оценки используется таблица соответствий, представленная в Таблице 3.2.

Таблица 3.2. Соответствие компонентов хранилища данных типам функциональных точек

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

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

Маппинги (mappings) в хранилище данных реализуют требуемую логику путем извлечения данных из исходных таблиц, их преобразования и загрузки в целевые таблицы. Они считаются внешним вводом (EI), поскольку изменяют поведение системы за счет реализации бизнес-правил.

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

Системные оповещения (Process alerts) информируют внешние системы о статусах процессов ETL и, следовательно, считаются внешним выводом (EO).

Оценка факторов сложности ETL

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

РИСУНОК 3.14 Диаграмма причин и следствий для факторов сложности ETL

Диаграмма показывает причины и следствия факторов сложности в типичных ETL-проектах. Однако не все эти факторы коррелируют с фактическими затратами усилий. Они зависят от организации и проектных команд. Чтобы выявить факторы, оказывающие влияние, требуется корреляционный анализ, например поэтапный метод регрессионного анализа (step-wise forward regression analysis).

Пример уравнения для регрессионного анализа в рамках конкретного проекта по хранилищу данных может выглядеть следующим образом (Уравнение 3.1):
Пример уравнения для регрессионного анализа:

Y=A⋅x5+B⋅x9+C⋅x15+D⋅x16+E⋅x19+F⋅(x2⋅x4)+G⋅(x3⋅x4)+H
Y=A⋅x5+B⋅x9+C⋅x15+D⋅x16+E⋅x19+F⋅(x2⋅x4)+G⋅(x3⋅x4)+H

Где:

x5: Количество целевых столбцов
x9: Тип трансформации
x15: Файл параметров, который необходимо изменить или создать
x16: Новое сопоставление (mapping)
x19: Неприведенные функциональные точки (unadjusted function points)
x2x4: Объем обработанных данных * Количество трансформаций (взаимосвязанные факторы)
x3x4: Критерии производительности * Количество трансформаций (взаимосвязанные факторы)

Фактическое уравнение для регрессионного анализа проекта также будет включать коэффициенты регрессии, которые в Уравнении 3.1 обозначены символами A–H.

Применение анализа функциональных точек к хранилищам данных

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

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

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

Способность предоставлять обоснованные оценки является ключевым требованием CMMI (Capability Maturity Model Integration) для достижения уровней зрелости выше начального/выполняемого уровня.

Например, FPA может применяться на уровне зрелости 2 (управляемый уровень) для:

• Квантификации объема функциональных требований в управлении требованиями.
• Оценки затрат усилий и стоимости в управлении проектами.
• Предоставления данных по функциональным точкам руководству и т. д.

Для выполнения процесса оценки с использованием FPA необходимо вести точные метрики по прошлым проектам разработки хранилищ данных.

Эти данные используются для корректировки уровня усилий в зависимости от организационных особенностей.

Количество человеко-часов зависит от сложности функциональности. Очевидно, что сложные функции требуют больше времени на реализацию, чем простые (в пересчете на функциональную точку).

Таблица 3.3 демонстрирует пример, который актуален в рамках одного конкретного проекта.

Таблица 3.3 Человеко-часы на один функциональный пункт (Person Hours per Function Point)

Обратите внимание, что Таблица 3.3 должна быть скорректирована для каждого оцениваемого проекта, а также эти значения меняются со временем, поскольку разработчики набираются опыта или, из-за текучки кадров, теряют его в команде.

Как мы уже обсуждали ранее, количество функциональных пунктов зависит от функциональных характеристик разрабатываемого программного обеспечения. Чтобы использовать FPA (анализ функциональных пунктов) в методологии Data Vault 2.0, функциональные характеристики ПО (внешние входные данные, внешние выходные данные, внешние запросы, внутренние логические файлы и внешние интерфейсные файлы) пришлось адаптировать, чтобы они отражали специфику проектов Data Vault. Определены следующие функциональные характеристики хранилищ данных, построенных с использованием Data Vault:

• Загрузка стейджа
• Загрузка хаба
• Загрузка линка
• Загрузка сателлита
• Загрузка измерения
• Загрузка факта
• Построение отчёта

Аналогичным образом можно определить и другие функциональные характеристики, например, для PIT-таблиц (point-in-time), мостовых таблиц, сущностей Business Vault или OLAP-кубов. В целом, процедуры загрузки в Data Vault 2.0 представляют собой EtL-паттерны (маленькая «t» в «EtL» означает, что трансформация минимальна): для загрузки Raw Data Vault требуется минимальное преобразование сырых данных. Следовательно, функциональные пункты для таких трансформаций должны быть низкими, что приводит к высокой степени оптимизации, низкому уровню сложности и простым расчётам функциональных пунктов.

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

Таблица 3.4 Функциональные пункты и уровень трудозатрат

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

Оценочные функциональные пункты указывают количество функциональных пунктов, рассчитанных для данного типа элемента. Колонка Estimated Total Hours представляет собой произведение колонки Estimated Function Points из Таблицы 3.4 на значение Person Hours per Function Point из Таблицы 3.3.

Обратите внимание, что проводится различие между «узкими» (thin) и «широкими» (wide) сателлитами. Это различие относится к количеству колонок, а не к физической ширине таблицы, которая зависит от числа колонок и ширины каждой колонки в байтах. В общем случае, чем больше колонок содержит сателлит, тем более сложной становится логика загрузки, тем выше вероятность возникновения опечаток, загрузки неверных полей в неправильные цели или пропуска сравнения колонок. Именно поэтому данная таблица разделяет такие загрузки.

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

Необходимо помнить, что данная таблица должна составляться индивидуально для каждого проекта и обновляться со временем. Может потребоваться дополнительное различение между менее или более сложными рабочими элементами (например, загрузками сателлитов в примере из Таблицы 3.4). Чтобы запустить этот процесс, важно следовать общей процедуре, описанной ранее, чтобы получить оценку функциональных пунктов, которая соотносится с фактическими трудозатратами на создание элементов, а также отслеживать количество человеко-часов, требуемых для реализации и тестирования этих функциональных пунктов.

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

Функциональные пункты для корпоративного хранилища данных

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

• Стейджинг-таблицы: Количество функциональных пунктов зависит от необходимого уровня нормализации. Рассмотрим случай плоских файлов в формате CSV, которые не требуют нормализации (для стейджинга), поскольку все колонки могут быть добавлены в стейджинг напрямую. Сравните это с файлами XML или COBOL, которые не так просто загрузить в реляционные таблицы, как файлы CSV, из-за наличия вложенных структур. Для загрузки таких данных требуется определённое усилие по нормализации, чтобы преобразовать данные из их структурированного формата в набор реляционных таблиц. Однако можно избежать этих затрат на нормализацию, загружая данные в иерархические таблицы (например, используя тип данных XML), что приведёт к (значительному) снижению производительности.
• Загрузки стейджинга и Data Vault: В зависимости от сложности ETL-процесса, необходимого для загрузки стейджинг-таблиц или сущностей Data Vault (таких как хабы, линки, сателлиты и т. д.), количество функциональных пунктов будет различаться. Функциональные пункты для хабов, как правило, одинаковы, независимо от размера или состава бизнес-ключа. В остальных случаях это правило не работает: чем больше хабов связано с линком, тем больше функциональных пунктов должно быть назначено из-за немного более сложного ETL-потока данных (однако все линковые связи между двумя хабами должны иметь одинаковое количество функциональных пунктов). Также влияют такие факторы, как количество атрибутов в сателлите, перегрузка сателлитов и их разбиение. Однако основное внимание следует уделять сложности самого маппинга для этой функциональной характеристики. Общее правило: хабы загружаются проще всего, линки — от простых до средних, а сателлиты часто загружаются со средней или высокой сложностью.
• Загрузки информационных витрин: В этих функциональных характеристиках ключевым фактором являются количество и сложность бизнес-правил, а также количество дополнительных колонок, реализуемых в процессе ETL-загрузки. Также важно учитывать, где именно реализуются бизнес-правила — в ETL или виртуально в SQL-представлениях. Кроме того, следует различать функциональные пункты для таблиц фактов, измерений, OLAP-кубов, реляционных отчётов и т. д.
• Загрузки Business Vault: Они схожи с информационными витринами, поскольку также включают реализацию бизнес-правил.

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

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

Анализ функциональных пунктов (FPA) также способствует продвижению измеримых и оптимизируемых компонентов, которые необходимы для проведения оценки. Этой цели способствует разделение отдельных компонентов, которые должны быть поставлены бизнесу. Без такого разделения оценки перекрывали бы функциональность, что снижало бы их точность. Выявление компонентов также снижает неопределённость относительно того, что и когда будет поставлено. Поскольку каждый компонент должен быть идентифицирован и описан, становится возможным планирование его поставки.

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

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

Выполнение проекта

Будучи гибкой, методология Data Vault 2.0 следует Scrum для организации команды и использует эволюционный и итеративный подход, аналогичный Scrum. Следующие рекомендации помогают сделать этот подход успешным:

• Определить начальную архитектуру: Поскольку в рамках спринта нет времени на разработку окончательной архитектуры за один шаг, требуется начальная архитектура, позволяющая применять эволюционный подход.
• Моделировать детали «just-in-time»: Вместо того чтобы заранее моделировать всё корпоративное хранилище данных, моделируйте только те области, которые необходимы для реализации функционала в рамках текущего спринта.
• Раннее подтверждение архитектурных решений: Убедитесь, что архитектурные решения проверяются на ранних этапах. Лучше потерпеть неудачу в начале процесса и внести соответствующие изменения в архитектуру, чем столкнуться с проблемами позднее (что может привести к значительным затратам). Поздние изменения в архитектуре обходятся очень дорого.
• Фокус на использовании: Реализуйте только ту функциональность, которая имеет непосредственную бизнес-ценность.
• Избегайте стремления к «единой истине»: Фокусируйтесь на фактах и данных (подробнее об этом можно узнать в Главе 1, разделах 1.2.3 и 1.2.4).
• Организация работы по требованиям: Поскольку требования проще документировать и изменять, чем реализовывать или модифицировать саму реализацию, фиксация требований даёт значительную пользу для выполнения проекта.
• Активное участие заинтересованных сторон: Следуйте Scrum, проводя ежедневные стендапы. Убедитесь, что заинтересованные стороны присутствуют на этих встречах и участвуют в обсуждении.

Итеративный подход в Data Vault 2.0 реализуется с помощью спринтов продолжительностью от двух до трёх недель. Длина спринта зависит от возможностей организации. Обычно организации начинают с более длинных циклов, например три-четыре недели, когда только внедряют гибкие методологии, но затем стараются сократить продолжительность спринтов ради более частых релизов. То же самое применяется в методологии Data Vault 2.0 и подтверждается практическим опытом. Хорошим стартом для организаций является спринт продолжительностью три недели, разделённый на этапы, представленные в Таблице 3.5.

Таблица 3.5. Цели гибкой поставки

Таблица 3.5 показывает, что команда выполняет внутри спринта «мини-водопад». Этот водопад следует традиционному жизненному циклу разработки программного обеспечения (SDLC), который кратко описан в разделе 3.2.1. Применение этих концепций в методологии Data Vault 2.0 рассмотрено в разделе 3.2.2.

Традиционный жизненный цикл разработки программного обеспечения

Традиционно проекты по разработке хранилищ данных следовали одной из разновидностей модели жизненного цикла разработки программного обеспечения, называемой каскадной моделью (waterfall model). В литературе существуют различные её версии с разным количеством этапов и их названиями, однако все они основаны на поэтапном подходе. Кроме того, этим моделям присущи детальное планирование, за которым следуют всестороннее проектирование, реализация и тестирование. Входные данные от пользователей предоставляются в начале процесса, а затем передаются в техническую систему во время реализации и тестирования. Некоторые из этих поэтапных моделей допускают возврат на предыдущие этапы, например, если в ходе системного тестирования выявлены проблемы, требующие дополнительного участия пользователей.

Рисунок 3.15 демонстрирует репрезентативную версию оригинальной каскадной методологии.

РИСУНОК 3.15. Каскадная модель

На рисунке показано, что данная модель включает пять этапов:

• Инженерия требований
• Проектирование
• Реализация и модульное тестирование
• Интеграционное и системное тестирование
• Эксплуатация и сопровождение

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

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

Инженерия требований

На этом этапе проектная команда собирает и аккумулирует все бизнес- и технические требования организации. Основным результатом данного этапа является документ «Определение хранилища данных» (Data Warehouse Definition), который эквивалентен документу «Спецификация требований к программному обеспечению» (Software Requirements Specification, SRS) в области разработки операционного ПО. Этот документ полностью описывает все необходимые функции и ограничения создаваемого хранилища данных, включая следующие требования:

• Требования к данным в рамках бизнес-областей
• Архитектурные требования
• Требования к аудиту
• Требования к архивированию

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

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

Традиционные методы включают следующее:

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

Современные методы включают следующее:

• Совместное проектирование приложений (Joint Application Design, JAD), при котором ключевые пользователи, менеджеры и системные аналитики совместно собирают системные требования.
• Прототипирование для дополнения процесса определения требований.

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

Проектирование

На этапе проектирования разработчики хранилища данных разрабатывают его архитектуру, включая уровни и модули системы. Определение архитектуры основывается на документе «Определение хранилища данных» (Data Warehouse Definition) и включает в себя описание баз данных для каждого уровня, таких как структура таблиц промежуточного слоя (staging area), таблиц уровня хранилища данных (data warehouse layer) и звездной схемы в витрине данных (data mart). Для каждой базы данных определяются названия и столбцы всех таблиц. Часто определение базы данных выполняется с использованием инструментов моделирования «сущность-связь» (ER), которые позволяют создавать и документировать структуру базы данных.

Microsoft SQL Server 2012 включает SQL Server Management Studio, который позволяет быстро создавать и заполнять каждый уровень хранилища данных, используя инструмент Visual Database Tool Designer.

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

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

Реализация и модульное тестирование

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

Microsoft SQL Server 2012 включает различные инструменты для создания хранилища данных. Большинство из них доступны в среде разработки Microsoft Business Intelligence Development Studio. В эту среду разработки входят следующие инструменты:

• SQL Server Integration Services – для интеграции данных
• SQL Server Analysis Services – для разработки многомерных хранилищ данных (OLAP-кубов) и выполнения задач интеллектуального анализа данных (data mining)
• SQL Server Reporting Services – для разработки отчетов на основе реляционных и многомерных источников данных

Кроме того, большинство команд используют дополнительные инструменты от Microsoft или сторонних поставщиков ПО. Среди часто используемых инструментов:

• OLAP-клиенты для удобного просмотра OLAP-кубов и расширенных возможностей отчетности
• Среды анализа данных для предоставления расширенных аналитических возможностей конечным пользователям
• Инструменты ER-моделирования для определения и документирования баз данных
• Инструменты автоматизации наполнения хранилища данных, такие как генераторы DDL (Data Definition Language)
• Инструменты профилирования данных для более глубокого понимания исходных данных
• Инструменты обеспечения качества данных для очистки и оценки данных

Интеграция и системное тестирование

Хотя разработчики хранилища данных реализовали и протестировали модули хранилища отдельно, на этом этапе выполняется их интеграция. Отдельные модули соединяются друг с другом и интегрируются. Этот процесс интеграции начинается с некоторых модулей на нижнем уровне архитектуры, которые полностью интегрируются и тестируются (Рисунок 3.16).

РИСУНОК 3.16. Тестирование снизу вверх

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

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

Эксплуатация и сопровождение

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

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

Применение жизненного цикла разработки ПО к методологии Data Vault 2.0

Жизненный цикл разработки программного обеспечения применяется в рамках спринта методологии Data Vault 2.0 в виде мини-водопада. Для выполнения этого мини-водопада используется проектный план. В таблице 3.6 приведён пример реализации нового отчёта.

Таблица 3.6. Agile-план проекта

ID	WBS	Task Name	Duration	Predecessors
1	3	Agile Delivery of Single Requirements	58 hrs
2	3.1	Choose Report to Produce (Scope)	0.5 hrs
3	3.2	Estimate Work Effort	0.5 hrs	2
4	3.3	Fill in Risk Assessment	0.5 hrs	3
5	3.4	Identify Source/Stage Tables for Report	4 hrs	4
6	3.4.1	Source to Requirements Matrix	4 hrs
7	3.5	Design ER Data Vault Model	2 hrs	3
8	3.6	Add Attributes to ER Data Vault Model	6 hrs	7
9	3.7	Create ETL Data Vault Loads	4 hrs	8
10	3.7.1	Create Hub Loads	1 hr
11	3.7.2	Create Link Loads	1 hr
12	3.7.3	Create Satellite Loads	2 hrs
13	3.8	Design Data Mart Model for Report	4 hrs	3
14	3.9	Create ETL Data Vault to Information Mart	16 hrs	13
15	3.9.1	Build Dimension Loads	8 hrs
16	3.9.2	Build Fact Loads	8 hrs	15
17	3.10	Build Report and Produce Output	8 hrs	13
18	3.11	Create Source-to-Target Report for Project Documentation	2 hrs	5;8;13
19	3.12	Unit Test	4 hrs	17
20	3.13	Record Actual Effort	0.5 hrs
21	3.14	Sign-off	1 hr	20
22	3.15	Deploy to Test Environment	2 hrs
23	3.16	Run User Acceptance Test	2 hrs
24	3.17	Deploy to Production	1 hr	22;23

Идентификатор (ID) определяет задачу в инструменте управления проектами, таком как Microsoft Project. В основном он используется внутри системы, например, в колонке «Предшественники» (Predecessors), где указываются зависимости между отдельными задачами. Колонка WBS используется для добавления проектной референсной строки к задаче. В следующем разделе обсуждается, как использовать этот идентификатор.

Колонка «Название задачи» (Task Name) содержит читаемое пользователем название, а колонка «Длительность» (Duration) показывает примерное время, необходимое для завершения задачи. В дополнение к длительности во многих проектах добавляется колонка «Объём работы» (Work), которая оценивает трудозатраты. Это необходимо, так как трудозатраты и длительность задачи могут различаться, если над одной задачей работают несколько сотрудников на полной ставке. Этот параметр может использоваться дополнительно к оценкам, полученным с помощью анализа функциональных точек (см. раздел 3.1.4).

Большинство инструментов управления проектами, включая Microsoft Project, поддерживают необязательную колонку «Заметки» (Notes), которая не показана в таблице 3.6. Её можно использовать для включения ссылок на дополнительные зависимости (по их техническим номерам), чтобы идентифицировать оставшиеся артефакты. Эта концепция эквивалентна проектной референсной строке в колонке WBS и также будет описана в одном из следующих разделов.

Обратите внимание, что проектный план в таблице 3.6 показывает рассчитанную длительность для двухнедельного спринта с общим объёмом в 58 часов. В этом примере также предполагается использование инструментов автоматизации для загрузки данных в Data Vault через ETL (элемент 3.7). Если автоматизация не используется, рекомендуется добавить детализированные задачи для загрузки хабов, связей и спутников (под элементами 3.7.1, 3.7.2 и 3.7.3).

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

При этом следует учитывать, что длительность некоторых задач должна оставаться фиксированной, как показано в таблице 3.6 (например, процедура утверждения). Нет смысла увеличивать длительность на 50%, если таблица адаптируется под трёхнедельный спринт. В любом случае, длительность задач должна быть скорректирована в соответствии с потребностями проекта. Кроме того, этап определения границ проекта (задачи с ID 2–4) критичен для его успеха, но при этом не должен занимать более двух часов.

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

Проектный план также показывает, что в ходе проекта создаются определённые артефакты. Это не ограничивается только моделями баз данных или потоками данных ETL. Одним из ключевых аспектов методологии Data Vault 2.0 является создание документации, ценной как для бизнеса, так и для ИТ. Необходимая документация включает:

• Бизнес-глоссарий: Этот документ помогает в построении информационных витрин, так как в нём идентифицируются и документируются бизнес-объекты и связанные с ними термины.
• Документация по требованиям: Описывает информационные витрины и отчёты в деталях. В решении хранилища данных не должно быть функциональности, для которой нет соответствующего зафиксированного требования. Документ должен быть максимально кратким, например, использовать user story объёмом около одной страницы на каждое требование.
• Проектный план: Содержит только задачи, которые необходимо выполнить в течение одного спринта.
• Глоссарий сокращений: В этом документе приведены распространённые сокращения, используемые в бизнесе или в технологической области хранилищ данных.
• Документ об объёме работ (Scope) или заявлении о выполнении работ (Statement of Work): Описывает объём спринта и фиксирует достигнутые соглашения. Является важным источником для процедуры утверждения (sign-off) в конце спринта.
• Документ запросов на изменения: Любой запрос на изменение уже реализованных требований требует документированного процесса, который основан на этом документе.
• Документ приёмки и утверждения (Delivery and Sign-off Document): Когда проектная команда передаёт новую функциональность в конце спринта, требуется утверждение (sign-off) со стороны бизнеса перед её развертыванием. Этот документ подтверждает, что переданная функциональность соответствует или превышает ожидания, изложенные в документации по требованиям или в документе запросов на изменения.
• Роли и обязанности: Определяет роли в проектной команде и связанные с ними обязанности.
• Иерархическая структура работ (Work Breakdown Structure): Разбивает общее поставляемое решение (хранилище данных) на управляемые компоненты.
• Иерархическая структура процессов (Process Breakdown Structure): Каждый бизнес-процесс, поддерживаемый хранилищем данных, должен быть описан с помощью диаграммы бизнес-процесса. Он должен быть смоделирован с таким уровнем детализации, который позволяет идентифицировать наборы данных и их бизнес-ключи.
• Иерархическая структура данных (Data Breakdown Structure): Для каждого (включённого в спринт) бизнес-отчёта создаются две таблицы: одна сопоставляет отчёт с исходными таблицами, другая — с источником Data Vault для вывода информационной витрины.
• Иерархическая структура организации (Organizational Breakdown Structure): Отображает организационные связи и может использоваться для распределения ресурсов в проекте. Создаётся совместно с иерархической структурой работ. Также связывает отдельных членов команды с ролями, определёнными в документе «Роли и обязанности».
• Стандарты моделирования данных: Этот документ содержит соглашения по наименованию сущностей Data Vault, фактов, измерений и их атрибутов. В нём приводится информация о согласованных стандартах моделирования определённых сущностей, системных атрибутов и т. д.
• Стандарты ETL: Описывает реализацию потоков управления и данных, включая соглашения по наименованию, требования к документации, вопросы физического проектирования и другие аспекты.

Этот список показывает, что некоторые из этих документов ссылаются друг на друга. Для поддержания этого процесса рекомендуется использовать проектный технический номер (концепция, описанная в разделе 1.2.4) для идентификации каждого артефакта в документации и реализованном решении. В противном случае невозможно уникально перекрёстно ссылаться на эти артефакты в рамках проекта.

На рисунке 3.17 приведён пример иерархической структуры организации.

РИСУНОК 3.17 Пример иерархической структуры организации

В этой структуре каждая роль связана с членом команды, чьё имя указано на диаграмме. Стандарты управления проектами, такие как Project Management Professional (PMP), требуют, чтобы в проектных планах отслеживались роли, а не конкретные люди, поскольку отдельные участники могут исполнять лишь часть роли в проекте, но каждая роль должна быть заполнена на 100%. В противном случае график проекта не сможет быть соблюдён. То же самое относится и к CMMI.

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

Параллельные команды

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

Команды используют те же шаблоны, которые определены в этой главе, и создают документацию, соответствующую тем же принципам. При реализации и поставке бизнес-требований команды, работающие параллельно, синхронизируют свои модели данных с помощью сущности «связь» (link entity), которая обсуждается в главе 5 «Моделирование Intermediate Data Vault».

С существующей командой Data Vault новым участникам не требуется иметь много предварительных знаний или навыков работы с Data Vault. Для добавления новых человеческих ресурсов в текущий проект, помимо знания среды разработки и правил разработки, требуются следующие навыки (в зависимости от задачи):

• Загрузка из источника в stage: новые члены команды должны знать, как создавать новые stage-таблицы и загружать данные из исходных таблиц. В лучшем случае для этого требуется только выполнение CREATE TABLE и конструкции INSERT INTO … SELECT FROM в SQL.
• Загрузка из stage в hub и link: снова очень похоже и просто. Требуется лишь использование SELECT DISTINCT, некоторой фильтрации для обработки только отсутствующих записей и оператора INSERT INTO для загрузки hub-ов и link-ов.
• Загрузка из stage в satellite: при использовании только SQL-операторов необходимы SELECT DISTINCT, сравнение строк и INSERT для сохранения актуальных данных.

Этот список показывает, что для добавления дополнительных ресурсов в проект, где уже есть эксперты по Data Vault, не требуется много специализированных навыков Data Vault. Более опытные разработчики и моделировщики могут направлять новых участников команды при выполнении этих задач. Следует отметить, что эти навыки применимы к командам, работающим без ETL-инструментов. В дополнение к этим навыкам требуется знание выбранного ETL-инструмента, например Microsoft SQL Server Integration Services. В главе 12 «Загрузка Data Vault» рассматривается процесс загрузки данных в Data Vault с использованием Microsoft SQL Server.

Помимо параллельной реализации бизнес-требований, в проекте работают и другие команды, сосредоточенные на различных видах деятельности, таких как сбор требований, data mining, управляемый BI самообслуживания и т. д. Эти процессы также выполняются параллельно с реализацией.

Техническая нумерация

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

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

Примеры артефактов:

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

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

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

Существует несколько приложений, в которых артефакты ссылаются друг на друга по их техническим номерам:

• Требования → исходные таблицы: это, вероятно, самая мощная схема перекрёстных ссылок, так как она идентифицирует исходные таблицы и атрибуты, используемые конкретным требованием. Должна существовать одна строка на каждое требование, определяющая источники для всех требований. Это одна из структур разбиения данных, упомянутая в предыдущем разделе.
• Исходные таблицы → таблицы Data Vault: эта схема создаётся перед разработкой ETL-процессов для загрузки таблиц Data Vault и указывает соответствие между исходной таблицей и целевыми таблицами Data Vault.
• Таблицы Data Vault → таблицы витрин данных (information mart): аналогично предыдущей схеме, этот документ показывает, как данные сопоставляются между таблицами Data Vault и витринами данных. Этот документ должен представлять собой простую матрицу без указания бизнес-правил, так как они должны быть задокументированы в требованиях.
• Требования → таблицы витрин данных: эта матрица аналогична первой схеме и указывает таблицы витрин данных, используемые определёнными требованиями. Опять же, должна существовать одна строка на каждое требование. Это вторая структура разбиения данных, упомянутая в предыдущем разделе.

Лучший подход — предоставлять эти схемы в виде матриц перекрёстных ссылок в инструменте моделирования или (если лучший вариант недоступен) в таблицах, например в Microsoft Excel. Таблица 3.7 демонстрирует, как должна выглядеть структура разбиения данных.

Таблица 3.7 Пример соответствия требований таблицам витрин данных

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

• Passenger,
• Airplane Utilization и
• Connections.

Отчёт Passenger использует только таблицу Passenger Information в витрине данных, тогда как отчёт Connections использует таблицы Connections и Airplanes. Эти названия сущностей являются логическими; также предоставлены физические названия в качестве справочной информации. Кроме того, эта таблица ссылается на документ требований, в котором отчёты описаны более детально (в проекте может быть несколько документов требований, если команда решает разделить их, например, по функционалу и т. д.).

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

Таблица 3.8 Примеры аббревиатур для типов артефактов

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

Обзор и улучшение

Прежде чем команда завершит спринт и начнёт следующий, проводятся два относительно коротких собрания:

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

Первое собрание фокусируется на продукте: участники оценивают, соответствуют ли реализованные функции ожиданиям и зафиксированным требованиям. По этой причине в обсуждении участвуют все заинтересованные стороны, связанные с рассматриваемыми функциями. Если в ходе собрания выявляются проблемы или отклонения от определённых требований, необходимо создать запрос на изменение, который будет реализован в одном из последующих спринтов. Для проведения этого обзора команда должна быть способна чётко идентифицировать ожидаемые функции и проследить их происхождение до первоначальных требований. Именно поэтому техническая нумерация, описанная в разделе 1.2.4, играет важную роль в методологии Data Vault 2.0. Улучшение результатов проекта невозможно, если команда не может полностью определить источник возникших проблем, но это является ключевым условием успешной оптимизации проекта.

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

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

Six Sigma

Six Sigma играет важную роль в процессе улучшения. Принципы Six Sigma применяются для достижения максимальной оптимизации гибкости процесса построения и внедрения корпоративных хранилищ данных в соответствии со стандартом Data Vault 2.0. Six Sigma опирается на измерения (оценки vs. фактические показатели) или KPI, чтобы определить, что пошло не так на уровне проекта, насколько спринт отклонился от намеченного курса и какие действия необходимо предпринять, чтобы привести процесс в соответствие.

Это процессная часть Six Sigma, применяемая к «исправлению ошибок» или «оптимизации» процесса создания систем бизнес-аналитики. Важно отметить, что такие измерения и KPI должны оценивать команды, а не отдельных членов команды. Data Vault 2.0, как и другие гибкие методологии, включая Disciplined Agile Delivery (DAD), ставит людей на первое место. Если сотрудники понимают, что их индивидуальная продуктивность оценивается, они найдут способы обхода этих измерений. Кроме того, в некоторых юрисдикциях измерение продуктивности отдельных сотрудников является незаконным. Метрики следует рассматривать как возможные индикаторы производительности. Чтобы выявить реальные причины проблем в проекте, следует разговаривать с его участниками, так как именно они, скорее всего, лучше всего знают, что происходит.

Six Sigma также применяется к данным, когда мы превращаем их в информацию, передаём в бизнес-среду и тестируем. Количество «ошибок», обнаруженных в ходе тестирования, является показателем качества данных и количества выявленных дефектов. Измерение ошибок с помощью Six Sigma даёт представление о качестве процессов, разрабатываемых в системе бизнес-аналитики. Чем меньше ошибок совершается со временем, тем более оптимизированными и эффективными становятся процессы, что позволяет команде работать быстрее, дешевле и гибче.

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

Преимущества Six Sigma заключаются в том, что она:

• Обеспечивает контроль качества продуктов и услуг
• Создаёт инновационные методы повышения качества
• Обеспечивает полное удовлетворение потребностей клиентов
• Формирует устойчивую культуру качества

Ключевая концепция Six Sigma заключается в улучшении производительности процессов для достижения трех целей:

• Снижение затрат на процессы
• Повышение удовлетворенности клиентов
• Увеличение выручки и, следовательно, прибыли

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

Существует множество типов входных данных в процессах, применяемых в проектах по хранилищам данных:

• Трудовые ресурсы
• Материалы (например, офисные принадлежности)
• Решения
• Информация
• Измерения

Хотя для большинства производственных компаний основным выходным результатом процессов является продукт, в R&D-ориентированных организациях результатом также могут быть процессы или другие разрабатываемые материалы.

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

Возможно анализировать отклонения в результате процесса, измерять и визуализировать их. Существует три характеристики, описывающие эти отклонения:

• Расположение (Location) – среднее значение качества
• Разброс (Spread) – диапазон значений
• Форма (Shape) – характер распределения отклонений

Чем больше отклонений в процессе, тем ниже качество результата. Следовательно, вариативность является главным врагом контроля качества. Однако отклонения зависят от различных факторов внутри организации или проекта, которые представлены на Рисунке 3.18 «Треугольник производительности процесса».

Вариативность в Six Sigma эквивалентна стандартному отклонению, статистическому измерению разброса данных. В статистике это отклонение обозначается греческой буквой σ (сигма).

Шесть стандартных отклонений означают, что результаты процесса максимально приближены к совершенству. Как показано на Рисунке 3.18, другие важные факторы — это временной цикл (cycle time) и выход (yield).

Выход (yield) – это процент успешных результатов процесса, выраженный в процентах. Он показывает долю выходных данных с приемлемым качеством.

Таблица 3.9 предоставляет обзор уровней производительности, которые можно достичь при различных значениях стандартного отклонения (σ, то есть уровня вариативности).

Источники вариативности

Причины вариативности многообразны. Вариативность подразделяется на общие причины (common causes) и специальные причины (special causes).

Общие причины (common causes) присутствуют в любом повторяющемся процессе с стабильным и предсказуемым распределением во времени. Их трудно устранить, так как они являются неотъемлемой частью процесса. Единственный способ уменьшить их – это пересмотреть сам процесс. Однако редизайн процесса может ввести новые вариации.
Верхняя часть Рисунка 3.19 показывает вариативность стабильного и предсказуемого процесса, обусловленную общими причинами.

Рисунок 3.19 «Общие и специальные причины вариативности»

Специальные причины (special causes) также называются назначаемыми причинами (assignable causes).

• Эти редкие и нестандартные факторы изменяют распределение процесса.
• Если не устранить их, они непредсказуемо повлияют на результаты процесса.
• Наличие специальных причин разрушает стабильность процессов.

Это показано в нижней части Рисунка 3.19.

Рисунок 3.20 «Прорывные результаты в Six Sigma».

Применение Six Sigma в разработке программного обеспечения

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

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

В контексте определения процесса, данного в этой главе, не важно, является ли процесс:

• импровизированным (ad-hoc),
• уникальным каждый раз,
• или высокоповторяющимся.

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

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

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

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

• занимать больше времени
• иметь больший риск, так как доступно меньше данных для статистического анализа.

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

Команды Six Sigma могут сосредоточиться либо на повторяющихся задачах в проекте (например, на проверках), либо на человеческих факторах. В любом случае важно правильно нормализовать данные, чтобы убедиться, что сравнения корректны.

В разработке ПО создается только одна мастер-копия. Ее дублирование простое и не приводит к вариациям в конечном продукте. Однако разработка отдельных компонентов ПО выполняется только один раз, и между этими компонентами могут быть различия.

Еще одним источником вариативности является внедрение ПО в среду пользователя.

Каркас Six Sigma

Компании, которые решают внедрить Six Sigma в свои организации, опираются на каркас Six Sigma, состоящий из нескольких важных компонентов.

Три основных элемента, которые определяют этот каркас:

• Приверженность высшего руководства
• Вовлечение заинтересованных сторон
• Стратегия улучшения

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

Все эти компоненты управляют тремя различными функциями Six Sigma:

• Проектирование по Six Sigma (Design for Six Sigma)
• Производственная Six Sigma (Manufacturing Six Sigma)
• Операционная (транзакционная) Six Sigma (Transactional Six Sigma).

Приверженность высшего руководства

Приверженность высшего руководства необходима, так как Six Sigma — это стратегическое управленческое решение, которое должно инициироваться топ-менеджментом.

Чтобы Six Sigma была успешной, все элементы каркаса (включая стратегию улучшения) требуют поддержки высшего руководства. Особенно важно, чтобы обучающие программы и деятельность проектных команд получали достаточное внимание. Без сильной поддержки сверху они редко оказываются успешными.

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

Для успеха инициативы Six Sigma требуется вовлечение не только высшего руководства, но и всех заинтересованных сторон.

В улучшение процессов по Six Sigma должны быть вовлечены:

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

Большая часть конкретных действий выполняется сотрудниками, которым нужна поддержка со стороны высшего руководства, например:

• доступ к обучающим курсам
• участие в проектных командах
• оценка эффективности процессов

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

Обучение и система поясов

Успех любой инициативы Six Sigma зависит от квалифицированных участников, таких как сотрудники.

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

• процесс работы проектных команд
• методы внедрения требований клиентов

Этот набор навыков редко бывает изначально доступен внутри компании, поэтому он должен развиваться через программы обучения и другие методы передачи знаний.

Для этого в Six Sigma предусмотрены стандартизированные уровни подготовки, обозначенные системой поясов из боевых искусств:

• Белые пояса (White Belts)
• Зеленые пояса (Green Belts)
• Черные пояса (Black Belts)
• Мастера черных поясов (Master Black Belts)
• Чемпионы (Champions)

Наибольшее значение имеют Зеленые и Черные пояса, так как именно они становятся ключевыми участниками команд Six Sigma.

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

Для работы проектных команд рекомендуется следующий порядок действий:

• Создать команду Six Sigma и установить долгосрочное управленческое видение для организации.
• Сначала обучить чемпионов Six Sigma.
• Выбрать бизнес-направления, в которых Six Sigma будет внедряться в первую очередь.
• Обучить Зеленые и Черные пояса.
• Назначить Черные пояса в качестве проектных менеджеров на полную занятость в критически важных процессах, чтобы сосредоточиться на ключевых проблемах качества.
• Укрепить инфраструктуру для поддержки Six Sigma, например, путем внедрения систем управления знаниями, статистического контроля процессов и систем управления базами данных.
• Убедиться, что высшее руководство следит за ходом работы команд Six Sigma. Ввести регулярный “День Six Sigma” и организовывать презентации или награждения за достижения.

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

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

Как уже было указано, стратегия улучшения основана на этапах DMAIC. Следующий раздел рассматривает их подробно.

Улучшение по DMAIC

Стратегия улучшения, представленная в предыдущем разделе, основана на шагах DMAIC — подходе, который также называется прорывным (Breakthrough) подходом.

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

• Требования, критичные для клиента
• Цели и задачи проекта
• Роли и обязанности команды
• Объем проекта и ресурсы
• Базовый уровень производительности процесса
• Карту процесса, включая поставщика, входные данные, процесс, выходные данные и клиента

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

• Устав проекта
• Анализ вовлеченности заинтересованных сторон
• Диаграммы аффинности
• Голос клиента (Voice of the Customer)
• Анализ качества
• Анализ силового поля (Force Field Analysis)
• Анализ Парето
• Картирование процесса

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

После выявления проблем в процессе следующий шаг — поиск корневых причин на этапе анализа (analyze phase). Возможности для улучшения приоритизируются по двум критериям:

• Их влияние на удовлетворенность клиентов
• Их влияние на прибыльность

На этапе улучшения (improve phase) внедряются выявленные на предыдущем шаге возможности для улучшения. Участники проекта разрабатывают несколько возможных решений и выбирают наиболее эффективное по результатам и производительности.

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

Последним шагом улучшения по DMAIC является этап контроля (control step). Его цель — контролировать улучшенные процессы и гарантировать устойчивость инициативы Six Sigma. Однако, если результаты улучшений, выполненных на предыдущих шагах, окажутся под угрозой, процесс улучшения DMAIC может начаться заново, как показано на Рисунке 3.21.

Применение Six Sigma к хранилищам данных

Оба типа встреч — обзор спринта (sprint review meeting) и ретроспектива (retrospective meeting) — являются обязательными, если организация стремится сократить длину итерации с четырех до трех недель или с трех до двух недель.

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

Если команды хотят сократить длину итерации, им необходимо проанализировать свою деятельность и определить, сколько времени уходит на каждую отдельную задачу. Затем команда определяет, на что уходит слишком много времени (например, на документацию, внедрение и т. д.) и разбирается, как сократить время на эти процессы.

В некоторых случаях технологии могут помочь, например, развертывание blue-green (описано в Главе 8 «Физический дизайн хранилища данных») или автоматизация ETL-процессов.

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

Еще одним фактором являются сами люди:

• Дополнительное обучение может сократить продолжительность процессов
• Дополнительные и более качественные ресурсы (технологические, организационные и человеческие) также могут ускорить работу

С учетом этого подхода разницы между разработкой ПО и разработкой хранилищ данных в контексте Six Sigma практически нет. Поэтому к хранилищам данных применяются те же концепции, что и в разделе [«Применение Six Sigma к программному обеспечению»](см. предыдущий раздел).

Всеобщее управление качеством (Total Quality Management)

Для достижения высочайшего качества менеджеры и команды часто обращаются к Total Quality Management (TQM) — набору теорий, методов, техник и стратегий управления качеством, предназначенных для конкуренции на мировом уровне.

TQM — это управленческий процесс, в котором основное внимание уделяется постоянному улучшению качества.

Термин «Total» (Всеобщее) в TQM указывает на то, что каждый сотрудник организации и каждая функциональная единица должны участвовать в непрерывном совершенствовании качества.

В этом смысле:

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

Типичные действия в рамках TQM:

• Проектирование экспериментов
• Круги качества
• Ценностная инженерия
• Затраты на качество
• Информационные системы
• Методы Тагучи
• Общее продуктивное обслуживание
• Статистический контроль процессов
• Гарантия качества
• Устойчивый (робастный) дизайн
• Компьютеризированное проектирование
• Развертывание функций качества
• Непрерывное улучшение
• Партисипативное управление (участие сотрудников в управлении)

Не включены деятельности, имеющие значение только для производственной отрасли, такие как планирование производственных ресурсов (MRP — Manufacturing Resource Planning).

Однако некоторые подходы могут быть адаптированы к хранилищам данных, особенно к системам DWH, построенным по стандарту Data Vault.

Кроме того, ряд концепций TQM уже описан в других частях этой главы (или будет рассмотрен в следующих разделах). Например:

• Партисипативное управление уже применяется в Scrum: вместо того чтобы принимать решения на высшем уровне организационной структуры проекта, полномочия передаются на более низкий уровень.
• То же касается TQM: ответственность за качество распределяется максимально низко.
• Члены проекта должны иметь право принимать обоснованные решения для улучшения качества продукта или услуги.
• Эти решения принимаются без предварительного одобрения со стороны руководства.

Типичные инициативы по внедрению TQM следуют поэтапному подходу, состоящему из пяти фаз, представленных на Рисунке 3.22.

Рисунок 3.22 Успешное внедрение TQM в пять фаз

Как показано на рисунке, пять фаз включают:

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

Однако не стоит путаться из-за Рисунка 3.22.

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

Измерения качества данных

Так как методология Data Vault 2.0 фокусируется на управлении качеством данных в рамках TQM, стоит рассмотреть две методологии, которые могут стать частью инициативы TQM в хранилищах данных.

Обе методологии основаны на объективной оценке качества данных.

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

Таблица 3.10 содержит список основных измерений качества данных.

Dimension (Измерение)	Definition (Определение)
Accessibility (Доступность)	Указывает, насколько данные доступны или могут быть легко и быстро извлечены бизнес-пользователем.
Appropriate Amount of Data (Соответствующий объем данных)	Предоставляет информацию о подходящем объеме данных для задачи бизнес-пользователя.
Believability (Правдоподобность)	Указывает, насколько данные считаются истинными и заслуживающими доверия бизнес-пользователем.
Completeness (Полнота)	Определяется степенью доступности данных, то есть отсутствием пропущенных данных и наличием данных в достаточной широте и глубине для выполнения задачи бизнес-пользователя. Это определяется как ожидаемая полнота. Отсутствие необязательных данных не влияет на полноту данных.
Concise Representation (Краткость представления)	Указывает, представлены ли данные в компактном формате.
Conformity (Соответствие)	Указывает, представлены ли данные в одном и том же, согласованном формате, если они доступны в нескольких местах. Обеспечивает соответствие стандартным определениям данных, включая тип данных, размер и формат.
Ease of Manipulation (Простота обработки)	Определяет, легко ли данные обрабатывать и применять к различным задачам.
Free-of-Error (Отсутствие ошибок)	Указывает, свободны ли данные от ошибок, а значит, являются правильными и надежными.
Integrity (Целостность)	Указывает, являются ли данные корректными в контексте их взаимосвязей.
Interpretability (Интерпретируемость)	Указывает, используют ли данные правильный язык, символы, определения и единицы измерения.
Objectivity (Объективность)	Определяет, насколько данные являются беспристрастными, непредвзятыми и объективными.
Relevancy (Актуальность)	Указывает, являются ли данные полезными и применимыми для задачи бизнес-пользователя.
Reputation (Репутация)	Предоставляет информацию о репутации источника или содержания данных.
Security (Безопасность)	Указывает, правильно ли защищены данные в плане ограничения доступа.
Timeliness (Актуальность по времени)	Предоставляет информацию о восприятии бизнес-пользователем своевременности и обновленности данных.
Understandability (Понятность)	Указывает, легко ли бизнес-пользователю понять данные.
Uniqueness (Уникальность)	Обеспечивает, что данные не хранятся избыточно.
Value-Added (Ценность добавленной информации)	Предоставляет информацию о выгодах и преимуществах данных для бизнес-пользователя.

Оценка измерений качества данных может быть:

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

Полное управление качеством данных (Total Data Quality Management)

Первая методология — Total Data Quality Management (TDQM), которая применяет человеческие и количественные ресурсы для улучшения продуктов и услуг, аналогично TQM.
TDQM поддерживает миграцию баз данных, продвигает использование стандартов данных и применение бизнес-правил для улучшения баз данных.

В TDQM существует четыре циклические фазы, представленные на Рисунке 3.23.

Рисунок 3.23. Фазы TDQM

Фаза определения – анализируются данные и собираются бизнес-требования.
Определяется информационная система производства данных.
На выходе получается логический и физический дизайн информационного продукта с атрибутами качества.
Создаётся E/R-модель качества, которая определяет информационный продукт и качество данных.

Фаза измерения – определяются метрики качества данных и выявляются проблемы качества после их анализа.

Фаза анализа – анализируются выявленные проблемы качества данных, и определяются первопричины ошибок.

Фаза улучшения – выбираются ключевые области для улучшения, а также разрабатываются стратегии и методы.
Эти стратегии и методы применяются в фазе определения, когда цикл TDQM начинается заново.

Качество хранилища данных (Data Warehouse Quality)

Вторая методология — Data Warehouse Quality (DWQ), разработанная в рамках европейского проекта по качеству хранилищ данных.
Хотя в DWQ используются те же фазы, что и в Total Data Quality Methodology, их значение и взаимосвязь отличаются.
Рисунок 3.24 показывает процессный поток методологии DWQ.

Рисунок 3.24. Фазы DWQ

Входными данными для фазы определения являются:

• определение данных из операционных систем,
• перспективы заинтересованных сторон,
• информация о проекте и контексте хранилища данных.

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

Бизнес-пользователи и другие заинтересованные стороны взвешивают эти измерения качества.

Фаза измерения использует измерения качества из фазы определения и определяет зависимости между ними.

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

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

Интеграция TQM с методологией Data Vault 2.0

В методологии Data Vault 2.0 TQM служит механизмом управления для применения гибких методологий, CMMI и Six Sigma.
Благодаря этому TQM связывает элементы улучшения из этих методов, чтобы постоянно совершенствоваться и превышать ожидания бизнес-пользователей, бизнес-спонсоров и других заинтересованных сторон.

TQM имеет несколько ключевых элементов, которые важны при внедрении ориентированного на клиента процесса постоянного улучшения:

• Ориентация на клиента: качество в контексте TQM определяется клиентом. В случае хранилищ данных бизнес-пользователь определяет качество артефактов, создаваемых в проекте хранилища данных. Поэтому именно пользователи решают, стоит ли усилие команды хранилища данных, обучение, постоянное совершенствование процессов и повышение качества затраченных ресурсов.
• Всеобщее вовлечение сотрудников: для достижения высшего качества артефактов хранилища данных каждый сотрудник должен участвовать в процессах постоянного улучшения. Руководство обязано создать необходимые условия для поддержки этих усилий. Процессы непрерывного улучшения должны быть интегрированы в обычные бизнес-операции.
• Ориентация на процессы: аналогично Six Sigma, TQM фокусируется на процессах. Это идеально подходит для Data Vault 2.0, где четко определенные процессы с четкими этапами приводят к ожидаемым результатам. Показатели производительности контролируются постоянно. Если возникают неожиданные отклонения от ожидаемых результатов, они фиксируются и передаются в управление проектом.
• Интеграция: TQM не ограничивается одной функциональной командой. Для достижения всеобщего качества требуется интеграция различных функциональных подразделений, обеспечивающая их взаимосвязанную работу.
• Стратегический и системный подход: тотальное качество не достигается случайно. Оно является результатом стратегического планирования и управления и включает интеграцию качества в стратегический план организации.
• Постоянное улучшение: TQM невозможно без непрерывного повышения возможностей организации. TQM управляет этими постоянными улучшениями.
• Принятие решений на основе фактов: процесс улучшения основывается на измерениях производительности. Для этого организация должна постоянно собирать и анализировать данные.
• Коммуникация: эффективная коммуникация необходима для поддержания мотивации сотрудников на всех уровнях организации.

Обсуждаемые в начале этого раздела встречи должны интегрировать эти элементы, чтобы быть успешными с точки зрения TQM.

Иногда, когда в отчетах или OLAP обнаруживается ошибочная информация, организация не следует рекомендованному подходу TQM для определения первопричины ошибки и ее устранения (вероятно, в исходной системе или бизнес-процессах). Вместо этого организация принимает решение исправить ошибку где-то между исходной системой и конечными отчетами. Если выбран такой подход, то единственно допустимый способ исправления ошибки в хранилище данных — применение мягких бизнес-правил на выходе из Raw Data Vault, например, используя Business Vault или при предоставлении информационного хранилища.
В главе 13 «Реализация качества данных» показано, как реализовать управление качеством данных в хранилище. Однако, с точки зрения TQM, цель этих усилий — создание замкнутого цикла процесса. Это достигается путем вовлечения бизнес-пользователей в выравнивание данных в исходных системах и исправление ошибок непосредственно в исходных системах, а не в хранилище данных.

Однако TQM — это не просто исправление качества данных (DQ). Хотя TQM включает в себя мероприятия, связанные с качеством данных, его суть заключается в идентификации ошибок в отчетах, анализе данных и оформлении запросов на изменения в исходных системах для исправления процессов, данных или обоих аспектов одновременно.
Без замкнутого цикла обработки (как описано выше: пользователи исправляют и согласовывают наборы данных в исходных системах) это превращается в простое управление качеством данных (DQ). Вместо этого TQM требует вовлеченности людей, а также замыкания цикла между исходными системами и уровнем представления за счет обратной связи и устранения ошибок, что позволяет устранить разрывы во всей системе.

Глава 9 расскажет о управлении эталонными данными (MDM), которое позволяет бизнес-пользователям участвовать в управлении данными и требует взаимодействия «менеджмента» и управления качеством данных. Эти же принципы применяются для устранения разрывов и согласования всех исходных систем в соответствии с концепцией эталонных данных, определяемой бизнес-пользователями.

В этой же главе рассматривается управляемая самостоятельная аналитика BI (Managed Self-Service BI), которая позволяет бизнес-пользователям напрямую взаимодействовать с данными в корпоративном хранилище, вносить исправления в режиме реального времени, а также публиковать сообщения, создаваемые в процессе Managed Self-Service BI. Эти сообщения передаются обратно в операционные системы через Service-Oriented Architecture (SOA) и Enterprise Service Bus (ESB).

Для этого необходима функция обратной записи (write-back capabilities), которая позволит бизнес-пользователям вносить исправления в исходные системы.