Desarrollo Ágil Tema 2

Debido a las metodologías ágiles las metodologías clásicas están en desuso. Verdadero. Falso.

Las metodologías ágiles son más comunes que las metodologías clásicas. Verdadero. Falso.

Las metodologías clásicas son más comunes que las metodologías ágiles. Verdadero. Falso.

Extreme Programming (XP) es una metodología en cascada para el desarrollo de software. Verdadero. Falso.

Extreme Programming (XP) es una metodología ágil para el desarrollo de software. Verdadero. Falso.

Extreme Programming (XP) es una metodología clásica para el desarrollo de software. Verdadero. Falso.

Extreme Programming se sustenta principalmente en ______ valores. 3. 4. 5. 6. 7.

Extreme Programming se sustenta sobre 5 reglas. Verdadero. Falso.

Extreme Programming se sustenta sobre 5 valores. Verdadero. Falso.

Cuáles de las siguientes características NO es uno de los valores de Extreme Programming. Valentía. Comunicación. Respeto. Enfoque. Retroalimentación.

Cuáles de los siguientes características SI es uno de los valores de Extreme Programming. Transparencia. Inspección. Simplicidad. Apertura. Enfoque.

¿Qué es KISS en Extreme Programming?. Simplicidad. Respeto. Retroalimentación. Ninguna es correcta.

¿A qué valor de Extreme Programming corresponde la siguiente "descripción"? No me anclo, pero todo lo que hago es con cabeza. Valentía. Comunicación. Retroalimentación. Respeto. Simplicidad.

¿A qué valor de Extreme Programming corresponde la siguiente "descripción"? Es fundamental entre el equipo y el cliente, ya que ambos deben participar en la creación del proyecto. Valentía. Comunicación. Retroalimentación. Respeto. Simplicidad.

¿A qué valor de Extreme Programming corresponde la siguiente "descripción"? De cada parte que hago recibo feedback de los juicios de todos mis compañeros. Valentía. Comunicación. Retroalimentación. Respeto. Simplicidad.

¿A qué valor de Extreme Programming corresponde la siguiente "descripción"? Trabaja lo menos posibles obteniendo siempre lo máximo. Valentía. Comunicación. Retroalimentación. Respeto. Simplicidad.

En Extreme Programming la unidad de medida es. Las HU. El tiempo. Las iteraciones. Las entregas.

En la metodología de trabajo de Extreme Programming se debe llevar un desarrollo variable pero con un ritmo sostenible. Verdadero. Falso.

En la metodología de trabajo de Extreme Programming se debe llevar un desarrollo iterativo pero con un ritmo sostenible. Verdadero. Falso.

En Extreme Programming no existen las Historias de Usuario. Verdadero. Falso.

En Extreme Programming la planificación es trimestral. Verdadero. Falso.

En Extreme Programming se permiten los reajustes y cambios trimestralmente. Verdadero. Falso.

En Extreme Programming se práctica el ajuste continuo. Verdadero. Falso.

En Extreme Programming la planificación es trimestral pero se aplica el ajuste continuo. Verdadero. Falso.

En Extreme Programming se puede reajustar la planificación fuera del plazo trimestral. Verdadero. Falso.

Las iteraciones en Extreme Programming son. Mensuales. Semanales. Trimestrales. Variables.

En Extreme Programming existen 3 roles fundamentales en el equipo de desarrollo: desarrolladores, Product Owner, y supervisor. Verdadero. Falso.

En Extreme Programming existen 3 roles fundamentales en el equipo de desarrollo: Desarrolladores, Product Owner, y supervisor. Desarrolladores, investigador, y supervisor. Desarrolladores, Product Owner, e investigador. No existen roles en Extreme Programming.

¿Qué son los SLACKS?. Tiempo de la jornada en la que en vez de programar se aprende algo nuevo. Tiempo sobrante que suele darse al finalizar una iteración antes de tiempo. Iteraciones que excepcionalmente duran más que la media por lo que debe reajustarse la planificación. Divisiones de tiempo dentro de las iteraciones semanales en los que los desarrolladores ponen en común su trabajo.

¿Cuál es el tiempo que suele dedicarse a los SLACKS?. Menos del 20% de la jornada laboral. El 10% de cada iteración. 1h por cada 10 trabajadas. Mínimo 15 minutos al día.

Comunicación Osmótica en Extreme Programming, ¿qué es?. El equipo trabaja en un espacio compartido por lo que todas las dudas y resoluciones también son compartidas en el momento en el que se hacen. El equipo debe ponerse en contacto cada hora durante 10 minutos para exponer las dudas o eventos relevantes encontrados de modo que todos están al tanto de todo.

