metodologia xp
TRANSCRIPT
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 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
Universidad Nacional de Trujillo Página 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.
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
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.
Universidad Nacional de Trujillo Página 5
Figura 1. Kent Beck, creador de la Metodología XP
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
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.
Universidad Nacional de Trujillo Página 7
Figura 2. Valores XP
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
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
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
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
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.
1.1.5 Ciclo De Vida Del Programador
Universidad Nacional de Trujillo Página 12
Figura 3. Ciclo de vida de XP
É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.
1.1.5.5 Q & A
Universidad Nacional de Trujillo Página 13
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.
1.1.6 Roles Y Responsabilidades
Universidad Nacional de Trujillo Página 14
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
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.
Historia de Usuario
Universidad Nacional de Trujillo Página 16
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:
(Alta / Media / Baja)
Puntos Estimados:
Riesgo en Desarrollo:
(Alto / Medio / Bajo)
Puntos Reales:
Descripción:
Observaciones:
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
Figura 4. Modelo propuesto para una historia de usuario
Universidad Nacional de Trujillo Página 18
Figura 5. Modelo propuesto para una prueba de aceptación.
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:
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.
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
1.1.8 Ventajas Y Desventajas
Universidad Nacional de Trujillo Página 19
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
2. APLICACIÓN DE METODOLOGÍA XP
Universidad Nacional de Trujillo Página 20
Figura 7. Ventajas y desventajas de usar la Metodología XP.
2.1Descripció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
2.1.1 Historias de usuario:
Universidad Nacional de Trujillo Página 21
Historia de Usuario
Número: 1 Usuario: Administrador y vendedor/cajero
Nombre historia: Registro de clientes
Prioridad en negocio:
Alta
Riesgo en desarrollo:
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
Historia de Usuario
Universidad Nacional de Trujillo Página 22
Número: 2 Usuario: Administrador
Nombre historia: Registrar productos
Prioridad en negocio:
Alta
Riesgo en desarrollo:
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:
Alta
Riesgo en desarrollo:
Alta
Puntos estimados: 2 Iteración asignada: 1
Programador responsable: Eveling Cruz Vásquez
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.
Universidad Nacional de Trujillo Página 23
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:
Alta
Riesgo en desarrollo:
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
Historia de Usuario
Número: 5 Usuario: Administrador
Universidad Nacional de Trujillo Página 24
Nombre historia: Pedido De Productos
Prioridad en negocio:
Alta
Riesgo en desarrollo:
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
2.1.1.1 Historia de Usuario – iteración 1
La tarea realizada en la primera iteración fue:
Universidad Nacional de Trujillo Página 25
- Crear la Base de datos con la que trabajaremos.
Historia de Usuario
Número: 1 Usuario: Administrador
Nombre historia: Registrar productos
Prioridad en negocio:
Alta
Riesgo en desarrollo:
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
Universidad Nacional de Trujillo Página 26
Figura 7. Ventajas y desventajas de usar la Metodología XP.
Historia de Usuario
Número: 2 Usuario: Administrador y vendedor/cajero
Nombre historia: Registro de clientes
Prioridad en negocio:
Alta
Riesgo en desarrollo:
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
Historia de Usuario
2.1.2 Número: 3 2.1.3 Usuario: Administrador
Nombre historia: Registrar Proveedores
Prioridad en negocio:
Alta
Riesgo en desarrollo:
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
Universidad Nacional de Trujillo Página 27
Observaciones:
CONFIRMADO con el cliente
Entrega de iteración 1:
Interfaces del sistema:
REGISTRAR PRODUCTOS (historia de usuario 1)
REGISTRAR CLIENTES (historia de usuario 2)
Universidad Nacional de Trujillo Página 28
Fig.8 Interfaz Registrar Producto
- R
REGISTRAR PROVEEDORES (historia de usuario 3)
Universidad Nacional de Trujillo Página 29
Fig.9 Interfaz Registrar Clientes
Universidad Nacional de Trujillo Página 30
Fig.10 Interfaz Registrar Proveedores
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.
Universidad Nacional de Trujillo Página 31
Historia de Usuario
Número: 4 Usuario: Administrador y vendedor/cajero
Nombre historia: Ingresar al Sistema
Prioridad en negocio: Riesgo en desarrollo:
Universidad Nacional de Trujillo Página 32
Fig.11 Base de datos modificada- agregando login
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:
Alta
Riesgo en desarrollo:
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
productos registrados en la Base de Datos.
Observaciones:
Se hace una consulta a la Base de Datos.
CONFIRMADO con el cliente
Universidad Nacional de Trujillo Página 33
Historia de Usuario
Número: 6 Usuario: Vendedor/cajero
Nombre historia: Seleccionar cliente
Prioridad en negocio:
Alta
Riesgo en desarrollo:
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
Historia de Usuario
Número: 7 Usuario: Vendedor/cajero
Nombre historia: Generar Factura
Prioridad en negocio:
Alta
Riesgo en desarrollo:
Alta
Puntos estimados: 2 Iteración asignada: 1
Universidad Nacional de Trujillo Página 34
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 :
INGRESAR AL SISTEMA (historia de usuario 4)
Universidad Nacional de Trujillo Página 35
SELECCIONAR PRODUCTO (historia de usuario 5)
SELECCIONAR CLIENTES (historia de usuario 6)
Universidad Nacional de Trujillo Página 36
Fig.12 Interfaz Ingresar al sistema
Fig.13 Interfaz Seleccionar Productos
FACTURA (historia de usuario 7)
Universidad Nacional de Trujillo Página 37
Fig.14 Interfaz Seleccionar Clientes
Fig.15 Interfaz Generar Factura
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:
Alta
Riesgo en desarrollo:
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:
Alta
Riesgo en desarrollo:
Alta
Puntos estimados: 2 Iteración asignada: 1
Universidad Nacional de Trujillo Página 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:
Alta
Riesgo en desarrollo:
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 39
Entrega de versiones Iteración 3:
Interfaces
HISTORIAL DE FACTURAS (historia de usuario 9)
HISTORIAL DE FACTURAS-PROVEEDOR (historia de usuario 10)
Universidad Nacional de Trujillo Página 40
Fig.16 Interfaz Historial de facturas
Fig.17 Interfaz Historial facturas de los proveedores
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 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 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 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 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
Universidad Nacional de Trujillo Página 45
a vender, si no está registrado en cliente, se puede almacenar en el acto.
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
clientes.
- Conectar con la base de
datos.
- Ingresar los datos de
clientes en la base de
datos.
- Confirmar los datos.
Para el registro de clientes
se necesitaría de los datos
de los clientes.
- La clase cliente.
- La clase login
Universidad Nacional de Trujillo Página 46
Registrar Productos
REGISTRAR PRODUCTOS
- Obtener los datos de los
productos.
- Conectar con la base de
datos.
- Ingresar los datos de
productos en la base de
datos.
- Confirmar los datos.
Para el registro de
productos se necesitaría de
los datos de los productos.
- La clase producto.
- La clase login
- La clase stock
- La clase marca
- La clase categoría
Registrar Proveedores
REGISTRAR PROVEEDORES
- Obtener los datos de los
proveedores.
- Conectar con la base de
datos.
- Ingresar los datos de
proveedores en la base de
datos.
- Confirmar los datos.
Para el registro de
proveedores se necesitaría
de los datos de los
proveedores.
- La clase proveedor
- La clase login
Ingresar Al Sistema
INGRESAR AL SISTEMA
- Conectar con la base de
datos.
- Comparar los datos
Para ingresar al sistema se
necesita el usuario y la
contraseña y la confirmación
Universidad Nacional de Trujillo Página 47
ingresados con lo de la
base de datos.
- Confirmar los datos.
- Denegar el ingreso.
si acepta o no.
- La clase login
- La clase vendedor/ cajero
- La clase administrador
Seleccionar producto
SELECCIONAR PRODUCTO
- Conectar con la base de
datos.
- Seleccionar la tabla de la
base de datos donde
están registrados la base
de datos.
- Mostrar los datos de la
tabla.
- Mostrar en la interfaz.
- Seleccionar el producto.
Para la selección de
productos.
- La clase login
- La clase producto
- La clase categoría
- La clase marca
- La clase stock
Seleccionar Clientes
SELECCIONAR CLIENTES
- Conectar con la base de
datos.
- Seleccionar la tabla de la
base de datos donde
están registrados la base
de datos.
- Mostrar los datos de la
tabla.
- Mostrar en la interfaz.
Para la selección de
clientes.
- La clase login
- La clase cliente
Universidad Nacional de Trujillo Página 48
- Seleccionar el cliente.
Facturar
FACTURAR
- Conectar con la base de
datos.
- Seleccionar el cliente
- Seleccionar el producto.
- Ingresar cantidad
- Calcular monto
- Generar factura
Para realizar una factura
- La clase login
- La clase factura
- La clase vende
- La clase producto
- La clase stock
- La clase categoría
- La clase marca
- La clase cliente
- La clase vendedor
Universidad Nacional de Trujillo Página 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 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
Universidad Nacional de Trujillo Página 51
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 52