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

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

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

1. Определение множества характеристик, которые, являясь важными для программного обеспечения, допускают несложное измерение и не перекрываются.

2. Выделение кандидатов в метрики, которые измеряют степень удовлетворения указанным характеристикам.

3. Исследование характеристик и связанных метрик, для определения корреляции, значимости, степени автоматизируемости.

4. Исследование корреляции между метриками, степени перекрытия, зависимости и недостатков.

5. Рафинирование множества метрик в целом во множество метрик, которые в совокупности адекватно отражают качество программного обеспечения.

6. Корректировка каждой метрики в итоговом множестве в контексте зафиксированных множеств характеристик и метрик.

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

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

Разработка современных больших программных систем в настоящее время все более базируется на компонентной разработке (Component Base System - CBS). Технология построения CBS позволяет значительно снизить стоимость и время разработки. В то же время возрастает риск, связанный с использованием в системе программных компонент разработанных различными производителями.

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

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

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

Примерами метрик могут служить следующие показатели:

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

- Цена (Cost) - расходы на приобретение/разработку. Измеряет общую цену, включая цену анализа рынка, приобретения, интеграции и улучшения качества.

- Время разработки (Time-to-market). Мера времени от формирования заказа на программу до поставки. При итерационной разработке данная метрика модифицируется для измерения времени, требуемого для поставки заданного объема приращения функциональности, то есть скорости поставки.

- Среда разработки (Software Engineering Environment). Процент целевых компьютерных ресурсов, используемых системой.

- Использование системных ресурсов (System Resource Utilization). Мера способности производителя разрабатывать программное обеспечение высокого качества. Данная метрика может быть выражена в терминах модели «Software Acquisition Capability Maturirty Model» (SA - СММ)

Указанные метрики могут использоваться на этапах планирования и контроля проектов и других задач управления или использоваться в качестве параметров управления штатной ERP системы.

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

- Соответствие требованиям (requirement conformance)

- Стабильность требований (requirement stability)

- Изменяемость требований(Requirement Convertibility)

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

3. Метрики качества ПП/ПС в целом:

- Адаптируемость (adaptability). Мера гибкости системы, оценивает способность системы адаптироваться к изменениям требований либо перепроектированием системы, либо интеграцией приложений.

- Сложность интерфейсов и интеграции (complexity of interfaces and integration). Метрика, измеряющая степень сложности интерфейса или дополнительного программирования требуемого для интеграции компоненты в систему, которые требуются для тестирования, отладки и сопровождения, компенсирующего потерю качества.

- Тестовое покрытие (test coverage). Степень полноты различных типов тестирования.

- Надежность (reliability). Метрика, оценивающая вероятность работы системы без отказов. Данная метрика может быть получена в рамках традиционного подхода.

- Профили ошибок (fault profiles). Метрика, измеряющая кумулятивное число обнаруженных ошибок.

- Степень удовлетворения потребностей заказчика (customer satisfaction). Метрика, оценивающая степень соответствия программного обеспечения ожиданиям и требованиям заказчика. Данная метрика может быть оценена перед поставкой на этапе опытной эксплуатации на основе прогнозирующих параметров.

4. Метрики качества программного кода, выводимые из требований:

- Гибкость (flexability), которая аккумулирует ряд свойств:

- Модульность (Modularity)

- Изменяемость (Changeability)

- Сопровождаемость (Maintainability)

- Адаптивность (adaptability), которая подразумевает:

- Настраиваемость (customizability)

- Переносимость (Portability)

- Способность к взаимодействию (Interoperability)

Как правило, единственным доступным механизмом определения «ожиданий заказчика» являются требования (software requirement specifications). Требования Технического задания определяют функции программного обеспечения и нефункциональные требования, такие как производительность, надежность и т.п. Нетехнические требования, такие как цена, сроки поставки утверждаются в контрактных документах.

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