Lecture No.

7
 Agile Software Development
 Software Engineering: A Practitioner’s
Approach
By Roger Pressman

Slides copyright © 1996, 2001, 2005, 2009
by Roger S. Pressman
 Adapting a Process Model
The process should be agile and adaptable to problems. Process
adopted for one project might be significantly different than a process
adopted from another project. (to the problem, the project, the team,
organizational culture). Among the differences are:

the overall flow of activities, actions, and tasks and the

interdependencies among them
the degree to which actions and tasks are defined within each
framework activity
the degree to which work products are identified and required
the manner which quality assurance activities are applied
the manner in which project tracking and control activities are applied
the overall degree of detail and rigor with which the process is
described
the degree to which the customer and other stakeholders are involved
with the project
the level of autonomy given to the software team
the degree to which team organization and roles are prescribed

2
 Prescriptive and Agile Process
Models

The prescriptive process models stress detailed definition,

identification, and application of process activates and tasks.
Intent is to improve system quality, make projects more
manageable, make delivery dates and costs more predictable, and
guide teams of software engineers as they perform the work
required to build a system.
Unfortunately, there have been times when these objectives were
not achieved. If prescriptive models are applied dogmatically and
without adaptation, they can increase the level of bureaucracy.

Agile process models emphasize project “agility” and follow a

set of principles that lead to a more informal approach to software
process. It emphasizes maneuverability and adaptability. It is
particularly useful when Web applications are engineered.

3
 Agile methods
 Dissatisfaction with the overheads involved in
software design methods of the 1980s and 1990s led
to the creation of agile methods. These methods:
 Focus on the code rather than the design
 Are based on an iterative approach to software
development
 Are intended to deliver working software quickly and evolve
this quickly to meet changing requirements.
 The aim of agile methods is to reduce overheads in
the software process (e.g. by limiting documentation)
and to be able to respond quickly to changing
requirements without excessive rework.
The Manifesto for Agile Software
Development
“We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
•Individuals and interactions over processes
and tools
•Working software over comprehensive
documentation
•Customer collaboration over contract
negotiation
•Responding to change over following a plan
That is, while there is value in the items on the
right, we value the items on the left more.”

Kent Beck et al
 What is “Agility”?
 Effective (rapid and adaptive) response to
change
 Effective communication among all
stakeholders
 Drawing the customer onto the team
 Organizing a team so that it is in control
of the work performed
Yielding …
 Rapid, incremental delivery of software
Agility and the Cost of Change
Plan-driven and agile specification
An Agile Process

 Is driven by customer descriptions of

what is required (scenarios)
 Recognizes that plans are short-lived
 Develops software iteratively with a
heavy emphasis on construction
activities
 Delivers multiple ‘software increments’
 Adapts as changes occur
 Agility Principles - I
1. Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in
development. Agile processes harness change for the
customer's competitive advantage.
3. Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to the
shorter timescale.
4. Business people and developers must work together
daily throughout the project.
5. Build projects around motivated individuals. Give them
the environment and support they need, and trust
them to get the job done.
6. The most efficient and effective method of conveying
information to and within a development team is face–
to–face conversation.
 Agility Principles - II
7. Working software is the primary measure of
progress.
8. Agile processes promote sustainable
development. The sponsors, developers, and
users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence and
good design enhances agility.
10. Simplicity – the art of maximizing the amount
of work not done – is essential.
11. The best architectures, requirements, and
designs emerge from self–organizing teams.
12. At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
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.
 Problems with agile methods

 It can be difficult to keep the interest of

customers who are involved in the process.
 Team members may be unsuited to the
intense involvement that characterises agile
methods.
 Prioritizing changes can be difficult where
there are multiple stakeholders.
 Maintaining simplicity requires extra work.
 Contracts may be a problem as with other
approaches to iterative development.
 Agile methods and software maintenance

• Most organizations spend more on maintaining

existing software than they do on new software
development. So, if agile methods are to be
successful, they have to support maintenance as well
as original development.
• Two key issues:
– Are systems that are developed using an agile approach
maintainable, given the 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?
• Problems may arise if original development team
cannot be maintained.
 Plan-driven and agile development
Plan-driven development
 A plan-driven approach to software engineering is based
around separate development stages with the outputs to
be produced at each of these stages planned in
advance.
 Not necessarily waterfall model – plan-driven,
incremental development is possible
 Iteration occurs within activities.
Agile development
 Specification, design, implementation and testing are
inter-leaved and the outputs from the development
process are decided through a process of negotiation
during the software development process.
 Human Factors
 the process molds to the needs of the
people and team, not the other way
around
 key traits must exist among the people
on an agile team and the team itself:
 Competence.
 Common focus.
 Collaboration.
 Decision-making ability.
 Fuzzy problem-solving ability.
 Mutual trust and respect.
 Self-organization.
