Documento Trabajo Degr A Do

IMPLEMENTACIÓN DE UN SISTEMA DE INVENTARIOS PARA EL ÁREA DE
SOPORTE TÉCNICO EN LA EMPRESA COMERCIALIZADORA ARTURO

CALLE S.A.S.
DAVID GUILLERMO LATORRE PELAEZ
UNIVERSIDAD CATÓLICA DE COLOMBIA

FACULTAD DE INGENIERÍA
PROGRAMA DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
BOGOTÁ D.C.
2017
IMPLEMENTACIÓN DE UN SISTEMA DE INVENTARIOS PARA EL ÁREA DE
SOPORTE TÉCNICO EN LA EMPRESA COMERCIALIZADORA ARTURO CALLE
S.A.S.
DAVID GUILLERMO LATORRE PELAEZ
Trabajo de grado para optar al título

de Ingeniero de Sistemas
Director
RAÚL ERNESTO MENÉNDEZ MORA, PhD
UNIVERSIDAD CATÓLICA DE COLOMBIA

FACULTAD DE INGENIERÍA
PROGRAMA DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
BOGOTÁ D.C.
2017
3
AGRADECIMIENTOS
Agradezco a Dios y la Virgen María

por las bendiciones recibidas. A mis
padres, hermanos y tía por el apoyo
moral para culminar mis estudios
como Ingeniero de sistemas en la
Universidad Católica de Colombia.
4
NOTA DE ACEPTACIÓN
Aprobado por el comité de grado en

Cumplimiento de los requisitos exigidos por la
Facultad de Ingeniería y la Universidad Católica
de Colombia para optar al título de ingenieros de
Sistemas.
Director de Trabajo de Grado

Ing. Raúl Ernesto Menéndez Mora
Asesor Metodológico
Ing. Raúl Ernesto Menéndez Mora
Jurado
Bogotá D.C., Mayo de 2017
5
CONTENIDO
Pág.
INTRODUCCIÓN 15
1. GENERALIDADES 18
1.1. ANTECEDENTES 18
1.2. PLANTEAMIENTO DEL PROBLEMA 19
1.2.1. Descripción del problema 19
1.2.2. Formulación del problema 19
1.3. OBJETIVOS 20
1.3.1. Objetivo general 20
1.3.2. Objetivos Específicos 20
1.4. JUSTIFICACIÓN 21
1.5. DELIMITACIÓN 22
1.6.1. Espacio 22
1.6.2. Tiempo 22
1.6.3. Contenido 22
1.6.4. Alcance 22
1.7. MARCO REFERENCIAL (TEÓRICO Y CONCEPTUAL) 23
1.7.1. Marco Teórico 23
1.7.2. Marco Conceptual 24
1.7.2.1. Sistema de Información 24
1.7.2.2. Inventario 25
1.7.2.3. Extreme Programming 25
1.7.2.4. JavaServer Faces (JSF) 26
1.7.2.5. Prime Faces 26
1.8. METODOLOGÍA 26
1.8.1. Tipo de Estudio 26
1.8.2. Fuentes de Información 27
1.9. DISEÑO METODOLÓGICO 28
6
2. DISEÑO Y DESARROLLO DEL SISTEMA DE INVENTARIO 29
2.1. EXPLORACIÓN 29
2.1.1. Historias de usuario 29
2.1.2. Requerimientos funcionales del sistema 32
2.1.3. Requerimientos no funcionales del sistema 33
2.2. PLANIFICACIÓN 34
2.2.1. Plan de entregas 35
2.2.2. Plan de pruebas 37
2.3. ITERACIONES 39
2.3.1. Iteración 1 39
2.4. PUESTA EN PRODUCCIÓN 68
3. CONCLUSIONES 72
4. RECOMENDACIONES 73
BIBLIOGRAFÍA 74
ANEXOS 77
7
LISTA DE TABLAS
Pág.
Tabla 1 - Roles XP y Funciones 27

Tabla 2 - Formato Historia de Usuario 30
Tabla 3 - Historias de usuario 31
Tabla 4 - Requerimientos Funcionales del Sistema 32
Tabla 5 - Requerimientos no funcionales del sistema 33
Tabla 6 - Plan de entregas 35
Tabla 7 - Plan de pruebas 37
Tabla 8 - Nivel de satisfacción del aplicativo web 68
Tabla 9 - Tiempo promedio de solución a incidencias. 69
Tabla 10 - Historia de Usuario 1 77
Tabla 26 - Formato de especificación requerimiento R1 93
8
9
LISTA DE FIGURAS
Pág.
Figura 1- Comparación Ciclos de Desarrollo 25

Figura 2 - Estructura Modelo Vista Controlador 34
Figura 3 - Fragmento de la clase UbicacionTecnicaService.java 39
Figura 4 - Fragmento de la clase UbicacionTecnicaDAO.java 40
Figura 5 - Fragmento de la clase UbicacionTecnicaDTO.java 41
Figura 6 - Fragmento del archivo dirUbicTec.xhtml 42
Figura 7 - Fragmento de la clase DatosLugarService.java 43
Figura 8 - Fragmento de la clase DatosLugarDAO.java 44
Figura 9 - Fragmento de la clase DatosLugarDTO.java 45
Figura 10 - Fragmento de la clase CentroDeCostoService.java 46
Figura 11 - Fragmento de la clase CentroDeCostoDAO.java 47
Figura 12 - Fragmento de la clase CentroDeCostoDTO.java 48
Figura 13 - Fragmento de la clase OficinaService.java 49
Figura 14 - Fragmento de la clase OficinaDAO.java 50
Figura 15 - Fragmento de la clase OficinaDTO.java 51
Figura 16 - Fragmento de la clase DatosDispositivoService.java 52
Figura 17 - Fragmento de la clase DatosDispositivoDAO.java 53
Figura 18 - Fragmento de la clase DatosDispositivoDTO.java 54
Figura 19 - Fragmento de la clase EquipoService.java 55
Figura 20 - Fragmento de la clase EquipoDAO.java 56
Figura 21 - Fragmento de la clase EquipoDTO.java 57
Figura 22 - Fragmento de la clase EquipoBajaService.java 58
Figura 23 - Fragmento de la clase EquipoBajaDAO.java 59
Figura 24 - Fragmento de la clase EquipoBajaDTO.java 60
Figura 25 - Fragmento del archivo invBajas.xhtml 61
Figura 26 - Fragmento del archivo dirCCosto.xhtml 62
Figura 27 - Fragmento del archivo DirOficinas.xhtml 63
Figura 28 - Fragmento del archivo invTorreEmpresarial.xhtml 64
Figura 29 - Fragmento del archivo invOficinas.xhtml 65
Figura 30 - Fragmento del archivo invCentroCosto.xhtml 66
Figura 31 - Fragmento del archivo invHistorial.xhtml 67
Figura 32 - Promedio Tiempo Incidencias Básicas 70
Figura 33 - Promedio Tiempo Incidencias Dificultad Intermedia 71
Figura 34 - Promedio Tiempo Incidencias Dificultad Alta 71
Figura 35 - Mockup página de inicio 109
Figura 36 - Mockup directorio ubicaciones tecnicas 109
Figura 37 - Mockup directorio centros de costo 110
10
Figura 38 - Mockup directorio oficinas 110
Figura 39 - Mockup inventario centros de costo 111
Figura 40 - Mockup inventario oficinas 111
Figura 41 - Mockup inventario torre empresarial 112
Figura 42 - Mockup inventario bajas 112
Figura 43 - Mockup inventario historial 113
Figura 44 - Diagrama relacional del sistema de inventario 114
Figura 45 - Fragmento Diagrama de clases 115
Figura 46 – Diagrama de clases sistema de inventario 116
11
LISTA DE ANEXOS
Pág.
Anexo A - Detalles historias de usuario 77
Anexo B - Especificación de requerimientos funcionales 93
Anexo C - Mockups del proyecto 109
Anexo D - Diagrama relacional 114
Anexo E - Diagrama de clases 115
Anexo F - Manual de ejecución 117
Anexo G - Manual de usuario del aplicativo 121
12
GLOSARIO
BASE DE DATOS: Herramienta para recopilar y organizar información. Las bases

de datos pueden almacenar información sobre personas, productos, pedidos u
otras cosas.1
EXTREME PROGRAMMING: Es un enfoque de la ingeniería de software

formulado por Kent Beck, autor del primer libro sobre la materia, Extreme
Programming Explained: Embrace Change (1999). Es el más destacado de los
procesos ágiles de desarrollo de software.2
GLASSFISH: Servidor compatible con la plataforma Java EE 5 para el desarrollo y

la implementación de las aplicaciones de Java EE y los servicios web basados en
la tecnología Java en entornos de producción a gran escala.3
JAVA: Es un lenguaje de programación y una plataforma informática

comercializada por primera vez en 1995 por Sun Microsystems. Java es rápido,
seguro y fiable. 4
MOCKUP: Fotomontajes que permiten a los diseñadores gráficos y web mostrar al

cliente cómo quedaran sus diseños.5
MYSQL: Motor de base de datos de código abierto. Es multi-hilo y multi-usuario. 6
NETBEANS IDE: Entorno de desarrollo integrado (IDE), modular, de base

estándar (normalizado), escrito en el lenguaje de programación Java. El proyecto
NetBeans consiste en un IDE de código abierto y una plataforma de aplicación,
las cuales
1
OFFICE. Conceptos básicos sobre bases de datos, ¿Qué es una base de datos?, 2007,Disponible en:
https://support.office.com/es-es/article/Conceptos-b%C3%A1sicos-sobre-bases-de-datos-a849ac16-07c7-
4a31-9948-3c8c94a7c204/
2
FLORES, Ervin. Ingeniería de Software: Programación Extrema XP, 1 junio, 2014, Disponible en:
http://ingenieriadesoftware.mex.tl/52753_xp---extreme-programing.html/
3
ORACLE, Corporation. Capítulo 2 Acerca de Sun GlassFish Enterprise Server, 2010, Disponible en:
https://docs.oracle.com/cd/E19879-01/821-1040/relnotessgesintro/index.html/
4
ORACLE, Corporation. ¿Qué es la tecnología Java y para qué la necesito?, Disponible en:
https://www.java.com/es/download/faq/whatis_java.xml/
5
BRAVO, Cludia. Mock Ups: ¿Para Qué Sirve?, 03 marzo, 2017, Disponible en: http://estudioka.es/que-es-
un- mock-up/
6
MYSQL. MySQL 5.7 Reference Manual, Capítulo 1: Información General, 2017 ,Disponible en:
13
https://dev.mysql.com/doc/refman/5.7/en/introduction.html/
14
pueden ser usadas como una estructura de soporte general (framework) para
compilar cualquier tipo de aplicación.7
REQUERIMIENTOS FUNCIONALES: Descripción de la interacción entre el

sistema y su ambiente independientemente de su implementación.8
REQUERIMIENTOS NO FUNCIONALES: Son requisitos que imponen

restricciones en el diseño o la implementación como restricciones en el diseño o
Estándares de Calidad. Son propiedades o cualidades que el producto debe
tener.9
7
NERBEANS. HOME / Community / Releases & Planning: Información NetBeans IDE 6.1, 2017, Disponible en:
https://netbeans.org/community/releases/61/index_es.html/
8
QUIROGA, Juan. Requerimientos Funcionales y No Funcionales, 5 diciembre, 2013, Disponible en:
http://www.electrohuila.com.co/Portals/0/UpDocuments/0b530417-2986-450e-bd92-34928a11e2f5.pdf
9
QUIROGA, Juan. Requerimientos Funcionales y No Funcionales, 5 diciembre, 2013, Disponible en:
http://www.electrohuila.com.co/Portals/0/UpDocuments/0b530417-2986-450e-bd92-34928a11e2f5.pdf
15
RESUMEN
Este documento presenta la implementación de un sistema de inventarios

