Gestión de Proyectos Software

Las Leyes de Lehman afirman que el software puede permanecer inalterado durante largos periodos sin afectar a su utilidad. Verdadero. Falso.

Cuando varios desarrolladores trabajan sin coordinación adecuada, es frecuente que reaparezcan errores ya resueltos. Verdadero. Falso.

La Gestión de la Configuración del Software (GCS) busca evitar cambios en el software para mantener estabilidad. Verdadero. Falso.

Sin un sistema de control de versiones, es habitual que se pierdan o sobrescriban versiones de forma accidental. Verdadero. Falso.

¿Cuál es la principal idea de las Leyes de Lehman sobre la evolución del software?. El software es estático y no debería cambiar. El software debe actualizarse continuamente para evitar quedarse obsoleto. El software solo debe cambiar cuando hay un error crítico. El software evoluciona únicamente cuando cambia el hardware.

¿Cuál de los siguientes problemas aparece comúnmente en proyectos sin control de versiones?. Mejora automática de la calidad del software. Aumento de la productividad del equipo. Reaparición de bugs y pérdida de versiones. Reducción del trabajo en equipo.

La Gestión de la Configuración del Software (GCS) se define como…. Un conjunto de políticas y herramientas para impedir que el software cambie. Un sistema que solo sirve para etiquetar versiones finales. Un proceso que organiza y controla la evolución del software. Una técnica para depurar errores automáticamente.

Una herramienta de GCS sirve principalmente para…. Crear automáticamente documentación del proyecto. Controlar quién hizo qué cambio, cuándo y por qué. Mejorar el rendimiento del software en producción. Detectar vulnerabilidades de seguridad.

¿Qué consecuencia directa se obtiene al aplicar GCS en un proyecto?. Mayor riesgo de sobrescribir archivos. Desorganización del equipo. Control ordenado de la evolución del software. Eliminación total de los errores.

¿Qué describe mejor el “caos organizativo” en desarrollo de software?. Uso excesivo de herramientas de control. Falta de coordinación que deriva en versiones perdidas y errores reincidentes. Estrategias estrictas de planificación de cambios. Documentación clara y compartida.

La actividad de “Versiones” se encarga de rastrear los cambios realizados en los componentes y en el código del software. Verdadero. Falso.

La actividad de “Construcción” consiste en evaluar el impacto de los cambios antes de aplicarlos. Verdadero. Falso.

La actividad de “Entregas” se orienta a preparar versiones ejecutables del software para los usuarios o clientes. Verdadero. Falso.

La actividad “Cambios” implica analizar cuánto costará aplicar una modificación en el sistema. Verdadero. Falso.

¿Cuál es el propósito principal de la actividad “Versiones”?. Detectar errores en tiempo de ejecución. Rastrear y registrar cambios en los artefactos y el código. Generar instaladores del sistema. Elaborar documentación del producto.

La actividad de “Construcción” en GCS consiste principalmente en…. Evaluar la calidad del código escrito por cada desarrollador. Ensamblar y compilar los componentes para generar un sistema ejecutable. Registrar quién realiza un cambio y cuándo. Preparar manuales para el cliente.

La actividad encargada de analizar el impacto y coste de modificaciones es…. Versiones. Cambios. Construcción. Entregas.

¿Qué actividad prepara el software en un formato adecuado para ser entregado a los usuarios o clientes?. Versiones. Cambios. Construcción. Entregas.

¿Qué actividad permite asegurar que cada modificación en el software esté correctamente identificada y trazada?. Cambios. Versiones. Entregas. Construcción.

Cuando el equipo necesita saber si un cambio afecta a otros módulos del sistema, debe recurrir a la actividad de…. Construcción. Entregas. Versiones. Cambios.

Una codeline representa una secuencia histórica de versiones de un único componente del software. Verdadero. Falso.

Una baseline se utiliza para congelar un sistema completo o una parte importante de él en un estado específico. Verdadero. Falso.

Una codeline actúa como un punto de referencia inalterable para futuras versiones del sistema completo. Verdadero. Falso.

