Creador de efectos sobre ruedas en movimiento a través de ...laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-CESE... · Gestión de Compras 22. Seguimiento y control

Plan de Proyecto del Trabajo Final de Carrera

de Especialización de Sistemas Embebidos

Juan Agustín Bassi

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

Autor

Lic. Juan Agustín Bassi

Director del trabajo

Dr. Ing. Pablo Gomez

Jurado propuesto para el trabajo

- Esp. Ing. Ramiro Alonso (FIUBA). - Dr. Ing Ignacio Alvarez Hamelin (FUIBA)

Este plan de trabajo ha sido realizado en el marco de la asignatura gestión de proyectos entre octubre y diciembre de 2015.

Página 1 de 22



Juan Agustín Bassi

Tabla de contenido

Registros de cambios

Acta Constitutiva

1. Nombre del Proyecto

2. Fecha de inicio y finalización del proyecto

3. Presupuesto preliminar asignado

4. Identificación y análisis de los interesados

5. Propósito y Justificación del proyecto

6. Objetivos

7. Alcance del proyecto

8. Supuestos y restricciones del proyecto

9. Requerimientos

10. Entregables principales del proyecto

11. Desglose del trabajo en tareas

12. Análisis de factibilidad

13. Diagrama de Activity On Node

14. Diagrama de Gantt

15. Matriz de uso de recursos de materiales

16. Presupuesto detallado del proyecto

17. Matriz de asignación de responsabilidades

18. Gestión de riesgos

19. Gestión de la calidad

20. Comunicación del proyecto

21. Gestión de Compras

22. Seguimiento y control

23. Procesos de cierre

Página 2 de 22



Juan Agustín Bassi

Registros de cambios

Revisión Cambios realizados Fecha

1.0 Creación del documento. 01/11/15

1.1 Correcciones en el ordenamiento de objetivos. 03/11/15

1.2 Completado de los puntos 11 al 17. 09/11/15

1.3 Correcciones de horas/hombre y desglose de tareas. 10/11/15

1.4 Completado detallado de requerimientos. 11/11/15

1.5 Completado de los puntos 18 a 23. 13/11/15

1.6 Acomodo diagrama Gantt e inclusión de hitos finales. 15/11/15

1.7 Acomodo de diagrama Gantt en procesos de cierre. 16/11/15

1.8 Cuantificación de los objetivos y elección de jurado. 17/11/15

1.9 Revisiones del director del proyecto. 24/11/15

Versión final del documento 24/11/15

Página 3 de 22



Juan Agustín Bassi

Acta Constitutiva

CABA, 1° de noviembre de 2015.

Atte Juan Agustín Bassi

De mi mayor consideración

Con el fin de llevar a cabo la realización de un dispositivo, destinado a crear efectos y dibujos

sobre ruedas en movimiento, a través de LEDs, se lo designa a Ud como Responsable del proyecto

“Efectos sobre ruedas”, con un presupuesto total estimado de 600 horas/hombre, con fecha tentativa

de inicio el 01/11/15 y de finalización 01/06/2016.

Se adjunta a esta acta la planificación inicial.

Oscar Contreras, gerente de ventas en

Man-t Electronics, cliente del proyecto.

Página 4 de 22



Juan Agustín Bassi

1. Nombre del Proyecto

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

2. Fecha de inicio y finalización del proyecto

Fecha de inicio: 01/11/2015.

Fecha de finalización: 01/06/2016.

La prioridad del proyecto es la máxima, por lo que se espera tenerlo listo para los primeros días de junio de 2016, con el fin de poder presentarlo en la “Expo Bici” que tiene lugar en CABA.

3. Presupuesto preliminar asignado

Se comienzan las actividades con un presupuesto preliminar de entre 600 y 650 horas/hombre y con $3000 en efectivo para la compra de todo tipo de materiales y componentes necesarios para la realización del proyecto.

4. Identificación y análisis de los interesados

Rol Nombre y Apellido Departamento Puesto

Auspiciante Man-t Electronics Ventas

Cliente Man-t Electronics Ventas

Responsable Juan Agustin Bassi

Colaboradores Eric Pernía

Pablo Gomez

Ingeniero

Ingeniero

Docente CESE

