Файл: Утверждаю Куратор проекта.pdf

5.5.4.
Обеспечение целостности при переносе функционала
Поскольку переносом модификации занимается не разработчик модификации, а сотрудник отдела ИС, то для обеспечения целостности функционала требуется тщательным образом подходить к комментированию проектного кода
(комментарии должны содержать код проекта и код модификации). Кроме того, помимо экспорта файла проекта необходимо готовить инструкцию по обновлению в виде текстового файла с описанием изменения структуры данных (как сейчас это и принято делать). Контроль за наличием комментариев в коде проекта осуществляется ведущим разработчиком. Наличие инструкции контролируется сотрудником ИС, проводящим перенос модификации.
5.5.5.
Действия на стороне пользователя
В рамках данного проекта допускается, что на стороне пользователя используется браузер Internet Explorer. В том случае, если пользователь пользуется альтернативными браузерами и в ходе тестирования портала будет выяснено, что альтернативные браузеры работают с порталом некорректно, понадобится установка какой-либо из последних версий Internet Explorer (начиная с версии 6.0).
Ответственность за установку Internet Explorer на стороне дилера лежит на IT- службе самого дилера.
Требования к IT-инфраструктуре на стороне дилеров приводятся в пользовательской документации и предоставляются дилерам. Ответственным за передачу документации является эксперт проекта.
Портал будет располагаться по тому же веб-адресу, что и существующий портал BIG DATA. Перенастройка осуществляется ответственными сотрудниками
ИС, поскольку сотрудники, скорее всего, будут лишены доступа к рабочей среде.
5.5.6.
Требование к резервированию сред разработки и тестирования
Резервное копирование проводится ответственными сотрудниками отдела ИС
Клиента. Среды разработки и тестирования следует включить в процедуру резервного копирования, начиная с этапа разработки.

Процесс резервного копирования Microsoft Dynamics™ AX должен быть организован согласно принятым у Клиента процедурам и интегрирован с общим процессом резервного копирования.
6.
План отката
Данный раздел определяет объекты переноса (справочники) из базы данных
Microsoft Dynamics
™ AX в базу данных BIG DATA на случай отката на старое приложение, а также определяет способы, инструменты и регламент переноса данных. Возможность отката предусматривается на случай, если в силу неких маловероятных причин после начала промышленной эксплуатации портала BIG
DATA в Microsoft Dynamics™ AX будет выявлена невозможность дальнейшей эксплуатации портала (вследствие каких-либо недоработок) и будет принято решение о временном возврате к прежнему приложению.
В случае необходимости отката на старое приложение откат осуществляется следующим образом:
1) должны быть перенесены данные BIG DATA из БД Microsoft Dynamics™ AX в БД портала BIG DATA;
2) настройки, необходимые для обращения пользователей к порталу BIG
DATA
, должны быть восстановлены. То есть необходимо перенастроить IIS обратно на работу с прежним порталом BIG DATA (указать путь к директориям в локальной сети, где хранятся веб-страницы и прочий контент портала), сохраняя тот же веб-адрес для доступа к порталу. Данные настройки восстанавливаются силами Клиента, поскольку сотрудники не будут иметь доступ к рабочей среде с необходимыми правами.
Решение об откате на старое приложение принимает Заказчик проекта.
Решение должно быть зафиксировано в виде электронного письма на имя
Руководителя проекта от Компании с копией Руководителю проекта от
Исполнителя. Получение письма авторизует процесс отката.
6.1.
Данные к переносу
Ответственность за перенос данных лежит на представителях IT1. При откате переносятся следующие справочники:
• справочник автомобилей.
Для переноса можно использовать существующий DTS-пакет (определён на SQL-сервере Arzamas), с помощью которого на сегодняшний день производится синхронизация данной информации в БД Microsoft Dynamics™ AX с БД BIG DATA. При необходимости может быть создан дополнительный функционал по переносу данной информации;
• история обмена автомобилей. Историю обмена автомобилей переносится с помощью действующего функционала синхронизации между Microsoft

