Informe de Prácticas Version Final

UNIVERSIDAD TECNOLGICA DE LOS ANDES
Facultad de Ingeniera
Escuela Profesional de Ingeniera de Sistemas e Informtica
INFORME PRCTICAS PRE PROFESIONALES
Implementacin de un Sistema de Inventario para la

IMPORTADORA SARITA E.I.R.L.
Autor: Edwin Batallanos Huaman
Cusco - Per
2016
SISTEMA DE CONTROL DE INVENTARIO PARA LA IMPORTADORA SARITA E.I.R.L.
INTRODUCCIN
En la actualidad, la ciudad del Cusco est experimentado
un
desarrollo
sostenible
que
es
impulsado
por
el
crecimiento econmico en sectores como la agricultura,

minera, turismo, transporte, entre otros. Estos sectores
deben su crecimiento al uso de maquinaria especializada y
vehculos de transporte de pasajeros y/o carga. Dicha
maquinaria y vehculos para prestar un servicio eficiente
y eficaz debe tener un adecuado programa de mantenimiento
y sobretodo la adquisicin de repuestos originales. En
muchos casos se opta por la contratacin de un servicio
de mantenimiento especializado, la cual resulta ser de
elevado costo, es por ello que las MYPES buscan formas de
minimizar costos, por ellos acuden a importadoras que
puedan proveerles los repuestos originales y en el menor
tiempo.
La empresa llamada IMPORTADORA SARITA E.I.R.L. es una MYPE
localizada en el distrito de San Jernimo de la ciudad y
regin de Cusco. La empresa se dedica a la importacin y
venta
de
partes,
piezas
accesorios
para
vehculos
automotores. Para su normal operacin a fin de cumplir

con su misin de la venta de autopartes, la importadora
cuenta con dos reas para cumplir con su respectiva misin
y
satisfacer
al
cliente
con
los
requerimientos
de
autopartes y/o repuestos.

La presente prctica pre-profesional se realiza en las dos
reas de la importadora. Propiamente dicho es el rea de
Ventas y el rea de Almacn, las cules respectivamente,
se encargan de la comercializacin de las autopartes
importadas y de la gestin de inventario (autopartes).
La estrategia que se plantea para cumplir con el objetivo
de la presente prctica pre-profesional, es la elaboracin
II
de un sistema de ventas que permita la integracin entre

