Критерии оценки трудозатрат для перехода на новую систему

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

• Возможность разбиения унаследованной системы на части-модули

Чем меньше и проще система, тем легче ее полностью заменить на новую. А что делать с большими системами? И где проходит граница между малой и большой ИС?

Опишем основные признаки, указывающие на то, что перед нами действительно большая система [6]:

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

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

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

• Уровень языка программирования, на котором была написана перестраиваемая система

Здесь имеется в виду, насколько язык программирования приближен к машиным кодам (командам для процессора) компьютера.
Выстраивается иерархия вида:

Самый нижний уровень - собственно машиные коды
Средний уровень - Ассемблер
Высокий уровень -

• 3GL языки (С, C++, COBOL, Ada, Pascal)
• 4GL языки (Microsoft VisualBasic, PowerBuilder, Inprise Delphi Object Pascal, Oracle Developer PL/SQL)

Самый верхний уровень (моделирования, анализа, проектирования) - OMG UML

Производить реенжиниринг даже небольшой ИС на основе машинных кодов даже с использованием инструментария - черезвычайно сложная задача. На среднем уровне обычно используется дизассемблер, но и здесь для программиста остается море работы. Для небольших программ это вполне приемлемый способ восстановления алгоритма их работы и вероятность ошибок слишком высокая. Для языков высокого уровня имеется множестов инструментов по переносу систем, на них написанных, на другие более современные. Например, есть такой замечательный продукт, как RescueWare, который позволяет делать реверс-инжениринг со старого COBOL на новый либо на С/С++/Java. Тем не менее сами такие инструменты могут стоить от нескольких сотен до нескольких милионов долларов, и сам процесс также не назовешь дешевым: по порядку это обычно не меньшие цифры. Среднего размера организации обычно довольствуются ручной переделкой кода их программистами (либо консультантами со стороны, но это опять же дорого). В этом случае проще держать при себе создателей системы с использованием различных стимулов (высокий оклад, отличная пенсия, льготы и др.).
Для 4GL языков (4-го поколения, языков, встроенных в интегрированные интерактивные среды разработки ПО) на сегодня дела обстоят довольно неплохо. Для некоторых сочетаний созданы утилиты регенерации с одного языка на другой. Также в CASE (инструментах проектирования систем) 2-го поколения (например, в Oracle Designer 2000 Release 2) появились утилиты для закачки в их репозитарии алгортимов из кодов на 4GL языках (старый знакомый реверс-инжениринг). Однако, надо признать, что диапазон языков по своему охвату оставляет желать лучшего. Но и здесь не все потеряно: разрабатываются стандарты по переносу проектной информации между различными CASE, создан стандарт универсального хранилища проектов в виде объектной базы данных. Мы постепенно пришли к высшему на данный момент уровню - уровню модели ИС. Имея описание системы на уровне ее модели (например, описанной на UML (Unified Modeling Language) - Унифицированном языке моделирования), можно легко произвести с помощью соответствующей утилиты (ре-)генерацию кода на нужном языке (и 3-го, и 4-го поколений). При этом система легко интегрируется с другими системами, если имеется их описание на этом или аналогичных ему языках моделирования.

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

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

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

• Наличие документации по унаследованной системе
  Исчерпывающая документация, особенно грамотно и толково составленная, может очень сильно помочь разработчикам понять функции, выполняемые устаревшей системой и вследствие этого быстрее и качественнее перейти к обновленному ее варианту даже при отсутствии исходного кода.
  Напротив, плохая документация или ее полное отсутствие является одним из признаков нежизнеспособности системы [23]. Такие системы еще называют " вылетающие в трубу" (stovepipe systems).

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

Часть II - Интеграция ИС