Базовые понятия процесса сопровождения программных систем

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

Стандарт IEEE 1219 определяет сопровождение как модификацию программного продукта после передачи в эксплуатацию для устранения сбоев, улучшения показателей производительности и/или других характеристик (атрибутов) продукта или его адаптацию для использования в модифицированном окружении.

Стандарт жизненного цикла 12207 (IEEE, ISO/IEC, ГОСТ Р ИСОМЭК) определяет сопровождение как один из важных процессов ЖЦ, направленный на модификацию программного продукта в части кода и документации для решения возникающих в процессе эксплуатации проблем или реализации потребностей в улучшениях характеристик продукта.

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

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

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

Специалисты по сопровождению должны иметь доступ к артефактам разрабатываемой системы и получать необходимые знания для сопровождения программного продукта, начиная со стадии опытной эксплуатации программного продукта. При этом в ряде проектов служба поддержки должна еще и исправлять ошибки разработчиков (с обязательным информированием последних о них), а также осуществлять выпуск так называемых «патчей» (patch – заплата).

При работе с заказчиком в обязанности инженеров службы сопровождения входит следующее: проверка пользовательского сценария, приводящего к сбою; идентификация причин сбоя; устранение причин сбоя или их обход (work around); документирование всех работ и операций; внесение описания проблемы и ее решения в базу знаний службы сопровождения; передача всей информации разработчикам; информирование пользователя о статусе запроса на сопровождение. Перечень этих работ может варьироваться в зависимости от корпоративных стандартов.

В обязанности персонала входит выполнение следующих действий: поддержка контроля (управляемости) ПО в течение всего цикла эксплуатации; поддержка модификации программных систем совершенствование существующих функций сопровождения; предотвращение уменьшения производительности программной системы до неприемлемого уровня.

Выполнение запросов на сопровождение программного продукта можно рассматривать как его совершенствование (эволюцию). В результате программный продукт становится все более сложным в эксплуатации и сопровождении. Этот процесс может продолжаться до тех пор, пока не будут разработаны специальные мероприятия по уменьшению сложности программного продукта.

В связи с этим особый интерес вызывают наследуемые системы (legacy systems), которые представляют собой программные продукты созданные однажды для какой–либо компании и используемые ими на протяжении длительного времени (десятилетиями). При эксплуатации данные системы подвергаются неоднократной модификации в соответствии с операционным окружением и реальными бизнес-процессами.

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

Рисунок 25.1. Многоуровневая модель наследуемой системы.

 

С точки зрения сопровождения, с унаследованными приложениями возможны два действия: сопровождение продолжать и сопровождение прекратить. Последнее действие может быть детализировано следующим образом: заменить на новый продукт (купленный или разработанный самостоятельно); присоединить к новому приложению; инкапсулировать и использовать как сервер (с использованием образца проектирования Adapter).

Очевидно, что проектирование наследуемой системы будет отличаться от системы, которая не предусматривает подобный механизм модификации. Здесь можно использовать уже готовые решения (если проектирование осуществляется на основе объектного подхода), например, воспользоваться образцом проектирования Adapter для получения нового приложения из исходного путем расширения или модификации последнего (метка i на рис. 25.2).

Возможно также использование инкапсуляции, в этом случае исходное приложение практически не изменяется, новое приложение создается полностью независимо, но в процессе его выполнения вызывается функциональность унаследованного приложения. Это может осуществляться как напрямую (метка ed), так и через класс–обертку(метка ew).

 

Рисунок 25.2. Использование унаследованных приложений.

 

При сопровождении программного продукта специалистами, не участвовавшими в его разработке, важным аспектом является трудоемкость его «понимания» (понимание предметной области, архитектуры, алгоритмов работы, исходного кода). «Понимание» программных систем напрямую связано с качеством результата управления конфигурациями: если документация согласована с кодом, то необходимый анализ кода и системы в целом не будет сопряжен с большими трудозатратами.

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

Рисунок 25.3. Прослеживание требований в различных частях проекта.

 

Обеспечить прослеживание можно с помощью механизма встроенной документации, который хорошо развит, например, в Java – инструмент javadoc. Идея состоит в том, что программный код и документация к нему помещаются в один файл с использованием специального синтаксиса комментариев и специального инструмента, который извлекает комментарии и представляет их в подходящем виде.

Использование javadoc также существенно упрощает и задачу сопровождения документации в процессе разработки. Важным является тот факт, что указанный механизм не только извлекает соответствующим образом помеченную информацию, но и ставит ей в соответствие имя класса или метода. Результатом работы программы javadoc является HTML-файл, который можно просмотреть в браузере. Также имеется возможность для документирования встроить HTML-код в исходный файл таким образом, как это делается в привычных HTML-файлах.

С помощью javadoc можно внести в исходный код и получить следующую информацию о классах, переменных или методах:

- сведения об авторе;

- сведения о версии;

- информацию о том, что возвращает метод;

- информацию о параметрах метода;

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

- сведения о том, что класс или член класса является устаревшим;

- сведения о том, в каком выпуске было внесено определенное изменение.