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

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

Стратегии

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

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

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

Существуют разные драйверы и стратегии модернизации ПО:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Статьи, статьи и книги

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

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

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

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

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

использованная литература

  1. ^ Гарднер, Д: «Модернизация приложений не просто мелочь, а продлевает жизненный цикл унаследованных активов кода», ZDNet, 24 октября 2006 г.
  2. ^ Ограниченная рациональность Саймона. Истоки и использование в экономической теории
  3. ^ Гарднер, Д: «Модернизация приложений не просто мелочь, а продлевает жизненный цикл унаследованных активов кода», ZDNet, 24 октября 2006 г.
  4. ^ Стефан ван дер Зейден; Томас Клинект. «Создание бизнес-кейса по модернизации мультиплатформенных приложений». Цитировать журнал требует | журнал = (Помогите)
  5. ^ а б Menychtas, Andreas; Сантзариду, Кристина; Кусиурис, Джордж; Варваригу, Феодора; Ору-Эчеваррия, Лейре; Алонсо, Хункал; Горроноготия, Иисус; Брунельер, Гюго; Штраус, Оливер; Сенькова, Татьяна; Пелленс, Брам; Стуэр, Питер (2013), «Методология и структура ARTIST: новый подход к миграции устаревшего программного обеспечения в облако» (PDF), 2013 15-й Международный симпозиум по символьным и числовым алгоритмам для научных вычислений, 15-й Международный симпозиум по символьным и числовым алгоритмам для научных вычислений (SYNASC), IEEE, стр. 424–431, Дои:10.1109 / SYNASC.2013.62, ISBN  978-1-4799-3036-4, S2CID  8150975
  6. ^ а б Menychtas, Andreas; Константели, Клеопатра; Алонсо, Хункал; Ору-Эчеваррия, Лейре; Горроноготия, Иисус; Кусиурис, Джордж; Сантзариду, Кристина; Брунельер, Гюго; Пелленс, Брам; Стуэр, Питер; Штраус, Оливер; Сенькова, Татьяна; Варваригу, Теодора (2014), «Модернизация программного обеспечения и облачность с использованием методологии миграции и фреймворка ARTIST», Масштабируемые вычисления: практика и опыт, 15 (2), Дои:10.12694 / scpe.v15i2.980
  7. ^ Исследовательский проект ARTIST
  8. ^ Ян Уоррен; Джейн Рэнсом (2002). «Ренессанс: метод поддержки эволюции программных систем». 26-я ежегодная международная конференция по компьютерному программному обеспечению и приложениям. С. 415–420. CiteSeerX  10.1.1.137.7362. Дои:10.1109 / CMPSAC.2002.1045037. ISBN  978-0-7695-1727-8. S2CID  16563177.
  9. ^ Иззет Сахин; Фатеме Мариам Захеди (2001). «Анализ политики в отношении гарантии, обслуживания и обновления программных систем». Журнал сопровождения программного обеспечения: исследования и практика. 13 (6): 469–493. Дои:10.1002 / smr.242.
  10. ^ Юсси Коскинен; Ярмо Ахонен; Хейкки Линтинен; Хна Сивула; Теро Тилус. «Оценка бизнес-ценности модернизации программного обеспечения». Цитировать журнал требует | журнал = (Помогите)
  11. ^ Lewis, G .; Morris, E .; Smith, D .; О'Брайен, Л. (2005). "Сервис-ориентированная миграция и метод повторного использования (SMART)". 13-й международный семинар IEEE по программным технологиям и инженерной практике (STEP'05). С. 222–229. Дои:10.1109 / step.2005.24. HDL:10344/2208. ISBN  0-7695-2639-X. S2CID  18912663.
  12. ^ Льюис, Грейс А .; Плакош, Даниил; Сикорд, Роберт С. (2003). Модернизация устаревших систем: программные технологии, инженерные процессы и бизнес-практика. Эддисон-Уэсли Профессионал. п. 27–37. ISBN  0321118847.
  13. ^ Андреа Де Люсия; Эухенио Помпелла и Сильвио Стефануччи (июль 2002 г.). «Оценка усилий по корректирующему обслуживанию программного обеспечения» (PDF). Материалы 14-й международной конференции по программной инженерии и инженерии знаний - SEKE '02. SEKE '02 Искья, Италия. п. 409. Дои:10.1145/568760.568831. ISBN  978-1581135565. S2CID  10627249.CS1 maint: location (ссылка на сайт)
  14. ^ De Lucia, A .; Fasolino, A.R .; Помпель, Э. (2001). «Структура принятия решений для управления устаревшей системой». Труды Международной конференции по сопровождению программного обеспечения IEEE. ICSM 2001. С. 642–651. Дои: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. ^ К. Геззи (2018). «Поддержка надежной эволюции». В Gruhn, Volker; Стример, Рюдигер (ред.). Суть программной инженерии. С. 32–33. Дои:10.1007/978-3-319-73897-0. ISBN  978-3-319-73897-0. S2CID  49187426.
  18. ^ "Модернизация мэйнфреймов в двух словах". Центр модернизации. Получено 2017-08-23.
  19. ^ Серии, А. С. (ISO 9001: 2008). Традиционная модернизация - преобразование в гибкое предприятие. Технический документ по устаревшей модернизации
  20. ^ SearchCIO.com
  21. ^ С.К. Мишра; Д.С. Кушваха; А.К. Мисра (июль – август 2009 г.). «Создание повторно используемого программного компонента из объектно-ориентированной устаревшей системы посредством обратного проектирования». Журнал объектных технологий. 8 (5): 133–152. Дои:10.5381 / jot.2009.8.5.a3.
  22. ^ Мольтке, Х. против (среда, 22 января 2003 г., 21:55). Модернизация, управляемая рисками. Джавахарлал Неру, Речь в парламенте Нью-Дели,: Seacord.book.