Workflow de requisitos:

1) Realice un gráfico indicando actividades, trabajadores y artefactos implicados en el workflow de Requisitos

planteado por el PUD. (10 pts.) (EL SEGUNDO GRAFICO ESTA EN LA DIAPOSITIVA, OSEA QUE ESTA
BIEN, habri que hacer los dos porque uno muestras los artefactos y el otro las actividades) o combinarlos

2) Explicar cómo se lleva a cabo el ciclo de vida del WF de requisitos en el PUD.

3) Indique si las siguientes afirmaciones son verdaderas o falsas (10 pts.)

V 1. Un caso de uso describe una secuencia de acciones requeridas para realizar alguna
tarea o conseguir alguna meta de un actor o una organización.
F 2. Los CU adicionales son solamente los de inclusión y los de extensión.
V 3. Un diagrama de CU constituye la vista estática y externa del sistema de información.
V 4. El conjunto de CU muestran el dominio del problema
F 5. La descripción de un CU debe hacerse teniendo en cuenta la tecnología de
implementación.
F 6. Las plantillas de descripción de CU son modelos formales de UML
V 7. Las operaciones del sistema de información que el software debe ejecutar se reflejan
descripciones de los CU
V 8. Los CU adicionales surgen cuando sus operaciones están duplicadas en otros CU p
las operaciones son complejas y largas.
V 9. Un actor es un rol que estimula/solicita acciones del sistema y recibe
reacciones/eventos de este.
F 10. Un actor es siempre un trabajador del negocio.
3) Indique si las siguientes afirmaciones son verdaderas o falsas: (30 pts)

V 1. Un caso de uso describe una secuencia de acciones requeridas para realizar alguna tarea o conseguir
alguna meta de un actor o una organización.
V 2. Un caso de uso es un conjunto de escenarios de éxito o fracaso.

V 3. Los casos de uso son una forma de especificar requerimientos funcionales.

F 4. Un diagrama de casos de uso muestra todos los requisitos funcionales y no funcionales que debe
brindar el sistema.
F 5. Los casos de uso adicionales son solamente los de inclusión y los de extensión.

V 6. El conjunto de casos de uso muestran el dominio del problema.

F 7. La descripción de un caso de uso debe hacerse teniendo en cuenta la tecnología de implementación.

F 8. Las plantillas de descripción de casos de uso son modelos formales de UML.

V 9. Las operaciones del sistema de información que el software debe ejecutar se reflejan en las
descripciones de los casos de uso.
V 10. Los casos de uso adicionales surgen cuando sus operaciones están duplicadas en otros casos de uso o
las operaciones son complejas y largas.
V 11. Un actor es un rol que estimula/solicita acciones del sistema y recibe reacciones/eventos de éste.

F 12. Un actor es siempre un trabajador del negocio.

F 13. Casos de uso 2.0 es una práctica escalable y ágil que emplea los casos de uso para capturar
un conjunto de requisitos y conducir el desarrollo en cascada de un sistema que los realice.
V 14. La porción del caso de uso es una o más historias seleccionadas de un caso de uso para
formar un elemento de trabajo que es de valor claro para el usuario.
V 15. Las porciones de casos de uso pueden incluir opcionalmente los casos de prueba en su
especificación.

4) Complete el siguiente cuadro sobre Casos de Usos del SI (10 pts.)

Tipo de CU Definición Ejemplo

Esencial Describen la funcionalidad Registrar Venta

principal o esencial con la que
tiene que cumplir el sistema.
Comprenden los principales
procesos que debe ejecutar el
 sistema de información.

Soporte Comprenden la funcionalidad Registrar Provincia, Ciudad, etc.

que surge a partir de analizar
aquello que se necesita para
que puedan funcionar los CU
esenciales.

De inclusión Es una relación desde un CU Registrar Alojamiento incluye a

base a un CU de inclusión, Consultar Habitación
donde el comportamiento
definido en el CU de inclusión es
explícitamente insertado en el
comportamiento definido en el
CU base. La relación no es
opcional, por ello, al ejecutarse
el CU base, siempre se ejecutará
el CU de inclusión.

De extensión Es una relación desde un CU de Registrar Cliente (CU de

extensión a un CU base, donde extensión) extiende a Registrar
el comportamiento definido en Venta (CU base)
el CU de extensión puede ser
insertado en el comportamiento
definido por el CU base. La
ejecución del CU es opcional, al
ejecutarse el CU base, el CU de
extensión sólo se ejecutará bajo
ciertas condiciones.

Generalización Es una relación de un CU hijo a Registrar Venta de Contado y

un CU padre, donde el hijo Registrar Venta con Tarjeta
hereda todo el comportamiento extienden a Registrar Venta
y características descriptas por
el padre.

