'U1nivers'

'Tcnica e JVfl.a1flW!b jFactuta,d:e, Ciencias lnfmr;m;tcO/S lngen;,e:tr1L eCSoftware

Grupo
Tem2l:
.:. Proqramacn Extrema (XP)

.:. Arteaqa Alcvar LiI rana Da n tela

.:. Menqozil MenqoZil Cerna Michell :SoSil Rosales Roberth Alexander

SptImo "A"

Profesor:
Ing. Milt"icelil Pinarqote Pottovlelo 2Of2

Esta Metodologa consiste en un conjunto de prcticas, 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.

A lo largo de los aos la aplicacin de esta metodologa ha dado los mejores resultados, las etapas que plantea han sido llevadas al extremo, en muchos lugares del mundo, y en diversos mbitos de la actividad humana donde se ha necesitado disear un sistema informtico.

Caractersticas ok Ca
:Mletof)Coaia XP
DesarrOllO iterativo
~

e incremental

.... ,

pruebas unitarias continuas

....

programacin en parejas

Integracin del equipo de

(
>.

programacin con el cliente

.. ..

Correccin de todos lOSerrores

Refactorizacin cdigo

del

.... ,.
,

propiedad del Cdigocompartida

...

SimPlicidad

'RoCes le Ca JWJ.etoo(oa1L XP
1'.
PrOgl"amador Cliente Encargado de Pruebas TracKer

Enereoador

ConSUlwr

__ ...

Historiasdel Valores

Usuario de Aceptacin

...... Criterios de pruebas ~ Plan de Iteracill

:.- Diseo Simple :.- Tarjet ..s CRC

../ ../

Soluciones en punta Prototicos

lanzamiento Incre!mC!nto de! software!

Velocidad
proyecto

calculada

del

Prueba de unidad
Prueba de Aceptacin

.:.

Programacin

por parejas

InteElracin continua

'Ventajas y 'Desventajas
Ventajas: .~ Programacin organizada . ~ Menor taza de errores . ~ Satisfaccin del programador . ~ Solucin de errores de programas .~ Versiones nuevas .~ Implementa una forma de trabajo donde se adapte fcilmente a las circunstancias

Desventajas: ;.. Esrecomendable emplearlo solo en proyectos a corto plazo. ;.. Altas comisiones en caso de fallar. ;.. Imposible prever todo antes de programar ;.. Demasiado costoso.

'"

Descripcin

del negocio:

Se trata de un mini mercado en formato de autoservicio con un capital de aproximadamente quince millones de pesos el cual atiende a una poblacin alrededor de 550 familias ubicado en la zona de Altos de Llano Grande cerca al Parque Industrial en la ciudad de Pereira. Al momento de iniciar el proyecto, el negocio contaba con una caja registradora convencional la cual no ofreca las funcionalidades que requera el cliente, por lo cual se acord desarrollar un software que desempeara las funcionalidades de un sistema POS (Polnt Of Sale) con elementos de administracin de inventario que cumpliera las necesidades especficas del cliente.

HERRAMIENTAS EMPLEADAS
Se opt por seleccionar herramientas libres para el desarrollo de la aplicacin. Por un lado se emple JAVA como herramienta de desarrollo mientras que como motor de base de datos se decidi por Postgres SQL

HISTORIAS DE USUARIO
Lo que
Escritas por el usuario. Terminologa del cliente. -Ba]o nivel de detalle Sirve de base para estimar los tiempos de implementacin -No deben ser menos de 20 ni ms de 80

dlceXP:

ooo

Si bien el cliente no fue quien escribi personalmente las historias de usuario, fue l quien dise su contenido y dirigi la redaccin de las mismas. Desde el punto de vista del nivel de detalle, se sigui la directiva en el sentido de no profundizar ni en descripciones ni en procesos, mantenindolas de esta forma breves y claras.

Experiencia en POSitron:

Una vez recolectadas todas las historias de usuario, se hizo una reunin del equipo de trabajo donde se plantearon los tiempos necesarios para su implementacin, estimaciones inusualmente los cuales resultaron de los tiempos en de

aproximadas

desarrollo en comparacin con los realmente requeridos. Finalmente desde el punto de vista del nmero de historias de usuario, se obtuvo un total de veintiuno. Considerando por un

lado la recomendacin de que no sean menos de 20 ni ms de 80.

NUMERO HISTORIA 01
NOMBRE HISTORIA FECHA ENTREVISTADO(USUARIO) TIEMPO ESTIMADO , Pago a proveedores 6 de Febrero 2007 Alirio Ramrez 6 HORAS

DESCRIPCION:

Se le cancela el dinero a un proveedor, luego se ingresa al sistema dicho pago del cual se imprime un tiquete y queda registrado para hacer parte de un resumen diario. En algunos pagos se da un descuento en porcentaje sobre el total de la factura. Se debe asociar con un cdigo de factura de compra y un proveedor