¿Qué día no puede ser nuca la reunión semanal de Extreme Programming?. Lunes. Martes. Miércoles. Jueves. Viernes.

¿Por qué la reunión semanal de Extreme Programming no puede ser un lunes?. Porque los trabajadores no descansan el finde se semana. Porque suele el ser el día con más bajas laborales. Porque los trabajadores no tienen "fresco" el trabajo que hicieron el viernes anterior. Porque los empleados deben preparase cierto información que no pueden hacer antes de la reunión.

En la reunión trimestral de Extreme Programming no se planifica. Verdadero. Falso.

En la reunión trimestral de Extreme Programming se planifica las HU de esa semana pero no se altera el plan trimestral. Verdadero. Falso.

En la reunión trimestral de Extreme Programming se puede modificar el plan trimestral. Verdadero. Falso.

En Extreme Programming se añaden HU de usuario cada 3 meses no en cada iteración. Verdadero. Falso.

En la reunión semanal de Extreme Programming se habla de lo que se ha hecho, de lo que se va a hacer y se planifica. Verdadero. Falso.

El ajuste continuo del plan trimestral se realiza en la reunión semanal. Verdadero. Falso.

El ajuste continuo del plan trimestral se realiza todos los lunes. Verdadero. Falso.

El ajuste continuo del plan trimestral se realiza en la extreme reunión. Verdadero. Falso.

En las reuniones semanales de Extreme Programming debe participar el cliente. Verdadero. Falso.

En Extreme Programming el cliente colabora con la creación de la Historias de Usuario. Verdadero. Falso.

Extreme Programming no fomenta el programar en parejas. Verdadero. Falso.

Programar en parejas solo sirve para intercambiar conocimientos entre 2 programadores. Verdadero. Falso.

Es beneficioso que más de una persona conozcan el código. Verdadero. Falso.

Programar en pareja empeora la calidad del código, ya que ralentiza el desarrollo. Verdadero. Falso.

Programar en parejas ralentiza el desarrollo al principio. Verdadero. Falso.

Un código programado en parejas tiende a ser de mayor calidad. Verdadero. Falso.

Programar en parejas consiste en dos personas con su respectivo ordenador desarrollando el mismo código a la vez y comunicándose y ayudándose en el proceso. Verdadero. Falso.

Programar en parejas consiste en dos personas con un único ordenado. Verdadero. Falso.

Compilar y ejecutar un programa no debe tardar más de: 5 minutos. 10 minutos. 15 minutos. 12 minutos.

Los Spikes están incluidos en la "tabla" de las historias de usuario. Verdadero. Falso.

El TDD es como. Un ciclo. Una secuencia de pasos. Una reglas a seguir. Un triángulo.

En el TDD lo que primero se escribe es: El test. El código.

¿Cuál es el orden a seguir en el TDD?. Primero. Segundo. Tercero.

El primer TDD sobre el código siempre debería fallar. Verdadero. Falso.

En TDD reescribimos el código cuando el test falla. Verdadero. Falso.

El primer TDD sobre el código siempre debería funcionar. Verdadero. Falso.

El objetivo del TDD es probar el código. Verdadero. Falso.

El objetivo del TDD es programar el código para que no pase las pruebas. Verdadero. Falso.

En TDD solo se puede escribir código si es para corregir un test que falla. Verdadero. Falso.

En el TDD tengo que redactar los test de cara a que el código los pase. Verdadero. Falso.

En el TDD tengo que redactar los test de cara a que el código los fallé. Verdadero. Falso.

Gracias al TDD obtener códigos con todas las necesidades cubiertas. Verdadero. Falso.

No podemos evitar que el TDD sea infinito, simplemente paramos de hacer pruebas. Verdadero. Falso.

Para que el TDD no sea infinito. Utilizamos pruebas de caja negra. Marcamos un límite de test por código. Paramos cuando el código pase todos los test. Utilizamos pruebas de caja blanca.

Si necesito un número del rango 0 y 100, ¿con qué número implemento las pruebas de caja negra de particiones de equivalencia?. -1/ 10 / 200. 10 / 25 / 50 /75 / 90. 0 / 50 / 100. 0 / 100.

Las pruebas TDD se hacen con los valores límite. Verdadero. Falso.

Las pruebas TDD se pueden hacer con cualquier valor pero no es recomendable. Verdadero. Falso.

Existen 2 tipos de pruebas TDD. De unidad e integración. De comprobación y corrección.

