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.
|