MEDAC Entornos Tema 11-20 DAM

Los diagramas de actividad…. A. No están contemplados en UML. B. Permiten mostrar el flujo de ejecución. C. Realizan una tarea similar a los diagramas de secuencia. D. Ninguna de las anteriores es correcta.

Un diagrama de tiempo…. A. Permite mostrar el flujo temporal. B. No está contemplado en UML. C. Se puede utilizar para planificación temporal del proyecto. D. Ninguna de las anteriores es correcta.

En un diagrama de actividad podemos distinguir…. A. Nodos objeto. B. Nodos de control. C. Nodos ejecutables. D. Todas las anteriores son correctas.

Cuando queremos mostrar la planificación temporal…. A. Mejor utilizar un diagrama de clases. B. Mejor utilizar un diagrama de planificación. C. Mejor utilizar un diagrama de tiempos. D. Ninguna de las anteriores es correcta.

En referencia los diagramas de tiempo…. A. Existen diferentes tipos. B. No se pueden utilizar en la planificación UML. C. No tiene sentido utilizarlos en el desarrollo software. D. Ninguna de las anteriores es correcta.

Un diagrama de red de tareas…. A. Es un tipo especial de diagrama de actividad. B. Es un tipo especial de diagrama de tiempo. C. Es un tipo especial de diagrama de clase. D. Es un tipo especial de diagrama de secuencia.

Un diagrama de Gantt…. A. Es lo mismo que un diagrama de barras. B. Se puede utilizar para la planificación temporal. C. Tiene muchas limitaciones para el desarrollo software. D. Todas las anteriores son correctas.

Un diagrama PERT…. A. Es un diagrama de secuencia. B. Es un diagrama de actividad. C. Es un tipo de diagrama de clases. D. Ninguna de las anteriores es correcta.

Para contemplar los retrasos en la planificación…. A. Es mejor utilizar un diagrama de actividad. B. Hay que utilizar un diagrama de clases. C. Es suficiente con cualquier diagrama de tiempo. D. Ninguna de las anteriores es correcta.

En un diagrama de actividad…. A. Es necesario marcar el estado inicial. B. Hay que tener en cuenta las actividades. C. Hay que incluir las acciones. D. Todas las anteriores son correctas.

Un diagrama de estado…. A. Solo se aplica en el ámbito matemático. B. Proviene del ámbito matemático. C. Solo se utiliza en el diseño software. D. Ninguna de las anteriores es correcta.

El término determinista…. A. No se aplica los diagramas de estado. B. No tiene nada que ver con la informática. C. Es imprescindible en los diagramas de estado. D. Ninguna de las anteriores es correcta.

En un diagrama de estado…. A. Solo podemos tener estados. B. Solo podemos tener estado con transiciones. C. Pueden existir estados con flujos dentro. D. Ninguna de las anteriores es correcta.

Una buena práctica para crear diagramas de estados es…. A. Definir previamente el conjunto de estados. B. Realizarlo una vez que el software esté implementado. C. Utilizar el diagrama de secuencia. D. Ninguna de las anteriores es correcta.

Un estado de convergencia…. A. No se puede representar en un diagrama de estado. B. Es aquel en el que confluyen varias transiciones de diferentes estados. C. No está soportado por UML. D. Aquel del que parten varias posibles transiciones.

Un evento en un diagrama de estado…. A. No está soportado por UML. B. No se puede representar en el sistema. C. Normalmente se produce con un disparador. D. Ninguna de las anteriores es correcta.

Para poder crear un diagrama de estado…. A. Solo puede haber un estado inicial. B. Es necesario especificar al menos un estado de finalización. C. Hay que definir los estados. D. Todas las anteriores son correctas.

En un diagrama de estado, los eventos de llamada…. A. No existen. B. Son siempre asíncronos. C. No están soportados. D. Ninguna de las anteriores es correcta.

Los eventos en el diagrama de estados…. A. Son siempre síncronos. B. Son siempre asíncronos. C. Los síncronos no se contemplan en UML. D. Pueden ser síncronos o asíncronos.

