exam

Основные требования к качеству программного обеспечения.

Основные требования к качеству программного обеспечения (ПО) опираются на международные и отраслевые стандарты — в первую очередь на ISO/IEC 25010:2011, который задаёт модель качества ПО. Требования делят на функциональные и нефункциональные; вместе они определяют, что система должна делать и насколько хорошо она это делает.


Функциональные требования

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

  • Полнота реализации функций. Все заявленные возможности должны быть реализованы в соответствии с требованиями и пользовательскими сценариями.
  • Корректность поведения. Система должна выдавать ожидаемые результаты при корректных входных данных; обработка граничных и ошибочных случаев должна быть явно описана.
  • Соответствие бизнес‑логике и правилам предметной области. Особенно важно в регулируемых отраслях (финансы, медицина, госсектор): ПО должно учитывать нормативные требования и внутренние регламенты.
  • Точность вычислений. Для расчётов (бухгалтерия, аналитика, инженерия) задают допустимую погрешность, разрядность и правила округления.
  • Правильная обработка исключений и ошибок. Система должна сообщать пользователю понятную причину сбоя и предлагать дальнейшие действия, а разработчикам — давать диагностическую информацию.

Нефункциональные требования (атрибуты качества)

Это характеристики, которые определяют, как система работает. По ISO/IEC 25010 к ним относятся:

  • Надёжность. Способность ПО стабильно работать в заданных условиях. Сюда входят:
    • Доступность (uptime, SLA) — например, 99,9% времени в год.
    • Устойчивость к сбоям — корректная реакция на ошибки оборудования, сети, внешних сервисов.
    • Восстанавливаемость — время и процедуры восстановления после аварии, наличие бэкапов и плана DR.
  • Производительность. Измеряется конкретными метриками:
    • Время отклика API и страниц (например, ≤200 мс для API, ≤2 с для загрузки страницы).
    • Пропускная способность (запросов в секунду).
    • Потребление ресурсов (CPU, RAM, дисковое пространство, сетевой трафик).
    • Поведение под пиковой и стрессовой нагрузкой.
  • Безопасность. Защита данных и инфраструктуры от угроз:
    • Аутентификация и авторизация (ролевая модель, MFA).
    • Шифрование данных в покое и при передаче (TLS, шифрование БД).
    • Защита от типовых уязвимостей (OWASP Top 10): инъекции, XSS, CSRF, SSRF и др.
    • Управление секретами, аудит действий, журналирование инцидентов.
  • Удобство использования (юзабилити). ПО должно быть понятным и предсказуемым для целевой аудитории:
    • Соответствие гайдлайнам платформ и стандартам доступности (WCAG).
    • Логичная навигация, понятные сообщения об ошибках, подсказки.
    • Адаптивность под разные устройства и размеры экранов.
  • Сопровождаемость. Насколько легко поддерживать и развивать систему:
    • Модульная архитектура, чёткие границы ответственности компонентов.
    • Документация (архитектура, API, инструкции по запуску и деплою).
    • Покрытие тестами, понятные коммиты, стандартизированный стиль кода.
    • Возможность быстрого онбординга новых разработчиков.
  • Переносимость (портативность). Способность работать в разных окружениях:
    • Поддержка нескольких ОС, браузеров, устройств.
    • Независимость от проприетарных технологий там, где это критично.
    • Контейнеризация (Docker) и декларативная инфраструктура (IaC) для воспроизводимости среды.
  • Совместимость. Взаимодействие с другими системами и форматами:
    • Интеграции через API, очереди сообщений, файловые форматы.
    • Версионирование API и политика обратной совместимости.
    • Поддержка стандартов обмена данными (JSON, XML, Protobuf и т. п.).

Практические способы сделать требования измеримыми

Чтобы требования к качеству были проверяемыми, их формулируют с конкретными метриками и условиями:

  • Вместо «система должна быть быстрой» пишут: «время отклика API для 95‑го перцентиля не более 200 мс при нагрузке до 1 000 RPS».
  • Вместо «система должна быть надёжной» указывают: «доступность не менее 99,95% в месяц, RTO ≤15 минут, RPO ≤5 минут».
  • Для безопасности задают: «все внешние API требуют HTTPS, токены доступа имеют TTL 15 минут и отзываются при выходе из системы».

Стандарты и нормативы

  • ISO/IEC 25010:2011 — базовая модель качества ПО (характеристики и подхарактеристики).
  • ГОСТ Р ИСО/МЭК 25021‑2014 — методы задания требований к качеству.
  • OWASP — рекомендации по безопасности веб‑приложений.
  • WCAG — требования к доступности интерфейсов.
  • Отраслевые стандарты (PCI DSS для платежей, GDPR для персональных данных, ФЗ‑152 в РФ и т. д.) задают дополнительные обязательные требования.

Как обеспечивают качество на практике

  • На этапе требований — формализуют и приоритизируют атрибуты качества, вводят метрики и критерии приёмки.
  • В процессе разработки — применяют код‑ревью, статический анализ, автоматизированное тестирование (юнит, интеграционные, контрактные тесты), проверки безопасности (SAST/DAST).
  • При сборке и доставке — CI/CD с обязательными проверками, сканирование зависимостей, контроль версий и секретов.
  • В эксплуатации — мониторинг (SLO/SLI), алертинг, постмортемы инцидентов, регулярное обновление уязвимостей.