Calvo pon estas preguntas

Comenzar a codificar justo al inicio del proyecto es bueno porque... Nos permite iterar sobre los requisitos sobre una aplicación. Así el proyecto tarda más y podemos cobrar más al cliente. El cliente ve resultados desde el principio. No es bueno.

Sobre los requisitos... No cambian durante la ejecución del proyecto. Pueden aparecer requisitos que no habíamos considerado. Habrá inherentemente requisitos que tenemos que añadir. Se hace un ciclo de vida completo para cada requisito.

Ante un cambio de un requisito... Tenemos que rechazarlo, hay que saber decir que no. Es posible que sea más fácil rehacer desde cero el diseño e implementación que arreglarlo. Debemos mantener el antiguo y añadir este como un requisito nuevo. Los requisitos no pueden cambiar.

El modelo del dominio... Se corresponde con el mundo real relevante al proyecto. Se corresponde con el software a implementar. Se corresponde con el interfaz. Se corresponde con los requisitos.

El sistema es... El software a desarrollar. El software que también pertenece al entorno. Una representación del mundo real y nuestra aplicación software. Corrupto, cruel y creado por máquinas para obtener energía.

Las entidades del interfaz... Son habitualmente controladas o detectadas por el sistema o el entorno, pero no por ambos. Se corresponden con elementos físicos del entorno. Se controlan con el ratón. No pertenecen al sistema.

Los REQUISITOS... Se expresan en términos de entorno. Se expresan en términos de interfaz. Se expresan en términos de sistema. Se expresan en términos de los usuarios.

El entorno... Se puede modelar con un diagrama de contexto. Se puede modelar con un diagrama de secuencia. Se puede modelar con un diagrama de Venn. Se puede modelar con un diagrama de casos de uso.

El conocimiento del dominio... Se refiere a los casos de uso que habrá que implementar en el dominio de la aplicación. Es todo aquello del mundo real que se relaciona con la aplicación. Son propiedades del dominio que ayudan a satisfacer los requisitos. Lo tienen los programadores.

La mayoría de las especificaciones de requisitos software están escritas... En lenguaje semiformal. En lenguaje formal. En lenguaje naturaldominio. En diagramas.

¿Qué opciones tenemos si nuestra especificación junto al dominio NO satisface los requisitos?. Fortalecer la especificación. Relajar los requisitos. Fortalecer el conocimiento del dominio. Eliminar el requisito.

Los cuantificadores universales... No son críticos. Son útiles. Son peligrosos. Hay que evitarlos a toda costa.

"The domain is the subject matter of the system's computations, and provides the context in which those computations have useful meaning or effect." A domain is "a topic for description in its own right, independently of any description that we may eventually make of the system to be constructed." ¿Cómo debemos describir el dominio?. Modo indicativo. Modo optativo. Modo imperativo. Modo interrogativo.

¿Cómo debemos describir los requisitos?. Modo interrogativo. Modo indicativo. Modo optativo. Modo imperativo.

Un cuantificador universal en el modo indicativo... Es deseable. Es lógico. Ha de ser desafiado. No importa.

En el contexto del dominio, ¿cuál es una técnica útil para desafiar los cuantificadores universales?. Ignorarlos. Incluirlos en los requisitos. Advertir a los desarrolladores. Mirroring.

En el modo optativo (requisitos), un cuantificador universal es... Prohibido. Deseable. Ignorable. Inútil.

Sobre cuantificadores universales... En modo optativo es probablemente falso. En modo indicativo es probablemente falso. En modo optativo indica que hay que cubrir el caso base y las excepciones. En modo indicativo indica que hay que cubrir el caso base y las excepciones.

Imagina una frase extraída de una especificación de requisitos. Si se la damos a 10 personas, y hay más de una interpretación, es probable que sea ambigua Si una frase tiene una interpretación ambigua, habitualmente... El lector se queda con la última acepción. El lector se queda con la primera acepción. El lector evalúa todas las posibilidades. El lector no la entiende.

¿Cuál NO es un paso recomendado a la hora de crear un diagrama de clases del dominio?. Añadir las asociaciones a las clases en el diagrama de clases. Listar las clases conceptuales relacionadas con el proyecto y las operaciones que pueden hacer. Añadir los atributos a las clases en el diagrama de clases. Incluir los casos de uso como clases.

¿Cuál de las siguientes NO es una relación habitual en el diagrama de clases del dominio?. Dependencia. Herencia. Extends. Composición.

¿Cuál es la relación entre Aplicación, Frontend y Backend?. La aplicación puede tener frontend, backend o ambos. El frontend es una aplicación, y el backend otra. La aplicación tiene frontend y backend. Aplicación rombito frontend y backend.

