Июнь 2008

«В программировании, как и все остальное, чтобы быть в ошибке является возродиться.»

Алан Джей Перлис, первый лауреат премии Тьюринга

20 мая 2008 статический анализ инструментов поставщик Coverity выпустила доклад, озаглавленный «Открытый исходный отчет 2008». Доклад включает информацию, собранную в течение первых двух лет Coverity сканирования проекта, который был разработан как часть контракта из США министерства национальной безопасности. Coverity предоставляет инструменты для открытых проектов с целью определения качества и безопасности недостатки в его анализа базы кода. После определения, разработчики open source проектов получили информацию для того, чтобы способствовать усилению безопасности программного обеспечения.

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

Данные, используемые в отчете

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

Coverity является поставщиком программного обеспечения, который разрабатывает инструменты для автоматического определения недостатков в исходном коде. В то время как обычно продается для разработчиков коммерческого программного обеспечения, Департамент национальной безопасности США контракт Coverity для анализа программного обеспечения с открытым исходным кодом (ПСОК) и предоставить результаты для открытия разработчиков, чтобы они могли исправить дефекты, которые были выявлены.

Coverity «Открытый исходный отчет 2008», включает выборка некоторых из данных, собранных с момента запуска проекта в марте 2006 года. Информация в докладе попадает в целый ряд различных категорий. Есть данные о степени улучшения и регрессии качества проектов с открытым кодом с помощью сканирования сайта. Есть данные о частоте различных типов дефектов, выявленных анализа и информации о последствиях каждого типа дефекта. Существуют статистические корреляции между различными измерениями программных проектов, которые отслеживаются и статистические данные о доле дефектов, где разработчики определено, что средство анализа был неправ, когда он утверждал, что дефект.

Данные в отчете на основе проектов с открытым кодом, которые добавляют до 55 миллионов строк кода. В более чем 14 000 построения и анализа сессий более двух лет почти 10 миллиардов строк кода выполнялись через механизм анализа. В дополнение к глядя на наличие дефектов, анализ сохраняет сведения о коде, например имена и числа функций и их длины, файлы, которые включают различные проекты и расчетные сложности метрик. Коммерческое программное обеспечение не является обычно доступны для анализа на постоянной основе например, выполненных в проекте сканирования. Коммерческие разработчики часто не освобождают их исходный код, и когда они делают, это обычно в виде конкретной версии, которая обычно получает тщательной проверки до его публикации.

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

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

Выводы доклада

Плотность дефектов измеряется в количестве дефектов на 1000 строк кода. За два года с марта 2006 по март 2008 года средняя дефекта плотности в проектах, наблюдаемом упадено 0,30 дефектов на тысячу строк кода до 0,25, или примерно 1 дефект на 3333 строк кода для одного дефекта на 4000 строк кода. Это общее улучшение 16%. На рисунке 1 показаны изменения в плотности дефекта.

Рисунок 1: Изменение плотности дефекта

Статистическая корреляция была выполнена для сравнения дефекта плотности и длины функции СРЗНАЧ в каждом проекте. Поправочный коэффициент доверия был 1,49%, где факторы доверия может варьироваться от 0% до 100%. Данные, включенные в отчет показывают никакой корреляции между плотностью дефектов и функции средней длины. Поскольку рекомендации часто предусматривают, что длинные функции должны быть повторно разложенном на несколько меньших функций, поддержка, что практика будет продемонстрировано если данные свидетельствуют о корреляции более высокой плотности дефекта с длиной более функции СРЗНАЧ. Хотя могут быть преимущества повторно факторинг для оказания помощи в ремонтопригодности кода, более короткие функции не гарантируют улучшения плотности дефекта. На рисунке 2 показана связь между плотностью дефектов и функции длины.

Рисунок 2: Плотность дефектов статического анализа и функции длина

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

Codebase размер и дефект count корреляция составила 71,9%, что указывает, что увеличение числа дефектов во многом линейный с ростом количества строк кода. Если увеличение сложности приводит к более дефектов и более частые дефекты, линейная корреляция должна быть намного ниже, чем показатель почти 72%. Это, как представляется, указывают, что написание 1000 дополнительных строк кода для добавления большой базы кода (скажем, более 1 миллиона строк) не немного сложнее или ошибок чем 1000 строк кода для добавления небольшой базы кода.

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

Сравнения производятся в докладе между codebase размера и сложности рассчитанные метрики для каждой базы кода. Цикломатическая сложность — алгоритм для измерения количества независимых путей часть исходного кода. Было установлено, что общая цикломатическая сложность приложения коррелировать почти 92% к количеству строк кода в приложении. Это означает, что вычисление метрики сложности для codebase может рассказать вам больше о сколько кода, у вас, чем о ее сложности. На рисунке 3 показана корреляция между сложностью и строками кода.

Рисунок 3: Цикломатическая сложность и строк кода

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

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

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

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

Заключение

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

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

Доля этой статьи:

Цитируете эту статью:

Оцените содержание: 
Нет голосов были поданы еще. Скажи свое слово!

Добавить новый комментарий

Обычный текст

  • Теги HTML не разрешены.
  • Адреса электронной почты и адреса страниц включите в ссылки автоматически.
  • Строки и параграфы переносятся автоматически.