ESCUELA MILITAR DE INGENIERÍA

Mcal. ANTONIO JOSÉ DE SUCRE

BOLIVIA

MARCO TEÓRICO DE TRABAJO DE GRADO

SISTEMA PWA DE CONTROL, REGISTRO Y MONITOREO

EMPLEANDO REALIDAD AUMENTADA EN LOS CENTROS
DE CÓMPUTO. CASO DE ESTUDIO: ESCUELA MILITAR DE
INGENIERIA U.A. COCHABAMBA

LOPEZ QUISPE BENJAMIN ALEJANDRO

COCHABAMBA, 2022
ESCUELA MILITAR DE INGENIERÍA
Mcal. ANTONIO JOSÉ DE SUCRE
BOLIVIA

MARCO TEÓRICO DE TRABAJO DE GRADO

SISTEMA PWA DE CONTROL, REGISTRO Y MONITOREO

EMPLEANDO REALIDAD AUMENTADA EN LOS CENTROS
DE CÓMPUTO. CASO DE ESTUDIO: ESCUELA MILITAR DE
INGENIERIA U.A. COCHABAMBA
LOPEZ QUISPE BENJAMIN ALEJANDRO

Modalidad: Proyecto de
grado presentado como
requisito para optar por el
título de Licenciatura en
Ingeniería de Sistemas

TUTOR: LIC. LENNY SANABRIA CASTELLON

COCHABAMBA, 2022
ÍNDICE DE CONTENIDO
 ÍNDICE DE CONTENIDO
CONTENIDO PÁGINAS
1 GENERALIDADES .............................................................................5
1.1 INTRODUCCIÓN. ........................................................................................6
1.2 ANTECEDENTES. .......................................................................................7
1.3 PLANTEAMIENTO DEL PROBLEMA. .......................................................10
1.3.1 Identificación del problema. 1........................................................................0
1.3.2 Análisis causa efecto. ................................................................................11
1.3.2.1 Causa. .....................................................................................................11
1.3.2.2 Efecto. .....................................................................................................11
1.3.3 Formulación del problema. .........................................................................11
1.4 OBJETIVOS. ..............................................................................................12
1.4.1 Objetivo general. ........................................................................................12
1.4.2 Objetivos específicos. ................................................................................12
1.4.2.1 Acciones del proyecto. .............................................................................12
1.5 JUSTIFICACIÓN. .......................................................................................14
1.5.1 Justificación operativa. ...............................................................................14
1.5.2 Justificación económica. ............................................................................15
1.5.3 Justificación técnica. ..................................................................................15
1.6 ALCANCE. ................................................................................................. 15
1.6.1 Alcance temático. .......................................................................................15
1.6.1.1 Área y líneas de investigación. .................................................................15
1.6.1.2 Tema específico. .......................................................................................16
1.6.2 Alcance temporal. ...................................................................................... 16
1.6.3 Alcance funcional. ......................................................................................16
1.6.4 Alcance institucional. ..................................................................................17
2 Marco teorico .......................................................................18
2.1 ESQUEMA DEL MARCO TEÓRICO ..........................................................19
2.2 CONTENIDO DEL MARCO TEÓRICO ......................................................20
2.3 DESARROLLO DEL MARCO TEORICO ...................................................23
2.3.1 Técnicas de recolección de información ....................................................23
2.3.1.1 Cuestionario .............................................................................................23
2.3.1.2 Entrevista ................................................................................................. 28
2.3.1.3 Observación .............................................................................................30
2.3.2 Ingeniería del software ...............................................................................31
2.3.2.1 Metodología de desarrollo de software ágil ..............................................31
2.3.2.2 UML 2 .....................................................................................................42
2.3.2.3 Pruebas de Software ................................................................................49
2.3.3 Realidad Aumentada. .................................................................................51
2.3.4 Gestión de base de datos ..........................................................................65
2.3.4.1 Base de datos relacionales .......................................................................66
2.3.4.2 Base de datos no relacionales ..................................................................68
2.3.5 Aplicaciones web progresivas. ...................................................................72
2.3.6 Sistemas operativos para servidores. ........................................................72
2.3.7 Redes computacionales. ............................................................................72

ANEXOS
ANEXO ‘A’: Entrevista 1
ANEXO ‘B’: Entrevista 2
ANEXO ‘C’: Entrevista 3
ANEXO ‘D’: Registro se solicitud se apertura del centro de cómputo laboratorio de
Redes
ANEXO ‘E’: Registro de solicitud de uso de equipo de cómputo laboratorio de
redes
ANEXO ‘F’: Horario de uso de centros de cómputo de los laboratorios Bolivar y
Sucre
ANEXO ‘G’: Registro de solicitud de apertura del centro de cómputo
ANEXO ‘H’: Centro de cómputo laboratorio de Redes
ANEXO ‘I’: Centro de cómputo laboratorio Bolivar
ANEXO ‘J’: Centro de cómputo laboratorio Sucre
ANEXO ‘K’: Centro de cómputo laboratorio Gral. Esteban Arce
ANEXO ‘L’: Centro de cómputo laboratorio Cnl. Jose Miguel Lanza
ANEXO ‘M’: Centro de cómputo laboratorio cnl. Julio Sanjines Goitia
 ÍNDICE DE TABLAS
CONTENIDO PÁGINAS
Tabla 1. Objetivos específicos y acciones. ...........................................................12
Tabla 2. Fundamentación Teórica ........................................................................20
 ÍNDICE DE TABLAS
CONTENIDO PÁGINAS
Figura 1. Esquema de marco teórico................................................................. 19
Figura 2. Guía para la elaboración de un cuestionario....................................... 28
Figura 3. Panel de Kanban .................................................................................34
Figura 4. Ciclo de scrum .................................................................................... 38
Figura 5. Diagrama de casos de uso.................................................................. 44
Figura 6. Tipos de relaciones de casos de uso ..................................................45
Figura 7. Diagrama de actividades .....................................................................47
Figura 8. Particiones y flujos de objetos .............................................................48
Figura 9. Diagrama de despliegue .....................................................................49
Figura 10. Realidad aumentada ...........................................................................52
Figura 11. Activadores de Realidad Aumentada ..................................................53
Figura 12. Proceso del funcionamiento de RA .....................................................54
Figura 13. Código UPC y código Q ......................................................................55
Figura 14. Marcador de ARToolkit .......................................................................55
Figura 15. Ipad2 por WIKITUDE en Flickr ............................................................56
Figura 16. Project Glass6 ©2012 Google .............................................................57
 CAPÍTULO 1:
1 GENERALIDADES
 CAPITULO 1

GENERALIDADES

1.1 INTRODUCCIÓN.

Con el paso del tiempo la necesidad de equipos computacionales para las

carreras profesionales de ingeniería se volvió de gran importancia al momento de
capacitar a los estudiantes. Las universidades con la misión de formar y
especializar profesionales en el área de ingeniería cuentan con laboratorios de
cómputo.

Estos laboratorios deberían contar con un registro de actividades tanto hardware

como software para salvaguardar la integridad física y lógica de todos los equipos
de computación con el propósito de mantener su vida útil intacta y no generar
pérdida de dinero en mantenimientos o cambio de dispositivos tales como mouse,
teclado, pantalla, etc.

Las tecnologías vanguardia de las universidades y empresas se pueden definir de

la siguiente manera:

Redes de cómputo, también llamada red de ordenadores o red informática, es un

conjunto de equipos conectados por medio de cables, señales, ondas o cualquier
otro método de transporte de datos, que comparten información y recursos.

La aplicación web progresiva (PWA) se definen comúnmente como las Apps que
reúnen lo mejor de las aplicaciones web y de las nativas, incluso llegando a ser
entendidas como un punto medio o una forma evolucionada. La base son páginas
webs, pero utilizan tecnologías que hacen que su estética y funcionamiento se
asemejen enormemente a una App nativa. Se accede a ellas a través de un
navegador, pero se puede anclar un acceso directo en nuestro dispositivo. No
dependen de sistemas operativos y van incorporando funcionalidades nativas del
dispositivo.

La Realidad Aumentada permite añadir capas de información visual sobre el

mundo real que rodea, utilizando la tecnología, dispositivos como pueden ser
nuestros propios teléfonos móviles. Esto ayuda a generar experiencias que
aportan un conocimiento relevante sobre nuestro entorno, y además se recibirá
esa información en tiempo real.

Se propone realizar una red de cómputo por laboratorio para conseguir la

información de cada equipo de cómputo, una aplicación web progresiva (PWA)
que contará con la gestión de usuarios y de equipos de cómputo con su debido
registro de actividades, con la adición de realidad aumentada para la visualización
de la información por equipo.

1.2 ANTECEDENTES.

El 26 de octubre de 1950 mediante un Decreto Supremo (D.S. 02226) se crea la

Escuela Militar de Ingeniería, elevado a rango de Ley el 10 de noviembre del
mismo año, con el nombre de Mcal. Antonio José de Sucre, con sede en la ciudad
de La Paz. A partir del 10 de noviembre de 1980 se acepta la inscripción de
estudiantes civiles. En 1985 el comité ejecutivo de las universidades bolivianas
reconoce a la EMI como una universidad del sistema y a partir del siguiente año
esta puede emitir títulos en Provisión Nacional.

A principios del Segundo Milenio, la Escuela Militar de Ingenieros tuvo la

posibilidad de expandir e inaugurar nuevas facilidades de estudio localizadas en
La Paz (Alto Irpavi y próximamente Irpavi), Santa Cruz, Cochabamba y Riberalta.

En la Escuela Militar de Ingeniería unidad Cochabamba al impartir una educación

de calidad cuenta con 6 centros de cómputo:
 Laboratorio de Redes. (Ver anexo H)
 Laboratorio Bolívar. (Ver anexo I)
 Laboratorio Sucre. (Ver anexo J)
 Laboratorio de Gral. Esteban Arce. (Ver anexo K)
 Laboratorio Cnl. Jose Miguel Lanza. (Ver anexo L)
 Laboratorio Cnl. Julio Sanjines Goitia. (Ver anexo M)

Estos ambientes prestan sus servicios de apoyo a la docencia, la investigación y

desarrollo de aplicaciones informáticas.

Las áreas de trabajo están perfectamente definidas y delimitadas, con una mesa
para dos computadoras, una mesa para el docente que imparte la clase.

Según entrevistas realizadas se pudo recabar la siguiente información (ver anexo

A, B y C):

Se realizan mantenimiento preventivos y correctivos según un cronograma para

los equipos de cómputo, el mantenimiento correctivo se realiza en fechas previas
al inicio de semestre y el mantenimiento preventivo se realiza únicamente a finales
de año, dichos mantenimientos son registrados en un software. En cuanto un
mantenimiento excepcional por alguna falla inesperada presente en algún equipo
de cómputo, se realiza una solicitud mantenimiento o reemplazo, posteriormente a
esto se analiza si el equipo presenta un defecto en software o hardware, en el
caso de ser problemas de hardware se realiza otro informe y solicitud para el
reemplazo del componente defectuoso.

Cada centro de cómputo tiene un sistema de cámaras de seguridad el cual guarda

video en un servidor local, dichos videos tienen un tiempo de vida de 20 días a 1
mes.

Actualmente se cuenta con procesos distintos entre las solicitudes de apertura y

uso del laboratorio de redes, los laboratorios Bolívar y Sucre y Laboratorios Cnl.
Julio Sanjines Goitia, Cnl. Jose Miguel Lanza y Gral. Esteban Arce.
El Laboratorio de Redes, requiere para la apertura y uso de los equipos de
cómputo en horario de clases, el docente debe presentar una solicitud de apertura
del mismo con 24 horas previas a su clase adjuntando el plan de trabajo que va a
seguir al encargado del laboratorio.

Para la apertura del laboratorio en horarios fuera de clase se procede al llenado de

un formulario, el cual registra fecha, nombre del solicitante, materia o curso, el
motivo, hora de inicio, hora de fin, observaciones si es necesario y la firma. (ver
anexo D)

En el caso de requerir el uso de algún equipo del laboratorio se procede al llenado

de un formulario extra con un registro similar al anterior con la adición del número
CI del solicitante, la asignatura, el semestre y los equipos que van a usar. (ver
anexo E)

Los Laboratorios Bolívar y Sucre, estos laboratorios cuentan con un horario

establecido a inicios de semestres de las materias que usarán los centros de
cómputo, los docentes que no requieran el uso continuo de los centros de
cómputo tendrán un resaltador de fondo de color amarillo y los mismos serán
registrados en el biométrico para que puedan ingresar a los ambientes en sus
horarios respectivos. (ver anexo F)

En este caso solo existe una única solicitud de apertura y uso de los centros de
cómputo fuera de los horarios de clases que debe ser presentada al jefe de la
UTIC.

Los Laboratorios Cnl. Julio Sanjines Goitia, Cnl. Jose Miguel Lanza y Gral.
Esteban Arce, cuentan con un horario establecido a inicios de semestres de las
materias que usarán los centros de cómputo, los docentes serán agregados al
biométrico para que los mismos puedan abrir los laboratorios dentro de sus
horarios de clases.
Para la apertura del laboratorio en horarios fuera de clase se procede al llenado de
un formulario, el cual registra fecha, horas de uso, nombre y código del solicitante,
carrera y curso, el motivo, observaciones si es necesario y la firma. (ver anexo G)

No obstante, los equipos de cómputo no son de uso obligatorio al momento de

inicio de clases, los estudiantes pueden llevar equipos de cómputo
propios(laptops) y con los mismo trabajar.

El proceso actual de distribución de equipo de cómputo por persona depende de la

persona que solicitó la apertura del centro de cómputo comúnmente este proceso
consta de que el estudiante busque un equipo optimo, esto ocurre en todos los
laboratorios anteriormente mencionados, de mismo modo la responsabilidad del
cuidado de todos los equipos de cómputo depende de la persona que realizo la
solicitud de apertura y uso del laboratorio.

