1955237
Question 1
Question
Qué significa que un software es "Eficiente"?
Answer
-
Que es seguro
-
Que trabaja correctamente siempre, sin fallos
-
Que hace su trabajo con los recursos disponibles
-
Que hace Io que se requiere según las especificaciones
Question 2
Question
Definición de modelo:
Answer
-
Es un prototipo funcional que aun no ha sido validado ni documentado
-
Es un prototipo no funcional de un sistema
-
ciclo de vida de construcción o desarrollo de un sistema real
-
Es una representación abstracta y comprensible, de un sistema real que sirve para entender dicho sistema
Question 3
Question
Sobre "los modelos", se puede afirmar que:
Answer
-
Un buen modelo debe mostrar toda la complejidad del sistema real completo para que este se pueda construir correctamente
-
Un modelo muestra una simplificación de un sistema complejo mostrando únicamente algunos aspectos de este
-
Demasiada abstracción es mala ya que si no se diseñan los detalles la construcción final será de mala calidad
-
Cuando son correctos la implernentación final será correcta
Question 4
Question
¿Cuál de estas cuestiones es importante desde el punto de vista del mantenimiento del software?
Answer
-
¿Se puede manejar fácilmente?
-
¿Se puede actualizar?
-
¿Es íntegro (seguro)?
-
¿Sigue un diseño modular?
Question 5
Question
Un ciclo de vida del software es:
Answer
-
La planificación en cascada de cada tarea que es preciso realizar para desarrollar aplicaciones software
-
La planificación en espiral de cada tarea que es preciso realizar para desarrollar aplicaciones software
-
La planificación incremental de cada tarea que es preciso realizar para desarrollar aplicaciones software
-
El conjunto de tareas que es necesario hacer junto con la planificación de cuando hay que hacerlas para desarrollar aplicaciones software
Question 6
Question
¿El modelado de un sistema puede requerir de la realización de varios modelos?
Answer
-
No, muchos modelos complican la comprensión del sistema
-
Sí, habrá un modelo por cada miembro del equipo de desarrollo
-
Sí, cada modelo puede mostrar diferentes visiones y aspectos del problema
-
No, un solo modelo que contenga todos los detalles facilitará la construcción
Question 7
Question
Ventaja/as de los ciclos de vida iterativos con respecto a los clásicos:
Answer
-
Fuerzan a que el cliente proporcione todas las especificaciones desde el principio y así el desarrollo es más rápido
-
No requieren de grandes equipos de trabajo, con una o dos personas es posible desarrollar cualquier proyecto software
-
Ofrece versiones parciales del producto que pueden ser evaluadas de forma temprana
-
No existen tales ventajas, los cidos de vida itenativos, debido a dichas iteraciones son más lentos
Question 8
Question
La especificación de requisitos:
Answer
-
Consiste en identificar las necesidades del negocio y la interacción con los usuarios
-
Es la implementación de los primeros prototipos del sistema aptos para su validación
-
Es el conjunto de documentos que especifica cómo realizar el mantenimiento del sistema
-
Es el conjunto de diagramas que determinan como debe realizarse la implementación de cada módulo del sistema final
Question 9
Question
¿Cuál de los siguientes hechos requiere una tarea de mantenimiento?
Answer
-
Incluir en el sistema opciones que permitan hacer pruebas
-
Incluir en el sistema funcionalidades que sabemos que van a ser necesarias en el futuro
-
Incluir un sistema ayuda On-line para sus usuarios finales
-
lncluir en el sistema toda la documentación del mismo
Question 10
Question
¿Por qué ocurrió la denominada "Crisis del Software" en los años 60 y 70?
Answer
-
Por no existencia en la época de lenguajes de alto nivel con los que poder mejorar la abstracción de los módulos implementados para los programas desarrollados en aquellos años
-
El precio del hardware bajó haciendo que muchas empresas de informática cerraran al ver reducidos sus beneficios por el escaso margen de los productos que comercializaban
-
Los nuevos equipos informáticos eran más barato y potentes, lo que permitió desarrollar programas de mayor tamaño, pero no existía una buena metodología para realizar ese tipo de desarrollos
-
El hardware experimentó una fuerte bajada en sus precios y esto motivó que muchas personas "no profesionales" empezaran a desarrollar software, siendo este de muy mala calidad
Question 11
Question
En la ingeniería de requisitos, la gestión de requisitos se realizará
Answer
-
Al final, cuando durante el mantenimiento, además de corregir errores, pudiera necesitarse hacer modificaciones mayores por nuevos requerimientos de la empresa
-
Al principio, cuando se capturan los requerimientos
-
Simultáneamente con la etapa de implementación, para adaptar mejor la programación del producto con los cambios de requisitos que puedan surgir en ese momento
-
Desde el mismo comienzo del proyecto hasta su finalización, incluyendo la etapa de mantenimiento
Question 12
Question
¿Por qué es difícil capturar los requisitos de un sistema?:
Answer
-
No siempre será fácil para el analista y asimilar el lenguaje y los conceptos del cliente y vicerversa
-
Porque esta tarea no suele estar contemplada en los ciclos de vida que se aplican en los procesos de desarrollo
-
No existen herramientas CASE que faciliten esta tarea
-
Por la dificultad para plasmarlos en gráficos y diagramas
Question 13
Question
Todo requisito debe cumplir que...
Answer
-
Debe ser enteramente compatible con Ios objetivos del sistema y ha de tener el visto bueno de Ios desarrolladores
-
Debe ser enteramente compatible con los objetivos del sistema y estar correctamente plasmado en diagramas de diseño
-
Debe ser enteramente compatible con los objetivos del sistema y ha de poderse validar una vez desarrollado el producto
-
Debe ser enteramente compatible con los objetivos del sistema y con las herramientas de desarrollo que se vayan a emplear
Question 14
Question
¿Cuál de las siguientes características NO es deseable en "Revisión Técnica Formal" de validación de requisitos?:
Answer
-
Debe realizarse por un grupo reducido de personas, que sea ágil y operativo
-
Debe prepararse y planificarse previamente en no demasiado tiempo
-
Debe durar todo el tiempo que sea necesario, hasta limar todos los detalles tratados aportando soluciones a los problemas detectados
-
Debe tratar un objetivo muy concreto y delimitado
Question 15
Question
Un cambio en los requisitos de un software se aceptará...
Answer
-
Siempre a posteriori, después de haber terminado el desarrollo propuesto originalmente, durante la etapa de mantenimiento, y con la condición de que el cliente de el visto bueno al sobrecoste económico que suponga realizar el cambio
-
Siempre a posteriori, después de haber terminado el desarrollo propuesto originalmente, durante Ia etapa de mantenimiento
-
Si es compatible con el resto de funcionalidades del sistema, si no hay inconvenientes económicos o técnicos para su realización y si no implica reprogramar algún módulo importante de Ia aplicación
-
Si se comprueba que no es incompatible con el resto de funcionalidades del sistema y si tampoco hay inconvenientes económicos o técnicos para su realización
Question 16
Question
¿Qué significa que los requerimientos del sistema están negociados?:
Answer
-
Que el cliente los conoce y está en proceso de negociación con sus empleados (usuarios finales)
-
Que no son ambiguos
-
Que analista y cliente los han tratado y los consideran aptos
-
Que han sido capturados por el analista y este los ha discutido y validado con su equipo de desarrollo
Question 17
Question
Requerimientos no funcionales :
Answer
-
Especifican cosas como las características técnicas de las herramientas CASE de diseño o de desarrollo
-
Especifican cosas como cuántos operarios deberá haber en cada departamento, qué formación técnica deben tener, etc..
-
Especifican cosas como la accesibilidad del sistema, su seguridad, cómo deben ser los tiempos de respuesta, etc..
-
Especifican cosas como qué operaciones hace el sistema, cómo es el tratamiento de los datos, etc..
Question 18
Question
¿Qué se obtiene al identificar los requisitos de un sistema?:
Answer
-
La funcionalidad esperada del sistema
-
La planificación óptima del resto de tareas del ciclo de vida
-
Los actores que intervienen en el sistema y sus manuales de usuario
-
La funcionalidad que necesitarán tener las herramientas de desarrollo
Question 19
Question
En el proceso de Revisión Técnica Formal ...
Answer
-
El producto revisado se acepta si no hay errores, se acepta provisionalmente si hay errores y, en este caso, se plantean soluciones para resolverlo
-
El producto revisado se acepta si no hay errores o directamente se rechaza si se detectan errores, en cuyo caso hay que rehacer todo el trabajo de nuevo
-
El producto revisado se acepta si no hay errores, o entre el responsable del mismo y los revisores, se arreglan los problemas encontrados durante la propia reunión
-
El producto revisado se acepta si no hay errores, se acepta provisionalmente si hay errores o se rechaza si hay errores graves
Question 20
Question
¿Qué es la "abstracción"?:
Answer
-
Considerar conjuntamente tanto el "qué" son las cosas y el "cómo" están hechas para poder reproducirlas
-
Considerar los detalles de las cosas para entenderlas mejor
-
Considerar la posición que ocupan las cosas dentro de un sistema superior con el que interactuan
-
Considerar la esencia de las cosas, su concepto general sin entrar a considerar sus detalles
Question 21
Question
Diferencia entre análisis y diseño:
Answer
-
El análisis describe formalmente las necesidades del cliente y el diseño define el ciclo de vida y plantea como desarrollar la aplicación que satisfaga dichas necesidades
-
El análisis describe formalmente las necesidades del cliente junto con el ciclo de vida y el diseño plantea como desarrollar la aplicación que satisfaga dichas necesidades
-
El análisis describe formalmente las necesidades del cliente y define los algoritmos más complejos, y el diseño define el ciclo de vida y plantea como desarrollar la aplicación que satisfaga dichas necesidades
-
El análisis describe formalmente las necesidades del cliente y el diseño plantea como desarrollar la aplicación que satisfaga dichas neceisades
Question 22
Question
En una caja negra...
Answer
-
Debe estar muy bien definida su operativa interna
-
Debe estar muy bien definida su interfaz, es decir, sus entradas, salidas y detalles de funcionamiento
-
Debe estar muy bien definida su interfaz, es decir, sus entradas y salidas
-
Debe estar muy bien definido su diseño modular
Question 23
Question
"Encapsular" en Ingeniería del Software es...
Answer
-
Ocultar la interfaz de un módulo mostrando solo sus detalles
-
Ocultar el diseño y la interfaz de un módulo mostrando sólo sus detalles
-
Ocultar los detalles de un módulo mostrando su interfaz y su diseño
-
Ocultar los detalles de un módulo mostrando sólo su interfaz
Question 24
Question
Sobre el diseño modular...
Answer
-
Es recomendable que cada módulo tenga su propia interfaz oculta al resto de módulos
-
Es recomendable que cada módulo interactúe con d resto cuanto más mejor para facilitar la comunicación entre módulos
-
Es recomendable que cada módulo resuelva cuantos más problemas, mejor
-
Es recomendable que cada módulo este asociado a un problema concreto
Question 25
Question
Si consideramos un ordenador como un sistema, su capa de abstracción sería ...
Answer
-
El procesador y la memoria RAM
-
El teclado, el monitor y el ratón
-
El procesado, la memoria RAM, los buses y los sistemas de almacenamiento
-
El teclado, el monitor, el ratón y el procesador
Question 26
Question
¿Por qué es importante encapsular el software?
Answer
-
Para evitar que un usuario realice operaciones que puedan colgar el programa
-
Para evitar que un usuario manipule indebidamente la interfaz de un módulo o una clase
-
Para evitar que un usuario manipule indebidamente configuraciones internas de un módulo produciendo errores de funcionamiento
-
Para evitar que un usuario inexperto realice pruebas en el software
Question 27
Question
¿Por qué es importante hacer un buen diseño al desarrollar software?:
Answer
-
Porque si no se capturan correctamente los requerimientos del cliente, todo el proceso de desarrollo será más lento y costoso y el producto final no cumplirá bien las necesidades de este
-
Porque de lo contrario la implementación posterior será más compleja y probablemente tendrá más errores
-
Porque no es recomendable acometer el desarrollo de un producto software sin antes haber definido el ciclo de vida más adecuado
-
Porque la definición posterior de los módulos de la aplicación será de mejor calidad que sin un diseño previo adecuado
Question 28
Question
El proceso de refinamiento modular...
Answer
-
Genera una jerarquía de módulos de no más de 4 niveles
-
Genera una jerarquía de módulos de varios niveles, dependiendo del tipo de problema
-
Genera una jerarquía de módulos en la que el nivel más bajo contiene los módulos con mayor nivel de abstracción
-
Genera una jerarquía de módulos donde cada uno se subdivide en no másde 4 en el siguiente nivel
Question 29
Question
¿Cuándo finaliza el proceso de refinamientos sucesivos?:
Answer
-
Cuando los Gqrcftnientos del cliente lo determinen
-
Cuando el coste de desarrollar los módulos sea mínimo
-
Cuando los módulos sean tan pequeños que su implementación sea abordable, pero no tantos como para complicar en exceso la conexión de todos ellos
-
Cuando las pruebas de cada módulo detecten los primeros erróneos o incompatibles
Question 30
Question
¿Qué especifican los requisitos funcionales?
Answer
-
Especifican cosas como la accesibilidad del sistema, su seguridad, cómo deben ser los tiempos de respuesta, etc..
-
Especifican cosas como cuántos operarios deberá haber en cada departamento, qué formación técnica deben tener, etc..
-
Especifican cosas como qué operaciones hace el sistema, cómo es tratamiento de los datos, etc...
-
Especifican cosas como el funcionamiento de las herramientas CASE de diseño o de desarrollo
Want to create your own Quizzes for free with GoConqr? Learn more.