CISQ. Исследование анализа качества ПО 2020 — часть 1

В этой статье перевод части результатов опроса — раздела «Инженерия».
Для удобства привожу список вопросов, на которые собрана статистика:

• Используете ли вы в настоящее время анализ качества ПО (SQA)?

• Требует ли ваша внутренняя регуляторная функция или функция обеспечения качества обязательного использования SQA вашими командами разработки?

• Связана ли степень автономии вашей команды с уровнем зрелости команды в области SQA и управления техническим долгом?

• Какие стандарты разработчики используют для SQA?

• Как часто проводите SQA?

• Как часто игнорируете метрики SQA?

• Какая самая распространенная причина игнорирования метрик SQA?

• Кто получает наибольшую выгоду от использования SQA?

• В каких областях качества кода SQA приносит наибольшую пользу?

• Использует ли ваша команда данные SQA для улучшения процессов?

• Довольны ли вы использованием инструментов SQA?

Во второй части будет перевод оставшихся двух разделов — «Системные интеграторы», «Управление поставщиками».
———————

Представляем отчет «Состояние отрасли»

Консорциум по качеству информации и программного обеспечения (CISQ) запустил опрос «Состояние отрасли», первое комплексное исследование анализа качества программного обеспечения, охватывающее поставщиков инструментов, системных интеграторов, менеджеров и инженеров в организациях конечных пользователей. Опрос был открыт с июля 2019 года по январь 2020 года. Толчком для этого исследования стало тревожное увеличение количества инцидентов, связанных с качеством программного обеспечения, а также обеспокоенность членов CISQ тем, что организации не соблюдают основные требования. Мы хотели понять, как переход к Agile-разработке и DevOps меняет не только практики обеспечения качества программного обеспечения, но и отношение разработчиков и их поведение в отношении качества кода. Также важно понять, как стандарты качества программного обеспечения используются системными интеграторами и организациями конечных пользователей; какие стандарты применяются, какие сектора способствуют их внедрению и как организации получают пользу от стандартов качества программного обеспечения.

Методология

Результаты в отчете «Состояние отрасли» по анализу качества программного обеспечения основаны на 82 ответах в онлайн-опросе, 155 телефонных беседах с ИТ-руководителями предприятий, их командами и менеджерами поставщиков ИТ-услуг, обсуждениях на семинарах, организованных CISQ, и форумах на LinkedIn. Этот отчет включает результаты опроса, наблюдения и рекомендации. Отчет разделен на три раздела:

• Инженерия

• Системные интеграторы

• Управление поставщиками

Что разработчики думают об анализе качества программного обеспечения (SQA)?

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

Проблемы низкого качества программного обеспечения и технического долга существуют с момента появления ИТ. Похоже, что мы достигли кризисного момента, когда необходимо гораздо серьезнее относиться к решению этих проблем и начинать рассматривать разработчиков как инженеров. Это значит, что нужно не только писать код, но и уделять внимание другим аспектам инженерии, таким как обеспечение качества, безопасность, надежность и долгосрочная жизнеспособность разрабатываемых решений. С переходом к SaaS и облачным технологиям предприятия и инженерные команды могут считать, что это не касается их, но это не так. SaaS-решения создаются инженерами. Если у этих решений есть слабые места, это затрагивает тысячи, если не миллионы, пользователей.

В отчете CISQ «Состояние отрасли» по анализу качества программного обеспечения мы хотели проверить гипотезу о том, что надежность, безопасность, эффективность производительности и поддерживаемость, поскольку их часто называют «нефункциональными требованиями», остаются второстепенными по сравнению с функциями, ориентированными на клиента, для продуктовых владельцев, менеджеров и команд. Давайте перейдём к результатам опроса.

Используете ли вы в настоящее время SQA?

Результаты: Большинство разработчиков, 82%, сообщают, что используют анализ качества программного обеспечения. Более того, 33% утверждают, что всегда используют статический анализ кода, по сравнению с 17%, которые всегда используют динамический анализ кода. 32% разработчиков сообщают, что часто используют статический и динамический анализ кода, т.е. на ежедневной или еженедельной основе.

Требует ли ваша внутренняя регуляторная функция или функция обеспечения качества обязательного использования SQA вашими командами разработки?

Результаты: 17% разработчиков сообщают, что использование анализа качества программного обеспечения является обязательным в рамках внутренней регуляторной функции, треть отмечает, что это зависит от проекта, и еще треть считает, что регуляторная функция должна требовать использования SQA. Эти данные показывают, что существует значительный потенциал для более тесного взаимодействия между инженерией и подразделениями управления рисками и соблюдения нормативных требований (GRC) для снижения рисков в программном обеспечении, который еще не полностью реализован. Функция обеспечения качества (QA) отражает регуляторную политику: 17% разработчиков сообщают, что SQA является обязательным, а 33% — что это зависит от проекта. Однако треть разработчиков отмечает, что функция QA никогда не требует обязательного использования анализа кода.

