Чат поддержки

Практикум
Привет! Это поддержка Практикума 👋 Если что-то не получается — постараемся помочь. Пишите в чат или выберите другой способ связи

пт, 2 декабряв 17:21

Мы уже начали заниматься вашим вопросом, ответим в ближайшее время

Практикум

Здравствуйте!

Поддержка не сможет помочь с вопросами, связанными с теорией или задачам из курса «Системный аналитик» — в этой ситуации рекомендуем вам обратиться к вашему преподавателю в чате в Slack.

Если же у вас возникнут иные вопросы — обязательно пишите, будем рады помочь :)

17:24

Выбрать способ связи

Поменять когорту

Перейти в профиль

Выйти из профиля

Добавить аккаунт

Поддержка, обслуживание и оценка результатов

спринт Поддержка, обслуживание и оценка результатов

Рабочая документация

2/2

О чём этот спринт

Документирование по ГОСТ

План миграции

4/4

План миграции

План подготовки кадров

Обучение пользователей

Информация для пользователей

Постпроектная деятельность

1/1

Воркшоп и домашнее задание

2/2

Заключение

1/1

Пригласить друзей

План миграции

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

Даня

Ты, кажется, что-то говорила о плане миграции? Его тоже будем составлять?

Айгуль

Ой, я погорячилась — нам он не понадобится 😅

Даня

Почему?

Айгуль

У Капсулы не было другого ПО, мы разработали первое.

Так, конечно, не всегда бывает, так что о плане миграции тебе стоит знать!

Даня

Окей! Рассказывай 😜

Поехали!

Зачем нужна миграция?

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

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

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

Миграция ПО — это процесс перехода организации от старого ПО к новому.

Организационные изменения

Миграция на новое ПО почти никогда не происходит сама по себе. Вместе с миграцией происходят и организационные изменения.

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

Размораживание

Движение

Замораживание

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

Размораживание

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

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

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

Движение

Второй этап подразумевает непосредственный переход на новое ПО и на новые процессы. На этом этапе нужно выполнить много задач, в частности:

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

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

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

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

Замораживание

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

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

Основная задача этапа: сделать всё возможное, чтобы новое ПО и новые процессы стали привычными и эффективными.

Схема миграции

Даня

Так, и как для всех этих процессов план составить?

Айгуль

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

Даня

Как это понимать? 🙃

Айгуль

Сейчас объясню!

Подробнее о плане миграции

План миграции

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

План миграции включает в себя принятие решений по трём направлениям:

Подготовка бизнеса

Проектная команда должна определить оптимальную стратегию перехода. Сделать это можно с учётом нескольких параметров: бюджет, сроки, риски.

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

Подготовка технологий

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

Подготовка кадров

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

План миграции

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

В этом уроке разберём подробнее подготовку бизнеса и технологи. О подготовке кадров вы узнаете в следующих уроках спринта.

Подготовка бизнеса

Стратегия перехода определяет процесс ввода нового ПО и перехода организации на него.

Стратегия перехода включает в себя три составляющие:

выбор стиля перехода;

определение области распространения изменений;

определение составных частей изменений.

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

Составляющие стратегии перехода

Выбор стиля перехода

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

Прямой переход;

Параллельный переход.

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

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

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

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

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

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

По описанию ситуации определите, о каком стиле перехода идёт речь.

Прямой переход

Все данные старой системы будут перенесены единоразово в новую систему.

Все данные старой системы будут перенесены единоразово в новую систему.

С понедельника все сотрудники начинают работать в новой системе.

С понедельника все сотрудники начинают работать в новой системе.

Наиболее рискованный стиль перехода.

Наиболее рискованный стиль перехода.

Параллельный переход

Пользователь может выбрать старый или новый дизайн личного кабинета.

Пользователь может выбрать старый или новый дизайн личного кабинета.

В старой системе нельзя зарегистрироваться — можно только войти в личный кабинет с уже существующими учётными данными.

В старой системе нельзя зарегистрироваться — можно только войти в личный кабинет с уже существующими учётными данными.

Каждую ночь данные старой и новой систем синхронизируются.

Каждую ночь данные старой и новой систем синхронизируются.

Наиболее затратный стиль перехода

Наиболее затратный стиль перехода

Проверить
Правильных ответов: 7, неправильных ответов: 0.
Ответить повторно

Определение области распространения

Новое ПО можно внедрять поэтапно в разных частях организации или во всей организации единовременно. Исходя из этого область распространения может быть:

пилотной;

одновременной.

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

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

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

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

Определение составных частей

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

Внедрить новое ПО можно двумя способами:

модуль за модулем;

систему целиком.

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

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

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

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

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

Прочитайте утверждение и определите, о какой составляющей стратегии перехода идёт речь.

