От теории к практике: как ГОСТ Р ИСО/МЭК 25010:2015 улучшает качество софта
ГОСТ Р ИСО/МЭК 25010:2015 — это национальный стандарт РФ, гармонизированный с международным ISO/IEC 25010, который определяет единую модель оценки качества программного обеспечения. Его главная цель — заменить субъективное мнение «работает/не работает» на измеримые метрики по 8 ключевым характеристикам (функциональность, надежность, безопасность и др.). Применение стандарта позволяет командам выявлять риски на ранних этапах, упрощает приемку госзаказов и создает прозрачную систему требований для разработчиков и заказчиков.
Суть стандарта и отличие от предшественников
До 2015 года в России действовал ГОСТ 28195-89, который фокусировался преимущественно на технических параметрах. Новый стандарт смещает акцент на качество в использовании (Quality in Use). Это означает, что программа считается качественной не только если в ней нет багов, но и если она эффективна, безопасна и удовлетворяет потребности пользователя в конкретном контексте.
Стандарт описывает две взаимосвязанные модели:
- Модель качества продукта — внутренние и внешние характеристики самого кода и системы.
- Модель качества в использовании — результат взаимодействия пользователя с системой в реальной среде.
Где обязателен стандарт? ГОСТ Р ИСО/МЭК 25010:2015 является базой для сертификации ПО в рамках технических регламентов Таможенного союза (например, ТР ТС 020/2011) и часто требуется в тендерах для государственных информационных систем (ГИС).
8 характеристик качества продукта
Это ядро стандарта. Каждая из 8 характеристик декомпозируется на подхарактеристики, которые можно превратить в конкретные метрики для чек-листов и автотестов.
| Характеристика | Что оцениваем | Примеры подхарактеристик | Практическая метрика |
|---|---|---|---|
| Функциональная пригодность | Соответствие заявленным функциям | Полнота, корректность, уместность | % реализованных требований из ТЗ; количество ложных срабатываний. |
| Производительность | Эффективность ресурсов | Временная характеристика, утилизация ресурсов | Время отклика < 2 сек при нагрузке 1000 RPS; потребление RAM < 512 Мб. |
| Совместимость | Взаимодействие с окружением | Сосуществование, взаимозаменяемость | Успешный обмен данными с API партнеров; работа на разных версиях ОС. |
| Используемость | Удобство для человека | Понятность, обучаемость, защита от ошибок | Время выполнения целевого действия новичком; уровень удовлетворенности (SUS). |
| Надежность | Стабильность работы | Зрелость, доступность, отказоустойчивость | Uptime 99.9%; среднее время восстановления (MTTR) < 1 часа. |
| Безопасность | Защита данных и доступа | Конфиденциальность, целостность, неотказуемость | Отсутствие уязвимостей уровня Critical по итогам сканирования; наличие 2FA. |
| Поддерживаемость | Легкость изменений кода | Модульность, переиспользуемость, анализируемость | Покрытие кода тестами > 80%; цикломатическая сложность функций < 10. |
| Переносимость | Адаптация к новым средам | Адаптируемость, устанавливаемость, заменяемость | Время развертывания на новом сервере; успешная установка на разные дистрибутивы Linux. |
Качество в использовании: взгляд глазами клиента
В отличие от технических метрик, эта группа оценивает итоговый опыт. Она критически важна для бизнес-приложений и потребительских сервисов. Стандарт выделяет пять аспектов:
- Эффективность: Насколько точно и полно пользователи достигают своих целей.
- Продуктивность: Затраты ресурсов (времени, денег) на достижение цели.
- Безопасность (в контексте использования): Отсутствие рисков для людей, бизнеса или имущества при эксплуатации.
- Удовлетворенность: Комфорт, доверие и удовольствие от использования.
- Свобода от рисков: Минимизация экономического ущерба или вреда здоровью.
Лайфхак для метрик Не пытайтесь измерить всё сразу. Для стартапа на ранней стадии приоритетны Функциональная пригодность и Используемость. Для финтех-проекта на первом месте всегда Безопасность и Надежность. Выберите топ-3 характеристики для текущего спринта.
Пошаговый план внедрения стандарта в разработку
Внедрение ГОСТ Р ИСО/МЭК 25010:2015 не требует бюрократии, если интегрировать его процессы в существующий цикл разработки (SDLC).
Шаг 1. Анализ контекста и выбор приоритетов
Соберите команду (менеджер, разработчик, тестировщик, представитель заказчика). Определите, какие характеристики критичны для вашего продукта.
- Пример: Для медицинского ПО критична Безопасность и Надежность. Для игры — Производительность и Используемость.
Шаг 2. Декомпозиция на метрики
Превратите абстрактные понятия в цифры.
- Вместо «система должна быть быстрой» пишем: «Время загрузки главной страницы не более 1.5 с при скорости канала 10 Мбит/с».
- Вместо «код должен быть чистым» — «Индекс поддерживаемости в SonarQube не ниже A».
Шаг 3. Инструментарий и автоматизация
Настройте пайплайны CI/CD для сбора метрик:
- Статический анализ: SonarQube, PVS-Studio (для Поддерживаемости и Безопасности).
- Нагрузочное тестирование: JMeter, k6 (для Производительности и Надежности).
- UX-аналитика: Яндекс.Метрика, Hotjar, опросы NPS ( для Используемости и Удовлетворенности).
Шаг 4. Регулярный аудит и отчетность
Внедрите еженедельные дашборды качества. Если метрика падает ниже порога (например, покрытие тестами упало с 85% до 70%), сборка не должна попадать в продакшен.
Частая ошибка Игнорирование характеристики «Переносимость». Разработчики часто тестируют софт только на своих машинах. В результате при установке у заказчика возникают ошибки зависимостей или прав доступа, что формально является нарушением стандарта.
Типичные ошибки при оценке качества
- Подмена понятий: Считать, что отсутствие багов = высокое качество. Баг может быть исправлен, но если система неудобна (низкая используемость), качество все равно низкое.
- Отсутствие базовых линий: Невозможно сказать, стало ли лучше, если вы не зафиксировали показатели «как было» до начала работ.
- Формальный подход: Заполнение таблиц соответствия ГОСТу «задним числом» перед сдачей проекта, вместо реального использования метрик в процессе разработки.
Часто задаваемые вопросы (FAQ)
Нужно ли сертифицировать ПО по этому ГОСТу обязательно? Для коммерческих продуктов — нет, это добровольный стандарт. Однако он становится обязательным, если этого требует контракт (особенно с госзаказчиками) или если продукт подлежит обязательной сертификации по техрегламентам (например, средства криптографии или медицинские изделия).
Заменяет ли этот стандарт техническое задание (ТЗ)? Нет, он дополняет его. В ТЗ вы пишете что должна делать система, а ГОСТ Р ИСО/МЭК 25010 помогает описать как хорошо она должна это делать (критерии приемки).
Как применить стандарт в Agile-команде? Интегрируйте проверки характеристик в Definition of Done (DoD). Например, задача не считается закрытой, пока не пройден тест на производительность и код не проверен статическим анализатором согласно выбранным подхарактеристикам.
Можно ли использовать стандарт для оценки легаси-кода? Да, это один из лучших способов провести аудит старой системы. Прогоните код по 8 характеристикам, чтобы выявить «узкие места» (технический долг) и построить план рефакторинга.