1. 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
2. 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
Historia de usuario – iteración 2
31
2.1.1.3
Historia de usuario – iteración 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
3. 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.
Universidad Nacional de Trujillo
Página 3
4. 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.
Universidad Nacional de Trujillo
Página 4
5. 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
Universidad Nacional de Trujillo
Página 5
6. 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:
Universidad Nacional de Trujillo
Página 6
7.
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
Universidad Nacional de Trujillo
Página 7
8. 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.
Universidad Nacional de Trujillo
Página 8
9. 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.
Universidad Nacional de Trujillo
Página 9
10. 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.
Universidad Nacional de Trujillo
Página 10
11. 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.
Universidad Nacional de Trujillo
Página 11
12. 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
Universidad Nacional de Trujillo
Página 12
13. 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.
Universidad Nacional de Trujillo
Página 13
14. 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.
Universidad Nacional de Trujillo
Página 14
15. 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.
Universidad Nacional de Trujillo
Página 15
16.
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.
Universidad Nacional de Trujillo
Página 16
17. 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.
Universidad Nacional de Trujillo
Página 17
18. 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.
Universidad Nacional de Trujillo
Página 18
19. 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
Universidad Nacional de Trujillo
Página 19
20. 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.
Universidad Nacional de Trujillo
Página 20
21. 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
Universidad Nacional de Trujillo
Página 21
22. 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
Universidad Nacional de Trujillo
Página 22
23. Historia de Usuario
Número: 2
Usuario: Administrador
Nombre historia: Registrar productos
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 productos.
Observaciones:
Cada producto tiene un id diferente y está divido en categorías y marcas.
CONFIRMADO con el cliente
Historia de Usuario
Número: 3
Usuario: Vendedor/cajero
Nombre historia: Generar Factura
Prioridad en negocio:
Riesgo en desarrollo:
Alta
Alta
Puntos estimados: 2
Iteración asignada: 1
Programador responsable: Eveling Cruz Vásquez
Descripción:
Universidad Nacional de Trujillo
Página 23
24. 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.
CONFIRMADO con el cliente
Historia de Usuario
Número: 4
Usuario: Administrador
Nombre historia: Gestión de datos de los proveedores
Prioridad en negocio:
Riesgo en desarrollo:
Alta
Alta
Puntos estimados: 2
Iteración asignada: 1
Programador responsable: equipo xp
Descripción:
Se muestra por pantalla una interfaz con los datos de los proveedores, ya
almacenados en la Base De Datos
Observaciones:
CONFIRMADO con el cliente
Universidad Nacional de Trujillo
Página 24
25. Historia de Usuario
Número: 5
Usuario: Administrador
Nombre historia: Pedido De Productos
Prioridad en negocio:
Riesgo en desarrollo:
Alta
Alta
Puntos estimados: 2
Iteración asignada: 1
Programador responsable: equipo xp
Descripción:
Se muestra por pantalla un tipo comprobante para que pueda realizar el pedido de
los productos de acuerdo al proveedor.
Observaciones:
CONFIRMADO con el cliente
Universidad Nacional de Trujillo
Página 25
26. 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.
Universidad Nacional de Trujillo
Página 26
27. Historia de Usuario
Número: 1
Usuario: Administrador
Nombre historia: Registrar productos
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 productos.
Observaciones:
Cada producto tiene un id diferente y está divido en categorías y marcas.
CONFIRMADO con el cliente
Historia de Usuario
Número: 2
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:
Universidad Nacional de Trujillo
Página 27
28. 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
Historia de Usuario
2.1.2 Número: 3
2.1.3 Usuario: Administrador
Nombre historia: Registrar Proveedores
Prioridad en negocio:
Riesgo en desarrollo:
Alta
Alta
Puntos estimados: 2
Iteración asignada: 1
Programador responsable: equipo xp
Descripción:
Se muestra por pantalla una interfaz donde podemos ingresar los datos de los
proveedores
Observaciones:
CONFIRMADO con el cliente
Entrega de iteración 1:
Interfaces del sistema:
Universidad Nacional de Trujillo
Página 28
29. REGISTRAR PRODUCTOS (historia de usuario 1)
Fig.8 Interfaz Registrar Producto
REGISTRAR CLIENTES (historia de usuario 2)
Fig.9 Interfaz Registrar Clientes
-
R
Universidad Nacional de Trujillo
Página 29
30. REGISTRAR PROVEEDORES (historia de usuario 3)
Fig.10 Interfaz Registrar Proveedores
Universidad Nacional de Trujillo
Página 30
31. 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
Universidad Nacional de Trujillo
Página 31
32. Historia de Usuario
Número: 4
Usuario: Administrador y vendedor/cajero
Nombre historia: Ingresar al Sistema
Prioridad en negocio:
Riesgo en desarrollo:
Alta
Alta
Puntos estimados: 2
Iteración asignada: 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.
CONFIRMADO con el cliente
Historia de Usuario
Número: 5
Usuario: Vendedor/cajero
Nombre historia: Seleccionar producto
Prioridad en negocio:
Riesgo en desarrollo:
Alta
Alta
Puntos estimados: 2
Iteración asignada: 2
Programador responsable: equipo xp
Descripción:
Universidad Nacional de Trujillo
Página 32
33. 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.
CONFIRMADO con el cliente
Historia de Usuario
Número: 6
Usuario: Vendedor/cajero
Nombre historia: Seleccionar cliente
Prioridad en negocio:
Riesgo en desarrollo:
Alta
Alta
Puntos estimados: 2
Iteración asignada: 2
Programador responsable: equipo xp
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
CONFIRMADO con el cliente
Universidad Nacional de Trujillo
Página 33
34. Historia de Usuario
Número: 7
Usuario: Vendedor/cajero
Nombre historia: Generar Factura
Prioridad en negocio:
Riesgo en desarrollo:
Alta
Alta
Puntos estimados: 2
Iteración asignada: 1
Programador responsable: equipo xp
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.
CONFIRMADO con el cliente
Entrega de iteración 2:
Interfaces del sistema :
Universidad Nacional de Trujillo
Página 34
35. INGRESAR AL SISTEMA (historia de usuario 4)
Fig.12 Interfaz Ingresar al sistema
SELECCIONAR PRODUCTO (historia de usuario 5)
Fig.13 Interfaz Seleccionar Productos
Universidad Nacional de Trujillo
Página 35
36. SELECCIONAR CLIENTES (historia de usuario 6)
Fig.14 Interfaz Seleccionar Clientes
FACTURA (historia de usuario 7)
Fig.15 Interfaz Generar Factura
Universidad Nacional de Trujillo
Página 36
37. 2.1.3.2 Historia de usuario – iteración 3
Historia de Usuario
Número: 8
Usuario: Administrador
Nombre historia: Alerta de pedido
Prioridad en negocio:
Riesgo en desarrollo:
Alta
Alta
Puntos estimados: 2
Iteración asignada: 1
Programador responsable: equipo xp
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.
CONFIRMADO con el cliente
Historia de Usuario
Número: 9
Usuario: Administrador
Nombre historia: Historial de Facturas
Prioridad en negocio:
Riesgo en desarrollo:
Alta
Alta
Puntos estimados: 2
Iteración asignada: 1
Universidad Nacional de Trujillo
Página 37
38. Programador responsable: equipo xp
Descripción:
Se muestra por pantalla una interfaz en donde se podrá registrar las facturas de
ventas del vendedor/cajero
Observaciones:
CONFIRMADO con el cliente
Historia de Usuario
Número: 10
Usuario: Administrador
Nombre historia: Historial de Facturas-proveedor
Prioridad en negocio:
Riesgo en desarrollo:
Alta
Alta
Puntos estimados: 2
Iteración asignada: 1
Programador responsable: equipo xp
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:
CONFIRMADO con el cliente
Universidad Nacional de Trujillo
Página 38
39. 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
Universidad Nacional de Trujillo
Página 39
40. 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.
Universidad Nacional de Trujillo
Página 40
41. 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.
Condiciones de ejecución:
Este se llevará a cabo si el administrador tiende productos a registrar.
Entrada/ Pasos de ejecución:
Tenemos como parámetros de entrada:
-
Nombre del producto
-
Categoría
-
Marca
-
Descripción
-
Cantidad mínima
-
Cantidad de venta
-
Cantidad de almacé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.
Universidad Nacional de Trujillo
Página 41
42. 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.
Condiciones de ejecución:
Este se llevará a cabo si el administrador tiende proveedores a registrar.
Entrada/ Pasos de ejecución:
Tenemos como parámetros de entrada:
-
Nombre del proveedor
-
Apellidos del proveedor
-
Ciudad
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.
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
Condiciones de ejecución:
Este se llevará a cabo si en la base de datos estén registrados
Universidad Nacional de Trujillo
Página 42
43. Entrada/ Pasos de ejecución:
Tenemos como parámetros de entrada:
-
Nombre del producto
-
Contraseña
Pasos de ejecución:
En primer lugar tenemos que ingresar al sistema
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
Evaluación de la prueba:
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
Condiciones de ejecución:
Este se llevará a cabo si en la base de datos estén registrados los productos
Pasos de ejecución:
Pasos de ejecución:
En primer lugar tenemos que ingresar al sistema
Ingresar a la interfaz listar productos e inmediatamente aparecerán los
productos
Resultado esperado:
Los datos son visualizas con éxito
Evaluación de la prueba:
Después de haber analizado la prueba nos dimos cuenta que esto es bueno
Universidad Nacional de Trujillo
Página 43
44. 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
Condiciones de ejecución:
Este se llevará a cabo si en la base de datos estén registrados los clientes
Pasos de ejecución:
Pasos de ejecución:
En primer lugar tenemos que ingresar al sistema
Ingresar a la interfaz listar clientes e inmediatamente aparecerán los
productos
Resultado esperado:
Los datos son visualizas con éxito
Evaluación de la prueba:
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.
Condiciones de ejecución:
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.
Universidad Nacional de Trujillo
Página 44
45. Entrada/Pasos de ejecución:
Entrada:
-
Datos de los clientes
-
Datos de los productos
-
Cantidad de los productos a vender
Pasos de ejecución:
En primer lugar tenemos que ingresar al sistema
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
Evaluación de la prueba:
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.
Universidad Nacional de Trujillo
Página 45
46.
Registrar Productos
REGISTRAR PRODUCTOS
Para
productos se necesitaría de
Conectar con la base de
los datos de los productos.
datos.
-
Obtener los datos de los
productos.
-
- La clase producto.
de
- La clase stock
- La clase marca
Confirmar los datos.
- 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
Conectar con la base de
de
datos.
-
Obtener los datos de los
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.
-
Confirmar los datos.
Ingresar Al Sistema
INGRESAR AL SISTEMA
-
Conectar con la base de
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.
Universidad Nacional de Trujillo
si acepta o no.
-
La clase login
Página 46
47. -
Confirmar los datos.
-
La clase vendedor/ cajero
-
Denegar el ingreso.
-
La clase administrador
Seleccionar producto
SELECCIONAR PRODUCTO
Conectar con la base de
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
Conectar con la base de
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.
Universidad Nacional de Trujillo
Página 47
48.
Facturar
FACTURAR
-
Conectar con la base de
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
Universidad Nacional de Trujillo
Página 48
49. 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.
Universidad Nacional de Trujillo
Página 49
50. 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
Universidad Nacional de Trujillo
Página 50