Facultad de Ingeniería de Sistemas, Cómputo y

Telecomunicaciones

TESIS PARA OPTAR EL TÍTULO DE INGENIERO DE SISTEMAS

Y CÓMPUTO

DESARROLLO DE UNA APLICACIÓN WEB PARA EL

REGISTRO Y SEGUIMIENTO DE PRÉSTAMO DE AUTOPARTES
ENTRE ALMACENES PARA EL ÁREA DE LOGÍSTICA DE LA
EMPRESA RAMLE CAR S.A.C.

Presentado por:

NOMBRE DEL ALUMNO

Lima - Perú

Mayo - 2016
 “Tesis presentada a la Universidad Inca
Garcilaso de la Vega Lima – Perú, para obtener
el Título de Ingeniero de Sistemas y Cómputo”

Orientador: Orientador

Co-orientador: (si lo hubiera)

Orientador: Mg. Raúl Díaz Rojas.

© Nombre del Alumno, 2016.

Todos los derechos reservados.

ii
 DEDICATORIA

Este trabajo está dedicado mi familia a todos

ellos sin excepción por estar siempre
apoyándome especialmente a mi madre
Victoria el agradecimiento siempre eterno.

3
 AGRADECIMIENTOS

A mis padres y hermano que hicieron todo el esfuerzo posible para que termine mis
estudios, apoyándome siempre en las buenas y en las malas.

A todos mis tíos, en especial a mi tío Carlos y Alberto que siempre estuvieron presente
orientándome y tratando de solucionar los problemas que se me presentaban en la
universidad.

Al profesor Mg. Raúl Díaz Rojas, por su orientación y dedicación para que este trabajo
cumpla con los objetivos trazados.

A todos mis compañeros de la universidad por su ayuda y apoyo constante, y por

darme la oportunidad de compartir nuestros triunfos hasta el final y de aprender el
verdadero valor de la amistad.

A todas aquellas personas que indirectamente me ayudaron para culminar este trabajo
y que muchas veces constituyen un invalorable apoyo.

Y por encima de todo doy gracias a Dios.

 ÍNDICE GENERAL

LISTA DE CUADROS...................................................................................... IX

LISTA DE FIGURAS ......................................................................................... X

RESUMEN .................................................................................................. XIII

ABSTRACT .................................................................................................. XIV

CAPÍTULO 1: INTRODUCCIÓN.................................................................... 1

1.1 Planteamiento del Problema................................................................ 1

1.1.1 Descripción de la realidad problemática o antecedentes del problema ..........1
1.1.2 Definición del Problema............................................................................2

1.2 Objetivos.............................................................................................. 2
1.2.1 Objetivo principal.....................................................................................2
1.2.2 Objetivos secundarios ..............................................................................3

1.3 Justificación ......................................................................................... 3

1.4 Alcances ............................................................................................... 4

1.5 Estrategia metodológica ...................................................................... 5

1.5.1 Revisión bibliográfica ...............................................................................5
1.5.2 Estudio del problema ...............................................................................5
1.5.3 Estudio de la metodología ........................................................................6
1.5.4 Desarrollo de la propuesta........................................................................6
1.5.5 Validación de la propuesta........................................................................6
1.5.6 Desarrollo de la plataforma tecnológica .....................................................6

1.6 Presentación del resto del informe ...................................................... 7

CAPÍTULO 2: MARCO CONCEPTUAL ........................................................... 9

2.1 Almacén ............................................................................................... 9

2.2 Tipos de Almacén ............................................................................... 10

2.3 Actividades Fundamentales en el Almacén. ....................................... 11
2.3.1 Proceso de Recepción ............................................................................ 11
2.3.2 Proceso de Almacenamiento ................................................................... 12
2.3.3 Proceso de Despacho ............................................................................. 12

2.4 Control de Inventario ........................................................................ 13

2.5 Seguimiento de préstamos ................................................................ 15

2.6 Responsabilidades en el almacén ...................................................... 16

2.6.1 Del Supervisor ....................................................................................... 16
2.6.2 Del Responsable .................................................................................... 17

2.7 Arquitectura y Diseño de Sistema de Información Web .................... 17

2.7.1 Ventajas y Desventajas de una Aplicación web ......................................... 19

2.8 Framework MVC................................................................................. 20

2.8.1 El Framework Spring MVC ...................................................................... 21

CAPÍTULO 3: MÉTODOS PARA LA CONSTRUCCIÓN DE LA SOLUCIÓN

TECNOLÓGICA ........................................................................................... 23

3.1 Metodologías / Modelo / Algoritmos ................................................. 23

3.1.1 Proceso Unificado Rational RUP .............................................................. 23
3.1.1.1 Procesos dirigidos por casos de uso ................................................. 23
3.1.1.2 Proceso iterativo e incremental ........................................................ 24
3.1.1.3 Estructura del Proceso .................................................................... 25
3.1.1.4 Modelado del negocio ..................................................................... 26
3.1.1.5 Requisitos ...................................................................................... 26
3.1.1.6 Análisis y diseño ............................................................................. 27
3.1.1.7 Implementación ............................................................................. 28
3.1.1.8 Pruebas ......................................................................................... 28
3.1.1.9 Despliegue..................................................................................... 28
3.1.2 Metodología ICONIX .............................................................................. 29
3.1.2.1 Fases de iconix............................................................................... 30
3.1.2.2 Resumen de iconix ......................................................................... 32
3.1.3 Metodología SCRUM............................................................................... 33
3.1.3.1 Componentes de scrum................................................................... 34
3.1.3.2 Los artefactos de scrum .................................................................. 35
3.2 Evaluación comparativa entre las metodologías / modelos /
algoritmos .................................................................................................... 35
3.2.1 Criterios de evaluación ........................................................................... 35

CAPÍTULO 4: APORTE TEÓRICO ............................................................... 39

4.1 Aplicación de la metodología / modelo / algoritmos al problema ..... 39

4.1.1 Modelado del negocio ............................................................................ 39
4.1.1.1 Glosario de términos ....................................................................... 39
4.1.1.2 Diagrama de casos de uso del negocio ............................................. 41
4.1.1.3 Descripción de alto nivel de casos de uso del negocio ........................ 41
4.1.2 Requerimiento....................................................................................... 43
4.1.2.1 Determinar requerimientos .............................................................. 43
4.1.2.2 Encontrar actores y casos de uso ..................................................... 46
4.1.3 Casos de uso del sistema web ................................................................ 47
4.1.3.1 Descripción de alto nivel de casos de uso del sistema ........................ 48
4.1.3.2 Priorizar casos de uso ..................................................................... 52
4.1.3.3 Detallar casos de uso ...................................................................... 53
4.1.4 Diagrama de clases................................................................................ 56
4.1.5 Prototipos ............................................................................................. 56

CAPÍTULO 5: APORTE PRÁCTICO.............................................................. 59

5.1 Diseño de la herramienta tecnológica................................................ 59

5.1.1 Casos de uso del negocio ....................................................................... 59
5.1.1.1 Descripción en detalle de casos de uso del negocio ........................... 59
5.1.2 Casos de uso del sistema ....................................................................... 64
5.1.2.1 Descripción en detalle de casos de uso del sistema ........................... 64
5.1.2.2 Diagrama de secuencia de casos de uso del sistema.......................... 73
5.1.2.3 Diagrama de actividades de casos de uso del sistema........................ 78
5.1.3 Diagrama de clases................................................................................ 83
5.1.4 Diagrama de componentes ..................................................................... 84
5.1.5 Diagrama de despliegue ......................................................................... 85
5.1.6 Modelo físico de la base de datos ............................................................ 86
5.1.7 Interfaces de usuario ............................................................................. 93

CAPÍTULO 6: CONCLUSIONES Y TRABAJOS FUTUROS............................ 103

6.1 Conclusiones .................................................................................... 103

vii
6.2 Trabajos futuros .............................................................................. 103

REFERENCIAS BIBLIOGRÁFICAS ............................................................... 105

ANEXO I ......................................................................................................... A

ANEXO II ........................................................................................................ C

ANEXO III ...................................................................................................... E

ANEXO IV ....................................................................................................... F

88
 Lista de cuadros

Tabla 3.1 Evaluación de metodología de desarrollo de software [Fuente: Propia] ...... 37

Tabla 4.1 Realizar pedido de producto [Fuente: Propia]. ......................................... 41

Tabla 4.2 Controlar producto [Fuente: Propia]........................................................ 42

Tabla 4.3 Distribuir producto [Fuente: Propia]. ....................................................... 42

Tabla 4.4 Solicitar producto [Fuente: Propia].......................................................... 42

Tabla 4.5 Realizar venta [Fuente: Propia]. ............................................................. 42

Tabla 4.6 Controlar préstamo de autopartes [Fuente: Propia]. ................................. 49

Tabla 4.7 Registrar préstamo de autopartes [Fuente: Propia]. ................................. 49

Tabla 4.8 Mantener préstamo de autopartes [Fuente: Propia]................................. 49

Tabla 4.9 Controlar stock préstamo de autopartes [Fuente: Propia].......................... 50

Tabla 4.10 Ingreso al sistema [Fuente: Propia]....................................................... 50

Tabla 4.11 Generar orden de devolución [Fuente: Propia]. ...................................... 50

Tabla 4.12 Registrar Usuario [Fuente: Propia]. ....................................................... 51

Tabla 4.13 Mantener información de responsables [Fuente: Propia]. ........................ 51

Tabla 4.14 Emitir reporte [Fuente: Propia]. ............................................................ 51

Tabla 4.15 Relación de requisitos funcionales y casos de uso [Fuente: Propia] .......... 52

Tabla 4.16 Priorizar casos de uso [Fuente: Propia].................................................. 53

Tabla 5.1 Tabla empleado [Fuente propia]. ............................................................ 87

Tabla 5.2 Tabla tipo usuario [Fuente propia]. ......................................................... 87

Tabla 5.3 Tabla usuario [Fuente propia]................................................................. 87

Tabla 5.4 Tabla préstamo [Fuente propia].............................................................. 88

Tabla 5.5 Tabla detalle de préstamo [Fuente propia]. ............................................. 88

Tabla 5.6 Tabla autoparte [Fuente propia]. ............................................................ 89

Tabla 5.7 Tabla tipo de autoparte [Fuente propia]. ................................................. 89

Tabla 5.8 Tabla almacén [Fuente propia]. .............................................................. 90

9
 Lista de figuras

