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

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

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

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

3) Системы-источники имеют особенности работы с ссылками и связями между объектами данных. Например, вместо уникальных идентификаторов в качестве ссылок (foreign key) на объекты использовались имена, не имевшие проверок на уникальность. Таким образом, способы создания ссылок и связей между объектами данных в системах-источниках должны быть проанализированы при получении данных из систем-источников для того, чтобы определить насколько представляется возможными мигрировать такие связи в систему-приемник.

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

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

В состав тестовой выгрузки из систем-источников вошли следующие объекты:

· Пример классификаторов из двух систем, не дублирующих друг друга по смыслу. В состав выгрузки вошли два справочника из каждой системы: иерархический и плоский;

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

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

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

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

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

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

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

2.4 Выявленные проблемы документирования требований к миграции данных

В рамках плана проекта была запланирована работа по разработке документа, описывающего требования к миграции данных. Требования к миграции данных были зафиксированы в документе «Функциональная спецификация на утилиту миграции данных». Функциональная спецификация составлялась на основе применяемых ими методологий разработки ПО и государственных стандартов. Дальнейший анализ государственных стандартов будет проводиться для того, чтобы установить соответствие между рассмотренными в главе 1 методологиями миграции данных и государственными стандартами разработки ИС, а также для выявления проблем работ по документированию требований к миграции данных.

Создание информационных систем в проектах, где заказчиком является организация государственного сектора, должно проводиться в соответствии с государственным стандартом - ГОСТ 34.601-90 Автоматизированные системы [8]. Стадии создания. Любая другая применяемая разработчиком методология создания ИС должна соответствовать основным положениям упомянутого выше государственного стандарта.

Этапы процесса миграции данных, описанные нами в главе 1, можно соотнести со стадиями разработки информационной системы, обозначенными в ГОСТ 34.601-90.

Формулировка стратегии миграции данных может осуществляться на стадии «Обследование объекта и обоснование необходимости создания в АС». Однако в соответствии с государственным стандартом на этой стадии не предусмотрено работ по оценке рисков бизнеса при выбранной стратегии миграции.

Следующий этап процесса миграции данных - подготовительный этап - может соотноситься со стадиями «Формирование требований пользователя к АС», «Разработка и утверждение технического задания на создание АС» и «Разработка предварительных проектных решений по системе и её частям». На практике в техническом задании фиксируются только высокоуровневые требования к миграции данных. В ТЗ могут быть определены рамки миграции и закреплены требования по способу проведения миграции: в одну или несколько итераций, «онлайн» или «оффлайн». Таким образом, требования к профилю данных для переноса в целевую ИС, их составу, качеству, временному горизонту выгрузки остаются за рамками технического задания и должны быть зафиксированы в других проектных артефактах. Более подробный анализ государственного стандарта «ГОСТ 34.201-89 Виды, комплектность и обозначение документов при создании автоматизированных систем» [10] приведен ниже.

Работы по переносу и загрузке данных совпадают со стадиями «Разработка предварительных проектных решений по системе и её частям», «Разработка проектных решений по системе и её частям» и «Подготовка объекта автоматизации к вводу АС в действие». Стадиям разработки предварительных проектных решений и проектных решений соответствуют работы по подготовке утилиты миграции. Работы по загрузке данных в целевую ИС и тестирование работоспособности целевой ИС с загруженными данными должны производиться на стадии подготовки объекта автоматизации к вводу АС в действие.

Проектная документация в проектах по созданию и внедрению КИС в организациях государственного сектора, как правило, разрабатывается в соответствии с государственными стандартами (ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы, ГОСТ 34.201-89 Виды, комплектность и обозначение документов при создании автоматизированных систем).

Рассмотрим подробнее, в каких проектных артефактах согласно ГОСТ 34.602-89, ГОСТ 34.201-89, а также ГОСТ 19.101-77 [11] должны быть зафиксированы бизнес-требования к миграции данных.

Документирование требований к миграции данных должно производиться на стадии разработки и создания технического проекта и рабочего проекта информационной системы. Требования к утилите миграции должны разрабатываться на основе информации о состоянии данных в системе-источнике - «as is». Описание объекта автоматизации «as is» содержится в разделе «Характеристика объекта автоматизации», однако согласно государственному стандарту ГОСТ 34.602-89 этот раздел должен содержать «краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию». Соответственно, в этот раздел не будет включено описание логической структуры данных системы-источника, необходимое для формирования требований к выгрузке и проверкам качества и полноты данных.

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

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

