Время — деньги. Создание команды разработчиков программного обеспечения

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

Обычно, когда близится завершение внутреннего этапа, выпуск бета-версии и кандидата на выпуск, интенсивность устранения выше интенсивности возникновения. Если это не так, то новых проблем появляется больше, чем решается, а это не то, что вы бы хотели видеть, приближаясь к периоду стабилизации или выпуску.

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

Количество изменений

Количество изменений также может о многом поведать. Количество изменений показывает число обновлений информации о неполадке. Причина обновления не имеет значения. Большое число изменений — верный знак того, что не всё идёт так гладко. Так, оставшаяся неполадка может исследоваться многими людьми, и ни один из них не установит причину её возникновения. Возможно, её передавали из отдела технической поддержки к разработчикам, от тестировщиков — к разработчикам или между двумя разработчиками туда и обратно. Наблюдение за количеством изменений информации об ошибках поможет определить те, что требуют внимания со стороны ведущих специалистов и менеджера проекта.

Счётчик неудачных исправлений

Ещё один хороший способ оценки нестабильности проекта — счётчик неудачных исправлений для всех ошибок, которые считались исправленными, но на самом деле исправлены не были. При устранении неполадки от команды тестировщиков требуется подтверждение того, что ошибка действительно исправлена. Если проблема всё ещё существует или исправление не принято, ей возвращается статус открытой, а значение поля «Исправлено неудачно» устанавливается в 1. Если тестировщики снова не могут подтвердить устранения неполадки, значение счётчика увеличивается до 2 или 3. Это сигнализирует о серьёзности проблемы и говорит о необходимости вмешательства ведущих специалистов или менеджера проекта.

Дополнительные средства

Хотя средства управления исходным кодом и устранения проблем были стержнем процесса разработки в NuMega, мы регулярно использовали и другие инструменты.

Отладчики

Одним из наиболее важных инструментов для наших разработчиков был разработанный NuMega Technologies невероятно мощный отладчик для Windows — SoftICE. Он загружается при запуске системы как драйвер устройства на уровне ядра и предоставляет беспрецедентные возможности управления и наблюдения за внутренними процессами приложения и операционной системы. Команда разработчиков часто использовала SoftICE для разрешения наиболее сложных проблем при отладке.

Средства анализа производительности и полноты

Мы часто использовали средства анализа производительности, в том числе наши собственные продукты TrueTime и TrueCoverage, для настройки производительности собираемых приложений. Мы поняли, что эти инструменты нужно использовать регулярно в течение цикла разработки, а не в самом конце, когда времени на оптимизацию или устранение проблем не хватает. Анализ производительности проекта по завершении определённого этапа или при выпуске бета-версии предупреждает проблемы и часто раскрывает ошибки, которые могут не проявляться в коде до самого выпуска. Не ждите, пока вы столкнётесь с проблемами производительности, а начинайте сразу применять средства анализа производительности.

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

Средства написания сценариев и автоматизации тестирования