SOFTWARE PARA EL CONTROL DE VENTAS DE UNA BODEGA

“METODOLOGÍA ÁGIL PROGRAMACION EXTREMA (XP)”

INTEGRANTES:

CHÁVEZ TEJADA, MAYRA ESPINOZA SUAREZ, JENNIFER YENGLE COSAMALÓN JORWIN

ESCUELA DE INGENIERIA INFORMATICA

INGENIERO:

ARTURO DÍAZ PULIDO

1

INTRODUCCION

Este esquema "tradicional" para abordar el desarrollo de software ha demostrado ser efectivo y necesario en proyectos de gran tamaño (respecto a tiempo y recursos), donde por lo general se exige un alto grado de ceremonia en el proceso. Sin embargo, este enfoque no resulta ser el más adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Ante las dificultades para utilizar metodologías tradicionales con estas restricciones de tiempo y flexibilidad, muchos equipos de desarrollo se resignan a prescindir del buen hacer de la ingeniería del software, asumiendo el riesgo que ello conlleva.En este escenario, las metodologías ágiles emergen como una posible respuesta para llenar ese vacío metodológico. Por estar especialmente orientadas para proyectos pequeños, las metodologías ágiles constituyen una solución a medida para ese entorno, aportando una elevada simplificación que a pesar de ello no renuncia a las prácticas esenciales para asegurar la calidad del producto. Las metodologías ágiles son sin duda uno de los temas recientesen ingeniería de software que están acaparando gran interés. Prueba de ello es que se están haciendo un espacio destacado en la mayoría de conferencias y workshops celebrados en los últimos años.

2

DEDICATORIA

Dedicamos el presente proyecto a

nuestro Dios, por habernos brindado la

salud y la sabiduría para poder guiarnos

en el proyecto, a nuestros padres que con

su esfuerzo y apoyo deposita su confianza

en estos años de estudio.

3

AGRADECIMIENTO.

Agradecemos al Administrador y

socios de la bodega en formato de autoservicio

en la zona de Ciudad de Dios, por permitirnos

realizar nuestro proyecto con gran satisfacción.

Al Ingeniero Arturo Díaz Pulido, que

con sus clases y enseñanzas, nos orientó   para

la realización de   nuestro proyecto.

4

INDICE

INTRODUCCION………………………..……………….………………………………..2

DEDICATORIA…………………….…..……..……………………………….…………..3

AGRADECIMIENTO…………..…..…………….………….…………………………….4

METODOLOGÍA ÁGIL XP: SOFTWARE PARA EL CONTROL DE VENTAS DE UNA BODEGA ……….…………………………………………………………………...6

1. ORIGEN PROGRAMACION EXTREMA (XP)……..……….……………………62. ¿QUE ES PROGRAMACIO EXTREMA O XP?................................................63. OBEJTIVOS DE XP..........................................................................................64. CARACTERISTICAS........................................................................................75. PRINCIPIOS DE LOS METODOS AGILES .....................................................76. VALORES QUE INSPIRAN XP........................................................................87. LAS VARIABLES DE LA METODOLOGIA AGIL XP......................................98. PRACTICAS DE PROGRAMACION EXTREMA(XP) ..................................109. DESCRIPCION DEL SOFTWARE PARA EL CONTROL DE VENTAS DE

UNA BODEGA……………………………………………………………………..119.1. Iera FASE: PLANIFICACION………………..…………………………….119.2. IIda FASE: DISEÑO………………………………………………………...15

ANEXOS……………………………………………………………………..169.3. IIIera FASE: DESARROLLO…………………………………………...…..199.4. IV FASE: PRUEBAS……………………………………………...………..20

CONCLUSIONES………………………………………………………………………..25

5

METODOLOGÍA ÁGIL XP: SOFTWARE PARA EL CONTROL DE VENTAS DE UNA BODEGA

1. ORIGEN PROGRAMACION EXTREMA (XP)

Nace de la mano de Kent Beck en el verano de 1996, cuando trabajaba para Chrysler Corporation. Él tenía varias ideas de metodologías para la realización de programas que eran cruciales para el buen desarrollo de cualquier sistema. Las ideas primordiales de sus sistemas las comunico en las revistas c++ Magazine en una entrevista que esta le hizo el año 1999.

2. ¿QUE ES PROGRAMACIO EXTREMA O XP?

Es una metodología ligera de desarrollo de aplicaciones que se basa en la simplicidad, la comunicación y la realimentación del código desarrollado.

3. OBEJTIVOS DE XP

La satisfacción del cliente. Potenciar el trabajo en grupo. Minimizar el riesgo actuando sobre las variables del proyecto: costo,

tiempo, calidad, alcance.

4. CARACTERISTICAS

6

Metodología basada en prueba y error para obtener un software que funcione realmente.

Fundamentada en principios. Está orientada hacia quien produce y usa software (el cliente participa

muy activamente). Reduce el coste del cambio en todas las etapas del ciclo de vida del

sistema. Combina las que han demostrado ser las mejores prácticas para

desarrollar software, y las lleva al extremo. Cliente bien definido. Los requisitos pueden cambiar. Grupo pequeño y muy integrado (2-12 personas). Equipo con formación elevada y capacidad de aprender.

5. PRINCIPIOS DE LOS METODOS AGILES

PRINCIPIO DESCRIPCION

PARTICIPACION DEL CLIENTE

Los clientes deben estar fuertemente implicados en todo el proceso de desarrollo. Su papel es proporcionar y priorizar nuevos requerimientos del sistema y evaluar las iteraciones del sistema.

ENTREGA INCREMENTAL

El software se desarrolla en incrementos, donde el cliente especifica los requerimientos a incluir en cada incremento.

PERSONAS, NO PROCESOSSe deben conocer y explotar las habilidades del equipo de desarrollo.se les debe dejar desarrollar sus propias formas de trabajar, sin procesos formales, a los miembros del equipo.

Se debe contar con que los

7

ACEPTAR EL CAMBIO requerimientos del sistema cambian, por lo que el sistema se diseña para dar cabida a estos cambios.

MANTENER LA SIMPLICIDADSe deben centrar en la simplicidad tanto en el software a desarrollar como en el proceso de desarrollo. Donde sea posible, se trabaja activamente para eliminar la complejidad del sistema.

5. VALORES QUE INSPIRAN XP

El desarrollo de software es una actividad humana, es afectada por la motivación, creencias y los instintos de las personas.Valores comunes: son los que permiten que las personas trabajen por el beneficio común antes que el propio.

6. LAS VARIABLES DE LA METODOLOGIA AGIL XP

8

Surge ante la necesidad de ofrecer una alternativa a las metodologías tradicionales, caracterizadas por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades desarrolladas.

a. EL COSTE DEL CAMBIO

Evolución de los largos ciclos de desarrollo en cascada(a) a ciclos iterativos más cortos (b) y a la mezcla que hace XP.

b. CICLO DE ENTREGA EN XP

c. CICLO DE VIDA DEL PROCESO XP

9

7. PRACTICAS DE PROGRAMACION EXTREMA(XP)

a. PRACTICAS DE CODIFICACION

Simplicidad de código y diseño para producir software fácil de modificar.

Reingeniería continúa para lograr que el código tenga un diseño óptimo.

Desarrollar estándares de codificación, para comunicar ideas con claridad a través del código.

Desarrollar un vocabulario común, para comunicar las ideas sobre el código con claridad.

b. PRACTICAS DE DESARROLLO

Adoptar un método de desarrollo basado en las prueba para asegurar que el código se comporta según lo esperado.

Programación por parejas, para incrementar el conocimiento, la experiencia y las ideas.

Asumir la prioridad colectiva del código, para que todo el equipo sea responsable de él.

Integración continua, para reducir el impacto de la incorporación de nuevas funcionalidades.

c. PRACTICAS DE NEGOCIO

10

Integración de un representante del cliente en el equipo, para encauzar las cuestiones de negocio del sistema de forma directa, sin retrasos o pérdidas por intermediación.

Adoptar el juego de la planificación para centrar en la agenda el trabajo más importante.

Entregas regulares y frecuentes para satisfacer la inversión del cliente.

Ritmo de trabajo sostenible, para terminar la jornada cansado pero no agotado.

8. DESCRIPCION DEL SOFTWARE PARA EL CONTROL DE VENTAS DE UNA BODEGA

Se trata de una bodega en formato de autoservicio en la zona de Ciudad de Dios.Al momento de iniciar el proyecto, el negocio contaba con una caja registradora convencional la cual no ofrecía las funcionalidades que requería el cliente, por lo cual se acordó desarrollar un software que desempeñara las funcionalidades de un sistema con elementos de administración de inventario que cumpliera las necesidades específicas del cliente. Al finalizar dicho proyecto, pusimos en modo de prueba con el mismo administrador y un vendedor para verificar que cumpla con sus requerimientos. Tuvimos que hacer algunos cambios pequeños, pero al final el cliente quedó satisfecho.

FASES DE LA METODOLOGIA XP

8.1. Iera FASE: PLANIFICACION

XP plantea la planificación como un permanente dialogo entre las partes la empresarial (deseable) y la técnica (posible).

a) HISTORIA DE USUARIO

11

Las historias de usuario tienen el mismo propósito que los casos de uso. Las escriben los propios clientes, tal y como en ellos las necesidades del sistema. Las historias de usuario solamente proporcionaran los detalles sobre la estimación del riesgo y cuánto tiempo conllevará la implementación de dicha historia de usuario.

Con respecto al proyecto la historia de usuario es:

Administrador: Se encarga de verificar los ingresos/egresos del negocio cuando él quiera. También verifica si hay stock de algún producto o si se necesita comprar, y es el encargado de agregar/quitar nuevos productos, y es el único que puede agregar y eliminar usuarios (vendedores).