Таким образом, анализ государственных стандартов, регулирующих создание информационных систем и документирование требований к ПО, позволяет сделать вывод о том, что требования к утилите миграции разрабатываются на основе модели данных и требований к данным в системе-приемнике - типа «to be». Соответственно, ограничения системы-источника, а также ограничения, связанные с качеством исторических данных, не принимаются во внимание при разработке пакета требований к миграции данных. Именно таким образом была разработана функциональная спецификация на утилиту миграции данных в анализируемом проекте.

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

Таким образом, требования к утилите миграции и загрузке данных были задокументированы на основе модели данных «to be». В ФС были отражены следующие типы требований к загрузчику данных:

Состав логических проверок целостности данных, а именно:

1) Из загруженных данных должны быть исключены экземпляры сущностей с отсутствующими значениями обязательных атрибутов согласно модели данных внедряемой системы;

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

3) Из загруженных данных должны быть удалены экземпляры сущностей с нарушенными связями и отсутствующими ссылками, которые являются обязательными согласно модели данных внедряемой системы;

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

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

6) В ФС на утилиту миграции отсутствовал полный маппинг атрибутов всех сущностей объектной модели. Атрибутный состав сущностей в проектируемой системе и системах-источниках отличается, часть атрибутов при маппинге была удалена, что привело к потере полноты мигрируемых данных.

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

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

2.5 Выявленные проблемы при тестировании загруженных данных в систему-приемник

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

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

Цели этапа тестирования миграции данных в рамках анализируемого проекта были сформулированы следующим образом:

1. Определить полноту загруженных данных в систему-приемник;

2. Выявить ошибки и дефекты в работе утилиты миграции;

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

4. Выявить ошибки и дефекты в работе внедряемой системы после размещения данных.

В качестве методологической базы для организации работ по тестированию на этапе миграции данных в проекте внедрения информационных систем были использованы положения таких стандартов, как ANSI/IEEE Std 829-1998 - Standard for Software Test Documentation [1] и ANSI/IEEE Std 1008-1987 - IEEE Standard for Software Unit Testing [2].

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

· Определение рамок тестирования: функции и модули системы для тестирования;

· Определение источников тестовых данных для проведения проверок;

· Сопоставление выбранных функций системы с планируемыми юнит-тестами;

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

· Составление плана ресурсов и календарного плана проведения тестирования.

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

· Разработка тестовой документации: тестовые сценарии с подробным описанием процедуры тестирования и ожидаемым поведением системы;

· Согласование пакета тестовой документации.

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

· Выполнение тестовых сценариев;

· Доработка тестовых сценариев при обнаружении дефектов, в случае если дефект был порожден некорректным тестовым сценарием;

· Доработка ПО при обнаружении дефектов, в случае если дефект был порожден некорректно разработанным ПО;

· Создание новых тестовых сценариев - при необходимости;

· Составление отчета о тестировании.

В ходе проведения работ по тестированию в рамках анализируемого проектного опыта был составлен документ «Программа и методика испытаний» в соответствии с ГОСТ-19.101-77 [11], в котором были частично описаны тестовые сценарии этапа миграции данных. В данном документе были зафиксированы процедуры тестирования утилиты миграции, направленные на выявление технических сбоев и ошибок работы, однако в документе не были зафиксированы процедуры тестирования бизнес-логики утилиты, качества загруженных данных и пост-миграционные процедуры тестирования системы-приемника. Таким образом, документирования этапа миграции данных было проведено не полностью и не могло обеспечить выполнение эффективного и полного тестирования.

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

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

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

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

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

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

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

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



3. Методика организации проведения миграции данных

3.1 Последовательность шагов для организации миграции данных

Разработка общих требований к миграции данных

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

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

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

Параллельно с выбором стратегии проведения миграции данных менеджментом проекта и/ или бизнес-аналитиком должна быть произведена выявление типовых рисков миграции данных. Для каждого выявленного риска должна быть выбрана стратегия (методы) работы с риском и разработан комплекс мероприятий по предотвращению риска. Стратегией предотвращения риска может быть одна из следующих [13]:

· отказ от чрезмерно рисковой деятельности (метод отказа),

· профилактика или диверсификация (метод снижения),

· аутсорсинг затратных рисковых функций (метод передачи),

· формирование резервов или запасов (метод принятия).

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

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

Таблица 1 Матрица рисков и возможных стратегий работы с рисками этапа миграции