¿Cuál es la relación entre aplicación, frontend y backend?. La aplicación se compone, opcionalmente, de un frontend y un backend. No podemos tener una aplicación sin frontend y backend. La aplicación tiene que ser o frontend o backend. Tenemos una clase genérica de aplicación; a su vez, hay 2 tipos de aplicaciones específicas, frontend y backend.

El fluwinki makalea un puffon kitano petarísticamente Fluwinki es un sustantivo. Lo pondríamos como... Un atributo. Un requisito no funcional. Una relación. Una clase.

El fluwinki makalea un puffon kitano petarísticamente Makalea es un verbo. Lo pondríamos como... Un atributo. Una relación. Una clase. Un requisito no funcional.

El fluwinki makalea un puffon kitano petarísticamente Kitano es un adjetivo. Lo pondríamos como... Un atributo. Una relación. Una clase. Un requisito no funcional.

De manera informal, un caso de uso es... Una secuencia de pasos para obtener un objetivo. Lo que el usuario no administrador puede hacer en el sistema. Cada forma de utilizar el sistema. Cada función del sistema.

Un escenario es... Un conjunto de casos de uso. Donde voy a estar yo en 3 años, que le den por saco a la informática. Voy a ser una estrella. La lista de actores que intervienen en un caso de uso. Una secuencia de pasos concretos que ocurren entre el usuario y el sistema.

Un caso de uso puede tener... Alternativas. Atributos. Excepciones.

La definición formal de un caso de uso es que... Es una generalización de varios escenarios. Es una forma de utilizar una aplicación. Es un conjunto de actores y relaciones. Es un diagrama.

Un caso de uso es Una abstracción parametrizada de uno o más escenarios de tal forma que cada escenario se obtiene aplicando una serie de parámetros específica al caso de uso. ¿Cómo nos puede ayudar esta definición a la hora de establecer especificaciones de requisitos?. Permite establecer límites a los requisitos. Nos ayuda a definir todos los escenarios posibles. El caso de uso tiene que cubrir cualquier parametrización - i.e, excepciones, entradas no esperadas... A nada, se hace la especificación antes que los diagramas de casos de uso.

Si llega a un desarrollador/tester una especificación de requisitos incompleta... Tiene que posponer la tarea hasta que el project manager la aclare. Toma una decisión, ya que conoce la aplicación y el código. Debería de preguntar a las personas relevantes para aclarar la especificación. Debería de pasarle la tarea a un compañero con más experiencia.

¿Cuándo tiene que estar el cliente disponible para resolver dudas?. Al inicio del proyecto cuando se discute el alcance. Durante toda la etapa planificada de Ingeniería de Requisitos. En la fase de Obtención de Requisitos. Durante toda la etapa real de Ingeniería de Requisitos.

Actualmente, se tiende más y más a ciclos de vida iterativos, con iteraciones cortas (una o dos semanas). Una de las ventajas que tiene es adaptarse a cambios de requisitos, o requisitos no especificados de forma fácil. Como mínimo, en cada iteración el equipo tiene una reunión con un stakeholder. ¿Qué participantes son esenciales en estas reuniones?. Algún tester y algún desarrollador. El jefe de proyecto. El representante de ventas. El usuario final del cliente.

Moviéndonos a Especificación de Requisitos Software. ¿Cuál NO es una restricción de diseño?. El lenguaje de programación a utilizar. El sistema operativo con el que tiene que ser compatible. Tener en el equipo al menos 2 testers. Límites de cuotas de la aplicación.

En el estándar ISO de Especificación de Requisitos, ¿podemos customizarlo al proyecto - por ejemplo, usar diagramas no estándar?. Sí, siempre que lo indiquemos en el apartado correspondiente de la sección 1. No, es necesario seguir el estándar. Sí, siempre que los cambios sean intuitivos. Sí, indicando en cada sección qué customizaciones incluye.

En la sección 2.2, Características del producto, se incluye: Las características del logo. Los diagramas de secuencia de los casos de uso. Los requisitos no funcionales. Un listado exhaustivo de los casos de uso.

La sección de características del usuario nos permite... Definir qué características son deseables que tengan los usuarios. Establecer los requisitos mínimos que cada usuario tiene que cumplir para usar la aplicación de forma autónoma. Limitar el acceso a ciertos componentes de la aplicación según el tipo de usuari. Conocer el perfil de cada usuario individual de la aplicación de cara a mejorar su experiencia.

