Módulo de búsqueda, seguimiento y decorrelación para un ...laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-CESE-Facund… · Plan de Proyecto del Trabajo Final de Carrera

Plan de Proyecto del Trabajo Final de Carrera

de Especialización de Sistemas Embebidos

Ing. Facundo Larosa

Página 1 de 28

Módulo de búsqueda,

seguimiento y decorrelación

para un sistema GPS sobre

FPGA

Autor

Ing. Facundo Larosa

Director del trabajo

Ing. Nicolás Álvarez

Jurado propuesto para el trabajo

- Esp. Ing. Pedro Martos

- Ing. Edgardo Comas

- Ing. Octavio Alpago

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

Proyectos entre abril y mayo de 2016.



Ing. Facundo Larosa

Página 2 de 28

Tabla de contenido

Registros de cambios

Acta de Constitución del Proyecto

Identificación y análisis de los interesados

1. Propósito del proyecto

2. Alcance del proyecto

3. Supuestos del proyecto

4. Requerimientos

5. Entregables principales del proyecto

6. Desglose del trabajo en tareas

7. Diagrama de Activity On Node

8. Diagrama de Gantt

9. Matriz de uso de recursos de materiales

10. Presupuesto detallado del proyecto

11. Matriz de asignación de responsabilidades

12. Gestión de riesgos

13. Gestión de la calidad

14. Comunicación del proyecto

14. Gestión de Compras

16. Seguimiento y control

17. Procesos de cierre



Ing. Facundo Larosa

Página 3 de 28

Registros de cambios

Revisión Cambios realizados Fecha

0.0 Creación del documento 30/03/2016

1.0 Se completó el documento hasta el punto 6 (desglose de

tareas) inclusive 02/04/2016

1.1 Se modificó el trabajo en base a las sugerencias del Dr. Ing

Ariel Lutenberg de fecha 03/04/2016 03/04/2016

1.2 Se completó el documento hasta el punto 11 (matriz de

responsabilidades) inclusive 12/04/2016

1.3

Se modificó el trabajo en base a las sugerencias del Dr. Ing.

Ariel Lutenberg de fecha 14/04/2016. Se completaron todos

los puntos del documento.

16/04/2016

1.4 Se modificó el trabajo en base a las sugerencias del Dr. Ing.

Ariel Lutenberg de fecha 18/04/2016. 18/04/2016

1.5 Se modificó el trabajo en base a las sugerencias del Ing.

Nicolás Álvarez de fecha 24/04/2016 26/06/2016



Ing. Facundo Larosa

Página 4 de 28

Acta de Constitución del Proyecto

Buenos Aires, 30 de marzo de 2016

Por medio de la presente se acuerda con el Ing. Facundo Larosa que su Proyecto Final de la Carrera

de Especialización en Sistemas Embebidos se titulará “Módulo de búsqueda, seguimiento y decorrelación

para un sistema GPS sobre FPGA”, consistirá esencialmente en el prototipo preliminar de un módulo de

hardware sobre FPGA orientado a realizar las operaciones de búsqueda, seguimiento y decorrelación de

señales GPS digitalizadas en frecuencia intermedia , y tendrá un presupuesto preliminar estimado de 660

hs de trabajo y $187.200, con fecha de inicio miércoles 30 de marzo de 2016 y fecha de presentación pública

miércoles 14 de diciembre de 2016.

Se adjunta a esta acta la planificación inicial.

Dr. Ing. Ariel Lutenberg Ing. Carlos González

Director de la CESE-FIUBA Departamento de Ingeniería Electrónica

UTN Haedo



Ing. Facundo Larosa

Página 5 de 28

Identificación y análisis de los interesados

Rol Nombre y Apellido Departamento Puesto

Auspiciante Carlos González Ingeniería Electrónica -

UTN Haedo Director

Cliente Nicolás Álvarez Ingenieria Electrónica -

FIUBA Director de tesis

Impulsor Edgardo Fernández

Vescovo

Ingeniería Aeronáutica -

UTN Haedo Director

Responsable Facundo Larosa Ingeniería Electrónica -

UTN Haedo Investigador

Colaboradores Pedro Martos Ingenieria Electrónica -

FIUBA

Docente CESE-

FIUBA

Orientadores Anibal Guanca Ingeniería Electrónica –

UTN Haedo Docente

Equipo Facundo Larosa Ingeniería Electrónica -

UTN Haedo Investigador

