Приложение 1 – Матрица RACI для работ по миграции
advertisement
Правительство Российской Федерации Федеральное государственное автономное образовательное учреждение высшего профессионального образования "Национальный исследовательский университет "Высшая школа экономики" Факультет Бизнеса и менеджмента Школа бизнес-информатики Кафедра управления информационными системами и цифровой инфраструктурой ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА (МАГИСТЕРСКАЯ ДИССЕРТАЦИЯ) На тему РАЗРАБОТКА МЕТОДИКИ ПРОВЕДЕНИЯ МИГРАЦИИ ДАННЫХ В ПРОЕКТАХ ВНЕДРЕНИЯ КИС Студентка группы № 244-М Верник А.А. Руководитель ВКР к.т.н., доцент, Моргунов А.Ф. Москва, 2015 г. Аннотация Данная работа посвящена исследованию проблем, возникающих в проектах внедрения корпоративных информационных систем, целью которых является замена или модернизация эксплуатируемых ИС. Анализ проблем направлен на изучение этапа миграции данных из эксплуатируемых систем во внедряемую систему. Цель работы – разработка обобщенной методики проведения миграции данных, которая бы позволила решить выявленные в ходе анализа проблемы, а также учесть индивидуальные особенности каждого проекта по миграции данных. Предложенная в работе методика может быть применена в других проектах по миграции данных как инструмент планирования, организации работ, разработки требований бизнеса и оценки результатов миграции данных. Ключевые слова Проект внедрения, миграция данных, корпоративные информационные системы, разработка требований к миграции данных, методика проведения миграции данных, типовые риски проекта, стратегии работы с рисками, планирование миграции, тестирование результатов миграции, миграционное ПО, проектирование миграционного ПО, план коммуникаций, структура работ по миграции. 2 Содержание Термины и сокращения ...................................................................................... 5 Введение............................................................................................................... 6 Миграция данных в проектах внедрения КИС ..................................... 10 1. 1.1. Цели и стратегия процесса миграции данных в проектах внедрения ИС ........................................................................................................... 10 1.2. Этапы процесса миграции данных в проектах внедрения ИС ...... 14 1.3. Особенности планирования миграции данных ............................... 18 1.4. Особенности разработки бизнес-требований к миграции данных21 1.5. Постановка задачи на разработку методики проведения миграции данных 26 Анализ проектного опыта проведения миграции данных ................... 29 2. 2.1. Краткая характеристика проекта внедрения ИС ............................ 29 2.2. Выявленные проблемы при разработке плана работ и коммуникаций на этапе миграции данных ........................................................... 31 2.3. Выявленные проблемы при разработке требований к выгрузке из системы-источника .................................................................................................. 35 2.4. данных Выявленные проблемы документирования требований к миграции 40 2.5. Выявленные проблемы при тестировании загруженных данных в систему-приемник ................................................................................................... 44 3. Методика организации проведения миграции данных ........................ 51 3.1. Последовательность шагов для организации миграции данных .. 51 3.1.1. Разработка общих требований к миграции данных ................... 51 3.1.2. Организация планирования работ по миграции данных ........... 53 3 3.1.3. Разработка и документирование бизнес-требований к миграции данных 57 3.1.4. Проведение тестирования в рамках работ по миграции данных 66 3.2. Оценка применения разработанной методики организации и проведения миграции данных ................................................................................ 69 Заключение ........................................................................................................ 74 Список использованных источников .............................................................. 75 Приложения ....................................................................................................... 77 Приложение 1 – Матрица RACI для работ по миграции данных............. 78 Приложение 2 – Пример трассировки требований к миграции данных .. 79 Приложение 3 – Примеры схем жизненного цикла сущностей в системеисточнике .................................................................................................................. 81 Приложение 4 - Фрагмент лога утилиты миграции ................................... 83 Приложение 5 - Журнал тестирования результатов миграции................. 84 Приложение 6 - Результаты апробации разработанной методики ........... 85 4 Термины и сокращения Термин/ Сокращение Маппинг Определение/Расшифровка - Соответствие атрибутов системы-источника атрибутам системы-приемника Технологический - регламент/ ТР Документ в составе комплекта проектной документации, регламентирующий работы со строительными объекте строительства ФС - Функциональная спецификация ER - Entity - relationship MSF - Microsoft Solution Framework RACI - Responsible Accountable Consult before doing Inform after doing UML: - Unified modelling language 5 правила отходами на Введение Исследование проблем проведения проектов внедрения корпоративных информационных систем являются актуальными для возможного исследования в силу возрастающего интереса заказчиков к проектам внедрения КИС, целью которых является замена эксплуатируемых информационных систем, что подтверждается аналитикой CNews [15]. Аналитики CNews отмечают следующие особенности и тренды в поведении заказчиков: Заинтересованность в качестве результата проекта; Направленность проектов на оптимизацию существующих бизнеспроцессов, в том числе за счет совершенствования существующих средств автоматизации; Повышенное внимание заказчика к качеству управления проектом внедрения ИС. Еще одним поводом для исследования являются показатели качества осуществленных проектов. По данным аналитического издания PCWeek [13] неудачными оказываются до 75% всех ИТ-проектов. В настоящее время довольно большое количество заказчиков уже имеет внедренные информационные системы, поэтому миграция данных является неотъемлемой частью таких проектов. Результаты проведения этапа миграции данных имеют влияние на дальнейшие этапы проекта, как правило, являются условием приемки системы в промышленную эксплуатацию. Миграция данных является обязательной частью большинства проектов. В частности, в соответствии с законодательством РФ, подробный анализ которого в этой сфере будет проведен позднее в работе, организации государственного сектора не имеют возможности отказаться от части исторических данных и обязаны перенести электронные архивы в новую информационную систему. В случае негосударственных организаций процесс работы с историческими данными может регулироваться внутренними корпоративными политиками и регламентами, а также политиками клиентов этих организаций. Таким образом, 6 проблемы, возникающие на этапе миграции исторических данных, являются актуальными и могут стать материалом для дальнейшего исследования темы. При рассмотрении аналитических материалов по вопросам миграции данных, становится очевидным следующее существующее противоречие: разрабатываются частные программные решения и методические материалы в области миграции данных, но в то же время отсутствует общий подход к разработке требований практических к наработок процессу миграции. Существует ведущих мировых вендоров целый ряд программного обеспечения, например, IBM Best Practices или Oracle White paper, однако отсутствует обобщенный подход к организации миграции данных, который бы учитывал многообразие особенностей заказчиков и проектов. Соответственно, можно сделать предположение о том, что предложенная проблема исследования является недостаточно изученной. Объектом настоящего исследования являются проекты по модернизации или замене уже внедренных информационных систем. Предмет исследования – этап миграции данных в проектах по замене эксплуатируемых информационных систем и подходы к организации работ данного этапа проектов. Целью работы является разработка методики организации процесса миграции данных из эксплуатируемой информационной системы во внедряемую информационную систему. Общая цель работы может быть детализирована с учетом этапов проведения миграции данных, а именно: предложить подходы к планированию этапа миграции данных, описать методику разработки требований к миграции данных, разработать подходы к тестированию и оценке результатов этапа миграции данных. В качестве гипотезы исследования рассматривается следующий тезис: может быть разработана методика организации этапа миграции данных, который позволит повысить качество разработки бизнес-требований к процессу миграции и снизить вероятность «срабатывания» рисков данного этапа. 7 Для достижения цели работы необходимо последовательное решение следующих задач исследования: 1. Выявить наиболее «узкие» места процесса миграции, порождающие риски для бизнеса. 2. Проанализировать существующие методологии проведения миграции данных, лучшие практики вендоров ПО для миграции данных. 3. Выявление особенностей заказчика, влияющих на организацию миграции данных и формирование пакета требований к миграции данных. 4. Выявление проблем бизнеса, возникающих при миграции данных, которые не могут быть решены с помощью существующих средств автоматизации; 5. Разработка методики организации процесса миграции данных, которые позволят устранить выявленные проблемы бизнеса на всех этапах миграции (планирование, сбор требований, проектирование, реализация, тестирование); 6. Оценка разработанных подходов и методов организации и проведения миграции данных. В качестве предпосылки для проведения исследования принимается необходимость мигрировать накопленные в существующей системе данные в новую систему. Проведение данного этапа работ требуется не во всех проектах, однако для целей настоящего исследования стоит предположить наличие такой потребности у заказчика. В качестве теоретической базы для исследования используются методология разработки требований, сформулированная К. Вигерсом в книге «Разработка требований к программному обеспечению» [12], а также основные принципы методологии MSF, методы решения проектных задач этапа миграции данных, изложенные в White Paper вендоров ПО IBM [4] , Oracle [3], Microsoft [5]. Результатом работы должна стать методика организации процесса миграции данных. Ожидаемый результат работы является новым, так как каждый проект по миграции данных обладает индивидуальными особенностями, 8 в то же время разрабатываемая методика должна позволять учесть такие особенности проекта и нивелировать потенциальные риски проекта. В частности, будет предложен набор инструментов планирования и структурирования работ этапа миграции данных, ряд методов разработки требований к программному обеспечению, специфических для этапа миграции данных. Такой набор инструментов будет предложен для каждого этапа миграции данных. Ожидаемыми результатами работы является методика организации миграции данных, которая будет опробована в организации-заказчике определенного типа (государственное предприятие). Полученные результаты могут быть использованы при организации проектов, в рамки которых входит миграции данных. Предложенные автором подходы и способы решения проектных задач могут являться способом снижения рисков бизнес-заказчика, возникающих при ошибках, допущенных в ходе миграции данных из эксплуатируемой ИС во внедряемую ИС. Структура работы предполагает последовательное описание этапов решения поставленных задач исследования. В первой части работы будет приведен обзор существующих методик проведения миграции данных. Вторая часть работы будет посвящена анализу предметной области проектов, а также выявлению типичных проблем этапа миграции данных, которые не могут быть решены с помощью существующих инструментов и методов, проанализированных в первой части работы. Третья часть исследования будет описывать последовательность шагов, которые позволят оптимизировать процесс миграции данных и решить проблемы бизнеса, обозначенные во второй части работы. В третьей части работы будет проведена оценка предложенной методики организации и проведения миграции данных, проведенная на основании апробации этой методики в рамках реального проекта. 9 1. Миграция данных в проектах внедрения КИС 1.1. Цели и стратегия процесса миграции данных в проектах внедрения ИС Миграция данных – процесс переноса информации при смене информационной системы, хранилища или изменении версии приложения. Процесс миграции данных, как правило, является частью одного из этапов проекта внедрения корпоративной информационной системы, однако проведение этого процесса может являться целью для отдельного проекта. Внедряемая информационная система должна заменить систему или системы, находящиеся в эксплуатации в настоящее время. По завершении проекта внедрения КИС, как правило, дальнейшая эксплуатация существующих систем в организации-заказчике не планируется. В терминах процесса миграции данных эксплуатируемая система или системы являются системами- источниками. Внедряемая система является системой-приемником. Внедряемая система должна заменить автоматизированные функции систем-источников, соответственно, внедряемая система будет использовать исторические данные, накопленные в двух эксплуатируемых системах. Наличие этапа миграции данных в проектах внедрения КИС определяется соответствующими бизнес-требованиями. Необходимость мигрировать данные возникает при решении одного из следующих случаев: - Создание новой системы в результате кардинального изменения требований заказчика. Такая ситуация может возникать при критических запросах на изменение функциональных требований, изменения внешних факторов, влияющих на бизнес, и недостаточной гибкости используемого решения. - Слияние организации) бизнес-единиц вызывает (отделы, необходимость 10 департаменты использовать или единую информационную систему вместо нескольких систем, с которыми ранее работали сотрудники заказчика. - Изменение ИТ-инфраструктуры при использовании текущих КИС. Здесь речь идет о необходимости миграции данных из разрозненных систем при создании общего корпоративного хранилища данных (data warehouse) для хранения данных из корпоративных приложений. При решении перечисленных выше задач необходимо определить стратегию миграции, руководствуясь принципами которой, будут проводиться работы по миграции данных. Эксперты Oracle [3] определяют два типа стратегий: стратегия «большого взрыва» (big bang) и стратегия плавной миграции (trickle migration). В первом случае миграция производится единовременно, при миграции происходит остановка работы системы-источника и целевой системы. Такой подход может показаться привлекательным в силу снижения временных затрат на проведение процесса миграции, однако осуществление миграции по принципу «большого взрыва» довольно часто является рискованным решением. В первую очередь риски связаны с затруднениями в работе организации во время остановки систем. Как правило, бизнес-заказчики отказываются от остановки информационных систем. Для осуществления эффективного процесса миграции необходимо предпринять, по крайней мере, одну тестовую попытку, прежде чем мигрировать реальные данные. Помимо времени на тестирование необходимо учесть при планировании возможную дополнительную дату миграции – резервный день – требуемый для повторной миграции в случае первой неудачи. Спланировать проведение такого процесса довольно сложно без значительных потерь работоспособности бизнеса в момент миграции, поэтому качество мигрированных данных при таком подходе, как правило, страдает из-за недостаточно тестирования и нехватки времени для валидации результатов миграции. 11 При использовании стратегии плавной миграции данных системаисточник и целевая система работают параллельно, работа приложений не приостанавливается, что обыкновенно позитивно воспринимается заказчиками. Применение такого подхода, скорее всего, приведет к усложнению средств миграции, так как понадобится в реальном времени отслеживать наборы данных, которые были мигрированы, а также контролировать изменения в данных, сделанные пользователями системы-источника. При плавной миграции процесс переноса данных может быть синхронизирован с процессом переключения групп пользователей на работу с новой системой. При постепенном переключении групп пользователей на работу с целевой системой происходит параллельная эксплуатация обеих систем, что может сказаться на сохранности мигрируемых данных. Изменения в мигрируемыех данных могут быть внесены за время параллельной работы двух систем, что приведет к повторной миграции этих данных. При формулировании стратегии миграции данных существует ряд типовых рисков, которые требуют дополнительной оценки и могут привести к проблемам в ходе реализации процесса миграции. Согласно экспертам Oracle [3] типичные проблемы, возникающие при формулировании стратегии миграции данных, можно разделить на несколько групп: 1. Риски составления технической спецификации В техническую спецификацию для миграции данных входит описание наборов, типов и форматов данных, а также алгоритмы миграции. При составлении технической документации этапа миграции обыкновенно мало внимания уделяется информационному изучении обеспечению документации по системы-источника. функционалу При и составлении спецификаций может быть использована нерепрезентативная или недостаточная по объему выборка данных из старой системы, соответственно, могут быть упущены детали. Фокус смещен в сторону технических, а не бизнес-требований 12 к новой системы, такая ситуация приводит к некорректному маппингу данных и ошибкам при миграции. Риски тестирования 2. Риски этапа тестирования чаще всего связаны с недостатком времени, такая ситуация складывается не только при миграции данных, но может быть характерна, в целом, для всего проекта. Этап миграции требует тщательного тестирования на больших объемах данных, зачастую же используются юниттесты, результаты которых не могут быть в данном случае достаточными. Риски процесса получения и загрузки данных 3. Как правило, при миграции данных может быть упущен этап валидации данных, полученных из системы-источника. Это упущение может привести к непредвиденному развитию событий при загрузке информации в новую систему. Такая ситуация может возникать, когда в системе-источнике существовали ошибки соответствия метаинформации и контента, а алгоритмы миграции были спроектированы, исходя из метаданных о контенте. Риски размещения данных в целевой системе 4. Некорректно проведенная загрузка данных при миграции может привести к следующим негативным последствия: некорректная работа функциональности целевой системы в связи с конфликтами и ошибками, вызванными загруженными данными. Для решения проблем требуется дополнительное время на разработку обходных путей решения проблем путем доработки функциональности целевой системы, очистки или дополнительной конвертации загруженных данных. Итогом описанных сбоев и ошибок является снижение эффективности работы новой ИС, недовольство пользователей системы и убытки бизнеса. 5. Риски, связанные с работой проектной команды Этап миграции данных, как и любой другой этап проекта внедрения информационной системы, требует четкого распределения ролей в проектной команде и привлечения всех заинтересованных 13 сторон. Отсутствие вовлеченности бизнес-пользователей новой системы в процесс миграции приводит к упущениям при сборе требований и повышает риски возникновения ошибок. При разработке алгоритмов переноса данных требуется привлечение экспертов, обладающих знаниями о структуре и назначении данных для миграции. Таким образом, смещение ответственности в сторону технических специалистов, работающих только с целевой, новой системой является распространенным, но нерациональным решением. Формулировка стратегии и оценка рисков этапа миграции являются одними из наиболее важных шагов при осуществлении миграции данных. Результаты мероприятий по оценке рисков и выбора стратегии – это входные данные для этапа планирования процесса миграции. 1.2. Этапы процесса миграции данных в проектах внедрения ИС Процесс миграции данных может являться одним из этапов проекта внедрения ИС, а может быть организован как отдельный проект. Под процессом миграции данных в рамках настоящей работы будем подразумевать проектные работы, покрывающие полный цикл задач, связанных с миграцией данных: от планирования работ по миграции данных до оценки результатов этапа миграции данных. В любом случае процесс миграции данных распадается на несколько взаимосвязанных последовательных этапов, в настоящем исследовании будут последовательно рассмотрены все шаги процесса миграции по методологии Oracle и IBM [3, 4]. Жизненный цикл процесса миграции начинается после формирования стратегии и оценки рисков этапа миграции данных. Схема процесса миграции представлена на диаграмме процесса (см. Рис. 1). 14 Формулировка стратегии Подготовительный этап Перенос и загрузка данных Пост-миграционный этап - Определение рамок - Оценка рисков - Планирование работ - Разработка требований заказчика - Анализ и проектироание - Выгрузка данных - Валидация на входе в целевую ИС - Загрузка данных - Опытная эксплуатация, тестирование Поддержка и доработки Оценка результатов миграции данных Рис. 1 - - Жизненный цикл процесса миграции данных Целью любого процесса миграции данных является маппинг информации, типов и форматов данных старой системы с типами и форматами данных новой системы. При миграции данных этапу «Data Extraction» соответствует выбор и выгрузка данных из старой системы, а этапу «Data Loading» соответствует перенос полученных данных старой системы и их загрузка в новую систему. Ниже процесс миграции будет рассмотрен более детально. После завершения этапа планирования миграции данных наступает этап определения требований к мигрируемым данным. Этот этап включает в себя разработку требований заказчика и описание их в соответствующих проектных документах. На этапе сбора требований ответственной ролью в команде проекта за результат этапа является бизнес-аналитик или системный аналитик. Подробнее этот этап миграции будет освещен в третьей главе настоящей работы. Выходной информацией этапа определения требований к данным для миграции является описание структуры и состава данных для миграции. 15 Этап сбора требований к данным для миграции, как правило, очень тесно взаимосвязан со следующим этапом – разработки алгоритмов переноса данных из системы-источника в целевую систему. На этапе проектирования аналитиками создаются подробные спецификации с описанием типов данных системы-источника и их взаимосвязей с типами данных целевой системы. В таких спецификациях описывается структура данных для миграции, их объемы, источник, назначение. Спецификация является источником для постановки задач разработчику, который будет проектировать и разрабатывать специализированное ПО для переноса данных. На этапе проектирования проводится анализ существующей архитектуры данных в системе-источнике – анализ «as is» и разработка архитектуры данных в целевой системе – «to be». При анализе существующей архитектуры данных выявляются и учитываются все ограничения и ИТ-инфраструктуре, а также их влияние на работу целевой системы с мигрированными данными. Выходными артефактами анализа архитектуры данных могут являться такие документы, как логические модели данных (ER-диаграммы, модели баз данных), словари и справочники с детальным описанием каждого элемента и его атрибутов, описание бизнесправил работы с данными, сведения о системах, взаимодействующих с системой-источником при информационном обмене и интеграции. Результаты сбора требований и проектирования являются основаниями для выбора метода и определения технологии миграции данных. Миграция может осуществляться в режиме «оффлайн» или «онлайн», категоризация методов зависит от того, поддерживается ли работоспособность приложений в течение процесса миграции. Выбор метода и средств миграции определяется совокупностью факторов, в числе которых доступное время простоя систем, зависимость бизнеса от партнеров, объем данных, физическое размещение хранилищ данных системы-источника, политика информационной безопасности системы-источника и целевой системы. 16 Описанные выше этапы анализа и планирования можно объединить в общий подготовительный этап. Разработанные процедуры и механизмы миграции регламентируют этапы извлечения, переноса и загрузки данных в новую систему, то есть осуществляются последовательно все шаги ETLпроцесса. После получения необходимых для миграции данных наступает фаза загрузки этих данных в целевую систему, перед началом которой необходимо выделить отдельный этап – верификация мигрируемого контента. Проверка соответствия загружаемых данных требованиям может происходить в режиме «онлайн» - непосредственно на входе в целевую информационную систему или в режиме «оффлайн» - как промежуточный этап в процессе миграции. По завершении загрузки данных в целевую систему производится дополнительная проверка, зачастую, запускаются обе системы для параллельной работы. Тестовые мероприятия параллельной работы планируются при проектировании правил и процедур миграционного процесса. В рамках миграционного процесса параллельная работа двух систем может рассматриваться как опытная эксплуатация. Результатом опытной эксплуатацией может стать подтверждение полной работоспособности новой системы с мигрированными данными. В случае выявления массовых ошибок в ходе параллельной работы системы-источника и целевой системы может быть принято решение о повторной миграции данных и перезагрузке контента. Согласованные результаты миграции фиксируются в журнале опытной эксплуатации целевой системы с загруженными данными, выполненных тесткейсах, могут быть составлены опросные листы для проверки соответствия мигрированных данных требованиям целевой системы. Мероприятия тестирования не ограничиваются параллельной эксплуатацией системы-источника и целевой системы. Тесты могут проводиться на выборках из мигрируемых данных с целью раннего выявления ошибок и их исправления до начала разработки миграционного ПО. Более ранняя ликвидация ошибок позволяет экономить бюджет и избежать повторных загрузок данных. К 17 работам по тестированию могут быть отнесены мероприятия по аудиту данных в процессе миграции. Аудит данных позволяет отслеживать состояние данных и избежать ошибок, вызванных изменениями в контенте, которые могут быть внесены пользователями уже во время проведения работ по миграции. После согласования миграционных работ, результатов включающих миграции проверку, стартует очистку и этап пост- тестирование работоспособности целевой системы, в целом, после миграции данных. Очистка может происходить вручную или с помощью программных средств. Очистка данных производится для удаления устаревшей информации и удовлетворения требований к информационному обеспечению новой системы. Методология проведения миграции данных, приведенная выше, предполагает, что наиболее «узким» местом при организации данного этапа проекта является этап планирования и работы с бизнес-требованиями заказчика, то есть сбор требований и проектирование, поэтому рассмотрим подходы к решению задач этих этапов подробнее в следующих частях работы. Помимо этапов планирования и разработки бизнес-требований особое внимание стоит уделить этапу оценки результатов работ этапа миграции данных, так как в соответствии с циклом Деминга (PDCA) [16], именно проведение мероприятий по оценке работ является условием успешности проведения аналогичных работ в аналогичных проектах. 1.3. Особенности планирования миграции данных Планирование миграции данных является первым этапом жизненного цикла процесса и производится с учетом понимания основных рисков процесса и стратегии миграции. Входной информацией помимо стратегии миграции может являться раздел технического задания или документа о рамках всего проекта, посвященный миграции данных. На этапе планирования определяются рамки процесса миграции данных, устанавливаются достижимые в условиях проектных ограничения (источники данных, требования верхнего уровня) цели 18 процесса миграции данных. Для определения рамок процесса миграции целесообразно привлечение бизнес-пользователей, обладающих пониманием того, как система работала с данными в прошлом и как она должна работать с ними в будущем. Далее в зависимости от способа миграции устанавливается срок, и выделяются необходимые ресурсы в рамках заданного бюджета. При планировании миграции данных важными моментом является определение участников процесса со стороны заказчика, то есть тех бизнес-пользователей и технических специалистов заказчика, которые отвечают за управление данными. На выходе процесса планирования процесса миграции данных могут формироваться следующие проектные артефакты: - Документ о рамках миграции данных; - План работ по миграции данных с указанием ответственных членов проектной команды; - План коммуникаций на этапе миграции. Организация этапа миграции в проектах внедрения ИС начинается с этапа планирования, где необходимо составить план работ, рассчитать необходимые ресурсы и сроки выполнения. Пакеты работ на этапе миграции должны соответствовать фазам жизненного цикла процесса, примерная структура плана-графика работ может быть следующей: - Планирование и обозначение рамок миграции данных; - Бизнес-анализ и документирование требований; - Выбор, настройка или проектирование и специализированного ПО; - Перенос данных; - Валидация мигрированных данных; - Опытная эксплуатация; - Пост-миграционные работы по очистке и тестированию; 19 разработка - Согласование результатов миграции, оценка и закрытие этапа проекта внедрения. Назначение ответственных членов проектной команды за выполнение пакетов работ этапа миграции данных происходит на этапе планирования после составления плана работ. Выбранным проектным ролям приведены в соответствие кластеры – зоны ответственности, определенные в методологии MSF [6]. Стоит отдельно отметить, что под управлением продуктом в контексте миграции будем понимать управление качеством мигрированных данных и работоспособностью целевой системы после миграции. Управление релизами (выпусками) в терминах процесса миграции – осуществление итераций процесса миграции, получение и загрузка данных миграции. В соответствии с моделью MSF предполагается следующее распределение зон ответственности между ролевыми кластерами: - Системный аналитик - управление программой, удовлетворение потребителя; - Менеджер по разработке – управление программой, управление продуктом, управление выпуском; - Разработчик – разработка алгоритмов или специализированного ПО для переноса данных в целевую Систему, специализированного ПО (при необходимости); - Тестировщик – тестирование, управление выпуском. Для того чтобы наглядно продемонстрировать участие привлеченных человеческих ресурсов в мероприятиях процесса миграции данных составим матрицу RACI [13]– приведена в приложении 1 к работе (см. Приложение 1 – Матрица RACI для работ по миграции данных). Нужно оговориться, что менеджер по разработке (технический менеджер) рассматривается как лидер команды, занимающейся миграцией данных, поэтому он несет ответственность за проведение всего процесса, в целом. Однако если 20 миграция данных проводится в рамках масштабного проекта внедрения ИС, где назначен менеджер всего проекта, то технический менеджер этапа миграции будет только исполнителем в задачах, касающихся определения сроков и подбора персонала. Решения по вопросам персонала, ресурсов и сроков в таком случае принимается менеджментом проекта коллегиально. 1.4. Особенности разработки бизнес-требований к миграции данных Этап разработки требований бизнеса при миграции данных является ключевым при подготовке средств переноса данных, и именно от того, насколько качественно были собраны и проанализированы требования бизнеспользователей будет зависеть качество процесса миграции, в целом. Требования к миграции данных могут быть зафиксированы в различных проектных артефактах, рекомендации по разработке таких проектных артефактов будут приведены в Главе 3. Методологической базой для организации проектных работ по выявлению и разработке бизнес-требований к миграции данных могут служить различные стандарты. В рамках настоящего исследования теоретической базой для бизнесанализа является подход Карла Вигерса [12]. Для начала рассмотрим применение инструментария, рекомендуемого Вигерсом для моделирования бизнес-требований в контексте разработки требований к миграции данных. Рассмотрим ниже применение подхода Вигерса к разработке требований к миграции данных. Требования к миграции данных выявляются параллельно с разработкой функциональных требований к внедряемой системе. В процессе разработки функциональных требований обозначаются входные наборы данных для автоматизируемых бизнес-процессов, таким образом могут быть обозначены верхнеуровневые требования бизнеса к составу мигрируемых данных. Вигерс предлагает использование ER-диаграмм (диаграмма «сущностьсвязь») для определения логической структуры предметной области. Диаграмма 21 «сущность-связь» используется для построения модели данных предметной области. Логическая структура данных (концептуальная модель данных - КМД) позволяет описать предметную область работы системы в терминах объектов данных (сущностей). Использование модели данных в форме ER-диаграммы согласно Вигерсу позволяет облегчить процесс выявления требований к организации структуры данных в проектируемой системе за счет наглядности и относительной простоты изложения модели. Работая с ER-диаграммой «as is», ключевые бизнеспользователи смогут определить перечень объектов данных, которые необходимо перенести из системы-источника в проектируемую системуприемник. Помимо диаграмм «сущность-связь» в процессе выявления требований к миграции данных может использоваться другой инструмент моделирования – диаграмма смены состояний или диаграмма перехода состояний. Диаграмма перехода состояний позволяет получить точное, полное и ясное представление о механизме с конечным числом состояний. Диаграмма перехода состояний является частью подхода к моделированию – UML (unified modelling language) и позволяет наглядно представить жизненные циклы объектов данных. Переход в каждую следующую стадию жизненного цикла определяется определенным набором бизнес-правил. При разработке такой модели в ходе разработки функциональных требований к проектируемой информационной системе необходимо проводить сравнительный анализ такой модели с аналогичной моделью для эксплуатируемой системы. При модернизации ИС некоторые состояния объектов данных могут быть изменены или исключены, могут быть изменены правила смены состояний. Такие случаи должны быть учтены при разработке требований к миграции для того, чтобы корректно определить в каком состоянии объекты данных должны быть перенесены в системуприемник. Помимо этого, в требованиях к миграции данных необходимо учесть логические несоответствия, которые могут возникнуть из-за модернизации 22 правил смены состояний. Например, переход объекта данных в следующее состояние может зависеть от заполнения или значения какого-либо атрибута сущности. При разработке требований к системе-приемнику атрибутный состав сущностей может быть изменен таким образом, что данный атрибут будет исключен. В таком случае смена состояний для мигрированной сущности будет невозможна. Соответственно, в работе функциональности системы-приемника возникнут сбои и ошибки. Во избежание таких ошибок каждый подобный случай изменения атрибутного состава должен быть выявлен, а в требованиях к миграции данных должна быть отражена логическая проверка или правило обработки такой ситуации. Пример разработанной диаграммы состояний для одной из сущностей в системе-приемнике приведен в приложении 3 к работе (см. Приложение 3 – Примеры схем жизненного цикла сущностей в системеисточнике ). Выше было рассмотрено применение инструментария бизнес-анализа для выявления требований высокого уровня к миграции данных. Теперь более подробно проанализируем методологическую базу для детальной проработки потребностей бизнеса: в частности, для разработки требований к профилю мигрируемых данных. При взаимодействии с заказчиком по вопросам составления профиля данных для миграции требований аналитику необходимо получить информацию по следующим вопросам [3], [5]: 1. Что является источником данных: корпоративное приложение, система или источники за пределами организации-заказчика? 2. Будут ли мигрированные данные являться входными для работы какоголибо бизнес-процесса? 3. Каковы требования к данным в целевой системе? В каких процессах новой системы будут использоваться эти данные? Позволяет ли структура данных корректно работать с ними в целевой ИС (возможно ли соотнести структуру мигрируемых данных 23 и целевую модель данных)? Присутствуют ли в структуре данных поля и типы, которые невозможно заполнить в целевой структуре и – наоборот? 4. Каково качество данных? Соответствует ли текущий уровень качества данных уровню, необходимому для функционирования целевой системы? Есть ли критические ошибки (например, незаполненные обязательные поля, несоответствие типов данных в системе-источнике и системеприемнике). Существует ли необходимость в разработке процедур по улучшению качества данных до начала процесса переноса данных? 5. Позволяет ли метаинформация мигрируемого контента разработать алгоритмы миграции? Возможно ли произвести анализ структуры данных на основе метаинформации или необходимо производить анализ самого контента, предназначенного для миграции? 6. Оценка критичности ошибок при переносе данных в целевую систему. Будут ли эти данные использоваться в пользовательском интерфейсе или достаточно произвести валидацию на уровне БД? 7. Есть ли связь выбранных данных с историческими данными? Происходили ли за некоторый выбранный период (например, год или 5 лет) значительные изменения в бизнес-процессе, которые могут привести к изменениям в структуре или форме хранения выбранного элемента модели данных? 8. Каковы бизнес-правила работы с выбранными данными? 9. Кто является владельцем данных (контента, документов, изображений) и кто является ответственным за сохранность и качество выбранных данных? 10.Какие ограничения системы-источника отражаются на структуре данных, формах хранения и работы с данными? Сохранятся ли данные ограничения при работе с данными в целевой системе? 11.Существует ли необходимость в поддержке «онлайн» миграции данных? 24 12.Будут ли вноситься изменения в мигрируемые данные в течение процесса миграции? Существует ли необходимость в итеративном процессе выгрузки и загрузки данных? Выявленные потребности бизнеса должны быть зафиксированы и описаны в виде пакета требований к миграции. Взаимосвязь потребностей бизнеса и функциональных требований соблюдается в случае, когда функциональные требования являются трассируемыми. Помимо инструментов моделирования предметной области и бизнеспроцессов немалое внимание Вигерс уделяет такому понятию в работе с бизнестребованиями, как «трассируемость» требований. Трассируемость требований также означает, что возможно проследить взаимосвязь требований верхнего уровня, зафиксированных в концепции проекта или техническом задании, с более детальными требованиями к подсистемам и модулям, зафиксированными в функциональных и технических спецификациях. При разработке требований к миграции данных также должна соблюдаться трассируемость требований. Требования верхнего уровня, отражающие необходимость и стратегию миграции, фиксируются в документе о рамках проекта внедрения ИС или техническом задании. Потребность бизнеса в миграции данных из эксплуатируемой систем в проектируемую систему трассируется к пакету требований к миграции: составу мигрируемых данных, способу проведения миграции, конкретным правилам и сценариям миграции, которые описываются в техническом задании на реализацию ИС или технической спецификации процесса миграции. Инструментом для отслеживания трассируемости требований по Вигерсу может являться матрица трассируемости требований. С помощью матрицы трассируемости можно наглядно представить взаимосвязи между требованиями к разрабатываемому ПО. 25 В приложении 2 к работе (Приложение 2 – Пример трассировки требований к миграции данных) представлен пример - фрагмент составленной матрицы трассируемости требований к миграции данных. В приведенном фрагменте матрицы представлены различные типы пользовательских потребностей: Нефункциональное требование к способу проведения миграции; Требования непосредственно к функциям утилиты миграции данных; Бизнес-требование к функциональности проектируемой системы, связанное с функциональными требованиями к утилите миграции. В первой строке примера отсутствует тестовый сценарий, так как данная потребность пользователей трассируется к плану организации работ по миграции данных, а не к конкретному элементу утилиты миграции. Вигерс допускает такие исключения при составлении матриц трассируемости требований. Требования высокого уровня являются входящей информацией при планировании работ этапа миграции. При составлении плана коммуникаций проекта системным аналитиком и техническим менеджером для проведения обследования должны быть выбраны не только технические специалисты, но и бизнес-пользователи, причем как системы-источника, так и целевой системы. Прочие приведенные в матрице трассируемости пользовательские потребности и функциональные требования являются обобщенными примерами бизнес-требований, разработанных в рамках конкретного проекта по миграции. Характеристика этого проекта, а также детальный анализ проектного опыта миграции данных будет проведен в Главе 2. 1.5. Постановка задачи на разработку методики проведения миграции данных Ожидаемым результатом работы должна стать методика организации и проведения миграции данных. Такая 26 методика должна состоять из последовательности взаимосвязанных шагов, выполнение которых позволит спланировать, провести и протестировать результаты миграции данных. Каждая из частей методики должна содержать описание последовательности мероприятий для отдельного этапа миграции, а именно: планирование, разработка требований, проведение миграции (выгрузка и загрузка), тестирование результатов. Таким образом, предлагаемая в работе методика должна содержать рекомендации по выполнению задач каждого из этапов, представленных на схеме жизненного цикла миграции данных (Рис. 1). В первой части методики должны быть приведены и описаны способы разработки общих требований к миграции данных. В частности, в этой части методики должны быть описаны способы работы с потенциальными рисками этапа миграции данных. В этой же части методики также описывается взаимодействие с ключевыми пользователями с целью выявить требования к стратегии миграции и другие бизнес-требования высокого уровня. Вторая часть методики должна быть посвящена инструментам планирования и организации процесса миграции. На основе анализа проектного опыта выявляются наиболее «узкие» места процесса, для которых методика предлагает способы решения. Следующая часть методики должна покрывать этап обследования и разработки требований к миграции данных. Эта часть методики должна содержать указания по проведению мероприятий обследования (встречи, коммуникации других видов), а также по документированию результатов этапа – шаблоны документации и примеры заполнения. Заключительная часть методики проведения миграции должна содержать рекомендации по проведению миграции и тестирования на этапе миграции. Тестирование на этапе миграции делится на тестирования миграционного ПО, а также на тестирование работы системы-приемника после размещения в ней мигрированных данных. Данная часть методики должна содержать описание 27 способов контроля процесса миграции, выявления возможных дефектов и их причин. 28 2. Анализ проектного опыта проведения миграции данных 2.1. Краткая характеристика проекта внедрения ИС Проектный опыт, который будет рассмотрен в работе, - это несколько проектов миграции данных, проведенных в рамках портфеля проектов внедрения ведомственной информационной системы. В рамках анализа проектного опыта будет дана краткая характеристика проекта и рассмотрены некоторые особенности организации-заказчика. В рамках настоящей работы будет проанализирован проектный опыт внедрения информационной системы в государственной организации, входящей в систему органов исполнительной власти регионального уровня. Основной проект был разбит на несколько подпроектов, каждый из которых подразумевал автоматизацию группы бизнес-процессов заказчика. Соответственно, в каждом проекте предполагался перевод на работу с новой системой некоторой части бизнес-подразделений заказчика. В каждом из проектов была предусмотрена миграция накопленных в системах-источниках данных, с которыми работает соответствующее бизнес-подразделение. Основная деятельность организации такого типа связана с оказанием государственных услуг населению. В рамках настоящего анализа будет рассматриваться этап миграции данных в проектах по внедрению ИС, автоматизирующей именно этот вид деятельности организациизаказчика. В следующих частях работы для проведения более глубокого бизнесанализа и демонстрации практических результатов работы будет описана более узкая часть предметной области – на уровне оказания определенной государственной услуги. Для того чтобы подробнее описать профиль организации-заказчика, необходимо ввести несколько понятий. «Заявителем» или «публичным пользователем ИС» является лицо, обратившееся за оказанием государственной услуги. «Объектом данных» будем называть одну из сущностей или артефактов предметной области деятельности организации-заказчика. 29 «Системой- приемником» будем называть внедряемую корпоративную информационную систему, относящуюся к классу ECM. Заказчик эксплуатирует две отдельных информационных системы, не интегрированных между собой, для хранения контента и автоматизации основного бизнес-процесса. Эти системы будут являться источниками данных – «системами-источниками» для процесса миграции данных во внедряемую систему. Первая из двух существующих систем разработана на платформе IBM Lotus Notes и предназначена для автоматизации бизнес-процесса в одном из функциональных подразделений заказчика. Вторая система была разработана сотрудниками заказчика самостоятельно и предназначена для автоматизации бизнес-процессов в других бизнес-подразделениях и хранения документов в электронном виде, сбора и хранения отчетной информации по бизнес-процессам организации. Организационной особенностью ведения проекта является использование следующей модели распределения ответственности за результаты проекта между следующими основными участниками со стороны Заказчика: Функциональный заказчик несет ответственность за качественный результат проекта; Нефункциональный заказчик несет ответственность за финансовый результат проекта. Организация – функциональный заказчик является владельцем автоматизируемых бизнес-процессов. Сотрудники этой организации обладают знаниями специфики предметной области. Сотрудники функционального заказчика будут являться конечными пользователями внедренной информационной системы. Сотрудники нефункционального заказчика могут не обладать знаниями и глубокой экспертизой в узкой предметной области деятельности. В их обязанности входит контроль проведения проекта внедрения ИС с организационной точки зрения, организация постпроектной технической поддержки внедренной системы на стороне заказчика. Стоит также отметить, 30 что в зону ответственности нефункционального заказчика может входить надзорная функция за операционной деятельностью организации – приводило к функционального заказчика. Специфическое распределение ответственности возникновению конфликта интересов функционального и нефункционального заказчика в ходе проведения проекта. Такая организационная структура является источником риска при проведении миграции данных. 2.2. Выявленные проблемы при разработке плана работ и коммуникаций на этапе миграции данных При разработке плана работ на этапе миграции данных менеджмент проекта опирался на модель проектной группы MSF, а также использовал в качестве инструмента распределения ответственности матрицу RACI. Анализ такого подхода был проведен выше, в Главе 1. На этом же шаге была сформулирована стратегия проведения миграции данных в рамках проекта. Стратегия была выбрана, исходя из верхнеуровненвых требований функционального заказчика, который отказался приостанавливать бизнес-процесс для проведения работ по миграции. Таким образом, была выбрана стратегия «большого взрыва», единовременная миграция данных из двух источников в систему-приемник. Первоначальная иерархическая структура работ этапа миграции данных выглядела так, как показано на Рис. 2. 31 Миграция данных Обследование организациизаказчика Интервью с ключевыми пользователями системы Lotus Notes Интервью с ключевыми пользователями «сампописной» информационной системы Разработка требований к миграции данных Описание профиля данных для загрузки в системуприемник Разработка функциональ ной спецификаци и на утилиту миграции Разработка и настройка утилиты миграции Разработка ПО Тестовая выгрузка из системисточников Проведение миграции данных Тестирование загруженных данных Получение выгрузки из системисточников Выборочная демонстрация целостности и полноты мигрированных данных Ручные проверки полученной выгрузки Загрузка данных в системуприемник Первичное тестирование утилиты Рис. 2 - Разработанная в проекте иерархическая структура работ по миграции данных Согласно первоначальному плану проекта работы непосредственно по проведению выгрузки данных из систем-источников и загрузке данных в систему-приемник должны были занять 4 календарных дня. 3 дня были отведены на получение данных и загрузку файлов во внедряемую систему, а также 1 день был зарезервирован для снижения риска срыва работ по загрузке данных. Однако работы не были реализованы в срок: в ходе проекта сработало несколько рисков, обозначенных при анализе теории в Главе 1. Срыв сроков проведения работ в течение первого проекта по миграции данных произошел из-за некорректного планирования коммуникации с заинтересованными лицами на стороне заказчика. Как упоминалось выше, организация-заказчик имеет сложную организационно-штатную структуру. При планировании работ по обследованию и выбору пользователей для сбора бизнес32 требований необходимо было привлечь к обследованию заказчика сотрудников нефункционального заказчика. Именно эти сотрудники заказчика обладают знаниями в области надзора за деятельностью функционального заказчика. Так, сотрудники нефункционального заказчика обладали знаниями о требованиях к временному горизонту выгрузки данных из систем-источников. Требования к временному горизонту выгрузки могли быть разработаны на основе анализа нормативно-правовой базы и согласованы с сотрудниками нефункционального заказчика, однако эти работы не были запланированы и проведены. Таким образом, можно говорить сразу о двух проблемах этапа миграции: 1) Некорректное планирование плана коммуникации с сотрудниками заказчика; 2) Некорректное планирование работ в ИСР; 3) Неполные бизнес-требования к миграции данных, как следствие первой проблемы. В частности, выгрузка из систем-источников была получена только за последние 2 года работы деятельности функционального заказчика. В то же время выгрузка данных должна была охватывать гораздо более длительный период. Далее представим краткий обзор нормативно-правовой базы, регулирующей работу с данными в организации-заказчике. Органы исполнительной власти регионов РФ обязаны хранить исторические данные (архивы) в течение сроков, установленных ФЗ [16]. Таким образом, требования к составу выгрузки данных из систем-источников определяются в соответствии с регламентом хранения данных, который, в свою очередь, ссылается на федеральный закон. Помимо требований к составу выгрузки данных из системы-источника именно требования к временному горизонту хранения данных во многом определяют требуемый объем хранилища данных в системе-приемнике. 33 Более узкая предметная область, в которой работает функциональный заказчик, - оказание государственных услуг строительным и проектным организациям в области экологического надзора. В соответствии с ФЗ организация-заказчик обязана хранить: проектную документацию по капитальному строительству в течение 20 лет; технологическую и конструкторскую документацию в течение 20 лет. Организация-заказчик ввела в эксплуатацию существующие информационные системы в 2005 и 2000 годах, соответственно. Таким образом, в диапазон выгрузки для переноса данных в систему-приемник попадают все документы, хранящиеся в системах-источниках, а также все объекты, на которые ссылаются такие документы. Аналогично описанному выше примеру может быть произведен анализ норм законодательства для других организаций государственного сектора или коммерческих организаций, в случае если внутренние регламенты таких организаций составляются на основе федеральных законов. Помимо временного горизонта выгрузки из систем-источников федеральным законом определяются также требования к составу выгрузки из систем-источников: перечень наименований документов, необходимость переноса в новую систему их версий и дополнительных материалов – приложений, дополнений к каждому документу. Федеральным законодательством определены виды и состав документации, которую обязана хранить организация-заказчик. Соответственно, нормы ФЗ должны быть проанализированы с учетом особенностей деятельностей конкретного заказчика и состава документации, которая требуется для оказания определенного вида государственных услуг. Артефакты предметной области деятельности заказчика должны быть сопоставлены с нормами законодательства и объектами модели данных эксплуатируемой 34 системы-источника. Результаты такого анализа позволят определить состав выгрузки из системы-источника и определения требований к приемнику, а также к программному средству переноса данных. Возвращаясь к примеру организации, входящей в структуру Департамента строительства региона, в состав данных для переноса из системы-источника в систему-приемник могут быть определены такие объекты как: Электронные образы комплектов технологической, проектной и конструкторской документации объектов капитального строительства, а также объекты данных, хранящие информацию о соответствующих документах; Электронные образы распорядительной технологической документации и организационной- объектов переработки и захоронения строительных отходов, а также объекты данных, хранящие информацию о соответствующих документах; Электронные образы разрешительной документации, а также история выдачи дубликатов таких документов, а также объекты данных, хранящие информацию о соответствующих документах; История работы со всеми перечисленными выше видами документации, хранимая в системе-источнике. Таким образом, сработал риск некорректного планирования и, как следствие, частично сработал риск разработки неполных требований к выгрузке данных. Более подробно возможность «срабатывания» риска неполноты требований к выгрузке из систем-источников будет рассмотрен в следующей части работы. 2.3. Выявленные проблемы при разработке требований к выгрузке из системы-источника В рамках планирования работ по миграции данных в проекте отсутствовали работы по проверке данных, входящих в состав выгрузки из 35 систем-источников. Предполагалась валидация всего объема данных на входе в систему-приемник по модели данных внедряемой системы. Анализ качества алгоритмов логических проверок и валидации данных будет приведен в следующем разделе работы. В этой части работы анализируются подготовительные операции по получению данных из систем-источников и анализа состояния данных в этих системах. Для того чтобы исследовать состояние данных, выявить потенциальные проблемы размещения данных в системе-приемнике формируется тестовая выгрузка из систем-источников. Цель этого шага – успешно разместить тестовую выгрузку в системе-приемнике, выявить все потенциальные проблемы при загрузке данных и, таким образом, снизить риск неудачной миграции вследствие ошибок при загрузке невалидных данных в систему-приемник. Ниже проанализируем особенности эксплуатации систем-источников, которые привели к срабатыванию рисков процесса получения и выгрузки данных. Стоит отметить следующие особенности эксплуатируемых заказчиком информационных систем, которые должны быть учтены при анализе выгрузки из систем-источников, а именно: 1) Ведение словарей и справочников в информационных системах осуществляется различными пользователями, при этом отсутствуют проверки на заполнение обязательных атрибутов записей, а также отсутствуют автоматические проверки на создание дублирующих записей. Таким образом, в словарях и справочниках эксплуатируемых систем было создано большое количество невалидных записей, которые, тем не менее, использовались пользователями при работе с данными. С такими записями создавались связи, а также на эти записи проставлялись ссылки из других объектов данных. Наличие таких записей в словарях и справочниках эксплуатируемых системах означает необходимость разработки для них специального алгоритма миграции. 36 2) Правила работы с данными в системах-источниках и системе- приемнике отличаются в части работы с обязательными атрибутами. В системеприемнике были установлены более строгие правила и проверки правил заполнения атрибутов, соответственно, часть данных в составе выгрузки не отвечали требованиям системы-приемника и не могли быть корректно мигрированы без разработки специальных алгоритмов. 3) связями Системы-источники имеют особенности работы с ссылками и между объектами данных. Например, вместо уникальных идентификаторов в качестве ссылок (foreign key) на объекты использовались имена, не имевшие проверок на уникальность. Таким образом, способы создания ссылок и связей между объектами данных в системах-источниках должны быть проанализированы при получении данных из систем-источников для того, чтобы определить насколько представляется возможными мигрировать такие связи в систему-приемник. 4) Системы-источники имели гораздо менее строгую систему проверок данных по сравнению с системой-приемником. За счет более слабых проверок корректности работы с данными в объектах данных, записях классификаторов и словарей пользователями были допущены ошибки ручного ввода данных, которые потенциально могли препятствовать корректной загрузке таких данных в систему-приемник. Приведенные выше особенности эксплуатации систем-источников служат основанием для возникновения рисков получения данных, а также рисков некорректного размещения выгруженных данных в системе-приемнике. Для снижения таких рисков в плане работ по миграции данных были предусмотрены работы по анализу тестовой выгрузки данных, однако требования к тестовой выгрузке составлялись, исходя из объектной модели предметной области без учета приведенных выше особенностей функционирования систем-источников. 37 В состав тестовой выгрузки из систем-источников вошли следующие объекты: Пример классификаторов из двух систем, не дублирующих друг друга по смыслу. В состав выгрузки вошли два справочника из каждой системы: иерархический и плоский; Случайная выборка электронных документов различных типов из систем-источников без учета их состояний (статуса жизненного цикла) в системе-источнике и без проверки полноты заполнения обязательных атрибутов согласно правилам проектируемой системы. В состав выгрузки входили как минимум десять документов каждого типа из двух систем. Требования к тестовой выгрузке из систем-источников формировались вместе с разработкой объектной модели предметной области. Однако здесь сработал риск работы проектной команды и некорректного планирования работ. После согласования требований к тестовой выгрузке объектная модель продолжала дорабатываться, что в итоге привело к образованию в модели данных типов и сущностей, маппинг с которыми не был реализован в тестовой выгрузке. Таким образом, помимо проблем ограниченности и нерепрезентативности выборки данных тестовая выгрузка не соответствовала актуальной версии модели данных проектируемой системы, соответственно, успешное размещение такой выгрузки в системе-приемнике, не давало гарантии успешного размещения полного объема данных в системе-приемнике. Таким образом, тестовая выгрузка не смогла выявить все возможные проблемы размещения данных в системе-приемнике, что в итоге отразилось на целостности и полноте загруженных во внедряемую систему данных. Отсутствие проработки требований к миграции записей классификаторов и справочников из двух параллельно эксплуатируемых систем привело к тому, что сверку и поиск дублирующих записей, а также маппинг записей из двух систем пришлось производить вручную сотрудникам команды исполнителя. 38 Такой подход был выбран вследствие неполноты требований, зафиксированных в функциональной спецификации на утилиту миграции. Отсутствие анализа правил работы с данными в системах-источниках привело к ошибкам загрузки данных в систему-приемник и нарушению работы функциональности внедряемой системы. В частности, даже если объект данных с неполным составом заполненных обязательных атрибутов был загружен в систему-приемник, то работать с таким объектом в системе-приемнике не представлялось возможным. Экранные формы отображались некорректно, а также блокировалась работа с объектом данных в рамках автоматизированных бизнес-процессов. Например, в системе-приемнике продвижение сущности по ее жизненному циклу было возможно только при заполнении определенного набора обязательных атрибутов. В случае если мигрированный объект данных не обладал на момент переноса данных необходимым набором заполненных обязательных атрибутов, то работа с таким объектом данных в системеприемнике приводила к сбою работы функциональности системы-приемника. Описанная выше особенность создания связей между объектами данных в системах-источниках также не была учтена при формировании тестовой выгрузки, что в ходе миграции на продуктивной среде привело к потере ссылочной целостности. Этот риск можно было бы снизить в случае выявления проблемы на этапе анализа тестовых данных. Анализ неудачных проектов по миграции, вызванных неполной проработкой требований к тестовой выгрузке, показывает необходимость выделения в плане работ отдельного пакета работ, выходом которого должны являться документированные требования к тестовой выгрузке, разработанные на основе обследования эксплуатируемых систем, которые могут считаться полными только после окончательного составления модели данных внедряемой системы. 39 Выявленные 2.4. проблемы документирования требований к миграции данных В рамках плана проекта была запланирована работа по разработке документа, описывающего требования к миграции данных. Требования к миграции данных были зафиксированы в документе «Функциональная спецификация на утилиту миграции данных». Функциональная спецификация составлялась на основе применяемых ими методологий разработки ПО и государственных стандартов. Дальнейший анализ государственных стандартов будет проводиться рассмотренными в для того, главе 1 чтобы установить методологиями соответствие миграции между данных и государственными стандартами разработки ИС, а также для выявления проблем работ по документированию требований к миграции данных. Создание информационных систем в проектах, где заказчиком является организация государственного сектора, должно проводиться в соответствии с государственным стандартом - ГОСТ 34.601-90 Автоматизированные системы [8]. Стадии создания. Любая другая применяемая разработчиком методология создания ИС должна соответствовать основным положениям упомянутого выше государственного стандарта. Этапы процесса миграции данных, описанные нами в главе 1, можно соотнести со стадиями разработки информационной системы, обозначенными в ГОСТ 34.601-90. Формулировка стратегии миграции данных может осуществляться на стадии «Обследование объекта и обоснование необходимости создания в АС». Однако в соответствии с государственным стандартом на этой стадии не предусмотрено работ по оценке рисков бизнеса при выбранной стратегии миграции. Следующий этап процесса миграции данных - подготовительный этап – может соотноситься со стадиями «Формирование требований пользователя к АС», «Разработка и утверждение технического задания на создание АС» и 40 «Разработка предварительных проектных решений по системе и её частям». На практике в техническом задании фиксируются только высокоуровневые требования к миграции данных. В ТЗ могут быть определены рамки миграции и закреплены требования по способу проведения миграции: в одну или несколько итераций, «онлайн» или «оффлайн». Таким образом, требования к профилю данных для переноса в целевую ИС, их составу, качеству, временному горизонту выгрузки остаются за рамками технического задания и должны быть зафиксированы в других проектных артефактах. Более подробный анализ государственного стандарта «ГОСТ 34.201-89 Виды, комплектность и обозначение документов при создании автоматизированных систем» [10] приведен ниже. Работы по переносу и загрузке данных совпадают со стадиями «Разработка предварительных проектных решений по системе и её частям», «Разработка проектных решений по системе и её частям» и «Подготовка объекта автоматизации к вводу АС в действие». Стадиям разработки предварительных проектных решений и проектных решений соответствуют работы по подготовке утилиты миграции. Работы по загрузке данных в целевую ИС и тестирование работоспособности целевой ИС с загруженными данными должны производиться на стадии подготовки объекта автоматизации к вводу АС в действие. Проектная документация в проектах по созданию и внедрению КИС в организациях государственного сектора, как правило, разрабатывается в соответствии с государственными стандартами (ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы, ГОСТ 34.201-89 Виды, комплектность и обозначение документов при создании автоматизированных систем). Рассмотрим подробнее, в каких проектных артефактах согласно ГОСТ 34.602-89, ГОСТ 34.201-89, а также ГОСТ 19.101-77 [11] должны быть зафиксированы бизнес-требования к миграции данных. 41 Документирование требований к миграции данных должно производиться на стадии разработки и создания технического проекта и рабочего проекта информационной системы. Требования к утилите миграции должны разрабатываться на основе информации о состоянии данных в системеисточнике – «as is». Описание объекта автоматизации «as is» содержится в разделе «Характеристика объекта автоматизации», однако согласно государственному стандарту ГОСТ 34.602-89 этот раздел должен содержать «краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию». Соответственно, в этот раздел не будет включено описание логической структуры данных системы-источника, необходимое для формирования требований к выгрузке и проверкам качества и полноты данных. Требования к работе с данными в целевой системе, их логической структуре, типам и структурам могут быть зафиксированы в документе технического проекта «Описание организации информационной базы». Требования к использованию данных в качестве входной информации в бизнеспроцессах, автоматизируемых с помощью целевой системы, могут быть закреплены в документе «Описание автоматизированных функций». Здесь же должны быть зафиксированы требования к бизнес-правилам работы с данными. Специфические требования к миграции данных, например, необходимость поддержки «онлайн» миграции данных или ограничения процесса миграции (внесение бизнес-пользователями изменений в мигрируемые данные в течение процесса миграции) не находят отражения в составе документации технического или рабочего проекта создания информационной системы. Таким образом, анализ государственных стандартов, регулирующих создание информационных систем и документирование требований к ПО, позволяет сделать вывод о том, что требования к утилите миграции разрабатываются на основе модели данных и требований к данным в системеприемнике - типа «to be». Соответственно, ограничения системы-источника, а 42 также ограничения, связанные с качеством исторических данных, не принимаются во внимание при разработке пакета требований к миграции данных. Именно таким образом была разработана функциональная спецификация на утилиту миграции данных в анализируемом проекте. В рассмотренных выше государственных стандартах, регулирующих процесс создания информационных систем, а также документирование требований к информационным системам не найдено специализированных разделов, посвященных организации миграции данных. Соответственно, потеря части требований бизнеса может привести к срабатыванию рисков, описанных в главе 1, в частности, риска составления технической (функциональной) спецификации. Таким образом, требования к утилите миграции и загрузке данных были задокументированы на основе модели данных «to be». В ФС были отражены следующие типы требований к загрузчику данных: Состав логических проверок целостности данных, а именно: 1) Из загруженных данных должны быть исключены экземпляры сущностей с отсутствующими значениями обязательных атрибутов согласно модели данных внедряемой системы; 2) Из загруженных данных должны быть исключены экземпляры документов с отсутствующими приложениями, которые являются обязательными согласно модели данных внедряемой системы; 3) Из загруженных данных должны быть удалены экземпляры сущностей с нарушенными связями и отсутствующими ссылками, которые являются обязательными согласно модели данных внедряемой системы; 4) Из загруженных данных должны быть исключены записи-дубли справочников и словарей систем-источников. Образование таких дублей в системах-источниках было связано с отсутствием автоматических проверок на дублирование, а также с тем, что справочники и словари велись пользователями вручную параллельно в двух системах. Таким образом, при переносе данных 43 возникала проблема сохранения ссылочной целостности данных после удаления дублей. 5) При загрузке данных экземплярам документов должны быть присвоены номера и имена в соответствии с масками и правилами, валидными во внедряемой системе. 6) В ФС на утилиту миграции отсутствовал полный маппинг атрибутов всех сущностей объектной модели. Атрибутный состав сущностей в проектируемой системе и системах-источниках отличается, часть атрибутов при маппинге была удалена, что привело к потере полноты мигрируемых данных. Таким образом, из данных, предназначенных для загрузки, была исключена часть контента заказчика, не удовлетворяющая требования к данным во внедряемой системе. Такой подход к работе с данными систем-источников привел к потере части информации, необходимой заказчику для работы. Данные были загружены не полностью, что привело к повторному проведению миграции данных после доработки требований к утилите миграции и доработки самой утилиты. Логические проверки, описанные в первоначальной версии ФС, были изменены таким образом, чтобы можно было загрузить максимальное количество данных из систем-источников, не отбраковывая невалидные объекте на входе в систему-приемник. Повторное техническое проектирование утилиты и доработка ПО привели к переносу сроков выполнения работ, увеличению трудозатрат и срыву приемки результатов работ. 2.5. Выявленные проблемы при тестировании загруженных данных в систему-приемник Этап тестирования в рамках миграции данных должен быть разделен на несколько отдельных шагов. Во-первых, тестируется программное обеспечение, предназначенное для проведения загрузки данных в систему-приемник. Вовторых, тестируется качество данных, загруженных в систему приемник и 44 работоспособность системы-приемника после миграции данных. В-третьих, тестируется работоспособность системы-приемника после загрузки мигрируемых данных для снижения риска размещения данных в проектируемой системе, описанного выше в Главе 1. В данном разделе будет проанализирован проектный опыт трех проектов миграции данных, в каждом из которых проводилось тестирование и оценка результатов миграции данных. Цели этапа тестирования миграции данных в рамках анализируемого проекта были сформулированы следующим образом: 1. Определить полноту загруженных данных в систему-приемник; 2. Выявить ошибки и дефекты в работе утилиты миграции; 3. Оценить качество загруженных в систему данных по следующим характеристикам: целостность взаимосвязей между объектами, отсутствие дублирующей информации; 4. Выявить ошибки и дефекты в работе внедряемой системы после размещения данных. В качестве методологической базы для организации работ по тестированию на этапе миграции данных в проекте внедрения информационных систем были использованы положения таких стандартов, как ANSI/IEEE Std 829-1998 - Standard for Software Test Documentation [1] и ANSI/IEEE Std 10081987 - IEEE Standard for Software Unit Testing [2]. Первая фаза работ - составление плана тестирования, в течение этой фазы работ составляется ресурсный план для выполнения работ, выбирается общий подход к тестированию, а также вносятся корректировки в проектный план (при необходимости). Входящей информацией для первой фазы работ по тестированию являются документы, описывающие требования к тестируемому ПО, а также проектный план. В первой фазе работ по тестированию выполняются следующие задачи: 45 Определение рамок тестирования: функции и модули системы для тестирования; Определение источников тестовых данных для проведения проверок; Сопоставление выбранных функций системы с планируемыми юниттестами; Определение набора конечных условий, которые будут свидетельствовать об успешном завершении тестирования; Составление плана ресурсов и календарного плана проведения тестирования. Вторая фаза работ по тестированию включает в себя составление тестпланов и согласование тестовых сценарием при необходимости. Проектная команда решает следующие задачи в течение второй фазы работ по проведению юнит-тестирования: Разработка тестовой документации: тестовые сценарии с подробным описанием процедуры тестирования и ожидаемым поведением системы; Согласование пакета тестовой документации. Третья фаза работ подразумевает выполнение тестов согласно разработанным и согласованным ранее тестовым сценариям, а также оценку результатов тестирования и составления плана доработок ПО (при необходимости). Третья фаза работ покрывает выполнение таких проектных задач: Выполнение тестовых сценариев; Доработка тестовых сценариев при обнаружении дефектов, в случае если дефект был порожден некорректным тестовым сценарием; Доработка ПО при обнаружении дефектов, в случае если дефект был порожден некорректно разработанным ПО; 46 Создание новых тестовых сценариев – при необходимости; Составление отчета о тестировании. В ходе проведения работ по тестированию в рамках анализируемого проектного опыта был составлен документ «Программа и методика испытаний» в соответствии с ГОСТ-19.101-77 [11], в котором были частично описаны тестовые сценарии этапа миграции данных. В данном документе были зафиксированы процедуры тестирования утилиты миграции, направленные на выявление технических сбоев и ошибок работы, однако в документе не были зафиксированы процедуры тестирования бизнес-логики утилиты, качества загруженных данных и пост-миграционные процедуры тестирования системыприемника. Таким образом, документирования этапа миграции данных было проведено не полностью и не могло обеспечить выполнение эффективного и полного тестирования. На третьей фазе работ по тестированию может составляться Журнал (лог) тестирования как отдельный проектный артефакт. В анализируемом проектном опыте создание такого проектного артефакта не планировалось. Это привело к неэффективному тестированию миграции данных в первых двух проектах миграции данных. Лог миграции данных был составлен только в третьем проекте по миграции данных для того, чтобы обеспечить полноту проверок бизнес-тестирования утилиты миграции. Тестирование утилиты миграции направлено на выявление дефектов, которые могут повлиять на процесс миграции и привести к ошибкам в ходе переноса данных в систему-приемник. Проведение тестирования утилиты миграции может быть организовано в соответствии с методологиями, описанными в стандартах ANSI и проанализированными выше. В первом рассматриваемом проекте этап бизнес-тестирования утилиты миграции отсутствовал вообще. Во втором проекте проводились юнит-тесты, которые, как отмечено выше, не смогли обеспечить полноту проверок загруженных данных. Неполнота мигрированных данных была обнаружена в 47 ходе опытной эксплуатации и привела к повторной миграции данных, для которой была доработана функция логирования процесса миграции. Проверка качества мигрированных данных является еще одним этапом тестирования миграции данных. Основная проблема работ этого этапа – неполнота тестовых сценариев, разработанных без участия бизнес- пользователей, которые являются носителями знаний о качестве и полноте данных с точки зрения функционирования бизнеса. Тестовые сценарии в случае тестирования качества загруженных данных должны покрывать тестирование полноты и целостности загруженных данных. Составленные без участия бизнеспользователей сценарии тестирования для создания тестовой выборки могут покрывать требования к мигрируемым данным только частично. В таком случае проблемы загруженных данных станут очевидны только после старта опытной эксплуатации системы, что приведет к доработкам миграции и повторным загрузкам данных. При тестировании качества загруженных данных в систему-приемник не могут использоваться тесты на малых объемах данных. Результаты такого тестирования не могут являться гарантией выполнения всех требований бизнеса к миграции данных. В рамках этапа тестирования не представляется возможным проверить весь массив размещенных в системе-приемнике данных, однако тестовые планы и сценарии должны согласовываться с бизнес-пользователями для того, чтобы обеспечить полноту проверки качества размещенных данных. В рамках рассматриваемого проектного опыта фаза тестирования качества размещенных данных отсутствовала в первом проекте миграции, то есть бизнеспользователи не вовлекались в процесс оценки качества миграции. После старта опытной эксплуатации бизнес-пользователи в ходе работы с внедряемой системой бизнес-пользователи обнаружили неполноту и отсутствие целостности мигрированных данных, что привело к срыву этапа опытной эксплуатации и проведению повторной миграции. 48 Тестирование работоспособности системы-приемника относится к уровню системного тестирования. Ошибки работы функциональности системы- приемника были связаны с расхождениями в моделях данных старой и новой системы. В частности, обязательные атрибуты сущностей в системе-приемнике могли быть необязательными для заполнения в старой системе. В таком случае работа некоторых функций может быть блокирована из-за отсутствия значений некоторых обязательных атрибутов. Например, движение электронных документов по их жизненному циклу часто зависит от заполнения различных наборов атрибутов. Соответственно, сущности, мигрированные из системыисточника, не будут продвинуты по их жизненному циклу. Отсутствие значений обязательных атрибутов может привести к сбоям работы экранных форм карточек документов и автоматизированных бизнес-процессов работы с документами в системе. В случае если на этапе системного тестирования после миграции не проводится тестирование работы функциональности системыприемника с использованием мигрированных данных, отсутствует гарантия безошибочной работы системы-приемника, что приводит к срыву мероприятий по приемке внедряемой системы. Помимо описанных выше особенностей работы с мигрированными сущностями и их обязательными атрибутами, имеет значение тип мигрируемых данных. Несоответствие типов мигрируемых данных требованиям системыприемника также приводит к возможным ошибкам работы функциональности системы. Например, могут возникать ошибки при несовпадении форматов хранения дат или численных значений в системе-источнике и системеприемнике. Более явные несовпадения форматов хранения данных могут быть выявлены на этапе технического проектирования утилиты миграции. Для того чтобы избежать ошибок в обработке данных должны быть разработаны механизмы преобразования данных при переносе мигрируемых данных из системы-источника в систему-приемник. Например, должны быть разработаны механизмы преобразования строковых значений - в числовые или строковых 49 значений - в формат дат. Необходимость менее явных преобразований может быть упущена на этапе технического проектирования и разработки требований к утилите миграции, однако должна быть выявлена при проведении тестирования работоспособности функциональности системы-приемника после миграции. Таким образом, отсутствие тестирования функциональности проектируемой системы с использованием мигрированных данных может привести к тому, что результаты разработки ПО не будут соответствовать заваленному в проекте уровню качества. В рассматриваемом проекте внедрения информационной системы тестирование функциональности внедряемой системы не дало ожидаемых результатов в силу неверного планирования работ по тестированию. На проверку функциональности системы-приемника после загрузки данных не было выделено достаточно ресурсов и времени, соответственно, разработанный тест-план не охватывал все потенциальные «узкие» места в автоматизированных бизнес-процессах, а проведенные мероприятия по тестированию в соответствии с этим тест-планом оказались недостаточно эффективными. 50 3. Методика организации проведения миграции данных 3.1. Последовательность шагов для организации миграции данных 3.1.1. Разработка общих требований к миграции данных В рамках разработки общих требований к миграции данных бизнесаналитиком должна быть определена стратегия миграции данных. Исходя из потребностей бизнеса, режима функционирования организации-заказчика, должна быть выбрана миграция «большого взрыва» или плавная миграция. При выборе стратегии «большого взрыва» должно быть определено время, которое может быть затрачено бизнесом на простой во время миграции данных. После определения времени, которое бизнес может потратить на простой во время миграции данных может быть составлен график миграции данных. При составлении графика миграции данных должен быть выделен резервный день или дни, необходимые для повторной миграции в случае серьезных ошибок. При выборе стратегии плавной миграции все бизнес-пользователи целевой системы должны быть разделены на группы, для которых должен быть составлен график переключения на работу с целевой системой. После деления бизнес-пользователей на группы должны быть определены соответствующие им наборы данных и сущностей. При распределении бизнес-пользователей по группам должны учитываться взаимосвязи этих групп в рамках бизнес-процесса, автоматизируемого в целевой системе. Параллельно с выбором стратегии проведения миграции данных менеджментом проекта и/ или бизнес-аналитиком должна быть произведена выявление типовых рисков миграции данных. Для каждого выявленного риска должна быть выбрана стратегия (методы) работы с риском и разработан комплекс мероприятий по предотвращению риска. Стратегией предотвращения риска может быть одна из следующих [13]: отказ от чрезмерно рисковой деятельности (метод отказа), профилактика или диверсификация (метод снижения), 51 аутсорсинг затратных рисковых функций (метод передачи), формирование резервов или запасов (метод принятия). В таблице 1, приведена матрица типовых рисков миграции данных и способы работы с каждым из таких рисков. В ячейках матрицы приведены примеры мероприятий по работе с каждым из рисков в рамках каждого метода предотвращения риска. При составлении таблицы предполагалось, что стратегия «Отказ» не является приемлемой для проектной команды, так как предпосылкой для исследования является необходимость выполнять работы по миграции. Таким образом, отсутствует возможность полного или частичного исключения таких работ из скоупа проекта. Таблица 1 Матрица рисков и возможных стратегий работы с рисками этапа миграции Стратегия работы с риском Отказ Снижение Передача Принятие Привлечение к работам по составлению технической спецификации консультантов Формирование резерва бюджета и времени на проекте для работы с потенциальными запросами на изменение Формирование резерва времени и бюджета на потенциальные дополнительные работы вследствие неполного тестирования миграционного ПО и размещенных данных Формирование резерва бюджета и времени для повторных получений выгрузок и итеративной загрузки Риск Риски составления технической спецификации - Проработка требований к миграции совместно с бизнесом, владельцами и потребителями мигрируемых данных Риски тестирования - Риски процесса получения и загрузки данных - Проработка тестовых Передача пакета планов и сценарием с работ по привлечением бизнес- тестированию пользователей отдельной команде с заранее определенными условиями приемки их резудьтатов Проработка требований к тестовой выгрузке. Проведение «тестовой» миграции с использованием тестовой выгрузки 52 Продолжение таблицы 1 Стратегия работы с риском Отказ Снижение Передача Принятие Параллельная проработка модели данных “as is” и “ to be” для нивелирования различий в форматах и способах работы с данными в источнике и приемнике - Формирование резерва времени и бюджета для доработок функциональности системы-приемника Риск Риски, связанные с работой проектной команды Риски размещения данных в целевой системе - - 3.1.2. Организация планирования работ по миграции данных Входной информацией для составления планов работ по миграции является стратегия миграции данных, сформулированная в рамках разработки общих требований к миграции данных. Результатом планирования работ по миграции данных должен набор проектных артефактов, в которых зафиксирована последовательность шагов по реализации миграции данных. Выходами этапа планирования являются следующие проектные артефакты: план работ по миграции и план коммуникаций на этапе миграции данных. План работ по миграции определяет набор задач и ответственных за их выполнение, распределенных с помощью матрицы RACI. Проектный план работ по миграции должен содержать пакеты задач и работ для каждого из этапов миграции: от подготовительного до пост-миграционного этапа работ. С учетом результатов анализа проектного опыта была разработана ИСР, позволяющая 53 избежать рисков и соответствующая «эталонным» теоретическим подходам к организации миграции данных. Приведенная на Рис. 3 структура работ покрывает все этапы миграции и может быть трассирована к строкам проектного плана работ. В рамках проектного плана работ должны быть определены сроки выполнения каждой задачи и обозначены выходы каждой задачи. При составлении плана работ для каждой задачи должно быть определено условие, выполнение которого будет однозначно определять, что 54 задача завершена. Миграция данных Обследование организации-заказчика Разработка требований к миграции данных Интервью с ключевыми пользователями систем-источников Описание модели данных to be Интервью с ИТспециалистами Разработка требований к профилю данных для загрузки Описание модели данных as is Разработка требований к тестовой выгрузке Разработка и настройка утилиты миграции Проведение миграции данных Разработка ПО Первичное тестирование утилиты Тестовая миграция данных с использованием тестовой выгрузки Приемка результатов миграции и опытная эксплуатация Получение выгрузки из систем-источников Бизнес-тестирование утилиты ОЭ и анализ ошибок Оценка качества полученных данных с привлечением бизнеспользователей Бизнес-тестирование загруженных данных Подговка сценариев для демонстрации Загрузка данных в систему-приемник Тестирование системыприемника после загрузки Проведение демонстрации системы-приемника с загруженными данными Разработка функциональной спецификации на утилиту миграции Рис. 3 - Иерархическая структура работ проекта миграции данных 55 Тестирование Не менее важным проектным артефактом этапа миграции данных является план коммуникаций. План коммуникаций на этапе миграции определяет цели и виды взаимодействия между участниками проектной команды, а также между участниками проектной команды и сотрудниками заказчика – бизнес-пользователями. Оформление плана коммуникаций в рамках этапа миграции должно основываться на составленном ранее плане работ. Для каждой задачи в рамках проектного плана должны быть определены следующие атрибуты: 1. Предмет (тема) коммуникации. 2. Необходимость взаимодействия ролевых групп внутри команды; Кто должен участвовать в коммуникации? Какие ролевые группы? 3. Какой тип взаимодействия приемлем? 4. Что должно являться выходом коммуникации? 5. Необходимость взаимодействия с проектной команды и бизнеспользователей; 6. Кто должен участвовать в коммуникации со стороны проектной команды и со стороны бизнеса? 7. Какой тип взаимодействия с бизнес-пользователями приемлем? 8. Что должно являться выходом коммуникации с бизнес- пользователями? 9. Кто должен быть осведомлен о результатах коммуникации? Шаблон плана коммуникаций на этапе миграции данных приведен в таблице 2 ниже (Таблица 2). 56 Таблица 2 Шаблон плана коммуникации на этапе миграции данных указывается основной вопрос или задача, для Тема коммуникации решения которой необходима данная коммуникация, раздел требований к миграции, объекты данных Участники со стороны проектной команды указываются ролевые группы и роли Необходимость взаимодействия с бизнесом проставляется признак: да или нет Участники со стороны бизнеса указывается функциональное подразделение и ответственный сотрудник указывается Тип взаимодействия тип взаимодействия, например: письменное, встреча, воркшоп Ссылка на задачу в проектном плане работ ссылка проставляется для определения сроков проведения коммуникации 3.1.3. Разработка и документирование бизнес-требований к миграции данных Разработка и документирование требований к миграции данных должно осуществляться в несколько этапов. В рамках разрабатываемой методики в этап разработки бизнес-требований к миграции данных будет также включен обследования шаг проведения организации-заказчика. и документирования Цель этапа результатов разработки бизнес- требований к миграции данных – разработка полного пакета требований к специализированному ПО для миграции данных, а также к составу данных, мигрируемых в целевую систему. 1. Обследование эксплуатируемой информационной системы Обследование эксплуатируемой информационной системы хронологически должно быть первым этапом работ в рамках разработки требований к миграции данных. Обследование существующей информационной системы в рамках разработки требований к миграции данных может проводиться в рамках работ по обследованию бизнеса всего проекта внедрения ИС. Обследование в рамках разработки требований к миграции данных должно быть направлено на создание модели данных ‘as is’. Модель данных ‘as is’ позволит 57 подготовить требования к составу мигрируемых данных из системыисточника в систему-приемник. Модель данных ‘as is’ описывает все объекты данных, которые используются в эксплуатируемой системе. После составления такой модели заказчику будет проще выбрать перечень объектов данных для переноса в систему-приемник. В такой модели должны быть указаны имена сущностей, а также описан их атрибутный состав и взаимосвязи между сущностями с указанием их кардинальности. Помимо модели данных эксплуатируемой системы на этапе обследования должны быть составлены схемы бизнес-процессов, в которых используются объекты данных, выбранные для переноса в целевую систему. Модели бизнес-процессов позволят выявить недостающие объекты данных, в случае если они были упущены при анализе модели данных. Помимо составления модели данных ‘as is’ на этапе обследования должны быть описаны правила работы со словарями и справочниками в эксплуатируемой системе. В частности, должны быть описаны следующие моменты для каждого словаря: Наименование словаря или справочника; Ответственное за администрирование словаря функциональное подразделение; Наличие проверки уникальности для кодов и значений записей словарей; Наличие правил регулярного обновления записей в словарях; Описание правил работы с записями словарей, потерявшими актуальность; В случае если миграция данных производится из нескольких источников, необходимо описать, есть ли дублирование словарей в нескольких системах-источниках. В случае наличия дублей словарей в нескольких системах-источниках, требуется описание правил дедубликации и маппинга записей для каждого словаря; 58 Формат спецификации требований к миграции словарей из системыисточника в целевую систему приведен в таблице и пример заполнения такой спецификации приведен в таблице 3. Таблица 3 Формат спецификации для миграции словарей / справочников и пример заполнения Наименован ие справочника в системеприемнике Виды отходов строительств а и сноса Организации и юр. лица Ответственн ое подразделен ие УПТ УПТ, перемещение грунтов и отходов Системаисточник Наименование справочника в системеисточнике Проверка уникальнос ти записей в источнике Lotus Каталог отходов Проверки отсутствуют Регулярное обновление записей Регламент обновления справочника отсутствует Проверки отсутствуют Обновление реестров происходит раз в неделю Lotus, «Грунт» Юридические лица Правила работы с неактуальн ыми записями Проставляе тся флаг «архивный» Проставляе тся флаг «архивный» Необходимост ь дедубликации при миграции Дедубликация не требуется. Требуется дедубликация при совпадении полного наименования в разных системахисточниках 2. Разработка требований к профилю данных для миграции Разработка требований к профилю данных для миграции должна происходить с участием групп ключевых бизнес-пользователей в соответствии с планом коммуникаций, разработанным в ходе планирования работ по миграции данных. Шаблон документа и пример заполнения для фиксирования результатов обследования приведен в таблице 4 (Таблица 4). Бизнес-пользователи являются источниками для получения ответов на следующие вопросы о профиле данных для миграции данных: 1) Будут ли мигрированные данные являться входными для работы бизнес-процесса, автоматизированного в проектируемой системе? Ответом на данный вопрос должна стать таблица-описание соответствия объектов данных системы-источника и бизнес-процессов, автоматизированных в целевой системе. 2) Какой временной промежуток должен быть определен для миграции данных? При этом должны быть учтены положения нормативных и организационно-распорядительных документов. Ответом на данный вопрос 59 должна стать таблица соответствия объекта данных и временного горизонта выгрузки данных из системы-источника. 3) Какому объекту данных целевой системы соответствует каждый из выбранных для миграции объектов данных системы-источника? Ответом на данный вопрос должна стать таблица маппинга объектов данных системыисточника и системы-приемника. 4) Есть ли в атрибутном составе объектов данных системы- источника поля или группа атрибутов, которые не будут использоваться в целевой системе? Ответом на данный вопрос должна стать таблица описания атрибутного состава объектов данных с проставленным флагом: используется/ не используется в целевой системе. 5) Есть ли в атрибутном составе объектов данных системы- источника поля или группы атрибутов, которые не соответствуют по типу данных полям в целевой системе? Ответом на данный вопрос должна стать таблица описания атрибутного состава объектов данных с проставленным флагом и расшифровкой несоответствий. 6) Происходила ли модернизация системы-источника, результатом которой стало значительное изменение в структуре данных, которые необходимо мигрировать? Примеры изменений: - Изменение состава обязательных атрибутов; - Изменение правил хранения объектов данных; - Значительное изменение структуры объекта данных, приводящее к изменению объемов данных. Ответом на данный вопрос должно стать описание объектов данных системы-источника с описанием особенностей работы с объектом данных в течение временного промежутка, для которого производится миграция данных. 7) Какое функциональное подразделение или конкретные пользователи являются владельцами данных? Ответом на этот вопрос должна стать таблица соответствия объектов данных и сотрудников заказчика. 60 Таблица 4 Результаты обследования организации-заказчика на этапе миграции данных. Пример заполнения атрибуты и правила конвертации объект данных владелец данных Технологический регламент Подразделение УПТ Разрешение на перемещение строительных отходов Отдел оформления разрешений на перемещение строительных отходов бизнес-процесс Регистрация технологических регламентов временной горизонт объект данных в системе-приемнике исключаемые атрибуты 10 лет 1. Технологический регламент 2. Объект перемещения строительных отходов Ссылка на объекты строительства Категория технологического регламента атрибут Номер ТР Набор кодов видов отходов правило Проверка уникальности; Формирование номеров согласно маске Ссылка на справочник «Виды отходов» Серия разрешения Оформление разрешений 5 лет Разрешение 61 Округ объекта строительства Дата выдачи разрешения Согласующий эксперт Тип объекта строительства Преобразование к формату дат Заполнение константой при отсутствии значения в системеисточнике Сотрудники ИТ-подразделения являются источниками для получения ответов на следующие вопросы о профиле данных для миграции: 1) Где физически хранятся данные, выбранные бизнес-пользователями для миграции в целевую систему? Что является источником данных: корпоративное приложение, система или источники за пределами организациизаказчика? Ответом на данный вопрос должна стать таблица соответствия объектов данных и их хранилищ (имя и тип БД, имя таблицы/таблиц в БД). 2) Позволяет ли метаинформация мигрируемого контента разработать алгоритмы миграции? Возможно ли произвести анализ структуры данных на основе метаинформации? 3) Есть ли технологические ограничения системы-источника, которые отражаются на структуре данных, формах хранения и работы с данными? Ответом на данный вопрос должно стать полное описание технологических ограничений системы-источника в разрезе объектов данных для миграции. Сотрудники ИТ-подразделения и бизнес-пользователи совместно должны произвести оценку критичности потенциальных ошибок при переносе данных из системы-источника в целевую систему. В частности, бизнес-пользователи и сотрудники ИТ-подразделений должны проанализировать взаимосвязи объектов данных на уровне используемой БД для определения перечня возможных проверок целостности данных при переносе в целевую систему. Разработка требований к профилю данных для миграции должна завершаться получением тестовой выгрузки данных из системы-источника (систем-источников) в соответствии с разработанным профилем данных. Полученная тестовая выгрузка будет использоваться миграционного ПО и оценки качества предоставляемых данных. 62 для отладки 3. Разработка требований к утилите миграции 1) Требования к очистке и логическим проверкам данных После разработки требований к профилю данных для миграции необходимо разработать правила очистки или преобразования выгруженных из систем-источников данных для их корректного размещения в целевой системе. Для этой цели необходимо соотнести бизнес-требования к модели данных проектируемой системы и описание модели данных эксплуатируемой системы. Для целей определения уровня качества данных должны применяться следующие типы логических проверок в рамках каждого мигрируемого объекта данных: - Заполнены ли все обязательные атрибуты? - Физический тип данных каждого атрибута в системе-источнике и системе-приемнике совпадают? - Длины значений атрибутов в объекте данных удовлетворяют требованиям в целевой системе? - Формат хранения данных (даты, десятичные числа) соответствуют требованиям в целевой системе? - Идентификаторы объектов данных в системе-источнике позволяют их однозначно различить? Требования к логическим проверкам должны быть зафиксированы в функциональной спецификации на утилиту миграции данных. Выявленные несоответствия в данных для загрузки могут быть устранены одним из следующих способов: данные могут быть удалены из состава выгрузки, если они не имеют бизнес-ценности или преобразованы с помощью специфических алгоритмов. Для корректного размещения данных в целевой системе для объектов данных могут быть разработаны алгоритмы преобразований следующих видов: - Недостающие обязательные атрибуты могут быть заполнены заранее определенными значениями - «заглушками». 63 - Значения атрибутов, длина которых не соответствует требованиям целевой системы, должны быть сокращены. - Формат дат системы-источника должен быть приведен к формату хранения дат системы-приемника. - Формат хранения десятичных числовых данных должен быть приведен к формату хранения десятичных числовых данных в целевой системе. - Атрибуты, физически тип данных которых не соответствует требованиям целевой системы, должны быть преобразованы. Например, текстовые значения могут быть приведены к целочисленным. Требования к алгоритмам очистки и преобразования данных, а также виды объектов данных, для которых они будут применены, должны быть зафиксированы в функциональной спецификации на утилиту миграции данных. 2) Требования к именованию сущностей в системе-приемнике Требования к разработке алгоритмов именования сущностей в системеприемнике должны разрабатываться в случае, если в целевой системе невозможно применить алгоритмы, используемые для именования сущностей в системе-источнике/ системах-источниках. Алгоритмы именования и нумерации объектов данных должны быть разработаны в следующих случаях: Если из двух систем-источников производится миграция объектов данных с одинаковым бизнес-смыслом, то в целевой системе для формирования их имен и номеров должен применяться общий алгоритм. Если в системе-источнике для формирования номеров сущностей применялись алгоритмы, которые более не являются актуальными в силу изменившихся нормативных или организационно-распорядительных документов. Если в системе-источнике для формирования номеров сущностей применялись алгоритмы, которые не удовлетворяют бизнес-правилам работы с сущностями в проектируемой системе. 64 Требования к алгоритмам формирования имен и номеров мигрированных сущностей должны быть зафиксированы в функциональной спецификации на утилиту миграции данных. 3) Требования к логированию миграции данных Для отслеживания состояния процесса миграции данных утилита миграции должна поддерживать логирование загрузки данных в целевую систему. При этом в логе утилиты миграции должна отражаться информация обо всех произведенных логических проверках и удалении данных из набора данных для загрузки в целевую систему. Требования к логу утилиты миграции должны быть зафиксированы в функциональной спецификации на утилиту миграции. Лог утилиты миграции должен позволять отследить каждую операцию в рамках процесса загрузки данных в целевую систему. Каждая запись лога миграции данных должна обладать как минимум следующим набором атрибутов: Вид мигрируемого объекта данных; Система-источник; Уникальный идентификатор объекта данных в системе-источнике; Уникальный идентификатор объекта данных в системе-приемнике; Дата и время проведения загрузки для данного объекта данных; Сформированное утилитой миграции имя/номер для данного объекта данных, в случае если для данного объекта данных был применен алгоритм формирования имен/ номеров сущностей; Флаг: был ли объект данных мигрирован в систему-приемник или был исключен из загруженных данных; Причина, по которой объект был исключен из загруженных данных – состав логических проверок и правил; Описание ошибки, возникшей в ходе миграции объекта данных, если такая произошла. 65 В атрибуте «Описание ошибки» отражается параметризованное сообщение утилиты миграции данных, в случае если утилита миграции не смогла выполнить загрузку объекта данных в целевую систему. В случае если для объекта данных выставлен флаг – объект удален из мигрируемых данных, то в атрибуте «Причина исключения удаления объекта данных» должно отражаться параметризованное сообщение, описывающее алгоритм очистки данных, в соответствии с которым из мигрируемых данных был удален данный объект. Фрагмент лога утилиты миграции приведен в приложении 4 (Приложение 4 - Фрагмент лога утилиты миграции). 3.1.4. Проведение тестирования в рамках работ по миграции данных Работы по тестированию состоит из следующих пакетов работ: 1. Первичное тестирование миграционного ПО на соответствие технической спецификации; 2. Бизнес-тестирование миграционного ПО на соответствие требованиям бизнеса к алгоритмам трансформации данных во время миграции; 3. Тестовая очистка и загрузка данных в систему-приемник; 4. Тестирование работы функциональности системы-приемника после размещения мигрируемых данных; Ниже приведена последовательность шагов, которые должны быть предприняты проектной командой для проведения каждого из этапов тестирования. Первичное тестирование миграционного ПО должно выявить и устранить технические сбои и дефекты разработанной утилиты миграции. Такое тестирование должно проводиться силами команды тестировщиков в соответствии с разработанными тест-кейсами. При этом после доработок ПО в случае выявленных ошибок обязательным является проведение регрессионного тестирования утилиты. 66 Бизнес-тестирование миграционного ПО на соответствие требования бизнеса и алгоритмам трансформации данных должно выполняться с использованием лога утилиты миграции для обеспечения полноты проверок и тестов. Порядок действий при бизнес-тестировании может быть следующим: 1. Определить по логу утилиты миграции игнорированные при загрузке объекты данных. 2. Убедиться, что эти объекты в системе-источнике удовлетворяли условиям применения логических проверок или механизмов трансформации. 3. В случае выявления несоответствия зафиксировать ошибку работы утилиты миграции. Ошибки, зафиксированные в ходе тестирования, должны фиксироваться в таком виде, чтобы можно было однозначно определить источник их появления – алгоритм или правило, сработавшее неверно. Для бизнес-тестирования утилиты миграции могут применяться автоматизированные средства тестирования. В случае их отсутствия набор юнит-тестов должен охватывать все возможные типы объектов данных, которые были мигрированы в целевую систему, а также все спроектированные для каждого типа проверки и механизмы трансформации. Тестовая очистка и загрузка данных предполагает работы с данными, полученными после разработки пакета требований к профилю мигриуемых данных. Тестовая выгрузка должна быть инструментом для проверки следующих характеристик миграционного ПО: - Работа бизнес-алгоритмов, логических проверок и механизмов преобразования на реальных данных; - Работоспособность миграционного ПО на приближенных к продуктивным объемах данных. Работа с тестовой выгрузкой – завершающий этап тестирования миграционного ПО. После обработки утилитой миграции тестовой выгрузки становится возможной оценка необходимого планового времени для загрузки 67 всего массива мигрируемых данных. Успешное размещение тестовой выгрузки в системе-приемнике должно означать внутреннюю приемку утилиты миграции и возможность перехода к работам по загрузке промышленной - полной выгрузки из системы-источника в целевую систему. Тестовая очистка и загрузка данных в систему-приемник предполагает выполнение всех необходимых для миграции данных в целевую систему операций, включая тестирование функциональности системы-приемника. Подробнее этот этап тестирования описан ниже. Тестирование работы функциональности системы-приемника должно обеспечить возможность убедиться в том, что все функции системы, использующие мигрированный контент работают в штатном режиме. При этом такое тестирование может осуществляться в два этапа: 1. Тестирование работоспособности системы-приемника; 2. Детальное тестирование функциональности системы-приемника. Для проведения тестирования работоспособности системы-приемника сразу после завершения загрузки должен быть составлен краткий сценарий тестирования, в котором указывается, что именно необходимо проверить на работоспособность, например: - перечень экранных форм, которые необходимо открыть, - количество объектов в справочниках (словарях), которое должно быть видно пользователю; - количество объектов в реестрах системы, которое должно быть видно пользователю, - перечень функций системы, которые должны быть запущены (построение отчетов, поисковые механизмы, доступ к мигрированным объектам данных). Детальное тестирование функциональности системы-приемника предполагает запуск всех автоматизируемых бизнес-процессов, для которых входными данными являются мигрированные данные. В случае если в состав загруженных данных входит более одного типа объектов данных, то тестовые 68 сценарии должны быть предусмотрены для каждого мигрированного типа данных. Результаты тестирования функциональности системы-приемника должны фиксироваться в журнале тестирования. В соответствии со стандартом ANSI журнал (лог) тестирования миграции данных должен иметь следующую структуру: 1. Идентификатор тест-кейса; 2. Описание операции в рамках тест-кейса; 3. Описание ошибки во время выполнения операции в рамках тесткейса; 4. Влияние ошибки на функциональность системы; 5. Влияние ошибки на связанные операции тестирования. Описание операции в рамках тест-кейса в обязательном порядке должно включать: a) Входящие данные для операции; b) Ожидаемые результаты; c) Полученные результаты; d) Дата и время выполнения операции; e) Количество попыток выполнения операции; f) Ответственные за тестирование члены проектной команды; g) Окружение операции в рамках тест-кейса. Фрагмент журнала тестирования функциональности системы-приемника приведен в приложении 5 (Приложение 5 - Журнал тестирования результатов миграции). 3.2. Оценка применения разработанной методики организации и проведения миграции данных Описанная в разделе 3.1 методика проведения миграции данных была опробована в рамках последнего проекта по миграции данных по внедрению ведомственной информационной системы. 69 По итогам каждой итерации миграции данных менеджментом проекта и проектной командой проводился анализ результатов и разбор типовых ошибок. Результаты такого анализа после каждой итерации или проекта миграции сопоставлялись с результатами предыдущей итерации/проекта, что позволило в итоге разработать наиболее полный комплекс мероприятий и успешно завершить миграцию данных в целевую систему. Таким образом, можно проследить, повлияло ли использование методики проведения миграции данных на результат проектных работ и если повлиял, то в какой мере. На этапе оценки и завершения процесса миграции критическими факторами успеха можно назвать соответствие ожиданий заказчика и членов проектной команды уровню, определенному на этапе планирования миграции, а также штатное функционирование целевой системы с полным составом мигрированных данных. Выполнение этих двух условий в совокупности дает основание для закрытия этапа миграции данных. Однако помимо качественной оценки результатов этапа миграции проектной командой была проведена также количественная оценка результатов процесса миграции. Разработанная методика миграции данных оценивалась с помощью набора метрик процесса миграции. В качестве метрик качества проведения миграции данных были использованы следующие количественные показатели: 1. Доля дополнительных доработок функциональности системы-приемника для успешного размещения мигрированных данных. Значение данного показателя измеряется как отношение количества трудозатрат на доработки функциональности системы-приемника, вызванные изменениями требований в процессе миграции, к трудозатратам на проектирование и разработку модифицированных модулей системы-приемника. 2. Доля дополнительных доработок миграционного ПО для завершения успешной загрузки данных Значение данного показателя измеряется как отношение количества трудозатрат на доработки функциональности миграционного ПО, вызванные 70 изменениями требований в процессе миграции, к трудозатратам на проектирование и разработку утилиты миграции в целом. 3. Доля «потерянных» данных при миграции от общего объема данных, предназначенных для переноса в целевую систему; Показатель определяется как отношение количества объектов данных, которые не были успешно размещены в системы-приемнике, и для их загрузки понадобились настолько серьезные доработки миграционного ПО, приведшие к повторной миграции. 4. Отклонение количества времени, потраченного на перенос данных в целевую систему от запланированного количества времени; Данный показатель измеряет качество планирования процесса миграции данных и управление проектными рисками. Значение показателя определяется как соотношение фактически затраченного времени на миграцию данных и плановых значений для тех же задач. Для каждого показателя было определено некоторое целевое значение, в сравнении с которым оценивался результат проектных работ. Часть целевых значений была согласована с заказчиком в рамках формирования требований к уровню качества миграции данных. Логика определения целевого значения для каждого показателя описана ниже в таблице 5. Таблица 5 Целевые показатели для оценки разработанной методики миграции данных Название показателя Дополнительные доработки Целевое Логика значение значения системы- 5% Целевое приемника определения целевого значение параметра определяется, исходя из буфера бюджета и трудозатрат проекта, пропорционально времени, плановому отведенному на миграцию данных Доля доработок миграционного ПО не более Целевое значение определяется, 15% исходя проектного буфера 71 параметра бюджета из и Название показателя Целевое Логика значение значения определения целевого трудозатрат на разработку ПО Доля «потерянных» данных в общем объеме 0 Все необходимые бизнесу данные данных должны быть мигрированы в систему-приемник, соответственно, целевое значение 0 Отклонение времени, затраченного на 10% Значение определено, исходя из миграцию, от плана того, что во всем портфеле проектов по внедрению данной ИС был заложен резерв на отклонение от плана в 10% Изменение значений ключевых показателей эффективности процесса миграции от проекта к проекту показано в приложении 6 к работе (Приложение 6 - Результаты апробации разработанной методики). Первый проект по миграции проводился без каких-либо методических доработок. В течение второго проекта использовались описанные в п. 3.1.3 инструменты документирования и разработки требований. В третьем проекте использовались инструменты тестирования, логирования процесса, описанные в п. 3.1.4. Соответственно, изменения значений целевых показателей демонстрируют влияние групп разработанных подходов к проведению миграции на результаты проекта. Результаты оценки миграции данных по итогам каждого проекта позволяют сделать вывод о том, что предложенный комплекс мероприятий по организации и проведению миграции данных позволяет успешно проводить работы по миграции данных в проектах внедрения ИС. Результатом третьего проекта по миграции данных стал успешный запуск системы-приемника в промышленную эксплуатацию с полностью загруженными в полном объеме. 72 мигрированными данными, Таким образом, была проведена оценка и апробация разработанной методики проведения миграции данных в рамках проекта по внедрению информационной системы. 73 Заключение Результатом работы стала разработанная методика организации миграции данных, которая была опробована и протестирована в проекте миграции данных. Разработанная методика позволяет последовательно решить проектные задачи, возникающие на этапе миграции. Жизненный цикл миграции данных был составлен и описан на основе анализа методологической базы, проведенного в теоретической части работы. Для каждого этапа жизненного цикла процесса миграции данных были сформулированы основные риски этапа миграции. В соответствии с выделенными этапами процесса миграции данных был проведен анализ проектного опыта. В рамках анализа проектного опыта последовательно рассмотрены и выявлены проблемы каждого из этапов миграции данных. Выявленные проблемы миграции данных и сработавшие риски этапа миграции являются входящей информацией для разработки методики организации и проведения миграции данных. Предложенная в работке методика содержит рекомендации или указания по решению каждой выявленной и описанной проектной проблемы. При разработке конкретных подходов в рамках методики, шаблонов и примеров документов использовалась методологическая база настоящего исследования. Шаблоны документации, планы обследования, способы документирования требований к миграции разрабатывались на основе стандартов (ГОСТ, ANSI) и методологий (MSF, подход К. Вигерса и т.д.). Предложенная в работе методика организации и проведения миграции данных была опробована в ходе одного из проектов по миграции. Данный проект являлся заключительным в серии проектов внедрения ведомственной информационной системы в органе исполнительной власти. Результаты апробации методики могут быть оценены по динамике выбранных метрик. Таким образом, результаты работы являются практически значимыми. 74 Список использованных источников 1. 829-1998 - IEEE Standard for Software Test Documentation https://standards.ieee.org/findstds/standard/829-1998.html 27.05.2015 2. 1008-1987 - IEEE Standard for Software Unit Testing https://standards.ieee.org/findstds/standard/1008-1987.html 27.05.2015 3. An Oracle White Paper, Successful Data Migration, Oracle Corporation, 2011 4. Best practices for data migration. Methodologies for planning, designing, migrating and validating data migration, IBM Corporation 2007 5. Introduction to the Data Migration Framework in Microsoft Dynamics, By Ruben Barron on April 23, 20 http://blog.bhsolutions.com/index.php/2013/04/introduction-to-the-datamigration-framework-in-microsoft-dynamics/13 06.06.2014 6. Michael S. V. Turner, Microsoft® Solutions Framework Essentials, 2006, 340 c. 7. PMI PM BOK Guide 4th Edition. Руководство к своду знаний по управлению проектами, 4е издание, на английском языке, 2008 год, PMI. 8. ГОСТ 34.601-90 Автоматизированные системы. Стадии создания 9. ГОСТ 34.602-89 Техническое задание на создание АС 10.ГОСТ 34.201-89 Виды, комплектность, обозначения документов при создании АС 11.ГОСТ 19.101-77 ВИДЫ ПРОГРАММ И ПРОГРАММНЫХ ДОКУМЕНТОВ 12.Карл И. Вигерс, «Разработка требований к программному обеспечению», М.: ИТД "Русская Редакция", 2014 - 576 с. 13. В.И. Грекул, Н.Л. Коровкина, Ю.В. Куприянов Методические основы управления ИТ-проектами, ИТУИТ.РУ, БИНОМ.ЛЗ, с. - 391, М.,2010 14.А.Колесов PC Week Review, 11 2008 «Неудачные проекты: в чем причина?» 75 http://www.pcweek.ru/idea/article/detail.php?ID=116042 27.05.2015 15.Андрей Арсентьев «Рынок ИТ-услуг 2014» http://www.cnews.ru/reviews/new/itservice2014/ 27.05.2015 16. В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина Управление внедрением информационных систем, Интернет-Университет Информационных Технологий М., 2008 17.Федеральный закон Российской Федерации от 22 октября 2004 г. N 125ФЗ Об архивном деле в Российской Федерации 76 Приложения 77 Приложение 1 – Матрица RACI для работ по миграции данных Таблица 6 Матрица ответственных ролей в проекте на этапе миграции 1 Наименование пакета работ Определение рамок процесса миграции Определение стратегии миграции в соответствии с требованиями верхнего уровня Составление плана работ Привлечение ресурсов для проведения процесса миграции Составление плана-графика работ и назначение ответственных Сбор бизнес-требований Проектирование алгоритмов миграции Консультации с вендорами систем Составление спецификации требований Разработка тест-планов Разработка/Настройка ПО для миграции в соответствии со спецификацией Валидация загруженных данных Ведение журнала опытной эксплуатации Очистка данных Тестирование функционала Оценка результатов миграции в соответствии с разработанными метриками Закрытие этапа миграции Системный аналитик I, C Менеджер по Разработчик разработке R, A I Тестировщик I R, A I, C I I I R, A R, A I I I I I R, A I I R R A, C A I R, C I I I R R I R A, C I, C I, C I I A A I R R I I A I R R I, A I I I I R, C A A R, A I, C I, C I R R I I В таблице использованы следующие обозначения: R – Responsible – исполнитель пакета работ. A – Accountable - роль, ответственная за результат пакета работ, может осуществлять контроль и руководство работами. C – Consult before doing - роль, осуществляющая поддержку выполнения работ в качестве эксперта, консультанта. I – Inform after doing – роль, которая должна быть проинформирована о результатах выполнения пакета работ. 1 78 Приложение 2 – Пример трассировки требований к миграции данных Таблица 7 Примеры трассировки пользовательских требований к миграции данных до тестовых сценариев Пользовательское требование Функциональное требование Модуль системы Тестовый сценарий Миграция данных должна быть Стратегия миграции - - - «большой взрыв» проведена единовременно без предполагает проведение одной итерации Требования остановки функционирования выгрузки и загрузки данных. планированию бизнеса. В работ проектируемую систему В систему-приемник должны быть перенесены все перенесены проектные к документы все должны документы с быть Требования в Количество датой выгрузке данных. в создания >= (Текущая дата – 10 лет). проектных документов с датой создания (Текущая дата – 10 лет) в системе-источнике = соответствии с нормативными Количество проектных документов с документами. датой создания (Текущая дата – 10 лет) в системе-приемнике. В проектируемую систему В проектируемой системе статус Утилита Юнит-тесты для документов типа что должны быть перенесены все «Разрешение выдано» заменен статусом миграции. «Разрешения», проверяющие, документы разрешения с в состоянии «Документ «Разрешение выдано». согласован», следовательно, Загрузчик: утилитой миграции произведена статуса «Документ должна принудительная «Разрешение согласован» выдано» для одинаковым быть функция смены идентификатором в системе-источнике и смена статусов системе-приемнике находятся в статусах на мигрируемых всех объектов документов типа «Разрешение». 79 «Разрешение выдано» и согласован», соответственно. «Документ продолжение таблицы 7 Пользовательское требование Функциональное требование В проектируемой должна быть системе Утилита миграции должна осуществлять Утилита реализована поиск всех дублирующих проверка уникальности словарях (справочниках). наименований записей словарях системы. Модуль системы записей в миграции. Загрузчик: в Утилита миграции должна осуществить функция (справочниках) поиск и актуализацию всех ссылок и дедубликации связей с найденными дублями. словарей Утилита миграции должна осуществить (справочников). удаление дублирующих записей из словарей (справочников). 80 Тестовый сценарий Проверка отсутствия дублей в мигрированных словарях (справочниках). Юнит-тестирование актуализированных мигратором связей и ссылок на дубли. Приложение 3 – Примеры схем жизненного цикла сущностей в системе-источнике Рис. 4 – Пример 1 диаграммы состояний сущности в системе-приемнике 81 Заявка получена с ПГУ Новая Эксперт/Оператор регистрирует заявку Зарегистрирована Эксперт выбирает заявку на рассмотрение На рассмотрении Эксперт формирует рекомендации Для отходов типа «Грунт»: Эксперт направляет рекомендации на ПГУ Рекомендации выданы Получен договор с Транспортной организацией Эксперт аннулирует текущее разрешение Эксперт открывает новое разрешение Выдано разрешение Эксперт закрывает разрешение Закрыта Рис. 5 - Пример 2 диаграммы состояний сущности в системе-приемнике 82 Приложение 4 - Фрагмент лога утилиты миграции Таблица 8 Фрагмент лога утилиты миграции данных Вид мигрируемого объекта данных Системаисточник ID объекта данных в системеисточнике ID объекта данных в системеприемнике Заявка Lotus 234771 0000013 Timestamp 23/04/2014 13:45:12 Заявка Lotus 234772 0000014 23/04/2014 13:46:14 Заявка 234773 0000015 Разрешение Lotus Система «Грунт» 10012 000100 23/04/2014 13:46:48 23/04/2014 20:21:34 Разрешение Система «Грунт» 10013 000101 23/04/2014 20:22:34 83 Статус миграции Код ошибки 0 - 1 10 1 11 0 - 1 11 Описание ошибки Отсутствие обязательного приложения Отсутствует обязательный атрибут «организациязаказчик строительства» Отсутствует обязательный атрибут – «номер разрешения» Приложение 5 - Журнал тестирования результатов миграции Таблица 9 Фрагмент журнала тестирования миграции данных в части тестирования функциональности системы-приемника после размещения данных ID тесткейса Описание операции в рамках тест-кейса Описание ошибки во время выполнения операции в рамках тесткейса Согласовать разрешение путем перевода объекта в статус "Согласовано". Для выполнения операции в экранной Кнопка неактивна для форме разрешения нажать всех мигрированных 1 на кнопку "Согласовать" разрешений Сгенерировать отчет "Сводные данные по 2 перемещению грунтов" Открыть экранную форму мигрированной заявки в 3 статусе "Новая" Влияние ошибки на функциональность системы Отсутствует возможность согласовать разрешение блокируется бизнеспроцесс согласования Влияние ошибки на связанные операции тестирования - Генерация отчета "Сводные данные по перемещению грунтов" невозможна Отсутствует возможность выгрузить статистические данные за период - Экранная форма не отображается Отсутствует возможность просмотра и редактирования данных по мигрированным объектам данных Отсутствует возможность тестирования бизнеспроцесса работы с заявкой 84 Критично сть ошибки Причина ошибки Критичная Для мигрированных разрешений не заполнен обязательный атрибут "заявка-источник", поэтому процесс согласования заблокирован Средняя Невозможно сформировать отчет за период более, чем 2 года, так как в выгрузку данных из системыисточника были включены исторические данные только за последние 2 года Критичная Невозможно открыть экранную форму заявки изза несоответствия форматов данных системы-источника и предусмотренных полей экранной формы системыприемника Приложение 6 - Результаты апробации разработанной методики Таблица 10 Результаты проектов и апробации методики Название показателя Дополнительные доработки Целевое Значение показателя значение 1 проект 2 проект 3 проект 20% 10% 3% более 80% 40% 10% 35% 20% 0 100% 50% - системы- 5-10% приемника Доля доработок миграционного ПО Не 15% Доля «потерянных» данных в общем объеме 0 данных Отклонение времени, затраченного на 10% миграцию, от плана 85
