Метрика числа ошибок в программе закон миллера
В настоящее время в программной инженерии еще не сформировалась окончательно система метрик. Действуют разные подходы к определению их набора и методов измерения [10.11-10.13].
Система измерения включает метрики и модели измерений, которые используются для количественной оценки качества ПО.
При определении требований к ПО задаются соответствующие им внешние характеристики и их атрибуты (подхарактеристики), определяющие разные стороны управления продуктом в заданной среде. Для набора характеристик качества ПО, приведенных в требованиях, определяются соответствующие метрики, модели их оценки и диапазон значений мер для измерения отдельных атрибутов качества.
Согласно стандарту [1.16] метрики определяются по модели измерения атрибутов ПО на всех этапах ЖЦ (промежуточная, внутренняя метрика) и особенно на этапе тестирования или функционирования (внешние метрики) продукта.
Остановимся на классификации метрик ПО, правилах для проведения метрического анализа и процесса их измерения.
Типы метрик.
Существует три типа метрик:
- метрики программного продукта, которые используются при измерении его характеристик - свойств;
- метрики процесса, которые используются при измерении свойства процесса ЖЦ создания продукта.
- метрики использования.
Метрики программного продукта включают:
- внешние метрики, обозначающие свойства продукта, видимые пользователю;
- внутренние метрики, обозначающие свойства, видимые только команде разработчиков.
Внешние метрики продукта - это метрики:
- надежности продукта, которые служат для определения числа дефектов;
- функциональности, с помощью которых устанавливаются наличие и правильность реализации функций в продукте;
- сопровождения, с помощью которых измеряются ресурсы продукта (скорость, память, среда);применимости продукта, которые способствуют определению степени доступности для изучения и использования;
- стоимости, которыми определяется стоимость созданного продукта.
Внутренние метрики продукта включают:
- метрики размера, необходимые для измерения продукта с помощью его внутренних характеристик;
- метрики сложности, необходимые для определения сложности продукта;
- метрики стиля, которые служат для определения подходов и технологий создания отдельных компонентов продукта и его документов.
Внутренние метрики позволяют определить производительность продукта и являются релевантными по отношению к внешним метрикам.
Внешние и внутренние метрики задаются на этапе формирования требований к ПО и являются предметом планирования и управления достижением качества конечного программного продукта.
Метрики продукта часто описываются комплексом моделей для установки различных свойств, значений модели качества или прогнозирования. Измерения проводятся, как правило, после калибровки метрик на ранних этапах проекта. Общая мера - степень трассируемости, которая определяется числом трасс, прослеживаемых с помощью моделей сценариев типа UML и оценкой количества:
- требований;
- сценариев и действующих лиц;
- объектов, включенных в сценарий, и локализация требований к каждому сценарию;
- параметров и операций объекта и др.
Стандарт ISO/IEC 9126-2 определяет следующие типы мер:
Специальной мерой может служить уровень использования повторных компонентов и измеряется как отношение размера продукта, изготовленного из готовых компонентов, к размеру системы в целом. Данная мера используется также при определении стоимости и качества ПО. Примеры метрик:
- общее число объектов и число повторно используемых;
- общее число операций, повторно используемых и новых операций;
- число классов, наследующих специфические операции;
- число классов, от которых зависит данный класс;
- число пользователей класса или операций и др.
При оценке общего количества некоторых величин часто используются среднестатистические метрики (среднее число операций в классе, наследников класса или операций класса и др.).
Как правило, меры в значительной степени являются субъективными и зависят от знаний экспертов, производящих количественные оценки атрибутов компонентов программного продукта.
Примером широко используемых внешних метрик программ являются метрики Холстеда - это характеристики программ, выявляемые на основе статической структуры программы на конкретном языке программирования: число вхождений наиболее часто встречающихся операндов и операторов; длина описания программы как сумма числа вхождений всех операндов и операторов и др.
На основе этих атрибутов можно вычислить время программирования, уровень программы (структурированность и качество) и языка программирования (абстракции средств языка и ориентация на проблему) и др.
В качестве метрик процесса могут быть время разработки, число ошибок, найденных на этапе тестирования и др. Практически используются следующие метрики процесса:
- общее время разработки и отдельно время для каждой стадии;
- время модификации моделей;
- время выполнения работ на процессе;
- число найденных ошибок при инспектировании;
- стоимость проверки качества;
- стоимость процесса разработки.
Метрики использования служат для измерения степени удовлетворения потребностей пользователя при решении его задач. Они помогают оценить не свойства самой программы, а результаты ее эксплуатации - эксплуатационное качество. Примером может служить - точность и полнота реализации задач пользователя, а такжезатраченные ресурсы (трудозатраты, производительность и др.) на эффективное решение задач пользователя. Оценка требований пользователя проводится с помощью внешних метрик.
10.1.3. Стандартная оценка значений показателей качества
Оценка качества ПО согласно четырехуровневой модели качества начинается с нижнего уровня иерархии, т.е. с самого элементарного свойства оцениваемого атрибута показателя качества согласно установленных мер. На этапе проектирования устанавливают значения оценочных элементов для каждого атрибута показателя анализируемого ПО, включенного в требования.
По определению стандарта ISO/IES 9126-2 метрика качества ПО представляет собой "модель измерения атрибута, связываемого с показателем его качества". При измерении показателей качества данный стандарт позволяет определять следующие типы мер:
- меры размера в разных единицах измерения (количество функций, размер программы, объем ресурсов и др.);
- меры времени - периоды реального, процессорного или календарного времени (время функционирования системы, время выполнения компонента, время использования и др.);
- меры усилий - продуктивное время, затраченное на реализацию проекта (производительность труда отдельных участников проекта, коллективная трудоемкость и др.);
- меры интервалов между событиями, например, время между последовательными отказами;
- счетные меры - счетчики для определения количества обнаруженных ошибок, структурной сложности программы, числа несовместимых элементов, числа изменений (например, число обнаруженных отказов и др.).
Метрики качества используются при оценке степени тестируемости с помощью данных ( безотказная работа, выполнимость функций, удобство применения интерфейсов пользователей, БД и т.п.) после проведения испытаний ПО на множестве тестов.
Наработка на отказ как атрибут надежности определяет среднее время между появлением угроз, нарушающих безопасность, и обеспечивает трудноизмеримую оценку ущерба, которая наносится соответствующими угрозами.Очень часто оценка программы проводится по числу строк. При сопоставлении двух программ, реализующих одну прикладную задачу, предпочтение отдается короткой программе, так как её создает более квалифицированный персонал и в ней меньше скрытых ошибок и легче модифицировать. По стоимости она дороже, хотя времени на отладку и модификацию уходит больше. Т.е. длину программы можно использовать в качестве вспомогательного свойства для сравнения программ с учетом одинаковой квалификации разработчиков, единого стиля разработки и общей среды.
Если в требованиях к ПО было указано получить несколько показателей, то просчитанный после сбора данных показатель умножается на соответствующий весовой коэффициент, а затем суммируются все показатели для получения комплексной оценки уровня качества ПО.
На основе измерения количественных характеристик и проведения экспертизы качественных показателей с применением весовых коэффициентов, нивелирующих разные показатели, вычисляется итоговая оценка качества продукта путем суммирования результатов по отдельным показателям и сравнения их с эталонными показателями ПО (стоимость, время, ресурсы и др.).
Все метрики -атрибута суммируются и образуют -показатель качества. Когда все атрибуты оценены по каждому из показателей качества, производится суммарная оценка отдельного показателя, а потом и интегральная оценка качества с учетом весовых коэффициентов всех показателей ПО.
В конечном итоге результат оценки качества является критерием эффективности и целесообразности применения методов проектирования, инструментальных средств и методик оценивания результатов создания программного продукта на стадиях ЖЦ.
Для изложения оценки значений показателей качества используется стандарт [10.4], в котором представлены следующие методы: измерительный, регистрационный, расчетный и экспертный (а также комбинации этих методов). Измерительный метод базируется на использовании измерительных и специальных программных средств для получения информации о характеристиках ПО, например, определение объема, числа строк кода, операторов, количества ветвей в программе, число точек входа (выхода), реактивность и др.
Регистрационный метод используется при подсчете времени, числа сбоев или отказов, начала и конца работы ПО в процессе его выполнения.
Расчетный метод базируется на статистических данных, собранных при проведении испытаний, эксплуатации и сопровождении ПО. Расчетными методами оцениваются показатели надежности , точности, устойчивости, реактивности и др.
Экспертный метод осуществляется группой экспертов - специалистов, компетентных в решении данной задачи или типа ПО. Их оценка базируется на опыте и интуиции, а не на непосредственных результатах расчетов или экспериментов. Этот метод проводится путем просмотра программ, кодов, сопроводительных документов и способствует качественной оценки созданного продукта. Для этого устанавливаются контролируемые признаки, которые коррелированны с одним или несколькими показателями качества и включены в опросные карты экспертов. Метод применяется при оценке таких показателей, как анализируемость, документируемость, структурированность ПО и др.
Для оценки значений показателей качества в зависимости от особенностей используемых ими свойств, назначения, способов их определения используются:
- шкала метрическая (1.1 - абсолютная, 1.2 - относительная, 1.3 - интегральная);
- шкала порядковая (ранговая), позволяющая ранжировать характеристики путем сравнения с опорными;
- классификационная шкала, характеризующая наличие или отсутствие рассматриваемого свойства у оцениваемого программного обеспечения.
Показатели, которые вычисляются с помощью метрических шкал, называются количественные, а определяемые с помощью порядковых и классификационных шкал - качественные.
Атрибуты программной системы, характеризующие ее качество, измеряются с использованием метрик качества. Метрика определяет меру атрибута, т.е. переменную, которой присваивается значение в результате измерения.Для правильного использования результатов измерений каждая мера идентифицируется шкалой измерений.
Стандарт ISO/IES 9126-2 рекомендует применять 5 видов шкал измерения значений, которые упорядочены от менее строгой к более строгой:
«Магическое число семь плюс-минус два» («кошелёк Миллера», «закон Миллера») — закономерность, обнаруженная американским учёным-психологом Джорджем Миллером, согласно которой кратковременная человеческая память, как правило, не может запомнить и повторить более 7 ± 2 элементов.
В 1956 году Джордж Миллер, американский психолог, опубликовал статью под названием «Магическое число семь плюс-минус два: некоторые ограничения в нашей возможности обработки информации».
Проведя серию экспериментов, в ходе которых людям необходимо было различать звуковые сигналы с разной частотой, психолог выявил, что если количество сигналов 2 или 3, то у испытуемых не возникает сложностей в их определении. Начиная с 4-го сигнала появляются незначительные проблемы. А на 5-м и более звуках испытуемые ошибаются все чаще. Помимо экспериментов со звуком также проводились эксперименты со вкусом, с визуальным восприятием и другие.
Миллер обобщил показатели всех экспериментов и получил то самое число 7±2. Именно такое количество элементов способна хранить кратковременная память среднестатистического человека.
Несмотря на то, что закон Миллера является одним из наиболее популярных и цитируемых в среде UX дизайна, он не имеет почти никакого отношения к пользовательскому опыту и интерфейсам.
Этот закон – миф, как и многие вытекающие из него убеждения о том, что количество элементов меню или количество элементов списка не должно превышать отметку в семь единиц.
Начнем с того, что пользователю просто незачем запоминать информацию, она и так представлена в полном объеме у него на экране, поэтому он легко может оперировать большим количеством элементов. И незачем искусственно ограничивать это количество семью.
Human Factors International (HFI), одна из крупнейших компаний, специализирующихся на проектировании пользовательского опыта провела исследования, в результате которого выяснилось, что объемные, но неглубокие меню могут работать лучше, чем те, которые имеют большое количество вложенностей.
Разделы на сайте Amazon
Даже сам Джордж Миллер был потрясен тем, насколько его статья была неверно истолкована, заявив, что исследования проводились для одномерных стимулов (звук, яркость и т. д.), и не имеет никакого отношения к способностям человека понимать печатный текст.
Тем не менее, основной вывод исследований Миллера для UX специалистов должен заключаться в следующем: кратковременная память человека ограничена, поэтому, если вы хотите, чтобы ваши пользователи работали с бОльшим объемом информации и запоминали ее, разделяйте информацию на порции. Не просите пользователей одновременно хранить в своей краткосрочной памяти сразу много фрагментов информации. И не зацикливайтесь на цифре семь.
Закон Теслера
Закон Теслера, или закон сохранения сложности, утверждает, что для любой системы существует определенный уровень сложности, который нельзя сократить.
Ларри Теслер — информатик, специалист в области взаимодействия человека и компьютера. Он работал в таких компаниях как Xerox PARC, Apple, Amazon и Yahoo. Фактически именно он ввел в оборот комбинацию клавиш Ctrl+C, Ctrl+V.
Он утверждал, что каждое приложение имеет определенную степень сложности. Единственный вопрос: кто будет иметь с этим дело? Пользователь, разработчик приложения или разработчик платформы?
Распределение сложности системы
Требуется довольно много работы, чтобы сделать что-то «простое». Уменьшая сложность для пользователя, мы переносим сложность на дизайнеров, разработчиков.
Давайте разберем простой пример — выбор типа платежной системы.
Тип платежной системы выбирает пользователь
Тип платежной системы подставляется автоматически
В первом случае выбор ложится на плечи пользователя, тем самым усложняя для него систему, но упрощая разработку. Во втором — тип платежной системы подставляется автоматически, когда пользователь начинает вводить номер карты. Это упрощает работу для пользователя, так как сложность задачи уменьшается на один шаг. Но разработка при этом становится сложнее.
Распространенная ошибка многих продуктовых команд — отдать как можно больше контролов для выбора пользователю, как будто он лучше знает, что с этим делать. Дизайнер рисует очередную пачку чекбоксов, говоря прямым текстом пользователю: «Парень, теперь это твоя проблема».
Вместо этого, команде следует собрать больше информации о пользователях, проанализировать ее и сделать этот выбор за пользователя.
Модель Кано
«Модель Кано» — методика, которая используется для оценки эмоциональной реакции потребителя на отдельные характеристики продукта. Она позволяет управлять удовлетворенностью и лояльностью потребителей, упрощает и оптимизирует процесс потребления.
Модель Кано разработана в 1984 году доктором Нориаки Кано.
Модель Кано позволяет проектировщикам гораздо лучше понять желания потребителей и избавиться от ненужных фич в продукте. С его помощью компании вырабатывают стратегии и решают задачи по обеспечению удовлетворенности и лояльности пользователей.
Модель Кано
Кано разделяет все свойства продуктов на 5 категорий:
- Обязательные характеристики
- Линейные характеристики
- Привлекательные характеристики
- Безразличные характеристики
- Обратные характеристики
Обязательные характеристики
Как и следует из названия, к обязательным характеристикам продукта относятся те, без которых продукт не будет работать надлежащим образом. Например, автомобиль без руля, смартфон без возможности совершать звонки и так далее.
Обязательные атрибуты должны присутствовать, ведь без них продукт не будет иметь ценность для потребителя.
Однако, как следует из графика ниже, уровень выполнения обязательных характеристики продукта не влияет на удовлетворенность потребителей напрямую.
Обязательные характеристики
Само наличие таких атрибутов в продукте не вызывает у них больших эмоций, поскольку они считают, что эти атрибуты должны присутствовать в продукте по умолчанию. Но если упустить какое-либо основное свойство, то никакие прочие свойства продукта не спасут потребителя от разочарования.
Линейные Характеристики
К линейным или одномерным характеристикам относят характеристики из разряда «чем больше, тем лучше». Например, объем памяти, расход топлива, емкость аккумулятора и прочие. Чем лучше значения этих показателей, тем выше удовлетворенность клиента.
Линейные характеристики
Как показывает график, уровень удовлетворенности линейными характеристиками находится в прямой зависимости с уровнем функциональности указанного атрибута.
Привлекательные характеристики
Привлекательные или восхищающие характеристики продукта — это киллер фичи вашего продукта. К таким характеристикам в свое время относилась функция iPhone Touch ID, а теперь и Face ID. Автоматическая разблокировка MacBook часами Apple Watch, беспроводная зарядка смартфонов и многие другие.
Привлекательные характеристики
Уровень выполнения привлекательных свойств не влияет на удовлетворенность потребителей напрямую. Если восхищающее свойство отсутствует, потребители не будут разочарованы, так как у них не было никаких ожиданий относительно такого свойства. Но зато если восхищающее свойство обнаружено потребителями, то благодаря эффекту неожиданности они будут настолько впечатлены, что просто не смогут удержаться и не поделиться своим открытием с другими.
Со временем многие привлекательные характеристики переходят в разряд обязательных.
Безразличные характеристики
Это те функции и атрибуты продукта, которые потребителя мало интересуют или не интересуют вовсе; функционал, который никак не влияет на уровень удовлетворенности клиента продуктом.
Безразличные характеристики
В качестве примера таких свойств можно привести шифрование фотографий в Google Photos, сторона расположения бензобака на автомобиле и другие.
Обратные характеристики
Обратные или нежелательные характеристики — это те свойства продукта, которые по мере роста своего количества уменьшают удовлетворенность пользователя продуктом.
Обратные характеристики
В качестве примера таких характеристик можно привести огромное количество кнопок на руле автомобиля, которые отвлекают водителя, или автомобильная парковка с большим количеством мест, но места в которой настолько узкие, что трудно открыть дверь автомобиля.
Как использовать Модель Кано?
Для того, чтобы использовать Модель Кано, вам потребуется провести исследование целевой аудитории, выявить их видение характеристик вашего продукта.
Составьте список фич вашего продукта для каждого типа персон. Ведь один сегмент ваших потребителей будет видеть доминирующую ценность продукта в одних характеристиках, а другие – в других. Учитывайте этот факт при опросе.
Далее перейдем к самому опросу. Он состоит всего из двух вопросов, каждый из которых задается один раз для каждого атрибута:
- как бы вы себя чувствовали, если бы продукт имел следующую характеристику?
- как бы вы себя чувствовали, если бы продукт не имел следующей характеристики?
- Мне бы понравилось
- Я ожидаю это
- Мне все равно
- Я могу с этим жить
- Я бы не использовал продукт из-за этого
Она состоит из нескольких категорий, отмеченных буквами:
A — Attractive — Привлекательные
O — One dimensional — Линейные
M — Must-be — Обязательные
I — Indifferent — Безразличные
R — Reverse — Обратные
Q — Questionable — Под вопросом (Отражает неясные результаты, которые не могут быть оценены)
К примеру, если пользователь отвечает «1. Мне бы понравилось» на функциональный (положительный) вопрос и «2. Я ожидаю это» на нефункциональный (отрицательный) вопрос, то тестируемая функция попадает в категорию «А», т.е. привлекательная.
Обратите внимание также, что там, где вы получили R — людям не интересен ваш продукт, это не ваша целевая аудитория, а там, где вы получили Q, люди скорее всего не поняли вопрос.
Таким образом, Модель Кано может помочь выяснить требования клиентов к данному продукту и помогает в создании продуктов, которые приводят к высокой удовлетворенности клиентов.
Закон Парето
Закон Парето (принцип Парето, принцип 80/20) — эмпирическое правило в наиболее общем виде формулируется как «20 % усилий дают 80 % результата, а остальные 80 % усилий — лишь 20 % результата».
Принцип Парето
Этот принцип был предложен консультантом по управлению Джозефом Джураном в 1951 году, который сослался на частную закономерность, выявленную итальянским экономистом и социологом Вильфредо Парето в 1897 году.
Закон Парето полезен, потому что он позволяет нам сосредоточить наши усилия на областях, которые приносят наибольшую пользу. Он используется практически в каждой бизнес-дисциплине.
Неважно, разрабатываете ли вы небольшой веб-сайт или большое и сложное приложение, как только вы углубитесь в пользовательскую аналитику, вы увидите, что бОльшую часть времени пользователи работают лишь с ограниченной частью функционала. Конечно это не означает, что остальные функциональные возможности или контент не имеют никакой ценности, но это говорит о том, что некоторые функциональные возможности и контент более важны для ваших пользователей, чем для остальных.
Это важно, потому что это позволяет вам сосредоточить свои исследования на наиболее важных вещах и обеспечить сохранность этих вещей, когда вы приступаете к пересмотру пользовательского опыта. Если вы не будете учитывать это, то вы потеряете пользователей. И наоборот, если вы сможете улучшить взаимодействие с пользователем этих ключевых атрибутов вашего продукта, вы с большей вероятностью сможете завоевать новых пользователей и поощрить лояльность текущих.
Но не все так просто, предположим, что вы получили в службу поддержки 300 обращений, 200 из которых относятся к проблеме A, 80 относятся к проблеме B, и только 20 относятся к C. На этом этапе нетрудно сосредоточиться на решении проблемы A. Но если все запросы, относящиеся к B или C, поступают от пользователей с платной или премиальной подпиской, а вызовы, относящиеся к функции A — нет, то вы все же можете сначала сосредоточить свои усилия на исправлении B или C.
Закон Парето предлагает способ сосредоточить свою энергию и усилия на создании пользовательского опыта. Он поможет вам получить четкое представление о том, что имеет отношение к вашим пользователям и бизнесу, чтобы вы могли устанавливать приоритеты и решать правильные дизайн задачи.
Все написанное выше не является аксиомой, скорее это набор несложных принципов и рекомендаций, пользуясь которыми, можно ощутимо улучшить пользовательский опыт и избежать типичных проблем юзабилити продукта.
Спасибо, что потратили время на чтение этой статьи, надеюсь, она была для вас полезной.
Значительная часть усилий и времени, затрачиваем на реализацию большинства программ для ЭВМ, приходится на их отладку, т. е. выявление и устранение ошибок типа “лишних и недостающих элементов”, внесенных в начальный период написания программы. Следовательно, любое обоснованное представление о числе первоначальных ошибок, ожидаемых в данной программе, даст важную оценку для практики. Предлагаемая метрика предсказывает число первоначальных ошибок (до отладки и тестирования) и не может служить доказательством правильности (корректности) программы, даже если ее значение равно нулю.
Время, требуемое на разработку программы, характеризуется числом элементарных мысленных различений Е. Следовательно, число моментов, в которые можно сделать ошибочное различение, также определяется значением Е или связанным с ним значением объема программы V. По утверждениям психолога Джорджа Миллера (закон “7±2”) мозг человека может в своей “сверхбыстрой” памяти обрабатывать пять “объектов” одновременно (т. е. получать из них результат). Представив эту способность мозга как Екрит, получим ее программное значение.
Пусть каждый объект так же, как и результат, соответствует единице уникальных операндов в потенциальном языке, т. е. h2* = 6. С помощью равенств h1* = 2 и
Далее из уравнения (4.8) имеем
а из табл. 6 получаем для английского языка l= 2,16. Тогда для описания программы на уровне английского языка приходим к следующему выводу
Екрит = (24) 3 * (2,16) 2 = 3000 (4.13)
Определим теперь Ео как среднее число элементарных различений между возможными ошибками в программировании, а В — как число переданных ошибок в программе. Можно ожидать, что
но при этом не будет учтено какая-либо избыточность в создаваемой программе.
Однако уровень программы L, собственно, и является мерой такой избыточности. Заметим, что только в потенциальном языке, на котором любая программа может быть выражена в виде вызова процедуры, не повторяются ни операторы, ни операнды. Для такого потенциального языка L = 1. Для всех же остальных языков L уменьшается с увеличением избыточности.
Следовательно, вместо уравнения (4.14) реальнее ожидать, что
По правилам алгебры произведение L ´ Е можно заменить на V, что даст:
Если теперь приравнять Eo из уравнений (4.14) значению Екрит, найденному по уравнению (4.13), то получим соотношение
C другой стороны, подставив в (4.17) выражение для V из (4.10), получим
B= (V * ) 2 / (3000*l) (4.18)
Из выражения (4.18) следует, что поскольку для определения потенциального объема необходимо только знание числа независимых входных и выходных параметров программы, задаваемого в техническом задании на ее разработку, то после выбора языка программирования потенциальное количество ошибок можно оценить до написания программы.
Сколько ошибок в программе? Это вопрос, который волнует каждого программиста. Особую актуальность придает ему принцип кучкования ошибок, согласно которому нахождение в некотором модуле ошибки увеличивает вероятность того, что в этом модуле есть и другие ошибки. Точного ответа на вопрос о количестве ошибок в программе очень часто дать невозможно, а вот построить некоторую оценку — можно. Для этого существуют несколько статических моделей. Рассмотрим одну из них: Модель Миллса.
В 1972 г. суперпрограммист фирмы IBM Харлан Миллс предложил следущий способ оценки количества ошибок в программе. Пусть у нас есть программа. Предположим, что в ней N ошибок. Назовем их естественными. Внесем в нее дополнительно M искусственных ошибок. Проведём тестирование программы. Пусть в ходе тестирования было обнаружено n естественных ошибок и m искусственных. Предположим, что вероятность обнаружения для естественных и искусственных ошибок одинакова. Тогда выполняется соотношение:
Мы нашли один и тот же процент естественных и искусственных ошибок. Отсюда количество ошибок в программе:
Количество необнаруженных ошибок равно (N-n).
Например, пусть в программу внесено 20 искусственных ошибок, в ходе тестирования было обнаружено 12 искусственных и 7 естественных ошибок. Получим следущую оценку количества ошибок в программе:
Количество необнаруженных ошибок равно (N-n) = 12 — 7 = 5.
Легко заметить, что в описанном выше способе Миллса есть один существенный недостаток. Если мы найдем 100% искусственных ошибок, это будут означать, что и естественных ошибок мы нашли 100%. Но чем меньше мы внесем искусственных ошибок, тем больше вероятность того, что мы найдём их все. Внесем единственную исскуственную ошибку, найдем ее, и на этом основании объявим, что нашли все естесственные ошибки! Для решение такой проблемы Миллс добавил вторую часть модели, предназначенную для проверки гипотезы о величине N:
Предположим, что в программе N естественных ошибок. Внесём в неё M искусственных ошибок. Будем тестировать программу до тех пор, пока не найдем все искусственные ошибки. Пусть к этому моменту найдено n естественных ошибок. На основании этих чисел вычислим величину C:
Величина C выражает меру доверия к модели. Это вероятность того, что модель будет правильно отклонять ложное предположение. Например, пусть мы считаем, что естественных ошибок в программе нет (N=0). Внесем в программу 4 искусственные ошибки. Будем тестировать программу, пока не обнаружим все искусственные ошибки. Пусть при это мы не обнаружим ни одной естественной ошибки. В этом случае мера доверия нашему предположению (об отсутствии ошибок в программе) будет равна 80% (4 / (4+0+1)). Для того чтобы довести ее до 90% количество искусственных ошибок придется поднять до 9. Следущие 5% уверенности в отсутствии естественных ошибок обойдутся нам в 10 дополнительных искусственных ошибок. M придется довести до 19.
Если мы предположим, что в программе не более 3-х естественных ошибок (N=3), внесем в нее 6 искусственных (M=6), найдем все искусственные и одну, две или три (но не больше!) естественных, то мера доверия к модели будет 60% (6 / (6+3+1)).
Значения функции С для различных значений N и M, в процентах:
Таблица 1 — с шагом 1;
Таблица 2 — с шагом 5;
Из формул для вычисления меры доверия легко получить формулу для вычисления количества искусственных ошибок, которые необходимо внести в программу для получения нужной уверенности в полученной оценке:
Количество исскуственных ошибок, которые необходимо внести в программу, для достижения нужной меры доверия, для различных значений N:
Таблица 3 — с шагом 1;
Таблица 4 — с шагом 5;
Модель Миллса достаточно проста. Ее слабое место — предположение о равновероятности нахождения ошибок. Чтобы это предположение оправдалось, процедура внесения искусственных ошибок должна обладать определенной степенью «интеллекта». Ещё одно слабое место — это требование второй части миллсовой модели отыскать непременно все искусственные ошибки. А этого может не произойти долго, может быть, и никогда.
1.13. Метрика числа ошибок в программе. Закон Миллера
Предсказывает число первоначальных ошибок (до отладки и тестирования) и не может служить доказательством правильности (корректности) программы, даже если ее значение равно нулю.
^ Джордж Миллер – мозг человека может обрабатывать не более 7+-2 «объектов» одновременно (Закон «7+-2»): 9 двоичных чисел, 8 десятичных чисел, 7 букв алфавита, 5 односложных слов.
Представив эту способность мозга как критическое значение получим ее программное значение.
Пусть каждый объект так же, как и результат, соответствует единице уникальных операндов в потенциальном языке.
Нам известно: и
Тогда критический объем
Из уравнения уровня языка
Для английского языка , тогда для описания программы на уровне английского языка
Если – среднее число элементарных различений между возможными ошибками в программировании, а – число ошибок в программе, то но при этом не будет учтено наличие какой-либо избыточности в программе. Мерой такой избыточности является уровень программы . Следовательно, более реально
При постоянных усилиях на отладку интенсивность обнаружения ошибок следует считать пропорциональной оставшемуся их количеству.
Время наработки на отказ (
(основная масса ошибок выявляется во время отладки, то есть, приблизительно равна )
^ Количество ошибок в текстах программ пропорционально работе программирования, которая может быть вычислена.
Предположив, что с каждым из написанных фрагментов программы связана хотя бы одна ошибка, получим:
расчетный объем программы.
^
1.14. Порядок расчета метрических характеристик программных средств. Расчет начальной надежности программы
Точность расчета метрических характеристик ПС достигается в случае, если правильно оценен параметр в постановке задачи.
^ 1. Расчет структурных параметров ПС.
Учитывая, что оптимальное число входных переменных модуля равно 8, число модулей ПС должно быть равно:
Если , необходимо сделать поправку на число модулей в соответствии с выражением
^ 2. Расчет длины программы.
Длина модуля слов.
Полная длина программы
Последним членом часто пренебрегают.
^ 3. Расчет объема программы
Объем одного модуля:
Объем ПС:
^ 4. Расчет количества команд ассемблера
– коэффициент пересчета Кнута на команды ассемблера
^ 5. Расчет календарного времени программирования.
^ 6. Расчет начального количества ошибок (перед комплексной отладкой)
7. Расчет начальной надежности ПС
В пределах календарного времени разработки период отладки определяется из неравенства
Будем считать, что отладка занимает у разработчика половину времени,
Читайте также: