Software Development Process Models (II)

1

• Software Development Process Models (II)
• Agile Methodologies
• Extreme Programming

2
Agile Methodologies

• Agile methods are a family of software
  development processes for teams facing
  unpredictable or rapidly changing requirements.
• Extreme Programming (XP)
• Agile Modeling
• Adaptive Software Development (ASD)
• Crystal Clear and Other Crystal Methodologies
• Dynamic Systems Development Method (DSDM)
• Feature Driven Development
• Lean software development
• Agile Unified Process (AUP)
• (For more detailed information, see The Agile
  Alliance).

3
Agile Methodologies (contd)

• Reject the notion that we should design for
  future change
• dont borrow trouble
• 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
• Seductive, but
• Beware it is not yet widely accepted in
  industry, and its own proponents admit that it is
  not always a good choice

4
Agile Methodologies (contd)

• Agile methods emphasize real-time communication,
  preferably face-to-face, over written documents.
• Team include all the people necessary to finish
  software
• programmers and their customers, testers,
  interaction designers, technical writers, and
  managers.
• Most agile methods share iterative development's
  emphasis on building releasable software in short
  time periods.
• Agile methods differ from iterative methods
• time period is measured in weeks rather than
  months
• treat their time period as strict time box.
• work is performed in a highly collaborative
  manner.

5
Agile or Plan driven?
Senior developers High requirements change
Small number of developers Culture that thrives
on chaos
Junior developers Low requirements change Large
number of developers Culture that demands order
Agile home ground
Plan-driven home ground
6

• Customer involvement
• Incremental delivery
• People not process
• Embrace change
• Maintain simplicity

7
12 principles of Agile

1. "The 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 time scale.
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.

8
12 principles of Agile

1. Working software is the primary measure of
   progress.
2. Agile processes promote sustainable development.
   The sponsors, developers, and users should be
   able to maintain a constant pace indefinitely.
3. Continuous attention to technical excellence and
   good design enhances agility.
4. Simplicity the art of maximizing the amount of
   work not done is essential.
5. The best architectures, requirements, and designs
   emerge from self-organizing teams.
6. At regular intervals, the team reflects on how to
   become more effective, then tunes and adjusts its
   behavior accordingly. "

9
Extreme Programming (XP)

• The most popular agile software development
  methodology.
• Places a higher value on adaptability than on
  predictability
• as all the agile methodologies do
• Target Small to medium sized teams (lt10 members)
  building software with vague or rapidly changing
  requirements
• Risky projects with dynamic requirements are good
  candidates for XP.

10

• Small iterations -2 weeks
• Feedbackcustomer involvementschedule slips
• Make each release work
• Make the smallest initial release that works
  Establish credibilityresults
• Keep delivering working products
• Maintain test re-run test after every change
• Keep Defect rate under control
• Customer in team continuously refining specs
• Do the right product address need changes
• Make your own estimates, human interaction,
  constant pace collective work

11

• Simplicity focus on current requirements and no
  more
• Future may change
• Maintain simplicity via frequent refactoring
• Instead of upfront design re-architect for
  simplicity
• Pair programming
• Collective ownership and Informal reviews
• Test first tests are your goals to achieve
• Implement test first requires through
  understanding of the specification
• Ambiguities and omissions are captured before
  implementation
• On site customer
• Decisions, clarification, prioritization,
  acceptance tests
• Continuous integration working product releases
• Relies on tests

12
XP Practices

• The XP methodology has 12 practices.
• The Planning Game
• Small releases
• Metaphor
• Simple Design
• Testing
• Refactoring
• Pair programming
• Collective ownership
• Continuous integration
• 40-hour week
• On-site customer
• Coding standards

• Beck emphasizes that you cant pick and choose
• if youre not doing them all, youre not
  doing XP

13
12 Practices of XP

• Planning Game Determine the next releases scope
  by working with customers
• Customer what is desirable
• Programmer what is possible -balancing
• Small Releases Put a system into production
  quickly (release every 1-2 weeks)
• Metaphor Guide the development with a simple
  story of how the system works
• E.g. Desktop is a metaphor used in OS referring
  office desktop
• Simple Design

14
12 Practices of XP (contd)

• Testing tests are written first, by both
  programmers and customer unit tests, acceptance
  tests
• Tests are your goals to achieve
• Implement test first requires through
  understanding of the specification
• Ambiguities and omissions are captured before
  implementation
• Refactoring Restructure the system without
  changing its behavior
• Simplicity focus on current requirements and no
  more
• Future may change
• Maintain simplicity via frequent refactoring
• Instead of upfront design re-architect for
  simplicity

15
12 Practices of XP (contd)

• Pair programming 2 programmers at 1 machine
  write codes
• Two programmer working side-by-side, on the same
  computer, interchanging roles back and forth.
  While one programmer actively implements, the
  other observes and identify defects and also
  thinks strategically about the direction of the
  code
• Informal reviews
• Collective ownership Anyone in the team can
  modify the code Everyone is responsible of every
  bit of code

16
12 Practices of XP (contd)

• Continuous integration Integrate and build the
  system many times a day
• Keep testing while integratingalways a working
  product
• 40-hour a week Work no more than 40 hours per
  week
• On-site customer Have the customer on the team
  to answer questions full-time
• Resolve disputes set short term priorities
  decisions
• Coding standards
• Improve communication by adopting coding
  standards collective ownershipmaintanance

17
When not to try XP

• XP is very appealing to many programmers often
  because they think can get away from heavy
  documentation
• in fact the test-first practice creates a lot of
  documentation, though in code form
• Beck himself indicates that there are situations
  where XP is not appropriate. These include
• When it is not supported by the company culture
• e.g. belief in big specifications, or overtime
  seen as a proxy for commitment to company
• More than 10 or 20 programmers (now, he claims
  the opposite)
• Project too big for regular complete integration
• Where it inherently takes a long time to get
  feedback
• Where you cant realistically test
• e.g. already in production using a 1,000,000
  machine that is already at full capacity
• When the physical environment is wrong

18
Extreme Programming 5 Values

• Communication (with customer and within the team)
• "XP programmers communicate with their customers
  and fellow programmers. "
• Simplicity Keep design simple and clean
• Feedback Get feedback by testing the software
  starting on day one
• Courage Deliver the system to the customers as
  early as possible and implement changes as
  suggested. Feel comfortable with refactoring or
  modifying or deciding to throw code away
• "With this foundation XP programmers are able to
  courageously respond to changing requirements and
  technology. "
• Respect (the latest value) respect others and
  their work
• E.g. never commit change that break compilation

Based on http//www.extremeprogramming.org
19
Comparison of activities
Time
Test
Implement
Design
Analyze
Waterfall
Iterative
XP
20
(No Transcript)
21
Other Software Process Models

• Rational Unified Process
• Rapid Application Development
• Formal Systems Development
• Reuse Based Development
• Component Based Development