Transition

So Inception handled the risk of creating a project with insufficient value.
Elaboration handled the risk of selecting an architecture that couldn’t handle the high risk requirements.
Construction handled the risk of providing the most amount of the value we identified in Inception.

Transition handles the risk of a valuable project not being adopted into use.

Once we arrive at Transition, we have a complete valuable project with a good architecture. But we have to ensure that the target audience actually uses the product we’ve created successfully or that value is not realized.

Transition ends in one of two different ways, depending on the business you are in. Either it ends with “End Of Life (EOL)” or with “Release.”

If you are responsible for maintaining the product until the product is retired, then Transition ends with EOL. This means that you will continue to add maintenance iterations onto the plan for a long time to come. You will have iterations that basically implement groups of change requests, then release a product upgrade.

If you ever receive a change request that is architecturally significant or that radically changes the vision, what do you do? You probably guessed it. You start a new generation with its own IECT phases. Inception: Does this change have value? What is its scope? Elaboration: Let’s change a small part of the system to prove the architecture will work. Construction: Let’s change the rest providing as much value as we can based on time constraints. Transition: Let’s support the new version.

If you do not have the responsibility for maintenance, then Transition ends with “Release.” This can be because another group will be doing the support, or because you will be turning the source over to a client, etc. In this case Transition is finite and ends when the client or maintenance team accepts that they can successfully own the product now.

Construction

Inception handled the risk of building a project that had little or no value.
Elaboration handled the risk of building a project whose architecture could not support the high risk requirements.

Construction handles the risk of providing the most amount of value possible given the time constraints on the project.

By the time we get to Construction, we are sure that the project has value, and we are sure that the architecture is valid and will support the solution. Now we must build as much of the feature set as we can to provide the most value to our customers.

So there is an interesting point to understand here for a RUP project. Most people will say that value to the customer should drive development. In a RUP project this is true during Construction, but in Elaboration technical risk drives the project. In other words, during Elaboration, the Architect picks what we work on based on highest risk first, NOT based on highest value! But then during Construction the RUP Systems Analyst (a.k.a. Business Analyst, Requirements Owner, etc) picks what we work on based on highest value first.

Another interesting point is that other than how we pick what requirements we are going to implement, the tasks on the iteration plans for iterations in Elaboration and Construction are nearly identical! There are some architectural tasks that we can skip in Construction, but overall the work is quite similar. The main difference is that the work in Construction is less risky as we’ve already created an architecture to follow and proved that it will work.

By the end of Construction, the product is complete, or as complete as we could make it, and provides the most amount of value possible.

Elaboration

Inception handles the risk of investing in a project that has no value. Therefore, if we get out of Inception and the project is still a go, we can be sure it has a strong business case.

Elaboration handles the risk of building a project whose technical architecture can not support the requirements for the system.

Many software projects fail due to selecting the wrong architecture. In Elaboration we must prove that our architecture is valid. In a waterfall project, the architecture is a “paper architecture” which means that it is sketched out and then we say we have defined our architecture.

The RUP requires that we create an “executable architecture.” This means that not only must we create our paper architecture, we must then prove that it works by selecting the highest risk requirements for the system, implementing them, and testing that they work correctly using the selected architecture. Also, by actually implementing part of the system we can determine if the paper architecture was correctly rendered (which in most cases it was not) and then improve it.

Elaboration has another purpose. In Inception we create a high level scope of our project and capture that in a Vision document. During Elaboration, we often discover that our Vision was not correct, and we adjust it based on what we learn during Elaboration. The customer, when they see the results of an iteration often need to adjust their request now that they better understand the solution. Also, the architects tend to learn a lot as well and also can reshape the Vision based on what is learned during the iteration as can other team members as well.

So, your project has entered Elaboration when we have proven it is of value. The project leaves Elaboration when the Vision has stabilized and the Architecture has been proven through a prototype that is tied to the real high risk requirements of the system.

I will cover the details on how to make this happen in part 2.

The RUP Phases: Inception

Ok, so now you should understand that a RUP project, software oriented or otherwise, should go through the four phases IECT. Also each phase can have one or more iterations that it guides. Let’s talk about what those phases mean.

Each phase was created for the RUP to handle a different type of project risk. Inception handles the risk of building a project that has no value to the organization. The term “Business Driven Development” is very popular, and gets at the idea that we have built far too many projects that don’t actually provide value.

As an example, I was at a Ship and Check, and wanted to know how much it would cost to ship a TV from Detroit to Phoenix. If the cost was too much (it would only cost about $250 to buy a new one) I was hoping to sell it. I noticed that the clerk looked up the cost in a large book. So, being in this line of work, I said “I’m surprised they haven’t automated that lookup.”

The man answered “It is. This computer right here can do it.”

So I, always the analyst, asked “Why don’t you use it then?”

“Well, it is actually faster to just use the book.”

Now there are lots of possibilities here. The problem could be a training issue (covered in the Transition phase of RUP), or it could be that the selected architecture was too slow to compete with a manual lookup (web based vs. stand alone client). But it also could be that the automation of the lookup really didn’t have value! It is possible that some executive said “Let’s automate that lookup.” Imagine the cost of creating the software correctly, then installing it in all the stores and training the folks to use it only to discover that no one does!

