entorno de programación educativo en lenguaje python para la...

Plan de Proyecto del Trabajo Final de Carrera

de Especialización de Sistemas Embebidos

Ing. Ernesto Gigliotti

Entorno de programación educativo en lenguaje Python para la EDUCIAANXP

Autor


Director del trabajo

Ing. Eric Pernia

Jurado propuesto para el trabajo

Ing. Pedro Martos Ing. Alejandro Permingeat Ing. Gerardo Sager

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 22




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 22




Registros de cambios

Revisión Cambios realizados Fecha

1.0 Creación del documento 30/03/2016

1.1 Primeras correcciones hasta punto 6 03/04/2016

1.2 Se completó hasta punto 11 08/04/2016

1.3 Correcciones título, gant y matriz responsabilidades 12/04/2016

1.4 Se completó hasta punto 17 15/04/2016

1.5 Correcciones gant 18/04/2016

1.6 Se agregaron los Jurados 08/05/2016

Página 3 de 22




Acta de Constitución del Proyecto

Buenos Aires, 30 de marzo de 2016

Por medio de la presente se acuerda con el Sr. Ernesto Gigliotti que su Proyecto Final de la

Carrera de Especialización en Sistemas Embebidos se titulará “Entorno de programación educativo en

lenguaje Python para la EDUCIAANXP.”, consistirá esencialmente en el soporte del firmware del

proyecto micropython para la placa EDUCIAA, la realización de un entorno de programación y la

generación de documentación y ejemplos, y 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

Director de la CESEFIUBA

Página 4 de 22




Identificación y análisis de los interesados

Rol Nombre y Apellido Departamento Puesto

Auspiciante

Cliente Jurado FIUBA Jurados de la CESE

Impulsor Ernesto Gigliotti

Responsable Ernesto Gigliotti UTNFRA Desarrollador

Colaboradores Martin Ribelotta Responsable

SoftwareIDE del

proyecto CIAA

Orientadores Eric Pernia UNQUI/FIUBA Docente en la

Carrera de Esp. en

Sistemas Embebidos

Equipo

Opositores

Usuario Final Alumnos de nivel

secundario y

universitario

Escuelas secundarias y

universidades

1. Propósito del proyecto

El objetivo principal del proyecto será proveer una herramienta que permita a estudiantes de

educación secundaria y universitaria aprender programación y electrónica, utilizando el lenguaje

Python junto con la plataforma EDUCIAA NXP.

2. Alcance del proyecto

El proyecto incluye el desarrollo del soporte para la placa, de modo que se puedan utilizar desde módulos python, las entradas y salidas de la placa así como también los periféricos básicos como UART, entradas analógicas, etc..

Página 5 de 22




Por otro lado se desarrollará un software a modo de entorno de programación, monoarchivo, que permita escribir el programa que se ejecutará en la placa.

El alcance del proyecto también incluye la realización de proyectos de ejemplo utilizando la placa y el lenguaje Python, así como también la documentación de las bibliotecas desarrolladas para programar.

El proyecto no incluye la implementación de periféricos complejos como ethernet, usb o can.

3. Supuestos del proyecto

Para el desarrollo del presente proyecto se supone que la placa sobre la que se plantea el

desarrollo es accesible a bajo costo y en la cantidad demandada, por alumnos de nivel secundario y universitario.

Se tomará como base el port de micropython para el lpc43xx realizado por Martin Ribelotta el cual incluye la inicialización básica del intérprete Python, la realización de un módulo REPL y la implementación de un Filesystem simple dentro de la memoria Flash del microcontrolador, todas estas características se suponen estables y funcionando.

4. Requerimientos

1. Grupo de requerimientos referidos a las bibliotecas Python disponibles para programar:

1.1 Manejo de los leds que dispone la placa.

1.2 Utilización de los pulsadores.

1.3 Manejo y configuración de los pines designados como GPIO.

1.4 Configuración y utilización de la UART.

1.5 Configuración y utilización de la interface RS485..

1.6 Lectura de las entradas ADC.

1.7 Salida DAC.

1.8 Utilización de la EEPROM interna.

2. Grupo de requerimientos referidos al entorno de desarrollo

