Sistema autónomo para medición de nivel de ruido en el...

Plan de Proyecto del Trabajo Final de la

Maestría de Sistemas Embebidos

Esp. Ing. Patricio Bos

Sistema autónomo para medición de nivel de ruido en el mar

Autor


Director del trabajo

Dr. Ing. Ariel Lutenberg (FIUBA)

Página 1 de 22




Tabla de contenido

Acta de Constitución del Proyecto 3

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

Identificación y análisis de los interesados 6

1. Propósito del proyecto 7

2. Alcance del proyecto 7

3. Supuestos del proyecto 7

4. Requerimientos 8

6. Desglose del trabajo en tareas 9

7. Diagrama de Activity On Node 10

8. Diagrama de Gantt 11

9. Matriz de uso de recursos de materiales 13

10. Presupuesto detallado del proyecto 14

11. Matriz de asignación de responsabilidades 14

12. Gestión de riesgos 16

13. Gestión de la calidad 18

14. Comunicación del proyecto 19

15. Gestión de Compras 20

16. Seguimiento y control 20

17. Procesos de cierre 22

Página 2 de 22




Acta de Constitución del Proyecto

Por medio de la presente se acuerda con el Sr. Patricio Bos que su proyecto final de la Maestría en

Sistemas Embebidos se titulará “Sistema autónomo para medición de nivel de ruido en el mar”, consistirá

esencialmente en el prototipo preliminar de un sistema para la medición in-situ del ruido ambiente submarino y tendrá un presupuesto preliminar estimado de 600 hs de trabajo y $90.000.

Se adjunta a esta acta la planificación inicial.

Ariel Lutenberg Igor Prario

Director de la MSE-FIUBA Jefe de División Acústica Submarina -

Armada Argentina

Ariel Lutenberg

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 3 de 22




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

En el campo de la acústica submarina resulta muy relevante el conocimiento del parámetro SONAR

Nivel de Ruido en el mar (NL: Noise Level), que incluye el Ruido Ambiente propiamente dicho (NLa) y el Ruido Propio (NLp) asociado al sistema de medición. En el caso de escucha pasiva (estudios de impactos ambientales sobre mamíferos marinos a bajas frecuencias o detección subacuática efectuada desde vehículos submarinos), el NL está dominado por el NLa .

Conceptualmente, el Nivel de Ruido en el mar está asociado al ruido de “fondo” (background) remanente en ausencia de toda otra fuente identificable. Es el nivel de energía acústica mínimo que debe tener una señal para ser detectada.

Cabe destacar que el ruido subacuático puede clasificarse esencialmente en tres tipos:

● Ruido Ambiente: comúnmente denominado ruido de fondo, se mide omnidireccionalmente y es originado principalmente por ruido en la superficie marina (debido al viento, oleaje o lluvia), ruido de origen biológico (producido por peces, mamíferos e invertebrados), ruido sísmico o geoacústico natural, ruido de tráfico marítimo (originado por tráfico marítimo distante).

● Ruido Radiado: originado por una fuente específica tal como un buque en particular, plataformas de explotación de petróleo o gas, instalaciones de exploración y perforación, instalaciones de generación eléctrica, etc.

● Ruido Propio: generado por el propio sistema de electrónico de medición de ruido y por la plataforma donde se encuentre instalado.

El conocimiento de valores de NL es fundamental en aplicaciones tales como oceanografía acústica, predicción SONAR, exploración geofísica, comunicación subacuática, ingeniería offshore, entre otras.

Por otra parte, existen muy pocas normas a nivel internacional para la estandarización de la medición in-situ del ruido ambiente subacuático. Si bien en acústica aérea sí existen estándares nacionales e internacionales muy aceptados, estos no pueden extrapolarse fácilmente a la acústica subacuática dadas las diferentes características físicas del fluido en el cual se propaga el sonido, respectivamente.

Actualmente, en el ámbito de la comunidad científica internacional existe una creciente necesidad de medición y monitoreo del ruido subacuático. El interés está parcialmente motivado por un marco regulatorio internacional en lo concerniente al impacto ambiental del ruido subacuático de origen antrópico y principalmente para la evaluación del riesgo en la vida marina.

