prototipo funcional de un sistema de detección de...

Plan de Proyecto del Trabajo Final de Carrera

de Especialización de Sistemas Embebidos

Ing. Matías Dell’Oso

Página 1 de 24

Prototipo funcional de un

sistema de detección de

caídas

Autor

Ing. Matías Dell'Oso

Director del trabajo

Esp. Ing. Pablo Ridolfi

Jurado propuesto para el trabajo

Mg. Ing. Juan Manuel Reta (UNER)

Ing. Gerardo Sager (UNLP)

Dr. Ing. Pablo Gomez (FIUBA)

Este plan de trabajo ha sido realizado en el marco de la asignatura gestión de

proyectos entre octubre y diciembre de 2015.

Ariel Lutenberg




Página 2 de 24

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 ActivityOnNode

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 3 de 24

Registros de cambios

Revisión Cambios realizados Fecha

1.0 Creación del documento 30/10/2015

1.1 Correcciones de los puntos 1 a 7 y agregado de los puntos 8 a

11

04/11/2015

1.2 Correcciones de los puntos 1 a 11 07/11/2015

1.3 Correcciones de los puntos 1 a 11 y agregado de los puntos 12

a 17

11/11/2015

1.4 Correcciones de los puntos 6, 13, 14 y 17 12/11/2015

1.5 Correcciones de los puntos 9, 13, 14 y 16. Agregado de los

puntos 18 a 23

17/11/2015

1.6 Correcciones de los puntos 5, 6, 8, 9, 10, 13, 14, 17 y 19.

Agregado del jurado propuesto para el trabajo

25/11/2015

Ariel Lutenberg




Página 4 de 24

Acta Constitutiva

CABA, 3º de noviembre de 2015

Atte. Matías Dell'Oso

De mi mayor consideración

Con el fin de diseñar un detector de caídas que permita mejorar la tasa de aciertos que poseen los

detectores de caídas que se encuentran actualmente en el mercado, se lo designa a Ud como

Responsable del proyecto Prototipo funcional de un sistema de detección de caídas con un presupuesto

total estimado de 600 horas/hombre, con fecha tentativa de inicio 30/10/2015 y de finalización

30/06/2016.

Se adjunta a esta acta la planificación inicial.

Lic. Laura Lanzarini

Secretaria de Ciencia y Técnica

Universidad de La Plata

Ariel Lutenberg




Página 5 de 24

1. Nombre del Proyecto

Prototipo funcional de un sistema de detección de caídas.

2. Fecha de inicio y finalización del proyecto

Fecha de inicio: 30/10/2015

Fecha de finalización: 30/06/2016

3. Presupuesto preliminar asignado

600 hs/persona y $3000 pesos argentinos para la compra de materiales

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

Rol Nombre y Apellido Departamento Puesto

Auspiciante Laboratorio de

investigación III-LIDI

Universidad de La Plata

Cliente Laura Lanzarini Licenciada Investigador

Impulsor Laura Lanzarini Licenciada Investigador

Responsable Matías Dell'Oso Ingeniero Investigador

Colaboradores Laura Lanzarini Licenciada Investigador

Orientadores Pablo Ridolfi Ingeniero Investigador

Equipo

Opositores

Usuario Final Personas de avanzada

edad

- Auspiciante: El laboratorio de investigación III-LIDI espera que el proyecto se termine en tiempo y

forma. De no ser cumplidos los plazos de tiempo los objetivos no estarán logrados.

Ariel Lutenberg




Página 6 de 24

- Impulsor: Laura Lanzarini es exigente en cuanto a presentar informes de avances. Se deberá

adoptar una metodología ágil, por ejemplo scrum.

- Orientador: Pablo Ridolfi no reside en la misma ciudad que el responsable. La comunicación deberá

ser vía mail y se deberán coordinar reuniones mensuales.

5. Propósito y Justificación del proyecto

El propósito de este proyecto es obtener el título de Especialista en Sistemas Embebidos que otorga

la Universidad de Buenos Aires. Se pondrá mayor esfuerzo en la realización de hardware con el fin de

