Casos de Uso 2.0

No hace mucho, Ivar Jacobson, junto a Ian Spence y a Kurt Bittner, publicó el eBook "Use Case 2.0", sobre cómo mejorar el uso de los casos de uso.

Casos de Uso 2.0 se trata de una práctica para capturar requisitos y guiar la construcción del software.

Un caso de uso tiene una meta bien establecida, una estructura de historia entendida por todos los involucrados en el proyecto, pero también un conjunto de historias que el sistema debe satisfacer o cumplir, incluyendo la más simple, la cual es la historia más simple que le permite al usuario alcanzar la meta.

Todo esto se puede conseguir a partir del concepto que nos presenta Jacobson, la porción del caso de uso, que es una o más historias seleccionadas de un caso de uso para formar un elemento de trabajo que es de valor claro para el usuario. La porción actúa como un contenedor para todo el trabajo requerido para completar la implementación de las historias seleccionadas. Las porciones de casos de uso son más que requisitos y casos de prueba y evolucionan para incluir las porciones correspondientes a través del diseño, la implementación y las pruebas.

Las porciones de caso de uso: 

• Posibilitan que los casos de uso sean divididos en unidades de trabajo más pequeñas e independientemente entregables. 
• Posibilitan que los requisitos contenidos en un conjunto de casos de uso sean ordenados, priorizados y tratados en paralelo.
• Enlazan los distintos modelos de un sistema (requisitos,  análisis, diseño, implementación y pruebas) usados en el desarrollo dirigido por casos de uso.

Según Jacobson, la receta es sencilla: primero se identifica la función más útil que el sistema debe hacer y nos enfocamos en ello. Luego tomamos esa función más útil y la dividimos en porciones más pequeñas. Y después seleccionamos la porción más importante, una que "viaje" de principio a fin a través del proceso de desarrollo. Con el equipo de trabajo, estimamos el desarrollo y comenzamos a construir. Luego añadimos los casos de prueba previamente definidos para esa porción.

Ahora repetimos esto mismo mientras haya más porciones y más casos de uso que dividir. Así, el sistema lo vamos entregando por incrementos, "cada incremento se construye sobre el incremento previo para adicionar más funcionalidad o mejorar la calidad de lo que se ha hecho antes. 

Casos de Uso 2.0 es una práctica liviana, escalable, versátil y fácil de usar. El documento comienza presentando los principios básicos:

1. Mantenerlo simple contando historias

1. Entender el cuadro completo

1. Enfocarse en el valor

1. Construir el sistema por partes

1. Entregar el sistema en incrementos

1. Adaptarse para cubrir las necesidades del equipo.

Casos de Uso 2.0 es para todo tipo de sistemas; es para manejar todo tipo de requisitos,  incluyendo los no funcionales; puede aplicarse con cualquier estrategia de desarrollo o método; se puede escalar para cubrir todas nuestras necesidades en materia de desarrollo de software.

¿Demasiada documentación?

Si hacemos esta pregunta a casi todos los stakeholders de un proyecto seguro que nos contestan que sí, que hay demasiados entregables y que esto retrasa las fechas del proyecto. He dicho "a casi todos" porque seguro que al equipo de metodología del proyecto no le parecerán demasiados.
La realidad es que los entregables debe ser algo que debería fijar el propio cliente. Dentro de la ingeniería de Requisitos, los Requisitos Organizacionales forman parte de los Requisitos No Funcionales, y describen aspectos como:

• Procesos estándar utilizados.
• Fechas de entrega.
• Documentación a entregar. Una subcategoría definida como Requisitos de Entrega.
• etc.,.

Nosotros podemos (y debemos) ayudar al cliente a identificar sus necesidades, pero debemos llegar a un consenso en los entregables que debe recibir. Le debemos recordar que los entregables forman parte de su propia necesidad como dueño del producto software. No se hacen porque los desarrolladores quieran sino porque el cliente lo necesita como parte del producto.
Por supuesto, nuestra obligación también es intentar encontrar un nivel de documentación que no sea excesivo pero sí suficiente.

La documentación en el desarrollo de software

A menudo nos encontramos con los siguientes problemas:

• Falta de documentación.
• Exceso de documentación.
• La persona que ha escrito la documentación no está disponible.
• Contenido erróneo de documentación.
• Documentación desactualizada.
• La documentación no sigue el formato establecido según las normas de calidad.
• No contiene control de cambios.
• La documentación se contradice.
• No hay una norma establecida para la gestión de la documentación.
• La documentación no tiene las referencias ni fuentes que corresponden.
• Cada equipo de trabajo gestiona de forma diferente la documentación.
• La documentación fue elaborada con un software que ya no tenemos.

Debemos realizar una documentación de calidad. Debe ser un instrumento que sirva como herramienta para un desarrollo debiendo estar ajustada a las posibilidades y contexto del proyecto.

La documentación debe ser la precisa, ni más ni menos y por ese motivo debe ser el proyecto el que determine la que resulta necesaria.

Debemos distinguir entre varios tipos de documentación a la hora de elegir el tipo y la profundidad de la documentación:

• La documentación que se utiliza a lo largo del desarrollo del proyecto pero que no forma parte de la versión definitiva del producto software.
• La documentación que se utiliza como contrato con el cliente de lo que se va a realizar en el proyecto.
• La documentación que forma parte de los entregables del proyecto.

Respecto del formalismo en la documentación, aunque se puede ser flexible es importante que se siga homogeneidad. Se puede partir de un conjunto de plantillas estándar y negociarlas con el cliente con el fin de que se encuentre cómodo con lo que recibirá.

Una documentación de alta calidad no es el resultado de los formalismos que se establezcan sobre la misma sino por la adecuación de sus contenidos a los propósitos del proyecto. Tener una documentación de un proyecto perfecta a nivel formal no asegura que el producto final satisfaga las expectativas que se tenían puestas en él, lo único que asegura es la inversión de un esfuerzo que se podría haber utilizado para entregar un producto más depurado.

Publicado con Blogsy