Page 214 -

6.4 Lifecycle models: showing how the activities relate 183

to one another so that the full development process can be seen. The term lifecycle
1
model is used to represent a model that captures a set of activities and how they
are related. Sophisticated models also incorporate a description of when and how
to move from one activity to the next and a description of the deliverables for each
activity. The reason such models are popular is that they allow developers, and par-
ticularly managers, to get an overall view of the development effort so that
progress can be tracked, deliverables specified, resources allocated, targets set, and
SO on.
Existing models have varying levels of sophistication and complexity. For pro-
jects involving only a few experienced developers, a simple process would probably
be adequate. However, for larger systems involving tens or hundreds of developers
with hundreds or thousands of users, a simple process just isn't enough to provide
the management structure and discipline necessary to engineer a usable product.
So something is needed that will provide more formality and more discipline. Note
I
that this does not mean that innovation is lost or that creativity is stifled. It just
means that a structured process is used to provide a more stable framework for
creativity.
However simple or complex it appears, any lifecycle model is a simplified
version of reality. It is intended as an abstraction and, as with any good ab-
straction, only the amount of detail required for the task at hand should be in-
cluded. Any organization wishing to put a lifecycle model into practice will
need to add detail specific to its particular circumstances and culture. For ex-
ample, Microsoft wanted to maintain a small-team culture while also making
possible the development of very large pieces of software. To this end, they
have evolved a process that has been called "synch and stabilize," as described
in Box 6.3.
In the next subsection, we introduce our view of what a lifecycle model for in-
teraction design might look like that incorporates the four activities and the three
key characteristics of the interaction design process discussed above. This will form
the basis of our discussion in Chapters 7 and 8. Depending on the kind of system
being developed, it may not be possible or appropriate to follow this model for
every element of the system, and it is certainly true that more detail would be re-
quired to put the lifecycle into practice in a real project.
Many other lifecycle models have been developed in fields related to interac-
tion design, such as software engineering and HCI, and our model is evolved from
these ideas. To put our interaction design model into context we include here a de-
scription of five lifecycle models, three from software engineering and two from
HCI, and consider how they relate to it.

'Somme~ille (2001) uses the term process model to mean what we call a lifecycle model, and refers to
the waterfall model as the software lifecycle. Pressman (1992) talks about paradigms. In HCI the term
"lifecycle model" is used more widely. For this reason, and because others use "process model" to
represent something that is more detailed than a lifecycle model (e.g., Comer, 1997) we have chosen to
use lifecycle model.