Many companies have created software that works as specified, but that provides no real business value back to the organization. The purpose of the inception phase is to get the team to quantify what the value of the project really can be, and to scope what needs to be done to get us to that value at a high level.

For the truly curious, it would have cost about $200 to ship the TV. I offered the TV to the ship and check clerk for $100 and he took it.

Phases and Iterations

Ok, you’ve taken the quiz, lets start defining the phases. You may have heard definitions before, but as promised, I believe that you will find a clearer definition here than you have found before!

First off, how do the phases relate to iterations? That was the topic of question 5. Basically, the best way to understand the phases is to first get rid of them altogether. A project can be iterative without following the RUP. Imagine that you decide, based on some criteria, that you want to try to build a complete product in nine iterations.

Each iteration, if you are truly doing iterative development, you would travel through all nine software disciplines (Project Management, Requirements, Analysis and Design, Implementation, Test, Deployment, etc.) in each iteration. Each iteration would result in a partial solution until the whole solution was at last available.

But a question usually comes up when people first look at this approach. “How do we select what we do in each iteration?” That is where the phases come in to play.

RUP can guide any project, even those that have NO software component. This is why they have an “implementation” discipline instead of a “coding” discipline. Implementation = coding if you are doing a software project. But if you are doing a non software project, implementation would be whatever it takes to go from detailed designs into a real tangible solution.

Basically every RUP guided project, software or otherwise, goes sequentially through a set of four phases. A phase is sequential and you can’t go backwards. These four phases are Inception, Elaboration, Construction and Transition. By understanding what happens in each phase, you can then understand how to choose what work to perform in each of your nine iterations.

At this point, it should be clear that the answer to question 5 is A, not B. In ‘A’ the project goes through each of the four phases once. In B, you go through the four phases again and again, and this is not possible.

For example, let’s imagine we are talking about a human’s life. Inception = Infancy, Elaboration = Teenager, Construction = Mid Life and Transition = Senior Citizen. If in your Mid Life, you realize you wished you did things differently when you were a Teen, you can take corrective action in your Mid Life, but you can’t go back to being a Teen!

There are two reasons people sometimes pick B. 1. They equate each iteration to a “generation” of the project that is to be externally released. Under this interpretation, each iteration is actually a full project, and each project goes through IECT.

2. They equate I to Planning and Requirements, E to Design, C to Code and T to Deployment. In each iteration you really do go through all those disciplines, but equating the RUP phases to waterfall phases is actually incorrect. More on why later, but this should tip you off that the answer to Q4 is actually No. I’ll provide more justification on that later too.

More iterative or more waterfall?

I often ask my clients about their current process when helping them transition to the RUP. One question I like to ask is this one: “Is your process more iterative or more waterfall like?” Some don’t know what waterfall means, so I explain it and they realize that they did know what a waterfall project is, but they just didn’t call it that.

Anyway a large portion of my clients say “we are more iterative.” When I hear this I like to follow up with these questions: “Do you do gather and detail all of your requirements at the beginning of the project, or do you gather and detail the requirements each iteration?” The usual answer is “well the requirements we do at the beginning or else we really couldn’t scope the project.”

The second question I like to ask is “do you do your system test on an actual executable product at the end of the project or during each iteration?” The usual answer is “well we do unit test each iteration, but you can’t do system test until the system is built at the end of the project.”

So they do their requirements at the beginning of their project, they do the system test at the end of their project, but they claim their process is more iterative than waterfall. What are they doing iteratively? Don’t confuse having builds with iterative development. It is not enough just to do the design and coding in iterations, it is the whole lifecycle that needs to be iterative.

A question that often comes up here is “if we don’t do all of our requirements up front, how can we manage the scope of our projects?” I’ll answer that question in a separate post.

Question 5

Which of these is the correct interpretation of RUP phases vs. iterations?

Imagine that you have a project that will be completed in nine iterations. We will refer to the nine iterations as I1, I2, I3… I9.

Which of the following would be a correct application of the RUP?

A.
Inception will have I1 and I2
Elaboration I3, I4
Construction I5, I6, I7
Transition I8, I9

Or B.
In I1 we go through Inception, Elaboration, Construction, Transition (IECT)
I2 again IECT
I3 IECT
I4 IECT
…
I9 IECT

So A shows that iterations belong to a single phase, while B shows that iterations consists of four phases each.

The Ultimate RUP Quiz

* Q1: Can you code in Inception?
* Q2: Is coding typical in Elaboration?
* Q3: Is writing detailed use cases typical in Construction?
* Q4: Is this a good approximation for explaining the RUP?
(RUP Phase) = (Waterfall Phase)
- Inception = Planning
- Elaboration = Requirements and Design
- Construction = Code
- Transition = Test and Deployment

