Из Википедии, свободной энциклопедии
Перейти к навигации Перейти к поиску

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

Стратегии [ править ]

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

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

Стратегии модернизации [ править ]

Существуют разные драйверы и стратегии модернизации программного обеспечения:

  • Модернизация, управляемая архитектурой (ADM) - это инициатива по стандартизации представлений о существующих системах с целью обеспечения общих действий по модернизации, таких как анализ и понимание кода, а также преобразование программного обеспечения.
  • Подход, ориентированный на бизнес: стратегия модернизации связана с добавленной стоимостью бизнеса в результате модернизации. Это подразумевает определение пересечения критичности приложения для бизнеса с его техническим качеством. [1] Этот подход, продвигаемый Gartner, ставит анализ портфеля приложений (APA) в качестве предварительного условия для принятия решений о модернизации портфеля приложений для измерения состояния, рисков, сложности и стоимости программного обеспечения, обеспечивая понимание сильных и слабых сторон приложений. [3]
  • Модельно-ориентированная инженерия (MDE) исследуется как подход к обратному проектированию, а затем к прямому проектированию программного кода. [4] [5] [6]
  • Renaissance [7] Метод итеративной оценки унаследованных систем с технической, деловой и организационной точек зрения.
  • WMU (Warrants, Maintenance, Upgrade) - это модель для выбора подходящих стратегий обслуживания, основанная на желаемом уровне удовлетворенности клиентов и их влиянии на него. [8] [9]

Управление рисками модернизации [ править ]

Модернизация программного обеспечения - это рискованный, сложный, длительный и высокоинтеллектуальный процесс, в котором участвует множество заинтересованных сторон. Задачи модернизации программного обеспечения поддерживаются различными инструментами, относящимися к архитектуре, управляемой моделями, от Группы управления объектами и такими процессами, как ISO / IEC 14764: 2006 или Сервис-ориентированная миграция и повторное использование (SMART). [10] Модернизация программного обеспечения подразумевает выполнение различных ручных и автоматизированных задач специализированными специалистами. Инструменты поддерживают задачи участников проекта и помогают организовать совместную работу и упорядочить работу.

Общий подход к управлению модернизацией программного обеспечения [11], явно учитывающий риски (как технологические, так и бизнес-цели), состоит из:

  • Анализ существующего портфеля: измерение технического качества и стоимости бизнеса. Сопоставление технического качества с бизнес-целями для определения правильной стратегии: замена, отказ, низкий приоритет, хороший кандидат.
  • Определите заинтересованные стороны: всех лиц, участвующих в модернизации программного обеспечения: разработчиков, тестировщиков, заказчиков, конечных пользователей, архитекторов и т. Д.
  • Поймите требования: требования разделены на 4 категории: пользовательские, системные, ограничения и нефункциональные.
  • Создайте бизнес-модель: бизнес-модель поддерживает процесс принятия решений при рассмотрении различных подходов, когда это необходимо лицам, принимающим решения.
  • Понимание системы, которую необходимо модернизировать: это важный шаг, поскольку документация по программному обеспечению редко обновляется, а проекты выполняются многочисленными командами, как внутренними, так и внешними, и, как правило, на долгое время вне поля зрения. Извлечение содержимого приложения и его архитектура помогают разобраться в системе.
  • Понимать и оценивать целевую технологию: это позволяет сравнивать и сравнивать технологии и возможности с требованиями и существующей системой.
  • Определите стратегию модернизации: [12] стратегия определяет процесс трансформации. Эта стратегия должна учитывать изменения, происходящие в процессе модернизации (изменения технологий, дополнительные знания, эволюция требований).
  • Согласование стратегии с потребностями заинтересованных сторон: предполагаемые заинтересованные стороны могут иметь разные мнения о том, что важно и как лучше всего действовать. Важно достичь консенсуса между заинтересованными сторонами.
  • Оценка ресурсов: когда определены предыдущие шаги, можно оценить затраты. Это позволяет руководству определить, осуществима ли стратегия модернизации с учетом имеющихся ресурсов и ограничений.

