SOFTWARE ENGINEERING

CSC 423 B - MWF 11-12

EXTREME PROGRAMMING

TO:

Dr. Khaldoun El Khalidi

FROM: Lamia Nassif,

Jessy,
Nadine Ghanem,
&
Pedro Maroun Eid

Due: 20 March 2002

Table of Contents
I. ABSTRACT ...........................................................................................................................3
II. TECHNICAL INVESTIGATION .......................................................................................4
A. Principles...............................................................................................................4
B. Practices................................................................................................................4
C. The Process...............................................................................................................6
III. RUP vs. XP......................................................................... Error! Bookmark not defined.
IV. REFERENCES ....................................................................................................................16

EXTREME PROGRAMMING

I-

ABSTRACT

Extreme Programming, or XP, is a lightweight discipline of software development

based on values of simplicity, communication, feedback, and courage. It was developed
by Kent Beck in 1996 who wrote the original book on the subject, Extreme Programming
Explained. XP is designed for use with small teams who need to develop software quickly
in an environment of rapidly changing requirements. [1] It works by bringing the whole
team together in the presence of simple practices, with enough feedback to enable the
team to see where they are and to tune the practices to their unique situation.
Extreme Programming challenges many common assumptions about software
development. One of the most controversial is its rejection of significant effort in upfront design, in favour of a more evolutionary approach. To its detractors, this is a return
to "code and fix" developmentusually derided as hacking. To its fans, it's often seen as
a rejection of design techniques, principles and patterns. [3]

II-

TECHNICAL INVESTIGATION
A- Principles:

Extreme Programming rests on the values of simplicity, communication,

feedback, and aggressiveness, which are considered as The Four Commandments of
Extreme Programming (XP). [2]

SIMPLICITY means that the software is developed using the simplest possible design
and constructs, but it means more: simplicity pervades the entire process. XP eliminates,
as much as possible, the unnecessary elements of building software. One of our rules is
You arent going to need it, which reminds us to add software or process only when we
really need them, not in anticipation of need.
COMMUNICATION is key to rapid development and to customer satisfaction. XP
embodies communication with a focus on simplicity: Use person-to-person
communication instead of written documents wherever possible. It also stresses
continual communication between the customer and development team members by
having an on-site customer while development progresses. The on-site customer decides
what will be built and in what order.
FEEDBACK is important to any development process, but when you are trying to
eliminate everything you can, you need feedback to be sure youre on track. Software
testing is a major source of quality feedback in XP, but we include resource, scope, and
time feedback as well.
AGGRESSIVENESS (or courage) in moving forward is possible when you take the
simplest possible approach and employ a process high in communication and feedback.
In other words, doing the right thing even when it is not the most popular thing to do. It
means being honest about what you can and cannot do.

B- Practices:
Twelve XP practices support the four values. These practices tend to keep the
team on track while they build up a grasp of the principles that form the basis for the
practices. In XP, every contributor to the project is an integral part of the whole team
formed around a business representative the Customer. There are twelve XP
practices that the team should depend on when adopting XP.
i. The Planning Process, sometimes called the Planning Game:
The XP planning process allows the XP "customer" to define the business value of desired
features, and uses cost estimates provided by the programmers, to choose what needs
to be done and what needs to be deferred. The effect of XP's planning process is that it
is easy to steer the project to success.
There are two planning steps in XP:
The Release planning: a practice where the customer presents the desired features to
the programmers in the team who in return estimate their difficulty.
Iteration planning: a practice whereby the team is given direction every couple of
weeks building a software in 2-weeks iterations and delivering running useful software
at the end of each iteration.

ii. Small Releases:

XP teams put a simple system into production early, and update it frequently on a very
short cycle. The team releases running, tested software, delivering business value
chosen by the Customer, every iteration. The most important aspect is that the software
is visible, and given to the customer, at the end of every iteration. This keeps everything
open and tangible.
iii. Testing, also known as customer tests:
XP teams focus on validation of the software at all times. Programmers develop software
by writing tests first, then software that fulfils the requirements reflected in the tests.
Customers provide acceptance tests that enable them to be certain that the features
they need are provided. The best way for success is that once the test runs, the team
keeps it running correctly thereafter.
iv. Metaphor:
XP teams develop a common vision of how the program works, which we call metaphor.
In other words they use a common "system of names" and a common system
description that guides development and communication.
v. Simple Design:
A program built with XP should be the simplest program that meets the current
requirements. There is not much building "for the future". Instead, the focus is on
providing business value. Of course it is necessary to ensure that you have a good
design. There are design steps in release planning and iteration planning, plus teams
engage in quick design sessions and design revisions through refactoring, through the
course of the entire project. In an incremental, iterative process like Extreme
Programming, good design is then essential. That's why there is so much focus on
design throughout the course of the entire development.
vi. Refactoring, or design improvement:
Extreme Programming focuses on delivering business value in every iteration. To
accomplish this over the course of the whole project, the software must be well
designed. This is done by keeping the software clean: without duplication, with high
communication, simple, yet complete. Refactoring is, of course, strongly supported by
comprehensive testing to be sure that as the design evolves. Thus the customer tests
are a critical enabling factor. The XP practices support each other: they are stronger
together than separately.
vii. Pair Programming:
XP programmers write all production code in pairs, two programmers working together
at one machine. This practice ensures that all production code is reviewed by at least
one other programmer, and results in better design, better testing, and better code. In
fact, many experiments have shown that pair programming produces better software at
similar or lower cost than programmers working alone.
viii. Collective Code Ownership:
All the code belongs to all the programmers. This lets the team go at full speed, because
when something needs changing, it can be changed without delay, which increases code
quality and reduces defects.
ix. Continuous Integration:
XP teams integrate and build the software system multiple times per day. This keeps all
the programmers on the same page, and enables very rapid progress. Perhaps
surprisingly, integrating more frequently tends to eliminate integration problems that
plague teams who integrate less often.

x. Sustainable Pace sometimes known as 40-hour week:

XP programmers work hard and at a pace that can be sustained indefinitely. This means
they do not work overtime, unless its effective, keeping themselves fresh, healthy, as to
reduce as much as possible mistakes.
xi. On-site Customer:
An XP project is steered by a dedicated individual who is empowered to determine
requirements, set priorities, and answer questions as the programmers have them. The
effect of being there is that communication improves, with less hard-copy documentation
- often one of the most expensive parts of a software project.
xii. Coding Standard:
For a team to work effectively in pairs, and to share ownership of all the code, all
programmers need to write the code in the same way, with rules that make sure the
code communicates clearly.

C- The Process:
As all other software engineering methods, the process in XP is similar to the
process used elsewhere. In fact, we can divide the above discussed practices into four clear

progressions that are the planning, the design, the coding and the testing.

i. Planning:
The Onsite Customer participates in the Planning Game. The development team
interviews the customer to determine user stories about how the system will work. User
stories are combined or split to come up with a story that can be described on a CRC
Card, and completed by a pair of programmers during one release cycle (typically about
three weeks). The customer prioritizes the cards according to the business value of the
user stories, which puts stories into the release schedule based on the development
resources available. This lets customers have an accurate commitment schedule.
After each release, the customer has a system that works according to the stories
completed so far; they don't have to wait for the whole thing to be done to start using
the initial functionality. The development group identifies which stories are risky to
complete on time (mainly because of a lack of experience with that type of coding) and
does worst things first based on a spike solution.

ii. Designing:
XP relies on test driven development for its inner loop. This pumps the outer loop,
and makes the political end of XP possible. Promises are automatically kept. Unit tests
are written which the successful software will be able to pass. At first, the tests fail
because the software hasn't been written yet. A simple design is developed by doing the
simplest thing which might pass the tests. Big-design-up-front is avoided because you
are not going to need it. However, once the simplest thing is done the programmers
refactor (combine similar code) mercilessly, because in the end things should be
expressed once and only once.

iii. Coding:
XP involves pairs of programmers working together on code, so that the entire
development team achieves Code Stewardship. Code Stewardship is the opposite of
Code Ownership, emphasizing that code is the team's property, and not the sole
province of any one person or pair. Programmers should code Unit Tests first. This Pair
Programming leads to Collective Code Ownership. Programmers follow the coding
conventions (standards) whenever they write new code, and while they refactor
mercilessly. The customer should always be available upon the coding phase; this is to
ensure that the code is being written as the customer wants. The written code should be
integrated often, typically each day. Code should be optimized as it is written; there
should be no need for revision afterwards. Coding should be done according to the
corresponding user stories written in the order that the customer informs. Each story is
written stand alone and at the end of the day integrated into the rest of the project.
Programmers or coders should work no more than 40 hours a week, this is to always be
sure that these programmers are always giving out their best. Basically, No overtime
should be allowed.

