| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmi:id="_fdds0BUJEdqrUt4zetC1gg" name="artifact,_fdRfkBUJEdqrUt4zetC1gg" guid="_fdds0BUJEdqrUt4zetC1gg" changeDate="2006-04-13T14:05:00.252-0700"> |
| <mainDescription><p> |
| Artifacts are tangible well-defined Work Products consumed, produced, or modified by Tasks.&nbsp; Artifacts may be |
| composed of other Artifacts. For example, a model Artifact can be composed of model elements, which are also Artifacts. |
| They may serve as a basis for defining Reusable Assets.&nbsp; Roles use Artifacts to perform Tasks and produce |
| Artifacts in the course of performing Tasks. |
| </p> |
| <p> |
| 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 method requires the appropriate set of skills. Even though one |
| Role might "own" a specific type of Artifact, other Roles can still use the Artifacts, and perhaps even update them if |
| the Role has been given permission to do so. |
| </p> |
| <p> |
| <b>Artifacts&nbsp;are generally <i>not</i> documents</b>. Many methods have an excessive focus on documents, and in |
| particular on <i>paper documentation</i>. The most efficient and pragmatic approach to managing project Artifacts is to |
| maintain&nbsp;them <i>within</i> the appropriate tool used to create and manage them. When necessary, one may generate |
| documents (snapshots) from these tools, on a just-in-time basis. |
| </p> |
| <p> |
| Examples Artifacts: |
| </p> |
| <ul> |
| <li> |
| A use case specification stored in&nbsp;a word processor tool&nbsp; |
| </li> |
| <li> |
| A design model stored in&nbsp;a visual modeling tool.&nbsp; |
| </li> |
| <li> |
| A project plan stored in&nbsp;a project planning tool.&nbsp; |
| </li> |
| <li> |
| A defect stored in&nbsp;a change requests tools&nbsp; |
| </li> |
| <li> |
| A project requirements database in a requirements management tool. |
| </li> |
| </ul> |
| <p> |
| Note also that formats such as on <b>whiteboards</b> or <b>flip charts</b> 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. |
| </p> |
| <p> |
| 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, teams should consider using collaborative <b>Work Group</b> tools, such as WikiWiki webs |
| or Groove to capture textual documentation electronically, thus 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, Work |
| Products <strong>are</strong> <strong>most likely to be subject to version control and configuration |
| management.</strong> This is sometimes only achieved by versioning the container Work Product, when it is not possible |
| to do it for the elementary, contained Work Products. For example, in software development, you may control the |
| versions of a whole design model, or design package, and not the individual classes they contain. |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |