Project ABC—Development Case

This is an example of what a development case may look like. There is no point in restating information already in the process. What you have to describe are the deviations from the process. You may put together a Development Case that contains a small description of the process. However, the problem with that kind of document is that they tend to grow forever, until they're the size of the process handbook! 

This example is intended to give you an idea about how a development case would look for a small project, let's say a commercial information system.

For more information about the Development Case, its contents, and outline, see Artifact: Development Case.

Topics

• Introduction
  • Revision History
  • Purpose
  • Definitions, Acronyms and Abbreviations
  • References
• Overview of the Development Case
  • Lifecycle Model
  • Disciplines
  • Discipline Configuration
  • Artifact Classification
  • Review Procedures
  • Sample Iteration Plans
• Disciplines
  • Business Modeling
  • Requirements
  • Analysis & Design
  • Implementation
  • Test
  • Deployment
  • Configuration & Change Management
  • Project Management
  • Environment
• Roles

Introduction

Revision History

Purpose

The purpose of the document is to describe the development process for the project ABC.

Definitions, Acronyms, and Abbreviations

Not applicable.

References

Not applicable.

Overview of the Development Case

Lifecycle Model

See the section titled "Project Plan" in the project's Software Development Plan.

Disciplines

The development-case example presented here takes you through all nine disciplines: Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management, and Environment.

Discipline Configuration 

The purpose of this section is to explain how the discipline configuration works. This includes the purpose of the different tables and sections that describe each workflow in the section titled "Workflows".

Section: "Workflows"

This section details any changes made to the structure of the workflow itself. Typical changes include the addition of activities to describe company-specific ways of working or the removal of activities from the workflow.

Section: "Artifacts"

The section describes, in a table, how the artifact will be used. Additional 'local' artifacts can be added to the table as needed. 

Section: "Notes on Artifacts"

This section has three main purposes: 

• It contains a list all artifacts you Won't use and the motives behind your decision not to use them. 
• It contains a reference to the project's Configuration Management (CM) Plan, which describes the configuration management strategy used when working on these artifacts. The CM Plan allows developers to answer questions such as: 
  • When do I release my artifact? 
  • Where do I put my newly created or modified artifact?
  • Where do I find existing artifacts for the project?
• If the development case is an organization-level development case, this is where you add notes on what each project needs to consider when they decide what to do with the artifact. Use the predefined table below as a starting point.

Section: "Reports"

This section lists the reports to be used and additional 'local' reports can be added to the table as needed.

Section: "Notes on the Reports"

This section has two main purposes. First, it lists all reports that the project has decided it Won't use, and the motives behind its decision not to use them. Secondly, if the development case is a an organization-level use case, this is where to add notes on what each project needs to consider when they decide what to do with the report.

Section: "Additional Review Procedures"

This section captures any additional review procedures required for the artifacts used in the discipline. These supplement the general review procedures described in the "Overview" section of the Development Case.

Section: "Other Issues"

This section captures any outstanding issues with the discipline's configuration. This section can be used as an Issues List while building the development case.

Artifact Classification

An artifact is a deliverable of the process. It is often developed within one discipline, although there are exceptions. The artifacts are organized in the discipline where it's created. To describe how an artifact will be used, consider the following classification scheme and see Guidelines: Classifying Artifacts for details:  

• Must
• Should
• Could
• Won't

Review Procedures

The project uses the following review levels: 

• Formal-External
• Formal-Internal
• Informal
• None

For details, see Guidelines: Review Levels.

Sample Iteration Plans 

Inception Phase

• Sample Iteration Plan: Inception Phase

Elaboration Phase

To be defined later in the project.

Construction Phase

To be defined later in the project.

Transition Phase

To be defined later in the project.

Disciplines

Business Modeling

Workflow

Follow the Domain Modeling workflow detail only. See Business Modeling: Overview.

Artifacts

Notes on the Artifacts

See the project's Configuration Management Plan for information on how the artifacts are 
configuration-managed.

The project decided to only perform domain modeling, which means that the following artifacts will not be developed: Business Actor, Business Architecture Document, Business Rules, Business Use Case, Business Use-Case Model, Business Vision, Business Worker, Organization Unit, and Supplementary Business Specification.

Reports

Requirements

Workflow

No changes. For details see the Requirements Overview.

Artifacts

Notes on the Artifacts

See the project's Configuration Management Plan for information about how the artifacts are 
configuration-managed.

Reports

Analysis & Design

Workflow

A real-time application is not being developed, therefore the Capsule Designer role and the activity Capsule Design are excluded. For details on the workflow, see the Analysis & Design Overview. 

Artifacts

Notes on the Artifacts

The project is not developing a real-time product, which means that the following artifacts will not developed: Capsule, Event, Protocol, and Signal.

The project decided not to keep an analysis model, which means that the following artifacts will not be developed: Analysis Class and Analysis Model. 

Reports

Implementation

Workflow

No changes in the workflow. For details see the Implementation Overview.

Artifacts

Additional Review Procedures

Informal code reviews are performed. 

Test

Workflow

No formal performance test is done, otherwise the workflow is followed unchanged. For details on the process, see the Test: Overview.

Artifacts

Notes on the Artifacts

No Workload Analysis Document is developed.

Additional Review Procedures

• Test cases—informally approved by the system testers.
• The system testers decide if the test criteria for an iteration is fulfilled.
• The customer approves the final iteration.

Deployment

Workflow

A previously existing deployment workflow was adapted to use the artifacts suggested in the RUP. An exception is the Course Material artifact, which is excluded because no formal training is produced for our product.

Artifacts

Notes on the Artifacts

No Training Materials are developed because the product does not require formal training. 

Reports

Configuration & Change Management

Workflow

No changes in the workflow. For details on the process, see the Configuration & Change Management: Overview.

Artifacts

Project Management

Workflow

No changes to the workflow. For details, see Project Management: Overview.

Artifacts

Notes on the Artifacts

The artifact Work Order won't be used. 

Environment

Workflow

No changes in the workflow. For details on the process, see the Environment: Overview.

Artifacts

Roles

Not applicable.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process