Un diagrama de estado…. A. Permite mostrar el flujo de ejecución y los estados de los objetos. B. Se puede reemplazar por un diagrama de secuencia. C. Se puede reemplazar por un diagrama de clases. D. Ninguna de las anteriores es correcta.

Las pruebas software…. No forman parte de la planificación de un proyecto. Pueden ser de diferentes tipos. Normalmente es mejor no utilizarlas. Ninguna de las anteriores es correcta.

En la planificación de un proyecto software…. Solo es necesario contemplar el tiempo de implementación. No es necesario contemplar la realización de pruebas. Es muy importante añadir el tiempo de pruebas y desarrollo de éstas. Ninguna de las anteriores es correcta.

Las metodologías basadas en pruebas…. Basan toda su filosofía en la existencia de pruebas. No existe tipo de metodologías. Son muy lentas. No se aplican en la actualidad.

Las pruebas estáticas…. Permiten observar el funcionamiento del código. Son muy potentes. Solo permiten valorar el código desde el punto vista lógico. Ninguna de las anteriores es correcta.

Las pruebas no funcionales…. Se centran en probar que se cumplen los requisitos no funcionales. Se centran en probar si se cumplen los requisitos funcionales y no funcionales. No son muy relevantes. Ninguna de las anteriores es correcta.

Las pruebas dinámicas…. Son menos potentes que las pruebas estáticas. Permiten comprobar el código en funcionamiento. No se utilizan en la actualidad. Son solo de un tipo.

Los casos de prueba…. No están relacionados con los casos de uso. Solo se relacionan con los casos de uso en requisitos no funcionales. Están relacionados con los casos de uso. Ninguna de las anteriores es correcta.

Las pruebas unitarias…. Permite verificar todo el código a la vez. Permiten comprobar cómo se comporta el código con otros componentes. Permiten comprobar que no existen errores de regresión. Ninguna de las anteriores es correcta.

Las pruebas de regresión…. Permiten comprobar que no existen efectos colaterales. Se hacen al principio del desarrollo. Son imprescindibles para avanzar más rápidamente. Todas las anteriores son correctas.

Las pruebas de integración…. Se realizan con la utilización de pruebas funcionales. Es recomendable realizarlas después de las pruebas de regresión. Es recomendable realizarlas después de las pruebas unitarias. Es mejor realizarlas después de las pruebas de componentes.

Las pruebas de caja negra…. Permiten observar los detalles del código. Ocultan totalmente los detalles del código. No son una solución válida para las pruebas software. Ninguna de las anteriores es correcta.

Las pruebas de seguridad…. No son relevantes en el software. No requieren ningún estándar. Dependerán del tipo de información almacenada. Ninguna de las anteriores es correcta.

Las pruebas de usabilidad…. Se realizan siempre automáticamente. No son necesarias en el software. Requieren siempre intervención humana. No afectan en la calidad de la aplicación.

Las pruebas de aceptación…. Son de las últimas en realizarse. Pueden requerir información de estadísticas. Se suelen realizar incluso una vez publicado el software. Todas las anteriores son correctas.

Las pruebas de tipo A/B…. Son poco eficientes. No permiten elegir el mejor candidato. No se utilizan en el desarrollo software. Ninguna de las anteriores es correcta.

Las pruebas de caja blanca…. Pueden tener acceso total al código. No pueden ver los detalles de implementación. No se aplican en el software. No son eficientes para detectar errores.

El enfoque exploratorio…. No es una solución válida para las pruebas software. Aplica una metodología determinada. Se centran en la experiencia del probador. Ninguna de las anteriores es correctas.

Las pruebas de caja gris…. Son una solución intermedia entre las pruebas de caja negra y las de caja blanca. No existe en el desarrollo software. Son un tipo de prueba exploratoria. Ninguna de las anteriores es correcta.

El desarrollo de prueba en cascada…. Es el más utilizado en la actualidad. No se adapta a las necesidades actuales de las empresas. No utiliza prueba de caja negra. No utiliza prueba de caja blanca.

Las pruebas de accesibilidad…. Permiten aumentar el público objetivo. Actualmente son muy importantes. Se suelen confundir con las pruebas de usabilidad. Todas las anteriores son correctas.

El depurador de código…. No es necesario en ningún caso. Se vuelve más necesario a medida que aumenta el número de líneas de código. Afecta al rendimiento de la versión final. Ninguna de las anteriores es correcta.

El depurador…. Nunca se incluye en los entornos de desarrollo. Solo se puede utilizar en lenguajes compilados. Permite la utilización de puntos de ruptura. Ninguna de las anteriores es correcta.

Un punto de ruptura…. Permite aumentar la velocidad de ejecución. No se pueden introducir versiones depuración. Permite parar el flujo de ejecución en un punto determinado. Ninguna de las anteriores es correcta.

Para conocer el contenido de una variable…. Solo podemos imprimirla por los logs. No se puede saber el contenido de una variable. En versiones de depuración se puede utilizar los examinadores de variables. Solo es posible conocer los valores de las variables en entornos web.

En relación con los puntos de ruptura…. Son necesarios para la versión de depuración. Dificultan el flujo de ejecución. Dificultan el proceso de desarrollo. Ninguna de las anteriores es correcta.

Para poder generar una versión de depuración…. Es necesario que sea soportado por el entorno de desarrollo. Es necesario que sea soportado por el hardware subyacente. Deben existir una versión especial de depuración. Todas las anteriores son correctas.

A la hora de depurar el interior de una función…. Se puede utilizar la opción step into. Se puede utilizar la opción step forward. Se puede utilizar la opción step out. Ninguna de las anteriores es correcta.

A la hora de depurar un programa…. No podemos fijar muchos puntos de ruptura. No tenemos que considerar los requisitos de la máquina. No hay que generar una versión especial de la aplicación. Ninguna de las anteriores es correcta.

Al trabajar con muchas líneas de código…. Es mejor utilizar una impresora para depurar. No es posible utilizar la depuración. Lo ideal es disponer de un depurador. Ninguna de las anteriores es correcta.

Desde el punto de vista del programador…. Tener muchos puntos de ruptura es costoso. Disponer de un depurador es una pérdida de tiempo. Es importante utilizar herramientas adecuadas al desarrollo. Ninguna de las anteriores es correcta.

Para poder realizar pruebas a mayor velocidad…. Es necesario tener claro los vectores de pruebas. Hay que definir y acotar los rangos de pruebas. Se pueden utilizar herramientas de prueba automática. Todas las anteriores son correctas.

La calidad del código…. No tiene ninguna forma de medirse. Es fundamental para disponer de un buen producto. No se relaciona con las pruebas. Ninguna de las anteriores es correcta.

Los valores extremos…. No requieren de pruebas específicas. No se aplican en el software. Son valores de casos particulares. Ninguna de las anteriores es correcta.

Desde el punto de vista de los estándares…. No se pueden utilizar para medir el código. No existe ningún estándar que se pueda utilizar en el software. Permiten determinar reglas para medir la calidad del software. Ninguna de las anteriores es correcta.

En cuanto a la realización de pruebas…. Son necesarias para garantizar la seguridad. Permiten garantizar la fiabilidad del software. Pueden requerir mucho tiempo para su ejecución. Todas las anteriores son correctas.

En relación con JUnit …. Es una herramienta para realizar pruebas unitarias. Es una herramienta para medir la calidad. Una herramienta que permite documentar el código. Ninguna de las anteriores es correcta.

Las pruebas de interfaz gráfica…. Normalmente requieren la intervención humana. Normalmente se automatizan. No se llevan nunca acabo. Ninguna de las anteriores es correcta.

Las pruebas unitarias…. Pueden ser muy numerosas. Solo garantizan que el código es correcto. Puede llegar a ser complicado realizarlas. Todas las anteriores son correctas.

Las pruebas de cobertura…. Son muy complicadas de realizar. No se pueden aplicar a soluciones software. Son las más comunes de realizar. Ninguna de las anteriores es correcta.

Las clases de equivalencia…. Aumentan el número de casos de prueba. No se pueden aplicar al software. Disminuyen el número de casos de prueba. No afecta al número de casos de prueba.

