Ingeniería S2

¿Qué técnica de especificación de requerimientos utiliza plantillas predefinidas?. Lenguaje natural estructurado. Lenguaje natural. Diagramas. Tablas.

¿Cuál de los siguientes elementos Reduciría la ambigüedad en la especificación de requerimientos?. Descripciones cortas y simplificadas. Abundante jerga técnica. Uso extensivo de diagramas y flujogramas. Redacción vaga e informal.

El estándar IEEE recomienda que la especificación de requerimientos incluya: La priorización y planificación de cada requerimiento. Un glosario de términos utilizados. El código fuente detallado de cada módulo. La descripción de la base de datos relacional.

Los requerimientos no funcionales usualmente se elicitan por medio de: Casos de uso para modelar procesos detallados. Prototipos para validar soluciones técnicas. Análisis de documentos y normativas existentes. Entrevistas abiertas para conocer objetivos abstractos.

¿Cuál es el principal riesgo de no validar adecuadamente los requerimientos?. Entregar un sistema que no satisface al cliente. Demoras en la entrega del sistema. Incremento en el presupuesto del proyecto. Dificultad para mantener el sistema.

¿Qué técnica involucra la observación del trabajo real de los usuarios?. Etnografía. Prototipos. Escenarios. Casos de uso.

¿Cuál es la ventaja de utilizar escenarios durante la adquisición de requerimientos?. Identifican inconsistencias entre requerimientos. Permiten una validación temprana de requerimiento. Son fáciles de entender para los usuarios no técnicos. Facilitan la clasificación y priorización de requerimientos.

¿Cuál es el propósito de incluir información sobre posibles cambios en el documento de especificación de requerimientos?. Evitar decisiones de diseño restrictivas. Facilitar la planificación de nuevas versiones. Advertir sobre incompatibilidades técnicas. Predecir cómo evolucionará el sistema en el futuro.

¿Cuál de los siguientes NO es un ejemplo de requerimiento no funcional?. El sistema debe permitir búsquedas en todas las clínicas. El sistema debe tener una interfaz amigable para el usuario. El sistema debe ser seguro y prevenir accesos no autorizados. El sistema debe ser portable a múltiples plataformas.

¿Cuál es la información mínima que debe tener la especificación estructurada de un requerimiento funcional?. Entradas, salidas y datos requeridos. Descripción básica, entradas y fuente del requerimiento. Solo precondición, postcondición y efectos colaterales. Prioridad, riesgos e interdependencias.

La negociación de requerimientos es necesaria debido a que: Los recursos para el proyecto son ilimitados. Las prioridades de los usuarios son homogéneas. Inevitablemente hay opiniones contradictorias. No existen conflictos entre los interesados.

¿Por qué se recomienda incluir pre y post condiciones al especificar requerimientos funcionales?. Para definir restricciones antes y después de ejecutar una función. Para especificar entradas y salidas de cada función. Para dividir la función en partes obligatorias y opcionales. Para vincular requerimientos dependientes entre sí.

¿Qué tipo de lenguaje debe evitarse en la especificación de requerimientos?. Analogías que faciliten la comprensión. Jerga y acrónimos técnicos de software. Términos del negocio propios de los usuarios. Descripciones conceptuales de alto nivel.

Según Sommerville (2011), durante el proceso de validación de requerimientos, tienen que realizarse diferentes tipos de comprobaciones sobre los requerimientos contenidos en el documento de requerimientos. ¿Cuál de los siguientes no una de las comprobaciones?. Comprobaciones de realismo. Comprobaciones de validez. Comprobaciones de consistencia. Verificabilidad. Comprobaciones de totalidad. Comprobación lógica.

¿Por qué es difícil que un conjunto de requerimientos satisfaga por completo a todos los usuarios?. Los usuarios tienen necesidades conflictivas. Los requerimientos técnicos limitan la funcionalidad. El presupuesto restringe la implementación. Los requerimientos cambian con el tiempo.

. ¿Cuál es la ventaja de desarrollar casos de prueba durante la validación de requerimientos?. Verifica que los requerimientos sean realizables o comprobables. Permite validar la completitud de los requerimientos. Garantiza que los requerimientos estén bien documentados. Detecta requerimientos ambiguos o inconsistentes.

La comprobación de totalidad en la validación verifica que: El sistema pueda desarrollarse con los recursos disponibles. Se hayan implementado las funciones más importantes. No haya funciones o restricciones faltantes. Los requerimientos deriven de los procesos del negocio.

¿Qué representa el diagrama de casos de uso en UML. Los procesos internos del sistema. Los componentes arquitectónicos del sistema. Los requerimientos funcionales y no funcionales. Las interacciones entre actores y el sistema.