Стратегия работы с риском Риск	Отказ	Снижение	Передача	Принятие
Риски составления технической спецификации	-	Проработка требований к миграции совместно с бизнесом, владельцами и потребителями мигрируемых данных	Привлечение к работам по составлению технической спецификации консультантов	Формирование резерва бюджета и времени на проекте для работы с потенциальными запросами на изменение
Риски тестирования	-	Проработка тестовых планов и сценарием с привлечением бизнес-пользователей	Передача пакета работ по тестированию отдельной команде с заранее определенными условиями приемки их резудьтатов	Формирование резерва времени и бюджета на потенциальные дополнительные работы вследствие неполного тестирования миграционного ПО и размещенных данных
Риски процесса получения и загрузки данных	-	Проработка требований к тестовой выгрузке. Проведение «тестовой» миграции с использованием тестовой выгрузки	-	Формирование резерва бюджета и времени для повторных получений выгрузок и итеративной загрузки
Стратегия работы с риском Риск	Отказ	Снижение	Передача	Принятие
Риски, связанные с работой проектной команды	-
Риски размещения данных в целевой системе	-	Параллельная проработка модели данных “as is” и “ to be” для нивелирования различий в форматах и способах работы с данными в источнике и приемнике	-	Формирование резерва времени и бюджета для доработок функциональности системы-приемника

Организация планирования работ по миграции данных

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

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

План работ по миграции определяет набор задач и ответственных за их выполнение, распределенных с помощью матрицы RACI. Проектный план работ по миграции должен содержать пакеты задач и работ для каждого из этапов миграции: от подготовительного до пост-миграционного этапа работ. С учетом результатов анализа проектного опыта была разработана ИСР, позволяющая избежать рисков и соответствующая «эталонным» теоретическим подходам к организации миграции данных.

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

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

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

1. Предмет (тема) коммуникации.

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

Кто должен участвовать в коммуникации? Какие ролевые группы?

3. Какой тип взаимодействия приемлем?

4. Что должно являться выходом коммуникации?

5. Необходимость взаимодействия с проектной команды и бизнес-пользователей;

6. Кто должен участвовать в коммуникации со стороны проектной команды и со стороны бизнеса?

7. Какой тип взаимодействия с бизнес-пользователями приемлем?

8. Что должно являться выходом коммуникации с бизнес-пользователями?

9. Кто должен быть осведомлен о результатах коммуникации?

Шаблон плана коммуникаций на этапе миграции данных приведен в таблице 2 ниже (Таблица 2).

Таблица 2 Шаблон плана коммуникации на этапе миграции данных

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

Разработка и документирование бизнес-требований к миграции данных

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

1. Обследование эксплуатируемой информационной системы

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

Обследование существующей информационной системы в рамках разработки требований к миграции данных может проводиться в рамках работ по обследованию бизнеса всего проекта внедрения ИС. Обследование в рамках разработки требований к миграции данных должно быть направлено на создание модели данных `as is'. Модель данных `as is' позволит подготовить требования к составу мигрируемых данных из системы-источника в систему-приемник.

Модель данных `as is' описывает все объекты данных, которые используются в эксплуатируемой системе. После составления такой модели заказчику будет проще выбрать перечень объектов данных для переноса в систему-приемник. В такой модели должны быть указаны имена сущностей, а также описан их атрибутный состав и взаимосвязи между сущностями с указанием их кардинальности.

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

Помимо составления модели данных `as is' на этапе обследования должны быть описаны правила работы со словарями и справочниками в эксплуатируемой системе. В частности, должны быть описаны следующие моменты для каждого словаря:

- Наименование словаря или справочника;

- Ответственное за администрирование словаря функциональное подразделение;

- Наличие проверки уникальности для кодов и значений записей словарей;

- Наличие правил регулярного обновления записей в словарях;

- Описание правил работы с записями словарей, потерявшими актуальность;

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

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

2. Разработка требований к профилю данных для миграции

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

Бизнес-пользователи являются источниками для получения ответов на следующие вопросы о профиле данных для миграции данных:

1) Будут ли мигрированные данные являться входными для работы бизнес-процесса, автоматизированного в проектируемой системе? Ответом на данный вопрос должна стать таблица-описание соответствия объектов данных системы-источника и бизнес-процессов, автоматизированных в целевой системе.

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

3) Какому объекту данных целевой системы соответствует каждый из выбранных для миграции объектов данных системы-источника? Ответом на данный вопрос должна стать таблица маппинга объектов данных системы-источника и системы-приемника.

4) Есть ли в атрибутном составе объектов данных системы-источника поля или группа атрибутов, которые не будут использоваться в целевой системе? Ответом на данный вопрос должна стать таблица описания атрибутного состава объектов данных с проставленным флагом: используется/ не используется в целевой системе.

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