1.3 PLANTEAMIENTO DEL PROBLEMA.

1.3.1 Identificación del problema.

Respecto al mantenimiento de los equipos se logró evidenciar que al no contar

con un registro detallado del uso de los equipos de cómputo provoca
mantenimientos que toman más tiempo del requerido dado que no se cuenta con
un registro actualizado de uso de cada equipo de cómputo.

Por otro lado, se tiene que las cámaras de seguridad guardan video de todas las
actividades de los laboratorios en servidores locales, estos videos tienen un
tiempo de guardado de aproximadamente un mes ya que tienen un tamaño
grande, de mismo modo dichas cámaras llegan a presentar puntos ciegos y al no
contar un registro exacto de todo el personal que ingresa a los centros de cómputo
esto provoca que no se ubique el conjunto total de equipos y por ende el usuario
manipulara de mala manera los equipos lo que genera riesgo de indebida
manipulación, perdida o daños a los equipos de cómputo.
Se pudo evidenciar que el proceso actual de solicitud de ingreso y uso de los
centros de cómputo son deficientes en vista que solo registra a una persona, el
cual puede llegar a ser el docente o estudiante que llene el formulario, dándole la
carga de responsabilidad del cuidado de todos los equipos de cómputo a una sola
persona, la Escuela Militar de Ingeniería al ser un ente de educación superior su
personal estudiantil incrementará con el paso del tiempo, haciendo que el trabajo
de que solo una persona, en el caso de que esta persona sea un docente, tendrá
que cuidar todos los equipos de cómputo lo que provocará dificultades al impartir
su clase y en el caso de que un estudiante sea el que solicite apertura a los centro
de cómputo tendrá la responsabilidad de cuidar ante cualquier situación todos los
equipos y esto da a lugar a que este pendiente de mantener en condiciones
normales el centro de cómputo para que no lo consideren culpable por algún error.

De manera paralela si un estudiante que ingresa al centro de cómputo cuenta con

un equipo propio(laptop) incide en la desconexión de cables de los equipos de
cómputo para usar su equipo propio sin hacer la debida reconexión al finalizar sus
actividades en el laboratorio, esto dificulta al siguiente personal que necesite el
uso de los equipos de cómputo.

1.3.2 Análisis causa efecto.

1.3.2.1 Causa.

• El proceso actual de solicitud para la apertura y uso de los centros de

cómputo.
• La información desactualizada de las actividades del equipo de cómputo.
• El actual sistema de monitoreo en base a una cámara de seguridad
1.3.2.2 Efecto.

• Registros incompletos respecto al personal que ingreso al centro de

cómputo.
• Mantenimientos que requieren mucho tiempo.
• Riesgos respectos a la integridad física y lógica de los equipos de
cómputo.
1.3.3 Formulación del problema.

El proceso actual y manual de control, registro y monitoreo de los centros de

cómputo es ineficiente lo que provoca información desactualizada y bajo nivel de
visualización, de manipulación de equipos por parte de los estudiantes poniendo
en riesgo la integridad de los equipos.

1.4 OBJETIVOS.

1.4.1 Objetivo general.

Desarrollar una aplicación web progresiva (PWA) de control, registro y monitoreo

empleando realidad aumentada para mejorar la organización y actualización de la
información y, el control y manipulación de los equipos de cómputo de los
laboratorios de informática de la EMI.

1.4.2 Objetivos específicos.

• Diseñar el proceso actual y alternativo de negocio.
• Desarrollar módulo de gestión de usuarios.
• Desarrollar módulo de gestión de equipos de cómputo
• Implementar realidad aumentada.
• Configurar e implementar el servidor de usuarios.
• Generar reportes de la asignación de computadoras de cada centro de
cómputo
• Realizar pruebas al sistema web
1.4.2.1 Acciones del proyecto.

Tabla 1. Objetivos específicos y acciones.

OBJETIVOS ACCIONES
ESPECIFICOS
 Recopilar información a través de entrevistas
sobre el proceso actual de negocio.
 Analizar la información del proceso actual de
Diseñar el proceso actual y negocio.
alternativo de negocio.  Elaborar el modelo de negocio actual.
 Identificar falencias en el proceso actual de
negocio.
 Modelar el proceso de negocio alternativo.
 Seleccionar la metodología a usar.
 Planificar actividades de desarrollo según la
metodología seleccionada.
 Seleccionar las herramientas para el desarrollo
del sistema web.
Desarrollar módulo de  Seleccionar el gestor de base de datos.
gestión de usuarios  Analizar los requerimientos para el módulo de
gestión de usuarios.
 Realizar el modelamiento del módulo aplicando
diagramas UML2.
 Codificar el módulo de gestión de usuarios.
 Realizar pruebas funcionales al módulo.
Desarrollar módulo de  Analizar los requerimientos para el módulo de
gestión de equipos de gestión de equipos de cómputo.
computo  Realizar el modelamiento del módulo aplicando
diagramas UML2.
 Diseñar e implementar la interfaz de asignación
de equipo de cómputo.
 OBJETIVOS ACCIONES
ESPECIFICOS
 Diseñar e implementar la interfaz de monitoreo
de los equipos de cómputo por laboratorio.
 Codificar el módulo de gestión de equipos de
cómputo.
 Diseñar la estructura de la base de datos.
 Realizar pruebas funcionales al módulo.
 Analizar los requerimientos para el módulo de
AR.
 Seleccionar objeto real a interpretar.
 Generar interpretador para el reconocimiento por
Implementar realidad equipo de cómputo.
aumentada.  Seleccionar objetos 3D a modelar.
 Modelar objetos 3D seleccionados.
 Implementar objetos 3D por equipo de cómputo.
 Realizar pruebas funcionales al módulo de
realidad aumentada web.
 Elegir sistema operativo a trabajar.
 Elegir herramientas para el registro de usuario y
Configurar e implementar el de acceso de los clientes al servidor.
servidor de usuarios.  Configurar los protocolos de conexión.
 Registrar usuarios en el servidor que permitan
reconocer su acceso en cada equipo.
 Obtener registro de uso de cada equipo.
 Definir la información necesaria de los centros de
Generar reportes de la
cómputo.
asignación y uso de las
 Obtener reportes correspondientes.
computadoras de cada
 Organizar y estructurar la solicitud del
centro de cómputo
administrador.
 OBJETIVOS ACCIONES
ESPECIFICOS
 Seleccionar tipos de pruebas a realizar
Realizar pruebas al sistema  Ejecutar pruebas del sistema web
web  Corregir o modificar los elementos observados.
 Documentar las pruebas realizadas.

Fuente: Elaboración propia, 2022

1.5 JUSTIFICACIÓN.

1.5.1 Justificación operativa.

El proyecto a través de las redes computacionales permitirá tener todos los datos
de los equipos de cómputo conectados al servidor, del mismo modo con su
funcionamiento web permitirá a los encargados acceder desde cualquier tipo de
dispositivo que cuenta con un navegador web, además permitirá tener un espacio
fijo y centralizado, escalable para futuras implementaciones gracias a las
aplicaciones web progresivas (PWA), y haciendo uso de la realidad aumentada
facilitará la visualización y comprensión de la información.

1.5.2 Justificación económica.

La implementación del sistema permitirá tener información actualizada de cada

equipo de cómputo lo cual ayudará al mantenimiento de los mismos, de este modo
el gasto será reducido.

1.5.3 Justificación técnica.

El uso de redes computaciones permitirá tener que todos los programas, datos y
equipo de cómputo estén disponibles para cualquiera de la red y del mismo modo
los mismos pueden ser controlados por el servidor ubicado en cada laboratorio, el
uso de las aplicaciones web progresivas permitirá acceder al sistema web de la
gestión de usuarios y equipos de cómputo desde cualquier dispositivo que cuente
con un navegador de por medio con la opción de instalar el sistema web en la
pantalla de inicio del encargado, se podrá trabajar con el mismo al momento de
perder conexión con la red, el uso de realidad aumentada permitirá la visualización
de los registros de uso por equipo de cómputo esto beneficiara en el
entendimiento y distribución de la información registrada.

1.6 ALCANCE.

1.6.1 Alcance temático.

1.6.1.1 Área y líneas de investigación.

El proyecto pertenece al área de investigación de gestión del conocimiento y

nuevas tecnologías. Y a la línea de investigación de gestión de sistemas de
información y comunicación

1.6.1.2 Tema específico.

El sistema propuesto se desarrollará haciendo uso de tecnologías web,

empleando tecnologías aplicación web progresiva (PWA) para aplicaciones web
progresivas y realidad aumentada web para realidad aumentada a través de
navegadores dentro de lo que es la ingeniería de software, aplicando análisis del
modelo de referencia, implementación, despliegue de los distintos componentes
de la arquitectura en los diferentes entornos, técnicas de recopilación de datos y
tecnologías de desarrollo.

1.6.2 Alcance temporal.

El desarrollo del Proyecto de Grado se rige de acuerdo al cronograma de

actividades en la segunda gestión del 2022 y la primera gestión del 2023
siguiendo el calendario académico de la Escuela Militar de Ingeniería.

1.6.3 Alcance funcional.

El sistema:
 Proporcionará información de las actividades de los equipos de cómputo.
 Permitirá a los encargados gestionar la información disponible.
 Permitir al visitante del sitio web, el diseño responsivo o adaptativo en
cualquier dispositivo.
 Permitirá generar reportes de acuerdo a la necesidad del usuario.
 Con la realidad aumentada se indicará las conexiones correspondientes
en la torre.
 Con la realidad aumentada se visualizará el registro de actividades por
equipo de cómputo.
 Monitorear cada equipo a través del servidor.
1.6.4 Alcance institucional.

El desarrollo del presente proyecto de grado tendrá un alcance institucional en el

centro de cómputo laboratorio de redes de la Escuela Militar de Ingeniería U.A
Cochabamba.
2 MARCO TEORICO

CAPÍTULO 2:
MARCO TEÓRICO
 CAPITULO 2

MARCO TEÓRICO
2.1 ESQUEMA DEL MARCO TEÓRICO
Figura 1. Esquema de marco teórico

Fuente: Elaboración propia, 2022

2.2 CONTENIDO DEL MARCO TEÓRICO

Tabla 2. Fundamentación Teórica

OBJETIVOS ACCIONES FUNDAMENTO
ESPECIFICOS TEORICO
 Recopilar información a  Técnicas de
través de entrevistas sobre recolección de
el proceso actual de información.
negocio.  Ingeniería del
 Analizar de la información software.
Diseñar el
del proceso actual de
proceso actual
negocio.
y alternativo de
 Elaborar el modelo de
negocio.
negocio actual.
 Identificar falencias en el
proceso actual de negocio.
 Modelar el proceso de
negocio alternativo.
 OBJETIVOS ACCIONES FUNDAMENTO
ESPECIFICOS TEORICO
 Seleccionar la metodología  Ingeniería de
a usar. software.
 Planificar actividades de  Gestión de base
desarrollo según la de datos.
metodología seleccionada.  Aplicaciones web
 Seleccionar las progresivas.
herramientas para el
desarrollo del sistema web.
Desarrollar  Seleccionar el gestor de
módulo de base de datos.
gestión de  Analizar los requerimientos
usuarios para el módulo de gestión
de usuarios.
 Realizar el modelamiento
del módulo aplicando
diagramas UML2.
 Codificar el módulo de
gestión de usuarios.
 Realizar pruebas
funcionales al módulo.
Desarrollar  Analizar los requerimientos  Ingeniería de
módulo de para el módulo de gestión software.
gestión de de equipos de cómputo.  Gestión de base
equipos de  Realizar el modelamiento de datos.
computo del módulo aplicando  Aplicaciones web
diagramas UML2. progresivas.
 Diseñar e implementar la
interfaz de asignación de
 OBJETIVOS ACCIONES FUNDAMENTO
ESPECIFICOS TEORICO
equipo de cómputo.
 Diseñar e implementar la
interfaz de monitoreo de los
equipos de cómputo por
laboratorio.
 Codificar el módulo de
gestión de equipos de
cómputo.
 Diseñar la estructura de la
base de datos.
 Realizar pruebas
funcionales al módulo.
 Analizar los requerimientos  Ingeniería de
para el módulo de AR. software.
 Seleccionar objeto real a  Gestión de base
interpretar. de datos
 Generar interpretador para  Realidad
el reconocimiento por Aumentada
equipo de cómputo.
Implementar
 Seleccionar objetos 3D a
realidad
modelar.
aumentada.
 Modelar objetos 3D
seleccionados.
 Implementar objetos 3D por
equipo de cómputo.
 Realizar pruebas
funcionales al módulo de
realidad aumentada web.
 OBJETIVOS ACCIONES FUNDAMENTO
ESPECIFICOS TEORICO
 Elegir sistema operativo a  Sistemas
trabajar. operativos para
 Elegir herramientas para el servidores.
registro de usuario y de  Redes
acceso de los clientes al computacionales.
Configurar e
servidor.
implementar el
 Configurar los protocolos de
servidor de
conexión.
usuarios.
 Registrar usuarios en el
servidor que permitan
reconocer su acceso en
cada equipo.
 Obtener registro de uso de
cada equipo.
Generar  Definir la información  Aplicaciones web
reportes de la necesaria de los centros de progresivas.
asignación y cómputo.  Ingeniería de
uso de las  Obtener reportes software
computadoras correspondientes.
de cada centro  Organizar y estructurar la
de cómputo solicitud del administrador.
Realizar  Seleccionar tipos de  Ingeniería de
pruebas al pruebas a realizar software
sistema web  Ejecutar pruebas del
sistema web
 Corregir o modificar los
elementos observados.
 Documentar las pruebas
 OBJETIVOS ACCIONES FUNDAMENTO
ESPECIFICOS TEORICO
realizadas.

Fuente: Elaboración propia, 2022

2.3 DESARROLLO DEL MARCO TEORICO

2.3.1 Técnicas de recolección de información

