Informe de práctica profesional II

Proyecciones de comercio exterior empleando series de

tiempo

CC5901-1 Práctica Profesional II

Informe de Práctica

Felipe Sanhueza C.
19.432.964-4
sanhuezafce@gmail.com
(+56) 9 5670 5786
Duración: 18//01/2021 -
12/03/2021
Fecha de entrega: 30/04/2021
.
Instituto Milenio Fundamentos
de los Datos
Informe de Práctica Felipe Sanhueza C.

Índice
1. Resumen 2

2. Introducción 3
2.1. Equipo de Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Descripción general del trabajo realizado . . . . . . . . . . . . . . . . . . . . 3

3. Descripción del problema 4

4. Objetivos 5

5. Metodologı́a 6

6. Descripción de la solución 7
6.1. Hardware y Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Series de tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.3. Corrección de errores en BBDD . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.4. Fortalezas y debilidades de las soluciones . . . . . . . . . . . . . . . . . . . . 11

7. Reflexión 12
7.1. Dificultades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Herramientas Universitarias . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.3. Aprendizajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

8. Conclusión 14

1
Informe de Práctica Felipe Sanhueza C.

1. Resumen
El trabajo fue realizado para el Instituto Milenio Fundamentos de los Datos (IMFD de
ahora en adelante). Este trabajo consistió en generar proyecciones económicas empleando
series de tiempo y, en crear un script en python el cual, corrija la estructura de un conjunto
de tablas dentro de una base de datos.

Debido a temas de confidencialidad, se firmó un NDA con el IMFD por lo cual, no se

adjuntan resultados explı́citos del trabajo realizado (gráficos y parámetros).

En una primera instancia el practicante investiga todos los conceptos nuevos y tecnologı́as
a utilizar durante la práctica lo cual concluye en una definición de requisitos y metodologı́a
de trabajo para la práctica.

Luego, se implementa un modelo SARIMAX el cual se valida parcialmente y, al intentar

realizar predicciones sobre otras variables se obtienen resultados similares.

Por otro lado, se desarrolló también un script en python el cual luego de recibir feedback
del supervisor, se le agregaron features, se testeo, documento y, corrigieron casos bordes.

Finalmente se documentan ambas soluciones, se agrega un README a la implementación

de las series de tiempo y, se ordena la estructura del código de ambas soluciones para tener
ası́ entregables claros.

Esto concluye la práctica de manera exitosa cumpliendo ambos objetivos de los dos pro-
yectos, a pesar de no haber tenido proyecciones completamente precisas, el supervisor
está satisfecho con el trabajo realizado ya que se obtuvieron resultados preliminares cohe-
rentes sobre los cuales el IMFD podrá a futuro ajustar los parámetros con más datos y
técnicas.

Posterior a la finalización de la práctica, el practicante realiza una última tarea para

el IMFD la cual era una exposición respecto a series de tiempo y los resultados de la
proyección realizada a todos los integrantes del IMFD.

Sobre los aprendizajes obtenidos, por un lado está la capacidad de explorar lenguajes
de programación nuevos (para el programador) y, por otro lado, la manera apropiada de
levantar requisitos con un cliente.

También vale la pena mencionar el manejo de la librerı́a pandas y, de las técnicas necesarias
para implementar series de tiempo.

2
Informe de Práctica Felipe Sanhueza C.

2. Introducción
Actualmente el IMFD está dividido en múltiples equipos de trabajo los cuales asumen dis-
tintos proyectos todos relacionados al ámbito de Data Science. El practicante se integró al
instituto para prestar apoyo a 2 equipos: el equipo del gobierno de datos los cuales re-
querı́an asistencia para corregir errores en la base de datos de un cliente y, al equipo del
ministerio de transporte (MTT de ahora en adelante) el cual debı́a generar una proyección
empleando series de tiempo.

Debido a esta estructura de trabajo, se dividirán las principales partes del informe para
comentar de manera ininterrumpida cada proyecto.

2.1. Equipo de Trabajo

En ambos equipos de trabajo, el practicante contaba con 2 personas a los cuales debı́a
prestar apoyo en la realización de alguna tarea dentro del proyecto. Estos compañeros
prestaron su ayuda en caso de que fuera necesaria y, dentro de los equipos existı́a muy
buena comunicación debido en parte, a reuniones diarias de avance.

2.2. Descripción general del trabajo realizado

Primero el practicante comenzó en el equipo de MTT, donde tuvo que familiarizarse rápi-
damente con series de tiempo y su implementación en Python. Este proceso culminó en
el desarrollo de notebooks en Jupyter los cuales tenı́an explicado los análisis realizados
sobre múltiples gráficos desde los cuales se desprendı́a información sobre los parámetros
tentativos del modelo.

Finalmente con los datos adquiridos a partir de los gráficos, se generaron proyecciones
sobre el 2022 respecto a las exportaciones desde los puertos de Chile y, se validaron a
través de tests y análisis de gráficos. Con esto se concluye el trabajo para el equipo MTT.

Durante el trabajo con el gobierno de datos el practicante tuvo que solucionar un problema
respecto a la estructura de las tablas presentes en una base de datos, esta corrección se
realizó a través de un script de python el cual, debı́a pasar por un pipeline antes de ser
aceptado por el sistema.

Este script una vez implementando se notificó al supervisor el cual, entregó feedback
sobre nuevas features a implementar. El script entonces es testeado y, las nuevas features
implementadas, concluyendo ası́ el trabajo realizado.

3
Informe de Práctica Felipe Sanhueza C.

3. Descripción del problema

Se describirán por separado los problemas de cada proyecto ya que estos consisten de
problemas y equipos totalmente distintos.

MTT
Para el caso del MTT, al momento de que el practicante se incorpora al equipo, estos
estaban cerrando una fase del proyecto con el ministerio de transporte luego de haber
entregado un set de visualizaciones respecto a las exportaciones de los puertos Chilenos.
El problema entonces, era que para la siguiente fase del proyecto, se solicitó generar unas
proyecciones respecto a las exportaciones de los puertos para el año 2021-2022 las cuales
debı́an realizarse con series de tiempo. En la duración de la práctica, se consideraba dentro
de las tareas del practicante aprender sobre series de tiempo.

Gobierno de datos
Por otro lado, el trabajo con el gobierno de datos se basó en un problema en la base de
datos de un cliente, el cual luego de instalar un software para administrar la información
de su personal, generó inconsistencias debido a que el personal no usaba tanto la nueva
plataforma. Estas inconsistencias llevaron a que solicitarán del IMFD ayuda para norma-
lizar bases de datos y crear nuevas vistas. No obstante durante el proceso de validación, el
equipo del IMFD previa a la llegada del practicante se encontró con un bug causado por
la lógica de SQL al eliminar tablas en cascada las cuales contenı́an un ciclo por lo cual,
debieron implementar una solución a través de triggers. Esto último a pesar de haber so-
lucionado el problema, tenı́a una desventaja muy grande ya que al tener que implementar
todos los triggers manualmente y debido al volumen de las tablas, quedaron inconsistencias
difı́ciles de detectar manualmente en varias tablas.

4
Informe de Práctica Felipe Sanhueza C.

4. Objetivos
Los objetivos de esta práctica fueron nuevamente por proyecto ya que entre estos, no habı́a
relación.

MTT

Objetivo Principal

Hacer una proyección de la demanda portuaria en operaciones de comercio exterior.

Objetivos especı́ficos

1. Estudiar series de tiempo conceptualmente.

2. Implementar la proyección en Python u, otro lenguaje que permita una mejor pro-
yección.

3. Utilizar el set de datos en conjunto al modelo para generar proyecciones.

4. Emplear técnicas para validar el modelo.

5. Generar un entregable y exponer la solución al equipo.

Gobierno de datos
Objetivo Principal

Automatizar la corrección de las tablas para cualquier base de datos que contenga incon-
sistencias causadas por el problema encontrado.

Objetivos especı́ficos

1. Estudiar las bases de datos y las tecnologı́as necesarias para trabajar en este proyecto.

2. Entender el problema e investigar distintas formas de solucionarlo.

3. Definir requisitos del script con supervisor .

4. Implementar solución en el lenguaje seleccionado y, de acuerdo al pipeline utilizado

por el proyecto.

5. Testear y documentar código de la solución.

6. Enviar solución a supervisor y corregir en base a comentarios.

5
Informe de Práctica Felipe Sanhueza C.

5. Metodologı́a
Se dividirá la metodologı́a en dos partes según cada proyecto.

MTT
Comenzando el trabajo, se procede a estudiar series de tiempo para determinar cuál es
la mejor forma de implementar la solución al problema dado. Esta se concluye que es
implementar un modelo ARIMA en python.

Se sigue un tutorial el cual guiaba una implementación de un modelo similar. En base a

esto y a un conjunto de papers, se adquiere un set de parámetros que se utilizaron para
alimentar el modelo.

Finalmente, en base al resultado adquirido y la validación, se concluye que el resultado no

es correcto y se procede a revisar los parámetros y, a intentar un modelo SARIMAX ya
que la validación permitió inferir que el modelo previo era inadecuado.

Se procede a hacer los ajustes necesarios para implementar un modelo SARIMAX el cual,
una vez implementado y ajustados los parámetros, entregó mejores resultados.

Una vez finalizado esto, se procede a ordenar los archivos, documentar los métodos y los
análisis realizados para tener un entregable ordenado.

Gobierno de datos
El practicante comienza estudiando la estructura de las bases de datos y, las herramientas
requeridas para trabajar en el proyecto como Gitlab y Docker. Por otro lado, le fue asignado
investigar cómo implementar de manera más efectiva una solución al problema dado. Esto
concluyo en que serı́a un script de python.

Luego, se asignó la tarea de implementar dicho script en base a un standard de trabajo

dado por el equipo y, por un pipeline el cual testea con flake8 el código. Una vez finalizada
la implementación, se notifica tanto al supervisor como a otro miembro del equipo ya que,
ahora se debı́an implementar correcciones dadas por ellos en el script.

Esta fase constó de más de una iteración ya que durante el proceso de corrección se hizo
notar la falta de algunos requisitos que no fueron apropiadamente definidos en un inicio
por lo cual se tuvo que hacer un refactoring de parte del código.

Una vez finalizadas estas iteraciones, se da por cerrada la fase de corrección y se organiza
un entregable bien documentado para el equipo.

6
Informe de Práctica Felipe Sanhueza C.

6. Descripción de la solución
6.1. Hardware y Software
En términos de Hardware, debido a la pandemia todo el trabajo realizado en la práctica
fue remoto, por lo que el hardware relevante son el computador mismo del practicante el
cual se solicitó que tuviera Linux como sistema operativo.

En términos de software, se utilizó principalmente Python para llegar a las soluciones

finales en ambos proyectos pero, en el proceso también se trabajó principalmente con
Gitlab y Jupyter entre otros.

6.2. Series de tiempo

Para el equipo del MTT, la solución tiene forma de una serie de archivos notebook jupyter
en los cuales se estructuran cada uno de las distintas configuraciones de parámetros para
las múltiples proyecciones a realizar con el modelo SARIMAX.

Se hizo en particular un enfoque en la proyección del Free On Board 1 (FOB de ahora en

adelante) total ya que era una de las variables principales a analizar junto con las toneladas
de peso exportado.

Se realizaron también otras predicciones sobre otros subsets de datos una vez se tuvo la
estructura principal de estas.

Datos a trabajar

Se recibió un dataset filtrado con información justa y necesaria para realizar la serie de
tiempo. El practicante no tuvo acceso al detalle de las operaciones.

El trabajo común para cada archivo (los cuales generan las predicciones) era un pre pro-
cesamiento de datos el cual incluı́a filtrar los datos (para adquirir un sub set adecuado
para cada predicción dada) y, realizar un proceso de re-sampling de estos, para que cada
fila represente un mes de transacciones en vez de una sola. Esto se realizó con la librerı́a
pandas y, permitió obtener predicciones más precisas sobre los datos.

Modelo e implementación SARIMAX

El modelo SARIMAX se armó a partir de la librerı́a statsmodels de python la cual tiene

métodos para la implementación de múltiples modelos de series de tiempo. Para poder
1
FOB=el valor de la mercancı́a puesta en el puerto de embarque.

7
Informe de Práctica Felipe Sanhueza C.

utilizar estos modelos, se requirió de la librerı́a de python pandas ya que esta permite
arreglar los datos para obtener predicciones más precisas.

Para obtener una predicción entonces, se gráfica la autocorrelacion (ACF ) y autocorrela-

ción parcial (PACF ), una descomposición adquirida a partir de la librerı́a statsmodels y,
se ejecutan unos métodos de la librerı́a pmdarima (tests para determinar parámetros).

Una vez realizado todo esto, se llama finalmente al método del modelo el cual es invocado
con los parámetros adquiridos a partir del análisis de todos los gráficos y test previamente
realizados.

Proyecciones