NUMERO HISTORIA 02
NOMBREHISTORIA FECHA ENTREVISTADO (USUARIO) TIEMPOESTIMADO DESCRIPCiN El cliente se acerca con los productos a la caja. El cajero ingresa cada uno de los productos. El sistema muestra el total. Elcliente paga,se calcula la devuelta y se le entrega un tiquetede venta. Se ingresan los productos por cdigo pero se acepta la posibilidad de hacerse por nombre. Si es por nombre, debe aparecer informacin complementaria a este. Estndar para el cdigo. Cadadepartamento tiene un rango de cdigos Eltiquete de venta tiene la siguiente informacin Encabezamiento, raznsocial, telfono, fecha, etc. Nombre del producto, cdigo Precio de todos los productos agrupados por cantidad (El precio de cinco bolsas de leche) Nro de artculos Total venta Pago Devuelta
'--

Venta normal 6 de Febrero 2007 Alirio Ramrez

16 HORAS

Hora al final

NUMERO HISTORIA 03 NOMBRE HISTORIA

1--

Retirar un producto de venta en curso 6 de Febrero del 2007 Alirio Rarnrez

FECHA ENTREVISTADO (USUARIO) TIEMPO ESTIMADO DESCRIPCiN

2 HORAS

En medio de una venta en proceso el cliente decide retirar un producto ya registrado de esa venta. El sistema retira el producto de la venta y se recalculan los valores necesarios. Se hace un retorno de mercanca. En el tiquete de venta se indica el producto, la cantidad y precio retornado. Debe haber dos funciones, una que retire el ltimo y otra que retire cualquier otro. Nota: el proceso debe ser muy gil.

Lo que

dkeXP:

o
Nmero de historias de usuario o tareas de programacin realizadas por iteracin.

Sirve de ayuda para estimar la cantidad de historias de usuario a implementar determinada iteracin en una

Experiencia en POSitron: El nmero de historias de usuario realizadas por iteracin no fue una buena medida de la velocidad del proyecto debido que no todas tenan el mismo nivel de dificultad y por tanto el mismo requerimiento de horas de desarrollo.

Velocidad dell'rovecto Horas Semanas Horas semanales Historias de usuario (Velocidad del proyecto) Iteracin 1 Iteracin 2 Iteracin 3 Iteracin 4 46,00 41 42 30 1 2 2 2 23 20,5 21 30

1Jivs6n en iteraciones

lo que dice XP:

El proyecto se divide en vanas iteraciones La duracin de una iteracin vara entre una y tres semanas

1Jvisfn en teraciones
Experiencia en POSitron:
El proyecto fue dividido en 4 iteraciones, por consiguiente se obtuvo un total de cuatro entregas para las cuales se desarrollaron partes de la aplicacin completamente funcionales. La primera iteracin se refiri al mdulo de POST mientras las dems iteraciones se relacionaron con la manipulacin de inventarios. En la planeacin de iteraciones se tomaron dos semanas como perodo, excepto en la ltima, la cual slo se fij para una semana, ya que se redujo la carga de obligaciones externas al proyecto.

Lo que dice XP:

Entregas funcionales del proyecto frecuentemente

Experiencia en POSitron: Debido a que las iteraciones tenan una duracin de 15 das, fue al trmino de este plazo que se realizaron entregas, las cuales siempre fueron funcionales, lo que quiere decir que al momento de la entrega estaban en condiciones de ser puestas en funcionamiento en las instalaciones del cliente. Esto represent un xito en el desarrollo del proyecto ya que mantena el inters del cliente en continuarlo debido a que estaba viendo resultados en el corto plazo.

p{an 'De 'EntregQJS

Lo que dice XP: 1. Reunin al inicio del proyecto 2. Cuales historias de usuario sern implementadas para cada entrega 3. Grado de relevancia para cada historia de usuario 4. Se aproxima el tiempo para la realizacin de cada iteracin

p{an 'De 'Entregas

Experiencia en POSitron:
1. 2. Se realizaron tres reuniones inciales. La tarea de escoger las historias fue realizada por el grupo en conjunto, incluyendo al cliente, lo cual no gener problemas en las entregas de los mdulos funcionales. La clasificacin de las historias no fue realizada estrictamente por su grado de importancia en el proyecto. Slo se opt por desarrollar el mdulo de servicio al cliente en la primera iteracin, por tratarse de la actividad ms importante en el negocio. Para aproximar el tiempo que demorara cada iteracin, se tom como medida dos semanas. Cada semana constaba de cuatro das (lunes, martes, jueves y viernes) en los que se trabajaban cuatro horas sin distracciones.

3.

4.