2.3.1.1 Cuestionario

El cuestionario es un conjunto de preguntas diseñadas para generar los datos

necesarios, con el propósito de alcanzar los objetivos del proyecto de
investigación. Se trata de un plan formal para recabar información de la unidad de
análisis objeto de estudio y centro del problema de investigación.

En general, un cuestionario consiste en un conjunto de preguntas respecto a una o

más variables que van a medirse. El cuestionario permite estandarizar y uniformar
el proceso de recopilación de datos. Un diseño inadecuado recoge información
incompleta, datos imprecisos y, por supuesto, genera información poco confiable.

Antes de iniciar la elaboración de un cuestionario, es necesario tener claros los

objetivos y las hipótesis o preguntas de investigación que impulsan a diseñar el
cuestionario. Además, es preciso tener cierta seguridad de que la información
podrá conseguirse usando los métodos de que se dispone y requiere el objeto de
estudio.

Cuando se prepara un instrumento para recabar datos, deben examinarse los

siguientes aspectos básicos:

 La naturaleza de la información que se busca.

 La naturaleza de la población o muestra de sujetos que aportarán la
información.
 El medio o los medios de aplicación del instrumento

Dada la importancia que tiene el cuestionario en un proceso de investigación

científica, pues es uno de los recursos más utilizados (a veces el único) para
obtener la información de la investigación, a continuación, se presenta una guía
general de los ocho aspectos que deben tenerse en cuenta en la elaboración de
un cuestionario. Estos aspectos son:

1. Tener claros el problema, los objetivos y la hipótesis o las preguntas de la

investigación que va a realizarse, ya que la información por obtener mediante el
cuestionario debe responder a tales aspectos, es decir, la razón de ser de la
investigación.

2. Conocer las características de la población objeto del estudio. El cuestionario

debe tener presentes las características socioculturales de las personas que se
van a encuestar.

3. Indagar sobre la existencia de cuestionarios o técnicas de recolección de

información sobre un mismo tema de la investigación que va a realizarse. Esto,
según Hernández, Fernández y Batista (1998) sirve para utilizar un cuestionario ya
existente una vez estandarizado o como orientación para preparar uno nuevo.

4. En caso de no existir un cuestionario previo que sirva como base para elaborar
el propio, es necesario comenzar por determinar el formato de preguntas y
respuestas que conformarán el cuestionario. Esta etapa consiste en determinar el
tipo de preguntas que van a emplearse en la encuesta. Básicamente, existen tres
tipos de preguntas: abiertas, cerradas y de respuesta a escala. Preguntas abiertas
Este tipo de preguntas le permiten al encuestado contestar en sus propias
palabras, es decir, el investigador no limita las opciones de respuesta. Las
preguntas abiertas ofrecen diversas ventajas para el investigador. Permiten que
las personas entrevistadas indiquen sus reacciones generales ante un
determinado aspecto o rasgo. Por ejemplo, ¿qué ventajas, si es que las hay,
ofrece el uso de Internet en el mundo actual? Además, propician la obtención de
información abundante o pueden sugerir posibilidades que no se incluyen en las
preguntas cerradas. Las preguntas abiertas también conllevan ciertas desventajas:
se dificulta el proceso de edición y codificación, así como la interpretación de los
patrones de datos y las frecuencias de las respuestas. El encuestador muchas
veces se ve en la necesidad de hacer interpretaciones de las respuestas para
ubicarlas en alguna categoría de clasificación, lo cual podría originar sesgos del
entrevistador, además de que no resultan muy adecuadas para los cuestionarios
de autoadministración. Preguntas cerradas Le solicitan a la persona encuestada
que elija la respuesta en una lista de opciones. La ventaja de este tipo de
preguntas es que se elimina el sesgo del entrevistador, que es muy común en las
preguntas abiertas; además, son fáciles de codificar y se obtienen respuestas muy
concretas.

Las preguntas cerradas se subdividen en dos clases: dicotómicas y de opción

múltiple.

 Dicotómicas: es el tipo más sencillo de preguntas cerradas. Por ejemplo: En

ocasiones se agrega una opción neutra o la opción “sin opinión/no sabe” a las
preguntas dicotómicas; en otras, los entrevistadores anotan NS por “no sabe” o
NR por “no responde”, cuando la opción neutra no se incluye en el
cuestionario. Para algunos investigadores, las preguntas dicotómicas incurren
en un error de medición considerable. Como las alternativas están polarizadas,
se omite la gran diversidad de posibilidades entre las opciones extremas.
 De opción múltiple: como todas las preguntas cerradas, las de opción múltiple
proporcionan información limitada, y se le pide al entrevistado que indique la
alternativa que exprese su opinión o, en algunos casos, es necesario indicar
varias opciones.

Preguntas de respuesta a escala. Son aquellas preguntas básicamente dirigidas a

medir la intensidad o el grado de sentimientos respecto a un rasgo o a una
variable por medir; usualmente se les conoce como escalas de medición de
actitudes, entre las cuales la más común es la escala de Likert.
5. Una vez que se ha decidido el tipo o los tipos específicos de preguntas y los
formatos de respuesta, la siguiente tarea consiste en redactar las preguntas. Al
respecto, deben considerarse los siguientes aspectos:

 Las preguntas deben ser claras y comprensibles para los encuestados. La falta
de claridad implica confusiones y ambigüedades; por ejemplo, ¿compra algún
producto en este almacén? Esta pregunta es confusa, pues no delimita la
frecuencia ni el tipo de productos.
 Se deben evitar las preguntas tendenciosas. Una pregunta resulta tendenciosa
cuando le presenta al entrevistado una clave para orientar su respuesta; por
ejemplo, ¿considera usted que el gobierno debe estimular el consumo de
bienes nacionales, aunque éstos sean de menor calidad que los importados
con el propósito de evitar el desempleo?
 Es necesario elaborar preguntas específicas para cada una de las variables
que van a medirse, con la finalidad de evitar confusiones; por ejemplo, ¿qué
opinión tiene del precio y de la calidad de los productos de la marca JP? En
este caso, es importante redactar una pregunta para conocer la actitud
respecto al precio y otra para la calidad; pero no una sola pregunta para ambas
variables, ya que el encuestado podría responder a una variable y no a las dos.
Además, estas preguntas generan inconformidad en el encuestado porque
podría opinar sobre cada variable por separado y no disponer del espacio
suficiente.

Según Malhotra (1997):

 Las preguntas no deben redactarse de manera que la respuesta sea

dependiente de suposiciones implícitas acerca de lo que sucederá como
consecuencia del contenido de la pregunta; por ejemplo, ¿está a favor de un
presupuesto equilibrado, si genera un incremento en el impuesto sobre el
ingreso personal?
 Elaborar preguntas adaptando el lenguaje a las características de los
entrevistados.
 Evaluar la pertinencia de la pregunta. ¿Realmente es necesaria la pregunta?
Esto se logra contrastando la pregunta con los objetivos de la investigación.
 Evaluar si el encuestado puede y quiere aportar la información que se le
solicita (p. 237).

6. Establecer el flujo y la estructura del cuestionario. Una vez redactadas las

preguntas, es importante darles orden. El cuestionario tiene que iniciar con
información referente a las características sociodemográficas y económicas que
permitirán clasificar a los entrevistados. En relación con el flujo de ítems o
preguntas, se recomienda:

 Iniciar con preguntas sencillas e interesantes.

 Formular primero las preguntas de tipo general.
 Incluir las preguntas que se consideren más difíciles en la parte intermedia del
cuestionario.
 Clasificar las preguntas por temas afines o subtemas, de manera que el
encuestado se concentre en un solo tema o aspecto cada vez que se desplace
por el cuestionario.

7. Efectuar una evaluación previa del cuestionario. El objetivo primario de la

prueba anterior es corroborar que el cuestionario posea los criterios de
confiabilidad y de validez. Esto se logra si se somete el cuestionario al juicio de
expertos en la elaboración de instrumentos de medición y recolección de datos,
así como de especialistas en el tema objeto de estudio, y la realización de una
prueba piloto, aplicando el instrumento a una pequeña muestra de la población
objeto de la investigación. 8. Elaborar el cuestionario definitivo, teniendo en cuenta
las observaciones del jurado y la experiencia de la prueba piloto.

8. Elaborar el cuestionario definitivo, teniendo en cuenta las observaciones del

jurado y la experiencia de la prueba piloto.
 Figura 2. Guía para la elaboración de un cuestionario

2.3.1.2 Entrevista

Como se mencionó en el capítulo anterior, retomando a Buendía, Colás y

Hernández (2001) la entrevista es una técnica que consiste en recoger
información mediante un proceso directo de comunicación entre entrevistador(es)
y entrevistado(s), en el cual el entrevistado responde a cuestiones, previamente
diseñadas en función de las dimensiones que se pretenden estudiar, planteadas
por el entrevistador.

En investigación hay diferentes tipos de entrevista; sin embargo, es usual clasificar

las entrevistas en: estructurada, semiestructurada y no estructurada.

Entrevista estructurada Cerda (1998) señala que a esta entrevista también se le

denomina entrevista directiva; se realiza a partir de un esquema o formato de
cuestiones previamente elaborado, el cual se plantea en el mismo orden y en los
mismos términos a todas las personas entrevistadas.
Para Buendía et al. (2001), las entrevistas requieren entrevistadores muy
entrenados y que, a la vez, conozcan ampliamente el tema objeto de estudio.

Entrevista semiestructurada Es una entrevista con relativo grado de flexibilidad

tanto en el formato como en el orden y los términos de realización de la misma
para las diferentes personas a quienes está dirigida.

Entrevista no estructurada Este tipo de entrevistas se caracterizan por su

flexibilidad, ya que en ella sólo se determinan previamente los temas que se van a
tratar con el entrevistado. Durante la entrevista, el entrevistador puede definir la
profundidad del contenido, la cantidad y el orden de las preguntas o cuestiones
por tratar con las personas que van a entrevistarse

Aunque no hay un modelo único para realizar una entrevista, a continuación, se

presenta una guía general de cómo hacer una entrevista en investigación
científica. Las fases en esta guía son los siguientes:

Fase 1. Preparación de la entrevista En esta etapa, se parte del problema de

investigación, los objetivos y la hipótesis (si la hay), luego se prepara un guion de
entrevista, teniendo en cuenta el tema que se va a tratar, el tipo de entrevista que
va a realizarse y las personas que se van a entrevistar. El guion inicial se valida
con una prueba piloto o mediante el juicio de expertos, se entra en contacto previo
con las personas que se van a entrevistar y se concreta la entrevista. Cuando la
entrevista requiere varios entrevistadores, hay que capacitarlos previamente.

Fase 2. Realización de la entrevista Con el guion de entrevista definido, y

habiendo entrado en contacto con las personas que se van a entrevistar, se
procede a la fase de realización de la entrevista, una vez preparado el material y
las condiciones requeridas para tal efecto. Se comienza por presentarle al
entrevistado el objetivo de la entrevista, la forma como se registrará la información
(escrita, grabada, filmada, etcétera) y después se procede a desarrollar el guion
de la entrevista, según el tipo de entrevista seleccionado.
Fase 3. Finalización de la entrevista o de las conclusiones En esta fase se
agradece su participación al entrevistado y se organiza la información para ser
procesada posteriormente para su respectivo análisis.

2.3.1.3 Observación

La observación, como técnica de investigación científica, es un proceso riguroso

que permite conocer, de forma directa, el objeto de estudio para luego describir y
analizar situaciones sobre la realidad estudiada.

De acuerdo con Cerda (1998), los elementos que conforman un proceso de

observación y necesitan ser claramente definidos por el observador, en todo
proceso de investigación fundamentado en la observación, son los siguientes: • El
sujeto que investiga.

 El objeto de estudio.
 Los medios en los que se da la observación.
 Los instrumentos que se van a utilizar.
 El marco teórico del estudio.

Para el mencionado autor, según los niveles de relación que se den entre el sujeto
y el objeto, así como entre éstos con los medios y los instrumentos, se dan
diferentes tipos de observación entre los cuales cabe señalar los siguientes:

Observación natural Es aquella en la que el observador es un mero espectador de

la situación observada; por tanto, no hay intervención alguna de éste en el curso
de los acontecimientos observados.

Observación estructurada Es la observación en la que el observador tiene un

amplio control sobre la situación objeto de estudio; por tanto, el investigador puede
preparar los aspectos principales de la situación de tal forma que reduzca las
interferencias ocasionadas por factores externos al estudio y que se logren los
fines de la investigación.

Observación participante En este tipo de observación, el observador es parte de la

situación que observa. Según Cerda (1998), una de las premisas del investigador
que opta por tal técnica de obtención de información es que debe estar el mayor
tiempo en la situación que se observa, con el propósito de conocer de forma
directa todo aquello que a su juicio puede constituirse en información para el
estudio.

2.3.2 Ingeniería del software

2.3.2.1 Metodología de desarrollo de software ágil

un método es ágil sí permite construir un producto de forma incremental, es decir,

crear algo muy sencillo inicialmente y que vaya siendo enriquecido y completado
de forma progresiva. No se construirán trozos de producto por separado que luego
se tendrá que hacer encajar al final como un rompecabezas, sino que se
construye contemplando la totalidad desde el principio.
Las metodologías Ágiles tienen un conjunto de doce principios comunes que se
enuncian a continuación:

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y

continua de software con valor.

2. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo.

Los procesos ágiles se doblegan al cambio como ventaja competitiva para el
cliente.

3. Entregar con frecuencia software que funcione, en periodos de un par de

semanas hasta un par de meses, con preferencia en los periodos breves.

4. Las personas del negocio y los desarrolladores deben trabajar juntos de forma

cotidiana a través del proyecto.

5. Construcción de proyectos en torno a individuos motivados, dándoles la
oportunidad y el respaldo que necesitan y procurándoles confianza para que
realicen la tarea.

6. La forma más eficiente y efectiva de comunicar información de ida y vuelta

