Está en la página 1de 104

UNIVERSIDAD NACIONAL DE HUANCAVELICA

(Creada por ley N° 25265)

FACULTAD DE INGENIERÍA ELECTRÓNICA - SISTEMAS

ÁREA DE PRÁCTICAS PRE-PROFESIONALES


ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

“IMPLEMENTACIÓN DE UN SISTEMA DE
INVENTARIO EN LA GERENCIA SUB REGIONAL DE
TAYACAJA PARA EL ÁREA DE LOGISTICA”

INFORME DE PRÁCTICAS PRE-PROFESIONALES PARA OPTAR EL GRADO


ACADÉMICO DE BACHILLER EN INGENIERÍA DE SISTEMAS

ENTIDAD : GERENCIA SUB REGIONAL DE TAYACAJA

LUGAR DE EJECUCIÓN : PAMPAS

FECHA DE INICIO : 23 DE JUNIO DEL 2018

FECHA DE CULMINACIÓN : 23 DE OCTUBRE DEL 2018

PRESENTADO POR : PARI HILARIO, WILLIAN

ASESOR : Dr. RAFAEL ROJAS BUJAICO

TAYACAJA - HUANCAVELICA

2019

CARÁTULA
UNIVERSIDAD NACIONAL DE HUANCAVELICA

(Creada por ley N° 25265)

FACULTAD DE INGENIERÍA ELECTRÓNICA - SISTEMAS

ÁREA DE PRÁCTICAS PRE-PROFESIONALES


ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

“IMPLEMENTACIÓN DE UN SISTEMA DE
INVENTARIO EN LA GERENCIA SUB REGIONAL DE
TAYACAJA PARA EL ÁREA DE LOGISTICA”

INFORME DE PRÁCTICAS PRE-PROFESIONALES PARA OPTAR EL GRADO


ACADÉMICO DE BACHILLER EN INGENIERÍA DE SISTEMAS

ENTIDAD : GERENCIA SUB REGIONAL DE TAYACAJA

LUGAR DE EJECUCIÓN : PAMPAS

FECHA DE INICIO : 23 DE JUNIO DEL 2018

FECHA DE CULMINACIÓN : 23 DE OCTUBRE DEL 2018

PRESENTADO POR : PARI HILARIO, WILLIAN

ASESOR : Dr. RAFAEL ROJAS BUJAICO

TAYACAJA - HUANCAVELICA

2019
Dedicatoria
“El presente dedico con mucho amor y respeto
a mis queridos padres y hermanos que por su
apoyo incondicional, y también a los docentes
que contribuyeron a mi formación profesional.”
AGRADECIMIENTO

A la Escuela Profesional de Ingeniería de Sistemas, que durante mis estudios realizados


obtuve los conocimientos y habilidades necesarias para realizar mi práctica pre
profesionales.

A mis padres y hermanos por motivarme en todo aspecto para seguir adelante con mis
estudios superiores

De igual manera agradezco al personal administrativo de la Gerencia Sub Regional de


Tayacaja por apoyarme y brindarme la oportunidad de realizar mis practicas pre
profesionales en dicha institución.
A la Econ, Marilú Pedraza Medrano, Directora de la de Área de Estudios de Pre inversión y
al Ing. Oscar Huanay López, Director del área de Logística por apoyarme para realizar mis
practicas pre profesionales satisfactoriamente.

Al docente encargado de asesorarme, Dr. Rafael Rojas Bujaico, en la elaboración del


presente informe, quien me apoyo con su amplio conocimiento en la parte estructural y
contenido adecuado del informe.
ÍNDICE
CONTENIDO PÁGINA

Dedicatoria ------------------------------------------------------------------------------------------------------------ v
AGRADECIMIENTO ----------------------------------------------------------------------------------------------vi
ÍNDICE ---------------------------------------------------------------------------------------------------------------- 7
ÍNDICE DE IMAGENES ----------------------------------------------------------------------------------------- 11
ÍNDICE DE TABLAS --------------------------------------------------------------------------------------------- 12
INTRODUCCIÓN -------------------------------------------------------------------------------------------------- 13
CAPÍTULO I--------------------------------------------------------------------------------------------------------- 14
DATOS INFORMATIVOS DE LA INSTITUCIÓN -------------------------------------------------------- 14
1.1. DATOS GENERALES ------------------------------------------------------------------------------------ 14
1.2. MISIÓN ------------------------------------------------------------------------------------------------------- 14
1.3. VISIÓN ------------------------------------------------------------------------------------------------------- 14
1.4. UBICACIÓN DE LA GERENCIA SUB REGIONAL DE TAYACAJA ----------------------- 15
1.4.1. UBICACIÓN GEOGRÁFICA ------------------------------------------------------ 15
1.4.2. UBICACIÓN POLÍTICA------------------------------------------------------------ 15
1.5. ORGANIGRAMA ESTRUCTURAL DE LA UNIDAD DE GESTIÓN EDUCATIVA
LOCAL DE TAYACAJA --------------------------------------------------------------------------------- 16
1.6. FINALIDADES DE LA GERENCIA SUB REGIONAL DE TAYACAJA -------------------- 16
1.7. ESTRUCTURA ORGÁNICA ---------------------------------------------------------------------------- 17
1.8. FUNCIONES ------------------------------------------------------------------------------------------------ 17
1.8.1. FUNCIONES DE LA GERENCIA SUB REGIONAL DE TAYACAJA ---- 17
1.9. DESCRIPCIÓN DEL ÁREA DE PRÁCTICAS ------------------------------------------------------ 18
1.9.1. RESPONSABLE DE LA OFICINA SUB REGIONAL DE ESTUDIOS
PRE INVERSIÓN -------------------------------------------------------------------- 18
Apellidos y Nombres : Pedraza Medrano, Marilú--------------------------------------- 18
CAPÍTULO II-------------------------------------------------------------------------------------------------------- 19
PLAN DE ACTIVIDADES DE PRÁCTICAS PRE PROFESIONALES ------------------------------- 19
2.1. OBJETIVOS ------------------------------------------------------------------------------------------------- 19
2.2. METAS ------------------------------------------------------------------------------------------------------- 19
2.3. TAREAS ------------------------------------------------------------------------------------------------------ 20
2.4. CRONOGRAMA DE ACTIVIDADES ---------------------------------------------------------------- 20
2.4.1. ACTIVIDADES----------------------------------------------------------------------- 20

7
2.4.2. CRONOGRAMA DE ACTIVIDADES ------------------------------------------- 21
2.4.3. DESCRIPCIÓN BÁSICA DE LAS ACTIVIDADES --------------------------- 21
2.4.3.1. ACTIVIDAD 1.-RECOPILACIÓN DE LA INFORMACIÓN PARA LA
BASE DE DATOS --------------------------------------------------------------------------- 21
2.4.3.2. ACTIVIDAD 2.- DISEÑO DE LA INTERFAZ Y PROGRAMACIÓN DE
CÓDIGO FUENTE -------------------------------------------------------------------------- 22
2.4.3.3. ACTIVIDAD 3.- PRUEBA, MEJORAS Y PUESTA EN MARCHA DEL
SISTEMA ------------------------------------------------------------------------------------- 22
2.4.3.4. ACTIVIDAD 4.- IMPLEMENTACIÓN Y MANTENIMIENTO DEL
SISTEMA ------------------------------------------------------------------------------------- 22
2.5. METODOLOGÍAS ----------------------------------------------------------------------------------------- 22
2.6. INSTRUMENTOS, EQUIPOS Y HERRAMIENTAS ---------------------------------------------- 23

CAPÍTULO III ----------------------------------------------------------------------------------------------------- 25


DOCUMENTACIÓN BIBLIOGRÁFICA ------------------------------------------------------------------ 25
3. LENGUAJE UNIFICADO DE MODELADO (UML) ---------------------- 25
3.1. DEFINICIÓN DE LENGUAJE UNIFICADO DE MODELADO ------------ 25
3.1.1. MODELOS ---------------------------------------------------------------------------------------- 26
3.1.2. DIAGRAMAS ------------------------------------------------------------------------------------ 26
3.2. SOFTWARE Y SISTEMAS DE INFORMACIÓN -------------------------- 28
3.2.1. DEFINICIÓN DE SOFTWARE ------------------------------------------------------------- 28
3.2.2. DEFINICIÓN DE SISTEMAS DE INFORMACIÓN----------------------------------- 28
3.2.3. ACTIVIDADES BÁSICAS DE LOS SISTEMAS DE INFORMACIÓN ----------- 29
3.2.4. ANÁLISIS Y DISEÑO DEL SISTEMA ---------------------------------------------------- 30
3.2.5. DESARROLLO DEL DISEÑO DEL SISTEMA ----------------------------------------- 30
3.2.6. DISEÑO DEL SISTEMA --------------------------------------------------------------------- 32
3.3. BASE DE DATOS ------------------------------------------------------------------- 32
3.3.1. DEFINICIÓN DE BASE DE DATOS ------------------------------------------------------ 32
3.3.2. SISTEMA DE GESTIÓN DE BASE DE DATOS (SGBD) ---------------------------- 33
3.3.3. COMPONENTES DE UNA BASE DE DATOS ---------------------------------------- 33
3.3.4. XAMPP -------------------------------------------------------------------------------------------- 34
3.3.5. MYSQL--------------------------------------------------------------------------------------------- 35
3.4. PROGRAMACIÓN ORIENTADA A OBJETOS ---------------------------- 36
3.4.1. DEFINICIÓN DE LA PROGRAMACIÓN ORIENTADA A OBJETOS --------- 36
3.4.2. CARACTERÍSTICAS DE LOS LENGUAJES PROGRAMACIÓN
ORIENTADA A. OBJETOS ------------------------------------------------------------- 37
3.4.3. CLASES Y OBJETOS -------------------------------------------------------------------------- 38
3.5. LENGUAJE DE PROGRAMACIÓN JAVA. ------------------------------------- 38
8
3.6. PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE ----------- 39
3.6.1. DEFINICIÓN DEL PROCESO DE DESARROLLO DE SOFTWARE ----------- 39
3.6.2. PRINCIPIOS BÁSICOS DEL PROCESO UNIFICADO DE
DESARROLLO DE SOFTWARE ----------------------------------------------------- 40
3.6.3. VIDA DEL PROCESO UNIFICADO ------------------------------------------------------- 40
3.6.4. FLUJOS DEL PROCESO UNIFICADO DE DESARROLLO DE
SOFTWARE --------------------------------------------------------------------------------- 41
CAPÍTULO IV ----------------------------------------------------------------------------------------------------- 45
ACTIVIDADES Y PROCEDIMIENTOS------------------------------------------------------------------- 45
4.1. RECOPILACIÓN DE INFORMACIÓN PARA LA BASE DE DATOS --- 46
4.1.1. REQUISITOS DEL SISTEMA DE INFORMACIÓN ---------------------------------- 46
4.1.2. TÉCNICAS E INSTRUMENTOS DE RECOLECCIÓN DE DATOS -------------- 47
4.1.3. TÉCNICAS DE ANÁLISIS DE DATOS --------------------------------------------------- 47
4.1.4. DISEÑO OPERATIVO------------------------------------------------------------------------- 48
4.1.5. RIESGOS DEL SISTEMA -------------------------------------------------------------------- 48
4.2. DISEÑO DE LA INTERFAZ Y PROGRAMACIÓN DE CÓDIGO
FUENTE ------------------------------------------------------------------------------- 48
4.2.1. MODELO DE CASOS DE USO ------------------------------------------------------------- 48
4.2.2. IDENTIFICACIÓN DE LOS ACTORES -------------------------------------------------- 48
4.2.3. IDENTIFICACIÓN DE CASOS DE USO DEL MODELO ACTUAL ------------- 49
4.2.4. IDENTIFICACIÓN DE CASOS DE USO DEL SISTEMA PROPUESTO -------- 49
4.2.5. IDENTIFICACIÓN DE CASOS DE USO ------------------------------------------------- 50
4.2.6. IMPLEMENTACIÓN DE LA BASE DE DATOS DEL SISTEMA ------------ 60
4.2.7. DISEÑO DE LA INTERFAZ ------------------------------------------------------------ 61
4.3. PRUEBA, MEJORAS Y PUESTA EN MARCHA DEL SISTEMA --------- 66
CAPÍTULO V ------------------------------------------------------------------------------------------------------ 68
EVALUACIÓN PRE Y POST PRÁCTICA PREPROFESIONAL ---------------------------------- 68
5.1 ASPECTO TÉCNICO-CIENTÍFICO ------------------------------------------ 68
5.2 ASPECTO TÉCNICO CIENTÍFICO (FORMACIÓN
ACADÉMICA) ----------------------------------------------------------------------- 69
5.3 FORMACIÓN LABORAL -------------------------------------------------------- 70
5.4 ASPECTO PERSONAL ----------------------------------------------------------- 70
5.5 LOGROS DESPUÉS DE LA IMPLEMENTACIÓN DEL SISTEMA
------------------------------------------------------------------------------------------- 70
CAPÍTULO VI ----------------------------------------------------------------------------------------------------- 71
APORTES DE MEJORA EN PRO DE LA ENTIDAD ------------------------------------------------- 71

9
6.1 APORTE CULTURAL------------------------------------------------------------- 71
6.2 OPTIMIZACIÓN DE TIEMPO ------------------------------------------------- 71
6.3 ALMACENAMIENTO DE DATOS -------------------------------------------- 72
6.4 AUTOMATIZACIÓN DE PROCESOS ---------------------------------------- 72
LIMITACIONES -------------------------------------------------------------------------------------------------- 73
CONCLUSIONES ------------------------------------------------------------------------------------------------- 74
SUGERENCIAS --------------------------------------------------------------------------------------------------- 75
BIBLIOGRAFÍA -------------------------------------------------------------------------------------------------- 76
REFERENCIAS BIBLIOGRÁFICAS --------------------------------------------------- 76
REFERENCIAS DE PÁGINAS WEB --------------------------------------------------- 77

10
INDICE DE IMAGENES
Imagen Nº 1 Organigrama estructural de la Gerencia Sub Regional- Tayacaja.................. 16
Imagen Nº 2 Elementos de un sistema de información. ...................................................... 29
Imagen Nº 3. Actividades de un sistema de información. ................................................... 30
Imagen Nº 4. Ventana principal de XAMPP for Windows localhost.................................. 35
Imagen Nº 5. Arquitectura de la plataforma MYSQL server. ............................................. 36
Imagen Nº 6. Fases del proceso unificad. ............................................................................ 41
Imagen Nº 7. Diagrama de caso de uso de almacén (actual) ............................................... 49
Imagen Nº 8. Diagrama de casos de uso del sistema a implementar. .................................. 51
Imagen Nº 9. Caso de uso acceder al sistema. ..................................................................... 51
Imagen Nº 10. Caso de uso mantenimiento de información de los administradores. ......... 53
Imagen Nº 11. Caso de uso mantenimiento de información de materiales. ........................ 54
Imagen Nº 12. Caso de uso mantenimiento de información de personal. ........................... 56
Imagen Nº 13. Caso de uso realizar entrega de equipos. ..................................................... 57
Imagen Nº 14. Casos de uso generar reporte de entrega. .................................................... 58
Imagen Nº 15. Caso de uso consultar reportes. ................................................................... 59
Imagen Nº 16. Diseño de base de datos del Sistema ........................................................... 61
Imagen Nº 17. Interfaz de autentificación del usuario. ....................................................... 62
Imagen Nº 18. Interfaz principal. ........................................................................................ 63
Imagen Nº 19. Interfaz registro de personal. ....................................................................... 63
Imagen Nº 20. Interfaz de personal registrado. ................................................................... 64
Imagen Nº 21. Interfaz registro de personal. ....................................................................... 64
Imagen Nº 22. Interfaz de materiales registrados ................................................................ 65
Imagen Nº 23. Interfaz de registro de usuarios. .................................................................. 66
Imagen Nº 24. Interfaz consultar entregas. .......................................................................... 66
Imagen Nº 25. Traspapelación en la documentación de inventario (pre implementación) . 80
Imagen Nº 26. Falta de espacio a causa de los excesivos folios de registros (pre
implementación) .................................................................................................................. 81
Imagen Nº 27. Registrando en el inventario (pre implementación) .................................... 82
Imagen Nº 28. Desarrollando el Sistema de Inventario ....................................................... 83
Imagen Nº 29. Software implementado en el área de logística. .......................................... 84
Imagen Nº 30. Explicando al jefe de logística el funcionamiento del sistema e instalando la
base de datos al servidor. ..................................................................................................... 84
Imagen Nº 31. Último día de prácticas, entrega de la ficha de evaluación. ........................ 85

