EGEL Plus de Informática 2026: temario, estructura y diagnóstico

Modelo Canvas y propuesta de valor

El Modelo Canvas organiza un negocio en nueve bloques (segmentos de clientes, propuesta de valor, canales, relaciones, ingresos, recursos, actividades, socios y costos). El examen suele pedir ubicar en qué bloque se documenta un elemento específico del negocio. El error común es confundir la propuesta de valor (por qué el cliente elegiría esta oferta) con los canales (cómo se le entrega) o las fuentes de ingresos (cómo se cobra por ella).

Análisis FODA y diagramas causa-efecto

El FODA distingue factores internos (fortalezas y debilidades) de factores externos (oportunidades y amenazas) al planear una solución informática; los diagramas causa-efecto (Ishikawa) ayudan a identificar las causas raíz de un problema organizacional antes de proponer un sistema. Se confunde una debilidad interna (por ejemplo, personal sin capacitación) con una amenaza externa (por ejemplo, un competidor con mejor tecnología).

Requerimientos funcionales y no funcionales

Los requerimientos funcionales describen qué debe hacer el sistema (registrar una venta, generar un reporte); los no funcionales describen bajo qué condiciones de calidad debe hacerlo (tiempo de respuesta, capacidad, seguridad, disponibilidad). El examen presenta una lista de requerimientos y pide clasificar cada uno. El error frecuente es tratar una condición de desempeño como si fuera una función del sistema.

Evaluación de alternativas tecnológicas

Comparar dos propuestas de solución no debe limitarse al precio de adquisición: el costo total de propiedad (TCO) incluye implementación, capacitación, mantenimiento y soporte a lo largo de la vida útil. El error común es elegir la opción más barata al inicio sin proyectar sus costos recurrentes.

Ruta crítica y estimación con PERT

La ruta crítica es la secuencia de actividades dependientes cuya duración total fija el tiempo mínimo del proyecto; retrasar cualquiera de ellas retrasa todo el proyecto, porque no tienen holgura. La técnica PERT estima la duración de una actividad combinando un tiempo optimista, uno más probable y uno pesimista. El error frecuente es confundir las actividades con holgura (que sí pueden retrasarse) con las de la ruta crítica (que no pueden).

Estimación de costos y análisis de riesgos

Antes de aprobar un proyecto se estima su presupuesto y se identifican los riesgos que podrían afectarlo, clasificándolos según probabilidad e impacto. El examen pide priorizar riesgos o identificar qué falta en una estimación de costos incompleta.

Control de cambios durante la ejecución

Un cambio de alcance solicitado a mitad del proyecto debe evaluarse mediante un proceso formal de control de cambios (impacto en costo, tiempo y calidad) antes de aprobarse, para evitar la ampliación no controlada del alcance. El error común es incorporar cualquier solicitud del cliente sin evaluarla primero.

Cierre formal y lecciones aprendidas

Un proyecto no se considera cerrado solo porque el sistema entró en producción: falta obtener la aceptación formal de los entregables y documentar las lecciones aprendidas para futuros proyectos. El error frecuente es confundir la puesta en producción (parte de la ejecución) con el cierre administrativo del proyecto.

Roles en metodologías ágiles

En Scrum, el Product Owner prioriza y mantiene el Product Backlog según el valor para el negocio; el Scrum Master facilita el proceso y elimina obstáculos, sin decidir qué se construye. El examen plantea un escenario de equipo y pide identificar de quién es la responsabilidad. El error común es asignar al Scrum Master decisiones de priorización que corresponden al Product Owner.

Lenguajes compilados e interpretados

Un lenguaje compilado traduce todo el programa a código máquina antes de ejecutarlo; uno interpretado traduce y ejecuta instrucción por instrucción en tiempo de ejecución. Se confunde la portabilidad de un programa con el hecho de que su lenguaje sea compilado o interpretado, cuando ambos modelos pueden diseñarse pensando en portabilidad.

Modelo relacional: llaves primarias y foráneas

La llave primaria identifica de forma única cada fila de una tabla; la llave foránea referencia la llave primaria de otra tabla para establecer una relación y garantizar integridad referencial. El examen puede pedir identificar el tipo de combinación (JOIN) adecuado entre dos tablas relacionadas. El error frecuente es esperar que una llave foránea no admita valores repetidos, cuando sí puede repetirlos.

Ciclo de vida de una aplicación

El desarrollo de una aplicación sigue, en general, esta secuencia: análisis de requerimientos, diseño, codificación, pruebas y documentación con puesta en operación. El error común es empezar a programar sin haber analizado antes qué necesita resolver el sistema.

Estudios de factibilidad

La factibilidad técnica evalúa si existe la tecnología necesaria; la económica, si hay presupuesto y retorno esperado; la operativa, si la organización podrá usar el sistema. El examen presenta un análisis y pide identificar a qué tipo de factibilidad corresponde. El error frecuente es mezclar la disponibilidad de presupuesto (económica) con la disponibilidad de tecnología (técnica).

Fases del proceso de auditoría informática

Una auditoría sigue una secuencia: planeación (identificar y clasificar riesgos para diseñar el programa de pruebas), ejecución (aplicar las pruebas) e informe (documentar hallazgos y recomendaciones). El error común es suponer que los riesgos se identifican durante la ejecución, cuando corresponde a la planeación.

Confidencialidad, integridad y disponibilidad

Estos tres principios de seguridad de la información se afectan de forma distinta: la confidencialidad cuando información llega a quien no debería verla; la integridad cuando se altera sin autorización; la disponibilidad cuando deja de estar accesible para quien la necesita. El examen plantea un incidente y pide identificar cuál de los tres se vio comprometido.

Indicadores clave de desempeño del área de TI

Un KPI mide de forma cuantitativa si un área o proceso cumple un objetivo específico (por ejemplo, el porcentaje de incidentes resueltos dentro del tiempo acordado en un SLA). Se confunde un KPI de operación continua con un estudio de factibilidad, que evalúa la viabilidad de un proyecto antes de emprenderlo, no el desempeño de un servicio ya en marcha.