option
Cuestiones
ayuda
daypo
buscar.php

COMPUTATIONAL THINKING - INTRODUCCIÓN AL PENSAMIENTO COMPUTACIONAL - T4

COMENTARIOS ESTADÍSTICAS RÉCORDS
REALIZAR TEST
Título del Test:
COMPUTATIONAL THINKING - INTRODUCCIÓN AL PENSAMIENTO COMPUTACIONAL - T4

Descripción:
Especificación de una Solución

Fecha de Creación: 2026/07/02

Categoría: Otros

Número Preguntas: 50

Valoración:(0)
COMPARTE EL TEST
Nuevo ComentarioNuevo Comentario
Comentarios
NO HAY REGISTROS
Temario:

¿Cuál es el objetivo principal de la especificación de una solución ?. Desarrollar el software lo más rápido posible, ignorando el presupuesto aprobado. Descomponer problemas, recoger y analizar datos para especificar una solución. Minimizar el número de tickets de soporte. Asegurar que la solución sea estéticamente agradable.

¿Qué se busca evitar al definir un problema tecnológico de forma adecuada?. Tickets ambiguos, cambios innecesarios y configuraciones alejadas del contexto de uso. Que los usuarios entiendan el problema. La descomposición del problema en subproblemas. La identificación de patrones y dependencias.

¿qué aplica el pensamiento computacional en la descomposición de un problema?. Reunir toda la información sin modificarla. Separar el problema en subproblemas manejables, reconocer patrones y dependencias. Proponer la solución antes de entender el problema. Evitar ambigüedades en la redacción.

¿Cuál es la diferencia clave entre un problema y una solución en la redacción de un enunciado?. El problema se enfoca en el resultado intermedio, la solución en el proceso. El enunciado del problema debe proponer la solución. El enunciado del problema describe la situación sin adelantar una solución. La solución es siempre más compleja que el problema.

¿Qué se debe evitar al redactar un enunciado de problema?. Identificar el hecho observable y los usuarios implicados. Ser específico sobre el contexto y el resultado esperado. Expresiones como "mejorar el sistema" o "hacerlo más fácil" si no indican qué proceso falla. Utilizar verbos concretos como registrar, consultar o validar.

¿Qué indica el 'alcance' en una especificación básica?. Las limitaciones técnicas del sistema. Qué parte del problema se va a resolver y qué resultados se esperan. Las condiciones que reducen o impiden opciones de solución. El número de usuarios que utilizarán la solución.

Las 'limitaciones' en una especificación básica indican: Las funcionalidades que se implementarán. Las condiciones que reducen, condicionan o impiden determinadas opciones de solución. El presupuesto disponible para el proyecto. El plazo máximo de desarrollo de la solución.

¿Qué diferencia hay entre 'alcance incluido' y 'alcance excluido'?. El alcance incluido son las funcionalidades obligatorias, el excluido son las opcionales. El alcance incluido es lo que se resolverá, el excluido es lo que no se resolverá. El alcance incluido son los requisitos funcionales, el excluido los no funcionales. El alcance incluido es el problema, el excluido es la solución.

¿Qué debe evitarse al expresar un resultado observable?. Vincularlo al contexto de clasificación inicial de incidencias. Separar el problema en subproblemas manejables. Expresar promesas amplias como "hacer el soporte más rápido". Verificar si el resultado se ha problema antes de plantear una solución.

¿Qué es la trazabilidad en el contexto de los requisitos?. La relación entre el diseño y la implementación. La relación entre cada requisito y un problema, subproblema, límite u objetivo documentado. El seguimiento de los errores durante el desarrollo. La documentación de las decisiones tomadas.

¿Qué se busca al identificar las opciones viables en la toma de decisiones?. Encontrar la opción más económica. Descartar alternativas que incumplen restricciones ya conocidas. Elegir la opción que el cliente prefiera. Seleccionar la opción tecnológicamente más avanzada.

¿Qué datos mínimos debe contener una decisión útil?. Qué se decide, por qué se decide, quién valida y qué efecto tiene. Quién toma la decisión, cuándo se toma y qué recursos se necesitan. La opción elegida, las opciones descartadas y el coste estimado. La fecha de la decisión, el nombre del responsable y la fecha de implementación.

¿Qué error se comete al confundir preferencia con requisito?. Se priorizan funcionalidades innecesarias. Se incluyen elementos que no responden a una necesidad real. Se aumenta el coste del proyecto. Se retrasa la entrega del producto.

¿Qué permite la identificación de patrones en la descomposición?. Aumentar la complejidad del problema. Reducir duplicidades y crear componentes comunes reutilizables. Ignorar las dependencias entre subproblemas. Justificar la necesidad de más recursos.

