5 Common Automized Software Quality Metrics (with Pros & Cons)

1. Source Lines of Code (SLOC)

Counting lines of code is probably the most simple method. It mostly indicates the scale of the software and gives an input for project growth and planning. For example, if we get SLOC count once a month, we may sketch a graph of project growth. Of course this is not reliable due to refactoring and design phases but may give a viewpoint.

SLOC may be counted as Source Logical Line of Code (SLLOC) for better info. Logical code lines does not include empty lines, one char brackets and comment lines. You can easily calculate SLLOC using tools like Metrics.

Line of code should not be used for evaluating developer performance. This may cause duplicate, unmaintainable and unprofessional code.

2. Bugs per code_section/module/time_period

Bug tracking is essential for better testing and faster maintainability. If bugs are tracked, bugs per code section, module or specific time period (day, week, month etc.) may be calculated easily by reporting tools (e.g. Mantis). If this value is obtained, bug causes may be noticed and intervened early.
Bug count may be used as one of the inputs of evaluating developer performance, but attention must be paid. If it is most important evaluation method, software developers and testers may become enemies. In a productive company, all employees must be coherent with each other.

For better evaluation, bugs may be classified as low, medium, high etc. for weighting, because their importance and resolving costs are not the same.

3. Code Coverage

Code coverage states the degree to which the source code of a program has been tested. Automaticity of code coverage calculation is a plus. There are so many tools which perform that operation (e.g. Cobertura).

Code coverage does not represent the whole quality of unit tests, but may give some info about test coverage. It may be used as a software metric together with a few other test metrics. Also unit test codes, integration test scenarios and results should be reviewed frequently.

4. Design/Development Constraints

There are so many design constraints and principles for software development. Some of them are:

  • Class/method length,
  • Number of methods/attributes in a class,
  • Method/constructor parameter counts,
  • Magical number, string usage in code files,
  • Comment lines percentage etc.

These are important for code maintainability and readability. Development teams may choose a few (or all) of those metrics and follow them with automized tools (like maven pmd plugin). This will raise the quality of produced software.

5. Cyclomatic Complexity

We separated cyclomatic complexity from other design/development constraints because its concept is a bit different. Cyclomatic complexity is about the detailed implementation and code execution. It also may be calculated automatically with tools like pmd.

It is calculated as ‘the count of the number of linearly independent paths through a source code section’. For example, if there are a path diagram of a source code section as below:

Cyclomatic Complexity = E(edges) – N(nodes) + 2P (exit nodes) So, Cyc.Cmp. = 8 – 7 + 2*1 = 3
You can also see that there are 3 different paths from leftmost node to rightmost node. This value can be calculated especially for methods, using the whole method source as the execution path. Some upper limit numbers (6, 8 or 10 etc.) may be defined according to the project type.
Only one metric does not detect the quality of your whole project or solve everything. If you use more metrics, you will have more viewpoints about the quality of your project.

Reference: 5 Common Automized Software Quality Metrics (with Pros & Cons) from our NCG partner Cagdas Basaraner at the CodeBuild blog.

Related Whitepaper:

Best Practices for Secure Software Development

Best practices for all organizations that would like to produce more secure applications!

As part of the software development process, security professionals must make choices about where to invest their budget and staff resources to ensure that homegrown applications are as secure as possible. ESG research found organizations that are considered security leaders tend to make different choices than other firms.

Get it Now!  

  • larry

    Very well explained the possible metrics for software quality with their advantages and provided the option where to consider a particular method and where it will not be suited. Thanks for sharing!!



.NET Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use
All trademarks and registered trademarks appearing on .NET Code Geeks are the property of their respective owners.
.NET is a trademark or registered trademark of Microsoft Corporation in the United States and other countries.
.NET Code Geeks is not connected to Microsoft Corporation and is not sponsored by Microsoft Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close
Get tutored by the Geeks! JCG Academy is a fact... Join Now
Hello. Add your message here.