Extreme Programming (XP)
 The most widely used agile process,
originally proposed by Kent Beck
 XP Planning
 Begins with the creation of “user stories”
 Agile team assesses each story and assigns a
cost
 Stories are grouped to for a deliverable
increment
 A commitment is made on delivery date
 After the first increment “project velocity” is
used to help define subsequent delivery dates
for other increments
 Extreme Programming (XP)
 XP Design
 Follows the KISS principle
 Encourage the use of CRC cards
 For difficult design problems, suggests the creation of “spike
solutions”—a design prototype
 Encourages “refactoring”—an iterative refinement of the
internal program design
 XP Coding
 Recommends the construction of a unit test for a store before
coding commences
 Encourages “pair programming”
 XP Testing
 All unit tests are executed daily
 “Acceptance tests” are defined by the customer and executed
to assess customer visible functionality
A spike solution, or spike, is a
technical investigation. It's a
small experiment to research
the answer to a problem. For
example, a programmer might
not know whether Java throws
an exception on arithmetic
overflow.
Extreme Programming (XP)
User Stories

Who (often called role) and what

Why (optional)

Easy to understand

Short

Indicates measures of success

 User Story Examples (1 of 2)
As a smart phone As a business owner,
user, I want to be able I want to be able to
to install the
application. accept credit cards.

As a smart phone As a business owner,

user, I want to be able I want to be able to
to uninstall the
application. receive confidential
customer feedback.

#pmineflconf2015
@LewisCindy
 User Story Examples (2 of 2)
As a dog owner, I As a dog owner, I
want the dog to don’t want the dog
notify me when it
needs to go out. to bite humans.

As Asa dog owner, I

a dog owner, I
want the dog to sit want the dog to
when asked. come when called.

#pmineflconf2015
@LewisCindy
 Adaptive Software Development

 Originally proposed by Jim Highsmith

 ASD — distinguishing features
 Mission-driven planning
 Component-based focus
 Uses “time-boxing”
 Explicit consideration of risks
 Emphasizes collaboration for requirements
gathering
 Emphasizes “learning” throughout the process
Adaptive Software Development
 Dynamic Systems Development Method

 Promoted by the DSDM Consortium (www.dsdm.org)

 DSDM—distinguishing features
 Similar in most respects to XP and/or ASD
 Nine guiding principles

• Active user involvement is imperative (commanding).

• DSDM teams must be empowered to make decisions.
• The focus is on frequent delivery of products.
• Fitness for business purpose is the essential criterion for
acceptance of deliverables.
• Iterative and incremental development is necessary to
converge on an accurate business solution.
• All changes during development are reversible.
• Requirements are baselined at a high level
• Testing is integrated throughout the life-cycle.
Dynamic Systems Development Method

DSDM Life Cycle (with permission of the DSDM consortium)

 Scrum
 Originally
proposed by Schwaber and Beedle
 Scrum—distinguishing features
 Development work is partitioned into “packets”
 Testing and documentation are on-going as the
product is constructed
 Work occurs in “sprints” and is derived from a
“backlog” of existing requirements
 Meetings are very short and sometimes conducted
without chairs
 “demos” are delivered to the customer with the time-
box allocated
Scrum

 Uses iterative development where each 30-day

iteration is called a “sprint”.

 Multiple self-organizing teams implement

product increments in parallel. Coordination is
done daily at a brief daily meeting called
“scrum”.

31
Scrum
The Scrum process
 Crystal
 Proposed by Cockburn and Highsmith
 Crystal—distinguishing features
 Actually a family of process models that

allow “maneuverability” based on problem

characteristics
 Face-to-face communication is emphasized

 Suggests the use of “reflection workshops”

to review the work habits of the team

Crystal
 A collection of approaches based on the
notion that every project needs a unique set of
policies, conventions and methodologies.
 It is believed that people have a major
influence on software quality, and thus the
quality of projects and processes improves as
the quality of the people involved is improved.
 Productivity increases through better
communication and frequent delivery.

35
 Feature Driven Development

 Originally proposed by Peter Coad et al

 FDD—distinguishing features
 Emphasis is on defining “features”
• a feature “is a client-valued function that
can be implemented in two weeks or less.”
 Uses a feature template
• <action> the <result> <by | for | of | to>
a(n) <object>
 A features list is created and “plan by feature”
is conducted
 Design and construction merge in FDD
Feature Driven Development

Reprinted with permission of Peter Coad

 Agile Modeling (AM)
 Originally proposed by Scott Ambler
 Suggests a set of agile modeling principles
 Model with a purpose
 Use multiple models
 Travel light
 Content is more important than representation
 Know the models and the tools you use to
create them
 Adapt locally
Other Methodologies
for Self Study
Kanban
 Lean Development