Cuestiones
ayuda
option
Mi Daypo

TEST BORRADO, QUIZÁS LE INTERESEFIS parcial 1

COMENTARIOS ESTADÍSTICAS RÉCORDS
REALIZAR TEST
Título del test:
FIS parcial 1

Descripción:
Test para estudiar FIS

Autor:
Mr.White
(Otros tests del mismo autor)

Fecha de Creación:
12/03/2019

Categoría:
Universidad

Número preguntas: 20
Comparte el test:
Facebook
Twitter
Whatsapp
Comparte el test:
Facebook
Twitter
Whatsapp
Últimos Comentarios
No hay ningún comentario sobre este test.
Temario:
En relación al desarrollo del software: En el desarrollo dirigido por modelos (model driven development), y en concreto en el model to code, se podría generar código a partir de un diagrama de clases La implementación se realiza inmediatamente después del análisis de requisitos El ciclo de vida es la vida de un producto software desde el comienzo de una idea hasta su desarrollo e implantación El modelo en cascada no acepta ni retroalimentación ni prototipado.
En el modelo espiral: El desarrollo del software se realiza en una única iteración o incremento Las primeras versiones del software son prototipos que serán siempre desechables El número de iteraciones está indefinido Reúne la naturaleza iterativa del modelo en cascada con los aspectos controlados del modelo incremental.
En el desarrollo basado en reutilización: Los productos de la familia de producto comparten aspectos comunes pero nunca su diseño arquitectónico El ensamblado de componentes se puede hacer sin necesidad de conocer los detalles internos En el desarrollo de componentes los ciclos de vida son más cortos. Un componente es una pieza de código que encapsula un conjunto de funciones no relacionadas (o de datos).
En relación a las características de los requisitos: Definen cómo se debe hacer y no el qué se debe hacer Deben ser no ambiguos, es decir, que no tengan conflictos con otros requisitos Se denominan atributos a las características de los requisitos Se denomina atributo a información complementaria, como p.ej. el tipo.
En relación a los requisitos: Por ejemplo, que una aplicación funcione para la última versión Oreo de Android, sería un requisito funcional Cuando se quiere que la aplicación a desarrollar resulte fácil de aprender estamos hablando de un requisito funcional Cuando queremos que una pasarela de pago sea segura estamos hablando de un requisito no funcional Requisitos esperados son aquellos establecidos en las reuniones con los clientes, de manera que si estos requisitos están presentes los clientes quedan satisfechos.
En relación a la validación de los requisitos: La validación de requisitos se reduce a comprobar que son verificables Una de las técnicas empleadas para validar los requisitos es la generación de casos de uso El coste de hacer un desarrollo con un requisito erróneo es inversamente proporcional al tiempo en que se detecta como tal Cuando nos encontramos un requisito para el que no es posible probar si el sistema lo satisface decimos que es no verificable.
En relación a los modelos: UML es el lenguaje de modelado que se utiliza de manera standard en cualquier paradigma de programación UML cubre todas las necesidades de especificación de un producto, como por ejemplo la especificación de requisitos no funcionales En la especificación de requisitos se utilizan modelos para describir los escenarios de uso El modelo representa todos los aspectos de la realidad y por tanto es una abstracción de la misma.
En relación a los diagramas de casos de uso: En cada caso de uso se especifica el cómo hace el sistema, no el qué En una relación de generalización entre actores un actor se especializa en otros Un caso de uso simple no puede estar incluido en varios casos bases simultáneamente En una relación extend se termina de ejecutar antes el caso que extiende.
En relación a los diagramas de casos de uso: Las secuencias de eventos alternativos del caso de uso son susceptibles de ser descritas conversacionalmente Cada caso de uso tiene un escenario alternativo Los actores pueden tener distintos roles en un escenario Los escenarios alternativos representan las acciones más habituales.
En relación al análisis: El modelado de comportamiento para el paradigma de objetos se instancia en el diagrama de clases En el Diagrama de Flujo de Datos, los procesos del diagrama de nivel 1 se subdividen en otros procesos que dan lugar al diagrama de nivel 0 Una diferencia entre los Diagramas Entidad-Relación y los Diagramas de Clases es que se adoptan en paradigmas de programación diferentes Los diagramas de clases son modelos estáticos mientras que los diagramas de objetos son dinámicos.
En relación a los diagramas de clases de modelado conceptual: La transgresión del encapsulamiento se produce con la no ocultación de los atributos Los atributos pueden preservar el principio de encapsulación del paradigma Orientado a Objetos no siendo ni protegidos ni privados Al igual que ocurre en los diagramas de casos de uso, se debe incluir la clase “system” Es necesario especificar los parámetros de los métodos así como el tipo de los atributos.
En relación a los diagramas de clases de modelado conceptual: Las clases asociación se derivan de una asociación etiquetada en el centro por los roles La relación reflexiva es antisimétrica En las relaciones de agregación inclusiva la navegación es unidireccional En la relación de composición las partes tienen sentido sin el todo.
El modelo en cascada: Soporta bien el cambio durante el proceso. No necesita unos requisitos bien definidos. Necesita unos requisitos bien definidos y razonablemente estables. Soporta el cambio durante el proceso siendo indiferente que los requisitos estén bien definidos.
En el modelo en espiral: Se utilizan prototipos. Los prototipos se deben evitar. El desarrollo se ajustará a un calendario previsto con la suficiente antelación. Se conoce de antemano el número de iteraciones a dar hasta obtener el software.
En relación con el diseño del software: Se determinan los modelos del diseño y a continuación se utilizan para modelar los requisitos. Se determinan primero los modelos de requisitos, por tener un nivel más bajo de abstracción que los modelos de diseño. Se refinan los modelos de diseño hasta generar los modelos de requisitos. Los diagramas de casos de uso, DFD’s, diagramas de clase, diagramas de estado o de secuencia se utilizan para realizar los modelos del diseño.
En los diagramas de clase: Es obligatorio utilizar la notación UML (Unified Modelling Language). Las relaciones de agregación y composición se utilizan para indicar que una clase está formada por otra u otras. Las relaciones de herencia se establecen habitualmente entre dos objetos y son bidireccionales. Las relaciones siempre tienen una multiplicidad.
En los casos de uso: Siempre existe un escenario principal y uno alternativo. Siempre existe un escenario principal. Existe un único escenario que se denominará o bien principal o bien alternativo. Existe un escenario o bien típico o bien de fracaso.
El análisis de requisitos: Se realiza para detectar conflictos que hayan surgido al establecer los requisitos Es la única labor que realiza el ingeniero de requisitos. Se realiza antes de la extracción de requisitos (requirements elicitation). Se realiza después del modelado de requisitos.
Los requisitos: Se clasifican en normales, deseados e inesperados (exciting). Se clasifican en normales o funcionales e inesperados o no funcionales. Se clasifican en normales, esperados e inesperados (exciting). Se clasifican en funcionales, no funcionales y disfuncionales.
En los diagramas de casos de uso: Cada usuario tiene un único rol. Los actores pueden referirse a usuarios pero nunca a otras aplicaciones. Un mismo rol no puede ser desempeñado por distintos actores. Se puede interaccionar con otras aplicaciones.
Denunciar test Consentimiento Condiciones de uso