11
INDICE DE TABLAS
Tabla Nro.1.Cronograma de Actividades para la implementación del sistema fijado de
Febrero a Mayo de 2018. ..................................................................................................... 21
Tabla 2. Pasos para acceder al sistema ................................................................................ 52
Tabla 3. Pasos para realizar el mantenimiento de la información de los administradores .. 53
Tabla 4. Pasos para realizar el mantenimiento de la información de equipos. .................... 54
Tabla 5. Pasos para realizar el mantenimiento de la información de personal. ................... 56
Tabla 6. Pasos para realizar entrega de equipos. ................................................................. 57
Tabla 7. Pasos para generar reporte de entrega. .................................................................. 58
Tabla 8. Pasos para consultar reportes................................................................................ 60
Tabla 9. Detalle de pruebas realizadas del sistema. ............................................................ 67
Tabla 10. Evaluación pre y post de la organización. ........................................................... 68
Tabla 11. Convalidado de optimización de tiempo. ............................................................ 69

12
INTRODUCCIÓN
El informe de prácticas pre profesionales realizados en la oficina de Logística de la Gerencia
Sub Regional de Tayacaja, donde cumplí toda la labor encomendada y aporté para mejorar
la misma. Mediante el presente informe doy a conocer el sistema de inventario que se
implementó para organizar adecuadamente los equipos tecnológicos de la gerencia sub
regional de Tayacaja. El objetivo del programa de información es almacenar los datos de los
equipos de manera consistente, al ser un programa que cumpla con los requerimientos y
funciones de la Oficina de Logística se considera una herramienta fundamental para los
trabajadores de la mencionada oficina.
En este informe se detalla de manera secuencial cómo se desarrolló la implementación del
programa con segmentaciones por capítulos, por lo que se presenta en el Capítulo I los datos
informativos de la empresa, se refiere a la información detallada de la institución donde se
desarrolló las practicas pre profesionales. Capitulo II el plan de actividades de prácticas pre
profesionales, en este capítulo se presenta el plan que se siguió durante la realización del
programa en cuestión, continuando, en el Capítulo III se hace una descripción de todo el
marco teórico consultado y utilizado para el buen desenvolvimiento en el desarrollo de las
tareas planeadas. Más adelanten el Capítulo IV se presenta la descripción en detalle de cada
una de las actividades y tareas ejecutadas señalando los procedimientos desarrollados.
Posteriormente, en el Capítulo V se describen las experiencias, aprendizaje, evaluación (pre
y post) en el aspecto técnico-científico, laboral y personal que se efectuaron durante el
desarrollo del programa implementado, asimismo en el Capítulo VI se presenta la
descripción de los aportes, propuestas ejecutaron en pro de la entidad, por último en el
Capítulo VII se presentan las dificultades o limitaciones que se tuvo en el desempeño del
trabajo realizado. En la última parte del informe también se presentan las conclusiones,
sugerencias con respecto al programa desarrollado.

13
CAPÍTULO I
DATOS INFORMATIVOS DE LA INSTITUCIÓN

En este capítulo se detalla la información de la institución, es decir de la Gerencia Sub


Regional de Tayacaja, también en algunos sub ítems se agrega información del área y oficina
donde se realizó las prácticas pre profesionales.
1.1. DATOS GENERALES
 NOMBRE DE LA INSTITUCIÓN
Gerencia Sub Regional de Tayacaja
 NOMBRE DEL ÁREA DE PRÁCTICAS
Oficina sub regional de Logística
 NOMBRE DE LA OFICINA DE PRÁCTICAS
Área de Logística
1.2. MISIÓN1
Organizar y Conducir con eficiencia y transparencia la gestión pública regional,
conducente a lograr concertadamente el desarrollo integral y sostenido de la región,
dentro de un marco democrático y de práctica de valores.

1.3. VISIÓN2
Es una organización moderna, proactiva y con identidad propia que lidera el desarrollo
sostenible de la región, institucionalizando los valores humanos, generando condiciones
para la competitividad integral y articulando la inversión pública y privada.

1
Gerencia Sub Regional de Tayacaja/ ROF Y CAP Ordenanza REG 255-2018 GSRT.
2
Gerencia Sub Regional de Tayacaja / ROF Y CAP Ordenanza REG 255-2018 GSRT.

14
1.4. UBICACIÓN DE LA GERENCIA SUB REGIONAL DE TAYACAJA
1.4.1. UBICACIÓN GEOGRÁFICA
Actualmente la Gerencia sub Regional de Tayacaja, está ubicada en el ovalo de
Rumichaca.
1.4.2. UBICACIÓN POLÍTICA
 DISTRITO
Pampas
 PROVINCIA
Tayacaja
 DEPARTAMENTO
Huancavelica
 PAÍS
Perú

15
1.5. ORGANIGRAMA ESTRUCTURAL DE LA UNIDAD DE GESTIÓN
EDUCATIVA LOCAL DE TAYACAJA3

OFICINA SUB
GERENCIA SUB
REGIONAL DE
REGIONAL DE TAYACAJA
CONTROL
INSTITUCIONAL

OFICINA SUB
OFICINA SUB REGIONAL DE
REGIONAL DE ASESORÍA
PLANEAMIENTO Y JURÍDICA
PRESUPUESTO

OFICINA SUB OFICINA SUB OFICINA SUB


REGIONAL DE REGIONAL REGIONAL
ESTUDIOS DE DE
PRE SUPERVISIÓ ADMINISTRA
INVERSIÓN NY CIÓN
LIQUIDACIÓN

UNIDAD UNIDAD DE UNIDAD


UNIDAD UNIDAD COMUNIDADE OPERATIVA
OPERATIVA UNIDAD DE UNIDAD DE
OPERATIV OPERATI S DE
DE INFRAESTR SERVICIOS
A DE VA CAMPESINAS EDUCACIÓN
EDUCACIÓN UCTURA MÚLTIPLES
SALUD AGRARIA E INCLUSIÓN SURCUBAMB
-TAYACAJA
SOCIAL A

Imagen Nº 1 Organigrama estructural de la Gerencia Sub Regional- Tayacaja.


1.6. FINALIDADES DE LA GERENCIA SUB REGIONAL DE TAYACAJA4
1. Fomentar el desarrollo integral, sostenible y armónico promoviendo la inversión pública
y privada promoviendo el empleo.
2. Garantizar el ejercicio pleno de los derechos y la igualdad de oportunidades de sus
habitantes de la Provincia de Tayacaja.

3
Gerencia Sub Regional de Tayacaja ROF Y CAP Ordenanza REG 255-2018 GSRT.
4
Gerencia Sub Regional de Tayacaja ROF Y CAP Ordenanza REG 255-2018 GSRT.

16
3. Garantizar también de acuerdo con los planes y programas nacionales, regionales y
locales de desarrollo, con adecuada prestación de los servicios públicos.
1.7. ESTRUCTURA ORGÁNICA5
La Gerencia Sub Regional de Tayacaja, tiene la siguiente estructura orgánica.
 ÓRGANO DE DIRECCIÓN: gerencia sub regional
 ÓRGANO DE CONTROL: oficina sub regional de control institucional
Área de Gestión Institucional
 ÓRGANO DE ASESORAMIENTO: Área de gestión administrativa
Oficina de Atenciones, Denuncias y Reclamos
 ÓRGANO DE PARTICIPACIÓN: Consejo Participativo Local de Educación
1.8. FUNCIONES
1.8.1. FUNCIONES DE LA GERENCIA SUB REGIONAL DE TAYACAJA6
- Mejorar los niveles de producción agropecuaria y piscícola, propiciando su
desarrollo competitivo y sostenido.
- Mejorar la articulación vial e integración territorial, para el acceso de la población
a los servicios sociales y oportunidades de mercado.
- Mejorar las condiciones de los servicios educativos a través de la ampliación,
rehabilitación y construcción de infraestructura educativa, garantizando una
educación básica de calidad en los diferentes niveles, con equidad y formación
de valores.
- Ampliar la cobertura y mejorar la cálida de los servicios básicos de saneamiento
y electrificación en el ámbito regional.
- Mejorar la calidad y cobertura de los servicios integrales de salud, desarrollando
principalmente programas asociados a la disminución de la desnutrición crónica
infantil y la mortalidad materna neonatal.
- Fomentar la protección y utilización racional de recursos naturales, medio
ambiente y prevención de riesgos y daños en la población por efectos naturales y
antrópicos.
- Modernizar y fortalecer la gestión pública regional en un marco de eficiencia y
democracia participativa.

5
Gerencia Sub Regional de Tayacaja ROF Y CAP Ordenanza REG 255-2018 GSRT.
6
Gerencia Sub Regional de Tayacaja ROF Y CAP Ordenanza REG 255-2018 GSRT.

17
- Desarrollar una oferta turística competitiva y sostenible en el departamento de
Huancavelica.

1.9. DESCRIPCIÓN DEL ÁREA DE PRÁCTICAS7


La Unidad de Servicios múltiples (logística) es el órgano de línea dependiente de la
gerencia sub regional, que promueve la generación de empleo productivo,
dinamizando la economía mejorando el nivel de vida, incentivando la producción y el
valor agregado; fomenta las oportunidades de negocios y orienta el crecimiento de su
comunidad, impulsando actividades y proyectos en materia de: turismo, comercio,
artesanía, pesquería, industria, energía y minas e hidrocarburos y toda función que no
esté contemplado en los órganos de línea.
1.9.1. RESPONSABLE DE LA OFICINA SUB REGIONAL DE ESTUDIOS PRE
INVERSIÓN
Apellidos y Nombres : Pedraza Medrano, Marilú
Cargo : Directora de estudios de pre inversión
Teléfono : 947668368
E – Mail : pedrazamarilu@gmail.com

7
Gerencia Sub Regional de Tayacaja ROF Y CAP Ordenanza REG 255-2018 GSRT.

18
CAPÍTULO II

PLAN DE ACTIVIDADES DE PRÁCTICAS PRE PROFESIONALES

Para hacer realidad la implementación del programa realizado durante las prácticas pre -
profesionales se planteó los siguientes objetivos, metas, tareas y actividades que a
continuación se describen.
2.1. OBJETIVOS
2.1.1. OBJETIVO GENERAL
Desarrollar e implementar un sistema de registro de inventarios en la GERENCIA
SUB REGIONAL DE TAYACAJA para la oficina de logística.
2.1.2. OBJETIVOS ESPECÍFICOS
 Recopilar información para realizar el análisis del sistema.
 Diseñar la interfaz de usuario siendo interactivo a la vez programar el código
fuente para el registro de las actividades de la oficina de logística.
 Implementar el programa en la oficina de logística de la Gerencia Sub
Regional de Tayacaja.
2.2. METAS
Entre las metas trazadas en el desarrollo del sistema se fijaron los siguientes:
 Efectuar las encuestas y entrevistas a los trabajadores encargados del área de
logística y almacén para obtener los requerimientos necesarios del sistema.
 Cumplir con los objetivos durante el plazo establecido según el diagrama de
actividades.
 Utilizar las técnicas de recolección de datos como encuestas, entrevistas a los
trabajadores para la recolección de información necesaria para el desarrollo del
sistema.
 Construir una base de datos consistente a medida del sistema.

19
2.3. TAREAS
En cuanto a las tareas realizadas todas fueron efectuadas por el responsable de realizar
las prácticas pre-profesionales ya que fue el único en desarrollar todo el proceso de
principio a fin.
En vista que las tareas son secuenciales se optó por basarse al cronograma de actividades
para no alterar el normal desarrollo del sistema.
2.4. CRONOGRAMA DE ACTIVIDADES
FECHA DE INICIO : 23 de junio del 2018.
FECHA DE FIN : 23 de junio del 2018.
HORARIO : Lunes a Viernes, de 2:30 am a 7:00 pm
2.4.1. ACTIVIDADES
ACTIVIDAD 1.-Recopilación de la información y Análisis del Programa.
ACTIVIDAD 2.-Diseño de la interfaz y programación de código fuente.
ACTIVIDAD 3.-Prueba, mejoras y puesta en marcha del sistema.

20
2.4.2. CRONOGRAMA DE ACTIVIDADES

Nº ACTIVIDADES MESES

JUNIO AGOSTO SEPTIEMBRE OCTUBRE

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

1 Recopilación de X X X
la información

2 Diseño del X X X X X
interfaz y
programación
del código fuente

3 Prueba, mejora y X X X
puesta en marcha
del sistema

4 Implementación X X X
y mantenimiento
del sistema

Tabla Nro.1.Cronograma de Actividades para la implementación del sistema


fijado de JUNIO a OCTUBRE de 2018.

2.4.3. DESCRIPCIÓN BÁSICA DE LAS ACTIVIDADES


En el capítulo IV se detalla todas las actividades y procedimientos seguidos en
el desarrollo del sistema, sin embargo, en este punto se describe de una manera
generalizada cada uno de las actividades que se desarrollaron para poder finalizar
satisfactoriamente con la implementación del sistema.
2.4.3.1. ACTIVIDAD 1.-RECOPILACIÓN DE LA INFORMACIÓN
PARA LA BASE DE DATOS

Es una de las actividades que se ejecutó en el principio del desarrollo


del sistema mediante una la entrevista al encargado para el análisis de
los requerimientos y diseño de la base de datos del sistema.
En este proceso se tuvo que conocer en primer lugar el funcionamiento
de la oficina lo que tomó un buen tiempo, también se recolectó
información de todo tipo referente al movimiento y circulación de los

21
datos en la oficina, pues luego se clasificó, organizó, diseñó y por
último se estructuró en una base de datos de la información obtenida.
2.4.3.2. ACTIVIDAD 2.- DISEÑO DE LA INTERFAZ Y
PROGRAMACIÓN DE CÓDIGO FUENTE

Al finalizar la primera actividad, se prosiguió a diseñar la interfaz del


