Sistema de monitoreo de estado del agua de una...

Plan de Proyecto del Trabajo Final de Carrera de Especialización de Sistemas Embebidos

Ing. Fabrizio Gelsi

Sistema de monitoreo de estado del agua de una

piscina

Autor

Ing. Fabrizio Gelsi

Director del trabajo

Esp. Ing. Patricio Bos

Jurado propuesto para el trabajo

- Esp. Ing. Facundo Larosa - Esp. Ing. Juan V. Montilla C. - Esp. Ing. Ramiro Alonso

Este plan de trabajo ha sido realizado en el marco de la asignatura Gestión de Proyectos entre octubre y noviembre de 2016.

Página 1 de 40


Ing. Fabrizio Gelsi

Página 2 de 40


Ing. Fabrizio Gelsi

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 6

1. Propósito del proyecto 7

2. Alcance del proyecto 7

3. Supuestos del proyecto 7

4. Requerimientos 8

5. Entregables principales del proyecto 9

6. Desglose del trabajo en tareas 9

7. Diagrama de Activity On Node 11

8. Diagrama de Gantt 12

9. Matriz de uso de recursos de materiales 16

10. Presupuesto detallado del proyecto 18

11. Matriz de asignación de responsabilidades 20

12. Gestión de riesgos 22

13. Gestión de la calidad 26

14. Comunicación del proyecto 29

15. Gestión de Compras 30

16. Seguimiento y control 30

17. Procesos de cierre 37

Página 3 de 40


Ing. Fabrizio Gelsi

Registros de cambios

Revisión Detalle de los cambios realizados Fecha

1.0 - Creación del documento - Completados puntos 1 a 6

14/10/2016

1.1 - Corrección en la “identificación y análisis de los interesados” y en los puntos: 4 y 6

- Completados puntos 7 a 11

28/10/2016

1.2 - Corrección en el gráfico de la descripción técnica-conceptual y en el diagrama de Gantt

- Completados puntos 12 a 17

06/11/2016

Página 4 de 40


Ing. Fabrizio Gelsi

Acta de Constitución del Proyecto

Buenos Aires, 14 de octubre de 2016

Por medio de la presente se acuerda con el Ing. Fabrizio Gelsi que su Proyecto Final de la

Carrera de Especialización en Sistemas Embebidos se titulará “Sistema de monitoreo de estado del agua

de una piscina”, consistirá esencialmente en el prototipo preliminar de un sistema de medición

automática de variables que informan el estado del agua en una piscina y son enviadas al módulo de

control de bombas vía bluetooh, y tendrá un presupuesto preliminar estimado de 600 hs de trabajo,

con fecha de inicio sábado 14 de octubre de 2016 y fecha de presentación pública lunes 31 de julio de

2017.

Se adjunta a esta acta la planificación inicial.

Ariel Lutenberg Sergio Vicente

Director de la CESE-FIUBA Presidente de ComSi S.A.

Patricio Bos

Director del Trabajo Final

Facundo Larosa Juan V. Montilla C.

Jurado del Trabajo Final Jurado del Trabajo Final

Ramiro Alonso

Jurado del Trabajo Final

Página 5 de 40


Ing. Fabrizio Gelsi

Descripción técnica-conceptual del Proyecto a realizar

El proyecto consiste en generar un módulo que sea capaz de automatizar la tarea de medir las

diferentes variables que determinan el estado del agua en una piscina, y afectan a la misma. Mediante

este sistema se puede obtener el estado del agua sin tener que medir las diferentes variables de

manera manual una a una. Una vista macro del sistema se muestra a continuación en la Figura 1.

La variables que se van a medir para determinar el estado del agua son: Temperatura, pH, nivel de

cloro, salinidad, sólidos disueltos.

Figura 1 - Intercomunicación de los módulos del sistema

Página 6 de 40


Ing. Fabrizio Gelsi

Identificación y análisis de los interesados

Rol Nombre y Apellido Departamento Puesto

Cliente ComSi S.A. Dirección Empresa

Impulsor Sergio Vicente ComSi S.A. Presidente

Responsable Fabrizio Gelsi Ingeniero Implementador

Colaboradores Marcelo Moreno Ingeniero Implementador

Jorge Angioni Diseño de hardware Técnico

David San Román Diseño de hardware Técnico

Gastón Maciel Dirección de proyectos Asistente de

proyecto

José Luis Gonzalez Diseño de software y app Gerente de proyecto

Usuario Final Particulares/Empresas

que posean una piscina

- Auspiciante y Cliente: La empresa ComSi S.A. espera que el proyecto se termine en tiempo y forma.

Aportará el dinero necesario para la compra de los elementos a utilizar y también brindará la

posibilidad de utilizar su propio laboratorio de ser necesario para el desarrollo del proyecto.

- Impulsor: Aportará su knowledge de proyectos anteriores con el objetivo de generar una buena

planificación e implementación del proyecto. Es exigente en cuanto a conocer el avance del proyecto.

Se realizarán reuniones vía Skype cada 7 o 15 días.

- Colaborador (Marcelo Moreno): Aportará en la decisión de la interfaz entre el actual sistema, y el

sistema que el desarrollará denominado “Sistema de Control de Bombas de Filtrado y Aplicación de Químicos”, a fin de que ambos sistemas se comuniquen exitosamente, y el sistema funcione en su conjunto. Tiene interés en que el proyecto salga adelante sino no aprueba su posgrado.

- Usuario Final: Cadena de hoteles, centros vacacionales, clubes, centros deportivos públicos y

privados, usuarios hogareños y consorcios que poseen una piscina.

Página 7 de 40


Ing. Fabrizio Gelsi

1. Propósito del proyecto

