Overview > Concepts > Key Concepts > Artifact

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