usuario de acuerdo a los requerimientos del cliente (encargado de la
Oficina de Logística), una vez culminado el diseño de la interfaz se pasó
a la creación del código fuente del sistema los cuales incluye la
validación del sistema en desarrollo, todo este proceso se desarrolló en
la plataforma de NetBeans 8.0.
2.4.3.3. ACTIVIDAD 3.- PRUEBA, MEJORAS Y PUESTA EN MARCHA
DEL SISTEMA

En esta actividad lo que se hizo fue que se ponga en marcha el sistema


desarrollado, pero solo de modo de prueba de errores los cuales nos
permitió corregir muchos de ellos principalmente en la validación del
sistema, finalizado la prueba se puso en marcha el sistema completo con
datos más consistentes, ya que se habían superado los errores que se
generaron durante la prueba de errores.
2.4.3.4. ACTIVIDAD 4.- IMPLEMENTACIÓN Y MANTENIMIENTO
DEL SISTEMA

Es la última actividad que se realizó durante el desarrollo del sistema,


lo cual consta en la implementación definitiva del producto final que
viene funcionando en la oficina de logística.
Posteriormente se hizo algunos mantenimientos generales en los que no
se obtuvo problemas que pudieran causar el retroceso de la puesta en
marcha del sistema.

2.5. METODOLOGÍAS
Para el desarrollo del presente sistema se empleó la metodología RUP (Rational
Unified Process), por ser un proceso que integra las mejores prácticas de desarrollo de
software a través de la definición de procesos, flujos de actividades, roles, guías,
documentos patrón, ejemplos y métricas. Las fases a utilizar de esta metodología son

22
las fases de inicio, elaboración y construcción. También se utilizó la Metodología de
Gestión por Procesos.
 Modelado del negocio: Se Analizara y entenderá las necesidades del área para
el cual se está desarrollando el software. Donde se diseñara el proceso actual del
área de logísticas para el requerimiento de almacén para ver las necesidades de
este y luego realizar sus mejoras a través de un nuevo diseño.
 Requisitos: Se identificaran todos los requisitos necesarios para la construcción
y funcionalidad del sistema.
 Análisis y Diseño: Se traslada los requisitos analizados anteriormente a un
sistema automatizado y desarrollar una arquitectura para el sistema.
 Implementación: Se realizara la implementación del sistema en la Unidad de
logística.
 Pruebas: Se realizara las pruebas del sistema para asegurarse de que el
comportamiento requerido es correcto y que todo lo solicitado está presente.

2.6. INSTRUMENTOS, EQUIPOS Y HERRAMIENTAS


Para que la implementación del sistema se realice con normalidad se requirió del uso de
los siguientes materiales:
a) EQUIPOS
 Laptop TOSHIBA, (Procesador: Intel Core i 5, RAM: 6 GB, HD: 500 GB
, Monitor: 14 pulgadas).- Se utilizó para el desarrollo y elaboración del
Software.
 Escáner: Se utilizó para escanear los documentos de prácticas pre
profesionales y el certificado de prácticas.
 USB 8 GB: Utilizado para trasladar información, software e instaladores.
b) SOFTWARE
Entornos CASE (y meta-CASE)

 Enterprise Architect.
Editores / IDEs personalizables:

 Java Neetbeans 8.0


 XAMPP (phpmyadmin).

23
Otros

 Google Chrome.
c) MATERIALES BIBLIOGRÁFICOS, DE CONSULTAS Y DE
ESCRITORIO
 Libros y tutoriales.
 Videos y audios.
 Internet.
 Estructura General Organizativa.

MATERIALES BIBLIOGRÁFICOS, DE CONSULTAS Y DE ESCRITORIO

 Libros y tutoriales
 Videos y audios
 Hojas bond, lapiceros, corrector, borrador, lápiz, etc.,
 Internet
 Reglamento de Organización y Funciones (ROF)
 Manual de Organización y Funciones (MOF)
 Entre otros

24
CAPÍTULO III
DOCUMENTACIÓN BIBLIOGRÁFICA
Aquí se presenta la descripción de todo el marco teórico consultado y utilizado para el
correcto y normal desarrollo del sistema.

3. LENGUAJE UNIFICADO DE MODELADO (UML)

3.1. DEFINICIÓN DE LENGUAJE UNIFICADO DE MODELADO8


El Lenguaje Unificado de Modelado (UML) es un lenguaje de modelado visual
de propósito general que es usado para especificar, visualizar, construir y
documentar los artefactos de un sistema software (Jacobson I., Booch G. y
Rumbaugh J, 2000). El UML captura información acerca de la estructura estática
y el comportamiento dinámico de un sistema. Un sistema es modelado como una
colección de objetos discretos que interactúan para desempeñar un trabajo que
en última instancia beneficia a un usuario externo. La estructura estática define
el tipo de objetos importantes para un sistema y su implementación, así como la
relación entre los objetos. El comportamiento dinámico define la historia de los
objetos sobre el tiempo y la comunicación entre objetos para cumplir metas.
Partiendo del hecho que las diferencias entre los métodos disminuyen y que la
guerra de métodos no hace progresar la tecnología de objetos, Jim Rumbaugh y
Grady Booh decidieron a finales de 1.994, unificar sus trabajos en un método
único: El Método Unificado (The Unified Method). Un año más tarde se les unió
Iván Jacobson. Los tres autores fijaron cuatro objetivos:
 Representar sistemas completos (más allá de un solo programa) por
conceptos de objetos.
 Establecer una relación explícita entre los conceptos y los artefactos
ejecutables.

8
Arlow J., Neustad I. “ProgramaciónUML2”. (2006)

25
 Tener en cuenta los factores de escala inherentes a los sistemas complejos y
críticos.
 Crear un lenguaje de modelado utilizable tanto por los humanos como por
las máquinas.

3.1.1. MODELOS9
Un modelo es la representación en un cierto medio de algo en el mismo u otro
medio. El modelo captura los aspectos importantes del ente que será modelado
desde un cierto punto de vista, simplificando u omitiendo el resto.
Modelo de Casos de Uso: El modelo de casos de uso permite que los
desarrolladores de software y los clientes lleguen a un acuerdo sobre los
requisitos. Contiene actores, casos de uso y sus relaciones.
Modelo de Análisis: El modelo de análisis se representa mediante un sistema
de análisis que denota el paquete de más alto nivel del modelo. La utilización de
otros paquetes de análisis es por tanto una forma de organizar el modelo de
análisis en partes más manejables que representan abstracciones de subsistemas
y posiblemente capas completas del diseño del sistema.
Modelo de Diseño: El modelo de diseño es un modelo de objetos que describe
la realización física de los casos de usos centrándose en cómo los requisitos
funcionales y no funcionales, junto con otras restricciones relacionadas con el
entorno de implementación, tienen impacto en el sistema a considerar.

3.1.2. DIAGRAMAS10
Un diagrama es la representación gráfica de un conjunto de elementos,
usualmente representado como un grafo conectado de vértices (elementos) y
arcos (relaciones).
a) DIAGRAMAS DE CASOS DE USOS
Un diagrama de caso de uso es un diagrama que muestra un conjunto de casos
de uso, actores y sus relaciones. Los mismos sirven para especificar la
funcionalidad y el comportamiento de un sistema mediante su interacción con
los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la
relación entre los actores y los casos de uso dentro de un sistema. A

9
Arlow J., Neustad I. “ProgramaciónUML2”. (2006)
10
Arlow J., Neustad I. “ProgramaciónUML2”. (2006)

26
continuación, se explican los elementos del diagrama de casos de usos con
detalle:
 Casos de Usos: Un caso de uso describe un conjunto de
secuencias, donde cada una representa la interacción de los
elementos externos al sistema (Actores) con el mismo sistema.
 Actor (es): Un actor es la representación de un conjunto coherente
de roles que los usuarios de los casos de uso juegan cuando
interactúan con estos. Por lo general, representan el papel
desempeñado por una persona, un dispositivo, un objeto e incluso
otro sistema que interactúa con el sistema propuesto.
 Relación de Dependencia: Es una conexión de uso que indica
que cualquier cambio en un elemento puede afectar a otro
elemento que la utiliza, pero no necesariamente de modo inverso.
Esta es representada por una flecha, de línea no continua,
orientada hacia el elemento del que se depende.
 Relación de Generalización: Es la relación que existe entre un
elemento general y un caso específico de ese mismo elemento. La
generalización significa que los objetos hijos se pueden emplear
en cualquier lugar donde pueda aparecer el padre, más no a la
inversa. Esta relación se representa por una flecha continua con
punta vacía orientada hacia el padre.
 Relación de Asociación: Se entiende por la relación estructural
que indica que los objetos de un elemento están conectados con
los objetos de otro. Una asociación se representa por una línea
continua que conecta las clases.

27
3.2. SOFTWARE Y SISTEMAS DE INFORMACIÓN

3.2.1. DEFINICIÓN DE SOFTWARE11


Es el conjunto de los programas de cómputo, procedimientos, reglas,
documentación y datos asociados. Que forman parte de las operaciones de un
sistema de computación.
Considerando esta definición, el concepto de software va más allá de los
programas de computación en sus distintos estados: código fuente, binario o
ejecutable; también su documentación, los datos a procesar e incluso la
información de usuario forman parte del software: es decir, abarca todo lo
intangible, todo lo (no físico) relacionado.
El concepto de leer diferentes secuencias de instrucciones (programa) desde la
memoria de un dispositivo para controlar los cálculos fue introducido por
Charles Babbage como parte de su máquina diferencial.

3.2.2. DEFINICIÓN DE SISTEMAS DE INFORMACIÓN12


Un sistema de información (SI) es un conjunto de elementos orientados al
tratamiento y administración de datos e información, organizados y listos para
su uso posterior, generados para cubrir una necesidad o un objetivo. Dichos
elementos formarán parte de alguna de las siguientes categorías:
 Personas
 Actividades o técnicas de trabajo
 Datos
 Recursos materiales en general (recursos informáticos y de comunicación,
generalmente, aunque no necesariamente).
Todos estos elementos interactúan para procesar los datos (incluidos los
procesos manuales y automáticos) y dan lugar a información más elaborada, que
se distribuye de la manera más adecuada posible en una determinada
organización, en función de sus objetivos.

11
Seen. J.“análisis y diseño de sistemas de información”. (1992).
12
https://es.wikipedia.org/wiki/Sistema_de_informaci%C3%B3n

28
Imagen Nº 2 Elementos de un sistema de información.
Fuente: Libro de análisis y diseño de sistemas de información.

3.2.3. ACTIVIDADES BÁSICAS DE LOS SISTEMAS DE INFORMACIÓN13


Los Sistemas de Información realizan las diversas actividades principales
haciendo uso de la computadora, lo cual permite un mejor desempeño de los
sistemas de información en las organizaciones públicas y privadas.
Las actividades básicas de un sistema de información son las siguientes:
 Entrada de datos: Proceso mediante el cual se captura y prepara datos
para su posterior procesamiento. Las entradas pueden ser manuales o
automáticas. Las manuales se realizan por el operador o el usuario, y las
automáticas surgen de otros sistemas.
 Almacenamiento de datos: El almacenamiento es una de las actividades
o capacidades más importantes que tiene una computadora, ya que a través
de esta propiedad el sistema puede recordar la información guardada en la
sección o proceso anterior.
 Procesamiento de datos: Es la capacidad de efectuar operaciones con los
datos guardados en las unidades de memoria. Durante este procesamiento
se evidencia lo siguiente:
 Aumenta, manipula y organiza la forma de los datos.
 Analiza y evalúa su contenido.

13
http://izamorar.com/actividades-basicas-de-un-sistema-de-informacion/

29
 Selecciona la información para ser usada en la toma de decisiones, y
constituye un componente clave en el sistema de información
gerencial.
 Salida de datos: Actividad que permite transmitir información útil y
valiosa a los usuarios finales.

Imagen Nº 3. Actividades de un sistema de información.


Fuente: Libro de análisis y diseño de sistemas de información.

3.2.4. ANÁLISIS Y DISEÑO DEL SISTEMA14


El análisis y diseño del sistema se refiere al proceso de explorar la situación de
la organización con el propósito de mejorarla con métodos y procedimientos más
adecuados, en el caso de este sistema se utilizó el Lenguaje de Modelado
Unificado (UML).
El análisis de sistemas, es el proceso de clasificación e interpretación de hechos,
diagnósticos de problemas y empleo de la información para recomendar mejoras
al sistema. El análisis especifica que es lo que el sistema debe hacer y cómo se
va realizar.

3.2.5. DESARROLLO DEL DISEÑO DEL SISTEMA15


Es un proceso que consta de las siguientes actividades:

14
Senn, J. Análisis y Diseño de Sistemas de Información”. (1992).
15
Senn, J. “Análisis y Diseño de Sistemas de Información”. (1992)

30
a) INVESTIGACIÓN PRELIMINAR
La solicitud para recibir ayuda de un sistema de información puede
originarse por varias razones; sin importar cuales sean éstas, el proceso
se inicia siempre con la petición de una persona (administrador,
empleado, o especialista en sistemas).
Cuando se formula la solicitud, comienza la primera actividad: la
investigación preliminar. Esta tiene tres partes: Aclaratoria de la
solicitud, estudio de factibilidad y aprobación de la solicitud.
b) ACLARACIÓN DE LA SOLICITUD
Muchas solicitudes que provienen de empleados y usuarios no están
formuladas de manera clara. Por consiguiente, antes de considerar
cualquier investigación de sistemas, la solicitud de proyecto debe
examinarse para determinar con precisión lo que el solicitante desea. Si
el solicitante pide ayuda sin saber qué es lo que está mal o donde se
encuentra el problema, la aclaración del mismo se vuelve más difícil y
más complicado.
c) ESTUDIO DE FACTIBILIDAD
El sistema solicitado debe ser factible en tres aspectos:
 Factibilidad técnica: El trabajo para el proyecto, ¿puede realizarse
con el equipo actual, la tecnología existente de software y el
personal disponible?, y si se cuenta con la tecnología ¿cuál es la
posibilidad de desarrollarla?
 Factibilidad económica: Al crear el sistema, ¿los beneficios que
se obtienen serán suficientes para aceptar los costos?, ¿los costos
asociados con la decisión de no crear el sistema son tan grandes
que se debe aceptar el proyecto?
 Factibilidad operacional: Si se desarrolla e implanta, ¿será
utilizado el sistema?, ¿existirá cierta resistencia al cambio por parte
de los usuarios?
d) APROBACIÓN DE LA SOLICITUD
No todos los proyectos solicitados son deseables o factibles. Los que
son deben incorporarse a los planes. Muchas organizaciones desarrollan
sus planes para sistemas de información con el mismo cuidado con el

31
que planifican nuevos productos y programas de fabricación o la
expansión de las instalaciones.

3.2.6. DISEÑO DEL SISTEMA16


El diseño de un sistema de información produce los detalles que establecen la
forma en la que el sistema cumplirá con los requerimientos identificados durante
la fase de análisis.
Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como
diseño lógico en contraste con la de desarrollo de software a la que denominan
diseño físico.
Los analistas de sistemas comienzan el proceso de diseño identificando los
reportes y demás salidas que debe producir el sistema. Hecho lo anterior se
determinan con toda precisión los datos específicos para cada reporte y salida.
El diseño de un sistema también indica los datos de entrada, aquellos que serán
calculados y los que deben ser almacenados. Los documentos que contienen las
especificaciones de diseño representan a éste de muchas maneras (diagramas,
Tablas, y símbolos especiales).
La información detallada del diseño se proporciona al equipo de programación
para comenzar la fase de desarrollo de software.
3.3. BASE DE DATOS