profundizar los conocimientos en esta área. Para ello, se propone diseñar un detector de caídas que

permita mejorar la tasa de aciertos que poseen los detectores de caídas que se encuentran

actualmente en el mercado. El énfasis estará puesto en lograr una solución de bajo costo a fin de

facilitar su uso por parte de los distintos sectores de la sociedad.

Este proyecto también tiene como propósito ser un punto de partida para luego crear un nuevo

sistema reutilizando el hardware y modificando el algoritmo a uno basado en redes neuronales, con

el fin de aumentar en gran medida la tasa de aciertos del dispositivo.

La justificación de este proyecto es que los detectores de caídas del mercado suelen tener una tasa de

fallos que no es aceptable para pacientes críticos. Además, el costo que presenta es elevado lo que

limita el alcance del mismo.

6. Objetivos

Terminar el proyecto antes del 30 de junio de 2016

Lograr identificar cuál es la mejor combinación de dispositivos (acelerómetro,

microcontrolador, módulo de comunicación) para crear una solución económica (tratar de

mantener el precio por debajo de los $1000 argentinos) y al mismo tiempo que arroje datos

confiables.

7. Alcance del proyecto

El proyecto incluye la realización de un prototipo de hardware completamente funcional, con

el cual se podrán detectar caídas.

Se crearán los drivers para manejar los distintos módulos utilizados.

Se implementará un algoritmo basado en umbrales para verificar el correcto funcionamiento

del dispositivo.

Ariel Lutenberg




Página 7 de 24

Se creará un software a modo de interfaz de usuario, en el cual se recibirán las notificaciones

provenientes del dispositivo.

El proyecto no incluye la creación de una base de conocimientos.

El proyecto no incluye la realización del algoritmo final de la rede neuronal.

8. Supuestos y restricciones del proyecto

Supuestos:

Todos los módulos necesarios para el proyecto podrán adquirirse.

El dispositivo estará pensado para personas de movilidad reducida, es decir, se

utilizará dentro del hogar.

Restricciones:

El dispositivo no podrá pesar más de 200 gramos.

9. Requerimientos

1. Características del sistema

1.1. El sistema debe contar con una batería de alimentación que dure al menos 1 día

1.2. El sistema deberá contar con al menos 1 unidad de medición inercial (IMU) de 9 ejes

1.3. El sistema deberá contar con 1 módulo WiFi y 1 módulo GSM

1.4. El material que recubra el dispositivo debe ser resistente (tolerante a caídas)

1.5. El microcontrolador utilizado debe pertenecer a una gama de bajo consumo

2. Software necesario

2.1. El sistema debe contar con una aplicación WEB para visualizar los datos recolectados

por el dispositivo.

3. Control de versiones y documentación

3.1. Se utilizará GIT como herramienta de control de versiones.

3.2. Se utilizará Doxygen como herramienta para generar la documentación.

Ariel Lutenberg

Ariel Lutenberg

Ariel Lutenberg

Esto debería ser tambien un requerimiento

Ariel Lutenberg




Página 8 de 24

10. Entregables principales del proyecto

Prototipo del sistema

Manual de uso

Informe final

Presentación Power Point

Instaladores de software (en caso de ser necesario)

11. Desglose del trabajo en tareas

1. Búsqueda de material bibliográfico

1.1. Buscar hoja de datos de todos los componentes

1.2. Estudiar cómo funciona cada uno de los componentes

2. Elección de hardware a utilizar

2.1. Elegir el microcontrolador a utilizar.

2.2. Elegir en función de lo estudiado qué dispositivos van a utilizarse en el proyecto

2.3. Elección de batería a utilizar

3. Implementación de los drivers para los dispositivos elegidos

3.1. Implementar el driver del acelerómetro

3.2. Implementar los drivers de los módulos de comunicación

4. Implementar el sistema

4.1. Desarrollar el código utilizando los drivers ya creados

4.2. Desarrollar el programa de interfaz con el usuario

5. Diseñar un PCB para integrar todos los componentes

