INFORMÁTICA

Y
TELECOMUNICA
CIONES

TALLER DE PROYECTO DE SOFTWARE

ToxiCar

NOMBRE: LILIAN CIFUENTES TRONCOSO, ALEJANDRO MAYRÓ LENA, BASTIÁN

LARRONDO GALLO.
CARRERA: INGENIERÍA EN INFORMÁTICA.
ASIGNATURA: TALLER DE PROYECTO DE SOFTWARE.
PROFESOR: JOSE MARTÍNEZ OPAZO.
FECHA: 22/06/2022.
Contenido

1 Introducción............................................................................................................................ 4
2 Definición problemática........................................................................................................... 5
2.1.1 Identificación del problema.......................................................................................5
2.1.2 Cadena de valor.......................................................................................................6
3 Requerimientos....................................................................................................................... 7
3.1 Requerimientos de Usuario.............................................................................................8
3.2 Requerimientos de Sistema.............................................................................................8
3.3 Requerimientos funcionales.............................................................................................9
3.4 Requerimientos no funcionales......................................................................................10
4 Matriz de trazabilidad de requerimientos..............................................................................11
5 Gestión de Configuración del Software.................................................................................11
5.1 Línea base..................................................................................................................... 11
5.2 Control de Cambios.......................................................................................................14
6 Alternativas técnicas de implementación de solución...........................................................15
7 Definición técnica de la solución...........................................................................................19
8 Análisis y diseño del producto...............................................................................................19
8.1 Reglas del negocio del Cliente......................................................................................19
8.2 Diseño de la Solución....................................................................................................20
8.2.1 Diagramas BPMN...................................................................................................20
8.2.2 Diagramación UML.................................................................................................21
8.2.2.1 Casos de uso..................................................................................................21
8.2.2.2 Diagrama de secuencias.................................................................................23
8.2.2.3 Diagrama de componentes..............................................................................27
8.2.2.4 Diagrama de clases de diseño........................................................................27
9 Base de Datos...................................................................................................................... 28
9.1 Arquitectura del almacenamiento..................................................................................28
9.2 Modelo Físico................................................................................................................29
9.3 Elección y justificación del SGBD seleccionado............................................................29
9.4 Tiempo de respuesta.....................................................................................................31
9.5 Estimación de tamaño de base de datos.......................................................................33
9.6 Mecanismos de seguridad.............................................................................................34
9.7 Monitorización y afinamiento.........................................................................................35

2
10 Factibilidades.................................................................................................................... 37
10.1 Factibilidad Técnica.......................................................................................................37
10.2 Factibilidad Implementativa...........................................................................................38
11 Ciclo de vida y metodología de desarrollo.........................................................................40
11.1 Metodología ágil............................................................................................................ 40
11.2 Ciclo de vida..................................................................................................................43
12 Planificación temporal Desarrollo......................................................................................45
12.1 Carta Gantt.................................................................................................................... 45
13 Planificación de Recursos Humanos para el desarrollo....................................................45
14 Gestión de las comunicaciones.........................................................................................46
15 Calidad del producto......................................................................................................... 46
15.1 Plan de calidad.............................................................................................................. 46
15.2 Producto por entregar....................................................................................................46
16 Diseño casos de pruebas..................................................................................................47
16.1 Pruebas funcionales......................................................................................................47
16.2 Pruebas estructurales o de Caja Blanca........................................................................47
17 Análisis de resultados de las pruebas...............................................................................48
18 Generación de métricas e indicadores..............................................................................49
19 Matriz de Riesgos.............................................................................................................50
19.1 Desarrollo del software..................................................................................................50
19.2 Mapa de calor................................................................................................................ 51
20 Plan de Distribución y Definición Ambiente de Producción...............................................51
21 Plan de implementación....................................................................................................53
21.1 Manual técnico.............................................................................................................. 53
21.2 Manual de usuario......................................................................................................... 53
22 Interesados por el proyecto...............................................................................................54
23 Conclusión........................................................................................................................ 57
24 Bibliografía........................................................................................................................ 58

3
1 Introducción

El trabajar cerca de gases puede ser algo muy peligroso para la persona que se encuentra
expuesta a estos, con tan solo inhalar un pequeño porcentaje de gases que se puedan encontrar
en el aire por un incendio, o en un laboratorio químico o el trabajo más impensado un Gasfíter
puede llegar a ser mortal, en la mayoría de los casos el rápido actuar ante las situaciones puede
salvar la vida del trabajador o de las personas, es cierto que existen muchas medidas para evitar
estos problemas o para afrontar estas situaciones, pero aún se sigue encontrando en riesgo el
personal, y aun con toda la implementación de seguridad.
Para lograr ayudar y evitar estos problemas se creó Toxicar, con una facilidad para ser utilizado
y un diseño cómodo para funcionar en cualquier momento, es un robot medidor de gases que se
controla desde una aplicación móvil y envía los datos de mediciones a una página web, esto
ayudara a disminuir los riesgos siempre presentes en estos tipos de trabajos que se encuentran
gases que pueden ser muy peligrosos.
A lo largo del informe, aparte de los puntos de anteriores entregas. Se presenta plan de calidad,
pruebas funcionales y pruebas estructurales, el plan de distribución del proyecto junto al
diagrama de distribución, actividades que se realizaran post desarrollo de la implementación del
proyecto junto al manual técnico y el manual de usuario para el uso tanto de personas con o sin
conocimientos del área o de productos tecnológicos.

4
2 Definición problemática

2.1.1 Identificación del problema

El proyecto ToxiCar nace con el propósito de ayudar a los trabajadores que realizan mediciones
de gases tóxicos en el sector industrial o particular, para que sus actividades se ejecuten con
mayor seguridad, específicamente reduciendo los riesgos de intoxicación por el contacto que
tienen las personas con dichos químicos.
La tarea de testear puede resultar peligrosa para los trabajadores, ya que deben estar con un
dispositivo de medición en la mano y en el mismo lugar para tomar las muestras, lo que podría
causar una intoxicación al no contar con el equipamiento necesario (botas, guantes, mascarillas,
traje superior e inferior) y en el peor de los casos una explosión si el dispositivo no logra detectar
a tiempo el gas, debido a que estos productos son limitados (mayormente no permiten medir
varios gases a la vez) y muy costosos para las características que poseen, tales como, poca
capacidad de almacenamiento, pantallas de baja resolución, transferencia de datos lenta y
funcionabilidades escasas.
En el mercado existe un dispositivo denominado “Medidor de CO2 PCE-7755” que se encuentra
en la página www.pce-instruments.com, el cual puede detectar el gas CO2 y su precio es de
$349.467. ToxiCar pretende ofrecerles a sus clientes un producto que pueda medir múltiples
gases a un costo razonable a sus características, accesible y personalizable, de acuerdo a las
necesidades del usuario, ya que los requerimientos de una empresa minera son distintos a los
de un gasfíter, por ejemplo, si el robot de ToxiCar se encuentra en túneles mineros, éste tendrá
que soportar caminos inestables, mientras que una persona particular, solo necesitará que el
dispositivo se desplace con una estructura física básica. A su vez conlleva un cambio en los
sensores de detección ya que la concentración de químicos también es diferente en ambos
lugares. Usualmente en los subterráneos, encontramos “Nitrógeno, anhídrido carbónico,
monóxido de carbono, gases nitrosos, anhídrido sulfuroso, gas sulfhídrico y gas grisú”
(Seguridad Minera, 2016) y en una casa o departamento, gas butano (calentamiento de agua),
monóxido de carbono (combustión, calefacción o chimeneas) y gas natural (cocina).
Cabe señalar que a pesar de las intoxicaciones que puedan tener los trabajadores que miden
gases, existe la posibilidad de derrumbes, caídas, lesiones físicas u otro tipo de accidentes, dado
que los lugares de medición en ocasiones suelen ser peligrosos, pequeños, de difícil acceso y
con poca visibilidad, como en el caso de un incendio, donde el humo y las llamas ponen en
peligro al propio trabajador. Detectar de forma precisa el gas es imprescindible cuando existe
una emergencia química en una empresa, ya que los recursos para combatir el incidente
variarán según el gas, recordando también que dichos químicos “Ponen en peligro la salud y la
vida de las personas, por eso es necesario utilizar equipos de detección de gases tanto en
ámbitos residenciales, industriales y comerciales” (Mercadeo Premac, 2021).
En resumen, con el proyecto ToxiCar se pretende unir la informática con la robótica, para
desarrollar un producto único, tecnológico y novedoso con altas características, tanto de
software como hardware, estando al alcance de todas las personas.

5
2.1.2 Cadena de valor

* Cadena de valor orientada a la competencia, organizaciones que desarrollan dispositivos de

medición.
En la cadena presentada, encontramos procesos con determinados déficits y debilidades, los
cuales afectan al producto final, por ejemplo, no existe una inversión en nueva tecnología para
los dispositivos, más bien se utiliza para comprar maquinarias para aumentar la capacidad de
producción.
Un punto que es bastante negativo es que implementan la misma arquitectura en la mayoría de
sus productos, esto quiere decir que los cambios entre una versión nueva con una antigua, no es
significativa, lo más común que varía, es la capacidad de almacenamiento, funciones de
traspaso de registros al computador y mayor precisión, sin embargo, el patrón se mantiene,
conectar con un cable el dispositivo para transferir información, espacio de 500 a 600 datos y
ajuste de los sensores. El diseño físico de estos dispositivos es el mayor cambio visible, ya que
pueden ser más pequeños, ligeros y transportables, aun así, sus pantallas y botones mantienen
la misma calidad. Se puede decir que las empresas que fabrican testers, prefieren continuar con
su ciclo de producción, la innovación o adaptación a los cambios, es un factor que no se
encuentra muy presente en ellas.
Otro punto desfavorable, es que este tipo de organizaciones no ofrece un servicio para
desarrollar un producto de acuerdo las necesidades del cliente, por lo general los sensores de
detección son predeterminados para cada dispositivo, no permitiendo ser sustituidos, por
ejemplo, si un usuario necesita medir gases muy específicos, lo más seguro es que un tester no
cuente con dicha capacidad, siendo necesario comprar un segundo o tercer dispositivos. Esto
también sucede con el espacio de almacenamiento, dado que tampoco existe la opción para
ampliar su capacidad, teniendo un número fijo de registros máximos para guardar, conllevando a
la eliminación de datos, si se llegará a su límite.

6
La falta de procesos, dan como resultado un producto no innovador con bajas capacidades y
funcionabilidades, afectando principalmente a los trabajadores que hacen uso de los dispositivos
y empresas que los compran, tal como mineras, químicas, bomberos, gasfíteres, o cualquier otra
persona u organización que los utilice.
Las empresas que fabrican los testers, se preocupan de tener un producto precioso y pequeño,
sin embargo, dejan de lado la seguridad del personal, ya que la labor de medir gases es la
misma independiente a la versión del dispositivo.
En resumen, los efectos que trae la falta de procesos a los usuarios en relación al producto final
son, riesgos de accidentes (caídas, explosiones, intoxicaciones, etc.) al no innovar, necesidad de
comprar uno o más dispositivos para medir determinados gases, dificultad para transferir datos
al computador, mediante cable, producto repetitivo (mismas funciones, capacidades de
almacenamiento limitadas y no expandibles, pantallas de baja de resolución, etc.) y no se adapta
siempre a las necesidades del usuario.

3 Requerimientos

El proyecto ToxiCar, trae un nuevo producto al mercado (Robot, Accesorio, Aplicación Móvil y
Página Web), para que los usuarios puedan tomar muestras de gases ambientales de forma más
segura y automatizada. Se trata de un emprendimiento que soluciona diversos problemas
detectados en el proceso de medición. Los requerimientos se obtuvieron a partir de la
observación y análisis de los dispositivos actuales, con el objetivo de mejorarlos, agregándoles
nuevas funcionabilidades y capacidades que no existían y limitaban al usuario, por ejemplo, la
característica “Transferir registros al computador por USB”, se remplazó por “Generar reportes
en Excel a través de la página web”, por lo cual ya no será necesario un cable conectado al
tester ni al computador para descargar los datos. Otros requerimientos como visualizar, guardar
y eliminar mediciones, son funciones que los dispositivos actuales ya tienen, pero los procesos
internos del robot serán diferentes y resultarán más sencillos para los usuarios finales.
Agregando también que las capacidades van a ser superiores, tal como el espacio de
almacenamiento. Ambos dispositivos pueden guardar datos, sin embargo, ToxiCar les permitirá
a los usuarios personalizar el número de registros para almacenar. Una característica única del
proyecto es que el dispositivo ToxiCase, permitirá ampliar el rango de distancia para controlar el
robot, se incluye este como un “Plus”, para asegurar que el trabajador pueda realizar mediciones
de forma segura. Por lo general este producto debe ser compacto y pequeño para que las
personas lo puedan transportar sin inconvenientes.
Existen muchas técnicas para obtener requerimientos, tal como entrevistas, sesiones facilitadas,
cuestionarios, prototipos, seguimiento, observación, etc. Para determinar correctamente los
requerimientos se planificó y realizó una entrevista a uno de los interesados del proyecto
(gasfíter), la selección de esta persona no fue al azar, ya que se trata del usuario que utilizará el
sistema. Por lo general un cliente (ej. Empresa Minera) puede solicitar un determinado producto,
sin embargo, la compra no siempre es la correcta, ya que primero se debe conocer las
necesidades del usuario (Obrero o Minero), antes de hacer la adquisición.
Durante la sesión se pudo obtener información de cómo funciona un sistema actual de medición
de gases, y cuáles son las características que se deben mejorar o incluir en el proyecto. Así
mismo se fue guiando al entrevistado, para generar un listado completo de las necesidades, las
cuales fueron anotadas para su debido análisis.

7
Para confirmar la toma de requerimientos de la entrevista, se desarrolló un cuestionario, para
que el usuario (gasfíter), lo resolviera. Dentro de este se incluyeron preguntas como, que
experiencia tiene con la posible tecnología a implementar, cuáles son las expectativas sobre el
producto final, que características físicas y lógicas debe tener el robot para un óptimo
funcionamiento, entre otras.

3.1 Requerimientos de Usuario

RU01- El usuario trabajador podrá realizar múltiples mediciones de gases con la aplicación móvil
conectada al robot / accesorio.
RU02- El usuario trabajador podrá guardar los resultados de las mediciones.
RU03- El usuario trabajador podrá visualizar en la aplicación móvil los valores de las mediciones
al instante.
RU04- El usuario trabajador podrá controlar el robot (adelante, atrás, derecha, izquierda y
detener) mediante la aplicación para smartphone.
RU05- El usuario trabajador podrá consultar todas sus mediciones guardadas por medio de la
página web.
RU06- El usuario administrador podrá ver y eliminar las mediciones almacenadas de los
trabajadores en la página web.
RU07- El usuario trabajador podrá eliminar sus propias mediciones a través de la página web.
RU08- El usuario trabajador podrá descargar en Excel el listado de sus mediciones por medio
del sitio web.
RU09- El usuario administrador podrá descargar en Excel todas las mediciones realizadas por
los trabajadores.
RU10- El usuario administrador podrá exportar a Excel el listado completo de los usuarios
registrados en el sistema (trabajadores).
RU11- El usuario trabajador podrá filtrar sus mediciones, a través del identificador, tipo de gas,
localización, fecha y hora.
RU12- El usuario administrador podrá filtrar a los usuarios, mediante el rut, nombre, teléfono,
dirección, comuna y correo.
RU13- El usuario administrador podrá filtrar (identificador, tipo de gas, localización, fecha y hora)
las mediciones de todos los trabajadores.
RU14- El usuario trabajador podrá realizar las mismas funciones en ToxiCar o ToxiCase.

