Модернизация программного обеспечения

Обновление или перенос устаревшего программного обеспечения на современные практики и платформы

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

В основе и первом шаге инициатив по модернизации программного обеспечения, стратегии, управления рисками, оценки затрат и ее реализации лежит знание модернизируемой системы. Знание того, для чего предназначены все функции, и знание того, как они были разработаны. ^[2] Поскольку эксперты по предметной области (SME), которые работали в начале и во время всех эволюций приложения, больше не доступны или имеют частичные знания, а также из-за отсутствия надлежащей и актуальной документации, инициативы по модернизации начинаются с оценки и обнаружения приложения с использованием Software Intelligence . ^[3]

Стратегии

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

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

Стратегии модернизации

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

• Архитектурно-ориентированная модернизация (ADM) — это инициатива по стандартизации представлений о существующих системах с целью обеспечения общих мероприятий по модернизации, таких как анализ и понимание кода, а также преобразование программного обеспечения.
• Подход, ориентированный на бизнес: стратегия модернизации связана с добавленной модернизацией ценностью для бизнеса. Она подразумевает определение пересечения критичности для бизнеса приложений с их техническим качеством. ^[1] Этот подход, продвигаемый Gartner, ставит анализ портфеля приложений (APA) в качестве предварительного условия для принятия решений о модернизации портфеля приложений для измерения работоспособности программного обеспечения, рисков, сложности и стоимости, предоставляя представление о сильных и слабых сторонах приложения. ^[5]
• Model Driven Engineering (MDE) изучается как подход к обратному проектированию, а затем прямому проектированию программного кода. ^{[6] [7] [8]}
• Ренессанс ^[9] Метод итеративной оценки устаревших систем с технической, деловой и организационной точек зрения.
• WMU (Warrants, Maintenance, Upgrade) — это модель выбора подходящих стратегий обслуживания на основе желаемого уровня удовлетворенности клиентов и их влияния на него. ^{[10] [11]}

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

Модернизация программного обеспечения ^[12] — это рискованный, сложный, длительный и высокоинтеллектуальный процесс, в котором задействовано множество заинтересованных сторон. Задачи модернизации программного обеспечения поддерживаются различными инструментами, связанными с архитектурой на основе моделей от Object Management Group и такими процессами, как ISO/IEC 14764:2006 или Service-Oriented Migration and Reuse Technique (SMART). ^[13] Модернизация программного обеспечения подразумевает различные ручные и автоматизированные задачи, выполняемые специализированными работниками знаний. Инструменты поддерживают задачи участников проекта и помогают организовать совместную работу и последовательность работы.

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

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

Расходы на модернизацию

• Softcalc (Sneed, 1995a) — это модель и инструмент для оценки стоимости входящих заявок на техническое обслуживание, разработанные на основе COCOMO и FPA.
• EMEE (ранняя оценка затрат на техническое обслуживание) ^{[16] [17]} — это новый подход к быстрой оценке затрат на техническое обслуживание до начала фактического обслуживания.
• RENAISSANCE — это метод поддержки эволюции системы, сначала восстанавливая стабильную основу с помощью реинжиниринга, а затем непрерывно улучшая систему потоком постепенных изменений. Подход успешно интегрируется с различными процессами управления проектами ^[18]

Проблемы модернизации наследия

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

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

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

Варианты модернизации

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

