En gestión de proyectos, los analistas se pueden saltar la recogida de requisitos porque ya lo han hecho otras veces y conocen lo que los usuarios necesitan	Falso (Módulo 3, apartado 2
En orientación a objetos, una clase de objetos es un conjunto de instancias que comparten los mismos atributos y comportamiento.	Cierto (Módulo 2, Apartado 2.3)
En un diagrama de casos de uso UML, un punto de extensión define en qué punto de un caso de uso se puede producir un evento que provoca un comportamiento alternativo.	Cierto (Módulo 4, Apartado 2.1.6)
En un diagrama de clases UML, la composición se dibuja con un rombo de color *****	Cierto (Módulo 4, Apartado 4.8.1)
El objetivo final de la gestión de proyectos es poder llegar a equilibrar las siguientes 3 variables: calidad, coste y tiempo.	Falso. Módulo 1, apartado 2.3.1
Una clase asociativa es aquella asociación las instancias de la cual son instancias de una clase.	Falso. Módulo 2, apartado 2.3.2.
Según Cockburn, los casos de uso se pueden clasificar según su granularidad en los siguientes niveles: Usuario, General o Tarea.	Cierto. Módulo 3, apartado 5.4.1.
Mediante un diagrama de casos de uso podemos saber cuál será el comportamiento final del sistema.	Falso. Módulo 4, apartado 2.1.
En gestión de proyectos, hay que equilibrar cuatro variables: alcance, tiempo, coste y riesgo.	Falso (Módulo 1, Apartado 2.3.1)
En orientación a objetos, en una asociación recursiva puede haber muchas clases implicadas.	Falso (Módulo 2, Apartado 5.3)
En un diagrama de casos de uso UML, describimos quién utiliza el sistema y como puede interactuar.	Cierto (Módulo 4, Apartado 2.1)
Un diagrama de actividades UML debe incluir sólo un único símbolo de final de proceso	Falso (Módulo 4, Apartado 2.2)
En orientación a objetos, el polimorfismo permite que varias clases diferentes tengan un comportamiento homogéneo.	Falso (Módulo 2, Apartado 4.2)
En orientación a objetos, la relación entre una cesta de compra y los productos comprados en esta cesta es de generalización / especialización.	Falso (Módulo 2, Apartado 4.1.1)
En un diagrama de casos de uso UML es conveniente mezclar casos de uso de diferentes nivel de abstracción	Falso (Módulo 4, Apartado 2.1.3)
En un diagrama de actividades, todos los flujos entrantes en un join se deben completar antes que el proceso continúe.	Cierto (Módulo 4, Apartado 2.2.2)
Un ciclo de vida clásico o en cascada puede ser el más adecuado para proyectos que tengan objetivos claros y soluciones conocidas	Cierto: Apartado 3.2.1 del módulo 1
El uso de patrones de diseño es una técnica de reutilización de la implementación que tiene como principal inconveniente que es difícilmente aplicable en dos contextos diferentes	Falso: No es una técnica de reutitlización basada en la implementación, por tanto, no tiene el inconveniente que se menciona. Apartado 4.1.5 del módulo 1
Uno de los problemas más importantes de la priorización de requisitos es que el valor que aporta cada uno de ellos es relativo a los stakeholders, un mismo requisito puede ser muy importante para un stakeholder mientras que para otro puede ser muy poco importante.	Cierto: Apartado 3.2 del módulo 3
El principal inconveniente de las historias de usuario es que no permiten establecer cuando una historia está implementada completamente.	Falso, las pruebas son uno de los componentes básicos de las historias de usuario y permiten establecer cuando una historia está implementada completamente: Apartado 4.3 del módulo 3
En un ciclo de vida iterativo e incremental, durante las primeras iteraciones sólo se hará trabajo de obtención y selección de requisitos	Falso. Módulo 1 apartado 2.2
En el contexto de los roles típicos de la ingeniería del software, el analista funcional tiene, entre otras responsabilidades, la de hacer el diseño detallado del sistema respetando la arquitectura definida por el arquitecto	Falso, se trata de una tarea del analista orgánico o analista técnico: Apartado 2.4.5 del módulo 1
En el contexto de la gestión ágil de requisitos podemos utilizar unidades ficticias (como los puntos de historia) o reales (como las horas de trabajo) para estimar el coste de cada requisito.	Cierto: Apartado 3.1.1 del módulo 3
El hecho de que las historias de usuario estén muy enfocadas a la comunicación verbal puede ser a la vez una ventaja (las hace más ágiles y fluidas) y un inconveniente (no quedan documentadas).	Cierto: Apartado 4.3 del módulo 3
En el contexto del desarrollo ágil no hay que crear ningún tipo de documentación ya que el segundo principio de "el agile manifesto" es "Software que funciona por encima de documentación exhaustiva"	Falso, este principio en ningún caso dice que no sea necesario documentar nada: Apartado 3.3.3 del módulo 1
Todos los actores son stakeholders por fuerza pero puede suceder que no todos los stakeholders sean actores	Cierto: Apartado 5.2 del módulo 3
En un contexto de desarrollo ágil se utilizan mucho más los casos de uso que las historias de usuario para documentar requisitos funcionales.	Falso, es precisamente al revés: Apartado 4.3 del módulo 3
Por defecto UML considera que los extremos de las asociaciones son ordenadas y sin repeticiones	Falso, las considera sin orden y sin repeticiones: Apartado 4.8.2 del módulo 4
Según Scrum, el rol de Scrum Master define a la persona responsable de decidir qué se implementa y qué es más prioritario	Falso. Módulo 1. Apartado 3.3.3.
Los atributos de una clase pueden almacenar, o bien un valor diferente para cada instancia, o bien un mismo valor para todas las instancias de la clase.	Cierto. Módulo 2. Apartado 2.3.1.
Los casos de uso son la herramienta habitual de documentación de requisitos en las metodologías ágiles	Falso. Módulo 3. Apartado 4.3.
La unión (join) en un diagrama de actividades bloquea la ejecución hasta que no han finalizado todos los flujos de entrada	Cierto. Módulo 4. Apartado 2.2.2.
En la fase de selección de requisitos no se deben considerar los riesgos asociados a cada requisito porque sólo se tiene en cuenta la prioridad.	Falso, sí que se deben considerar. Apartado 3.3 del módulo 3.
Un método de desarrollo de software debe describir las tareas, los roles y los artefactos que entran en juego en los procesos que describe	Cierto. Apartado 2.2 del módulo 1.
En el contexto de los roles típicos de la ingeniería del software, los programadores son los encargados de desarrollar los programas que están desarrollando.	Falso, se trata de una tarea del encargado de despliegue: Apartado 2.4 del módulo 1.
El lenguaje de programación no puede formar parte de los requisitos	Falso, puede venir determinado por un stakeholder. Apartado 1.2 del módulo 3.
Para seleccionar los requisitos debemos tener en cuenta la prioridad, el costo y los recursos disponibles	Cierto. Apartado 3.3 del módulo 3.
En un ciclo de vida iterativo e incremental, no es hasta la tercera iteración que disponen de un producto operativo	Falso, en cada iteración se pasa por todas las fases. Apartado 3.2.2 del módulo 1.
En el contexto de los roles típicos de la ingeniería del software, el jefe de proyecto tiene, entre otras responsabilidades, la de escoger la tecnología adecuada para la implementación del proyecto	Falso, se trata de una tarea del arquitecto: Apartado 2.4 del módulo 1.
Una de las técnicas más usadas en la obtención de requisitos es el Planning poker	Falso, el Planning poker es para valorar requisitos. Apartado 3.1.3 del módulo 3.
El objetivo final de la gestión de proyectos es poder llegar a equilibrar las siguientes 3 variables: calidad, coste y tiempo.	Falso. Módulo 1, apartado 2.3.1.
Una clase asociativa es aquella asociación las instancias de la cual son instancias de una clase	Falso. Módulo 2, apartado 2.3.2.
Según Cockburn, los casos de uso se pueden clasificar según su granularidad en los siguientes niveles: Usuario, General o Tarea.	Cierto. Módulo 3, apartado 5.4.1.
Mediante un diagrama de casos de uso podemos saber cuál será el comportamiento final del sistema	Falso. Módulo 4, apartado 2.1.

Descubre

Crear Tarjetas

Acerca de Nosotros

Explore Tarjetas

Comparta este Set de Tarjetas de Aprendizaje

Tarjetas de Aprendizaje relacionadas

Ing. Software

Cómo estudiar sus tarjetas

Rango de Cartas a estudiar

44 Cartas en este set