Dynamics
™ AX (хранимая процедура в БД Microsoft Dynamics™ AX) и порталом BIG DATA;
• справочник дилерских центров;
• справочник клиентов;
• справочник контрактов;
• справочник операций. Должен быть создан функционал (скорее всего, функционал будет реализован в виде хранимых процедур в БД Microsoft
Dynamics
™ AX), осуществляющий перенос указанных справочников из
Microsoft Dynamics
™ AX в БД BIG DATA;
• история автомобилей;
• история контрактов;
• история операций;
• история удаленных контрактов. Данные некритичны для функционирования портала. Возможно обойтись без их переноса: всё-таки откат к прежнему порталу BIG DATA стоит рассматривать только как временную меру на период, пока не будут решены проблемы с порталом BIG DATA в Microsoft
Dynamics
™ AX, приведшие к необходимости отката. Или их можно перенести впоследствии. Для переноса понадобится создать необходимый функционал (хранимая процедура в БД Microsoft Dynamics™ AX).
6.2.
Подготовка к откату
Функционал переноса данных для отката следует реализовать после завершения активной разработки и компонентного тестирования (структура данных в Microsoft Dynamics™ AX на данный момент будет точно определена) и желательно после подготовки и обкатки функционала по миграции данных из портала BIG DATA в Microsoft Dynamics™ AX, что предположительно должно уменьшить сложность работ над функционалом отката.
Для тестирования правильности отката необходимо будет развернуть в тестовой среде копию БД BIG DATA и копию файлов/страниц BIG DATA портала.
Развёртывание будет производится силами АргусСофт, IT1 и сотрудников отдела
ИС Клиента. С помощью реализованного функционала необходимо будет перенести данные из БД Microsoft Dynamics™ AX и провести тестирование, которое будет заключаться в проверке возможности работы с данными, полученными из Microsoft Dynamics™ AX, в портале BIG DATA.
Тестирование отката на старое приложение также определит время, необходимое для ввода в строй старого приложения.
6.3.
Последовательность действий при откате
1.
Отключить доступ пользователей к порталу Microsoft Dynamics™ AX.

2.
Произвести копирование БД BIG DATA портала.
3.
Произвести перенос данных (запустить DTS-пакеты, выполнить хранимые процедуры).
4.
Настроить доступ пользователей к порталу BIG DATA.
Операции проводятся силами отдела ИС Клиента и представителями IT1.
7.
План миграции данных
При миграции и развертывании приложений должна также выполняться миграция следующих данных:
• данные из старого BIG DATA в новый портал на основе Axapta;
• данные в ПП – из нового портала;
• данные в OLAP – из нового портала.
7.1.
Требования к миграции данных BIG DATA в Axapta
Документ BIG DATA Integration to Axapta устанавливает следующие требования к переносу данных из существующего портала BIG DATA. Требуется перенести все данные с начала 2004 года, находящиеся:
• в справочнике автомобилей;
• справочнике дилерских центров;
• справочнике контрактов;
• справочнике клиентов;
• справочнике операций;
• истории автомобилей;
• истории контрактов;
• истории обмена автомобилей;
• истории удаленных контрактов.