¿Cuál NO sería una restricción general (apartado 2.4)?. Los usuarios administradores tienen acceso a la base de datos. Auditar las acciones de los usuarios. Utilizar Role Based Access Control (RBAC). Limitar cada instancia de la aplicación a 32GB de RAM (las máquinas que tenemos están limitadas).

¿Con qué tipo de requisitos están relacionadas las restricciones generales?. Requisitos de mantenimiento. Requisitos de usuario. Requisitos funcionales. Requisitos no funcionales.

Suposiciones y dependencias... (2.5). ¿Cuál de las siguientes NO es correcta en una aplicación de e-commerce?. Sólo los usuarios registrados pueden comprar. La aplicación está funcionando 24x7. Las bases de datos nunca fallan.

¡Sección 3 de la especificación de requisitos! Obligatoriamente, tiene que contener... Todas las funciones que realiza el sistema. Todos los interfaces del sistema. El listado de hardware necesario para aplicación. Todos los servicios externos que usarán el software.

¿Cuál NO es una forma típica de organizar los requisitos funcionales?. Por tipo de interfaz. Por usuarios. Por características. Por casos de uso.

¿Cuál de los siguientes requisitos de rendimiento es incorrecto en la especificación?. El sistema manejará 200GB de datos diarios. El sistema procesará 500 registros por segundo. El sistema admitirá 200 usuarios simultáneos. El sistema ejecutará las consultas de manera eficiente.

¿Cuál de los siguientes requisitos no funcionales es correcto?. Un usuario administrador puede modificar el perfil de cualquier usuario. La aplicación web ofrece interfaz web encriptado (sólo HTTPS). Un usuario puede hacer apuestas sólo si tiene suficiente saldo. La aplicación diariamente reporta a los usuarios los resultados de los partidos.

En el modelo WRSPM, ¿qué es la interfaz?. La intersección entre el entorno y el sistema. La interfaz gráfica. La intersección entre el mundo y el entorno. Ninguna de las otras.

Si la especificación de requisitos y el conocimiento del dominio no son suficientes para satisfacer los requisitos, ¿qué hacemos?. Fortalecer la especificación, relajar los requisitos y fortalecer el conocimiento del dominio. Relajar la especificación, fortalecer los requisitos y fortalecer el conocimiento del dominio. Fortalecer la especificación, fortalecer los requisitos y relajar el conocimiento del dominio. Relajar la especificación, relajar los requisitos y fortalecer el conocimiento del dominio.

¿En que modo se escriben las descripciones del dominio?. Optativo. Imperativo. Indicativo.

En un diagrama de casos de uso... una relación "include" implica que el caso de uso incluído se ejecutará opcionalmente cuando se ejecute el caso de uso incluyente. una relación "extend" implica que un caso de uso optativamente añade funcionalidad a otro. una relación "extend" implica que un caso de uso condicionalmente añade funcionalidad a otro. una relación "include" implica que un caso de uso optativamente añade funcionalidad a otro.

¿Cuál es la relación entre escenarios y casos de uso?. 1:1. 1:N. N:1. N:N.

Una serie de casos de uso junto con sus correspondientes descripciones, ¿es una especificación de requisitos?. Si. No.

¿Qué es un caso de uso?. Una abstracción parametrizada de uno o más escenarios. Una colección de escenarios. Una sucesión de pasos específica para llegar a un objetivo concreto. Todas las anteriores.

En el modelo WRSPM, ¿qué es el entorno?. La intersección entre el sistema y el mundo. La parte del mundo relevante a nuestro problema. Los eventos compartidos entre el mundo y el sistema. Todas las anteriores.

En el modelo WRSPM, ¿qué es el entorno?. La intersección entre el sistema y el mundo. La parte del mundo relevante a nuestro problema. Los eventos compartidos entre el mundo y el sistema. Todas las anteriores.

En que modo se escriben los requisitos. Interrogativo. Indicativo. Imperativo. Ninguno de los demás.

¿Cuáles son las fases de la Ingeniería de Requisitos?. Elicitar, analizar, desarrollar, especificar, validar y mantener. Elicitar, especificar y mantener. Obtener, analizar, implementar y testear. Elicitar, analizar, especificar, validar y mantener.

Sobre el ejemplo de monitorización de pacientes que vimos en clase: ¿a que tipo de enventos pertenece la medición del pulso que le manda el sensor al sistema?. e_h. e_v. s_v. s_h.

¿Puede existir un caso de uso sin postcondiciones?. Sí. No.

¿Puede un caso de uso no tener alternativas?. Sí. No. Depende.

¿Puede un caso de uso no tener excepciones?. Sí. No. Depende.