Este proyecto tiene dos propósitos. El primero es obtener el título de Especialista en Sistemas

Embebidos, que otorga la Universidad de Buenos Aires, por lo tanto en la realización del hardware se

pondrá el mayor esmero posible con el fin de conseguir la solidez necesaria que demuestre los

conocimientos en esta área. En segundo lugar se busca tener la primer experiencia real como ingeniero

desarrollando un producto para un tercero, en este caso una empresa; con lo cual las relaciones que se

mantengan con la empresa, las presentaciones intermedias que se realicen y el desarrollo general de

llevar adelante el proyecto de manera estable es un gran desafío personal. La idea es generar en mi

persona una base de conocimiento y un portfolio personal para futuros trabajos.

2. Alcance del proyecto

El proyecto incluye:

● Realización de un prototipo de hardware completamente funcional, con el cual se podrán medir las variables especificad en la descripción técnico-conceptual del documento.

● Interfaz de comunicación entre el prototipo realizado y el servidor, vía bluetooth. ● Aplicación móvil que se conecta vía bluetooth con el hardware desarrollado, para poder

visualizar la información de estado del agua.

El proyecto no incluye:

● El diseño/fabricación de la carcasa que contiene el hardware desarrollado.

3. Supuestos del proyecto

Supuestos:

● Todos los módulos necesarios para el proyecto podrán adquirirse. ● La empresa ComSi S.A. brindará los módulos antes mencionados, y se hará cargo del gasto

económico que pueda generarse como compra de dichos módulos. ● En caso de que la empresa ComSi S.A. desista en llevar adelante el proyecto, se llevará

adelante de manera personal, tomando los costes del proyecto en este caso de manera personal.

● El dispositivo será utilizado dentro de una carcasa que cumple con la norma IP66. La carcasa será diseñada y fabricada por ComSi S.A..

● El alumno que realiza el proyecto Sistema de Control de Bombas de Filtrado y Aplicación de Químicos, no debe abandonar el proyector. En caso de que ello suceda, la segunda restricción mencionada más adelante, deja de tener valor.

Página 8 de 40


Ing. Fabrizio Gelsi

Restricciones:

● Se deberá usar el microcontrolador ATMEL XMEGA - (ATXMEGA16A4 o ATxMEGA64A3). ● El prototipo generado debe integrarse totalmente con el Módulo de control de filtrado y

aplicación de químicos para el Sistema de Monitoreo y Control de Piscina.

4. Requerimientos

1. Variables a sensar 1.1. Se deberá utilizar un sensor de temperatura resistente al agua. 1.2. Se deberá utilizar un sensor de pH. 1.3. Se deberá utilizar un sensor de nivel de cloro. 1.4. Se deberá utilizar un sensor de salinidad. 1.5. Se deberá utilizar un sensor de sólidos disueltos. 1.6. Todos los sensores antes mencionados deben presentar un grado de protección

IP66 como mínimo. 2. Comunicaciones

2.1. La comunicación entre el prototipo y el Servidor o la aplicación móvil, será vía bluetooth.

3. Características del sistema 3.1. Se utilizará el microcontrolador ATMEL XMEGA (ATXMEGA16A4 o ATxMEGA64A3). 3.2. El sistema debe contar con una batería de alimentación para su funcionamiento. 3.3. El sistema debe contar con una celda solar para tener la posibilidad de recargar la

batería mencionada en 3.2. 3.4. La batería mencionada en 3.2 también podrá cargarse mediante la conexión a la red

eléctrica. 3.5. El sistema debe contar con 1 módulo Bluetooth. 3.6. Se deberá tener una central (Servidor) que almacene los datos sensados por el

sistema. 4. Software

4.1. Se contará con una aplicación móvil que permita visualizar los datos adquiridos por el sistema embebido.

4.2. Se deberá mostrar los datos adquiridos mediante la plataforma Web iDAT de ComSi.

5. Ambiente 5.1. El sistema deberá operar correctamente en un rango de temperatura entre 0°C y

60°C. 6. Funcionamiento del sistema embebido:

6.1. El sistema permitirá 2 formas de funcionamiento: Automática y Manual. 6.1.1. En el modo automático, el sistema adquirirá todos los datos detallados

anteriormente en Requerimiento 1, de manera periódica y los enviará a la estación central a travé del módulo de comunicaciones.

Página 9 de 40


Ing. Fabrizio Gelsi

6.1.2. El período de adquisición de datos podrá ser seteado por el usuario de una lista de selección posible.

6.1.3. En el modo manual, la adquisición de datos se hace cuando el usuario la solicita mediante la aplicación móvil.

6.1.4. Mientras el sistema no se encuentra adquiriendo datos, se encontrará en modo de bajo consumo.

6.2. El Servidor debe dar alertas por límites de las variables sensadas, desconexión con el sistema de sensado, o baja batería en el sistema de sensado.

6.3. El sistema debe poder alertar también de manera propia que la batería se está agotando. A determinar si es una alerta sonora o lumínica.

7. Documentación 7.1. Se deberá utilizar una herramienta de generación automática de documentación.

5. Entregables principales del proyecto

● Prototipo del sistema ● Aplicación móvil para comunicación vía bluetooth con el prototipo. ● Manual de instalación ● Manual de usuario ● Informe final

6. Desglose del trabajo en tareas

1. Investigación (69 hs)

1.1. Relevar información de empresas que ofrezcan productos similares (5 hs)

1.2. Buscar hoja de datos de todos los componentes. Por cada componente más de una hoja

de datos, de distinto fabricante, o de igual fabricante, distinto producto, para tener

varias opciones a elegir (8 hs)

1.3. Realizar informe mostrando las mejores opciones teniendo en cuenta costo/beneficio

