Taller De Analisis y Diseño De Software Parcial 1

¿Cuál de las siguientes NO es una actividad fundamental de la ingeniería de software presente en todas las metodologías?. Especificación de requerimientos. Diseño e implementación del producto. Marketing y ventas del producto. Validación y verificación.

Las actividades fundamentales son especificación, diseño e implementación, validación/verificación y evolución. El marketing no es una actividad de ingeniería de software per se. Un conjunto de herramientas CASE para programar. Únicamente la etapa de codificación del software. Un conjunto coherente de actividades para la construcción de un producto de software. La documentación detallada del código fuente.

¿En qué tipo de proyectos se sigue utilizando preferentemente el modelo en cascada hoy en día?. Proyectos pequeños con requisitos poco claros. Desarrollo de aplicaciones web interactivas. Sistemas críticos donde una falla puede causar graves daños. Proyectos que requieren entregas funcionales rápidas.

Una característica distintiva del Modelo V respecto al modelo en cascada simple es: Elimina completamente la necesidad de documentación. Permite iniciar la codificación sin tener los requisitos definidos. Hace explícita la relación entre las fases de desarrollo y las actividades de prueba correspondientes. Se enfoca exclusivamente en el desarrollo ágil.

¿Cuál es una desventaja principal del modelo en cascada?. Permite una gran flexibilidad para cambios de requisitos durante el desarrollo. Permite una gran flexibilidad para cambios de requisitos durante el desarrollo. Entrega versiones funcionales del producto en etapas tempranas. Los requisitos se consideran invariantes una vez definidos, lo cual no es realista.

¿Cuál es el objetivo principal del modelo incremental?. Definir todos los requisitos al inicio y no modificarlos. Un crecimiento progresivo de la funcionalidad del producto a través de entregas. Minimizar la documentación del proyecto. Realizar un análisis exhaustivo de riesgos en cada fase.

El modelo en espiral se diferencia de otros modelos principalmente por: Su simplicidad y facilidad de gestión. Su reconocimiento explícito y gestión continua del riesgo. La ausencia de planificación en sus ciclos. Ser adecuado solo para proyectos muy pequeños y de bajo riesgo.

En el modelo incremental, si se adopta un enfoque ágil, la selección de funcionalidades para el siguiente incremento depende de: Las prioridades del cliente. El plan detallado realizado al inicio del proyecto. Las prioridades definidas por el equipo de desarrollo únicamente. La disponibilidad de herramientas de desarrollo.

Según el Manifiesto Ágil, se valora más: Los procesos y las herramientas sobre los individuos y las interacciones. La documentación exhaustiva sobre el software operativo. La colaboración con el cliente sobre la negociación del contrato. Seguir un plan sobre la respuesta al cambio.

¿Cuál de las siguientes es una característica fundamental de los enfoques ágiles?. Una planificación detallada y fija al inicio del proyecto. Poca o nula participación del cliente durante el desarrollo. Entrega incremental del producto. Resistencia a los cambios en los requerimientos.

Las metodologías ágiles son más adecuadas cuando: El equipo de trabajo es grande y distribuido geográficamente. Los requisitos son completamente estables y conocidos desde el inicio. El proyecto es de alta criticidad y requiere documentación exhaustiva. El equipo de trabajo es pequeño y puede comunicarse informalmente.

El concepto de "encapsulamiento" en la orientación a objetos se refiere a: Que un objeto puede comportarse de modos distintos en distintas clases. Separar los aspectos externos del objeto de los detalles internos de implementación. Compartir atributos y operaciones entre clases mediante una jerarquía. organizar el software como una colección de objetos discretos.

¿Qué es una "clase" en el paradigma orientado a objetos?. Una instancia específica con identidad y estado. Una implementación específica de un comportamiento. Una plantilla o estructura a partir de la cual se crean objetos. Una relación jerárquica entre objetos.