6. Testing

6.1. Testear el correcto funcionamiento del dispositivo

Ariel Lutenberg




Página 9 de 24

6.2. Testear el correcto funcionamiento de la aplicación

6.3. Testear el sistema en conjunto

7. Presentación del trabajo

7.1. Presentación del informe de avance

7.2. Presentación de la memoria escrita

7.3. Presentación pública del trabajo

12. Análisis de factibilidad

Actualmente existen tanto en el mercado como en el ámbito académico dispositivos que detectan

caídas basándose en la aceleración del cuerpo. Estos dispositivos de colocan en alguna parte del

cuerpo (pecho, cintura, cabeza, etc.) y mediante un acelerómetro son capaces de detectar (en gran

medida) si la persona sufrió una caída. Mencionado esto, se puede afirmar que es factible realizar

este proyecto con respecto al apartado técnico.

En lo que respecta a la factibilidad económica-financiera, el producto no presentara egresos elevados

debido a que (como ya se mencionó) tendrá como objetivo principal mantener su costo al mínimo

posible. Esto permitirá que el dispositivo tenga un gran impacto en el mercado, sobretodo en

Argentina donde los dispositivos importados no están al alcance de todos los ciudadanos.

Ariel Lutenberg




Página 10 de 24

13. Diagrama de ActivityOnNode

Las unidades de tiempo están expresadas en días

Ariel Lutenberg

Ariel Lutenberg

Mejor si podes hacer que el fondo quede en blanco o transparente.




Página 11 de 24

14. Diagrama de Gantt

15. Matriz de uso de recursos de materiales

Código WBS

Nombre de la tarea Recursos requeridos (horas)

Programador Notebook CIAA

Acelerómetro Mod.

Comunicación

1.1 Buscar hoja de datos de los

componentes

8 8

1.2 Estudiar cómo funciona cada

componente

60 60

2.1 Elegir el microcontrolador a

utilizar

20

2.2 Elegir qué batería se utilizará 20

2.3 Elegir qué dispositivo se

utilizarán

8

Ariel Lutenberg




Página 12 de 24

3.1 Implementar el driver del

acelerómetro

60 60 60 60

3.2 Implementar los drivers de los

módulos de comunicación

80 80 50 50

4.1 Desarrollar el código principal 80 80 40 40 40

4.2 Desarrollar el programa de

interfaz con el usuario

80 80

5 Diseñar un PCB para integrar

todos los componentes

40 40

6.1 Testear el correcto

funcionamiento del dispositivo

30 30 40 40 40

6.2 Testear el correcto

funcionamiento de la aplicación

30 30 40 40 40

6.3 Testear el sistema en conjunto 40 40 40 40 40

7.1 Presentación del informe de

avance

20 20

7.2 Presentación de la memoria

escrita

40 40

7.3 Presentación pública del trabajo 1 1 1 1 1

Total de horas 617 569 271 221 211

Ariel Lutenberg




Página 13 de 24

16. Presupuesto detallado del proyecto El proyecto tendrá un costo total aproximado de $73.910 ARS. A continuación se presenta el desglose

del costo.

Componentes

o Microcontrolador - $250

o Acelerómetro - $40

o Módulos de comunicación - $300

o Batería - $350

o LEDs - $10

o Pulsadores - $50

Materiales

o Placa FR2 - $10

o Acrílico contenedor - $100

Recursos Humanos

o Hora/hombre - 600 x $120 = $72000

Costos indirectos

o Viaje La Plata – Buenos Aires- $800

Ariel Lutenberg




Página 14 de 24

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

Matías Dell’Oso

Responsable

Laura Lanzarini Impulsor

Pablo Ridolfi Colaborador

1.1 Buscar hoja de datos de los componentes P

1.2 Estudiar cómo funciona cada componente P

2.1 Elegir el microcontrolador a utilizar P I A

2.2 Elegir qué batería se utilizará P I A

2.3 Elegir qué dispositivo se utilizarán P I A

3.1 Implementar el driver del acelerómetro P I A, C

