El Framework Ideal.

Objetivo general

Que el estudiante analice requerimientos de software y aplique criterios de evaluación técnicos para seleccionar el framework de desarrollo móvil más adecuado (Nativo, React Native o Flutter) para un proyecto empresarial, demostrando capacidad de análisis arquitectónico.

Introducción

El desarrollo móvil moderno ofrece múltiples rutas estratégicas. Optar por el rendimiento puro del desarrollo nativo (Swift/Kotlin) frente a la versatilidad y velocidad de los frameworks multiplataforma (como Flutter o React Native) es una de las decisiones más críticas en cualquier proyecto de software. En esta actividad, el estudiante asumirá el rol de Líder Técnico (Tech Lead) en una startup. Se enfrentará a un caso de estudio real con restricciones de tiempo, presupuesto y habilidades del equipo, donde una mala elección de framework podría comprometer la viabilidad del producto.

Materiales o recursos necesarios

Computadora personal con acceso a internet.
Editor de texto o IDE (como Visual Studio Code o google codelab).
Procesador de textos o herramienta de hojas de cálculo para la creación de matrices.
Documento JSON con las especificaciones del caso de estudio (provisto en esta guía).

Generación de Insumos Prácticos

Para realizar la práctica, el estudiante debe basar su análisis estrictamente en los siguientes requerimientos del cliente ficticio. A continuación, se provee el archivo requerimientos_proyecto.json y una plantilla en Markdown matriz_decision.md que el estudiante deberá utilizar.

Instrucciones paso a paso

Lectura del entorno técnico: Se debe analizar el archivo requerimientos_proyecto.json para comprender profundamente las restricciones del negocio, especialmente la experiencia del equipo y los tiempos de entrega. ¿Por qué hacerlo?: Porque una decisión técnica desligada de la realidad del equipo y del negocio conduce al fracaso del proyecto.
Investigación de capacidades: Se deberá investigar cómo cada alternativa (Nativo, React Native, Flutter) maneja los requerimientos específicos de “GPS en segundo plano” y “animaciones de mapas”. ¿Por qué hacerlo? Porque ciertos frameworks requieren puentes (bridges) complejos para procesos en segundo plano, lo que impacta los tiempos de desarrollo.
Llenado de la matriz: El estudiante debe completar la matriz_decision.md. Multiplicará el peso del criterio por el puntaje asignado a cada framework para obtener el total. ¿Por qué hacerlo? Porque las matrices ponderadas eliminan los sesgos emocionales y permiten una evaluación cuantitativa.
Validación de viabilidad: Una vez obtenido un framework ganador en la matriz, se debe buscar en la documentación oficial de dicho framework al menos una librería o paquete real que resuelva el uso de la cámara y el GPS. ¿Por qué hacerlo? Para asegurar que el ecosistema de la herramienta elegida soporta las necesidades del cliente.
Redacción del dictamen final: Se redactará un documento ejecutivo de máximo una cuartilla, dirigido a los “inversionistas”, justificando la elección final basándose en los datos de la matriz. ¿Por qué hacerlo? Porque el perfil de ingeniería moderna exige excelentes habilidades de comunicación escrita para defender arquitecturas ante perfiles no técnicos.

Recomendaciones para el estudiante

Recordar que un framework excelente técnicamente puede ser una mala elección si el equipo no lo conoce y hay prisa.
Prestar especial atención a la sección experiencia_previa del equipo en el archivo JSON.
Considerar los “pesos” de la matriz de forma realista; el tiempo de mercado suele valer más que el micro-rendimiento para las startups.
No dejarse llevar por el fanatismo hacia una tecnología específica.
Asegurarse de que el párrafo final utilice lenguaje de negocio (ROI, tiempos de entrega, costos de capacitación).

Posible problema y solución rápida

Solución: Recordar al estudiante la restricción de tiempo y costo. Explicar el concepto de “Time-to-Market” y sugerirle que evalúe qué pasaría con los tiempos del proyecto si tienen que aprender Swift y Kotlin desde cero o contratar a 4 personas nuevas. Esto recalibrará sus puntajes en la matriz hacia tecnologías como React Native, dado el stack del equipo.

Problema: El estudiante se inclina por el Desarrollo Nativo argumentando el acceso al GPS y las animaciones, ignorando que el equipo solo sabe JavaScript y tienen 3 meses para lanzar en iOS y Android.

Arquitectos de la Movilidad