science is as mature as its measurement tools," (Louis Pasteur in Ebert
Dumke, ). Measuring software quality is motivated by at least two reasons:
Risk Management: Software failure has caused more than inconvenience. Software errors have caused human fatalities. The causes have ranged from poorly designed user interfaces to direct programmingerrors. An example of a programming error that led to multiple deaths is discussed in Dr. Leveson's paper. This resulted in requirements for the development of some types of software, particularly and historically for software embedded in medical and other devices that regulate critical infrastructures:"[Engineers who write embedded software] see Java programs stalling for one third of a second to perform garbage collection and update the user interface, and they envision airplanes falling out of the sky.". Inthe United States, within the Federal Aviation Administration (FAA), the Aircraft Certification Service provides software programs, policy, guidance and training, focus on software and Complex Electronic Hardware that has an effect on the airborne product (a “product” is an aircraft, an engine, or a propeller)".
As in any other fields of engineering, an application with good structural software quality costs less to
maintain and is easier to understand and change in response to pressing
business needs. Industry data demonstrate that poor application structural
quality in core business applications (such as Enterprise Resource Planning
(ERP), Customer Relationship Management (CRM) or large transaction processing
systems in financial services) results in cost and schedule overruns and
creates waste in the form of rework (up to 45% of development time in some
organizations ). Moreover, poor structural quality is strongly correlated with
high-impact business disruptions due to corrupted data, application outages,
security breaches, and performance problems. However, the distinction between
measuring and improving software quality in an embedded system (with emphasis
on risk management) and software quality in business software (with emphasis on
cost and maintainability management) is becoming somewhat irrelevant. Embedded
systems now often include a user interface and their designers are as much
concerned with issues affecting usability and user productivity as their
counterparts who focus on business applications. The latter are in turn looking
at ERP or CRM system as a corporate nervous system whose uptime and performance
are vital to the well-being of the enterprise. This convergence is most visible
in mobile computing: a user who accesses an ERP application on their smartphone
is depending on the quality of software across all types of software layers.
types of software now use multi-layered technology stacks and complex
architecture so software quality analysis and measurement have to be managed in
a comprehensive and consistent manner, decoupled from the software's ultimate
purpose or use. In both cases, engineers and management need to be able to make
rational decisions based on measurement and fact-based analysis in adherence to
the precept "In God (we) trust. All others bring data".
((mis-)attributed to W. Edwards Deming and others).
though "quality is a perceptual, conditional and somewhat subjective
attribute and may be understood differently by different people" (as noted
in the article on quality in business), software structural quality
characteristics have been clearly defined by the Consortium for IT Software
Quality (CISQ). Under the guidance of Bill Curtis, co-author of the Capability
Maturity Model framework and CISQ's first Director; and Capers Jones, CISQ's
Distinguished Advisor, CISQ has defined five major desirable characteristics of
a piece of software needed to provide business value. In the House of
Quality model, these are "Whats" that need to be achieved:
An attribute of resiliency and structural solidity. Reliability measures the
level of risk and the likelihood of
potential application failures. It also measures the defects injected due to
modifications made to the software (its “stability” as termed by ISO). The goal
for checking and monitoring Reliability is to reduce and prevent application
downtime, application outages and errors that directly affect users, and
enhance the image of IT and its impact on a company’s business performance.
2. Efficiency: The
source code and software architecture attributes are the elements that ensure high performance once the
application is in run-time mode. Efficiency is especially important for
applications in high execution speed environments such as algorithmic or
transactional processing where performance and scalability are paramount. An
analysis of source code efficiency and scalability provides a clear picture of
the latent business risks and the harm they can cause to customer satisfaction
due to response-time degradation.
3. Security: A measure of the likelihood
of potential security breaches due to poor coding practices and architecture.
This quantifies the risk of encountering critical vulnerabilities that damage
4. Maintainability: Maintainability
includes the notion of adaptability, portability and transferability (from one development team to another). Measuring
and monitoring maintainability is a must for mission-critical applications
where change is driven by tight time-to-market schedules and where it is
important for IT to remain responsive to business-driven changes. It is also
essential to keep maintenance costs under control.
While not a quality attribute per se, the sizing of source code is a software characteristic that obviously impacts
maintainability. Combined with the above quality characteristics, software size
can be used to assess the amount of work produced and to be done by teams, as