При этом, подчеркивает SWEBOK,
контроль сложно измерить. В свою очередь,
перед аутсоурсером (организацией, принимающей
на себя ответственность по сопровождению)
стоит серьезная проблема по определению
содержания соответствующих работ, в том
числе, для описания содержания соответствующего
контракта. Отмечается, что около 50% сервисов,
предоставляемых аутсоурсером, проводятся
без соответствующего детального и однозначно
интерпретируемого соглашения (service level
agreement, SLA). Компании, занимающиеся аутсоурсингом,
обычно затрачивают несколько месяцев
на оценку программного обеспечения прежде,
чем заключают соответствующий контракт.
Еще один вопрос, требующий специального
внимания, заключается в необходимости
определения процесса и процедур передачи
программного обеспечения на внешнее
сопровождение.
2.3 Оценка стоимости
сопровождения (Maintenance Cost Estimation)
Как уже отмечалось, инженеры должны
понимать разницу в различных
категориях сопровождения. Это, в большой
степени, необходимо для оценки соответствующих
затрат. С точки зрения планирования,
как составной части проектной
и управленческой деятельности, оценка
стоимости является важным аспектом
деятельности по сопровождению программного
обеспечения.
2.3.1 Оценка стоимости (Cost Estimation)
При обсуждении анализа влияния (см.
2.1.3 Impact Analysis) говорилось о том, что такой
анализ помогает в оценке стоимости работ
по сопровождению. На эти затраты оказывает
влияние множество технических и других
факторов. ISO/IEC 14764 (Standard for Software Engineering -
Software Maintenance)определяет, что “существует
два наиболее популярных метода оценки
стоимости сопровождения – параметрическая
модель и использование опыта”. Чаще всего,
оба этих подхода комбинируются для повышения
точности оценки.
2.3.2 Параметрические модели (Parametric
models)
SWEBOK приводит ряд источников, подробно
рассматривающих вопросы оценки
стоимости сопровождения и, в
частности, параметрические модели.
Для использования таких моделей
используются данные предыдущих
проектов. Наравне с историческими
данными используется метод функциональных
точек (см. стандарт IEEE 14143.1-00).
2.3.3 Опыт (Experience)
Среди тех подходов, которые позволяют
повысить точность оценок, полученных
при использовании параметрических
моделей – применение опыта (в
форме экспертного мнения, например,
при использовании техники оценки
“Delphi”, название которой происходит от
“делфийского оракула”), аналогий, а также
структуры декомпозиции работ. Наилучшие
результаты получаются в случае сочетания
эмпирических методов с имеющимся опытом.
Получаемые данные используются как результат
программы измерения аспектов сопровождения.
2.4 Измерения в
сопровождении программного обеспечения
(Software Maintenance Measurement)
Формы и данные измерений в процессе
сопровождения могут объединяться
в единую программу корпоративную
программу количественных оценок, проводимых
в отношении программного обеспечения.
Многие организации используют популярный
и практичный подход для измерений,
базирующийся на оценке количества проблем
и статуса их решений (issue-driven measurement).
Идеи этого подхода систематизированы
в проекте Practical Software and Systems Measurement (PSM).
Существуют общие (для всего жизненного
цикла) метрики и, соответственно, их категории,
в частности, определяемые Институтом
Программной Инженерии университета Карнеги-Меллон
(Software Engineering Institute, Carnegie-Mellon University – SEI
CMU): размер, усилия, расписание и качество.
Применение этих метрик является хорошей
отправной точкой для оценки работ со
стороны организации, отвечающей за сопровождение.
Более детальное обсуждение вопросов
измерений в отношении продуктов
и процессов представлено в области
знаний “Процесс программной инженерии
(Software Engineering Process). В свою очередь, вопросы
организации программы измерений относятся
к области знаний “Управление программной
инженерией” (Software Engineering Management).
2.4.1 Специализированные метрики
(Specific Measures)
Существуют различные методы внутренней
оценки продуктивности (benchmarking) персонала
сопровождения для сравнения работы различных
групп сопровождения. Организация, ведущая
сопровождение, должна определить метрики,
по которым будут оцениваться соответствующие
работы. Стандарты IEEE 1219 (Standard for Software Maintenance)
и ISO/IEC 9126-01 (Software Engineering – Product Quality – Part
1: Quality Model, 2001 г.) предлагают специализированные
метрики, ориентированные именно на вопросы
сопровождения и соответствующие программы.
Ниже представлены типичные метрики
оценки работ по сопровождению, соответствующих
распространенной классификации эксплуатационных
характеристик программного обеспечения:
- Анализируемость (Analyzability): оценка (в первую очередь, дополнительных) усилий или ресурсов, необходимых для диагностики недостатков или причин сбоев, а также для идентификации тех фрагментов программной системы, которые должны быть модифицированы.
- Изменяемость (Changeability): оценка усилий, необходимых для проведения заданных модификаций.
- Стабильность (Stability): оценка случаев непредусмотренного поведения системы, включая ситуации, обнаруженные в процессе тестирования.
- Тестируемость (Testability): оценка усилий персонала сопровождения и пользователей по тестированию модифицированного программного обеспечения.
3. Процесс сопровождения
(Maintenance Process)
Вопросы организации процесса сопровождения
напрямую связаны с соответствующими
стандартами и de facto практиками реализации
такого процесса. Тема “Работы по сопровождению”
(Maintenance Activities) различает вопросы сопровождения
и разработки и показывает взаимосвязь
c другими аспектами деятельности программной
инженерии.
Типичные и распространенные потребности
в процессах программной инженерии
подробно описаны и документированы
в различных источниках. Одна из
наиболее детально проработанных и
распространенных (на уровне стандарта
de facto) процессных моделей, изначально
созданных с ориентацией на программное
обеспечение – CMMI (Capability Maturity Model Integration
– интегрированная модель зрелости), разработанная
в Институте программной инженерии университета
Карнеги-Меллон (SEI CMU). CMMI, в частности,
уделяет специальное внимание процессам
сопровождения. Существуют и другие, менее
распространенные, но тем не менее развивающиеся
модели.
3.1 Процессы сопровождения
(Maintenance Processes)
Процессы сопровождения описывают
необходимые работы и детальные
входы/выходы этих работ. Эти процессы
рассматриваются в стандартах IEEE 1219 (Standard
for Software Maintenance) и ISO/IEC 14764 (Standard for Software Engineering
- Software Maintenance).
Процесс сопровождения начинается
по стандарту IEEE 1219 с момента передачи
программной системы в эксплуатацию
(post-delivery stage) и касается таких вопросов,
как планирование деятельности по сопровождению
(см. рисунок 2).
Рисунок 2. Работы в процессе
сопровождения по стандарту IEEE 1219.
Стандарт ISO/IEC 14764 уточняет положения,
связанные с процессом сопровождения,
стандарта жизненного цикла 12207. Работы
по сопровождению, описанные в этом
стандарте аналогичны работам в
IEEE 1219, за исключением того, что сгруппированы
несколько иначе (см. рисунок 3).
Рисунок 3. Процесс сопровождения
по стандарту ISO/IEC 14764.
Работы по сопровождению в стандарте
14764 разбиты на задачи:
- Process Implementation – реализация процесса
- Problem and Modification Analysis – анализ проблем и <необходимых> модификаций
- Modification Implementation –проведение модификаций (реализация изменений)
- Maintenance Review/Acceptance – оценка и принятие <проведенных работ> при сопровождении
- Migration – миграция (на модифицированную или новую версию программного обеспечения)
- Software Retirement – вывод из эксплуатации (прекращение эксплуатации программного обеспечения)
В представленных в SWEBOK источниках можно
найти описание истории эволюции
соответствующих процессных моделей
упоминаемых стандартов ISO/IEC и IEEE. Кроме
того, существует и общая (обобщенная)
модель процессов сопровождения. Agile-методологии,
активно развивающиеся в последние
годы, предлагают “облегченные” (light или
lightweight) процессы, в том числе, и для организации
деятельности по сопровождению, например,
Extreme maintenance (см. соответствующие источники,
указанные в SWEBOK).
3.2 Работы по
сопровождению (Maintenance Activities)
Как уже отмечалось, многие работы
по сопровождению похожи на аспекты
деятельности по разработке. В обоих
случаях необходимо проводить анализ,
проектирование, кодирование, тестирование
и документирование. Специалисты
по сопровождению должны отслеживать
требования так же, как и инженеры-разработчики
и обновлять документацию по мере
разработки и/или выпуска обновленных
или новых релизов продукта. Стандарт
ISO/IEC 14764 рекомендует, чтобы персонал
или организации, отвечающие за сопровождение,
в случае использования элементов
процессов разработки в своей
деятельности, адаптировали эти процессы
<целиком> в соответствии со своими
потребностями. В то же время, деятельность
по сопровождению обладает и определенными
уникальными чертами, что приводит
к необходимости использования
специализированных процессов.
3.2.1 Уникальные работы (Unique activities)
Существует ряд процессов, работ
и практик, уникальных для деятельности
по сопровождению. SWEBOK приводит следующие
примеры такого рода уникальных характеристик:
- Передача (Transition): контролируемая и координируемая деятельность по передаче программного обеспечения от разработчиков группе, службе или организации, отвечающей за дальнейшую поддержку;
- Принятие/отклонение запросов на модификацию (Modification Request Acceptance/Rejection): запросы на изменения могут как приниматься и передаваться в работу, так и отклоняться по различным обоснованным причинам – объему и/или сложности требуемых изменений, а также необходимых для этого усилий. Cоответствующие решения могут также приниматься на основе приоритетности, оценке обоснованности, отсутствии ресурсов (в том числе, отсутствия возможности привлечения разработчиков к решению задач по модификации, при реальном наличии такой потребности), утвержденной запланированности к реализации в следующем релизе и т.п.
- Средства извещения персонала сопровождения и отслеживания статуса запросов на модификацию и отчетов об ошибках (Modification Request and Problem Report Help Desk): функция поддержки конечных пользователей, инициирующая работы по оценке (assessment, подразумевая в том числе оценку необходимости), анализу приоритетности и стоимости модификаций, связанных с поступившим запросом или сообщенной проблемой.
- Анализ влияния (Impact Analysis): анализ возможных последствий изменений, вносимых в существующую систему - рассматривался выше в теме 2.1.3.
- Поддержка программного обеспечения (Software Support): работы по консультированию пользователей, проводимые в ответ на их информационные запросы (request for information), например, касающиеся соответствующих бизнес-правил (см. область знаний “Требования к программному обеспечению”), проверки, содержания данных и специфических (ad hoc) вопросов пользователей и их сообщений о проблемах (ошибках, сбоях, непредусмотренному поведению, непониманию аспектов работы с системой и т.п.).
- Контракты и обязательства: к ним относятся классическое соглашение об уровне предоставляемого сервиса - Service Level Agreement (SLA), а также другие договорные аспекты, на основании которых, группа/служба/организация по сопровождению выполняет соответствующие работы.
На практике сложно провести
грань между разделяемыми в SWEBOK функциями
Help Desk и Software Support – эти функции, обычно,
совмещены с процессной точки зрения.
3.2.2 Дополнительные работы, поддерживающие
процесс сопровождения (Support activities)
Столь длинный перевод названия
данной темы связан с содержанием
соответствующих работ, описываемых
SWEBOK, как работы персонала сопровождения,
не включающие явного взаимодействия
с пользователями, но необходимые
для осуществления соответствующей
деятельности. К таким работам
относятся: планирование сопровождения.
Конфигурационное управление (software configuration
management), проверка и аттестация (V&V – verification
and validation), оценка качества программного
обеспечения (software quality assessment), различные
аспекты обзора, анализа и оценки (reviews),
аудит (audit) и обучение (training) пользователей.
Также, к таким специальным (внутренним)
работам относится обучение персонала
сопровождения.
В силу особой значимости (с точки
зрения автора - обязательности) ряда упомянутых
работ, им посвящены следующие под-темы
данной секции области знаний по сопровождению
программного обеспечения.
3.2.3 Работы по планированию сопровождения
(Maintenance planning activity)
Планирование является более чем
необходимым для адекватного
проведения работ по сопровождению
и должно касаться связанных с
этим вопросов с нескольких точек
зрения:
- Бизнес-планирование (организационный уровень)
- Планирование непосредственных работ по сопровождению (уровень передачи программного обеспечения – см. выше 3.2.1)
- Планирование релизов/версий (уровень программного обеспечения)
- Планирование обработки конкретных запросов на изменение (уровень запроса)
На уровне индивидуального запроса,
работы по планированию проводятся вместе
с проведением анализа влияния
(см. 2.1.3). В свою очередь, планирование
релизов/версий требует от персонала сопровождения
выполнения задач:
- Получения и сбора информации о датах размещения индивидуальных запросов и отчетов
- Достижения соглашения с пользователями о содержании (функциональности, поведении и т.п.) последующих релизов/версий программного обеспечения
- Идентификации потенциальных конфликтов и возможных альтернатив <реализации необходимых запросов>
- Оценки рисков для <функционирования> текущего релиза и разработки плана “отката” на немодифицированный (текущий, до внесения изменений, касающихся рассматриваемого запроса) вариант системы, в случае возникновения проблем, связанных с модификацией
- Информирования всех заинтересованных лиц