1. Многоуровневая модель качества программного обеспечения

1. Многоуровневая модель качества программного обеспечения

2. Многоуровневый подход качества ПО

Качество программного обеспечения — многомерное понятие. То, что
является «качественным» для разработчика (чистый код, низкая связанность),
может не совпадать с ожиданиями конечного пользователя (удобный
интерфейс, быстрый отклик).
Многоуровневая модель позволяет:
• Разделить ответственность между разными стейкхолдерами
• Связать низкоуровневые метрики (например, сложность кода) с
высокоуровневыми бизнес-показателями
• Управлять качеством на всех этапах жизненного цикла ПО
Классическое определение (по ISO/IEC 25010):
Качество ПО — это степень, с которой система
удовлетворяет заявленные и подразумеваемые
потребности всех заинтересованных сторон.

3. Историческая эволюция моделей качества

Современный стандарт ISO/IEC 25010 (SQuaRE) закрепил двухуровневую
структуру качества продукта (внутреннее + внешнее) и отдельный уровень
«качество в использовании». На практике же говорят о трёхуровневой модели,
куда также включают уровень кода/архитектуры.

4. Общая схема многоуровневой модели (базовые 3 уровня)

Принцип причинности:
Внутреннее качество → Внешнее качество → Качество в использовании.
Многоуровневая модель — не просто три списка свойств. Это каузальная
(причинно-следственная) сеть:

5. Общая схема многоуровневой модели (базовые 3 уровня)

Детальная декомпозиция каждого уровня с примерами:
Уровень 1. Внутреннее качество (почва, фундамент)
Пример из реального проекта:
Две команды реализуют один и тот же REST API для авторизации.
Измерение внутреннего качества (без
запуска кода):
• Цикломатическая сложность Маккейба
(чем выше, тем хуже)
• Индекс сопровождаемости (чем выше,
тем лучше)
• Процент дублирования кода
• Глубина наследования (DIT)
• Связность и сцепление (LCOM, CBO)
Статус:
Внутреннее качество не видно пользователю
напрямую, но оно предсказывает:
• Скорость выхода новых функций
• Частоту регрессий
• Время исправления багов

6. Общая схема многоуровневой модели (базовые 3 уровня)

Уровень 2. Внешнее качество (поведение системы)
Пример того же API авторизации:
Парадокс:
Можно добиться высокого
внешнего качества при
ужасном внутреннем
(например, один баг фиксится
20 костылями, но система
формально работает).
Важное отличие от уровня 1:
Однако:
Внешнее качество оценивается
• Первый же новый функционал всё
динамически — система запущена, мы
сломает
подаём запросы и смотрим на ответы. • Исправление одного бага породит
три новых
Но мы не знаем, как устроен код
• Инцидент будет восстанавливаться
внутри. Мы тестируем «чёрный
часами вместо минут
ящик».

7. Общая схема многоуровневой модели (базовые 3 уровня)

Уровень 3. Качество в использовании (восприятие и результат)
Тот же API авторизации, но теперь с пользователем.
Сценарий: менеджер в
CRM-системе
пытается войти в
систему с планшета,
находясь в поезде с
плохим интернетом.
Ключевое:
API может быть идеальным с точки зрения внешнего качества (быстрый,
надёжный, функциональный), но если в клиентском интерфейсе поле «пароль»
не подсвечивается при ошибке — пользователь будет неэффективен.
Качество в использовании находится на стыке системы, пользователя и среды.

8. Общая схема многоуровневой модели (базовые 3 уровня)

Сквозной пример: онлайн-банк
Ситуация:
Команда разрабатывает мобильное приложение банка.
Внутреннее качество (уровень 1):
• Архитектура: Clean Architecture + MVVM
• Модульные тесты покрывают 85% логики
• Инструменты: статический анализ (detekt), CI проверяет сложность кода
• Результат: нет «смертельных» связей между модулями
Внешнее качество (уровень 2):
• Функциональность: перевод денег проходит все проверки
• Производительность: баланс загружается за 0.4 сек
• Надёжность: крашей < 0.01% сессий
• Безопасность: биометрия + шифрование
Качество в использовании (уровень 3):
• Результативность: 98% переводов доходят с первого раза (без отмен)
• Эффективность: время перевода для пользователя < 20 секунд
• Удовлетворённость: NPS 75, рейтинг в сторе 4.8