dentro de un equipo de desarrollo es mediante la conversación cara a cara.

7. El software que funciona es la principal medida del progreso.

8. Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores,

desarrolladores y usuarios deben mantener un ritmo constante de forma

indefinida.

9. La atención continua a la excelencia técnica enaltece la agilidad.

10. La simplicidad como arte de maximizar la cantidad de trabajo que no se hace,

es esencial.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos que se

autoorganizan.

12. En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo
y ajusta su conducta en consecuencia.

Existen métodos ágiles de proceso o gestión como son Scrum o Kanban. En el

caso de que el proyecto sea un desarrollo de software, una buena gestión no es
suficiente y se necesita también seguir unas buenas prácticas de programación.
Eso permitirá una gestión optimizada, a la vez que se crea un software de calidad.
Es aquí donde entran en juego los métodos ágiles de programación, como, por
ejemplo, la Programación eXtrema (XP). En definitiva, para crear un buen
producto software, se necesita una combinación de mejores prácticas de gestión
con mejores prácticas de programación, ambas compartiendo los valores y
principios ágiles.
A continuación, se describen brevemente algunos de los métodos ágiles más
extendidos.

2.3.2.1.1 Kanban
Kanban es un método útil para gestionar los productos cuyos requisitos cambian
constantemente, bien porque aparezcan nuevas necesidades o bien porque su
prioridad varíe. Este método también es útil en los casos en los que sea muy
complicado planificar el trabajo, así como cuando no se pueda comprometer un
equipo a trabajar con iteraciones de duración fija y predeterminada por el motivo
que sea (interrupciones, cambios, dependencias, etc.). Se usa mucho para la
resolución de incidencias y actividades de mantenimiento: es decir, cuando no se
puede prever de antemano la cantidad de trabajo ni su naturaleza. De forma
simplificada, los pasos que debe seguir para trabajar con Kanban son los
siguientes:

 Visualizar el flujo de todo el trabajo: En un panel organizado en columnas debe

estar representado todo el flujo del trabajo que hay que realizar en el proyecto,
desde el principio hasta el último momento. Cada actividad se representa por
una tarjeta (de ahí el nombre de Kanban). Este panel debe estar accesible y
bien visible para todos los miembros del equipo.
 Para que el panel sea útil tiene que representar en qué estado del flujo está
cada ítem en cada momento. La primera columna representa el Backlog del
producto, es decir, la lista priorizada de las necesidades o actividades
pendientes. Se puede usar tantas columnas como estados sean necesarios
para que todo el flujo de trabajo esté contemplado.
 Divida el trabajo en ítems pequeños y escriba cada uno en una tarjeta.
Priorícelos y colóquelos ordenados en la primera columna del tablero. Una
buena práctica es tratar de dividir los ítems de forma que la carga de trabajo
sea similar de unos con otros. Esto proporciona una gran ventaja, ya que
permite estimar visualmente el trabajo asociado a cada estado.
 Limite el trabajo en curso: Esta es una de las claves para que trabajar con
Kanban funcione. Es imprescindible poner un límite al número de ítems
permitidos en cada columna y de esta forma evitar colapsos, cuellos de botella
y eliminar cuanto antes los impedimentos que surjan y que impidan trabajar
con un ritmo sostenible. Este número que indica el límite permitido en cada
columna debe estar visible en la parte superior de la misma.
 Mida el tiempo empleado en completar un ciclo completo: Calcule el tiempo
que se emplea desde que se empieza a trabajar con un ítem o tarea hasta que
se da por cerrado o terminado y trate de buscar la manera de disminuir este
tiempo. Esta práctica ayuda también a ser predecible y poder hacer una
estimación previa de cuánto tiempo empleará en completar cada ítem.

Figura 3. Panel de Kanban

Fuente: Sanchez,2020
2.3.2.1.2 Scrum
Scrum propone un marco de trabajo que puede dar soporte a la innovación,
basándose en equipos autogestionados. Con Scrum se pueden obtener resultados
con calidad, en iteraciones cortas (entre una y cuatro semanas) llamadas Sprints.
Scrum es el método ágil más aplicado y con más elementos aplicables.

Scrum se basa en los siguientes principios:

 Inspección y adaptación: En Scrum se trabaja en iteraciones llamadas Sprints,

que tienen una duración de entre 1 y 4 semanas. Cada iteración termina con
un producto entregable (por ejemplo, software ejecutable o los planos de un
edificio). Al finalizar cada iteración, este producto se muestra al cliente para
 que opine sobre él. A continuación, el equipo se reúne para analizar la manera
en que está trabajando. Uniendo los dos puntos de vista, “el qué” se ha hecho
y “el cómo” se está construyendo, se aprenderá con la experiencia y se podrá
mejorar iteración tras iteración.
 Auto-organización y colaboración: El equipo se gestiona y organiza a sí mismo.
Este nivel de libertad implica asumir una responsabilidad y un gran nivel de
compromiso por parte de todos. Esta auto-organización funcionará siempre
que exista una alta colaboración y espíritu de equipo. Los líderes y clientes
colaborarán igualmente con el equipo de desarrollo en todo momento,
facilitando su trabajo, resolviendo dudas y eliminando posibles impedimentos.
 Priorización: Como en el resto de los métodos ágiles, es crucial no perder
tiempo y dinero en algo que no interesa inmediatamente para el producto. Para
ello, es necesario tener unos requisitos perfectamente priorizados reflejando el
valor del negocio.
 Mantener un latido: Es tremendamente valioso mantener un ritmo que dirija el
desarrollo. Este latido marcará la pauta del trabajo y ayudará a los equipos a
optimizar su trabajo. El tener un ritmo fijo de trabajo, tanto en el día a día como
en las iteraciones o Sprints, permite que el equipo sea predecible, ya que este
aprenderá a estimar la cantidad de trabajo a la que puede comprometerse. El
mantener un latido ayuda a todos a centrarse en crear el producto y, para ello,
es básico tener fechas clave de una iteración muy estables.

Una de las principales características de Scrum es que, en cada iteración, todas

las etapas de la creación de un producto se solapan, es decir, en cada Sprint se
realiza la planificación, análisis, creación y comprobación de lo que se va a
entregar al final del mismo. El marco de trabajo general de Scrum está compuesto
por una serie de roles, reuniones y de paneles de información o artefactos que se
indican a continuación:

 Los roles en el equipo Scrum:

• El Product Owner o dueño del producto. Es el responsable desde el punto de
vista del negocio.
• El Scrum Master es el responsable de que el equipo sea productivo,
ayudándole en todo momento a conseguir el objetivo acordado y de asegurar
que los principios de Scrum se están respetando.
• El equipo. Es el responsable de la construcción del producto.
 Los artefactos de Scrum: Los Backlog o repositorios son los artefactos en los
que el Product Owner, equipo y Scrum Master escriben los requisitos y tareas.
• El Product Backlog es el lugar que contiene los requisitos del cliente
priorizados y estimados. Es propiedad del Product Owner, aunque todos los
afectados deben asesorar durante su creación y en el mantenimiento del
mismo para que esté permanentemente actualizado. El Product Backlog está
escrito en lenguaje de negocio y debe revisarse la priorización, al menos, antes
del inicio de cada Sprint.
• El Sprint Backlog es la selección de requisitos del Product Backlog negociados
para el Sprint y que se ha descompuesto en tareas por el equipo para expresar
los requisitos del cliente en un lenguaje técnico. El Sprint Backlog es propiedad
del equipo.
• El Burndown Chart es una gráfica en la que se representa el trabajo pendiente
del equipo. Existen dos tipos de gráficas principales: la relacionada con el
Sprint y la relacionada con la totalidad del proyecto.

De forma muy simplificada se podría resumir el flujo del trabajo con Scrum de la
siguiente manera:

1. El Product Owner escribe en el Product Backlog todas las funcionalidades y

requisitos que quiera que su producto contemple. Eso sí, debe priorizarla
indicando el orden en que quiere que se vaya construyendo su producto. Los
ítems más prioritarios deben estar más detallados que los que no son tan
urgentes.
2. El equipo estimará cada uno de estos requisitos en función de su complejidad.
Teniendo en cuenta la prioridad marcada por el Product Owner y la estimación
realizada por el equipo, se acordará la cantidad de trabajo que se vaya a abordar
en el siguiente Sprint. Ojo, los requisitos seleccionados no podrán cambiarse
durante el Sprint.

 Jhhhnhn
• Hjhjhjh
 Jjhjhjhhjhj


3. Empieza el Sprint y el equipo se sincronizará diariamente con la Daily Meeting.

4. Al finalizar el Sprint, el equipo muestra al Product Owner el trabajo realizado

que debe ser un producto potencialmente entregable. Con la opinión y
sugerencias del Product Owner y la información obtenida en la retrospectiva
posterior que realizará el equipo, se preparará la siguiente iteración.

Este flujo de trabajo se repetirá tantas veces como sea necesario hasta que se
complete el Product Backlog, o bien se acabe el presupuesto o se llegue a una
determinada fecha.
 Figura 4. Ciclo de scrum

2.3.2.1.3 Programación eXtrema XP

Tal y como lo define Kent Beck eXtreme Programming (XP) es un método ágil
para el desarrollo de software muy útil a la hora abordar proyectos con requisitos
vagos o cambiantes. XP es especialmente útil si se aplica a equipos de desarrollo
pequeños o medianos. Es un método adaptativo, es decir, se ajusta muy bien a los
cambios. Propone desarrollar el código de forma que su diseño, arquitectura y
codificación permitan incorporar modificaciones y añadir una funcionalidad nueva
sin demasiado impacto en la calidad del mismo. Por otro lado, XP es un método
muy orientado hacia las personas, tanto a las que están creando el producto como
a los clientes y usuarios finales. Desarrollando como propone XP, se obtienen
rápidamente resultados. Al trabajar con pequeñas iteraciones, se puede obtener
con frecuencia comentarios del cliente, lo que tiene como resultado que el
producto final cubra ampliamente sus expectativas y necesidades. Para XP las
pruebas son la base de la construcción y propone que sean los desarrolladores los
que escriban las pruebas a medida que van construyendo el código y se realice
una integración continua, de forma que el software creado tenga una gran
estabilidad. Las pruebas automáticas se realizan de forma constante para poder
detectar los fallos rápidamente. Cuanto antes se detecte un problema, antes podrá
resolverse sin que las consecuencias y el impacto sean mayores.

A continuación, se detalla algo más sobre cómo llevar a cabo cada una de estas
etapas de planificación, análisis, arquitectura, diseño, codificación y pruebas
aplicando XP:

 Planificación: En cualquier equipo que vaya a desarrollar un proyecto, debe

haber personas responsables de tomar las decisiones de negocio y que tengan
clara cuál es la visión del producto, el plan de entregas, establezcan las
necesidades que debe cubrir el sistema y gestionen los riesgos. El resto del
equipo hará sugerencias y estimaciones para matizar este plan inicial de entregas.
Las historias de usuario deberán estar priorizadas para reflejar el orden en que se
debe construir el producto, desde el punto de vista de negocio y contemplando
también la secuencia lógica desde un punto de vista más técnico. Naturalmente,
en las etapas iniciales del proyecto, es necesario dedicar un mayor esfuerzo a la
planificación. Sin embargo, esto no significa que no se vuelva a planificar a lo largo
del desarrollo. En función de las nuevas necesidades que vayan surgiendo, los
clientes deben revisar y mejorar el plan de entregas. También será necesario
adaptar el plan inicial en el caso de que surjan imprevistos o dependencias
externas que dificulten mantener dicho plan. Las historias más prioritarias serán
las que se implementen en primer lugar. A su vez, el equipo, al comienzo de cada
semana, planificará de forma detallada la manera de abordar la siguiente iteración.
Además, cada día el equipo organizará el trabajo para esa jornada. En definitiva,
se planifica al inicio del proyecto, al inicio de cada iteración y, aún más en detalle,
todos los días.
 Análisis: Para que el análisis se mantenga actualizado durante todo el
proyecto, los clientes deben estar en comunicación constante y cercana con las
personas que están construyendo el producto. Cuando un desarrollador tenga
dudas sobre cómo implementar un requisito, debe poder preguntar al cliente. De
igual manera, se debe trabajar en estrecha colaboración con los responsables
tanto de pruebas como de diseño gráfico, de manera que no quepa ambigüedad
en la definición de los requisitos.
 Diseño y codificación: XP propone trabajar de manera que tanto el diseño
como la arquitectura se creen de forma incremental. De este modo, se mejora el
diseño y la arquitectura poco a poco y de forma constante.
 Pruebas: Uno de los pilares sobre los que se fundamenta XP son las
pruebas. Las pruebas deben realizarse a todos los niveles y todos los implicados
en un proyecto contribuyen a su realización. Los desarrolladores construyen el
código a la vez que lo prueban, ya que utilizando TDD se están realizando
pruebas completas del código. Por otro lado, los usuarios realizan pruebas de
aceptación. En ocasiones, una parte del equipo está dedicado a realizar pruebas
más amplias y completas, pero, si no fuera así, el mismo equipo de desarrollo
ejecutaría dichas pruebas
 Despliegue: La forma de construir el producto con XP hace posible que, al
