Giving an agile flavor to Use Case documentationRegional Scrum Gathering Ecuador 2015

(Universidad de Las Américas)

José Cahuana Turpojcahuana@ucsm.edu.pe

Walter A. Carpio wcarpiom@ucsm.edu.pe@wcarpiom

1

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

Estado del arte

- Use cases- User stories- Persona stories

3

Terminología

User Stories Acceptance Test

CodeTest green - TDD

Test green - AT Working Software

4

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.

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/

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.

Casos de uso

8

Constituye un aspecto del software que enmarca el comportamiento requerido.

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

Fuente: J. Braz (2008)

Formatos de especificación de los Use Cases

11

Fuente: Dr Simon Spacey

12

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

Algunos númerosUser 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

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.

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.

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

19

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.

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.

Demo

22

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

Trabajos a futuro

24

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