El polimorfismo permite que: Los datos estén cuantificados en entidades discretas llamadas objetos. Una operación pueda comportarse de modos distintos en distintas clases. Se compartan atributos y operaciones entre clases basadas en una jerarquía. Los aspectos internos de un objeto queden ocultos a otros objetos.

En el Análisis y Diseño Orientado a Objetos (ADOO), el Análisis Orientado a Objetos (AOO) se ocupa principalmente de: Modelar el problema en términos de objetos relacionados del dominio del problema. Definir la mejor solución técnica y la implementación. Traducir el diseño a un lenguaje de programación específico. Optimizar el rendimiento de la base de datos.

¿Cuál es una característica distintiva del enfoque orientado a objetos respecto a los enfoques estructurados en cuanto a las fases de análisis y diseño?. Existe una separación muy marcada y una gran distancia entre análisis y diseño. El análisis se realiza exclusivamente con diagramas de flujo y el diseño con pseudocódigo. El diseño orientado a objetos precede siempre al análisis orientado a objetos. La transición entre análisis y diseño es mucho más suave, difuminando sus fronteras.

Los objetos del dominio de la solución en el Diseño Orientado a Objetos (DOO) incluyen: Únicamente conceptos abstractos del problema. Solamente los requisitos funcionales del sistema. Objetos de interfaz, objetos de aplicación y objetos base o de utilidad. Exclusivamente los casos de uso del sistema.

¿Cuáles son las tres características esenciales del proceso de software propuesto por RUP?. Secuencial, centrado en la documentación y no iterativo. Dirigido por casos de uso, centrado en la arquitectura, e iterativo e incremental. Ágil, enfocado solo en la codificación y con poca planificación. Basado en el modelo en cascada, con fases estrictas y sin solapamiento.

¿Cuál es el objetivo principal de la fase de "Elaboración" en RUP?. Definir el alcance del proyecto y el caso de negocio. Construir completamente el sistema y realizar todas las pruebas. Planificar el proyecto, especificar la mayoría de los casos de uso y definir la arquitectura base. Entregar el producto final a los usuarios y obtener su aceptación.

La fase de "Transición" en RUP se enfoca en: La identificación inicial de riesgos y la definición de objetivos. El desarrollo de la mayor parte de la funcionalidad del sistema. La entrega del producto a los usuarios y su puesta en operación. La creación de la primera línea base de la arquitectura.

En RUP, una "disciplina" se entiende como: Una fase del ciclo de vida del proyecto. Un conjunto de actividades vinculadas a un área específica del proyecto, como requerimientos o diseño. Una herramienta de software utilizada en el desarrollo. Un entregable específico para el cliente.

¿Cuál de las siguientes es una de las buenas prácticas recomendadas por el Proceso Unificado?. Evitar el desarrollo iterativo para mantener la estabilidad del proyecto. Minimizar la gestión de requerimientos para agilizar el desarrollo. El uso de arquitecturas basadas en componentes. No realizar verificación de la calidad del software hasta el final del proyecto.

La disciplina de "Requerimientos" en RUP está asociada principalmente con el modelo de: Diseño. Implementación. Casos de Uso. Prueba.

UML (Unified Modeling Language) es principalmente un: Lenguaje de programación de alto nivel. Sistema de gestión de bases de datos. Lenguaje estándar para visualizar, especificar, construir y documentar sistemas de software mediante modelos visuales. Metodología de desarrollo de software completa.

Los diagramas de UML se pueden agrupar en dos categorías principales: Diagramas simples y diagramas complejos. Diagramas de flujo y diagramas de entidad-relación. Diagramas de estructura y diagramas de comportamiento. Diagramas manuales y diagramas generados por herramientas CASE.

Una "vista" en UML representa: La totalidad del sistema de software. Un subconjunto de las construcciones de modelado que representa un aspecto del sistema. Únicamente la interfaz de usuario del sistema. El código fuente del sistema.

En un diagrama de casos de uso, un "Actor" representa: Un componente interno del sistema. Una función específica que el sistema realiza. Un rol o entidad externa que interactúa con el sistema. Una base de datos utilizada por el sistema.

