✖


Jump to content

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

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

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

Стратегии

[ редактировать ]

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

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

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

[ редактировать ]

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

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

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

[ редактировать ]

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

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

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

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

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

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

[ редактировать ]

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

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

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

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

[ редактировать ]

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

  • Оценка приложений: определение базы существующего портфеля приложений с использованием аналитики программного обеспечения для понимания состояния программного обеспечения, качества, состава, сложности и готовности облака, чтобы начать сегментировать и определять приоритеты приложений для различных вариантов модернизации.
  • Обнаружение приложений . Компоненты приложений сильно переплетены, что подразумевает необходимость понимания сложности и разрешения взаимозависимостей программного компонента.
  • Миграция: миграция языков (3GL или 4GL), баз данных (устаревших в СУБД и одной СУБД в другую), платформы (из одной ОС в другую), часто с использованием автоматических конвертеров или систем преобразования программ для повышения эффективности. Это быстрый и экономичный способ трансформации устаревших систем.
  • Миграция в облако: миграция устаревших приложений на облачные платформы, часто с использованием такой методологии, как методология Gartner 5 Rs, для сегментации и определения приоритетов приложений по различным моделям (перехостирование, рефакторинг, пересмотр, перестройка, замена).
  • Реинжиниринг: метод перестройки устаревших приложений на новой технологии или платформе с той же или расширенной функциональностью – обычно путем принятия сервис-ориентированной архитектуры (SOA). Это наиболее эффективный и гибкий способ преобразования устаревших приложений. [6] на уровне приложений Для этого требуется программный интеллект с устаревшими системами, которые недостаточно известны или документированы.
  • Повторный хостинг: запуск устаревших приложений без серьезных изменений на другой платформе. Бизнес-логика сохраняется, поскольку приложения и данные переносятся в открытую среду. Этот вариант требует только замены промежуточного программного обеспечения, оборудования, операционной системы и базы данных.<r [21] ation Hub|language=en-US|access-date=2017-08-23}</ref> Это часто используется в качестве промежуточного шага для отказа от устаревшего и дорогостоящего оборудования. Наиболее распространенные примеры включают мэйнфреймов размещение приложений на платформах UNIX или Wintel .
  • Внедрение пакета: замена устаревших приложений полностью или частично на готовое программное обеспечение (COTS), такое как ERP, CRM, SCM, программное обеспечение для выставления счетов и т. д. [22]

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

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

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

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

[ редактировать ]

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

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

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

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

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

[ редактировать ]

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

[ редактировать ]

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

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

