Introducción a la Ingeniería del software

Un buen software debe proporcionar la funcionalidad requerida por el cliente y además tener las siguientes características (seleccionar la que no corresponde). Mantenibilidad - Para poder evolucionar para satisfacer las nuevas necesidades. Eficiencia - Los recursos no han de ser malgastados. Durabilidad - Para poder ser utilizado durante un largo periodo de tiempo. Aceptación - Por los usuarios finales (no por los desarrolladores).

El mito sobre desarrollo de software que dice "Si vamos mal de tiempo, podemos añadir más programadores para avanzar más rápido". Es falso porque añadir más programadores puede exigir un mayor esfuerzo en su coordinación. Es falso porque añadir programadores que no están familiarizados con el proyecto puede retrasar su avance. Las dos anteriores son correctas. Ninguna de las anteriores es correcta.

¿Cuál de las siguientes afirmaciones es verdadera en el contexto de un proyecto software?. Si hay que acelerar el desarrollo, lo ideal es incorporar más programadores. Las etapas del software siguen un orden prestablecido siempre. La productividad no es proporcional al número de personas trabajando en una tarea. Las personas del equipo deberían dedicarse a varias tareas.

El camino crítico es: El conjunto de tareas que debe completarse obligatoriamente en el proyecto. El conjunto de tareas que tienen holgura 0. El conjunto de tareas que garantizan que el proyecto se acabará a tiempo. Ninguna de las anteriores es correcta.

¿Cuáles son las fases del proceso de gestión del riesgo y en qué orden se deben realizar?. Identificación, Análisis, Planificación y Seguimiento. Identificación, Planificación, Análisis y Seguimiento. Identificación, Análisis, Seguimiento y Planificación. Análisis, Identificación, Planificación y Seguimiento.

Estamos dedicando el 100% de nuestros recursos a desarrollar una aplicación móvil tipo mascota virtual y los contactos en la competencia nos informan de que este tipo de juego se ha puesto de moda y están a punto de aparecer varias docenas de aplicaciones similares en el mercado. ¿Qué tipo de riesgo supone esencialmente esta situación?. Un riesgo del producto. Un riesgo del negocio. Un riesgo del proyecto. No es un riesgo, sino una oportunidad para motivar al equipo.

Los tipos de riesgo son (seleccionar el que no corresponda): Los riesgos de proyecto. Los riesgos de desarrollo. Los riesgos de producto. Los riesgos de negocio.

¿Cuál de las siguientes afirmaciones no es cierta?. Entender el problema es tarea de la ingeniería de requisitos. Los modelos de procesos software son una representación simplificada de un proceso software. Los proyectos software reales suelen seguir un flujo secuencial. No existe un proceso software ideal.

En SCRUM... (seleccionar la afirmación falsa): Todo el equipo participa en todas las fases. Se reflexiona sobre lo que ha funcionado bien y mal en el daily Scrum. Existen menos jerarquías y roles que en un proceso software tradicional. Los ciclos cortos disminuyen los riesgos.

Una de las cuatro ideas fundamentales de la metodología XP (Extreme Programming) es el «Coraje». ¿A qué hace referencia?. Al valor con el que deben establecerse cauces de comunicación frecuentes y fluidos entre todas las partes interesadas. A la capacidad de emprender los cambios necesarios en el código y corregir los errores con decisión y firmeza. Al ánimo con el que debe buscarse la simplicidad a la hora de diseñar e implementar. Al enfurecimiento que experimenta el programador cuando aparecen errores en tiempo de ejecución.

¿Qué modelo de proceso software es secuencial, desde la planificación hasta su finalización?. Modelo de prototipado. Modelo secuencialista. Modelo en cascada. SCRUM.

En SCRUM, el "Product Backlog". Reúne los requisitos de un Sprint. Reúne los requisitos de proyecto priorizados. Se realiza antes de comenzar cada Sprint. Es el encargado de organizar las reuniones.

Test Driven Development... es una técnica de desarrollo de software. es una técnica de testing. consiste en probar antes de desarrollar. consiste en probar antes de integrar cada elemento software que se desarrolle. Ninguna de las otras respuestas es cierta.

¿Cuál de las siguientes afirmaciones es cierta sobre requisitos?. Los requisitos no funcionales influyen más que los funcionales en la cantidad de código que debe desarrollarse. Los requisitos no funcionales influyen más que los funcionales en la cantidad de pruebas que son necesarias. Los requisitos no funcionales influyen más que los funcionales en la selección arquitectura que debe adoptarse. Ninguna de las otras respuestas es cierta.

El uso del lenguaje natural para especificar requisitos tiene los siguientes problemas: Ambigüedad, falta de flexibilidad, imposibilidad de usar plantillas, particionamiento. Ambigüedad, falta de claridad, exceso de flexibilidad, particionamiento. Ambigüedad, falta de modularidad, exceso de flexibilidad, falta de claridad. Ninguna de las otras respuestas es cierta.

Las técnicas de elicitación (descubrimiento) de requisitos incluyen: Entrevistas, cuestionarios, observación (etnografía) de documentación, reuniones de grupo. Escenarios, cuestionarios, observación, revisión por pares, reuniones de grupo. Entrevistas, cuestionarios, prototipos, escenarios, reuniones de grupo. Ninguna de las otras respuestas es cierta.

