Librerías para manejo de displays en la CIAAlaboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-CESE... · Con el fin de brindar soporte en el proyecto CIAA a las pantallas

Plan de Proyecto del Trabajo Final de Carrera

de Especialización de Sistemas Embebidos

Ing. Nicolás Venturo

Librerías para manejo de displays en la CIAA

Autor


Director del trabajo

Esp. Ing. Eric Pernia (FIUBA)

Jurado propuesto para el trabajo

- Mg. Ing. Felix Safar (UNQ) - Dr. Ing. Carlos Lombardi (UNQ) - TBD

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 20




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 20




Registros de cambios

Revisión Cambios realizados Fecha

1.0 ● Creación del documento ● Nombre del Proyecto ● Fechas de inicio y finalización ● Presupuesto preliminar ● Propósito y justificación ● Objetivos ● Alcance

4/11/2015

1.1 ● Correcciones menores ● Requerimientos ● Supuestos ● WBS ● Entregables ● Análisis de factibilidad ● Diagrama de Gantt ● Gestión de Riesgos

17/11/2015

1.2 ● Presupuesto ● Gestión de compras ● Gestión de calidad

18/11/2015

1.3 ● Uso de materiales ● Asignación de responsabilidades ● Verificación y validación

26/11/2015

1.4 ● Asignación de responsabilidades ● Comunicación del proyecto ● Seguimiento y control ● Procesos de cierre

1/12/2015

Página 3 de 20




Acta Constitutiva

Ciudad Autónoma de Buenos Aires, 4 de noviembre de 2015

Attn Nicolás Venturo

De mi mayor consideración

Con el fin de brindar soporte en el proyecto CIAA a las pantallas LCD más comunes en el

mercado, se lo designa a Ud como Responsable del proyecto con “Librerías para manejo de displays en

la CIAA”, con un presupuesto total estimado de 600 horas hombre, con fecha tentativa de inicio

4/11/2015 y de finalización 30/06/2016.

Se adjunta a esta acta la planificación inicial.

Esp. Ing. Eric Pernia

Página 4 de 20




1. Nombre del Proyecto

Librerías para manejo de displays en la CIAA.

2. Fecha de inicio y finalización del proyecto

Inicio: 4 de noviembre de 2015.

Finalización: 30 de junio de 2016.

3. Presupuesto preliminar asignado

600 horas hombre.

4. Identificación y análisis de los interesados

Rol Nombre y Apellido Departamento Puesto

Auspiciante Nicolás Venturo

Cliente Mariano Cerdeiro

Impulsor Nicolás Venturo

Responsable Nicolás Venturo

Colaboradores Eric Pernia

Orientadores Comunidad CIAA

Equipo N/A

Opositores N/A

Usuario Final Programadores de la

CIAA

- Cliente: es muy estricto con la calidad del firmware del proyecto CIAA, es importante seguir sus

lineamientos de estilo, convenciones de nombres, etc.

- Usuario final: la CIAA es utilizada tanto por principiantes como por programadores avanzados,

por lo que ambos perfiles de usuario deben ser considerados en el diseño de las librerías.

Página 5 de 20




5. Propósito y Justificación del proyecto

El propósito de este proyecto es facilitar la integración de pantallas LCD de bajo costo en proyectos

realizados con la CIAA (tanto la CIAA-NXP como la EDU-CIAA o ediciones futuras basadas en una

arquitectura similar), lo cual enriquecería los mismos y contribuiría a la popularidad y adopción de la

CIAA como plataforma.

La justificación de este proyecto es la brecha percibida entre la ubicuidad de dichas pantallas, sumada

al entusiasmo que genera en la mayoría de los programadores trabajar con una de ellas, y la falta de

soporte en el firmware de la CIAA para utilizarlas. Prueba de esto es el caso de la primer placa de

expansión (Poncho) creada para la CIAA, el Poncho UI, cuya característica principal es la presencia de

una pantalla LCD de caracteres. Al momento de redactar esta sección (noviembre de 2015), han

transcurrido 11 meses desde la fabricación del primer prototipo físico de este Poncho, y el mismo aún

no ha sido utilizado ni por los propios creadores del mismo, debido al trabajo que implica el desarrollo

del software necesario.

Si bien existen ya una serie de librerías con licencias libres para este tipo de dispositivos, abundan

implementaciones incompletas, con dificultades para ser utilizadas en microcontroladores distintos al

