Analizador de memoria de Sistemas Embebidos (AMSE)

Transcripción

1 Analizador de memoria de Sistemas Embebidos (AMSE) Autor Director del Trabajo Ing. Juan Manuel Cruz Jurado propuesto para el trabajo Ing. Roberto Barneda (UTN FRBA) Ing. Rubén Lozano (UTN FRBA) Ing. Juan Alarcón (UTN FRBA) Página 1 de 19

2 Tabla de contenido 1. Avance en las tareas 2. Cumplimiento de los requerimientos 3. Gestión de riesgos 4. Plan de comunicación Revisión Cambios realizados Fecha 1.0 Creación del documento Abril 15 de Se agrega reporte de las tareas aún no comenzadas Abril 28 de 2016 Página 2 de 19

3 1. Avance en las tareas Se presenta el estado de avance de cada tarea con la siguiente simbología. El color indica el estado de situación de las tareas: Verde se considera satisfactorio. Amarillo se considera insatisfactorio por sobrecostos y/o demoras. Rojo si lo considera muy insatisfactorio por sobrecostos y/o demoras. En la subcelda inferior izquierda: ** * $ $$ si el gasto de recursos fue o está siendo muy inferior a lo planificado. si el gasto de recursos fue o está siendo inferior a lo planificado. si el gasto de recursos fue o está siendo de acuerdo a lo planificado. si el gasto de recursos fue o está siendo superior a lo planificado. $$$ si el gasto de recursos fue o está siendo muy superior a lo planificado. En la subcelda inferior derecha: = + ++ si la tarea se ejecutó o se está ejecutando mucho más rápido de lo previsto si la tarea se ejecutó o se está ejecutando más rápido de lo previsto si la tarea se ejecutó o se está ejecutando en el tiempo previsto. si la tarea se ejecutó o se está ejecutando con demoras. si la tarea se ejecutó o se está ejecutando con demoras muy significativas. El trazado de borde grueso indica las tareas que están en el camino crítico. Las tareas que no indican estado de avance es porque su fecha planificada de inicio es posterior a la realización de este informe. Página 3 de 19

4 1. 1 Buscar documentación del reporte de compilación 1.2 Discriminar información de interés 1.3 Armar una tabla con los resultados del análisis $ = $ + $ Investigar programas de treemaps 2.2 Selección de una alternativa 2.3 Experimentació n con la aplicación elegida * = $ = $ = 3.1 Integración de resultados previos 3.2 Verificación y Validación 4.1 Buscar un experto en Java 4.2 Aprender el entorno de desarrollo de plugins 4.3 Desarrollar un plugin de prueba 4.4 Integrar el programa desarrollado 4.5 Validación con usuarios finales Página 4 de 19

5 Debe notarse que el proyecto estaba planificado originalmente para el tercer trimestre del año 2015 y se reprogramó para marzo del 2016 debido a inconvenientes laborales y personales del único involucrado en el desarrollo. A continuación se presenta un nuevo diagrama de Gantt con la planificación actualizada. Página 5 de 19

6 Para cada una de las tareas previstas en el WBS se indica: Responsable de la tarea, personas a ser informadas y consultadas, y encargado de aprobar la tarea. El grado de avance a la fecha, comparando lo planificado y lo efectivamente realizado, según el indicador establecido en la planificación. Las horas de trabajo utilizadas, comparando lo planificado y lo efectivamente utilizado. Los recursos materiales utilizados, comparando lo planificado y lo efectivamente utilizado. La celda Autodiagnóstico pintarla del mismo color utilizado en el punto 1)a) de la página anterior Nombre de la tarea : 1.1 Buscar documentación del mismo Autodiagnóstico Responsable: Informado a: Consultado con: Aprobado por: Alejandro Celery Alejandro Celery Se encontró que la información requerida no era necesario extraerla manualmente del archivo.map sino que hay herramientas libres que la extraen del mismo, y que están debidamente documentadas. 100% 100% 18/03/ /04/2016 alcanzada: Nombre de la tarea : 1.2 Discriminar información de interés Autodiagnóstico Alejandro Celery Alejandro Celery Los consumos de memoria por parte del usuario son fáciles de identificar, pero aparecen otros generados por el compilador que aún no se logran detallar con precisión. Esto hace que el reporte contenga zonas grises de consumos no identificados. La tarea se da por finalizada con este criterio. 100% 100% 25/03/ /04/2016 alcanzada: Página 6 de 19

