COMPUTATIONAL THINKING - INTRODUCCIÓN AL PENSAMIENTO COMPUTACIONAL - T3

¿Qué permite la abstracción en el análisis de datos?. Añadir más detalles a los datos. Reducir los datos a sus elementos esenciales sin perder el objetivo del análisis. Ignorar completamente los datos. Aumentar la complejidad de la información.

¿En qué ayuda la abstracción en un entorno TIC?. A complicar la interpretación de tickets de incidencia. A ignorar inventarios de equipos. A interpretar tickets de incidencia, inventarios de equipos o registros básicos de servicio. A descartar todos los datos relevantes.

¿Qué consiste la identificación de patrones?. Reconocer repeticiones, relaciones o comportamientos similares. Ignorar cualquier tipo de repetición en los datos. Crear datos completamente nuevos y aleatorios. Descartar toda la información de entrada.

¿Cuándo se usa la identificación de patrones?. Cuando hay que agrupar incidencias por categoría, detectar incoherencias o simplificar un proceso. Solo cuando se quiere añadir complejidad a un proceso. Nunca se utiliza en entornos TIC. Cuando se desea descartar todos los datos de entrada.

¿Cuál de los siguientes es un error a evitar al identificar patrones?. Confundir coincidencias aisladas con patrones. Descartar datos innecesarios. Ser demasiado específico en la descripción. Utilizar un lenguaje técnico preciso.

¿Qué es un patrón de datos?. Un registro de datos único y aislado. Una regularidad reconocible que comparten varios registros. Un error en la entrada de datos. Una suposición sin base en los datos.

¿Dónde se puede detectar un patrón de datos en un entorno TIC?. Solo en inventarios de equipos. Exclusivamente en logs resumidos. En tickets de incidencia, logs resumidos, inventarios de equipos, entre otros. Nunca se detecta en datos de soporte técnico.

¿Cuál es la finalidad de reconocer patrones de datos?. Adivinar causas complejas de los problemas. Reconocer repeticiones útiles para tomar decisiones. Ignorar cualquier tipo de repetición. Aumentar la cantidad de datos a analizar.

¿Qué dato es más relevante en un ticket si el objetivo es detectar incidencias repetidas?. El identificador interno del ticket. El servicio afectado, el tipo de error, la franja horaria y la prioridad. La hora exacta en que se registró el ticket. El nombre del técnico que lo resolvió.

¿Cuál de las siguientes es una forma habitual que puede adoptar un patrón básico?. Una concentración de registros en una categoría. Una secuencia de eventos. Una repetición de incidencias similares. Todas las anteriores.

¿Cómo se debe describir un patrón para que sea útil?. Usando lenguaje ambiguo y general. Con lenguaje claro, verificable y ajustado al contexto. Evitando dar detalles sobre la ubicación o condición. Describiendo solo coincidencias aisladas.

En el micro-caso aplicado sobre tickets de una pyme, ¿qué orientó la comprobación inicial?. La hora exacta de apertura de todos los tickets. El patrón que indicaba que la mayoría de tickets eran de correo corporativo y se abrían antes de las 10:00. La lista completa de todos los servicios afectados. La prioridad de cada ticket individual.

¿Qué paso se sigue para trabajar con datos sencillos y identificar patrones?. Formular el patrón con una frase subjetiva. Seleccionar todos los campos, sin importar su utilidad. Definir la pregunta operativa que se quiere responder. Ignorar las repeticiones y secuencias.

¿Qué error se comete al conservar todos los datos 'por si acaso'?. Se pierde información relevante. Se dificulta la interpretación y aumenta el ruido. Se simplifica el análisis innecesariamente. Se acelera la toma de decisiones.

¿Qué significa simplificar información sin control?. Retirar detalles que no cambian la interpretación principal. Eliminar toda la información secundaria. Aumentar la cantidad de detalles presentados. Ignorar los datos de entrada.

