What is an artifact? No, we’re not talking ancient artifacts here. The type of artifact we’re talking about is related to software development.
Whether you’re an amateur or professional developer, you’re going to be dealing with software artifacts. They’re some of the most crucial parts of any piece of software, from a website to a more complex program.
Without properly created and stored artifacts, the software development process is going to be much more of a slog than it needs to be.
To learn everything you need to know about software artifacts, keep reading, and learn what you need to know moving forward.
What Is an Artifact?
To put it simply, an artifact is a by-product of software development. It’s anything that is created so a piece of software can be developed. This might include things like data models, diagrams, setup scripts — the list goes on.
“Artifact” is a pretty broad term when it comes to software development. Most pieces of software have a lot of artifacts that are necessary for them to run. Some artifacts explain how a piece of software is supposed to work, while others actually allow that program to run.
Why Is It Called an Artifact?
Think about an archaeological dig site. During an archaeological dig, any man-made object that’s dug up is an artifact. These artifacts help us determine what civilization may have been like and help us paint a picture of their society.
Similarly, digital artifacts are all products of people. They help other developers see the thought process behind what goes into developing a piece of software. This, in turn, helps lead developers to further decisions and gives them a better understanding of how to proceed.
The Artifact Process
Typically, a software development team will come up with a list of necessary artifacts for a piece of software before coding anything. These include things like risk assessments, source code, diagrams, and use cases. This is done during the research phase of the project.
Developing a piece of software without any of this is like building a house without blueprints. The process would be a huge mess, and crucial pieces would inevitably be left out. In this way, getting all your artifacts together is one of the most crucial parts of the software development life cycle.
Once all the initial artifacts are compiled, a development team can begin programming and building the actual program. Throughout this process, further artifacts might be developed. These can come up at any time and include everything from new sketches to use cases.
Some artifacts, like the end-user agreement, may need to be built after the software is complete for total accuracy. These may be added in before the program is compiled and sent out for consumption.
There are a lot of different parts of any given piece of software that can be artifacts. Here are a few of the most common examples.
Use cases are descriptions of how users are meant to perform tasks on a given program, website, or piece of software. These relate directly to the function of the site, making them important artifacts.
Unified Modeling Language (UML)
UML is a way of visualizing and plotting out the way a piece of software works. It works to map out links, processes, etc.
Like use cases, UML doesn’t directly help software run, but it’s a key step in designing and programming a piece of software.
Like UML, a class diagram is a way to map out the structure of a piece of software or application. Class diagrams are used to map out links and processes that happen between clicks in a more visual way.
Any images used to help develop the piece of software are considered artifacts. These might be example images used to help in the design of the product, or preliminary design images. It could even be simple sketches and diagrams used to help map out the software.
The majority of the artifacts are software documents. Any document that describes the characteristics or attributes of a piece of software is an artifact. These can relate to the software’s architecture, technical side, end-user processes, and marketing.
The majority of these artifacts won’t even cross the mind of the user. They’re meant for developers and those who might be interested in the software from a large-scale business perspective. Much of it is technical, and simply not of interest to the typical user.
The source code is the language used to program a given piece of software. It’s not the physical code itself, but the system that allows that code to work. This, too, is an artifact according to software developers.
Yes, even meeting notes are artifacts in the world of software design. This may include full transcripts of meetings, or just jotted notes. Important design choices and aspects may have been made during these meetings, making it important to include these in your repository.
A risk assessment offers a look at the potential risks and downfalls of a piece of software. It helps tell a developer what not to do and lists problems that the developer needs to find a way around. In some ways, these are some of the most crucial artifacts for developers to consider.
Any prototype of your program is an artifact. These might be fully-functioning pieces of the software or previews of certain parts of the program. Either way, they help a developer see what has been done and tried, and give them an idea of where to go next.
The Compiled Application
Once the piece of software is fully developed, it’s compiled into a usable application. This is the final artifact, and one of the only ones a typical user will care about. The compiled application will let the user install it onto their machine, and use it as its meant to be used.
There may be a number of these in the artifact repository. There could be different versions, from early prototypes to experimental builds and the final compilation.
Why Are Artifacts Important?
Artifacts are important to hold onto throughout the development process of any piece of software, and even long after.
Without each and every artifact, it can make developing a piece of software much more difficult over time. This is especially true if development switches hands. When a new developer is put on a project, one of the first things they’ll want to do is go through the artifacts to get an idea of how the software works.
If an artifact is missing, that leaves a developer in the dark. This is why most artifacts are kept in a repository. This lets relevant developers access the artifacts at any time, all from one place.
What Is an Artifact Repository?
An artifact repository is a location for all of the necessary artifacts that might be used to develop a piece of software. It is often hosted on a local server or in the cloud for easy access by developers.
Using an artifact repository is absolutely necessary for all software development. It makes a complex task easier by giving developers all the resources they need in one place. It helps cut down on searching and gives developers the ability to move, add, and delete artifacts with ease.
There are three types of artifact repositories used in software development:
Remote Repository: A remote repository is hosted on a remote URL, sometimes by a third-party company. You cannot add new artifacts to a remote repository, but you can remove them.
Local Repository: A local repository is stored in-house, usually on a dedicated server.
Virtual: A combination of the two above. This repository is held under one URL, allowing access to local and remote artifact files. This lets you add and remove artifacts from each repository with ease.
There are a few key functions artifact repository software handles for the developers. Versioning support is one of these. The software will keep track of when each artifact is built, and apply a version to each build of the software.
Repository software can also help keep important artifacts, and delete ones that become irrelevant. This may happen when a new version of a given artifact is uploaded to the repository.
Of course, the most important factor of a good artifact repository is privacy and permissions. The software will keep all these artifacts private, and require a password to access.
The Types of Artifacts
There are three main categories that software artifacts fall under. These are code-related artifacts, project management artifacts, and documentation. Here’s a closer look at all three.
Every program is made up of codes, and each coded process produces artifacts. These include:
- Test Suites: Coded test to run against the program in order to make sure a certain process is working
- Setup Scripts: Allow the program to run on a given machine
- Complied Code: The final, compiled code that goes out to the user
- Test Output: Logs and information that comes from the testing process
Code artifacts are unavoidable, important by-products of the coding process. They let a developer test the ins and outs of their software, allowing them to perfect it for the user.
We’ve touched on a few types of document artifacts previously. Essentially, any piece of documentation relating to the software at hand is a relevant artifact. This includes:
- Diagrams: We talked about class diagrams above. Diagrams are a great way to visualize the internal processes of a given program. These will be created throughout the coding process, particularly in the preliminary stages.
- End-User Agreements: An end-user agreement is any document meant for the user to read. This includes terms-of-service documents and anything that helps the user understand the program.
- Internal Documents: Any document that helps developers, bug-fixers, programmers improve on and understand the program. This also includes walkthroughs — guides that show testers, quality control people, etc. how to manage the application.
A lot of the artifacts in a given program fall under the documentation category. These are produced throughout the development process, from beginning to end. The more research that goes into a program, the more documentation artifacts there are.
No matter how unimportant or preliminary the document may seem, these are important to keep track of.
Project Management Artifacts
These artifacts come about during the project management phase. They may come after routine tests of software, or after bug-checks. These artifacts relate to the ideal behavior of the program, and what the client wants of it.
- User Cases/Stories: These artifacts describe what the program should do in specific, technical terms. They detail what’s wanted of the program, and how that might be achieved.
- Criteria: These artifacts layout the minimum acceptable requirements of the program/project. These typically come from the client or the project manager. This gives developers a concrete goal to work towards.
Project management artifacts let the development team know if they’re on the right track, and give them an idea of how to get there. These are crucial bits of feedback for everyone on the development team, new or old.
Understanding Software Artifacts
So, what is an artifact? Essentially, it’s the skeleton of any given program. From documents to code tests to sketches, all of these are important artifacts for any developer.
No piece of software is complete without a host of artifacts, from diagrams to meeting notes and the source code itself. You can’t escape them, but you can better understand what they are and why they’re so important to keep track of. Hopefully, this guide has helped you understand software artifacts just a little more.