CC BY
40
ПРЕДОТВРАЩЕНИЕ ДЕФЕКТОВ ПРИ СОЗДАНИИ ПРОГРАММНЫХ ИЗДЕЛИЙ
С.Н. Баранов, А.Н. Домарацкий, Н.К. Ласточкин, В.П. Морозов
Современные программные изделия (ПИ) представляют собой настолько сложные объекты [1], что формулирование исчерпывающих требований для них - задача практически невыполнимая. Поэтому в реализующем эти требования ПИ неизбежны несоответствия между тем, как заказчик понимает свои требования и тем, как они проявляются в поведении разработанного исполнителем ПИ.
Расхождения в оценке поведения ПИ (качество поставленного заказчику ПИ) характеризуются количеством содержащихся в выпущенном ПИ дефектов. В практике производства ПИ его качество принято определять по плотности оставшихся в нем дефектов после поставки заказчику. Плотность дефектов в поставленном ПИ, в свою очередь, принято определять отношением количества оставшихся в ПИ дефектов к общему размеру его программного кода [2].
Размер программного кода ПИ измеряется числом строк кода (LOC - Lines of Code) или тысяч строк кода (KLOC). Для обеспечения возможности сравнения размеров кодов, написанных на разных языках программирования, применяется единица измерения "тысяча строк эквивалентного ассемблерного кода" (KAELOC - K of Assembler Equivalent Lines of Code). Для различных языков программирования статистически выявлены коэффициенты пересчета KLOC данного языка программирования в KAELOC, которые представлены
Таблица 1
Значения коэффициентов пересчета для вычисления строк ассемблерного эквивалента
Язык Коэффициент
программирования пересчета
Ada 4,5
Assembler 1
C 2,5
C++ 11
Forth 5
FORTRAN 3
LISP 1,5
Macro-Assembler 1
Pascal 3,5
Query languages 25
Unix shell script 1,5
4-th GLs 16
в таблице 1.
При поставке ПИ заказчику оценку его качества определяют по плотности оставшихся в нем
дефектов, приведенной к размеру программного кода в 1000 КЛЕЬОС. В любом ПИ теоретически дефекты могут содержаться в каждой строке кода. Тогда можно считать, что в ПИ размером в 1000 КЛЕЬОС распределение вероятностей строк кода, содержащих дефекты и принятых за случайные величины, подчиняется нормальному закону распределения (рис. 1).
Исходя из вышесказанного, в практике производства ПИ считают, что его качество имеет уровень 1 сигма (сигма (5) - это среднеквадратиче-ское отклонение нормального распределения), если количество строк кода, содержащих ошибки, попадает за интервал [т-15, т+15] относительно математического ожидания т (см. рис. 1).
В действительности в поставляемом ПИ распределение вероятностей строк кода, содержащих ошибки, отличается от нормального. Поэтому для оценки качества ПИ используют по аналогии с промышленным производством в машинострое-
Таблица 2
Плотности дефектов в поставляемом ПИ в зависимости от уровня его качества
Уровень качества 4 сигма 5 сигма 6 сигма
деф./KAELOC 6.21 0.23 0.0034
нии несколько увеличенные плотности дефектов [3-4] (табл. 2).
Из таблицы 2 видно, что при уровне качества ПИ 6 сигма заказчику может быть поставлено ПИ, в котором может быть только 3 дефекта на миллион строк ассемблерного эквивалента. Это очень высокий уровень качества ПИ, к нему должны стремиться все современные производители программного обеспечения.
Невозможно поставлять пользователям высококачественные ПИ, не имея в организации соответствующего уровня качества процесса его разработки (под процессом понимается технологический процесс обеспечения, выполнения и поддержки жизненного цикла ПИ от концептуализации проекта ПИ и планирования работ по нему до поставки и сопровождения созданного ПИ).
Оценка уровня качества разработки ПИ осуществляется так же, как и поставляемого ПИ, исходя из концепции уровня качества 6 сигма. Существует правило: если организация хочет иметь возможность выпускать ПИ с уровнем качества 1 сигма в плановые сроки без превышения установленных людских и финансовых ресурсов, необходимо, чтобы в этой организации был достигнут
плотность вероятностей
68,26%
1000 КЛЕШС
всех строк 95,44 % всеТ^трок -
— ■ 99,73% всех строк-
- 99,9937% всех строк-
99,999943% всех строк -99,9999998% всех строк -
число строк кода
Рис.1. Распределение вероятностей строк кода, содержащих дефекты
0
уровень качества выполнения проекта в целом не ниже, чем (1-1) сигма.
В любой выпускающей ПИ организации во время выполнения проекта его исполнители допускают ошибки, часть которых переходит в дефекты. При этом оценка общего количества возможных ошибок в проекте по приведенному правилу определяется уровнем качества выпускаемого ПИ.
Задача обеспечения требуемого качества выпускаемого ПИ состоит в том, чтобы, имея установленный уровень его качества, попытаться так организовать работу по нахождению и устранению допущенных ошибок в проекте (организовать работу по предотвращению дефектов в проекте), чтобы выполнить этот проект в кратчайшие сроки силами имеющегося коллектива разработчиков.
Исходя из реальных метрик, полученных в разных организациях при выполнении многих проектов ПИ, установлено, что трудоемкость нахождения и устранения ошибки в два-пять и более раз меньше трудоемкости нахождения и устранения дефекта [5]. Поэтому в программном проекте целесообразно организовать работу так, чтобы обеспечить возможность раннего обнаружения и устранения допущенных ошибок на всех фазах жизненного цикла ПИ. Важным средством обнаружения ошибок в проекте ПИ являются все виды обзоров создаваемых продуктов проекта (всех документов и программных кодов).
Работу по обнаружению и устранению допускаемых в проекте ошибок принято характеризо-
вать коэффициентом предотвращения дефектов. Этот коэффициент является статистическим и определяется как отношение количества найденных и устраненных ошибок в проекте на всех фазах жизненного цикла ПИ: от системного тестирования к общей сумме возможных ошибок в проекте до поставки ПИ заказчику. Он дает оценку возможного количества допущенных в проекте ошибок, которые превращаются в дефекты.
Как правило, большинство дефектов проекта (не найденных в проекте ошибок в результате деятельности по предотвращению дефектов) обнаруживается и устраняется на этапе модульного, интеграционного тестирования и тестирования работоспособности ПИ, оставшиеся дефекты обнаруживаются и устраняются на фазе системного тестирования, а некоторые дефекты, может быть, остаются в ПИ навсегда.
Может показаться, что чем меньше ошибок переходит в дефекты, тем меньше времени будет потрачено на устранение оставшихся дефектов и тем самым уменьшится общая трудоемкость проекта. Однако практические наблюдения показывают, что трудоемкость работ по выполнению проекта ПИ в целом находится в сложной зависимости от коэффициента предотвращения дефектов.
Это объясняется тем, что время обнаружения ошибки, допущенной в любом создаваемом продукте, зависит от относительной трудоемкости его обзора (отношение трудоемкости обзора к трудоемкости создания обозреваемого продукта) и количества до нее уже обнаруженных ошибок из оценки общего числа всех возможных. Наш опыт по разработке ПИ в соответствии со стандартным процессом [1] показывает, что удовлетворительные результаты в работе по предотвращению дефектов наблюдаются при относительной трудоемкости обзоров равной 10%, при значениях коэффициента предотвращения дефектов, лежащих в пределах [0.75-0.85].
На основе приведенных рассуждений построим графическое отображение модели возникновения и устранения ошибок и дефектов в проекте ПИ, используя для этого реальные метрики стандартного процесса АОЗТ "Информационные деловые услуги" (ИДУ), созданного при Санкт-Петербургском институте информатики и автоматизации РАН.
Стандартным процессом ИДУ определена модель жизненного цикла ПИ в виде спирали с четырьмя фазами - "Планирование и составление требований", " Высокоуровневое и низкоуровневое проектирование", "Кодирование и отладка", "Системное тестирование". На рисунке 2 представлена метрика - реальное распределение трудоемкостей фаз жизненного цикла ПИ, а на рисунке 3 - реальное распределение количества возникающих ошибок в проекте на всех фазах разработки ПИ. Эти метрики получены в ИДУ в результате работы в течение трех лет более чем над 10 проектами ПИ с качеством 5 сигма в различных предметных областях.
Оценку суммарного количества допустимых ошибок в проекте, выполняемом с заданным качеством, принято исчислять только из размера нового программного кода выпускаемого ПИ (без учета повторно используемых программных кодов). Так, например, если уровень качества разработки ПИ с размером нового кода в N КЛЕЬОС соответствует 4 сигма (аналог тому, что заказчику поставляется ПИ с новым кодом того же размера с качеством 4 сигма), то оценка допустимого количества ошибок в проекте будет равна 6.21 *N (штук). При этом считается,
что повторно используемые коды имеют тот же уровень качества, что и разрабатываемое ПИ, или выше.
На рисунке 4 представлено графическое отображение модели обнаружения и устранения ошибок и дефектов в проекте на этапе разработки ПИ в ИДУ (уровень качества разработки ПИ - 4 сигма, уровень качества поставляемых заказчику ПИ - 5 сигма).
По оси абсцисс на рисунке 4 последовательно отложены трудоемкости (в %) всех фаз разработки ПИ (без учета фазы "Системное тестирование"). Отдельно выделена суммарная трудоемкость работ по предотвращению и устранению дефектов на фазах {1}, {2}, {3} и {4} (последний этап 3.4 на рис. 4). Трудоемкость этапа 3.4 представляет собой сумму трудоемкостей по выявлению и устранению 75 % ошибок из оценки допустимого числа ошибок в проекте (коэффициент предотвращения дефектов стандартного процесса ИДУ равен 0.75), выявлению и устранению некоторого числа (не обязательно всех) дефектов на каждой из фаз разработки ПИ (фазы {1}, {2}, {3}), выявлению и анализу причин возникновения ошибок в прошлом и выработке мер по устранению обнаруженных причин в будущем, по устранению всех оставшихся дефектов, обнаруженных на фазе {4} ("Системное тестирование").
При этом следует исходить из того, что по окончании системного тестирования в поставляемом ПИ оставалось дефектов не более, чем значение оценки допустимого числа дефектов, определяемой уровнем качества ПИ (не более величины, определенной на рисунке 4 нижней параллельной оси абсцисс прямой).
В организации ИДУ трудоемкость этапа 3.4
Фаза {1} 1.1. Планирование
1.2. Составление требований
Фаза {2} Проектирование
Фаза {3} 3.1. Кодирование 3.2. Модульное, интеграционное тестирование, тестирование работоспособности
3.3. Составление пользовательской
документации
Рис. 3. Реальное распределение количества возникающих ошибок и дефектов на фазах разработки ПИ стандартного процесса ИДУ
Фаза {1} 1.1. Планирование
1.2. Составление требований
Ф а за {2} Проектирование
Фаза {3} 3.1. Кодирование 3.2. Модульное, интеграционное тестирование, тестирование работоспособности
3.3. Составление пользовательской
документации
Ф а за {4} Системное тестирование
Рис. 2. Реальное распределение трудоемкостей фаз жизненного цикла ПИ стандартного процесса ИДУ
Оценка допустимого числа ошибок и дефектов в проекте = К*6.21
% 100
86.48
Оценка допустимого числа поставляемых дефектов в ПИ = N^.23
Рис. 4. Графическое отображение модели обнаружения и устранения ошибок и дефектов при разработке ПИ с качеством 5 сигма
составляет 12 % от общей трудоемкости проекта ПИ.
По оси ординат графика (рис. 4) отложены значения оценок допустимого на различных фазах разработки ПИ числа ошибок (в % от величины оценки допустимого количества ошибок в проекте) - возрастающая часть графика и оценка количества обнаруженных и устраненных ошибок и дефектов на тех же фазах - нисходящая часть графика. В организации с хорошо налаженным стандартным процессом величины этих оценок приближаются друг к другу, то есть в такой организации практически все допустимые ошибки и дефекты проекта находятся и устраняются во время обзоров продуктов и всех видов тестирования ПИ.
На рисунке 4 отсутствует фаза "Системное тестирование" (фаза {4} на рис. 2), поскольку в группе тестирования не осуществляется разработка ПИ, и новых ошибок в его программный код не вносится.
Количество ошибок, допущенных и устраненных на фазе {4} при разработке тестов и тестовых комплектов, должно учитываться отдельно от ошибок разработки ПИ. Для определения качества тестов и тестовых комплектов на фазе "Системное
тестирование" должны использоваться те же механизмы учета допущенных и устраненных ошибок и дефектов, что и при разработке ПИ.
Заметим, что деятельность по предотвращению дефектов (плановые обзоры всех кодов и документов, сбор и анализ причин возникновения ошибок и дефектов в проекте, определение и осуществление мероприятий по устранению выявленных причин) и все виды тестирования ПИ являются средством обеспечения требуемого уровня его качества. Поэтому при выполнении программного проекта важно не только сохранять в базе данных все найденные ошибки и дефекты, но и поддерживать правильный и наглядный учет всех обнаруженных, устраненных (закрытых) и еще не устраненных (открытых) ошибок и дефектов.
Для обеспечения такого учета в проекте ПИ целесообразно, начиная с первой фазы, осуществлять плановую работу по обнаружению ошибок и
%
100.0 3.4
Фаза {1} 1.1. Планирование 1.2. Составление требований
Фаза {2} Проектирование
Фаза {3} 3.1. Кодирование
3.2. Модульное, интеграционное тестирование, тестирование работоспособности
3.3. Составление пользовательской документации
3.4. Нахождение и устранение ошибок и дефектов на фазах {1},{2},{3}, {4}, выявление причин их возникновения
N - размер нового кода ПИ в КЛЕЬОС
Рис. 5. График отслеживания найденных, открытых и закрытых ошибок и дефектов при выполнении проекта ПИ с качеством 5 сигма
дефектов во всех продуктах, создаваемых на фазах жизненного цикла ПИ (в планах, в требованиях заказчика к ПИ, спецификациях высокоуровневого и детального проектирования, кодах и во всех других продуктах фаз) в результате всех видов обзоров и тестирования, производить запись обнаруженных ошибок и дефектов в базу данных ошибок и дефектов (БДОД), а после их устранения записывать в нее количество закрытых ошибок и дефектов. В БДОД необходимо регулярно производить подсчет найденных, закрытых и открытых ошибок и дефектов на момент окончания очередного ее обновления. По результатам такого подсчета автоматически осуществляется построение графиков, аналогичных показанным на рисунке 5. Графики (рис. 5) автоматически корректируются одновременно с обновлением БДОД.
В ИДУ обновление графиков осуществляется каждую неделю с начала проекта ПИ (этот график является одним из компонентов еженедельного метрического отчета по каждому проекту ПИ). При этом каждый руководитель проекта в свой работе по управлению проектом стремится к тому, чтобы к окончанию любой фазы жизненного цикла ПИ было бы найдено и устранено такое общее число ошибок и дефектов на ней, которое бы соответствовало метрикам стандартного процесса этой фазы (см. возрастающие части графика графической модели рис. 4).
Анализ графического метрического отчета, показанного на рисунке 5, является не только эффективным средством отслеживания возможного качества создаваемого ПИ, но и средством для выработки управляющих воздействий по улучшению деятельности по предотвращению дефектов.
Так, например, если в результате обзоров и тестирования в нескольких еженедельных метрических отчетах подряд указывается меньшее число ошибок и дефектов, чем определено метриками стандартного процесса (см. рис. 4), то это является свидетельством низкого качества обзоров и(или) плохо продуманного тестирования (три и более отчетов подряд) или сигналом к необходимости повышения качества выполнения этих мероприятий (два отчета подряд).
В заключение отметим, что графическая модель обнаружения и устранения ошибок и дефектов в программном проекте (рис. 4) и еженедельный метрический отчет о количестве обнаруженных, открытых и закрытых ошибок и дефектов (рис. 5) совместно представляют собой эффективное средство для отслеживания уровня качества выполнения программного проекта и управления качеством создаваемых ПИ.
Список литературы
1. Paulk, M.C., B.Curtis, M.B.Chrissis, Ch.V.Weber (1993) Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24; ESC-TR-93-177. Key Practices of the Capability Maturity Model, Version 1.1. CMU/SEI-93-TR-25; ESC-TR-93-178. Software [2] Six Sigma Producibility Analysis and Process Characterization, by M. J. Harry and
2. R. Lawson, Motorola University Press, Chapter 6, (708) 576-7507.
3. Suzanne de Treville, Norman M. Edelson, and Rick Watson, "Getting Six Sigma Back to Basics," Quality Digest, May 1995, pp. 42-47.
4. IEEE Standards Collection. Software Engineering, 1993 Edition. - New York: IEEE, 1993. - 952 p.
5. Robert B. Grady, Practical Software Metrics for Project Management and Process Improvement, HP Professional Books, 1992, 270 p.
СРАВНЕНИЕ СЛОЖНЫХ ПРОГРАММНЫХ СИСТЕМ ПО КРИТЕРИЮ ФУНКЦИОНАЛЬНОЙ ПОЛНОТЫ
Г.Н. Хубаев
В настоящей работе объектом рассмотрения являются сложные программные системы (ПС), но описанный алгоритм может применяться для оценки функциональной полноты и других характеристик любых сложных систем, имеющих десятки, сотни и тысячи функций (свойств, признаков, реализуемых услуг и т.п.). Так, ПС, базирующаяся на предложенном алгоритме, успешно использовалась не только по своему основному назначению, но и для формализованного анализа текстов (текстовых файлов).
В сегодняшних условиях рынок ПС в состоянии предложить потенциальному покупателю
множество систем одного назначения, отличающихся по составу и качеству выполняемых функций (эксплуатационных параметров, характеристик, предоставляемых услуг и др.). Поэтому перед покупателем-пользователем встает проблема выбора из перечня конкурирующих систем одной или нескольких, в наибольшей степени удовлетворяющих его требованиям, например, к функциональной полноте или другим эксплуатационным характеристикам. Если речь идет о программных продуктах (ПП), то для реализации оптимального выбора необходимо, во-первых, располагать количественной оценкой того, насколько (в какой сте-
