Giving RUP a Chance

by Gary K. Evans

This month's newsletter focuses on The IBM/Rational Unified Process. I have had several encounters this month about how to move to RUP, and the benefits it offers. Here are some of my answers.

The IBM/Rational Unified Process (RUP) is one of the leading iterative software development processes. The current version of RUP, version 7, is available as an embedded component of the IBM/Rational Method Composer product. RUP has always been a generic process definition, or more accurately, a generic process framework. Because it is a generic process, RUP has always been large in size (7,505 files in 278 folders). It can be challenging to adopt, and even more challenging to implement.

Should you consider RUP? Do you have to take RUP as it is defined by IBM? What does a process like this mean for the main constituencies in your project ecosystem?

If you read our industry press you could easily conclude that waterfall died in the '90s and everyone is iterative or agile today. My consulting experience affirms that the truth under this blanket of hyperbole is that many successful organizations still pursue waterfall software development - and many of them are running C# or Java shops. But competitive pressures for greater efficiency are motivating these companies to look for alternatives.

Nothing can excite, or inject fear into, a company like changing everything about how you develop software. Changing development languages is trivial compared to changing process. But the potential trauma can be minimized with just a little planning and forethought.

Small Steps

You can move to RUP in measured steps. You do not have to implement RUP in its totality to obtain real benefit. If your organization needs to improve requirements, introduce just the practices of RUP's Requirements discipline. Even if your Project Management Office is following a large serial PM process, you can still introduce RUP's iterative approach just within the IT organization. One of the most popular articles on my website is my one-page version of RUP focusing just on the development team.

Make RUP Adapt to You

You can, and should, tailor RUP to meet your needs, not twist your organization to conform to RUP's out-of-box definition. IBM's packaging of RUP inside Method Composer is a clear signal that RUP should be tailored to fit your organization's culture and practices. With Method Composer you can remove RUP content that you are not ready to adopt, and you can add new content that RUP does not address. I worked with a huge tax filing service and assisted their augmentation of RUP. We added an entirely new Initiation phase that preceeded the Inception phase of RUP. The disciplines of this phase focused on project initiation and chartering.

Kick the Tires Before You Buy

Don't dictate that RUP will be your standard until you test drive it on at least one project, and preferably two. Add to the project plan a review milestone where you actively dissect your experience with RUP: what worked, what did not, what surprised you, what must you do to make it better the next time? Do you still see value in moving to RUP? I have worked projects where the organization had been following RUP for 2-3 years, yet they were not successful in their implementation. But they never did an autopsy to discover why all the projects were dying.

People Supercede Process

Moving to RUP affects almost every group on a project. Business Analysts will have to become comfortable with not having all requirements up front. Developers will have to learn to describe the problem before they jump into a solution, and in the iterative world they have to deliver software every few weeks, not 6 months from now. Project Managers will have to learn that "formality is not discipline" and being part of the team is more important than building Gantt charts. Testers will have to learn to test early and often, not just at the end of development. Changing how people think is always painful...until the new way becomes the old way.

RUP is Not Waterfall

When an organization moves to a new paradigm like RUP, it is inevitable that the people will bring along their prior ways of thinking. The single most common mistake made is to equate RUP's four phases with the phases of the waterfall process. That is, thinking that RUP's Inception phase is where requirements are gathered, then the Elaboration phase is where design is done, the Construction phase is where all the coding is done, and the Transition phase is where all the testing is done. This thinking is entirely opposite to the iterative philosophy embodied in RUP, where each iteration across all the RUP phases conducts some level of requirements capture, analysis, design, implementation and test.

If you are exploring options to your current development process, RUP is worth giving a long, hard look. In reality RUP can be almost anything you want it to be. But it should never be a cause of failure, or frustration.

    Gary K. Evans

When Should Your Project Start Updating?

A question that always arises in my projects, and my training sessions, is: When changes occur downstream should we update our earlier project documents? I reply to this question with 3 answers.

1. If you always update everything for every change - large or small - you will never accomplish anything but document upates.
2. If the downstream change does not render the original document misleading, don't waste the time retrofitting those changes into new versions of the document.
3. What consequences can you reasonably expect if you simply allow some divergence between upstream and downstream artifacts?

But there is a larger issue here, and that is: what is the value-lifetime of any document or project artifact you produce?

Not all documents, models, or even code, have the same value over time. Many UML diagrams have very limited lifetimes. The use case diagram has primarily only structural value. It illustrates the associations between actors and use cases in a system. But after a few iterations the value of the use case diagram approaches zero, because the real project value is in the use case descriptions. A Vision specification written in March may be quite out of sync by August after customer requirements change. Some code not only may be removed, some code always should be removed from a system. Every developer knows they would make wholesale changes to their code if they could do it over. Code refactoring is a very controlled way to acknowledge, and remedy, this diminishing value in code.

Whether you try to maintain a tight fidelity between your project artifacts and your code is both a process issue and a policy issue. I encourage my project teams to consider both the upside, and the downside, to keeping all information updated all the time. In reality the current code set is always the definition of the project's status. If changes later in your project render your architecture spec, or your business requirements spec, to be slightly out of date, is that really a project risk? In many cases it is not. We can never get the whole project perfect, so we should always put our effort where it will have real return on our investment. Many times, forcing updates on earlier artifacts is not the best investment we can make.