tesis final ejemplo

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

ii

Orientador: Orientador

Co-orientador: (si lo hubiera)

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

“Tesis presentada a la Universidad Inca

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

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.

………………………………………

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

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

vi

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

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

viii

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 para

conocer el entorno y captar los requerimientos principales.

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

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

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

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

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.

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

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.

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

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

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.

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

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

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

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

ordenadores clientes).No sólo se ahorra tiempo porque reducimos la actualización a

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

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

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

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

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

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:

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

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

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

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 (eXtreme

Programming). Iconix deriva directamente del RUP y su fundamento es el hecho de

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:

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


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


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

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

35

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

36

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

37

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

38

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.

39

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.

40

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.

41

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

42

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

43

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

44

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

45

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.

46

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

47

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

48

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.

49

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.


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.


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.


realizar el control de stock de préstamo de autopartes, deberá manejar el stock

50

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

51

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.


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.


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

52

4.1.3.2 Priorizar casos de uso

REQUISITO CASO DE USO

Realizar seguimiento de productos

prestados.

1 Registrar Usuario.

2 Controlar Préstamo de

Autoparte.

4 Generar Orden de

devolución.

Registrar información de los responsables

del préstamo.


3 Mantener Información de

Responsables.

Generar orden de devolución de los

productos.

2 Controlar Préstamo de

Autoparte.

4 Generar Orden de

devolución.

Controlar el stock de los productos

prestados. 2

Controlar Préstamo de

Autoparte.

Modificar productos en estado de

préstamo.

Mostrar información de los productos

prestados a través de reportes.

5 Emitir 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

53

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.


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

Controlar Préstamo de Autopartes.

Registrar Préstamo de Autopartes.

Mantener Préstamo de Autopartes.

Controlar Stock de Préstamo de

Autopartes.

Ingreso al Sistema. Ingreso al Sistema.

Generar Orden de devolución.

Mantener Devolución por periodo.

Solicitar devolución por demanda en

Venta.

Registrar Usuario.

Mantener Usuario.

Modificar Registro de Usuario.

54

Mantener Información de Responsables.

Registrar Responsables.

Modificar Información de

Responsables.

Emitir Reportes.

Generar Reporte de Préstamo por

fecha.

Generar Reporte de Productos por

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.

55

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

56

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

57

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

Figura 4.12 Prototipo mantenimiento de autopartes [Fuente Propia].

58

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

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

59

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

pedido de nuevas autopartes.

2.1 El sistema muestra un mensaje solicitando el

llenado correcto de los datos.

3. El sistema envía los datos ingresados del

pedido de autopartes a la base de datos del

sistema.

3.1 Si hay alguna falla en el tipo de datos el

sistema muestra un mensaje de error.

4. El sistema almacena la información en la

base de datos.

5. El sistema envía un mensaje al jefe de

almacén con respecto al almacenamiento

satisfactorio de la información.

5.1 El jefe de almacén cancela la operación

Controlar Préstamo de Producto.

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:

60

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.


1. Se carga la ventana realizar pedido.

2. El jefe de almacén, encargado o supervisor

registra mantiene y actualiza información

sobre los préstamos de autopartes.




registro mantenimiento de autopartes a la

base de datos del sistema.




base de datos.

5. El sistema envía un mensaje al jefe de

almacén encargado o supervisor con

respecto al almacenamiento satisfactorio de

la información.

5.1 El jefe de almacén, supervisor o encargado

cancela la operación Controlar Producto.

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.



61

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.


1. Se carga la ventana distribuir producto.

2. El distribuidor ingresa la solicitud de

autopartes requeridas por el cliente



3. El sistema envía los datos ingresados sobre

la distribución y envio de autopartes al

cliente, a la base de datos del sistema.




base de datos.

5. El sistema envía un mensaje al distribuidor

con respecto al almacenamiento


5.1 El jefe distribuidor cancela la operación

Controlar Producto.

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.



62

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.


1. Se carga la ventana solicitar producto.

2. El almacenero ingresa en el sistema la

autoparte solicitada por el área de ventas.




búsqueda de autopartes, a la base de datos

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

solicitar prestamo

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.



63

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.


1. Se carga la ventana realizar venta de

producto.

2. El vendedor ingresa en el sistema las

autopartes y las cantidades a vender, asi

como el nombre del cliente.



3. El sistema envía los datos ingresados el

registro de ventas de autopartes, a la base





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

venta.

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.



64

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



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

2. El supervisor o encargado ingresa la

información del registro del préstamo o

mantenimiento, esta incluye el producto,

cantidad, responsables, fecha, almacén de

origen, almacén de destino.




préstamo o modificación del producto a la





base de datos.

5. El sistema envía un mensaje al supervisor o

encargado con respecto al almacenamiento


5.1 El supervisor o encargado cancela la

operación Controlar Préstamo de Producto.

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.



65

Caso de uso: Registrar Préstamo de Autopartes.


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.


1. Se carga la ventana Registrar Préstamo de

Autoparte.


información del registro del préstamo la

cual incluye el producto, cantidad,

responsable, fecha, almacén de origen

almacén de destino.




préstamo de las autopartes a la base de

datos del sistema.


base de datos.

5. El sistema muestra la interface para un

nuevo préstamo y genera el código de

préstamo de manera automática.

5.1 El Usuario cancela la operación Registrar

Préstamo de Autopartes.

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




