Consideration of Dynamic Systems Development Method DSDM and eXtreme Programming XP

1
Consideration of Dynamic Systems Development
Method (DSDM) and eXtreme Programming (XP)

• Holistic approaches to software development
  embracing the principled of RAD project
  environment
• Delivering Agile Business Solutions on Time
• How user involvement can work in practice

2
Objectives

• Introduce DSDM
• Discuss benefits and issues
• Identify skills and techniques
• Consider DSDM in relation to management and
  professional issues
• Extend DSDM to consider eXtreme Programming

3
Agile Methods

• DSDM and XP are agile methods
• Other agile methods include Adaptive Software
  Development (ASD), Crystal, Scrum, and Feature
  Driven Development (FDD)
• Agile methods are adaptive rather than predictive
• Unlike other engineering methods, agile methods
  welcome change.
• Agile methods are people oriented rather than
  process oriented. Agile methods assert that no
  processes will ever make up the skill of the
  development team, so the role of the process is
  to support the development team in their work
• All agile methods centre around small iterations

4
Agile Software Development

• Individuals and Interactions over processes and
  tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

5
DSDM

• The Dynamic Systems Development Method (DSDM) is
  a public domain Rapid Application Development
  method which has been developed through capturing
  the experience of a large consortium of vendor
  and user organisations.
• It is now considered to be the UK's de-facto
  standard for RAD.

6
DSDM History

• 1994 DSDM consortium formed
• 1995 DSDM Version 1.0 released
• 1996 DSDM Version 2.0 released
• Late 1997 DSDM Version 3.0 released
• Early 2001 e-DSDM Version 1.0 released
• Autumn 2001 DSDM Version 4 released
• 2002 DSDM Version 4.1 released
• Spring 2003 e-DSDM Version 2.0 released
• Summer 2003 Version 4.2 released
• Autumn 2004 10th Anniversary Conference

7
Development of eXtreme Programming

• Roots of XP lie in the Smalltalk (programming
  language) community
• XP evolved as an informal practice in the early
  1990s
• 1996 formalised into a methodology
• (working on a payroll project for Chrysler which
  went live in 1997)
• 2000 eXtreme Programming Explained is published

8
Software Development Environments

• Initiation
• Development
• Testing
• Live
• Maintenance (often used as a parallel to live)

9
DSDM Focus

• The key to DSDM is to deliver what business needs
  when it needs it.
• Achieved by using the various techniques in the
  framework and flexing requirements.
• The aim is always to address the current and
  imminent needs of the business rather than to
  attack all the perceived possibilities.
• A fundamental assumption of DSDM is that nothing
  is built perfectly first time, but that a usable
  and useful 80 of the proposed system can be
  produced in 20 of the time it would take to
  produce the total solution.

10
eXtreme Programming Focus

• eXtreme programming reference Kent Beck (2000)
• Like DSDM seeks to address problems of software
  development failing to deliver
• Uses development of code as main driver for
  development
• Examines the way we manage
• cost, time, quality and scope
• Incorporates four values
• communication, simplicity, feedback, courage
• Promoting principles of
• rapid feedback, assume simplicity, incremental
  change, embracing change, quality work

11
Software Development

• Many writers argue that software development
  fails to deliver product and fails to deliver
  value
• Failure of software development has huge economic
  and human impact
• Agile methods seek address the issues of failure

12
Why systems fail

• The system fails to meet the business
  requirements for which it was developed. The
  system is either abandoned or expensive adaptive
  maintenance is undertaken.
• There are performance shortcomings in the system,
  which make it inadequate for the users needs.
  Again, it is either abandoned or amended
  incurring extra costs.
• Errors appear in the developed system causing
  unexpected problems. Patches have to be applied
  at extra cost.
• Users reject the imposition of the system, for
  political reasons, lack of involvement in its
  development or lack of commitment to it.
• Systems are initially accepted but over time
  become unmaintainable and so pass into disuse.

13
Risk the Basic Problem

• Beck (2000) argues that the basic problem of
  software development is risk and identifies the
  following examples of risk
• Schedule slips
• Project cancelled
• Systems go sour needs to be replaced after a
  short period in a live environment
• Defect rate put in to production but never used
• Business misunderstood
• Business change
• False feature rich from user and developer
• Staff turnover
• Return to XP addresses these issues later

14
RAD Lifecycle

• Delivers a fully functional system in 90 days,
  give or take 30 days
• Phases
• Requirements Planning
• User Design
• Construction
• Cutover
• Essential components
• JAD,
• Evolutionary Prototyping,
• Tool Support

15
Criteria for RAD success

• Management commitment
• Use of evolutionary prototyping
• User involvement throughout
• Appropriate use of tools
• Use of standards

16
The CASE for RAD

• Reduced development time
• time-boxing
• concurrent development
• evolutionary prototyping
• Lower cost
• reduced development time
• less maintenance
• Higher quality
• more user involvement
• more emphasis on requirements specification
• focus on product

17
The CASE against RAD

• Over-hyped, misunderstood
• Set-up costs often underestimated
• Getting the right people involved
• Need for commitment to the process
• Danger of inappropriate application
• Can reduce quality through lack of rigour

18
DSDM Ethos

• A fundamental assumption of the DSDM approach is
  that nothing is built perfectly first time, but
  that 80 of the solution can be produced in 20
  of the time it would take to produce the total
  solution.
• In traditional development practice, a lot of
  time is spent in getting from the 80 solution to
  the total solution, with the assumption that no
  step ever needs to be revisited. The result is
  either projects that are delivered late and over
  budget or projects that fail to meet the business
  needs since time is not spent reworking the
  requirements.
• DSDM assumes that all previous steps can be
  revisited as part of its iterative approach.
  Therefore, the current step need be completed
  only enough to move to the next step, since it
  can be finished in a later iteration.

19
Benefits of using DSDM

• Using an iterative process based on prototyping,
  DSDM involves the users throughout the project
  life cycle
• Gives the benefits of
• early implementation to business problems
• users more likely to accept ownership of the
  computer system
• risk of building the wrong computer system is
  reduced
• the final system is more likely to meet the
  users real business requirements
• IT professionals and end users become partners
• the users will be better trained, since their
  representatives will define and co-ordinate the
  training required
• implementation is more likely to go smoothly,
  because of the co-operation of all parties
  concerned in development
• empowerment

20
DSDM Organisation
Senior Management Board
Executive Sponsor
Project Steering Committee
Development Project
Project Roles Project Manager Technical
Co-ordinator Visionary
User Management
Team Roles Team Leader Ambassador User Developer,
Scribe, Tester
End Users, including Advisor Users
Operations
21
Traditional methods versus DSDM
18-24
11
87
77
5
4-6
Average time to delivery (in months)
Average project team size
of completed projects rated good to excellent
Using traditional approaches
Using DSDM
Source British Airways IM Department, Newcastle
22
DSDM Principles

• active user involvement is imperative
• DSDM teams must be empowered to make decisions
• focus is on the frequent delivery of products
• need to measure fitness for business purpose
• iterative and incremental development is required
• all changes during development are reversible
• requirements are base lined at a high level
• testing is integrated through the lifecycle
• a collaborative and co-operative approach between
  all stakeholders is essential
• See seminar notes, Stapleton (1997, 2003) and
  DSDM website (www.dsdm.org) for details on
  principles

23
DSDM Process Overview
Feasibility
Business Study
Agree Schedule
Implement
Implementation
Create Functional Prototype
Identify Functional Prototype
Functional Model Iteration
Review Business
Train Users
User Approval User Guidelines
Review Prototype
Identify Design Prototype
Design Build Iteration
Review Design Prototype
Agree Schedule
Create Design Prototype
24
User centred techniques in DSDM

• User analysis
• identify user population for the proposed system
• Usability analysis
• determine characteristics of user interface
• Task modelling
• identify business events (user tasks)
• Task scenario Definition
• identify instances of task execution for a user
• User conceptual modelling (user object modelling)
• provide a map of the system from the users
  perspective
• GUI design
• user interface to support identified tasks
• User interface prototyping
• provide animated view of proposed system

25
Introducing DSDM to an organisation

• Questions to raise in the change of culture
• How are projects currently staffed ?
• What responsibility and authority do project
  managers have ?
• Current environment one of consensus or control ?
• How will people react to change in working
  practices?
• How mobile are staff in an organisation ?
• Can workshops be accommodated ?
• What is the current relationship with users ?

26
Functional Model Iteration

• Produces standard analysis, but also software.
• Cycle
• Identify what is to be produced
• Agree how and when to do it
• Create the product
• Check that it has been produced correctly
• Software aimed at function
• Testing takes place

27
Design and Build Iteration

• Computer system is engineered to a suitably high
  standard
• Major product is a tested SYSTEM
• Includes non-functional requirements
• Cycle
• Identify what is to be produced
• Agree how and when to do it
• Create the product
• Check that it has been produced correctly
• Only agreed parts due to time constraint

28
Implementation

• Cutover from development environment to
  operational environment
• Training of users
• Documentation is completed

29
Difference between traditional development and
DSDM
Time
Functionality
Resources
Fixed
DSDM
Traditional
Vary
Time
Functionality
Resources
30
Critical success factors in DSDM

• acceptance of DSDM philosophy before starting
  work
• the decision making powers of the users and
  developers in the development team
• commitment of senior user management to provide
  significant end-user involvement
• incremental delivery
• easy access by developers to end-users
• the stability of the team
• development team skills
• in tools and business knowledge
• size of the development team
• supportive commercial relationship
• development technology

31
Selecting projects for DSDM

• Care should be taken that the right sort of
  projects are selected.
• DSDM is particularly well-suited to business
  applications but has been used with considerable
  success in engineering system development.

32
Characteristics of systems where DSDM can be used

• Interactive systems, where functionality is
  clearly demonstrable at the user interface
• Systems with a clearly defined user group
• In complex system, systems that allow for the
  complexity to be decomposed or isolated
• Systems that are time constrained
• Systems where requirements can be prioritised
• Systems where the requirements are unclear or
  subject to frequent change

33
Characteristics of systems where care is required
in applying DSDM

• Process control or real time applications
• Requirements that have to be fully specified
  before any code can be written
• Safety critical applications
• Systems delivering re-usable components
• re-use debate correctness versus high
  modularity

34
Inappropriate reasons for DSDM

• Impatience
• "we want the system now and we dont care about
  the rest of the selection criteria".
• Control
• If traditional controls are applied to DSDM, the
  project will probably not succeed in delivering
  quality software to the business when it wants
  it.

35
Potential Risks in using DSDM

• Lack of user involvement
• Excessive time spent on decision making
• Irreversible increments are developed
• Team focus on activity rather than delivery of
  products
• Testing is not integrated throughout the
  lifecycle
• Users allocated to the project are not wanted
  by the organisation
• Users get too involved in the project
• Data structures get too monolithic and inflexible
  due to rapid prototyping

36
Techniques to consider

• Flexibility
• Timeboxing
• MoSCoW Rules
• Prototyping
• Facilitated Workshops

37
Flexibility

• The flexibility of requirements to be satisfied
  has significant impact on the development
  processes and controls, and on acceptance of the
  system.
• A fundamental assumption of DSDM is that nothing
  is built perfectly first time.
• Assumes that a usable and useful 80 of the
  proposed system can be produced in 20 of the
  time it would take to produce the total system.

38
8020 model
Requirements
80
20
Time
39
8020 in more detail

• A fundamental assumption is that nothing is built
  perfectly first time, but that a usable and
  useful 80 of the proposed system can be produced
  in 20 of the time it would take to produce the
  total solution.
• One of the underlying principles of DSDM is that
  fitness for business purpose is the essential
  criterion for the acceptance of deliverables.
• This moves away from the approach of satisfying
  all the "bells and whistles" in a requirements
  specification as this approach often loses sight
  of the fact that the requirements may be
  inaccurate.

40
Timeboxing

• This is a very important aspect of DSDM projects.
  Without effective timeboxing, prototyping teams
  can lose their focus and run out of control.
• Timeboxing works by concentrating on when a
  business objective will be met as opposed to the
  tasks which contribute to its delivery.

