Устаревшая система

В вычислительной технике устаревшая система — это старый метод, технология, компьютерная система или прикладная программа , «относящаяся к предыдущей или устаревшей компьютерной системе или являющаяся ею». ^[1]но все еще используется. Часто упоминание системы как «унаследованной» означает, что она проложила путь для стандартов, которые последуют за ней. Это также может означать, что система устарела или нуждается в замене.

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

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

Примером устаревшего оборудования являются устаревшие порты , такие как порты PS/2 и VGA, а также процессоры со старыми, несовместимыми наборами команд (например, с новыми операционными системами). Примеры устаревшего программного обеспечения включают устаревшие форматы файлов , такие как .swf для Adobe Flash или .123 для Lotus 1-2-3 , а также текстовые файлы, закодированные с помощью устаревших кодировок символов , таких как EBCDIC .

Обзор [ править ]

Первое использование термина « наследие» для описания компьютерных систем, вероятно, произошло в 1960-х годах. ^[3]К 1980-м годам оно стало широко использоваться для обозначения существующих компьютерных систем, чтобы отличить их от разработки и внедрения новых систем. Legacy часто слышен во время процесса преобразования, например, при перемещении данных из устаревшей системы в новую базу данных.

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

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

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

Система работает хорошо, и владелец не видит смысла ее менять.
Затраты на перепроектирование или замену системы непомерно высоки, поскольку она большая, монолитная и/или сложная.
Переобучение на новой системе потребует больших затрат времени и денег по сравнению с ожидаемыми ощутимыми выгодами от ее замены (которые могут быть нулевыми).
Система требует почти постоянной доступности , поэтому ее нельзя вывести из эксплуатации, а стоимость разработки новой системы с аналогичным уровнем доступности высока. Примеры включают системы для управления счетами клиентов в банках , компьютерные системы бронирования , управления воздушным движением , распределения энергии ( энергетические сети ), атомные электростанции , военные оборонные объекты и такие системы, как база данных TOPS .
Принцип работы системы не совсем понятен. Такая ситуация может возникнуть, когда проектировщики системы покинули организацию, а система либо не полностью документирована, либо документация утеряна.
Пользователь ожидает, что систему можно будет легко заменить, когда в этом возникнет необходимость.
Новые системы выполняют нежелательные (особенно для индивидуальных или неинституциональных пользователей) второстепенные функции, такие как: а ) отслеживание и отчетность об активности пользователей и/или б ) автоматическое обновление, которое создает « черные » уязвимости безопасности и оставляет конечных пользователей зависимыми от товара. доверие и честность поставщика, предоставляющего обновления. Эта проблема особенно остра, когда эти второстепенные функции новой системы невозможно отключить.

связанные с вычислениями устаревшими Проблемы ,

Некоторые инженеры-программисты считают устаревшие системы потенциально проблематичными по нескольким причинам. ^[4]

