Activity:  Develop Development Case

A development case is developed to be used in a software-development project.

The project's phase plan and organization has a major impact on the process, and vice versa. Therefore, the development of the development case must be coordinated with development of the project plan. See the Artifact: Software Development Plan, section "Project Plan", for more details. For example, if the project decides to use a different set of phases than in the Rational Unified Process (RUP), this is something that needs to be captured in the development case.

The project's choice of configuration items also has a major impact on the process, and vice versa. Therefore, the development of the development case must be coordinated with development of the configuration management plan. The configuration items are defined in the configuration management plan. See Artifact: Configuration Management Plan and Concepts: Product Directory Structure.

Analyze the Project and the Organization

The Artifact: Development-Organization Assessment contains information about the project and the organization. Analyze the factors to decide how they should affect the development case. See the Guideline: Process Discriminants for guidelines on how the main factors influence the choice of process.

Define Scope

Define which disciplines to cover in the development case, by looking at the following aspects of the Development-Organization Assessment:

• Areas where the project members already have a common way of working, where it is not necessary to introduce a new process and tools. For example, if they know how to test, it can be a good idea to not introduce the Test discipline of the RUP to limit the number of new factors. You can focus on introducing some parts of the RUP, to correct problems in their existing process.  See Concepts: Implementing a Process in a Project, section "Improving Process and Tools", for details. 
• Areas (disciplines) where the project must introduce new process and tools, because there is no existing way of working. In some cases there is no existing process and tools to fall back on, and it is necessary to introduce most of the RUP, together with supporting tools. See Concepts: Implementing a Process in a Project, section "Change Everything", for details. 
• Problems in the existing process. Focus on improving in areas in which the organization has had problems.
• Which tools they plan to use. If the project has decided to use certain tools, the development case should normally cover the corresponding areas of the RUP.
• The project's capacity to change. When looking at the organization's problems there is a tendency to try to fix everything at once, especially since many of these problems occur together. This is usually a fatal trap. Organizations just like individuals can accommodate change but only within a limited range. If the capacity to change is low, you have to go slower, and maybe just introduce one or two disciplines of the RUP in the first project.
• Areas where the project's members lack knowledge, or are weak. Let the development case cover these areas. Make sure that it is easy to find the right information in the RUP.

We recommend that you implement the RUP iteratively, as described in the Concepts: Implementing a Process in a Project. The Development Case does not have to capture the entire process. Be prepared not to cover all disciplines; skip disciplines and delegate process responsibility; see "Delegating Process Responsibility" in Guidelines: Development Case.

Document the result in the section "Scope" in the Development Case.

Decide How to Perform Each Discipline

Once you have decided which disciplines you need to introduce, decide the following for each: 

• How to perform the workflow. 
• Which parts of the workflow should be used. 
• When, during the project's lifecycle, to introduce the workflows and their parts. 

To help you decide, there are is a section "Decide How to Perform the Workflow", in each of the following guidelines:

• Guidelines: Important Decisions in Business Modeling
• Guidelines: Important Decisions in Requirements
• Guidelines: Important Decisions in Analysis & Design
• Guidelines: Important Decisions in Implementation
• Guidelines: Important Decisions in Test
• Guidelines: Important Decisions in Deployment
• Guidelines: Important Decisions in Project Management
• Guidelines: Important Decisions in Configuration & Change Management
• Guidelines: Important Decisions in Environment

When you consider introducing a particular discipline, or part of one, take the following into account:

• Applicability. Is it applicable for the project? Does it really add value to introduce it?
• Problems and root causes addressed. Does it address any of the perceived problems and their root causes?
• Tool support. What tool support is needed?
• Timing. When during the project's lifecycle should it be introduced? See Concepts: Implementing a Process in a Project, for more information.
• Cost of implementing. What is the cost of implementing it in the project? This includes:
  • Cost to train project members. 
  • Cost to install the supporting tools.
  • Cost to develop guidelines and templates.

Tailor Artifacts per Discipline

Tailor the artifacts for each of the disciplines. See Guidelines: Tailoring the Process.

Don't do all of the disciplines at once–focus on the next one to be applied in the project. Perform the following steps:

1. Decide how the artifact (modeling element or document) should be used (see Guidelines: Classifying Artifacts for more information):
   • Must have.
   • Should have
   • Could have
   • Won't have