Se realizó en primer lugar, una predicción sobre el “FOB total”. Esta predicción fue al-
tamente documentada tanto en la adquisición de los parámetros como en la lógica de la
implementación ya que, se usarı́a como estructura para las demás predicciones.

Los resultados adquiridos de esta proyección no fueron del todo buenos. A pesar de múlti-
ples intentos de adquirir una mejor proyección, existieron limitaciones debido a errores y
problemas con la librerı́a statsmodels y, debido a que en los datos dados al practicante,
existı́an inconsistencias.

Lo mismo ocurrió al usar otros subconjuntos de datos para realizar proyecciones sobre
otros atributos del set de datos inicialmente entregado al practicante.

Proyecciones en R

Dado los problemas presentados previamente , el practicante al solicitar ayuda a otro

miembro del equipo, se encuentra con que la solución podrı́a ser una implementación en
R de la proyección.

Para realizar esto, se implementó en un breve periodo de tiempo, los gráficos y test nece-
sarios para adquirir parámetros para el modelo.

Finalmente los resultados adquiridos son de mejor calidad, logrando obtener con ellos
valores distintos para los parámetros previamente seleccionados. Esta implementación en
R no pudo llegar más lejos debido al tiempo restante en la práctica y, no pudo solucionar
los problemas previamente encontrados.

8
Informe de Práctica Felipe Sanhueza C.

Validación y documentación

Para todos los casos, los resultados de las predicciones lograron ser parcialmente validadas,
Indicando que existe aún espacio para ajustar los parámetros y el modelo en sı́.

Finalmente, se documentan los análisis y métodos en el archivo de la proyección “FOB

total”(ya que las demás proyecciones son análogas) y, se realiza, un README junto con
una carpeta con pdfs y links útiles en el proceso de implementar series de tiempo en python
yR.

6.3. Corrección de errores en BBDD

Requisitos solución

En una primera reunión con el supervisor se definió que la solución debı́a cumplir los
siguientes requisitos:

Encontrar y corregir los triggers y llaves foráneas incompletos en la bbdd.

Entregar un reporte de errores y, la opción de hacer cambios en base al reporte.

Los archivos a entregar deben pasar el pipeline del proyecto.

En base a estos primeros requisitos, se confecciona la primera iteración de la solución.

Script de python

El script entregado al supervisor recibe por argumentos una carpeta (la cual debe ser el
esquema donde se encuentran las tablas a revisar) y, un parámetro adicional –fix.

El código lo que hace es revisar todas las tablas del esquema y almacenar en un diccio-
nario información sobre qué tablas referencia un trigger o, una llave foránea (todo esto
será necesario para la corrección) y, sobre el contenido del archivo donde se encontró dicha
tabla.

Luego el código a través de una expresión regular(regex ), revisa la tabla referenciada por
un trigger cualquiera y, en dicha tabla busca una llave foránea que la referencia devuelta
(comportamiento esperado). Este mismo proceso se realiza en el sentido inverso (de una
llave foránea a triggers) y, en caso de encontrar inconsistencias estas se guardan en una
lista (estas son las tablas a corregir).

Finalmente, el script si no fue llamado con el parámetro –fix solamente entrega un reporte
de errores para que el usuario pueda revisar manualmente en caso de necesitarlo. En caso

9
Informe de Práctica Felipe Sanhueza C.

de dar el parámetro, el script edita los archivos donde están las tablas afectadas agregando
la estructura de las llaves foráneas o triggers faltantes.

Pipeline y standard del código

Este código debe pasar un pipeline que lo evaluaba con flake8 para ser aceptado por el
repositorio del proyecto por lo cual, el practicante tuvo que preocuparse de mantener la
solución al estándar adecuado. También en base a comentarios del supervisor y miembros
del equipo, el código se modifica para cumplir con buenas prácticas y, para utilizar las
técnicas más adecuadas para las tareas más generales (parsear argumento, estructurar
tests entre otros),

Correcciones del código

El código una vez finalizado, se notificó tanto al supervisor como a un miembro del equipo
los cuales, revisaron el código y entregaron feedback respecto a prácticas utilizadas y, sobre
features que se deberı́an agregar al script. Entre estas se encontraban:

El script debe funcionar en otros esquemas

Agregar el caso cuando existe más de una tabla en un archivo.

Se debe testear la solución con pytest

Se deben corregir casos bordes encontrados.

Para poder implementar estos nuevos requisitos, se debió refactorizar parte del código lo
cual se realizó exitosamente.