41
Component parts of a timebox
Start
Close
Investigate
Consolidate
Refine
Identify and plan
Review
Investigation a quick pass to see whether the
team is taking the right direction Refinement
to build on the comments resulting from the
review at the end of investigation Consolidation
the final part of the timebox to tie up any
loose ends
42
Timeboxing basics

• time between start and end of an activity
• DSDM uses nested timeboxes, giving a series of
  fixed deadlines
• ideally 2 - 6 weeks in length
• objective is to have easiest 80 produced in each
  timebox
• remaining 20 potentially carried forward
  subsequent timeboxes
• focus on the essentials
• helps in estimating and providing resources

43
Key Characteristics of Timebox

• Time available dictates work done
• Review at deadline
• Reaffirm scope
• Prevent drift
• Potential risk
• Loss of functionality
• Failure to meet all objectives

44
MoSCoW Rules
formalised in DSDM version 3 Must have
fundamental to project success Should have
important but project does not rely on Could
have left out without impacting on project
Won't have this time round can be left out this
time
45
Prototyping in DSDM (1)

• Prototypes are necessary in DSDM because
• facilitated workshops define the high-level
  requirements and strategy
• prototypes provide the mechanism through which
  users can ensure that the detail of the
  requirements is correct
• demonstration of a prototype broadens the users'
  awareness of the possibilities and assists them
  in giving feedback to the developers
• speeds up the development process and increases
  confidence that the right solution will be
  delivered.

46
Prototyping in DSDM (2)

• A prototype need not be complete and tested with
  respect to all its related functional and
  non-functional requirements.
• DSDM prototypes are intended to be incremental,
  in other words they evolve.
• Four categories of prototype are recommended
• Business for demonstrating the business processes
  being automated,
• Usability for investigating aspects of the user
  interface that do not affect functionality,
• Performance Capacity for ensuring that the
  system will be able to handle full workloads
  successfully,
• Capability/Technique for trialling a particular
  design approach or proving a concept.

47
Prototype Potential Issues

• Experience shows prototyping is is a potential
  problem area in DSDM
• Lack of control
• Scope creep
• False expectation of completion

48
Facilitated Workshops

• Purpose to produce clear outcomes that have been
  reached by consensus
• Participants
• workshop sponsor
• workshop owner
• facilitator
• participants
• scribes
• observers
• prototypers

49
Advantages of Workshops

• Speed
• Involvement /ownership
• Productivity
• Consensus
• Quality of decisions
• Overall perspective / synergy

50
Types of Workshop
Business Vision Analysis
Acceptance Test Planning
Business Systems Planning
Technical Systems Options
Business Process Design
Information Systems Design
Business Information Systems Benefits
Information Systems Requirements
Definition/Prioritisation
51
Linking DSDM to other methods

• Why look at DSDM in isolation ?
• When not take the best bits of DSDM and combine
  with other methods ?
• Why not use the robustness of more formal methods
  to strengthen DSDM ?
• Why should organisation be constrained by one
  method ?

52
For example merge UML with DSDM
Feasibility
Business Study
Agree Schedule
Implement
Implementation
Create Functional Prototype
Identify Functional Prototype
Review Business
Train Users
Functional Model Iteration
User Approval User Guidelines
Review Prototype
Identify Design Prototype
Design Build Iteration
Review Design Prototype
Agree Schedule
Create Design Prototype
53
XP in more detail

• Next section of lecture examines the principles
  and practices of XP.

54
Addressing Risks in XP

• Schedule slips - short release cycles, release
  highest priority first
• Project cancelled - customer chooses the smallest
  release that makes the most business sense
• Systems go sour - XP creates and maintains a
  comprehensive suite of tests, run and rerun after
  every change to ensure a quality baseline
• Defect rate - test by function by function
  (programmer) and program feature by program
  feature (customer)
• Business misunderstood customer to be an
  integral part of the development team
• Business changes - shortens release cycle
• False feature rich - address highest priority
  tasks
• Staff turnover - give programmers responsibility
  for estimating and completing their own work

55
XP Core Values

• Values necessary for an emergent culture and
  improved productivity
• Communication
• Feedback
• Simplicity
• Courage
• To support and reinforce the core values, XP
  recommends a whole range of planning, testing
  and development practices that can be divided
  into 3 groups
