Activity: Develop Development Case

A development case is developed to be used in a software-development project and is consider part of the project-specific process. It is a refinement of the development process configured for the project, see Artifact: Development Process for further information.

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.

Decide How to Perform Each Discipline

Part of tailoring the RUP framework for use on a specific project is to decide on which disciplines to introduce. As described in Activity: Tailor the Process for the Project, you should avoid using all of RUP in one single project. And if your project is fairly new to the practices described in the RUP, you should concentrate on limiting the number of unknown factors to a handful, to ease the transition of the teams onto a new process platform.

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

Select the right set of artifacts for the project to produce. Just because an artifact is part of the configured process, doesn't mean that the project has to produce it. The configuration is often defined over a selection of process components, not at the level of individual artifacts. Typically, your development case should define a subset of the artifacts you'll find in the process Website.

If you cannot clearly articulate why the artifact should be produced, for example if no external stakeholder has requested it, then consider to exlude it. It is a good practice to use the development case to document any deviations from the underlying process, so exclusion of any artifact should be justified and documented.

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

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. 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:

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 Iterations

Describe at least one sample iteration (more likely you will describe several) for each phase. These iteration descriptions describe how the project will work in different iterations and phases of the project. The RUP suggests two different ways of defining sample iterations. One approach is to define cross-discipline example iteration workflows, see Key Concept: Iteration Workflow for a definition, or see the different phase descriptions under the RUP Lifecycle page for detailed examples. The other approach is to define a set of sample iteration plans.

The purpose of describing sample iterations in the development case is to communicate to the project teams, which activities your project will perform, and in which order. As such it can serve as a more detailed iteration plan. The description of the sample iterations should be brief. Do not include details that belong in the activities, artifacts and guidelines. You can choose to describe the sample iterations in terms of activities or workflow details. Workflow detail based descriptions can be easier to use for planning and control at the management level, but activity based descriptions are preferred when using them at the practitioner level.

In most cases you should describe at least one sample iteration per phase. Describe the sample iterations 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.

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 underlying configuration is released, you need to update the development case.

Rational Unified Process