A proposal is developed to get use case documentation according the second value of agilism. It complements a use case to be executable. Presentation given at "Regional Scrum Gathering Ecuador 2015"

1. Giving an agile flavor to
Use Case documentation
Regional Scrum Gathering Ecuador 2015
(Universidad de Las Américas)
José Cahuana Turpo
jcahuana@ucsm.edu.pe
Walter A. Carpio
wcarpiom@ucsm.edu.pe
@wcarpiom
1

2. Agenda
● Introducción
○ Estado del arte
○ Terminología
○ Formatos
● Desarrollo
○ Formalización
○ Algunos números
○ Caso de estudio
○ Aplicación de la propuesta
○ Demostración
● Conclusiones y trabajos futuros
2

3. Estado del arte
- Use cases
- User stories
- Persona stories
3

4. Terminología
User Stories
Acceptance
Test
CodeTest green - TDD
Test green - AT Working Software
4

5. Pruebas de aceptación (AT)
5
● Son las pruebas que configuran los criterios de aceptación por parte del
usuario. El enfoque está basado en pruebas de caja negra, donde el
usuario en base a lo que ve en la interfaz, prueba la funcionalidad y
demás atributos del software.

6. Desarrollo basado en pruebas (TDD)
6
● En un desarrollo basado en pruebas, las pruebas son el proceso inicial de
todo el desarrollo del software. Luego se produce el código mínimo
necesario para superar las pruebas.
Extraído de http://crowdsourcetesting.com/test-driven-development/

7. Desarrollo basado en pruebas de aceptación (ATDD)
7
● Es un tipo particular de TDD, donde cada prueba representa un requerimiento que pueda ser
probado, entonces la prueba de aceptación se va a dar por el comportamiento que muestre el
sistema, respecto de la funcionalidad solicitada.
● Algo importante de este desarrollo es que fomenta la comunicación entre el cliente y el
desarrollador.

8. Casos de uso
8
Constituye un aspecto del software que enmarca el comportamiento requerido.

9. User Story
9
● Una user story es la descripción de la funcionalidad solicitada que tiene un
valor intrínseco.
● Previo a dicha descripción, se conversa con el usuario respecto de su
situación, y de sus necesidades.

10. 10
Fuente: J. Braz (2008)
Formatos de especificación de los Use Cases

11. 11
Fuente: Dr Simon Spacey

12. 12

13. 13Fuente: Gong Zhang, Tao Yue y Shaukat Ali (2013)

14. Algunos números
User stories
Use cases
Customer Oriented
Main success scenario
Story points
Faster and shorter
Model interaction
Many scenarios
Use case points
More time for analysis and writing
14Fuente: Ambysoft, url: http://www.ambysoft.com/surveys/howAgileAreYou2013.html

15. Formalización de un Caso de Uso
15
Sea un UC un caso de uso representado por la tupla
(A, d, F), donde:
-A es el conjunto de actores.
-d es la descripción de la funcionalidad requerida.
-F es un conjunto de flujos básico y alternativos.

16. Formalización de una Historia de Usuario
16
Sea una US una User Story representada por la tupla
(A, s, F, O), donde:
-A es quien necesita la funcionalidad.
-s es la historia del usuario que provocó la necesidad.
-F es la expresión de la necesidad.
-V es el valor que tiene la necesidad para el usuario.

17. Caso estudio
17
● Se desea especificar las necesidades de una biblioteca.
● El usuario puede buscar en el inventario de publicaciones.
● La información de cada publicación será mostrada en una ficha individual.
● Se deben poder administrar préstamos de las publicaciones.

18. 18

19. 19

20. Formalización de un test de aceptación
20
Sea un AT (Test de aceptación) una tupla formada por (F,
S, d, A), donde
-F es un feature a comprobar.
-S es el conjunto de steps que componen el feature.
-d es el conjunto de funciones de implementación para cada
step, donde una de esas funciones di es la que comprueba
si se alcanza el estado de aceptación.
-A es el estado de aceptación para la prueba.

21. Formalización: Resultado
21
Sea un UC-S (satisfiable use case) una tupla formada por
(A, d, F, ATs), donde
-A, d y F corresponden a la definición habitual de un UC, y
-ATs es un conjunto de funciones booleanas, que luego de su
ejecución, todas dan true. En caso alguna de false producto
de un test de regresión, se realiza una verificación del
sistema, hasta que sea totalmente satisfecha.

22. Demo
22

23. Conclusiones
23
1. Uno de los inconvenientes de los casos de uso es que no son ejecutables.
2. Los criterios de aceptación agregados a la especificación de casos de uso
sí se pueden automatizar.
3. La propuesta se ajusta al segundo valor del agilismo: se prefiere software
funcionando a la documentación exhaustiva.
4. Las especificaciones de los flujos principal o alternos en los casos de uso,
generan procesos de pruebas manuales.
5. Se automatizan las pruebas que protegen contra daños colaterales.
6. Los tests de aceptación facilitan las pruebas de regresión

24. Trabajos a futuro
24
● UC-S para requerimientos no funcionales.
● Generación automática de informe de pruebas.