No Frozen Artifacts

To simplify planning and to give a feeling of achievement or progress, there is also a temptation to try to complete a RUP artifact (model, document, code) in one shot, within one phase, or even within one single iteration, and to freeze it. "Let's build the requirements, have them 'signed off,' and be done with it." Or "The design is now complete."

There is nothing wrong with doing a perfect job early and not having to revisit an artifact. It is good that some artifacts become stable as you progress. But the objectives of the phases are not described in terms of finishing an artifact, but bringing it to the right level of maturity to be able to make the correct decisions about it. As the project evolves and more is understood about the objectives, as difficulties are discovered , and as external changes are introduced, artifacts have to be revisited, updated, and corrected. Therefore, activities that have already been run have to be re-executed. And having gone much too far in polishing an artifact too early may actually lead to much rework later on.

The Vision and the Business Case will be developed during Inception and hopefully will be stable through the end of the cycle. The requirements are built gradually over Inception and Elaboration and should be complete by the end of the Elaboration phase. The architecture will be designed or selected gradually and should be stable enough by the end of the Elaboration phase. But these artifacts are not sacred and untouchable. You may have to alter the Vision, modify the requirements, or change the architectural design in later phases.

And as we wrote earlier, although all the artifacts described in the RUP could potentially play a role in a project, you do not need to develop all the artifacts in your project. Moreover, for a specific kind of artifact, use cases (UCs), for example, you may choose to develop some completely because they are delicate and risky, but not others, which can remain in the form of short descriptions because they are trivial or very similar to existing ones. For example, not all use cases are equally important and critical for the success of the project, and you may decide not to fully develop the description of minor ones.