La refactorización…. Es una tarea muy sencilla. Requiere comprobar el código generado. No posee ninguna herramienta de apoyo. Ninguna de las anteriores es correcta.

Las herramientas de refactorización…. Pueden ayudar a realizar un borrado seguro. Pueden ayudar a realizar un renombrado de métodos. Pueden ayudar a realizar un renombrado de variables. Todas las anteriores son correctas.

Los patrones de refactorización…. Solo se pueden aplicar a determinados casos. No garantizan que se estructure mejor el código. Requieren que se hagan pruebas a posteriori. Ninguna de las anteriores es correcta.

Al referirnos a la sustitución de bloques…. Hace referencia a cambiar el nombre de los métodos. Se refiere a encapsular los datos. Permite sustituir bloques dando el nombre de métodos. Ninguna de las anteriores es correcta.

Cuando movemos una clase a otro nivel…. Es un tipo de refactorización. No podemos hablar de refactorización. Siempre se produce un error. Ninguna de las anteriores es correcta.

En referencia a los analizadores de código…. Se pueden utilizar para conocer el estado de nuestro código. Pueden apoyar en la toma decisiones. Están basados en métricas. Todas las anteriores son correctas.

Las herramientas para la refactorización…. Permiten la refactorización de manera automática. No incluyan métodos para renombrado. No se encuentran integradas en los entornos de desarrollo. Ninguna de las anteriores es correcta.

Para poder realizar un borrado seguro…. Es necesario recompilar. Deberíamos tener en cuenta dónde se está utilizando el elemento de código a borrar. El borrado nunca es una tarea segura. Ninguna de las anteriores es correcta.

Los analizadores de código…. No son utilizados en la actualidad. Tienen una potencia más limitada. Suelen estar integrados en el editor del entorno de desarrollo. Ninguna de las anteriores es correcta.

La realización de pruebas…. No son necesarias cuando se hace una refactorización. No se pueden aplicar después de una refactorización. Son poco eficientes después de una refactorización. Ninguna de las anteriores es correcta.

Un sistema de generación de generación documentación…. Utiliza etiquetas para marcar los datos. Puede ser integrados en entornos de desarrollo. Pueden trabajar con múltiples lenguajes de programación. Todas las anteriores son correctas.

Los sistemas de control de versiones…. Complican la tarea trabajar con equipos grandes. Son muy útiles a la hora de trabajar con equipos grandes. No son recomendables de utilizar en el código. Ninguna de las anteriores es correcta.

Cuando surge un conflicto con el código…. El sistema de gestión de versiones no se puede utilizar. Siempre se utilizará lo más nuevo. Será necesario la intervención humana para resolver el conflicto. Ninguna de las anteriores es correcta.

Las herramientas de generación automática de documentación…. No son adecuadas para generar manuales de usuario. No son necesarias en el desarrollo software. Pueden utilizarse para generar manuales de usuario. Ninguna de las anteriores es correcta.

A la hora de trabajar con un sistema de control de versiones…. Es necesario descargar el código. Es posible realizar modificaciones. Se puede subir el código cuando sea necesario. Todas las anteriores son correctas.

La herramienta Doxygen…. Se trata de un sistema Cloud. Permite controlar las versiones del código. Es un sistema de generación de documentación. Ninguna de las anteriores es correcta.

En relación con JavaDoc…. Permite llevar a cabo el control del código. Permite generar documentación para diferentes lenguajes. No funciona con etiquetas. Ninguna de las anteriores es correcta.

A la hora de subir el código a un repositorio…. Pueden existir conflictos. Siempre se soluciona automáticamente los conflictos encontrados. No es posible realizar la subida al repositorio en cualquier momento. Ninguna de las anteriores es correcta.

A la hora de documentar APIs…. Se pueden utilizar herramientas de generación de documentación. Se pueden utilizar etiquetas. Una alternativa sería JavaDoc si está escrito en Java. Todas las anteriores son correctas.

La documentación creada para las APIs…. Puede servir a desarrolladores externos. Puede servir a desarrolladores internos. Se puede generar con la herramienta de generación automática de documentación. Todas las anteriores son correctas.

