Metodologia XP

UNIVERSIDAD NACIONAL DE TRUJILLO

FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS

ESCUELA DE INFORMÁTICA

MONOGRAFÍA

METODOLOGÍAS ÁGILES

PROGRAMACIÓN EXTREMA XP

AUTORES:

BALAREZO PENADILLO JOEL MARCOS

CRUZ VASQUEZ EVELING GISELLE

LAMADRID BRINGAS FRANSHESCA

GUADALUPE – PERU

2013

INDICE

DEDICATORIA 3

INTRODUCCION 4

1. MARCO TEÓRICO 5

1.1 METODOLOGÍA EXTREME PROGRAMMING (XP) 5

1.1.1 Definición De Xp 5

1.1.2 Valores XP 6

1.1.3 Principales Conceptos 8

1.1.4 Ciclo de vida del XP 10

1.1.5 Ciclo de vida del programador 13

1.1.6 Roles Y Responsabilidades 15

1.1.7 Artefactos XP 16

1.1.8 Ventajas y Desventajas 20

2. PLICACIÓN DE LA METODOLOGÍA XP 21

2.1 DESCRIPCIÓN DEL PROYECTO 21

2.1.1 Historias de usuario 22

2.1.1.1 Historia de usuario – iteración 1 26



2.1.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


Esta monografía es el resultado del esfuerzo

conjunto de todos los que formamos el grupo de

trabajo. Por esto agradecemos a nuestro profesor,

Ing. Arturo Díaz Pulido, a quien le debemos gran

parte de nuestros conocimientos, gracias a su

paciencia y enseñanza y finalmente un eterno

agradecimiento a nuestra prestigiosa universidad

la cual nos prepara para un futuro competitivo y

nos forma como personas de bien.

INTRODUCCIÓN

La metodología ágil es importante durante el desarrollo del software, pero como

elegir una metodología que sea eficiente y nos ayude con el desarrollo del

proyecto.

Para elegir esta metodología tendría que lograr un código sin errores, con alta

funcionabilidad, manteniendo a cliente al tanto del proyecto y en plazos de tiempo

cómodos.

La Metodología de “Programación Extrema” (XP) propone la manera de alcanzar

esos objetivos.

Esta Metodología consiste en un conjunto de prácticas, fundamentadas en valores

que deben de mantener los participantes de proyecto que, a manera de trabajo en

grupo, pretende lograr como producto final un software con un muy alto grado de

calidad.

Las etapas que recomienda seguir esta metodología se plantean de manera

sencilla pero a la vez son estrictas, y se inspiran en la total participación de los

involucrados.

Por lo cual el presente informe nos presentará la metodología xp, sus valores,

principales conceptos entre otros.


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

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:


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

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.


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.


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.


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.


Muerte

Es cuando el cliente no tiene más historias para ser incluidas en el

sistema. Esto requiere que se satisfagan las necesidades del cliente en

otros aspectos como rendimiento y confiabilidad del sistema. Se genera la

documentación final del sistema y no se realizan más cambios en la

arquitectura.

La muerte del proyecto también ocurre cuando el sistema no genera los

beneficios esperados por el cliente o cuando no hay presupuesto para

mantenerlo.

1.1.5 Ciclo De Vida Del Programador


Figura 3. Ciclo de vida de XP

Éste ciclo de vida indica cómo trabajan los programadores para poder

codificar. A continuación se detallan cada una de las actividades:

1.1.5.1 Elección de pares

Toda la producción se realiza en pares.

El encargado de escribir piensa tácticamente, su pareja piensa

estratégicamente.

Se rotan los roles periódicamente.

1.1.5.2 Testing

Se escriben los testing unitarios.

Se verifica que los test fallen antes de codificar.

Se testea todo lo que posiblemente puede fallar.

1.1.5.3 Codificación

“Hacer algo que funcione de la manera más sencilla”

Implementar lo suficiente para hacer que el test pase.

Seguir el estándar de codificación.

1.1.5.4 Refactoring

Quitar toda porción de código que no parezcan estar bien y luego

verificar si el código aún pasa los test unitarios.

El código debe ser claro, no tener partes duplicadas y tener la menor

cantidad de clases y métodos posibles.

Realizar cambios pequeños y luego realizar los test unitarios.

1.1.5.5 Q & A


El cliente puede proveer rápidamente cualquier respuesta on-site.

Muchas preguntas requieren decisiones y el cliente debe estar

preparado para poder hacerlas.

El cliente suele escribir una story o un test de aceptación que

captura sus preguntas.

1.1.5.6 Integración