finalizar cada semana, el software obtenido pueda ser puesto en producción, ya
que la funcionalidad comprometida está asegurada. Esto no significa que se
realicen entregas al cliente final con esta frecuencia. Las entregas se realizarán
siguiendo el plan de entregas establecido previamente con el cliente.
Los 5 valores que guían el desarrollo en XP son la comunicación, simplicidad,
feedback, valentía y el respeto, pero, obviamente, estos no son los únicos valores
que deben aplicarse. En cada empresa y situación personal habrá que decidir qué
otros valores adicionales incorporar, como, por ejemplo, asegurar la calidad de
vida o el ser predecibles.
Comunicación: La base del éxito del trabajo de un equipo de desarrollo es la
comunicación, sin lugar a dudas. La comunicación entre los desarrolladores y, a
su vez, con el cliente es la mejor forma de evitar la mayoría de los problemas y
errores. Si se comentan los problemas o impedimentos de forma constante entre
los miembros del equipo, se podrá contar con el conocimiento de alguien que tal
vez haya lidiado con un problema similar en otras ocasiones o, entre todos, pensar
una solución y no hacerlo de forma individual. Hay muchas formas de
comunicarse, además de hablar. Por ejemplo, un código simple y bien escrito es
una forma eficaz de comunicación entre los desarrolladores, ya que cualquiera de
ellos podrá entender el código desarrollado por otro miembro de su equipo.
Simplicidad: Las cosas deben hacerse de la forma más simple posible. Cuidado,
es importante no confundir simple con simplista y para esto hace falta experiencia.
No es fácil construir un sistema sencillo y que cumpla exactamente los requisitos
establecidos. La forma de simplificar un sistema muchas veces se consigue con
un método de trabajo de ensayo-error. Construir de forma simple disminuye la
cantidad de código que hay que escribir y aumenta la calidad. Se debe simplificar
el diseño, documentar el código de forma muy simple pero que aporte valor y
utilidad y refactorizar el código, eliminando redundancias y las partes inservibles
para mantener la sencillez del mismo.
Feedback: El feedback debe entenderse como una combinación de comentarios,
reacciones, sugerencias, opiniones, etc. Es necesario poder conocer siempre
cómo de cerca está el producto que se está construyendo de lo que realmente se
necesita. Una de las herramientas fundamentales para obtener comentarios y
sugerencias del cliente es la estrecha comunicación con él. De esta forma se
favorece que el equipo conozca con mucha frecuencia su opinión sobre el trabajo
que se está realizando. Asimismo, se evita tener que realizar costosas
modificaciones y ayuda los desarrolladores a centrarse en lo que realmente el
cliente necesita. Teniendo esta comunicación, se eliminan malentendidos que
pueden generar que en ocasiones haya que tirar una gran cantidad de trabajo que
en realidad no era necesario realizar. La otra gran herramienta para obtener
información sobre el sistema son los test automáticos que se crean a la vez que el
producto, ya que ayudan a revisar el estado del código y facilitan detectar, de
forma casi inmediata, posibles fallos producidos por cambios. El feedback está
muy relacionado con la comunicación y la simplicidad. Sin comunicación, es
imposible obtenerlo y, por otro lado, cuanto más simple se construya un sistema
más fácil será opinar sobre él.
Coraje: Hasta ahora, no se ha dicho nada que no sea de sentido común y es
necesario ser valientes para aplicar estos valores a nuestro trabajo. Se necesita
valentía para comunicarnos clara y eficazmente con el cliente y con nuestros
compañeros y afrontar sin miedo los cambios en el producto. Se Necesita ser
valiente para construir de forma simple solo y exactamente lo que se necesita en
este momento y tener valor para saber parar sin caer en la tentación de crear algo
decidido por nuestra cuenta y de manera individual. Se necesita esa valentía para
recibir y dar feedback de forma productiva y, por supuesto, es necesario ser
valiente para aplicar algunas de las prácticas que XP propone, ya que, en
ocasiones por desconocimiento, puede haber quien dude de su utilidad.
• Respeto: Los cuatro valores anteriores llevan implícito el respeto. Ningún método
puede funcionar si no se trabaja con respeto mutuo, valorando el trabajo de los
demás y sus aportaciones. Es necesario tener siempre muy presente cómo puede
afectar nuestro trabajo a las personas que trabajan con nosotros y a su
organización. De igual manera, hay que tener en cuenta a todas las personas que
puedan interactuar con el producto que se está generando.

2.3.2.2 UML 2

El Lenguaje Unificado de Modelado (UML) es un lenguaje de modelado visual de

propósito general que se utiliza para especificar, visualizar, construir y documentar
los artefactos de un sistema software. Captura decisiones y conocimiento sobre
sistemas que deben ser construidos. Se usa para comprender, diseñar, ojear,
configurar, mantener y controlar la información sobre tales sistemas. Está pensado
pasa ser utilizado con todos los métodos de desarrollo, etapas del ciclo de vida,
dominios de aplicación y medios. El lenguaje de modelado pretende unificar la
experiencia pasada sobre las técnicas de modelado e incorporar las mejores
prácticas de software actuales en una aproximación estándar. UML incluye
conceptos semánticos, notación y principios generales. Tiene partes estáticas,
dinámicas, de entorno y organizativas. Está pensado para ser apoyado por
herramientas de modelado visuales e interactivas que dispongan de generadores,
tanto de código, como de informes. La especificación de UML no define un
proceso estándar, pero está pensado para ser útil en un proceso de desarrollo
iterativo. Pretende dar apoyo a la mayoría de los procesos de desarrollo
orientados a objetos existentes.
UML capta la información sobre la estructura estática y el comportamiento
dinámico del sistema. Un sistema es modelado como una colección de objetos
discretos que interactúan para realizar un trabajo que en última instancia beneficia
a un usuario externo. La estructura estática define tipos de objetos importantes
para un sistema y para su implementación, así como las relaciones entre los
objetos. El comportamiento dinámico define la historia de los objetos a lo largo del
tiempo y la comunicación entre objetos para cumplir los objetivos. El modelado de
un sistema desde varios puntos de vista separados pero relacionados, permite
entenderlo para diferentes propósitos.

UML2 es en lo fundamental lo mismo que UML1, en especial, en lo que se refiere

a las características principales utilizadas habitualmente. Algunas áreas
problemáticas han sido modificadas, se han añadido algunas mejoras importantes
y se han solucionado muchos pequeños fallos.

Algunos de los cambios más importantes visibles para los usuarios son:

 La construcción y notación de los diagramas de secuencia se basa en gran

parte en el estándar ITU Message Sequence Chart, adaptándolo para hacerlo más
orientado a objetos.
 Se elimina la relación existente entre los conceptos del modelado de
actividad y las máquinas de estados y del uso de notación popular en la
comunidad de modelado de negocio.
 Se unifica el modelado de actividad con el modelado de acción añadido en
la versión 1.5 de UML, para proporcionar un modelo procedimental más completo.
 Construcciones del modelado contextual para la composición interna de
clases y colaboraciones. Estas construcciones permiten, tanto la encapsulación
libre, como la encapsulación estricta, y el enlace de estructuras internas a partir de
partes más pequeñas.
 El reposicionamiento de componentes como construcciones de diseño y
artefactos como entidades físicas que son desplegadas.
2.3.2.2.1 Diagrama de caso de uso
La vista de casos de uso captura el comportamiento de un sistema, subsistema,
clase o componente tal y como se muestra a un usuario externo. Divide la
funcionalidad del sistema en transacciones que tienen significado para los actores
—usuarios ideales de un sistema. Las piezas de funcionalidad interactiva se
denominan casos de uso.

Un actor es una idealización de un rol desempeñado por una persona externa, un

proceso o cosa que interactúe con el sistema, subsistema o clase. Un actor
caracteriza la interacción que una clase de usuarios externos puede tener con el
sistema.

Figura 5. Diagrama de casos de uso

Cada actor participa en uno o más casos de uso. Interactúa con el caso de uso (y,
por tanto, con el sistema o clase que posee el caso de uso) mediante el
intercambio de mensajes. La implementación interna de un actor no es relevante
en el caso de uso; un actor puede estar suficientemente caracterizado por un
conjunto de atributos que definen su estado.

Un caso de uso es una unidad coherente de funcionalidad externamente visible

proporcionada por un clasificador (denominado sistema) y expresada mediante
secuencias de mensajes intercambiados por el sistema y uno o más actores de la
unidad del sistema. El propósito de un caso de uso es definir una pieza de
comportamiento coherente sin revelar la estructura interna del sistema.

Un caso de uso es una unidad coherente de funcionalidad externamente visible

proporcionada por un clasificador (denominado sistema) y expresada mediante
secuencias de mensajes intercambiados por el sistema y uno o más actores de la
unidad del sistema. El propósito de un caso de uso es definir una pieza de
comportamiento coherente sin revelar la estructura interna del sistema.

Un caso de uso puede participar en varias relaciones, además de en la asociación

con los actores

Figura 6. Tipos de relaciones de casos de uso

Las relaciones de inclusión y extensión se dibujan como flechas de línea

discontinua con la palabra clave «include» o «extend». La relación de inclusión
apunta al caso de uso a ser incluido; la relación de extensión apunta el caso de
uso que se extenderá.

2.3.2.2.2 Diagrama de actividades

Una actividad es un grafo de nodos y flujos que muestra el flujo de control (y
opcionalmente datos) a través de los pasos de la computación. Los pasos de
ejecución pueden ser, tanto concurrentes, como secuenciales. Una actividad
involucra constructores de sincronización y de bifurcación, de forma similar, pero
más potente, a los tradicionales diagramas de flujo, que sólo soportaban
constructores secuenciales y de bifurcación.

Los nodos de actividad se pueden anidar. Un diagrama de actividad puede

contener bifurcaciones, así como divisiones del control en hilos concurrentes, Los
hilos concurrentes representan actividades que se pueden realizar
concurrentemente por diferentes objetos o personas en una organización.

Un nodo de actividad se muestra como una caja con las esquinas redondeadas
que contiene una descripción de la actividad. Un flujo de control se muestra como
una flecha. Las bifurcaciones se muestran como condiciones de guarda sobre los
flujos de control o como rombos con múltiples flechas de salida etiquetadas. Una
división o unión del control se muestra mediante múltiples flechas saliendo o
entrando en una barra gruesa de sincronización
 Figura 7. Diagrama de actividades

Para aquellas situaciones en las que se deben incluir eventos externos, la

recepción de un evento se puede mostrar como una acción que indica la espera
de una señal. Una notación similar indica el envío de una señal.

Particiones. A menudo es útil organizar las actividades de un modelo de acuerdo

con su responsabilidad
 Figura 8. Particiones y flujos de objetos

Flujos de objetos. Un diagrama de actividad puede mostrar el flujo de valores de

objetos, además del flujo de control. Un flujo de objeto representa un objeto que es
la entrada o salida de una actividad. Para un valor de salida, se dibuja una flecha
de línea continua desde la actividad al flujo de objeto.

2.3.2.2.3 Diagrama de despliegue

La vista de despliegue muestra la disposición física de los nodos. Un nodo es un
recurso computacional de ejecución, como computadoras u otros dispositivos.
Durante la ejecución, los nodos pueden contener artefactos, entidades físicas
como los archivos. La relación de manifestación muestra la relación entre un
elemento de diseño, como un componente, y los artefactos que los plasman en el
sistema software.
Un nodo modela un recurso computacional de tiempo de ejecución, que
generalmente tiene menos memoria y a menudo también capacidad de
procesamiento. Los nodos pueden tener estereotipos para distinguir los diferentes
tipos de recursos, como UCP, dispositivos y memorias. Los nodos pueden
albergar artefactos.

Un artefacto modela una entidad física como un archivo. Un artefacto se muestra

mediante un rectángulo con la palabra clave «artifact». La presencia de un
artefacto en un nodo se representa anidando físicamente el símbolo del artefacto
dentro del símbolo del nodo.

Se pueden marcar con estereotipos distintos tipos de artefactos, como las bases
de datos, las páginas Web, los ejecutables o los guiones.

Figura 9. Diagrama de despliegue

2.3.2.3 Pruebas de Software

Las pruebas son parte fundamental de cualquier proyecto, ya que ayudarán a

tener mejores resultados, ofrecer una calidad mayor de nuestro producto y en
consecuencia los clientes estarán más satisfechos.
El proceso de prueba de software tiene tres procesos principales: el desarrollo de
los casos de prueba, la ejecución de estos casos de prueba y el análisis de los
resultados de la ejecución.

La definición de prueba que aporta Myers es: “La prueba es el proceso de

ejecución de un programa con la intención de encontrar errores”.

2.3.2.3.1 Prueba funcional

Este tipo de pruebas se basa en las funcionalidades de un sistema que se
describen en la especificación de requisitos, es decir, lo que hace el sistema.
También pueden no estar documentadas, pero se requiere un nivel de experiencia
elevado para interpretar estas pruebas.

La funcionalidad a su vez, la dividen en las siguientes características:

 Completitud funcional: el grado en el que las funcionalidades cubren todas

las tareas y objetivos del usuario especificados.
 Corrección funcional: capacidad del producto o sistema para proveer
resultados correctos con el nivel de precisión requerido.
 Pertenencia funcional: capacidad del producto de software para
proporcionar un conjunto apropiado de funciones para tareas y objetivos de
usuario especificados.

2.3.2.3.2 Prueba no funcional

Este tipo de pruebas tienen en cuenta el comportamiento externo del software, es
decir cómo funciona el sistema, y se suelen utilizar técnicas dediseño de caja
negra.

Se han de tener en cuenta las siguientes características no funcionales en las

pruebas:

 Pruebas de carga: consisten en la medición del comportamiento del sistema

para aumentar la carga del mismo, ya sea mediante el número de peticiones que
se realizan a una WEB al mismo tiempo, el número de usuarios que trabajan
simultáneamente, etc.
 Pruebas de rendimiento: en estas pruebas se medirán la velocidad de
procesamiento y el tiempo de respuesta del sistema.
 Pruebas de volumen: se mide la capacidad del sistema para procesar gran
cantidad de datos, como procesar archivos con tamaños muy grandes.
 Pruebas de esfuerzo: se realizan pruebas donde se sobrecarga el sistema y
se analiza la capacidad de recuperación.
 Pruebas de seguridad: se realizan diferentes pruebas de accesos no
autorizados, ataque de denegación de servicio, etc.
 Pruebas de estabilidad, eficiencia, robustez: se realiza una medición de la
respuesta del sistema a los errores de funcionamiento.
 Pruebas de compatibilidad: son pruebas del funcionamiento del sistema con
