Какие показатели могут служить метриками:

1. метрики менеджмента

(1-4 - этап планирования/контроля)

1. цена - расходы на приобретение или разработку

• анализ рынка

• приобретение

• интерпретация

• улучшение качества

2. время разработки - от формирования до постройки или количество времени до постройки

3. среда разработки - мера способности разрабатывать ПО высокого качества - СММ

4. использование системных ресурсов - % целевых комп. ресурсов системы

2. метрики требований

(дают возможность контроллировать спецификации, изменения требований и степень их удовлетворения)

1. соответствие требованиям

2. стабильность требований - насколько часто менялись заказчиком

3. метрики качества

   1. адаптируемость - мера гибкости системы, способность адаптироваться к изменениям: требований или перепроектирования/интегрирования приложений

   2. сложность интерфейсов и интеграции - степень сложности интерфейсов/ дополнительного программирования, требуемого для интеграции компонентов системы, которые требуются для тестирования/отладки/сопровождения системы

   3. тестовые покрытия - степень полноты различных типов тестирования

   4. надежность - оценивается вероятность функционирования системы без отказов

   5. профили ошибок - измеряется коммулятивное число обнаруженных ошибок

   6. степень удовлетворения требованиям заказчика - степень соответствия ПО требованиям (может быть оценена перед постановкой)

Качество программного кода

Единственный механизм оценки соответствия - требования

Существуют технические и нетехнические требования => метрики, которые из них выводятся, очень важны.

Но они формируются на раннем этапе => есть доля неопределенности => нужно различать с качеством того, что предстоит реализовать. Для этого используем:

Гибкость:

• модульность

• изменяемость

• сопровождаемость

Адаптивность

• настраиваемость

• переносимость

• способность к взаимодействию

Причины, по которым может быть инициировано исправление ПО:

• исправление ПО с недостаточным уровнем качества

• изменение ПО для повышения уровня качества

• изменение ПО для удовлетворения изменений в правилах

Опыт использования и внедрения крупных ПС показывает, что стоимость эксплуатации и сопровождения в составе общей стоимости владения системы увеличивается с ростом системы опережающими темпами, => показатели, связанные с гибкостью и настраиваемостью, становятся все более важны.

Баланс производительности и гибкости очень важен и должен быть под контролем.

Качество технического проекта

Три уровня, на которых нужно тестировать повторное использование:

• исходный код

• физический дизайн

• логический дизайн

• требования (системы/проекта)

Модификация ПО

• реструктуризация - создание логически эквивалентной системы

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

• прямой инжиниринг - разработка системы от спецификаций до кодирования и внедрения

Должны использоваться метрики для объекто-ориентированной системы

• надежность

• сложность

• повторное использование

Стоимость ошибки проектирования на 2 порядка выше стоимости ошибки кодирования.

Используется модель фактор-критерий-измерение

Пример:

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

• сложность - фактор, отражающий сложность понимания реализации и модификации

• возможность повторного использования - отражает степень применяемости проектных решений в различных контекстах. Наличие таких решений значительно уменьшает сложность и объем проекта

Любому фактору ставится в соответствие критерий

• точность

• точность-полнота

• согласованность

• размер модуля

• связь модулей по данным

• связность

• модульность

• норма управяемости

Измерение качества на основе сопровождения продукта

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

Интегральная оценка качества

Производится на основе анализа взаимовлияния различных параметров, характеризующих качество продукта.

Эволюция понятия качества ПО

Модель качества - структурная система характеристик по МакКолу

1977г. Характеристики делятся на 3 группы:

1. факторы, описывающие ПО с позиции пользователя и задавая требования

2. принципы, описывающие ПО с позиции разработчика и задаваемые как цели

3. Метрики, используемые как количественное описание характеристик качества

Факторы делятся на 3 группы по способу работы людей с ПО

Ревизии

• сопровождаемость

• оцениваемость

• гибкость

Внедрение

• Переносимость

• Переиспользуемость (повторное использование)

• Способность к взаимодействию

Функционирование

• корректность

• надежность

• эффективность

• целостность

• практичность

Критерии качества - числовые уровни факторов, пост. в качестве цели при разработке ПО

Непосредственно измерить сложно => ввели метрики

Шкала 0-10:

• удобство проверки на соответствие стандартам

• точность управления и вычислений

• степень стандартности интерфейса

• функциональная полнота

• однородность используемых правил проектирования и документации

• степень стандартизации форматов данных

• устойчивость к ошибкам

• эффективность работы

• расширяемость

• широта области потенциального использования

• независимость от аппаратной платформы

• полнота протоколирования ошибок и других событий

• модульность

• удобство работы

• защищенность

• самодокументированность

• простота работы

• независимость от программной платформы

• возможность соотнесения проекта с требованиями

• удобство обучения

Для более важных коэффициент больше, для мене - меньше.