Если устаревшее программное обеспечение работает только на устаревшем оборудовании , затраты на обслуживание системы могут в конечном итоге перевесить затраты на замену программного и аппаратного обеспечения, если только какая-либо форма эмуляции или обратной совместимости не позволит программному обеспечению работать на новом оборудовании. ^[5]
Эти системы может быть сложно поддерживать, улучшать и расширять из-за общего отсутствия понимания системы; сотрудники, которые были экспертами в этой области, ушли на пенсию или забыли, что они знали о ней, а сотрудники, которые пришли в эту область после того, как она стала «наследием», вообще никогда о ней не узнали. Ситуация может усугубиться отсутствием или потерей документации. Авиакомпания Comair уволила своего генерального директора в 2004 году из-за сбоя устаревшей устаревшей системы планирования экипажей, которая столкнулась с ограничениями, о которых никто в компании не знал. ^[6]
Устаревшие системы могут иметь уязвимости в старых операционных системах или приложениях из-за отсутствия доступных или применяемых исправлений безопасности. Также могут существовать производственные конфигурации, вызывающие проблемы с безопасностью. Эти проблемы могут подвергнуть устаревшую систему риску взлома со стороны злоумышленников или знающих инсайдеров. ^[7]
Интеграция с новыми системами также может быть затруднена, поскольку новое программное обеспечение может использовать совершенно другие технологии. Интеграция технологий довольно распространена в вычислительной технике, но интеграция между новыми технологиями и существенно более старыми встречается нечасто. Возможно, просто не будет достаточного спроса на разработку интеграционных технологий. Часть этого «связующего» кода иногда разрабатывается поставщиками и энтузиастами определенных устаревших технологий.
Бюджетные ограничения часто приводят к тому, что корпорации не решают проблему замены или миграции устаревшей системы. Однако компании часто не учитывают растущие затраты на поддержку (люди, программное обеспечение и аппаратное обеспечение, все упомянутое выше) и не принимают во внимание огромную потерю возможностей или непрерывности бизнеса в случае отказа устаревшей системы. Как только эти соображения будут хорошо поняты, то, основываясь на проверенной рентабельности инвестиций, новая, более безопасная и обновленная платформа стека технологий окажется не такой дорогостоящей, как альтернатива, и бюджет найден.
В связи с тем, что большинство устаревших программистов вступают в пенсионный возраст, а количество молодых инженеров, заменяющих их, очень невелико, существует тревожная нехватка доступной рабочей силы. Это, в свою очередь, приводит к трудностям в обслуживании устаревших систем, а также к увеличению затрат на привлечение опытных программистов. ^[8]
Некоторые устаревшие системы имеют жесткое ограничение на общую емкость, которого может быть недостаточно для сегодняшних нужд, например ограничение памяти в 4 ГБ на многих старых процессорах x86 или ограничение в 4 миллиарда адресов в IPv4 .

программных системах устаревших Улучшения в

Там, где невозможно заменить устаревшие системы путем прекращения использования приложений , их все равно можно усовершенствовать (или «переоформить»). Большая часть разработок часто связана с добавлением новых интерфейсов в устаревшую систему. Наиболее известным методом является предоставление веб-интерфейса для приложения мэйнфрейма на базе терминала. Это может снизить производительность труда персонала из-за более медленного времени отклика и более медленных действий оператора с помощью мыши, однако это часто рассматривается как «обновление», поскольку стиль интерфейса знаком неквалифицированным пользователям и им легко пользоваться. Джон Маккормик обсуждает такие стратегии, в которых используется промежуточное программное обеспечение . ^[9]

Улучшения печати проблематичны, поскольку устаревшие системы программного обеспечения часто не содержат инструкций по форматированию или используют протоколы, которые невозможно использовать в современных принтерах для ПК/Windows. Сервер печати можно использовать для перехвата данных и перевода их в более современный код. Документы в формате RTF или PostScript можно создавать в устаревшем приложении, а затем интерпретировать на ПК перед печатью.

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

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

на основе моделей Подходы обратного и прямого проектирования также можно использовать для улучшения устаревшего программного обеспечения. ^[10]

Пример НАСА [ править ]

Андреас М. Хейн исследовал использование устаревших систем при освоении космоса в Техническом университете Мюнхена. По мнению Хейна, устаревшие системы привлекательны для повторного использования, если у организации есть возможности для проверки, валидации, тестирования и истории эксплуатации. ^[11]^[12]Эти возможности должны быть интегрированы в различные этапы жизненного цикла программного обеспечения, такие как разработка, внедрение, использование или обслуживание. Для программных систем решающее значение имеет возможность использовать и обслуживать систему. В противном случае система будет становиться все менее понятной и поддерживаемой.