3.2 Implementar los drivers de los módulos de

comunicación

p I A, C

4.1 Desarrollar el código principal P A C

4.2 Desarrollar el programa de interfaz con el usuario P A I

5 Diseñar un PCB para integrar todos los

componentes

P A, C

6.1 Testear el correcto funcionamiento del

dispositivo

P A I

Ariel Lutenberg




Página 15 de 24

6.2 Testear el correcto funcionamiento de la

aplicación

P A I

6.3 Testear el sistema en conjunto P I A

7.1 Presentación del informe de avance P I A

7.2 Presentación de la memoria escrita P I A

7.2 Presentación pública del trabajo P I A

Referencias: P = Responsabilidad Primaria

S = Responsabilidad Secundaria A = Aprobación I = Informado C = Consultado

18. Gestión de riesgos

Riesgo 1: mala planificación de los tiempos.

Severidad (S): 10. Si la planificación fue mala, no se cumplirán los tiempos de entrega

preestablecidos y los objetivos del proyecto no serán cumplidos.

Probabilidad de ocurrencia (O): 2. Para planificar el proyecto de manera correcta se realizará

un informe previo utilizando herramientas adecuadas para realizar una planificación exitosa.

Tasa de no detección (D): 3. Aunque sea poco probable, pueden surgir imprevistos no

planeados que alteren los planes iniciales.

Riesgo 2: no cumplir las expectativas del jurado

Severidad (S): 10. Si el proyecto no cumple con las expectativas del jurado se deberá tomar la

decisión de agregar contenido al mismo o cambiar de proyecto. Cualquiera de las dos

opciones implica una pérdida de tiempo y una reingeniería de todas las etapas realizadas.

Ariel Lutenberg

Ariel Lutenberg

a)




Página 16 de 24

Probabilidad de ocurrencia (O): 3. Es difícil que el jurado no acepte la propuesta pero no

imposible. Ellos tienen la última palabra.

Tasa de no detección (D): 2. El proyecto tiene el aval de personas de conocimiento sobre el

tema lo que aumenta la probabilidad de que sea aceptado.

Riesgo 3: dificultades para conseguir los componentes

Severidad (S): 9. No contar con los componentes en el momento indicado generaría un

retraso general de todo el proyecto debido a que el hardware es necesario en las etapas

tempranas.

Probabilidad de ocurrencia (O): 6. Se intentará trabajar con productos que sean de fácil

adquisición en Argentina. Además, ya se poseen la mayoría de los dispositivos.

Tasa de no detección (D): 1. Debido a las políticas de estado, ya se sabe que se debe planear

con suficiente antelación la compra de productos importados.

Riesgo 4: falla de los componentes

Severidad (S): 10. Si se produce la falla de un componente importado, el proyecto sufrirá un

retraso intolerable debido a que se perderán meses esperando la llegada del dispositivo.

Probabilidad de ocurrencia (O): 4. Si bien los componentes pueden fallar, generalmente esto

no ocurre si se utilizan de manera correcta.

Tasa de no detección (D): 5. Es muy difícil prever que un componente fallará.

Riesgo 5: pérdida de prioridades del proyecto frente a compromisos laborales

Severidad (S): 10. No podrá cumplirse la fecha de entrega preestablecida.

Probabilidad de ocurrencia (O): 8. El responsable del proyecto tiene una jornada laboral de

10 horas diarias.

Tasa de no detección (D): 7. No se sabe si surgirán trabajos que no puedan ser postergados.

Ariel Lutenberg

Ariel Lutenberg




Página 17 de 24

c) Tabla de gestión de riesgos:

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

1 10 2 3 60 10 2 3 60

2 10 3 2 60 10 3 2 60

3 9 6 1 54 9 6 1 54

4 10 4 5 200 10 4 1 40

5 10 8 7 560 10 8 1 80

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

Severidad (S): 10. Si se produce la falla de un componente importado, el proyecto sufrirá un

retraso intolerable debido a que se perderán meses esperando la llegada del dispositivo.