Director proyecto

Orientadores Pablo Ridolfi

Pablo Gomez

Ingeniero

Ingeniero

Docente CESE

Director proyecto

Usuario Final Ciclistas

Características de los interesados:

● Cliente: Exigente a la hora del cumplimiento de fechas. Penalizará el incumplimiento de las

fechas pactadas a la hora de definir el contrato.

● Colaborador: Dinámico y con buen criterio en la resolución de problemas de software.

● Orientador: Experimentado y con visión a futuro en el desarrollo de ingeniería electrónica, su

mayor influencia será a través de la elección de componentes para el hardware.

Página 5 de 22



Juan Agustín Bassi

● Director: Supervisor de las tareas, con fuerte dominio en los campos del software y hardware

en sistemas embebidos.

● Responsable: Cumplidor en tiempo y forma de las fechas pactadas, trabajará más horas de las

planeadas en caso de encontrarse atrasado el proyecto.

5. Propósito y Justificación del proyecto

El propósito del proyecto es crear un dispositivo que encastre en los rayos de las bicicletas, y pueda generar efectos y dibujos mientras ésta se encuentra en movimiento. Desde el punto de vista académico, el propósito es terminar la Especialización en Sistemas Embebidos.

Por otro lado, los materiales necesarios para la fabricación del dispositivo pueden adquirirse en el país, lo que asegura continuidad y seguridad en el proceso de manufactura.

La justificación es que, después de observar que la cantidad de ciclistas a nivel mundial va en aumento, y sobre todo en Capital Federal, se intenta desarrollar un producto que apunte a este sector.

6. Objetivos

● Al ser un producto a fabricar en serie, su costo debe ser menor a $500. ● El consumo de energía debe durar al menos 4 horas. ● Debe crear efectos cambiando los colores de los LEDs. ● Se debe tener una versión standard con el hardware y software mínimo, y posteriormente

otra versión full. ● Debe poder actualizar su firmware “in circuit”, para adaptar nuevas funcionalidades en los

dispositivos existentes. ● Se debe crear una aplicación para PC, que genere los efectos de forma gráfica, y que luego

se puedan cargar en el microcontrolador.

7. Alcance del proyecto

El alcance del proyecto incluye:

● Crear efectos sobre 10 LEDs RGB, ubicando 5 de cada lado de la placa. ● Efectos sobre ruedas sencillos (cambiar estado de LEDs, variar colores).

No quedan incluidos dentro del alcance:

● Manejar más de un driver de led a la vez. ● Aplicación para smartphone con comunicación bluetooth. ● Aplicación en PC que genere los efectos desde una interfaz gráfica. ● Figuras complejas a mostrar (como pueden ser formas o dibujos).

Página 6 de 22



Juan Agustín Bassi

8. Supuestos y restricciones del proyecto

● Se supone que la rueda más pequeña en la que irá el dispositivo es de 12 pulgadas, y la más grande de 28 pulgadas.

● Se supone que la velocidad mínima a la que se dibujarán los efectos es a 15 km/h y la máxima a 40 km/h.

● Suponiendo que el proyecto va a poder realizarse con 600 horas/hombre, y que se cuentan con 7 meses para la realización del mismo, se estima que, trabajando una persona sola, debe dedicar aproximadamente 4 horas diarias al proyecto (sin contar fines de semana).

9. Requerimientos

1. Características del sistema: 1.1. El abastecimiento de energía durará más de 4 horas. 1.2. El dispositivo se pondrá en modo standby automáticamente si la rueda dejara de

girar y volverá a modo normal cuando detecte giro en la rueda. 1.3. Tendrá módulo bluetooth. 1.4. Los componentes de la placa (exceptuando los LEDs) estarán recubiertos por un

material ultra resistente al agua. (*) 1.5. La placa estará recubierta por un material que la proteja del agua. 1.6. La precisión con la que se mostrarán los efectos y dibujos en la rueda será 1 píxel

cada 2° de giro. 2. Componentes:

2.1. El sensor de efecto hall detectará las vueltas a máxima velocidad. 2.2. Se tendrá más de una tensión.

3. Diseño hardware: 3.1. El diseño de esquemático y PCB deberá contemplar la comunicación con todos los

