Xtreme
e
Programming Angelo Corsaro
[email protected] http://tao.doc.wustl.edu/~corsaro
Table of Contents Software Development Life Cycle (SWDLC). SWDLC Models. Cost Of Change. XP Introduction. XP’s Values. XP’s Principles. XP’s Practices. Putting it all Together. An XP Project Road-Map. References.
2
oftware Development Life Cycle
A Brief Overview… A Software Development Life Cycle (SWDLC) is an abstract representation of how software is developed. A SWDLC process can consist of Sequential Phases/Steps Parallel Phases/Steps
The Phases of a SWDLC process are typically – – – – – –
Requirement Analysis Design Specification Coding and Unit Testing Test and Integration Acceptance Test System and Software Maintenance
3
SWDLC Models
Generic Waterfall Model Assume a development process in which the step 1-6 outlined before are executed one after the other in sequential order. Requirements
Design Coding Unit Testing Test Integration Acceptance Test
Maintenance
4
SWDLC Models
Generic Waterfall Model This model in not practical, it fails in capturing the inherent iterative nature of SW development. SW development has concurrent and iterative aspects that this model fail to capture. Does not encourage prototyping and software reuse. The DOD SWDLC uses a variation of the Waterfall-Model. NASA uses a SWDLC development model that 5 is a minor variation of the DOD SWDLC.
Risk: The Basic Problem SWDLC Models
The basic problem of SW development is risk. Sample of risks are Schedule slips Project Cancelled System Goes Sour Defect Rate Business Misunderstood False Feature-Rich Staff Turnover
Commonly used SWDLC fall short in coping with the previously cited risks. 6
Spiral Model 1/2 It encompass both the best features of both classic life cycles and prototyping. Planning
Design Spec.
Req Analysis
Accptance Test
Client Evaluation And Input
Risk Analysis Prototyping Coding Unit Testing
SWDLC Models
Is a Risk-Driven approach to SW development.
Test and Integration.
Development Prototyping
7
SWDLC Models
Spiral Model 2/2 The Spiral Model can be used effectively for both System Enhancement System Development
Most SWDLC can be considered as a special case of the Spiral Model. The embedded Risk-Analysis built into the model avoids many of the difficulties that arise in other models. 8
SWDLC Models
Other SWDLC Models Rapid Throwaway Prototype Model. Incremental Development Model. Evolutionary Prototype Model. Cleanroom Approach (Based on mathematical specification of the software requirements).
9
Cost of Change One Universal Assumption of SW Engineering is that the cost of changing a program rises exponentially over time One of the key assumption of XP is that the cost of changing a program, can be kept mostly constant over time. This assumption is based on real-world experience, and on the use of both better Programming Practice Programming Environments
This assumption about the cost of change gives the opportunity of taking a totally different approach to SW development.
10
XP Introduction
Main XP Concepts XP is a lightweight development process. XP is made of a collection of Values Rules/Principles Practices
In XP values, principles and practices are often set to the extreme level, from here the name eXtreme Programming
11
XP Values
The Four Core Values of XP Communication. Simplicity. Feedback. Courage.
12
XP Values
Communication Often problem that arise in SW project can be tracked back to lack of communication. XP enforces the Communication Value by employing many practice that could not be carried without communicating (e.g. pair programming, unit testing etc.). XP employs a Coach whose job is that of noticing when people are not communicating and reintroduce them. 13
Simplicity
XP Values
XP embrace the principle of “Make it Simple” XP is betting that it is better to do a simple thing today and pay a little more tomorrow to change it, if it needs to be changed, than building a more complicate system that has feature that will never be used. Simplicity and Communication support each other mutually.
14
Feedback
XP Values
Feedback works in XP at different time scales. Programmers have feedback on a minutes time scale on the status of the system thanks to unit tests. When customers write new stories the programmers estimate those immediately to give prompt feedback to the customer about the quality of the stories. The customer review the scheduler every 2-3 weeks and provide prompt feedback to the 15 developer.
XP Values
Courage XP team should have the courage of throwing code away. XP team should have the courage of mainly refactor the architecture of the system, if architectural flaw are detected. Courage has in XP the same role that mutation has in genetic algorithms. Takes you out of local maximum/minimum.
16
XP Principles
Core XP Principles Rapid Feedback. Assume Simplicity. Incremental Change. Embracing the Change. Quality Work.
17
XP Principles
More XP Principles Teach learning. Small Initial Investment.
Accepted Responsibility. Local Adaptation.
Play to Win.
Travel Light.
Concrete Experiments.
Honest Measurement.
Open, Honest Communication.
Work with people instinct’s not against them. 18
XP Practices
XP Practices The Planning Game.
Pair Programming.
Small Releases.
Collective Ownership.
Metaphor. Simple Design.
Continuous Integration.
Testing.
40-Hours a Week.
Refactoring.
On-Site Customer. Coding Standards. 19
Putting it all Together 1/2 Planning User Stories Release Planning Release Plan Make Frequent Small Releases Project Velocity Iterative Development Iteration Planning Move People Around Daily Stand Up Meeting Fix XP When it Breaks
Designing Simplicity is the Key Choose a System Metaphor CRC Cards Spike Solution Never add Functionality Early Refactor Mercilessly
20
Putting it all Together 2/2 Coding On Site Customer Coding Standard Code Unit Then Test Pair Programming Sequential Integration Integrate Often Collective Code Ownership Optimize Last 40 Hours a Week
Testing Unit Tests When a Bug is Found Acceptance Test
21
XP Project
22
XP Project
23
XP Project
24
XP Project
25
References Extreme Programming Explained, Kent Beck Addison Wesley 1999 Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison Wesley 1999 http://www.extremeprogramming.org http://www.xp2001.org
26