EGEL Plus de Ingeniería de Software 2026: temario, estructura y diagnóstico

Tipos de requerimientos

Los requerimientos funcionales describen qué debe hacer el sistema; los no funcionales describen cómo debe hacerlo (rendimiento, seguridad, usabilidad). El examen plantea clasificar un requerimiento descrito en un caso. Se confunde un requerimiento no funcional de rendimiento con uno funcional que simplemente menciona un tiempo de respuesta como parte de su comportamiento.

Técnicas de elicitación y validación de requerimientos

Entrevistas, cuestionarios, observación y talleres son técnicas para obtener requerimientos; la validación confirma que reflejan lo que el cliente necesita, y la verificación que están completos y sin contradicciones. El examen pregunta qué técnica conviene ante un tipo de usuario o proyecto. Se confunde elicitación (obtener) con priorización (decidir el orden de implementación).

Documentación y trazabilidad de requerimientos

La especificación de requerimientos de software (ERS) documenta de forma estructurada lo que el sistema debe hacer, y la trazabilidad conecta cada requerimiento con su origen y con los elementos de diseño o prueba que lo satisfacen. El examen plantea identificar qué documento o notación corresponde a una necesidad de documentación descrita. Se confunde un caso de uso (interacción usuario-sistema) con una historia de usuario (formato ágil, más breve).

Estilos y patrones arquitectónicos

Los estilos arquitectónicos (cliente-servidor, en capas, microservicios, orientado a eventos) organizan el sistema a gran escala, mientras que los patrones de diseño (Singleton, Observer, Factory) resuelven problemas recurrentes a nivel de componente. El examen plantea qué estilo arquitectónico conviene ante un requisito de escalabilidad o distribución. Se confunde un estilo arquitectónico con un patrón de diseño: el primero define la estructura global, el segundo una solución local.

Cohesión y acoplamiento

La cohesión mide qué tan relacionadas están las responsabilidades dentro de un módulo (alta cohesión es deseable); el acoplamiento mide qué tan dependiente es un módulo de otros (bajo acoplamiento es deseable). El examen plantea evaluar un diseño descrito en términos de estos dos atributos. Se confunde alta cohesión con alto acoplamiento, como si ambos fueran igual de deseables.

Modelo entidad-relación y normalización

El modelo entidad-relación representa entidades, atributos y relaciones antes de traducirlos a tablas; la normalización organiza esas tablas para reducir redundancia según las formas normales. El examen plantea identificar una relación (uno a muchos, muchos a muchos) o una violación de normalización. Se confunde una relación muchos a muchos con dos relaciones uno a muchos independientes.

Diseño centrado en el usuario

El diseño centrado en el usuario prioriza las necesidades y el contexto de uso real de quien usará el sistema, validado con prototipos y pruebas de usabilidad antes de construir la versión final. El examen plantea qué actividad de diseño de interfaces corresponde a una etapa del proceso. Se confunde un prototipo de baja fidelidad (bocetos, sin funcionalidad) con uno de alta fidelidad (funcional, cercano al producto final).

Paradigmas de programación

La programación estructurada organiza el código en procedimientos secuenciales; la orientada a objetos, en clases con estado y comportamiento; la funcional evita el estado mutable y los efectos secundarios. El examen plantea identificar qué paradigma describe mejor un fragmento de código o un requisito de diseño. Se confunde usar objetos con programar orientado a objetos: se puede escribir código estructurado dentro de una clase.

Control de versiones y entornos de desarrollo

Un sistema de control de versiones distribuido (como Git) permite que varios desarrolladores trabajen en ramas independientes y fusionen sus cambios; el IDE integra edición, depuración y compilación. El examen plantea qué operación de control de versiones resuelve un conflicto o una necesidad de colaboración descrita. Se confunde una rama (branch) con una copia (fork): la primera es un espacio de trabajo dentro del mismo repositorio.

Gestión de datos y transacciones

Una transacción agrupa varias operaciones sobre una base de datos para que se ejecuten todas o ninguna (atomicidad), evitando estados inconsistentes ante fallas o accesos concurrentes. El examen plantea identificar qué propiedad ACID se compromete en un escenario de falla a mitad de una operación. Se confunde atomicidad (todo o nada) con consistencia (los datos siempre cumplen las reglas del negocio).

Plataformas y arquitectura cliente-servidor

Una aplicación puede desplegarse en plataformas web, móvil o de escritorio, cada una con restricciones distintas de conectividad, rendimiento y ciclo de actualización; la arquitectura cliente-servidor separa la lógica que corre en el dispositivo del usuario de la que corre en un servidor remoto. El examen plantea qué plataforma o arquitectura conviene ante un requisito de disponibilidad sin conexión o de actualización centralizada. Se confunde una aplicación web con una aplicación móvil híbrida, que empaqueta contenido web dentro de un contenedor nativo.

Selección de lenguajes de desarrollo

Un lenguaje compilado se traduce por completo a código máquina antes de ejecutarse; uno interpretado se traduce y ejecuta línea por línea en tiempo de ejecución, lo que afecta velocidad de ejecución y facilidad de depuración. El examen plantea qué tipo de lenguaje conviene según el contexto (rendimiento crítico frente a rapidez de desarrollo). Se confunde un lenguaje compilado con uno de tipado estático: son características independientes que pueden combinarse de distintas formas.

Estimación de esfuerzo, costos y riesgos

Técnicas como el juicio de expertos, la analogía con proyectos previos o los puntos de función estiman el esfuerzo y el costo de un proyecto de software; la gestión de riesgos identifica, evalúa y planea respuestas ante eventos que podrían afectar el proyecto. El examen plantea qué técnica de estimación conviene ante la información disponible de un proyecto. Se confunde un riesgo (evento incierto que podría ocurrir) con un problema (evento que ya ocurrió).

Calidad de software

El modelo de calidad ISO/IEC 25010 organiza las características de un producto de software (adecuación funcional, eficiencia de desempeño, compatibilidad, usabilidad, fiabilidad, seguridad, mantenibilidad, portabilidad) en un marco medible; las pruebas unitarias verifican componentes individuales y las de integración verifican su interacción conjunta. El examen plantea identificar qué característica de calidad se ve afectada en un escenario descrito. Se confunde fiabilidad (el sistema funciona sin fallar durante el tiempo esperado) con disponibilidad (el sistema está accesible cuando se necesita).

Metodologías de gestión de proyectos de software

Scrum organiza el trabajo en sprints con roles definidos (Scrum Master, Product Owner, equipo de desarrollo); el modelo en cascada ejecuta las fases de forma secuencial; los modelos iterativos e incrementales entregan versiones parciales que crecen en funcionalidad. El examen plantea qué metodología conviene ante un requisito de flexibilidad frente a uno de alcance fijo desde el inicio. Se confunde un sprint de Scrum con una iteración genérica de cualquier modelo incremental, aunque Scrum define roles y eventos específicos que otros modelos no exigen.