SlideShare a Scribd company logo
1 of 34
Количественное управление
  процессом тестирования
 Александр Александров, Анатолий Галай, Ясна Милькова
                      Люксофт
Содержание
• Анализ современных методов количественного и статистического
  управления процессами разработки программного обеспечения
   – Количественное и статистическое управление в CMMI
   – Метрики в проектах
   – Определение возможностей процесса (Process capability
     Baseline)
   – Статистический анализ в проекте и количественное
     управление (на примере процесса тестирования и метрики
     плотность дефектов)
• Методы анализа данных
   – Метод прогнозирования количества дефектов, которые будут
     обнаружены заказчиком при эксплуатации программного
     продукта
   – Метод интерпретации количественных результатов аудитов
     проектов
• Среда визуализации данных количественного управления проектами-
  Quantitative Dashboard (QD)
Cтатистическое управление
•   Статистическое управление (SPC) – это использование
    статистических методов для обработки и оценки результатов
    измерений параметров процессов в проекте.
•   В результате применения таких методов становится возможным:
         • определять границы, в которых могут находиться
           значения параметра, если подпроцесс выполняется
           штатно (т.е. предсказывать значение параметра
           подпроцесса),
         • определять значения контролируемого параметра,
           которые являются следствием воздействия каких-то
           особенных (одномоментных) причин.
Последовательность
  проведения SPC
Количественное
                         управление
•   Количественное управление (QPC) – это процесс использования
    данных проектных измерений, обработанных с помощью
    статистического управления подпроцессами (или каких-то других
    методов) для:
         • определения того, обеспечат ли текущие значения
           параметра процесса выполнение требований к нему в
           конце проекта,
         • если текущие результаты не дают уверенности в
           выполнении конечных требований, то определение
           корректирующих действий, которые должны быть
           предприняты для обеспечения достижения
           установленных целей,
         • последующего контроля эффективности предпринятых
           мер.
Последовательность
 проведения QPC
Метрики в проектах (ключевые)

•   Производительность кодирования команды,
•   Плотность дефектов до поставки,
•   Плотность дефектов после поставки,
•   Индекс отклонения от календарного плана(SPI),
•   Индекс отклонения трудозатрат (CPI),
•   Общие удельные трудозатраты (Development
    efficiency).
Процесс измерения проектов

•   Определить набор метрик, которые интересуют организацию
•   Дать однозначные определения всем метрикам
•   Определить круг инструментов, с помощью которых можно
    получать эти метрики воспроизводимо и однозначно
•   Собрать историческую информацию по этим метрикам
•   Статистически ее обработать, в результате чего разработать PCB
•   Ставить количественные цели для процессов (подпроцессов)
•   На регулярной основе проводить мониторинг метрик
•   Анализировать метрики
•   Регулярно пересматривать PCB (если необходимо) в разумные
    периоды времени (например, ежегодно) для постановки новых
    количественных целей либо при изменении процесса
Границы возможностей процесса
          (Process Capability Baseline)
•   Цели создания PCB:
     – Накопление истории
       измерений
     – Определение
       возможностей процесса
     – Основа для
       прогнозирования
       возможностей процесса
•   PCB в Люксофте
     – Основана на бизнес-
       целях компании
     – Ежегодно
       актуализируется
Выбор подпроцессов для
              управления (1)
• Желательно, чтобы выбранный подпроцесс был
  одним из основных подпроцессов жизненного цикла

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

    Как правило, подпроцесс тестирования отвечает вышеприведенным
    критериям.
Выбор подпроцессов для
                       управления (3)
Процесс нестабильный ─ управлять нельзя
Необходимы корректирующие действия
Причины нестабильности
                 процесса




Причины                   Примеры коррекции

Низкая квалификация       Обучение
персонала
Нарушение требований      Внеочередные аудиты качества
процессов                 и эскалация проблем
Отсутствие поставленных   Постановка процессов
процессов
…………….                    …………….
Критерии выбора метрик
•   Выбранные метрики должны отражать главные, ключевые
    характеристики процесса
•   Выбранные метрики должны отражать выполнение как минимум
    одной из целей проекта
•   Метрики должны быть самым полным образом определены,
    должно быть ясно, каким образом метрики будут собираться и
    вычисляться
•   Метрики должны позволять использование статистических
    методов для их анализа
Метрики в тестировании
•   Плотность дефектов (SDD = Число дефектов / Размер кода)
•   Плотность дефектов после поставки (PDDD = Число дефектов после
    поставки / Размер кода)