los diferentes sistemas operativos, plataformas de hardware, etc., con los que
puede interactuar el programa.
 Pruebas de usabilidad: se mide la facilidad de uso, efectividad y
satisfacción, siempre dentro de un grupo específico de usuarios.

2.3.3 Realidad Aumentada.

La Realidad Aumentada, a partir de ahora RA, es una tecnología que superpone a
una imagen real obtenida a través de una pantalla imágenes, modelos 3D u otro
tipo de informaciones generados por ordenador.

La realidad virtual es una experiencia completamente digital e inmersiva que

reemplaza el mundo real por uno simulado; según Pérez (2011, p. 4), la realidad
virtual es “la percepción en 3D de entornos simulados que permiten trasladar al
usuario a mundos de ensueño y le posibilitan viajar a través del tiempo al pasado y
al futuro”. Mientras esto sucede, el usuario está inmerso en un ambiente artificial y
no puede ver a su alrededor.

En contraste, la RA se entiende como “la generación de imágenes nuevas a partir

de la combinación de información digital en tiempo real y el campo de visión de
una persona” (Johnson et al. 2013, p. 12). La RA se puede considerar como una
mezcla entre lo completamente artificial y lo completamente real.

Figura 10. Realidad aumentada

Fuente: Elaboración propia, 2022

Otros autores ofrecen elaboraciones del concepto más complejas que contienen
más elementos de discernimiento. Así por ejemplo De Pedro (2011) explica la RA
como «aquella tecnología capaz de complementar la percepción e interacción con
el mundo real, brindando al usuario un escenario real aumentado con información
adicional generada por ordenador. De este modo, la realidad física se combina
con elementos virtuales disponiéndose de una realidad mixta en tiempo real» (p.
301).

A partir de la definición básica y la descripción de las capacidades de la RA se

enumeran tres características necesarias para contar con verdadera RA; según
Kipper y Rampolla (2012):
 Debe combinar información real y virtual.
 Requiere ser interactiva en tiempo real.
 Debe operar y ser usada en un ambiente en tercera dimensión.
Existen conceptos y elementos básicos para entender cómo funciona la RA en la
actualidad, los cuales delinean los componentes necesarios en distintas
plataformas. Respecto al hardware se requiere una computadora o un dispositivo
móvil, una pantalla, una cámara y un marcador (geolocalización, reconocimiento
de imágenes).
En el caso del software es preciso contar con una aplicación informática o
programa para RA, y un servidor de contenidos. La RA se puede presentar de dos
formas: reconociendo un marcador(interpretador) o mediante un punto de
localización geográfica, por eso al señalar que se requiere un marcador se brindan
las dos opciones.

Figura 11. Activadores de Realidad Aumentada

Cuando se utiliza un marcador básicamente se asocia un modelo virtual en tercera

dimensión a un objeto físico; cuando se usa la localización, en lugar de reconocer
un marcador, se asigna información digital a un grupo de coordenadas
geográficas.
La Realidad Aumentada no es una tecnología que necesite de muchos
requerimientos técnicos actualmente para ponerla en práctica. Se puede
experimentar Realidad Aumentada empleando un dispositivo que esté dotado de
los siguientes elementos:
 Una cámara o webcam que capte la imagen del entorno.
 Software de Realidad Aumentada que permita superponer contenido digital
sobre la escena real.
 Microprocesador con capacidad de procesamiento para modificar la señal
de vídeo que se entrega a la pantalla.
 Un monitor o pantalla donde visualiza la imagen real tomada por la cámara
combinada en tiempo real con el contenido digital.
El proceso de RA por medio de un marcador o a partir de una imagen comienza
por una cámara que muestra una señal de video en tiempo real, la señal es
digitalizada e interpretada por el programa que, a su vez, identifica el marcador y
lo asocia con el contenido digital asignado a él y, finalmente, el contenido digital es
reproducido dentro del marco de la señal de video a través de la pantalla del
dispositivo o el monitor de la computadora.

Figura 12. Proceso del funcionamiento de RA

Fuente: Elaborado a partir de Kipper y Rampolla (2012)

2.3.3.1.1 Niveles de la realidad aumentada

Nivel 0. Hiperenlazando el mundo físico. Basado en códigos de barra (enlaces 1D,
Universal Product Code), códigos 2D (por ejemplo los códigos QR) o
reconocimiento de imágenes aleatorias. Lo característico de este nivel 0 es que
los códigos son hiperenlaces a otros contenidos, no existe registro en 3D ni
seguimiento de los marcadores (básicamente funcionan como un hiperenlace html
pero sin necesidad de teclear)

Figura 13. Código UPC y código Q

Para leer un código QR se deebe instalar en el smartphone un lector adecuado al

sistema operativo del dispositivo que se van a emplear. Los códigos QR no son
como los marcadores de Realidad Aumentada. Estos únicamente pueden ser
identificados por la aplicación para la que han sido creados. La información que se
muestra en un marcador de Realidad Aumentada viene determinada por la
aplicación a la que está asociado. Sin embargo, en un código QR, al estar la
información codificada en el propio símbolo, puede ser leída por cualquier lector
de códigos QR.

Nivel 1. AR basado en marcadores (marker based AR). Normalmente es

reconocimiento de patrones 2D, el reconocimiento 3D de objetos sería la forma
más avanzada de nivel 1 de AR. Según Estebanell et al. (2012): «los marcadores
son unas imágenes en blanco y negro, generalmente cuadradas, con dibujos
sencillos y asimétricos» (p.282).
 Figura 14. Marcador de ARToolkit

Los marcadores están formados generalmente por un cuadrado de color negro

con un diseño determinado en su interior que permite que se diferencien unos de
otros.

Para experimentar este tipo de Realidad Aumentada el procedimiento general

suele ser el siguiente:

 Imprimir el marcador.
 Iniciar la aplicación.
 Situar el marcador delante de la cámara.
 El software reconoce el marcador y superpone generalmente un modelo 3D.

Nivel 2. RA sin marcadores (markerless AR). Mediante el uso del GPS y la brújula
de los dispositivos electrónicos se consigue localizar la situación y la orientación y
superponer puntos de interés en las imágenes del mundo real. LensFitzgerald
(2009) lo define como AR basada en GPS-brújula. También puede incluir el uso de
acelerómetros para calcular la inclinación.
 Figura 15. Ipad2 por WIKITUDE en Flickr

Nivel 3. Visión aumentada, citando a Rice (2009):«Debemos despegarnos del

monitor o el display para pasar a ligeros, transparentes displays para llevar encima
(de una escala como las gafas). Una vez la RA se convierte en VA (visión
aumentada), es inmersiva. La experiencia global inmediatamente se convierte en
algo más relevante, contextual y personal. Esto es radical y cambia todo» (párr.6).

Figura 16. Project Glass6 ©2012 Google

2.3.3.1.2 Captación de la escena
Una de las tareas más importantes en cualquier sistema de realidad aumentada es
la de identificar el escenario que se desea aumentar. En el caso de los sistemas
que utilicen reconocimiento visual, es indispensable contar con algún mecanismo
que permita recoger la escena para que pueda ser posteriormente procesada. En
esta sección se analizan los diferentes tipos de dispositivos físicos que permiten
captar dicho escenario. A grandes rasgos, estos dispositivos se pueden agrupar,
principalmente, en dos conjuntos:

 Dispositivos video-through: dentro de este grupo se encuentran aquellos

dispositivos que realizan la captura de imágenes o video y que están aislados de
los dispositivos de visualización. En este conjunto se encontrarían las cámaras de
video o los terminales móviles (siempre y cuando tengan una cámara).
 Dispositivos see-through: son los dispositivos que realizan tanto la tarea de
capturar la escena real como de mostrarla con información aumentada al usuario.
Estos dispositivos acostumbran a trabajar en tiempo real. Dentro de este grupo se
encontrarían aquellos dispositivos conocidos como headmounted.

El proceso de identificación de escenas consiste en averiguar qué escenario físico

real es el que el usuario quiere que se aumente con información digital. Este
proceso puede llevarse a cabo, básicamente, de dos maneras: utilizando
marcadores o sin utilizarlos

 Reconocimiento por marcadores: En los sistemas de realidad aumentada,

un marcador es un objeto cuya imagen es conocida por el sistema. Las maneras
en que el sistema conoce el marcador se pueden agrupar en tres conjuntos,
mediante su geometría, su color o mediante ambas características, dichos
mecanismos, suelen implicar una gran capacidad de cálculo y, por tanto, afecta al
rendimiento del sistema.
 Reconocimiento sin marcadores: Es posible identificar la escena mediante
reconocimiento de imágenes o mediante la estimación de la posición. También es
posible encontrar sistemas que realicen una combinación de ambas en función de
la situación. A este tipo de identificación se le denominará híbrida. Dentro de cada
uno de estos dos conjuntos de técnicas se pueden encontrar diversas variaciones
que dependerán en gran medida de las prestaciones que deba ofrecer el sistema,
así como de sus posibilidades técnicas.

2.3.3.1.3 Métodos de seguimiento

El seguimiento (tracking) es como se conoce al proceso de localización espacial
del usuario en un entorno. Es uno de los aspectos clave en el desarrollo de
aplicaciones de realidad aumentada ya que cuanto mejor sea la estimación de la
posición y orientación del dispositivo, mejores y más acertados serán los
resultados y la inmersión por parte del usuario.

Los algoritmos de tracking se encargan de calcular la posición del dispositivo en

relación a los objetos de la escena física. Existen multitud de tecnologías y
métodos en los que se apoyan para llevarlos a cabo, siendo los más comunes:
sensores mecánicos, magnéticos, sónicos, dinámicos y basados en visión. Hoy en
día estos últimos son los más extendidos, ya que la mayoría de los dispositivos
desde los que se despliegan las aplicaciones de realidad aumentada, como
móviles o tabletas, disponen de una o varias cámaras.

En este tipo de posicionamiento es necesario disponer de un conjunto de

marcadores o referencias tridimensionales para situar la cámara con respecto a
ellas. Aunque recientemente se ha tendido a utilizar en menor medida los
marcadores físicos para dar una experiencia más rápida y cómoda al usuario, han
sido una herramienta imprescindible en los primeros pasos de la realidad
aumentada para la obtención de la localización relativa de la cámara. Según David
Marimón, fundador y director general de Catchoom, se pueden distinguir dos
aproximaciones distintas a la hora del tracking: los métodos Bottom-Up y los Top-
Down.
 Bottom-Up pretenden obtener la posición del dispositivo basándose en la
información que recibe a través de la cámara. Para este método de tracking la
posición y orientación se calculan en base a la obtención de características
geométricas de objetos y sus relaciones. Dependiendo de los datos procesados, el
seguimiento puede ser con marcas o sin ellas.
 top-down intentan estimar desde la posición actual del dispositivo si se está
percibiendo lo que se esperaba. Es decir, primero se estima la posición y después
se confirma esa estimación con los datos del medio. En este caso, se emplean
modelos de movimiento para hacer una predicción de la localización del
dispositivo. Partiendo de esta estimación, se busca mediante la cámara una serie
de referencias parciales que corrijan la predicción y mejoren el posicionamiento
del observador. Por ello, todos los modelos top-down se ven obligados a trabajar
con filtros y modelos de asociación de datos.

2.3.3.1.4 Herramientas de desarrollo RA

2.3.3.1.4.1Lenguaje de programación

C#: Lenguaje de programación orientado a objetos, desarrollado y estandarizado

por Microsoft como parte de su plataforma.NET.

 Diseñado para la infraestructura de lenguaje común (estándar que

implementa un entorno virtual para la ejecución de aplicaciones, escritas en
diferentes lenguajes de alto nivel, para que puedan ejecutarse en múltiples
plataformas de Microsoft).
 Aunque forma parte de la plataforma .NET, ésta es una API, mientras que
C# es un lenguaje de programación independiente diseñado para generar
programas sobre dicha plataforma.
 Existencia de compiladores en los marcos de proyecto Mono-DotGNU, para
el desarrollo de programas en diferentes plataformas, como Windows, Unix,
Android, iOS, Windows Phone, Mac OS y GNU/Linux.
 Su sintaxis básica deriva de C/C++ y utiliza el modelo de objetos de la
plataforma .NET, similar al de Java, aunque incluye mejoras derivadas de otros
lenguajes.
Javascript: Lenguaje de programación interpretado, y se define como orientado a
objetos, basado en prototipos, imperativo, débilmente tipado y dinámico.
 Se utiliza en su forma del lado del cliente (client-side), implementado como
parte de un navegador web, permitiendo mejoras en la interfaz de usuario y
páginas web dinámicas, aunque existe una forma de JavaScript del lado del
servidor (Server-side JavaScript o SSJS).
 JavaScript se diseñó con una sintaxis similar al C, aunque adopta nombres
y convenciones del lenguaje de programación Java. Sin embargo Java y
JavaScript no están relacionados y tienen semánticas y propósitos diferentes.
 Todos los navegadores modernos interpretan el código JavaScript integrado
en las páginas web. Para interaccionar con una página web se provee al lenguaje
JavaScript de una implementación del Document Object Model (DOM).

Boo: Lenguaje de programación orientado a objetos, de tipos estáticos para la

Common Language Infrastructure, con una sintaxis inspirada en Python y un
énfasis en la extensibilidad del lenguaje y su compilador.

 Inferencia de tipos, generadores, multimétodos, duck typing opcional (estilo

de tipificación dinámica de datos), macros, clausuras, currificación (transformación
de una función con varios argumentos en una función con un solo argumento) y
funciones de primera clase.
 Es software de código abierto, con licencia tipo MIT/BSD.
 Boo se integra sin fisuras con Microsoft.NET y Mono.

2.3.3.1.4.2Framework

Wikitude sdk: Es un Kit de Desarrollo de Software Wikitude SDK es una librería de