las reas de venta y almacn, ya que actualmente ambas
reas trabajan independientemente, y a su vez que permita
cumplir con la misin y visin de la importadora.
III
INDICE
INTRODUCCION .......................................................................................................................... II
CAPTULO I ............................................................................................................................... 1
1.1 DESCRIPCIN DE LA EMPRESA ............................................................................. 2
1.2 MISIN Y VISION DE LA EMPRESA .................................................................... 2
1.3 ORGANIGRAMA DE LA EMPRESA ............................................................................. 2
1.4 DESCRIPCIN DEL PROBLEMA ................................................................................ 2
1.5 JUSTIFICACIN ECONMICA .................................................................................. 4
1.5.1 JUSTIFICACION TECNOLOGICA..................................................................... 4
1.5.2 JUSTIFICACIN ECONMICA ......................................................................... 4
1.6 OBJETIVOS DE LAS PRACTICAS PRE-PROFESIONALES ................................ 6
1.6.1 OBJETIVO GENERAL .......................................................................................... 6
1.6.2 OBJETIVOS ESPECFICOS .............................................................................. 6
CAPTULO II ............................................................................................................................ 7
2.1 TECNOLOGAS DE INFORMACIN Y COMUNICACIN: ..................................... 8
2.2 SISTEMATIZACIN ..................................................................................................... 9
2.3 GESTIN DE ALMACN ............................................................................................ 10
2.4 METODOLOGA DE PROGRAMACIN....................................................................... 13
2.5 XTREME PROGRAMING .............................................................................................. 14
2.6 SISTEMA DE GESTIN DE BASE DE DATOS (SGBD) ................................... 23
2.7 PROGRAMACIN EN 3 CAPAS ................................................................................ 29
2.8 LENGUAJE ESTRUCTURADO DE CONSULTAS (SQL) ....................................... 30
2.9 C Sharp (C#) ...................................................................................................... 31
CAPTULO III ........................................................................................................................ 32
3.1 PLANEACIN ............................................................................................................... 33
3.2 DISEO ......................................................................................................................... 44
3.3 CODIFICACIN .......................................................................................................... 50
3.4 PRUEBAS ...................................................................................................................... 53
CAPTULO IV .......................................................................................................................... 57
4.1 RESULTADOS ............................................................................................................... 58
4.2 CONCLUSIONES Y RECOMENDACIONES ............................................................... 61
IV
4.3 RECOMENDACIONES ................................................................................................... 61

BIBLIOGRAFA ........................................................................................................................ 62
ANEXOS ...................................................................................................................................... 64
A.
DIAGRAMA DE LA BASE DE DATOS .................................................................. 64
B.
HISTORIAS DE USUARIO ..................................................................................... 65
C.
CRONOGRAMA Y PRESUPUESTO ........................................................................... 76
PRESUPUESTO .................................................................................................................. 76
CRONOGRAMA ..................................................................................................................... 78
CAPTULO I
GENERALIDADES
1.1 DESCRIPCIN DE LA EMPRESA

- Razn Social de la Empresa :
IMPORTADORA
SARITA
E.I.R.L.
- Actividad Econmica
: Venta de partes, piezas
y accesorios para vehculos automotores.

- Oficina
: Mza. L Lote 5 Urb. 3 de
Mayo San Jernimo - Cusco

- Responsable de la Empresa
Haydee
Palomino
Ccorimanya Titular Gerente.

1.2 MISIN Y VISIN DE LA EMPRESA
MISIN: Brindar a nuestros clientes un servicio con
calidad
calidez
travs
de
una
atencin
personalizada, con el mejor producto a un buen precio,

en el momento oportuno.
VISIN:
Ser
la
empresa
lder
comercializadora
de
autopartes, lder en ventas en la ciudad del Cusco,

innovando la calidad de nuestro servicio, con personal
comprometido
capacitado,
respondiendo
las
con
RUC
necesidades y cambios del mercado automotriz.

1.3 ORGANIGRAMA DE LA EMPRESA
Grfico 01
Organigrama Importadora Sarita E.I.R.L.
GERENCIA GENERAL
AREA DE VENTAS
AREA DE ALMACEN
Fuente: Importadora Sarita E.I.R.L.
1.4 DESCRIPCIN DEL PROBLEMA

La empresa IMPORTADORA
SARITA
E.I.R.L
20450570541, con ms de diez aos en el mercado ubicada

en el distrito de San Jernimo de la ciudad del Cusco,
se dedica a la importacin y venta de autopartes,

piezas y accesorios para vehculos automotores.
La
empresa
en
la
actualidad
tiene
como
principal
cliente a las personas freelance1, que por motivos

econmicos no pueden recurrir a grandes distribuidores
o servicios de mantenimiento ya que el costo de los
repuestos les resulta muy costoso.
La empresa cuenta con un rea de almacn donde se hace
la recepcin del inventario importado, que est a cargo
por
el
responsable
que
realiza
la
venta,
este
inventario no es registrado en algn tipo de sistema

computarizado ms si en cuadernos que resulta tedioso
la manipulacin de estos y, por lo tanto, generalmente
no se realiza este control, aludiendo que la empresa
es pequea, que siempre se ha estado realizando los
procesos de esta manera y por tal no hay necesidad de
cambiar. Este problema de control de inventario hace
que no se lleve registro del inventario que entra y
sale
del
almacn,
no
existe
una
clasificacin
de
inventario segn tipo, uso u otro tipo de filtro que

facilite la ubicacin del mismo. Lo que trae como
principal consecuencia a la empresa, la prdida de
inventario, no saber la cantidad exacta con la que se
cuenta y tambin otra consecuencia es la aparicin de
bastante cantidad de material estancado, lo cual se
traduce en mayores costos para la empresa.
La
empresa
cuenta
con
acceso
internet
dos
computadoras, que segn las polticas de la empresa
Se denomina freelance (o trabajador autnomo, por cuenta propia o

trabajador independiente) a la persona cuya actividad consiste en
realizar trabajos propios de su ocupacin, oficio o profesin, de forma
autnoma.
1
deben servir para realizar los pedidos de inventario y

para hacer los libros contables.
1.5 JUSTIFICACIN ECONMICA
Para la elaboracin del presente trabajo se considera dos
justificaciones: Tecnolgica y la Econmica.
1.5.1 JUSTIFICACION TECNOLGICA
El desarrollo mundial que se viene produciendo es en
base al correcto uso de las TICs las cuales son una
ventaja competitiva en el mercado actual.
Est
por
empresas
dems
que
explicar
quieran
que
hoy
seguir
en
en
da
todas
competencia
las
deben
adquirir tecnologa y sobre todo darles un buen uso.

Segn
el
portal
SERVICIOS
TIC,
empresa
dedicada
proveer es tipo de servicios, las Tecnologas de la

Informacin y la Comunicacin, tambin conocidas como
TIC, son el conjunto de tecnologas desarrolladas para
gestionar informacin y enviarla de un lugar a otro.
Abarcan un abanico de soluciones muy amplio. Incluyen
las
tecnologas
para
almacenar
informacin
recuperarla despus, enviar y recibir informacin de un

sitio a otro, o procesar informacin para poder calcular
resultados y elaborar informes.
La empresa IMPORTADORA SARITA E.I.R.L cuenta con una
computadora y tambin con acceso a Internet, pero esta
no resulta una ventaja competitiva para ellos. El uso
de las TICs diferenciara a la empresa del resto de
las MYPES que se dedican a la venta de autopartes.
1.5.2 JUSTIFICACIN ECONMICA
Segn (Porta Rueda, 2011), el almacn es el local, rea
o espacio, ubicado estratgicamente y adecuadamente
donde se guardan los diferentes tipos de materiales
necesarios para la buena marcha y operatividad de la
4
organizacin.
controles
Ellos estn sujetos en este lugar a
de
inventario,
operaciones
de
ingreso,
salida, reubicacin, modificaciones de presentacin,

registros,
custodia
conservacin
transitoria
temporal, etc.
Vale decir que, para tener una ventaja competitiva y
por lo tanto mayores ingresos, nuestra clave de mejora
de los procesos debe estar en el rea de almacn.
En un mercado actual donde innovar un proceso, ya sea
por el uso de tecnologa o no, tiene como consecuencia
directa de incrementar los ingresos a la empresa. Segn
Bocanegra2
realizacin
Vzquez3
de
la
Para
la
actividad
gestin,
promocin
minorista,
el
ltimo
eslabn del proceso de distribucin ya que se encuentra

directamente vinculado al consumidor final, es el uso
de las TIC es prioritario para ser competitivo en el
mercado.
Actualmente la empresa IMPORTADORA SARITA E.I.R.L viene
sufriendo prdidas. Al no tener un control de inventario
del
que
entra
ni
del
que
sale.
La
empresa
tiene
generalmente un dficit de inventario, lo que indica

que algo est fallando en el rea de almacn
Con el uso de un sistema de inventario, estas pueden
contabilizarse y, por lo tanto, se puede tener un
control acerca de la cantidad de autopartes que entran
y salen. Lo que ahorra costos,
evita prdidas del
material y tambin se evita el pedido de materiales

innecesarios.
Carmen Bocanegra Gastelum, Profesorainvestigadora del Departamento de

Economa de la Universidad de Sonora.
3 Miguel ngel Vzquez Ruiz, Profesorinvestigador del Departamento de
Economa de la Universidad de Sonora
1.6 OBJETIVOS DE LAS PRACTICAS PRE-PROFESIONALES

El presente informe de prcticas tiene por objetivo:
1.6.1 OBJETIVO GENERAL
Implementar
un
Sistema
de
Inventario
para
la

1.6.2 OBJETIVOS ESPECFICOS
Mejorar la gestin de inventario para la IMPORTADORA
SARITA E.I.R.L.
Sistematizar los procesos de manejo de inventario
para la IMPORTADORA SARITA E.I.R.L.
CAPTULO II
MARCO TERICO
2.1 TECNOLOGAS DE INFORMACIN Y COMUNICACIN

Segn (UDEA, 2016), las Tecnologas de la Informacin
y la Comunicacin, tambin conocidas como TIC, son el
conjunto de tecnologas desarrolladas para gestionar
informacin y enviarla de un lugar a otro. Abarcan un
abanico
de
soluciones
muy
amplio.
Incluyen
las
tecnologas para almacenar informacin y recuperarla

despus, enviar y recibir informacin de un sitio a
otro,
procesar
informacin
para
poder
calcular
resultados y elaborar informes".

Las TIC nos ofrecen la posibilidad de realizar unas
funciones que facilitan nuestros trabajos tales:
Fcil acceso a todo tipo de informacin.
Instrumentos para todo tipo de proceso de datos.
Canales de comunicacin
Almacenamiento
informacin
en
de
grandes
pequeos
cantidades
soportes
de
de
fcil
transporte
Automatizacin de tareas
Interactividad
Instrumento
cognitivo
que
potencia
nuestras
capacidades mentales y permite el desarrollo de

nuevas maneras de pensar.
Grfico 02
Tecnologas de la Informacin y la Comunicacin
Fuente: (Lozano & Moreano, 2016)
2.2 SISTEMATIZACIN
Segn (Definicin, 2016) se denomina sistematizacin
al proceso por el cual se pretende ordenar una serie
de
elementos,
pasos,
etapas,
etc.,
con
el
fin
de
otorgar jerarquas a los diferentes elementos.

Las personas siempre buscan el orden. Podramos decir
incluso que todas nuestras actividades buscan un orden.
Qu tiene que ver el orden con una sistematizacin?
Bien, empecemos (claro) por el principio. Un sistema
es un objeto por el cual ordenamos una serie de
componentes,
entre
los
cuales
estn
conectados
de
alguna manera (uno con otro, o con ms de uno).

Segn (Zenteno, 2016), las empresas con las mejores
prcticas
internacionales,
se
orienten
la
sistematizacin de procesos, para mejorar la calidad

de sus productos y servicios y reducir los costos de
operacin y produccin de los mismos, lo cual eleva su
competitividad y rentabilidad.
Grfico 03
Procesos en una empresa
Fuente: (Zenteno, 2016)
Toda empresa PYME, que pretenda mantenerse competitivo

en
el
mercado,
debe
orientar
sus
esfuerzos
la
sistematizacin de procesos, para atacar de raz los

problemas
recurrentes
establecer
soluciones
definitivas y por sistema y con ello liberar a sus
directivos para que se dediquen a lo importante no

urgente, es decir a lo estratgico.
El sistematizar los procesos permite los siguientes
beneficios, entre otros:
Controlar el desempeo de los procesos que genere
la mejora de servicios y productos: Eficiencia y
Productividad, Costo y Beneficio
Asegurar
consistentemente
la
calidad
del
resultado final: una salida que cumpla con las

necesidades del cliente interno o externo y lograr
su satisfaccin y lealtad
Medir
evaluar
para
mejorar
optimizar
continuamente el funcionamiento de los procesos y

por lo tanto de los resultados de negocio
Lo que no se
mide, no se controlalo que no
se
controla, no se mejora Lo que no se mejora, no es

sustentable
Grfico 04
Documentacin de Procesos
Fuente: (Zenteno, 2016)
2.3 GESTIN DE ALMACN

Segn (Porta Rueda, 2011), es el proceso logstico que
trata la recepcin, almacenamiento y movimiento de
cualquier material dentro de un mismo almacn hasta el
punto de consumo, as como el tratamiento e informacin
de los datos generados.
10
Proceso de Gestin de Almacn

1. La Planificacin y Organizacin en la Gestin de
Almacn. ((Actividades de carcter estratgico y
Tctico).
Las actividades de planificacin y organizacin en
la Gestin de Almacenes tienen que ver con
- Diseo de la Red de Distribucin y Almacenamiento
- Ubicacin de los Almacenes
- Tamao de los Almacenes
- Modelos de organizacin fsica de los Almacenes
- Diseo y Layout de los Almacenes
2. La Direccin en la Gestin de Almacn
a. La recepcin de los materiales: Proceso de vital
importancia referido a las entradas de productos,
descarga y verificacin; del mismo depende en
buena parte la Calidad del producto final.
estrechamente
ligado
con
las
compras,
ya
Est
que
almacn debe coordinar con el rea de compras

aspectos tales como el tipo de embalaje para la
conservacin de la mercadera en el almacn, el
rotulado o bultos requeridos, fecha y horario de
recepcin, etc.
Proceso de la Recepcin
Se hace recepcin y se almacena a los productos
en buenas condiciones, firmando y sellando los
documentos en seal de conformidad
1.
Llegada del producto.
2.
Comprobacin y control.
3.
Sellado,
informe,
pruebas
Los
productos
recibidos deben ser registrados y controlados,

clasificndolos,
codificndolos
ubicndolos
dentro del almacn.
11
4.
Registro.
Se
correspondientes
al
ingresan
ingreso
los
de
documentos
mercadera
al
sistema o base de datos en forma inmediata.

5.
Etiquetado. Todos los productos recibidos son
rotulados y sus ubicaciones son colocadas en el

sistema.
b. El Almacenamiento de los materiales.
Es
el
subproceso
concerniente
la
guarda
conservacin de los productos con los mnimos

riesgos
optimizando
el
espacio
fsico.
Sus
funciones bsicas son:

- Informa a compras sobre las existencias.
- Controla y mantiene los artculos inventariados.
- Vigila que no se agotan los materiales.
c. El Movimiento de los materiales.
Es el subproceso del almacn relativo al traslado
de los materiales de una zona a otra de un mismo
almacn
desde
ubicacin
de
la
zona
de
almacenamiento
recepcin
la
Factores
considerar, para el tipo de herramienta a emplear

en el movimiento:
- Volumen del almacn.
- Volumen de los productos.
- Vida de los productos.
- Costo del equipo.
- Cantidad
de
manipulaciones
expediciones
requeridas.
- Distancia de los movimientos.
3. El control en la Gestin de Almacn (Informacin).
Su mbito se extiende a todos los procesos que se
dan en la Gestin de Almacn.
Tipos de informacin
- Informacin para Gestin
12
- Identificacin de Ubicaciones
- Visibilidad y trazabilidad de los productos
Informacin para Gestin
- Configuracin del Almacn
- Datos relativos a los medios disponibles
- Datos tcnicos de los productos almacenados
- Informes de actividades
- Evolucin de Indicadores
- Procedimientos e instrucciones de trabajo.
- Perfiles y requisitos de los puestos
- Registros de la actividad diaria
Grfico 05
Proceso de Gestin de Almacn
Fuente: (Porta Rueda, 2011)
2.4 METODOLOGA DE PROGRAMACIN

Segn (Cantone, 2006),
desarrollo
de
software
la
es
metodologa
un
modo
para
el
sistmico
de
realizar, gestionar y administrar un proyecto para

llevarlo a cabo con altas posibilidades de xito. Esta
sistematizacin nos indica como dividiremos un gran
proyecto en mdulo ms pequeos llamados etapas, y las
acciones que corresponden en cada una de ellas, nos
ayudad a definir entradas y salidas para cada una de
las etapas y, sobre todo normaliza el modo en que
administraremos el proyecto. Entonces, una metodologa
13
para el desarrollo de software son los procesos a

seguir
sistmicamente
mantener
un
para
producto
idear,
software
implementar
desde
que
surge
y
la
necesidad del producto hasta que cumplimos el objetivo

por el cual fue creado.
2.5 XTREME PROGRAMING
Segn (Joskowicz, 2008), Xtreme Programming (XP) surge
como una nueva manera de encarar proyectos de software,
proponiendo una metodologa basada esencialmente en la
simplicidad y agilidad. Las metodologas de desarrollo
de software tradicionales (ciclo de vida en cascada,
evolutivo,
en
espiral,
iterativo,
etc.)
aparecen,
comparados con los nuevos mtodos propuestos en XP,

como pesados y poco eficientes. La crtica ms frecuente
a estas metodologas clsicas es que son demasiado
burocrticas.
Hay
tanto
que
hacer
para
seguir
la
metodologa que, a veces, el ritmo entero del desarrollo

se retarda. Como respuesta a esto, se ha visto en los
ltimos
tiempos
el
surgimiento
de
Metodologas
giles. Estos nuevos mtodos buscan un punto medio

entre la ausencia de procesos y el abuso de los mismos,
proponiendo un proceso cuyo esfuerzo valga la pena.
Los mtodos giles cambian significativamente algunos
de los nfasis de las metodologas clsicas:
Los mtodos giles son adaptables en lugar de
predictivos.
Los
mtodos
clsicos
tienden
intentar planear una gran parte del proceso del

software en gran detalle para un plazo largo de
tiempo.
Esto
funciona
bien
hasta
que
las
cosas
cambian. As que su naturaleza es resistirse al

cambio. Para los mtodos giles, no obstante, el
cambio es bienvenido. Intentan ser procesos que se
adaptan y crecen en el cambio.
14
Los mtodos giles son orientados a la gente y

no
orientados
mtodos
al
proceso.
clsicos
es
El
objetivo
definir
un
de
los
proceso
que
funcionar bien independientemente de quien lo

utilice. Los mtodos giles afirman que ningn
proceso podr nunca maquillar las habilidades del
equipo de desarrollo, de modo que el papel del
proceso es apoyar al equipo de desarrollo en su
trabajo.
XP
es
una
de
las
llamadas
metodologas
giles
de
desarrollo de software ms exitosas de los tiempos

recientes. La metodologa propuesta en XP est diseada
para entregar el software que los clientes necesitan en
el
momento
en
desarrolladores
que
a
lo
necesitan.
responder
XP
alienta
los
los
requerimientos
cambiantes de los clientes, an en fases tardas del

ciclo de vida del desarrollo.
La metodologa tambin enfatiza el trabajo en equipo.
Tanto
gerentes
como
clientes
desarrolladores
son
partes del mismo equipo dedicado a entregar software de

calidad.
2.5.1 Modelo XP
La
metodologa
XP
define
cuatro
variables
para
cualquier proyecto de software: costo, tiempo, calidad

y alcance. Adems, se especifica que, de estas cuatro
variables,
slo
tres
de
arbitrariamente
por
desarrolladores
(clientes
ellas
actores
y
podrn
externos
jefes
de
ser
al
fijadas
grupo
de
proyecto).
El
valor de la variable restante podr ser establecido por

el equipo de desarrollo, en funcin de los valores de
las otras tres. Este mecanismo indica que, por ejemplo,
si el cliente establece el alcance y la calidad, y el
15
jefe de proyecto el precio, el grupo de desarrollo

tendr libertad para determinar el tiempo que durar el
proyecto.
El ciclo de vida de un proyecto XP incluye, al igual
que las otras metodologas, entender lo que el cliente
necesita, estimar el esfuerzo, crear la solucin y
entregar el producto final al cliente. Sin embargo, XP
propone un ciclo de vida dinmico, donde se admite
expresamente que, en muchos casos, los clientes no son
capaces de especificar sus requerimientos al comienzo
de un proyecto.
Por esto, se trata de realizar ciclos de desarrollo
cortos
(llamados
iteraciones),
con
entregables
funcionales al finalizar cada ciclo. En cada iteracin

se
realiza
un
ciclo
completo
de
anlisis,
diseo,
desarrollo y pruebas, pero utilizando un conjunto de

reglas y prcticas que caracterizan a XP (y que sern
detalladas ms adelante).
Tpicamente un proyecto con XP lleva 10 a 15 ciclos o
iteraciones.
La
ciclos
desarrollo
de
siguiente
figura
en
esquematiza
cascada
los
iterativos
tradicionales (por ejemplo, incremental o espiral),

comparados con el de XP.
Grfico 06
Comparacin de metodologas
Fuente: (Joskowicz, 2008)
16
2.5.2 Fases para desarrollo de XP

a) Planificacin del proyecto
Historias de usuario
El primer paso de cualquier proyecto que siga la
metodologa XP es definir las historias de usuario
con el cliente. Las historias de usuario tienen la
misma finalidad que los casos de uso, pero con algunas
diferencias: Constan de 3 4 lneas escritas por el
cliente en un lenguaje no tcnico sin hacer mucho
hincapi en los detalles; no se debe hablar ni de
posibles
algoritmos
para
su
implementacin
ni
de
diseos de base de datos adecuados, etc. Son usadas

para estimar tiempos de desarrollo de la parte de la
aplicacin que describen. Tambin se utilizan en la
fase de pruebas, para verificar si el programa cumple
con lo que especifica la historia de usuario. Cuando
llega la hora de implementar una historia de usuario,
el
cliente
los
desarrolladores
se
renen
para
concretar y detallar lo que tiene que hacer dicha

historia. El tiempo de desarrollo ideal para una
historia de usuario es entre 1 y 3 semanas.
Las
Historias
sustituyen
de
los
usuarios
documentos
(User
de
stories)
especificacin
funcional, y a los casos de uso. Estas historias

son escritas por el cliente, en su propio lenguaje,
como descripciones cortas de lo que el sistema debe
realizar. La diferencia ms importante entre estas
historias
los
tradicionales
documentos
de
especificacin funcional se encuentra en el nivel de

detalle requerido. Las historias de usuario deben
tener
el
detalle
mnimo
como
para
que
los
programadores puedan realizar una estimacin poco

17
riesgosa del tiempo que llevar su desarrollo. Cuando

llegue
el
momento
desarrolladores
de
la
dialogarn
implementacin,
directamente
los
con
el
cliente para obtener todos los detalles necesarios.

Release Planning
Despus de tener ya definidas las historias de usuario
es necesario crear un plan de publicaciones, en ingls
"Release plan", donde se indiquen las historias de
usuario que se crearn para cada versin del programa
y las fechas en las que se publicarn estas versiones.
Un "Release plan" es una planificacin donde los
desarrolladores y clientes establecen los tiempos de
implementacin ideales de las historias de usuario,
la prioridad con la que sern implementadas y las
historias que sern implementadas en cada versin del
programa. Despus de un "Release plan" tienen que
estar claros estos cuatro factores: los objetivos que
se
deben
cumplir
(que
son
principalmente
las
historias que se deben desarrollar en cada versin),

el tiempo que tardarn en desarrollarse y publicarse
las versiones del programa, el nmero de personas que
trabajarn en el desarrollo y cmo se evaluar la
calidad
del
trabajo
realizado.
(*Release
plan:
Planificacin de publicaciones).
Iteraciones
Todo proyecto que siga la metodologa X.P. se ha de
dividir en iteraciones de aproximadamente 3 semanas
de
duracin.
Al
comienzo
de
cada
iteracin
los
clientes deben seleccionar las historias de usuario

definidas
en
el
"Release
planning"
que
sern
implementadas. Tambin se seleccionan las historias

de usuario que no pasaron el test de aceptacin que
18
se realiz al terminar la iteracin anterior. Estas

historias de usuario son divididas en tareas de entre
1
das
de
duracin
que
se
asignarn
los
programadores.
La Velocidad del Proyecto
Es una medida que representa la rapidez con la que se
desarrolla el proyecto; estimarla es muy sencillo,
basta con contar el nmero de historias de usuario
que se pueden implementar en una iteracin; de esta
forma, se sabr el cupo de historias que se pueden
desarrollar en las distintas iteraciones. Usando la
velocidad del proyecto controlaremos que todas las
tareas se puedan desarrollar en el tiempo del que
dispone la iteracin. Es conveniente reevaluar esta
medida cada 3 4 iteraciones y si se aprecia que no
es adecuada hay que negociar con el cliente un nuevo
"Release Plan".
Programacin en Parejas
La
metodologa
X.P.
aconseja
la
programacin
en
parejas pues incrementa la productividad y la calidad

del software desarrollado.
El trabajo en pareja involucra a dos programadores
trabajando en el mismo equipo; mientras uno codifica
haciendo hincapi en la calidad de la funcin o mtodo
que est implementando, el otro analiza si ese mtodo
o funcin es adecuado y est bien diseado. De esta
forma se consigue un cdigo y diseo con gran calidad.
Reuniones Diarias
Es
necesario
que
los
desarrolladores
se
renan
diariamente y expongan sus problemas, soluciones e
19
ideas de forma conjunta. Las reuniones tienen que ser

fluidas y todo el mundo tiene que tener voz y voto.
b) Diseo
Diseos Simples
La
metodologa
XP
sugiere
que
hay
que
conseguir
diseos simples y sencillos.