Probabilidad de ocurrencia (O): 4. Si bien los componentes pueden fallar, generalmente esto

no ocurre si se utilizan de manera correcta.

Tasa de no detección (D): 1. Se comprarán 2 unidades de cada componente. Riesgo 5: pérdida de prioridades del proyecto frente a compromisos laborales

Severidad (S): 10. No podrá cumplirse la fecha de entrega preestablecida.

Probabilidad de ocurrencia (O): 8. El responsable del proyecto tiene una jornada laboral de

10 horas diarias.

Tasa de no detección (D): 1. Debido a que uno de los trabajos del responsable es en una institución académica, se utilizaran esas horas laborales para la realización del proyecto.

Ariel Lutenberg

b)

Ariel Lutenberg

c)

Ariel Lutenberg




Página 18 de 24

19. Gestión de la calidad Requerimiento 1: el sistema debe contar con una batería de alimentación que dure al menos 1 día

Calidad: se satisface que el sistema cuenta con una batería de alimentación que dure al menos 1 día.

Grado de calidad: es todavía mejor si sólo es necesario recargarla 1 vez a la semana.

Costos de conformidad: costos asociados a la compra de la batería de dichas características.

Costos de no conformidad: el dispositivo puede apagarse dejando de cumplir su función.

Responsable de la verificación: Matías Dell’Oso

Verificación: determinar cuánto consume el sistema y cuánta energía puede entregar la fuente y realizar los cálculos para determinar si dicha batería cumple los requisitos.

Responsable de la validación: Matías Dell’Oso

Validación: se dejará el dispositivo prendido y se observará en cuánto tiempo se apaga. Requerimiento 2: el sistema deberá contar con al menos 1 unidad de medición inercial (IMU) de 9 ejes

Calidad: se satisface que el sistema cuanta con 1 IMU de 9 ejes.

Grado de calidad: es todavía mejor si se combina con otro IMU ubicado en otra parte del cuerpo. Costos de conformidad: costos asociados a la compra de la IMU.

Costos de no conformidad: el dispositivo no cumplirá su cometido.


Verificación: se corroborará en la hoja de datos que el componente sea el adecuado.


Validación: se creará un programa para testear su correcto funcionamiento. Requerimiento 3: el sistema deberá contar con 1 módulo WiFi y 1 módulo GSM

Calidad: se satisface que el sistema cuanta con 1 módulo WiFi y 1 módulo GSM

Grado de calidad: es todavía mejor si el sistema cuenta también con un módulo bluetooth para generar redundancia.

Costos de conformidad: lograr integrar los 2 módulos en el dispositivo y programar sus respectivos drivers.

Costos de no conformidad: el dispositivo no podrá informar los valores sensados.


Verificación: se realizará un diseño preliminar del dispositivo.


Validación: se realizarán pruebas de comunicación con el dispositivo. Requerimiento 4: el material que recubra el dispositivo debe ser resistente (tolerante a caídas)

Calidad: se satisface que el material que recubre el dispositivo sea resistente a caídas.

Grado de calidad: es aún mejor si el material es liviano y barato.

Costos de conformidad: se deben probar diferentes materiales para dar con el correcto.

Costos de no conformidad: el dispositivo puede romperse al ocurrir una caída.

Ariel Lutenberg




Página 19 de 24

Responsable de la verificación: Pablo Ridolfi

Verificación: se consultará a un experto en materiales.


Validación: se arrojará el dispositivo desde 1 metro de altura y se observará si tolera la caída. Requerimiento 5: el microcontrolador utilizado debe pertenecer a una gama de bajo consumo.

Calidad: se satisface que el microcontrolador utilizado sea de una gama de bajo consumo.

Grado de calidad: es todavía mejor si el microcontroaldor es de la familia Cortex-M0 o Cortex-M0+

Costos de conformidad: conseguir en el mercado local un microcontrolador con dichas características

Costos de no conformidad: la batería del dispositivo se agotará antes de lo esperado


Verificación: corroborar en la hoja de datos del microcontrolador que su consumo no sea elevado