periféricos. 3.2. Los periféricos deberán ser independientes, es decir que se podrá dispensar de

algunos. 4. Diseño software:

4.1. Se usará repositorio para versionado. 4.2. Diseño del software en alto nivel.

4.2.1. Se modelará la capa de abstracción de hardware para no depender de fabricantes específicos.

4.2.2. El software se adaptará a las versiones preliminares modularmente. 4.2.3. La falta de un periférico no perjudicará el funcionamiento cíclico del

programa. 4.2.4. Se tendrá informes de funcionamiento de dispositivos similares. 4.2.5. Se implementará el software con una versión mínima y otra con

funcionalidades superiores. (*) 4.3. Diseño detallado del software.

Página 7 de 22



Juan Agustín Bassi

4.3.1. Todos los datos correspondientes a los fabricantes de los periféricos estarán detallados en archivos de inicialización, de modo que al momento de realizar la compilación sólo será necesario indicar con qué archivos generar el código ejecutable para el microcontrolador. (*)

4.3.2. Cada módulo del sistema tendrá indicadores de estado. (*) 4.3.3. Los driver de comunicación con periféricos serán modulares. 4.3.4. Se contemplarán todas las funciones y variables necesarias para integrar los

módulos del sistema, aunque no sean todos implementados. 4.4. Diseño de pruebas a realizar.

4.4.1. Se realizará test unitario a cada módulo. 4.4.2. Se evaluará si cumple los objetivos propuestos.

4.5. Integración de funcionalidades. 5. Procesos finales:

5.1. Se confeccionará un manual de usuario. 5.2. Se realizará un video tutorial, explicando visualmente la instalación del dispositivo. 5.3. Se elaborará un informe final con las características del dispositivo, los procesos

que fueron correctos y que vale la pena implementar, así como los que habrá que descartar.

5.4. Se detallarán las funcionalidades que pueden agregarse a futuro. 5.5. Se evaluarán los resultados obtenidos. 5.6. Se agradecerá a todos los involucrados en el proyecto. 5.7. Se realizará un anuncio público de la finalización del proyecto.

(*) Referencia: Son los requerimientos agregados luego de realizar la gestión de riesgos.

10. Entregables principales del proyecto

Al finalizar el proyecto, se entregarán:

● Dispositivo terminado. ● Manual de usuario. ● Video tutorial para realizar la instalación. ● Informe final con los detalles del proyecto. ● Funcionalidades a agregar en versiones posteriores.

11. Desglose del trabajo en tareas

1. Preparar un entorno de desarrollo en PC, con software para: 1.1. Versionar el código. 1.2. Programar en lenguaje C. 1.3. Compilar el programa hacia el microcontrolador elegido. 1.4. Crear el diagrama esquemático del circuito y PCB. 1.5. Simular el programa realizado en C junto con el PCB.

2. Investigación preliminar:

Página 8 de 22



Juan Agustín Bassi

2.1. Medir tiempos para determinar frecuencia de clock a máxima velocidad. 2.2. Evaluar costos de pilas comunes, pilas recargables, baterías y baterías recargables.

Se debe optar por la de mejor precio/duración. 2.3. Investigar material para recubrir la placa.

3. Seleccionar componentes: 3.1. Microcontrolador. 3.2. Driver de LEDs RGB. 3.3. Sensor de efecto hall. 3.4. Memoria EEPROM externa SPI o I2C. 3.5. Módulo bluetooth. 3.6. Filtros de alimentación. 3.7. Pulsadores. 3.8. LEDs de estado. 3.9. LEDs RGB.

4. Buscar proveedores y pedir presupuestos. 4.1. Adquirir componentes.

5. Diseñar hardware: 5.1. Realizar diagrama esquemático. 5.2. Probar en protoboard. 5.3. Rutear de las pistas. 5.4. Testar y corregir en software de simulación. 5.5. Diseñar placa final. 5.6. Fabricar placa final. 5.7. Soldar de componentes.

6. Diseñar software: 6.1. Diseñar y testear drivers de comunicación entre microcontrolador y cada

periférico. 6.2. Estudiar de aplicaciones similares. 6.3. Modelizar efectos para las ruedas y crear de capas de abstracción de hardware. 6.4. Realizar máquina de estados y diagrama de flujo. 6.5. Diseñar programa principal. 6.6. Testear y corregir bugs.

