Saltar a contenido

Proyecto Intermodular DAM con ACbR

¿Qué es ACbR

ACbR significa Aprendizaje Basado en Retos.
Se basa en plantear retos reales o cercanos al mundo laboral, en lugar de ejercicios teóricos aislados. Es por ello que se trabaja como en una empresa de desarrollo, resolviendo problemas abiertos y con múltiples posibles soluciones.

¿Cómo encaja en 2º de DAM?

En 2º curso ya tenéis bases de:

  • Programación
  • Acceso a Datos
  • Interfaces
  • Servicios
  • Empresa

El Proyecto Intermodular busca:

  • Integrar conocimientos de todos los módulos.
  • Trabajar en equipo con roles definidos.
  • Aplicar metodologías ágiles (Scrum, Kanban).
  • Desarrollar un producto real y funcional.

Diferencias con un proyecto clásico

  1. No se da todo mascado → hay que investigar y decidir.
  2. Trabajo autónomo y en equipo → investigación, reparto de tareas.
  3. Evaluación continua → proceso y resultado final cuentan.
  4. Enfoque realista → simulación de un entorno laboral.

Ejemplo de reto

Diseñar y desarrollar una aplicación multiplataforma para la gestión de eventos deportivos locales.

Pasos esperados:

  • Definir requisitos (usuarios, funcionalidades, roles).
  • Decidir arquitectura (lenguajes, BD, API, interfaz).
  • Aplicar metodologías ágiles (sprints, backlog).
  • Crear prototipos y validar.
  • Entregar un MVP (Producto Mínimo Viable).

Organización de un proyecto con ACbR

Roles típicos

  • Product Owner: define requisitos y prioriza.
  • Scrum Master / Coordinador: organiza y facilita el trabajo.
  • Desarrolladores Backend: lógica de negocio y BD.
  • Desarrolladores Frontend: interfaces gráficas.
  • QA / Tester: pruebas y calidad del software.
  • Documentación y despliegue: manuales, guías, presentación.

Fases del proyecto

  1. Inicio y análisis del reto
  2. Planificación del trabajo (Scrum/Kanban)
  3. Diseño de arquitectura y prototipos
  4. Desarrollo iterativo (sprints)
  5. Pruebas y control de calidad
  6. Entrega del MVP
  7. Mejoras y refinamiento
  8. Presentación final

Entregables

  • Documentación inicial: análisis, requisitos, backlog.
  • Diseños y diagramas: casos de uso, arquitectura.
  • Código funcional en repositorio (GitHub/GitLab).
  • MVP desplegado.
  • Documentación final y presentación.

Esquema de Proyecto Intermodular DAM con ACbR

Roles en el equipo

  • Product Owner: Define requisitos y prioriza funcionalidades (cliente). Además, organiza, facilita reuniones y seguimiento.
  • Backend: Persistencia, lógica, servicios externos.
  • Frontend: Interfaces con Jetpack Compose, UX/UI accesible.
  • QA/Tester: Plan y ejecución de pruebas unitarias, UI y con usuarios. Labor que puede recaer en todo el equipo
  • Documentación/Despliegue: Documentación, modelo de negocio, demo y defensa.

Fases del proyecto

1. Descubrimiento

  • Documento del proyecto inicial (visión, reto, objetivos SMART).
  • Estudio de mercado (problema, segmento, benchmark, propuesta de valor).
  • Backlog inicial (épicas, HU con criterios de aceptación).

2. Diseño

  • Personas, journeys y wireframes.
  • Arquitectura técnica (Clean Arch + MVVM).
  • Modelo de datos (Room).
  • Prototipo navegable (Figma).

3. Implementación

  • Navegación y estados en Compose.
  • Persistencia local con Room.
  • Lógica de negocio, notificaciones, procesos en segundo plano.
  • Integración opcional con servicios externos (REST/Firebase).

4. Calidad y pruebas

  • Pruebas unitarias, instrumentadas y de UI.
  • Accesibilidad (TalkBack, contraste, tamaños).
  • Métricas básicas (Firebase/Matomo).

5. Lanzamiento

  • Publicación en canal interno (Google Play / APK).
  • Demo pública con guion de defensa.
  • Recogida de feedback y analítica.

Ejemplo de posible rúbrica de Coevaluación y Autoevaluación

Cada miembro del equipo completa esta rúbrica al final del proyecto:

  • Autoevaluación: evalúo mi propio trabajo.
  • Coevaluación: evalúo a mis compañeros de equipo.

Escala de valoración

  • 4 = Excelente → Supera las expectativas, aporta valor extra.
  • 3 = Notable → Cumple bien lo esperado, con pequeños fallos menores.
  • 2 = Adecuado → Cumple lo mínimo, con carencias notables.
  • 1 = Insuficiente → No cumple, falta de implicación o calidad deficiente.

Criterios de evaluación

1. Producto (MVP desarrollado)

  • Cumple con los requisitos funcionales definidos.
  • La UX/UI es clara, accesible y usable (Material Design 3, TalkBack, contraste).
  • El rendimiento es fluido, sin errores críticos.
  • Se entrega un MVP funcional y probado.

2. Proceso y trabajo en equipo

  • Participación activa en las reuniones y sprints.
  • Responsabilidad en las tareas asignadas (issues/commits).
  • Colaboración con el equipo y resolución de conflictos.
  • Uso correcto de herramientas (Git, Issues, Pull Requests).

3. Documentación y evidencias

  • Documento del proyecto actualizado y completo.
  • Historias de usuario con criterios de aceptación claros.
  • Pruebas documentadas (unitarias, UI, accesibilidad).
  • Trazabilidad RA/CE con evidencias.

4. Presentación y comunicación

  • Pitch claro y convincente.
  • Demo fluida y preparada.
  • Responde adecuadamente a preguntas del público.
  • Uso de métricas y aprendizajes en la defensa.

5. Aprendizaje y mejora personal

  • Reflexión crítica sobre el trabajo realizado.
  • Identifica fortalezas y áreas de mejora.
  • Propone mejoras realistas para futuros proyectos.
  • Muestra autonomía y capacidad de autoaprendizaje.

Tabla de evaluación

Criterio Autoevaluación (1-4) Coevaluación (1-4) Comentarios
Producto (MVP)
Proceso y equipo
Documentación y evidencias
Presentación y comunicación
Aprendizaje personal