de los componentes (6 hs)

1.4. Realizar informe de lo mejor que ofrecen otras empresas (5 hs)

1.5. Estudiar cómo funciona cada uno de los componentes mediante las hojas de datos

obtenidas en 1.2 (45hs)

2. Elección de hardware a utilizar (16 hs)

2.1. Seleccionar el sensor de temperatura (2 hs)

2.2. Seleccionar el sensor de pH (2 hs)

2.3. Seleccionar el sensor de nivel de cloro (2 hs)

2.4. Seleccionar el sensor de salinidad (2 hs)

2.5. Seleccionar el sensor de sólidos disueltos (2 hs)

2.6. Seleccionar el módulo Bluetooth (2 hs)

2.7. Seleccionar batería a utilizar (2 hs)

2.8. Seleccionar celda solar a utilizar (2 hs)

Página 10 de 40


Ing. Fabrizio Gelsi

3. Obtención del hardware (16 hs)

3.1. Adquisición de los componentes (16 hs). Demoran 45 días en llegar.

4. Comienzo del desarrollo (8 hs)

4.1. Familiarizarse con el entorno de desarrollo provisto por el fabricante del

microcontrolador (8 hs)

5. Implementación de los drivers para los dispositivos elegidos (170 hs)

5.1. Implementar driver del sensor de temperatura (20 hs)

5.2. Implementar driver del sensor de pH (20 hs)

5.3. Implementar driver del sensor de nivel de cloro (20 hs)

5.4. Implementar driver del sensor de salinidad (20 hs)

5.5. Implementar driver del sensor de sólidos disueltos (20 hs)

5.6. Implementar los drivers de los módulos de comunicación (40 hs)

5.7. Pruebas unitarias de los drivers (30 hs)

6. Implementar el sistema (220 hs)

6.1. Desarrollar el código principal (70 hs)

6.2. Desarrollar la aplicación móvil que se conecte con el sistema (100 hs)

6.3. Realizar el hardware necesario para que la batería se cargue mediante la celda solar (60

hs)

6.4. Prueba del sistema en su conjunto (10 hs)

7. Armado del prototipo (5 hs)

7.1. Encapsular el sistema de sensado en la carcasa provista por ComSi S.A., que cumple con

las normas IP66. (5 hs)

8. Testing (20 hs)

8.1. Testear el correcto funcionamiento del dispositivo (5 hs)

8.2. Testear el correcto funcionamiento de la aplicación (5 hs)

8.3. Testear el sistema en su conjunto (8 hs)

8.4. Evaluar el cumplimiento de los requerimientos (2 hs)

9. Documentación del proyecto (78 hs)

9.1. Realizar el informe de avance (15 hs)

9.2. Realizar el Manual de usuario (15 hs)

9.3. Realizar el Manual de instalación (15 hs)

9.4. Realizar el informe final (25 hs)

9.5. Realizar una presentación para exponer en público el proyecto (8 hs)

Cantidad total de horas: 602 hs

Página 11 de 40


Ing. Fabrizio Gelsi

7. Diagrama de Activity On Node

La unidad de tiempo (t) que se utiliza para la descripción del desglose de tareas en el diagrama Activity

On Node es la hora.

Diagrama AON tomando en cuenta WBS realizado en 6.

Se marcó el camino crítico en el diagrama con flechas de mayor grosor. El mismo se corresponde a las

tareas: 1.2 - 1.3 - 1.5 - 2 - 3.1 - 5 - 6.1 - 9.1 - 6.2 - 7.1 - 8.1 - 8.2 - 8.3 - 8.4 - 9

Si bien el proyecto cuenta con un solo recurso humano para la ejecución de las tareas, existe la posibilidad de realizar algunas tareas en forma paralela con la colaboración de personal de ComSi S.A. por ejemplo, si fuera necesario en el proyecto. En este sentido la tarea 6.3 podría ser realizada por ellos independientemente del avance del proyecto.

Página 12 de 40


Ing. Fabrizio Gelsi

8. Diagrama de Gantt

Página 13 de 40


Ing. Fabrizio Gelsi

Página 14 de 40


Ing. Fabrizio Gelsi

Página 15 de 40


Ing. Fabrizio Gelsi

Página 16 de 40


Ing. Fabrizio Gelsi

9. Matriz de uso de recursos de materiales

Código WBS

Nombre de la tarea

Recursos requeridos (horas)

Programador Notebook Micro ATMEL

Componente(s) electrónico(s)

1.1 Relevar información de

empresas que ofrezcan

productos similares

5 5

1.2 Buscar hoja de datos de los

componentes

8 8

1.3 Realizar informe de los

componentes

6 6

1.4 Realizar informe sobre otras

empresas

5 5

1.5 Estudiar cómo funciona cada

componente

45

2.1 Seleccionar el sensor de

temperatura

2

2.2 Seleccionar el sensor de pH 2

2.3 Seleccionar el sensor de nivel

de cloro

2


salinidad

2


sólidos disueltos

2

2.6 Seleccionar el módulo

Bluetooth

2

2.7 Seleccionar la batería 2

2.8 Seleccionar la celda solar 2

Página 17 de 40


Ing. Fabrizio Gelsi

4.1 Familiarizarse con el entorno

de desarrollo

8 8

5.1 Implementar driver del sensor

de temperatura

20 20 20


de pH

20 20 20


de nivel de cloro

20 20 20


de salinidad

20 20 20


de sólidos disueltos

20 20 20

5.6 Implementar los driver de los

módulos de comunicación

40 40 40

5.7 Pruebas unitarias de los

drivers

30 30 30

6.1 Desarrollar el código principal 70 70 70 70

6.2 Desarrollar la aplicación móvil

