4/27/07

RUP and risk management

I must admit that I like the Unified Process. The more non-trivial the project is, the more I think is applicable.
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)
After those phases are completed, you will have the architecture of the system, feedback from the most critical use cases, a clear view of the scope, and no technical surprises awaiting. At this point you should be able to have an accurate estimation of the total project effort, and the total risk exposure of the project should be significantly lower...

3 comments:

blyons said...

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.

Unknown said...

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)…

ITMastersPro said...

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!