Testeo del código

Finalmente, se realizan test con pytest los cuales se volvieron parte del entregable final.
Estos tests incluyen un set de tablas para modificar y, tablas desde las cuales se retornan
al estado inicial de tal forma de no alterar los tests por su ejecución misma. Estos tests
revelaron más casos los cuales fueron corregidos a tiempo.

Documentación y finalización de práctica

Una vez realizado todo lo previo, se documentan todos los métodos realizados, los tests y,
se solicita el merge con la rama principal del proyecto dando por finalizado el trabajo con
el equipo del gobierno de datos.

10
Informe de Práctica Felipe Sanhueza C.

6.4. Fortalezas y debilidades de las soluciones

En el caso del MTT, la principal fortaleza es la estructura definida y la documentación
redactada ya que estos reducen en gran parte la labor investigativa necesaria para poder
implementar series de tiempo apropiadamente y, dejan en claro cómo continuar el trabajo
comenzado y como enfrentar los errores más tı́picos.

La principal debilidad es el lenguaje en el cual fue implementada la solución ya que al

estar en python, se utilizó una librerı́a la cual fue parte de los principales problemas de
la implementación. En un breve periodo durante la fase de validación, experimentos con
el lenguaje R indicaron que en comparación a los resultados preliminares obtenidos con
python, R mostró mejores resultados lo cual indicó que de haber existido más tiempo, una
implementación en R pudo haber entregado mejores resultados.

Otra debilidad que vale la pena mencionar, es el hecho de que el modelo fue entrenado con
datos del 2018 al 2020. En este perı́odo ocurre el “estallido social”(2019) y, la pandemia
llegó a Chile (2020) por lo tanto, no se contaban con condiciones normales para los datos.

En el caso del gobierno de datos, la principal fortaleza de la solución es la versatilidad

que tiene para corregir errores dentro de una carpeta dada, desde la detección del tipo
correcto de archivo hasta la detección de múltiples tablas dentro de un archivo o tablas
de esquemas distintos en una sola carpeta.

La debilidad de esta solución, recae en que debe ejecutarse el script de python para realizar
la corrección, esta no es capaz de hacerse por sı́ sola y, es algo que a futuro quizás deba
implementarse.

11
Informe de Práctica Felipe Sanhueza C.

7. Reflexión
Previamente el practicante habı́a realizado una práctica relacionada al área de la investi-
gación en el laboratorio SPEL, esta práctica al ser también del mismo ámbito reafirmó la
idea de que la investigación es algo de gran interés para el practicante y, particularmente
el área del data science.

La experiencia de un trabajo en una empresa del ámbito computacional contrastó con

aquella de un laboratorio, particularmente en la estructura del trabajo y en cómo este
progresaba.

La manera en que los múltiples equipos trabajaban de manera disjunta por un gran ob-
jetivo general, demostró el alto grado organizacional que la empresa tiene y, demostró al
practicante lo eficiente que puede ser un gran equipo de trabajo con un liderazgo y orga-
nización adecuada.

7.1. Dificultades
Las principales dificultades de esta práctica fueron durante el proyecto del equipo MTT y
la implementación de series de tiempo.

Por un lado, la implementación de las series de tiempos resultó un proceso desafiante en

el cual se tuvo que retomar pasos previos múltiples veces debido a la variedad de técnicas
disponibles para llegar a un resultado y, la necesidad de encontrar uno adecuado para el
caso presente. También agregar que el practicante no tenı́a experiencia previa con series
de tiempo y aprenderlas, era parte de los desafı́os de la práctica.

Por otro lado, se utilizó python para la implementación de estos modelos y, ya avanzado
el trabajo se evidencio que el lenguaje R es mucho más adecuado para este trabajo, en
parte debido a su capacidad para dar mejor feedback sobre el comportamiento del modelo
y, por los múltiples problemas presentados por la librerı́a statsmodels de python la cual,
es la principal herramienta para modelar series de tiempo en este lenguaje.

Esta librerı́a fue tanto una ayuda como un problema, una ayuda dado que sin ella no
se hubiese podido alcanzar una solución pero aun ası́, esta tenı́a métodos sin implemen-
tar, presentaba problemas para desplegar resultados y, genera también problemas cuando
habı́an inconsistencias en los datos los cuales se pretendı́an arreglar manualmente. Esto
ocurrió principalmente porque los métodos de statsmodels reciben wrappers con la infor-
mación necesaria en vez de vectores o dataframes de pandas.

