1

UNIVERSIDAD DE LAS AMÉRICAS

PRESENTACIÓN DE PROYECTO DE TÍTULO

Gestor de permanencia

Profesor: Mauricio Andrés Hormazabal Benítez

Estudiante: Paulo César Bolívar Jofré

NOVIEMBRE– 2018
SANTIAGO DE CHILE
 2

Temario

CAPITULO I: ASPECTOS DE LA EMPRESA

1.1 Antecedentes de la Empresa.

1.2 Organigrama.
1.3 Área funcional
1.4 Descripción del Proceso a intervenir. (BPMN).

CAPITULO II SITUACIÓN ACTUAL DEL PROYECTO

2.1 Descripción de la Situación Actual.

2.2 Descripción del Problema.
2.3 Propósito del proyecto.
2.4 Estado del Arte.
2.5 Solución Planteada.
2.6 Alcances y restricciones.

CAPITULO III PLANTEAMIENTO DE OBJETIVOS

3.1 General.
3.2 Específicos.

CAPITULO IV ESTUDIO DE FACTIBILIDAD Y GESTIÓN DE RIESGOS

4.1 Estudio de Factibilidad.
4.1.1Factibilidad Técnica.
4.1.2 Análisis costo beneficio a un año.
4.1.3 Factibilidad Operacional.
4.1.4 Factibilidad Legal.
4.2 Identificación de Riesgos.
4.2.1 Riesgos de Planeación
4.2.2 Riesgos de Desarrollo.
4.2.3 Riesgos del Cliente.
4.2.4 Riesgos de Implementación.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 3

CAPITULO V PLANTEAMIENTO DE LA SOLUCION

5.1 Análisis de la Solución

5.1.1 Descripción solución propuesta en detalle.
5.1.2 Evaluación de Herramientas de desarrollo e Implementación.
5.1.3 Diagrama de Arquitectura de Solución Propuesta.
5.1.4 Diagrama proceso mejorado. (BPMN)
5.2 Metodología aplicada
5.2.1 Comparativa de metodologías asociadas al proyecto.
5.2.2 Justificación de la metodología la seleccionada.
5.2.3 Metodología de Administración.
5.2.4 Carta Gantt.
5.3 Obtención de Requerimientos
5.3.1 Metodología Aplicada a la Toma de Requerimientos.
5.3.2 Requerimientos Funcionales.
5.3.3 Requerimientos No Funcionales.
5.3.4 Requerimientos de Seguridad.
5.3.5 Requerimientos de Mantención.
5.3.6 Especificación de requerimiento.

CAPITULO VI DISEÑO DEL SISTEMA

6.1. Modelamiento UML

6.1.1 Diagrama Casos de Usos.
6.1.2 Documentación Casos de Uso.
6.1.3 Diagrama de Componentes.
6.2 Modelo Entidad Relación / Modelo de Datos.

CAPITULO VII CONSTRUCCIÓN DE PROTOTIPO FUNCIONAL

CAPITULO VIII: DISEÑOS DE PRUEBAS DEL SOFTWARE

CAPITULO IX CONCLUSIONES DEL PROYECTO

9.1 Conclusiones.
9.2 Perspectivas Futuras.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 4

Introducción

“Bci Seguros se define como una empresa de seguros orientada a personas y pymes, que
busca superar las expectativas de sus clientes, basada en la innovación, calidad, cercanía,
excelencia, omnicanalidad y eficiencia, con un elevado compromiso de sus colaboradores y
un robusto soporte tecnológico, estableciendo prudentes políticas de gestión de riesgo y
altos”. (Bci Seguros, 2017)

Cuenta con casi 900 trabajadores, en jornadas de 42,5 horas semanales, donde todas las
áreas pueden solicitar trabajos fuera de hora, principalmente con pago de horas extras.

Bajo este escenario y al no existir un sistema de gestión de permanencias, con una carga
excesiva en el manejo de formularios en papel, el presente proyecto busca entregar una
solución tecnológica que entregue visibilidad del gasto de movilización, colación y horas
extras que se llevan a cabo en la actualidad.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 5

CAPITULO I: ASPECTOS DE LA EMPRESA

1.1 Antecedentes de la Empresa.

Bci Seguros se define como una empresa de seguros orientada a personas y pymes,
que busca superar las expectativas de sus clientes, basada en la innovación, calidad,
cercanía, excelencia, omnicanalidad y eficiencia, con un elevado compromiso de sus
colaboradores y un robusto soporte tecnológico, estableciendo prudentes políticas de
gestión de riesgo y altos.
Cuenta con casi 900 trabajadores, en jornadas de 42,5 horas semanales, donde todas
las áreas pueden solicitar trabajos fuera de hora, principalmente con pago de horas
extras.

1.2 Organigrama.

La compañía se divide en 3 empresas relacionadas, bajo el paraguas de BCI.

En la figura 1.1, se presenta el resumen de la planta aprobada, al mes de agosto 2018.

En la figura 1.2, se presentan las áreas funcionales de la compañía, bajo la

dependencia de la Gerencia General, a modo de organigrama resumen.

En la figura 1.3, se el organigrama de la Gerencia De Personas y Administración, como

usuarios principales de la solución.

Figura 1.1: planta aprobada de Bci Seguros a agosto 2018, para las 3 empresas que
conforman la compañía.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 6

1.3 Área funcional

En la actualidad, la compañía cuenta con 8 áreas funcionales, dependientes del

Gerente General.
Las 8 son generadores de trabajos fuera de hora, por lo que eventualmente son los
potenciales usuarios.
Se marca de manera especial la Gerencia de Administración, Finanzas y Gestión de
Personas, ya que es el área de Administración, la encargada de los gastos de las
permanencias.

En la figura 1.2, se presentan las áreas funcionales de la compañía, bajo la

dependencia de la Gerencia General y el área específica que será el cliente.

Figura 1.2: áreas funcionales de la compañía.

Figura 1.3: Detalle del organigrama del área de administración y compensaciones.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 7

1.4 Descripción del Proceso a intervenir. (BPMN).

El proceso actual en la gestión de una permanencia, consta de 3 partes:

• Revisión de solicitud de permanencia

• Revisión de aprobaciones
• Revisión de gastos

Donde en el primer punto, se efectúan todas las revisiones asociadas a la necesidad

de cubrir tareas en horas extras. En esto se incluye la revisión de las tareas a realizar,
la revisión de personal disponible, la revisión de los horarios por cubrir y la revisión de
las necesidades de movilización posterior y colaciones.

