Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
Plataforma abierta para dispositivos vestibles (wearables)
Autor
Esp. Ing. Rodrigo Alejandro Tirapegui
Director del trabajo
Mg. Ing. Diego Javier Brengi (INTI)
Jurado propuesto para el trabajo
- Mg. Ing. Agustin Bassi (UNLZ) - Dr. Ing. Emanuel Irrazabal (UNNE) - Mg. BioIng. Eduardo Filomena (UNER)
Este plan de trabajo ha sido realizado en el marco de la asignatura Gestión de la
Tecnología y la Innovación entre marzo y abril de 2019.
Página 1 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
Tabla de contenido
Registros de cambios 3
Acta de Constitución del Proyecto 4
Descripción técnica-conceptual del Proyecto a realizar 5
Identificación y análisis de los interesados 8
1. Propósito del proyecto 9
2. Alcance del proyecto 9
3. Supuestos del proyecto 9
4. Requerimientos 10
5. Entregables principales del proyecto 11
6. Desglose del trabajo en tareas 11
7. Diagrama de Activity On Node 13
8. Diagrama de Gantt 14
9. Matriz de uso de recursos de materiales 15
10. Presupuesto detallado del proyecto 17
11. Matriz de asignación de responsabilidades 18
12. Gestión de riesgos 19
13. Gestión de la calidad 21
14. Comunicación del proyecto 26
15. Gestión de Compras 27
16. Seguimiento y control 27
17. Procesos de cierre 30
Página 2 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
Registros de cambios
Revisión Detalle de los cambios realizados Fecha
1.0 Creación del documento 16/03/2019
2.0 Confección del documento
● Redacción Acta de Constitución del proyecto ● Redacción Descripción técnica-conceptual del
Proyecto ● Redacción Identificación y Análisis de los Interesados ● Redacción ítems 1 a 9
23/03/2019
3.0 Finalización en la confección del documento
● Redacción ítems 9 a 17
24/03/2019
3.1 ● Correcciones Acta de Constitución del proyecto 31/03/2019
3.2 ● Corrección imagenes Diagrama de Gantt 03/04/2019
Página 3 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
Acta de Constitución del Proyecto
Buenos Aires, 3 de marzo de 2017
Por medio de la presente se acuerda con el Sr. Rodrigo Alejandro Tirapegui que su Proyecto Final
de la Maestría en Sistemas Embebidos se titulará “Plataforma abierta para dispositivos vestibles
(wearables)”, consistirá esencialmente en el prototipo preliminar de un rastreador de actividad vestible
basado en una plataforma de hardware y código abierto diseñada por el Instituto Nacional de Tecnología
Industrial (INTI), y tendrá un presupuesto preliminar estimado de 600 hs de trabajo, con fecha de inicio
lunes 11 de marzo de 2019 y fecha de presentación pública a partir del lunes 16 de diciembre de 2019.
Se adjunta a esta acta la planificación inicial.
Ariel Lutenberg Diego Javier Brengi
Director de la MSE-FIUBA INTI Micro y nanotecnología
Diego Javier Brengi
Director del Trabajo Final
Agustín Bassi Emanuel Irrazabal
Jurado del Trabajo Final Jurado del Trabajo Final
Eduardo Filomena
Jurado del Trabajo Final
Página 4 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
Descripción técnica-conceptual del Proyecto a realizar
Los dispositivos vestibles (wearables) son pequeños módulos electrónicos que se incorporan a las prendas
o accesorios para cumplir alguna función en las áreas de entretenimiento, bienestar y deporte, pero que
también pueden aplicarse en ámbitos laborales, militares, de seguridad y vigilancia, y muchos otros.
El desarrollo de estos dispositivos se incrementó a medida que los componentes electrónicos se hicieron
más pequeños, y las tecnologías de visualización y comunicación avanzaron a lo largo de los años.
Por ejemplo, a mediados de los años setenta, la mayoría de los dispositivos electrónicos portátiles tenían
una correa que colgaba alrededor del cuello; mientras que hacia finales de la década, las cámaras, las
radios e incluso el Walkman se habían vuelto más pequeños, más baratos y personales, creando las bases 1
para la industria de la electrónica de consumo.
En la actualidad, ésta tecnología portátil es a menudo utilizada para registrar variables corporales
relacionadas con la actividad física, dado que, al estar en contacto cercano con el cuerpo, puede recopilar
datos fácilmente. Estas funciones se agrupan en una sola unidad denominada rastreador de actividad , 2
que incluye el monitoreo de los siguientes parámetros:
● Ritmo cardíaco
● Calorías quemadas
● Cantidad de pasos caminados
● Presión sanguínea
● Tiempo dedicado a realizar actividad física
A nivel mundial, el crecimiento del mercado de los rastreadores de actividad se ve impulsado por el
aumento en la tendencia de la tecnología portátil entre los jóvenes, por la generalización de una mayor
conciencia sobre salud entre los consumidores, y por la facilidad de acceso a las funciones de los
smartphones y su compatibilidad con una amplia gama de sistemas operativos.
En base a la descripción presentada, el objetivo del trabajo es desarrollar el prototipo operativo de un rastreador de actividad, que permita validar y demostrar el uso de la plataforma de hardware denominada PlatC, que fue diseñada por el Instituto Nacional de Tecnología Industrial (INTI).
Al momento de la escritura de este documento, en el INTI se han desarrollado dos plataformas abiertas para aplicación en vestibles:
● Spora, cuyo diseño está publicado en Github. ● PlatC, cuyo diseño aún no se ha publicado abiertamente, a la espera de tener avanzadas las
rutinas de firmware de prueba y alguna aplicación demostrativa.
La plataforma de hardware PlatC ha sido verificada en sus primeras etapas de encendido y programación, y queda por probar los distintos periféricos que la integran.
1 https://es.wikipedia.org/wiki/Walkman 2 https://en.wikipedia.org/wiki/Activity_tracker
Página 5 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
En este sentido, se busca desarrollar un prototipo de rastreador de actividad con el cual se logre cubrir los siguientes aspectos, necesarios para su publicación en forma abierta:
● Brochure de la plataforma de hardware y mejora de la documentación. ● Rutinas de prueba básicas del hardware. ● Protocolo básico de comunicación. ● Aplicación básica demostrativa con algún tipo de interacción con un smartphone o tablet para
sistema operativo Android.
Con la publicación de la plataforma PlatC se busca promover la innovación para crear, diseñar y desarrollar soluciones electrónicas en vestibles, impulsando de ese modo el desarrollo tecnológico nacional y dándole visibilidad positiva a la electrónica argentina.
El hardware de PlatC cuenta con los siguiente periféricos:
● Un módulo Bluetooth BGM113 de Silicon Labs. ● Un acelerómetro MPU 9250. ● Un pulsador. ● Un LED RGB. ● Un parlante. ● Un conector de expansión que permite agregar sensores, actuadores o un display. ● Un microcontrolador ARM Cortex M0+ SAMD21 de Atmel/Microchip.
En las figuras 1 y 2 se muestran el prototipo fabricado y el diagrama en bloques de la plataforma de hardware PlatC.
Figura 1. Prototipo de hardware plataforma PlatC.
Página 6 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
Figura 2. Diagrama en bloques de la plataforma de hardware PlatC.
El proyecto abarca la implementación del firmware del microcontrolador SAMD21 y una aplicación demostrativa en un smartphone que será utilizada para realizar ejercicio físico.
El firmware será implementado en base al framework denominado Reactive framework for hierarchical state machines (RKH ), el cual provee la infraestructura necesaria para construir embedded software bajo 3
el paradigma de la programación dirigida por eventos, basado en la ejecución simultánea de máquinas de estado del tipo statecharts de acuerdo con la especificación UML 2.x . 4 5
La aplicación demostrativa implementará un protocolo de comunicación (sobre Bluetooth), con el cual será posible contar la cantidad de pasos caminados, ó el número de repeticiones de abdominales o flexiones generados por PlatC, e informarlos en el momento (mediante comandos de voz, como si fuera un entrenador).
En la figura 3 se muestra la arquitectura en capas del framework RKH.
3 https://www.vortexmakes.com/que-es/ 4 http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf 5 http://agilemodeling.com/essays/umlDiagrams.htm
Página 7 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
Figura 3. Arquitectura en capas del framework RKH.
Identificación y análisis de los interesados
Rol Nombre y Apellido Departamento Puesto
Cliente Mg. Ing. Diego Javier
Brengi
INTI Micro y
nanotecnología
Coordinador en el
área de desarrollos
electrónicos
Impulsor Mg. Ing. Diego Javier
Brengi
INTI Micro y
nanotecnología
Coordinador en el
área de desarrollos
electrónicos
Responsable Esp. Ing. Rodrigo
Alejandro Tirapegui
- Estudiante MSE
Colaboradores Ing. Francisco Gargiulo - Desarrollador
Orientadores Mg. Ing. Diego Javier
Brengi
INTI Micro y
nanotecnología
Coordinador en el
área de desarrollos
electrónicos
Usuario Final Instituciones, empresas o
entusiastas que busquen
desarrollar aplicaciones
en vestibles
- -
Página 8 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
1. Propósito del proyecto
El propósito de este proyecto es desarrollar el prototipo operativo de un rastreador de actividad vestible
(activity tracker), que permita demostrar el uso de la plataforma de hardware abierta denominada PlatC,
diseñada por el Instituto Nacional de Tecnología Industrial (INTI). El dispositivo le permitirá al usuario
visualizar sus estadísticas diarias de salud y estado físico, descubrir su progreso, y recibir asesoramiento
personalizado y recordatorios de sus objetivos a través de una aplicación en su smartphone o tablet.
2. Alcance del proyecto
El proyecto incluye el diseño e implementación del firmware para el prototipo de hardware de la plataforma PlatC, el diseño e implementación del software de una aplicación celular para sistema operativo Android, confección de la documentación de la plataforma de hardware y la demostración en condiciones de laboratorio.
Específicamente se cubrirán los siguiente aspectos:
● Adquisición de datos de aceleración, giroscopio y sensor de temperatura ambiente del dispositivo vestible.
● Procesamiento de los datos recogidos para determinar cantidad de pasos caminados/repeticiones de abdominales realizadas.
● Diseño e implementación de un protocolo de comunicación a través de la interfaz Bluetooth. ● Indicación del estado de conexión del dispositivo vestible. ● Visualización de los datos adquiridos y parámetros de configuración en una aplicación celular. ● Realización de tests y documentación detallados.
El proyecto no incluye el diseño y fabricación de la carcasa plástica para el dispositivo vestible, ni tampoco el manejo de más de un dispositivo en simultáneo.
3. Supuestos del proyecto
Para el desarrollo del presente proyecto se supone que:
● Los gastos en componentes e insumos serán cubiertos por INTI dentro de las posibilidades administrativas de la caja chica.
● Disponibilidad de los laboratorios e instrumental de INTI para cubrir la tarea de desarrollo. ● Disponibilidad de un prototipo de hardware funcional de PlatC desde la fecha de inicio del
proyecto. ● Disponibilidad de los desarrolladores del hardware para posibles consultas sobre el mismo.
Página 9 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
4. Requerimientos
Los requerimientos del sistema se mencionan a continuación, diferenciándolos según si se trata de requerimientos funcionales o no funcionales.
Además, se indica al lado de cada requerimiento su prioridad, siendo [1] muy prioritario y [3] poco prioritario.
Requerimientos Funcionales:
1. Módulo PlatC
1.1 Detectará movimientos con aceleración superiores a MOTION_THR. [1]
1.2 Cuando se detecte una aceleración superior a MOTION_THR, transmitirá inmediatamente un paquete PlatCData hacia PlatCApk. [1]
1.3 Cuando se detecte una aceleración superior a MOTION_THR, encenderá y mantendrá el indicador MOTION_LED durante MOTION_DET_TIME. [1]
1.4 Se vinculará con PlatCApk mediante un enlace BLE. [1]
1.5 Cuando se encuentre vinculado con PlatCApk, encenderá el indicador BLE_LED. [1]
1.6 Cuando se encuentre en proceso de carga de baterías, encenderá el indicador BATTERY_LED. [1]
1.7 Cuando no exista vínculo entre PlatCApk y no se esté en curso una indicación de detección de movimiento mediante MOTION_LED, el sistema encenderá en secuencia los indicadores MOTION_LED, BLE_LED, y BATTERY_LED cada KEEPALIVE_TIME. [1]
1.8 Recibirá el paquete PlatCApkSettings con configuraciones desde el PlatCApk. [1]
1.9 Ajustará el umbral MOTION_THR de acuerdo al paquete de configuración PlatCApkSettings enviado por PlatCApk. [1]
1.10 Cuando inicie será descubrible por PlatCApk. [1]
1.11 Cuando permanezca sin establecer vínculo con PlatCApk durante más de DISCONNECTED_TIMEOUT dejará de ser descubrible. [2]
1.12 Cuando esté vinculado a PlatCApk y se presione PUSH_BUTTON durante más de SHORT2LONG_BUTT_TIME se desvinculará y permanecerá descubrible. [1]
1.13 Cuando esté vinculado a PlatCApk y se presione PUSH_BUTTON durante menos de SHORT2LONG_BUTT_TIME transmitirá un paquete PlatCData a PlatCApk. [2]
1.14 Cuando no sea descubrible y se presione PUSH_BUTTON durante más de SHORT2LONG_BUTT_TIME será descubrible inmediatamente. [1]
2. Módulo de visualización
2.1 Deberá ser una aplicación para sistema operativo Android. [2]
2.1 Deberá mostrar los parámetros de configuración y datos adquiridos por el módulo PlatC. [1]
Página 10 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
2.3 Deberá describir de forma hablada los datos adquiridos por el módulo PlatC. [1]
2.2 Deberá permitir la modificación de los parámetros de configuración del módulo PlatC. [1]
Requerimientos No Funcionales:
1. Módulo PlatC
1.1 Las configuraciones de PlatCSettings serán almacenadas en memoria no volátil. [1]
1.2 Filtrará el rebote del pulsador PUSH_BUTTON. [1]
1.3 MOTION_DET_TIME será configurable en tiempo de compilación. [3]
1.4 Mantendrá el tiempo de operación en memoria no persistente. [3]
1.5 El firmware del módulo debe diseñarse minimizando el consumo. [1]
1.6 Debe cumplir con la recomendación IEC 801 de “Compatibilidad electromagnética para medición de procesos industriales y equipos de control (por extensión)”. [1]
Los requerimientos listados previamente surgen del análisis de los requerimientos establecidos por INTI durante el desarrollo es la plataforma de hardware abierta Spora.
5. Entregables principales del proyecto
Los entregables del proyecto son:
● Prototipo del módulo PlatC. ● Manual de uso de la aplicación demostrativa. ● Diagrama esquemático del hardware. ● Código fuente del software. ● Informe de avance. ● Memoria del proyecto. ● Presentación ante el jurado.
6. Desglose del trabajo en tareas
Se enumeran a continuación las tareas que componen el proyecto:
1. Gestión de Proyecto 115 hs
1.1 Planificación y presentación del Trabajo Final 15 hs
1.2 Confección del Manual de Usuario 10 hs
1.3 Confección del Informe de Avance 10 hs
1.4 Confección de la Memoria del Trabajo 60 hs
Página 11 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
1.5 Preparación de la Presentación Final 20 hs
2. Diseño e Implementación de Firmware 255 hs
2.1 Análisis e investigación del framework RKH 25 hs
2.2 Análisis e investigación del stack Bluetooth Low Energy (BLE) 20 hs
2.3 Configuración del entorno/herramientas de desarrollo 15 hs
2.4 Definición e implementación de máquinas de estados e interfaces 50 hs
2.5 Definición e implementación del protocolo de comunicación BLE 40 hs
2.6 Implementación de drivers para adquisición de datos de los sensores 60 hs
2.7 Implementación de drivers para el manejo del transceptor BLE 30 hs
2.8 Documentación del firmware 15 hs
3. Diseño e Implementación de Aplicación de Visualización y Configuración 135 hs
3.1 Análisis e investigación del SDK Android 15 hs
3.2 Análisis e investigación de las APIs TextToSpeech 25 hs
3.3 Configuración del entorno/herramientas de desarrollo 20 hs
3.4 Implementación de funcionalidades e interfaces 60 hs
3.5 Documentación del software 15 hs
4. Verificación y Validación 105 hs
4.1 Implementación y ejecución de rutinas de prueba del hardware 15 hs
4.2 Implementación y ejecución de pruebas unitarias del firmware 30 hs
4.3 Implementación y ejecución de pruebas unitarias del software 30 hs
4.4 Implementación y ejecución de pruebas de integración del sistema 15 hs
4.5 Documentación del proceso de verificación y validación 15 hs
Cantidad total de horas 610 hs
Página 12 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
7. Diagrama de Activity On Node
Las tareas se subdividen de la siguiente manera:
1. Gestión de proyectos
2. Diseño e implementación de firmware
3. Diseño e implementación de Aplicación de Visualización y Configuración
4. Verificación y validación
Figura 4. Diagrama de Activity On Node (AON).
Página 13 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
8. Diagrama de Gantt
Figura 5. Tabla de Gantt.
Página 14 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
Figura 6. Diagrama de barras de Gantt.
Se observa que la fecha de finalización del proyecto coincide con la indicada en el Acta Constitutiva.
9. Matriz de uso de recursos de materiales La ejecución del proyecto requerirá de los siguientes recursos materiales:
1. PC 2. Módulo PlatC 3. Smartphone con sistema Android 4. Instrumental de laboratorio
La siguiente tabla muestra la matriz de recursos materiales, con la cantidad de horas que cada tarea demandará de cada uno de ellos. Algunas tareas no utilizan ciertas recursos materiales, mientras que otras utilizan más de uno.
Página 15 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
Código WBS
Nombre de la tarea
Recursos requeridos (horas)
PC PlatC Smartphone
Instrumental
1.1 Planificación y presentación del Trabajo Final 15hs
1.2 Confección del Manual de Usuario 10hs
1.3 Confección del Informe de Avance 10hs
1.4 Confección de la Memoria del Trabajo 60hs
1.5 Preparación de la Presentación Final 20hs
2.1 Análisis e investigación del framework RKH 15hs 10hs
2.2 Análisis e investigación del stack BLE 10hs 10hs
2.3 Configuración del entorno/herramientas de
desarrollo
10hs 5hs
2.4 Definición e implementación de máquinas de
estados e interfaces
40hs 10hs
2.5 Definición e implementación del protocolo de
comunicación BLE
30hs 10hs
2.6 Implementación de drivers para adquisición de
datos de los sensores
50hs 10hs
2.7 Implementación de drivers para el manejo del
transceptor BLE
30hs 10hs
2.8 Documentación del firmware 15hs
3.1 Análisis e investigación del SDK Android 10hs 5hs
3.2 Análisis e investigación de las APIs TextToSpeech 15hs 10hs
3.3 Configuración del entorno/herramientas de
desarrollo
15hs 5hs
3.4 Implementación de funcionalidades e interfaces 50hs 10hs
3.5 Documentación del software 15hs
Página 16 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
4.1 Implementación y ejecución de rutinas de
prueba del hardware
5hs 5hs 5hs
4.2 Implementación y ejecución de pruebas
unitarias del firmware
20hs 5hs 5hs
4.3 Implementación y ejecución de pruebas
unitarias del software
20hs 10hs
4.4 Implementación y ejecución de pruebas de
integración del sistema
5hs 5hs 5hs
4.5 Documentación del proceso de verificación y
validación
15hs
10. Presupuesto detallado del proyecto
Categoría Descripción Cantidad Costo unitario
Subtotal
Costos Directos
Desarrollo 610 hs $ 350 / hs $ 213.500
Módulo Bluetooth BGM113 3 $ 442 $ 1326
Acelerómetro MPU 9250 3 $ 300 $ 900
Buzzer PB-1221P 3 $ 90 $ 270
MCU ATSAMD21E17A-AUT 3 $100 $ 300
IC cargador de batería MCP73832T 3 $ 25 $ 75
LED RGB 3 $ 33 $ 99
Pulsador 3 $ 10 $ 30
Conector de expansión 3 $ 45 $ 135
Fabricación y montaje PCB 3 $ 2250 $ 6750
Subtotal $ 223.385
Costos Indirectos Aproximadamente 30% de los costos directos
- - $ 67.015
Total costos del proyecto $ 290.400
Página 17 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
11. Matriz de asignación de responsabilidades
Código WBS Nombre de la tarea
Listar todos los nombres y apellidos y el rol definidos en el proyecto
Rodrigo Tirapegui Responsable
Diego Brengi
Impulsor
Francisco Gargiulo
Colaborador Cliente
1.1 Planificación y presentación del
Trabajo Final
P I - I
1.2 Confección del Manual de Usuario P A - I
1.3 Confección del Informe de Avance P A - I
1.4 Confección de la Memoria del Trabajo P A - -
1.5 Preparación de la Presentación Final P A - -
2.1 Análisis e investigación del framework
RKH
P - C -
2.2 Análisis e investigación del stack BLE P - C -
2.3 Configuración del
entorno/herramientas de desarrollo
P - C -
2.4 Definición e implementación de
máquinas de estados e interfaces
P I - -
2.5 Definición e implementación del
protocolo de comunicación BLE
P I - -
2.6 Implementación de drivers para
adquisición de datos de los sensores
P I - -
2.7 Implementación de drivers para el
manejo del transceptor BLE
P I - -
2.8 Documentación del firmware P I - -
3.1 Análisis e investigación del SDK
Android
P - C -
3.2 Análisis e investigación de las APIs
TextToSpeech
P - C -
Página 18 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
3.3 Configuración del
entorno/herramientas de desarrollo
P - C -
3.4 Implementación de funcionalidades e
interfaces
P I - -
3.5 Documentación del software P I - -
4.1 Implementación y ejecución de rutinas
de prueba del hardware
P A C I
4.2 Implementación y ejecución de
pruebas unitarias del firmware
P A C I
4.3 Implementación y ejecución de
pruebas unitarias del software
P A C I
4.4 Implementación y ejecución de
pruebas de integración del sistema
P A - I
4.5 Documentación del proceso de
verificación y validación
P A - I
Referencias: P = Responsabilidad Primaria
S = Responsabilidad Secundaria A = Aprobación I = Informado C = Consultado
Página 19 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
12. Gestión de riesgos Se identifican a continuación los riesgos asociados a la realización del proyecto y se estiman sus
consecuencias de la siguiente manera:
● Severidad (S): mientras más severo más alto es el número. Rango: 1 a 10.
● Probabilidad de ocurrencia (O): mientras más probable, más alto es el número. Rango: 1 a 10.
Riesgo 1 Cancelación del proyecto por parte de INTI.
Severidad 10 Porque produce la no aprobación de la Maestría en Sistemas Embebidos.
Prob. de Ocurrencia 3 El coordinador del área de desarrollos electrónicos de INTI es el impulsor y director del proyecto.
Riesgo 2 Falta de capacidad en el ATSAMD21 (número de GPIOs, memoria RAM, memoria FLASH, etc.) para implementar las funcionalidades del módulo PlatC.
Severidad 9 Porque haría inviable el proyecto o bien implicaría reducir sus funcionalidades.
Prob. de Ocurrencia 3 Porque una investigación previa permitió determinar que la cantidad periféricos del ATSAMD21 es suficiente para la implementación del proyecto.
Riesgo 3 Defectos de fabricación en el hardware del módulo PlatC.
Severidad 6 Porque en caso de suceder realizar una nueva fabricación se traduce en pérdidas de tiempo.
Prob. de Ocurrencia 5 Porque es común que suceda toparse con algún error de ruteo o de mal dimensionamiento de los componentes.
Riesgo 4 No cumplir con la fecha de entrega pactada en el Acta de Constitución del Proyecto.
Severidad 10 Porque produce la no aprobación de la Maestría en Sistemas Embebidos.
Prob. de Ocurrencia 6 Porque el responsable del proyecto no cuenta con mucha experiencia previa en la planificación de proyectos.
Página 20 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
Riesgo 5 No cumplir con los requerimientos funcionales planteados
Severidad 9 Porque implica entregar un producto que no cumple con los requerimientos funcionales planteados.
Prob. de Ocurrencia 6 Porque el responsable del proyecto no cuenta con mucha experiencia previa en la ejecución de proyectos.
Se muestra a continuación la tabla de gestión de riesgos: el RPN se calcula como RPN = SxO.
Riesgo Severidad Ocurrencia RPN Severidad* Ocurrencia* RPN*
1 10 3 30 - - -
2 9 3 27 - - -
3 6 5 30 - - -
4 10 6 60 10 3 30
5 9 6 54 9 4 36
Criterio adoptado: Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 40 según el criterio definido por el responsable del proyecto. Nota: - Los valores marcados con (*) en la tabla corresponden luego de haber aplicado la mitigación. El plan de mitigación de los riesgos que originalmente excedían el PRN máximo establecido es el siguiente:
Riesgo 4 No cumplir con la fecha de entrega pactada en el Acta de Constitución del Proyecto.
Plan de mitigación Rigurosidad en el seguimiento del plan de trabajo y asignación de horas extras a tareas retrasadas.
Severidad 10 Porque aún produce la no aprobación de la Maestría en Sistemas Embebidos.
Prob. de Ocurrencia 3 Porque al ser riguroso en el seguimiento del plan de trabajo y asignar horas extras a las tareas retrasadas, el proyecto debería ser finalizado en tiempo y forma.
Página 21 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
Riesgo 5 No cumplir con los requerimientos funcionales planteados.
Plan de mitigación Analizar en profundidad junto con el orientador del proyecto cada uno de los requerimientos funcionales y simplificarlos en caso de ser ambiguos o requerir un tiempo de desarrollo superior al planificado.
Severidad 9 Porque implica entregar un producto que no cumple con los requerimientos funcionales planteados.
Prob. de Ocurrencia 4 Porque los requerimientos funcionales establecidos se pueden realizar en el tiempo planificado del proyecto.
13. Gestión de la calidad Se enumeran a continuación los requerimientos del proyectos, clasificándolos según sean funcionales o no funcionales; y se indica para cada uno de ellos la verificación y validación que será llevada a cabo por parte del responsable del proyecto.
Requerimientos Funcionales:
1. Módulo PlatC
1.1 Detectará movimientos con aceleración superiores a MOTION_THR. ● Verificación: Leer hoja de datos del acelerómetro MPU 9250 para verificar que tiene una
sensibilidad superior a MOTION_THR. ● Validación: Realizar movimientos con aceleración superiores a MOTION_THR y evidenciar
que el MPU 9250 los detecta, comparándolo con un acelerómetro patrón (presente en el smartphone, por ejemplo).
1.2 Cuando se detecte una aceleración superior a MOTION_THR, transmitirá inmediatamente un paquete PlatCData hacia PlatCApk.
● Verificación: Leer hoja de datos del acelerómetro MPU 9250 para verificar que tiene una sensibilidad superior a MOTION_THR.
● Validación: Conectar PlatC con el smartphone y realizar movimientos con aceleración superiores a MOTION_THR. Evidenciar que en la aplicación se reciben los valores de aceleración sensados.
1.3 Cuando se detecte una aceleración superior a MOTION_THR, encenderá y mantendrá el indicador MOTION_LED durante MOTION_DET_TIME.
● Verificación: Leer hoja de datos del acelerómetro MPU 9250 para verificar que tiene una sensibilidad superior a MOTION_THR.
● Validación: Realizar movimientos con aceleración superiores a MOTION_THR y evidenciar que el firmware del SAMD21 enciende MOTION_LED durante MOTION_DET_TIME.
1.4 Se vinculará con PlatCApk mediante un enlace BLE.
Página 22 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
● Verificación: Leer hoja de datos del módulo BLE BGM113 y verificar que sea compatible con el del smartphone (ambos deben ser compatibles con la norma Bluetooth 4.0).
● Validación: Iniciar el proceso de vinculación del dispositivo vestible desde la aplicación y evidenciar que efectivamente el enlace queda establecido.
1.5 Cuando se encuentre vinculado con PlatCApk, encenderá el indicador BLE_LED. ● Verificación: Leer hoja de datos del módulo BLE BGM113 y verificar que sea compatible
con el del smartphone (ambos deben ser compatibles con la norma Bluetooth 4.0). Verificar que la máquina de estados implementada en el SAMD21 enciende el BLE_LED cuando se produce el evento de conexión del BGM113.
● Validación: Iniciar el proceso de vinculación del dispositivo vestible desde la aplicación y evidenciar que efectivamente el enlace queda establecido y el BLE_LED se enciende.
1.6 Cuando se encuentre en proceso de carga de baterías, encenderá el indicador BATTERY_LED.
● Verificación: Leer hoja de datos del circuito de carga MCP73832T y verificar que sus pines estén ruteados a un GPIO del MCU SAMD21.
Verificar que la máquina de estados implementada en el SAMD21 enciende el BATTERY_LED cuando se produce el evento de inicio de carga de batería.
● Validación: Conectar el prototipo PlatC a un cargador y evidenciar que se enciende BATTERY_LED.
1.7 Cuando no exista vínculo entre PlatCApk y no se esté en curso una indicación de detección de movimiento mediante MOTION_LED, el sistema encenderá en secuencia los indicadores MOTION_LED, BLE_LED, y BATTERY_LED cada KEEPALIVE_TIME.
● Verificación: Leer hoja de datos del módulo BGM113 y verificar de qué manera indica su estado de conexión Bluetooth.
Verificar que la máquina de estados implementada en el SAMD21 enciende en secuencia los indicadores MOTION_LED, BLE_LED, y BATTERY_LED cada KEEPALIVE_TIME cuando el BGM113 está desconectado y el MPU 9250 no detecta movimiento.
● Validación: Desconectar PlatC de la aplicación que corre en el smartphone y evidenciar que se encienden en secuencia los indicadores MOTION_LED, BLE_LED, y BATTERY_LED cada KEEPALIVE_TIME.
1.8 Recibirá el paquete PlatCApkSettings con configuraciones desde el PlatCApk. ● Verificación: Leer la especificación del estandar Bluetooth 4.0 y determinar si el largo
máximo del paquete PlatCApkSettings es soportado para ser transmitido sin fragmentación.
● Validación: Conectar PlatC con la aplicación del smartphone, y evidenciar que el mensaje PlatCApkSettings es recibido mientras se debuguea el código.
1.9 Ajustará el umbral MOTION_THR de acuerdo al paquete de configuración PlatCApkSettings enviado por PlatCApk.
● Verificación: Leer la especificación del estandar Bluetooth 4.0 y determinar si el largo máximo del paquete PlatCApkSettings es soportado para ser transmitido sin fragmentación.
● Validación: Conectar PlatC con la aplicación del smartphone, y evidenciar que el mensaje PlatCApkSettings es recibido mientras se debuguea el código, y que el umbral MOTION_THR es modificado en memoria.
1.10 Cuando inicie será descubrible por PlatCApk.
Página 23 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
● Verificación: Leer la hoja de datos del BGM113 y analizar la manera en que el dispositivo se configura en modo Advertise (descubrible).
Verificar que la máquina de estados implementada en el SAMD21 configura al BGM113 en modo Advertise cuando el programa inicia.
● Validación: Encender PlatC y mediante el uso de un sniffer Bluetooth 4.0 capturar los paquetes que envía el BGM113 en modo Advertise.
1.11 Cuando permanezca sin establecer vínculo con PlatCApk durante más de DISCONNECTED_TIMEOUT dejará de ser descubrible.
● Verificación: Leer la hoja de datos del BGM113 y analizar la manera en que el dispositivo se saca de modo Advertise (descubrible).
Verificar que la máquina de estados implementada en el SAMD21 saca al BGM113 del modo Advertise cuando transcurrió DISCONNECTED_TIMEOUT .
● Validación: Encender PlatC y mediante el uso de un sniffer Bluetooth 4.0 capturar los paquetes que envía el BGM113 en modo Advertise. Evidenciar que transcurrido DISCONNECTED_TIMEOUT los paquetes dejan de ser transmitidos por el BGM113.
1.12 Cuando esté vinculado a PlatCApk y se presione PUSH_BUTTON durante más de SHORT2LONG_BUTT_TIME se desvinculará y permanecerá descubrible.
● Verificación: Verificar que la máquina de estados implementada en el SAMD21 configura al BGM113 del modo Advertise cuando transcurrió se presiona PUSH_BUTTON durante SHORT2LONG_BUTT_TIME.
● Validación: Encender PlatC y vincularlo a la aplicación del smartphone. Luego, pulsar PUSH_BUTTON durante SHORT2LONG_BUTT_TIME y mediante el uso de un sniffer Bluetooth 4.0 capturar los paquetes que envía el BGM113 en modo Advertise.
1.13 Cuando esté vinculado a PlatCApk y se presione PUSH_BUTTON durante menos de SHORT2LONG_BUTT_TIME transmitirá un paquete PlatCData a PlatCApk.
● Verificación: Verificar que la máquina de estados implementada en el SAMD21 envía un paquete PlatCData cuando se presiona PUSH_BUTTON durante menos de durante SHORT2LONG_BUTT_TIME .
● Validación: Encender PlatC y vincularlo a la aplicación del smartphone. Luego, pulsar PUSH_BUTTON durante menos de SHORT2LONG_BUTT_TIME y evidenciar que el paquete PlatCData se recibe en la aplicación.
1.14 Cuando no sea descubrible y se presione PUSH_BUTTON durante más de SHORT2LONG_BUTT_TIME será descubrible inmediatamente.
● Verificación: Verificar que la máquina de estados implementada en el SAMD21 configura al BGM113 en modo Advertise cuando se presiona PUSH_BUTTON durante más de SHORT2LONG_BUTT_TIME.
● Validación: Encender PlatC mediante el uso de un sniffer Bluetooth esperar hasta que no se observen más paquetes de Advertise. Luego, presionar PUSH_BUTTON durante más de SHORT2LONG_BUTT_TIME y evidenciar que el sniffer vuelve a capturar los paquetes de Advertise.
Página 24 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
2. Módulo de visualización
2.1 Deberá ser una aplicación para sistema operativo Android.
● Verificación: Verificar que el entorno de trabajo (Xamarin) permite desarrollar aplicaciones para el sistema operativo Android.
● Validación: Instalar la aplicación desarrollada en un smartphone Android y evidenciar que funciona correctamente.
2.1 Deberá mostrar los parámetros de configuración y datos adquiridos por el módulo PlatC.
● Verificación: Verificar que la aplicación desarrollada contiene una pantalla de configuración para los parámetros de funcionamiento de PlatC, y otra para observar los datos reportados.
● Validación: Instalar la aplicación desarrollada en un smartphone, modificar los parámetros de configuración de PlatC e impactarlos. Luego, evidenciar que se reciben mediones basadas en los nuevos umbrales de operación.
2.3 Deberá describir de forma hablada los datos adquiridos por el módulo PlatC.
● Verificación: Verificar que el entorno de trabajo (Xamarin) soporta la librería TextToSpeech.
● Validación: Vincular PlatC con el smartphone y evidenciar que la aplicación “lee” los datos recibidos.
2.2 Deberá permitir la modificación de los parámetros de configuración del módulo PlatC.
● Verificación: Leer la especificación del estándar Bluetooth 4.0 y determinar si el largo máximo del paquete PlatCApkSettings es soportado para ser transmitido sin fragmentación por la aplicación.
● Validación: Conectar PlatC con la aplicación del smartphone, y evidenciar que el mensaje PlatCApkSettings es recibido mientras se debuguea el código.
Requerimientos No Funcionales:
1. Módulo PlatC
1.1 Las configuraciones de PlatCSettings serán almacenadas en memoria no volátil.
● Verificación: Leer la hoja de datos del SAMD21 y verificar que cuenta con una zona de memoria no volátil (NVM) donde se puedan almacenar los umbrales de operación.
Buscar en Atmel Software Framework (ASF) el driver para almacenar dichos datos en la NVM.
Verificar que la máquina de estados implementada almacena los umbrales de operación en la NVM cuando se recibe un paquete PlatCSettings.
● Validación: Conectar PlatC con la aplicación del smartphone, enviar un paquete PlatCSettings y evidenciar que su contenido es almacenado en la NVM conforme se debuguea el código.
1.2 Filtrará el rebote del pulsador PUSH_BUTTON.
Página 25 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
● Verificación: Analizar el esquemático de PlatC y verificar que PUSH_BUTTON está conectado a un GPIO del SAMD21.
● Validación: Pulsar PUSH_BUTTON y evidenciar que la lógica anti rebote entra en acción conforme se debugue el firmware del SADM21.
1.3 MOTION_DET_TIME será configurable en tiempo de compilación.
● Verificación: Verificar que el código programado en el SAMD21 acepta como un literal de tiempo de compilación la constante MOTION_DET_TIME.
● Validación: Modificar MOTION_DET_TIME y recompilar el firmware. Debugger la nueva versión y evidenciar que el valor asignado a MOTION_DET_TIME es diferente del previo.
1.4 Mantendrá el tiempo de operación en memoria no persistente.
● Verificación: Verificar que el código programado en el SAMD21 utiliza el valor devuelto por el RTC mediante una variable no volátil de RAM.
● Validación: Vincular PlatC con el smartphone y leer el tiempo de operación reportado. Luego, reiniciar PlatC y evidenciar que el tiempo de operación volvió a cero.
1.5 El firmware del módulo debe diseñarse minimizando el consumo.
● Verificación: Leer la hoja de datos del BGM113 y SAMD21 y verificar que cuentan con modos de operación de bajo consumo.
● Validación: Realizar mediciones de consumo que permitan validar que el mismo no supere cierto umbral a definir.
1.6 Debe cumplir con la recomendación IEC 801 de “Compatibilidad electromagnética para medición de procesos industriales y equipos de control (por extensión)”.
● Verificación: Leer la hoja de datos del BGM113 y verificar que su potencia de transmisión de adecua a la especificada en la recomendación IEC 801.
● Validación: Realizar un ensayo de compatibilidad electromagnética en una institución adecuada para tal fin (por ejemplo, INTI).
14. 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
Plan de Proyecto Director de MSE, director del proyecto
y cliente
Evaluar los requerimientos e
indicar la motivación y la planificación del
proyecto
Una vez (al inicio del proyecto)
Documentación compartida en
formato electrónico
Esp. Ing. Rodrigo
Alejandro Tirapegui
Página 26 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
Diseño del firmware
Director y colaborador del proyecto
Confirmar que cumple con los requerimientos
funcionales planteados
Semanalmente
Correo electrónico
Esp. Ing. Rodrigo
Alejandro Tirapegui
Implementación del firmware
Director del proyecto
Confirmar la correcta
implementación del mismo
Semanalmente
Correo electrónico
Esp. Ing. Rodrigo
Alejandro Tirapegui
Diseño de software
Director y colaborador del proyecto
Confirmar que cumple con los requerimientos
funcionales planteados
Semanalmente
Correo electrónico
Esp. Ing. Rodrigo
Alejandro Tirapegui
Implementación de software
Director del proyecto
Confirmar la correcta
implementación del mismo
Semanalmente
Correo electrónico
Esp. Ing. Rodrigo
Alejandro Tirapegui
Gestión del proyecto
Director de MSE
Confirmar la correcta
redacción de los diferentes
documentos que componen el
proyecto
En cada entrega
Documentación compartida en
formato electrónico
Esp. Ing. Rodrigo
Alejandro Tirapegui
15. Gestión de Compras El presente proyecto no requiere la compra de componentes electrónicos dado que actualmente, INTI
cuenta con 3 (tres) prototipos fabricados del módulo PlatC. En relación con el instrumental necesario para
llevar a cabo el proyecto, INTI ofrece sus laboratorios e instrumental para cubrir la tarea, contando con
osciloscopios, equipo de soldadura e inspección, analizadores lógicos, etc.
Página 27 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
16. 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 Items completados del plan de trabajo
Semanal durante la etapa de
desarrollo de la tarea
Esp Ing. Rodrigo Alejandro Tirapegui
Director MSE, director del proyecto y
cliente
Correo electrónico
1.2 Porcentaje del manual de
usuario completado
Semanal durante la etapa de
desarrollo de la tarea
Esp. Ing. Rodrigo Alejandro Tirapegui
Director MSE, director del proyecto y
cliente
Correo electrónico
1.3 Items del informe de
avance completados
Semanal durante la etapa de
desarrollo de la tarea
Esp .Ing. Rodrigo Alejandro Tirapegui
Director MSE, director del proyecto y
cliente
Correo electrónico
1.4 Items de la memoria de
trabajo completados
Semanal durante la etapa de
desarrollo de la tarea
Esp. Ing. Rodrigo Alejandro Tirapegui
Director MSE y director del
proyecto
Correo electrónico
1.5 Diapositivas incluidas y video
Diario durante la etapa de
desarrollo de la tarea
Esp .Ing. Rodrigo Alejandro Tirapegui
Director MSE y director del
proyecto
Correo electrónico
2.1 Documentación y ejemplos de
uso del framework RKH
Semanal durante la etapa de
desarrollo de la tarea
Esp. Ing. Rodrigo Alejandro Tirapegui
Colaborador del proyecto
Correo electrónico
2.2 Documentación y ejemplos de uso del stack
BLE
Semanal durante la etapa de
desarrollo de la tarea
Esp. Ing. Rodrigo Alejandro Tirapegui
Colaborador del proyecto
Correo electrónico
2.3 Proyecto funcional en el
entorno de trabajo
Una vez al configurar el entorno de
trabajo
Esp. Ing. Rodrigo Alejandro Tirapegui
Colaborador del proyecto
Link a repositorio de
GitHub
Página 28 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
2.4 Archivos fuente de cada
máquina de estados
implementada
Semanalmente durante la etapa
de desarrollo de la tarea
Esp. Ing. Rodrigo Alejandro Tirapegui
Director del proyecto
Link a repositorio de
GitHub
2.5 Documento explicativo del
protocolo y archivos fuente
con la lógica implementada
Semanalmente durante la etapa
de desarrollo de la tarea
Esp. Ing. Rodrigo Alejandro Tirapegui
Director del proyecto
Correo electrónico y link a repositorio de
GitHub
2.6 Documento explicativo y
archivos fuente con la lógica
implementada
Semanalmente durante la etapa
de desarrollo de la tarea
Esp Ing. Rodrigo Alejandro Tirapegui
Director del proyecto
Correo electrónico y link a repositorio de
GitHub
2.7 Documento explicativo y
archivos fuente con la lógica
implementada
Semanalmente durante la etapa
de desarrollo de la tarea
Esp. Ing. Rodrigo Alejandro Tirapegui
Director del proyecto
Correo electrónico y link a repositorio de
GitHub
2.8 Porcentaje de la documentación
redactada
Semanalmente durante la etapa
de desarrollo de la tarea
Esp. Ing. Rodrigo Alejandro Tirapegui
Director del proyecto
Correo electrónico
3.1 Documentación y ejemplos de uso del SDK
Android
Semanalmente durante la etapa
de desarrollo de la tarea
Esp. Ing. Rodrigo Alejandro Tirapegui
Colaborador del proyecto
Correo electrónico
3.2 Documentación y ejemplos de
uso de la librería TextToSpeech
Semanalmente durante la etapa
de desarrollo de la tarea
Esp .Ing. Rodrigo Alejandro Tirapegui
Colaborador del proyecto
Correo electrónico
3.3 Proyecto funcional en el
entorno de trabajo
Una vez al configurar el entorno de
trabajo
Esp. Ing. Rodrigo Alejandro Tirapegui
Colaborador del proyecto
Link a repositorio de
GitHub
Página 29 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
3.4 Documento explicativo y
archivos fuente con la lógica
implementada
Semanalmente durante la etapa
de desarrollo de la tarea
Esp. Ing. Rodrigo Alejandro Tirapegui
Director del proyecto
Correo electrónico y link a repositorio de
GitHub
3.5 Porcentaje de la documentación
redactada
Semanalmente durante la etapa
de desarrollo de la tarea
Esp. Ing. Rodrigo Alejandro Tirapegui
Director del proyecto
Correo electrónico
4.1 Listado de los periféricos de
hardware probados
Semanalmente durante la etapa
de desarrollo de la tarea
Esp. Ing. Rodrigo Alejandro Tirapegui
Director del proyecto,
colaborador del proyecto
y cliente
Correo electrónico
4.2 Listado de las pruebas
unitarias de firmware probadas
Semanalmente durante la etapa
de desarrollo de la tarea
Esp. Ing. Rodrigo Alejandro Tirapegui
Director del proyecto,
colaborador del proyecto
y cliente
Correo electrónico
4.3 Listado de las pruebas
unitarias de software probadas
Semanalmente durante la etapa
de desarrollo de la tarea
Esp. Ing. Rodrigo Alejandro Tirapegui
Director del proyecto,
colaborador del proyecto
y cliente
Correo electrónico
4.4 Listado de las pruebas de
sistema realizadas
Semanalmente durante la etapa
de desarrollo de la tarea
Esp .Ing. Rodrigo Alejandro Tirapegui
Director del proyecto y
cliente
Correo electrónico
4.5 Porcentaje de la documentación
redactada
Semanalmente durante la etapa
de desarrollo de la tarea
Esp. Ing. Rodrigo Alejandro Tirapegui
Director del proyecto y
cliente
Correo electrónico
Página 30 de 31
Plan de Proyecto del Trabajo Final de la
Maestría de Sistemas Embebidos
Esp. Ing. Rodrigo Alejandro Tirapegui
17. Procesos de cierre Al finalizar el proyecto se realizará una evaluación final que contemple las siguientes actividades:
● El responsable del proyecto analizará si se respetó el plan de proyecto original, comparando dicho cronograma contra el real e identificando las tareas que mayor divergencia de tiempo presentaron y sus causas.
● El responsable del proyecto realizará una lista de las técnicas y procedimientos que le resultaron útiles para cumplir con los objetivos preestablecidos, y las que le hayan generado retrasos, indicando las posibles causas.
● El responsable del proyecto se encargará de agradecer a todas las personas involucradas en el proyecto, miembros del jurado, docentes y autoridades de MSE.
Página 31 de 31