x.x.x.

HISTORIAS DE USUARIO
Las Historias de Usuario representan una breve descripción del
comportamiento del sistema, se realizan por cada característica principal del
sistema y son utilizadas para cumplir estimaciones de tiempo y el plan de
lanzamientos, así mismo reemplazan un gran documento de requisitos y presiden
la creación de las pruebas de aceptación.

Cada historia de usuario debe ser lo suficientemente comprensible y

delimitada para que los programadores puedan implementarlas en unas semanas

La Plantilla a utilizarse para la elaboración de las historias de usuario se

muestra en la tabla 2 y cada uno de sus componentes se explica a continuación.
(Letelier & Penades, 2006)
Historia de Usuario
Número Usuario

Nombre historia Riesgo

(A lta / M edia / B aja)
Prioridad Complejidad
1- 5
Iteración asignada

Programador responsable

Descripción

Observaciones

Tabla xxx Plantilla para las historias de usuario

Número: Permite identificar a una historia de usuario.

Nombre Historia: Describe de manera general a una historia de usuario.
Prioridad en Negocio: Grado de importancia que el cliente asigna a una historia
de usuario.
Iteración Asignada: Número de iteración, en que el cliente desea que se
implemente una historia de usuario.
Usuario: Persona que utilizará la funcionalidad del sistema descrita en la historia
de usuario.
Complejidad: Complejidad de 1 a 5 identificada para esta historia de uaurio
Riesgo en Desarrollo: Valor de complejidad que una historia de usuario representa
al equipo de desarrollo.
Programador Responsable: Persona encargada de programar cada historia de
usuario.
Descripción: Información detallada de una historia de usuario.
Observaciones: Campo opcional utilizado para aclarar, si es necesario, el
requerimiento descrito de una historia de usuario.
x.x.x. TARJEAS DE INGENIERÍAS
En estas tarjetas, serán donde se realizan las tareas de ingeniería, apuntando
todas las tareas de programación requeridas durante el proceso de implementación
del sistema
Historia de Usuario __ Tarea de Ingenieria
Número de Tarea Puntos Estimados

Nombre de Tarea Tipo de Tarea

Fecha Inicio Fecha Fin

Programador responsable

Descripción

Tabla X.X.X. Modelo propuesto para una tarea de ingeniería

Fuente: Equipo Desarrollador

Historia de Usuario: Permite identificar a la historia de usuario origen de la tarea.

Número de Tarea: Permite identificar a una tarea de ingeniería
Nombre de Tarea: Describe de manera general a una tarea de ingeniería.
Puntos Estimados: Número de días que se necesitará para el desarrollo de una tarea
de ingeniería.

Tipo de Tarea: Tipo al que corresponde la tarea de ingeniería.

Fecha Inicio: Fecha inicial de la creación de la tarea de ingeniería.

Fecha Fin: Final concluida de la tarea de ingeniería.

Programador Responsable: Persona encargada de programar la tarea de ingeniería.

Descripción: Información detallada de la tarea de ingeniería.

x.x.x. TARJETAS DE PRUEBAS CAJA NEGRA
También, conocidas como Tarjetas de Pruebas de función, es donde, permite
comprobar que la historia de usuario fue correctamente implementada.
Caso de Ingenieria de Caja Negra
Historia de Usuario
N ro C O D IG O

Descripción

Condiciones de Ejecución

Entrada / Pasos de Ejecución

Resultado Esperado

Evaluación de la Prueba

Tabla x,x,x. Modelo propuesto para una prueba de aceptación

Fuente: Equipo Desarrollador

Historia de usuario Nro.:: Nro. de Historia de Usuario Relacionada a la Prueba.

Historia de usuario Nombre.:: Nombre de Historia de Usuario Relacionada a la

Prueba.
Codigo: Nº Único, permite identificar la prueba de aceptación.

Descripción: Información detallada de prueba ejecutada.

Condiciones de Ejecución: Condiciones previas que deben cumplirse para realizar la

prueba de aceptación.

Entrada / Pasos de Ejecución: Pasos que siguen los usuarios para probar la
funcionalidad de la historia de usuario.
Resultado Esperado: Respuesta del sistema que el cliente espera, después de haber
ejecutado una funcionalidad

Evaluación de la Prueba: Nivel de satisfacción del cliente sobre la respuesta del

sistema. Los niveles son: Aprobada y No Aprobada.
x-x-x TARJETAS CRC ( CLASE – RESPONSABILIDADES –COLABORADORES)

Estas tarjetas CRC permiten conocer que clases componen el sistema y

cuales interactúan entre sí. se dividen en tres secciones que contienen la
información del nombre de la clase, sus responsabilidades y sus colaboradores.

Nombre de la Clase

Responsabiliddes Colaboradores
|

Tabla x,x,x. Modelo propuesto para una tarjeta CRC

Fuente: Equipo Desarrollador
“Una clase es cualquier procedimiento o función, pantalla o reporte. Las
responsabilidades de una clase son: las cosas que conoce y las que realiza, sus
atributos y métodos. Los colaboradores de una clase son las demás clases con las
que trabaja en conjunto para llevar a cabo sus responsabilidades.
En la práctica conviene tener pequeñas tarjetas de cartón, que se llenarán y que
son mostradas al cliente, de manera que se pueda llegar a un acuerdo sobre la
validez de las abstracciones propuestas.” [Fuente: es.wikipedia.org/wiki/
Tarjetas_CRC]
Los pasos a seguir para llenar las tarjetas, son las siguientes:
 Encontrar clases. Para encontrar las clases se debe pensar, qué cosas
interactúan con el sistema (en nuestro caso el usuario), y qué cosas son parte
del sistema, así como las pantallas útiles a la aplicación (un despliegue de
datos, una entrada de parámetros y una pantalla general, entre otros).
 Encontrar responsabilidades. Una vez que las clases principales han sido
encontradas se procede a buscar los atributos y las responsabilidades, para
esto se puede formular la pregunta ¿Qué sabe la clase? Y ¿Qué hace la
clase?
 Definir colaboradores. Finalmente se buscan los colaboradores dentro de la
lista de clases que se tenga.
 Disponer las tarjetas.
x-x-x TARJETAS DE PRUEBAS DE ACEPTACIÓN.
También, conocidas como Tarjetas de Pruebas de función, es donde, permite
comprobar que la historia de usuario fue correctamente implantada correctamente,
esta prueba se realiza conjuntamente con él usuario..
Caso de Prueba de Aceptación Cliente
Historia de Usuario
N ro C O D IG O

Descripción

Condiciones de Ejecución

Entrada / Pasos de Ejecución

Resultado Esperado

Evaluación de la Prueba

Tabla x,x,x. Modelo propuesto para una prueba de aceptación

Fuente: Equipo Desarrollador

Historia de usuario Nro.:: Nro. de Historia de Usuario Relacionada a la Prueba.

Historia de usuario Nombre.:: Nombre de Historia de Usuario Relacionada a la
Prueba.
Codigo: Nº Único, permite identificar la prueba de aceptación.

Descripción: Información detallada de prueba ejecutada.

Condiciones de Ejecución: Condiciones previas que deben cumplirse para realizar la

prueba de aceptación.

Entrada / Pasos de Ejecución: Pasos que siguen los usuarios para probar la
funcionalidad de la historia de usuario.
Resultado Esperado: Respuesta del sistema que el cliente espera, después de haber
ejecutado una funcionalidad

Evaluación de la Prueba: Nivel de satisfacción del cliente sobre la respuesta del

sistema. Los niveles son: Aprobada y No Aprobada.