Software Quality

In the context of software engineering, software quality refers to two related but distinct notions that exist wherever quality is defined in a business context:


Software functional quality reflects how well it complies with or conforms to a given design, based on functional requirements or specifications. That attribute can also be described as the fitness for purpose of a piece of software or how it compares to competitors in the marketplace as a worthwhile product. Software structural quality refers to how it meets non-functional requirements that support the delivery of the functional requirements, such as robustness or maintainability, the degree to which the software was produced correctly. Structural quality is evaluated through the analysis of the software inner structure, its source code, in effect how its architecture adheres to sound principles of software architecture. In contrast, functional quality is typically enforced and measured through software testing. Software quality measurement is about quantifying to what extent a software or system rates along each of these five dimensions. An aggregated measure of software quality can be computed through a qualitative or a quantitative scoring scheme or a mix of both and then a weighting system reflecting the priorities. This view of software quality being positioned on a linear continuum has to be supplemented by the analysis of Critical Programming Errors that under specific circumstances can lead to catastrophic outages or performance degradations that make a given system unsuitable for use regardless of rating based on aggregated measurements.

Software Quality Model

Software quality can be defined as 'conformance to requirements' and/or 'fitness of use'. Quality achievements start with a clear definition of what "quality of source code" means to the organization or project. In simple terms all the stakeholders must be well informed of what is expected, what the goals to be achieved are, what the evaluation criteria will be and how they can contribute to achieve the goal.

Procedure
The first step in this direction is to decide the goals and their definitions, for example the following are some of the common goals of any software development / maintenance project.
 

Testability: Ease of testing. Maintainability: The ease of change.

This solves the first level of ambiguity, but the job of defining software quality has just begun. The very next step is to determine what predicates a quality goal. There can be several factors which can influence a particular goal positively or negatively, these factors can be predicates of a goal and these predicates can be as simple as a naming convention to be followed or as complex as a desired "useful" comments percentage per class. In general these predicates are nothing but the "best practices" to be followed and standard "software metrics" which are collected to determine different quality aspects of the software solution.

Types of Software Quality Model

ISO:It is an international standard for the evaluation of software quality. The fundamental objective of this standard is to address some of the well known human biases that can adversely affect the delivery and perception of a software development project. These biases include changing priorities after the start of a project or not having any clear definitions of "success". The standard is divided into four parts:
   

quality model external metrics internal metrics Quality in use metrics.

Boehms:Boehm's quality model improves upon the work of McCall and his colleagues (Boehm, Brown, Kaspar, Lipow & MacCleod, 1978). This quality model loosely retains the factor-measurable property arrangement. However, for Boehm and his colleagues, the prime characteristic of quality is what they define as general utility . For Boehm, general utility is composed of as-is utility, maintainability and portability (Boehm et al., 1976): How well (easily, reliably, efficiently) can I use it [software system] as-is? How easy is it to maintain (understand, modify, and retest)? Can I still use it if I change my environment?

Dromey:Dromey's (1995) model takes a different approach to software quality then the two previously Presented models. For Dromey, a quality model should clearly be based upon the product Perspective of quality:

What must be recognized in any attempt to build a quality model is that software does not directly manifest quality attributes. Instead it exhibits product characteristic that imply or contribute to quality attributes and other characteristics (product defects) that detract from the quality attributes of a product. Most models of software quality fail to deal with the product characteristics side of the problem adequately and they also fail to make the direct links between quality attributes and corresponding product characteristics. According to Dromey (1995), these components all possess intrinsic properties that can beclassified into four categories: Correctness: Evaluates if some basic principles are violated. Internal: Measure how well a component has been deployed according to its intended use. Contextual: Deals with the external influences by and on the use of a component. Descriptive: Measure the descriptiveness of a component (for example, does it have a meaningful name?).

FURPS:The FURPS model originally presented by Robert Grady[1992], then it has been extended by IBM Rational Software [Jacobson et al, 1999, Kruchten, 2000] into FURPS+, where the + indicates such requirements as design constraints, implementation requirements, interface requirements and physical requirements [Jacobson et al, 1999]. In this quality model, has the following five characteristics: 1. Functionality: it may include feature sets, capabilities, and security. 2. Usability: it may include human factors, aesthetics, consistency in the user interface, online and context sensitive help, wizards and agents, user documentation, and training materials. 3. Reliability: it may include frequency and severity of failure, recoverability, predictability, accuracy, and mean time between failures (MTBF). 4. Performance: it imposes conditions on functional requirements such as speed, efficiency, availability, accuracy, throughput, response time, recovery time, and resource usage. 5. Supportability: it may include testability, extensibility, adaptability, maintainability, compatibility, configurability, serviceability, installability, and localizability.

McCall:McCall s Quality Model (also known as the General Electric s Model of 1977) is one of the most known quality models in the software engineering literature. It has been presented by Jim McCall et al. [1977]. This model originates from the US military and is primarily aimed towards the system developers and the system development process [McCall et al, 1977]. Using this model, McCall attempts to bridge the gap between users and developers by focusing on a number of software quality factors that reflect both the users views and the developers priorities [McCall et al, 1977].