•   Доля отклоненных дефектов (DDR = Число отклоненных дефектов /
    Число дефектов )
•   «Убойность» тестов (DP = Число дефектов / Число тестов)
•   Эффективность тестирования (TE = Число дефектов / Трудозатраты
    тестирования)
•   Доля покрытия требований (RCR = Число требований, покрытых
    тестами / Число требований)
•   Плотность покрытия требований (RCD = Число тестов / Число
    требований)
•   Доля повторно открытых дефектов (RDR = Число повторно открытых
    дефектов / Число дефектов )
•   И много-много других …
Выбор аналитических техник.
 Контрольные карты XmR (1)
Выбор аналитических техник.
               Контрольные карты XmR (2)
• XmR chart (контрольные карты) - это массив данных, где
  точки располагаются в хронологическом порядке
• XmR chart включает 2 вида диаграмм:
   – Individual - контрольная карта размаха (массив
      измеряемых данных, где точки располагаются в
      хронологическом порядке)
   – Moving Range - контрольная карта скользящего
      размаха (массив данных сдвига между двумя точками
      измерений)


• UCL - верхняя контрольная граница
• CL - среднее
• LCL - нижняя контрольная граница
Сбор выбранных метрик и
                        статистическая обработка
                               результатов
• Измерения по установленным правилам
• Расчет на основе производных метрик, которые
  впоследствии подвергаются статистическому анализу
• Расчет среднего значения и границ верхнего и нижнего
  пределов при получении каждого нового значения метрики
• Отображение полученных результатов на контрольной
  карте и анализ стабильности процессов на их основе

•   Последние два действия могут выполняться с
    помощью специальных программных
    инструментов, реализующих алгоритм расчета
    контрольных карт.

•   Нами разработан инструмент для расчета и
    вывода на диаграмму параметров исследуемых
    метрик по алгоритму XmR
Определение особых
                         случаев (1)
Особый случай – это попадание
значения контролируемой метрики за
пределы границ, вычисленных с
помощью контрольной карты или
«особое», необычное поведение
последовательности значений метрики,
свидетельствующее о ее неслучайном
поведении.




Число значений <3

Особые случаи не
определяются
Определение особых
                         случаев (2)
Число значений от 3 до 29
(фаза накопления данных)

Наш опыт говорит о том, что
что «кандидатом» на особый
случай является выход
значения за ±2G




Число значений >29 (фаза
полноценного SPC)

Используется канонический
способ определения особых
случаев (> ±3G)
Причины особых случаев и
                их устранение
При расчете новых границ и среднего значения контролируемого
параметра процесса использовать значение особого случая нельзя (если
причина особого случая выявлена и устранена), т.к. в противном случае
мы получим неоправданно широкие возможные границы параметра




                •   Поиск причин особых случаев
                •   Принятие мер по их недопущению в будущем
                •   Понимание того, что причина, приведшая к особому
                    случаю, есть следствие неуправляемых событий
                    или свершившихся рисков, которые наступили и
                    больше не ожидаются
Количественное
                       управление
•   Вычисленные ранее естественные границы процесса (process
    capability, или голос процесса) на этом шаге сравниваются с
    установленными целями по значению контролируемого
    параметра (objectives, или голос заказчика).
•   Если голос процесса удовлетворяет голосу заказчика, то ничего
    предпринимать не надо
•   Если же нет, то необходимо выработать меры по согласованию
    process capability и customer voice.

    Меры могут быть следующие:
•   Изменение по согласованию с
    заказчиком установленных целей
•   Улучшение выполнения
    существующего процесса для
    уменьшения размаха process capability
•   Введение новых процессных
    элементов, которые могут обеспечить
    нужные значения контролируемого
    параметра процесса
Пример распределения
           метрики SDD (1)
Параметры процесса не обеспечивают полностью достижение
проектной цели




               Корректирующие действия
Причины выхода за “голос
                  заказчика”


Причины                         Примеры коррекции

Слабая квалификация             Обучение, замена
разработчиков
Высокие требования заказчика    Договориться о снижении
                                требований, повысить показатели
Высокое качество тестирования   Не требуется дополнительных
                                действий
Отсутствие анализа кода         Внедрить анализ кода или любое
                                дополнительное статическое
                                тестирование - peer review
                                объектов
……………..                         ……………..
Пример распределения
               метрики SDD (2)
Параметры процесса (при гарантии его неизменности) с вероятностью
около 100% обеспечивают достижение проектной цели
Преимущества использования
                           SPC
