Writing the Development Case

In the Rational Unified Process, a Development Case is a description of how you will customize the process for your project. Even on this small, fairly well-defined project, we immediately decided that we wanted to use RUP to help guide us and keep us on track. But we were not interested in process for its own sake.

We started from the premise of Gary's Prime Directive: "Only do those activities and produce those artifacts that directly lead to delivering value to your customers and stakeholders." Another way to think about this directive is to ask "If I don't perform a particular process step, will anything bad happen?" (Read the "Process" section in Chapter 3.) It turned out that we didn't eliminate many RUP steps, but we took a much more informal approach than a larger project might have. For example, instead of creating formal artifacts, we had discussions or wrote informal documents.

As a small team, we were also interested in techniques from the agile community. So Gary and Chris did some pair programming when it was appropriate, and some test-first development (see Appendix C and the sidebar on Agility in Chapter 1), and were pleased with the results. We'll talk more about these points in a later chapter.

We wrote a brief development case using the RUP template. Our development case is available on the project Web site. It is longer than we would like. Most of the length is due to the RUP template. The first five-and-a-half pages contain introductory material and descriptions of how to read the rest of the document. Our team did not need this information, but we recognize that this part of the document can help someone new to the project, or any interested person, understand the purpose and format of the document.

We want to be clear that this is the way we decided to document our development case. You can choose to document, or not document, the parts of your development artifacts in whatever way is useful to your team. RUP provides templates that serve as examples and as possible starting points. You must decide what is right for your team.

The next sections describe the key features of our development case.

Conventions Used in the Development Case

Each project team tailors a development case for their project, even if there is a common development case for the larger organization. The Development Case template contains a section that lets you describe how you tailored the Development Case and identify the conventions you used to represent your process.

We focused on artifacts rather than activities; therefore, the main descriptive vehicle in our development case is a table that describes each artifact. Figure 4.1 shows its format.

Figure 4.1. Format for the artifact table in the Development Case

We created one artifact table for each RUP discipline we planned on using. RUP provides guidance for what to put into the table, but we chose our own style. So, in our Development Case, we described our conventions. These are shown in Table 4.1.

For each discipline, we included placeholders for notes and other issues in the artifact table. The real content that describes our planned process takes up about three pages in the Development Case document. Most of this space is occupied by tables like Figure 4.2, which shows our planned requirements artifacts.

Figure 4.2. Planned requirements artifacts

Table 4.1. Artifact table explanations

Column Name	Purpose	Contents/Comments
Artifact	The name of the artifact.	A reference to the artifact in RUP, or to a local artifact defined as part of the development case.
How to use	Describe how the artifact is used across the lifecycle.	Decide for each phase whether the artifact is produced or modified significantly. The possible values of this field are: C ” create in the phase. M ” modify in the phase. Blank ” not used or not changed in this phase.
Review details	Define the review level, and review procedures to be applied to the artifact.	Formal ” reviewed and signed off by the customer or relevant stakeholders. Informal ” reviewed by one or more team members . No sign off required. Blank ” no review required.
Tools used	Definition of the tool (or tools), used to produce the artifact.	References to the details of the tools used to develop and maintain the artifact.
Responsible	The role responsible for the artifact.	Describe which role, for example, Project Manager or Developer, is responsible for ensuring that the artifact is completed.

Role Map

Every project distributes responsibilities to team members differently. Few projects have a direct one-to-one mapping between roles described in RUP and actual people and jobs. Therefore, it is important to be clear about what each person is responsible for. On small projects, this is critical because there is a lower threshold to tolerate duplication of effort.

We recommend that every Development Case have a role map. Table 4.2 shows our initial role map. We simply took the different "Responsible" roles from the discipline artifact tables in the Development Case and created a row in the table for each one. Then we ensured that at least one person on the team was assigned to that set of responsibilities.

Table 4.2. Role map from the Development Case

	Liz	Chris	Jas	Gary
System Analyst			X
User -Interface Designer		X
Data Designer				X
Software Architect				X
Integrator				X
Implementer		X		X
Test Designer		X	X	X
Tester	X	X	X	X
Deployment Manager				X
Technical Writer	X
Configuration Manager				X
Project Manager				X
Process Engineer				X
Tool Specialist	X	X	X	X

This role map provided an initial guess about how the project would proceed. It helped us ensure that every responsibility was covered and it helped us decide whether anyone was overcommitted.

Artifacts in Our Development Case

You may wonder which artifacts we originally thought we would need to produce for our project. We identified over twenty that we thought would be helpful. We did not create all of them. As we progressed, we found that some of our early assumptions were wrong. Rather than create something just because we planned to do it, we chose to do the right thing and create only those artifacts that were truly helpful.

If you download the material from the book's Web site, you can compare our original Development Case to the following list of those artifacts that we actually produced.

• Vision

• Risk list

• Use-case model

• Design model

• Build

• Component

• Test plan

• Test case

• Test results

• Product (the complete system as it is delivered to the customer)

• Release notes

• End-user support materials

• Iteration plan

• Iteration assessment

• Project plan

• Development case

• Programming guidelines

• Tools

You would probably produce all these artifacts for any project you undertake. You might not produce volumes of paper, diagrams, or data, but you would produce the artifacts in some form. In some cases, there may be existing artifacts that you can just reuse, for example, Tools or Programming guidelines.

Importance of the Development Case

Some people think the Development Case is an important artifact in RUP and others think it should just be part of the project plan. Our thoughts on the Development Case are somewhere in between.

We believe that the Development Case is necessary. Team members need to understand their responsibilities. They need to know what they are expected to produce, what artifacts will be available for their use, and the form of the artifacts. The real question is how much time and effort you should spend creating and maintaining the Development Case.

Our advice is simple. If you have a small team, especially one that has worked together before and has a shared understanding of the process, then the Development Case can be an oral artifact. That is, it can be communicated to the team via discussions. The further you stray from a small, familiar team ”whether in terms of size of the team or team members' lack of familiarity with each other or the common process ”the more you need to write your Development Case and keep it up to date.

We probably did not have to write down our Development Case. The hour or so that it took was not totally lost, though. It gave our team a good topic of conversation for early meetings.