Download Plan de Trabajo - Investigación

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
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
2
Anexo I – Diagrama de Gantt .................................................................................................................................. 18
3
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 RealTime 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.
4
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.
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.
2
5
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 CIAANXP 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.
CUIDADO: Las restricciones son aclaraciones respecto a
cosas que sabes que no vas a poder hacer. Ejemplo: no se
podra usar plutonio. O no se podrá empezar antes de tal
fecha. Algunas de estas cosas no estan expresadas como
restricciones.
6

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.
7



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.
8
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.
¿Por qué esto está
Estandarizar los tamaños de tipos de datos.
en negritas?
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.
9
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.
A mi entender falta lo referido a:
- Gestion del proyecto
- Documentacion
10
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.
11
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
Código WBS
1.1.1.
Recursos requeridos (horas)
Descripción
Puesto de trabajo EDU-CIAA-NXP
Realizar el porting del Firmware de la Hardware
Virtual Machine (HVM) permitiendo que la que la
64
64
CIAA-NXP y EDU-CIAA-NXP puedan programarse en
lenguaje Java.
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.
12
1.1.2.
1.1.3.
1.1.4.
1.2.1.
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.
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 ejemplo utilizando el
hardware.
Documentación de Firmware.
Adaptación de Icecaptools para CIAA.
Programación del plug-in CIAA4HVM para
Icecaptools.
Documentación de Software.
Realizar una aplicación de referencia con
especificadores de tiempo real (SCJ).
Testear dicha aplicación para comprobar el
cumplimiento de las especificaciones.
Documentación de comportamiento de la
aplicación en tiempo real.
Entrega a los clients para aprobación del firmware,
software y aplicación de referencia.
Manual de Instalación.
Manual de utilización.
Subida de documentación y manuales a la wiki del
proyecto CIAA.
36
36
28
28
16
52
0
48
48
24
0
112
56
160
80
48
0
0
0
12
24
0
0
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
660
312
Total de horas por recurso
Tabla 1. Matriz de recursos materiales.
El presupuesto se resume en la siguiente tabla:
Categoría
Detalle
Costos
directos
Ing. Eric Pernia. 94 días de trabajo
de 4 horas, a $120 la hora.
Ing. Leonardo Gassman. 73 días de
trabajo de 4 horas, a $100 la hora.
Costos
indirectos
Estimados como el 60% de los
costos directos
Estimados como el 15% de la suma
Reserva para
de los costos directos y los costos
contingencia
indirectos.
Total
Costo
$ 45.120,00
$ 29.200,00
$ 44.592,00
$ 17.836,80
$ 136.748,80
Tabla 2. Presupuesto.
13
13. Plan de gestión de riesgos
En la tabla 3 se muestra la tabla de gestión de riesgos:
Nº
1
Riesgo
Requerimientos no
cumplidos.
O
S
D
6 10
5
RPN
Acción correctiva
Se destinarán más horas
300
para reparar los errores.
O S D RPN
4 7 4 112
2
Las autoridades de la UNQ
disponen de los team
members
para
otras 8
actividades reduciendo la
dedicación al proyecto.
9
4
Se solicitará a los team
members trabajar más
288
6 7 2
horas fuera del horario de
la facultad.
3
Horas
de
trabajo
planificadas
insuficientes 5 10
para alcanzar el deadline.
3
Se destinarán más horas
150 de los team members
para este proyecto.
2 5 1
10
4
Se rompe la placa EDU2
CIAA-NXP.
10
140
Se reemplazará por otra
placa.
1 4 6
24
7
Se solicitará a los team
members trabajar desde 1 6 3
sus casas.
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).
5
No se dispone de
puestos de trabajo.
los
2
8
6
96
84
18
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
Costos de
conformidad
Costos de
prevención
Entrenamiento en técnicas de
testing de software.
Revisión de documentación.
Costo
$ 8.800,00
$ 880,00
14
Costos de
evaluación
Costos No
conformidad
Costos de fallas
internas
Costos de fallas
externas
Programación de tests unitarios de
cada módulo.
Programación de tests de
integración.
Tests de aplicación de referencia.
Fallos de firmware que impliquen
reprogramación.
Fallos de software que impliquen
reprogramación.
Fallos de integración que
impliquen reprogramación.
Errores en documentación.
No aprobación por parte de los
clients del firmware, software y
aplicación de referencia
entregados.
Costo total de calidad
$ 3.360,00
$ 4.520,00
$ 17.600,00
$ 7.200,00
$ 6.000,00
$ 12.320,00
$ 5.240,00
$ 30.760,00
$ 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.
15
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
Ing. Eric
Ing. Leonardo
Pernia
Gassman
Código WBS
Descripción
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.
1.1.4.
1.2.1.
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.
Realizar aplicaciones de ejemplo utilizando el
hardware.
Documentación de Firmware.
Adaptación de Icecaptools para CIAA.
Programación del plug-in CIAA4HVM para
Icecaptools.
Documentación de Software.
Realizar una aplicación de referencia con
especificadores de tiempo real (SCJ).
Testear dicha aplicación para comprobar el
cumplimiento de las especificaciones.
Documentación de comportamiento de la
aplicación en tiempo real.
Entrega a los clients para aprobación del
firmware, software y aplicación de referencia.
Manual de Instalación.
Manual de utilización.
Subida de documentación y manuales a la wiki
del proyecto CIAA.
Creación de lista de correo para
desarrolladores en Java.
Subida del firmware y software al repositorio
del proyecto CIAA.
Anuncio en las listas de correo para
desarrolladores de la CIAA y embebidos 32.
P
Clients
S
P
P
A
P
A
P
P
P
P
P
P
P
A
P
P
S
S
P
P
P
P
P = Responsabilidad Primaria
S = Responsabilidad Secundaria
A = Aprobación
Tabla 5. Matriz de asignación de responsabilidades.
No está bueno que haya
dos Responsables
primarios
16
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.
17
Anexo I – Diagrama de Gantt