•   Проактивный подход- своевременно предпринимаются
    корректирующие/ предупреждающие действия
•   Импульс для улучшения процесса
•   После внесения изменений в процесс, можно объективно оценить,
    стал ли процесс “лучше” или “хуже”
•   Возможность прогнозирования конечного результата
Корреляция метрик
Примеры пар метрик, корреляцию которых организации может быть
полезно получать:
     • плотность дефектов после передачи программного продукта в
       Production и плотность дефектов до передачи программного
       продукта в Production
     • высокие оценки качества проектных аудитов и признание
       заказчиком проекта как успешного

Корреляция метрик помогает на более раннем этапе проекта выявить
проблемы и предпринять корректирующие действия
Корреляция метрик-
прогнозирование результата (1)
Корреляция метрик-
         прогнозирование результата (2)

•   Параметр r (множественный коэффициент корреляции/
    множественное r/ коэффициент корреляции Пирсона) –
    характеризует тесноту связи между зависимой
    переменной и предиктором
•   Параметр r2 (квадрат множественного коэффициента
    корреляции/ множественный коэффициент
    детерминации) – коэффициент, показывающий, какая
    доля дисперсии результативного признака объясняется
    влиянием независимых переменных
•   Параметр Р – статистическая значимость коэффициента
    корреляции (например, для уровня значимости 0.05
    вероятность ошибки 5 %)
•   Проведенная прямая называется прямой регрессии или
    прямой, построенной методом наименьших квадратов
Количественное управление
            результатами аудитов
Позволяет продемонстрировать:
• Оценку качества выполнения проекта в целом
• Текущую оценку проекта
Quantitative Dashboard (1)




Главное меню              Массив данных

          Особый случай
Quantitative Dashboard (2)




Пример построения контрольной карты
Quantitative Dashboard (3)




Пример распределения сдвига
значений (Moving range)       Пример гистограммы
Спасибо за внимание!

     Вопросы?

More Related Content

What's hot

Хозяйственная жизнь и политическая карта Азии в Средневековье
Хозяйственная жизнь и политическая карта Азии в СредневековьеХозяйственная жизнь и политическая карта Азии в Средневековье
Хозяйственная жизнь и политическая карта Азии в СредневековьеПётр Ситник
 
анализ турбобуров
анализ турбобурованализ турбобуров
анализ турбобуровgafar87
 
Политические партии
Политические партииПолитические партии
Политические партииПётр Ситник
 
viral manual for newbies
viral manual for newbiesviral manual for newbies
viral manual for newbiesGoodKarma.me
 
Инструкция для родителей
Инструкция для родителейИнструкция для родителей
Инструкция для родителейguest1817f0
 
Школе 52 — 50 лет (история школы в истории страны)
Школе 52 — 50 лет (история школы в истории страны) Школе 52 — 50 лет (история школы в истории страны)
Школе 52 — 50 лет (история школы в истории страны) Denis Bavykin
 
Devby Sef Presentation
Devby Sef PresentationDevby Sef Presentation
Devby Sef Presentationsef2009
 
Идеологическое разнообразие современности
Идеологическое разнообразие современностиИдеологическое разнообразие современности
Идеологическое разнообразие современностиПётр Ситник
 
Ивелина Атанасова - Генчев - DigitalKidZ #6
Ивелина Атанасова - Генчев - DigitalKidZ #6Ивелина Атанасова - Генчев - DigitalKidZ #6
Ивелина Атанасова - Генчев - DigitalKidZ #6Ivelina Atanasova - Genchev
 
Career Development в Epam Systems
Career Development в Epam SystemsCareer Development в Epam Systems
Career Development в Epam Systemssef2009
 
вопросы
вопросывопросы
вопросыsef2009
 
тезисы каганова исследование_школьных_программ_по_литературе
тезисы каганова исследование_школьных_программ_по_литературетезисы каганова исследование_школьных_программ_по_литературе
тезисы каганова исследование_школьных_программ_по_литературеНаталья Тарасова
 
Общественные объединения
Общественные объединенияОбщественные объединения
Общественные объединенияПётр Ситник
 
ХМАО - "Портал государственных и муниципальных услуг – региональный компоне...
ХМАО - "Портал  государственных и муниципальных услуг – региональный компоне...ХМАО - "Портал  государственных и муниципальных услуг – региональный компоне...
ХМАО - "Портал государственных и муниципальных услуг – региональный компоне...Victor Gridnev
 
