Metodologia XP

UNIVERSIDAD NACIONAL DE
TRUJILLO
FACULTAD DE CIENCIAS FÍSICAS Y
MATEMÁTICAS
ESCUELA DE INFORMÁTICA

MONOGRAFÍA

METODOLOGÍAS ÁGILES
PROGRAMACIÓN EXTREMA XP
AUTORES:
BALAREZO PENADILLO JOEL MARCOS
CRUZ VASQUEZ EVELING GISELLE
LAMADRID BRINGAS FRANSHESCA
GUADALUPE – PERU
2013

INDICE

DEDICATORIA

3

INTRODUCCION

4

1. MARCO TEÓRICO

5

1.1 METODOLOGÍA EXTREME PROGRAMMING (XP)

5

1.1.1 Definición De Xp

5

1.1.2 Valores XP

6

1.1.3 Principales Conceptos

8

1.1.4 Ciclo de vida del XP

10

1.1.5 Ciclo de vida del programador

13

1.1.6 Roles Y Responsabilidades

15

1.1.7 Artefactos XP

16

1.1.8 Ventajas y Desventajas

20

2. PLICACIÓN DE LA METODOLOGÍA XP

21

2.1 DESCRIPCIÓN DEL PROYECTO

21

2.1.1 Historias de usuario

22

2.1.1.1

Historia de usuario – iteración 1

26

2.1.1.2


31

2.1.1.3


37

2.1.2 Casos de prueba de aceptación

40

2.1.3 Tarjetas CRC

45

CONCLUSIONES

49

BIBLIOGRAFÍA

50

Universidad Nacional de Trujillo

Página 2

Esta monografía es el resultado del esfuerzo
conjunto de todos los que formamos el grupo de
trabajo. Por esto agradecemos a nuestro profesor,
Ing. Arturo Díaz Pulido, a quien le debemos gran
parte de nuestros conocimientos, gracias a su
paciencia y enseñanza

y finalmente un eterno

agradecimiento a nuestra prestigiosa universidad
la cual nos prepara para un futuro competitivo y
nos forma como personas de bien.


Página 3

INTRODUCCIÓN

La metodología ágil es importante durante el desarrollo del software, pero como
elegir una metodología que sea eficiente y nos ayude con el desarrollo del
proyecto.
Para elegir esta metodología tendría que lograr un código sin errores, con alta
funcionabilidad, manteniendo a cliente al tanto del proyecto y en plazos de tiempo
cómodos.
La Metodología de “Programación Extrema” (XP) propone la manera de alcanzar
esos objetivos.
Esta Metodología consiste en un conjunto de prácticas, fundamentadas en valores
que deben de mantener los participantes de proyecto que, a manera de trabajo en
grupo, pretende lograr como producto final un software con un muy alto grado de
calidad.
Las etapas que recomienda seguir esta metodología se plantean de manera
sencilla pero a la vez son estrictas, y se inspiran en la total participación de los
involucrados.
Por lo cual el presente informe nos presentará la metodología xp, sus valores,
principales conceptos entre otros.


Página 4

1. MARCO TEÓRICO

1.1 METODOLOGÍA EXTREME PROGRAMMING (XP)

1.1.1

Definición De Xp

Fue formulada por Kent Beck, autor del primer libro sobre la materia, Extreme
Programming Explained: Embrace Change (1999). Es el más destacado de
los procesos ágiles de desarrollo de software.
La programación extrema es una metodología de desarrollo ligero (o ágil)
basada en una serie de valores y de prácticas de buenas maneras que
persigue el objetivo de aumentar la productividad a la hora de desarrollar
programas.
En XP se realiza el software que el cliente solicita y necesita, en el momento
que lo precisa, alentando a los programadores a responder a los
requerimientos cambiantes que plantea el cliente en cualquier momento. Esto
es posible porque está diseñado para adaptarse en forma inmediata a los
cambios, con bajos costos asociados, en cualquier etapa del ciclo de vida. En
pocas palabras, XP “abraza” el cambio.

Figura 1. Kent Beck, creador de la
Metodología XP


Página 5

1.1.2

Valores Xp

Para poder implementar las prácticas que presenta XP hay que conocer
cuáles son los valores principales. Estos valores son:
1.1.2.1 Comunicación
Muchos de los problemas que existen en proyectos de software (así como
en muchos otros ámbitos) se deben a problemas de comunicación entre las
personas.
La comunicación con el cliente es de vital importancia en XP y es por este
motivo que el cliente es integrado al equipo. De esta forma, cualquier duda
sobre los requerimientos puede ser evacuada inmediatamente. Además, se
planifica con el cliente y este puede estar al tanto del avance del proyecto.
XP ha sido diseñada para minimizar el grado de documentación como forma
de comunicación, haciendo énfasis en la interacción personal. De esta
manera se puede avanzar rápidamente y de forma efectiva, realizando solo
la documentación necesaria.

