Contexto, requisitos y priorización — lo que el equipo entregó en las Actividades 1 y 2.
Darell Estren · Joshua Orbes · Ximena Rangel · Jonnathan Reyes · Karelys Vargas
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 | MoSCoW |
|---|---|---|
| Info académica | M | |
| Matrícula | M | |
| Horarios/asignaturas | M | |
| Iniciar pagos | M | |
| Solicitudes/trámites | S | |
| Estado de solicitud | S |
| ID | Requisito | MoSCoW |
|---|---|---|
| Control de acceso | M | |
| Evitar pago duplicado | M | |
| Multi-dispositivo | S | |
| Reemplazar sistemas | W | |
| Noticias/avisos | C | |
| Notificaciones | S |
M = Must · S = Should · C = Could · W = Won't (por ahora)
| ID | Requisito | MoSCoW |
|---|---|---|
| Noticias/avisos | C | |
| Notificaciones | S | |
| Punto de acceso común | M | |
| Proteger info sensible | M | |
| Mantener sistemas operativos | M |
| ID | Requisito | MoSCoW |
|---|---|---|
| Integración progresiva | M | |
| Trazabilidad financiera | M | |
| Incorporar nuevos servicios | S | |
| Reducir procesos manuales | C | |
| Centralizar seguimiento | S |
R14 comparte dominio con R07 (protección de datos vs. control de acceso) y R17 con R08 (trazabilidad vs. evitar duplicados) — facetas relacionadas del mismo problema, no el mismo requisito repetido.
| 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 · Click o Enter sobre una barra para ver el detalle.
Escala 1–5 por criterio · Puntaje = Σ (calificación × peso) · Click en un ID para ver el detalle.
(Must) cae al puesto 15 de 20, muy por debajo de varios Should.
(Won't) no queda último — puesto 18, por encima de y .
Motivo: "riesgo" e "impacto arquitectónico" miden gravedad de la consecuencia, no conveniencia de hacerlo.
y quedan muy cerca de y en el ranking — no porque midan lo mismo, sino porque los cuatro pertenecen a los dos dominios más críticos del caso: control de acceso y seguridad financiera.
Por eso comparamos los dos métodos: ninguno alcanza solo — cada uno expone un sesgo que el otro no ve.
Click en un código (R03, R10...) para ver su puntaje y racional sin volver a la slide anterior.
| ID | Requisito | Qué condiciona en la arquitectura |
|---|---|---|
| Carga y escalabilidad | ||
| Matrícula | Capacidad de respuesta ante picos de demanda | |
| Pagos y trazabilidad financiera | ||
| Iniciar pagos | Comunicación con plataformas de pago externas | |
| Evitar pago duplicado | Verificación de operaciones financieras | |
| Trazabilidad financiera | Verificación y rastreo de transacciones | |
| Seguridad y acceso | ||
| Control de acceso | Permisos según el tipo de usuario | |
| Proteger info sensible | Protección y control de acceso a los datos | |
| Convivencia con lo existente | ||
| Reemplazar sistemas (restricción) | Convivencia con los sistemas existentes | |
| Mantener sistemas operativos | Continuidad durante la transición | |
| Integración progresiva | Comunicación entre sistemas heterogéneos | |
| Crecimiento futuro | ||
| Incorporar nuevos servicios | Facilidad de crecimiento futuro | |
No son siempre los más urgentes para el usuario — pero un cambio ahí obliga a rediseñar la estructura. Estos 10 sustentan los 5 drivers que siguen. Click en un ID para ver su detalle.
| # | Atributo | Por qué |
|---|---|---|
| 1 | Seguridad | Información personal, académica y financiera con distintos niveles de acceso. |
| 2 | Escalabilidad | Picos de miles de usuarios en matrícula, más el crecimiento esperado de la institución. |
| 3 | Interoperabilidad | Sistemas académico y financiero heterogéneos que deben seguir operando durante la transición. |
| 4 | Disponibilidad | UNIConecta es el punto de acceso principal — si falla, se afecta toda la operación institucional. |
| 5 | Usabilidad | Hoy no está claro qué plataforma usar para cada trámite. |
| Pregunta | Quién podría responder |
|---|---|
| Usuarios simultáneos y tiempo de respuesta esperado en matrícula | Dirección de Tecnología / Infraestructura |
| Nivel de disponibilidad requerido y tiempo máximo de recuperación ante fallas | Dirección de Tecnología / Servicios Digitales |
| Cómo inicia sesión el usuario — ¿reutiliza las credenciales institucionales actuales? | Dirección de Tecnología |
| Qué sistemas existentes se integran primero, y cuáles ya tienen API | Administradores de sistemas institucionales |
| Qué puede consultar, modificar o ejecutar cada tipo de usuario | Rectoría / Talento Humano / Tecnología |
| Presupuesto disponible para el proyecto y su operación | Rectoría / Dirección Financiera |
El caso reconoce que nadie en la reunión inicial supo responder estos datos — no es que se nos pasó preguntarlos.
Convertimos cada atributo priorizado en una condición observable — Fuente → Estímulo → Respuesta → Medida.
Pendiente de validar con el cliente: usuarios simultáneos máximos, tiempo de respuesta aceptable, % de disponibilidad requerido y qué sistemas puntuales se integran primero.
| # | Driver | Origen |
|---|---|---|
| 1 | Integración progresiva y coexistencia con sistemas existentes | R15, R16 · Interoperabilidad |
| 2 | Integridad y trazabilidad de las operaciones financieras | R04, R08, R17 · Seguridad |
| 3 | Soportar picos de demanda y el crecimiento futuro | R02, R18 · Escalabilidad |
| 4 | Seguridad y control de acceso según el tipo de usuario | R07, R14 · Seguridad |
| 5 | Centralizar el acceso y seguimiento de los servicios | R01, R05, R06, R12, R13, R20 · Usabilidad |
Equipo 5 · ConectaDev