Software engineering provides a means of understanding the structure of the design process, and that

process can be assessed for its effectiveness in interactive system design.

THE SOFTWARE LIFE CYCLE

One of the claims for software development is that it should be considered as an engineering discipline,
in a way similar to how electrical engineering is considered for hardware development.

Activities in the life cycle

A more detailed description of the life cycle activities is depicted in Figure 6.1. The graphical
representation is reminiscent of a waterfall, in which each activity naturally leads into the next. The
analogy of the waterfall is not completely faithful to the real relationship between these activities, but it
provides a good starting point for discussing the logical flow of activity. We describe the activities of this
waterfall model of the software life cycle next.

Requirements specification

In requirements specification, the designer and customer try to capture a description of what the
eventual system will be expected to provide. This is in contrast to determining how the system will
provide the expected services, which is the concern of later activities. Requirements specification
involves eliciting information from the customer about the work environment, or domain, in which the
final product will function. Aspects of the work domain include not only the particular functions that the
software product must perform but also details about the environment in which it must operate.
Requirements specification begins at the start of product development. Though the requirements are
from the customer’s perspective, if they are to be met by the software product they must be formulated
in a language suitable for implementation. Requirements are usually initially expressed in the native
language of the customer.

Architectural design

As we mentioned, the requirements specification concentrates on what the system is supposed to do.
The next activities concentrate on how the system provides the services expected from it. The first
activity is a high-level decomposition of the system into components that can either be brought in from
existing software products or be developed from scratch independently. An architectural design
performs this decomposition.

Detailed design

The architectural design provides a decomposition of the system description that allows for isolated
development of separate components which will later be integrated. For those components that are not
already available for immediate integration, the designer must provide a sufficiently detailed description
so that they may be implemented in some programming language. The detailed design is a refinement
of the component description provided by the architectural design. The behavior implied by the higher-
level description must be preserved in the more detailed description.
Coding and unit testing

The detailed design for a component of the system should be in such a form that it is possible to
implement it in some executable programming language. After coding, the component can be tested to
verify that it performs correctly, according to some test criteria that were determined in earlier activities

Integration and testing

Once enough components have been implemented and individually tested, they must be integrated as
described in the architectural design. Further testing is done to ensure correct behavior and acceptable
use of any shared resources. It is also possible at this time to perform some acceptance testing with the
customers to ensure that the system meets their requirements. It is only after acceptance of the
integrated system that the product is finally released to the customer.

Maintenance

After product release, all work on the system is considered under the category of maintenance, until
such time as a new version of the product demands a total redesign or the product is phased out
entirely. Consequently, the majority of the lifetime of a product is spent in the maintenance activity.
Maintenance involves the correction of errors in the system which are discovered after release and the
revision of the system services to satisfy requirements that were not realized during previous
development.
Validation and verification

Throughout the life cycle, the design must be checked to ensure that it both satisfies the high-level
requirements agreed with the customer and is also complete and internally consistent. These checks are
referred to as validation and verification, respectively. Boehm [36a] provides a useful distinction
between the two, characterizing validation as designing ‘the right thing’ and verification as designing
‘the thing right’.

Verification of a design will most often occur within a single life-cycle activity or between two adjacent
activities. Validation of a design demonstrates that within the various activities the customer’s
requirements are satisfied. Validation is a much more subjective exercise than verification, mainly
because the disparity between the language of the requirements and the language of the design forbids
any objective form of proof.

An important question, which applies to both verification and validation, asks exactly what constitutes a
proof.

Proofs that are for verification of a design can frequently occur within one language or between two
languages which both have a precise mathematical semantics. Time constraints for a design project and
the perceived economic implications of the separate components usually dictate which proofs are
carried out in full formality and which are done only rigorously. As research in this area matures and
automated tools provide assistance for the mechanical aspects of proof, the cost of proof should
decrease.

Validation proofs are much trickier, as they almost always involve a transformation between languages.
Furthermore, the origin of customer requirements arises in the inherent ambiguity of the real world and
not the mathematical world. This precludes the possibility of objective proof, rigorous or formal.
Instead, there will always be a leap from the informal situations of the real world to any formal and
structured development process.

We refer to this inevitable disparity as the formality gap, depicted in Figure 6.3. The formality gap means
that validation will always rely to some extent on subjective means of proof.
Interactive systems and the software life cycle

The life cycle for development we described above presents the process of design in a somewhat
pipeline order. In reality, even for batch-processing systems, the actual design process is iterative, work
in one design activity affecting work in any other activity both before or after it in the life cycle. We can
represent this iterative relationship as in Figure 6.4, but that does not greatly enhance any
understanding of the design process for interactive systems.

The traditional software life cycle suits a principled approach to design; that is, if we know what it is we
want to produce from the beginning, then we can structure our approach to design in order to attain the
goal. We have already mentioned how, in practice, designers do not find out all of the requirements for
a system before they begin. Figure 6.4 depicts how discovery in later activities can be reflected in
iterations back to earlier stages. This is an admission that the requirements capture activity is not
executed properly. The more serious claim we are making here is that all of the requirements for an
interactive system cannot be determined from the start, and there are many convincing arguments to
support this position. The result is that systems must be built and the interaction with users observed
and evaluated in order to determine how to make them more usable.
USABILITY ENGINEERING

In relation to the software life cycle, one of the important features of usability engineering is the
inclusion of a usability specification, forming part of the requirements specification, that concentrates
on features of the user–system interaction which contribute to the usability of the product. Various
attributes of the system are suggested as gauges for testing the usability. For each attribute, six items
are defined to form the usability specification of that attribute. Table 6.1 provides an example of a
usability specification for the design of a control panel for a video cassette recorder (VCR), based on the
technique presented by Whiteside, Bennett and Holtzblatt.
Recoverability refers to the ability to reach a desired goal after recognition of some error in previous
interaction. The recovery procedure can be in either a backward or forward sense. Current VCR design
has resulted in interactive systems that are notoriously difficult to use; the redesign of a VCR provides a
good case study for usability engineering. In designing a new VCR control panel, the designer wants to
take into account how a user might recover from a mistake he discovers while trying to program the VCR
to record some television program in his absence.

One approach that the designer decides to follow is to allow the user the ability to undo the
programming sequence, reverting the state of the VCR to what it was before the programming task
began.

The backward recoverability attribute is defined in terms of a measuring concept, which makes the
abstract attribute more concrete by describing it in terms of the actual product. So in this case, we
realize backward recoverability as the ability to undo an erroneous programming sequence.

The measuring method states how the attribute will be measured, in this case by the number of explicit
user actions required to perform the undo, regardless of where the user is in the programming
sequence.

The now level indicates the value for the measurement with the existing system, whether it is computer
based or not.

The worst case value is the lowest acceptable measurement for the task, providing a clear distinction
between what will be acceptable and what will be unacceptable in the final product.

The planned level is the target for the design and the best case is the level which is agreed to be the best
possible measurement given the current state of development tools and technology.

Measurements such as those promoted by usability engineering are also called usability metrics.
Problems with usability engineering

The major feature of usability engineering is the assertion of explicit usability metrics early on in the
design process which can be used to judge a system once it is delivered.

The problem with usability metrics is that they rely on measurements of very specific user actions in
very specific situations. When the designer knows what the actions and situation will be, then she can
set goals for measured observations. However, at early stages of design, designers do not have this
information.

ITERATIVE DESIGN AND PROTOTYPING

On the technical side, iterative design is described by the use of prototypes, artifacts that simulate or
animate some but not all features of the intended system. There are three main approaches to
prototyping:

Throw-away :

The prototype is built and tested. The design knowledge gained from this exercise is used to build the
final product, but the actual prototype is discarded. Figure 6.5 depicts the procedure in using throw-
away prototypes to arrive at a final requirements specification in order for the rest of the design process
to proceed.
Incremental

The final product is built as separate components, one at a time. There is one overall design for the final
system, but it is partitioned into independent and smaller components. The final product is then
released as a series of products, each subsequent release including one more component. This is
depicted in Figure 6.6.

Evolutionary

Here the prototype is not discarded and serves as the basis for the next iteration of design. In this case,
the actual system is seen as evolving from a very limited initial version to its final release, as depicted in
Figure 6.7. Evolutionary prototyping also fits in well with the modifications which must be made to the
system that arise during the operation and maintenance activity in the life cycle.

On the management side, there are several potential problems, as pointed out by Sommerville [327]:

Time:

Building prototypes takes time and, if it is a throw-away prototype, it can be seen as precious time
taken away from the real design task. So the value of prototyping is only appreciated if it is fast, hence
the use of the term rapid prototyping. However, rapid development and manipulation of a prototype
should not be mistaken for rushed evaluation which might lead to erroneous results and invalidate the
only advantage of using a prototype in the first place.

Planning :

Most project managers do not have the experience necessary for adequately planning and costing a
design process which involves prototyping.

Non-functional features:

Often the most important features of a system will be non-functional ones, such as safety and
reliability, and these are precisely the kinds of features which are sacrificed in developing a prototype.
For evaluating usability features of a prototype, response time – yet another feature often compromised
in a prototype – could be critical to product acceptance. This problem is similar to the technical issue of
prototype realism.
Contracts

The design process is often governed by contractual agreements between customer and designer which
are affected by many of these managerial and technical issues. Prototypes and other implementations
cannot form the basis for a legal contract, and so an iterative design process will still require
documentation which serves as the binding agreement.

Techniques for prototyping

Storyboards

Probably the simplest notion of a prototype is the storyboard, which is a graphical depiction of the
outward appearance of the intended system, without any accompanying system functionality.
Storyboards do not require much in terms of computing power to construct; in fact, they can be mocked
up without the aid of any computing resource.

The origins of storyboards are in the film industry, where a series of panels roughly depicts snapshots
from an intended film sequence in order to get the idea across about the eventual scene. Similarly, for
interactive system design, the storyboards provide snapshots of the interface at particular points in the
interaction.

Evaluating customer or user impressions of the storyboards can determine relatively quickly if the
design is heading in the right direction. Modern graphical drawing packages now make it possible to
create storyboards with the aid of a computer instead of by hand. Though the graphic design achievable
on screen may not be as sophisticated as that possible by a professional graphic designer, it is more
realistic because the final system will have to be displayed on a screen.

Also, it is possible to provide crude but effective animation by automated sequencing through a series of
snapshots. Animation illustrates the dynamic aspects of the intended user–system interaction, which
may not be possible with traditional paper-based storyboards. If not animated, storyboards usually
include annotations and scripts indicating how the interaction will occur.

Limited functionality simulations

More functionality must be built into the prototype to demonstrate the work that the application will
accomplish. Storyboards and animation techniques are not sufficient for this purpose, as they cannot
portray adequately the interactive aspects of the system.

To do this, some portion of the functionality must be simulated by the design team. Programming
support for simulations means a designer can rapidly build graphical and textual interaction objects and
attach some behavior to those objects, which mimics the system’s functionality.