Desarrollo de software para un Sistema de Referencia de ...laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo... · 600 hs de trabajo, con fecha de inicio miércoles 30 de marzo de

Plan de Proyecto del Trabajo Final de Carrera

de Especialización de Sistemas Embebidos

Ing. Alejandro Permingeat

Desarrollo de software para un Sistema de Referencia de

Actitud y Rumbo con interfaz con la CIAA

Autor


Director del trabajo

Ing. Juan Cecconi

Jurado propuesto para el trabajo

Mg. Diego Brengi (INTI) Ing. Gustavo Alessandrini (INTI) Bioing. Jerónimo Labruna (FIUBA)

Este plan de trabajo ha sido realizado en el marco de la asignatura Gestión de Proyectos entre abril y mayo de 2016.

Página 1 de 25




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

Página 2 de 25




Registros de cambios

Revisión Cambios realizados Fecha

1.0 Creación del documento 30/03/2016

1.1 Completado hasta el punto 6 26/04/2016

1.2 Correcciones observadas por Ariel Lutenberg. Se reagrupan de otra manera las tareas (Sección 6 de este documento). Completado hasta el punto 11.

01/05/2016

1.3 Se agregan los ID a los requerimientos. Se actualiza el requerimiento de validación [REQ015]. Se agregan tareas de

verificación y validación. Se completa hasta el punto 17.

02/05/2016

1.4 Correcciones observadas por Ariel Lutenberg. 18/05/2016

Página 3 de 25




Acta de Constitución del Proyecto

Buenos Aires, 30 de marzo de 2016

Por medio de la presente se acuerda con el ing. Alejandro Permingeat que su Proyecto Final de

la Carrera de Especialización en Sistemas Embebidos se titulará “Desarrollo de Software para un

Sistema de Referencia de Actitud y Rumbo con Interfaz con la CIAA.”, consistirá esencialmente en el

prototipo preliminar de un software que controlará un dispositivo desarrollado por VSATMotion S.R.L. y

su finalidad será el sensado de su GPS, su acelerómetro, su magnetómetro y su giróscopo , calculará la

actitud actual y publicará los datos en una red RS485. Tendrá un presupuesto preliminar estimado de

600 hs de trabajo, 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.

Ariel Lutenberg Dario Alejandro Cajal

Director de la CESEFIUBA Apoderado VSATMotion S.R.L.

Página 4 de 25




Identificación y análisis de los interesados

Rol Nombre y Apellido Departamento Puesto

Auspiciante Dario Cajal Apoderado

VSATMotion S.R.L.

Cliente Sebastián Osuna Socio Gerente

VSATMOtion S.R.L.

Impulsor

Responsable Alejandro Permingeat

Colaboradores

Orientadores Juan Ceconi (director) Coordinador CESE

Equipo

Opositores

Usuario Final Empresas petroleras

1. Propósito del proyecto

El propósito de este proyecto es el desarrollo de un AHRS (firmware) que corra sobre una placa

VSATM015 versión 1, siguiendo un enfoque MDD (Model Driver Development), en especial el proceso

de desarrollo Harmony/ERT.

2. Alcance del proyecto

El alcance del proyecto consiste en:

● desarrollar la infraestructura básica del software (obtención de datos crudos de los sensores)

● calibración del magnetómetro ● primera etapa de procesamiento. Esto incluye,

○ cálculo de inclinación para los planos “xy”, “yz” y “xz” ○ calculo de velocidad angular para los planos “xy”, “yz” y “xz” y ○ cálculo del vector norte para los planos “xy”, “yz” y “xz”.

El proyecto no incluye el cálculo avanzado de la actitud (filtros Kalman, etc).

Página 5 de 25




3. Supuestos del proyecto

Para el desarrollo del presente proyecto se supone que se contará con una licencia de la herramienta Enterprise Architect y con una placa VSATM015.

4. Requerimientos

1. Requerimientos de documentación

1.1. Se debe generar un documento de requerimiento de sistema a partir de los

requerimientos de usuarios listados a continuación [REQ001]

1.2. Se debe generar un manual de usuario [REQ002]

