Un artefacto es uno de los muchos tipos de subproductos tangibles que se producen durante el desarrollo de software. Algunos artefactos (p. ej., casos de uso , diagramas de clases y otros modelos, requisitos y documentos de diseño del Lenguaje Unificado de Modelado (UML)) ayudan a describir la función, la arquitectura y el diseño del software. Otros artefactos tienen que ver con el proceso de desarrollo en sí, como planes de proyecto, 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, 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 realizar pruebas como un artefacto, porque el ejecutable es necesario para llevar a cabo el plan de pruebas. Sin el ejecutable para probar, el artefacto del plan de pruebas se limita a pruebas no basadas en ejecución. En las pruebas no basadas en ejecución, los artefactos son los recorridos , las inspecciones y las pruebas de corrección . Por otro lado, las pruebas basadas en ejecución requieren como mínimo dos artefactos: un conjunto de pruebas y el ejecutable. En ocasiones, un artefacto puede referirse al código publicado (en el caso de una biblioteca de códigos ) 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 a los contribuyentes garantizar que sus cambios no causen 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 del usuario final, un artefacto es una aplicación o un objeto de datos complejo creado por un usuario final sin la 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 mantenibilidad. La mantenibilidad 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 que cumplan una función simbólica para mostrar al patrocinador del proyecto cuán serio es el contratista en cuanto a satisfacer las necesidades del proyecto. Los artefactos simbólicos a menudo transmiten información de manera deficiente, pero tienen un aspecto impresionante. Simbólico mejora la comprensión. En términos generales, los Pergaminos Iluminados también se consideran inmantenibles debido a la diligencia que requiere para preservar la calidad simbólica. Por esta razón, una vez que los Pergaminos Iluminados se muestran al patrocinador del proyecto y se aprueban, son reemplazados por artefactos que cumplen una función práctica. Los artefactos prácticos generalmente necesitan mantenimiento durante todo el ciclo de vida del proyecto y, como tales, generalmente son altamente 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 adició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 problema en sí, es decir, un resultado de 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.