software y un framework que Soporta cualquier tipo de casos de uso basados en
localización, provee de un conjunto de herramientas para el desarrollo de
aplicaciones con Realidad Aumentada personalizadas (Butchart, 2011). Está
disponible gratis cuando se utiliza en proyectos no comerciales, pero también
requiere del registro y permiso de su uso. Además, la gestión de los datos para
mostrar en la realidad aumentada depende de Wikitude (y sus servidores) o de
servidores que trabajan con esta plataforma, permitiendo a los Desarrolladores
aprovechar las tecnologías web estándar, como HTML5, CSS y JavaScript para
crear mundos de realidad aumentada. De este modo, no hay necesidad de que los
Desarrolladores aprendan otros idiomas de programación, lo que les permite
obtener creaciones AR de la tierra y en funcionamiento en un tiempo mínimo.

Las principales funcionalidades son:

 Geo AR (Puntos de anclaje vía GPS)

 Reconocimiento de imágenes 2D (marcadores)
 Reconocimiento de objetos 3D

ARKit: ARKit se define como un tipo de tecnología enfocada en la realidad

aumentada, que funciona como una librería para esta y que fue lanzada por los
sistemas de Apple en el año de 2017.

Asimismo, es importante destacar que esta tecnología fue diseñada por Apple
para los equipos y dispositivos de Apple y que contribuye a que los
desarrolladores tengan la opción de producir aplicaciones que permitan la
interacción con el entorno, a través del uso de las cámaras y sensores presentes
en los móviles y dispositivos.

Como característica del sistema de ARKit se encuentra que, al igual que las
demás experiencias de realidad aumentada, tiene la capacidad de desarrollar y
mantener una coherencia o correspondencia visual entre el mundo real percibido
por el usuario y el mundo virtual donde se observa el contenido gráfico.

Funcionalidades:
 Reconocimiento de imágenes 2D (marcadores)
 Reconocimiento de objetos 3D
 Reconocimiento de rostro (hasta 3 simultáneamente)
 Oclusión
 SLAM
 Estimación de luces
 Puntos de anclaje en la nube

ARCore: Google define ARCore como una plataforma para crear experiencias de
realidad aumentada. La definición es algo críptica, pero viene a ser algo así como
un sistema que tienen los móviles Android para analizar el entorno y poder hacer
los cálculos para ubicar objetos virtuales en el mundo real.

Funcionalidades:

 Reconocimiento de imágenes 2D (marcadores)

 Reconocimiento de objetos 3D
 Reconocimiento de rostro
 SLAM
 Mapeado de áreas grandes
 Estimación de luces
 Puntos de anclaje en la nube

Vuforia: Vuforia Unity es un kit de desarrollo de software (SDK) para dispositivos

móviles que permite la creación de aplicaciones de realidad aumentada (AR). Se
trata de un sistema para el desarrollo de aplicaciones de realidad aumentada que
cualquier persona que se quiera especializar en AR, reconoce y rastrea imágenes
planas y objetos 3D en tiempo real mediante el uso de una tecnología concreta de
visión artificial.

Funcionalidades:

 Reconocimiento de imágenes 2D (marcadores)

 Reconocimiento de objetos 3D
 Escáner de objetos 3D

Kudan: Es una herramienta SLAM de creadores chinos, que es similar en muchas

características a Vuforia, siendo su competidor directo. Por otro lado, solo admite
dos plataformas principales: iOS y Android. Esto puede limitar las capacidades del
desarrollador hasta cierto punto. Usando la tecnología SLAM, Kudan permite
reconocer imágenes simples y objetos 3D, proporcionando una generación de
base de datos simple en el editor de Unity.

Funcionalidades:

 Reconocimiento de imágenes 2D (marcadores)

 SLAM

MaxST: MAXST ofrece todas las funciones necesarias para ayudarlo a crear un
mundo de realidad aumentada. Proporciona un SDK de AR con las herramientas
necesarias para el desarrollo de aplicaciones de AR. Uno de esos módulos es el
Instant Tracker que puede comprender el área apuntada por la cámara, lo que le
permite colocar cualquier objeto. Otro componente es Visual SLAM que reúne
puntos característicos del espacio 3D a través de la lente de la cámara de su
dispositivo y crea un mapa virtual, que luego se almacena como un archivo.

Funcionalidades:

 Reconocimiento de imágenes 2D (marcadores)

 Reconocimiento de objetos 3D
 Reconocimiento de códigos de barras y QR

8th Wall: 8th wall tiene una buena propuesta para los desarrolladores porque tiene
una tecnología híbrida que permite trasladarse fácilmente entre web y app. Es
decir, se puede generar un proyecto enteramente para navegadores y también
fácilmente se puede migrar a un proyecto para android o iphone. Además, tiene
una buena calidad y estabilidad.
Funcionalidades:

 Reconocimiento de imágenes 2D (marcadores)

 6 grados de libertad
 SLAM
 Estimación de la luz

Easy AR: EasyAR es una plataforma especializada en la creación de realidad

aumentada proveniente de China, la cual cuenta con las siguientes
funcionalidades.

 Reconocimiento de imágenes 2D (marcadores)

 Reconocimiento de objetos 3D
 SLAM
 Grabación de pantalla

ARFoundation: Este no trata exactamente de una librería, sino de un marco de

trabajo creado especialmente para el desarrollo en realidad aumentada. Que
integra una API de alto nivel que permite tener el mismo código funcional para
ARCore y ARKit, según si se compila el proyecto para Android o para iOS.

Soporta las mismas funcionalidades que ARCore y ARKit:

 Reconocimiento de imágenes 2D (marcadores)

 Reconocimiento de objetos 3D
 Reconocimiento de rostro
 Oclusión (iOS con ARKit)
 SLAM
 Mapeado de áreas grandes (ARCore)
 Estimación de luces
 Puntos de anclaje en la nube
2.3.4 Gestión de base de datos
Una base de datos es una colección compartida de datos relacionados que se
utilizan para respaldar las actividades de una organización en particular.

Una base de datos tiene las siguientes propiedades:

 Es una representación de algún aspecto del mundo real o una colección de

elementos de datos (hechos) que representan información del mundo real.
 Una base de datos es lógica, coherente e internamente consistente.
 Una base de datos está diseñada, construida y poblada con datos para un
propósito específico.
 Cada elemento de datos se almacena en un campo.
 Una combinación de campos forma una tabla. Por ejemplo, cada campo en
una tabla de empleados contiene datos sobre un empleado individual.

2.3.4.1 Base de datos relacionales

El lenguaje estructurado de consultas (SQL, Structured Query Language) apoya la

creación y mantenimiento de la base de datos relacional y la gestión de los datos
dentro de la base de datos.

Las bases de datos relacionales han sido durante décadas el modelo de

persistencia más utilizado en la mayoría de las aplicaciones software. En este
sentido se van a revisar las ventajas y desventajas que presentan. Desde el punto
de vista de los beneficios que aportan las bases de datos relacionales, se puede
destacar:

 Persistencia de datos. Una de las misiones más importantes de las bases

de datos es mantener cantidades enormes de datos persistentes. En la mayoría
de las aplicaciones es necesario disponer de un almacén de datos que actúe de
backup. Estos almacenes se pueden estructurar de muchas formas, como, por
ejemplo, un archivo del sistema de archivos del sistema operativo. Sin embargo, la
forma preferida es una base de datos, pues ofrece más flexibilidad que el sistema
de archivos cuando almacena grandes cantidades de datos a la hora de permitir
obtener conjuntos de información de una forma rápida y fácil.
 Concurrencia. En general, en las aplicaciones normales suele haber
muchas personas que están trabajando sobre los mismos dados, y puede que
estén modificando los mismos datos. Esta situación obliga a coordinar las
diferentes interacciones sobre los mismos datos para evitar inconsistencias en
estos. La gestión directa de la concurrencia es complicada y existen muchas
posibilidades de cometer errores. Las bases de datos ayudan a controlar todos los
accesos a los datos usando transacciones. Aunque no es un sistema que no
pueda dar lugar a errores (pueden ocurrir errores en las transacciones y entonces
hay que retroceder la transacción), sin embargo, sí permite gestionar la
complejidad que supone la concurrencia.
 Integración. Con frecuencia, las aplicaciones requieren interaccionar con
otras aplicaciones de forma que compartan los mismos datos, y unas y otras
utilizan los datos que han sido modificados por el resto de las aplicaciones. Una
forma de implementar esta interacción consiste en usar una integración basada en
compartir una base de datos, es decir, las diferentes aplicaciones que
interaccionan almacenan sus datos en una única base de datos. Usar una única
base de datos permite que todas las aplicaciones usen los datos de las restantes
de una forma fácil. Además, el sistema de control de la concurrencia de las bases
de datos permite que existan múltiples aplicaciones usando la misma base de
datos.
 Modelo estándar. Las bases de datos relacionales han tenido éxito debido a
que proporcionan los beneficios clave de constituir un sistema estándar. Una
persona puede aprender unos conocimientos generales sobre el modelo relacional
que son comunes a las diferentes bases de datos relacionales y podrá aplicarlos
en cualquier caso particular. Es decir, los mecanismos nucleares son los mismos y
las diferencias serán, por ejemplo, la existencia de dialectos de SQL o pequeñas
diferencias de funcionamiento de las transacciones, pero esencialmente el
funcionamiento es el mismo.
Sin embargo, las bases de datos relacionales no son perfectas. Uno de los
principales problemas hace referencia a la diferencia entre el modelo relacional y
las estructuras de datos en memoria que algunos autores denominan
«impedancia». En el modelo relacional, una tupla es un conjunto de pares nombre-
valor y una relación es un conjunto de tuplas. Todas las operaciones en SQL
consumen y retornan relaciones de acuerdo con el algebra relacional. Este uso de
las relaciones proporciona cierta elegancia y simplicidad, pero introduce un
conjunto de limitaciones. En particular, los valores en una tupla relacional tienen
que ser simples (no pueden tener estructura tal como un registro anidado o una
lista). Esta limitación no se da en las estructuras de datos en memoria, donde
existe un conjunto de tipos de estructuras mucho más ricas que las relaciones.
Como consecuencia, si se quiere usar una estructura de datos más compleja que
la relación, hay que traducirla a una representación relacional para poderla
almacenar en disco. Este problema llevó a pensar que las bases de datos
relacionales serían sustituidas por bases de datos que replicaran las estructuras
de datos en memoria.

2.3.4.2 Base de datos no relacionales

Debido a las limitaciones mencionadas en base de datos relacionales algunas

empresas decidieron usar alternativas a las bases de datos relacionales. Este fue
el caso de Google y Amazon, que desarrollaron sistemas de almacenamiento
basado en el uso de clústeres: las Big Tables de Google y Dynamo de Amazon.
Estos sistemas permitían gestionar grandes cantidades de datos en ambientes
distribuidos y llevar a cabo su procesamiento, por lo que se consideran el origen
de las denominadas «bases de datos NoSQL». Aunque muchas empresas no
gestionaban las escalas de datos de las empresas antes mencionadas, sin
embargo, muchas de ellas empezaron a diseñar sus aplicaciones para ejecutarse
en estos ambientes distribuidos y usar este tipo de bases de datos al descubrir las
ventajas que ofrecían:
 Productividad del desarrollo de aplicaciones. En los desarrollos de muchas
aplicaciones se invierte un gran esfuerzo en realizar mapeos entre las estructuras
de datos que se usan en memoria y el modelo relacional. Las bases de datos
NoSQL proporcionan un modelo de datos que encaja mejor con las necesidades
de las aplicaciones simplificando así la interacción, lo que resulta en tener que
codificar, depurar y evolucionar menos las aplicaciones.
 Datos a gran escala. Las organizaciones han encontrado muy valiosa la
posibilidad de tener muchos datos y procesarlos rápidamente. En general, es caro
(en el caso de ser posible) hacerlo con una base de datos relacional. La primera
razón es que las bases de datos relacionales están diseñadas para ejecutarse en
una única máquina, y por otro lado es mucho más barato ejecutar muchos datos y
procesarlos si se encuentran cargados sobre clústeres de muchas maquinas, pero
más pequeñas y baratas. La mayoría de las bases de datos NoSQL están
diseñadas para ejecutarse sobre clústeres, por lo que encajan mejor para estas
situaciones.
Algunas de las características compartidas por las bases de datos NoSQL son:
 No usan SQL como lenguaje de consultas, sin embargo, algunas de ellas
utilizan lenguajes de consultas similares a SQL, tales como CQL en Cassandra.
 En general se trata de proyectos de código abierto.
 Muchas de las bases de datos NoSQL nacieron por la necesidad de
ejecutarse sobre clúster, lo que ha influido sobre su modelo de datos como su
aproximación acerca de la consistencia. Las bases de datos relacionales usan
transacciones ACID para manejar la consistencia de la base de datos, sin
embargo, esto choca con un entorno de clúster, de manera que ofrecen diversas
opciones para implementar la consistencia y la distribución. Sin embargo, no todas
las bases de datos NoSQL están orientadas a correr sobre clúster.
 Las bases de datos NoSQL no tienen un esquema fijo.

2.3.4.2.1 Cassandra
Apache Cassandra es una base de datos distribuida altamente escalable y de alto
rendimiento diseñada para manejar grandes cantidades de datos en muchos
servidores básicos, proporcionando alta disponibilidad sin un punto único de falla,
es un tipo de base de datos NoSQL.

Apache Cassandra es un sistema de almacenamiento (base de datos) de código

abierto, distribuido y descentralizado/distribuido, para administrar grandes
cantidades de datos estructurados repartidos por todo el mundo. Proporciona un
servicio de alta disponibilidad sin un único punto de falla.

A continuación se presentan algunas de las características de Cassandra:

 Escalabilidad elástica: Cassandra es altamente escalable; permite agregar

más hardware para acomodar a más clientes y más datos según el requisito.
 Siempre en arquitectura: Cassandra no tiene un único punto de falla y está
continuamente disponible para aplicaciones críticas para el negocio que no
pueden permitirse una falla.
 Rápido rendimiento de escala lineal: Cassandra es linealmente escalable,