1.3. Se debe generar un documento de casos de pruebas [REQ003]

2. Requerimientos funcionales del software

2.1. Grupo de requerimientos asociados con los sensores

2.1.1. Se debe encuestar al magnetómetro, acelerómetro, giróscopo cada 100 ms.

[REQ004]

2.1.2. Se deben obtener del magnetómetro, acelerómetro y giróscopo los valores

leídos en los 3 ejes. [REQ005]

2.1.3. Se debe obtener la latitud, longitud y altura del GPS cada 1 segundo. [REQ006]

2.1.4. Se debe obtener la hora del GPS cada 1 segundo [REQ007]

2.2. Grupo de requerimientos asociado con la comunicación

2.2.1. Se debe brindar la información al usuario a través del canal RS485 [REQ008]

2.3. Grupo de requerimientos relacionados con la calibración

2.3.1. Se debe poder calibrar el magnetómetro para superar interferencias del tipo

hardiron y softiron [REQ009]

2.4. Grupo de requerimientos asociados con el procesamiento

2.4.1. Se debe poder indicar cuál es la inclinación con respecto al vector gravedad

para cada uno de los planos “xy”, “yz” y “xz” del sensor acelerometro. [REQ010]

2.4.2. Se debe poder indicar cuál es la de velocidad angular para cada uno de los planos “xy”, “yz” y “xz”. [REQ011]

2.4.3. Se debe poder indicar cuál es el azimut con respecto al vector norte magnético para los planos “xy”, “yz” y “xz”. [REQ012]

3. Requerimientos de verificación 3.1. Se debe generar una matriz de trazabilidad entre el documento de diseño y los

requerimientos. [REQ013] 3.2. Se debe generar una matriz de trazabilidad entre los módulos de software y los

módulos de diseño. [REQ014] 4. Requerimientos de validación

4.1. Se debe generar una matriz de trazabilidad entre las pruebas de integración y los requerimientos. [REQ015]

5. Restricciones de diseño 5.1. El software debe correr sobre una placa VSATM015 versión 1. [REQ016]

Página 6 de 25




5.2. El software debe estar bajo control de versiones (git) [REQ017] 5.3. El software debe ser implementado en C [REQ018] 5.4. El modelo del software debe ser implementado en una herramienta CASE. [REQ019]

5. Entregables principales del proyecto

Los entregables del proyecto serán:

● Especificación de requerimientos de software ● Documento de diseño ● Repositorio con la implementación del software ● Manual de usuario ● Documento de verificación ● Documento de validación

6. Desglose del trabajo en tareas

WBS Descripción Total

1 Especificación de requerimientos 32

2 Iteración 1: Desarrollo de infraestructura de software: comunicación con sensores y comunicación RS485

194

2.1 Análisis de casos de uso primera iteración) 32

2.2 Definición de la arquitectura del software primera iteración 24

2.3 Desarrollo del diseño detallado para la primer iteración 40

2.4 Implementación para la primer iteración 40

2.5 Desarrollo de pruebas unitarias para primer iteración 30

2.6 Desarrollo de pruebas de integración 20

2.7 Documento de la release 1 (primera iteración) 8

3 Iteración 2: Desarrollo del procesamiento de datos: cálculo preliminar de actitud y rumbo

186

3.1 Análisis de casos de uso segunda iteración (procesamiento de datos de sensores)

32

3.2 Revisión de arquitectura 16

Página 7 de 25




3.3 Desarrollo del diseño detallado para la segunda iteración 40

3.4 Implementación para la segunda iteración 40

3.5 Desarrollo de pruebas unitarias para segunda iteración 30


3.7 Documento de la release 2 (segunda iteración) 8

4 Infraestructura 40

4.1 Preparar ambiente de desarrollo 8

4.2 Configurar y mantener servidor de integración continua 24

4.3 Configurar y mantener servidor control de versiones 8

5 Documentación 108

5.1 Informe de avance (mitad del proyecto) 16

5.2 Escritura manual de usuario 32

5.3 Escritura de las “memorias del proyecto” 40

5.4 Armar presentación 20

6. Verificación 16

