Unveiling the Rational Unified Process

Last week I took a short course on the Rational Unified Process (RUP) and it reminded me of a great talk delivered by Rodolpho Ugolini (senior IBM RUP instructor) at Encontro Agil 2009. He spoke about some fairly common misconceptions in regard to RUP and clearly explained what the core of the process really is. Since RUP is often misunderstood, I decided to share on this post some of the things I learned from that talk (I also recommend the article “How to fail with the Rational Unified Process: seven steps to pain and suffering”).

What RUP is?

• a set of principles and techniques

• a knowledge base about Software Development

• a set of tools for process creation

RUP’s myths

• It recommends responsibility division and “silos”;

• Big teams with many specialists;

• Requirements must be detailed at the beginning of the project;

• Iterations are “little waterfalls”;

• There are many documents to be filled;

• Implementing a software model is fundamental;

• RUP is heavy-weighted, outdated and bureaucratic.

What RUP really says

• Roles are not posts (RUP has dozens of roles);

• Applying all RUP will result in a deficient project environment;

• Generalists (or multispecialists) are encouraged (generalists are more expensive!)

• The more multi-disciplined the better;

• Projects benefit from teams working with fewer people, working at the same place (the ideal team size is 5 people);

• Each activity is the responsibility of a role;

• The team is responsible for the project’s success;

• Project’s decisions are made by the team;

• Use cases are a technique to elicit requirements, and they’re not the smallest work unit. Each iteration must prioritize use cases and implement specific scenarios. Use cases must be identified at the beginning of the project;

• Software development is not predictive. The best way to estimate is basing upon the team’s experience;

• RUP is an iterative method! Every iteration’s goal is to produce software. The shorter the iteration, the better.

• The artifacts generally are not documents. Documents are the least efficient way of communication. The best way of communication is personal and direct.

• No RUP artifact is mandatory. Again: no RUP artifact is mandatory! Artifacts are just tools to ease communication. So use if it is good for you.

• RUP has models: requirements model, analysis and design model, implementation model and scripts. Again, none of them is mandatory and not all of them are to be specified with UML (one of the worst uses of UML is for documentation). Models can be either more formal or less formal (keep in mind that formality is different from text). The team decides what has value for the project;

• The goal is to produce software, not documents;

• Lots of documentation is bad and little documentation is bad;

• It’s useless to document code;

Conclusion

Can you notice the resemblance of RUP with Agile methods? Most of what RUP already spoke is being repeated by the Agile community with better words.

In short, RUP has four pillars:

• controlled iterative development;
• guided by use cases;
• architecture centered;
• directed by risks.

So why RUP failed? According to the speaker, Rational’s worst mistake was to provide diagrams and templates. By the way, during the course I took, I noticed how IBM/Rational still has a strong focus on processes and tools (maybe they’re sort of ignorant of the first principle of the Agile Manifesto).

What do people do when they don’t know how to do something? They go after the recipe. We must understand that no software is the same as another and neither are the processes used to make software. Take the Eclipse project, for instance, which is one the the most complex and sophisticated current software projects. The Eclipse team developed their own method, called Eclipse Way.

Most companies that state they’re using RUP are actually using WUP – the Waterfall Unified Process (just as an aside: the “waterfall” process was first desbribed in Dr. Winston Royce’s 1970 paper “Managing the development of large software systems”. In the paper, he mentions how this model is flawed as does not work for building software!).

Bottom line is: If it’s not iterative , then it’s not RUP.

“If one has strong discipline without agility, the result is bureaucracy and stagnation. Agility without discipline is the unencumbered enthusiasm of a startup company before it has to turn a profit.” (Alistair Cockburn)