Este proyecto se enmarca dentro del desarrollo de un producto tecnológico con un fuerte componente de investigación aplicada. Su objetivo es explorar el uso de un elemento tecnológico existente —el radar UWB— aplicado al monitoreo no invasivo de funciones vitales en bebés durante el sueño.
El trabajo parte de una tecnología ya disponible, pero la resignifica al diseñar un sistema completo que permita su aplicación en un entorno doméstico, con foco en el seguimiento fisiológico preventivo. El enfoque combina tareas de diseño técnico, implementación de algoritmos, integración de hardware y desarrollo de interfaces de usuario.
El resultado esperado es un sistema funcional y validado (mínimo producto viable), orientado a resolver una necesidad específica. No se trata de un producto de implementación masiva ni de aplicación única, sino de una solución exploratoria con potencial de adaptación a distintos escenarios o entornos clínicos especializados.
## 2. Tipo de proyecto
Este proyecto se enmarca dentro del desarrollo de un producto tecnológico con un fuerte componente de investigación aplicada. Su objetivo es explorar el uso de un elemento tecnológico existente —el radar UWB— aplicado al monitoreo no invasivo de funciones vitales en bebés durante el sueño.
El trabajo combina diseño técnico, desarrollo de hardware, implementación de algoritmos de procesamiento de señales y diseño de interfaces de usuario, integrando conocimientos de distintas disciplinas. ==Al tener un enfoque centrado en la investigación y la exploración de nuevas aplicaciones, el proyecto conlleva un costo elevado tanto en términos de desarrollo como en generación de conocimiento.==
No se trata de un producto de implementación masiva ni de aplicación única, sino de una solución específica con valor en contextos puntuales, que se busca vender en un modelo de suscripción a parejas con bebes recién nacidos.
| Falta de precisión del radar UWB | El radar puede no detectar con suficiente fidelidad señales respiratorias o cardíacas en recién nacidos. | 8 - Alto | 7 - Media | Realizar pruebas en etapas tempranas, usar sensores de referencia. |
| Dificultades en el desarrollo de algoritmos | El procesamiento de señales puede no lograr distinguir señales fisiológicas reales del ruido. | 9 - Alto | 8 - Alta | Incorporar expertos en bioseñales desde el inicio. |
| Interferencia electromagnética | El entorno doméstico podría generar interferencias que afecten al radar UWB. | 6 - Medio | 6 - Media | Realizar pruebas en diferentes entornos reales; incorporar filtros o corrección por software. |
| Inestabilidad de la conectividad Wi-Fi | Puede fallar la conexión entre dispositivo y servidor/plataforma. | 7 - Medio | 8 - Alta | Incorporar buffers locales y reconexión automática. |
| Problemas de compatibilidad hardware/software | Integrar distintos componentes puede generar errores de compatibilidad. | 6 - Medio | 6 - Media | Elegir componentes con interfaces estándar, plan de pruebas integrales. |
| Dificultad para conseguir muestras reales | Falta de acceso a bebés o familias dispuestas a participar en validaciones. | 8 - Alto | 7 - Media | Establecer acuerdos con instituciones pediátricas o centros de salud. |
| Errores en los datos recolectados | Mala calidad de las mediciones por condiciones no controladas. | 7 - Medio | 7 - Media | Diseñar protocolos de recolección robustos, registrar metadatos. |
| Resultados no concluyentes | El método no logra validarse experimentalmente. | 9 - Alto | 6 - Baja | Documentar todos los pasos, dejar abierta la iteración de diseño. |
| Retrasos en la fabricación de hardware | Fallas en la entrega de componentes o problemas de diseño. | 6 - Medio | 6 - Media | Planificar buffers de tiempo, diseño modular. |
| Diseño físico poco amigable | El gabinete puede no resultar adecuado para entornos reales de uso. | 5 - Medio | 5 - Media | Testeo con familias desde el prototipo funcional. |
| Dificultad para coordinar trabajo multidisciplinario | El proyecto integra electrónica, software, procesamiento de señales y validación clínica. | 7 - Alto | 6 - Media | Establecer cronogramas claros y comunicación constante entre equipos. |
| Desviación del objetivo de MVP | Riesgo de sobrediseñar el sistema e ir más allá del producto mínimo viable. | 6 - Medio | 7 - Alta | Revisiones periódicas del alcance, definir límites del prototipo. |
| Cuestiones éticas en el monitoreo de bebés | Requiere consentimiento informado, uso responsable y privacidad. | 8 - Alto | 6 - Media | Asesoramiento legal y ético desde el inicio. |
| Requisitos regulatorios no previstos | Aunque es un MVP, podría entrar en conflicto con normativas médicas. | 7 - Alto | 5 - Baja | Consultar marcos normativos locales e internacionales desde el diseño. |
### 2.2. Riesgos del Desarrollo Comercial y Post-lanzamiento
| Problemas de stock o disponibilidad | Si la demanda supera la producción, no se podrá responder en tiempo. | 7 - Alto | 6 - Media | Planificar escalabilidad de ensamblado, tercerización parcial si es necesario. |
| Fallas o caídas del servidor remoto | Puede dejar inactiva la plataforma de monitoreo para los usuarios. | 9 - Crítico | 6 - Media | Infraestructura con redundancia, backups automáticos, monitoreo 24/7. |
| Dificultades con el mantenimiento de equipos alquilados | Equipos dañados o fuera de funcionamiento por mal uso o fallas técnicas. | 8 - Alto | 7 - Media | Política clara de reposición, logística inversa y mantenimiento periódico. |
| Escepticismo inicial del mercado | Dificultad para convencer a familias del valor del sistema no invasivo. | 6 - Medio | 7 - Alta | Estrategia comunicacional basada en evidencia y testimonios. |
| Baja tasa de retención de clientes | Usuarios que prueban el servicio pero lo abandonan rápido. | 6 - Medio | 6 - Media | Ofrecer soporte postventa, prueba gratuita, alertas de salud atractivas. |
| Saturación de soporte técnico | Muchos usuarios solicitando ayuda simultáneamente. | 7 - Alto | 5 - Media | Escalar el sistema de soporte gradualmente, incluir FAQs y soporte automatizado. |
| Costos operativos mayores a lo previsto | Costos de logística, mantenimiento, servidor o atención al cliente pueden ser altos. | 8 - Alto | 6 - Media | Modelar el flujo financiero con escenarios variables, ajustar tarifa de alquiler. |
| Problemas legales por uso indebido del dispositivo | El mal uso del sistema podría generar consecuencias legales o reputacionales. | 8 - Alto | 4 - Baja | Manuales de uso claros, cláusulas legales en el contrato de alquiler. |
| Interferencia electromagnética afecta la señal UWB | 7 | 6 | 6 | 252 | Puede degradar o distorsionar mediciones; depende del entorno del usuario. |
| Corte de servicio del servidor o nube | 9 | 5 | 7 | 315 | Inhabilita visualización de datos y alertas. Impacta en la confianza del usuario. |
| Red Wi-Fi hogareña inestable o débil | 6 | 8 | 5 | 240 | Común en algunos hogares. Puede dificultar la transmisión de datos. |
| Saturación del backend por aumento de usuarios | 8 | 6 | 6 | 288 | Si el sistema no escala correctamente, puede dejar inoperables todas las unidades. |
| Falla eléctrica por microcortes o baja tensión | 6 | 5 | 6 | 180 | Puede apagar o dañar el equipo si no está protegido. |
| Restricciones legales sobre el uso de UWB | 8 | 4 | 9 | 288 | En algunos países o regiones no está permitido el uso libre del espectro. |
| Acceso no autorizado a la plataforma (ciberataque) | 9 | 4 | 8 | 288 | Puede comprometer datos sensibles y afectar la reputación del servicio. |
| Incompatibilidad con routers del usuario | 5 | 7 | 4 | 140 | Puede impedir la conexión inicial. Impacto moderado pero común. |
| Ambientes con humedad o polvo excesivo dañan el equipo | 6 | 5 | 7 | 210 | Puede provocar fallas de hardware en hogares con condiciones adversas. |
### 2.4. Entregables
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.
| T1 | Diseño del módulo de medición | — | Hardware | Diseño electrónico y estructural del módulo con radar UWB para adquirir señales. |
| T7 | Diseño del protocolo de medición | — | Validación | Definición del entorno, frecuencia, duración y condiciones para la toma de datos en personas. |
| T2 | Estudio para obtención de mediciones | T1, T7 | Validación | Planificación y ejecución de la recolección de mediciones fisiológicas reales de prueba. |
| T3 | Diseño de los módulos por separado | — | Hardware/Infraestructura | Diseño técnico individual del hardware, servidor, interfaz y sistema embebido. |
| T4 | Integración de todos los módulos | T3 | Hardware | Ensamblado e interconexión funcional del sistema completo. |
| T5 | Estudio y diseño del algoritmo | T1 | Procesamiento | Desarrollo del método de procesamiento de señales y definición del algoritmo. |
| T6 | Validación del algoritmo | T2, T5 | Procesamiento/Validación | Evaluación del algoritmo usando datos reales recolectados con el módulo. |
| T8 | Diseño de API y aplicación de usuario | T3 | Interfaz de Usuario | Desarrollo de la API y de la interfaz (web o móvil). |
| T9 | Configuración del servidor | T3 | Infraestructura Remota | Implementación del servidor para almacenamiento y consulta de datos. |
| T18 | Diseño del sistema de alimentación y autonomía | T3 | Hardware | Diseño del subsistema de energía y evaluación de autonomía del dispositivo. |
| T10 | Validación del prototipo | T4, T5, T18 | Validación | Verificación funcional del sistema ensamblado. |
| T11 | Diseño y construcción del gabinete | T4 | Hardware | Desarrollo de la estructura física del dispositivo. |
| T12 | Estudio normativo para cumplimiento del MVP | T4 | Validación/Regulación | Revisión de normativas técnicas que el MVP debe cumplir. |
| T13 | Homologación médica | T6, T12 | Validación/Regulación | Validación formal del sistema frente a criterios médicos. |
| T16 | Pruebas de usabilidad con usuarios finales | T8, T10 | Validación/UX | Validación de experiencia de usuario en condiciones reales o simuladas. |
| T17 | Documentación técnica del sistema completo | T10, T11, T8, T9 | Documentación | Generación de documentación técnica para validación, mantenimiento y regulación. |
### 2.6. 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.
#### 2.6.1. Requerimientos tecnicos
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.
# Análisis FODA del Proyecto: Detección de Anomalías Cardiorrespiratorias con Radares UWB
# Análisis FODA del Proyecto: Detección de Anomalías Cardiorrespiratorias con Radares UWB
## 1. 🟩 Fortalezas
### 0.1. Análisis FODA
- **Alta precisión en distancias cortas**: Los radares UWB son ideales para detectar movimientos sutiles en un rango cercano, lo que es perfecto para monitorear signos vitales como la respiración y el ritmo cardíaco sin contacto físico.
- **No invasivo y seguro**: Al utilizar señales de baja potencia y no ionizantes, los radares UWB son seguros para el monitoreo continuo de pacientes, incluso en entornos sensibles como unidades de cuidados intensivos.
A continuación se desarrolla un análisis de fortalezas, oportunidades, debilidades y amenazas vinculadas al desarrollo y despliegue del proyecto.
- **Desarrollo tecnológico avanzado**: La tecnología UWB permite una alta resolución temporal y espacial, lo que mejora la precisión en la detección de pequeñas variaciones en los signos vitales.
- **Potencial para aplicaciones en telemedicina**: La capacidad de monitorear a distancia sin contacto físico es especialmente valiosa en el contexto actual de atención médica remota.​:contentReference[oaicite:0]{index=0}
**Fortalezas**
## 2. 🟨 Oportunidades
- **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.
- **Demanda creciente de soluciones de monitoreo remoto**: :contentReference[oaicite:1]{index=1}
- **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.
- **Apoyo institucional y gubernamental**: :contentReference[oaicite:2]{index=2}
- **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.
- **Colaboraciones con el sector salud**: :contentReference[oaicite:3]{index=3}
- **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.
- **Interés en aplicaciones específicas**: :contentReference[oaicite:4]{index=4}​:contentReference[oaicite:5]{index=5}
- **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. 🟥 Debilidades
- **Limitación en el rango de detección**: :contentReference[oaicite:6]{index=6}
**Oportunidades**
- **Dependencia de condiciones ambientales**: :contentReference[oaicite:7]{index=7}
- **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.
- **Costos iniciales de desarrollo**: :contentReference[oaicite:9]{index=9}​:contentReference[oaicite:10]{index=10}
- **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.
## 4. 🟦 Amenazas
- **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.
- **Competencia de tecnologías establecidas**: :contentReference[oaicite:11]{index=11}
- **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.
- **Percepción del usuario final**: :contentReference[oaicite:13]{index=13}
- **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.
**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.
Datos interesantes sobre el flujo de caja de Erick https://ibb.co/wZv4gBfS
@ -146,4 +146,87 @@ El diseño preliminar del producto abarca tres áreas fundamentales que aseguran
3. **Diseño del Servidor y la Aplicación de Usuario:**
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.
- **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.
- **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.
