What does `Artifacts` actually mean in Unified Process?
I read a book recently on Design patterns: I came across the word Artifacts in each pages many times! What are they actually? Where it should be used?
In UP, artifacts are really important and they play a major role in Object Oriented Analysis . . . .
Answer
The term artifact (or artefact) seems to have been popularized around the time that Booch, Rumbaugh and Jacobsen (the 3 amigos) described the Rational Unified Process.
The word Artifact in RUP software engineering was a generic term to refer to any 'deliverable' which could be produced by any 'role' in the software development lifecycle, including:
- Documents, such as Project Plan, Requirements Document, Specifications etc
- A Model generated during design, usually one of the UML available diagrams, e.g. a Class Diagram, or ERD
- Code artifacts, including source files, binary outputs, and test or support code.
Artifacts could be brought into Software Configuration Management (identified, versioned, change could be managed, etc).
The term artifact also crops up in business process modelling, usually referring to a physical or electronic document produced by a process, e.g. a claim form, an EDI document, or a report output.
Nowadays, the word artifact might be regarded in the same light as pretentious management speak, and the term is usually too vague and generic to be used frequently by the actual software development team, e.g. you'll get blank stares if you use terminology such as:
"I've finished checking in the artifact"
"Please could you write an artifact for our next test case"
i.e. You'll likely want to use more specific terminology at the coal face of software development!