Hay que procurar hacerlo todo lo menos complicado
posible
para
conseguir
un
diseo
fcilmente
entendible e implementable que a la larga costar

menos tiempo y esfuerzo desarrollar.
Glosarios de Trminos
Usar
glosarios
de
trminos
una
correcta
especificacin de los nombres de mtodos y clases

ayudar
comprender
posteriores
el
ampliaciones
diseo
y
la
facilitar
sus
reutilizacin
del
cdigo.
Riesgos
Si surgen problemas potenciales durante el diseo, XP
sugiere utilizar una pareja de desarrolladores para
que investiguen y reduzcan al mximo el riesgo que
supone ese problema.
Funcionabilidad extra
Nunca se debe aadir funcionalidad extra al programa,
aunque se piense que en un futuro ser utilizada.
Slo el 10% de la misma es utilizada, lo que implica
que
el
desarrollo
de
funcionalidad
extra
es
un
desperdicio de tiempo y recursos.

Refactorizar
Refactorizar es mejorar y modificar la estructura y
codificacin de cdigos ya creados sin alterar su
20
funcionalidad. Refactorizar supone revisar de nuevo

estos
cdigos
funcionamiento.
para
Es
muy
procurar
comn
optimizar
rehusar
cdigos
su
ya
creados que contienen funcionalidades que no sern

usadas y diseos obsoletos.
c) Codificacin
Como ya se dijo en la introduccin, el cliente es una
parte ms del equipo de desarrollo; su presencia es
indispensable en las distintas fases de XP. A la hora
de codificar una historia de usuario su presencia es
an ms necesaria. No olvidemos que los clientes son
los que crean las historias de usuario y negocian los
tiempos en los que sern implementadas. Antes del
desarrollo de cada historia de usuario el cliente
debe especificar detalladamente lo que sta har y
tambin tendr que estar presente cuando se realicen
los test que verifiquen que la historia implementada
cumple la funcionalidad especificada. La codificacin
debe hacerse ateniendo a estndares de codificacin
ya creados. Programar bajo estndares mantiene el
cdigo
consistente
facilita
su
comprensin
escalabilidad.
d) Pruebas
Uno de los pilares de la metodologa XP es el uso de
test para comprobar el funcionamiento de los cdigos
que vayamos implementando. El uso de los test en XP
es el siguiente:
Se deben crear las aplicaciones que realizarn los
test con un entorno de desarrollo especfico para
test.
21
Hay que someter a test las distintas clases del

sistema omitiendo los mtodos ms triviales.
Se deben crear los test que pasarn los cdigos
antes de implementarlos; en el apartado anterior
se explic la importancia de crear antes los test
que el cdigo.
Un punto importante es crear test que no tengan
ninguna dependencia del cdigo que en un futuro
evaluar.
Como se coment anteriormente los distintos test
se deben subir al repositorio de cdigo acompaados
del cdigo que verifican.
Test
de
aceptacin.
Los
test
mencionados
anteriormente sirven para evaluar las distintas

tareas en las que ha sido dividida una historia de
usuario.
Al ser las distintas funcionalidades de nuestra
aplicacin no demasiado extensas, no se harn test
que analicen partes de las mismas, sino que las
pruebas
se
realizarn
para
las
funcionalidades
generales que debe cumplir el programa especificado

en la descripcin de requisitos.
Grfico 07
Fases de la Metodologa XP
Fuente: (Joskowicz, 2008)
22
2.5.3 Ventajas y Desventajas

Ventajas:
- Programacin organizada.
- Menor taza de errores.
- Satisfaccin del programador.
Desventajas:
- Es recomendable emplearlo solo en proyectos a corto
plazo.
- Altas comisiones en caso de fallar.
2.6 SISTEMA DE GESTIN DE BASE DE DATOS (SGBD)
Segn (Prez Valds, 2007), los Sistemas de Gestin de
Base de Datos (en ingls DataBase Management System)
son un tipo de software muy especfico, dedicado a
servir de interfaz entre la base de datos, el usuario
y las aplicaciones que la utilizan. Se compone de un
lenguaje de definicin de datos, de un lenguaje de
manipulacin de datos y de un lenguaje de consulta.
Ventajas de las bases de datos
Control sobre la redundancia de datos:
Los sistemas de ficheros almacenan varias copias
de los mismos datos en ficheros distintos. Esto
hace que se desperdicie espacio de almacenamiento,
adems de provocar la falta de consistencia de
datos.
En los sistemas de bases de datos todos estos
ficheros
estn
integrados,
por
lo
que
no
se
almacenan varias copias de los mismos datos. Sin

embargo, en una base de datos no se puede eliminar
la redundancia completamente, ya que en ocasiones
es necesaria para modelar las relaciones entre los
datos.
23
Consistencia de datos:
Eliminando o controlando las redundancias de datos
se reduce en gran medida el riesgo de que haya
inconsistencias. Si un dato est almacenado una
sola vez, cualquier actualizacin se debe realizar
slo una vez, y est disponible para todos los
usuarios inmediatamente. Si un dato est duplicado
y el sistema conoce esta redundancia, el propio
sistema puede encargarse de garantizar que todas
las copias se mantienen consistentes.
Compartir datos:
En
los
sistemas
de
ficheros,
los
ficheros
pertenecen a las personas o a los departamentos

que los utilizan. Pero en los sistemas de bases de
datos, la base de datos pertenece a la empresa y
puede ser compartida por todos los usuarios que
estn autorizados.
Mantenimiento de estndares:
Gracias a la integracin es ms fcil respetar los
estndares necesarios, tanto los establecidos a
nivel
de
la
empresa
internacionales.
como
Estos
los
nacionales
estndares
pueden
establecerse sobre el formato de los datos para

facilitar su intercambio, pueden ser estndares de
documentacin, procedimientos de actualizacin y
tambin reglas de acceso.
Mejora en la integridad de datos:
La integridad de la base de datos se refiere a la
validez
la
consistencia
de
los
datos
almacenados. Normalmente, la integridad se expresa

mediante restricciones o reglas que no se pueden
violar.
Estas
restricciones
se
pueden
aplicar
24
tanto a los datos, como a sus relaciones, y es el

SGBD quien se debe encargar de mantenerlas.
Mejora en la seguridad:
La seguridad de la base de datos es la proteccin
de
la
base
de
datos
frente
usuarios
no
autorizados. Sin unas buenas medidas de seguridad,

la integracin de datos en los sistemas de bases
de datos hace que stos sean ms vulnerables que
en los sistemas de ficheros.
Mejora en la accesibilidad a los datos:
Muchos SGBD proporcionan lenguajes de consultas o
generadores de informes que permiten al usuario
hacer cualquier tipo de consulta sobre los datos,
sin que sea necesario que un programador escriba
una aplicacin que realice tal tarea.
Mejora en la productividad:
El
SGBD
proporciona
muchas
de
las
funciones
estndar que el programador necesita escribir en

un sistema de ficheros. A nivel bsico, el SGBD
proporciona
todas
las
rutinas
de
manejo
de
ficheros tpicas de los programas de aplicacin.

El hecho de disponer de estas funciones permite al
programador
centrarse
mejor
en
la
funcin
especfica requerida por los usuarios, sin tener

