SISTEMA DE GESTION DE INGRESOS Y SALIDAS DE PRODUCTOS DE ALMACEN

Facultad de Ingeniería
Facultad de Ingeniería
Escuela Académico Profesional de Ingeniería de Sistemas

TEMA DE PRÁCTICAS: “SISTEMA DE GESTION DE INGRESOS Y

SALIDAS DE PRODUCTOS DE ALMACEN”
NOMBRE DE LA EMPRESA: TRIMBLE PERU CORPORATION SAC

ALUMNOS:
- Gonzales Castillo Jorge Arcadio
- Ramos Suyón Juan Carlos

DOCENTE ASESOR:
Ing. MENDOZA RIVERA, RICARDO DARIO, Dr.

CICLO:
IX
TRUJILLO – PERÚ
2016
IX Ciclo Página 1
 SISTEMA DE GESTION DE INGRESOS Y SALIDAS DE PRODUCTOS DE ALMACEN

Contenido
1. Generalidades ....................................................................................................................... 3
2. Formulación de problema ..................................................................................................... 3
2.1. Realidad Problemática .................................................................................................. 3
3. Objetivos ............................................................................................................................... 3
3.1. Objetivo principal .......................................................................................................... 3
3.2. Objetivo secundario ...................................................................................................... 4
4. Metodología .......................................................................................................................... 4
4.1. La metodología a utilizar es la XP .................................................................................. 4
4.2. Características fundamentales ...................................................................................... 4
4.3. Fases de la metodología XP ........................................................................................... 5
4.4. Ventajas e inconvenientes de la metodología ............................................................ 11
5. Bibliografía .......................................................................................................................... 11
6. Presupuesto ........................................................................................................................ 12
7. Materiales tecnológicos a utilizar ....................................................................................... 12
8. Cronograma de ejecución ................................................................................................... 13

IX Ciclo Página 2
 SISTEMA DE GESTION DE INGRESOS Y SALIDAS DE PRODUCTOS DE ALMACEN

1. Generalidades
Nombre Comercial:
“TRIMBLE PERU CORPORATION SAC”

RUC:
20566082901

Giro del Negocio:

Vta. May. De Otros Productos.

Dirección:
Av. General Salaverry Nro. 674 Dpto. 203 Jesús María Lima, Perú

2. Formulación de problema
2.1. Realidad Problemática
Actualmente la empresa TRIMBLE PERU CORPORATION SAC no cuenta con
un sistema para el área de almacén, que permita tener el control de las entradas
y salidas así como el seguimiento de los productos. Los registros se venían
haciendo en hojas de cálculo de Excel. Estos déficit pueden provocar problemas
mayores como desinformación de los ingresos y egresos de productos al
almacén.

Entre los problemas que se pueden encontrar tenemos:

No se podía realizar correctamente la búsqueda o el seguimiento de un producto.
Al momento de realizar el balance de existencias no concordaban las cantidades.
No se podía diferenciar correctamente entre dos productos que tenían el mismo
código.
Los consolidados se hacían manualmente y en hojas de cálculo, de esta manera
no se podía visualizar bien los resultados y el tiempo de elaboración eran largos.
3. Objetivos
3.1. Objetivo principal
Implementar una aplicación para optimizar la gestión y control de los ingresos y
salidas de productos en el área de almacén.

IX Ciclo Página 3
 SISTEMA DE GESTION DE INGRESOS Y SALIDAS DE PRODUCTOS DE ALMACEN

3.2. Objetivo secundario

 Recopilar información necesaria del área de almacén mediante la
comunicación constante con el gerente de la empresa.
 Analizar los requerimientos necesarios para el desarrollo del proyecto.

4. Metodología
4.1. La metodología a utilizar es la XP
La programación extrema o eXtreme Programming (de ahora en adelante, XP)
es una metodología de desarrollo de la ingeniería de software formulada por
Kent Beck, autor del primer libro sobre la materia, Extreme Programming
Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles
de desarrollo de software. Al igual que éstos, la programación extrema se
diferencia de las metodologías tradicionales principalmente en que pone más
énfasis en la adaptabilidad que en la previsibilidad. Los defensores de la XP
consideran que los cambios de requisitos sobre la marcha son un aspecto natural,
inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de
adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto
es una aproximación mejor y más realista que intentar definir todos los
requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los
cambios en los requisitos(«Programación extrema» 2016).

Se puede considerar la programación extrema como la adopción de las mejores

metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el
proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.

4.2. Características fundamentales

Las características fundamentales del método son:

- Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.

- Pruebas unitarias continuas, frecuentemente repetidas y automatizadas,
incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba
antes de la codificación. Véase, por ejemplo, las herramientas de
prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la
plataforma.NET o PHPUnit para PHP. Estas tres últimas inspiradas en JUnit,

IX Ciclo Página 4
 SISTEMA DE GESTION DE INGRESOS Y SALIDAS DE PRODUCTOS DE ALMACEN

la cual, a su vez, se insipiró en SUnit, el primer framework orientado a

realizar tests, realizado para el lenguaje de programación Smalltalk.
- Programación en parejas: se recomienda que las tareas de desarrollo se
lleven a cabo por dos personas en un mismo puesto. La mayor calidad del
código escrito de esta manera -el código es revisado y discutido mientras se
escribe- es más importante que la posible pérdida de productividad
inmediata.
- Frecuente integración del equipo de programación con el cliente o usuario.
Se recomienda que un representante del cliente trabaje junto al equipo de
desarrollo.
- Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer
entregas frecuentes.
- Refactorización del código, es decir, reescribir ciertas partes del código para
aumentar su legibilidad y mantenibilidad pero sin modificar su
comportamiento. Las pruebas han de garantizar que en la refactorización no
se ha introducido ningún fallo.
- Propiedad del código compartida: en vez de dividir la responsabilidad en el
desarrollo de cada módulo en grupos de trabajo distintos, este método
promueve el que todo el personal pueda corregir y extender cualquier parte
del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles
errores serán detectados.
- Simplicidad en el código: es la mejor manera de que las cosas funcionen.
Cuando todo funcione se podrá añadir funcionalidad si es necesario. La
programación extrema apuesta que es más sencillo hacer algo simple y tener
un poco de trabajo extra para cambiarlo si se requiere, que realizar algo
complicado y quizás nunca utilizarlo.

4.3. Fases de la metodología XP

1ª Fase: Planificación del proyecto.

- Historias de usuario: El primer paso de la metodología X.P es definir las

historias de usuario con el cliente. Constan de 3 o 4 líneas escritas por el
cliente en un lenguaje no técnico sin hacer mucho hincapié en los detalles;
no se debe hablar ni de posibles algoritmos para su implementación ni de
diseños de base de datos adecuados, etc. Usadas para estimar tiempos de
desarrollo de la parte de la aplicación que describen. También 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 y los desarrolladores se reúnen 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.
IX Ciclo Página 5
 SISTEMA DE GESTION DE INGRESOS Y SALIDAS DE PRODUCTOS DE ALMACEN

 Release planning: Después de tener ya definidas las historias de usuario

es necesario crear un plan de publicaciones, en inglés "Release plan",
donde se indican las historias de usuario que se crearán para cada versión
del programa y las fechas en las que se publicarán estas versiones. Un
"Release plan" es una planificación donde los desarrolladores y clientes
establecen los tiempos de implementación ideales de las historias de
usuario, la prioridad con la que serán implementadas y las historias que
serán implementadas en cada versión del programa. Después 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 versión), el tiempo que tardarán en desarrollarse y
publicarse las versiones del programa, el número de personas que
trabajarán en el desarrollo y cómo se evaluará la calidad del trabajo
realizado.

- Iteraciones La metodología X.P. se ha de dividir en iteraciones de

aproximadamente 3 semanas de duración. Al comienzo de cada iteración los
clientes deben seleccionar las historias de usuario definidas en el "Release
planning" que serán implementadas. Estas historias de usuario son divididas
en tareas de entre 1 y 3 días de duración que se asignarán a los
programadores.

- Velocidad del proyecto: La velocidad del proyecto es una medida que

representa la rapidez con la que se desarrolla el proyecto. Usando la
velocidad del proyecto controlaremos que todas las tareas se puedan
desarrollar en el tiempo del que dispone la iteración. 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".

- Programación en pareja: La metodología X.P. aconseja la programación 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 función o método que está implementando, el otro analiza si ese
método o función es adecuado y está bien diseñado. De esta forma se
consigue un código y diseño con gran calidad.

IX Ciclo Página 6
 SISTEMA DE GESTION DE INGRESOS Y SALIDAS DE PRODUCTOS DE ALMACEN

- Reuniones diarias. Es necesario que los desarrolladores se reúnan

diariamente y expongan sus problemas, soluciones e ideas de forma
conjunta. Las reuniones tienen que ser fluidas y todo el mundo tiene que
tener voz y voto.

2ª Fase: Diseño.