Vendedor: Se encarga de vender, recibir dinero y dar cambio si es necesario, e informa al administrador si en caso falta stock de algún producto.

b) PLAN DE ENTREGA

Es una planificación donde los desarrolladores y clientes establecen los tiempos de implementación ideales de las historias de usuario, la prioridad con la que serán implementadas y las historias que serán implementadas en cada versión del programa.

12

CALENDARIO DE TRABAJO

Semana 18-24 de noviembre

Martes 19 a Jueves 21Elaboración de la base de datos para almacenar el stock y el dinero en caja (diseño de base de datos y consultas).

Viernes 22 Elaboración de interfaces de usuario (Vendedor).

Sábado 24 Elaboración de interfaces de usuario (Administrador).

c) PLAN DE ITERACION

Así puede verse un plan de iteración

Leer las Historias

Detallar las tareas

13

Tormentas de ideas- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Reparto de tareas

Estoy demasiado ocupadoEs demasiado grande

d) ROTACIONES

Evitaran que las personas se conviertan en si mismas en un cuello de botella. Las rotaciones permitirán que todo el mundo conozca cómo funciona el sistema.

e) REUNIONES

Reuniones de seguimiento diarias.

f) CORRECIONES

Deberemos corregir el proceso cuando este falle. Todo el mundo debe estar al corriente de los cambios.

Tareas sin asignar

Seleccionar y estimar las

tareas

Programador 1

Programador 2

Programador 3

14

Para que esto funcione correctamente se tiene que tomar en cuenta las pruebas de cada módulo que se desarrolla.

8.2. IIda FASE: DISEÑO

El diseño adecuado para el software es aquel que funciona con todas las pruebas, no tiene lógica duplicada, manifiesta cada intención importante para los programadores.

Entre los más importantes que menciona XP referente al diseño son:

Simplicidad: sugiere que hay conseguir diseños simples y sencillos.

Las tarjetas CRC: representan objetos, la clase a la que pertenece el objeto se puede escribir en la parte de arriba de la tarjeta, en una columna a la izquierda se pueden escribir las responsabilidades u objetivos que debe cumplir el objeto y a la derecha, las clases que colaboran con cada responsabilidad.

El Refactorizar: es mejorar y modificar la estructura y codificación de códigos ya creados sin alterar su funcionalidad. Refactorizar supone revisar de nuevo estos códigos para procurar optimizar su funcionamiento.

ANEXOS:

15

Diseño de Software para el control de ventas de una bodega

Ventana principal usuario y contraseña

Ventana del administrador

Ventana Cambiando Password

Ventana agregar usuario

16

Ventana de mensaje

Ventana de entrada: la cantidad que desea ingresar

Ventana de entrada: la cantidad que desea retirar

Ventana de entrada: usuario a eliminar

Ventana lista de usuarios

17

Ventana de ingresar la categoría

Ventana donde se va almacenando la lista de productos

Ventana agregar productos

Ventana final

18

8.3. IIIera FASE: DESARROLLO

Disponibilidad del cliente Unidades de prueba o test Programación pareja Integración del código Frecuencia en la integración del código El código es propiedad de todos Dejar de optimizaciones para el final No a las horas extras.

19

En esta fase va el código del proyecto:

Agregar Producto Agregar Stock Agregar Vendedor Cambiar Password Login Modificar Vendedor Ventana Root Ventana Usuario Ver Productos Ver Vendedores

8.4. IV FASE: PRUEBAS

Unidades de test o pruebas: pilar básico. Implantación: el código será implantado cuando supere sus

correspondientes unidades de test. Protección contra fallos: solución, un test. Pruebas de aceptación: evaluación del cliente.

En esta fase se van aplicando las pruebas de aceptación de cada ventana del Software para el control de ventas de una bodega.

Se ingresa el usuario y la contraseña.

20

En esta ventana se ingresa los datos del administrador.

21

22

Esta ventana es del vendedor

23

9. CONCLUSION

La programación extrema es una forma ligera, eficiente, flexiva, predecible, científica y divertida de generar software.

La programación extrema se beneficia de la existencia de un gran número de herramientas de software libre que permiten aplicarla con gran productividad.

El software libre se inspira en alguna de las prácticas de la XP.

Aprovecha el tiempo de los clientes y ayuda a que un cliente se sienta integrado, evitando que se desmoralice por no saber cómo preparar pruebas de aceptación.

24

El proceso de desarrollo de las pruebas ayuda al cliente a clarificar y concretar la funcionalidad de la historia de uso y favorece la comunicación entre el cliente y el equipo de desarrollo.

El desarrollo de pruebas ayuda identificar y corregir fallos u omisiones en las historia de uso.

Permite corregir errores en las ideas del cliente, también permite identificar historias adicionales que no fueran obvias para el cliente o en las que el cliente no hubiese de no enfrentarse a dicha situación.

Garantiza la cobertura de la funcionalidad de las pruebas de aceptación, garantizando que no se deja ningún punto importante de la funcionalidad de una historia de uso sin probar.

25