original (porting complejo), o con interfaces para el programador diseñadas con un tipo específico de

aplicación en mente (lo cual puede tornar imposible su uso, por ejemplo, al integrar una librería

baremetal en una aplicación con un RTOS). Debido a estos motivos, se considera conveniente el

desarrollo de una implementación propia del proyecto CIAA, que considere la mayoría de los casos de

uso posibles y en consecuencia logre un uso sencillo de la misma.

6. Objetivos

● Lograr que sea sencillo el uso de las pantallas más comunes en el mercado por un programador

novato.

● Permitir el acceso a funcionalidades avanzadas a programadores con mayor experiencia, sin

pérdidas notables de desempeño (con bajos retardos y altas tasas de refresco).

● Diseñar las interfaces de programación de modo que sean consistentes entre sí aún para

distintas pantallas.

● No restringir el uso de las librerías a ningún tipo de arquitectura de aplicación en particular.

● Generar utilidades que faciliten el desarrollo de aplicaciones utilizando las pantallas.

● Brindar soporte a los modelos con mayor presencia en el mercado en aquellos casos donde

haya más de un fabricante de controladores de pantalla.

● Respetar las condiciones de trabajo impuestas por la comunidad CIAA.

● Las librerías deben estar terminadas para el 30 de Junio de 2016.

Página 6 de 20




7. Alcance del proyecto

● Se soportarán LCDs de caracteres basados en el controlador Hitachi HD44780 de cantidad de

filas y columnas configurable por el programador (16x2, 20x4, etc.), incluyendo la capacidad de

generar caracteres personalizados.

● Se soportarán LCDs de matriz de puntos basados en los controladores Hitachi HD44102,

Samsung KS0107/KS108 y Toshiba T6963C, de resolución configurable por el programador

(128x64, 240x64, etc.).

● Se soportarán LCDs TFT basados en el controlador Ilitek ILI340.

● No se soportarán las funcionalidades de desplazamiento: sólo se utilizará la porción del mapa

de memoria visible en pantalla.

● No se soportarán las funcionalidades touch de las pantallas TFT.

● Se permitirá el uso de las librerías en distintos tipos de aplicaciones: ya sea con retardos

busy-wait, utilizando interrupciones, o utilizando un sistema operativo simple.

● No se desarrollarán circuitos impresos que contengan dichas pantallas.

● Se dará al programador la flexibilidad para realizar la interconexión entre la CIAA y la pantalla

como más conveniente le resulte.

● Sólo se soportará el uso de una única pantalla por aplicación.

● Se desarrollarán utilidades (fuera del Firmware de la CIAA) que facilitarán el uso de las librerías,

como conversores de imágenes a mapas de bits en el formato de los GLCD, simuladores con

previsualización, etc.

8. Supuestos y restricciones del proyecto

● Se supone que este trabajo será considerado útil por los encargados del Firmware de la CIAA, y

en consecuencia será evaluado y no ignorado.

● El código fuente generado deberá ser compatible con las licencias utilizadas por el resto del

Firmware de la CIAA.

9. Requerimientos

1. Requerimientos de las librerías

1.1. Soporte

1.1.1. Para LCDs de caracteres

1.1.2. Para LCDs de matriz de puntos

1.1.3. Para displays TFT (sólo dibujado)

1.2. Interfaces

1.2.1. Con llamadas busy-wait

1.2.2. Asincrónica utilizando callbacks e interrupciones 1.2.3. Orientada a threads (para ser utilizada junto con un RTOS)

2. Requerimientos de las utilidades

2.1. General

Página 7 de 20




2.1.1. Simulación del funcionamiento de las pantallas y uso de las librerías mediante

una aplicación con una interfaz gráfica (para ser ejecutada en una computadora

personal, no en la CIAA).

2.2. Para LCDs de matriz de puntos

2.2.1. Generación automática de código para dibujar una imágen a partir de archivos

en formato png, jpeg y bmp.

2.2.2. Generación automática de código para generar texto en una cierta tipografía y

tamaño de letra.

10. Entregables principales del proyecto

● Código fuente de las librerías (archivos .c y .h), con instrucciones de compilación (Makefile)

● Documentación del funcionamiento y filosofía de diseño de las librerías

● Código fuente con ejemplos de utilización de las librerías

● Programas misceláneos auxiliares (no son parte del Firmware)

● Informe