En el segundo punto, se efectúan todas las revisiones (una vez aprobado el punto
anterior) de las aprobaciones, para que la permanencia se lleve a cabo. En esto se
incluye la creación del formulario de permanencia, la revisión de este por la jefatura y
su aprobación, y, por último, la entrega del formulario firmado al área de
administración.

En el tercer punto, se efectúan todas tareas posteriores a la actividad, donde el área

de administración revisa los modelos de gastos y revisa los cumplimientos por ítem,
según presupuesto; efectúa un análisis por gerencia (cuando se puede) y por último
efectúa un análisis de los gastos en movilización y colaciones.

En la figura 1.4, se presentan las tareas por nivel, según la lógica de los pasos de un
proceso de la gestión de permanencias.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 8

Figura 1.4: BPMN para la gestión de permanencias.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 9

CAPITULO II SITUACIÓN ACTUAL DEL PROYECTO

2.1 Descripción de la Situación Actual.

Para los colaboradores que efectúan horas extras, se debe completar formulario en
papel denominado “solicitud de permanencia”, donde el trabajador indica el horario en
el cual se desarrollará la actividad, el detalle de la tarea, si es necesario colación o
movilización, si al término de la jornada no se cuenta con trasporte público.
En la actualidad la compañía gasta cerca de UF 6.000 por ambos ítems, y el concepto
de las tareas efectuadas fuera de horario normal son desconocidos, así como las
áreas que lo generan.

Una vez que se ha generado la solicitud, cada Jefe autorizado debe imprimir un
formulario, completarlo y firmarlo, pero sin visión del gasto acumulado.

Los formularios deben ser entregados al área de administración, los cuales, a su vez,
revisan los modelos de gastos y revisa los cumplimientos por ítem, según
presupuesto; efectúa un análisis por gerencia (cuando se puede) y por último efectúa
un análisis de los gastos en movilización y colaciones

2.2 Descripción del Problema.

Existe gestión de formularios de permanencias en papel, con una carga excesiva en

el manejo de formularios y se desconoce el motivo del trabajo fuera de hora. Esto se
traduce en gasto excesivo de papel, tóner e implementos de oficina; así como también,
en nulo control de gasto de traslados y colaciones en este rango horario.

2.3 Propósito del proyecto.

Crear un sistema de gestión de permanencias automatizado, disminuyendo la carga

excesiva en el manejo de formularios en papel y permitiendo, a través del módulo de
reporte, dar a conocer los motivos de solicitudes por usuario y por área.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 10

2.4 Estado del Arte.

¿Cómo hacen hoy las empresas, para eliminar la carga excesiva en el manejo de
formularios en papel y conocer los motivos de solicitudes por usuario y por área y el
gasto por cada ítem?

Desde el punto de las áreas de recursos humanos, las mejores prácticas apuntan a
que el trabajador pueda efectuar las tareas en el horario normal y apuntan a gestionar
las labores para cumplir con las leyes que aplican para estas tareas.
Desde este punto de vista, los desarrollos de sistemas de control, apuntan a entregar
a la empresa diversas opciones para responder a la pregunta original. El punto que
sigue, es como llevarlo a la realidad de cada organización y es acá donde está el
desafío.

En la actualidad, las empresas líderes del rubro en administración de empresas y de

recursos humanos en el mercado chileno, consideran que el uso de suites de
administración y módulos independientes (que se conectan al sistema actual de la
empresa), permiten controlar de forma mucho más eficiente y bajo la normativa,
gestión de las horas extras y el detalle de estas.

Como ejemplo tenemos:

- ADP Payroll, con su módulo de asistencia, el cual permite a la empresa que
administre y controle horas extras y permisos, con goce o sin goce de sueldo con
fórmulas y variables para cálculos sobre marcas y atrasos.
[Link]

- Contaex, con su suite de soluciones administrativas, el cual permite realizar las

distintas tareas de apoyo a la operación, como Facturación, Tesorería, Trámites,
Logística, Cobranza, Back Office. Esto gracias a los modelos de integración que
ofrece, con los sistemas que tenga la empresa.
[Link]

- Wiseplan, con su suite Outsourcing Remuneraciones, el cual entrega un portal de

autoservicio para el uso de los colaboradores, conexión en línea y acceso a
reportes y estadísticas a medida.
[Link]
VHRslK6moEuPKcds6y1Kk2V9tNCH5MyzF5fIW1H4aAhw_EALw_wcB

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 11

2.5 Solución Planteada.

Desarrollar un sistema web con [Link] y un manejo de base de datos en MySQL,

que entregue una interfaz de solicitud de permanencias para el trabajador, con una
interfaz de aprobación para las jefaturas y una interfaz de reportes, para el área de
administración.

2.6 Alcances y restricciones.

Alcances:

El proyecto busca contribuir a un proceso que hoy es manual y en papel, lo cual

presenta en sí mismo problemas de control de gastos.

En detalle:
• Conocer la desviación del presupuesto de horas extras.
• Controlar el cumplimiento legal, con respecto a este ítem.
• Disminuir los costos fijos anuales como mínimo en un 5% por compra de: Papel,
tóner, ganchos, carpetas y otros ítems incluidos en el inventario como
papelería, comunicaciones y fotocopias.
• Generar un reporte de control del flujo horas extras por trabajador, uso de taxi
y colación por periodo y área.
• Generar un reporte que entregue visibilidad del movimiento de horas, para la
carga de estas en el sistema de pago de remuneraciones.

Restricciones:

• No contempla integración con el sistema de remuneraciones.

• No contemple cruce de información de horas extras o rescate de estas.
• El costo de la implementación, si bien no es mayor (como se indica en el análisis
de factibilidad técnica), se debe considerar dentro del presupuesto de la
compañía y la reutilización de software ya licenciado.
• Los plazos de implementación, si bien son acotados, pudieran presentar retraso
en caso de problemas de presupuesto o disponibilidad de servidores.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 12

CAPITULO III PLANTEAMIENTO DE OBJETIVOS

3.1 General.

Implementar una plataforma web con perfil de ingreso, que permita la gestión, control
y automatización del ingreso de las solicitudes de permanecías, fuera del horario
normal para la compañía Bci Seguros.

3.2 Específicos.

• Digitalizar el registro de actividades, horarios, colaciones y movilización.

• Entregar la capacidad para que cada colaborador ingrese su solicitud en el
sistema.
• Validar las solicitudes según cada Jefe.
• Generar un resumen de las solicitudes y gastos de colación, para el área de
administración.
• Generar un resumen de las solicitudes y gastos de movilización, para el área
de administración.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 13