7.2.
План миграции данных BIG DATA в Axapta
7.2.1.
Справочники к переносу
Планируется переносить следующие справочники:
• справочник автомобилей;
• справочник дилерских центров;
• справочник клиентов.
В Microsoft Dynamics AX в указанных справочниках в любой момент времени находится актуальная информация. Переносить из BIG DATA в
Microsoft Dynamics AX эту информацию не планируется. Но в Axapta вручную для дилеров надо будет указать страну и бренд (также при реализации нужно сделать эти поля обязательными к заполнению для дилеров).
Также планируется переносить:
• справочник контрактов. В данный момент по действующей процедуре синхронизации между порталом BIG DATA и Axapta переносятся только виртуальные контракты, понадобится создать функционал по переносу также и резервов, виртуальных резервов и контрактов;
• историю обмена автомобилей. История переносится (обновляется) по действующей процедуре синхронизации между порталом BIG DATA и
Axapta без каких-либо изменений;
• справочник операций. Необходимо реализовать функционал по переносу операций в Axapta. На сегодняшний день раз в неделю (и в начале каждого месяца) проводится процедура закрытия периода, в рамках которой производится закрытие ранее выполненных операций, после чего любые операции закрытого периода откатить уже нельзя. Если перенос данных будет осуществлён непосредственно после закрытия периода, то актуальных операций не будет. Принятие такого допущения позволит уменьшить сложность функционала по переносу операций, поскольку не будет необходимости откатывать в Axapta операции, сделанные на портале
BIG DATA.
Исключение – операции создания контракта и создания виртуального контракта, отменять которые можно и в закрытом периоде;
• историю автомобилей;
• историю контрактов;
• историю удаленных контрактов. Должен быть создан функционал по переносу. Понадобится создание в Axapta нового справочника для хранения данной информации.
7.3.
Подход к миграции данных
Функционал переноса данных должен быть реализован к моменту нагрузочного тестирования, то есть после того как закончится активная фаза разработки и будет уточнена структура данных в Axapta.

Перед проведением нагрузочного тестирования в тестовую среду будут перенесены данные из БД BIG DATA.
На данном этапе, помимо подготовки рабочего объёма данных для нагрузочного тестирования, мы получим общее время, требуемое для миграции данных, что понадобится для определения регламента переноса данных на рабочую версию.
Процедура миграции данных состоит из следующих шагов:
• подготовить пакеты полной и частичной синхронизации из Axapta;
• остановить работы в рабочей среде, зафиксировав таким образом данные на определенный момент времени;
• выполнить стандартную существующую процедуру синхронизации данных. При этом в Axapta попадают не те же самые данные, которые перейдут в нее при использовании механизма миграции;
• выполнить резервное копирование обеих БД;
• запустить рабочие приложения;
• восстановить из резервных копий BIG DATA и Axapta;
• к Axapta применить дополнительно процедуру миграции приложения;
• выполнить процедуру миграции данных BIG DATA в Axapta.
Упрощенно порядок миграции данных представлен на картинке.

AX
DSMS
Синхронизация
Шаг 1: STOP!
DSMS
R
e s
to re
Рабочая среда
Тестовая среда
AX
R
e s
to re
,
М
е ха н
и зм м
и гр а
ц и
и п
р и
л о
ж е
н и
я
Миграция данных
Шаг 2: Стандартная синхронизация + backup
Шаг 3: Восстановить из резервной копии DSMS
Шаг 4: Восстановить из копии AX и применить процедуру миграции приложения
Шаг 5: Миграция данных
8.
Контроль миграции данных
8.1.
Контроль миграции BIG DATA в Axapta
Основная цель процедуры: убедиться, что миграция BIG DATA в Axapta работает корректно.
Вторичная цель: снизить вероятность того, что при переносе данных из БД на портал были допущены ошибки в алгоритмах. А также снизить вероятность того, что данные для визуализации были взяты не из тех источников. Этот риск возможен потому, что БД обеих систем денормализованы.
8.1.1.
Первичный контроль
Усилиями основного подрядчика (IT1) создается функциональный дизайн, который фиксирует:
• показатели контроля (что планируется контролировать);
• источники данных для построения показателей контроля;
• описание формата файла(ов), который будет содержать показатели контроля.
Документ согласуется с АргусСофт. На основе этих спецификаций оба подрядчика разрабатывают процедуры выгрузки показателей контроля в файл специфицированного формата.