que se conecte al sistema

100 100 100 100

6.3 Realizar el hardware

necesario para que la batería

se cargue mediante la celda

solar

60

6.4 Prueba del sistema en su

conjunto

10 10 10 10

7.1 Encapsular el sistema de

sensado en la carcasa provista

por ComSi S.A.

5 5 5

8.1 Testear el correcto

funcionamiento del

dispositivo

5 5 5 5

Página 18 de 40


Ing. Fabrizio Gelsi


funcionamiento de la

aplicación

5 5 5 5

8.3 Testear el sistema en su

conjunto

8 8 8 8

8.4 Evaluar el cumplimiento de

los requerimientos

2 2

9.1 Realizar el informe de avance 15 15

9.2 Realizar el Manual de usuario 15 15

9.3 Realizar el Manual de

instalación

15 15

9.4 Realizar el informe final 25 25

9.5 Realizar presentación para

exposición del proyecto

8 8

10. Presupuesto detallado del proyecto

Categoría Detalle Costo($)

Trabajo directo 600 hs x $250/h 150.000

Componentes Microcontrolador 120

Sensor de temperatura 150

Sensor de pH 300

Sensor de nivel de cloro Indefinido

Sensor de salinidad 1.000

Página 19 de 40


Ing. Fabrizio Gelsi

Sensor de sólidos

disueltos Indefinido

Módulos Bluetooth 225

Leds 10

Batería 400

Celda solar 50

Costos indirectos (30% del costo directo) (152.255+INDEFINIDO)*0.3

Total presupuesto 152.255 + INDEFINIDO

Página 20 de 40


Ing. Fabrizio Gelsi

11. Matriz de asignación de responsabilidades

Código WBS

Título de la tarea Fabrizio Gelsi Responsable

Sergio VIcente

Impulsor

Marcelo Moreno

Colaborardor

ComSi S.A. Cliente

1.1 Relevar información de

empresas que ofrezcan

productos similares

P S

1.2 Buscar hoja de datos de

los componentes

P

1.3 Realizar informe de los

componentes

P I A

1.4 Realizar informe sobre

otras empresas

P I,C A

1.5 Estudiar cómo funciona

cada componente

P


temperatura

P C I A


pH

P C I A


nivel de cloro

P C I A


salinidad

P C I A


sólidos disueltos

P C I A

2.6 Seleccionar el módulo

Bluetooth

P C I A

2.7 Seleccionar la batería P C I A

2.8 Seleccionar la celda

solar

P C I A

Página 21 de 40


Ing. Fabrizio Gelsi

4.1 Familiarizarse con el

entorno de desarrollo

P C

5.1 Implementar driver del

sensor de temperatura

P I,C


sensor de pH

P I,C


sensor de nivel de cloro

P I,C


sensor de salinidad

P I,C


sensor de sólidos

disueltos

P I,C

5.6 Implementar los driver

de los módulos de

comunicación

P I,C

5.7 Pruebas unitarias de los

drivers

P I A

6.1 Desarrollar el código

principal

P I,C

6.2 Desarrollar la aplicación

móvil que se conecte al

sistema

P I A

6.3 Realizar el hardware

necesario para que la

batería se cargue

mediante la celda solar

P C C A

6.4 Prueba del sistema en

su conjunto

P A

7.1 Encapsular el sistema de

sensado en la carcasa

provista por ComSi S.A.

S P A

Página 22 de 40


Ing. Fabrizio Gelsi


funcionamiento del

dispositivo

P I A


funcionamiento de la

aplicación

P I A

8.3 Testear el sistema en su

conjunto

P I A

8.4 Evaluar el cumplimiento

de los requerimientos

P I A

9.1 Realizar el informe de

avance

P I


usuario

P I A


instalación

P I A

9.4 Realizar el informe final P I

9.5 Realizar presentación

para exposición del

proyecto

P I

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

12. Gestión de riesgos a) - Riesgo 1: Mala planificación del proyecto.

● Severidad (S): 8. Si se realizó una mala planificación del proyecto, no se cumplirán con los objetivos del proyecto en tiempo y forma.

● Probabilidad de ocurrencia (O): 4.

Página 23 de 40


Ing. Fabrizio Gelsi

Para planificar el proyecto de manera correcta se realizará un informe previo utilizando herramientas adecuadas para realizar una planificación que sea lo más cercana posible a la realidad, en el caso ideal, sería la realidad exacta, pero hay que tener en cuenta que es la primera vez que el responsable del proyecto lleva adelante un trabajo de tal envergadura con lo cual se debe tener en cuenta ello también.

- Riesgo 2: No cumplir las expectativas del jurado.

● Severidad (S): 10. Si el proyecto no cumple con las expectativas del jurado se deberá modificar bien los requerimientos del proyecto, o cambiar de proyecto directamente. Cualquiera de las dos opciones implica una pérdida importante de tiempo y una reingeniería de todas las etapas ya realizadas.

● Probabilidad de ocurrencia (O): 2. Suena poco probable que el jurado no acepte la propuesta, ya que al parecer del responsable del proyecto cumple con varios puntos importantes, es un proyecto de sistemas embebidos, es un proyecto para una empresa externa al posgrado, y es un producto interesante el que se va a generar, pero no hay que descartarlo.

- Riesgo 3: Retraso en la adquisición de los componentes o no adquisición. ● Severidad (S): 9.

Un retraso en la adquisición de los componentes generaría un grave problema, ya que de por si esa es una etapa que tiene asignada mucho tiempo en el proyecto. No contar con los componentes, sería aún un caso peor, ya que habría que cambiar algunos requerimientos del proyecto.