Validación: se utilizarán elementos de laboratorio como testers y osciloscopios para determinar que el consumo sea el correcto.

Requerimiento 6: el sistema debe contar con una aplicación desktop o WEB para visualizar los datos recolectados por el dispositivo.

Calidad: se satisface que el sistema cuente con una aplicación para visualizar los datos recolectados.

Grado de calidad: es todavía mejor si se realizan tanto la aplicación desktop como la WEB.

Costos de conformidad: tiempo dedicado al desarrollo de la aplicación.

Costos de no conformidad: no habrá forma de tener un registro de los datos sensados.


Verificación: se diseñará un plan de trabajo previo que contemple el desarrollo de esta aplicación.


Validación: se realizarán pruebas de caja blanca y caja negra sobre la aplicación. Requerimiento 7: se utilizará GIT como herramienta de control de versiones.

Calidad: se satisface que se utilice GIT como herramienta de control de versiones.

Grado de calidad: es todavía mejor si se usa otra herramienta de versionado para tener redundancia de los datos.

Costos de conformidad: aprender a utilizar la herramienta.

Costos de no conformidad: puede perderse todo el trabajo realizado

Responsable de la verificación: Pablo Ridolfi

Verificación: se estipulará que antes de comenzar cualquier tarea se iniciará el programa de versionado.

Responsable de la validación: Pablo Ridolfi

Validación: se constatará que se realicen versiones periódicamente

Ariel Lutenberg




Página 20 de 24

Requerimiento 8: se utilizará Doxygen como herramienta para generar la documentación.

Calidad: se satisface que se utilice Doxygen como herramienta para generar documentación

Grado de calidad: es todavía mejor si se redactan en word informes de avances mensuales.

Costos de conformidad: aprender a utilizar la herramienta.

Costos de no conformidad: no se tendrá documentación del proyecto.

Responsable de la verificación: Matías Dell'Oso

Verificación: se estipulará que antes de comenzar cualquier tarea se iniciará el programa de documentación.

Responsable de la validación: Matías Dell'Oso

Validación: se constatará periódicamente que haya documentación sobre lo ya codificado.

20. Comunicación del proyecto El plan de comunicación del proyecto es el siguiente:

PLAN DE COMUNICACIÓN DEL PROYECTO

¿Qué comunicar?

Audiencia Propósito Frecuencia Método de comunicac.

Responsable

Análisis de los dispositivos

Pablo Ridolfi

Elegir correctamente los

dispositivos a utilizar

Antes de comenzar el proyecto

Correo electrónico

Matías Dell'Oso

Avance en el desarrollo de

los drivers

Pablo Ridolfi

Asegurar que el camino que está

tomando el proyecto es el

correcto

Cada 15 días Correo electrónico

Matías Dell'Oso

Finalización del informe de

avance

Pablo Ridolfi

Informar avance 1 única vez, cuando haya que presentar el informe al jurado

Correo electrónico

Matías Dell'Oso

Inicio del diseño de PCB

Pablo Ridolfi

Obtener sugerencias para un buen diseño

1 única vez, a la hora de diseñar el

integrado

Reunión personal

Matías Dell'Oso

Finalización de la codificación e inicio de testing

Pablo Ridolfi, Laura

Lanzarini

Informar avance Al finalizar la codificación

Correo electrónico

Matías Dell'Oso

Ariel Lutenberg

Ariel Lutenberg




Página 21 de 24

Finalización del proyecto

Pablo Ridolfi

Determinar que los objetivos

fueron cumplidos

Al finalizar la etapa de testing

Reunión personal

Matías Dell'Oso

21. Gestión de Compras

El criterio que se seguirá para elegir proveedores dependerá de cada material en particular:

Microcontrolador: se elegirá un fabricante con el cual el desarrollador del dispositivo esté

familiarizado. A su vez, el proveedor deberá tener cede en Argentina y contar con stock

disponible para entrega inmediata.

Sensores y módulos de comunicación: los dispositivos ya fueron encargados con antelación a un

