CSCI 335 — Software Development
eXtreme Programming
November 14, 2007
Material adapted from slides by Jan Vitek at Purdue University and Kent Beck, eXtreme Programming eXplained.
CS 335 1
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community
Ask the community for help and clear up your study doubts
University Rankings
Discover the best universities in your country according to Docsity users
Free resources
Our save-the-student-ebooks!
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
Lecture Notes on Extreme Programming | CSCI 335, Study notes of Software Engineering
Material Type: Notes; Professor: VanDrunen; Class: Software Development; Subject: Computer Science; University: Wheaton College; Term: Fall 2007;
Typology: Study notes
Pre 2010
1 / 12
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Lecture Notes on Extreme Programming | CSCI 335 and more Study notes Software Engineering in PDF only on Docsity!
CSCI 335 — Software Development
eXtreme Programming November 14, 2007
Material adapted from slides by Jan Vitek at Purdue University and Kent Beck, eXtreme Programming eXplained.
Problems in Software Development
Schedule slips. Estimates are hard to make, even harder to meet. System souring. After a few years in place and a few changes, things stop working. Defect rate. When code is buggy enough, it is abandoned. Specification misunderstandings and changes.of-date problems. The system solves wrong or out-
False feature richness. The system has lots of features, most unnecessary. Staff turnover. The best programmers quit.
The Traditional View
Design, design, design first!
We must work out all the bugs ahead of time.We can’t afford mistakes later.
XP’s Central Premise
Cost of change
Specification Analysis Design Coding Testing Production
XP’s Solutions
- Spec misunderstanding and changes.
- – Customer is on the teamChange?– No problem
- False feature richness.
- Highest priority features first
- Staff turnover.
- Process breeds loyalty
XP Strategy
Contain the cost of change:
- OO design (for reusability, plus polymorphism etc)
- Simple designs
- Automated tests
- Atmosphere of modifications
Instead of making big decisions early and little ones late, XP
makes frequent decisions and assures them with tests.
XP Activities
- Coding
- Testing
- Listening
- Designing
XP Practices
- Whole team.Metaphor. Design with a shared story. Remove the barrier between the customer and the rest of the development team
- The planning game.Small releases. Simple system soon, short cycle for new versions. Quick and focused on the next release.
- Simple design.Testing. Developers continuously write unit tests, customers write functional tests. Remove complexity.
- Refactoring.Pair programming. Redesigning while maintaining functionality. All code produced by two programmers at one machine. 10.^ 9.^ Collective ownership.Continuous integration.^ All code is communal—anyone may change anything at anytime. Build many times a day.
- 40-hour week.On-site customer No more than two consecutive over-time weeks.. A live user is on the team.
- Coding standards. Prevents chaos.