Перевод части главы «Dashboard for Continuous Monitoring of Quality» / «Дашборд для постоянного мониторинга качества» книги «Relating System Quality and Software Architecture" / "Связь качества системы и архитектуры программного обеспечения", Mistrik, 2014

В этом разделе мы представляем, как три изучаемые компании использовали концепцию готовности к выпуску в своих дашбордах для команд и проектов разработки. Подход трёх компаний отличается и основан на истории использования показателей в этих компаниях, поэтому не все элементы успешного дашборда присутствуют во всех компаниях. Таблица 1 представляет собой сводку по каждой компании

Компании работают в трех различных областях, имея общие черты (например, разработка встроенного программного обеспечения) и различия (например, методология разработки, зависимость от поставщиков). Широта охвата компаний и общие черты, представленные на дашборде, показывают, что схожие вызовы и элементы успешных дашбордов применимы для каждой области.​

Ericsson AB

Ericsson AB разрабатывает крупные программные продукты для сетей мобильной телекоммуникации. Во время исследования численность организации составляла несколько сотен инженеров, а количество проектов доходило до нескольких сотен. Проекты все чаще выполнялись в соответствии с принципами Agile-разработки программного обеспечения и системы Lean-производства, называемой Streamline development в Ericsson (Tomaszewski и др., 2007). В этих условиях различные команды были ответственны за более крупные части процесса по сравнению с традиционными процессами: команды по разработке (кросс-функциональные команды, ответственные за полный цикл анализа, проектирования, внедрения и тестирования определенных функций продукта), проверка сетей и интеграционное тестирование, и другие.

Организация использовала несколько систем измерений: для контроля проекта разработки программного обеспечения (на уровне проекта), для контроля качества продуктов в эксплуатации (на уровне продукта) и для мониторинга состояния организации на высшем уровне. Все системы измерений были разработаны методами, описанными в Staron и др. (2008, 2010a), с особым упором на модели проектирования и развертывания систем измерений, представленные в работах Staron и Meding (2009b) и Meding и Staron (2009).

Потребности организации изменились от расчета и представления метрик (около 7 лет до написания этой главы) к использованию прогнозов, симуляций, систем раннего предупреждения и обработке больших объемов данных для управления организацией на разных уровнях и предоставления информации как с проектов, так и с линии. Эти потребности были удовлетворены в ходе научно-исследовательских проектов, проводимых в организации с 2006 года.

Volvo Car Corporation

VCC — это шведский производитель автомобилей и оригинального оборудования для автомобилей (OEM), расположенный в Гетеборге. VCC разрабатывала программное и аппаратное обеспечение в распределенной среде разработки программного обеспечения. Для ряда электронных блоков управления (ECU) программное обеспечение разрабатывалось внутренними командами разработки программного обеспечения, которые обычно также были ответственны за интеграцию программного обеспечения с аппаратным обеспечением, разработанным поставщиками. Однако основная часть разработки встроенного программного обеспечения приходила от внешних поставщиков, которые проектировали, внедряли и тестировали функциональность на основе спецификаций от VCC (Eklund и др., 2012; McGee и др., 2010).

Объем ресурсов всего автомобильного проекта был значительно больше, чем у проектов в области телекоммуникаций, из-за того, что участвовали как OEM, так и поставщики (первого и второго уровней), а проекты разработки автомобилей обычно проводились с использованием подхода к производственной линейке с учетом эталонных архитектур (Gustavsson и Eklund, 2011). Тем не менее, мы изучали одну команду, которая по размерам была сопоставима с командами в Ericsson и Saab EDS.

Изучаемая организация в VCC представляла собой команду разработки программного обеспечения, ответственной за программное обеспечение для ECU системы климат-контроля. Команда получила набор измерений для визуализации прогресса разработки и передачи этой информации руководству.

Saab Electronic Defense Systems