● Probabilidad de ocurrencia (O): 8. ComSi S.A. que es quien se encargará de comprar los componentes ya tiene experiencia en la compra de los mismos, y tiene contacto habitualmente con sus proveedores con lo cual no debería ocurrir, pero debe tenerse en cuenta igualmente porque si ya de por sí se nos dijo desde ComSi S.A. que puede demorar mucho tiempo, entonces hay que preverlo.

- 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 nuevamente de 15 días a 3 meses en la espera de los nuevos componentes. Esto directamente anularía el poder cumplir con la entrega del trabajo en tiempo y forma.

● Probabilidad de ocurrencia (O): 3. Si bien los componentes pueden fallar, generalmente esto no ocurre si se utilizan de manera correcta.

- Riesgo 5: Dificultad para construir una carcasa que contenga al sistema embebido. ● Severidad (S): 6.

Ya que el sistema operará estando en el agua, es necesario que el mismo se encuentre protegido porque sino le ingresaría líquido así como radiación solar y su funcionamiento sería impredecible o nulo directamente. El sistema quedaría como un prototipo en lugar de un componente final para venta con lo cual la severidad es puntuada en 6 por ello.

● Probabilidad de ocurrencia (O): 2.

Página 24 de 40


Ing. Fabrizio Gelsi

ComSi S.A. se comprometío a realizarlo por consiguiente se supone que no debería pasar. Además de que comentó que tienen una persona de diseño industrial que se encargará de ello con lo cual su experiencia será la necesaria para que la carcasa sea construida en tiempo y forma.

- Riesgo 6: Variación en los requerimientos del proyecto. ● Severidad (S): 6.

Este valor depende del grado de avance del proyecto al momento de la ocurrencia del riesgo. En la etapa actual, la severidad no es tan alta. Si sucede en etapas posteriores a la implementación del sistema, puede llegar a tener un impacto considerablemente negativo.

● Probabilidad de ocurrencia (O): 9. Es altamente probable que los requerimientos cambien en el tiempo, además que tiene un peso fuerte porque fue un proyecto que ComSi S.A. no lo tenía planificado, sino que tenía una idea de algo que pensaba hacer, pero nunca se lo había planteado en firme.

- Riesgo 7: Pérdida de prioridades del proyecto frente a compromisos laborales.

● Severidad (S): 9. No podrá cumplirse la fecha de entrega.

● Probabilidad de ocurrencia (O): 7. El responsable del proyecto además de cursar el posgrado tiene un trabajo, el cual le implica 8 horas al día dedicadas para ello, además de que si surgieran tareas en el trabajo que no puedan postergarse esas 8 horas diarias podrían extenderse cada día en el tiempo.

b) Tabla de gestión de riesgos:

Riesgo Severidad Ocurrencia RPN Severidad* Ocurrencia* RPN*

1 8 4 32

2 10 2 20

3 9 8 72 9 5 45

4 10 3 30

5 6 2 12

6 6 9 54 6 2 12

7 9 7 63 9 4 36

Criterio adoptado: - Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 50. Nota: - Los valores marcados con (*) en la tabla corresponden luego de haber aplicado la mitigación.

Página 25 de 40


Ing. Fabrizio Gelsi

c) Plan de mitigación de los riesgos que originalmente excedían el PRN máximo establecido: - Riesgo 3: Retraso en la adquisición de los componentes o no adquisición.

● Plan de mitigación: Si sucediera que no se consiguen los componentes, pasado el tiempo máximo de 3 meses, se recurrirá a proveedores dentro del país y si estos no pueden satisfacer, se recurrirá a utilizar los componentes más cercanos a los deseados que se obtengan en Argentina, a fin de cumplir los tiempos de entrega pactados para obtener el título de Especialista.

● Severidad (S): 9. Un retraso en la adquisición de los componentes generaría un grave problema, ya que de por si esa es una etapa que tiene asignada mucho tiempo en el proyecto. No contar con los componentes, sería aún un caso peor, ya que habría que cambiar algunos requerimientos del proyecto.

● Probabilidad de ocurrencia (O): 5. Al aplicar el plan de mitigación, en caso de que ocurra el riesgo, no se sabe si se podrá cumplir con los requisitos exactos iniciales del proyecto, por eso igualmente el valor de probabilidad de ocurrencia es medianamente alto.

- Riesgo 6: Variación en los requerimientos del proyecto. ● Plan de mitigación: Se adoptará una metodología de trabajo en la cual se hagan reuniones

semanales, para ir validando, a medida que avanza el proyecto, los requerimientos con el cliente. Así no habrá problemas de que los requerimientos varíen de manera importante.

● Severidad (S): 6. Este valor depende del grado de avance del proyecto al momento de la ocurrencia del riesgo. En la etapa actual, la severidad no es tan alta. Si sucede en etapas posteriores a la implementación del sistema, puede llegar a tener un impacto considerablemente negativo.

● Probabilidad de ocurrencia (O): 2. Al utilizar esta metodología de trabajo la variación de requerimientos no impactará notablemente en el desarrollo del proyecto.

- Riesgo 7: Pérdida de prioridades del proyecto frente a compromisos laborales.

● Plan de mitigación: Se hará el mayor esfuerzo, durante los meses de diciembre 2016, y enero 2017, que el responsable del proyecto no tiene cursada de posgrado, para avanzar lo más posible con el proyecto.

● Severidad (S): 9. No podrá cumplirse la fecha de entrega.

● Probabilidad de ocurrencia (O): 4. El responsable del proyecto quiere obtener el título de especialista en tiempo y forma con lo cual va a poner su mayor energía en los meses antes nombrados a fin de cumplir con los objetivos del proyecto.

Página 26 de 40


Ing. Fabrizio Gelsi

Página 27 de 40


Ing. Fabrizio Gelsi

