Формальные инспекции на практике Вадим Савкин vsavkin.livejournal.com

2 Содержание Проблема качества ПО Понятие формальных инспекций Опыт применения инспекций в CQG Особенности процесса инспекций в CQG Метрики процесса инспекций Контроль процесса инспекций Что необходимо, чтобы инспекции были эффективными

3 Проблема качества ПО Качество ПО Тестирование ПО Качество ПО = Весь процесс разработки ориентирован на качество с ранних этапов Инспекции = контроль качества на ранних этапах

4 Формальные инспекции - это проверка разрабатываемых артефактов коллегами, проводимая согласно строгому формальному процессу

5 Эффективность поиска дефектов Метод поиска ЭПД % Метод поиска ЭПД % Неформальный обзор дизайна 35%Тестирование новой функции (компонента) 30% Формальные инспекции дизайна 55%Интеграционное тестирование 35% Неформальный обзор кода (code review) 25%Регрессионное тестирование 25% Формальные инспекции кода 60%Системное тестирование 40% Моделирование и прототипирование 65%Бета-тестирование (1000 тестеров) 75%

6 Данные компании CQG Этап % найденных дефектов Плотность дефектов (#/ KLOC) Формальные инспекции 59%2.03 Интеграционное тестирование 23%0.78 Системное тестирование 11%0.36 Релиз тестирование 4%0.15 Пост-релиз 3%0.12

7 О компании CQG Компания CQG является поставщиком данных и сервисов для биржевой торговли на основе разрабатываемых в компании программных систем. Компания CQG является поставщиком данных и сервисов для биржевой торговли на основе разрабатываемых в компании программных систем. Штат департамента разработки насчитывает порядка 300 сотрудников, распределённых между 6 офисами в разных странах. Штат департамента разработки насчитывает порядка 300 сотрудников, распределённых между 6 офисами в разных странах. Разработчики объединены в команды размером от 3 до 7 человек каждая. Разработчики объединены в команды размером от 3 до 7 человек каждая.

8 Важность инспекций в CQG Инспекции применяются > 6 лет Рассматриваются как основной инструмент обеспечения качества разрабатываемого ПО Уделяется большое внимание контролю эффективности инспекций Процесс инспекций немного отличается от классического

9 Роли процесса инспекций Автор – тот, чей артефакт подвергается инспекции. Инспектор – тот, кто проверяет качество этого артефакта. Инспекторов может быть несколько. Модератор – тот, кто контролирует качество проведения конкретной инспекции и разрешает споры между автором и инспекторами. Один из инспекторов.

10 Процесс инспекций (workflow) Автор Инспектор

11 Типы обнаруживаемых замечаний Вопрос – недопонимание со стороны инспектора, никаких изменений в артефакт не вносится. Нефункциональный дефект – дефект в артефакте, который не приведёт к неправильной работе программной системы. Функциональный дефект – дефект в артефакте, который может привести к неправильной работе программной системы. Дубликат – точно такое же замечание было высказано другим инспектором.

12 Приоритет инспекций Инспекциям при равных условиях отдаётся больший приоритет Ограничения на длительность: Инспектор обязан проинспектировать в течение 2 дней Весь процесс инспекции не должен превышать 4 дня Для высокоприоритетных инспекций лимиты в 2 раза меньше

13 Инструментальная поддержка инспекций В CQG все данные об инспекциях регистрируются в специальном инструменте для командной работы: Тип и название инспектируемого артефакта; Проект и задача, к которым относится инспекция; Участники инспекции; Размер инспектируемого артефакта; Найденные замечания (с классификацией по типам); Время, потраченное инспекторами, в минутах.

14 Метрики инспекций Скорость инспектирования (checking rate), измеряемая в числе строк кода в час. Плотность найденных замечаний (issue density), измеряемая в числе замечаний на 1000 строк кода. Процент дефектов от общего числа найденных замечаний. Процент покрытия кода инспекциями.

15 Метрики инспекций – демо - 1

16 Метрики инспекций – демо - 2

17 Метрики инспекций – демо - 3

18 Контроль процесса инспекций - 1 Все необходимые данные об инспекции должны быть введены в инструмент автоматизации. Каждое изменение кода объёмом более 20 строк должно быть проинспектировано. Число инспекторов не должно быть меньше 2-х. Размер инспекции не должен превышать 1000 строк кода (чем больше артефакт, тем, как правило, менее тщательно он инспектируется, см. рис. 2).

19 Зависимость плотности найденных дефектов от размера кода

20 Контроль процесса инспекций - 2 Скорость инспектирования не должна превышать 500 строк кода в час (скорость напрямую характеризует тщательность проверки, см. рис. 3). Плотность замечаний не должна быть ниже 10 замечаний на 1000 строк кода (в противном случае велика вероятность, что инспекция сделана плохо, особенно если и скорость инспектирования была высокой). Длительность инспекций должна быть в заданных пределах (4 и 2 дня).

21 Зависимость плотности найденных дефектов от скорости инспектирования

22 Инструмент контроля процесса инспекций - демо

23 Стоимость процесса инспекций (данные компании CQG) Время инспектирования в среднем занимает 8% от всего времени, затрачиваемого на разработку Средняя стоимость поиска и исправления одного дефекта Инспекции9 чел-часов Интеграционное тестирование21 чел-час Системное тестирование34 чел-часа

24 Заключение Грамотно организованный процесс формальных инспекций – эффективное средство повышения качества Формальные инспекции значительно эффективнее тестирования

25 Необходимые меры - 1 Инспекции должны быть обязательными для всех жизненно важных артефактов разработки. Разработчики должны понимать важность и необходимость инспекций для обеспечения высокого качества разрабатываемых ими продуктов. Приоритет инспекций должен рассматриваться инспекторами как более высокий, чем приоритет их собственных задач.

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

27 Вопросы? Вадим Савкин