diseñado para el área de soporte técnico de la empresa Comercializadora Arturo
Calle S.A.S. El proyecto se realizó con base en los lineamientos de la metodología
de diseño de software Extreme Programming y se desarrolla en un ciclo de cuatro
fases (exploración, planificación, iteración y puesta en producción). La
implementación del sistema se dio como solución a los problemas evidenciados en
la forma como se llevaba el registro de los dispositivos tecnológicos de la
empresa. Información errónea, pérdida de datos y falta de control eran algunos de
los inconvenientes que afectaban los procesos en la gestión de incidencias en el
área de soporte técnico. En este documento se muestran los pasos que se
siguieron para desarrollar el proyecto y los entregables que se generaron en cada
una de las fases de la metodología. Finalmente se darán las conclusiones que se
obtuvieron al implantar el sistema de inventarios diseñado.
Palabras clave: Diseño de sistemas, inventario, sistema de información, software.
16
ABSTRACT
This document presents the implementation of an inventory system that was

designed for the technical support area of the company Arturo Calle S.A.S. The
project was based on the guidelines of the software design methodology Extreme
Programming, and was developed in a four-stage cycle (exploration, planning,
iteration and putting into production). The implementation of the system was given
as a solution to the problems evidenced in the way in which the registration of the
technological devices of the company was carried out. Wrong information, loss of
data and not carrying necessary data control are some inconveniences that
affected the processes in the management of incidents in technical support. This
document shows the steps that were followed to develop the project and
deliverables that were generated in each of the phases of the methodology, finally,
the conclusions that were obtained when implementing the designed inventory
system were given.
Keywords: Systems design, inventory, information system, software.
17
INTRODUCCIÓN
En la actualidad las aplicaciones tecnológicas y el software inteligente juegan un

papel importante en las empresas. No es un lujo sino una necesidad tener
actualizado su sistema con el último software del mercado ya que una empresa
que no se esté actualizando constantemente pasa rápidamente a ser una empresa
obsoleta porque el mundo actual requiere cambios constantes según las
necesidades que surgen a diario.
El activo más importante de una empresa es la información, por lo cual en los

procesos se debe manejar teniendo en cuenta los estándares de seguridad
definidos por la empresa para evitar daños o pérdida de datos durante su uso.
En la empresa Comercializadora Arturo Calle S.A.S. se llevan los registros de

inventarios de equipos tecnológicos en varios archivos Excel, por lo cual se
requiere migrar toda la información que se tiene hasta el momento a una
herramienta que permita mejorar el acceso y uso de estos datos, evitando pérdida
o daño de los mismos. Por medio de este proyecto se busca diseñar un aplicativo
que permita mejorar el proceso de registro y consulta de dispositivos electrónicos
a cargo del área de soporte técnico de la empresa Comercializadora Arturo Calle
S.A.S.
En la primera etapa del proyecto se definen los requerimientos necesarios para

que el aplicativo cumpla con los estándares definidos por la empresa
Comercializadora Arturo Calle S.A.S. en la segunda parte se dará inicio al diseño
del aplicativo para posteriormente en una tercera fase desarrollar el aplicativo y
finalmente la empresa define los estándares para implantar el proyecto.
18
1. GENERALIDADES
1.1. ANTECEDENTES
Hoy en día todas las empresas sin importar su magnitud utilizan el término de
inventario, pero no es un término actual, ya que en la antigüedad era usado por el
pueblo de Egipto como está escrito en la sagrada Biblia 10. El pueblo de Egipto
recaudaba la quinta parte de su cosecha y la almacenaba en las ciudades, en este
caso se llevaba el registro de la cantidad de alimento que se tenía y realizaban un
cálculo para que las reservas alcanzaran para siete años. A través del tiempo ha
evolucionado el concepto de inventario, llevando los registros de distintas formas y
siempre cambiando a la necesidad del ser humano.11
Según la Sociedad Americana de la Producción y el Control de Inventarios

(SAPCI), “los inventarios son aquellas existencias o ítems usados para apoyar la
producción, las actividades de apoyo (mantenimiento, reparación y operaciones de
apoyo) y servicio al cliente (bienes terminados y partes disponibles). Comprende
también el almacenamiento de todos los materiales usados o fabricados por
cualquiera en la organización para propósitos directos o indirectos de ofrecer
productos terminados o servicios a los clientes”12
A través del tiempo el término de Inventarios ha venido creciendo para llevar

control sobre todas las áreas de la empresa, apoyando cada actividad y proceso.
En la actualidad el software que ayuda a administrar los inventarios hace parte del
Sistema de Gestión de Inventarios (WMS por sus siglas en ingles), el cual
básicamente pretende llevar el control del inventario y la ubicación de estos.
Existen herramientas de licenciamiento libre que son básicas y a su vez se limitan
en la capacidad de almacenamiento y son poco eficaces al generar reportes. Otras
herramientas de software comercial ofrecen una mayor cantidad de servicios
según la necesidad de la empresa, pero sin importar si es básica o compleja el
objetivo es administrar adecuadamente el flujo de activos en una empresa.
Dados los inconvenientes encontrados en la forma que se lleva actualmente el

registro de inventario en el área de soporte técnico de la empresa Arturo Calle
SAS, se pretende buscar una solución que ayude a mitigar los riesgos de pérdida,
daño
10
La Santa Biblia. Traducido de los textos originales por Evaristo Martín Nieto. 5 ed. Colombia: Editorial San
Pablo, 1933. Génesis 35: 25-35.
11
GESTIOPOLIS. Importancia del control de inventarios en las empresas [en línea]. [citado el 18 Abril de
2017]. Disponible en internet: <https://www.gestiopolis.com/importancia-del-control-de-inventarios-en-las-
empresas/> 12 SOCIEDAD AMERICANA DE LA PRODUCCIÓN Y EL CONTROL DE INVENTARIOS, Citado
por ARANGO,
Carlos. Definición, desarrollo e implementación de una propuesta metodológica para determinar el modelo de
inventarios para productos terminados en las empresas que fabrican elementos de fijación en Colombia. Tesis
Magíster en Ingeniería. Medellín: Universidad Nacional de Colombia. Facultad de Minas. Departamento de
19
1. GENERALIDADES
Ingeniería. 2009. 19 p.
20
o imprecisión en los datos que se evidencian en ocasiones en la empresa a través
de una herramienta diseñada a lo largo de este proyecto.
1.2. PLANTEAMIENTO DEL PROBLEMA
1.2.1. Descripción del problema.
Actualmente en la empresa Arturo Calle S.A.S se lleva un control de los

dispositivos electrónicos como teclados, pantallas, impresoras, monitores, entre
otros, a través de varios archivos en Excel, pero se evidencia que es un proceso
donde tiene grandes dificultades a la hora de buscar información de un dispositivo,
ya que se debe buscar en varios documentos y además se han presentado
pérdidas de datos en varias oportunidades. Otros problemas que se encuentran
actualmente es que no se guarda un registro de los lugares donde ha sido
asignado un dispositivo, sólo se almacena el lugar donde se encuentra
actualmente. Para la empresa es importante saber el historial de los lugares y qué
personas han utilizado los dispositivos existentes. Además existen riesgos de
guardar información errónea, duplicar valores, asignaciones en ubicaciones
inexistentes de la empresa, entre otros inconvenientes que se presentan por no
utilizar una herramienta adecuada.
Los datos de los dispositivos electrónicos son utilizados en la gestión de

incidencias de la empresa, por ejemplo, si un computador presenta una falla la
persona encargada de solucionarla necesita saber algunos datos del dispositivo,
como nombre del equipo, marca, modelo, entre otros. Las fallas en el actual
registro de inventario hacen que se pierda tiempo en la gestión de incidencias.
1.2.2. Formulación del problema.
¿Cómo implementar un aplicativo para el registro y control de inventario de

dispositivos tecnológicos en el área de soporte técnico de la empresa Arturo Calle
S.A.S que mantenga la integridad de los datos, solucione los problemas actuales y
apoye la gestión de incidencias garantizando la disponibilidad de la información?
21
1.3. OBJETIVOS
1.3.1. Objetivo general.
Implementar un sistema de inventario en la empresa Comercializadora Arturo

Calle S.A.S. para apoyar la gestión de incidencias en el área de soporte
técnico.
1.3.2. Objetivos Específicos.
 Seleccionar la metodología de desarrollo para la construcción del software.
 Determinar los requerimientos funcionales y no funcionales para

dimensionar el sistema.
 Diseñar el sistema de inventario para precisar la arquitectura y diagramas

que lo componen.
 Desarrollar el sistema de inventario para apoyar la gestión de incidencias

en el área de soporte técnico.
22
1.4. JUSTIFICACIÓN
En cada tarea que realizan las empresas se genera información que contiene
todos los movimientos de las mismas, una empresa avanza a medida que toma
decisiones de acuerdo a sus necesidades y teniendo en cuenta la información
almacenada en su sistema. Para que se tomen las decisiones más adecuadas se
debe tener la información de las transacciones de las empresas sin ningún error,
ya que si los registros son erróneos se optará por tomar medidas que no son
viables. Por ejemplo, si en una entidad bancaria por error el sistema muestra que
el banco genera más pérdidas que ganancias entonces se optara por tomar
medidas que no los lleve a la bancarrota cuando en realidad la entidad está
generando ganancias.
Cuando las empresas necesitan realizar adecuaciones que involucren exponer la

información a un riesgo de pérdida o daño se debe realizar bajo los estándares
más rigurosos muchas veces definidos por la empresa, y más si son grandes
volúmenes de información como los que manejan las medianas y grandes
empresas para no tener ningún inconveniente. La pérdida de datos es causada
muchas veces por el mal funcionamiento de hardware o el mal manejo de las
herramientas por parte de los empleados, es por esto que las empresas deben
manejar aplicativos confiables y con entornos fáciles de manejar para sus
empleados.
Según Jack Fleitman en el artículo “La Importancia De Los Sistemas De

Información Y Control En La Empresas” cita lo siguiente:
“Las empresas deben tener modernos sistemas de información,

administración y operación para que prosperen y sobrevivan en los
mercados internacionales.
Asimismo, los directivos y los mandos medios de las empresas muchas

veces necesitan disponer de información instantánea, pues deben tomar
decisiones que no pueden esperar y, por ello, requieren de sistemas fáciles
y efectivos que proporcionen diferentes tipos de datos con el mayor detalle
y de la mejor manera posible.”13
De acuerdo con lo anterior se puede decir que las empresas deben utilizar
sistemas de información que proporcionen de manera eficaz datos requeridos en
cualquier momento. Es por esto que se pueden utilizar diversas herramientas
que existen
13
Fleitman, J. La Importancia De Los Sistemas De Información Y Control En La Empresa. [en línea]. México:
23
1.4. JUSTIFICACIÓN
La Empresa [citado 07 de Abril, 2017]. Disponible en Internet <URL:
http://cmapspublic2.ihmc.us/rid=1NS6XX71W-29LN31F- 254J/LA%20IMPORTANCIA%20DE%20LOS
%20SISTEMAS%20DE%20INFORMACI%C3%93N%20Y.pdf. >.
24
actualmente algunas de ellas gratuitas para el manejo adecuado de la información
y con la tranquilidad de que los datos están seguros y no perderán su integridad.
En el caso de la empresa Comercializadora Arturo Calle S.A.S. contar con un
sistema de inventarios eficaz permitirá mitigar problemas actuales como el tiempo
de solución a las incidencias presentadas con los dispositivos tecnológicos. La
empresa se ha caracterizado por diseñar sus propias aplicaciones, es por esto que
se necesita diseñar un sistema desde cero ya que se requiere un software que se
adapte a las necesidades de la empresa y no que la empresa de adapte a un
software ya diseñado.
1.5. DELIMITACIÓN
1.5.1. Espacio. El actual proyecto se limitará a la Torre Empresarial de Arturo

