Компания EMT. Рекомендации по миграции на СПО. Проект migration.osdn.org.ua

В. Машков – Киев, Украина

LVEE 2005

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

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

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

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

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

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

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

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

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

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

В качестве примера рассмотрим замену использования макросов MS Office, которые используются для вычислений. Цель – замена офисного пакета свободным аналогом. В результате мы получаем макросы, которые реализуют требуемую функциональность. В процессе замены необходимо проверить правильность работы макросов и выяснить как пользователи оценивают работу офисных пакетов “до” и “после”.

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

Составьте ПОДРОБНЫЙ план, в котором учитываются все детали, начиная от необходимости создания резервных копий существующих данных до развёртывания системы и заканчивая сроками обучения пользователей.
Уделите особое внимание переносу данных из унаследованной системы в новую.
На этапе обучения пользователей уделите особое внимание тем, кто является приверженцем старой системы.

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

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

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

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