En el caso práctico del departamento de soporte, ¿qué se observó tras clasificar los tickets por servicio afectado?. La mayoría de incidencias eran de hardware. La mayoría de incidencias correspondían al correo corporativo y se producían por la mañana. Las incidencias se distribuían uniformemente a lo largo del día. Solo las incidencias de alta prioridad eran relevantes.

¿Qué ventaja tiene un gráfico de barras en el análisis de datos?. Permite conservar el detalle de cada registro. Es ideal para comparar el número de incidencias por categoría. Organiza los datos en filas y columnas. Facilita la lectura de valores individuales.

¿Cuándo conviene usar un gráfico circular?. Para comparar el número de incidencias por categoría. Para observar la variación diaria de tickets abiertos. Solo cuando se comparan pocas partes de un total. Para revisar el detalle concreto de cada registro.

¿Por qué es importante controlar la incoherencia en los datos antes de representarlos?. Para aumentar la cantidad de datos. Para evitar que un gráfico divida un único problema en grupos falsos. Para hacer el análisis más complejo. Para omitir información relevante.

En el micro-caso aplicado sobre un proveedor de servicios gestionados y tickets de clientes, ¿qué permitió priorizar una revisión?. La tabla que mostraba todos los detalles de cada ticket. El gráfico de barras que mostraba la distribución de incidencias por categoría, indicando que la mayoría eran de acceso y credenciales. La lista de clientes sin clasificar. La hora de apertura de los tickets.

¿Qué diferencia hay entre un dato relevante y un dato accesorio?. El dato relevante es más largo que el accesorio. El dato relevante ayuda a tomar una decisión o resolver un problema; el accesorio no aporta valor al objetivo definido. El dato accesorio siempre es numérico. El dato relevante se introduce más tarde.

¿Por qué la relevancia de un dato cambia según la finalidad del análisis?. Porque los datos se corrompen con el tiempo. Porque diferentes objetivos requieren diferentes informaciones para la toma de decisiones. Porque los datos accesorio se vuelven relevantes con el tiempo. Porque la cantidad de datos siempre determina su relevancia.

¿Qué paso se sigue para trabajar con criterios relevantes?. Enumerar todos los datos disponibles sin filtrarlos. Asociar cada dato con una decisión posible, considerándolo accesorio si no la modifica. Ignorar el objetivo operativo. Clasificar los datos en categorías ambiguas.

¿Por qué es importante revisar si la información conservada permite actuar sin consultar datos adicionales?. Para aumentar la complejidad del análisis. Para evitar la pérdida de información esencial. Para asegurar que el análisis es completo y facilita la acción. Para descartar información demasiado pronto.

¿Qué puede ocurrir si un comentario aparentemente secundario es decisivo para diferenciar un problema?. El comentario se puede descartar sin problema. Se podría omitir una pista crucial para el diagnóstico. El análisis se simplifica demasiado. Se genera información redundante.

¿Por qué un dato demasiado general puede no servir para el análisis?. Porque es demasiado específico. Porque no permite intervenir con precisión. Porque es difícil de entender. Porque aporta demasiada información.

En tareas de gestión digital, ¿cuándo conviene fijar campos obligatorios y categorías cerradas?. Después de recopilar todos los datos. Al trabajar con una tabla de tickets, para reducir ambigüedades. Cuando se desea aumentar la flexibilidad del sistema. Solo si el equipo no tiene experiencia.

En el caso práctico relacionado sobre incidencias de servicios, ¿qué datos se seleccionaron para decidir qué incidencias requerían atención inmediata?. Usuario, Departamento, Comentarios. Servicio afectado, Prioridad, Estado, Número de usuarios afectados. Equipo, Fecha, Prioridad. Servicio afectado, Comentarios, Estado.

¿Qué permite la identificación de semejanzas, diferencias y subconjuntos en un conjunto de datos?. Aumentar la complejidad de los datos. Perder la información esencial. Reducir un conjunto de datos a partes manejables sin perder información esencial. Ignorar los detalles de los registros.

