# Rúbrica Analítica de Evaluación — Proyecto Final Integrador (ABP - FBC) **Asignatura:** TEL-420 · Sistemas Paralelos **Docente:** Ing. Elias Cassal Baldiviezo **Escala:** 100 puntos (Ponderación formativa y sumativa transversal EC1–EC5) **Modalidad:** Aprendizaje Basado en Proyectos (ABP) bajo Formación Basada en Competencias (FBC) **Equipos:** Máximo 3 estudiantes --- ## 1. Propósito de la Evaluación Evaluar de manera integral la competencia general del Proyecto Formativo: > *"Resuelve problemas computacionales complejos de alto impacto regional mediante el diseño, despliegue y optimización de infraestructuras paralelas (cústeres virtualizados/contenerizados) y la implementación de algoritmos concurrentes bajo estándares de memoria compartida, memoria distribuida o aceleración por hardware, evaluando cuantitativamente el rendimiento y la escalabilidad bajo principios de ética y responsabilidad social."* La matriz analítica se desglosa en cuatro dimensiones con sus respectivos porcentajes: 1. **SABER (Conceptual) — 25 %:** Fundamentación teórica y arquitectónica. 2. **SABER HACER 1 (Procedimental) — 30 %:** Diseño e implementación de código paralelo. 3. **SABER HACER 2 (Procedimental) — 25 %:** Infraestructura, benchmarking y reproducibilidad. 4. **SABER SER (Actitudinal) — 20 %:** Pertinencia regional, innovación y trabajo en equipo. --- ## 2. Matriz Analítica de Evaluación (100 Puntos) | Dimensión | Criterio de Desempeño | Indicadores de Evaluación | Excelente (100 %) | Bueno (75 %) | Aceptable / Regular (50 %) | Insuficiente (0–25 %) | Puntaje Máx. | |---|---|---|---|---|---|---|---| | **SABER (Conceptual)**
**25 %** | **Fundamentación Teórica y Arquitectónica:**
Domina los modelos de memoria, leyes de rendimiento y taxonomía del hardware utilizado. | • Explica rigurosamente el impacto de la Ley de Amdahl y Gustafson en su proyecto.
• Identifica con precisión los cuellos de botella de red y memoria de la arquitectura Dell OptiPlex utilizada.
• Responde con solidez conceptual durante la defensa oral individual. | Domina y argumenta con rigor matemático los límites de Amdahl y Gustafson. Identifica con exactitud cuellos de botella en memoria/red del clúster Dell OptiPlex y responde todas las preguntas teóricas con solidez profesional. (23–25 pts) | Explica correctamente las leyes de rendimiento y cuellos de botella del hardware con fallos menores en la deducción matemática o en conceptos avanzados de memoria. (18–22 pts) | Conoce superficialmente las leyes de Amdahl/Gustafson; confusión entre escalabilidad fuerte y débil; dificultad para responder interpelaciones teóricas individuales. (12–17 pts) | Desconoce los modelos teóricos, no puede justificar el comportamiento de la aceleración ni responde preguntas teóricas en la defensa oral. (0–11 pts) | **25 pts** | | **SABER HACER 1 (Procedimental)**
**30 %** | **Diseño e Implementación de Código Paralelo:**
Desarrolla software concurrente eficiente, libre de condiciones de carrera y optimizado. | • Paralelización efectiva y correcta mediante OpenMP, MPI o esquema híbrido.
• Uso justificado de cláusulas de sincronización, particionamiento y reducción.
• Verificación empírica de corrección matemática frente al modelo secuencial. | Implementación paralela limpia, modular y robusta (OpenMP/MPI/híbrido). Cero condiciones de carrera, falsas comparticiones ni deadlocks. Verificación matemática estricta y automática del resultado paralelo frente al secuencial ($T_1$). (27–30 pts) | Implementación paralela correcta y funcional que produce aceleración medible. Uso adecuado de directivas/comunicaciones, con detalles menores de modularidad o optimización. (22–26 pts) | Código compila y ejecuta, pero presenta ineficiencias graves (sincronización excesiva, serialización oculta o falsas comparticiones) o requiere ajustes para coincidir con el resultado secuencial. (15–21 pts) | El código no compila, produce resultados matemáticamente incorrectos, presenta carreras críticas/deadlocks o no logra ninguna paralelización efectiva. (0–14 pts) | **30 pts** | | **SABER HACER 2 (Procedimental)**
**25 %** | **Infraestructura, Benchmarking y Reproducibilidad:**
Conteneriza el entorno y mide rigurosamente el rendimiento alcanzado. | • Despliegue funcional del clúster virtual/contenerizado (Docker/Slurm) en el laboratorio.
• Obtención de gráficas experimentales de Speedup, Eficiencia y Escalabilidad.
• Repositorio en GitHub 100% reproducible mediante scripts automatizados. | Despliegue impecable en clúster (Docker Compose / Slurm multi-nodo) en equipos Dell OptiPlex (32 GB). Repositorio GitHub con estructura obligatoria reproducible en un solo comando (`./benchmark.sh`). Gráficas y tablas experimentales completas y rigurosas. (23–25 pts) | Clúster funcional y mediciones correctas de Speedup y Eficiencia. Scripts de benchmarking operativos con pequeños pasos manuales en el despliegue o gráficas incompletas. (18–22 pts) | Clúster desplegado con inestabilidades; pruebas experimentales insuficientes (pocos puntos de datos, sin promedios de calentamiento); repositorio desordenado o difícil de replicar. (12–17 pts) | No logra desplegar la infraestructura de clúster ni contenedor; carece de script automatizado de benchmarking o no entrega repositorio reproducible en GitHub. (0–11 pts) | **25 pts** | | **SABER SER (Actitudinal)**
**20 %** | **Pertinencia Regional, Innovación y Trabajo en Equipo:**
Aplica la solución a un problema real de Yacuiba/Chaco con ética y profesionalismo. | • La temática elegida aborda una necesidad productiva, ambiental o social tangible de la región.
• Demuestra pensamiento crítico e iniciativa para superar restricciones de hardware.
• Trabajo colaborativo articulado y defensa técnica profesional del equipo. | Problema de alta relevancia para el Gran Chaco (cuenca Pilcomayo, incendios, agroclima o logística). Solución innovadora y creativa ante limitaciones de hardware. Equipo coordinado, ético y defensa técnica con demo en vivo impecable (20 min). (18–20 pts) | Problema regional pertinente y bien contextualizado. Buena dinámica de equipo y defensa oral estructurada con pequeñas dudas durante la demostración en vivo. (15–17 pts) | El tema es genérico o escasamente contextualizado a la región; participación desigual entre los integrantes del grupo durante la defensa o demo inestable. (10–14 pts) | Tema abstracto o trivial (ejercicio de juguete sin aplicación real); desarticulación evidente del grupo; actitud pasiva o incumplimiento ético en el desarrollo. (0–9 pts) | **20 pts** | | **TOTAL** | | | | | | | **100 pts** | --- ## 3. Entregables Asociados y Ponderación Relativa | Entregable | Formato | Dimensión Evaluada | Peso Relativo | |---|---|---|---| | **Entregable A:** Informe Técnico de Ingeniería | Paper IEEE (PDF, máx. 10 páginas) | SABER (25 %) + Análisis de resultados | Evaluado en rúbrica global | | **Entregable B:** Repositorio y Reproducibilidad | GitHub / GitLab (`src/`, `infrastructure/`, `scripts/`) | SABER HACER 1 (30 %) + SABER HACER 2 (25 %) | Evaluado en rúbrica global | | **Entregable C:** Defensa Técnica y Live Demo | 20 minutos (10 min exposición + 10 min demo / preguntas) | SABER SER (20 %) + Interpelación conceptual | Evaluado en rúbrica global | --- ## 4. Baremo de Calificación Institucional UAJMS - **90 – 100 pts (Excelente / Sobresaliente):** Cumple con excelencia todas las dimensiones. Aporte real a la ingeniería regional con solución HPC reproducible. - **75 – 89 pts (Notable / Muy Bueno):** Proyecto sólido con paralelización efectiva, clúster funcional y buen análisis de aceleración. - **51 – 74 pts (Aprobado / Suficiente):** Cumplimiento básico de requisitos mínimos funcionales; deficiencias en optimización o fundamentación. - **0 – 50 pts (Reprobado / Insuficiente):** No alcanza las competencias mínimas de paralelización, código inoperativo o falta de reproducibilidad.