carlos alberto duque ospina
TRANSCRIPT
SISTEMA DE INFORMACIÓN PARA LA MEJORA DE PROCESOS
ADMINISTRATIVOS Y OPERATIVOS EN LA EMPRESA EVENTUALES 2020
CARLOS ALBERTO DUQUE OSPINA
UNIVERSIDAD PILOTO DE COLOMBIA SECCIONAL ALTO MAGDALENA
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
GIRARDOT
2020
1
SISTEMA DE INFORMACIÓN PARA LA MEJORA DE PROCESOS
ADMINISTRATIVOS Y OPERATIVOS EN LA EMPRESA EVENTUALES 2020
CARLOS ALBERTO DUQUE OSPINA
PRESENTADO A:
LUDWIG IVÁN TRUJILLO HERNANDEZ
UNIVERSIDAD PILOTO DE COLOMBIA SECCIONAL ALTO MAGDALENA
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
GIRARDOT
2020
2
Índice
Índices especiales 6
Tablas 6
Figuras 7
Introducción 8
Problema 9
3.1. Definición del problema 9
3.2. Formulación del problema 11
3.2.1. Preguntas secundarias 11
3.3. Elementos del problema 12
Justificación 12
4.1. Justificación técnica 12
4.2. Justificación social 13
4.3. Justificación académica 13
Objetivo general 13
5.1. Objetivos específicos 13
5.2. Objetivos del sistema 13
Alcances y límites 14
6.1. Presente 14
6.2. Futuro 14
6.3. Limitaciones 14
Marco de referencia 14
7.1. Antecedentes 14
7.1.1. Zoho-Backstage 14
7.1.2. Eventtia 15
3
7.2. Marco teórico 15
7.2.1. La no utilización de las T.I.C. en empresas 15
7.2.2. ¿Hay ventajas en la utilización de sistemas de información para eventos?
16
7.2.3. La baja eficiencia en el área administrativa de eventos 17
7.2.4. Metodologías de desarrollo para la construcción de un software. 18
7.2.4.1. Metodologías AGILE 19
7.2.5. Frameworks 21
7.3. Marco conceptual 22
7.3.1. Alfabetismo digital. 22
7.3.2. Tecnología de la información y la comunicación. 23
7.4. Marco Legal 23
7.4.1. Ley estatutaria 1581 de 2012 23
7.4.2. Licencia CDDL 24
Hipótesis 24
Área de investigación 25
Instrumentos de Recolección de Datos 26
10.1. Análisis documental 26
10.2. Encuesta 26
10.3. Grupo focal 26
Validación del instrumento, población y muestra 27
11.1. Definición de la muestra 27
11.2. Aplicación de los instrumentos 27
11.3. Tabulación 27
4
11.4. Análisis y resultados de los datos 29
Desarrollo de la metodología 30
12.1. Metodología Ágil 30
12.2. Sxp 30
12.2.1. Planificación 30
12.2.1.1 Actividades. 30
12.2.1.2. Artefactos. 31
12.2.2. Desarrollo 32
12.2.2.1. Actividades. 32
12.2.2.2. Artefactos. 32
12.2.3. Entrega 33
12.2.3.1. Actividades. 33
12.2.3.2. Artefactos 34
12.2.4. Mantenimiento 34
12.2.4.1. Actividades. 34
12.2.4.2. Artefactos 34
12.3. Herramientas y Diagramas 34
Requerimientos 35
13.1. Requerimientos funcionales 35
13.2. Requerimientos no funcionales 35
13.3. Requerimiento de seguridad 35
13.4. Historias de usuario 36
13.6. Lista de Reserva del producto (LRD) 36
Análisis del sistema actual 36
5
14.1. Diagnóstico del sistema actual 36
14.2. Definición de los casos de uso 37
14.3. Definición del modelo conceptual 38
14.4. Definición del diagrama de colaboración 39
14.5. Definición del diseño de clases 39
Diseño y desarrollo del sistema propuesto 40
15.1. Diccionario de datos 40
15.2. Modelo Relacional 44
15.3. Secuencia 45
15.4. Modelo entidad-relación 45
Análisis de riesgos 46
16.1 Definición de escalas. 46
16.2. Posibles riesgos del sistema. 47
16.3. Identificación de factores y evaluación de riesgos 47
16.3.1. Factor Humano. 47
16.3.2. Factor técnico o tecnológico. 48
16.3.3. Factor Organizacional. 48
16.3.4. Factor del hardware. 49
16.3..4.1. Prioridad. 50
16.3.5. Conclusión del análisis de riesgos. 50
Análisis del proyecto 51
17.1. Estudio de factibilidad 51
17.1.1. Factibilidad técnica. 51
17.1.2. Factibilidad económica. 52
6
17.1.2.1. Presupuesto 52
17.1.3. Factibilidad judicial. 53
17.1.4. Factibilidad ética. 53
17.1.5. Factibilidad Operativa. 54
17.1.6. Cronograma 55
Pruebas 56
18.1. Prueba Unitaria 56
18.2. Pruebas de Humo 56
Recomendaciones 56
Conclusiones 57
Referencias 58
Índices especiales
Tablas
Tabla 1. Encuesta. 25 Tabla 2. Grupo focal. 26 Tabla 3. Historias de usuario. 36 Tabla 4. Tabla persona 40 Tabla 5. Tabla agenda 40 Tabla 6. Tabla cliente. 40 Tabla 7. Tabla compra. 40 Tabla 8. Tabla cuentas . 41 Tabla 9. Tabla det_compra 41 Tabla 10. Tabla detpago 41 Tabla 11. Tabla evento. 41 Tabla 12. Tabla nomina 42 Tabla 13. Tabla paquete 42 Tabla 14. Tabla proveedor 42 Tabla 15. Tabla recursos. 42 Tabla 16. Tabla requerimientos. 43 Tabla 17. Tabla trabajador. 43 Tabla 18. Definición de escalas. Impacto. 46
7
Tabla 19. Definición de escalas. 47 Tabla 20. Riesgos del factor humano 47 Tabla 21. Riesgos factor técnico o tecnológico 48 Tabla 22. Riesgos factor organizacional 49 Tabla 23. Factor del hardware 49 Tabla 24. Prioridad . 50 Tabla 25. Factibilidad económica. 52 Tabla 26. Factibilidad operativa 55 Tabla 27. Resultados de la implementación. 57 Figuras
Figura 1. Casos de uso sistema actual 37 Figura 2. Modelo conceptual de sistema actual. 38 Figura 3. Diagrama de colaboración sistema actual. 39 Figura 4. Diagrama de clases sistema actual. 39 Figura 5. Modelo relacional. 44 Figura 6. Diagrama de secuencia. 45 Figura 7. Modelo entidad-relación. 45 Gráficas
Gráfica 1. Resultados encuesta. 29 Gráfica 2. Resultados del grupo focal. 29
8
Resumen
La mejora en los procesos administrativos y operativos de una empresa de eventos
en la ciudad Girardot como lo son: la organización de personal, organización del
evento, manejo de caja, organización de documentos, toma de datos de los
trabajadores y el cálculo del pago de nómina según la labor realizada, se ven
afectados por la falta de implementación de sistemas de información, pues al hacer
todos estos procesos de manera manual (talonarios) y uno que otro archivo digital
(hojas de Excel independientes para cada trabajador administrativo que “debería”
tener la misma información que los demás) hacen de un proceso sencillo una
maraña de información dando como resultado desde reasignaciones a última hora
de trabajadores, hasta descuadres de caja. Para este proyecto siendo un solo
investigador se implementa una metodología híbrida ágil sxp (Scrum: llevar un
seguimiento estricto del proceso y XP: para proyectos pequeños con equipos de
trabajo de igual tamaño) con sus herramientas y procesos, entre ellas encontramos:
toma de datos (historias de usuario), análisis de la información y estructuración del
proyecto (Working skeleton o LRP “Lista de Reserva del Producto), se descubre
que con estos sistemas se agilizan los procesos y dan orden a los datos e
información que la empresa maneje ya que e tiene claridad en todo el
funcionamiento del proceso. Con lo anterior se argumenta el desarrollo de este
sistema de información que satisface las necesidades que la empresa de eventos
posee.
Introducción
La empresa Eventuales y Logística tiene una trayectoria de aproximadamente 3
años en los cuales ha sido bien recibida por sus clientes satisfechos por el servicio
recibido, conforme la empresa presenta crecimiento se han venido creando
problemas en la organización de sus procesos, tanto administrativos como
operacionales, pues sus fundadores y dueños de la empresa siguen manejando
estas acciones como en sus inicios, de manera manual con talonarios y (ya en muy
poco uso en la empresa) listados impresos del personal disponible, todo esto
genera confusiones entre los empleados administrativos ya que ellos no poseen un
9
archivo en común de los trabajadores y últimamente se han generado conflictos por
dichos malentendidos generados por la falta de actualización de las operaciones
(haciendo referencia a la introducción de sistemas de información).
Lo que se pretende lograr es: implementar un sistema de información que ayude a
la mejora de procesos tanto administrativos como operacionales ya mencionados y
que unifique los archivos existentes para que dicho sistema sea quien se encargue
de la organización por medio de funciones y una interfaz gráfica de fácil
entendimiento. Este proceso se realizará por medio de la metodología AGIL para
desarrollo de proyectos, SXP. Esta metodología es una mezcla entre las
metodologías SCRUM y XP, pues reúne las características necesarias de cada una
y se aplica para proyectos y equipos de trabajo pequeños enfocados como si fuesen
proyectos grandes.
Cabe aclarar que la investigación está limitada al hecho de que los fundadores
tienen una mentalidad de no cambiar su modo de trabajar ya que este en sus inicios
les funcionó, solo aceptan que el sistema de información se encuentre en sus
equipos de mesa de manera local, que por medio de red se conecten al sistema de
información, no les llama la atención ninguna otra solución por el analfabetismo
digital que ellos poseen.
TITULO: Sistema de Información para la Mejora de Procesos Administrativos y
Operativos en la Empresa Eventuales 2020.
Problema
3.1. Definición del problema
Para la mejora de procesos administrativos y operativos en las empresas de
eventos, se ha vuelto necesario la implementación de sistemas de información, esto
10
con el fin de aliviar cargas administrativas, ayudar con el almacenamiento y
búsqueda de información.
“Los sistemas de información están cambiando en la actualidad la forma en que
operan las organizaciones. Mediante su uso se obtienen grandes mejoras, ya que
automatizan los procesos operativos que se pueden llevar a cabo en toda empresa,
proporcionan información de apoyo al proceso de tomas de decisiones y facilitan el
logro de ventajas competitivas a través de su implantación dentro de la
organización.” (Hamidian Fernández & Ospino Sumoza, 2015).
En Europa, más exactamente en España, hay una empresa que permite por medio
de una plataforma web organizar eventos, esta empresa es “tu fabrica de eventos”:
Tu Fábrica de Eventos es el software online para la gestión integral de eventos
"Todo en uno! más completo y potente del mercado, integrando todas las
soluciones que necesita un organizador en un mismo lugar.(tu fabrica deventos,
2016).
Desde California - Estados Unidos se encuentra Zoho-Backstage: “Es un software
de administración de eventos que le permite a los planificadores de eventos
organizar conferencias, lanzamientos de productos, reuniones con varios
participantes y mucho más con un mayor impacto y eficiencia ”(Zoho, s.f.). Este
software ha tenido tan buena acogida que posee oficinas físicas en Japón, India
China, Australia, entre otros.
En Colombia ya hay empresas que se dedican a implementar los sistemas de
información en el gremio de eventos, un ejemplo entre los más reconocidos en este
tema ubicado en Antioquia es Eventtia: Para planear un próximo evento, gestionar
11
el registro online, comunicar mejor con sus participantes, construir el website del
evento, lanzar una aplicación móvil, gestionar una rueda de negocios, u organizar
una feria, el software de gestión de eventos está para ayudar. (eventtia, 2020).
En Girardot hay empresas dedicadas a organizar eventos, ya tienen su propia
página web, pero el manejo interno no lo comparten ya que “es información
confidencial” manifiestan ellos. Pero basando los hechos en la observación, ellos
poseen ya los valores predeterminados en tablas al igual que su personal.
En la empresa eventuales, los problemas se encuentran en el manejo de personal:
en el seguimiento de sus afiliaciones y pagos de seguridad social, asignación a
eventos y manejo contable de ingresos y egresos diarios. Estos procesos son
hechos de manera engorrosa(manual), con archivos diferentes que poseen listados
de los empleados aparte de los otros y esto genera confusiones al momento de la
asignación de personal y recursos al evento, todo esto generado por el
analfabetismo digital de los fundadores, pues se niegan a hacer un cambio ya que
“lo manual” les ha funcionado en un inicio.
3.2. Formulación del problema
¿Cómo desarrollar e implementar un sistema de información, que permita mejorar
los procesos administrativos y operativos de la empresa Eventuales teniendo en
cuenta el analfabetismo de los fundadores?
3.2.1. Preguntas secundarias
● ¿Cómo incluir al mundo tecnológico a las personas analfabetas
digitales?
● ¿Cómo demostrar la mejora en los tiempos de un proceso?
● ¿Es necesaria esa mejora en los tiempos?
● ¿Por qué mejorar los tiempos de dichos procesos?
12
3.3. Elementos del problema
● La no utilización de las T.I.C. en empresas.
● ¿Hay ventajas en la utilización de sistemas de información para
eventos?
● La baja eficiencia en el área administrativa de eventos.
● Metodologías de desarrollo para la construcción de un software.
● Frameworks.
Justificación
El proyecto tiene como finalidad, integrar las diferentes áreas de control para
automatizar procesos administrativos y operativos como lo son: generación de
recibos, manejo de la caja (control de ingresos y egresos), las cuentas por cobrar
a clientes, las cuentas por pagar a proveedores, manejo de la seguridad social de
sus trabajadores. Esto crea ventajas competitivas para la empresa.
La implementación del sistema tiene como fin, sacar el mayor provecho del
inventario y sus colaboradores, pues permite conocer la ubicación y labor que están
desempeñando, esto evita confusiones o sobrecarga de labores.
Finalmente ahorrar en papelería y poder manejar todo a través del sistema, pues
como se ha expresado, Eventuales es una empresa que maneja todos sus
procesos en talonarios, AZ’s, listas manuales, entre otros.
4.1. Justificación técnica
Técnicamente el proyecto es viable pues: se hará una aplicación de software libre,
con lenguaje java, con Netbeans como framework, cuenta con una base de datos
creada y administrada con phpMyAdmin y a su vez la empresa posee los elementos
necesarios para implementar el sistema de información, tienen tomas de corriente
funcionales, terminales de internet y computadores que permitirán la puesta en
marcha del proyecto.
13
4.2. Justificación social
Será de gran ayuda al gremio de empresas de eventos pues ofrecerá una
“herramienta” que facilitará y optimizará las tareas administrativas (manejo de
personal: seguridad social, organización por grupos), obteniendo conocimientos en
el manejo de aplicaciones o programas.
4.3. Justificación académica
Este proyecto nos permitirá implementar los conocimientos adquiridos en
Programación para desarrollar la solución, Bases de Datos para modelar y crear el
sistema de información y Taller de Investigación para sustentar la necesidad de
este proyecto, pues, aunque nos son todas las materias en el pensum universitario,
son las fundamentales en la realización de este proyecto.
Objetivo general
Diseñar, desarrollar e implementar un sistema de información que mejore los
procesos administrativos y operativos en la empresa Eventuales, propendiendo por
la disminución del analfabetismo digital de los fundadores.
5.1. Objetivos específicos
● Analizar y comparar cuales son los procesos administrativos y
operativos de las empresas de eventos y cómo incorporarlos en un
sistema informático.
● Determinar los requerimientos de software y hardware necesarios
para el diseño y desarrollo el sistema de información de acuerdo a la
empresa Eventuales.
● Implementar el software haciendo pruebas para disminuir el
analfabetismo digital de los fundadores y mantenimientos.
5.2. Objetivos del sistema
● Determinar la mejor metodología de desarrollo para el proyecto.
● Determinar la arquitectura de software y hardware pertinentes para el
proyecto.
14
Alcances y límites
6.1. Presente
El software realizará las tareas que se realizan en la empresa actualmente como lo
son:
Crear planes o paquetes de eventos mostrando su disponibilidad.
Crear eventos.
Controlar al personal disponible para asignarlos a eventos.
Mostrar el personal para realizar el respectivo pago de su salario.
Una vez culminado el evento y el pago se procederá a hacer el despido.
Tener el listado del personal para realizar el pago de seguridad social.
6.2. Futuro
Se pretende que este software se pueda exportar a una app o sitio web que permita
la expansión del negocio y alcance del software.
6.3. Limitaciones
Teniendo en cuenta al personal de la empresa, una de las limitaciones presentes
es la negación al cambio o actualización a la sistematización, esto provocaría la
cancelación del proyecto.
Marco de referencia
7.1. Antecedentes
7.1.1. Zoho-Backstage
“Optimice las actividades de su evento antes, durante y después de este. Cree sitios
web, configure las entradas, gestione oradores, planifique sesiones.
Promocione su evento para aumentar los registros. Mantenga informados a sus
asistentes durante todas las fases del evento.
Programe correos electrónicos personalizados y mantenga a sus asistentes en
sintonía.
Consiga atraer más atención a su evento. Comparta la página del evento en todos
sus canales de redes sociales.
15
Capte a los primeros asistentes mediante la entrega de un descuento promocional
por tiempo limitado.”(Zoho, s.f.).
Esas son algunas de las características que el programa ofrece a sus usuarios y
empresarios para crear y promocionar sus eventos (más que todo streamers) y a
su vez es una mirada que se desea implementar a futuro en la empresa Eventuales.
7.1.2. Eventtia
Este software siendo un producto colombiano posee las siguientes características:
“Nuestro software para gestión de eventos es 100% amigable y fácil de usar,
simplifica considerablemente los procesos logísticos y permite a tu equipo planificar
eventos increíbles.
El registro en línea es el núcleo de nuestro software para gestión de eventos.
Diseñamos nuestra plataforma de eventos, integrando un módulo completo de
registro y venta de entradas.
Genera y envía fácilmente cuentas de cobro. Gracias a nuestra integración con
PayPal, PayU y Stripe, puedes recibir pagos online al instante.
El sistema enviará a los asistentes todas las alertas de solicitud de reuniones,
creando automáticamente una agenda con las citas aceptadas. Además, informará
a los participantes sobre las últimas actualizaciones respecto al evento.” (eventtia,
2020).
Es una plataforma que brinda muchas herramientas a la empresa y es el paso
siguiente de la empresa, entrar en el negocio virtual de los eventos, pues cabe
aclarar que Eventuales, por el momento, maneja eventos sociales como los son:
cumpleaños, bodas y demás.
7.2. Marco teórico
7.2.1. La no utilización de las T.I.C. en empresas
El docente cuando innova toma decisiones creativas que amplían y fortalecen el
sentido de la tarea formativa e implican a todos los miembros de las instituciones
tanto en la reflexión compartida como en el diseño y desarrollo de las prácticas
(Hernández, 2011).
16
Entre los beneficios generales del diseño asistido por computadora (CAD) se
incluyen menores costos de desarrollo de productos, mayor productividad, mejor
calidad del producto y menor tiempo de respuesta al mercado (Arancón, 2015).
Todos estos son los beneficios de utilizar estas tecnologías, ahora, con las
referencias anteriores, se dan a conocer las falencias que acarrea el no hacerlo
indicando la importancia de agregar estas tecnologías en los procesos tanto
educativos como administrativos.
7.2.2. ¿Hay ventajas en la utilización de sistemas de información para
eventos?
En una empresa se presenta mucha pérdida de tiempo. Algunos problemas con
estos procesos son:
● “No tiene seguridad contra posibles asaltos o robos
● No cuenta con el feble o monedas de baja denominación necesarias.
● Pierde tiempo en cuadrar caja del día”. (Amorós, Díaz, & León, 2007)
Por lo tanto, para impulsar la utilización de un sistema de información para una
empresa de eventos encontramos:
● “Control efectivo de las actividades de la organización.
● Integración de nuevas tecnologías y herramientas de vanguardia.
● Ayuda a incrementar la efectividad en la operación de las empresas.
● Proporciona ventajas competitivas y valor agregado.
● Disponibilidad de mayor y mejor información para los usuarios en tiempo
real.
● Elimina la barrera de la distancia trabajando con un mismo sistema en
puntos distantes.
● Disminuye errores, tiempo y recursos superfluos.
● Permite comparar resultados alcanzados con los objetivos programados,
con fines de evaluación y control”. (Mero Suarez, 2011).
17
7.2.3. La baja eficiencia en el área administrativa de eventos
Al tener atención al cliente directo afecta mucho en los tiempos de atención,
provocando en ocasiones filas y descuadres en la caja.
En lo administrativo se presenta en la organización de archivo y la falta de personal,
pues muchas veces no tienen la cantidad necesaria para garantizar un buen tiempo
de respuesta.
“La medición de la productividad del área de servicios y el trabajo de oficina tiene
una dificultad fundamental, esta es la incapacidad de definir claramente las
unidades de producto y hallar un denominador común para estos. No obstante,
podría medirse la productividad administrativa en términos financieros, tales como
servicios vendidos o costo de los factores utilizados. También podría medirse en
términos de tiempo estándar para la realización de un trabajo, estas mediciones
basadas en el tiempo requieren del cálculo de los tiempos tipo o estándar para
realizar cada trabajo, de un estudio de tiempos y del muestreo de actividades”.
(Moreno Henao & Duque Martinez, 2013).
Según Moreno y Duque, la productividad no es un proceso fácil de medir, pues
estos procesos requieren de varios factores y características, que puede variar para
cada caso de estudio.
“Dado que el tiempo dedicado a cada actividad puede medirse y compararse a
través de las técnicas mencionadas anteriormente, la medida más apropiada para
la productividad del trabajo de oficina sería el porcentaje de tiempo dedicada por
cada persona a la realización de actividades útiles y convenientes”. (Moreno Henao
& Duque Martinez, 2013).
Esto indica la forma correcta de medir la productividad administrativa, pues es un
concepto abstracto, es decir, un concepto relativo y que no puede ser medido de
una manera en común, dificultando las maneras básicas de medición.
18
7.2.4. Metodologías de desarrollo para la construcción de un software.
Si bien los conceptos básicos en las metodologías de desarrollo de software no
varían, si existen varios modelos de trabajo. Son métodos de trabajo que han sido
creados para satisfacer necesidades específicas en los proyectos.
“a) Modelo en cascada:
Las actividades están relacionadas unas a otras de modo que el proceso en su
conjunto avanza cuanto mayor sea el número de tareas ejecutadas. Las acciones
principales del desarrollo de un programa software son la especificación, la
validación y la evolución del mismo. También resultan determinantes el diseño del
software como tal, la implementación y las pruebas.” (OBS Businnes School, s.f.).
Este modelo es uno de los primeros en ser implementados, con este proceso, el
usuario no conocía las etapas del proyecto, este modelo a su vez, es muy poco
práctico, pues si había un error en el proceso se debía repetir todo el modelo para
corregirlo.
“b) Modelo de desarrollo evolutivo:
En este caso, por el contrario, lo más importante no es la suma de aportes de cada
etapa del proceso, sino el hecho de que las actividades de especificación,
desarrollo y validación están entrelazadas. El punto de partida siempre es un
sistema inicial que se desarrolla de forma rápida y que va evolucionando según la
dinámica del propio proyecto y las peticiones de los clientes o destinatarios.” (OBS
Businnes School, s.f.).
Este es un avance en comparación con el “modelo cascada”, ya que desde un inicio
el proyecto evoluciona con la ayuda de las peticiones del cliente, todo hasta que los
objetivos son alcanzados.
19
“c) Modelo de componentes:
Se trata de un modelo especialmente útil en procesos que parten del trabajo que
otros han llevado a cabo. Las partes que ya no aportan ningún beneficio a otros
proyectos son reutilizadas e integradas en una nueva metodología de desarrollo.”
(OBS Businnes School, s.f.).
Con este modelo se implementa la reutilización de partes de un proyecto al cual ya
no le es útil y se integra a otra metodología, esto es una adecuación generando un
nuevo valor en el proyecto.
7.2.4.1. Metodologías AGILE
Son varias y poseen la posibilidad de adaptarse. Son basadas en respuestas
rápidas y la intervención en los procesos por parte del cliente. Son diferentes pues
en las metodologías anteriores, los progresos se hacían hasta el momento de la
entrega, eso significaba mayor costo y resultados menos óptimos.
1. “Extreme Programming XP
Pone el acento en las relaciones personales de los miembros del equipo y entre
éstos y los clientes o destinatarios del proyecto. Es especialmente oportuna para
«startups» o empresas que aún no están consolidadas en sus respectivos
mercados. Además, dado que el foco son las relaciones entre los miembros, lo ideal
es que se acoja en escenarios con equipos de trabajo reducidos. Sus fases
principales son:
● El cliente decide lo que quiere del proceso: objetivos y resultados.
● El equipo divide el trabajo en acciones pequeñas y le asigna un tiempo a
cada una.
● El cliente decide qué acciones se realizan primero.
El equipo de trabajo realiza lo que el cliente ha decidido.” (OBS Businnes School,
s.f.).
20
Esta es una metodología pensada para proyectos y grupos de trabajo pequeños,
quiere decir, que no conllevan mucho tiempo y pueden realizarse con equipos de
menos de 4 personas.
2. “SCRUM:
Podría denominarse como la «metodología del caos», dado que afirma que todos
los procesos son caóticos por naturaleza. Por tanto, su estrategia irá orientada a
gestionar ese caos antes que a eliminarlo. El proceso de la metodología SCRUM
se divide en fases y el equipo de trabajo y su líder se reúnen periódicamente para
evaluar los resultados de cada etapa. El criterio en cada momento es el mismo: el
cumplimiento de los objetivos trazados. Si no ha sido así, se aplican las mejoras
correspondientes.” (OBS Businnes School, s.f.).
SCRUM es una metodología con mayor énfasis en cada una de las fases, pues se
hacen entregas en cada una de las reuniones verificando la factibilidad y
cumplimiento de cada uno de los objetivos planteados.
3. “Kanban:
La estrategia Kanban es especialmente útil para los responsables de proyectos.
Consiste en la elaboración de un cuadro o diagrama en el que se reflejan tres
columnas de tareas: pendientes, en proceso y terminadas. Es indispensable que el
cuadro esté ubicado en un lugar visible, o en una herramienta de Software
compartida, para que los miembros de los equipos sepan la evolución del proceso
y eviten repetir tareas. De esta manera, se logra una mejor coordinación de
tiempos, talentos y habilidades.” (OBS Businnes School, s.f.).
Con esta metodología todo el equipo de trabajo puede observar el avance del
proyecto y las tareas pendientes, garantizando que los miembros del equipo
puedan trabajar en sin repetir objetivos o malgastar tiempo.
21
4. “Agile Inception
Esta metodología está orientada a la definición, o redefinición, si el caso lo merece,
de los objetivos generales de las empresas. Su meta es clarificar cuestiones como
el tipo de cliente objetivo, las propuestas de valor añadido, las formas de venta,
entre otras. Suele apoyarse en el método del ‘elevator pitch’, que consiste en
pequeñas reuniones con socios y miembros en las que las intervenciones no
pueden superar los 5 minutos. Se busca la precisión, la agilidad y el sentido
práctico.”
” (OBS Businnes School, s.f.).
Al tener varias opciones de metodologías ágiles, existe la posibilidad de que haya
metodologías híbridas como lo es sxp, esta metodología combina a Scrum y XP
convirtiéndola en una buena herramienta para el desarrollo de proyectos pequeños
con equipo de desarrollo pequeño convirtiéndolo en la mejor opción para este
trabajo.
7.2.5. Frameworks
“Dado que a menudo son construidos, probados y optimizados por varios ingenieros
de software y programadores experimentados, los frameworks son versátiles,
robustos y eficientes. El uso de un marco de software para desarrollar aplicaciones le permite centrarse
en la funcionalidad de alto nivel de la aplicación. Esto se debe a que el propio frame
se ocupa de cualquier funcionalidad de bajo nivel.
¿Por qué usamos Frameworks?
El desarrollo de software es un proceso complejo. Requiere una gran cantidad de
tareas, incluida la codificación, el diseño y las pruebas. Solo para la parte de
codificación, los programadores tuvieron que ocuparse de la sintaxis,
declaraciones, recolección de basura, declaraciones, excepciones y más.
Los frameworks facilitan la vida de los desarrolladores al permitirles tomar el control
de todo el proceso de desarrollo de software, o la mayor parte, desde una única
plataforma.
22
Ventajas de usar un frame de software:
● Ayuda a establecer mejores prácticas de programación y al uso apropiado
de patrones de diseño
● El código es más seguro
● Se puede evitar el código duplicado y redundante
● Ayuda a desarrollar códigos consistentes con menos errores
● Facilita el trabajo en tecnologías sofisticadas.
Uno podría crear su framework o contribuir a marcos de código abierto. Por lo tanto,
hay una mejora continua en la funcionalidad.
Varios segmentos de código y funcionalidades están pre-construidos y probados
previamente. Esto hace que las aplicaciones sean más confiables.
Probar y depurar el código es mucho más fácil y puede hacerlo incluso los
desarrolladores que no poseen el código
El tiempo requerido para desarrollar una aplicación se reduce significativamente
¿Qué va en un frame?
Cuando instala un framework, lo primero que debe tener en cuenta son los
requisitos del sistema. Una vez que se instala y configura un marco, crea una
estructura de directorio”. (Singh, 2020). Uno de los frameworks es Netbeans, este
es un programa que permite la creación de software libre, de fácil uso y
comprensión para el desarrollo visual de aplicaciones.
7.3. Marco conceptual
7.3.1. Alfabetismo digital.
Bernal Pérez (2003) se refiere al término "ciberalfabetización" para denominar el
conocimiento y manejo de las herramientas digitales. En su trabajo, enfatiza en el
aspecto ético del acceso a la información digital. Afirma que "las habilidades para
orientarse satisfactoriamente en la red ayudarán también a las personas a
23
descubrir, usar y evaluar las fuentes de información que posibiliten su desarrollo,
tanto profesional como humano"(p.7).
Fueron Eshet-Alkalai (2004) y sus colegas quienes le dieron al alfabetismo digital
una forma más medible:
“… por ejemplo, “leer” instrucciones de una muestra gráfica en interfaces de
usuario; utilizar una reproducción digital para crear nuevos materiales significativos
de otros ya existentes; construir conocimientos de navegación nonlinear e
hipertextual; evaluar la calidad y la validez de la información; y tener un
entendimiento maduro y realista de las “reglas” que prevalecen en el ciberespacio”
(Sandoval R. 2015) .Ahora, es importante conocer este concepto pues es el
principal problema que posee la empresa, al ser sus fundadores analfabetas
digitales se han negado al cambio.
7.3.2. Tecnología de la información y la comunicación.
Cuando unimos estas tres palabras, Tecnologías de la Información y la
Comunicación (TIC), hacemos referencia al conjunto de avances tecnológicos que
nos proporcionan la informática, las telecomunicaciones y las tecnologías
audiovisuales, que comprenden los desarrollos relacionados con los ordenadores,
Internet, la telefonía, las aplicaciones multimedia y la realidad virtual. Estas
tecnologías básicamente nos proporcionan información, herramientas para su
proceso y canales de comunicación. (Mañas, 2019). Es el medio por el cual se
desea implementar la solución y a su vez, es el medio de trabajo de muchas de las
empresas ofreciendo una gran capacidad de competencia en el mercado.
7.4. Marco Legal
7.4.1. Ley estatutaria 1581 de 2012
Reglamentada parcialmente por el decreto Nacional 1377 de 2013.
Por la cual se dictan disposiciones generales para protección de usos personales.
Como la aplicación tratará con datos sensibles de los clientes y trabajadores como
lo son: direcciones, teléfonos, números de cédula, datos de beneficiarios, etc. Por
24
lo tanto, se debe garantizar lo concebido en esta ley. Para mayor información
revisar ley 1581 de 2012.
7.4.2. Licencia CDDL
“2.1. La subvención inicial para desarrolladores.
Condicional a Su cumplimiento con la Sección 3.1 a continuación y sujeto a
reclamos de propiedad intelectual de terceros, el Desarrollador Inicial le otorga una
licencia mundial, libre de regalías y no exclusiva:
(a) bajo derechos de propiedad intelectual (que no sean patentes o marcas
comerciales) Con licencia del Desarrollador inicial, para usar, reproducir, modificar,
mostrar, ejecutar, sublicenciar y distribuir el Software original (o partes del mismo),
con o sin Modificaciones, y / o como parte de una obra mayor; y
(b) en virtud de Reclamaciones de patentes infringidas por la fabricación, uso o
venta del Software original, para hacer, haber hecho, usar, practicar, vender y
ofrecer para la venta y / o deshacerse del Software original (o partes del mismo).
(c) Las licencias otorgadas en las Secciones 2.1 (a) y (b) entran en vigencia en la
fecha en que el Desarrollador Inicial distribuye por primera vez o pone el Software
Original a disposición de un tercero bajo los términos de esta Licencia.
(d) No obstante lo dispuesto en la Sección 2.1 (b) anterior, no se otorga ninguna
licencia de patente: (1) por el código que elimine del Software original, o (2) por
infracciones causadas por: (i) la modificación del Software original, o (ii) la
combinación del Software original con otro software o dispositivos.” (Open Source
Iniciative, s.f.)
Hipótesis
La implementación de un sistema de información para eventos producirá mayor
eficiencia en los procesos administrativos y operativos en la empresa Eventuales.
25
Variable independiente: Implementación de un sistema de información
para eventos.
Variable dependiente: Eficiencia en los procesos administrativos en la
empresa Eventuales.
Área de investigación
- Tema de investigación: Desarrollo de Software.
“El desarrollo de software moderno se distingue básicamente por dos
características: la programación orientada al objeto y la separación de las diferentes
etapas lógicas en nivel de presentación, de aplicación y de acceso a los datos.”
(voigtmann, s.f.).
- Línea: Diseño y desarrollo de sistemas informáticos.
Al utilizar una metodología se toman muchos factores a tener en cuenta, desde
modelamiento como investigación de todo el marco referencial de la empresa y su
problema y con base en eso se plantea la solución que satisfaga la necesidad.
- Tipo de investigación: Aplicada.
“Tipo de estudios científicos orientados a resolver problemas de la vida cotidiana y
a controlar situaciones prácticas. Actualmente, este tipo de investigación se
posiciona como un ámbito muy fértil, considerando la alianza establecida entre la
educación y la industria”. (duoc, s.f.)
- Enfoque: Cuantitativo.
“El enfoque cuantitativo de investigación se caracteriza por privilegiar la lógica
empírico-deductiva, a partir de procedimientos rigurosos, métodos experimentales
y el uso de técnicas de recolección de datos estadísticos”. (Mata Solis, 2019)
- Carácter de la Investigación: Descriptivo.
Su principal interés es explicar por qué ocurre un fenómeno y en qué condiciones
se da éste, o por qué dos o más variables están relacionadas. (Hernández,
Fernández & Baptista, s.f.)
26
Instrumentos de Recolección de Datos
10.1. Análisis documental
Se utiliza como herramienta para recavar información que ayude a soportar la
solución propuesta, poder organizar y conocer todos los beneficios y contratiempos
que posea cada una de las opciones que se le brindarán al cliente.
“Cuando se estudia un documento, se hace desde dos puntos de vista:
● Por un lado, su parte externa, es decir, en el soporte documental. A
esto se le llama Análisis Formal o Externo. Ayuda a identificar un
documento dentro de una colección.
● Por otro lado, se analiza el contenido del documento, es decir,
estudiar su mensaje, la temática sobre la que trata. A esta parte se le
conoce como Análisis de Contenido o Interno”.(Corral, 2015)
10.2. Encuesta
“La técnica de encuesta es ampliamente utilizada como procedimiento de
investigación, ya que permite obtener y elaborar datos de modo rápido y eficaz.”
(Casa Anguita, Repullo Labrador, & Donado Campos, 2003).
Se utilizará para preguntar, dialogar y discutir sobre las soluciones obtenidas en el
Análisis documental con los usuarios finales (aquellos que utilizarán y saben de
primera mano las problemáticas que posee la empresa).
10.3. Grupo focal
Un grupo de personas que han sido seleccionadas y convocadas por un
investigador con el propósito de discutir y comentar, DESDE SU PUNTO DE VISTA,
el tópico o tema propuesto por el investigador (Powell et al, 1996).
Con este instrumento se lleva a conversación los resultados que se obtienen al
implementar la herramienta con los altos cargos de varias empresas que, viendo
solicitudes de sus empleados y conociendo el negocio darán su punto de vista y
avalar el proyecto junto a sus funciones.
27
Validación del instrumento, población y muestra
11.1. Definición de la muestra
El tamaño de la muestra será de 12 personas, 8 de estos es la totalidad del personal
disponible en la empresa y 3 son gerentes de otras empresas de eventos radicadas
en la ciudad de Girardot pues estos serán los usuarios finales.
11.2. Aplicación de los instrumentos
Estos instrumentos se implementaron a mediados del segundo semestre del año
2019. Se pudo aplicar al 100% de la población sin excepción, esto gracias al tiempo
y tamaño de la muestra. Para mayor información de estos datos revisar anexos.
11.3. Tabulación
Encuesta:
PREGUNTA APP ESCRITORIO WEB
¿Conoce alguna de estos tipos de software?
7 8 6
¿Ha manejado alguna de estos tipos?
6 7 6
¿En cuál se desempeña mejor?
5 8 7
¿Cuál sería la mejor opción a implementar en la empresa?
4 8 8
Tabla 1. Encuesta. Fuente: Autor.
La encuesta fue propuesta para los trabajadores, para las personas que están al
frente del proceso,los usuarios que al final utilizarán la solución como herramienta
de trabajo diaria, ellos demuestran que tienen mayor conocimiento sobre la
aplicación de escritorio, pues sus procesos son de manera local y agilizaría mucho
28
las cosas, ya que comentan el hecho de que no dependen de la calidad del internet
para el procesamiento y solicitudes que haga la aplicación
Grupo focal:
En el grupo focal se debe tener en cuenta que los altos cargos de varias empresas
de eventos reunidos para este instrumento de recolección también fueron
sometidos a la encuesta y en la reunión se profundizó sobre la última pregunta:
siendo jefe y director de la empresa, ¿Cuál sería la mejor opción a implementar en
la empresa?
PREGUNTA APP ESCRITORIO WEB
Siendo jefe y director de la empresa, ¿Cuál sería la mejor opción a implementar en la empresa?
1 4 3
Tabla 2. Grupo focal. Fuente: Autor.
Con los altos cargos, se busca la respuesta con la experiencia y se tiene en cuenta
la opinión de los empleados. Estos directivos dan razón a sus empleados en que
(como está organizada la empresa y sus procesos) es mejor una aplicación de
escritorio que depende de la máquina y no de factores externos.
29
11.4. Análisis y resultados de los datos
Gráfica 1.
Resultados Encuesta.
Fuente: Autor.
En la Gráfica 1 se muestra la predominancia de la aplicación de escritorio sobre las
otras alternativas, los usuarios manifiestan que si bien la mayoría conocen todas
las opciones tienen mayor conocimiento y facilidad en uso las aplicaciones de
escritorio.
Gráfica 2. Resultados del grupo focal.
La Gráfica 2 demuestra que en el grupo focal también predomina el software de
escritorio, los altos cargos argumentaban que esta solución es mejor implementarla
30
de esa manera ya que tanto las cotizaciones como la organización de los eventos
se realiza en la oficina física.
Desarrollo de la metodología
12.1. Metodología Ágil
La metodología ágil es el modo que más se acomoda a las necesidades de los
usuarios pues este tipo de metodología implementa las sugerencias de los clientes
durante la etapa de producción del software.
12.2. Sxp
“Es una combinación de dos tipos de metodologías: XP y Scrum. Esta metodología
toma lo mejor de ambas y las implementa en la producción del software.
Desarrollada en el 2007 en la Universidad de las Ciencias Informáticas está
especialmente indicada para proyectos pequeños, con rápidos cambio de requisitos
donde existe un alto riesgo técnico y se orienta a una entrega rápida de resultados
y una alta flexibilidad.
12.2.1. Planificación
En esta fase es donde se establece la visión, se fijan las expectativas y se realiza
el aseguramiento del financiamiento del proyecto.
12.2.1.1 Actividades.
Entrevista con el cliente: escribir la visión (concepción del sistema), presupuesto y
reserva del producto con estimaciones iniciales.
Juego de la planificación: es un espacio frecuente de comunicación entre el cliente
y los programadores. El equipo técnico realiza una estimación del esfuerzo
requerido para la implementación de las historias de usuario y los clientes deciden
sobre el ámbito y tiempo de las entregas y de cada iteración.
Captura de requisitos.
● Creación de la LRP (Lista de Reserva del Producto).
● Priorización de la LRP.
● Definir las historias de usuario.
31
● Asignar las historias de usuario.
Valoración del esfuerzo.
Valoración de riesgos.
Diseño con las metáforas: el sistema es definido mediante una metáfora o un
conjunto de metáforas compartidas por el cliente y el equipo de desarrollo. Una
metáfora es una historia compartida que describe cómo debería funcionar el
sistema.
Refactorización: la refactorización es una actividad constante de reestructuración
del código con el objetivo de remover duplicación de código, mejorar su legibilidad,
simplificarlo y hacerlo más exible para facilitar los posteriores cambios.
Reunión de revisión del diseño.
12.2.1.2. Artefactos.
Plantilla de concepción del sistema: en esta plantilla se refleja la visión general del
producto a implementar, recoge los diferentes roles que intervendrán en el
desarrollo del software, así como las tecnologías usadas.
Plantilla LRP: es una lista priorizada que define el trabajo que se va a realizar en el
proyecto. Los posibles elementos de esta lista son requerimientos técnicos y del
negocio, funciones, y actualizaciones tecnológicas requeridas.
Plantilla Historia de usuario: en esta plantilla se especifican los requisitos del
software, las historias de usuarios son escritas por el cliente como las tareas que el
sistema debe hacer y su construcción depende principalmente de la habilidad que
tenga el cliente para definirlas, escritas en lenguaje natural y sin un formato
predeterminado.
Plantilla Lista de riesgos: en ésta son definidos los posibles riesgos que actuarán
sobre el proceso de desarrollo de software, así como la estrategia trazada para
mitigarlos.
Plantilla Modelo de diseño: en esta plantilla se dene un esbozo inicial del diseño del
sistema, sin entrar en especificaciones, ni detalles, solo lo que el diseñador necesita
para hacer una primera versión del sistema.
32
12.2.2. Desarrollo
Es la fase donde se realiza la implementación del sistema hasta que esté listo para
ser entregado.
12.2.2.1. Actividades.
Junta de planificación.
● Definir las historias de usuario a implementar.
● Definir las tareas para lograr la implementación.
Implementación.
● Estándar de código
Junta de seguimiento.
Taller técnico.
Junta de revisión.
Pruebas.
12.2.2.2. Artefactos.
Plantilla de Glosario de términos: recoge los términos que se relacionan con el
sistema y la metodología utilizada que pueden causar dudas al cliente para un
mejor entendimiento de todo el proceso de desarrollo de software.
Plantilla de Tareas de Ingeniería: en esta plantilla se recogen las tareas por historias
de usuario a realizar.
Plantilla Cronograma de producción: recoge las actividades realizadas en el equipo
de desarrollo durante la iteración. Se realiza un cronograma para cada iteración
planificada durante el proceso.
Plantilla de Plan de Release: cada una de las iteraciones que se van a desarrollar
para la realización del producto, la descripción del objetivo de la misma, el número
de historias de usuario que se van a implementar en cada una de las iteraciones
por orden de prioridad y la duración total que va a ser el tiempo estimado según las
HU propuestas en que demorara su implementación.
Estilo de código: plantilla con el estilo de código del o los lenguajes de programación
con los que se va a desarrollar la aplicación. Esto se hace ya que es importante
que los programadores del equipo de desarrollo sigan un determinado estándar de
33
código, lograr la comunicación de los programadores, pues todos no tienen la
misma forma de programar, se pueden seguir estándares del mismo equipo, de la
organización a la cual pertenecen u otros estándares reconocidos para los
lenguajes de programación que se utilizan, fundamentales cuando los
programadores cambian de compañeros, con esto se consigue un código legible,
con el mismo estilo y homogéneo.
Código fuente: esto no es una plantilla sino un indicativo del código fuente
comprimido y además otro paquete compilado con sus dependencias.
Plan de Pruebas: contiene el listado de historias de usuarios que serán probadas,
el cronograma con las observaciones realizadas a cada tarea de las historias de
usuario probadas. Recoge además el resultado de las pruebas unitarias, de las
pruebas de instalación y configuración, de las pruebas de seguridad, pruebas de
recuperación y tolerancia a fallos y por último la evaluación de las pruebas.
Plantilla Caso de Prueba de aceptación: en esta plantilla el desarrollador escribe
las pruebas realizadas según la historia de usuario seleccionada para realizar la
comprobación y validar las funcionalidades del sistema, y de esta forma saber si
está apto para ser liberado. Para la realización de la misma se debe tener en cuenta
el tipo de prueba que se va a aplicar, de Caja Negra o de Caja Blanca, contiene los
casos de prueba de aceptación que se realizan a diferentes funcionalidades que
recogen el código del caso de prueba, con el nombre de la historia de usuario a la
que le va a realizar la prueba, nombre de la persona que la realiza, la descripción
de la misma, las condiciones de ejecución; que son las condiciones necesarias para
poder realizar la prueba, el resultado esperado y la evaluación de la prueba.
12.2.3. Entrega
Fase donde se pone en marcha el producto desarrollado y se hace la entrega al
cliente.
12.2.3.1. Actividades.
Entrega de la documentación.
Entrenamiento.
Marketing.
34
12.2.3.2. Artefactos
Manual de desarrollo: es una plantilla realizada por los desarrolladores, donde se
recoge todo lo relacionado con las pautas realizadas para la programación del
sistema.
Instalador. (.deb, .exe y .tar.gz)
Cursos de capacitación: los cursos de capacitación que se le dan al cliente y otros
interesados que utilizarán el producto.
12.2.4. Mantenimiento
En esta se realiza el soporte para el cliente.
12.2.4.1. Actividades.
Soporte.
12.2.4.2. Artefactos
Plantilla de Gestión de cambios: esta plantilla guarda los cambios realizados en el
sistema una vez es terminado el producto y se pasa a la fase donde se mantiene
dándole soporte al cliente. Recoge los datos para identificar el nombre de la historia
de usuario de donde se deriva el cambio, quien lo realiza y el lugar donde ocurre la
actualización del código.
Registro Legal
En la actividad de registro se generan los siguientes artefactos, los cuales deben
ser registrados:
Manual de usuario: en esta plantilla el desarrollador realiza una guía de los pasos
necesarios y de conceptos de aspectos importantes con los que cada uno de los
usuarios podrá consultar en caso de dudas para interactuar con el sistema.
Manual de identidad: el diseñador debe hacer una caracterización general de los
aspectos que se tomaron en cuenta para la realización del diseño del
sistema.”(Orozco Vaillant).
12.3. Herramientas y Diagramas
En el desarrollo de la aplicación final, se utilizaron las siguientes herramientas para
el diseño, desarrollo y pruebas:
● Netbeans
35
● Visual Studio Code
● phpMyAdmin
● Visio 2016
Requerimientos
13.1. Requerimientos funcionales
Se quiere que el programa permita la revisión de la totalidad del personal en tablas
dentro de los grupos a los cuales pertenece.
Se quiere que el programa permita conocer la información que posee el cliente en
el sistema en una vista nueva.
El programa hará manejo de cuentas diarias teniendo en cuenta ingresos y gastos.
Mostrará al personal pendiente por pago organizado por empresas y grupos que se
estén manejando en una vista nueva.
13.2. Requerimientos no funcionales
Todos los sistemas deben respaldarse cada 24 horas.
El tiempo de aprendizaje del sistema por un usuario deberá ser menor a 3 horas.
El sistema debe contar con manuales de usuario estructurados adecuadamente.
13.3. Requerimiento de seguridad
Los permisos de acceso al sistema podrán ser cambiados solamente por el
administrador de acceso a datos.
El sistema incluirá un procedimiento de autorización de usuarios, en el cual los
usuarios deben identificarse usando un nombre de usuario y contraseña. Sólo los
usuarios autorizados de esta forma podrán acceder a los datos del sistema.
36
13.4. Historias de usuario
ITEM ROL EVENTO FUNCIONALIDAD
1 ADMINISTRADOR Tener control sobre las cuentas de usuario
Crear o eliminar cuentas según sea necesario
2 ASESORA Crear eventos Su manejo correspondiente
3 RECURSOS HUMANOS
Listado de personal disponible
Asignar a eventos
4 GERENTE FINANCIERO
Saber que personal trabajó
Hacerles el respectivo pago
5 RECURSOS HUMANOS
Conocer la lista de empleados
Hacer despidos
Tabla 3. Historias de usuario.
13.6. Lista de Reserva del producto (LRD)
1. Crear cuentas de usuario para Log In.
2. Crear lista de eventos.
3. Crear listado del personal.
4. Cálculo de nómina.
Análisis del sistema actual
14.1. Diagnóstico del sistema actual
En la empresa eventuales manejan todos sus procesos de manera manual
(talonarios y agendas), tanto la organización del personal para sus eventos como
las cuentas, requerimientos del evento y pago de personal.
La organización de personal toma cerca de 1 día completo, medio día revisando el
personal disponible y el otro medio asignando el personal.
El calcular las cuentas diarias lleva entre 1 y 2 horas, revisando uno por uno los
talonarios y digitalizando cada detalle de estos.
El pago de personal varía entre 3 a 5 días pues deben revisar los listados de
eventos asignados y calcular manualmente el número de días a cancelar si no es
directo por la empresa.
La suma de todos estos procesos da como resultado 6 días con 2 horas el dar como
terminado un evento. En estas cuentas no se está tomando en cuenta los días que
puede llegar a tener el evento en sí.
37
14.2. Definición de los casos de uso
RECURSOS HUMANOS: Son las personas encargadas de la nómina
laboral, desde la contratación hasta los retiros.
COORDINADOR: Es la persona encargada de los equipos y materiales,
desde su creación hasta dar de baja y también de estar al tanto del listado
de empleados para su asignación.
ASESOR: Es la persona encargada de la creación y administración de los
eventos.
38
Cada caso de uso se encuentra en el área correspondiente, por lo que es fácil
entender que significa en cada caso. Si se encuentra en el recuadro “Nomina
laboral” hace referencia a los empleados, si se encuentra en el recuadro “Equipos
materiales” hace referencia a los recursos y por último el recuadro de “Eventos” es
todo lo relacionado con ellos.
Figura 1. Casos de uso Sistema actual.
14.3. Definición del modelo conceptual
Figura 2. Modelo conceptual de Sistema actual.
39
14.4. Definición del diagrama de colaboración
Figura 3. Diagrama de colaboración sistema actual
14.5. Definición del diseño de clases
Figura 4. Diagrama de clases sistema actual.
40
Según el sistema actual, la única diferencia entre cada clase son las funciones de
cada uno, pues, el sistema esta tan desordenado, que no hay atributos que
diferencien a uno del otro.
Diseño y desarrollo del sistema propuesto
15.1. Diccionario de datos
Tabla 4. Tabla persona.
Tabla 5. Tabla agenda.
Tabla 6. Tabla cliente.
Column
nameDataType PK NN UQ BIN UN ZF AI Default Comment
num_doc VARCHAR(15) ✔ ✔
tipo_doc
ENUM('cc',
'ce', 'ti', 'nit',
'pep')
✔
nombres VARCHAR(45) ✔
apellidos VARCHAR(45) ✔
telefono VARCHAR(11)
direccion VARCHAR(45)
Persona
Column
nameDataType PK NN UQ BIN UN ZF AI Default Comment
idagenda INT ✔ ✔ ✔
fecha DATE ✔
trabajador INT(11) ✔
evento INT ✔
agenda
Column
nameDataType PK NN UQ BIN UN ZF AI Default Comment
idcliente DOUBLE ✔ ✔
rsocial VARCHAR(45)
num_doc VARCHAR(15) ✔
cliente
Column
nameDataType PK NN UQ BIN UN ZF AI Default Comment
idcompra INT ✔ ✔ ✔
fecha DATE ✔
valor INT
proveedor DOUBLE ✔
idcuentas INT ✔
compra
41
Tabla 7. Tabla compra.
Tabla 8. Tabla cuentas.
Tabla 9. Tabla det_compra.
Tabla 10. Tabla detpago.
Tabla 11. Tabla evento.
Column
nameDataType PK NN UQ BIN UN ZF AI Default Comment
idcuentas INT ✔ ✔
fecha DATE ✔
total DOUBLE
cuentas
Column
nameDataType PK NN UQ BIN UN ZF AI Default Comment
serial INT ✔ ✔ ✔
cant INT ✔
costo INT ✔
idcompra INT ✔
codbarras DOUBLE ✔
det_compra
Column
nameDataType PK NN UQ BIN UN ZF AI Default Comment
iddtepago INT ✔ ✔
valort VARCHAR(45) ✔
idtrabajador DOUBLE ✔
idnomina INT ✔
detpago
Column
nameDataType PK NN UQ BIN UN ZF AI Default Comment
idevento INT ✔ ✔ ✔
nombre VARCHAR(45) ✔
fecha DATE ✔
horario
ENUM('Maña
na', 'Tarde',
'Noche')
✔
telefono BIGINT(11) ✔
direccionVARCHAR(10
0)✔
hora VARCHAR(10) ✔
estado
ENUM('venci
do', 'a
tiempo',
'impreso')
✔ 's tiempo'
cliente DOUBLE ✔
paquete INT ✔
evento
42
Tabla 12. Tabla nómina.
Tabla 13. Tabla paquete.
Tabla 14. Tabla proveedor.
Tabla 15. Tabla recursos.
Column
nameDataType PK NN UQ BIN UN ZF AI Default Comment
idnomina INT ✔ ✔
valor INT ✔
fecha DATE ✔
cuentas INT ✔
nomina
Column
nameDataType PK NN UQ BIN UN ZF AI Default Comment
idpaquete INT ✔ ✔ ✔
nompaq VARCHAR(45) ✔
tipevent
ENUM('cumpl
eaños',
'boda',
'quinceaños',
'despedida')
✔
valor INT
paquetes
Column
nameDataType PK NN UQ BIN UN ZF AI Default Comment
num_doc VARCHAR(15) ✔ ✔
tipo_doc
ENUM('cc',
'ce', 'ti', 'nit',
'pep')
✔
rsocial VARCHAR(45) ✔
direccion VARCHAR(45) ✔
telefono VARCHAR(11) ✔
proveedor
Column
nameDataType PK NN UQ BIN UN ZF AI Default Comment
codbarras VARCHAR(10) ✔ ✔
nombre VARCHAR(45) ✔
stock INT ✔
retornableENUM('si',
'no')✔
valor INT
detalle VARCHAR(45)
recursos
43
Tabla 16. Tabla requerimientos.
Tabla 17. Tabla trabajador.
Column
nameDataType PK NN UQ BIN UN ZF AI Default Comment
idreq INT ✔ ✔ ✔
cant INT ✔
idpaquete INT ✔
codbarras DOUBLE ✔
requerimientos
Column
nameDataType PK NN UQ BIN UN ZF AI Default Comment
idtrabajado
rINT(11) ✔ ✔
usuario VARCHAR(45)
clave VARCHAR(45)
cargo
ENUM('AUX
ADMON',
'GERENTE',
'CONTADOR')
✔
num_doc VARCHAR(15) ✔
trabajador
44
15.2. Modelo Relacional
Figura 5. Modelo relacional.
Para ver el modelo completo revisar anexos Figuras/Figura 5.
45
15.3. Secuencia
Figura 6. Diagrama de secuencia. Fuente: Autor.
15.4. Modelo entidad-relación
46
Figura 7. Modelo entidad relación. Fuente: Autor.
Para ver el modelo completo ir a anexos Figuras/Figura 7.
Análisis de riesgos
A continuación, se muestran los factores que pueden afectar negativamente el
proyecto generando retrasos, omisiones de actividades, y hasta la interrupción del
mismo. Se efectúa el análisis de cada uno de los riesgos con el fin de identificar
claramente cada uno de ellos y, poder idear un plan de contingencia que permita la
conclusión efectiva y exitosa del proyecto. A la hora de determinar los posibles
riesgos del proyecto debe realizarse una descripción efectiva de los estos mismos,
para esto se deben tener en cuenta ciertos aspectos:
16.1 Definición de escalas.
Impacto: Establece un orden de atención que se debe prestar al riesgo descrito.
La escala del impacto se estableció en un rango de 1 a 5 siendo 1 el valor menor
impacto y 5 el de mayor impacto, como se muestra a continuación:
DESCRIPCIÓN VALOR
Muy bajo 1
Bajo 2
Medio 3
Alto 4
Muy alto 5
Tabla 18. Definición de escalas. Impacto.
Prioridad: Permite identificar la probabilidad y el impacto para establecer la
atención que se debe prestar al riesgo ocasionado. La escala de prioridad se
establece del mismo modo que la de impacto, de 1 a 5 según su valor de
importancia.
47
DESCRIPCIÓN VALOR
Muy bajo 1
Bajo 2
Medio 3
Alto 4
Muy alto 5
Tabla 19. Definición de escalas.
16.2. Posibles riesgos del sistema.
● Falta de disponibilidad de herramientas necesarias como, tapete electrónico
o pantallas, para el desarrollo de actividades.
● Pérdida de información por factores externos como manipulación indebida,
virus, daños en hardware, violación en la seguridad, entre otros.
● Cuidado o manipulación indebida del tapete electrónico.
● La dificultad de aprendizaje por parte del personal, ya que, alguno de los
empleados son analfabetas digitales.
16.3. Identificación de factores y evaluación de riesgos
Durante la definición de los riesgos se identifican los posibles factores que pueden
presentarse en el sistema, dichos factores se muestran a continuación:
16.3.1. Factor Humano.
Se refiere a las personas involucradas en el desarrollo del proyecto. Se identifica
como un factor indispensable para una culminación exitosa, una afección negativa
a este factor representa una amenaza significativa al proyecto.
RIESGO PRIORIDAD IMPACTO RESPUESTA ESTRATEGIA
Enfermedad o accidente de alguno de los
5 5 ACEPTAR Suplir actividades de integrante o en su defecto replantear el
48
involucrados del proyecto.
cronograma de actividades.
Fallas humanas durante el proceso de desarrollo e implementación del proyecto.
4 4 PREVENIR Corregir errores, hacer pruebas que permitan identificar los errores y hacer retroalimentaciones sobre los procesos para evitar reincidencias.
Tabla 20. Riesgos del factor humano.
16.3.2. Factor técnico o tecnológico.
Se refiere a los recursos de hardware o software relacionados con el todo el proceso
desarrollo, puede sufrir una afectación directa o indirecta como daños irreparables
por mal manejo o manipulación. Se identifica como un factor indispensable para la
culminación exitosa del proyecto, una afectación negativa a este factor podría
representar costos adicionales, retrasos, pérdida de tiempo, entre otros.
RIESGO PRIORIDAD IMPACTO RESPUESTA ESTRATEGIA
Fallas de hardware
5 5 PREVENIR Mantenimiento constante según tiempos estipulados.
Fallas de software
5 5 PREVENIR Mantenimiento preventivo según tiempos estipulados.
Daño o hurto de equipos.
4 3 PREVENIR Buen manejo de los equipos y protección física a elementos de fácil acceso.
Tabla 21. Riesgos factor técnico o tecnológico.
16.3.3. Factor Organizacional.
Se refiere a la planificación y organización de cada una de las actividades
necesarias para el desarrollo del proyecto que define los tiempos estimados de
realización. Se identifica como un factor importante en el proyecto, una afectación
negativa sobre este factor puede representar retrasos, pérdida de tiempo, costos
adicionales.
49
RIESGO PRIORIDAD IMPACTO RESPUESTA ESTRATEGIA
Falta de tiempo para el desarrollo del proyecto
4 4 PREVENIR Acoplarse al cronograma de actividades.
Cambio de algunos requerimientos
5 5 ACEPTAR Reestructurar los nuevos requerimientos para incluirlos.
Tabla 22. Riesgos factor organizacional.
16.3.4. Factor del hardware.
N° RIESGO PRIORIDAD IMPACTO SOLUCIÓN
1 Daño de la batería del computador
1 2 Dado caso que el computador sea portátil se puede seguir usando con el cargador.
2 Daño del cargador 2 1 Ya que sin haber toma alguna el computador no se podrá prender tratar de conseguir un cargador o ver la manera de trabajar en otro.
3 Daño del computador 2 1 Dado caso que el computador se dañe tratar de tener respaldo o tratar de conseguir otro
4 Fallas eléctricas 3 1 Por lo general se debe contar con una planta eléctrica. Cuando el riesgo sea por daño de corto verificar contar con una ups o estabilizador y estar revisando constantemente los cables de energía verificando que no haya cables sueltos o algún daño referente a cortocircuitos.
Tabla 23. Factor del hardware
En la anterior tabla se observa los riesgos que podrían ocurrir en la parte del
hardware, especificando la importancia que uno de estos daños traería ya que son
materiales indispensables para poder ejecutar los programas que se vayan a
utilizar.
50
16.3..4.1. Prioridad.
LISTADO DE RIESGOS PRIORIDAD
Accidente 3
Enfermedad 4
Virus en el sistema 5
Desastre natural 6
Fallas eléctricas 7
Traslado a una ciudad 8
Robo de equipos 9
Daño del computador 11
Daño del cargador 12
Daño de la batería del computador 13
Tabla 24. Prioridad
16.3.5. Conclusión del análisis de riesgos.
Una vez listados los riesgos terminan en los 3 primeros puestos:
1. Fallas del hardware
2. Falles del software
3. cambio en los requerimientos
Sobre los cuales se implementarán las siguientes mitigaciones respectivamente:
1. Mantenimiento de los equipos en el tiempo establecido.
2. Mantenimiento preventivo y mesa de ayuda.
3. Reestructurar y estudiar los nuevos requerimientos para incluirlos.
Los demás riesgos, si bien pueden ocurrir, se mitigan con el desarrollo del proyecto,
pues muchos de ellos se pueden encontrar las soluciones al dialogar con los
encargados y brindar la mejor opción que satisfaga a ambas partes.
51
Análisis del proyecto
17.1. Estudio de factibilidad
La metodología se creará con de acuerdo a las necesidades de los empleados de
la empresa Eventuales según el desorden provocado por la gran cantidad de
papeleo y procesos analógicos que se realiza en dicha entidad.
La herramienta implementada brindará mejoras en el tiempo de atención y calidad
de los servicios que la empresa brinda.
● Hardware: corresponden a todas las partes tangibles de un sistema
informático los cuales se necesitarán a lo largo del proyecto (computadoras,
unidades de almacenamiento, salas de trabajo y periféricos como
impresoras y escáneres para la documentación necesaria.
● Software: todos aquellos programas en los cuales se desarrollarán el
software, bases de datos, es decir, el equipamiento lógico de un sistema
informático.
● Documentación: Manuales necesarios que se les darán a la empresa para
que entiendan lo necesario del proyecto y los alcances que este posee.
17.1.1. Factibilidad técnica.
La empresa cuenta con 6 equipos disponibles, 4 se encuentran en el área de
atención al cliente y 2 para el área de gerencia.
Los equipos deberán estar capacitados para el acceso a:
● impresoras adecuadas para su respectiva facturación.
● tomas de energía eléctrica disponibles para las conexiones de los equipos.
● mouse y teclados en buen estado.
● acceso a internet.
En lo que respecta al software, la empresa cuenta las aplicaciones necesarias lo
cual significa que las herramientas poseen ningún costo y no amerita inversión
alguna. Las estaciones de trabajo, operarán bajo ambiente Windows.
● equipos debidamente configurados con el software en buen uso.
● claves de acceso de personal autorizado.
52
17.1.2. Factibilidad económica.
En este caso se maneja de forma de contraprestaciones, en la cual la empresa
recibirá un programa que beneficiará la productividad y de parte del investigador un
ambiente en el cual puede realizar su investigación y a la vez realizar la
implementación del producto.
17.1.2.1. Presupuesto
ETAPA DEFINICIÓN DURACIÓN
COSTO
PROPUESTA Generar una idea que sirva de solución al problema.
1 Mes $150.000
ANTEPROYECTO Documento cuya finalidad es dar a entender todos los elementos
del problema y el paso a paso de la solución.
5 Meses
$140.000
ANÁLISIS Y DISEÑO
Etapa en la cual se realiza la recolección de datos y se
estudian para ver qué tan verídica sería la propuesta.
6 Meses
Insumos de oficina Se hace referencia al costo de papeleo e impresiones, junto a carpetas y demás artículos de
oficina.
$20.000
Insumos de Hardware
Corresponde a todos aquellos dispositivos electrónicos
necesarios para el proyecto, como los son: computadores,
impresoras y demás.
$300.000
Transporte Es el costo de los viáticos de 1 visita al día hábil por los 6 meses
que dura la etapa.
$120.000
DESARROLLO Etapa en la cual se empieza a desarrollar el software.
6 meses
$13’000.000
IMPLEMENTACIÓN Etapa en la cual se entrega el sistema y se realizan
capacitaciones
1 mes $120.000
Total $13’850.000
53
Tabla 25. Factibilidad económica.
17.1.3. Factibilidad judicial.
Las herramientas que se usarán a lo largo del proyecto son herramientas basadas
en software libre con licenciamientos libres al público que manejara un código
fuente reutilizable.
17.1.4. Factibilidad ética.
Como desarrollador que soy formado por la Universidad Piloto de Colombia hago
énfasis en la responsabilidad que adquiero como profesional, con un código ético
que me hace ejercer un buen perfil de responsabilidad ante este proyecto, para esto
se tiene en cuenta el código ético de un ingeniero:
1.01. Aceptar la completa responsabilidad de su trabajo.
1.02. Mitigar sus propios intereses, los del empresario, los del cliente y los de los
usuarios con los del bienestar público.
1.03. Dar el visto bueno al software sólo si se tiene fundada creencia de que es
seguro, de que cumple las especificaciones, de que ha pasado las pruebas
pertinentes y de que no disminuye la calidad de la vida, la confidencialidad ni daña
el medio ambiente. El efecto último del trabajo debería ser el bienestar público.
1.04. Revelar a las personas o autoridades correspondientes cualquier peligro real
o potencial para el usuario, la sociedad o el medio ambiente, peligro que
razonablemente consideren que está asociado con el software o con documentos
relacionados.
1.05. Cooperar en las materias relacionadas con preocupaciones graves causadas
por el software, su instalación, mantenimiento, soporte o documentación.
1.06. Ser justos y veraces en todas las afirmaciones, especialmente en las que sean
públicas, relativas al software o a documentos, métodos y herramientas
relacionados.
1.07. Considerar las cuestiones de discapacidades físicas, asignación de recursos,
desventajas económicas y otros factores que puedan disminuir el acceso a los
beneficios del software.
54
2.02. No utilizar conscientemente software obtenido o retenido de manera ilegal o
no ética.
2.03. Utilizar la propiedad de un cliente o patrón sólo de maneras adecuadamente
autorizadas, y con el conocimiento y el consentimiento de éste.
2.04. Garantizar que cualquier documento en el que se confía ha sido aprobado,
cuando así se requiera, por alguien con autoridad para hacerlo.
2.05. Mantener como privada cualquier información confidencial obtenida mediante
el trabajo profesional, siempre que tal confidencialidad no sea inconsistente con los
aspectos de interés general ni con la ley.
2.06. Identificar, documentar, recoger evidencia e informar con prontitud al cliente
o al empresario si, en su opinión, existe la probabilidad de que un proyecto fracase,
resulte demasiado caro, viole la legislación sobre propiedad intelectual o sea
problemático.
2.07. Identificar, documentar e informar al empresario o al cliente sobre cualquier
asunto de interés social, o del que se tenga conocimiento, acerca del software o de
documentos relacionados.
2.08. No aceptar trabajo externo que vaya en detrimento de aquél que desarrollen
para su principal contratante.
3.14. Mantener la integridad de los datos, siendo sensibles a aquéllos que estén
obsoletos o equivocados.
4.04. No involucrarse en prácticas financieras engañosas, tales como sobornos,
dobles facturaciones u otras prácticas impropias.
4.05. Comunicar a todas las partes los conflictos de intereses que no puedan
evitarse razonablemente.
5.03. Garantizar que los empleados conocen las políticas y los procedimientos del
empresario para la protección de las claves de acceso, ficheros y otra información
que sea confidencial para el empresario o para otros.
17.1.5. Factibilidad Operativa.
Teniendo en cuenta los factores anteriores y cualquier alternativa posible se
desarrollara este proyecto en la empresa con la finalidad de garantizar el buen
55
funcionamiento del sistema y que este impactara a nivel comercial en forma positiva
a los clientes y usuarios, este fue desarrollado en forma estándar a los sistemas
existentes en la empresa, presentando una interfaz amigable a los trabajadores, lo
que se traduce en una herramienta de fácil manejo y comprensión, contando con la
opinión de los empleados para cualquier modificación del sistema.
A medida de la planificación del proyecto se llevó a cabo la aceptación del mismo,
que de una manera más sencilla y amigable, cubra todos sus requerimientos,
expectativas y proporcionan la información en forma oportuna y confiable.
17.1.6. Cronograma
NOMBRE DE LA TAREA DURACIÓN COMIENZO FIN
1 INICIALIZACIÓN 7 Días 01/08/2019 07/08/2019
2 Estudio previo 3 Días 05/08/2019 07/08/2019
3 PLANEACIÓN 30 Días 08/08/2019 07/09/2019
4 Estudio del sistema actual
7 Días 08/08/2019 14/08/2019
5 Recolección de datos 15 Días 15/09/2019 29/08/2019
6 Definición de tareas 2 Días 30/08/2019 31/08/2019
7 Presupuesto 1 Día 01/09/2019 01/09/2019
8 ANÁLISIS DEL PROYECTO
15 Días 02/09/2019 16/09/2019
9 Análisis de la información
7 Días 17/09/2019 23/09/2019
10 Selección de herramientas
3 Días 24/09/2019 26/09/2019
11 DESARROLLO 6 Meses 27/09/2019 27/03/2020
12 IMPLEMENTACIÓN 30 Días 28/03/2020 28/04/2020
Tabla 26. Factibilidad operativa.
56
Pruebas
Para dar veracidad del programa y que se está desarrollando según lo acordado
(historias de usuario), el sistema de información se somete a varios tipos de
pruebas durante su desarrollo, entre estas pruebas se encuentran:
18.1. Prueba Unitaria
“Se focaliza en ejecutar cada módulo (o unidad mínima a ser probada, ej.= una
clase) lo que provee un mejor modo de manejar la integración de las unidades en
componentes mayores. Como se viene trabajando, cada vez que un módulo se
termina, se somete a esta prueba para asegurar el buen funcionamiento interno
(por partes) del programa.” (Abad Londoño, 2005).
La prueba unitaria es para precisamente tener una inclusión del usuario en el
proyecto como lo sugiere la metodología, con la búsqueda de solucionar problemas
de poco impacto al proyecto en pequeños módulos del mismo, como pueden ser
información visualizada: pueden encontrarse duplicidad en la información mostrada
de una de las pestañas. Para mayor ampliación por favor remítase a anexos
“Pruebas del sistema” Pag 1 - 4.
18.2. Pruebas de Humo
“Pruebas de humo son el Subconjunto de todos los casos de prueba
definidos/planificados que cubren la funcionalidad principal de un componente o
sistema, con el objeto de asegurar que las funciones cruciales de un programa
funcionan, pero sin preocuparse por los detalles finos.” (Globe, s.f.)
En el proyecto estas pruebas son tomadas como unión de las dos anteriores, pues
se hace una prueba unitaria por cada módulo y se revisa en conjunto todas las
funciones principales con la regresión.
Para mayor ampliación remítase al anexo “Pruebas del sistema” Pag 5.
Recomendaciones
Cualquier situación que requiera revisión para el manejo del sistema de
información, remítase al manual de usuario anexo a este proyecto.
57
Por favor, leerlo detenidamente, ya que, en este se dan soluciones a posibles
errores del usuario frente al sistema, o en debido caso, se muestra el paso a paso
para evitar errores.
Para un mejor desarrollo en un proyecto de software, se recomienda la utilización
de metodologías Ágiles, ya que con estas se conoce de antemano los errores y
recomendaciones que el usuario (con más participación al momento del desarrollo)
reconozca y esto genere un mejor resultado.
Conclusiones
Los procesos administrativos son: el manejo de caja, papeleo de cuentas, recursos
humanos (afiliaciones a su respectiva seguridad social). Y operativas se
encuentran: asignación de personas, asignación de recursos, seguimiento a
eventos.
Como se busca algo de fácil acceso y manejo se utiliza un lenguaje libre (Java) que
no consume muchos recursos en hardware y software y puede ser implementado
en cualquier ambiente.
Se demuestra que, con las funciones desarrolladas en el programa, los procesos
de la empresa son menos engorrosos y más rápidos, como se demuestra en la
siguiente tabla:
PROCESO TIEMPO
ANTES AHORA
Creación del evento 1 día 10 – 15 min
Asignación de personal 2 – 3 días 10 – 15 min
Cierre de caja 1 – 2 horas 15 – 20 min
Análisis de ventas 3 – 5 días 10 – 15 min
Tabla 27. Resultados de la implementación.
Esta implementación demuestra un sistema organizado, sin duplicidad de los datos
como se presentaba anteriormente.
Al crear los usuarios y sus permisos se enmarcan las funciones y disposiciones de
cada cargo obteniendo un mejor control en la empresa.
58
Referencias
Marín, J. (2003). El analfabetismo tecnológico. Monografías. com. Lucas Morea/Sinexi, SA 2003. http://www. monografias.com/trabajos12/elanolftc2.shtml.
Morales Capilla, M., Trujillo Torres, J. M., & Raso Sánchez, F. (2015). Percepciones
acerca de la integración de las TIC en el proceso de enseñanza-aprendizaje de la universidad. Píxel-Bit. Revista de Medios y Educación, 46, 103-117.
Sáez Vacas, F. (1990). Ofimática compleja. Fundación para el Desarrollo de la
Función Social de las Comunicaciones. Piscitell, A., (2009), Nativos digitales. Obtenido de
http://www.terras.edu.ar/biblioteca/2/Laalfabetizaciondigitalcomonuevainfraestructura.pdf
Universidad Nacional de Colombia - Sede Medellín. (s.f.). Universidad Nacional de
Colombia - Sede Medellín: Ofimática. Recuperado 18 septiembre, 2019, de http://xue.medellin.unal.edu.co/moodle/course/index.php?categoryid=3
Guerrero, Dávila, Guadalupe. Metodología de la investigación, Grupo Editorial
Patria, 2014. ProQuest Ebook Central, https://ebookcentral.proquest.com/lib/upilotosp/detail.action?docID=3228613.
Andrade, B., Lucía. Analfabetismo tecnológico: efecto de las tecnologías de
información, Red Actualidad Contable Faces, 2005. ProQuest Ebook Central, https://ebookcentral.proquest.com/lib/upilotosp/detail.action?docID=3161887.
Barcelo, M. (2018, 8 enero). Analfabetismo digital. Recuperado 25 octubre, 2019, de https://upcommons.upc.edu/handle/2117/112444
Metodología cuantitativa y cualitativa para mirar las estrategias de aprendizaje.
(2019). Retrieved from http://search.ebscohost.com.ezproxy.unipiloto.edu.co/login.aspx?direct=true&db=edsbas&AN=edsbas.D9D6A198&lang=es&site=eds-live
Hernández, M. A., & Olmos, M. S. (Eds.). (2011). Metodologías de aprendizaje
colaborativo a través de las tecnologías. Retrieved from https://ebookcentral.proquest.com
59
Arancón, P. D. (2015). Adecuación de la normativa de acotación a las t.i.c. : Propuesta de nueva norma. Retrieved from https://ebookcentral.proquest.com
Sandoval Almazán, R. (2015). Interfase para reducir el analfabetismo digital en las
personas de escasos recursos y aminorar la brecha digital en México. Retrieved from http://search.ebscohost.com.ezproxy.unipiloto.edu.co/login.aspx?direct=true&db=edsbas&AN=edsbas.744A1F90&lang=es&site=eds-live
Eshet-Alkalai Alkali & Yair Amichai-Hamburger (2004) Experiments in Digital
Litercy. CyberPsychology & Behavior 7, 421-429 Pérez Mazatan, (Ed.) 2004. Cerrando la brecha digital en México: Avances y
Perspectivas. Foro Gobierno DIgital: Mañas Pérez, A., & Roig-Vila, R. (2019). Las Tecnologías de la Información y la
Comunicación en el ámbito educativo. Un tándem necesario en el contexto de la sociedad actual. Retrieved from http://search.ebscohost.com.ezproxy.unipiloto.edu.co/login.aspx?direct=true&db=edsbas&AN=edsbas.3500E51A&lang=es&site=eds-live
Hernández, S., Fernández, A., & Baptista, B. (s.f.). Metodología de la investigación.
In M. C. Ed Gracias hill (Ed.), Capítulo IV (pp. 23–63). Recuperado de https://www.google.com/url?sa=t&source=web&rct=j&url=http://catarina.udlap.mx/u_dl_a/tales/documentos/lcp/texson_a_gg/capitulo4.pdf&ved=2ahUKEwiuhbKhyNPnAhUro1kKHYInDAcQFjABegQIDhAH&usg=AOvVaw2c2hAHxJZ-cugs-FB1Rfdc
Orozco Vaillant, M. E. (s.f.). Informe de investigación. Bayamo. Recuperado el 26
de Febrero de 2020 eventtia. (2020). eventtia. Recuperado el 29 de Febrero de 2020, de Software de
organización de eventos: https://www.eventtia.com/es/inicio Hamidian Fernández , B. F., & Ospino Sumoza, G. R. (2015). ¿Por qué los sistemas
de información son esenciales? Recuperado el 28 de Febrero de 2020, de http://servicio.bc.uc.edu.ve/derecho/revista/idc38/art07.pdf
tu fabrica deventos. (2016). tufabricadeventos. Recuperado el 29 de Febrero de
2020, de Software para eventos: https://www.software-para-eventos.com/acerca-de-nosotros
60
Amorós, E., Díaz, D., & León, C. (Enero de 2007). eumed.net. Recuperado el 29 de Febrero de 2020, de TOMA DE DECISIONES PARA NEGOCIOS: CASOS PRÁCTICOS: http://www.eumed.net/libros-gratis/2007a/261/13.htm
Corral, A. M. (2 de Marzo de 2015). Dokutekana. Obtenido de https://archivisticafacil.com/2015/03/02/que-es-el-analisis-documental/
Powell R.A. and Single H.M. (1996) 'Focus groups', International Journal of Quality in Health Care 8 (5): 499-504
Casa Anguita, J., Repullo Labrador, J., & Donado Campos, J. (2003). La encuesta como técnica de investigación. Elaboración de cuestionarios y tratamiento estadístico de los datos. Atención Primaria, 527-538.
Mero Suarez, K. (6 de Septiembre de 2011). Sistemas de información. Obtenido de Ventajas y desventajas de utilizar S.I.: https://blogereducativo.wordpress.com/2011/09/06/ventajas-y-desventajas-de-utilizar-s-i/
Moreno Henao, K. M., & Duque Martinez, M. D. (2013). Medición de la productividad en el área administrativa de Compras y suministros de Comfamiliar Risaralda: una propuesta de mejora continua. Pereira: Universidad tecnológica de Pereira.
Zoho. (s.f.). Zoho. Recuperado el 23 de Abril de 2020, de Backstage: https://www.zoho.com/es-xl/backstage/
OBS Businnes School. (s.f.). Project Management. Recuperado el 10 de Mayo de 2020, de ¿Qué son las metodologías de desarrollo de software?: https://obsbusiness.school/es/blog-project-management/metodologia-agile/que-son-las-metodologias-de-desarrollo-de-software
Singh, V. (09 de Abril de 2020). hackr.io. Obtenido de What is Frameworks? [Definition] Types of Frameworks: https://hackr.io/blog/what-is-frameworks
voigtmann. (s.f.). voigtmann. Recuperado el 13 de Mayo de 2020, de Desarrollo de Software: https://www.voigtmann.de/es/desarrollo-de-software/
duoc. (s.f.). duoc. Recuperado el 6 de Mayo de 2020, de http://www.duoc.cl/biblioteca/crai/definicion-y-proposito-de-la-investigacion-aplicada
Mata Solis, L. D. (21 de Mayo de 2019). Investigalia. Obtenido de El enfoque cuantitativo de investigación: https://investigaliacr.com/investigacion/el-enfoque-cuantitativo-de-investigacion/
61
Abad Londoño, J. H. (2005, Abril 06). Ingeniería de Software. Obtenido de TIPOS
DE PRUEBAS DE SOFTWARE: http://ing-sw.blogspot.com/2005/04/tipos-
de-pruebas-de-software.html
Globe. (s.f.). Globe. Recuperado el Diciembre 18, 2020, de Pruebas de humo:
https://www.globetesting.com/glosario/pruebas-de-humo/
Open Source Iniciative. (s.f.). Open Source Iniciative. Recuperado el Febrero 22,
2021, de Common Development and Distribution License 1.0:
https://opensource.org/licenses/CDDL-1.0