¿Cuándo aparece una semejanza en los datos?. Cuando varios registros no comparten ninguna característica. Cuando varios registros comparten una característica relevante. Cuando un registro es completamente único. Cuando hay una diferencia significativa entre registros.

Un subconjunto de datos es... El conjunto de datos completo. Una parte del conjunto inicial formada mediante una condición concreta. Una característica aleatoria de los datos. Un error en la entrada de datos.

Para aplicar la técnica de semejanzas, diferencias y subconjuntos, ¿qué se debe fijar primero?. Las variables de comparación. La finalidad del análisis. Los errores más comunes. Los detalles accesorios.

¿Qué error habitual se comete al mezclar criterios en el análisis de subconjuntos?. Crear categorías demasiado amplias. Ignorar datos que no afectan al objetivo. Considerar como diferencia un dato que no afecta al objetivo. Dividir en demasiados subconjuntos pequeños.

En el micro-caso de incidencias tras un parche de seguridad, ¿cuál fue el subconjunto útil identificado?. Todos los usuarios con problemas. Usuarios con portátil, cliente VPN afectado y error de conexión después del parche. Todos los usuarios de la red. Incidencias de conexión generales.

¿Qué es una predicción basada en patrones?. Una adivinanza sobre el futuro. Una estimación de lo que puede ocurrir a continuación basada en secuencias de datos con regularidad suficiente. La confirmación de eventos pasados. Un análisis de datos sin relación con el tiempo.

¿Por qué la predicción debe limitarse al alcance de los datos disponibles?. Para hacer la predicción más vaga. Para evitar la sobreinterpretación y mantener la fiabilidad. Porque los datos más lejanos son siempre irrelevantes. Para complicar el análisis.

¿Qué se debe hacer para comprobar la regularidad en una secuencia de datos?. Ignorar si los valores aumentan o disminuyen. Observar si los valores aumentan, disminuyen, se repiten o alternan con una lógica reconocible. Asumir que los valores siempre aumentan. Buscar solo valores idénticos.

¿Qué elemento es importante incluir al documentar una predicción?. Solo el dato previsto. El dato previsto, la regla usada y la condición de validez. Una descripción general sin detalles. La fecha en que se realizó la predicción.

¿Cuál es el objetivo principal de una predicción útil en soporte?. Lograr una precisión absoluta. Reducir la incertidumbre y apoyar la toma de decisiones operativas. Demostrar la complejidad del análisis. Ignorar los datos históricos.

En el micro-caso aplicado sobre tickets por errores de autenticación, ¿qué permitió prever un refuerzo temporal del soporte?. La aparición del mismo patrón en tres despliegues de parche consecutivos. Una única incidencia de error de autenticación. La falta de datos históricos. Una predicción sin base en datos observados.

¿Por qué una regla de predicción pierde consistencia si se mezclan datos de diferentes tipos?. Porque aumenta la cantidad de datos. Porque los criterios de medición o el contexto son diferentes, invalidando la comparación. Porque los datos más antiguos son siempre menos relevantes. Porque la regla se vuelve demasiado simple.

En el caso práctico de incidencias de acceso remoto, ¿qué indicaba el patrón observado?. Que las incidencias disminuirían la semana siguiente. Que el número de incidencias seguiría aumentando al mismo ritmo que la semana anterior. Que las incidencias se mantendrían constantes. Que las incidencias se debían a un problema de hardware.

¿Qué es un modelo abstracto?. Una representación detallada de toda la realidad. Una representación simplificada de un problema, centrándose en elementos esenciales y relaciones. Una copia exacta de la situación real. Un modelo que solo incluye detalles accesorios.

¿Para qué sirve un modelo abstracto en soporte TIC?. Para complicar la interpretación de procesos. Para interpretar procesos, comunicar requisitos y detectar fallos de comprensión. Para ignorar los detalles importantes. Para crear modelos excesivamente detallados.

