АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыСпецпроектыСтать автором
Сменить язык
О РУВИКИ

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

Ме́трика програ́ммного обеспе́чения (англ. software metric) — мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций.

Поскольку количественные методы хорошо зарекомендовали себя в других областях, многие теоретики и практики информатики пытались перенести данный подход и в разработку программного обеспечения. Как сказал Том ДеМарко, «вы не можете контролировать то, что не можете измерить».

В современном жизненном цикле разработки программного обеспечения метрики выполняют функции объективного измерения и прогнозирования, связывая технические аспекты с бизнес-показателями[1]. В контексте подхода, основанного на данных (Data-Driven), они используются для принятия решений, смещая фокус с исключительно технических характеристик на достижение бизнес-целей и создание ценности для клиента[2].

Современная концепция также базируется на метриках устойчивости программного обеспечения (англ. software sustainability metrics), которые оценивают способность систем стабильно приносить пользу с течением времени. Этот подход требует баланса трёх ключевых аспектов: технической (сопровождаемость и технический долг), экологической (ресурсоэффективность и снижение энергопотребления) и экономической устойчивости (финансовая эффективность эксплуатации и поддержки).

История развития

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

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

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

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

В период 2020–2026 годов индустрия разработки программного обеспечения перешла от использования исключительно метрик доставки к многомерным подходам и AI-нативной разработке. В дополнение к DORA стали внедряться фреймворки SPACE (оценка удовлетворённости, производительности и коммуникации), DevEx (фокус на повседневном опыте разработчиков) и унифицированная модель DX Core 4. Современные подходы измеряют когнитивную нагрузку, состояние потока и комплексную эффективность, включающую скорость, качество и влияние на бизнес. С развитием искусственного интеллекта появились специфические метрики: доля сгенерированного ИИ кода, выживаемость кода и пропускная способность с учётом сложности задач (CAT). Новый этап ознаменовал отказ от сведения продуктивности к одному показателю, позволив сбалансировать скорость доставки с качеством кода и благополучием команд, а также предотвратить искусственное завышение показателей при массовой генерации кода нейросетями[7][8][9][10][11].

Классификация метрик

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

Метрики уровня кода

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

Метрики процесса и потока

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

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

Частота развёртывания (англ. Deployment Frequency) — измеряет, как часто изменения успешно выпускаются в рабочую среду[17]. Время выполнения изменений (англ. Lead Time for Changes) — время с момента фиксации кода до его успешного развёртывания (в отличие от общего времени выполнения, англ. Lead Time, которое отсчитывается от момента поступления запроса)[18]. Коэффициент сбоев при изменениях (англ. Change Failure Rate) — процент развёртываний, приводящих к сбоям и требующих вмешательства[17]. Время восстановления после неудачного развёртывания (англ. Failed deployment recovery time) — время, необходимое для восстановления после сбоя, вызванного непосредственно развёртыванием[19].[20] Доля переделок при развёртывании (англ. Deployment rework rate) — доля незапланированных развёртываний, происходящих в результате инцидента в рабочей среде[19].[20]

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

Время цикла (англ. Cycle Time) — время, в течение которого задача находится непосредственно в активной работе, без учёта простоев. Эффективность потока (англ. Flow Efficiency) — доля времени активной работы от общего времени выполнения задачи[22]. Скорость потока (англ. Flow Velocity) — количество рабочих элементов, завершённых за определённый период времени[23]. Нагрузка потока (англ. Flow Load) — объём незавершённой работы, активно обрабатываемой в потоке в любой момент времени[23]. Распределение потока (англ. Flow Distribution) — распределение рабочих элементов по типам (например, новые функции, дефекты, технический долг)[23].

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

Вариативность времени выполнения (англ. Lead Time variance) — степень разброса времени выполнения задач; низкая вариативность указывает на высокую предсказуемость процесса[25]. Пропускная способность (англ. Throughput) — количество задач или единиц работы, успешно завершённых за определённый период времени[26]. Незавершённое производство (англ. Work in Progress, WIP) — количество задач, которые уже взяты в работу, но ещё не доведены до конца[26].

Метрики надежности и производительности

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

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

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

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

Метрики безопасности (DevSecOps)

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

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

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

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

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

Продуктовые и бизнес-метрики

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

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

Базовые метрики скорости поставки программного обеспечения, такие как время выполнения (англ. Lead Time) и частота развёртываний (англ. Deployment Frequency), не являются стандартом для оценки бизнес-ценности. Из-за массового использования искусственного интеллекта для генерации кода эти показатели искажаются: они фиксируют снижение времени выполнения и рост частоты развёртываний, что отражает лишь скорость работы ИИ, а не реальную ценность для бизнеса. Для связи инженерных процессов с финансовыми результатами и бизнес-влиянием базовые метрики необходимо расширять дополнительными фреймворками (например, Core 4), которые учитывают сложность задач и итоговый результат[42][43].

