Things have moved on a little since the last posts - IBM donated part of RUP to Eclipse (the EPF project at www.eclipse.org 
) as well as the Eclipse-based tooling to create process descriptions that use a HTML-based format to document them. EPF includes efforts to incorporate XP/SCRUM and other methods/approaches. This has not fundamentally changed RUP as such - just easier for you to take a look at and use if appropriate -- Anthony Kesterton See Eclipse Process Framework.
Rational Unified Process (RUP) has been acquired by Ibm Corporation and an introduction is found at www-306.ibm.com
Previously, Rational Unified Process was a version (proprietary to the Rational Company) of the Unified Software Development Process, a Software Engineering 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 www.itworld.com 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 www.rational.com
Which explains its weightiness. -- Alistair Cockburn
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. -- Martin Fowler
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 Extreme Programming Explained. If you're looking for details however, go straight to the source (Jacobson).
Any opinions on the usefulness of Rational Unified Process? It seems to be rather much documentation to produce in every iteration. Is it useful even for large projects or will creativeness suffer? -- Fredrik Rubensson
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 Crystal Clear Methodology, 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 Crystal Clear Methodology, 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. -- Alistair Cockburn
Perhaps the project manager should make a tiny subset of the documentation mandatory? I feel documents like Requirements Specification including Use Cases, Architectural Overview, Code Comments, Test Plan and Project Evaluation 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. -- Fredrik Rubensson
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 Onsite Customer. -- John Brewer
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. -- Keith Braithwaite
Object Mentor 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 :-) Caroline Foster
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 Taylorist Management 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 Construction Metaphor 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 Test First Design (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. -- Caroline Foster
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. -- Johannes Brodwall
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 Document Transformation Theory Of Software Engineeringy methods (e.g. Catalysis Methodology) have rejected this for a much more subtle idea of seamlessness. The old notion resonates well with a Taylorist Management ("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. -- Keith Braithwaite
I've read the book. Does everyone agree it's just another heavyweight process? Why bother when we have Extreme Programming? -- sg
It is claimed, by Uncle Bob, 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 Gnomic Understanding 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. -- Dion Hinchcliffe
Q: So with the online support, the CD, and the books, what's the full price-tag of RUP?
A: ...
First, you don't need RUP books. The RUP CD-ROM is one big book (written as hyperlinked HTML pages, plus a Java applet collapsable/expandable menu bar in the style of Windows Explorer style).
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 Rational Workbench tool for easily editing the site then publishing it, and Rational Rose 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 ;-) ]
Note: You can do RUP without Rose. You can do RUP without Workbench if you don't want to customise it (beyond selecting a predefined workflow). You can not customise RUP without Workbench very easily; the web pages are too hard to edit. If you don't use the web pages, you're not using RUP, though you may still be using an instance of the USDP. RUP is USDP with fancy web pages, essentially. The RUP web pages are _very_ neat, but the inherent lack of flexibility and the difficulty of customising without shelling out for Workbench kills them. I'm yet to see a RUP workflow that did exactly what I want to do, out-of-the-box. -- Robert Watkins
Is anyone else using the RUP CD product at their company? What are your experiences with it?
I'm using it. Actually it's been made available as a network share. It has a nice Java Applet for navigation. There are several references to XP practices and integrating with RUP. If there's interest I'll see if I can supply a few short quotes and not violate our license agreement. -- Steven Newton
The RUP is actually a proprietary realisation (with some minor additions) of the (free) Unified Software Development Process, which provides the framework for RUP and any other similar iterative development processes. In this sense, the USDP is an abstract process and is described in the Usdp Book. -- Andrew Joyner
RUP is also an abstract process. RUP workflows are the process realisations, and can be either heavy or light (though even the published light ones are very heavy compared to most of the agile methodologies) -- Robert Watkins
The Rational people give a comparison of XP and RUP in their on-line mag The Rational Edge (www.rationaledge.com ). There are two parts...
RUP and XP Part I -- Finding Common Ground (www.therationaledge.com )
RUP and XP Part II -- Valuing Differences (www.therationaledge.com )
I attended (a couple of days ago) a seminar that Rational was giving in Auckland on XP. The general thrust appeared to be to sell RUP and their new IDE add-on for Visual Studio .NET (plus a couple of others) - "XDE".
The bit I found quite inventive was when they managed to sidestep the entire "Where does XP fit into RUP" (or vice versa) by redfining RUP as a Meta Process that allows you to implement the XP process in RUP via templates.
Yes, it's New and Improved Snake Oil, now in exiting new "Flavour of the Month"! Order yours now!
The seminar was mostly worthless, but there were a couple of quite good White Papers on "Pair Programming" and "Test First Design and Refactoring" given out. Both can be found on Rational's website. Both were written by Robert Cecil Martin of Object Mentor Inc.
It's not redefining: RUP is and has always been a Meta Process. If you built suitable templates, it would be easy to implement XP in RUP. Note that the "lightweight" workflows that Rational publish are still too heavy. -- Robert Watkins.
I'd hate to see Rational try to Embrace And Extend XP into RUP. Maybe it's a good thing that Xp Is Dogmatic; it's a good defense against Embrace And Extend if you're isolationist.
See original on c2.com