Guidelines: Classifying Artifacts

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

SWEN 5135 Configuration Management

Topics

Introduction
Impact of classification
Examples of usage

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
Artifact	Incep	Elab	Const	Trans	Comment
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.

Rational Unified Process