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