2.1 El software deberá ser multiplataforma (Windows/Linux/OSX)

2.2 No debe ser necesario recompilar el firmware de la placa para cambiar el script de python.

2.3 El programa de python se enviará por el COM virtual generado al conectar la placa a la PC.

2.4 El software deberá tener embebida una terminal serial, por donde se implementará la interfaz

de salida y entrada estándar del programa de Python.

2.5 El software deberá tener porciones de código de ejemplo que puedan insertarse fácilmente

junto con lo que el usuario programa (Snippets)

2.6 El software deberá tener links para acceder fácilmente a la documentación online y a los

proyectos de ejemplo.

Página 6 de 22




3. Grupo de requerimientos referidos a los proyectos de ejemplo

3.1 Los proyectos de ejemplo serán divididos en tres categorías: Inicial, Intermedio y Avanzado.

3.2 Los proyectos de ejemplo consistirán en el código fuente, la explicación del mismo en forma

detallada, y un esquemático de conexión con componentes externos en el caso que se

requiera.

3.3 Los proyectos de ejemplo estarán basados en los proyectos típicos de electrónica que se

realizan en escuelas secundarias.

4. Grupo de requerimientos generales

4.1 El acceso a la información del proyecto será libre y gratuita.

4.2 Se publicará la documentación de las bibliotecas de Python disponibles para programar.

5. Entregables principales del proyecto

● Repositorio de firmware. ● Instructivo de instalación de firmware. ● Instalador y código fuente del software entorno de desarrollo. ● Instructivo de utilización del software entorno de desarrollo. ● Repositorio con proyectos de ejemplo. ● Documentación de las bibliotecas Python que pueden utilizarse para programar.

6. Desglose del trabajo en tareas

1. Grupo de tareas respecto al firmware (127 hs)

1.1 Puesta en marcha del core básico de micropython. (12hs)

1.2 Configuración y habilitación de features. (4 hs)

1.3 Creación de una Biblioteca C para el uso de leds. (4 hs)

1.4 Creación de un Módulo Python para el uso de leds. (6 hs)

1.5 Creación de una Biblioteca C para uso de pulsadores. (4 hs)

1.6 Creación de un Módulo Python para uso de pulsadores. (6 hs)

1.7 Creación de una Biblioteca C para uso de la UART. (12 hs)

1.8 Creación de un Módulo Python para uso de la UART. (8 hs)

1.9 Creación de una Biblioteca C para uso de GPIOs. (8 hs)

1.10 Creación de un Módulo Python para uso de GPIOs. (6 hs)

1.11 Creación de una Biblioteca C para uso de ADC. (8 hs)

1.12 Creación de un Módulo Python para uso de ADC. (6 hs)

1.13 Creación de una Biblioteca C para uso de DAC. (4 hs)

1.14 Creación de un Módulo Python para uso de DAC. (5 hs)

1.15 Creación de una Biblioteca C para uso de Timers. (8 hs)

1.16 Creación de un Módulo Python para uso de Timers. (6 hs)

1.17 Creación de una Biblioteca C para el uso de la EEPROM interna. (4 hs)

1.18 Creación de un Módulo Python para uso de la EEPROM interna. (4 hs)

1.19 Implementación de protocolo xmodem para transferir archivo desde el IDE a la placa. (12 hs)

Página 7 de 22




2. Grupo de tareas respecto al software (80 hs)

2.1 Implementación de editor con syntax highlighter. (16 hs)

2.2 Envío de archivo a la placa. (12 hs)

2.3 Menú configuración puerto serie. (8 hs)

2.4 Menú con snippets. (8 hs)

2.5 Terminal serie integrada. (18 hs)

2.6 Instructivo de instalación y uso. (12 hs)

2.7 Generación de instaladores. (6 hs)

3. Grupo de tareas de testing de firmware (100 hs)

3.1 Crear tests unitarios de bibliotecas C (32 hs)

3.2 Crear tests unitarios de módulos Python (40 hs)

3.3 Crear test funcional de cada módulo Python de cada periférico (28 hs)

4. Grupo de tareas de testing de software (44 hs)

4.1 Crear test unitarios para pantalla de terminal integrada. (12 hs)

4.2 Crear test unitarios para pantalla de snippets. (8 hs)