7. Realizar procesos finales: 7.1. Crear manual de usuario. 7.2. Grabar video tutorial de instalación y subirlo a internet. 7.3. Realizar informe de características del dispositivo, y lecciones aprendidas. 7.4. Realizar informe sobre nuevas funcionalidades a agregar en versiones futuras. 7.5. Evaluar los resultados, comparar los requerimientos planteados con los obtenidos. 7.6. Agradecer formalmente a los involucrados en el proyecto. 7.7. Realizar un anuncio público de finalización del proyecto, y mostrar en ese anuncio

el producto terminado.

Página 9 de 22



Juan Agustín Bassi

12. Análisis de factibilidad

Respecto a la factibilidad técnica, hay proyectos que tienen características similares (ej: propeller clock, que posee microcontrolador, driver de LEDs, y debe girar para mostrar la hora) , y que en internet se puede comprobar su correcto funcionamiento.

Con respecto a la factibilidad económico-financiera, se considera aceptable y que puede tener repercusión positiva en el ambiente del ciclismo, sobre todo los que disfrutan del ciclismo nocturno. Además, el dispositivo puede servir para motocicleta, lo que amplía el panorama respecto a los usuarios finales.

Analizando la factibilidad técnica, como la económico-financiera, se concluye que es un proyecto que puede realizarse en tiempo y forma y obtener los beneficios deseados.

13. Diagrama de Activity On Node

El valor de las unidades representadas es t = horas / hombre. Para rutear las pistas, es necesario diseñar los drivers de comunicación con periféricos, ya que se puede dar que la conexión no pueda establecerse en el lugar primeramente planeado, (ej: multiplexación de pin del uC). Luego de comunicar correctamente los periféricos se debe realizar el ruteo de pistas.

Página 10 de 22



Juan Agustín Bassi

14. Diagrama de Gantt

Página 11 de 22



Juan Agustín Bassi

15. Matriz de uso de recursos de materiales

Código WBS Nombre de la tarea

Recursos requeridos (horas)

PC Proto

board Soldador Torno

Bicicleta Motor para

girar rueda

1.4 - … - 1.4 Preparar entorno en PC 15

2.1 - 2.2 - 2.3 Investigación preliminar 15

3.1 - … - 3.9 Selec. componentes 20

4.1 -4.2 Buscar presupuestos -

adquirir componentes

20

5.1 Diagrama esquemático 20

5.2 Armado en protoboard 10 15

5.3 - 5.4 - 5.5 Ruteo pistas - Testeo y

corrección -

Diseño final PCB

65

5.6 Fabricar prototipo PCB 10 10 10

6.1 Diseñar y testear

drivers

130 130

6.2 - … - 6.4 Estudiar aplicaciones

similares - Modelizar

efectos y HAL -

Máquina estados y

diagrama flujo - Diseño

programa principal

225

6.6 Testeo de bugs 50 50 50

7 Procesos de cierre 70

TOTALES - 650 145 10 10 50 50

Página 12 de 22



Juan Agustín Bassi

16. Presupuesto detallado del proyecto El valor de las unidades debajo es expresado en pesos $.

● Costo de componentes (aprox): ○ Microcontrolador = 100 ○ Driver de LEDs = 100 ○ Placa de cobre = 30 ○ Módulo bluetooth = 150 ○ Memoria externa = 50 ○ Sensor de efecto hall = 30 ○ Pulsadores = 10 ○ LEDs RGB = 30

------------------------------------------------------------- ○ Total componentes = 500

● Costos de materiales extras:

○ Horquilla y rueda de bicicleta = 300 ○ Motor eléctrico para girar rueda = 300

------------------------------------------------------------- ○ Total materiales extras = 600

● Costos de viajes hacia:

○ Distribuidores de componentes = 100 ○ Bicicleterías = 50 ○ Motor eléctrico = 50

------------------------------------------------------------- ○ Total de viajes = 200

● Costos de empleados:

○ Hora / hombre = 100 ------------------------------------------------------------ Total horas / hombre (600) = 60000

