planificación del trabajo final de carrera

Plan de Proyecto del Trabajo Final de Carrera

de Especialización de Internet de las Cosas

Ciro Edgardo Romero

Smart Traceability

Autor

Ciro Edgardo Romero

Director del trabajo

Mg. Ing. Carlos Moisés Fontela (FIUBA)

Jurado propuesto para el trabajo

- Esp. Ing. Pablo Ariel Briff (FIUBA)- Esp. Ing. Iván Andrés León (filiación)- Esp. Ing. Matías Álvarez (filiación)

Este plan de trabajo ha sido realizado en el marco de la asignatura Gestión de

Proyectos entre junio del año 2021 y febrero del año 2021.

Página 1 de 30



Ciro Edgardo Romero

Tabla de contenido

Registros de cambios 3

Acta de Constitución del Proyecto 4

Descripción técnica-conceptual del Proyecto a realizar 5

Identificación y análisis de los interesados 8

1. Propósito del proyecto 9

2. Alcance del proyecto 9

3. Supuestos del proyecto 10

4. Requerimientos 10

5. Entregables principales del proyecto 11

6. Desglose del trabajo en tareas 11

7. Diagrama de Activity On Node 13

8. Diagrama de Gantt 16

9. Matriz de uso de recursos de materiales 19

10. Presupuesto detallado del proyecto 21

11. Matriz de asignación de responsabilidades 22

12. Gestión de riesgos 23

13. Gestión de la calidad 25

14. Comunicación del proyecto 28

15. Gestión de Compras 28

16. Seguimiento y control 29

17. Procesos de cierre 30

Página 2 de 30



Ciro Edgardo Romero

Registros de cambios

Revisión Detalle de los cambios realizados Fecha

1.0 Creación del documento. 27/04/2020

1.1 Modificación de redacción y correcciones. 05/05/2020

1.2 Se agregan gráficos de planificación y sugerencias. 10/05/2020

1.3 Se completa información del documento. 18/05/2020

1.4 Correcciones y sugerencias. 21/05/2020

Página 3 de 30



Ciro Edgardo Romero

Acta de Constitución del Proyecto

Buenos Aires, 28 de Mayo de 2020

Por medio de la presente se acuerda con el Sr. Ciro Edgardo Romero que su Trabajo Final de la

Carrera de Especialización en Internet de las Cosas se titulará “Smart Traceability” y consistirá

esencialmente en el desarrollo de un prototipo alfa que controle las condiciones en las que se encuentra

un producto transportado. Tendrá un presupuesto preliminar estimado de 600 horas de trabajo y $15000,

con fecha de inicio lunes 1 de junio de 2020 y fecha de presentación pública lunes 5 de mayo de 2021.

Se adjunta a esta acta la planificación inicial.

Ariel Lutenberg Franco Boette

Director de la CESE-FIUBA C y S Informatica S.A.

Carlos Moisés Fontela

Director del Trabajo Final

Nombre y Apellido (1) Nombre y Apellido (2)

Jurado del Trabajo Final Jurado del Trabajo Final

Nombre y Apellido (3)

Jurado del Trabajo Final

Página 4 de 30



Ciro Edgardo Romero

Descripción técnica-conceptual del Proyecto a realizar

Según la Real Academia Española, la trazabilidad es por definición la “posibilidad de identificar el origen y

las diferentes etapas de un proceso de producción y distribución de bienes de consumo”. En el ámbito

particular de la trazabilidad logística se lleva a cabo el seguimiento de las mercaderías desde su lugar de

producción hasta su destino final. Este seguimiento busca identificar el origen y chequear las distintas

etapas por las que dichas mercaderías pasaron a lo largo del proceso de distribución y hasta llegar al

consumidor final.

Durante cada una de las etapas antes mencionadas, el producto es trasladado y manipulado de diferentes

formas, lo que puede provocar que esté sometido a diferentes ambientes durante la cadena de

distribución. Estos cambios de ambiente, si son demasiado bruscos, pueden tener efectos negativos sobre

la mercadería trasladada. Por ello, se debe tener confianza en las personas involucradas, las metodologías

aplicadas y los sistemas que se utilizan para registrar la información durante la distribución.

Es sabido que actualmente durante el proceso de distribución, diferentes personas consultan y generan

información sobre el estado del producto. Sin embargo, muchas veces la información es registrada de

manera inexacta o incluso equívoca, debido al margen de error humano. El objetivo de este proyecto es

aplicar al proceso de transporte de productos, la confianza que brindan los ambientes de condiciones

controladas y la tecnología de registros de transacciones distribuidas.

El proyecto contaría con un recipiente de condiciones constantemente evaluadas mediante sensores, que

garantice el estado óptimo de la mercadería transportada y su ubicación geográfica casi en tiempo real.

Además, para visualizar la evolución del estado de los productos y el ambiente donde viajaron, se propone

la utilización de una aplicación web con soporte blockchain. Mediante la implementación de esta, se

lograría aumentar la fiabilidad del proceso y la confianza de los usuarios de la cadena de distribución

logística. Esto sucedería gracias a que por las características particulares de blockchain la información se

hace inmutable y no puede ser modificada una vez que se ingresa en el registro de transacciones.

En la figura 1 se presenta un diagrama con los diferentes componentes que interactuarían en el sistema

para lograr el seguimiento de un producto a través de un flujo de distribución.

Página 5 de 30



Ciro Edgardo Romero

Fig. 1 relación de componentes.

El sistema constaría de tres partes bien definidas. En primer lugar se encontraría el contenedor que

transportaría la mercadería, Controlled container. Dicho contenedor sería un envase térmico que contaría

con sensores de presión, humedad y temperatura dispuestos para monitorear las condiciones del espacio

donde se colocaría el producto y las condiciones atmosféricas externas. Por otro lado, el contenedor

también contaría con un giróscopo y un acelerómetro, para registrar todas las posiciones en las que se

encontró durante su transporte. Por último, el contenedor contaría con un pulsador que serviría para

chequear si este se hubiera abierto en algún momento. Toda esta información quedaría guardada de

manera local en un registro temporal de memoria y, en paralelo, la información sería enviada a través de

Internet a una aplicación web utilizando un módulo GSM/GPRS, con el agregado de datos de posición,

fecha y hora.

En la figura 2 se observa una primera descripción para las disposiciones de los diferentes elementos del

Controlled container.

Página 6 de 30



Ciro Edgardo Romero

Fig. 2 gráfico de dispersión de elementos del prototipo

Una vez que los sensores hayan recolectado la información, esta sería recibida por la segunda parte del

sistema: una aplicación web a la que llamaremos Application view. Este elemento, consta de tres

componentes:

Un back-end, encargado de recibir la información provista y almacenarla en la base de datos.

Una API para realizar la comunicación entre el back-end y el registro de transacciones distribuidas

(una blockchain semi permisionada).

Un front-end donde se visualiza la evolución del recorrido del contenedor (allí el usuario podría

corroborar que el transporte se hizo de manera correcta).

En la figura 3 vemos el camino de haría información, a través de los diferentes elementos del sistema.

Página 7 de 30



Ciro Edgardo Romero

Fig. 3 flujo de datos

Las limitaciones de cada elemento quedan detalladas en la sección de alcance.

Identificación y análisis de los interesados

Rol Nombre y Apellido Departamento Puesto

Auspiciante Norberto Caniggia Dirección General Presidente

Cliente Franco Boette Desarrollo de Negocios Director de Negocios

Responsable Ciro Edgardo Romero Investigación, Desarrollo e

Innovación

Referente técnico en

tecnologías IOT

Colaboradores Alejandro Elustondo Investigación, Desarrollo e

Innovación

Referente técnico en

tecnologías DLT

Orientadores Carlos Fontela Investigación, Desarrollo e

Innovación

Gerente

Página 8 de 30



Ciro Edgardo Romero

Usuario Final Usuarios de logística de

productos de consumo

humano (ej: bebida,

alimentos, medicamentos)

- -

1. Propósito del proyecto

El propósito de este proyecto es generar el prototipo de un sistema de seguimiento, capaz de brindar

información continua y confiable sobre las condiciones a las que se ve sometido un producto durante el

proceso de distribución.

2. Alcance del proyecto

Desarrollar un prototipo capaz de funcionar como contenedor de productos de consumo humano, que

integre sensores de posición, apertura, presión, humedad y temperatura. El desarrollo contará con una

batería recargable y detectará por sí mismo cuando un producto sea depositado en su interior, tomando

ese evento como referencia para el inicio de un traslado. Todas las mediciones recolectadas, estarán

asociadas a ese viaje que se dará por finalizado cuando el producto sea retirado.

Cabe aclarar que el prototipo será capaz de conectarse a través de internet para enviar los datos

recolectados por los sensores a un servidor, en tiempo real. La información enviada al servidor, será

guardada en una base de datos y esta será visualizada en una plataforma, la cual mostrará los detalles de

las mediciones realizadas durante cada viaje.

Toda la información quedará inmutada a través de una operación criptográfica que generará

identificadores únicos e irrepetibles a partir de la información dada (conocido como hash). Dicha

información impactará en una base de datos distribuida semi permisionada, a través de una interfaz de

programación o API.

Sólo se contempla la situación de un único dispositivo generando información en la plataforma, por lo que

la autenticación de acceso será única para el prototipo.

El proyecto no contempla cumplir con especificaciones detalladas en normas o certificaciones de ANMAT,

para el transporte de productos de consumo humano.

Página 9 de 30



Ciro Edgardo Romero

3. Supuestos del proyecto

Para el desarrollo del proyecto se establecen las siguientes suposiciones:

● Se dispondrá del horario laboral para la realización de los diferentes aspectos del proyecto.

● Se utilizarán sólo los materiales necesarios para el armado de un prototipo.

● Se dispondrá de licencias y certificados para el uso de blockchains semi permisionadas.

● El tiempo establecido para el desarrollo de las tareas será aprovechado de forma óptima.

4. Requerimientos

1. Requerimientos del prototipo de contenedor

1.1. Poseer un contenedor térmico, capaz de incorporar sensores

1.2. Medir la presión en un rango de 300 a 1100 hPa (resolución 0,16 Pa)

1.3. Medir la temperatura en un rango de -40 °C a 85 °C (resolución 0,01°C)

1.4. Medir la humedad relativa en un rango del 0-100% (precisión )± 3°1.5. Medir la posición utilizando un acelerómetro y magnetómetro para determinar los 9 ejes

de rotación (guiñada cabeceo y alabeo).

1.6. Debe poder guardar los datos de manera local

1.7. Poseer tecnología GSM/GPRS para comunicar por internet mobile

1.8. Debe sincronizar el reloj interno con un servicio de sincronización de internet

1.9. Debe poseer la lógica para enviar a los datos a los servicios del sistema

2. Requerimientos de la capa de servicios (Back-end)

2.1. Debe poseer la interfaz necesaria (API) para recibir los datos

2.2. Debe persistir los datos en una base de datos

2.3. Debe comunicarse con una DLT para inmutar los datos

2.4. Debe poseer una interfaz (API) para integrarse con el Front-end

3. Requerimientos de la capa de presentación (Front-end)

3.1. Debe mostrar los datos recolectados en un histórico

3.2. Debe poder mostrar los viajes hechos por el contenedor

3.3. Debe poder comunicar con el Back-end

4. Requerimientos de la capa de negocio (lógica)

4.1. Debe poder permitir al usuario informar del principio y el final de un viaje de transporte

de mercadería

4.2. La información debe poder describir la evolución de las variables en un viaje

Página 10 de 30



Ciro Edgardo Romero

5. Entregables principales del proyecto

● Manual del usuario

● Planos esquemáticos de conexión entre componentes

● Prototipo funcional

● Imagen para desplegar aplicación con:

○ Servicios para recepción de datos

○ Plataforma para visualización de datos

● Informe final

● Presentación

6. Desglose del trabajo en tareas

Estimación de tareas

TAREAS HORAS

1 Armado entorno de desarrollo y adquisiciones previas 14

1.1 Preparación de herramientas 5

1.2 Compra (virtual) de componentes 1

1.3 Configuración de servidor 5

1.4 Armado de base de datos 3

2 Desarrollo de prototipo 205

2.1 Preparación para la instalación de sensores 6

2.2 Preparación para la instalación de controladores 6

2.3 Preparación para la instalación de batería recargable 6

2.4 Conexión de componentes 3

2.5 Modelado de arquitectura 10

2.6 Familiarización de firmware 10

2.7 Medición de P. H. y T. int. 12

2.8 Medición de P. H. y T. ext. 12

2.9 Programa del giroscopio y magnetómetro 16

2.10 Programa del módulo GSM/GPRS 32

2.11 Sincronización NTP 6

Página 11 de 30



Ciro Edgardo Romero

2.12 Integración de componentes 16

2.13 Programa de manipulación de datos 16

2.14 Lógica de comunicación remota 23

2.15 Pruebas unitarias de componentes 24

2.16 Pruebas de integración 7

3 Desarrollo de Back-end 112


3.2 Servicio de recepción de información 24

3.3 Manipulador de datos 16

3.4 Integración con base de datos del sistema 2

3.5 Integración con DLT (externo) 8

3.6 Socket de comunicación 12


3.8 Pruebas unitarias 18


4 Desarrollo de Front-end 101

4.1 Maquetado de presentación 8


4.3 Recuperación de datos de DLT 18

4.4 Funcionalidad de visualización de datos 16

4.5 Paginado 8

4.6 Integración de elementos 12



5 Pruebas de validación 80

5.1 Pruebas de integración de elementos 40

5.2 Ensayos de funcionamiento productivo 40

6 Documentación 60

6.1 Preparación del informe de avance 20

6.2 Escritura del manual de usuario 20

6.3 Memoria técnica 20

Página 12 de 30



Ciro Edgardo Romero

7 Presentación final 40

7.1 Preparación de diapositivas para exposicion 8

7.2 Preparación del informe final 32

TOTAL 612

7. Diagrama de Activity On NodeLa interconexión entre los gráficos se da a través de los círculos numerados de color negro.

Página 13 de 30



Ciro Edgardo Romero

Página 14 de 30



Ciro Edgardo Romero

Las unidades de tiempo están expresadas en horas.

Página 15 de 30



Ciro Edgardo Romero

8. Diagrama de Gantt

Cronograma establecido entre el 01/06/2020 al 26/06/2020.

Página 16 de 30



Ciro Edgardo Romero


Página 17 de 30



Ciro Edgardo Romero


Página 18 de 30



Ciro Edgardo Romero

9. Matriz de uso de recursos de materiales

CódigoWBS

Nombre de la tarea

Materiales necesarios

PC ServidorContenedor

térmicoControlador

Kit de sensoresy batería

Electrónicamisceláneos

1 Armado de ambiente de desarrollo y adquisiciones previas

1.1 Preparación de herramientas 5

1.2Compra (virtual) decomponentes

1

1.3 Configuración de servidor 5

1.4 Armado de base de datos 2 1

2 Desarrollo de prototipo

2.1Preparación para la instalaciónde sensores

6

2.2Preparación para la instalaciónde controladores

6

2.3Preparación para la instalaciónde batería recargable

6

2.4 Conexión de componentes 3


2.6 Familiarización de firmware 5 5

2.7 Medición de P. H. y T. int. 6 6

2.8 Medición de P. H. y T. ext. 6 6

2.9Programa del giroscopio ymagnetómetro

8 8

2.10Programa del móduloGSM/GPRS

16 16

2.11 Sincronización NTP 3 3

2.12 Integración de componentes 8 8

2.13Programa de manipulación dedatos

8 8

2.14 Lógica de comunicación remota 11,5 11,5

2.15Pruebas unitarias decomponentes

12 12

2.16 Pruebas de integración 3,5 3,5

3 Desarrollo de Back-end


Página 19 de 30



Ciro Edgardo Romero

3.2Servicio de recepción deinformación

24

3.3 Manipulador de datos 16

3.4Integración con base de datosdel sistema

1 1

3.5 Integración con DLT (externo) 8





4 Desarrollo de Front-end

4.1 Maquetado de presentación 8


4.3 Recuperación de datos de DLT 18

4.4Funcionalidad de visualizaciónde datos

16

4.5 Paginado 8

4.6 Integración de elementos 12



5 Pruebas de validación

5.1Pruebas de integración deelementos

10 10 20

5.2Ensayos de funcionamientoproductivo

10 10 20

6 Documentación

6.1Preparación del informe deavance

20

6.2 Escritura del manual de usuario 20

6.3 Memoria técnica 20

7 Presentación final

7.1Preparación de diapositivas paraexposición

8

7.2 Preparación del informe final 32

Página 20 de 30



Ciro Edgardo Romero

10. Presupuesto detallado del proyecto

Tipo de costos Detalle Cantidad Costo