Calle ubicada en Bogotá. Se utilizarán los equipos de cómputo de la entidad
para el desarrollo del proyecto. La información será confidencial y no se
podrá llevar fuera de sus instalaciones.
1.5.2. Tiempo. El periodo de desarrollo del proyecto es a partir del 11 de enero

del 2017 al 10 de Julio de 2017, fecha durante la cual el estudiante estará
realizando la práctica empresarial.
1.5.3. Contenido. El análisis del proyecto se hará a través de la información

actual de la entidad y se aplicarán herramientas libres para cumplir los
requerimientos de la empresa Comercializadora Arturo Calle S.A.S.
1.5.4. Alcance.
 El actual proyecto no pretende ser un sistema para la gestión de

incidencias en la empresa Comercializadora Arturo Calle S.A.S.
 El presente proyecto pretende el diseño e implementación de un sistema

de inventario para la empresa Comercializadora Arturo Calle S.A.S.
 El presente sistema no pretende realizar procesos de minería de datos

sobre la información que se tenga.
25
1.6. MARCO REFERENCIAL (TEÓRICO Y CONCEPTUAL)
1.6.1. Marco Teórico.
El actual proyecto sigue la teoría reduccionista de la teoría general de sistemas, la

cual tiene un enfoque al estudio de los fenómenos complejos basándose en el
análisis de cada una de sus partes. La teoría reduccionista consiste en ir de lo
general a lo particular.14 Con la empresa comercializadora Arturo Calle S.A.S se
observa los inconvenientes generales del área de soporte técnico y se analiza
particularmente los problemas generados a través del registro de inventarios
actual.
Para dar solución al problema encontrado se debe seguir una metodología ágil de
desarrollo de software. Las metodologías ágiles son usadas desde hace más de
una década alrededor del mundo y se generan en respuesta a los fracasos y
frustraciones del modelo en cascada. Las metodologías ágiles reconocen que el
software es propenso a errores por naturaleza y proponen unos lineamientos para
minimizar los riesgos desde el principio15.
14
CARMONA, Dougglas. Teoría General De Sistemas Un Enfoque Hacia la Ingeniería de Sistemas. Colombia,
2011.
15
BLÉ Carlos. Diseño Ágil con TDD. Canarias, 2010.
26
1.6.2. Marco Conceptual
1.6.2.1. Sistema de Información. Conjunto de componentes interrelacionados

que permiten capturar, procesar, almacenar y distribuir la información
para la toma de decisiones y el control 16, en este caso, para ayudar al
manejo de información en el área de soporte técnico de la empresa
Comercializadora Arturo Calle S.A.S.
Los sistemas de información sirven para:
 Tener acceso rápido a la información requerida y optimizar tiempos
en procesos de usuarios.
 Generar información confiable y tener el control del sistema.
 Analizar la información a través de indicadores para detectar

posibles fallas.
 Tener la posibilidad de planear e idear proyectos, los cuales van a

estar generados de un sistema de información que tiene unos
elementos claros y en dado caso sustentados para prever cualquier
tipo de requerimientos.
 Sistematizar la información, ya que manualmente aumenta los

riesgos de tener fallas en la información.
 Evita la pérdida de tiempo en la organización de la información.
 Dar mayor interés en la creación de nuevos procesos de trabajo

debido a la facilidad que brinda para la obtención y el procesamiento
de información.
 Se hace más efectiva la comunicación entre procesos y por lo tanto

entre grupos de trabajo, una comunicación de diferentes instancias
con los mismos resultados ágiles y confiables.17
16
FLORES, Adrián Alejandro. Metodología de gestión para las micro, pequeñas y medianas empresas.
Trabajo de grado Ingeniería. Lima: Universidad Nacional Mayor de San Marcos. Facultad de Ingeniería.
Departamento de Ingeniería de Sistemas e Información, 2011. 158 p.
17
GERENCIE. Sistemas de Información [en línea]. [citado 18 Abril de 2017]. Disponible en internet:
<URL:https://www.gerencie.com/sistemas-de-informacion.html>
27
1.6.2.2. Inventario. Según la Real Academia Española (RAE), inventario se
define como los bienes y demás cosas pertenecientes a una persona o
comunidad, hecho con orden y precisión.18
1.6.2.3. Extreme Programming (XP). Es una metodología ágil para el desarrollo

de software basada en la simplicidad y agilidad. Algunas características
de las metodologías agiles como la XP son:
 Son adaptables a lugares predictivos, es resistente a cambios.

 Los métodos ágiles son orientados a la gente y no orientados al
proceso. Los métodos ágiles apoyan al equipo de desarrollo en su
trabajo.19
En la figura 1 se comparan los ciclos de desarrollo de cascada, iterativos
tradicionales y los de XP. Se observa que el ciclo de vida de XP es
dinámico y constantemente realiza ciclos completos de análisis, diseño,
desarrollo y pruebas. Una ventaja de XP frente a otros modelos es que
el cliente puede realizar cambios en los requerimientos sin afectar los
procesos que ya se han realizado.
Figura 1- Comparación Ciclos de Desarrollo
Fuente:
https://iie.fing.edu.uy/~josej/docs/XP%20-%20Jose%20Joskowicz.pdf
18
REAL ACADEMIA ESPAÑOLA. Diccionario de la lengua Española [en línea]. [citado 18 Abril de 2017].
Disponible en internet: <URL: http://dle.rae.es/?id=M2v6jgO>
19
JOSKOWICZ, José. Reglas y Prácticas en eXtreme Programming. España, 2008. P. 8.
28
1.6.2.4. JavaServer Faces (JSF). Tecnología que establece estándares para la
construcción de interfaces de usuario aprovechados por herramientas
para el desarrollo web.20
1.6.2.5. Prime Faces. Prime faces es un conjunto de componentes para JSF,

PrimeFaces sobresale entre otras bibliotecas de componentes por:
 Simplicidad y rendimiento: PrimeFaces es una biblioteca ligera, sin

dependencias ni nada que configurar.
 Fácil de usar: PrimeFaces diseña sus componentes ocultando la

complejidad pero mantiene la flexibilidad de los mismos.
 Retroalimentación de la comunidad: PrimeFaces a través de su

comunidad promueve el desarrollo de nuevas ideas, parches e
informe de errores. 21
Estado del arte, relacionar 10 referencias de sistemas de inventarios (incluir

algunos que sean libres).
1.7. METODOLOGÍA
1.7.1. Tipo de Estudio.
La metodología de desarrollo de software propuesta para este trabajo es eXtreme

Programming (XP). Esta define el modelo a seguir para realizar un proyecto viable,
identificando pros y contras en la implementación del proyecto en un entorno
empresarial tipo práctico.
La metodología consiste en involucrar a los clientes del proyecto con el equipo de

trabajo que va a realizar el desarrollo del sistema, con el fin de tener una visión
más amplia de lo que se busca implementar y no tener inconvenientes de
comunicación durante el proceso.
20
ORACLE, JavaServer faces Technology [en línea]. [citado 18 Abril de 2017]. Disponible en internet: <URL:
http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html >
21
PRIMEFACES. Why PrimeFaces? [en línea]. [citado 18 Abril de 2017]. Disponible en internet: <URL:
https://www.primefaces.org/whyprimefaces/ >
29
1.7.2. Fuentes de Información.
El ingeniero José Joskowicz define que “El ciclo de vida de un proyecto XP es

dinámico y se puede separar en 4 fases, Fase de exploración, Fase de
planificación, Fase de iteraciones y Fase de producción” 22, a través del ciclo de
vida se permitirá hacer una implementación correcta y al finalizarlo realizar las
conclusiones correspondientes al proyecto. En el desarrollo del proyecto se
utilizarán unos roles propuestos por la metodología los cuales son Programador,
Cliente, Tester, Tracker, Coach, Big boss23. En la siguiente tabla se muestra las
funciones asociados a cada rol.
Tabla 1 - Roles XP y Funciones

Rol Funciones
Programador Describir Pruebas Unitarias y Programar

el Módulo de inventarios.
Cliente Realizar Pruebas Funcionales, Realiza

Historias de Usuario junto con el Tester.
Describe pruebas Funcionales junto con

Tester el Cliente, Ejecuta las pruebas Descritas
por el programador.
Seguimiento del proyecto, Tiempos

Tracker estimados del proyecto, Seguimiento a
cada iteración.
Coach Responsable proceso Global.
Big Boss Responsable de condiciones adecuadas

para el desarrollo del proyecto.
Fuente: El Autor.
22
JOSKOWICZ, José. Reglas y Prácticas en eXtreme Programming. España, 2008. P. 8.
23
CANÓS, J. LETELIER P. y PENADÉS M. Metodologías Agiles en el Desarrollo de Software. Taller realizado
en el marco de las VIII Jornadas de Ingeniería del Software y Bases de Datos (JISBD)
30
1.8. DISEÑO METODOLÓGICO
Inicialmente se escoge la metodología de desarrollo de software más adecuada

para el actual proyecto. Con base en la metodología seleccionada se comienza
con un análisis de los requerimientos del cliente a través de historias de usuario.
En la segunda fase el programador analiza las historias de usuario describiendo

con ellas los requerimientos funcionales y no funcionales del sistema para
después realizar un plan de entregas junto a las pruebas que debe pasar cada
tarea.
En la tercera fase se entregan los diagramas pertinentes para posteriormente

empezar a realizar iteraciones cumpliendo con los requerimientos del cliente y
entregando el código fuente después de realizar las pruebas donde se evidencie el
cumplimiento de dichos requerimientos.
En la cuarta fase el cliente valida el cumplimiento de todos los requerimientos

descritos y decide si se pone en producción, finalmente se darán las conclusiones
del diseño e implementación del proyecto.
31
2. DISEÑO Y DESARROLLO DEL SISTEMA DE INVENTARIO
El diseño y desarrollo de este sistema de inventario se hará durante las 4 fases de

la metodología XP descritas anteriormente (Exploración, Planificación, Iteraciones
y Puesta en Producción).
2.1. EXPLORACIÓN
Para la fase de exploración se realizan reuniones con el cliente del proyecto y el

programador, se diligencian las historias de usuario en cada reunión atendiendo
los requerimientos del cliente para después analizar los requerimientos mínimos
que debe tener el sistema.
2.1.1. Historias de usuario.
Las historias de usuario fueron diligenciadas en el siguiente formato:
32
Tabla 2 - Formato Historia de Usuario
HISTORIA DE USUARIO
Número: Fecha:
Número que identifica la Historia de Fecha del desarrollo de la historia de
Usuario. usuario en mención.
Usuario:
Personas entrevistadas en la historia de usuario en mención.
Nombre de Historia:
Nombre que define la Historia de Usuario en mención.
Prioridad en Negocio: Puntos Estimados:
Tiempo estimado de desarrollo de la
(Alta / Medio / Baja) Historia de Usuario. (Cada punto equivale
a una semana de trabajo).
Riesgos en Desarrollo: Puntos Reales:
Tiempo real de desarrollo de la Historia de
(Alta / Medio / Baja) Usuario. (Cada punto equivale a una
semana de trabajo).
Programador Responsable: Iteración Asignada:
Persona encargada de desarrollar las Número de iteración asignada donde se
tareas de la Historia de Usuario en desarrollarán las tareas de la Historia de
mención. Usuario en mención.
Descripción:
Breve descripción de los requerimientos descritos por los usuarios entrevistados para
ser desarrollados el aplicativo.
Observaciones:
Descripción de las observaciones a tener en cuenta para desarrollar las tareas de la

