Software Engineering for Students A Programming Approach

332 Chapter 26 ■ Agile methods and extreme programming
A whiteboard and colored pens are useful for drawing diagrams, such as use case diagrams,
class diagrams, user interface mock-ups and also informal sketches. It is easy to
change the diagram, and it can be viewed collaboratively and discussed by a group of
people. A digital camera is a convenient way of capturing the information on a whiteboard.
Index cards and a large table are useful for designing the class structure of software,
using CRC (Class–Responsibility–Collaborator) modeling (see Chapter 11). The cards
can easily be moved around, changed or removed. Again a digital camera can record the
end product.
Sticky notes can be used with a whiteboard or a large sheet of paper to create diagrams
during design.
Simple tools such as those mentioned are cheap, portable, quick to use, flexible,
assist collaborative working and can be used for communication with the user. On the
other hand, simple tools can be limited, are not amenable to computer-assisted checking
and do not support distributed working.
26.3 ● Extreme programming
This is perhaps the best-known of the agile methods. Its name conveys something dangerous
and foolhardy, but this is far from true. The name instead denotes a radical perspective
which is a contrast to heavyweight methods. Centrally, extreme programming
(XP) recognizes that requirements continually change and the method embraces the
changes, rather than considering them to be disruptive.
Before we look at the values of XP and its full set of techniques, we will explore its
principal approaches.
In XP, the client (or a representative) is always present as a member of the development
team. This person writes use cases, termed stories in XP. (We met these in Chapter 4 on
requirements engineering.) A use case is a small individual function that is required of the
software. It is written in English (or another natural language) in non-technical language
and typically occupies three sentences. It is a statement of a requirement, not a statement
of implementation – what to implement, not how to implement. Thus a use case is a useful
fragment of a requirements specification. For each use case, the developers make an
estimate of how much effort will be needed for implementation. Because use cases are
small, this will typically be a few weeks of person time. A longer estimate means that the
use case is too large and needs to be broken down into smaller use cases. Once a use case
has been priced, and a decision has been taken to implement it, then the client provides
more detailed information about the requirement.
The client specifies acceptance tests for each use case. These are a set of black box
(functional) tests to ascertain whether the use case has been implemented correctly. XP
uses the term acceptance test, rather than functional test, to emphasize their role in
guaranteeing a system that is acceptable to the client. Acceptance tests are automated,
so that they can be run repeatedly easily and objectively. A use case has not been successfully
implemented until all its acceptance tests have been passed. The client is
responsible for checking that tests have ultimately been successful.
Acceptance tests drive the project. They are written before implementation of the
use case is begun. They are repeatedly applied before and while the use case is being