По словам Хейна, проверка, валидация, тестирование и история эксплуатации повышают уверенность в надежности и качестве системы. Однако накопление этой истории часто обходится дорого. В ныне закрытой программе НАСА «Спейс Шаттл» использовалось большое количество технологий эпохи 1970-х годов. Замена была непомерно дорогой из-за дорогостоящих требований по летной сертификации. Исходное оборудование выполнило дорогостоящие требования по интеграции и сертификации для полета, но любое новое оборудование должно было бы пройти весь этот процесс заново. Этот долгий и детальный процесс потребовал обширных испытаний новых компонентов в их новых конфигурациях, прежде чем один блок можно было бы использовать в программе «Спейс Шаттл». Таким образом, любая новая система, начавшая процесс сертификации, де-факто становится устаревшей системой к моменту ее утверждения для полета.

Кроме того, вся система космического корабля «Шаттл», включая наземные средства и средства ракеты-носителя, была спроектирована для совместной работы как закрытая система. Поскольку спецификации не изменились, все сертифицированные системы и компоненты хорошо показали себя в той роли, для которой они были разработаны. ^[13] Еще до того, как в 2010 году планировалось вывести «Шаттл» из эксплуатации, НАСА сочло выгодным продолжать использовать многие технологии 1970-х годов, а не модернизировать эти системы и повторно сертифицировать новые компоненты.

Перспективы устаревшего кода [ править ]

Некоторые специалисты по разработке программного обеспечения предпочитают описывать «устаревший код», не подразумевая, что он устарел. Среди наиболее распространенных нейтральных концепций — исходный код, унаследованный от кого-то другого, и исходный код, унаследованный от более старой версии программного обеспечения . Эли Лопиан, генеральный директор Typemock, определил это как «код, который разработчики боятся менять». ^[14] Майкл Физерс ^[15]ввел определение устаревшего кода как кода без тестов , что отражает точку зрения, что с устаревшим кодом трудно работать, отчасти из-за отсутствия автоматизированных регрессионных тестов . Он также определил тесты для определения характеристик , чтобы начать устаревшего кода тестирование .

Джинни Хендри охарактеризовала создание кода как «вызов» нынешним программистам создать код, который «похож на другое наследие в нашей жизни — например, антиквариат, семейные реликвии и истории, которые лелеют и с любовью передаются из поколения в поколение. если бы устаревший код был тем, чем мы гордились?». ^[16]

использования термина Наследие» в вычислительной « Дополнительные варианты технике

Термин « поддержка устаревших систем» часто используется в сочетании с устаревшими системами. Этот термин может относиться к особенности современного программного обеспечения. Например, операционные системы с «устаревшей поддержкой» могут обнаруживать и использовать старое оборудование. Этот термин также может использоваться для обозначения бизнес-функции; например, поставщик программного обеспечения или оборудования, который поддерживает или обеспечивает обслуживание программного обеспечения для старых продуктов.

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

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

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

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

Архитектура Браунфилда [ править ]

Программисты позаимствовали термин «браунфилд» из строительной отрасли, где ранее освоенные земли (часто загрязненные и заброшенные) описываются как «браунфилд» . ^[17]

Архитектура Браунфилда — это тип программного обеспечения или сетевой архитектуры, включающий в себя устаревшие системы.
Развертывание на существующих объектах — это обновление или дополнение к существующему программному обеспечению или сетевой архитектуре, в котором сохраняются устаревшие компоненты.

Альтернативный взгляд [ править ]

Существует альтернативное положительное мнение, растущее после краха пузыря доткомов в 1999 году, что устаревшие системы — это просто компьютерные системы в рабочем использовании:

« Устаревший код » часто отличается от предлагаемой альтернативы тем, что он действительно работает и масштабируется.
— Бьёрн Страуструп, создатель C++

По оценкам ИТ-аналитиков, стоимость замены бизнес-логики примерно в пять раз превышает стоимость повторного использования. ^[18]даже если не принимать во внимание риск системных сбоев и нарушений безопасности. В идеале компаниям никогда не придется переписывать основную бизнес-логику: дебет = кредит – это постоянное требование.

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

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

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

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

