7.3 Дефекты программных изделий

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

Тогда количественной характеристикой качества можно считать плотность оставшихся в программном изделии дефектов после поставки заказчику.¹

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

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

Размер программного кода ПИ измеряется числом строк кода (LOC - Lines of Code) или тысяч строк кода (KLOC). Для обеспечения возможности сравнения размеров кодов, написанных на разных языках программирования, применяется единица измерения «тысяча строк эквивалентного ассемблерного кода» (KAELOC – К of Assembler Equivalent Lines of Code). Для различных языков программирования статистически выявлены коэффициенты пересчета KLOC данного языка программирования в KAELOC, которые представлены в таблице 7.2.

Таблица 7.2  Коэффициенты пересчета

Язык программирования	Коэффициент пересчета
Assembler, Macro-Assembler	1
LISP	1,5
С	2,5
C++	11
FORTRAN	3
Pascal	3,5
Query Languages	25
Unix Shell Script	1,5
4-th GLs*)	16
*) Объектно-ориентированные языки 4-ого поколения

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

,

где m – математическое ожидание;  – среднеквадратическое отклонение.

В практике производства ПИ считают, что его качество имеет уровень i сигма, если количество строк кода, не содержащих дефекты, попадает в интервал [m–i, m+i] относительно математического ожидания m (рис. 7.1). Оставшиеся за пределами этого интервала строки кода, содержащие ошибки, определяют плотность дефектов в поставляемом ПИ.

Например, интеграл при =1 равен 0,6827. Поэтому количество строк, содержащих дефекты, составляет 31,73% всех строк кода.

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

Таблица 7.3  Плотности дефектов в поставляемом ПИ в зависимости от уровня его качества

Уровень качества (деф./КАЕLOС):	4 сигма	5 сигма	6 сигма
по нормальному распределению	0,063	0,00057	0,000002
по аналогии с пром. производством	6,21	0,23	0,0034

Тогда при уровне качества 6 сигма заказчику может быть поставлено ПИ, в котором может быть только 3…4 дефекта на миллион строк ассемблерного эквивалента. Это очень высокий уровень качества ПИ, к нему должны стремиться все современные производители программного обеспечения.

Невозможно поставлять пользователям высококачественные ПИ, не имея в организации соответствующего уровня качества процесса его разработки. Оценка уровня качества разработки ПИ осуществляется так же, как и поставляемого ПИ, исходя из концепции уровня качества 6 сигма. Существует правило: если организация хочет иметь возможность выпускать ПИ с уровнем качества i сигма в плановые сроки без превышения установленных людских и финансовых ресурсов, необходимо, чтобы в этой организации был достигнут уровень качества выполнения проекта в целом не ниже, чем (i-1) сигма.