Directos Horas de trabajo ($350/h) 612 $214.200,00

Indirectos 30% del trabajo indirecto - $64.260,00

Materiales

TTGO T-Call (Placa de desarrollo) 1 $150,00

BME280 (Sensor de P,H y T) 2 $1.300,00

MPU6050 (Sensor de posición) 1 $280,00

GY-9960 (Sensor de movimiento) 1 $481,00

TTP223 (Pulsador capacitivo) 1 $60,00

Mini interruptor 1 $150,00

Total $280.881,00

Página 21 de 30



Ciro Edgardo Romero

11. Matriz de asignación de responsabilidades

Todas las tareas son únicamente responsabilidad primaria del responsable del proyecto, con excepción delas detalladas en la siguiente tabla.

Código

WBSTítulo de la tarea

Auspiciante

(NC)

Cliente

(FB)

Responsable

(CER)

Colaboradores

(AE)

Orientadores

(CF)

1.2 Compra (virtual) de componentes C P I

2.11 Sincronización NTP P C

2.12 Integración de componentes P C

2.14 Lógica de comunicación remota P C

2.16 Pruebas de integración I I P

3.5 Integración con DLT (externo) P S

3.9 Pruebas de integración I A P

4.3 Recuperación de datos de DLT P C

4.6 Integración de elementos I P C

4.8 Pruebas de integración I A P

5.1Pruebas de integración de

elementosI A P S

5.2Ensayos de funcionamiento

productivoI A P S C

6.1 Preparación del informe de avance I P I

6.2 Escritura del manual de usuario I I P C I

6.3 Memoria técnica I I P C

7.1Preparación de diapositivas para

exposicionP C

7.2 Preparación del informe final I I P C/A

Referencias: P = Responsabilidad PrimariaS = Responsabilidad SecundariaA = AprobaciónI = InformadoC = Consultado

Página 22 de 30



Ciro Edgardo Romero

12. Gestión de riesgosEn la siguiente sección se identifican y se analizan los riesgos de el proyecto, de modo de podermitigarlos mediante un plan de contingencia.Se establece un rango de severidad y ocurrencia de 1 a 5, referenciado entre paréntesis.

a) Identificación de los riesgos.1. Mala calidad de sensores para el prototipo

a. Severidad (3): un mal rendimiento en los sensores puede dar información imprecisa oincluso errónea, a la plataforma.

b. Probabilidad de Ocurrencia (3): la variedad de materiales está limitada a la disponibilidadde comercios que tengan venta online, a público general. Además, los costos no tienenque exceder el presupuesto.

2. Servicio GPRS insuficiente para el volumen de datos a transmitira. Severidad (3): si el tamaño de los datos es mayor a la capacidad de transmisión del

módulo de internet, provocaría que el sistema no tenga propósito.b. Probabilidad de Ocurrencia (2): la cantidad de datos que se pueden disponer está limitada

por el proveedor de servicios de Internet móvil. También puede tener un impacto en elpresupuesto, ya que el servicio sería un costo adicional.

3. Mediciones insuficientes para establecer un parámetro de seguimientoa. Severidad (4): si la capacidad del módulo para actualizar la ubicación es muy espaciada, no

se podría hacer un buen seguimiento del contenedor.b. Probabilidad de Ocurrencia (2): la velocidad teórica de transmisión de datos del módulo

GPRS es baja, pero suele tener buen rendimiento en ciudad.4. Roturas del prototipo

a. Severidad (4): este riesgo puede retrasar varias de las tareas principales hasta su solución.b. Probabilidad de Ocurrencia (2): todo elemento puede romperse debido a fatiga y

accidentes.5. No disponer del tiempo suficiente para terminar el proyecto

a. Severidad (2): provocaría que el proyecto no esté terminado antes de la fecha de entrega.b. Probabilidad de Ocurrencia (3): el responsable es el único encargado de desarrollar casi

todas las tareas. A demás, posee una jornada laboral y una cursada que hacen que eltiempo sea dividido.

b) Tabla de gestión de riesgos (El RPN se calcula como RPN=Severidad * Ocurrencia).Se establece un rango de severidad y ocurrencia de 1 a 5

Riesgo Severidad Ocurrencia RPN Severidad* Ocurrencia* RPN*

1 3 3 9 3 1 3