3.3.1. DEFINICIÓN DE BASE DE DATOS17


Una base de datos es una colección de datos relacionados. Por datos, se quiere
decir, hechos conocidos que pueden registrarse y que tienen un significado
implícito. Una base de datos tiene las siguientes propiedades implícitas:
Una base de datos representa algunos aspectos del mundo real, en ocasiones
denominado mini mundo o Universo del Discurso. Los cambios en el mini
mundo se reflejan en la base de datos.
Una base de datos es una colección de datos lógicamente coherentes, con algunos
significados inherentes. Un conjunto aleatorio de datos no puede considerarse
como una base de datos.

16
Senn, J. “Análisis y Diseño de Sistemas de Información”. (1992).
17
Elmasri R., Navathe S. “Sistemas de Bases de Datos. Conceptos Fundamentales”. (2000).

32
Las bases de datos se diseñan, construyen y pueblan con datos para un propósito
específico. Está destinada a un grupo de usuarios y tiene algunas aplicaciones
preconcebidas de interés para dichos usuarios.

3.3.2. SISTEMA DE GESTIÓN DE BASE DE DATOS (SGBD)18


Es una colección de programas que permiten a los usuarios crear y mantener una
base de datos. Por lo tanto, un SGBD es un sistema de software de propósito
general que facilita los procesos de definición, construcción, y manipulación de
base de datos para distintas aplicaciones. Ahora veamos descrito cada uno de
estos procesos:
 La definición: Consiste en especificar los tipos de datos, las estructuras
y restricciones para los datos que se van a almacenar en dicha base de
datos.
 La construcción: Es el proceso de almacenar los datos concretos sobre
algún medio de almacenamiento controlado por el SGBD.
 La manipulación: Incluye funciones como consultar la base de datos
para recuperar unos datos específicos, actualizar la base de datos para
reflejar los cambios ocurridos en el mini mundo, y generar informes a
partir de los datos.

3.3.3. COMPONENTES DE UNA BASE DE DATOS 19


Una arquitectura apropiada para los sistemas de base de datos es llamada
arquitectura de tres esquemas también conocida como la arquitectura
ANSI/SPARC, la cual tiene como objetivo separar las aplicaciones del usuario
y la base de datos física. Esta arquitectura se define en los tres niveles siguientes:

 EL NIVEL INTERNO: Tiene un esquema interno, que describe la


estructura física de almacenamiento de la base de datos. El esquema
interno emplea un modelo de datos físico y describe todos los detalles para
su almacenamiento, así como los caminos de acceso para la base de datos.
 EL NIVEL CONCEPTUAL: Tiene un esquema conceptual, que describe
la estructura de la base de datos completa para una comunidad de usuarios.

18
Elmasri R., Navathe S. “Sistemas de Bases de Datos. Conceptos Fundamentales”. (2000).
19
Elmasri R., Navathe S. “Sistemas de Bases de Datos. Conceptos Fundamentales”. (2000).

33
El esquema conceptual oculta los detalles de las estructuras físicas de
almacenamiento y se concentra en describir entidades, tipos de datos,
vínculos, operaciones de los usuarios y restricciones. En este nivel
podemos usar un modelo de datos de alto nivel o uno de implementación.
 EL NIVEL EXTERNO O DE VISTAS: Incluye varios esquemas
externos o vistas de usuario. Cada esquema externo describe la parte de
la base de datos que interesa a un grupo de usuarios determinado, y
oculta a ese grupo el resto de la base de datos.
 El modelo de datos relacional.
 El modelo de red.
 El modelo jerárquico.

3.3.4. XAMPP20
XAMPP es un servidor independiente de plataforma, software libre, que
consiste principalmente en el sistema de gestión de base de datos MYSQL, el
servidor web Apache y los intérpretes para lenguajes de script: PHP y Perl.

20
https://es.wikipedia.org/wiki/XAMPP.

34
Imagen Nº 4. Ventana principal de XAMPP for Windows localhost.
Fuente: Xampp para Windows.

3.3.5. MYSQL21
MYSQL es un sistema de administración de bases de datos (Database
Management System, DBMS) para bases de datos relacionales así, MYSQL
no es más que una aplicación que permite gestionar archivos llamados de
bases de datos.

Existen muchos tipos de base de datos, desde un simple archivo hasta


sistemas relacionales orientados a objetos. MYSQL, como base de datos
relacional, utiliza múltiples tablas para almacenar y organizar la información.
MYSQL fue escrito en C y C++ y destaca por su gran adaptación a diferentes
entornos de desarrollo, permitiendo su interactuación con los lenguajes de
programación más utilizados como PHP, Perl y Java y su integración en
distintos sistemas operativos.

21
https://es.wikipedia.org/wiki/MySQL

35
Imagen Nº 5. Arquitectura de la plataforma MYSQL server.
Fuente: Mysql Data Base.
3.4. PROGRAMACIÓN ORIENTADA A OBJETOS

3.4.1. DEFINICIÓN DE LA PROGRAMACIÓN ORIENTADA A OBJETOS22


La programación orientada a objeto (POO) tiene la ventaja de ser un paradigma
natural donde se pueden programar sistemas. Los seres humanos perciben el
mundo como si estuviera formado por objetos: mesas, sillas, computadoras,
coches, cuentas bancarias, partidos de fútbol, etc. También es un instinto humano
intentar organizar estos objetos disponiéndolos de una forma concreta, optando
por destacar determinadas características de algunos objetos que los destacan de
otros.
Los niveles de dichas categorías y los métodos de clasificación de objetos en el
mundo son infinitos. La forma en que las personas clasifican las cosas depende,
en gran medida, de lo que deseen hacer con ellas y las características que más
les llamen la atención. A la vez que se agrupan los objetos atendiendo a
esquemas de clasificación, también se tiende a resaltar determinados atributos
de objetos mostrando su preferencia sobre otros.

22
Miguel Ángel Álvarez, “La programación orientada a objetos”.1990.

36
La clave es la posibilidad de identificar los atributos importantes de objetos y
formar abstracciones y jerarquías idóneas.

3.4.2. CARACTERÍSTICAS DE LOS LENGUAJES PROGRAMACIÓN


ORIENTADA A. OBJETOS23
Los lenguajes de programación orientada a objetos (como C++, C#, Java y PHP)
se caracterizan por tres conceptos clave: encapsulación, herencia y
polimorfismo, que son compatibles con este aspecto natural de identificación y
clasificación de objetos.
a) ENCAPSULACIÓN
La encapsulación facilita la compresión de los grandes programas; la
ocultación de datos les hace más eficaces. Los objetos pueden interactuar
con otros objetos sólo a través de los atributos y métodos del objeto que
se muestran públicamente. Cuantos más atributos y métodos se muestren
públicamente, más difícil será modificar la clase sin que ello afecte al
código que utiliza la clase. Una variable oculta se podría cambiar de un
long a un double, sin que ello afecte al código que utilicen los objetos
creados (instanciados) de esa clase.
El programador solo se debería preocupar por los métodos en la clase que
han tenido acceso a esa clase, en lugar de por todos los sitios en el
programa que un objeto ha instanciado desde los que se puede llamar a la
clase.
b) HERENCIA
Proporciona dos ventajas evidentes a los programadores. La primera, y
más importante, es que permite crear jerarquías que expresen las
relaciones entre los diferentes tipos. Imagine que tiene dos clases, Cuenta
Ahorro y Cuenta Corriente, que proceden de la clase principal Cuenta. Si
tiene una función que necesite una clase Cuenta como argumento, podrá
pasarle una Cuenta Ahorro o una Cuenta Corriente, ya que ambas clases
son de tipos de Cuenta. Cuenta es una clasificación general, mientras que
Cuenta Corriente y Cuenta Ahorro son tipos más específicos.

23
Miguel Ángel Álvarez, “La programación orientada a objetos”.1990.

37
c) POLIMORFISMO
Polimorfismo significa, fundamentalmente, que las clases pueden tener el
mismo comportamiento, pero implementarse de distintas maneras. Esto
resulta muy útil en términos de programación, ya que permite trabajar con
tipos de objetos genéricos cuando lo que interesa no es cómo implementa
cada clase las funciones.

3.4.3. CLASES Y OBJETOS24


Como su propio nombre lo indica, la programación orientada a objetos está
relacionada con objetos. Un objeto se compone de datos que describen al objeto
y las operaciones que se pueden realizar en el objeto. No obstante, cuando se
crea un programa, en realidad se declaran y definen clases, no objetos.
Una clase es un tipo definido por el usuario, encapsula tanto los datos como los
métodos que funcionen en esos datos. Una clase es algo muy parecido a una
plantilla, que se utiliza para crear (instanciar) objetos.
3.5. LENGUAJE DE PROGRAMACIÓN JAVA.25
El Java es un lenguaje de programación orientado a objetos creado por James
Gosling en el año 1990. Su código es muy similar al del lenguaje C y C++ con
un modelo de objetos mucho más sencillo. La diferencia entre el Java y los
lenguajes C y C++ es que el Java es un lenguaje de programación plenamente
orientado a objetos.
Es muy fácil de aprender, en Java es relativamente sencillo programar desde el
principio. Todos los programadores que ya hayan programado anteriormente con
el C o el C++, les costara mucho menos su aprendizaje por la gran similitud entre
ellos.
El Java supuso un gran avance en los lenguajes de programación, tiene una
enorme potencia para el diseño orientado a objetos con un código sencillo en un
entorno muy estable y agradable. El Java nos permite realizar aplicaciones que
podemos incluir directamente en páginas web.
Estas aplicaciones se conocen con el nombre de applets. Estos son unos
programas que se transfieren dinámicamente a través de Internet. Los applets

24
Miguel Ángel Álvarez, “La programación orientada a objetos”. (1990).
25
https://es.wikipedia.org/wiki/Java_(lenguaje_de_programaci%C3%B3n)#Orientado_a_objetos

38
tienen un comportamiento inteligente, pueden reaccionar cuando un visitante
entra en una página web y cambian de forma. Todo esto ha posibilitado que el
Java sea un lenguaje interactivo entre el usuario y la aplicación.
La mayoría de los lenguajes de programación están compilados en código fuente,
mientras que el Java es compilado en un bytecode (código binario que contiene
un programa ejecutable) que es ejecutado por una máquina virtual de Java. Esta
máquina es la encargada de ejecutar todo el código de un programa hecho con
Java.
3.6. PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE

3.6.1. DEFINICIÓN DEL PROCESO DE DESARROLLO DE SOFTWARE26


El proceso Unificado es un proceso de desarrollo de software. Un proceso de
desarrollo de software es el conjunto de actividades necesarias para transformar
los requisitos de un usuario en un sistema de software. Sin embargo, el proceso
Unificado es más que un simple proceso; es un marco de trabajo genérico que
puede especializarse para una gran variedad de sistemas de software, para
diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes
niveles de aptitud y diferentes tamaños de proyecto.
El proceso Unificado está basado en componentes, lo cual quiere decir que el
sistema software en construcción está formado por componentes de software
interconectados a través de interfaces bien definidas.
El proceso Unificado utiliza el Lenguaje Unificado de Modelado (UML) para
preparar todos los esquemas de un sistema software; de hecho, UML es una parte
esencial del proceso Unificado.
El proceso unificado de desarrollo nace en vista de la necesidad de crear un
estándar para el desarrollo de software con la finalidad de satisfacer la creciente
demanda de sistemas más grandes, modernos y poderosos y que a su vez permita
disminuir el tiempo de desarrollo de los mismos.

26
Jacobson, I., Booch, G. Y Rumbaugh, J.“El Proceso Unificado de Desarrollo de Software”. (1999).

39
3.6.2. PRINCIPIOS BÁSICOS DEL PROCESO UNIFICADO DE DESARROLLO
DE SOFTWARE27
Los verdaderos aspectos definitorios del Proceso Unificado se resumen en tres
frases claves: dirigidos por casos de uso, centrados en la arquitectura, iterativo e
incremental. Esto es lo que hace único al proceso Unificado. A continuación, se
explican los principios básicos del Proceso Unificado de Desarrollo de Software:
a) PROCESO UNIFICADO DIRIGIDO POR CASOS DE USO
Cuando un usuario utiliza el sistema, se lleva a cabo una interacción que
consiste en una secuencia de acciones (tanto por parte del usuario como del
sistema) que proporcionan al usuario un resultado de valor importante para
él. Un caso de uso es precisamente una interacción de ese tipo, que deriva
en que el sistema debe incluir un fragmento de funcionalidad para
proporcionar al usuario el resultado de valor esperado.
Por tanto, los casos de uso representan los requisitos funcionales del sistema,
es decir, las necesidades de los usuarios y de la organización en donde se
desplegará el sistema.
b) PROCESO CENTRADO EN LA ARQUITECTURA
La arquitectura del software sirve para poder contemplar el futuro sistema
desde varios puntos de vista antes de que se construya y durante la
construcción. El concepto de arquitectura software incluye los aspectos
estáticos y dinámicos más significativos del sistema, es decir, especifica
la forma, estructura y comportamiento del sistema desde diversos puntos
de vista, todos ellos a un nivel de detalle que permita tener una idea global
clara sin perderse en detalles insignificantes (que, precisamente, no
influyen en la arquitectura del sistema).De esta forma quedan cubiertos
los dos aspectos fundamentales del sistema.

3.6.3. VIDA DEL PROCESO UNIFICADO28


El proceso unificado se repite a lo largo de una serie de ciclos que constituyen
la vida de un sistema. Cada ciclo consta de cuatro fases: inicio, elaboración,
construcción y transición.

27
Jacobson, I., Booch, G. Y Rumbaugh, J. “El Proceso Unificado de Desarrollo de Software”. (1999).
28
Jacobson, I., Booch, G. Y Rumbaugh, J.“El Proceso Unificado de Desarrollo de Software”. (1999)

40
En la ilustración 3, se puede visualizar las diferentes actividades: Requisitos,
Análisis, Diseño, Implementación y Prueba que tienen lugar sobre las 4 fases:
Inicio, Elaboración, Construcción y Transición.

Imagen Nº 6. Fases del proceso unificad.


Cada ciclo produce una nueva versión del sistema, y cada versión es un producto
preparado para su entrega; consta de un cuerpo de código fuente incluido en
componentes que puede compilarse y ejecutarse, además de manuales y otros
productos asociados. Sin embargo, el producto terminado no sólo debe ajustarse
a las necesidades de los usuarios, sino también a las de todos los interesados, es
decir, toda la gente que trabajará con el producto. El producto terminado incluye
los requisitos, casos de uso, especificaciones no funcionales y casos de prueba.
Incluye el modelo dela arquitectura y el modelo visual (artefactos modelados con
el UML).

3.6.4. FLUJOS DEL PROCESO UNIFICADO DE DESARROLLO DE


SOFTWARE29
Los flujos fundamentales: Requisitos, Análisis, Diseño, Implementación y
Pruebas, se distinguen entre los flujos de trabajos fundamentales e iterativos.
Dichos flujos no ocurren una sola vez, en el Proceso Unificado de Modelado,

29
Jacobson, I., Booch, G. Y Rumbaugh, J. “El Proceso Unificado de Desarrollo de Software”. (1999).