¿Por qué es importante registrar la fuente u origen de cada requerimiento?. Para establecer la prioridad e importancia del requerimiento. Para identificar a quién consultar si el requerimiento cambia. Para definir los casos de prueba detallados. Para determinar si debe ser un requerimiento funcional o no funcional.

¿Por qué es difícil evitar por completo detalles de diseño al especificar requerimientos de sistema?. Porque los programadores los necesitan para desarrollar el sistema. Porque se debe diseñar una arquitectura inicial para estructurarlos. Porque los requerimientos cambian y deben actualizarse constantemente. Porque el usuario siempre solicita detalles de implementación.

¿Cuál es la diferencia entre requerimientos funcionales y no funcionales?. Los requerimientos funcionales describen lo que hará el sistema, los no funcionales describen cómo lo hará. Los requerimientos funcionales son servicios específicos, los no funcionales son restricciones y propiedades. Los requerimientos funcionales son del sistema, los no funcionales del usuario. Los requerimientos funcionales son obligatorios, los no funcionales son opcionales.

¿Por qué es importante registrar la fuente u origen de cada requerimiento?. Para establecer la prioridad e importancia del requerimiento. Para identificar a quién consultar si el requerimiento cambia. Para determinar si debe ser un requerimiento funcional o no funcional. Para definir los casos de prueba detallados.

¿Cuál de los siguientes NO es un lineamiento recomendado para escribir requerimientos en lenguaje natural?. Resaltar partes claves del requerimiento. Ser lo más técnico posible para no perder precisión. Usar un formato estándar para todos. Distinguir entre requerimientos obligatorios y deseables.

La etnografía permite elicitar requerimientos que reflejan: La forma en que los usuarios realizan actualmente su trabajo. Los objetivos de negocio abstractos de los altos directivos. Los procesos organizacionales formales documentados. Las necesidades explícitas indicadas por los usuarios.

La etnografía permite elicitar requerimientos que reflejan: La forma en que los usuarios realizan actualmente su trabajo. Los objetivos de negocio abstractos de los altos directivos. Los procesos organizacionales formales documentados. Las necesidades explícitas indicadas por los usuarios.

. La comprobación de validez en la validación de requerimientos implica: Confirmar que están correctamente documentados. Verificar carencias en los requerimientos recolectados. Asegurar que sean técnicamente factibles de implementar. Garantizar que sean consistentes y no contradictorios.

¿Por qué es tan costoso corregir errores en los requerimientos durante el desarrollo?. Fuerza la renegociación del contrato. Requiere cambiar el plan del proyecto. Obliga a rehacer el diseño y la implementación. Necesita volver a capacitar a los usuarios.

En la validación de requerimientos, la generación de casos de prueba permite encontrar: Falta de trazabilidad entre requerimientos y código fuente. Conflictos entre requerimientos funcionales y no funcionales. Inconsistencias y omisiones en los requerimientos. Desviaciones del presupuesto y cronograma preliminares.

. La creación de prototipos en la ingeniería de requerimientos sirve para: Evaluar soluciones técnicas tentativas. Desarrollar parte del sistema de manera eficiente. Obtener requerimientos detallados por parte de los usuarios. Definir la arquitectura inicial del sistema.

¿Qué es el documento de especificación de requerimientos de software (ERS)?. Un documento formal con requerimientos detallados para el sistema. Un documento legal que obliga al proveedor a cumplir los requerimientos. Un documento preliminar con requerimientos de alto nivel. Un documento informal y opcional con ideas de requerimientos.

¿Por qué se genera conflicto entre requerimientos no funcionales y otros tipos de requerimientos?. Porque tienen diferentes orígenes y propósitos. Porque los no funcionales limitan la funcionalidad deseada. Porque cambian con más frecuencia durante el proyecto. Porque son de menor prioridad que los funcionales.

Según el texto, la especificación de requerimientos debe ser: Lo más simple posible para facilitar su lectura. Centrada en aspectos técnicos y detalles de implementación. Enfocada en requerimientos de muy alto nivel. Un equilibrio entre detalle técnico y comprensión del negocio.

¿Cuál es el propósito principal de los diagramas y modelos en la especificación de requerimientos?. Representar el diseño de base de datos. Desarrollar casos de prueba exhaustivos. Describir interacciones, flujos y cambios de estado. Definir la arquitectura detallada del sistema.