Una baseline contiene únicamente la versión más reciente de un solo archivo. Verdadero. Falso.

¿Qué define mejor una codeline?. La colección de documentos de usuario. La línea de tiempo de cambios de un componente individual. El conjunto completo del sistema congelado en un momento concreto. Un instalador de la versión final del sistema.

¿Qué caracteriza principalmente a una baseline?. Su constante actualización con cada modificación. Representar una versión estable y congelada del sistema completo. Ser exclusiva para bibliotecas externas. Recolectar únicamente cambios menores.

¿En qué situación es más útil una codeline?. Cuando se necesita rastrear la evolución de un archivo o componente específico. Cuando se prepara una versión lista para entregar al cliente. Cuando se necesita congelar oficiales las versiones del sistema. Cuando se documenta la arquitectura del sistema.

¿Qué afirmación describe correctamente la relación entre codeline y baseline?. La baseline es una codeline en su fase inicial. La codeline unifica varias baselines. Una baseline puede estar formada por versiones específicas tomadas de varias codelines. No existe relación, son conceptos completamente independientes.

¿Por qué es importante establecer una baseline?. Para impedir que cualquier desarrollador modifique el código. Para fijar un punto estable desde el cual se puede construir, probar o entregar el sistema. Para generar automáticamente documentación técnica. Para controlar únicamente bugs críticos.

¿Qué ocurre típicamente con una codeline a lo largo del tiempo?. Se mantiene congelada e inalterable. Evoluciona conforme se realizan cambios en un componente individual. Se convierte automáticamente en una baseline. Desaparece cuando se genera una entrega.

Los Sistemas de Control de Versiones (VCS) permiten gestionar el acceso, almacenamiento e identificación de las distintas versiones del software. Verdadero. Falso.

El repositorio público actúa como la base de datos principal que contiene las versiones definitivas del proyecto. Verdadero. Falso.

El espacio de trabajo es el repositorio en el que todos los desarrolladores suben directamente los cambios sin probarlos antes. Verdadero. Falso.

En un VCS, la historia debe ser inmutable para garantizar trazabilidad y seguridad. Verdadero. Falso.

El comando commit se utiliza para descargar la última versión del proyecto al espacio de trabajo. Verdadero. Falso.

¿Qué función principal cumplen los Sistemas de Control de Versiones (VCS)?. Crear automáticamente documentación. Gestionar el acceso y la identificación de versiones del software. Diseñar interfaces gráficas. Sustituir al sistema operativo.

El repositorio público se caracteriza por…. Ser un entorno privado del desarrollador. Contener solo archivos temporales. Ser la base de datos maestra con las versiones definitivas. No almacenar el historial del proyecto.

El espacio de trabajo (workspace) es…. El lugar donde se almacenan las versiones finales del software. El entorno local y privado del desarrollador donde edita y prueba cambios. Un servidor que controla accesos al repositorio. Una copia inmutable del código.

¿Cuál de las siguientes acciones corresponde al check-out?. Subir los cambios al repositorio. Descargar los archivos desde el repositorio al espacio de trabajo. Congelar una versión completa del sistema. Eliminar versiones antiguas.

¿Para qué sirve el commit en un VCS?. Para crear un nuevo repositorio. Para sincronizar workspace y repositorio sin enviar cambios. Para subir los cambios locales al repositorio público. Para revertir el historial del proyecto.

¿Por qué es importante tener una historia inmutable en un VCS?. Para que los desarrolladores puedan borrar versiones cuando quieran. Para asegurar integridad, trazabilidad y evitar inconsistencias. Para aumentar la velocidad de compilación. Para permitir el trabajo sin repositorio.

¿Cuál de las siguientes afirmaciones describe correctamente la “fuente de la verdad” en un proyecto?. El espacio de trabajo del desarrollador. El repositorio público donde se guardan las versiones definitivas. Los archivos temporales generados en compilación. El historial local de cada programador.

En el modelo centralizado, como en Apache Subversion (SVN), existe un único servidor maestro que almacena todas las versiones del proyecto. Verdadero. Falso.