11. Desglose del trabajo en tareas

1. Análisis de periféricos de la CIAA

1.1. Estudio del funcionamiento de los GPIO

1.2. Estudio del multiplexado interno de los GPIO y las posibles asignaciones de pines

1.3. Estudio del funcionamiento de los timers

2. Análisis del Firmware de la CIAA

2.1. Estudio de convenciones de estilo

2.2. Estudio de metodología de trabajo

2.3. Estudio de herramientas y entorno de desarrollo

2.4. Análisis de interfaces de periféricos similares

3. Diseño de arquitectura de software

3.1. Diseño de estructuras de datos internas

3.2. Diseño de mecanismos de interacción con los displays

3.3. Diseño de mecanismos de interacción con el simulador

4. Diseño de interfaces

4.1. Diseño del modelo del programador

4.2. Diseño de las interfaces para los distintos modos de uso

5. Diseño de los simuladores

5.1. Estudio de los dispositivos a simular

5.2. Determinación del alcance y precisión de la simulación

5.3. Determinación de arquitectura del simulador

6. Configuración de un entorno de desarrollo

Página 8 de 20




6.1. Determinación de herramientas de control de versiones a utilizar

6.2. Determinación de herramientas de documentación a utilizar

6.3. Instalación y configuración de compiladores

7. Implementación de las librerías en el Firmware

7.1. Capa de interacción con el hardware

7.2. Capa de interacción con el simulador

7.3. Capa de configuración / asignación de pines

7.4. Capa de manejo de displays

7.5. Capa de interfaces de usuario

8. Implementación del simulador

8.1. Capa de interacción con las librerías en el Firmware

8.2. Motor del simulador

8.3. Interfaz de usuario

9. Implementación de las utilidades misceláneas

10. Integración final al Firmware de la CIAA

10.1. Realización de correcciones requeridas por la comunidad

10.2. Merge y resolución de conflictos

11. Presentación del proyecto

11.1. Escritura del informe de avance

11.2. Escritura del informe final

11.3. Presentación pública final

12. Análisis de factibilidad

Existen múltiples librerías para manejar este tipo de displays, de distintos niveles de complejidad y para

múltiples plataformas. El propio tesista realizó una implementación para LCDs de caracteres en un

microcontrolador, y cuenta con experiencia en el uso de las otras variantes. Abunda además

documentación técnica acerca de los mismos, y han sido probados extensivamente por la comunidad,

por lo que todas sus particularidades (quirks) son ya conocidas. Por todos estos motivos, se concluye

que es improbable que se encuentren problemas técnicos que dificulten la continuación o éxito del

proyecto.

Las dificultades del proyecto se encuentran en el diseño de las interfaces para el programador, el cual

requiere criterio y experiencia. Debido a que el punto de contacto de la comunidad con las librerías son

estas interfaces, es de esperarse que programadores de la CIAA tengan interés en las mismas, por lo

que, en caso de tener problemas para llegar a un buen diseño, es posible consultar con expertos o con

la comunidad entera (a través de la lista de mails, por ejemplo).

Debido a que el proyecto no tiene un fin de lucro sino de contribución a la comunidad CIAA, no aplican

al caso cálculos financieros de tasas de retorno, período de repago, etc. Sí debe tenerse en cuenta que

se deberá contar con hardware para probar el desarrollo: en principio, el mismo será provisto por el

Página 9 de 20




propio tesista. En caso de requerir acceso a unidades adicionales y no ser posible adquirirlas, existe la

posibilidad de pedirlas en préstamo a la comunidad: esto ya ha sucedido en proyectos similares, y la

ubicuidad de los displays en el mercado debería facilitar este proceso.

En conclusión, se determina que el proyecto es factible, y es poco probable que falle por factores

internos al mismo.

13. Diagrama de Activity On Node

(esto se me está yendo de control y faltan items del WBS todavía, paso a directamente especificar

items enteros y no subitems? condenso el WBS?)

Página 10 de 20




14. Diagrama de Gantt

Página 11 de 20




15. Matriz de uso de recursos de materiales

Código WBS

Nombre de la tarea Recursos requeridos (días)

PC de desarrollo

EDU-CIAA LCDs

1 Análisis de periféricos 8

2 Análisis del Firmware de la

CIAA 14

3 Diseño de arquitectura de

software 12

4 Diseño de interfaces 9

5 Diseño de los simuladores 16

6 Configuración de un