CAPITULO IV ESTUDIO DE FACTIBILIDAD Y GESTIÓN DE RIESGOS

4.1 Estudio de Factibilidad.

4.1.1Factibilidad Técnica.

Dentro de este estudio puede evaluarse la posibilidad del sistema frente a aspectos
como función, rendimiento y restricciones de los cuales se puede decir que hacen al
proyecto factible. Para esto, se debe considerar que la combinación de software y
hardware adjunta, entregan el mejor desempeño a la hora de solicitar y validar el
ingreso al sistema, la validación contra la base de datos y los tiempos de ejecución.

El sistema permitirá cumplir todas las actividades especificadas ya que cuenta con
herramientas de hardware y software como lo son:

Hardware:
2 equipos con 2T de disco duro, 8gb de memoria RAM y procesador I7.
Para el proyecto, la solución se considerará como servicio, por lo que este
requerimiento de hardware dependerá de lo que se pida en el hosting.

Software:
[Link]
MySQL

Herramientas que permiten la ejecución de un proyecto con las características

requeridas y no contradice leyes establecidas para la realización de un sistema como
el solicitado.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 14

4.1.2 Análisis costo beneficio a un año.

Como el proyecto se desarrollará dentro de la empresa, la cual ya está en

funcionamiento, solo se considerará los costos adicionales que se adjuntan en la tabla
4.1.

Tabla 4.1: Costos directos

Cargo Tiempo Sueldo Total

Director de proyecto 2 meses $3.000.000 $6.000.000
Ingeniero de desarrollo 2 meses $3.000.000 $6.000.000
Auxiliar de pruebas. 2 días NA NA
Auxiliar de capacitación. 2 días NA NA
Auxiliar de soporte. 1 día NA NA
Total $12.000.000

Servicio Tiempo Valor Total

Hosting 1 año $20.000 $20.000
Dominio 1 año $10.000 $10.000
Visual Studio 2017 PE Perpetua $453.219 $453.219
Total $483.219

Costo totales $12.483.219

En conclusión, los costos incurridos en el desarrollo de proyecto, considerando las

horas de trabajo y la inversión en software de desarrollo, hosting y dominio, se calculan
por un valor de $12.483.219.
El principal beneficio del proyecto considera el aporte en el control y gestión de los
gastos por permanencia, pudiendo identificar los motivos y las áreas que generan los
gasto.
De paso, considera rebajar en un 5% el presupuesto anual de gastos por papelería,
el cual bordea los $10.000.000.
En este sentido, se puede indicar que solo por el concepto de “paperless”, en el primer
año se queda a un 83% de break even.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 15

4.1.3 Factibilidad Operacional.

Para el desarrollo de una herramienta de registro de solicitudes y gestión de

permanencias se requiere las siguientes características en el personal y en la
empresa, como se muestra en la en la tabla 4.2.

Tabla 4.2: características en el personal y en la empresa para factibilidad operacional.

Cargo Perfil Roles

Director de proyecto Un Ingeniero de sistemas Gestor de proyectos: planea,
líder experto en manejo de gestiona y asigna recursos,
recursos tecnológicos y forma prioridades, coordina
humanos, capacidad de interacciones con clientes y
resolución de problemas. usuarios y mantiene
centrado al equipo de
proyecto.
Revisor de gestión: evalúa la
planificación del proyecto y
los productos de trabajo de
valoración del proyecto en
puntos de revisión
importantes del ciclo vital del
proyecto.
Ingeniero de desarrollo y Un Ingeniero de Sistemas Arquitecto de software:
Soporte con experiencia en incluye la promoción y la
desarrollo de software sobre creación de soporte para las
php o .net ymotor de bases decisiones técnicas claves
de datos SQL o MySql que restringen el diseño
global y la Implementación
para proyecto
Diseñador : dirige el diseño
de una parte del sistema,
dentro de las restricciones de
los requisitos, arquitectura y
proceso de desarrollo para el
proyecto.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 16

Diseñador de base de datos:

dirige el diseño de la
estructura de
almacenamiento de datos
persistentes que se utilizaran
en el sistema.
Diseñador de interfaz de
usuario:
coordina el diseño de la
interfaz de usuario. Esto
incluye recopilar los
requisitos de utilización y los
diseños de interfaz de
usuario candidata a la
creación de prototipos para
cumplir estos requisitos.
Implementador: desarrolla
los componentes de
software y efectúa las
pruebas de
desarrollado para la
integración en subsistemas
mas grandes
Integrador: dirige la
planificación y la ejecución
de la integración del
elemento de implementaron
para producir compilaciones.
Administrador del sistema:
mantiene la infraestructura
de desarrollo de hardware y
software (instalación,
configuración y copias de
seguridad)

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 17

Auxiliar de pruebas y Pesonal calificado del area de Gestor de pruebas: Dirige el

capacitación. administración, para la esfuerzo de prueba global.
obtención de reportes. Incluye el apoyo de calidad,
Auxiliar del area de la planificación, gestión de
compensaciones, para recursos y la resolución de
revisar el marco legal. cuestiones que impiden el
Auxiliar de soporte tecnico, esfuerzo de prueba.
para conocer el acceso y Analista de pruebas:
creación, mantención de identifica y define las
usuarios. pruebas necesarias,
supervisa el proceso de
pruebas, evalúa los
resultados y lacalidad global.
Diseñador de pruebas: dirige
la definición del enfoque de
pruebas y garantiza la
Implementación
satisfactoria.
Capacitador: se encarga de
transmitir el conocimiento
especifico sobre el software
desarrollado a los diferentes
actores que intercalan con la
herramienta.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 18

4.1.4 Factibilidad Legal.

Según la dirección del trabajo, en los artículos publicados en su sitio web, indicamos
que:
• Todo trabajador tiene derecho al pago de horas extras, ya que está establecido
expresamente que las horas extraordinarias de los dependientes que no tengan
convenido un sueldo, circunstancia que acontece cuando el trabajador tiene
remuneraciones variables, se calculan sobre el valor del ingreso mínimo
mensual. Es del caso señalar que para que un trabajador con remuneraciones
variables pueda tener derecho al pago de horas extraordinarias, tiene que tener
convenido en su respectivo contrato el cumplimiento de una jornada ordinaria
de trabajo, la cual conforme a lo dispuesto en el artículo 22 del Código del
Trabajo no puede exceder de 45 horas semanales, con un máximo de 10 horas
semanales.
[Link]