Подсистема криптографической защиты информации
Подсистема криптографической защиты информацииПодсистема криптографической защиты информации
Подсистема криптографической защиты информацииSQALab
 

What's hot (20)

Хозяйственная жизнь и политическая карта Азии в Средневековье
Хозяйственная жизнь и политическая карта Азии в СредневековьеХозяйственная жизнь и политическая карта Азии в Средневековье
Хозяйственная жизнь и политическая карта Азии в Средневековье
 
анализ турбобуров
анализ турбобурованализ турбобуров
анализ турбобуров
 
Политические партии
Политические партииПолитические партии
Политические партии
 
viral manual for newbies
viral manual for newbiesviral manual for newbies
viral manual for newbies
 
John 21
John 21John 21
John 21
 
Инструкция для родителей
Инструкция для родителейИнструкция для родителей
Инструкция для родителей
 
Школе 52 — 50 лет (история школы в истории страны)
Школе 52 — 50 лет (история школы в истории страны) Школе 52 — 50 лет (история школы в истории страны)
Школе 52 — 50 лет (история школы в истории страны)
 
Devby Sef Presentation
Devby Sef PresentationDevby Sef Presentation
Devby Sef Presentation
 
Идеологическое разнообразие современности
Идеологическое разнообразие современностиИдеологическое разнообразие современности
Идеологическое разнообразие современности
 
Ивелина Атанасова - Генчев - DigitalKidZ #6
Ивелина Атанасова - Генчев - DigitalKidZ #6Ивелина Атанасова - Генчев - DigitalKidZ #6
Ивелина Атанасова - Генчев - DigitalKidZ #6
 
Career Development в Epam Systems
Career Development в Epam SystemsCareer Development в Epam Systems
Career Development в Epam Systems
 
LED light
LED lightLED light
LED light
 
вопросы
вопросывопросы
вопросы
 
тезисы каганова исследование_школьных_программ_по_литературе
тезисы каганова исследование_школьных_программ_по_литературетезисы каганова исследование_школьных_программ_по_литературе
тезисы каганова исследование_школьных_программ_по_литературе
 
Общественные объединения
Общественные объединенияОбщественные объединения
Общественные объединения
 
Kanberra
KanberraKanberra
Kanberra
 
ХМАО - "Портал государственных и муниципальных услуг – региональный компоне...
ХМАО - "Портал  государственных и муниципальных услуг – региональный компоне...ХМАО - "Портал  государственных и муниципальных услуг – региональный компоне...
ХМАО - "Портал государственных и муниципальных услуг – региональный компоне...
 
Presentation1
Presentation1Presentation1
Presentation1
 
Njvosib Doroi
Njvosib DoroiNjvosib Doroi
Njvosib Doroi
 
Подсистема криптографической защиты информации
Подсистема криптографической защиты информацииПодсистема криптографической защиты информации
Подсистема криптографической защиты информации
 

Viewers also liked

25.04.09 Sidorov
25.04.09 Sidorov25.04.09 Sidorov
25.04.09 Sidorovsef2009
 
Sef Sivakou Prezentacia
Sef Sivakou PrezentaciaSef Sivakou Prezentacia
Sef Sivakou Prezentaciasef2009
 
персональные риски аналитика
персональные риски аналитикаперсональные риски аналитика
персональные риски аналитикаsef2009
 
25.04.09 Sidorov
25.04.09 Sidorov25.04.09 Sidorov
25.04.09 Sidorovsef2009
 
ксуп кейс
ксуп кейсксуп кейс
ксуп кейсsef2009
 
риски тестирования
риски тестированияриски тестирования
риски тестированияsef2009
 
Minsk Overview 190509 Tmpl
Minsk Overview 190509 TmplMinsk Overview 190509 Tmpl
Minsk Overview 190509 Tmplsef2009
 
Hienadz Drahun Ui Design At Epam
Hienadz Drahun    Ui Design At EpamHienadz Drahun    Ui Design At Epam
Hienadz Drahun Ui Design At Epamsef2009
 
Sef Sivakou Tezisy
Sef Sivakou TezisySef Sivakou Tezisy
Sef Sivakou Tezisysef2009
 
Mordovich Proto Presentation
Mordovich Proto PresentationMordovich Proto Presentation
Mordovich Proto Presentationsef2009
 
александров обучение в сфере Software Engineering
александров   обучение в сфере Software Engineeringалександров   обучение в сфере Software Engineering
александров обучение в сфере Software Engineeringsef2009
 