iv. Testing:
Extreme Testing includes Unit Tests for all code, creating tests when bug is found,
and running Acceptance tests often and publishing the scores. Extreme Testing is the
best way to survive extreme change. With extreme testing you can develop software
more quickly, with more confidence, and with higher quality. Extreme Testing includes
two basic tests: unit tests and functional tests.
1- Unit Tests
Unit Tests let developers evolve the system rapidly and with confidence.
Developers have to learn how to build the system, and customers have to learn what
they really want so that we can build the software and change it quickly. We should be
sure that the code is well-factored so that we can easily transform yesterday's code into
what we need tomorrow. Unit Tests specify two key actions:
a. To be sure that new features work, write Unit Tests for every feature.
Write them before you write the code and save all the Unit Tests for
the whole system.
b. To be sure that nothing is broken, run all the Unit Tests in the entire
system before any code is released, and ensure that those tests run at
100% because if anything breaks you will know exactly where the
problem is. When every Unit Test in the entire system is running 100%
that shows us not just that the new feature works, but that the
changes haven't broken anything anywhere.
2- Functional Tests
Functional Tests are tests that check each increment to see if the value is there.
These tests give customers and developers confidence that the whole product is
progressing in the right direction. Customers need confidence to keep putting up the
money and time. This confidence comes from seeing the system actually do what is
being paid for. Here are the key dimensions of Extreme Functional Tests:
c. Customer-owned: customers should understand the tests to get
confidence from them.
d. Comprehensive: customers should pick values where the test will
have meaning if it succeeds and if it fails.
e. Repeatable: developers should write new tests when you do a new
increment.
f. Automatic: developers should have a testing facility to set up and run

the tests, check the results, and report them.

g. Timely: If the tests do not show up until weeks after the development
is done, it just slows things down.
h. Public: customers need to see progress in the software
development, so if there is a decline in test scores the
developers should not ignore that.
Graph 2.1 can tell almost the complete story of quality. We can see the test
status at the end of each development increment. The yellow band says that there are
problems in getting validated answers. Then, as validated answers started to come
along, we see that the system is making a lot of errors. In increment eight, quality took
a big step upward, and has improved. Finally, in increment twelve, all the data values
are validated, and there has been a healthy project, and we can have great confidence in
the quality of the system.

Graph 2.1

III-

A Comparison: RUP VS XP

Rational Unified Process (RUP) is a process framework, refined over the years
by Rational Software and is being widely used on a variety of software projects, from
small to large.
Extreme Programming (XP) is a software development approach gaining increasing
recognition as an effective method for building smaller systems in an environment of
changing requirements.
Most processes have some common elements that make a systematic comparison
possible. They require sequences or groups of activities, which are performed by roles
(usually played by people working as individuals or teams) to generate artifacts or work
products, some or all of which are delivered to a customer. Most processes also
acknowledge that instances of the process will have a time dimension, with a beginning
and an end, and interesting intermediate milestones that represent the completion of
significant activities (or clusters of activities) and the production of associated artifacts.
[4]

The purpose of this comparison is to clarify the relative positions of RUP and XP in the
process spectrum to see what each can offer the other and to dispel the notion that XP is
a lightweight, and therefore desirable, alternative to the heavyweight RUP.
The dimensions of process that make the comparison between RUP and XP are the
following:

Time and Effort Allocation: It discusses how each process is arranged over
time and how the staffing effort allocation compares.
Artifacts: It compares the work products; those things produced in the course of
an XP and RUP based project.
Activities: It discusses the way in which each process says its artifacts should be
produced.
Disciplines: It compares the way in which XP and RUP delineate the major areas
of concern in software engineering.
Roles: It explores the differences between roles (that perform activities) in the
RUP and roles that are closer to positions within a team in XP.

Time and Effort Allocation

RUP deals with projects whose lifespan is divided into phases named Inception,
Elaboration, Construction, and Transition. Each phase is further split into iterations and
each iteration may require several builds.
For most projects in RUP, the duration of an iteration will be between two weeks and six
months, and the number of iterations in a projects lifetime will be between three and
nine. So at these default settings, RUP covers projects ranging in duration from six
weeks to 54 months. [4]
XPs iterations are about two weeks in duration. XPs releases are two months (or
slightly longer); they are defined by the customer and released to the customer. In
duration, XPs releases are like RUPs iterations, during Elaboration or Construction at
least, for projects with a maximum team size of 10 that are based on an established
architectural baseline. [4]

10

