Software Quality Attributes

Software quality is a broad and important field of software engineering.

Software quality attributes

Correctness
The software system’s fulfillment of the specifications underlying its development. The
correctness of a software system refers to:
> Agreement of program code with specifications
> Independence of the actual application of the software system.
The correctness of a program becomes especially critical when it is embedded in a complex
software system.

Example 1.1 Let p be the probability that an individual program is correct; then the
probability P of correctness of the software system consisting of n programs is computed as
P = pn .
If n is very large, then p must be nearly 1 in order to allow P to deviate significantly from 0
[Dijkstra 1972b].
Reliability
Reliability of a software system derives from
> Correctness, and
> Availability.
The behavior over time for the fulfillment of a given specification depends on the reliability
of the software system.
Reliability of a software system is defined as the probability that this system fulfills a
function (determined by the specifications) for a specified number of input trials under
specified input conditions in a specified time interval (assuming that hardware and input
are free of errors).
A software system can be seen as reliable if this test produces a low error rate (i.e., the
probability that an error will occur in a specified time interval.)
The error rate depends on the frequency of inputs and on the probability that an individual
input will lead to an error.
User friendliness:
> Adequacy
> Learnability
> Robustness

Adequacy
Factors for the requirement of Adequacy:
1. The input required of the user should be limited to only what is necessary. The software
system should expect information only if it is necessary for the functions that the user
wishes to carry out. The software system should enable flexible data input on the part of
the user and should carry out plausibility checks on the input. In dialog-driven software
systems, we vest particular importance in the uniformity, clarity and simplicity of the
dialogs.
2. The performance offered by the software system should be adapted to the wishes of the
user with the consideration given to extensibility; i.e., the functions should be limited to
these in the specification.
3. The results produced by the software system:
The results that a software system delivers should be output in a clear and well-structured
form and be easy to interpret. The software system should afford the user flexibility with
respect to the scope, the degree of detail, and the form of presentation of the results. Error
messages must be provided in a form that is comprehensible for the user.

Learnability
Learnability of a software system depends on:
> The design of user interfaces
> The clarity and the simplicity of the user instructions (tutorial or user manual).
The user interface should present information as close to reality as possible and permit
efficient utilization of the software’s failures.
The user manual should be structured clearly and simply and be free of all dead weight. It
should explain to the user what the software system should do, how the individual functions
are activated, what relationships exist between functions, and which exceptions might arise
and how they can be corrected. In addition, the user manual should serve as a reference
that supports the user in quickly and comfortably finding the correct answers to questions.

Robustness
Robustness reduces the impact of operational mistakes, erroneous input data, and
hardware errors.
A software system is robust if the consequences of an error in its operation, in the input, or
in the hardware, in relation to a given application, are inversely proportional to the
probability of the occurrence of this error in the given application.
> Frequent errors (e.g. erroneous commands, typing errors) must be handled with
particular care
> Less frequent errors (e.g. power failure) can be handled more laxly, but still must not
lead to irreversible consequences.

Maintainability
Maintainability = suitability for debugging (localization and correction of errors) and for
modification and extension of functionality.
The maintainability of a software system depends on its:
> Readability
> Extensibility
> Testability

Readability
Readability of a software system depends on its:
> Form of representation
> Programming style
> Consistency
> Readability of the implementation programming languages
> Structuredness of the system
> Quality of the documentation
> Tools available for inspection

Extensibility
Extensibility allows required modifications at the appropriate locations to be made without
undesirable side effects.
Extensibility of a software system depends on its:
> Structuredness (modularity) of the software system
> Possibilities that the implementation language provides for this purpose
> Readability (to find the appropriate location) of the code
> Availability of comprehensible program documentation
Testability
Testability: suitability for allowing the programmer to follow program execution (run-time
behavior under given conditions) and for debugging.
The testability of a software system depends on its:
> Modularity
> Structuredness
Modular, well-structured programs prove more suitable for systematic, stepwise testing
than monolithic, unstructured programs.
Testing tools and the possibility of formulating consistency conditions (assertions) in the
source code reduce the testing effort and provide important prerequisites for the extensive,
systematic testing of all system components.

Efficiency
Efficiency: ability of a software system to fulfill its purpose with the best possible
utilization of all necessary resources (time, storage, transmission channels, and
peripherals).
Portability
Portability: the ease with which a software system can be adapted to run on computers
other than the one for which it was designed.
The portability of a software system depends on:
> Degree of hardware independence
> Implementation language
> Extent of exploitation of specialized system functions
> Hardware properties
> Structuredness: System-dependent elements are collected in easily interchangeable
program components.
A software system can be said to be portable if the effort required for porting it proves
significantly less than the effort necessary for a new implementation.

Software crisis
From Wikipedia, the free encyclopedia

Jump to: navigation, search

Software crisis was a term used in the early days of computing science. The term was used to
describe the impact of rapid increases in computer power and the complexity of the problems
which could be tackled. In essence, it refers to the difficulty of writing correct, understandable,
and verifiable computer programs. The roots of the software crisis are complexity, expectations,
and change.

The term "software crisis" was coined by F. L. Bauer at the first NATO Software Engineering
Conference in 1968 at Garmisch, Germany.[1] An early use of the term is in Edsger Dijkstra's
1972 ACM Turing Award Lecture[2]:

The major cause of the software crisis is that the machines have become several orders of
magnitude more powerful! To put it quite bluntly: as long as there were no machines,
programming was no problem at all; when we had a few weak computers, programming became
a mild problem, and now we have gigantic computers, programming has become an equally
gigantic problem.

The causes of the software crisis were linked to the overall complexity of hardware and the
software development process. The crisis manifested itself in several ways:

 Projects running over-budget.

Many of the software problems were caused by increasingly complex hardware. In his essay,
Dijkstra noted that the newer computers in his day "embodied such serious flaws that [he] felt
that with a single stroke the progress of computing science had been retarded by at least ten
years"[2]. He also believed that the influence of hardware on software was too frequently
overlooked.

Various processes and methodologies have been developed over the last few decades to "tame"
the software crisis, with varying degrees of success. However, it is widely agreed that there is no
"silver bullet" ― that is, no single approach which will prevent project overruns and failures in
all cases. In general, software projects which are large, complicated, poorly-specified, and
involve unfamiliar aspects, are still particularly vulnerable to large, unanticipated problems.