Метрика программного обеспечения

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

В 1970-е годы развитие было сосредоточено на анализе исходного кода. В этот период появились фундаментальные метрики сложности кода, такие как цикломатическая сложность Томаса Маккейба (1976) и метрики Холстеда (1977)^[4].^[5]

В 1990-е годы, с распространением объектно-ориентированного программирования, возникла потребность в метриках дизайна для оценки архитектуры систем. Ключевым стал набор метрик Чидамбера и Кемерера (1993), позволивший измерять специфические аспекты объектно-ориентированного дизайна, такие как наследование и связность^[6].

Начиная с 2010-х годов, в эпоху Agile и DevOps, фокус сместился на метрики потока создания ценности. Отраслевым стандартом стали метрики DORA, оценивающие производительность команд через показатели скорости и стабильности поставки программного обеспечения (частота развёртывания, время выполнения изменений, процент сбоев и время восстановления сервиса)^[7].

Современная классификация метрик программного обеспечения является многоуровневой и группирует показатели по их стратегическому назначению, бизнес-целям и используемым методологиям (таким как Agile и DevOps), дополняя традиционное деление на низкоуровневые и высокоуровневые показатели^[8].^[9]

Статические метрики измеряют характеристики исходного кода (сложность, читаемость, поддерживаемость) без его выполнения^[10]..

• порядок роста (имеется в виду анализ алгоритмов в терминах асимптотического анализа и O-нотации),
• количество строк кода,
• цикломатическая сложность,
• анализ функциональных точек,
• количество ошибок на 1000 строк кода,
• степень покрытия кода тестированием,
• покрытие требований,
• количество классов и интерфейсов,
• метрики программного пакета от Роберта Сесиль Мартина,
• связность.

Для оценки эффективности процесса разработки используются следующие группы показателей:

• Метрики DORA^[7] — оценивают производительность и стабильность поставки программного обеспечения:

Частота развёртывания (англ. Deployment Frequency) — измеряет, как часто изменения успешно выпускаются в рабочую среду^[11]. Время выполнения изменений (англ. Lead Time for Changes) — время с момента фиксации кода до его успешного развёртывания^[12]. Коэффициент сбоев при изменениях (англ. Change Failure Rate) — процент развёртываний, приводящих к сбоям и требующих вмешательства^[11]. Время восстановления обслуживания (англ. Time to Restore Service) — среднее время, необходимое для восстановления работы после инцидента.

• Метрики потока создания ценности (англ. Value Stream Metrics)^[13] — измеряют процесс доставки ценности:

Время цикла (англ. Cycle Time) — время, в течение которого задача находится непосредственно в активной работе, без учёта простоев^[14]. Эффективность потока (англ. Flow Efficiency) — доля времени активной работы от общего времени выполнения задачи^[15].

• Метрики предсказуемости^[16] — помогают анализировать стабильность процессов:

Вариативность времени выполнения (англ. Lead Time variance) — степень разброса времени выполнения задач; низкая вариативность указывает на высокую предсказуемость процесса^[17].

Для оценки работы программного обеспечения в реальных условиях используются высокоуровневые метрики производительности и стабильности^[18]. К основным показателям относятся:

• Потребление ресурсов — уровень использования центрального процессора, оперативной памяти и дисковой подсистемы^[19].
• Время отклика (англ. Response Time) — скорость реакции системы на действия пользователя^[19].
• Среднее время наработки на отказ (англ. Mean Time Between Failures, MTBF) — средняя продолжительность работы системы без сбоев^[18].
• Время безотказной работы (англ. Uptime) — процент времени, в течение которого система доступна и функционирует^[18].
• Частота сбоев приложения (англ. Application Crash Rate) — показатель частоты аварийных завершений работы программы.

В рамках практики обеспечения надёжности (англ. Site Reliability Engineering, SRE) применяется подход к управлению качеством, основанный на иерархии метрик^[20]:

• Индикаторы уровня обслуживания (англ. Service Level Indicator, SLI) — количественные показатели фактической работы сервиса с точки зрения пользователя (например, доступность, задержка, процент ошибок)^[20].
• Цели уровня обслуживания (англ. Service Level Objective, SLO) — целевые значения или диапазоны для SLI, определяющие приемлемый уровень надёжности^[20].
• Бюджет ошибок (англ. Error Budget) — допустимый уровень несоблюдения SLO. Он рассчитывается как разница между 100 % и целевым показателем SLO, позволяя командам принимать объективные решения о балансе между внедрением новых функций и обеспечением стабильности продукта^[20].^[21]

В рамках подхода, основанного на данных (Data-Driven), метрики безопасности в DevSecOps смещают акцент с простого подсчёта уязвимостей на непрерывное измерение и улучшение процессов безопасности^[22]. Ключевыми категориями таких показателей являются:

• Метрики эффективности процессов:

Среднее время на устранение (англ. Mean Time to Remediate, MTTR) — показывает, как быстро исправляются обнаруженные уязвимости^[23]. Среднее время на обнаружение (англ. Mean Time to Detect, MTTD) — измеряет время с момента появления уязвимости до её обнаружения^[23]. Плотность уязвимостей (англ. Vulnerability Density) — количество уязвимостей на единицу кода (например, на 1000 строк).

• Метрики покрытия:

Покрытие сканирования (SAST/DAST) — доля приложений или репозиториев, которые регулярно проходят статическое и динамическое тестирование^[24]. Для оценки технического долга в области безопасности также отслеживается количество открытых уязвимостей (англ. Vulnerability Open Rate) — показатель, отражающий общее число неисправленных уязвимостей в системе^[25].

Для связи процессов разработки с бизнес-результатами применяется концепция Метрики Полярной звезды (англ. North Star Metric, NSM). Это ключевой показатель, который наиболее точно отражает основную ценность продукта для пользователей, а его рост связан с долгосрочным ростом компании. В управлении департаментами NSM служит единым ориентиром для синхронизации усилий всех подразделений: вся компания фокусируется на главной метрике, в то время как отдельные отделы работают над тактическими «входными» метриками, напрямую влияющими на NSM^[26]. Современные подходы к измерению стоимости разработки и эксплуатации программного обеспечения включают методологии FinOps и юнит-экономики, которые смещают фокус с традиционных затрат на оценку экономической эффективности:

• FinOps — практика управления облачными затратами. Одной из ключевых метрик является стоимость единицы облачной услуги (англ. Cloud Cost per Unit, CCPU), которая оценивает затраты на ресурсы относительно предоставляемых услуг (например, стоимость одной транзакции или обслуживания одного пользователя)^[27].^[28]
• Юнит-экономика — метод анализа прибыльности через расчёт рентабельности одного пользователя. Основными метриками выступают пожизненная ценность клиента (англ. Lifetime Value, LTV) и стоимость его привлечения (англ. Customer Acquisition Cost, CAC). Бизнес-модель считается устойчивой, если LTV превышает CAC^[29].

Для оценки продуктивности и благополучия команд разработчиков применяется фреймворк SPACE. Он представляет собой многомерную модель, разработанную в 2021 году исследователями из Microsoft, GitHub и Университета Виктории, которая предлагает целостный взгляд на продуктивность, выходящий за рамки традиционных метрик^[30]. Название SPACE является акронимом, обозначающим пять ключевых измерений:

• Удовлетворённость и благополучие (англ. Satisfaction and well-being) — оценивает, насколько разработчики довольны своей работой, инструментами и командой (примеры показателей: уровень выгорания, баланс работы и личной жизни, результаты опросов).
• Результативность (англ. Performance) — фокусируется на результатах работы и создаваемой ценности, а не на её объёме (примеры показателей: качество кода, надёжность системы, удовлетворённость клиентов).
• Активность (англ. Activity) — отслеживает действия и объёмы выполненной работы в процессе разработки (примеры показателей: количество коммитов, пул-реквестов, ревью кода).
• Коммуникация и сотрудничество (англ. Communication and collaboration) — оценивает эффективность совместной работы, обмена знаниями и интеграции (примеры показателей: качество и скорость ревью кода, качество документации).
• Эффективность и поток (англ. Efficiency and flow) — измеряет способность разработчиков работать плавно и без прерываний (примеры показателей: время выполнения задачи, частота развёртываний, время, затрачиваемое на совещания).

Фреймворк предлагает организациям выбирать сбалансированный набор показателей из всех пяти категорий в зависимости от их конкретных целей и контекста^[30].

Метрики устойчивого развития программного обеспечения (также известные как метрики Green IT) представляют собой количественные меры для оценки экологического воздействия программных продуктов на протяжении их жизненного цикла. Их основная цель — создание энергоэффективного и углеродно-эффективного программного обеспечения^[31]. Ключевые метрики оценки углеродного следа и энергоэффективности включают:

• Потребление энергии — базовая метрика, измеряющая количество электроэнергии, которое потребляет программное обеспечение во время работы^[32].
• Углеродный след (англ. Carbon Footprint) — оценка общего количества выбросов парниковых газов (в эквиваленте CO₂), связанных с работой программного обеспечения^[31].
• Software Carbon Intensity (SCI) — специализированная метрика для оценки углеродной эффективности приложения. Она учитывает потребляемую энергию, углеродную интенсивность источника энергии, выбросы от производства оборудования и выбранную функциональную единицу (например, количество транзакций или активных пользователей)^[33].
• Power Usage Effectiveness (PUE) — показатель эффективности использования энергии в центрах обработки данных (ЦОД). Данная метрика косвенно влияет на оценку программного обеспечения: работа в ЦОД с низким PUE означает меньшие косвенные энергозатраты на охлаждение и инфраструктуру^[32].