Con los subtotales obtenidos, se agrega un 20 % a la suma de los mismos como gastos extras no contemplados en el primer análisis.

Página 13 de 22



Juan Agustín Bassi

● Subtotal componentes = 500 ● Subtotal materiales extras = 600 ● Subtotal viajes = 200 ● Subtotal empleados = 60000

--------------------------------------------------------------------------- ● Subtotales sumados = 61300 ● Gastos extras = 12260

--------------------------------------------------------------------------- ● Total = 73560

17. Matriz de asignación de responsabilidades

Código WBS Título de la tarea

Listar todos los nombres y apellidos y el rol definidos en el proyecto

Agustin Bassi Eric Pernía Pablo Ridolfi

Pablo Gomez

1.1 - … - 1.4 Preparar entorno de desarrollo P C C

2.1 - 2.2 - 2.3 Investigación preliminar P C C A

3.1 - … - 3.9 Selección de componentes P C A

4.1 - 4.2 Buscar presupuestos - Adquirir

componentes

P C C C

5 Diseñar el hardware P C C A

6 Diseñar el software P C C A

Referencias: P = Responsabilidad Primaria S = Responsabilidad Secundaria A = Aprobación I = Informado C = Consultado

Página 14 de 22



Juan Agustín Bassi

18. Gestión de riesgos En caso de no cumplimiento de los siguientes requerimientos:

1. El abastecimiento de energía debe durar al menos 4 horas. 1.1. Severidad (9): El proyecto fracasará rotundamente si la placa no dura energizada al

menos una jornada de pedaleo. 1.2. Ocurrencia (3): No está probado cuánta energía pueden entregar las diferentes

opciones. Debido a que la severidad es muy alta en caso que pase, se utilizará, aunque más costosa, la opción de batería recargable, que sí cumplirá el requerimiento.

1.3. Tasa de no detección (2): Debido a que previo al lanzamiento se probará el dispositivo para determinar la duración del abastecimiento.

2. La placa estará recubierta por un material que la proteja del agua. 2.1. Severidad (10): La placa se dañará quedando inutilizable. 2.2. Ocurrencia (5): Habrá que probar la aislación que pueden otorgar las diferentes

opciones. 2.3. Tasa de no detección (8): Será difícil comprobar la duración real del recubrimiento

debido a que los tiempos de prueba se extenderán más que los de finalización del proyecto.

3. El sensor de efecto hall detectará las vueltas de la rueda a máxima velocidad. 3.1. Severidad (7): El sistema se mostrará inestable y no podrá dibujar efectos y figuras

correctamente. 3.2. Ocurrencia (2): En el mercado hay una extensa gama de sensores de efecto hall, por

lo que se podrá conseguir uno que cumpla los requerimientos de velocidad. 3.3. Tasa de no detección (2): Las pruebas en el proceso de desarrollo demostrarán

cómo funciona el sensor a máxima velocidad. 4. La falta de un periférico no perjudicará el funcionamiento cíclico del programa.

4.1. Severidad (7): En caso que por falta de stock no se pueda adquirir un componente, éste podrá afectar la producción del dispositivo.

4.2. Ocurrencia (3): Habrá un alto grado de posibilidades que el software se pueda realizar de manera modular, para no depender de un componente o módulo específico.

4.3. Tasa de no detección (3): Debido a que en el proceso de prueba y test se realizarán las pruebas, con diferentes combinaciones entre módulos y sistema.

5. Se modelará la capa de abstracción para no depender de fabricantes específicos. 5.1. Severidad (6): En caso que un fabricante discontinúe un chip, o bien no tenga stock

del mismo, habrá que rediseñar el software y hardware para adaptar al nuevo modelo.

5.2. Ocurrencia (6): Estando en Argentina, y debido a los problemas de importación, habrá una posibilidad que esto suceda.

5.3. Tasa de no detección (6): No se podrá estar consultando continuamente a los proveedores a ver si tienen o no el chip en stock, ni tampoco, debido al bajo

Página 15 de 22



Juan Agustín Bassi

presupuesto, se podrán adquirir gran cantidad de chips a la vez, si no que la producción será sobre la demanda.

Tabla de gestión de riesgos:

Riesgo Severidad Ocurren. Detección RPN Severidad* Ocurren.*