que preocuparse de los detalles de implementacin
de bajo nivel.
Mejora en el mantenimiento:
En los sistemas de ficheros, las descripciones de
los datos se encuentran inmersas en los programas
de aplicacin que los manejan.
Esto hace que los programas sean dependientes de
los datos, de modo que un cambio en su estructura,
o un cambio en el modo en que se almacena en disco,
25
requiere
cambios
importantes
en
los
programas
cuyos datos se ven afectados.

Sin embargo, los SGBD separan las descripciones de
los datos de las aplicaciones. Esto es lo que se
conoce como independencia de datos, gracias a la
cual
se
simplifica
el
mantenimiento
de
las
aplicaciones que acceden a la base de datos.

Aumento de la concurrencia:
En algunos sistemas de ficheros, si hay varios
usuarios que pueden acceder simultneamente a un
mismo fichero, es posible que el acceso interfiera
entre ellos de modo que se pierda informacin o se
pierda
la
integridad.
La
mayora
de
los
SGBD
gestionan el acceso concurrente a la base de datos

y garantizan que no ocurran problemas de este tipo.
Mejora en los servicios de copias de seguridad:
Muchos
sistemas
de
ficheros
dejan
que
sea
el
usuario quien proporcione las medidas necesarias

para proteger los datos ante fallos en el sistema
o en las aplicaciones. Los usuarios tienen que
hacer copias de seguridad cada da, y si se produce
algn
fallo,
utilizar
estas
copias
para
restaurarlos.
En este caso, todo el trabajo realizado sobre los
datos
desde
seguridad
se
que
se
pierde
hizo
la
tiene
se
ltima
que
copia
volver
de
a
realizar. Sin embargo, los SGBD actuales funcionan

de modo que se minimiza la cantidad de trabajo
perdido cuando se produce un fallo.
26
Desventajas de las bases de datos

Complejidad:
Los SGBD son conjuntos de programas que pueden
llegar a ser complejos con una gran funcionalidad.
Es preciso comprender muy bien esta funcionalidad
para poder realizar un buen uso de ellos.
Coste del equipamiento adicional:
Tanto el SGBD, como la propia base de datos, pueden
hacer que sea necesario adquirir ms espacio de
almacenamiento.
prestaciones
Adems,
deseadas,
para
es
alcanzar
posible
que
las
sea
necesario adquirir una mquina ms grande o una

mquina que se dedique solamente al SGBD. Todo
esto har que la implantacin de un sistema de
bases de datos sea ms cara.
Vulnerable a los fallos:
El hecho de que todo est centralizado en el SGBD
hace que el sistema sea ms vulnerable ante los
fallos que puedan producirse. Es por ello que deben
tenerse copias de seguridad (Backup).
Tipos de Campos
Cada Sistema de Base de Datos posee tipos de campos que
pueden ser similares o diferentes. Entre los ms comunes
podemos nombrar:
Numrico: entre los diferentes tipos de campos
numricos
podemos
encontrar
enteros
sin
decimales y reales decimales.

Booleanos: poseen dos estados: Verdadero Si y
Falso No.
Memos:
son
campos
alfanumricos
de
longitud
ilimitada. Presentan el inconveniente de no poder

ser indexados.
27
Fechas:
almacenan
fechas
facilitando
posteriormente su explotacin. Almacenar fechas de

esta forma posibilita ordenar los registros por
fechas o calcular los das entre una fecha y otra.
Alfanumricos:
contienen
cifras
letras.
Presentan una longitud limitada (255 caracteres).

Autoincrementables: son campos numricos enteros
que incrementan en una unidad su valor para cada
registro incorporado. Su utilidad resulta: Servir
de identificador ya que resultan exclusivos de un
registro.
Modelo entidad-relacin
Los diagramas o modelos entidad-relacin (denominado
por sus siglas, ERD Diagram Entity relationship) son
una herramienta para el modelado de datos de un sistema
de
informacin.
Estos
modelos
expresan
entidades
relevantes para un sistema de informacin, sus interrelaciones y propiedades.

Grfico 8
Modelo Entidad Relacin
Fuente: (Prez Valds, 2007)
Cardinalidad de las Relaciones

El diseo de relaciones entre las tablas de una base de
datos puede ser la siguiente:
28
Relaciones de uno a uno: una instancia de la

entidad A se relaciona con una y solamente una de
la entidad B.
Relaciones de uno a muchos: cada instancia de la
entidad A se relaciona con varias instancias de la
entidad B.
Relaciones de muchos a muchos: cualquier instancia
de
la
entidad
se
relaciona
con
cualquier
instancia de la entidad B.
2.7 PROGRAMACIN EN 3 CAPAS
Segn (Garca, 2009), la programacin por capas es un
estilo de programacin en el que el objetivo primordial
es la separacin de la lgica de negocios de la lgica
de
diseo;
un
ejemplo
bsico
de
esto
consiste
en
separar la capa de datos de la capa de presentacin al

usuario.
1.- Capa de presentacin: es la que ve el usuario
(tambin se la denomina "capa de usuario"), presenta
el sistema al usuario, le comunica la informacin y
captura la informacin del usuario en un mnimo de
proceso (realiza un filtrado previo para comprobar que
no hay errores de formato). Esta capa se comunica
nicamente con la capa de negocio. Tambin es conocida
como interfaz grfica y debe tener la caracterstica
de ser "amigable" (entendible y fcil de usar) para el
usuario.
2.- Capa de negocio: es donde residen los programas que
se ejecutan, se reciben las peticiones del usuario y
se envan las respuestas tras el proceso. Se denomina
capa de negocio (e incluso de lgica del negocio)
porque es aqu donde se establecen todas las reglas que
deben cumplirse. Esta capa se comunica con la capa de
presentacin, para recibir las solicitudes y presentar
29
los resultados, y con la capa de datos, para solicitar

al gestor de base de datos para almacenar o recuperar
datos de l. Tambin se consideran aqu los programas
de aplicacin.
3.- Capa de datos: es donde residen los datos y es la
encargada de acceder a los mismos. Est formada por uno
o ms gestores de bases de datos que realizan todo el
almacenamiento
de
datos,
reciben
solicitudes
de
almacenamiento o recuperacin de informacin desde la

capa de negocio.
Grfico 09
Arquitectura 3 Capas
Fuente: (Garca, 2009)
2.8 LENGUAJE ESTRUCTURADO DE CONSULTAS (SQL)

Segn (Prez Valds, 2007), el lenguaje de consulta
estructurado (SQL) es un lenguaje de base de datos
normalizado, utilizado por el motor de base de datos
de Microsoft Jet. SQL se utiliza para crear objetos
QueryDef,
como
el
argumento
de
origen
del
mtodo
OpenRecordSet y como la propiedad RecordSource del

control de datos. Tambin se puede utilizar con el
mtodo Execute para crear y manipular directamente las
bases de datos Jet y crear consultas SQL de paso a
travs para manipular bases de datos remotas cliente
servidor.
30
4.8.1 Componentes de SQL

El Lenguaje SQL est compuesto por comandos, clusulas,
operadores y funciones de agregado. Estos elementos se
combinan en las instrucciones para crear, actualizar y
manipular las bases de datos.
2.9 C Sharp (C#)
Segn (Wikipedia, 2016), C# (pronunciado si sharp en
ingls) es un lenguaje de programacin orientado a
objetos desarrollado y estandarizado por Microsoft como
parte de su plataforma .NET, que despus fue aprobado
como un estndar por la ECMA (ECMA-334) e ISO (ISO/IEC
23270). C# es uno de los lenguajes de programacin
diseados para la infraestructura de lenguaje comn.
Su sintaxis bsica deriva de C/C++ y utiliza el modelo
de objetos de la plataforma .NET, similar al de Java,
aunque incluye mejoras derivadas de otros lenguajes.
El
nombre
Sharp
fue
inspirado
por
la
notacin
musical, donde '#' (sostenido, en ingls sharp) indica

que la nota (C es la nota do en ingls) es un semitono
ms
alto,
sugiriendo
que
C#
es
superior
C/C++.
Adems, el signo '#' se compone de cuatro signos '+'

pegados.2
Aunque C# forma parte de la plataforma .NET, sta es
una API, mientras que C# es un lenguaje de programacin
independiente diseado para generar programas sobre
dicha plataforma. Ya existe un compilador implementado
que provee el marco Mono - DotGNU, el cual genera
programas
para
distintas
plataformas
como
Windows,
Unix, Android, iOS, Windows Phone, Mac OS y GNU/Linux.
31
CAPTULO III
METODOLOGA
3.1 PLANEACIN
A partir de esta seccin se describe la experiencia
obtenida en la realizacin del proyecto. Inicialmente
se comenta sobre cada uno de los aspectos que XP propone
para
etapa
elementos
de
se
planeacin.
enuncia
lo
Para
que
la
cada
uno
teora
de
sobre
los
XP
recomienda contrastndola con la experiencia real en

la realizacin del proyecto.
Entre los elementos a
discutir para esta seccin se encuentran las historias

de usuario, el plan de entregas, lo relacionado con las
iteraciones como las modificaciones que se aplicaron a
XP para hacerla ms adecuada para el proyecto.
En esta seccin se encontrar la misma estructura de
la seccin de planeacin del marco terico. Para cada
apartado se ver una serie de ideas que resumen la
teora contrastada con la interpretacin, aplicacin y
resultados en la prctica.
3.1.1
HISTORIAS DE USUARIO
Lo que dice XP:

- Escritas por el usuario.
- Terminologa del cliente.
- Bajo nivel de detalle.
- Sirve de base para estimar los tiempos de
implementacin
- No deben ser menos de 20 ni ms de 80
Experiencia Importadora Sarita
Si bien el cliente no fue quien escribi personalmente
las
historias
de
usuario,
fue
quien
dise
su
contenido y dirigi la redaccin de las mismas, debido

a que no tena los conocimientos necesarios en formato
para elaborarlas. A pesar de lo anterior, el propsito
de las mismas no se vio alterado de alguna forma,
manteniendo no solamente la terminologa del cliente al
33
punto en que este fuera autosuficiente en la comprensin

de su contenido, sino tambin su oficio como punto de
partida en la planificacin del proyecto.
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. Sin embargo, se logr abstraer
la informacin suficiente de ellas para realizar su
implementacin sin requerir demasiadas aclaraciones por
parte del cliente, siendo factor fundamental para no
ocasionar retrasos motivados por falta de claridad en
los requerimientos.
Por otro lado, es muy importante resaltar el papel
fundamental que jugaron las historias de usuario en la
estimacin de los tiempos requeridos para el desarrollo
del proyecto. 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, los cuales resultaron en estimaciones
inusualmente aproximadas de los tiempos de desarrollo
en comparacin con los realmente requeridos. Esto es
importante resaltarlo debido al poco nivel de detalle
que las historias de usuario tenan, significando la
poca informacin sobre las implicaciones tcnicas de su
implementacin.
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, y por el otro que el
tamao del proyecto fue pequeo en comparacin a otros
sistemas de control de inventario; se deduce que en
nmero es muy adecuado y por consiguiente el nivel de
agrupacin de tareas que cada historia de usuario tena.
34
3.1.2
VELOCIDAD DEL PROYECTO
Lo que dice XP:

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

- Sirve
de
historias
ayuda
de
para
usuario
estimar
a
la
cantidad
implementar
en
de
una
determinada iteracin.
Experiencia en Importadora Sarita
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. Por esto se encontr que mientras en
la
segunda
iteracin
se
trabajaron
menos
horas
semanales en comparacin con las dems, tambin fue

donde ms historias de usuario se evacuaron, lo que
supondra un nivel de rendimiento muy superior, lo
que no es cierto. El motivo de este resultado fue que
el nivel de dificultad y, por lo tanto, el nmero de
horas requeridas para las historias de usuario de la
segunda iteracin fue el ms bajo de todo el proyecto.
Tabla 01
Velocidad del Proyecto
1
Horas
15
30
30
30
30
45
45
30
Semanas
15
15
15
15
15
15
15
15
Horas
Semanales
Historias
de
Usuario
Fuente:
Elaboracin
propia
(Sistema
Control
de
Inventario)
35
Si bien esta medida de velocidad del proyecto fue