Prueba de calidad dentro de una función o mi código único. Prueba de unidad. Prueba de integración.

Prueba de la relación entre 2 clases. Prueba de unidad. Prueba de integración.

Los objetivos del TDD son 4. Verdadero. Falso.

¿Cuál de los siguientes no es un objetivo del TDD?. Favorecer diseños buenos y simples. Eliminar fallos por suposiciones erróneas. Producir código que pueda ser probado. Asegurar un código libre de fallos.

¿Cuál de los siguientes si es un objetivo del TDD?. Evitar problemas de un código con baja calidad. Soporta el desarrollo evolutivo. Proporciona evidencias concretas de que el software funciona. Proporciona un código más limpio y simple.

En el ciclo TDD la palabra correspondiente a la parte de escribir pruebas corresponde con: Rojo. Verde. Refactor.

En el ciclo TDD la palabra correspondiente a la parte de escribir el código de para que la prueba funcione corresponde con: Rojo. Verde. Refactor.

En el ciclo TDD la palabra correspondiente a la parte de simplificar el código corresponde con: Rojo. Verde. Refactor.

Las pruebas de caja blanca son apropiadas para hacer TDD. Verdadero. Falso.

Las pruebas de caja negra son apropiadas para hacer TDD. Verdadero. Falso.

En análisis minucioso del código corresponde con. Las pruebas de caja blanca. Las pruebas de caja negra.

Suelen ser más difíciles. Las pruebas de caja blanca. Las pruebas de caja negra.

Suelen ser más costosas. Las pruebas de caja blanca. Las pruebas de caja negra.

Analizan los requerimientos funcionales (qué resultado espero, sin importar como esté programado). Las pruebas de caja blanca. Las pruebas de caja negra.

Detecta errores como: funciones incorrectas o ausentes y estructura de datos. Las pruebas de caja blanca. Las pruebas de caja negra.

Diferencia entre OBJETIVOS y BENEFICIOS del TDD. Objetivos. Beneficios.

Diferencia entre OBJETIVOS y BENEFICIOS del TDD. Objetivos. Beneficios.

En las particiones de equivalencia de las pruebas de caja negra, sobre un valor concreto obtengo. 3 clases de equivalencia. 1 clases de equivalencia. 2 clases de equivalencia.

En las particiones de equivalencia de las pruebas de caja negra, sobre un valor de un rango obtengo. 3 clases de equivalencia. 1 clases de equivalencia. 2 clases de equivalencia.

En las particiones de equivalencia de las pruebas de caja negra, sobre un valor dentro de un conjunto obtengo. 3 clases de equivalencia. 1 clases de equivalencia. 2 clases de equivalencia.

En las particiones de equivalencia de las pruebas de caja negra, sobre un valor booleano obtengo. 3 clases de equivalencia. 1 clases de equivalencia. 2 clases de equivalencia.

En las particiones de equivalencia de las pruebas de caja negra, ¿qué clases obtengo?. Sobre un valor en un rango entre 0 y 99. Sobre un valor concreto, 50.

Para probar valores límite con las pruebas de caja negra probamos con. min-1, min, min+1, max-1, max, max+1. min-1, min+1, max-1, max+1. min-1, min, max, max+1. min, min+1, max-1, max.

¿Cuánto casos serías adecuados para probar siguiendo las pruebas de caja negra de particiones de equivalencia? Tenemos 2 variables: a y b Posibles casos por variable: valor negativo, valor positivo y 0 <head> <script> function suma(a,b) { return a+b } </script> </head>. 9. 20. 6. 8. 12.

Probablemente, al ir mejorando el diseño de nuestro código, podemos hacer menos número de casos de prueba. Verdadero. Falso.

Probablemente, al ir mejorando el diseño de nuestro código, podemos hacer más número de casos de prueba. Verdadero. Falso.

La función envio_gratis devuelve true cuando el importe de la compra es igual o superior al importe mínimo; false en otro caso. ¿Qué valores deberían probarse según los método de partición de equivalencia? function envio_gratis( importe_compra , minimo_envio_gratis) { return importe_compra>=minimo_envio_gratis }. minimo_envio_gratis: <0, =0, >0 importe_compra: <minimo_envio_gratis, =minimo_envio_gratis, >minimo_envio_gratis. minimo_envio_gratis: <importe_compra , =importe_compra, >importe_compra importe_compra: <minimo_envio_gratis, =minimo_envio_gratis, >minimo_envio_gratis. minimo_envio_gratis: -1, 0, 1 importe_compra: minimo_envio_gratis -1 , minimo_envio_gratis, > minimo_envio_gratis. minimo_envio_gratis: <importe_compra , =importe_compra, >importe_compra importe_compra: <0, =0, >0.

