Carrera de Especialización en Sistemas Embebidos

Desarrollo de Firmware y Software para programar la CIAA en lenguaje JAVA con aplicación en entornos Industriales Universidad de Buenos Aires, Facultad de Ingeniería

Ing. Eric Nicolás Pernia 05/06/2015

2

Contenido 1. Project Charter ...................................................................................................................................................... 4

2. Propósito del proyecto .......................................................................................................................................... 4

3. Objetivos del proyecto .......................................................................................................................................... 5

4. Interesados (stakeholders) .................................................................................................................................... 5

5. Requerimientos ..................................................................................................................................................... 6

5.1. Firmware ........................................................................................................................................................ 6

5.2. Software, IDE para Java sobre CIAA ............................................................................................................... 6

5.3. Aplicaciones Industriales ................................................................................................................................ 6

5.4. Documentación y difusión.............................................................................................................................. 6

6. Alcance del proyecto ............................................................................................................................................. 6

6.1. Justificación .................................................................................................................................................... 6

6.2. Restricciones .................................................................................................................................................. 6

6.3. Suposiciones ................................................................................................................................................... 7

6.4. Alcance ........................................................................................................................................................... 7

6.4. Criterio de aceptación .................................................................................................................................... 7

7. Análisis de factibilidad técnica .............................................................................................................................. 7

7.1. Java ................................................................................................................................................................. 7

7.2. Elección de la VM de Java, HVM .................................................................................................................... 7

7.3. IDE Icecaptools ............................................................................................................................................... 8

7.4. Porting de HVM e icecaptools a una nueva arquitectura .............................................................................. 9

7.5. Aplicación real-time de referencia .............................................................................................................. 10

8. Análisis de factibilidad financiera-económica ..................................................................................................... 10

9. Work breakdown structure (WBS) ...................................................................................................................... 10

10. Activity On Node (AON)..................................................................................................................................... 11

11. Diagrama de Gantt ............................................................................................................................................ 12

12. Matriz de recursos materiales y el detalle del presupuesto correspondiente ................................................. 12

13. Plan de gestión de riesgos ................................................................................................................................. 14

14. Plan de gestión de calidad ................................................................................................................................. 14

15. Gestión de costos .............................................................................................................................................. 14

16. Plan de verificación y validación ....................................................................................................................... 15

17. Plan de comunicación ....................................................................................................................................... 15

18. Gestión de RRHH ............................................................................................................................................... 16

19. Gestión de compras y Statement Of Work ....................................................................................................... 17

20. Procesos de control y seguimiento ................................................................................................................... 17

21. Proceso de cierre ............................................................................................................................................... 17

3

Anexo I – Diagrama de Gantt .................................................................................................................................. 18

4

1. Project Charter

Quilmes, 5 de junio de 2015 De mi consideración: Con el objetivo de crear un ambiente de Firmware y Software para programar la Computadora Industrial Abierta Argentina (CIAA), en un lenguaje de programación orientado a objetos (POO) para aplicaciones industriales en tiempo real; se asigna este proyecto al Ing. Eric Pernia, quien actuará como gerente del mismo, con el fin de comenzar los trabajos de investigación, análisis de requerimientos, diseño e implementación del Firmware y software. Se entregará como resultado del proyecto, el firmware y software a realizar junto a la documentación y manuales correspondientes. La fecha de finalización del mismo, está prevista para el 15 de Diciembre de 2015. El proyecto será llevará a cabo en la oficina 125 de la UNQ. Se utilizará el presupuesto de un proyecto de investigación previo de la Universidad Nacional de Quilmes (UNQ), ya que el presente proyecto es un subproducto del mismo. El recurso principal a emplear consistirá en horas de trabajo de los miembros del equipo, que se estima en 160 horas mensuales (aproximadamente 960 horas en total). Sin otro particular, saluda atentamente,

_____________________________ Secretaría de investigación UNQ

