What is a Software Artifact?

Asked

Viewed 9,191 times

5

In Software Engineering, much is heard about the term Software Artifact. I researched about it and found the following definition:

An article or artifact is one of several types of by-products produced during software development. Some artifacts (for example, use cases, class diagrams and other UML models, requirements and design documents) help describe the function, architecture and software design. Other artifacts are related to the development process itself - such as project plans, business processes and risk assessments. They be manual, executable files, modules etc.

The term artifact in connection with software development is widely associated with methods or development processes specific, for example, the Unified Process. This use of the term can originated with these methods.

Source: https://en.wikipedia.org/wiki/Artifact_(software_development)

I still can’t understand. What is a Software Artifact?

  • 3

    In college I was told that an artifact was either a document or a model. The difference from one to the other - if it is not clear - is that a document has the primary function of being consulted by people, while a model in general also receives automated processing. As both documents and models need to be versioned, going to the memory of the project, etc., "artifact" was used to refer to both. At least that’s how I learned, I don’t know if it’s the way it’s used these days.

3 answers

1

A software artifact can be summarized as any document or model generated during software development. For some people, a software package can also be considered an artifact.

I personally always imagine an artifact like any document, be it physical or digital, produced during the lifecycle of software development. For example, a planning document, a requirements document, the product backlog, an activity diagram, a good practice guide, an architecture document, etc.

1

Understand as artifact a sub-part of the software. It can be from the engineering that resulted in a part or artifact of software, to the source code that also make up the same. In other words, it is something that makes up the software development cycle that starts the analysis, after the development followed by the tests and finally the delivery of the program. You can think about the construction of a house for example, in it you have several artifacts ranging from the design to the construction and finishing with the finishes.

This is a simpler and more concise definition. If you search the internet you will have more detailed examples. I tried to speak simply and objectively, citing an example of everyday life.

  • This definition implies that an artifact can be either concrete (a design plan) or abstract (the design itself). I believe that the term artifact applies only to concrete elements, as stated in the definition included in the question. At least that’s how I see the term being used.

  • The definition I have put forward is simple and objective. Going back to the software area is something that gets even more complex, where the definition of such a term is linked directly with the context. However, I agree that an artifact is something concrete. For example, a test routine that forms part of the development cycle. Otherwise a documentation is generated there is no artifact. However, no artifact is the exception (or at least should be). Finally, to arrive at an exact definition it would be necessary to write a much more complete text, more for such the internet is there.

1

When a software is created or maintained, several documents are created in the process. For example:

  • Use cases, to detail user interaction with software;
  • Data models, to describe how the data that the software uses is structured;
  • The software source code itself;
  • UML diagrams of various types;
  • Minutes or other records of meetings.

These documents (and many others) are necessary for people involved in software development to have a common information base to communicate about the software. These documents are collectively called software artifacts. Depending on the development methodology (if any is used), artifact types vary.

It is possible, in theory, not to have artifacts, except for the source code, but this will make any program maintenance task a nightmare: to find out what makes each part of the system, you would need to reverse engineer the program! It is much more practical to consult a diagram or documentation, and understand face how that piece of the system works (or should work).

Browser other questions tagged

You are not signed in. Login or sign up in order to post.