3.2 Requerimientos de Sistema

La aplicación móvil de Toxicar es amigable para el usuario y también para su teléfono móvil
Android, ya que momentáneamente está destinada solamente a dispositivos con este SO, esta
aplicación ocupará un espacio entre 10 a 30 MB en el sistema, y consumiendo no más de 1GB

8
como máximo de RAM, gracias a estos requisitos básicos tan pequeños es que Toxicar puede
ser utilizado en Sistemas Android de gama baja como también en dispositivos actuales con
Android 12 en los cuales esta aplicación no supone carga alguna, lo que podría considerarse
más “difícil” de acceder para los usuarios de Toxicar seria la conexión a internet para él envió de
las mediciones que vaya recibiendo el Robot o Accesorio y se vayan guardando en la App Móvil,
ya que al estar directamente conectada con el servidor, las mediciones se irán guardando dentro
de este para su posterior visualización en la página web, si bien en la actualidad es muy raro que
una persona común no tenga acceso a internet en cualquier sector donde se encuentre, todavía
se presentan casos que no tienen acceso a las RRSS o a internet en general, de igual forma el
acceso a Bluetooth en el dispositivo móvil es fundamental para la utilización de la app y el control
del Robot o Accesorio, ya que estos funcionan directamente conectado con la aplicación
mediante Bluetooth.
RS01- La aplicación móvil funciona en Sistemas Operativos Android 4.0 o superiores.
RS02- La aplicación móvil dispone de unos 10 a 30 MB de espacio que será utilizados en el
Dispositivo.
RS03- La aplicación móvil utilizara entre 1GB y 2GB de RAM en el Dispositivo.
RS04- El dispositivo móvil requiere de Conexión a Bluetooth.
RS05- El dispositivo móvil requiere de Conexión a Internet.
RS06- La página web contara con una disposición sencilla para su uso.
RS07- La página web podrá generar una visualización de las mediciones y filtrar por distintos
parámetros.
RS08- El Robot Contará con un diseño que se podrá adaptar a cualquier situación.
RS09- Los sensores del robot son capaces de medir los gases presentes en el ambiente.
RS10- Los sensores del Robot son capaces de identificar los gases presentes en el ambiente.
RS11- El accesorio y el robot deben tener el mismo módulo de radiofrecuencia.
RS12- La conexión entre ToxiCase y la aplicación móvil debe ser con Bluetooth.
RS13- El accesorio, retransmitirá los datos recibidos o enviados por aplicación móvil o robot.
RS14- La base de datos debe contar con mecanismo de seguridad para limitar el ingreso de
datos (privilegios, roles, vistas, procedimientos almacenados, etc.).
RS15- Los componentes del accesorio y robot, deben ser sustituibles y remplazables fácilmente.
RS16- El alcance que debe tener ToxiCase para controlar el robot debe ser superior a los
1000m.

3.3 Requerimientos funcionales

RF01- El Robot deberá medir gases en el ambiente con los sensores que posee.
RF02- El sistema permitirá utilizar el GPS del celular para almacenar las mediciones con su
respectiva ubicación.

9
RF03- El Robot deberá enviar los resultados de las mediciones a la aplicación móvil.
RF04- La página web buscará y mostrará las mediciones efectuadas por el usuario.
RF05- El usuario trabajador no podrá modificar los valores de las mediciones en la página web.
RF06- La página web y aplicación móvil permitirán el ingreso de los trabajadores y
administradores mediante rut y contraseña.
RF07- La página web no mostrará a un trabajador las mediciones de otra persona.
RF08- La aplicación móvil deberá permitirle al usuario trabajador realizar mediciones y
visualizarlas.
RF09- La aplicación móvil permitirá al trabajador realizar la cantidad que desee de mediciones.
RF10- La página web y aplicación móvil funcionará si el usuario ingresado es válido.
RF11- La página web deberá generar un Excel cuando el usuario administrador o trabajador lo
soliciten.
RF12- La aplicación móvil y página web deben permitir el registro de nuevos usuarios.
RF13- El usuario trabajador podrá medir el nivel de monóxido de carbono, dióxido de carbono,
gas licuado del petróleo y alcohol en el ambiente.
RF14- El administrador podrá eliminar un usuario de tipo trabajador mediante la página web.
RF15- El sistema permitirá que cualquier usuario pueda modificar sus datos personales excepto
el Rut.
RF16- El accesorio permitirá al usuario trabajador controlar el robot (adelante, atrás, GLP,
Alcohol, etc.).

3.4 Requerimientos no funcionales

RNF01- El tiempo de respuesta para las mediciones debe ser inferior a 2 segundos.
RNF02- La página web será compatible con todos los navegadores web.
RNF03- La página web contará con módulos de ayuda.
RNF04- Los botones de la aplicación móvil y la página web deben tener un color verde y
amarillo.
RNF05- Las Interfaces del trabajador como administrador deben estar desarrolladas con
lenguaje de programación PHP y HTML.
RNF06- La base de datos debe ser con MySQL.
RNF07- Si hay más de 10 minutos de inactividad en la página web, el sistema cerrará sesión,
tanto para usuario administrador como trabajador.
RNF08- El accesorio y el robot tendrán un diseño compacto, pequeño y liviano.
RNF09- El lenguaje de programación del robot debe ser el mismo que para el accesorio (C++).

10
RNF10- La página web tendrá un código QR integrado para que los usuarios puedan descargar
la aplicación.
RNF11- ToxiCase debe retransmitir los datos en menos de 2 segundos, independiente a la
distancia.

4 Matriz de trazabilidad de requerimientos

Matriz de trazabilidad.

5 Gestión de Configuración del Software

5.1 Línea base

El proyecto ToxiCar, ofrece a los usuarios un producto nuevo, novedoso y con alta innovación.
Se puede decir que es una versión mejorada de los testers actuales, con una arquitectura

11
totalmente diferente, pasando de ser un dispositivo de mano a un robot controlado por una
aplicación móvil. Muchas de las características entre ambos productos serán compartidas, tal
como medir gases, almacenar mediciones, consultar datos, eliminar registros, etc., ya que la
base de ToxiCar corresponde a la de estos dispositivos, que es la detección, control y monitoreo
de químicos, por lo tanto, estos elementos no serán modificados, de lo contrario estaríamos
hablando de un producto diferente. Lo que si cambia es la forma y el proceso interno de dichas
funciones, por ejemplo, el almacenamiento de las mediciones de un testers es de manera local,
dentro de su mismo chip de memoria, mientras que, en ToxiCar, los datos se almacenarán en un
servidor de la nube, dándole la posibilidad al usuario de ampliar el espacio para guardar
registros, cosa que los testers actuales no pueden hacer.
Los requerimientos de usuario correspondientes a la línea base del proyecto, son RU01
(múltiples mediciones con la app móvil), este no cambiará, ya que el desarrollo de la aplicación
se encuentra contemplado y no hay otra forma de controlar al robot, RU02 (guardar mediciones),
es esencial que el producto, pueda almacenar registros, ya que los usuarios lo necesitan para
generar futuros reportes, de hecho uno de los objetivos del proyecto es ofrecerles a los usuarios
una mayor capacidad para guardar mediciones, por lo cual al no incluir dicha característica, no
se estaría solucionando por completo la problemática (los dispositivos actuales no permiten más
de 800 registros), más bien se estaría ofreciendo un producto con características inferiores.
Otros requerimientos que corresponden a la línea base son el RU03 (visualizar mediciones en
app) y RU04 (controlar robot adelante, atrás, derecha e izquierda por medio de la aplicación), ya
que al igual que el RU01, no existe otro medio que permita manejar el robot, que no sea por la
aplicación. Excepto si se creara un dispositivo exclusivo para controlarlo, sin embargo, el
smartphone, puede realizar las mismas funciones, agregando también, que la mayoría de las
personas ya cuenta con uno de estos, por lo que es mejor aprovechar lo que ya existe y sobre
todo si es altamente compatible.
Existe la posibilidad de que el requerimiento RU05 (visualizar mediciones en la página web), sea
modificado, para incorporarlo en la aplicación móvil, de esta forma el usuario trabajador podrá
consultar el historial de registros en ambas plataformas. Otros requerimientos que también
podrían ser cambiados, son el RU07 (eliminar mediciones a través del sitio web), RU08
(descargar reportes en Excel) y el RU11 (filtrar mediciones por usuario trabajador) ya que al igual
que el RU05, son funciones que también se podrían realizar por medio de la app.
Los requerimientos del administrador RU09, RU10 , RU12 y RU13 (exportar y filtrar mediciones y
usuarios a Excel), se mantendrán en la página web, ya que el volumen de datos puede resultar
bastante grande. Utilizar un computador es lo ideal para ver toda la información de manera
sencilla. Cabe decir que la aplicación móvil, principalmente se encuentra diseñada para los
trabajadores y no hay funciones de tipo administrador en ella. Otro requerimiento sumamente
importante es el RU14 (mismas funciones en ToxiCar o ToxiCase), ya que independiente a la
opción que escoja el trabajador el software debe ejecutar las mismas tareas (adelante, atrás,
GLP, alcohol, etc.).
Los requerimientos de sistema de la línea base son los siguientes, RS04 (dispositivo móvil con
Bluetooth), dado que, la conexión entre el robot y el smartphone será a través de este medio, el
cual permite la transferencia de datos de forma bidireccional (recibir y enviar), RS05 (móvil con
Internet), es fundamental que el dispositivo tenga una conexión a la red, ya que las mediciones
se almacenarán en la nube, siendo necesario el Internet para guardarlas, como también es
requerido para iniciar sesión o registrarse en la aplicación, RS06 (página web con disposición
sencilla para su uso), RS07 (el sitio podrá listar y filtrar las mediciones con distintos parámetros),
esta característica es muy importante, ya que si el usuario ha almacenado una gran cantidad de
mediciones, buscarlas de forma manual podría ser casi imposible o muy difícil, por lo tanto un

12
filtro específico (fecha, hora, tipo de gas, etc.), podrá listar de manera automatizada las
mediciones que el usuario necesita, RS08 (el robot tendrá un diseño adaptable a cualquier
situación), como ToxiCar, no tiene un público objetivo, la construcción base del robot, debe ser
de tal forma, que tanto una empresa minera como un particular, puedan utilizar el dispositivo
para el mismo propósito (detección de gases), este diseño, será el inicial, ya que cuando el
proyecto este implementado, tendrán la oportunidad de personalizar el producto, algunos
componentes para aquello, son ruedas, motores, carcasa, entre otros, RS09, RS10 (sensores
capaces de medir e identificar gases), RS11 (accesorio y robot mismo módulo de
radiofrecuencia), RS12 (ToxiCase con Bluetooth), RS13 (retransmisión de datos), RS14
(mecanismos de seguridad), RS15 (componentes sustituibles) y RS16 (alcance superior a los
1000 metros).
Los otros requerimientos de sistema, RS01 (aplicación compatible solo para Android 4.0), RS02
(consumo entre 10 y 30 MB de espacio del dispositivo) y RS03 (la app utilizará de 1 a 2 GB de
RAM), son características bastante relativas, ya que pueden variar de acuerdo a las nuevas
necesidades que se presenten o a sus modificaciones, entre más funciones que se integren a la
aplicación, mayor será el consumo de almacenamiento y RAM. Todos estos elementos serán
conversados con el cliente, en caso de haber un aumento significativo.
Los requerimientos funcionales, que no se modificarán son, el RF01 (medir gases con el
robot) y el RF02 (utilizar GPS del móvil), este último es una característica que los dispositivos
testers actuales no tienen. Es importante para los usuarios saber dónde se realizó una medición,
principalmente para diferenciar una de otras, ya que, al haber tantos registros, es probable que
se pierda el control de ellos. La mayoría de los smartphones actuales trae GPS incorporado, por
lo cual se aprovechará, en vez de modificar al robot para integrarle uno.
Otros requerimientos funcionales que también se mantendrán son el RF03 (enviar datos a la
app), RF05 (el usuario no podrá modificar las mediciones), dado que, al realizar un cambio, los
valores ya no serían los originales o iniciales que detectó el robot, RF06 (ingreso a la app y
página mediante Rut y contraseña), esta es una característica fundamental, ya que como
muchas personas utilizarán el sistema, es necesario saber quién realizó cada medición, RF07 (la
página web solo mostrará las mediciones del propio trabajador), RF08 (realizar y visualizar
mediciones en la app), RF09 (la aplicación permitirá el trabajador realizar la cantidad de
mediciones que desee), RF10 (página web y app solo funcionarán con un usuario valido), RF12
(registros de nuevos usuarios), este requerimiento es la base de un Login, ya que si no se puede
crear un usuario, tampoco podría haber un ingreso. RF14 (eliminar usuarios mediante el sitio),
RF15 (modificar datos personales excepto el Rut), debido a que este es el identificador único de
las personas, a diferencia de los demás elementos como el teléfono, correo y clave, que si
pueden cambiar. Por último, el RF16 (ToxiCase controlará el movimiento y mediciones del
robot).
Los requerimientos funcionales con posibilidad de ser modificados en el tiempo son el RF04
(buscar y mostrar mediciones en página web) y el RF11 (generar Excel a través del sitio), dado
que ambas funciones podrían ser integradas en la aplicación móvil. Agregando también el RF13
(medir monóxido y dióxido de carbono, gas licuado de petróleo y alcohol), ya que las
capacidades de detección son diferentes en cada cliente (mineras, bomberos, gasfíteres, etc.).
Por último, encontramos los requerimientos no funcionales que serán parte de la línea base
del proyecto. El primero es el RNF01 (tiempo de respuesta inferior a 2 segundos), ya que los
clientes, necesitan un sistema que responda rápidamente, sobre todo si corresponden a
funciones de medición, RNF03 (página web con módulo de ayuda), es esencial que el sitio tenga
una guía o instructivo de uso para que usuario pueda manejar los productos sin inconvenientes,
dicho manual proporcionará información sobre la app móvil, página web y robot, RNF04 (botones
13
de color verde y amarillo), RNF05 (interfaces desarrolladas con PHP y HTML), RNF06 (base de
datos MySQL), se escogió esta tecnología de almacenamiento y programación, ya que ambas
son altamente compatibles entre sí, por lo cual no serán modificadas, RNF07 (cerrar sesión a los
10 minutos de inactividad), con el objetivo de mantener seguras las mediciones de los usuarios,
evitando que otra persona pueda acceder a ellas si el dispositivo queda encendido, RNF08
(accesorio y robot con diseño compacto y liviano), esto es importante ya que el producto debe
ser transportable para los clientes (mineros, químicos, gasfíteres, etc.), RNF09 (lenguaje de
programación C++), RNF10 (página web con código QR para descargar la aplicación),
finalmente tenemos el requerimiento RNF11 (menos de 2 segundos para la retransmisión de
datos).
El requerimiento RNF02 (página web compatible con todos los navegades), es probable que sea
modificado en el futuro, para especificar con más detalles los softwares (Chrome, Edge, Safari,
etc.), que serán compatibles con el sitio.
Como se utilizará la metodología Scrum para el proyecto, la línea base corresponde al Product
Backlog, el cual contiene una “Lista con todos los requerimientos iniciales del producto que se va
a desarrollar.” (EALDE, 2019). Dicha lista es dinámica y va evolucionando a medida que avanza
el proyecto y su entorno. Los requerimientos mencionados anteriormente (usuario, sistema,
funcionales y no funcionales), tienen una alta probabilidad de no ser modificados, ya que
pertenecen a la base del sistema, sin embargo, el Product Owner es el que toma la decisión
final, ya que recordemos que este, es el dueño del Product Backlog, por lo tanto, puede agregar
o modificar los requerimientos, como también cambiar su priorización.
En resumen, los requerimientos que no serán modificados son:

Tipo de requerimiento Código del requerimiento

RU01, RU02, RU03, RU04, RU09, RU10,
Usuario
RU12, RU13, RU14.
RS04, RS05, RS06, RS07, RS08, RS09, RS10,
Sistema RS11, RS12, RS13, RS14, RS15, RS16.

RF01, RF02, RF03, RF05, RF06, RF07, RF08,

Funcionales
RF09, RF10, RF12, RF14, RF15, RF16.
RNF01, RNF03, RNF04, RNF05, RNF06,
No Funcionales
RNF07, RNF08, RNF09, RNF10, RNF11.

Cabe señalar que, en caso de haber alguna modificación en los requerimientos, independiente a
que pertenezcan o no a la línea base, serán manejados de acuerdo al tipo de cambio (normal o
emergencia), a continuación, en “Control de Cambios”, se detallarán las acciones y protocolos a
tomar.

5.2 Control de Cambios

Los cambios son habituales en cualquier tipo de proyecto de software. Estos “Aparecen en
diferentes formas: requisitos nuevos, cambios sobre lo entregado, incidencias, nuevos
usuarios…” (Tirado, 2019). En el modelo tradicional, un cambio significa hacer algo distinto a lo
planificado. Las modificaciones son mejoras sobre lo que tenemos, las cuales sirven para
obtener un producto superior, sin embargo, la lógica del proyecto, funcionabilidad tecnología
empleada y el entorno de trabajo se podrían ver afectados si no hay una gestión.

14
La metodología de desarrollo que se utilizará para el proyecto es Scrum, que corresponde a un
método ágil, el cual gestiona de muy buena forma los cambios, por lo general solo basta con
introducir el nuevo requerimiento en el Product Backlog, para ejecutarlo en el próximo Sprint o
cuando le toque, dependiente de su prioridad (alta, baja o media).
Según ITIL, existen dos tipos de cambios relevantes:
Cambios normales: llegan en cualquier momento y se pondrán en una “lista de espera” hasta la
próxima reunión de preparación del Sprint, donde serán tratados, para evaluar su aceptación y si
entran a formar parte o modifican de alguna manera el Product Backlog.
Cambios de emergencia: los cambios de emergencia como los normales, aparecen en
cualquier momento y circunstancia. Según el nivel de impacto se pueden clasificar en dos tipos
para ser manejados:
- Cambios de emergencia sin impacto sustancial: para tratar estos cambios, se dejará un
tiempo extraordinario en cada Sprint, específicamente dedicado a estos, de forma similar a la
manera de resolver incidentes, bugs, etc.
- Cambios de emergencia con impacto sustancial: Si el cambio puede esperar, se tratará
en la siguiente reunión de planificación del Sprint, para construir el nuevo Sprint Backlog. En
caso contrario, el Sprint se deberá interrumpir para volver a su debida planificación. Esta
acción, la ha de tomar el Product Owner, previamente informado por el equipo y valorando el
impacto que trae consigo dicho cambio e interrupción.
De forma general al haber una solicitud de cambios de requerimientos, se hará una valoración y
análisis de la modificación, se generará la documentación respectiva, habrá una negociación con
el cliente y por último se planificará y realizará el cambio.
Como protocolo, cada solicitud debe ser a través del documento PCR (petición de cambios de
requerimientos), el cual debe incluir el nombre del proyecto, la fecha, descripción, solicitante,
encargado del cambio, prioridad, impacto, plazo y comentarios. Una vez aprobada las
modificaciones, se documentarán en el “registro de cambios”, incluyendo el nombre del proyecto,
tarea, responsable, fecha, prioridad, estado del progreso y tipo de cambio. También se deberá
actualizar el cronograma para ajustarlos de acuerdo a los cambios o nuevos requerimientos.

6 Alternativas técnicas de implementación de solución

Alternativa 1: Desarrollar aplicación móvil, con Xamarin Forms, con el objetivo de crear un
software compatible tanto con Android como IOS, para ello se necesita el programa Visual
Studio 2019 o versión superior. Dentro de esta misma alternativa, se propone una página web,
programada con ASP.NET, API REST (conexión entre base de datos, app y página web),
servidor Azure en la nube, robot con Arduino Nano BLE y accesorio basado en Adafruit QT PY
RP2040 y modulo Lora 433mhz.
Las principales ventajas de esta alternativa es que, la aplicación, será compatible con dos
sistemas operativos, la disponibilidad de Azure es del 99.99% y la capacidad del servidor se
adapta de acuerdo a su uso. Otro de los beneficios generales de la nube, es que el proveedor es
el encargado de mantener el hardware y actualizar la plataforma, lo que ahorra costos de
mantención. Además, con esta alternativa, el trabajador no tendrá problemas para medir gases a
larga distancia, ya que, el módulo Lora de ToxiCase tiene un alcance de 5km, lo cual es
suficiente para su labor.

15
Dentro de las desventajas encontramos, baja documentación de Xamarin Forms, API y Arduino
Nano BLE, incrementa la complejidad de conectar la aplicación con el robot, al tener una placa
con Bluetooth de bajo consumo, se requiere de mano de obra especializada, aumenta el costo y
tiempo de desarrollo.
Cabe señalar que el accesorio (ToxiCase), se encuentra basado en la placa Adafruit QT PY
RP2040, la cual es difícil de encontrar e importar por su bajo stock. Normalmente la compañía
saca lotes de 100 unidades o menos, los cuales se agotan rápidamente. En caso de haber una
demanda alta por ToxiCase, podría no haber suficientes placas para su desarrollo.
La presente alternativa cumple con los objetivos del proyecto, los cuales son crear un robot,
accesorio, aplicación móvil y página web, para automatizar el proceso de medición de gases, sin
embargo, existen muchas desventajas, las cuales de manera general podrían incrementar el
costo y tiempo planificado.
Alternativa 2: Implementar servidor local con sistema operativo basado en Linux (CentOS,
Ubuntu Server o Red Hat Enterprise), integrando una base de datos MySQL y herramienta de
administración phpMyAdmin.
La aplicación móvil, será escrita en lenguaje Java, para dispositivos con SO Android, siendo
necesario el software Android Studio, como plataforma para el desarrollo. La conexión entre la
app y el servidor será mediante un archivo php alojado dentro del mismo, el cual cumple la
función de recibir datos (mediciones) de la aplicación y almacenarlos en la BD, como también se
utilizará para validar el inicio de sesión.
La página web también se encontraría desarrollada con lenguaje de programación Java, los
softwares que se pueden utilizar para aquello, son NetBeans IDE o Eclipse IDE, en este caso a
diferencia de la app móvil, la conexión con la base de datos se realiza de forma directa.
El robot, estará basado en Raspberry Pi Zero W. Esta pequeña placa soporta Bluetooth 4 y WIFI
802.11n. Además, es posible instalarle un sistema operativo Linux, como Raspbian. Por último,
el accesorio se construirá con Raspberry Pi Pico y el módulo NRF24L01+ PA + LNA.
Las ventajas de esta alternativa son, lenguaje de programación nativo para Android (rapidez,
rendimiento y experiencia), privacidad y mayor seguridad al tener un servidor local, sitio web con
lenguaje Java, que permite crear casi cualquier tipo app y placa útil para la mayoría de los
proyectos.
Entre las desventajas tenemos, riesgos de disponibilidad de la información, costos por
mantención del servidor, mayor complejidad al haber un lenguaje nativo, baja documentación
sobre las placas Raspberry y tiempo de desarrollo más extenso.
Al igual que la alternativa anterior, la tecnología, cumple y logra satisfacer las necesidades que
tienen las personas para medir gases ambientales.
Alternativa 3: Crear una página web con HTML, PHP, CSS y JS, utilizando el software Visual
Studio Code o Sublime Text, con el objetivo de tener un sitio dinámico, ligero y rápido. Así mismo
las plataformas de trabajo para estos lenguajes son bastante amigables y consumen pocos
recursos del computador, lo cual es bastante bueno.
El servidor que se implementará será en la nube, con el proveedor BlueHosting. Este servicio
trae integrada las herramientas phpMyAdmin (MySQL) y phpPgAdmin (PostgreSQL), para
gestionar las respectivas bases de datos. Dentro del mismo se alojará la página web y archivos
php para la comunicación entre el servidor y la aplicación móvil.

16
La base de datos que se utilizará en la presente alternativa es MySQL, la cual va a ser
consumida por la app y sitio web, principalmente para hacer consultas, guardar las mediciones,
iniciar sesión, eliminar datos, etc.
Algunos de los componentes del robot serán, una placa Arduino Uno Rev3, sensores de gases
de la línea MQ, un Arduino Motor Shield (control de motores DC), Protoboard (placa de pruebas)
y módulo Bluetooth tradicional, que permite a múltiples dispositivos conectarse, ya que la versión
BLE, limita su uso.
El desarrollo de ToxiCase, estará centrado en la placa Arduino Nano. En esta se incluirá el
módulo HC-12, el cual tiene un alcance de 1800 metros o 1,8 km. Es una distancia menor a la
opción uno, sin embargo, es suficiente para realizar la tarea de medir gases, ya que un rango
superior, tampoco permite visualizar físicamente al robot.
Por último, se propone una aplicación móvil para Android 4.1 o superior. El desarrollo, será a
través de App Inventor, donde la programación es en bloque, siendo bastante sencillo y útil para
levantar apps de forma rápida.
Las ventajas de esta alternativa son, lenguaje PHP libre y abierto, entorno de desarrollo de fácil y
rápida configuración, gran compatibilidad y seguridad de la base de datos, alta documentación y
soporte de las placas Arduino Uno Rev3 y Arduino Nano, proveedor de servidor confiable,
levantamiento rápido de la app, tecnología fácil de utilizar y reducción de los costos generales.
Entre las desventajas tenemos, aplicación móvil compatible solo con Android, dependencia con
el servidor en la nube, al modificar la estructura de la base de datos MySQL pueden ocurrir fallos
y baja cantidad de herramientas de depuración PHP.
La tercera alternativa logra satisfacer las necesidades detectadas, obteniendo un producto de
rápida implementación sin sacrificar características.

Nombre Puntaje
Alta 3
Media 2
Baja 1

Característica Xamarin + BLE Java + Raspberry. PHP + Uno Rev3

Aplicación Móvil
Funcionamiento en IOS y Alta Baja Baja
Android.
Requiere poco espacio de Baja Baja Alta
almacenamiento.
Compatible con versiones Baja Media Alta
antiguas de Android (4.1
en adelante).
Levantamiento rápido de Media Baja Alta
la App.
Bajo consumo de Media Media Alta
recursos en dispositivo.
Flexibilidad para cambios Alta Alta Baja
específicos.
El desarrollo no implica Baja Baja Alta
grandes conocimientos.
Fácil conexión con la Media Media Alta
base de datos.
Entornos de desarrollo Baja Baja Alta
ligeros.
17
 Página Web
El lenguaje permite crear Alta Alta Alta
una web dinámica.
Fácil comunicación con la Media Media Alta
base de datos.
Compatibilidad con Media Media Alta
navegadores antiguos.
Bajos costos de Baja Baja Alta
implementación.
Conjunto de tecnologías Media Media Alta
web optimizadas.
Compatibilidad con Baja Media Alta
servidor Linux.
El software de desarrollo Baja Baja Alta
es ligero.
Sitio web con alta Baja Media Alta
portabilidad.
Robot (ToxiCar)
Robot liviano y Alta Media Media
transportable.
Placa con alta Baja Baja Alta
disponibilidad de stock.
Permite una conexión de Media Media Alta
Bluetooth sencilla.
Compatibilidad entre Media Media Alta
componentes.
Los costos de Media Baja Alta
construcción son bajos.
Alta documentación sobre Baja Baja Alta
la placa de desarrollo.
Entorno de trabajo Alta Media Alta
sencillo.
Hardware abierto y Alta Baja Alta
personalizable.
Servidor
Fácil intercambio de Media Alta Alta
datos entre la app y
servidor.
Disponibilidad de la Alta Media Alta
información garantizada.
No se requiere mantener Alta Baja Alta
el hardware del servidor.
Utilización eficiente de los Alta Baja Alta
recursos.
Alta compatibilidad con la Alta Media Alta
página web y app móvil.
Bajos costos de Media Baja Alta
implementación inicial.
Acceso al servidor desde Alta Baja Alta
cualquier ubicación.
Levantamiento rápido del Alta Baja Alta
servidor.
Accesorio (ToxiCase)
Alta disponibilidad de la Baja Media Alta
placa (stock).
Distancia de largo Alta Alta Alta
alcance (>1000m).
Fácil integración del Media Baja Alta

18
 dispositivo al ecosistema.
Placa compacta y de Alta Media Media
tamaño reducido.
Estabilidad de la Alta Baja Media
radiofrecuencia.
Alta documentación sobre Baja Media Alta
los recursos.
Precio accesible de los Baja Media Alta
componentes.
Fácil sustitución de los Alta Media Alta
materiales.
Resultados 85 68 116

7 Definición técnica de la solución

Según los resultados anteriores, la mejor alternativa que se adapta hacia el proyecto es la
tercera, principalmente porque logra satisfacer en un gran porcentaje la necesidad. Esto no
quiere decir que las otras opciones, no lo hagan más bien todas cumplen el mismo objetivo, sin
embargo, existen elementos que marcan la diferencia, por ejemplo, la alternativa 3 propone una
aplicación móvil que consume pocos recursos y espacio de almacenamiento, mientras que las
otras opciones, pueden superar los 150 MB. Así mismo el tiempo de desarrollo se ve reducido
considerablemente, ya que, al tratarse de una programación en bloque y visual, resulta mucho
más intuitivo y rápido para el equipo. Otro punto bastante importante, es que el servidor de la
alternativa 3, es en la nube, lo que permite una alta disponibilidad de la información, en
comparación a una infraestructura local, reduciendo también los costos de mantención.
Hay ciertas características, que se ven sacrificadas, por ejemplo, el peso del robot ya que no es
tan liviano como el Arduino Nano BLE o Raspberry Pi Zero, sin embargo, el stock de la placa se
encuentra relativamente asegurado en la alternativa 3, ya que existen muchos proveedores o
alternativas de compra.
Como se nombró anteriormente las características técnicas de la solución 3 son, base de datos
MySQL, página web con HTML, PHP, CSS y JS, servidor en la nube (BlueHosting),
programación en bloque para la aplicación, utilización de placa Arduino Uno Rev3, integración de
sensores de la línea MQ, Arduino Motor Shield (control de motores DC), Arduino Nano, antena
radiofrecuencia HC-12 y archivos PHP para la comunicación entre el servidor y la app móvil.
El conjunto de las tecnologías utilizadas para la alternativa se llama LAMP, que corresponde a la
“Combinación más común y popular en el área de desarrollo de páginas webs, por lo tanto, se ha
optimizado para un rendimiento mejorado extensivamente.” (Andrés, 2018), lo cual es bastante
bueno, ya que se obtiene un sistema altamente compatible entre sí.

8 Análisis y diseño del producto

8.1 Reglas del negocio del Cliente

- Cada Sprint Review debe ser planificada e informada con anterioridad (1 a 2 semanas).

19
- Las fechas de entrega no se modificarán, excepto si los cambios interrumpen o alargan el
trabajo.
- Durante el desarrollo, cualquier cambio debe ser solicitado a través del documento PCR.
- Toda modificación al Product Backlog, será evaluada por el equipo de trabajo.
- El incremento será sometido a un control de calidad, antes de su entrega.
- Los requerimientos deben ser validados por más de una técnica (entrevista, cuestionarios,
etc.).
- Cualquier persona jurídica o natural que esté interesado en el dispositivo, podrá adquirirlo.
- Todo cliente, se encontrará registrado en el sistema.
- Soporte técnico para los clientes, lunes a viernes de 8:00 AM a 18:00.
- Ningún dispositivo, requerirá una configuración especial por parte del cliente.
- Todos los clientes, podrán solicitar un robot personalizado (sensores, estructura, motores, etc.).
- Los productos que se comercializarán deben incluir el IVA.
- Cualquier cliente, podrá solicitar el aumento de espacio de almacenamiento.
- Las solicitudes de desarrollo y aumento de espacio, serán evaluadas dentro de 2 días hábiles.

8.2 Diseño de la Solución

8.2.1 Diagramas BPMN

Proceso de registro de usuario (App Móvil y Página Web).

Proceso de medición de gases (ToxiCar y Aplicación Móvil).

20
 Proceso de medición de gases (ToxiCar, ToxiCase y Aplicación Móvil).

Proceso para visualizar las mediciones almacenadas (Página Web).

8.2.2 Diagramación UML

21
8.2.2.1 Casos de uso

Usuario trabajador utilizando ToxiCar o ToxiCase para medir gases.

Usuario trabajador visualizando y exportando mediciones.

Usuario administrador consultando las mediciones de los trabajadores

22
8.2.2.2 Diagrama de secuencias

Usuario trabajador, aplicación móvil y ToxiCar.

23
Usuario trabajador, aplicación móvil, ToxiCar y ToxiCase.

24
Usuario trabajador y página web.

25
Usuario administrador y página web.

26
8.2.2.3 Diagrama de componentes

8.2.2.4 Diagrama de clases de diseño

27
9 Base de Datos

9.1 Arquitectura del almacenamiento

La arquitectura de 3 niveles es un “Estándar de diseño abstracto para un sistema de gestión de

bases de datos (SGBD – DBMS), fue propuesto por primera vez en el año de 1975 por la
empresa ANSI” (Arciniega, 2019). El objetivo de esta arquitectura es ocultar los detalles físicos
de almacenamiento a los usuarios.
El modelo se divide en tres vistas, interna (cómo están almacenados los datos), conceptual
(relación entre las entidades o tablas) y externa (vista de cómo el usuario ve los datos
almacenados).

28
9.2 Modelo Físico

Script del modelo físico.

9.3 Elección y justificación del SGBD seleccionado

Criterio SQL Server MySQL Oracle

Alta documentación de la base de datos 2 3 3
(comunidad, foros, sitios web, etc.).
Compatibilidad con la tecnología 1 3 2
utilizada (PHP y Linux).
Grado de popularidad del motor para 2 3 2
sistemas web.
Fácil configuración e instalación del 2 3 2
entorno.
Bajo consumo de recursos del equipo. 1 3 3
Posee licencia de código abierto y 1 3 1
software libre (GNU).
Base de datos con soporte exclusivo. 3 2 3
Ideal para proyectos pequeños y 2 3 2
medianos.
Bajos costos de instalación e 1 3 1

29
 implementación.
Seguridad de acceso (usuario, 3 2 3
contraseña, validación de perfil, etc.)
Tiempos de respuesta estables a medida 3 2 3
que aumenta el uso de la BD.
Alta capacidad para almacenar y 3 3 3
manejar diferentes tablas.
Diversidad de softwares para acceder y 1 3 2
controlar la base de datos.
BD multiusuario. 3 3 3
Baja complejidad de la sintaxis. 3 2 3
Permite generar Scripts de respaldos de 2 3 3
forma sencilla.
Mayor control sobre las mantenciones. 3 2 2
Herramientas complementarias para la 3 2 2
BD (respaldos, migraciones, etc.)
Posee diferentes versiones (empresas, 1 3 3
Express y comunidad).
Puntaje Total: 40 51 46

La elección de MySQL no fue solamente por el puntaje obtenido, sino que se trata del sistema de
gestión de base de datos que es altamente compatible con la tecnología que se utilizará para el
proyecto. La combinación de Linux, Apache, MySQL y PHP se denomina LAMP, donde los
recursos se encuentran optimizados para obtener el máximo rendimiento. Cabe señalar que
“SQL Server está destinado principalmente para desarrolladores que usan .NET como su
lenguaje de desarrollo, en oposición a PHP para MySQL.” (Deyimar, 2022), mientras que Oracle
Database es ideal para C, C++ y Java.
El servidor de la nube contratado nos provee una base de datos MySQL, con una capacidad de
almacenamiento ilimitada, esto no quiere decir que sea infinita, más bien se trata de no restringir
el consumo de recursos. De igual forma, si el umbral es superado, existe la posibilidad de migrar
toda la información a otro servidor. Es un proceso bastante sencillo, ya que el proveedor se
encarga de aquello.
Otro punto importante para nombrar es que el motor de base de datos MySQL, está orientado
principalmente para pequeñas y medianas empresas, a diferencia de SQL Server y Oracle, que
se utilizan en ambientes de alto rendimiento, donde la cantidad de registros es mucho mayor. Se
puede decir que los 3 motores ofrecen una velocidad relativamente similar. Según el estudio de
la revista IJARCCE, demuestro que existen diferencias en los tiempos de respuesta, basados en
las consultas SELECT, INSERT, DELETE y UPDATE, por ejemplo, al seleccionar los primeros
5.000 registros, a MySQL le tomo 0.0487 segundos, mientras que a SQL Server 0.0012seg. Para
las consultas de tipo INSERT, MySQL obtuvo mejores resultados, con una diferencia de
0.0006seg.
Los costos asociados a cada motor son distintos, por ejemplo, para implementar SQL Server, se
necesitan licencias y un servidor con sistema operativo Windows o Azure en caso de ser en la
nube. Por lo general toda la tecnología de Microsoft es mucho más cara. Con Oracle sucede lo
mismo, ya que, para acceder a la totalidad de sus características, se debe comprar una licencia,
su versión gratuita es limitada para las empresas, normalmente se utiliza la versión Express
solamente para probar la funcionabilidad. En cambio, MySQL, es gratis, dependiendo de su
versión y se implementa principalmente en servidores basados en Linux (gratuitos o de pago) y
se utiliza con PHP, el cual es mucho más económico de mantener, que C#, .NET o Java.

30
9.4 Tiempo de respuesta

Consulta Cantidad Usuario Media (ms) Mín. (ms) Máx. (ms) % Error
1 23 23 23 0,00%
500 2916 787 3699 0,00%
SELECT 1000 6705 2813 9503 0,50%
2000 12216 4956 24794 0,55%
3000 14335 1012 21053 30,20%
4000 18635 5995 25261 51,70%
1 49 49 49 0,00%
100 40 12 139 0,00%
INSERT 500 2806 583 3543 0,00%
1000 5681 4142 6815 0,00%
1500 7137 4022 13523 8,67%
2000 9506 3827 18695 4,20%
1 45 45 45 0,00%
100 17 11 42 0,00%
DELETE 400 2145 297 3141 0,00%
800 4178 2448 7651 0,00%
1200 6029 3533 8230 0,00%
1600 9207 5433 15130 10,31%

Usuario Consulta
200 select
1 1 insert
1 delete

Tiempos de respuesta de la base de datos.

La aplicación utilizada para medir los tiempos de respuesta fue JMeter, dicha herramienta “Nos
permite la realización de prueba de carga, con el fin de analizar y medir el comportamiento y
rendimiento de servicios, principalmente web.” (Rojas, 2021), es un software de código abierto
100% basado en Java. Además, permite probar aplicaciones FPT, conexiones TCP, procesos
nativos del sistema operativo y bases de datos.
Según los resultados obtenidos, podemos afirmar que el desempeño de la BD tiende a
descender a medida que aumenta la carga y trabajo. Para las pruebas de tipo SELECT, se
consideró que cada usuario tiene alrededor de 200 mediciones registradas, el principal objetivo
de esta fue determinar el tiempo que demora la base de datos en buscar los registros. Por
ejemplo, si 500 trabajadores consultan sus datos en el mismo instante, el tiempo medio de
espera es de 2916 milisegundo, con una mínima de 787ms y máxima de 3699ms. A partir de los
1000 usuarios, la base de datos no logra procesar exitosamente las solicitudes, marcando un
0,50% de error. Cabe señalar que dicho porcentaje puede variar dependiendo de la conexión a
internet, procesador del computador, estado actual del servidor de la nube, etc. Al aumentar la
cantidad de usuarios a 4000, prácticamente la mitad de ellos logra hacer la petición, ya que el
porcentaje de error incrementa al 50% aproximadamente.

31
Para las consultas de tipo INSERT, se tomó en cuenta el funcionamiento real del sistema, donde
un usuario puede almacenar solo una medición a la vez. De acuerdo a los resultados de esta
prueba podemos afirmar que el tiempo medio de espera para guardar un registro es de 49
milisegundos. En cambio, cuando ingresan 100 datos al mismo instante la media es de 40ms
(tiempo inferior que la prueba de 1 registro), pero la máxima aumenta a 139ms. De forma
general tanto la mínima como la media, incrementan a medida que crece el volumen de
peticiones. La máxima que se registro fue de 18695ms o 18,6 segundo al insertar 2000
mediciones a la vez. Dicho tiempo es demasiado extenso para cualquier tipo de usuario.
En las pruebas de tipo DELETE, al igual que para las de INSERT, se tomó en cuenta que cada
usuario puede eliminar solo una medición a la vez. El tiempo mínimo de espera que se obtuvo al
ejecutar 400 peticiones fue de 297 milisegundos y la máxima de 3141ms o 3,1 segundos. Se
puede apreciar en la tabla superior que los tiempos de 2000 INSERT y 1600 DELETE, son muy
similares, a pesar de la cantidad diferente de peticiones.
En resumen, se puede afirmar que los tiempos de espera, son bastante relativos, ya que
depende de la circunstancia actual del internet, computador, servidor, etc. De igual manera es
sumamente importante realizar dichas pruebas, ya que se puede obtener una visión general de
como rendirá la base de datos al someterse a una determinada cantidad de peticiones o
consultas. Un factor que debe considerarse es que el servidor actual de la nube es compartido,
por lo tanto, su rendimiento es limitado, ya que su capacidad se distribuye en una cierta cantidad
de usuarios. En caso de querer reducir los tiempos de respuesta, se puede alquilar un servidor
totalmente dedicado, sin embargo, los costos por este servicio son muchos más elevados en
comparación a uno compartido.
Por otra parte, encontramos los tiempos de respuesta de ToxiCar y ToxiCase, según la distancia:

Para medir los tiempos de respuesta de los dispositivos, se integró un cronometro en la

aplicación móvil y se utilizó la función millis() de Arduino. Las primeras pruebas están enfocadas
en determinar los milisegundos que demora el robot en recibir y ejecutar una acción enviada por
Bluetooth. En base a los resultados, se puede afirmar que a medida que aumenta la distancia
entre el robot y smartphone, los tiempos de respuesta tienden a incrementar. Por lo general
realizar una medición demora mucho más tiempo que controlar al robot (adelante, atrás, etc.),
esto es porque el dispositivo no solo tiene que recibir datos, sino que también debe ejecutar
código para calcular los niveles de gases y enviarlos por Bluetooth. Cabe decir que, a partir de
los 8 metros, el robot no logra ejecutar todas sus funciones, ya que, alcanza su límite de
distancia y control.
También se desarrollaron pruebas para ToxiCase, básicamente con los mismos criterios que la
anterior. Por lo general los tiempos de respuesta no aumentan significativamente en
comparación a la conexión directa por Bluetooth. La transmisión de datos es bastante estable
llegando como máximo a los 451 milisegundos de espera. Esto tiene aún más valor, ya que se

32
tiene que considerar que el nivel de complejidad para el envío y recepción de datos es mucho
mayor.
De igual forma la opción que elija el trabajador para realizar mediciones (conexión directa o por
ToxiCase), no tendrá problemas con los tiempos de respuesta, ya que, en ambos casos, son
bastante bajos, de hecho, es muy difícil apreciarlos.

9.5 Estimación de tamaño de base de datos

En la base de datos, existen tablas que su número de registros no aumentará con el uso del
software, entre ellas encontramos “COMUNA”, “PREGUNTA”, “TIPO_USUARIO” y “TIPO_GAS”,
esto se debe a que contienen datos predefinidos, los cuales no cambiarán al menos en los
próximos meses, por ejemplo, la tabla “COMUNA”, tendrá 346 registro, ya que actualmente en
Chile solo existe dicha cantidad. La probabilidad de que aparezcan nuevas comunas es muy
baja, ya que, su proceso de formación es bastante complejo y requiere de muchos factores
legales. El tamaño de la tabla “TIPO_GAS”, es relativo, ya que solo ingresarán datos de los
nuevos sensores, por ejemplo, si un cliente solicita un robot personalizado para detectar un gas
no probado anteriormente (amoniaco, benceno y sulfuro) este se tendrá que agregar a la base
de datos. De igual forma no se puede contabilizar un registro mensual ni semestral por lo relativo
que es. Se estimo de forma general que existirán alrededor de 12 tipos de gases.
En cambio, la tabla llamada “USUARIO” aumentará de tamaño a medida que hallan nuevos
clientes, ya que para acceder y hacer uso del sistema (aplicación móvil y página web) es
necesario tener una cuenta registrada. Esta es la primera instancia donde las personas
interactuarán con la base de datos. La tabla “MEDICIÓN”, es y será la que tendrá mayor número
de datos, ya que un solo usuario podría realizar muchas mediciones al día.
Una ventaja de ToxiCar es que maneja solamente datos de tipo varchar, int y datetime, esto
hace que la BD tenga un crecimiento progresivo relativamente bajo, por ejemplo, el campo
“LOCALIZACIÓN” de la tabla usuario, pesa como máximo 101 bytes (100 caracteres + 1 byte).
En cambio, si ToxiCar manejara imágenes, multimedia o PDF, un solo campo, podría pesar
varios megas, ya que un video de 2 minutos a 1080p, consume 200 MB aproximadamente. Los
tipos de datos mediumblod y longblod de MySQL, permiten almacenar desde 16MB a 4GB. Para
que el tamaño total de la BD pese lo equivalente a un solo campo de 16 MB, tendría que haber
el doble de registros en un semestre.

33
En resumen, se estima que en un mes la base de datos pesará alrededor de 1487,98 KB o 1,5
MB, en un trimestre 4,1 MB y al semestre 7,9 MB.

9.6 Mecanismos de seguridad

La seguridad de la base de datos se encuentra regulada por la aplicación móvil y página web.
Las consultas de tipo SELECT, INSERT, DELETE y MODIFY, dependen del tipo de usuario que
ingresa al sistema (trabajador o administrador.), cada uno de ellos tiene su propia ventana y
entorno. En el código es donde se encuentran las principales diferencias, por ejemplo, la página
inicial del administrador tiene una consulta de tipo SELECT, la cual retorna el listado de todas las
mediciones de los usuarios, mientras que, en la interfaz del trabajador, se llama a un
procedimiento almacenado que tiene como parámetro de ingreso el RUT. Existen consultas que
ambos usuarios podrán hacer a la base de datos, algunas de ellas son, buscar y modificar sus
datos personales, listar los nombres de las comunas y cambiar su clave. Las ventanas para
estas consultas son las mismas, solo cambia el valor que ingresa como parámetro a la
sentencia.
Cabe señalar que los procedimientos almacenados son “Funciones programables que se crean y
guardan en la base de datos y pueden estar compuestas de sentencias SQL y estructuras de
control.” (Programador Click, 2019). Dichos procedimientos evitan el acceso directo a las tablas y
ayudan a establecer un entorno seguro. Se creo una serie de estos, para controlar las consultas,
ingreso y retorno de datos. Los procedimientos se encuentran en el backend de cada interfaz de
usuario (trabajador y administrador). Por ejemplo, para eliminar una medición, se implementó un
procedimiento que ejecuta la sentencia DELETE.
Además de los procedimientos, también se crearon vistas de usuario con el objetivo de
simplificar y personalizar la muestra de datos. Esta función es bastante útil, sobre todo si existen
tablas relacionadas con llaves foráneas. En la página del administrador se utiliza una vista para
mostrar el listado de mediciones y usuarios registrados en el sistema.
Las principales ventajas de implementar vistas son, mayor rendimiento, control de accesos,
pruebas seguras e integridad de los datos.
A continuación, se muestra el listado de los procedimientos almacenados y vistas de usuario que
se diseñaron:

34
9.7 Monitorización y afinamiento

Actualmente la base de datos dispone de 6 tablas, una de ellas se llama “MEDICIÓN”. Esta
almacenará un mayor número de datos a diferencia de otras (COMUNA, PREGUNTA,
TIPO_USUARIO, etc.). La segunda tabla importante corresponde a la del “USUARIO”, la cual
es la base del sistema. Principalmente la liberación de espacio debe enfocarse en estas dos
tablas. Sin embargo, cada eliminación de dato debe ser controlada, ya que, la falta de un valor
puede afectar a otra tabla.
Actividades para liberar espacio de la base de datos:

La periodicidad de cada actividad fue definida por su grado de importancia o relevancia, por
ejemplo, el control de la tabla “PREGUNTAS”, no impacta significativamente al sistema, ya que
la cantidad de datos que maneja dicha tabla es bastante baja, cada registro pesa alrededor de
0,08KB, se estima que habrá un total de 10 filas (0,8 KB). Esta cantidad es muy pequeña en
comparación a la capacidad que tiene el servidor de la nube. En cambio, la tabla mediciones si
puede provocar un impacto al sistema, ya que un solo usuario podría guardar varios registros en
un solo día, por lo tanto, para no acumular grandes cantidades de datos, se eliminarán las

35
mediciones de tres años de antigüedad. De igual forma se enviarán los respaldos
correspondientes al trabajador.
Por lo general las acciones definidas para liberar espacio, pueden ser ejecutadas fácilmente
desde el software MySQL Workbench o directamente en phpMyAdmin, el cual se encuentra
integrado e instalado en el servidor (BlueHosting). Cabe señalar que la actividad “eliminar
usuario”, también puede ser realizada a través de la página web del administrador, como
también el “eliminar mediciones”.
El proyecto ToxiCar se centra en desarrollar un dispositivo para venderlo a personas o
empresas, toda la parte del servidor, almacenamiento, código, scripts e infraestructura es y será
manejada siempre por ToxiCar. El administrador de la base de datos es parte del equipo de
trabajo del proyecto. A medida que aumente el tamaño de la BD, este rol podría ser compartido
por algún otro trabajador.
Para controlar el uso de la BD, se diseñó el siguiente plan:

El presente plan aplica una vez implementado el sistema ToxiCar, sin embargo, muchas de las
actividades, ya fueron ejecutadas durante el desarrollo, por ejemplo, la optimización de consultas
SQL, limitar los privilegios de los usuarios y mejorar los scripts internos del software. En cambio,
el monitoreo no ha tenido mayor presencia durante el desarrollo, excepto en las pruebas, donde
resultar indispensable visualizar el comportamiento de la base de datos al realizar consultas
SQL.
Al igual que el plan anterior, el administrador de ToxiCar, será el encargado de realizar las
actividades. Cabe señalar que es posible que alguna de las tareas no necesite ser ejecutada
nuevamente, o por lo menos durante un tiempo, por ejemplo, si los privilegios de usuario se
encuentran completamente ajustados y el sistema funciona bien, no es necesario hacer ningún
cambio. Por lo general esto aplica a todas las actividades, excepto al monitoreo diario de la base
de datos, ya que, cuando el sistema se implemente, los usuarios almacenarán un gran número
de mediciones. Dicho control tendrá como objetivo verificar el estado y el rendimiento que va
teniendo la BD a medida que aumenta la carga y uso por parte de los usuarios.
En resumen, las principales herramientas que se utilizarán para liberar espacio, mantener y
controlar la base de datos serán las siguientes:

Software Características

36
 Con este software, se crearán los
procedimientos almacenados y vistas de
phpMyAdmin (integrado en el servidor) usuario. También servirá para ejecutar
comandos SQL para liberar espacio de la base
de datos. (eliminar usuarios, mediciones,
preguntas, etc.).
El administrador utilizará MySQL Workbench,
principalmente para monitorear el estado y
MySQL Workbench (software de escritorio) rendimiento de la base de datos, ya que la
función “Performance”, genera un dashboard
resumido del estado del sistema. Este software
ofrece más funciones que phpMyAdmin.
La aplicación RemoDB, es una alternativa para
dispositivos móviles (Android e IOS). Dicha app
RemoDB (versión móvil) permite acceder y ejecutar funciones básicas en
la BD. El administrador de ToxiCar utilizará esta
versión en caso de no disponer de un
computador en el lugar donde se encuentre.

10 Factibilidades

10.1 Factibilidad Técnica

El equipo de trabajo necesita disponer de al menos 3 computadores. Cada uno de ellos, debe
tener como mínimo un procesador Intel i5, 256GB de almacenamiento, 8GB de RAM y sistema
operativo Windows 10 (64-bits). Por lo general los softwares que se utilizarán para la creación
del sistema (Robot, Accesorio, Aplicación Móvil y Página Web), consumen pocos recursos del
equipo, por ejemplo, Visual Studio Code, para funcionar de manera adecuada, requiere un
procesador de 1.6 GHz de velocidad y 1 GB de memoria RAM, mientras que el software Arduino
IDE para programar el robot y accesorio, solo exige Windows 10 versión 14393.0 o posterior,
siendo ambos instalables en la mayoría de los computadores. También se requerirá de un
smartphone para probar la futura aplicación móvil, este dispositivo debe tener Android 4.1 como
mínimo, 2GB de RAM, Bluetooth, GPS, Internet móvil y 50MB de espacio libre.
El desarrollo de la página web, será a través del software Visual Studio Code versión 1.66.2 o
superior, el cual puede descargarse de manera totalmente gratuita a través del sitio web de
Microsoft. Otra alternativa es Sublime Text, sin embargo, se debe adquirir una licencia para
utilizar todas sus características. Dentro de este software, se escribirá la página web en HTML,
PHP, CSS y JS.
El motor de base de datos que se utilizará es MySQL, para trabajar con el de manera sencilla, se
instalará XAMPP en un computador local hasta que el servidor de la nube se encuentre
operativo. Este software también permitirá alojar y probar la página escrita en PHP.
También se necesita un servidor en la nube, como se mencionó a comienzos del informe, será
con el proveedor BlueHosting, el cual garantiza una alta disponibilidad. Este servidor se
encuentra basado en Linux y permite alojar sitios web desarrolladas en PHP e integrar bases de
datos MySQL. Junto a esto, se comprará el dominio www.toxicar.cl, para la respectiva página.
Tener acceso a Internet es indispensable, ya que el equipo de trabajo necesitará de el para
buscar documentación sobre la tecnología a desarrollar (códigos, diagramas, librerías, etc.).
37
Además, se utilizará para crear la aplicación móvil de ToxiCar, dado que la codificación es en
línea, a través de App Inventor 2, el cual “Es un entorno de desarrollo de software creado por
Google para la elaboración de aplicaciones destinadas al sistema operativo de Android.”
(Abellán, 2019). Una ventaja de esta plataforma es que permite programar en bloque, haciendo
que el proceso de construcción sea mucho más rápido. Lo ideal es tener una velocidad de
Internet de 50 MB de bajada y 20 de subida, para trabajar sin retrasos. El Internet, también es
necesario para las futuras mantenciones o modificaciones de los sistemas implementados, ya
que para acceder a estos (servidor en la nube y App Inventor) se requiere una conexión de red.
Para construir el robot, los principales componentes que se necesitan son, un chasis de dos
orugas, un motor Shield marca Arduino para controlar los motores DC, una Protoboard o Perma
Proto (placa de pruebas), tres sensores de gases (MQ2, MQ3 y MQ135), un módulo Bluetooth
Grove Dual Model o el estándar HC-06, antena HC-12 (conexión radiofrecuencia), treinta
Jumpers aproximadamente para cablear el dispositivo, dos baterías NI-MH 9.6V y por último se
requiere una placa de desarrollo Arduino Uno Rev3. Por lo general estos materiales se
encuentran en cualquier tienda de electrónica y robótica, resulta fácil comprarlos e importarlos en
caso de no haber stock dentro del país. Inclusive es posible sustituir gran parte de estos
componentes por versiones alternativas u otras marcas, por ejemplo, si no se encuentra la placa
central Arduino Uno, se puede remplazar por la DFRobot Uno R3 o por Adafruit Metro Uno, que
básicamente cumplen la misma función. Por otra parte, los materiales que se necesitan para
desarrollar ToxiCase, son Arduino Nano, Antena HC-12, Jumpers, Mini Protoboard de 25 puntos,
un módulo Bluetooth y una batería de 9V. Dichos recursos son igual de accesibles que los del
robot, ya que el desarrollo está basado en Arduino, lo que significa que significa una alta
disponibilidad de los componentes.
En resumen, los softwares para crear los sistemas (Arduino IDE y Visual Studio Code),
consumen pocos recursos de un equipo y la gran mayoría de estos puede ser instalado.
Actualmente se cuenta con los computadores y aplicaciones para el desarrollo.
Dentro del mercado encontramos diversas alternativas de componentes para el robot (placas,
sensores, módulos, etc.), muchos de estos pueden ser remplazados sin afectar el
funcionamiento del dispositivo. Es una gran ventaja, ya que, si una pieza es descontinuada o se
encuentra escasa, se puede sustituir fácilmente. Cabe señalar que se dispone de todos los
materiales para construir el robot y accesorio, de acuerdo a la propuesta de solución
seleccionada (Arduino Uno Rev3, sensores MQ2, MQ3 y MQ135, Jumpers, módulo Bluetooth,
Arduino Motor Shield, antena HC-12, etc.).
La página web y base de datos, se alojarán en un servidor de la nube, el cual se encuentra
adquirido y activo. Las características de este son, espacio de almacenamiento ilimitado, soporte
PHP y MySQL, herramienta de gestión phpMyAdmin y certificado SSL gratuito para el dominio.
El conjunto de recursos que se posee para desarrollar la aplicación móvil, robot y página web
logran satisfacer a la solución. Por el momento no es necesario adquirir ningún componente,
equipo, software o servicio adicional, como tampoco modificar la tecnología a utilizar, ya que
existe una alta compatibilidad entre ellas (lenguajes, motores de BD, etc.).

10.2 Factibilidad Implementativa

