Телефон:
8 (929) 574-86-83

Профилактика дефектов: улучшаем качество, снижая затраты (15.10.2009)

Как говорится, болезнь легче предупредить, чем ее лечить. Это применимо как к жизненному циклу человека, так и в отношении жизненного цикла ПО. Говоря о дефектах, разработчики программного обеспечения имеют в виду некоторые отклонения от желаемых характеристик. К таким характеристикам относят полные и точные требования и спецификации, сформированные пожеланиями потенциального покупателя. Таким образом, из-за дефектов продукт не оправдывает ожиданий по требованиям, что расстраивает покупателя.

Если же на наличие дефектов проверяют в процессе разработки, то чем раньше их обнаружат, тем легче и дешевле будет их устранение. Результатом устранения или раннего выявления дефектов станет продукт с наименьшим числом ошибок или без них.
Насколько значима работа с дефектами в области разработки ПО? По информации Computer Finance Magazine (1998), в США до 60 % разработчиков работают в области исправления ошибок. Если брать во внимание только этот факт без учета обеспечения качества, необходимого чтобы угодить покупателю, значимость профилактики дефектов становится очевидной.

Чем раньше обнаружим, тем дешевле
Эффективность раннего обнаружения дефектов подтверждается данными из отчетов. По результатам исследования, проведенного Национальным Институтом Стандартов и Технологии (НИСТ) в 2002, если устранение одного бага на этапе промышленной эксплуатации ПО занимает 15 часов, то при выявлении этого бага на этапе разработки его устранение заняло бы всего 5 часов.
Как сообщает Институт Информационных Систем IBM, стоимость устранения одной ошибки, обнаруженной после выхода продукта, превышала затраты на исправление одной ошибки, обнаруженной во время дизайна, в 4-5 раз, а если баг был выявлен через техническую поддержку, то его устранение обходилось в 100 раз дороже, чем если его находили на этапе дизайна.

Рисунок 1: Затраты на исправление ошибки. Источник: Институт Информационных систем IBM (IBM Systems Sciences Institute)

Достаточно ли для профилактики дефектов зарегистрировать их в некой «системе/инструменте отслеживания дефектов», документируя их и обеспечивая их устранение? Очевидно, что ответ – нет, хотя это и является первым шагом к профилактике дефектов. Профилактика дефектов предполагает наличие структурированной методологии решения задач и проблем, чтобы распознавать, анализировать и предотвращать возникновение дефектов.
Профилактика дефектов заключается в непрерывном сборе информации о неполадках, проведении анализа первопричины, определении и внедрении мер по устранению неисправностей и обмене приобретенным опытом для предотвращения ошибок в будущем.

Принципы профилактики дефектов
Как организовать профилактику дефектов? На рисунке 2 отражен механизм профилактики дефектов. Процесс профилактики начинается с анализа требований: необходимо перевести требования заказчика в спецификации продукта, не внося дополнительных ошибок. Разрабатывается архитектура программы, проводится анализ и тестирование кода, по результатам чего выполняется регистрация и документирование ошибок.

Рисунок 2: Цикл профилактики дефектов

На сером фоне изображены блоки и процессы, которые отражают обработку дефектов в рамках наиболее распространенных принципов софтверной индустрии – выявление, отслеживание/документирование и анализ дефектов для быстрого нахождения решений, реализуемых в короткий срок.
На белом фоне размещены элементы методики профилактики дефектов. Основные процессы профилактики дефектов: выявление первопричины дефекта в результате его анализа, успешный поиск быстрого устранения и профилактической меры. Такие меры профилактики после их одобрения и подтверждения членами команды, становятся основой для проектов в будущем.
Большинство действий по профилактике дефектов требуют наличия координатора. Им может стать руководитель проекта разработки ПО, расширив тем самым круг своих обязанностей, или же кто-то еще из команды. Назначенный координатором профилактики дефектов активно задействован в управлении работами по профилактике дефектов: организации собраний и взаимодействии внутри команды, менеджменте, подготовке сводок по профилактическим мерам.

Пять основных этапов профилактики дефектов:

1. Анализ требований ПО

Таблица 1: Распределение багов по этапам жизненных циклов ПО, на которых они внесены
Этап жизненного цикла ПО	Доля дефектов
Описание требований	20 %
Дизайн	25 %
Кодирование	35 %
Руководство пользователя	12 %
Устранение неполадок	8 %
Источник: Computer Finance Magazine

Как сообщает Computer Finance Magazine, ошибки на этапе создания требований ПО и на этапе проектирования встречаются чаще, нежели в исходном коде. Ошибки, допущенные на стадиях создания требований и проектирования, наиболее вероятны, серьезны и сложно устранимы. Ошибки на этапах требований и проектирования нельзя обнаружить посредством тестирования, необходимо проводить анализ и инспекцию до тестирования. Соотношение ошибок, внесенных на различных этапах жизненного цикла ПО, представлено в таблице 1.
Как видно из многочисленных исследований, проведенных сообществами разработчиков, большинство сбоев в программных продуктах возникает из-за ошибок на этапах требований и проектирования – 64% от всех дефектов (см. рисунок 3) по данным Crosstalk, the Journal of Defense Software Engineering.

Рисунок 3: Причины возникновения дефектов