Detecc * RPN*

1 9 3 2 54

2 10 5 8 400 10 1 3 30

3 7 2 2 28

4 7 3 3 63 2 3 2 12

5 6 6 6 216 3 2 2 12

Criterio adoptado: Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 60. Nota: Los valores marcados con (*) en la tabla corresponden luego de haber aplicado la mitigación. Plan de mitigación de los riesgos que originalmente excedían el PRN máximo establecido:

1. Riesgo 2: La placa estará recubierta por un material que la proteja del agua. a. Plan de mitigación: La placa será recubierta de por un material transparente que la

proteja del agua. Además las partes más sensibles al agua (microcontrolador e integrados) serán cubiertas por otro material adicional, que será silicona derretida (la que se inyecta a través de una pistola). De esta manera solo quedará sin ese doble recubrimiento los LEDs, que son lo que realmente el dispositivo debe mostrar.

b. Severidad (10): Si de todas formas, la placa fuera afectada por el agua, la misma quedará inutilizable.

c. Ocurrencia (1): Teniendo un doble recubrimiento, queda muy acotada la probabilidad que ocurra.

d. Tasa de no detección (3): Se pondrá un reactor al agua sobre la superficie de la placa que haga evidente que hubo filtraciones, de esta manera detectará a tiempo el problema.

2. Riesgo 4: La falta de un periférico no perjudicará el funcionamiento cíclico del programa. a. Plan de mitigación: Se diseñará el software de tal manera que, en caso de no

encontrarse habilitado un periférico, se saltará la lógica empleada para ese módulo. Cada periférico tendrá una bandera de habilitado/deshabilitado. También se elaborará un plan para que el dispositivo pueda trabajar con funcionalidades reducidas.

Página 16 de 22



Juan Agustín Bassi

b. Severidad (2): Debido a que los casos en que no esté habilitado un módulo serán probados previo al lanzamiento del producto.

c. Ocurrencia (3): Las posibilidades que un distribuidor se quede sin stock. d. Tasa de no detección (2): Este tipo de lógica podrá probarse fácilmente, hasta sin

necesidad del propio hardware. Solamente simulando estos valores, y ejecutando el software.

3. Riesgo 5: Se modelará la capa de abstracción para no depender de fabricantes específicos. a. Plan de mitigación: Las interfaces, que serán la conexión entre la aplicación de

usuario y el hardware del sistema, serán configuradas a través de archivos de inicialización, de modo que, una vez codificado el código fuente, se puede invocar al compilador bajo diferentes condiciones, y así generar el código correcto para cada fabricante.

b. Severidad (3): Las variantes con la que se configurará el código será tal que contemplará la mayoría de los fabricantes en cada caso. De esta manera la severidad radicará en que ninguna de las opciones contempladas se puedan conseguir.

c. Ocurrencia (2): Habrá bajas probabilidades que por un componente el dispositivo deje de ser manufacturado.

d. Tasa de no detección (2): Se tendrán variantes para cada componente, el caso en que no se detecte el abastecimiento de uno sería si todos los fabricantes contemplados (varios) no comercializaran más sus productos en el país.

19. Gestión de la calidad ● El abastecimiento de energía durará más de 4 horas.

○ Calidad: Alcanzar el tiempo especificado. ○ Grado de calidad: Implementar modos de ahorro de energía en el firmware. Además

implementar un circuito de carga para pila/batería con el movimiento de la rueda. ○ Costo de conformidad: Implementar modos de bajo consumo en el

microcontrolador tiene costos notables en la performance del mismo. Por otro lado, realizar un circuito de carga de energía implica un análisis y costo adicional al proyecto.

○ Costo de no conformidad: Fabricar un producto con alto consumo de energía puede provocar un fracaso, debido a que no abastecería ni una jornada de pedaleo.

○ Verificación: Realizada por el responsable del proyecto. La verificación constará de determinar si el tiempo de energía supera el requerido.

○ Validación: Realizada por el responsable del proyecto. La validación constará de hacer funcionar al dispositivo durante el período requerido, y en caso que supere ese tiempo energizado, superará el requerimiento.