9. Уровень 1 — Внутреннее качество (Internal Quality)

Внутреннее качество – совокупность характеристик, заложенных в исходном
коде, архитектуре, документации и тестовых артефактах, которые можно
оценить без выполнения программы (статический анализ).
Инструменты оценки:
• Статические анализаторы: SonarQube, ESLint, Pylint, Checkstyle
• Метрики сложности: цикломатическая сложность Маккейба, глубина
вложенности
• Анализ зависимостей: JDepend, Structure101

10. Уровень 2 — Внешнее качество (External Quality)

Внешнее качество – свойства, наблюдаемые во время выполнения программы в
тестовой или реальной среде. Оцениваются динамическими методами.
Модель ISO/IEC 25010:
Инструменты оценки:
• Функциональное тестирование (black box)
• Нагрузочное тестирование (JMeter, Gatling)
• Тестирование безопасности (DAST, пентест)
• Измерение доступности (Uptime мониторинг)

11. Уровень 3 — Качество в использовании (Quality in Use)

Качество в использовании – степень, в которой продукт позволяет конкретным
пользователям достигать конкретных целей с определённой эффективностью,
продуктивностью и удовлетворённостью в заданном контексте использования.
Отличие от внешнего
качества:
• Внешнее качество:
«система вернула корректный
ответ за 200 мс»
• Качество в использовании:
«пользователь успел
обработать 15 заявок в час и
не устал»
Качество в использовании невозможно оценить без реальных пользователей
или очень точных профилей пользователей (personas).

12. Расширенные уровни (бизнес- и организационное качество)

Во многих моделях добавляют 4-й уровень (реже 5-й), поскольку качество в
использовании не равно коммерческому успеху.
Уровень 4 — Бизнес-качество:
• TCO (Total Cost of Ownership) — стоимость владения (лицензии, поддержка,
хостинг)
• ROI (Return on Investment) — скорость окупаемости разработки
• Time-to-market — выход на рынок раньше конкурентов
• Рыночная доля — захват аудитории
Уровень 5 — Организационное / стратегическое качество:
• Соответствие регуляторным требованиям (GDPR, HIPAA, ISO 9001)
• Устойчивость к изменениям бизнес-среды
• Качество процессов разработки (CMMI, SPICE)
Однако в академической традиции под «многоуровневой моделью качества ПО»
чаще всего понимают именно 3 уровня (ISO 25010) + связка с внутренними
метриками.

13. Связи между уровнями

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

14. Стратегия внедрения многоуровневой модели

1) Для малого проекта (MVP)
• Уровень 1 (внутреннее) — минимально: простые линтеры + одна метрика
(покрытие тестами > 60%)
• Уровень 2 (внешнее) — ключевые сценарии + производительность
• Уровень 3 (качество в использовании) — опрос первых 10 пользователей
2) Для критической системы (авионика, медицина, финансы)
• Уровень 1 — формальный статический анализ (MISRA, CERT),
доказательство корректности
• Уровень 2 — exhaustive тестирование (мутационное, нагрузочное на 120% от
максимума)
• Уровень 3 — полевые испытания с замером времени реакции пользователя в
аварийных сценариях
• Уровень 4 — расчёт экономического ущерба при отказе
Инструменты для интеграции уровней:
• SonarQube → внутреннее качество (код)
• Selenium + JMeter → внешнее качество
• Google Analytics / Hotjar / Userlytics → качество в использовании
• Таблица связей (Traceability Matrix) — связывает требование → код → тест →
бизнес-метрику

15. Критика и ограничения многоуровневой модели

Пусть стратегии и организуют работу по разработке и обеспечению качества, у
них есть свои минусы:
1. Жесткое разделение не всегда возможно — некоторые атрибуты (например,
безопасность) пронизывают все уровни.
2. Задержка эффекта — изменение внутреннего качества даёт результат через
месяцы.
3. Избыточность для малых проектов — нагрузка на измерение превышает
выгоду.
4. Субъективность качества в использовании — трудно оцифровать
удовлетворённость.
5. Отсутствие общепринятой метрики «суммарного качества» — невозможно
сказать «качество увеличилось на 15%» без взвешивания.
Тем не менее, модель остаётся основным теоретическим фундаментом для
инженерных практик качества (DevOps, TestOps, SRE).

