Instantiating the RUP in a Project

Each project needs to decide how to instantiate, that is, how their project should apply their RUP Process Configuration. Your RUP Configuration may contain more artifacts than you will produce in your specific project, and the project team needs to understand which of those artifacts to produce and how to capture the information ”in a document, in a tool, or on a whiteboard as a throw-away artifact. This type of information is documented in a development case. Make sure that the process you instantiate is streamlined ”that is, it is at as low a level of ceremony as is suitable for your needs (see Chapter 3). A common mistake is to instantiate a process at a level of ceremony that is too high, adding more formalism to your project than may be required. Add just enough ceremony to ensure success, but not so much that it slows you down.

A RUP Development Case

A development case is an artifact that provides specific guidance for a project or for a set of projects with very similar characteristics, regarding exactly which artifacts your project should produce, which tools or templates will be used, when to produce them, and with what level of formality . A development case may also specify who in your project takes on what roles in the RUP approach, which can make the development case a key artifact supporting an effective instantiation of the RUP Configuration for your specific project.

Note that the development case does not contain any information on how to produce an artifact, thus repeating what is in the RUP. Rather, it links to the RUP Configuration used by your project, which in turn provides information on how to produce an artifact. This allows a development case to be quite brief (normally four to eight pages long) and therefore produced quickly. We recommend that your development case contain, at minimum, a brief list describing one stereotypical iteration for each of the four phases ”Inception, Elaboration, Construction, and Transition ”and that it indicate what artifacts are produced, their level of formality, and how they should be reviewed. Figure 10.3 shows an example of such a list, which indicates what artifacts should be produced and with what formality they should be reviewed. For guidance on what the artifact is and how to produce it, you follow the link, which will lead you to your RUP Configuration.

Figure 10.3. Development Case ”Artifacts and Formality. A development case is a project artifact specifying what artifacts to produce, at what time, and with what formality. It may also specify additional information such as what templates to use and how to review the artifact.

A development case specifies, in detail, which subset of artifacts within your RUP Configuration should be produced. For example, your RUP Configuration may provide guidance on two artifacts, Stakeholder Requests and Vision, but you may decide to use only the Vision document in your project. Your development case should specify that you produce a Vision document during Inception and list how formally it should be developed and by whom it should be reviewed. Since you do not plan to produce a Stakeholder Request document, the development case will not list it ( optionally , you could have your development case specify that Stakeholder Request documents should not be produced).

Figure 10.4 presents another extract from a development case. It shows who is playing what role in the project. Again, when you click on a role, you are brought to your RUP Configuration Web site for a description of the different roles.

Figure 10.4. Development Case ”Roles. A development case may specify staffing information, such as who in the project takes on what role(s) in the RUP .

You should consider doing a very simple development case for your first project; the greatest value normally comes from the initial four to eight hours of investment. The RUP provides templates allowing you to rapidly produce a development case for your project. There is also great value in doing frequent updates to the development case, perhaps at the end of each iteration, or at least at the end of each phase. This approach allows you to improve the process you follow based on experiences gained . At the end of each project, you should also consider updating a development case template to incorporate feedback from your project, for use on future projects producing similar development cases. Too often, we have seen process engineers spending weeks and weeks on a development case before they get started with the first project. Writing a good development case is like developing software: You will not get it right the first time, so make a small investment first, try it out, improve it, try it out again, and so on.

Naturally, there are some cases where it is well worth the investment to spend a few weeks to produce a good development case. In large projects, where confusion about what process to follow can be very costly, or for systems where a high degree of discipline is necessary to comply with regulations, or wherever quality is crucial ”in these cases the extra time can yield high dividends downstream.

Project Web Site

All project members should have easy access to a development case. One way to achieve this is to have a project Web site providing one point of access for all your project information, including staffing information, meeting minutes, links to relevant information, links to artifacts that have been produced, information about when you are doing certain types of builds, and so on. We also recommend that the project Web site include your development case so it will be readily available for all project team members . And you should create a link to your project Web site in each team member's Process View. When developing a project Web site, you may want to use the Project Web Template that comes with the RUP product as a starting point.

Alternatively, you should consider using Rational ProjectConsole, which is a Rational Suite component that will automatically extract information from Rational tools and third-party tools to build a project Web site for you with information about all current artifacts. Rational ProjectConsole will also present advanced metrics, allowing you to analyze the data. It comes with suggested metrics and reports for each of the four phases in the RUP approach.

The project Web site will provide links to your RUP Configuration as appropriate. This allows you to change the underlying RUP Configuration with a minimum impact to the development case (see Figure 10.5). You may find that a few of the hyperlinks no longer work or that you need to add or remove a few artifacts in your development case to reflect the changed configuration, but typically these changes will take only a few minutes to implement ( assuming that your development case is not too extensive ).

Figure 10.5. Project Web Site in Rational ProjectConsole. Rational ProjectConsole can automatically generate a current project Web site, providing one point of access for all your project information, including development case, meeting minutes, and links to artifacts that have been produced.

Alternatives to Producing a Development Case

Producing a development case ensures that your team members have a clear understanding of exactly which artifacts should be produced, when they should be produced, by whom, and how they should be reviewed. However, this information can be distributed in other ways. A project manager or mentor may tell project members what to do and how to review artifacts, or project members may consult the project plan to understand what they are supposed to deliver. They can then go to the RUP Configuration to understand how to do the work. Especially for smaller projects with an experienced mentor, these alternative approaches can work well.