Docstoc

Extreme Programming

Document Sample
Extreme Programming Powered By Docstoc
					Extreme Programming

    Kiran Pamnany
Software Engineering

ü Computer programming as an engineering
  profession rather than an art or a craft
ü Meet expectations:
  ü   Functionality
  ü   Reliability
  ü   Cost
  ü   Delivery schedule
Methodologies

üMethodology: codified set of
 recommended practices
üNo consensus:
  ü Waterfall model
  ü Spiral model
  ü Rational Unified Process (RUP)
  ü Extreme Programming (XP)
Classic process steps

ü Requirements Analysis
ü Specification
ü Design and Architecture
ü Coding
ü Testing
ü Documentation
ü Maintenance
Waterfall model

ü Proposed in 1970 by W. W. Royce
ü Development flows through steps:
  ü   Requirements analysis
  ü   Architectural design
  ü   Detailed design
  ü   Coding, debugging and unit testing
  ü   Integration and system testing
  ü   Deployment, operation and maintenance
Waterfall model (cont.)

ü Pros:
  ü Track progress easily due to clear stages
  ü Easily identifiable milestones and deliverables
ü Cons:
  ü Inflexible: difficult to respond to changing
    requirements
  ü Design and coding discover requirements
    inconsistencies
  ü Some problems not discovered until system testing
Spiral model

ü Defined in 1986 by Barry Boehm
ü Modified waterfall
ü Software is developed in a series of
  incremental releases
ü Early releases are prototypes
ü Later releases become increasingly complete
ü Receive feedback after each release
Spiral model (cont.)

ü Pros:
  ü Systematic and stepwise, but in an iterative
    framework
  ü Estimates get more realistic as work progresses
  ü Some ability to cope with changing requirements
ü Cons:
  ü Time-intensive process
  ü Not extensively used
Rational Unified Process (RUP)

ü Defined in 1997 by Grady Booch, Ivar
  Jacobson and James Rumbaugh
ü General framework to describe specific
  development processes
ü Designed to be tailored for a given software
  project with consideration for its size and type
ü Recognized to be particularly applicable to
  large projects with large teams
RUP Phases

ü Inception
  ü Shared understanding of the system with the
    customer
ü Elaboration
  ü Architecture to build the system
ü Construction
  ü Developing the system
ü Transition
  ü Customer takes ownership of system
RUP Guidelines

ü Develop iteratively
   ü Deal with changing requirements
   ü Address high risk items as the highest priority
     tasks at each iteration
   ü Ideally, each iteration has an executable release
ü Manage requirements
   ü Document functionality, constraints, design
     decisions, business requirements
   ü Define use cases and scenarios
RUP Guidelines (cont.)

ü Use component architecture
   ü For extensibility and reusability (CORBA/COM)
ü Model software visually
   ü Abstraction using UML
ü Verify software quality
   ü Plan quality control and assessment
   ü Involve all team members
ü Control changes to software
   ü Use secure workspaces
RUP Workflows - Typical Project




 (Source: George Stepanek, 2004)
RUP Criticism

ü‘High ceremony methodology’
üBureaucratic: process for everything
üSlow: must follow process to comply
üExcessive overhead: rationale,
 justification, documentation, reporting,
 meetings, permission
Extreme Programming (XP)

üFormulated in 1999 by Kent Beck, Ward
 Cunningham and Ron Jeffries
üAgile software development
 methodology (others: Scrum, DSDM)
üDeveloped in reaction to high ceremony
 methodologies
XP: Why?

ü Previously:
  ü Get all the requirements before starting design
  ü Freeze the requirements before starting
    development
  ü Resist changes: they will lengthen schedule
  ü Build a change control process to ensure that
    proposed changes are looked at carefully and no
    change is made without intense scrutiny
  ü Deliver a product that is obsolete on release
XP: Embrace Change

ü Recognize that:
  ü All requirements will not be known at the beginning
  ü Requirements will change
ü Use tools to accommodate change as a
  natural process
ü Do the simplest thing that could possibly work
  and refactor mercilessly
ü Emphasize values and principles rather than
  process