[ редактировать ]

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

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ Перейти обратно: а б Гарднер, Д.: «Модернизация приложений — это не просто мелочь, а продлевает жизненный цикл устаревших кодов» , ZDNet , 24 октября 2006 г.
  2. ^ Вольфарт, Даниэле; Ассунсао, Уэсли; да Силва, Ивоней; Домингуш, Диого; Шмейнг, Эдерсон; Вильяка, Гильерме; Паза, Диого (июнь 2021 г.). «Модернизация устаревших систем с помощью микросервисов: дорожная карта» . Оценка и оценка в разработке программного обеспечения . стр. 149–159. дои : 10.1145/3463274.3463334 . ISBN  9781450390538 . S2CID   235474042 .
  3. ^ Бартошук, Цезари; Домбровский, Роберт; Стенсель, Кшиштоф; Тимошук, Гжегож (июнь 2013 г.). «О быстром понимании и оценке программного обеспечения» . Материалы 14-й Международной конференции по компьютерным системам и технологиям . стр. 161–168. дои : 10.1145/2516775.2516806 . ISBN  9781450320214 . S2CID   17034416 .
  4. ^ Ограниченная рациональность Саймона. Происхождение и использование в экономической теории.
  5. ^ Стефан Ван дер Зейден; Томас Клинкект. «Построение бизнес-кейса по модернизации мультиплатформенных приложений» . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  6. ^ Перейти обратно: а б Менихтас, Андреас; Санцариду, Кристина; Кузиурис, Джордж; Варваригу, Теодора; Оруэ-Эчеваррия, Лейре; Алонсо, Хункал; Горроногоития, Иисус; Брюнельер, Гюго; Штраус, Оливер; Сенькова Татьяна; Пелленс, Брэм; Стуер, Питер (2013), «Методология и структура ARTIST: новый подход к миграции устаревшего программного обеспечения в облако» (PDF) , 15-й Международный симпозиум по символическим и числовым алгоритмам для научных вычислений (PDF) , 2013 г., 15-й Международный симпозиум по Символьные и числовые алгоритмы для научных вычислений (SYNASC), IEEE, стр. 424–431, doi : 10.1109/SYNASC.2013.62 , ISBN  978-1-4799-3036-4 , S2CID   8150975
  7. ^ Перейти обратно: а б Менихтас, Андреас; Константели, Клеопатра; Алонсо, Хункал; Оруэ-Эчеваррия, Лейре; Горроногоития, Иисус; Кузиурис, Джордж; Санцариду, Кристина; Брюнельер, Гюго; Пелленс, Брэм; Стуер, Питер; Штраус, Оливер; Сенькова Татьяна; Варваригу, Теодора (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 . дои : 10.1109/CMPSAC.2002.1045037 . ISBN  978-0-7695-1727-8 . S2CID   16563177 .
  10. ^ Иззет Шахин; Фатеме «Мариам» Захеди (2001). «Анализ политики гарантийного обслуживания, обслуживания и обновления программных систем». Журнал обслуживания программного обеспечения: исследования и практика . 13 (6): 469–493. дои : 10.1002/smr.242 .
  11. ^ Юсси Коскинен; Ярмо Ахонен; Хейкки Линтинен; хна сивула; Теро Тилус. «Оценка бизнес-ценности модернизации программного обеспечения» . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  12. ^ «Миграция VB6. Зачем ставить под угрозу безопасность данных, если можно перейти на более современные платформы?» .
  13. ^ Льюис, Г.; Моррис, Э.; Смит, Д.; О'Брайен, Л. (2005). «Техника сервис-ориентированной миграции и повторного использования (SMART)». 13-й международный семинар IEEE по технологиям программного обеспечения и инженерной практике (STEP'05) . стр. 222–229. дои : 10.1109/шаг.2005.24 . hdl : 10344/2208 . ISBN  0-7695-2639-Х . S2CID   18912663 .
  14. ^ Льюис, Грейс А.; Плакош, Дэниел; Сикорд, Роберт К. (2003). Модернизация устаревших систем: программные технологии, инженерные процессы и бизнес-практики . Аддисон-Уэсли Профессионал. стр. 27–37. ISBN  0321118847 .
  15. ^ Мобилизовать.Нет. «Ускоренный путь к модернизации программного обеспечения | Mobilize.Net» . www.mobilize.net . Проверено 19 марта 2021 г.
  16. ^ Андреа Де Люсия; Эухенио Помпелла и Сильвио Стефануччи (июль 2002 г.). «Оценка усилий по корректирующему обслуживанию программного обеспечения» (PDF) . Материалы 14-й международной конференции по программной инженерии и инженерии знаний - SEKE '02 . SEKE '02 Искья, Италия. п. 409. дои : 10.1145/568760.568831 . ISBN  978-1581135565 . S2CID   10627249 . {{cite book}}: CS1 maint: местоположение ( ссылка ) CS1 maint: отсутствует местоположение издателя ( ссылка )
  17. ^ Де Люсия, А.; Фасолино, Арканзас; Помпель, Э. (2001). «Система принятия решений для управления устаревшими системами». Материалы Международной конференции IEEE по сопровождению программного обеспечения. МЦСМ 2001 . стр. 642–651. дои : 10.1109/ICSM.2001.972781 . ISBN  0-7695-1189-9 . S2CID   32184332 .
  18. ^ Коскинен, Юсси; Линтинен, Хейкки; Сивула, Хна; Тилус, Теро. «Оценка методов оценки модернизации программного обеспечения с использованием метафреймворка NIMSAD». Публикации Научно-исследовательского института информационных технологий . CiteSeerX   10.1.1.106.2633 .
  19. ^ Сантош Г. Рамакришна; ВВ (май 2007 г.). «Модернизация наследия логистики» (PDF) . Инфосис Технологии Лимитед.
  20. ^ К. Гецци (2018). «Поддержка надежной эволюции». В Грюн, Волкер; Стример, Рюдигер (ред.). Сущность программной инженерии . стр. 32–33. дои : 10.1007/978-3-319-73897-0 . ISBN  978-3-319-73897-0 . S2CID   49187426 .
  21. ^ ef>{{Cite web|url= http://www.modernizationhub.com%7Ctitle=Модернизация мэйнфрейма в двух словах|last=|first=|date=|website=Moderniz
  22. ^ Серия, AS (ISO 9001:2008). Модернизация наследия – преобразование в гибкое предприятие. Технический документ по модернизации наследия
  23. ^ SearchCIO.com
  24. ^ С.К. Мишра; Д.С. Кушваха; А. К. Мисра (июль – август 2009 г.). «Создание повторно используемого программного компонента из объектно-ориентированной устаревшей системы посредством обратного проектирования» . Журнал объектных технологий . 8 (5): 133–152. дои : 10.5381/jot.2009.8.5.a3 .
  25. ↑ Мольтке, Х. против (среда, 22 января 2003 г., 21:55). Модернизация, управляемая рисками. Джавахарлал Неру, Речь в парламенте Нью-Дели: Seacord.book.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Software_modernization&oldid=1232794668"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 7df535ca1540682086eb1f7691af97ae__1720187100
URL1:https://arc.ask3.ru/arc/aa/7d/ae/7df535ca1540682086eb1f7691af97ae.html
Заголовок, (Title) документа по адресу, URL1:
Software modernization - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)