1.1.2.2 Simplicidad
XP propone una regla muy simple: “hacer algo que funcione de la manera
más sencilla”. En el caso de tener que añadir nueva funcionalidad al sistema
se deben examinar todas las posibles alternativas y seleccionar la más
sencilla.
La programación XP no utiliza sus recursos para la realización de
actividades, sólo se desarrolla lo que el cliente demanda, de la forma más
sencilla.

1.1.2.3 Feedback (Retroalimentación)
Brindar un feedback correcto y preciso hace que se pueda mantener una
buena comunicación y conocer el estado actual del proyecto. Ésta se
presenta en los dos sentidos:


Página 6



Por parte del equipo de trabajo hacia el cliente, de esta manera,

el cliente está al tanto del avance del proyecto. Además, el sistema es
puesto en producción en menor tiempo, con lo cual los programadores
saben si realizaron un buen trabajo y si sus decisiones fueron acertadas.


Desde el cliente hacia el equipo de trabajo, cuando un cliente

escribe sus stories los programadores realizan la estimación de cada
una de ellas y el cliente puede obtener inmediatamente el feedback
sobre la calidad de dichas stories.

1.1.2.4 Coraje
El coraje es poder realizar cambios cuando algo no funciona del todo bien,
diseñar e implementar solo lo necesario para el presente, pedir ayuda o
reducir el alcance de una entrega si el tiempo no alcanza. Si no hay coraje
en un proyecto no se puede clasificar como extremo y es necesario que los
otros tres valores estén presentes.

Figura 2. Valores XP


Página 7

1.1.3

Principales Conceptos

Antes de comenzar a profundizar sobre la forma de trabajo de XP es bueno
tener en claro algunos conceptos que son básicos en esta metodología. A
continuación se detallan los más importantes.
 Story Cards

Las story cards sirven para registrar los requerimientos de los clientes y
son utilizadas para poder realizar la estimación de cada una de las
iteraciones durante la fase de planificación. Las story cards son escritas
por los clientes en base a lo que se estima es necesario para el sistema.
Están escritas en un formato de oraciones en la terminología del cliente,
sin necesidad de sintaxis técnicas. También son utilizadas para poder
crear los test de aceptación. Por lo general se necesitan uno o más test de
aceptación para verificar que la story ha sido implementada correctamente.
Las story cards solo proveen suficiente detalle para poder realizar la
estimación de cuando tardará en ser implementada dicha funcionalidad.
Cuando el tiempo es calculado el programador se encarga de solicitarle al
cliente una descripción más detallada de los requerimientos. Otra diferencia
entre las stories y los documentos tradicionales es que se centran en lo que
el cliente necesita.
Cada story puede llevar entre 1 a 3 semanas en ser desarrollada en un
desarrollo ideal.
El número ideal para poder crear un plan de entregas es entre 20 y 80
stories.


Página 8

 Iteración

Consta de un período de una a dos semanas en las cuales el cliente
selecciona las stories en ser desarrolladas. Luego de ser implementadas
este cliente corre sus test funcionales para ver si la iteración puede
terminar de manera exitosa.
Otro punto que no debe ser pasado por alto es el tema de la duración de
cada iteración. Con iteraciones cortas se pretende que el equipo tenga
objetivos a corto plazo y pueda ver el resultado de su trabajo cada cierto
tiempo y no esperar varios meses para ver si lo que se hizo estuvo bien o
no.
También debemos considerar que las iteraciones cortas permiten hacer un
diagnóstico prematuro de la situación del proyecto, con lo cual no se debe
esperar mucho tiempo en detectar posibles problemas.


Refactoring

Consiste en realizar cambios al sistema sin modificar la funcionalidad del
mismo para poder hacer el sistema más simple, para aumentar la
eficiencia o para que el código sea mucho más entendible.


Release

La idea de cada release es poder tener un producto intermedio al final de
cada iteración en la cual el cliente pueda testear la funcionalidad pedida.
Con esto los clientes pueden, además, ver el avance del proyecto y poder
realizar comentarios a los programadores y no esperar hasta el final del
mismo cuando esté todo integrado.



Test de aceptación

Los test de aceptación representan algún tipo de resultado por parte del
sistema. Los clientes son los responsables de verificar la exactitud de
estos test y de revisar los resultados para poder así priorizar los test que
fracasaron.


Página 9