Al implementar ToxiCar las empresas podrán reducir sus costos considerablemente, ya que solo
necesitarán de un dispositivo para medir múltiples gases, a diferencia de los tester existentes,
que son limitados y no personalizables.
38
Un elemento que diferencia a ToxiCar de los medidores es que el robot, les ofrecerá mayor
seguridad a los trabajadores que realizan mediciones de gases, ya que, dicho anteriormente,
habrá una distancia más segura entre la incidencia y la persona, lo que significa menor
probabilidad de riesgo de accidentes. Sobre todo, si utilizan el dispositivo “ToxiCase”, ya que
este, tiene un alcance de 1200 metros.
El ecosistema de ToxiCar instalado debiese operar de forma estable y sin grandes
inconvenientes, por ejemplo, como el servidor se encuentra en la nube, la probabilidad de
intermitencia, caídas o cortes es inferior a la de un servidor local, ya que el proveedor se encarga
de contar con recursos físicos, para prevenir dichos problemas. La disponibilidad puede variar de
acuerdo el servicio contratado, en este caso se escogió un proveedor confiable y conocido, por
lo cual el riesgo de inestabilidad es inferior. Cabe señalar que el servicio en la nube soporta una
gran cantidad de peticiones de lectura y escritura por segundo, ya que su capacidad puede
adaptarse según la necesidad, significando una garantía para el usuario, básicamente porque el
problema no se presentaría. Si los umbrales son superados, el costo del servicio aumentaría, sin
embargo, el beneficio es mayor y necesario.
La aplicación móvil, es compatible con smartphones que poseen Android 4.1 o superior,
permitiendo a muchos dispositivos utilizarla sin problemas, considerando también que dicha
versión es bastante antigua, ya que actualmente existe Android 12. La app, necesita que el
móvil, tenga un espacio libre de 15 MB, lo cual es bastante bajo, inclusive para dispositivos de
años anteriores. El Bluetooth independiente a la versión es necesario para el funcionamiento del
sistema, ya que la conexión con el robot se realiza a través de este medio, sin embargo, no es
ningún problema, porque todos los smartphones lo traen integrado.
En cuanto a la página web, solo se necesita de un dispositivo con navegador y conexión a
internet para acceder.
Existen variables externas que podrían afectar el funcionamiento del robot, tal como la caída de
la red, básicamente porque la aplicación móvil requiere de Internet para iniciar sesión y guardar
las mediciones en el servidor, sin esto no se podrían generar reportes y visualizar los registros a
través de la página web, lo que se limitaría su funcionamiento.
Dicho lo anterior, es posible afirma que el ecosistema de ToxiCar tiene una alta compatibilidad,
podrá operar de forma estable, la capacidad del servidor se adapta de acuerdo al uso, y la
información estará disponible en todo momento para los usuarios.
Para las personas no será difícil utilizar el robot, más bien se trata de un “auto a control remoto”
conectado a una aplicación móvil, tampoco se requiere de ningún curso especial o capacitación,
ya que la propia página web les proporciona un instructivo de uso.
El cambio más sustancial entre un dispositivo tester actual y el robot ToxiCar, corresponde a la
forma en que se realizarán las mediciones, ya que pasa a ser un dispositivo de mano, a un
producto inalámbrico con movilidad, capaz de detectar múltiples gases en el ambiente, sin la
necesidad que el trabajador se encuentre en el mismo lugar.
Cuando una persona adquiere un nuevo producto, independe a su tipo, requiere de tiempo para
adaptarse, por ejemplo, un sistema operativo, puede tener la misma base que la versión anterior,
pero lo más probable es que las aplicaciones, funciones y diseño no sean iguales, lo que
conlleva a investigar, probar y experimentar por parte del usuario para utilizarlas. En el caso del
proyecto ToxiCar, es un cambio radical, pero a su vez resulta más sencillo, ya que tanto la
plataforma web como móvil están pensadas para que el usuario con la menor cantidad de clicks
posible, pueda realizar determinada acción, específicamente con 3 toques en la app para medir
un gas, considerando los botones de iniciar sesión, conexión con el robot y selección de químico.

39
En cuanto al sitio web, solo se necesita que la persona ingrese con su rut y contraseña, ya que
las mediciones almacenadas, aparecerán inmediatamente en la página principal, lo cual es
bastante simple.
Es importante nombrar que, “La robótica ha avanzado exponencialmente en Chile en diversas
áreas productivas, como minería, salud, retail e incluso para definir los estados anímicos de una
persona.” (Fasola, 2021), por ejemplo, los brazos robóticos industriales, permiten realizar tareas
de paletizado, envoltura, etc. Esto nos indica que dicha tecnología ya se encuentra en nuestro
presente y seguirá creciendo con el objetivo de automatizar cada vez más procesos.
Se puede decir que el producto de ToxiCar corresponde al resultado de un dispositivo tester
integrado en un robot, el cual se encontrará en un ecosistema que permite almacenar y transferir
datos (mediciones) de manera inalámbrica, a través de internet.
Invertir en tecnología no solo es necesario para automatizar procesos, sino que también se gana
mayor competitividad dentro del mercado, al aumentar la productividad, reducir los costos y
mejorar la atención al cliente. El proyecto, como se dijo anteriormente incrementará la seguridad
de los trabajadores, automatizará el proceso de detección de gases y reducirá los costos
generales de inversión, ya que el dispositivo es personalizable y puede realizar las funciones de
uno o más testers.
Al tratarse de un producto nuevo y totalmente diferente, existe la posibilidad que una parte de las
personas o empresas objetivo no desee invertir en el robot de ToxiCar, sobre todo al tratarse de
un cambio de tecnología significativo, sin embargo, también hay organizaciones, que, si deseen
obtener un producto con altas características, para hacer más sencillo los trabajos de medición.
Algunos de los elementos más relevantes que nos indican que el sistema será utilizado, son, la
fácil operación del producto, no se requieren cursos o capacitaciones especiales, app y página
web intuitivas, precio del dispositivo acorde a sus características y el alto crecimiento de la
robótica en las empresas, tal como en la minería.

11 Ciclo de vida y metodología de desarrollo

11.1 Metodología ágil

RUP y Scrum

Metodología Ágil RUP

Ventajas Desventajas
- Con la metodología ágil RUP, sería más fácil - Para el proyecto ToxiCar, nosotros
asignar roles, ya que dicho modelo tiene una queremos utilizar una metodología fácil y
forma muy disciplinada y ordenada en la sencilla, la cual todo el equipo de trabajo
definición de las tareas, lo que ayuda pueda comprenderla.
bastante a la hora de escoger el personal, El modelo RUP en muchos aspectos es
reduciendo el riesgo de una mala asignación bastante complejo, tiende a ser muy extenso
de estos. y pesado.
- Detectar las fallas a tiempo es muy - Para utilizar la metodología RUP, es
importante en nuestro proyecto, ya que está necesario que el personal tenga experiencia
en juego la calidad del producto. RUP, nos sobre el tema, debido al grado de complejidad
permite encontrar los problemas de forma que tiene.
40
bastante temprana, antes de la integración Implementarla nos significaría una inversión
final del sistema. Esto se debe a las extra de tiempo y dinero, ya que se tendrían
iteraciones que tiene la metodología ágil. que hacer capacitaciones para que el
- Como se dijo anteriormente la participación personal tenga las competencias y
de los usuarios en el proyecto es fundamente habilidades requeridas por el modelo.
para nosotros, ya que, con el feedback - En el proyecto, lo ideal es disminuir los
continuo, podemos mejorar el software. RUP costos lo máximos posible. Si se
permite la participación del usuario, debido a implementará la metodología RUP, los
que al finalizar cada iteración se libera un montos podrían subir, ya que se necesitan
ejecutable, el cual puede ser inspeccionado y herramientas especiales para trabajar con la
evaluado por el cliente. metodología, las cuales son vendidas y
- Nuestro proyecto ToxiCar, probablemente proporcionadas por IBM.
tenga muchas modificaciones durante el - RUP, se relaciona constantemente con
tiempo de desarrollo, ya sea por necesidad, modelos UML, principalmente con casos de
nueva tecnología o cambios de uso. Si nuestro personal no logra capturar a
requerimientos. Con la metodología RUP, se tiempo uno de ellos, puede causar una
puede gestionar de mejor forma los cambios, reconstrucción parcial de la arquitectura. En
ya que describe como controlar, rastrear y dicho modelo, los casos de uso no son
monitoréalos, consiguiendo un desarrollo solamente una herramienta para especificar
iterativo más exitoso. los requerimientos, sino que también guían el
- En el proyecto, es fundamental que el diseño, implementación y pruebas. Por lo cual
producto desarrollado cumpla con todas las al omitir o desarrollar un modelo con errores
características previstas desde su comienzo. puede provocar problemas a futuro en el
Utilizar la metodología RUP, garantiza de sistema, lo cual es bastante riesgoso.
alguna forma que el software final será de - Para nosotros es importante prevenir y
calidad, cumpliendo con las necesidades de controlar eventos que pudiesen afectar al
los usuarios de acuerdo al presupuesto y proyecto. Con RUP, esto generaría un trabajo
planificación. adicional, ya que la metodología no cubre la
gestión de personal, presupuestos y
contratos.
Metodología Ágil Scrum
Ventajas Desventajas
- Al implementar Scrum, se obtendría el - Trabajar con la metodología Scrum, requiere
máximo valor del producto en el menor tiempo de un equipo de trabajo calificado y
posible, permitiendo lanzar el software de la conocedor de los fundamentos y marco
forma más rápida. En pocas palabras la teórico del modelo. Siendo también necesario
metodología Scrum, nos guía para crear un conocer los roles de la metodología para
producto bueno en el menor tiempo y costo evitar una dispersión y choque de funciones.
posible. Si se llegará a implementar el presente
- Un punto bastante importante para nosotros, modelo se tendrá que evaluar al personal.
es la retroalimentación por parte de los - El éxito del proyecto ToxiCar dependerá en
clientes. El modelo Scrum propone gran parte de la preparación y experiencia
presentaciones al finalizar cada Sprint, con el que tenga nuestro Scrum Master, ya que es el
objetivo de que el cliente, opine y dé a encargado de guiar al equipo para que este
conocer sus nuevas necesidades. Lo cual es se mantenga enfocado en los objetivos
bastante bueno para ToxiCar, ya que el éxito previstos. Además de lo anterior el Scrum
del proyecto también depende del feedback Master debe asegurar que todo el equipo,
del cliente. comprenda y aplique correctamente la
- La metodología Scrum fomenta el metodología, para entregar el máximo valor al
autoaprendizaje en los miembros del cliente. Por lo tanto, la persona asignada a
proyecto, de una forma bastante rápida, ya este cargo tiene que cumplir con las
que el hecho de haber iteraciones que se exigencias del modelo, de lo contrario no se
completan en un breve tiempo permite que el tendrán buenos resultados.
equipo de trabajo obtenga un aprendizaje, el - En el caso de estar utilizando la metodología
41
cual puede ser utilizado en los próximos Scrum y una persona del equipo de trabajo
Sprint del proyecto. Siendo cada iteración renuncia, podría ser bastante difícil remplazar
mejor que la anterior. aquel rol, ya que se llevaría con él, todos los
- Al implementar el modelo Scrum en ToxiCar, conocimientos específicos del proyecto, esto
sería más fácil estimar y dimensionar el incluye el robot, la aplicación móvil y página
proyecto, ya que, mediante las iteraciones o web. Lo cual sería bastante negativo para
Sprint, se puede segmentar el proyecto en nosotros, ya que habría que invertir tiempo y
bloques pequeños, mucho más gestionables, dinero para poner al día a la nueva persona,
que, si tratáramos de abarcar el proyecto evaluar si está capacitada para la
ToxiCar, de principio a fin, como lo que podría metodología, etc.
ser la metodología Cascada, ya que no - Es bueno para nosotros que la metodología
considera iteraciones para desglosar el Scrum permite hacer reuniones para revisar
proyecto, sino que fases completas. los avances, dificultades y evaluar al equipo.
- Como se dijo anteriormente existe una alta Sin embargo, podrían ser demasiadas las
probabilidad de que haya modificaciones o reuniones para los pocos avances iniciales,
cambios de requerimientos durante el resultando bastante cansador y agotador
proyecto. Lo que para Scrum no es un reunirse tantas veces por el mismo tema.
problema, ya que cualquier cambio se Principalmente por las juntas diarias (Scrum
gestiona de manera bastante sencilla, Daily Meeting). Lo que podría provocar que
introduciendo el nuevo ítem en el Product algunos de los miembros del equipo vayan
Backlog, para ser ejecutado o desarrollado en perdiendo el interés.
la siguiente iteración de acuerdo a su
prioridad.

Comparativa entre metodologías

Criterio Cascada RUP Scrum

Alta presencia en el mercado. 2 5 7
Considera todos los riesgos. 4 6 7
Contempla desarrollo de software iterativo. 1 7 7
Documentación mínima necesaria. 3 4 7
Adaptable a los cambios. 2 7 7
El éxito del proyecto depende de la
4 7 7
satisfacción del cliente.
Tiempos limitados de entrega. 6 4 4
Alta participación del cliente en el proyecto. 2 6 7
Estructura sencilla y fácil de comprender. 7 2 5
La metodología no necesita un personal de
6 1 3
trabajo especializado.
Se obtiene el máximo valor del producto en
1 6 7
el menor tiempo posible.
Permite gestionar el proyecto más 2 4 7
fácilmente.
Fomenta el autoaprendizaje del equipo. 1 5 6
Entregas tempranas y continuas. 1 7 7
Optimización de los recursos y resultados. 4 7 7
Pruebas de software tempranas. 2 7 7
Mayor probabilidad de asignar correctamente
3 7 5
los roles.
Los resultados del proyecto son más
6 4 4
predecibles.
Puntaje Total 57 96 111

42
La metodología seleccionada para el proyecto ToxiCar es Scrum, no solamente por el puntaje
conseguido, sino que también por las grandes ventajas que tiene, por ejemplo, permite obtener
el máximo valor del producto en el menor tiempo posible, facilita dimensionar el proyecto a
través de iteraciones e incluye al cliente dentro de todo el proceso de desarrollo, lo que es
bastante importante, ya que, según las retroalimentaciones de este, se irá mejorando el
software. Un factor relevante de Scrum es que existe mucha documentación sobre dicho modelo,
libros, documentos, páginas, blogs, etc., ya que se trata de la metodología ágil más utilizada y
efectiva en la actualidad para el desarrollo de software, según lo publicado en
www.zoraidaceballosdemariño.info. Desde el inicio del proyecto, se consideró implementar un
modelo ágil en vez de uno tradicional, como lo es Cascada, dado que en la actualidad las
necesidades de las personas cambian demasiado rápido, lo que hace imprescindible ir
agregándolas en el proyecto, con más razón si se trata de un producto tecnológico, tal como el
robot, página web y aplicación móvil de ToxiCar. Scrum logra gestionar bastante bien los
cambios de requerimientos, ya que, solo basta con negociar con el cliente para llegar a un
acuerdo y agregar las modificaciones o nuevas necesidades al Product Backlog, para ser
desarrollador en las siguientes iteraciones, de acuerdo a su prioridad. Otro factor que influyo en
la selección de la metodología fue por los conocimientos y experiencia que tenemos utilizándola.
En resumen, la metodología Scrum es la mejor alternativa para nuestro proyecto llamado
ToxiCar, ya que es flexible, adaptable, posee entregas continuas, el desarrollo del producto es
rápido y tiene una alta participación del cliente. Además, Scrum, obtiene los mejores resultados,
ya que gana con 111 pts. en la “Evaluación de metodologías según criterios” lo que confirma aún
más su elección.

11.2 Ciclo de vida

El ciclo de vida de un proyecto se define por las distintas fases que recorre el proyecto desde el
momento en que se pone en marcha hasta que éste se da por finalizado. En este caso se
utilizará el ciclo de vida incremental, también conocido como adaptativo, este modelo busca
alcanzar un crecimiento progresivo de las funcionalidades del software. El procedimiento
consiste en estructurar las fases en procesos cíclicos, para al terminar, hacer la entrega del
incremento del producto.
Las fases del ciclo de vida incremental son:
- Requerimientos: definición de los objetivos específicos y centrales que persiguen al proyecto.
- Definición de las tareas e iteraciones: se listan todas las tareas y se agrupan en iteraciones.
Cada una de estas persigue objetivos específicos.
- Diseño de los incrementos: determinar la evolución que tendrá el producto en cada una de
las iteraciones.
- Desarrollo del incremento: se realizan las tareas previstas y se desarrollan los incrementos
establecidos anteriormente.
- Validación del incremento: al terminar la iteración, los encargados de la gestión del proyecto
deben validar y comprobar el incremento. Si los resultados no son los esperados es posible
volver hacía atrás.
- Integración de incrementos: se trata de integrar todos los incrementos validados o aprobados
de la etapa anterior, dando una evolución global al proyecto.