Saab EDS разрабатывает встроенное программное обеспечение и графические пользовательские интерфейсы для наземных радарных систем. Конкретный продукт, над которым мы работали, был частью более крупного продукта, разработанного несколькими сотнями разработчиков, дизайнеров, тестировщиков, аналитиков и других специалистов. Исторический проект по разработке этого продукта осуществлялся поэтапно и не использовал кросс-функциональные команды. Управление проектом производило некоторые ручные метрики по отчетам о неполадках.

С тех пор организация перешла на более Agile-процессы и кросс-функциональные команды. Также были сделаны значительные улучшения и оптимизации в отношении времени сборки и доставки программного обеспечения. Чтобы повысить ценность для клиентов, конкурентоспособность на рынке и прибыль, Saab AB Electronic Defense Systems в Гетеборге проходит Lean-трансформацию.

У Saab EDS есть история использования измерений и коммуникации качества через дашборды. Дашборд, представленный в этой главе, показывает, как организация использует одну метрику — количество дефектов — в различной детализации для предоставления информации о статусе разработки программного обеспечения.

Дашборд Ericsson

Ericsson выбирает дашборд, который показывает готовность к выпуску продукта в компактной форме. Индикатор готовности к выпуску продукта предназначен для предсказания момента, когда разрабатываемый продукт достигнет соответствующего качества для выпуска (Staron и др., 2012). Качество измеряется количеством открытых отчетов о дефектах для продукта, что означает, что правильное качество для выпуска продукта — это 0 дефектов. Дефекты могут быть связаны как с функциональностью программного обеспечения, так и с его нефункциональными свойствами, в частности, производительностью, надежностью и доступностью. Эти свойства тестируются в рамках регулярно выполняемых тестовых наборов.

Критерий 0 дефектов является достаточным только при выполнении другого критерия — вся функциональность протестирована, и все тестовые случаи пройдены. Заинтересованное лицо для этого индикатора — менеджер проекта, а программа разработки программного обеспечения — это группа, которая должна передавать информацию вышестоящим управленческим командам программы и организации. Индикатор (RR, готовность к выпуску) имеет следующую форму:

где #defects — это количество открытых дефектов для продукта, defect_removal_rate — это среднее количество удаленных дефектов за последние 4 недели, test_execution_rate — это среднее количество тестовых случаев, выполненных за последние 4 недели, а test_pass_rate — это среднее количество тестовых случаев, прошедших за последние 4 недели. Период в 4 недели выбран на основе статистических и эмпирических анализов. Эти анализы показали, что, исходя из длины тестовых циклов и мероприятий по устранению дефектов, период в 4 недели является наиболее подходящей длиной для данного прогноза и дает наиболее точные результаты (Staron и др., 2012).

Формула основана на ряде базовых измерений (например, тесты, прошедшие за неделю) и производных измерений (например, коэффициент прохождения тестов за последние 4 недели), которые показывают, как стандартизация в соответствии с ISO/IEC 15939 реализуется на практике. Каждое из измерений в формуле определяется в соответствии со стандартом с его методом измерения и функцией измерения. Заинтересованное лицо имеет средства и возможности для реагирования и возвращения проекта на правильный путь, если это необходимо.

Рисунок 8.3 демонстрирует, как индикатор распространяется в организации на ежедневной основе — в виде гаджета MS Vista Sidebar (пример сжатой визуализации). Гаджет представляет собой дашборд, на котором представлен индикатор. Он дополнен файлом Excel с трендами для измерений в формуле RR.

Содержимое гаджета показывает, что проекту потребуется 2 недели для достижения качества выпуска (недели до выпуска). Презентация информации проста и лаконична, предоставляя заинтересованному лицу (менеджеру исследуемого проекта разработки продукта) необходимую информацию. Гаджет также содержит индикатор качества информации (обеспечение качества информации), который сокращенно обозначается как IQ (Staron и Meding, 2009a). Подробности о базовых и производных измерениях доступны в связанном файле MS Excel, который открывается при нажатии на гаджет.

