Cómo resolver un supuesto práctico de GSI: estructura, ejemplo y revisión

Para resolver un supuesto práctico de GSI, empieza por identificar qué te piden, separa los datos del enunciado de tus suposiciones y escribe una respuesta que una cada decisión con una razón y una comprobación. Una estructura útil es: objetivo, hechos, hipótesis, pasos, criterios de elección y verificación. Practícala con casos pequeños antes de intentar respuestas extensas.

Esta guía trata del método de trabajo y de redacción para aspirantes al Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado (GSI). No establece el formato ni los criterios de corrección de una convocatoria concreta. Antes de entrenar con tiempo o extensión fijos, consulta las bases aplicables en el BOE de la convocatoria enlazada y los avisos de la página de GSI del INAP. Si tu proceso es otro, localiza sus documentos propios.

Qué evalúas al practicar un caso

Una respuesta útil no consiste en volcar todo lo que recuerdas sobre redes, bases de datos o desarrollo. Consiste en resolver el encargo descrito. El objetivo de la práctica es comprobar si entiendes el problema, eliges una secuencia razonada, explicas los límites de la información disponible y comunicas cómo verificarías el resultado. Cuando un dato necesario falta, dilo: es preferible formular una hipótesis explícita a presentarla como un hecho.

Por ejemplo, «la aplicación no responde» no permite concluir por sí solo que falla DNS, la red o el servidor. Es una observación inicial. Una respuesta ordenada propone comprobaciones que distingan esas posibilidades. Del mismo modo, si un enunciado pide diseñar una solución, no basta con nombrar una tecnología: hay que relacionarla con requisitos, riesgos y pruebas.

1. Lee el enunciado como una lista de entregables

Antes de redactar, subraya los verbos del encargo: analizar, proponer, justificar, comparar, diseñar o verificar. Cada verbo exige algo distinto. «Propón» pide una solución; «justifica» pide los motivos; «compara» pide criterios comunes; «verifica» pide una forma de saber si funciona. Convierte esos verbos en un índice provisional de tu respuesta.

Después haz dos columnas breves: datos que ofrece el caso y datos que no ofrece. Incluye restricciones explícitas, como continuidad del servicio, seguridad, compatibilidad o tiempo de intervención, solo si aparecen. Si no aparecen, puedes señalar que habría que confirmarlas antes de cerrar una decisión definitiva.

• Objetivo: ¿qué resultado debe obtenerse y para quién?
• Alcance: ¿qué sistemas, usuarios o componentes menciona el enunciado?
• Condiciones: ¿qué límites hay sobre tiempo, datos, recursos o seguridad?
• Entregables: ¿piden un diagnóstico, una propuesta, un esquema, una comparación o varios de ellos?

Esta lectura inicial evita dedicar media respuesta a un tema cercano pero no solicitado. Si el caso contiene varios apartados, numéralos y deja espacio para todos antes de profundizar en uno.

2. Construye una respuesta que permita seguir tu razonamiento

Usa encabezados cortos o párrafos con una función clara. El lector debe poder encontrar la propuesta y entender por qué llegaste a ella. La siguiente plantilla se adapta a problemas de diagnóstico, diseño o mejora; elimina los apartados que no aporten nada al caso.

Parte	Pregunta que responde	Qué incluir
Objetivo	¿Qué hay que resolver?	Una frase que reformule el encargo sin cambiarlo.
Hechos y supuestos	¿Qué sabemos y qué asumimos?	Datos del enunciado separados de hipótesis pendientes de comprobar.
Propuesta o diagnóstico	¿Qué harías primero y después?	Pasos en orden, con dependencias y decisiones.
Justificación	¿Por qué esos pasos?	Relación entre cada medida y el problema que atiende.
Verificación	¿Cómo sabrías que sirve?	Pruebas, evidencias esperadas y criterio para rectificar.

No hace falta repetir esos rótulos de forma mecánica. Su valor está en impedir saltos lógicos: una conclusión sin evidencia, una medida sin motivo o un cierre sin comprobación. Si hay varias opciones razonables, indica qué dato decidiría entre ellas en lugar de fingir una certeza que el caso no ofrece.

3. Ejemplo: una aplicación interna deja de responder

Imagina un ejercicio de práctica inventado, sin relación con un examen oficial: «Tras un cambio, una aplicación interna deja de responder para parte de los usuarios. Describe cómo investigarías el problema y cómo comprobarías la recuperación». El enunciado no especifica la causa, el alcance exacto ni la arquitectura. Por tanto, la respuesta debe empezar acotando la incidencia, no anunciando una reparación.

Una secuencia defendible