Наблюдения: Очевидно, что как внутренняя регуляторная функция, так и, что удивительно, функция обеспечения качества не требуют обязательного использования инструментов для анализа качества кода. Похоже, что подавляющее большинство разработчиков самостоятельно принимают решение использовать SQA. Подход, зависящий от конкретного проекта, остается доминирующим, и возникает вопрос, насколько он оправдан, учитывая текущий уровень ИТ-рисков и рисков безопасности.

Связана ли степень автономии вашей команды с уровнем зрелости команды в области SQA и управления техническим долгом?

Результаты: 50% разработчиков сообщают, что уровень автономии, предоставляемой команде, неформально связан с использованием анализа качества программного обеспечения. 17% указывают, что автономия формально связана с SQA. 33% разработчиков не знают о какой-либо формальной или неформальной связи между анализом кода и автономией команды.

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

Какие стандарты разработчики используют для SQA?

Результаты: Наиболее «часто» используемыми стандартами являются: OWASP Top 10, ISO 25000. Стандарты, используемые «иногда», включают: MISRA, MITRE CWE, SANS/CWE Top 25, OMG/CISQ.

Наблюдения: Неудивительно, что учитывая его распространенность в отрасли, список OWASP Top 10 является одним из наиболее часто упоминаемых стандартов. Необходимо учитывать, что существует разница между осознанием и ссылкой на стандарт и разработкой кода, соответствующего этому стандарту. MISRA — это пример того, что мы ожидаем увидеть в будущем — отраслевые стандарты качества программного обеспечения. Мы прогнозируем, что киберфизические устройства и IoT увеличат использование стандартов качества программного обеспечения, специфичных для определенных областей.

Как часто проводите SQA?

Результаты: 60% разработчиков сообщают, что код сканируется ежедневно или еженедельно, 20% указывают, что код сканируется перед выпуском на этапе контроля качества, и 20% сообщают, что анализ кода носит реактивный характер и проводится по мере необходимости, когда возникает проблема.

Как часто вы игнорируете метрики SQA?

Результаты: 60% разработчиков сообщают, что они «иногда» игнорируют результаты SQA, а 40% утверждают, что они «редко» это делают.

Какая самая распространенная причина игнорирования метрик SQA?

Результаты: Самая распространенная причина, по которой разработчики игнорируют метрики SQA, — это нехватка времени (40% ответов), 20% указывают на ложные срабатывания, а остальные отметили «не актуально» или «другое».

Следует обратить внимание бизнесу и менеджерам приложений на то, что 40% разработчиков игнорируют результаты из-за нехватки времени. Это противоречит ценностям Agile, связанным с доставкой ценности клиенту, и связано с недостаточным пониманием влияния нефункциональных требований со стороны владельцев продуктов и менеджеров продуктов. Неудивительно, что в ходе разговоров с разработчиками они часто считают, что SQA — это пустая трата времени, если они получают противоречивые сигналы от бизнеса и его представителей. Качеству программного обеспечения нужен защитник в компании, и этот вопрос должен возглавляться бизнесом.

Кто получает наибольшую выгоду от использования SQA?

Результаты: Топ-3 заинтересованных сторон, получающих наибольшую выгоду от SQA, в следующем порядке: 1) QA/Тестировщики, 2) Разработчики, 3) Операционные команды.

В каких областях качества кода SQA приносит наибольшую пользу?

Результаты: Топ-3 областей качества кода, которые получают наибольшую выгоду от анализа кода, в следующем порядке: 1) Надежность, 2) Поддерживаемость, 3) Эффективность работы.

Использует ли ваша команда данные SQA для улучшения процессов?

Результаты: 60% разработчиков утверждают, что их команды «редко» используют данные анализа программного обеспечения на ретроспективах или для улучшения процессов, 20% делают это «иногда», а 20% — «всегда».

Довольны ли вы использованием инструментов SQA?

Результаты: 80% разработчиков сообщают, что они «в некоторой степени довольны» использованием инструментов анализа кода, а 20% — «очень довольны». Ни один из респондентов не сообщил о том, что он «недоволен».

У нас все еще есть пути для продвижения вперед, прежде чем SQA будет восприниматься как столь же важный элемент, как непрерывная интеграция (CI) и тестируемая разработка (TDD). Тем не менее, разговор должен начаться с бизнеса и с движением от плохо названных нефункциональных требований. Если надежность, эффективность работы, безопасность и поддерживаемость будут помечены как нефункциональные, они продолжат занимать второстепенное место по сравнению с функциями для клиентов.

