Agile Software Development – Part I
Ian Sommerville,
Software Engineering, 9th Edition
Pearson Education, Addison-Wesley
1
Rapid software development
Rapid development and delivery is now often
the most important requirement for software
systems.
Businesses now operate in a globally, rapidly
changing environment.
Response are needed to new opportunities, new
markets, changing economic conditions, emergence of
competing products and services.
Software is part of almost all business operations so
new software should developed quickly to take the
advantage.
2
Rapid software development
Businesses operate in a fast –changing environment
and it is practically impossible to produce a set of
stable software requirements.
Software has to grow quickly to reflect changing
business needs.
3
Rapid software development
Software development processes that plan on completely
specifying the requirements, designing, building, and
testing the system are not suited for 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 delay the delivery of final
software to the customer long after it was originally
specified. 4
Rapid software development
For some types of software, such as safety-critical
systems, where a complete analysis of the system is
essential, a plan-driven approach is the right one.
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 software may effectively get useless.
Therefore, for business systems in particular,
development processes that focus on rapid software
development and delivery are essential.
5
History of Agile Methods
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
- Introduction of fourth generation languages, also in the 1980s
- Later Scrum (Schwaber and Beedle, 2001)
- extreme programming (Beck, 1999; Beck, 2000).
6
Rapid software development
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.
User interfaces are often developed using an Integrated
Development Environment and graphical toolset.
7
Some Common Features of Rapid
software development methods
The processes of specification, design, and
implementation are interleaved.
There is no detailed system specification, and design
documentation is minimized 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.
8
Common Features of Rapid software
development methods
System is developed as a series of versions with
stakeholders involved in version evaluation.
They may propose changes to the software and new
requirements that should be implemented in a later
version of the system.
Eg. System user interfaces are often developed using an
interactive development environment that allows the
interface design to be quickly created by drawing and
placing icons on the interface.
9
Agile Methods
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
customers in short times (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.
10
Traditional methods vs. Agile methods
Dissatisfaction with the expenditures involved in
software design methods of the 1980s and 1990s led
to the creation of agile methods.
Widespread view at that time was best way to
develop better software was through careful project
planning, formalized quality assurance, the use of
analysis and design methods supported by CASE tools,
and controlled software development processes.
11
Traditional methods vs. Agile methods
This view came from software engineering community
that was responsible for developing large, long lived
software systems by large teams (aerospace and
government systems)
This is justifiable 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.
12
Traditional methods vs. Agile methods
However, when this heavyweight, plan-driven
development approach is applied to small and medium-
sized business systems, overhead involved is so large
that it dominates software development process.
More time is spent on how system should be designed
than program development and testing.
As system requirements change, rework is essential
and, in principle at least, specification and design has
to change with program.
13
Traditional methods vs. Agile methods
Some features of Agile methods.
Focus on the code rather than the design and
documentation
Rely on an incremental approach to software
specification, development, and delivery.
They are best suited to application development
where system requirements usually change rapidly
during development process.
14
Traditional methods vs. Agile methods
Agile methods.
Goal is to deliver working software quickly.
Aim of agile methods is to reduce overheads
(indirect cost) in the software process (e.g. by
limiting documentation) and to be able to respond
quickly to changing requirements without excessive
rework.
15
Agile manifesto (policy)
We are discovering better ways of developing software
by doing it and helping others do it. Through this work
we have come to value:
Value Individuals and interactions over processes and tools;
People are required to deliver software. People who need the product
must explain it to the team that develop it. If detailed processes and
sophisticated tools were developed, focus shifted from people to
tools and process )
Focus should be on people and communication between them. The
process and tools should be use for minimum.
16
Agile manifesto (policy)
Working software over comprehensive documentation;
- it is virtually impossible for customers to document computer
system they need. Even if they could do this, it's likely that needs
will change between time requirements were signed off on and
product ships.
- In agile approach build shippable increments of product in short
periods of time with minimum documentations that is only
required for job.
17
Agile manifesto (policy)
Customer collaboration over contract negotiation;
- It is not contracts are needed all collaborations are is informal
- More flexible contracts are required
- Iterative delivery approach will have a better chance of
delivering a product that provides customer with a competitive
advantage than a contract that is signed early in the lifecycle
and is difficult to change.
18
Agile manifesto (policy)
Responding to change over following a plan;
- Many projects that have elaborate project plans with detailed Gantt
charts have failed.
- We make plans so complex and detailed that they're difficult to
modify when changes occur.
- Agile process replaces project plans with release schedules and
burn-down charts that can accommodate change.
- We can still track progress and, in fact, progress is more
transparent than in a typical Waterfall project plan.
(https://www.scrumalliance.org/community/articles/2013/2013-
april/what-does-the-agile-manifesto-mean)
19
Different Agile Methods
Different agile methods are all based around the
notion of incremental development and delivery, they
propose different processes to achieve this.
But share a set of principles, based on the agile
manifesto, and so have much in common.
;
20
The principles of agile methods
Principle Description
Customers should be involved throughout the development
Customer involvement process. Their role is provide and prioritize new system
requirements and to evaluate the iterations of the system.
The software is developed in increments with the customer
Incremental delivery specifying the requirements to be included in each increment.
The skills of the development team should be recognized and
People not process exploited. Team members should be left to develop their own
ways of working without prescriptive processes.
Expect the system requirements to change and so design the
Embrace change system to accommodate these changes.
Focus on simplicity in both the software being developed and
Maintain simplicity in the development process. Wherever possible, actively work
to eliminate complexity from the system.
21
Agile method applicability
Product development where a software company is
developing a small or medium-sized product for sale.
Custom system development within an organization,
where there is a clear commitment from the
customer to become involved in the development
process and where there are not a lot of external
rules and regulations that affect the software.
Because of their focus on small, tightly-integrated
teams, there are problems in scaling agile methods to
large systems.
22
Problems with agile methods
1. It can be difficult to keep interest of customers
who are involved in process.
2. Team members may not have suitable personality for
strong involvement, and therefore not interact well
with other team members.
3. Prioritizing changes can be difficult where there are
multiple stakeholders.
4. Maintaining simplicity requires extra work.
23
Problems with agile methods
5. Many large organizations have spent years so that
processes are defined and followed. It is difficult
for them to move to a working model in which
processes are informal and defined by development
teams.
6. Software requirements document is usually part of
contract between customer and supplier. Because
incremental specification is characteristic in agile
methods, writing contracts for this type of
development may be difficult.
24
Agile methods and software maintenance
Huge amount of software engineering effort goes into
the maintenance and evolution of existing software
systems. So, if agile methods are to be successful,
they have to support maintenance as well as original
development.
25
Agile methods and software maintenance
Two key issues that should be considered when
considering agile methods and maintenance:
Are systems that are developed using an agile
approach maintainable, given emphasis in the
development process of minimizing formal
documentation?
Can agile methods be used effectively for evolving a
system in response to customer change requests?
26
Agile methods and software maintenance
Formal documentation is supposed to describe system
and making it easier for people changing system to
understand.
In practice, however, formal documentation is often
not kept up to date and so does not accurately reflect
the program code.
For this reason, agile methods supporters argue that it
is a waste of time to write this documentation and that
key is to implementing maintainable software and
produce high-quality, readable code.
27
Agile methods and software maintenance
Agile practices therefore emphasize importance of
writing well-structured code and investing effort on
code improvement.
Therefore, lack of documentation should not be a
problem in maintaining systems developed using an agile
approach.
28
Agile methods and software maintenance
However, some people argue for system maintenance
key is the system requirements document, which tells
software engineer what system is supposed to do.
Without such knowledge, it is difficult to assess
impact of proposed system changes.
Many agile methods collect requirements informally
and incrementally and do not create a coherent
requirements document.
In this respect, use of agile methods is likely to make
subsequent system maintenance more difficult and
expensive.
29
Agile methods and software maintenance
However, main difficulty after software is delivered is
to keep customers involved in the process.
Although a customer may be able to justify fulltime
involvement of a representative during system
development, this is less likely during maintenance
where changes are not continuous.
Customer representatives are likely to lose interest in
the system.
30
Agile methods and software maintenance
The other problem that is likely to arise is maintaining
continuity of development team.
Agile methods rely on team members understanding
aspects of system without having to consult
documentation.
If an agile development team is broken up, then this
implicit knowledge is lost and it is difficult for new
team members to build up same understanding about
system and its components. (ie. Problems may arise if
original development team cannot do maintenance
work).
31
Agile methods and software maintenance
Supporters of agile methods promoting its use by
overlooking shortcomings.
Some highlight (DeMarco and Boehm, 2002) both
advantages and disadvantages of agile methods.
They proposed a hybrid approach where agile methods
incorporate some techniques from plan-driven
development may be the best way forward.
32
Plan-driven and agile development
Agile approaches to software development consider
design and implementation to be central activities in
software process.
Other activities, such as requirements elicitation and
testing are incorporate into design and
implementation.
By contrast, plan-driven approach to software
engineering identifies separate stages in software
process with outputs associated with each stage.
The outputs from one stage are used as a basis for
planning the following process activity.
33
Plan-driven and agile specification
34
Plan-driven and agile development
Plan-driven development
In a plan-driven approach, iteration occurs within
activities with formal documents used to
communicate between stages of the process.
For example, requirements will evolve and,
ultimately, a requirements specification will be
produced.
This is then an input to the design and
implementation process.
In agile approach, iteration occurs across
activities. Therefore, requirements and design are
developed together, rather than separately
35
Plan-driven and agile development
A plan-driven software process
- support incremental development and delivery.
- It is feasible to allocate requirements and plan
design and development phase as a series of
increments.
An agile process is not inevitably code-focused and it
may produce some design documentation.
36
Technical, human, organizational issues
Most projects include elements of plan-driven and agile
processes. Deciding on the balance depends on:
Is it important to have a very detailed specification
and design before moving to implementation? If so,
you probably need to use a plan-driven approach.
Is an incremental delivery strategy, where you
deliver software to customers and get rapid
feedback from them, realistic? If so, consider using
agile methods.
37
Technical, human, organizational issues
How large is the system that is being developed?
- Agile methods are most effective when system can
be developed with a small co-located team who can
communicate informally.
- This may not be possible for large systems that
require larger development teams so a plan-driven
approach may have to be used.
38
Technical, human, organizational issues
What type of system is being developed?
• Plan-driven approaches may be required for
systems that require a lot of requirements &
design analysis before implementation (e.g. real-
time system with complex timing requirements,
safety critical systems).
What is the expected system lifetime?
• Long-lifetime systems may require more design
documentation to communicate original intentions
of system developers to support team.
Chapter 3 Agile software development 39
Technical, human, organizational issues
What technologies are available to support system
development?
• Agile methods rely on good tools to keep track of
an evolving code
If you are developing a system using an IDE that
does not have good tools for program visualization
and analysis, then more design documentation may be
required
40
Technical, human, organizational issues
How is the development team organized?
• If development team is distributed or if part of
development is being outsourced, then you may
need to develop design documents to communicate
across the development teams.
41
Technical, human, organizational issues
Are there cultural or organizational issues that
may affect system development?
- Traditional engineering organizations have a
culture of plan-based development, as this is
the norm in engineering.
- This requires extensive design documentation,
rather than informal knowledge used in agile
processes.
42
Technical, human, organizational issues
How good are designers and programmers in
development team?
- It is sometimes argued that agile methods
require higher skill levels than plan-based
approaches in which programmers simply
translate a detailed design into code
- If you have a team with relatively low skill
levels, you may need to use best people to
develop design, with others responsible for
programming.
43
Technical, human, organizational issues
Is the system subject to external regulation?
If a system has to be approved by an external
regulator (e.g. aviation authority approval,
software that is critical to operation of an
aircraft) then you will probably be required to
produce detailed documentation as part of system
safety case.
44