43
- Entrega del producto: una vez realizada la integración y validación del producto en relación a
los objetivos iniciales, se procede a su entrega.
Comparativa entre el ciclo de vida incremental y cascada.

Incremental
El modelo incremental o también conocido como adaptativo se utiliza con metodologías ágiles
como Kanban y Scrum, este modelo busca alcanzar un crecimiento progresivo de las
funcionalidades del producto final, esto quiere decir que en cada iteración (período de
desarrollo) se entrega una parte del producto final funcional, por lo que en cada ciclo siguiente
se van agregando más funciones para lograr el desarrollo completo, las fases por cada ciclo
son “Análisis”, “Diseño”, “Código” y “Pruebas”.
Ventajas Desventajas
- Se adapta rápidamente a los cambios, el - Se puede ir perdiendo la calidad de las
costo por algún cambio de requerimiento entregas que se han realizado anteriormente
puede ser menor que en un modelo más dado que el equipo se puede enfocar
rígido. demasiado en el desarrollo de las
- Satisfacción al cliente, dado que está funcionalidades posteriores, dejando de lado
presente durante todo el proyecto, en las las entregadas.
primeras etapas de cada iteración él dice lo - Se requiere mucha experiencia para llevar a
que necesita para luego el equipo cabo este modelo debido a que se deben
desarrollarlo y entregárselo al cliente al definir bien los requerimientos para que
finalizar la iteración. cuando termine una iteración el producto
- Los resultados del producto se van tenga un valor para el cliente, de igual forma
obteniendo rápidamente, con lo que se puede las tareas que se desarrollan se deben
apreciar si el rumbo de la fase es el correcto o repartir equitativamente para todo el equipo
no, de no serlo se puede llegar a una solución ya que si un trabajador tiene mucho trabajo
antes de la entrega. otro podría quedar sin hacer nada.
- Es más fácil gestionar los riesgos y como
solucionarlos si se presentaran.
Cascada
Cascada es un proceso de desarrollo secuencial, en el que el desarrollo de software se
ejecuta en un conjunto de etapas una tras otra. Se le denomina de esta forma por las
posiciones que ocupan las diferentes fases que componen el proyecto, colocadas una encima
de otra, y siguiendo un flujo de ejecución de arriba hacia abajo, dando forma como de una
cascada. Se tiene una visión muy clara del orden de las etapas para el desarrollo básicamente
son, “Requerimientos”, “Análisis”, “Diseño”, “Implementación”, “Integración” y “Mantención”.
Ventajas Desventajas
- Las etapas están bien definidas por lo que - Como muchas veces los clientes no saben
es un modelo fácil de entender. con claridad los requerimientos que
- Como se cuenta con mucha documentación necesitarán para su producto final, es muy
exhaustiva del proyecto, si al equipo se posible que los cambien frecuentemente por
integra un nuevo trabajador le será fácil lo que si esto sucede el cliente deberá
entender el proyecto. esperar hasta la versión siguiente para hacer
- Cada vez que termina una etapa se realizan cambios.
pruebas para continuar con la siguiente, con - El cliente no puede ver un avance del
esto disminuye la cantidad de errores. producto hasta que terminen todas las fases,
44
 - Como es un modelo lineal, es más simple la por lo que puede pensar que está perdiendo
implementación. dinero.
- Si se dispone de todos los requerimientos - No es recomendable para proyectos con
desde el comienzo, es muy útil. cambios de requerimientos continuos, como
- Puede generar un gran producto final sin la al implementar nueva tecnología que no se
necesidad de tener un personal altamente conoce.
calificado. - No es bueno para proyectos a largo plazo
- Las fases están muy organizadas y no se debido a que las necesidades de los clientes
mezcla una con otra. pueden ir variando durante el tiempo.

Al comparar estos dos se puede decir que el ciclo de vida incremental es mucho mejor para este
proyecto dado que se adapta rápidamente a los cambios en comparación al cascada porque en
este se debe esperar hasta el fin de la iteración para recién poder realizar algunos cambios,
inclusive la participación del cliente es muy alta en incremental dado que este está presente
durante todo el proyecto, en cambio en cascada solo aparece al finalizar cada iteración, lo que
tampoco le permite ir viendo la evolución y avances del proyecto.
El ciclo de vida se ajusta con todo lo que la metodología requiere, en primer lugar, Scrum se
ejecuta en ciclos temporales cortos y de duración fija, lo que se denomina Sprint. Durante este
periodo se añaden nuevas funcionalidades al software, las cuales se entregarán posteriormente
al cliente.
En segundo lugar, en incremental cada ciclo que se realiza va obteniendo una porción del
producto, servicio o resultado, cada parte generada en una iteración se le denomina incremento,
es donde se producen fragmentos del resultado del proyecto, siendo dicho proceso bastante
similar a la metodología seleccionada.
Tanto en la metodología Scrum como en el ciclo de vida incremental, los requerimientos para
cada iteración se asignan al comienzo, en scrum se seleccionan según el nivel de prioridad, con
el objetivo de poner en marcha el software lo más rápido posible en base a los requerimientos
más importantes.
Una vez desarrollado el incremento, se realizan las pruebas correspondientes, en scrum se
efectúan al final del sprint backlog, y en incremental después del periodo de construcción, lo cual
es bastante parecido.
El ciclo de vida incremental es la mejor alternativa para el proyecto ToxiCar, dado a los posibles
cambios que habrá durante el desarrollo del software. Además, permite ordenar los avances por
medio de las iteraciones. Otro punto importante es la alta similitud que tiene con Scrum, ya que
muchas etapas comparten los mismos objetivos generales, tal como lo mencionado
anteriormente.
Esto no quiere decir que el modelo Cascada sea malo, sino que no se adapta al proyecto ni a la
metodología, principalmente porque existe una alta probabilidad de cambios de requerimientos y
participación del cliente durante el desarrollo. Este modelo no acepta de buena manera los
cambios, siendo muy difícil volver atrás. Otro punto es que el cliente no ve un avance hasta
terminar todas las etapas del desarrollo, lo cual es bastante negativo, ya que, en el proyecto se
espera una alta participación del cliente. Se puede decir que Cascada está enfocada para
proyectos que tienen una visión clara sobre el producto y con requerimientos fijos, cosa que, en
ToxiCar, podrían variar.

45
12 Planificación temporal Desarrollo

12.1 Carta Gantt

Macro Gantt. Carta Gantt.

13 Planificación de Recursos Humanos para el desarrollo

Planificación de RR.HH.

14 Gestión de las comunicaciones

Plan de comunicaciones.

15 Calidad del producto

46
15.1 Plan de calidad

Plan de calidad.

15.2 Producto por entregar

- Robot ToxiCar, con los debidos sensores y módulos integrados.

- Baterías más cargador, para alimentar el producto.
- ToxiCase (carcasa) para aumentar la distancia de manejo y control del robot.
- Aplicación móvil descargable desde la Play Store o por medio del sitio web en formato APK.
- Manual de usuario físico e instrucciones de uso en la página web.
- 2 horas de capacitación en caso de ser requeridas.
- Documentación técnica de ToxiCar y ToxiCase.
- Cuenta de usuario creada por el administrador o propio cliente.

16 Diseño casos de pruebas

16.1 Pruebas funcionales

Pruebas de caja negra:

Aplicación móvil Página web

Nombre de prueba Requerimientos cubiertos

RU01, RU02, RU03, RU04, RU14, RF01, RF02,

Aplicación móvil RF03, RF06, RF08, RF09, RF10, RF12, RF13,
47
 RF16.

RU05, RU06, RU07, RU11, RU12, RU13,

Página web
RF04, RF05, RF06, RF07, RF10, RF12, RF14,
RF15.

Test de distancia (ToxiCar y ToxiCase):

Dispositivo Medio Teórica Real Obstáculos

ToxiCar / ToxiCase Bluetooth 10 metros 8 metros 5 metros

ToxiCase y ToxiCar Módulo 1800 metros 1520 metros 1150 metros

HC12

16.2 Pruebas estructurales o de Caja Blanca

Aplicación móvil Página web ToxiCar y ToxiCase

17 Análisis de resultados de las pruebas

Las pruebas de caja negra corresponden a una “Técnica de testing en la que se prueba la
funcionalidad de una aplicación ignorando la parte interna de dicha aplicación.” (Testing
Funcional, 2019), esto quiere decir que se omite el código fuente. Esta prueba se centra
exclusivamente en las entradas y salidas del software.
Se puede afirmar que los resultados que se obtuvieron al probar la aplicación móvil fueron los
esperados, el software respondió positivamente a las pruebas. La función iniciar sesión cumplió
su propósito al igual que el registro de usuario.
Por ejemplo, para guardar una medición en la base de datos, deben ingresar los parámetros,
“localización”, “tipo de gas” y “resultado”. Cabe señalar que el usuario no debe introducir ningún
valor, ya que el software los genera y asigna automáticamente. De igual forma se establecieron
clases validas que hacen referencia a los botones que tiene la aplicación móvil.

48
Las funciones más relevantes de la app, que son el joystick y la medición de gases, también
dieron resultados bastante positivos y esperados, ya que cada acción que ejecuta el robot
corresponde a lo seleccionado en la aplicación móvil (adelante, atrás, medir GLP, alcohol, etc.).
Por otra parte, encontramos las pruebas de caja negra aplicadas a la página web, estas se
ejecutaron en base a las acciones que puede realizar el usuario trabajador y administrador
dentro del sitio (eliminar mediciones, registrarse, modificar datos personales, listar registros,
etc.). Al igual que en la aplicación móvil, los resultados se encontraron dentro de los esperado.
En pocas palabras la página web, logra validar los datos que ingresan (rut, nombre, correo,
filtros, etc.) y generar mensajes o respuestas de salida, tales como, “el teléfono debe tener 9
números”, “opción no válida”, “tipo de gas alfanumérico”, entre otras.
En las pruebas de caja blanca “Se pretende indagar sobre la estructura interna del código,
omitiendo detalles referidos a datos de entrada o salida.” (Martínez, 2015), su objetivo principal
es testear la lógica del programa desde su algoritmo, de esta forma se puede garantizar la
ejecución de todos sus caminos y bucles respectivos.
Las pruebas estructurales que se realizaron a la aplicación móvil fueron exitosas, ya que el
código del software orientado a sus funciones principales (iniciar sesión, registro y guardar
medición), actuó de acuerdo a sus estructuras de control (if, else, for, while, etc.).
Por ejemplo, el código de iniciar sesión tiene la condición if (true o false), con dos caminos
independientes, en caso de ser correcto el usuario y la contraseña, el sistema ejecuta el código
necesario para abrir la ventana principal del trabajador, la cual incluye un joystick y menú para
realizar mediciones.
Las pruebas de caja blanca aplicadas a la página web, también respondieron positivamente, ya
que el software logra ejecutar todas las estructuras de control y bucles sin problemas o errores.
La cantidad de código que se testeo fue mayor en comparación a la aplicación móvil, ya que el
sitio, posee más funciones y características (filtrar mediciones, borrar registros, editar datos
personales, etc.).
También se realizó un testing de código a ToxiCar y ToxiCase, ambos productos superaron las
pruebas de caja negra (ingreso de datos por la app) y caja blanca. La estructura interna que
tienen estos dispositivos es bastante sencilla y fácil de entender. Básicamente ToxiCase
funciona como intermediario (receptor y emisor de datos) entre la aplicación móvil y el robot.
ToxiCar es el que ejecuta finalmente las acciones recibidas por el dispositivo.
La última prueba que se realizo está enfocada en determinar el alcance que tiene ToxiCar y
ToxiCase. El módulo Bluetooth tiene una distancia teórica de 10 metros, sin embargo, este valor
no puede ser considerado a la hora de trabajar, ya que las condiciones ambientales y físicas en
donde se prueban estos dispositivos siempre son controladas, lo cual no es lo real. El primer
test, se efectuó en un lugar abierto, dando como resultado 8 metros de distancia, en cambio al
ingresar a un recinto cerrado y con obstáculos, el alcance se redujo a 5 metros.
La distancia teórica del módulo HC12, que tiene integrado ToxiCase y ToxiCar, tampoco es la
real, ya que el alcance de 1800 metros no considera el clima, humedad e interferencias naturales
del ambiente. El alcance obtenido en condiciones normales fue de 1500 metros y al sobreponer
obstáculos e interferencias la distancia disminuyo a 1150 metros, lo cual es suficiente para medir
gases de forma segura.
En resumen, se puede afirmar que el sistema funcionará sin problemas una vez implementado,
las pruebas de caja negra permitieron evaluar los datos que ingresan y salen de la aplicación y la
caja blanca, probar el código interno del software. Los resultados en general fueron positivos, no

49
se encontró ningún error dentro del testing. Así mismo el robot, logra ejecutar y realizar cada
acción de acuerdo a lo seleccionado en la aplicación móvil (adelante, atrás, medir GLP, CO,
etc.). También se diseñó una prueba específica para determinar el alcance que tiene el robot por
medio de Bluetooth o ToxiCase. La distancia es bastante relativa, ya que dependiendo de las
interferencias (paredes, murallas, metales, etc.) es el alcance. Por ejemplo, si conectamos
directamente el móvil al robot en un ambiente abierto, la distancia de control es de 8 metros, en
caso contrario solo 5 metros. Con el dispositivo ToxiCar el usuario trabajador tendrá un mayor
alcance para controlar el robot, aproximadamente de 1500 metros.
Cabe destacar que las pruebas de caja negra y caja blanca aplicadas a la aplicación móvil,
página web, ToxiCar y ToxiCase, cubren y validan todos los requerimientos funcionales y de
usuario, esto indica que el producto cumple con su objetivo y es de calidad.

18 Generación de métricas e indicadores

Producto Métricas Rango normal Actual

Tiempo de descarga mediciones.xlsx < 300 ms 246 ms
Velocidad de carga. < 500 ms 384 ms
Enlaces rotos. <2 0
Página web Errores de usabilidad. <2 0
Número de Bugs. <2 1
Tiempo para listar las mediciones. < 400 ms 243 ms
Número de funciones inactivas. <= 1 0
Tiempo para guardar un registro. < 200 ms 126 ms
Tiempo de carga entre las vistas. < 110 ms 94 ms
Aplicación móvil
Número de errores. <2 0
Tiempo en que se tardan las mediciones en < 450 ms < 315 ms
aparecer en la pantalla.
Cantidad de Bugs. <2 1
Tiempo en interpretar los comandos < 60 ms 46 ms
recibidos.
Velocidad (revoluciones por minuto). > 140 y < 150 rpm 146 rpm
ToxiCar
Distancia de control (Bluetooth). >= 1 y <= 8 metros 5 metros
Líneas de código sin ejecutar < 5 líneas 0
Número de fallas en el robot. <= 1 0
Duración de la batería. > 140 y < 180 minutos 168 minutos
Tiempo de envío y recepción de datos. < 350 ms 243 ms
Peso del dispositivo. > 300 y < 400 gr 364 gr
Alcance de la conexión (radiofrecuencia). >= 1 y <= 1150 metros 1150 metros
ToxiCase
Cantidad de errores. <= 1 0
Tiempo de autonomía. > 90 y < 120 minutos 108 minutos
Líneas de código sin ejecutar < 2 líneas 0