Usuario Final UTN Haedo Ingeniería Electrónica /

Ingeniería Aeronáutica



Ing. Facundo Larosa

Página 6 de 28

1. Propósito del proyecto

El propósito del proyecto es diseñar, implementar y simular un módulo de hardware necesario para la

implementación de un receptor GPS definido por software. Los receptores definidos por software

tienen como ventaja un tipo de implementación más flexible lo cual permite el agregado de

funcionalidades específicas para cada aplicación (por ejemplo, filtrado digital, integración con otros

dispositivos para utilizar técnicas de navegación avanzadas, etc.). Esto resulta de gran interés para el

desarrollo de sistemas que integran navegación por satélites, tales como sistemas de aumentación

(SBAS, GBAS) o sistemas de navegación integrada con sensores para diferentes plataformas.

2. Alcance del proyecto

El proyecto incluye:

1. Estudio preliminar de las arquitecturas adecuadas para la implementación del sistema

principal y subsistemas

2. Diseño de alto nivel (arquitectura) del sistema

3. Diseño del sistema en lenguaje de descripción de hardware (VHDL)

4. Plan de pruebas unitarias y ensayos (testbenchs) para cada subsistema

5. Plan de pruebas de integración y ensayos (testbenchs) para agrupaciones de subsistemas

6. Plan de pruebas del sistema y ensayos (testbenchs) para el sistema completo

7. Documentación del sistema y subsistemas que incluya:

a. Descripción de entradas y salidas (frecuencias, tamaño y tipos de datos, señales de

control, etc.)

b. Descripción de parámetros del sistema

c. Requerimientos funcionales implementados trazables a los requerimientos del

proyecto (matriz de trazabilidad)

d. Hipótesis de diseño, justificación de la elección del diseño, estudios previos y marco

teórico (si aplica)

e. Diagrama de arquitectura

f. Reporte de ensayos realizados

g. Referencias bibliográficas

Exclusiones:

1. Integración con front-end GPS (módulo de hardware que realiza la operación de amplificación,

mezcla, filtrado y digitalización en frecuencia intermedia de las señales GPS)

2. Operaciones y algoritmos de posicionamiento de satélites en base al contenido del mensaje de

navegación



Ing. Facundo Larosa

Página 7 de 28

3. Supuestos del proyecto

1. Se supone que el desarrollo es factible en base a bibliografía específica de la temática

2. Se supone que el equipo de trabajo será capaz de alcanzar un grado suficiente del dominio

del problema y de las técnicas que permitan implementar las soluciones en el marco de la

Especialización en Sistemas Embebidos

3. Se supone que la línea de trabajo actual tendrá una prioridad alta en el desarrollo de las

tareas de la organización

4. Requerimientos

A fin de detallar los requerimientos se propone un desglose en subsistemas básicos que implementan

las funcionalidades del sistema global y permiten organizar los requisitos funcionales mínimos por

área. La arquitectura del sistema, tal como se aprecia en la Figura 1, puede variar durante el desarrollo

del proyecto, pero sin importar la implementación final, deberá poder trazarse sus funcionalidades

asegurando la cobertura total de los requerimientos propuestos a continuación.

Figura 1 – Desglose de subsistemas propuesto

Subsistema de sincronización

de reloj de entrada

Subsistema de búsqueda

Subsistema de seguimiento

Subsistema de pruebas y

comunicación



Ing. Facundo Larosa

Página 8 de 28

1. Generales

1.1. Operación: El sistema recibirá a su entrada una señal GPS en banda L1 (simulada) que envíe

información de un satélite desconocido, cuya frecuencia central y desplazamiento de su código

C/A (código pseudoaleatorio de decorrelación) se desconocen a priori (el intervalo posible de

ambas cantidades se aclara en el punto 2.2), convenientemente preamplificada, filtrada,

convertida a frecuencia intermedia (fi) y digitalizada. El sistema será capaz de hallar la

frecuencia de portadora y desplazamiento del código C/A, mantener la sincronización del

canal y obtener el mensaje de navegación para dicho satélite.

1.2. Arquitectura: El sistema contará mínimamente con los siguientes subsistemas:

1.2.1. Subsistema de sincronización de reloj de entrada

La función de este módulo será evitar los estados no estables de entrada debidos a la

desincronización y diferencia de frecuencias del reloj de entrada y el reloj del sistema.

1.2.2. Subsistema de búsqueda (search)

La función de este módulo será la de hallar durante la inicialización del módulo la

