Этап сопровождения
В сравнении с традиционными методологиями разработки ПС этап сопровождения в компонентной методологии характеризуется следующими особенностями.
1. Обслуживающий персонал ПС не имеет доступа к коду компонентов. В связи с этим при необходимости изменения ПС традиционные подходы и методы адаптируются к возможностям новых условий функционирования, тестирования, выявления и исправление ошибок, модификации отдельных элементов и др.
2. Вся политика модернизации, усовершенствования, расширения ПС должна строиться на компонентной основе, в которой главными механизмами могут лишь быть:
– замена существующих компонентов новыми компонентами с сохранением интерфейсов и сервисных возможностей;
– расширение функциональных и технологических возможностей отдельных компонентов на основе их свойств и сохранение существующих интерфейсов.
3. Отдельные компоненты, которые применяются в ПС, могут быть созданы посторонними разработчиками и использоваться в данной ПС, как готовые. Соответственно с этим производителями проводится собственная политика относительно поддержки, усовершенствования, развития таких компонентов. При сопровождении ПС такие ситуации необходимо учитывать как в технологическом, так и в организационно–правовом аспекте (например, охрана авторских прав на программное обеспечение).
Эти особенности существенным образом влияют на традиционные задачи этапа сопровождения и процессов, которое их поддерживают. К основным процессам этого процесса относятся:
– модификация компонентной конфигурации;
– адаптация новых компонентов к требованиям и условиях интегрированной среды;
– анализ отказов функционирования, обнаружение дефектов, поиск и исправления ошибок в программной системе;
– тестирование ПС.
Кратко остановимся на общей характеристике этих процессов.
Модификация компонентной конфигурации. Этот процесс отвечает за следующее:
– добавление и исключение определенных компонентов;
– замещение существующих компонентов новыми как с тождественной функциональностью и интерфейсами, так и с расширенными характеристиками.
Необходимыми условиями для этого процесса является возможность манипуляций с компонентами как отдельными объектами с сохранением свойств и характеристик разных частей ПС. Это достигается благодаря применению систем управления конфигурациями, с помощью которых отслеживаются и выполняются все изменения в конфигурации системы.
Адаптация новых компонентов к требованиям и условиям среды. Данный процесс, по сути и по содержанию, почти не отличается от соответствующего процесса этапа интеграции. Имеющиеся отличия носят непринципиальный характер. К ним, в частности, можно отнести то, что в случае неудовлетворительной адаптации, всегда имеется возможность вернуться к существующему компоненту и программная система остается без перемен.
Кроме этого, сам процесс адаптации может выполняться обслуживающим персоналом пользователя (при наличии специалистов с необходимой квалификацией), а не разработчиком ПС.
Анализ отказов функционирования, поиск и исправления ошибок в ПС. Если при определенных условиях в программной системе появляются отказы функционирования или ошибки программирования, то главной задачей их локализации является нахождение компонентов, которые ненормально работают. В большинстве случаев обслуживающий персонал не в состоянии исправить код компонента, к которому нет доступа.
Для исправления ошибок используются следующие механизмы:
– обращение к разработчику компонента и, если он был специально созданный для этой системы, дождаться от него исправления ошибки, а потом заменить соответствующий компонент;
– если компонент является коммерческим продуктом, который создан сторонним производителем, то ему должны сообщить соответствующие разработчики и дождаться официальной версии компонента, в котором исправлена ошибка, и есть возможность заменить этот компонент;
– не дожидаясь исправления ошибки другими разработчиками, провести замену локализованного ошибочного компонента другим правильным с соответствующей функциональностью и интерфейсами.
На период исправления ошибки последовательности взаимодействий компонентов, которые были определены на предыдущих этапах, выключаются из функционирования путем внесения адекватных изменений в компонентную конфигурацию.
Тестирование ПС. Тестирование проводится периодически для проверки правильности функционирования системы и в случаях внесения изменений в компонентную конфигурацию или замены отдельных компонентов. Под этим процессом понимается тестирование системы на компонентном уровне, т.е. покомпонентное тестирование.
Для проведения периодического тестирования применяются тесты, которые передаются разработчиком ПС пользователю. Главная цель такого тестирования – подтвердить правильность функционирования системы, оценить ее эффективность, быстродействие и другие технологические характеристики. Порядок и условия процесса тестирования для ПС отображаются в соответствующих документах.
Для тестирования проведенных изменений в компонентную конфигурацию и отдельные компоненты необходимо иметь:
– сами компоненты в готовом к применению виде;
– гарантию относительно достаточно полного тестирования компонентов их разработчиками, иметь информацию о результатах тестирования, в частности перечень еще неисправленных ошибок;
– четко сформулированные условия применения компонентов, как с функциональной точки зрения, так и с технологической (в частности, иметь данные о ресурсах, необходимых для нормальной работы компонентов системы).
При разработке тестов учитывается:
– последовательности взаимодействий компонентов, в состав которых входят те компоненты, которые проходят тестирование;
– информация о самостоятельном тестировании компонентов (используется для уменьшения объема тестирования);
– условия для нормального функционирования компонентов.
После проведения тестирования и анализа результатов, при наличии ошибок разного рода, проводятся соответствующие изменения, как в компонентную конфигурацию, так и в отдельные компоненты системы, в которых обнаружены ошибки.