Una story no es aceptada hasta que haya pasado su test de aceptación.
Esto significa que en cada iteración se deben realizar nuevos test de
aceptación o de lo contrario el equipo tendrá una avance de cero.
 Test unitario
Son realizados desde el punto de vista del programador y sirven, además
de testear el código, para poder realizar el refactoring del mismo. Cada
programador, antes de comenzar a programar, debe preparar los test
unitarios. Esto hace que dichos test estén preparados para ser corridos
durante la codificación y además, hace que al programador le surjan dudas
y pueda evacuarlas con el cliente antes de empezar con la codificación.

1.1.4

El Ciclo De Vida De Xp

El ciclo de vida ideal de XP consiste de seis fases:
 Exploración
En esta fase los clientes realizan las story cards que desean que estén
para la primera entrega. Cada story describe una de las funcionalidades
que el programa tendrá. Al mismo tiempo el equipo de desarrollo se
familiariza con las herramientas, la tecnología y las prácticas a ser
utilizadas durante el proyecto. La duración de esta fase puede extenderse
desde unas pocas semanas a varios meses dependiendo de la adaptación
del equipo de desarrollo.
La clave es darle rápidamente al cliente una feedback de las primeras
stories para que aprendan en seguida a como especificar lo que los
programadores necesitan.
 Planificación
El propósito de esta fase es el de llegar a un acuerdo entre los clientes y
los programadores en cuáles serán las stories a ser implementadas
durante cada iteración. Si se hace una buena preparación durante la fase
de exploración esta actividad no suele llevar más de un día o dos. La
entrega del primer release debe tomar entre dos a seis meses de duración.


Página 10

Si se planifica realizarla en menos tiempo es probable que no se tengan los
elementos necesarios para solucionar los problemas más significativos.
Pero si se tarda más de este período se corre el riesgo que el cliente no
quede satisfecho.
 Iteraciones por entregas
Una vez elegido el orden en el cual se implementarán las stories se
procede a definir cuantas iteraciones serán necesarias para el proyecto.
Cada iteración tiene una duración de una a cuatro semanas, en las cuales
se realizan los test funcionales para cada una de las stories a ser
implementadas.
Al final de cada iteración el cliente debe analizar que todas las stories estén
implementadas. Debe también correr todos los test funcionales y que estos
resulten ser exitosos.
 Producción
Requiere de pruebas adicionales y revisiones de rendimiento antes de que
el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben
tomar decisiones sobre la inclusión de nuevas características a la versión
actual, debido a cambios durante esta fase. Las ideas que han sido
propuestas y las sugerencias son documentadas para su posterior
implementación (por ejemplo, durante la fase de mantenimiento).
 Mantenimiento
En esta fase se debe agregar nueva funcionalidad, mantener el sistema
corriendo e incorporar nuevos integrantes al equipo. Se hacen los
refactoring que no se pudieron realizar anteriormente. Además, se prueba
la nueva tecnología que se va a utilizar en el próximo release o migrar a
nuevas versiones de la tecnología que se está utilizando. También se suele
experimentar con nuevas ideas para la arquitectura actual y el cliente suele
escribir nuevas stories que puedan mejorar el sistema.


Página 11

 Muerte
Es cuando el cliente no tiene más historias para ser incluidas en el
sistema. Esto requiere que se satisfagan las necesidades del cliente en
otros aspectos como rendimiento y confiabilidad del sistema. Se genera la
documentación final del sistema y no se realizan más cambios en la
arquitectura.
La muerte del proyecto también ocurre cuando el sistema no genera los
beneficios esperados por el cliente o cuando no hay presupuesto para
mantenerlo.

Figura 3. Ciclo de vida de XP


Página 12

1.1.5

Ciclo De Vida Del Programador

Éste ciclo de vida indica cómo trabajan los programadores para poder
codificar. A continuación se detallan cada una de las actividades:
1.1.5.1 Elección de pares


Toda la producción se realiza en pares.



El encargado de escribir piensa tácticamente, su pareja piensa
estratégicamente.



Se rotan los roles periódicamente.

1.1.5.2 Testing


Se escriben los testing unitarios.



Se verifica que los test fallen antes de codificar.



Se testea todo lo que posiblemente puede fallar.

1.1.5.3 Codificación


“Hacer algo que funcione de la manera más sencilla”



Implementar lo suficiente para hacer que el test pase.



Seguir el estándar de codificación.

1.1.5.4 Refactoring


Quitar toda porción de código que no parezcan estar bien y luego
verificar si el código aún pasa los test unitarios.



El código debe ser claro, no tener partes duplicadas y tener la menor
cantidad de clases y métodos posibles.