Заключение

Давление времени на разработчиков, владельцев продуктов и менеджеров продуктов усугубляет негативное отношение к анализу качества программного обеспечения и нефункциональным требованиям. Мы должны учитывать, что разработчики игнорируют результаты SQA и не особенно довольны использованием этих инструментов. Легко обвинять разработчиков, но мы считаем, что это отражает среду, в которой они работают. Наша рекомендация — запретить термин “нефункциональные требования” (NFRs). Пока мы этого не сделаем, NFR будут рассматриваться как второстепенные. Ясно, что разработчики получают смешанные сигналы. Несмотря на высокий процент разработчиков, использующих SQA, процент тех, кто использует его проактивно для улучшения процессов и действует на основе полученных выводов, ниже, чем хотелось бы.

Рекомендации менеджменту

Менеджеры приложений и скрам-менеджеры должны обращать внимание на свое поведение и отношение к нефункциональным требованиям. Они должны проактивно работать с владельцами продуктов или менеджерами проектов, чтобы обеспечить должное внимание к NFR. Мы обнаружили, что разговор с командой управления продуктами, сосредоточенный только на проблемах технического долга, не является конструктивным. Это обсуждение должно проводиться в контексте бизнес-результатов и рисков.

Команда управления должна обеспечить правильное использование SQA. Например, команды должны настраивать инструменты SQA для уменьшения ложных срабатываний. Также необходимо убедиться, что инструменты SQA интегрированы в цепочку инструментов. Мы должны понимать, что это может означать реорганизацию функций QA и тестирования, чтобы в командах проводилось больше качественного тестирования, связанного с NFR.

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

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

С точки зрения культуры разработки, и в соответствии с Agile и DevOps, нам необходимо изменить поведение и действия команд с фокуса на обеспечение качества (QA) на фокус на инженерии качества (QE). Это выходит за рамки практик разработки на основе тестирования (TDD) или разработки на основе поведения (BDD) и требует фундаментального изменения в философии бережливого производства для обеспечения качества на каждом этапе.

Рекомендации разработке

Удивительно видеть, что уровень использования SQA выше, чем мы ожидали, однако очевидно, что нам предстоит еще пройти долгий путь, прежде чем SQA будет эффективно использовано. Наша первая рекомендация заключается в том, чтобы команды прекратили использовать термин «нефункциональные требования» (NFR) и обучили своих бизнес-аналитиков и владельцев продуктов важности NFR для конечного потребителя.

Мы рекомендуем рассматривать инструменты SQA так же, как и инструменты CI/CD, интегрируя их в цепочку инструментов с высоким уровнем автоматизации. Для того чтобы это было успешно и не создавало проблем для разработчиков, инструменты SQA должны быть настроены под среду программирования и соответствующие стандарты кодирования, чтобы сократить количество ложных срабатываний.

Команды должны использовать подход, основанный на данных, для приоритизации задач по рефакторингу. Инструменты SQA, настроенные под кодовую базу и стили программирования команды, могут помочь в приоритизации и аргументировании с владельцем продукта или менеджером продукта необходимости выделения времени на рефакторинг. Чтобы установить цели приоритизации и уменьшить внутренние споры, мы рекомендуем последовательно использовать стандарты качества кода вместе с инструментами SQA. Кроме того, команды должны использовать стандарты, которые могут быть автоматизированы и не требуют ручного вмешательства.

Учитывая низкий уровень использования метрик SQA для улучшения процессов, мы рекомендуем, чтобы все ретроспективы включали обзор панелей мониторинга SQA, даже если это будет всего лишь быстрый обзор, чтобы избежать самоуспокоенности. Если команды работают в организациях, где автономия должна зарабатываться на основе конкретных метрик, это становится еще более важным.

Наконец, командам необходимо создать убедительный бизнес-кейс для использования SQA, особенно если они работают в условиях, где NFR рассматриваются как второстепенные по сравнению с функциональностью, ориентированной на клиента. Мы обнаружили, что лучший подход заключается в том, чтобы указать на причинно-следственную связь между низким качеством и клиентским опытом, а также на положительный эффект от использования стандартного подхода к SQA для снижения технического рефакторинга, который сегодня обычно составляет 10-15% времени, затрачиваемого на спринт.

«Нефункциональные требования недостаточно подчеркиваются в управлении проектами и являются одной из основных причин перерасхода бюджета и срывов проектов. Нефункциональные требования критически важны для успеха, и необходимо уделить больше внимания подготовке к поддерживаемости, что имеет решающее значение для общей стоимости владения.»
_{Доктор Барри Бом, главный ученый, SERC, профессор программной инженерии TRW и директор Центра программной инженерии при Университете Южной Калифорнии}