^ «Мерриам-Вебстер» . Проверено 22 июня 2013 г.
^ Перья, Майкл К. (2005). Эффективная работа с устаревшим кодом . Аппер-Сэддл-Ривер, Нью-Джерси: Профессиональный технический справочник Прентис-Холла. п. 15. ISBN 0-13-293174-5 . OCLC 660166658 .
^ Тауде, Свати. «Наследная система» . образование .
^ (например, см. Bisbal et al., 1999).
^ Лэмб, Джон (июнь 2008 г.). «Устаревшие системы по-прежнему имеют место на предприятии» . Компьютерный еженедельник . Проверено 27 октября 2014 г.
^ Стефани Оверби (01 мая 2005 г.). «Рождественская катастрофа Comair: обречена на провал – CIO.com – Лидерство в сфере бизнес-технологий» . CIO.com . Проверено 29 апреля 2012 г.
^ Razermouse (3 мая 2011 г.). «Опасность устаревших систем» . Mousesecurity.com. Архивировано из оригинала 23 марта 2012 года . Проверено 29 апреля 2012 г.
^ «Преимущества модернизации мэйнфреймов» . Центр модернизации . Проверено 23 августа 2017 г.
^ Маккормик, Джон (2 июня 2000 г.). «Промежуточное программное обеспечение мэйнфрейма и веб-сети» . Gcn.com . Проверено 29 апреля 2012 г.
^ Менихтас, Андреас; Константели, Клеопатра; Алонсо, Хункал; Оруэ-Эчеваррия, Лейре; Горроногоития, Иисус; Кузиурис, Джордж; Санцариду, Кристина; Брюнельер, Гюго; Пелленс, Брэм; Стуер, Питер; Штраус, Оливер; Сенькова Татьяна; Варваригу, Теодора (2014), «Модернизация программного обеспечения и облачная среда с использованием методологии и структуры миграции ARTIST», Масштабируемые вычисления: практика и опыт , 15 (2), doi : 10.12694/scpe.v15i2.980
^ А.М. Хейн (2014), Как оценить системы наследия на ранних этапах? , 6-я Международная конференция по системам и параллельному проектированию космических приложений 2014, ЕКА
^ А. М. Хейн (2016), «Технологии наследия в космических программах - методология оценки и статистический анализ» , докторская диссертация, факультет машиностроения, Технический университет Мюнхена
^ А.М. Хейн (2014), Как оценить системы наследия на ранних этапах? , 6-я Международная конференция по системам и параллельному проектированию космических приложений, 2014 г., ЕКА, с. 3
^ Лопиан, Эли (15 мая 2018 г.). «Определение устаревшего кода» . Проверено 10 июня 2019 г.
^ Майкл Физерс « Эффективная работа с устаревшим кодом » ( ISBN 0-13-117705-2 )
^ Джинни Хендри (11 июля 2014 г.). «Гордитесь своим наследием (Кодекс)» . Проверено 7 октября 2021 г.
^ «Определение развертывания новых и существующих объектов» . Searchunifiedcommunication.techtarget.com . Проверено 29 апреля 2012 г.
^ «Рассмотрение стоимости проекта миграции мэйнфрейма в облако» . Кумаран Системы .
^ Комелла-Дорда, Сантьяго (1 апреля 2000 г.). «Обзор подходов к модернизации устаревших систем» (PDF) . Цифровая библиотека ГЭИ .

Дальнейшее чтение [ править ]

А. М. Хейн, Как оценить системы наследия на ранних этапах? SECESA 2014, 08-10 октября 2014 г., Штутгартский университет, Германия.
«Советы и рекомендации по устаревшему оборудованию» , Дэнни Будзински, журнал Control Design Magazine , январь 2011 г.
«Рождественская катастрофа Comair: обречена на провал», Стефани Оверби, журнал CIO , 1 мая 2005 г.
«Провал цифрового компьютера» Адама Н. Розенберга
Бисбал, Дж.; Лоулесс, Д.; Ву, Б.; Гримсон, Дж. (1999). «Устаревшие информационные системы: проблемы и направления». Программное обеспечение IEEE . 16 (5): 103–111. дои : 10.1109/52.795108 .
Джим МакГи (10 ноября 2005 г.). «Устаревшие системы: почему история имеет значение» . Журнал корпоративных систем .
«Опасность устаревших систем» , Стив Р. Смит, 3 мая 2011 г.