• Sobre el registro de las horas extras, cumplir con lo establecido en el artículo

33 del Código del Trabajo, el empleador se encuentra obligado a llevar un
registro para controlar la asistencia y horas trabajadas de los trabajadores,
registro que puede consistir en un libro de asistencia o un reloj control con
tarjeta de registro. También se puede llevar un registro electrónico-
computacional en que el trabajador utilice una tarjeta con cinta magnética,
siempre y cuando el dispositivo cuente con un visor que haga visible los datos
que registra o una hoja de comprobación que deje oportuna constancia de ellos
o un sistema computacional de control biométrico por impresión dactilar,
sistema que la Dirección del Trabajo lo hace asimilable a un reloj control.
[Link]

En resumen, el sistema debe alinearse con las normas legales de registro y pago de horas
extras.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 19

4.2 Identificación de Riesgos.

4.2.1 Riesgos de Planeación:

• Falta de información al momento del análisis del problema.

• Insuficiente capacitación a los usuarios finales.

Impacto:
• No se puede definir correctamente el alcance del proyecto.

Plan de mitigación:
• Buscar toda la información posible al momento de efectuar el análisis de
requerimientos.
• Diseñar un plan Capacitación de los funcionarios.
• Diseñar manuales y ayudas auxiliares que permitan a los usuarios finales
conocer la herramienta.
Plan de contingencia:
• Reunir expertos en el tema de horas extras y permanencias, para definir la
funcionalidad que esperan obtener de la herramienta.

4.2.2 Riesgos de Desarrollo.

• Desconocimiento de las tecnologías más apropiadas para la implementación

más eficiente de la solución.
• No contar con Hosting, para disponibilizar el aplicativo y base de datos.

Impacto:
• Deficiencia en la toma de decisiones. Aumenta los tiempos y el costo del
proyecto

Plan de mitigación:
• Buscar toda la información posible al momento de efectuar el análisis de
requerimientos.
• Diseñar un plan Capacitación de los funcionarios.
• Diseñar manuales y ayudas auxiliares que permitan a los usuarios finales
conocer la herramienta.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 20

Plan de contingencia:

• Adquisición inmediata de la herramienta que cumpla con las condiciones

requeridas.

4.2.3 Riesgos del Cliente.

• Falta de conocimiento del cliente, en el uso de nuevas tecnologías.

• Resistencia al cambio por parte de los usuarios finales
• Falta de disponibilidad por parte del Cliente, para participar en reuniones de
levantamiento y pruebas.
• Cliente no aprueba reportes generados.

Impacto:
• Afectaría los resultados en el uso de la herramienta.
• Pérdida de imagen y credibilidad en la herramienta.
• Demoras en la implementación de la herramienta por falta del recurso
capacitado.

Plan de mitigación:
• Diseñar un plan Capacitación de los funcionarios en herramientas tecnológicas.
• Diseñar manuales y ayudas auxiliares que permitan a los usuarios finales
conocer la herramienta.
• Diseñar un plan Capacitación de los funcionarios.

Plan de contingencia:
• Realizar de inmediato talleres de capacitación intensiva.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 21

4.2.4 Riesgos de Implementación.

• Desconocimiento de leyes laborales, con respecto a horas extras.

• Elección incorrecta de herramientas de desarrollo

En la Tabla 4.3 se aprecia la matriz de riesgos, con su probabilidad de ocurrencia, impacto,

nivel de riesgo y la estrategia a seguir.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 22

Tabla 4.3: Matriz de riesgos.

Nivel de Impacto Plan de mitigación Plan de

Código Riesgo Probabilidad Impacto Riesgo Estrategia contingencia

T1 Desarrollar una Buscar toda la Reunir expertos en

Desconocimiento de leyes herramientas que esté información posible el tema de horas
laborales, con respecto a horas 1 4 Medio mitigar al margen de la ley al momento de extras y
extras. laboral. efectuar el análisis permanencias.
de requerimientos.

T2 Afectaría los resultados Diseñar un plan Realizar de

en el uso de la Capacitación de los inmediato talleres
herramienta. funcionarios en de capacitación
Pérdida de imagen y herramientas intensiva.
credibilidad en la tecnológicas.
herramienta. Diseñar manuales y
Falta de conocimiento del
Demoras en la ayudas auxiliares
cliente, en el uso de nuevas 1 4 bajo Mitigar
implementación de la que permitan a los
tecnologías.
herramienta por falta usuarios finales
del recurso capacitado conocer la
herramienta.
Diseñar un plan
Capacitación de los
funcionarios.

T3 No se puede definir Buscar toda la Reunir expertos en

Falta de información al
correctamente el información posible el tema de horas
momento del análisis del 2 5 Medio Mitigar
alcance del proyecto al momento de extras y
problema.
efectuar el análisis permanencias.
 23

de requerimientos.
Diseñar un plan
Capacitación de los
funcionarios.
Diseñar manuales y
ayudas auxiliares
que permitan a los
usuarios finales
conocer la
herramienta.

T4 Afectaría los resultados Diseñar manuales y Realizar de

Falta de disponibilidad por en el uso de la ayudas auxiliares inmediato talleres
parte del Cliente, para herramienta. que permitan a los de capacitación
3 3 Medio Mitigar
participar en reuniones de usuarios finales intensiva.
levantamiento y pruebas. conocer la
herramienta

T5 Pérdida de imagen y Reunir al equipo de Rehacer los

credibilidad en la administración y requerimientos de
Cliente no aprueba reportes herramienta. generar una informes.
3 3 Medio Mitigar
generados. Demoras en la capacitación en
implementación de la base a los
herramienta. requerimientos.

T6 Pérdida de imagen y Diseñar un plan Realizar de

Insuficiente capacitación a los credibilidad en la Capacitación de los inmediato talleres
3 3 grave Mitigar
usuarios finales herramienta. funcionarios en de capacitación
Demoras en la herramientas intensiva

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 24

implementación de la tecnológicas.
herramienta por falta Diseñar manuales y
del recurso capacitado ayudas auxiliares
que permitan a los
usuarios finales
conocer la
herramienta.
Diseñar un plan
Capacitación de los
funcionarios.

T7 Pérdida de imagen y Diseñar un plan Realizar de

credibilidad en la Capacitación de los inmediato talleres
herramienta. funcionarios en de capacitación
Demoras en la herramientas intensiva.
implementación de la tecnológicas.
herramienta por falta Diseñar manuales y
del recurso capacitado ayudas auxiliares
Resistencia al cambio por parte
que permitan a los
de los usuarios 3 3 grave Mitigar
usuarios finales
Finales
conocer la
herramienta.
Diseñar un plan
Capacitación de los
funcionarios.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 25