41
como sucede teóricamente en el modelo en cascada; sino que se repiten más bien
en cada iteración, una y otra vez, como flujos de trabajos iterativos. Cada
repetición, sin embargo, se diferencia en los detalles que se enfrentan o asuntos
centrales de cada iteración.
a) REQUISITOS
El esfuerzo principal en la fase de requisitos es desarrollar un modelo del
sistema que se va a construir, y la utilización de los casos de uso en una
forma adecuada de crear este modelo. Esto es debido a que los requisitos
funcionales se estructuran de forma natural mediante casos de uso, y a que
la mayoría de los otros requisitos no funcionales son específicos de un solo
caso de uso, y pueden tratarse en el contexto de ese caso de uso. Así, los
requisitos de un sistema se capturan en forma de:
 Un modelo del negocio o un modelo del dominio para establecer
el contexto del sistema.
 Un modelo de casos de uso que capture los requisitos
funcionales, y los no funcionales que son específicos de casos de
uso concretos. El modelo de casos de uso se realiza mediante una
descripción general, un conjunto de diagramas, y una descripción
detallada de cada caso de uso.
 Un conjunto de esbozos de interfaces de usuario y de prototipos
de cada actor, que representan el diseño de las interfaces de
usuario.
 Una especificación de requisitos adicionales para los requisitos
que son genéricos y no específicos de un caso de uso en
particular.
b) ANÁLISIS
Durante el análisis, estudiamos los requisitos que se describen en la
captura de requisitos, refinándolos y estructurándolos. El resultado del
flujo de trabajo del análisis es el modelo de análisis, que es un modelo del
objeto conceptual que analiza los requisitos mediante su refinamiento y
estructuración.
La vista de la arquitectura del modelo de análisis se utiliza como entrada
en la creación de la vista de la arquitectura del modelo de diseño. Es muy

42
probable que los elementos de las diferentes vistas (de los diferentes
modelos) tengas trazas entre ellos.
c) DISEÑO
En el diseño se modela el sistema y se encuentra la forma para que soporte
los requisitos que se suponen. El principal resultado del diseño es el
modelo de diseño. Se esfuerza en conservar la estructura del sistema
impuesta por el modelo de análisis, y que sirve como esquema para la
implementación. El modelo de diseño incluye los siguientes elementos:
 Subsistemas del diseño y subsistemas de servicio y sus
dependencias, interfaces y contenidos. Los subsistemas del
diseño de las dos capas superiores (las capas específicas de la
aplicación) se obtienen a partir de los paquetes del análisis
algunas de las dependencias entre subsistemas del diseño se
obtienen a partir de las correspondientes dependencias entre
paquetes del análisis. Algunas de las interfaces se obtienen a
partir de las clases del análisis.
 Clases del diseño, incluyendo las clases activas, y sus
operaciones, atributos y requisitos de implementación. Algunas
clases del diseño relevantes para la arquitectura se obtienen a
partir de las clases del análisis relevante para la arquitectura.
Algunas clases activas se obtienen a partir de clases del análisis
se utilizan como especificaciones al obtener las clases de diseño.
 Realizaciones de casos de uso-diseño, que describen como se
diseñan los casos de uso en términos de colaboraciones dentro
del modelo de diseño. En general, al obtener las realizaciones de
caso de uso-diseño utilizamos las realizaciones de caso de uso-
análisis como especificaciones.
d) IMPLEMENTACIÓN
El resultado principal de la implementación es el modelo de la
implementación, el cual incluye los siguientes elementos:
 Subsistemas de implementación y sus dependencias, interfaces y
contenidos.

43
 Componentes, incluyendo componentes ficheros y ejecutables, y
las dependencias entre ellos. Los componentes son sometidos a
pruebas de unidad.
 La vista de la arquitectura del modo de implementación,
incluyendo sus elementos arquitectónicamente significativos.
La implementación también produce como resultado un refinamiento de
la vista de la arquitectura de modelo de despliegue, donde los
componentes ejecutables son asignados a nodos. El modelo de
implementación es la entrada principal de las etapas de pruebas que siguen
a la implementación, más concretamente, durante la etapa de prueba cada
construcción generada durante la implementación es sometida a pruebas
de implementación, y posiblemente también a pruebas del sistema.
e) PRUEBAS
El resultado principal de la prueba es el modelo de prueba, el cual describe
como ha sido probado el sistema. El modelo reprueba incluye:
 Casos de prueba, que especifican que probar en sistema.
 Procedimientos de prueba, que especifican como realizar los
casos de pruebas.
 Componentes de pruebas, que automatizan los procedimientos de
pruebas.

44
CAPÍTULO IV
ACTIVIDADES Y PROCEDIMIENTOS
Aquí se detalla todas los objetivos específicos seguidas en el desarrollo e implementación
del sistema, como se describen el Capítulo II en presente informe se tiene básicamente
cinco objetivos específicos muy importantes los cuales fueron desarrollados de manera
secuencial.
Estos objetivos específicos son las siguientes:
 Objetivo 1: Recopilación de la información para realizar el análisis del sistema.
Para la recopilación de información se usaron las técnicas e instrumentos de recolección
de datos, una vez analizado los datos e información se pasaron a definir y detallar los
requerimientos funcionales, no funcionales, una vez obtenido los requerimientos se pasó
a la creación de la base de datos del sistema.
 Objetivo 2: Diseño de la interfaz de usuario interactivo y programación de código
fuente.
Para lograr este objetivo se definió mediante los diagramas de caso de uso como va ser
la funcionalidad del sistema, teniendo en cuenta esto se pasó a diseñar la interfaz del
sistema de almacén a la vez a programar su código fuente.
 Objetivo 3: Prueba, mejoras y puesta en marcha del sistema.
En este objetivo se realiza las pruebas necesarias para comprobar el buen
funcionamiento del sistema de inventarios, para así poder mejorarlo y poner en marcha
dicho sistema.
 Objetivo 4: Implementar el sistema de área en el área de trabajo.
En este objetivo se realizará la implementación del sistema de inventarios oficina de
Logística de la Gerencia Sub Regional de Tayacaja.
 Objetivo 5: Realizar el mantenimiento adecuado al Sistema:
La función de este objetivo es brindar una solución algunos errores que puede haber.

45
4.1. RECOPILACIÓN DE INFORMACIÓN PARA LA BASE DE DATOS

4.1.1. REQUISITOS DEL SISTEMA DE INFORMACIÓN


Se detalla la identificación de los requisitos del sistema para lo cual fue
fundamental trabajar con el Jefe de área de Logística Oscar Huanay Lopez la
directora del Área de Pre inversión Marilú Pedraza Medrano para así guiar el
desarrollo hacia un sistema eficaz y eficiente.
La técnica inmediata para identificar los requisitos del sistema se basa en los
casos de usos, éstos capturan tanto los requisitos funcionales como los no
funcionales que son específicos de cada caso de uso.
a) REQUISITOS FUNCIONALES
El sistema de almacén debe ser capaz de administrar la entrada-salida de
materiales y gestionar los usuarios que harán uso del mismo, por lo tanto:
 El sistema permitirá la autenticación de los administradores para el
acceso al sistema.
 El sistema permitirá el manejo de información de los
administradores.
 El sistema permitirá el manejo de información de los equipos y
licencias de software.
 El sistema permitirá el manejo de información de los servicios.
 El sistema permitirá el manejo de información del personal.
 El sistema permitirá registrar los materiales que existen, licencias de
software y servicios.
 El sistema permitirá generar los reportes en formato PDF e
imprimir.
b) REQUISITOS NO FUNCIONALES
 El sistema deberá funcionar en el área principal de Logística.
 La estructura y diseño del sistema será fácilmente adaptable a
cualquier cambio o mejora.
 El sistema deberá incluir el historial de materiales del municipio.
 El sistema posee una interfaz de fácil acceso, uso y manejo.

46
 El sistema deberá funcionar correctamente, sin errores durante la
jornada de trabajo de la Institución (8:00 a.m. – 6:30 p.m.)
c) REQUISITOS DE SOFTWARE
 Sistema Operativo Windows 7 o superior.
 Sistema de Gestión de Base de Datos Mysql.
 Adobe Acrobat Reader (PDF).
 Java NetBeans 8.0.2
e) REQUISITOS DE HARDWARE
 Procesador Corei 3 o superior.
 2 GB a más de memoria RAM.
 Espacio de en el disco duro superior a 50 GB.
 Impresora de cualquier tipo o marca.
 Discos o memoria de almacenamiento extraíbles.

4.1.2. TÉCNICAS E INSTRUMENTOS DE RECOLECCIÓN DE DATOS


Mediante el objetivo del sistema, se emplearon métodos, instrumentos y técnicas
orientadas a obtener información y datos a través de las siguientes técnicas:
a) OBSERVACIÓN DIRECTA
Se observó el funcionamiento de las operaciones que se realizaba en dicha
área, a fin de determinar por sus fuentes principales las causas de los
diferentes inconvenientes que se presentan en el área de almacén. Mediante
este tipo de técnica se pudo recolectar datos reales que permitió la
disminución del tiempo en la recolección de datos.
b) ENTREVISTA NO ESTRUCTURADA O INFORMAL
Se realizó algunas entrevistas a mano y papel los cuales las preguntas
fueron formuladas con anterioridad, este tipo de entrevista se aplicó
esencialmente al gerente y al encargado del área de logística.

4.1.3. TÉCNICAS DE ANÁLISIS DE DATOS


Se agruparon los resultados de las técnicas empleadas para obtener la
información y datos descritos anteriormente. Por lo tanto, el estudio consistió en
organizar los datos y presentar los resultados de interés de los actores a efecto
de captar y procesar los aspectos más importantes.

47
4.1.4. DISEÑO OPERATIVO
Para el desarrollo del sistema se empleó la metodología RUP (Rational Unified
Process), por ser un proceso que integra las mejores prácticas de desarrollo de
software a través de la definición de procesos, flujos de actividades, roles, guías,
documentos patrón, ejemplos y métricas.

4.1.5. RIESGOS DEL SISTEMA


Todos los riesgos técnicos pueden hacerse corresponder con un caso de uso o un
escenario correspondiente.
 Es importante conocer todas las necesidades del usuario y crear una visión
clara de lo que se quiere.
 Una arquitectura que no sea lo suficientemente robusta, es considerado un
riesgo crítico y debe solventarse durante la fase de inicio y elaboración.
4.2. DISEÑO DE LA INTERFAZ Y PROGRAMACIÓN DE CÓDIGO FUENTE
Para esto se empleó el modelo de casos de uso, identificación de los actores y cada uno
de sus especificaciones, asimismo se desarrolló el código fuente en plataforma personal,
utilizando el gestor de base de datos como Mysql y el lenguaje de programación Java
Netbeans.

4.2.1. MODELO DE CASOS DE USO


Los casos de uso es un modelo del sistema que nos permitió captar, crear y
documentar requisitos, que facilitó el desarrollo del software, permitió llegar con
el personal a un acuerdo sobre lo que se quiere del sistema, y proporcionar la
entrada fundamental para el análisis, diseño y las pruebas.

4.2.2. IDENTIFICACIÓN DE LOS ACTORES


Es importante realizar la identificación de los actores, ello permitió obtener
visión del entorno externo del sistema. A continuación, se describe cada uno de
los actores del sistema.
 Administrativo: Es el responsable del área de logística cuenta con
privilegios como administrador al ingresar al sistema.
 Almacenero: Es la persona encargada de realizar todos los pasos
concernientes al proceso que se realiza dentro del almacén, por lo tanto
también tiene el acceso de administrador al ingresar al sistema.

48
4.2.3. IDENTIFICACIÓN DE CASOS DE USO DEL MODELO ACTUAL
Se presenta el diagrama de casos de uso actual del área sin que el sistema esté
implementado, es decir con este diagrama se representa el modelo de
funcionamiento actual en la Municipalidad, el diagrama se representa a
continuación.

uc WIL

Solicita informacion
de materiales

Solicita materiales

Aprueba entrega de
materiales

Logistica

Personal

Rev isa material en Entrega informacion Entrega de material


inv entario de material

Imagen Nº 7. Diagrama de caso de uso de almacén (actual)


Fuente: Elaboración propia.

4.2.4. IDENTIFICACIÓN DE CASOS DE USO DEL SISTEMA PROPUESTO


Es aquí donde se presenta el diagrama de casos de uso en lo que el sistema está
basado.
 Acceder al Sistema: Este caso de uso permite al encargado
(administrativo y/o almacenero) ingresar al sistema comprobando su
identidad en el sistema tales como cargo, usuario y contraseña.
 Mantenimiento de información de los administradores: Es donde en
la cual el actor administrativo puede ingresar (nuevo), editar, guardar y
eliminar los datos de los usuarios.

49
 Mantenimiento de información de los equipos: Es donde en la cual el
actor administrador puede ingresar (nuevo), editar, guardar y eliminar los
datos de los mequipos con los que se cuenta.
 Mantenimiento de información de los usuarios: Es donde en la cual el
actor almacenero puede ingresar (nuevo), editar, guardar y eliminar los
datos del personal con los que se trabaja.
 Realizar entrega de equipos: El actor administrador realiza la entrega
de materiales según el pedido previamente solicitado por el personal.
 Generar reporte de entrega: En el sistema se realiza el documento de
entrega y se imprime.
 Consultar reporte al sistema: El sistema permite realizar reportes sobre
los registros de entrega, entrega por fechas y stock de equipos.

4.2.5. IDENTIFICACIÓN DE CASOS DE USO


El caso de uso principal permite representar una visión global del sistema, en él
se muestran las funciones primordiales. A continuación, se presentan
detalladamente los casos de uso para su mejor comprensión del sistema.

50
uc SIS IMPLEMENTAR

SISTEMA DE INVENTARIADO

Mantenimiento de inf de
administradores
Acceder al sistema

Mantenimiento de inf de
equipos

Mantenimiento de
informacion de
personal

Administrativ o Personal
Realizar entrega de
equipos

Generar reporte de
entrega

Consultar reporte al
sistema

Imagen Nº 8. Diagrama de casos de uso del sistema a implementar.


Fuente: Elaboración propia.
a) CASO DE USO ACCEDER AL SISTEMA
uc ACCEDER AL SISTEMA

ACCEDER AL
SISTEMA

ADMINISTRATIVO PERSONAL

Imagen Nº 9. Caso de uso acceder al sistema.

51
Fuente: Elaboración propia.
Tabla 2. Pasos para acceder al sistema

NOMBRE DE ACCEDER AL SISTEMA

CASO DE USO

Descripción Sirve para acceder al sistema para realizar cualquier


operación.

Datos 1. Cargo
Requeridos 2. Usuario.
3. Contraseña
Actores 1. Administrativo.
2. Invitado.

Acciones 1. Adm: Abre el sistema.


2. S: Muestra el formulario de identificación y pide
datos requeridos.
3. Adm: Ingresa datos solicitados y presionar
“INGRESAR.”
4. S: Validar datos.
Fuente: Elaboración propia.

52
b) CASO DE USO MANTENIMIENTO DE LA INFORMACIÓN DE
LOS ADMINISTRADORES
uc MANT DE INF ADMIN

Mantenimiento de
informacion de los
administradores

ADMINISTRATIVO

«extend» «extend» «extend»

Nuev o Editar Eliminar

