Предсказание сопровождения (И. Соммервилл)

Изменение

предсказания

Предсказание затрат на сопровождение зависит от понимания системы и ее взаимодействия с окружением.

Тесно связанные с окружением системы требуют изменений всякий раз, когда окружение меняется.

Факторы, влияющие на такую связь:

Число и сложность системных интерфейсов

Число требований к системе, которые крайне нежелательно изменять

Характер бизнес-процессов,в которых используется система

Метрики сложности

Предсказание затрат на сопровождение может быть сделано на основе метрик сложности программы

По результатам исследований, можно утверждать, что наибольшие затраты на сопровождение выполняются в сравнительно небольшое число модулей системы

Сложность системы зависит от:

Сложности управляющей структуры

Сложности структур данных

Размера модулей системы

Метрики процесса

Для оценки затрат на сопровождение могут быть использованы метрики процесса:

Число запросов на исправления

Среднее время, затрачиваемое на анализ

Среднее время, затрачиваемое на одно исправление

Число запросов на существенные изменения

Если все эти характеристики или большинство из них увеличиваются, это может означать потерю сопровождаемости

Исследование и исправление ошибок (1/3)

База данных ошибок (Bug tracking database) – база

данных, содержащая все сообщения об

обнаруженных ошибках (bug reports). Обычно она строго конфиденциальна. Базы данных ошибок,

открытые для общего использования, доступны

только для open source и shared source - продуктов

(например, bugzilla)

Bug id – порядковый номер ошибкиSynopsis – краткое описание ошибки

Description – подробное описание ошибки

(проблемы)

Priority – приоритет, срочность ошибки;

определяется пользователем; часто понижается

менеджером продукта (с целью избежать срочных

исправлений при выпуске релиза)

Как правило,приоритет 1 означает, что ошибка весьма срочная; она должна быть исправлена не

позднее чем через неделю. Для ошибок высоких

приоритетов исправленная версия (patch) продукта

выкладывается на Web-сайт, доступный

пользователям продукта

Severity – внутренняя функциональная серьезность

ошибки

Исследование и исправление ошибок (3/3)

Стадии обработки ошибки:

- submitted (выставлена)– начальная стадия; осуществляется CTE (Customer Technical Escalations)

– инженером после обращения пользователя

- accepted (принята к рассмотрению) –

информация обработана менеджером проекта; назначен ответственный инженер для исправления

ошибки

- evaluated (исследована)– ответственный

инженер исследовал проблему и ввел в базу

данных ошибок результаты своего исследования, в частности, suggested fix (предлагаемое

исправление) в форме вставок и изменений

коокретных исходных кодов

- fixed (исправлена) – исправление ошибки выполнено, интегрировано в рабочее пространство

исходных кодов и проверено

- integrated (исправление интегрировано) –

исправление интегрировано в общее (эталонное)

пространство исходныых кодов; для ошибок

высоких приоритетов должен быть изготовлен patch продукта. Patch обычно включает не одно исправление, а все недавно сделанные исправления

ошибок высоких приоритетов

Возможные результаты обработки ошибки

Fixed/integrated/verified – исправление ошибки

интегрировано и независимо оттестировано release-

инженером

Closed because (закрыта, так как ...):

- fixed and verified (исправлена, и исправление проверено)

- ошибка является дубликатом уже известной

другой ошибки с другим bug id

- not reproducible – не воспроизводится

- will not fix (нет ресурсов для исправления ошибки); подобное решение весьма нежелательно, так как внижает репутацию разработчикаНесмотря на то, что ошибка закрыта, она все равно

остается в базе данных и при необходимости может быть вновь открыта

Совет: при сопровождении продукта не доводите

счетчик не исправленных ошибок до нуля

Исправление ошибок:

распределение ролей

Ответственный менеджер – руководитель

сопровождения продукта. Распределяет ошибки для

исправления между ответственными инженерами. Может увеличить или уменьшить приоритет ошибки

Ответственный инженер – инженер, назначенный для

исправления ошибки. Выполняет исследование

(evaluation) и исправление (fix) ошибки

Customer Technical Escalations (CTE) engineer –

инженер, ответственный за взаимодействие с

пользователями продукта в стране или регионе.

Собирает (часто неформальные) сообщения ош

ошибках в продукте от пользователей. Выставляет ошибки в базу данных ошибок. Взаимодействует с командой сопровождения продукта

Customer – пользователь. Может сам выставить ошибку в базу данных. Посылает вопросы CTE- инженеру и команде сопровождения. Скачивает и

использует патчи продукта, разработанные группой

сопровождения

Системы управления исходным

кодом (1/2)

SCCS, TeamWare (Sun), RCS, CVS, MS Visual SourceSafe,

Mercurial

Обеспечивают параллельную коллективную работу над

общим кодомИмеется интеграционное рабочее пространство

исходных кодов

Имеется песочница у каждого разработчика

SCCS: “дельты” - версии каждого исходного файла (например, mycode.c); нумеруются как M.N

Команды SCCS: info, edit, get, delta (добавление новой

дельты с комментарием)

Каждая дельта соответствует исправлению ошибки или реализации RFE (или ее части)

Не рекомендуется изменять полномочия для работы с

файлом вручную; используйте пару sccs edit / sccs delta