7 Nombre de la tarea : 1.3 Armar una tabla con los resultados del análisis Autodiagnóstico Alejandro Celery Juan Manuel Cruz Se lograron identificar los consumos de memoria generados por el usuario. Falta identificar cómo acomodar el compilador en memoria las variables miembros de estructuras. 100% 90% 01/04/ /04/2016 estimada: 15 8 Nombre de la tarea : 2.1 Investigar programas de treemaps Autodiagnóstico Alejandro Celery Alejandro Celery Luego de la planificación inicial se encontraron herramientas alternativas a la propuesta inicialmente, se optó por hacer una búsqueda de alternativas que facilitaran el trabajo. 100% 100% 25/03/ /03/2016 alcanzada: Nombre de la tarea : 2.2 Selección de una alternativa Autodiagnóstico Alejandro Celery Alejandro Celery Se leyó la documentación y se hicieron experiencias con las aplicaciones encontradas en el punto anterior, buscando cuál ofrecía más ventajas para el proyecto. Página 7 de 19

8 Se optó por reemplazar el original WinDirStat por QDirStat, disponible en forma libre en Linux y que permite leer desde un archivo el treemap a dibujar. 100% 100% 08/04/ /04/2016 alcanzada: Nombre de la tarea : 2.3 Experimentación con la aplicación elegida Autodiagnóstico Alejandro Celery Alejandro Celery Se ensayaron distintas formas de armar manualmente un treemap para que lo dibuje QDirStat, atendiendo a las funcionalidades y limitaciones del programa. Falta mejorar la manera de representar las variables miembros de vectores y de estructuras. Falta definir a manera de representar las distintas secciones de memoria que usa el compilador. 100% 80% 15/04/ /04/2016 estimada: Nombre de la tarea : 3.1 Integración de resultados previos Autodiagnóstico Alejandro Celery Alejandro Celery Se escribe una herramienta prototipo con la que validar los resultados alcanzados hasta el momento. 0% 0% 06/05 /2016 estimada: Página 8 de 19

9 30 0 Nombre de la tarea : 3.2 Verificación y validación Autodiagnóstico Alejandro Celery Juan Manuel Cruz Se hacen pruebas de campo de la herramienta prototipo por el director del trabajo. 0% 0% 13/05/2016 estimada: 15 0 Nombre de la tarea : 4.1 Buscar un experto en Java Autodiagnóstico Alejandro Celery Alejandro Celery Se busca la ayuda de un experto en el lenguaje Java para acelerar el proceso de desarrollo del plugin. 0% 0% 06/05/2016 estimada: 15 0 Nombre de la tarea : 4.2 Aprender el entorno de desarrollo de plugins Autodiagnóstico Alejandro Celery Alejandro Celery Se estudiará bibliografía específica del tema. Página 9 de 19

10 0% 29/04/2016 estimada: 20 Libro Eclipse 4 Plug in Development by Example, Alex Blewitt. 0% 0 Nombre de la tarea : 4.3 Desarrollar un plug in de prueba Autodiagnóstico Alejandro Celery Juan Manuel Cruz Alejandro Celery Se desarrolla una aplicación piloto, se prevé luego empezar de nuevo para la aplicación final aprovechando la experiencia adquirida. 0% 0% 06/05/2016 estimada: 5 0 Nombre de la tarea : 4.4 Integrar el programa desarrollado Autodiagnóstico Alejandro Celery Juan Manuel Cruz Jurados del trabajo Se escribe la aplicación final, donde se vuelca a un plugin el resultado validado de la aplicación prototipo. 0% 0% 03/06/2016 estimada: 45 0 Nombre de la tarea : 4.5 Validación con usuarios finales Autodiagnóstico Página 10 de 19

11 Alejandro Celery Juan Manuel Cruz Jurados del trabajo Se hacen pruebas de campo de la herramienta por los jurados que son docentes de sistemas embebidos. 0% 0% 17/06/2016 estimada: 30 0 Página 11 de 19

12 2. Cumplimiento de los requerimientos a) Indicar a continuación para cada uno de los requerimientos el estado de situación según su criterio, utilizando verde si considera que ya se ha cumplido, amarillo si considera que aún no se a cumplido pero se podrá cumplir, y rojo si considera que aún no se ha cumplido y tiene dudas si se podrá cumplir. Req #1: Representación visual del uso de la memoria interna del MCU. Req #2: Fácil identificación de los principales consumos de memoria. Req #3: Indicación de a qué zona de memoria fue asignada cada variable. Req #4: Presentación de estos datos dentro de una ventana de Eclipse. b) Para cada uno de los requerimientos indicar en una tabla el nivel de cumplimiento alcanzado a la fecha, incluyendo las acciones de verificación y validación previstas en el Plan de Gestión de Calidad, y si existen modificaciones al respecto, así como también los costos de conformidad en que se ha incurrido y los costos de no conformidad que se estima pudieran ocasionarse a futuro. Indicar si existieron cambios en los requerimientos y en caso afirmativo presentar el nuevo detalle de requerimientos modificado, cómo se implementó la trazabilidad de esos cambios y cómo se considera que impactan estos cambios en el proyecto. Requerimiento: Nivel de cumplimiento Observaciones: Req #1: Representación visual del uso de la memoria interna del MCU. 100% Autodiagnóstico La capacidad del programa QDirStat de leer el treemap de un archivo externo hace que con el resultado de los grupos de tareas 1 y 2 se cumpla este requisito. Página 12 de 19

