Typically, RUP is presented as a use-case driven, architecture first, iterative-incremental process divided in four phases: inception, elaboration, construction, and transition.
Somehow, using a manufacturing metaphor (I know, I know... usually are the worst ones, and can't go too far), the project can be divided into 2 major stages: "engineering" (inception and elaboration) and "production" (construction and transition).
The good thing is "engineering" aims to reduce significantly the risk level of the project. The biggest uncertainties at the beginning of a project are usually related to requirements (and scope) or technical ones, and they have a big impact because they’re the major sources of cost and time overruns. The traditional approach like the “waterfall” process is to pinpoint all the requirements and then complete the design to the detail (what the “agilists” call “Big Requirements Up Front” and “Big Design Up Front”). I will not beat the “Waterfall” straw man, it has its niche (albeit a lot smaller than most people think). Other option is ignore them and hope that the team is “agile” enough to respond to the risks when they materialize.
In the case of RUP, there’s an explicit intention to “defuse” those risks, by exposing and validating the assumptions as soon as possible:
- the inception phase main goal is to discover what it should be done (usually identifying most of the use cases, and detailing the most critical ones)
- the elaboration phase main goal is to define how it should be done, by defining the architecture of the system (based on the critical use cases)
3 comments:
Walker Royce does a good job of explaining this in his text Software Project Management: A Unified Framework. There is a version of a graphic Royce had in that text on slide 8 in this presentation.
Thanks for your comment!
I have the book and I love it, it was a great eye-opener about the unified process: I always looked at RUP from the development (designer/architect) POV and seemed very good, but when I saw the management perspective, it looked even better :-)
I'm sure that Walker Royce explains it better than me, but I wanted to highlight it, because somehow I feel people misses the point and one of the big values of RUP (Maybe they should call it “risk-driven” process also)…
Thanks a lot for the slides, although I’ll complain abo: I saw it many times, and I understand Rational marketing trying to push RUP everywhere, but IMHO, that’s not RUP, there’s no executable architecture validation at the end of elaboration, and the iteration feedback loop is missing… in that case, probably you can use waterfall and avoid RUP complexities.
On the other hand, I guess if you’re using MDA or DSLs you’ll end with a strange shaped RUP, i.e. probably you’ll spend most of the effort in Elaboration (if you need to define your translation/language)…
You have given a bird-eye view of RUP that readers will find useful as I did. I had used some aspects of RUP and planning to prepare some ready reckoner of RUP for students. Good job dude!
Post a Comment