Multimedia de moguris para moguris

miércoles, 23 de mayo de 2012

miércoles, 4 de abril de 2012

viernes, 23 de marzo de 2012

Refactorizar en la práctica: Peligros y soluciones

Preguntas Test:

1. Refactorizar es
    a) Modificar el código para mejorar su comportamiento externo sin alterar su estructura interna
    b) Reescribir el código para evitar posibles confusiones
    c) Modificar el código para mejorar su estructura interna sin alterar su comportamiento externo
    d) Añadir funciones nuevas al código

2. La calidad de un código
    a) Viene determinada por el número de líneas que tiene
    b) Viene determinada por su sencillez y estructuración
    c) Viene determinada por la cantidad y calidad de comentarios
    d) Viene determinada por la profesionalidad de los integrantes del equipo de desarrollo

3. La eficiencia de un código
    a) Depende del tiempo que tarda en compilarse
    b) Depende del número de errores que encuentra
    c) Depende de un diseño intuitivo y funcional
    d) Depende del número de comentarios informativos

4. Los "Bad Smells" son
    a) Fallos tanto de compilación como de ejecución
    b) Aspectos del código que determinan si sería viable o no una refactorización
    c) Aspectos del código que nos informan de que el código puede tener problemas
    d) Requisitos del cliente que entorpecen el desarrollo del código anterior

5. A la hora de refactorizar no importa
    a) Lo extensa que sea una clase o función.
    b) Si existe código duplicado.
    c) La cantidad de clases y funciones que haya.
    d) El número de individuos del equipo de desarrollo

6. Es recomendable refactorizar
    a) Inmediatamente al detectar algún imprevisto que interfiera con el desarrollo de código
    b) Al final de la elaboración del código fuente
    c) Siempre y cuando se nos de permiso para empezar con la refactorización
    d) Solo si existe algún motivo de peso que nos obligue a ello

7. Los integrantes de un equipo de desarrollo
    a) No necesariamente han de estar comunicados unos con otros
    b) Han de estar comunicados mediante comentarios detallados en el código
    c) Han de trabajar en un código sencillo que todos puedan entender
    d) Deben especificar desde el primer momento un código rígido e invariable

8. Un código
    a) Ha de ser rígido e invariable durante todo el proceso de desarrollo
    b) Puede evolucionar alterándose y necesitando de posteriores refactorizaciones
    c) Viene determinado por el cliente, nosotros solo debemos refactorizarlo
    d) Ha de generarse de forma intuitiva incluso si el cliente no nos lo ha especificado

Desarrollo del software dirigido por modelos

Descargar resumen

Preguntas test:

1. El Desarrollo de Software Dirigido por Modelos (DSDM) surge debido a:

a) La alta complejidad de las aplicaciones y la dependencia del soporte tecnológico.

b) Rápida evolución de la tecnología.

c) Bajo nivel de abstracción.

d) Todas las anteriores son ciertas.

2. En el DSDM, los modelos son:

a) Documentos estructurados que capturan el funcionamiento de los sistemas.

b) Repositorios donde se almacenan los requisitos funcionales del sistema.

c) Plantillas a seguir para la realización de un proyecto.

d) Mecanismos específicos de cada fase.

3. En el DSDM, los modelos se caracterizan por ser:

a) Abstractos, precisos, comprensibles.

b) Complejos, precisos, caros.

c) Extensos, inestables, baratos.

d) Abstractos, cambiantes, complejos.

4. El DSDM se basa en:

a) Los distintos casos de uso que se pueden dar en el sistema.

b) La separación entre la especificación de la estructura y funcionalidad esenciales del sistema y la implementación final.

c) Reflejar la arquitectura del sistema, de manera que desde el principio existe una base sobre la cual se van agregando elementos.

d) La importancia de implementar código, dejando a un lado la fase de requisitos.

5. Los tres objetivos primarios de MDA (Model Driven Architecture) son:

a) Escalabilidad, reusabilidad y centralización.

b) Autogestión, portabilidad y mantenimiento.

c) Portabilidad, interoperabilidad y reusabilidad.

d) Estabilidad, expansión y desacoplamiento.

6. Como aplicación del DSDM, destaca:

a) La autogestión de los proyectos.

b) La implantación de mejoras de seguridad.

c) La conversión entre distintos modelos semánticos.

d) La generación automática de código.

7. Mediante modelos, DSDM persigue…

a) Facilitar la implementación de código.

b) Elevar el nivel de abstracción en el desarrollo de software.

c) El acercamiento a los recursos.

d) Optimizar la eficiencia de los productos finales.

8. Entre las desventajas de los modelos, cabe destacar:

a) La imposibilidad de capturar todos los casos de uso.

b) La imposibilidad de relacionar distintos modelos del mismo sistema.

c) La pérdida semántica (respecto al sistema real) que se produce al utilizarlos.

d) La incapacidad de reflejar todos los recursos de los que dispone el sistema.

martes, 20 de marzo de 2012

Las pruebas en metodologías ágiles y convencionales

Descargar Resumen

Preguntas tipo test:

1. Las metodologías ágiles han emergido como una reacción para...

a. Superar cambios de mercado y una progresiva reducción del tiempo de los procesos relativos a los requisitos.

b. Mejorar los tiempos de producción a costa de disminuir la calidad de los productos.

c. Hacer software de calidad aumentando el tiempo de producción.

d. Construir el software a través de varias personas, teniendo tareas sencillas que duren poco tiempo.

2. Las pruebas tienen objetivos diferentes en las distintas metodologías:

a. En las metodologías convencionales se utilizan como validación del producto desarrollado.

b. En las metodologías ágiles se utilizan en sustitución de las especificaciones de requisitos

c. En las metodologías ágiles se utilizan como guía para el desarrollo de software.
d. Todas las anteriores son correctas.

3. Las técnicas de caja blanca están basadas en:
a. Valores de entrada y salida.
b. Requisitos funcionales.
c. Código fuente.
d. Requisitos no funcionales.

4. Las técnicas de caja negra están basadas en:

a. Valores de entrada y salida.

b. Requisitos funcionales.

c. Código fuente.

d. Requisitos no funcionales.

5. Cuando se habla de las pruebas en los enfoques convencionales, fundamentalmente se identifican las siguientes actividades relacionadas:
a. Codificación e implementación.
b. Pruebas unitarias, pruebas de integración, pruebas de aceptación y pruebas de sistema.
c. Implementación y pruebas de caja negra/blanca.
d. Pruebas basadas en código fuente.

6. El enfoque TDD toma como base:
a. Las pruebas unitarias.
b. Las pruebas de integración.
c. Las pruebas de aceptación.
d. Las pruebas de sistema.

7. El propósito de las pruebas unitarias es:
a. Probar el código completo al finalizarlo.
b. Probar el código en un intervalo de tiempo establecido.
c. Probar el código una vez por fase para detectar errores.
d. Probar una parte del código aislada del resto.

8. El enfoque ATDD se basa en:

a. Las pruebas unitarias.

b. Las pruebas de integración.

c. Las pruebas de aceptación.

d. Las pruebas de sistema.