6) Происходила ли модернизация системы-источника, результатом которой стало значительное изменение в структуре данных, которые необходимо мигрировать? Примеры изменений:

- Изменение состава обязательных атрибутов;

- Изменение правил хранения объектов данных;

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

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

7) Какое функциональное подразделение или конкретные пользователи являются владельцами данных? Ответом на этот вопрос должна стать таблица соответствия объектов данных и сотрудников заказчика.

Сотрудники ИТ-подразделения являются источниками для получения ответов на следующие вопросы о профиле данных для миграции:

1) Где физически хранятся данные, выбранные бизнес-пользователями для миграции в целевую систему? Что является источником данных: корпоративное приложение, система или источники за пределами организации-заказчика? Ответом на данный вопрос должна стать таблица соответствия объектов данных и их хранилищ (имя и тип БД, имя таблицы/таблиц в БД).

2) Позволяет ли метаинформация мигрируемого контента разработать алгоритмы миграции? Возможно ли произвести анализ структуры данных на основе метаинформации?

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

Сотрудники ИТ-подразделения и бизнес-пользователи совместно должны произвести оценку критичности потенциальных ошибок при переносе данных из системы-источника в целевую систему. В частности, бизнес-пользователи и сотрудники ИТ-подразделений должны проанализировать взаимосвязи объектов данных на уровне используемой БД для определения перечня возможных проверок целостности данных при переносе в целевую систему.

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

3. Разработка требований к утилите миграции

1) Требования к очистке и логическим проверкам данных

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

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

- Заполнены ли все обязательные атрибуты?

- Физический тип данных каждого атрибута в системе-источнике и системе-приемнике совпадают?

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

- Формат хранения данных (даты, десятичные числа) соответствуют требованиям в целевой системе?

- Идентификаторы объектов данных в системе-источнике позволяют их однозначно различить?

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

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

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

- Недостающие обязательные атрибуты могут быть заполнены заранее определенными значениями - «заглушками».

- Значения атрибутов, длина которых не соответствует требованиям целевой системы, должны быть сокращены.

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

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

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

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

2) Требования к именованию сущностей в системе-приемнике

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

Алгоритмы именования и нумерации объектов данных должны быть разработаны в следующих случаях:

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

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

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

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

3) Требования к логированию миграции данных

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

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

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

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

· Вид мигрируемого объекта данных;

· Система-источник;

· Уникальный идентификатор объекта данных в системе-источнике;

· Уникальный идентификатор объекта данных в системе-приемнике;

· Дата и время проведения загрузки для данного объекта данных;

· Сформированное утилитой миграции имя/номер для данного объекта данных, в случае если для данного объекта данных был применен алгоритм формирования имен/ номеров сущностей;

· Флаг: был ли объект данных мигрирован в систему-приемник или был исключен из загруженных данных;

· Причина, по которой объект был исключен из загруженных данных - состав логических проверок и правил;

· Описание ошибки, возникшей в ходе миграции объекта данных, если такая произошла.

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

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

Фрагмент лога утилиты миграции приведен в приложении 4 (Приложение 4 - Фрагмент лога утилиты миграции).

Проведение тестирования в рамках работ по миграции данных

Работы по тестированию состоит из следующих пакетов работ:

1. Первичное тестирование миграционного ПО на соответствие технической спецификации;

2. Бизнес-тестирование миграционного ПО на соответствие требованиям бизнеса к алгоритмам трансформации данных во время миграции;

3. Тестовая очистка и загрузка данных в систему-приемник;

4. Тестирование работы функциональности системы-приемника после размещения мигрируемых данных;

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

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

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

1. Определить по логу утилиты миграции игнорированные при загрузке объекты данных.

2. Убедиться, что эти объекты в системе-источнике удовлетворяли условиям применения логических проверок или механизмов трансформации.

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

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

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

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

- Работа бизнес-алгоритмов, логических проверок и механизмов преобразования на реальных данных;

- Работоспособность миграционного ПО на приближенных к продуктивным объемах данных.

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

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

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

1. Тестирование работоспособности системы-приемника;

2. Детальное тестирование функциональности системы-приемника.

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

- перечень экранных форм, которые необходимо открыть,

- количество объектов в справочниках (словарях), которое должно быть видно пользователю;

- количество объектов в реестрах системы, которое должно быть видно пользователю,

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

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

В соответствии со стандартом ANSI журнал (лог) тестирования миграции данных должен иметь следующую структуру:

1. Идентификатор тест-кейса;

2. Описание операции в рамках тест-кейса;

3. Описание ошибки во время выполнения операции в рамках тест-кейса;

...