Метрики качества программного обеспечения [закрываются]

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

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

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

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

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

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

Следует отметить несколько моментов в отношении показателей в процессе разработки программного обеспечения:

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

If you are using Ruby, there are some tools to help you out with metrics ranging from LOCs/Method and Methods/Class Saikuros Cyclomatic complexity.

My boss actually held a presentation on software metric we use at a ruby conference last year, these are the slides.

A interesting tool that brings you a lot of metrics at once is metric_fu. It checks alot of interesting aspects of your code. Stuff that is highly similar, changes a lot, has a lot of branches. All signs your codes could be better :)

I imagine there are lot more tools like this for other languages too.

Об этом есть хорошая ветка от старого Джоэла в группах обсуждения программного обеспечения.

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

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

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

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

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

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

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

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