Метрики опыта разработчиков

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

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

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

В 2023 году в качестве дополнения к SPACE был представлен фреймворк Developer Experience (DevEx), фокусирующийся на человеческом опыте разработчиков[45]. Он базируется на трёх основных столпах:

  • Циклы обратной связи (англ. Feedback Loops) — скорость и качество ответов от инструментов и людей на действия разработчика[46][47].
  • Когнитивная нагрузка (англ. Cognitive Load) — объём умственных усилий, необходимых для выполнения рабочих задач[47].
  • Состояние потока (англ. Flow State) — способность входить в состояние глубокой сфокусированности на значимой работе без прерываний[46][47].

Метрики устойчивого развития

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

  • Потребление энергии — базовая метрика, измеряющая количество электроэнергии, которое потребляет программное обеспечение во время работы[49].
  • Углеродный след (англ. Carbon Footprint) — оценка общего количества выбросов парниковых газов (в эквиваленте CO₂), связанных с работой программного обеспечения[48].
  • Software Carbon Intensity (SCI) — специализированная метрика (стандарт ISO/IEC 21031:2024) для оценки углеродной эффективности приложения. Она рассчитывается по формуле SCI = ((E × I) + M) / R, где учитываются потребляемая энергия (E), углеродная интенсивность источника энергии (I), выбросы от производства оборудования (M) и выбранная функциональная единица (R, например, количество транзакций или активных пользователей)[50].
  • Power Usage Effectiveness (PUE) — показатель эффективности использования энергии в центрах обработки данных (ЦОД). Данная метрика косвенно влияет на оценку программного обеспечения: работа в ЦОД с низким PUE означает меньшие косвенные энергозатраты на охлаждение и инфраструктуру[49].

С 2026 года в России введена обязательная экологическая отчётность для дата-центров. На основании Федерального закона № 244-ФЗ от 23 июля 2025 года, закрепившего определение ЦОД, с 1 марта 2026 года Минцифры России ведёт реестр дата-центров[49].

Метрики систем искусственного интеллекта

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

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

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

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

Для комплексной оценки LLM-кодогенерации исторически применялись бенчмарки HumanEval и MBPP. В связи с перенасыщением этих тестов и риском их попадания в обучающие выборки моделей, индустрия перешла к новым стандартам, таким как SWE-bench Verified (оценка решения реальных багов в многофайловых open-source репозиториях) и LiveCodeBench (защита от утечек данных за счёт постоянного сбора новых задач)[56].

Управление на основе данных (Data-Driven)

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

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

Критика

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

  • Неэтичность: Утверждается, что неэтично судить о производительности программиста по метрикам, введенным для оценки эффективности программного кода. Такие известные метрики, как количество строк кода и цикломатическая сложность, часто дают поверхностное представление об «удачности» выбора того или иного подхода при решении поставленных задач, однако нередко они рассматриваются как инструмент оценки качества работы разработчика. Такой подход достаточно часто приводит к обратному эффекту: в коде появляются более длинные конструкции и избыточные необязательные методы.
  • Замещение «управления людьми» на «управление цифрами», которое не учитывает опыт сотрудников и их другие качества.
  • Искажение: Процесс измерения может быть искажён за счёт того, что сотрудники знают об измеряемых показателях и стремятся оптимизировать эти показатели, а не свою работу. Например, если количество строк исходного кода является важным показателем, то программисты будут стремиться писать как можно больше строк и не будут использовать способы упрощения кода, сокращающие количество строк.
  • Неточность: Нет метрик, которые были бы одновременно и значимы, и достаточно точны. Количество строк кода — это просто количество строк, этот показатель не даёт представления о сложности решаемой проблемы. Анализ функциональных точек был разработан с целью лучшего измерения сложности кода и спецификации, но он использует личные оценки измеряющего, поэтому разные люди получат разные результаты.
  • Манипуляция данными (gaming the system) в рамках подхода, основанного на данных (Data-Driven): при внедрении метрик разработчики могут начать оптимизировать свою деятельность ради улучшения показателей в ущерб качеству продукта. Эта проблема описывается законом Гудхарта, согласно которому мера, ставшая целью, перестаёт быть хорошей мерой[60]. Для предотвращения искажений применяется методология «балансирующих метрик» (balancing metrics)[61].
  • Ограниченность метрик DORA: показатели оценивают в первую очередь скорость и стабильность доставки, игнорируя бизнес-результаты и реальную ценность продукта для пользователя. Существует риск «погони за скоростью», а анализ данных без учёта контекста приводит к неверным выводам[62]. Применение метрик DORA для индивидуальной оценки разработчиков признано антипаттерном, стимулирующим искусственное завышение активности (например, создание микро-коммитов)[63].
  • Риски применения искусственного интеллекта для оценки метрик: результаты работы ИИ подвержены предвзятости алгоритмов из-за некачественных обучающих данных. Также выделяются проблема «чёрного ящика» (непрозрачность логики принятия решений), для решения которой ещё не приняты единые стандарты объяснимого ИИ (XAI)[64], и риск «галлюцинаций» — генерации правдоподобных, но ложных оценок[65][66][67].

