Creador de efectos sobre ruedas en movimiento a través de LEDs RGB.

Transcripción

1 Creador de efectos sobre ruedas en movimiento a través de LEDs RGB. Autor Director del trabajo Dr. Ing. Pablo Gomez Jurado propuesto para el trabajo Esp. Ing. Ramiro Alonso (FIUBA). Dr. Ing Ignacio Alvarez Hamelin (FUIBA). Ing. Gustavo Alessandrini (INTI). Página 1 de 21

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 23/02/ Agregado de lista de requerimientos fuera del alcance 24/02/ Página 2 de 21

3 1. Avance en las tareas Detalle de la simbología empleada en la tabla. Color de las tareas en funcion de su estado de situación: Verde: Satisfactorio. Amarillo: Insatisfactorio por sobrecostos y/o demoras. Rojo: Muy insatisfactorio por sobrecostos y/o demoras. 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. 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. Página 3 de 21

4 Las siguientes tareas salieron del primer análisis de requerimientos: 1.0 Entorno de desarrollo. $ = 2.0 Investigación preliminar. $ = 3.0 Seleccionar componentes. 3.1 Buscar proveedores y presupuestos. 3.2 Adquirir componentes. $ = $ = $ Diagrama esquemático. 4.1 Prueba protoboard. 4.2 Ruteo de pistas. 4.3 Testeo de HW. 4.4 Diseño final PCB. 4.5 Fabricar PCB. $ + $ = $ + $ + $$ ++ $ Diseño y test de drivers. 5.1 Analizar aplicaciones similares. 5.2 Modelizar la HAL y efectos a mostrar. 5.3 Máquina de estados y diagrama flujo. 5.4 Diseño programa principal (integración) 5.5 Test y corrección de bugs. $ + $ = $$ = $ = $ = $ = Se rediseñó el diagrama de Gantt debido a que los siguientes requerimientos no fueron considerados dentro de la nueva definición de alcance del proyecto. O bien para cumplir con los plazos de entrega previstos (*) o porque luego de un análisis más profundo no son necesarios (**). Página 4 de 21

5

6 El nuevo diagrama de Gantt queda de la siguiente manera: Página 6 de 21

7 Nombre de la tarea : 1.0 Preparar entorno de desarrollo Autodiagnóstico Responsable: Informado a: Consultado con: Aprobado por: Agustín Bassi Agustín Basi Observaciones y comentarios Grado de avance planificado: Fecha de finalización planificada: Horas de trabajo planificadas: Recursos planificadas: Se creó un ambiente de desarrollo en Linux para programar microcontroladores ARM de 32 bits. 100 % Grado de avance 100 % alcanzado: 10/11/2015 Fecha de finalización 10/11/2015 estimada/alcanzada: 15 Horas de trabajo 15 utilizadas: PC Recursos PC utilizados: Nombre de la tarea : 2.0 Investigación preliminar Autodiagnóstico Responsable: Informado a: Consultado con: Aprobado por: Agustín Bassi Agustín Bassi Observaciones y comentarios Grado de avance planificado: Fecha de finalización planificada: Horas de trabajo planificadas: Recursos planificadas: Investigación de restricciones de tiempo. 100 % Grado de avance alcanzado: 16/11/2015 Fecha de finalización estimada/alcanzada: 16 Horas de trabajo utilizadas: PC Recursos utilizados: 100 % 16/11/ PC Página 7 de 21

8 Nombre de la tarea 3.0 Componentes Autodiagnóstico : Responsable: Informado a: Consultado con: Aprobado por: Agustín Bassi Pablo Gomez. Eric Pernía. G. Alessandrini Agustín Bassi Observaciones y comentarios Grado de avance planificado: Fecha de finalización planificada: Horas de trabajo planificadas: Recursos planificadas: A través de las clases de la CESE, se consultó a profesores y compañeros acerca de qué componentes se podían utlizar. Se buscó proveedores y se adquirieron componentes. 100 % Grado de avance 100 % alcanzado: 20/11/2015 Fecha de finalización 20/11/2015 estimada/alcanzada: 45 Horas de trabajo 45 utilizadas: PC Recursos PC utilizados: Nombre de la tarea : 5.0 Diseñar el Hardware Autodiagnóstico Responsable: Informado a: Consultado con: Aprobado por: Agustín Bassi Pablo Gomez Pablo Gomez Observaciones y comentarios Grado de avance planificado: Fecha de finalización planificada: Se resume en una tarea diseñar el HW. Al día de la fecha se tiene armado en protoboard el circuito con un kit de desarrollo. Falta armar formalmente el esquemático, diseñar y armar PCB. 10 % Grado de avance 5 % alcanzado: 22/03/2016 Fecha de finalización estimada/alcanzada: Página 8 de 21