Realizar cambios pequeños y luego realizar los test unitarios.


Página 13

1.1.5.5 Q & A


El cliente puede proveer rápidamente cualquier respuesta on-site.



Muchas preguntas requieren decisiones y el cliente debe estar
preparado para poder hacerlas.



El cliente suele escribir una story o un test de aceptación que
captura sus preguntas.

1.1.5.6 Integración


Llevar el código a la máquina donde se realiza la integración, unir el
sistema y correr todos los test.



Arreglar todos los errores para que pasen todos los test unitarios.



Si no es fácil la integración es mejor tirar todo y comenzar
nuevamente al día siguiente.

1.1.5.7 Retornar al inicio


Si resta tiempo, se puede elegir otra pareja o cambiar de roles y
comenzar con otra actividad.


Página 14

1.1.6

Roles Y Responsabilidades

Existen diferentes roles (actores) y responsabilidades en XP para diferentes
tareas y propósitos durante el proceso, a continuación se detallan los más
importantes:


Cliente (Customer)

Es parte del equipo y es quien establece que es lo que debe realizar el
sistema, tomando la decisión de cuando se debe implementar determinada
funcionalidad, así como también en el orden a ser implementadas. Además,
el cliente escribe las story cards y los test funcionales y decide cuando cada
requerimiento está satisfecho. Los clientes también priorizan cada uno de los
requerimientos.



Entrenador (Coach)

Es el líder del equipo, toma las decisiones más importantes. Además es el
encargado de asegurar el cumplimiento de todas las prácticas, transmitiendo
sus conocimientos y experiencia al resto del equipo.


Consultant

Es una persona externa al equipo que posee el conocimiento técnico
necesario para poder ayudar al equipo con determinados problemas.


Programador

Es el responsable de escribir los testing del sistema y mantener el código lo
más simple y definitivo posible. El primer aspecto a tener en cuenta para que
XP sea exitoso es la coordinación entre los programadores y el resto del
equipo.


Probador (Tester)

Los tester ayudan a los clientes a escribir los test funcionales del sistema.
Además, corren dichos testing regularmente, envían los informes con los
resultados y realizan el mantenimiento a las herramientas de testing.


Página 15



Rastreador (Tracker)

Tiene como principal responsabilidad realizar las mediciones y la recolección
de métricas. Mide el progreso del proyecto y lo compara con lo estimado.
También observa el desempeño del equipo, haciendo énfasis en el
cumplimiento de los plazos y aconsejando al equipo si deben realizar
cambios para lograr los objetivos. Además de todo esto, mantiene los
registros de los casos de prueba ejecutados, los defectos encontrados y sus
responsables.

1.1.7

Artefactos XP

A continuación describimos los artefactos de XP, entre los que se encuentran:
Historias de Usuario y Tarjetas CRC.
 Historias de Usuario (Story Cards)
Representan una breve descripción del comportamiento del sistema, se
emplean para hacer estimaciones de tiempo y para el plan de
lanzamientos.


Página 16

Historia de Usuario
Número:

Nombre Historia de Usuario:

Modificación (o extensión) de Historia de Usuario (Nro. y
Nombre):
Usuario:

Iteración Asignada:

Prioridad en Negocio:

Puntos Estimados:

(Alta / Media / Baja)
Riesgo en Desarrollo:

Puntos Reales:

(Alto / Medio / Bajo)
Descripción:

Observaciones:

Figura 4. Modelo propuesto para una historia de usuario

Las Historias de Usuario tienen tres aspectos:
 Tarjeta: En ella se almacena suficiente información para identificar y
detallar la historia.
 Conversación: cliente y programadores discuten la historia para ampliar
los detalles (verbalmente cuando sea posible, pero documentada
cuando se requiera confirmación)
 Pruebas de Aceptación: permite confirmar que la historia ha sido
implementada correctamente.


Página 17

Caso de Prueba de Aceptación

Código:

Historia de Usuario (Nro. y Nombre):

Nombre:

Descripción:

Condiciones de Ejecución:

Entrada / Pasos de ejecución:

Resultado Esperado:

Evaluación de la Prueba:

Figura 5. Modelo propuesto para una prueba de aceptación.


Página 18

 Tarjetas CRC (Clase-Responsabilidad-Colaborador)

Estas tarjetas se dividen en tres secciones que contienen la información
del nombre de la clase, sus responsabilidades y sus colaboradores.

Figura 6. Modelo de tarjeta CRC.