5) Explicar con un ejemplo la forma en la que se derivan los requerimientos de un sistema de información a partir
de un modelo de negocio.

DERIVAR LOS REQUISITOS FUNCIONALES

A PARTIR DEL MODELO DEL NEGOCIO

En la realización de los casos de uso del negocio, se obtienen las actividades que serán objeto de
automatización. Estas actividades no son exactamente los requisitos funcionales, pero sí son el punto de partida
para identificar qué debe hacer el sistema.

Los requisitos funcionales no alteran la funcionalidad del producto, esto quiere decir que se mantienen
invariables sin importarles con que propiedades o cualidades se relacionen. Los requisitos no funcionales
también añaden funcionalidad al producto, pues hacen que un producto sea fácil de usar, seguro, o interactivo
demanda cierta cantidad de procesamiento. Sin embargo, la razón fundamental de que esta funcionalidad sea
parte del producto es brindarle a este las características deseadas.

Por ejemplo, podrían definirse como requisitos funcionales, entre otros los siguientes:

1. Registrar solicitud de exposición de obras de arte en una galería.

2. Optimizar un grafo usando el escalador de colinas estocástico.

3. Generar un reporte con todos los estudiantes que cumplan determinadas condiciones.

4. Enviar correo electrónico.

5. Leer de un barómetro las mediciones de presión atmosférica.

6. Consultar en el sistema automatizado de recursos humanos la categoría docente de un profesor dado.

En la figura 2 se muestra al diagrama de actividades3,4 del proceso de negocio "Atender solicitud de proyecto".
Resaltadas se encuentran las actividades que, después del análisis del sistema actual, se propone sean objeto de
automatización. A partir de aquí podrían derivarse los siguientes requisitos funcionales:

1. Determinar viabilidad técnica de un proyecto

2. Determinar viabilidad económica de un proyecto.

3. Aprobar la ejecución de un proyecto.

6) ¿Qué relación existe entre los requerimientos de un sistema de información y el diagrama de clases?

Prototipos de interfaz de Usuario:

Relación entre los Requerimientos de un Sistema y el Diagrama de Clases: Los

requerimientos de un SI que descubiertos son los más relevantes del dominio, y estos van a
pasar a ser clases del diagrama de clase.

7) Señala la opción correcta (5 pts.)

¿Cuáles son las ventajas de utilizar un desarrollo de prototipos?

a. Facilitar la visualización de requerimientos inconsistentes y/o incompletos

b. Se dispone rápidamente de un sistema que funcione y demuestre la funcionalidad de la aplicación
c. Todas las anteriores son correctas

Los prototipos evolutivos son recomendables cuando:

a. Se piensen desarrollar prototipos de baja tecnología

b. El sistema es difícil o imposible de especificar
c. Hay que verificar el diseño antes de la construcción del sistema

Los prototipos desechables son principalmente utilizados para:

a. Ayudar a desarrollar los requerimientos del sistema

b. Realizar la validación del diseño
c. Probar la factibilidad del proyecto de sistemas.

En la construcción de prototipos para validar requerimientos es recomendable:

a. Un único prototipo para todo el sistema

b. Realizar varios prototipos, quizás uno para cada actor
c. Es más común utilizar otras técnicas de validación.
8) Realiza un cuadro indicando las diferencias entre un prototipo desechable y uno evolutivo.

(SE podría agregar mas del resumen como las ventajas y desventajas)

Patrones evolutivos El prototipo desechable

El prototipo evolutivo entrega a los usuarios El prototipo desechable valida o deriva los
finales un sistema funcionando. Se usa con los requerimientos del sistema. Se usa con los
requerimientos que mejor se comprenden. requerimientos que no se conocen bien.
Período de vida corto.

Workflow de análisis:

9) Indique si las siguientes afirmaciones son verdaderas o falsas (10 pts.)

F 1. Esta descripto en el lenguaje del usuario

V 2. Proporciona una vista interna del sistema
V 3. Es utilizado fundamentalmente por los desarrolladores para comprender como
debería darse forma al sistema.
F 4. Define realizaciones de casos de uso y cada una de ellas representa el diseño de un
CU
V 5. Una clase de análisis puede ser: de interfaz, de entidad y de control.
F 6. Una clase de análisis representa el tratamiento de los requisitos funcionales y de los
no funcionales
F 7. Una realización de un CU posee una descripción textual del flujo de sucesos,
diagramas de clases que muestran sus clases de dominio participantes y diagramas
de interacción que muestran la realización del CU en términos de interacción entre
los objetos de las clases de análisis.
V 8. Un diagrama de comunicación muestra relaciones estructurales entre objetos
conectados por medio de enlaces que especifican los mensajes que envían y reciben
los objetos.
V 9. Los paquetes de análisis se utilizan para organizar los artefactos del modelo de
análisis en piezas manejables. Puede contener clases de análisis, realizaciones de
CU y otros paquetes de análisis.
F 10. Hay que tratar que los paquetes sean altamente cohesivos (es decir, las
dependencias de unos con otros deberían ser mínimas) y débilmente acoplados
(es decir sus contenidos deberían estar fuertemente relacionados)