XP Practices




  (Source: http://www.xprogramming.com/xpmag/whatisxp.htm)
XP Practices: Whole Team

ü All contributors to an XP project are one team
ü Must include a business representative--the
  ‘Customer’
  ü Provides requirements
  ü Sets priorities
  ü Steers project
ü Team members are programmers, testers,
  analysts, coach, manager
ü Best XP teams have no specialists
XP Practices: Planning Game

ü Two key questions in software development:
   ü Predict what will be accomplished by the due date
   ü Determine what to do next
ü Need is to steer the project
ü Exact prediction (which is difficult) is not
  necessary
XP Practices: Planning Game

ü XP Release Planning
  ü Customer presents required features
  ü Programmers estimate difficulty
  ü Imprecise but revised regularly
ü XP Iteration Planning
  ü   Two week iterations
  ü   Customer presents features required
  ü   Programmers break features down into tasks
  ü   Team members sign up for tasks
  ü   Running software at end of each iteration
XP Practices: Customer Tests

ü The Customer defines one or more automated
  acceptance tests for a feature
ü Team builds these tests to verify that a feature
  is implemented correctly
ü Once the test runs, the team ensures that it
  keeps running correctly thereafter
ü System always improves, never backslides
XP Practices: Small Releases

ü Team releases running, tested software every
  iteration
ü Releases are small and functional
ü The Customer can evaluate or in turn, release
  to end users, and provide feedback
ü Important thing is that the software is visible
  and given to the Customer at the end of every
  iteration
XP Practices: Simple Design

ü Build software to a simple design
ü Through programmer testing and design
  improvement, keep the software simple and
  the design suited to current functionality
ü Not a one-time thing nor an up-front thing
ü Design steps in release planning and iteration
  planning
ü Teams design and revise design through
  refactoring, through the course of the project
XP Practices: Pair Programming

ü All production software is built by two
  programmers, sitting side by side, at the same
  machine
ü All production code is therefore reviewed by at
  least one other programmer
ü Research into pair programming shows that
  pairing produces better code in the same time
  as programmers working singly
ü Pairing also communicates knowledge
  throughout the team
XP Practices: Test-Driven
Development
ü Teams practice TDD by working in short
  cycles of adding a test, and then making it
  work
ü Easy to produce code with 100 percent test
  coverage
ü These programmer tests or unit tests are all
  collected together
ü Each time a pair releases code to the
  repository, every test must run correctly
XP Practices: Design
Improvement
ü Continuous design improvement process
  called ‘refactoring’:
  ü Removal of duplication
  ü Increase cohesion
  ü Reduce coupling
ü Refactoring is supported by comprehensive
  testing--customer tests and programmer tests
XP Practices: Continuous
Integration
üTeams keep the system fully integrated
 at all times
üDaily, or multiple times a day builds
üAvoid ‘integration hell’
üAvoid code freezes
XP Practices: Collective Code
Ownership
ü Any pair of programmers can improve any
  code at any time
ü No ‘secure workspaces’
ü All code gets the benefit of many people’s
  attention
ü Avoid duplication
ü Programmer tests catch mistakes
ü Pair with expert when working on unfamiliar
  code
XP Practices: Coding Standard

üUse common coding standard
üAll code in the system must look as
 though written by an individual
üCode must look familiar, to support
 collective code ownership
XP Practices: Metaphor

ü XP Teams develop a common vision of the
  system
ü With or without imagery, define common
  system of names
ü Ensure everyone understands how the system
  works, where to look for functionality, or where
  to add functionality
XP Practices: Sustainable Pace

üTeam will produce high quality product
 when not overly exerted
üAvoid overtime, maintain 40 hour weeks
ü‘Death march’ projects are unproductive
 and do not produce quality software
üWork at a pace that can be sustained
 indefinitely
XP Values

üCommunication
üSimplicity
üFeedback
üCourage
XP Values: Communication

ü Poor communication in software teams is one
  of the root causes of failure of a project
ü Stress on good communication between all
  stakeholders--customers, team members,
  project managers
ü Customer representative always on site
ü Paired programming
XP Values: Simplicity

ü ‘Do the Simplest Thing That Could Possibly
  Work’
  ü Implement a new capability in the simplest
    possible way
  ü Refactor the system to be the simplest possible
    code with the current feature set
ü ‘You Aren’t Going to Need It’
  ü Never implement a feature you don’t need now
XP Values: Feedback

üAlways a running system that delivers
 information about itself in a reliable way
üThe system and the code provides
 feedback on the state of development
üCatalyst for change and an indicator of
 progress
XP Values: Courage

üProjects are people-centric
üIngenuity of people and not any process
 that causes a project to succeed
XP Criticism

ü Unrealistic--programmer centric, not business
  focused
ü Detailed specifications are not written
ü Design after testing
ü Constant refactoring
ü Customer availability
ü 12 practices are too interdependent
XP Thoughts

ü The best design is the code.
ü Testing is good. Write tests before code. Code
  is complete when it passes tests.
ü Simple code is better. Write only code that is
  needed. Reduce complexity and duplication.
ü Keep code simple. Refactor.
ü Keep iterations short. Constant feedback.
Software Quality: Another View

ü A programmer presenting an elegant but
  ‘inefficient’ solution, talks of the inelegant but
  ‘efficient’ solution
ü […] but your solution doesn’t work: if the
  solution doesn’t have to work, then Begin..End
  is a valid solution. Gerald Weinberg, ‘The
  Psychology of Computer Programming’, 1972
Software Quality: Another View

ü […] software engineering has accepted as its
  charter “How to program if you cannot.” E.W.
  Dijkstra, ‘The Cruelty of Really Teaching
  Computer Science’, 1988
ü Computer programming as a branch of
  mathematics--formal provability of a program
  is a major criterion for correctness
ü Program correctness is ‘constitutional’; an
  incorrect program is worthless or of negative
  worth
Formal Verification

ü The act of proving or disproving a system’s
  correctness with respect to a formal specification
  or property, using formal methods
ü System types include FSM, Petri nets, timed and
  hybrid automata, cryptographic protocols,
  combinatorial circuits, etc.
ü Properties to be verified are described in temporal
  logics; approaches include state space
  enumeration, abstract interpretation, etc.
Formal Methods

ü Mathematical techniques for the specification,
  development and verification of software and
  hardware systems
ü Classified as:
   ü Denotational semantics
   ü Operational semantics
   ü Axiomatic semantics
The Way Forward?

ü ‘High ceremony’ software engineering
  methodologies in disfavor
ü Agile software development methodologies in
  increasing use, but with significant criticism
ü Formal methods will never have a significant
  impact until they can be used by people that
  don’t understand them. T. Melham

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:1
posted:7/23/2013
language:English
pages:44