tenida en cuenta para el anlisis de tiempos, result
de mayor utilidad estimar el nmero de horas que
tomara
implementar
cada
historia
de
usuario
planificar las entregas acordes con esta medida. De

esta
forma,
al
tener
la
disponibilidad
de
cada
desarrollador en horas por semana, se pudo estimar

con
mucha
precisin
cuntas
historias
de
usuario
podan ser asignadas en iteracin. Esta medida de la

velocidad
del
proyecto
result
tan
acertada
que
permiti realizar un plan de entregas preciso, y lo

ms importante, cumplirlo. De esta forma se planearon
cuatro
entregas
las
cuales
se
realizaron
sin
necesidad de solicitud de aplazamientos o trabajar

horas
extras.
present
con
Una
la
dificultad
velocidad
inesperada
del
proyecto
que
se
fue
el
refactoring, En la tercera iteracin surgieron varias

recomendaciones
por
parte
del
cliente
que
se
convirtieron en refactoring, el cual no se haba

considerado dentro de ninguna de las dos medidas de
velocidad.
Producto
de
esta
omisin
el
grupo
de
desarrollo debi reestimar el tiempo dedicado a la

iteracin para no tener que remover historias de
usuario de esta. Finalmente, la contingencia fue bien
administrada por el grupo y se pudo cumplir con las
metas de la iteracin sin necesidad de trabajar ms
horas de las planeadas.
3.1.3
DIVISIN EN OPERACIONES
Lo que dice XP:

- El proyecto se divide en varias iteraciones.
- La duracin de una iteracin vara entre una y
tres semanas.
36
El proyecto fue dividido en nueve iteraciones, por

consiguiente, se obtuvo un total de nueve entregas
para las cuales se desarrollaron partes de la
aplicacin completamente funcionales. La primera
iteracin
se
refiri
al
mdulo
de
Categoras
mientras las dems iteraciones se relacionaron con

la manipulacin de inventarios y venta. Este orden
se eligi debido a la naturaleza del negocio del
cliente y la importancia que tiene para l la
prestacin del servicio a la comunidad.
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. La
estimacin de las dos semanas para una iteracin
fue correcta, se cumplieron a cabalidad dichos
plazos
se
decir,
sin
realizaron
posponer
entregas
historias
completas,
para
es
posteriores
iteraciones. En la ltima iteracin tambin se

demostr que la decisin de trabajar en una semana
fue la ms adecuada, debido que se increment el
ritmo de trabajo en dicha semana.
Aunque las entregas fueron planeadas con fechas
para su realizacin y la mayora se cumplieron para
dichas fechas, la reunin para la ltima entrega
no se pudo realizar el da que se tena planeado,
no por razones de retraso en la implementacin de
la aplicacin sino debido a la disponibilidad del
cliente. El distanciamiento del cliente con el
proyecto ocasion una paralizacin irremediable
del mismo mientras poda volver a participar, lo
cual evidenci una peligrosa dependencia con el
cliente.
37
3.1.4
ENTREGAS PEQUEAS
Lo que dice XP:

- Entregas
funcionales
del
proyecto
frecuentemente.
Debido a que las iteraciones tenan una duracin de
15
das,
fue
realizaron
al
trmino
entregas,
las
de
este
cuales
plazo
siempre
que
se
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.
Para las entregas se fijaron las siguientes fechas:
Tabla 2
Cronograma Iteraciones
ITERACIN
FECHA
DURACIN
PRIMERA
09/04/2016
50 minutos
SEGUNDA
23/04/2016
50 minutos
TERCERA
07/05/2016
50 minutos
CUARTA
21/05/2016
50 minutos
QUINTA
04/06/2016
50 minutos
SEXTA
25/06/2016
50 minutos
SPTIMA
16/07/2016
50 minutos
OCTAVA
30/07/2016
50 minutos
Fuente: Elaboracin propia (Sistema Control de Inventario)
38
Cada una de las reuniones se dividi en dos partes.

Por un lado, se hizo la entrega y familiarizacin de
las
funcionalidades
acordadas,
con
la
respectiva
aprobacin del cliente o sus recomendaciones para

refactoring. Al final de la reunin, en un periodo no
superior a 20 minutos, se confirm cules seran las
historias de usuario a implementar para la siguiente
iteracin y la fecha exacta de la prxima reunin.
3.1.5
PLAN DE ENTREGAS
Lo que dice XP:

- Reunin al inicio del proyecto.
- Cuales historias de usuario sern implementadas
para cada entrega.
- Grado
de
relevancia
para
cada
historia
de
usuario.
- Se aproxima el tiempo para la realizacin de
cada iteracin
Se realizaron tres reuniones iniciales. En la primera
reunin, se grab en audio las historias de usuario
que el representante del cliente expuso. Para la
segunda reunin se contact al segundo representante,
el cual complement las historias que el primero
redact, y agreg algunas ms. La tercera reunin se
realiz para que el primer cliente confirmara que las
historias de usuario que se crearon en la primera y
segunda reunin cubran todos los requerimientos,
adems de profundizar en las definiciones de las
historias.
La realizacin de dichas reuniones retras en varios
das el desarrollo del proyecto, al no ser necesarias
ms de dos reuniones. Con el trabajo realizado en la
39
primera y segunda reunin habra sido suficiente para

continuar con el proyecto, ya que en estas reuniones
los clientes expusieron la totalidad de las historias
de usuario. Debido a la claridad de las historias de
usuario, la ltima reunin fue considerada intil
adems de no ser recomendada por XP.
Aunque XP propone que el cliente sea quien decida
cules historias se implementarn y cul es el grado
de importancia de cada una en la correspondiente
iteracin, 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

PRODUCTO en la primera iteracin, por tratarse de la
actividad ms importante en el negocio. En las dems
iteraciones
se
prioriz
la
dependencia
con
los
mdulos ya implementados.
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.
Esta
decisin
fue
acogida
por
el
equipo debido a obligaciones externas al proyecto.

3.1.6
REUNION INICIAL DE ITERACION
Lo que dice XP:

- Las
historias
son
traducidas
tareas
al
comienzo de cada iteracin.

- Se estiman los tiempos para la realizacin de
tareas en das ideales.
40

En la reunin que realizaba el equipo de trabajo, se
transformaba el contenido de las historias de usuario
en responsabilidades que eran plasmadas en las CRC,
para luego proceder a la programacin de dicha tarea.
Esta traduccin facilit la creacin de clases y
mtodos iniciales de las mismas, ya que fue la etapa
de
diseo
del
proyecto.
Esta
etapa
siempre
fue
realizada en conjunto por ambos miembros del equipo

de desarrollo, lo que supone una pequea modificacin
a XP, en el sentido que no plantea el diseo en esta
reunin. Las tareas fueron cuidadosamente estimadas
en horas, no en das, lo cual aport ms precisin al
momento de calcular las historias a implementar (lo
que se plantea en la velocidad de proyecto). En dichas
estimaciones no se tom en cuenta el tiempo que se
necesita para el refactoring, lo que se considera una
omisin, sin embargo, cuando se requiri, se les pudo
hacer gestin sin afectar al proyecto. Al elegir las
historias de usuario, se trat de igualar el nmero
de horas trabajadas en la anterior iteracin, sin
embargo, en la primera se realiz un estimativo que
result muy conveniente, lo que evit el retraso en
la realizacin de las historias a implementarse.
3.1.7
REUNIN MATINAL
Lo que dice XP:

- La realizacin de una reunin al comenzar el da
laboral.
- Esta reunin se realizar en el sitio de trabajo
del equipo.
- Evitar discusiones largas.
41

El beneficio que se desea obtener con esta prctica
es la facilitacin del proceso de comunicacin del
equipo. Debido al entorno de trabajo, en el cual no
se
contaba
desarrollo
implementado
con
un
del
proyecto,
sitio
fsico,
para
este
aspecto
cabalidad.
Se
el
normal
no
recurri
fue
a
la
utilizacin de la comunicacin por celular e internet

para
apoyar
la
comunicacin
del
equipo,
lo
cual
result ser una excelente estrategia como solucin al

alejamiento de los puestos de trabajo y reemplazo de
la reunin matinal. La comunicacin de problemas y
soluciones se realiz a lo largo de la jornada de
trabajo, ya que se contaba con la permanencia en la
red durante la mayor parte del da, adems de las
consultas telefnicas, y las que se realizaba antes
o despus de las clases de la universidad.
Las discusiones que surgieron no fueron muy largas.
Los problemas que se plantearon no demandaron mucho
tiempo para encontrar su solucin, debido a que eran
dudas relacionadas con la codificacin.
3.1.8
MOVER PERSONAL
Lo que dice XP:

- Cada persona en un equipo debe conocer mucho del
cdigo de cada seccin del proyecto.
- Rotar
los
programadores
en
partes
del
desarrollo.
El objetivo de implementar cada rea fue fcil de
lograr para el proyecto, debido a que por un lado el
practicante tena los conocimientos necesarios y por
el otro que el tamao del proyecto as lo permiti.
42
Para el proyecto se presentaron dos temas que debieron

ser tratados de forma especial para evitar islas de
conocimiento. El primero fue la compra de inventario,
con la cual se implementaron las pruebas y el segundo
se trat de las ventas o salidas de inventario ya que
algunas ordenes quedaban abiertas. En ambos casos se
encarg la realizacin de Spike Solution, el cual al
finalizar ste, se obtuvo el conocimiento necesario
para la implementacin de los mdulos.
Al
trabajar
con
el
personal
encargado
de
la
importadora, y sobre todo gracias a la comunicacin

efectiva y la buena relacin interpersonal se logr
el objetivo de evitar las islas de conocimiento y los
cuellos de botella.
3.1.9
MODIFICAR XP CUANDO SEA NECESARIO
Lo que dice XP:

- Corrija las reglas de XP cuando estas fallen.
- Las reglas solo se cambian cuando el equipo lo
apruebe en conjunto.
La principal fuente de modificaciones al proyecto,
surgi del hecho que este fue desarrollado en un
ambiente
acadmico
slo
se
involucr
un
programador, modificando las siguientes normas.

Jornada laboral: se adapt a las obligaciones de los
dos integrantes en el sentido de flexibilizar el
nmero de horas dedicadas al proyecto semanalmente de
acuerdo con las obligaciones acadmicas.
Cliente en sitio: se ajust la participacin del
cliente
en
el
proyecto
permitindole
no
estar
permanentemente en el sitio de trabajo, debido a su
43
disponibilidad, compensando esto con una comunicacin

telefnica permanente.
En general, los cambios que se hicieron a XP fueron
acertados y facilitaron la culminacin exitosa del
mismo; sin embargo, lo ms importante no fue tomar la
decisin de hacerlos, si no la formalizacin de los
mismos. De no haberse tenido un procedimiento para
ajustar a XP en el transcurso del proyecto, se habra
diluido la filosofa de la programacin extrema y al
final no se podra haber dicho que se aplic XP al
proyecto.
3.2 DISEO
A diferencia de las metodologas pesadas, el diseo se
realiza durante todo el tiempo de vida del proyecto,
siendo
constantemente
revisado
muy
probablemente
modificado debido a cambios presentados durante el

desarrollo.
Tal como se present en la seccin 5.1, este captulo
presenta una estructura similar a la seccin de diseo
del marco terico donde se observar para cada uno de
los elementos constitutivos de dicha etapa una serie
de ideas que describen la teora contrastada con lo
vivenciado durante la ejecucin del proyecto.
Entre los elementos ms importantes que menciona XP
referentes al diseo est la simplicidad, las tarjetas
CRC, el refactoring y Spike Solution. A continuacin,
se detalla la experiencia vivida con cada uno de ellos.
3.2.1 SIMPLICIDAD
Lo que dice XP:
- El diseo debe ser sencillo.
- Slo se crearn diagramas tiles.
44

