Artifacts > Environment Artifact Set > Development Case > Guidelines > Classifying Artifacts

SWEN 5135 Configuration Management

Topics

Introduction

Classification

Explanation

Must have

You must use this artifact. It is a key artifact and may cause problems later in development if it's not produced.

Should have

You should have this artifact, if at all possible, but it is negotiable. If you do not produce this artifact, you should be able to justify why not.

Could have

Could have means that this artifact doesn't have to be produced. It's only produced if it adds value and if there's enough time. 

Won't have

This means you won't use this artifact. This may occur where a Rational Unified Process artifact is replaced by a local artifact.
 

Impact of Classification

All artifacts classified as Must have or Should have must have their review procedures, tools, templates and configuration management practices defined.  

The specification of these procedures is optional for artifacts classified as Could have—these decisions could be left to the developers or projects that decide to produce these artifacts.

All artifacts classified as Won't have must have their omission justified.

The major benefit of adopting this classification scheme is that it allows the development case to clearly denote how the process has been specialized, and where there are options for negotiation and local decision making.

Examples of Usage

One way to think about the artifact classification scheme is that it enables the development case to set constraints on how the elements of the process are used.

For example, if you decide that the project could have an Analysis Model, then the process engineer would fine tune these values by deciding that the project:

  • Must have an Analysis Model, or
  • Won't have an Analysis Model, or even 
  • Will leave things as they are; that is, could have an Analysis Model.

The classification scheme can even be used dynamically—allowing the status of the artifact to change depending upon which phase the project is in.

The following table shows different ways of treating the Analysis Model.  The How to use column defines how the artifact is used in each of the phases.

Artifact

How to use

Comment

Incep

Elab

Const

Trans

Analysis Model

Won't

Won't

Won't

Won't

No Analysis Model is developed

Analysis Model

Could

Could

Could

Could

Normal

Analysis Model

Could

Should

Won't

Won't

An evolutionary approach where the Analysis Model is replaced by the Design Model

Analysis Model

Must

Won't

Won't

Won't

An evolutionary approach where the Analysis Model is mandatory during the Inception phase to help scope the project but is replaced by the Design Model during Elaboration

Analysis Model

Should

Must

Must

Must

A formal process where the Analysis Model is a mandatory, preserved artifact that is optional in the inception phase

Another good example is to consider ways that the Business Use-Case Model is used within the Business Modeling discipline. It describes different possible artifact sets required to support different problem frames. The Concepts: Scope of Business Modeling discusses domain modeling versus business modeling versus business process re-engineering, each of which requires the production of a different set of artifacts.

Copyright  © 1987 - 2001 Rational Software Corporation


Display Rational Unified Process using frames

Rational Unified Process