Historia de Usuario en mención.
Fuente: El Autor.
33
En la siguiente tabla se muestran las historias de usuario obtenidas, los detalles
de las historias de usuario diligenciadas se encuentran en el Anexo A.
Tabla 3 - Historias de usuario
Historias de usuario
Número Nombre
1 Guardar/Modificar Ubicaciones Técnicas.
2 Guardar/Modificar Centros de costo.
3 Guardar/Modificar Oficinas.
Consultar Información por Centro de Costo y Listado Centros de
4
costo (Directorio).
Consultar Información de oficinas por zona y Listado de oficinas
5
(Directorio).
6 Listar de ubicaciones de la torre empresarial.
7 Guardar/Modificar Información de dispositivos.
8 Asociar dispositivo a un responsable.
9 Dar de baja a un equipo.
10 Almacenar historial de dispositivo.
Listar el historial de un dispositivo. (Buscar por placa nueva o
11
antigua).
12 Buscar historial de una persona (Buscar por cedula).
13 Listar equipos activos.
Listar equipos activos y diferenciar entre centros de costo, torre
14 empresarial y oficinas.
15 Listar equipos que están de baja.
16 Buscar ubicación técnica por Ubicación.
Fuente: El Autor.
34
2.1.2. Requerimientos funcionales del sistema.
A partir de las historias de usuario identificadas, se definen los requerimientos del

sistema que se muestran a continuación.
Tabla 4 - Requerimientos Funcionales del Sistema
NÚMERO REQUERIMIENTOS FUNCIONALES
R1 Registrar/Modificar ubicaciones técnicas.
R2 Mostrar ubicaciones técnicas.
R3 Registrar/Modificar datos de dispositivos.
R4 Registrar/Modificar datos de un lugar.
R5 Mostrar datos de un lugar.
R6 Registrar/Modificar datos de oficinas.
R7 Mostrar datos de oficinas.
R8 Registrar/Modificar centros de costos.
R9 Mostrar centros de costos.
R10 Registrar/Modificar equipos de baja.
R11 Mostrar equipos de baja.
R12 Asociar responsables a los dispositivos.
R13 Mostrar equipos con responsable y datos del dispositivo.
R14 Mostrar historial de dispositivos.
R15 Mostrar historial asociados a un responsable.
Cambiar estado de asignación del equipo cuando cambia de
R16
responsable o se da de baja.
Fuente: El Autor.
Los detalles de cada requerimiento se encuentran en el Anexo B.
35
2.1.3. Requerimientos no funcionales del sistema.
Los requerimientos funcionales son descritos como atributos de calidad los cuales
se pueden clasificar en Usabilidad, Eficiencia, Mantenibilidad y Seguridad.24
Los requerimientos funcionales para el actual sistema se definen en la siguiente
tabla:
Tabla 5 - Requerimientos no funcionales del sistema

Número Clasificación Atributo de calidad Descripción
1 Flexibilidad Funcionamiento por módulos.
El sistema de inventario es
Usabilidad capaz de cumplir los objetivos
2 Usabilidad deseados por la empresa con
efectividad, eficiencia y
satisfacción.
Todos los módulos son
aprobados utilizando el plan de
3 Mantenibilidad Testeabilidad pruebas, cada módulo depende
de otro para mostrar y
almacenar información.
El sistema es capaz de registrar
4 Eficiencia Concurrencia múltiples equipos de forma
recurrente.
La información tiene respaldo
5 Tolerancia a fallos en caso de fallas en el sistema.
Los datos suministrados por el
Seguridad sistema son examinados y
6 Auditabilidad verificados por el Ingeniero
encargado, realizando pruebas
de visibilidad.
Fuente: El Autor.
24
SOMMERVILLE, Ian. Software Engineering. Traducido por Víctor Campos Olguín. 9 ed. Escocia: 2015.
816p. ISBN 9780133943030.
36
2.2. PLANIFICACIÓN
El desarrollo del aplicativo del sistema de inventario se hará en base al patrón de

arquitectura Modelo-Vista-Controlador. A continuación se muestra la relación entre
capas del modelo-vista-controlador.
Figura 2 - Estructura Modelo Vista Controlador
Fuente: POTEL, Mikel. MVP: Model-View-Presenter The Taligent Programming

Model for C++ and Java. Paper. P.13.
Para el diseño de la interfaz de usuario se realizan los mockups del aplicativo

(Anexo C) que describen la capa vista, el proyecto cuenta con 9 páginas
enlazadas unas a otras.
El diagrama relacional se encuentra en el anexo D, el cual describe la capa modelo.
El diagrama de clases se encuentra en el anexo E que define la capa controlador
en donde se encuentra la lógica del negocio.
Se debe utilizar la librería Java Server Faces (JSF) con la cual se adquiere un
componente llamado PrimeFaces que facilita el entorno visual de la aplicación,
todo se desarrollará en el entorno de Netbeans y utilizando como motor de base
de datos MySQL server.
37
Ya descritas las condiciones y entorno de programación que se utilizará para el
actual proyecto se describe el plan de entregas y plan de pruebas para empezar a
programar el aplicativo en las iteraciones indicadas.
2.2.1. Plan de entregas.
A continuación se describe las historias asociadas a cada iteración, las tareas a

realizar en cada una y la fecha de entrega.
Tabla 6 - Plan de entregas
Historias de usuario asignadas Fecha de
Núm. Nombre Tareas
entrega
 Inserción de
Guardar/Modificar ubicaciones técnicas. 08 de Marzo
1 Ubicaciones Técnicas del 2017.
 Modificación de
ubicaciones técnicas.
 Inserción de centros de
Guardar/Modificar Centros costo. 10 de Marzo
2 de costo del 2017.
 Modificación de centros
de costo.
Iteración
 Inserción de oficinas.
1
3 Guardar/Modificar Oficinas 16 de Marzo

 Modificación de del 2017.
oficinas.
Buscar si existe ubicación  Buscar ubicación 21 de Marzo
16
técnica. técnica por ubicación. del 2017.
 Listar ubicaciones
Listado ubicaciones técnicas.
6 técnicas de la torre 24 de Marzo
empresarial.  Diseño de la interfaz del 2017.
para la sección de
ubicaciones técnicas.
Guardar/Modificar
Información de dispositivos.
 Inserción de equipos
Asociar dispositivo a un asignados.
Iteración 2
7–8- 31 de Marzo
responsable.
10 del 2017.
 Modificación de
equipos asignados.
Almacenar historial de un
dispositivo.
 Inserción de bajas. 04 de Abril de
9 Dar de baja a un equipo. 2017.
38
 Diseño de la interfaz
para la sección de
bajas.
 Listar datos centros de
costo.
Directorio Centros de 10 de Abril de
4 Costo.  Diseño de la interfaz 2017.
para la sección de
directorio centros de
costo.
 Listar datos de oficinas.
14 de Abril de
5 Directorio de Oficinas.  Diseño de la interfaz 2017.
para la sección de
directorio de oficinas.
para la sección de
inventario equipos en la
torre empresarial.
Listado equipos activos.
para la sección de
13 - inventario equipos en 25 de Abril de
Listado de equipos según
14 las oficinas. 2017.
tipo de lugar.
para la sección de
inventario equipos en
los centros de costo.
 Listar datos de equipos

Iteración
activos según el tipo de

3
lugar.
 Listar historial de un
dispositivo por placa
nueva.
Buscar historial de un  Listar historial de un

11 02 de Mayo
dispositivo por placa nueva dispositivo por placa de 2017.
o placa antigua. antigua.
 Diseñar interfaz para la

sección de historial de
dispositivos.
Buscar historial de  Listar historial de un 05 de Abril de

12 dispositivos por cedula del dispositivo por cedula 2017.
responsable. del responsable.
39
11 de Abril de
15 Listado equipos de baja.  Listar equipos de baja.
2017.
Fuente: El Autor.
2.2.2. Plan de pruebas.
A continuación se definieron las pruebas que se deben realizar para validar la

funcionalidad de cada iteración.
Tabla 7 - Plan de pruebas

Pruebas
Núm. Descripción
Insertar cuatro ubicaciones con los siguientes datos:
1 (1ABC1, TE, Puesto de trabajo 11 - tipo 2), (2OFI1, OF,
Oficina Medellín), (3CEC1, CC, Centro
Comercial SantaFe),
(1TEAC1, TE, Torre Empresarial General).
2 Modificar la ubicación 1TEAC1 por 1AC1.
Insertar un centro de costo con la siguiente información
3 (3CEC1, CALI, CALLE 123 # 48-00, Adriana Gómez, 7894,
null, null, 3213213211, OQ0, 5, 2).
Modificar el nombre del administrador del centro de costo
4
Iteración 1
ingresado por María Quintero.

Insertar una oficina con los siguientes datos (2OFI1, Medellín,
5 Calle 47 # 47 – 00, Paola Moreno, 5678, null, null, null,
Antioquia).
Modificar el teléfono1 y teléfono 2 por (1234567), (7654321)
6
respectivamente.
Buscar si existe la ubicación (1ABC1), debe mostrar el
7
mensaje de que si existe la ubicación.
Buscar si existe la ubicación (2EER4), debe mostrar el
8
mensaje de que no existe la ubicación.
Listar las ubicaciones técnicas debe aparecer los datos de
9
las siguientes ubicaciones (1ABC1, 2OFI1, 3CEC1,
1TEAC1).
Insertar cuatro equipos con los siguientes datos
(ABCMT1234, MT1234, Lenovo, m12, 12345, monitor,
1ABC1, David Latorre, 1234567890, davidl, 02/05/2017,
equipo nuevo), (ABCTE4321, TE4321, Lenovo, t21, 54321,
10
Iteración 2
teclado, 1ABC1,
David Latorre, 1234567890, davidl, 02/05/2017, null),
(ABCCJ4321, CJ4321, Epson, c34, 12456, cajón monedero,
3CEC1, James Castro, 7856985421, OQ0, 02/05/2017, null),
(ABCPO1234, null, Lenovo, p623, 121579, portátil, 2OFI1,
Laura Giraldo, 1030578942, laurag, 02/05/2017, null).
11 Dar de baja al equipo con placa nueva ABCPO1234.
40
Modificar el equipo con placa ABCMT1234 con la
12
observación (equipo nuevo comprado el 22 de febrero).
13 Dar de baja al equipo de placa 1ABCTE4321.
Listar Oficinas, deben aparecer los datos de la oficina de la
14
zona de Antioquia.
Listar Centros de costo, deben aparecer los datos del centro
15 de costo con nombre OQ0.
Listar los equipos activos en la torre empresarial, deben
16 aparecer los datos de los dispositivos de placa ABCMT1234
y ABCTE4321.
Listar los equipos activos en los centros de costo, deben
17
aparecer los datos del dispositivo de placa ABCCJ4321.
Listar los equipos activos en las oficinas, deben aparecer los
Iteración 3
18
datos del dispositivo de placa ABCPO1234.
Buscar el historial del dispositivo de la placa nueva
19
ABCCJ4321.
20 Buscar el historial del dispositivo de la placa antigua MT1234.
Buscar el historial de dispositivos del responsable con cedula
21
1234567890.
Listar equipos de baja, debe aparecer la información del
22
equipo con placa ABCPO1234.
Fuente: El Autor.
41
2.3. ITERACIONES
2.3.1. Iteración 1
En la primera iteración se cumplió con las tareas asignadas, dando como resultado
los siguientes archivos:
1. Clase UbicacionTecnicaService.java (véase Figura 3). En esta clase se
manejan los servicios que permitirán guardar, listar y buscar ubicaciones
técnicas.
Figura 3 - Fragmento de la clase UbicacionTecnicaService.java
Fuente: El Autor.
42
2. Clase UbicacionTecnicaDAO.java (véase Figura 4). Esta clase permite la
comunicación entre la tabla ubicaciontecnica de la base de datos
sistemadeinventarioac y la aplicación.
Figura 4 - Fragmento de la clase UbicacionTecnicaDAO.java
Fuente: El Autor.
43
3. Clase UbicacionTecnicaDTO.java (véase Figura 5). Esta clase permite
almacenar información de la ubicación técnica en un objeto y transportarla
para los procesos pertinentes.
Figura 5 - Fragmento de la clase UbicacionTecnicaDTO.java
Fuente: El Autor.
44
4. Archivo HTML dirUbicTec.xhtml (véase Figura 6). Este archivo contiene la
interfaz gráfica de la sección del directorio de ubicaciones técnicas.
Figura 6 - Fragmento del archivo dirUbicTec.xhtml
Fuente: El Autor.
45
5. Clase DatosLugarService.java (véase Figura 7). En esta clase se manejan
los servicios que permitirán guardar, listar y buscar datos de un lugar.
Figura 7 - Fragmento de la clase DatosLugarService.java
Fuente: El Autor.
46
6. Clase DatosLugarDAO.java (véase Figura 8). Esta clase permite la
comunicación entre la tabla datoslugar de la base de datos
Figura 8 - Fragmento de la clase DatosLugarDAO.java
Fuente: El Autor.
7. Clase DatosLugarDTO.java (véase Figura 9). Esta clase permite almacenar

