Page 75 -

58 Chapter 3 Agile software development

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.

3.1 Agile methods

In the 1980s and early 1990s, there was a widespread view that the best way to
achieve better software was through careful project planning, formalized quality
assurance, the use of analysis and design methods supported by CASE tools, and
controlled and rigorous software development processes. This view came from the
software engineering community that was responsible for developing large, long-
lived software systems such as aerospace and government systems.
This software was developed by large teams working for different companies. Teams
were often geographically dispersed and worked on the software for long periods of
time. An example of this type of software is the control systems for a modern aircraft,
which might take up to 10 years from initial specification to deployment. These plan-
driven approaches involve a significant overhead in planning, designing, and document-
ing the system. This overhead is justified when the work of multiple development teams
has to be coordinated, when the system is a critical system, and when many different
people will be involved in maintaining the software over its lifetime.
However, when this heavyweight, plan-driven development approach is applied
to small and medium-sized business systems, the overhead involved is so large that it
dominates the software development process. More time is spent on how the system
should be developed than on program development and testing. As the system
requirements change, rework is essential and, in principle at least, the specification
and design has to change with the program.
Dissatisfaction with these heavyweight approaches to software engineering led a
number of software developers in the 1990s to propose new ‘agile methods’. These
allowed the development team to focus on the software itself rather than on its design