En lo que respecta a la sencillez del diseo, se acogi
la recomendacin de XP, slo invirtiendo el tiempo
exclusivamente necesario en elaboracin de diagramas
y diseo de interfaz grfica. A consecuencia de esta
decisin se debieron hacer algunos sacrificios. Al no
haber hecho muchos diagramas, la orientacin a objetos
no
fue
tan
completa,
sacrificando
de
esta
forma
escalabilidad, versatilidad y elegancia del diseo, lo

que fue considerado un precio justo a cambio del
cumplimiento de los plazos. Desde el punto de vista de
las interfaces, tampoco se invirti mucho tiempo en su
diseo, sin embargo, se prest mucha atencin a ubicar
los
elementos
tal
como
el
cliente
las
haba
solicitado y presentndolos en una forma elegante pero

sencilla. A consecuencia de esto se not una reaccin
muy positiva del cliente, manifestando conformidad con
la apariencia visual de la aplicacin. Es importante
aclarar
que
estos
sacrificios
en
ningn
momento
representaron una baja en la calidad de la aplicacin

en cuanto a la funcionalidad se refiere.
En lo que se refiere a los diagramas, se crearon las
tarjetas CRC, algunos diagramas de secuencia y el
modelo Entidad Relacin, del cual surgieron varias
versiones
en
la
medida
que
se
incorporaban
funcionalidades a la aplicacin. Si bien no fueron

muchos
diagramas,
si
fueron
muy
tiles
se
convirtieron en la columna vertebral del desarrollo.

Todos estos diagramas fueron elaborados a mano y sin
prestar mucha atencin a la esttica de los mismos tal
y como lo plantea XP. La nica excepcin fueron los
diagramas Entidad Relacin los cuales se construyeron
45
en el SQL SERVER EXPRESS con la cual se elaboraban

mucho ms fcil que a mano.
3.2.2 METFORA DEL SISTEMA
Lo que dice XP:
- Plasmar
la
arquitectura
del
sistema
en
una
objetos
del
historia.
- Convencin
de
nombres
para
los
sistema.
Debido que el programa es una aplicacin sencilla y
de fcil comprensin tanto para el desarrollador como
para el cliente, no se requiri del empleo de una
metfora, manteniendo todos los nombres en contexto
mediante la aplicacin.
3.2.3 TARJETAS CRC
Lo que dice XP:
- Su
principal
utilidad
es
dejar
el
enfoque
procedimental y entrar al modelo orientado a

objetos.
- Todo el grupo participa en su elaboracin
Una de las principales piezas de diseo empleada en
el proyecto fueron las tarjetas CRC que no slo
sirvieron como columna vertebral de este, sino que
tambin fueron la base del modelo Entidad Relacin,
elaborado para modelar la base de datos. Cada Tarjeta
CRC se convirti en un objeto, sus responsabilidades
en mtodos pblicos y sus colaboradores en llamados
a otras clases.
En el proceso de elaboracin de las tarjetas CRC los
dos
miembros
del
equipo
estuvieron
presentes
46
manipulndolas, de modo tal que tanto el diseo fue

producto de la participacin del desarrollador y el
representante de la empresa, como el resultado del
mismo
fue
ampliamente
asimilado
por
ambos,
favoreciendo la propiedad colectiva del cdigo.

En XP el proceso de diseo es iterativo, por lo cual
las tarjeas CRC no fueron creadas todas en la primera
iteracin. Al inicio de cada iteracin se les fueron
agregando
responsabilidades,
llamados,
fueron
creadas otras CRC nuevas de modo tal que el diseo se

convirti en un proceso dinmico que se adaptaba a
las
necesidades
planteadas
para
el
momento.
Sin
embargo, su utilidad no fue la misma durante todo el

proceso de desarrollo. En las primeras iteraciones
fueron supremamente tiles dando una idea clara de la
arquitectura del sistema, distribucin de clases,
paquetes
la
ubicacin
de
las
diferentes
responsabilidades sobre la lgica del negocio, pero

en las ltimas iteraciones donde ya se tena claridad
sobre todos estos elementos, las tarjetas CRC fueron
menos empleadas.
XP
no
propone
una
estrategia
para
afrontar
la
implementacin de las tarjetas CRC, por lo cual se

cre una con la cual se garantiz el poder correr las
pruebas
desde
el
implementacin.
mismo
Primero
momento
fueron
que
inici
implementadas
la
las
clases ms sencillas, aquellas que no hacan llamados

a
ninguna
otra,
para
seguir
con
las
que
hacan
llamados a las ya implementadas y as sucesivamente.

Aunque XP no plantea una metodologa para implementar
un
modelo
de
CRC,
fue
importante
adoptar
esta
metodologa debido a que era la forma ms cmoda de

poder aplicar las pruebas en todo momento.
47
3.2.4 SPIKE SOLUTION (SOLUCIN RPIDA)

Lo que dice XP:
- Se trata de una prueba que se hace para resolver un
problema tcnico o de diseo.
- Es un programa muy simple que explora una solucin
potencial.
Se presentaron dos situaciones en las cuales se debi
implementar Spike Solution. Cada uno de los cuales se
produjo en su respectiva iteracin.
Para implementar las pruebas tal como XP las recomienda
se
debi
recurrir
una
librera
especialmente
diseada para tal fin, Visual Studio Express 2012. El

estudio de esta fue encargado al desarrollador, el
cual destin aproximadamente ocho horas a su estudio,
al trmino de las cuales en un periodo no mayor a dos
horas
capacit
representante
requiri
de
de
una
en
el
empleo
la
empresa.
herramienta
de
Por
que
la
otro
librera
lado,
permitiera
se
crear
reportes impresos de calidad de una forma sencilla. La

mejor solucin encontrada fue CrystalREPORTS, la cual
fue estudiada en el transcurso de la primera iteracin
por
el
desarrollador
sin
que
retrasara
sus
dems
responsabilidades con el proyecto.

XP
recomienda
parejas,
sin
asignar
embargo,
estos
tal
Spike
como
se
Solution
explic
en
por
el
captulo de planeacin no fue hecho de esta forma, lo

que no represent un problema. El objetivo de lograr
una comprensin rpida de cada uno de esto asuntos fue
logrado, asegurando el cumplimiento de los plazos del
proyecto.
48
Un
aspecto
Solution
importante
es
que
el
relacionado
conocimiento
con
los
adquirido
Spike
con
la
elaboracin de estos debe ser compartido con el resto

del
grupo,
debido
que
es
uno
de
los
puntos
ms
sensibles de convertirse en islas de conocimiento y

posteriormente
cuellos
de
botella,
lo
que
definitivamente procura evitar XP.

Uno de los aportes ms importantes del concepto de
Spike
Solution
fue
la
posibilidad
de
desligarse
completamente del proyecto mientras se trabaja en l,

lo que facilita la concentracin del esfuerzo personal
en adquirir un conocimiento en lugar de disiparlo
intentando
solucionar
un
problema
sin
saber
cmo
enfrentarlo.
3.2.5 REFACTORIZACIN
Lo que dice XP:
- Diseo como tarea permanente.
- Se conserva el cdigo sencillo.
- Rehacer secciones de cdigo si es necesario.
Al transcurrir el desarrollo de la aplicacin, se
revis constantemente el diseo de la misma surgiendo
situaciones que no fueron tomadas en cuenta al comienzo
del proyecto en el diseo general. Como salida a estos
problemas se opt por la refactorizacin de las partes
afectadas, buscando las soluciones ms convenientes y
sencillas,
Aunque
conservando
estos
cambios
la
simplicidad
fueron
extensos,
del
en
cdigo.
ningn
momento se convirtieron en cuellos de botella.

Una de estas situaciones se refiri a la decisin que
se tom de no crear las ordenes que estn por venir a
la empresa de las que ya se encuentran en la empresa.
49
Las medidas tomadas para subsanar este error no tomaron

ms de 1 hora para su solucin. En una metodologa
pesada, este tipo de situaciones podra generar costos
extras, mientras en XP no tuvo la menor trascendencia,
slo demand la implementacin de una estrategia de
solucin en el menor tiempo posible.
Otra situacin a la que se aplic refactoring fue la
conveniencia de cambiar el tipo de datos de la tabla
proveedor,
casi
al
finalizar
el
proyecto.
Dicha
modificacin afectaba aproximadamente la mitad de las

clases y mtodos de la aplicacin, entre las cuales se
encontraban las relacionadas con Producto, y Ordenes.
Aunque este inconveniente se present a ltima hora,
el desarrollador logr cambiar los tipos de datos de
cadena a entero no slo en la base de datos sino
tambin en los mtodos donde existan estas variables,
en un tiempo aproximado de dos horas. Este refactoring
fue logrado con xito gracias a la estructura del
programa que permiti la adicin del cdigo faltante,
y al plan de organizacin que se ide antes de dicha
modificacin.
3.3 CODIFICACIN
En metodologas pesadas, la codificacin es un proceso
al cual solo se llega despus de largas fases de
anlisis y diseo de las que queda una gran cantidad
de documentacin a partir de la cual el proceso de
codificacin
proceso
es
es
muy
relativamente
diferente.
sencillo.
En
Prcticamente
XP
el
desde
un
principio se inicia con la codificacin, favoreciendo

el
logro
del
objetivo
de
estar
haciendo
entregas
frecuentemente al cliente.
Algunos de los elementos ms importantes en cuanto a
la codificacin son que, el cliente siempre debe estar
50
presente en esta, se debe trabajar en parejas y debe

haber una propiedad colectiva del cdigo. Todos estos
elementos representan paradigmas nuevos en lo que a la
ingeniera de software se refiere, planteando entornos
de discusin sobre la conveniencia de adoptarlas.
A
continuacin,
encontrar
para
cada
uno
de
los
aspectos que conforman la etapa de codificacin una

comparacin entre las ideas tericas de la codificacin
y lo aplicado en la ejecucin del ejercicio prctico.
3.3.1 CLIENTE SIEMPRE PRESENTE
Lo que dice XP:
- El cliente debe estar disponible en el sitio de
trabajo.
- El cliente es fundamental para solucionar dudas
cara a cara.
La idea de tener al cliente, un representante de ste
o
un
usuario
no
es
fcil
de
asimilar
si
se
consideran los costos que esto representa. En el caso

de este proyecto, el cliente no poda desplazarse a
ninguno de los lugares de trabajo, pero si se cont
con la presencia del representante de la empresa. Por
tal motivo se debi implementar una estrategia de
comunicacin distinta en la cual el desarrollador
poda llamar va telefnica al cliente en el momento
que
requirieran
solucionar
cualquier
duda
en
el
proceso de implementacin. Si bien esta estrategia no

fue igual de efectiva que haber tenido al usuario
acompaando el desarrollo, fue suficiente para lograr
una buena comunicacin con el cliente.
Es importante tener en cuenta que contar con un
representante del cliente en las instalaciones del
51
equipo
de
desarrollo
demandar
una
inversin
econmica representada en la remuneracin econmica

para
el
representante.
En
muchos
proyectos
susceptibles de ser desarrollados por medio de XP,

este gasto se vuelve inaceptable por elevar de forma
importante el costo del proyecto. Sin embargo, se
puede
plantear
una
solucin
intermedia
donde
el
representante del cliente solo est presente durante

un
periodo
de
tiempo
acordado
con
el
grupo
de
desarrollo por da, que deber ser aprovechado para

disipar cualquier duda que haya surgido durante el
resto del tiempo de desarrollo en que no estuvo. Esta
es
una
Cliente
modificacin
In
Situ
importante
es
uno
de
a
los
XP,
ya
que
elementos
el
ms
relevantes de esta metodologa y la hace mucho ms

aplicable en la prctica.
3.3.2 NO TRABAJAR HORAS EXTRAS
Lo que dice XP:
- No trabajar horas extras.
- El dedicar horas extras a un proyecto retrasado,
no lo va a poner al da.
- Es preferible replantear los plazos a trabajar
horas extras.
Debido al tamao del negocio, el equipo de trabajo no
tuvo algn tipo de retraso considerable que requiera
replanteo del proyecto.
Uno de los elementos que considera XP para hacer la
mayora de sus planteamientos es el hecho que la labor
de programacin es muy difcil de estimar y proyectar
en el tiempo. La experiencia tanto en este proyecto
como en otros anteriores es que el rendimiento en la
52
labor de programacin vara mucho segn un sinnmero

