Рис. 13.5. Ожидаемая стабильность на протяжении жизненного цикла благополучного проекта.
13.3.2 Дефекты и коэффициент дефектности.
Дефектность определяется как средняя мера изменений, которая представляет собой объем базового ПО, требующего доработки (может выражаться в SLOC, функциональных точках, компонентах, подсистемах, файлах и т.д.). Коэффициент дефектности — это тенденция изменения среднего количества дефектов с течением времени. Для благополучного проекта ожидаемая тенденция — уменьшение или стабильность (см. рис. 13.6).
Этот показатель позволяет понять, доброкачественный или злокачественный характер носят изменения ПО. В случае зрелого процесса итерационной разработки изменения на ранних этапах обычно приводят к большему объему отбраковки, чем на более поздних. Тенденция к увеличению дефектов с течением времени ясно указывает на то, что сопровождаемость продукта вызывает подозрения.
Рис. 13.6. Ожидаемый коэффициент дефектности на протяжении жизненного цикла благополучного проекта.
13.3.3 Доработки и адаптируемость.
Доработка определяется как средняя стоимость внесения изменений, в которую входят затраты на анализ, принятие решения, повторное тестирование всех изменений в основе ПО. Адаптируемость определяется как тенденция изменения количества доработок в зависимости от времени. Для благополучного проекта ожидаемая тенденция — уменьшение или стабильность (см. рис. 13.7).
Рис. 13.7. Ожидаемая адаптируемость на протяжении жизненного цикла благополучного проекта.
Не все изменения одинаковы. Некоторые из них могут быть внесены за один человеко-час, другие требуют нескольких человеко-недель. Эта метрика позволяет измерять объем доработок. В сформировавшемся итерационном процессе изменения на ранних этапах (изменения в архитектуре, которые оказывают влияние на большое количество компонентов и людей), как правило, требуют больших доработок, чем на поздних (изменения при разработке, которые обычно ограничиваются одним компонентом или человеком). Тенденция к увеличению доработок с течением времени ясно указывает на то, что сопровождаемость продукта вызывает подозрения.
13.3.4 MTBF и завершенность.
MTBF — это среднее время использования ПО меж^у двумя отказами. В общем случае MTBF можно вычислить, поделив время тестирования на количество SCO типов 0 и 1. Завершенность определяется как тенденция изменения MTBF с течением времени (см. рис. 13.8).
Рис. 13.8. Ожидаемая завершенность на протяжении жизненного цикла благополучного проекта.
Раннее определение завершенности требует создания эффективной инфраструктуры для тестирования. Традиционные подходы к тестированию монолитных компьютерных программ уделяют основное внимание достижению полного тестового покрытия каждой строки кода, каждой ветви программы и т.д. В современных распределенных и разбитых на компоненты программных системах такое исчерпывающее тестовое покрытие достижимо только для отдельных компонентов. Системы компонентов более эффективно тестируются с использованием статистических методов. Соответственно параметр «завершенность» определяет статистику за время использования, а не охватывает весь продукт.
Ошибки в ПО могут быть разбиты на две категории: детерминированные и недетерминированные. Физики назвали бы их соответственно ошибками Бора и ошибками Гейзенберга. Ошибки Бора — это класс ошибок, которые всегда проявляются, когда ПО используется определенным образом. Такие ошибки в большинстве случаев являются следствием ошибок кодирования, а необходимые изменения обычно ограничиваются одним компонентом. Ошибки Гейзенберга — это отказы ПО, которые происходят случайно с некоторой вероятностью при наступлении некоторой ситуации. Эти ошибки почти всегда возникают из-за ошибок,.
допущенных при разработке (и зачастую требующих внесения изменений в множество компонентов), и обычно не воспроизводятся даже в тех случаях, когда ПО используется одним и тем же видимым способом. Для обеспечения адекватного тестового покрытия и исправления статистически значимых ошибок Гейзенберга требуется экстенсивное статистическое тестирование по реальным и случайным сценариям применения.
Традиционные программные продукты, в которых единственная программа выполняется на единственном процессоре, как правило, содержат только ошибки Бора. Современные распределенные системы с множеством взаимодействующих компонентов, выполняющихся в сети процессоров, оказываются уязвимыми для ошибок Гейзенберга, которые сложно обнаруживать, анализировать и исправлять. Лучший способ сделать программный продукт совершенным заключается в создании с самого начала такой инфраструктуры тестирования, которая допускает выполнение случайных сценариев использования на ранних стадиях жизненного цикла и постоянно увеличивает ширину и глубину сценариев для охвата критичных по надежности компонентов.
По мере своего создания базовые версии ПО должны постоянно проверяться с помощью сценариев тестирования. На основе этого тестирования можно определить параметры надежности. Осмысленная оценка завершенности продукта может быть выполнена за счет максимизации времени тестирования (с использованием независимой среды тестирования, автоматизированных регрессионных тестов, случайного статистического тестирования, тестирования в часы, следующие за большими нагрузками, и т.д.). Такой подход предоставляет мощный механизм для автоматизации тестирования на самых ранних стадиях жизненного цикла. Этот метод может быть применен также для мониторинга производительности и измерения надежности.