Software Engineering I
Instructor:
Reham Adel
Ahram Canadian University- Faculty of Computers and Information
Technology
2
Chapter 3 – Agile Software Development
Chapter 3 Agile Software Development
Topics covered
3
❑ Agile methods
❑ Plan-driven and Agile development
❑ Agile project management
❑ Agile development techniques
Chapter 3 Agile Software Development
Extreme programming (XP)
4
A very influential agile method, developed in the
late 1990s, that introduced a range of agile
development techniques.
Extreme Programming (XP) takes an ‘extreme’
approach to iterative development.
New versions may be built several times per day;
Increments are delivered to customers every 2 weeks;
All tests must be run for every build and the build is
only accepted if tests run successfully.
Chapter 3 Agile Software Development 30/10/2014
The extreme programming release
5
cycle
Chapter 3 Agile Software Development
Extreme programming practices (a)
6
Principle or practice Description
Incremental planning Requirements are recorded on story cards and the stories to be
included in a release are determined by the time available and
their relative priority. The developers break these stories into
development ‘Tasks’.
Small releases The minimal useful set of functionality that provides business
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.
Test-first development An automated unit test framework is used to write tests for a
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.
Chapter 3 Agile Software Development
Extreme programming practices (b)
7
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 islands of 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.
Chapter 3 Agile Software Development
XP and agile principles
8
Incremental development is supported through small, frequent
system releases.
Customer involvement means full-time customer engagement
with the team.
People not process, are supported through pair programming,
collective ownership and a process that avoids long working
hours.
Change supported through regular system releases.
Maintaining simplicity through constant refactoring of code.
Chapter 3 Agile Software Development
Influential XP practices
9
Extreme programming has a technical focus and is not easy
to integrate with management practice in most
organizations.
Therefore, companies adopting agile methods pick and
choose those XP practices that are most appropriate for
their way of working. Sometimes, they are used in
conjunction with a management focused agile method such
as Scrum.
Key practices
User stories for specification;
Refactoring;
Test-first development;
Pair programming.
Chapter 3 Agile Software Development
User stories for requirements
10
In XP, a customer or user is part of the XP team and is
responsible for making decisions on requirements.
User requirements are expressed as user stories or
scenarios.
These are written on cards and the development team
break them down into implementation tasks. These tasks
are the basis of schedule and cost estimates.
The customer chooses the stories for inclusion in the next
release based on their priorities and the schedule
estimates.
Chapter 3 Agile Software Development
A ‘prescribing medication’ story
11
Chapter 3 Agile Software Development
Examples of task cards for prescribing
12
medication
Chapter 3 Agile Software Development
Refactoring
13
Conventional wisdom in software engineering is to
design for change. It is worth spending time and
effort anticipating changes as this reduces costs
later in the life cycle.
XP, however, maintains that this is not worthwhile as
changes cannot be reliably anticipated.
Rather, it proposes constant code improvement
(refactoring) to make changes easier when they
have to be implemented.
Chapter 3 Agile Software Development
Refactoring
14
Programming team look for possible software
improvements and make these improvements even
where there is no immediate need for them.
This improves the understandability of the software
and so reduces the need for documentation.
Changes are easier to make because the code is
well-structured and clear.
However, some changes requires architecture
refactoring and this is much more expensive.
Chapter 3 Agile Software Development
Examples of refactoring
15
Re-organization of a class hierarchy to remove
duplicate code.
Tidying up and renaming attributes and methods to
make them easier to understand.
The replacement of inline code with calls to methods
that have been included in a program library.
Chapter 3 Agile Software Development
Test-first development (TFD)
16
Extreme Programming developed a new approach to
program testing to address the difficulties of testing
without a specification.
Testing is automated and is central to the development
process, and development cannot proceed until all tests
have been successfully executed.
The key features of testing in XP are:
Test-first development.
Incremental test development from scenarios.
User involvement in test development and validation.
Automated tests are used to run all component tests each
time that a new release is built.
Chapter 3 Agile Software Development
Test Driven Development-TDD
17
❑ Test-Driven Development (TDD) is an
enhanced version of TFD designed for use
with incremental development.
❑ Developing automated test cases before
developing the actual code, then building
and integrating small pieces of code, then
executing the component tests, correcting
any issues, and re-factoring the code.
❑ Usually relies on a testing framework such
as selenium.
Test automation
18
Test automation means that tests are written as
executable components before the task is implemented
These testing components should be stand-alone, should
simulate the submission of input to be tested and should
check that the result meets the output specification. An
automated test framework (e.g. selenium) is a system that
makes it easy to write executable tests and submit a set of
tests for execution.
As testing is automated, there is always a set of tests
that can be quickly and easily executed
Whenever any functionality is added to the system, the tests
can be run and problems that the new code has introduced
can be caught immediately.
Chapter 3 Agile Software Development
Test case description for dose checking
19
Chapter 3 Agile Software Development
Test case example
20
Pair programming
21
Pair programming involves programmers working in pairs,
developing code together.
This helps develop common ownership of code and spreads
knowledge across the team.
It serves as an informal review process as each line of code is
looked at by more than 1 person.
It encourages refactoring as the whole team can benefit from
improving the system code.
Chapter 3 Agile Software Development
Pair programming
22
In pair programming, programmers sit together at the
same computer to develop the software.
Pairs are created dynamically so that all team members
work with each other during the development process.
The sharing of knowledge that happens during pair
programming is very important as it reduces the overall
risks to a project when team members leave.
Pair programming is not necessarily inefficient and
there is some evidence that suggests that a pair
working together is more efficient than 2 programmers
working separately.
Chapter 3 Agile Software Development