El objetivo general del proyecto es el desarrollo del prototipo de un Sistema autónomo para la medición in-situ del ruido ambiente submarino para ser instalado en regiones de interés en el mar y con la capacidad de transmitir los datos más relevantes a una estación receptora. Este desarrollo permitirá disponer de series temporales de ruido ambiente submarino durante períodos lo

Página 4 de 22




suficientemente largos como para analizar los resultados mediante modelos teóricos y/o empíricos que contribuyan a incrementar el conocimiento de dicho parámetro, especialmente a nivel local.

Para alcanzar el objetivo general se dispone de un paquete tecnológico compuesto principalmente por un equipo de trabajo multidisciplinario con conocimientos teóricos de los fenómenos físicos subyacentes a la propagación del sonido en el medio submarino, la disponibilidad de bibliografía específica al campo de la acústica submarina y el conocimiento de ingeniería en el campo de los sistemas embebidos.

Se presenta un diagrama en bloques tentativo del sistema propuesto en la figura 1 donde se han agrupado por color los distintos submódulos que conforman una misma área funcional.

Fig. 1 - Diagrama en bloques del sistema

El Trabajo Final de maestría se centrará en realizar una primera iteración del desarrollo de un firmware de control, implementado en una placa CIAA-NXP.

Página 5 de 22




Identificación y análisis de los interesados

Rol Nombre y Apellido Departamento Puesto

Auspiciante Programa PIDDEF Ministerio de Defensa SSIDyPD

Cliente Igor Prario Propagación subacua Jefe de División

Impulsor Silvia Blanc Propagación subacua Jefa de Departamento

Responsable Patricio Bos Propagación subacua Ing. de desarrollo

Colaboradores Mariano Cinquini Propagación subacua Ing. de desarrollo

Equipo Un becario a determinar Propagación subacua Becario PIDDEF

Usuario Final Profesionales del ámbito de Ciencia y Técnica Nacional.

Página 6 de 22




1. Propósito del proyecto

El propósito general del proyecto es el desarrollo del prototipo de un sistema autónomo para la medición in-situ del ruido ambiente submarino para ser instalado en regiones de interés en el mar y con la capacidad de transmitir los datos más relevantes a una estación receptora. Este desarrollo permitirá disponer de series temporales de ruido ambiente submarino durante períodos lo suficientemente largos como para analizar los resultados mediante modelos teóricos y/o empíricos que contribuyan a incrementar el conocimiento de dicho parámetro, especialmente a nivel local.

2. Alcance del proyecto

En particular, para el trabajo de maestría se realizará una primera iteración sobre el ciclo de diseño centrada en la programación del sistema embebido que constituye el núcleo del proyecto general. Se propone desarrollar un firmware multicore de control en una CIAA-NXP que utilice ambos procesadores del microcontrolador LPC4337 y sea capaz de cumplir las siguientes funciones:

● Adquirir datos ambientales de temperatura y velocidad de viento. ● Controlar el sistema mediante una interfaz serie ● Almacenar los datos

En la primera iteración, se contempla la posibilidad de simular algún elemento del sistema según sea necesario para avanzar rápidamente en el diseño del firmware de control y las funciones mencionadas. A los fines prácticos de cumplir los requerimientos de tiempo del trabajo final de maestría, quedarán excluídos del diseño:

● La transmisión de datos a una estación receptora. ● Consideraciones mecánicas del proyecto. ● La gestión de energía. ● La gestión y control del señalamiento reglamentario marítimo. ● La adquisición de señales acústicas.

Según un estudio preliminar, para el registro de señales acústicas resulta necesario una placa de adquisición A/D con características muy específicas en cuanto a frecuencia de muestreo, bits de resolución y figura de ruido, del tipo NI USB-6356 o equivalente. Este tipo de placas poseen driver propietarios cerrados que, en principio, no es posible utilizar con la CIAA-NXP. Por este motivo, la adquisición de señales acústicas también queda excluida del alcance en esta primera iteración.

3. Supuestos del proyecto

Para el desarrollo del presente proyecto se supone que se contará con:

● 1 CIAA-NXP ● 1 Termómetro digital tipo DS18b20 o equivalente ● 1 Anemómetro tipo WindSonic 1405-PK-021 o equivalente ● 1 becario provisto por el programa PIDDEF del Ministerio de Defensa.

Página 7 de 22




4. Requerimientos

1. Requerimientos de documentación:

1.1. Se debe generar un Memoria Técnica con la documentación de ingeniería detallada.