2 3 2 6 - - 6

3 4 2 8 3 2 6

4 4 2 8 2 2 4

5 2 3 6 - - 6

Página 23 de 30



Ciro Edgardo Romero

Criterio adoptado:- Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 7.

Nota:- Los valores marcados con (*) en la tabla corresponden luego de haber aplicado la mitigación.

c) Plan de mitigación de los riesgos que originalmente excedían el PRN máximo establecido:

1. Mala calidad de sensores para el prototipoa. Plan de mitigación: consultar e interiorizarse sobre los productos disponibles en el

mercado para realizar la mejor compra. Buscar diferentes fuentes sobre experiencias concada producto antes de realizar las compras.

b. Severidad (3): la severidad se mantiene, por desconocimiento de los productosdisponibles.

c. Probabilidad de Ocurrencia (1): con una investigación exhaustiva, sin apurarse en realizarcompras, se reducen las probabilidades de ocurrencia.

3. Mediciones insuficientes para establecer un parámetro de seguimientoa. Plan de mitigación: realizar pruebas con diferentes antenas para mejorar la transmisión de

datos del módulo GSM/GPRS. En paralelo, se estudiará la posibilidad de optimizar el usodel ancho de banda.

b. Severidad (3): con la optimización en la comunicación, se reduce la severidad. Noobstante, se reduce poco por no tener información precisa sobre detalles técnicos de lasantenas, ni experiencia previa en optimización de uso del ancho de banda.

c. Probabilidad de Ocurrencia (2): optimizando los recursos de comunicación se reduce laprobabilidad de tener problemas con la misma.

4. Pérdida o rotura del prototipoa. Plan de mitigación: Se planea construir el prototipo conectando los elementos de tal

forma que se pueda reemplazar cada parte fácilmente.b. Severidad (2): al tener cada elemento “plug and play”, la falla o rotura de cada uno puede

solucionarse reemplazando solo la parte que muestre problemas.c. Probabilidad de Ocurrencia (2): la probabilidad de ocurrencia se mantiene porque, como

se mencionó antes, todo elemento puede romperse debido a fatiga y accidentes.

Página 24 de 30



Ciro Edgardo Romero

13. Gestión de la calidadPara cada uno de los requerimientos del proyecto se enuncia el procedimiento de verificación yvalidación.

Requerimientos asociados al prototipo

1.1 Poseer un contenedor térmico, capaz de incorporar sensores

● Verificación: se adaptará una conservadora de tergopol, para instalar los sensores, el controlador

y la batería.

● Validación: se hará un informe con el envase comprado, las propiedades del mismo, más un

registro fotográfico de las modificaciones que se realicen para adaptarlo.

1.2 Medir la presión en un rango de 300 a 1100 hPa (resolución 0,16 Pa)

● Verificación: se verificará que el controlador se conecte correctamente con el sensor. Se incluirá

una hoja de datos del sensor seleccionado.

● Validación: se realizarán pruebas unitarias de medición, registrando los resultados.

1.3 Medir la temperatura en un rango de -40 °C a 85 °C (resolución 0,01°C)




1.4 Medir la humedad relativa en un rango del 0-100% (precisión )± 3°




1.5 Medir la posición utilizando un acelerómetro y magnetómetro para determinar los 9 ejes de

rotación (guiñada cabeceo y alabeo).

● Verificación: se verificará que el controlador se conecte correctamente con el módulo. Se incluirá


● Validación: se realizarán pruebas unitarias, controlando las diferentes mediciones que realiza el

sensor según las posiciones.

1.6 Debe poder guardar los datos de manera local.

● Verificación: se analizarán diferentes métodos para guardar datos, teniendo presente el

controlador seleccionado y los módulos disponibles.

● Validación: se harán pruebas unitarias para validar que se guarde la información necesaria para

cubrir el requerimiento.

Página 25 de 30



Ciro Edgardo Romero

1.7 Poseer tecnología GSM/GPRS para comunicar por internet mobile.

● Verificación: se analizaran diferentes opciones de mercado para incluir un módulo GSM/GPRS que

sirva para el propósito del proyecto. Se incluirá la documentación técnica.

● Validación: se realizará una conexión a internet, completamente desde el módulo GSM/GPRS para

validar que no requiere otro tipo de conexión para transmitir información.