2. Propósito del proyecto

El propósito del proyecto es la incorporación de nuevas tecnologías en ambientes industriales mediante el desarrollo de arquitecturas de sistemas embebidos novedosas. En particular, permitir crear aplicaciones Real-Time para entornos industriales, utilizando un lenguaje de programación orientado a objetos (POO), sobre la Computadora Industrial Abierta Argentina (CIAA). Además, se espera acercar a programadores informáticos a la disciplina de programación de sistemas embebidos. Finalmente, se desea reforzar los lazos de colaboración entre las carreras ingeniería en automatización y control industrial e ingeniería informática a través de los miembros del proyecto, ambos profesionales de las respectivas carreras.

5

3. Objetivos del proyecto Los objetivos del presente proyecto son:

Permitir que la CIAA-NXP y EDU-CIAA-NXP puedan programarse en Java1 realizando el porting2 del Firmware de la Hardware Virtual Machine (HVM3).

Integración de HVM con el Firmware de la CIAA para permitir el acceso al hardware desde el programa de usuario en Java.

Adaptación de Icecaptools4 para CIAA.

Realizar una aplicación Real-Time (SCJ) de referencia para testear el funcionamiento del sistema.

Documentar el proyecto para permitir futuras ampliaciones.

Redactar manuales de usuario.

Compartir el software, documentación y manuales con la comunidad de la CIAA.

Fecha de entrega 15/12/2015.

4. Interesados (stakeholders)

Clients

Universidad Nacional de Quilmes (UNQ) - Secretaría de investigación. Universidad de Buenos Aires (UBA) - Director de la Carrera Especialización en Sistemas Embebidos (CESE) Dr. Ing. Ariel Lutemberg.

Sponsor

Universidad Nacional de Quilmes (UNQ) - Secretaría de investigación. End-user

Comunidad de usuarios y desarrolladores del proyecto CIAA. Programadores informáticos que quieran incursionar en la programación de sistemas embebidos.

Champion

Director de la carrera Ingeniería en Automatización y Control Industrial (IACI), departamento de Ciencia y Tecnología (Dto. CyT) de la UNQ, Mg. Ing. Felix Safar. Drivers

Ing. Eric Pernia, Ing. Leonardo Gassman, Mg. Ing. Felix Safar y desarrolladores de la CIAA. Supporters

Dto. CyT de la UNQ y desarrolladores del proyecto CIAA. Project manager

Ing. Eric Pernia. Team members

Ing. Eric Pernia e Ing. Leonardo Gassman.

1 Java es uno de lenguajes de POO más utilizados en la actualidad. 2 Realizar un “porting” significa en este caso adaptar un software a otra arquitectura de hardware diferente a la que fue diseñado originalmente. 3 HVM es una máquina virtual (VM) de Java, libre, que cumple con la especificación Safet- Critical Java (SCJ). 4 Icecaptools es un plug-in de Eclipse realizado por Stephan Erbs Korsholm, que convierte al Eclipse en un IDE para la programación en lenguaje Java y permite compilar el programa de usuario para HVM.

6

5. Requerimientos

Los requerimientos del proyecto fueron establecidos en base a reuniones entre el project manager, los team members y el champion, para proponer una solución que permita la aplicación de un lenguaje de programación orientado a objetos, moderno, y de uso masivo, como Java, para la programación de sistemas embebidos en ambientes industriales con requerimientos de tiempo real. De una investigación llevada a cabo previamente, surge como solución posible la utilización de las herramientas HVM e Icecaptools como software. Se desea entonces realizar el porting de dichas herramientas para la CIAA y extender sus capacidades. Para lograrlo, se identifican los siguientes requerimientos:

5.1. Firmware Realizar el porting del Firmware de la Hardware Virtual Machine (HVM) permitiendo que la que la CIAA-

NXP y EDU-CIAA-NXP puedan programarse en lenguaje Java.