1.2. Se debe generar un documento de casos de prueba.

2. Requerimientos funcionales del sistema:

2.1. El sistema debe adquirir datos de un array de sensores de temperatura a intervalos regulares con un período de adquisición seleccionable.

2.2. El sistema debe adquirir datos de un anemómetro a intervalos regulares con un período de adquisición seleccionable.

2.3. El sistema debe almacenar los datos de temperatura y velocidad de viento adquiridas junto con una marca de tiempo identificatoria en un medio físico no volátil.

2.4. El sistema debe poder operar con dos perfiles de consumo de energía, uno maximizando el desempeño y otro minimizando el consumo de energía.

2.5. El sistema debe contar con una interfaz serie tipo HMI cableada que permita interactuar y realizar operaciones de configuración y mantenimiento.

3. Requerimientos de verificación:

3.1. Se debe generar una matriz de trazabilidad entre la Memoria Técnica y los requerimientos.

3.2. Se debe generar una matriz de trazabilidad entre las pruebas de integración y los requerimientos.

4. Requerimientos de validación:

4.1. Se debe generar una matriz de trazabilidad entre el documento de casos de prueba y los requerimientos.

5. Entregables principales del proyecto

1. Plan de Proyecto del Trabajo Final 2. Informe de Avance 3. Memoria Técnica 4. Documento de casos de prueba

Página 8 de 22




6. Desglose del trabajo en tareas

Al comienzo de cada etapa se indica un subtotal en horas de las tareas que la componen.

1 Documentación y análisis preliminar 100

1.1 Planificación del proyecto 60

1.2 Análisis de bibliografía específica 30

1.3 Definición de casos de prueba 10

2 Diseño e implementación 340

2.1 Inicialización del entorno de trabajo 30

2.2 Definición de arquitectura de firmware 30

2.3 Definición de interfaces y APIs 30

2.4 Implementación de herramientas de testing 30

2.5 Implementación de soporte de HW para testing 10

2.6 Implementación de módulo adquisición 40

2.7 Implementación de módulo de almacenamiento 40

2.8 Implementación de módulo de HMI 40

2.9 Implementación de módulo de control 30

2.10 Integración de submódulos 60

3 Verificación y validación 60

3.1 Pruebas unitarias en submódulos 20

3.3 Pruebas de integración 20

3.5 Pruebas de sistema 20

4 Cierre100

4.1 Elaboración de Memoria Técnica de Trabajo Final 80

4.3 Elaboración de presentación de Trabajo Final 20

TOTAL 600

Página 9 de 22




7. Diagrama de Activity On Node

Los tiempos del diagrama están expresados en horas.

Página 10 de 22




8. Diagrama de Gantt

En el desglose de tareas se indican los hitos del proyecto como elementos de duración 0. Para el diagrama de Gantt se consideró una dedicación parcial promedio de 2 hs durante todos los días hábiles desde el comienzo del trabajo.

Página 11 de 22




Página 12 de 22




9. Matriz de uso de recursos de materiales

Código WBS

Nombre de la tarea

Recursos requeridos (horas)

CIAA-NXP Termómetro digital y Anemómetro

PC de desarrollo

2.1 Inicialización de herramientas de trabajo 10 30

2.4 Implementación de herramientas de testing 10 30

2.5 Implementación de soporte de HW para

testing

10 10

2.6 Implementación de módulo de adquisición 30 30 40

2.7 Implementación de módulo de

almacenamiento

30 40

2.8 Implementación de módulo de interfaz HMI 25 30

2.9 Implementación de módulo de control 30 10 40

2.10 Integración de submódulos 50 10 60

3.1 Pruebas unitarias de submódulos 20 6 20

3.3 Pruebas de integración 20 10 20

3.5 Pruebas de sistema 20 20 20

Página 13 de 22




10. Presupuesto detallado del proyecto

Costos Descripción Cantidad Valor unitario Valor

Directos

Horas de Ingeniería 600 $200 $120.000

CIAA-NXP 1 $7.000 $7.000

Anemómetro 1 $20.000 $20..000

Termómetro Digital 3 $1.000 $3.000

SUBTOTAL $150.000

Indirectos %40 de costos directos $60.000

SUBTOTAL $60.000

TOTAL $210.000

11. Matriz de asignación de responsabilidades

Código WBS Título de la tarea

