RationalUnifiedProcess (RUP) has been acquired by IbmCorporation and an introduction is found at http://www-306.ibm.com/software/awdtools/rup/
Previously, Rational Unified Process was a version (proprietary to the RationalCompany) of the UnifiedSoftwareDevelopmentProcess, a SoftwareEngineering Process.
RUP provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget.
See  For a view of RUP (and all its supporting modules) that is up to date as at mid 2005.
The methodology was formerly known as Objectory (MFKAO). See 
Which explains its weightiness. -- AlistairCockburn
There's an introductory book on it by Phillipe Kruchten ISBN 0201604590 . It's a nice overview book, but RUP is certainly aimed at heaviness. -- MartinFowler
Q: If I'm going to read one book on RUP, should I read this one? I'd assumed I'd go to the source (Jacobson), but perhaps this is unwise. I ask because it is rumored that my company will be adopting RUP.
A: Yes, this is a good book to start with. It is an overview similar in scope to ExtremeProgrammingExplained. If you're looking for details however, go straight to the source (Jacobson).
Any opinions on the usefulness of RationalUnifiedProcess? It seems to be rather much documentation to produce in every iteration. Is it useful even for large projects or will creativeness suffer? -- FredrikRubensson
I have the book, and flipped through it (i.e., did not read carefully and critically. I actually thought they did a good job at writing. As the XP people have noticed by now, and Ron commented on CrystalClearMethodology, any methodology looks awfully large when you try to write it down in any amount of detail. So what I found were fairly reasonable discussions of requirements changing, use of prototypes, etc. ... I say that, but then I have been accused of not reading books with enough of a critical eye...
Regarding documentation, every methodology I have ever seen - with the specific exceptions of XP and CrystalClearMethodology, advises more documentation to be done than any successful project team I have interviewed has been able to do. I did meet a person whose project was cancelled because they were actually made to produce all that documentation. Mostly I meet teams who are told to produce all that documentation, and simply produce a percentage, and the project managers are content, because they get the software they need in a tolerable time frame, with at least a little documentation. -- AlistairCockburn
Perhaps the project manager should make a tiny subset of the documentation mandatory? I feel documents like RequirementsSpecification including UseCases, ArchitecturalOverview?, CodeComments, TestPlan? and ProjectEvaluation? should be mandatory. (Somewhat depending on the development context. Speculative software are less likely to need a detailed specification than internal software written to do a specific task. -- FredrikRubensson
In the company I work with, we've been using RUP for some time with great success. They key thing about RUP is that you don't take it wholesale and produce every artifact that it defines. You start with a Development Case that defines what you think will be useful to your project. To me this fits well with the philosophy of XP - keep it simple, only do what needs to be done, etc.
The problem I see with XP is that it is too developer centric, it sees the primary focus of a project as the developers. I believe this is a dangerous attitude to have, since the primary focus of a system must be the customer/user.
Much of what is in XP is in RUP, I see it as a light weight extension of RUP focused on the construction phase - though the user stories focus on requirements. -- Alastair Thomson
Why do you say XP focuses on developers? It strikes me as one of the most customer-focused methodologies I know of. It's certainly the only one I'm aware of that 'mandates' an OnsiteCustomer. -- JohnBrewer
They key thing about RUP is that you don't take it wholesale and produce every artifact that it defines.
It now seems fairly clear that RUP can be configured into something like XP if you need to be seen to do RUP. -- KeithBraithwaite
ObjectMentor have developed an XP tailoring of the RUP product - which I discovered during a recent Rational RUP training course - so it seems they can happily coexist after all :-) CarolineFoster
Reading the Rational RUP Whitepaper, I got very frustrated. It seems like in RUP, the Construction Phase (aka Coding) is supposed to be boring and mechanical. This sounds like a very thoughtless evaluation. From the whitepaper:
It is easy to argue that the elaboration phase is the most critical of the four phases. At the end of this phase, the hard "engineering" is considered complete and the project undergoes it's most important day of reckoning....
Stupid me, I thought the most critical part of a project was whether it delivered its required functionality or not. Here is more:
The construction phase is, in one sense, a manufacturing process where emphasis is placed on managing resources and controlling operation to optimize costs, schedules and quality.
I thought TayloristManagement principles were proven to not work well in software construction (or most other activities, for that matter). It seems like the RUP view of the construction phase is that it should be boring, mechanical and mainly handled by drones. Aren't they dragging the ConstructionMetaphor too far?
It does however advocate iterative development within each phase, so that by the end of the "elaboration" phase (which is 2/4, after "inception") there should have been a few cycles of build-test-release already. It goes on to say you should have established a baseline architecture and a production-quality prototype by the end of Elaboration. If you are practicing TestFirstDesign (which they also encourage) you will indeed have a large chunk of the functionality in place already. So the Construction phase should be dealing mainly with remaining functionality, last minute changes, bugs and deployment issues. They see it as a transition from the development of intellectual property during inception and elaboration, to the development of deployable products during construction and transition. Which doesn't sound so bad. -- CarolineFoster
On another note, has anyone studied the possible connection between techniques that are perceived as boring and techniques that resist adoption? Sorry about the steam; a bit of built up tension there. -- JohannesBrodwall
It does seem as if techniques that are boring for developers are much easier to get accepted by management. Or is that not what you were asking about...
RUP does seem to carry forward the idea of "seamlessness" that was built into OMT and such: The idea that requirements can merge into design into code in a very uniform way. More recent DocumentTransformationTheoryOfSoftwareEngineeringy? methods (e.g. CatalysisMethodology) have rejected this for a much more subtle idea of seamlessness. The old notion resonates well with a TayloristManagement ("software factory") mindset. Of course, we all know that the software factory is the compiler and CD burner.
XP is trivially seamless, as all the deliverables are code. -- KeithBraithwaite
I've read the book. Does everyone agree it's just another heavyweight process? Why bother when we have ExtremeProgramming? -- sg
It is claimed, by UncleBob, most notably, that RUP doesn't have to be heavy weight at all. This suggests to me that Bob has a much deeper and more GnomicUnderstanding? of RUP and how it is meant to be used than anyone I've ever seen try to use it. The real joy of RUP is that it is, like Objectory before it, a proprietary methodology. The book mentioned above just scratches the surface. For the full deal, you have to buy the CD. Think about that, a whole CD devoted to this one method. -- Keith
Right. That's scary! Reminds me of DOD Std 2169! -- sg
Sure, the RUP is weighty and complex (sophisticated?), but my experience with using it on two major projects is that if you ask anybody on the project team if they could simplify the part of the RUP they will be working with, they will typically object that it can't be done.
This reflects the by-now widely understood truth that modern software development has become quite difficult and complex. You have to juggle a lot of balls at the same time to make sure every component of a system can do all the things expected of it these days. To paraphrase a great thinker, you can only make your development processes as simple as possible, but no simpler.
Expectations for new systems are now very high in general but software development projects are especially being pressured by increasing amounts of COTS and legacy integration requirements resulting an explosion of one of the trickiest software problems: Excessive system dependencies and logistical management issues. In addition, new software systems now have to scale up to the Internet and as a result are expected to exhibit 24/7 reliability right out of the gate. This is further exacerbated by the expectations people now have after years of coming into frequent contact with good examples of high-quality software systems. These influences ensure that software projects are far more complex (and difficult) than in previous years while the techniques and processes for managing the difficulty and complexity are falling behind. Most current lightweight development methods (read: informal programming techniques) just can't coherently address and manage these issues with reasonable time/cost curves.
If you invest the resources, the RUP (or any well-defined and documented structuring of your development activities) will actually help to mitigate these challenges instead of just helping you tread water. The problems are classic though: The learning curve and finding talented people willing to learn and work together using a common plan. And, XP is not so different based on my one attempt to use it on a non-trivial project. Either way, there's lots to learn, and so little time and few good people. -- DionHinchcliffe
Secondly, as my company management recently crystallized their "we like Rational" approach by buying RUP, I can reveal it's fairly cheap. $10,000 dollars for CD-ROMs for everyone in a small company, and free future RUP upgrades. However, be warned that the RUP product has been designed to work best with close integration with other Rational tools. That is, the RationalWorkbench? tool for easily editing the site then publishing it, and RationalRose for the UML creation/publishing. The combined costs of several licences for Workbench, and the large cost of a company-wide licence for Rose, would certainly dwarf the price of RUP. So Rational's strategy is to sell RUP very cheaply. Once you have it, there's an entire Tool Mentor section which serves as a huge advertisement for the Raional Suite of tools. And, as noted, if you wish to make company-specific changes to RUP HTML files (and there's 1000's of them), for maintainability and easy future RUP upgrades you must buy Rational Workbench and Rose. There lies the rub.
So "the full price-tag of RUP" is ultimatly the cost of:
RUP + Workbench + Rose [+ the pain of having to actually use RUP ;-) ]