Sección 5
Plan de la primera entrega
Del lunes 31 de agosto al jueves 3 de septiembre de 2026. Cuatro tardes de trabajo: cada día nos juntamos y trabajamos a partir de las 16:00. El lunes 31 comparto esta página antes de la reunión de arranque para que todos lleguen habiéndola leído.
5.1 Requisitos de la entrega
| # | Requisito | Cómo se cumple | Responsable |
|---|---|---|---|
| 1 | Equipos mixtos de desarrollo y diseño | Somos cuatro de desarrollo (IDS) y Sam en diseño; cada uno con su módulo y su responsabilidad transversal (§4.1). | Equipo |
| 2 | Seleccionar un problema social | Falta de control cotidiano del gasto personal, sustentada en §1.1. | Equipo |
| 3 | Investigar el público objetivo | Encuesta a 25 personas, cinco entrevistas, hallazgos y personas clave en §2. La investigación de campo la simulamos a partir de esa muestra para entregar antes. | Sam |
| 4 | Diseñar wireframes y flujos | Bocetos, sistema visual, alta fidelidad y prototipo según tabla 4.3. | Sam |
| 5 | Prototipo funcional con al menos dos pantallas | Tres pantallas conectadas por barra inferior con datos que persisten. | Omar Paola David Santiago |
| 6 | Documentar justificación y bocetos | Este documento con justificación en §1.1 y necesidades en §2.4. Cada uno redacta su parte; Paola coordina y cierra. | Paola coordina · todos redactan |
| 7 | Entregar archivos fuente y documentación | Código, documento, material de diseño, APK y evidencia de pruebas, subidos juntos antes de las 21:00 del jueves 3. | Omar |
5.2 Cronograma
| Integrante | Lunes 31 | Martes 1 | Miércoles 2 | Jueves 3 |
|---|---|---|---|---|
| Sam | Llega con el material de investigación simulado a partir de §2 y el primer borrador del flujo. Flujo y bocetos de baja fidelidad listos a las 17:00 (D-1). Sistema visual base —paleta, tipografía, escala— a las 21:00 (D-2). | Alta fidelidad de las tres pantallas a las 19:00 (D-3). Prototipo navegable, propuesta de identidad e ícono de la app a las 21:00 (D-4). | Prueba de usabilidad con cinco personas; entrega los resultados a las 20:00 (D-5). Los hallazgos se clasifican para la segunda entrega (§6.1). | Redacta su parte del documento: informe de investigación (a partir de §2), memoria de decisiones de diseño y auditoría de accesibilidad. Exporta el prototipo con enlace público. Cierra el PDF junto con Paola y David. |
| Omar | Llega con el repositorio creado y el contrato core redactado. Reunión de arranque a las 16:00. Con D-1 (17:00) monta la navegación y las tres pantallas vacías unidas por la barra inferior. Congela core a las 18:00 (§4.2). | Módulo de registro: teclado numérico propio, monto válido (RN-2), tipo gasto/ingreso (RN-3) y guardado con fecha del día (RN-4). Maqueta con D-2 y ajusta con D-3. | Integra todas las ramas por la tarde (§4.5). Tras el punto de control, conecta RepositorioRoom en MainActivity por PR. Aplica el ícono de D-4 y genera el APK firmado. | Redacta su parte del documento: ficha del módulo de registro y bitácora de integración. Verifica que el proyecto compila desde cero en una carpeta recién descargada, escribe el README (quién hizo qué y cómo compilar) y sube el paquete completo antes de las 21:00. |
| Paola | Capa de lógica del resumen sobre mes natural (RN-6): gastado hoy, gastado en el mes (RN-7), disponible (RN-8) e ingresos por separado (RN-9). Trabaja contra la interfaz del contrato con el repositorio de prueba. | Capa de presentación del resumen. Maqueta con el sistema visual (D-2) y la ajusta a la alta fidelidad (D-3). | Empieza a redactar en el documento las primeras secciones y escribe la ficha de su módulo (plantilla 8.1). | Redacta su parte y coordina el cierre: finalización de la redacción del PDF —documento de definición y planificación más las fichas de módulo— junto con Sam y David. |
| David | Capa de lógica del historial: agrupación por día, subtotales diarios y orden descendente. Escribe sus pruebas contra el repositorio de prueba. | Capa de presentación del historial, con el estado de lista vacía. Maqueta con D-2 y ajusta con D-3. | Eliminación con confirmación (RN-10). Prueba la app en dos teléfonos físicos distintos. | Repite el recorrido de pruebas (anexo 8.2) y registra en el documento los resultados y la bitácora de pruebas. Cierra el PDF junto con Paola y Sam. |
| Santiago | Entidades, consultas y base de datos local con Room, sin depender del diseño. Carga inicial de las seis categorías (RN-5). | Implementación real del repositorio (RepositorioRoom) sobre la misma interfaz del contrato. | Termina y prueba RepositorioRoom; queda listo para el punto de control de las 18:00, cuando Omar lo conecta en MainActivity. | Redacta su parte del documento: esquema de datos y procedimiento de migración. Verifica que los datos persisten al cerrar y reabrir. |
Punto de control · miércoles 2, 18:00
Si a esa hora la aplicación no compila con la base de datos integrada, se entrega con el repositorio de prueba y datos en memoria.
El documento se escribe entre todos
Cada uno redacta su parte —su ficha de módulo y el material que le toca (§4.1)—. Paola arranca la redacción el miércoles y el jueves cierra el PDF junto con Sam y David. Nadie compila el documento solo al final.
5.3 Criterios de terminado
Un módulo está terminado si…
- Compila y la aplicación no se cierra al utilizarlo.
- Funciona en un teléfono físico, no solo en el emulador.
- Tiene resuelto su estado sin datos.
- Respeta el sistema visual de Sam.
- Está fusionado en la rama de desarrollo y revisado.
- Tiene su ficha de documentación completa.
La entrega está lista si…
- El proyecto compila desde cero en una carpeta recién descargada.
- Se puede registrar un gasto, verlo en el historial y encontrarlo al reabrir.
- Las tres pantallas se alcanzan desde la barra inferior.
- El APK se instala y abre.
- El prototipo tiene enlace público.
- El documento incluye justificación, público objetivo y bocetos.