Publicado automáticamente por el pipeline CI.

Publicado automáticamente por el pipeline CI.

El APK está firmado con el keystore del proyecto y puede instalarse en cualquier dispositivo Android:

1. Descarga app-release.apk desde el release v1.0.1
2. En el dispositivo: Ajustes → Seguridad → Instalar desde fuentes desconocidas
3. Abre el archivo .apk descargado e instala

• Los Modelos contienen únicamente atributos y relaciones del dominio (álbumes, artistas, coleccionistas, tracks).

• Los ViewModels concentran la lógica de negocio y exponen métodos para consultar, filtrar, crear o actualizar datos.

• Las Views se limitan a mostrar la información y a invocar métodos del ViewModel.

• Se garantiza que la vista nunca interactúe directamente con los modelos.

• Los ViewModels actúan como puente, manteniendo la aplicación escalable y mantenible.

• Cada entidad del dominio (Album, Artista, Coleccionista, Track) cuenta con un repositorio dedicado que actúa como único punto de acceso a los datos para el ViewModel. El repositorio encapsula la lógica de decisión entre dos fuentes: la API REST a través de VinilosApiService (datos en línea) y la base de datos local Room a través de AlbumDao (caché offline). Esta decisión evita que el ViewModel conozca el origen concreto de los datos, lo que reduce el acoplamiento entre capas y facilita las pruebas unitarias al permitir sustituir cualquier fuente por un doble de prueba sin modificar la lógica de presentación.

• Cada ViewModel declara sus atributos de estado como MutableLiveData de acceso privado (p. ej. _albumes) y los expone públicamente solo como LiveData de solo lectura (p. ej. albumes). Esta asimetría garantiza que únicamente el propio ViewModel puede mutar el estado, mientras que los Fragments de la capa View únicamente pueden observarlo.

• Para cada lista de dominio se definió un Adapter independiente (AlbumAdapter, ArtistaAdapter, ColeccionistaAdapter), desacoplado del Fragment que lo usa. Los Fragments delegan en el adaptador exclusivamente la responsabilidad de transformar una lista de entidades en vistas infladas, mientras que ellos mismos se limitan a observar el LiveData del ViewModel y a llamar a submitList(). Esta decisión respeta el principio de responsabilidad única dentro de la propia capa View y hace que cada adaptador sea reutilizable en más de un Fragment sin duplicar lógica de presentación.

• Ningún ViewModel del diagrama contiene referencias a Fragments, Adapters ni a objetos del framework de UI de Android (Context, View, FragmentManager). La comunicación desde el ViewModel hacia la Vista ocurre exclusivamente a través del mecanismo reactivo de LiveData.

• El diagrama muestra que las dependencias fluyen en un único sentido: la capa View conoce al ViewModel, el ViewModel conoce al Repository, y el Repository conoce al DAO y al ApiService. Ninguna capa inferior referencia a una capa superior. Esta unidireccionalidad es la garantía estructural de que el patrón MVVM se aplica de forma coherente

El proyecto cuenta con un pipeline de GitHub Actions que automatiza pruebas, construcción y publicación de releases.

Push / PR a main o develop
        ↓
┌─────────────────────────┐
│   JOB 1: Tests y Build  │
│  · Compila el proyecto  │
│  · Ejecuta unit tests   │
│  · Ejecuta pruebas E2E  │
│    (Espresso en emulador│
│     API 34)             │
└────────────┬────────────┘
             │ (si tests pasan)
             ▼
┌─────────────────────────┐
│  JOB 2: APK Release     │
│  · Firma el APK con el  │
│    keystore almacenado  │
│    en GitHub Secrets    │
│  · Verifica que el APK  │
│    fue generado         │
│  · Sube el APK como     │
│    artefacto temporal   │
└────────────┬────────────┘
             │ (solo workflow_dispatch)
             ▼
┌─────────────────────────┐
│  JOB 3: Release y Merge │
│  · Incrementa versión   │
│    en build.gradle.kts  │
│  · Crea rama release_vX │
│  · Merge release → main │
│  · Crea GitHub Release  │
│    con changelog auto   │
│  · Adjunta el APK       │
│    firmado al release   │
│  · Merge main → develop │
│  · Elimina rama release │
└─────────────────────────┘

El APK generado en cada release está firmado con el keystore del proyecto y puede instalarse directamente en cualquier dispositivo Android habilitando "Instalar desde fuentes desconocidas" en Ajustes → Seguridad.

Los secrets de firma (KEYSTORE_BASE64, KEYSTORE_PASSWORD, KEY_ALIAS, KEY_PASSWORD) están almacenados en GitHub Secrets y nunca se exponen en el código.

Para garantizar la entrega completa en una semana, el equipo se ha enfocado estrictamente en las siguientes historias de usuario (Flujo de solo lectura):

• HU01 - Consultar catálogo de álbumes: Visualización y carga de lista desde la API.
• HU02 - Ver detalle de un álbum: Navegación e información extendida (incluyendo tracks). (Nota: Escenarios de Login y Creación fueron excluidos del alcance crítico).

Para cubrir la "fragmentación" de dispositivos, se han configurado y validado las pruebas sobre 3 perfiles secuenciales:

• Perfil "Standard": Pantalla mediana (ej. Pixel 7), 4GB RAM, Android 13.
• Perfil "Old Gen": Pantalla pequeña (ej. Nexus 5), poca RAM (1GB), Android 9.
• Perfil "High End": Pantalla grande/Tableta, 8GB RAM, Android 14.