Помимо гаджета, команда имеет вспомогательную систему измерений, отслеживающую зависимости между архитектурными компонентами, как явными, так и неявными. Система измерений основана на мониторинге того, как компоненты программного обеспечения изменяются со временем и какие компоненты изменяются совместно (Staron и др., 2013), с примером на рисунке 8.4.

Зависимости визуализируются очень лаконично и позволяют командам быстро находить неявные зависимости, которые могут привести к эрозии архитектуры. Новые зависимости требуют обновления стратегий тестирования и, следовательно, влияют на индикатор готовности к выпуску (новые тестовые случаи для выполнения, что требует больше времени для тестирования продукта перед выпуском).

Дашборд в VCC

В случае VCC мы изучали, как одна команда разработки программного обеспечения может отслеживать прогресс разработки с помощью дашборда, состоящего из трех компонентов — управление требованиями, контроль версий моделей и прогресс тестирования. Интерес команды заключался в том, чтобы сообщать о статусе разработки программного обеспечения для одного ECU для семейства современных автомобилей под брендом Volvo. Дашборд был спроектирован и разработан совместно с заинтересованным лицом из команды, который имел представление о процессе разработки и практике в компании. Заинтересованное лицо было назначено командой для представления общего мнения команды. Дашборд для мониторинга прогресса разработки для команды представлен на рисунке 8.5.

Этот дашборд представляет индикаторы для мониторинга тенденций в разработке программного обеспечения, отслеживая темп моделирования функциональности ECU (таблица под заголовком «Индикаторы»). Команда выбрала четыре индикатора для мониторинга темпа коммитов и тенденций:

• Тенденция коммитов: основной индикатор, отражающий готовность функциональности, определяемый как разница между скользящей средней и количеством проверок на прошлой неделе. Если количество проверок уменьшается относительно скользящей средней, это свидетельствует о высокой вероятности того, что команда движется к фазе тестирования. В сжатой форме он отражает готовность команды к реализации функциональности.

• Количество коммитов на прошлой неделе: индикатор, фиксирующий «температуру» разработки функциональности.

• Количество коммитов на текущей неделе: индикатор, отслеживающий деятельность в текущей неделе, чтобы помочь команде проверить, как статус развивается со временем.

• Темп коммитов: индикатор, показывающий средний уровень (скользящая средняя) проверок.

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

Поскольку команда работает по Agile-методологии, где функциональное тестирование является неотъемлемой частью разработки моделей, количество коммитов может быть связано как с добавлением новой функциональности, так и с изменениями существующей функциональности, вызванными исправлением дефектов. Однако регрессионное тестирование не включалось, и поэтому потребовалось дополнительное измерение для контроля прогресса основного обеспечения качества разработанной функциональности.

Команда отслеживала три вспомогательных тренда на дашборде, чтобы убедиться, что предположения индикаторов выполняются:

• Выявление и разбивка требований (количество REQPRODs): для оценки готовности к выпуску команда проверяет наличие новых требований в бэклоге. Новые требования указывают на то, что еще предстоит выполнить новую работу (в частности, новые обновления моделей или разработку новых моделей).

• Моделирование (количество новых проверенных файлов): для определения готовности команды с продуктом, где необходимо оценить тенденцию разработки. Тепловая карта ревизий моделей показывает внутреннюю стабильность архитектуры.

• Прогресс тестирования: количество пройденных тестов регрессионного тестирования.

Дашборд, представленный на рисунке 8.5, построен на тех же принципах, что и гаджет, представленный в разделе “Дашборд Ericsson”, но информация представлена в виде потока — три диаграммы в одном ряду вместо одного индикатора. Это более исчерпывающее представление готовности к выпуску объясняется тем, что команда хотела получить больше информации о процессе разработки и визуально сообщить статус заинтересованным сторонам за пределами команды, например, менеджерам субпроектов.

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