Внешние ссылки [ править ]

СМИ, связанные с устаревшими системами, на Викискладе?

[1] «Мерриам-Вебстер» . Проверено 22 июня 2013 г.

[2] Перья, Майкл К. (2005). Эффективная работа с устаревшим кодом . Аппер-Сэддл-Ривер, Нью-Джерси: Профессиональный технический справочник Прентис-Холла. п. 15. ISBN 0-13-293174-5 . OCLC 660166658 .

[3] Тауде, Свати. «Наследная система» . образование .

[4] (например, см. Bisbal et al., 1999).

[5] Лэмб, Джон (июнь 2008 г.). «Устаревшие системы по-прежнему имеют место на предприятии» . Компьютерный еженедельник . Проверено 27 октября 2014 г.

[6] Стефани Оверби (01 мая 2005 г.). «Рождественская катастрофа Comair: обречена на провал – CIO.com – Лидерство в сфере бизнес-технологий» . CIO.com . Проверено 29 апреля 2012 г.

[7] Razermouse (3 мая 2011 г.). «Опасность устаревших систем» . Mousesecurity.com. Архивировано из оригинала 23 марта 2012 года . Проверено 29 апреля 2012 г.

[8] «Преимущества модернизации мэйнфреймов» . Центр модернизации . Проверено 23 августа 2017 г.

[9] Маккормик, Джон (2 июня 2000 г.). «Промежуточное программное обеспечение мэйнфрейма и веб-сети» . Gcn.com . Проверено 29 апреля 2012 г.

[10] Менихтас, Андреас; Константели, Клеопатра; Алонсо, Хункал; Оруэ-Эчеваррия, Лейре; Горроногоития, Иисус; Кузиурис, Джордж; Санцариду, Кристина; Брюнельер, Гюго; Пелленс, Брэм; Стуер, Питер; Штраус, Оливер; Сенькова Татьяна; Варваригу, Теодора (2014), «Модернизация программного обеспечения и облачная среда с использованием методологии и структуры миграции ARTIST», Масштабируемые вычисления: практика и опыт , 15 (2), doi : 10.12694/scpe.v15i2.980

[11] А.М. Хейн (2014), Как оценить системы наследия на ранних этапах? , 6-я Международная конференция по системам и параллельному проектированию космических приложений 2014, ЕКА

[12] А. М. Хейн (2016), «Технологии наследия в космических программах - методология оценки и статистический анализ» , докторская диссертация, факультет машиностроения, Технический университет Мюнхена

[13] А.М. Хейн (2014), Как оценить системы наследия на ранних этапах? , 6-я Международная конференция по системам и параллельному проектированию космических приложений, 2014 г., ЕКА, с. 3

[14] Лопиан, Эли (15 мая 2018 г.). «Определение устаревшего кода» . Проверено 10 июня 2019 г.

[15] Майкл Физерс « Эффективная работа с устаревшим кодом » ( ISBN 0-13-117705-2 )

[16] Джинни Хендри (11 июля 2014 г.). «Гордитесь своим наследием (Кодекс)» . Проверено 7 октября 2021 г.

[17] «Определение развертывания новых и существующих объектов» . Searchunifiedcommunication.techtarget.com . Проверено 29 апреля 2012 г.

[18] «Рассмотрение стоимости проекта миграции мэйнфрейма в облако» . Кумаран Системы .

[19] Комелла-Дорда, Сантьяго (1 апреля 2000 г.). «Обзор подходов к модернизации устаревших систем» (PDF) . Цифровая библиотека ГЭИ .

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]