Concepto: Artefacto
Un artefacto es un producto de trabajo que proporciona una descripción y una definición para productos de trabajo tangibles, es decir, que no son triviales.
Descripción principal

Los artefactos son productos de trabajo tangibles y bien definidos, que las tareas consumen, producen o modifican. Los artefactos pueden estar compuestos por otros artefactos. Por ejemplo, un artefacto de modelo puede estar compuesto de elementos de modelo que también sean artefactos. Pueden servir de base para la definición de activos reutilizables. Los roles utilizan artefactos para realizar tareas y producen artefactos durante la realización de las tareas.

Los artefactos son responsabilidad de un único rol, de forma que la responsabilidad es fácil de identificar y de comprender, y promueven la idea de que toda la información producida en el método precisa el conjunto de habilidades adecuado. Incluso si un rol pudiera ser el "propietario" de un tipo específico de artefactos, otros roles también pueden utilizar los artefactos incluso actualizarlos si el rol ha recibido permiso para hacerlo.

En general, los artefactos no son documentos. Muchos métodos prestan una atención excesiva a los documentos y en particular a la documentación en papel. La forma más eficaz y pragmática de gestionar los artefactos del proyecto es mantenerlos dentro de la herramienta adecuada que se haya utilizado para crearlos y gestionarlos. Cuando sea necesario, se pueden generar documentos (instantáneas) desde esas herramientas, según el principio de 'justo a tiempo'.

Ejemplos de artefactos:

  • Una especificación de caso de uso almacenada en Microsoft® Word®
  • Un modelo de diseño almacenado en Rational Software Architect.
  • Un plan de proyecto almacenado en Microsoft® Project®.
  • Un defecto almacenado en Rational ClearQuest.
  • Una base de datos de requisitos del proyecto en Rational RequisitePro.

Obsérvese asimismo que los formatos del tipo pizarras o blocs para pizarra pueden utilizarse para capturar información gráfica como los diagramas UML, información de tablas como las listas breves de información de estado o incluso información de texto como las sentencias de visión cortas. Estos formatos funcionan bien para equipos más pequeños y colocados en los que todos los miembros del equipo ya tienen acceso a estos recursos.

No obstante, sigue habiendo artefactos que ya son o es mejor que sean simplemente documentos de texto, como es el caso de las entradas externas al proyecto, o en algunos casos en los que es simplemente la mejor manera de presentar información descriptiva. Siempre que sea posible, los equipos deben considerar la utilización de herramientas cooperativas de grupo de trabajo, como las webs WikiWiki o Groove para capturar electrónicamente documentos de texto y así simplificar el contenido continuo y la gestión de versión. Esto es especialmente importante cuando deben mantenerse registros históricos de cara a cumplir los requisitos de una auditoría, por ejemplo. Para cada esfuerzo de desarrollo que no sea trivial, especialmente en los que participan grandes equipos de desarrollo, es muy probable que los productos de trabajo estén sujetos al control de versión y la gestión de la configuración. A veces, esto sólo se consigue mediante una versión del producto de trabajo contenedor, cuando no es posible hacerlo para los productos de trabajo elementales contenidos. Por ejemplo, durante el desarrollo de software, puede controlar las versiones de un modelo de diseño o de un paquete de diseño completo, y no hacerlo de las clases concretas que contiene.