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

8/16/2019 DESARROLLO DE UNA APLICACIÓN WEB PARA EL REGISTRO Y SEGUIMIENTO DE PRÉSTAMO DE AUTOPARTES ENTRE…

1/133

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


2/133

ii

Orientador: Orientador

Co-orientador: (si lo hubiera)

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

“Tesis presentada a la Universidad IncaGarcilaso de la Vega Lima – Perú, para obtener

el Título de Ingeniero de Sistemas y Cómputo”

© Nombre del Alumno, 2016.

Todos los derechos reservados.


3/133

iii

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.


4/133

iv

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 trabajocumpla 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.


5/133

v

Í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 .......... 11.1.2 Definición del Problema ............................................................................ 2

1.2 Objetivos.............................................................................................. 2

1.2.1 Objetivo principal ..................................................................................... 21.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 ............................................................................... 51.5.2 Estudio del problema ............................................................................... 51.5.3 Estudio de la metodología ........................................................................ 61.5.4 Desarrollo de la propuesta ........................................................................ 6

1.5.5 Validación de la propuesta ........................................................................ 61.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


6/133

vi

2.3 Actividades Fundamentales en el Almacén. ....................................... 11

2.3.1 Proceso de Recepción ............................................................................ 112.3.2 Proceso de Almacenamiento ................................................................... 122.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 ....................................................................................... 162.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 .............................................................. 233.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 ............................................................................. 283.1.1.8 Pruebas ......................................................................................... 28

3.1.1.9 Despliegue ..................................................................................... 28

3.1.2 Metodología ICONIX .............................................................................. 293.1.2.1 Fases de iconix ............................................................................... 30

3.1.2.2 Resumen de iconix ......................................................................... 32

3.1.3 Metodología SCRUM ............................................................................... 333.1.3.1 Componentes de scrum................................................................... 34

3.1.3.2 Los artefactos de scrum .................................................................. 35


7/133

vii

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 ............................................................................ 394.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 .............................................................. 434.1.2.2 Encontrar actores y casos de uso ..................................................... 46

4.1.3 Casos de uso del sistema web ................................................................ 474.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 ................................................................................ 564.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 ....................................................................... 595.1.1.1 Descripción en detalle de casos de uso del negocio ........................... 59

5.1.2 Casos de uso del sistema ....................................................................... 645.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 ................................................................................ 835.1.4 Diagrama de componentes ..................................................................... 845.1.5 Diagrama de despliegue ......................................................................... 855.1.6 Modelo físico de la base de datos ............................................................ 865.1.7 Interfaces de usuario ............................................................................. 93

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

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


8/133

viii

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

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

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

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

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

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


9/133

ix

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]. ................................. 49Tabla 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


10/133

x

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:


Figura 3.5 Trazabilidad entre artefactos [Fuente:


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:


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


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

http://www.scrumprimer.org/primers/es_scrumprimer20.pdf] ................................. 34


11/133

xi

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


12/133

xii

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]. ............................................................................................................... 79Figura 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 [FuentePropia]. ............................................................................................................... 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]. ........................... 86Figura 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


13/133

xiii

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 manteniendoun 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.


14/133

xiv

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 ApplicationJava 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.


15/133

1

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 otraempresa 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 autopartesa 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.


16/133

2

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 seacepta 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 vecesté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 controlarde 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.


17/133

3

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 deproductos 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.


18/133

4

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 deautopartes.

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.


19/133

5

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 paraconocer el entorno y captar los requerimientos principales.


20/133

6

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 delas 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.


21/133

7

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, eneste 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.


22/133

8

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 seaplica 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áficasutilizadas para el desarrollo de esta tesis.


23/133

9

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).


24/133

10

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.


25/133

11

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 deacceso 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 bloquescompactos, 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 larecepción de los productos pueden realizarse a ciegas o convencionalmente,


26/133

12

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.


27/133

13

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 revisary 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 deexpedició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 estamosindicando 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:


28/133

14

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 quetienen 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.


29/133

15

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.


30/133

16

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á definirque 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 delos almacenes.


31/133

17

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 ellasrequisitos 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


32/133

18

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


33/133

19

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.000ordenadores clientes).No sólo se ahorra tiempo porque reducimos la actualización a


34/133

20

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).


35/133

21

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 diversasestrategias 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


36/133

22

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).


37/133

23

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 ayudarancon 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 elementoclave 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


38/133

24

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 miniproyectos. 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).


39/133

25

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:


40/133

26

Figura 3.4 Estructura de RUP [Fuente:


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


41/133

27

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 metasdel 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).


42/133

28

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 finalde 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 derequisitos 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:


43/133

29

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:


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 (eXtremeProgramming). Iconix deriva directamente del RUP y su fundamento es el hecho de


44/133

30

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:


45/133

31

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 unabreve 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:



46/133

32

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 deuso 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. Encualquier 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:



47/133

33

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 conlos 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).


48/133

34

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 principal

Documents

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