ГЛАВА 20 Качество ПО
463
Табл. 20-2. Эффективность нахождения дефектов
при использовании разных методик
Методика
Минимальная
Типичная
Максимальная
устранения дефектов
эффективность
эффективность
эффективность
Неформальные
25%
35%
40%
обзоры проекта
Формальные
45%
55%
65%
инспекции проекта
Неформальные
20%
25%
35%
обзоры кода
Формальные
45%
60%
70%
инспекции кода
Моделирование
35%
65%
80%
или прототипирование
Самостоятельная
20%
40%
60%
проверка кода
Блочное тестирование
15%
30%
50%
Тестирование новых
20%
30%
35%
функций (компонентов)
Интеграционное
25%
35%
40%
тестирование
Регрессивное
15%
25%
30%
тестирование
Тестирование системы
25%
40%
55%
Ограниченное бета#тес# 25%
35%
40%
тирование (менее чем в 10 организациях)
Крупномасштабное бета# 60%
75%
85%
тестирование (более чем в 1000 организаций)
Источники: «Programming Productivity» (Jones, 1986a), «Software Defect#Removal
Efficiency» (Jones, 1996) и «What We Have Learned About Fighting Defects» (Shull et al., 2002).
Самое интересное в этих данных то, что типичная эффективность об#
наружения дефектов при использовании любой методики не превышает
75% и что в среднем она равна примерно 40%. Более того, самые попу#
лярные методики — блочное тестирование и интеграционное тестирование — по#
зволяют найти обычно только около 30–35% дефектов. Как правило, использует#
ся подход, основанный на интенсивном тестировании, что позволяет устранить лишь около 85% дефектов. Ведущие организации используют более широкий ди#
апазон методик, достигая при этом 95%#ой или более высокой эффективности ус#
транения дефектов (Jones, 2000).
Итак, если разработчики хотят достигнуть более высокой эффективности обна#
ружения дефектов, они должны полагаться на комбинацию методик. Одно из подтверждений этого вывода было получено в классическом исследовании Глен#
форда Майерса (Myers, 1978b). Участниками исследования были программисты,
обладавшие минимум 7#, а в среднем — 11#летним опытом. Исследуемая программа
464
ЧАСТЬ V Усовершенствование кода содержала 15 известных ошибок. Майерс попросил каждого программиста най#
ти эти ошибки, используя одну из следующих методик:
тестирование выполнения программы по спецификации;
тестирование выполнения программы по спецификации с возможностью изу#
чения исходного кода;
анализ/инспекция с использованием и спецификации, и исходного кода.
Различия эффективности обнаружения дефектов оказались очень боль#
шими: программисты нашли от 1 до 9 дефектов. Средний показатель был равен 5,1, или 1/3 от общего числа известных дефектов.
При использовании одной методики никакая из них не имела статистически зна#
чимого преимущества над любой другой. В то же время любая комбинация двух методик — в том числе использование одной методики двумя независимыми груп#
пами — приводила к увеличению общего числа найденных дефектов почти вдвое.
В исследованиях, проведенных в Лаборатории проектирования ПО NASA, компа#
нии Boeing и других компаниях, было обнаружено, что разные программисты находят разные дефекты. Только примерно каждую пятую ошибку, обнаруженную в ходе инспекций, находят двое или более разработчиков (Kouchakdjian, Green,
and Basili, 1989; Tripp, Struck, and Pflug, 1991; Schneider, Martin, and Tsai, 1992).
Майерс обращает внимание на то, что поиск одних видов ошибок оказывается более эффективным при непосредственном участии людей (например, при инспекции или анализе кода), а других видов — при компьютерном тестировании (Myers, 1979).
Этот вывод подтвердился в более позднем исследовании, показавшем, что чтение кода способствует нахождению дефектов интерфейса, а функциональное тести#
рование — нахождению дефектов управляющих структур (Basili, Selby, and Hutchens,
1986). Гуру тестирования Борис Бейзер (Boris Beizer) сообщает, что неформаль#
ные подходы к тестированию обычно позволяют достигнуть покрытия кода тес#
тами лишь на 50–60%, если
только вы не используете анализатор покрытия(Johnson, 1994).
Таким образом, методики поиска дефектов лучше применять в комбина#
ции. Джонс (Jones) также подтверждает этот вывод. Используя исключи#
тельно тестирование, высоких результатов добиться невозможно. Джонс сообщает, что комбинация блочного тестирования, функционального тестирования и тестирования системы часто приводит к обнаружению менее 60% дефектов, что обычно неприемлемо для конечного продукта.
Эти данные также помогают понять, почему программисты, начинающие приме#
нять дисциплинированную методику устранения дефектов, такую как экстремаль#
ное программирование, добиваются более высокой степени устранения дефектов.
Как показывает табл. 20#3, набор методик устранения дефектов, применяемых в экстремальном программировании, позволяет устранить около 90% дефектов в обычной ситуации и 97% в лучшем случае, что гораздо выше среднего для отрас#
ли показателя, равного 85%. Некоторые программисты связывают этот факт с синергичными отношениями между методиками экстремального программиро#
вания, но на самом деле это просто предсказуемый результат использования кон#
кретного набора методик устранения дефектов. Эффективность других комбинаций методик может оказаться такой же или даже более высокой, поэтому выбор кон#
ГЛАВА 20 Качество ПО
465
кретных методик устранения дефектов, позволяющих достичь желаемого уровня качества, является одним из аспектов эффективного планирования проекта.
Табл. 20-3. Эффективность обнаружения дефектов, характернаядля экстремального программированияМетодика устраненияМинимальнаяТипичнаяМаксимальнаядефектовэффективностьэффективностьэффективностьНеформальные обзоры
25%
35%
40%
проекта (парное программи#
рование)
Неформальные обзоры кода
20%
25%
35%
(парное программирование)
Самостоятельная
20%
40%
60%
проверка кода
Блочное тестирование
15%
30%
50%
Интеграционное
25%
35%
40%
тестирование
Регрессивное тестирование
15%
25%
30%
Общая эффективность
74%
90%
97%
устранения дефектов
Стоимость нахождения дефектовНекоторые методики обнаружения дефектов дороже других. Наиболее экономич#
ные при прочих равных условиях имеют наименьшую стоимость в расчете на один обнаруженный дефект. Равенством прочих условий пренебрегать нельзя, поскольку стоимость методики в расчете на один дефект зависит от общего числа обнару#
женных дефектов, этапа обнаружения каждого дефекта и других факторов, не связанных с экономическими аспектами конкретной методики.
Как правило,
эксперименты показывают, что инспекции обходятся дешев#
ле, чем тестирование. В исследовании, проведенном в Лаборатории про#
ектирования ПО, было обнаружено, что при чтении кода число дефек#
тов, находимых в час, было примерно на 80% более высоким, чем при тестирова#
нии (Basili and Selby, 1987). В другой организации поиск дефектов проектирова#
ния с использованием блочного тестирования был вшестеро дороже, чем при ис#
пользовании инспекций (Ackerman, Buchwald, and Lewski, 1989). Более позднее ис#
следование, проведенное в IBM, показало, что на обнаружение каждой ошибки раз#
работчики тратили 3,5 человеко#часа в случае инспекций кода и 15–25 в случае тестирования (Kaplan, 1995).
Стоимость исправления дефектовСтоимость нахождения дефектов — только одна часть уравнения. Другой частью является стоимость их исправления. На первый взгляд, методика обнаружения дефектов не играет роли: стоимость их исправления всегда будет одинаковой.
Это неверно, потому что чем дольше дефект остается в системе, тем больше средств придется потратить на его устранение. Следовательно, методика, способствующая раннему обнаружению ошибок, снижает стоимость их исправления. Еще важнее
466
ЧАСТЬ V Усовершенствование кода то, что одни методики — такие как инспекции — позволя#
ют определить и симптомы, и причины дефектов за один этап; другие — например, тестирование — указывают на симптомы дефекта, но требуют выполнения дополнитель#
ной работы для диагностики и устранения его причины. В
итоге одноэтапные методики оказываются гораздо более дешевыми, чем двухэтапные.
В одном из подразделений Microsoft обнаружили, что при использова#
нии инспекции кода — одноэтапной методики — на нахождение и ис#
правление дефекта уходит 3 часа, тогда как при использовании тестиро#
вания — двухэтапной методики — на это требуется 12 часов (Moore, 1992). Кол#
лофелло и Вудфилд сообщили, что при разработке программы из 700 000 строк,
над которой работало более 400 программистов, обзоры кода имели гораздо бо#
лее высокую экономическую эффективность, чем тестирование: прибыль на ин#
вестированный капитал была равной 1,38 и 0,17 соответственно (Collofello and
Woodfield, 1989).
Суть сказанного в том, что эффективная программа контроля качества должна включать комбинацию методик, применяемых на всех стадиях разработки. Для достижения высокого качества ПО можно использовать следующую комбинацию:
формальные инспекции всех требований, всех аспектов архитектуры и всех проектов критических частей системы;
моделирование или прототипирование;
чтение или инспекции кода;
тестирование выполнения программы.
20.4. Когда выполнять контроль качества ПО?Как было отмечено в главе 3, чем раньше ошибка внедряет#
ся в приложение, тем сильнее она переплетается с другими частями приложения и тем больше средств придется потра#
тить на ее устранение. Дефект в требованиях может вылить#
ся в один или несколько дефектов в проекте, которые могут привести к появлению множества дефектов в коде. Ошибка в требованиях может привести к разработке дополнительных компонентов архитектуры или подтолкнуть к неудачным ар#
хитектурным решениям. Дополнительные архитектурные компоненты
требуют написания дополнительного кода, те#
стов и документации. С другой стороны, ошибка в требованиях может привести к выбрасыванию частей архитектуры, кода и тестов. Если идея устранения ошибок из чертежей дома перед заливкой фундамента бетоном кажется вам разумной, то вы согласитесь и с тем, что дефекты требований и архитектуры также следует уст#
ранять до того, как они повлияют на более поздние этапы разработки.
Кроме того, ошибки в требованиях или архитектуре обычно имеют более широ#
кие следствия, чем ошибки конструирования. Одна ошибка в архитектуре может затронуть несколько классов и десятки методов, тогда как одна ошибка констру#
Перекрестная ссылка О зависи- мости стоимости исправления дефектов от срока их присут- ствия в системе см. раздел «Об- ращение к данным» раздела 3.1.
Сами ошибки более подробно обсуждаются в разделе 22.4.
Перекрестная ссылка Контроль качества предварительных дей- ствий — например, определения требований и разработки архи- тектуры — в этой книге не рас- сматривается. Информацию по этим темам можно найти в кни- гах, указанных в разделе «До- полнительные ресурсы» в кон- це этой главы.
ГЛАВА 20 Качество ПО
467
ирования скорее всего повлияет только на один метод или класс. Это еще одно убедительное обоснование как можно более раннего нахождения ошибок.
Дефекты проникают в ПО на всех стадиях разработки, поэтому контро#
лю качества следует уделять должное внимание на всех этапах проекта,
начиная с самых ранних. Контроль качества нужно внести в планы в начале работы над программой; его следует выполнять по мере прогресса; нако#
нец, он должен подчеркивать удачное завершение работы над проектом.
20.5. Главный Закон Контроля Качества ПОНи в одном ресторане посетителей не кормят бесплатно, и даже если б кормили, никто не смог бы поручиться за качество блюд. Однако разра#
ботка ПО — совсем не кулинарное искусство, и качество ПО имеет одну важную необычную особенность. Главный Закон Контроля Качества ПО заключа#
ется в том, что повышение качества системы снижает расходы на ее разработку.
В основе этого закона лежит одно важное наблюдение: лучшим способом повы#
шения производительности труда программистов и качества ПО является мини#
мизация времени, затрачиваемого на исправление кода, чем бы оно ни объясня#
лось: изменениями требований, изменениями проекта или отладкой. Средняя для отрасли производительность труда программистов эквивалентна примерно 10–
50 строкам кода на одного человека в день (с
учетом всех затрат, не связанных с кодированием). Написание 10–50 строк кода требует нескольких минут, — на что же уходит остальное время?
Такая, казалось бы, низкая производительность труда час#
тично объясняется тем, что в подобных средних показате#
лях учитывается время, не связанное непосредственно с программированием. Время тестировщиков, руководителей,
секретарей — все эти факторы включены в данный показа#
тель. Определение требований, разработка архитектуры и другие действия, не относящиеся к кодированию, также отра#
жены в «строках кода в день». Однако основные временные затраты объясняются не этим.
Самый длительный этап в большинстве проектов — отладка и исправление не#
правильного кода. При традиционном цикле разработки ПО эти действия зани#
мают около 50% времени (см. раздел 3.1). Сокращение потребности в отладке,
достигаемое благодаря предотвращению ошибок, повышает производительность труда. Следовательно, наиболее очевидный метод сокращения графика разработ#
ки — повышение качества ПО и снижение объема времени, уходящего на его отладку и исправление.
Этот анализ подтверждается реальными данными. В обзоре 50 проектов,
потребовавших более 400 человеколет и включивших почти 3 000 000
строк кода, проведенном в Лаборатории проектирования ПО NASA, было обнаружено, что повышенное внимание к контролю качества позволяло снизить уровень ошибок, но не повышало общие расходы на разработку (Card, 1987).
Перекрестная ссылка О разли- чиях между написанием отдель- ной программы и созданием программного продукта см. под- раздел «Программы, продукты,
системы и системные продукты»
раздела 27.5.
468
ЧАСТЬ V Усовершенствование кода
В исследовании, проведенном в IBM, были получены аналогичные результаты:
Программным проектам с наименьшими уровнями дефектов соответствовали самые короткие графики разработки и максимальные показатели производитель#
ности труда… устранение дефектов на самом деле — самый дорогой и длитель#
ный этап разработки ПО (Jones, 2000).
Это верно и для противоположного края шкалы. В одном исследовании
1985 года ученые попросили 166 профессиональных программистов написать программы по одной и той же спецификации. Итоговые про#
граммы содержали в среднем 220 строк, а на их написание ушло в среднем чуть меньше 5 часов. Результаты оказались поистине удивительными: программисты,
работавшие над своими программами средний объем времени, допустили наиболь#
шее число ошибок. Программисты, которым потребовалось больше или меньше времени, допустили значительно меньше ошибок (DeMarco and Lister, 1985). Ре#
зультаты показаны на рисунке 20#2.
Рис. 20'2. Ни при самом быстром, ни при самом медленном подходе к разработкеПО не наблюдается наибольший уровень дефектовВ сравнении с самой быстрой группой двум самым медленным группам понадо#
билось примерно в 5 раз больше времени для достижения результата с примерно тем же уровнем дефектов. Таким образом, на создание ПО без дефектов не всегда уходит больше времени, чем на написание ПО с дефектами.
Вероятно, в некоторых случаях контроль качества требует значительных затрат.
Если вы пишете приложение управления космическим кораблем или медицин#
ской системой жизнеобеспечения, высокие требования к надежности ПО делают проект более дорогим.
В сравнении с традиционным циклом «кодирование — тестирование — отладка»
улучшенная программа контроля качества ПО оказывается более экономичной.
Она перенаправляет ресурсы от отладки и рефакторинга к предварительным этапам контроля качества. Предварительные этапы влияют на качество системы больше,
чем последующие, поэтому время, потраченное на предварительных этапах, по#
зволяет сэкономить больше времени потом. Результатом является снижение уровня
ГЛАВА 20 Качество ПО
469
дефектов, сокращение сроков разработки и снижение затрат. В трех следующих главах вы найдете еще несколько примеров, иллюстрирующих Главный Закон
Контроля Качества ПО.
Контрольный список: план контроля качества Идентифицировали ли вы специфические характеристики качества, имеющие особую важность в вашем проекте?
Сообщили ли вы другим программистам целевые характеристики качества?
Провели ли вы различие между внешними и внутренними характеристика- ми качества?
Обдумали ли вы, как некоторые характеристики могут усиливать или ос- лаблять другие?
Призывает ли ваш проект к использованию нескольких методик обнаруже- ния ошибок, ориентированных на поиск разных видов ошибок?
Составили ли вы план контроля качества, охватывающий все этапы разра- ботки ПО?
Оцениваете ли вы качество системы каким-нибудь образом,
чтобы можно было определить, повышается оно или понижается?
Понимают ли руководители, что контроль качества требует дополнительных расходов в начале проекта, но зато позволяет добиться общей экономии средств?
Дополнительные ресурсыСоставить список книг для этой главы несложно, потому что методики повышения качества ПО и производительности труда описываются почти во всех трудах, посвященных эф#
фективным методологиям разработки ПО. Сложность в том, чтобы выделить книги,
касающиеся непосредственно качества ПО. Ниже я указал две такие работы.
Ginac, Frank P.
Customer Oriented Software Quality Assurance. Englewood Cliffs, NJ: Prentice
Hall, 1998. В этой очень краткой книге описаны атрибуты качества, метрики каче#
ства, программы контроля качества, роль тестирования в контроле качества, а так#
же известные программы повышения качества, в том числе модель CMM, разрабо#
танная в институте Software Engineering Institute, и стандарты ISO серии 9000.
Lewis, William E.
Software Testing and Continuous Quality Improvement, 2d ed. Auer#
bach Publishing, 2000. В этой книге можно найти подробное обсуждение цикла контроля качества, а также методик тестирования. Кроме того, в ней вы найдете много контрольных форм и списков.
Соответствующие стандартыIEEE Std 730%2002 — стандарт IEEE планирования контроля качества ПО.
IEEE Std 1061%1998 — стандарт IEEE методологии метрик качества ПО.
IEEE Std 1028%1997 — стандарт обзоров ПО.
http://cc2e.com/2043
http://cc2e.com/2050
http://cc2e.com/2057
470
ЧАСТЬ V Усовершенствование кода
IEEE Std 1008%1987 (R1993) — стандарт блочного тестирования ПО.
IEEE Std 829%1998 — стандарт документирования тестов ПО.
Ключевые моментыВысокого качества можно достичь без дополнительных затрат, но для этого вы должны перераспределить ресурсы и предотвращать дефекты вместо того,
чтобы их исправлять.
Стремление к одним характеристикам качества препятствует достижению дру#
гих. Четко определите цели,
имеющие для вас первостепенную важность, и сообщите об этом всем членам группы.
Никакая методика обнаружения дефектов не является достаточно эффектив#
ной. Тестирование само по себе — не самый лучший способ устранения оши#
бок. Составляя программу контроля качества, предусмотрите применение не#
скольких методик, позволяющих обнаружить разные виды ошибок.
Существуют многие эффективные методики контроля качества, применяемые как во время конструирования, так и до его начала. Чем раньше вы обнаружи#
те дефект, тем слабее он переплетется с остальным кодом и тем меньше вреда он успеет принести.
В мире программирования контроль качества ориентирован на процесс.
В отличие от промышленного производства разработка ПО не включает по#
вторяющегося этапа, влияющего на конечный продукт, поэтому качество ре#
зультата определяется процессом, используемым для разработки ПО.
Скачать 5.88 Mb.