Listar todos los nombres y apellidos y el rol definidos en el proyecto

Patricio Bos Responsable

Mariano Cinquini

Colaborador

Igor Prario Cliente

Silvia Blanc Impulsor

1.1 Planificación del

proyecto P S I I

1.2

Análisis de

bibliografía

específica

S S P C

1.3 Definición de casos

de prueba P S A I

2.1 Inicialización del

entorno de trabajo P I

2.2

Definición de

arquitectura de

firmware

P S

Página 14 de 22




2.3 Definición de

interfaces y APIs P S

2.4

Implementación de

herramientas de

testing

P S

2.5

Implementación de

soporte de HW para

testing

P S

2.6

Implementación de

módulo de

adquisición

A P

2.7

Implementación de

módulo de

almacenamiento

P A

2.8 Implementación

módulo de HMI P S A I

2.9 Implementación de

módulo de control P S

2.10 Integración de

submódulos P S

3.1 Pruebas unitarias P S I I

3.3 Pruebas de

integración P S I I

3.5 Pruebas de sistema P S A I

4.1 Elaboración

Memoria Técnica P I I I

4.3

Elaboración de

presentación de

Trabajo Final

P I I I

Referencias: P = Responsabilidad Primaria S = Responsabilidad Secundaria A = Aprobación I = Informado C = Consultado

Página 15 de 22




12. Gestión de riesgos

a) Identificación de los riesgos y estimación de sus consecuencias:

1. No contar a tiempo con el anemómetro

● Severidad = 10. No es posible adquirir datos de velocidad de viento

● Probabilidad de ocurrencia = 8. Si bien el anemçometro ya ha sido comprado a un representante local, este debe ser importado y el plazo mínimo de entrega es de 45 días, pudiendo ser más extenso.

2. No contar con drivers para controlar el termómetro digital para trabajar en su de programación a nivel de registros con la CIAA-NXP.

● Severidad = 10. No es posible adquirir datos provenientes del termómetro sin contar con este recurso.

● Probabilidad de ocurrencia = 5. El termómetro pre-seleccionado utiliza una interfaz one-wire. Existen drivers para distintos microcontroladores disponibles en la web pero ninguno específico para su utilización con el microcontrolador LPC4337 de la CIAA-NXP. Sin embargo, existe suficiente documentación para elaborar el driver faltante en caso de ser necesario.

3. No contar con el becario PIDDEF a tiempo para que pueda participar en el proyecto.

● Severidad = 4. Si bien puede ser muy valioso contar con un miembro más en el equipo de trabajo, las tareas han sido calculadas para ser llevadas a cabo sin la colaboración de un becario.

● Probabilidad de ocurrencia = 7. La efectivización del becario depende de la firma de un funcionario del Ministerio de Defensa. Gestiones similares han tenido meses de retraso.

4. Pérdida, robo o destrucción total o parcial de la placa CIAA-NXP y/o el anemómetro

● Severidad = 10. No es posible continuar el proyecto sin contar con alguno de estos recursos.

● Probabilidad de ocurrencia = 2. El equipo de trabajo tiene experiencia en proyectos similares y no hay precedentes de ocurrencia de un riesgo similar.

5. Cancelación del proyecto PIDDEF del Ministerio de Defensa que da soporte a este trabajo.

● Severidad = 7. El trabajo final de maestría se realiza solapado con horas laboral que de no contar con el proyecto PIDDEF asociado, no podrían utilizarse. Asimismo, no se podría contar con los recursos económicos que otorga el Ministerio de Defensa.

● Probabilidad de ocurrencia = 1. Los proyectos PIDDEF se someten a revisión una vez al año y es poco probable que este proyecto en particular se cancele ya que cuenta con una evaluación positiva recomendando su continuidad.

Página 16 de 22




b) Tabla de gestión de riesgos: (El RPN se calcula como RPN=SxO)

Riesgo Severidad Ocurrencia RPN Severidad* Ocurrencia* RPN*

1 10 8 80 4 8 32

2 10 5 50 4 5 20

3 4 7 28

4 10 2 20

5 7 1 7

Criterio adoptado: - Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 50. Se Indica en color rojo los riesgos con RPN mayores o iguales a 50, en amarillo mayores o iguales a 15 y menores a 50 y en verde los menores a 15. - 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. No contar a tiempo con el anemómetro.