de circunstancias que afectan no slo al proyecto en
s mismo sino tambin a quin lo est implementando.
En tal sentido, se debera poder tanto flexibilizar
en
lo
posible
los
plazos
como
disearlos
con
suficiente holgura para contemplar estas posibles

demoras. Si bien XP plantea que debera ser posible
replantear algunos plazos, esta posibilidad debera
quedar clara desde el principio con el cliente para
evitar malos entendidos.
3.4 PRUEBAS
XP enfatiza en la realizacin de un sin nmero de
pruebas a lo largo del proyecto, con el fin de asegurar
en todo momento la realizacin de lo planteado en el
diseo. En este proceso no slo participa el equipo de
desarrollo,
tambin
es
importante
los
aportes
del
cliente, sobre todo en las pruebas de aceptacin.

Cabe sealar que el diseo de pruebas se realiza para
todas las partes del sistema como una prctica para
garantizar el buen funcionamiento, independiente de la
decisin
que
se
tome
sobre
implementarlas
en
un
framework como Visual Studio Express.

Esta seccin se divide en partes que corresponden a las
pruebas unitarias, de aceptacin y qu hacer cuando se
encuentra un error.
3.4.1 PRUEBAS UNITARIAS
Lo que dice XP:
- Las pruebas deben ser escritas antes que los
mtodos.
- Su implementacin y ejecucin deben consumir el
menor tiempo posible.
53

La creacin de pruebas fue una experiencia nueva para
el equipo de trabajo al ser una de las reglas de la
metodologa XP que no se haba llegado a utilizar en
proyectos anteriores. Debido a esto, la realizacin
de pruebas al principio del proyecto fue traumtica
y demand ms tiempo de lo planeado, lo cual no fue
conveniente ya que la metodologa intenta disminuir
los cuellos de botella, no aumentarlos.
El carcter obligatorio de la escritura de las pruebas
antes
del
desarrollo
de
los
mtodos
del
sistema
implica un proceso de diseo previo. Esto se considera

una
ventaja
construccin
ya
de
que
la
se
destina
prueba,
pero
tiempo
al
en
la
realizar
la
codificacin del mtodo, ste resultaba de manera

casi inmediata. Tambin se destaca la autonoma que
deben tener dichas pruebas a la hora de su ejecucin,
lo que implicaba la manipulacin de la base de datos
y la recuperacin de su estado inicial al finalizar
la prueba.
Segn XP, se deben crear todas las pruebas de una
clase antes de comenzar a desarrollar los mtodos. En
la experiencia fue conveniente realizar las pruebas
individualmente, debido a que se producan errores al
ejecutar todas las pruebas en un solo llamado. Se
descubri que este inconveniente estaba relacionado
con la base de datos y no con los mtodos, lo que al
principio del proyecto aplic dificultad al evaluar
si un mtodo haba pasado o no la prueba. Una vez que
se descubri este error se empez a ejecutar las
pruebas por grupos en lugar de ejecutarlas todas de
una
vez.
De
esta
forma
no
haba
problemas
de
comunicacin con la Base de Datos, y se garantizaba

54
que si una prueba fallaba era solo por errores de

lgica.
XP propone la utilizacin de una herramienta que
realice
de
forma
automtica
la
implementacin
ejecucin de las pruebas. En este caso se recurri a

la
compilacin,
una
herramienta
de
Visual
Studio
especializada para la creacin de unidades de prueba,

que result ser una eleccin apropiada a la hora de
probar las clases y mtodos que se referan a la
lgica del negocio.
3.4.2 PRUEBAS DE ACEPTACIN
Lo que dice XP:
- Se deben disear las pruebas de aceptacin con
base en las historias de usuario.
Tres elementos permitieron al grupo de desarrollo
disear las pruebas de aceptacin. En primer lugar,
el tipo de sistema implementado era suficientemente
sencillo y conocido por todos los miembros del equipo
de desarrollo, principalmente porque uno de ellos
labor como empleado para el cliente. En segundo
lugar, las reuniones de las cuales se obtuvieron las
historias de usuario fueron grabadas en audio y video
con lo cual fue posible la reconstruccin de las
pruebas
de
aceptacin
por
parte
del
equipo
de
desarrollo sin toda la intervencin del cliente. En

tercer
funcin
lugar,
de
el
diseo
cliente
de
las
acept
el
pruebas
delegar
debido
esta
que
su
disponibilidad de tiempo, como ya es mencionada en

otros apartados del documento, se lo impidi.
55
3.4.3 CUANDO SE ENCUENTRA UN ERROR

Lo que dice XP:
- Al encontrar un error debe escribirse primero la
prueba antes que corregirlo.
Estas pruebas manuales consistan en cajas negras
donde se verificaba la solucin del problema mediante
la ejecucin del programa.
Cuando el cdigo de una de las clases principales
pasaba
la
prueba
que
se
haba
diseado
con
anterioridad, pero los programadores encontraban que

la funcionalidad no era correcta, se modificaba la
prueba y se correga el cdigo.
56
CAPTULO IV
RESULTADOS Y CONCLUSIONES
4.1 RESULTADOS
En la presente imagen se ve el sistema de control de
inventario, el cual tiene el mdulo de ventas, pedidos
donde
se
registra
el
material,
las
categoras,
los
clientes, gestionar proveedores y empleados.

Grfico 10
Vista Pedidos del sistema control de inventario
En el grfico 10, observamos que podemos hacer un filtro

ya sea en base al nombre del producto, categora, nombre
del empleado y proveedor.
58
En la siguiente grfica se har el registro de un nuevo

producto.
Grfico 11
Registro de Producto
En la siguiente grfica se har el registro de un nuevo

empleado.
Grfico 12
Registro de empleado

59
En la siguiente grfica se muestra como se realiza la

salida
de
un
producto
del
sistema
este
se
debita
automticamente del stock de producto, primero observamos

que el stock para el producto Muelle para Camin JAC, es
de 10.
Grfico 13
Vista inventario
Seguidamente realizamos el registro de una venta

Grfico 14
Registro de pedido

60
Al volver a la pestaa inventario, observamos que ahora

el producto esta en 6. Lo cual demuestra que el sistema
debito esa compra.
Grfico 15
Vista inventario con el producto debitado
4.2 CONCLUSIONES Y RECOMENDACIONES

CONCLUSION
Se logr implementar un Sistema de Inventario para la
CONCLUSIONES ESPECFICAS
Se
mejor
la
gestin
de
inventario
para
la

Se sistematiz los procesos de manejo de inventario
para la IMPORTADORA SARITA E.I.R.L.
4.3 RECOMENDACIONES
Se debe considerar
control
de
en
inventarios,
un
posterior
las
ordenes
trabajo
que
en
el
estn por
llegar a la empresa, y no considerar las ordenes como

el stock inicial de la empresa.
61
BIBLIOGRAFA
Cantone, D. (2006). Ciclo de Vida del Software. En D.

Cantone, La biblia del programador. Implementacin y
Debugging (pg. 16). Argentina: MP Ediciones.
Definicin. (2016). Sistematizacin. Obtenido de Definicin
MX: http://definicion.mx/sistematizacion/
Garca, E. (2009). Introduccin a la programacin en 3
capas. Obtenido de Coding Blog:
https://mredison.files.wordpress.com/2009/11/viernes13
noviembre2009.pdf
Joskowicz, J. (2008). Reglas y Prcticas en eXtreme
Programming. Obtenido de Instituto de Ingeniera
Elctrica: http://iie.fing.edu.uy/~josej/docs/XP%20%20Jose%20Joskowicz.pdf
Lozano, D., & Moreano, D. (2016). TIC slides. Obtenido de
emaze presentations:
https://www.emaze.com/@ACQZQFFI/TIC-slides
Prez Valds, D. (2007). Qu son las bases de datos?
Obtenido de Maestros del Web:
http://www.maestrosdelweb.com/que-son-las-bases-dedatos/
Porta Rueda, C. A. (2011). Gestin de inventario, stocks y
almacenes GestioPolis. Obtenido de GestioPolis Conocimiento en Negocios:
http://www.gestiopolis.com/gestion-de-inventariostocks-y-almacenes/
UDEA. (2016). Manejo de TIC: Definicin del concepto de
TIC. Obtenido de Aprendeenlinea.udea.edu.co:
62
http://aprendeenlinea.udea.edu.co/lms/investigacion/mo
d/page/view.php?id=3118
Wikipedia. (2016). C Sharp. Obtenido de es.wikipedia.org:
https://es.wikipedia.org/wiki/C_Sharp
Zenteno, R. (2016). SISTEMATIZACIN DE PROCESOS EN LAS
PYMES, LA CLAVE PARA LA RENTABILIDAD . Obtenido de
Akbal Consulting: http://www.akbalconsulting.com/tipsde-gestion/sistematizacin-de-procesos-en-las-pymes-laclave-para-la-rentabilidad
63
ANEXOS
A. DIAGRAMA DE LA BASE DE DATOS
En la siguiente imagen se muestra el diagrama de la base de datos que se utiliz para la elaboracin
del sistema de control de inventario.
PedidoDetalles (Entradas)
Pedidos (Entradas)
id_pedido
id_producto
id_Proveedor
precio_unitario
id_empleado
id_Cliente
id_empleado
FK_Ventas_Empleado
fecha_requerido
FK_Pedidos_Proveedores
ruc
direccion
ciudad
region
pais
telefono
fax
FK_PedidoDetalles_Productos
fecha_ordenado
FK_Pedidos_Empleado
nombre_empresa
descuento
id_Venta
codigo
Proveedores (Entradas)
cantidad
Ventas (Salidas)
fecha_entrada
id_Proveedor
id_pedido
FK_PedidoDetalles_Pedidos
fecha_entregado
Empleados (RecursosHumanos)
costo_envio
id_empleado
Productos (Inventario)
codigo
nombre_empleado
id_producto
apellido_empleado
nombre_producto
direccion
id_categoria
precio_unitario
ciudad
region
detalles
pais
FK_VentaDetalles_Ventas
telefono
codigo
Unidades_Stock
FK_Ventas_Clientes
codigo
Clientes (Salidas)
email
id_cliente
codigo
nombre_cliente
FK_VentaDetalles_Productos
FK_Productos_Categorias
nombre_contacto
direccion
VentaDetalles (Salidas)
ciudad
id_Venta
region
id_producto
pais
precio_unitario
telefono
cantidad
fax
descuento
email
codigo
Categorias (Inventario)
id_categoria
nombre_categoria
descripcion
codigo
B. HISTORIAS DE USUARIO
Las historias de usuario que son prioridad para el
desarrollo de esta metodologa, se realizaron mediante
entrevistas con el cliente, las siguientes historias
son las que se recopilaron.
Historia de Usuario 01
Nombre
REGISTRO CLIENTE
Historia
FECHA
01/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
El encargado de la tienda, procede a pedir

los datos al cliente. Y los ingresa
manualmente a un libro. Donde los agenda.
NOTAS
Nombre
REGISTRO PROVEEDOR
Historia
FECHA
01/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
El encargado de la tienda, procede a ingresar

los datos de un nuevo proveedor manualmente en
un libro de proveedores.
NOTAS
Se realiza esta operacin una vez un proveedor

se haya realizado la compra de inventario.

65
Nombre
REGISTRO CATEGORA
Historia
FECHA
02/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
El encargado de la tienda, al ingresar un nuevo

producto que no corresponda a alguna categora,
procede a ingresarla en su libro de inventario.
NOTAS
Se realiza esta operacin una vez que se haya

comprobado que un producto no tiene una
categora pre-establecida.
Nombre
REGISTRO EMPLEADO
Historia
FECHA
01/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
El gerente de la tienda una vez pasada la

entrevista
respectiva
con
el
potencial
empleado de la empresa, procede a registrar sus

