Rational Unified Process Rational Unified ProcessPreviously, 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 http://www.itworld.com/AppDev/530/050803mi/ For a view of RUP (and all its supporting modules) that is up to date as at mid 2005.
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
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
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
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
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
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:
I'm using it. Actually it's been made available as a network share. It has a nice JavaApplet 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. -- StevenNewton
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) -- RobertWatkins
The Rational people give a comparison of XP and RUP in their on-line mag The Rational Edge (http://www.rationaledge.com). There are two parts...
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 MetaProcess that allows you to implement the XP process in RUP via templates.
Yes, it's New and Improved SnakeOil, 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 "PairProgramming" and "TestFirstDesign and Refactoring" given out. Both can be found on Rational's website. Both were written by RobertCecilMartin of ObjectMentor Inc.
It's not redefining: RUP is and has always been a MetaProcess. 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. -- RobertWatkins.
I'd hate to see Rational try to EmbraceAndExtend XP into RUP. Maybe it's a good thing that XpIsDogmatic; it's a good defense against EmbraceAndExtend if you're isolationist.
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006