Конкретный набор характеристик для контроля может варьироваться в зависимости от бизнес приоритетов компании, либо концентрироваться на каких-то конкретных темах, которые важны именно сейчас.

Центральным звеном такой инфраструктуры является единая база данных, содержащая в себе всю необходимую информацию о процессе разработки.

Наличие всех этих данных создаёт широкое пространство для анализа эффективности процесса разработки, поиска скрытых зависимостей, влияющих на качество и продуктивность разработки.

Современные инструменты также могут поддерживать автоматизацию контроля “workflow” – это тоже в некоторой степени контроль процесса, контроль действий на низком уровне. Этими возможностями также следует пользоваться по максимуму.

Project Dashboard should be shown here.

Team Dashboard should be shown here. Also mention about Team-Project dashboard.

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

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

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

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

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

Slide 6 Стоимость контроля процесса Формальный контроль процесса разработки ПО: эффективен, когда проводится регулярно довольно дорогая процедура

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

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

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

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

Автоматизация формальных проверок Программный код: 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(“Defect LOCs") / GetVal(“Total LOCs") >= 0.2 Then addAnalysisIssue “Code rework is greater than ...“ ... End If Примеры формальных проверок из практики компании CQG: «Каждая активность типа «разработка требований», «проектирование», «разработка тест-плана», «кодирование» приводит к созданию артефактов соответствующего типа с задержкой не более 2-х недель» - пример проверки на полноту и согласованность данных. «Каждое изменение кода размером, превышающим 20 строк, прошло через формальный процесс инспекций» - пример проверки на соблюдение стандартов процесса. «Объём переделок меньше 20%» - пример проверки качества процесса. Slide 11

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

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

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

Slide 15 CQG: Инфраструктура сбора данных о процессе разработки ПО Раз в сутки все данные о процессе из перечисленных слева систем экспортируются в единую базу данных, которая используется для сбора метрик и анализа процесса

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

Slide 17 CQG Dashboards CQG Dashboards (на платформе MS Excel) объединяют в себе функциональность визуальных инструментальных панелей (dashboards) и автоматизированных анализаторов метрик. Разработано несколько типов таких средств, отличающихся областью применения: Team Dashboard, Project Dashboard, Team-Project Dashboard, System Dashboard, Maintenance Dashboard. Результатами работы CQG Dashboards являются: Набор графических диаграмм, показывающих изменение во времени (с недельными периодами) основных показателей и метрик процесса. Набор текущих числовых значений основных метрик. Набор детализированных данных из БД, относящихся к выбранному подмножеству. Список замечаний, найденных при применении формальных контрольных таблиц (checklists). Обобщённая оценка соответствия процесса стандарту на основе автоматических проверок.

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

Slide 19 CQG: Project Dashboard (demo)

Slide 20 CQG: Team Dashboard (demo)

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

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

Конец Вопросы? Автор: Вадим Савкин, vadim.savkin@gmail.com http://vsavkin.livejournal.com/