La relación <<include>> entre dos casos de uso (A incluye a B) significa que: El caso de uso A es opcional y extiende la funcionalidad de B. El caso de uso B es una parte obligatoria y se inserta en el caso de uso A. Los casos de uso A y B son completamente independientes. El caso de uso A es una generalización del caso de uso B.

¿Cuál de las siguientes afirmaciones es una buena práctica al nombrar casos de uso?. Usar sustantivos que describan el resultado. Usar frases largas y muy detalladas. Usar acrónimos y abreviaturas siempre que sea posible. Usar verbos o frases verbales que indiquen una acción.

Si un caso de uso "Realizar Pago con Tarjeta" y "Realizar Pago con Transferencia" comparten una funcionalidad común "Verificar Datos de Pago", esta última podría ser un caso de uso abstracto relacionado con los dos primeros mediante: Extensión. Inclusión. Generalización. Asociación directa.

En un diagrama de clases, el compartimento de atributos de una clase contiene: Las propiedades o características de los objetos de esa clase. Las acciones que la clase puede realizar. Las clases con las que se relaciona. Las instancias específicas de la clase.

La relación de "Composición" entre una Clase A (todo) y una Clase B (parte) implica que: La Clase B puede existir independientemente de la Clase A. La Clase A es una especialización de la Clase B. Si la Clase A (el todo) es destruida, la Clase B (la parte) también deja de existir. Existe una comunicación opcional entre A y B.

¿Qué símbolo de visibilidad se utiliza para un atributo o método protegido en un diagrama de clases UML?. +. -. #. ~.

Un diagrama de objetos muestra: La estructura genérica de las clases y sus relaciones. El comportamiento dinámico de un solo objeto a lo largo del tiempo. Las instancias de las clases (objetos) y los enlaces específicos entre ellas en un momento determinado. El flujo de actividades dentro de una operación.

¿Qué diagrama UML se utiliza para hacer hincapié en la secuencia temporal del intercambio de mensajes entre objetos?. Diagrama de Clases. Diagrama de Actividad. Diagrama de Secuencia. Diagrama de Estados.

Un diagrama de máquina de estados modela: Las posibles historias de vida de un objeto, mostrando sus estados y transiciones. La estructura de los componentes físicos del sistema. La colaboración entre un conjunto de objetos sin enfocarse en el tiempo. Las funcionalidades del sistema desde la perspectiva del usuario.

El diagrama UML que ilustra la naturaleza dinámica de un sistema mediante el modelado del flujo de una actividad a otra, mostrando pasos secuenciales y/o concurrentes, es el: Diagrama de Componentes. Diagrama de Despliegue. Diagrama de Actividad. Diagrama de Paquetes.

En un diagrama de secuencia, la dimensión vertical representa: Los diferentes objetos que participan en la interacción. El flujo de datos entre los objetos. El eje de tiempos. La estructura de clases de los objetos.

Un requerimiento funcional describe: Restricciones sobre el proceso de desarrollo, como el lenguaje a utilizar. Las propiedades emergentes del sistema, como la fiabilidad o el tiempo de respuesta. Las políticas o procedimientos de la organización del cliente. Los servicios que el sistema debe proporcionar y cómo debe reaccionar a entradas particulares.

"El sistema debe permitir a un usuario registrado consultar el saldo de su cuenta". Este es un ejemplo de: Requerimiento no funcional de producto. Requerimiento no funcional organizacional. Requerimiento funcional de usuario. Requerimiento no funcional externo.

"El sistema deberá cumplir con la Ley de Protección de Datos Personales vigente". Este es un ejemplo de: Requerimiento no funcional de producto. Requerimiento funcional de sistema. Requerimiento no funcional organizacional. Requerimiento no funcional externo.