Integración de HVM con el Firmware de la CIAA para permitir el acceso al hardware desde el programa de usuario en Java.

Realizar aplicaciones de ejemplos utilizando el hardware.

5.2. Software, IDE para Java sobre CIAA Adaptación de Icecaptools para CIAA.

Programación de un nuevo plug-in, al que llamaremos CIAA4HVM, para Icecaptools.

5.3. Aplicaciones Industriales Realizar una aplicación de referencia, con especificadores de tiempo real, para comprobar el

cumplimiento de la especificación SCJ.

5.4. Documentación y difusión Documentación del proyecto para permitir futuras ampliaciones.

Manuales de usuario.

Compartir el software, documentación y manuales con la comunidad de la CIAA.

6. Alcance del proyecto

6.1. Justificación Con la experiencia adquirida a partir del proyecto de investigación orientado por la práctica profesional de la UNQ, titulado: “Estrategias de desarrollo de sistemas embebidos en ambientes de automatización y control industrial. Un enfoque de programación con objetos y servicios web” [i]; donde se investigó, entre otras cosas, la programación de sistemas embebidos en tiempo real mediante lenguajes de POO y se realizó el porting de de HVM e Icecaptools a la plataforma STM32F4 Discovery (con arquitectura ARM Cortex-M4); se identificó un camino válido para lograr la programación en objetos y en tiempo real de sistemas embebidos.

6.2. Restricciones Se desarrollarán herramientas de firmware y software para las placas EDU-CIAA-NXP y CIAA-NXP.

En la, CIAA-NXP se integrarán todas las entradas y salidas, tanto digitales como analógicas (borneras). En el caso de la EDU-CIAA-NXP, se fijará el propósito de 8 pines como entradas digitales, 8 como salidas digitales, 2 como entradas analógicas y 1 como salida analógica.

Cada uno de los team members dedicará veinte (20) horas semanales al proyecto. De lunes a viernes, es decir, 4 horas diarias.

Fecha de comienzo del proyecto 15/06/2015.

7

Fecha de culminación del proyecto 15/12/2015.

6.3. Suposiciones Se dispone de los puestos de trabajo.

Se dispone de una EDU-CIAA-NXP.

Las horas de trabajo planificadas son suficientes para alcanzar el deadline.

No se reasignará a ninguno de los integrantes a otro proyecto.

No ocurrirán eventos fortuitos ni de fuerza mayor que limiten la cantidad de horas semanales asignadas a este proyecto.

6.4. Alcance En base al proyecto mencionado en [i], y en apoyo al proyecto CIAA, se desea entonces realizar el porting de HVM e Icecaptools para la CIAA, así como completar y ampliar las funcionalidades desarrolladas como prueba de concepto para la STM32F4 Discovery. Se espera obtener una plataforma de firmware y software que permita la programación de aplicaciones Real-Time para la CIAA en lenguaje Java cumpliendo todos los requerimientos y con las restricciones expuestas en 5.

6.4. Criterio de aceptación Para probar el correcto funcionamiento de las herramientas a entregar, se realizará una aplicación de referencia con especificadores de tiempo real. Luego se testeará dicha aplicación para comprobar el cumplimiento de las especificaciones. Finalmente, se entregará la misma a los clients a la espera de su posterior aprobación.

7. Análisis de factibilidad técnica

Los team members del proyecto poseen experiencia comprobable a través del proyecto de investigación previo citado en [i] referente a las áreas de conocimiento. Este proyecto propone portar HVM e Icecaptools a la CIAA tanto en firmware como software para permitir la programación en Java. En las siguientes secciones se detallan las herramientas elegidas para llevar a cabo el proyecto.

7.1. Java Se elije Java debido a que es uno de lenguajes de POO más utilizados en la actualidad. Es un lenguaje moderno, con manejo de memoria automático y sintaxis similar a C++. A diferencia de otros, en lugar de compilarse para la arquitectura del controlador objetivo, se compila a un lenguaje similar al assembler (bytecodes) que se ejecuta mediante una Máquina Virtual, o VM, por sus siglas en inglés (Virtual Machine). Esta máquina virtual corre habitualmente sobre un sistema operativo.

