Contexto, requisitos y priorización — lo que el equipo entregó en las Actividades 1 y 2.
La Institución Universitaria Horizonte creció, y cada área adquirió o construyó su propia herramienta. Hoy el estudiante debe navegar entre varias plataformas distintas para lo académico, lo financiero y lo administrativo.
Mayor reto identificado: integrar los sistemas existentes y permitir que la solución crezca, sin afectar los procesos institucionales que ya funcionan.
| Funcionalidad | Prioridad |
|---|---|
| Consultar información académica | ALTA |
| Realizar procesos de matrícula | ALTA |
| Consultar información financiera | ALTA |
| Iniciar procesos de pago | ALTA |
| Realizar solicitudes y trámites | MEDIA |
| Consultar estado de solicitudes y notificaciones | MEDIA |
Los estudiantes no siempre saben dónde hacer cada trámite.
Miles de estudiantes en matrícula al mismo tiempo, y la institución espera crecer.
Información personal, académica y financiera, con distintos niveles de acceso.
Restricciones clave: los sistemas actuales deben seguir funcionando durante la transición · las operaciones financieras deben ser verificables · la demanda tiene picos fuertes en matrícula.
| ID | Requisito | |
|---|---|---|
| R01 | Info académica | M |
| R02 | Matrícula | M |
| R03 | Horarios/asignaturas | M |
| R04 | Iniciar pagos | M |
| R05 | Solicitudes/trámites | S |
| R06 | Estado de solicitud | S |
| ID | Requisito | |
|---|---|---|
| R07 | Control de acceso | M |
| R08 | Evitar pago duplicado | M |
| R09 | Multi-dispositivo | S |
| R10 | Reemplazar sistemas | W |
| R11 | Noticias/avisos | C |
| R12 | Notificaciones | S |
M = Must · S = Should · C = Could · W = Won't (por ahora)
| ID | Requisito | |
|---|---|---|
| R11 | Noticias/avisos | C |
| R12 | Notificaciones | S |
| R13 | Punto de acceso común | M |
| R14 | Proteger info sensible | M |
| R15 | Mantener sistemas operativos | M |
| ID | Requisito | |
|---|---|---|
| R16 | Integración progresiva | M |
| R17 | Trazabilidad financiera | M |
| R18 | Incorporar nuevos servicios | S |
| R19 | Reducir procesos manuales | C |
| R20 | Centralizar seguimiento | S |
R14 se solapa con R07 (control de acceso) y R17 con R08 (evitar pago duplicado) — casi el mismo requisito redactado dos veces con distinto enfoque.
| Criterio | Peso | Por qué |
|---|---|---|
| Valor para el negocio | 30% | Objetivo central de la iniciativa |
| Valor para el usuario | 25% | El dolor principal es la experiencia fragmentada |
| Riesgo | 20% | Pagos y datos sensibles, consecuencias serias |
| Urgencia | 15% | Ventana corta cada semestre |
| Impacto arquitectónico | 10% | Condiciona el diseño, pero pesa menos que lo inmediato |
Puntaje = Σ (calificación × peso) · escala 1–5
Azul = Must · Ámbar = Should · Verde = Could · Rojo = Won't
R03 (Must) cae al puesto 15 de 20, muy por debajo de varios Should.
R10 (Won't) no queda último — puesto 18, por encima de R06, R11 y R19.
Motivo: "riesgo" e "impacto arquitectónico" miden gravedad de la consecuencia, no conveniencia de hacerlo.
R14 y R17 (los requisitos que se solapan con R07 y R08) quedan muy cerca de sus pares en el ranking — otra señal de que están midiendo casi lo mismo dos veces.
Por eso comparamos los dos métodos: ninguno alcanza solo — cada uno expone un sesgo que el otro no ve.
Integración con proveedores externos
Exige idempotencia y auditoría
Permisos transversales a toda la plataforma
Concurrencia alta en ventanas cortas
No son siempre los más urgentes para el usuario — pero un cambio ahí obliga a rediseñar la estructura.
Todo lo mostrado hoy responde a evidencia del caso, no a preferencia del equipo — esa es la regla que seguimos en ambas actividades.
Equipo 5 · ConectaDev — Darell Estren · Joshua Orbes · Ximena Rangel · Jonnathan Reyes · Karelys Vargas