Los repositorios de código distribuido…. Solo permite que el código está en un nodo central. Permiten que el código esté en diferentes máquinas de los usuarios. Son menos potentes que los centralizados. Ninguna de las anteriores es correcta.

Un sistema de control de versiones…. Puede afectar al rendimiento del equipo. Debe de adaptarse a la forma de trabajo. Pueden tener interfaz gráfica. Todas las anteriores son correctas.

Al trabajar con múltiples ramas de desarrollo…. Es mejor tener un sistema distribuido. Es mejor tener un sistema centralizado. No podemos tener un sistema centralizado. Ninguna de las anteriores es correcta.

El sistema de control de versiones Git…. Es un sistema antiguo. Es menos potente que SVN. Es un sistema distribuido. Ninguna de las anteriores es correcta.

Un sistema de control de versiones basado en repositorio centralizados…. Suelen ser más rígidos a la hora de trabajar. Puede ser adecuado para medidas de seguridad. Pueden tener problema con el renombrado de archivos. Todas las anteriores son correctas.

A la hora de establecer roles, un repositorio…. Es más sencillo en un sistema distribuido. Es más sencillo en un sistema centralizado. Tenemos que hacerlo a nivel de servidor. Ninguna de las anteriores es correcta.

Utilizando Git…. No es necesario inicializar el repositorio. No se puede clonar repositorio remoto. Se puede hacer commit en local. Nunca surgen conflictos.

Cuando surge un conflicto…. Git lo resuelva automáticamente. SVN lo resuelve automáticamente. En los repositorios distribuidos no pueden existir conflictos. Ninguna de las anteriores es correcta.

En referencia al histórico de cambios…. Git no posee histórico de cambios. SVN no permite ver los cambios realizados. En el caso de Git hay que utilizar git clone log. Ninguna de las anteriores es correcta.

En cuanto a la integración con los sistemas operativos…. SVN dispone de mayor compatibilidad. Los sistemas operativos tienen que ser adaptados para este tipo de herramientas. Git posee mayor compatibilidad. El sistema operativo no influye en estas herramientas.

En cuanto a los sistemas Cloud…. Existe SaaS. Existe PaaS. Existe IaaS. Todas las anteriores son correctas.

La utilización del repositorio de basados en Cloud…. No se utilizan en la actualidad. Permiten simplificar la estructura de nuestra empresa. Son muy lentos. Ninguna de las anteriores es correcta.

Al utilizar GitHub…. Es posible utilizar paneles como Kanban. No es posible el trabajo colaborativo. Solo hay suscripciones de pago. Ninguna de las anteriores es correcta.

A la hora de elegir un sistema cloud para almacenamiento de código…. Es necesario elegir siempre uno de pago. Es mejor utilizar aquellos que permitan crear repositorios públicos. Es importante elegir aquellos que puedan crear diferentes tipos de repositorios. Ninguna de las anteriores es correcta.

En relación con GitHub…. No permite crear repositorios públicos. No permite crear repositorio privados. Permite crear wikis por cada proyecto. No se puede utilizar en contextos web.

Al utilizar GitLab…. Podemos utilizar SVN. Podemos establecer colaboradores en nuestros proyectos. No se puede usar en proyectos multiplataformas. Ninguna de las anteriores es correcta.

En relación con GitLab…. Permite almacenar menos archivos que GitHub. No permite almacenar imágenes. Ofrece suscripciones de pago y gratuitas. Ninguna de las anteriores es correcta.

A la hora de utilizar repositorio como GitHub…. Es importante tener en cuenta el tamaño del código del proyecto. Es importante tener en cuenta el tamaño máximo del archivo. Es necesario considerar el tipo de suscripción. Todas las anteriores son correctas.

Como alternativa GitHub y GitLab…. Podemos utilizar SourceForge. Podemos utilizar GNU Savannah. Podemos utilizar Bitbucket. Todas las anteriores son correctas.

En un proyecto en el que tenemos que hacer integración continua y trabajar con archivos muy grandes…. Es mejor utilizar GitHub. No es posible utilizar soluciones basadas en la nube. Es mejor utilizar GitLab. Ninguna de las anteriores es correcta.