• Оценка приложений: создание базовой модели существующего портфеля приложений с использованием аналитики программного обеспечения для оценки работоспособности, качества, состава, сложности и готовности к работе в облаке программного обеспечения с целью начала сегментации и расстановки приоритетов приложений для различных вариантов модернизации.
• Обнаружение приложений : компоненты приложений тесно переплетены, что требует понимания сложности и разрешения взаимозависимостей компонентов программного обеспечения.
• Миграция: Миграция языков (3GL или 4GL), баз данных (из устаревших в СУБД и из одной СУБД в другую), платформы (из одной ОС в другую ОС), часто с использованием автоматизированных конвертеров или систем преобразования программ для высокой эффективности. Это быстрый и экономически эффективный способ преобразования устаревших систем.
• Миграция в облако: миграция устаревших приложений на облачные платформы, часто с использованием такой методологии, как методология Gartner 5 Rs, для сегментации и приоритизации приложений в различных моделях (повторный хостинг, рефакторинг, пересмотр, перестройка, замена).
• Реинжиниринг: Метод перестройки устаревших приложений на новой технологии или платформе с той же или улучшенной функциональностью — обычно путем принятия сервисно-ориентированной архитектуры (SOA). Это наиболее эффективный и гибкий способ преобразования устаревших приложений. ^{[6] Для этого требуется} программный интеллект на уровне приложений с устаревшими системами, которые недостаточно известны или документированы.
• Повторный хостинг: запуск устаревших приложений без существенных изменений на другой платформе. Бизнес-логика сохраняется, поскольку приложение и данные переносятся в открытую среду. Этот вариант требует только замены промежуточного программного обеспечения, оборудования, операционной системы и базы данных. ^[21] Это часто используется в качестве промежуточного шага для устранения устаревшего и дорогостоящего оборудования. Наиболее распространенными примерами являются приложения мэйнфреймов , повторно размещаемые на платформе UNIX или Wintel .
• Пакетная реализация: замена устаревших приложений, полностью или частично, готовым программным обеспечением (COTS), таким как ERP, CRM, SCM, программное обеспечение для выставления счетов и т. д. ^[22]

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

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

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

Миграция программного обеспечения

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

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

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

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

Статьи, доклады и книги

Создание многоразового программного обеспечения

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

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

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

Смотрите также

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

Ссылки

