Esfuerzo estimado para construir la aplicación S1 - JohannPaezU/MISW4501-MediSupply GitHub Wiki

Esfuerzo estimado

Supuestos clave

16 semanas totales.

  • Productividad real: 15 h/semana/persona.

  • Integrantes: 4 desarrolladores

  • Total disponible: 960 HH.

  • Metodología: iterativo (sprints semanales).

  • Foco en MVP esencial:

    • Web: compras, inventarios, ventas básicos.
    • Móvil: pedidos y tracking simple.
    • Backend: microservicios inventarios, ventas, logística, auth.
    • Integraciones: mapas y ruteo básico.
    • Infraestructura: despliegue en GCP con PostgreSQL.
    • IoT: mockeado, solo con pruebas de concepto.

Estimación de esfuerzo por fase

Fase 1 – Arquitectura y Prototipado 8 semanas

Actividades:

  • Modelos contexto, dominio, componentes, despliegue.

  • Definición de SLA, riesgos y seguridad mínima.

  • Prototipado de del proyecto

Esfuerzo:

  • Equipo completo: 4 × 15 h × 8 sem = 480 HH

Fase 2 – Desarrollo MVP 8 semanas

Actividades:

  • Frontend web Angular, i18n básico.

  • Backend core: inventarios, ventas, compras, logística y IoT (Mockeado).

  • App móvil con pedidos y tracking.

  • DB PostgreSQL

  • Despliegue GCP básico con 1 región, GKE y CI/CD

  • Integraciones externas: Google Maps API

Esfuerzo:

  • Equipo completo: 4 × 15 h × 8 sem = 480 HH

QA y validación final esta incluida en últimas 2 semanas de desarrollo de la fase 2

Actividades:

  • Pruebas funcionales en los módulos críticos.

  • Documentación básica de la arquitectura, manual de usuario y despliegue

Esfuerzo:

  • Incluido dentro de las 480 HH de desarrollo

Total estimado

  • Arquitectura: 480 HH (~50%)

  • Desarrollo + QA: 480 HH (~50%)

  • Total = 960 horas-hombre

Consideraciones

  • Capacidad crítica: cada semana perdida equivale a 60 h menos (≈6% del total).

  • Alcance reducido: IoT real, analítica avanzada, ML y multilenguaje completo quedan fuera.

Conclusión

Con la disponibilidad de 3h/día por integrante, el esfuerzo total disponible es 960 HH, lo que obliga a concentrarse en un MVP reducido pero funcional y dejar en segundo plano módulos complejos como los componentes regulatorios y de IoT avanzado