a n d

sis Activities Within a Software Process 40 T e s t

A n a l y
exception. For example, high dependability is usually in tension with time to
and in most cases it is better to achieve a reasonably .fugh degree of dependabilit v
a tight schedule than to achieve ultra-high dependability on a much longer sc
although the opposite is tnie in some domains (e.g., certain medical devices),
The quality process should be structured for completeness, timeliness, and ca st.
effectiveness. Completeness means that appropriate activities are planned to d etect each
important class of faults. What the important classes of faults are depends on the
application domain, the organization, and the technologies employed (e.g., memory leaks
are an important class of faults for C++ programs, but seldom for Java program s).
Timeliness means that faults are detected at a point of high leverage, which in practice
almost always means that they are detected as early as possible. Cost-effectiveness
means that, subject to the constraints of completeness and timeliness, one chooses
activities depending on their cost as well as their effectiveness. Cost must be considered
over the whole development cycle and product life, so the dominant factor is likely to
be the cost of repeating an activity through many change cycles.
Activities that one would typically consider as being in the domain of quality assurance or quality improvement, that is, activities whose primary goal is to prevent or
detect faults, intertwine and interact with other activities carried out by members of a
software development team. For example, architectural design of a software system
has an enormous impact on the test and analysis approaches that will he feasible and
on their cost. A precise, relatively formal architectural model may form the basis for
several static analyses of the model itself and of the consistency between the model
and its implementation, while another architecture may be inadequate for static analysis and, if insufficiently precise, of little help even in forming an integration test plan.
The intertwining and mutual impact of quality activities on other development activities suggests that it would be foolish to put off quality activities until late in a project.
The effects run not only from other development activities to quality activities but also
in the other direction. For example, early test planning during requirements engineering typically clarifies and improves requirements specifications. Develpin14...
a test plan
during architectural design may suggest structures and interlaces that not only facilitate
testing earlier in development, but also make key interfaces simpler and more precisely
defined.
There is also another reason for carrying out quality
activities a t the earliest oppor(unity arid for preferring earlier to later activities when either could serve to detect the
same fault: The single best predictor 01 . the cost of repair mg a soft are detect is the
time between its introduction and its detection. A detect introduced in coding is tat
cheaper to repair during unit test than later during integration or system icst, and most
expensive if it is detected bya user of the tickled system. A detect introduced during
.
is relatively cheap to re
requirements engineering (e.g., an ambiguous require',tent)
(thou' itiv
at that stage, but may be hugely expensive it it is only uncov
lb a (Asyut,.