А значит, чтобы убедиться, что требования заказчика верно переведены в спецификации продукта, необходим подходящий процесс анализа требований. Пожалуй, чтобы разработчик лучше представил себе требования, следует встречаться с заказчиком повторно.

2. Анализ: Проверка автором и экспертная оценка проектной документации

Проверка автором одна из наиболее эффективных процедур для обнаружения тех дефектов, которые впоследствии может выявляет команда тестировщиков или сам пользователь. Сегодня в большинстве софтверных компаний проверка автором считается одной из лучших методик работы с кодом; следует заметить, что качество продукта в этих компаниях заметно улучшается.
Часто такая проверка кода позволяет понизить число дефектов, связанных с реализацией алгоритма, ошибкой в логике или недостатком условий. Когда у разработчика готов модуль кода, для проведения проверки ему достаточно бегло просмотреть код и осознать, что этот код делает по сравнению с тем, что от него требуется.
По своей сути ревью (экспертная оценка) проектной документации похоже на Self-review. Разница состоит в том, что код проверяет некий эксперт, отлично понимающий его функциональность, а не разработчик, благодаря чему появляется свежий взгляд.

3. Регистрация и документирование ошибок

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

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

4. Анализ первопричины и определение профилактических мер
После регистрации и документирования дефектов их необходимо проанализировать. Как правило, назначенный координатор профилактики дефектов или руководитель проекта разработки организует собрание для выявления первопричины дефекта.
Три ключевых принципа анализа первопричины:

Понижаем число дефектов для улучшения качества. Анализ должен привести к внедрению таких изменений в процессы, которые помогут предотвратить дефекты и гарантировать их раннее обнаружение.
Прислушиваемся к советам экспертов. Люди, которые понимают, что именно пошло не так, – это те, кто присутствовал при внесении этих дефектов, то есть – члены команды разработки ПО. Они-то и могут дать наилучшие советы по предотвращению таких дефектов в будущем.
Выявляем систематические ошибки. Наверняка на собрании можно будет обсудить многие дефекты и ошибки, однако некоторые из них оказываются повторяющимися. Такие систематические ошибки составляют немалую часть дефектов на софтверном проекте. Выявление и предотвращение систематических ошибок может оказать большое влияние на качество при относительно малом вложении средств.

Приведенный алгоритм направлен на анализ дефектов с целью выявления их возникновения. Собранные данные о причинах дефектов пригодятся при проведении анализа первопричины дефектов. Дефекты классифицируются по типам. Цель анализа первопричины - выявить наиболее часто возникающий тип дефекта. Например, распределение дефектов по причинам их появления показано на диаграмме (рисунок 4). Наиболее эффективны для такого анализа диагрммы Парето (диаграммы распределения по причинам).

Рисунок 4: Пример распределения дефектов по причинам возникновения

Анализ первопричины – процесс выявления и устранения причины, что в свою очередь позволяет предотвратить повторное возникновение такой проблемы. Выявление причин настолько же важно, как и их устранение.
Каждый тип дефектов и причины, которые приводят к их возникновению, можно отобразить с помощью схемы причинно-следственных связей, пример которой приведен на рисунке 5.

Рисунок 5: Схема причинно-следственных связей для дефекта

Схема причинно-следственных связей – простой графический способ классификации факторов, которые привели к сложившейся ситуации, и выявления связей между ними. Обычно команда разрабатывает эту схему во время специально организованного мозгового штурма. После документирования причин необходимо провести отдельное собрание для поиска путей устранения дефектов; на этом собрании также обсуждаются изменения, необходимые для минимизации повторения дефектов.

5. Внедрение процедур профилактики дефектов в процесс разработки ПО
Среди всех процедур по профилактике дефектов самой сложной является внедрение изменений в процесс разработки. Для него требуется полное участие со стороны команды разработчиков и руководства. План действий составляется для изменения существующих процессов или введения новых с согласия руководства и команды. На этом этапе профилактики дефектов проводятся и другие процедуры, такие как:

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

Следует помнить, что для успешной профилактики дефектов не достаточно работы одного человека; требуется отдача всей команды. Группе разработчиков следует улучшить процесс профилактики, выявляя дефекты на начальном этапе, что минимизирует время их исправления и, таким образом, снижает издержки проекта.

Заключение: за пределами "человеку свойственно ошибаться"
Человеку свойственно ошибаться, но процедуры профилактики дефектов увеличивают возможность разработчиков ПО учится на совершенных ошибках, и, что более важно, учится на ошибках других. Применение методов профилактики дефектов приводит к следующим результатам:

Улучшение чек-листа оценки качества продукта
Снижение трудозатрат на внесение изменений
Значительное уменьшение числа дефектов и их критичности
Улучшение взаимодействия между командой проекта и руководством
Оптимизация планирования ресурсов

Для подготовки статьи использованы материалы Mukesh Soni*

^{*Mukesh Soni обладает семилетним опытом проектирования продуктов, как аппаратных так и программных, на разных этапах, включая исследование, разработку, поддержку и обслуживание. Он работал в таких компаниях как L&T Infotech, General Electric, Robert Bosch, а теперь Tektronix. Он аттестован GE с квалификацией «Зеленый пояс» по системе «Шесть сигма», является автором двух книг, специалистом по электронике и биоинженерии. Вы можете связаться с ним mukesh.soni@tek.com.}