frecuencia de portadora y fase de código C/A para un satélite determinado y alimentar

con estos datos al módulo de seguimiento

1.2.3. Subsistema de seguimiento (tracking)

La función de este módulo será la de mantener la sincronización del generador de

portadora y código C/A interno con el de un satélite determinado a partir de los datos

iniciales recibidos por el módulo de búsqueda

1.2.4. Subsistema de pruebas y comunicación

La función de este módulo será la de proveer información del estado del sistema a través

de alguna interfaz a definir (por ejemplo, UART, SPI, etc.)

1.2.5. Plataforma: La plataforma de hardware para la implementación será una FPGA Xilinx

Spartan 3E500 o una Xilinx XC6SLX16 (TBC1)

1 TBC, del inglés “To be confirmed”, a confirmar



Ing. Facundo Larosa

Página 9 de 28

2. Específicos

2.1. Módulo de sincronización de reloj de entrada

2.1.1. Este módulo debe evitar la posibilidad de que existan estados metaestables de datos a

la entrada del módulo de búsqueda

2.2. Módulo de búsqueda (search)

2.2.1. Bits de señal de entrada: 1

2.2.2. Frecuencia de señal de entrada: fc=16,368 MHz (TBC)

2.2.3. Frecuencia intermedia: fi=4,092MHz (TBC)

2.2.4. Dominio de búsqueda de la frecuencia de portadora: fi 6000 Hz

2.2.5. Dominio de búsqueda del código C/A: [0,1023] chips (el código es periódico)

2.2.6. Intervalo de frecuencia (bin) (máximo): 200 Hz

2.2.7. Tiempo máximo de búsqueda (locking) (máximo): 3 minutos (TBC)

2.3. Módulo de seguimiento (tracking)

2.3.1. El módulo no deberá perder sincronización de la frecuencia de portadora y fase del

código C/A ante variaciones de la señal de entrada consistentes con el movimiento de un

satélite de la constelación GPS y un receptor cuasiestacionario para el peor caso (máxima

variación de frecuencia de portadora). El valor exacto de la variación temporal de la

frecuencia de portadora y fase se calculará durante la fase de estudio (tarea 2.3 Estudio

de señal GPS en frecuencia intermedia).

2.3.2. El módulo debe proveer a la salida el mensaje de navegación binario



Ing. Facundo Larosa

Página 10 de 28

2.4. Módulo de pruebas y comunicación

El módulo de pruebas deberá proveer información a través de una interfaz (UART, SPI, etc.)

y una trama de datos (que será definida luego de la fase de estudio) del estado del sistema y

subsistemas. Como mínimo indicará:

2.4.1. Generales

2.4.1.1. Recepción de datos: SI/NO

2.4.1.2. Estado del sistema:

BÚSQUEDA: La búsqueda de frecuencia/fase se encuentra en curso

ADQUISICIÓN: La búsqueda de frecuencia/fase ha finalizado y la señal se

encuentra sincronizada

SIN SEÑAL: No se detecta señal a la entrada del sistema

ERROR(tipo): Los errores posibles del sistema se listarán luego de la etapa de

análisis

2.4.2. Módulo de búsqueda

2.4.2.1. Frecuencia de portadora

2.4.2.2. Desplazamiento de código C/A

2.4.2.3. Estado del subsistema

BUSCANDO: La búsqueda de frecuencia/fase se encuentra en curso

BUSQUEDA_TERMINADA: La búsqueda de frecuencia/fase ha finalizado

2.4.2.4. Progreso de la búsqueda (en porcentaje del dominio comprobado)

2.4.3. Módulo de seguimiento

2.4.3.1. Frecuencia de portadora

2.4.3.2. Desplazamiento de código C/A

2.4.3.3. Estado del subsistema:

SINCRONIZADO: El módulo de seguimiento se encuentra sincronizado en

frecuencia y en fase de código respecto de la señal de entrada

NO_SINCRONIZADO:

El módulo de seguimiento no se encuentra sincronizado en frecuencia y en

fase de código respecto de la señal de entrada

2.4.3.4. Último mensaje de navegación válido empaquetado (información contenida

en los subframes 1, 2 y 3 del mensaje de navegación GPS) (no mandatorio,

deseable)



Ing. Facundo Larosa

Página 11 de 28

Todos los requerimientos precedentes son mandatorios salvo que se indique lo contrario. En caso de

que durante el proceso de desarrollo se verificase que no pudiera cumplirse alguno de ellos deberá

