Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
GNU Radio FMCOMMS1
Autor
Ing. Juan Pablo Tettamanti
Director del trabajo
Esp. Ing. Pedro Ignacio Martos
Jurado propuesto para el trabajo
- Mg. Ing. Diego Brengi (UNLAM, INTI) - Ing. Octavio Alpago (FIUBA) - (???)
Este plan de trabajo ha sido realizado en el marco de la asignatura gestión de proyectos entre octubre y diciembre de 2015.
Página 1 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
Tabla de contenido
Registros de cambios
Acta Constitutiva
1. Nombre del Proyecto
2. Fecha de inicio y finalización del proyecto
3. Presupuesto preliminar asignado
4. Identificación y análisis de los interesados
5. Propósito y Justificación del proyecto
6. Objetivos
7. Alcance del proyecto
8. Supuestos y restricciones del proyecto
9. Requerimientos
10. Entregables principales del proyecto
11. Desglose del trabajo en tareas
12. Análisis de factibilidad
13. Diagrama de Activity On Node
14. Diagrama de Gantt
15. Matriz de uso de recursos de materiales
16. Presupuesto detallado del proyecto
17. Matriz de asignación de responsabilidades
18. Gestión de riesgos
19. Gestión de la calidad
20. Comunicación del proyecto
21. Gestión de Compras
22. Seguimiento y control
23. Procesos de cierre
Página 2 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
Registros de cambios
Revisión Cambios realizados Fecha
1.0 Creación del documento 01-11-2015
1.1 Definición puntos 1 a 7 01-11-2015
1.2 Definición puntos 8 a 17 08-11-2015
1.3 Definición puntos 18 a 23 15-11-2015
1.4 Correcciones generales 1 22-11-2015
1.5 Correcciones generales 2 27-11-2015
Página 3 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
Acta Constitutiva
27 de noviembre de 2015, CAADIEL
Attn Juan Pablo Tettamanti
De mi mayor consideración
Con el fin de implementar bloques de GNU Radio para el uso del kit de desarrollo FMCOMMS1,
se lo designa a Ud como Responsable del proyecto con “GNU Radio FMCOMMS1”, con un presupuesto
total estimado de seiscientas (600) horas hombre, con fecha tentativa de inicio 1 de noviembre de 2015
y de finalización 30 de junio de 2016.
Se adjunta a esta acta la planificación inicial.
Esp. Ing. Pedro Martos
Docente de la Carrera de Especialización en Sistemas
Embebidos - FIUBA
Página 4 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
1. Nombre del Proyecto
GNU Radio FMCOMMS1
2. Fecha de inicio y finalización del proyecto
01-11-2015 al 30-06-2016
3. Presupuesto preliminar asignado
600 HH
4. Identificación y análisis de los interesados
Rol Nombre y Apellido Departamento Puesto
Auspiciante LSE LSE - FIUBA
Cliente Pedro Ignacio Martos CESE - FIUBA Docente
Impulsor Pedro Ignacio Martos CESE - FIUBA Docente
Responsable Juan Pablo Tettamanti CESE - FIUBA Estudiante
Colaboradores Docentes CESE CESE - FIUBA
Orientadores Pedro Ignacio Martos CESE - FIUBA Docente
Equipo -
Opositores -
Usuario Final Integrantes LSE LSE - FIUBA
- Orientador: Pedro Ignacio Martos, lleva tiempo trabajando con la placa FMCOMMS1 y el software
GNU Radio.
Página 5 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
5. Propósito y Justificación del proyecto
El propósito de este proyecto es implementar en el software GNU Radio los bloques para el uso de la
placa FMCOMMS1, adquirir los conocimientos necesarios para llevar adelante un proyecto de Software
Defined Radio y satisfacer el requerimiento de un proyecto final de la Carrera de Especialización en
Sistemas Embebidos.
La justificación de este proyecto es que el LSE cuenta con una placa FMCOMMS1, la cual se usa en
conjunto con una placa Zedboard y el software GNU Radio para la implementación de distintos
proyectos de Software Defined Radio.
6. Objetivos
1. Terminar el proyecto antes del 30 de junio de 2016
2. Aprender sobre Software Defined Radio
3. Implementar bloques de entrada-salida de la placa FMCOMMS1 en GNU Radio
4. Enviar el código de los bloques implementados al proyecto GNU Radio
7. Alcance del proyecto
El proyecto incluye la programación de los bloques para el uso de la placa FMCOMMS1 con GNU Radio, la documentación de los bloques implementados y el envío del código al proyecto GNU Radio para su inclusión. El proyecto no incluye la aceptación del código por parte del proyecto GNU Radio, la obtención de las placas de desarrollo necesarias para implementar y testear los bloques y el funcionamiento de los bloques implementados en plataformas diferentes a la provista (Zedboard).
8. Supuestos y restricciones del proyecto
Supuestos:
● El LSE cuenta con una placa Zedboard ● El LSE cuenta con una placa FMCOMMS1 ● Las placas Zedboard y FMCOMMS1 serán ampliamente accesibles ● Se podrá obtener a modo de préstamo las placas Zedboard y FMCOMMS1 por periodos de
tiempo limitados
Restricciones:
● No se podrán reponer las placas Zedboard y FMCOMMS1 en caso de avería y o extravío.
Página 6 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
9. Requerimientos
Requerimientos de plataforma 1. Utilizar la placa de desarrollo Zedboard para el procesamiento de señales de RF 2. Utilizar la placa de desarrollo FMCOMMS1 para la adquisición de señales de RF 3. Utilizar el software GNU Radio para la ejecución del software
Requerimientos de SW
4. Implementar un bloque de fuente (source) para GNU Radio 5. Implementar un bloque de sumidero (sink) para GNU Radio 6. Permitir un uso pleno de la opciones del hardware de la placa FMCOMMS1 desde el software
GNU Radio
10. Entregables principales del proyecto
1. Código de los bloques FMCOMMS1 para GNU Radio 2. Documentación de usuario 3. Ejemplos de uso y validación de la plataforma
Página 7 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
11. Desglose del trabajo en tareas
1. Gestión del proyecto (40 hs)
2. Estudio inicial de plataforma de desarrollo (120 hs)
2.1. Estudio de software GNU Radio (40 hs)
2.2. Estudio de plataforma Zedboard (40 hs)
2.3. Estudio de placa FMCOMMS1 (40 hs)
3. Pruebas iniciales de plataforma de desarrollo (80 hs)
3.1. Pruebas del sistema operativo (20 hs)
3.2. Pruebas de drivers (20 hs)
3.3. Adquisición de señal de prueba (40 hs)
4. Diseño detallado (120 hs)
4.1. Software (80 hs)
4.2. Documentación de usuario (40 hs)
5. Implementación (120 hs)
5.1. Software (80 hs)
5.2. Documentación de usuario (40 hs)
6. Integración y ensayos (120 hs)
6.1. Software (80 hs)
6.2. Documentación de usuario (40 hs)
7. Presentación (75 hs)
7.1. Informe de avance (15 hs)
7.2. Memoria del trabajo (50 hs)
7.3. Presentación pública (10 hs)
Página 8 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
12. Análisis de factibilidad
Las radios definidas por software o SDR (del inglés Software Defined Radio), son sistemas de telecomunicaciones donde varios de los componentes típicamente implementados en hardware, son implementados en software.
Debido al hecho de que la mayor parte de la funcionalidad de un sistema SDR se encuentra definido en el software, los mismos resultan mucho más fáciles de modificar o upgradear.
Como consecuencia, los investigadores y desarrolladores han invertido tiempo en implementar distintos sistemas de radio utilizando esta nueva plataforma. Esto ha permitido la validación de distintos sistemas y protocolos bajo la más diversa variedad de condiciones.
Conforme esta tecnología continúa evolucionando y madurando, se espera poder incorporar funciones más avanzadas, tales como la selección de protocolos dependiendo de las condiciones atmosféricas.
A medida que las radios definidas por software se han ido volviendo más comunes, distintas compañías y organizaciones han desarrollado plataformas de hardware para el uso en este tipo de aplicaciones, siendo unas de las más conocidas, las plataformas USRP de Ettus Research.
Adicionalmente, existen varios proyectos de software para el desarrollo de radios definidas por software, siendo algunas de las más conocidas GNU Radio y OSSIE (ambas de código abierto) y Simulink y Labview (ambas sistemas propietarios).
Página 9 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
13. Diagrama de Activity On Node
Página 10 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
14. Diagrama de Gantt
Página 11 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
15. Matriz de uso de recursos de materiales
Código WBS
Nombre de la tarea
Recursos requeridos (horas)
Zedboard FMCOMMS1 Generador de
señal Analizador de
espectro 3.1 Pruebas del
sistema
operativo
20 - - -
3.2 Pruebas de
drivers
20 20 - -
3.3 Adquisición
de señal de
prueba
40 40 40 -
6.1 Software 80 80 - 40
Total 160 140 40 40
Página 12 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
16. Presupuesto detallado del proyecto Costos directos de recursos humanos Costo de hora de desarrollador - 30 ARS / hora
1. Gestión del proyecto (40 hs) - 1200 ARS
2. Estudio inicial de plataforma de desarrollo (120 hs) - 3600 ARS
2.1. Estudio de software GNU Radio (40 hs) - 1200 ARS
2.2. Estudio de plataforma Zedboard (40 hs) - 1200 ARS
2.3. Estudio de placa FMCOMMS1 (40 hs) - 1200 ARS
3. Pruebas iniciales de plataforma de desarrollo (80 hs) - 2400 ARS
3.1. Pruebas del sistema operativo (20 hs) - 600 ARS
3.2. Pruebas de drivers (20 hs) - 600 ARS
3.3. Adquisición de señal de prueba (40 hs) - 1200 ARS
4. Diseño detallado (120 hs) - 3600 ARS
4.1. Software (80 hs) - 2400 ARS
4.2. Documentación de usuario (40 hs) - 1200 ARS
5. Implementación (120 hs) - 3600 ARS
5.1. Software (80 hs) - 2400 ARS
5.2. Documentación de usuario (40 hs) - 1200 ARS
6. Integración y ensayos (120 hs) - 3600 ARS
6.1. Software (80 hs) - 2400 ARS
6.2. Documentación de usuario (40 hs) - 1200 ARS
7. Presentación (75 hs) - 2250 ARS
7.1. Informe de avance (15 hs) - 450 ARS
7.2. Memoria del trabajo (50 hs) - 1500 ARS
7.3. Presentación pública (10 hs) - 300 ARS
Costos directos totales: 22250 ARS
Página 13 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
Costos directos en plataforma de desarrollo Estos costos ya se encuentran cubiertos al momento de iniciar este proyecto
❏ Zedboard, Academic Edition - 319 USD ❏ AD-FMCOMMS1-EBZ - 1,042.96 USD
Costos indirectos en licencias de software Estos costos ya se encuentran cubiertos al momento de iniciar este proyecto
❏ Debian GNU/Linux Jessie - 0 USD ❏ GNU Radio - 0 USD ❏ GCC - 0 USD ❏ Python - 0 USD ❏ PetaLinux - 0 USD ❏ Xilinx Design Suite - 5795 USD
Página 14 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
17. 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
Juan Pablo Tettamanti
Pedro Martos Jurado Ariel Lutenberg
1 Gestión del
proyecto
P C A
2.1 Estudio de GNU
Radio
P C,A C
2.2 Estudio de
Zedboard
P C,A C
2.3 Estudio de
FMCOMMS1
P C,A C
3.1 Pruebas del
sistema operativo
P C,A
3.2 Pruebas de
drivers
P C,A
3.3 Adquisición de
señal de prueba
P C,A
4.1 Software P C,A C
4.2 Documentación P C,A
5.1 Software P C,A C I
5.2 Documentación P C,A I
6.1 Software P C,A C I
6.2 Documentación P C,A I
7.1 Informe de
avance
P C,A C,A I
7.2 Memoria del
trabajo
P C,A C,A I
7.3 Presentación
pública
P C,A C,A I
Referencias: P = Responsabilidad Primaria S = Responsabilidad Secundaria A = Aprobación I = Informado C = Consultado
Página 15 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
18. Gestión de riesgos Identificación de los riesgos y estimación de sus consecuencias
★ Riesgo 1: Pérdida o rotura de Zedboard ○ Severidad (S): 10
Si la placa se pierde o resulta dañada, es altamente probable que no se pueda reemplazar antes de la fecha de finalización del proyecto.
○ Probabilidad de ocurrencia (O): 2 La placa podría resultar dañada durante su uso o perderse si se la transporta, pero la placa es manejada con cuidado por especialistas y no es transportada con frecuencia.
○ Tasa de no detección (D): 1 Si la placa se daña o se pierde, será totalmente evidente que esto ha ocurrido.
★ Riesgo 2: Pérdida o rotura de FMCOMMS1 ○ Severidad (S): 10
Si la placa se pierde o resulta dañada, es altamente probable que no se pueda reemplazar antes de la fecha de finalización del proyecto.
○ Probabilidad de ocurrencia (O): 2 La placa podría resultar dañada durante su uso o perderse si se la transporta, pero la placa es manejada con cuidado por especialistas y no es transportada con frecuencia.
○ Tasa de no detección (D): 1 Si la placa se daña o se pierde, será totalmente evidente que esto ha ocurrido.
★ Riesgo 3: Borrado accidental del software ○ Severidad (S): 8
Si se borra el software, se deberá comenzar desde cero. ○ Probabilidad de ocurrencia (O): 4
El desarrollador principal tiene la costumbre de borrar periódicamente archivos y carpetas en desuso mediante la secuencia Ctrl + Alt + Supr.
○ Tasa de no detección (D): 2 Si se borra un archivo, podría pasar desapercibido en el caso de que no sea un archivo de importancia crítica o bien sea de uso poco frecuente.
★ Riesgo 4: Introducción de cambios que provocan un mal comportamiento del software ○ Severidad (S): 6
En ocasiones se suelen introducir cambios que provocan un mal comportamiento; si bien los mismos son reparables, es un proceso que lleva tiempo.
○ Probabilidad de ocurrencia (O): 6 Es altamente probable que un programador, por más experimentado que sea, eventualmente introduzca cambios que provoquen un mal comportamiento.
○ Tasa de no detección (D): 4 En ocasiones, una pieza de software que introduce un mal comportamiento no lo manifiesta hasta etapas posteriores en el proceso de desarrollo.
Página 16 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
★ Riesgo 5: Pérdida o rotura de la PC de desarrollo ○ Severidad (S): 4
Si se pierde o se rompe la PC de desarrollo, se deberá conseguir una nueva. ○ Probabilidad de ocurrencia (O): 4
La PC de desarrollo suele transportarse con frecuencia. ○ Tasa de no detección (D): 1
La PC de desarrollo está en uso constantemente, será totalmente evidente que esto ha ocurrido.
Tabla de gestión de riesgos
Riesgo Severidad Ocurren. Detección RPN Severidad* Ocurren.*
Detecc * RPN*
1 10 2 1 20
2 10 2 1 20
3 8 4 2 64 2 4 1 8
4 6 6 4 144 4 2 2 16
5 4 4 1 64 2 2 1 4
Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 50.
Página 17 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
Plan de mitigación de los riesgos que originalmente excedían el PRN máximo establecido ★ Riesgo 3: Uso de software de control de versiones en la nube (github)
○ Severidad (S): 2 Si se borra la copia local, simplemente se debe descargar una copia remota. Se deberán realizar las modificaciones que no se hubieran subido al sistema de control de versiones.
○ Probabilidad de ocurrencia (O): 4 El uso de un software de control de versiones no afecta el comportamiento del desarrollador y por lo tanto la probabilidad de ocurrencia.
○ Tasa de no detección (D): 1 El uso de un software de control de versiones indica claramente si se ha eliminado algún archivo recientemente y requiere de pasos adicionales para eliminar definitivamente un archivo. Adicionalmente, el mismo puede ser recuperado de versiones anteriores.
★ Riesgo 4: Uso extensivo de pruebas unitarias ○ Severidad (S): 4
El uso de pruebas unitarias contribuye a acotar cuanto se propaga un mal comportamiento.
○ Probabilidad de ocurrencia (O): 2 El proceso de diseño de las pruebas de un software ayuda a identificar posibles fuentes de error en ocasiones antes de que se escriba el propio código a poner a prueba.
○ Tasa de no detección (D): 2 El uso de estas pruebas permite detectar que las modificaciones introducidas no alteren el comportamiento deseado, contribuyendo a la detección temprana de errores.
★ Riesgo 5: Contar con un segundo dispositivo de desarrollo ○ Severidad (S): 2
Contar con un segundo dispositivo de desarrollo permite continuar con el mismo aún en caso de falla del primer dispositivo.
○ Probabilidad de ocurrencia (O): 2 La probabilidad de ocurrencia se divide proporcionalmente entre la cantidad de dispositivos.
○ Tasa de no detección (D): 1 Es fácil detectar fallas o pérdidas de los equipos de desarrollo.
Página 18 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
19. Gestión de la calidad 1. Utilizar la placa de desarrollo Zedboard para el procesamiento de señales de RF
★ Calidad Utilizar la placa de desarrollo Zedboard
★ Grado de calidad No corresponde
★ Costo de conformidad Se aprueba el trabajo
★ Costos de no conformidad No se aprueba el trabajo
★ Verificación Verificar que la placa sea comprada mediante un canal autorizado (http://zedboard.org/product/zedboard)
★ Validación Confirmar que los logos de Digilent, Avnet y Zedboard se encuentran en la placa
2. Utilizar la placa de desarrollo FMCOMMS1 para la adquisición de señales de RF
★ Calidad Utilizar la placa de desarrollo Zedboard
★ Grado de calidad No corresponde
★ Costo de conformidad Se aprueba el trabajo
★ Costos de no conformidad No se aprueba el trabajo
★ Verificación Verificar que la placa sea comprada mediante un canal autorizado (http://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/eval-fmcomms.html#eb-buy)
★ Validación Confirmar que el logo de Analog Devices y la leyenda AD-FMCOMMS1-EBZ se encuentren sobre la placa
Página 19 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
3. Utilizar el software GNU Radio para la ejecución del software ★ Calidad
Utilizar la placa de desarrollo Zedboard ★ Grado de calidad
No corresponde ★ Costo de conformidad
Se aprueba el trabajo ★ Costos de no conformidad
No se aprueba el trabajo ★ Verificación
Descargar el codigo de una fuente confiable (http://gnuradio.org) o del repositorio de una distribución (“sudo apt-get install gnuradio” en Debian o Ubuntu)
★ Validación Comprobar que en la sección Help->About aparezca una ventana con el logo, copyright, la frase “GNU Radio Companion vXXXX” y un enlace a https://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion
4. Implementar un bloque de fuente (source) para GNU Radio
★ Calidad El bloque funciona correctamente en GNU Radio
★ Grado de calidad El bloque es fácil de utilizar
★ Costo de conformidad Se debe invertir tiempo en realizar pruebas al bloque (40 hs)
★ Costos de no conformidad Proyectos posteriores no serán capaces de generar señales
★ Verificación Se analiza el diseño detallado
★ Validación Realizar mediciones de señales generadas usando este bloque
Página 20 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
5. Implementar un bloque de sumidero (sink) para GNU Radio ★ Calidad
El bloque funciona correctamente en GNU Radio ★ Grado de calidad
El bloque es fácil de utilizar ★ Costo de conformidad
Se debe invertir tiempo en realizar pruebas al bloque (40 hs) ★ Costos de no conformidad
Proyectos posteriores no serán capaces de adquirir señales ★ Verificación
Se analiza el diseño detallado ★ Validación
Realizar mediciones de señales generadas usando este bloque
6. Permitir un uso pleno de la opciones del hardware de la placa FMCOMMS1 desde el software GNU Radio
★ Calidad Los bloques implementados en el software GNU Radio permiten la transmisión y recepción señales con una frecuencia de portadora de 400MHz a 4GHz y un ancho de banda máximo de 125MHz
★ Grado de calidad Los bloques implementados en el software GNU Radio permiten la transmisión y recepción señales hasta el valor teórico
★ Costo de conformidad Se debe invertir tiempo en realizar las pruebas correspondientes
★ Costos de no conformidad No será posible adquirir señales con la frecuencia de portadora y ancho de banda deseados
★ Validación Consultar con especialista en el tema
★ Verificación Realizar mediciones de señales conocidas por medio de la placa FMCOMMS1 para verificar la correcta recepción Realizar mediciones de señales generadas por medio de la placa FMCOMMS1 para verificar la correcta transmisión
Página 21 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
20. Comunicación del proyecto
PLAN DE COMUNICACIÓN DEL PROYECTO
¿Qué comunicar?
Audiencia Propósito Frecuencia Método de
comunicac.
Responsable
Estado del proyecto
Tutor Evitar retrasos Evitar errores
Semanalmente Correo
electrónico
Juan Pablo Tettamanti
Diseño del software
Tutor Comunicar
finalización de diseño
Al finalizar Correo
electrónico
Juan Pablo Tettamanti
Implementación de software
Tutor Comunicar
finalización de implementación
Al finalizar Correo
electrónico
Juan Pablo Tettamanti
Ensayos Tutor Comunicar
resultado de los ensayos
Al finalizar Correo
electrónico
Juan Pablo Tettamanti
Informes de Avance
Jurados Tutor
Comunicar estado del proyecto
31 de marzo de 2016
Informe escrito
Juan Pablo Tettamanti
Memoria escrita
Jurados Tutor Ariel
Lutenberg
Informar el cuerpo de
conocimiento obtenido como resultado del
proyecto
15 de julio de 2016
Informe escrito
Juan Pablo Tettamanti
Presentación
pública
Jurados Tutor Ariel
Lutenberg
Defender y dar a conocer
públicamente los resultados
obtenidos
31 de julio de 2016
Página 22 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
21. Gestión de Compras Este proyecto no requiere comprar elementos o contratar servicios.
22. 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 Cantidad de
puntos del
informe
completados
Semanalmente Juan Pablo Tettamanti
Ariel Lutenberg
Pedro Martos
Correo electrónico
2.1 Cantidad de
horas
Al finalizar Juan Pablo Tettamanti
Pedro Martos
Correo electrónico
2.2 Cantidad de
horas
Al finalizar Juan Pablo Tettamanti
Pedro Martos
Correo electrónico
2.3 Cantidad de
horas
Al finalizar Juan Pablo Tettamanti
Pedro Martos
Correo electrónico
3.1 Cantidad de
horas
Semanalmente Juan Pablo Tettamanti
Pedro Martos
Correo electrónico
3.2 Cantidad de
horas
Semanalmente Juan Pablo Tettamanti
Pedro Martos
Correo electrónico
3.3 Adquisición de
señal de prueba
Semanalmente Juan Pablo Tettamanti
Pedro Martos
Correo electrónico
Página 23 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
SEGUIMIENTO DE AVANCE
Tarea del WBS
Indicador de avance
Frecuencia de reporte
Responsable de seguimiento
Persona a ser informada
Método de comunicac.
4.1 Software Semanalmente Juan Pablo Tettamanti
Pedro Martos
Correo electrónico
4.2 Documentación
de usuario
Semanalmente Juan Pablo Tettamanti
Pedro Martos
Correo electrónico
5.1 Cantidad de
funcionalidades
implementadas
Semanalmente Juan Pablo Tettamanti
Pedro Martos
Correo electrónico
5.2 Porcentaje de
funciones
documentadas
Semanalmente Juan Pablo Tettamanti
Pedro Martos
Correo electrónico
6.1 Cantidad de
pruebas
realizadas
Semanalmente Juan Pablo Tettamanti
Pedro Martos
Correo electrónico
6.2 Porcentaje de
pruebas
documentadas
Semanalmente Juan Pablo Tettamanti
Pedro Martos
Correo electrónico
Página 24 de 25
Plan de Proyecto del Trabajo Final de Carrera
de Especialización de Sistemas Embebidos
Ing. Juan Pablo Tettamanti
23. Procesos de cierre Reunión de cierre El Ing. Juan Pablo Tettamanti liderará un análisis sobre el Proyecto con el fin de extraer las soluciones encontradas a problemas relevantes, las lecciones aprendidas durante el mismo y las oportunidades de mejora futura. Luego de finalizada la reunión, el Responsable del Proyecto elaborará una nota de reunión con las lecciones aprendidas que se distribuirá por email a todos los participantes. Entrega de su memoria escrita del proyecto El Ing. Juan Pablo Tettamanti procederá a entregar una memoria escrita que detalle claramente los resultados obtenidos. Presentación pública y defensa El Ing. Juan Pablo Tettamanti realizará la defensa pública del mismo frente a un jurado previamente establecido. Acto de agradecimiento a los involucrados El Ing. Juan Pablo Tettamanti será el encargado de agradecer al Cliente, al equipo de trabajo y a los colaboradores del Proyecto a través de una reunión final de cierre. El Auspiciante financiará los gastos de dicha reunión.
Página 25 de 25