1. UNIVERSIDAD NACIONAL DE TRUJILLO SUB SEDE VALLE JEQUETEPEQUE FACULTAD DE CIENCIAS FSICAS Y MATEMTICAS INFORMTICAMONOGRAFAMETODOLOGA XPAUTORES: JOS SANCHZ FLORES JOS RODRGUEZ CARUAJULCA GUIDO MOSTACERO ESPINOZAGUADALUPE PER 2013Universidad nacional de Trujillo1

2. NDICEDEDICATORIA3INTRODUCCIN41. MARCO TERICO51.1 Extreme programing51.1.1 Definicin51.1.2 Valores51.1.3 Conceptos61.1.4 Caractersticas fundamentales71.1.5 Ciclo de vida81.1.6 Actores y responsabilidades101.1.7 Artefactos111.1.8 Ventajas y desventajas151.1.8.1 Ventajas151.1.8.2 Desventajas151.1.9 Ejemplo16CONCLUSIONES28BIBLIOGRAFA29Universidad nacional de Trujillo2 3. Primeramente a Dios a Dios por habernos permitido llegar hasta este punto y habernos dado salud, ser el manantial de vida y darnos lo necesario para seguir adelante da a da para lograr nuestros objetivos, adems de su infinita bondad y amor. A nuestros padres por habernos apoyado en todo momento, por sus consejos, sus valores, por la motivacin constante que nos ha permitido ser personas de bien, pero ms que nada, por su amor.Universidad nacional de Trujillo3 4. INTRODUCCIONLa metodologa gil es importante durante el desarrollo del software, pero como elegir una metodologa que sea eficiente y nos ayude con el desarrollo del proyecto. La XP se puede definir como un conjunto de pasos de diversas metodologas, acopladas de manera que sean pasos flexibles a seguir utilizadas con el uso comn, para realizar un desarrollo ms agradable y sencillo. As, la XP se puede definir como un conjunto de pasos de diversas metodologas, acopladas de manera que sean pasos flexibles a seguir utilizadas con el uso comn, para realizar un desarrollo ms agradable y sencillo. Se puede considerar la programacin extrema como la adopcin de las mejores metodologas de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinmica durante el ciclo de vida del software. Esta metodologa tiene como base la simplicidad y como objetivo principal la satisfaccin del cliente. Las etapas que recomienda seguir esta metodologa se plantean de manera sencilla pero a la vez son estrictas, y se inspiran en la total participacin de los involucrados. Por lo cual la presente monografa nos presentar la metodologa xp, sus valores, principales conceptos entre otros.Universidad nacional de Trujillo4 5. 1. MARCO TERICO 1.1 EXTREME PROGRAMMING (XP) 1.1.1 Definicin Fue creado por Kent Beck, para la plantilla del proyecto C3 en Chrysler. Durante el proceso del proyecto C3 Chrysler metodologa llamada extreme programming.naciuna nuevaLa programacin extrema o eXtremeProgramming (XP) es una metodologa de desarrollo gil, una de las ms exitosas en tiempo reciente. Su autor principal es Kent Beck, quien eligi algunas caractersticas de otras metodologas y las relacion de forma que cada una complementara a la otra. En XP se realiza eel 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 diseado para adaptarse en forma inmediata a los cambios, con bajos costos asociados, en cualquier etapa del ciclo de vida. 1.1.2 Valores Para poder implementar la metodologa XP en un proyecto tenemos que conocer los valores principales, los cuales son los siguientes. Simplicidad: La simplicidad es la base de la programacin extrema, se refiere que ante todo y sin importar qu funcionalidad requiera el usuario en su sistema, ste debe ser fcil. El diseo debe ser sencillo y amigable al usuario, el cdigo debe ser simple y entendible, programando slo lo necesario y lo que se utilizar. Comunicacin: Es muy importante que haya una comunicacin constante con el cliente y dentro de todo el equipo de trabajo, de esto depender que el desarrollo se lleve a cabo de una maneraUniversidad nacional de Trujillo5 6. sencilla, entendible y que se entregue al cliente lo que necesita. Coraje/valenta: La valenta le permite a los desarrolladores que se sientan cmodos con reconstruir su cdigo cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se implementaran ms fcilmente. Otro ejemplo de valenta es saber cundo desechar un cdigo: valenta para quitar cdigo fuente obsoleto, sin importar cuanto esfuerzo y tiempo se invirti en crear ese cdigo. Adems, valenta significa persistencia: un programador puede permanecer sin avanzar en un problema complejo por un da entero, y luego lo resolver rpidamente al da siguiente, slo si es persistente. Retroalimentacin (Feedback): Al estar el cliente integrado en el proyecto, su opinin sobre el estado del proyecto se conoce en tiempo real. Es la comunicacin constante entre el desarrollador y el usuario.1.1.3 Conceptos Los principales conceptos son los siguientes: StoryCards: Las storycards sirven para registrar los requerimientos de los clientes y son utilizadas para poder realizar la estimacin de cada una de las iteraciones durante la fase de planificacin. Las storycards son escritas por los clientes en base a lo que se estima es necesario para el sistema. Estn escritas en un formato de oraciones en la terminologa del cliente, sin necesidad de sintaxis tcnicas. 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 nmero ideal para poder crear un plan de entregas es entre 20 y 80 stories. Iteracin: Consta de un perodo 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 iteracin puede terminar de manera exitosa.Universidad nacional de Trujillo6 7. Otro punto que no debe ser pasado por alto es el tema de la duracin de cada iteracin. 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. Refactoring: Consiste en realizar cambios al sistema sin modificar la funcionalidad del mismo para poder hacer el sistema ms simple, para aumentar la eficiencia o para que el cdigo sea mucho ms entendible. Release: La idea de cada release es poder tener un producto intermedio al final de cada iteracin en la cual el cliente pueda testear la funcionalidad pedida. Con esto los clientes pueden, adems, 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 aceptacin: Los test de aceptacin representan algn 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. Una story no es aceptada hasta que haya pasado su test de aceptacin. Esto significa que en cada iteracin se deben realizar nuevos test de aceptacin o de lo contrario el equipo tendr una avance de cero. Test unitario: Son realizados desde el punto de vista del programador y sirven, adems de testear el cdigo, para poder realizar el refactoring del mismo. Cada programador, antes de comenzar a programar, debe preparar los test unitarios. Esto hace que dichos test estn preparados para ser corridos durante la codificacin y adems, hace que al programador le surjan dudas y pueda evacuarlas con el cliente antes de empezar con la codificacin. 1.1.4 Caractersticas fundamentales Las caractersticas fundamentales del mtodo son: Desarrollo iterativo e incremental: Pequeas mejoras, unas tras otras. Pruebas unitarias continuas: Frecuentemente repetidas y automatizadas, incluyendo pruebas de regresin. Se aconseja Universidad nacional de Trujillo7 8. escribir el cdigo de la prueba antes de la codificacin. Programacin en parejas: Se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. La mayor calidad del cdigo escrito de esta manera -el cdigo es revisado y discutido mientras se escribe- es ms importante que la posible prdida de productividad inmediata. Frecuente integracin del equipo de programacin con el cliente o usuario: Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo. Correccin de todos los errores: Antes de aadir nueva funcionalidad. Hacer entregas frecuentes. Refactorizacin del cdigo: Es decir, reescribir ciertas partes del cdigo para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorizacin no se ha introducido ningn fallo. Propiedad del cdigo compartida: En vez de dividir la responsabilidad en el desarrollo de cada mdulo en grupos de trabajo distintos, este mtodo promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresin garantizan que los posibles errores sern detectados. Simplicidad en el cdigo:La simplicidad y la comunicacin son extraordinariamente complementarias. Con ms comunicacin resulta ms fcil identificar qu se debe y qu no se debe hacer. Cuanto ms simple es el sistema, menos tendr que comunicar sobre ste, lo que lleva a una comunicacin ms completa, especialmente si se puede reducir el equipo de programadores. 1.1.5 Ciclo de vida El ciclo de vida ideal de XP consiste de seis fases: Exploracin: En esta fase los clientes realizan las storycards que desean que estn 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 tecnologa y las prcticas a ser utilizadas durante el proyecto. La duracin de esta fase puede extenderse desde unas pocas semanas a varios meses dependiendo de la adaptacin del equipo de desarrollo. Planificacin: El propsito de esta fase es el de llegar a un Universidad nacional de Trujillo8 9. acuerdo entre los clientes y los programadores en cules sern las stories a ser implementadas durante cada iteracin. Si se hace una buena preparacin durante la fase de exploracin esta actividad no suele llevar ms de un da o dos. La entrega del primer release debe tomar entre dos a seis meses de duracin. Iteraciones por entregas: Una vez elegido el orden en el cual se implementarn las stories se procede a definir cuantas iteraciones sern necesarias para el proyecto. Cada iteracin tiene una duracin 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 iteracin el cliente debe analizar que todas las stories estn implementadas. Debe tambin correr todos los test funcionales y que estos resulten ser exitosos. Produccin: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 inclusin de nuevas caractersticas a la versin actual, debido a cambios durante esta fase. 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. Adems, se prueba la nueva tecnologa que se va a utilizar en el prximo release o migrar a nuevas versiones de la tecnologa que se est utilizando. Muerte: Es cuando el cliente no tiene ms 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 documentacin final del sistema y no se realizan ms cambios en la arquitectura. La muerte del proyecto tambin ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo.Universidad nacional de Trujillo9 10. Figura 1. Ciclo de vida XP1.1.6 Actores y responsabilidades Programador: Responsable de decisiones tcnicas; construir el sistema; disea y realizar pruebas. Debe existir una comunicacin y coordinacin adecuada entre los programadores y otros miembros del equipo Cliente (Customer): Es parte del equipo y es quien establece que es lo que debe realizar el sistema, tomando la decisin de cuando se debe implementar determinada funcionalidad, as como tambin en el orden a ser implementadas. Los clientes tambin priorizan cada uno de los requerimientos. Entrenador (Coach): Es el lder del equipo, toma las decisiones ms importantes. Adems es el encargado de asegurar el cumplimiento de todas las prcticas, transmitiendo sus Universidad nacional de Trujillo10 11. conocimientos y experiencia al resto del equipo.Encargado de pruebas (Tester): Los tester ayudan a los clientes a escribir los test funcionales del sistema. Adems, corren dichos testing regularmente, envan los informes con los resultados y realizan el mantenimiento a las herramientas de testing. Rastreador (Tracker): Tiene como principal responsabilidad realizar las mediciones y la recoleccin de mtricas. Mide el progreso del proyecto y lo compara con lo estimado. Tambin observa el desempeo del equipo, haciendo nfasis en el cumplimiento de los plazos y aconsejando al equipo si deben realizar cambios para lograr los objetivos. Adems de todo esto, mantiene los registros de los casos de prueba ejecutados, los defectos encontrados y sus responsables. Consultor: Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto. Gua al equipo para resolver un problema especfico. Gestor (Big boss): Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin.1.1.7 Artefactos A continuacin describimos los artefactos de XP, entre los que se encuentran: Historias de Usuario, Tareas de Ingeniera y Tarjetas CRC.Historias de Usuario (Story Cards): Representan una breve descripcin del comportamiento del sistema, se emplean para hacer estimaciones de tiempo y para el plan de lanzamientos.Universidad nacional de Trujillo11 12. Historia de Usuario Nmero:Nombre Historia de Usuario:Modificacin (o extensin) de Historia de Usuario (Nro. y Nombre): Usuario:Iteracin Asignada:Prioridad en Negocio:Puntos Estimados:(Alta / Media / Baja) Riesgo en Desarrollo:Puntos Reales:(Alto / Medio / Bajo) Descripcin:Observaciones:Figura 2. Historia de usuarioLas Historias de Usuario tienen tres aspectos: Tarjeta: En ella se almacena suficiente informacin para identificar y detallar la historia. Conversacin: cliente y programadores discuten la historia para ampliar los detalles (verbalmente cuando sea posible, pero documentada cuando se requiera confirmacin). Pruebas de Aceptacin: permite confirmar que la historia ha sido implementada correctamente.Universidad nacional de Trujillo12 13. Caso de Prueba de AceptacinCdigo:Historia de Usuario (Nro. y Nombre):Nombre:Descripcin:Condiciones de Ejecucin:Entrada / Pasos de ejecucin:Resultado Esperado:Evaluacin de la Prueba:Figura 3. Prueba de aceptacinUniversidad nacional de Trujillo13 14. Tarjetas CRC (Clase-Responsabilidad-Colaborador): Estas tarjetas se dividen en tres secciones que contienen la informacin del nombre de la clase, sus responsabilidades y sus colaboradores.Figura 4. Tarjeta CRCUna 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 mtodos. Los colaboradores de una clase son las dems clases con las que trabaja en conjunto para llevar a cabo sus responsabilidades. En la prctica conviene tener pequeas tarjetas de cartn, que se llenarn 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 colaboradoresUniversidad nacional de Trujillo14 15. Disponer las tarjetas1.1.8 Ventajas y Desventajas 1.1.8.1 Ventajas: Programacin organizada. Menor taza de errores. Satisfaccin del programador. Solucin de errores de programas. Versiones nuevas. Implementa una forma de trabajo donde fcilmente a las circunstanciasse adapte1.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 innecesarioUniversidad nacional de Trujillo15 16. EJEMPLO DE XP FERRETERIA 1. Historias de usuario: Historia de Usuario Nmero: 1Usuario: VendedorNombre historia: Registro de clientes Prioridad en negocio: AltaRiesgo en desarrollo: AltaPuntos estimados: 2Iteracin asignada: 1Programador responsable: equipo xp Descripcin: Se mostrar por pantalla una interfaz donde permitir al administrador ingresar los datos de los clientes. Observaciones: Estos datos de los clientes se almacenarn en una Base De Datos CONFIRMADO con el clienteHistoria de Usuario Nmero: 2Usuario: VendedorNombre historia: Registrar productos Prioridad en negocio: Alta Puntos estimados: 2Riesgo en desarrollo: Alta Iteracin asignada: 1Programador responsable: equipo xp Descripcin: 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 categoras y marcas. CONFIRMADO con el clienteUniversidad nacional de Trujillo16 17. Historia de Usuario Nmero: 3Usuario: AdministradorNombre historia: Registrar proveedor Prioridad en negocio: Alta Puntos estimados: 2Riesgo en desarrollo: Alta Iteracin asignada: 1Programador responsable: equipo xp Descripcin: Se mostrar por pantalla una interfaz donde permitir al administrador ingresar los datos de los proveedores. Observaciones: Cada proveedor tiene un id diferente y est divido en categoras y marcas. CONFIRMADO con el clienteHistoria de Usuario Nmero: 3Usuario: VendedorNombre historia: Generar Factura Prioridad en negocio: AltaRiesgo en desarrollo: AltaPuntos estimados: 2Iteracin asignada: 1Programador responsable: equipo xp Descripcin: 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 automticamente su nmero de factura y su serie. CONFIRMADO con el cliente.Universidad nacional de Trujillo17 18. Historia de Usuario Nmero: 4Usuario: AdministradorNombre historia: Pedido De Productos Prioridad en negocio: Alta Puntos estimados: 2Riesgo en desarrollo: Alta Iteracin asignada: 1Programador responsable: equipo xp Descripcin: Se muestra por pantalla un tipo comprobante para que pueda realizar el pedido de los productos de acuerdo al proveedor. Observaciones: CONFIRMADO con el cliente1.1Historia de Usuario iteracin 1La tarea realizada en la primera iteracin fue: Crear la Base de datos con la que trabajaremos. Historia de Usuario Nmero: 1Usuario: VendedorNombre historia: Registrar productos Prioridad en negocio: Alta Puntos estimados: 2Riesgo en desarrollo: Alta Iteracin asignada: 1Programador responsable: equipo xp Descripcin: 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 categoras y marcas. CONFIRMADO con el clienteUniversidad nacional de Trujillo18 19. 1.2 Historia de usuario- iteracin 2 -El cliente hizo una modificacin en cuanto a la seguridad, agregar login. Modificacin en la Base de datos. Historia de UsuarioNmero: 4Usuario: Administrador y vendedorNombre historia: Ingresar al Sistema Prioridad en negocio: AltaRiesgo en desarrollo: AltaPuntos estimados: 2Iteracin asignada: 2Programador responsable: equipo xp Descripcin: Se muestra por pantalla una interfaz donde podrn colocar su nombre y contrasea. Observaciones: El administrador y cliente tendrn un nombre y contrasea almacenada en la Base de datos. CONFIRMADO con el cliente Historia de Usuario Nmero: 2Usuario: VendedorNombre historia: Registro de clientes Prioridad en negocio: AltaRiesgo en desarrollo: AltaPuntos estimados: 2Iteracin asignada: 1Programador responsable: equipo xp Descripcin: Se mostrar por pantalla una interfaz donde permitir al administrador ingresar los datos de los clientes. Observaciones: Estos datos de los clientes se almacenarn en una Base De Datos CONFIRMADO con el clienteUniversidad nacional de Trujillo19 20. Historia de Usuario Nmero: 5Usuario: VendedorNombre historia: Seleccionar producto Prioridad en negocio: Alta Puntos estimados: 2Riesgo en desarrollo: Alta Iteracin asignada: 2Programador responsable: equipo xp Descripcin: 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 clienteHistoria de Usuario Nmero: 6Usuario: VendedorNombre historia: Seleccionar cliente Prioridad en negocio: AltaRiesgo en desarrollo: AltaPuntos estimados: 2Iteracin asignada: 2Programador responsable: equipo xp Descripcin: 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 clienteUniversidad nacional de Trujillo20 21. Historia de Usuario Nmero: 7Usuario: VendedorNombre historia: Generar Factura Prioridad en negocio: Alta Puntos estimados: 2Riesgo en desarrollo: Alta Iteracin asignada: 1Programador responsable: equipo xp Descripcin: 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 automticamente su nmero de factura y su serie. Seleccionar el producto deseado con la historia de usuario nmero 2. Seleccionar el cliente con la historia de usuario nmero 3. CONFIRMADO con el cliente1.3Historia de usuario iteracin 3Historia de Usuario Nmero: 8Usuario: AdministradorNombre historia: Alerta de pedido Prioridad en negocio: Alta Puntos estimados: 2Riesgo en desarrollo: Alta Iteracin asignada: 1Programador responsable: equipo xp Descripcin: Se muestra por pantalla una interfaz en donde el sistema avisa al administrador los productos faltantes o que estn por agotarse. Observaciones: Este se llevar a cabo cuando la cantidad de venta llegue a la cantidad mnima del producto. CONFIRMADO con el clienteUniversidad nacional de Trujillo21 22. Historia de Usuario Nmero: 9Usuario: AdministradorNombre historia: Historial de Facturas Prioridad en negocio: AltaRiesgo en desarrollo: AltaPuntos estimados: 2Iteracin asignada: 1Programador responsable: equipo xp Descripcin: Se muestra por pantalla una interfaz en donde se podr registrar las facturas de ventas del vendedor/cajero Observaciones: CONFIRMADO con el clienteHistoria de Usuario Nmero: 10Usuario: AdministradorNombre historia: Historial de Facturas-proveedor Prioridad en negocio: AltaRiesgo en desarrollo: AltaPuntos estimados: 2Iteracin asignada: 1Programador responsable: equipo xp Descripcin: 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 clienteUniversidad nacional de Trujillo22 23. 2. Casos de prueba de aceptacin Casos de Prueba Historia de usuario: 1 registrar clientes Cdigo: 1 Nombre: Registro de Clientes Descripcin: Este permitir ingresar los datos de los clientes y almacenarlos en la base de datos. Condiciones de ejecucin: Este se llevar a cabo si el cliente a registrar al menos ha comprado un producto de la ferretera. Entrada/ Pasos de ejecucin: Tenemos como parmetros de entrada: - Nombre del cliente - Apellidos del cliente - Ruc - Dni - Telfono - Direccin Pasos de ejecucin: 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 Evaluacin de la prueba: Despus de hacer las pruebas, nos dimos cuenta que tenemos que hacer una actualizacin cada vez que ingresamos un nuevo registro.Universidad nacional de Trujillo23 24. Casos de Prueba Historia de usuario: 2 registrar productos Cdigo: 2 Nombre: Registro de Productos Descripcin: Este permitir ingresar los datos de los productos y almacenarlos en la base de datos. Condiciones de ejecucin: Este se llevar a cabo si el administrador tiende productos a registrar. Entrada/ Pasos de ejecucin: Tenemos como parmetros de entrada: - Nombre del producto - Cdigo del producto - Categora - Marca - Descripcin - Cantidad mnima - Cantidad de venta - Cantidad de almacn Pasos de ejecucin: 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 Evaluacin de la prueba: Despus de hacer las pruebas, nos dimos cuenta que tenemos que hacer una actualizacin cada vez que ingresamos un nuevo registro.Universidad nacional de Trujillo24 25. Casos de Prueba Historia de usuario: 3 registrar proveedores Cdigo: 3 Nombre: Registro de Productos Descripcin: Este permitir ingresar los datos de los proveedores y almacenarlos en la base de datos. Condiciones de ejecucin: Este se llevar a cabo si el administrador tiende proveedores a registrar. Entrada/ Pasos de ejecucin: Tenemos como parmetros de entrada: - Nombre del proveedor - Cdigo del proveedor Pasos de ejecucin: 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 Evaluacin de la prueba: Despus de hacer las pruebas, nos dimos cuenta que tenemos que hacer una actualizacin cada vez que ingresamos un nuevo registro.Casos de Prueba Historia de usuario: 4 ingresar al sistema Cdigo: 4 Nombre: Login Descripcin: Este permitir ingresar al sistema siempre y cuando tengas un permiso Condiciones de ejecucin: Este se llevar a cabo si en la base de datos estn registrados Entrada/ Pasos de ejecucin: Tenemos como parmetros de entrada: - Nombre del producto - Contrasea Pasos de ejecucin: 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 ests registrado de caso contrario acceso denegado. Resultado esperado: Los datos comparados con xito Evaluacin de la prueba: Prueba exitosaUniversidad nacional de Trujillo25 26. Casos de Prueba Historia de usuario: 5 seleccionar productos Cdigo: 5 Nombre: Lista de productos Descripcin: Este permitir visualizar todos los productos almacenados en la Base de datos Condiciones de ejecucin: Este se llevar a cabo si en la base de datos estn registrados los productos Pasos de ejecucin: En primer lugar tenemos que ingresar al sistema Ingresar a la interfaz listar productos e inmediatamente aparecern los productos Resultado esperado: Los datos son visualizas con xito Evaluacin de la prueba: Despus de haber analizado la prueba nos dimos cuenta que esto es bueno para cuando existen pocos productos.Casos de Prueba Historia de usuario: 6 seleccionar clientes Cdigo: 6 Nombre: Lista de clientes Descripcin: Este permitir visualizar todos los clientes almacenados en la Base de datos Condiciones de ejecucin: Este se llevar a cabo si en la base de datos estn registrados los clientes Pasos de ejecucin: En primer lugar tenemos que ingresar al sistema Ingresar a la interfaz listar clientes e inmediatamente aparecern los productos Resultado esperado: Los datos son visualizas con xito Evaluacin de la prueba: Despus de haber analizado la prueba nos dimos cuenta que esto es bueno para cuando existen pocos clientes.Universidad nacional de Trujillo26 27. Casos de Prueba Historia de usuario: 7 generar factura Cdigo: 7 Nombre: Facturar Descripcin: Este permitir realizar una venta de los productos almacenados a determinado cliente. Condiciones de ejecucin: Este se llevar a cabo si en la base de datos estn registrados los productos a vender, si no est registrado en cliente, se puede almacenar en el acto. Entrada/Pasos de ejecucin: Entrada: - Datos de los clientes - Datos de los productos - Cantidad de los productos a vender Pasos de ejecucin: 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 Evaluacin de la prueba: Despus de haber analizado la prueba nos dimos cuenta que tenemos que hacer varios ingresos a la base de datos para realizar una venta.Universidad nacional de Trujillo27 28. CONCLUSIONESEl desarrollo de software no es una tarea fcil. Prueba de ello es que existen numerosas propuestas metodolgicas. No existe una metodologa universal para hacer frente con xito a cualquier proyecto de desarrollo de software. Toda metodologa debe ser adaptada al contexto del proyecto. Una de las cualidades ms destacables de XP es su sencillez, tanto en su aprendizaje como en su aplicacin, reduciendo as los costos de implantacin en un equipo de desarrollo. Usar o no XP, depende del grupo de desarrollo de software y del sistema a implementar, este documento solo es una referencia para aquellos interesados en conocer o usar esta metodologa, pero para decidir que metodologa usar, primero se deben examinar las distintas propuestas metodolgicas.Universidad nacional de Trujillo28 29. BIBLIOGRAFIAhttp://es.wikipedia.org/wiki/Programaci%C3%B3n_Extrema https://www.google.com.pe/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&cad=rja&ved=0C FoQFjAG&url=http%3A%2F%2Fwww.dsic.upv.es%2Fasignaturas%2Ffacultad%2Flsi%2Fdoc%2F MetodologiasAgilesyExtremeProgramming.ppt&ei=VjShUuv_AdPnkAfvo4GoBw&usg=AFQjCNG QW5dyLViXWxZ2N5F4Pce1B1IrmQ&sig2=0yhnm9aMWAWtrxJy_LXPQw http://ingsoftware072301.obolog.com/metodologia-xp-2012877 http://ingenieriadesoftware.mex.tl/52753_XP---Extreme-Programing.htmlUniversidad nacional de Trujillo29