Llevar el código a la máquina donde se realiza la integración, unir el

sistema y correr todos los test.

Arreglar todos los errores para que pasen todos los test unitarios.

Si no es fácil la integración es mejor tirar todo y comenzar

nuevamente al día siguiente.

1.1.5.7 Retornar al inicio

Si resta tiempo, se puede elegir otra pareja o cambiar de roles y

comenzar con otra actividad.

1.1.6 Roles Y Responsabilidades


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.


Rastreador (Tracker)

Tiene como principal responsabilidad realizar las mediciones y la recolección

de métricas. Mide el progreso del proyecto y lo compara con lo estimado.

También observa el desempeño del equipo, haciendo énfasis en el

cumplimiento de los plazos y aconsejando al equipo si deben realizar

cambios para lograr los objetivos. Además de todo esto, mantiene los

registros de los casos de prueba ejecutados, los defectos encontrados y sus

responsables.

1.1.7 Artefactos XP

A continuación describimos los artefactos de XP, entre los que se encuentran:

Historias de Usuario y Tarjetas CRC.

Historias de Usuario (Story Cards)

Representan una breve descripción del comportamiento del sistema, se

emplean para hacer estimaciones de tiempo y para el plan de

lanzamientos.

Historia de Usuario


Número: Nombre Historia de Usuario:

Modificación (o extensión) de Historia de Usuario (Nro. y

Nombre):

Usuario: Iteración Asignada:

Prioridad en Negocio:

(Alta / Media / Baja)

Puntos Estimados:

Riesgo en Desarrollo:

(Alto / Medio / Bajo)

Puntos Reales:

Descripción:

Observaciones:

Las Historias de Usuario tienen tres aspectos:

Tarjeta: En ella se almacena suficiente información para identificar y

detallar la historia.

Conversación: cliente y programadores discuten la historia para ampliar

los detalles (verbalmente cuando sea posible, pero documentada

cuando se requiera confirmación)

Pruebas de Aceptación: permite confirmar que la historia ha sido

implementada correctamente.


Figura 4. Modelo propuesto para una historia de usuario


Figura 5. Modelo propuesto para una prueba de aceptación.

Caso de Prueba de Aceptación

Código: Historia de Usuario (Nro. y Nombre):

Nombre:

Descripción:

Condiciones de Ejecución:

Entrada / Pasos de ejecución:

Resultado Esperado:

Evaluación de la Prueba:

Tarjetas CRC (Clase-Responsabilidad-Colaborador)

Estas tarjetas se dividen en tres secciones que contienen la información

del nombre de la clase, sus responsabilidades y sus colaboradores.

Una clase es cualquier persona, cosa, evento, concepto, pantalla o reporte. Las

responsabilidades de una clase son las cosas que conoce y las que realizan, sus

atributos y métodos. Los colaboradores de una clase son las demás clases con

las que trabaja en conjunto para llevar a cabo sus responsabilidades.

En la práctica conviene tener pequeñas tarjetas de cartón, que se llenarán y que

son mostradas al cliente, de manera que se pueda llegar a un acuerdo sobre la

validez de las abstracciones propuestas.

Los pasos a seguir para llenar las tarjetas son los siguientes:

Encontrar clases

Encontrar responsabilidades

Definir colaboradores

Disponer las tarjetas

1.1.8 Ventajas Y Desventajas


A continuación veremos las ventajas y desventajas de usar la metodología

XP:

1.1.8.1 Ventajas:

Programación organizada.

Menor taza de errores.

Satisfacción del programador.

Solución de errores de programas.

Versiones nuevas.

Implementa una forma de trabajo donde se adapte fácilmente a las

circunstancias.

1.1.8.2 Desventajas:

Es recomendable emplearlo solo en proyectos a corto plazo

Altas comisiones en caso de fallar

Imposible prever todo antes de programar

Demasiado costoso e innecesario

2. APLICACIÓN DE METODOLOGÍA XP


Figura 7. Ventajas y desventajas de usar la Metodología XP.

2.1Descripción del proyecto:

El proyecto consiste en construir un software para una tienda de ropa

femenina, como la metodología es xp es aplicable para este proyecto porque

la tienda es mediana.

Su objetivo del proyecto es diseñar e implementar un software para la tienda,

para una eficiente y rápida realización de atención al cliente, así mismo como

una mejor administración de la esta.

Para llevar a cabo este proyecto trabajamos conjuntamente con el cliente, a

la cual le ayudamos para que nos diga que exactamente quiere que realice el

software.

Nos ayudamos con los siguientes artefactos:

Historia de usuario

Pruebas de aceptación

