<Project Name>
Development Case
Version <1.0>
[Note: The following template is provided for use with the Rational Unified Process (RUP). Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).]
Important: There are hyperlinks to pages in the RUP in this template. These hyperlinks must be modified when
you create your own development case. For example, assume that the RUP is installed in a folder named 'RationalUnifiedProcessX.X'.
Also assume that you put the development case at the same level as the RUP. In that case you should:
Search: "../../../"
Replace: "RationalUnifiedProcessX.X"]
Revision History
Date |
Version |
Description |
Author |
<dd/mmm/yy> |
<x.x> |
<details> |
<name> |
|
|
|
|
|
|
|
|
|
|
|
|
"The purpose of the document is to describe the development process for the <<project name>>."
The purpose of this section is to explain how the discipline configuration works. This includes an explanation of the purpose for the various tables and for each of the sections that describe the various disciplines listed in the section titled Disciplines.
Artifacts | How to use | Review Details | Tools used | Templates/
Examples |
|||
Incep | Elab | Const | Trans | ||||
Explanation of the table |
||
Column Name | Purpose | Contents and Comments |
'Artifacts' |
[The name of the artifact.] |
[A reference to the artifact in the RUP or to a local artifact definition held as part of the development case.] |
'How to use' |
[Qualify how the artifact is used across the lifecycle.] |
[Decide for each phase:
These are defined in Guidelines: Classifying Artifacts.] |
'Review Details' |
[Define the review level and review the procedures to be applied to the artifact.] |
[Decide on the review level:
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 general Review Procedure section in the Development Case. More specific review procedures are defined under the subsection titled Additional Review Procedures.] |
'Tools used' |
[Definition of the tool or tools used to produce the artifact.] |
[Reference the details of the tools used to develop and maintain this artifact.] |
'Templates/Examples' |
[The templates to be used and examples of artifacts using the templates.] |
[Reference the templates and examples. This could be references to either the templates and examples in the RUP or to local templates and examples. This column may also contain references to actual artifacts to provide additional help to the project members.] |
It contains a reference to the project's Configuration Management Plan, which describes the configuration management strategy to be used when working on these artifacts. The CM Plan needs to allow developers to answer questions such as:
Where do I put my newly created or modified artifact?
Where do I find existing artifacts for the project?
Artifacts | How to Use | Reason |
|
|
Reports | How to use | Templates/Examples | Tools Used |
|
|
An artifact is a deliverable of the process. It is often developed within one discipline, though there are exceptions. The artifacts are organized in the discipline where it's created. To describe how an artifact needs to be used, use the following classification scheme (see Guidelines: Classifying Artifacts for details):
Should
Could
Won't
Artifacts | How to use | Review Details | Tools used | Templates/
Examples |
|||
Incep | Elab | Const | Trans | ||||
Business Analysis Model | |
|
|
|
|
||
|
|
|
|
|
|||
|
|
|
|
|
|||
|
|
|
|
|
|||
|
|
|
|
|
|||
|
|
|
|
|
|||
Business Architecture Document | |
|
|
|
|
||
Business Glossary | |
|
|
|
|
||
Business Goal | |
|
|
|
|
||
Business Rule | |
|
|
|
|
||
Business Use-Case Model | |
|
|
|
|
||
|
|
|
|
|
|||
|
|
|
|
|
|||
Business Vision | |
|
|
|
|
||
Supplementary Business Specification | |
|
|
|
|
||
Target-Organization Assessment | |
|
|
|
|
Artifacts | How to Use | Reason |
|
|
Reports | How to use | Templates/Examples | Tools Used |
Business Actor | |
|
|
Business Analysis Model Survey | |
|
|
Business Entity | |
|
|
Business Rules Survey | |
|
|
Business Use-Case | |
|
|
Business Use-Case Realization | |
|
|
Business Use-Case Model Survey | |
|
|
Business Worker | |
|
Artifacts | How to use | Review Details | Tools used | Templates/
Examples |
|||
Incep | Elab | Const | Trans | ||||
Glossary | |||||||
Requirements Attributes | |||||||
Requirements Management Plan | |||||||
Stakeholder Requests | |||||||
Software Requirement | |||||||
Software Requirements Specification | |||||||
Storyboard | |||||||
Supplementary Specifications | |||||||
Use-Case Model | |||||||
|
|
|
|
|
|||
Vision |
Artifacts | How to Use | Reason |
|
|
Reports | How to Use | Templates/Examples | Tools Used |
Actor | |||
Use-Case | |
||
Use-Case Model Survey | |
|
Artifacts | How to use | Review Details | Tools used | Templates/
Examples |
|||
Incep | Elab | Const | Trans | ||||
Analysis Model | |
|
|
|
|
||
|
|
|
|
||||
Architectural Proof-Of-Concept | |||||||
Data Model | |||||||
Deployment Model | |||||||
Design Model | |||||||
|
|||||||
|
|||||||
Navigation Map | |||||||
Reference Architecture | |||||||
Software Architecture Document | |||||||
User-Interface Prototype |
Artifact | How to Use | Reason |
|
|
Reports | How to Use | Templates/Examples | Tools Used |
Class | |||
Design-Model Survey | |||
Design Package/Subsystem | |||
Use-Case Realization |
Artifacts | How to use | Review Details | Tools used | Templates/
Examples |
|||
Incep | Elab | Const | Trans | ||||
Build | |||||||
Implementation Model | |
|
|
|
|
||
|
|
|
|
|
|||
Integration Build Plan |
Artifacts | How to Use | Reason |
|
|
Reports | How to Use | Templates/Examples | Tools Used |
|
|
Artifacts | How to use | Review Details | Tools used | Templates/
Examples |
|||
Incep | Elab | Const | Trans | ||||
Test Automation Architecture | |
|
|
|
|
||
Test Case | |
|
|
|
|
||
Test Data | |
|
|
|
|
||
Test Environment Configuration | |||||||
Test Evaluation Summary | |||||||
Test Ideas List | |||||||
Test Interface Specification | |||||||
Test Log | |||||||
Test Strategy | |||||||
Test Suite | |||||||
Test Plan | |||||||
Test Results | |||||||
Test Script | |||||||
Workload Analysis Model |
Artifacts | How to Use | Reason |
|
|
Reports | How to Use | Templates/Examples | Tools Used |
Test Survey |
|
|
Artifacts | How to use | Review Details | Tools used | Templates/
Examples |
|||
Incep | Elab | Const | Trans | ||||
Deployment Plan | |
|
|
|
|
||
End-User Support Material | |
|
|
|
|
||
Product | |||||||
|
|
|
|
|
|||
|
|
|
|
|
|||
Artifacts | How to Use | Reason |
|
|
Reports | How to Use | Templates/Examples | Tools Used |
|
|
Artifacts | How to use | Review Details | Tools used | Templates/
Examples |
|||
Incep | Elab | Const | Trans | ||||
Change Request |
|
|
|
|
|
||
Configuration Audit Findings |
|
|
|
|
|
||
Configuration Management Plan | |||||||
Project Repository | |||||||
Workspace |
Artifacts | How to Use | Reason |
|
|
Reports | How to Use | Templates/Examples | Tools Used |
|
|
Artifacts | How to use | Review Details | Tools used | Templates/
Examples |
|||
Incep | Elab | Const | Trans | ||||
Business Case | |
|
|
|
|
||
Issues List | |
|
|
|
|
||
Iteration Assessment | |
|
|
|
|
||
Iteration Plan | |||||||
Project Measurements | |||||||
Review Record | |||||||
Risk List | |||||||
Software Development Plan | |||||||
Status Assessment | |||||||
Work Order |
Artifacts | How to Use | Reason |
|
|
Reports | How to Use | Templates/Examples | Tools Used |
|
|
Artifacts | How to use | Review Details | Tools used | Templates/
Examples |
|||
Incep | Elab | Const | Trans | ||||
Development Infrastructure | |||||||
Development-Organization Assessment | |||||||
Development Process | |
|
|
|
|
||
|
|
|
|
|
|||
|
|
|
|
|
|||
Manual Styleguide | |||||||
Tools |
Artifacts | How to Use | Reason |
|
|
Reports | How to Use | Templates/Examples | Tools Used |
|
|
To map job positions in the organization to the roles in the RUP. The reason for this is that 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 for 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.]