ARTIFACTS

Activities have input and output artifacts. An artifact is a piece of information that is produced, modified, or used by a process. Artifacts are the tangible products of the project: the things the project produces or uses while working toward the final product. Artifacts are used as input by workers to perform an activity and are the result or output of such activities. In object-oriented design terms, just as activities are operations on an active object (the worker), artifacts are the parameters of these activities.

Artifacts may take various shapes or forms:

A model, such as the use-case model or the design model
A model element ”an element within a model ”such as a class, a use case, or a subsystem
A document, such as a business case or software architecture document
Source code
Executables

Note that artifact is the term used in the Rational Unified Process. 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. Figure 3-3 shows some of the major artifacts of the Rational Unified Process.

Figure 3-3. Major artifacts of the Rational Unified Process

Artifacts can also be composed of other artifacts. For example, the design model contains many classes; the software development plan contains several other plans: a staffing plan, a phase plan, a metrics plan, iteration plans, and so on.

Artifacts are very likely to be subject to version control and configuration management. Sometimes, this can be achieved only 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 the individual classes they contain.

Typically, artifacts are not documents. Many processes place an excessive focus on documents and in particular on paper documents. The Rational Unified Process 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 can 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 is based on actual project work, and producing it shouldn't require additional effort.

The following are examples of artifacts:

A design model stored in Rational Rose
A project plan stored in Microsoft Project
A defect stored in ClearQuest
A project requirements database in Requisite Pro

However, certain artifacts must be plain text documents, as in the case of external input to the project, and sometimes plain text is simply the best means of presenting descriptive information.

Artifacts are the responsibility of a single worker, to promote the idea that every piece of information must be the responsibility of a specific person. Even though one person may "own" the artifact, many people may use this artifact, perhaps even updating it if they have been given permission.

Artifacts are denoted in the process prefixed with the word Artifact, as in Artifact: Use-case storyboard.

Reports

Models and model elements may have associated reports. 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. You can reproduce them at any time by going back to the artifacts that generated them.

Sets of Artifacts

The artifacts of the Rational Unified Process have been organized into five information sets:

Management set
Requirements set
Design set
Implementation set
Deployment set

The management set groups all artifacts related to the software business and to the management of the project:

Planning artifacts, such as the software development plan (SDP), the business case, the actual process instance used by the project (the development case), and so on
Operational artifacts, such as a release description, status assessments, deployment documents, and defect data

The requirements set groups all artifacts related to the definition of the software system to be developed:

The vision document
Requirements in the form of stakeholders' needs, use-case model, and supplementary specification
The business model, if it is required for an understanding of the business processes supported by the system

The design set contains a description of the system to be built (or as built) in the form of

The design model
The architecture description
The test model

The implementation set includes

The source code and executables
The associated data files or the files needed to produce them

The deployment set contains all the information delivered, including

Installation material
User documentation
Training material

In an iterative development process, the various artifacts are not produced, completed, or even frozen in one phase before you move to the next phase. On the contrary, the five information sets evolve throughout the development cycle. They are grown, as depicted in Figure 3-4. Appendix B lists all artifacts defined in the Rational Unified Process, organized by workflow.

Figure 3-4. Growing the information sets