- Diseños simples: La metodología X.P sugiere que hay que conseguir diseños
simples y sencillos. Hay que procurar hacerlo todo lo menos complicado
posible para conseguir un diseño fácilmente entendible e impleméntable que
a la larga costará menos tiempo y esfuerzo desarrollar.

- Glosarios de términos: Usar glosarios de términos y un correcta

especificación de los nombres de métodos y clases ayudará a comprender el
diseño y facilitará sus posteriores ampliaciones y la reutilización del código.

- Riesgos: Si surgen problemas potenciales durante el diseño, X.P sugiere

utilizar una pareja de desarrolladores para que investiguen y reduzcan al
máximo el riesgo que supone ese problema.

- Funcionalidad extra: Nunca se debe añadir funcionalidad extra al programa

aunque se piense que en un futuro será utilizada. Sólo 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

codificación de códigos ya creados sin alterar su funcionalidad. Refactorizar
supone revisar de nuevo estos códigos para procurar optimizar su
funcionamiento. Es muy común rehusar códigos ya creados que contienen
funcionalidades que no serán usadas y diseños obsoletos. Esto es un error
porque puede generar código completamente inestable y muy mal diseñado;
por este motivo, es necesario refactorizar cuando se va a utilizar código ya
creado.

IX Ciclo Página 7
 SISTEMA DE GESTION DE INGRESOS Y SALIDAS DE PRODUCTOS DE ALMACEN

3ª Fase: Codificación.
Como ya se dijo en la introducción, el cliente es una parte más del equipo
de desarrollo; su presencia es indispensable en las distintas fases de X.P.
A la hora de codificar una historia de usuario su presencia es aún más
necesaria. No olvidemos que los clientes son los que crean las historias
de usuario y negocian los tiempos en los que serán implementadas. Antes
del desarrollo de cada historia de usuario el cliente debe especificar
detalladamente lo que ésta hará y también tendrá que estar presente
cuando se realicen los test que verifiquen que la historia implementada
cumple la funcionalidad especificada.
La codificación debe hacerse ateniendo a estándares de codificación ya
creados. Programar bajo estándares mantiene el código consistente y
facilita su comprensión y escalabilidad.
Crear test que prueben el funcionamiento de los distintos códigos
implementados nos ayudará a desarrollar dicho código. Crear estos test
antes nos ayuda a saber qué es exactamente lo que tiene que hacer el
código a implementar y sabremos que una vez implementado pasará
dichos test sin problemas ya que dicho código ha sido diseñado para ese
fin. Se puede dividir la funcionalidad que debe cumplir una tarea a
programar en pequeñas unidades, de esta forma se crearán primero los
test para cada unidad y a continuación se desarrollará dicha unidad, así
poco a poco conseguiremos un desarrollo que cumpla todos los requisitos
especificados.
Como ya se comentó anteriormente, X.P opta por la programación en
pareja ya que permite un código más eficiente y con una gran calidad.
X.P sugiere un modelo de trabajo usando repositorios de código dónde
las parejas de programadores publican cada pocas horas sus códigos
implementados y corregidos junto a los test que deben pasar. De esta
forma el resto de programadores que necesiten códigos ajenos trabajarán
siempre con las últimas versiones. Para mantener un código consistente,
publicar un código en un repositorio es una acción exclusiva para cada
pareja de programadores.
X.P también propone un modelo de desarrollo colectivo en el que todos
los programadores están implicados en todas las tareas; cualquiera puede

IX Ciclo Página 8
 SISTEMA DE GESTION DE INGRESOS Y SALIDAS DE PRODUCTOS DE ALMACEN

modificar o ampliar una clase o método de otro programador si es

necesario y subirla al repositorio de código. El permitir al resto de los
programadores modificar códigos que no son suyos no supone ningún
riesgo ya que para que un código pueda ser publicado en el repositorio
tiene que pasar los test de funcionamiento definidos para el mismo.
La optimización del código siempre se debe dejar para el final. Hay que
hacer que funcione y que sea correcto, más tarde se puede optimizar.
X.P afirma que la mayoría de los proyectos que necesiten más tiempo
extra que el planificado para ser finalizados no podrán ser terminados a
tiempo se haga lo que se haga, aunque se añadan más desarrolladores y
se incrementen los recursos. La solución que plantea X.P es realizar un
nuevo "Release plan" para concretar los nuevos tiempos de publicación y
de velocidad del proyecto.
A la hora de codificar no seguimos la regla de X.P que aconseja crear test
de funcionamiento con entornos de desarrollo antes de programar.
Nuestros test los obtendremos de la especificación de requisitos ya que
en ella se especifican las pruebas que deben pasar las distintas
funcionalidades del programa, procurando codificar pensando en las
pruebas que debe pasar cada funcionalidad.
4ª Fase: Pruebas.
Uno de los pilares de la metodología X.P es el uso de test para comprobar
el funcionamiento de los códigos que vayamos implementando.
El uso de los test en X.P es el siguiente:
 Se deben crear las aplicaciones que realizarán los test con un