generarse un reporte sobre la limitación encontrada. De esta manera se podrá explorar la aplicación

de algún mecanismo de mitigación que pudiera ser necesario, o la flexibilización del requerimiento en

conjunto con los interesados (cliente, colaboradores, etc.).

5. Entregables principales del proyecto

1. Documentación del sistema y subsistemas que incluya:

a. Descripción de entradas y salidas (frecuencias, tamaño y tipos de datos, señales de

control, etc.)

b. Descripción de parámetros del sistema

c. Requerimientos funcionales implementados trazables a los requerimientos del

proyecto (matriz de trazabilidad)

d. Hipótesis de diseño, justificación de la elección del diseño, estudios previos y marco

teórico (si aplica)

e. Diagrama de arquitectura

f. Reporte de ensayos realizados

g. Referencias bibliográficas

2. Publicación (paper) en formato IEEE para ser presentada en un congreso de la especialidad



Ing. Facundo Larosa

Página 12 de 28

6. Desglose del trabajo en tareas

El desglose de tareas da un total de 660 hs, repartidas entre las diferentes fases del proyecto como se indica a

continuación.

Código EDT

Nombre de tarea Duración

1

Fase de planificación general 60 horas

1.1 Redacción de alcance, requisitos y desglose de tareas 20 horas

1.2 Planificación de tiempos, recursos y presupuesto 20 horas

1.3 Planificación de responsabilidades, riesgos, calidad, comunicación y cierre 20 horas

2

Fase de estudio 170

horas

2.1 Búsqueda de bibliografía general y específica 20 horas

2.2 Instalación y puesta a punto de herramientas de software 20 horas

2.3 Estudio de señal GPS en frecuencia intermedia 20 horas

2.4 Estudio de técnicas de búsqueda 20 horas

2.5 Estudio de técnicas de seguimiento 20 horas

2.6 Diseño de arquitectura preliminar módulo de sincronización 10 horas

2.7 Diseño de arquitectura preliminar módulo de búsqueda 20 horas

2.8 Diseño de arquitectura preliminar módulo de seguimiento 20 horas

2.9 Diseño de arquitectura preliminar módulo de pruebas 20 horas

3

Fase de análisis 70 horas

3.1 Diseño de arquitectura detallada módulo de sincronización 10 horas

3.2 Diseño de arquitectura detallada módulo de búsqueda 20 horas

3.3 Diseño de arquitectura detallada módulo de seguimiento 20 horas

3.4 Diseño de arquitectura detallada módulo de pruebas 20 horas

4

Fase de implementación y pruebas unitarias 140

horas

4.1 Implementación y pruebas de módulo de sincronización 20 horas

4.2 Implementación y pruebas de método de búsqueda 40 horas

4.3 Implementación y pruebas de módulo de seguimiento 40 horas

4.4 Implementación y pruebas de módulo de pruebas 40 horas

5

Fase de pruebas de integración y de sistema 100

horas

5.1 Pruebas sincronización/búsqueda 20 horas

5.2 Pruebas sincronización/búsqueda/seguimiento 40 horas

5.3 Pruebas de sistema 40 horas

6

Fase de cierre 120

horas

6.1 Confección de documentación general y específica 40 horas

6.2 Redacción memoria del trabajo final 40 horas

6.3 Diagramación de diapositiva para exposición 20 horas

6.4 Redacción paper 20 horas



Ing. Facundo Larosa

Página 13 de 28

7. Diagrama de Activity On Node

1.1(20hs)

1.2(20hs)

1.3(20hs)

2.1(20hs)

2.2(20hs)

2.3(20hs)

2.4(20hs)

2.5(20hs)

2.6(10hs)

2.7(20hs)

2.8(20hs)

2.9(20hs)

3.1(10hs)

3.3(20hs)

3.2(20hs)

3.4(20hs)

4.1(20hs)

4.3(40hs)

4.2(40hs)

4.4(40hs)

5.3(40hs)

5.2(40hs)

5.1(20hs)

6.3(20hs)

6.2(40hs)

6.1(40hs)

6.4(20hs)

Fase 1Planificación

general

Fase 2Estudio

Fase 3Análisis

Fase 4Implementación y pruebas unitarias

Fase 5Pruebas de integración y

de sistema

Fase 6Cierre



Ing. Facundo Larosa

Página 14 de 28

En el diagrama de Activity On Node se indican los caminos críticos en color rojo. Ambos caminos duran