T8 Deficiencia en la toma Buscar toda la Adquisición

de decisiones. Aumenta información posible inmediata de la
los tiempos y el costo al momento de herramienta que
del proyecto efectuar el análisis cumpla con las
de requerimientos. condiciones
Diseñar un plan requeridas.
Elección incorrecta de Capacitación de los
3 3 medio Mitigar
herramientas de desarrollo funcionarios.
Diseñar manuales y
ayudas auxiliares
que permitan a los
usuarios finales
conocer la
herramienta.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 26

5.1 Análisis de la Solución

5.1.1 Descripción de la solución propuesta en detalle.

Recordemos que para los colaboradores de la compañía Bci Seguros, que efectúan horas
extras, se debe completar formulario en papel denominado “solicitud de permanencia”, donde
el trabajador indica el horario en el cual se desarrollará la actividad, el detalle de la tarea, si
es necesario colación o movilización, si al término de la jornada no se cuenta con trasporte
público.
En la actualidad la compañía gasta cerca de UF 6.000 y el concepto de las tareas efectuadas
fuera de horario normal son desconocidos, así como las áreas que lo generan.

Una vez que se ha generado la solicitud, cada Jefe autorizado debe imprimir un formulario,
completarlo y firmarlo, pero sin visión del gasto acumulado.

Los formularios deben ser entregados al área de administración, los cuales, a su vez, revisan
los modelos de gastos y revisa los cumplimientos por ítem, según presupuesto; efectúa un
análisis por gerencia (cuando se puede) y por último efectúa un análisis de los gastos en
movilización y colaciones.

La solución contempla la creación de un sitio web, que automatiza todo este proceso que
actualmente se hace en papel.
Este sitio web desarrollado en [Link], contempla un template bootstrap y una conexión a
una base de datos MySQL. Ambos en servidores que estarán alojados en un hosting externo.

El sitio web contempla en su página de inicio, un formulario de ingreso de usuario y clave,

para validar los datos de ingreso y el perfil que debe ver cada usuario.

La base de datos, guarda toda la información de los colaboradores de la compañía. Los

principales para la gestión del sistema de permanencia serán: RUT, nombre cargo, área,
gerencia, jefe que aprueba y rol.

Cada solicitud efectuada desde el PC del usuario, registrará una interacción con el sitio web
y este con la base de datos, para mantener el detalle de las transacciones en línea.

Una vez que el usuario se haya identificado, previa validación con los parámetros que tiene
la base de datos, tendrá accedo al menú que corresponde según el rol.

En el rol del usuario que efectúa la solicitud de permanencia, se mostrará un menú donde se
debe ingresar la fecha y hora de inicio y fin de la solicitud, la tarea a realizar, si tiene
necesidad de movilización y si tiene la necesidad de colación.
 27

En el rol del usuario jefe, que efectúa la labor de revisar y aprobar las solicitudes, se
mostrarán las solicitudes que tiene pendientes por aprobar. En cada solicitud podrá, revisar
el colaborador que pide la tarea, la hora de inicio y fin de esta y si necesita movilización de
colación o traslado.
Este usuario contará con un botón para aprobar la solicitud y otro para rechazar. Este último,
devolverá la solicitud al usuario creador, con las observaciones que el jefe estime para
justificar el rechazo.

En el rol del usuario del área de administración de la compañía, quien gestionará el control
de gastos por concepto de colación y traslado, se mostrará un menú donde pueda elegir el
tipo de informe, la fecha de inicio y termino del reporte y algunos reportes globales, que
pueden ser: reporte por gerencia o por área.
Este tendrá la opción de revisar la información en el sistema o de exportar a Excel.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 28

5.1.2 Evaluación de Herramientas de desarrollo e Implementación.

Para el presente desarrollo, se ha decidido utilizar la tecnología de .Net, dado que su curva
de aprendizaje es bastante sencilla y por su velocidad de desarrollo, ya que es el más rápido
debido a la cantidad de componentes que tiene pre programado y que ayudan en el trabajo.

Dado el gran número de opciones a la hora de escoger una herramienta de desarrollo, se

incluye un cuadro comparativo de las cuales se consideraron como posibilidades por parte
del desarrollador. En la tabla 5.1, se muestra el costo y las características principales.

Tabla 5.1: Comparativo herramientas de desarrollo. Elaboración propia.

Nombre Costo Características

PHP $0 • Curva de aprendizaje: Es el más
sencillo.
• Velocidad de desarrollo: es rápido si se
usa algún framework.
• Seguridad: tiene mala fama, pero es
debido, sobre todo, a los desarrolladores,
no al lenguaje de programación.
• Rendimiento: Suele ganar PHP en
cuestión de velocidad.
• Servidor Web: tiene versiones
comerciales y open source.
• PHP corre en (casi) cualquier plataforma
utilizando el mismo código fuente,
pudiendo ser compilado y ejecutado en
algo así como 25 plataformas, incluyendo
diferentes versiones de Unix, Windows y
Macs. Como en todos los sistemas se
utiliza el mismo código base, los scripts
pueden ser ejecutados de manera
independiente al sistema operativo.
• Puede interactuar con muchos motores
de bases 40 de datos tales como MySQL,
MS SQL, Oracle, Informix, PostgreSQL, y
otros muchos. Siempre podrás disponer

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 29

de ODBC para situaciones que lo

requieran.
.Net Visual Studio • Curva de aprendizaje: es bastante
2017 Edición sencillo.
Profesional: • Velocidad de desarrollo: es el más
$453.219. rápido, debido a la cantidad de
componentes que tiene que te hacen todo
el trabajo.
• Seguridad: tiene también mala fama
debido a fallos de seguridad debidos a
Windows.
• Rendimiento: es más pesado.
• Servidor Web: solo funciona con IIS.
• Para instalar una aplicación .NET basta
con copiar el código. No es necesario
registrar los componentes y no se toman
en cuenta los problemas de
compatibilidad con DLLs.
• Todos los códigos que se ejecutan en el
ambiente .NET son compilados, lo cual
proporciona un gran rendimiento. El
ambiente Java fue diseñado para ejecutar
el código interpretado.
Java Tiene • Curva de aprendizaje: el más
herramientas complicado de aprender.
gratuitas y • Velocidad de desarrollo: es el más lento
pagadas. • Seguridad: es el más seguro
• Rendimiento: es más pesado
•Servidor Web: tiene versiones
comerciales y open source.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 30