• Programmer practices
• Team practices
• Project practices

56
XP Practices in Projects

• Plan
• Small releases
• Metaphor eg Microsoft use desktop
• Simple design
• Testing
• Refactoring
• Pair Programming
• Collective Ownership
• Continuous iteration
• No overtime
• On-site customer
• Coding standards

57
programmer practices
team practices
project practices
58
XP challenges assumptions

• XP says that analogies between software
  engineering and other engineering are false
• software customers requirements change more
  frequently
• our products can be changed more easily
• the ratio of design costbuild cost is much
  higher
• if we consider coding as design and
  compile-link as build
• the build task is so quick and cheap it should
  be considered instant and free,
• almost all software development is design.

59
XP challenges assumptions

• The design meets known existing requirements, not
  all possible future functionality.
• Beck (2000) If you believe that the future is
  uncertain, and you believe that you can cheaply
  change your mind, then putting in functionality
  on speculation is crazy. Put in what you need
  when you need it.

60
How XP works

• As with RAD and DSDM etc. programmers meet and
  communicate with customers regularly, and the
  software gets released incrementally.
• Programmers always work in pairs (considered more
  productive).

61
Pair Programming

• At first glance seems expensive and wasteful use
  of labour
• Two programmers working together on one programme
  on one machine,
• First programmer writes code,
• Second engages in strategic thinking, suggesting
  better alternatives, correcting mistakes (syntax
  and semantics), identifying unit tests
• After a time pair swap roles
• Pairing is dynamic
• ie people in team move between pairs
• Helps in testing and following standards
• At least two people in organisation will
  understand the code !

62
How XP works

• Testing is the start point, not the end
• For each user story, the customer first writes an
  acceptance test.
• For each unit the programmer writes a set of unit
  tests.
• Then each unit in a story is coded.
• When a unit is ready, its tests are run
  automatically.
• Customers are allowed to suggest improvements.
• Redesigns are common - what they call refactoring
  - and handled easily.

63
The Limits of XP

• Technical limitations
• Programming language - possibly
• Legacy code
• Where rapid change is not facilitated
• Cultural limitations
• Team size big teams can be problematic
• Colocation example in distributed projects
• Situations where users / customers are
  distrustful
• Product development
• Regulated industries
• Competitive tender / fixed price contracts

64
XP and DSDM

• DSDM and XP aim to solve the same problem
  delivering good systems in short timescales
• Argue that they are complementary activity for
  you to think about in seminar
• XP focuses on the act of programming which is
  treated very lightly in DSDM
• DSDM provides a controlling framework into which
  XP can be plugged

65
XP and DSDM
Feasibility
Business Study
Agree Schedule
Implement
Implementation
Create Functional Prototype
Identify Functional Prototype
Review Business
Train Users
Functional Model Iteration
User Approval User Guidelines
Review Prototype
Identify Design Prototype
Design Build Iteration
Review Design Prototype
Agree Schedule
Create Design Prototype
XP focuses on link between FMI and D and BI
66
Agile Professional Issues

• DSDM and XP are not homes for hackers
• Opportunity for practitioner certification
• Developers work in teams whose focus is not only
  on technological problems
• Practitioners are expected to be quality
  conscious and manage their work effectively

67
Quality Issues !

• Agile methods aim to remove the quick and dirty
  image of RAD
• Agile methods address maintainability
• Options
• maintainable from day 1
• maintainable at a late date
• quick fix which will be withdrawn later
• Agile methods develop solution that is fit for
  business purpose
• Testing happens throughout development
• DSDM linked to TickIT by the BSI
• Quality expectations of right first time every
  time need to change

68
Measuring success of Agile methods

• Reduce the number of systems developments which
  fail
• Increase user satisfaction
• Improve productivity of developers
• Get business solutions to live environment in time

69
Conclusion

• DSDM and XP can potentially be great benefits to
  systems development in business
• Great care should be taken in selecting projects
  to make use of DSDM (suitablity matrix)
• DSDM and XP are neither cheap nor easy options
• DSDM and XP both require combination of technical
  and interpersonal skills in both approaches
  people are key