¿Cuál es el propósito principal de la especificación estructurada de requerimientos?. Hacer la especificación más formal y reducir ambigüedades. Permitir especificaciones gráficas y matemáticas. Mejorar la comunicación con los usuarios no técnicos. Facilitar cambios y actualizaciones a los requerimientos.

. ¿Qué problema puede causar el uso de jerga y abreviaturas en los requerimientos?. Menor precisión en la especificación. Confusión para usuarios no técnicos. Incumplimiento de estándares de documentación. Dificultad para traducirlos a otros idiomas.

¿Qué problema puede causar el uso de jerga y abreviaturas en los requerimientos?. Menor precisión en la especificación. Confusión para usuarios no técnicos. Incumplimiento de estándares de documentación. Dificultad para traducirlos a otros idiomas.

¿Qué problema puede causar el uso de jerga y abreviaturas en los requerimientos?. Menor precisión en la especificación. Confusión para usuarios no técnicos. Incumplimiento de estándares de documentación. Dificultad para traducirlos a otros idiomas.

¿Qué tipo de problema busca detectar la revisión de requerimientos?. Requerimientos no realizables. Requerimientos inconsistentes o incorrectos. Requerimientos difíciles de verificar. Requerimientos que no reflejan las necesidades reales.

¿Cuál es el propósito principal de la validación de requerimientos?. Verificar que los requerimientos definan el sistema deseado por el cliente. Detectar requerimientos inconsistentes o ambiguos. Asegurar que los requerimientos sean realistas y verificables. Garantizar que todos los requerimientos estén completos.

¿Cuál es el propósito principal de incluir razones junto con los requerimientos?. Describir cómo se implementará el requerimiento. Explicar por qué se necesita ese requerimiento. Priorizar y clasificar los diferentes requerimientos. Mostrar quién solicitó el requerimiento.

¿Por qué es importante evitar ambigüedades en la especificación de requerimientos?. Porque dificulta la comunicación con los usuarios. Porque hace el mantenimiento más complicado. Porque viola los estándares y normas de especificación. Porque puede causar malentendidos y errores en el desarrollo.

La plantilla en la especificación estructurada ayuda a: Reducir la cantidad de detalles. Simplificar el lenguaje. Usar terminología más técnica. Estandarizar los requerimientos.

. Los requerimientos del sistema detallan los requerimientos de usuario con el fin de: Describir la implementación y el código fuente. Definir la arquitectura y el diseño detallado. Ser utilizados como entrada por los desarrolladores. Establecer la interacción entre componentes.

¿Qué tipo de sistema requiere una especificación de requerimientos más exhaustiva y detallada?. Un sistema que interactúa poco con otros sistemas. Un sistema web sencillo desarrollado internamente. Un sistema desarrollado con metodología ágil. Un sistema crítico y complejo.

¿Por qué la etnografía es útil para la adquisición de requerimientos?. Facilita la comunicación con usuarios no técnicos. Identifica rápidamente las necesidades de los usuarios. Permite observar cómo usan el sistema existente. Revela requerimientos implícitos de los procesos reales.

Los requerimientos deben ser verificables para minimizar: Conflictos posteriores entre el cliente y el equipo de desarrollo. La posibilidad de cambios luego de la fase de diseño detallado. Riesgos en la implementación derivados de su ambigüedad. Renegociaciones del alcance debido a malentendidos.

Los requerimientos no funcionales suelen ser: Claros, objetivos y fáciles de validar. Directamente relacionados con casos de uso específicos. Más significativos que los requerimientos funcionales. Menos importantes que los requerimientos funcionales.

Los requerimientos funcionales se obtienen principalmente mediante: Observación etnográfica de los procesos organizacionales. Derivación de políticas y normativas institucionales. Análisis de requerimientos de sistemas existentes similares. Entrevistas con los usuarios finales.

La comprobación de consistencia en la validación de requerimientos implica: Validar que no existan conflictos entre requerimientos. Verificar que no haya requerimientos redundantes. Confirmar que estén completamente documentados. Garantizar que sean trazables a través del código fuente.

Los requerimientos deseables en un sistema: Se implementan después de los requerimientos obligatorios. Son obligatorios y críticos para el éxito del sistema. Se omiten porque no son esenciales. Se escriben usando "debería" en lugar de "debe".

Según el texto, la principal causa de problemas en el desarrollo de software es: La evolución y cambio frecuente de requerimientos. La falta de participación de los usuarios finales. La ausencia de un documento de requerimientos detallado. La mala interpretación de requerimientos por parte de los desarrolladores.

Un requerimiento funcional ambiguo puede provocar que: Aumenten significativamente los costos. Se extienda el tiempo de desarrollo. Los desarrolladores lo interpreten de manera incorrecta. Todas las anteriores.