7.2. Elección de la VM de Java, HVM HVM son las siglas de Hardware Virtual Machine. Es una máquina virtual (VM) de Java libre, diseñada para ejecutarse bare metal5 sobre microcontroladores y portable a diferentes arquitecturas. Su implementación de referencia fue realizada por Stephan Erbs Korsholm (Icelab, Dinamarca) para su tesis doctoral. Esta VM cumple con la especificación Safety-Critical Java (SCJ) Level 0, 1 y 2 permitiendo realizar aplicaciones en tiempo real para sistemas críticos. Provee 3 formas de acceso al hardware:

5 Significa que se ejecuta directamente sobre el hardware, sin necesidad de un sistema operativo.

8

Variables Bindeadas.

Hardware Objects.

Métodos nativos. La última forma, métodos nativos, se elige como alternativa para proveer al programa de usuario en lenguaje Java el acceso al hardware.

7.3. IDE Icecaptools Icecaptools es un plug-in de Eclipse realizado por Stephan Erbs Korsholm, que convierte al Eclipse en un IDE para la programación en lenguaje Java y permite compilar el programa de usuario para HVM. Funciona realizando una traducción de un programa de usuario escrito en lenguaje Java, a un programa en lenguaje C que incluye el código de dicho programa y el código C generado de HVM. De esta manera, logra portabilidad entre diferentes microcontroladores y permite integración con programas escritos previamente en lenguaje C, como por ejemplo, el firmware de la CIAA. Requiere un toolchain de lenguaje C, para el microcontrolador objetivo, que permita compilar el código, generando un binario ejecutable, y su posterior descarga a dicho dispositivo. En la figura 1 se incluye un esquema gráfico de su funcionamiento.

Figura 1. Filosofía de Icecaptools.

9

7.4. Porting de HVM e icecaptools a una nueva arquitectura Para portar el Firmware HVM a una nueva arquitectura deben realizarse los siguientes pasos:

Conseguir un ambiente de desarrollo en lenguaje C para la arquitectura.

Estandarizar los tamaños de tipos de datos.

Implementar una HAL para la arquitectura.

Implementar el acceso al hardware. Para facilitar la inclusión de nuevas arquitecturas a icecaptools y automatizar tareas habituales, que en caso contrario debería realizar el usuario para cada nueva aplicación, se propone:

Adaptar Icecaptools para la arquitectura ARM mediante su extensión a través de un plug-in que llamaremos HvmForArmCortexM.

La programación de un segundo plug-in más específico llamado HVM4CIAA. Finalmente, en la figura 2 se grafica la solución propuesta para lograr utilizar icecaptools y HVM con la CIAA.

Figura 2. Solución propuesta.

10

7.5. Aplicación real-time de referencia Una vez realizado el porting para la CIAA se realizará una aplicación de referencia para comprobar el funcionamiento en tiempo real. Se establecerán los requerimientos de la misma, se investigarán y aplicaran técnicas de testeo. Una vez realizado el testeo se entregará la aplicación al client para su posterior aprobación.

8. Análisis de factibilidad financiera-económica Este proyecto se enmarca en la continuación del proyecto de investigación de la UNQ [i] y se utilizará como proyecto final en el posgrado “Carrera de Especialización en Sistemas Embebidos” y su resultado consistirá en herramientas de firmware y software para programar la CIAA, cuyo código se liberará a la comunidad. Los recursos económicos han sido asignados previamente por la UNQ para el proyecto de investigación [i] y no existirá una tasa interna de retorno, al no existir una inversión cuantificable.

9. Work breakdown structure (WBS)

