UNIVERSIDAD NACIONAL DE TRUJILLO SUB SEDE VALLE
JEQUETEPEQUE
FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS
INFORMÁTICA

MONOG...
ÍNDICE

DEDICATORIA

3

INTRODUCCIÓN

4

1. MARCO TEÓRICO

5

1.1 Extreme programing

5

1.1.1 Definición

5

1.1.2 Valore...
Primeramente a Dios a Dios por habernos
permitido llegar hasta este punto y habernos
dado salud, ser el manantial de vida ...
INTRODUCCION

La metodología ágil es importante durante el desarrollo del software, pero como
elegir una metodología que s...
1. MARCO TEÓRICO
1.1 EXTREME PROGRAMMING (XP)
1.1.1 Definición
Fue creado por Kent Beck, para la plantilla del proyecto C3...
sencilla, entendible y que se entregue al cliente lo que necesita.
Coraje/valentía: La valentía le permite a los desarroll...
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...
escribir el código de la prueba antes de la codificación.
Programación en parejas: Se recomienda que las tareas de
desarro...
acuerdo entre los clientes y los programadores en cuáles serán
las stories a ser implementadas durante cada iteración. Si ...
Figura 1. Ciclo de vida XP

1.1.6 Actores y responsabilidades
Programador: Responsable de decisiones técnicas; construir e...
conocimientos y experiencia al resto del equipo.

Encargado de pruebas (Tester): Los tester ayudan a los
clientes a escrib...
Historia de Usuario
Número:

Nombre Historia de Usuario:

Modificación (o extensión) de Historia de Usuario (Nro. y
Nombre...
Caso de Prueba de Aceptación

Código:

Historia de Usuario (Nro. y Nombre):

Nombre:

Descripción:

Condiciones de Ejecuci...
Tarjetas CRC (Clase-Responsabilidad-Colaborador): Estas
tarjetas se dividen en tres secciones que contienen la información...
 Disponer las tarjetas

1.1.8 Ventajas y Desventajas
1.1.8.1 Ventajas:
Programación organizada.
Menor taza de errores.
Sa...
EJEMPLO DE XP – FERRETERIA
1. Historias de usuario:
Historia de Usuario
Número: 1

Usuario: Vendedor

Nombre historia: Reg...
Historia de Usuario
Número: 3

Usuario: Administrador

Nombre historia: Registrar proveedor
Prioridad en negocio:
Alta
Pun...
Historia de Usuario
Número: 4

Usuario: Administrador

Nombre historia: Pedido De Productos
Prioridad en negocio:
Alta
Pun...
1.2 Historia de usuario- iteración 2
-

El cliente hizo una modificación en cuanto a la seguridad, agregar login.
Modifica...
Historia de Usuario
Número: 5

Usuario: Vendedor

Nombre historia: Seleccionar producto
Prioridad en negocio:
Alta
Puntos ...
Historia de Usuario
Número: 7

Usuario: Vendedor

Nombre historia: Generar Factura
Prioridad en negocio:
Alta
Puntos estim...
Historia de Usuario
Número: 9

Usuario: Administrador

Nombre historia: Historial de Facturas
Prioridad en negocio:
Alta

...
2. Casos de prueba de aceptación
Casos de Prueba
Historia de usuario: 1 registrar clientes
Código: 1
Nombre:
Registro de C...
Casos de Prueba
Historia de usuario: 2 registrar productos
Código: 2
Nombre:
Registro de Productos
Descripción:
Este permi...
Casos de Prueba
Historia de usuario: 3 registrar proveedores
Código: 3
Nombre:
Registro de Productos
Descripción:
Este per...
Casos de Prueba
Historia de usuario: 5 seleccionar productos
Código: 5
Nombre:
Lista de productos
Descripción:
Este permit...
Casos de Prueba
Historia de usuario: 7 generar factura
Código: 7
Nombre:
Facturar
Descripción:
Este permitirá realizar una...
CONCLUSIONES

El desarrollo de software no es una tarea fácil. Prueba de ello es que existen
numerosas propuestas metodoló...
BIBLIOGRAFIA

http://es.wikipedia.org/wiki/Programaci%C3%B3n_Extrema
https://www.google.com.pe/url?sa=t&rct=j&q=&esrc=s&so...
Próxima SlideShare
Cargando en…5
×

Monografia de xp

1.268 visualizaciones

Publicado el

eXtreme Programming

Publicado en: Educación
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
1.268
En SlideShare
0
De insertados
0
Número de insertados
4
Acciones
Compartido
0
Descargas
95
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Monografia de xp

  1. 1. UNIVERSIDAD NACIONAL DE TRUJILLO SUB SEDE VALLE JEQUETEPEQUE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS INFORMÁTICA MONOGRAFÍA METODOLOGÍA XP AUTORES: JOSÉ SANCHÉZ FLORES JOSÉ RODRÍGUEZ CARUAJULCA GUIDO MOSTACERO ESPINOZA GUADALUPE – PERÚ 2013 Universidad nacional de Trujillo 1
  2. 2. ÍNDICE DEDICATORIA 3 INTRODUCCIÓN 4 1. MARCO TEÓRICO 5 1.1 Extreme programing 5 1.1.1 Definición 5 1.1.2 Valores 5 1.1.3 Conceptos 6 1.1.4 Características fundamentales 7 1.1.5 Ciclo de vida 8 1.1.6 Actores y responsabilidades 10 1.1.7 Artefactos 11 1.1.8 Ventajas y desventajas 15 1.1.8.1 Ventajas 15 1.1.8.2 Desventajas 15 1.1.9 Ejemplo 16 CONCLUSIONES 28 BIBLIOGRAFÍA 29 Universidad nacional de Trujillo 2
  3. 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 día a día para lograr nuestros objetivos, además de su infinita bondad y amor. A nuestros padres por habernos apoyado en todo momento, por sus consejos, sus valores, por la motivación constante que nos ha permitido ser personas de bien, pero más que nada, por su amor. Universidad nacional de Trujillo 3
  4. 4. INTRODUCCION 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. La XP se puede definir como un conjunto de pasos de diversas metodologías, acopladas de manera que sean pasos flexibles a seguir utilizadas con el uso común, para realizar un desarrollo más agradable y sencillo. Así, la XP se puede definir como un conjunto de pasos de diversas metodologías, acopladas de manera que sean pasos flexibles a seguir utilizadas con el uso común, para realizar un desarrollo más agradable y sencillo. Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software. Esta metodología tiene como base la simplicidad y como objetivo principal la satisfacción del cliente. 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 la presente monografía nos presentará la metodología xp, sus valores, principales conceptos entre otros. Universidad nacional de Trujillo 4
  5. 5. 1. MARCO TEÓRICO 1.1 EXTREME PROGRAMMING (XP) 1.1.1 Definición Fue creado por Kent Beck, para la plantilla del proyecto C3 en Chrysler. Durante el proceso del proyecto C3 Chrysler metodología llamada extreme programming. nació una nueva La programación extrema o eXtremeProgramming (XP) es una metodología de desarrollo ágil, una de las más exitosas en tiempo reciente. Su autor principal es Kent Beck, quien eligió algunas características de otras metodologías 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á diseñado 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 metodología XP en un proyecto tenemos que conocer los valores principales, los cuales son los siguientes. Simplicidad: La simplicidad es la base de la programación extrema, se refiere que ante todo y sin importar qué funcionalidad requiera el usuario en su sistema, éste debe ser fácil. El diseño debe ser sencillo y amigable al usuario, el código debe ser simple y entendible, programando sólo lo necesario y lo que se utilizará. Comunicación: Es muy importante que haya una comunicación constante con el cliente y dentro de todo el equipo de trabajo, de esto dependerá que el desarrollo se lleve a cabo de una manera Universidad nacional de Trujillo 5
  6. 6. sencilla, entendible y que se entregue al cliente lo que necesita. Coraje/valentía: La valentía le permite a los desarrolladores que se sientan cómodos con reconstruir su código cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se implementaran más fácilmente. Otro ejemplo de valentía es saber cuándo desechar un código: valentía para quitar código fuente obsoleto, sin importar cuanto esfuerzo y tiempo se invirtió en crear ese código. Además, valentía significa persistencia: un programador puede permanecer sin avanzar en un problema complejo por un día entero, y luego lo resolverá rápidamente al día siguiente, sólo si es persistente. Retroalimentación (Feedback): Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real. Es la comunicación 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 estimación de cada una de las iteraciones durante la fase de planificación. Las storycards 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. 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. 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. Universidad nacional de Trujillo 6
  7. 7. 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. 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. 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 Características fundamentales Las características fundamentales del método son: Desarrollo iterativo e incremental: Pequeñas mejoras, unas tras otras. Pruebas unitarias continuas: Frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja Universidad nacional de Trujillo 7
  8. 8. escribir el código de la prueba antes de la codificación. Programación en parejas: Se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. La mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata. Frecuente integración del equipo de programación con el cliente o usuario: Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo. Corrección de todos los errores: Antes de añadir nueva funcionalidad. Hacer entregas frecuentes. Refactorización del código: Es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo. Propiedad del código compartida: En vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados. Simplicidad en el código:La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más 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: Exploración: En esta fase los clientes realizan las storycards 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. Planificación: El propósito de esta fase es el de llegar a un Universidad nacional de Trujillo 8
  9. 9. 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. 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. 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. 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. Universidad nacional de Trujillo 9
  10. 10. Figura 1. Ciclo de vida XP 1.1.6 Actores y responsabilidades Programador: Responsable de decisiones técnicas; construir el sistema; diseña y realizar pruebas. Debe existir una comunicación y coordinación 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 decisión de cuando se debe implementar determinada funcionalidad, así como también en el orden a ser implementadas. 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 Universidad nacional de Trujillo 10
  11. 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. Además, corren dichos testing regularmente, envían 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 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. Consultor: Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto. Guía al equipo para resolver un problema específico. Gestor (Big boss): Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación. 1.1.7 Artefactos A continuación describimos los artefactos de XP, entre los que se encuentran: Historias de Usuario, Tareas de Ingeniería 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 11
  12. 12. 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 2. 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 12
  13. 13. 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 3. Prueba de aceptación Universidad nacional de Trujillo 13
  14. 14. 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 4. 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 Universidad nacional de Trujillo 14
  15. 15.  Disponer las tarjetas 1.1.8 Ventajas y Desventajas 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 fácilmente a las circunstancias se adapte 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 Universidad nacional de Trujillo 15
  16. 16. EJEMPLO DE XP – FERRETERIA 1. Historias de usuario: Historia de Usuario Número: 1 Usuario: Vendedor 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 Número: 2 Usuario: Vendedor Nombre historia: Registrar productos Prioridad en negocio: Alta Puntos estimados: 2 Riesgo en desarrollo: Alta 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 16
  17. 17. Historia de Usuario Número: 3 Usuario: Administrador Nombre historia: Registrar proveedor Prioridad en negocio: Alta Puntos estimados: 2 Riesgo en desarrollo: Alta 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 proveedores. Observaciones: Cada proveedor tiene un id diferente y está divido en categorías y marcas. CONFIRMADO con el cliente Historia de Usuario Número: 3 Usuario: Vendedor Nombre historia: Generar Factura 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á 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áticamente su número de factura y su serie. CONFIRMADO con el cliente. Universidad nacional de Trujillo 17
  18. 18. Historia de Usuario Número: 4 Usuario: Administrador Nombre historia: Pedido De Productos Prioridad en negocio: Alta Puntos estimados: 2 Riesgo en desarrollo: Alta 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 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. Historia de Usuario Número: 1 Usuario: Vendedor Nombre historia: Registrar productos Prioridad en negocio: Alta Puntos estimados: 2 Riesgo en desarrollo: Alta 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 18
  19. 19. 1.2 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. Historia de Usuario Número: 4 Usuario: Administrador y vendedor Nombre historia: Ingresar al Sistema 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 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: 2 Usuario: Vendedor 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 Universidad nacional de Trujillo 19
  20. 20. Historia de Usuario Número: 5 Usuario: Vendedor Nombre historia: Seleccionar producto Prioridad en negocio: Alta Puntos estimados: 2 Riesgo en desarrollo: Alta 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 Historia de Usuario Número: 6 Usuario: Vendedor 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 Universidad nacional de Trujillo 20
  21. 21. Historia de Usuario Número: 7 Usuario: Vendedor Nombre historia: Generar Factura Prioridad en negocio: Alta Puntos estimados: 2 Riesgo en desarrollo: Alta 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áticamente su número de factura y su serie. Seleccionar el producto deseado con la historia de usuario número 2. Seleccionar el cliente con la historia de usuario número 3. CONFIRMADO con el cliente 1.3 Historia de usuario – iteración 3 Historia de Usuario Número: 8 Usuario: Administrador Nombre historia: Alerta de pedido Prioridad en negocio: Alta Puntos estimados: 2 Riesgo en desarrollo: Alta 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 o que están por agotarse. Observaciones: Este se llevará a cabo cuando la cantidad de venta llegue a la cantidad mínima del producto. CONFIRMADO con el cliente Universidad nacional de Trujillo 21
  22. 22. 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 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 22
  23. 23. 2. Casos de prueba de aceptación Casos de Prueba Historia de usuario: 1 registrar clientes Código: 1 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 ha comprado un producto de la ferretería. 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 23
  24. 24. Casos de Prueba Historia de usuario: 2 registrar productos Código: 2 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 - Código 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 24
  25. 25. Casos de Prueba Historia de usuario: 3 registrar proveedores Código: 3 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 - Código del proveedor 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 Historia de usuario: 4 ingresar al sistema Código: 4 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 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 Universidad nacional de Trujillo 25
  26. 26. Casos de Prueba Historia de usuario: 5 seleccionar productos Código: 5 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: 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 para cuando existen pocos productos. Casos de Prueba Historia de usuario: 6 seleccionar clientes Código: 6 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: 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. Universidad nacional de Trujillo 26
  27. 27. Casos de Prueba Historia de usuario: 7 generar factura Código: 7 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. 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. Universidad nacional de Trujillo 27
  28. 28. CONCLUSIONES El desarrollo de software no es una tarea fácil. Prueba de ello es que existen numerosas propuestas metodológicas. No existe una metodología universal para hacer frente con éxito a cualquier proyecto de desarrollo de software. Toda metodología debe ser adaptada al contexto del proyecto. Una de las cualidades más destacables de XP es su sencillez, tanto en su aprendizaje como en su aplicación, reduciendo así los costos de implantación 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 metodología, pero para decidir que metodología usar, primero se deben examinar las distintas propuestas metodológicas. Universidad nacional de Trujillo 28
  29. 29. BIBLIOGRAFIA http://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.html Universidad nacional de Trujillo 29

×