¿Por qué se recomienda evitar el uso de jerga y abreviaturas al escribir requerimientos?. Porque dificulta la traducción a otros idiomas. Porque los usuarios no las entenderán. Porque irán en contra de estándares y normas. Porque se prestan a malinterpretaciones.

Los stakeholders o interesados principales en la especificación de requerimientos son: El equipo de desarrollo de software. Los encargados de pruebas y QA. Todas las anteriores. Los usuarios finales y expertos del negocio.

¿Cuál es el objetivo principal de la adquisición de requerimientos?. Descubrir y documentar las necesidades de los usuarios. Validar que los requerimientos sean consistentes. Priorizar y negociar requerimientos con los usuarios. Clasificar y organizar los requerimientos por subsistemas.

Los requerimientos no funcionales usualmente restringen: Las características y comportamiento global del sistema. Las funciones específicas provistas por el sistema. Las interfaces externas con otros sistemas existentes. Los componentes individuales que implementan cada requerimiento.

¿Cuál es el objetivo de clasificar y organizar los requerimientos?. Resolver inconsistencias entre requerimientos. Asociar requerimientos con subsistemas. Priorizar requerimientos por importancia. Simplificar la especificación de requerimientos.

¿Qué tipo de requerimientos se derivan principalmente de las entrevistas?. Requerimientos organizacionales y externos. Requerimientos funcionales de los usuarios. Requerimientos no funcionales del sistema. Requerimientos no explícitos o implícitos.

Los escenarios son útiles para elicitar requerimientos con usuarios inexpertos porque: Describen interacciones concretas con el sistema. No requieren una participación muy activa de los usuarios. Se centran en aspectos abstractos del negocio. Permite utilizar un lenguaje técnico preciso.

¿Cuál de las siguientes NO es una razón por la que los requerimientos del sistema pueden incluir detalles de diseño?. Para estructurar la especificación. Para evitar cambios costosos. Para reutilizar componentes existentes. Por restricciones técnicas.

¿Cuál es la principal ventaja de usar tablas para especificar requerimientos?. Permiten especificar requerimientos gráficos. Son más simples que el lenguaje natura. Tienen una estructura clara y eliminan ambigüedades. Se integran fácilmente con diagramas.

Según el texto, la especificación de requerimientos debe ser: Lo más simple posible para facilitar su lectura. Centrada en aspectos técnicos y detalles de implementación. Enfocada en requerimientos de muy alto nivel. Un equilibrio entre detalle técnico y comprensión del negocio.

La etnografía enfatiza en: Evaluación de opciones tecnológicas. Procesos formales definidos por la organización. Comportamientos informales reales de los usuarios. Requisitos explícitos planteados por los usuarios.

Qué debe especificarse como parte del diseño de la arquitectura. Propiedades extrafuncionales, estructurales y clases de diseño. Modularidad, abstracción y aspectos. Propiedades extrafuncionales, estructurales y familias de diseños. Propiedades estructurales, extrafuncionales y familias de sistemas relacionados.

. ¿Qué tipo de sistemas generan datos para el sistema especificado?. Sistemas internos. Sistemas de hardware. Sistemas externos. Sistemas manuales.

. ¿Qué tipo de modelos se utilizan para representar sistemas de manera formal?. Modelos formales (matemáticos). Modelos de casos de uso. Modelos de interacción. Modelos de contexto.

Una especificación de requerimientos para el desarrollo externalizado de un sistema debe ser: Menos detallada porque habrá comunicación directa. Más detallada para evitar malinterpretaciones. Enfocada en el diseño e implementación. Centrada en requerimientos de alto nivel.

La clasificación y organización de requerimientos permite: Agrupar relacionados en categorías coherentes. Definir un cronograma detallado de entrega. Resolver inconsistencias y conflictos. Negociar la prioridad e importancia relativa.

La comprobación de realismo en la validación considera: La participación comprometida de los usuarios. La posibilidad técnica de implementar los requerimientos. La facilidad de uso y capacitación requerida. La aprobación formal de los requerimientos por los interesados.

¿Cuál de los siguientes NO es un atributo de calidad propuesto por McCall?. Usabilidad. Seguridad. Tolerancia a fallas. Eficiencia.

Seleccione la característica de un acoplamiento de control. Este acoplamiento lleva a la propagación incontrolada del error. Ocurre cuando una operación transmite una bandera de control a otra operación. Ocurre cuando un componente modifica subrepticiamente datos internos de otro componente. Este acoplamiento lleva a una propagación controlada de un error.