entorno de desarrollo 5

7.1 Capa de interacción con el

hardware 4 4

7.2 Capa de interacción con el

simulador 3

7.3 Capa de configuración /

asignación de pines 4 4

7.4 Capa de manejo de

displays 10 10 10

7.5 Capa de interfaces de

usuario 4

8 Implementación del

simulador 19

9 Implementación de las

utilidades misceláneas 6

Página 12 de 20




10 Integración final al

Firmware de la CIAA 10

11 Presentación del proyecto 25

Total 149 18 10

16. Presupuesto detallado del proyecto

Categoría Detalle Costo

Trabajo directo 600hs a $120/hr $72.000

Costos indirectos (30%

del trabajo directo) $21.600

Materiales EDU-CIAA $600

Materiales LCD de caracteres $200

Materiales LCD de matriz de puntos $200

Materiales LCD TFT $300

Otros materiales $300

Costo Total $95.200

Página 13 de 20




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

Nicolás Venturo Responsable

Eric Pernia Colaborador

Mariano Cerdeiro Cliente

1 Análisis de periféricos de la CIAA P

2 Análisis del Firmware de la CIAA P C C

3 Diseño de arquitectura de software P

4 Diseño de interfaces P C

5 Diseño de los simuladores P

6 Configuración de un entorno de

desarrollo

P

7 Implementación de las librerías en el

Firmware

P C

8 Implementación del simulador P

9 Implementación de las utilidades

misceláneas

P

10 Integración final al Firmware de la

CIAA

P A

11 Presentación del proyecto P C

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

Página 14 de 20




18. Gestión de riesgos a) Identificación de riesgos: Riesgo 1: otra persona desarrolla por su cuenta una serie de librerías similares. - Severidad: 7. Gran parte del esfuerzo realizado será trabajo duplicado, pero es probable que ambos

proyectos se puedan alimentar entre sí, y la experiencia como Proyecto Final seguiría siendo válida. - Probabilidad de ocurrencia: 3. SI bien los displays son muy conocidos y utilizados, los usuarios suelen

optar por librerías preexistentes, o implementaciones propias sencillas. - Tasa de no detección: 2. Un desarrollo de este tipo seguramente sería anunciado en las listas de

correo de la comunidad CIAA, o llegará a los oídos de alguno de los encargados del proyecto, los cuales estarán al tanto de este desarrollo. Riesgo 2: el proyecto no es factible técnicamente y no se pueden cumplir los requisitos.

- Severidad: 10. En función de la gravedad de las dificultades encontradas, se deberá hacer una reevaluación potencialmente muy grande del alcance del proyecto. - Probabilidad de ocurrencia: 3. La experiencia indica que no se deberían encontrar obstáculos

insalvables. - Tasa de no detección: 7. La creencia de que el campo es conocido y el orgullo propio puede dificultar

percibir problemas técnicos a tiempo. Riesgo 3: el desarrollo no es de interés para la comunidad CIAA. - Severidad: 4. Uno de los principales objetivos del proyecto es la graduación como Especialista en

Sistemas Embebidos, lo cual no se vería afectado por un desinterés por parte de la comunidad. Sin embargo, podría causar una desmotivación que afecte negativamente a la productividad. - Probabilidad de ocurrencia: 2. El proyecto se encontraba listado en la wiki del proyecto como un

desarrollo útil, y la gran mayoría de los programadores conoce y disfruta trabajar con estos displays. - Tasa de no detección: 4. Si bien se tiene contacto con encargados del proyecto, es posible que los

mismos fallen al captar las necesidades y deseos de la comunidad. Riesgo 4: no es posible conseguir displays con los cuales probar las librerías. - Severidad: 10. Si bien la documentación de estos displays no es escasa, no todos los modelos son

idénticos, y la experiencia indica que para poder asegurar el funcionamiento correcto de un driver es una condición necesaria probar extensivamente los mismos en hardware real. - Probabilidad de ocurrencia: 2. El tesista cuenta con dos de los tres dispositivos requeridos, y los

restantes son fácilmente adquiribles tanto en comercios nacionales como internacionales. Además, siempre existe la posibilidad de obtener un préstamo.