Una de las principales ventajas de los sistemas centralizados es que permiten trabajar sin conexión a Internet o a la red. Verdadero. Falso.

Si el servidor maestro de un sistema centralizado falla, los desarrolladores pueden seguir trabajando normalmente con historial completo. Verdadero. Falso.

Los modelos centralizados suelen presentar conflictos frecuentes debido a la necesidad de actualizar y subir cambios constantemente al servidor. Verdadero. Falso.

¿Cuál de los siguientes sistemas es un ejemplo típico de modelo centralizado?. Git. Mercurial. Apache Subversion (SVN). Fossil.

En un modelo centralizado, toda la información del proyecto se almacena en…. Cada ordenador de los desarrolladores. Un único servidor maestro. Múltiples repositorios distribuidos. Un repositorio temporal local.

¿Qué ocurre si el servidor maestro de un sistema centralizado deja de funcionar?. Solo el administrador no puede trabajar. Los desarrolladores pueden trabajar sin historial. Todos los desarrolladores quedan bloqueados. El sistema crea automáticamente un servidor secundario.

Una desventaja crítica del modelo centralizado es…. La duplicación innecesaria del repositorio. La incapacidad de trabajar con varios lenguajes de programación. La necesidad de conexión permanente al servidor. La imposibilidad de registrar cambios.

¿Por qué en los sistemas centralizados son más frecuentes los conflictos?. Porque cada desarrollador trabaja en un repositorio completamente aislado. Porque todos dependen del mismo punto de sincronización. Porque el historial es inmutable. Porque los cambios se suben automáticamente.

¿Qué característica diferencia claramente a un sistema centralizado de uno distribuido?. Permitir commits locales sin conexión. Tener múltiples copias completas del repositorio en cada usuario. Mantener un único servidor maestro con la historia del proyecto. Permitir trabajo en ramas separadas.

En un modelo distribuido como Git, cada desarrollador tiene una copia completa del repositorio. Verdadero. Falso.

Git es actualmente uno de los estándares de la industria para el control de versiones. Verdadero. Falso.

Una ventaja clave del modelo distribuido es que depende totalmente de un único servidor para funcionar. Verdadero. Falso.

Las operaciones en Git son más rápidas porque se ejecutan de forma local. Verdadero. Falso.

En un modelo distribuido no es posible trabajar sin conexión a internet. Verdadero. Falso.

¿Qué caracteriza principalmente al modelo distribuido de control de versiones?. Solo el administrador tiene acceso al historial completo. Cada desarrollador posee un clon completo del repositorio. El repositorio solo se almacena en un servidor central. Las operaciones requieren conexión constante.

Una ventaja del modelo distribuido es…. La dependencia total de un servidor maestro. La imposibilidad de hacer commits locales. La resiliencia gracias a múltiples copias del repositorio. El historial compartido únicamente en la nube.

En Git, la mayoría de las operaciones (commit, diff, etc.) son rápidas porque…. Se ejecutan siempre en la nube. Los archivos se almacenan en formato comprimido. Se realizan localmente, sin acceso al servidor. Solo funcionan en memoria RAM.

¿Qué permite el modelo distribuido respecto al trabajo sin conexión?. Nada; requiere acceso constante al repositorio remoto. Solo permite visualizar archivos offline, no modificarlos. Permite hacer commits, crear ramas y comparar versiones sin internet. Solo permite compilar código sin conexión.

¿Por qué Git es considerado el estándar actual en la industria?. Porque obliga a usar un único servidor central. Porque no permite trabajar en equipo. Porque ofrece velocidad, trabajo offline y alta resiliencia. Porque no tiene historial de cambios.

La ramificación (branching) permite desarrollar nuevas funciones o correcciones sin afectar al código principal. Verdadero. Falso.

El desarrollo moderno en control de versiones suele ser estrictamente lineal. Verdadero. Falso.

El proceso de merging consiste en combinar los cambios de una rama con otra, normalmente con la rama principal. Verdadero. Falso.

Git es reconocido por su capacidad para resolver conflictos durante el proceso de fusión. Verdadero. Falso.