Artifacts
RUP describes over 100 artifacts, which has led to the criticism that it imposes an
intolerable bureaucratic overhead for small projects. This view is incorrect on four
counts:
Projects dont have to produce all artifacts: selecting and tailoring artifacts is a
necessary part of the process. RUP provides guidelines on what can be omitted and what
can be tailored.
An artifact (in RUP, an artifact description) is a specification entity that specifies the
information to be produced by an activity and, to do this systematically, it may describe
the abstract form of an artifact. The RUP characterization of artifacts as models, model
elements, or documents is not intended to imply a particular realization.
A UML model could be captured and presented using a purpose-built tool (such as
Rational Rose), or, at the other extreme, as diagrams made by using a simple graphics
tool, or even as a sketch on a whiteboard.
RUP documents are information sets composed of text and diagrams. To be useful, RUP
specifies what this information should be, and a convenient and systematic way to do
this is to point to a template, which enumerates and describes the items and issues to be
considered. Its certainly possible to use these templates in a direct and formal way to
realize the artifacts in document form that is, electronic or paper. Not everything
presented in a template is necessarily relevant to a particular projectand RUP gives a
project the freedom to choose any appropriate realization for an artifact. The important
thing is the information it contains.
XP seems to be immune from the criticism of being artifact-heavy, but this is an
oversimplification for two reasons:
XP is already tailored to suit a certain kind of development; dealing with a subset of the
RUP disciplines at a certain scale and so would be expected to call for fewer artifacts.
XP emphasizes the importance of user stories and code, but other things that are work
products are mentioned in passing when describing the process, so the artifact count is
not as small as it appears at first sight.
Here are some examples of artifacts:

Stories
Constraints
Tasks
Technical tasks
Acceptance tests
Softwarecode
Releases
Metaphors
The designCRC, UML sketch
Design documentsproduced at the end of the project
Coding standards
Unit tests
Workspace (development and other facilities)
Release plan
Iteration plan
Reports and notes on any meetings
Overall planbudget
Reports on progress

11

Story estimates
Task estimates
Defects (and associated data)
Additional documentation from conversations
Supporting documentation
Test data
Testing framework tools
Code management tools
Test results
Spikes (solutions)
Task work time records
Metrics data
- Resources
- Scope
- Quality
- Time
Other metrics
Tracking results

There we have around 30 artifacts, some of which are composites too. The list is
intended to be indicative, not exhaustive.
Once a project has to realize them, more detail of their content and form will be needed.
A project can certainly do that on the fly, but that takes time away from the real work;
in contrast, RUP provides up-front guidance, thereby saving the project time. [4]
The reasons for which XP does not need all the RUP artifacts are the following:
1- XP is about programming to meet a business need. How that business need
occurred, and how its modeled, captured, and reasoned about, is not XPs main
concern.
2- XP asserts that requirements and design capture can be done rather simply.
3- RUP allows for a greater formality in project management, where this is
necessary, and in some contract arrangements it will be. Many of RUPs project
management artifacts are part of composite artifacts, and need only be realized
as separate documents when the formality of the project demands it.
Activities
RUP formally defines the term activity as work performed by a role, using and
transforming input artifacts, and producing new and changed output artifacts. RUP then
goes on to enumerate these activities and categorize them according to discipline or
major area of concern within project. [4] These disciplines are:

Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Configuration & Change Management
Project Management
Environment

Activities are time-related through the artifacts that they produce and consume: an
activity can logically begin when its inputs are available. This means that producer-

12

consumer activity pairs can overlap in time, if the artifact state permits; they need not
be rigidly sequenced.
Activities in RUP are intended to make the intellectual process of producing an artifact
less opaque, to give some strong guidance on how something should be produced.
Activities may also be used to help the project manager with his or her planning. Woven
through the RUP as its described in terms of lifecycle, artifacts, and activities, are the
best practices: software engineering principles proven to yield quality software built to
predictable schedule and budget. [4]
The RUP, through its activities and their associated artifacts, supports and realizes these
best practicesthey are themes running through the RUP.
XP presents an engagingly simple view of software development as having four basic
activities that are to be enabled and structured according to some supporting practices:

Coding
Testing
Listening
Designing

Actually, XPs activities are closer in scope to RUPs disciplines than to RUPs activities,
and much of what happens on an XP project (in addition to coding, testing, listening, and
designing) will come from the elaboration and application of its practices.
RUPs apparent prescription comes from its completeness and greater formality in
its systematic treatment of activities, and their inputs and outputs. XP does not lack
prescription, but perhaps in the attempt to remain lightweight, the formality and detail
are simply omitted. The detail that is present in RUP will have to be added when XP is
implemented on a project. Lack of specificity is not a strength or a weakness, but we
should not confuse the lack of detailed information in XP with simplicity. At some point,
the people on the project will need to know what to do and at that time will need the
detail. [4]
Disciplines and Workflow
A discipline in RUP is the collection of activities and associated concepts producing a
particular set of artifacts, which represents some important aspect or concern in
software development.
RUPs disciplines are Business Modeling, Requirements, Analysis & Design,
Implementation, Test, Deployment, Configuration & Change Management, Project
Management, and Environment.
This does not cover every aspect of what an
organization or business might do when employing people to develop, deploy, operate,
support, sell, market, or otherwise deal with systems that are largely software.
RUP currently does not cover Systems Engineering or all of the requirements of some
international software process standards such as ISO 15504 since they are outside its
engineering focus. [4]
XP explicitly restricts itself even further. It includes four basic activitiescoding, testing,
listening, and designingperformed using a set of practices, which requires performing
other activities that map to some of the other disciplines in RUP.