Amayorov Hindex
Amayorov HindexAmayorov Hindex
Amayorov Hindexsef2009
 
Sef презентация
Sef презентацияSef презентация
Sef презентацияsef2009
 
козюминский в.д. презентация доклада
козюминский в.д.  презентация докладакозюминский в.д.  презентация доклада
козюминский в.д. презентация докладаsef2009
 
блинов Java Belarus 2009
блинов   Java Belarus 2009блинов   Java Belarus 2009
блинов Java Belarus 2009sef2009
 
Sef Sivakou Doklad
Sef Sivakou DokladSef Sivakou Doklad
Sef Sivakou Dokladsef2009
 
Sef 2009
Sef 2009Sef 2009
Sef 2009sef2009
 
Content Migration Framework
Content Migration FrameworkContent Migration Framework
Content Migration Frameworksef2009
 

Viewers also liked (20)

25.04.09 Sidorov
25.04.09 Sidorov25.04.09 Sidorov
25.04.09 Sidorov
 
Sef Sivakou Prezentacia
Sef Sivakou PrezentaciaSef Sivakou Prezentacia
Sef Sivakou Prezentacia
 
персональные риски аналитика
персональные риски аналитикаперсональные риски аналитика
персональные риски аналитика
 
25.04.09 Sidorov
25.04.09 Sidorov25.04.09 Sidorov
25.04.09 Sidorov
 
ксуп кейс
ксуп кейсксуп кейс
ксуп кейс
 
риски тестирования
риски тестированияриски тестирования
риски тестирования
 
Minsk Overview 190509 Tmpl
Minsk Overview 190509 TmplMinsk Overview 190509 Tmpl
Minsk Overview 190509 Tmpl
 
Hienadz Drahun Ui Design At Epam
Hienadz Drahun    Ui Design At EpamHienadz Drahun    Ui Design At Epam
Hienadz Drahun Ui Design At Epam
 
Sef Sivakou Tezisy
Sef Sivakou TezisySef Sivakou Tezisy
Sef Sivakou Tezisy
 
Mordovich Proto Presentation
Mordovich Proto PresentationMordovich Proto Presentation
Mordovich Proto Presentation
 
александров обучение в сфере Software Engineering
александров   обучение в сфере Software Engineeringалександров   обучение в сфере Software Engineering
александров обучение в сфере Software Engineering
 
Amayorov Hindex
Amayorov HindexAmayorov Hindex
Amayorov Hindex
 
Sef презентация
Sef презентацияSef презентация
Sef презентация
 
козюминский в.д. презентация доклада
козюминский в.д.  презентация докладакозюминский в.д.  презентация доклада
козюминский в.д. презентация доклада
 
7) Esercitazione Guidata Railsassemblare Le Pagine
7) Esercitazione Guidata Railsassemblare Le Pagine7) Esercitazione Guidata Railsassemblare Le Pagine
7) Esercitazione Guidata Railsassemblare Le Pagine
 
Sef
SefSef
Sef
 
блинов Java Belarus 2009
блинов   Java Belarus 2009блинов   Java Belarus 2009
блинов Java Belarus 2009
 
Sef Sivakou Doklad
Sef Sivakou DokladSef Sivakou Doklad
Sef Sivakou Doklad
 
Sef 2009
Sef 2009Sef 2009
Sef 2009
 
Content Migration Framework
Content Migration FrameworkContent Migration Framework
Content Migration Framework
 

More from sef2009

технопарк бнту метолит
технопарк бнту метолиттехнопарк бнту метолит
технопарк бнту метолитsef2009
 
распознавание для Web
распознавание для Webраспознавание для Web
распознавание для Websef2009
 
Sef Kolotygin.V4
Sef Kolotygin.V4Sef Kolotygin.V4
Sef Kolotygin.V4sef2009
 
Sef 2009 Itsm
Sef 2009 ItsmSef 2009 Itsm
Sef 2009 Itsmsef2009
 
21 05 2009 Grigorash Surova Sef
21 05 2009 Grigorash Surova Sef21 05 2009 Grigorash Surova Sef
21 05 2009 Grigorash Surova Sefsef2009
 
якимович нагрузочное тестирование клиент серверных приложений
якимович нагрузочное тестирование клиент серверных приложенийякимович нагрузочное тестирование клиент серверных приложений
якимович нагрузочное тестирование клиент серверных приложенийsef2009
 
