Source: http://www.gazafatonarioit.com/2012/11/
Timestamp: 2017-12-17 10:09:23+00:00

Document:
Gazafatonario IT: noviembre 2012
Dicen el Dr. Jacobson y sus colegas que la materia prima de Casos de Uso 2.0 son los requisitos del software, el producto de software mismo y las pruebas que demuestren que el producto obedece a esos requisitos y los ejecuta a cabalidad.
En el corazón de Casos de Uso 2.0 están el caso de uso, la historia y la porción de caso de uso. Estos elementos capturan los requisitos y conducen el desarrollo del sistema. La Figura muestra como estos conceptos están relacionados entre sí. También muestra como los cambios y los defectos impactan el uso de Casos de Uso 2.0. [1]
Mapa Conceptual de Casos de Uso 2.0. Fuente: eBook "Use Case 2.0", Jacobson y otros.
Ya he hablado lo suficiente sobre Requisitos en general y de Casos de Uso en particular, así que hablemos de los demás conceptos que aquí encontramos:
Los Interesados son todas aquellas personas que de una u otra manera impactan del proyecto y se ven afectados por este y por el producto que se está construyendo. Todos ellos influencias directa o indirectamente al proyecto y no solo incluyen a los usuarios del sistema, sino también a los patrocinadores, a los ejecutivos, a otras áreas de la organización y a entidades externas relacionadas de alguna forma con la organización. A todos hay que tenerlos en cuenta a la hora de delimitar las funciones del sistema.
Uno de los principales mecanismos de comunicación entre los Interesados y el equipo de construcción es que los primeros nos cuenten historias a los segundos, sus Historias. Son narrativas acerca de lo que hacen y como lo hacen, con qué, con quién interactúan y qué intercambian. Estas narrativas son el alma de los casos de uso (no confundir con Historias de Usuario que son un repositorio de esas historias, como los son los casos de uso, los requisitos en prosa, los prototipos, los tableros de historias, entre otros).
En todo proyecto siempre hay Cambios, ya sea porque cambian las políticas de la organización, cambian las expectativas de los usuarios, cambia aspectos legales o contables, o cambian los interesados o los usuarios y estos últimos quieren otra cosa. Estos cambios seguramente modificarán las historias y, por consiguiente, los requisitos y los casos de uso. Incluso pueden requerir nuevas historias. Los cambios pueden llegar en cualquier momento y las porciones de casos de uso son una buena forma de analizar su impacto en el proyecto y de incluirlos en el producto.
Las Pruebas nunca deben faltar. Es lo único que asegura la calidad total del producto y deben verse como algo intrínseco al ciclo de vida del software. Como el software se implementó vía porciones de casos de uso, que ya incluyen los casos de prueba en su especificación, esta unión “software-pruebas” se hace finalmente indivisible, es uno de los grandes aspectos que nos enseña Casos de Uso 2.0 y una práctica excepcional. El hecho de que las pruebas hagan parte de la especificación de las porciones de casos de uso es a todas luces un paso más allá hacia la solución de una gran cantidad de inconvenientes que encontramos durante la práctica diaria de la construcción del software. Incluso, de esta forma, es posible implementar prácticas como Desarrollo Conducido por Pruebas (TDD por sus siglas en inglés –Test Driven Development) y otros métodos ágiles de desarrollo de software.
Durante las pruebas encontramos Defectos y mientras estos existan sabremos que la porción de casos de uso actual no está finalizada. Los defectos pueden ser encontrados durante una revisión par, en etapas tempranas del ciclo de vida e incluso de la iteración actual, durante la misma programación del sistema, con las pruebas unitarias u otro tipo de pruebas del programador, o mientras realizamos las pruebas de calidad final de cada porción de caso de uso y las pruebas de integración del sistema. En este punto juegan un papel muy importante el uso de herramientas para automatizar pruebas, como los Robots de pruebas.
Estos son algunos de los conceptos más importantes, inherentes a las prácticas expuestas en Casos de Uso 2.0. En el libro electrónico de Jacobson [1] encuentran más detalles sobre este modelo conceptual.
[1] El e-Book "Use Case 2.0", sobre las buenas prácticas alrededor del uso de los casos de uso, lo pueden encontrar en www.ivarjacobson.com.
Sobre Casos de Uso 2.0 pueden leer mi serie de artículos en este Gazafatonario:
Publicado por Lucho Salazar en 11:51 a.m. 2 comentarios: Enlaces a esta entrada
Etiquetas: Analista Funcional, Caso de Uso, casos de uso 2.0, Escritura de casos de uso, Essence, historias de usuario, porción de caso de uso, Requisitos
Publicado por Lucho Salazar en 11:29 a.m. No hay comentarios.: Enlaces a esta entrada
Etiquetas: Analista Funcional, Caso de Uso, casos de uso 2.0, Escritura de casos de uso, porción de caso de uso, Requisitos, Usuario Final
Publicado por Lucho Salazar en 4:50 p.m. No hay comentarios.: Enlaces a esta entrada
Cuando se trata de incluir casos de uso se escribe:
El sistema ejecuta el caso de uso “AQUÍ VIENE EL NOMBRE DEL CASO DE USO INCLUIDO”
Se ejecuta el caso de uso “AQUÍ VIENE EL NOMBRE DEL CASO DE USO INCLUIDO”
En este último caso se entiende que el único que ejecuta casos de uso incluidos es el sistema. Como en:
n. El sistema ejecuta el caso de uso “Verificar Lista Clinton”
n+1. Se ejecuta el caso de uso “Hacer Análisis de Riesgo”
La especificación de un caso de uso incluido se debe iniciar estableciendo los nombres de los casos de uso que incluyen este caso de uso, como en:
Donde n es el número del último paso del caso de uso incluido.
Recordemos que esta relación de inclusión se usa cuando queremos:
La primera opción se usa especialmente en casos de uso largos o complejos donde algunas partes del mismo no son relevantes para el sentido primordial del caso de uso y no son necesarias, en primera instancia, para entenderlo y aprobarlo. Por ejemplo, un caso de uso para Ingresar un Cliente de Naturaleza Jurídica puede solicitar docenas o cientos de datos que se pueden agrupar de acuerdo a algunos criterios como Datos Generales, Datos del Tipo de Entidad y Naturaleza Jurídica, Datos del Gerente o Representante Legal, Datos de los Contactos, Referencias Comerciales, entre otros. Algunos de estos grupos de datos pueden incluirse en casos de uso complementarios que son ejecutados desde el caso de uso principal.
La segunda posibilidad de inclusión es la reusabilidad de funcionalidad del sistema, es decir, cuando existe un comportamiento del sistema que se ejecuta en dos o más casos de uso de la misma manera, podemos usar un caso de uso incluido que represente ese comportamiento común. Por ejemplo, un caso de uso Verificar Centrales de Riesgo, que se ejecuta desde varios casos de uso de un sistema financiero, como Matricular Cliente, Revisar Solicitud de Crédito, Abrir Cuenta Corriente, entre otros.
Para conocer más acerca de relaciones entre casos de uso, pueden leer la Lectura Fundamental 12 Casos de Uso: de Extensiones y de Inclusiones en mi Gazafatonario IT:
La serie completa de estos consejos la encuentran en:
Publicado por Lucho Salazar en 11:53 a.m. 2 comentarios: Enlaces a esta entrada
Etiquetas: Analista del Software, Analista Funcional, Caso de Uso, casos de uso 2.0, Escritura de casos de uso, extends, historias de usuario, includes, porción de caso de uso, Requisitos, Usuario Final
Cuando el sistema realiza más de una de estas funciones se especifica la de mayor relevancia para el usuario. Por ejemplo: si para hacer un cálculo específico, el sistema debe buscar uno o más datos, se especifica el cálculo. Si el sistema clasifica u ordena un conjunto de datos para buscar uno o varios de ellos, se especifica la búsqueda. Si el sistema calcula y luego almacena, se puede decir “el sistema calcula SUJETO DE CÁLCULO y almacena DATOS A ALMACENAR” como en:
“El sistema calcula el interés corriente y almacena los datos del crédito.”
Publicado por Lucho Salazar en 11:01 a.m. No hay comentarios.: Enlaces a esta entrada
Etiquetas: Analista del Software, Caso de Uso, casos de uso 2.0, Escritura de casos de uso, historias de usuario, porción de caso de uso, Requisitos, Usuario
Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos, IV
Al escribir el caso de uso deben evitarse sinónimos “técnicos” para Sistema como “programa”, “módulo”, “rutina”, “función”, “procedimiento”, “procedimiento almacenado” y “subrutina”. Como en:
n. El programa solicita la fecha de ingreso
n+1. El actor proporciona la fecha de ingreso
n+2. El módulo calcula el número de días laborados hasta la fecha
Algunos de estos términos son usados de manera indistinta donde debemos usar siempre “sistema”, otros se usan en pasos específicos donde normalmente estamos suministrando información técnica que no es responsabilidad de los casos de uso, como cuando hablamos de procedimientos almacenados o de rutinas.
Simplemente usamos el término “sistema”.
Consideremos el siguiente caso de uso de la Web 2.0, relacionado con la publicación de entradas en un blog:
Caso de Uso: Publicar Artículo
Actor: Bloguero
Descripción: este caso de uso permite crear una entrada para su publicación en un blog específico de la Web.
1. El Bloguero está debidamente acreditado ante el Sistema
1. El caso de uso inicia cuando el Bloguero opta por publicar un nuevo artículo
2. El sistema solicita el título del artículo
3. El Bloguero ingresa el título del artículo
4. El sistema solicita el cuerpo del artículo
5. El Bloguero proporciona el cuerpo del artículo
6. El sistema solicita las palabras clave con las cuales indexar el artículo
7. El Bloguero ingresa las palabras clave del artículo
8. El sistema verifica que el título del artículo no existe y solicita confirmación para publicar la entrada
9. El Bloguero confirma la publicación del artículo
10. El sistema publica el artículo
Secuencia Alterna 1: el título de la publicación ya existe
8A. El sistema muestra el mensaje “El título del artículo ya existe. Por favor, verifique.”
8B. El caso de uso continúa en el paso 2 de la secuencia básica
Secuencia Alterna 2: el Bloguero cancela la publicación del artículo
9A. El Bloguero cancela la publicación de la entrada al Blog
9B. El caso de uso termina
Poscondiciones:
1. La entrada se puede modificar durante los siguientes 30 minutos.
2. El artículo puede ser leído por los lectores del blog.
Nótese que en todo momento sabemos qué hace el sistema y qué hace el actor.
Publicado por Lucho Salazar en 1:57 p.m. 1 comentario: Enlaces a esta entrada
Etiquetas: Analista del Software, Analista Funcional, Caso de Uso, casos de uso 2.0, Escritura de casos de uso, historias de usuario, Ingeniería de Software, porción de caso de uso, Requisitos, Usuario

References: artículo
2
 artículo
3
 artículo
4
 artículo
5
 artículo
6
 artículo
7
 artículo
8
 artículo
10
 artículo
9