what is the meaning of iterative in RUP?

Question

I have been reading the article entitled "A manager's introduction to RUP" and I have some doubts about what does iterations really mean on this methodology.

For what I know RUP has 4 phases: Inception, Elaboration, Construction and Transition; each of these phases has some "deliverables" or milestones that should be accomplished before going to the next phase.

Apart of that, I have like 9 disciplines that range from Business Modelling, Requirement elicitation, design, among others and ending with the environment phase. So if I want, for example, to make a selling system for a drugstore I suppose that my project should pass thru these 9 disciplines in each of the phases mentioned before.

So the iterative nature of RUP means that I can jump from top to bottom and bottom to top in these 9 disciplines for refining purposes; and should I do this for each of the phases? Or the iteration part means other thing?

Thanks

Answer 1

The first thing to keep in mind is that the Rational Unified Process is a process framework. It provides some constraints to allow organizations to build their own process around, with tailoring to let organizations choose what is appropriate for their needs.

I think the image on the Wikipedia article is a pretty good representation of the process framework.

Your four phases - Inception, Elaboration, Construction, and Transition are sequential. In a given project, you'll be in each one once. However, in each phase and within each iteration of a phase, you'll spend different amounts of time in the 9 (6 engineering and 3 supporting) disciplines.

You can see this in the diagram. Although some aspects aren't shown. For example, the diagram only shows one Inception iteration, but there could be many. Some disciplines lend themselves better to Inception than other disciplines - for example, Project Management, Business Modeling, Requirements, Environment, Configuration Management. The Inception phase has criteria for completion - agreed upon scope, primary use cases identified, a managed development process, project plan baselines, etc. Each iteration could have a different emphasis on work that needs to achieve the completion criteria, meaning the types of and effort put into the disciplines will vary within each iteration.

The same applies to the Elaboration, Construction, and Transition phases. Each one could have one or more iterations that show progress toward the end goals of that phase.

Answer 2

RUP was invented as an alternative to the traditional waterfall approach. Waterfall is considered risky nowadays, as you can discover too late that something you decided early on won't actally work.

If you look beyond the fancy terminology, RUP is a series of mini-waterfalls. On each iteration, you do the architecture, design, coding and testing. The first iteration should deliver something that is at least good enough to demonstrate, even if there are major features missing. It is recommended that risky features are also tackled early, so that if there are problems, you have more iterations to fix them.

Subsequent iterations revisit the architecture and design, add new code for missing features, then test everything so far.

I would expect each discipline to be involved in each iteration, though later iterations naturally tend to involve more low-level design and coding and less requirement and architectural stuff.

Unlike agile methods, RUP assumes that you have a reasonably mature specification before you start, and can plan how many iterations you should need. But it acknowledges that you won't get everything right first time.

Answer 3

Normally an iteration is a "feature set" or change. Keep in mind this is all abstract.

So you first "iteration" is make a button. Your second iteration is make a button blue. Your third iteration is make a button say "Hello".

How you go about accomplishing each iteration is where your "disciplines" come in. Keep in mind that each discipline will be used differently in each phase of the "iteration".

So no, you would not "bounce" around in your disciplines. You "finish" make a button, THEN "finish" (refine) make a button blue.

For example the "Inception" phase may be very heavy in "business modeling" but by the time your to do your "transition" there's little business modeling left to do. That does't mean that your can't use "business modeling" in the transition phase, it just means that there not a lot of if left to do.

Keep in mind that the disciplines are not steps but skill sets.

So take a simple exaple "Draw a house".

During inception you may use your "basic shapes" discipline, but in the Elaboration phase, when you decide to make it a red house, your not really using basic shapes any more.

Once again, however, these are generic, abstract constructs, that you can use to apply to your business how you see fit. They are not supposed to be strict, ridged rules or roles that must be followed (though your book may outline some of them.)