380 horas.

Es importante destacar que el diagrama anterior indica las dependencias entre las tareas en virtud que

los entregables de las tareas predecesoras son necesarios para las tareas siguientes. No obstante, se

verá en la sección 8 (a continuación) que dado los recursos afectados al proyecto no será posible llevar

a cabo tareas en paralelo.



Ing. Facundo Larosa

Página 15 de 28

8. Diagrama de Gantt

Se muestra el diagrama por fases para facilitar su visualización.

Listado de tareas



Ing. Facundo Larosa

Página 16 de 28

Fase 1 – Planificación general (11 de abril – 29 de abril)

Fase 2 – Estudio (2 de mayo – 29 de junio)



Ing. Facundo Larosa

Página 17 de 28

Fase 3 – Análisis (29 de junio – 22 de julio)

Fase 4 – Implementación y pruebas unitarias (25 de julio – 14 de septiembre)

Fase 5 – Pruebas de integración y de sistema (19 de septiembre – 21 de octubre)



Ing. Facundo Larosa

Página 18 de 28

Fase 6 – Cierre (24 de octubre – 2 de diciembre)

9. Matriz de uso de recursos de materiales

Código WBS

Nombre de la tarea Duración de la tarea

[horas]

Equipos requeridos [horas]

PC Kit FPGA Nexys 2

1.x Fase de planificación

general 60 60 0

2.x Fase de estudio 170 100 0

3.x Fase de análisis 70 40 0

4.x

Fase de

implementación y

pruebas unitarias

140 140 140

5.x Fase de integración y

de sistema 100 100 100

6.x Fase de cierre 120 120 0

Total proyecto 660 560 240



Ing. Facundo Larosa

Página 19 de 28

10. Presupuesto detallado del proyecto

N° Descripción Costo unitario Cantidad Costo total 1 Horas hombre 200 $/hora 660 horas $132.000,00 2 Amortización equipos $20/hora 600 horas $12.000,00

Subtotal costos directos $144.000,00 3 Costos indirectos aproximados

(30% costos directos) - - $43.200,00

Subtotal costos indirectos $43.200,00 Total proyecto $187.200,00

11. Matriz de asignación de responsabilidades

Código WBS

Título de la tarea F. Larosa

Responsable N. Álvarez

Cliente

E. Fernández V.

Impulsor

Carlos González

Auspiciante

Pedro Martos

Colaborador

A. Guanca Orientador

1.x

Fase de planificación

general P A I I C C

2.x Fase de estudio P A I I C C

3.x Fase de análisis P A I I C C

4.x

Fase de

implementación y

pruebas unitarias

P A I I C C

5.x Fase de integración y

de sistema P A I I C C

6.x Fase de cierre P A I I C C

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



Ing. Facundo Larosa

Página 20 de 28

12. Gestión de riesgos 12.1 Identificación de riesgos A continuación se desarrollan los riesgos identificados y el análisis efectuado sobre los mismos.

Riesgo 1: No disponer de kit de desarrollo (Nexys 2) por rotura o pérdida

Severidad (S): 9(nueve) La severidad es alta ya que no se podrán realizar pruebas básicas.

Probabilidad de ocurrencia(O): 3(tres) La probabilidad es relativamente baja ya que el kit será utilizado sólo por el desarrollador.

Tasa de no detección (D): 10 (diez) La tasa de no detección es alta, ya que tanto en el caso de pérdida o rotura es muy difícil de preveer.

Riesgo 2: Que la FPGA que se dispone (Spartan 3E) no cuente con la capacidad suficiente para implementar el módulo objeto del proyecto

Severidad (S): 7(siete) La severidad es media-alta, ya que no se podrá implementar el módulo completo.

Probabilidad de ocurrencia(O): 4(cuatro) La probabilidad es media-baja ya que en base a la bibliografía se puede presumir que se han implementado módulos similares sobre este tipo de plataformas.

Tasa de no detección (D): 9 (nueve) La tasa de no detección es alta, ya que no se conoce a priori y no es sencillo preveer la complejidad de los circuitos a implementar

Riesgo 3: No cumplir con los requerimientos técnicos planteados (sección 4)

Severidad (S): 5(cinco) La severidad es media ya que tratándose de un desarrollo existe la posibilidad de que sea necesario bajar las expectativas en base a los requerimientos estrictamente propuestos.

