Is perceived quality applicable for software?

Is perceived quality applicable for CT software?

Beyond performance, what about quality?

Software is becoming increasing important in our lives, both at home and at work. It is a vital tool which accompanies us. But, unlike most of our tools, the concept of perceived quality does not exist for software.

Although a cook is proud of his knives forged by a Japanese craftsman, and a garage mechanic of his torque wrench with its smooth and accurate adjustment, it is much more unusual to see a user praise the merits of his software’s click.

Or, more precisely, he will praise the software based on its results and performance. Very often, in our field, they are based on the speed of the reconstruction time, the image filtering. Even that is not an absolute criterion and can be circumvented by proposing computer architectures capable of compensating certain shortcomings and lack of speed. And, anyway, we will have no information on the intrinsic quality of the product.

This is because a software application is essentially a series of encapsulated instructions which does not reveal its complexity. It is an executable and the code part is well hidden.

The software applications are black boxes

A very common criticism heard is “I don’t like software applications because they are black boxes over which we have no control”.

There are two answers to this. It is something which is unfortunately difficult to avoid for processes which require a high level of optimization, such as reconstruction in particular. And also, the philosophy of a software application is to restrict its user.

The user, perhaps unconsciously, tries to find this reproducibility and methodology.  In fact one of the strengths of a software application is that it provides a methodology and a repeatability without offending individuals or individualities. Using the same tool and the same parameters imposes discipline and a working method. This is what some people regret when talking about a black box, but the advantages largely outweigh the disadvantages.

If we set aside the criticism of the black box, it is however extremely difficult to judge the quality of the proposed applications. We obviously eliminate software with continual bugs which prevent it from running, or even worse, which block the computer. This was common ten years ago but is very rare today.

CT software maintenance, a guarantee of quality

However, even if we can see that it works perfectly well today, who can guarantee that it will work in the coming years?

And who can guarantee that it will work in a future which is moving faster and faster? Because the versions of the OS, graphic board architectures and browsers change more rapidly.

This is where a very important concept for the software comes in, that of maintenance. The revenues from this maintenance allow the software house to follow these changes and offer a software application which is up to date with its environment.

This type of contract being therefore a sign of quality, it indicates that the software house has the desire and the capabilities to guarantee its product’s sustainability. But we must not forget that, in many countries, the software remains assimilated to copyright. This is not a coincidence, because coding is sometimes equivalent to a literary work. Code is written and read, words must always be listened to, and the terminology speaks volumes.

Looking for software engineering

Who says that there are, deep down and encapsulated, long lyrical monologues, erasures, a sometimes approximate grammar and incoherent sentences whose precarious balance is on the point of collapse? No one.

The software’s history is full of magnificent failures where everything was going fine until the software went out of control.

Are we then powerless? Yes and no.

It is clear that access to a source code with a classification of one to five stars by an independent organization is not going to come overnight. During conversations, it is possible to learn about the software engineering methodologies implemented.

“Do you use unit tests? Do you have automatic test systems which run during the night? Do you use agile working methods?”

If these questions seem strange to your listener and if you find that the more the versions progress, the greater the difficulty the software has in processing the volumes of data (which are ever increasing), you can form your own opinion of the quality of the software proposed to you.