13. Gestión de la calidad Para cada uno de los requerimientos del proyecto indique:

1. Variables a sensar 1.1. Se deberá utilizar un sensor de temperatura resistente al agua.

■ Verificación: Al momento de selección del componente, se seleccionará uno que cumpla con la especificación descripta.

■ Validación: Una vez adquirido el sensor y desarrollado el driver para utilizarlo, se compararán las medidas provistas por el mismo contra las dadas por un termómetro de uso cotidiano.

1.2. Se deberá utilizar un sensor de pH. ■ Verificación: Al momento de selección del componente, se seleccionará uno

que cumpla con la especificación descripta. ■ Validación: Una vez adquirido el sensor y desarrollado el driver para

utilizarlo, se compararán las medidas provistas por el mismo contra las dadas por un medidor de pH cotidiano.

1.3. Se deberá utilizar un sensor de nivel de cloro. ■ Verificación: Al momento de selección del componente, se seleccionará uno


utilizarlo, será utilizado para medir niveles de cloro en agua que contenga diferente nivel de cloro, una de otra cada muestra.

1.4. Se deberá utilizar un sensor de salinidad. ■ Verificación: Al momento de selección del componente, se seleccionará uno


utilizarlo, será utilizado para medir niveles de salinidad en agua que contenga diferente nivel de salinidad, una de otra cada muestra.

1.5. Se deberá utilizar un sensor de sólidos disueltos. ■ Verificación: Al momento de selección del componente, se seleccionará uno


utilizarlo, será utilizado para medir niveles de sólidos disueltos en agua que contenga diferente nivel de sólidos disueltos, una de otra cada muestra.

1.6. Todos los sensores antes mencionados deben presentar un grado de protección IP66 como mínimo.

■ Verificación: Revisar la hoja de datos de cada componente y corrobar que el fabricante explicite que el sensor provee un grado de protección IP66.

■ Validación: Cada componente será sometido a chorros de agua y sumergidos, verificando que sigan funcionando correctamente.

2. Comunicaciones

Página 28 de 40


Ing. Fabrizio Gelsi

2.1. La comunicación entre el prototipo y el Servidor o la aplicación móvil, será vía bluetooth.

■ Verificación: Se seleccionará un módulo de comunicación bluetooth. ■ Validación: Una vez adquirido el módulo, se desarrollará lo básico para

hacer una prueba de comunicación con el mismo. 3. Características del sistema

3.1. Se utilizará el microcontrolador ATMEL XMEGA (ATXMEGA16A4 o ATxMEGA64A3). ■ Verificación: Se verá que el esquemático del microcontrolador corresponda

con el deseado. ■ Validación: Se verá que se esté utilizando en el prototipo el

microcontrolador según se especificó. 3.2. El sistema debe contar con una batería de alimentación para su funcionamiento.

■ Verificación: Se determinará cuánta energía consume el sistema, y en base a esto se seleccionará una fuente que satisfaga la condición.

■ Validación: Se dejará el dispositivo encendido y se observará que se mantenga encendido.

3.3. El sistema debe contar con una celda solar para tener la posibilidad de recargar la batería mencionada en 3.2.

■ Verificación: Se calculará qué celda solar es necesaria para recargar la batería mencionada en 3.2.

■ Validación: Se dejará la batería conectada a la celda solar, y esto se lo dejará al sol verificando que la fuente se recarga.

3.4. La batería mencionada en 1.1 también podrá cargarse mediante la conexión a la red eléctrica.

■ Verificación: Se seleccionará una batería que pueda cargarse mediante la red eléctrica.

■ Validación: Se conectará la batería a la red eléctrica y se verificará que se carga.

3.5. El sistema debe contar con 2 módulos Bluetooth. ■ Verificación: Se realizará la compra de 2 módulos Bluetooth. ■ Validación: Se observará que llegaron los 2 módulos Bluetooth.

3.6. Se deberá tener una central (Servidor) que almacene los datos sensados por el sistema.

■ Verificación: Se diseñará cómo será la central que va a almacenar los datos. ■ Validación: Se enviarán datos desde el módulo de sensado, y serán enviados

a la centra. Se observará si los mismos fueron almacenados en la centra. 4. Software

4.1. Se contará con una aplicación móvil que permita visualizar los datos adquiridos por el sistema embebido.

■ Verificación: Se diseñará cómo serán visualizados los datos en la aplicación móvil y cuáles datos serán mostrados.

Página 29 de 40


Ing. Fabrizio Gelsi

■ Validación: Se solicitarán datos, desde la aplicación móvil, al módulo de sensado y se observará cómo son mostrados.

4.2. Se deberá mostrar los datos adquiridos mediante la plataforma Web iDAT de ComSi.

■ Verificación: Se mostrarán datos de prueba en la plataforma Web iDAT de ComSi.

■ Validación: Se mostrarán los datos que se almacenaron en 3.6, mediante la plataforma Web iDAT de ComSi.

5. Ambiente 5.1. El sistema deberá operar correctamente en un rango de temperatura entre 0°C y

60°C. ■ Verificación: Se realizará un prototipo y será sometidos a esas temperaturas

observando que funciona. ■ Validación: El sistema final será sometido a esas temperaturas, observando

que siga funcionando. 6. Funcionamiento del sistema embebido:

6.1. El sistema permitirá 2 formas de funcionamiento: Automática y Manual.

En el modo automático, el sistema adquirirá todos los datos detallados anteriormente en Requerimiento 1, de manera periódica y los enviará a la estación central a travé del módulo de comunicaciones.

■ Verificación: Se calculará el período que mejor se adecue a las necesidades del usuario final sin impactar negativamente en el consumo