Когда тренд роста требований остается стабильным, тренд проверок снижается, а количество пройденных тестов регрессионного тестирования стабильно или растет, это говорит о том, что команда близка к выпуску (акцент на принятии решений).

Дашборд в Saab EDS

В Saab EDS мы изучили два дашборда — один для мониторинга внутреннего качества разрабатываемого программного продукта (Рисунок 8.6) и один для мониторинга внешнего качества (Рисунок 8.7). Эти дашборды дополняются радиаторами сборки. Радиаторы сборки используются для отображения текущего статуса сборки продуктов в изучаемой организации Saab EDS. Если продукт отображается красным (что указывает на неработающую сборку) на радиаторе, люди реагируют на это и предпринимают необходимые действия, чтобы сборка снова прошла.

Дашборд на Рисунке 8.6 представляет индикаторы для мониторинга текущего состояния и тенденций внутреннего качества программного обеспечения (ISO, 2005b), в частности, сложности продукта. Этот дашборд используется разработчиками ежедневно, поскольку визуализирует данные, которые немедленно важны для них. Данные для индикаторов генерируются инструментом статического анализа кода и показывают состояние таких индикаторов качества, как сложность исходного кода.

Раннее предупреждение о проблемах предоставляется другими представлениями в том же дашборде, показывающими тенденции для следующих метрик (в качестве примера):

• Древовидная карта/тепловая карта (в центре Рисунка 8.6 с красным интенсивным цветом, указывающим на проблемную область, и зеленым цветом, показывающим высокое качество области) используется для идентификации программного модуля с низким соблюдением правил. Размер прямоугольника определяется количеством строк кода. Эта информация используется как вводные данные для принятия решения о том, следует ли очистить или переписать определенный модуль.

• В верхней правой части дашборда (Рисунок 8.6) показаны «горячие точки», вызванные критическими нарушениями, что помогает быстро идентифицировать код с высоким риском и простые решения. «Горячие точки» — это самые важные части программных систем, которые нарушают правила, установленные архитекторами, например, несоответствие архитектурным рекомендациям и дефекты видимости интерфейса.

• Прямоугольник в центре справа перечисляет наиболее нарушенные правила по степени серьезности. Заштрихованное поле представляет собой количество случаев, а диаграмма распределения слева. Эта информация используется для выявления определенных проблемных областей, которые следует решить (фокусированная очистка кода, обучение и т. д.).

• В нижнем правом прямоугольнике на Рисунке 8.6 показана сложность кода. Учитывая, что модуль с высокой сложностью может быть более подвержен ошибкам и сложнее в обслуживании, более высокие значения требуют принятия мер для данного модуля.

Дашборд представляет несколько аспектов внутреннего качества сжато и является «кликабельным», что позволяет дизайнерам углубляться в детализированные меры или в те же меры на более низких уровнях абстракции (например, функции или части кода). Внутреннее качество включает большинство атрибутов из ISO 25000 (атрибуты из частей стандарта, одобренных ISO). Атрибуты рассчитываются на нескольких уровнях архитектуры — от уровня продукта до уровня модуля или функции (если применимо).

Дашборд на Рисунке 8.7 представляет индикаторы для мониторинга отчетов о проблемах, то есть внешнего качества разрабатываемого программного продукта. Информация используется для быстрого выявления узких мест в процессе решения отчетов о проблемах. Маленькие графики представляют количество отчетов о проблемах в соответствующем состоянии в определенный момент времени. Сводный график содержит сумму маленьких графиков в данный момент времени. Цветные числа под сводкой указывают дельту отчетов о проблемах за 24 часа.

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

Почитать о моем опыте использования дашборда качества, не основанного на этих примерах, можно здесь - я также использую серию стандартов ISO 25000 и визуализацию для принятия решений

Буду рад поделиться опытом на тему качества IT-продукта, QACoE (QA Center of Excellence), TCoE (Testing CoE) - пишите в мой линкедин.