What is quality software?

What is quality software? The answer will largely depend on the role of the person you ask. A user will focus on their needs, while someone in charge of maintenance will prefer code that is reliable, readable, and understandable. Some will be happy with a quantitative definition (ex. the number of bugs per 1000 instructions), while others prefer a more qualitative definition (how well it satisfies user needs, the successfulness of the product, etc.).

For more than 30 years, countless researchers have worked to find models that effectively and objectively quantify software quality.

Several models have been noteworthy, including the following:

The McCall Model (1977): McCall's "Quality Triangle" is one of the first published models for quality. Three high-level "perspectives" group together eleven factors of quality that can be measured based on a set of properties. One of the criticisms against this model is the subjectivity of some properties.

The Boehm Model (1978): Boehm and his team were inspired by the McCall model (a three-level hierarchical model), and they expanded the list of measurable quality factors.

http://en.wikipedia.org/wiki/Barry_Boehm http://sunset.usc.edu/Research_Group/barry.html

ISO 9126 (1991): The International Organization for Standardization's ISO 9126 was inspired by these models to define a standard quality model and establish recommendations for measuring its characteristics.

http://en.wikipedia.org/wiki/ISO_9126

However, despite the degree of theoretical maturity, it was difficult to put these models into practice. Software providers are fully aware of the impact of implementing code quality control on the reliability and maintainability of software. However, code quality remains an untapped source of improvements, as opposed to process quality or project management (CMMI, ISO certifications).

A study (2) conducted on nearly 200 software providers highlighted the reasons that discouraged them from establishing development quality procedures. The main reasons mentioned are:

• Setup and monitoring time
• The initial cost
• Lack of support from quality management

The research and development we have conducted with the INSA Lyon and CETIC laboratories is based on the above research, yet it provides specific responses to these problems. Some of the findings from this research are available in a scientific publication, published by ICSSEA (International Conference on Software & Systems Engineering and their Applications) in 2008.

(1) McCall, J. A., Richards, P. K., and Walters, G. F., "Factors in Software Quality", Nat'l Tech. Information Service, no. Vol. 1, 2 and 3, 1977

(2) J.M. Verner, T.T. Moores, A.R. Barret “Software quality: perceptions and practices in Hong Kong”, Achieving quality in software, Chapman & Hall, 1996, p.77-88

[Practice] Derivable internal method called in the constructor

Each article in the Practice category focuses on a bad development practice detected by Kalistick's Cockpit.

Calling a derivable internal method (not final in Java, or virtual in C#) from the class constructor is a risky practice. If the method is overloaded, inconsistencies or even errors may arise.

The intrinsic reasons for these errors are closely related to the object instantiation processes in the C# and Java languages, particularly when executing parent constructors before initializing the fields in the child class.

Example:

MyWindow.java

public class MyWindow
{
public MyWindow()
{
 /* ... */
 buildUI();
}

public void buildUI()
{
 /* ... */
}
}

MyExtendedWindow.java

public class MyExtendedWindow extends MyWindow
{
private MyComponent component;

public MyExtendedWindow()
{
 this.component = new MyComponent();
}

public void buildUI()
{
 super.buildUI();
 component.setWidth(800);
}
}

The buildUI method in the MyWindow class is derivable and called in the constructor for the MyWindow class.

The MyExtendedWindow class extends MyWindow and overloads the buildUI method in order to add processing to these fields.

When instantiating an object in the MyExtendedWindow class, the order of execution will be as follows:

1. Initialize the fields in the MyWindow class (declaration).
2. Execute the constructor for the MyWindow class.
3. Execute the buildUI method in the MyExtendedWindow class (overload).
4. Initialize the fields in the MyExtendedWindow class (declaration).
5. Execute the constructor for the MyExtendedWindow class.

The instantiation will result in a nullity exception (in 3) since the setWidth method in MyComponent is called before the component object is initialized, which will be in 5. Here, the error is obvious. In other circumstances, the symptoms might not be as obvious, making the diagnostic much more time consuming!

Possible corrections:

• Declare the non-derivable or private buildUI method at the MyWindow level so that it can no longer be overloaded.
• Remove the buildUI method from the MyWindow constructor and explicitly call it after the constructor.