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 roles 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 role), artifacts are the parameters of these activities.

Artifacts 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 units , deliverables , and so on, to denote the same thing. Deliverables in RUP 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 measurement 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 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 in UML stored in Rational XDE

• A project plan stored in Microsoft Project

• A defect stored in Rational ClearQuest

• A project requirements database in Rational Requisite Pro

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

To promote the idea that every piece of information should be the responsibility of a specific person, artifacts are the responsibility of a single role. 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 can 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 information sets that are aligned with the core disciplines.

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 design set contains a description of the system to be built (or as built) in these forms:

• The design model

• The architecture description

The implementation set includes these elements:

• 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 the following:

• 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 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 discipline.

Figure 3-4. Growing the information sets