Esta carpeta contiene todo lo que necesitas para desarrollar el Proyecto Personal de la asignatura AEDV (Análisis Exploratorio de Datos y Visualización).
| Fichero / Carpeta | Para qué sirve |
|---|---|
README_Proyecto_Personal.html |
Empieza aquí — esta guía en formato legible |
ModeloMemoriaProyectoPersonalAEDV.html |
Vista previa de la plantilla de memoria |
ModeloMemoriaProyectoPersonalAEDV.Rmd |
Plantilla que abres en RStudio para escribir tu proyecto |
RubricaEvaluaciónProyectoPersonal.xlsx |
Criterios de evaluación de las tres entregas |
SelecciónDatasetsProyecto/ |
Herramientas para elegir y validar tus datos |
SelecciónDatasetsProyecto/README_Selección_Tema.html |
guía para la elección del tema del proyecto |
estilos.css |
Estilos visuales — no modificar |
utilidades.R |
Funciones de la asignatura que carga la memoria, entre ellas
aedv_incluir_dataset() para incorporar los datasets — no
modificar |
DashboardInstruccionesServidorShiny.html |
Instrucciones para subir y desplegar el cuadro de mandos en el servidor Shiny del DIS |
Antes de hacer cualquier otra cosa
Configura la Google Sheet de seguimiento: descarga la plantilla,
haz una copia en tu Google Drive y pega la URL en el chunk
seguimiento-lectura del
ModeloMemoriaProyectoPersonalAEDV.Rmd. Solo se tarda 5
minutos y es obligatorio. De hecho, el tiempo que dedicas a leer este
documento ya habría que contabilizarlo como tiempo de dedicación al
proyecto. El detalle completo está en el Paso 0 más
abajo.
El proyecto personal se desarrolla en tres entregas progresivas:
Las tres entregas del proyecto
Las entregas no son tres trozos independientes de la memoria, sino tres versiones sucesivas del mismo documento. El trabajo se hace por iteraciones, igual que en la metodología CRISP-DM: en cada entrega se añaden apartados nuevos y, a la vez, se revisan y mejoran los ya entregados, a partir de los comentarios del profesor y las técnicas que se vayan aprendiendo en la asignatura. Un apartado entregado en la Entrega 1 no queda cerrado: se vuelve a él tantas veces como haga falta. De la misma forma cada evaluación pasa por todos los apartados y puede solicitar en apartados ya evaluados anteriormente.
Entrega 1 — Validación del tema y datasets
Acredita que el tema elegido es viable e interesante y que los datos seleccionados cumplen los criterios de AEDV. En la memoria hay que rellenar una primera versión de los siguientes apartados:
Exigencia de la Entrega 1: las preguntas de investigación. No basta con que los datasets cumplan los requisitos de AEDV: la entrega debe plantear preguntas de investigación interesantes que se puedan responder con esos datos y justificar, en Comprensión del negocio, que los datasets elegidos permiten responderlas. Un tema sin preguntas de investigación interesantes no se valida aunque sus datasets cumplan todos los requisitos. Todos los datasets incorporados a la memoria deben estar referenciados por al menos una pregunta: no puede haber un dataset “suelto” que no ayude a responder ninguna de ellas. Son preguntas iniciales: se irán refinando por iteraciones a medida que avance el análisis de los datos (ver el Paso 1).
Entrega 2 — Entrega intermedia
Corresponde a los contenidos del primer parcial del curso. En esta entrega se revisan los apartados de la Entrega 1 —en particular las preguntas de investigación, que se ajustan a lo que ha ido mostrando el análisis— y se añade una primera versión de los siguientes:
ggplot2). Ver sección Visualizaciones en la
memoria.Siguen formando parte de la entrega 1.3 Objetivos, 3.3 Comprensión del negocio, 3.4 Comprensión de los datos y el Anexo II, en su versión revisada.
Entrega 3 — Entrega final
Es la versión final de la memoria: se completan y revisan todos los apartados, incluidos los de las entregas anteriores, para que el documento se lea de principio a fin con un hilo conductor común. Además de los apartados de las Entregas 1 y 2, completados con los contenidos del segundo parcial (análisis de atributos, visualización dinámica y cuadro de mandos), hay que rellenar:
plotly).El cuadro de mandos interactivo debe estar desplegado en el servidor Shiny del DIS, y su enlace, activo y accesible desde la red del DIS o su VPN en el momento de la corrección.
La Google Sheet de seguimiento de actividades se revisa en las tres entregas. Debe estar activa desde el primer día: cada sesión de trabajo debe registrarse en el momento, y la memoria la lee automáticamente para generar el Anexo II. Sin ella el documento puede no compilar correctamente. De hecho, si estás leyendo este documento ya estás trabajando en el proyecto personal y deberías tener una sesión de trabajo abierta.
La nota final depende de todas las entregas, no solo de la última
La calificación final del proyecto personal se basa en el conjunto de las tres entregas y en la calidad con la que se vayan realizando, no únicamente en la entrega final. Si el profesor rechaza una entrega y pide un nuevo envío por errores graves, eso influye negativamente en la nota final aunque la versión corregida se entregue después. Por eso conviene revisar bien cada entrega antes de enviarla, no después de que se rechace.
Comprueba que la memoria compila solo con los ficheros que vas a subir
En cada entrega hay que subir todos los ficheros necesarios
para que la memoria compile: el .Rmd y su
.html, y además los .rds y
_metadatos.xlsx de los datasets, sus
_analisis.Rmd, utilidades.R,
estilos.css y la imagen de portada, si es un fichero local.
En tu carpeta de trabajo están siempre todos, así que la memoria compila
aunque te olvides de subir alguno; en el ordenador del profesor, en
cambio, no compilará, y un .Rmd que no compila
equivale a no entregado.
Para detectarlo antes de enviar:
.Rmd de la memoria desde esa
carpeta y compílalo (Ctrl+Shift+K).Si compila, la entrega está completa: sube el contenido de esa
carpeta (sube los archivos individualmente, no un zip).
Si falla, el error indica qué falta. Por ejemplo,
Error en gzfile(file, "rb"): no se puede abrir la conexión
en el chunk de un dataset significa que falta su .rds, y
Falta el fichero estilos.css (o utilidades.R)
lo dice directamente. Añade el fichero a la carpeta temporal y vuelve a
compilar.
Revisa además el .html que sale de esa carpeta: si las
cajas de colores o las tablas anchas con barra de desplazamiento
aparecen sin formato, es que falta estilos.css. Sin ese
fichero la memoria se ve mal aunque llegue a compilar.
Verifica tu entrega con la IA antes de enviarla
Antes de enviar cualquier entrega, pide a un agente de IA que la
revise contra la rúbrica. Dale acceso a tu .Rmd y a su
.html ya compilado —así puede ver también el resultado
final, no solo el código— y pídele que compruebe los criterios de esa
entrega a partir de este documento. Por ejemplo, para la Entrega 1:
Utiliza los ficheros
NombreApellido1Memoria.Rmdy su compiladoNombreApellido1Memoria.html(para que mires el resultado de la compilación) y verifica si cumple todos los criterios de la primera entrega del proyecto personal usando los criterios que figuran enREADME_Proyecto_Personal.Rmd.
Adapta el número de entrega (1, 2 o 3) y repite la comprobación antes de cada envío. Esto no sustituye la revisión del profesor, pero ayuda a detectar a tiempo los errores graves que llevarían a un rechazo de la entrega.
Revisa tú el documento: se nota cuando no se ha hecho
No se evalúa si has usado la IA, sino si el documento es tuyo: si lo has leído, entendido y corregido. Al evaluar se tendrán en cuenta, como indicios de un documento no revisado:
%>% en vez de |>, o programar desde cero
lo que ya resuelve utilidades.R).Estos aspectos afectan a la calificación del proyecto y, si el resultado es muy deficiente, la entrega puede calificarse como NO APTA.
Hazlo antes que nada — solo se tarda 5 minutos
El tiempo dedicado al proyecto es un requisito evaluable. Debes registrar cada sesión de trabajo en el momento en que la realizas, no reconstruirla después. Las fechas son verificables y deben ser coherentes con las entregas.
Configuración (una sola vez):
ModeloMemoriaProyectoPersonalAEDV.Rmd, localiza el
chunk seguimiento-lectura y sustituye la
URL por la tuya:SeguimientoActividadesProyecto <- read_sheet(
'https://docs.google.com/spreadsheets/d/TU_ENLACE_AQUI/...'
)Uso en cada sesión de trabajo — solo dos acciones:
Cómo funciona el registro automático
No necesitas introducir a mano ni la hora de inicio ni la duración. Cierra siempre la actividad que has abierto antes de empezar otra o de dejarlo por hoy: una fila sin la nota final se queda sin minutos calculados y aparece como actividad incompleta, lo que hace que la hoja deje de ser coherente.
La columna ACTIVITY debe coincidir exactamente con los
valores del vector actividades definido en el chunk
seguimiento-por-actividad de la memoria
("Introducción", "Comprensión del negocio",
etc.).
Antes de escribir una sola línea de código, necesitas tener claro qué quieres averiguar y con qué datos vas a hacerlo.
Primero las preguntas, después los datos
Que un dataset cumpla los requisitos de AEDV es condición necesaria, pero no suficiente. Un proyecto que parte de «he encontrado un dataset que cumple los requisitos» sin saber qué quiere averiguar con él acaba siendo una sucesión de gráficas sin hallazgos ni conclusiones.
Parte de un tema que te interese y formula entre 3 y 5 preguntas de investigación: preguntas concretas, que se puedan responder con los datos y con las técnicas de la asignatura, y cuya respuesta no sea obvia de antemano. Suelen implicar una comparación, una relación o un cambio:
Explorar los catálogos puede ayudarte a descubrir temas y a inspirar preguntas, pero antes de dar por elegido un dataset tienes que poder decir a qué pregunta ayuda a responder. Ningún dataset debe quedar sin pregunta asociada: si tienes un dataset que no sirve para responder a ninguna de tus preguntas, o lo descartas o formulas una pregunta nueva que lo justifique. Las preguntas se escriben en el apartado Objetivos de la memoria (el modelo trae más ejemplos en sus comentarios), guían todo el análisis y se responden en las Conclusiones.
Las preguntas de la Entrega 1 son un punto de partida, no una versión definitiva. Igual que la metodología CRISP-DM, se trabajan por iteraciones: al explorar y modelar los datos aparecerán resultados que obligan a matizar una pregunta, a descartar otra que los datos no permiten responder o a plantear una nueva que no se veía al principio. Actualiza el apartado Objetivos en cada entrega para que las preguntas de la memoria final sean las que el análisis responde de verdad.
Abre y lee el documento
SelecciónDatasetsProyecto/README_Selección_Tema.Rmd (o su
versión compilada .html). Ese documento explica cómo
explorar siete fuentes de datos públicas — INE, ISTAC, EUROSTAT, Banco
Mundial, EDGAR GHG, CLIMA (AdapteCCa/AEMET) e INFORME PISA (resultados
educativos con contexto de pobreza y desigualdad) — y cómo comprobar que
los datasets elegidos cumplen los requisitos de AEDV.
Requisitos que deben cumplir tus datasets
Cobertura geográfica adecuada al nivel del dato:
Datos actualizados: último dato de 2024 o posterior.
Tamaño de las series temporales: P25 ≥ 10 años (anuales), ≥ 20 semestres, ≥ 40 trimestres, ≥ 60 meses, ≥ 200 semanas o ≥ 1096 días (tres años), según la frecuencia del dato; esto garantiza que el 75 % de las regiones tiene series suficientemente largas.
España y/o Canarias bien representadas: no basta con que el dataset sea grande en conjunto — el proyecto tiene que poder analizar nuestro entorno. Se comprueba, además, que la serie de España o de Canarias alcance por su cuenta el umbral del criterio anterior:
Canarias, sus dos provincias o municipios con código
35xxx/38xxx).ES)
o alguna región de Canarias (ES7,
ES70, o las islas ES703–ES709);
basta una de las dos.ESP), porque
sus datos son por países y no bajan a nivel regional.Mínimo de 4 atributos válidos (que cumplan los criterios anteriores de tamaño de series temporales y representación de España/Canarias). INE y EUROSTAT suelen tener más de 4 en un solo dataset; ISTAC y Banco Mundial tienen uno por dataset, así que necesitas varios.
Flujo concreto. Las cuatro fuentes con API —INE, ISTAC, EUROSTAT y Banco Mundial— se abordan exactamente igual, en cuatro etapas. Cambia el organismo y el nombre de los ficheros, no el procedimiento; lo que produce cada etapa es justo de lo que parte la siguiente:
ETAPA 1 catálogo (inventario) de todos los datasets, que se guarda en la hoja excel <FUENTE>.datasets.xlsx (ya está hecho)
▼
ETAPA 2 buscas en ese Excel, con ayuda de una IA, los datasets de tu tema
▼
ETAPA 3 descarga y valida los que has elegido usando <FUENTE>_DatasetSelection.Rmd
▼
ETAPA 4 incorporas a tu memoria de proyecto personal los ficheros que ha guardado y su análisis1. Inventario — el catálogo ya está hecho. Abre el
catálogo Excel de la fuente que te interese:
SelecciónDatasetsProyecto/INE/INE.datasets.xlsx,
SelecciónDatasetsProyecto/ISTAC/ISTAC_datasets.xlsx,
SelecciónDatasetsProyecto/EUROSTAT/Eurostat.datasets.xlsx o
SelecciónDatasetsProyecto/WORLD_BANK/wb.datasets.xlsx. Cada
catálogo lo generó el *_TableDatasetGeneration.Rmd de su
carpeta recorriendo la API del organismo dataset a dataset; tú
no tienes que ejecutarlo, solo leer el Excel. Es un índice —una
fila por dataset con su ficha: identificador, nombre, frecuencia,
cobertura geográfica, fechas—, no contiene los
datos.
2. Búsqueda del tema. Busca dentro del catálogo los
datasets de tu tema: súbele el .xlsx a una IA y pídele los
identificadores relacionados, y que descarte los que no vayan a cumplir
los requisitos de arriba (README_Selección_Tema detalla qué
columna los anticipa en cada fuente). Lo que sale es una lista
de candidatos, no una elección: quien dice si un dataset sirve
es la etapa 3.
3. Descarga y validación. Copia los identificadores
en el fichero *_DatasetSelection.Rmd de la fuente
correspondiente: - INE: Dataset.Id <- 76136 - EUROSTAT:
dataset.name <- "nama_10r_2hhinc" - ISTAC/WB:
IDS <- c("ID1", "ID2", ...)
y haz Knit (Ctrl+Shift+K). El documento hace dos
cosas, en este orden: primero (3a) descarga los datos y los
guarda en disco —<nombre>.rds con
los datos ya limpios y <nombre>_metadatos.xlsx con la
ficha del dataset—; después (3b) los analiza leyendo esos dos
ficheros, y termina en una tabla de validación (verde = cumple
el criterio, rojo = no cumple) y un veredicto sobre el mínimo de 4
atributos. Además guarda ese análisis en un tercer fichero,
<nombre>_analisis.Rmd, preparado para la memoria.
4. Incorporación a la memoria. Los ficheros que ha guardado la etapa 3 se copian a la carpeta de tu memoria, y el análisis se incluye en ella con una sola instrucción; se explica más abajo, en Cómo importar los datos en la memoria (Paso 3 de esta guía). Que la descarga vaya primero y el análisis después es justo lo que lo hace posible: el análisis arranca leyendo del disco, así que funciona tal cual en tu memoria sin volver a descargar nada.
EDGAR, CLIMA e INFORME PISA son datasets únicos ya construidos: no tienen etapas 1 y 2 (no hay catálogo en el que buscar), pero sus documentos conservan la misma estructura 3a/3b, así que la incorporación a la memoria se hace igual. Sus ficheros
_analisis.Rmdya vienen generados en su carpeta.
Antes de confirmar un dataset, verifica en el Campus Virtual que ningún otro alumno lo haya elegido ya. Si hay solapamiento, consulta con el profesor.
Uso de la IA: un uso adecuado de los agentes IA puede facilitar mucho la exploración de los datasets y la búsqueda del tema del proyecto personal. La estrategia que sigas para seleccionar los datasets —catálogos explorados, peticiones a la IA, candidatos validados y descartados, y a qué pregunta de investigación responde cada dataset elegido— se describe en la sección Comprensión del negocio de la memoria. En todo el proyecto, la IA se usa con dos límites: entender lo que se hace y usar solo las librerías que aparecen en el libro de la asignatura, con un código comprensible teniendo en cuenta el contenido y el enfoque de la asignatura. Pide a la IA que dé prioridad al uso de las funciones de
utilidades.Ren vez de programar desde cero algo que esas funciones ya resuelven.
Abre ModeloMemoriaProyectoPersonalAEDV.Rmd en RStudio y
personaliza la cabecera:
title: "Mi título de Proyecto Personal" # ← tu título
author: "Mi nombre y apellidos" # ← tu nombreActiva “Knit on Save” (checkbox en la barra de
herramientas) para ver los cambios en el HTML cada vez que guardes con
Ctrl+S.
Atajos de teclado esenciales en RStudio
| Atajo | Acción |
|---|---|
Ctrl+Shift+K |
Compilar (Knit) el documento completo |
Ctrl+Alt+C |
Ejecutar el chunk donde está el cursor |
Ctrl+Enter |
Ejecutar la línea / código seleccionado |
Ctrl+Alt+I |
Insertar un nuevo chunk de código R |
Ctrl+Shift+1 |
El editor ocupa / deja de ocupar toda la ventana |
La memoria sigue la metodología de desarrollo
CRISP-DM (Cross Industry Standard Process for Data
Mining). Cada sección tiene instrucciones detalladas en comentarios HTML
(<!-- ... -->) que no aparecen en el
documento compilado pero te guían sobre qué escribir. La
memoria se organiza a través de las siguientes secciones:
Nota importante: los resultados NO van en una sección aparte; se presentan de forma distribuida en las fases de preparación de los datos, modelado, evaluación y despliegue. Esto es coherente con CRISP-DM.
Esta es la etapa 4 (incorporación) del flujo de
selección de datos del Paso 1. Al compilarse, cada
*_DatasetSelection.Rmd guarda, junto a los datos, un
fichero <nombre>_analisis.Rmd con su
sección Análisis del dataset (la etapa 3b) preparada
para la memoria, y termina con una sección, Incorporación del
dataset a la memoria, que indica exactamente qué ficheros copiar y
qué chunk pegar. Los pasos son dos:
ModeloMemoriaProyectoPersonalAEDV.Rmd los ficheros del
dataset: el .rds (o los .rds), el
_metadatos.xlsx y el _analisis.Rmd. En esa
carpeta tiene que estar también utilidades.R (viene en la
carpeta ProyectoPersonal, junto al modelo de memoria), que
la memoria carga en su chunk de librerías con
source("utilidades.R").*_DatasetSelection.Rmd, cambiando el nombre de la
tabla por uno que describa el dataset. Por ejemplo:```{r, results='asis', cache=FALSE}
ipc <- aedv_incluir_dataset("76136_analisis.Rmd")
```Al compilar la memoria, el análisis completo aparece en el lugar del
chunk —con sus tablas, su validación y los títulos colgando de
Comprensión de los datos— y los datos quedan en la tabla que
elijas (aquí ipc, un tibble), con la que se sigue
trabajando en el resto de la memoria. El análisis arranca leyendo del
disco los ficheros que acabas de copiar, así que funciona sin descargar
nada de internet. El chunk necesita las opciones
results='asis' (sin ella, el análisis saldría como texto
sin formato) y cache=FALSE. Al ejecutarlo en RStudio chunk
a chunk (Ctrl+Alt+C), la función solo carga los datos, sin
generar el análisis, para que puedas seguir trabajando con ellos.
aedv_incluir_dataset("...", validacion = FALSE) omite la
validación de requisitos AEDV, para no alargar la memoria con un dataset
que no tiene que cumplirlos.aedv_incluir_dataset() las devuelve juntas en una
lista, y el chunk que propone su documento las separa
justo después, cada una con su propio nombre. Por ejemplo, para CLIMA
Canarias:```{r, results='asis', cache=FALSE}
clima <- aedv_incluir_dataset("CLIMA_CANARIAS_analisis.Rmd")
clima_obs <- clima$data # observaciones mensuales por municipio, 1990-2022
clima_proy <- clima$proy # proyecciones por escenario, modelo y horizonte
```| Dataset | Tablas de la lista | Contenido |
|---|---|---|
| EDGAR | data, data_norm |
emisiones por país, sector y gas; emisiones per cápita y por unidad de PIB |
| CLIMA (Canarias y España) | data, proy |
observaciones mensuales; proyecciones por escenario, modelo y horizonte |
| INFORME PISA | pisa_paises, pisa_ccaa,
contexto_paises, contexto_ccaa |
resultados PISA y contexto socioeconómico, por país y por Comunidad Autónoma |
_analisis.Rmd no se edita:
se vuelve a generar cada vez que se compila el
*_DatasetSelection.Rmd. Tu texto va en la memoria, antes o
después del chunk.La parte de descarga (etapa 3a) no va en la memoria.
Lo que falta por hacer tras pegar el chunk
Pegar el chunk no es incorporar el dataset: solo es el primer paso. Antes de dar por completado el apartado Comprensión de los datos, es muy importante tener en cuenta lo siguiente:
Con frecuencia, para explicar el significado de las variables hace falta recurrir a la IA, dado que no viene en los metadatos: muchos datasets usan terminología técnica del organismo que los publica (códigos de clasificación, nombres de indicadores, categorías administrativas) que la ficha de metadatos no aclara, y preguntarle a una IA qué significa cada concepto o cada opción suele ser más rápido y más completo que buscarlo a mano.
Recuerda: registra en la Google Sheet el tiempo que dedicas a cada sesión de desarrollo del dashboard.
El dashboard es el elemento más importante de la fase de
Despliegue. Se construye y se prueba primero en tu
ordenador, y cuando funciona se despliega en el servidor Shiny
del DIS. Todo el proceso está explicado paso a paso, con WinSCP (o
Cyberduck/FileZilla en macOS) o con scp y ssh
desde la consola, en DashboardInstruccionesServidorShiny.html.
En resumen:
NombreApellido1Dashboard.Rmd (por ejemplo,
LuisAlvarezDashboard.Rmd) que lea los ficheros de datos de
su misma carpeta, sin rutas.https://www.dis.ulpgc.es/vpn/). El fichero
.ovpn de la VPN y el usuario y la contraseña de tu cuenta
en el servidor Shiny están en MiDIS
(https://www.dis.ulpgc.es/midis/), al que se entra con las
claves del Campus Virtual..Rmd y sus ficheros de datos a
la carpeta de tu cuenta en el servidor (10.22.143.222), con
WinSCP o Cyberduck/FileZilla (en macOS), o con scp desde la
consola.http://10.22.143.222:3838/sample-apps/aXXXX/NombreApellido1Dashboard.Rmd,
sustituyendo aXXXX por tu cuenta del servidor.ModeloMemoriaProyectoPersonalAEDV.Rmd, línea
[Cuadro de mandos](...)).Si funciona en tu ordenador pero no en el servidor, recuerda que el
servidor es Linux y distingue mayúsculas de minúsculas en los nombres de
fichero, que a veces hay que indicar la librería de una función
(libreria::funcion) y que los errores se consultan en los
ficheros de log del servidor (Paso 4 de las instrucciones del
servidor).
Errores comunes en el proyecto
NA. Una actividad empezada hay que
terminarla (con su nota final) antes de pasar a la siguiente.utilidades.R para lo que necesitas, pídele
que la use en vez de programar algo equivalente desde cero.Haciendo las entregas mal no se puede superar la asignatura
Para superar la asignatura en un curso académico, todas las entregas deben realizarse durante el periodo lectivo, siguiendo el calendario previsto y con un mínimo de calidad. En caso contrario el alumno deberá repetir la asignatura el curso siguiente. No se permitirá la entrega de proyectos en las convocatorias ordinaria, extraordinaria o especial cuyas entregas parciales no hayan sido supervisadas y validadas por el profesor durante el periodo lectivo.
RubricaEvaluaciónProyectoPersonal.xlsx)La evaluación del proyecto personal se estructura en torno a 29 criterios agrupados en siete áreas. Cada criterio se valora como No Satisfactorio, Satisfactorio o Sobresaliente. La columna E1/E2/E3 indica en qué entregas se tiene en cuenta cada criterio.
| # | Criterio | E1 | E2 | E3 |
|---|---|---|---|---|
| Alcance y calidad global | ||||
| 1 | Alcance y calidad del trabajo realizado | ✓ | ✓ | ✓ |
| 2 | Preguntas de investigación interesantes que justifican y cubren todos los datasets, y evolucionan con el análisis | ✓ | ✓ | ✓ |
| 3 | Documento revisado por el alumno: sin texto, código ni gráficas de la IA sin revisar | ✓ | ✓ | ✓ |
| Entrega y formato técnico | ||||
| 4 | Entrega memoria html + Rmd compilable, datos en RDS | ✓ | ✓ | ✓ |
| 5 | Enlace al Dashboard en el servidor Shiny del DIS + entrega de su
.Rmd |
✓ | ||
| 6 | Nombre de archivos correcto (NombreApellido1Memoria,
NombreApellido1Dashboard), ficheros sueltos sin
comprimir |
✓ | ✓ | ✓ |
| Texto y estructura de la memoria | ||||
| 7 | Texto atractivo, bien formateado, sin rastros de R | ✓ | ✓ | ✓ |
| 8 | Texto coherente con hilo conductor común | ✓ | ✓ | ✓ |
| 9 | Todas las secciones completadas siguiendo CRISP-DM | ✓ | ||
| 10 | Cada cosa en la sección que le corresponde | ✓ | ✓ | ✓ |
| 11 | Aportaciones y conclusiones coherentes con el trabajo | ✓ | ||
| Comprensión y preparación de los datos | ||||
| 12 | Información, origen y fiabilidad de los datasets | ✓ | ✓ | ✓ |
| 13 | Descripción detallada del procesado inicial de datos | ✓ | ✓ | |
| 14 | Conceptos manejados claros desde el principio | ✓ | ✓ | ✓ |
| 15 | Elección correcta de atributos para PCA | ✓ | ||
| Visualizaciones en la memoria | ||||
| 16 | Primeras gráficas ilustran los conceptos de forma general | ✓ | ✓ | |
| 17 | Gráficas de calidad profesional, sin solapamientos y autocontenidas | ✓ | ✓ | |
| 18 | Todas las gráficas dinámicas con identificación | ✓ | ||
| 19 | No repetir la misma gráfica con datos distintos | ✓ | ✓ | |
| 20 | Tipos requeridos: disco, barra, HeatMap, caja | ✓ | ✓ | |
| Dashboard | ||||
| 21 | Dashboard bien diseñado, cubre todas las variables e incluye los cinco cuadros de mandos de referencia | ✓ | ||
| 22 | Dashboard: series temporales con facet_wrap |
✓ | ||
| 23 | Dashboard: predicción con ARIMA o STL + ARIMA | ✓ | ||
| 24 | Dashboard: mapas coropléticos | ✓ | ||
| 25 | Dashboard: comparación de dos atributos con Yeo-Johnson | ✓ | ||
| 26 | Dashboard: matriz de correlación, PCA y k-means | ✓ | ||
| 27 | Dashboard: variables fijadas dinámicamente con Inputs | ✓ | ||
| Seguimiento y dedicación | ||||
| 28 | Uso de Google Sheet para control de dedicación | ✓ | ✓ | ✓ |
| 29 | Coherencia entre horas dedicadas y trabajo realizado | ✓ | ✓ | ✓ |
Criterio determinante
Alcance y calidad del trabajo realizado — Es el criterio con más peso en la evaluación. No se trata solo de cumplir los requisitos técnicos, sino de demostrar capacidad de análisis, pensamiento crítico y dominio del tema. Un proyecto técnicamente correcto pero superficial no alcanza la calificación máxima. Se valora además un uso inteligente de la IA, entendiendo y corrigiendo las aportaciones de la IA.
Preguntas de investigación. El proyecto plantea preguntas de investigación interesantes, concretas y que se pueden responder con los datos, y la elección de los datasets se justifica a partir de ellas (la estrategia de selección y el uso de la IA se describen en Comprensión del negocio). Todos los datasets de la memoria deben estar cubiertos por al menos una pregunta: un dataset que no responde a ninguna pregunta de investigación es un dataset sin justificar. Las preguntas iniciales de la Entrega 1 se van refinando por iteraciones a partir del análisis de los datos, y las de la memoria final se responden una a una en las Conclusiones. Un proyecto cuyo único argumento es que el dataset cumple los requisitos de AEDV no supera este criterio.
Documento revisado por el alumno. El texto, el código y las gráficas deben mostrar que has leído, entendido y corregido todo lo que entregas, también lo que hayas generado con ayuda de la IA. Los indicios de un documento no revisado que se tienen en cuenta están en el recuadro Revisa tú el documento: se nota cuando no se ha hecho, en Qué tienes que entregar. Este criterio afecta a la calificación del proyecto y, si el resultado es muy deficiente, la entrega puede calificarse como NO APTA.
Un proyecto de calidad sobresaliente integra los datos con una narrativa coherente, extrae conclusiones no triviales, aplica correctamente la metodología CRISP-DM y presenta los resultados de forma clara y profesional tanto en la memoria como en el dashboard.
Estos criterios son de carácter binario: o se cumplen o no se cumplen. Un fallo en cualquiera de ellos puede impedir la corrección del trabajo.
Entrega memoria en HTML y código en Rmd compilable, con
datos en RDS. Se entrega el .html compilado más el
.Rmd con los datos en formato .rds y metadatos
(si hay) en formato .xlsx, junto con los ficheros
_analisis.Rmd de los datasets y utilidades.R,
sin los que la memoria no compila. El código debe funcionar en cualquier
ordenador sin modificaciones: rutas relativas, sin dependencias externas
y solo las librerías que aparecen en el libro de la asignatura. Si la
imagen de portada es un fichero local, también hay que
entregarla junto al .Rmd. Esto se verifica desde la Entrega
1; un .Rmd que no compila equivale a no entregado. Para
comprobarlo antes de enviar, compila la memoria desde una carpeta
temporal que contenga solo los ficheros que vas a subir (recuadro
Comprueba que la memoria compila solo con los ficheros que vas a
subir, en Qué tienes que entregar).
Enlace al Dashboard en el servidor Shiny del DIS
(solo Entrega 3). El enlace debe aparecer al inicio de la
memoria y estar operativo en el momento de la corrección. Un dashboard
caído o inaccesible sin VPN equivale a no entregado. Además del
despliegue, hay que entregar también el .Rmd del
dashboard (el mismo fichero que subes al servidor Shiny), junto
con el resto de ficheros.
Nombre de archivos correcto. El
.Rmd y el .html de la memoria, y también el
.Rmd del dashboard, deben empezar por
NombreApellido1. Por ejemplo:
LuisAlvarezMemoria.Rmd,
LuisAlvarezMemoria.html y
LuisAlvarezDashboard.Rmd. Esto facilita la gestión de
entregas. Sube los ficheros sueltos al Campus Virtual, nunca
comprimidos en un .zip o .rar: el
profesor necesita poder abrir cada fichero directamente para
corregirlo.
La memoria no es un cuaderno de laboratorio: es un documento académico que debe leerse con fluidez de principio a fin.
Texto atractivo, bien formateado, sin rastros de
R. El documento HTML no debe mostrar código R, mensajes de
carga de librerías, advertencias ni salidas de consola. El modelo de
memoria ya trae echo=FALSE por defecto en las opciones
globales (knitr::opts_chunk$set(...)): no lo cambies a
echo=TRUE salvo en algún chunk puntual que quieras mostrar
a propósito. El parámetro message=FALSE, warning=FALSE debe
estar activo en los chunks que los generen. No se debe incluir
toc: true en el cuerpo del texto — eso ya está configurado
en la cabecera YAML. El uso de negritas, secciones bien delimitadas y
párrafos cortos mejora la legibilidad. Usar bloques coloreados para
enfatizar aspectos relevantes también ayuda mucho a la lectura.
Texto coherente con hilo conductor común. Cada sección debe conectar con la anterior. La introducción plantea preguntas que el análisis responde; las conclusiones cierran esas preguntas. Evita secciones que parezcan escritas de forma independiente y pegadas sin relación entre sí.
Todas las secciones completadas correctamente siguiendo la metodología CRISP-DM (solo Entrega 3). El modelo de memoria tiene secciones fijas que deben aparecer todas y estar desarrolladas, y cada una debe contener lo que le corresponde según la fase CRISP-DM que representa. Una sección con solo el título o con el texto de ejemplo sin sustituir se considera no completada.
Cada cosa en su sección. Los resultados no van en una sección propia: se presentan dentro de Preparación de los datos, Modelado, Evaluación y Despliegue, según el momento CRISP-DM al que correspondan. Las tablas de estructura de datos van en Comprensión de los datos, no en Preparación.
Aportaciones y conclusiones coherentes con el trabajo. Las conclusiones deben derivarse directamente del análisis realizado, no ser genéricas. Las aportaciones deben ser específicas al dominio estudiado y al dataset elegido.
Lo que se valora en esta área
El evaluador comprueba que el alumno entiende los datos que está usando, no solo que los ha cargado correctamente.
Información, origen y fiabilidad de los datasets. La sección “Comprensión de los datos” debe incluir: fuente y descripción del dataset, quién lo publica y con qué garantías de fiabilidad, cobertura geográfica y temporal, número de observaciones y variables, tipos de datos, y una exploración inicial (distribuciones, valores ausentes, outliers). No basta con decir “el dataset tiene X filas y Y columnas”.
Descripción detallada del procesado inicial de datos. Cada transformación aplicada — filtros, joins, cambios de formato, imputación de nulos, normalización — debe estar explicada y justificada. El lector debe poder reproducir el proceso de preparación leyendo este apartado.
Conceptos claros desde el principio. Si el proyecto trabaja con conceptos especializados (tasas de natalidad, índice de Gini, emisiones per cápita…), estos deben definirse la primera vez que aparecen. No se puede asumir que el lector los conoce.
Elección correcta de atributos para el PCA (solo Entrega 3). Para el análisis de componentes principales deben seleccionarse al menos cuatro atributos de interés e independientes por área geográfica. Las demás variables libres deben fijarse o filtrarse correctamente, de modo que el PCA se calcule sobre un conjunto bien definido y comparable entre áreas.
Las gráficas son el elemento más visible de la memoria. Una mala gráfica comunica más descuido que páginas de texto.
Las primeras gráficas ilustran los conceptos de forma
general y clara. No se debe empezar el análisis con gráficas
muy detalladas o de subconjuntos específicos. Las primeras
visualizaciones deben dar una visión global del fenómeno estudiado antes
de entrar en detalles. Una buena idea suele ser empezar presentado la
evolución de algunas series temporales usando
facet_wrap
Calidad profesional: sin textos solapados ni códigos
visibles, y autocontenidas. Los ejes deben tener etiquetas
legibles, sin textos solapados ni cortados, las leyendas no deben
solaparse con los datos y los títulos deben ser informativos. El tamaño
de fuente debe ser legible: usa theme_minimal() o similar y
ajústalo si hay muchas categorías. Además, cada gráfica debe ser
autocontenida: entenderse sin ambigüedad con la sola
información que aparece en ella; si hace falta, añade un
fig.cap en el chunk para explicarla mejor.
Sobre las etiquetas identificativas en los gráficos: Para que un gráfico se entienda no puede usar códigos como etiquetas identificativas, es decir si, por ejemplo aparecen CCAA, no se pueden identificar en el gráfico por su código (por ejemplo “ES70” en lugar de “Canarias”). Además si las etiquetas son largas hay que cambiarlas por cortas que quepan en el gráfico, esto pasa con frecuencia por ejemplo, en sectores económicos o enfermedades que pueden tener nombres muy largos. También hay que acortar nombres de regiones cuando son innecesariamente largos para identificarlos. Por ejemplo “Comunidad Foral de Navarra” se puede sustituir por “Navarra”
Algunos errores a evitar en los gráficos
fig.asp).Requisito para que el proyecto sea APTO
Todos los gráficos del proyecto deben cumplir estos requisitos de calidad. Basta con que algunos no los cumplan para que el proyecto no se considere apto.Todas las gráficas dinámicas. Todas las
visualizaciones de la memoria deben ser interactivas (Plotly o similar).
Una gráfica estática de ggplot sin convertir con ggplotly()
o renderPlotly() no cumple este criterio. El título,
subtítulo o fig.cap deben identificar claramente qué
muestra la gráfica.
No repetir la misma gráfica cambiando los datos.
Si una gráfica de serie temporal funciona bien para un atributo, no la
repitas para otros cinco atributos consecutivos con el mismo código. Usa
facet_wrap o presenta un selector interactivo en el
dashboard.
Gráficas de disco, barra, HeatMap y diagramas de caja en la memoria. La memoria debe incluir al menos estos cuatro tipos de gráficas. Cada tipo tiene un propósito: los diagramas de caja para distribuciones y comparación entre grupos, los HeatMaps para correlaciones o evolución temporal cruzada, los de disco para proporciones, y los de barra para comparaciones categóricas.
Tablas grandes: recortadas y con scroll. Una
tabla con muchas filas o columnas mostrada entera ocupa demasiado
espacio en la memoria sin aportar nada. Si su tamaño es excesivo,
recórtala antes de mostrarla: quédate con las columnas
relevantes (select()) y con las primeras filas
(slice(1:10)) o las que interesen (filter()).
Después, envuelve el chunk en
<div class="tabla-scroll-xy"> (estilo
definido en estilos.css): la tabla se muestra con la
cabecera fija y unas pocas filas a la vista, y el resto se recorre con
barras de desplazamiento horizontal y vertical. Deja una línea en blanco
antes y después del chunk, y termina la tabla con
knitr::kable(): sin él, la tabla sale como texto de consola
y el recuadro no tiene nada que desplazar. Por ejemplo:
<div class="tabla-scroll-xy">
```{r}
datos |> select(region, fecha, valor) |> slice(1:10) |> knitr::kable()
```
</div>El dashboard es el entregable técnico más exigente. Debe estar desplegado y accesible el día de la entrega.
Los cuadros de mandos de referencia son obligatorios
Tu dashboard debe incluir obligatoriamente, como páginas, los cinco cuadros de mandos de referencia de la asignatura, adaptados a tus datos. Puedes descargarlos desde estos enlaces:
Como ejemplo mínimo de un dashboard que reúne las cinco páginas aplicadas a un mismo dataset tienes Dashboard_eurostat_gasto_publico.Rmd, con el gasto público por sectores de Eurostat. Cada página elige cada atributo (país, sector, medida, año) con su propio desplegable y ofrece todas las opciones de los datos. Es un punto de partida: tu dashboard tiene que cubrir todas las variables de tu dataset, con el mismo criterio.
La carga del dashboard puede ser lenta: cómo acelerarla
Un dashboard con varias páginas puede tardar en abrirse, porque al arrancar se ejecuta todo el documento: se cargan las librerías, se leen los datos y se calculan todas las páginas. Algunas estrategias sencillas para acelerarlo (el ejemplo mínimo de arriba aplica casi todas):
.rds. Si antes de usar los datos los filtras,
cambias de formato o unes tablas, haz ese preprocesado una sola vez
fuera del dashboard, guarda el resultado con saveRDS() y,
en el dashboard, carga directamente esa tabla procesada con
readRDS().actionButton() con eventReactive()): así, al
abrir el dashboard no se calcula nada, y cada página solo hace sus
cuentas cuando el usuario lo pide.global. En un flexdashboard con Shiny, el chunk
llamado global (```{r global, include=FALSE})
se ejecuta una sola vez y lo comparten todos los usuarios. Pon ahí las
librerías, utilidades.R y la lectura de los datos, y lee
los datos una sola vez aunque los usen varias
páginas..rds, quita las columnas y filas que el dashboard no
usa. Con los mapas, recorta la geometría a las áreas de tus datos: es lo
que se envía al navegador cada vez que se dibuja el mapa.global, se repiten cada vez que alguien abre el
dashboard.Bien diseñado e ilustra los datos en su máxima generalidad. El dashboard no es un subconjunto de la memoria: debe permitir explorar todas las variables originales del dataset, no solo las que se analizaron en la memoria. El diseño visual debe ser limpio, con paneles bien organizados y controles intuitivos. Además, debe incluir, como mínimo, las páginas de los cinco cuadros de mandos de referencia adaptados a tus datos (recuadro de arriba).
Variables fijadas dinámicamente con Inputs. Todas las variables del dashboard deben controlarse mediante Inputs interactivos (selectores, sliders, etc.). No se deben fijar valores a mano en el código: el usuario ha de poder cambiar la variable, el año o la región desde la interfaz.
Estos criterios se verifican, no se declaran
Las fechas de la Google Sheet son verificables. Un registro reconstruido al final, con todas las sesiones en los últimos días antes de la entrega, no es creíble y se valora como No Satisfactorio.
Uso de Google Sheet para el control de
dedicación. La hoja debe estar activa desde el principio del
proyecto, con entradas regulares que reflejen el progreso real, y debe
estar operativa y dar resultados coherentes: sin
valores NA y sin actividades incompletas (sin fecha de
inicio, sin fecha de fin o sin minutos calculados). La memoria la lee
automáticamente para generar el Anexo II — si la hoja no está bien
configurada o tiene actividades a medio registrar, el documento puede no
compilar o el Anexo II puede salir con huecos.
Coherencia entre horas registradas y trabajo realizado. Un proyecto muy elaborado con pocas horas registradas, o muchas horas con un resultado pobre, genera inconsistencias que el evaluador detecta. El registro de actividades debe ser acorde al nivel de desarrollo de cada fase CRISP-DM.