El siguiente WBS está organizado a partir de sus entregables. 1. Proyecto de Firmware y Software para permitir la programación de la CIAA en lenguaje JAVA (SCJ). 1.1. Firmware.

1.1.1. Realizar el porting del Firmware de la Hardware Virtual Machine (HVM) permitiendo que la que la CIAA-NXP y EDU-CIAA-NXP puedan programarse en lenguaje Java. 1.1.2. Integración de HVM con el Firmware de la CIAA para permitir el acceso al hardware desde el programa de usuario en Java.

1.1.3. Realizar aplicaciones de ejemplo utilizando el hardware. 1.1.4. Documentación de Firmware. 1.2. Software, IDE para Java sobre CIAA. 1.2.1. Adaptación de Icecaptools para CIAA. 1.2.2. Programación del plug-in CIAA4HVM para Icecaptools. 1.2.3. Documentación de Software. 1.3. Generación de una aplicación industrial de referencia. 1.3.1. Realizar una aplicación de referencia con especificadores de tiempo real (SCJ). 1.3.2. Testear dicha aplicación para comprobar el cumplimiento de las especificaciones. 1.3.3. Documentación de comportamiento de la aplicación en tiempo real. 1.4. Entrega a los clients para aprobación del firmware, software y aplicación de referencia. 1.5. Manuales de usuario. 1.5.1. Manual de Instalación. 1.5.2. Manual de utilización. 1.6. Difusión del firmware y software. 1.6.1. Subida de documentación y manuales a la wiki del proyecto CIAA. 1.6.2. Creación de lista de correo para desarrolladores en Java. 1.6.3. Subida del firmware y software al repositorio del proyecto CIAA. 1.6.4. Anuncio en las listas de correo para desarrolladores de la CIAA y embebidos 32.

11

10. Activity On Node (AON)

Este AON está definido en base a “días” como unidad de tiempo de las tareas. El mismo se muestra en la figura 3. Para su realización se tuvo en cuenta la dependencia entre tareas y la disponibilidad de los team members. Los recuadros con doble borde indican los hitos, mientras que los recuadros con borde simple, indican las tareas necesarias para alcanzarlos. El camino crítico está dado por el recorrido de las tareas:

1.1.1. -> -> 1.1.2. -> 1.2.2. -> 1.2.3. -> -> 1.3.1. -> 1.3.2. -> 1.3.3. -> -> 1.4. -> -> 1.5.1. -> 1.5.2. -> -> 1.6.1. -> 1.6.2. -> 1.6.3. -> 1.6.4.

Este camino crítico es de 106 días hábiles en total y se indica con bordes más gruesos en la figura 3. El único camino semicrítico es el camino que pasa por la secuencia 1.1.3. -> 1.1.4. Estas dos tareas tienen una duración de 11 días en contraste con el camino crítico que pasa por 1.1.2. -> 1.2.3. cuya duración es de 18 días.

Figura 3. AON.

12

11. Diagrama de Gantt

El diagrama de Gantt6 muestra en la figura 4. Además, se adjunta debido a su tamaño, en formato pdf, en el Anexo I. Los títulos en azul representan los hitos. Para la realización del diagrama se tuvo en cuenta la participación de dos ingenieros destinados para la realización de las tareas (los team members), algunas de las cuales serán rezadas por cada uno de ellos y otras por la colaboración entre ambos. En la sección 18. Se detallan las responsabilidades de cada uno de ellos. Los mismos trabajarán en el proyecto cuatro horas diarias, de lunes a viernes, a excepción de feriados y otros (tenidos en cuenta en el diagrama).

Figura 4. Diagrama de Gantt.

12. Matriz de recursos materiales y el detalle del presupuesto

correspondiente

Los materiales necesarios serán una oficina con dos puestos de trabajo (uno para cada team member) y una única placa EDU-CIAA-NXP. Cada puesto de trabajo consiste en un escritorio, con silla y una PC con conexión a internet. De esta forma la matriz de recursos materiales es:

Actividad Recursos requeridos (horas)

Código WBS Descripción Puesto de trabajo EDU-CIAA-NXP

1.1.1.

Realizar el porting del Firmware de la Hardware Virtual Machine (HVM) permitiendo que la que la CIAA-NXP y EDU-CIAA-NXP puedan programarse en lenguaje Java.

64 64

6 Este diagrama ha sido generado con el software on line SmartSheet, en https://es.smartsheet.com/. Este software permite la administración de tareas como ser duración, fecha de inicio, de finalización, responsabilidades y seguimiento del estado.

13

1.1.2. Integración de HVM con el Firmware de la CIAA para permitir el acceso al hardware desde el programa de usuario en Java.

36 36

1.1.3. Realizar aplicaciones de ejemplo utilizando el hardware.

28 28

1.1.4. Documentación de Firmware. 16 0

1.2.1. Adaptación de Icecaptools para CIAA. 52

1.2.2. Programación del plug-in CIAA4HVM para Icecaptools.

48 48

1.2.3. Documentación de Software. 24 0

1.3.1. Realizar una aplicación de referencia con especificadores de tiempo real (SCJ).

112 56

1.3.2. Testear dicha aplicación para comprobar el cumplimiento de las especificaciones.

160 80

1.3.3. Documentación de comportamiento de la aplicación en tiempo real.

48 0

1.4. Entrega a los clients para aprobación del firmware, software y aplicación de referencia.

0 0

1.5.1. Manual de Instalación. 12 0

1.5.2. Manual de utilización. 24 0

1.6.1. Subida de documentación y manuales a la wiki del proyecto CIAA.

16 0

1.6.2. Creación de lista de correo para desarrolladores en Java.

4 0

1.6.3. Subida del firmware y software al repositorio del proyecto CIAA.

12 0

1.6.4. Anuncio en las listas de correo para desarrolladores de la CIAA y embebidos 32.

4 0

Total de horas por recurso 660 312

Tabla 1. Matriz de recursos materiales.

El presupuesto se resume en la siguiente tabla:

Categoría Detalle Costo

Costos directos

Ing. Eric Pernia. 94 días de trabajo de 4 horas, a $120 la hora.

$ 45.120,00

Ing. Leonardo Gassman. 73 días de trabajo de 4 horas, a $100 la hora.

$ 29.200,00

Costos indirectos

Estimados como el 60% de los costos directos

$ 44.592,00

Reserva para contingencia

Estimados como el 15% de la suma de los costos directos y los costos indirectos.

$ 17.836,80

Total $ 136.748,80

Tabla 2. Presupuesto.

14

13. Plan de gestión de riesgos

En la tabla 3 se muestra la tabla de gestión de riesgos:

Nº Riesgo O S D RPN Acción correctiva O S D RPN

1 Requerimientos no cumplidos.

6 10 5 300 Se destinarán más horas para reparar los errores.

4 7 4 112

2

Las autoridades de la UNQ disponen de los team members para otras actividades reduciendo la dedicación al proyecto.

8 9 4 288

Se solicitará a los team members trabajar más horas fuera del horario de la facultad.

6 7 2 84

3 Horas de trabajo planificadas insuficientes para alcanzar el deadline.

5 10 3 150 Se destinarán más horas de los team members para este proyecto.

2 5 1 10

4 Se rompe la placa EDU-CIAA-NXP.

2 7 10 140 Se reemplazará por otra placa.

1 4 6 24

5 No se dispone de los puestos de trabajo.

2 8 6 96 Se solicitará a los team members trabajar desde sus casas.

1 6 3 18

Ocurrencia [O]: 1 (muy baja) a 10 (muy alta). Severidad [S]: 1 (muy baja) a 10 (muy alta). Detectabilidad [D]: 1 (muy alta) a 10 (muy baja).

Tabla 3. Gestión de riesgos.