Probabilidad de ocurrencia(O): 9(nueve) La probabilidad es alta ya que las especificaciones planteadas son en realidad, cotas de máxima

Tasa de no detección (D): 9 (nueve) La probabilidad es alta ya que no se conocen a priori detalles de la implementación que permitan preveer si se va o no a cumplir con las especificaciones.



Ing. Facundo Larosa

Página 21 de 28

Riesgo 4: No cumplir con plazos planteados (sección 8)

Severidad (S): 10 (diez) La severidad es máxima ya que no se podrá presentar el proyecto en el plazo acordado y finalizar la especialización.

Probabilidad de ocurrencia(O): 7(siete) La probabilidad es media-alta ya que a menudo, los proyectos que involucran desarrollos requieren de mayor cantidad de horas de lo previsto.

Tasa de no detección (D): 7 (siete) La tasa de no detección es media-alta, ya que en proyectos de desarrollo, especialmente donde no media una gran experiencia técnica en el área resulta difícil evaluar el corrimiento de plazos a priori.

Riesgo 5: Falta de tiempo de recursos humanos por contingencias ajenas al proyecto

Severidad (S): 9 (nueve) La severidad es alta ya que el tiempo es un recurso fundamental para el desarrollo de este proyecto.

Probabilidad de ocurrencia(O): 4(cuatro) La probabilidad es media-baja ya que se prevee una alta dedicación al proyecto

Tasa de no detección (D): 5 (cinco) La tasa de no detección es media ya que si bien ante imprevistos puntuales puede preveerse la falta de tiempo, por la naturaleza misma del proyecto podría llegar a ser necesario invertir más horas de lo previsto.

12.2 Ponderación de riesgos

Riesgo Descripción S O D RPN S* O* D * RPN*

1 Falta de kit 9 3 10 270 2 3 10 60

2 Falta de capacidad hardware

7 4 9 252 2 4 9 72

3 No cumplir requerimientos

5 9 9 405 3 9 6 162

4 No cumplir plazos 10 7 7 490 10 3 3 90

5 Falta de recursos humanos

9 4 5 180

Criterio adoptado: se tomarán medidas de mitigación para aquellos riesgos cuyo RPN supere 200. Nota: Los valores marcados con (*) en la tabla corresponden luego de haber aplicado la mitigación.



Ing. Facundo Larosa

Página 22 de 28

12.3 Plan de mitigación de riesgos

Riesgo 1: No disponer de kit de desarrollo (Nexys 2) por rotura o pérdida Medida de mitigación: Se dispondrá de un kit de repuesto facilitado por colegas en el lapso de tiempo que se necesite para adquirir un kit nuevo. De esta forma se reduce la severidad del riesgo de 9 (nueve) a 2 (dos).

Severidad (S): 2(dos) La severidad es baja ya que se dispone de una alternativa para continuar el trabajo.

Probabilidad de ocurrencia(O): 3(tres) La probabilidad es relativamente baja ya que el kit será utilizado sólo por el desarrollador.

Tasa de no detección (D): 10 (diez) La tasa de no detección es alta, ya que tanto en el caso de pérdida o rotura es muy difícil de preveer.

Riesgo 2: Que la FPGA que se dispone (Spartan 3E 500) no cuente con la capacidad suficiente para implementar el módulo objeto del proyecto Medida de mitigación: Se dispone de la posibilidad de utilizar un kit alternativo que cuenta con una Spartan XC6LX16 (de mayor capacidad). De esta forma, la severidad se reduce de 7 (siete) a 2 (dos).

Severidad (S): 2(dos) La severidad es baja ya que se dispone de una alternativa de mayor capacidad.

Probabilidad de ocurrencia(O): 4(cuatro) La probabilidad es media-baja ya que en base a la bibliografía se puede presumir que se han implementado módulos similares sobre plataformas similares.

Tasa de no detección (D): 9 (nueve) La tasa de no detección es alta, ya que no se conoce a priori y no es sencillo preveer la complejidad de los circuitos a implementar

Riesgo 3: No cumplir con los requerimientos técnicos planteados (sección 4) Medida de mitigación: Se prestará especial atención al cumplimiento de los requerimientos técnicos desde el inicio de la etapa de implementación a fin de explicitar las posibles razones que pudieran causar acotar los requerimientos técnicos. Se informará posibles cursos de solución para alcanzar los requisitos originales de máxima. De esta forma, disminuyen la severidad (se dejarán expresadas las posibles soluciones), y la tasa de no detección (análisis temprano de la situación).