Imagen Nº 10. Caso de uso mantenimiento de información de los administradores.


Fuente: Elaboración propia.

Tabla 3. Pasos para realizar el mantenimiento de la información de los administradores

NOMBRE DE CASO MANTENIMIENTO DE LA INFORMACIÓN DE LOS

DE USO ADMINISTRADORES

Descripción Permite ingresar nuevo, editar y eliminar datos de los


administradores que trabajan con el sistema.
Datos Requeridos 1. Código
2. Nombres
3. DNI
4. Celular
5. Tipo de acceso
6. Contraseña
Actores 1. Administrativo.
Acciones 1. Adm: Abre el formulario nuevo.
2. Adm: Ingresa datos al formulario.
A. Operación Nuevo 1. Adm: Rellena los datos del nuevo administrador
(administrativo).

53
2. S: Valida los datos.

B. Operación Editar 1. Adm: selecciona un administrador.


2. Adm: Rellena los datos a editar de los
administradores en el sistema.
3. S: Valida datos.
C. Operación 1. Adm: Selecciona un administrador
Eliminar 2. Adm: confirma la eliminación.
3. S: Elimina datos.
Fuente: Elaboración propia.

c) CASO DE USO MANTENIMIENTO DE INFORMACIÓN DE


EQUIPOS:
uc MANT INF EQUIPOS

Manteminiemto de
informacion de
equipos

ADMINISTRADOR

«include» «extend» «extend»

Nuev o
Editar Eliminar

Imagen Nº 11. Caso de uso mantenimiento de información de materiales.


Fuente: Elaboración propia.
Tabla 4. Pasos para realizar el mantenimiento de la información de equipos.

NOMBRE DE CASO DE MANTENIMIENTO DE LA INFORMACIÓN

USO DE EQUIPOS

Descripción Permite ingresar nuevo, editar y eliminar datos


de los equipos y licencias de software.
Datos Requeridos 1. Código

54
2. Nombre
3. Unidad de medida
4. Marca
5. Descripción
6. Stock
7. Imagen
Actores 1. Administrador.
Acciones 1. Adm: Abre el formulario nuevo.
2. Adm: Ingresa datos al formulario.
A. Operación Nuevo 1. T.A: Rellena los datos del nuevo material
2. S: Valida los datos.

B. Operación Editar 1. Adm: Selecciona un material.


2. Adm: Rellena los datos a editar del material.
3. S: Valida datos.
C. Operación Eliminar 1. Adm: Selecciona un material.
2. Adm: Confirma la eliminación.
3. S: Elimina datos.
Fuente: Elaboración propia

d) CASO DE USO MANTENIMIENTO DE INFORMACIÓN DE


PERSONAL:
uc MANT INF DE PERSONAL

Manteminiemto de
informacion de
personal

ADMINISTRADOR

«include» «extend» «extend»

Eliminar
Nuev o Editar

55
Imagen Nº 12. Caso de uso mantenimiento de información de personal.
Fuente: Elaboración propia.

Tabla 5. Pasos para realizar el mantenimiento de la información de personal.

NOMBRE DE MANTENIMIENTO DE LA INFORMACIÓN

CASO DE USO DE PERSONAL

Descripción Permite ingresar nuevo, editar y eliminar datos


de personal de la gerencia u otros.
Datos Requeridos 1. Código
2. Nombre
3. Apellido
4. Área
5. Teléfono/Celular
Actores 1. Adminstrador.
Acciones 1. Adm: Abre el formulario nuevo.
2. Adm: Ingresa datos al formulario.
A. Operación Nuevo 1. Adm: Rellena los datos del nuevo personal.
2. S: Valida los datos.
B. Operación Editar 1. Adm: selecciona un personal.
2. Adm: Rellena los datos a editar del personal.
3. S: Valida datos.
C. Operación 1. Adm: Selecciona personal.
Eliminar 2. Adm: confirma la eliminación.
3. S: Elimina datos.

Fuente: Elaboración propia.

56
f) CASO DE USO REALIZAR ENTREGA DE EQUIPOS:
uc ENTREGA DE EQUIPOS

Realizar entrega de
equipos Cancelar entrega
«extend»

ADMINISTRATIVO
«include»
«include»
Buscar y asignar
personal «include» «include»
Finalizar entrega

Agregar cantidad
Buscar y agregar
total
equipos

Imagen Nº 13. Caso de uso realizar entrega de equipos.


Fuente: Elaboración propia.

Tabla 6. Pasos para realizar entrega de equipos.

NOMBRE DE CASO REALIZAR ENTREGA DE EQUIPOS

DE USO

Descripción Permite buscar y asignar cliente, buscar y


agregar equipos, agregar cantidad total, finalizar
entrega y cancelar entrega.
Datos Requeridos 1. Código
2. Área del personal
3. Nombre del personal
4. Producto
5. Cantidad
6. Fecha
Actores 1. Administrador
Acciones 1. Adm: Abre el formulario nuevo.
2. Adm: Rellena datos al formulario.

57
A. Operación buscar 1. Adm: Busca personal.
2. S: Muestra el personal.
3. Adm: Selecciona al personal.
4. S: Asigna al personal.
B. Operación agregar 1. Adm: Selecciona el material.
2. Adm: Agrega el material.
3. S: Valida datos.
C. Operación cancelar 1. Adm: Selecciona una entrega.
2. Adm: Acepta la condición.
3. S: Cancela entrega.
Fuente: Elaboración propia.

g) CASO DE USO GENERAR ENTREGA

uc GENERAR ENTREGA

Generar reporte de
entrega

ADMINISTRADOR

Imagen Nº 14. Casos de uso generar reporte de entrega.


Fuente: Elaboración propia.

Tabla 7. Pasos para generar reporte de entrega.

NOMBRE DE GENERAR ENTREGA

CASO DE USO

Descripción Permite generar el reporte de entrega.

Datos Requeridos 1. Número de entrega.


Actores 1. Administrador.

Acciones 1. Administrador: Generar reporte de entrega.

58
2. S: El reporte de entrega generado se exporta en
formato PDF.

Fuente: Elaboración propia

h) CASO DE USO CONSULTAR REPORTES


uc CONSULTAR REPORTES

Stock de materiales

ADMINISTRATIVO

«include»

Consultar reporte al
sistema

«extend»

Consultar entrega por


fecha

USUARIO

Imagen Nº 15. Caso de uso consultar reportes.


Fuente: Elaboración propia.

59
Tabla 8. Pasos para consultar reportes

NOMBRE DE CONSULTAR REPORTES AL SISTEMA

CASO DE USO

Descripción El caso de uso puede realizar reportes como: hoja


stock de materiales y consulta de entregas por
fechas.
Datos Requeridos 1. Inserción de datos (fecha).
Actores 1. Administrativo.
2. Almacenero.
Acciones 1. Adm: Abre el formulario.
2. S: Muestra el formulario solicitado.
3. S: Muestra reporte de registro solicitado.
A. Operación 1. Adm: Ingresa datos (fecha) al sistema.
Reporte 2. S: Valida datos.
Solicitado 3. S: Muestra reporte de registro.
Fuente: Elaboración propia.

4.2.6. IMPLEMENTACIÓN DE LA BASE DE DATOS DEL SISTEMA


Después del análisis del flujo de datos del área se llegó a crear una base de datos,
en la cual el sistema desarrollado está almacenando los datos ingresados.

60
a) DEFINICIÓN DE LAS TABLAS DE LA BASE DE DATOS
RELACIONAL

Imagen Nº 16. Diseño de base de datos del Sistema


Fuente: Elaboración propia.

4.2.7. DISEÑO DE LA INTERFAZ


El Prototipo de interfaz usuario refleja a rasgos muy generales de cómo será el
diseño de la aplicación del sistema, esto por medio de un esquema de las
interfaces principales. Los prototipos se fueron diseñados teniendo como guía
los casos de uso que se han venido estudiando a lo largo de la fase de inicio y
elaboración de la interfaz.
El sistema tiene una interfaz muy amigable y una estructura única en todos los
formularios empleados en el sistema.

61
a) INTERFAZ DE AUTENTICACIÓN DE USUARIO
Es la primera pantalla del sistema que se presenta al ejecutar el
programa, como se muestra a continuación:

Imagen Nº 17. Interfaz de autentificación del usuario.


Fuente: Elaboración propia.

b) INTERFAZ PRINCIPAL
Es la pantalla principal del sistema de inventario.

62
Imagen Nº 18. Interfaz principal.
Fuente: Elaboración propia.
c) INTERFAZ REGISTRO DE PERSONAL
Es el interfaz que muestra la ventana de registro de personal del
municipio.

Imagen Nº 19. Interfaz registro de personal.


Fuente: Elaboración propia.
e) INTERFAZ DE PERSONAL REGISTRADOS.
En esta interfaz se muestra el listado de personal del municipio.

63
Imagen Nº 20. Interfaz de personal registrado.
Fuente: Elaboración propia.
f) INTERFAZ DE REGISTRO DE EQUIPOS Y LICENCIAS
Es el interfaz que muestra la ventana de registro de materiales.

Imagen Nº 21. Interfaz registro de personal.


Fuente: Elaboración propia.

64
g) INTERFAZ DE EQUIPOS REGISTRADOS
En esta interfaz se muestra la ventana del listado de materiales ya
registrados.

Imagen Nº 22. Interfaz de materiales registrados


Fuente: Elaboración propia.
i) INTERFAZ DE REGISTRO USUARIOS
Es el interfaz que muestra la ventana de registro de los usuarios que
manejan el programa.

65
Imagen Nº 23. Interfaz de registro de usuarios.
Fuente: Elaboración propia.
j) INTERFAZ CONSULTAR ENTREGAS
Es el interfaz en el que se encuentran los reportes que se desea consultar.

Imagen Nº 24. Interfaz consultar entregas.


Fuente: Elaboración propia.
4.3. PRUEBA, MEJORAS Y PUESTA EN MARCHA DEL SISTEMA
Una vez finalizado la construcción del sistema en esta fase se hizo las respectivas
pruebas que en conjunto con el jefe del área de Logística de la Gerencia Sub Regional
de Tayacaja, se hicieron las evaluaciones de todos los supuestos errores que se puede
tener.
Aquí algunas consideraciones de las pruebas realizadas:

66
Tabla 9. Detalle de pruebas realizadas del sistema.
PRUEBAS REALIZADAS RESULTADO
Conexión con la base de datos Correcto
Seguridad contra la vulnerabilidad del sistema Correcto
Gestión de usuarios Correcto
Registro de personal Correcto
Registro de materiales Correcto
Generar Entrega Correcto
Realizar Entrega Correcto
Ejecución de reportes Correcto
Fuente: Elaboración propia
Ya realizado las pruebas y levantado todo los errores se pasó a poner en marcha el
sistema, el cual viene funcionando con normalidad. Este sistema está instalado en
una computadora en el área de Logística de la Gerencia Sub Regional de Tayacaja.

67
CAPÍTULO V
EVALUACIÓN PRE Y POST PRÁCTICA PREPROFESIONAL
5.1 ASPECTO TÉCNICO-CIENTÍFICO
 EVALUACIÓN DE LA ORGANIZACIÓN

Tabla 10. Evaluación pre y post de la organización.

PRE 1. En la Unidad de Logística no se contaba con un sistema de inventarios.


2. El registro de entrega que se realizaba demoraba mucho tiempo (30 min),
se realizaba a mano y a veces traía complicaciones respecto al inventario.
3. Para el respectivo seguimiento de entregas que se realizaba era
complicado, demoraba 20 minutos, puesto que se tenía que consultar un
cuaderno donde se registran la lista de entregas diarias o de acuerdo se
necesite.
4. Para la consulta de stocks era complicado y demoraba de 10 minutos a
más.
5. Los recursos (hojas, folios, fólderes) que se utilizaban eran muchos
generando traspapelación y pérdida de información, además ocupaban
demasiado espacio.
POST 1. El área de Logística de la Gerencia Sub Regional de Tayacaja ya cuenta con
un sistema de inventarios.
2. La emisión de entregas se realiza de forma digital, esto guardando en una base
de datos de Mysql e imprimiendo de forma rápida, de tal manera que minimiza
el tiempo de escribir manualmente, se ha optimizado en 3 minutos.

68
3. El seguimiento de entrega de materiales se realiza en menor tiempo. Se ha
optimizado a 5 segundos, por lo cual se ha reducido en el tiempo de consultas.
4. La consulta de stock se realiza en menor tiempo de 5 segundos
5. Se lograron optimizar recursos, brindar seguridad a los registros y generar
espacio de manera eficiente.
Fuente: Elaboración propia

 TABLA DE OPTIMIZACIÓN DE TIEMPO


Para considerar las evaluaciones de la actividad N°3 de pre y post de la tabla 5.1,
se hizo la consolidación de datos de manera que se obtuvo muestras de la
observación directa.
Tabla 11. Convalidado de optimización de tiempo.

CASO TIEMPO EN TIEMPO EN


MINUTOS SIN EL MINUTOS CON
SISTEMA EL SISTEMA
Consultar los materiales 10 0.10
Emitir entrega 12 3
Consulta de stock 10 0.10
Consultar reportes 20 0.10
Registrar un nuevo material 3 0.20
Registrar personal 3 0.10
TOTAL 58 4.00
Fuente: Elaboración propia
En la tabla se muestra la optimización de tiempos en minutos sin el sistema y con el
sistema, el cual podemos apreciar que con el sistema se ahorra mucho tiempo y más
rápida es la atención al cliente.

5.2 ASPECTO TÉCNICO CIENTÍFICO (FORMACIÓN ACADÉMICA)


La utilización de estos sistemas de información son muy accesibles para el desarrollo
eficiente de la institución y el buen manejo de la información, esto nos permite:
 Mejorar el desempeño en el área de logística.
 Continuar con un servicio excelente.
 Mediante la base de datos es seguro evitar la pérdida de información
 Facilitar la operatividad del sistema.
 Optimizar el tiempo para verificar lo que se desee consultar al sistema.

69
5.3 FORMACIÓN LABORAL
Durante el tiempo de implementación del sistema realizado se adquirió habilidades y
destrezas que me ayudaron a desarrollar adecuadamente mis aptitudes como practicante,
demostrando profesionalismo, trabajo en equipo, puntualidad, responsabilidad entre
otros.
Es bueno entender que en el aspecto laboral es necesario conocer muchas cosas y así dar
soluciones a los inconvenientes de los procesos que puedan tener las diferentes áreas en
una organización.
5.4 ASPECTO PERSONAL
En lo personal para mi es una gran alegría y un triunfo haber realizado mis prácticas en
la gerencia sub regional, puesto que permitió desarrollar mis conocimientos, habilidades
obtenidas en la Escuela Profesional de Ingeniería de sistemas.
Estas prácticas pre profesionales hicieron también que pueda socializarme de manera
más fácil con profesionales que laboran en la organización.
5.5 LOGROS DESPUÉS DE LA IMPLEMENTACIÓN DEL SISTEMA
Durante el proceso de las prácticas pre-profesionales se obtuvo logros muy aceptables
después de la implementación del sistema, como:
 Reducción de horas de trabajo del personal del Área de Logística.
 Reducción de pérdidas de información.
 Reducción de uso de los espacios en la oficina.
 Reducción de fallas en la transferencia de la información.

