What is the difference between UP, RUP, and XP

[Jane Somerfield]

Hi, What is the difference between UP, RUP, and XP?

[Ilja Preuss]

UP is the Unified Process - a process framework from which you can essemble your personal process. It is quite voluminous, aiming to provide a solution for every problem. Many teams have problems with slimming it down to an appropriate size for their project, so it has the reputation of being rather heavy weight, although it doesn't have to be.
RUP stands for Rational Unified Process and is simply the commercial version of the UP. The Rational corporation makes a living by selling tools to help with the process and by coaching teams in using it.
XP - eXtreme Programming - OTOH is a minimal methodology, providing a starting set of practices you can start your project with, trusting the team that it will augment it where appropriate. It is very people centric and tends to suggest the usage of rather low-tech tools. It isn't backed up by a single big company, but by a world-wide, strong community. There are some companies specializing in XP-coaching and some open source projects providing the most essential tools you will need (JUnit being certainly the most famous).
It is possible to tailor a RUP project, so that it strongly resembles XP: http://www.objectmentor.com/publications/RUPvsXP.pdf
Why do you ask?

[Jane Somerfield]

Thanks, Ilja.
I thought they are only for software. I do not know whether UP can be used for everything that
involves human activities.
I used RUP before. It is only for software production.
XP is new to me. I think that Its idea is very similar to RUP.
The reason I was asking is to clear some confusion.

[Glen Cai]

I think RUP is enough. Why should we worry
about XP?

[Frank Carver]

I think RUP is enough. Why should we worry
about XP?
Because it can enable small, focussed teams to deliver high-quality, high-value software which tracks changing business needs from day one?
Becuase it can help to break down the "Big Design Up Front" burden which is carried by so many projects ?
I strongly suggest that you read about XP. For many people XP (and other similar "agile" software development methodologies) can bring a breath of fresh air into a project.

[Ilja Preuss]

Originally posted by Jane Smith:
Thanks, Ilja.

You're welcome!

I thought they are only for software. I do not know whether UP can be used for everything that
involves human activities.

You are right, all the three are *software development* processes/process frameworks. I think I somehow thought that was implied... :roll:

XP is new to me. I think that Its idea is very similar to RUP.

Admittedly, I don't know RUP very well. How would you describe its idea?

The reason I was asking is to clear some confusion.

I hope this helped somewhat.
If you want to know more about it, take a look at http://www.extremeprogramming.org/ - it's a little bit outdated in some minor details, but nevertheless a very nice introduction.
And don't hesitate to ask further questions!

[Ilja Preuss]

Originally posted by Glen Cai:
I think RUP is enough. Why should we worry
about XP?

Because XP can show you a new perspective to software development, because it can teach you things RUP doesn't teach - simply to fill your bag of tricks.
Of course you probably shouldn't only take a look at XP, but also at SCRUM, Crystal, FDD, ASD, DSDM, AM etc. (in random order).
Unless you don't want to improve, of course - then you shouldn't care at all and just continue to do what you are currently doing...

[Ilja Preuss]

BTW, Grady Booch (from Rational) is close observer and frequent poster of the XP mailinglist. So it *is* possible to know RUP and being interested in XP nevertheless...

[Jane Somerfield]

I'll try to say it in one sentance:
RUP is a role based iterative process for
requirement, architecture/design, development, building, testing, and source control.
Or I can say "do a litter and test a litter, but
not lose the big picture".
A complex system is divided into smaller and
maybe simpler tasks in the iterations for each
developers.

[Glen Cai]

What is the true value that XP brings, but RUP
does not have?

[Ilja Preuss]

Originally posted by Jane Smith:
I'll try to say it in one sentance:
RUP is a role based iterative process for
requirement, architecture/design, development, building, testing, and source control.
Or I can say "do a litter and test a litter, but
not lose the big picture".
A complex system is divided into smaller and
maybe simpler tasks in the iterations for each
developers.

I guess that would more or less resemble XP, too, yes. Although XP is more activity based than role based (in fact it basically only defines two roles: customer and developer), makes a strong point about writing the tests *before* implementing the accompanied production code and possibly might be seen as laying less stress on the "big picture".

[Ilja Preuss]

Originally posted by Glen Cai:
What is the true value that XP brings, but RUP
does not have?

What you see as "the true value" will probably depend on what you seek in a methodology and what role you play in the development process - it will have totally different values for customers, developers, managers etc.
So tell us - what do *you* seek in a methodology? What is your role in software development. What is the greatest risk you see in software development?

[Ilja Preuss]

BTW, Rational is working on an XP-plug-in for RUP: http://www.rational.com/products/rup/xprog.jsp

[Glen Cai]

The successful rate for enterprise software is
too low (about 20%?). A good methodology should
improve it, not just some new terminology.

[Ilja Preuss]

Originally posted by Glen Cai:
The successful rate for enterprise software is
too low (about 20%?). A good methodology should
improve it, not just some new terminology.

Yes.
If you are really interested in learning more about XP, please answer my questions above. It shouldn't be that much effort to you, but will help me considerably getting down to the points that are interesting to you - instead of writing tomes of bland explanations.

[Glen Cai]

The greatest risk I see is the management.

[Ilja Preuss]

Originally posted by Glen Cai:
The greatest risk I see is the management.

Am I understading you correctly that you mean things like "will the project be on time/in budget"?

[Glen Cai]

You are partially right. Corruption in
middle level management in big enterprises
and immature technologies are other problems.

[Ilja Preuss]

Originally posted by Glen Cai:
You are partially right.

For that part an XP team would give you the ability to rather accurately know where the project stands and what to expect in the future every one to two weeks.
The techniques making that possible are mainly a *very* incremental development cycle (making it impossible that "90% of the system are 90% done") and the Planning Game.

Corruption in
middle level management in big enterprises
and immature technologies are other problems.

That is outside the scope of XP.

[John Dale]

I don't have XP exerience, although I'm trying to get started. But here are a few observatoins.
Although XP may provide some help in dealing with an immature technology, like providing for quick, focused explorations that might help you determine that the technology doesn't fit or doesn't work, encouraging you to build the riskiest parts first so you can make drastic changes if needed to deal with problems (like yanking a technology that is too immature), and by producing a design and providing a process that is more likely to accomodate a drastic change if you have to make it.
As for corrupt management, well, XP should have you operating in a fail-fast mode (to stretch a programming analogy). Success or lack thereof should be visible relatively early. That may not help with real corruption, but it can help keep you as honest as you are willing to be.

[Jane Somerfield]

I think corruption in project management can
cause morale problems in the development team.
It may lead to the project failure. Is there
a methodology that can deal with it? I do not
think so.
[ September 07, 2002: Message edited by: Jane Smith ]

[John Dale]

It would seem that some approaches, a management problem is more likely to be visible early, as would be other problems.
Early visibility of problems, and the early opportunity to fix them, is part of the attraction of XP for me.
On the flip side, I'm expecting XP to make it easier to say "it's not a problem unless it is a problem", that is, to consider something a problem only if it becomes a problem, not because it might become a problem later. So you spend your time addressing the problems that really do need to be fixed, instead of whatever you happen to spot from the large universe of potential problems.