Un artefacto es uno de los muchos tipos de subproductos tangibles que se generan durante el desarrollo de software. Algunos artefactos (por ejemplo, casos de uso , diagramas de clases , requisitos y documentos de diseño) ayudan a describir la función, la arquitectura y el diseño del software. Otros artefactos se relacionan con el proceso de desarrollo en sí, como planes de proyectos, casos de negocios y evaluaciones de riesgos.
El término artefacto, en relación con el desarrollo de software, se asocia en gran medida con métodos o procesos de desarrollo específicos, por ejemplo, el proceso unificado . Este uso del término puede haberse originado con esos métodos.
Las herramientas de compilación a menudo se refieren al código fuente compilado para pruebas como un artefacto, porque el ejecutable es necesario para llevar a cabo el plan de prueba. Sin el ejecutable para probar, el artefacto del plan de prueba se limita a pruebas no basadas en ejecución. En las pruebas no basadas en ejecución, los artefactos son los tutoriales , las inspecciones y las pruebas de corrección . Por otro lado, las pruebas basadas en ejecución requieren al menos dos artefactos: un conjunto de pruebas y el ejecutable. Ocasionalmente, el artefacto puede referirse al código publicado (en el caso de una biblioteca de código ) o al ejecutable publicado (en el caso de un programa) producido, pero más comúnmente un artefacto es el subproducto del desarrollo de software en lugar del producto en sí. Las bibliotecas de código fuente abierto a menudo contienen un arnés de prueba para permitir que los contribuyentes se aseguren de que sus cambios no provoquen errores de regresión en la biblioteca de código.
Gran parte de lo que se considera artefactos es documentación de software .
En el desarrollo para el usuario final, un artefacto es una aplicación o un objeto de datos complejo creado por un usuario final sin necesidad de conocer un lenguaje de programación general. Los artefactos describen comportamientos automatizados o secuencias de control, como solicitudes de bases de datos o reglas gramaticales [1] o contenido generado por el usuario .
Los artefactos varían en su capacidad de mantenimiento. La capacidad de mantenimiento se ve afectada principalmente por el papel que cumple el artefacto. El papel puede ser práctico o simbólico. En las primeras etapas del desarrollo de software, el equipo de diseño puede crear artefactos para que cumplan una función simbólica y muestren al patrocinador del proyecto la seriedad con la que el contratista se toma las necesidades del proyecto. Los artefactos simbólicos suelen transmitir información de forma deficiente, pero tienen un aspecto impresionante. Los simbólicos mejoran la comprensión. En términos generales, los pergaminos iluminados también se consideran inmanejables debido a la diligencia que requiere preservar la calidad simbólica. Por este motivo, una vez que se muestran los pergaminos iluminados al patrocinador del proyecto y se aprueban, se reemplazan por artefactos que cumplen una función práctica. Los artefactos prácticos suelen necesitar mantenimiento durante todo el ciclo de vida del proyecto y, como tales, suelen ser muy fáciles de mantener.
Los artefactos son importantes desde la perspectiva de la gestión de proyectos como entregables . Es probable que los entregables de un proyecto de software sean los mismos que sus artefactos, con la incorporación del software en sí.
El sentido de artefactos como subproductos es similar al uso del término artefacto en ciencia para referirse a algo que surge del proceso en cuestión más que del resultado en sí, es decir, un resultado del interés que surge de los medios más que del fin.
Para recopilar, organizar y gestionar artefactos, se puede utilizar una carpeta de desarrollo de software.