- Tasa de no detección: 6. Debido al momento relativamente tardío en el proyecto en que se comiencen a utilizar los displays, y a la creencia de que aprovisionamiento es sencillo, la tarea de obtención de los mismos será seguramente dejada para último momento, por lo que un problema de este tipo no sería detectado hasta no encontrarse el proyecto ya atrasado. Riesgo 5: las capacidades de la CIAA no son suficientes para utilizar las librerías. - Severidad: 9. Las librerías carecen de sentido si pueden ser utilizadas, y el proyecto resultaría fallido.

Quizás sería posible reducir los requerimientos de procesamiento y/o memoria de las mismas para que puedan ser utilizadas en la CIAA.

Página 15 de 20




- Probabilidad de ocurrencia: 2. La CIAA cuenta con una amplia capacidad de procesamiento para lo que es un microcontrolador normal, y existe amplia variedad de microcontroladores capaces de utilizar estos displays: el overhead agregado por las librerías no debería ser tan grande como para dificultar el funcionamiento. - Tasa de no detección: 6. Similar a los casos anteriores, en el plan de desarrollo normal un problema

de este tipo sólo sería detectado demasiado tarde debido a la gran cantidad de actividades a realizar previas al desarrollo de los drivers. b) Tabla de gestión de riesgos:

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

Detecc * RPN*

1 7 3 2 42

2 10 3 7 210 10 3 3 90

3 4 2 4 32

4 10 2 6 120 10 2 2 40

5 9 2 6 108 9 2 2 36

Criterio adoptado: - Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 100. 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: Los dos riesgos identificados se corresponden a causas externas al desarrollo de las librerías, y ni su severidad ni la probabilidad de ocurrencia pueden ser modificadas: los esfuerzos se concentrarán en detectar estos posibles problemas lo antes posible para maximizar el tiempo de respuesta (dando tiempo, a por ejemplo, realizar una modificación parcial del proyecto que sortee la dificultad encontrada). Riesgo 2: el proyecto no es factible técnicamente y no se pueden cumplir los requisitos. Se consultará con el director de trabajo y otros programadores acerca de la factibilidad técnica del proyecto, y se seguirá con un ojo crítico el avance del mismo, buscando identificar posibles obstáculos insalvables. - Nueva tasa de no detección: 3. Riesgo 4: no es posible conseguir displays con los cuales probar las librerías.

Página 16 de 20




En lugar de dejarse para las últimas etapas de desarrollo, se adquirirán los displays lo antes posible. En caso de no conseguirse unidades inmediatamente, se consultará periódicamente a los vendedores nacionales acerca del estado de las importaciones de dichos componentes. - Nueva tasa de no detección: 2. Riesgo 4: las capacidades de la CIAA no son suficientes para utilizar las librerías. Se realizará un análisis preliminar de requerimientos de memoria y capacidad de procesamiento en la etapa de diseño de las librerías, de modo que se pueda tener una idea pronta de la factibilidad de que las librerías puedan ejecutarse en la CIAA. - Nueva tasa de no detección: 2.

19. Gestión de la calidad

Requerimientos 1.1.1 a 1.1.3: Soporte a los distintos tipos de LCDs en las librerías - Calidad: se satisface si pueden utilizarse las librerías para controlar los LCDs especificados. - Grado de calidad: es mejor si se permite fácil integración para soportar más tipos de displays, o si se

implementan las funcionalidades touch de los TFT. - Costo de conformidad: tiempo de desarrollo y pruebas. - Costo de no conformidad: las librerías no funcionan y el proyecto no cumple su objetivo. - Verificación: contrastar las hojas de datos y manuales de cada LCD con los modos de uso previstos

por el firmware. - Validación: dibujar en cada uno de los distintos LCDs soportados utilizando las librerías. Requerimientos 1.2.1 a 1.2.3: Existencia de distintos tipos de interfaces para el programador - Calidad: se satisface si las librerías pueden ser utilizadas de múltiples maneras y en aplicaciones con

motores de ejecución diferentes.. - Grado de calidad: es mejor si las interfaces son consistentes entre sí, y se reutiliza un gran porcentaje

del código fuente. - Costo de conformidad: tiempo de desarrollo e investigación de proyectos similares. - Costo de no conformidad: las librerías no pueden utilizarse fácilmente en todo tipo de aplicaciones. - Verificación: comparar el diseño de cada tipo de interfaz con interfaces similares, de otros productos. - Validación: crear aplicaciones sencillas (de ejemplo) para cada tipo de uso previsto, utilizando la