1. Gardner, D: «Не просто косметический ремонт, модернизация приложений продлевает жизненный цикл устаревших кодовых активов», ZDNet , 24 октября 2006 г.
2. Вольфарт, Даниэле; Ассунсао, Уэсли; да Силва, Ивоней; Домингуш, Диого; Шмейнг, Эдерсон; Вильяка, Гильерме; Паза, Диого (июнь 2021 г.). «Модернизация устаревших систем с помощью микросервисов: дорожная карта». Оценка и оценка в разработке программного обеспечения . стр. 149–159. дои : 10.1145/3463274.3463334. ISBN 9781450390538. S2CID  235474042.
3. Bartoszuk, Cezary; Dąbrowski, Robert; Stencel, Krzysztof; Timoszuk, Grzegorz (июнь 2013 г.). «О быстром понимании и оценке программного обеспечения». Труды 14-й Международной конференции по компьютерным системам и технологиям . стр. 161–168. doi :10.1145/2516775.2516806. ISBN 9781450320214. S2CID  17034416.
4. Ограниченная рациональность Саймона. Происхождение и использование в экономической теории
5. Стефан Ван дер Зийден; Томас Клинкект. «Построение бизнес-кейса по модернизации мультиплатформенных приложений». {{cite journal}}: Цитировать журнал требует |journal=( помощь )
6. Менихтас, Андреас; Санцариду, Кристина; Кузиурис, Джордж; Варваригу, Теодора; Оруэ-Эчеваррия, Лейре; Алонсо, Хункал; Горроногоития, Иисус; Брюнельер, Гюго; Штраус, Оливер; Сенькова Татьяна; Пелленс, Брэм; Stuer, Peter (2013), «Методология и структура ARTIST: новый подход к миграции устаревшего программного обеспечения в облако» (PDF) , 2013 15-й Международный симпозиум по символьным и численным алгоритмам для научных вычислений (PDF) , 15-й Международный симпозиум по Символьные и числовые алгоритмы для научных вычислений (SYNASC), IEEE, стр. 424–431, doi :10.1109/SYNASC.2013.62, ISBN 978-1-4799-3036-4, S2CID  8150975
7. Menychtas, Andreas; Konstanteli, Kleopatra; Alonso, Juncal; Orue-Echevarria, Leire; Gorronogoitia, Jesus; Kousiouris, George; Santzaridou, Christina; Bruneliere, Hugo; Pellens, Bram; Stuer, Peter; Strauss, Oliver; Senkova, Tatiana; Varvarigou, Theodora (2014), "Модернизация программного обеспечения и облачная обработка с использованием методологии и фреймворка миграции ARTIST", Scalable Computing: Practice and Experience , 15 (2), CiteSeerX 10.1.1.675.6225 , doi : 10.12694/scpe.v15i2.980 
8. Исследовательский проект ARTIST
9. Ян Уоррен; Джейн Рэнсом (2002). «Возрождение: метод поддержки эволюции программных систем». 26-я ежегодная международная конференция по компьютерному программному обеспечению и приложениям . стр. 415–420. CiteSeerX 10.1.1.137.7362 . doi :10.1109/CMPSAC.2002.1045037. ISBN  978-0-7695-1727-8. S2CID  16563177.
10. Иззет Сахин; Фатемех «Мариам» Захеди (2001). «Анализ политики гарантии, обслуживания и обновления программных систем». Журнал обслуживания программного обеспечения: исследования и практика . 13 (6): 469–493. doi :10.1002/smr.242.
11. Юсси Коскинен; Ярмо Ахонен; Хейкки Линтинен; хна сивула; Теро Тилус. «Оценка бизнес-ценности модернизации программного обеспечения». {{cite journal}}: Цитировать журнал требует |journal=( помощь )
12. «Миграция на VB6. Зачем идти на компромисс с безопасностью данных, если можно перейти на более современные платформы?».
13. Льюис, Г.; Моррис, Э.; Смит, Д.; О'Брайен, Л. (2005). «Сервисно-ориентированная миграция и метод повторного использования (SMART)». 13-й Международный семинар IEEE по программным технологиям и инженерной практике (STEP'05) . стр. 222–229. doi :10.1109/step.2005.24. hdl :10344/2208. ISBN 0-7695-2639-X. S2CID  18912663.
14. Льюис, Грейс А.; Плакош, Дэниел; Сикорд, Роберт К. (2003). Модернизация устаревших систем: программные технологии, инженерные процессы и деловая практика. Addison-Wesley Professional. стр. 27–37. ISBN 0321118847.
15. Mobilize.Net. «Быстрый путь к модернизации программного обеспечения | Mobilize.Net». www.mobilize.net . Получено 19.03.2021 .
16. Андреа Де Лючия; Эудженио Помпелла и Сильвио Стефануччи (июль 2002 г.). "Оценка усилий для корректирующего сопровождения программного обеспечения" (PDF) . Труды 14-й международной конференции по программной инженерии и инженерии знаний - SEKE '02 . SEKE '02 Искья, Италия. стр. 409. doi :10.1145/568760.568831. ISBN 978-1581135565. S2CID  10627249.{{cite book}}: CS1 maint: location (link) CS1 maint: location missing publisher (link)
17. Де Люсия, А.; Фасолино, А. Р.; Помпель, Э. (2001). «Решающая структура для управления устаревшими системами». Труды Международной конференции IEEE по обслуживанию программного обеспечения. ICSM 2001. С. 642–651. doi :10.1109/ICSM.2001.972781. ISBN 0-7695-1189-9. S2CID  32184332.
18. Коскинен, Юсси; Линтинен, Хейкки; Сивула, Хна; Тилус, Теро. «Оценка методов оценки модернизации программного обеспечения с использованием метафреймворка NIMSAD». Публикации Научно-исследовательского института информационных технологий . CiteSeerX 10.1.1.106.2633 . 
19. Сантош Г. Рамакришна; VV (май 2007 г.). «Модернизация логистического наследия» (PDF) . Infosys Technologies Limited.
20. C. Ghezzi (2018). «Поддержка надежной эволюции». В Gruhn, Volker; Striemer, Rüdiger (ред.). Сущность программной инженерии. стр. 32–33. doi :10.1007/978-3-319-73897-0. ISBN 978-3-319-73897-0. S2CID  49187426.
21. "Модернизация мэйнфреймов в двух словах". Modernization Hub . Получено 23-08-2017 .
22. Серия AS (ISO 9001:2008). Модернизация устаревших систем – преобразование в гибкое предприятие. Белая книга по модернизации устаревших систем
23. ПоискCIO.com
24. SK Mishra; DS Kushwaha; AK Misra (июль–август 2009 г.). «Создание повторно используемого программного компонента из устаревшей объектно-ориентированной системы с помощью обратного проектирования». Журнал объектных технологий . 8 (5): 133–152. doi : 10.5381/jot.2009.8.5.a3 .
25. Мольтке, Х. в. (среда, 22 января 2003 г., 9:55 вечера). Модернизация с управлением рисками. Джавахарлал Неру, Речь в парламенте Нью-Дели,: Seacord.book.