¿El modelado de un sistema puede requerir de la realización de varios modelos?
Sí, siempre (salvo en problemas muy, muy simples)
Sí, de lo contrario no se conseguirá la baja abstacción deseada
No, muchos modelos complican la comprensión del sistema
No, un solo modelo que contenga todos los detalles facilitará la construcción
¿Cuál de los siguientes hechos requiere una tarea de mantenimiento?:
Un cambio en el entomo del problema al que se esté aplicando el software desarollado
Un cambio en los miembros del equipo de desarollo
Un cambio en las herramientas de desarollo
Un cambio en la plantilla de usuarios finales en la empresa/cliente
¿Por qué es importante encapsular el software?
Ayuda a generar sistemas más fláciles de entender y robustos
Ayuda a generar sistemas más abstractos
Ayuda a generar sistemas más modulares
Ayuda a generar sistemas más potentes y funcionales
Un requisito es aceptable si...
Se dispone de los medios adecuados para conseguirlo y está descrito sin ambigüedades
Se dispone de los medios adecuados para conseguirlo y el equipo de desarrollo está técnicamente preparado para implementarlo
Se dispone de los medios adecuados para conseguirlo y se especifica adecuadamente con una herramienta CASE apropiada para captura de requisitos
Se dispone de los medios adecuados para conseguirlo y no entra en conflicto con el diseño del sistema
Un ciclo de vida del software es:
Una forma general de organizar el trabajo a la hora de desarrollar software
Un conjunto de tareas que obligatoriamente hay que hacer sea cuando sea para desarrollar software
Una metodología para capturar los requisitos de un problema
Una determinada técnica de implementar, probar y documentar un desarrollo
¿Qué ventaja aportan los ciclos de vida iterativos con respecto a los esquemas clásicos?:
Contempla la posibilidad de que los requerimientos del cliente cambien o se amplíen
Son siempre más sencillos de entender y aplicar
El desarrollo es mucho más rápido cuando el equipo de trabajo es pequeño
No requiere que sus participantes estén especialmente especializados en el dominio del problema
¿Qué son los requerimientos no funcionales?:
Los que definen ciertos atributos de calidad
Los que definen el comportamiento del sistema
Los que definen los términos técnicos del domino del problema
Los que definen el comportamiento de las herramientas de desarrollo
¿Qué es "encapsular" en Ingeniería del Software?:
Agrupar en un mismo paquete todos los elementos que pertenecen a un mismo módulo, función o clase
Agrupar en un mismo paquete todos los módulos de una aplicación
Agrupar en un mismo paquete todos los módulos de un mismo nivel
Agrupar en un mismo paquete todas las funciones de librería desarrolladas para un mismo proyecto
¿Qué son los requerimientos funcionales?:
Los que definen el funcionamiento de las herramientas de desarrollo
Un motivo para no aceptar cambios en un producto software es:
Que resulte excesivamente caro
Que implique añadir nuevos actores en el sistema
Que suponga eliminar actores clave (p.e. el "administrador")
Que requiera reprogramar algún módulo importante
Causa principal de la Crisis del Software de finales de los 60 - principios de los 70
La dificultad para abordar correctamente el desarrollo de grandes programas en los primeros equipos informáticos de gran tamaño
El alto precio del Hardware a finales de los años 60 y principios de los 70
La mala formación de los "profesionales" informáticos
La aparición de los primeros virus informáticos
¿Cuál de estas cuestiones es importante desde el punto de vista del mantenimiento del software?
¿Se puede probar el software?
¿Se puede manejar fácilmente?
¿Es fiable?
¿En qué lenguaje se ha desarrollado?
¿Qué significa que los requerimientos del sistema estén negociados?:
Que han sido convenientemente discutidos con el cliente y este y el analista han dado su visto bueno
Que el cliente los conoce y está en proceso de negociación con sus empleados (usuarios finales)
Que han sido capturados por el analista y este los ha discutido y validado con su equipo de desarrollo
Que han sido transcritos digitalmente con una herramienta CASE adecuada para representar equerimientos
¿Cuál de los puntos siguientes es un resultado de la identificación de los requisitos?:
Necesidades, características y actores que intervienen en el sistema
Actores que intervienen en el sistema y su manual de usuario
Ciclo de vida aaplicar y las características del sistema
Necesidades del sistema y planificación del equipo de desarrollo
Sobre el diseño modular...
Es más efectivo si cada módulo interactua lo menos posible con el resto de módulos
Es más efectivo si cada módulo implementa varias funciones relacionadas para ahorrar espacio
Es más efectivo si cada módulo hace sólo una llamada al resto de módulos
Es más efectivo si cada módulo puede sacarse del sistema y ponerse a funcionar fuera de él sin el resto de módulos
¿Qué características debe cumplir una "Revisión Técnica Formal" de validación de requisitos?:
Debe ser una reunión preparada y planificada previamente, para un grupo reducido de personas (que sea operativo) y de una duración mas bien corta
Debe ser una reunión preparada previamente, para un grupo de personas lo más amplio posible (que abarque codos los aspectos de la empresa) y de una duración más bien corta
Debe ser una reunión preparada previamente, para un grupo lo más amplio de personas (que abarque codos los aspectos de la empresa) y de una duración larga que de tiempo atratar el máximo de cuestiones
Debe ser una reunión preparada previamente de manera concienzuda, tomándose para dicha preparación todo el tiempo que sea necesario y de una duración más bien corta, gracias en parte a la extensa y concienzuda preparación previa
Sobre "los modelos", es cierto que:
Siempre será más simplificado que el sistema que está siendo modelado
Un buen modelo debe mostrar toda la complejidad del sistema real completo para que este se pueda construir correctamente
Se debe evitar un alto grado de abstracción para que sea posible pasar del diseño a la implementación final
Si están bien hechos se estará garantizando la correcta construcción y validación del sistema final
Un problema importante en la captura de requisitos es:
Los cambios que estos pueden sufrir a a largo de la vida del proyecto de desarrollo
Esta tarea no suele estar contemplada en los ciclos de vida que se aplican en los procesos de desarrollo
No existen técnicas apropiadas para validar la calidad de los requisitos capturados
La dificultad para plasmarlos en gráficos y diagramas
¿Qué es un modelo?
Es una descripción simplificada de una realidad que ayuda a entenderla
Es una implementación incompleta de un determinado desarrollo
Es un sistema enteramente desarrollado antes de su validación
Es un ciclo de vida de desarrollo o construcción de un sistema real
¿Qué es una caja negra?:
Un elemento que se estudia considerando solo las entradas que recibe y las respuestas que da a dichas entradas
Un elemento que se estudia considerando su funcionamiento interno
Un elemento que se estudia considerando su nivel alto o bajo de abstracción
Un elemento que se esfudia considerando las respuestas que proporciona independientemente de sus detalles internos y las entradas recibidas
La especificación de requisitos:
Es una descripción de cómo debería ser el sistema final una vez terminado
Es una definición de los componentes del sistema como la base de datos, la interfaz,etc...
Es la implementación de los primeros prototipos del sistema aptos para su validación
Es un manual de desarrollo y/o funcionamiento de la aplicación
¿Qué significa que un software es "Correcto"?
Que hace lo que se requiere según las especificaciones
Que trabaja correctamente siempre, sin fallos
Que hace su trabajo con los recursos disponibles
Que es seguro
Diferencia entre análisis y diseño:
El análisis captura requerimientos y necesidades del sistema; y el diseño además muestra como hacer el desarrollo para resolver dicho problema
El análisis describe los requisitos, necesidades y algunos algoritmos más complejos; y el diseño comienza con la implementación de dichos algoritrnos
El análisis captura requerimientos y necesidades; y el diseño describe el problema en general y determina el ciclo de vida a utilizar
El análisis captura requerimientos, necesidades y determina el ciclo de vida que se va a utilizar y el diseño muestra como hacer el desarrollo para resolver dicho problema
Sobre el concepto de "abstracción":
Supone ver un elemento como un todo, considerando su funcionalidad observada externamente sin importar su implementación u operaciones internas
Supone estudiar al máximo todos los detalles de un elemento para comprenderlo mejor y poder así implementarlo
Supone descomponer un elemento en partes para abordar mejor el estudio de cada una de ellas
Supone ver un elemento como un sistema, estudiando tanto su interacción con otros sistemas como su funcionamiento intemo
Si consideramos un microondas como un sistema, su capa de abstracción sería...
Los botones o reguladores para programar la potencia y el tiempo
El mecanismo encargado de emitir las ondas que cocinan y calientan alimentos
El motor que hace girar el plato intemo
El mecanismo que emite las ondas junto con el motos que gira el plato interno
En el proceso de Revisión Técnica Formal...
Los revisores estudian previamente el objeto a revisar y en la revisión exponen las pegas detectadas
Los revisores conocen durante la exposición el objeto a revisar y en la revisión exponen las pegas detectadas
Los revisores estudian previamente el objeto a revisar y en la revisión exponen las pegas detectadas y plantean soluciones para resolverlas
Los revisores conocen durante la exposición el objeto a revisar y en la revisión exponen las pegas detectadas y plantean soluciones para resolverlas
¿En qué momento se hace la gestión de requisito?:
Durante la duración completa del proyecto y en todas sus etapas
Al final, para ver que modificaciones hay que hacer el producto ya terminado
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 la etapa de implementación en adelante
En el proceso de refinamiento modular, cada paso nuevo de refinamiento...
Crea módulos más pequeños menos abstractos
Crea módulos más pequeños y más abstractos
Crea módulos más pequeños y mas encapsulados
Crea módulos más pequeños menos encapsulados
Hacer un buen diseño es importante porque...
Facilita las tareas posteriores de implementación, pruebas y mantenimiento
Facilita la elección de un ciclo de vida adecuado para que el producto final sea de calidad
Facilita una buena captura de requisitos
Facilita la definición correcta de los módulos de la aplicación
¿Cuándo finaliza el proceso de refinamientos sucesivos?:
Cuando el coste de desarrollo e integración de los módulos sea mínimo
Cuando se tienen 4 niveles de módulos
Cuando se tienen módulos que se pueden implementar con no más de 30 o 40 líneas de código
Cuando el coste de desarrollo de cada módulo es mínimo