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 To top of page

Revision History To top of page

Date

Version

Description

Author

01/01/2000

1.0 - Tom Smith

 

Purpose To top of page

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

Definitions, Acronyms, and Abbreviations To top of page

Not applicable.

References To top of page

Not applicable.

Overview of the Development Case To top of page

Lifecycle Model To top of page

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

DisciplinesTo top of page

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  To top of page

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. 

Artifacts How to use Review Details Tools used Templates/
Examples
Incep Elab Const Trans
               

Explanation of the table

Column Name Purpose Contents/Comments
Artifacts To name of the artifact  A reference to the artifact in the Rational Unified Process (RUP) or to a local artifact definition that's held as part of the development case. 
How to use To qualify how the artifact is used across the life cycle For each phase, decide on: 
  • Must haves
  • Should haves
  • Could haves
  • Won't haves

These are defined in the Guidelines: Classifying Artifacts.  

Review Details To define the review level and review procedures  applied to the artifact.  Decide on the review level: 
  • Formal-External
  • Formal-Internal
  • Informal
  • None

For details, see Guidelines: Review Levels.

Also add a reference to the definition and detail of the relevant review procedures. The reference could point to either the RUP or to the section titled "Review Procedure" in the development case. More specific review procedures are defined in the discipline's "Additional Review Procedures" sub-section.

Tools used To define the tool or tools used to produce the artifact. References to the details of the tools used to develop and maintain the artifact.
Templates/Examples To provide the templates to be used and examples of artifacts that use the templates. References to templates and examples. This could refer to either the templates and examples in the RUP or local templates and examples. This column may also contain references to actual artifacts that provide additional help to project members.

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.
Artifacts How to Use Reason
 
 
 

Section: "Reports"

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

Reports How to use Templates/Examples Tools Used
   
 
 

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 To top of page

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 To top of page

The project uses the following review levels: 

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

For details, see Guidelines: Review Levels.

Sample Iteration Plans  To top of page

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 To top of page

Business Modeling To top of page

Workflow

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

Artifacts
Artifacts How to use Review Details Tools used Templates/
Examples
Incep Elab Const Trans
Business Entity

Must

Could

Could

Could

Formal-External

Rational Rose

 
Business Glossary

Must

Could

Could

Could

Formal-External

Rational Rose

 
Business Analysis Model

Must

Could

Could

Could

Formal-External

Rational Rose

 

Target-Organization Assessment

Must

Could

Could

Could

Formal-External

Rational Rose

 

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, Business System, and Supplementary Business Specification.

Reports
Reports How to use Templates/Examples Tools Used
Business Entity Could

 

Microsoft Word

Business Analysis Model Survey Could

 

Rational SoDA
Microsoft Word


Requirements To top of page

Workflow

No changes. For details see the Requirements Overview.

Artifacts
Artifacts How to use Review Details Tools used Templates/
Examples
Incep Elab Const Trans
Actor

Must

Must

Must

Must

Informal

 

 
Glossary Must Must Must Must Formal-External    
Requirements Attributes Must Must Must Must Formal-Internal    
Requirements Management Plan Must Must Must Must Formal-
Internal
   
Stakeholder Requests Must Must Must Must Formal-External    
Software Requirements Specification Must Must Must Must Formal-External    
Supplementary Specification Must Must Must Must Formal-External    
Use Case Must Must Must Must Formal-External    
Use-Case Model Must Must Must Must Formal-External    
Use-Case Package Must Must Must Must Informal    
Use-Case Storyboard Won't Must Could Could Informal    
User-Interface Prototype Won't Must Could Could Formal-External    
Vision Must Must Must Must Formal-External    

Notes on the Artifacts

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

Reports
Reports How to Use Templates/Examples Tools Used
Actor Could    
Use-Case Could

 

     
Use-Case Model Survey Could

 

 

Use-Case Storyboard Could    

Analysis & Design To top of page

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
Artifacts How to use Review Details Tools used Templates/
Examples
Incep Elab Const Trans
Data Model Won't Could Could Could Informal Rational Rose  
Deployment Model Could Must Must Must Formal-
Internal
Rational Rose  
Design Class Could Must Must Must Informal Rational Rose  
Design Model Could Must Must Must Formal-
Internal
Rational Rose  
Design Package Could Must Must Must Formal-
Internal
Rational Rose  
Design Subsystem Could Must Must Must Formal-
Internal
Rational Rose  
Interface Could Must Must Must Formal-
Internal
Rational Rose  
Reference Architecture Could Must Must Must Formal-
Internal
Rational Rose  
Software Architecture Document (SAD) Could Must Must Must Formal-
External
Rational SoDA
Microsoft Word
 
Use-Case Realization Could Must Must Must Informal Rational Rose  

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
Reports How to Use Templates/Examples Tools Used
Class Could   Rational SoDA
Microsoft Word
Design-Model Survey Could   Rational SoDA
Microsoft Word
Design Package/Subsystem Could   Rational SoDA
Microsoft Word
Use-Case Realization Could   Rational SoDA
Microsoft Word

Implementation To top of page

Workflow

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

Artifacts
Artifacts How to use Review Details Tools used Templates/
Examples
Incep Elab Const Trans
Build Could Must Must Must Informal Microsoft® Visual Basic®  
Implementation Element Could Must Must Must Informal

Code reviews