es decir, aumenta su rendimiento a medida que aumenta la cantidad de nodos en
el clúster. Por lo tanto, mantiene un tiempo de respuesta rápido.
 Almacenamiento de datos flexible: Cassandra se adapta a todos los
formatos de datos posibles, incluidos: estructurados, semiestructurados y no
estructurados. Puede adaptarse dinámicamente a los cambios en sus estructuras
de datos según sus necesidades.
 Fácil distribución de datos: Cassandra proporciona la flexibilidad para
distribuir datos donde los necesite mediante la replicación de datos en varios
centros de datos.
 Compatibilidad con transacciones: Cassandra admite propiedades como
Atomicidad, Consistencia, Aislamiento y Durabilidad (ACID).
 Escrituras rápidas: Cassandra se diseñó para ejecutarse en hardware
básico económico. Realiza escrituras increíblemente rápidas y puede almacenar
cientos de terabytes de datos, sin sacrificar la eficiencia de lectura.
2.3.4.2.2 CouchDB
Apache CouchDB es una base de datos NoSQL open source orientada a
documentos que nos permite gestionar de forma distribuida una gran cantidad de
datos no estructurados. La primera versión de CouchDB se publicó en el año 2005
y el software está implementado en el lenguaje de programación Erlang.

CouchDB garantiza la escalabilidad con su arquitectura y replicación multimaster

para distribuir los datos globalmente. Un clúster de varios nodos guarda todos los
datos de forma redundante, para que siempre estén disponibles cuando sean
necesarios. Puede desplegarse con un único nodo o bien en modo clúster. La
mayoría de proyectos pueden comenzar con una sola instancia de CouchDB. Los
proyectos más exigentes pueden actualizarse cuando sea necesario a un
despliegue en modo clúster. Este modo clúster permite ejecutar un único servicio
de base de datos en cualquier número de servidores o de máquinas virtuales. El
clúster mejora la capacidad y dota al sistema de alta disponibilidad.

Su arquitectura interna es tolerante a fallos, y los fallos se producen en un entorno

controlado. La arquitectura de CouchDB intenta evitar que los problemas
individuales se propaguen en cascada por todo el sistema e intenta aislarlos.

Sus componentes pueden utilizarse como bloques de construcción que resuelven

los problemas de almacenamiento de formas ligeramente diferentes para sistemas
más grandes y complejos. Ya sea que necesites un sistema que sea muy rápido
pero que no se preocupe demasiado por la fiabilidad, o uno que garantice el
almacenamiento en dos o más ubicaciones físicamente separadas, pero que estés
dispuesto a sacrificar parte del rendimiento, CouchDB te puede resultar útil.

2.3.4.2.3 Mongo DB
MongoDB es una base de datos NoSQL orientada a documentos creada por la
compañía 10gen en el año 2007. Se caracteriza por que almacena los datos en
documentos de tipo JSON con un esquema dinámico denominado «BSON».
Los documentos son la unidad básica de organización de la información en
MongoDB, y desempeñan un papel equivalente a una fila en las bases de datos
relacionales. Un documento es un conjunto ordenado de claves que tienen
asociados valores, y que se corresponden con algunas estructuras de datos
típicas de los lenguajes de programación tales como tablas hash o diccionarios.
En general, los documentos contendrán múltiples pares clavevalor, como, por
ejemplo, {“Nombre”:”Juan”,”País”:”España”}. Sus principales características son:

 Las claves son cadenas, por lo que se permite cualquier carácter con un par
de excepciones:
– La clave no puede contener el carácter nulo «\0».
– El punto «.» y el «$» deben evitarse, pues tienen propiedades especiales.
 MongoDB es sensitivo tanto a las mayúsculas/minúsculas como a los tipos
de datos. Así, por ejemplo, los siguientes documentos se consideran distintos:
{“Edad”:3}, {“Edad”: “3”}, {“edad”:3}, {“edad”:”3”}.
 Los documentos no pueden tener claves duplicadas. Así, por ejemplo, el
siguiente documento es incorrecto: {“edad”:3,”edad”:56}.
 Los pares clave-valor están ordenados en los documentos. Por ejemplo, el
documento {“x”:3,”y”:5} no es igual que {“y”:5,”x”:3}. Es importante no definir las
aplicaciones pensando en el orden de los campos, pues MongoDB puede
reordenarlos automáticamente en determinadas situaciones.
 Los valores de un documento pueden ser de diferentes tipos.
Los principales tipos de datos soportados por los documentos en MongoDB son:
 Nulo: representa el valor nulo o bien un campo que no existe. Por ejemplo,
{“x”:null}. Booleanos: representa el tipo booleano, que puede tomar los valores de
true o false. Por ejemplo, {“x”:true}.
 Números: distingue entre números reales, como, por ejemplo, {“x”:3.14}, y
números enteros, como, por ejemplo, {“x”:45}.
 Cadenas: cualquier cadena de caracteres, como, por ejemplo,
{“x”:”Ejemplo”}.
 Fechas: almacena la fecha en milisegundos, pero no la zona horario. Por
ejemplo, {“x”:new Date()}.
 Expresiones regulares: se pueden usar expresiones regulares para realizar
consultas. • Arrays: se representa como un conjunto o lista de valores. Por
ejemplo, {“x”:[“a”,”b”,”c”]}.
 Documentos embebidos: los documentos pueden contener documentos
embebidos como valores de un documento padre. Por ejemplo, {“x”:{“y”:45}}.
 Identificadores de objetos: es un identificador de 12 bytes para un
documento. Por ejemplo, {“x”: OjectId()}.
 Datos binarios: es una cadena de bytes arbitraria que no puede ser
manipulada directamente desde el Shell y que sirve para representar cadenas de
caracteres no UTF8.
 Código Javascript: los documentos y las consultas pueden contener código
JavaScript. Por ejemplo, {“x: function () { …}}.

2.3.5 Aplicaciones web progresivas.

2.3.6 Sistemas operativos para servidores.
2.3.7 Redes computacionales.
ANEXOS
 ANEXO A: ENTREVISTA 1

1. ¿Cómo asigna los centros de cómputo a las materias en los horarios de

clase?
R. Requerimiento para la apertura del centro de cómputo en base en la solicitud
del docente 24 horas previas antes adjuntando el plan de trabajo.

2. ¿Quiénes pueden solicitar la apertura de los centros de cómputo fuera del

horario de clases?
 Docentes.
 Estudiantes.
o Administrativos
o Otros……………
3. ¿Cuál es el proceso de solicitud de apertura fuera de los horarios de clases?
R. Se realiza a través de un registro solicitando la apertura de centro de cómputo,
en el caso de usar un equipo de cómputo se debe llenar un registro extra.

4. ¿Cuáles son los sistemas de vigilancia que cuenta en los centros de

cómputo?
 Cámaras de seguridad
o Software de control (mejorar)
o Otros……………
5. ¿Cómo gestiona los mismo?
R. Las cámaras de seguridad guardan video en un servidor local y tiene un
tiempo de vida de aproximadamente un mes

6. ¿Con que frecuencia se le comunica algún imperfecto en los equipos?

 Cada día
o Cada semana
o Fin de mes
o Fin de semestre
7. ¿Qué imperfectos son más comunes?
 Hardware
 Equipos desconectados.
 Perdida de cables o dispositivos electrónicos
o Daño físico en los equipos o dispositivos electrónicos
 Softwares
 Programas instalados indebidamente.
 Programas de trabajo desinstalados.
o Drivers alterados.
8. ¿Qué tipos de mantenimientos realiza a los equipos de cómputo?
 Mantenimiento de tipo preventivo.
o Mantenimiento de tipo predictivo.
o Mantenimiento de tipo evolutivo.
 Mantenimiento de tipo correctivo.
9. ¿Cómo y cuándo efectuar estos mantenimientos?
R. Se realiza una solicitud de manteamiento o reemplazo del equipo. Cada fin de
semestre se realiza un mantenimiento correctivo y al final de año se realiza
mantenimiento preventivo.

10. ¿Quién es el encargado de distribuir los equipos de cómputo?

 Docentes.
 Estudiantes.
o Administrativos
o Otros……………
11. ¿Cuál es el proceso de distribución?
R. La distribución es en un proceso diferente de acuerdo al encargado (el que
lleno el formulario o el docente)
 ANEXO B: ENTREVISTA 2

1. ¿Cómo asigna los centros de cómputo a las materias en los horarios de clase?
R. Se realiza un horario a inicio de semestres que contiene todas las materias
que usaran los centros de cómputo. Dicho horario contiene materias con fondo
amarillo el cual significa que puede o no usar el centro de computo

2. ¿Quiénes pueden solicitar la apertura de los centros de cómputo fuera del

horario de clases?
 Docentes.
 Estudiantes.
o Administrativos
o Otros……………
3. ¿Cuál es el proceso de solicitud de apertura fuera de los horarios de clases?
R. Se realiza a través de una solo solicitud al jefe de la UTIC

4. ¿Cuáles son los sistemas de vigilancia que cuenta en los centros de

cómputo?
 Cámaras de seguridad
o Software de control (mejorar)
o Otros……………
5. ¿Cómo gestiona los mismo?
R. Las cámaras de seguridad guardan video en un servidor local y tiene un
tiempo de vida de aproximadamente un mes

6. ¿Con que frecuencia se le comunica algún imperfecto en los equipos?

o Cada día
o Cada semana
o Fin de mes
o Fin de semestre
7. ¿Qué imperfectos son más comunes?
 Hardware
 Equipos desconectados.
 Perdida de cables o dispositivos electrónicos
 Daño físico en los equipos o dispositivos electrónicos
 Softwares
 Programas instalados indebidamente.
 Programas de trabajo desinstalados.
o Drivers alterados.
8. ¿Qué tipos de mantenimientos realiza a los equipos de cómputo?
 Mantenimiento de tipo preventivo.
o Mantenimiento de tipo predictivo.
o Mantenimiento de tipo evolutivo.
 Mantenimiento de tipo correctivo.
9. ¿Cómo y cuándo efectuar estos mantenimientos?
R. Se sigue el cronograma de mantenimiento Enero-diciembre y junio-julio

10. ¿Quién es el encargado de distribuir los equipos de cómputo?

 Docentes.
 Estudiantes.
o Administrativos
o Otros……………
11. ¿Cuál es el proceso de distribución?
R. La distribución es en un proceso diferente de acuerdo al encargado(el que
lleno el formulario o el docente)
 ANEXO C: ENTREVISTA 3

1. ¿Cómo asigna los centros de cómputo a las materias en los horarios de

clase?
R. En el inicio de semestre los docentes de acuerdo a su materia solicitan el
uso de los laboratorios, los docentes aprobados pasan posteriormente
agregarlos al biométrico y ellos mismos abrir los laboratorios en sus horas
solicitadas.

2. ¿Quiénes pueden solicitar la apertura de los centros de cómputo fuera del

horario de clases?
 Docentes.
 Estudiantes.
o Administrativos
o Otros……………
3. ¿Cuál es el proceso de solicitud de apertura fuera de los horarios de
clases?
R. Hablar con el encargado para solicitad el formulario de apertura de los
laboratorios

4. ¿Cuáles son los sistemas de vigilancia que cuenta en los centros de

cómputo?
 Cámaras de seguridad
o Software de control (mejorar)
o Otros……………
5. ¿Cómo gestiona los mismo?
R. Las cámaras de seguridad guardan video en un servidor local y tiene un
tiempo de vida de aproximadamente de 20 dias

6. ¿Con que frecuencia se le comunica algún imperfecto en los equipos?

o Cada día
 Cada semana
o Fin de mes

1
 o Fin de semestre
7. ¿Qué imperfectos son más comunes?
 Hardware
 Equipos desconectados.
o Perdida de cables o dispositivos electrónicos
o Daño físico en los equipos o dispositivos electrónicos
 Softwares
o Programas instalados indebidamente.
o Programas de trabajo desinstalados.
o Drivers alterados.
8. ¿Qué tipos de mantenimientos realiza a los equipos de cómputo?
 Mantenimiento de tipo preventivo.
o Mantenimiento de tipo predictivo.
o Mantenimiento de tipo evolutivo.
 Mantenimiento de tipo correctivo.
9. ¿Cómo y cuándo efectuar estos mantenimientos?
R. Se realizan mantenimientos preventivos al inicio y fin del semestre, los
mantenimientos correctivos se realizan si son necesarios.

10. ¿Quién es el encargado de distribuir los equipos de cómputo?

 Docentes.
 Estudiantes.
o Administrativos
o Otros……………
11. ¿Cuál es el proceso de distribución?
R. La distribución depende del encargado que lleno el formulario

2
ANEXO D: REGISTRO DE SOLICITUD DE APERTURA DEL CENTRO DE
COMPUTO LABORATORIO DE REDES

3
ANEXO E: REGISTRO DE SOLICITUD DE USO DE EQUIPO DE COMPUTO
LABORATORIO DE REDES

4
NEXO F: HORARIO DE USO DE CENTROS DE COMPUTO DE LOS
LABORATORIOS BOLIVAR Y SUCRE

5
ANEXO G: REGISTRO DE SOLICITUD DE APERTURA DEL CENTRO DE
COMPUTO

ANEXO H: CENTRO DE CÓMPUTO LABORATORIO DE REDES

6
7
ANEXO I: CENTRO DE CÓMPUTO LABORATORIO BOLIVAR

8
ANEXO J: CENTRO DE CÓMPUTO LABORATORIO SUCRE

9
ANEXO K: CENTRO DE CÓMPUTO LABORATORIO GRAL. ESTEBAN ARCE

10
ANEXO L: CENTRO DE CÓMPUTO LABORATORIO CNL. JOSE MIGUEL
LANZA

11
ANEXO M: CENTRO DE CÓMPUTO LABORATORIO CNL. JULIO SANJINES
GOITIA

12
13