66

Caso de uso: Mantener Préstamo de Autopartes.


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.


1. Se carga la ventana Mantener Préstamo de

Autopartes.


información concerniente a la modificación

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

nuevo préstamo y genera el código de

préstamo de manera automática.

5.1 El supervisor o encargado cancela la

operación Mantener Préstamo de

Autopartes.


password.

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




67

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


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



1. Se carga la ventana Mantenimiento de

Autoparte.

2. El Supervisor o Encargado ingresa el código

de autoparte o descripción de la autoparte,

indicando el almacén al que pertenece.




el control de stock de autopartes a la base


4. El sistema muestra al Supervisor o

Encargado el stock de las autopartes

prestados.

4.1 El Supervisor o encargado cancela la

operación controlar stock de préstamo de

producto.


password.

Postcondiciones: Los datos sobre el control de stock de préstamo de autopartes han sido emitidos en un

formulario simple dentro del sistema.



68

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.


1. Se carga la ventana de logeo de Usuario.

2. El sistema pide al usuario que introduzca su

nombre de usuario y su password.

2.1 El sistema muestra un mensaje solicitando

que el campo nombre de Usuario y su

password sean rellenados.

3. El sistema valida los datos ingresados por el

usuario y si son correctos el Usuario ingresa

a la Aplicación Web.

3.1 Si los datos son incorrectos el Sistema le

mostrara un mensaje de error en el acceso.

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.



69

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.


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.



3. El sistema envía los datos ingresados de la

orden de devolución a la base de datos del

sistema.




base de datos.

5. El sistema envía un mensaje al Encargado



5.1 El Encargado cancela la operación generar

orden de devolució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




70

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.


1. Se carga la ventana Registrar Usuario.

2. El Supervisor ingresa los datos personales

de los usuarios del sistema en este caso de

los encargados.

2.1 Si el Supervisor no valido correctamente los

datos personales del usuario, el sistema

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.


base de datos.

5. El sistema muestra una lista con los

Usuarios registrados por el Supervisor.

5.1 El Supervisor cancela la operación registrar

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.



71

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.


1. Se carga la ventana Mantener Información

de Responsables.

2. El Supervisor ingresa los datos personales

del responsable en este caso del

Almacenero, así como también podrá

modificarla actualizarla e incluso eliminarla.

2.1 Si el Supervisor no valido correctamente los

datos personales del empleado, el sistema

envía un mensaje de error.

3. El Supervisor genera un código para el

Almacenero el cual lo diferenciara de los

demás individuos.


base de datos.

5. El sistema muestra una lista con los

responsables registrados por el Usuario.

5.1 El Supervisor cancela la operación mantener

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.



72

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.


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

los distintos reportes por fecha, es decir en

que periodo se llevo a cabo el préstamo de

una determinada autoparte.



4. El sistema muestra el reporte solicitado por

el Usuario.

4.1 El Supervisor cancela la operación Emitir

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.



73

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

74

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

75

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

76

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

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

77

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

Propia].

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

78

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

79

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

Propia].

80

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

81

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

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

82

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

Propia].

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

83

5.1.3 Diagrama de clases

Figura 5.17 Diagrama de clases [Fuente Propia].

84

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

85

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

86

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

87

Tablas físicas diccionario de datos:

Tabla Empleado

Name Code Data

Type

Length Comment

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

Type

Length Comment

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

Type

Length Comment

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

88

Tabla Préstamo

Name Code Data

Type

Length Comment

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

Type

Length Comment

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

89

Tabla Autoparte

Name Code Data

Type

Length Comment

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

o

varchar 5 Indica el código de

tipo de producto

cantidad_producto cantidad_producto number Indica la cantidad de

strock

unidad_medida unidad_medida char 10 Indica la unidad de

medida


almacén

Tabla 5.6 Tabla autoparte [Fuente propia].

Tabla Tipo de autoparte

Name Code Data

Type

Length Comment

código_tipo_autopa

rte

código_tipo_autopa

rte

varchar 5 Indica el código de tipo

autoparte

tipo_producto tipo_producto char 15 Indica el tipo de

autoparte

descripción_tipo_pr

oducto

descripción_tipo_pr

oducto

char 20 Indica la descripción tipo

de autoparte

Tabla 5.7 Tabla tipo de autoparte [Fuente propia].

90

Tabla Almacén

Name Code Data

Type

Length Comment


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

91

"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;

92

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

) ;

93

5.1.7 Interfaces de usuario

Figura 5.21 Login de Usuario [Fuente Propia].

Figura 5.22 Acceso al sistema [Fuente Propia].

94

Figura 5.23 Mantenimiento de autopartes [Fuente Propia].

95

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

96

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

97

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

98

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

99

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

100

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

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

101

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

102

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

103

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

104

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.

105

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.

106

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.

a

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

______________________________________________________________

______________________________________________________________

______________________________________________________________

______________________________________________________________

b

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?

______________________________________________________________

______________________________________________________________

______________________________________________________________

______________________________________________________________

c

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?

______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

d

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?

______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

e

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

producto

Almacén

Origen

Almacén

Destino

Cantidad Responsable

en entregar

Responsable

en recibir

Fecha de

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:

f

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; }

g

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());

h

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

i

// 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); }

j

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");

k

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

l

//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.getAlmacenDestino(),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);

m

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; }

tesis final ejemplo

Documents