5.1.3 Diagrama de Arquitectura de Solución Propuesta.

La solución contempla el uso de un servidor web y otro servidor de base de datos.

Ambos servidores estarán alojados en un hosting externo.

La base de datos, guarda toda la información de las transacciones de los colaboradores de

la compañía, indicando el cargo, jefe que aprueba y rol, en el caso de los administradores.

Cada solicitud efectuada desde el PC del usuario, registrará una interacción con el sitio web
y la base de datos, para mantener el detalle de las transacciones en línea.

El detalle de la arquitectura muestra cómo se genera la interacción desde el explorador web

del usuario, la cual solicita a la capa de negocio una conexión al servidor web. Este a su vez,
valida el usuario y el tipo de transacción se puede hacer, según los roles que encuentre en
la base de datos. Esto se muestra en figura 5.1. (Elaboración propia).

Figura 5.1: Diagrama de Arquitectura de la solución

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 31

5.1.4 Diagrama proceso mejorado. (BPMN)

El proceso mejorado en la gestión de una permanencia, mantiene las 3 partes del proceso
original, pero suma toda la automatización de validaciones:

• Ingreso de solicitud de permanencia

• Revisión de aprobaciones
• Revisión de gastos

Donde en el primer punto, se efectúan todas las solicitudes permanencias en horas extras.
En esto se incluye el ingreso al sistema con un usuario y clave, y la validación de este para
conocer el perfil que se debe presentar. En caso de ser un usuario que solicita permanencia,
da acceso al menú de solicitudes, el cual pide los datos necesarios para registrar el pedido.
Una vez que se ingresan los datos, el sistema valida y confirma la recepción.

En el segundo punto, el sistema se enfoca en la revisión y aceptación por parte de las

jefaturas, de todas las solicitudes ingresadas. En este punto se valida que la solicitud sea
consistente con las tareas encargadas y si su horario, si por el horario necesitara movilización
y si en la solicitud se ha pedido colación.

En el tercer punto, se efectúan todas tareas posteriores a la actividad, donde el área de

administración revisa los modelos de gastos y revisa los cumplimientos por ítem, según
presupuesto; efectúa un análisis de gastos en movilización, por colaciones y un total por
área.

En la figura 5.2, se presentan las tareas por nivel, según la lógica de los pasos de un proceso
de la gestión de permanencias.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 32

Figura 5.2: BPMN para la gestión de permanencias. (Elaboración propia).

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 33

5.2 Metodología aplicada

5.2.1 Comparativa de metodologías asociadas al proyecto.

En la tabla 5.2 y 5.3, se muestran las principales características de 12 metodologías

consideradas para el desarrollo del sistema. En ella se incluye una breve descripción, la
relación del cliente con el desarrollador, el tipo de software con la que se relaciona, sus
etapas y algunas características propias de cada metodología.

Tabla 5.2: Comparativo metodologías. (Briones, 2014).

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 34

Tabla 5.3: Comparativo metodologías. (Briones, 2014).

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 35

5.2.2 Justificación de la metodología la seleccionada.

Tal como se muestra en la figura 5.4, la metodología seleccionada corresponde a la de

Prototipo.
Se ha seleccionado esta metodología principalmente porque:

• El Jefe de administración el proceso actual y entiende que automatizarlo será

beneficioso.
• El responsable del desarrollo no está familiarizado con las solicitudes actuales y como
sería la mejor forma en el manejo de las solicitudes de permanencia.
• Permite entregar una idea general del proyecto de ingreso de solicitudes y aprobación,
y luego hacer modificaciones en base a lo acordado con el cliente.
• Permite entregar un diseño del módulo de ingreso de solicitudes y de aprobación,
según la lógica del negocio actual.

Figura 5.4: Metodóloga selecciona: Prototipo. Elaboración propia.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 36

5.2.3 Metodología de Administración.

La gestión de proyectos necesita apoyarse en el uso de técnicas para minimizar errores y

aumentar su eficacia. Entre las metodologías para la gestión de proyectos más comúnmente
empleadas se encuentran: el Diagrama de Gantt, Pert/CPM y el Método de la Cadena Crítica.
Cada una de ellas cuenta con sus ventajas e inconvenientes, pero todas suponen una gran
ayuda a la hora de planificar y administrar recursos de la mejor manera y también en lo
referente a controlar la evolución del proyecto.

Para este proyecto, se ha decidido por usar la Carta Gantt, la cual lleva utilizándose durante
cerca de siete décadas y es una de las más famosas metodologías para la gestión de
proyectos. La simplicidad de su estructura y lo manejable de su planteamiento lo configuran
como la herramienta ideal tanto para quienes están iniciándose en la Dirección de Proyectos
como para quienes ya cuentan con una nutrida experiencia en el Project management. La
Carta de Gantt como metodología para la gestión de proyectos, podría resumirse así:

Se compone de dos ejes donde se recogen las tareas y actividades que componen un
proyecto y se asocian a un cronograma, quedando reflejada su duración, momento de inicio
y plazo de entrega previsto.

En este eje de coordenadas también hay espacio para marcar las distintas fases que forman
el proyecto y para resaltar los eventos o acontecimientos que suponen un hito reseñable para
los participantes en el mismo.

Las principales dificultades del Diagrama de Gantt se derivan del establecimiento de

prioridades y la detección de dependencias entre actividades.

Aporta una visión clara y realista de la situación, pero requiere e actualización continua para
garantizar su validez.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 37

5.2.4 Carta Gantt.

Dado que ya se ha avanzado en la definición de las etapas de planificación, de determinación de objetivos y análisis de
riesgo, se adjunta la planificación para la etapa de desarrollos y pruebas, tal como se muestra en la figura 5.5.

Figura 5.5: Detalle de carta Gantt. (Elaboración propia).

ACI 594 Proyecto de título
Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 38

5.3 Obtención de Requerimientos

5.3.1 Metodología Aplicada a la Toma de Requerimientos.

La Metodología utilizada fue: Formulario para entrevista de toma de requerimientos.

Principalmente se elige esta metodología porque representa el comienzo de cada ciclo.

Corresponde a la parte más importante del proceso ya que todo lo que se obtenga en el
formulario de toma de requerimientos, será la base para la construcción del sistema.
Aquí, los analistas de requerimientos deberán trabajar junto al cliente resolver. Esto por lo
regular se hace una reunión antes de comenzar todo, donde se debe especificar lo siguiente:

• Objetivo del sistema, y fechas tentativas del inicio y fin del proyecto.
• Presentación del Equipo de Trabajo
• Presentación de los involucrados en la definición de los requerimientos y líder funcional,
que es quien hace la autorización de los documentos en nombre de todo el equipo.

La especificación de Requerimientos Funcionales, Requerimientos No Funcionales,

Requerimientos de Seguridad, Requerimientos de Mantención y Especificación de
requerimientos, se debe revisar el anexo de especificación de requerimientos.

5.3.2 Requerimientos Funcionales.

• Registro en línea.
• Que guarde y edite.
• Crear nuevos usuarios.
• Edición de usuarios creados.
• Validar campos numéricos y no numéricos.
• Validar contraseñas contra la base de datos.
• Que permita crear una solicitud de permanencia.
• Que permita aprobar o rechazar las solicitudes.
• Que entregue resúmenes diarios, semanales o mensuales de cada trabajador, área o
tipo de uso (tipos de tareas, uso de traslado o colación).
• Obtener un sistema que permita hacer login.

5.3.3 Requerimientos No Funcionales.

• Disponibilidad al tiempo total al que el sistema puede ser usado en un período

determinado.
• Extensibilidad en la implementación del sistema, toma en consideración y facilita su
crecimiento en el futuro.
• La facilidad de uso y aprendizaje del Sistema.
 39

5.3.4 Requerimientos de Seguridad.

• Necesita una sesión.

• No pueda entrar cualquiera al sistema.
• Que la sesión no dure más de 5 minutos sin ocupar.

5.3.5 Requerimientos de Mantención.

Alguna incidencia productiva o algún problema en la marcha blanca será resuelto en su
totalidad.

5.3.6 Especificación de requerimiento.

• El sistema debe contar con la información de los colaboradores cargada en la base de

datos.
• La solicitud de permanencia estará relacionada con el rol de usuario.
• La aprobación de solicitudes estará relacionada al rol de jefe.
• La extracción de reportes estará relacionada al rol de jefe del área de administración.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 40

6.1. Modelamiento UML

6.1.1 Diagrama Casos de Usos.

En la figura 6.1, se adjunta la identificación de los 3 casos de uso desarrollados.

Figura 6.1: Casos de uso. (Elaboración propia).

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 41

En la figura 6.2, se adjunta la identificación del caso de uso correspondiente al usuario

originador.

Figura 6.2: Caso de uso, rol originador. (Elaboración propia).

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 42

En la figura 6.3, se adjunta la identificación del caso de uso correspondiente al usuario jefe
validador.

Figura 6.3: Caso de uso, rol jefe validador. (Elaboración propia).

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 43

En la figura 6.4, se adjunta la identificación del caso de uso correspondiente al usuario jefe
administración .

Figura 6.4: Caso de uso, rol jefe administración. (Elaboración propia).

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 44

6.1.2 Documentación Casos de Uso.

Para el presente proyecto se presentan 3 casos de uso que se aplican al diseño del sistema,
los cuales se pueden revisar en detalle en la sección de anexos.

En la tabla 6.1, se puede revisar la información para un rol de trabajador (originador).

En la tabla 6.2, se puede revisar la información para un rol de Jefe (validador).
En la tabla 6.3, se puede revisar la información para un rol de Jefe de Administración.

Tabla 6.1: Caso de uso para rol de trabajador (originador). Elaboración propia.

Nombre Caso de Uso Ingresando la permanencia

Actores Trabajador (originador)
Pasos normales Pasos alternativos
1) El trabajador ingresa al sistema de 1.1 SI existe problema de autenticación,
permanencias con su Rut y clave. se indica que debe revisar el Rut o la
clave ingresada

2) El sistema obtiene la información

sobre el usuario que se ha identificado.

3) El usuario indica el tipo de solicitud

que quiere realizar.

4) El sistema valida el rol del usuario y

entrega el menú de ingreso de hora de
inicio y fin de la tarea.

5) El sistema valida el rol del usuario y

entrega el menú de ingreso si es
necesario traslado y colación.

6) el sistema valida los datos

ingresado y envía una solicitud de
aprobación al jefe que corresponde al
usuario originador.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 45

Tabla 6.2: Caso de uso para rol de Jefe (validador). Elaboración propia.

Nombre Caso de Uso Aprobando las solicitudes de permanencia

Actores Jefe Aprobador
Pasos normales Pasos alternativos
1) El trabajador ingresa al sistema de 1.1) SI existe problema de autenticación,
permanencias con su Rut y clave. se indica que debe revisar el Rut o la
clave ingresada

2) El sistema obtiene la información

sobre el usuario que se ha identificado.

3) El usuario indica el tipo de solicitud

que quiere realizar.

4) El sistema entrega el menú de

revisión de hora de inicio y fin de la
tarea.

5) El sistema entrega el menú de

revisión de traslado y colación.

6) El jefe aprueba la solicitud en el 6.1) Si no existe aprobación, el sistema

sistema. genera un aviso al usuario originador.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 46

Tabla 6.3: Caso de uso para rol de jefe de administración (RRHH). Elaboración propia.

Nombre Caso de Uso Revisando los gastos por permanencia

Actores Jefe Administración
Pasos normales Pasos alternativos
1) El trabajador ingresa al sistema de 1.1) SI existe problema de autenticación,
permanencias con su Rut y clave. se indica que debe revisar el Rut o la
clave ingresada

2) El sistema obtiene la información

sobre el usuario que se ha identificado.

3) El usuario indica el tipo de solicitud

que quiere realizar.

4) El sistema entrega el menú de

gastos por área.

5) El sistema entrega el menú de

gastos de traslado y colación.

6) El sistema entrega el menú de

gastos de versus presupuesto.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 47

6.1.3 Diagrama de Componentes.

A modo general y como se puede revisar en la figura 6.2, podemos identificar el comienzo
de la transacción, el paso por la interfaz de usuario, el paso por las lógicas de la misma
interfaz y negocio, y su acceso a la base de datos.

Figura 6.2: Diagrama de componentes. Elaboración propia.

En el comienzo de las transacciones, donde se efectúan todas las solicitudes permanencias

en horas extras, se considera el ingreso al sistema con un usuario y clave, y la validación de
este para conocer el perfil que se debe presentar. En caso de ser un usuario que solicita
permanencia, da acceso al menú de solicitudes, el cual pide los datos necesarios para
registrar el pedido. Una vez que se ingresan los datos, el sistema valida y confirma la
recepción.

