Автоматизированный контроль процесса разработки ПО

1. Автоматизированный контроль процесса разработки ПО Вадим Савкин

2. Сведения об авторе • Вадим Савкин • Инженер по процессам разработки ПО в компании CQG • Участник CQG SEPG(Software Engineering Process Group) • vadim@cqg.com

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

4. План презентации • Теория • Необходимость контроля процесса • Инфраструктура для автоматизации контроля процесса • Контроль корректности собираемых данных • Процесс контроляи улучшения процесса разработки • Практика — опыт автоматизации контроля процесса разработки в компании CQG • Инфраструктура сбора данных • CQG Dashboards demo • Автоматизированный контроль процесса в CQG

5. Необходимость контроля процесса Формальный контроль процесса разработки: • гарантирует выполнение стандартов и правил установленного процесса разработки ПО • помогает оценить эффективность процесса • помогает усовершенствовать процесс и оценить эффект от изменений • необходим средним и крупным компаниям-разработчикам ПО

6. Структура контроля процесса • Контроль соблюдения заданного процесса. • Проверка согласованности, полноты и корректности данных, собираемых различными системами поддержки разработки; • Проверка соблюдения стандартов процесса разработки, принятого в компании. • Контроль эффективности и качества процесса. • Оценка качества разрабатываемых продуктов; • Оценка продуктивности разработки; • Оценка точности планирования; • Интервьюирование разработчиков и менеджеров относительно процесса. • Принятие решений. • Принятие проектных решений по результатам проверок (в случае проектных аудитов); • Принятие решений о необходимости внесения изменений в процесс разработки.

7. Стоимость контроля процесса • Формальный контроль процесса разработки ПО: • эффективен, когда проводится регулярно • довольно дорогая процедура • Вывод – необходима автоматизация: • Автоматизированный сбор метрик процесса разработки • Автоматизация формальных проверок

8. Инфраструктура для автоматизации контроля процесса • В первую очередь, инфраструктура, обеспечивающая возможность автоматизации контроля процесса, должна позволять согласованно собирать и накапливать данные обо всех значимых аспектах процесса разработки, которые необходимо анализировать и контролировать

9. Содержимое единой базы данных • Иерархия департамента разработки ПО с данными обо всех разработчиках и менеджерах. • Иерархия продуктов и проектов с разбивкой на задачи. • Данные о времени, потраченном разными сотрудниками на ту или иную активность или задачу. • Данные о созданных артефактах (требования, дизайн, тест-планы, код, проектная документация и т.п.) с подсчитанными размерами (необходимы стандарты оформления и подсчёта) • Данные о найденных дефектах со всеми необходимыми атрибутами и историей изменений. • Прочие данные, специфичные для процесса разработки, принятого в компании. • Вспомогательные данные.

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

11. Автоматизация формальных проверок Программный код: analyseActivitiesConsistency "Requirements", "Requirement Records", 2 * 7 analyseActivitiesConsistency "Design", "Model Elements", 2 * 7 analyseActivitiesConsistency "Test Cases Development", "Test Cases", 2 * 7 analyseActivitiesConsistency "Code & Unit Test", "Lines of Code", 2 * 7 If .Cells(i, oCols("Inspection")) = ""And _ .Cells(i, oCols("LOCs")) > 20 Then addTaskAnalysisIssue oRawSheet, oCols, i,.Cells(i, oCols("LOCs")) & " LOCs have not been inspected?" End If If GetVal("Integration Testing") < GetVal("System Testing") Then addAnalysisIssue "There were more defects found during ...“ ... End If ... Примеры формальных проверок из практики компании CQG: • «Каждая активность типа «разработка требований», «проектирование», «разработка тест-плана», «кодирование» приводит к созданию артефактов соответствующего типа с задержкой не более 2-х недель» - пример проверки на полноту и согласованность данных. • «Каждое изменение кода размером, превышающим 20 строк, прошло через формальный процесс инспекций» - пример проверки на соблюдение стандартов процесса. • «Количество дефектов, найденных в ходе системного тестирования, меньше количества дефектов, найдённых в ходе интеграционного тестирования, которое, в свою очередь, меньше количества дефектов, найденных в ходе инспекций» - пример проверки качества процесса.

12. Процесс контроляи улучшения процесса разработки

13. Опыт автоматизации контроля процессов в компании CQG Вадим Савкин

14. CQG: Инфраструктура сбора данныхо процессе разработкиПО • Cреднее суммарное время, которое тратит разработчик на работу со всеми программными инструментами сбора данных в CQG, составляет около 15 минут в день.

15. CQG: Инструменты сбора данных • PV Tool: Система учёта рабочего времени и размеров произведённых артефактов с привязкой к конкретным проектам (собственная разработка) • Tracker: Система учёта отдельных задач и поддержки инспекций (собственная разработка, поддерживает методологию PSP) • CQGenie: Система bug-tracking и репозиторий требований (разработка на базе Siebel) • CVS: Система контроля версий

16. CQG Dashboards - структура

17. CQG: Основные метрики процесса • Метрики производительности: • Производительность (число строк кода в неделю) • Скорость кодирования • Метрики качества: • Плотности дефектов разных типов • Объём переделок • Покрытие кода требованиями • Метрики формального процесса инспекций: • Скорость просмотра кода • Плотность найденных замечаний • Процент дефектов от общего числа замечаний. • Покрытие кода инспекциями • Метрики точности планирования: • Отклонение реальных значений затрат от запланированных • Себестоимость проекта

18. CQG: Project Dashboard (demo)

19. CQG: Team Dashboard (demo)

20. CQG: Автоматизированный контроль процесса разработки ПО • В компании CQG автоматизированный контроль процесса разработки применяется на нескольких уровнях: • Периодический контроль стандартного процесса разработки в командах (раз в 2-3 недели). • Периодический аудит проектов (раз в 4-6 недель). • Периодический контроль процесса поддержки (maintenance) продуктов (в зависимости от частоты релизов). • Контроль проводится независимыми экспертами, которые совмещают роль разработчика с ролью инженера по процессам разработки ПО.

21. Заключение Для автоматизации контроля процесса необходимо: • Постоянно собирать требуемые данные о процессе всем разработчикам • Накапливать данные в единой базе данных • Периодически контролировать корректность и полноту данных • Регулярно подсчитывать метрики на основе собранных данных При выполнении вышеперечисленных условий • Формальные проверки различных показателей процесса могут быть легко автоматизированы