Crear una rama nueva siempre modifica directamente el código principal. Verdadero. Falso.

¿Qué es una rama (branch) en Git?. Un archivo temporal de compilación. Una línea divergente para trabajar en paralelo a la principal. Una copia permanente del repositorio remoto. Un registro de commits eliminados.

¿Para qué se usa principalmente el branching?. Para borrar el historial del proyecto. Para crear una línea paralela donde desarrollar sin afectar a la rama principal. Para acelerar la compilación. Para copiar automáticamente configuraciones del sistema.

¿Cuál es la función del merging?. Eliminar cambios realizados en la rama. Crear un repositorio nuevo. Combinar los cambios de una rama con otra, normalmente la principal. Evitar que los desarrolladores trabajen en paralelo.

¿Qué ventaja ofrece Git respecto a la fusión de ramas?. Impide que se produzcan conflictos. Gestiona y resuelve conflictos de forma eficiente cuando ocurren. Elimina ramas automáticamente al terminar el merge. Requiere conexión permanente para fusionar.

¿Cuál es una razón común para crear una rama?. Probar código peligroso en la rama principal. Congelar el proyecto permanentemente. Trabajar en una nueva funcionalidad o corrección sin romper el código estable. Reducir el tamaño del repositorio.

El almacenamiento basado en deltas guarda únicamente las diferencias entre una versión y la anterior. Verdadero. Falso.

Git utiliza un sistema de almacenamiento basado exclusivamente en deltas. Verdadero. Falso.

En el sistema de snapshots de Git, si un archivo no cambia, se duplica igualmente en cada versión. Verdadero. Falso.

El modelo delta es más lento para reconstruir un archivo completo porque requiere combinar varias diferencias. Verdadero. Falso.

El modelo de snapshots es generalmente más rápido para operaciones como commits, diffs o checkouts. Verdadero. Falso.

¿Qué caracteriza al almacenamiento por deltas?. Guarda una copia completa del archivo cada vez. Almacena solo las partes que cambian entre versiones. Duplica el repositorio completo en cada commit. Siempre es más rápido que los snapshots.

¿Qué tipo de almacenamiento utiliza Git?. Delta tradicional. Snapshots con archivos duplicados. Snapshots con referencias a datos no modificados. Un solo archivo global para todo el repo.

¿Por qué el modelo delta puede ser más lento para reconstruir un archivo?. Porque usa demasiada memoria RAM. Porque comprime los archivos en exceso. Porque necesita aplicar muchos cambios acumulados. Porque depende de un servidor remoto.

¿Qué ventaja ofrece el modelo snapshot de Git?. Menor velocidad en operaciones internas. Reconstrucción compleja del historial. Acceso rápido a versiones completas. Alta dependencia del repositorio remoto.

En un sistema de snapshots como Git, si un archivo se mantiene igual entre versiones…. Se vuelve a almacenar íntegramente. Se elimina del repositorio. Se marca como archivo delta. Se reutiliza mediante un puntero a la versión anterior.

La construcción del sistema consiste en transformar el código fuente en un producto ejecutable. Verdadero. Falso.

El proceso de construcción solo utiliza código fuente; no necesita librerías ni datos. Verdadero. Falso.

La compilación y el enlazado son pasos típicos del proceso de construcción. Verdadero. Falso.

La salida del proceso de construcción puede ser un ejecutable como .exe o .jar. Verdadero. Falso.

El proceso de construcción se realiza únicamente al final del desarrollo. Verdadero. Falso.

¿Cuál es el objetivo principal de la fase de construcción?. Escribir documentación. Convertir código fuente en un producto ejecutable. Diseñar la arquitectura. Comprimir los archivos del proyecto.

¿Cuál de los siguientes sí es una entrada del proceso de construcción?. Ejecutable final. Código fuente, datos y librerías. Diagramas UML. Reportes de pruebas.

¿Qué acción forma parte del proceso de construcción?. Depuración del código. Compilación y enlazado. Diseño UI/UX. Pruebas automatizadas.

¿Qué tipo de archivo es una salida típica de un build?. .uml. .docx. .exe o .jar. .png.