Relacione la característica correspondiente según el lineamiento. A Componentes 1 Para mejor legibilidad, modelar de izquierda a derecha B Interfaces 2 Los nombres deben provenir del dominio del problema C Dependencias 3 Deben aparecer aquellas que sean relevantes para el componente. A1 – B2 – C3. A1 – B3 – C2. A3 – B2 – C1. A2 – B3 – C1.

¿Cuál de los siguientes NO es un beneficio potencial de los estándares de software?. Definen expectativas de calidad. Promueven el uso de buenas prácticas. Reducen la necesidad de pruebas. Facilitan la consistencia entre proyectos.

¿Cuál es el propósito principal de la certificación ISO 9001?. Definir procesos de desarrollo de software. Establecer el uso de herramientas específicas. Auditar los procesos de gestión de calidad. Garantizar software de alta calidad.

¿Qué conceptos fundamentales modela UML para el diseño de componentes?. Abstracciones y generalizaciones. Restricciones y contexto. Colaboraciones e interfaces. Procesos y datos.

. Relacione el concepto según la característica para cada componente. A Calificación 1 Implica la integración fácil en la arquitectura de una aplicación. B Adaptación 2 Garantiza que un componente ejecute la función requerida. C Combinación 3 Ensambla componentes con la ingeniería necesaria para la arquitectura. A1 – B2 – C3. A2 – B1 – C3. A2 – B3 – C1. A1 – B3 – C2.

La ingeniería de software basada en componentes, ¿en qué se enfoca?. En la reutilización. En el diseño orientado a objetos. En el modelado de objetos. En la construcción con componentes reutilizables.

El tipo de materiales, tolerancias y especificaciones del desempeño, todo contribuye a: Los estándares de software. Las especificaciones del programa. La conformidad de diseño. La calidad de diseño.

El modelo de calidad de McCall clasifica los factores de calidad en: Características operativas, modificabilidad y portabilidad. Corrección, eficiencia y facilidad de mantenimiento. Funcionalidad, confiabilidad y usabilidad. Eficiencia, flexibilidad y estabilidad.

¿Qué señala el Principio de Sustitución de Liskov?. Que los componentes cliente deben poder utilizar subclases sin problema. Que los componentes deben tener bajo acoplamiento. Que las interfaces de los componentes deben ser fácilmente extensibles. Que los cambios no deben afectar a otros componentes.

Complete el concepto para el diseño del contenido en el nivel de componente. Se encuentra ________ en objetos de contenido y en la _________ que se empacan para su presentación a un usuario _________ de webapps. diseñado – forma - final. centrado – estructura - informático. centrado – forma – final. diseñado – estructura – informático.

La adaptación de componentes, ¿qué problema resuelve?. Inconsistencias en la coordinación. Restricciones funcionales. Errores sintácticos. Incompatibilidad de interfaces.

En qué consisten los estándares de proceso. Se aplican al producto de software a desarrollar. Es un proceso extenso en donde se congregan los interesados en el estándar. Establecen los procesos que deben seguirse durante el desarrollo del software. Establecen como debe usarse un lenguaje de programación.

¿Cuál es el propósito principal de los estándares de software?. Reducir la creatividad en el desarrollo de software. Limitar el uso de nuevas tecnologías. Definir buenas prácticas y expectativas de calidad. Mejorar la productividad de los programadores.

Las tablas de decisión, ¿cómo contribuyen en el diseño de componentes?. Ayudan en la verificación. Facilitan la implementación. Reducen la ambigüedad. Mejoran la eficiencia algorítmica.

¿Qué construye la Ingeniería de Dominio?. Una biblioteca de componentes reutilizables. Los conectores. Los requisitos. La infraestructura.

¿Qué construcción NO tiene una representación estructurada?. Recursión. Repetición. Secuencia. Condición.

La calidad de un producto de software según Pressman depende de: Cumplimiento de estándares internacionales. Uso de las mejores herramientas y lenguajes. Desarrollo por equipos altamente calificados. Un proceso eficaz, utilidad del producto y valor para el productor y usuario.

La confiabilidad en el modelo de calidad de ISO 9126 se relaciona con: Exactitud de los resultados generados. Seguridad de acceso del sistema. Facilidad de uso del sistema. Disponibilidad del sistema para su uso.

¿Qué construcción NO se representa en los diagramas mostrados?. Excepción. Condición. Secuencia. Repetición.

Cuál es el concepto adecuado para la Ingeniería del dominio. Describir la interfaz al componente e identificar la semántica. Determinar componentes que apuntan hacia componentes reutilizables. Colocar un componente de software reutilizable en su dominio de aplicabilidad. Identificar un conjunto de componentes de software aplicables en futuro.