13 Responsable de verificación : Acción de verificación prevista: Fecha y resultado de la verificación: Responsable de validación : Acción de validación prevista: Fecha y resultado de la validación: Costos de conformidad incurridos: Costos no conformidad estimados: Alejandro Celery. Comparar la salida del comando nm con la representación gráfica de QDirStat y ver que no falte ninguna variable declarada en el código que se use para la prueba. 01/04/2016. Se verifica OK. Director del trabajo Lo mismo pero con un programa suministrado por el validador. No realizada, 4 horas hombre., ver el plan de proyecto. Requerimiento: Nivel de cumplimiento Observaciones: Responsable de verificación : Acción de verificación prevista: Fecha y resultado de la verificación: Responsable de validación : Acción de validación prevista: Fecha y resultado de la validación: Req #2: Representación visual del uso de la memoria interna del MCU. 100% Autodiagnóstico El uso de treemaps garantiza la fácil identificación de los bloques de memoria que ocupan el mayor espacio en el MCU. Alejandro Celery. Se coteja que el tamaño reportado en el treemap corresponde al de las variables que existen en el programa y que las áreas gráficas tienen los tamaños relativos correctos. 01/04/2016. Se verifica lo previsto. Director del trabajo Lo mismo pero con un programa suministrado por el validador. No realizada, Página 13 de 19

14 Costos de conformidad incurridos: Costos no conformidad estimados: 2 horas hombre., ver el plan de proyecto. Requerimiento: Nivel de cumplimiento Observaciones: Responsable de verificación : Acción de verificación prevista: Fecha y resultado de la verificación: Responsable de validación : Acción de validación prevista: Fecha y resultado de la validación: Costos de conformidad incurridos: Costos no conformidad estimados: Req #3: Indicación de a qué zona de memoria fue asignada cada variable 0% Autodiagnóstico Aún no se ha extraído esta información de los reportes del compilador. Alejandro Celery. Declarar una variable en cada posible zona de memoria de un MCU testigo y ver que el programa la reporte correctamente. No realizada. Director del trabajo Verificar que se cumple el requerimiento en un programa de aplicación suministrado por el validador. No realizada. Aún no se ha trabajado en el cumplimiento de este requerimiento., ver el plan de proyecto. Requerimiento: Nivel de cumplimiento Observaciones: Responsable de verificación : Acción de verificación prevista: Req #4: Presentación de estos datos dentro de una ventana de Eclipse. 0% Alejandro Celery. Autodiagnóstico Verificar que en la ventana de Eclipse se ve correctamente el treemap de un programa de prueba. Página 14 de 19

15 Fecha y resultado de la verificación: Responsable de validación : Acción de validación prevista: Fecha y resultado de la validación: Costos de conformidad incurridos: Costos no conformidad estimados: No realizada. Director del trabajo Verificar que en la ventana de Eclipse se ve correctamente el treemap de un programa de aplicación suministrado por el validador. No realizada. Aún no se ha trabajado en el cumplimiento de este requerimiento., ver el plan de proyecto. Página 15 de 19

16 3. Gestión de riesgos a) Indicar a continuación para cada uno de los riesgos el estado de situación según su criterio, utilizando verde si considera que el riesgo ya no se manifestará o es muy improbable que se manifieste, amarillo si considera que es posible que es improbable que el riesgo se manifieste o si se manifiesta estima que será fácilmente controlado, y rojo si considera que es muy probable que el riesgo se manifieste y que no pueda ser controlado fácilmente. Riesgo #1: No conseguir un experto en Java que quiera colaborar con el proyecto. Riesgo #2: Subestimar la duración de las tareas. Riesgo #3: No encontrar documentación sobre la generación del reporte de compilación. Riesgo #4: No poder adaptar el programa WinDirStat para lo que se necesita. Riesgo #5: Incurrir en un pico de trabajo que no permita dedicar las horas presupuestadas al proyecto. Página 16 de 19

