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.