El contexto de un componente, ¿qué permite?. Su clasificación. Su modificación. Su reutilización efectiva. Su recuperación.

La calidad de un producto de software según Pressman depende de: Un proceso disciplinado, cumplimiento de requisitos y beneficios para el productor y usuario final. Cumplimiento de estándares internacionales y uso de las mejores prácticas. Uso de las herramientas y lenguajes de programación más modernos. Desarrollo por un equipo altamente calificado.

¿Cuál de los siguientes NO es un beneficio de usar estándares de software?. Definen expectativas de calidad. Promueven la reutilización de conocimiento de valor para la organización. Eliminan la necesidad de probar el software. Proveen continuidad entre múltiples desarrolladores.

¿Qué concepto define un contrato entre un componente cliente y servidor?. Condición. Restricción. Conexión. Colaboración.

¿Qué diagramas permiten representar las construcciones estructuradas?. Diagrama de secuencia. Diagrama de estados. Diagrama de actividades. Diagrama de casos de uso.

A que se denomina un acoplamiento externo. Ocurre cuando se transmiten cadenas largas de argumentos de datos. Ocurre cuando se declara una clase como argumento de operación de otra clase. Ocurre cuando un componente modifica subrepticiamente datos internos de otro componente. Ocurre cuando un componente se comunica con componentes de infraestructura.

En los estándares del producto, pueden incluir otro tipo de estándares tales como: Estándares de calidad, estándares de codificación y estándares de documentos. Estándares de documentos, estándares de documentación y estándares de codificación. Estándares de documentos, estándares de codificación y estándares de proceso. Estándares de codificación, estándares de documentación y estándares de proceso.

¿Cuál es la principal diferencia entre los estándares ISO 9001 y CMMI?. ISO 9001 es un marco de trabajo y CMMI define procesos específicos. ISO 9001 se enfoca en productos y CMMI en procesos. CMMI es más reciente que ISO 9001. CMMI es específico para software y ISO 9001 es genérico.

¿Qué permite el uso de construcciones estructuradas en el diseño?. Mejorar la legibilidad y facilidad de pruebas. Reducir la complejidad algorítmica. Aumentar la modularidad. Todas las anteriores.

¿Qué mejora propone el Principio de Inversión de Dependencias?. Evitar el uso de componentes específicos. Basar los componentes en abstracciones. Reducir el contenido de los componentes. Hacer los componentes más independientes.

¿Qué aspectos describe el contenido de un componente?. Sus detalles de implementación. Su semántica. Sus características externas. Su contexto de uso.

Según las dimensiones de calidad que pertenecen a Garvin, cual es la que permite sorprender la primera vez a los usuarios finales. Calidad del desempeño. Usabilidad. Conformidad. Calidad de las características.

¿Cuál es la principal diferencia entre los estándares ISO 9001 y CMMI?. CMMI es para software y ISO 9001 para hardware. ISO 9001 se enfoca en el proceso y CMMI en el producto. CMMI define procesos y ISO 9001 es un marco de trabajo. ISO 9001 es prescriptivo y CMMI es flexible.

¿Qué permite la adaptación de componentes?. Reducir inconsistencias. Integrarse más fácilmente en la arquitectura. Mejorar la interoperabilidad. Todas las anteriores.

Relacione el tipo de cohesión con su concepto adecuado. A Funcional 1 Las operaciones que acceden a los datos se definen dentro de una clase. B De capa 2 Ocurre cuando una capa más alta accede a los servicios de otra más baja. C De comunicación 3 Ocurre cuando un componente realiza un cálculo y devuelve el resultado. A2 – B3 – C1. A1 – B2 – C3. A3 – B2 – C1. A1 – B3 – C2.

¿Qué nivel de cohesión presentan los paquetes y componentes?. Capas. Funcional. Comunicación. Rutinas.

La calidad de conformidad se enfoca en: La capacidad de un sistema para ser modificado. El grado de concordancia entre la implementación y el diseño. La satisfacción del usuario con el sistema. El grado en que un sistema cumple sus objetivos.

Cuál de las siguientes es una característica de un estándar de producto. Realizar revisión de diseño. Formato de plan de proyecto. Proceso de registro de prueba. Proceso de control de cambio.

¿Qué busca minimizar el diseño a nivel de componentes?. La complejidad. La cohesión. El acoplamiento. El rendimiento.

¿Qué permite representar el diagrama de actividades?. La secuencia, condición y repetición, y desciende de un diseño gráfico. La calificación, adaptación y combinación, y desciende de un diseño gráfico. La estructura lógica de un lenguaje de programación. Las clases, componentes y herencia de un diseño gráfico.