Tarjetas CRC

2.1.1 Historias de usuario:


Historia de Usuario

Número: 1 Usuario: Administrador y vendedor/cajero

Nombre historia: Registro de clientes

Prioridad en negocio:

Alta

Riesgo en desarrollo:

Alta

Puntos estimados: 2 Iteración asignada: 1

Programador responsable: equipo xp

Descripción:

Se mostrará por pantalla una interfaz donde permitirá al administrador ingresar los

datos de los clientes.

Observaciones:

Estos datos de los clientes se almacenarán en una Base De Datos

CONFIRMADO con el cliente

Historia de Usuario


Número: 2 Usuario: Administrador

Nombre historia: Registrar productos


Alta


Alta



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.


Historia de Usuario

Número: 3 Usuario: Vendedor/cajero

Nombre historia: Generar Factura


Alta


Alta


Programador responsable: Eveling Cruz Vásquez

Descripción:

Se muestra por pantalla una interfaz en donde se podrá realizar una venta, tiene

como entradas datos del cliente, datos de los productos y su total de monto.


Observaciones:

En la factura se genera automático su número de factura y su serie.


Historia de Usuario


Nombre historia: Gestión de datos de los proveedores


Alta


Alta



Descripción:

Se muestra por pantalla una interfaz con los datos de los proveedores, ya

almacenados en la Base De Datos

Observaciones:


Historia de Usuario



Nombre historia: Pedido De Productos


Alta


Alta



Descripción:

Se muestra por pantalla un tipo comprobante para que pueda realizar el pedido de

los productos de acuerdo al proveedor.

Observaciones:


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.

Historia de Usuario


Nombre historia: Registrar productos


Alta


Alta



Descripción:



Observaciones:

Cada producto tiene un id diferente y está divido en categorías y marcas.



Figura 7. Ventajas y desventajas de usar la Metodología XP.

Historia de Usuario


Nombre historia: Registro de clientes


Alta


Alta



Descripción:


los datos de los clientes.

Observaciones:

Estos datos de los clientes se almacenarán en una Base De Datos


Historia de Usuario

2.1.2 Número: 3 2.1.3 Usuario: Administrador

Nombre historia: Registrar Proveedores


Alta


Alta



Descripción:

Se muestra por pantalla una interfaz donde podemos ingresar los datos de los

proveedores


Observaciones:


Entrega de iteración 1:

Interfaces del sistema:

REGISTRAR PRODUCTOS (historia de usuario 1)

REGISTRAR CLIENTES (historia de usuario 2)


Fig.8 Interfaz Registrar Producto

- R

REGISTRAR PROVEEDORES (historia de usuario 3)


Fig.9 Interfaz Registrar Clientes


Fig.10 Interfaz Registrar Proveedores

2.1.3.1 Historia de usuario- iteración 2

- El cliente hizo una modificación en cuanto a la seguridad, agregar login.

- Modificación en la Base de datos.


Historia de Usuario


Nombre historia: Ingresar al Sistema

Prioridad en negocio: Riesgo en desarrollo:


Fig.11 Base de datos modificada- agregando login

Alta Alta


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.


Historia de Usuario


Nombre historia: Seleccionar producto


Alta


Alta



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.



Historia de Usuario


Nombre historia: Seleccionar cliente


Alta


Alta



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


Historia de Usuario


Nombre historia: Generar Factura


Alta


Alta




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.


Entrega de iteración 2:

Interfaces del sistema :

INGRESAR AL SISTEMA (historia de usuario 4)


SELECCIONAR PRODUCTO (historia de usuario 5)

SELECCIONAR CLIENTES (historia de usuario 6)


Fig.12 Interfaz Ingresar al sistema

Fig.13 Interfaz Seleccionar Productos

FACTURA (historia de usuario 7)


Fig.14 Interfaz Seleccionar Clientes

Fig.15 Interfaz Generar Factura

2.1.3.2 Historia de usuario – iteración 3

Historia de Usuario


Nombre historia: Alerta de pedido


Alta


Alta



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.


Historia de Usuario


Nombre historia: Historial de Facturas


Alta


Alta




Descripción:

Se muestra por pantalla una interfaz en donde se podrá registrar las facturas de

ventas del vendedor/cajero

Observaciones:


Historia de Usuario


Nombre historia: Historial de Facturas-proveedor


Alta


Alta



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:



Entrega de versiones Iteración 3:

Interfaces

HISTORIAL DE FACTURAS (historia de usuario 9)

HISTORIAL DE FACTURAS-PROVEEDOR (historia de usuario 10)