Severidad (S): 3(tres) La severidad es media-baja ya que si bien podría no cumplirse con los requisitos de máxima del proyecto, por tratarse de un proyecto de desarrollo el análisis de las



Ing. Facundo Larosa

Página 23 de 28

dificultades encontradas será de gran ayuda en las etapas de mejora que eventualmente se produzcan a futuro.

Probabilidad de ocurrencia(O): 6 (seis) La probabilidad es alta ya que las especificaciones planteadas son en realidad, cotas de máxima

Tasa de no detección (D): 6 (seis) La probabilidad es media ya que se prestará especial atención a los requerimientos planteados desde el inicio de la etapa de implementación.

Riesgo 4: No cumplir con plazos planteados (sección 8) Plan de mitigación: Se trabajará en base a la planificación para predecir tempranamente desvíos y tomar las medidas necesarias para corregirlos, por ejemplo, dedicar horas adicionales, buscar el consejo de especialistas, etc. De esta manera, se reduce tanto la probabilidad de ocurrencia como la tasa de no detección.

Severidad (S): 10 (diez) La severidad es máxima ya que no se podrá presentar el proyecto en el plazo acordado y finalizar la especialización.

Probabilidad de ocurrencia(O): 3(tres) La probabilidad es media-baja ya que se dispondrán de mecanismos para dedicar más horas al proyecto, contar con el consejo de especialistas, etc.

Tasa de no detección (D): 3 (tres) La tasa de no detección es media-baja ya que se evaluará de forma continua desvíos del plan original a fin de detectar tempranamente una posible extensión de plazo.



Ing. Facundo Larosa

Página 24 de 28

13. Gestión de la calidad 13.1 Verificación El plan de verificación estará compuesto por el conjunto de pruebas unitarias para cada módulo, previstas en la fase 4 del proyecto “Fase de implementación y pruebas unitarias”. El plan de pruebas unitarias se detallará al finalizar la fase 3 del proyecto “Fase de análisis” (ya que se contará con el diseño arquitectural detallado para cada módulo), en base a los requerimientos originales planteados en la sección 4 “Requerimientos”. El responsable de definir y realizar las pruebas será Facundo Larosa, con la asistencia y aprobación de su director Nicolás Álvarez.

4

Fase de implementación y pruebas unitarias 140

horas 4.1 Implementación y pruebas de módulo de sincronización 20 horas 4.2 Implementación y pruebas de método de búsqueda 40 horas 4.3 Implementación y pruebas de módulo de seguimiento 40 horas 4.4 Implementación y pruebas de módulo de pruebas 40 horas

13.2 Validación El plan de validación estará dado por el conjunto de pruebas de integración entre los diferentes módulos y las pruebas de sistema previstas en la fase 5 “Fase de pruebas de integración y de sistema”. El plan de pruebas de integración y de sistema se detallará al finalizar la fase 3 del proyecto “Fase de análisis” (ya que se contará con el diseño arquitectural detallado para cada módulo), en base a los requerimientos originales planteados en la sección 4 “Requerimientos”.

5

Fase de pruebas de integración y de sistema 100

horas 5.1 Pruebas sincronización/búsqueda 20 horas 5.2 Pruebas sincronización/búsqueda/seguimiento 40 horas 5.3 Pruebas de sistema 40 horas



Ing. Facundo Larosa

Página 25 de 28

14. Comunicación del proyecto

PLAN DE COMUNICACIÓN DEL PROYECTO

¿Qué comunicar?

Audiencia Propósito Frecuencia Método de

comunicación Responsable

Plan de proyecto

Curso CESE

Compartir el tema de proyecto y las

estrategias de planificación

aplicadas

Única vez Presentación

privada Facundo Larosa

Plan de proyecto

Jurado de tesis, director de

proyecto, director CESE

Poner en conocimiento de los interesados el plan de proyecto

Única vez Correo

electrónico Facundo Larosa

Informe de avance



Poner en conocimiento de los interesados el

estado del proyecto

Única vez Correo


Memoria de proyecto final



Poner en conocimiento de los interesados la

memoria del proyecto final a los

efectos de su evaluación

Única vez Correo


Presentación de proyecto

final Audiencia pública

Poner en conocimiento de los asistentes el

trabajo final desarrollado para la especialización

Única vez Presentación

pública Facundo Larosa

En este plan de comunicación se resumen los principales hitos de comunicación del proyecto. La comunicación referente al avance y estado de tareas se detalla en la sección 16 (Seguimiento y control).

