Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Metodologia XP

5,982 views

Published on

Metodologia XP

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 30. REGISTRAR PROVEEDORES (historia de usuario 3) Fig.10 Interfaz Registrar Proveedores Universidad Nacional de Trujillo Página 30
  31. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  51. 51. Universidad Nacional de Trujillo Página 51

×