17 b) Para cada uno de los riesgos identificados inicialmente indicar en una tabla: Severidad (S) inicial estimada y estimación actual de la severidad. Justificar el motivo por el cual se cambia o no el número de severidad (S). Probabilidad de ocurrencia (O) inicial estimada y estimación actual de prob. de ocurrencia. Justificar el motivo por el cual se cambia o no el número de Probabilidad de ocurrencia (O). Tasa de no detección (D) inicial estimada y estimación actual de tasa de no detección. Justificar el motivo por el cual se asigna determinado número de (D). Si existen nuevos riesgos que se hayan identificado incluir el análisis correspondiente y el cálculo de su RPN. Riesgo: Riesgo #1: No conseguir un experto en Java Autodiagnóstico Severidad (S): Ocurrencia (O): No detección (D): RPN: Estimación inicial: Estimación actual: Observaciones: Riesgo: Riesgo #2: Subestimar la duración de las tareas Autodiagnóstico Severidad (S): Ocurrencia (O): No detección (D): RPN: Estimación inicial: Estimación actual: Observaciones: Riesgo: Riesgo #3: No encontrar documentación Autodiagnóstico Severidad (S): Ocurrencia (O): No detección (D): RPN: Estimación inicial: Estimación actual: Observaciones: Baja la (O) al emplear herramientas debidamente documentadas para analizar el reporte de compilación. Riesgo: Riesgo #4: No poder adaptar WinDirStat Autodiagnóstico Severidad (S): Ocurrencia (O): No detección (D): RPN: Estimación inicial: Estimación actual: Observaciones: La (O) se vuelve 0 ya que se reemplazó el uso de WinDirStat por QDirStat, que no requiere que se modifique su código. Riesgo: Riesgo #5: Incurrir en un pico de trabajo Autodiagnóstico Severidad (S): Ocurrencia (O): No detección (D): RPN: Estimación inicial: Estimación actual: Observaciones: Este riesgo se materializó y obligó a reprogramar el proyecto para el Página 17 de 19

18 4. Plan de comunicación a) Indicar a continuación para cada uno de las actividades de comunicación previstas el estado de situación según su criterio, utilizando verde si considera que ya se ha cumplido o se está cumpliendo adecuadamente, amarillo si considera que no se ha cumplido o no cumple del todo satisfactoriamente, y rojo si considera que no se ha cumplido y/o no se podrá cumplir. #1 Intercambio de e mail con los desarrolladores de WinDirStat. #2 Reuniones personales con el Champion #3 Difusión en la lista de correos embebidos32 b) Indicar cuáles de las actividades del Plan de Comunicación del Proyecto se realizaron de acuerdo a lo previsto y cuáles no y por qué. La celda Autodiagnóstico pintarla de verde si la comunicación se realizó de acuerdo a lo previsto en tiempo y forma, de amarillo si hubo deficiencias pero la comunicación se realizó de manera mínimamente aceptable, y en rojo si la comunicación se realizó de manera claramente deficiente. PLAN DE COMUNICACIÓN DEL PROYECTO Item #1 Qué comunicar? Audiencia Propósito Frecuencia Método de comunicac. Responsable El uso pretendido de su software Desarrolladores de WinDirStat Obtener su colaboración Al inicio del proyecto e mail Alejandro Celery Se realizó de según lo previsto? Autodiagnóstico Justificación: Al descartarse el uso de esta herramienta no fue necesaria esta actividad de comunicación. La herramienta que la reemplazó no necesita modificaciones. Qué comunicar? PLAN DE COMUNICACIÓN DEL PROYECTO Item #2 Audiencia Propósito Frecuencia Método de comunicac. Responsable Página 18 de 19

19 Estado de avance del proyecto El champion Pedir su ayuda en la búsqueda de un programador Java Mensual Reuniones personales Alejandro Celery Se realizó de según lo previsto? Autodiagnóstico Justificación: Se perdió el contacto personal diario al concluir un proyecto que lo generaba. Se reemplazará por e mails personales si llega a ser necesaria su colaboración. Qué comunicar? PLAN DE COMUNICACIÓN DEL PROYECTO Item #3 Audiencia Propósito Frecuencia Método de comunicac. Responsable Disponibilidad de nuevas versiones de software Posibles adoptantes del software generado en el proyecto Realimentaci ón sobre su experiencia de uso Cada vez que se libera una nueva versión del software Difusión en listas de correo. Alejandro Celery Se realizó de según lo previsto? Autodiagnóstico Justificación: Aún no hay nuevo software para comunicar su disponibilidad. Página 19 de 19