Patrones:
10) ¿Qué son los patrones? ¿Qué características debe poseer un buen patrón? (2 pts.)

PATRONES: Un patrón es una idea que ha sido útil en un contexto práctico, y que probablemente lo
sea en otros. Un patrón es una solución probada a un problema dentro de un contexto.
UN PATRÓN:

 Resuelve un problema.
 Es un concepto probado.
 La solución no es obvia.
 Describe una relación: no sólo describe módulos, sino estructuras internas.
CARACTERÍSTICAS DE UN BUEN PATRÓN:
UN BUEN PATRÓN:
  Plantea una solución al problema.
 Provee conceptos.
 Permite derivar soluciones desde primeros principios.
 Describe relaciones,
 Debe tener en cuenta al componente humano.

11) Mencione que tipos de patrones ha visto y cuál es la utilidad de cada uno (3 pts.)

Patrones Transaccionales:Los patrones transaccionales son aquellos patrones que tienen un

jugador de transacción o tienen jugadores que comúnmente juegan con un jugador de
transacción.
Los patrones de transacciones son:

1. Actor-Participante. (persona – estudiante)

2. Participante-Transacción. (cliente –venta)
PATRONES DE AGREGACIÓN:
Los Patrones de agregación son:
1. Contenedor-Contenido.
2. Contenedor-Detalle de contenedor.
PATRONES DE PLAN:
1. Plan-Paso.
2. Plan-Ejecución de plan.

PATRONES DE CASO DE USO: Estos patrones examinan los problemas que enfrentan las personas
al escribir casos de uso y describen las soluciones simples, elegantes y probadas para los problemas
específicos de la escritura de casos de uso en proyectos reales.
Los objetivos son proporcionar un vocabulario paro discutir y compartir estas propiedades con otras
personas, para ofrecer consejo para escribir y organizar eficazmente los casos de uso, y para dar
algunos 'diagnósticos’ para la evaluación de casos de uso.

Categoría de los Patrones de los Casos de Usos:

 Patrones estructurales: describen los componentes básicos de los CU, cómo deberían estar
organizados y ofrecen criterios para juzgar su uso.
 Patrones de desarrollo: describen características de prácticas de escritura de CU probadas y
ofrecen criterios para medir la calidad del proceso de escritura.

12) ¿Qué indica el patrón fundamental para la construcción del modelo de objetos del dominio?

Patrón fundamental para la construcción del modelo de objetos del dominio:El patrón
fundamental indica la plantilla que todos los patrones siguen para la construcción del
modelado de objetos del dominio.

13) Elija un sistema de información específico y ejemplifique el uso de los siguientes patrones:

a. VerbPhraseName
 Nombrar el caso de uso con una frase que contenga un verbo active que represente la meta del actor
primario.

b. TechnologyNeutral

Escriba cada paso en una manera tal que la tecnología quede expresada de una manera neutral, es decir sin
referenciar tecnología alguna.

c. ClearCastOfCharacters

Identifique a los actors con los cuales el Sistema debe interactuar y el papel que cada actor juega con
respecto al Sistema. Claramente describa cada uno.

d. ScenarioPlusFragments

Escriba la línea de historia de éxito como un scenario simple sin consideración de los posibles fracasos.
Luego agregue los fragmentos de historia que muestren qué alternativas pueden ocurrir.

e. ActorIntentAccomplished

Escriba cada paso para mostrar claramente qué actor está realizando la acción, y lo que el actor logra.

Sistema Biblioteca:

VerbPhraseName: Registrar Socio (Bien) – Socio Registrado (Mal)

TechnologyNeutral: El usuario registra un nuevo socio (Bien) – El usuario hace click en el sistema para indicar
que se está registrando un socio.

ClearCastOfCharacters: Encargado de Préstamo: (PONER QUE HACE)

ScenarioPlusFragments: Éxito: El Socio se registró correctamente asignándole un número de socio y una

categoría. Alternativas: El Recepcionista no confirma el registro, etc.

ActorIntentAccomplished: El Encargado de Préstamo ingresa el nombre del socio para buscarlo (Bien) – El EP
busca al socio