entorno de desarrollo específico para test.
 Hay que someter a tests las distintas clases del sistema omitiendo
los métodos más triviales.
 Se deben crear los test que pasarán los códigos antes de
implementarlos; en el apartado anterior se explicó la importancia
de crear antes los test que el código.
 Un punto importante es crear test que no tengan ninguna
dependencia del código que en un futuro evaluará. Hay que crear
los test abstrayéndose del futuro código, de esta forma

IX Ciclo Página 9
 SISTEMA DE GESTION DE INGRESOS Y SALIDAS DE PRODUCTOS DE ALMACEN

aseguraremos la independencia del test respecto al código que

evalúa.
 Como se comentó anteriormente los distintos test se deben subir
al repositorio de código acompañados del código que verifican.
Ningún código puede ser publicado en el repositorio sin que haya
pasado su test de funcionamiento, de esta forma, aseguramos el
uso colectivo del código (explicado en el apartado anterior).
 El uso de los test es adecuado para observar la refactorización.
Los test permiten verificar que un cambio en la estructura de un
código no tiene por qué cambiar su funcionamiento.
 Test de aceptación. Los test mencionados anteriormente sirven
para evaluar las distintas tareas en las que ha sido dividida una
historia de usuario. Para asegurar el funcionamiento final de una
determinada historia de usuario se deben crear "Test de
aceptación"; estos test son creados y usados por los clientes para
comprobar que las distintas historias de usuario cumplen su
cometido.
 Al ser las distintas funcionalidades de nuestra aplicación no
demasiado extensas, no se harán test que analicen partes de las
mismas, sino que las pruebas se realizarán para las
funcionalidades generales que debe cumplir el programa
especificado en la descripción de requisitos(«Fases» [sin fecha]).
Figura N° 1: Iteración dentro de la metodología XP

Fuente: («ProcesosdeSoftware - METODOLOGIA XP» [sin fecha])

IX Ciclo Página 10
 SISTEMA DE GESTION DE INGRESOS Y SALIDAS DE PRODUCTOS DE ALMACEN

4.4. Ventajas e inconvenientes de la metodología

- Ventajas:
o Da lugar a una programación sumamente organizada.
o Cuenta con una tasa de errores muy pequeña.
o Propicia la satisfacción del programador.
o Facilita los cambios.
o Permite ahorrar mucho tiempo y dinero.
o Puede ser aplicada a cualquier lenguaje de programación.
o El cliente tiene el control sobre las prioridades.
o Se hacen pruebas continuas durante el proyecto.
- Inconvenientes:
o Es recomendable emplearla solo en proyectos a corto plazo.
o En caso de fallar, las comisiones son muy altas.
o Requiere de un rígido ajuste a los principios de XP.
o Puede no siempre ser más fácil que el desarrollo
tradicional(«Metodología xp» 18:00:32 UTC).

5. Bibliografía
- Fases. [en línea], [sin fecha]. [Consulta: 15 mayo 2016]. Disponible en:
http://programacionextrema.tripod.com/fases.htm#primeraFase.

- Metodología xp. [en línea], 18:00:32 UTC. S.l. [Consulta: 15 mayo 2016].
Disponible en: http://es.slideshare.net/Piskamen/metodologa-xp.

- ProcesosdeSoftware - METODOLOGIA XP. [en línea], [sin fecha]. [Consulta:

15 mayo 2016]. Disponible en:
https://procesosdesoftware.wikispaces.com/METODOLOGIA+XP.

- Programación extrema. En: Page Version ID: 90952029, Wikipedia, la

enciclopedia libre [en línea], 2016. [Consulta: 15 mayo 2016]. Disponible en:
https://es.wikipedia.org/w/index.php?title=Programaci%C3%B3n_extrema&oldi
d=90952029.

IX Ciclo Página 11
 SISTEMA DE GESTION DE INGRESOS Y SALIDAS DE PRODUCTOS DE ALMACEN

6. Presupuesto

Materiales Cantidad Costos Costos Totales

