1. ESCUELA DE INGENIERIA INFORMATICA
SOFTWARE PARA EL CONTROL DE VENTAS DE
UNA BODEGA
“METODOLOGÍA ÁGIL PROGRAMACION EXTREMA (XP)”
INGENIERO:
ARTURO DÍAZ PULIDO
INTEGRANTES:
CHÁVEZ TEJADA, MAYRA
ESPINOZA SUAREZ, JENNIFER
YENGLE COSAMALÓN JORWIN
1
2. 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
3. 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
4. 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
5. INDICE
INTRODUCCION………………………..……………….………………………………..2
DEDICATORIA…………………….…..……..……………………………….…………..3
AGRADECIMIENTO…………..…..…………….………….…………………………….4
METODOLOGÍA ÁGIL XP: SOFTWARE PARA EL CONTROL DE VENTAS DE
UNA BODEGA ……….…………………………………………………………………...6
1.
2.
3.
4.
5.
6.
7.
8.
9.
ORIGEN PROGRAMACION EXTREMA (XP)……..……….……………………6
¿QUE ES PROGRAMACIO EXTREMA O XP?................................................6
OBEJTIVOS DE XP..........................................................................................6
CARACTERISTICAS........................................................................................7
PRINCIPIOS DE LOS METODOS AGILES .....................................................7
VALORES QUE INSPIRAN XP........................................................................8
LAS VARIABLES DE LA METODOLOGIA AGIL XP......................................9
PRACTICAS DE PROGRAMACION EXTREMA(XP) ..................................10
DESCRIPCION DEL SOFTWARE PARA EL CONTROL DE VENTAS DE
UNA BODEGA……………………………………………………………………..11
9.1. Iera FASE: PLANIFICACION………………..…………………………….11
9.2. IIda FASE: DISEÑO………………………………………………………...15
ANEXOS……………………………………………………………………..16
9.3. IIIera FASE: DESARROLLO…………………………………………...…..19
9.4. IV FASE: PRUEBAS……………………………………………...………..20
CONCLUSIONES………………………………………………………………………..25
5
6. 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
7.
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
PARTICIPACION DEL CLIENTE
ENTREGA INCREMENTAL
PERSONAS, NO PROCESOS
DESCRIPCION
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.
El software se desarrolla en
incrementos,
donde
el
cliente
especifica los requerimientos a incluir
en cada incremento.
Se 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.
7
8. ACEPTAR EL CAMBIO
MANTENER LA SIMPLICIDAD
Se debe contar con que los
requerimientos del sistema cambian,
por lo que el sistema se diseña para
dar cabida a estos cambios.
Se 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.
8
9. 6. LAS VARIABLES DE LA METODOLOGIA AGIL XP
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
10. 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
11.
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
12. 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
13. CALENDARIO DE TRABAJO
Semana 18-24 de noviembre
Martes 19 a Jueves 21
Elaboració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
14. -
Tormentas de ideas
- - - ----------------------------
Reparto de tareas
Tareas sin
asignar
Seleccionar y
estimar las
tareas
Estoy demasiado ocupado
Es demasiado grande
Programa
dor 1
Programa
dor 2
Programa
dor 3
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.
14
15.
8.2.
Para que esto funcione correctamente se tiene que tomar en
cuenta las pruebas de cada módulo que se desarrolla.
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
16. 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
17. 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
18. Ventana de ingresar la categoría
Ventana donde se va almacenando la lista de productos
Ventana agregar productos
Ventana final
18
19. 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
20. En esta fase va el código del proyecto:
8.4.
Agregar Producto
Agregar Stock
Agregar Vendedor
Cambiar Password
Login
Modificar Vendedor
Ventana Root
Ventana Usuario
Ver Productos
Ver Vendedores
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
21. En esta ventana se ingresa los datos del administrador.
21
24. 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.
24
25.
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.
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