● La placa estará recubierta por un material que la proteja del agua. ○ Calidad: Lograr que la placa no se dañe con la exposición al agua.. ○ Grado de calidad: Lograr que además de la placa, el cable de alimentación también

se encuentre protegido. ○ Costo de conformidad: Agregar material y costo extra al producto.

Página 17 de 22



Juan Agustín Bassi

○ Costo de no conformidad: La placa puede quedar inutilizable en contacto con el agua.

○ Verificación: Realizada por responsable proyecto. La verificación constará de determinar que el material elegido para recubrir la placa sea resistente al agua.

○ Validación: Realizada por responsable del proyecto. La validación constará de exponer la placa al agua y determinar la respuesta de los hechos.

● Los periféricos deberán ser independientes, es decir que se podrá dispensar de algunos. ○ Calidad: Comprobar qué sin algunos componentes (pulsadores, memoria,

bluetooth), aunque con funcionalidades reducidas, el sistema responda correctamente.

○ Grado de calidad: Quitar en tiempo de ejecución un módulo y que el sistema adopte el cambio automáticamente.

○ Costo de conformidad: Modelizar el software de manera tal que cada módulo tenga indicadores de estado, dependiendo de estos, se puede asociar y desasociar su funcionalidad ligada.

○ Costo de no conformidad: Estar frente a la rotura de un periférico, o no contando con el stock de uno y que el producto no pueda ser vendido o no pueda funcionar.

○ Verificación: Realizada por responsable del proyecto. La verificación constará de evaluar que con la falta de uno o varios periféricos, el sistema deshabilite funcionalidades pero siga funcionando.

○ Validación: Realizada por responsable del proyecto. La validación constará de quitar el módulo bluetooth, los pulsadores y la memoria externa y comprobar que se dibujen los efectos en la rueda.

● Se modelará la capa de abstracción de hardware para no depender de fabricantes específicos.

○ Calidad: Poder cambiar de fabricantes de componentes sin necesidad de cambios en el software o hardware.

○ Grado de calidad: Con solo cambiar una definición global en el proyecto, se tendrán todos los recursos y datos disponibles para cambiar de fabricante.

○ Costo de conformidad: Estudiar cómo trabaja cada fabricante con su integrado tiene un costo de tiempo elevado.

○ Costo de no conformidad: Estar frente a un proveedor que no entrega mercadería con la producción detenida.

○ Verificación: Realizada por responsable del proyecto. La verificación constará de contemplar qué componentes son los apropiados para buscar opciones de fabricantes..

○ Validación: Realizada por responsable del proyecto. La validación constará de intercambiar los componentes del sistema (memoria EEPROM, sensor hall, módulo bluetooth) y que responda siempre la misma manera.

Página 18 de 22



Juan Agustín Bassi

● Se implementará el software con una versión mínima y otra con funcionalidades superiores.

○ Calidad: Lograr dos versiones del producto. ○ Grado de calidad: Lograr que el software sea inteligente para determinar en qué

modo funcionar de forma automática. ○ Costo de conformidad: Analizar, evaluar y llevar a cabo dos fases del proyecto. ○ Costo de no conformidad: Retrasar el tiempo de tener un producto tangible para

realizar pruebas tempranas, aumenta el riesgo que el producto final tiene de fracasar, debido que pudo no cumplir con los requerimientos planeados.

○ Verificación: Realizada por responsable del proyecto. La verificación constará de asegurar que una versión reducida conste las prestaciones mínimas, y que una versión completa abarque todos los aspectos propuestos.

○ Validación: Realizada por responsable del proyecto. La validación constará de comprobar que se tengan dos versiones del proyecto, una minimalista, con sólo lo necesario y otra completa, con funciones más complementarias

● Se realizará test unitario a cada módulo. ○ Calidad: Probar el funcionamiento de cada módulo independientemente. ○ Grado de calidad: Automatizar los test unitarios. ○ Costo de conformidad: Aprender a emplear herramientas de test unitario y

automatización de pruebas. ○ Costo de no conformidad: No probar correctamente un módulo y que falle en el

producto del usuario final. ○ Verificación: Realizada por responsable del proyecto.

La verificación constará de determinar que cada módulo tenga un informe de los datos a la entrada y salida.