70
CAPÍTULO VI
APORTES DE MEJORA EN PRO DE LA ENTIDAD
Durante el desarrollo del sistema se realizó diferentes aportes tales como. Aporte cultural,
optimización de tiempo, almacenamiento de datos y automatización de algunos procesos,
cada uno de estos aportes se detalla a continuación:
6.1 APORTE CULTURAL
Se ha contribuido en los usuarios y trabajador en el área de Logística cambiar su
perspectiva e introducirse en el sistema tecnológico que hoy en día va superando las
expectativas de todas las personas, es decir que al principio del desarrollo del sistema
había una resistencia al cambio, sin embargo, el funcionamiento y la demostración hizo
que la tecnología hace las cosas más rápidas y en muchos casos de manera segura, por
ello es que se pudo lograr que se apueste por la tecnología.
6.2 OPTIMIZACIÓN DE TIEMPO
Con la implementación del sistema ha sido posible optimizar el tiempo del trabajador
del área de Logística ya que realizan registro, búsqueda de entregas y consultas que se
ejecutan de manera acelerada.
Teniendo un sistema automatizado se redujo los siguientes:
 Reducción de tiempo en la emisión de entrega.
 Reducción de horas de trabajo del personal.
 Reducción de pérdidas de entregas.
 Reducción de uso de espacio.

71
6.3 ALMACENAMIENTO DE DATOS
Como se ha descrito anteriormente los archivos se tenían en materiales físicos y otros en
documentos Word no estructurados, el cual ocupan espacio y falta de organización en la
documentación todos estos son propensos a ser dañados o tal vez con una probabilidad
que desaparezcan o sean borrados por errores no contemplados que pueda ocasionar el
empleado lo cual causaría malestar en los usuarios. Por ello es que ahora se tiene
implementado una “Base de Datos” que con la validación del sistema ya tiene una
seguridad en el almacenamiento de datos.
6.4 AUTOMATIZACIÓN DE PROCESOS
Con el sistema actual implementado, algunos procesos del área de Almacén se realizan
de manera automatizada, ya que cuenta con el sistema en pleno funcionamiento, el cual
desde la ejecución del sistema facilita las labores con mayor eficiencia, eficacia y
disponibilidad de la información.

72
LIMITACIONES
Esta no era la excepción durante la implementación del sistema, se tuvo algunas limitaciones
en cuanto al desempeño de las labores que se debían hacer entre ellas cabe mencionar lo más
esencial, estas fueron los siguientes:
 En un principio se desconocía a los responsables del área, asimismo las funciones
que se cumplían.
 Para conocer bien el funcionamiento del área se tuvo que realizar los trabajos que
efectuaban correctamente, ello tardó un poco al desarrollo del sistema.

73
CONCLUSIONES
1. Se desarrolló e implementó de manera satisfactoria el Sistema de inventarios en su
versión 1.0, lo cual ahora es una herramienta indispensable de la empresa ya que se tuvo
una buena aceptación por parte del trabajador del área y por parte del gerente general del
municipio.
2. Se identificó y se analizó los requerimientos luego se logró diseñar una base de datos en
Mysql el cual nos sirvió para el desarrollo del sistema de acuerdo a los métodos y teorías
establecidos en el capítulo tres.
3. Se diseñó la interfaz de usuario interactivo y se programó el código fuente en el lenguaje
de programación Java Neetbeans de acuerdo a los requerimientos encontrados y
siguiendo la representación de los casos de uso construidos.
4. Se realizaron las pruebas y mejoras correspondientes poniendo en marcha el sistema que
al final se implementó en la Gerencia Sub Regional de Tayacaja, que desde entonces
viene funcionando con normalidad.

74
SUGERENCIAS
1. Capacitar a los personales sobre el uso correcto del sistema para así tener más
conocimiento del manejo del sistema y no manipularlo de manera inadecuada.
2. Identificar los requerimientos de las otras áreas de la organización para la construcción
de un sistema de que facilite a todos los administrativos realizar sus trabajos laborales
con eficiencia y eficacia.
3. Se sugiere que los requerimientos de las otras áreas de trabajo sean plasmados en
diagramas de casos de uso para que sea más fácil de entender y diseñar las interfaces del
sistema. en un lenguaje de programación más adecuada
4. Se sugiere un constante mantenimiento a la base de datos, actualizando con nuevos datos
en las tablas existentes e incluso en nuevas tablas.

75
BIBLIOGRAFÍA
REFERENCIAS BIBLIOGRÁFICAS
1. ARLOW J., NEUSTAD I. “ProgramaciónUML2. (2006).
2. ELMASRI R., NAVATHE S. “Sistemas de Bases de Datos. Conceptos
Fundamentales”. Segunda Edición. México. Editorial Pearson Educación. (2000).
3. GONZALES APAZA, Renan D, HUAMANI ORDOÑEZ, Kevin. Sistema de
inventarios. Tesis, Moquegua: Universidad Nacional de Moquegua, Facultad de
Ingeniería. (2010).
4. JACOBSON, I., BOOCH, G. Y RUMBAUGH, J. “El Proceso Unificado de Desarrollo
de Software”. (1999).
5. Miguel Ángel Álvarez, “La programación orientada a objetos. (1990).
6. MOF Municipalidad Distrital de Chongos Bajo-organigrama estructural.
7. Reglamento de Prácticas Pre-Profesionales. Escuela Académico Profesional de
Ingeniería de Sistemas de la Universidad Nacional de Huancavelica. (2011).
8. ROGER S.PRESSMAN. Ingeniería del Software. Un enfoque práctico. Editorial
MCGraw-Hill. (2010).
9. SENN, J.“ANÁLISIS y Diseño de Sistemas de Información”, Segunda Edición.
Editorial Mc. Graw-Hill. México. (1992).
10. Sommerville, I. “Ingeniería del Software”. (1982).

76
REFERENCIAS DE PÁGINAS WEB

1. http://repositorio.puce.edu.ec/handle/22000/3766?show=full
2. https://es.wikipedia.org/wiki/Sistema_de_informaci%C3%B3n
3. http://www.gcsinformatic.com.pe
4. http://izamorar.com/actividades-basicas-de-un-sistema-de-informacion/
5. https://prezi.com/mvoi1pmlanwc/sistema-de-tramite-documentario/
6. http://www.larevistainformatica.com/lenguaje-programacion-viasual-basic.htm
7. https://prezi.com/.../analisis-del-requerimiento-de-un-sistema-de-tramite-documen/
8. www.reniec.gob.pe/portal/pdf/03_sitd.pdf
9. http://ri.ufg.edu.sv/jspui/bitstream/11592/7828/9/005.12-Ch512d-B.pdf
10. http://es.slideshare.net/alexysbike/introduccin-a-la-base-de-datos-14069671
11. http://tesis.pucp.edu.pe/repositorio/handle/123456789/552
12. https://www.dspace.espol.edu.ec/bitstream/123456789/1602/1/3144.pdf
13. http://repositorio.uis.edu.co/jspui/bitstream/123456789/4717/2/119452.pdf
14. http://www.ra-ma.es/libros/SISTEMAS-INFORMATICOS-CFGS/32651/978-84-
9964-099-0
15. http://es.wikipedia.org/wiki/Visual_Basic
16. https://es.wikipedia.org/wiki/XAMPP
17. https://es.wikipedia.org/wiki/MySQL
18. http://repositorio.puce.edu.ec/bitstream/handle/22000/3766/T-PUCE
3813.pdf?sequence=1&isAllowed=yhttp://www.itba.edu.ar/archivos/secciones/gomez
_tesisprocesosventas.pdf
19. http://tfig.itcilo.org/SP/contents/invoicing-process.htm
20. https://es.wikipedia.org/wiki/Requisito_(sistemas)
21. http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational
22. http://repositorio.utm.edu.ec/bitstream/123456789/33/1/TESIS%20SISTEMA%20INF
ORMATICO%20DE%20LA%20ESCUELA%2021%20DE%20MAYO.pdf
23. MACROMEDIA. Utilización de Dreamweaver 8, Aspectos Básicos de las Aplicaciones
Web. 2005. [Disponible en URL.

77
ANEXOS

78
ANEXO 1. Fotografías que evidencian las prácticas realizadas.
ANEXO 2. Código fuente del Sistema de Inventario.
ANEXO 3. Original de la Constancia de Área Académica que acredita que el
alumno se encuentra superior al VII ciclo y no tiene cursos pendientes
de ciclo anterior.
ANEXO 4. Carta de Presentación dirigida a la institución (cargo).
ANEXO 5. Carta de Aceptación original de la institución receptora.
ANEXO 6. Memorando de designación del docente asesor.
ANEXO 7 Copia del recibo de pago del Reglamento de Prácticas Pre-
Profesionales.
ANEXO 8. Certificado de cumplimiento de las Practicas Pre-Profesionales.
ANEXO 9. Ficha de evaluación de las Practicas Pre-Profesionales.

79
ANEXO 1. FOTOGRAFÍAS QUE EVIDENCIAN LAS PRÁCTICAS
REALIZADAS

Imagen Nº 25. Traspapelación en la documentación de inventario (pre


implementación)
Fuente: Fotografía propia.

80
Imagen Nº 26. Falta de espacio a causa de los excesivos folios de
registros (pre implementación)
Fuente: Fotografía propia.

81
Imagen Nº 27. Registrando en el inventario (pre implementación)
Fuente: Fotografía propia.

82
Imagen Nº 28. Desarrollando el Sistema de Inventario
Fuente: Fotografía propia.

83
Imagen Nº 29. Software implementado en el área de logística.
Fuente: Fotografía propia.

Imagen Nº 30. Explicando al jefe de logística el funcionamiento del


sistema e instalando la base de datos al servidor.
Fuente: Fotografía propia.

84
Imagen Nº 31. Último día de prácticas, entrega de la ficha de evaluación.
Fuente: Fotografía propia.

85
ANEXO 2. CÓDIGO FUENTE DEL SISTEMA DE INVENTARIO.

 CÓDIGO FUENTE DE LA PANTALLA PRINCIPAL

package InterfazAdmin;

import Actualizar.articulos;

import Actualizar.usuarios;

import Articulos.IngresoArticulos;

import Cambio.CambioEquipo;

import Joption.Joption;
import Joption.Joptionx;

import Reloj.Reloj;
import Reportes.Equipo;

import Reportes.Reporte;
import Usuarios.Registro;

import java.text.SimpleDateFormat;
import java.util.Date;
import javax.swing.ImageIcon;

import javax.swing.JLabel;

import javax.swing.JLayeredPane;

86
import javax.swing.JOptionPane;

import javax.swing.JPanel;

import sesion.Login;

/**
*

* @author willianPC
*/

public class InterfazAdmin extends javax.swing.JFrame {

Joption icon = new Joption();

Joptionx save = new Joptionx();

* Creates new form InterfazAdmin

*/

public InterfazAdmin() {

initComponents();

Reloj hilo=new Reloj (cajahora);

hilo.start();

pane1.setVisible(false);
cajafecha.setText(fechaActual());

bloqueo();

setTitle("SISTEMA DE CONTROL DE INVENTARIOS GSRT");

setResizable(false);
setExtendedState(MAXIMIZED_BOTH);
setLocationRelativeTo(null);

setIconImage(new ImageIcon(getClass().getResource("SCIEC.png")).getImage());

((JPanel)getContentPane()).setOpaque(false);

ImageIcon uno = new ImageIcon(this.getClass().getResource("wall.jpg"));


JLabel fondo = new JLabel();
fondo.setIcon(uno);

getLayeredPane().add(fondo,JLayeredPane.FRAME_CONTENT_LAYER);
fondo.setBounds(0, 0, uno.getIconWidth(), uno.getIconHeight());
}

void bloqueo(){

btnequipo.setEnabled(false);

87
btnusuario.setEnabled(false);

btnconsulta1.setEnabled(false);

btnadmin.setEnabled(false);

btnarti.setEnabled(false);
btncerrar.setEnabled(false);

btnreporte.setEnabled(false);
}

public static String fechaActual(){


Date fecha=new Date();

SimpleDateFormat formatoFecha=new SimpleDateFormat("dd/MM/YYYY");

return formatoFecha.format(fecha);

* This method is called from within the constructor to initialize the form.

* WARNING: Do NOT modify this code. The content of this method is always

* regenerated by the Form Editor.

*/

@SuppressWarnings("unchecked")

// <editor-fold defaultstate="collapsed" desc="Generated Code">

private void initComponents() {

jDesktopPane1 = new javax.swing.JDesktopPane();

btnequipo = new javax.swing.JButton();

btnusuario = new javax.swing.JButton();


btnconsulta1 = new javax.swing.JButton();
btnadmin = new javax.swing.JButton();

btnarti = new javax.swing.JButton();

btnreporte = new javax.swing.JButton();

btncerrar = new javax.swing.JButton();


usuario = new javax.swing.JLabel();
jLabel4 = new javax.swing.JLabel();

jLabel3 = new javax.swing.JLabel();


cajahora = new javax.swing.JLabel();
jLabel6 = new javax.swing.JLabel();

cajafecha = new javax.swing.JLabel();

jLabel5 = new javax.swing.JLabel();

88
pane1 = new javax.swing.JDesktopPane();

jButton2 = new javax.swing.JButton();

jButton3 = new javax.swing.JButton();

jButton4 = new javax.swing.JButton();


jButton5 = new javax.swing.JButton();

jMenuBar1 = new javax.swing.JMenuBar();


jMenu1 = new javax.swing.JMenu();

jMenu3 = new javax.swing.JMenu();


jMenu2 = new javax.swing.JMenu();

jMenu5 = new javax.swing.JMenu();

jMenu6 = new javax.swing.JMenu();

setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);

btnequipo.setBackground(new java.awt.Color(0, 0, 0));

btnequipo.setFont(new java.awt.Font("Gulim", 1, 12)); // NOI18N

btnequipo.setForeground(new java.awt.Color(255, 255, 255));

btnequipo.setIcon(new javax.swing.ImageIcon(getClass().getResource("/InterfazAdmin/icon

monitor pc.png"))); // NOI18N

btnequipo.setText("Nuevo Equipo");
btnequipo.setBorderPainted(false);

btnequipo.setFocusPainted(false);

btnequipo.addActionListener(new java.awt.event.ActionListener() {

public void actionPerformed(java.awt.event.ActionEvent evt) {


btnequipoActionPerformed(evt);
} btnusuario.setBackground(new java.awt.Color(0, 0, 0));

btnusuario.setFont(new java.awt.Font("Gulim", 1, 12)); // NOI18N

btnusuario.setForeground(new java.awt.Color(255, 255, 255));

btnusuario.setIcon(new
javax.swing.ImageIcon(getClass().getResource("/InterfazAdmin/USER.png"))); // NOI18N
btnusuario.setText("Nuevo Usuario");

btnusuario.setBorderPainted(false);
btnusuario.setFocusPainted(false);
btnusuario.addActionListener(new java.awt.event.ActionListener() {

public void actionPerformed(java.awt.event.ActionEvent evt) {

btnusuarioActionPerformed(evt);

89
}

});

btnconsulta1.setBackground(new java.awt.Color(0, 0, 0));

btnconsulta1.setFont(new java.awt.Font("Gulim", 1, 12)); // NOI18N


btnconsulta1.setForeground(new java.awt.Color(255, 255, 255));

btnconsulta1.setIcon(new
javax.swing.ImageIcon(getClass().getResource("/InterfazAdmin/icon_os.png"))); // NOI18N

btnconsulta1.setText("Equipos");
btnconsulta1.setBorderPainted(false);

btnconsulta1.setCursor(new java.awt.Cursor(java.awt.Cursor.HAND_CURSOR));

btnconsulta1.setFocusPainted(false);

btnconsulta1.addActionListener(new java.awt.event.ActionListener() {

public void actionPerformed(java.awt.event.ActionEvent evt) {

btnconsulta1ActionPerformed(evt);

});

btnadmin.setBackground(new java.awt.Color(0, 0, 0));

btnadmin.setFont(new java.awt.Font("Gulim", 1, 12)); // NOI18N

btnadmin.setForeground(new java.awt.Color(255, 255, 255));


btnadmin.setIcon(new

javax.swing.ImageIcon(getClass().getResource("/InterfazAdmin/modificar.png"))); // NOI18N

btnadmin.setText("Usuarios");

btnadmin.setBorderPainted(false);
btnadmin.setFocusPainted(false);
btnadmin.addActionListener(new java.awt.event.ActionListener() {

public void actionPerformed(java.awt.event.ActionEvent evt) {

btnadminActionPerformed(evt);

}
});
btnarti.setBackground(new java.awt.Color(0, 0, 0));

btnarti.setFont(new java.awt.Font("Gulim", 1, 12)); // NOI18N


btnarti.setForeground(new java.awt.Color(255, 255, 255));
btnarti.setIcon(new

javax.swing.ImageIcon(getClass().getResource("/InterfazAdmin/modificar.png"))); // NOI18N

btnarti.setText("Articulos");

90
btnarti.setBorderPainted(false);

btnarti.setCursor(new java.awt.Cursor(java.awt.Cursor.HAND_CURSOR));

btnarti.setFocusPainted(false);

btnarti.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt) {

btnartiActionPerformed(evt);
}

});
btnreporte.setBackground(new java.awt.Color(0, 0, 0));

btnreporte.setFont(new java.awt.Font("Gulim", 1, 12)); // NOI18N

btnreporte.setForeground(new java.awt.Color(255, 255, 255));

btnreporte.setIcon(new

javax.swing.ImageIcon(getClass().getResource("/InterfazAdmin/pdf.png"))); // NOI18N

btnreporte.setText("Tipo de Reporte");

btnreporte.setBorderPainted(false);

btnreporte.setCursor(new java.awt.Cursor(java.awt.Cursor.HAND_CURSOR));

btnreporte.setFocusPainted(false);

btnreporte.addActionListener(new java.awt.event.ActionListener() {

public void actionPerformed(java.awt.event.ActionEvent evt) {


btnreporteActionPerformed(evt);

});

btncerrar.setBackground(new java.awt.Color(0, 0, 0));


btncerrar.setFont(new java.awt.Font("Gulim", 1, 12)); // NOI18N
btncerrar.setForeground(new java.awt.Color(255, 255, 255));

btncerrar.setIcon(new

javax.swing.ImageIcon(getClass().getResource("/InterfazAdmin/salir_1.png"))); // NOI18N

btncerrar.setText("Salir Sistema");
btncerrar.setBorderPainted(false);
btncerrar.setCursor(new java.awt.Cursor(java.awt.Cursor.HAND_CURSOR));

btncerrar.setFocusPainted(false);
btncerrar.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt) {

btncerrarActionPerformed(evt);

91
javax.swing.GroupLayout jDesktopPane1Layout = new

javax.swing.GroupLayout(jDesktopPane1);

jDesktopPane1.setLayout(jDesktopPane1Layout);

jDesktopPane1Layout.setHorizontalGroup(
jDesktopPane1Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)

.addGroup(jDesktopPane1Layout.createSequentialGroup()
.addContainerGap()

.addGroup(jDesktopPane1Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADI

NG)

.addComponent(btnequipo, javax.swing.GroupLayout.DEFAULT_SIZE,

javax.swing.GroupLayout.DEFAULT_SIZE, Short.MAX_VALUE)

.addComponent(btnusuario, javax.swing.GroupLayout.DEFAULT_SIZE,

javax.swing.GroupLayout.DEFAULT_SIZE, Short.MAX_VALUE)

.addComponent(btnconsulta1, javax.swing.GroupLayout.DEFAULT_SIZE,

javax.swing.GroupLayout.DEFAULT_SIZE, Short.MAX_VALUE)

.addComponent(btnadmin, javax.swing.GroupLayout.DEFAULT_SIZE,

javax.swing.GroupLayout.DEFAULT_SIZE, Short.MAX_VALUE)

.addComponent(btnarti, javax.swing.GroupLayout.Alignment.TRAILING,
javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE,

Short.MAX_VALUE)

.addComponent(btnreporte, javax.swing.GroupLayout.Alignment.TRAILING,

javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE,
Short.MAX_VALUE)
.addComponent(btncerrar, javax.swing.GroupLayout.Alignment.TRAILING,

javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE,

Short.MAX_VALUE))

.addContainerGap())
);
jDesktopPane1Layout.setVerticalGroup(

jDesktopPane1Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
.addGroup(jDesktopPane1Layout.createSequentialGroup()
.addContainerGap()

92
.addComponent(btnequipo, javax.swing.GroupLayout.PREFERRED_SIZE, 42,

javax.swing.GroupLayout.PREFERRED_SIZE)

.addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED)

.addComponent(btnusuario, javax.swing.GroupLayout.PREFERRED_SIZE, 42,


javax.swing.GroupLayout.PREFERRED_SIZE)

.addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED)
.addComponent(btnconsulta1, javax.swing.GroupLayout.PREFERRED_SIZE, 42,

javax.swing.GroupLayout.PREFERRED_SIZE)
.addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED)

.addComponent(btnadmin, javax.swing.GroupLayout.PREFERRED_SIZE, 42,

javax.swing.GroupLayout.PREFERRED_SIZE)

.addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED)

.addComponent(btnarti, javax.swing.GroupLayout.PREFERRED_SIZE, 42,

javax.swing.GroupLayout.PREFERRED_SIZE)

.addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED)

.addComponent(btnreporte, javax.swing.GroupLayout.PREFERRED_SIZE, 42,

javax.swing.GroupLayout.PREFERRED_SIZE)

.addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED,

javax.swing.GroupLayout.DEFAULT_SIZE, Short.MAX_VALUE)
.addComponent(btncerrar, javax.swing.GroupLayout.PREFERRED_SIZE, 42,

javax.swing.GroupLayout.PREFERRED_SIZE)

.addContainerGap()) );