12
Informe de Práctica Felipe Sanhueza C.

Respecto al equipo del gobierno de datos, una dificultad que se presentó de manera ines-
perada fue la poca claridad del practicante al levantar requisitos para el script de python
con el equipo del gobierno de datos. Durante el desarrollo del proyecto este requirió de
refactoring y múltiples adiciones de features lo cual, pudo haber sido evitado y se pudie-
ron haber ahorrado mucho trabajo si, en la reunión inicial con el supervisor el practicante
hubiese planteado más dudas y hubiese ahondado más en lo solicitado y, en lo que respecta
al uso esperado de la solución.

7.2. Herramientas Universitarias

Respecto a las herramientas universitarias, cursos como CC3002-1 (Metodologı́as de Diseño
y Programación) y, CC4901-1 (Práctica Profesional I) Fueron los más recordados por el
practicante ya que gracias a las buenas prácticas de programación aprendidas y, a la
experiencia laboral de la Practica I, el trabajo fue en general de mayor calidad.

Por otro lado, herramientas adquiridas en cursos como MA1002-1 (Cálculo Diferencial e
Integral) y, CC3201-1 (Bases de Datos), ayudaron al practicante a entender las tareas
particulares dados en cada proyecto, ya que por un lado el trabajo de las series de tiempo
involucra un alto componente matemático y, por el lado del gobierno de datos, todos los
archivos manipulados eran scripts para crear tablas en SQL.

7.3. Aprendizajes
Respecto de los aprendizajes, el principal fue uno adquirido en el equipo del gobierno
de datos. Debido a las múltiples iteraciones en el entregable final, fue evidente que se
requirió de un levantamiento de requisitos más estricto de parte del practicante, hubieron
múltiples problemas que se a pesar de no ser graves, requirieron de trabajo extra que pudo
ser fácilmente evadido.

Otro aprendizaje importante fue respecto a los lenguajes de programación. Para el caso
del proyecto del MTT, se utilizó python debido a la familiaridad del practicante con este
lenguaje y, debido a que en la investigación se evidenció que existı́an herramientas para
poder realizar el trabajo. Ya más avanzada la practica R demostró finalmente ser la mejor
herramienta a pesar de todo.

Uno de los motivos por los cuales se escogió python fue para enfocar los esfuerzos de la
investigación (solo series de tiempo y no eso más un lenguaje de programación nuevo), el
practicante reconoce que al momento de aprender R para realizar unas pruebas rápidas,
esto no fue una tarea tan difı́cil como pudo haberlo pensado. Lo cual deja como enseñanza

13
Informe de Práctica Felipe Sanhueza C.

ser más abierto a lo que lenguajes poco familiares pueden ofrecer.

Algo más particular, fue el aprendizaje de la librerı́a pandas. Esta fue una de las herra-
mientas más importantes para el manejo de los datos durante la implementación de las
series de tiempos y su uso adecuado fue un aprendizaje importante.

Finalmente, respecto al área de la investigación, se aprendieron mejores técnicas, herra-

mientas y, formas de pensar para encontrar soluciones inteligentes a problemas complejos
relacionados con los datos.

8. Conclusión
En primera instancia respecto al cumplimiento de los objetivos de la práctica, se puede
decir que estos fueron exitosos. A pesar de que los modelos no dieron resultados comple-
tamente precisos, los objetivos de este trabajo eran ver si con una proyección con series
de tiempo se obtenı́an resultados coherentes y relevantes(lo cual se obtuvo), el ajuste de
parámetros es algo que realizara el IMFD en base al trabajo del practicante y a futuro.

Las herramientas matemáticas entregadas por la carrera fueron puestas a prueba en todo
momento por la práctica y fue un gran recordatorio de las capacidades que el programador
tiene al manejar un nivel matemático alto.

El ambiente laboral fue grato y se llegó a relacionar con muchas personas a pesar de las
condiciones (pandemia). Las reuniones diarias, los workshops semanales y las conversa-
ciones ocasionales con el equipo de trabajo permitió un ambiente psicológico de plena
confianza donde ideas podı́an ser compartidas sin miedo y se encontraba siempre apoyo
cuando se requerı́a.

En conclusión, se comenzó esta práctica con altas expectativas y todas estas se cumplieron,
presentó un desafı́o tanto matemático como computacional y, se aprendió mucho del ámbito
laboral empresarial de la computación.

14