6.1 Confeccionar matriz de trazabilidad entre diseño y requerimientos 8

6.2 Confeccionar matriz de trazabilidad módulos de software y los módulos de diseño

8

7 Validación 8

7.1 Confeccionar matriz de trazabilidad entre pruebas de integración y requerimientos

8

Total (horas/hombre) 584

Página 8 de 25




7. Diagrama de Activity On Node

Página 9 de 25




8. Diagrama de Gantt

Página 10 de 25




Página 11 de 25




9. Matriz de uso de recursos de materiales

WBS Descripción

Procesador

de textos

Prototipo

VSATM01

5

Enterprise

Architect Servidor

1 Especificación de requerimientos 24 0 8 0

2 Iteración 1: Desarrollo de infraestructura de software:

comunicación con sensores y comunicación RS485 28 70 96 0

2.1 Análisis de casos de uso primera iteración) 32

2.2 Definición de la arquitectura del software primera

iteración 24

Página 12 de 25




2.3 Desarrollo del diseño detallado para la primer iteración 40

2.4 Implementación para la primer iteración 40

2.5 Desarrollo de pruebas unitarias para primer iteración 30


2.7 Documento de la release 1 (primera iteración) 8

3 Iteración 2: Desarrollo del procesamiento de datos:

cálculo preliminar de actitud y rumbo 28 70 88 0

3.1 Análisis de casos de uso segunda iteración

(procesamiento de datos de sensores) 32

3.2 Revisión de arquitectura 16

3.3 Desarrollo del diseño detallado para la segunda

iteración 40

3.4 Implementación para la segunda iteración 40

3.5 Desarrollo de pruebas unitarias para segunda iteración 30


3.7 Documento de la release 2 (segunda iteración) 8

4 Infraestructura 0 0 0 40

4.1 Preparar ambiente de desarrollo 8

4.2 Configurar y mantener servidor de integración continua 24

4.3 Configurar y mantener servidor control de versiones 8

5 Documentación 108 0 0 0

5.1 Informe de avance (mitad del proyecto) 16

5.2 Escritura manual de usuario 32

5.3 Escritura de las “memorias del proyecto” 40

5.4 Armar presentación 20

Página 13 de 25




6 Verificación 16

6.1 Confeccionar matriz de trazabilidad entre diseño y requerimientos

8


8

7 Validación 8

7.1 Confeccionar matriz de trazabilidad entre pruebas de

integración y requerimientos 8

Total 188 140 192 40

Nota: Los valores están expresados en horas/hombre.

10. Presupuesto detallado del proyecto

ID Descripción Cantidad Costo unitario

(USD) Total (USD)

1 Horas Hombre 584 $20,00 $11.680,00

2 Licencia Enterprise Architect 1 $150,00 $150,00

3 Amortización Servidores 584 $2,00 $1.168,00

Total costos directos (USD) $11.350,00

4 Costos indirectos (20% de costos directos)

$2.366,00

Total costos (USD) $12.998,00

Página 14 de 25




11. Matriz de asignación de responsabilidades

WBS Descripción

Darío Cajal

(apoderado

VSATMotion)

Auspiciante

Sebastián

Osuna

(socio Gerente

VSATMotion)

Cliente

Alejandro

Permingeat

Responsable

Juan

Cecconi

Orientador

2.1 Análisis de casos de uso primera

iteración I A P C

2.2 Definición de la arquitectura del

software primera iteración I A P C

2.3 Desarrollo del diseño detallado para la

primer iteración I A P C

2.4 Implementación para la primer

iteración I A P C

2.5 Desarrollo de pruebas unitarias para

primer iteración I A P C

2.6 Desarrollo de pruebas de integración I A P C

2.7 Documento de la release 1 (primera

iteración) I A P C

3.1

Análisis de casos de uso segunda

iteración (procesamiento de datos de

sensores)

I A P C

3.2 Revisión de arquitectura I A P C

3.3 Desarrollo del diseño detallado para la

segunda iteración I A P C

3.4 Implementación para la segunda

iteración I A P C

3.5 Desarrollo de pruebas unitarias para