Figura 2.1 Proceso de almacenamiento [Fuente:

http://www.aidima.es/gdp/documentos/Documentos/fpiquer_SGAvWeb.pdf]............ 10

Figura 2.2 Control de Inventario [Fuente: Jorge Sierra y Acosta].............................. 14

Figura 2.3 Seguimiento de préstamo de autopartes [Fuente: Propia] ........................ 16

Figura 2.4 Arquitectura de Sistema de Información Web [Fuente:

http://dspace.ucuenca.edu.ec/bitstream/123456789/4303/1/tesis.pdf]..................... 18

Figura 2.5 El Framework Spring MVC [Fuente:

https://riunet.upv.es/bitstream/handle/10251/16951/Memoria.pdf?sequence=1] ...... 21

Figura 3.1 Los casos de uso integran el trabajo [Fuente:

http://cybertesis.urp.edu.pe/urp/2010/chavez_vh/pdf/chavez_vh-TH.3.pdf] ............. 24

Figura 3.2 Una iteración RUP [Fuente:

http://cybertesis.urp.edu.pe/urp/2010/chavez_vh/pdf/chavez_vh-TH.3.pdf]. ............ 25

Figura 3.3 Esfuerzo en actividades según la fase del proyecto [Fuente:

http://cybertesis.urp.edu.pe/urp/2010/chavez_vh/pdf/chavez_vh-TH.3.pdf] ............. 25

Figura 3.4 Estructura de RUP [Fuente:

http://cybertesis.urp.edu.pe/urp/2010/chavez_vh/pdf/chavez_vh-TH.3.pdf]. ............ 26

Figura 3.5 Trazabilidad entre artefactos [Fuente:

http://cybertesis.urp.edu.pe/urp/2010/chavez_vh/pdf/chavez_vh-TH.3.pdf]. ............ 29

Figura 3.6 Ejemplo de Ficha de Casos de Uso [Fuente:

http://ima.udg.edu/~sellares/EINF-ES2/Present1011/MetodoPesadesICONIX.pdf]..... 31

Figura 3.7 Flujo entre objetos Frontera, Control y Entidad [Fuente:

http://ima.udg.edu/~sellares/EINF-ES2/Present1011/MetodoPesadesICONIX.pdf]..... 31

Figura 3.8 Resumen de la Metodología ICONIX [Fuente:

http://ima.udg.edu/~sellares/EINF-ES2/Present1011/MetodoPesadesICONIX.pdf]..... 32

Figura 3.9 Visión General de la Metodología SCRUM [Fuente:

http://www.scrumprimer.org/primers/es_scrumprimer20.pdf] ................................. 34
Figura 4.1 Diagrama de casos de uso del negocio [Fuente: Propia]. ......................... 41

Figura 4.2 Caso de uso controlar préstamo autopartes [Fuente: Propia]. .................. 47

Figura 4.3 Caso de uso ingreso al sistema [Fuente: Propia]. .................................... 47

Figura 4.4 Caso de uso generar orden devolución [Fuente: Propia]. ......................... 48

Figura 4.5 Caso de uso registrar usuario [Fuente: Propia]. ...................................... 48

Figura 4.6 Caso de uso mantener información de responsables [Fuente: Propia]. ...... 48

Figura 4.7 Caso de uso emitir reporte [Fuente: Propia]. .......................................... 48

Figura 4.8 Diagrama de Casos de Uso de la Aplicación web para registrar y dar
seguimiento a productos prestados entre almacenes [Fuente Propia]. ......................
55

Figura 4.9 Diagrama de clases inicial [Fuente Propia]. ............................................. 56

Figura 4.10 Prototipo acceso al sistema web [Fuente Propia]. .................................. 56

Figura 4.11 Prototipo bienvenida al sistema web [Fuente Propia]. ............................ 57

Figura 4.12 Prototipo mantenimiento de autopartes [Fuente Propia]. ....................... 57

Figura 4.13 Prototipo registrar préstamo de autopartes [Fuente Propia]. .................. 58

Figura 4.14 Prototipo mantener préstamo de autopartes [Fuente Propia].................. 58

Figura 5.1 Diagrama de Secuencia Registrar Préstamo de Autopartes [Fuente Propia].

.......................................................................................................................... 73

Figura 5.2 Diagrama de Secuencia Mantener Préstamo de Autopartes [Fuente Propia].

.......................................................................................................................... 74

Figura 5.3 Diagrama de Secuencia Controlar Stock de Préstamo de Autopartes [Fuente

Propia]................................................................................................................ 75

Figura 5.4 Diagrama de Secuencia Ingresar al Sistema [Fuente Propia]. ................... 75

Figura 5.5 Diagrama de Secuencia Generar Orden de Devolución [Fuente Propia]. .... 76

Figura 5.6 Diagrama de Secuencia Registrar Usuario [Fuente Propia]. ...................... 76

Figura 5.7 Diagrama de Secuencia Mantener Información de Responsables [Fuente

Propia]................................................................................................................ 77

Figura 5.8 Diagrama de Secuencia Emitir Reporte [Fuente Propia]. .......................... 77

Figura 5.9 Diagrama de Actividades Registrar Préstamo de Autopartes [Fuente Propia]
.......................................................................................................................... 78

Figura 5.10 Diagrama de Actividades Mantener Préstamo de Autopartes [Fuente

Propia]................................................................................................................ 79

Figura 5.11 Diagrama de Actividades Controlar Stock de Préstamo de Autopartes

[Fuente Propia].................................................................................................... 80

Figura 5.12 Diagrama de Actividades Ingresar al Sistema [Fuente Propia]. ............... 80

Figura 5.13 Diagrama de Actividades Generar Orden de Devolución [Fuente Propia].. 81

Figura 5.14 Diagrama de Actividades Registrar Usuario [Fuente Propia].................... 81

Figura 5.15 Diagrama de Actividades Mantener Información de Responsables [Fuente

Propia]................................................................................................................ 82

Figura 5.16 Diagrama de Actividades Emitir Reporte [Fuente Propia]........................ 82

Figura 5.17 Diagrama de clases [Fuente Propia]. .................................................... 83

Figura 5.18 Diagrama de componentes [Fuente Propia]. ......................................... 84

Figura 5.19 Diagrama de despliegue [Fuente Propia]. ............................................. 85

Figura 5.20 Implementación de la Base de Datos [Fuente Propia]. ........................... 86

Figura 5.21 Login de Usuario [Fuente Propia]. ........................................................ 93

Figura 5.22 Acceso al sistema [Fuente Propia]........................................................ 93

Figura 5.23 Mantenimiento de autopartes [Fuente Propia]....................................... 94

Figura 5.24 Registrar préstamo de autopartes [Fuente Propia]................................. 95

Figura 5 25 Búsqueda y selección de autoparte para préstamo [Fuente Propia]......... 96

Figura 5.26 Autopartes agregados a lista de préstamo [Fuente Propia]. .................... 97

Figura 5.27 Mantenimiento de préstamo de autopartes [Fuente Propia].................... 98

Figura 5.28 Búsqueda de préstamo de autopartes [Fuente Propia]. .......................... 99

Figura 5.29 Reporte de préstamo de autopartes [Fuente Propia]............................ 100

Figura 5.30 Búsqueda de préstamo de autopartes [Fuente Propia]. ........................ 100

Figura 5.31 Reporte de préstamo de autopartes por fecha [Fuente Propia]. ............ 101

Figura 5.32 Búsqueda autopartes por almacén [Fuente Propia].............................. 102

xii
 RESUMEN

RAMLE CAR S.A.C. es una empresa cuya actividad principal es la venta de partes,
piezas y accesorios eléctricos para vehículos, la empresa RAMLE CAR S.A.C maneja una
gran cantidad de autopartes en stock en sus diferentes almacenes, es por ello que la
empresa se ve en la necesidad de desarrollar y agilizar los procesos que se realizan en
dicho sector empresarial. El principal problema es el registro y seguimiento de los
productos que se trasladan a manera de préstamo hacia el almacén de otra empresa
que se dedica al mismo rubro de venta de autopartes, por estas razones la aplicación
web desarrollada permite efectuar el registro y seguimiento de préstamos de modo
sistematizado agilizando el proceso, reduciendo los tiempos de registro y manteniendo
un control estricto de los productos pertenecientes a un determinado almacén. Para el
desarrollo de la Aplicación Web se empleó el lenguaje de programación Java a través
del IDE Eclipse, Oracle SQL Developer como base de datos, Framework SPRING MVC y
como metodología RUP. La aplicación web incluye los módulos de registro de
autopartes, registro de préstamos de autopartes, mantenimiento de autopartes, y un
módulo que permite ver reportes de autopartes prestadas.

Palabras Claves

Aplicación web, almacén, autopartes, préstamo de autopartes.

131
313
 ABSTRACT

RAMLE CAR S.A.C. is a company whose main activity is the sale of parts and electrical
accessories for vehicles, the company Ramle CAR SAC handles a lot of auto parts in
stock at different stores, which is why the company is the need to develop and
streamline processes performed in that business sector. The main problem is the
recording and tracking of products moving by way of loan to store another company
dedicated to the same category of selling auto parts, for these reasons the Web
Application developed can make the recording and tracking loans so systematic
streamlining the process, reducing registration times and maintaining strict control of
products belonging to a determined store. For the development of the Web Application
Java programming language is used through the Eclipse IDE, Oracle SQL Developer as
a database, MVC and Spring framework as RUP. The web application modules will
record auto parts, auto loan registration, maintenance parts, and a module that allows
you to view reports borrowed parts.

Keywods
web application, store , auto parts, auto parts loan.

141
4
 CAPÍTULO 1: INTRODUCCIÓN

1.1 Planteamiento del Problema

1.1.1 Descripción de la realidad problemática o antecedentes del problema

RAMLE CAR S.A.C se encuentra en el mercado de venta de partes, piezas y accesorios

para vehículos desde Junio del 2005, desde entonces ha realizado sus actividades de
venta de productos y control de stock de forma manual, en este punto podemos
mencionar que las autopartes que adquiere la empresa están en la categoría de parte
eléctrica para vehículos; hasta que en el 2008 adquirió su sistema para el control de
sus procesos, pero debido a que los dueños de la empresa están asociados con otra
empresa del mismo rubro llamada RC S.A.C, se realizan muchas veces los préstamos
de las autopartes hacia los almacenes de la empresa RC para ser vendidos en sus
tiendas, con un volumen tan grande de autopartes trasladados a otros puntos, ocurren
incidencias como la pérdida o desaparición de la mercadería, esta desaparición puede
ocurrir por el siguiente motivo, puede ser producto de un manejo descuidado o de
actos premeditados malintencionados por parte de los trabajadores del almacén de
origen; este extravió de autopartes le genera a la empresa RAMLE CAR S.A.C perdidas
mensualmente considerables. Otro inconveniente es que no existen reportes sobre el
registro de préstamos entre almacenes y no hay manera de hacer un seguimiento
minucioso, por lo que estos factores han llevado a la empresa a requerir con urgencia
una aplicación web que registre dichos préstamos para de esta forma mantener
actualizado el stock y la información concerniente sobre las autopartes prestadas, cabe
mencionar que este proceso se ejecuta en la actualidad de manera manual, y tiene un
conjunto de procesos que se ejecutan de la siguiente manera:

Primero: el empleado del almacén destino (almacén de donde se solicita las autopartes
a prestar) se acerca al almacén origen (de donde se prestan las autopartes), con una
solicitud sobre la cantidad de autopartes que se requieren.

Segundo: el empleado del almacén origen, evalúa si las autopartes solicitadas están en
stock disponible (las autopartes tanto en almacén origen como almacén destino deben
existir y tener el mismo código) y la prioridad de las autopartes, si es así se efectúa el
préstamo.

1
Tercero: el empleado del almacén origen tiene la facultad previa coordinación con
gerencia general de brindar o no ciertas autopartes como préstamo, ya sea por su
carácter de urgente o porque su stock es limitado en número.

Cuarto: se genera una orden sobre el préstamo de las autopartes, con lo cual se
acepta la solicitud indicada.

Quinto: el tramite sobre el envió por préstamo del almacén de origen al almacén
destino es inmediato, no pudiendo demorarse más de 8 horas.

Sexto: el trámite por devolución de los préstamos se ejecuta, de acuerdo a la

necesidad física de las autopartes para la venta en la empresa RAMLE CAR, también
puede ser por el tiempo estimado de devolución no siendo mayor de una semana.

Todo este proceso produce pérdida de tiempo y costo, empleando muchas veces
técnicas que son inadecuadas para el manejo de los productos por ejemplo: anotar los
préstamos en un cuaderno, anotarlos en una pizarra, etc. Este método de trabajo es
lento e ineficiente y genera inconvenientes y problemas en el seguimiento de las
autopartes prestadas, es por ello que para implementar esta aplicación web se ha
recopilado información sobre todas las actividades que se llevan a cabo durante la fase
de préstamo de autopartes, todo esto facilitara el seguimiento de préstamos de modo
que se harán más rápidos y los empleados encargados del almacén podrán controlar
de forma estricta las entradas y salidas de las autopartes de un almacén a otro,
manteniendo un inventario actualizado constantemente.

1.1.2 Definición del Problema

No existe un mecanismo de registro y seguimiento del estado de los productos que se

prestan del almacén origen al almacén destino, lo que genera un control deficiente de
la información, la cual es registrada en hojas y cuadernos a mano y otros en archivos
Excel, generando insatisfacción en la gerencia de la empresa.

1.2 Objetivos

1.2.1 Objetivo principal

Desarrollar una aplicación web, que permita el registro y seguimiento del estado de las
autopartes prestados entre almacenes, para la empresa RAMLE CAR S.A.C.
1.2.2 Objetivos secundarios

 Proporcionar información actualizada de los productos en calidad de préstamo.

 Agilizar el proceso de préstamos de autopartes.

 Analizar los requerimientos necesarios para el desarrollo de la aplicación web.

 Emplear las tecnologías de información adecuadas para la aplicación.

1.3 Justificación

Entre los principales beneficios para la empresa podemos mencionar:

 la aplicación web registra y realiza el mantenimiento a las autopartes prestadas,

así como la generación de reportes detallados que indiquen la cantidad de
productos que han sido prestados a otro almacén.

 La aplicación web permite mejorar la relación entre el personal de logística y de

ventas ya que se mediante el registro de préstamos, se conoce la cantidad
exacta de stock de autopartes que el área de venta solicita.

 Los empleados del almacén de RAMLE CAR S.A.C reducen el impacto de los
tiempos de atención en la solicitud de préstamos de autopartes hacia el
almacén destino ubicado en la empresa RC S.A.C.

 Se minimiza el riesgo en la perdida de los productos cuando son transferidos de

un almacén a otro.

 Se facilita y agiliza aquellos procesos que consumen más esfuerzo y dedicación

en cuanto a la búsqueda y stock de las autopartes prestadas.

 Se incrementa la eficiencia y productividad laboral de los empleados del área de

almacén.

 Debido a que toda la información es digital los archivos físicos que antes se
generaban en cuadernos o Excel desaparecen, siendo el tiempo de registro más
rápido.

 Debido a que es una aplicación web, la gerencia de RAMLE CAR podrá conocer
en todo momento y en cualquier lugar la información actualizada sobre el
registro y seguimiento de los productos préstamos.
1.4 Alcances

En la creación de la aplicación web para el control de préstamo de productos entre

almacenes, se establece lo siguiente:

 La presente implementación de la aplicación web se desarrolla para la empresa

RAMLE CAR SAC. En el área de logística, Ubicada en la ciudad de Lima, distrito de
Cercado de Lima.

 La aplicación web es utilizada por los usuarios que son los empleados del almacén
de la empresa RAMLE CAR SAC.

 Se realiza el estudio sobre la problemática de préstamos de autopartes entre

almacenes, ocurrida en la empresa RAMLE CAR S.A.C.

 Se realiza el estudio de la metodología RUP para el desarrollo del software de la

aplicación web.

 Adaptación de la metodología RUP para brindar la solución a la problemática,

proporcionando artefactos que nos permita cumplir con los objetivos.

 Análisis y Diseño de la aplicación web para el préstamo de autopartes entre

almacenes, con la metodología RUP y plataforma Web.

Respecto al aplicativo:

 La aplicación web se ejecuta en sistema operativo Windows XP y versiones

superiores.

 La aplicación web cuenta con un módulo de seguridad de autenticación de usuario.

 La aplicación web cuenta con un módulo de registro de los préstamos de las

autopartes.

 La aplicación web cuenta con un módulo de mantenimiento de los préstamos de

autopartes.

 La aplicación web tiene un módulo de vistas de reportes en pdf utilizando ITEXT,

lo cual mostrara el seguimiento de las autopartes prestadas del almacén origen a
destino.

 Como IDE para el desarrollo de la programación se utiliza ECLIPSE IDE.

 La base datos para la aplicación web es ORACLE SQL DEVELOPER.

 El Framework utilizado para la aplicación web es SPRING FRAMEWORK ya que
contiene los niveles de; modelo, vista y controlador.

 Como contenedor web se emplea APACHE TOMCAT 7.0 para el soporte de Servlet
y JSP.

1.5 Estrategia metodológica

La estrategia metodológica para la implementación de la aplicación web para el control

de préstamos de autopartes entre almacenes estará conformada por los siguientes
hitos:

1.5.1 Revisión bibliográfica

En este punto realizaremos las siguientes actividades:

 Visitas a Bibliotecas Privadas como las de las universidades particulares como la

UIGV, PUCP, U.DE LIMA, ESAN, UNMS, UNFV, USIL, etc
 Búsqueda en INTERNET en Páginas WEB referidas a sistemas web de control de
inventario, páginas sobre metodologías de control de almacén y otros, Revistas
Online, Tesis, etc.
 Revisión de la documentación interna de la compañía con respecto al manejo de los
prestamos de autopartes entre almacenes.
 Investigación de cursos, talleres sobre control y seguimiento de préstamo de
autopartes.

1.5.2 Estudio del problema

Para el estudio del problema se realizan los siguientes pasos:

 Establecer los objetivos tanto principal, como secundarios de la problemática de

préstamos de autopartes entre almacenes.

 Se identifican a los usuarios tanto principales como secundarios, que son la fuente
de conocimiento sobre los procesos que se llevan a cabo dentro del almacén de
autopartes.

 Se realiza el estudio de cuál es el flujo del proceso de préstamo, desde que inicia el
préstamo de la autoparte hasta donde culmina con su devolución.

 Se realizan encuestas cuestionarios y entrevistas a los empleados del almacén para

conocer el entorno y captar los requerimientos principales.
1.5.3 Estudio de la metodología

Se considera el uso de una metodología popular de desarrollo de software, los

candidatos son: RUP, ICONOX, SCRUM. Se evalúa mediante criterios especiales que
metodología se adapta mejor a la empresa, para esto se realiza un estudio previo de
las metodologías indicadas.

1.5.4 Desarrollo de la propuesta

Para el desarrollo de la propuesta de solución, se realizan las siguientes actividades:

 Se estudia otros casos similares al registro y seguimiento de préstamos de

autopartes entre almacenes, para así facilitar el manejo del trabajo.

 Se efectúa la revisión de tecnologías de información actual referida para la

implementación de la aplicación web, sobre todo aquellas herramientas comerciales
que permitan enriquecer la propuesta tecnológica que se implementa con la
aplicación web.

 Se especifica una propuesta de solución donde se define y justifica el problema a

resolver, y se plantea la solución, para la satisfacción del personal de almacén.

1.5.5 Validación de la propuesta

Para validar la propuesta realizamos lo siguiente:

 Se llevan a cabo reuniones con los usuarios con la finalidad de validar la solución
propuesta, ya que se debe satisfacer las necesidades directamente de los usuarios
de la aplicación web, así como verificar que propuesta brinde los resultados
necesarios a la empresa RAMLE CAR.

 Se realizan consultas al asesor del trabajo, con la finalidad de establecer una

evaluación objetiva sobre la propuesta realizada.

 Establecer conclusiones y recomendaciones una vez validada la propuesta se

deberá escribir todas las conclusiones y recomendaciones para la empresa.

1.5.6 Desarrollo de la plataforma tecnológica

 Se establece en primera instancia el modelo del negocio para conocer la necesidad

del porque implementar la aplicación web.
 Se estiman los tiempos y los recursos según otros trabajos similares con la finalidad
de aprovechar experiencias anteriores.

 Se definen los requisitos de la aplicación web que deben ser satisfechos en la

implementación, en ella se tendrá que establecer reuniones con los interesados, en
este caso la gerencia de la empresa RAMLE CAR y los empleados del almacén
quienes conocen los procesos internos en la realización de préstamos de productos
entre almacenes.

 Se definen los requisitos no funcionales de la aplicación web como la usabilidad,

portabilidad, mantenibilidad, entre otros.

 Se define una lista o matriz de requisitos funcionales y no funcionales para la

aplicación web.

 Se desarrolla un glosario de términos con la colaboración de los empleados del área

de logística.

 Se prioriza en detalle los casos de uso a implementar para elaborar el diseño de

diagrama de caso de uso de la aplicación web.

 Se define el diagrama de componentes para la aplicación web.

 Se establece todos los diagramas de secuencia para los casos de uso priorizados.

 Se elabora del diseño de la base de datos de la aplicación web.

 Se define como se conforma el modelo de despliegue de la aplicación web.

 Elaboración de las interfaces de la aplicación web, interfaz de login, interfaz de

registro de productos, interfaz de mantenimiento de productos, interfaz de registro
de préstamos, interfaz de reportes de préstamos.

 Se ejecutan pruebas en la aplicación web, para verificar que se cumplan los

requisitos funcionales y no funcionales de la aplicación web.

 Se coordinara con la gerencia a fin de efectuar el mantenimiento y ampliación

futura de la aplicación web, de acuerdo a futuras metas de la empresa.

1.6 Presentación del resto del informe

A partir del Capítulo 2 de la presente tesis, referida al Marco Conceptual, se describen

conceptos, definiciones sobre Almacén, Préstamos, Aplicación Web los cuales son base
para el desarrollo del presente trabajo.
En el Capítulo 3 se presentan los Métodos para la el desarrollo de software candidatos
para este proyecto. Se efectúa una comparación de metodologías de desarrollo de
software a fin de evaluarlas y decidir por la que mejor se adapte a nuestro proyecto.

El Capítulo 4 muestra el Aporte Teórico que se realiza en la presente tesis, de cómo se

aplica el modelo, algoritmo o método para solucionar la problemática planteada.

El Capítulo 5 Aporte Práctico es la sección donde se detalla el diseño de la solución

informática planteada en la tesis.

Finalmente en la última parte del trabajo nos referimos a las Conclusiones y Trabajos
Futuros, nos muestra las conclusiones a las que he arribado producto del trabajo
realizado y aquellos futuros trabajos que podrían ayudar a mejorar la solución
implementada y finalmente se encontraran todas las Referencias Bibliográficas
utilizadas para el desarrollo de esta tesis.
 CAPÍTULO 2: MARCO CONCEPTUAL

2.1 Almacén

Este eslabón de la cadena logística se ha convertido en uno de los más importantes,

consecuencia de su incidencia en el servicio al cliente y en los costes operativos de la
empresa, para empezar nuestro camino en este manual vamos a realizar una breve
definición del concepto de almacenaje:

Función de la logística que permite mantener cercanos los productos a los distintos
mercados, al tiempo que puede ajustar la producción a los niveles de la demanda y
facilita el servicio al cliente. (Iglesias, 2012, pág. 3).

El Almacén es una instalación o parte de ésta, destinada al almacenamiento,

manipulación y conservación de mercancías, equipada tecnológicamente para estos
fines.

Los almacenes aunque son un mal necesario (se inmovilizan recursos) brindan algunas
ventajas, ya que:

 Permiten una mejor organización en la distribución de las mercancías.

 Posibilitan una correcta conservación de los productos.

 Posibilitan una utilización racional de la técnica (con la concentración de los

almacenes).

 En algunos casos son parte del proceso productivo (para el añejamiento de

bebidas). (Hernandez Muñoz, 2012, pág. 27).
 Figura 2.1 Proceso de almacenamiento [Fuente:
http://www.aidima.es/gdp/documentos/Documentos/fpiquer_SGAvWeb.pdf].

2.2 Tipos de Almacén

La empresa tiene que analizar y valorar el tipo de almacén que necesita en función de
diferentes criterios, no solo teniendo en cuenta aspectos relacionados con la cadena
logística, esta es una decisión estratégica y en ella se deben ver involucrados todos los
departamentos de la empresa, entre los tipos de almacén se tienen:

a. Almacén de materias primas.- Los que suministran los productos que un proceso
productivo ha de transformar. Normalmente se encuentran próximos a los talleres o
centros de producción.

b. Almacén de productos semielaborados.- Suelen estar situados entre dos talleres y

su proceso productivo no está enteramente finalizado.

c. Almacén de piezas de recambio.- Pueden estar segregados de los de productos

acabados, si bien las piezas o conjuntos almacenados también están destinados a la
venta.

d. Almacén de materias auxiliares.- Los que suministran al proceso productivo

materiales para que éste se pueda llevar a cabo.
e. Almacén de productos terminados.- Son los que más nos interesan dentro del
campo de la logística de distribución que estamos estudiando. Los productos
almacenados están destinados a ser vendidos.

f. Almacén convencional.- Sistema clásico de almacenamiento con estanterías de

acceso manual servidas por carretillas.

g. Almacén en bloque.- Sistema de almacenamiento sin ningún tipo de estructura de

soporte, los pallets cargados se apilan uno sobre otro.

h. Almacén compacto.- Sistema de almacenamiento, cuya característica principal, es la

de no tener espacios entre pasillos, pudiendo introducirse las carretillas dentro de
las estanterías.

i. Almacén dinámico.- Sistema de almacenamiento móvil. Formados por bloques

compactos, sin pasillos. Su principal característica es el deslizamiento de los palets
desde el punto de entrada a la estantería, hasta el de salida. Sistema FIFO.

j. Almacén móvil.- Sistema de almacenamiento que se caracteriza por el movimiento

de toda la estructura de estanterías. Esto permite abrir un pasillo entre cualquiera
de ellas, manteniendo el resto compacto.

k. Almacén semiautomático y automático.- Estos sistemas se caracterizan por el

movimiento automatizado de las zonas de almacenamiento. Ello permite el acceso a
cualquier producto almacenado desde el punto de control.

l. Almacén autoportante.- Estos almacenes se caracterizan por la doble función de las

estanterías. Una es la de almacenar los diferentes productos, y la otra es la de
hacer de soporte del edificio. (Iglesias, 2012, págs. 9-14).

2.3 Actividades Fundamentales en el Almacén.

2.3.1 Proceso de Recepción

 Descarga de los productos de los medios de transporte: En este proceso el

primer paso es la recepción de los documentos del transportista, los cuales
pueden ser mediante una factura o conduce, seguido al mismo se procede a la
descarga de los productos mediante equipos o manual.

 Operación de verificación y conteo de los productos: Se puede realizar por

bultos o al detalle, según corresponda, y a su vez, estos dos momentos en la
recepción de los productos pueden realizarse a ciegas o convencionalmente,
 según la información que reciba el dependiente y el volumen de productos o
surtidos. Para ello se debe contar con los medios de medición verificados y en
buen estado técnico. (Hernandez Muñoz, 2012, págs. 34-35).

2.3.2 Proceso de Almacenamiento

La función fundamental del almacén es la de mantener adecuadamente almacenadas

las mercancías que se requieran para el abastecimiento sistemático, el almacenaje es
la acción que se ejecuta después de recibida la mercancía cuando se procede a su
almacenamiento en forma organizada, con el propósito de viabilizar la función posterior
al despacho para ello se debe efectuar lo siguiente:

 Colocar los productos en los alojamientos seleccionados: De acuerdo al método

de control de ubicación y localización de los productos seleccionados, ya sea en
las estanterías o en las estibas seleccionadas.

 Reubicar los productos cuando sea necesario, garantizando la rotación: Cuando

el producto incorporado se suma a una existencia anterior hay que reubicarlo
garantizando la accesibilidad a los productos más próximos a vencerse para
cumplir con el principio: primero –en vencerse, primero –en salir.

 Verificar que se cumplan con las marcas gráficas: Tanto antes de almacenarse,
como en el almacén.

 Mantener actualizadas las entradas y salidas de productos (inventario): Llenar

la Tarjeta de Estiba para controlar las existencias en unidades solamente, de
producto en almacén mediante el registro de movimiento de entrada, salida y
existencia de los mismos. Responsabilidad del dependiente de almacén realizar
los registros en la misma. (Hernandez Muñoz, 2012).

2.3.3 Proceso de Despacho

 Recepción y clasificación de los pedidos: A partir de la recepción de los pedidos,

estos son ordenados y clasificados según su volumen, número de surtidos o
ambos a la vez con el fin de establecer el orden en que deben ser conformados
los despachos, teniendo en cuenta los productos de que se trate, las
características de los clientes, la urgencia de los mismos y la estrategia de la
empresa, y en el caso de entregas a destinos la prioridad la puede imponer la
optimización de los recorridos.
  Orden de despacho: Es la realización de la continuidad del proceso documental
y de información necesario para el control, desde el pedido hasta la entrega al
cliente, garantiza la selección del producto teniendo en cuenta las rotaciones de
los inventarios, garantizando por los métodos existentes (manual o
automatizado) el principio de que el primero en vencerse es el primero en salir.

 Selección del método para el despacho: Este puede ser por clientes, por
productos o mixto.

 Extracción de las cargas: Se refiere a extraer los productos solicitados del

medio de almacenamiento, mediante los equipos de manipulación existentes o
manualmente.

 Revisión y control: Al conformar el pedido de cada cliente, es necesario revisar

y controlar los mismos, en cuanto a cantidad, lotes de salida, calidad y
documentación. También debe revisarse el estado del envase y el embalaje.

 Realización de los servicios técnico – productivos asociados: Estos se ejecutarán

cuando sean solicitados por los clientes y puede consistir en el envasado
especial o el reenvase, entre otros.

 Traslado a la zona de expedición o entrega: Cuando el pedido está conformado

para cada cliente, entonces se puede proceder a trasladarlo al área de
expedición, para que sea transportado al cliente y de hecho se produce el
despacho. (Hernandez Muñoz, 2012, pág. 50).

2.4 Control de Inventario

Cuando hablamos de "inventarios", de manera intuitiva comprendemos que se trata de

objetos, personas, cosas o servicios que componen los haberes o existencias de una
organización. Cuando nos referimos a la palabra "control", básicamente estamos
indicando el dominio que se tiene sobre algo. Es decir, que de acuerdo al control o
dominio que tengamos sobre ese algo podemos darle la dirección, avance, retroceso,
dotación y esfuerzo que la situación a controlar requiera, para no perder dicho control
y seguir manteniéndola bajo dominio. (Goicochea Rojas, 2009).

Aplicando el primer vocablo sobre el segundo, obtenemos el título del tema que nos
ocupa: " Control de Inventarios ", que en su forma más simple lo podemos definir
como:
Control de Inventarios: Es el dominio que se tiene sobre los haberes o existencias
pertenecientes a una organización.

En la práctica el control de inventarios (CI) no resulta tan fácil como su definición. Por
sí mismo el CI es un sistema que está subordinado a otros sistemas mayores que
tienen como fin último operar para el logro de los objetivos generales de toda la
organización, el sistema CI se puede representar gráficamente como sigue. (Sierra y
Acosta, 2008, pág. 8).

Figura 2.2 Control de Inventario [Fuente: Jorge Sierra y Acosta].

La función básica de las existencias es el desglose, es decir, separar las actividades

internas de una compañía, tales como manufactura, distribución o comercialización.
Con el objetivo de satisfacer las necesidades y expectativas de los clientes, debe
encontrarse el equilibrio ideal, brindándoles el mayor nivel de servicio posible con el
menor nivel de inventario. Si un bien no está disponible en el momento en que el
cliente lo solicita, se perderá la venta y, en algunas circunstancias, posiblemente, las
ventas futuras. Por el contrario, si se tienen altas cantidades de dicho producto, se
tendrán altos costos asociados a los costos de oportunidad de tener recursos de capital
invertidos innecesariamente en dichas mercancías. El objetivo final de una buena
administración del inventario, es mantener la cantidad suficiente para que no se
presenten ni faltantes(stockouts) ni excesos de existencias (overstock), en un proceso
fluido de producción y comercialización. Esto conduce a tener una adecuada inversión
de los recursos de una compañía y un nivel óptimo de costos de administrar el
inventario. (Mora Garcia, 2011).

Las organizaciones tienen stocks por diferentes motivos, que pueden ser clasificados
en cinco funciones:

 Para absorber las fluctuaciones e incertidumbres de oferta y demanda de los

clientes.

 Para desglosar o separar los procesos internos dentro de una organización.

 Para anticiparse ante circunstancias de incertidumbre como estacionalidades en

la demanda, huelgas, inestabilidad política, escasez de productos, problemas de
transporte, variables macroeconómicas externas, etc.

 Para aprovisionarse (economías de escala) al comprar volúmenes superiores a

los promedio, en épocas de alzas de precios, con el fin de reducir costos.

 Para compensar los tiempos de reabastecimiento de los proveedores. (Mora

Garcia, 2011).

2.5 Seguimiento de préstamos

El procedimiento para el seguimiento el seguimiento del préstamo de los productos

tiene la siguiente secuencia de acuerdo a la necesidad de la empresa solicitante:

 El empleado del almacén solicitante (a donde se dirige el producto solicitado),

presenta una hoja detallada con los productos solicitados para su traslado al
almacén.
  El empleado del almacén principal (de donde sale el producto prestado), evalúa
si lo solicitado se encuentra activo y disponible en el stock del almacén.

 Antes del registro del préstamo se evalúa si los productos solicitados están en
estado óptimo para su despacho.

 Si los productos solicitados tienen el stock necesario, se procede con el

préstamo, efectuando el registro respectivo en donde se detalla, el código, el
nombre del producto, cantidad, el almacén de donde se sale y el almacén a
donde se deriva.

 Después de realizado el préstamo, se efectúa un control sobre las devoluciones,

esto dependerá del grado de necesidad y del tiempo el cual ha transcurrido
desde el día del préstamo hasta la fecha actual, la administración deberá definir
que productos deben ser devueltos a la brevedad. (General, 2010).

Figura 2.3 Seguimiento de préstamo de autopartes [Fuente: Propia]

2.6 Responsabilidades en el almacén

2.6.1 Del Supervisor

 Mantener, supervisar y controlar las existencias físicas de los insumos y

materiales de acuerdo a los niveles de máximos y mínimos, y activar su
abastecimiento de acuerdo con el punto de reposición.

 Establecer controles internos para el surtimiento de los insumos y materiales de

los almacenes.
  Programar la entrega de los materiales a las unidades administrativas, de
acuerdo con las salidas del almacén.

 Establecer las condiciones de almacenamiento de los materiales adquiridos, de

acuerdo a sus características, volumen y frecuencia de uso.

 Supervisar que los depósitos se encuentren en condiciones de seguridad y buen

funcionamiento. (Estatal, 2007).

2.6.2 Del Responsable

 Dar entrada en el depósito a su cargo, a los bienes que sean adquiridos a

través del movimiento correspondiente.

 Custodiar y almacenar los bienes adquiridos.

 Efectuar la recepción de los pedidos verificando que los artículos o bienes

cumplan con las características y especificaciones establecidas. (Estatal, 2007).

2.7 Arquitectura y Diseño de Sistema de Información Web

Las aplicaciones web se han convertido en complejos sistemas con interfaces de

usuarios cada vez mas parecidos a las aplicaciones de escritorio, dando servicio a
procesos de negocio de considerable envergadura y estableciéndose sobre ellas
requisitos estrictos de accesibilidad y respuesta. Esta a exigido reflexiones sobre la
mejor arquitectura y las tecnicas de diseño mas adecuadas. (Ceballos Sierra, 2012).

La rapida expansion de la Internet y el uso de Intranets coorporativas a supuesto una

transformacion en las necesidades de informacion de las organizaciones y esto afecta
de acuerdo a que:

a. La información sea accesible desde cualquier lugar dentro de la organización e

incluso desde el exterior.
b. Esta información sea compartida entre todas las partes interesadas, de manera que
todas tengan acceso a la información completa (o aquella parte que le corresponda
según su función) en cada momento. (Lujan Mora, 2012).

Estas necesidades han provocado un cambio de las aplicaciones tradicionales de

escritorio hacia las aplicaciones web, los sitios web tradicionales que se limitaban a
mostrar informacion se han convertido en aplicaciones capaces de una interaccion mas
o menos sofisticada con el usuario, esto a provocado un aumento progresivo de la
complejidad de estos sistemas; y por ende la necesidad de buscar opciones de diseño
nuevas que permitan dar con la arquitectura optima que facilite la construccion de los
mismos. El usuario interactua con la aplicacion web a traves del navegador. Como
consecuencia de las actividades del usuario, se envian peticiones al servidor, donde se
aloja la aplicacion y que normalmente hace uso de una base de datos que almacena
toda la informacion relacionada con la misma. El servidor procesa la peticion y
devuelve la respuesta al navegador que la presenta la usuario. Por tanto el sistema se
distribuye en tres componentes:

a. El navegador.- que presenta la interfaz al usuario.

b. La aplicación.- que se encarga de realizar las operaciones necesarias según las
acciones llevadas a cabo por este.
c. La base de datos.- donde la información relacionada con la aplicación se hace
persistente. (Mateu, 2004).

Figura 2.4 Arquitectura de Sistema de Información Web [Fuente:

http://dspace.ucuenca.edu.ec/bitstream/123456789/4303/1/tesis.pdf]

Esta distribucion se conoce como modelo o arquitectura de tres niveles, en todos los
sistemas de este tipo y ortogonalmente a cada uno de lo niveles comentados, podemos
dividir la aplicacion en tres areas o niveles:

a. Nivel de Presentación.- es el encargado de generar la interfaz de usuario en función

de las acciones llevadas por el mismo. Es la que ve el usuario, presenta el sistema al
usuario, le comunica la información y captura la información del usuario dando un
 mínimo de proceso, este nivel se comunica solo con el nivel de negocio.

b. Nivel de Negocio.- contiene toda la lógica que modela los procesos del negocio y es
donde se realiza todo el procesamiento necesario para atender a las peticiones del
usuario. Este nivel se comunica con el nivel de presentación, para recibir las
solicitudes y presentar los resultados, y con el nivel de datos, para solicitar al gestor
de base de datos para almacenar o recuperar datos de él.

c. Nivel de Administración de datos.- encargado de hacer persistir toda la información,

suministra y almacena información para el nivel de negocio. (Mateu, 2004).

Esta arquitectura de tres niveles presenta los siguientes beneficios:

 Abstracción.- ya que los cambios se realizan a alto nivel y se puede

incrementar o reducir el nivel de abstracción que se usa en cada capa del
modelo.
 Aislamiento.- ya que se pueden realizar actualizaciones en el interior de las
capas sin que esto afecte al resto del sistema.
 Rendimiento.- ya que distribuyendo las capas en diferentes niveles físicos se
puede mejorar la escalabilidad, la tolerancia a fallos y el rendimiento.
 Testeabilidad.- ya que cada capa tiene una interfaz definida sobre la que
realizar pruebas y la habilidad de cambiar entre diversas implementaciones de
una capa.
 Independencia.- ya que elimina la necesidad de considerar el hardware y el
despliegue así como las dependencias con interfaces externas. (Sarasty
España, 2015, pág. 16).

2.7.1 Ventajas y Desventajas de una Aplicación web

Una ventaja clave del uso de aplicaciones web es que el problema de gestionar el
códigoen el cliente se reduce drásticamente. Suponiendo que existe un navegador o
explorador estándar en cada cliente, todos los cambios, tanto de interfaz como de
funcionalidad,que se deseen realizar a la aplicación se realizan cambiando el código
que resida en el servidor web. Compárese esto con el coste de tener que actualizar
uno por uno el código en cada uno de los clientes (imaginemos que tenemos 2.000
ordenadores clientes).No sólo se ahorra tiempo porque reducimos la actualización a
una sólo máquina,sino que no hay que desplazarse de un puesto de trabajo a otro (la
empresa puede tener una distribución geográfica amplia). Una segunda ventaja,
relacionada con la anterior, es que se evita la gestión de versiones. Se evitan
problemas de inconsistencia en las actualizaciones, ya que no existen clientes con
distintas versiones de la aplicación. Una tercera ventaja es que si la empresa ya está
usando Internet,no se necesita comprar ni instalar herramientas adicionales para los
clientes. Otra ventaja,es que de cara al usuario,los servidores externos(Internet) e
internos (intranet) aparecen integrados,lo que facilita el aprendizaje y uso. Una última
ventaja,pero no menos importante,es la independencia de plataforma. Para que una
aplicación web se pueda ejecutar en distintas plataformas (hardware y sistema
operativo), sólo se necesita disponer de un navegador para cada una de las
plataformas, y no es necesario adaptar el código de la aplicación a cada una de ellas.
Además,las aplicaciones web ofrecen una interfaz gráfica de usuario independiente de
la plataforma (ya que la plataforma de ejecución es el propio navegador). Una
desventaja,que sin embargo está desapareciendo rápidamente,es que la programación
en la web no es tan versátil o potente como la tradicional. El lenguaje HTML presenta
varias limitaciones, como es el escaso repertorio de controles disponibles para crear
formularios. Por otro lado,al principio las aplicaciones web eran básicamente de solo
lectura:permitían una interacción con el usuario prácticamente nula. Sin embargo, con
la aparición de nuevas tecnologías de desarrollo como Java, JavaScriptyASP,esta
limitación tiende a desaparecer. (Lujan Mora, 2012, págs. 53-54).

2.8 Framework MVC

En inglés framework se puede traducir como estructura; en el sentido que nos ocupa
un framework sería un marco de trabajo. MVC son las siglas de Modelo-Vista-
Controlador un paradigma de programación de aplicaciones que separa en tres niveles
el trabajo: por un lado el modelo que hace referencia a las aplicaciones empresariales
conocido como la lógica de negocio (por ejemplo el Sistema Gestor de la Base de
Datos); la vista hace referencia al aspecto visual de la aplicación con el usuario; el
controlador finalmente es la parte que controla las acciones del usuario y las comunica
a los dos apartados anteriores. Es, en definitiva, un modelo de trabajo que facilita la
creación de aplicaciones web complejas. Se les conoce también con el nombre de
plantillas. (Sanchez Asenjo, 2011).
2.8.1 El Framework Spring MVC

Para aplicar el patrón MVC se utiliza lo siguiente:

 Una capa de vista, formada de jsp, html, css, etiquetas personalizadas, etc.

 Una capa de modelo, que cuenta con las subcapas de servicios, persistencia
(daos, etc.) y dominio (beans). Se forma mediante clases e interfaz Java.

Sin embargo, se necesita una capa de control, que se compone de lo siguiente:

 DispatcherServlet: es el controlador frontal, que recibe y gestiona todas las

peticiones (request). Resulta oculto al programador y es creado por Spring.

 Interface HandlerMapping: analiza cada petición y determina el controlador que

la gestiona. Podemos contar con varios manejadores, en función de las diversas
estrategias de "mapeo" (basado en cookies, variables de sesión, etc.). En la
mayor parte de los casos, nos sirve el manejador por defecto del framework
Spring: BeanNameUrlHandleMapping.

 Controladores: manejan las peticiones de cada página. Cada controlador recibe

las peticiones de su página correspondiente, delega en el dominio y recoge los
resultados. Lo que hace es devolver un modelo a la vista que ha seleccionado
(por medio del controlador frontal). (Mayor Martin, 2014).

Figura 2.5 El Framework Spring MVC [Fuente:

https://riunet.upv.es/bitstream/handle/10251/16951/Memoria.pdf?sequence=1]

Lo que devuelve cada controlador es un objeto del tipo ModelAndView. Este objeto se
compone de lo siguiente:
 Una referencia a la vista destino
 El modelo: un conjunto de objetos se utilizan para componer (render) la vista
destino; por ejemplo, un bean Cliente o una lista de beans (clientes) que se ha
obtenido de un DAO. (Cibertec, 2010).
 CAPÍTULO 3: MÉTODOS PARA LA CONSTRUCCIÓN DE LA SOLUCIÓN
TECNOLÓGICA

En este Capítulo veremos que Metodologías de Desarrollo de Software nos ayudaran

con la implementación de la aplicación web, el objetivo es presentar un conjunto de
técnicas tradicionales y modernas de modelado de sistemas que permitan desarrollar
software de calidad.

3.1 Metodologías / Modelo / Algoritmos

A continuación se presentan las dos metodologías candidatas para el desarrollo de la

solución. Posteriormente se exponen las justificaciones respecto a la elección de una
de estas propuestas.

3.1.1 Proceso Unificado Rational RUP

RUP es una metodología de desarrollo de software basada en un enfoque iterativo con

una adecuada adaptación de los cambios durante el proceso de desarrollo, sumada a la
correcta gestión de requerimientos incorporando al diseño de software el lenguaje
UML, definido como un sistema de modelamiento visual para la representación gráfica
de casos de uso, clases de análisis, componentes de software entre otros. Un elemento
clave en la concepción de RUP es el aseguramiento de la calidad del software.

Esta metodología engloba una serie de entregables o artifacts del ciclo de desarrollo
del producto, constituyéndose así como el activo más importante después del producto
final, pues en éstos se documentan los alcances técnicos y funcionales definitivos del
producto desarrollado en el presente proyecto de fin de carrera. (Rueda Chacon,
2006).

3.1.1.1 Procesos dirigidos por casos de uso

Los Casos de Uso son una técnica de captura de requisitos que fuerza a pensar en
términos de importancia para el usuario y no sólo en términos de funciones que sería
bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del
sistema que proporciona al usuario un valor añadido. Los Casos de Uso representan los
requisitos funcionales del sistema.
En RUP los Casos de Uso no son sólo una herramienta para especificar los requisitos
del sistema. También guían su diseño, implementación y prueba. Los Casos de Uso
constituyen un elemento integrador y una guía del trabajo. (Jacobson, Boosch, &
Rambaugh, 2000).

Figura 3.1 Los casos de uso integran el trabajo [Fuente:

http://cybertesis.urp.edu.pe/urp/2010/chavez_vh/pdf/chavez_vh-TH.3.pdf]

3.1.1.2 Proceso iterativo e incremental

El equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy parecido al
equilibrio de la forma y la función en el desarrollo del producto, lo cual se consigue con
el tiempo. Para esto, la estrategia que se propone en RUP es tener un proceso
iterativo e incremental en donde el trabajo se divide en partes más pequeñas o mini
proyectos. Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya
logrando durante cada mini proyecto, así durante todo el proceso de desarrollo. Cada
mini proyecto se puede ver como una iteración (un recorrido más o menos completo a
lo largo de todos los flujos de trabajo fundamentales) del cual se obtiene un
incremento que produce un crecimiento en el producto. (Jacobson, Boosch, &
Rambaugh, 2000).
 Figura 3.2 Una iteración RUP [Fuente:
http://cybertesis.urp.edu.pe/urp/2010/chavez_vh/pdf/chavez_vh-TH.3.pdf].

A continuación se muestra cómo varía el esfuerzo asociado a las disciplinas según la

fase en la que se encuentre el proyecto RUP.

Figura 3.3 Esfuerzo en actividades según la fase del proyecto [Fuente:

http://cybertesis.urp.edu.pe/urp/2010/chavez_vh/pdf/chavez_vh-TH.3.pdf]

3.1.1.3 Estructura del Proceso

El proceso puede ser descrito en dos dimensiones o ejes:

 Figura 3.4 Estructura de RUP [Fuente:
http://cybertesis.urp.edu.pe/urp/2010/chavez_vh/pdf/chavez_vh-TH.3.pdf].

3.1.1.4 Modelado del negocio

Con este flujo de trabajo pretendemos llegar a un mejor entendimiento de la

organización donde se va a implantar el producto.

Los objetivos del modelado de negocio son:

a. Entender la estructura y la dinámica de la organización para la cual el sistema va ser

desarrollado (organización objetivo).
b. Entender el problema actual en la organización objetivo e identificar potenciales
mejoras.
c. Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento
común de la organización objetivo.
d. Derivar los requisitos del sistema necesarios para apoyar a la organización objetivo.
(Sommerville, 2005).

3.1.1.5 Requisitos

Este es uno de los flujos de trabajo más importantes, porque en él se establece qué
tiene que hacer exactamente el sistema que construyamos. En esta línea los requisitos
son el contrato que se debe cumplir, de modo que los usuarios finales tienen que
comprender y aceptar los requisitos que especifiquemos.

Los objetivos del flujo de datos Requisitos son:

a. Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que

el sistema podría hacer.
b. Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema.
c. Definir el ámbito del sistema.
d. Proveer una base para la planeación de los contenidos técnicos de las iteraciones.
e. Proveer una base para estimar costos y tiempo de desarrollo del sistema.
f. Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas
del usuario.

Los requisitos se dividen en dos grupos. Los requisitos funcionales representan la

funcionalidad del sistema. Se modelan mediante diagramas de Casos de Uso. Los
requisitos no funcionales representan aquellos atributos que debe exhibir el sistema,
pero que no son una funcionalidad específica. (Jacobson, Boosch, & Rambaugh, 2000).

3.1.1.6 Análisis y diseño

El objetivo de este flujo de trabajo es traducir los requisitos a una especificación que
describe cómo implementar el sistema.

Los objetivos del análisis y diseño son:

a. Transformar los requisitos al diseño del futuro sistema.
b. Desarrollar una arquitectura para el sistema.
c. Adaptar el diseño para que sea consistente con el entorno de implementación,
diseñando para el rendimiento.

El resultado final más importante de este flujo de trabajo será el modelo de diseño.
Consiste en colaboraciones de clases, que pueden ser agregadas en paquetes y
subsistemas, otro producto importante de este flujo es la documentación de la
arquitectura de software, que captura varias vistas arquitectónicas del sistema.
(Jacobson, Boosch, & Rambaugh, 2000).
3.1.1.7 Implementación

En este flujo de trabajo se implementan las clases y objetos en ficheros fuente,

binarios, ejecutables y demás. Además se deben hacer las pruebas de unidad: cada
implementador es responsable de probar las unidades que produzca. El resultado final
de este flujo de trabajo es un sistema ejecutable.

En cada iteración habrá que hacer lo siguiente:

a. Planificar qué subsistemas deben ser implementados y en qué orden deben ser
integrados, formando el Plan de Integración.
b. Cada implementador decide en qué orden implementa los elementos del
subsistema.
c. Si encuentra errores de diseño, los notifica.
d. Se prueban los subsistemas individualmente.
e. Se integra el sistema siguiendo el plan. (Rueda Chacon, 2006).

3.1.1.8 Pruebas

Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos
desarrollando, pero no para aceptar o rechazar el producto al final del proceso de
desarrollo, sino que debe ir integrado en todo el ciclo de vida.

Esta disciplina brinda soporte a las otras disciplinas. Sus objetivos son:

a. Encontrar y documentar defectos en la calidad del software.

b. Generalmente asesora sobre la calidad del software percibida.
c. Provee la validación de los supuestos realizados en el diseño y especificación de
requisitos por medio de demostraciones concretas.
d. Verificar las funciones del producto de software según lo diseñado.
e. Verificar que los requisitos tengan su apropiada implementación. (Jacobson, Boosch,
& Rambaugh, 2000).

3.1.1.9 Despliegue

El objetivo de este flujo de trabajo es producir con éxito distribuciones del producto y
distribuirlo a los usuarios. Las actividades implicadas incluyen:
a. Probar el producto en su entorno de ejecución final.
b. Empaquetar el software para su distribución.
c. Distribuir el software.
d. Instalar el software.
e. Proveer asistencia y ayuda a los usuarios.
f. Formar a los usuarios y al cuerpo de ventas.
g. Migrar el software existente o convertir bases de datos.

Por último podemos considerar las relaciones de trazabilidad entre artefactos del
proyecto. (Rueda Chacon, 2006).

Figura 3.5 Trazabilidad entre artefactos [Fuente:

http://cybertesis.urp.edu.pe/urp/2010/chavez_vh/pdf/chavez_vh-TH.3.pdf].

3.1.2 Metodología ICONIX

Iconix es una metodología pesada-ligera de Desarrollo del Software que se halla a

medio camino entre un RUP (Rational Unified Process) y un XP (eXtreme
Programming). Iconix deriva directamente del RUP y su fundamento es el hecho de
que un 80% de los casos pueden ser resueltos tan solo con un uso del 20% del UML,
con lo cual se simplifica muchísimo el proceso sin perder documentación al dejar solo
aquello que es necesario. Esto implica un uso dinámico del UML de tal forma que
siempre se pueden utilizar otros diagramas además de los ya estipulados si se cree
conveniente. (Fernandez Peña, 2007).

3.1.2.1 Fases de iconix

a. Análisis de Requisitos

En esta primera fase se realiza un Modelo de Dominio, que no es más que un

Diagrama de Clases extremadamente simplificado. Este modelo contiene
únicamente aquellos objetos de la vida real cuyo comportamiento o datos deban
ser almacenados en el sistema. Requisitos nuevos o modificados Sistema nuevo o
modificado Proceso de Desarrollo de Software Requisitos nuevos o modificados
Sistema nuevo o modificado Proceso de Desarrollo de Software A partir de este
pequeño modelo, se realiza un pequeño prototipo basándose en la storyboard de
la interfaz gráfica obtenida previamente, el cual se mostrará al cliente y se refinará
en sucesivas reuniones. Normalmente este prototipo suele converger en dos o tres
iteraciones. Una vez el prototipo ya es final y se han obtenido todos los requisitos
del sistema por parte del cliente, se procede a realizar los casos de uso.
(Yaccherima Espin, 2011).

b. Análisis y Diseño Preliminar

A partir de cada caso de uso se obtienen sus correspondientes fichas de caso de

uso. Cabe destacar que estas fichas no pertenecen al UML. He aquí un ejemplo de
ficha para que se entienda mejor:
 Figura 3.6 Ejemplo de Ficha de Casos de Uso [Fuente:
http://ima.udg.edu/~sellares/EINF-ES2/Present1011/MetodoPesadesICONIX.pdf].

La ficha está formada por un nombre, que suele ser el del caso de uso, posee una
breve descripción (generalmente en vista usuario, es decir, que hace de forma
intuitiva, no como), una precondición que debe cumplir antes de iniciarse, una
postcondición que debe cumplir al terminar si termina correctamente, un flujo
normal que sigue el sistema en caso de que todo vaya correctamente y un flujo
alternativo en caso de que haya cualquier problema. El resto de campos son
opcionales. Después será necesario realizar lo que se conoce como Diagrama de
Robustez, el cual pertenece al proceso Iconix y tampoco forma parte del UML. Así
pues se establece el siguiente flujo: (Yaccherima Espin, 2011).

Figura 3.7 Flujo entre objetos Frontera, Control y Entidad [Fuente:

http://ima.udg.edu/~sellares/EINF-ES2/Present1011/MetodoPesadesICONIX.pdf].
c. Diseño

En esta fase se proceden a realizar los diagramas de secuencia, los cuales derivan
directamente de las fichas de caso de uso. Obsérvese como, los diagramas de
secuencia se relacionan con fichas de caso de uso que se relacionan con casos de
uso que se relacionan con requisitos. Esto implica que una vez finalizado el diseño,
tras refinar nuevamente el diagrama de clases, podremos verificarlo directamente
gracias a este factor de trazabilidad, y prepararnos para la siguiente fase.
(Yaccherima Espin, 2011).

d. Implementación

De cara a poder distribuir el software correctamente, puede ser adecuado realizar

un diagrama de componentes en algunos casos, pero no siempre es necesario. En
cualquier caso, aquí es donde se escribe el código tal y como fue especificado en
las fases anteriores y se planean las pruebas basándonos en los requisitos
iniciales, al nivel que fuese necesario. Aquí es donde hacemos uso real de la
trazabilidad y donde realmente ponemos en práctica esa garantía de calidad que
tanto hemos mencionado. (Yaccherima Espin, 2011).

3.1.2.2 Resumen de iconix

Figura 3.8 Resumen de la Metodología ICONIX [Fuente:

http://ima.udg.edu/~sellares/EINF-ES2/Present1011/MetodoPesadesICONIX.pdf].
3.1.3 Metodología SCRUM

Scrum es un marco de trabajo en el que equipos cross-funcionales pueden crear

productos o desarrollar proyectos de una forma iterativa e incremental. El desarrollo se
estructura en ciclos de trabajo llamados Sprints (también conocidos como iteraciones).
Estas iteraciones no deben durar más de cuatro semanas cada una (siendo dos
semanas la duración más habitual) y tienen lugar una tras otra sin pausa entre ellas.
Los Sprints están acotados en el tiempo – finalizan en una fecha determinada
independientemente de si el trabajo ha finalizado por completo o no, y jamás se
prorrogan. Normalmente los equipos Scrum escogen una duración de Sprint y la
mantienen para todos sus Sprints hasta que mejoran y pueden emplear ciclos más
cortos. Al principio de cada Sprint, un Equipo cross-funcional (de en torno a siete
personas) selecciona elementos (peticiones del cliente) de una lista priorizada. El
equipo acuerda un objetivo colectivo respecto a lo que creen que podrán entregar al
final del Sprint, algo que sea tangible y que estará “terminado” por completo. Durante
el Sprint no se podrán añadir nuevos elementos; Scrum se adapta a los cambios en el
siguiente Sprint, pero el pequeño Sprint actual está pensado para concentrarnos en un
objetivo pequeño, claro y relativamente estable. Todos los días el Equipo se reúne
brevemente para inspeccionar su progreso y ajustar los siguientes pasos necesarios
para completar el trabajo pendiente. Al final del Sprint, el Equipo revisa el Sprint con
los diferentes Stakeholders (interesados e involucrados en el producto) y realiza una
demostración de lo que han desarrollado. Se obtiene feedback que podrá ser
incorporado en el siguiente Sprint. Scrum enfatiza un producto “funcionando” al final
del Sprint que esté realmente “terminado”. En el caso del software, esto significa un
sistema que está integrado, testado, con la documentación de usuario generada y
potencialmente entregable. (Larman, 2012).
 Figura 3.9 Visión General de la Metodología SCRUM [Fuente:
http://www.scrumprimer.org/primers/es_scrumprimer20.pdf]

3.1.3.1 Componentes de scrum

a. Las Reuniones

 Planificación de Backlog, se definirá un documento en el que se reflejaran los

requisitos del sistema por prioridades, en este fase se definirá también la
planificación del Sprint 0, en la que se decidirá cuáles van a ser los objetivos y el
trabajo que hay que realizar para esa iteración.

Se obtendrá además en esta reunión un Sprint Backlog, que es una lista de tareas
y que es el objeto más importante del Sprint.

 Seguimiento del Sprint, en esta fase se hacen reuniones diarias en las que tres
preguntas principales para evaluar el avance de las tareas serán: ¿Qué trabajo se
realizó desde la reunión anterior?, ¿Qué trabajo se hará hasta una nueva reunión?
y inconvenientes que han surgido y que hay que solucionar.

 Revisión del Sprint, cuando finaliza el Sprint se realiza una revisión del incremento
que se ha generado, se presentaran los resultados finales y una demo o versión.
(Scrum Body, 2016).

b. Los Roles
 El Product Owner o dueño del producto, es el responsable desde el punto de vista
del negocio.

 El Scrum Mater, Responsable de que el equipo sea productivo, ayudándole en todo

momento a conseguir el objetivo acordado y de asegurar que los principios de
Scrum se están respetando.

 El Equipo, es el responsable de la construcción del producto. (Trigas Gallego).

3.1.3.2 Los artefactos de scrum

a. El Product Backlog, Es el lugar que contiene los requisitos del cliente priorizados y
estimados. El Product Backlog está gestionado por el Product Owner y usa
lenguaje de negocio.
b. El Sprint Backlog, Es la selección de requisitos del Product Backlog negociados
para el Sprint y que se ha descompuesto en tareas por el equipo para expresar los
requisitos del cliente en un lenguaje técnico.
c. Incremento, Parte añadida o desarrollada en un Sprint, es una parte terminada y
totalmente operativa. (Trigas Gallego).

3.2 Evaluación comparativa entre las metodologías / modelos / algoritmos

3.2.1 Criterios de evaluación

En esta sección realizaremos una comparación de las metodologías RUP, ICONIX,

SCRUM, las evaluaremos y definiremos cuál de ellas se asocia más a nuestro trabajo.

 Documentación de la metodología

Debe existir documentación publicada a través de libros en español o inglés,

tesis, trabajos de investigación, documentación Libre a través de foros, blog,
etc. Lo cual permite tener un mejor conocimiento de la misma; además de
tener puntos de control, revisión y asesoramiento sobre la aplicación de la
metodología. El hecho de contar con mayor documentación sea física o
publicada en Internet permite un mejor entendimiento. Para la presente
valoración la metodología que cuenta con mayor documentación de referencia
deberá tener el puntaje más alto.

 Conocimiento de la metodología
 Quien desarrolla la aplicación web deberá tener un buen entendimiento y
conocimiento de la metodología utilizada para la solución al problema, este
criterio es muy importante para la valoración ya que muchas veces la
metodología de desarrollo es importante para seguir todas las etapas del
desarrollo del software; desde el inicio hasta su entrega final.

 Metodología debe cumplir con el ciclo de vida del software

Cada metodología tiene sus propias fases algunas pueden ser simples o
complejas, la metodología que se adapte más a las etapas de requerimientos
análisis diseño e implementación, será la que mayor valoración tenga para
nuestro trabajo.

 Metodología relacionada a UML

Adicionalmente la metodología debe estar ligada al lenguaje de modelado

unificado, que es un lenguaje de fácil entendimiento por los usuarios finales lo
cual permite una comunicación bidireccional; esto permite un mejor
entendimiento durante el desarrollo del trabajo, es por ello que la metodología
que se adapte a UML será la que obtenga una mayor valoración.

 Metodología alineada a los objetivos del proyecto

La capacidad del producto de software para permitir al usuario entender si el

software es adecuado, y cómo puede ser utilizado para las tareas y las
condiciones particulares de la aplicación.

Se debe entender que la metodología debe tener como resultado final, la

consecución de los objetivos trazados al inicio del trabajo, la metodología que
cumpla con ello obtendrá una valoración mayor.

 Metodología debe especificar a responsables de resultados

Debe especificar claramente quienes son los responsables de cada tarea a

desarrollar, cada responsable debe entregar sus propios resultados durante el
desarrollo del proyecto, la metodología que tenga mayor valoración será la
elegida.

 Metodología que desarrolle artefactos o entregables

La metodología debe cumplir en cada fase de su desarrollo con la presentación

de artefactos u entregables los cuales serán manejados por el desarrollador de
 la aplicación, esto permitirá conocer el avance del trabajo, la metodología que
cuente con mayor valoración será la escogida.

 Metodología para verificación de la calidad

Se refiere a la evaluación continua entre lo requerido y entregado, debe existir

una refinación en cada fase del desarrollo de la aplicación web, la metodología
que cumpla ello tendrá mayor valoración.

CRITERIO RUP ICONIX SCRUM

Documentación de la metodología 3 2 2

Conocimiento de la metodología 3 1 1

Metodología debe cumplir con el ciclo de vida 3 2 2

Metodología relacionada a UML 3 2 2

Metodología alineada a los objetivos del proyecto 2 2 2

Metodología debe especificar a responsables 2 2 3

Metodología que desarrolle entregable u artefactos 3 2 2

Metodología para verificación de calidad 2 1 2

Puntuación total 21 14 16

Tabla 3.1 Evaluación de metodología de desarrollo de software [Fuente: Propia]

Tener en cuenta que:

1 es nivel bajo, 2 es nivel regular y 3 es nivel optimo

La metodología de desarrollo seleccionada para el presente trabajo es Proceso

Unificado Rational por las razones expuestas a continuación:

 El enfoque RUP ofrece un amplio marco de buenas prácticas en la fase de

construcción de software en búsqueda de la optimización promoviendo medidas
 como la ejecución de pruebas con la programación así como el manejo de
unidades de prueba. Del mismo modo se constituye como una de las
metodologías más aplicadas para el análisis, implementación y documentación
de sistemas orientados a objetos.

 RUP cuenta con actividades de carácter iterativo e incremental lo cual

favorecen al logro de un producto software en menor tiempo y bajo una
comunicación horizontal en el tratamiento de cambios (el equipo de
desarrolladores reunido directamente con el cliente para conocer sus
necesidades) en lugar de una comunicación vertical (la solicitud de cambio
transmitida a través de una serie de revisiones, usuarios y analistas).

 RUP prioriza a un grado mayor la documentación para el entendimiento de la

solución final, la cual es de primordial ayuda para la implementación de la
aplicación web.

 Como punto final por tratarse de la implementación de una aplicación web

conformado únicamente por el investigador como responsable de las labores de
análisis, diseño e implementación, resulta inevitable el uso de la metodología
RUP para el entendimiento fácil y el logro del producto software final.
 CAPÍTULO 4: APORTE TEÓRICO

El desarrollo de este capítulo abarca los requerimientos, análisis, diseño e

implementación de la aplicación web a desarrollar.

4.1 Aplicación de la metodología / modelo / algoritmos al problema

La metodología RUP será utilizada para solucionar la problemática planteada al inicio

del trabajo como bien es cierto necesitamos una aplicación web que registre y de
seguimiento de los productos prestados, con RUP se cumplirá la realización de los
objetivos del presente trabajo.

4.1.1 Modelado del negocio

4.1.1.1 Glosario de términos

 Almacén, es el lugar donde se alojan los productos de la empresa.

 Almacenero, es la persona que labora dentro del almacén, quien conoce la

totalidad de los productos.

 Distribuidor, es la persona que traslada los productos hacia las agencias para
envíos a provincias, o para entrega de productos prestados.

 Encargado, es un usuario de la aplicación tiene acceso limitado a la aplicación

web de control de préstamo de productos.

 Jefe de Almacén, es quien controla a todos los almaceneros, realiza pedido de

productos y los controla.

 Marca, representa la marca del producto que hay en el almacén.

 Préstamo, el préstamo contiene una serie de productos que se trasladan a otro

almacén.

 Producto, son los productos que se encuentran disponibles en la empresa en

este caso en el almacén, para su venta y distribución.

 Repuesto, Accesorio, Autoparte, es el nombre común con el que se le conoce a

toda la mercadería dentro del negocio.

 Supervisor, tiene mayor acceso a la aplicación web de control de préstamo de

productos.
 Tipo, es el tipo de producto que hay en el almacén puede ser electrónico,
limpieza, etc.

 Unidad de Medida, es la unidad de medida del producto como puede ser

unidad, piezas de dos, ciento, etc.

 Usuario, puede ser un encargado o un supervisor de la aplicación web que se

desarrolla para controlar los préstamos de productos.

 Vendedor, realiza la venta de los productos a los clientes.

 Proveedor, es el proveedor de las autopartes.

4.1.1.2 Diagrama de casos de uso del negocio

Figura 4.1 Diagrama de casos de uso del negocio [Fuente: Propia].

4.1.1.3 Descripción de alto nivel de casos de uso del negocio

1- Proceso de negocio: Realizar pedido de producto.

2- Actor: Jefe de almacén, proveedor.

3- Objetivo: permite solicitar autopartes al proveedor de la empresa, para llenado

de stock en almacenes.

Tabla 4.1 Realizar pedido de producto [Fuente: Propia].

1- Proceso de negocio: Controlar producto.

2- Actor: Jefe de almacén, supervisor, encargado.

3- Objetivo: permite dar seguimiento al registro de productos prestados a otros

almacenes.

Tabla 4.2 Controlar producto [Fuente: Propia].

1- Proceso de negocio: Distribuir producto.

2- Actor: Distribuidor.

3- Objetivo: permite distribuir los productos a los clientes de la empresa.

Tabla 4.3 Distribuir producto [Fuente: Propia].

1- Proceso de negocio: Solicitar producto.

2- Actor: Almacenero.

3- Objetivo: permite al almacenero notificar sobre la falta de productos en

almacén para ser adquiridos por el proveedor.

Tabla 4.4 Solicitar producto [Fuente: Propia].

1- Proceso de negocio: Realizar venta.

2- Actor: Vendedor.

3- Objetivo: permite al vendedor realizar la venta de productos a clientes del

mercado automotriz.

Tabla 4.5 Realizar venta [Fuente: Propia].

4.1.2 Requerimiento

4.1.2.1 Determinar requerimientos

a. Requisitos funcionales

Req1: Realizar seguimiento de autopartes prestadas.

Las diversas autopartes que salen del almacén en calidad de préstamo deben estar
almacenados en la base de datos para establecer su control al momento de efectuar el
préstamo, el Usuario directo del sistema en este caso Encargado debe de realizar el
seguimiento de las autopartes prestadas, esto incluye saber el almacén de origen
(donde sale un producto), el almacén de destino (donde se recibe un producto) la
fecha, los responsables del préstamo; para luego agregar las autopartes prestadas con
la cantidad solicitada y de esta manera se pueda grabar en el sistema.

Req2: Registrar información de los responsables del préstamo.

Cada vez que un determinado almacenero en este caso Empleado envié los productos
del almacén de origen donde realiza el préstamo hacia el almacén de destino donde se
recibe el préstamo, este deberá mostrar el producto que se lleva al otro almacén así el
Usuario del sistema podrá registrar el préstamo, de esta forma los que intervienen
directamente con el manejo de las autopartes deben estar registrados en el sistema de
tal manera que se pueda saber quién se llevó una determinada autoparte y en qué
fecha, y del mismo modo al Usuario directo del sistema, de este manera tendremos
noción de los Responsables directos en el movimiento de las autopartes prestadas.

Req3: Generar orden de devolución de las autopartes.

En el momento en que el Supervisor solicite información de aquellas autopartes
prestadas a otro almacén, el Usuario del sistema procederá a generar la orden de
devolución de acuerdo a la fecha en que se realizó el préstamo o conforme a que tan
solicitado es una determinada autoparte para el área de ventas, para posteriormente
mostrar en el sistema la relación de todas las autopartes que se encuentran en calidad
de préstamo, se debe considerar las autopartes prestadas mediante una descripción
detallada y la cantidad de los mismos a la hora de generar la orden de devolución.
El supervisor podrá decidir si se devuelven aquellas autopartes prestadas ya que llega
un momento en que una determinada autoparte no cuenta con stock necesario para el
área de ventas del almacén de origen.

Req4: Controlar el stock de las autopartes prestadas.

Cuando se efectué el préstamo de las autopartes se debe detallar la cantidad en stock

que queda en el almacén de origen y la cantidad en stock que ingresa en forma de
préstamo hacia el almacén de destino, de esta manera se tendrá información precisa
a la hora de solicitar las devoluciones.
Se debe considerar que todas las autopartes pertenecientes al almacén de origen
deben estar inventariados correctamente con cantidades reales tanto en forma física
como dentro del sistema.

Req5: Modificar autopartes en estado de préstamo.

El sistema debe tener la propiedad de modificar el registro de autopartes prestadas,

esto es en ocasiones ocurre ciertos errores al momento de registrar la salida de una
autoparte en calidad de préstamo se registra una autoparte por otra, lo cual causa que
el stock varié en ocasiones radicalmente, o en otras ocasiones la autoparte que ha sido
prestada es devuelto lo cual debe eliminarse de la relación de autopartes en estado de
préstamo.

Req6: Mostrar información de las autopartes prestadas a través de reportes.

Posteriormente el encargado podrá acceder a la información de todas las autopartes

prestadas, puede ser por fecha de préstamo, por código de préstamo, ya que en
ocasiones se solicita información sobre una determinada autoparte, que se necesita
con urgencia para ser vendido y por tal motivo tiene un carácter de urgencia en ser
devuelto, para ello se emitirán reportes de todas las autopartes en calidad de
préstamo, el supervisor podrá generar reportes de autopartes prestadas por fechas y
autopartes por almacén.

b. Requisitos no funcionales

 Requisitos de interfaces externas

Req1: Interfaz de usuario
Las pantallas deben se sencillas e intuitivas y mostrarse en español, se debe mantener
la misma distribución física en las pantallas, es decir si en más de una pantalla existe el
mismo icono, en todas debe ubicarse en el mismo lugar y orden.

Req2: Comunicación Con Otros Sistemas

La comunicación con otros sistemas se efectúa a través del protocolo TCP/IP, y la
consulta a la bases de datos con el estándar SQL.

 Requisitos de rendimiento

Req1: Recursos
Los Recursos de rendimiento de consumo del sistema, deben ser mínimos debido a
que no se necesita software extra. El sistema en el equipo cliente debe ser soportado
por un equipo Pentium IV, de 1 Gb de memoria RAM, como mínimo para que agilicen
los procesos.

Req2: Velocidad de Respuesta

Las Consultas deben consumir la menor cantidad posible de recursos del servidor de
base de datos. Las consultas simples no se deben de tardar más de 10 milisegundos,
las consultas complejas, como la del parte de trabajo en la que se muestra muchos
datos en pantalla, no deben tardar más de 20 milisegundos en la mayoría de los casos.
La mayoría del proceso de debe realizar en el equipo cliente y sólo realizar las
consultas a la base de datos con los comandos SQL estándares.

 Requisitos de desarrollo

Req1: Ciclo de Vida

El desarrollo se debe realizar con la metodología RUP, respetando el ciclo de vida
orientado a objetos con la notación que permite realizar cambios de acuerdo a las
necesidades del usuario.
  Requisitos tecnológicos

Req1: Plataforma
El sistema en el entorno del usuario debe ser soportado por cualquier equipo que
tenga instalado Microsoft Windows XP o Versiones siguientes.

 Otros requisitos

Req1: Seguridad
El acceso al sistema debe ser seguro, por tanto se requiere la identificación del
usuario y el ingreso de un password.

Req2: Mantenibilidad
El sistema debe ser modular y orientado a objetos para facilitar el mantenimiento y las
futuras ampliaciones de acuerdo a las necesidades cambiantes.
Req3: Fiabilidad
El Sistema debe comportarse consistentemente, sin perder información y respondiendo
de la misma forma ante pedidos iguales.

Req4: Impresiones
Las impresiones deben ser realizadas en formato estándares pdf.

4.1.2.2 Encontrar actores y casos de uso

a. Actores

Después de realizar el análisis de los requerimientos se ha podido extraer los

siguientes actores del sistema de control de préstamo de productos
1. Usuario: representa al usuario de la aplicación.
2. Supervisor: supervisa los préstamos, tiene más privilegios en la aplicación.
3. Encargado: registra, modifica préstamos, tiene menos privilegios en la aplicación.
4. Empleado (Almacenero): es quien solicita préstamo de productos.

b. Casos de uso
A continuación se detalla una relación de casos de uso que tienen como punto de
partida los requerimientos que se listaron anteriormente.

1. Registrar Usuario.
2. Controlar Préstamo Autoparte.
3. Mantener Información de Responsables.
4. Generar Orden de Devolución.
5. Emitir Reportes.
6. Ingreso al Sistema.

4.1.3 Casos de uso del sistema web

a. Controlar préstamo de autopartes

Figura 4.2 Caso de uso controlar préstamo autopartes [Fuente: Propia].

b. Ingreso al sistema

Figura 4.3 Caso de uso ingreso al sistema [Fuente: Propia].

c. Generar orden de devolución

 Figura 4.4 Caso de uso generar orden devolución [Fuente: Propia].

d. Registrar Usuario

Figura 4.5 Caso de uso registrar usuario [Fuente: Propia].

e. Mantener información de responsables

Figura 4.6 Caso de uso mantener información de responsables [Fuente: Propia].

f. Emitir reporte

Figura 4.7 Caso de uso emitir reporte [Fuente: Propia].

4.1.3.1 Descripción de alto nivel de casos de uso del sistema

1- Caso de uso del sistema: Controlar préstamo de autopartes.

2- Actor: Usuario.
3- Descripción: El caso de uso es iniciado por el usuario, quien es responsable de
realizar el Control de Préstamo de Autopartes a otro almacén, el control de
préstamo debe realizarse teniendo en cuenta el código de producto, la
cantidad, usuario, responsable, etc.

Tabla 4.6 Controlar préstamo de autopartes [Fuente: Propia].

1- Caso de uso del sistema: Registrar préstamo de autopartes.

2- Actor: Usuario.

3- Descripción: El caso de uso es iniciado por el usuario, quien es responsable de

realizar el registro de préstamo de Autopartes a otro almacén, se debe tener
en cuenta el código de producto, descripción, para proceder al registro.

Tabla 4.7 Registrar préstamo de autopartes [Fuente: Propia].

1- Caso de uso del sistema: Mantener préstamo de autopartes.

2- Actor: Usuario.

3- Descripción: El caso de uso es iniciado por el usuario, quien es responsable de

modificar o eliminar el préstamo de producto, lo cual debe realizarse teniendo
en cuenta el código del préstamo o la fecha.

Tabla 4.8 Mantener préstamo de autopartes [Fuente: Propia].

1- Caso de uso del sistema: Controlar stock préstamo de autopartes.

2- Actor: Usuario.

3- Descripción: El caso de uso es iniciado por el usuario, quien es responsable de

realizar el control de stock de préstamo de autopartes, deberá manejar el stock
 de las autopartes prestados de manera actualizada, indicando el inventario de
los mismos.

Tabla 4.9 Controlar stock préstamo de autopartes [Fuente: Propia].

1- Caso de uso del sistema: Ingreso al sistema.

2- Actor: Usuario.

3- Descripción: El caso de uso es iniciado por el usuario, quien para poder

acceder a la aplicación web deberá de ingresar su nombre de usuario y su
contraseña.

Tabla 4.10 Ingreso al sistema [Fuente: Propia].

1- Caso de uso del sistema: Generar orden de devolución.

2- Actor: Encargado.

3- Descripción: El caso de uso es iniciado por el Encargado, quien es responsable

de generar la orden de devolución de las autopartes prestados. La orden de
devolución debe mostrar las autopartes que se requieran con suma urgencia
para su posterior venta, se debe considerar las fechas en las que se realizaron
los préstamos ya que la devolución se debe realizar cada cierto periodo.

Tabla 4.11 Generar orden de devolución [Fuente: Propia].

1- Caso de uso del sistema: Registrar usuario.

2- Actor: Supervisor.

3- Descripción: El caso de uso es iniciado por el Supervisor quien es el

responsable de registrar, modificar, y eliminar los datos de un nuevo usuario
en este caso de los posibles encargados; el sistema los registra y le genera un
 login y clave para acceder al sistema.

Tabla 4.12 Registrar Usuario [Fuente: Propia].

1- Caso de uso del sistema: Mantener información de responsables.

2- Actor: Supervisor.

3- Descripción: El caso de uso es iniciado por el Supervisor quien se ocupara de

registrar, modificar, y eliminar los datos de los responsables directos en el
préstamo de las autopartes en este caso del Almacenero.

Tabla 4.13 Mantener información de responsables [Fuente: Propia].

1- Caso de uso del sistema: Emitir reporte.

2- Actor: Supervisor.

3- Descripción: El caso de uso es iniciado por el Supervisor quien se ocupara de

Emitir Reportes, podrá generar reportes sobre los préstamos de las autopartes
por fechas, así como también sobre devolución y las autopartes pertenecientes
a un determinado almacén.

Tabla 4.14 Emitir reporte [Fuente: Propia].

4.1.3.2 Priorizar casos de uso

REQUISITO CASO DE USO

1 Registrar Usuario.
Controlar Préstamo de
Realizar seguimiento de 2 Autoparte.
productos prestados.
Generar Orden de
4 devolución.

1 Registrar Usuario.
Registrar información de los
Mantener Información de
responsables del préstamo.
3 Responsables.

Controlar Préstamo de
2 Autoparte.
Generar orden de devolución de
los productos. Generar Orden de
4 devolución.

Controlar el stock de los Controlar Préstamo de

productos prestados.
2 Autoparte.

Modificar productos en estado

de préstamo.

Mostrar información de los Emitir Reportes.

5
productos prestados a través de reportes.

Seguridad en la Aplicación Web 6 Ingreso al Sistema

Tabla 4.15 Relación de requisitos funcionales y casos de uso [Fuente: Propia]

Después de detallar la relación de los requerimientos con sus respectivos casos de uso
procederemos a establecer la prioridad de los casos de uso de acuerdo a su
importancia dentro del sistema. Considere la máxima prioridad con el mayor valor
asociado.

PRIORIDAD CASO DE USO

6 Controlar Préstamo de Autopartes.

5 Ingreso al Sistema

4 Generar Orden de devolución.

3 Registrar Usuario.

2 Mantener Información de Responsables.

1 Emitir Reportes.

Tabla 4.16 Priorizar casos de uso [Fuente: Propia].

4.1.3.3 Detallar casos de uso

CASOS DE USO CASOS DE USO RELACIONADOS

Registrar Préstamo de Autopartes.

Mantener Préstamo de Autopartes.

Controlar Préstamo de Autopartes.
Controlar Stock de Préstamo de
Autopartes.

Ingreso al Sistema. Ingreso al Sistema.

Mantener Devolución por periodo.

Generar Orden de devolución. Solicitar devolución por demanda en

Venta.

Mantener Usuario.
Registrar Usuario.
Modificar Registro de Usuario.
 Registrar Responsables.

Modificar Información de
Mantener Información de Responsables.
Responsables.

Generar Reporte de Préstamo por

fecha.

Generar Reporte de Productos por

Emitir Reportes. almacén.

Generar Reporte de Devolución.

Tabla N°4.17: Casos de uso relacionados [Fuente: Propia].

Después de haber listado nuestros requerimientos funcionales, de obtener a nuestros

actores, priorizar y detallar los casos de uso de nuestro sistema, pasaremos a mostrar
el siguiente diagrama que representa el Modelo de Casos de Uso del Sistema que se va
a implementar.
Figura 4.8 Diagrama de Casos de Uso de la Aplicación web para registrar y dar
seguimiento a productos prestados entre almacenes [Fuente Propia].
4.1.4 Diagrama de clases

Figura 4.9 Diagrama de clases inicial [Fuente Propia].

4.1.5 Prototipos

Figura 4.10 Prototipo acceso al sistema web [Fuente Propia].

 Figura 4.11 Prototipo bienvenida al sistema web [Fuente Propia].

Figura 4.12 Prototipo mantenimiento de autopartes [Fuente Propia].

Figura 4.13 Prototipo registrar préstamo de autopartes [Fuente Propia].

Figura 4.14 Prototipo mantener préstamo de autopartes [Fuente Propia].

 CAPÍTULO 5: APORTE PRÁCTICO

5.1 Diseño de la herramienta tecnológica

5.1.1 Casos de uso del negocio

5.1.1.1 Descripción en detalle de casos de uso del negocio

Caso de uso: Realizar pedido de producto.

Actor: Jefe de almacén.

Descripción: El caso de uso es iniciado por el jefe de almacén, quien es responsable de realizar el
pedido de productos al proveedor de autopartes, para realizar el pedido de autopartes se debe tener en
cuenta el código de producto, la cantidad, fecha de ejecución, fecha de entrega.

Activación: El caso de uso se activa cuando el jefe de almacén elige la opción Realizar Pedido de
Autopartes en el menú del sistema.

Curso normal Curso alternativo

1.
Se carga la ventana realizar pedido.

2.
El jefe de almacén ingresa la solicitud de 2.1 El sistema muestra un mensaje solicitando el
pedido de nuevas autopartes. llenado correcto de los datos.

3.
El sistema envía los datos ingresados del 3.1 Si hay alguna falla en el tipo de datos el
pedido de autopartes a la base de datos del sistema muestra un mensaje de error.
sistema.

4.
El sistema almacena la información en la
base de datos.

5.
El sistema envía un mensaje al jefe de 5.1 El jefe de almacén cancela la operación
almacén con respecto al almacenamiento Controlar Préstamo de Producto.
satisfactorio de la información.

Precondiciones: El jefe almacén debe estar conectado al sistema con su nombre de usuario y password.

Postcondiciones: Los datos del pedido han sido almacenados en la base de datos del sistema.

Puntos de extensión:

Observaciones y datos:
Caso de uso: Controlar producto.

Actor: Jefe de almacén, supervisor, encargado.

Descripción: El caso de uso es iniciado por el jefe de almacén, supervisor o encargado quienes se
encargan de registrar y dar seguimiento a las autopartes prestadas del almacén origen al almacén destino.

Activación: El caso de uso se activa cuando el jefe de almacén, el supervisor o encargado elige la opción
Controlar autopartes en el menú del sistema.

Curso normal Curso alternativo

1.
Se carga la ventana realizar pedido.

2.
El jefe de almacén, encargado o supervisor 2.1 El sistema muestra un mensaje solicitando el
registra mantiene y actualiza información llenado correcto de los datos.
sobre los préstamos de autopartes.

3.
El sistema envía los datos ingresados del 3.1 Si hay alguna falla en el tipo de datos el
registro mantenimiento de autopartes a la sistema muestra un mensaje de error.
base de datos del sistema.

4.
El sistema almacena la información en la
base de datos.

5.
El sistema envía un mensaje al jefe de 5.1 El jefe de almacén, supervisor o encargado
almacén encargado o supervisor con cancela la operación Controlar Producto.
respecto al almacenamiento satisfactorio de
la información.

Precondiciones: El jefe almacén, encargado o supervisor deben estar conectados al sistema con su
nombre de usuario y password.

Postcondiciones: Los datos del pedido han sido almacenados en la base de datos del sistema.

Puntos de extensión:

Observaciones y datos:

60
Caso de uso: Distribuir producto.

Actor: Distribuidor.

Descripción: El caso de uso es iniciado por distribuidor, quien se encarga conducir y llevar las autopartes
hacia los clientes que han comprado autopartes.

Activación: El caso de uso se activa cuando el distribuidor elige la opción distribuir producto en el menú
del sistema.

Curso normal Curso alternativo

1.
Se carga la ventana distribuir producto.

2.
El distribuidor ingresa la solicitud de 2.1 El sistema muestra un mensaje solicitando el
autopartes requeridas por el cliente llenado correcto de los datos.

3.
El sistema envía los datos ingresados sobre 3.1 Si hay alguna falla en el tipo de datos el
la distribución y envio de autopartes al sistema muestra un mensaje de error.
cliente, a la base de datos del sistema.

4.
El sistema almacena la información en la
base de datos.

5.
El sistema envía un mensaje al distribuidor 5.1 El jefe distribuidor cancela la operación
con respecto al almacenamiento Controlar Producto.
satisfactorio de la información.

Precondiciones: El distribuidor debe estar conectado al sistema con su nombre de usuario y password.

Postcondiciones: Los datos de las autopartes distribuidas a los clientes han sido almacenados en la base
de datos del sistema.

Puntos de extensión:

Observaciones y datos:

61
Caso de uso: Solicitar producto.

Actor: Almacenero.

Descripción: El caso de uso es iniciado por almacenero, quien se encarga solicitar las autopartes
del almacén de origen para que sean llevadas y conducidas al área de ventas.

Activación: El caso de uso se activa cuando el almacenero elige la opción solicitar producto en el menú
del sistema.

Curso normal Curso alternativo

1.
Se carga la ventana solicitar producto.

2.
El almacenero ingresa en el sistema la 2.1 El sistema muestra un mensaje solicitando el
autoparte solicitada por el área de ventas. llenado correcto de los datos.

3.
El sistema envía los datos ingresados sobre 3.1 Si hay alguna falla en el tipo de datos el
búsqueda de autopartes, a la base de datos sistema muestra un mensaje de error.
del sistema.

4.
El sistema confirma la existencia de las
autopartes solicitadas

5.
El sistema envía un mensaje al almacenero 5.1 El jefe almacenero cancela la operación
con respecto al almacenamiento solicitar prestamo
satisfactorio de la información.

Precondiciones: El almacenero debe estar conectado al sistema con su nombre de usuario y password.

Postcondiciones: Los datos de las autopartes solicitadas han sido almacenados en la base de datos del
sistema.

Puntos de extensión:

Observaciones y datos:

62
Caso de uso: Realizar venta.

Actor: Vendedor.

Descripción: El caso de uso es iniciado por el vendedor, quien se encarga de vender las autopartes a
loso clientes.

Activación: El caso de uso se activa cuando el vendedor elige la opción realizar ventas en el menú del
sistema.

Curso normal Curso alternativo

1.
Se carga la ventana realizar venta de
producto.

2.
El vendedor ingresa en el sistema las 2.1 El sistema muestra un mensaje solicitando el
autopartes y las cantidades a vender, asi llenado correcto de los datos.
como el nombre del cliente.

3.
El sistema envía los datos ingresados el 3.1 Si hay alguna falla en el tipo de datos el
registro de ventas de autopartes, a la base sistema muestra un mensaje de error.
de datos del sistema.

4.
El sistema almacena la información en la
base datos y emite una boleta o factura

5.
El sistema envía un mensaje al almacenero 5.1 El vendedor cancela la operación realizar
con respecto al almacenamiento venta.
satisfactorio de la información.

Precondiciones: El vendedor debe estar conectado al sistema con su nombre de usuario y password.

Postcondiciones: Los datos de las autopartes vendidas han sido almacenados en la base de datos del
sistema.

Puntos de extensión:

Observaciones y datos:

63
5.1.2 Casos de uso del sistema

5.1.2.1 Descripción en detalle de casos de uso del sistema

Caso de uso: 1. Controlar Préstamo de Autopartes.

Actor: Supervisor, Encargado.

Descripción: El caso de uso es iniciado por el supervisor o encargado, quien es responsable de realizar
el Control de Préstamo de Autopartes a otro almacén, el control de préstamo debe realizarse teniendo en
cuenta el código de producto, la cantidad, usuario, responsable, etc.

Activación: El caso de uso se activa cuando el Encargado elije la opción Controlar Préstamo de
Autopartes en el menú del sistema.

Curso normal Curso alternativo

1.
Se carga la ventana Control de Préstamo.

2.
El supervisor o encargado ingresa la 2.1 El sistema muestra un mensaje solicitando el
información del registro del préstamo o llenado correcto de los datos.
mantenimiento, esta incluye el producto,
cantidad, responsables, fecha, almacén de
origen, almacén de destino.

3.
El sistema envía los datos ingresados del 3.1 Si hay alguna falla en el tipo de datos el
préstamo o modificación del producto a la sistema muestra un mensaje de error.
base de datos del sistema.

4.
El sistema almacena la información en la
base de datos.

5.
El sistema envía un mensaje al supervisor o 5.1 El supervisor o encargado cancela la
encargado con respecto al almacenamiento operación Controlar Préstamo de Producto.
satisfactorio de la información.

Precondiciones: El supervisor o encargado debe estar conectado al sistema con su nombre de usuario y
password.

Postcondiciones: Los datos del control de préstamo de Autopartes han sido almacenados en la base de
datos del sistema.

Puntos de extensión:

Observaciones y datos:

64
Caso de uso: Registrar Préstamo de Autopartes.

Actor: Supervisor, Encargado.

Descripción: El caso de uso es iniciado por el Supervisor o Encargado, quien es responsable de realizar
el registro de préstamo de Autopartes a otro almacén, se debe tener en cuenta el código de producto,
descripción, para proceder al registro.

Activación: El caso de uso se activa cuando el Supervisor o Encargado elije la opción Registrar Préstamo
de autopartes en el menú del sistema.

Curso normal Curso alternativo

1.
Se carga la ventana Registrar Préstamo de
Autoparte.

2.
El supervisor o encargado ingresa la 2.1 El sistema muestra un mensaje solicitando el
información del registro del préstamo la llenado correcto de los datos.
cual incluye el producto, cantidad,
responsable, fecha, almacén de origen
almacén de destino.

3.
El sistema envía los datos ingresados del
préstamo de las autopartes a la base de
datos del sistema.

4.
El sistema almacena la información en la
base de datos.

5.
El sistema muestra la interface para un 5.1 El Usuario cancela la operación Registrar
nuevo préstamo y genera el código de Préstamo de Autopartes.
préstamo de manera automática.

Precondiciones: El Supervisor o Encargado, debe estar conectado al sistema con su nombre de usuario
y password.

Postcondiciones: Los datos del registro del préstamo de las autopartes han sido almacenados en la base
de datos del sistema.

Puntos de extensión:

Observaciones y datos:

65
Caso de uso: Mantener Préstamo de Autopartes.

Actor: Supervisor, Encargado.

Descripción: El caso de uso es iniciado por el Supervisor o Encargado, quien es responsable de

modificar o eliminar el préstamo de producto, lo cual debe realizarse teniendo en cuenta el código del
préstamo o la fecha.

Activación: El caso de uso se activa cuando el Supervisor o Encargado elije la opción Mantener Préstamo
de Autopartes en el menú del sistema.

Curso normal Curso alternativo

1.
Se carga la ventana Mantener Préstamo de
Autopartes.

2.
El supervisor o encargado ingresa la 2.1 El sistema muestra un mensaje solicitando el
información concerniente a la modificación llenado correcto de los datos.
o eliminación del préstamo, esta es por
código de préstamo o por fecha de
préstamo.

3.
El sistema envía los datos sobre la
modificación o eliminación del préstamo de
las autopartes a la base de datos del
sistema.

4.
El sistema almacena la información de
mantenimiento en la base de datos.

5.
El sistema muestra la interface para un 5.1 El supervisor o encargado cancela la
nuevo préstamo y genera el código de operación Mantener Préstamo de
préstamo de manera automática. Autopartes.

Precondiciones: El supervisor o encargado debe estar conectado al sistema con su nombre de usuario y
password.

Postcondiciones: Los datos del mantenimiento de préstamo de producto han sido almacenados en la
base de datos del sistema.

Puntos de extensión:

Observaciones y datos:

66
Caso de uso: Controlar Stock de Préstamo de Autopartes.

Actor: Supervisor, Encargado.

Descripción: El caso de uso es iniciado por el supervisor o encargado, quien es responsable de realizar
el control de stock de préstamo de autopartes, deberá manejar el stock de las autopartes prestados de
manera actualizada, indicando el inventario de los mismos.

Activación: El caso de uso se activa cuando el supervisor o Encargado elije la opción Mantener
Autopartes en el menú del sistema.

Curso normal Curso alternativo

1.
Se carga la ventana Mantenimiento de
Autoparte.

2.
El Supervisor o Encargado ingresa el código 2.1 El sistema muestra un mensaje solicitando el
de autoparte o descripción de la autoparte, llenado correcto de los datos.
indicando el almacén al que pertenece.

3.
El sistema envía los datos ingresados sobre
el control de stock de autopartes a la base
de datos del sistema.

4.
El sistema muestra al Supervisor o 4.1 El Supervisor o encargado cancela la
Encargado el stock de las autopartes operación controlar stock de préstamo de
prestados. producto.

Precondiciones: El supervisor o encargado debe estar conectado al sistema con su nombre de usuario y
password.

Postcondiciones: Los datos sobre el control de stock de préstamo de autopartes han sido emitidos en un
formulario simple dentro del sistema.

Puntos de extensión:

Observaciones y datos:

67
Caso de uso: Ingreso al Sistema.

Actor: Encargado Supervisor.

Descripción: El caso de uso es iniciado por el Encargado o Supervisor, quien para poder acceder a
la aplicación web deberá de ingresar su nombre de usuario y su contraseña.

Activación: El caso de uso se activa cuando el Encargado o Supervisor ingresa el URL de la página e
inician su autenticación.

Curso normal Curso alternativo

1.
Se carga la ventana de logeo de Usuario.

2.
El sistema pide al usuario que introduzca su 2.1 El sistema muestra un mensaje solicitando
nombre de usuario y su password. que el campo nombre de Usuario y su
password sean rellenados.

3.
El sistema valida los datos ingresados por el 3.1 Si los datos son incorrectos el Sistema le
usuario y si son correctos el Usuario ingresa mostrara un mensaje de error en el acceso.
a la Aplicación Web.

4.
El Usuario cancela la operación Ingreso al
Sistema

Precondiciones: El Encargado o Supervisor deben estar dados de alta de la aplicación Web.

Postcondiciones: El Usuario tendrá acceso restringido de acuerdo a su tipo de usuario esto es user o
admin.

Puntos de extensión:

Observaciones y datos:

68
Caso de uso: 2. Generar Orden de devolución.

Actor: Encargado.

Descripción: El caso de uso es iniciado por el Encargado, quien es responsable de generar la orden de
devolución de las autopartes prestados. La orden de devolución debe mostrar las autopartes que se
requieran con suma urgencia para su posterior venta, se debe considerar las fechas en las que se
realizaron los préstamos ya que la devolución se debe realizar cada cierto periodo.

Activación: El caso de uso se activa cuando el Encargado elije la opción Generar Orden de devolución en
el menú del sistema.

Curso normal Curso alternativo

1.
Se carga la ventana Generar Orden de
Devolución.

2.
El Encargado selecciona las autopartes para
ser devueltos ya sea porque tienen alta
demanda en el área de ventas o por periodo
de devolución.
2.1 El sistema debe mostrar por periodo (día,
mes, ano) los productos registrados por
préstamo.
2.2 El sistema muestra un mensaje solicitando el
llenado correcto de los datos.

3.
El sistema envía los datos ingresados de la 3.1 Si hay alguna falla en el tipo de datos el
orden de devolución a la base de datos del sistema muestra un mensaje de error.
sistema.

4.
El sistema almacena la información en la
base de datos.

5.
El sistema envía un mensaje al Encargado 5.1 El Encargado cancela la operación generar
con respecto al almacenamiento orden de devolución.
satisfactorio de la información.

Precondiciones: El Encargado debe estar conectado al sistema con su nombre de usuario y password.

Postcondiciones: Los datos de la Orden de devolución de las autopartes han sido almacenados en la
base de datos del sistema.

Puntos de extensión:

Observaciones y datos:

69
Caso de uso: 3. Registrar Usuario.

Actor: Supervisor.

Descripción: : El caso de uso es iniciado por el Supervisor quien es el responsable de registrar,

modificar, y eliminar los datos de un nuevo usuario en este caso de los posibles encargados; el sistema
los registra y le genera un login y clave para acceder al sistema.

Activación: El caso de uso se activa cuando el Supervisor elije la opción Registrar Usuario en el menú del
sistema.

Curso normal Curso alternativo

1.
Se carga la ventana Registrar Usuario.

2.
El Supervisor ingresa los datos personales 2.1 Si el Supervisor no valido correctamente los
de los usuarios del sistema en este caso de datos personales del usuario, el sistema
los encargados. envía un mensaje de error.

3.
El Supervisor genera el login y password del
usuario. El sistema envía los datos del
usuario que han sido registrados por el
Supervisor.

4.
El sistema almacena la información en la
base de datos.

5.
El sistema muestra una lista con los 5.1 El Supervisor cancela la operación registrar
Usuarios registrados por el Supervisor. usuario.

Precondiciones: El Supervisor debe estar conectado al sistema con su nombre de usuario y password.

Postcondiciones: El Usuario queda almacenado en la base de datos del sistema.

Puntos de extensión:

Observaciones y datos:

70
Caso de uso: 4. Mantener Información de Responsables.

Actor: Supervisor.

Descripción: El caso de uso es iniciado por el Supervisor quien se ocupara de registrar, modificar, y
eliminar los datos de los responsables directos en el préstamo de las autopartes en este caso del
Almacenero.

Activación: El caso de uso se activa cuando el Supervisor elije la opción Mantener Información de
Responsables en el menú del sistema.

Curso normal Curso alternativo

1.
Se carga la ventana Mantener Información
de Responsables.

2.
El Supervisor ingresa los datos personales 2.1 Si el Supervisor no valido correctamente los
del responsable en este caso del datos personales del empleado, el sistema
Almacenero, así como también podrá envía un mensaje de error.
modificarla actualizarla e incluso eliminarla.

3.
El Supervisor genera un código para el
Almacenero el cual lo diferenciara de los
demás individuos.

4.
El sistema almacena la información en la
base de datos.

5.
El sistema muestra una lista con los 5.1 El Supervisor cancela la operación mantener
responsables registrados por el Usuario. información de responsables.

Precondiciones: El Supervisor debe estar conectado al sistema con su nombre de usuario y password.

Postcondiciones: los datos del responsable quedan almacenados en la base de datos del sistema.

Puntos de extensión:

Observaciones y datos:

71
Caso de uso: 5. Emitir Reportes.

Actor: Supervisor.

Descripción: El caso de uso es iniciado por el Supervisor quien se ocupara de Emitir Reportes, podrá
generar reportes sobre los préstamos de las autopartes por fechas, así como también sobre devolución y
las autopartes pertenecientes a un determinado almacén.

Activación: El caso de uso se activa cuando el Supervisor elije la opción Emitir Reportes en el menú del
sistema.

Curso normal Curso alternativo

1.
Se carga la ventana Emitir Reportes.

2.
El Supervisor elige de un conjunto de
opciones los reportes que desea emitir ya
sea reporte de préstamo por fechas, reporte
de devolución, autopartes y reporte de
autopartes por un determinado almacén.

3.
El Supervisor podrá detallar en el sistema 3.1 Si hay alguna falla en el tipo de datos el
los distintos reportes por fecha, es decir en sistema muestra un mensaje de error.
que periodo se llevo a cabo el préstamo de
una determinada autoparte.

4.
El sistema muestra el reporte solicitado por 4.1 El Supervisor cancela la operación Emitir
el Usuario. Reporte.

Precondiciones: El Supervisor debe estar conectado al sistema con su nombre de usuario y password,
del mismo modo los préstamos deben estar debidamente registrados en el sistema.

Postcondiciones: Se obtiene la información sobre los diversos préstamos detallados en los reportes.

Puntos de extensión:

Observaciones y datos:

72
5.1.2.2 Diagrama de secuencia de casos de uso del sistema

Figura 5.1 Diagrama de Secuencia Registrar Préstamo de Autopartes [Fuente Propia].

73
Figura 5.2 Diagrama de Secuencia Mantener Préstamo de Autopartes [Fuente Propia].

74
Figura 5.3 Diagrama de Secuencia Controlar Stock de Préstamo de Autopartes [Fuente
Propia].

Figura 5.4 Diagrama de Secuencia Ingresar al Sistema [Fuente Propia].

75
Figura 5.5 Diagrama de Secuencia Generar Orden de Devolución [Fuente Propia].

Figura 5.6 Diagrama de Secuencia Registrar Usuario [Fuente Propia].

Figura 5.7 Diagrama de Secuencia Mantener Información de Responsables [Fuente
Propia].

Figura 5.8 Diagrama de Secuencia Emitir Reporte [Fuente Propia].

5.1.2.3 Diagrama de actividades de casos de uso del sistema

Figura 5.9 Diagrama de Actividades Registrar Préstamo de Autopartes [Fuente Propia].

Figura 5.10 Diagrama de Actividades Mantener Préstamo de Autopartes [Fuente
Propia].
Figura 5.11 Diagrama de Actividades Controlar Stock de Préstamo de Autopartes
[Fuente Propia].

Figura 5.12 Diagrama de Actividades Ingresar al Sistema [Fuente Propia].

Figura 5.13 Diagrama de Actividades Generar Orden de Devolución [Fuente Propia].

Figura 5.14 Diagrama de Actividades Registrar Usuario [Fuente Propia].

Figura 5.15 Diagrama de Actividades Mantener Información de Responsables [Fuente
Propia].

Figura 5.16 Diagrama de Actividades Emitir Reporte [Fuente Propia].

5.1.3 Diagrama de clases

Figura 5.17 Diagrama de clases [Fuente Propia].

5.1.4 Diagrama de componentes

A continuación se muestran las dependencias entre los componentes, donde cada

componente ofrece una interface y utiliza otras, debemos aclarar en este punto que si
la dependencia entre componentes se hace a través de interfaces entonces los
componentes se pueden sustituir por otros componentes que realicen las mismas
interfaces. Cada componente mostrado en el diagrama representa la parte física del
Sistema Web de Control de Préstamo de Autopartes.

Figura 5.18 Diagrama de componentes [Fuente Propia].

5.1.5 Diagrama de despliegue

El diagrama de despliegue ilustra la forma en que luce el Sistema físicamente cuando

sea conjugado, aquí se muestra un Servidor de Aplicación que conecta un Servidor de
Base de Datos, del mismo modo el Servidor de Aplicación se conecta a las PC de
Usuario la cual cuenta con un navegador web.

Figura 5.19 Diagrama de despliegue [Fuente Propia].

5.1.6 Modelo físico de la base de datos

La base de datos del Sistema de Control de Préstamo de Autopartes se desarrolló en

ORACLE SQL DEVELOPER y para poder separar la capa de datos de la lógica de
negocio, usaremos un JDBC (Conector de base de datos). Por otra parte esta capa se
va a encargar de crear las consultas SQL para las operaciones básicas de insertado,
eliminación, actualización y recuperación de datos.

Modelo de datos:

Figura 5.20 Implementación de la Base de Datos [Fuente Propia].

Tablas físicas diccionario de datos:

 Tabla Empleado

Name Code Data Length Comment

Type
código_empleado código_empleado varchar 5 Indica el código de
empleado
nombres_empleado nombres_empleado char 20 Indica el nombre de
empleado
apellidos_empleado apellidos_empleado char 20 Indica el apellido de
empleado

Tabla 5.1 Tabla empleado [Fuente propia].

 Tabla Tipo Usuario

Name Code Data Length Comment

Type
código_tipo_usuario código_tipo_usuario varchar 5 Indica el código de tipo
usuario
tipo_usuario tipo_usuario char 10 Indica que tipo usario
(user,adm)

Tabla 5.2 Tabla tipo usuario [Fuente propia].

 Tabla Usuario

Name Code Data Length Comment

Type
código_usuario código_usuario varchar 5 Indica el código de
usuario
usuario Usuario varchar 20 Indica el login de
usuario
password Password varchar 20 Indica la clave de
usuario
nombre_completo nombre_completo char 30 Indica el nombre de
usuario
código_tipo_usuario código_tipo_usuario varchar 5 Indica el código de tipo
usuario

Tabla 5.3 Tabla usuario [Fuente propia].

  Tabla Préstamo

Name Code Data Length Comment

Type
código_prestamo código_prestamo varchar 5 Indica el código de
préstamo
almacen_origen almacen_origen varchar 50 Indica el almacén de
origen
almacen_destino almacen_destino varchar 50 Indica el almacén de
destino
código_usuario código_usuario varchar 5 Indica el código de
usuario
código_empleado código_empleado varchar 5 Indica el código de
empleado
fecha_prestamo fecha_prestamo date Indica la fecha de
préstamo

Tabla 5.4 Tabla préstamo [Fuente propia].

 Tabla Detalle de Préstamo

Name Code Data Length Comment

Type
código_detalle código_detalle varchar 5 Indica el código de detalle
código_prestamo código_prestamo varchar 5 Indica el código de
préstamo
código_producto código_producto varchar 5 Indica el código de
producto
cantidad_préstamo cantidad_préstamo number Indica la cantidad
solicitada
código_almacen código_almacen varchar 5 Indica el código de
almacén

Tabla 5.5 Tabla detalle de préstamo [Fuente propia].

  Tabla Autoparte

Name Code Data Length Comment

Type
código_producto código_producto varchar 5 Indica el código de
producto
descripcion_producto descripcion_producto char 50 Indica la descripción
producto
marca_producto marca_producto char 20 Indica la marca de
producto
codigo_tipo_producto codigo_tipo_product varchar 5 Indica el código de
o tipo de producto
cantidad_producto cantidad_producto number Indica la cantidad de
strock
unidad_medida unidad_medida char 10 Indica la unidad de
medida
código_almacen código_almacen varchar 5 Indica el código de
almacén

Tabla 5.6 Tabla autoparte [Fuente propia].

 Tabla Tipo de autoparte

Name Code Data Length Comment

Type
código_tipo_autopa código_tipo_autopa varchar 5 Indica el código de tipo
rte rte autoparte
tipo_producto tipo_producto char 15 Indica el tipo de
autoparte
descripción_tipo_pr descripción_tipo_pr char 20 Indica la descripción tipo
oducto oducto de autoparte

Tabla 5.7 Tabla tipo de autoparte [Fuente propia].

  Tabla Almacén

Name Code Data Length Comment

Type
código_almacen código_almacen varchar 5 Indica el código de
almacén
nombre_almacen nombre_almacen char 50 Indica el nombre de
almacén
direccion_almacen direccion_almacen varchar 50 Indica la dirección de
almacén

Tabla 5.8 Tabla almacén [Fuente propia].

Script de creación de base de datos:

 Tabla Empleado

create table "tb_empleado"

( "codigo_empleado" varchar2(5),

"nombres_empleado" char(20),

"apellidos_empleado" char(20),

constraint "pk_codigoempleado" primary key ("codigo_empleado") enable

);

 Tabla Tipo Usuario

create table "tb_tipo_usuario"

( "codigo_tipo_usuario" varchar2(5),
"tipo_usuario" char(10),
constraint "pk_codigotipousuario" primary key ("codigo_tipo_usuario") enable
);

 Tabla Usuario

create table "tb_usuario"

( "codigo_usuario" varchar2(5),
"usuario" varchar2(20),
"password" varchar2(20),
 "nombre_completo" char(30),
"codigo_tipo_usuario" varchar2(5),
constraint "pk_codigousuario" primary key ("codigo_usuario") enable
) ;alter table "tb_usuario" add constraint "fk_codigotipousuario1" foreign key
("codigo_tipo_usuario")
references "tb_tipo_usuario" ("codigo_tipo_usuario") enable;

 Tabla Préstamo

create table "tb_prestamo"

( "codigo_prestamo" varchar2(5),
"almacen_origen" varchar2(50),
"almacen_destino" varchar2(50),
"codigo_usuario" varchar2(5),
"codigo_empleado" varchar2(5),
"fecha_prestamo" date,
constraint "pk_codigoprestamo" primary key ("codigo_prestamo") enable
) ;alter table "tb_prestamo" add constraint "fk_codigoempleado1" foreign key
("codigo_empleado")
references "tb_empleado" ("codigo_empleado") enable;alter table
"tb_prestamo" add constraint "fk_codigousuario1" foreign key ("codigo_usuario")
references "tb_usuario" ("codigo_usuario") enable;

 Tabla Detalle de Préstamo

create table "tb_detalle_prestamo"

( "codigo_detalle" varchar2(5),
"codigo_prestamo" varchar2(5),
"codigo_producto" varchar2(5),
"cantidad_prestamo" number(*,0),
"codigo_almacen" varchar2(5),
constraint "pk_codigodetalle" primary key ("codigo_detalle") enable
) ;alter table "tb_detalle_prestamo" add constraint "fk_codigoproducto" foreign key
("codigo_producto", "codigo_almacen")
references "tb_autoparte" ("codigo_producto", "codigo_almacen")
enable;alter table "tb_detalle_prestamo" add constraint "fk_codigouprestamo" foreign
key ("codigo_prestamo")
references "tb_prestamo" ("codigo_prestamo") enable;
 Tabla Autoparte

create table "tb_autoparte"

( "codigo_producto" varchar2(5),
"descripcion_producto" char(50),
"marca_producto" char(20),
"codigo_tipo_producto" varchar2(5),
"cantidad_producto" number(*,0),
"unidad_medida" char(10),
"codigo_almacen" varchar2(5),
constraint "pk_codigoproducto" primary key ("codigo_producto",
"codigo_almacen") enable
) ;alter table "tb_autoparte" add constraint "fk_codigoalmacen" foreign key
("codigo_almacen")
references "tb_almacen" ("codigo_almacen") enable;alter table
"tb_autoparte" add constraint "fk_codigotipoproducto1" foreign key
("codigo_tipo_producto")
references "tb_tipo_autoparte" ("codigo_tipo_producto") enable;

 Tabla Tipo de autoparte

create table "tb_tipo_autoparte"

( "codigo_tipo_producto" varchar2(5),
"tipo_producto" char(15),
"descripcion_tipo_producto" char(20),
constraint "pk_codigotipoproducto" primary key ("codigo_tipo_producto")
enable
);

 Tabla Almacén

create table "tb_almacen"

( "codigo_almacen" varchar2(5),
"nombre_almacen" char(50),
"direccion_almacen" varchar2(50),
constraint "pk_codigoalmacen" primary key ("codigo_almacen") enable
);
5.1.7 Interfaces de usuario

Figura 5.21 Login de Usuario [Fuente Propia].

Figura 5.22 Acceso al sistema [Fuente Propia].

Figura 5.23 Mantenimiento de autopartes [Fuente Propia].

94
Figura 5.24 Registrar préstamo de autopartes [Fuente Propia].

95
Figura 5 25 Búsqueda y selección de autoparte para préstamo [Fuente Propia].

96
Figura 5.26 Autopartes agregados a lista de préstamo [Fuente Propia].

97
Figura 5.27 Mantenimiento de préstamo de autopartes [Fuente Propia].

98
Figura 5.28 Búsqueda de préstamo de autopartes [Fuente Propia].

99
Figura 5.29 Reporte de préstamo de autopartes [Fuente Propia].

Figura 5.30 Búsqueda de préstamo de autopartes [Fuente Propia].

100
Figura 5.31 Reporte de préstamo de autopartes por fecha [Fuente Propia].

101
Figura 5.32 Búsqueda autopartes por almacén [Fuente Propia].

102
 CAPÍTULO 6: CONCLUSIONES Y TRABAJOS FUTUROS

6.1 Conclusiones

1. La aplicación web de registro y seguimiento de autopartes, permite no solo dar

solución a la problemática generada por el préstamo de autopartes entre el
almacén de origen y destino, sino que mantiene actualizado todos los
prestamos llevados a cabo, logrando la satisfacción de la gerencia de la
empresa.

2. Las tecnologías usadas fueron las adecuadas para la implementación de la

aplicación web de préstamos de autopartes.

3. La lógica de programación empleada en la aplicación web, cubre las exigencias

de la empresa y permite posteriores mejoras y modificaciones tanto en el
diseño como en el funcionamiento, empleando un mínimo de cambios en la
estructura del código escrito, debido a que es una aplicación que utiliza el
esquema MVC para el desarrollo de los componentes.

4. La aplicación web resulta satisfactoria en términos de ajuste a los

requerimientos establecidos y en medida similar en relación a las necesidades
de los usuarios, cumpliendo así con los objetivos trazados inicialmente,
abarcando con las funcionalidades que se exigen en los procesos del negocio.

5. La propuesta del empleo de una aplicación web de registro y seguimiento de

autopartes, permite considerables beneficios que ayudan a que la labor en el
almacén origen y destino se realice de manera más integra y rápida,
reduciendo la falla humana durante el proceso de préstamo de autopartes.

6.2 Trabajos futuros

1. Desarrollo de módulos de devolución de préstamos, ventas y facturación, para

realizar la venta de autopartes a través de la aplicación web, impresión de
facturas electrónicas de las compras realizadas por los clientes, a través de
internet.

2. Desarrollar nuevas interfaces para la búsqueda de autopartes en los diversos

almacenes, así como también construir un chat en tiempo real para el

103
 seguimiento de los préstamos, y para que puedan ser utilizados en los módulos
de ventas entre el vendedor y el cliente.

3. Dentro de los trabajos futuros podríamos indicar la implementación del

reconocimiento de las autopartes a través de código de barras, para controlar
de forma segura el inventario.

4. Con la experiencia adquirida podrían realizarse otras aplicaciones Web de

mayor dificultad, experimentar con las cargas de la base de datos y ver cuáles
son los límites del lenguaje y framework elegidos.
 REFERENCIAS BIBLIOGRÁFICAS

Ceballos Sierra, J. (2012). Interfaces graficas y aplicaciones para internet. España: RA-
MA.

Chavez Gomez, V. (2010). Sistema de Informacion para el control, seguimiento y

mantenimiento del equipo hospitalario. Lima.

Cibertec. (2010). Desarrollo de Aplicaciones Web II. Lima.

Estatal, A. P. (2007). Manual de Procedimientos del Departamento de Almacen.

Mexico.

Fernandez Peña, J. (2007). Iconix Notas del metodo con ampliaciones y mejoras.

General, D. (2010). Manual de procedimientos para el manejo de almacenes. Fondo de

cultura economica.

Goicochea Rojas, M. (2009). Sistema de control de inventarios del almacen de

productos terminados en una empresa metal mecanica. Lima.

Hernandez Muñoz, R. (2012). Libro de Logistica de Almacenes. Cuba.

Iglesias, A. (2012). Manual de Gestion de Almacen.

Jacobson, I., Boosch, G., & Rambaugh, J. (2000). El Proceso Unificado de Desarrollo
de Software. Madrid: Addison Wesley.

Larman, C. (2012). Una introduccion basica a la teoria y practica de scrum.

Lujan Mora, S. (2012). Programacion de Aplicaciones Web. Alicante: Club

Universitario.

Mateu, C. (2004). Desarrollo de Aplicaciones Web. Barcelona: Eureca Media.

Mayor Martin, D. (2014). Evaluacion de Spring MVC. Alcala.

Mora Garcia, L. (2011). Gestion Logistica de Almacenes. Bogota: Ecoe Ediciones.

Rueda Chacon, J. (2006). Aplicacion de la Metodologia RUP para el desarrollo rapido

de aplicaciones basado en el estandar J2EE. Guatemala.

Sanchez Asenjo, J. (2011). Servidores de Aplicaciones Web. España: Creative Commos.

Sarasty España, H. (2015). documentacion y analisis de los principales frameworks de
arquitectura de software en aplicaciones epresariales. La Plata.

Scrum Body, o. (2016). Una guia para el conocimiento de SCRUM. Scrumstudy.

Sierra y Acosta, J. (2008). Administracion de Almacenes y Control de Inventario.

Mexico: Enciclopedia Virtual.

Sommerville, I. (2005). Ingenieria del Software. Madrid: Addison wesley.

Trigas Gallego, M. (s.f.). Gestion de Proyectos Informaticos Metodologia Scrum.

Yaccherima Espin, L. (2011). Implementacion de un software orientado a la web que

gestione la aplicacion de la tecnica de calidad seis sigma al proceso de
desarrollo de software, sobre la plataforma java enterprise edition 5.0
empleando un framework integrador JBoss Seam 2.2.0. Sangolqui.
 Anexo I

Guía de entrevista para recolección de información en la Empresa RAMLE

CAR.

Objetivo: Conocer la información necesaria para la factibilidad del desarrollo de la

aplicación web, desde el punto de vista operativo.

Indicaciones: por favor responda de forma objetiva, pues de ello dependen los
resultados del trabajo.

Lugar: Fecha:
Entrevistado: Área:

1. ¿Cómo definiría su nivel de conocimiento en el área de informática?

2. Mencione los sistemas operativos que conoce

3. Mencione los navegadores web que conoce

a
4. ¿Qué programas utiliza actualmente para la realización de sus tareas laborales?

5. ¿Considera que un nuevo sistema informático facilitara sus tareas laborales?

¿Por qué?

6. ¿Está dispuesto a recibir capacitaciones para el uso de un nuevo sistema

informático para el mejoramiento de sus tareas laborales?

b
 Anexo II

Encuesta de diagnóstico de situación actual en el área de logística almacén

de la Empresa RAMLE CAR.

Objetivo: Conocer la información necesaria para determinar los requerimientos en el

desarrollo de la aplicación web.

Indicaciones: por favor responda de forma objetiva, pues de ello dependen los
resultados del trabajo.

Lugar: Fecha:
Entrevistado: Área:

1. ¿Podría definir las tareas y actividades que realiza en el área de almacén?

2. ¿Qué problemas se presentan durante sus actividades diarias?

3. ¿Durante el proceso de préstamo de autopartes entre almacenes que incidente,

errores o fallos se presentan en el registro de préstamos?

c
4. ¿Qué mecanismos utiliza para registrar los préstamos de autopartes?

5. ¿Posee información almacenada en hojas o archivos digitales sobre registro,

seguimiento y reportes de devolución de autopartes?

d
 Anexo III

Formato de plantilla de registro de préstamo de autopartes en el área de

logística almacén de la Empresa RAMLE CAR.

ITEM Código Almacén Almacén Cantidad Responsable Responsable Fecha de

producto Origen Destino en entregar en recibir préstamo
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Firma del responsable en entregar Firma del responsable en recibir

Código de responsable: Código de responsable:

e
 Anexo IV

Código fuente del módulo principal préstamo de autopartes ubicado en el

paquete pe.com.scpp.portal.web.controller de la aplicación web de la
Empresa RAMLE CAR.

 Sentencia para realizar préstamo de autopartes

public ModelAndView movimientoProducto(HttpServletRequest request,

HttpServletResponse response) throws Exception
{
logger.debug("=================Movimiento Producto===============");
ModelAndView model = new ModelAndView(Constantes.JSP_INIT_PRESTAMO);
List<Prestamo> lstPrestamo = new ArrayList<Prestamo>();
//Prestamo prestamo = null;
PrestamoForm prestamoForm = new PrestamoForm();
Prestamo prestamo = (Prestamo)request.getAttribute("prestamoBean");
String tipoBusqueda = (String)request.getAttribute("tipoBusqueda");
try{
prestamoForm.setUsuarioSistema(userSessionBean.getUsuario().getUsuario());
prestamoForm.setFechaPrestamo(sdf.format(new Date()));
lstPrestamo = prestamoService.getPrestamo(prestamo,tipoBusqueda);
List<Almacen> lstAlmacen = prestamoService.getAlmacen(null);
logger.info("Almacen: " + lstAlmacen.size());
List<Empleado> lstEmpleado = prestamoService.getEmpleado(null);
////////////////////AUTOGENERAR CODIGO PRESTAMO////////////////////
String codigoPrestamo = prestamoService.getCodigoPrestamo();
logger.debug("codigoPrestamo: " + codigoPrestamo);
int codigo = Integer.parseInt(StringUtils.remove(codigoPrestamo, 'P'));
codigo++;
logger.debug("codigo1: " + codigo);
logger.debug("codigo2: " + 'P'+StringUtils.leftPad(codigo+"", 4, '0'));
prestamoForm.setCodigoPrestamo('P'+StringUtils.leftPad(codigo+"", 4, '0'));
//////////////////////////////////////////////////////////////////
model.addObject("lstAlmacen", lstAlmacen);
model.addObject("lstEmpleado", lstEmpleado);
model.addObject("lstPrestamo", lstPrestamo);
model.addObject("prestamoForm", prestamoForm);
model.addObject("update_prestamo", Constantes.PARAMETER_NEW);
model.addObject(Constantes.TITULO, "REGISTRAR PRESTAMO");
userSessionBean.remove("ListaProductoDetalle");
}catch (Exception e) {
// TODO: handle exception
logger.error(e.getMessage(),e);
}
return model;
}

f
  Sentencia para listar autopartes prestadas

public ModelAndView listarPrestamo(HttpServletRequest request,

HttpServletResponse response) throws Exception
{
logger.debug("=================Lista de Prestamo===============");
ModelAndView model = new ModelAndView(Constantes.JSP_INIT_LISTAR);
List<Prestamo> lstPrestamo = new ArrayList<Prestamo>();
PrestamoForm prestamoForm = new PrestamoForm();
Prestamo prestamo = (Prestamo)request.getAttribute("prestamoBean");
String tipoBusqueda = (String)request.getAttribute("tipoBusqueda");
try{
logger.debug("PrestamoBean: " + prestamo);
logger.debug("TipoBusqueda: " + tipoBusqueda);
prestamoForm.setTipoBusqueda("C");
lstPrestamo = prestamoService.getPrestamo(prestamo,tipoBusqueda);
if (!CollectionUtils.isEmpty(lstPrestamo)){
if (lstPrestamo.size()>20){
lstPrestamo = lstPrestamo.subList(0, 20);
}
}
model.addObject("lstPrestamo", lstPrestamo);
model.addObject("prestamoForm", prestamoForm);
}catch (Exception e) {
// TODO: handle exception
logger.error(e.getMessage(),e);
}
return model;
}
 Sentencia para guardar préstamo

public ModelAndView savePrestamo(HttpServletRequest request,

HttpServletResponse response, PrestamoForm prestamoForm) throws Exception
{
logger.debug("=================SAVE Prestamo===============");
String codigo = request.getParameter("codigo");
String parametro = request.getParameter(Constantes. PARAMETER);
String[] datos = request.getParameter("productos").split(":");
logger.debug("codigo prestamo: " + prestamoForm.getCodigoPrestamo() );
Prestamo prestamo = new Prestamo();
Producto producto = null;
List<Producto> lstProducto = new ArrayList<Producto>();
//traer codigo de prestamo!!!!
prestamoForm.setCodigoPrestamo(codigo);
logger.debug("Codigo Prestamo: "+ codigo);
logger.debug("Productos: "+ datos);
prestamo.setCodigoPrestamo(prestamoForm.getCodigoPrestamo());
prestamo.setAlmacenOrigen(prestamoForm.getAlmacenOrigen());

g
prestamo.setAlmacenDestino(prestamoForm.getAlmacenDestino());
prestamo.setUsuarioSistema(prestamoForm.getUsuarioSistema());
prestamo.setResponsablePrestamo(prestamoForm.getResponsablePrestamo());
prestamo.setFechaPrestamo(prestamoForm.getFechaPrestamo());
try {
logger.info("Parametro: " + parametro);
logger.info("Codigo: " + prestamoForm.getCodigoPrestamo());
logger.info("Almacen Origen: " + prestamoForm.getAlmacenOrigen());
logger.info("Almacen Destino: " + prestamoForm.getAlmacenDestino());
logger.info("Usuario: " + prestamoForm.getUsuarioSistema());
logger.info("Responsable: " + prestamoForm.getResponsablePrestamo());
logger.info("Fecha: " + prestamoForm.getFechaPrestamo());
for (int i = 0; i < datos.length; i++) {
producto = new Producto(); String[] prods =
datos[i].split(","); producto.setCodigoProducto(prods[0]);
producto.setCantidadProducto(Integer.parseInt(prods[1]));
producto.setCantidadProductoD(Integer.parseInt(prods[2]));
logger.debug("Producto: " + datos[i]);
logger.debug("Codigo..: " + prods[0]);
logger.debug("Stock..: " + prods[1]);
logger.debug("CantidadPrestamo..: " + prods[2]);
lstProducto.add(producto);
logger.debug("Cantidad de Productos en detalle: " + lstProducto.size());
}
logger.debug("Productos a guardar: " + lstProducto.size());
prestamo.setLstProducto(lstProducto);
List<Producto> array = (List<Producto>) userSessionBean.get("ProductosEliminados");
///////////////metodo para elimnar producto en detalle ubicado en
saveprestamo//////////////////////
prestamoService.updatePrestamo(prestamo, parametro, array);
} catch (Exception e) {
// TODO: handle exception
logger.error(e.getMessage(),e);
}
return movimientoProducto(request, response);
}

 Sentencia para actualizar préstamo

public ModelAndView actualizarPrestamo(HttpServletRequest request,

HttpServletResponse response, PrestamoForm prestamoForm) throws Exception
{
logger.debug("=================UPDATE Prestamo===============");
ModelAndView model = new ModelAndView(Constantes.JSP_INIT_PRESTAMO);
String codigoPrestamo = request.getParameter(Constantes.PARAMETER_ID);
String parametro = request.getParameter(Constantes.PARAMETER);
Prestamo prestamo = prestamoService.getPrestamo(codigoPrestamo);
logger.debug("Parametro: "+parametro );
logger.debug("codigo prestamo: "+codigoPrestamo );
//para eliminar todo el prestamo
if (StringUtils.equals(parametro, Constantes.PARAMETER_DELETE)){
prestamoService.actualizarPrestamo(codigoPrestamo,parametro);
}
if (StringUtils.equals(parametro, Constantes.PARAMETER_EDIT)){

h
// para traer las cantidades a las cajas de texto al momento de editar String cadena = "";
prestamo.setLstProducto(prestamoService.getDetallePrestamo(codigoPrestamo,prestamo.getAl
macenOrigen()));
logger.debug("productos: "+prestamo.getLstProducto().size() );
if (prestamo!=null){
prestamoForm.setCodigoPrestamo(prestamo.getCodigoPrestamo());
prestamoForm.setAlmacenOrigen(prestamo.getAlmacenOrigen());
prestamoForm.setAlmacenDestino(prestamo.getAlmacenDestino());
prestamoForm.setUsuarioSistema(prestamo.getUsuarioSistema());
prestamoForm.setResponsablePrestamo(prestamo.getResponsablePrestamo());
prestamoForm.setFechaPrestamo(prestamo.getFechaPrestamo());
for (Iterator iterator = prestamo.getLstProducto().iterator(); iterator
.hasNext();) {
Producto producto = (Producto) iterator.next();
cadena = cadena + producto.getCantidadProductoD() + ",";
}
logger.info("Cadena: " + cadena);
userSessionBean.put("ListaProductoDetalle", prestamo.getLstProducto());
model.addObject("lstProducto1", prestamo.getLstProducto());
model.addObject("CONT", prestamo.getLstProducto().size());
model.addObject("update_producto", Constantes.PARAMETER_EDIT);
model.addObject(Constantes.TITULO, "EDITAR PRESTAMO");
model.addObject("Cadena", cadena);
}
List<Almacen> lstAlmacen = prestamoService.getAlmacen(null);
logger.info("Almacen: " + lstAlmacen.size());
List<Empleado> lstEmpleado = prestamoService.getEmpleado(null);;
logger.info("empleados: " + lstEmpleado.size());
model.addObject("lstAlmacen", lstAlmacen);
model.addObject("lstEmpleado", lstEmpleado);
model.addObject("update_prestamo", parametro);
model.addObject("prestamoForm", prestamoForm);
return model;
}
if (StringUtils.equals(parametro, Constantes.PARAMETER_SEARCH)){
logger.debug("parametro: "+ parametro );
prestamo = new Prestamo();
if (StringUtils.equals(prestamoForm.getTipoBusqueda(),
Constantes.BUSQUEDA_X_CODIGO))
{
prestamo.setCodigoPrestamo(prestamoForm.getCodigoPrestamo().trim().toUpperCase());
}else
{
prestamo.setFechaPrestamo(prestamoForm.getFechaPrestamo().trim().toLowerCase());
}
logger.debug("Codigo Prestamo "+prestamoForm.getCodigoPrestamo());
request.setAttribute("prestamoBean", prestamo);
request.setAttribute("tipoBusqueda", prestamoForm.getTipoBusqueda());
//return listarPrestamo(request, response);
}
return listarPrestamo(request, response);
}

i
  Sentencia para obtener lista de autopartes en popup

public ModelAndView buscarProductoPopup(HttpServletRequest request,

HttpServletResponse response, PrestamoForm prestamoForm) throws Exception
{
logger.debug("=================Obtener Productos Popup===============");
String parametro = request.getParameter("parametro");
String parametro1 = request.getParameter("parametro1");
String codigo = request.getParameter("codigo");
ModelAndView model = new ModelAndView(Constantes.JSP_INIT_PRESTAMO);
logger.debug("TipoBusqueda: " + prestamoForm.getTipoBusqueda());
logger.debug("CodigoPrducto: " + prestamoForm.getCodProd());
logger.debug("DescripcionProducto: " + prestamoForm.getDesProd());
logger.debug("Parametro1: " +parametro1);
logger.debug("prestamoForm: " + prestamoForm);
logger.debug("almacen origen: " + prestamoForm.getAlmacenOrigen());
logger.debug("almacen destino: " + prestamoForm.getAlmacenDestino());
logger.debug("codigo prestamo: " + prestamoForm.getCodigoPrestamo());
//logger.debug("stock transferencia: " + prestamoForm.getCantidadPrestamo());
logger.debug("Parametro: " +parametro);
List<Producto> lstProducto = new ArrayList<Producto>();
try {
if (StringUtils.equals(parametro, Constantes.PARAMETER_SEARCH)){
Producto producto = new Producto();
producto.setCodigoProducto(prestamoForm.getCodProd());
producto.setDescripcionProducto(prestamoForm.getDesProd());
producto.setCodigoAlmacen(prestamoForm.getAlmacenOrigen());
//////// devolver la lista de productos al formulario principal/////////////////////////////
List<Producto> lstProducto1 = (List<Producto>) userSessionBean.get("ListaProductoDetalle") ;
if (CollectionUtils.isEmpty(lstProducto1))
lstProducto1 = new ArrayList<Producto>();
////////////////////////////////////////////////////////////////////////////////////////////
lstProducto = productoService.getProducto(producto, prestamoForm.getTipoBusqueda());
if (!CollectionUtils.isEmpty(lstProducto)){
if (lstProducto.size()>5){
lstProducto = lstProducto.subList(0, 5);
}
}
/////////////////////////////////////////////////////////////////////////////////////////////
userSessionBean.put("ListaProductoDetalle", lstProducto1);
model.addObject("lstProducto1", lstProducto1);
model.addObject("COUNT", lstProducto1.size());
logger.debug("cantidad de productos en la lista de prestamo a devolver: " +
lstProducto1.size());
/////////////////////////////////////////////////////////////////////////////////////////////
//model.addObject(Constantes.SHOW_DIV, Constantes.SHOW_DIV_NONE);
model.addObject(Constantes.SHOW_DIV, Constantes.SHOW_DIV_BLOCK);
}
if (StringUtils.equals(parametro, Constantes.PARAMETER_SELECT)){
//String cadena = "";
List<Producto> lstProducto1 = (List<Producto>) userSessionBean.get("ListaProductoDetalle");

j
if (CollectionUtils.isEmpty(lstProducto1))
lstProducto1 = new ArrayList<Producto>();
String[] codigos = prestamoForm.getCodigos();

//if(lstProducto1.size()<10){
for (int i = 0; i < codigos.length; i++) {
String[] valores = codigos[i].split(",");
if (!validaCodigoProducto(lstProducto1, valores[0])){
Producto producto= new Producto();
producto.setCodigoProducto(valores[0]);
producto.setDescripcionProducto(valores[1]);
producto.setCantidadProducto(Integer.parseInt(valores[2]));
lstProducto1.add(producto);
//cadena = cadena + producto.getCantidadProductoD() + ",";
}
logger.debug("I: " + codigos[i]);
// restringiendo la cantidad de registros por prestamo a 9 items
if (!CollectionUtils.isEmpty(lstProducto1)){
if (lstProducto1.size()>9){
lstProducto1 = lstProducto1.subList(0, 9);
}
}
}
//}
/////////////////////////////////////////////////////////////////////////////////////////////
userSessionBean.put("ListaProductoDetalle", lstProducto1);
model.addObject("lstProducto1", lstProducto1);
model.addObject("COUNT", lstProducto1.size());
logger.debug("lista de producto en lstProducto1: " + lstProducto1.size());
/////////////////////////////////////////////////////////////////////////////////////////////
//model.addObject("Cadena", cadena);
model.addObject(Constantes.SHOW_DIV, Constantes.SHOW_DIV_NONE);
}
if (StringUtils.equals(parametro, Constantes.PARAMETER_CANCEL)){
List<Producto> lstProducto1 = (List<Producto>) userSessionBean.get("ListaProductoDetalle") ;
if (CollectionUtils.isEmpty(lstProducto1)) lstProducto1 =
new ArrayList<Producto>();
userSessionBean.put("ListaProductoDetalle", lstProducto1);
model.addObject("lstProducto1", lstProducto1);
model.addObject("COUNT", lstProducto1.size());
logger.debug("cantidad de productos en la lista de prestamo a devolver: " +
lstProducto1.size());
model.addObject(Constantes.SHOW_DIV, Constantes.SHOW_DIV_NONE);
}
//codigo para elimnar el producto en la lista de prestamo
if (StringUtils.equals(parametro, Constantes.PARAMETER_DELETE)){
Prestamo prestamo = new Prestamo();
//Producto producto = new Producto();
//prestamo = prestamoService.getPrestamo(prestamo.getCodigoPrestamo());
//prestamo.setLstProducto(prestamoService.getDetallePrestamo(prestamo.getCodigoPrestamo()
,prestamo.getAlmacenOrigen()));
prestamo.setLstProducto(lstProducto);
//para select del popup
List<Producto> lstProducto1 = (List<Producto>) userSessionBean.get("ListaProductoDetalle") ;
//List<Producto> array1 = (List<Producto>) userSessionBean.get("ProductosEliminados");
logger.debug("lstProducto1: " + lstProducto1.size());
String idProd = request.getParameter("id");
logger.debug("idProd: " + idProd);

k
//guardando productos a eliminar cuando el parametro1 sea edit
List<Producto> array = new ArrayList<Producto>();
///////////////NUEVAMENTE DEVUELVO LAS CANTIDADES A LA CAJA DE
TEXTO////////////// String cadena = "";
int i= 0;
for (Iterator iterator = lstProducto1.iterator(); iterator
.hasNext();) {
Producto producto = (Producto) iterator.next(); logger.debug("producto: " +
producto.getCodigoProducto()); logger.debug("cantidad de producto: " +
producto.getCantidadProductoD());
//para eliminar producto de la lista de prestamo
if (StringUtils.equals(producto.getCodigoProducto(), idProd)){
lstProducto1.remove(i);
//prestamoService.updatePrestamo(prestamo, parametro, array1);
//prestamoService.actualizarStockAlmacen(prestamo.getAlmacenOrigen(),prestamo.getAlmacen
Destino(),producto.getCodigoProducto(),producto.getCantidadProductoD());
//prestamoService.actualizarPrestamo(prestamo.getCodigoPrestamo(), parametro);
if(StringUtils.equals(parametro1, Constantes.PARAMETER_EDIT)){
//array.add(producto);
//prestamoService.updatePrestamo(prestamo, parametro1, array);
//prestamoService.actualizarStockAlmacen(prestamo.getAlmacenOrigen(),prestamo.getAlmacen
Destino(),producto.getCodigoProducto(),producto.getCantidadProductoD());
//prestamoService.actualizarPrestamo(prestamo.getCodigoPrestamo(), parametro1);
prestamoService.actualizarStockAlmacen(prestamoForm.getAlmacenOrigen(),
prestamoForm.getAlmacenDestino(), producto.getCodigoProducto(),
producto.getCantidadProductoD());
prestamoService.eliminarProductoDetalle(prestamoForm.getCodigoPrestamo(),"",
producto.getCodigoProducto());
}
break;
}
///////////ENTREGANDO CANTIDADES///////////
cadena = cadena + producto.getCantidadProductoD() + ",";
logger.debug("getCodigoProducto: " + producto.getCodigoProducto());
logger.info("Cadena: " + cadena);
i++;
}
userSessionBean.put("ListaProductoDetalle", lstProducto1);
//userSessionBean.put("ProductosEliminados", array);
//List<Producto> array = (List<Producto>) userSessionBean.get("ProductosEliminados");
logger.debug("lstProducto2: " + lstProducto1.size());
logger.info("prestamo: " + prestamo);
logger.info("paremetro: " + parametro);
logger.info("paremetro1: " + parametro1);
logger.info("array: " + array.size());
////////CADENA--------------------cadena//////////////////
model.addObject("Cadena", cadena); model.addObject("lstProducto1",
lstProducto1); model.addObject("COUNT", lstProducto1.size());
model.addObject(Constantes.SHOW_DIV, Constantes.SHOW_DIV_NONE);
}
List<Almacen> lstAlmacen = prestamoService.getAlmacen(null);
List<Empleado> lstEmpleado = prestamoService.getEmpleado(null);
model.addObject("lstEmpleado", lstEmpleado);
model.addObject("lstAlmacen", lstAlmacen);
model.addObject("lstProducto", lstProducto);
if(StringUtils.equals(parametro1, Constantes.PARAMETER_NEW)){
model.addObject("update_prestamo", Constantes.PARAMETER_NEW);

l
model.addObject(Constantes.TITULO, "REGISTRAR PRESTAMO");
}
if(StringUtils.equals(parametro1, Constantes.PARAMETER_EDIT)){

model.addObject("update_prestamo", Constantes.PARAMETER_EDIT);
model.addObject(Constantes.TITULO, "EDITAR PRESTAMO");
}
prestamoForm.setCodigoPrestamo(codigo);
prestamoForm.setCantidadPrestamo(null);
logger.debug("Codigo Prestamo: "+ codigo);
} catch (Exception e) {
// TODO: handle exception
logger.error(e.getMessage(), e);
}
model.addObject("prestamoForm", prestamoForm);
return model;
}
public boolean validaCodigoProducto(List<Producto> lista, String codigo){

for (Iterator iterator = lista.iterator(); iterator.hasNext();) {

Producto producto = (Producto) iterator.next();
if (StringUtils.equals(producto.getCodigoProducto(), codigo))
return true;
}
return false;
}