Оценка систем искусственного интеллекта и машинного обучения (MLOps), а также кода, сгенерированного ИИ, требует применения специализированных метрик. В методологии MLOps для оценки качества данных и производительности моделей применяются следующие показатели:^[34]

• Дрейф данных (англ. Data Drift) — статистическое изменение распределения входных данных между обучающей выборкой и реальными данными в рабочей среде^[35].
• Точность (англ. Precision) и полнота (англ. Recall) — метрики, показывающие долю релевантных объектов среди найденных и долю найденных релевантных объектов от их общего числа соответственно^[34].
• Дрейф концепции (англ. Concept Drift) — изменение статистического распределения выходных данных модели или ухудшение её производительности с течением времени^[34].

Для оценки качества и безопасности исходного кода, созданного искусственным интеллектом, традиционные метрики дополняются многоуровневой системой оценки:^[36]

• Модульные тесты (англ. Unit Tests) — базовый уровень проверки корректности сгенерированных функций и сценариев^[37].
• A/B-тестирование — применяется для оценки производительности ИИ-системы в реальных условиях путём сравнения различных версий моделей.
• Строгие проверки безопасности — направлены на выявление типичных уязвимостей, которые часто встречаются в сгенерированном коде, таких как SQL-инъекции (CWE-89) и использование устаревших криптографических алгоритмов (CWE-327)^[36].

Подход, основанный на данных (Data-Driven), в управлении разработкой программного обеспечения представляет собой методологию, при которой решения принимаются на основе анализа объективных показателей. Ключевую роль в реализации этого подхода играют единые хранилища данных (DWH), которые обеспечивают централизованный сбор и консолидацию информации из разрозненных источников, таких как системы контроля версий, таск-трекеры и инструменты CI/CD^[38].^[39]

Современной тенденцией в управлении на основе данных является использование искусственного интеллекта для прогнозного управления качеством. ИИ и модели машинного обучения применяются для анализа исторических данных и изменений в коде с целью прогнозирования рисков и выявления модулей, подверженных дефектам. Это позволяет командам переходить от реактивного обнаружения ошибок к их проактивному предотвращению^[40].

Потенциальные недостатки подхода, на которые нацелена критика:

• Неэтичность: Утверждается, что неэтично судить о производительности программиста по метрикам, введенным для оценки эффективности программного кода. Такие известные метрики, как количество строк кода и цикломатическая сложность, часто дают поверхностное представление об «удачности» выбора того или иного подхода при решении поставленных задач, однако нередко они рассматриваются как инструмент оценки качества работы разработчика. Такой подход достаточно часто приводит к обратному эффекту: в коде появляются более длинные конструкции и избыточные необязательные методы.
• Замещение «управления людьми» на «управление цифрами», которое не учитывает опыт сотрудников и их другие качества.
• Искажение: Процесс измерения может быть искажён за счёт того, что сотрудники знают об измеряемых показателях и стремятся оптимизировать эти показатели, а не свою работу. Например, если количество строк исходного кода является важным показателем, то программисты будут стремиться писать как можно больше строк и не будут использовать способы упрощения кода, сокращающие количество строк.
• Неточность: Нет метрик, которые были бы одновременно и значимы, и достаточно точны. Количество строк кода — это просто количество строк, этот показатель не даёт представления о сложности решаемой проблемы. Анализ функциональных точек был разработан с целью лучшего измерения сложности кода и спецификации, но он использует личные оценки измеряющего, поэтому разные люди получат разные результаты.
• Манипуляция данными (gaming the system) в рамках подхода, основанного на данных (Data-Driven): при внедрении метрик разработчики могут начать оптимизировать свою деятельность ради улучшения показателей в ущерб качеству продукта. Эта проблема описывается законом Гудхарта, согласно которому мера, ставшая целью, перестаёт быть хорошей мерой^[41].
• Ограниченность метрик DORA: показатели оценивают в первую очередь скорость и стабильность доставки, игнорируя бизнес-результаты и реальную ценность продукта для пользователя. Существует риск «погони за скоростью», а анализ данных без учёта контекста приводит к неверным выводам^[42].
• Риски применения искусственного интеллекта для оценки метрик: результаты работы ИИ подвержены предвзятости алгоритмов из-за некачественных обучающих данных. Также выделяются проблема «чёрного ящика» (непрозрачность логики принятия решений) и риск «галлюцинаций» — генерации правдоподобных, но ложных оценок^[43][44][45].