Software quality temporal monitoring: Back in time

Software quality temporal monitoring

Let’s continue our exploration: by monitoring software quality with a tool, you should benefit from the big quality concepts without the headaches. As we saw already, we have to navigate through a lot of data, with great detail, coming from several origins.
And that’s not all, you’ll also need to go back in time!

Why use time in quality monitoring

Software quality standards often recommend to check code metrics against thresholds, and more dimensions can be added, like safety-dependent thresholds. There are many metrics, dealing with a lot of categories (complexity, comments, coverage, etc), enough to produce useful dashboards, and relevant alerts.

So with this approach, we are describing the project’s current quality status in great detail, it is like a photograph we can zoom in and out at will.

But you surely guessed we can go further to monitor software quality: temporal monitoring.
Knowing how good a project is today is important of course, but knowing that you are improving or deteriorating is even better, that’s why quality metrics are not only useful on demand, but also need to be produced regularly, following the project’s lifecycle.

In essence, software quality needs regular monitoring: it is not an act, it is a habit.

Going back in time, and in the future

What more can we do now that quality data is available for today, but also yesterday?

  • Evolution tracking
    The first obvious action is to track quality evolution.
    “Is 70% code coverage good?” is not an easy question. If you previously had 20% or 100%, the answer will definitely not be the same, and produce satisfaction or alarm.
    It is important to know if quality objectives are reached, but also how.

  • Trend analysis and prediction
    Going one step further, temporal data can also provide knowledge on probable outcome.
    For example, tracking the code complexity can help detect growing and plateau phases. If we can’t see the growth curve flattening when the project should have reached a certain maturity, then an action must be taken.
    Analyzing the time behavior of quality objectives can help anticipate problems.
  • Goals and Milestones monitoring
    Software project lifecycle is typically split into milestones, each having quality goals.
    Using regular trend analysis with the project’s planned quality can help check if goals for the next milestone are going to be met in time, or at all. It is much more relaxing to work knowing the progress being made towards the objectives.
    Early milestone quality tracking can help avoid a tunnel effect.

See it in action

In a previous post, we presented our analysis of several GitHub open source projects, an ongoing showcase of software quality monitoring.

Software quality temporal monitoring starts from the moment you first rate a project.
Depending on your process, the project is rated for a version or release, each at a specific date, for which the whole rating details are kept (incrementally, or else the stored data would explode!)

For example, if a project is rated each time a patch is issued, you will get a version for each, and be able to check the trend, verify the impact of a given patch, etc.
We can consider two types of project versions:

  • The draft version, which is the latest available version (there can be only one)
    It typically represents the work in progress, and can be updated as teams are working
    Note that in the online showcase there are no drafts, since we only take into account releases available in GitHub.
  • The baseline versions, which are all stored versions (there can be as many as needed).
    They represent a full quality state of the project for a given moment in time.
Navigating baseline versions

Here in the “project portfolio” view you can access:

  • The breakdown of managed projects, in categories
  • Each project’s versions are accessible: you can visit the past in one click

That’s it for now. Now that we have filled the data space and project time, we need the most important part of the software quality monitoring experience: you!

Next time we’ll explore the user side of things.

Further readings


Leave a Comment

Related Posts

Maintain Software Quality Coderskitchen
Andreas Horn

How to maintain software quality?

In my previous blog post “What is software quality and how to measure it?” I have explained what quality is and how we can measure

Software Quality Metrics Coderskitchen
Flavien Huynh

Software quality: From metrics to habits

There is more to software quality than preventing bugs. It also gives us the opportunity to reach better code. From the different levels of quality

Monitoring Software Quality Coderskitchen
Flavien Huynh

Software quality monitoring: Real use case

Let’s continue unfolding the story of software quality monitoring on a real project.In the previous post, we saw that the price of setting up a