2. Decide the review level for each artifact and capture it in the "Review Details". For details see Guidelines: Review Levels. Decide how to review each artifact; that is, which review procedures to use. 
3. Decide how you should capture the final results of a discipline. Do you need to store the results on paper? If so, you have to decide on one or several reports that extract the results from the tools, and capture the results on paper. 
4. Decide which tools to use to develop and maintain the artifact.
5. Decide which properties to use and how to use them. See the Properties table for each artifact and the section titled "Tailoring" of each artifact.
6. When relevant, decide which stereotypes to use. For each artifact, see the section titled "Tailoring."
7. Decide on an outline for the document artifacts. For the respective artifact, see the section titled "Brief Outline."

In addition to these steps you should also:

• Decide which reports to use. Decide if you need any work reports to extract information from models, then document the information on paper for reviews. These work reports are usually treated as casual since they are temporary and will be discarded as soon as the review is complete. See "Reports" for example of several predefined reports you can use. You may need to tailor the outline.

There are more things to decide for each discipline. See the guidelines for each discipline for more details:

• Guidelines: Important Decisions in Business Modeling
• Guidelines: Important Decisions in Requirements
• Guidelines: Important Decisions in Analysis & Design
• Guidelines: Important Decisions in Implementation
• Guidelines: Important Decisions in Test
• Guidelines: Important Decisions in Deployment
• Guidelines: Important Decisions in Environment
• Guidelines: Important Decisions in Project Management
• Guidelines: Important Decisions in Configuration & Change Management

Modify Disciplines and Activities

Study the modified set of artifacts and the activities that use, create and update these artifacts. Decide whether you should modify or simplify these activities. Note that for each activity input and output artifacts are indicated. Be sure to delete any unnecessary step or activity. Consider the following:

• Introduce new steps and possibly new activities to reflects the artifacts, reports, and documents that you have had to add.
• Examine how the tools used can facilitate, automate, or even suppress some of the steps.
• Introduce into the activities any specific guidelines and rules inherited from the organization's experience. They may be added as guidance points, checkpoints, review items, or left as separate documents that can be referenced.
• Once the activities are known, revisit the workflows that show how activities interplay, removing or adding activities as necessary.
• Whole disciplines can be omitted or created.
• You may have to introduce some additional roles to take care of special activities requiring specific skills.

Describe the changes in the Development Case.

Choose Lifecycle Model

Choose the kind of lifecycle model the project should employ. Refine the RUP model and adjust milestones and the milestone evaluation criteria if necessary. You may even decide to omit one or several of the phases, or add or remove milestones. See Phases and Concepts: Iteration for more information and ideas. Document the project's lifecycle model in the section "Overview of the Development Case".

Describe Sample Iteration Plans

Describe at least one sample iteration plan (more likely you will describe several) for each phase. These iteration plans describe how the project will work in different iterations and phases of the project. The purpose of sample iteration plans in the development case is to describe which activities your project will perform, and in which order. As such it can serve as a more detailed iteration plan. The sample iteration plan is important as a way for team members, to understand how the process will be applied.

The description of the sample iteration plan should be brief. Do not include details that belong in the activities, artifacts and guidelines. You can choose to describe the sample iteration plan in terms of activities or workflow details.

These iteration workflows can be captured textually (or graphically), as in the sample iteration plans that are part of the RUP (see Phases).

In most cases you should describe at least one sample iteration plan per phase. Describe the sample iteration plans as they are needed; there is no reason to describe how to work during the Transition phase at the beginning of a project. Start by defining how the project will work in the Inception phase.

Identify Stakeholders

The role Stakeholder represents all possible stakeholders to a project. You need to identify and describe the different types of stakeholders, their needs and responsibilities. Examples of different stakeholders are customer representative, user representative, investor, production manager, and buyer.

Describe the different stakeholders and their needs in the development case, in the section "Roles".

Map Roles to Job Positions

In some development organizations there are job positions defined. If these job positions are commonly used and have a wide acceptance within the organization, it may be worth doing a mapping between the roles in the RUP, and the job positions in the organization. Mapping job positions to roles can make it easier to make people in the organization understand how to employ the RUP. The mapping can also help people understand that roles are not job positions, which is a common misconception. Document this mapping in the development case, section "Roles".

Document the Development Case

Describe the development case. We recommend that you describe the development case on one or several web pages, with hyperlinks to the RUP online, and to other guidelines. This is explained in the section "Representing a Development Case Online" in Guideline: Development Case. Use the Example: Development Case as a starting point. See also, Toolkit: Creating a Development Case Using the Rational Unified Process, and Toolkit: Authoring Web Pages.

Maintain the Development Case

Many of the decisions should be made before the project starts. After each iteration in the software-development project you should evaluate the process, and reconsider the decisions you have made. If a new version of the RUP is released you need to update the development case. This is explained in the Toolkit: Upgrading the Rational Unified Process.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process