¿Cuál de las siguientes es una actividad que se realiza durante la definición de requisitos en el desarrollo de sistemas?
Decidir la estructura interna de módulos y los procedimientos de procesamiento de los programas
Corregir las fallas que se producen después de la puesta en marcha del sistema y mejorar sus funciones
Estudiar las operaciones de negocio de los usuarios y aclarar las funciones y el rendimiento que debe ofrecer el sistema
Comprobar uno por uno cada programa terminado para confirmar que funciona según lo especificado en los documentos de diseño
RespuestaC. Estudiar las operaciones de negocio de los usuarios y aclarar las funciones y el rendimiento que debe ofrecer el sistema
La definición de requisitos (要件定義) es la primera fase del desarrollo: organiza las peticiones de los usuarios y aclara las funciones y el rendimiento que debe ofrecer el sistema. La opción A corresponde al diseño interno (内部設計), la opción D a la prueba unitaria (単体テスト) y la opción B al mantenimiento (保守); todas ellas son posteriores a la definición de requisitos.
Pregunta 2 | Diseño externo
¿Cuál de los siguientes es el elemento más adecuado que se decide en el diseño externo, también llamado diseño básico?
Los procedimientos para preparar los datos de prueba que se usarán en la prueba de integración
La denominación uniforme de variables y funciones conforme a las convenciones de codificación
Los procedimientos internos de procesamiento y los algoritmos de cada módulo
El diseño de las pantallas que manejan los usuarios y de los informes que se imprimen
RespuestaD. El diseño de las pantallas que manejan los usuarios y de los informes que se imprimen
El diseño externo (外部設計) es la fase en la que se deciden las partes visibles para los usuarios, como las pantallas, los informes (帳票) y el intercambio de datos, por lo que la opción D es la correcta. La opción C corresponde al diseño interno, la opción B a la programación y la opción A a la fase de pruebas; ninguna se decide en el diseño externo.
Pregunta 3 | Fases de diseño
¿Cuál de las siguientes explica adecuadamente la relación entre el diseño externo y el diseño interno?
Las especificaciones visibles para el usuario decididas en el diseño externo se convierten en estructuras de programa en el diseño interno
El diseño externo se realiza después de terminar el diseño interno, a partir de sus resultados
Tanto el diseño externo como el diseño interno son fases en las que se deciden los diseños de pantallas e informes que deben acordarse con los usuarios
El diseño externo lo dirigen principalmente los programadores, y el diseño interno, principalmente los usuarios
RespuestaA. Las especificaciones visibles para el usuario decididas en el diseño externo se convierten en estructuras de programa en el diseño interno
El desarrollo avanza del diseño externo (外部設計) al diseño interno (内部設計), y convierte las especificaciones visibles desde fuera en estructuras de módulos y procedimientos de procesamiento concretos. La opción B invierte el orden; la opción C es incorrecta porque el diseño interno no es una fase para decidir especificaciones orientadas al usuario; y la opción D invierte los responsables.
Pregunta 4 | Orden de las fases
¿Cuál de los siguientes es el orden adecuado en que se realizan las fases del desarrollo de sistemas?
Definición de requisitos, luego pruebas, luego diseño del sistema, luego programación
Diseño del sistema, luego definición de requisitos, luego pruebas, luego programación
Definición de requisitos, luego programación, luego diseño del sistema, luego pruebas
Definición de requisitos, luego diseño del sistema, luego programación, luego pruebas
RespuestaD. Definición de requisitos, luego diseño del sistema, luego programación, luego pruebas
El desarrollo avanza así: en la definición de requisitos (要件定義) se decide qué construir, en el diseño del sistema (システム設計) se decide cómo realizarlo, en la programación se construye y en las pruebas se verifica. En cada una de las otras tres opciones, el diseño o las pruebas aparecen antes de lo debido, lo que produce secuencias imposibles, como inspeccionar algo antes de construirlo.
Pregunta 5 | División en módulos
¿Cuál es el objetivo principal de diseñar un programa dividiéndolo en varios módulos?
Aumentar la independencia de cada componente para facilitar la modificación, las pruebas y la reutilización
Reducir el número de servidores usados en el entorno de producción y bajar los costos
Reducir el número de datos que deben introducir los usuarios y facilitar el manejo
Garantizar una reducción del número total de líneas de código fuente del programa
RespuestaA. Aumentar la independencia de cada componente para facilitar la modificación, las pruebas y la reutilización
La división en módulos (モジュール分割) convierte cada función en un componente muy independiente, lo que reduce el alcance del impacto de los cambios y facilita las pruebas y la reutilización. Dividir un programa no reduce necesariamente el número total de líneas, por lo que la opción D es incorrecta; la opción C trata del diseño de pantallas y la opción B de la configuración de la infraestructura, así que sus objetivos son distintos.
Pregunta 6 | Usabilidad
¿Cuál de los siguientes es el ejemplo más adecuado de diseño de pantalla que mejora la usabilidad?
Avisar en el momento de los errores de entrada y mostrar concretamente qué está mal y cómo corregirlo
Usar muchos términos técnicos para que solo los usuarios con conocimientos puedan manejar la pantalla
No mostrar instrucciones de uso en la pantalla y explicarlas solo en un manual aparte
Meter todos los campos de entrada en una sola pantalla sin mostrar ningún encabezado ni explicación complementaria
RespuestaA. Avisar en el momento de los errores de entrada y mostrar concretamente qué está mal y cómo corregirlo
La usabilidad (ユーザビリティ) es la facilidad con la que los usuarios pueden alcanzar sus objetivos de forma eficiente y sin perderse, y comunicar los errores de manera clara e inmediata la mejora. Las opciones B, D y C aumentan la carga de comprensión y manejo para los usuarios, por lo que reducen la facilidad de uso.
Pregunta 7 | Aceptación
¿Cuál de las siguientes describe adecuadamente la aceptación de software?
Mejorar el software después de su puesta en marcha, en respuesta a cambios en el negocio y a peticiones de los usuarios
Que los desarrolladores prueben los programas que escribieron, módulo por módulo o programa por programa
Que el cliente que hizo el encargo compruebe el software entregado mediante pruebas operativas y otros medios, y lo acepte si cumple los requisitos
Que los desarrolladores construyan la estructura interna y los procedimientos de procesamiento de los programas según los documentos de diseño
RespuestaC. Que el cliente que hizo el encargo compruebe el software entregado mediante pruebas operativas y otros medios, y lo acepte si cumple los requisitos
La aceptación de software (ソフトウェア受入れ) es la fase en la que el cliente que hizo el encargo confirma, mediante pruebas operativas (運用テスト) y comprobaciones similares, que los entregables cumplen los requisitos antes de recibirlos; también se llama inspección de recepción (検収). La opción B es la prueba unitaria, la opción D es la programación y la opción A es el mantenimiento; todas son fases distintas de la aceptación.
Pregunta 8 | Prueba unitaria
¿Cuál de las siguientes describe adecuadamente la prueba unitaria?
Hacer que los usuarios manejen el sistema siguiendo sus procedimientos de trabajo reales para verificar que cumple los requisitos
Verificar, para cada módulo o programa individual, que su procesamiento interno funciona correctamente
Verificar todo el sistema, incluidos el rendimiento y la resistencia a la carga, en un entorno cercano al de producción
Combinar varios módulos y verificar que los datos se transmiten correctamente entre ellos
RespuestaB. Verificar, para cada módulo o programa individual, que su procesamiento interno funciona correctamente
La prueba unitaria (単体テスト) es la primera etapa de las pruebas y se realiza módulo por módulo. La opción D describe la prueba de integración (結合テスト), la opción C la prueba de sistema (システムテスト) y la opción A la prueba operativa (運用テスト), que sirve como prueba de aceptación; todas se realizan en etapas posteriores a la prueba unitaria.
Pregunta 9 | Prueba de integración
¿Qué se verifica principalmente en la prueba de integración?
Si el intercambio de datos y la coordinación entre los módulos combinados son correctos
Si los usuarios pueden realizar su flujo de trabajo real sin problemas
Si se han ejecutado todas las instrucciones y ramificaciones dentro de un solo módulo
Si los costos de desarrollo se mantienen dentro del presupuesto inicial
RespuestaA. Si el intercambio de datos y la coordinación entre los módulos combinados son correctos
La prueba de integración (結合テスト) conecta los módulos que han superado la prueba unitaria y verifica que las interfaces, es decir, el intercambio de datos entre ellos, sean correctas. La opción C es la prueba de caja blanca (ホワイトボックステスト) que se hace durante la prueba unitaria, la opción B es el objetivo de la prueba operativa y la opción D trata de la gestión de costos del proyecto, no de pruebas.
Pregunta 10 | Prueba de sistema
¿Cuál de las siguientes es la descripción más adecuada de lo que se hace en la prueba de sistema, también llamada prueba general?
Verificar todo el sistema en un entorno cercano al de producción, comprobando, además de las funciones, el rendimiento y la resistencia a la carga
Corregir las irregularidades de sangría y formato del código fuente con un formateador automático
Añadir como funciones nuevas las características que piden los usuarios después de la entrega
Que los miembros lean juntos en papel, uno por uno, los módulos en desarrollo para encontrar errores en lo escrito (en el código)
RespuestaA. Verificar todo el sistema en un entorno cercano al de producción, comprobando, además de las funciones, el rendimiento y la resistencia a la carga
La prueba de sistema (システムテスト) es la última etapa de las pruebas que realiza el equipo de desarrollo, y confirma que todo el sistema funciona según lo requerido en cuanto a funciones, rendimiento, carga, etc. La opción D es trabajo de revisión o de prueba unitaria, la opción B es trabajo de codificación y la opción C es la adición de funciones durante el mantenimiento; ninguna corresponde.
Pregunta 11 | Prueba operativa
¿Cuál de las siguientes describe adecuadamente la prueba operativa, también llamada prueba de aceptación?
Que los desarrolladores lean los programas en papel y señalen los errores
Que los desarrolladores se centren en la estructura interna de los programas y comprueben exhaustivamente instrucciones y ramificaciones
Que los desarrolladores verifiquen la coordinación entre los módulos integrados
Que los usuarios manejen el sistema siguiendo su flujo de trabajo real para verificar que cumple los requisitos
RespuestaD. Que los usuarios manejen el sistema siguiendo su flujo de trabajo real para verificar que cumple los requisitos
La prueba operativa (運用テスト) es la prueba final que dirigen los usuarios, es decir, el cliente que hizo el encargo (発注者), para confirmar que el sistema puede usarse en los procedimientos de trabajo reales. La opción B es la prueba de caja blanca, la opción C es la prueba de integración y la opción A es la revisión de código; todas son actividades que realizan los desarrolladores, por lo que difieren tanto el responsable como el objetivo.
Pregunta 12 | Modelo en V
En el modelo en V, ¿qué fase de pruebas corresponde al diseño externo, también llamado diseño básico?
Prueba unitaria
Prueba de integración
Prueba de sistema
Prueba operativa
RespuestaC. Prueba de sistema
En el modelo en V (V字モデル), la definición de requisitos se empareja con la prueba operativa, el diseño externo con la prueba de sistema (システムテスト), el diseño interno con la prueba de integración y la programación con la prueba unitaria. Por lo tanto, la fase que corresponde al diseño externo es la prueba de sistema; la prueba unitaria corresponde a la programación, la prueba de integración al diseño interno y la prueba operativa a la definición de requisitos.
Pregunta 13 | Caja blanca
¿Cuál de las siguientes describe adecuadamente la prueba de caja blanca?
Introducir el mismo volumen de datos que en producción y medir si el tiempo de procesamiento se mantiene dentro del estándar
Una prueba que ignora la estructura interna del programa y se centra solo en la relación entre entradas y salidas indicada en las especificaciones
Una prueba que se centra en la estructura interna del programa y cubre las rutas de ejecución para que se ejecuten las instrucciones y ramificaciones
Hacer que los usuarios manejen un prototipo e incorporar sus opiniones a los requisitos
RespuestaC. Una prueba que se centra en la estructura interna del programa y cubre las rutas de ejecución para que se ejecuten las instrucciones y ramificaciones
La prueba de caja blanca (ホワイトボックステスト) examina el interior del programa, su estructura de control, y diseña casos de prueba que cubran las instrucciones y ramificaciones; se usa principalmente en la prueba unitaria. La opción B describe la prueba de caja negra (ブラックボックステスト), la opción D el prototipado y la opción A la prueba de rendimiento.
Pregunta 14 | Caja negra
¿Cuál de las siguientes es una forma adecuada de crear casos de prueba en la prueba de caja negra?
Asignar mecánicamente un número de casos de prueba proporcional al número de líneas de código fuente
Elegir las rutas de ejecución de modo que cada ramificación se ejecute al menos una vez
Comprobar línea por línea si los comentarios escritos por los desarrolladores son correctos
Dividir las condiciones de entrada de las especificaciones en grupos con sentido y elegir de ellos valores representativos y valores límite
RespuestaD. Dividir las condiciones de entrada de las especificaciones en grupos con sentido y elegir de ellos valores representativos y valores límite
La prueba de caja negra (ブラックボックステスト) se basa en las especificaciones sin mirar la estructura interna, y elige valores representativos y valores límite de las entradas mediante la partición de equivalencia (同値分割) y el análisis de valores límite (境界値分析). La opción B es la prueba de caja blanca, que se centra en la estructura interna; en la opción A, el número de líneas no es base para los casos de prueba; y la opción C es trabajo de revisión de código.
Pregunta 15 | Prueba de regresión
¿Cuál es el propósito de realizar una prueba de regresión?
Confirmar que la modificación del programa no ha introducido defectos en partes que funcionaban correctamente antes de la modificación
Confirmar que los usuarios capacitados han aprendido correctamente los nuevos procedimientos de manejo después del cambio
Confirmar que el sistema tiene suficiente rendimiento de procesamiento para soportar el uso en producción
Comprobar solo la parte recién añadida, verificando únicamente si la función añadida funciona según lo especificado
RespuestaA. Confirmar que la modificación del programa no ha introducido defectos en partes que funcionaban correctamente antes de la modificación
La prueba de regresión (回帰テスト) verifica que las funciones existentes que antes funcionaban correctamente no se hayan estropeado por modificaciones o por funciones añadidas. La opción D es la prueba de la propia función añadida, la opción C es la prueba de rendimiento y la opción B es la verificación de la formación y capacitación; ninguna es el propósito de la prueba de regresión.
Pregunta 16 | Técnicas de revisión
Entre las técnicas de revisión de software, ¿cuál de las siguientes describe adecuadamente una inspección?
Una revisión formal dirigida por un moderador, con los roles y procedimientos de los participantes definidos de antemano, para detectar defectos en los entregables
Ejecutar realmente el programa para verificar que las salidas para determinadas entradas coinciden con las especificaciones
Dos personas que comparten un terminal y se turnan para escribir el programa
Una sesión dirigida por el autor, que recorre el entregable en orden con los participantes mientras estos señalan de manera informal, en el momento, errores y dudas
RespuestaA. Una revisión formal dirigida por un moderador, con los roles y procedimientos de los participantes definidos de antemano, para detectar defectos en los entregables
Una inspección (インスペクション) es una revisión formal dirigida por un moderador (モデレータ), con roles y procedimientos definidos y con registro de resultados. La opción D es un recorrido de revisión o walkthrough (ウォークスルー), que es informal; la opción B es una prueba en la que se ejecuta realmente el programa; y la opción C es la programación en pareja de XP; ninguna es una inspección.
Pregunta 17 | Modelo en cascada
¿Cuál de las siguientes es una característica adecuada del modelo en cascada?
Construir prototipos y concretar los requisitos mientras se reciben las evaluaciones de los usuarios
Avanzar por las fases en orden y, por regla general, desarrollar sin volver a fases anteriores
Repetir iteraciones cortas y entregar software que funciona en cada iteración
Que el personal de desarrollo y el de operaciones trabajen como uno solo y publiquen versiones con frecuencia mediante la automatización
RespuestaB. Avanzar por las fases en orden y, por regla general, desarrollar sin volver a fases anteriores
El modelo en cascada (ウォーターフォールモデル) avanza por las fases en orden, de las primeras etapas a las últimas, y aprueba los entregables de cada fase partiendo de la premisa de no volver a fases anteriores. La opción C describe el desarrollo ágil (アジャイル開発), la opción A el modelo de prototipado (プロトタイピングモデル) y la opción D DevOps; cada una es un enfoque distinto.
Pregunta 18 | Prototipado
¿Cuál es la principal ventaja de adoptar el modelo de prototipado?
El prototipo sustituye a los documentos de diseño, por lo que no hace falta ningún trabajo de documentación
Hacer que los usuarios revisen un prototipo en una etapa temprana reduce el retrabajo causado por desajustes y malentendidos en los requisitos
Como los usuarios han revisado el prototipo, se puede garantizar que no habrá cambios de especificaciones después de la puesta en marcha del sistema
Construir un prototipo siempre reduce el esfuerzo total de desarrollo y recorta los costos a la mitad
RespuestaB. Hacer que los usuarios revisen un prototipo en una etapa temprana reduce el retrabajo causado por desajustes y malentendidos en los requisitos
El prototipado (プロトタイピング) es una técnica que evita un gran retrabajo (手戻り) causado por requisitos mal entendidos, al hacer que los usuarios evalúen pronto un prototipo. Aun con un prototipo siguen siendo necesarios los documentos de diseño, por lo que la opción A es incorrecta; no hay garantía de que el esfuerzo se reduzca siempre a la mitad ni de que nunca haya cambios, así que las opciones D y C también son incorrectas.
Pregunta 19 | Modelo en espiral
¿Cuál de las siguientes describe adecuadamente el modelo en espiral?
Completar todas las funciones en una sola pasada de las primeras a las últimas fases, sin volver a fases anteriores ni hacer revisiones intermedias
Omitir la fase de definición de requisitos, construir primero algo que funcione y documentar después las especificaciones
Externalizar todas las fases de desarrollo y controlar el avance solo mediante informes mensuales
Dividir el sistema en partes y aumentar su grado de completitud en espiral repitiendo un ciclo de diseño, desarrollo y evaluación
RespuestaD. Dividir el sistema en partes y aumentar su grado de completitud en espiral repitiendo un ciclo de diseño, desarrollo y evaluación
El modelo en espiral (スパイラルモデル) divide el sistema en partes y repite un ciclo que va del diseño a la evaluación, reduciendo los riesgos mientras aumenta el grado de completitud. La opción A responde a la lógica del modelo en cascada, y las opciones B y C no tienen relación con la definición del modelo en espiral.
Pregunta 20 | Ágil
¿Cuál de las siguientes es la descripción más adecuada del enfoque de desarrollo ágil?
Los usuarios participan solo en la definición de requisitos y en la aceptación, sin intervenir durante el desarrollo
Fijar todas las especificaciones al principio y, por regla general, no permitir cambios posteriores
Construir software que funciona en iteraciones cortas y responder a los cambios incorporando las opiniones de los usuarios
Dar prioridad a documentos de diseño detallado perfectamente pulidos antes que a mostrar pronto software que funciona
RespuestaC. Construir software que funciona en iteraciones cortas y responder a los cambios incorporando las opiniones de los usuarios
El desarrollo ágil (アジャイル開発) repite iteraciones cortas y valora el software que funciona y la capacidad de respuesta al cambio, colaborando con los usuarios. Las opciones B, D y A son características del desarrollo en cascada y se oponen al enfoque ágil.
Pregunta 21 | Elección del modelo
Los requisitos aún no están definidos y se prevé añadir funciones en ciclos cortos mientras se observa la reacción de los usuarios. ¿Cuál de las siguientes es la política de desarrollo más adecuada para este sistema?
Ejecutar todas las pruebas juntas al final y no verificar el funcionamiento hasta entonces
No empezar el desarrollo hasta que se apruebe el documento de requisitos y no aceptar ningún cambio después de la aprobación
Publicar funciones que funcionan en cada iteración corta y reflejar las evaluaciones de los usuarios en la siguiente iteración
Fijar las especificaciones de todas las funciones, desarrollarlo todo de una vez y mostrarlo a los usuarios solo al terminar
RespuestaC. Publicar funciones que funcionan en cada iteración corta y reflejar las evaluaciones de los usuarios en la siguiente iteración
En los proyectos cuyos requisitos cambian con facilidad, es adecuado un estilo ágil (アジャイル型) que entrega algo que funciona en cada iteración e incorpora las evaluaciones. Las opciones D y B son de estilo en cascada y responden mal a los cambios, y la opción A retrasa el descubrimiento de defectos y aumenta el retrabajo, así que ninguna se ajusta a esta situación.
Pregunta 22 | RAD
¿Cuál de las siguientes describe adecuadamente el RAD (Rapid Application Development, desarrollo rápido de aplicaciones)?
Un enfoque en el que el personal de desarrollo y el de operaciones cooperan estrechamente y buscan la mejora continua mediante la automatización
Una técnica para desarrollar un sistema en poco tiempo usando un equipo pequeño y herramientas de apoyo al desarrollo
Una técnica para crear un servicio nuevo combinando varios servicios disponibles públicamente
Una técnica para analizar programas existentes y obtener sus especificaciones e información de diseño
RespuestaB. Una técnica para desarrollar un sistema en poco tiempo usando un equipo pequeño y herramientas de apoyo al desarrollo
El RAD es una técnica que acorta el periodo de desarrollo usando un equipo pequeño y herramientas de apoyo al desarrollo. La opción D describe la ingeniería inversa (リバースエンジニアリング), la opción A DevOps y la opción C un mashup (マッシュアップ); cada una es un término distinto del RAD.
Pregunta 23 | Programación en pareja
¿Cuál de las siguientes describe adecuadamente la programación en pareja?
Dos equipos desarrollan por separado la misma función y, al terminar, se adopta el mejor resultado
Dos personas comparten un terminal; una escribe el código mientras la otra lo revisa y aconseja durante el desarrollo
Hacer que dos usuarios manejen la misma pantalla y comparar la facilidad de uso
Ejecutar dos tipos de pruebas al mismo tiempo para encontrar antes los defectos
RespuestaB. Dos personas comparten un terminal; una escribe el código mientras la otra lo revisa y aconseja durante el desarrollo
La programación en pareja (ペアプログラミング) es una práctica representativa de XP en la que dos personas escriben un mismo código, elevando la calidad mediante la revisión en el momento. La opción A es una forma competitiva de desarrollar, la opción D es una forma de realizar pruebas y la opción C es una evaluación de usabilidad; ninguna corresponde.
Pregunta 24 | TDD
¿Cuál de las siguientes es la forma adecuada de proceder en el desarrollo guiado por pruebas (TDD)?
Escribir primero el código de prueba y luego implementar el programa de modo que pase las pruebas
Planificar las pruebas por primera vez solo después de terminar toda la implementación
Dejar las pruebas por completo en manos de especialistas externos, sin que los desarrolladores hagan ninguna prueba
Crear pruebas por primera vez solo cuando los usuarios informan de fallas después de la puesta en producción
RespuestaA. Escribir primero el código de prueba y luego implementar el programa de modo que pase las pruebas
El desarrollo guiado por pruebas (テスト駆動開発) escribe primero las pruebas, implementa lo mínimo necesario para pasarlas y repite la mejora. En las opciones B, C y D, las pruebas llegan después de la implementación o de la puesta en marcha, lo que contradice la idea del TDD de que las pruebas guían el desarrollo.
Pregunta 25 | Refactorización
¿Cuál de las siguientes describe adecuadamente la refactorización?
Reorganizar la estructura interna de un programa para hacerla más clara sin cambiar su comportamiento visible desde fuera
Trasladar un sistema en funcionamiento a otro centro de datos
Añadir funciones nuevas a un programa existente en respuesta a peticiones de los usuarios
Aumentar el número de servidores o la cantidad de memoria para mejorar la velocidad de procesamiento
RespuestaA. Reorganizar la estructura interna de un programa para hacerla más clara sin cambiar su comportamiento visible desde fuera
La refactorización (リファクタリング) es el trabajo de ordenar la estructura interna del código conservando su comportamiento visible desde fuera, para facilitar modificaciones posteriores. La opción C es la adición de funciones, la opción D es el refuerzo del hardware y la opción B es el traslado de instalaciones; ninguna es una mejora de la estructura interna.
Pregunta 26 | Propietario del producto
¿Cuál es el rol del propietario del producto (product owner) en Scrum?
Ser responsable del contenido y la prioridad del backlog del producto y maximizar el valor del producto
Evaluar el desempeño de los miembros del equipo y asignar tareas a cada persona
Registrar el avance diario e informar a la dirección de los sobrecostos del presupuesto
Ayudar a que las reglas de Scrum se sigan correctamente y eliminar los problemas que dificultan el desarrollo
RespuestaA. Ser responsable del contenido y la prioridad del backlog del producto y maximizar el valor del producto
El propietario del producto (プロダクトオーナー) es el rol responsable de priorizar «qué construir». La opción D es el rol del Scrum Master (スクラムマスター); la opción B no está definida en Scrum, donde el equipo de desarrollo decide por sí mismo el reparto del trabajo; y la opción C tampoco es un rol definido.
Pregunta 27 | Scrum Master
¿Cuál de las siguientes describe adecuadamente el rol del Scrum Master en Scrum?
Ayudar al equipo a practicar Scrum correctamente y eliminar los problemas que lo obstaculizan
Negociar precios con los clientes y decidir las condiciones del contrato
Dar órdenes de trabajo a cada miembro del equipo de desarrollo y controlarlos reprendiendo a quienes se retrasan
Decidir la prioridad de los requisitos y definir las funciones que se publicarán
RespuestaA. Ayudar al equipo a practicar Scrum correctamente y eliminar los problemas que lo obstaculizan
El Scrum Master (スクラムマスター) apoya al equipo para que practique Scrum y elimina los impedimentos. El mando y control como en la opción C no forma parte del rol, la opción B es tarea de ventas o de administración y la opción D es el rol del propietario del producto; ninguna es función del Scrum Master.
Pregunta 28 | Términos de Scrum
¿Cuál de las siguientes describe adecuadamente el daily scrum (scrum diario) en Scrum?
El equipo de desarrollo se reúne brevemente cada día para compartir el avance y los problemas y confirmar el trabajo del día
Al final de un sprint, los entregables terminados en ese sprint se muestran a las partes interesadas para su evaluación y comentarios
Los requisitos que deben realizarse se organizan en una lista priorizada
El equipo reflexiona sobre su forma de trabajar y decide mejoras para el futuro
RespuestaA. El equipo de desarrollo se reúne brevemente cada día para compartir el avance y los problemas y confirmar el trabajo del día
El daily scrum (デイリースクラム) es una reunión breve de unos 15 minutos que se celebra cada día, con el objetivo de compartir el avance y detectar pronto los impedimentos. La opción B describe la revisión del sprint (スプリントレビュー), la opción C el backlog del producto (プロダクトバックログ) y la opción D la retrospectiva del sprint (スプリントレトロスペクティブ); su momento y su propósito son distintos.
Pregunta 29 | CI/CD
¿Cuál de las siguientes describe adecuadamente CI/CD, la integración continua y la entrega continua?
Que el personal de operaciones copie manualmente los archivos al entorno de producción y aplique los cambios uno por uno
Fusionar todos los cambios de una sola vez justo antes de la publicación y ejecutar todas las pruebas juntas, una sola vez, solo en ese momento
Suspender el desarrollo nuevo y dedicarse solo a mantener la documentación de los sistemas existentes
Integrar con frecuencia el código fuente modificado, ejecutar automáticamente la compilación y las pruebas, y automatizar el flujo hasta la publicación
RespuestaD. Integrar con frecuencia el código fuente modificado, ejecutar automáticamente la compilación y las pruebas, y automatizar el flujo hasta la publicación
CI/CD es una práctica que integra con frecuencia cambios pequeños y automatiza la compilación, las pruebas y la publicación, lo que eleva la calidad y la velocidad de entrega. La opción B es la integración tradicional de una sola vez (一括結合), que retrasa el descubrimiento de problemas; la opción A no está automatizada; y la opción C detiene por completo la actividad de desarrollo, así que todas son incorrectas.
Pregunta 30 | Ingeniería inversa
¿Cuál de las siguientes corresponde a la ingeniería inversa?
Usar un entorno de desarrollo que permite crear aplicaciones con solo colocar componentes en la pantalla
Crear un programa a partir de los documentos de diseño
Crear un servicio nuevo combinando varios servicios disponibles públicamente
Analizar un programa existente para obtener sus especificaciones e información de diseño
RespuestaD. Analizar un programa existente para obtener sus especificaciones e información de diseño
La ingeniería inversa (リバースエンジニアリング) consiste en analizar software existente para extraer sus especificaciones e información de diseño. La opción B es el desarrollo ordinario hacia delante (順方向), del diseño a la implementación; la opción C es un mashup; y la opción A describe el desarrollo sin código (no-code) o de bajo código (low-code).
Práctica: responda las preguntas de esta página
Es una herramienta de práctica con preguntas en orden aleatorio (funciona si JavaScript está activado). Aun sin ella, puede leer todas las preguntas y explicaciones de arriba.
* Las explicaciones son información con fines de estudio. El contenido y el sistema de los exámenes cambian cada año, así que consulta siempre los anuncios oficiales de la entidad organizadora.
Esta página es una traducción del texto original en japonés. Si hay diferencias entre la traducción y el original, prevalece la versión en japonés. Esta traducción se ha hecho con IA y puede contener errores.Informar de un error de traducciónVer el original en japonés