información de los datos de un lugar en un objeto y transportar dicha
información entre procesos de la aplicación.
47
Figura 9 - Fragmento de la clase DatosLugarDTO.java
Fuente: El Autor.
8. Clase CentroDeCostoService.java (véase Figura 10). En esta clase se

manejan los servicios que permitirán guardar, listar y buscar centros de
costo.
48
Figura 10 - Fragmento de la clase CentroDeCostoService.java
Fuente: El Autor.
9. Clase CentroDeCostoDAO.java (véase Figura 11). Esta clase permite la

comunicación entre la tabla centrodecosto de la base de datos
49
Figura 11 - Fragmento de la clase CentroDeCostoDAO.java
Fuente: El Autor.
10. Clase CentroDeCostoDTO.java (véase Figura 12). Esta clase permite

almacenar información de un centro de costo en un objeto y transportar
dicha información entre procesos de la aplicación.
50
Figura 12 - Fragmento de la clase CentroDeCostoDTO.java
Fuente: El Autor.
11. Clase OficinaService.java (véase Figura 13). En esta clase se manejan los
servicios que permitirán guardar, listar y buscar oficinas.
51
Figura 13 - Fragmento de la clase OficinaService.java
Fuente: El Autor.
12. Clase OficinaDAO.java (véase Figura 14). Esta clase permite la

comunicación entre la tabla oficina de la base de datos
52
Figura 14 - Fragmento de la clase OficinaDAO.java
Fuente: El Autor.
13. Clase OficinaDTO.java (véase Figura 15). Esta clase permite almacenar
información de los datos de una oficina en un objeto y transportar dicha
información entre procesos de la aplicación.
53
Figura 15 - Fragmento de la clase OficinaDTO.java
Fuente: El Autor.
Las pruebas se efectuaron satisfactoriamente (véase Figura 16) y se procederá a

continuar con la siguiente iteración.
54
2.3.2. Iteración 2.
En la segunda iteración se cumplió con las tareas asignadas, dando como

resultado las siguientes clases:
1. Clase DatosDispositivoService.java (véase Figura 17). En esta clase se
manejan los servicios que permitirán guardar, listar y buscar datos de los
dispositivos.
Figura 16 - Fragmento de la clase DatosDispositivoService.java
Fuente: El Autor.
2. Clase DatosDispositivoDAO.java (véase Figura 18). Esta clase permite la

comunicación entre la tabla datosdispositivo de la base de datos
55
Figura 17 - Fragmento de la clase DatosDispositivoDAO.java
Fuente: El Autor.
3. Clase DatosDispositivoDTO.java (véase Figura 18). Esta clase permite

almacenar información de los datos de un dispositivo en un objeto y
transportar dicha información entre procesos de la aplicación.
56
Figura 18 - Fragmento de la clase DatosDispositivoDTO.java
Fuente: El Autor.
4. Clase EquipoService.java (véase Figura 19). En esta clase se manejan los

servicios que permitirán guardar, listar y buscar datos de las asociaciones
de los dispositivos con los responsables.
57
Figura 19 - Fragmento de la clase EquipoService.java
Fuente: El Autor.
5. Clase EquipoDAO.java (véase Figura 20). Esta clase permite la

comunicación entre la tabla equipo de la base de datos
58
Figura 20 - Fragmento de la clase EquipoDAO.java
Fuente: El Autor.
6. Clase EquipoDTO.java (véase Figura 21). Esta clase permite almacenar

información de un equipo en un objeto y transportar dicha información entre
procesos de la aplicación.
59
Figura 21 - Fragmento de la clase EquipoDTO.java
Fuente: El Autor.
7. Clase EquipoBajaService.java (véase Figura 22). En esta clase se manejan

los servicios que permitirán guardar, listar y buscar equipos que están de
baja.
60
Figura 22 - Fragmento de la clase EquipoBajaService.java
Fuente: El Autor.
8. Clase EquipoBajaDAO.java (véase Figura 23). Esta clase permite la

comunicación entre la tabla equipobaja de la base de datos
61
Figura 23 - Fragmento de la clase EquipoBajaDAO.java
Fuente: El Autor.
9. Clase EquipoBajaDTO.java (véase Figura 24). Esta clase permite

almacenar información de un equipo que está de baja en un objeto y
transportar dicha información entre procesos de la aplicación.
62
Figura 24 - Fragmento de la clase EquipoBajaDTO.java
Fuente: El Autor.
10. Archivo invBajas.xhtml (véase Figura 25). Este archivo contiene la interfaz
gráfica de la sección de bajas.
63
Figura 25 - Fragmento del archivo invBajas.xhtml
Fuente: El Autor.
11. Archivo HTML dirCCosto.xhtml (véase Figura 26). Este archivo contiene la
64
Figura 26 - Fragmento del archivo dirCCosto.xhtml
Fuente: El Autor.
12. Archivo HTML dirOficinas.xhtml (véase Figura 27). Este archivo contiene la
65
Figura 27 - Fragmento del archivo DirOficinas.xhtml
Fuente: El Autor.
Las pruebas se efectuaron satisfactoriamente y se procedió a continuar con la

siguiente iteración.
66
2.3.3. Iteración 3.
En la tercera iteración se cumplió con las tareas asignadas, dando como resultado
los siguientes archivos:
1. invTorreEmpresarial.xhtml (véase Figura 28). Este archivo contiene la
interfaz gráfica de la sección del inventario de la torre empresarial.
Figura 28 - Fragmento del archivo invTorreEmpresarial.xhtml
Fuente: El Autor.
2. invOficinas.xhtml (véase Figura 29). Este archivo contiene la interfaz gráfica

de la sección del inventario de las oficinas.
67
Figura 29 - Fragmento del archivo invOficinas.xhtml
Fuente: El Autor.
3. invCentroCosto.xhtml (véase Figura 30). Este archivo contiene la interfaz

gráfica de la sección del inventario de los almacenes.
68
Figura 30 - Fragmento del archivo invCentroCosto.xhtml
Fuente: El Autor.
4. invHistorial.xhtml (véase Figura 31). Este archivo contiene la interfaz gráfica

de la sección de historial de dispositivos.
69
Figura 31 - Fragmento del archivo invHistorial.xhtml
Fuente: El Autor.
Las pruebas se efectuaron satisfactoriamente. Con esta iteración se culmina la

tercera fase de la metodología.
70
2.4. PUESTA EN PRODUCCIÓN
En el anexo F se puede observar el manual de ejecución para volver a cargar el

aplicativo en caso de pérdida o daño del sistema.
En el anexo G se puede observar el manual de usuario del aplicativo web.
El aplicativo junto a la base de datos se almacenará en una unidad compartida por
red donde los empleados del área de soporte técnico tendrán acceso a través de
equipos de cómputo unidos al dominio de Arturo Calle SAS.
El sistema de Arturo Calle realiza backups en un periodo definido para salvar la
información almacenada en la unidad de red.
Por último, el equipo de trabajo del área de soporte técnico se reune para validar
el aplicativo y se diligencian las encuestas adjuntas en la tabla 8 y la tabla 9. La
ingeniera de soporte Laura Baldión comprueba el correcto funcionamiento del
sistema de inventario y lo valida mediante pruebas con información verdadera
suministrada por la empresa para posteriormente realizar el cargue de los datos
actuales a la base de datos sistemadeinventarioAC.sql. Los datos no pueden ser
mostrados en el actual proyecto por la cláusula de confidencialidad de la empresa
comercializadora Arturo Calle S.A.S.
Para la medición del nivel de satisfacción se utilizan los siguientes valores:
5=Excelente, 4 = Muy Bueno, 3 = Bueno, 2 = Malo y 1= Pésimo.
Para la medición del nivel de complejidad se utilizan los siguientes valores: 3=Alto,
2 = Medio y 1 = Bajo.
Tabla 8 - Nivel de satisfacción del aplicativo web
Nivel de
satisfacción Nivel de
con los complejidad
Nombre Cargo servicios del Observaciones
del aplicativo
aplicativo web
web
Practicante
Michael
Ingeniero de 5 1 Ninguna.
Moreno
soporte junior.
Es buena la aplicación ya que hace
más sencillo el proceso de encontrar
información de dispositivos. Sería
Laura Ingeniera de
5 1 bueno poder encontrar un módulo
Baldión Soporte
donde se pueda encontrar información
de los responsables como cargo, área
y
extensión.
71
Es fácil de usar, solo se debe tener
Laura Castro Practicante 5 1 conocimientos básicos sobre temas del
área de soporte para dar un buen uso
a
la aplicación.
Se solucionaron los problemas de
encontrar ubicaciones técnicas
incorrectas, lo que reduce el tiempo de
Camilo Analista de dar solución a las incidencias porque
5 1 en ocasiones cuando se buscaba la
Guzmán Soporte
persona en la ubicación técnica no la
encontraba y se perdía tiempo
buscando esa persona.
Fuente: El Autor.
Tabla 9 - Tiempo promedio de solución a incidencias.

