Снижение количества дефектов в крупных проектах по разработке программного обеспечения

Question

В большинстве программных проектов дефекты возникают из-за требований, дизайна, кодирования и исправления дефектов. По моему опыту, большинство дефектов происходит на этапе кодирования.

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

Я видел следующие аппрокраски, используемые с разным уровнем успеха и сопутствующей стоимостью

• код проверки
• модульные тесты
• инструменты статического анализа кода
• использование стиля программирования
• одноранговое программирование

Answer 1

По моему опыту, это ошибка процесса, а не разработчиков, которые допускают дефекты. См. Они пишут правильные вещи о том, как этот процесс влияет на ошибки.

Конкурсные испытания

Разработчики программного обеспечения должны стремиться помешать тестировщикам найти проблемы с программным обеспечением, которое они написали. Тестировщики должны быть вознаграждены (не должны быть финансовыми) за обнаружение проблем с программным обеспечением.

Выйти

Назначьте ответственного за программное обеспечение человека, который лично заинтересован в том, чтобы программное обеспечение не имело проблем. Программное обеспечение не поставляется, пока этот человек не будет удовлетворен.

Требования

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

Переключение задач

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

Метрика

Соберите как можно больше метрик. Строки кода для метода, для класса, отношения зависимости и другие.

Стандарты

Убедитесь, что все придерживаются корпоративных стандартов, в том числе:

• Форматирование исходного кода. Это может быть автоматизировано, и это не обсуждение.
• Соглашения об именах (переменные, объекты базы данных, URL-адреса и т. Д.). Используйте инструменты, когда это возможно, и еженедельные проверки кода для обеспечения выполнения.
• Код должен компилироваться без предупреждений. Обратите внимание и просмотрите все исключения.
• Согласованное (повторное) использование API, как внутренних, так и внешних.

Независимый обзор

Наймите стороннего поставщика для выполнения проверки кода.

Компетентные программисты

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

Распространение информации

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

Отслеживание задач

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

Оценка процесса

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

Answer 2

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

Две вещи снижают количество ошибок

• Ловкость. Вы с меньшей вероятностью будете внедрять ошибки на каждом этапе (требования, дизайн и т. Д.), Если вы не делаете так много на каждом этапе. Если вы попытаетесь написать все требования, вы совершите ужасные ошибки. Если вы попытаетесь написать требования к следующему спринту, скорее всего, вы исправите эти несколько требований.

• TDD. У вас меньше шансов бороться с плохими требованиями или плохим дизайном, если вам сначала нужно написать тест. Если вы не можете понять, что вы тестируете, у вас есть ошибка с требованиями. Прекратить кодирование. Отойди от клавиатуры.

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

Answer 3

Дополнительно:

• База знаний проекта . В нем говорится, как мы выполняем действие X (например, «проверка формы») в этом проекте. Это позволяет унифицировать и повторно использовать тестируемое решение, предотвращая появление ошибок при повторном изобретении колеса.

• Мониторинг производственных ошибок . Когда производственная ошибка происходит, это исследуется. Почему этот баг не был пойман? Как мы можем гарантировать, что это больше не повторится? Затем мы изменим процесс соответственно.

Answer 4

Шаг 1 - понять, где вводятся ваши дефекты.

Используйте методику, такую ​​как Ортогональная классификация дефектов (ODC) , чтобы измерить, когда в программном обеспечении жизненного цикла внедряются дефекты и когда они обнаруживаются. Как только вы узнаете, когда дефекты были введены, и определили, когда они были обнаружены, вы можете начать понимать пробелы в вашем процессе в отношении внедрения и удаления дефектов.

Шаг 2 - Разработайте дефектные «фильтры» и адаптируйте ваш процесс

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

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

Answer 5

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

• выявление и исправление неоднозначных, неточных или просто неверных требований
• разоблачение неоптимальной и / или хрупкой архитектуры

может сэкономить колоссальное количество времени и общую слизистую оболочку желудка в проекте значительного масштаба.

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

• сокращение, исключение и / или консолидация собраний
• обеспечивает рабочую среду без прерываний
• позволяет разработчикам исправлять свои дефекты, когда они их обнаруживают (хотя ответственный код еще свеж в их памяти), а не откладывать их на более позднее время, когда контекст должен быть восстановлен

Answer 6

Я думаю, что основной проблемой скорости впрыска может стать множество источников, и она варьируется от среды к окружающей среде.

Вы можете использовать множество лучших практик, таких как TDD, DDD, парное программирование, непрерывная интеграция и т. Д. Но вы никогда не будете свободны от ошибок, потому что ошибки создают люди, а не процессы.

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