После выполнения миграции данных из BIG DATA в Axapta процедуры выгрузки запускаются в обеих системах. Результаты предоставляются эксперту проекта.
Эксперт проекта выделяет из набора данных агрегированные показатели контроля (их не так много). По агрегированным показателям он выполняет ручной контроль путем сравнения этих данных в двух файлах. Форматы файла идентичны.
Детальные показатели контроля с помощью специальной утилиты Oracle и системного администратора сравниваются автоматически посредством вычитания. Эксперт получает результат сравнения и определяет корректность данных.
8.1.2.
Вторичный контроль
Эксперт проекта использует штатную функцию порталов по выгрузке журналов в формат XLS. Формат результатов из каждой системы будет различным и не подлежит автоматическому контролю. Контроль будет осуществляться вручную и выборочно.
Будут сравниваться:
1) выгрузка из BIG DATA с выгрузкой из Axapta;
2) выгрузка из BIG DATA с выгрузкой из БД BIG DATA;
3) выгрузка из Axapta с выгрузкой из БД Axapta.

8.1.3.
Схема процесса
AX
DSMS
Миграция данных
MICROSOFT CORPORATION
XLS - отчеты
MICROSOFT CORPORATION
XLS - отчеты
Pay to
$
Выгрузка с портала в XLS
Выгрузка с портала в XLS
Эксперт проекта
Ручной визуальный выборочный контроль.
Вторичная проверка
Oracle util
Детальные данные в большом объеме
Эксперт проекта
Агрегированные данные в малом объеме
Эксперт проекта
Эксперт проекта
Контроль риска ошибок в алгоритмах и денормализации БД
Контроль риска ошибок в алгоритмах и денормализации БД
8.2.
Контроль миграции источника данных плазменных панелей
Цель процедуры: убедиться, что новый механизм передачи данных в БД ПП работает корректно.
Процедура контроля должна проводиться после выполнения миграции данных
BIG DATA в Axapta и процедуры контроля ее корректности.
Процедура состоит из следующих шагов:
• в тестовой среде
1
необходимо поднять два тестовых приложения ПП и две тестовые БД ПП;
• в одну тестовую систему синхронизировать данные из BIG DATA. При этом будет использоваться существующий механизм;
• в другую тестовую систему синхронизировать данные из Axapta. При этом будет использоваться новый механизм. Корректную работу этого механизма и надлежит проверить;
1
Эту задачу будет выполнять Андрей Жуков. Конкретное местоположение (серверы) тестовых систем будет определено при постановке задачи. С Андреем это согласовано. Предварительно – там же, где и существующая тестовая среда для ПП.

• данные сравниваются визуально через Internet Explorer экспертом проекта.
Ввиду небольшого объема данных автоматизировать сравнение нет смысла.
9.
Приложение 1. Шаблон протокола тестирования
Протокол тестирования
<Название модификации (бизнес-процесса)>
Дата: _____________
№ Процедура/
функция
Отдел
Цели
тестирования
Отметка
о приёмке
Отметка о приёмке
пользовательской
документации
ФИО/
подпись
DSMS
AX
Тестовая среда
Процедура миграции данных DSMS2AX проведена
БД Плазменных панелей №1
БД Плазменных панелей №2
С
ущ е
ст ву ю
щ ий м
ех а
ни зм п
ер е
д ач и д
ан ны х
Н
ов ы
х м
ех ан и
зм
Эксперт проекта
Дост уп че рез
IE
До сту п ч ере з IE
Ручной визуальный контроль

№ Процедура/
функция
Отдел
Цели
тестирования
Отметка
о приёмке
Отметка о приёмке
пользовательской
документации
ФИО/
подпись
1

Принято

Принято с замечаниями

Не принято

Принято

Принято с замечаниями

Не принято
2

Принято

Принято с замечаниями

Не принято

Принято

Принято с замечаниями

Не принято
Результаты тестирования
<Название модификации (бизнес-процесса)>

Принято

Принято с замечаниями

Не принято
Перенос модификаций в рабочую версию разрешаю:
Владелец информационного ресурса
Дата
Подпись
10.
Приложение 2. Шаблон списка замечаний
Замечания по результатам тестирования
Дата:
__________
Отдел:
______________
<Название модификации (бизнес-процесса)>
№
№ пункта
протокола
Описание
Подпись
Дата / принято
1 2