proveedor extranjero. El criterio seguido a la hora de elegirlo fue el bajo costo.

Batería: la batería deberá adquirirse de un proveedor local al igual que el microcontrolador. Se

busca principalmente un bajo costo.

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.

1.1. Buscar hoja de datos de todos los

componentes

Cantidad de hojas de

datos utilizadas

Una única vez Matías Dell'Oso Pablo Ridolfi Correo Electrónico

1.2. Estudiar cómo

funciona cada uno de los

componentes

Componentes estudiados


2.1. Elegir el microcontrola

Cantidad de microcontro


Ariel Lutenberg




Página 22 de 24

dor a utilizar ladores estudiados

2.2. Elegir qué dispositivos

van a utilizarse en el proyecto

Módulos de comunicación estudiados


2.3. Elección de batería a

utilizar

Baterías investigadas


3.1. Implementar el driver del

acelerómetro

Número de drivers

implementados

Semanal Matías Dell'Oso Pablo Ridolfi Correo Electrónico

3.2. Implementar los drivers de los módulos

de comunicación

Número de drivers

implementados


4.1. Desarrollar el

código utilizando los

drivers ya creados

Porcentaje de la

aplicación que ya fue codificado


4.2. Desarrollar el programa de

interfaz con el usuario

Porcentaje de la

aplicación que ya fue codificado

Semanal Matías Dell'Oso Laura Lanzarini

Reunión

5.1. Diseño de PCB para

integrar todos los

componentes

Módulos ruteados

correctamente


6.1. Testear el Cantidad de Cada 2 Matías Dell'Oso Pablo Ridolfi Reunión




Página 23 de 24

correcto funcionamien

to del dispositivo

pruebas de caja negra y caja blanca realizadas

semanas

6.2. Testear el correcto

funcionamiento de la

aplicación

Cantidad de pruebas de caja negra y caja blanca realizadas

Cada 2 semanas

Matías Dell'Oso Pablo Ridolfi Correo Electrónico

6.3. Testear el sistema en conjunto

Cantidad de pruebas de caja negra y caja blanca realizadas

Cada 2 semanas

Matías Dell'Oso Pablo Ridolfi, Laura

Lanzarini

Reunión

7.1. Presentación del informe de avance

Cantidad de funcionalida

des descriptas


7.2. Presentación

de la memoria escrita


des descriptas

Mensual Matías Dell'Oso Pablo Ridolfi Reunión

7.3. Presentación

pública del trabajo


des descriptas

Una única vez Matías Dell'Oso Pablo Ridolfi, Laura

Lanzarini

Correo Electrónico

23. Procesos de cierre

Una vez finalizado el proyecto se realizarán las siguientes actividades:

Análisis del grado de cumplimiento de objetivos: se analizarán los objetivos planteados inicialmente verificando que se hayan cumplido cada uno de ellos.

Identificación de las técnicas y procedimientos útiles e inútiles que se utilizaron: se analizará el WBS planteado inicialmente y se verificará que cada una de las tareas se haya cumplido en tiempo y forma. Si alguna tarea se terminó más rápido se podrá decir que el procedimiento

Ariel Lutenberg




Página 24 de 24

utilizado fue muy útil. A su vez, si una tarea tardó más de lo planeado será porque el procedimiento seguido no fue el adecuado.

Análisis de si se respetaron las versiones originales de cronogramas, recursos y riesgos: organizar una reunión en la cual se analice el documento de planificación original detallando qué parte del mismo fue respetada y cual parte no lo fue.

Memoria de los problemas que surgieron y cómo se solucionaron: se organizará una reunión con todos los miembros del equipo y se nombraran los problemas que surgieron a lo largo del proyecto. El encargado del proyecto será el encargado de documentar qué solución se le dio a cada problema.

Acto de agradecimiento a todos los interesados, y en especial al equipo de trabajo y colaboradores: se realizará un almuerzo con todos los integrantes del equipo a modo de agradecimiento por su participación y dedicación.

Ariel Lutenberg

prototipo funcional de un sistema de detección de...

Documents