Si la lógica de la interfaz y negocio detectan que, al sistema se conecta un usuario con rol de
jefe, el sistema debe acceder a los datos de todas las solicitudes ingresadas, según el
organograma. En este punto se valida que la solicitud sea consistente con las tareas
encargadas y si su horario, si por el horario necesitara movilización y si en la solicitud se ha
pedido colación.

Si la lógica de la interfaz y negocio detectan que, al sistema se conecta un usuario con rol de
jefe de área de administración, el sistema debe acceder a los datos de los modelos de gastos
y revisa los cumplimientos por ítem, según presupuesto; efectúa un análisis de gastos en
movilización, por colaciones y un total por área.
ACI 594 Proyecto de título
Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 48

6.2 Modelo de Datos.

Para el modelo de la base de datos, se identifican 2 tablas principales, tal como se muestra
en la figura 6.3.
La tabla GP_USUARIO, almacena toda la información relacionada a los distintos usuarios
del sistema.
La tabla GP_SOLICITUD, almacena toda la información de las transacciones asociadas a un
usuario.

Luego existen 4 tablas secundarias que dan soporte a las principales que son:

GP_ROL, donde se almacena el tipo de Usuario.

GP_CARGO, que almacena los tipos de roles que tienen los usuarios.
GP_AREA, que almacena el área a la que pertenece el trabajador que genera las solicitudes.
GP_GERENCIA, que almacena la gerencia a la que pertenece el trabajador que genera las
solicitudes.
GP_USUARIO
GP_ROL RUT
GP_AREA
ROL_ID AREA_ID
ROL_ID
NOMBRE_ROL NOMBRE_AREA
NOMBRE

CLAVE

JEFE

AREA_ID

GERENCIA_ID

CARGO_ID
GP_CARGO
COMPANNIA_ID
CARGO_ID
EMAIL GP_GERENCIA
NOMBRE_CARGO
GERENCIA_ID

GERENCIA_NOMBRE

GP_SOLICITUD
ID_TRANSAC

FECHA_SOLICITUD

HORA_INI_SOLICITUD

HORA_FIN_SOLICITUD

[COLACION?]

[TRASLADO?]

ESTADO_SOLICITUD

RUT

Figura 6.3: Modelo de datos de la base “GestionPermanencia”. (Elaboración propia).

ACI 594 Proyecto de título
Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 49

CAPITULO VII CONSTRUCCIÓN DE PROTOTIPO FUNCIONAL

Según el perfil del usuario que ingresa al sistema, se presenta un menú para crear una nueva
solicitud, como se muestra en la figura 7.1.

Figura 7.1: Menú de ingreso de solicitudes.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 50

Para ver las solicitudes creadas, su estado y la posibilidad de exportar la información, se

presenta un resumen como se muestra en la figura 7.2.

Figura 7.2: Menú de detalle de solicitudes para aprobar.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 51

CAPITULO VIII: DISEÑOS DE PRUEBAS DEL SOFTWARE

Se ha considerado pasar el sistema por 3 etapas:

1. Pruebas de desarrollo.
2. Versiones de prueba.
3. Pruebas de usuario.

Pruebas de desarrollo:
El software se ha puesto a prueba durante este proceso para detectar bugs o defectos.
Para esto, se han efectuado:

• Pruebas de unidad: donde se han probado unidades de programa de manera

individual.
• Pruebas del componente: donde se han probado la integración de los componentes
individuales.
• Pruebas del sistema: donde se ha probado el sistema como un todo.

Versiones de prueba:
El software se ha puesto a prueba por un analista que no intervino en el desarrollo.
Para ello, se efectuaron:

• Pruebas basadas en los requerimientos.

• Pruebas de escenario.
• Pruebas de rendimiento.

Pruebas de usuario:
Pruebas Alfa: Donde los 2 prototipos iniciales se han trabajado entre el usuario y el
desarrollador, en el PC de desarrollo.
Pruebas Beta: Donde se ha liberado una versión, basada en el prototipo 3, para que el
usuario experimente el uso real, permitiendo encontrar errores de uso.
Prueba de aceptación: Prueba que aún se encuentra pendiente, pero que permitirá decidir
si el sistema está listo o no, ya que se despliega en el entorno del cliente.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 52

CAPITULO IX CONCLUSIONES DEL PROYECTO

9.1 Conclusiones.

Luego de pasar por un análisis completo de los aspectos de la empresa, conocer su situación
actual y plantear los objetivos generales y específicos, se puede indicar que la herramienta
desarrollada para la gestión de permanencias, ayudará a eliminar la carga excesiva en el
manejo de formularios en papel, a través de una solución tecnológica que entrega visibilidad
en el consumo de movilización y colación, cuando se generan horas extras.

Si miramos de manera específica el detalle de los objetivos, podemos indicar que cada punto
se ha cumplido, principalmente porque la aplicación permite:

• Digitalizar el registro de actividades, horarios, colaciones y movilización.

• Entregar la capacidad para que cada colaborador ingrese su solicitud en el
sistema.
• Validar las solicitudes según cada Jefe.
• Generar un resumen de las solicitudes y gastos de colación, para el área de
administración.
• Generar un resumen de las solicitudes y gastos de movilización, para el área
de administración.

9.2 Perspectivas Futuras.

Dentro de la mirada futura, se espera que la compañía adopte esta herramienta como un
aporte en la gestión y control de los ítems de traslado y colaciones, que se efectúan fuera
del horario de trabajo; entregado a las áreas responsables, un seguimiento detallado en el
periodo de tiempo que se necesite.
Otra visión futura, puede ser la integración con el sistema de registro de asistencia, el cual
permitiría una visión de 360°, sobre los gastos relacionados a horas extras.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados
 53

Web grafía

Bci Seguros. (2017). [Link]. Obtenido de Estados Financieros:

[Link]
Briones, S. (2014). [Link]. Obtenido de [Link]
comparativo-34456077
OBS. (2018). OBS Business School. Obtenido de [Link]
management/administracion-de-proyectos/las-3-metodologias-para-la-gestion-de-
proyectos-que-mas-se-utilizan

Bibliografía

Sommerville, I. (2005). Introducción a la ingeniería de Software. En I. Sommerville,

Introducción a la ingeniería de Software (pág. 712). Madrid: Pearson education S.A.

ACI 594 Proyecto de título

Escuela de Tecnología de la Información – FINE
Proyecto creado por Paulo Bolívar Jofré
Derechos reservados