SISTEMAS 1 HISTORIAS DE USUARIO Y CASOS DE USO

SISTEMAS 1

HISTORIAS DE USUARIO

y CASOS DE USO

Enunciado Trabajo Final

Historia de usuarios 3

Definición y contexto 3

Algunas características que deben cumplir las historias de usuario son: 4

Otros criterios (INVEST): 5

Plantilla de historias de usuario 6

Recomendaciones previas a su uso. 6

Formato 6

El enunciado de la historia de usuario 7

Una vez se definen estos componentes, 8

Los criterios de aceptación 9

Beneficios: 10

Limitaciones: 10

Casos de usos 11

Definición: 11

Elementos: 12

Tipos de actores 13

Descripción de los casos de uso 15

Elementos para la descripción de un Caso de Uso: 16

ALTERNATIVAS 17

Beneficios de los casos de uso 18

NORMAS DE APLICACION 18

Diagrama de casos de uso 19

Relación de casos de estudio: 22

Tarjetas con historias del usuario para el proyecto del curso. 24

Diagrama de contexto 25

Descripción de 2 casos de Uso 26

Bibliografia 27

Historia de usuarios

Definición y contexto

Las historias de usuario son un instrumento para el levantamiento de requerimientos para el desarrollo de un software, que ha emergido con la aparición de los nuevos marcos de trabajo de desarrollo ágil

Las historias de usuario son un conjunto de fichas escritas por [[nombre del cliente]] que indican las funciones que debe realizar el sistema, constituyendo el mecanismo base de captura de requerimientos de la programación extrema.

Al redactar una historia de usuario deben tenerse en cuenta describir el Rol, la funcionalidad y el resultado esperado de la aplicación en una frase corta. Adicionalmente, debe venir acompañada de los criterios de aceptación, no más de 4 por historia, redactado también en una frase que incluya el contexto, el evento y el comportamiento esperado ante ese evento.

Cada historia de usuario incluye una breve descripción, en torno a tres sentencias de texto escritas por el cliente en su terminología, es importante procurar no incluir sintaxis técnica, de modo que se centren en las necesidades y no en la especificación del aspecto de las interfaces de usuario ni en la implementación, como base de datos o algoritmos específicos.

Al momento de implementar las historias, los desarrolladores deben tener la posibilidad de discutirlas con los clientes. El estilo sucinto de las historias podría dificultar su interpretación, podría requerir conocimientos de base sobre el modelo o podría haber cambiado desde que fue escrita.

Cada historia de usuario debe tener en algún momento pruebas de validación asociadas, lo que permitirá al desarrollador, y más tarde al cliente, verificar si la historia ha sido completada. Como no se dispone de una formulación de requisitos precisa, la ausencia de pruebas de validación concertadas abre la posibilidad de discusiones largas y no constructivas al momento de la entrega del producto.

Algunas características que deben cumplir las historias de usuario son:

Independientes. Deben ser atómicas en su definición. Es decir, se debe intentar que no dependa de otras historias para poder completarla.

Negociables. Deben ser ambiguas en su enunciado para poder debatirlas, dejando su concreción a los criterios de aceptación.

Valoradas. Deben ser valoradas por el cliente. Para poder saber cuanto aporta al Valor de la aplicación y junto con la estimación convertirse en un criterio de prioridad.

Estimables. Deben tener su alcance lo suficientemente definido como para poder suponer una medida de trabajo en la que pueda ser completarla.

Pequeñas. Para poder realizar una estimación con cierta validez y no perder la visión de la Historia de Usuario, se recomienda que sean mayores de dos días y menores de dos semanas.

Verificables. Este es el gran avance de las Historias de Usuario. Que, junto con el cliente, se acuerdan unos Criterios de Aceptación que verifican si se ha cumplido con las funcionalidades descritas y esperadas.

Como las historias de usuario pueden llegar a ser de libre interpretación, éstas se deben detallar de alguna manera, para esto, en la parte posterior de la tarjeta o en el campo de descripción de las herramientas de gestión de proyectos, se expondrá el detalle claro y conciso que corresponde a la tarjeta.

Otros criterios (INVEST):

Las historias de usuario deben cumplir con el principio INVEST:

Independent (Independiente): la historia de usuario no debe depender de otra historia ya que esto facilitará la priorización de las mismas. Si por alguna razón la historia de usuario es dependiente se recomienda fusionarlas.

Negotiable (Negociable): la historia de usuario puede cambiar y evolucionar a lo largo de la ejecución del proyecto, incluso podría dejar de tenerse en cuenta si así el cliente lo desea.

Valuable (Valiosa): la historia de usuario debe brindar valor al proyecto y al usuario final.

Estimable (Estimable): la historia de usuario debe tener el tiempo que ésta tomará en implementarse.

Small (Pequeña): la historia de usuario debe ser pequeña y concisa. Si una historia de usuario es muy grande ésta se debe dividir en otras historias más pequeñas, esto con el fin de poder tener un mejor control sobre ellas.

Testeable: la historia de usuario debe poderse probar en un proceso

...