Поделиться
Гид разработчика: наследуем ИТ-систему
Достаточно часто предприятие, эксплуатирующее какую-либо АС в течение нескольких лет, в силу тех или иных причин не хочет отказываться от нее и при смене разработчика или передаче функций по ее обслуживанию на аутсорсинг. В этом случае внешним компаниям придется заниматься поддержанием работы, а также дальнейшим развитием унаследованной системы. Подобные проекты имеют свои особенности.Развитие унаследованных систем (legacy systems) – особая область деятельности аутсорсинговых компаний-разработчиков программного обеспечения. Речь идет о системах, которые предприятия эксплуатируют несколько лет, не хотят от них отказываться, однако их развитие под нужды бизнеса тем или иным способом затруднено, и необходимо вдохнуть в них вторую жизнь.
Наработки и проблематика этой области являются элементами внутренней технологической "кухни" компании-разработчика. В этой связи данная тема мало освещается в специализированной литературе и СМИ. Однако подобные проекты имеют свои особенности и закономерности, знакомство с которыми может быть полезно специалистам, сталкивающимся с задачей развития унаследованных систем.
В данной статье мы рассмотрим особенности работы с унаследованными ИТ-системами операторов сотовой связи.
В зависимости от происхождения можно выделить два типа унаследованных систем: разработанные собственными силами заказчика и созданные внешней компанией-разработчиком ПО.
В самом худшем случае, когда изначально система разрабатывалась "на коленке", придется иметь дело со всеми проблемами сразу
В обоих случаях унаследованные системы могут характеризоваться использованием устаревших технологий, языков программирования и архитектурных подходов, иметь несовременный пользовательский интерфейс. Кроме того, они бывают недостаточно гибкими и масштабируемыми, из-за чего обязательно возникают проблемы производительности.
В зависимости от типа унаследованной системы различаются и причины, по которым заказчик решает передать ее развитие внешней компании-разработчику. Рассмотрим по порядку каждый из случаев.
Вывод системы из внутренней разработки
Основная причина передачи созданной своими силами системы внешнему разработчику – общая тенденция к выводу разработки ПО в аутсорсинг. Компании становится не выгодно содержать собственный штат программистов, поэтому когда-то созданные ими ИТ-системы передаются на дальнейшую разработку внешней компании (вендору). При этом вендор может столкнуться с рядом типичных проблем. Наименее критичная из них - наличие в одной системе целого "зоопарка" модулей, написанных на различных языках программирования.Еще одна трудность, встречающаяся в таких АС, - отсутствие носителя знаний по данной системе (ее создателя, программиста, который дорабатывал систему) и отсутствие архитектурной документации, технического задания, спецификаций, требований. Достаточно серьезной можно считать проблему несоответствия исходных кодов, имеющихся у заказчика, и версии системы, находящейся в продуктивной эксплуатации. И наиболее критичным является отсутствие исходных кодов системы, например, по причине их утери.
Типичные проблемы, возникающие при передаче обслуживания "собственных" систем внешнему разработчику
| Ранг по степени критичности | Проблема |
| 1 | Отсутствие исходных кодов системы |
| 2 | Несоответствие исходных кодов, имеющихся у заказчика, и версии системы, находящейся в продуктивной эксплуатации |
| 3 | Отсутствие архитектурной документации, технического задания, спецификаций, требований |
| 4 | Отсутствие носителя знаний по данной системе (ее создателя, программиста, который дорабатывал систему) |
| 5 | Наличие в одной системе целого "зоопарка" модулей, написанных на различных языках программирования |
Источник: Instream, 2008
Стоит заметить, что наличие и степень упомянутых проблем зависят от уровня зрелости процесса разработки в ИТ-департаменте заказчика. В самом худшем случае, когда изначально система разрабатывалась "на коленке", придется иметь дело со всеми этими препятствиями сразу. Но даже в идеальном случае не стоит ожидать хорошего уровня документирования системы.
Смена поставщика
Когда система передается для доработки от другого поставщика ПО? Заказчик может передать систему другому вендору по причине плохого функционирования или невысокого качества работы вендора.
Короткая ссылка