datos en el libro de empleados.
NOTAS
Se realiza cuando ya el aspirante al cargo

aprueba la entrevista de trabajo.
66
Nombre
REGISTRO INVENTARIO
Historia
FECHA
01/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
El encargado de la tienda una vez que le hayan

trado una factura que indique la compra de
inventario
registrar
a
el
la
empresa,
producto
este
con
sus
procede
respectivas
caractersticas en libro de inventario segn a

una categora.
NOTAS
Se debe tener la factura de compra del

producto.

Nombre
REGISTRO INGRESO PRODUCTO (PEDIDOS)
Historia
FECHA
02/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
El encargado de la tienda, registra el pedido

que
trae
un
proveedor
lo
agrupa
con
el
producto al que pertenece y esta cantidad se

suma a la existente, y este se registra en el
libro de inventario.
NOTAS
Se debe tener la factura de compra y el

producto debe estar en la tienda.

67
Nombre
EDICIN INGRESO PRODUCTO
Historia
FECHA
02/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
El encargado de la tienda, hace correccin al

pedido que se ha ingresado en la el libro de
inventario.
NOTAS
Se debe tener la factura de compra y a su vez

el permiso del dueo de la empresa.
Nombre
ELIMINACIN INGRESO PRODUCTO
Historia
FECHA
03/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
El encargado de la tienda
si es que surgiera
algn tipo de inconveniente o anomala con el

inventario pedido, este procede a cancelar este
ingreso y a retirarlo del stock disponible.
NOTAS
Solo
se
realiza
cuando
existe
defectos
errores de envo por parte de los proveedores

de la empresa.
68
Nombre
REGISTRO VENTA
Historia
FECHA
03/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
El encargado de la tienda cuando un cliente

viene a realizar una compra, este solicita sus
datos y procede a llenar la orden de compra que
el cliente pide.
NOTAS
Para realizar el llenado de la boleta o

factura, el cliente debe de haber realizado
el pago del producto.
Nombre
EDITAR VENTA
Historia
FECHA
03/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
Cuando
el
cliente
procede
disminuir
la
cantidad de su compra o cambiar el producto,

el encargado de la tienda modifica la venta al
nuevo requerimiento del cliente y realiza el
pago.
NOTAS
Si ya se realiz la factura o boleta, esta se

anula y se realiza una nueva.

69
Nombre
ELIMINAR VENTA
Historia
FECHA
03/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
Cuando el cliente procede a su compra, el

encargado de la tienda cancela la venta.
NOTAS
Si ya se realiz la factura o boleta, esta se

anula.
Nombre
EDITAR EMPLEADO
Historia
FECHA
04/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
Si un empleado detecta algn tipo de error en

sus datos, este avisa al dueo de la empresa
para que realice la correccin respectiva.
NOTAS
El empleado debe llevar algn documento que

sustente el cambio de datos.
70
Nombre
ELIMINAR EMPLEADO
Historia
FECHA
05/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
El dueo de la empresa, cuando ya culmino el

periodo de contrato de algn trabajador o este
ha cometido algn incidente grave, este procede
a eliminar sus datos de la empresa.
NOTAS
Nombre
EDITAR CATEGORA
Historia
FECHA
05/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
El encargado, realiza el cambio de datos de una

categora ya ingresada, debido a que esta ya
no se vende o que ahora est pertenezca a otra
categora.
NOTAS
71
Nombre
ELIMINAR CATEGORIA
Historia
FECHA
05/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
El encargado de la tienda, procede a eliminar

una categora ya ingresada debido a que esta
ya no es necesaria
NOTAS
Nombre
ACTUALIZAR DATOS PROVEEDOR
Historia
FECHA
06/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
El encargado de la tienda procede a actualizar

los datos del proveedor previa coordinacin con
l.
NOTAS
72
Nombre
ELIMINACIN DE PROVEEDOR
Historia
FECHA
06/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
El encargado cuando un proveedor no cumpla con

los plazos establecidos en reiteradas veces,
este procede a eliminar los proveedores de la
empresa ya que se vuelve un atraso para el
progreso de la empresa.
NOTAS
Se debe tener un registro de incidencias.
Nombre
DEBITAR STOCK
Historia
FECHA
06/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
El encargado de la tienda una vez que se haya

realizado una venta, y se haya entregado el
producto al cliente y este a su vez haya hecho
el pago respectivo, procede a descontar esta
cantidad del stock con el que se cuenta.
NOTAS
Se debe tener la factura o boleta de venta.
73
Nombre
REINGRESO DE STOCK
Historia
FECHA
06/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
El encargado de la tienda una vez que se haya

producido la cancelacin de una venta, este
procede a re-anotar la cantidad de stock.
NOTAS
Nombre
EDITAR INVENTARIO
Historia
FECHA
06/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
El encargado de la tienda una vez que haya

realizado manualmente el inventariado de los
productos de la empresa y vea que exista un
descuadre entre lo que tiene anotado y con lo
que
registro
contando,
este
procede
actualizar el stock existente.

NOTAS
Debe
tener
anotada
sustentacin
cuando
realiza
de
la
cantidad
en
inventariado
manual.
74
Nombre
REGISTRAR VENTA PENDIENTE
Historia
FECHA
06/05/2016
ENTREVISTADO
FELIPE CHACN
TIEMPO
2 HORAS
ESTIMADO
DESCRIPCION
El encargado de la tienda cuando tiene una

venta de mayor cantidad al stock que tiene
disponible,
procede
estableciendo
una
fecha
realizar
de
entrega
esta,
del
producto al cliente.
NOTAS
Debe entregar la boleta de venta indicando el

da en el cual se contara con el stock deseado
por el cliente.
75
C. CRONOGRAMA Y PRESUPUESTO
PRESUPUESTO
Como se elaboraron 9 iteraciones, como se muestra en el
cronograma, el presupuesto total es:
PERSONAL DE DESARROLLO
Tabla 03
Costos para el desarrollo de Sistema de Control de Inventario

NRO
COSTO
NRO
NRO
Hr/Da
/HORA
D/Sem
SEM.
FASE DE PLANIFICACIN
S/. 225.00
FASE DE DISEO
S/. 375.00
FASE DE CODIFICACIN
S/. 630.00
FASE DE PRUEBA
S/. 180.00
DESCRIPCION
PRECIO
TOTAL
S/.1,410.00
SOFTWARE
Tabla 04
Costos de Software para el desarrollo.
DESCRIPCION
PRECIO
OBSERVACIONES
TOTAL
S/. 0.00
Freeware
S/. 0.00
S/. 0.00
Freeware
S/. 0.00
Visual Studio
Express 2012
SQL server
Express 2014
TOTAL
S/. 0.00
MATERIALES DE OFICINA
Tabla 05
Costos de materiales de oficina
DESCRIPCION
PRECIO
PAPELERIA
S/. 100.00
SERVICIOS
S/. 50.00
TOTAL
S/. 150.00
76
RESUMEN COSTOS
Tabla 06
Costo total de desarrollo e implementacin de sistema de control
de inventario.
DESCRIPCION
PRECIO
PERSONAL DE DESARROLLO
SOFTWARE
S/. 1,410.00
S/. 0.00
MATERIALES DE OFICINA
TOTAL
S/. 150.00
S/. 1,560.00
77
CRONOGRAMA
Tabla 07
Cronograma de actividades para el desarrollo del sistema de

control de inventario
ACTIVIDADES
1
1.
Entregable
del sistema.
2. Reuniones
Diarias
3. Iteracin 1
4. Iteracin 2
5. Iteracin 3
6. Iteracin 4
7. Iteracin 5
ABRIL
MAYO
JUNIO
JULIO
SEMANAS
SEMANAS
SEMANAS
Semana
X
X
X
X
X
X
X
X
10
11
12
X
X
13
14
15
X
X
16
X
9. Iteracin 7
10. Iteracin
8
Revisin
12. Segunda
Revisin
18
X
8. Iteracin 6
11. Primera
17
X
X
13.
SUSTENTACIN
78

Informe de Prácticas Version Final

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Informe de Prácticas Version Final

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSIDAD TECNOLGICA DE LOS ANDES

INFORME PRCTICAS PRE PROFESIONALES

Implementacin de un Sistema de Inventario para la

Autor: Edwin Batallanos Huaman

SISTEMA DE CONTROL DE INVENTARIO PARA LA IMPORTADORA SARITA E.I.R.L.

crecimiento econmico en sectores como la agricultura,

automotores. Para su normal operacin a fin de cumplir

autopartes y/o repuestos.

SISTEMA DE CONTROL DE INVENTARIO PARA LA IMPORTADORA SARITA E.I.R.L.

de un sistema de ventas que permita la integracin entre

SISTEMA DE CONTROL DE INVENTARIO PARA LA IMPORTADORA SARITA E.I.R.L.

SISTEMA DE CONTROL DE INVENTARIO PARA LA IMPORTADORA SARITA E.I.R.L.

4.3 RECOMENDACIONES ................................................................................................... 61

DIAGRAMA DE LA BASE DE DATOS .................................................................. 64

HISTORIAS DE USUARIO ..................................................................................... 65

CRONOGRAMA Y PRESUPUESTO ........................................................................... 76

SISTEMA DE CONTROL DE INVENTARIO PARA LA IMPORTADORA SARITA E.I.R.L.

1.1 DESCRIPCIN DE LA EMPRESA

: Venta de partes, piezas

y accesorios para vehculos automotores.

: Mza. L Lote 5 Urb. 3 de

Mayo San Jernimo - Cusco

Ccorimanya Titular Gerente.

personalizada, con el mejor producto a un buen precio,

autopartes, lder en ventas en la ciudad del Cusco,

necesidades y cambios del mercado automotriz.

Fuente: Importadora Sarita E.I.R.L.

1.4 DESCRIPCIN DEL PROBLEMA

20450570541, con ms de diez aos en el mercado ubicada

SISTEMA DE CONTROL DE INVENTARIO PARA LA IMPORTADORA SARITA E.I.R.L.

se dedica a la importacin y venta de autopartes,

cliente a las personas freelance1, que por motivos

inventario no es registrado en algn tipo de sistema

inventario segn tipo, uso u otro tipo de filtro que

computadoras, que segn las polticas de la empresa

Se denomina freelance (o trabajador autnomo, por cuenta propia o

SISTEMA DE CONTROL DE INVENTARIO PARA LA IMPORTADORA SARITA E.I.R.L.

deben servir para realizar los pedidos de inventario y

adquirir tecnologa y sobre todo darles un buen uso.

proveer es tipo de servicios, las Tecnologas de la

recuperarla despus, enviar y recibir informacin de un

SISTEMA DE CONTROL DE INVENTARIO PARA LA IMPORTADORA SARITA E.I.R.L.

Ellos estn sujetos en este lugar a

salida, reubicacin, modificaciones de presentacin,

eslabn del proceso de distribucin ya que se encuentra

generalmente un dficit de inventario, lo que indica

evita prdidas del

material y tambin se evita el pedido de materiales

Carmen Bocanegra Gastelum, Profesorainvestigadora del Departamento de

SISTEMA DE CONTROL DE INVENTARIO PARA LA IMPORTADORA SARITA E.I.R.L.

1.6 OBJETIVOS DE LAS PRACTICAS PRE-PROFESIONALES

IMPORTADORA SARITA E.I.R.L.

SISTEMA DE CONTROL DE INVENTARIO PARA LA IMPORTADORA SARITA E.I.R.L.

2.1 TECNOLOGAS DE INFORMACIN Y COMUNICACIN

tecnologas para almacenar informacin y recuperarla

resultados y elaborar informes".

capacidades mentales y permite el desarrollo de

Fuente: (Lozano & Moreano, 2016)

SISTEMA DE CONTROL DE INVENTARIO PARA LA IMPORTADORA SARITA E.I.R.L.

otorgar jerarquas a los diferentes elementos.

alguna manera (uno con otro, o con ms de uno).

sistematizacin de procesos, para mejorar la calidad

Fuente: (Zenteno, 2016)

Toda empresa PYME, que pretenda mantenerse competitivo