Last week, I presented the different levels of maturity in software quality and how the measure of the technical debt can help to progress through these different levels, for a proactive and optimized management of application quality.

On this occasion, I spoke of using technical debt as part of the evaluation of a portfolio of applications, along different axes. After this post, I was thinking about what I could do with a 3D graph of such a portfolio, using the eXcentia’s plugin ‘3D City Model’ (1).

I have already presented this plugin in previous articles: City Model, City Model – New release, Critical City where I explained how to customize the 3D graph using our own formulas, and finally the ABC metric to investigate the metric of the same name. Continue reading →

I suppose that you all know CMMI? This model developed by the Software Engineering Institute provides five levels of maturity in order to measure the quality of IT services, and best practices associated with this scale of five levels, in order to progress through it.

I will not write a whole post on this model, it is not the subject of this article, but I will try to present it simply, as I could summarize it to someone who knows nothing about project management and application development. Continue reading →

We talked in our previous post, about Function Points, a metric usually not known by developers, and if it could be useful to them.

Our answer was rather negative, especially if we consider that such an estimate is performed manually by consultants who rely on a complex process. There are many certifications whose purpose is to validate that a consultant knows these concepts and how to implement them correctly. Continue reading →

The title of this post is transposed from the title of a science fiction novel that you might know: « Do Androids Dream of Electric Sheep? », from the author Philip K. Dick.

This book served as the screenplay for the movie « Blade Runner » by Ridley Scott, in which a detective must find and neutralize androids that nothing can distinguish from humans. Continue reading →

We have seen in the previous post how to initiate a reengineering with SonarQube, starting with a functional redistribution and a re-design of our application.

Now we can go down a little deeper into the code to identify flows of treatments that would be good candidates for a restructuring.  Continue reading →

We defined our reengineering project as rewriting our legacy application in a new language or migrating it to a new technology, as opposed to a refactoring which involves reorganizing the code and to correct certain defects in order to make it more maintainable and reduce its technical debt.

We saw different plans of refactoring more or less ambitious, with the help of SonarQube and the SQALE plugin, from the resolution of the most critical defects to a reduction of the technical debt to a ‘A’ level (SQALE rating ) .

However, for the same Legacy application, is it more interesting to carry out a reengineering project or ‘just’ refactoring?  Continue reading →

A reengineering does not always mean in everyone’s mind, rewriting our Legacy application into another language generally more recent, but it is nevertheless the option we chose.

When it is ‘only’ about reorganizing the code to make it more maintainable, but without porting it onto a new hardware or software platform – such as migrating a Mainframe Cobol application to a Unix architecture – I prefer to talk of a refactoring.

I remind you that this blog has no academic ambitions, so I will not worry about meticulously exact definitions, which lead most often on quadripilotectomic (1) discussions from specialists who have nothing else to do than gossip on any comma. Continue reading →

When it comes to calculating a ROI, I keep it simple: I assume that we will reduce maintenance costs in an amount equal to the reduction of the technical debt.

It is a hypothesis that can be found simplistic and therefore debatable, but our ambition is not in numbers of an absolute and exact precision – it would be pretentious and unrealistic – but to provide to the management the elements that will facilitate its decision.
And I think that managers prefer a simple and clear hypothesis, even if not completely accurate, rather than a complex formula that is not necessarily more realistic. Continue reading →

As explained in the previous post, we have not customized the SonarQube Quality Profile and the SQALE model for our Legacy application, depending on its context, as it should be.

In fact, I use the results ‘out of the box’ in order to illustrate one possible approach to estimate the cost of refactoring this application, and present some ideas to the project team and management, for further actions – or eventually see them rejected.

In other words, it’s the process that interests us more than the results of our application, at least in the context of these articles.

What can we propose, based on the SQALE plugin? Continue reading →

In order to estimate the cost of refactoring our Legacy application, I will use the plugin SQALE of SonarQube, more usually employed to measure the technical debt.

We have already presented this plugin with a PL/SQL Legacy application. So just remember that the SQALE plugin is based on the SQALE quality model, and I will also add, on a method to adapt the model by aligning it with various business objectives, the technology or the contexte of the application. Continue reading →