Una clase es cualquier persona, cosa, evento, concepto, pantalla o reporte. Las
responsabilidades de una clase son las cosas que conoce y las que realizan, 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.
Los pasos a seguir para llenar las tarjetas son los siguientes:
 Encontrar clases
 Encontrar responsabilidades
 Definir colaboradores
 Disponer las tarjetas


Página 19

1.1.8

Ventajas Y Desventajas

A continuación veremos las ventajas y desventajas de usar la metodología
XP:
1.1.8.1 Ventajas:
 Programación organizada.
 Menor taza de errores.
 Satisfacción del programador.
 Solución de errores de programas.
 Versiones nuevas.
 Implementa una forma de trabajo donde

se adapte fácilmente a las

circunstancias.

1.1.8.2

Desventajas:

 Es recomendable emplearlo solo en proyectos a corto plazo
 Altas comisiones en caso de fallar
 Imposible prever todo antes de programar
 Demasiado costoso e innecesario

Figura 7. Ventajas y desventajas de usar la Metodología XP.


Página 20

2. APLICACIÓN DE METODOLOGÍA XP

2.1 Descripción del proyecto:
El proyecto consiste en construir un software para una tienda de ropa
femenina, como la metodología es xp es aplicable para este proyecto porque
la tienda es mediana.
Su objetivo del proyecto es diseñar e implementar un software para la tienda,
para una eficiente y rápida realización de atención al cliente, así mismo como
una mejor administración de la esta.
Para llevar a cabo este proyecto trabajamos conjuntamente con el cliente, a
la cual le ayudamos para que nos diga que exactamente quiere que realice el
software.
Nos ayudamos con los siguientes artefactos:
 Historia de usuario
 Pruebas de aceptación
 Tarjetas CRC


Página 21

2.1.1 Historias de usuario:
Historia de Usuario
Número: 1

Usuario: Administrador y vendedor/cajero

Nombre historia: Registro de clientes
Prioridad en negocio:

Riesgo en desarrollo:

Alta

Alta

Puntos estimados: 2

Iteración asignada: 1

Programador responsable: equipo xp

Descripción:
Se mostrará por pantalla una interfaz donde permitirá al administrador ingresar los
datos de los clientes.

Observaciones:
Estos datos de los clientes se almacenarán en una Base De Datos
CONFIRMADO con el cliente


Página 22

Historia de Usuario
Número: 2

Usuario: Administrador

Nombre historia: Registrar productos


Alta

Alta

Puntos estimados: 2



Descripción:
Se mostrará por pantalla una interfaz donde permitirá al administrador ingresar
los datos de los productos.

Observaciones:
Cada producto tiene un id diferente y está divido en categorías y marcas.


Historia de Usuario
Número: 3

Usuario: Vendedor/cajero

Nombre historia: Generar Factura


Alta

Alta

Puntos estimados: 2


Programador responsable: Eveling Cruz Vásquez

Descripción:


Página 23

Se muestra por pantalla una interfaz en donde se podrá realizar una venta, tiene
como entradas datos del cliente, datos de los productos y su total de monto.

Observaciones:
En la factura se genera automático su número de factura y su serie.


Historia de Usuario
Número: 4


Nombre historia: Gestión de datos de los proveedores


Alta

Alta

Puntos estimados: 2



Descripción:
Se muestra por pantalla una interfaz con los datos de los proveedores, ya
almacenados en la Base De Datos

Observaciones:



Página 24

Historia de Usuario
Número: 5


Nombre historia: Pedido De Productos


Alta

Alta

Puntos estimados: 2



Descripción:
Se muestra por pantalla un tipo comprobante para que pueda realizar el pedido de
los productos de acuerdo al proveedor.

Observaciones:



Página 25

2.1.1.1 Historia de Usuario – iteración 1
La tarea realizada en la primera iteración fue:
-

Crear la Base de datos con la que trabajaremos.

Figura 7. Ventajas y desventajas de usar la Metodología XP.


Página 26

Historia de Usuario
Número: 1


Nombre historia: Registrar productos


Alta

Alta

Puntos estimados: 2



Descripción:

Observaciones:
Cada producto tiene un id diferente y está divido en categorías y marcas.


Historia de Usuario
Número: 2


Nombre historia: Registro de clientes


Alta

Alta

Puntos estimados: 2



Descripción:


Página 27

los datos de los clientes.

Observaciones:
Estos datos de los clientes se almacenarán en una Base De Datos

Historia de Usuario
2.1.2 Número: 3

2.1.3 Usuario: Administrador

Nombre historia: Registrar Proveedores


Alta

Alta

Puntos estimados: 2



Descripción:
Se muestra por pantalla una interfaz donde podemos ingresar los datos de los
proveedores

Observaciones:


Entrega de iteración 1:
Interfaces del sistema:


Página 28

REGISTRAR PRODUCTOS (historia de usuario 1)

Fig.8 Interfaz Registrar Producto

REGISTRAR CLIENTES (historia de usuario 2)

Fig.9 Interfaz Registrar Clientes

-

R


Página 29

REGISTRAR PROVEEDORES (historia de usuario 3)

Fig.10 Interfaz Registrar Proveedores


Página 30

2.1.3.1 Historia de usuario- iteración 2

-

El cliente hizo una modificación en cuanto a la seguridad, agregar login.

-

Modificación en la Base de datos.

Fig.11 Base de datos modificada- agregando login


Página 31

Historia de Usuario
Número: 4


Nombre historia: Ingresar al Sistema


Alta

Alta

Puntos estimados: 2


Programador responsable: Eveling Cruz Vásquez

Descripción:
Se muestra por pantalla una interfaz donde podrán colocar su nombre y
contraseña.

Observaciones:
El administrador y cliente tendrán un nombre y contraseña almacenada en la
Base de datos.


Historia de Usuario
Número: 5


Nombre historia: Seleccionar producto


Alta

Alta

Puntos estimados: 2



Descripción:


Página 32

Se muestra por pantalla una interfaz en donde se podrá visualizar todos los
productos registrados en la Base de Datos.

Observaciones:
Se hace una consulta a la Base de Datos.

Historia de Usuario
Número: 6


Nombre historia: Seleccionar cliente


Alta

Alta

Puntos estimados: 2



Descripción:
Se muestra por pantalla una interfaz en donde se podrá visualizar todos los
clientes registrados en la Base de Datos.

Observaciones:
Se hace una consulta a la Base de Datos. Si el cliente no está registrado, se
podrá registrar en el acto


Página 33

Historia de Usuario
Número: 7


Nombre historia: Generar Factura


Alta

Alta

Puntos estimados: 2



Descripción:
Se muestra por pantalla una interfaz en donde se podrá realizar una venta, tiene
como entradas datos del cliente, datos de los productos y su total de monto.

Observaciones:
En la factura se genera automático su número de factura y su serie.
Seleccionar el producto deseado con el historia de usuario número 2.
Seleccionar el cliente con el historia de usuario número 3.

Entrega de iteración 2:
Interfaces del sistema :


Página 34

INGRESAR AL SISTEMA (historia de usuario 4)

Fig.12 Interfaz Ingresar al sistema

SELECCIONAR PRODUCTO (historia de usuario 5)

Fig.13 Interfaz Seleccionar Productos


Página 35

SELECCIONAR CLIENTES (historia de usuario 6)

Fig.14 Interfaz Seleccionar Clientes

FACTURA (historia de usuario 7)

Fig.15 Interfaz Generar Factura


Página 36

2.1.3.2 Historia de usuario – iteración 3

Historia de Usuario
Número: 8


Nombre historia: Alerta de pedido


Alta

Alta

Puntos estimados: 2



Descripción:
Se muestra por pantalla una interfaz en donde el sistema avisa al administrador
los productos faltantes.

Observaciones:
Este se llevará a cabo cuando la cantidad de venta llegue a la cantidad mínima
del producto.

Historia de Usuario
Número: 9


Nombre historia: Historial de Facturas


Alta

Alta

Puntos estimados: 2



Página 37


Descripción:
Se muestra por pantalla una interfaz en donde se podrá registrar las facturas de
ventas del vendedor/cajero

Observaciones:

Historia de Usuario
Número: 10


Nombre historia: Historial de Facturas-proveedor


Alta

Alta

Puntos estimados: 2



Descripción:
Se muestra por pantalla una interfaz en donde se podrá registrar las facturas de
compras de los productos solicitados a los proveedores

Observaciones:


Página 38

Entrega de versiones Iteración 3:
Interfaces

HISTORIAL DE FACTURAS (historia de usuario 9)

Fig.16 Interfaz Historial de facturas

HISTORIAL DE FACTURAS-PROVEEDOR (historia de usuario 10)

Fig.17 Interfaz Historial facturas de los proveedores


Página 39

2.1.2 Casos de prueba de aceptación

Casos de Prueba
Código: 1

Historia de usuario: 1 registrar clientes

Nombre:
Registro de Clientes
Descripción:
Este permitirá ingresar los datos de los clientes y almacenarlos en la base
de datos.
Condiciones de ejecución:
Este se llevará a cabo si el cliente a registrar al menos a comprado un
producto de la tienda.
Entrada/ Pasos de ejecución:
Tenemos como parámetros de entrada:
-

Nombre del cliente