Fig.16 Interfaz Historial de facturas

Fig.17 Interfaz Historial facturas de los proveedores

2.1.2 Casos de prueba de aceptación

Casos de Prueba

Código: 1 Historia de usuario: 1 registrar clientes

Nombre:

Registro de Clientes

Descripción:

Este permitirá ingresar los datos de los clientes y almacenarlos en la base

de datos.

Condiciones de ejecución:

Este se llevará a cabo si el cliente a registrar al menos a comprado un

producto de la tienda.

Entrada/ Pasos de ejecución:

Tenemos como parámetros de entrada:

- Nombre del cliente

- Apellidos del cliente

- Ruc

- Dni

- Teléfono

- Dirección

Pasos de ejecución:

En primer lugar tenemos que ingresar al sistema

Luego ingresar los datos, enviarlos a la base de datos y por último

guardarlos.

Resultado esperado:

Los datos ingresaron con éxito

Evaluación de la prueba:

Después de hacer las pruebas, nos dimos cuenta que tenemos que hacer

una actualización cada vez que ingresamos un nuevo registro.


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.


Este se llevará a cabo si el administrador tiende productos a registrar.



- Nombre del producto

- Categoría

- Marca

- Descripción

- Cantidad mínima

- Cantidad de venta

- Cantidad de almacén




guardarlos.

Resultado esperado:






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.


Este se llevará a cabo si el administrador tiende proveedores a registrar.



- Nombre del proveedor

- Apellidos del proveedor

- Ciudad




guardarlos.

Resultado esperado:





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


Este se llevará a cabo si en la base de datos estén registrados




- Nombre del producto

- Contraseña



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


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


Este se llevará a cabo si en la base de datos estén registrados los productos




Ingresar a la interfaz listar productos e inmediatamente aparecerán los

productos

Resultado esperado:

Los datos son visualizas con éxito


Después de haber analizado la prueba nos dimos cuenta que esto es bueno


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


Este se llevará a cabo si en la base de datos estén registrados los clientes




Ingresar a la interfaz listar clientes e inmediatamente aparecerán los

productos

Resultado esperado:

Los datos son visualizas con éxito


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.


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



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


Después de haber analizado la prueba nos dimos cuenta que tenemos que

hacer varios ingresos a la base de datos para realizar una venta.

2.1.3 Tarjetas CRC

Registrar clientes:

REGISTRAR CLIENTES

- Obtener los datos de los

clientes.

- Conectar con la base de

datos.

- Ingresar los datos de

clientes en la base de

datos.

- Confirmar los datos.

Para el registro de clientes

se necesitaría de los datos

de los clientes.

- La clase cliente.

- La clase login


Registrar Productos

REGISTRAR PRODUCTOS


productos.


datos.


productos en la base de

datos.


Para el registro de

productos se necesitaría de


- La clase producto.

- La clase login

- La clase stock

- La clase marca

- La clase categoría

Registrar Proveedores

REGISTRAR PROVEEDORES


proveedores.


datos.


proveedores en la base de

datos.


Para el registro de

proveedores se necesitaría

de los datos de los

proveedores.

- La clase proveedor

- La clase login

Ingresar Al Sistema

INGRESAR AL SISTEMA


datos.

- Comparar los datos

Para ingresar al sistema se

necesita el usuario y la

contraseña y la confirmación


ingresados con lo de la

base de datos.


- Denegar el ingreso.

si acepta o no.

- La clase login

- La clase vendedor/ cajero

- La clase administrador

Seleccionar producto

SELECCIONAR PRODUCTO


datos.

- Seleccionar la tabla de la

base de datos donde

están registrados la base

de datos.

- Mostrar los datos de la

tabla.

- Mostrar en la interfaz.

- Seleccionar el producto.

Para la selección de

productos.

- La clase login

- La clase producto


- La clase marca

- La clase stock

Seleccionar Clientes

SELECCIONAR CLIENTES


datos.

- Seleccionar la tabla de la

base de datos donde

están registrados la base

de datos.

- Mostrar los datos de la

tabla.

- Mostrar en la interfaz.

Para la selección de

clientes.

- La clase login

- La clase cliente


- Seleccionar el cliente.

Facturar

FACTURAR


datos.

- Seleccionar el cliente

- Seleccionar el producto.

- Ingresar cantidad

- Calcular monto

- Generar factura

Para realizar una factura

- La clase login

- La clase factura

- La clase vende

- La clase producto

- La clase stock


- La clase marca

- La clase cliente

- La clase vendedor


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.


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


Metodologia XP

Documents

Transcript of Metodologia XP