interfaz correspondiente. Requerimiento 2.1.1: Software de simulación de displays - Calidad: se satisface si el software permite simular lo que aparecerá en los LCDs, acelerando tiempos

de desarrollo. - Grado de calidad: es mejor si además se soportan las funcionalidades adicionales de los LCDs, como la

inicialización, selección de modo de cursor, etc. - Costo de conformidad: tiempo de desarrollo e investigación del funcionamiento interno de los LCDs. - Costo de no conformidad: la única manera de probar las librerías es con un LCD real. - Verificación: contrastar las hojas de datos y manuales de cada LCD con el funcionamiento pretendido

de los simuladores. - Validación: utilizar las aplicaciones de ejemplo en modo de simulación, y comparar el resultado en el

LCD físico con el simulado.

Página 17 de 20




Requerimientos 2.2.1 y 2.2.2: Software para imágenes y tipografías con código autogenerado - Calidad: se satisface si se facilita la utilización de tipografías personalizadas e imágenes con los LCDs. - Grado de calidad: es mejor si se soportan distintos tamaños y tipo de letra, así como escalamiento de

las imágenes. - Costo de conformidad: tiempo de desarrollo y pruebas. - Costo de no conformidad: el programador debe trabajar arduamente si quiere utilizar tipografías no

soportadas por las librerías, o dibujar imágenes preexistentes. - Verificación: identificar los formatos de imágenes y tipografías más utilizados, y contrastarlos con

aquellos para los que se prevee soporte. - Validación: generar aplicaciones de prueba que utilicen estas funcionalidades, y probarlas en los LCD.

20. 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

Avances generales,

dificultades encontradas

Eric Pernia (colaborador)

Identificar en forma temprana problemas que

puedan retrasar el proyecto.

Mensual E-mail Nicolás Venturo

Definición de arquitectura y funcionalidad del software

Mariano Cerdeiro (cliente)

Obtener feedback del cliente acerca del camino que

está siguiendo el proyecto

(validación).

Única vez E-mail Nicolás Venturo

Existencia y estado del proyecto

Comunidad CIAA

Informar a la comunidad del

proyecto que se está llevando a

cabo, para obtener feedback de los

futuros usuarios.

Trimestral Lista de e-mails

Nicolás Venturo

21. Gestión de Compras

Página 18 de 20




El proyecto sólo requiere de la adquisición de una EDU-CIAA (la cual sólo puede ser adquirida a través de los encargados del proyecto) y de los displays LCD, los cuales son muy fácilmente obtenibles en cualquier comercio de componentes electrónicos en Buenos Aires, por lo que la definición de un proveedor queda sujeta a los distintos precios de venta y disponibilidad.

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.

3. Diseño de arquitectura de

software y 4. Diseño de

interfaces

Se ha completado la especificación

del diseño.

Única (con repeticiones en

caso de requerirse en función del feedback)

Nicolás Venturo Eric Pernia E-mail

7. Implementación de las librerías en el Firmware

Los LCDs pueden ser utilizados

con la EDU-CIAA.

Única Nicolás Venturo Eric Pernia E-mail

8. Implementación del simulador y

9. Implementación de las utilidades

misceláneas

Las funcionalidades

adicionales están completas y se comportan correctamente.

Única Nicolás Venturo Eric Pernia E-mail

10. Integración final al Firmware

de la CIAA

El pull-request al repositorio central está

listo.

Única Nicolás Venturo Mariano Cerdeiro

E-mail

23. Procesos de cierre ● Respecto a la planificación:

Se contrastará el alcance y los requerimientos del proyecto con el resultado final del mismo. En particular, se evaluarán aquellos ítems cuya realización no estaba asegurada, y se estudiará las causas que llevaron a que hayan sido implementados o no. A cargo de: Nicolás Venturo (responsable principal), Eric Pernia.

● Respecto a las técnicas y procedimientos:

Página 19 de 20




Se repasarán las herramientas utilizadas y los motivos por los que fueron elegidas, y se analizará la manera en que se trabajó con ellas, y qué utilidades brindaron al proyecto. Se analizará también qué aspectos del proyecto requirieron más proyecto, y si hubiesen sido beneficiados por procedimientos no llevados a cabo. A cargo de: Nicolás Venturo (responsable principal), Eric Pernia.

Página 20 de 20

Documents

Librerías para manejo de displays en la CIAAlaboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-CESE... · Con el fin de brindar soporte en el proyecto CIAA a las pantallas