9 Horas de trabajo planificadas: Recursos planificadas: 105 Horas de trabajo utilizadas: PC, protoboard, soldador, torno Recursos utilizados: 10 PC, protoboard. Nombre de la tarea 6.0 Diseñar software Autodiagnóstico : Responsable: Informado a: Consultado con: Aprobado por: Agustín Bassi G. Alessandrini. Pablo Gomez. Eric Pernía. Pablo Ridolfi. G. Alessandrini. Pablo Gomez. Observaciones y comentarios Grado de avance planificado: Fecha de finalización planificada: Horas de trabajo planificadas: Recursos planificadas: Se resume en una tarea el diseño del software. La serie de tareas listadas en el WBS va a cumplirse a más tardar para la fecha de finalización pactada. 35 % Grado de avance 25 % alcanzado: 03/06/2016 Fecha de finalización 03/06/2016 estimada/alcanzada: 405 Horas de trabajo 60 utilizadas: PC, bicicleta, motor eléctrico, protoboard. Recursos utilizados: PC, protoboard. Nombre de la tarea 7.0 Procesos de cierre Autodiagnóstico : Responsable: Informado a: Consultado con: Aprobado por: Agustín Bassi Pablo Gomez. Ramiro Alonso. Ignacio Alvarez. Gustavo Alessandrini. Pablo Gomez. Observaciones y comentarios En esta tarea se finalizará formalmente el proyecto, presentando lo pactado (Manual, video de instalación, evaluación de resultado) teniendo el aval tanto de los jurados como el director del proyecto Página 9 de 21

10

11

12

13

14

15

16 3. Gestión de riesgos Debido a que algunos requerimientos quedaron fuera del alcance y a su vez, sus riesgos asociados, los riesgos a tener en cuenta son: Riesgo #1: El sensor de efecto hall detectará las vueltas de la rueda a máxima velocidad. Riesgo #2: La falta de un periférico no perjudicará el funcionamiento cíclico del programa. Riesgo #3: Se modelará la capa de abstracción para no depender de fabricantes específicos. Página 16 de 21

17 Riesgo: Riesgo #1: El sensor de efecto hall detectará las vueltas de la rueda a máxima velocidad. Severidad (S): Ocurrencia No detección (D): RPN: (O): Estimación inicial: Estimación actual: Observaciones: En caso que el sensor no pueda detectar la vuelta se realizará un promedio entre las velocidades máximas y mínimas en cada rodado y en función de esa cuenta se estimará un tiempo de vuelta como si fuera detectado por el sensor de efecto hall. Riesgo: Riesgo #2: La falta de un periférico no perjudicará el funcionamiento cíclico del programa. Severidad (S): Ocurrencia No detección (D): RPN: (O): Estimación inicial: Estimación actual: Observaciones: Se sostiene el plan de mitigación indicado en la sección gestión de riesgos del documento general del proyecto. Riesgo: Riesgo #2: Se modelará la capa de abstracción para no depender de fabricantes específicos. Severidad (S): Ocurrencia No detección (D): RPN: (O): Estimación inicial: Estimación actual: Observaciones: Se sostiene el plan de mitigación indicado en la sección gestión de riesgos del documento general del proyecto. Página 17 de 21

18

19 4. Plan de comunicación Seleccionar componentes. Diseño PCB. Diseño de drivers. Diseño del programa principal. Página 19 de 21

20 PLAN DE COMUNICACIÓN DEL PROYECTO Item #1 Qué comunicar? Audiencia Propósito Frecuencia Método de comunicac. Responsable Selección de componentes Eric Pernía. Pablo Ridolfi. Confirmar la correcta selección de componentes. Una vez seleccionados todos los componentes Aula CESE Agustín Bassi Se realizó de según lo previsto? Autodiagnóstico Justificación: Mediante mails y consulta en las clases del CESE se determinaron los componentes a utilizar correctamente. Qué comunicar? PLAN DE COMUNICACIÓN DEL PROYECTO Item #2 Audiencia Propósito Frecuencia Método de comunicac. Responsable Diseño PCB Pablo Gomez Confirmar la correcta distribución de componentes Durante el proceso de desarrollo del PCB, una vez por semana Aula CESE Lab. SE UBA Agustín Bassi Se realizó de según lo previsto? Autodiagnóstico Justificación: No se comenzó con la actividad pero se habló de solicitar ayuda cuando llegue el momento del diseño. Página 20 de 21

21 PLAN DE COMUNICACIÓN DEL PROYECTO Item #3 Qué comunicar? Audiencia Propósito Frecuencia Método de comunicac. Responsable Diseño drivers Eric Pernía G. Alessandrini Recibir sugerencias de diseño Cada vez que se comience un driver. Aula CESE Agustín Bassi Se realizó de según lo previsto? Autodiagnóstico Justificación: Plan acuerdo a lo previsto. Qué comunicar? PLAN DE COMUNICACIÓN DEL PROYECTO Item #4 Audiencia Propósito Frecuencia Método de comunicac. Responsable Diseño programa principal Pablo Gomez Eric Pernía Pablo Ridolfi G. Alessandrini Recibir sugerencias de diseño Durante el proceso de desarrollo Aula CESE Lab. SE UBA Agustín Bassi Se realizó de según lo previsto? Autodiagnóstico Justificación: No se comenzó con la actividad pero cuando se comience se tratará de cumplir pero menos frecuencia. Página 21 de 21