Затраты на модернизацию [ править ]

  • Softcalc (Sneed, 1995a) - это модель и инструмент для оценки стоимости входящих запросов на обслуживание, разработанная на основе COCOMO и FPA.
  • EMEE (Early Maintenance Effort Assessment) [13] [14] - это новый подход к быстрой оценке усилий по обслуживанию до начала фактического обслуживания.
  • RENAISSANCE - это метод поддержки эволюции системы, сначала восстанавливая стабильную основу с помощью реинжиниринга, а затем непрерывно улучшая систему потоком постепенных изменений. Подход успешно интегрируется с различными процессами управления проектами [15]

Проблемы модернизации устаревшей версии [ править ]

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

  • Отсутствие прозрачности для больших портфелей приложений. Крупные ИТ-организации имеют сотни, если не тысячи, программных систем. Технологии и функциональные знания по своей природе распределены, разбавлены и непрозрачны. Отсутствие центральной точки видимости для высшего руководства и архитекторов предприятия не является главной проблемой - сложно принимать решения о модернизации программных систем, не имея необходимых количественных и качественных данных об этих системах в масштабах всего предприятия.
  • Управление организационными изменениями. Пользователи должны быть переобучены и оснащены для эффективного использования и понимания новых приложений и платформ.
  • Сосуществование унаследованных и новых систем. Организации с большим объемом унаследованных систем не могут мигрировать сразу. Необходимо принять поэтапный подход к модернизации. Однако это создает свой собственный набор проблем, таких как обеспечение полного охвата бизнеса с хорошо понятными и реализованными дублирующими функциями, дублирование данных; одноразовые системы для объединения устаревших и новых систем, необходимых на промежуточных этапах. [16]
  • Плохое управление качеством структуры (см. Качество программного обеспечения ), в результате чего модернизированное приложение несет больше проблем с безопасностью, надежностью и ремонтопригодностью, чем исходная система.
  • Значительные затраты на модернизацию и продолжительность - Модернизация сложной устаревшей критически важной системы может потребовать больших инвестиций, а продолжительность полностью работающей модернизированной системы может исчисляться годами, не говоря уже о непредвиденных неопределенностях в этом процессе.
  • Обязательства заинтересованных сторон - основные заинтересованные стороны организации должны быть убеждены в инвестировании в модернизацию, поскольку выгоды и немедленная окупаемость инвестиций могут быть незаметны по сравнению с вложенными затратами на модернизацию.
  • Состав программного обеспечения. В наши дни разработчики крайне редко создают 100% оригинальный код для чего-либо, построенного после 2010 года. [17] Они часто используют сторонние и открытые исходные коды и программные компоненты для повышения эффективности, скорости и возможности повторного использования. Это создает два риска: 1.) уязвимости в стороннем коде и 2.) риск лицензирования с открытым исходным кодом.

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

Варианты модернизации [ править ]

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

  • Оценка приложений: определение базового уровня существующего портфеля приложений с использованием аналитики программного обеспечения для понимания работоспособности, качества, состава, сложности программного обеспечения и готовности к облаку для начала сегментации и определения приоритетов приложений для различных вариантов модернизации.
  • Обнаружение приложений : компоненты приложений сильно переплетены, что подразумевает необходимость понимания сложности и разрешения взаимозависимостей компонентов программного обеспечения.
  • Миграция: миграция языков (3GL или 4GL), баз данных (устаревшие в РСУБД и одной РСУБД в другую), платформы (из одной ОС в другую), часто с использованием автоматических анализаторов и конвертеров для повышения эффективности. Это быстрый и экономичный способ преобразования устаревших систем.
  • Миграция в облако: миграция устаревших приложений на облачные платформы, часто с использованием такой методологии, как методология Gartner 5 Rs для сегментации приложений и определения их приоритетов по различным моделям (Rehost, Refactor, Revise, Rebuild, Replace).
  • Реинжиниринг: метод перестройки унаследованных приложений на новую технологию или платформу с такой же или расширенной функциональностью - обычно путем принятия сервис-ориентированной архитектуры (SOA). Это наиболее эффективный и гибкий способ преобразования унаследованных приложений. [4] Для этого требуется программный интеллект на уровне приложений с устаревшими системами, которые малоизвестны или документированы.
  • Повторный хостинг: запуск устаревших приложений без серьезных изменений на другой платформе. Бизнес-логика сохраняется по мере того, как приложение и данные переносятся в открытую среду. Этот вариант требует замены только промежуточного программного обеспечения, оборудования, операционной системы и базы данных. [18] Это часто используется в качестве промежуточного шага для отказа от устаревшего и дорогостоящего оборудования. Наиболее распространенные примеры включают мэйнфреймы приложения которые rehosted на UNIX или Wintel платформы.
  • Внедрение пакета: замена устаревших приложений, полностью или частично, на готовое программное обеспечение (COTS), такое как ERP, CRM, SCM, программное обеспечение для выставления счетов и т. Д. [19]

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

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

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