■ Validación: Se realizará una medición de tiempos una vez que el sistema se encuentre funcionando en totalidad

El período de adquisición de datos podrá ser seteado por el usuario de una lista de selección posible.

■ Verificación: Se definirán los distintos períodos de elección posibles. ■ Validación: Seleccionar los diferentes períodos posibles y observar que el

sistema funcione con normalidad.

En el modo manual, la adquisición de datos se hace cuando el usuario la solicita mediante la aplicación móvil.

■ Verificación: Se definirá que en modo manual, no hay período de adquisición de datos.

■ Validación: Se observará que en modo manual no se almacenen datos en la central.

Mientras el sistema no se encuentra adquiriendo datos, se encontrará en modo de bajo consumo.

Página 30 de 40


Ing. Fabrizio Gelsi

■ Verificación: Se diseñará el sistema para que entre en modo bajo consumo cuando no está adquiriendo datos. Se realizará un cálculo estimativo del consumo que tendrá el sistema.

■ Validación: Se observará que cuando no se están adquiriendo datos, se este en modo bajo consumo. Se medirá el consumo eléctrico una vez que el sistema se encuentre en funcionamiento.

6.2. El Servidor debe dar alertas por límites de las variables sensadas, desconexión con el sistema de sensado, o baja batería en el sistema de sensado.

■ Verificación: Se diseñará el sistema de modo tal que cuente con dichas alertas.

■ Validación: Se generarán las posibles situaciones que desatan alertas, y se observará que las mismas se generen correctamente.

6.3. El sistema debe poder alertar también de manera propia que la batería se está agotando. A determinar si es una alerta sonora o lumínica.

■ Verificación: Se diseñará el sistema de modo tal que cuente con dicha alerta. ■ Validación: Se generará la posible situación, y se observará que la alerta se

genere. 7. Documentación

7.1. Se deberá utilizar una herramienta de generación automática de documentación. ■ Verificación: Se configurará la herramienta de generación de documentación

automática. ■ Validación: Se chequeará que la documentación se haya realizado, luego de

hacer un código que contenga posibilidad de documentación.

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

Análisis de los posibles dispositivos

Sergio Vicente Marcelo Moreno

Elegir los dispositivos que

serán comprados

para la realización del

proyecto

Antes de comenzar el

proyecto

Reunión vía Skype + Correo

electrónico

Fabrizio Gelsi

Avance en la

Sergio Vicente Informar sobre las tareas que

Cada semana

Reunión vía Skype +

Fabrizio Gelsi

Página 31 de 40


Ing. Fabrizio Gelsi

implementación de los

drivers

Marcelo Moreno

se van haciendo, y

redefinir siempre los

lineamientos a seguir en caso

de que se modifiquen

Correo electrónico

Finalización del informe de avance

Sergio Vicente Avisar que se va a presentar el informe de

avance

Antes de mostrar el informe al

jurado

Correo electrónico

Fabrizio Gelsi

Avance en el desarrollo

de codificación

Sergio Vicente Marcelo Moreno

Informar sobre las tareas que

se van haciendo

Cada semana Reunión vía Skype + Correo

electrónico

Fabrizio Gelsi

Finalización de

codificación e inicio de

testeo

Sergio Vicente Informar el avance del proyecto

Al finalizar la etapa de

codificación

Correo electrónico

Fabrizio Gelsi

Finalización del

proyecto

Sergio Vicente Informar que el sistema fue finalizado y

cumple con los requerimientos

solicitados

Al finalizar la etapa de

testeo

Reunión personal

Fabrizio Gelsi

15. Gestión de Compras La gestión de compras será llevada a cabo en su totalidad por ComSi S.A. con lo cual no aplica.

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.

Página 32 de 40


Ing. Fabrizio Gelsi

1.1

Relevar

informaci

ón de

empresas

que

ofrezcan

productos

similares

Cantidad de

empresas

relevadas

Sólo una vez Fabrizio Gelsi Sergio

Vicente

Correo

electrónico

1.2

Buscar

hoja de

datos de

los

compone

ntes

Cantidad de

hojas de datos

utilizadas

- - - -

1.3

Realizar

informe

de los

compone

ntes

Porcentaje de

componentes

informados


Vicente

Correo

electrónico

1.4

Realizar

informe

sobre

otras

empresas

Cantidad de

empresas

sobre las que

se informó


Vicente

Correo

electrónico

1.5

Estudiar

cómo

funciona

cada

compone

nte

Cantidad de

componentes

estudiados


Vicente

Correo

electrónico

Página 33 de 40


Ing. Fabrizio Gelsi

2.1

Seleccion

ar el

sensor de

temperat

ura

Cantidad de

sensores de

temperatura

estudiados


Vicente

Reunión vía

Skype

2.2

Seleccion

ar el

sensor de

pH

Cantidad de

sensores de

pH estudiados


Vicente

Reunión vía

Skype

2.3

Seleccion

ar el

sensor de

nivel de

cloro

Cantidad de

sensores de

nivel de cloro

estudiados


Vicente

Reunión vía

Skype

2.4

Seleccion

ar el

sensor de

salinidad

Cantidad de

sensores de

salinidad

estudiados


Vicente

Reunión vía

Skype

2.5

Seleccion

ar el

sensor de

sólidos

disueltos

Cantidad de

sensores de

sólidos

disueltos

estudiados


Vicente

Reunión vía

Skype

2.6

Seleccion

ar el

módulo

Bluetooth

Cantidad de

módulos

estudiados


Vicente

Reunión vía

Skype

Página 34 de 40


Ing. Fabrizio Gelsi

2.7

Seleccion

ar la

batería

Cantidad de

baterías

estudiadas


Vicente

Reunión vía

Skype

2.8