4.3 Crear test unitarios para pantalla de configuración. (4 hs)

4.4 Crear test unitarios para envío de archivo a la placa. (12 hs)

4.5 Test funcional de integración. (8 hs)

5. Grupo de tareas respecto a los proyectos de ejemplo (80 hs)

5.1 Crear al menos 4 proyectos de ejemplo de nivel inicial. (8 hs)

5.2 Crear documentación de los proyectos de nivel inicial. (8 hs)

5.3 Crear al menos 4 proyectos de ejemplo de nivel intermedio. (12 hs)

5.4 Crear documentación de los proyectos de nivel intermedio. (12 hs)

5.5 Crear al menos 4 proyectos de ejemplo de nivel avanzado. (24 hs)

5.6 Crear documentación de los proyectos de nivel avanzado. (16 hs)

6. Grupo de tareas respecto a documentación de bibliotecas (29 hs)

6.1 Crear documentación del módulo de python para el uso de leds. (3 hs)

6.2 Crear documentación del módulo de python para el uso de pulsadores. (3 hs)

6.3 Crear documentación del módulo de python para el uso de la UART. (4 hs)

6.4 Crear documentación del módulo de python para el uso de GPIOs. (3 hs)

6.5 Crear documentación del módulo de python para el uso de leds. (3 hs)

6.6 Crear documentación del módulo de python para el uso de ADC. (3 hs)

6.7 Crear documentación del módulo de python para el uso de DAC. (3 hs)

6.8 Crear documentación del módulo de python para el uso de Timers. (4 hs)

6.9 Crear documentación del módulo de python para el uso de la EEPROM. (3 hs)

Página 8 de 22




7. Grupo de tareas respecto a la escritura del trabajo (92hs)

7.1 Escribir memoria del trabajo (80 hs)

7.2 Escribir presentación (12 hs)

Total de horas: 552hs

7. Diagrama de Activity On Node

NOTA: Las tareas 2.x y 3.x se han indicado que pueden ser resueltas de forma simultánea, sin embargo

debido a que existirá un solo programador en el proyecto las tareas se desarrollarán en forma

consecutiva.

Página 9 de 22




8. Diagrama de Gantt

Página 10 de 22




Página 11 de 22




Página 12 de 22




Página 13 de 22




Página 14 de 22




9. Matriz de uso de recursos de materiales

Código WBS

Nombre de la tarea

Recursos requeridos (horas)

PC EDUCIAA NXP

1.x Desarrollo de

Firmware

127 hs 127 hs

2.x Desarrollo IDE 80hs 0hs

3.x Testing Firmware 100hs 100hs

4.x Testing IDE 44hs 20hs

5.x Proyectos de

ejemplo

80hs 80hs

6.x Documentación

bibliotecas

29hs 0hs

7.x Escribir trabajo final

y presentación

92hs 0hs

10. Presupuesto detallado del proyecto

Categoría Detalle Costo

Costo directo 600hs a $120/hr $72.000

Costo indirecto 30% del costo directo $21.600

Materiales EDUCIAA NXP $750

TOTAL $94.350

Página 15 de 22




11. Matriz de asignación de responsabilidades

Código WBS

Título de la tarea

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

Ernesto Gigliotti

Responsable

Martin Riobelotta

Colaborador

Eric Pernia

Orientador

Alumnos escuelas secundarias y universidades

Usuario

1.x Desarrollo de

Firmware

P C A I

2.x Desarrollo IDE P A I

3.x Testing Firmware P A

4.x Testing IDE P A

5.x Proyectos ejemplo P A I

6.x Documentación

bibliotecas

P A I

7.x Escribir trabajo final P A

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

12. Gestión de riesgos Riesgo 1: El código fuente implementado no cabe en la memoria del microcontrolador de la placa.

● Severidad (S)=7. Es una limitante en la cantidad de periféricos a los que se les puede dar soporte para poder ser utilizados desde el lenguaje Python.

● Probabilidad de ocurrencia (O)=3. El microcontrolador utilizado posee una gran cantidad de memoria de programa, por lo que es poco probable que ocurra.

● Tasa de no detección (D)=5. Es difícil estimar cuánto espacio va a ocupar un código que todavía no se programó.

