Показатели качества программного обеспечения

Question

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

Есть ли измерение, чтобы ответить на эти вопросы:

• Насколько легко изменить/улучшить программное обеспечение, надежность
• Если это общий/общий достаточно куска программного обеспечения, как для повторного использования является его
• Сколько дефекты были связаны с кодом
• ли это необходимо было переработан/перекодировано
• Как долго этот код был вокруг
• Как разработчикам нравится, как код разработан и реализован

Похоже, что большинство из них нужно будет тесно связать с инструментом CM и отчета об ошибках.

Answer 1

Существует хороший thread из старого Joel on Software Discussion group об этом.

Answer 2

Я знаю, что некоторые программы статистики SVN предоставляют обзор по измененным строкам на каждый отправитель. Если у вас есть система отслеживания ошибок и люди, исправляющие ошибки, добавляющие функции и т. Д., Указывая номер их фиксации, когда ошибка исправлена, вы можете рассчитать, сколько строк повлияло на каждый запрос об ошибке/новой функции. Это может дать вам измерение изменчивости.

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

Answer 3

Вы можете сделать это в экономичном пути или в путь программиста.

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

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

Answer 4

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

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

Например, вы можете использовать static code analysis tools для измерения синтаксического качества вашего кода и получения некоторых показателей из этого.

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

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

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

Несколько вещей, чтобы отметить о метриках в процессе программного обеспечения, хотя:

1. Если вы не делаете их хорошо, показатели могут оказаться больше вреда, чем пользы.
2. Метрики трудно преуспеть.
3. Вам следует проявлять осторожность при использовании показателей, чтобы оценить индивидуальную производительность или предлагать бонусные схемы. Как только вы сделаете это, каждый попытается обмануть систему, и ваши показатели окажутся бесполезными.

Answer 5

Если вы используете Ruby, есть некоторые инструменты, чтобы помочь вам с показателями в пределах от Locs/методы и сложностей Методов/Класс Saikuros цикломатических.

Мой босс на самом деле провел презентацию на программное обеспечение метрики мы используем на рубинового конференции в прошлом году, these are the slides.

интересный инструмент, который приносит вам много метрик на один раз metric_fu. Он проверяет много интересных аспектов вашего кода. Материал, который очень похож, сильно меняется, имеет много филиалов. Все признаки ваших кодов могут быть лучше :)

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

Answer 6

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

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

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

Answer 7

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

1. Поддержание работоспособности: Вы упомянули о том, как легко изменить/проверить код или повторно использовать код. Они связаны с возможностью проверки и повторного использования аксессуаров, которые считаются ключевыми характеристиками качества программного обеспечения. Таким образом, вы можете измерить ремонтопригодность в зависимости от тестируемости (охват тестового тестирования) и повторного использования (индекс когезионности кода).
2. Дефекты: Дефекты сами по себе не могут быть хорошей идеей для измерения. Однако, если вы можете моделировать плотность дефектов, это может дать вам хорошую картину.