La función envio_gratis devuelve true cuando el importe de la compra es igual o superior al importe mínimo; false en otro caso. ¿Qué valores deberían probarse según los método de valores límites para dicha función? function envio_gratis( importe_compra , minimo_envio_gratis) { return importe_compra>=minimo_envio_gratis }. minimo_envio_gratis: importe_compra -1 , importe_compra, > importe_compra importe_compra: -1, 0, 1. minimo_envio_gratis: -1, 0, 1 importe_compra: minimo_envio_gratis -1 , minimo_envio_gratis, > minimo_envio_gratis. minimo_envio_gratis: <0, =0, >0 importe_compra: <minimo_envio_gratis, =minimo_envio_gratis, >minimo_envio_gratis. minimo_envio_gratis: <importe_compra , =importe_compra, >importe_compra importe_compra: <0, =0, >0.

La función envio_gratis devuelve true cuando el importe de la compra es igual o superior al importe mínimo; false en otro caso. ¿Cuál es la correcta representación del método pruebas de equivalencia? function envio_gratis( importe_compra , minimo_envio_gratis) { return importe_compra>=minimo_envio_gratis }. minimo_envio_gratis: <0, =0, >0 importe_compra: <minimo_envio_gratis, =minimo_envio_gratis, >minimo_envio_gratis. minimo_envio_gratis: -1, 0, 1 importe_compra: minimo_envio_gratis <, minimo_envio_gratis, > minimo_envio_gratis.

La función envio_gratis devuelve true cuando el importe de la compra es igual o superior al importe mínimo; false en otro caso. ¿Cuál es la correcta representación del método de los valores límite? function envio_gratis( importe_compra , minimo_envio_gratis) { return importe_compra>=minimo_envio_gratis }. minimo_envio_gratis: <0, =0, >0 importe_compra: <minimo_envio_gratis, =minimo_envio_gratis, >minimo_envio_gratis. minimo_envio_gratis: -1, 0, 1 importe_compra: minimo_envio_gratis -1 , minimo_envio_gratis, > minimo_envio_gratis.

En las pruebas TDD existen dos métodos a la hora elegir los parámetros y test que hagamos. Verdadero. Falso.

En los TDD usamos 2 métodos para elegir los test y sus valores. Pruebas de caja negra y caja blanca. Pruebas de caja negra y particiones de equivalencia. Pruebas de unidad y de integración. Valores límite y particiones de equivalencia.

1. Crear conjuntos para cada condición de entrada 2. Probar un representante de cada conjunto. Clases de equivalencia. Valores límite.

Permiten probar la unidad en los valores cercanos a los últimos de un rango. Clases de equivalencia. Valores límite.

¿En qué fase del ciclo TDD se encuentra? function get_a_number(num) { } describe("Obtiene un número", function() { it("devolvería el cuadrado del número que se le pasa", function() { expect( get_a_number(8)).toEqual( 64 ) }); });. Roja. Verde. Refactor.

¿En qué fase del ciclo TDD se encuentra? function get_a_second_number(num) { if( num<10 || num>10 || num<=10 || num>=10) return 10; if( num==10 || num>=10 ) return 10; } describe("Obtiene otro número", function() { it("debería devolver el la raíz cuadrada de 100", function() { expect( get_a_second_number(-5)).toEqual( 10 ) expect( get_a_second_number(9)).toEqual( 10 ) expect( get_a_second_number(10)).toEqual( 10 ) expect( get_a_second_number(11)).toEqual( 10 ) expect( get_a_second_number(12)).toEqual( 10 ) }); });. Rojo. Verde. Refactor.

Dado el siguiente código en Javascript, ¿cuál de las *DOS LINEAS DESTACADAS* es la que habríamos escrito primero si estuviéramos usando la metodología TDD? ¿Por qué? <script> function siempre_devuelve_false() { *RETURN FALSE* } describe("Siempre devuelve false", function() { it("debería devolver false", function() { *EXPECT( SIEMPRE_DEVUELVE_FALSE()).TOEQUAL(FALSE)* }); }); </script>. RETURN FALSE. EXPECT( SIEMPRE_DEVUELVE_FALSE()).TOEQUAL(FALSE). Da igual el orden de escritura.

El ATDD o Acceptance TDD está pensado para proyectos individuales. Verdadero. Falso.

El ATDD o Acceptance TDD está pensado para proyectos grupales. Verdadero. Falso.