Миграция программного обеспечения [ править ]

Миграция программного обеспечения - это процесс перехода от использования одной операционной среды к другой операционной среде, которая в большинстве случаев считается лучшей. Например, переход с Windows NT Server на Windows 2000 Server обычно считается миграцией, поскольку он включает в себя обеспечение использования новых функций, отсутствие необходимости изменения старых настроек и принятие мер для обеспечения того, чтобы текущие приложения продолжали работать в новых. среда. Миграция также может означать переход с Windows NT на операционную систему на основе UNIX (или наоборот). Миграция может включать переход на новое оборудование, новое программное обеспечение или и то, и другое. Миграцияможет быть мелкомасштабным, например, при переносе отдельной системы, или крупномасштабным, включающим множество систем, новых приложений или измененную сеть. [20]

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

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

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

Статьи, статьи и книги [ править ]

Создание программного обеспечения многократного использования [ править ]

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

Модернизация с управлением рисками [ править ]

В целом, для модернизации унаследованных систем представляют интерес три класса технологий информационных систем: Технологии, используемые для построения унаследованных систем, включая языки и системы баз данных. Современные технологии, которые часто представляют собой нирвану для тех, кто погряз в устаревших технологиях, и которые обещают (часто нереализованные) мощные, эффективные, легко обслуживаемые корпоративные информационные системы. Технологии, предлагаемые поставщиками устаревших систем - эти технологии предоставляют возможность обновления для тех, кто слишком робок или мудр, чтобы сразу же броситься в новейшую волну ИТ-предложений. Производители устаревших систем предлагают эти технологии по одной простой причине: чтобы обеспечить возможность обновления для модернизации системы, которая не требует покидания комфорта «матки мэйнфреймов».«Хотя эти технологии могут обеспечить более плавный путь к современной системе, они часто приводят к приемлемому решению, которое не соответствует идеалу.[22]

См. Также [ править ]

  • Миграция системы
  • Перенос данных