El enlazado (linking) en el build se encarga de: Comprimir los recursos estáticos. Unir código compilado con librerías y dependencias. Crear documentación técnica. Ejecutar pruebas unitarias.

El sistema de desarrollo suele ser la máquina local del programador, donde se realizan pruebas unitarias. Verdadero. Falso.

Un servidor de construcción garantiza un entorno limpio y controlado, reduciendo problemas como “en mi máquina funciona”. Verdadero. Falso.

El entorno objetivo es aquel donde se ejecutará finalmente el software, como móviles, PC o la nube. Verdadero. Falso.

El servidor de construcción es opcional en proyectos grandes, ya que la máquina local es suficiente para generar builds fiables. Verdadero. Falso.

El entorno de desarrollo y el entorno objetivo siempre se ejecutan en la misma plataforma. Verdadero. Falso.

¿Cuál es el propósito principal del sistema de desarrollo?. Servir como entorno limpio para builds reproducibles. Ejecutar el software final para los usuarios. Codificar y realizar pruebas unitarias en la máquina local. Asegurar despliegues automáticos en la nube.

¿Qué ventaja ofrece un servidor de construcción?. Permite ejecutar videojuegos sin latencia. Garantiza un entorno aislado y controlado para generar builds consistentes. Optimiza el consumo de memoria del ejecutable. Produce automáticamente la interfaz gráfica del sistema.

El entorno objetivo es: La máquina del desarrollador. El servidor donde se generan los builds. El lugar donde el software se ejecutará realmente. Un repositorio con las versiones estables del código.

¿Cuál de los siguientes NO es un entorno de construcción?. Sistema de desarrollo. Servidor de construcción. Entorno objetivo. Repositorio de código.

El servidor de construcción ayuda principalmente a evitar: Problemas de compatibilidad con el sistema operativo del usuario. El problema de “en mi máquina funciona”. Errores de compilador en la máquina local. La necesidad de realizar pruebas unitarias.

Los timestamps se basan en la fecha y hora de modificación de los archivos para decidir si se recompilan. Verdadero. Falso.

El uso de timestamps es totalmente fiable para evitar recompilaciones innecesarias. Verdadero. Falso.

Los checksums (hash) permiten identificar si el contenido real del archivo ha cambiado. Verdadero. Falso.

El uso de checksums evita recompilaciones innecesarias y permite compilación paralela. Verdadero. Falso.

Copiar un archivo no afecta al checksum si el contenido es idéntico. Verdadero. Falso.

¿Qué problema presentan los timestamps como criterio de recompilación?. No son compatibles con compiladores modernos. Se actualizan aunque el contenido no cambie. No funcionan en sistemas Windows. Requieren demasiado tiempo para calcularse.

¿Cuál es la principal ventaja de usar checksums sobre timestamps?. Permiten recompilar siempre todo el proyecto. Son más rápidos de calcular. Detectan cambios reales en el contenido. No requieren herramientas de compilación.

Un checksum se define mejor como: Una comparación de fechas de modificación. Un número generado a partir del contenido del archivo. Una etiqueta del sistema operativo. Un nombre simbólico asignado al compilador.

¿Cuál de las siguientes opciones es una desventaja del uso de timestamps?. No permiten identificar cambios de contenido. Requieren mucha memoria RAM. No se pueden usar en sistemas Unix. Obligan a eliminar archivos temporales.

¿Por qué los checksums facilitan la compilación paralela?. Porque no generan archivos temporales. Porque requieren que todo se compile en serie. Porque garantizan que cada archivo se evalúa por su contenido sin depender del orden. Porque solo se calculan una vez por proyecto.

La Integración Continua consiste en reconstruir el sistema frecuentemente, tal como proponen las metodologías ágiles. Verdadero. Falso.

Jenkins y GitHub Actions son herramientas utilizadas para automatizar procesos de CI. Verdadero. Falso.

La Integración Continua recomienda hacer un único build al final del proyecto. Verdadero. Falso.

En CI es común que las integraciones se hagan varias veces al día. Verdadero. Falso.

