We have exposed a nice framework in previous posts: raw data produce metrics and indicators, and a rating model evaluates quality for each project component.
This can become an involved task, and if we remember our prize is to achieve quality without additional workload, we are moving away from it!
Let’s see what winning as a team means when software quality (SQ) is done right.
Winning alone is hard
Winning alone can be hard, and extremely rewarding too.
But speaking of Software Quality, who can single handedly manage a whole project and fulfill every stakeholder’s quality expectations?
Even with the help of a rating model as previously described, you would need to:
- Retrieve: Gather results of source code checkers or testing tools
- Making sure they all apply on the exact same revision of the code,
- Verifying they use the exact same data model to produce results,
- Unifying all these data in a common format
- Rate: Compute indicators based on metrics, ratios, thresholds all depending on conditions
Rating a function or a class is not done the same way. - Analyze: Parsing the rating results, look for code components with bad results, and decide if it is normal or not.
This is not as easy, especially if you are not the one responsible for the component, and you don’t know its context or history. - Alert: Finally, produce a workable list of actions to take in order to eventually reach the fabled quality objectives! Phew!
And remember you’re working against time: it won’t be long until the code has changed again, the tests suites have re-run, and you need to produce a quality report for tomorrow morning!
In these conditions, doing quality in isolation can become tedious, ungratifying and should not be the work of a single person.
Software quality supports the team
First, SQ is not the responsibility of just one person.
The project manager should not be the one checking quality to ask team members to focus on a specific issue.
And quality responsibility should not be restricted to the development team either.
The trick is to give each stakeholder (managers, testers, developers, designers) a way to view the project through the correct angle. It is still the same project, metrics and indicators, but there are several ways to look at it, using explorations methods relevant to what we need.
It might still sound like a lot of work to decide what quality attribute we need to study, and then sort through the data to analyze this attribute.
The role-based aspect of the rating model is key for such an approach, because much of the work has been done beforehand:
- Identifying the quality attributes,
- Specifying how to compute them,
- Deciding who they are relevant to
We are freed of the tedious and repetitive thinking. It is done in advance, and specified inside the rating model.
That way, each team member can focus on how his work impacts quality, with an adapted view of the project.
Winning as a team means software quality is a shared responsibility.
Winning as a team is great
Still, have we painted ourselves into a corner, surrounded by a multitude of tasks unrelated to actual coding?
Remember, the objective was to help us produce better code, not produce quality reports, even good ones!
The answer is not far.
As you might have anticipated, we haven’t introduced concepts such as metrics, indicators, models and roles just for the fun of it!
If this preliminary work has been done properly, all we need is to transform it into a deterministic and repeatable process.
Yes, we just have to code it 🙂
And it is all very logical from now on:
- Retrieve: We know what tools produce the raw data we need.
It’s then a matter of reading data and store it. - Rate: Knowing the exact indicators and metrics definitions.
We can develop a rating procedure for that. - Analyze: We know the roles and their quality need
It’s easy to compute them and provide them for easy analysis. - Alert: It’s (kind of) fun to build an algorithm capable of detecting unwanted situations, and pointing to the cause.
What happened here? We have automated the SQ assessment operation, and made it produce results each stakeholder can work with and decide upon.
And we won’t have to sweat on finding the raw data, remembering the indicators list, and how to compute them either.
And the best part is that “producing a quality report for tomorrow” is now one click away.
For example, you won’t have to wonder what definition of the cyclomatic complexity you should use, and how to compute it on each function of your code!
We are having our quality cake every day, and eat it too!
Or in other words, software quality has become part of the process.