Ссылки [ править ]

  1. ^ a b Гарднер, Д: «Модернизация приложений не просто мелочь, а продлевает жизненный цикл унаследованных активов кода» , ZDNet , 24 октября 2006 г.
  2. ^ Ограниченная рациональность Саймона. Истоки и использование в экономической теории
  3. ^ Stefan Van Der Zijden; Томас Клинект. «Построение бизнес-кейса модернизации мультиплатформенных приложений» . Цитировать журнал требует |journal=( помощь )
  4. ^ a b Menychtas, Андреас; Сантзариду, Кристина; Кусиурис, Джордж; Варваригу, Теодора; Ору-Эчеваррия, Лейре; Алонсо, Хункал; Горроноготия, Иисус; Брунельер, Гюго; Штраус, Оливер; Сенькова, Татьяна; Пелленс, Брам; Стуер, Питер (2013), «Методология и структура ARTIST: новый подход к миграции устаревшего программного обеспечения в облаке» (PDF) , 2013 15-й Международный симпозиум по символьным и числовым алгоритмам для научных вычислений , 15-й Международный симпозиум по символическим и числовым Алгоритмы для научных вычислений (SYNASC), IEEE, С. 424-431,. DOI : 10,1109 / SYNASC.2013.62 , ISBN  978-1-4799-3036-4, S2CID  8150975
  5. ^ a b Menychtas, Андреас; Константели, Клеопатра; Алонсо, Хункал; Ору-Эчеваррия, Лейре; Горроноготия, Иисус; Кусиурис, Джордж; Сантзариду, Кристина; Брунельер, Гюго; Пелленс, Брам; Стуэр, Питер; Штраус, Оливер; Сенькова, Татьяна; Варваригу, Теодора (2014), «Модернизация программного обеспечения и облачность с использованием методологии и структуры миграции ARTIST», Масштабируемые вычисления: практика и опыт , 15 (2), doi : 10.12694 / scpe.v15i2.980
  6. ^ Исследовательский проект ARTIST
  7. ^ Ян Уоррен; Джейн Рэнсом (2002). «Возрождение: метод поддержки эволюции программных систем». 26-я ежегодная международная конференция по компьютерному программному обеспечению и приложениям . С. 415–420. CiteSeerX 10.1.1.137.7362 . DOI : 10.1109 / CMPSAC.2002.1045037 . ISBN  978-0-7695-1727-8. S2CID  16563177 .
  8. ^ Иззет Сахин; Фатеме «Мариам» Захеди (2001). «Анализ политики в отношении гарантии, обслуживания и обновления программных систем». Журнал сопровождения программного обеспечения: исследования и практика . 13 (6): 469–493. DOI : 10.1002 / smr.242 .
  9. ↑ Юсси Коскинен; Ярмо Ахонен; Хейкки Линтинен; Хна Сивула; Теро Тилус. «Оценка бизнес-ценности модернизации программного обеспечения» . Цитировать журнал требует |journal=( помощь )
  10. ^ Льюис, G .; Morris, E .; Smith, D .; О'Брайен, Л. (2005). «Сервис-ориентированная миграция и метод повторного использования (SMART)». 13-й международный семинар IEEE по программным технологиям и инженерной практике (STEP'05) . С. 222–229. DOI : 10,1109 / step.2005.24 . hdl : 10344/2208 . ISBN 0-7695-2639-X. S2CID  18912663 .
  11. ^ Льюис, Грейс А .; Плакош, Даниил; Сикорд, Роберт С. (2003). Модернизация устаревших систем: программные технологии, инженерные процессы и бизнес-практика . Эддисон-Уэсли Профессионал. С. 27–37. ISBN 0321118847.
  12. ^ Mobilize.Net. «Быстрый путь к модернизации программного обеспечения | Mobilize.Net» . www.mobilize.net . Проверено 19 марта 2021 .
  13. ↑ Андреа Де Люсия; Эухенио Помпелла и Сильвио Стефануччи (июль 2002 г.). «Оценка усилий по корректирующему обслуживанию программного обеспечения» (PDF) . Материалы 14-й международной конференции по программной инженерии и инженерии знаний - SEKE '02 . SEKE '02 Искья, Италия. п. 409. DOI : 10,1145 / 568760,568831 . ISBN  978-1581135565. S2CID  10627249 .CS1 maint: location ( ссылка )
  14. ^ Де Люсия, А .; Фасолино, АР; Помпель, Э. (2001). «Структура принятия решений для управления устаревшей системой». Труды Международной конференции по сопровождению программного обеспечения IEEE. ICSM 2001 . С. 642–651. DOI : 10.1109 / ICSM.2001.972781 . ISBN 0-7695-1189-9. S2CID  32184332 .
  15. ^ Коскинен, Юсси; Линтинен, Хейкки; Сивула, хна; Тилус, Теро. «Оценка методов оценки модернизации программного обеспечения с использованием NIMSAD Meta Framework» (PDF) . Публикации Исследовательского института информационных технологий . CiteSeerX 10.1.1.106.2633 .  
  16. ^ Сантош Г. Рамакришна; ВВ (май 2007 г.). «Модернизация логистического наследия» (PDF) . Infosys Technologies Limited.
  17. ^ С. Ghezzi (2018). «Поддержка надежной эволюции». У Груна, Фолькера; Стример, Рюдигер (ред.). Сущность программной инженерии . С. 32–33. DOI : 10.1007 / 978-3-319-73897-0 . ISBN 978-3-319-73897-0. S2CID  49187426 .
  18. ^ "Модернизация мэйнфреймов в двух словах" . Центр модернизации . Проверено 23 августа 2017 .
  19. ^ Серия, AS (ISO 9001: 2008). Унаследованная модернизация - преобразование в гибкое предприятие. Технический документ по устаревшей модернизации
  20. ^ SearchCIO.com
  21. ^ С.К. Мишра; Д.С. Кушваха; А.К. Мисра (июль – август 2009 г.). «Создание повторно используемого программного компонента из объектно-ориентированной устаревшей системы посредством обратного проектирования» . Журнал объектных технологий . 8 (5): 133–152. DOI : 10.5381 / jot.2009.8.5.a3 .
  22. ↑ Мольтке, Х. В. (среда, 22 января 2003 г., 21:55). Модернизация, управляемая рисками. Джавахарлал Неру, Речь в парламенте Нью-Дели: Seacord.book.