Activity: Develop Development Case

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

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.

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

Tailor Artifacts per Workflow

Tailor the artifacts for each of the core process workflows. However, don't do all of the workflows at once–focus on the core process workflow that is next to be applied in the project. Perform the following steps:

1. Decide how the artifact (modeling element or document) should be used:
   • To be skipped: this artifact is not required in this specific process.
   • Casual: this artifact is created and used as work information, it is not reviewed and approved by anyone because it is often a temporary artifact that is discarded after the project is complete.
   • Informal: the artifact is used in the process but it is informal. It is not delivered, and maybe never defined on paper, but someone has approved it.
   • Formal-Internal: the artifact is formally produced and used internally at a specific milestone.
   • Formal-External: the artifact is part of a delivery at a specific milestone, and requires some form of approval by the buyer, the customer, or some other external stakeholder.
2. Decide how you should capture the final results of a core process workflow. 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 tools, and captures the results on paper. These reports are usually treated as formal-internal, or formal-external.
3. Decide which tools to use to develop and maintain the artifact.
4. Decide which properties to use, and how to use them. See the Properties table for each artifact, and the section "Tailoring" of each artifact.
5. When relevant, decide which stereotypes to use. For each artifact, see the section "Tailoring."
6. Decide on an outline for the document artifacts. For the respective artifact, see the section "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, and 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.  
• Decide which configuration items to have.
• Decide how to review artifacts and approval criteria.

Exactly what decision to make differs between core process workflows. See the guidelines for each core process workflow 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

Modify Core Process Workflows 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 theses 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.
• In some rare cases, whole a whole core process workflow can be omitted or created.
• You may have to introduce some additional workers to take care of special activities requiring specific skills.

Describe the changes in the Development Case.

Describe Iteration Workflows

Describe at least one iteration workflow (more likely you will describe several). These iteration workflows will describe how the project will work in different phases of the project. The purpose of iteration workflows 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 iteration workflow is important as a way for team members, to understand how the process will be applied. The Project Plan (and possibly the Iteration Plan) is a necessary input to be able to describe iteration workflows.

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

These iteration workflows can be captured textually (or graphically), as in the sample iteration workflows that are part of the Rational Unified Process (see the overview of the "Iteration Workflows").

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

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 Rational Unified Process online, and to other guidelines. This is explained in the section "Representing a Development Case Online" in Guideline: Development Case. Use the Guideline: Development Case Sample as a starting point. See also, Tool Mentor: 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.