jDesktopPane1.setLayer(btnequipo, javax.swing.JLayeredPane.DEFAULT_LAYER);
jDesktopPane1.setLayer(btnusuario, javax.swing.JLayeredPane.DEFAULT_LAYER);
jDesktopPane1.setLayer(btnconsulta1, javax.swing.JLayeredPane.DEFAULT_LAYER);

jDesktopPane1.setLayer(btnadmin, javax.swing.JLayeredPane.DEFAULT_LAYER);

jDesktopPane1.setLayer(btnarti, javax.swing.JLayeredPane.DEFAULT_LAYER);

jDesktopPane1.setLayer(btnreporte, javax.swing.JLayeredPane.DEFAULT_LAYER);
jDesktopPane1.setLayer(btncerrar, javax.swing.JLayeredPane.DEFAULT_LAYER);

usuario.setFont(new java.awt.Font("Segoe Script", 1, 36)); // NOI18N


usuario.setForeground(new java.awt.Color(255, 255, 255));
usuario.setText("NOMBRE");

usuario.setCursor(new java.awt.Cursor(java.awt.Cursor.HAND_CURSOR));

93
jLabel4.setFont(new java.awt.Font("DFKai-SB", 1, 24)); // NOI18N

jLabel4.setForeground(new java.awt.Color(255, 255, 0));

jLabel4.setText("USUARIO : ");

jLabel4.setCursor(new java.awt.Cursor(java.awt.Cursor.HAND_CURSOR));

jLabel3.setIcon(new
javax.swing.ImageIcon(getClass().getResource("/InterfazAdmin/1449700766_Admin.png"))); //

NOI18N
cajahora.setFont(new java.awt.Font("Sitka Text", 1, 48)); // NOI18N

cajahora.setForeground(new java.awt.Color(0, 51, 255));

cajahora.setText("hh:mm:seg");

cajahora.setCursor(new java.awt.Cursor(java.awt.Cursor.WAIT_CURSOR));

jLabel6.setIcon(new

javax.swing.ImageIcon(getClass().getResource("/InterfazAdmin/1449700949_Clock4.png"))); //

NOI18N

cajafecha.setFont(new java.awt.Font("Arial Black", 1, 24)); // NOI18N

cajafecha.setForeground(new java.awt.Color(255, 255, 255));


cajafecha.setText("DD/MM/YYYY");

jLabel5.setIcon(new

javax.swing.ImageIcon(getClass().getResource("/InterfazAdmin/1449700965_calendar-alt.png")));
// NOI18N
jButton2.setBackground(new java.awt.Color(0, 0, 0));

jButton2.setFont(new java.awt.Font("Gulim", 1, 12)); // NOI18N

jButton2.setForeground(new java.awt.Color(255, 255, 255));

jButton2.setIcon(new
javax.swing.ImageIcon(getClass().getResource("/InterfazAdmin/pdf.png"))); // NOI18N
jButton2.setText("Todos los Equipos");

jButton2.setCursor(new java.awt.Cursor(java.awt.Cursor.HAND_CURSOR));
jButton2.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt) {

jButton2ActionPerformed(evt); }

});

94
jButton3.setBackground(new java.awt.Color(0, 0, 0));

jButton3.setFont(new java.awt.Font("Gulim", 1, 12)); // NOI18N

jButton3.setForeground(new java.awt.Color(255, 255, 255));


jButton3.setIcon(new

javax.swing.ImageIcon(getClass().getResource("/InterfazAdmin/pdf.png"))); // NOI18N
jButton3.setText("Especificaciones de Equipos");

jButton3.setCursor(new java.awt.Cursor(java.awt.Cursor.HAND_CURSOR));
jButton3.addActionListener(new java.awt.event.ActionListener() {

public void actionPerformed(java.awt.event.ActionEvent evt) {

jButton3ActionPerformed(evt);

});

jButton4.setBackground(new java.awt.Color(0, 0, 0));

jButton4.setFont(new java.awt.Font("Gulim", 1, 12)); // NOI18N

jButton4.setForeground(new java.awt.Color(255, 255, 255));

jButton4.setIcon(new

javax.swing.ImageIcon(getClass().getResource("/InterfazAdmin/cancelar.png"))); // NOI18N
jButton4.setText("Cancelar");

jButton4.setCursor(new java.awt.Cursor(java.awt.Cursor.HAND_CURSOR));

jButton4.addActionListener(new java.awt.event.ActionListener() {

public void actionPerformed(java.awt.event.ActionEvent evt) {


jButton4ActionPerformed(evt);
} });

jButton5.setBackground(new java.awt.Color(0, 0, 0));

jButton5.setFont(new java.awt.Font("Gulim", 1, 12)); // NOI18N


jButton5.setForeground(new java.awt.Color(255, 255, 255));
jButton5.setIcon(new

javax.swing.ImageIcon(getClass().getResource("/InterfazAdmin/pdf.png"))); // NOI18N
jButton5.setText("Un Solo Equipo");
jButton5.setCursor(new java.awt.Cursor(java.awt.Cursor.HAND_CURSOR));

jButton5.addActionListener(new java.awt.event.ActionListener() {

public void actionPerformed(java.awt.event.ActionEvent evt) {

95
jButton5ActionPerformed(evt);

});

javax.swing.GroupLayout pane1Layout = new javax.swing.GroupLayout(pane1);


pane1.setLayout(pane1Layout);

pane1Layout.setHorizontalGroup(
pane1Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)

.addGroup(pane1Layout.createSequentialGroup()
.addContainerGap()

.addGroup(pane1Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)

.addGroup(pane1Layout.createSequentialGroup()

.addGroup(pane1Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING, false)

.addComponent(jButton3, javax.swing.GroupLayout.DEFAULT_SIZE,

javax.swing.GroupLayout.DEFAULT_SIZE, Short.MAX_VALUE)

.addComponent(jButton2, javax.swing.GroupLayout.DEFAULT_SIZE,

javax.swing.GroupLayout.DEFAULT_SIZE, Short.MAX_VALUE)

.addComponent(jButton4, javax.swing.GroupLayout.DEFAULT_SIZE,
javax.swing.GroupLayout.DEFAULT_SIZE, Short.MAX_VALUE))

.addGap(0, 0, Short.MAX_VALUE))

.addComponent(jButton5, javax.swing.GroupLayout.DEFAULT_SIZE,

javax.swing.GroupLayout.DEFAULT_SIZE, Short.MAX_VALUE))
.addContainerGap())
);

pane1Layout.setVerticalGroup(

pane1Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)

.addGroup(pane1Layout.createSequentialGroup()
.addGap(19, 19, 19)
.addComponent(jButton2, javax.swing.GroupLayout.PREFERRED_SIZE, 42,

javax.swing.GroupLayout.PREFERRED_SIZE)
.addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED)
.addComponent(jButton3, javax.swing.GroupLayout.PREFERRED_SIZE, 42,

javax.swing.GroupLayout.PREFERRED_SIZE)

.addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED)

96
.addComponent(jButton5, javax.swing.GroupLayout.PREFERRED_SIZE, 42,

javax.swing.GroupLayout.PREFERRED_SIZE)

.addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED)

.addComponent(jButton4, javax.swing.GroupLayout.PREFERRED_SIZE, 42,


javax.swing.GroupLayout.PREFERRED_SIZE)

.addContainerGap(12, Short.MAX_VALUE))
);

pane1.setLayer(jButton2, javax.swing.JLayeredPane.DEFAULT_LAYER);
pane1.setLayer(jButton3, javax.swing.JLayeredPane.DEFAULT_LAYER);

pane1.setLayer(jButton4, javax.swing.JLayeredPane.DEFAULT_LAYER);

pane1.setLayer(jButton5, javax.swing.JLayeredPane.DEFAULT_LAYER);

jMenu1.setBackground(new java.awt.Color(255, 255, 255));

jMenu1.setBorder(new

javax.swing.border.SoftBevelBorder(javax.swing.border.BevelBorder.RAISED));

jMenu1.setForeground(new java.awt.Color(0, 51, 255));

jMenu1.setIcon(new

javax.swing.ImageIcon(getClass().getResource("/InterfazAdmin/modificar.png"))); // NOI18N

jMenu1.setText("Registro ");
jMenu1.setCursor(new java.awt.Cursor(java.awt.Cursor.HAND_CURSOR));

jMenu1.setFont(new java.awt.Font("Gulim", 1, 14)); // NOI18N

jMenu1.addMouseListener(new java.awt.event.MouseAdapter() {

public void mouseClicked(java.awt.event.MouseEvent evt) {


jMenu1MouseClicked(evt);
}

});

jMenu1.addActionListener(new java.awt.event.ActionListener() {

public void actionPerformed(java.awt.event.ActionEvent evt) {


jMenu1ActionPerformed(evt);
}

});
jMenuBar1.add(jMenu1);

97
98
99
100
101
102
103
104
105

También podría gustarte