Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
`
Temario
= Introducción
Concepto
Vista Dinámica y Estática
Características de RUP
= Las seis mejores prácticas
= Disciplinas y Flujos de Trabajo
= Fases
= RUP y CMMI
= Conclusiones
¿Qué es un Proceso de Desarrollo de SW?
|
!"
#
$
È
È È
Î %
È
"
È È
È
&
'
Î
"
) *
(
"
Conceptos fundamentales
= Proceso:
Es un marco de trabajo común compuesto por
actividades de trabajo (conjuntos de tareas, hitos,
productos y puntos de garantía de calidad) y
actividades de protección (garantía de calidad,
gestión de configuración y medición) (Pressman
2001).
= Producto:
Es el resultado previsto y consistente del proceso.
Conceptos fundamentales
Ö
!
!
"
Ö
"
Diseño Empaquetamiento
Diagramas de Interacción de diseño (Secuencia y
Colaboraciones)
Diagrama de Clases de diseño
Modelo de Datos
Modelación de
Negocios
Requerimientos
Análisis y Diseño
Implementación
á$
Prueba
Despliegue
Disciplinas de Soporte
Admin. ðonfiguración
Administración
Ambiente
°
°
°
°
°
°
°
°
#
$
Conformación del Equipo
ROLáS ARáAS ASIGNADAS
Gestor del proyecto Establecer Condiciones de Trabajo
Analista del sistema Encontrar Actores y Casos de Uso
Estructurar el Modelo de Casos de
Uso
Arquitecto del sistema Priorizar los Casos de Uso
Efectuar el Análisis Arquitectural
Efectuar el Diseño Arquitectural
Efectuar la Implementación
Arquitectural
Especificador de casos de uso Detallar un Caso de Uso
Diseñador de interfaz de usuario Prototipar una Interfaz de Usuario
Ingeniero de casos de uso Analizar un Caso de Uso Diseñar
un Caso de Uso
Conformación del Equipo
ROLáS ARáAS ASIGNADAS
Ingeniero de componentes Analizar una Clase
Analizar un Paquete
Diseñar una Clase
Diseñar un Subsistema
Implementar un Subsistema
Implementar una Clase
Realizar una Prueba de Unidad
Implementar una Prueba
Integrador del sistema Integrar el Sistema
Ingeniero de pruebas Planear las Pruebas Diseñar las
Pruebas Evaluar las Pruebas
Verificador de integración Realizar una Prueba de Integración
Verificador del sistema Realizar las Pruebas del Sistema
ð r t rí ti
þ
ð
ð
p
Dirigido por Casos de Uso
= Un caso de uso es un fragmento de funcionalidad del
sistema que proporciona un resultado de valor a un
usuario. Los casos de uso modelan los
requerimientos funcionales del sistema.
= Los casos de uso también guían el proceso de
desarrollo (diseño, implementación y pruebas).
= De este modo los casos de uso no solo inician el
proceso de desarrollo sino que le proporcionan un
hilo conductor, que avanza a través de una serie de
flujos de trabajo.
Dependencia entre los Casos de Uso y los
demás modelos
°
á
þ
°
v
$ v
v
v
>
>
>
>
>
>
v
Iterativo e incremental
= Es práctico dividir el esfuerzo de desarrollo de un
proyecto de software en partes mas pequeñas o mini
proyectos. Cada mini proyecto es una iteración que
resulta en un incremento.
= Las iteraciones deben seleccionarse y ejecutarse de
forma planificada. Esta selección se basa en dos
cosas:
= El conjunto de casos de uso que amplían
funcionalidad
= En los riesgos mas importantes que deben
mitigarse
= En cada iteración se identifica y especifica los casos
de uso relevantes, se crea un diseño utilizando la
arquitectura seleccionada como guía, para
implementar dicho caso de uso.
Desarrollo ³en cascada´ tradicional
retarda la reducción del Riesgo
An. Requer.
R
I
Diseño
á
S ðod. & est U.
G
O
est Subs.
est. Sistema
I áMPO
Aplicando cascada iterativamente
Iteración 1 Iteración 2 Iteración 3
R R R
D D D
ð ð ð
I áMPO
u
Diagramas de Casos de Uso
à
à
à
Diagramas de Casos de Uso
'it
I f
r r
i t
t »
V r i
r
i l »
i tr r V t
Diagramas de Clases
Diagramas de Clases
= à
= '
ð
!
"
!
#
$
! %
Diagramas de Clases
*
*
-+
*+
*
*+
â
& $
'()
-+
,
*
Diagramas de Secuencia
Diagramas de Secuencia
= à
=
v " .
`
.
à #
.
Frambuesa
Crear Bebida :Jugo Natural
]x N}
Ingresar Venta
.
ð ð v v ð
Diagramas de Colaboración
Diagramas de Colaboración
à
! v " .
! .
! à #
.
Bucarest
:Sistema de
Bodega
1.5 Pedir Bebida
. 1.w Pedir Bebida
Diagramas de Actividades
Diagramas de Actividades
à
!
"
!
! %
r iti
r
i t
V li
Ir V t C ti i ]
Ii i
i
i t
i tr V t
v
.
!
!
! ' ,
"
Diagrama de Estados
Inicio
INGRáSADO SáR IDO
servir
ðANðáLADO
ðOBRADO PáRDIDO
a Pedidos
Anulados a Pedidos A Pedidos
ðobrados
Perdidos
Diagrama de Componentes
Diagrama de Componentes
à
v (
O
! .
! /"' O O
!
#
'
` )
'
("0"# # "1'#
)
Ba rm e n
´
V e nde dor
j
S is te m a de
´ l
Bode ga
Touc hS c re e n
´
V e nta
´
l
BDP ub
Diagrama de Distribución
Diagrama de Distribución
à v
% '
v ð
'2
3 4 2
! '
!
! $
! 5
! "
Clie nte Touc hS c re e n
S e r idor Bode ga
´ ctl
´J
:Touc hS c re e n
:Bode gue ro
S e r idor P ub
´J
Ba r e n :V e nde dor
S is te a de
Bode ga
´
:V e nta
S e r idor BD
´ rcl
:BDP ub
Diagrama de Distribución
Modelos y Flujos de Trabajo
Seis Mejores
Prácticas
Seis ³Mejores Prácticas´
Administrar requerimientos
Desarrollar Arquitecturas
erificar Modelizar
Iterativamente ðalidad isualmente Basadas en
ðomponentes
ðontrolar ðambios
Desarrollo Iterativo
El software moderno es complejo y novedoso.
No es realista usar un modelo lineal de
desarrollo como el de cascada.
Un proceso iterativo permite una comprensión
creciente de los requerimientos a la vez que se
va haciendo crecer el sistema.
RUP sigue un modelo iterativo que aborda las
tareas más riesgosas primero.
Con esto se logra reducir los riesgos del
proyecto y tener un subsistema ejecutable
tempranamente.
Desarrollo Iterativo
= Cada iteración resulta en un release ejecutable
Requerimientos
Planeamiento Implementación
Inicial Ambiente de
Administración
Evaluación
Prueba
Distribución
Administración de requerimientos
RUP describe cómo:
± Obtener los requerimientos
± Organizarlos
± Documentar requerimientos de funcionalidad y
restricciones
± Rastrear y documentar decisiones
± Captar y comunicar requerimientos del negocio
Req. w0
Obligatorio Alto
Alto $
Arquitecturas basadas en componentes
El proceso se basa en diseñar tempranamente una
arquitectura base ejecutable.
Mecanismos de interfaces
ð
ð|
Modelamiento Visual
Modelamiento visual de la estructura y el
comportamiento de la arquitectura y los
componentes.
Bloques de construcción:
± Permiten la comunicación en el equipo de
desarrollo
± Permiten analizar la consistencia:
entre las componentes
entre diseño e implementación
UML es la base del modelamiento visual de
RUP.
Modelamiento Visual
= Diagramas de Casos de Uso
= Diagramas de Clases
= Diagramas de Estados
= Diagramas de Componentes
= Diagramas de Implementación
Subsistemas
Modelización isual
Clases
eleva el nivel de
abstracción
Código
Verificación de la Calidad
ð
Necesidades
|
|
Control de cambios
Administración de
configuración y cambios
"
ð
!
_
Disciplinas y
Flujos de Trabajo
Disciplinas
Una disciplina es una colección de actividades
relacionadas vinculadas con un área específica
del proyecto.
Este agrupamiento de actividades en disciplinas
es principalmente para facilitar la comprensión
del proyecto desde la perspectiva tradicional del
modelo en cascada.
Flujo de Trabajo
Un flujo de trabajo describe la secuencia en que
se realizan las actividades en una disciplina,
quienes la realizan (trabajadores) y que
artefactos producen..
Disciplinas de Proceso
M
: describe la estructura y la
dinámica de la organización.
: describe el método basado en casos de uso
para extraer los requisitos.
: describe las diferentes vistas
arquitectónicas.
: tiene en cuenta el desarrollo de
software, la prueba de unidades y la integración.
: describe los casos de pruebas, los
procedimientos y las métricas para evaluación de
defectos.
: cubre la configuración del sistema
entregable.
Disciplinas de Soporte
M
: controla los cambios
y mantiene la integridad de los artefactos de un
proyecto.
: describe varias estrategias
de trabajo en un proceso iterativo.
: cubre la infraestructura necesaria para
desarrollar un sistema.
Disciplinas y Flujos de Trabajo
Disciplinas
de Proceso
Disciplinas
de Soporte
Modelamiento de Negocio
°
#
$
%
" %
°
#
"
"
Diseño
= Durante el diseño modelamos el sistema y su
arquitectura para que soporte los requisitos
funcionales y no funcionales. Una entrada
esencial al diseño es el modelo de análisis.
= El diseño es el centro de atención al final de la
fase de elaboración y comienzo de las
iteraciones de construcción .
Diseño
!
" !þ
!
!&
'
(
á&
)
*
+
+
&
!
!
!
!"
Diseño
!
" !þ
!
!"
þ
"
,
þ
" ,
-
#
) -
# ,
)
þ
) )
Diseño - Workflow
Arquitecto Ing de ðasos Ing de ðomponentes
de Uso
Diseño
!
! #
þ
°
#
$
%
þ %
°
#
. þ
°
Implementación
= Se inicia con el resultado del diseño y se
implementa el sistema en término de
componentes, es decir, ficheros de código
fuente, scripts, ficheros de código binario,
ejecutables, y similares.
= Es el centro durante las iteraciones de
construcción.
= Aunque también se realiza durante:
La fase de elaboración, para crear la línea base
ejecutable de la arquitectura
La fase de transición para tratar defectos tardíos.
Implementación
!
! #
þ
°
#
°
#
°
#
°
°
Implementación - Workflow
Arquitecto Integrador del Ingeniero de
Sistema ðomponentes
Prueba
= Los objetivos de la prueba son:
Planificar las pruebas necesarias en cada
iteración, incluyendo las pruebas de
integración y las pruebas de sistema.
Diseñar e implementar pruebas creando:
= Casos de prueba (especifican qué probar),
Procedimientos de prueba (especifican cómo
realizar las pruebas),
= Componentes de prueba para automatizar las
pruebas.
Realizar las pruebas.
Prueba
þ
!
á)
°
#
°
#
þ
°
#
°
#
. þ
Fases
Fase de Inicio
= Durante la fase de inicio se desarrolla la
descripción del producto final, y se presenta el
análisis del negocio.
= Esta fase responde las siguientes preguntas:
Cuáles son las principales funciones del sistema para
los usuarios mas importantes?
Cómo podría ser la mejor arquitectura del sistema?
Cuál es el plan del proyecto y cuanto costará
desarrollar el producto?
= En esta fase se identifican y priorizan los
riesgos mas importantes.
Fase de Inicio
= Los objetivos son:
Poner en marcha el proyecto
Desarrollar el análisis del negocio hasta
justificar la puesta en marcha plan de
proyecto
Para ello
Esbozar una arquitectura
Mitigar los riesgos
Análisis inicial del negocio (coste, agenda,
recuperación de la inversión)
Fase de Inicio
$
)
# *
#
* /
2
/
/
(2
#
,
/
/
&
°
#
/
,
!
0101 $
"
'
Fase de Inicio
*
%
`
+
,
,
Fase de Elaboración
= Durante la fase de elaboración se especifican
en detalle la mayoría de los casos de uso del
producto y se diseña la arquitectura.
= Las iteraciones en la fase de elaboración:
Establecen una firme comprensión del problema a
solucionar.
Establece un plan detallado para las siguientes
iteraciones.
Elimina los mayores riesgos.
= El resultado de esta fase es la línea base de la
arquitectura.
Fase de Elaboración
= Los objetivos son:
Recopilar la mayor parte de los requisitos
definiéndolos como casos de uso
Establecer una arquitectura sólida para guiar las
fases posteriores
Continuar la observación y control de los riesgos
críticos
Completar el plan de proyecto
Para ello
Se toman decisiones considerando la
comprensión global del sistema: ámbito, requisitos
funcionales y no funcionales
Fase de Elaboración
%
+
+ ,
(2
*
/ 3á )
4
/ 3á
4
/ 3
#5
,
4
/ 3á "
)
4
Fase de Construcción
En esta fase todas las componentes
restantes se desarrollan e incorporan al
producto.
Todo es probado en profundidad.
El énfasis está en la producción eficiente y no
ya en la creación intelectual.
Puede hacerse construcción en paralelo,
pero esto exige una planificación detallada y
una arquitectura muy estable.
Fase de Construcción
= Los objetivos son:
Línea base de la arquitectura crece hasta convertirse
en el sistema completo
Riesgos reducidos o rutinarios
Implementación de los casos de uso
Prototipo
Para ello
A través de sucesivas iteraciones e incrementos
se desarrolla un producto software, listo para
operar, éste es frecuentemente llamado versión
beta
Fase de Construcción
%
Manuales de usuario.
+
+ ,
Para ello
Las iteraciones en esta fase continúan
agregando características al sw.
El equipo se encuentra ocupado en
corregir y extender la funcionalidad del
sistema desarrollado en la fase anterior.
Fase de Transición
El objetivo es traspasar el software desarrollado a la
comunidad de usuarios.
Una vez instalado surgirán nuevos elementos que
implicarán nuevos desarrollos (ciclos).
Incluye:
± Pruebas Beta para validar el producto con las
expectativas del cliente
± Ejecución paralela con sistemas antiguos
± Conversión de datos
± Entrenamiento de usuarios
± Distribuir el producto
Fase de Transición
*
%
+
+ ,
Condiciones de éxito:
± Se han alcanzado los objetivos fijados en la fase
de Inicio ?
± El usuario está satisfecho ?
RUP y CMMI
Modelo ðMMI