○ Validación: Realizada por responsable del proyecto. La validación constará de probar cada módulo y función individualmente, y comprobando que la salida tenga concordancia con los datos de entrada.

Página 19 de 22



Juan Agustín Bassi

20. Comunicación del proyecto

PLAN DE COMUNICACIÓN DEL PROYECTO

¿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

email Aula CESE

responsable del proyecto

Diseño de PCB

Pablo Gomez

Confirmar la correcta

distribución de componentes

Durante el proceso de

desarrollo del PCB, una vez por semana

email Aula CESE


Diseño de drivers

Eric Pernía Recibir sugerencias de

diseño

Cada vez que se termine un

driver

email Aula CESE


Diseño del programa principal

Eric Pernía Pablo

Gomez Pablo Ridolfi

Recibir sugerencias de

diseño

En el proceso de desarrollo, semanalmente

email Aula CESE


21. Gestión de Compras Para realizar el proyecto, es necesario, por un lado adquirir los componentes que conformarán el dispositivo, y por otro lado los materiales extras que se necesitarán para realizar las pruebas. Con respecto a los componentes, la elección de proveedores priorizará los mismos en función de los siguientes requisitos:

● Ofrezca el mejor precio y tiempo de entrega. ● Asegure que traerá el/los componentes al menos durante 6 meses más desde el inicio del

proyecto.

La adquisición de materiales extras puede realizarse en cualquier lugar. La elección de un vendedor, será por :

● Cercanía al lugar de desarrollo del proyecto. ● Mejor precio.

Página 20 de 22



Juan Agustín Bassi

22. Seguimiento y control

SEGUIMIENTO DE AVANCE

Tarea del WBS Indicador de avance

Frecuencia de reporte

Responsable de

seguimiento

Persona a ser informada

Método de comunicac.

Preparar entorno de

desarrollo en PC

Instalación de un programa

una vez finalizada la

instalación de todos.


director del proyecto

email Aula CESE

Seleccionar componentes

Selección de cada

componente

una vez finalizada la selección de

todos.



email Aula CESE

Diseñar PCB Cantidad de componentes

ruteados

semanal responsable del proyecto

director del proyecto y

colaboradores

email Aula CESE

Diseñar drivers

Cantidad de drivers

diseñados

Al finalizar cada driver


Eric Pernía email Aula CESE

Diseñar programa principal

Funciones codificadas

Semanal responsable del proyecto

colaboradores

email Aula CESE

Realizar procesos de

cierre

Realización de cada una de

las tareas

Al finalizar todas



colaboradores

jurado

email Aula CESE personal

Página 21 de 22



Juan Agustín Bassi

23. Procesos de cierre Al momento de finalización del proyecto se deberán realizar las siguientes actividades:

● Determinar si el proyecto siguió las pautas de trabajo. ○ Persona a cargo: Responsable del proyecto. ○ Procedimiento a aplicar: Listar todos los requerimientos planteados, y en función

de cada uno, determinar si el dispositivo cumple los mismos. El porcentaje de requerimientos cumplidos determinará el grado de calidad. Esto debe ser informado en una planilla, y en caso de no cumplir el requisito indicar porque no lo hace.

● Identificar técnicas y procedimientos realizados durante el proyecto. ○ Persona a cargo: Responsable del proyecto. ○ Procedimiento a aplicar: A partir del listado de tareas a realizar (WBS), se tendrá

una planilla en la que se explique la metodología aplicada para resolver dichas tareas, a su vez, se tendrá un indicador si la forma de realizarlo fue correcta o no. De esta manera, se podrá tener visión a futuro de qué cosas son útiles y cuáles no.

● Organizar acto de agradecimiento: ○ Persona a cargo: Responsable del proyecto. ○ Procedimiento a aplicar: Una vez defendido el proyecto ante el jurado, se

agradecerá formalmente a cada miembro e involucrado del equipo. En caso que el jurado lo califique exitoso, se realizará un brindis con las personas involucradas y se intentará tenerlas en cuenta para los próximos proyectos. Este brindis, será invitado por el cliente del proyecto, Man-t Electronics.

Página 22 de 22

Documents

Creador de efectos sobre ruedas en movimiento a través de ...laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-CESE... · Gestión de Compras 22. Seguimiento y control