Особенности проектов по модернизации.

Большая часть задач по модернизации решения могут проводиться параллельно с эксплуатацией (не дожидаясь ее прекращения), однако это будет требовать повышенного контроля ко всем параметрам и данным системы, вероятность ошибок в которых резко повышается. С другой стороны, успешное применение подобного способа позволяет избежать необходимости мигрировать данные после модернизации и искать «промежуточное» решение, на время модификации ИС заменяющее по функциональности и удобству основную систему. Прежде, чем начать модернизацию, следует рассмотреть следующие аспекты: 1) Целесообразность модернизации. Иногда лучшим выбором может быть продолжение использования системы, фокусируясь на снижении затрат на поддержку. Однако любая legacy-система со временем будет требовать все больших вложений за счет необходимости ее сопровождения сотрудниками с необходимым набором компетенций и опытом работы с подобными системами. 2) Аутсорсинг систем и процессов. Все большее число компаний выбирают вариант рехостинга legacy-систем (особенно в условиях наличия многочисленных вариантов планов аутсорсинга, предлагаемых поставщиками). При этом модификации самой системы можно избежать. 3) Целесообразность перехода на другую платформу. Для компаний, активно участвующих в процессах слияний и поглощений (M&A), эффективной альтернативой модернизации может стать консолидация и перевод legacy-систем на единую корпоративную платформу (в идеале – с хорошей масштабируемостью). Подобные активности могут значительно повысить затраты в краткосрочном периоде, но долгосрочные выгоды оказываются очень существенными. 4) Минимизация числа изменений. В некоторых случаях предприятия могут вносить изменения во внутренний дизайн приложения, сохраняя его функциональные возможности. Так, рефакторинг кода программного решения иногда позволяет модифицировать приложение гораздо более эффективно, нежели масштабная модернизация. 5) Минимальная кастомизация. Многие вендоры положительно относятся к проектам по кастомизации / локализации их программных решений, когда это означает более высокую выручку и выход на новые рынки. Так, в большинстве случаев компании приобретают бизнес-платформы и адаптируют исходный код под собственную специфику (либо выпускают патч для более старой версии, например, с учетом изменений налогового законодательства). Однако в тот самый момент, когда предприятие примет решение о вы- пуске новых релизов, ей придется столкнуться с множеством кастомизированных доработок и отклонений от исходной версии, что увеличит время- и трудозатраты на модификацию. 6) Длительные проекты внедрения значительно повышают риски. В современных условиях, когда жизненный цикл программных решений постоянно сокращается, а новые технологии и стандарты появляются с завидной регулярностью, система, разработанная в сложном длительном проекте внедрения с многочисленными итерациями тестирования и доработок, может оказаться неактуальной еще до окончания проекта. 7) Интеграция систем на основе SOA не является панацеей от всех проблем. Все чаще вендоры рекомендуют настройку SOA-интерфейсов legacy-систем, когда «монолитные» приложения разбиваются на определенные компоненты, которые затем по отдельности реализуются по SOA-принципам. Адаптеры инкапсулируют различные технологии для реализации интерфейса между приложениями / для подключения используется единая сервисная шина. Однако следует отметить, что данный подход никоим образом не снижает сложность приложения / затраты на его сопровождение, а лишь обеспечивает его более эффективное взаимодействие с окружающей средой. 8) Возможности обновлений. Компании, заключающие контракт на сопровождение, чаще всего ограничиваются обновлением приложений до новой версии в случае необходимости. Однако возможна ситуация, когда приобретенное приложение больше не выпускается и не поддерживается, и организациям приходится сталкиваться с масштабной заменой программного решения. Поэтому необходимо взвешенно принимать решение об обновлении ПО при выпуске каждой новой версии, либо же с определенными промежутками, только после выпуска самых значительных обновлений. 9)Планирование архитектуры приложений. Замена системы может решить только небольшую часть проблем, важно в целом эффективно планировать ландшафт приложений, формировать принципы принятия решения о внедрении/ модернизации/ утилизации систем, согласовывать действия со стратегическими целями ИТ и предприятия в целом.

Список рекомендуемой литературы

а) основная литература:

1. УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ СИСТЕМ Е.П. ЗАРАМЕНСКИХ

б) дополнительная литература:

КОМПЛЕКСНОЕ ПЛАНИРОВАНИЕ МОДЕРНИЗАЦИИ ИНФОРМАЦИОННЫХ СИСТЕМ: МЕТОДОЛОГИЧЕСКИЕ И МЕТОДИЧЕСКИЕ ОСНОВЫ Б. В. СОКОЛОВ, Е. М. ЗАЙЧИК, А. В. ИКОННИКОВА, С. А. ПОТРЯСАЕВ

в) прочая литература:

http://www.intuit.ru

https://www.hse.ru/data/2014/12/25/1314149415/1Зараменских_ЖЦИС.pdf

Дата добавления: 2017-02-01