14. Plan de gestión de calidad

La calidad del firmware y software resultantes del proyecto estarán determinadas por el seguimiento del cumplimiento de los requerimientos funcionales propuestos en 5. que se comprobarán mediante las tareas de validación y verificación internas especificadas en 16. El detalle de la documentación también influirá en la calidad resultante del proyecto. Como esta plataforma será innovadora, es muy difícil comprobar el grado de calidad. En un proyecto posterior podrían realizarse pruebas de performance con otras alternativas de máquinas virtuales y herramientas para la programación en Java de microcontroladores. Sin embargo, esto implicaría volver a realizar el trabajo de porting para la plataforma CIAA.

15. Gestión de costos En la siguiente tabla se exponen los costos de calidad del proyecto.

Detalle Costo

Costos de conformidad

Costos de prevención

Entrenamiento en técnicas de testing de software.

$ 8.800,00

Revisión de documentación. $ 880,00

15

Costos de evaluación

Programación de tests unitarios de cada módulo.

$ 3.360,00

Programación de tests de integración.

$ 4.520,00

Tests de aplicación de referencia. $ 17.600,00

Costos No conformidad

Costos de fallas internas

Fallos de firmware que impliquen reprogramación.

$ 7.200,00

Fallos de software que impliquen reprogramación.

$ 6.000,00

Fallos de integración que impliquen reprogramación.

$ 12.320,00

Errores en documentación. $ 5.240,00

Costos de fallas externas

No aprobación por parte de los clients del firmware, software y aplicación de referencia entregados.

$ 30.760,00

Costo total de calidad $ 96.680,00

Tabla 4. Costos de calidad.

16. Plan de verificación y validación

Al concluir cada tarea propuesta en el WBS se deberá verificar que el cumplimiento de los requerimientos. Esta tarea será responsabilidad del team member a cargo de la misma. Una vez aprobada por parte del team member, el mismo deberá informar al project manager, para solicitar su aprobación final. Como validación interna se realizarán en principio aplicaciones de ejemplo para comprobar el correcto funcionamiento del hardware con el Firmware HVM propuestas (WBS 1.1.3.). Después para comprobar las funcionalidades real time se plantea en realizar una aplicación de referencia con especificaciones de tiempo real (WBS 1.3.1.) y someterá la misma a técnicas de testing (WBS 1.3.2.). Una vez realizadas las validaciones internas se realizará una validación externa llevada a cabo por los clients, en espera de su conformidad para seguir adelante con el proyecto. Luego de la finalización del proyecto y puesta a disposición de las herramientas para la comunidad de usuarios y desarrolladores del proyecto CIAA, se tendrá en cuenta las sugerencias para una futura versión que consistirá en otro proyecto.

17. Plan de comunicación

La comunicación entre los team members se realizará personalmente en reuniones semanales debido a que el proyecto cuenta únicamente con dos team members, siendo uno de ellos además project manager. Vía correo electrónico se expondrán dudas e informará el cumplimiento de cada tarea a ambos. Podrán solicitarse reuniones extraordinarias en forma presencial o vía videoconferencia. No se informará a terceros de los avances hasta finalizar con la tarea 1.3.3. Luego de verificar el cumplimiento de la tarea 1.3.3. se realizará una reunión con los clients para exponer las herramientas desarrolladas y realizar la entrega del firmware, software y la aplicación de referencia quedando a la espera de su aprobación. Una vez aprobada la entrega se comenzará con las actividades de difusión que forman parte del proyecto comprendidas por las tareas 1.6.1. a 1.6.4.

16

18. Gestión de RRHH La responsabilidad y autoridad del proyecto será del project manager. Cada uno de los team members del proyecto tendrán la responsabilidad de cumplir con sus tareas asignadas y el project manager será el encargado de certificar el cumplimiento de cada una, permitiendo al team member responsable avanzar a la realización de otra tarea. Se utiliza la matriz de asignación de responsabilidades como recurso:

Actividad Recursos humanos

Código WBS Descripción Ing. Eric Pernia

Ing. Leonardo Gassman

Clients

1.1.1.

Realizar el porting del Firmware de la Hardware Virtual Machine (HVM) permitiendo que la que la CIAA-NXP y EDU-CIAA-NXP puedan programarse en lenguaje Java.

P

1.1.2. Integración de HVM con el Firmware de la CIAA para permitir el acceso al hardware desde el programa de usuario en Java.

P

1.1.3. Realizar aplicaciones de ejemplo utilizando el hardware.

P S

1.1.4. Documentación de Firmware. P

1.2.1. Adaptación de Icecaptools para CIAA. P

1.2.2. Programación del plug-in CIAA4HVM para Icecaptools.

A P

1.2.3. Documentación de Software. A P

1.3.1. Realizar una aplicación de referencia con especificadores de tiempo real (SCJ).

P P

1.3.2. Testear dicha aplicación para comprobar el cumplimiento de las especificaciones.

P P

1.3.3. Documentación de comportamiento de la aplicación en tiempo real.

P P

1.4. Entrega a los clients para aprobación del firmware, software y aplicación de referencia.

A

1.5.1. Manual de Instalación. P S

1.5.2. Manual de utilización. P S

1.6.1. Subida de documentación y manuales a la wiki del proyecto CIAA.

P

1.6.2. Creación de lista de correo para desarrolladores en Java.

P

1.6.3. Subida del firmware y software al repositorio del proyecto CIAA.

P

1.6.4. Anuncio en las listas de correo para desarrolladores de la CIAA y embebidos 32.

P

P = Responsabilidad Primaria

S = Responsabilidad Secundaria

A = Aprobación

Tabla 5. Matriz de asignación de responsabilidades.

17

Se podría dar el caso de micromanagement en las tareas 1.2.1 a 1.2.3. por parte del project manager Ing. Eric Pernia, al intervenir más allá de la aprobación de la mismas, cuya responsabilidad es del ing. Leonardo Gassman. También en las tareas compartidas entre ambos team members comprendidas por el intervalo 1.3.1. a 1.3.3.

19. Gestión de compras y Statement Of Work

No se realizará ninguna compra para la realización del proyecto ya que se cuenta con todos los recursos materiales expuestos en 12. necesarios para el proyecto.

20. Procesos de control y seguimiento

Se realizarán reuniones semanales entre los team members y el project manager, para corroborar el estado del proyecto con el cronograma y actuar en consecuencia. Se asignarán más horas de los team members en caso de ser necesarias para cumplir con la fecha de entrega. Se comparará el diagrama de Gantt propuesto con el estado actual del proyecto corrigiéndolo de ser necesario. El responsable de cada tarea debe informar a los demás miembros del equipo y al project manager el estado de la misma al arribar a la fecha de culminación, y en caso de no ser finalizada en tiempo y forma, explicar las causas. Es responsabilidad de cada miembro del equipo anticipar al project manager si detecta que alguna tarea demorará más de lo planeado antes de su finalización.

21. Proceso de cierre

Se obtendrá la aprobación formal por parte del cliente.

Se analizará el grado de cumplimiento de los objetivos del proyecto.

Se propondrá a los team members la creación de proyectos derivados sujetos a aprobación, y además; nuevos proyectos pertenecientes al área de los sistemas embebidos en la UNQ para que los mismos elijan donde continuar con sus labores.

Se contrastará el cronograma propuesto con el cronograma real para verificar si las tareas fueron realizadas en el tiempo esperado. De esta forma se identificarán las tareas cuya duración ha sido mal estimada y las causas, para generar un informe final del proyecto que servirá como experiencia para los futuros.

Se archivará toda la documentación de la gestión del proyecto para ser fácilmente reutilizada en la planificación de futuros proyectos.

Anexo I – Diagrama de Gantt