¿Qué es un requisito en el contexto de una solución?. Una necesidad que la solución debe cumplir para resolver el problema tecnológico. Una sugerencia para mejorar la interfaz de usuario, parte de las opiniones de varios empleados. Una limitación impuesta por el cliente. Una posible solución al problema.

¿Qué se distingue entre los tipos de requisitos?. Funcionales, no funcionales y de seguridad. Funcionales, no funcionales y restricciones. Técnicos, operativos y de negocio. Obligatorios, deseables y opcionales.

¿Por qué un requisito escrito con 'rápido' no es verificable?. Porque es una opinión subjetiva y no una condición observable. Porque no indica el tiempo exacto necesario. Porque es difícil de medir. Porque no se relaciona con el problema.

¿Cuál es la diferencia principal entre diseño iterativo y diseño incremental?. El iterativo mejora una parte varias veces, el incremental añade partes nuevas. El iterativo entrega la solución completa, el incremental por partes. El iterativo se enfoca en requisitos funcionales, el incremental en los no funcionales. El iterativo es más rápido que el incremental.

¿Qué es un requisito previo para una solución?. La descripción de la función final del sistema. Una condición que debe estar clara antes de decidir cómo se resolverá el problema. El resultado esperado de la solución. La lista de herramientas a utilizar.

¿Cuál es el primer requisito previo para definir un problema sin ambigüedad?. Identificar a los usuarios implicados. Disponer de un problema delimitado y expresado sin ambigüedad. Definir un objetivo medible. Conocer el contexto de uso.

¿Por qué es importante distinguir entre 'restricción' y 'preferencia'?. Las restricciones limitan la solución obligatoriamente, las preferencias pueden negociarse. Las restricciones son internas, las preferencias externas. Las restricciones son funcionales, las preferencias no funcionales. No es importante, se pueden usar indistintamente.

¿Qué error se comete al confundir 'solución deseada' con 'necesidad real'?. Se invierten recursos en desarrollar algo que no resuelve el problema. Se omiten requisitos importantes. Se generan conflictos entre equipos. Se retrasa la entrega del proyecto.

¿Qué es un 'resultado de una solución'?. El programa instalado o el formulario creado. El efecto observable que debe producirse cuando la solución se aplica en su contexto de uso. La cantidad de código desarrollado. El número de tickets resueltos.

¿Cuál es la diferencia entre 'entregable' y 'resultado'?. El entregable es lo que se construye, el resultado es el beneficio operativo. El entregable es la solución funcional, el resultado la solución no funcional. El entregable es temporal, el resultado es permanente. No hay diferencia, son sinónimos.

¿Qué debe indicar un resultado no viable?. Que la solución es perfecta pero demasiado cara. La causa por la que no es viable y cómo se vincula a una restricción concreta. Que el cliente no entendió la propuesta. Que el problema no tiene solución.

¿Qué permite la trazabilidad para justificar cada resultado?. Detectar resultados innecesarios o decisiones técnicas que no aportan valor. Aumentar la complejidad de la especificación. Ignorar las restricciones del proyecto. Facilitar la toma de decisiones sin justificación.

¿Qué herramienta se usa principalmente para recoger necesidades de usuarios implicados?. Hoja de cálculo. Diagrama de flujo. Encuesta. Pseudocódigo.

¿Qué herramienta se usa para ordenar requisitos, restricciones y dependencias?. Diagrama de flujo. Encuesta. Pseudocódigo. Hoja de cálculo.

¿Qué herramienta se usa para representar decisiones y pasos de uso?. Pseudocódigo. Diagrama de flujo. Encuesta. Hoja de cálculo.

¿Cuándo se usa el pseudocódigo?. Cuando falta información de usuarios. Cuando hay que comparar y priorizar. Cuando hay que explicar un proceso. Cuando hay que precisar reglas de comportamiento.

¿Qué se busca al combinar las cuatro herramientas (encuesta, hoja de cálculo, diagrama de flujo, pseudocódigo)?. Crear una especificación básica con identificadores coherentes. Aumentar la complejidad del proyecto. Simplificar la documentación. Reducir el número de requisitos.

¿Qué ayuda a representar los diagramas de flujo?. La lógica detallada de un programa. El recorrido de una operación con decisiones claras. Las reglas de funcionamiento de un sistema. La priorización de requisitos.

¿Por qué se debe usar pseudocódigo?. Para describir acciones en orden lógico, usando nombres comprensibles. Para representar visualmente el flujo de trabajo. Para recoger opiniones de los usuarios. Para organizar requisitos y prioridades.