GitHub Actions solo funciona con repositorios privados. Verdadero. Falso.

¿Qué es Integración Continua?. Probar el sistema una vez al mes. Integrar cambios en el proyecto y reconstruirlo con frecuencia. Desplegar el software automáticamente en producción. Gestionar ramas con muchos desarrolladores.

¿Cuál de las siguientes herramientas se utiliza para CI?. Photoshop. Jenkins. Blender. Trello.

¿Cuál de estas afirmaciones describe un beneficio clave de la CI?. Reduce la necesidad de pruebas automatizadas. Retrasa la detección de errores para el final del proyecto. Detecta errores de integración de forma temprana. Obliga a tener un servidor local dedicado.

GitHub Actions se utiliza principalmente para: Crear interfaces gráficas. Automatizar flujos de CI/CD. Diseñar bases de datos. Comprimir archivos del repositorio.

¿Cuál es una práctica recomendada en CI?. Esperar a tener muchas tareas acumuladas antes de integrar. Integrar y construir frecuentemente, incluso varias veces al día. Compilar solo cuando se libera una nueva versión. Evitar automatizar el proceso de build.

La construcción diaria se utiliza habitualmente en sistemas muy grandes que requieren horas para compilarse. Verdadero. Falso.

En una construcción diaria, el sistema completo se compila automáticamente durante la noche. Verdadero. Falso.

Al día siguiente, el equipo obtiene una nueva versión del sistema gracias a la construcción diaria. Verdadero. Falso.

"Romper la construcción" significa que la compilación es lenta, pero aun así genera ejecutable. Verdadero. Falso.

Arreglar un "broken build" tiene prioridad máxima para el equipo. Verdadero. Falso.

¿Cuál es el propósito principal de la construcción diaria?. Compilar el sistema solo una vez por mes. Tener siempre una versión estable disponible por la mañana. Evitar que los desarrolladores trabajen en horario nocturno. Eliminar la necesidad de pruebas automatizadas.

¿Qué caracteriza a un "broken build"?. El sistema compila, pero no genera logs. El sistema no compila o fallan los tests. El sistema es demasiado grande para compilar. La compilación es más lenta de lo habitual.

¿Por qué se realiza la construcción diaria durante la noche?. Porque los servidores solo funcionan por la noche. Para aprovechar horas en las que nadie necesita el repositorio. Para evitar que los desarrolladores hagan commits. Para no interferir con la compilación paralela.

Una ventaja clave de la construcción diaria es: Permitir liberar software automáticamente todos los días. Reducir la duración total de la compilación. Proveer una versión fresca y global del sistema cada mañana. Eliminar la necesidad de integración continua.

Ante un "broken build", el equipo debe: Ignorarlo hasta la siguiente build. Priorizar arreglarlo de forma inmediata. Revertir todos los commits del día. Esperar a que el servidor se reinicie.

El ciclo de vida del cambio comienza cuando un cliente o desarrollador reporta un bug o una mejora. Verdadero. Falso.

El análisis de un cambio consiste en evaluar coste, impacto y validez. Verdadero. Falso.

La decisión sobre aprobar o rechazar un cambio la toma cualquier desarrollador del equipo. Verdadero. Falso.

La fase de acción incluye implementar el cambio y probarlo. Verdadero. Falso.

Si el CCB rechaza una petición, igualmente se implementa para mantener el flujo de trabajo. Verdadero. Falso.

¿Cuál es el primer paso del ciclo de vida del cambio?. Análisis. Acción. Petición. Decisión.

El objetivo principal de la fase de análisis es: Implementar la solución cuanto antes. Evaluar coste, impacto y validez del cambio. Generar documentación adicional. Reunir al CCB para la aprobación.

¿Quién aprueba o rechaza un cambio según el ciclo de vida del cambio?. El desarrollador más veterano. El Product Owner. El CCB (Comité de Control de Cambios). El cliente directamente.

La fase de acción consiste en: Evaluar coste e impacto. Implementar y probar el cambio aprobado. Recopilar nuevas peticiones. Negociar requisitos con el cliente.

