Agile Software Development-Part II

Ian Sommerville,
Software Engineering, 9th Edition
Pearson Education, Addison-Wesley

1
 Extreme programming
 Perhaps best-known and most widely used agile
method.
 Extreme Programming (XP) takes an ‘extreme’
approach to iterative development.
 several new versions of a system may be developed
by different programmers, integrated and tested
frequently.
 Increments are delivered to customers every 2
weeks;

2
 Extreme programming
 All tests must be run for every build (version) and
build is only accepted if tests run successfully, and
this may be the basis for iteration.
 Release deadlines are never slipped.
 if there are development problems, customer is
consulted and functionality is removed from planned
release, if needed.

3
 XP and agile principles

1. Incremental development is supported through

small, frequent releases of system. Requirements are
based on simple customer stories or scenarios that
are used as a basis for deciding what functionality
should be included in a system increment.

2. Customer involvement is supported through

continuous engagement of customer in development
team. Customer representative takes part in
development and is responsible for prioratizing
requirements and defining acceptance tests for
system.
4
 XP and agile principles

3. People, not process, are supported through pair

programming, collective ownership of the system
code, and a sustainable development process that
does not involve excessively long working hours.
4. Change is supported through regular system releases
to customers, test-first development, refactoring to
avoid code degeneration, and continuous integration
of new functionality.
5. Maintaining simplicity is supported by constant
refactoring that improves code quality and by using
simple designs that do not unnecessarily anticipate
future changes to the system.
5
Extreme programming practices (a)
Principle or practice Description
Requirements are recorded on story cards and the stories to be
Incremental planning included in a release are determined by the time available and
their relative priority. The developers break these stories into
development ‘Tasks’. See Figures 3.5 and 3.6.

The minimal useful set of functionality that provides business

Small releases value is developed first. Releases of the system are frequent
and incrementally add functionality to the first release.
Simple design Enough design is carried out to meet the current requirements
and no more.
An automated unit test framework is used to write tests for a
Test-first development new piece of functionality before that functionality itself is
implemented.
Refactoring All developers are expected to refactor the code continuously as
soon as possible code improvements are found. This keeps the
code simple and maintainable.

6
Extreme programming practices (b)
Pair programming Developers work in pairs, checking each other’s work and
providing the support to always do a good job.
Collective ownership The pairs of developers work on all areas of the system, so that
no single expertise develop and all the developers take
responsibility for all of the code. Anyone can change anything.
Continuous integration As soon as the work on a task is complete, it is integrated into
the whole system. After any such integration, all the unit tests in
the system must pass.
Sustainable pace Large amounts of overtime are not considered acceptable as
the net effect is often to reduce code quality and medium term
productivity
On-site customer A representative of the end-user of the system (the customer)
should be available full time for the use of the XP team. In an
extreme programming process, the customer is a member of
the development team and is responsible for bringing system
requirements to the team for implementation.

7
 Requirements scenarios

 In XP, a customer or a user is part of the XP team

and is responsible for making decisions on
requirements by prioritizing them.
 requirements are not specified as lists of required
system functions.
 Rather, the system customer is part of the
development team and discusses scenarios with other
team members.
 They develop a ‘story card’ that captures the
customer needs. .

8
A ‘prescribing medication’ story

9
 Requirements scenarios

 The story cards are main inputs to XP planning

process.
 Once story cards have been developed, development
team breaks these down into tasks and estimates
effort and resources required for implementing each
task.
 This involves discussions with customer to refine
requirements.
 Customer can prioritizes stories for implementation,
choosing stories that are immediately needed to
business support.
10
Examples of task cards for
prescribing medication

11
Extreme programming release cycle

12
 XP and agile principles

 Requirements might change, unimplemented stories

change or may be discarded.
 If changes are required for a system that has already
been delivered, new story cards are developed again,
customer decides whether these changes should have
priority over new functionality.
 During planning, questions that cannot be easily
answered come to light and additional work is
required to explore possible solutions.

13
 XP and agile principles

 Team may carry out some prototyping or trial

development to understand problem and solution.
 In XP terms, this is a ‘spike’, an increment where
no(or minimum) programming is done.
 There may also be ‘spikes’ to design system
architecture or to develop system documentation.
 (A spike is a product-testing method originating from
Extreme Programming that uses simplest possible
program to explore potential solutions.)

14
 XP and agile principles

 A fundamental principle of traditional software

engineering is that you should design for change.
 ie. you should anticipate future changes to software
and design it so that these changes can be easily
implemented for low cost.
 XP, discarded this principle on basis that designing
for change is often wasted effort.

15
 XP and agile principles

 It isn’t worth taking time to add generality to a

program to cope with change.
 The changes anticipated often never comes and
completely different change requests may actually be
made.
 Therefore, XP approach accepts that changes will
happen and restructure software when these changes
actually occur.

16
 XP and change
 A general problem with incremental development is
that it tends to degrade software structure, so
changes to software become harder and harder to
implement.
 During change code might get duplicated, parts of
software are reused in inappropriate ways, and
overall structure degrades as code is added to
system.
 Extreme programming tackles this problem by
constantly refactoring software.

17
 What is software Refactoring?

 Programming team look for possible software

improvements and make these improvements even
where there is no immediate need for them.
 This improves understandability of software and so
reduces need for documentation.
 Changes are easier to make because code is well-
structured and clear always.
 However, changes requires architecture refactoring
might be more expensive.