Mitigación: Se procederá a utilizar datos simulados para poder continuar el desarrollo del firmware. La implementación del submódulo de adquisición deberá modificarse para este fin y deberá ser retrabajado cuando se disponga del recurso faltante.

● Severidad = 4. Se reduce la severidad ya que se puede avanzar con el proyecto.

● Probabilidad de ocurrencia = 8. No cambia respecto a la evaluación de riesgo sin la acción de mitigación

2. No contar con drivers para controlar el termómetro digital para trabajar en su de programación a nivel de registros con la CIAA-NXP.

Mitigación: Se procederá a evaluar la utilización de otro sensor con drivers disponibles o a desarrollar un driver para el bus de comunicación onewire que utiliza el sensor pre-seleccionado. La planificación de la implementación del submódulo de adquisición deberá modificarse para reflejar el incremento de tiempo que estas tareas puedan insumir.

● Severidad = 4. Se reduce la severidad ya que se puede avanzar con el proyecto al costo de un retraso en el tiempo planificado para el submódulo de adquisición.

● Probabilidad de ocurrencia = 5. No cambia respecto a la evaluación de riesgo sin la acción de mitigación.

Página 17 de 22




13. Gestión de la calidad ■ REQ 1.1 Se debe generar un Memoria Técnica con la documentación de ingeniería detallada.

■ Verificación: Durante las diferentes etapas del proyecto se debe controlar la correcta generación de la documentación técnica correspondiente ya que servirá de base para la Memoria Técnica.

■ Validación: Lectura y revisión de la Memoria Técnica por parte del cliente, el tutor y/o los jurados del trabajo.

■ REQ 1.2 Se debe generar un documento de casos de prueba. ■ Verificación: Durante la primera etapa del proyecto se debe controlar la correcta

comprensión de la bibliografía específica y de la planificación del proyecto mediante una puesta en común con todos los interesados.

■ Validación: Lectura y revisión del documento de casos de prueba por parte del cliente y el equipo de trabajo.

■ REQ 2.1 El sistema debe adquirir datos de un array de sensores de temperatura a intervalos regulares con un período de adquisición seleccionable. ■ Verificación: Pruebas unitarias y de integración sobre las funciones asociadas. ■ Validación: Pruebas de sistema sobre el producto final.

■ REQ 2.2 El sistema debe adquirir datos de un anemómetro a intervalos regulares con un período de adquisición seleccionable. ■ Verificación: Pruebas unitarias y de integración sobre las funciones asociadas. ■ Validación: Pruebas de sistema sobre el producto final.

■ REQ 2.3 El sistema debe almacenar los datos de temperatura y velocidad de viento adquiridas junto con una marca de tiempo identificatoria en un medio físico no volátil. ■ Verificación: Pruebas unitarias y de integración sobre las funciones asociadas. ■ Validación: Pruebas de sistema sobre el producto final.

■ REQ 2.4 El sistema debe poder operar con dos perfiles de consumo de energía, uno maximizando el desempeño y otro minimizando el consumo de energía. ■ Verificación: Pruebas unitarias y de integración sobre las funciones asociadas. ■ Validación: Pruebas de sistema sobre el producto final.

■ REQ 2.5 El sistema debe contar con una interfaz serie tipo HMI cableada que permita interactuar y realizar operaciones de configuración y mantenimiento. ■ Verificación: Pruebas unitarias y de integración sobre las funciones asociadas. ■ Validación: Pruebas de sistema sobre el producto final.

Página 18 de 22




■ REQ 3.1 Se debe generar una matriz de trazabilidad entre la Memoria Técnica y los requerimientos. ■ Verificación: Controles parciales durante el desarrollo del trabajo de la cobertura de los

requerimientos. ■ Validación: Lectura y revisión de la matriz de trazabilidad por parte del equipo de trabajo y

el tutor.

■ REQ 3.2 Se debe generar una matriz de trazabilidad entre las pruebas de integración y los requerimientos. ■ Verificación: Controles parciales durante el desarrollo de las pruebas de la cobertura de los

requerimientos. ■ Validación: Lectura y revisión de la matriz de trazabilidad por parte del equipo de trabajo y el

tutor.

■ REQ 4.1 Se debe generar una matriz de trazabilidad entre el documento de casos de prueba y los requerimientos. ■ Verificación: Controles parciales durante el desarrollo de las pruebas de sistema de la