технологии качества возврат инвестиций
технологии качества   возврат инвестицийтехнологии качества   возврат инвестиций
технологии качества возврат инвестицийsef2009
 
интеграция приложений
интеграция приложенийинтеграция приложений
интеграция приложенийsef2009
 
Sef Trubach V1.2
Sef Trubach V1.2Sef Trubach V1.2
Sef Trubach V1.2sef2009
 
Sef Tech Customer Bezugliy Presentation
Sef Tech Customer Bezugliy PresentationSef Tech Customer Bezugliy Presentation
Sef Tech Customer Bezugliy Presentationsef2009
 
Sef Streluk Agile
Sef Streluk AgileSef Streluk Agile
Sef Streluk Agilesef2009
 
Sef Req Elicitation Baikin
Sef Req Elicitation BaikinSef Req Elicitation Baikin
Sef Req Elicitation Baikinsef2009
 
Sef Ikhelis
Sef IkhelisSef Ikhelis
Sef Ikhelissef2009
 

More from sef2009 (15)

технопарк бнту метолит
технопарк бнту метолиттехнопарк бнту метолит
технопарк бнту метолит
 
распознавание для Web
распознавание для Webраспознавание для Web
распознавание для Web
 
Sef Kolotygin.V4
Sef Kolotygin.V4Sef Kolotygin.V4
Sef Kolotygin.V4
 
Sef 2009 Itsm
Sef 2009 ItsmSef 2009 Itsm
Sef 2009 Itsm
 
21 05 2009 Grigorash Surova Sef
21 05 2009 Grigorash Surova Sef21 05 2009 Grigorash Surova Sef
21 05 2009 Grigorash Surova Sef
 
якимович нагрузочное тестирование клиент серверных приложений
якимович нагрузочное тестирование клиент серверных приложенийякимович нагрузочное тестирование клиент серверных приложений
якимович нагрузочное тестирование клиент серверных приложений
 
технологии качества возврат инвестиций
технологии качества   возврат инвестицийтехнологии качества   возврат инвестиций
технологии качества возврат инвестиций
 
интеграция приложений
интеграция приложенийинтеграция приложений
интеграция приложений
 
Sef Trubach V1.2
Sef Trubach V1.2Sef Trubach V1.2
Sef Trubach V1.2
 
Sef Tech Customer Bezugliy Presentation
Sef Tech Customer Bezugliy PresentationSef Tech Customer Bezugliy Presentation
Sef Tech Customer Bezugliy Presentation
 
Sef Streluk Agile
Sef Streluk AgileSef Streluk Agile
Sef Streluk Agile
 
Sef2009
Sef2009Sef2009
Sef2009
 
Sef Req Elicitation Baikin
Sef Req Elicitation BaikinSef Req Elicitation Baikin
Sef Req Elicitation Baikin
 
Sef Ikhelis
Sef IkhelisSef Ikhelis
Sef Ikhelis
 
Sef2009
Sef2009Sef2009
Sef2009
 