18
 Example: software Refactoring?

 Re-organization of a class hierarchy to remove

duplicate code.
 Renaming attributes and methods to make them
easier to understand.
 Replacement of inline code with calls to methods
included in a program library.

19
 Example: software Refactoring?
 In practice, many companies that have adopted XP do
not use all of XP practices listed.
 They choose according to their local ways of working.
(Example, some companies find pair programming
helpful;
others prefer to use individual programming and
reviews.
some programmers don’t do refactoring parts they did
not develop.
However, many have adopted an XP variant use small
releases, test-first development, and continuous
integration principles) 20
 Testing in XP

 One important difference between incremental

development and plan-driven development is how
system is tested.
 In incremental development, there is no system
specification that can be used by an external testing
team to develop system tests.
 As a consequence, some approaches to incremental
development have a very informal testing process, in
comparison with plan-driven testing.

21
 Testing in XP

 XP uses an approach to testing that reduces chances

of introducing undiscovered errors into current
version of system.
 XP testing features:
 Test-first development.
 Incremental test development from scenarios.
 User involvement in test development and
validation.
 Automated test are used to run all component
tests each time that a new release is built.

22
 Test-first development
 Writing tests before code is writing to clarify
requirements to be implemented.
 This means you can run test as code is being written
and discover problems during development.

 All previous and new tests are run automatically when

new functionality is added, thus checking that new
functionality has not introduced errors.

23
 Test-first development
 Task implementers have to thoroughly understand
specification so that they can write tests for system.
 Ambiguities and omissions in specification can be
clarified before implementation begins.
 It also avoids problem of ‘test-lag’.
(This may happen when developer of system works at
a faster pace than tester. Implementation gets
further and further ahead of testing and there is a
tendency to skip tests, to maintain development
schedule.)

24
Test case description for dose
checking

25
 Customer involvement

 The role of customer in testing is to help develop

acceptance tests for stories that are to be
implemented in next release of system.
 Customer who is part of team writes tests as
development proceeds. All new code is therefore
validated to ensure that it is what customer needs.
 However, people adopting customer role have limited
time available may cannot work full-time with
development team. They may feel that providing
requirements are enough and may be reluctant to get
involved in testing process.

26
 Customer involvement

 For story in example, acceptance test would involve

scenarios
(a) dose of a drug was changed
(b) a new drug was selected
(c) formulary was used to find a drug.

In practice, a series of acceptance tests rather than a

single test are normally required.

27
 Test automation
 Test automation means tests are written as
executable components before task is implemented
 These testing components should be stand-alone,
should simulate submission of input to be tested
and should check that result meets output
specification.
 An automated test framework (e.g. Junit) is a
system that makes it easy to write executable
tests and submit a set of tests for execution.

28
 Test automation
 As testing is automated, there is always a set of
tests that can be quickly and easily executed
 Whenever any functionality is added to system,
tests can be run and problems that new code has
introduced can be caught immediately.

29
 XP testing difficulties

 Programmers prefer programming to testing and

sometimes might take short cuts when writing tests.
For example, they may write incomplete tests that do
not check for all possible exceptions that may occur.
 Some tests can be very difficult to write
incrementally. For example, in a complex user
interface, it is often difficult to write unit tests for
code that implements the ‘display logic’ and workflow
between screens.
 It is difficult to judge completeness of a set of
tests. Although you may have a lot of system tests,
your test set may not provide complete coverage.
30
 Pair programming
 Another innovative practice introduced in XP is
programmers work in pairs to develop the software.
 They can sit together at same workstation to develop
software.
 However, same pairs do not always program together.
 Pairs are created dynamically so all team members
work with each other during development process.

31
Advantages of pair programming

1. It supports idea of collective ownership and

responsibility for system.
- reflects Weinberg’s (1971) idea of egoless
programming where software is owned by team as a
whole and individuals are not held responsible for
problems with code.
- Team has collective responsibility for resolving
these problems.

32
Advantages of pair programming

2. It acts as an informal review process because each

line of code is looked at by at least two people.
- Reports suggests, code inspections and reviews are
very successful in discovering a high percentage of
software errors.
- However, they are time consuming, typically,
introduce delays into development process.
- Though pair programming is a less formal process,
probably doesn’t find as many errors as code
inspections, it is a much cheaper inspection process
than formal program inspections.
33
Advantages of pair programming

 It helps refactoring, which is a process of software

improvement.
 An individual who performs refactoring may be less
efficient than one who carries code development.
 In pair programming collective ownership are used,
each benefit from other, so they are likely to support
the process.

34
General comments: pair programming

 You might think that pair programming would be less

efficient than individual programming. In a given time,
a pair of developers would produce half as much code
as two individuals working alone.
 There have been various studies of productivity of
pair programmers with mixed results.
 Using student volunteers, (Williams et al., 2000)
found that productivity with pair programming seems
to be equivalent with that of two people working
independently.

35
General comments: pair programming

 The reasons suggested are that pairs discuss

software before development so probably have fewer
false starts and less rework.
 Furthermore, number of errors avoided by informal
inspection is such that less time is spent repairing
bugs discovered during testing process.

36
General comments: pair programming

 However, studies with more experienced

programmers (Arisholm et al., 2007), a significant
loss of productivity has observed compared with two
programmers working alone.
 Nevertheless, sharing of knowledge that happens
during pair programming is very important as it
reduces overall risks to a project when team members
leave.

37