Página 16 de 22




Riesgo 2: Pérdida de los materiales de trabajo (placa o PC) ● Severidad (S)=2. Existen muchas en el mercado, es muy simple conseguir un reemplazo (ya sea

la placa o una PC) ● Probabilidad de ocurrencia (O)=3. No es muy probable que ocurra. Aunque es posible por una

mala manipulación de la placa o caso de robo. ● Tasa de no detección (D)=8. Es muy complicado saber cuando va a ocurrir un accidente de este

tipo con antelación. Riesgo 3: No se llegan a cumplir todos los requerimientos.

● Severidad (S)=5. Puede limitarse el proyecto a tener menos soporte de hardware en una primera versión, y luego incluir más horas para completarlo.

● Probabilidad de ocurrencia (O)=4. No es muy probable que ocurra ya que se pretende que el proyecto sea el trabajo final de una carrera de especialización y se terminará a tiempo.

● Tasa de no detección (D)=2. Si las tareas están bien estimadas, es fácil detectar si se llegará a tiempo a completarlas todas.

Riesgo 4: La plataforma no es utilizada por la comunidad CIAA. Si la documentación es confusa y es dificultoso comenzar a utilizar la placa con el firmware y el IDE desarrollados, el proyecto probablemente sea ignorado.

● Severidad (S)=8. Si la plataforma no es utilizada el proyecto pierde todo su sentido, ya que ésta fue la razón de existencia del mismo.

● Probabilidad de ocurrencia (O)=2. Como parte de las tareas a desarrollar se declararon las relacionadas a la creación de ejemplos y documentación, por lo que no es probable que ocurra.

● Tasa de no detección (D)=3. Al ser parte de los requerimientos, en la etapa de validación y verificación se detectará el problema.

Riesgo 5: La memoria RAM del microcontrolador no es suficiente para la implementación de todos los drivers y módulos de python.

● Severidad (S)=8. No podrán implementarse los módulos de python deseados, limitando lo que luego será posible hacer con la placa.

● Probabilidad de ocurrencia (O)=7. La placa EDUCIAA NXP no posee los chips de memoria externa, y la cantidad de memoria RAM que posee el microcontrolador no es tanta, por lo que es posible que este hecho ocurra.

● Tasa de no detección (D)=1. La mayor parte de la memoria es consumida por el port de micropython en sí y no por los drivers agregados, por lo que es posible detectar este problema antes de comenzar el desarrollo de los drivers.

Página 17 de 22




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 7 3 5 105 5 3 3 45

2 2 3 8 48

3 5 4 2 40

4 8 2 4 64 5 1 3 15

5 8 7 1 56

Criterio adoptado: Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 60 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: Plan de mitigación: Pueden programarse algunas rutinas en assembler para que ocupen menos espacio.

● Severidad (S)=5. Aunque es más trabajoso de realizar y quizá menos portable, con esta solución se solucionaría el problema.

● Probabilidad de ocurrencia (O)=3. No es probable que ocurra ya que la memoria disponible es grande.

● Tasa de no detección (D)=3. Se estima de antemano que el código en ASM ocupa un tercio del código en C.

Riesgo 4: Plan de mitigación: Se deberán reevaluar los ejemplos desarrollados y generar contenido multimedia (Videos, notas, presentaciones, fotos, etc) que ayude a la comprensión y utilización de la plataforma.

● Severidad (S)=5. Se sumará más tiempo de proyecto del requerido. ● Probabilidad de ocurrencia (O)=1. Al agregar material informativo bajará la probabilidad de que

ocurra el riesgo. ● Tasa de no detección (D)=3. Al ser parte de los requerimientos, en la etapa de validación y

verificación se detectará el problema.

Página 18 de 22




13. Gestión de la calidad Para cada uno de los requerimientos del proyecto indique: ■ Req #1.x: Grupo de requerimientos referidos a las bibliotecas Python disponibles para programar. ◆ Verificación y validación: Responsable de la verificación: Ernesto Gigliotti Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se realizarán tests de todos los módulos y drivers desarrollados. Responsable de la validación: Ernesto Gigliotti Validación a aplicar para medir el cumplimiento de lo requerido:

> Se revisarán los ejemplos generados en donde se utilizan los módulos de Python disponibles, de esta forma se valida si se cubrió la utilización de los periféricos requeridos. ■ Req #2.x: Grupo de requerimientos referidos al entorno de desarrollo. ◆ Verificación y validación: Responsable de la verificación: Ernesto Gigliotti Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se realizarán tests unitarios de la mayoría de las partes del software. Responsable de la validación: Ernesto Gigliotti Validación a aplicar para medir el cumplimiento de lo requerido: > Se probará el ejecución del software en los diferentes sistemas operativos para los que fue diseñado y su correcto funcionamiento y conectividad con la placa. ■ Req #3.x: Grupo de requerimientos referidos a los proyectos de ejemplo. ◆ Verificación y validación: Responsable de la verificación: Ernesto Gigliotti Verificación a aplicar para intentar saber si se cumplirá con lo requerido:

> Se revisará el correcto funcionamiento de los ejemplos generados, chequeando que cumplan con su propósito. Responsable de la validación: Ernesto Gigliotti Validación a aplicar para medir el cumplimiento de lo requerido: > Se revisarán las explicaciones poniéndose del punto de vista del usuario, para asegurarse de un claro entendimiento de las mismas. ■ Req #4.x: Grupo de requerimientos generales. ◆ Verificación y validación: Responsable de la verificación: Ernesto Gigliotti Verificación a aplicar para intentar saber si se cumplirá con lo requerido: > Se evaluará que sea posible publicar la información en la web del proyecto CIAA. Responsable de la validación: Ernesto Gigliotti Validación a aplicar para medir el cumplimiento de lo requerido: > Se pedirá a un grupo reducido de personas que prueben la plataforma para asegurarse de que la información brindada sea la correcta.

Página 19 de 22




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

Avances generales

Eric Pernia (Director)

Mantener informado y

obtener ideas y consejos.

Mensual email Ernesto Gigliotti

Existencia del

proyecto

Comunidad CIAA

Informar la existencia e incentivar la participación en el proyecto.

Mensual email Ernesto Gigliotti

Nuevas features para

microython

Martin Ribelotta

(Colaborador)

Agregar al port de

micropython lo desarrollado.

Cuando existan

versiones estables

Pull Requests mediante GITHUB

Ernesto Gigliotti

14. Gestión de Compras No se realizará ninguna compra para la realización del proyecto ya que se cuenta con todos los materiales necesarios para el proyecto.

Página 20 de 22




16. Seguimiento y control

SEGUIMIENTO DE AVANCE

Tarea del WBS

Indicador de avance Frecuencia de reporte

Responsable de seguimiento

Persona a ser

informada

Método de comunicac.

1.x Cantidad de periféricos soportados

única vez Ernesto Gigliotti

Eric Pernia email

2.x Software Completo y estable


Eric Pernia email

3.x Los tests pasaron satisfactoriamente


Eric Pernia email

4.x Los tests pasaron satisfactoriamente


Eric Pernia email

5.x Cantidad de ejemplos desarrollados


Eric Pernia email

6.x Cantidad de bibliotecas

documentadas


Eric Pernia email

7.x Se terminó de escribir el trabajo final


Eric Pernia email

Página 21 de 22




17. Procesos de cierre ■ Pautas de trabajo que se seguirán para analizar si se respetó el Plan de Proyecto original: Se revisará que se hayan cumplido los requerimientos, comparándolos con el proyecto terminado. A cargo de Ernesto Gigliotti. ■ Identificación de las técnicas y procedimientos útiles e inútiles que se utilizaron, y los problemas que surgieron y cómo se solucionaron: Para verificar si las tareas fueron realizadas en el tiempo esperado, se comparará el cronograma propuesto con el real, detectando las que llevaron mucho más tiempo de lo planeado y de esta forma poder analizar en dónde falló la planificación. A cargo de Ernesto Gigliotti. ■ Por último se enviará un email de agradecimiento al director de la tesis y los colaboradores del proyecto, así como también a los coordinadores de la carrera y toda la gente que se sume a utilizar y probar la plataforma durante el transcurso del desarrollo.

Página 22 de 22

entorno de programación educativo en lenguaje python para la...

Documents