Los requerimientos no funcionales de producto especifican: Los servicios que el sistema debe ofrecer a los usuarios. Las políticas de la organización que deben ser respetadas. El comportamiento del producto, como rendimiento, uso de recursos o fiabilidad. Las leyes y normativas externas que el sistema debe cumplir.

La etapa de "obtención o elicitación de requerimientos" tiene como objetivo: Buscar, investigar y ayudar a los clientes y usuarios a documentar sus necesidades. Diseñar la arquitectura del sistema. Escribir el código fuente del programa. Buscar, investigar y ayudar a los clientes y usuarios a documentar sus necesidades.

¿Cuál es el objetivo principal del "análisis de requerimientos" dentro del proceso de Ingeniería de Requerimientos?. Comprobar que los requerimientos definan lo que el cliente necesita. Gestionar los cambios solicitados a los requerimientos. Escribir los requerimientos en un formato estándar. Detectar conflictos y contradicciones en los requisitos obtenidos.

La "validación de requerimientos" se enfoca en: Buscar soluciones a conflictos entre necesidades de diferentes usuarios. Detectar defectos en la redacción de los requisitos. Asegurar que los requisitos verificados reflejen realmente las necesidades de clientes y usuarios. Documentar las necesidades de los usuarios en lenguaje natural.

Una de las dificultades comunes en la Ingeniería de Requerimientos es: La excesiva claridad con la que los clientes siempre expresan sus necesidades. La falta de herramientas para documentar requerimientos. Problemas de comunicación entre ingenieros y futuros usuarios, llevando a interpretaciones erradas. La poca importancia de los aspectos sociales y culturales en el proceso.

Un prototipo, en el contexto del modelo de interfaces, es principalmente una: Versión inicial o simulación del producto para demostrar conceptos y validar el diseño de interacción. Versión final y completa del producto de software. Documentación teórica de cómo funcionará el sistema. Base de datos optimizada para el sistema.

¿Cuál es una ventaja principal del uso de prototipos en el desarrollo de software?. Garantizan que no habrá errores en el producto final. Reducen la necesidad de interacción con el usuario. Permiten detectar errores y malos entendidos en etapas tempranas del desarrollo. Siempre son muy costosos y lentos de desarrollar.

Los prototipos de "parches o remiendos" se caracterizan por ser: Modelos no funcionales, solo para probar aspectos visuales. Modelos funcionales con todas las características, pero posiblemente ineficientes. Modelos que incluyen solo algunas características seleccionadas del producto final. Simples dibujos en lápiz y papel.

Para que la creación de prototipos sea exitosa, es esencial: Evitar cualquier modificación una vez creado el primer prototipo. Enfocarse únicamente en la eficiencia interna del código del prototipo. La retroalimentación oportuna y frecuente de los usuarios. Desarrollar el prototipo muy lentamente para asegurar su calidad.

El modelo de dominio tiene como principal objetivo: Definir las interfaces de usuario del sistema. Especificar el comportamiento dinámico detallado de cada objeto. Representar los conceptos significativos del dominio del problema, su vocabulario y sus relaciones estructurales. Planificar las iteraciones del desarrollo del software.

En la identificación de clases candidatas para el modelo de dominio, una buena práctica es considerar: Únicamente los verbos presentes en la descripción del problema. Solo las entidades físicas y tangibles. Los sustantivos que aparecen en la definición del problema. Exclusivamente los aspectos de la interfaz de usuario.

Al depurar la lista inicial de clases candidatas para el modelo de dominio, se deben eliminar las clases que: Tienen sentido en el dominio de la aplicación. Describen claramente una entidad. Representan conceptos implícitos del dominio. Son redundantes o irrelevantes para la solución del problema.

Si al modelar un sistema de biblioteca, se identifica que un "Libro" tiene un "Autor" y un "Lector" puede tomar "Prestado" un "Libro", ¿cuáles serían clases candidatas iniciales?. Tomar Prestado, Biblioteca. Libro, Autor, Lector, Préstamo. Consultar, Devolver. InterfazDeUsuario, BaseDeDatos.