CASPER

Aunque rápidamente se viene a la cabeza ese pequeño, cabezón y simpático fantasmilla, nos queremos referir al Conjunto de Artefactos Solo Para Esta Release.

Existe la idea equivocada de estar obligados mantener continuamente toda la documentación que se genera a lo largo de un proyecto. Pero sin embargo, hay cantidad de artefactos de usar y tirar. Es decir, información que sólo tiene sentido durante un ciclo de desarrollo (idealmente lo más corto posible); pero que no es necesario mantener por más tiempo.

Algunos ejemplos son: conjunto de peticiones u ocurrencias del cliente asumidas para la siguiente release, lista de pruebas específicas para dicha versión, notas sobre cambios realizados en los diseños o el código durante este ciclo de desarrollo, diagramas o indicaciones al programador sobre cómo implementar las nuevas funciones, etc.

Debemos asumir que esta documentación no requiere excesivo formalismo y, en general será bastante simplona, ya que en general se trata de indicaciones sobre cómo modificar el producto.

Evidentemente, tendremos artefactos que definen el producto en sí, y que sufren cambios continuos durante el ciclo de vida de dicho producto. Para entendernos, hablamos de la especificación funcional, de la arquitectura, diseño de clases o bbdd, código, hardware, equipo de trabajo,... es decir, el MODELO, con mayúsculas, o todo lo que se va manteniendo desde el principio hasta el final.

Diferenciar claramente entre ambos conceptos (CASPER y MODELO) aclara enormente las cosas a la hora de gestionar documentación, cambios, requisitos o el proyecto en general.