¿Qué ocurre después del análisis del cambio?. Se implementa directamente. Se rechaza automáticamente. Se pasa a la fase de decisión del CCB. Se archiva sin revisar.

Una de las preguntas clave en el análisis de un cambio es evaluar las consecuencias de no implementarlo. Verdadero. Falso.

El análisis de un cambio debe considerar la relación entre beneficios y coste. Verdadero. Falso.

El número de usuarios afectados no es relevante durante el análisis del cambio. Verdadero. Falso.

El análisis del impacto en la arquitectura es un paso clave antes de aprobar un cambio. Verdadero. Falso.

Si un cambio aporta beneficios menores, debe aprobarse siempre sin considerar coste o impacto. Verdadero. Falso.

¿Cuál de las siguientes preguntas forma parte del análisis previo a aprobar un cambio?. ¿Cuántos commits hay en la rama principal?. ¿Este cambio permite eliminar documentación?. ¿Cuáles son las consecuencias de NO hacerlo?. ¿Cuántos desarrolladores participan en el proyecto?.

El análisis coste–beneficio ayuda principalmente a: Decidir qué desarrollador implementará el cambio. Determinar si el valor del cambio justifica su coste. Detectar errores en el código fuente. Medir la velocidad del servidor.

¿Por qué es importante evaluar cuántos usuarios se verán afectados?. Para decidir qué rama de Git usar. Para estimar el impacto global del cambio en la experiencia del usuario. Para determinar el tamaño del ejecutable. Para saber si se debe recompilar todo el sistema.

Evaluar el impacto en la arquitectura permite: Saber si el proyecto cambiará de lenguaje de programación. Determinar si el cambio afecta a módulos críticos del sistema. Reducir el número de builds nocturnas. Incrementar el número de commits por semana.

¿Qué factor NO pertenece al análisis del cambio?. Consecuencias de no hacerlo. Impacto en arquitectura. Usuarios afectados. Número de ramas activas en el repositorio.

Una release de software es más que solo el ejecutable (.exe). Verdadero. Falso.

Para que una release sea confiable, debe ser reproducible. Verdadero. Falso.

La documentación y los instaladores no forman parte de una release completa. Verdadero. Falso.

La configuración y los datos necesarios para ejecutar el software forman parte de la release. Verdadero. Falso.

El packaging se refiere a la manera de empaquetar todos los componentes de la release para distribución. Verdadero. Falso.

¿Qué elementos incluye típicamente una release de software?. Solo el ejecutable (.exe). Ejecutable, instaladores, configuración, datos y documentación. Únicamente el código fuente. Solo pruebas unitarias.

¿Por qué una release debe ser reproducible?. Para ahorrar espacio en disco. Para que cualquiera pueda generar la misma versión confiable. Para acelerar la compilación. Para eliminar la necesidad de pruebas.

El packaging en una release tiene como propósito: Guardar solo el ejecutable. Organizar y preparar todos los componentes para distribución. Crear copias de seguridad automáticas. Ejecutar pruebas unitarias.

¿Qué NO es un componente típico de una release de software?. Documentación. Instaladores. Código fuente no compilado para producción. Configuración y datos.

¿Cuál es la ventaja de incluir documentación en la release?. Reducir el tamaño del ejecutable. Facilitar la instalación, uso y soporte del software. Evitar recompilaciones. Acelerar la integración continua.

El versionado semántico (SemVer) usa tres números: MAJOR, MINOR y PATCH. Verdadero. Falso.

Un cambio en el número MAJOR indica cambios incompatibles con versiones anteriores. Verdadero. Falso.

Un cambio PATCH corresponde a correcciones de bugs compatibles con la versión existente. Verdadero. Falso.

Incrementar MINOR indica nuevas funcionalidades que rompen la compatibilidad. Verdadero. Falso.

Si la versión actual es 1.5.2, un cambio de bug corregido compatible resultaría en la versión 1.5.3. Verdadero. Falso.

¿Qué tipo de cambio requiere incrementar el número MAJOR?. Cambios menores de UI. Corrección de bugs sin romper compatibilidad. Cambios incompatibles que rompen la API. Documentación adicional.