¿Qué se debe evitar al crear modelos abstractos?. Pasos ambiguos, categorías mezcladas y relaciones contradictorias. La simplificación excesiva. Ignorar detalles relevantes. Utilizar un lenguaje claro.

¿Qué representa una variable en un modelo abstracto?. Una acción que se repite. Una secuencia de pasos. Un dato cuyo valor puede cambiar entre casos. Una regla de decisión.

¿Cuál es la ventaja de usar una función en un modelo abstracto?. Aumentar la complejidad del modelo. Separar el criterio de decisión del caso concreto, facilitando cambios. Añadir detalles innecesarios. Ignorar los datos de entrada.

¿Qué describe un procedimiento en un modelo abstracto?. Un dato cuyo valor cambia. Una secuencia de acciones donde el orden importa. Una regla que transforma entradas en salidas. Un elemento fijo en el modelo.

Al construir una representación útil, ¿qué se debe seleccionar?. Solo variables que no influyan en el objetivo. Todos los datos disponibles, sin excepción. Solo variables que influyan en el objetivo operativo. Detalles accesorios que no aportan valor.

En el micro-caso aplicado sobre un proveedor de servicios y la clasificación de incidencias, ¿qué variables utilizó el técnico?. Cliente, servicio afectado, impacto y urgencia. Identificador del ticket, fecha y hora. Nombre del cliente, dirección y teléfono. Prioridad, estado y categoría.

¿Qué permite un modelo abstracto para comprender sistemas complejos?. Copiar la realidad completa, incluyendo todos los detalles. Tratar un sistema complejo como un conjunto manejable de elementos, relaciones y reglas. Aumentar la cantidad de detalles irrelevantes. Ignorar las relaciones entre los elementos.

¿Por qué la marca del monitor no aporta valor en una incidencia de acceso a una aplicación interna (a menos que el problema sea de visualización)?. Porque es un detalle demasiado específico. Porque no es relevante para el diagnóstico del problema de acceso. Porque es un dato accesorio que no influye en la decisión técnica. Porque el técnico no tiene acceso a esa información.

¿Qué tres condiciones determinan la utilidad de un modelo?. Correspondencia, limitación y verificación. Detalle, complejidad y extensión. Ambigüedad, generalidad y falta de ejemplos. Rapidez, coste y facilidad de uso.

En soporte técnico, ¿qué se puede representar mediante categorías simples como origen probable, impacto y prioridad?. Un modelo demasiado detallado. Una incidencia, facilitando la ordenación del trabajo. La copia completa de la realidad. Una relación entre componentes que no aporta valor.

¿Qué representa un diagrama de flujo?. Una descripción estática de un sistema. Una secuencia de acciones, decisiones y resultados conectados por flechas. Una lista de variables y funciones. Un conjunto de datos sin orden específico.

¿Por qué un diagrama de flujo es útil en entornos TIC?. Para describir procesos repetibles y reducir ambigüedades. Para aumentar la complejidad de los procesos. Para ignorar las decisiones tomadas. Para representar solo las acciones, sin incluir decisiones.

¿Cómo debe ser cada bloque en un diagrama de flujo evaluable?. Breve, con verbo de acción y dato relevante cuando sea necesario. Largo y detallado, explicando cada posible escenario. General y ambiguo, para permitir flexibilidad. Únicamente con el nombre de la acción.

En el micro-caso de un aviso de caída de acceso a una aplicación, ¿qué puede detectar un diagrama de flujo?. Si falta una comprobación previa, como validar red local antes de intervenir sobre el servidor. Que el problema siempre afecta a un único equipo. Que la intervención sobre el servidor es siempre necesaria. La causa raíz del problema sin necesidad de más comprobaciones.

¿Qué error frecuente se comete al dibujar diagramas de flujo?. Usar decisiones con condición clara. Cerrar el proceso antes de documentar la actuación. Representar el flujo principal y las desviaciones habituales. Utilizar flechas que no se cruzan.