Вы находитесь на странице: 1из 36

Chapter 4

An Agile View of Process

Software Engineering: A Practitioner’s Approach

6th Edition
Roger S. Pressman
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
– Working software over comprehensive
– 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
» Manifesto was published in 2001 2
What is Agility?

 Effective response to change

 Effective communication among all
 Drawing the customer onto the team;
 Organizing a team so that it is in control
of the work performed
 Rapid, incremental delivery of software

Principles to achieve agility(The Agile
Manifesto is based on 12 principles)
1. Highest priority -> satisfy the customer
2. Welcome changing requirements
3. Deliver working software frequently
4. Business people and developers must
work together
5. Build projects around motivated
6. Emphasize face-to-face conversation
7. Working software is the primary measure of

8. Agile processes promote sustainable development

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 designs emerge from self-organizing


12. The team tunes and adjusts its behavior to become

more effective 5
Agile Software Process – Three
Key Assumptions
 Difficulty in predicting changes of
requirements and customer priorities
 For many types of s/w, design and
construction are interleaved
 Analysis, design, construction, and
testing are not as predictable as we
might like

Agile Software Process

 An agile process must be adaptable

 It must adapt incrementally
 Requires customer feedback
 An effective catalyst for customer
feedback is an operational prototype

The Politics of Agile
 There is considerable debate about the
benefits and applicability of agile
software development
 No one is against agility. The real
question is:
– What is the best way to achieve it?

Human Factor
 Key point:
– The Process molds to the needs of the people and team, not
the other way around
 A number of 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 9
Agile Process Models

 Extreme Programming (XP) (1996)

 Adaptive Software Development (ASD) (1997)
 Dynamic Systems Development Method
(DSDM) (1995)
 Scrum (1995),
 Crystal
 Feature Driven Development (FDD)
 Agile Modeling (AM)
Extreme Programming (XP) - 1
 The most widely used agile process,
originally proposed by Kent Beck.
 XP uses an object-oriented approach as its
preferred development paradigm
 Defines four (4) framework activities
– Planning
– Design
– Coding
– Testing

Extreme Programming (XP) - 2
simple design spike solutions
CRC cards prototypes
user stories
acceptance test criteria
iteration plan


pair programming

unit test
software increment continuous integration
project velocity computed
acceptance testing
XP - Planning
 Begins with the creation of a set of stories (also
called user stories)
 Each story is written by the customer and is placed
on an index card
 The customer assigns a value (i.e. a priority) to the
 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 13
XP Values
Beck defines a set of five values that establish a
foundation for all work performed as part of XP
Communication (close, informal collaboration
between developers and stakeholders)
Simplicity (developers design for current
needs, not future needs)
Feedback [is derived from three sources: the
implemented software itself(unit tests), the
customer(user stories guide acceptance tests),
and other software team members(iterative
Courage (design for today not tomorrow)
Respect (stakeholders ,team members and
indirectly for the software itself)
XP - Design
 Follows the KIS (keep it simple) principle
 Encourage the use of CRC (class-
responsibility-collaborator) cards
 For difficult design problems, suggests the
creation of “spike solutions”—a design
 Encourages “refactoring”—an iterative
refinement of the internal program design
 Design occurs both before and after coding
XP - Coding
 Recommends the construction of a series of
unit tests for each of the stories before coding
 Encourages “pair programming”
– Mechanism for real-time problem solving and real-
time quality assurance
– Keeps the developers focused on the problem at
 Needs continuous integration with other
portions (stories) of the s/w, which provides a
“smoke testing” environment.
XP - Testing
 Unit tests should be implemented using a
framework to make testing automated. This
encourages a regression testing strategy.
 Integration and validation testing can occur
on a daily basis
 Acceptance tests, also called customer tests,
are specified by the customer and executed
to assess customer visible functionality
 Acceptance tests are derived from user
Industrial XP[“IXP is an organic evolution of XP” ]
XP differs most from the original XP in its greater inclusion of
management, its expanded role for customers, and its upgraded technical
IXP incorporates six new practices
•Readiness acceptance
Does an appropriate development environment exists to support IXP?
Will the team be populated by stakeholders?
Does the organization have a distinct quality program that support
continuous process improvement?
Will the organizational culture support new values of the agile team?
Will the broader project community be populated appropriately?
•Project community (finding the right people for the project team)
•Project chartering (determining whether or not an appropriate business
justification exists to justify the project)
•Test-driven management (used to establish measurable destinations and
criteria for determining when each is reached)
•Retrospectives (specialized technical review focusing on issues, events,
and lessons-learned across a software increment or entire software release)
•Continuous learning (vital part of continuous process improvement)
In addition to the six new practices discussed, IXP modifies a
number of existing XP practices.
XP Issues
•Requirement volatility (can easily lead for scope
creep that causes changes to earlier work design for the
then current needs)
•Conflicting customer needs (many project with many
customers make it hard to assimilate all customer
•Requirements expressed informally (with only user
stories and acceptance tests, its hard to avoid
omissions and inconsistencies)
•Lack of formal design (complex systems may need a
formal architectural design to ensure a product that
exhibits quality and maintainability)
Adaptive Software Development –
a technique for building complex software and systems. The
philosophical underpinnings of ASD focus on human
collaboration & team self organization.

Originally proposed by Jim Highsmith

 ASD — distinguishing features
Mission-driven planning
Component-based focus
Uses “time-boxing”

Timeboxing is a planning technique common in planning

projects (typically for software development), where the
schedule is divided into a number of separate time periods
(timeboxes, normally two to six weeks long), with each part
having its own deliverables, deadline and budget.
Explicit consideration of risks
 Emphasizes collaboration for requirements gathering
 Emphasizes “learning” throughout the process

3 phases- 1.speculation
3. learning

Speculation (project initiated and adaptive cycle planning

takes place)
Collaboration (requires teamwork from a jelled team, joint
application development is preferred requirements gathering
Learning (components implemented and testes, focus groups
provide feedback, formal technical reviews, postmortems)
Dynamic Systems Development
Another Agile software development approach. For
systems which meet tight time constraints

 Promoted by the DSDM Consortium .

 DSDM—distinguishing features

Similar in most respects to XP

Nine guiding principles

Active user involvement is imperative.

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.
(configuration management)
Requirements are baselined at a high level
Testing is integrated throughout the life-cycle.
This method believes in the ‘Pareto Principle’ (80-20 rule)
– 80% of an application can be delivered in 20% of the time
it would take to deliver 100% of the application. Only
enough work should be done in each increment to facilitate
movement to the next increment
An agile approach
A focus on frequent delivery of products
deliver something "good enough" earlier is always
better than to deliver everything "perfectly" in the end
When should we not use it?
Cases where there is no “good enough”
ultra dependable/safety critical software
What else?

DSDM life cycle activities
Feasibility study (establishes requirements and
Business study (establishes functional and information
requirements needed to provide business value, also,
defines the basic application architecture and identifies
the maintainability requirements for the application)
Functional model iteration (produces set of
incremental prototypes to demonstrate functionality to
Design and build iteration (revisits prototypes to
ensure they provide business value for end users, may
occur concurrently with functional model iteration)
Implementation (latest iteration placed in operational
another Agile method. Good for projects that have tight
timelines, changing requirements, and business criticality.
 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
 Currently seems to have overtaken XP as most popular

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

 Is actually a set of example agile processes that have

been proven effective for different types of projects. The
intent is to allow agile teams to select the member of the
Crystal family that is most appropriate for their project and
Feature Driven Development -
practical for object-oriented software engineering
􀂄 Originally proposed by Peter Coad et al
􀂄 FDD Philosophy
Emphasizes collaboration among team members
Manages problem and project complexity using
feature-based decomposition followed integration of
software increments
Technical communication using verbal, graphical, and
textual means.

Software quality encouraged by using incremental

development, design and code inspections, SQA audits,
metric collection, and use of patterns (analysis, design,
FDD 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)
Where an <object> is a person, place or thing.
Examples of features for an ecommerce
application might be:
• Add the product to shopping cart
• Display the technical specs of the product
• Store the shipping info for the customer
􀂄 A features list is created and “plan by
feature” is conducted
􀂄 Design and construction merge in FDD
The emphasis on the definition of features provides the following

• Because features are small blocks of deliverable functionality,

users can describe them more easily; understand how they relate
to one another more readily; and better review them for ambiguity,
error, or omissions.
• Features can be organized into a hierarchical business-related
• Since a feature is the FDD deliverable software increment, the
team develops operational features every two weeks.
• Because features are small, their design and code representations
are easier to inspect effectively.
• Project planning, scheduling, and tracking are driven by the
feature hierarchy, rather than an arbitrarily adopted software
engineering task set.
The FDD approach defines five “collaborating”
framework activities

A feature set groups related features into business-
related categories and is defined as:
<action><-ing> a(n) <object>

For example: Making a product sale is a feature set

that would encompass the features noted earlier and

Lean Software Development (LSD)
Adapted principles of Lean manufacturing to the world of
Lean principles that inspire LSD process are:
Eliminate waste
Build quality in
Create knowledge
Defer commitment
Deliver fast
Respect people
Optimize the whole

Agile Modeling
􀂄 Originally proposed by Scott Ambler
 Practice-based methodology for effective modeling and
documentation of software systems in a light-weight manner.
Suggests a set of agile modeling principles
􀂄 Model with a purpose
􀂄 Use multiple models
􀂄 Travel light - as software engineering proceeds, keep
only those models that will provide long term value and
jettison the rest.
􀂄 Content is more important than representation
􀂄 Know the models and the tools you use to create them
representation – understand the strengths & weaknesses of
each model & the tools that are used to create it.
􀂄 Adapt locally – the modeling approach should be
adapted to the needs of the agile team.
Agile Unified Process(AUP)

Adapt a “serial in the large “and “iterative in the small”

philosophy for building computer based system.
Each AUP iteration addresses
Modeling (UML representations of business and
problem domains)
Implementation (models translated into source code)
Testing (uncover errors and ensure source code meets
Deployment (software increment delivery and
acquiring feedback)
Configuration and project management (change
management, risk management, persistent work product
Environment management (standards, tools,