TP3 - Mta3 11-01-13 PDF

TALLER DE PROYECTOS 3 UPC Online
1
2
3
4
¿Qué causó el problema?

Una causa importante del problema fue la priorización inadecuada de los
requerimientos y casos de uso.
¿Cómo se pudo evitar?

Se pudo evitar revisando la priorización que se pudo haber realizado anteriormente,
considerando la importancia del requerimiento desde el punto de vista del usuario y del
proyecto.
¿Qué mecanismos de priorización de requerimientos conocemos?

En las siguientes diapositivas, descubriremos un elemento de priorización que
complementará al de casos de uso aprendido anteriormente.
El objetivo es priorizar efectivamente aquello que sea de más valor para el proyecto.
5
6
Como ya conocemos, un caso de uso contiene diferentes componentes, tales como un

Flujo Básico, Flujos Alternos y Sub-Flujos. Todos ellos representan los diferentes caminos
por los que puede derivarse la interacción entre el actor y el sistema.
Se denominan “Escenarios de un Caso de Uso” a las diferentes variantes o

combinaciones entre flujos que pudieran presentarse.
Por ejemplo, la imagen muestra todos los posibles flujos especificados en un

determinado caso de uso. Como observamos, el ejemplo cuenta con un Flujo Básico y
cuatro posibles Flujos Alternos.
7
Esta imagen muestra un posible escenario, en el cual el Flujo Básico se ejecuta sin
derivar la secuencia de pasos a ningún Flujo Alterno.
8
Otro posible escenario será el que se presentará cuando durante la ejecución del Flujo
Básico, se ejecuta el Flujo Alterno 1, y luego finaliza el caso de uso.
9
Un tercer escenario sería el que se observa en la imagen. En éste, se ejecutan tanto el

Flujo Alterno 1 como el 3, el cual lleva el control hacia un paso atrás del Flujo Básico,
luego del cual el caso de uso continua hasta su finalización.
10
Finalmente, podemos observar un cuarto escenario, en el cual se ejecutan los flujos

alternos uno y cuatro. En este caso, el Flujo Alterno cuatro finaliza el caso de uso
11
12
13
14
Revisaremos cada uno de los dos criterios mencionados en las siguientes diapositivas.
15
El impacto en la arquitectura es independiente del impacto en el negocio:

• Un escenario o caso de uso crítico para el negocio puede tener impacto débil en la
arquitectura.
• Un escenario o caso de uso secundario en el negocio puede tener alto impacto en la
arquitectura.
RUP propone 3 posibles atributos para describir el impacto:

• Ninguno: cuando el caso de uso o escenario no genera cambios a la arquitectura.
• Extiende: cuando el caso de uso o escenario requiere adiciones a la arquitectura
inicialmente planteada.
• Modifica: cuando el caso de uso o escenario requiere modificar la arquitectura
vigente.
16
Riesgo técnico a mitigar:

Constituye otro criterio adicional de priorización
17
18
19
20
21
En las siguientes diapositivas revisaremos algunas buenas prácticas de integración.

Específicamente, nos enfocaremos en las recomendaciones del RUP, las cuales
revisaremos detenidamente.
22
La planificación de la integración del sistema involucra cuatro actividades principales, las

cuales se deben realizar al menos una vez por cada iteración del proyecto:
- Identificar subsistemas.
- Definir Build sets.
- Definir una serie de Builds.
- Evaluar el Plan de Integración.
23
El plan de la iteración debe mencionar a todos los casos de uso y escenarios que se
deben implementar en la presente iteración. Es necesario identificar qué sub-sistemas
participan en los casos de uso y escenarios de la iteración actual. Para ello, se deben
revisar cuidadosamente artefactos de realización de los casos de uso, tales como
diagramas de secuencia, diagramas de colaboración y otros. Adicionalmente, es
necesario identificar qué otros sub-sistemas son necesarios para lograr la compilación,
es decir, crear builds.
24
Para facilitar la integración de sistemas, especialmente en sistemas grandes, es

recomendable definir build sets o conjuntos de sub-sistemas para compilación.
Para ello, se agrupan sub-sistemas que tienen estrecha relación, desde el punto de vista
de integración. Según RUP, se considera que un grupo de sub-sistemas se encuentran
estrechamente relacionados cuando no tiene sentido compilarlos de manera
independiente sino en conjunto.
Como se observa en la imagen, los build sets se traslapan.
25
Se refiere a la secuencia de builds necesarios para integrar el sistema de manera

incremental. Típicamente, se realiza desde las capas inferiores hacia las superiores
(estrategia denominada comúnmente bottom-up), en la representación de capas de
subsistemas del modelo de implementación.
Para cada build es necesario definir los sub-sistemas que se deben incluir, y cuáles otros
deberán encontrarse disponibles como stubs. En la imagen del ejemplo, se han definido
tres builds.
26
Veamos algunas recomendaciones a ser tomadas durante las revisiones:
27
28
Verifiquemos lo que hemos aprendido, respondiendo a las siguientes preguntas. Por

favor, tómese su tiempo en identificar la respuesta, antes de pasar a las siguientes
diapositivas.
29
30
Veamos la respuesta a la primera pregunta:
31
Respondamos otra pregunta.
32
33
Veamos la respuesta a la segunda pregunta:
34
35
36
37

TP3 - Mta3 11-01-13 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TP3 - Mta3 11-01-13 PDF

Uploaded by

Copyright:

Available Formats

TALLER DE PROYECTOS 3 UPC Online

¿Qué causó el problema?

¿Cómo se pudo evitar?

¿Qué mecanismos de priorización de requerimientos conocemos?

Como ya conocemos, un caso de uso contiene diferentes componentes, tales como un

Se denominan “Escenarios de un Caso de Uso” a las diferentes variantes o

Por ejemplo, la imagen muestra todos los posibles flujos especificados en un

Un tercer escenario sería el que se observa en la imagen. En éste, se ejecutan tanto el

Finalmente, podemos observar un cuarto escenario, en el cual se ejecutan los flujos

El impacto en la arquitectura es independiente del impacto en el negocio:

RUP propone 3 posibles atributos para describir el impacto:

Riesgo técnico a mitigar:

En las siguientes diapositivas revisaremos algunas buenas prácticas de integración.

La planificación de la integración del sistema involucra cuatro actividades principales, las

Para facilitar la integración de sistemas, especialmente en sistemas grandes, es

Como se observa en la imagen, los build sets se traslapan.

Se refiere a la secuencia de builds necesarios para integrar el sistema de manera

Veamos algunas recomendaciones a ser tomadas durante las revisiones:

Verifiquemos lo que hemos aprendido, respondiendo a las siguientes preguntas. Por

Veamos la respuesta a la primera pregunta:

Respondamos otra pregunta.

Veamos la respuesta a la segunda pregunta:

You might also like