15. Gestión de Compras El proyecto no posee un plan de adquisiciones, compras o contrataciones ya que se cuenta con los

elementos materiales necesarios (kit de desarrollo y PC) para su realización.



Ing. Facundo Larosa

Página 26 de 28

16. Seguimiento y control

Código EDT Nombre de tarea Horas de la tarea

Indicador de avance

Frecuencia de reporte

Responsable de

seguimiento

Persona a ser informada

Método de comunicación

1

Fase de planificación general 60 horas % Al finalizar cada

tarea (aproximadamente

una vez por semana)

Facundo Larosa

Ariel Lutenberg

Correo electrónico

1.1 Redacción de alcance, requisitos y

desglose de tareas 20 horas %

1.2 Planificación de tiempos, recursos y

presupuesto 20 horas %

1.3 Planificación de responsabilidades,

riesgos, calidad, comunicación y cierre 20 horas %

2

Fase de estudio 170

horas %

Cada dos semanas Facundo Larosa

Nicolás Álvarez Correo

electrónico / Reunión

2.1 Búsqueda de bibliografía general y

específica 20 horas %

2.2 Instalación y puesta a punto de

herramientas de software 20 horas %

2.3 Estudio de señal GPS en frecuencia

intermedia 20 horas %

2.4 Estudio de técnicas de búsqueda 20 horas %

2.5 Estudio de técnicas de seguimiento 20 horas %

2.6 Diseño de arquitectura preliminar módulo

de sincronización 10 horas %


de búsqueda 20 horas %


de seguimiento 20 horas %


de pruebas 20 horas %

3

Fase de análisis 70 horas %




3.1 Diseño de arquitectura detallada módulo

de sincronización 10 horas %


de búsqueda 20 horas %


de seguimiento 20 horas %


de pruebas 20 horas %

4

Fase de implementación y pruebas

unitarias

140 horas

%




4.1 Implementación y pruebas de módulo de

sincronización 20 horas %

4.2 Implementación y pruebas de método de

búsqueda 40 horas %


seguimiento 40 horas %


pruebas 40 horas %

5

Fase de pruebas de integración y de

sistema

100 horas

%




5.1 Pruebas sincronización/búsqueda 20 horas %

5.2 Pruebas

sincronización/búsqueda/seguimiento 40 horas %

5.3 Pruebas de sistema 40 horas %



Ing. Facundo Larosa

Página 27 de 28

6

Fase de cierre 120

horas %



electrónico

6.1 Confección de documentación general y

específica 40 horas %

6.2 Redacción memoria del trabajo final 40 horas %

6.3 Diagramación de diapositiva para

exposición 20 horas %

6.4 Redacción paper 20 horas %

El avance de las tareas se indicará por porcentaje de completamiento según la siguiente escala:

0% : Tarea no comenzada

20% : Tarea iniciada

70% : Tarea completada con entregables en versión preliminar o código sin errores de

sintaxis, compilación, arquitectura, etc, sin documentación asociada.

90% : Tarea completada con documentación asociada en versión preliminar o pendiente

de revisión

100%: Tarea finalizada

17. Procesos de cierre

Evaluación del plan de proyecto original Se evaluará el plan de proyecto original respecto del desempeño real con el objeto de sacar conclusiones que permitan a futuro mejores estimaciones respecto de:

Tiempo planificado para cada tarea Riesgos ocurridos, previstos o no previstos y efectividad de las medidas de mitigación

implementadas Imprecisiones, incertidumbres, malentendidos o errores de la comunicación entre los actores

del proyecto Retrabajos a consecuencia de, entre otros, especificaciones mal definidas, enfoques

incorrectos, etc. Exceso de horas extras, “cuellos de botella”, etc.

Aprobaciones formales Se gestionará y archivará la aprobación formal por parte del director de proyecto final, el jurado y el director de la Carrera de Especialización en Sistemas Embebidos (CESE) para realizar la presentación final.



Ing. Facundo Larosa

Página 28 de 28

Organización y guarda de documentación del proyecto Se organizarán los documentos utilizados como entradas del proyecto, así como la documentación intermedia o final generada de forma de facilitar su uso futuro. Se resguardará la misma por medio de una copia de seguridad.

Documents

Módulo de búsqueda, seguimiento y decorrelación para un ...laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-CESE-Facund… · Plan de Proyecto del Trabajo Final de Carrera