Seleccione cual es el concepto adecuado para el principio de sustitución de Liskov. Cualquier clase base de una clase derivada funcionará bien con el componente cuando se respeta la precondición establecida. Cualquier clase derivada de una clase base funcionará bien con el componente cuando se respeta la precondición establecida. Cualquier clase derivada creará abstracciones que servirán como búfer entre la funcionalidad y la clase. Cualquier clase o componente se diseñan para ser reutilizables.

¿Cuál es el propósito de los atributos de calidad como "intuitivo", "eficiente" y "robusto" para evaluar una interfaz de usuario?. Definir expectativas abstractas de los usuarios. Comparar diferentes interfaces de usuario. Cuantificar la calidad mediante métricas objetivas. Proveer criterios prácticos para evaluar la calidad.

La calidad del software se centra en tres aspectos importantes del producto de software: Componentes, interfaces y dependencias. Servicio, estética y percepción. Características operativas, capacidad de ser modificado y adaptabilidad a nuevos escenarios. Funcionalidad, confiabilidad y usabilidad.

Seleccione el principio básico del diseño en el cual se cambia el número de liberación del paquete y las demás clases deben ejecutar pruebas para comprobar su funcionamiento. Principio abierto-cerrado. Principio de la reutilización común. Principio de la sustitución de Liskov. Principio de cierre común.

¿Qué NO forma parte de la descripción de un componente?. Concepto y contexto. Restricciones. Contenido. Interfaz.

Seleccione la característica de un acoplamiento común. Ocurre cuando un componente modifica subrepticiamente datos internos de otro componente. Este acoplamiento lleva a una propagación controlada de un error. Ocurre cuando una operación transmite una bandera a otro control. Este acoplamiento lleva a la propagación incontrolada del error.

Seleccione una razón por la cual los estándares de software son importantes. Los estándares solo funcionan dentro de la misma empresa. Los estándares reflejan la sabiduría que es de valor para los ingenieros. Los estándares auxilian la continuidad cuando una persona retoma el trabajo iniciado por alguien más. Los estándares proporcionan un marco para definir, en un escenario particular, lo que significa el término “software”.

Los estándares de software son importantes porque: Capturan buenas prácticas y definen calidad. Limitan el uso de nuevas tecnologías. Restringen la creatividad de los programadores. Reducen la necesidad de pruebas.

¿Qué permite determinar la calificación de un componente?. Su calidad. Su contenido. Su contexto. Su utilidad.

La infraestructura en la Ingeniería de software basada en componentes (ISBC), ¿qué permite principalmente?. La coordinación entre componentes. La clasificación de componentes. La recuperación de componentes. La calificación de componentes.

En que consiste la calidad de diseño: Se refiere a las características que los diseñadores especifican para un producto. Se enfoca en el grado de apego entre la implementación y el diseño, y en el que el sistema resultante cumple sus metas de requerimientos y desempeño. Grado en el que un programa satisface sus especificaciones y en el que cumple con los objetivos de la misión del cliente. Se refiere a la cantidad de funcionalidades que puede tener un producto.

¿Cuál de los siguientes NO es una razón para establecer estándares de software en una organización?. Facilitar la continuidad entre desarrolladores. Establecer expectativas de calidad. Incrementar la productividad de los programadores. Definir procesos y prácticas óptimas.

Según el modelo de Pressman, la calidad del software depende de: Uso de tecnologías y metodologías modernas. Equipos de desarrollo altamente capacitados. Adherencia a estándares y certificaciones. Cumplimiento de requisitos, valor para el usuario, proceso disciplinado.

¿Qué permite la cohesión funcional en un componente?. Reutilización. Realizar un cálculo específico. Fácil mantenimiento. Encapsulamiento efectivo.

¿Qué permite modelar adecuadamente un Lenguaje de Diseño de Programa?. Todas las anteriores. Bloques y construcciones de programación. Estructuras de datos. Interfaces.

La calidad de un producto de software según Pressman depende principalmente de: Cumplimiento de estándares y certificaciones. Desarrollo por equipos altamente capacitados. Un proceso disciplinado que genere beneficios al usuario y productor. Uso de metodologías y herramientas modernas.

Seleccione el principio básico del diseño en el cual se crea una interfaz especializada para atender a cada categoría de cliente. Principio de cierre común. Principio de la sustitución de Liskov. Principio segregación de la interfaz. Principio de la equivalencia de la liberación de la reutilización.