-

Apellidos del cliente

-

Ruc

-

Dni

-

Teléfono

-

Dirección

Pasos de ejecución:
En primer lugar tenemos que ingresar al sistema
Luego ingresar los datos, enviarlos a la base de datos y por último
guardarlos.
Resultado esperado:
Los datos ingresaron con éxito
Evaluación de la prueba:
Después de hacer las pruebas, nos dimos cuenta que tenemos que hacer
una actualización cada vez que ingresamos un nuevo registro.


Página 40

Casos de Prueba
Código: 2

Historia de usuario: 2 registrar productos

Nombre:
Registro de Productos
Descripción:
Este permitirá ingresar los datos de los productos y almacenarlos en la
base de datos.
Este se llevará a cabo si el administrador tiende productos a registrar.
-

Nombre del producto

-

Categoría

-

Marca

-

Descripción

-

Cantidad mínima

-

Cantidad de venta

-

Cantidad de almacén

guardarlos.
Resultado esperado:


Página 41

Casos de Prueba
Código: 3

Historia de usuario: 3 registrar proveedores

Nombre:
Registro de Productos
Descripción:
Este permitirá ingresar los datos de los proveedores y almacenarlos en la
base de datos.
Este se llevará a cabo si el administrador tiende proveedores a registrar.
-

Nombre del proveedor

-

Apellidos del proveedor

-

Ciudad

guardarlos.
Resultado esperado:

Casos de Prueba
Código: 4

Historia de usuario: 4 ingresar al sistema

Nombre:
Login
Descripción:
Este permitirá ingresar al sistema siempre y cuando tengas un permiso
Este se llevará a cabo si en la base de datos estén registrados


Página 42

-

Nombre del producto

-

Contraseña

Luego ingresar los datos, enviarlos a la base de datos, compararlos y
finalmente devolver el acceso al sistema siempre y cuando estés registrado
de caso contrario acceso denegado.
Resultado esperado:
Los datos comparados con éxito
Prueba exitosa

Casos de Prueba
Código: 5

Historia de usuario: 5 seleccionar productos

Nombre:
Lista de productos
Descripción:
Este permitirá visualizar todos los productos almacenados en la Base de
datos
Este se llevará a cabo si en la base de datos estén registrados los productos
Ingresar a la interfaz listar productos e inmediatamente aparecerán los
productos
Resultado esperado:
Los datos son visualizas con éxito
Después de haber analizado la prueba nos dimos cuenta que esto es bueno


Página 43

para cuando existen pocos productos.

Casos de Prueba
Código: 6

Historia de usuario: 6 seleccionar clientes

Nombre:
Lista de clientes
Descripción:
Este permitirá visualizar todos los clientes almacenados en la Base de datos
Este se llevará a cabo si en la base de datos estén registrados los clientes
Ingresar a la interfaz listar clientes e inmediatamente aparecerán los
productos
Resultado esperado:
Los datos son visualizas con éxito
Después de haber analizado la prueba nos dimos cuenta que esto es bueno
para cuando existen pocos clientes.

Casos de Prueba
Código: 7

Historia de usuario: 7 generar factura

Nombre:
Facturar
Descripción:
Este permitirá realizar una venta de los productos almacenados a
determinado cliente.
Este se llevará a cabo si en la base de datos estén registrados los productos
a vender, si no está registrado en cliente, se puede almacenar en el acto.


Página 44

Entrada/Pasos de ejecución:
Entrada:
-

Datos de los clientes

-

Datos de los productos

-

Cantidad de los productos a vender

Ingresar a la interfaz factura e inmediatamente empezar a realizar la venta.
Primero seleccionar el cliente (historia de usuario 6), luego seleccionar los
productos (historia de usuario 5), ingresar la cantidad a vender de los
productos seleccionados y calcular monto total.
Resultado esperado:
La venta es realizada con éxito
Después de haber analizado la prueba nos dimos cuenta que tenemos que
hacer varios ingresos a la base de datos para realizar una venta.

2.1.3


Tarjetas CRC

Registrar clientes:

REGISTRAR CLIENTES

-

Obtener los datos de los

Para el registro de clientes

clientes.

-

se necesitaría de los datos

Conectar con la base de

de los clientes.

datos.
-

Ingresar

los

datos

de

La clase cliente.

-

La clase login

clientes en la base de
datos.
-

Confirmar los datos.


Página 45



Registrar Productos

REGISTRAR PRODUCTOS
Para

productos se necesitaría de



datos.

-

productos.

-

- La clase producto.
de

- La clase stock
- La clase marca


- La clase categoría



datos

de

- La clase login