Unitarios
1 Personal S/. 400.00
Honorarios 2 S/. 200.00 S/. 400.00

2 Equipos S/. 1,800.00

Computadoras 1 S/. 1,800.00 S/. 1,800.00
Escritorios 0 S/. 0.00 S/. 0.00
Impresora 0 S/. 0.00 S/. 0.00
Internet 1 S/. 0.00 S/. 0.00
Software 2 S/. 0.00 S/. 0.00

3 Viajes S/. 0.00

Viáticos 0 S/. 0.00 S/. 0.00
Transporte 0 S/. 0.00 S/. 0.00

TOTAL S/. 2,200.00

7. Materiales tecnológicos a utilizar

- Computadora :
RAM : 4GB
Disco Duro :500 GB
Mainboard: MSI h81m-p33
Tarjeta de RED inalámbrica PC-Link
Procesador Intel Core I3

- Software:
HTML 5, javascript(jquery), PHP 5 (Framework laravel),
CSS 3 (Framework Bootstrap)
MySQL Open Source

IX Ciclo Página 12
 SISTEMA DE GESTION DE INGRESOS Y SALIDAS DE PRODUCTOS DE ALMACEN

8. Cronograma de ejecución
Las prácticas se desarrollarán en 4 meses, desde inicios de mayo del 2016 a finales
de agosto 2016, realizando un total 656 hrs.
Los dias de la semana en que se desarrollará son de lunes a domingo realizando un
total 41 horas por semana.

Los horarios en que se desarrollará las prácticas son:

Hora
Dias
Inicio Termino
9 am 1 pm
Lunes
2 pm 6 pm
9 am 1 pm
Martes
2 pm 6 pm
9 am 1 pm
Miercoles
2 pm 6 pm
Jueves 3 pm 6 pm
Viernes 9 am 1 pm
Sabado 3 pm 6 pm
9 am 1 pm
Domingo
3 pm 6 pm

El cronograma de la realizacion de las prácticas sera:

DURACIÓN COMIENZO FIN

CRONOGRAMA DE PRÁCTICAS 112 días lun 28/09/15 lun 11/01/16
INICIACIÓN 7 días lun 02/05/16 lun 09/05/16
Coordinación de horarios con la empresa 3 día lun 02/05/16 mié 04/05/16
Explicación de problemática 2 día jue 05/05/16 vie 06/05/16
Listar los requerimientos de la empresa 2 día sáb 07/05/16 lun 09/05/16
PLANIFICACIÓN 11 días mar 10/05/16 dom 22/05/16
Maqueteo de la aplicación 5 días mar 10/05/16 sáb 14/05/16

IX Ciclo Página 13
 SISTEMA DE GESTION DE INGRESOS Y SALIDAS DE PRODUCTOS DE ALMACEN

Revisión del maqueteo y anotación de

3 día dom 15/05/16 mar 17/05/16
errores
Corrección de errores 2 días mié 18/05/16 jue 19/05/16
Retroalimentación del maqueteo 4 días jue 19/05/16 dom 22/05/16
EJECUCIÓN Y CONTROL 83 días lun 23/05/16 vie 12/08/16
Diseño de la base de datos 5 días lun 23/05/16 vie 27/05/16
Revisión de la base de datos 3 días sáb 28/05/16 lun 30/05/16
Desarrollo de la base de datos 10 días mar 31/05/16 jue 09/06/16
Presentación y revisión de la base de
1 día vie 10/06/16 vie 10/06/16
datos
Retroalimentación de la base de datos 5 días sáb 11/06/16 mié 15/06/16
Desarrollo de la aplicación en C# 40 días jue 16/06/16 dom 24/07/16
Presentación y revisión del proyecto en
1 día lun 25/07/16 lun 25/07/16
la empresa
Retroalimentación del proyecto 7 días mar 26/07/16 lun 01/08/16
Verificación de conexiones para el
1 día mar 02/08/16 mar 02/08/16
software
Realizar conexión para el proyecto 2 días mié 03/08/16 jue 04/08/16
Instalación del proyecto en la empresa 5 días vie 05/08/16 mar 09/08/16
Prueba del proyecto 3 días mié 10/08/16 vie 12/08/16
CIERRE 11 días sáb 13/08/16 lun 11/08/16
Listar datos de la empresa 5 días sáb 13/08/16 mié 17/08/16
Llenado de los datos en los software 3 días jue 18/08/16 sáb 20/08/16
Entrega del manual de usuario 3 día dom 21/08/16 mar 23/08/16

IX Ciclo Página 14