Debido a la restricción de hardware (1 Laptop), todas las pruebas (Monkey y VRT) se ejecutaron de forma serializada, encendiendo y apagando cada emulador de la Granja Virtual.

gantt
dateFormat YYYY-MM-DD
axisFormat %d-%m
section Setup
Día 1 - Gherkin y Setup :done, a1, 2026-04-12, 1d
section Ejecución
Día 2 - Robustez Monkey :done, a2, after a1, 1d
Día 3 - Scripting Kraken :done, a3, after a2, 1d
Día 4 - Data Faker (OMITIDO) :done, a4, after a3, 1d
Día 5 - VRT Manual :done, a5, after a4, 1d
section Cierre
Día 6 - Wiki (OMITIDO) :done, a6, after a5, 1d
Día 7 - Video Final :active, a7, after a6, 1d

• Día 1: Setup y Gherkin. [Completado] Se escribieron los 5 escenarios .feature basados en HU01 y HU02.
• Día 2: Robustez. [Completado] Ejecución del Monkey Test (2,000 eventos) en los 3 emuladores sin presentar FATAL EXCEPTION.
• Día 3: Scripting Kraken. [Completado] Codificación de los Steps técnicos usando los IDs reales de Android (ej. card_visitor).
• Día 4: Data Integration. [Omitido] No aplica, ya que HU01 y HU02 son flujos de lectura.
• Día 5: VRT Manual. [Completado] Se extrajeron exitosamente las 3 carpetas de Línea Base Visual (vrt-baseline-standard, old-gen, high-end).
• Día 6: Wiki y Arquitectura. [Omitido] La documentación MVVM ya existe y se gestiona externamente.
• Día 7: Cierre. [Completado] El APK se delega a un pipeline automático (CI/CD) y la demostración está finalizado.

• PASA: El Monkey no arroja crash, los scripts de Kraken llegan al final del flujo y la app mantiene el estado esperado en VRT.
• FALLA: El emulador muestra el diálogo "App not responding" o se detecta una FATAL EXCEPTION en los logs del sistema.

Las pruebas instrumentadas (Espresso) se ejecutan automáticamente en el emulador Android API 34 dentro del pipeline CI. El reporte completo está disponible como artefacto del job Tests y Build en GitHub Actions.

El artefacto espresso-test-results se puede descargar directamente desde la pestaña Actions → run → Artifacts en GitHub, o con:

gh run download <RUN_ID> --name espresso-test-results --dir ./espresso-report
open espresso-report/app/build/reports/androidTests/connected/index.html

Evidencia

Iteración evaluada: Inception

Objetivo: Analizar el desempeño del equipo durante la iteración inicial, identificando fortalezas, debilidades y oportunidades de mejora para optimizar el trabajo en las siguientes iteraciones.

Insumos utilizados:

• Resultados de la coevaluación entre los miembros del equipo
• Percepción general del equipo sobre el proceso de trabajo

El equipo demostró capacidad técnica para entregar las historias del Sprint 1 en tiempo, pero identificó como área de mejora prioritaria la comunicación continua durante la ejecución. La tendencia al trabajo individual generó silos de conocimiento y redujo la sinergia entre miembros. Para el siguiente sprint, el equipo se compromete a socializar avances y bloqueos de forma frecuente, practicar pair programming en tareas complejas y distribuir más equitativamente las decisiones técnicas, con el objetivo de construir un equipo más cohesionado y con conocimiento compartido.

Evidencia https://drive.google.com/file/d/11K6eyeg0clLJRjDGxllgyYWJqiwE6hIx/view?usp=sharing

• Fecha: 13 de Abril 2026
• Horario: 21:00 – 22:00
• Medio: Google Meet / Teams
• Asistentes: Rubén Camargo, Diego Rojas, David Rojas, Brian Martínez

Agenda:

1. Asignación de historias
2. Priorización y Distribución de tareas

Evidencia: https://drive.google.com/file/d/1CPIq2WrIAPWwtrsRxA3PJxedS8MgSd1h/view?usp=sharing

• Fecha: 18 de Abril 2026
• Horario: 21:00 – 22:00
• Medio: Google Meet / Teams
• Asistentes: Rubén Camargo, Diego Rojas, David Rojas, Brian Martínez

Agenda:

1. Entrega parcial de tareas asignadas
2. Revisión del CI/CD y set de pruebas

Evidencia: https://drive.google.com/file/d/1MQvNlzJ0dvj4QpOluv72498HJt9xPT0C/view?usp=share_link

• Fecha: 24 de Abril 2026
• Horario: 21:00 – 22:00
• Medio: Teams
• Asistentes: Rubén Camargo, Diego Rojas, David Rojas, Brian Martínez

Agenda:

1. Revisión de rubrica y errores encontrados en los modulos del sprint 1

Evidencia:

https://drive.google.com/file/d/1rX0SeJgshFGx2FMyDhPHXyrBhkATQOrZ/view?usp=sharing

• Fecha: 26 de Abril 2026
• Horario: 21:00 – 22:00
• Medio: Teams
• Asistentes: Rubén Camargo, Diego Rojas, David Rojas, Brian Martínez

Agenda:

1. Corrección del Issue de superposición de botones}
2. Creacion Release v1.0.1

Evidencia: https://drive.google.com/file/d/13aFYvBfZfChadQvFEebzIz7VzF630J-2/view?usp=sharing