Согласно [25] имеются следующие процессы, работы и практики, уникальные для деятельности по сопровождению:
- Передача (Transition) – контролируемая и координируемая деятельность по передаче программного обеспечения от разработчиков группе, службе или организации, отвечающей за дальнейшую поддержку.
- Принятие/отклонение запросов на модификацию (Modification Request Acceptance/Rejection) – деятельность по принятию решений о приёме и передаче в работу запросов на изменения, либо отклонении их. Такие решения могут приниматься на основе приоритетности, оценке обоснованности, отсутствии ресурсов, наличия утвержденного плана по реализации в следующей версии и т.п.
- Средства извещения персонала сопровождения и отслеживания статуса запросов на модификацию и отчетов об ошибках (Modification Request and Problem Report Help Desk) – функция поддержки конечных пользователей, инициирующая работы по оценке, анализу приоритетности и стоимости модификаций, связанных с поступившим запросом или сообщенной проблемой.
- Анализ влияния (Impact Analysis) – анализ возможных последствий изменений, вносимых в существующую систему.
- Поддержка программного обеспечения (Software Support) – работы по консультированию пользователей, проводимые в ответ на их информационные запросы, проверки содержания данных и специфических вопросов пользователей и их сообщений о проблемах (ошибках, сбоях, непредусмотренному поведению, непониманию аспектов работы с системой и т.п.).
- Контракты и обязательства, такие как соглашение об уровне предоставляемого сервиса, а также другие договорные аспекты, на основании которых, группа/служба/организация по сопровождению выполняет соответствующие работы.
Дополнительные работы, поддерживающие процесс сопровождения (Support activities)
Такие работы включают:
- планирование сопровождения;
- конфигурационное управление;
- проверка и аттестация;
- оценка качества программного обеспечения;
- различные аспекты обзора, анализа и оценки;
- аудит;
- обучение пользователей;
- обучение персонала сопровождения.
Рассмотрим подробнее каждую из этих работ:
1 Работы по планированию сопровождения
Планирование является необходимым для проведения работ по сопровождению и затрагивает связанные с этим вопросов с нескольких точек зрения:
- Бизнес-планирование (организационный уровень).
- Планирование непосредственных работ по сопровождению.
- Планирование релизов/версий (уровень программного обеспечения).
- Планирование обработки конкретных запросов на изменение (уровень запроса).
На уровне индивидуального запроса, работы по планированию проводятся вместе с проведением анализа влияния. В свою очередь, планирование релизов/версий требует от персонала сопровождения выполнения задач:
- Получения и сбора информации о датах размещения индивидуальных запросов и отчетов.
- Достижения соглашения с пользователями о содержании (функциональности, поведении и т.п.) последующих релизов/версий программного обеспечения.
- Идентификации потенциальных конфликтов и возможных альтернатив.
- Оценки рисков для функционирования текущего релиза и разработки плана «отката» на немодифицированный вариант системы, в случае возникновения проблем, связанных с модификацией.
- Информирования всех заинтересованных лиц.
Оценка ресурсов – важная неотъемлемая часть планирования. Ресурсы, необходимые для сопровождения должны быть заложены в бюджет еще при разработке системы. Планирование работ по сопровождению должно начинаться одновременно с принятием решения о создании системы и согласоваться с целями обеспечения качества (IEEE 1061-98 Standard for a Software Quality Metrics Methodology).
Началом работ по сопровождению должна явиться концепция сопровождения. Согласно стандарту ISO/IEC 14764 [10] она должна включать:
- содержания деятельности по сопровождению;
- адаптации процесса сопровождения;
- идентификации организации, которая будет заниматься сопровождением;
- оценки стоимости сопровождения.
На основе концепции деятельности по сопровождению должен быть разработан план сопровождения. Документ должен создаваться одновременно с разработкой программной системы и должен определять правила размещения пользователями своих запросов на модификацию (изменения) и сообщения об ошибках, сбоях и проблемах.
На уровне бизнес-вопросов, структура, отвечающая за сопровождение, должна проводить общую деятельность по бизнес-планированию, касающееся бюджетирования, финансового менеджмента и управления человеческими ресурсами, так же, как и любое другое (в том числе, профильное, если речь идет о потребителях ИТ) подразделение организации/компании.
2) Конфигурационное управление (Software configuration management)
Стандарт IEEE 1219, посвященный организации сопровождения программного обеспечения, определяет конфигурационное управление как критически важный элемент процесса сопровождения. Процедуры конфигурационного управления должны обеспечивать проверку, аттестацию и аудит на всех шагах, требуемых для идентификации, авторизации, реализации и выпуска программного продукта. Подробнее о конфигурационном управлении речь пойдёт в параграфе 2.6.
3) Качество программного обеспечения (Software quality)
Для поддержки процесса сопровождения должны планироваться и реализовываться соответствующие процедуры и процессы, направленные на повышение качества. Работы и техники по обеспечению качества (Software Quality Assurance, SQA), проверке и аттестации (V&V, verification and validation), обзору, анализу и оценке (review), а также аудиту, должны отбираться в контексте взаимодействия и согласования со всеми другими процессами, направленными на достижение желаемого уровня качества. Отдельно качество программного обеспечения рассмотрено в главе 4.
Методы сопровождения
Рассмотрим два наиболее распространённых методах сопровождения, применяемые сегодня на практике.
Реинжиниринг
Реинжиниринг программного обеспечения – его детальная оценка и перестройка для формирования понимания, воссоздания и дальнейшей реализации его функций в новой, более совершенной форме [25]. Как правило, реинжиниринг провидится для замены устаревшего программного обеспечения, а не для улучшения возможностей сопровождения, сколько. Реинжиниринг целесообразно рассматривать как самостоятельный проект, включающий в себя, как отмечает SWEBOK [44], формирование концепции, применение соответствующих инструментов и техник, анализ и приложения опыта проведения реинжиниринга, а также оценку рисков и преимуществ, связанных с такими работами.
Реализация продукта в новом качестве (форме) при сохранении основной функциональности оригинального продукта, является неотъемлемой и определяющей частью реинжиниринга, в отличие от обратного инжиниринга, рассматриваемого ниже и являющегося важной составной частью реинжиниринга.
Обратный инжиниринг
«Обратный» инжиниринг – это процесс анализа программного обеспечения с целью идентификации программных компонент и связей между ними, а также формирования представления о программном обеспечении, с дальнейшей перестройкой в новой форме. Обратный инжиниринг является пассивным, предполагая отсутствие деятельности по изменению или созданию нового программного обеспечения. Обычно, в результате усилий по обратному инжинирингу создаются модели вызовов и потоков управления на основе исходного кода системы. Примерами обратного инжиниринга являются:
- создание новой документации на существующую систему;
- восстановление дизайна системы и т.п.
К вопросам обратного инжиниринга, как и к вопросам реинжиниринга, также относятся работы по рефакторингу [41].
Рефакторинг – трансформация программного обеспечения, в процессе которой программная система реорганизуется (не переписываясь) с целью улучшения структуры, без изменения поведения. Сохранение «формы» (платформы, архитектурных и технологических решений) существующей программной системы позволяет рассматривать рефакторинг как один из вариантов обратного инжиниринга.
С точки зрения [7] и для реинжиниринга и для обратного инжиниринга возможно применение слова реконструкция, в зависимости от контекста, означающее как полную перестройку или воссоздание чего-либо, идентичного по определенным характеристикам оригинальному образцу, так и восстановление какой-либо сущности по сохранившимся и/или доступным внешним признакам, где восстановление может подразумевать опять-таки создание нового образца или представления об оригинальной сущности.
Конфигурационное управление
Работы по конфигурационному управлению программного обеспечения включают: управление и планирование процессов управления конфигурацией ПО (SCM), идентификацию программных конфигураций, контроль конфигураций, учет статусов конфигураций, аудит, а также управление выпуском (release management) и поставкой (delivery).
Управление конфигурацией связано с всеми областями знаний в программной инженерии, так как объектами её приложения являются все компоненты продукта, создаваемые и используемые в процессах программной инженерии.
Конфигурация системы – функциональные и/или физические характеристики аппаратного, программно-аппаратного, программного обеспечения или их комбинации, сформулированные в технической документации и реализованные в продукте.