cobertura de los casos de prueba. ■ Validación: Lectura y revisión de la matriz de trazabilidad por parte del equipo de trabajo y el

cliente.

14. Comunicación del proyecto El 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

Alcance de un hito del

proyecto

Equipo de trabajo

Tomar conocimiento

Cada vez que suceda

Reunión presencial

Patricio Bos

Cambio de etapa del proyecto

Equipo de trabajo

Tomar conocimiento

Al finalizar cada etapa

Reunión presencial

Patricio Bos

Desviación importante respecto al

plan de trabajo

Equipo de trabajo

Búsqueda de soluciones para

completar el proyecto a

tiempo

Al finalizar cada etapa

Reunión presencial

Patricio Bos

Finalización del proyecto

Todos los interesados.

Autoridades de la MSE. Tutor.

Tomar conocimiento

Al finalizar el proyecto

e-mail Patricio Bos

Página 19 de 22




15. Gestión de Compras No se contemplan compras ni contrataciones adicionales en el proyecto.

16. Seguimiento y control

SEGUIMIENTO DE AVANCE

Tarea del

WBS Indicador de avance

Frecuencia de reporte

Responsable de

seguimiento

Persona a ser

informada

Método de comunicac.

1.1 Alcance de hito Plan

de trabajo Al finalizar la etapa Patricio Bos

Equipo de trabajo

Reunión presencial

1.2

Porcentaje de bibliografía analizada

Quincenalmente Igor Prario Equipo de

trabajo Reunión

presencial

1.3 Alcance de hito Plan

de trabajo Al finalizar la etapa Patricio Bos

Equipo de trabajo

Reunión presencial

2.1

Porcentaje de herramientas inicializadas

Semanalmente Patricio Bos Mariano Cinquini

Reunión presencial

2.2

Porcentaje de Arquitectura

definida Semanalmente Patricio Bos

Mariano Cinquini

Reunión presencial

2.3 Porcentaje de

interfaces definidas Semanalmente Patricio Bos

Mariano Cinquini

Reunión presencial

2.4

Porcentaje de herramientas

implementadas Semanalmente Patricio Bos

Mariano Cinquini

Reunión presencial

2.5 Porcentaje de HW

implementado Semanalmente Patricio Bos

Mariano Cinquini

Reunión presencial

Página 20 de 22




2.6

Alcance de hito Documentación de

submódulos Al finalizar la etapa Patricio Bos

Equipo de trabajo

Reunión presencial

2.7



Equipo de trabajo

Reunión presencial

2.8



Equipo de trabajo

Reunión presencial

2.9



Equipo de trabajo

Reunión presencial

2.10



Equipo de trabajo

Reunión presencial

3.1

Alcance de hito reporte pruebas

unitarias Al finalizar la etapa Patricio Bos

Equipo de trabajo

Reunión presencial

3.3

Alcance de hito reporte pruebas de

integración Al finalizar la etapa Patricio Bos

Equipo de trabajo

Reunión presencial

3.5

Alcance de hito reporte de casos de

prueba Al finalizar la etapa Patricio Bos

Equipo de trabajo

Reunión presencial

4.1 Alcance de hito

Memoria Técnica Al finalizar el

proyecto Patricio Bos

Todos los interesados

e-mail

4.3

Alcance de hito Presentación del

Trabajo Final

Al finalizar el proyecto

Patricio Bos Todos los

interesados e-mail

Página 21 de 22




17. Procesos de cierre Al finalizar el proyecto se hará una presentación oral de los principales resultados alcanzados en el proyecto. En la presentación estarán presentes los jurados, el director del proyecto y el equipo de trabajo con el objeto de:

1. Determinar el grado de cumplimiento de la planificación original. Se debe contrastar el Plan de Trabajo con la Memoria Técnica y los documentos e hitos parciales junto con los registros de las comunicaciones relevantes relacionadas con el proyecto. Responsable Patricio Bos.

2. Identificar técnicas y procedimientos útiles e inútiles que se hayan implementado. Responsable Patricio Bos.

El acto de cierre estará a cargo del Dr. Ing. Ariel Lutenberg, en su calidad de Director de la Maestría.

Página 22 de 22

Sistema autónomo para medición de nivel de ruido en el...

Documents

Transcript of Sistema autónomo para medición de nivel de ruido en el...