Скорость внедряемых изменений.

Стиль перехода

То, насколько резко будут происходить изменения, определяет стиль перехода.

Функции ПО, которые будут доступны пользователю после запуска.

Составные части

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

В какой последовательности группы пользователей начнут использовать новое ПО.

Область распространения

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

Начать заново

Выбор стратегии перехода

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

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

При определении стратегии миграции необходимо рассматривать три фактора:

риски;

стоимость (бюджет);

сроки.

Риски

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

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

Стиль перехода

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

Область распространения

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

Составные части

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

Как оценить риски

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

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

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

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

Стоимость

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

зарплату сотрудникам, которые работают с системой (пользователи, обучающий персонал, системные администраторы, внешние консультанты);

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

материальные затраты на покупку или аренду оборудования.

Составляющие стратегии перехода определяют стоимость.

Стиль перехода

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

Область распространения

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

Составные части

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

Сроки

Финальный фактор, влияющий на выбор стратегии перехода — это время.

Стиль перехода

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

Область распространения

Одновременный переход занимает меньше времени в сравнении с «пилотным» стилем. Команда не тратит время на работу с пилотной группой пользователей, а работает со всеми сразу.

Составные части

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

Как принимать решение

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

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

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

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

Характеристики стратегий миграции

Прочитайте описание кейса и выберите подходящую стратегию перехода.

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

Тоже правильный ответ

Стиль перехода: прямой

Область применения: пилотная

Составные части: система целиком

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

Неправильный ответ

Стиль перехода: прямой

Область применения: одновременная

Составные части: система целиком

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

Стиль перехода: прямой

Область применения: пилотная

Составные части: модуль за модулем

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

Прочитайте описание кейса и выберите подходящую стратегию перехода.

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

Правильный ответ

Стиль перехода: параллельный

Область применения: одновременная

Составные части: модуль за модулем

Минимальный риск будет при параллельном переходе. Пользователей у ПО мало, поэтому можно переводить сразу всех библиотекарей. Так как ПО сложное, минимальные риски будут при переходе модуль за модулем.

Стиль перехода: прямой

Область применения: одновременная

Составные части: модуль за модулем

Прямой переход влечет высокие риски. Среди предложенных вариантов есть менее рискованная стратегия перехода.

Стиль перехода: прямой

Область применения: одновременная

Составные части: система целиком

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

Стратегия на случай непредвиденных обстоятельств

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

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

Для разработки плана приглашаются все заинтересованные лица. Системный аналитик может принимать участие в выработке стратегии совместно с разработчиком и DevOps-инженером.

Подготовка технологий

Техническая подготовка к миграции включает в себя 3 основных шага:

установка оборудования;

развертывание ПО;

миграция данных.

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

1. Установка оборудования

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

Набор и параметры оборудования определяют системные администраторы совместно с архитекторами, выделенными сотрудниками сопровождения и поддержки. Для определения необходимого оборудования используются нефункциональные требования, которые готовит системный аналитик при составлении спецификации требований. Если компания небольшая (например, до 50-100 человек), то к выбору может подключиться CTO/CIO организации.

2. Разработка, развёртка и установка ПО

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

3. Миграция данных

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

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

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

Правильный ответ

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

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

Участвует в настройке CI/CD (непрерывная интеграция и доставка ПО)

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

Выбор, установка и настройка дополнительных систем (например, систем логирования, мониторинга, подсчета метрик)

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

Правильный ответ

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

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

Подведём итоги

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

План миграции включает в себя:

подготовку бизнеса;

подготовку технологий;

подготовку кадров.

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

Выбор стиля перехода (прямой или параллельный).

Определение области распространения (пилотная или одновременная).

Определение составных частей (модуль за модулем или система целиком).

Выбор стиля миграции зависит от рисков, стоимости и сроков.

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

Подготовка технологий включает в себя:

установку оборудования;

развёртывание ПО;

миграцию данных.

В следующем уроке поговорим о подготовке кадров.

К следующему уроку

Курсы

Вводный модуль

Понимание профессии системного аналитика

Разработка требований

Проект 1. Спецификация требований ко второму релизу Chatty

SQL для аналитиков

Моделирование данных

Проект 2. Моделирование данных и работа с базой данных интернет-магазина «Накарабине»

Моделирование процессов

Пользовательские интерфейсы

Agile-практики

Проект 3. Бэклог приложения для сети клиник «Вита»

Трудоустройство

Архитектура системы

Программные интерфейсы

Проект 4

Реализация системы

Поддержка, обслуживание и оценка результатов

Дипломный проект

Дополнительные материалы

x

Draggable item. Ensure your screen reader is not in browse mode and then press space bar to lift.