¿Cuál sería la versión resultante si se agrega funcionalidad compatible a la versión 1.5.2?. 1.5.3. 1.6.0. 2.0.0. 1.5.2.1.

Un cambio de bug corregido en la versión 1.5.2 resultaría en: 1.5.1. 1.6.0. 1.5.3. 2.0.0.

¿Qué versión seguiría a 1.5.2 si se hiciera un cambio incompatible mayor?. 1.6.0. 1.5.3. 2.0.0. 1.5.2.1.

¿Cuál es el propósito principal del versionado semántico?. Evitar la creación de ramas nuevas en Git. Facilitar a los desarrolladores y usuarios la comprensión de compatibilidad y cambios. Reducir el tamaño del ejecutable. Automatizar la compilación.

En SaaS, el software se ejecuta completamente en la nube, sin necesidad de instalación en los equipos del cliente. Verdadero. Falso.

Las actualizaciones en SaaS se aplican de forma instantánea y global para todos los usuarios. Verdadero. Falso.

En SaaS, los clientes deben mantener varias versiones antiguas del software en sus máquinas. Verdadero. Falso.

SaaS simplifica la gestión del software en comparación con el modelo tradicional de instalación local. Verdadero. Falso.

En SaaS, cada usuario tiene que descargar e instalar manualmente cada actualización. Verdadero. Falso.

¿Cuál es una característica clave de SaaS?. Instalación local obligatoria. Actualizaciones globales instantáneas. Necesidad de múltiples versiones en el cliente. Requiere hardware dedicado para cada usuario.

¿Por qué se dice que SaaS representa un cambio de paradigma?. Porque obliga a usar solo sistemas Windows. Porque elimina la necesidad de instalación y centraliza la gestión. Porque requiere un servidor en cada oficina. Porque no permite actualizaciones automáticas.

Una ventaja de SaaS para los usuarios es: Tener que gestionar múltiples instalaciones. No preocuparse por versiones antiguas ni instalaciones locales. Depender de un hardware específico. Instalar actualizaciones manualmente.

¿Qué implicación tiene la actualización instantánea en SaaS?. Todos los usuarios tienen acceso inmediato a nuevas funciones y correcciones. Cada usuario debe descargar la actualización individualmente. Las versiones antiguas permanecen activas en los clientes. El software deja de funcionar temporalmente durante la actualización.

¿Cuál de las siguientes NO es una ventaja de SaaS?. Gestión simplificada. Acceso desde cualquier lugar. Instalaciones locales complejas. Actualizaciones automáticas y globales.

En un sistema de control de versiones distribuido como Git, cada desarrollador tiene una copia completa del repositorio, lo que permite trabajar offline. Verdadero. Falso.

La rama (branch) se utiliza únicamente para probar código experimental que nunca se integrará al principal. Verdadero. Falso.

¿Cuál de los siguientes NO es un componente típico de una release de software?. Ejecutable. Documentación. Instaladores. Repositorio de commits internos.

¿Qué representa un incremento en la versión MINOR según SemVer?. Corrección de bugs compatibles. Nueva funcionalidad compatible. Cambio incompatible que rompe la API. Cambio de documentación.

El build server ayuda a minimizar el problema del “en mi máquina funciona” al proporcionar un entorno limpio y controlado. Verdadero. Falso.

¿Cuál es la ventaja de utilizar checksums en lugar de timestamps para minimizar recompilaciones?. Permite recompilar todo el sistema más rápido. Detecta cambios reales en el contenido del archivo. Evita la necesidad de tests unitarios. Mejora la velocidad del servidor.

En SaaS, los usuarios siempre acceden a la versión más reciente, y no existen versiones antiguas instaladas en sus máquinas. Verdadero. Falso.

¿Cuál es el objetivo de la Integración Continua (CI)?. Esperar a que se complete el proyecto para compilar. Integrar y reconstruir el sistema frecuentemente para detectar errores temprano. Evitar la creación de ramas nuevas. Publicar automáticamente en producción sin pruebas.