Seleccion

ar la

celda

solar

Cantidad de

celdas

estudiadas


Vicente

Reunión vía

Skype

3.1

Adquisici

ón de los

compone

ntes

Cantidad de

componentes

adquiridos


Vicente

Correo

electrónico

4.1

Familiariz

arse con

el

entorno

de

desarrollo

Cantidad de

proyectos y

pruebas

realizadas

- - - -

5.1

Implemen

tar driver

del

sensor de

temperat

ura

Cantidad de

drivers

implementado

s

Una vez por

semana

Fabrizio Gelsi Sergio

Vicente

Reunión vía

Skype

5.2

Implemen

tar driver

del

Cantidad de

drivers

implementado

s

Una vez por

semana


Vicente

Reunión vía

Skype

Página 35 de 40


Ing. Fabrizio Gelsi

sensor de

pH

5.3

Implemen

tar driver

del

sensor de

nivel de

cloro

Cantidad de

drivers

implementado

s

Una vez por

semana


Vicente

Reunión vía

Skype

5.4

Implemen

tar driver

del

sensor de

salinidad

Cantidad de

drivers

implementado

s

Una vez por

semana


Vicente

Reunión vía

Skype

5.5

Implemen

tar driver

del

sensor de

sólidos

disueltos

Cantidad de

drivers

implementado

s

Una vez por

semana


Vicente

Reunión vía

Skype

5.6

Implemen

tar los

driver de

los

módulos

de

comunica

ción

Cantidad de

drivers

implementado

s

Una vez por

semana


Vicente

Reunión vía

Skype

5.7

Pruebas

unitarias

Cantidad de

pruebas

Una vez por

semana


Vicente

Reunión vía

Skype

Página 36 de 40


Ing. Fabrizio Gelsi

de los

drivers

unitarias

realizadas

6.1

Desarroll

ar el

código

principal

Porcentaje de

requerimiento

s

implementado

s sobre el total

de

requerimiento

s a

implementar

Una vez por

semana


Vicente

Reunión vía

Skype

6.2

Desarroll

ar la

aplicación

móvil que

se

conecte

al sistema

Porcentaje de

requerimiento

s

implementado

s sobre el total

de

requerimiento

s a

implementar

Una vez por

semana


Vicente

Reunión vía

Skype

6.3

Realizar

el

hardware

necesario

para que

la batería

se cargue

mediante

la celda

solar

Cantidad de

hardware

realizado

sobre total de

hardware a

desarrollar

Una vez por

semana


Vicente

Reunión vía

Skype

6.4

Prueba

del

sistema

en su

conjunto

Cantidad de

requerimiento

s validados

por el código

ya

desarrollado

Una vez por

semana


Vicente

Reunión vía

Skype

Página 37 de 40


Ing. Fabrizio Gelsi

7.1

Encapsula

r el

sistema

de

sensado

en la

carcasa

provista

por

ComSi

S.A.

Haber logrado

encapsular el

sistema en la

carcasa

- - - -

8.1

Testear el

correcto

funciona

miento

del

dispositiv

o

Cantidad de

prueba de caja

negra y blanca

realizadas

Una vez por

semana


Vicente

Reunión

8.2

Testear el

correcto

funciona

miento

de la

aplicación

Cantidad de

prueba de caja

negra y blanca

realizadas

Una vez por

semana


Vicente

Reunión

8.3

Testear el

sistema

en su

conjunto

Cantidad de

prueba de caja

negra y blanca

realizadas

Una vez por

semana


Vicente

Reunión

8.4

Evaluar el

cumplimi

ento de

Cantidad de

requerimiento

s cumplidos

sobre el total

Una vez por

semana


Vicente

Reunión vía

Skype

Página 38 de 40


Ing. Fabrizio Gelsi

los

requerimi

entos

de

requerimiento

s del sistema

9.1

Realizar

el

informe

de avance

Cantidad de

hojas escritas


Vicente

Correo

electrónico

9.2

Realizar

el Manual

de

usuario

Cantidad de

hojas escritas

Una vez por

semana


Vicente

Correo

electrónico

9.3

Realizar

el Manual

de

instalació

n

Cantidad de

hojas escritas

Una vez por

semana


Vicente

Correo

electrónico

9.4

Realizar

el

informe

final

Cantidad de

hojas escritas


Vicente

Correo

electrónico

9.5

Realizar

presentac

ión para

exposició

n del

proyecto

- - - - -

17. Procesos de cierre

Página 39 de 40


Ing. Fabrizio Gelsi

Una vez finalizado el proyecto, el responsable del mismo se encargará de analizar los resultados de las

distintas fases del proyecto y el resultado final con el fin de establecer si se respetó el Plan de Proyecto

y en qué grado. Analizar además si se respetaron los cronogramas establecidos en el inicio del

proyecto, los recursos y riesgos, se dejará detallado en un documento paralelo qué partes se

cumplieron, y las que no se cumplieron, por qué fue que no se cumplieron, con el objetivo de mejorar

esto en el futuro proyecto.

Por otra parte el análisis de si las técnicas y procedimientos aplicados fueron útiles o inútiles, será tarea

del responsable del proyecto. Con esto se busca determinar qué métodos son útiles aplicar para futuros

proyectos, y cuáles no. Para el caso de técnicas que no sirvieron, se dejarán planteadas alternativas

posibles.

Como conmemoración de finalización del proyecto, se realizará un almuerzo con todos los involucrados

del proyecto a modo de agradecimiento y para compartir un momento más allá de lo laboral, el mismo

será costeado por el responsable del proyecto.

Página 40 de 40

Sistema de monitoreo de estado del agua de una...

Documents

Transcript of Sistema de monitoreo de estado del agua de una...