1. Delimitar: confirmar desde cuándo ocurre, a quién afecta, si falla un nombre concreto o también el acceso por una ruta alternativa y qué cambió. Registrar ejemplos reproducibles.
2. Comprobar por capas: observar resolución de nombres, conectividad hacia el destino, respuesta del servicio y registros disponibles. Cada prueba debe contestar una pregunta; no conviene ejecutar comandos como una lista sin interpretar sus resultados.
3. Comparar: contrastar un usuario afectado con uno no afectado, y el estado anterior con el posterior al cambio si existe evidencia. Esa comparación puede reducir hipótesis, pero por sí sola no demuestra causalidad.
4. Actuar con criterio: proponer la medida de menor alcance que los datos justifiquen, documentar el cambio y contemplar una reversión si la intervención empeora la situación.
5. Verificar: repetir las pruebas iniciales desde los grupos afectados, comprobar el servicio desde la perspectiva del usuario y anotar qué señales vigilarías tras la recuperación.

Una redacción breve podría ser: «Primero confirmaría el alcance y recogería una petición fallida reproducible. Si el nombre resuelve a destinos distintos entre usuarios, investigaría la resolución; si resuelve igual pero el servicio no responde, comprobaría conectividad y respuesta de la aplicación. Aplicaría una corrección solo cuando la evidencia apunte a un componente y repetiría la prueba desde los usuarios afectados». La frase une observación, decisión y validación sin atribuir una causa no demostrada.

Si necesitas repasar conceptos que aparecen en este ejemplo, puedes consultar las guías existentes sobre registros DNS y códigos HTTP. Esas lecturas ayudan a distinguir hechos técnicos, pero la respuesta al caso debe seguir los datos de su propio enunciado.

4. Practica en tres pasadas, no solo leyendo soluciones

Primera pasada: respuesta sin apuntes. Ponte un límite de tiempo propio para entrenar, lee el caso y redacta una versión completa. Ese límite es un ejercicio personal, no una regla oficial. Deja marcadas las dudas en vez de rellenarlas con afirmaciones inseguras.

Segunda pasada: corrección con fuentes. Revisa el programa y las bases de tu convocatoria para comprobar que estudias el ámbito adecuado. Contrasta las afirmaciones técnicas con documentación de la tecnología concreta cuando sea necesario. Señala con otro color dónde confundiste un hecho con una hipótesis, omitiste una restricción o diste un paso sin explicar para qué servía.

Tercera pasada: reescritura selectiva. Reescribe solo el apartado más débil y añade una prueba de verificación. Después intenta explicar oralmente tu solución en un minuto. Si no puedes resumir la relación entre problema, decisión y prueba, quizá la respuesta aún contiene información suelta.

Conserva la primera versión y la revisada. Compararlas muestra una mejora concreta: menos suposiciones, mayor orden o una justificación más precisa. Para registrar patrones de fallo en preguntas cerradas, complementa este trabajo con la guía de análisis de errores en tests de GSI.

Lista de revisión antes de dar la respuesta por terminada

• ¿He contestado todos los apartados y verbos del enunciado?
• ¿Se distinguen los hechos dados de mis hipótesis?
• ¿Cada medida tiene un motivo relacionado con el problema?
• ¿He indicado qué comprobaría antes y después de actuar?
• ¿Hay alguna afirmación técnica que deba contrastar o matizar?
• ¿Se entiende la conclusión sin releer todo el desarrollo?

Si el tiempo de práctica se agota, prioriza una respuesta completa y legible frente a una introducción larga. Reserva unos minutos para releer nombres, negaciones y relaciones de causa y efecto: una palabra imprecisa puede cambiar el sentido de una propuesta.

Cómo apoyarte en PreparaGSI

En PreparaGSI puedes combinar tests para detectar conceptos que necesitas revisar, flashcards para recuperar definiciones y distinciones, y audio-podcasts para volver a escuchar contenidos. Después lleva esos conceptos a una respuesta escrita propia: explica qué decisión tomarías y con qué evidencia la comprobarías. Estos recursos acompañan el estudio; las bases oficiales determinan lo exigible en cada proceso.

Preguntas frecuentes

¿Hay una plantilla única para todos los supuestos de GSI?

No. La estructura objetivo, hechos, propuesta, justificación y verificación es una ayuda de estudio. Adáptala a los verbos y apartados de cada caso y a las instrucciones de la convocatoria aplicable.

¿Debo escribir una solución aunque falten datos?

Puedes proponer pasos condicionales: «si la prueba muestra X, comprobaría Y». Explica qué dato falta y cómo lo obtendrías. Evita convertir una posibilidad en un diagnóstico definitivo.

¿Basta con hacer tests para preparar una respuesta escrita?

Los tests pueden revelar lagunas, pero no sustituyen la práctica de ordenar y justificar una solución por escrito. Usa ambos ejercicios con objetivos distintos y consulta siempre el formato oficial de tu proceso.

¿Dónde compruebo el formato exigido?

En las bases publicadas por la administración convocante y en sus avisos oficiales. Como punto de partida para localizar documentación de GSI, consulta el BOE y la página del INAP enlazados arriba; verifica que correspondan exactamente a tu convocatoria y vía de acceso.