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, making responsibility easy to identify and understand, and promoting the idea that every piece of information produced in the process requires the appropriate set of skills. Even though one role may "own" the artifact, other roles will use the artifact, perhaps even updating it if the role has been given permission to do so.
Major artifacts in the process, and the approximate flow of information between them.
The diagram above shows how information flows through the project, using the artifacts; the arrows show how changes in one artifact ripple through other artifacts along the arrows. For clarity, many artifacts are omitted; for example, the many artifacts in the design model are omitted, being represented by the Artifact: Design Model.
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. An artifact may be composed of other artifacts. The Artifact Overview presents more information on artifacts and artifact sets.
Artifacts and artifact sets in the treebrowser
Artifacts may take various shapes or forms, such as:
- A model, such as the Use-Case Model or the Design Model, which contains other artifacts.
- A model element; that is, an element within a model, such as a Design Class, a Use Case or a Design Subsystem
- Databases or other types of tabular information repositories such as spreadsheets
- Source code and executables (kinds of Implementation Elements)
- Various types of documents, for example a specification document, such as Requirements Specification, or a plan document, such as the Software Development Plan.
Note that "artifact" is the term used in the RUP to describe what other processes denote using terms such as work product, work unit, and so on. In RUP, deliverables are only considered to be the subset of all artifacts that will end up being delivered into the hands of the customers and end-users, usually as part of a formal or contractually agreed hand-over.
In RUP, artifacts are generally not documents. Many processes have an excessive focus on documents, and in particular on paper documentation. The RUP 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 should not require any additional effort to produce.
Examples of artifacts:
- A design model stored in Rational Rose.
- A project plan stored in Microsoft® Project®.
- A defect stored in Rational ClearQuest.
- A project requirements database in Rational RequisitePro.
Note also that formats such as on whiteboards or flipcharts can be used to capture pictorial information such as UML diagrams, tabular information such as short lists of status information or even textual information such as short vision statements. These formats work well for smaller, Collocated teams where all team members have ready access to these resources.
However, there are still artifacts which either have to be or are best suited to being plain text documents, as in the case of external input to the project, or in some cases where it is simply the best means of presenting descriptive information. Where possible, you should consider using collaborative Work Group tools, such as Rational RequisitePro, Lotus Notes, WikiWiki webs or Groove to capture textual documentation electronically, simplifying ongoing content and version management.
This is especially of importance where historic records must be maintained for purposes such as fulfilling audit requirements. For any nontrivial development effort, especially where large development teams are involved, 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 the individual classes they contain.
Artifact Guidelines and Checkpoints
Artifacts typically have associated guidelines and checkpoints which present information on how to develop, evaluate and use the artifacts. Some artifacts have concept pages associated with them, although these are more descriptive in nature, and often associated with more high-level process elements, such as disciplines. Much of the substance of the Process is contained in the artifact guidelines; the activity descriptions try to capture the essence of what is done, while the artifact guidelines capture the essence of doing the work. The checkpoints provide a quick reference to help you assess the quality of the artifact. Concepts provide an educational or informative view of the artifact.
Both guidelines, checkpoints, and concepts, are useful in a number of contexts: they help you decide what to do, they help you to do it, they help you to decide if you've done a good job when you're done, and they help you understand how this artifact relates to the rest of the process. Supporting content pages related to each specific artifact are organized along with that artifact in the treebrowser.
A typical artifact in the treebrowser, with associated supporting
content pages.
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. Templates are linked to the tool that is to be used.
For example:
- Microsoft® Word® templates would be used for artifacts that are documents, and for some reports.
- Rational SoDA templates for Microsoft Word or Adobe® FrameMaker® would extract information from tools such as Rational Rose, Rational RequisitePro, or Rational TeamTest.
- Microsoft® FrontPage® templates for the various elements of the process.
- Microsoft Project template for the project plan.
As with guidelines, organizations may want to customize the templates prior to using them by adding the company logo, some project identification, or information specific to the type of project. Templates are listed in the Templates & Reports section of an artifact page and they are organized in the treebrowser beneath their associated artifact. They are also summarized in the Templates overview page, and a separate treebrowser entry shows all templates in your RUP configuration.
Expanded portion of the treebrowser, showing the different kinds of templates in the RUP.
Example
An example of an artifact is a good supplement to its prescriptive and descriptive process guidance. Examples are associated with the specific artifacts in the RUP Website to give the producer of this artifact a view of how it can look like when its done. The examples of an artifact are listed in the Examples section of the artifact description, and are generally organized in the treebrowser beneath the artifact on which they exemplify. An overview of all examples in your RUP configuration is presented in the Examples overview page, and a separate treebrowser entry shows any complete project examples included.
The Examples entry in the Overview section of the treebrowser provides access to artifact examples in the RUP.
Report
Artifacts may have reports associated with them. A report extracts information about one or more artifacts from a tool. For example, a report can present an artifact or a set of artifacts for use in a technical review. Unlike regular artifacts, reports are not subject to version control, however they may be baselined to provide a historic audit trail of the report over time. In some cases, the development tools enable the report to be reproduced at any time by rerunning the report against the historic artifacts. Reports are listed in the Templates & Reports section of an artifact page, and are generally organized in the treebrowser beneath the artifact on which they report.