The XPs practices are:

13

The Planning Game: Quickly determine the scope of the next release by combining
business priorities and technical estimates. As reality overtakes the plan, update the
plan.
Small Releases: Put a simple system into production quickly, and then release new
versions on a very short cycle.
Metaphor: Guide all development with a simple shared story of how the whole system
works.
Simple Design: The system should be designed as simply as possible at any given
moment. Extra complexity is removed as soon as it is discovered.
Testing: Programmers continually write unit tests, which must run flawlessly for
development to continue. Customers write tests demonstrating that features are
finished.
Refactoring: Programmers restructure the system without changing its behavior to
remove duplication, improve communication, simplify, or add flexibility.
Pair programming:
machine.

All production code is written with two programmers at one

Collective ownership: Anyone can change any code anywhere in the system at any
time.
Continuous integration:
time a task is completed.

Integrate and build the system many times a day, every

40-hour week: Work no more than 40 hours a week as a rule. Never work overtime a
second week in a row.
On-site customer: Include a real, live user on the team, available full-time to answer
questions.
Coding standards: Programmers write all code in accordance with rules emphasizing
communication through the code.
Activities performed as a result of the practice The Planning Game, for example, will
mainly map to RUPs Project Management discipline. However, some topics are outside
the scope of XP such as Business Modeling. Requirements elicitation is largely outside
the scope of XPthe customer defines and provides the requirements. Deployment of
the released software is outside the scope of XP too. Because of the scale and types of
development it addresses, XP can deal very lightly with issues in Environment and
Configuration & Change Management disciplines that the RUP covers in detail.
In the disciplines in which XP and RUP overlap, some of the practices described in XP
could be employed in RUP and others could not. The following table distinguishes
between these practices:

XP practices that do not

scale
Collective ownership

XP practices that scale

Pair Programming
Test-first
design
refactoring
On-site customer
Coding standards
Continuous integration

and

Refactoring
Metaphor
Rapid releases
Simple design
40-hour week

14

Roles
In RUP, activities are performed by roles. Responsible roles will usually create the
artifact and ensure that any changes made by other roles (if such changes are allowed),
do not break the artifact. A role in RUP may be performed by an individual or by a group
of people. Equally, an individual or a group may perform several roles. A role does not
have to be mapped to a single position or slot in an organization; the mapping of roles
to organizational units may also be many-to-many.
RUP defines a total of 30 roles. There is not an exact mapping to disciplines since a role
such as a software architect is not necessarily confined to one discipline, for example:

Business Modeling has three roles

Requirements has five roles
Analysis & Design has six roles
Implementation has three roles
Test has two roles
Deployment has four roles
Configuration & Change Management has two roles
Project Management has two roles
Environment has three roles

Roles in RUP are used to partition activities, and to finely discriminate the skills and
competencies needed to perform the role, which helps guide the selection of staff to
perform the roles. The level of division also facilitates the identification of new
organizational positions when the importance of a role changes. For example, on a small,
informal project, the role of Project Manager and Configuration Manager (RUP roles) may
well be performed by the same individual. By describing roles in this way, RUP facilitates
this mapping. [4]
XP defines seven applicable roles with their responsibilities, the skills, and the traits
required of the people who will perform them. These roles are:

Programmer
Customer
Tester
Tracker
Coach
Consultant
Big Boss

The difference in the number of XP and RUP roles is easily explained:

XP is not covering all of the RUP disciplines.

XP roles are actually closer to positions than RUP roles; for example, XPs
programmer actually performs multiple RUP rolesthose of Implementer,
Integrator, and Code Reviewerand these require slightly different competencies.

When RUP roles are mapped to a small project, the number of XP-like roles that are
mapped reduces considerably from 30. [4]

15

REFERENCES
[1]
Ronald E. Jeffries, What Is eXtreme Programming, Extreme Programming
Magazine,
August 2001.
[2]
Ronald E. Jeffries, eXtreme Testing, Software Testing & Quality Engineering
(STQE)
Magazine, March /April 1999.
[3]
2001.

Martin Fowler, Is Design Dead, Software Development (SD) Magazine, April

[4]
2001.

John Smith, A Comparison of RUP and XP, Rational Software White Paper,

16