19 Matriz de Riesgos

19.1 Desarrollo del software

50
19.2 Mapa de calor

Matriz de Riesgos.
51
20 Plan de Distribución y Definición Ambiente de Producción

Proceso de distribución de ventas:

Toxicar al ser un robot que contara con una aplicación móvil que realizara la función de controlar
al robot, una página web donde se podrá visualizar cada medición que haya sido realizada por el
usuario del robot y la app móvil, junto al robot Toxicar esta Toxicase el cual es un complemento
adicional con el que se podrá aumentar la distancia a la cual funciona normalmente Toxicar (8 o
menos metros) a unos 1000 metros aproximadamente, la forma en la que Toxicar será
distribuido al consumo del público será en base a la venta del robot con o sin su complemento.
Para la distribución se contará con una página web y tienda física dedicada a ser una tienda para
Toxicar y Toxicase, donde existirán 3 opciones de venta:

ToxiCar Solo: Básicamente será la venta del robot Toxicar únicamente, este al momento de ser
comprado se brindará del código QR para realizar la descarga de la aplicación móvil que servirá
para controlar Toxicar. Existirán 2 opciones previas a la conclusión de la venta de Toxicar, una
de ellas será la venta del robot ya ensamblado, con todas sus piezas en sus lugares
correspondientes y listo para su funcionamiento, y la segunda opción sería la venta de Toxicar,
pero esta vez desarmado, lo que se busca con vender Toxicar desarmado, aparte de ser la
opción más barata, es incentivar a los clientes a aprender de Arduino junto a brindar una forma
más intuitiva a la hora de comprar el Robot, para esta compra aparte del código QR se le
entregara al cliente un manual de armado para el robot, el cual estará detallado minuciosamente,
ya que, la programación del Arduino queda almacenado en esta y cada componente debe de
conectarse en el pin correspondiente.

ToxiCase Solo: Toxicase es el complemento que ayudara a Toxicar cubrir una mayor distancia
para realizar sus funciones de una manera más alejada al usuario, ya que, la conexión Bluetooth
tiene un rango de distancia no más de 8 metros, pero con este complemento puede llegar a
tener distancias de hasta 1200 metros.

ToxiCar + ToxiCase: esta opción brindara al cliente el robot Toxicar más su complemento
Toxicase, para así tener la distancia extra y al robot ya integro y listo para su funcionamiento,
esta opción es la ideal para llegar y trabajar con largas y cortas distancias.
Al momento de realizar la compra, a los clientes se le brindará una boleta junto al Folio/Código
de venta, la cual se le pedirá al usuario de Toxicar como campo obligatorio a la hora de
registrarse en la página principal www.toxicar.cl para revisar las mediciones realizadas por el
mismo y luego poder realizar una exportación en el archivo Mediciones.xlsx, este campo
obligatorio se realiza para evitar el registro de personas que no cuentan con el producto Toxicar.

52
Diagrama de distribución UML:

Resumen de la ubicación de los componentes:

Componente Ubicación
No habrá un servidor físico en las instalaciones de
ToxiCar, ya que se alquilará uno en la nube, de esta
Servidor forma se pueden ahorrar costos de instalación,
mantención y actualización, además de asegurar una
disponibilidad permanente y constante.
La BD, se encontrará integrada en el servidor de la nube
(BlueHosting), el administrador podrá acceder a ella a
Base de datos través de la página web del proveedor o por aplicaciones
externas (MySQL Workbench o RemoDB).
ToxiCar App, se instalará en cada uno de los
smartphones de los trabajadores (mineros, bomberos,
Aplicación Móvil químicos, etc.). Será subida a la Play Store, para que
estos puedan descargarla e instalarla.
La página web, se encontrará desplegada en el servidor
de la nube, los archivos de tipo HTML y PHP estarán
Página web guardados y organizados en la carpeta “PUBLIC_HTML”,
del servidor.

21 Plan de implementación

Plan de implementación Carta Gantt de la implementación

53
21.1 Manual técnico

Manual técnico.

21.2 Manual de usuario

Manual de usuario.

54
22 Interesados por el proyecto

Equipo del proyecto: Con el propósito de ayudar a los trabajadores o empresas que tienen
directo contacto con gases nocivos y algunos que pueden ser letales al estar en contacto con las
vías respiratorias de los trabajadores, nace el proyecto Toxicar, para facilitar dichos trabajos que
puedan poner en riesgo a las personas involucradas.

La principal expectativa del equipo del proyecto es el buen uso y la facilidad para entenderlo por
las empresas o personas que se estudiaron y serian principales interesados, entregando un
producto sencillo de entender la funcionalidad principal y fácil de manipular por cualquier
involucrado, ayudando y facilitando el trabajo de todos, entregando mediciones exactas de los
gases presentes en el ambiente para que las empresas realicen una estrategia o un trabajo sin
mayor riesgo.

Empresas mineras: ToxiCar va dirigido a diversos tipos de empresas, siendo la primera las
mineras. El robot que va a desarrollarse hará un gran aporte en los trabajos de medición en los
subterráneos de las minas, en donde se concentran diversos químicos, tales como el nitrógeno,
sulfúrico, monóxido de carbono entre otros. Dichos gases al encontrarse en altos niveles resultan
nocivos para la salud de las personas, siendo necesario monitorearlos.

La principal expectativa de la empresa, sobre el robot, es tener un producto que pueda medir
gases en un ambiente cerrado, oscuro y en un camino inestable, ya que el lugar de trabajo
presenta condiciones ambientales y físicas que el dispositivo tendrá que soportar. Añadiendo
que la temperatura y humedad son factores que podrían variar de acuerdo el nivel de
profundidad de los túneles, por lo cual es necesario que el robot posea una estructura resistente
ante las dificultades mencionadas anteriormente. Otra expectativa, de las mineras, en cuanto a
software, es poder obtener reportes de forma sencilla, para analizar las condiciones de los
túneles y tomar las medidas preventivas necesarias.

Los beneficios generales que brindará este producto en la minería es mayor seguridad, facilidad
para tomar muestras y mayor productividad.

La forma en la que se espera impacte el robot dentro de las empresas mineras será de lo más
positivo posible, logrando evitar que los trabajadores ingresen a ciertos lugares que no se tiene
claro la emisión de gases nocivos y sin antes estar seguros de si el lugar es seguro o no, como
se menciona anteriormente el robot brindara la seguridad necesaria de los trabajadores midiendo
y emitiendo reportes de cada Gas encontrado dentro de algún sector.

Empresas químicas: Una labor que hacen las empresas que trabajan con químicos es medir
gases en diferentes industrias, principalmente para mantener una condición ambiental adecuada,
con el propósito de evitar explosiones, intoxicaciones, incendios, etc. Medir gases también es útil
en uso interno, como por ejemplo en laboratorios, ya que, para trabajar con materiales tóxicos o
inflamables es necesario un ambiente controlado y libre de otros compuestos, para así disminuir
la probabilidad de una reacción no deseada.

55
Las empresas químicas tienen como expectativa, tener un producto, que les permita monitorear
múltiples gases a la vez, para llevar un control sobre ellos. Requieren que el dispositivo sea
liviano, para llevarlo a las distintas industrias a analizar. Agregando una mayor capacidad para
almacenar datos y un ecosistema simple.

El robot además de darles una mayor seguridad a los trabajadores automatizará varios
procesos, por ejemplo, no será necesario conectar el dispositivo al computador para transferir
datos, ya que la aplicación guardará de forma automática las mediciones en el servidor, las
cuales podrán visualizarse o exportarte a través de la página web. Además, será un producto
pequeño, ideal para ser transportado a diferentes lugares y tendrá una capacidad de
almacenamiento superior a los de un dispositivo tradicional. Se le integrarán diferentes sensores,
que le permitirán al personal de las empresas químicas u otra, detectar de forma rápida y
sencilla los gases en el ambiente.

Gracias a la seguridad que brindara el Robot en las empresas o laboratorios químicos ante el
monitoreo de gases, y el rápido control de estos mediante la página web donde se visualizarán
las mediciones entregadas por el robot, se podrán tomar medidas de seguridad en caso de fugas
o problemas derivados con los gases, sin poner en riesgo al personal de la empresa o
laboratorio, mejorando el rendimiento de trabajo gracias al robot.

Bomberos: Los bomberos en diversas ocasiones necesitan realizar mediciones de gases,

especialmente en incendios ya sea en un departamento, casa, industria, supermercado, etc. El
propósito de aquello es para saber con qué tipo de químicos se encuentran y la magnitud del
accidente, para así utilizar la mejor herramienta para combatir la emergencia.

Al igual que las empresas mineras, los bomberos esperar de ToxiCar un producto que además
de medir gases, no se vea afectado por el humo y las temperaturas del ambiente. Así mismo
requieren que el proceso de detección sea lo más preciso posible, con el objetivo de tener
claridad sobre los químicos existentes, ya que al utilizar una herramienta incorrecta se podría
propagar aún más el incidente.

Como el robot se controla de forma inalámbrica, específicamente con Bluetooth, les dará a los
trabajadores mayor protección al realizar las mediciones, ya que habrá una distancia entre el
incidente y el trabajador, por ejemplo, en caso de haber caída de escombros en un incendio, el
robot sería el dañado no el personal.

Gracias a la facilidad en el uso del robot, la rápida aplicación y la gran adaptabilidad que tiene el
robot para entrar en lugares pequeños, facilita enormemente el trabajo de los bomberos en
zonas de desastres como casas, departamentos e incluso en zonas forestales, donde en esta
ultima las emisiones de gases nocivos para el personal puede ser riesgosamente elevada
provocando intoxicaciones, como se mencionó con anterioridad la facilidad de uso y la gran
adaptabilidad que presenta el robot ayudaran en los trabajos de los bomberos entregando
mediciones inmediatas y llegando a lugares de difícil acceso para las personas, así los
bomberos podrán actuar de mejor manera ante dichas situaciones.

Gasfíter: Tanto las empresas de gasfitería como los gasfíteres particulares tienen como labor,
instalar o reparar sistemas de calefacción y a gas, por ejemplo, para solucionar problemas de
fugas, necesitan saber el tipo de gas para saber de dónde proviene. Así mismo medir los gases
56
es importante para verificar, si las instalaciones fueron realizadas de forma correcta, para evitar
accidentes.

Algunas de las expectativas de los gasfíteres sobre el proyecto ToxiCar, es obtener un producto
liviano, transportable y pequeño, principalmente para el uso en hogares o en pequeñas
empresas. Además, este grupo de personas también espera que el software sea sencillo y
básico, pero funcional, sin apartados sofisticados que impliquen una dedicación prolongada de
tiempo para aprender a utilizar el dispositivo. Otro factor relevante para los gasfíteres es el costo
final del producto, ya que como se dijo anteriormente, muchos de los dispositivos que existen en
el mercado son muy costoso para las funciones que tienen, por lo que significa que requieren un
producto acorde a sus características.

El robot les ofrecerá a los gasfíteres o empresas, mayor facilidad para detectar gases,
transportabilidad, software sencillo, seguridad y tecnología. Agregando también una página web
para visualizar las mediciones y una app para controlar el robot.

La manera de impactar el proyecto en los Gasfíter será gracias a lo mencionado con anterioridad
y reiterado en varios puntos, la fácil utilización del Robot, su fácil transporte, la comodidad en el
uso y la rapidez en los procesos que este realiza, de igual forma lo cómodo que es usar la
interfaz junto a la página web para visualizar cada medición hechas por el robot ayudan bastante
a que cualquier persona pueda ser capaz de utilizarlo.

Lista de Interesados.

57
23 Conclusión

Toxicar es un robot diseñado para las mediciones de gases que se encuentren presentes en el
ambiente o lugar donde este robot este presente y trabajando, básicamente se trata de un robot
Arduino que está integrado con sensores los cuales perciben y envían los datos de los gases
que estos reciban, está diseñado para ayudar a evitar accidentes de personas que se
encuentren expuestas a gases, como pueden ser bomberos, mineros, etc.
Durante todo el transcurso de este informe que va implementado cada entrega en uno solo se ha
podido ver cada punto de Toxicar, desde la idea, la creación de la solución, todo lo que conlleva
a los requerimientos, diagramas para la comprensión del trabajo.
Con todo esto se puede ir mostrando cada punto fuerte y las debilidades del proyecto, pero la
idea es cada vez ir actualizando y mejorando Toxicar para la llegada de los últimos entregables y
ultimo prototipo del trabajo, el cual debe ser adaptativo al entorno y lograr suplir en
funcionamiento a los dispositivos que hoy en día se utilizan para la medición de gases.

58
24 Bibliografía

Abellán, M. Á. (9 de 7 de 2019). Programo Ergo Sum. Obtenido de Introducción a la

programación con AppInventor: https://www.programoergosum.es/tutoriales/introduccion-
a-la-programacion-con-appinventor/

Andrés. (11 de 10 de 2018). Guiadev. Obtenido de PHP vs ASP.NET: https://guiadev.com/php-

vs-asp-net/

Deyimar. (9 de 3 de 2022). Hostinger Tutoriales. Obtenido de Diferencia entre MySQL y SQL

Server: https://www.hostinger.es/tutoriales/diferencia-mysql-sql-server

EALDE. (27 de 8 de 2019). EALDE BUSINNES SCHOOL. Obtenido de Dirección de Proyectos:

https://www.ealde.es/product-backlog-sprint-backlog/

Fasola, F. (13 de 9 de 2021). La Tercera. Obtenido de Robótica en Chile: el futuro ya está aquí:
https://www.latercera.com/laboratoriodecontenidos/noticia/robotica-en-chile-el-futuro-que-
ya-esta-aqui/ZVSDMDTGHZGKBGI7YZKGNSQDQY/

Mercadeo Premac. (30 de 4 de 2021). Premac Energy. Obtenido de ¿Conoce la importancia de

utilizar los detectores de gas y cuál es el más adecuado para su necesidad?:
https://www.premac.co/conoce-la-importancia-de-utilizar-los-detectores-de-gas-y-cual-es-
el-mas-adecuado-para-su-necesidad/

Programador Click. (2019). Programador Click. Obtenido de Introducción al procedimiento

almacenado mysql: https://programmerclick.com/article/9253634152/

Seguridad Minera. (6 de 4 de 2016). Seguridad Minera. Obtenido de 7 gases presentes en minas

subterráneas: https://www.revistaseguridadminera.com/operaciones-mineras/7-gases-
presentes-minas-subterraneas/

Testing Funcional. (4 de 12 de 2019). Testing Funcional. Obtenido de Pruebas de Caja Negra:

https://howtotesting.com/testing-funcional/pruebas-de-caja-negra/

Tirado, J. M. (28 de 11 de 2019). Mamá… ¿Qué es Scrum? Obtenido de Cómo resuelve Scrum
los cambios de alcance: https://mamaqueesscrum.com/2019/11/28/como-resuelve-scrum-
los-cambios-de-alcance/

59