Примечания

  1. ↑ Роль метрик в разработке программного обеспечения. Новости ИТ-канала. Дата обращения: 30 апреля 2026.
  2. ↑ Data-Driven подход: что это, зачем нужен и как внедрить. Sales Generator. Дата обращения: 30 апреля 2026.
  3. ↑ Cyclomatic Complexity. SonarSource. Дата обращения: 27 августа 2026.
  4. ↑ Halstead's Software Metrics. GeeksforGeeks. Дата обращения: 27 августа 2026.
  5. ↑ CAST Enforce Object Oriented Metrics - Chidamber and Kemerer Metrics Suite. doc.castsoftware.com. CAST Software. Дата обращения: 27 августа 2026.
  6. ↑ 1 2 What are DORA metrics? Atlassian. Дата обращения: 27 августа 2026.
  7. ↑ Developer Productivity Metrics: The Shift to Multidimensional Measurement. Zylos AI (7 февраля 2026). Дата обращения: 27 августа 2026.
  8. ↑ SPACE Framework Explained. Larridin. Дата обращения: 27 августа 2026.
  9. ↑ How to Measure Developer Productivity: DORA, SPACE, DevEx, DX Core 4. ES.NL. Дата обращения: 27 августа 2026.
  10. ↑ DORA Metrics Explained: Complete Guide. Larridin. Дата обращения: 27 августа 2026.
  11. ↑ DORA Metrics Tools. GetDX. Дата обращения: 27 августа 2026.
  12. ↑ Метрики продукта: как выбрать, считать и использовать. GoPractice. Дата обращения: 30 апреля 2026.
  13. ↑ Классификация метрик качества программного обеспечения. Fortus Science. Дата обращения: 30 апреля 2026.
  14. ↑ Product Metrics in Software Engineering. GeeksforGeeks. Дата обращения: 27 августа 2026.
  15. ↑ Cognitive Complexity: Because Testability != Understandability. SonarSource. Дата обращения: 27 августа 2026.
  16. ↑ Technical Debt Ratio: The Ultimate Guide. GetDX. Дата обращения: 27 августа 2026.
  17. ↑ 1 2 DORA Metrics. dora.dev. Дата обращения: 27 августа 2026.
  18. ↑ Lead Time for Changes: What it is and How to Measure it. Plandek. Дата обращения: 27 августа 2026.
  19. ↑ 1 2 DORA Metrics. dora.dev. Дата обращения: 27 августа 2026.
  20. ↑ 1 2 DORA Metrics 2026: Why Four Became Five. alekseialeinikov.com. Дата обращения: 27 августа 2026.
  21. ↑ Flow vs DORA Metrics: Benefits Together. mstone.ai. Дата обращения: 27 августа 2026.
  22. ↑ Как использовать метрики для повышения эффективности команды разработки. tproger.ru. Дата обращения: 30 апреля 2026.
  23. ↑ 1 2 3 Flow Metrics. agility-at-scale.com. Дата обращения: 27 августа 2026.
  24. ↑ Что такое предсказуемость выполнения задач и как ее понять. kanbanguide.ru. Дата обращения: 30 апреля 2026.
  25. ↑ Как измерить предсказуемость разработки. habr.com. Дата обращения: 27 августа 2026.
  26. ↑ 1 2 Kanban Metrics Guide. VirtuSoftware. Дата обращения: 27 августа 2026.
  27. ↑ 1 2 3 Ключевые метрики доступности и производительности. Proverator. Дата обращения: 30 апреля 2026.
  28. ↑ 1 2 Метрики производительности. Хабр. Microsoft. Дата обращения: 27 августа 2026.
  29. ↑ 1 2 3 4 SLI, SLO, SLA и Error Budget: что это такое и как их использовать. Хабр. Дата обращения: 27 августа 2026.
  30. ↑ SLI, SLO, Error Budget: как измерить стабильность сервиса. Setka. Дата обращения: 30 апреля 2026.
  31. ↑ 1 2 Error Budget SRE: Как управлять надежностью. isdown.app. Дата обращения: 27 августа 2026.
  32. ↑ Alerting on SLOs. SRE Workbook. Google. Дата обращения: 27 августа 2026.
  33. ↑ Error Budgets Explained. OpenObserve. Дата обращения: 27 августа 2026.
  34. ↑ Как не заблудиться в лесу метрик QA: классический и Data-Driven подходы. TestIT. Дата обращения: 27 августа 2026.
  35. ↑ 1 2 Метрики безопасности и показатели эффективности. DataFinder. Дата обращения: 30 апреля 2026.
  36. ↑ Security Assessment: Stay Ahead of Cyber Threats, Protect Your Business. Xygeni. Дата обращения: 27 августа 2026.
  37. ↑ Vulnerability Management Metrics: What to Track and Why. PurpleSec. Дата обращения: 27 августа 2026.
  38. ↑ Метрика North Star: что это такое и как используется в крупных компаниях. Timeweb. Дата обращения: 27 августа 2026.
  39. ↑ FinOps: полное руководство по управлению облачными расходами. Pritula Academy. Дата обращения: 27 августа 2026.
  40. ↑ Основные метрики и показатели FinOps. Cloudmaster. Дата обращения: 30 апреля 2026.
  41. ↑ Юнит-экономика: как оценить успешность бизнеса. Uplab. Дата обращения: 30 апреля 2026.
  42. ↑ DORA Metrics Explained: Complete Guide 2026. Larridin. Дата обращения: 27 августа 2026.
  43. ↑ DORA Metrics: The Complete Guide. GetDX. Дата обращения: 27 августа 2026.
  44. ↑ 1 2 The SPACE Framework: A Comprehensive Guide to Developer Productivity. Jellyfish. Дата обращения: 27 августа 2026.
  45. ↑ The DevEx Framework: A Guide to Measuring Developer Experience. Shipyard (26 октября 2023). Дата обращения: 27 августа 2026.
  46. ↑ 1 2 Developer Experience (DevEx): A Complete Guide. Taskade (15 января 2024). Дата обращения: 27 августа 2026.
  47. ↑ 1 2 3 Developer Experience: A Developer-Centric Approach to Productivity. Worklytics (1 ноября 2023). Дата обращения: 27 августа 2026.
  48. ↑ 1 2 Green Software Development. Meegle. Дата обращения: 27 августа 2026.
  49. ↑ 1 2 3 Green IT: обязательная экологическая отчетность для дата-центров в России с 2026 года. MosDigitals. Дата обращения: 30 апреля 2026.
  50. ↑ Software Carbon Intensity (SCI) Standard. Green Software Foundation. Дата обращения: 27 августа 2026.
  51. ↑ 1 2 3 MLOps и Product Management для ML. Big Data School. Дата обращения: 30 апреля 2026.
  52. ↑ Мониторинг ML-моделей в продакшене: метрики и инструменты. Хабр. Дата обращения: 27 августа 2026.
  53. ↑ Как тестировать AI-продукты: от модульных тестов до оценки человеком. Хабр. Дата обращения: 27 августа 2026.
  54. ↑ HumanEval benchmark. systems-analysis.ru. Дата обращения: 27 августа 2026.
  55. ↑ Pass@k Objective. Emergent Mind. Дата обращения: 27 августа 2026.
  56. ↑ HumanEval & MBPP Code Generation Benchmarks. Verity AI. Дата обращения: 27 августа 2026.
  57. ↑ Data-Driven подход: как принимать решения на основе данных. Reshape. Дата обращения: 30 апреля 2026.
  58. ↑ Единый центр данных для управления разработкой. GlobalCIO. Дата обращения: 30 апреля 2026.
  59. ↑ ISO 9001:2026, Digitalization, AI and the Future of Quality Management. Ideagen. Дата обращения: 27 августа 2026.
  60. ↑ Закон Гудхарта и метрики разработки. Хабр. Beget. Дата обращения: 27 августа 2026.
  61. ↑ Goodhart's Law and Engineering Metrics. CodePulse HQ. Дата обращения: 27 августа 2026.
  62. ↑ Everything Wrong with DORA Metrics. Aviator. Дата обращения: 27 августа 2026.
  63. ↑ The DORA Metrics: What They Measure, What Leaders Need to Know. Hyperdrive Agile. Дата обращения: 27 августа 2026.
  64. ↑ Как раскрыть «черный ящик»: объяснимый ИИ для Индустрии 5.0. CyberLeninka. Дата обращения: 27 августа 2026.
  65. ↑ Ethical AI: Overcoming Bias. Shaip. Дата обращения: 27 августа 2026.
  66. ↑ The Limitations of AI in Custom Software. Demski Group. Дата обращения: 27 августа 2026.
  67. ↑ Common Mistakes When Implementing AI. Quanter. Дата обращения: 27 августа 2026.

Ссылки

Категории