Part 1 Introduction to Software EngineeringSoftware Engineering

Chapter 3: Agile software development

The objective of this chapter is to introduce you to agile software
development methods. When you have read the chapter, you will:
■ understand the rationale for agile software development methods,
the agile manifesto, and the differences between agile and plan-
driven development;
■ know the key practices in extreme programming and how these
relate to the general principles of agile methods;
■ understand the Scrum approach to agile project management;
■ be aware of the issues and problems of scaling agile development
methods to the development of large software systems.

3.1 Agile methods
3.2 Plan-driven and agile development
3.3 Extreme programming
3.4 Agile project management
3.5 Scaling agile methods

Businesses now operate in a global, rapidly changing environment. They have to
respond to new opportunities and markets, changing economic conditions, and the
emergence of competing products and services. Software is part of almost all busi-
ness operations so new software is developed quickly to take advantage of new
opportunities and to respond to competitive pressure. Rapid development and deliv-
ery is therefore now often the most critical requirement for software systems. In fact,
many businesses are willing to trade off software quality and compromise on
requirements to achieve faster deployment of the software that they need.
Because these businesses are operating in a changing environment, it is often prac-
tically impossible to derive a complete set of stable software requirements. The initial
requirements inevitably change because customers find it impossible to predict how a
system will affect working practices, how it will interact with other systems, and what
user operations should be automated. It may only be after a system has been delivered
and users gain experience with it that the real requirements become clear. Even then,
the requirements are likely to change quickly and unpredictably due to external fac-
tors. The software may then be out of date when it is delivered.
Software development processes that plan on completely specifying the requirements
and then designing, building, and testing the system are not geared to rapid software
development. As the requirements change or as requirements problems are discovered,
the system design or implementation has to be reworked and retested. As a consequence,
a conventional waterfall or specification-based process is usually prolonged and the final
software is delivered to the customer long after it was originally specified.
For some types of software, such as safety-critical control systems, where a com-
plete analysis of the system is essential, a plan-driven approach is the right one.
However, in a fast-moving business environment, this can cause real problems. By
the time the software is available for use, the original reason for its procurement may
have changed so radically that the software is effectively useless. Therefore, for busi-
ness systems in particular, development processes that focus on rapid software
development and delivery are essential.
The need for rapid system development and processes that can handle changing
requirements has been recognized for some time. IBM introduced incremental
development in the 1980s (Mills et al., 1980). The introduction of so-called fourth-
generation languages, also in the 1980s, supported the idea of quickly developing
and delivering software (Martin, 1981). However, the notion really took off in the
late 1990s with the development of the notion of agile approaches such as DSDM
(Stapleton, 1997), Scrum (Schwaber and Beedle, 2001), and extreme programming
(Beck, 1999; Beck, 2000).
Rapid software development processes are designed to produce useful software
quickly. The software is not developed as a single unit but as a series of increments, with
each increment including new system functionality. Although there are many
approaches to rapid software development, they share some fundamental characteristics:
The processes of specification, design, and implementation are interleaved.
There is no detailed system specification, and design documentation is mini-
mized or generated automatically by the programming environment used to implement the system. The user requirements document only defines the most
important characteristics of the system.
2. The system is developed in a series of versions. End-users and other system
stakeholders are involved in specifying and evaluating each version. They may
propose changes to the software and new requirements that should be imple-
mented in a later version of the system.
3. System user interfaces are often developed using an interactive development
system that allows the interface design to be quickly created by drawing and plac-
ing icons on the interface. The system may then generate a web-based interface for
a browser or an interface for a specific platform such as Microsoft Windows.
Agile methods are incremental development methods in which the increments are
small and, typically, new releases of the system are created and made available to cus-
tomers every two or three weeks. They involve customers in the development process
to get rapid feedback on changing requirements. They minimize documentation by
using informal communications rather than formal meetings with written documents.

Leave a Reply

Your email address will not be published. Required fields are marked *