16. Пример сквозного анализа

Требование: «Система должна позволять пользователю оформлять заказ не более
чем за 30 секунд» (качество в использовании, эффективность).
Если внутреннее качество плохое (неиндексированная таблица), внешнее
нарушается, а с ним — и качество в использовании.

17. Пример сквозного анализа

Пример: Мобильное приложение доставки еды
Требование (качество в использовании, эффективность)
«Пользователь должен иметь возможность оформить заказ от открытия
приложения до нажатия кнопки “Оплатить” не более чем за 60 секунд, при этом
совершив не более 5 действий на экран».
Уровень 1 — Внутреннее качество:
Инструменты оценки
внутреннего качества:
• Android Studio
Profiler (замеры методов)
• Baseline Profiles
(Android) для
предкомпиляции
• Lint checks на
сложность навигации
• Тесты на сохранение
состояния

18. Пример сквозного анализа

Уровень 2 — Внешнее качество:
Как эмулировать плохое внешнее качество для проверки границ:
• Установить лимит времени ответа API в 1 секунду (вместо 300 мс) →
измерить итоговое время заказа пользователем.
• Искусственно добавить задержку парсинга 50 мс на элемент меню →
замерить превышение 60 секунд.

19. Пример сквозного анализа

Уровень 3 — Качество в использовании
Инструменты измерения:
• Firebase Analytics (User
Properties + события по
шагам)
• Mixpanel или Amplitude
(воронки, временные метки)
• Запись сессий
(Smartlook, FullStory) для
анализа действий
• A/B тест с разными
архитектурами (быстрая vs
медленная)

20. Основные определения

Далее представлен список основных определений в качестве программного
обеспечения:
• Качество программного обеспечения:
Степень, с которой программная система удовлетворяет заявленные и
подразумеваемые потребности всех заинтересованных сторон (стейкхолдеров) в
заданных условиях эксплуатации (ISO/IEC 25010).
• Модель качества ПО:
Формализованная структура, описывающая набор характеристик и их
взаимосвязей, которые совместно определяют качество программного продукта.
• Многоуровневая модель качества ПО:
Иерархическая структура, в которой качество рассматривается на нескольких
уровнях абстракции (обычно внутреннее, внешнее и качество в использовании),
причём каждый последующий уровень базируется на предыдущем.

21. Основные определения

• Стейкхолдер (заинтересованная сторона):
Лицо или организация, которые имеют законные интересы, права или
требования к программной системе (пользователи, разработчики, владельцы,
регуляторы, сопровождающий персонал).
• Атрибут качества:
Измеримое свойство программной системы, которое характеризует один из
аспектов её качества (например, надёжность, производительность,
модульность).
• Внутреннее качество (Internal Quality):
Совокупность статических свойств артефактов разработки (исходный код,
архитектура, документация, тесты), которые могут быть оценены без
выполнения программы, и которые влияют на способность создавать и
сопровождать систему.

22. Основные определения

• Внешнее качество (External Quality):
Совокупность свойств системы, наблюдаемых во время её выполнения в
тестовой или реальной среде, которые характеризуют поведение системы
относительно внешних интерфейсов и требований.
• Качество в использовании (Quality in Use):
Степень, в которой программный продукт позволяет конкретным пользователям
достигать конкретных целей с определённой эффективностью,
продуктивностью и удовлетворённостью в заданном контексте использования
(ISO/IEC 25010)..
• Качество продукта (Product Quality):
В терминах ISO 25010 — совокупность внутреннего и внешнего качества, то
есть характеристик самой системы, независимо от контекста использования.
• Бизнес-качество (Business Quality):
Расширенный уровень (4-й), включающий экономические показатели:
совокупную стоимость владения (TCO), возврат инвестиций (ROI), время
выхода на рынок и другие коммерческие метрики.

23. Благодарю за внимание