Sin el aplicativo web
Tiempo promedio
Tiempo promedio
Nombre Cargo Tiempo promedio en dar solución a
en dar solución a
en dar solución a incidencias de
incidencias de
incidencias básicas dificultad
dificultad alta
intermedia
Practicante
Michael
Ingeniero de 25 minutos 120 minutos N/A
Moreno
soporte junior.
Ingeniera de
Laura Baldión Soporte 15 minutos 90 minutos. 180 minutos.
Laura Castro Practicante 30 minutos N/A N/A
Camilo Analista de
Guzmán Soporte 15 minutos 80 minutos. 160 minutos.
Practicante
David Latorre Ingeniero de 20 minutos 110 minutos. 240 minutos.
soporte junior.
Con el aplicativo web
Tiempo promedio
Tiempo promedio
Tiempo promedio en dar solución a
en dar solución a
en dar solución a incidencias de
incidencias de
incidencias básicas dificultad
dificultad alta
intermedia
15 minutos 100 minutos N/A
8 minutos 65 minutos. 160 minutos.
18 minutos N/A N/A
72
Fuente: El Autor.
Se realiza una comparación de los tiempos en minutos que toman los usuarios del
sistema en dar solución a las incidencias presentadas en el área de soporte
técnico, antes y después de implementar el sistema de inventarios. Se evidencia
la reducción del tiempo en la gestión de incidencias. Los resultados se muestran
en la Figura 32, Figura 33 y Figura 34.
Figura 32 - Tiempo Promedio Incidencias Básicas

Tiempo promedio de solución a incidencias
básicas
25
20
15
Segund
10
Antes Despues
Fuente: El Autor.
73
Figura 33 - Tiempo Promedio de Incidencias Dificultad Intermedia
Tiempo promedio Solución a Incidencias de difcultad intermedia
120
100
80
60
40
Segund
20
0
Antes Despues
Fuente: El Autor.
Figura 34 – Tiempo Promedio Incidencias Dificultad Alta

Tiempo promedio solución a incidencias de difcultad alta
195
190
185
180
175
Segund
170
165
160
Antes Despues
Fuente: El Autor.
74
3. CONCLUSIONES
Con la implementación del sistema de inventarios se evidencia un impacto

favorable en el área de soporte técnico. A través de las pruebas realizadas se
pudo comprobar que hay un mayor control para validar los datos que serán
almacenados en el registro de dispositivos.
Con el uso del aplicativo web se logró tener acceso a información verídica de
manera rápida disminuyendo así el tiempo de reacción para atender las
incidencias presentadas a causa de fallas en los dispositivos tecnológicos de la
empresa Arturo Calle S.A.S.
Las pruebas realizadas para el manejo de la aplicación permiten evidenciar que es

fácil de usar y entender, lo que hace que cualquier empleado que entre en
contexto con las tareas que se realizan en el área de soporte técnico pueda
manejar la aplicación sin ningún problema.
75
4. RECOMENDACIONES
Para garantizar el mejor desempeño de la aplicación se recomienda mantener

actualizados los componentes JDK, Glassfish Server y MySQL Server. Es
importante realizar el backup de la base de datos sistemaDeInventarioAC.sql por
lo menos una vez a la semana para volver a iniciar la aplicación en caso de fallas
técnicas y que no se pierda la información almacenada anteriormente.
Se recomienda iniciar un proceso de permisos en la compañía para poder

consultar los datos básicos de un empleado como nombre, cédula, extensión,
cargo, entre otros, a través de la aplicación y así tener información más clara
acerca de los responsables asociados a cada dispositivo tecnológico de la
empresa.
Se propone adaptar un módulo que se integre al sistema de inventarios ya

implementado, el cual atienda los requerimientos del área de gestión humana para
mantener actualizada la información de los empleados que tengan equipos
tecnológicos asignados. De esta manera se podría tener un mayor control sobre
daños en los equipos, ya que a través de un nuevo módulo se verificarían el
estado de los dispositivos para otorgar un paz y salvo por parte del área de
soporte técnico a los responsables. Además se podrían generar reportes sobre la
cantidad de equipos por área.
Se recomienda realzar el registro lógico del software en la dirección nacional de

derechos de autor. Con los autores David Latorre y Raúl Menéndez.
76
BIBLIOGRAFÍA
BLÉ Carlos. Diseño Ágil con TDD. Canarias, 2010.

BRAVO, Cludia. Mock Ups: ¿Para Qué Sirve?, 03 marzo, 2017, Disponible en:
http://estudioka.es/que-es-un-mock-up/
CANÓS, J. LETELIER P. y PENADÉS M. Metodologías Agiles en el Desarrollo de
Software. Taller realizado en el marco de las VIII Jornadas de Ingeniería del
Software y Bases de Datos (JISBD) 2013.
CARMONA, Dougglas. Teoría General De Sistemas Un Enfoque Hacia la

Ingeniería de Sistemas. Colombia, 2011.
Fleitman, J. (2000). La importancia de los sistemas de información y control en la

empresa. [en línea]. México: La empresa [citado el 07 de Abril de 2017]. Disponible
en internet: <URL: http://cmapspublic2.ihmc.us/rid=1ns6xx71w-29ln31f- 254j/la
%20importancia%20de%20los%20sistemas%20de%20informaci%c3%93n
%20y.pdf
FLORES, Adrián Alejandro. Metodología de gestión para las micro, pequeñas y

medianas empresas. Trabajo de grado Ingeniería. Lima: Universidad Nacional
Mayor de San Marcos. Facultad de Ingeniería. Departamento de Ingeniería de
Sistemas e Información, 2011. 158 p.
FLORES, Ervin. Ingeniería de Software: Programación Extrema XP, 1 junio, 2014,

Disponible en: http://ingenieriadesoftware.mex.tl/52753_xp---extreme-
programing.html/
GERENCIE. Sistemas de Información [en línea]. [citado 18 Abril de 2017].

Disponible en internet: URL: https://www.gerencie.com/sistemas-de-
informacion.html
GESTIOPOLIS. Importancia del control de inventarios en las empresas [en línea].

[citado el 18 Abril de 2017]. Disponible en internet:
https://www.gestiopolis.com/importancia-del-control-de-inventarios-en-las-
empresas/
JOSKOWICZ, J. Reglas y Prácticas en eXtreme Programming. Trabajo de la

asignatura Nuevas Técnicas de Desarrollo del Doctorado de Ingeniería
Telemática. España: Universidad de Vigo. 2008.
77
La Santa Biblia. Traducido de los textos originales por Evaristo Martín Nieto. 5 ed.
Colombia: Editorial San Pablo, 1933. Génesis 35: 25-35.
MYSQL. MySQL 5.7 Reference Manual, Capítulo 1: Información General, 2017,

Disponible en: https://dev.mysql.com/doc/refman/5.7/en/introduction.html/
NERBEANS. HOME / Community / Releases & Planning: Información NetBeans

IDE 6.1, 2017, Disponible en:
https://netbeans.org/community/releases/61/index_es.html/
SOCIEDAD AMERICANA DE LA PRODUCCIÓN Y EL CONTROL DE

INVENTARIOS, Citado por ARANGO, Carlos. Definición, desarrollo e
implementación de una propuesta metodológica para determinar el modelo de
inventarios para productos terminados en las empresas que fabrican elementos de
fijación en Colombia. Tesis Magíster en Ingeniería. Medellín: Universidad Nacional
de Colombia. Facultad de Minas. Departamento de Ingeniería. 2009. 19 p.
SOMMERVILLE, Ian. Software Engineering. Traducido por Víctor Campos Olguín.

9 ed. Escocia: 2015. 816p. ISBN 9780133943030.
OFFICE. Conceptos básicos sobre bases de datos, ¿Qué es una base de datos?,
2007,Disponible en: https://support.office.com/es-es/article/Conceptos-
b%C3%A1sicos-sobre-bases-de-datos-a849ac16-07c7-4a31-9948-3c8c94a7c204/
ORACLE, JavaServer faces Technology [en línea]. [citado 18 Abril de 2017].

Disponible en internet: <URL:
http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html >
ORACLE, Corporation. Capítulo 2 Acerca de Sun GlassFish Enterprise Server,

2010, Disponible en: https://docs.oracle.com/cd/E19879-01/821-
1040/relnotessgesintro/index.html/
ORACLE, Corporation. ¿Qué es la tecnología Java y para qué la necesito?,

Disponible en: https://www.java.com/es/download/faq/whatis_java.xml/
PRIMEFACES. Why PrimeFaces? [en línea]. [citado 18 Abril de 2017]. Disponible

en internet: <URL: https://www.primefaces.org/whyprimefaces/>
QUIROGA, Juan. Requerimientos Funcionales y No Funcionales, 5 diciembre,

2013, Disponible en:
78
http://www.electrohuila.com.co/Portals/0/UpDocuments/0b530417-2986-450e-
bd92-34928a11e2f5.pdf
REAL ACADEMIA ESPAÑOLA. Diccionario de la lengua Española [en línea].

[citado 18 Abril de 2017]. Disponible en internet: <URL: URL: http://dle.rae.es/?
id=M2v6jgO >
79
ANEXOS
Anexo A – Detalles Historias de Usuario
Tabla 10 - Historia de Usuario 1

HISTORIA DE USUARIO
Numero: Fecha:
1 Lunes, 06 de Febrero de 2017
Usuario:
Cliente, Programador.
Nombre de Historia:
Guardar/Modificar Ubicaciones Técnicas
Alta 0.8
Media 0.3
David Latorre Iteración 1
Descripción:
Se quiere guardar las ubicaciones técnicas que tiene definidas la empresa, para ser
consultadas posteriormente, también se quiere guardar datos asociados a una
ubicación como el sitio donde está esa ubicación(Torre empresarial, oficinas o centros
de costo) y la denominación del lugar que puede ser el nombre con el que la empresa
reconoce el sitio.
Observaciones:
Las ubicaciones técnicas no pueden estar duplicadas.
Fuente: El Autor.
80
HISTORIA DE USUARIO
Numero: Fecha:
2 Martes, 07 de Febrero de 2017
Usuario:
Nombre de Historia:
Guardar/Modificar Centros de costo
Alta 0.8
Media 0.3
Descripción:
Para el Cliente es importante almacenar datos de los centros de costo, como: la ciudad
donde está ubicado, dirección, teléfonos, administrador, numero de cajas de la tienda,
el nombre del centro de costo y la ubicación técnica.
Observaciones:
El centro de costo es único, algunos tienen varios teléfonos de contacto y la ubicación

técnica ya está definida.
Fuente: El Autor.
81
HISTORIA DE USUARIO
Numero: Fecha:
3 Miércoles, 08 de Febrero de 2017
Usuario:
Nombre de Historia:
Guardar/Modificar Oficinas
Alta 0.8
Media 0.3
Descripción:
El Cliente solicita poder registrar datos de las oficinas, como dirección, ciudad, la zona
que abarca, administrador, teléfonos de contacto y ubicación técnica.
Observaciones:
Las oficinas son conocidas por la zona que abarcan, en las oficinas no hay almacén.
Fuente: El Autor.
82
HISTORIA DE USUARIO
Numero: Fecha:
4 Jueves, 09 de Febrero de 2017
Usuario:
Nombre de Historia:
Consultar Información por Centro de Costo y Listado Centros de costo(Directorio)
Alta 1.1
Media 0.7
Descripción:
El Cliente requiere poder consultar la información de los centros de costo, buscar un

centro de costo, el cliente lo define como tener acceso a un directorio de centros de
costo.
Observaciones:
Se solicita buscar datos ingresando el centro de costo.
Fuente: El Autor.
83
Tabla 84 - Historia de Usuario
84
HISTORIA DE USUARIO
Numero: Fecha:
5 Viernes, 10 de Febrero de 2017
Usuario:
Nombre de Historia:
Consultar Información de oficinas por zona y Listado de oficinas(Directorio)
Alta 1.1
Media 0.8
Descripción:
El Cliente requiere poder consultar la información de las oficinas, buscar una oficina, el
cliente lo define como un directorio de oficinas.
Observaciones:
Se solicita buscar datos ingresando la zona de la oficina.
Fuente: El Autor.
84
85
HISTORIA DE USUARIO
Numero: Fecha:
Usuario:
Nombre de Historia:
Listado de ubicaciones de la torre empresarial
Alta 1.0
Media 0.6
Descripción:
El Cliente requiere poder consultar las ubicaciones técnicas que existen en la torre
empresarial.
Observaciones:
Fuente: El Autor.
85
86
HISTORIA DE USUARIO
Numero: Fecha:
Usuario:
Nombre de Historia:
Guardar/Modificar Información de dispositivos.
Alta 0.8
Media 0.4
Descripción:
El Cliente solicita almacenar información de los equipos que tiene la compañía