segunda iteración I A P C

3.6 Desarrollo de pruebas de integración I A P C

Página 15 de 25




3.7 Documento de la release 2 (segunda

iteración) I A P C

4.1 Preparar ambiente de desarrollo I A P C

4.2 Configurar y mantener servidor de

integración continua I A P C

4.3 Configurar y mantener servidor control

de versiones I A P C

5.1 Informe de avance (mitad del proyecto) I A P C

5.2 Escritura manual de usuario I A P C

5.3 Escritura de las “memorias del

proyecto” I A P C

5.4 Armar presentación I A P C

6.1 Confeccionar matriz de trazabilidad entre diseño y requerimientos

I A P C


I A P C

7.1

Confeccionar matriz de trazabilidad

entre pruebas de integración y

requerimientos

I A P C

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

Página 16 de 25




12. Gestión de riesgos

a) Identificación de los riesgos

Riesgo 1: No disponer de una placa VSATM015 en tiempo y forma ● Severidad (S): 9

La severidad es alta ya que demora el inicio de la tarea 2.4 Implementación para la primer iteración, la cual se encuentra en el camino crítico.

● Probabilidad de Ocurrencia (O): 5 La probabilidad de ocurrencia es media, ya que dicha placa ya fue diseñada y en la actualidad se encuentra en proceso de fabricación

● Tasa de no detección (D): 2 Baja, ya que el seguimiento de la fabricación de dicha placa está a cargo de la misma persona que es el responsable de desarrollar este software

Riesgo 2: No disponer de una licencia de Enterprise Architect ● Severidad (S): 10

La severidad es muy alta ya que demora el inicio del 35% de las tareas que se encuentran en el camino crítico.

● Probabilidad de Ocurrencia (O): 7 La probabilidad de ocurrencia es media alta, ya que dicha compra la realiza el departamento de compras de VSATMotion y aún no fue puesta la orden de compra.

● Tasa de no detección (D): 2 Baja, ya que el seguimiento de la compra está a cargo de la misma persona que es el responsable de desarrollar este software

Riesgo 3: No poder desarrollar un algoritmo de determinación de la actitud con la precisión necesaria

● Severidad (S): 7 La severidad es media alta ya que ese requerimiento representa el 20% de la funcionalidad crítica del software.

● Probabilidad de Ocurrencia (O): 7 La probabilidad de ocurrencia es media alta, ya que el desarrollador no cuenta con experiencia en dichos tipos de algoritmos.

● Tasa de no detección (D): 5 Media, ya que la precisión del algoritmo ni es tan fácil de medir.

Riesgo 4: Ruptura de máquina donde corre servidor de control de versiones e integración continua

● Severidad (S): 9 La severidad es alta ya que produce una pérdida de información del proyecto.

● Probabilidad de Ocurrencia (O): 5 La probabilidad de ocurrencia es media, ya que la computadora que se plantea utilizar es una computadora de escritorio y no tiene las robustez de una computadora pensada par ser servidor.

● Tasa de no detección (D): 2 Baja, ya que se accedera a dicho servidor diariamente

Página 17 de 25




Riesgo 5: Ruptura/pérdida de notebook donde se encuentra modelo de Enterprise Architect

● Severidad (S): 9 La severidad es alta ya que podría causar pérdida de información valiosa del proyecto.

● Probabilidad de Ocurrencia (O): 4 La probabilidad de ocurrencia es media baja, ya que la notebook es de muy buena calidad y se encuentra funcionando correctamente.

● Tasa de no detección (D): 2 Baja, ya que se utilizará dicha notebook diariamente.

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

Riesgo Severidad Ocurren. Detección RPN Severidad* Ocurren.*

Detecc * RPN*

1 9 5 2 90 3 5 2 30

2 1 0 7 2 140 5 7 2 70

3 7 7 5 245 5 7 2 70

4 9 5 2 90 2 5 2 20

5 9 4 2 72

Criterio adoptado: Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 80 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:

Riesgo 1: No disponer de una placa VSATM015 en tiempo y forma Mitigación: Utilizar un kit de desarrollo que cuente con el mismo microcontrolador y sensores que la placa VSATM015. En la empresa se dispone de un kit FRDMKE02Z (con el mismo microcontrolador que la placa VSATM015) y un kit FRDMFXSMULTIB (con todos los sensores que tiene la placa VSATM015, a ecepcion del GPS). Evaluar comprar un kit de desarrollo con el sensor de geolocalización que posee la placa VSATM015

Página 18 de 25




● Severidad (S): 3 La severidad baja al nivel “medio bajo”, ya que se disone de una placa de desarrollo para todos los componentes de la placa VSATM015 (a excepción del sensor de geolocalización.

● Probabilidad de Ocurrencia (O): 5 La probabilidad de ocurrencia es media, ya que dicha placa ya fue diseñada y en la actualidad se encuentra en proceso de fabricación

● Tasa de no detección (D): 2 Baja, ya que el seguimiento de la fabricación de dicha placa está a cargo de la misma persona que es el responsable de desarrollar este software

Riesgo 2: No disponer de una licencia de Enterprise Architect Mitigación: En el caso de que se demore la compra de la licencia, utilizar una licencia trial, ya que el proveedor de esta herramienta ofrece una versión trial por 30 días.

● Severidad (S): 5 La severidad baja a media, ya que se dispondría de una licencia provisoria hasta que salga la compra de la licencia definitiva.

● Probabilidad de Ocurrencia (O): 7 La probabilidad de ocurrencia es media alta, ya que dicha compra la realiza el departamento de compras de VSATMotion y aún no fue puesta la orden de compra.

● Tasa de no detección (D): 2 Baja, ya que el seguimiento de la compra está a cargo de la misma persona que es el responsable de desarrollar este software

Riesgo 3: No poder desarrollar un algoritmo de determinación de la actitud con la precisión necesaria Mitigación: Forma parte de la empresa VSATMotion un especialista en software que actualmente se encuentra realizando una maestría en guiado y control en Estados Unidos y que se ha puesto a disposición como consultor..

● Severidad (S): 7 La severidad es media alta ya que ese requerimiento representa el 20% de la funcionalidad crítica del software.

● Probabilidad de Ocurrencia (O): 2 La probabilidad de ocurrencia baja abruptamente, ya que se contará con la asistencia de un magister en guiado y control en caso de necesidad.

● Tasa de no detección (D): 5 Media, ya que la precisión del algoritmo ni es tan fácil de medir.

Riesgo 4: Ruptura de máquina donde corre servidor de control de versiones e integración continua Mitigación: Montar los servidores sobre máquinas virtuales y realizar un backup semanal.

● Severidad (S): 2 La severidad baja mucho, ya que ante un problema se contará con backups de la información y la posibilidad de poner en línea nuevamente los servidores muy rápidamente (no hace falta configurar los servidores de nuevo, ya que se utilizarán máquinas virtuales).

Página 19 de 25




● Probabilidad de Ocurrencia (O): 5 La probabilidad de ocurrencia es media, ya que la computadora que se plantea utilizar es una computadora de escritorio y no tiene las robustez de una computadora pensada par ser servidor.

● Tasa de no detección (D): 2 Baja, ya que se accedera a dicho servidor diariamente

13. Gestión de la calidad 1. Requerimientos de documentación

1.1. Incluye los requerimientos: [REQ001], [REQ002], [REQ003]

1.2. Verificación

1.2.1. Responsable de la verificación: Alejandro Permingeat

1.2.2. Método de verificación: Revisión por parte de especialistas

1.3. Validación

1.3.1. Responsable de la validación: Alejandro Permingeat

1.3.2. Método de validación: Nota de recepción de la documentación por parte del

cliente

2. Requerimientos funcionales del software

2.1. Incluye los requerimientos: [REQ004], [REQ005], [REQ006], [REQ007], [REQ008],

[REQ009], [REQ010], [REQ011], [REQ012].

2.2. Verificación


2.2.2. Método de verificación:

2.2.2.1. Test unitarios

2.2.2.2. Matriz de trazabilidad entre diseño y requerimientos

2.2.2.3. Matriz de trazabiliadd entre módulos de software y módulos de diseño

2.3. Validación


2.3.2. Método de validación: Matriz de trazabilidad entre pruebas de integración y

requerimientos

3. Requerimientos de verificación 3.1. Incluye los requerimientos: [REQ013], [REQ014]

3.2. Verificación



3.3. Validación



cliente

4. Requerimientos de validación 4.1. Incluye el requerimiento: [REQ015]

4.2. Verificación


Página 20 de 25





4.3. Validación



cliente

5. Restricciones de diseño 5.1. Incluye el requerimiento: [REQ016], [REQ017], [REQ018] y [REQ019] 5.2. Verificación


5.2.2. Método de verificación: Revisión por parte de especialistas y test unitarios

5.3. Validación


5.3.2. Método de validación: Nota de recepción de software, servidor de versiones y

modelo en Enterprise Architect

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

Avance del proyecto

Juan Cecconi (director), Sebastián

Osuna (cliente), Darío Cajal (auspiciante)

Mantener informado y

obtener ideas y consejos

mensual email Alejandro Permingeat

Problemas que afecten el costo o el cronograma

Juan Cecconi (director), Sebastián

Osuna (cliente), Darío Cajal (auspiciante)

Facilitar la pronta toma de

decisiones ante problemas que

afecten el proyecto

cuando surjan problemas que afecten el costo en más del 5% del presupuesto total o el cronograma en más

del 10%

email Alejandro Permingeat

15. Gestión de Compras Para este proyecto solo hace falta la adquisición de una licencia de Enterprise Architect. Dado que es un producto específico de un proveedor específico (Sparx Systems), no se realizará ningún proceso de selección de proveedores. La compra será realizada y gestionada por el departamento de compras de VSATMotion S.R.L.

Página 21 de 25




Página 22 de 25




16. Seguimiento y control

Seguimiento y control

WBS Indicador de avance

Frecuencia de reporte

Responsable de seguimiento

Persona a ser informada

Método de comunicac.

1 Cantidad de secciones del documento

una vez por mes mientras dure esta tarea

Alejandro Permingeat

Juan Cecconi, Sebastián Osuna, Darío Cajal

email

2.1 Cantidad de casos de uso completados




email

2.2 Cantidad de componentes




email

2.3 Cantidad de módulos




email

2.4 Cantidad de módulos de software




email

2.5 Cantidad de pruebas




email





email

2.7 Cantidad de secciones de documento




email

3.1 Cantidad de casos de uso completados




email

Página 23 de 25




3.2 Cantidad de componentes




email

3.3 Cantidad de módulos




email

3.4 Cantidad de módulos de software




email





email





email





email

4.1 Tarea finalizada una vez por mes mientras dure esta tarea



email




email




email





email





email

Página 24 de 25








email





email

6.1 Cantidad de filas/columnas tabla




email





email





email

17. Procesos de cierre La reunión final que dará cierre al proyecto tendrá lugar durante la presentación y defensa pública del trabajo final de carrera de Alejandro Permingeat Para evaluar el desempeño durante el proyecto, Alejandro Permingeat realizará las siguientes actividades

1. evaluación de alcance: Se realizará una tabla en la cual se indicará si se cumplió con cada una de las tareas planteadas en la WBS (las filas serán las tareas de la WBS y la columna el porcentaje de cumplimiento).

2. evaluación del tiempo (cronograma). Se realizará una tabla en la cual se incluirá: el tiempo estimado, el tiempo real y el porcentaje indicando cuanto se desvió la tarea con respecto al tiempo estimado

3. no se incluirá una evaluación del costo, ya que solo hay una adquisición con costo fijo y la mayor parte del costo está compuesto por horas/hombre, cubierto por la evaluación del tiempo (cronograma).

Durante la presentación y defensa pública del trabajo final de carrera, Alejandro Permingeat incluirá una sección especial para agradecer a todos los interesados, y en especial al equipo de trabajo y colaboradores

Página 25 de 25

Documents

Desarrollo de software para un Sistema de Referencia de ...laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo... · 600 hs de trabajo, con fecha de inicio miércoles 30 de marzo de