Microsoft Visual Basic  
Implementation Model

Could

Must

Must

Must

Informal

Microsoft Visual Basic

 
Implementation Subsystem

Could

Must

Must

Must

Formal-
Internal

Microsoft Visual Basic

 
Integration Build Plan Could Must Must Must Formal-
Internal
Microsoft Word  

Additional Review Procedures

Informal code reviews are performed. 

Test To top of page

Workflow

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

Artifacts
Artifacts How to use Review Details Tools used Templates/
Examples
Incep Elab Const Trans
Test Plan Could Could Must Must Informal Microsoft Word  
Test-Ideas List Won't Could Must Must Informal Microsoft Word  
Test Case

Won't

Could

Must

Must

Informal

Microsoft Word

 
Test Data

Won't

Could

Must

Must

Informal

Rational Rose

 
Workload Model

Won't

Could

Must

Must

Informal

Rational Rose

 
Test Class

Won't

Could

Must

Must

Informal

Rational Rose

 
Test Components Won't Could Must Must Informal Microsoft Visual Basic  
Test Results Won't Could Must Must Informal Microsoft Word  
Test Evaluation Summary Won't Could Must Must Informal Microsoft Word  
Test Suite Won't Could Must Must Informal Rational Rose  
Test Script Won't Could Must Must Informal Rational TestStudio  
Test Environment Configuration Won't Could Must Must Informal Rational Rose  
Test Automation Architecture Won't Could Must Must Informal Rational Rose  
Test Interface Specification Won't Could Must Must Informal Rational Rose  

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 To top of page

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
Artifacts How to use Review Details Tools used Templates/
Examples
Incep Elab Const Trans
Bill of Materials

Won't

Won't

Could

Must

Formal-
Internal

Microsoft Word

 
Deployment Plan

Won't

Could

Must

Must

Informal

Microsoft Word

 
Deployment Unit

Won't

Could

Could

Must

Informal

Microsoft Word

 
Support Material

Won't

Could

Could

Must

Informal

Microsoft Word

 
Installation Artifacts Won't Could Could Must Informal

Microsoft Word

 
Product Won't Could Could Must Formal-
External
   
Product Artwork Won't Could Could Must Informal

Microsoft Word

 
Release Notes Won't Could Could Must Formal-
Internal

Microsoft Word

 

Notes on the Artifacts

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

Reports
Reports How to Use Templates/Examples Tools Used
   
 
 

Configuration & Change Management To top of page

Workflow

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

Artifacts
Artifacts How to use Review Details Tools used Templates/
Examples
Incep Elab Const Trans
Change Request

Won't

Could

Must Must Informal

Rational ClearQuest

 
Configuration Audit Findings

Won't

Could

Must

Must

Informal

Microsoft Word

 
Configuration Management Plan Won't Must Must Must Informal

Microsoft Word

 
Project Repository Won't Could Must Must None Rational ClearCase  
Workspace Won't Could Must Must None Rational ClearCase  

Project Management To top of page

Workflow

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

Artifacts
Artifacts How to use Review Details Tools used Templates/
Examples
Incep Elab Const Trans
Business Case

Must

Must

Could

Could

Formal-
External
Microsoft® Word®  
Iteration Assessment

Must

Must

Must

Must

Informal

Microsoft Word

 
Iteration Plan Could Must Must Must Informal Microsoft Word  
Measurement Plan Could Could Could Could Informal Microsoft Word  
Problem Resolution Plan Must Must Must Must Informal Microsoft Word  
Product Acceptance Plan Could Must Must Must Informal Microsoft Word  
Project Measurements Could Could Must Must Informal Microsoft Word  
Quality Assurance Plan Could Could Could Could Informal Microsoft Word  
Review Record Must Must Must Must Informal Microsoft Word  
Risk List Must Must Must Must Formal-
Internal
Microsoft Word  
Risk Management Plan Could Must Must Must Informal Microsoft Word  
Software Development Plan (SDP) Won't Could Must Must Formal-
Internal
Microsoft Word
Microsoft Project
 
Status Assessment Could Must Must Must Informal Microsoft Word  
Notes on the Artifacts

The artifact Work Order won't be used. 

Environment To top of page

Workflow

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

Artifacts
Artifacts How to use Review Details Tools used Templates/
Examples
Incep Elab Const Trans
Business Modeling Guidelines

Must

Could

Could

Could

Informal Microsoft Word  
Design Guidelines

Won't

Must

Must

Must

Informal Microsoft Word  
Development Case Must Must Must Must Informal Microsoft® FrontPage®  
Development Infrastructure Must Must Must Must Informal Microsoft Word  
Development-Organization Assessment Must Won't Won't Won't Informal Microsoft Word  
Manual Styleguide Won't Could Must Must Informal Microsoft Word  
Project-Specific Templates Must Must Must Must Informal Microsoft Word  
Programming Guidelines Won't Must Must Must Informal Microsoft Word  
Test Guidelines Won't Must Must Must Informal Microsoft Word  
Tools Must Must Must Must Informal Microsoft Word
to document
 
Tool Guidelines Won't Could Must Must Informal Microsoft Word  
Use-Case Modeling Guidelines Must Must Must Must Informal Microsoft Word  
User-Interface Guidelines Won't Must Must Must Informal Microsoft Word  

Roles To top of page

Not applicable.



Rational Unified Process   2003.06.13