datos.
-

los

registro

productos en la base de

-

Ingresar

el

Registrar Proveedores
REGISTRAR PROVEEDORES
Para

proveedores se necesitaría


de

datos.

-

proveedores.

-

proveedores.
los

datos

los

registro

datos

de

-

de

de

los

La clase proveedor

proveedores en la base de

-

Ingresar

el

La clase login

datos.
-




Ingresar Al Sistema

INGRESAR AL SISTEMA

-


Para ingresar al sistema se

datos.

-

necesita el usuario y la

Comparar

los

datos

contraseña y la confirmación

ingresados con lo de la
base de datos.


si acepta o no.
-

La clase login

Página 46

-


-

La clase vendedor/ cajero

-

Denegar el ingreso.

-

La clase administrador



Seleccionar producto

SELECCIONAR PRODUCTO

Para

datos.

-

la

selección

productos.
-

La clase login

donde

-

La clase producto

están registrados la base

-

La clase categoría

de datos.
-

Seleccionar la tabla de la
base

-

-

La clase marca

Mostrar los datos de la

-

de

La clase stock

de

datos

tabla.
-

Mostrar en la interfaz.

-

Seleccionar el producto.


Seleccionar Clientes

SELECCIONAR CLIENTES

Para

datos.

-

la

selección

clientes.

Seleccionar la tabla de la

-

La clase login

base

-

-

de

La clase cliente

de

datos

donde

están registrados la base
de datos.
-

Mostrar los datos de la
tabla.

-

Mostrar en la interfaz.

-

Seleccionar el cliente.


Página 47



Facturar

FACTURAR
-


Para realizar una factura

datos.

-

La clase login

-

Seleccionar el cliente

-

La clase factura

-

Seleccionar el producto.

-

La clase vende

-

Ingresar cantidad

-

La clase producto

-

Calcular monto

-

La clase stock

-

Generar factura

-

La clase categoría

-

La clase marca

-

La clase cliente

-

La clase vendedor


Página 48

CONCLUSIONES

Después de haber analizado y estudiado la programación extrema llegamos a la
conclusión que:
Esta metodología es muy útil porque a diferencia de las metodologías
tradicionales esta

acepta rápidamente los cambios efectuados durante el

desarrollo del software, y se adapta a estos.
También como toda metodología tiene sus ventajas y

desventajas pero a

diferencia de las demás es la más eficiente para proyectos cortos y medianos.
La comunicación con el cliente es fluida, por lo tanto cualquier duda en cuanto a
los requerimientos se podrá solucionar inmediatamente.
Los releases que se le dan cliente son importantes, porque el cliente así va viendo
como está quedando y si están manejando todos los requerimientos que él está
pidiendo.
Y por último la simplicidad, ayuda a que todos cooperen con el desarrollo del
software y puedan entender mejor.


Página 49

BIBLIOGRAFÍA

 Procesos de software
http://procesosdesoftware.wikispaces.com/METODOLOGIA+XP
 Ing. software (equipo 02)
http://ingsoftware072301.obolog.com/metodologia-xp-2012877
 Metodología XP
https://sites.google.com/site/xpmetodologia/home/introduccion
 Luis Calabri & Pablo Piriz, 2003 , Metodología XP
http://fi.ort.edu.uy/innovaportal/file/2021/1/metodologia_xp.pdf
 Ciclo De Vida De Un Proyecto De Sw
http://oness.sourceforge.net/proyecto/html/ch05.html
 Ing. José Joskowicz 2008 Reglas Y Prácticas En Extreme Programming
http://iie.fing.edu.uy/~josej/docs/XP%20-%20Jose%20Joskowicz.pdf
 Gerardo Fernández Escribano , 2002 , Introducción A Extreme
Programming
http://aalbertovargasc.files.wordpress.com/2011/07/presentacion-xp.pdf
 Luis Miguel Echeverry Tobón & Luz Elena Delgado Carmona , 2007 ,
Caso Práctico De La Metodología Ágil XP Al Desarrollo Del Software
http://repositorio.utp.edu.co/dspace/bitstream/11059/794/1/0053E18cp.pdf
 Juan Pablo Roche Saldarriaga & Julián Mauricio Suarez Arias , 2009 ,
Análisis, Diseño E Implementación De Un Software, para la
Administración de los Proyectos De Grado En El Programa De Ing. De
Sistemas, Aplicando Una Metodología Ágil
http://repositorio.utp.edu.co/dspace/bitstream/11059/1316/1/0057565R673.pdf


Página 50


Página 51

Metodologia XP

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Metodologia XP

Similar to Metodologia XP (20)

Metodologia XP