The Rational Unified Process is a software development process that covers the entire software development lifecycle. In this book chapter, you’ll learn its key features and how they can benefit you.
An Introduction to the Rational Unified Process
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Just to round up on that topic (not really representative):
http://www.codeproject.com/script/survey/detail.asp?survey=357
Reading the comments draws the picture: people are too ignorant to learn UML or see it as a fancy architects doodle tool. Beyond the sheer numbers you could correlate the poll result to nowadays software quality?
RUP is part useful documentation, part psycho babble. There are far better systems than this proprietry one, baring in mind that Rational charge the earth for training.
Yes, I have used it – exclusively for two years. No – I do not like it, nor do I recomend it to anyone below management level. It’s the sort of framework managers use to scare employees, use to make themselves feel self important, and fox directors into giving them stupid amounts of budget for unrealistic but ‘fully risk managed’ projects (that ultimately fail anyway.)
Have to agree with Arthur. I used RUP as well and end result was far over the budget.
The main problem with the RUP IMHO is either you go it full to the end or forget about it.
We wanted to implement it in design and management phases only and in the end we had a very nice digrams and docs which weren’t used by developers. Huge design phase was just trown out of the window. And implementation of it – just a HUGE cost without any real garantee of then end result (from my experience).
Reagarding processes in general, I see most of them as the offspring of corporation work rationalisaiton, based on the hypothesis that everything can be modelled and controlled to improved “quality” (aka. how many $ do I get back from the $ I put in) — this makes most of them rather inadequate to practice.
I consider RUP too much “corporate”-oriented to be really effective, but at least it offers a valuable guide on what to do to write an adequate program.
RUP is fine when you take it as advices and good practices, but let your own process emerge from your activity… which requires some reflexion and understanding of your activity.
… beside a damn lot of others.
As far as I learned so far about RUP, is that it is just another modified waterfall model. As many other modified waterfall models they allow to run through a [group of] step[s] more than once. Thus they call it an iterative process.
BTW, I prefer light weight models like eXtreme Programming.
Carsten
as far I know XP also use iterative processes… so no escapeing there
XP does not only use iterative processes it is an iterative process. And that is why I prefer XP.
RUP — like the V-Modell (aka AU250 in the german forces) used by the german government — is a sequentiell process with iterative processes patched in.
Carsten
…one problem is that people just take it as a whole while you are supposed to tailor it to your need. BTW after 4 years of RUP I prefer Agile Approaches such as SCRUM with eXtreme Programming http://agilealliance.org AND http://agilemovement.it
Sorry, used it and it is bloody awful. It constricts you into pointless processes where you could quite safely avoid them, you end up going around in circles (pun intended for those familiar with the RUP…) and time blows out because it is process driven.
Sorry but process driven approaches to system architecture and implementation do not work. You need a communication based methodology and for me, the only one that is worth a damn for development is CMM/CMMi. Combining the cherry picking CMM process with some form of agile development is the best way as far as I’m concerned. It maximises your throughput while enhancing your traceability and tractability.
http://computer.org/software/homepage/2003/s3man.htm
http://www.agilealliance.org/articles/articles/XPFromACMMPerspectiv…
http://www.dtic.mil/ndia/2002cmmi/boehm.pdf
RUP can work, but people need to be willing to change it and trailor it to their needs much as Grid says. I’ve use OUP (“Our” Unified Process) which cuts the fat from RUP that was too cumbersome or didn’t apply to our project; we injected pair-programming (not extreme programming as we’ve never seen that work real well on a project with 120+ developers) and some of our own refactoring processes (all allowed under RUP if you read and understand what you are suppose to do with it; using RUP out fo the box is not recommended).
If you’re do RAD or prototyping, or actually want to get something “out the door” in 6 months, then yes, stay away from RUP (especially as it sounds like others as others have been forced to use it). If you have a larger project and are contractually held to delivering what the customer is paying for, then you may want to consider using RUP as a framework or foundation of you process as documentation, no matter how painful it what can save your company’s a55….at the very least get them to sign off on the requirements so that you can provide your upper management with the necessary defenses when the customer claims the product doesn’t do x, y, or z.
Well there you have it. At least some people agree with me (though others don’t).
Andrew to be honest I prefer “pure” Agile approaches but I’m not a zealot who is unable to see that there are different situations and different needs 🙂
… it’s a meta-process. You have to adapt it to your own developers, to your organization, to your corporate culture. The problems arise when it’s everything else that adapts to RUP, and not vice versa.
All these “processes” reek of management-talk and MBA buzzword compliance.
The only method that works is drinking lots of coffee, writing the innermost parts first – in assembly, and giving a copy of
“The Mythical Man-Month” to your manager, so that they know in advance that it’s almost impossible to be on time and under budget!
“The Mythical Man-Month” is one of the doc Agile Approaches value most!!
You know what UML stands for? Useless Modeling Language. And god, I still blanch at the thought of what they said it’d cost us to get Rose.
Personally, I find it useless, though others might disagree. I here they’ve got some decent protocol documentation tools, though, so those might be helpful. Honestly, I never had trouble reading diagrams before UML came around, and it seems silly to me to spend twice as much effort in making perfect UML diagrams when some drawings on a sheet of computer paper get the same job done. Plus, I’m not a very visual person (and I think a lot of other coders might be in the same boat) so I feel the new UML craze tends to ignore what I consider most important — good, well-written, prose design documents.
As many here have pointed out, the RUP can be successful if everyone is committed to it. RUP’s biggest payoff comes fromthose projects where there has traditionally been a disconnect between a client’s expectations and what he or she receives from the development team (“That’s not what I wanted!”)
I’m a firm believer in choosing the right development methodology for the job, and a large development effort with many stakeholders and team members, that effort would be well-served by a formal methodology such as RUP. A small, dynamic group would be better served with a methodology like XP or whatever has worked before.
You don’t need the RUP tools or training to do RUP, but it helps. I’m not overly impressed with the clunky tools (think: VB gray)nor their dependency on MS Word, but they get the job done. Hopefully, IBM will maintain the development of Rational Rose, RequisitePro, etc., and open source some stuff to the Eclipse Project.
-danny
Majority of the RUP is nothing more than common sense like continuously verify software quality and manage requirements. On major projects this makes a huge difference in software quality.
“Honestly, I never had trouble reading diagrams before UML came around, and it seems silly to me to spend twice as much effort in making perfect UML diagrams when some drawings on a sheet of computer paper get the same job done.”
Or one can see UML as a way to make “back of the napkin” diagrams part of the process. Also UML can go through the same refinement process that defines software development.
“Plus, I’m not a very visual person (and I think a lot of other coders might be in the same boat) so I feel the new UML craze tends to ignore what I consider most important — good, well-written, prose design documents.”
Unfortunately that’s not what is delivered, to the point that it’s a running joke in the industry. How many times have we seen documentation (assuming there is some), and code fall out of sync?
IF UML can help in keeping everyone on the same page and in sync, then great?
Of course, those “back of the napkin diagrams” all get compiled into large books full of documentation. And as often as not, scanned in and put in the central documentation repository.
As for prose documentation — I don’t see why it’d be any harder to keep such documentation in sync then UML diagrams.
>> As for prose documentation — I don’t see why it’d be any harder to keep such documentation in sync then UML diagrams.
Prose documentation would describe what the code should do, whereas UML describes the structure of the code.
Er, scratch that last comment. Total misread what you had said.
I’ve been using StarTeam for Software Configuration Management
for a few years now and like it a lot. The focus is on software development
and not verbage, MBA-Speak.
http://www.borland.com/starteam/
Sean
http://www.osnews.com/comment.php?news_id=6425 from yesterday was about a better way for generating software (allthough the comments indicate it was about education)
as in merging the design and implementation process. Rose can generate code from UML – AFAIK. Has anyone tried it? Does it work?