1.8 Debe sincronizar el reloj interno con un servicio de sincronización de internet.

● Verificación: se verificará incluir en el código del controlador la lógica para que se conecte

correctamente con un servicio NTP.

● Validación: Se realizará la prueba de chequear la hora antes y después de conectarse.

1.9 Debe poseer la lógica para enviar a los datos a los servicios del sistema.

● Verificación: se incluirá en el código del prototipo los parámetros y la lógica para enviar datos a los

servicios del sistema. Se documentarán las pruebas necesarias para verificar el correcto

funcionamiento.

● Validación: se enviará información de prueba y se chequeará que llegue correctamente. Se

realizará un informe para reflejar la evidencia de las pruebas exitosas.

Requerimientos de la capa de servicios (Back-end)

2.1 Debe poseer la interfaz necesaria (API) para enviar los datos.

● Verificación: se verificará incluir en la plataforma un servicio exclusivamente dedicado a recibir

información desde el controlador.

● Validación: se enviará información de prueba y se chequeará que sea recibida correctamente. Se

adjuntará al informe mencionado en el requerimiento 1.9.

2.2 Debe persistir los datos en una base de datos.

● Verificación: se integrará un base de datos a la plataforma. Se verificará que la comunicación se

establezca, enviando datos de prueba.

● Validación: Se realizarán pruebas de consultas, después de realizar pruebas de comunicar entre

elementos, para chequear la persistencia de los datos.

2.3 Debe comunicarse con una DLT para inmutar los datos.

● Verificación: se incluirá en la plataforma un servicio exclusivamente dedicado a enviar información

ingresada a la plataforma. Se verificará de chequear todos los mensaje de comunicación exitosa.

● Validación: se enviará información de prueba, desde el prototipo a la plataforma, y se chequeara

el hash (identificadores únicos) que resulta del proceso. Se utilizará un buscador asociado a la DLT

para corroborar que el hash impactado en la base de registro sea el mismo de obtenido en la

prueba.

Página 26 de 30



Ciro Edgardo Romero

2.4 Debe poseer una interfaz (API) para integrarse con el Front-end.

● Verificación: se verificará incluir servicios de web sockets en la plataforma.

● Validación: se harán pruebas de visualización de la información desde el Front-end.

Requerimientos de la capa de presentación (Front-end)

3.1 Debe mostrar los datos recolectados en un histórico

● Verificación: se verificará que los datos sean visualizados en un elemento web del tipo gráfico

(histograma o lineal), desde la plataforma.

● Validación: se enviará un conjunto de datos, en un periodo de tiempo, desde el prototipo a la

plataforma. Se validará que los datos visualizados coincidan en el periodo de tiempo de la prueba.

3.2 Debe poder mostrar viaje hecho por el contenedor

● Verificación: se verificará que los datos sean visualizados en un mapa, desde la plataforma. Se

realizarán pruebas unitarias.

● Validación: se enviaran datos desde el prototipo a la plataforma, mientras el primero se encuentre

en movimiento. Se validará que los datos visualizados coincidan con un mapa de referencia.

3.3 Debe poder comunicar con el Back-end

● Verificación: se verificará incluir servicios de web sockets en la plataforma.

● Validación: se harán pruebas unitarias de visualización de la información desde el Back-end.

Requerimientos de la capa de negocio (lógica)

4.1 Debe poder permitir al usuario informar del principio y el final de un viaje de transporte de

mercadería.

● Verificación: se verificará que el prototipo reconozca cuando se coloque y se quite un producto en

su interior. Estos eventos, serán referenciados como un inicio y fin de un viaje. Se documentarán

las pruebas necesarias para verificar el correcto funcionamiento.

● Validación: se realizará un viaje desde un punto “A” a un punto “B”, y se validará que tanto la

trayectoria como las acciones de agregar y quitar producto, sean visualizadas. Se realizará una

demostración a los colaboradores y el cliente.

4.2 La información debe poder describir la evolución de las variables en un viaje.

● Verificación: se verificará que la plataforma muestre la trayectoria de un viaje realizado por el

prototipo, en un mapa interactivo.

● Validación: se complementa con la validación del requerimiento 4.1.

Página 27 de 30



Ciro Edgardo Romero

14. Comunicación del proyectoEl plan de comunicación del proyecto es el siguiente:

PLAN DE COMUNICACIÓN DEL PROYECTO

¿Qué

comunicar?Audiencia Propósito Frecuencia

Método de

comunicac.Responsable

Avance del

proyecto

Director del

trabajo

Mantener

informado del

estado del

proyecto

Mensual Reunión, e-mailCiro Edgardo

Romero

Avance del

proyecto

Cliente,

Auspiciante

Mostrar

evolución del

sistema

Bimestral e-mailCiro Edgardo

Romero

Necesidades

técnicasColaboradores

Coordinar

esfuerzosOn demand Reunión

Ciro Edgardo

Romero

Memoria técnicaJurado de

proyecto final

Cumplir plazos

de entrega del

proyecto

Única vez e-mailCiro Edgardo

Romero

Trabajo

terminadoPúblico general

Defender

proyecto finalÚnica vez Reunión

Ciro Edgardo

Romero

15. Gestión de ComprasPara el proyecto se tiene previsto la compra de los materiales detallados en el presupuesto del proyecto.Todos los materiales necesarios serán comprados por el responsable del proyecto, sin requerir procesoscomplejos de aprobación.

La infraestructura y las herramientas necesarias serán provistas por la empresa C&S Informática, comosponsor del proyecto. Si fuera necesario realizar alguna compra de herramientas, se seguirá el proceso decompra de la empresa, completando el formulario PR_EF_Compra, y siguiendo el flujo de Solicitud decompra.

Página 28 de 30



Ciro Edgardo Romero

16. Seguimiento y control

SEGUIMIENTO DE AVANCE

WBS Nombre de la tareaIndicador de

avance

Frecuencia de

reporte

Responsable

de

seguimiento

Persona a

ser

informada

Método de

comunic.

1

Armado entorno de

desarrollo y

adquisiciones previas

Minuta Única vezCiro Edgardo

RomeroDirector E-mail

2 Desarrollo de prototipoInforme con

checklistÚnica vez

Ciro Edgardo


3 Desarrollo de Back-endInforme con

checklistÚnica vez

Ciro Edgardo


4 Desarrollo de Front-endInforme con

checklistÚnica vez

Ciro Edgardo


5 Pruebas de validaciónDemostración

con informeÚnica vez

Ciro Edgardo

RomeroDirector

E-mail y

presentación

en vivo

6 Documentación

Plan de trabajo,

Informe de

avance, Memoria

técnica

Única vezCiro Edgardo

Romero

Autoridades

del posgrado,

Director,

Cliente

E-mail

7 Presentación finalInforme final,

presentaciónÚnica vez

Ciro Edgardo

Romero

Autoridadesdelposgrado,Director,Cliente,Auspiciante

E-mail y

presentación

en vivo

Página 29 de 30



Ciro Edgardo Romero

17. Procesos de cierre

Establecer las pautas de trabajo para realizar una reunión final de evaluación del proyecto, tal quecontemple las siguientes actividades:

● Pautas de trabajo que se seguirán para analizar si se respetó el Plan de Proyecto original:○ Responsable: Ciro Edgardo Romero○ Procedimiento:

■ Se revisará si se cumplieron con todos los requerimientos.■ Se analizará si fue correcto el plan de mitigación de riesgos o hubo riesgos no

contemplados.■ Las conclusiones serán registradas en la memoria del trabajo.

● Identificación de las técnicas y procedimientos útiles e inútiles que se utilizaron, y los problemasque surgieron y cómo se solucionaron:

○ Responsable: Ciro Edgardo Romero○ Procedimiento:

■ Se evaluará si la arquitectura planteada en el sistema fue la correcta.■ Se evaluará si la tecnología utilizada fue la acertada.■ Se analizaron los problemas que surgieron durante el proyecto y cómo se

solucionaron.■ Se tomará registro en la memoria del trabajo.

● Indicar quién organizará el acto de agradecimiento a todos los interesados, y en especial al equipode trabajo y colaboradores:

○ Responsable: Ciro Edgardo Romero○ Procedimiento:

■ Una vez finalizado el proyecto, se agradecerá formalmente a todos loscolaboradores y se informará a los interesados la finalización del mismo.

■ En la memoria del proyecto se escribirá un agradecimiento al auspiciante y a loscolaboradores.

Página 30 de 30

planificación del trabajo final de carrera

Documents