Information Technology Reference
In-Depth Information
not stay on the prescribed usage catalogs, even when highly constrained by user
interfaces. The software robustness argument against this concern is one for which
no counter argument can prevail; certified robustness and reliability is valid only for
the profile used in testing.
The operational profile includes the operating environment or system, third-party
application programming interfaces, language-specific run-time libraries, and ex-
ternal data files that the tested software accesses. The state of each of these other
users can determine the software robustness. If an e-mail program cannot access its
database, then it is an environmental problem that the team should incorporate into
the definition of an operational profile.
To specify an operational profile, the software DFSS team must account for more
than just the primary users. The operating system and other applications competing for
resources can cause an application to fail even under gentle uses. Software operating
environments are extremely diverse and complex. For example, the smooth use of
a word processor can elicit failure when the word processor is put in a stressed
operating environment. What if the document gently being edited is marked read-
only by a privileged user? What if the operating system denies additional memory?
What if the document autobackup feature writes to a bad storage sector? All these
aspects of a software environment can cause failures even though the user follows a
prescribed usage profile. Most software applications have multiple users. At the very
least, an application has one primary user and the operating system. Singling out the
end user and proclaiming a user profile that represents only that user is naive. That
user is affected by the operating environment and by other system users. A specified
operational profile should include all users and all operating conditions that can affect
the system under test (Whittaker & Voas, 2000).
18.5.2
Software Environment: A Major Source of Noise
The fundamental problem with trying to correlate code metrics to software quality
such as robustness is that quality is a behavioral characteristic, not a structural one.
A perfect reliable system can suffer from terrible spaghetti logic. Although spaghetti
logic may be difficult to test thoroughly using coverage techniques, and although
it will be hard to debug, it still can be correct. A simple straight-line chunk of
code (without decision points) can be totally unreliable. These inconsistencies make
generalizing code metrics impossible. Consider the Centaur rocket and Ariane 5
problems. Aviation Week and Space Technology announced that the Centaur upper
stage failure was caused by a simple programming error. A constant was set to one-
tenth of its proper value (
1.992476). This tiny miscoding of
a constant caused the rocket failure. Code complexity was not the issue. The Ariane
5 disaster was caused by failing to consider the environment in which a software
component was being reused (Lions, 1996). That is, the complexity or lack thereof
had nothing to do with the resulting software failure.
Although it is true that metrics correlate to characteristics like readability or
maintainability, they do not correlate well to robustness. Therefore, design teams need
complexity metrics with respect to the environment in which the code will reside.
−
0.1992476 instead of
−
Search WWH ::
Custom Search