Alexandrov Alex Quality

  • 1. Количественное управление процессом тестирования Александр Александров, Анатолий Галай, Ясна Милькова Люксофт
  • 2. Содержание • Анализ современных методов количественного и статистического управления процессами разработки программного обеспечения – Количественное и статистическое управление в CMMI – Метрики в проектах – Определение возможностей процесса (Process capability Baseline) – Статистический анализ в проекте и количественное управление (на примере процесса тестирования и метрики плотность дефектов) • Методы анализа данных – Метод прогнозирования количества дефектов, которые будут обнаружены заказчиком при эксплуатации программного продукта – Метод интерпретации количественных результатов аудитов проектов • Среда визуализации данных количественного управления проектами- Quantitative Dashboard (QD)
  • 3. Cтатистическое управление • Статистическое управление (SPC) – это использование статистических методов для обработки и оценки результатов измерений параметров процессов в проекте. • В результате применения таких методов становится возможным: • определять границы, в которых могут находиться значения параметра, если подпроцесс выполняется штатно (т.е. предсказывать значение параметра подпроцесса), • определять значения контролируемого параметра, которые являются следствием воздействия каких-то особенных (одномоментных) причин.
  • 5. Количественное управление • Количественное управление (QPC) – это процесс использования данных проектных измерений, обработанных с помощью статистического управления подпроцессами (или каких-то других методов) для: • определения того, обеспечат ли текущие значения параметра процесса выполнение требований к нему в конце проекта, • если текущие результаты не дают уверенности в выполнении конечных требований, то определение корректирующих действий, которые должны быть предприняты для обеспечения достижения установленных целей, • последующего контроля эффективности предпринятых мер.
  • 7. Метрики в проектах (ключевые) • Производительность кодирования команды, • Плотность дефектов до поставки, • Плотность дефектов после поставки, • Индекс отклонения от календарного плана(SPI), • Индекс отклонения трудозатрат (CPI), • Общие удельные трудозатраты (Development efficiency).
  • 8. Процесс измерения проектов • Определить набор метрик, которые интересуют организацию • Дать однозначные определения всем метрикам • Определить круг инструментов, с помощью которых можно получать эти метрики воспроизводимо и однозначно • Собрать историческую информацию по этим метрикам • Статистически ее обработать, в результате чего разработать PCB • Ставить количественные цели для процессов (подпроцессов) • На регулярной основе проводить мониторинг метрик • Анализировать метрики • Регулярно пересматривать PCB (если необходимо) в разумные периоды времени (например, ежегодно) для постановки новых количественных целей либо при изменении процесса
  • 9. Границы возможностей процесса (Process Capability Baseline) • Цели создания PCB: – Накопление истории измерений – Определение возможностей процесса – Основа для прогнозирования возможностей процесса • PCB в Люксофте – Основана на бизнес- целях компании – Ежегодно актуализируется
  • 10. Выбор подпроцессов для управления (1) • Желательно, чтобы выбранный подпроцесс был одним из основных подпроцессов жизненного цикла Основные процессы– это процессы, определяющие основные результаты деятельности компании. Для идентификации основных процессов применяются следующие критерии: – стратегическое значение, – создание воспринимаемой Заказчиками пользы, – ориентация на Заказчика.
  • 11. Выбор подпроцессов для управления (2) • Важно, чтобы во время выполнения проекта количество моментов времени для корректного измерения параметров процессов, подлежащих статистическому управлению, было достаточно большим • Подпроцесс, выбираемый для статистического управления, должен иметь достаточно стабильные значения характеризующих его параметров при выполнении данного подпроцесса по установленным правилам Как правило, подпроцесс тестирования отвечает вышеприведенным критериям.
  • 12. Выбор подпроцессов для управления (3) Процесс нестабильный ─ управлять нельзя Необходимы корректирующие действия
  • 13. Причины нестабильности процесса Причины Примеры коррекции Низкая квалификация Обучение персонала Нарушение требований Внеочередные аудиты качества процессов и эскалация проблем Отсутствие поставленных Постановка процессов процессов ……………. …………….
  • 14. Критерии выбора метрик • Выбранные метрики должны отражать главные, ключевые характеристики процесса • Выбранные метрики должны отражать выполнение как минимум одной из целей проекта • Метрики должны быть самым полным образом определены, должно быть ясно, каким образом метрики будут собираться и вычисляться • Метрики должны позволять использование статистических методов для их анализа
  • 15. Метрики в тестировании • Плотность дефектов (SDD = Число дефектов / Размер кода) • Плотность дефектов после поставки (PDDD = Число дефектов после поставки / Размер кода) • Доля отклоненных дефектов (DDR = Число отклоненных дефектов / Число дефектов ) • «Убойность» тестов (DP = Число дефектов / Число тестов) • Эффективность тестирования (TE = Число дефектов / Трудозатраты тестирования) • Доля покрытия требований (RCR = Число требований, покрытых тестами / Число требований) • Плотность покрытия требований (RCD = Число тестов / Число требований) • Доля повторно открытых дефектов (RDR = Число повторно открытых дефектов / Число дефектов ) • И много-много других …
  • 16. Выбор аналитических техник. Контрольные карты XmR (1)
  • 17. Выбор аналитических техник. Контрольные карты XmR (2) • XmR chart (контрольные карты) - это массив данных, где точки располагаются в хронологическом порядке • XmR chart включает 2 вида диаграмм: – Individual - контрольная карта размаха (массив измеряемых данных, где точки располагаются в хронологическом порядке) – Moving Range - контрольная карта скользящего размаха (массив данных сдвига между двумя точками измерений) • UCL - верхняя контрольная граница • CL - среднее • LCL - нижняя контрольная граница
  • 18. Сбор выбранных метрик и статистическая обработка результатов • Измерения по установленным правилам • Расчет на основе производных метрик, которые впоследствии подвергаются статистическому анализу • Расчет среднего значения и границ верхнего и нижнего пределов при получении каждого нового значения метрики • Отображение полученных результатов на контрольной карте и анализ стабильности процессов на их основе • Последние два действия могут выполняться с помощью специальных программных инструментов, реализующих алгоритм расчета контрольных карт. • Нами разработан инструмент для расчета и вывода на диаграмму параметров исследуемых метрик по алгоритму XmR
  • 19. Определение особых случаев (1) Особый случай – это попадание значения контролируемой метрики за пределы границ, вычисленных с помощью контрольной карты или «особое», необычное поведение последовательности значений метрики, свидетельствующее о ее неслучайном поведении. Число значений <3 Особые случаи не определяются
  • 20. Определение особых случаев (2) Число значений от 3 до 29 (фаза накопления данных) Наш опыт говорит о том, что что «кандидатом» на особый случай является выход значения за ±2G Число значений >29 (фаза полноценного SPC) Используется канонический способ определения особых случаев (> ±3G)
  • 21. Причины особых случаев и их устранение При расчете новых границ и среднего значения контролируемого параметра процесса использовать значение особого случая нельзя (если причина особого случая выявлена и устранена), т.к. в противном случае мы получим неоправданно широкие возможные границы параметра • Поиск причин особых случаев • Принятие мер по их недопущению в будущем • Понимание того, что причина, приведшая к особому случаю, есть следствие неуправляемых событий или свершившихся рисков, которые наступили и больше не ожидаются
  • 22. Количественное управление • Вычисленные ранее естественные границы процесса (process capability, или голос процесса) на этом шаге сравниваются с установленными целями по значению контролируемого параметра (objectives, или голос заказчика). • Если голос процесса удовлетворяет голосу заказчика, то ничего предпринимать не надо • Если же нет, то необходимо выработать меры по согласованию process capability и customer voice. Меры могут быть следующие: • Изменение по согласованию с заказчиком установленных целей • Улучшение выполнения существующего процесса для уменьшения размаха process capability • Введение новых процессных элементов, которые могут обеспечить нужные значения контролируемого параметра процесса
  • 23. Пример распределения метрики SDD (1) Параметры процесса не обеспечивают полностью достижение проектной цели Корректирующие действия
  • 24. Причины выхода за “голос заказчика” Причины Примеры коррекции Слабая квалификация Обучение, замена разработчиков Высокие требования заказчика Договориться о снижении требований, повысить показатели Высокое качество тестирования Не требуется дополнительных действий Отсутствие анализа кода Внедрить анализ кода или любое дополнительное статическое тестирование - peer review объектов …………….. ……………..
  • 25. Пример распределения метрики SDD (2) Параметры процесса (при гарантии его неизменности) с вероятностью около 100% обеспечивают достижение проектной цели
  • 26. Преимущества использования SPC • Проактивный подход- своевременно предпринимаются корректирующие/ предупреждающие действия • Импульс для улучшения процесса • После внесения изменений в процесс, можно объективно оценить, стал ли процесс “лучше” или “хуже” • Возможность прогнозирования конечного результата
  • 27. Корреляция метрик Примеры пар метрик, корреляцию которых организации может быть полезно получать: • плотность дефектов после передачи программного продукта в Production и плотность дефектов до передачи программного продукта в Production • высокие оценки качества проектных аудитов и признание заказчиком проекта как успешного Корреляция метрик помогает на более раннем этапе проекта выявить проблемы и предпринять корректирующие действия
  • 29. Корреляция метрик- прогнозирование результата (2) • Параметр r (множественный коэффициент корреляции/ множественное r/ коэффициент корреляции Пирсона) – характеризует тесноту связи между зависимой переменной и предиктором • Параметр r2 (квадрат множественного коэффициента корреляции/ множественный коэффициент детерминации) – коэффициент, показывающий, какая доля дисперсии результативного признака объясняется влиянием независимых переменных • Параметр Р – статистическая значимость коэффициента корреляции (например, для уровня значимости 0.05 вероятность ошибки 5 %) • Проведенная прямая называется прямой регрессии или прямой, построенной методом наименьших квадратов
  • 30. Количественное управление результатами аудитов Позволяет продемонстрировать: • Оценку качества выполнения проекта в целом • Текущую оценку проекта
  • 31. Quantitative Dashboard (1) Главное меню Массив данных Особый случай
  • 32. Quantitative Dashboard (2) Пример построения контрольной карты
  • 33. Quantitative Dashboard (3) Пример распределения сдвига значений (Moving range) Пример гистограммы