Метрики менеджмента, метрики требований, метрики качества

2020-06-032021-03-09zzyxelСтудИзба

5. Метрики менеджмента, метрики требований, метрики качества

5.1. Введение

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

При выборе метрик главными показателями являются:

· адекватность метрик целям качества,

· прозрачность и четкость интерпретации,

· экономическая эффективность получения.

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

· Цена (Cost) – расходы на приобретение/разработку

· Время разработки (Time-to-market)

· Среда разработки (Software Engineering Environment)

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

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

Сами метрики:

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

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

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

5.4. Метрики качества

· Адаптируемость (adaptability)

· Сложность интерфейсов и интеграции (complexity of interfaces and integration)

· Тестовое покрытие (test coverage)

· Надежность (reliability)

· Профили ошибок (fault profiles)

· Степень удовлетворения потребностей заказчика (customer satisfaction)

«Adaptability» - мера гибкости системы, оценивает способность системы адаптироваться к изменениям требований либо перепроектированием системы, либо интеграцией приложений.

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

Метрики «test coverage» указывают степень полноты различных типов тестирования.

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

«Fault profiles» - метрика, измеряющая кумулятивное число обнаруженных ошибок.

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

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

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

К числу подобных метрик относится:

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

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

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

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

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

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

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

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

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

"8 Рекомендации по конструированию отливок" - тут тоже много полезного для Вас.

Исправления программного обеспечения может быть инициировано по следующим причинам:

· исправление программы с недостаточным уровнем качества (bug fixing),

· изменение программы для повышения уровня качества (enhancement),

· изменение программы для удовлетворения изменения в требованиях.

Опыт внедрения и использования крупных программных систем показывает, что стоимость эксплуатации и сопровождения в составе общей стоимости владения системы (total cost ownership - TCO) увеличивается с ростом системы опережающими темпами. Отсюда следует, что показатели качества программ, связанные с гибкостью и настраиваемостью становятся все более важными.

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

Поделитесь ссылкой:

Популярные услуги