Table of Contents
“What you cannot measure, you cannot control” is a hackneyed phrase, but there is truth in it. This is also true for software development. In the end, the process of creating software is so multifaceted and at the same time difficult to understand that even minor flaws in the measurement system will inevitably affect the quality of management.
With the modern techniques, such as extreme programming or Scrum, development can be faster, and the presence of new platforms as well as abstracting from the lower levels can help to avoid many mistakes. Nevertheless, quality control should be carried out at the most diverse levels - from the methodological to the technological level. Any control assumes the presence of software development metrics that allow you to assess the achievement of a particular level of quality of a project. In this article, we will consider the most relevant metrics used in the software development process.
Software Development Metrics Classification
So, the metrics that can be useful for your project are divided into two main groups:
- Delivery metrics, that allow you to calculate performance indicators of the workflow.
- Technical metrics, that allow you to calculate the quality indicators of written code.
Let’s consider each of the groups in more detail.
Delivery Metrics
Burndown Chart
This chart shows how many tasks remain before the sprint end on the timeline (and how many of them have already been done). On the vertical axis - the number of tasks, horizontal - time. The goal of the team: to "burn" all the tasks before the deadline draws near.
The graph shows: “an ideal curve” if the tasks were performed by N pieces per day every day; "Actual curve", which shows the actual number of tasks performed on a particular day.
How to use: The manager looks at how much the actual curve differs from the ideal one and corrects the team's actions according to the situation. Theoretically, you can build a “trend line” somewhere in the middle of the sprint based on an actual schedule and see how much the actual completion date is behind the planned deadline. Of course, it’s better to push and meet deadlines.
Velocity Chart
A more “global” software development metric that allows you to evaluate how much the team copes with the plan in each sprint and make a forecast for the future. On the horizontal axis - time, on the vertical - the number of tasks in the sprint. Nearby two columns: the first - the actually completed tasks, the second - the sprint plan.
In order to operate with Velocity, it is necessary that the duration of the sprint and the number of people in the team do not change (as, indeed, the composition of the team).
How to use: This chart is intended to find out how much the actual number of tasks were done in the sprint correlates with the planned one.
Cumulative Flow Chart
It is a consolidated graph that essentially visualizes the state of a kanban board over time. It shows the ratio of tasks with different statuses “planned”, “in work”, “in control”, “done” - at every moment of time. On the horizontal axis - time, on the vertical - the number of tasks.
If we take a specific moment in time, we can see that the lines illustrating different statuses either approach each other or move away. From this we can draw conclusions: if the “plan” line soared up, and the number of completed ones grows at a slow pace, it means that your performers do not have time to cope with the flow of tasks.
How to use: If a “bottleneck” has formed on the graph (highlighted with a circular frame) - this suggests that someone in the process chain slows down the development process, performance of the tasks stuck at particular stage, downtimes are formed. For example, production does not have time to provide a quality control department with products. In this situation, the manager must decide: to increase the number of resources at this stage, increase the productivity of current performers, or reduce the flow of new tasks.
Technical Metrics
These metrics show the quality of the technical part of your project. Using such metrics will allow you to analyze the performance of your product from the inside and understand how significantly the “invisible” part affects the “visible”. After all, if something is wrong with the technical part, the number of errors will increase, the quality of work will decrease, and security along with delivery will suffer. Since the number of such metrics is quite large, we will combine them into three conditional categories.
ATTENTION! Next there will be a lot of technical terms! We have warned you! (but there is also “how to use” available so it’s ok)
Size Metrics
- SLOC (Source Lines of Code) reflects the number of lines of source code. It is worth considering that this software development metric is not always objective - its numerical value depends on many factors, for example, coding style.
Accordingly, getting an accurate project estimate using this metric is quite difficult, yet there are two approaches that help you get the result as close to the truth as possible:
- assessment of the SLOC indicator (for the entire project or its components) by comparing the functional properties with existing analogues.
- assessment of the bottom-up SLOC by the expert method. In accordance with this technique a project is divided into a hierarchical structure of tasks (Work Breakdown Structure, WBS), based on which an expert assessment of the indicator is performed and is summarized for the entire project.
How to use: Quite often this software development metric is used in the early stages of project development to assess the amount of work, the cost of the project and the duration of the implementation.
- LSI - metric that is used to estimate the size of the logical lines of the LSI code (logical source instructions), calculated after normalization (bringing the source code to the proper form) of the listing: eliminating the placement of several instructions on one line, empty lines, clearing comments, formatting, lines of code to initialize data, etc.
How to use: This indicator can serve for a more objective assessment of the volume of the system (an indicator using normalization looks the same as SLOC - the number of lines - not physical, but logical). LSI also has derivatives, for example, the one that is calculated not as the physical number of lines of code in the original programming language, but as the number of instructions in a lower level language (Assembler, MSIL, etc.), which eliminates the need for normalization.
Direct quality of the system does not depend on the use of these software development indicators, however, in a long run experienced developers can roughly predict the volume of the system for a given functional required by the customer. In this case, noticing a deviation from the given indicators, it is worth considering that the system may contain an excessive number of objects, and at an earlier stage, perform code refactoring.
Complexity Metrics
Complexity metrics can be directly used to evaluate and control code quality: cyclomatic complexity, code coherence, depth of inheritance, etc.
Cyclomatic Complexity Number (CCN) metric is one of the oldest software development metrics. It calculates the available code execution paths in a piece of software to determine its complexity. Each execution path includes one conditional construct from the list below, so they are pretty easy to spot in existing source code:
- ?
- case
- elseif
- for
- foreach
- if
- while
In this case, there are no else and default constructs, because in any case, they assume the use of the “if” and “case” constructs that are present in the list.
Each execution path increases complexity by 1, thereby calculating the cyclomatic complexity of the analyzed code fragment.
How to use: The final indicator can reflect the complexity of the control flow of the program and give a signal about the possible presence of a poor-quality code section. Cyclomatic complexity is used simultaneously with other software development metrics, for example, with the metric of the number of operators.
- Cognitive Complexity Metric. This metric is a measure of how difficult it is to understand a unit of code. Unlike cyclomatic complexity, which determines how complex your code will be from a testing perspective, cognitive complexity tells you how complex your code will be to read and understand.
How to use: This software development metric can help you determine which elements in the code are too complicated for a person to understand, and prevent their implementation in the code since it is extremely undesirable and harms the further development and maintenance of the program.
Maintenance Metrics
Metrics of this type show the complexity of the process of supporting and developing program code and, as a rule, are closely related to complexity metrics, but have their own characteristics that reflect the capabilities of system support.
- Halstead Metric - in the framework of this software development metric, basic assessments are made: a program dictionary is compiled; the length of the program, its volume and complexity are determined. It is further proposed to calculate various measures that allow you to evaluate the program code. For example, an expression for calculating the quality of programming, the complexity of understanding a program, the mental cost of creating a program, etc.
How to use: The Halstead metric is for informational purposes only, however, it remains one of the few that allows us to quantify the indicator of system support in the future, while this indicator has a direct correlation with the quality of the product.
And the last (but not least) thing you should remember about software development metrics...
It is better to collect all the qualitative and quantitative indicators right during development process, in order to prevent the occurrence of errors, otherwise you will have to deal with their subsequent analysis and elimination after the fact. However, the main thing is in any case the development team, because if it works effectively and professionally, then the indicators will be at their best.