Cuando queremos detallar un caso de uso, normalmente: Añadimos más detalles al diagrama de casos de uso. Lo hacemos mediante la especificación de diagramas de clases. Lo hacemos mediante la especificación de diagramas de secuencia. Lo hacemos mediante la especificación de diagramas de actividad.

¿Cuál de las siguientes descripciones se ajusta mejor a la relación especificada en la imagen (la cardinalidad no se muestra)?. «Tenemos varias instancias de B que en un momento dado se reunirán para formar un A». «Tenemos varias instancias de A que en un momento dado se reunirán para formar un B». «Una vez instanciado el A se podrán instanciar uno o varios de los B que lo componen». «Una vez instanciado el B se podrán instanciar uno o varios de los A que lo componen».

En un diagrama de clases que incluye las clases A y B, cuando tenemos una asociación unidireccional A-->B: Los objetos de tipo A no pueden contener referencias a objetos de tipo B. Los objetos de tipo B no pueden contener referencias a objetos de tipo A. Los objetos de tipo A siempre contienen referencias a un objeto de tipo B. Todas las anteriores son falsas.

El siguiente diagrama es incorrecto, ¿por qué?. P1 no puede enviar el mensaje 2 en el punto en el que aparece. El mensaje 1.1 enviado por P1 debería ser asíncrono. Los participantes no tienen nombre. No hay un actor que inicie la acción.

En el siguiente código y suponiendo que todas las variables están correctamente declaradas y que el mensaje asociado a la excepción aritmética de dividir por cero contiene "/ by zero": El primer assert tiene éxito y el segundo no se ejecuta. El primer assert falla y el segundo no se ejecuta. Ambos assert fallan. Ambos assert se ejecutan con éxito.

Las pruebas de caja negra (seleccionar la afirmación falsa): Incorpora técnicas tales como la de "particiones de equivalencia". Son una alternativa a las pruebas de caja blanca. Ignoran intencionalmente la estructura de control del programa. Incorpora técnicas tales como "análisis de valores límite".

Consideremos la clase de Java ExcepcionPersonal y la clase de prueba asociada ExcepcionPersonalTest: ¿Qué ocurrirá al ejecutar el método de prueba probarExcepcionPersonal?. Finalizará la ejecución y se pasará la prueba. Finalizará la ejecución, pero fallará el aserto assertThrows. Finalizará la ejecución, pero fallará el aserto assertEquals. No finalizará la ejecución porque se producirá una excepción.

Las pruebas de software son: Un proceso para demostrar que no hay errores en el software. Un proceso para demostrar que el software funciona correctamente. Un proceso para identificar errores y determinar la calidad del software. Todas las anteriores son verdaderas.

El principio de sustitución de Liskov dice que: "Las subclases deben poder ser sustituidas sin modificar la clase base". "Las subclases deben poder sustituir a la superclase sin que se necesiten cambios en el código cliente". "Las superclases deben sustituirse siempre por las subclases adecuadas". "Las superclases deben poder ser sustituidas sin que sea se necesiten cambios en las subclases".

Debemos diseñar el software de una red de sensores que recoge información ambiental por todo el Campus Universitario. Según los requisitos, es posible optar por una arquitectura centralizada (con un nodo servidor y todos los demás clientes) o bien por una arquitectura distribuida tipo punto a punto (P2P). ¿Cuál de los siguientes argumentos podría emplearse para justificar el uso de una arquitectura P2P?. Es más sencillo establecer y coordinar políticas comunes para todos los nodos. Podría ser más resistente a un ataque de denegación de servicio. La seguridad está más centralizada que en una arquitectura cliente servidor. Generalmente se requieren menos mensajes entre nodos y es menos probable que se sature la red.

Si en alguna parte de mi software he de elegir entre dos o más algoritmos que ofrezcan un mismo interfaz con implementaciones diferentes, consideraré un diseño que haga uso del patrón: Strategy. Factory method. Fachada. Singleton.

En una aplicación abierta, queremos contar el número de visitas a nuestro sistema. Para ello, queremos usar el patrón Singleton para que los tres mecanismos de acceso (WebPage, REST._API Y SOAP__API) compartan un único contador de visitas (VisitCounter). Dado este diagrama: El diagrama es incorrecto porque getCounter () debería devolver un entero. El diagrama es incorrecto porque VisitCounter () no cumple la convención de que los nombres de los métodos comiencen por minúscula. El diagrama es incorrecto porque VisitCounter () debería ser privado. El diagrama es correcto.

Los principios de diseño SOLID: Han de aplicarse en la medida de lo posible para mejorar la calidad del diseño software. Han de cumplirse siempre todos para garantizar un diseño de calidad. Son excluyentes, no pueden cumplirse más de dos simultáneamente en un mismo diseño. Han de ser tenidos en cuenta, pero con moderación, pues mejoran la escalabilidad del software al mismo tiempo que empeoran la legibilidad.

El principio de responsabilidad única dice que: "Una clase debe tener una única razón para cambiar". "Una clase debe tener un único desarrollador responsable de sus modificaciones". "Una clase debe tener un único método público (su responsabilidad)". "Una clase debe tener estar cerrada a modificaciones excepto para su responsabilidad".