¿Cuál es la ventaja de que cada herramienta produzca una salida revisable?. Simplifica la documentación. Permite que el resultado sea evaluable y las decisiones verificables. Aumenta la complejidad del diseño. Reduce el número de participantes en el proyecto.

Según el texto, ¿qué es una 'especificación básica'?. Un documento completo que detalla toda la solución técnica. Un documento que diferencia entre entregable y resultado. Un documento que detalla solo los requisitos funcionales. Un documento que solo describe el problema.

¿Qué se debe hacer si un requisito no puede relacionarse con ningún límite, objetivo o necesidad documentada?. Incluirlo de todos modos para no dejar cabos sueltos. Revisarlo, ya que puede representar una expectativa no validada. Asumir que es una necesidad futura y posponerlo. Eliminarlo sin más análisis.

¿Qué implica la "toma de decisiones" en la especificación básica de una solución tecnológica?. Elegir una opción basada en la intuición del equipo. Elegir una opción justificada entre varias alternativas posibles. Decidir únicamente en función del coste. Esperar a que el cliente decida la mejor opción.

Según el documento, ¿qué es "descomponer un problema"?. Romper el problema en partes más pequeñas para analizarlas mejor. Eliminar las partes del problema que parecen más difíciles. Reunir todas las partes del problema en una sola solución. Ignorar las subpartes del problema y enfocarse en la solución general.

¿Qué se debe hacer para que el "resultado sea correcto" en la definición de alcance, exclusiones y restricciones?. Que los elementos incluidos, excluidos y las restricciones no estén claros. Que los elementos incluidos, excluidos y las restricciones se diferencien claramente. Que solo los elementos incluidos sean visibles. Que las exclusiones sean secretas.

¿Cuál es el propósito de "identificar los usuarios implicados y las partes interesadas" como requisito previo?. Aumentar la complejidad del proyecto. Evitar requisitos contradictorios y priorizar adecuadamente. Simplificar la comunicación entre equipos. Delegar la responsabilidad de la solución.

¿Qué significa "entrada" en el contexto de los componentes de la descomposición?. El resultado esperado tras resolver una parte del problema. La información, evento o condición necesaria para tratar el subproblema. La dependencia entre dos subproblemas. Un elemento común que se repite en varios subproblemas.

¿Qué indica un "subproblema" en la descomposición?. Una tarea que no se puede resolver. Una unidad manejable del problema que expresa una acción o necesidad concreta. La dependencia entre dos partes del problema. El resultado final de la solución.

¿Por qué es importante la "trazabilidad" en la especificación de una solución?. Para aumentar la complejidad del documento. Para justificar cada decisión y requisito, y asegurar que responden a una necesidad real. Para hacer el documento más largo. Para ocultar información sensible.

¿Qué diferencia a un "requisito funcional" de un "requisito no funcional"?. El funcional indica qué hace la solución, el no funcional su calidad o rendimiento. El funcional es obligatorio, el no funcional es opcional. El funcional se enfoca en la interfaz, el no funcional en la base de datos. El funcional es para el usuario, el no funcional para el administrador.

¿Cuál de los siguientes enunciados describe correctamente un problema?. Debemos instalar un nuevo programa de gestión. Es necesario comprar ordenadores nuevos. Los empleados registran la misma información en tres aplicaciones distintas, generando errores y pérdida de tiempo. Hay que desarrollar una aplicación móvil.

¿Cuál de las siguientes afirmaciones corresponde al alcance de un proyecto?. El presupuesto disponible es de 20.000 €. El sistema permitirá registrar y consultar incidencias. Solo hay dos desarrolladores disponibles. El proyecto debe finalizar en tres meses.

¿Qué concepto responde a la pregunta "¿Qué se va a hacer?"?. Público objetivo. Alcance. Limitación. Requisito previo.

¿Qué se entiende por público objetivo?. El conjunto de personas que financiarán el proyecto. Las personas encargadas de desarrollarlo. Las personas para las que se diseña la solución. Los proveedores del proyecto.

¿Qué ventaja ofrece la descomposición?. Hace el problema más complejo. Permite resolver varios problemas pequeños en lugar de uno muy grande. Elimina la necesidad de planificar. Sustituye completamente los algoritmos.

¿Qué caracteriza al diseño iterativo?. Añadir nuevas funcionalidades en cada versión. Mejorar progresivamente una misma solución mediante revisiones. Sustituir completamente la solución anterior. Finalizar el proyecto antes de realizar pruebas.

Denunciar Test