Гид разработчика: наследуем ИТ-систему
Достаточно часто предприятие, эксплуатирующее какую-либо АС в течение нескольких лет, в силу тех или иных причин не хочет отказываться от нее и при смене разработчика или передаче функций по ее обслуживанию на аутсорсинг. В этом случае внешним компаниям придется заниматься поддержанием работы, а также дальнейшим развитием унаследованной системы. Подобные проекты имеют свои особенности.
Развитие унаследованных систем (legacy systems) – особая область деятельности аутсорсинговых компаний-разработчиков программного обеспечения. Речь идет о системах, которые предприятия эксплуатируют несколько лет, не хотят от них отказываться, однако их развитие под нужды бизнеса тем или иным способом затруднено, и необходимо вдохнуть в них вторую жизнь.
Наработки и проблематика этой области являются элементами внутренней технологической «кухни» компании-разработчика. В этой связи данная тема мало освещается в специализированной литературе и СМИ. Однако подобные проекты имеют свои особенности и закономерности, знакомство с которыми может быть полезно специалистам, сталкивающимся с задачей развития унаследованных систем.
В данной статье мы рассмотрим особенности работы с унаследованными ИТ-системами операторов сотовой связи.
В зависимости от происхождения можно выделить два типа унаследованных систем: разработанные собственными силами заказчика и созданные внешней компанией-разработчиком ПО.
В самом худшем случае, когда изначально система разрабатывалась «на коленке», придется иметь дело со всеми проблемами сразу
В обоих случаях унаследованные системы могут характеризоваться использованием устаревших технологий, языков программирования и архитектурных подходов, иметь несовременный пользовательский интерфейс. Кроме того, они бывают недостаточно гибкими и масштабируемыми, из-за чего обязательно возникают проблемы производительности.
В зависимости от типа унаследованной системы различаются и причины, по которым заказчик решает передать ее развитие внешней компании-разработчику. Рассмотрим по порядку каждый из случаев.
Вывод системы из внутренней разработки
Основная причина передачи созданной своими силами системы внешнему разработчику – общая тенденция к выводу разработки ПО в аутсорсинг. Компании становится не выгодно содержать собственный штат программистов, поэтому когда-то созданные ими ИТ-системы передаются на дальнейшую разработку внешней компании (вендору). При этом вендор может столкнуться с рядом типичных проблем. Наименее критичная из них — наличие в одной системе целого «зоопарка» модулей, написанных на различных языках программирования.
Еще одна трудность, встречающаяся в таких АС, — отсутствие носителя знаний по данной системе (ее создателя, программиста, который дорабатывал систему) и отсутствие архитектурной документации, технического задания, спецификаций, требований. Достаточно серьезной можно считать проблему несоответствия исходных кодов, имеющихся у заказчика, и версии системы, находящейся в продуктивной эксплуатации. И наиболее критичным является отсутствие исходных кодов системы, например, по причине их утери.
Типичные проблемы, возникающие при передаче обслуживания «собственных» систем внешнему разработчику
Ранг по степени критичности | Проблема |
1 | Отсутствие исходных кодов системы |
2 | Несоответствие исходных кодов, имеющихся у заказчика, и версии системы, находящейся в продуктивной эксплуатации |
3 | Отсутствие архитектурной документации, технического задания, спецификаций, требований |
4 | Отсутствие носителя знаний по данной системе (ее создателя, программиста, который дорабатывал систему) |
5 | Наличие в одной системе целого «зоопарка» модулей, написанных на различных языках программирования |
Источник: Instream, 2008
Стоит заметить, что наличие и степень упомянутых проблем зависят от уровня зрелости процесса разработки в ИТ-департаменте заказчика. В самом худшем случае, когда изначально система разрабатывалась «на коленке», придется иметь дело со всеми этими препятствиями сразу. Но даже в идеальном случае не стоит ожидать хорошего уровня документирования системы.
Смена поставщика
Когда система передается для доработки от другого поставщика ПО? Заказчик может передать систему другому вендору по причине плохого функционирования или невысокого качества работы вендора.
Это, конечно, взаимосвязанные причины: недовольство сервисом ИТ-компании приводит к неудовлетворенности качеством системы в целом – в бизнесе обычно нет дыма без огня. Конечно, встречаются еще политические, корпоративные, финансовые, личные мотивы смены производителя ПО, но их анализ выходит за рамки статьи.
Возникающие при смене компании-разработчика проблемы имеют специфический характер. В этом случае в системе не будет многообразия используемых технологий и языков. Носитель знаний, скорее всего, существует — это разработчик, который до последнего времени поддерживал развитие системы. Остаются четыре основных проблемы. Первая — недоступность носителя знаний по системе. Ведь вендор, у которого «отобрали» систему, не всегда идет навстречу своему конкуренту. Следующая трудность – опять же, отсутствие либо недоступность полной документации по системе. Вообще, это проблема большинства разработчиков. Кроме того, сложности может вызвать несоответствие исходных кодов функциональности последней версии системы. Заказчик просит передать исходные коды системы новому вендору, но не может отвечать за их адекватность. В итоге, последнюю версию исходных кодов новый вендор может получить только после нескольких попыток.
Типичные проблемы, возникающие при передаче обслуживания системы другому разработчику
Ранг по степени критичности | Проблема |
1 | Отсутствие исходных кодов системы |
2 | Несоответствие исходных кодов функциональности последней версии системы |
3 | Отсутствие, либо недоступность полной документации по системе |
4 | Недоступность носителя знаний по системе |
Источник: Instream, 2008
И, наконец, самая серьезная проблема, которая может возникнуть, — это отсутствие исходных кодов системы.
Постановка задачи
Обычно заказчик ставит перед новым разработчиком унаследованной системы следующие задачи: повысить производительность системы, реализовать критичные и срочные требования заинтересованного бизнес-подразделения, принять в поддержку и улучшить качество работы (снизить количество дефектов и инцидентов), внедрить систему в другом филиале/регионе /стране. Каждую из них стоит рассмотреть более детально.
Когда разработчик сталкивается с задачей повышения производительности, чаще всего система уже испытывает трудности и не справляется с нагрузкой. При этом требование может быть в виде конкретного значения, например, 2500 операций в секунду, либо будет указан желаемый срок стабильной работы системы при текущем маркетинговом прогнозе. Такая задача — клад для пытливых архитекторов и амбициозных разработчиков.
Задача внедрения унаследованной системы в новом филиале или регионе представляет собой отдельное направление деятельности
Как появляется задача реализовать новую функциональность в унаследованной системе? Бывает, что новая услуга/акция заказчика отлично укладывается в рамки существующей системы. И доработка этой системы может обойтись дешевле, чем разработка новой. Но, увы, у заказчика нет собственных ресурсов на доработку старой системы. Так она попадает к внешнему разработчику, в чьих интересах взять ее на развитие.
Очень важная задача – улучшить качество работы системы. Не секрет, что многие пользователи годами страдают от существующих ошибок, сбоев и других проявлений некачественной разработки и поддержки системы. Если у заказчика нет собственных ресурсов для обеспечения высокого уровня качества сервиса, то логично передать обслуживание внешней компании. Ее прямой обязанностью будет поддерживать систему в состоянии, за которое ему будет не стыдно. Здесь существует прямой вызов профессионализму разработчиков, тестировщиков и менеджеров. Известно, что не многие могут похвастаться благодарными отзывами от заказчиков и пользователей поддерживаемых ими систем.
Задача внедрения унаследованной системы в новом филиале/регионе/стране представляет собой отдельное направление деятельности компании-разработчика. При расширении географии бизнеса у заказчика возникает вполне резонное желание перенести существующие, годами отлаженные бизнес-процессы на новую территорию. При этом возникает необходимость копирования структуры ИТ-систем, поддерживающих эти процессы. Типичные задачи — кастомизация системы под местные особенности бизнес-процессов, локализация пользовательских интерфейсов, интеграция с существующим ИТ-окружением. И все это — в рамках жестко фиксированного срока запуска. При этом заказчик часто может не представлять объем необходимых для внедрения доработок, но в процессе первого внедрения происходит плавный переход от оптимизма к здоровому пессимизму.
В целом, при грамотном подходе как заказчика, так и разработчика, унаследованные системы могут не только «выжить», но и существенно помочь бизнесу заказчика. Для их развития не требуются многомиллионные вложения на внедрение, обучение пользователей, нет длительного периода «привыкания» к системе. Довольно разумно использовать уже имеющийся «багаж» отлаженных унаследованных систем, тем более, если они успешно решают конкретные задачи бизнеса.
Стратегия и тактика решения проблем, возникающих при работе с унаследованными системами, будут рассмотрены в следующей статье.
А. Ильин
источник: http://www.cnews.ru/reviews/index.shtml?2009/01/30/336313
Свежие комментарии