(Computadores, Lectores de código de barras, UPS, Portátiles, entre otros).
Observaciones:
Los equipos se distinguen por una placa que la compañía le pone a cada dispositivo. La
placa es única. Existe placa nueva que es obligatoria, y la placa anterior que la tienen
algunos dispositivos.
Fuente: El Autor.
86
87
HISTORIA DE USUARIO
Numero: Fecha:
Usuario:
Nombre de Historia:
Asociar dispositivo a un responsable.
Alta 0.8
Media 0.3
Descripción:
El cliente requiere asociar un responsable a los equipos de la compañía. Al igual que

asociar una ubicación técnica al dispositivo.
Observaciones:
Del responsable se almacena el nombre y la cedula, un responsable puede tener varios

equipos a su nombre.
Fuente: El Autor.
87
88
HISTORIA DE USUARIO
Numero: Fecha:
Usuario:
Nombre de Historia:
Dar de baja a un equipo.
Alta 0.5
Media 0.3
Descripción:
El Cliente solicita llevar un registro de los equipos que se dañan, con la fecha en la que
el equipo se da de baja.
Observaciones:
Un equipo de baja no almacena ubicación técnica ni responsable.
Fuente: El Autor.
88
HISTORIA DE USUARIO
Numero: Fecha:
Usuario:
Nombre de Historia:
Almacenar historial de dispositivo.
Alta 0.7
Media 0.3
Descripción:
El Cliente requiere llevar un registro de los movimientos de equipos, es decir, un

historial de los lugares por donde ha pasado un equipo. Almacenando la fecha de
asignación a un responsable.
Observaciones:
Un equipo puede pasar por todos los lugares, como la torre empresarial, tiendas y
oficinas.
Fuente: El Autor.
89
HISTORIA DE USUARIO
Numero: Fecha:
Usuario:
Nombre de Historia:
Listar el historial de un dispositivo. (Buscar por placa nueva o antigua).
Alta 0.5
Alta 0.8
Descripción:
El cliente requiere que se pueda buscar un dispositivo por la placa, mostrando los
lugares en donde ha estado (historial del dispositivo), con el responsable y fechas en
que se ha asignado. Se quiere poder buscar por placa anterior o placa antigua.
Observaciones:
Un equipo puede pasar por la misma persona varias veces.
Fuente: El Autor.
90
HISTORIA DE USUARIO
Numero: Fecha:
Usuario:
Nombre de Historia:
Buscar historial de una persona(Buscar por cedula)
Media 0.9
Alta 0.5
Descripción:
El cliente requiere que se pueda buscar los equipos que ha tenido una persona,
mostrando fechas y datos del dispositivo que fue asignado.
Observaciones:
Se pretende buscar los dispositivos que ha tenido una persona ingresando el número de
cedula.
Fuente: El Autor.
91
HISTORIA DE USUARIO
Numero: Fecha:
Usuario:
Nombre de Historia:
Listar equipos activos
Alta 1.0
Alta 0.7
Descripción:
El Cliente quiere que se muestre un listado donde aparezcan los equipos que están
activos en el momento.
Observaciones:
Los equipos activos hacen referencia a los equipos que no están de baja.
Fuente: El Autor.
92
HISTORIA DE USUARIO
Numero: Fecha:
Usuario:
Nombre de Historia:
Listar equipos activos y diferenciar entre centros de costo, torre empresarial y oficinas
Media 1.0
Alta 0.8
Descripción:
El Cliente requiere observar en una lista los equipos activos pero diferenciados entre
Centros de costo, Torre empresarial y Oficinas.
Observaciones:
Fuente: El Autor.
93
HISTORIA DE USUARIO
Numero: Fecha:
Usuario:
Nombre de Historia:
Listar equipos que están de baja
Alta 0.8
Alta 0.5
Descripción:
El cliente quiere poder observar en una lista los equipos inactivos que existen en la
compañía.
Observaciones:
Equipos inactivos hace referencia a los equipos de baja.
Fuente: El Autor.
94
HISTORIA DE USUARIO
Numero: Fecha:
Usuario:
Nombre de Historia:
Buscar ubicación técnica por Ubicación
Media 0.9
Media 0.6
Descripción:
El cliente quiere poder verificar si existe una ubicación técnica ingresando la ubicación
en un cuadro de texto.
Observaciones:
Fuente: El Autor.
95
Anexo B – Especificación de requerimientos funcionales
Tabla 26 - Formato de especificación requerimiento R1

Especificación de requerimientos
Identificador: Nombre:
R1 Registrar/Modificar Ubicaciones Técnicas
Tipo: Crítico? Prioridad:
Necesario. Si Alta
Entrada: Salida:
Visualización de mensaje satisfactorio
Ubicación. si se registró la información en la base
Tipo de lugar. de datos.
Denominación.
Visualización de mensaje de error si se
produjo un error durante el proceso.
Descripción:
El usuario ingresa en los campos indicados la información de entrada y da clic

en el botón guardar. Automáticamente debe aparecer el mensaje de aceptación
o de error.
Manejo de errores:
Si al ingresar la información en la base de datos es rechazada la solicitud

entonces aparecerá en la pantalla un mensaje identificando el error.
Criterios de aceptación:
Si hay algún campo del formulario que es obligatorio y está sin diligenciar, al
momento de intentar almacenar la información en la base de datos, se mostrara
el siguiente mensaje: “Por favor diligencie todos los campos del registro que son
obligatorios”.
Fuente: El Autor.
96
R2 Mostrar Ubicaciones Técnicas
Necesario. Si Alta
Entrada: Salida:
Listado de los datos de las ubicaciones
Ninguna.
técnicas.
Descripción:
El usuario ingresa al módulo de directorio de ubicaciones técnicas y

automáticamente aparecerá una tabla con el listado de las ubicaciones técnicas
Manejo de errores:
Si no se puede acceder a la base de datos para realizar la consulta, aparecerá

un mensaje describiendo el error.
Ninguno.
Fuente: El Autor.
97
R3 Registrar/Modificar datos de dispositivos
Necesario. Si Alta
Entrada: Salida:
Placa nueva.
Placa anterior.
si se registró la información en la base
Marca.
de datos.
Modelo.
Serial.
Tipo.
Estado (Disponible o Baja).
Descripción:

o de error.
Manejo de errores:

obligatorios”.
Fuente: El Autor.
98
R4 Registrar/Modificar datos de un lugar
Necesario. Si Alta
Entrada: Salida:
Ubicación técnica.
Ciudad. Visualización de mensaje satisfactorio
Dirección. si se registró la información en la base
Administrador. de datos.
Extensión.
Teléfono 1. Visualización de mensaje de error si se
Teléfono 2. produjo un error durante el proceso.
Celular.
Descripción:

o de error.
Manejo de errores:

obligatorios”.
Fuente: El Autor.
99
Tabla 100 - Formato de especificación requerimiento
R100
R5 Mostrar datos de un lugar
Necesario. Si Alta
Entrada: Salida:
Ubicación técnica. Listado de los datos del lugar.
Descripción:
El usuario ingresa al módulo de directorio del tipo de lugar que desea consultar e
introducirá la ubicación técnica en el campo solicitado, después dará clic en el
botón buscar y automáticamente aparecerá en una tabla la información
solicitada.
Manejo de errores:

Ninguno.
Fuente: El Autor.
10
0
R101
R6 Registrar/Modificar datos de oficinas
Necesario. Si Alta
Entrada: Salida:
Datos del lugar. de datos.
Zona.
Descripción:

o de error.
Manejo de errores:

obligatorios”.
Fuente: El Autor.
10
1
R102
R7 Mostrar datos de oficinas
Necesario. Si Media
Entrada: Salida:
Listado con los datos de las oficinas
Ninguna.
(Datos del lugar y la zona).
Descripción:
El usuario ingresa al módulo de directorio de oficinas y automáticamente

aparecerá una tabla con el listado de las oficinas y sus respectivos datos.
Manejo de errores:

Ninguno.
Fuente: El Autor.
10
2
R103
R8 Registrar/Modificar centros de costos
Necesario. Si Alta
Entrada: Salida:
Datos del lugar. si se registró la información en la base
Nombre del centro de costo. de datos.
Cajas fijas.
Cajas temporada. Visualización de mensaje de error si se
Descripción:

o de error.
Manejo de errores:

obligatorios”.
Fuente: El Autor.
103
R104
R9 Mostrar centros de costos
Necesario. Si Media
Entrada: Salida:
Listado de los centros de costo
almacenados en la base de datos con
Ninguna. su respectiva información (datos del
lugar, nombre, cajas fijas y cajas de
temporada).
Descripción:
El usuario ingresa al módulo de directorio de centros de costo y

automáticamente aparecerá una tabla con el listado de los centros de costo con
su respectiva información.
Manejo de errores:

Ninguno.
Fuente: El Autor.
104
R105
R10 Registrar/Modificar equipos de baja
Necesario. Si Alta
Entrada: Salida:
Equipo asociado. si se registró la información en la base
Fecha de baja. de datos.
Descripción de la baja.
Descripción:

o de error.
Manejo de errores:

obligatorios”.
Fuente: El Autor.
105
R106
R11 Mostrar equipos de baja
Necesario. Si Alta
Entrada: Salida:
Listado con los equipos que están de
Ninguna. baja y su respectiva información
(equipo asociado, fecha de baja y
descripción).
Descripción:
El usuario ingresa al módulo de inventario bajas y automáticamente aparecerá

una tabla con el listado de las bajas que están registradas en la base de datos
con su respectiva información.
Manejo de errores:

Ninguno.
Fuente: El Autor.
106
R107
R12 Asociar responsables a los dispositivos
Necesario. Si Alta
Entrada: Salida:
Responsable. de datos.
Cedula.
Descripción:

o de error.
Manejo de errores:

obligatorios”.
Fuente: El Autor.
107
R108
Mostrar equipos con responsable y datos del
R13
dispositivo
Necesario. Si Alta
Entrada: Salida:
Listado de los equipos con su
Ninguna.
respectiva información.
Descripción:
El usuario ingresa al módulo de inventario y automáticamente aparecerá una

tabla con el listado de los equipos y responsables de cada uno.
Manejo de errores:

Ninguno.
Fuente: El Autor.
108
R109
R14 Mostrar historial de dispositivos
Necesario. Si Media
Entrada: Salida:
Listado de los datos asociados a la
Placa nueva.
placa ingresada.
Descripción:
El usuario ingresa al módulo de inventario historial y automáticamente aparecerá

una tabla con el listado de las ubicaciones técnicas
Manejo de errores:

Ninguno.
Fuente: El Autor.
109
R110
R15 Mostrar historial asociados a un responsable
Necesario. Si Media
Entrada: Salida:
Equipos asociados a la cedula
Cedula del responsable.
ingresada con sus respectivos datos.
Descripción:
El usuario ingresa al módulo de inventario historial e ingresara los datos de

entrada en los campos identificados y automáticamente aparecerá una tabla con
el listado de los equipos que han estado asociados a la cedula digitada.
Manejo de errores:

Ninguno.
Fuente: El Autor.
110
R111
Cambiar estado de asignación del equipo cuando
R16
cambia de responsable o se da de baja.
Necesario Si Alta
Entrada: Salida:
Responsable. de datos.
Cedula.
Descripción:

o de error.
Manejo de errores:

obligatorios”.
Fuente: El Autor.
111
Anexo C – Mockups del proyecto sistema de inventario para la empresa
Arturo Calle SAS
Figura 35 - Mockup página de inicio
Fuente: El Autor.
Figura 36 - Mockup directorio ubicaciones tecnicas
Fuente: El Autor.
112
Figura 37 - Mockup directorio centros de costo
Fuente: El Autor.
Figura 38 - Mockup directorio oficinas
Fuente: El Autor.
113
Figura 39 - Mockup inventario centros de costo
Fuente: El Autor.
Figura 40 - Mockup inventario oficinas
Fuente: El Autor.
114
Figura 41 - Mockup inventario torre empresarial
Fuente: El Autor.
Figura 42 - Mockup inventario bajas
Fuente: El Autor.
115
Figura 43 - Mockup inventario historial
Fuente: El Autor.
116
Anexo D – Diagrama Relacional del sistema de inventario para la
empresa Arturo Calle SAS
Figura 44 - Diagrama relacional del sistema de inventario
Fuente: El Autor.
117
Anexo E – Diagrama de Clases del sistema de inventario para la
empresa Arturo Calle SAS
Para una mejor visualización del diagrama, a continuación se muestran las clases
sin atributos ni funciones y después el diagrama completo.
Figura 45 - Fragmento Diagrama de clases
Fuente: El Autor.
118
Figura 46 – Diagrama de clases sistema de inventario
Fuente: El Autor.
119
Anexo F – Manual de ejecución del aplicativo
1. Requerimientos de Hardware.
Para la ejecución del proyecto se puede implementar en casi cualquier

computador que tenga suficiente rendimiento, disponibilidad y seguridad y cuenten
con los siguientes requisitos como mínimo:
 Mínimo 4 GB de RAM.
 80 GB de espacio libre en disco y 1 GB para la instalación del Servidor.
 Debe contar con mínimo 2 Core en procesador.
2. Requerimientos de Software.
Para la ejecución del servidor es necesario:

 Windows 7/8.
 Java JDK 7 o Superior.
 GlassFish Server 4.1.2 o Superior.
 MySQL Server 5 o Superior.
 Netbeans IDE 8.1 o superior.
3. Configuración del Ambiente de Instalación.
Para poder realizar la ejecución del servidor se debe tener una Base de Datos
creada previamente en MySql. El script de la base de datos se encuentra adjunto
en el CD del proyecto.
3.1. Ingresar a Workbench de MySql, ingresar a Local instance

MySQL y digitar la clave del root o de la conexión que se requiera.
120
3.2. Ingresar y ejecutar el script de la Base de
Datos.
4. Ejecución del Servidor
4.1. Ingresar a Netbeans y abrir el proyecto sistemaDeInventarioAC (adjunto

en el cd del proyecto).
121
4.2. Dar clic derecho sobre el proyecto y escoger la opción “ejecutar”.
122
4.3. Se abrirá una página en internet con el enlace
localhost:8080/sistemaDeInventarioAC/invTorreEmpresarial.xhtml.
123
Anexo G – Manual de usuario del aplicativo
1. Requisitos tecnológicos para acceder al aplicativo.
Para poder ingresar al aplicativo se debe tener conexión al servidor. Se

puede ingresar a través de los siguientes navegadores teniendo en cuenta
la versión de estos.
Google Chrome 29.x o superior.
Internet Explorer 11 o superior.
Mozilla Firefox 22.x o superior.
2. Ingreso al sitio web.
Para ingresar a la página principal de la aplicación desde el mismo

computador donde está el dominio se debe escribir la siguiente dirección:
localhost:8080/SistemaDeInventarioAC/inicio.xhtml y aparecerá la página
de inicio como se muestra en la siguiente imagen:
Para acceder desde otro computador que no sea el servidor se debe

escribir en el navegador la dirección anterior cambiando el localhost por la
dirección ip del servidor.
3. Módulo inventario.
3.1. Registro dispositivos. Seleccionar el tipo de lugar donde se

encuentra el dispositivo en el menú de inventario en la parte
izquierda de la página (1).
Diligenciar los campos de texto. La ubicación técnica que se va a digitar

ya debe estar registrada con anterioridad. El campo de observaciones
no es obligatorio (2).
124
Dar clic en el botón guardar. Si el la placa digitada ya se encuentra
almacenada o la ubicación técnica no existe aparecerá un mensaje de
error (3).
3.2. Registro Bajas. Seleccionar la opción de bajas en el menú

de inventario en la parte izquierda de la página (1).

y la placa ya deben estar registradas con anterioridad. El campo de
observaciones no es obligatorio (2).
Dar clic en el botón guardar. Si el la placa digitada no se encuentra

almacenada o la ubicación técnica no existe aparecerá un mensaje de
error (3).
125
3.3. Historial de dispositivos. Seleccionar la opción de historial en el
menú de inventario en la parte izquierda de la página (1).
En el campo “Lugar” seleccionar el tipo de lugar donde se quiere hacer

el filtro de búsqueda (2). Diligenciar los campos de texto según la
consulta que se requiera, ya sea buscar por la placa nueva, cedula,
Responsable o placa anterior (3).
Dar clic en el botón consultar (4). Los datos de la consulta aparecerán

en la tabla de la parte central-inferior de la página. Si no se encuentra
información aparecerá un mensaje diciendo que no hay datos para la
consulta actual.
126
4. Modulo directorio
4.1. Registro/Consulta ubicaciones técnicas. Seleccionar la opción

de Ubicaciones técnicas en el menú de directorio en la parte izquierda
de la página.
En el campo “Tipo Lugar” seleccionar el tipo de lugar donde está la

ubicación técnica. Diligenciar los campos de texto según la consulta que
se requiera. Si se quiere almacenar la ubicación se deben completar
todos los campos de texto.
Dar clic en el botón Consultar Por Ubicación, Consultar Por Tipo de

Lugar, Listar todo o guardar según sea el caso. Los datos de la consulta
aparecerán en la tabla de la parte central-inferior de la página. Si se va a
guardar una ubicación técnica aparecerá la información en la tabla.
127
4.2. Registro/Consulta oficinas. Seleccionar la opción de Oficinas
en el menú de directorio en la parte izquierda de la página (1).

ya debe estar registrada con anterioridad. El campo de telefono2 no es
obligatorio (2).
Dar clic en el botón Guardar para almacenar la información diligenciada;

Consultar por zona para traer los registros que existan con la zona
diligenciada; Listar todo para mostrar todas las oficinas almacenadas en
el sistema (3). Los datos aparecerán en la tabla de la parte central-
inferior de la página.
128
4.3. Registro/Consulta centros de costo. Seleccionar la opción de
Centros de Costo en el menú de directorio en la parte izquierda de la
página (1).

ya debe estar registrada con anterioridad. El campo de telefono2 no es
obligatorio (2).
Dar clic en el botón Guardar para almacenar la información diligenciada;

Consultar por Centro de Costo para traer los registros que existan con el
centro de costo diligenciado; Listar todo para mostrar todos los centros
de costo almacenados en el sistema (3). Los datos aparecerán en la
tabla de la parte central-inferior de la página.
129

Documento Trabajo Degr A Do

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Documento Trabajo Degr A Do

Uploaded by

Copyright:

Available Formats

IMPLEMENTACIÓN DE UN SISTEMA DE INVENTARIOS PARA EL ÁREA DE

SOPORTE TÉCNICO EN LA EMPRESA COMERCIALIZADORA ARTURO

DAVID GUILLERMO LATORRE PELAEZ

UNIVERSIDAD CATÓLICA DE COLOMBIA

DAVID GUILLERMO LATORRE PELAEZ

Trabajo de grado para optar al título

UNIVERSIDAD CATÓLICA DE COLOMBIA

Agradezco a Dios y la Virgen María

Aprobado por el comité de grado en

Director de Trabajo de Grado

Bogotá D.C., Mayo de 2017

Tabla 1 - Roles XP y Funciones 27

Figura 1- Comparación Ciclos de Desarrollo 25

BASE DE DATOS: Herramienta para recopilar y organizar información. Las bases

EXTREME PROGRAMMING: Es un enfoque de la ingeniería de software

GLASSFISH: Servidor compatible con la plataforma Java EE 5 para el desarrollo y

JAVA: Es un lenguaje de programación y una plataforma informática

MOCKUP: Fotomontajes que permiten a los diseñadores gráficos y web mostrar al

MYSQL: Motor de base de datos de código abierto. Es multi-hilo y multi-usuario. 6

NETBEANS IDE: Entorno de desarrollo integrado (IDE), modular, de base

REQUERIMIENTOS FUNCIONALES: Descripción de la interacción entre el

REQUERIMIENTOS NO FUNCIONALES: Son requisitos que imponen

Este documento presenta la implementación de un sistema de inventarios

Palabras clave: Diseño de sistemas, inventario, sistema de información, software.

This document presents the implementation of an inventory system that was

Keywords: Systems design, inventory, information system, software.

En la actualidad las aplicaciones tecnológicas y el software inteligente juegan un

El activo más importante de una empresa es la información, por lo cual en los

En la empresa Comercializadora Arturo Calle S.A.S. se llevan los registros de

En la primera etapa del proyecto se definen los requerimientos necesarios para

Según la Sociedad Americana de la Producción y el Control de Inventarios

A través del tiempo el término de Inventarios ha venido creciendo para llevar

Dados los inconvenientes encontrados en la forma que se lleva actualmente el

1.2. PLANTEAMIENTO DEL PROBLEMA

1.2.1. Descripción del problema.

Actualmente en la empresa Arturo Calle S.A.S se lleva un control de los

Los datos de los dispositivos electrónicos son utilizados en la gestión de

1.2.2. Formulación del problema.

¿Cómo implementar un aplicativo para el registro y control de inventario de

1.3.1. Objetivo general.

Implementar un sistema de inventario en la empresa Comercializadora Arturo

1.3.2. Objetivos Específicos.

 Seleccionar la metodología de desarrollo para la construcción del software.

 Determinar los requerimientos funcionales y no funcionales para

 Diseñar el sistema de inventario para precisar la arquitectura y diagramas

 Desarrollar el sistema de inventario para apoyar la gestión de incidencias

Cuando las empresas necesitan realizar adecuaciones que involucren exponer la

Según Jack Fleitman en el artículo “La Importancia De Los Sistemas De

“Las empresas deben tener modernos sistemas de información,

Asimismo, los directivos y los mandos medios de las empresas muchas

1.5.1. Espacio. El actual proyecto se limitará a la Torre Empresarial de Arturo

1.5.2. Tiempo. El periodo de desarrollo del proyecto es a partir del 11 de enero

1.5.3. Contenido. El análisis del proyecto se hará a través de la información

 El actual proyecto no pretende ser un sistema para la gestión de

 El presente proyecto pretende el diseño e implementación de un sistema

 El presente sistema no pretende realizar procesos de minería de datos

1.6.1. Marco Teórico.

El actual proyecto sigue la teoría reduccionista de la teoría general de sistemas, la

1.6.2.1. Sistema de Información. Conjunto de componentes interrelacionados

 Generar información confiable y tener el control del sistema.

 Analizar la información a través de indicadores para detectar

 Tener la posibilidad de planear e idear proyectos, los cuales van a

 Sistematizar la información, ya que manualmente aumenta los