Según las dimensiones de calidad que pertenecen a Garvin, en cual se pregunta ¿Está disponible cuando se necesita?. Integridad. Durabilidad. Usabilidad. Confiabilidad.

Seleccione el principio básico del diseño en el cual se agrupan las clases que van dirigidas a la misma función. Principio de la sustitución de Liskov. Principio de cierre común. Principio abierto-cerrado. Principio de la reutilización de común.

¿Qué tipos de cohesión existen?. Funcional, comunicación y control. Funcional, capas y comunicación. Capas, rutinas y datos. Funcional, capas y control.

¿Qué formato NO es útil para representar componentes?. Pseudocódigo. Diagrama UML. Diagrama de flujo. Tabla de decisión.

¿Qué es la calidad del diseño según Pressman?. La calidad del diseño se refiere a la capacidad de un sistema para adaptarse a nuevos escenarios de uso. La calidad del diseño se refiere a las características que los diseñadores especifican para un producto. La calidad del diseño se refiere a la facilidad para mantener un sistema sin reducir su confiabilidad. La calidad del diseño se refiere a las características que los usuarios finales valoran en un producto de software.

Por qué los clientes de software demandan que sus proveedores tengan la certificación ISO 9001. Para estar seguros de que la compañía que desarrolla el software tiene un producto final aprobado. Para estar seguros de que la compañía que desarrolla el software tiene un sistema de gestión de calidad aprobado. Para estar seguros de que la compañía que desarrolla el software tiene un manual aprobado. Para estar seguros de que la compañía que desarrolla el software tiene un inventario aprobado.

Cuál es la dimensión de calidad que pertenecen a Garvin en la cual un proveedor que anteriormente se consideraba de mala calidad lanza un nuevo producto y se genera una influencia negativa. Estética. Conformidad. Percepción. Integridad.

¿Qué permite representar el diagrama de actividades?. La secuencia, condición y repetición, y desciende de un diseño gráfico. La estructura lógica de un lenguaje de programación. Las clases, componentes y herencia de un diseño gráfico. La calificación, adaptación y combinación, y desciende de un diseño gráfico.

¿Cuál es el propósito principal de los estándares de producto en software?. Seleccionar las herramientas de desarrollo. Todas las anteriores. Definir la documentación requerida. Especificar prácticas de codificación.

A que se denomina un acoplamiento externo. Ocurre cuando un componente se comunica con componentes de infraestructura. Ocurre cuando un componente modifica subrepticiamente datos internos de otro componente. Ocurre cuando se declara una clase como argumento de operación de otra clase. Ocurre cuando se transmiten cadenas largas de argumentos de datos.

¿Cuál es el propósito principal de los estándares de proceso en software?. Definir prácticas de codificación. Seleccionar herramientas de desarrollo. Describir las actividades de desarrollo de software. Especificar el formato de documentos.

Esta norma se desarrolló con el propósito de identificar los atributos clave del software de cómputo. Factores de la calidad ISO 2012. Dimensiones de la calidad de Garvin. Factores de la calidad de McCall. Factores de la calidad ISO 9126.

¿Qué concepto define un contrato entre un componente cliente y servidor?. Restricción. Condición. Conexión. Colaboración.

¿Cuál es el propósito principal de la evaluación de la usabilidad de una interfaz de usuario?. Compararla con otras interfaces. Determinar si tiene las características deseadas. Cuantificar métricas de calidad. Verificar el cumplimiento de requisitos.

Según los factores de la calidad de McCall. Cuál es el factor en el que un programa satisface sus especificaciones y en el que cumple con los objetivos de la misión del cliente. Corrección. Confiabilidad. Eficiencia. Integridad.

¿Cuál de las siguientes afirmaciones sobre los estándares ISO 9001 es FALSA?. Requieren auditorías de terceros. Proveen un marco para gestión de calidad. Definen procesos de desarrollo de software específicos. Son genéricos para múltiples industrias.

Relacione los factores de la calidad que se persiguen con su respectivo concepto A Intuitiva 1 Grado en que la interfaz provee varias características. B Eficiencia 2 Grado en el que sigue patrones esperados, hasta un novato podría usarla. C Riqueza 3 Grado en que se pueden localizar las operaciones y la información D Robustez 4 Grado de manejo para entradas erróneas de datos. A3 – B2 – C1 – D4. A2 – B1 – C3 – D4. A2 – B3 – C1 – D4. A2 – B4 – C1 – D3.

Los estándares ISO 9001: Son específicos para la industria del software. Garantizan software de alta calidad. Definen un marco para desarrollar sistemas de gestión de calidad. Definen procesos específicos de desarrollo de software.