Key Concept: Artifact
Topics:
Artifact 
Activities have input and output
artifacts. An artifact is a work product of the process: roles use artifacts to perform activities, and produce artifacts in the course
of performing activities. Artifacts are the responsibility of a single role and promote the idea that every piece of information in the process must be the
responsibility of a specific person. Even though one person may "own"
the artifact, many other people may use the artifact, perhaps even updating it
if they have been given permission.
To simplify the organization of artifacts, they are organized into
"information sets", or artifact sets. An artifact set
is a grouping of related artifacts that tend to be used for a similar purpose.
The Artifact Overview presents
more information on artifacts and artifact sets.
Artifacts may take various shapes or forms:
Note that "artifact" is the term used in the UPEDU. Other processes use terms such as work product,
work unit, and so on, to denote the same thing. Deliverables
are only the subset of all artifacts that end up in the hands of the customers
and end-users.
Artifacts are most likely to be subject to version control and
configuration management. This is sometimes only achieved by versioning
the container artifact, when it is not possible to do it for the elementary,
contained artifacts. For example, you may control the versions of a whole design
model, or design package, and not of individual classes they contain.
Artifacts are typically not documents. Many processes
have an excessive focus on documents, and in particular on paper documents.
The UPEDU discourages the systematic production of paper
documents. The most efficient and pragmatic approach to managing project
artifacts is to maintain the artifacts within the appropriate tool used
to create and manage them. When necessary, you may generate documents
(snapshots) from these tools, on a just-in-time basis. You should also consider
delivering artifacts to the interested parties inside and together with the
tool, rather than on paper. This approach ensures that the information is always
up-to-date and based on actual project work, and it shouldn't require any
additional effort to produce.
Guidelines and Checkpoints 
Artifacts typically have associated guidelines and checkpoints which present
information on how to develop, evaluate and use the artifacts. Much of the substance
of the Process is contained in these guidelines; the activity descriptions
try to capture the essence of what is done, while the guidelines capture
the essence of doing the work. The checkpoints provide a quick reference to
help you assess the quality of the artifact.
Both guidelines and checkpoints are useful in a number of contexts: they help
you decide what to do, they help you to do it, and they help you to decide if
you've done a good job when you're done. Guidelines are summarily presented in the Guidelines Overview Section.
Template 
Templates are "models," or prototypes, of artifacts. Associated with the
artifact description are one or more templates that can be used to create the corresponding artifacts.
Reports 
Models and model elements, may have
reports associated with them. A report extracts information about models and
model elements from a tool. For example, a report presents an artifact or a set
of artifacts for a review. Unlike regular artifacts, reports are not subject to
version control. They can be reproduced at any time by going back to the
artifacts that generated them. Reports are organized in the treebrowser beneath
the artifact on which they report.
Case Studies 
Most of the artifacts have a case study associated with them. The case studies are based on a real project realized by fourth year software engineering students at
École de Polytechnique de Montréal for a course called Studio in Software Engineering.
Templates, Case-Studies and Reports are summarily presented Templates, Case-Studies and Reports Section
Copyright:
© 1987 - 2004 Rational Software Corporation
© 2004 École Polytechnique de Montréal
|