You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
349 lines
36 KiB
Markdown
349 lines
36 KiB
Markdown
---
|
|
tags:
|
|
- Gestión_de_Proyectos
|
|
---
|
|
El ejemplo en el que se basa este informe se puede ver en el siguiente PDF: [[Template_Gestion_Proyectos_TC024_v2_2.pdf]]
|
|
|
|
## 1. Introducción
|
|
|
|
El monitoreo del sueño en bebés suele realizarse con tecnologías que requieren contacto físico directo, como sensores adheridos a la piel o bandas ajustadas al cuerpo. Este tipo de soluciones, si bien útiles en ciertos contextos clínicos, resultan invasivas y poco adecuadas para un monitoreo continuo en el tiempo. Su aplicación puede generar molestias, interferir con el descanso natural del bebé e incluso alterar las condiciones que se desean observar.
|
|
|
|
Este proyecto busca desarrollar una alternativa no invasiva basada en tecnología de radar UWB (Ultra Wideband), capaz de captar señales relacionadas con la respiración y la actividad cardíaca del bebé sin necesidad de contacto físico. El sistema está diseñado para recopilar datos de forma continua mientras el bebé duerme, con el objetivo de generar reportes periódicos sobre su estado fisiológico, sin interrumpir el descanso.
|
|
|
|
El producto está orientado al uso doméstico por familias que deseen contar con una herramienta accesible para observar cómo evoluciona la actividad fisiológica del bebé en su día a día, sin depender exclusivamente de intervenciones médicas. No se trata de un sistema de monitoreo en tiempo real ni de control activo, sino de una solución pensada para el análisis y la observación periódica, desde una perspectiva preventiva.
|
|
|
|
El objetivo de este proyecto es construir un **mínimo producto viable (MVP)** que integre el radar UWB, el hardware de procesamiento, los algoritmos de análisis de señal, y una interfaz de consulta digital. Este MVP permitirá validar el funcionamiento del sistema en condiciones reales y sentar las bases para futuras iteraciones del producto.
|
|
## 2. Definición del proyecto
|
|
|
|
El proyecto consiste en el desarrollo de un sistema electrónico no invasivo destinado al monitoreo de funciones vitales —frecuencia respiratoria y cardíaca— en bebés durante el sueño, utilizando tecnología de radar UWB. El producto está concebido como una solución integrada, pensada para funcionar en el hogar, de manera continua y con una experiencia de usuario simple y segura.
|
|
|
|
Este artefacto está diseñado para ser utilizado de forma cotidiana durante el sueño del bebé, recolectando datos de manera pasiva, sin contacto físico, y generando reportes periódicos que permitan observar su evolución fisiológica a lo largo del tiempo.
|
|
|
|
El sistema se compone de los siguientes bloques principales:
|
|
|
|
- **Hardware integrado:** constituye el cuerpo principal del dispositivo y está compuesto por un módulo de radar UWB encargado de adquirir las señales fisiológicas, junto con una unidad de control capaz de mostrar opciones al usuario mediante una interfaz local. Este bloque también permite transmitir los datos recolectados hacia un servidor remoto o estructura externa para su posterior análisis.
|
|
|
|
- **Procesamiento de señales:** abarca el diseño del método que permite extraer parámetros fisiológicos relevantes a partir de las señales captadas por el radar, así como la implementación del algoritmo correspondiente. Este procesamiento debe ser robusto frente a ruido e interferencias, y capaz de tolerar movimientos involuntarios típicos del sueño.
|
|
|
|
- **Servidor remoto e interfaz de usuario:** este bloque comprende tanto la infraestructura en la nube encargada de recibir, almacenar y procesar los datos enviados por el dispositivo, como la plataforma digital —web o móvil— desde la cual los cuidadores pueden acceder a los reportes generados, visualizar historiales y configurar notificaciones. Este componente articula la comunicación entre el sistema y el usuario final, y constituye la vía principal para consultar la información recolectada.
|
|
|
|
La integración de estos bloques permitirá construir un sistema funcional, evaluable en condiciones reales de uso, y alineado con las necesidades del entorno familiar.
|
|
|
|
### 2.1. Objetivos
|
|
|
|
El objetivo principal es construir un mínimo producto viable (MVP) que integre un conjunto de componentes electrónicos y de software capaces de cumplir esa función en condiciones reales de uso. Este MVP deberá permitir validar la viabilidad técnica, operativa y de experiencia de usuario del sistema, sentando las bases para futuras iteraciones del producto.
|
|
|
|
El sistema estará compuesto por los siguientes módulos funcionales:
|
|
|
|
- **Un módulo de captura con radar UWB:** encargado de adquirir una señal única relacionada con las microvariaciones del cuerpo del bebé provocadas por la respiración y la actividad cardíaca, utilizando tecnología de radar UWB. Esta señal será utilizada como base para el análisis posterior.
|
|
|
|
- **Un método de procesamiento de señales:** estudio y desarrollo de un método que permita extraer parámetros fisiológicos relevantes a partir de la señal adquirida, junto con la implementación de un algoritmo capaz de manejar ruido, interferencias y movimientos involuntarios leves o moderados del bebé.
|
|
|
|
- **Una unidad de control del sistema:** componente central que coordina el funcionamiento general del dispositivo, administra el flujo de datos entre módulos y garantiza la operación conjunta del sistema.
|
|
|
|
- **Una interfaz embebida de usuario:** compuesta por una pantalla y botones físicos que permitan la configuración del sistema, el inicio o detención del monitoreo y la visualización básica del estado del dispositivo.
|
|
|
|
- **Un módulo de conectividad Wi-Fi:** encargado de la transmisión automática y segura de los datos procesados hacia un servidor remoto, incluyendo el manejo de interrupciones de red.
|
|
|
|
- **Un servidor en la nube:** infraestructura encargada de recibir, almacenar y procesar los datos enviados desde los dispositivos, con el objetivo de generar reportes e historiales fisiológicos.
|
|
|
|
- **Una plataforma web o móvil :** interfaz desde la cual los cuidadores pueden consultar los reportes generados, acceder al historial de mediciones y recibir alertas configurables.
|
|
|
|
- **Un gabinete del dispositivo:** estructura externa del sistema que protege los componentes electrónicos, permite una manipulación segura y está adaptada a su uso en un entorno doméstico.
|
|
|
|
Además de estos componentes, el proyecto requiere completar los siguientes procesos de desarrollo clave:
|
|
|
|
- **Estudio para la generación de mediciones reales:** incluye la recolección de señales reales de sujetos de prueba usando el módulo de medición desarrollado, así como la adquisición de datos complementarios mediante métodos tradicionales u otros medios disponibles. Este proceso tendrá como resultado el banco de mediciones reales y la generación de un patrón de referencia que será utilizado para la validación del método de procesamiento.
|
|
|
|
- **Estudio de condiciones de uso y despliegue:** análisis de las situaciones en las que el dispositivo será utilizado, con el objetivo de diseñar un gabinete adecuado y definir las formas de instalación, soporte o integración del producto en su entorno final.
|
|
|
|
El alcance del proyecto incluye el diseño, implementación e integración de todos estos módulos, así como su validación en condiciones representativas de uso. El objetivo es lograr un sistema mínimamente viable (MVP), funcional de extremo a extremo, que permita comprobar la viabilidad técnica y de experiencia de usuario del monitoreo remoto no invasivo en el hogar.
|
|
|
|
|
|
### 2.2. Misión y Visión
|
|
|
|
**Misión**
|
|
Desarrollar un sistema tecnológico confiable, no invasivo y accesible para el entorno doméstico, que permita a las familias recopilar datos fisiológicos relevantes —como la frecuencia respiratoria y cardíaca— de sus bebés mientras duermen. El sistema procesará esa información para ofrecer reportes claros y útiles, orientados al seguimiento de la salud del bebé, sin interferir con su descanso ni requerir intervención médica directa.
|
|
|
|
**Visión**
|
|
Contribuir a resolver la falta de soluciones accesibles y no invasivas para el monitoreo de funciones vitales en bebés, brindando una herramienta que permita detectar de forma temprana posibles alteraciones durante el sueño. El proyecto busca facilitar un seguimiento cotidiano que complemente el control pediátrico tradicional, ayudando a reducir riesgos y mejorar el cuidado infantil desde el hogar o en contextos clínicos.
|
|
|
|
### 2.3. Entregables mensurables
|
|
|
|
El avance del proyecto se medirá a través de tres entregables principales, que representan hitos clave dentro del desarrollo:
|
|
|
|
- **Entregable 1: Módulo de medición construido y evaluación de costos**
|
|
Este entregable corresponde a la finalización del módulo de medición, lo que permite iniciar la generación de mediciones reales.
|
|
Además, debe realizarse una comparación entre el costo real de construcción del módulo y la estimación original.
|
|
- Si se detecta una desviación significativa en el presupuesto, deberá actualizarse el análisis de factibilidad económica del proyecto en función de los nuevos costos.
|
|
|
|
- **Entregable 2: Prototipo funcional de factibilidad técnica**
|
|
Este entregable implica la construcción de un prototipo que permita validar la viabilidad técnica del sistema. El prototipo debe:
|
|
- Adquirir señales fisiológicas reales de una persona.
|
|
- Transmitir los datos a una computadora mediante conexión Wi-Fi, sin necesidad de un servidor.
|
|
- Incluir una interfaz embebida básica para interactuar con el sistema.
|
|
|
|
- **Entregable 3: Mínimo producto viable (MVP) finalizado**
|
|
Este entregable representa la integración completa de todos los componentes del sistema, en una versión funcional y coherente. El MVP debe incluir:
|
|
- Hardware completo y ensamblado, con el radar integrado.
|
|
- Método de procesamiento de señales operativo.
|
|
- Interfaz de usuario embebida.
|
|
- Servidor remoto configurado y funcional.
|
|
- Aplicación web o móvil accesible para los usuarios.
|
|
- Estructura física (gabinete) lista para uso final.
|
|
|
|
Este entregable representa una versión lista para validación final o para un posible despliegue inicial en contexto real.
|
|
## 3. Evaluación del proyecto
|
|
|
|
### 3.1. Tipo de proyecto
|
|
|
|
### 3.2. Evaluación de factibilidad técnica
|
|
#### 3.2.1. Requerimientos técnicos
|
|
|
|
Los requerimientos técnicos abarcan tanto el hardware como el software necesario para el correcto funcionamiento del sistema. A continuación, se detallan los requisitos para cada uno de los componentes clave.
|
|
|
|
1. **Requerimientos del Hardware:**
|
|
- **Módulo de medición (Radar UWB)**:
|
|
El módulo de medición debe ser capaz de utilizar señales de radar UWB para medir las variables deseadas. Debe tener la capacidad de modular y demodular estas señales, así como muestrear la señal con precisión. Además, debe poder comunicarse con el centro de control para transmitir los datos obtenidos.
|
|
|
|
- **Módulo central de control**:
|
|
El módulo central debe ser capaz de manejar los periféricos conectados, tales como el display, el periférico de comunicación Wi-Fi y el periférico de medición. Este módulo debe garantizar la recuperación de todos los datos generados por el módulo de medición sin pérdida de información, volcando estos datos al módulo Wi-Fi para su transmisión al servidor a través de la red Wi-Fi sin pérdida de datos. La tasa de datos del radar es de aproximadamente **1 megabyte por segundo**, por lo que el módulo de control debe ser capaz de manejar esta cantidad de datos sin comprometer la integridad de la transmisión.
|
|
|
|
- **Requisitos de conectividad Wi-Fi**:
|
|
El módulo Wi-Fi debe ser capaz de conectarse a Internet y manejar un tránsito de datos de aproximadamente 1 megabyte por segundo sin pérdidas. También debe ser capaz de reconectarse automáticamente en caso de fluctuaciones o pérdida de conexión de la señal Wi-Fi.
|
|
|
|
2. **Requerimientos del Software:**
|
|
- El software debe ser capaz de procesar la señal cruda obtenida por el radar, realizar un análisis adecuado y extraer la **frecuencia cardíaca** y la **frecuencia respiratoria** del bebé, lidiando con el ruido presente en la señal.
|
|
|
|
- **Mitigación de movimientos**:
|
|
El software debe ser capaz de identificar y manejar los movimientos del bebé durante la medición. Debe poder filtrar los espasmos y movimientos más pequeños, descartando segmentos de datos no tan significativos sin perder precisión en las estimaciones. Para movimientos más grandes, como cambios de posición, el software debe continuar con la medición y registrar cualquier evento relevante que haya ocurrido.
|
|
|
|
3. **Requerimientos del Servidor:**
|
|
- El servidor debe ser capaz de recibir datos de múltiples usuarios simultáneamente. Debe ser diseñado de manera escalable para manejar el aumento en la cantidad de usuarios y datos sin afectar el rendimiento.
|
|
|
|
- El servidor debe procesar los datos obtenidos y generar un informe de los resultados, proporcionando un **pseudo diagnóstico** que brinde información básica sobre el comportamiento del bebé durante la noche.
|
|
|
|
4. **Requerimientos de la Aplicación de Usuario:**
|
|
- La aplicación debe ofrecer varias formas de contacto con la empresa proveedora del servicio para recibir soporte técnico.
|
|
|
|
- Debe tener un **historial** de las mediciones realizadas en diferentes días, permitiendo al usuario consultar resultados previos.
|
|
|
|
- La aplicación debe contar con un sistema de **notificación** que informe al usuario sobre el diagnóstico generado después de cada medición nocturna.
|
|
|
|
#### 3.2.2. Diseño preliminar
|
|
|
|
El diseño preliminar del producto abarca tres áreas fundamentales que aseguran su correcto funcionamiento: el hardware, el algoritmo de procesamiento de datos y la interacción del usuario a través del servidor y la aplicación. A continuación, se detallan los componentes y el flujo de trabajo propuestos para cada una de estas áreas.
|
|
|
|
1. **Diseño del Hardware:**
|
|
- **Módulo de radar DWM1000**: Emite y recibe ondas electromagnéticas para medir variaciones y extraer los datos necesarios.
|
|
- **Raspberry Pi Pico**: Controla los periféricos y gestiona la conectividad Wi-Fi, además de procesar los datos y asegurar la comunicación.
|
|
- **Display con cuatro botones**: Permite la interacción local con el sistema, visualizando los datos y realizando ajustes básicos.
|
|
- **Fuente de alimentación**: Suministra energía a los componentes, principalmente al Raspberry Pi Pico y otros módulos conectados.
|
|
|
|
2. **Diseño del Software (Algoritmo de Procesamiento de Datos):**
|
|
- **Análisis espectral**: Utilizado para estimar la **frecuencia respiratoria** a partir de los datos obtenidos por el radar.
|
|
- **Análisis de formas de onda**: Permite identificar los patrones del ritmo cardíaco, detectando los cuatro ciclos principales presentes en la señal.
|
|
|
|
3. **Diseño del Servidor y la Aplicación de Usuario:**
|
|
- **Servidor**: Se encarga de recibir los datos del dispositivo, procesar las señales y generar alertas automáticas para los usuarios si los parámetros monitoreados exceden los límites establecidos.
|
|
- **Aplicación de usuario**: Permite la interacción con el sistema, ofreciendo una interfaz para consultar los datos, recibir notificaciones y revisar el historial de mediciones.
|
|
#### 3.2.3. Inventario de los diferentes aspectos a cubrir
|
|
|
|
Para evaluar la factibilidad técnica del proyecto, se identifican los principales componentes y áreas de desarrollo que deben ser abordadas. Estos se agrupan en los siguientes bloques:
|
|
|
|
**Hardware del dispositivo**
|
|
|
|
- Radar UWB para medición: selección y configuración de un sensor capaz de registrar señales respiratorias y cardíacas de forma no invasiva, con robustez ante ruido y variabilidad del entorno.
|
|
- Unidad de procesamiento (Raspberry Pi): integración de una unidad capaz de coordinar la adquisición de datos, controlar periféricos y gestionar la operación del sistema.
|
|
- Pantalla y botones: incorporación de una interfaz embebida que permita navegación simple por menús y visualización de estados del dispositivo.
|
|
- Sistema de alimentación: diseño de una solución estable, segura y adecuada para uso continuo en un entorno doméstico.
|
|
|
|
**Software embebido**
|
|
|
|
- Control de periféricos: rutinas de bajo nivel para gestionar sensores, pantalla, botones y comunicación.
|
|
- Envío de datos al servidor: implementación de un sistema confiable para transferencia de información hacia la nube.
|
|
- Configuración de red Wi-Fi del usuario: desarrollo de un mecanismo simple y seguro para vincular el dispositivo con la red doméstica.
|
|
- Gestión del sistema (máquina de estados): estructura lógica que permita escalar el software, navegar entre modos de operación y mantener estabilidad del sistema.
|
|
|
|
**Diseño físico del gabinete**
|
|
|
|
- Estudio de estabilidad y colocación: análisis del comportamiento del producto en diferentes ubicaciones dentro del hogar, para asegurar un funcionamiento correcto.
|
|
- Desarrollo del gabinete físico: diseño de una carcasa resistente a condiciones comunes (polvo, humedad), fácil de ensamblar, reparar y mantener en el tiempo.
|
|
|
|
**Infraestructura del servidor**
|
|
|
|
- Comunicación con los dispositivos cliente: desarrollo de canales estables, seguros y escalables para recibir datos desde los dispositivos instalados.
|
|
- Procesamiento de señales remoto: implementación del algoritmo de análisis sobre los datos enviados desde el hardware.
|
|
- Generación de alertas y notificaciones: sistema que permita informar a los usuarios ante eventos o situaciones relevantes.
|
|
- Diseño escalable: arquitectura orientada a permitir el crecimiento progresivo del sistema sin comprometer su estabilidad.
|
|
|
|
**Aplicación para el usuario**
|
|
|
|
- Canal de comunicación con el proveedor: espacio dentro de la app donde el usuario pueda contactarse directamente para soporte o consultas.
|
|
- Seguridad de la aplicación: autenticación de usuarios, manejo de datos sensibles y protección frente a accesos no autorizados.
|
|
- Sincronización con el servidor: integración fluida entre la app y el backend para consultar información en tiempo real o diferido.
|
|
|
|
**Organización interna para operación continua**
|
|
|
|
- Área de producción: fabricación, ensamblaje y control de calidad de unidades nuevas.
|
|
- Área de ventas: promoción, comercialización y atención pre-venta.
|
|
- Área de atención y soporte técnico al cliente: resolución de consultas, problemas o incidencias durante el uso del producto.
|
|
- Área de mantenimiento y reacondicionamiento: gestión de stock, reparación de equipos devueltos y control logístico de componentes.
|
|
- Área de operación del servidor y la app: monitoreo, mantenimiento y actualización continua de las plataformas digitales.
|
|
- Área de desarrollo técnico: evolución del hardware y software del sistema, investigación de nuevas funcionalidades y mejoras.
|
|
### 3.3. Evaluación de factibilidad de negocios
|
|
|
|
A continuación se desarrolla un análisis de fortalezas, oportunidades, debilidades y amenazas vinculadas al desarrollo y despliegue del proyecto.
|
|
#### 3.3.1. Análisis FODA
|
|
##### 3.3.1.1. Fortalezas
|
|
|
|
- **Vínculo con un instituto de investigación especializado**: Existe un contacto activo con una institución que investiga las tecnologías involucradas, lo que aporta respaldo técnico y acceso a conocimiento actualizado.
|
|
- **Base técnica sólida del equipo**: El equipo cuenta con formación en electrónica, software y procesamiento de señales, lo que permite abordar internamente los principales desafíos tecnológicos.
|
|
- **Bajo costo del diseño de hardware**: El diseño inicial proyecta un costo reducido para los componentes, permitiendo desarrollar el MVP con recursos moderados.
|
|
- **Escalabilidad del producto**: La solución es adaptable para nuevas funcionalidades, como la detección de distintas patologías, lo que habilita la expansión a otros nichos de mercado en el futuro.
|
|
- **Control de desarrollo in-house**: Al ser un desarrollo propio, se puede iterar rápidamente sin depender de terceros o licencias de software/hardware externas.
|
|
- **Alta diferenciación funcional**: El enfoque no invasivo para monitoreo vital en bebés es único dentro del segmento doméstico, lo que otorga una ventaja clara frente a otros productos.
|
|
|
|
##### 3.3.1.2. Oportunidades
|
|
|
|
- **Tecnología UWB segura y aprobada**: El uso de radar UWB ya está regulado y validado para entornos humanos, facilitando su homologación médica.
|
|
- **Falta de dispositivos similares en el mercado**: Actualmente no existen productos que monitoreen ritmo respiratorio y cardíaco en bebés de forma no invasiva, lo que representa una oportunidad de innovación.
|
|
- **Tendencia en crecimiento del interés por UWB**: La tecnología está en expansión en distintas aplicaciones, y su adopción genera un entorno favorable para el desarrollo de productos basados en ella.
|
|
- **Envejecimiento de otras tecnologías en uso**: Muchos monitores actuales se basan en sensores de contacto o bandas físicas, tecnologías que presentan limitaciones frente a la propuesta UWB.
|
|
- **Potencial interés de organismos de salud**: Si se demuestra precisión y utilidad clínica, el producto podría interesar a hospitales, neonatologías y programas de salud pública.
|
|
- **Acceso a subsidios y programas de innovación**: El carácter tecnológico y biomédico del proyecto podría hacerlo elegible para fondos públicos o privados de I+D.
|
|
|
|
##### 3.3.1.3. Debilidades
|
|
|
|
- **Falta de perfiles técnicos clave**: El equipo actual no cuenta con especialistas en desarrollo de servidores, aplicaciones móviles ni asesoramiento médico.
|
|
- **Ausencia de colaboración con equipos médicos**: No existen vínculos establecidos con instituciones o profesionales médicos que puedan validar o mejorar el enfoque clínico del producto.
|
|
- **Poca experiencia en desarrollo de productos**: El equipo no cuenta con antecedentes en el diseño, testeo y despliegue de prototipos o MVPs para el mercado.
|
|
- **Falta de financiación asegurada**: Actualmente no se dispone de los fondos necesarios para llevar a cabo el desarrollo completo del sistema.
|
|
- **Proceso regulatorio incierto**: Aunque la tecnología UWB esté aprobada, la certificación del dispositivo completo puede requerir conocimientos y procesos complejos.
|
|
- **Limitada experiencia en diseño industrial**: El diseño físico del gabinete puede presentar dificultades si no se cuenta con especialistas en producto o ergonomía.
|
|
|
|
##### 3.3.1.4. Amenazas
|
|
|
|
- **Competencia indirecta en el mercado de monitoreo infantil**: Existen múltiples productos que, aunque no miden los mismos parámetros, podrían ser percibidos como soluciones alternativas.
|
|
- **Condiciones económicas desfavorables**: El producto podría ser considerado de nicho o de lujo, lo que limitaría su adopción en contextos de baja capacidad adquisitiva o crisis económica.
|
|
- **Barrera regulatoria y legal**: El proceso de homologación para uso médico puede extenderse, complejizarse o implicar altos costos.
|
|
- **Aceleración de competidores tecnológicos**: Empresas con mayor capital podrían lanzar productos similares más rápido, con más marketing o distribución.
|
|
- **Preocupaciones sobre privacidad de datos**: La gestión de datos fisiológicos sensibles puede generar desconfianza si no se comunica claramente la política de privacidad y seguridad.
|
|
- **Riesgos de obsolescencia rápida**: Si no se actualiza el producto con nuevas funcionalidades, podría ser superado tecnológicamente en poco tiempo.
|
|
### 3.4. Análisis de mercado y financiero
|
|
|
|
#### 3.4.1. Análisis de mercado y publico objetivo
|
|
|
|
El público objetivo de este producto son padres de bebés recién nacidos que desean contar con una herramienta tecnológica para el monitoreo del estado de salud de sus hijos mientras duermen. A diferencia de otros sistemas que requieren atención constante por parte de los cuidadores, este dispositivo está pensado para funcionar de manera autónoma, permitiendo que los padres reciban información relevante, sin la necesidad de estar monitoreando activamente al bebé en todo momento. Esto lo convierte en una solución ideal para familias que buscan tranquilidad y seguridad durante el sueño del bebé, sin sobrecargar su rutina con vigilancia permanente.
|
|
|
|
Se realizó un análisis de mercado para identificar el público potencial del producto, evaluando la demanda estimada y los factores que pueden influir en su adopción. Inicialmente, se analizó la competencia existente en el mercado, considerando productos con funciones relacionadas al monitoreo infantil como los baby calls (intercomunicadores de bebés) y las cámaras de monitoreo. Aunque estos dispositivos no cumplen exactamente las mismas funciones que el producto propuesto, podrían ser percibidos por los usuarios como soluciones alternativas. El objetivo de este análisis fue estimar la cantidad de ventas mensuales de estos productos para tener una referencia sobre el tamaño del mercado activo. Sin embargo, no fue posible obtener cifras públicas de ventas debido a la falta de datos oficiales disponibles, lo que limitó esta vía de análisis.
|
|
|
|
Frente a esta limitación, se optó por realizar un análisis demográfico basado en la cantidad de nacimientos mensuales en la región del AMBA (Área Metropolitana de Buenos Aires), como una forma de estimar el mercado potencial de familias que podrían estar interesadas en adquirir el producto. Para obtener una visión más ajustada a la realidad socioeconómica del público objetivo, se filtraron los datos considerando únicamente los nacimientos en hospitales privados y aquellos cubiertos por obras sociales, dado que este grupo representa a las familias con mayor capacidad adquisitiva y mayor probabilidad de invertir en un sistema de monitoreo infantil avanzado.
|
|
|
|
De los datos recopilados, se obtuvo que en el AMBA nacen aproximadamente 22.000 bebés mensualmente. Cuando se limita el análisis a los nacimientos en hospitales privados y con cobertura de obra social, el número se reduce a alrededor de 9.500 nacimientos mensuales. Considerando estos datos, se puede estimar de forma conservadora que al menos la mitad de estas familias podría formar parte del mercado potencial de compradores del producto, lo que representa un universo significativo de usuarios posibles.
|
|
|
|
Este análisis permite concluir que la principal limitación del proyecto no radica en la cantidad de personas que podrían comprar el producto, sino en la capacidad de la organización para captar a esos clientes y, fundamentalmente, en la infraestructura técnica necesaria para brindar el servicio de forma continua y confiable. El reto principal será desarrollar una estrategia efectiva de llegada al cliente, así como tener la capacidad operativa de producción, despliegue y soporte técnico de la solución.
|
|
|
|
#### 3.4.2. Análisis de competidores y sustitutos
|
|
|
|
Las alternativas actuales disponibles en el mercado para el monitoreo domiciliario de bebés son las siguientes:
|
|
|
|
- Owlet Dream Sock: Es un dispositivo diseñado para monitorear de manera domiciliaria la frecuencia cardíaca y la oxigenación del bebé durante el sueño. Funciona a través de un sensor que se coloca en el pie y envía los datos a una aplicación móvil, donde los padres pueden visualizar el estado del bebé y recibir alertas ante posibles eventos anómalos. El costo es de entre 299 y 399 dólares.
|
|
- Cámaras de monitoreo para bebés (como Nanit Pro, Lollipop Cam, CuboAi): Son cámaras inteligentes que permiten ver y escuchar al bebé en tiempo real desde un teléfono móvil. Algunos modelos avanzados incorporan alertas de movimiento o patrones de respiración mediante análisis de imagen, pero no miden signos vitales reales. El costo de estos dispositivos va de 150 a 300 dólares.
|
|
- Baby Call (monitor de audio tradicional): Son dispositivos simples que transmiten audio desde la habitación del bebé. Algunos modelos también incluyen video, pero en general su función es escuchar al bebé mientras duerme. No brindan información sobre parámetros fisiológicos. El costo se encuentra entre 30 y 80 dólares.
|
|
- No hacer nada: Consiste en la supervisión tradicional de los padres sin utilizar tecnología adicional. No genera costos económicos, pero implica un mayor nivel de atención directa y no ofrece mecanismos de alerta automática ante eventos críticos.
|
|
|
|
#### 3.4.3. Análisis de proyecto similar
|
|
|
|
En esta sección se analiza un producto similar al desarrollado en este proyecto con el fin de identificar antecedentes relevantes, aprender de experiencias previas y entender posibles riesgos asociados a productos de características comparables. Este ejercicio permite obtener información sobre el mercado, las dificultades técnicas y los desafíos comerciales que pueden surgir en la implementación de soluciones similares.
|
|
|
|
Durante el análisis de competencia se identificó un producto comparable en concepto: el **Miku Pro Smart Baby Monitor**. Este dispositivo combinaba una cámara con un sistema de monitoreo no invasivo capaz de medir tanto la frecuencia cardíaca como la frecuencia respiratoria de los bebés mientras dormían. El monitoreo se realizaba en tiempo real y sin contacto físico con el niño, lo cual lo posicionaba como una tecnología avanzada dentro de su segmento.
|
|
|
|
Sin embargo, este producto fue retirado del mercado en 2023 tras la bancarrota de la empresa desarrolladora. Uno de los aspectos distintivos del Miku Pro era el uso de componentes de precisión militar para realizar el análisis de señales, lo cual si bien aportaba un alto nivel tecnológico, probablemente contribuyó a un costo excesivamente alto que pudo haber dificultado su comercialización masiva y sostenibilidad en el tiempo.
|
|
|
|
Este caso representa un ejemplo valioso de un producto similar al propuesto que no logró consolidarse en el mercado. Aunque el hecho de que un proyecto comparable haya fallado no es necesariamente una buena noticia, permite extraer aprendizajes sobre los riesgos de sobredimensionar el producto en términos de tecnología o costos, y pone en evidencia la importancia de lograr un equilibrio adecuado entre funcionalidad, precio y viabilidad comercial.
|
|
|
|
|
|
## 4. Planificación del proyecto
|
|
### 4.1. Plan de producto
|
|
|
|
El desarrollo del producto contempla distintas versiones evolutivas que permiten mejorar la propuesta de valor y aumentar la utilidad para los usuarios. Estas iteraciones permiten ampliar las funcionalidades del sistema, adaptarse a nuevas necesidades y ofrecer un producto competitivo frente a otras soluciones del mercado.
|
|
|
|
A continuación se detallan posibles caminos de evolución del producto.
|
|
|
|
#### 4.1.1. Integración de función de Baby Calling
|
|
|
|
Uno de los productos con los que compite indirectamente esta solución es el baby call o intercomunicador de bebés, un dispositivo cuya función principal es transmitir audio desde la habitación del bebé hacia los padres o cuidadores.
|
|
|
|
Una posible evolución del sistema actual es incorporar esta funcionalidad, añadiendo un **micrófono al dispositivo y permitiendo la transmisión de audio en tiempo real a través de la aplicación del usuario**.
|
|
|
|
Esta mejora implicaría:
|
|
|
|
- Una actualización del hardware con la incorporación de un módulo de captura de audio.
|
|
- Una actualización de la aplicación para integrar la función de escucha remota.
|
|
- Un agregado de valor importante, ya que el usuario podría tener en un solo dispositivo tanto el monitoreo vital como el monitoreo sonoro.
|
|
|
|
#### 4.1.2. Detección de problemas en tiempo real
|
|
|
|
Una segunda evolución significativa consiste en desarrollar la capacidad de **detectar eventos críticos de salud en tiempo real**. Actualmente, el sistema está pensado para procesar datos y reportar información acumulada; sin embargo, podría evolucionar hacia un sistema de alerta inmediata.
|
|
|
|
Esto permitiría identificar eventos como:
|
|
|
|
- Apneas
|
|
- Episodios de asma
|
|
- Alteraciones en la frecuencia respiratoria o cardíaca durante el sueño
|
|
|
|
Esta mejora implicaría:
|
|
|
|
- Desarrollar algoritmos más complejos de procesamiento de señales en tiempo real.
|
|
- Optimizar el flujo de comunicación para generar alertas inmediatas al usuario.
|
|
- Integrar un sistema de notificaciones críticas a través de la app.
|
|
|
|
#### 4.1.3. Incorporación de monitoreo por cámara
|
|
|
|
Otra versión evolutiva posible es **la incorporación de un sistema de video**, sumando al hardware una cámara que permita al usuario visualizar al bebé en todo momento.
|
|
|
|
Esto permitiría:
|
|
|
|
- Monitoreo visual complementario al monitoreo vital.
|
|
- Integración en la aplicación móvil de una interfaz para transmisión y visualización de video en vivo.
|
|
|
|
Esta evolución acercaría al producto a una solución integral de monitoreo, ofreciendo múltiples canales de información para el usuario (vitales + sonido + imagen).
|
|
### 4.2. Organización del proyecto
|
|
|
|
La organización del proyecto se estructura en dos etapas principales, cada una con un equipo de trabajo adaptado a las necesidades y objetivos de esa fase:
|
|
|
|
#### 4.2.1. Equipo de trabajo
|
|
|
|
##### 4.2.1.1. Equipo de desarrollo (prototipo y MVP)
|
|
|
|
Esta etapa corresponde al diseño, construcción y validación del producto, incluyendo tanto el desarrollo del prototipo como la construcción del Mínimo Producto Viable (MVP).
|
|
|
|
El equipo está conformado por los siguientes perfiles:
|
|
|
|
- **3 ingenieros electrónicos**: responsables del diseño del hardware del producto, el desarrollo del sistema embebido, y además de la investigación y desarrollo del algoritmo de procesamiento de señales. Este equipo será el encargado de definir los métodos de análisis de datos, implementar los algoritmos correspondientes y obtener mediciones reales para la validación del sistema.
|
|
- **Consultor médico**: un profesional médico que asesora en aspectos clínicos, colabora en el proceso de recolección de mediciones y orienta al equipo en cuestiones relativas a salud y biomedicina.
|
|
- **2 ingenieros informáticos**: encargados de la programación del servidor, la arquitectura de backend y la implementación de la aplicación que utilizan los usuarios para interactuar con el sistema.
|
|
|
|
##### 4.2.1.2. Equipo de operación (post-lanzamiento y ventas)
|
|
|
|
Una vez finalizado el desarrollo del MVP y comenzada la etapa comercial, el proyecto requiere un equipo orientado a la producción, comercialización y mantenimiento del producto en el mercado.
|
|
|
|
El equipo de operación incluye los siguientes roles:
|
|
|
|
- **Ingeniero electrónico de producción y soporte**: encargado de la fabricación en serie, el control de calidad y la reparación de dispositivos en caso de fallas o devoluciones.
|
|
- **Responsable de ventas y stock**: encargado de la gestión comercial, manejo del inventario de productos y administración del flujo de ventas.
|
|
- **Encargado de atención al cliente**: responsable de recibir consultas, coordinar reposiciones o reemplazos de equipos, y brindar soporte post-venta a los usuarios. También debe gestionar la logística de stock para garantizar la disponibilidad de equipos de reemplazo.
|
|
- **Ingeniero informático de mantenimiento**: encargado del mantenimiento y actualización del servidor y de la aplicación utilizada por los clientes, asegurando la operación continua del sistema.
|
|
#### 4.2.2. Recursos necesarios
|
|
##### 4.2.2.1. Infraestructura
|
|
##### 4.2.2.2. Equipamiento
|
|
|
|
Para la ejecución del proyecto se requiere un conjunto específico de equipamiento técnico y herramientas. Cada uno de los integrantes del equipo utilizará su computadora personal para el desarrollo de software, procesamiento de datos y tareas de gestión. Aunque estos equipos no pertenecen formalmente a la empresa, forman parte esencial de los recursos de trabajo. Además, se necesita un espacio equipado para el montaje de hardware, incluyendo herramientas de soldadura y una mesa de trabajo dedicada a la fabricación y ensamblado de los módulos electrónicos.
|
|
|
|
Para la validación de las mediciones y la obtención de datos de referencia, se utilizarán equipos biomédicos tradicionales como un estetoscopio electrónico, que permitirá registrar la frecuencia respiratoria, y un oxímetro Bluetooth, necesario para medir la frecuencia cardíaca de manera complementaria. Estos dispositivos son fundamentales para generar el banco de datos comparativo que se utilizará en la etapa de prueba y ajuste del algoritmo de procesamiento de señales.
|
|
##### 4.2.2.3. Insumos
|
|
|
|
##### 4.2.2.4. Servicios
|
|
##### 4.2.2.5. Otros
|