So the quiz is really testing people’s understanding of the four phases of the RUP, Inception, Elaboration, Construction and Transition. I won’t answer the quiz right here so you can think about the answers and look for them later in the blog. Do your best to answer them, even if you don’t know the four RUP Phases. They do occur in chronological order, so you should be able to guess at the answers.

It is ok to be wrong. It is not ok not to play!

Do You REALLY Understand the RUP Phases?

Hundreds of my clients claim that they already understand the RUP. I always push on this because I find that most people who say they understand the RUP really don’t.

I have devised a fascinating quiz to help prove this point. It is fascinating because I have given it to literally over a thousand people and almost all have failed to get the questions correct! Yet I have also given it to IBM Rational Technical Specialists, and 100% of them have gotten 100% of the questions correct!

This tells me that the RUP is not great at communicating itself. I would love to be put in charge of fixing this problem, but in the meantime, this issue ensures that I will have lots and lots of work available to me helping folks to understand and adopt it. It is possible that no one could make it self adopting without consulting, but I’d like to imagine it could be done.

Ok so on to the quiz. The quiz consists of five questions. The first four questions are yes/no questions and the fifth (a newer addition to the quiz) is a pick choice A or B. These questions are NOT meant to be trick questions. The answers are obvious to those who know the RUP and a mystery to those that don’t.

When I give the quiz to Rational employees, the results are always interesting. If the colleague is new to the company, they hem and haw for a while but eventually, with lots of caveats, give me all the answers correctly. They are afraid to be the first internal person to get one wrong. But they don’t.

Meanwhile when I give it to a veteran colleague, they answer quickly and with an almost defiant air. Then they say, “and if you disagree, it is you that are incorrect in your interpretation of the RUP, Anthony.” Yet they give the same answers. The real difference is that they are confident in their understanding of the RUP!

OK, so here are the questions. Good luck! Oh and remember they are not trick questions. It is not “wordplay.” For example, when I say “typical” below, what I mean is that if you looked at 100 projects, most would have some characteristic.

Part 1: RUP Basics

One thing that often confuses people is that RUP is both a process and a product. I’d like to start by clarifying the difference between them.

When people first start looking at the products and services of IBM’s Rational brand, it seems overwhelming. But the RUP is the thing that ties it all together. All of the products, consulting services, instructor led and web based training that they offer are there to support the RUP’s six best practices. So basically if you understand the six best practices, you understand if Rational has a solution that could help you.

The six best practices are:
* Develop Iteratively
* Manage Requirements
* Use Component Architectures
* Model Visually
* Continuously Verify Quality
* Manage Change

So every product, service and training class in the Rational brand are there to help you succeed in these six areas, and the RUP process describes the approach to take to achieve this improvement.

The RUP product, on the other hand, helps to deliver the RUP process into the hands of the team. Basically the tool consists of four major parts.
* Process Delivery Tools
- Workflow
- Roles and Responsibilities
- Templates
- Examples
- Tool Mentors
- Guidelines
- Checklists
- Etc.
* Process Configuration Tools
* Process Authoring Tools
* Community Tools

The “Delivery Tools” get the RUP process into your hands by defining the workflow for nine different disciplines, such as requirements management, the roles and their responsibilities, templates for their artifacts, etc.

The “Configuration Tools” let you customize your version of RUP with your own process assets or with various RUP “plug ins” that center around other process or technologies, for example there are plug-ins for “XP,” “User Experience Development,” “COTS selection,” “J2EE development,” etc.

“Authoring Tools” allow you to create your own processes in the same style as the RUP and to create plug-ins like those listed above.

“Community Tools” are about the forums that exist (and even this blog!) to help you adopt the RUP successfully.

In this blog, I assume that you have access to the RUP tool. Even if you don’t I think you will derive huge value from the posts I put here, but to really maximize your chances of success, having a license of RUP will greatly help. And happily, it is the least expensive Rational tool by orders of magnitude.

Introduction (The First Post!)

This blog will help readers understand the Rational Unified Process. It will cover both how to use the RUP successfully on a project as well as how to deploy it in an organization. I plan to start with an introduction to iterative development, the most confusing part of RUP, then move into how to use it on a project, and then how to deploy it in an organization, however I will go whatever direction the blog seems to flow.

For the last six years I have worked for IBM Rational, helping customer to understand and adopt the RUP. In the last few years, I have introduced RUP to over 700 IBM Partners, to hundreds of IBMers during internal IBM educational events, and to attendees at the 2004 Rational Software Development Users Conference.

Now here's the thing. While many self proclaimed RUP experts have been thrown out of accounts due to an inability to show tangible results, over the last six years, I have had zero dissatisfied customers, and this is among literally thousands of software professionals as well as managers, directors, VPs and CxO level professionals. Because my approach to helping people understand the RUP is so unusual and so effective, hundreds of my colleagues and clients have asked when I will finally write a book.

This is where this blog comes in. I am at my best when I am teaching others about the RUP, rather than just narrating about it. So, I plan to start by sharing some great gems, but I am avidly hoping that questions will pour in allowing me to answer them in the blog, which is my best mode for communicating the RUP. Eventually I hope to then transfer all of that to a book.

Enjoy!