Project PlanGestión de Proyectos 2015
Título: Desarrollo de la capa de compatibilidad del firmwareEduCIAA para el hardware EduCIAA Xilinx.
Alumno: Gerardo L. PugaFecha: 31/05/2015Modificado: 31/05/2015
Revisión: Rev.A
Historial de modificaciones:
31/05/2015 Primera versión del documento.01/06/2015 Corrección de errores de escritura. Emisión de la
Rev.A del documento.
1
Project Charter
Con el fin de llevar a cabo el proyecto “Desarrollo de lacapa de compatibilidad del firmware EduCIAA para el el hardwareEduCIAA Xilinx” como requisito de aprobación de la Carrera deEspecialización en Sistemas Embebidos, se designa al IngenieroGerardo L. Puga para llevar adelante la gestión y ejecución delproyecto en todas sus etapas.
Se establece la duración máxima del proyecto en ocho meses,desarrollarse entre la segunda quincena de abril de 2015 y laprimera quincena de diciembre de 2015.
La disponibilidad del equipamiento necesario para llevaradelante la ejecución del proyecto (computadoras, kits dedesarrollo FPGA, cables, etc.), tanto en la Universidad de LaPlata como en la Universidad de Buenos Aires, permite asumir lanulidad de los costos materiales y operativos necesarios. Loscostos de transporte y personal necesarios para llevar adelante elproyecto se calculan en un total de $29.232. La totalidad de laserogaciones necesarias corren por cuenta del Ing. Puga.
El Ing. Pedro I. Martos, en su calidad de tutor yrepresentante del proyecto que se encuentra llevando adelante eldesarrollo del hardware de la EduCIAA Xilinx se compromete abrindar la asistencia que sea necesaria en términos de experienciade desarrollo, información sobre el hardware objetivo, ycaracterísticas necesarias para el desarrollo los modelos dedesarrollo.
Ing. Pedro I. MartosDocente Carrera de Especialización
en Sistemas Embebidos,Facultad de Ingeniería, UBA
Propósito
El presente proyecto tiene por fin el desarrollo de una capade compatibilidad que permita ejecutar el firmware del proyectoCIAA sobre el hardware de EduCIAA Xilinx que se encuentraactualmente en desarrollo.
Objetivos
Los objetivos del proyectos son, por orden de importancia, lossiguientes:
1. Realización del trabajo de finalización de carrera encumplimiento de los requisitos de aprobación de la Carrera deEspecialización en Sistemas Embebidos, cursada del año 2015.
2. Extensión de la base de hardware que es posible utilizar en
2
los proyectos CIAA y EduCIAA.3. Ampliación de la base de procesadores que soporta la versión
del sistema operativo de tiempo real OSEK utilizado por elproyecto CIAA, potencialmente facilitando su adopción enotros proyectos nacionales de desarrollo de sistemas detiempo real para aplicaciones críticas.
Stakeholders
Client Ing. Pedro Martos, en su calidad deresponsable del proyecto EduCIAA Xilinx.
EndUser Conjunto de los usuarios de losdispositivos EduCIAA Xilinx con fineseducativos, académicos o comerciales.
Sponsors Ing. Gerardo Puga
Champion Ing. Pedro Martos
Drivers Ing. Pedro MartosIng. Mariano Cerdeiro
Supporters Laboratorio de Sistemas Embebidos, UBA.Laboratorio LEICI, UNLP
Project Manager Ing. Gerardo Puga
Team members Ing. Gerardo Puga
Alcance
El alcance del proyecto se encuentra definido por las siguientes metas clave:
• Partiendo del último release estable al día de la fecha(Firmware_0.4.1), efectuar el desarrollo del código necesariopara habilitar la ejecución del firmware de la CIAA en elsoftcore utilizado en le EduCIAA Xilinx de acuerdo con laguías de estilo propias de firmware del Proyecto CIAA.
• Modificación de la configuración del sistema de compilacióndel firmware para incorporar la nueva plataforma a las yaexistentes.
• Documentación del sistema de desarrollo necesario paracompilar y ejecutar el firmware para la plataforma elegida.
• Documentación de las características mínimas requeridas de laplataforma por parte del firmware modificado.
3
• Hacer disponible el código y la documentación generada parasu evaluación y eventual reintegración al firmware delProyecto CIAA.
Requerimientos
R.01 Debe portarse el código de la versión dereferencia del firmware de la CIAA para quefuncione sobre el procesador seleccionado paraser sintetizado en la FPGA del proyecto EduCIAA.Fuente: Justificación del proyecto.
R.02 La versión a tomar como referencia para eldesarrollo es el último release estable al día dela fecha: Firmware_0.4.1.Fuente: Necesidad de fijar la versión de trabajo.
R.03 El código a portar incluye la capa decompatibilidad del sistema operativo OSEKencargada de la gestión multitarea del firmware,y los drivers de dispositivos de la capa deabstracción de hardware del firmware CIAA.Fuente: Análisis del código de la versión dereferencia.
R.04 Los drivers portados debe incluir los cuatrodrivers definidos en la capa de abstracción de laversión de referencia: ciaaDriverFlash,ciaaDriverUart, ciaaDriverAio y ciaaDriverDio.Los drivers que no sean pertinentes al hardwareobjetivo deben estar implementado como dummies deprueba.Fuente: Análisis del código de la versión dereferencia.
R.05 El código implementado debe respetar las CIAAFirmware Coding Guidelines.Fuente: Web Proyecto CIAA ( http://www.proyectociaa.com.ar )
R.06 El código implementado debe respetar laestructura de directorios adoptada por el equipode desarrollo del firmware.Fuente: Web Proyecto CIAA ( http://www.proyectociaa.com.ar )
R.07 El código implementado debe contenerdocumentación interna en el formato aceptado por
4
el generador automático de documentaciónutilizado por el proyecto (Doxygen).Fuente: Web Proyecto CIAA ( http://www.proyectociaa.com.ar )
R.08 (Anulado. Mantener para conservar la numeración).
R.09 El firmware modificado debe poder superar labatería de tests unitarios presentes en elfirmware en la misma medida en la que lo hace elfirmware de referencia. Fuente: Web Proyecto CIAA ( http://www.proyectociaa.com.ar ), intercambio por correo con MarianoCerceiro.
R.10 Al finalizar el proyecto debe existirdocumentación que explicite las característicasde los recursos de hardware asumidos en laimplementación del firmware modificado,incluyendo mapa de memoria esperado, ocupación dememoria, bloques IP utilizados, asignaciones defuncionalidad a los pines de puertos de propósitogeneral, tasa por defecto de la UART. Fuente: Experiencia personal.
R.11 Al finalizar el proyecto debe existirdocumentación que indique la configuración básicadel entorno de desarrollo utilizado para compilarel firmware portado, incluyendo versión de loscompiladores y demás software utilizado paragenerar la imagen binaria del firmware.Fuente: Experiencia personal.
R.12 Al finalizar el proyecto el firmware modificadodebe ser capaz de ejecutar correctamente elejemplo blinking (provisto con la versión dereferencia del firmware) en una versión de pruebadel hardware.Fuente: Necesario para cumplir los criterios deaceptación.
R.13 El proyecto debe alcanzar su conclusión antes definalizada la primera quincena de diciembre de2015.Fuente: Necesario para cumplimentar la exigenciasde aprobación del trabajo final de la Carrera deEspecialización en Sistemas Embebidos.
5
Análisis de Factibilidad Técnica
Se cuenta con la información, los equipos y los recursos humanosformados necesarios para la ejecución del proyecto. Además, elfirmware del proyecto CIAA ha sido portado a múltiplesarquitecturas de hardware y cuenta por lo tanto con unainfraestructura adecuada para este tipo de modificaciones.
Análisis de Factibilidad FinancieraEconómica
El desarrollo del proyecto no requiere de fuentes definanciamiento externas, ni de presupuesto para la compra deequipo. Los costos de personal y transporte serán cubiertos en sutotalidad por el ejecutor.
Work Breakdown Structure (WBS)
1 Iniciación de proyecto 1.1 Realización TPs Gestión de Proyectos
2 Puesta en marcha 2.1 Recopilación de información
2.1.1 Lectura Firmware Coding Guidelines 2.1.2 Estructura del repositorio de proyecto 2.1.3 Sistema de compilación proyecto CIAA 2.1.4 Sistema de tests de regresión CIAA 2.1.5 Sistema de control de versiones Git
2.2 Instalación herramientas de desarrollo del hardware 2.3 Generación modelo de desarrollo del hardware
2.3.1 Definición de características de modelo dedesarrollo
2.3.2 Implementación del modelo de desarrollo 3 Ejecución
3.1 Desarrollo 3.1.1 Port OSEK LEON 3 3.1.2 Drivers LEON 3 3.1.3 Actualización del sistema de compilación
3.2 Verificación 3.2.1 Verificar corrida de tests de regresión de OSEK 3.2.2 Verificar funcionamiento programa "blinking" en
modelo de desarrollo 3.3 Documentación
3.3.1 Documentación externa 3.3.1.1 Documentación hardware modelo de desarrollo 3.3.1.2 Documentación entorno desarrollo
3.3.2 Documentación interna 3.3.2.1 Documentacion doxygen
4 Cierre de proyecto
6
4.1.1 Escritura borrador tesis 4.1.2 Revisión borrador tesis 4.1.3 Versión final tesis
Diagrama ActivityonNode
Utilizando una aproximación de división del proyecto en fases parareducir la complejidad se establecieron hitos intermedios a cadauna de las fases del WBS que son luego utilizados como dependenciapara las actividades posteriores.
El diagrama de actividades resultante se ve en las figuras de laspáginas siguientes.
Los caminos críticos del proyecto son tres debido a la igualdad enlas duraciones de todas as actividades dentro de 3.3:
1.1 2.1.5 2.3.1 2.3.2 3.2.2 3.3.1.1 4.1.1→ → → → → → 4.1.2 4.1.3→ →
1.1 2.1.5 2.3.1 2.3.2 3.2.2 3.3.1.2 4.1.1→ → → → → → 4.1.2 4.1.3→ →
1.1 2.1.5 2.3.1 2.3.2 3.2.2 3.3.2.1 4.1.1→ → → → → → 4.1.2 4.1.3→ →
Un camino semicrítico posible es el que en lugar de pasar por2.1.5 pasa por 2.1.4 o 2.1.3, como en
1.1 2.1.3 2.3.1 2.3.2 3.2.2 3.3.1.1 4.1.1→ → → → → → 4.1.2 4.1.3→ →
ya que si la actividad se atrasa más que 0.5 días adicionales,este camino se convierte en el determinante de la duración delproyecto.
El análisis anterior no considera la limitación de recursoshumanos para llevar a cabo el proyecto (asume que todas las tareasno dependientes pueden realizarse en paralelo).
7
Diagrama de Gantt
Para la realización del diagrama de Gantt se asumió un una únicapersona a cargo de todas las tareas del proyecto, con unadedicación de dos días por semana.
10
Matriz de Recursos Materiales y Presupuesto
Plan de Gestión de Riesgos
Descripción de riesgos:
Riesgo 1Descripción: Imposibilidad de acceder a un kit de desarrollo de
FPGA para realizar el modelo de desarrollo dehardware de la EduCIAA Xilinx a tiempo paracomenzar el desarrollo.
Probabilidad: Muy baja. Existen múltiples kits de desarrollo deFPGA disponibles en la UNLP.
Impacto: Menor. Aunque no es recomendable, la etapa decodificación puede comenzar antes de tener elmodelo de desarrollo para hacer las pruebas sobreéste.
Detección: Muy probable. Se puede anticipar la disponibilidadde los equipos con tiempo y planificar suutilización.
13
Actividad Tiempo total Computadora
1.1 Trabajos prácticos gestión de proyectos 4 días 4 días2.1.1 Lectura firmware Coding Guidelines 0.25 días 0.25 días2.1.2 Estructura del repositorio de proyecto 0.25 días 0.25 días2.1.3 Sistema de compilación proyecto CIAA 0.5 días 0.5 días2.1.4 Sistema de tests de regresión CIAA 0.5 días 0.5 días2.1.5 Sistema de control de versiones Git 1 día 1 día2.2 Instalación herramientas de desarrrollo del hardware 1 día 1 día2.3.1 Definición de características de modelo de desarrollo 2 días2.3.2 Implementación del modelo de desarrollo 3 días 3 días 3 días3.1.1 Port OSEK LEON 3 4 días 4 días 4 días3.1.2 Drivers LEON 3 5 días 5 días 5 días3.1.3 Actualización del sistema de compilación 1 días 1 día3.2.1 Verificar corrida de tests de regresión de OSEK 1 día 1 día3.2.2 Verificar funcionamiento programa "blinking" en modelo de desarrollo 3 días 3 días 3 días3.3.1.1 Documentación hardware modelo de desarrrollo 1 día 1 día3.3.1.2 Documentacion entorno desarrollo 1 día 1 día3.3.2.1 Documentacion doxygen 1 día 1 día4.1 Escritura borrador tesis 4 días 4 días4.2 Revisión borrador tesis 10 días4.3 Versión final tesis 2 días 2 días
Kit desarrollo FPGA
Categoría Detalle CostoTrabajo directo Desarrollador (284 hs x $100/hs) 28400
Total Costos Directos 28400Costos Indirectos Transporte LP-BSAS 832
Total Costos Indirectos 832
Total 29232
Riesgo 2Descripción: Pérdida de prioridad del proyecto frente a otros
compromisos laborales.Probabilidad: Alta.Impacto: Crítico. No se cumplen con los hitos de avance, la
duración del proyecto se alarga y se corre elriesgo de no cumplir con la fecha de entregapactada.
Detección: Muy probable. En general es posible anticipar loscompromisos y determinar que la disponibilidad detiempo se va a volver un problema.
Riesgo 3Descripción: Imposibilidad de completar las tareas de desarrollo
(port de sistema operativo, drivers y modificacióndel sistema de compilación) en el plazo establecido(10 días dedicados).
Probabilidad: Baja.Impacto: Significativo. De acuerdo con el plan de gestión de
tiempos es posible el atraso del trabajo en hasta10 días dedicados (aproximadamente un mes lineal)antes de que el atraso impacte sobre la fecha decierre.
Detección: Imposible. No se puede anticipar este riesgo antesde que se manifieste.
Riesgo 4Descripción: La implementación del modelo de desarrollo del
hardware utilizando un kit de desarrollo de FPGA esuna actividad novedosa, y puede tomar más tiempodel previsto (3 días dedicados).
Probabilidad: Baja.Impacto: Significativo. Detección: Muy probable. Ya en las etapas de recolección de
información previas se puede anticipar el nivel dedificultad que va a significar la actividad.
Riesgo 5Descripción: Que la revisión de la primera versión de la tesis
del trabajo final se demore más tiempo del previsto(10 días dedicados) por falta de tiempo de partedel tutor.
Probabilidad: Baja.Impacto: Significativo. De acuerdo con el plan de gestión de
tiempos es posible el atraso del trabajo en hasta10 días dedicados (aproximadamente un mes lineal)antes de que el atraso impacte sobre la fecha decierre.
14
Detección: Imposible. No se puede anticipar este riesgo.
Estrategia de gestión de riesgos
A partir de un análisis de los riesgos anteriores se concluyó quees conveniente delinear una estrategia para lidiar con los riesgos2, 3 y 5, de forma tal de minimizar la probabilidad de que afectenal desarrollo del proyecto.
Riesgo 2Estrategia: Mitigar los efectos con una estrategia de avance
defensiva, adelantando hitos respecto de loestipulado de forma oportunista cada vez que existala posibilidad, para de esa forma hacer lugar afuturos potenciales atrasos.
Modificación: Esto puede reducir el impacto de Crítico aSignificativo.
Riesgo 3Estrategia: Idem Riesgo 2.Modificación: Se puede reducir el impacto de Significativo a
Menor.
Riesgo 5Estrategia: Mantener la extensión de la tesis breve, y el
contenido sintético para minimizar el tiempo quetoma la corrección. Realizar un proceso intenso derevisión del texto antes de enviárselo al tutor,para minimizar la cantidad de correcciones.
Modificación: Se puede reducir la probabilidad de que semanifieste el riesgo de Baja a Muy Baja.
Risk Priority Number (RPN) usando estrategia de gestión de riesgos
15
RiesgoProbabilidad Impacto Detección
RPNCualitativo Cuantitativo Cualitativo Cuantitativo Cualitativo Cuantitativo
Riesgo 1 Muy Baja 0.1 Menor 1 Muy Probable 0.33 0.033Riesgo 2 Alta 0.7 Significativo 10 Muy Probable 0.33 2.31Riesgo 3 Baja 0.3 Menor 1 Imposible 0.9 0.27Riesgo 4 Baja 0.3 Significativo 10 Muy Probable 0.33 0.99Riesgo 5 Muy Baja 0.1 Significativo 10 Imposible 0.9 0.9
Muy Baja Baja Media Alta Muy AltaProbabilidad 0.1 0.3 0.5 0.7 0.9
Menor Significativo Crítico CatastróficoImpacto 1 10 100 1000
Imposible Improbable Muy probable SeguraDetección 0.9 0.66 0.33 0.1
Nota: Detección está cuantificado como la probabilidad de NOdetección.
Plan de Gestión de Calidad
Los Costos de Conformidad del proyecto se encuentran asociadosfundamentalmente a la inversión de tiempo y esfuerzo necesariapara garantizar el cumplimiento de los requerimientos con un nivelde calidad adecuado, ya que en su formato actual el proyecto nodepende de ningún tipo de erogación económica para poder cumplirlos requerimientos (compra de equipos, entrenamiento de personal,etc.).
Los Costos de No Conformidad, por otro lado, se pagarán en laforma de tiempo invertido para realizar mantenimiento del códigoen el futuro en caso de que se encuentren errores, futurasiteraciones de la documentación para completar o aclarar lospasajes que puedan considerarse inadecuados, etc.
Plan de Verificación y Validación
La verificación se lleva a cabo durante el desarrollo del códigodel port, para comprobar la correcta implementación de losfragmentos de código, algoritmos y configuraciones auxiliares(sistema de compilación) que sean necesarios. El análisis estáticode código es la primera instancia de defensa frente a problemas enla programación, seguido de la verificación manual mediante casosde ensayo. El firmware CIAA cuenta con su propio set de tests quepermiten verificar de forma automatizada grandes secciones delcódigo de mismo para detectar que las modificaciones realizadas nointroduzcan problemas en el código preexistente.
La validación, por otro lado, se lleva a cabo verificando elcumplimiento de cada uno de los requerimientos enunciados para elproducto del proyecto, así como verificando la conformidad de loscriterios de aceptación del mismo.
Plan de Comunicación
La naturaleza prácticamente unipersonal del proyecto descripto poreste documento hace innecesaria la utilización de una gestión de comunicación muy compleja.
La comunicación es principalmente de tipo externo, pudiéndoseseñalar los siguientes tipos de comunicación necesarios para eldesarrollo del proyecto:
1. De seguimiento de avances, entre el ejecutor y el tutor delproyecto.
16
2. De coordinación y consulta, entre el ejecutor y los miembrosdel grupo de trabajo que lleva adelante el desarrollo delfirmware CIAA y del hardware de la EduCIAA Xilinx.
En el primer caso el seguimiento de avances puede realizarsemediante informes mensuales donde se detalle el estado de avancedel proyecto, demoras, problemas pendientes, actividades futuras,etc.
Estas comunicaciones serían iniciadas por el ejecutor, pudiendo ono recibir una devolución de parte del tutor en función de lostemas tratados en cada entrega. Por su formato y contenido estas comunicaciones de seguimiento deavances pueden realizarse mayormente mediante correo electrónico,o bien en caso de ser necesaria para una discusión más interactivasobre un tópico en particular es posible coordinar reunionespersonales entre el ejecutor del proyecto y el tutor.
En el segundo tipo de comunicación externa, el canal es aún másinformal que el primero y no tiene una periodicidad establecida.Su ejecución es en función de las necesidades de avance, paraobtener información adicional sobre elementos del software ohardware de trabajo. El canal de comunicación en este caso seráintercambios directos con los miembros de los equipos del firmwareo hardware EduCIAA Xilinx, o bien preguntas abiertas en laslistas de correo de dichos proyectos.
Gestión de Recursos Humanos
Matriz de Asignación de Responsabilidades
17
P = Responsabilidad Primaria S = Responsabilidad Secundaria A = Aprobación
Gestión de Compras
Selección de proveedores
Este trabajo no tiene proveedores.
En caso de que los tuviera, y teniendo más de uno en condicionesde cumplir con los requisitos de tiempo y costo de un producto oservicio dado, puedo elegir entre ellos planteando un árbol dedecisión.
En este árbol se enumeran para cada uno de los proveedores todoslos posibles resultados de realizar la compra a través de ellos(atrasos, adelantos, problemas de calidad), cuantificados por elcosto final de cada opción individual (costo del producto másdiferencial debido a ganancia/pérdida adicional por entrega fuerade término, perjuicio por calidad defectuosa, etc.) y asignando acada alternativa una probabilidad de ocurrencia
Finalmente para cada proveedor se calcula la esperanza del costofinal de contratarlo como la suma de los productos entre loscostos finales de cada alternativa y su probabilidad de ocurrenciaasociada.
18
Actividad
1.1 Trabajos prácticos gestión de proyectos P A2.1.1 Lectura firmware Coding Guidelines P2.1.2 Estructura del repositorio de proyecto P2.1.3 Sistema de compilación proyecto CIAA P2.1.4 Sistema de tests de regresión CIAA P2.1.5 Sistema de control de versiones Git P2.2 Instalación herramientas de desarrrollo del hardware P2.3.1 Definición de características de modelo de desarrollo P S2.3.2 Implementación del modelo de desarrollo P3.1.1 Port OSEK LEON 3 P3.1.2 Drivers LEON 3 P3.1.3 Actualización del sistema de compilación P3.2.1 Verificar corrida de tests de regresión de OSEK P3.2.2 Verificar funcionamiento programa "blinking" en modelo de desarrollo P3.3.1.1 Documentación hardware modelo de desarrrollo P A3.3.1.2 Documentacion entorno desarrollo P3.3.2.1 Documentacion doxygen P4.1 Escritura borrador tesis P4.2 Revisión borrador tesis P4.3 Versión final tesis P A
Gerardo Puga
Ariel Lutemberg
Pedro Martos
El proveedor que tenga la esperanza de costo final más baja es lamejor opción.
Statement of Work
Este trabajo no tiene proveedores.
Suponiendo que tercerizara la creación del modelo de desarrollodel hardware que se utilizará para trabajar, un Statement of Workposible podría ser la siguiente.
25 de Mayo de 2015
Por la presente se encarga el trabajo de desarrollo de un modelode ingeniería del hardware de la EduCIAA Xilinx con el fin deser utilizado para el desarrollo de un firmware compatible con elmodelo de hardware definitivo de la misma.
Entregables: Hardware del modelo. Diseño del hardware realizado.Guía de usuario.
Prop. intelectual:Todos los derechos de propiedad intelectualsobre el diseño pertenecen al adquiriente.
Plazo de entrega: 30 días a partir de la fecha.
Forma de Pago: Efectivo. 40% por adelantado a fecha decontrato, y lo restante sobre entrega delproducto final.
Garantía: Seis meses de garantía desde la entrega. Lagarantía cubre tanto vicios en el hardwareentregado, como también defectos en el diseñobase del mismo y en la documentación queacompaña.
Firma del Proveedor Firma del Responsable
Procesos de Control y Seguimiento
Para llevar a cabo un seguimiento del grado de avance del proyecto
19
se evaluará periódicamente la cantidad y tipo de actividades quehan sido completadas satisfactoriamente, así como el estado deavance de las que hayan sido comenzadas. Este registro secomparará con el cronograma estimado presente en el diagrama deGantt, analizando el impacto de cualquier divergencia entre elestado real y el previsto del proyecto en el momento deevaluación.
Procesos de Cierre
Una vez completadas todas las actividades previstas como parte dela ejecución del proyecto, es necesario realizar un cierreordenado del mismo que incluya las siguientes actividades finales:
• Análisis del desarrollo del proyecto, evaluando el nivel deaproximación entre el plan original contra los registros deejecución efectiva del proyecto, así como las razones de lasdiferencias.
• Devolución de todo el material que haya sido adquirido enpréstamo para la ejecución del proyecto (documentos,hardware, etc).
• Archivo de toda la información relativa al proyecto. • Archivo de la tesis de proyecto.
20