|
 


 

`

 

  


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?

= Define Quién debe hacer Qué, Cuándo y

Cómo debe hacerlo

|
  
 

  
 
   
 

No existe un proceso de software universal.

Las características de cada proyecto (equipo
de desarrollo, recursos, etc.) exigen que el
proceso sea configurable
 El Problema




Î   


 


 






!" 
 
  
 



   

 #
$

È
È È
Î
 % 
 
 


È
 
 

" 
 È È

      
 
 È

  &
'
  
 

Î
 
 
" 


 ) *




  (

   
"


  
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

= Ciclo de vida del software:

Es el conjunto de fases por las que pasa el
software, que abarcan desde su creación u
origen, hasta su eliminación o liquidación formal.
= Modelo de desarrollo:
También denominado v
 
  .
Estrategia de desarrollo basada en el ciclo de
vida, naturaleza del proyecto y metodología, que
determina las características específicas del
proceso (Pressman 2001).
Rational Unified Process
³RUP es un marco de trabajo genérico
que puede especializarse para una
variedad de tipos de sistemas,
diferentes áreas de aplicación, tipos de
organizaciones y diferentes tamaños
de proyectos´.

JACOBSON, Ivar; BOOCH, Grady y

RUMBAUGH, James 2000 El proceso
unificado de desarrollo de software,
Addison Wesley
 Noción de Proceso


  
 
  

   
    
 Ö




    
|
Ö


    






 


  þ

 

 
 
 




 


 


 
   

 



 


 



 

 Ö



  !

   !   
 

"
 Ö



 



 

"

Rational Unified Process

= Creado por los 3 amigos: Grandy Booch (creador de

³The Booch Method´), Ivar Jacobson e James
Rumbag (creador de ³Object Modeling Technique´ =
OMT)
= Aparece por primera vez en Junio de 1998 con el
nombre de Rational Unified Process 5.0 (RUP)
= Fue puesto a disposición pública entre finales de
1998 e inicios de 1999.
= Centrado en tres Puntos:
Personas
Procesos
Herramientas y métodos
Evolución de RUP

Estructura de RUP
= El proceso puede describirse en dos dimensiones, o
a lo largo de dos ejes:
El eje horizontal representa p 
y muestra el
aspecto dinámico del proceso, expresado en
términos de   , , p , y p.
El eje vertical representa el aspecto estático del
proceso; como está descrito en términos de
disciplinas: p


, pp , p
 y
 
p .
El Ciclo de Vida del Software en RUP
El Ciclo de Vida del Software en RUP
El Ciclo de Vida del Software en RUP
El Ciclo de Vida del Software en RUP
Relación entre Diagramas UML
y Disciplinas de RUP
Disciplina Diagrama
Requerimientos Diagramas de Casos de Uso

Análisis Refinamiento y documentación de los casos de usos

Definición preliminar de clases y
Diagramas de Interacción (Secuencia y Colaboraciones)

Diseño Empaquetamiento
Diagramas de Interacción de diseño (Secuencia y
Colaboraciones)
Diagrama de Clases de diseño
Modelo de Datos

Implementación Diagrama de Componentes

Diagrama de Despliegue
RUP Visión Estática
= En su visión estática, el modelo RUP está
compuesto por:
Roles: analista de sistemas, diseñador,
diseñador de pruebas, roles de gestión y roles
de administración.
Actividades: RUP determina el trabajo de
cada rol a través de actividades. Cada
actividad del proyecto debe tener un propósito
claro, y se asigna a un rol específico. Las
actividades pueden tener duración de horas o
de algunos días; y son elementos base de
planificación y progreso.
RUP Visión Estática
= En su visión estática, el modelo RUP está
compuesto por:
Artefactos: Son los elementos de entrada y
salida de las actividades. Son productos
tangibles del proyecto. Las cosas que el
proyecto produce o usa para componer el
producto final (modelos, documentos, código,
ejecutables«)
_lujos de trabajo: son el ³pegamento´de los
roles, actividades, artefactos y disciplinas, y
constituyen la secuencia de actividades que
producen resultados visibles.
RUP Visión Estática
= En su visión estática, el modelo RUP está
compuesto por:
Disciplinas: son ³contenedores´ empleados
para organizar las actividades del proceso.
RUP comprende 6 disciplinas de proceso y 3
de soporte.
Proceso: modelado del negocio, requisitos,
análisis y diseño, implementación, pruebas y
desarrollo.
Soporte: gestión de proyecto, gestión de
configuración y cambio, y entorno.
RUP Visión Dinámica
= En su visión dinámica, la visión de la estructura del ciclo
de vida RUP se basa en un desarrollo iterativo, jalonado
por hitos para revisar el avance y planear la continuidad
o los posibles cambios de rumbo.

= Cuatro son las fases que dividen el ciclo de vida de un

proyecto RUP:
1.- Inicio. Es la fase de la idea, de la visión inicial de
producto, su alcance. El esbozo de una arquitectura
posible y las primeras estimaciones. Concluye con el
³hito de objetivo´.
2.- álaboración. Comprende la planificación de las
actividades y del equipo necesario. La especificación
de las necesidades y el diseño de la arquitectura.
Termina con el ³hito de Arquitectura´.
RUP Visión Dinámica
3.- ðonstrucción. Desarrollo del producto hasta que
se encuentra disponible para su entrega a los
usuarios. Termina con el ³hito del inicio de la
capacidad operativa´.
w.- ransición. Traspaso del producto a los usuarios.
Incluye: manufactura, envío, formación, asistencia y el
mantenimiento hasta lograr la satisfacción de los
usuarios. Termina con el ³hito de entrega del
producto´.
 RUP Visión Dinámica
_ 

Disciplinas de Procesos #
á 
  
   

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
Gestor del proyecto
Analista del sistema
Arquitecto del sistema
Especificador de casos de uso
Diseñador de interfaz de usuario
Ingeniero de casos de uso
ARáAS ASIGNADAS
Establecer Condiciones de Trabajo
Encontrar Actores y Casos de Uso
Estructurar el Modelo de Casos de
Uso
Priorizar los Casos de Uso
Efectuar el Análisis Arquitectural
Efectuar el Diseño Arquitectural
Efectuar la Implementación
Arquitectural
Detallar un Caso de Uso
Prototipar una Interfaz de Usuario
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

= Las primeras iteraciones reducen los principales riesgos

= Cada iteración produce una versión ejecutable, un
incremento adicional al sistema
= Cada iteración incluye integración y test
Centrado en la Arquitectura
= La arquitectura se describe mediante
diferentes vistas del sistema en construcción.
Incluye aspectos estáticos y dinámicos.
= La arquitectura es una vista del diseño
completo con las características más
importantes resaltadas, dejando de los
detalles de lado.
= La arquitectura debe permitir el desarrollo de
todos los casos de uso requeridos
actualmente y a futuro, y los casos de uso
deben encajar en la arquitectura.
Organización de Modelos
Vistas de UML: Arquitectura w + 1
= †

=   

Diagramas de Casos de Uso

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  

 

! 


"  "  


=  
v
"     .
` 
   
.
à  
 #   

= È  
 (   

)# 
   $ (    

)
 Diagramas de Secuencia
.

Pepe Interfaz Motor BD de

:Barmen Barmen Venta Ventas

Ingresar Datos Venta

  
 
Confirmar Venta
 .
Ejecutar Venta  
123w5 :Venta
Crear Venta

.
Frambuesa
Crear Bebida :Jugo Natural

]x N}

Ingresar Venta

  
 .

  ð    ð      v
     v
   ð 
Diagramas de Colaboración
 Diagramas de Colaboración
 à    
  
 

 v  

  "

 


  
! v
"     .
! 
    .
! à  
 #   

 È  
 (    )#


   $ (     
)
Diagramas de Colaboración

.
Bucarest
:Sistema de
Bodega
1.5 Pedir Bebida

. 1.w Pedir Bebida

Pepe :Barmen Comunicador Bodega Interfaz Bodega

1 Vender Jugo Natural 1.3 Pedir Bebida

1.1 Vender Jugo Natural

1.2 Calcular Cantidad Bebida

Interfaz Barmen Motor Venta El cálculo dió la

cantidad bajo la mínima
permitida - hay que pedir
bebida de la bodega

 
Diagramas de Actividades
 Diagramas de Actividades
 à    
  
 
 

 v 
  
   

  
!    
" 

 
! 

   
! % 
  
      

 È 
      

     
 Diagramas de Actividades
 

ð i  i] 
ir 
i

t  i  íi 
< 



r iti

 r

 i t

V li
Ir
 V
t C ti  
i  ]

Ii  i
i

i t


i tr V
t

   , 

Diagrama de Estados
 Diagrama de Estados
 à    
  
&%`"
    


 v   
 
    .     

  
!  
 
! 
           
! '  
  ,

  
     
  
"
 Diagrama de Estados
  
Inicio


INGRáSADO SáR IDO
servir

   cancelar

Si el estado no
se cámbia
cobrar 1 día
durante 1 día

ð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'#  )

   
  

Diagrama de Componentes
´ 
Bode gue ro
 , 
 

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 Análisis y Diseño

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

 Los casos de uso y los escenarios indicados por el

proceso han probado ser una buena forma de captar
requerimientos y guiar el diseño, la implementación y las
pruebas.
 Administración de requerimientos

Req. 10 Aprobado Bajo Alta

€ $$$

Req. 13 Propuesto Medio Baja € $$

Req. w0
€
Obligatorio Alto
€ Alto $
Arquitecturas basadas en componentes
 El proceso se basa en diseñar tempranamente una
arquitectura base ejecutable.

 La arquitectura debe ser:

± Flexible
± Fácil de modificar
± Intuitivamente comprensible
± Promueve la reutilización de componentes

 RUP apoya el desarrollo basado en componentes,

tanto nuevos como preexistentes.
Arquitecturas basadas en componentes
_unciones de
cliente/ _unciones de
productos licenciamiento

Mecanismos de interfaces

ðliente Producto Licencia

ð

 
 
 ð|
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

= La actividad fundamental de esta práctica es

el testing
= Evaluar continuamente la calidad de un
sistema con respecto a funcionalidad,
confiabilidad, performance
 El aseguramiento de la calidad es parte del
proceso de desarrollo y no la responsabilidad
de un grupo independiente.
Verificación de la Calidad
      
   
Conjunto de actividades que serán ejecutadas para
generar confianza en que el producto cumplirá con los
requerimientos y el proceso es efectivo

ð  

 

Necesidades  
 

|
  

|
 
Control de cambios

 Los cambios son inevitables, pero es necesario

evaluar si éstos son necesarios y rastrear su
impacto.
 RUP indica como controlar, rastrear y monitorear los
cambios dentro del proceso iterativo de desarrollo.
= Las solicitudes de cambios formales facilitan la
claridad de comunicación
= La propagación del cambio es evaluable y
controlable
= Controlar, registrar y monitorear los cambios para
posibilitar el desarrollo iterativo
 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

= Los objetivos son:

Entender la estructura y la dinámica del negocio.
Asegurar que los clientes, usuarios y desarrolladores
tengan un entendimiento común de la organización.
Un Modelo de Casos de Uso del Negocio describe
los proceso de negocio de una empresa en términos
de
= casos de uso del negocio y
= actores del negocio
que se corresponden con los procesos del negocio y
los clientes respectivamente .
Modelamiento de Negocio ± Flujo de
Trabajo
Requerimientos
 Los desarrolladores y clientes deben acordar qué es lo
que el sistema debe hacer:
± Relevar requerimientos
± Documentar funcionalidad y restricciones
± Documentar decisiones
± Identificar actores
± Identificar casos de uso
 Los requerimientos no funcionales se incluyen en una
especificación complementaria.
Requerimientos ± Flujo de Trabajo
Análisis y Diseño
Objetivos:
 Ejecutar las tareas y funciones descritas en los casos
de uso
 Satisfacer todos los requerimientos
 Flexible a cambios
El diseño se centra en la noción de arquitectura
Diseñar y validar la arquitectura es una tarea esencial.
El modelo de diseño consta de
 Clases estructuradas en paquetes
 Diseños de subsistemas con interfaces
definidas (componentes)
 Forma de colaboración entre las clases.
Análisis y Diseño ± Flujo de Trabajo
Implementación
 Objetivo:

± Definir la organización del código

± Implementar clases y objetos en forma de
componentes (fuente, ejecutables, etc.)
± Probar las componentes desarrolladas
± Integrar las componentes en un sistema
ejecutable
Implementación ± Flujo de Trabajo
Test
 Objetivo:
± Verificar la interacción entre los objetos
± Verificar la integración apropiada de componentes
± Verificar que se satisfacen los requerimientos
± Identificar los defectos y corregirlos antes de la
instalación

 RUP describe como planear y ejecutar estas pruebas.

 RUP propone probar los componentes desde el
principio: Confiabilidad, funcionalidad y performance.
Test ± Flujo de Trabajo
Despliegue
 Producir un producto y hacerlo llegar a sus usuarios
finales.
 Incluye varias actividades:
± Producir un ³release´
± Empaquetar el software
± Distribuir el software
± Realizar pruebas beta
± Instalar el software
± Apoyar a los usuarios
± Migración de datos
Despliegue ± Flujo de Trabajo
Administración y Configuración de
Cambios
 Forma de controlar los artefactos producidos por las
personas que trabajan en el proyecto.

 Algunos problemas habituales:

± Actualizaciones simultáneas
± Múltiples versiones

 RUP da guías para:

± Desarrollos en paralelo
± Automatizar la construcción
± Administrar defectos
Administración y Configuración de
Cambios ± Flujo de Trabajo
Administración del Proyecto
 Es el arte de balancear objetivos contrarios,
manejar riesgos y producir software que
satisface a clientes y usuarios.
 Existen pocos proyectos realmente exitosos.
 RUP incluye:
± Un framework para manejo de proyectos
de software
± Guías para planificación, provisión de
personal, ejecución y monitoreo de planes
± Un framework para manejar riesgos
Administración del Proyecto ±
Flujo de Trabajo
Entorno
 Ambiente y herramientas de desarrollo que
harán posible llevar a cabo el proyecto.

 RUP guía en la configuración de un ambiente de

proceso apropiado a cada proyecto.

 Se debe seleccionar un conjunto de artefactos

para el proyecto, esta elección se puede recoger
en un documento breve llamado Marco de
Desarrollo
Entorno
Requerimientos
= El propósito fundamental del flujo de trabajo de los
requisitos es guiar el desarrollo hacia el sistema
correcto.
= Hay diferentes puntos de partida para la captura de
requisitos.
En algunos casos comenzamos haciendo un 
 o partimos de uno ya desarrollado.
En otros casos el cliente puede ya haber
desarrollado una especificación completa de
requisitos no basada en objetos, de la cual podemos
partir.
Requerimientos - Workflow
Analista Arquitecto áspecificador de Diseñador
ðasos de uso de interface
 Requerimientos
Trabajador Responsable de (artefacto)
Analista de sistemas Modelo de casos de uso
Actores
Glosario

Especificador de casos de uso Caso de uso

Diseñador de Interfaz de Usuario Prototipo de interfaz de usuario

Arquitecto Descripción de la arquitectura (vista

del modelo de casos de uso)
Análisis
= Durante el análisis, revisamos los requisitos que
se describieron en la captura de requisitos,
refinándolos y estructurándolos.
= El objetivo de hacerlo es conseguir una
comprensión más precisa de los requisitos y
una descripción de los mismos que sea fácil de
mantener y que nos ayude a estructurar el
sistema entero, incluyendo su arquitectura.
Análisis - Workflow
Arquitecto Ing de ðasos Ing de ðomponentes
de Uso
Análisis





 

  ! "


þ

  



° # 


$
    



%
 "

%

° # 
  


 "


   "


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


%

 Modelo de casos de uso  Un prototipo ejecutable

(80% completo) con de la arquitectura.
descripciones detalladas.  Lista revisada de
 Otros requerimientos no riesgos y del caso de
funcio-nales o no negocio.
asociados a casos de  Plan de desarrollo para
uso. el resto del proyecto.
 Descripción de la  Un manual de usuario
Arquitectura del preliminar.
Software.
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


%

 El producto de software integrado y corriendo en la

plataforma adecuada.

 Manuales de usuario.

 Una descripción del ³release´ actual.

Fase de Construcción
*
%
+
`


+
  +   , 

 Se obtiene un producto Beta que debe decidirse si

puede ponerse en ejecución sin mayores riesgos.
 Condiciones de éxito:
± El producto está maduro y estable para instalarlo
en el ambiente del cliente?
± Están los interesados listos para recibirlo?
Fase de Transición
= Los objetivos son:
Cumplir requisitos
Gestionar todos los aspectos de implantación
Pruebas de aceptación

 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

= Capability Maturity Model Integration.

= Modelo para la mejora o evaluación de los
procesos de desarrollo y mantenimiento de
sistemas y productos de software.
= Desarrollado por el Instituto de Ingeniería del
Software de la Universidad Carnegie Mellon
(SEI), y publicado en su primera versión en
enero de 2002.
= Para los usuarios es difícil especificarlos en
forma cuantitativa
Modelo ðMMI

= CMMI se desarrolló para facilitar y simplificar

la adopción de varios modelos de forma
simultánea, y su contenido integra y da relevo
a la evolución de sus predecesores:
CMM-SW (CMM for Sofwtare)
SE-CMM(Systems Engineering Capability Maturity
Model)
IPD-CMM(Integrated Product Development)
ðMMI ± Niveles de Madurez
NI áL Descripción
1-Inicial Punto base. La organización tiene procesos 
  o caóticos.
El éxito se debe a personas heroícas.
2-Repetible La organización empieza a guardar información. Ya hay
definiciones, pueden repetirse éxitos anteriores.

3-Definido Se conocen procesos estándares para desarrollar o mantener

software. Hay prácticas de Ingeniería de Software y de
Administración de procesos.

w-Administrado Se usan datos recolectados. Las decisiones están basadas en

datos cuantitativos. Los procesos son medidos, hay
retroalimentación.
5-Optimizado La organización se dedica a mejorar contínuamente. Se
localizan debilidades y fortalezas.
ðMMI
Areas ðlave de Proceso (KPAs)
NI áL Áreas ðlave de Proceso
1-Inicial
2-Repetible Gestión de Requisitos (RáQM), Planificación de proyecto,
Monitorización y control de Proyectos, Gestión y acuerdo de
suministros, Medición y Análisis, Gestión de la calidad de
procesos y productos, Gestión de la configuración
3-Definido Desarrollo de requisitos (RD), Solución técnica, Verificación,
Validación, Integración de producto, Procesos orientados a la
organización, Formación, Gestión Integrada de proyecto,
Gestión de riesgos, Análisis y resolución de decisiones

w-Administrado Gestión cuantificada de proyectos, Rendimiento de los

procesos de la organización
5-Optimizado Innovación y desarrollo
 Análisis RUP ± ðMMI
= RUP es un proceso
que define quién debe hacer las cosas, qué
debe hacerse, cómo y cuándo.
Dado su enfoque mantiene modelos en lugar
de gran cantidad de documentación, utiliza un
lenguaje concreto y bien definido (UML).

= CMMI es un modelo estático

que define áreas claves (PA) en las que se
deben llevar a cabo prácticas específicas o
genéricas, por lo tanto el hecho de
implementar RUP en el desarrollo de un
proyecto implica que ciertas KPA de CMMI
sean alcanzadas y otras no.
Análisis RUP ± ðMMI

Áreas ðlave de Revisión

Proceso
Gestión de RUP define claramente el proceso de administración de
Requisitos requerimientos y aporta herramientas como los casos de
uso, es una de las bases de RUP
Planificación de RUP habla de la planeación del proyecto de manera
proyecto iterativa y del control de riesgos.

Monitorización y RUP define cómo debe ser el control del proyecto.

control de Proyectos

Gestión de la RUP es muy claro cuando se habla de administración de

configuración la configuración incluso es una de las mejores prácticas
recomendada.
Análisis RUP ± ðMMI

Áreas ðlave de Revisión

Proceso
Gestión y acuerdo de RUP no menciona nada sobre administración de
suministros acuerdos, es algo no considerado.
Medición y Análisis La medición y análisis no están contemplados
detalladamente en RUP.

Gestión de la calidad En la etapa de transición se lleva a cabo la verificación de

de procesos y la calidad aunque no tan detallada como lo exige CMMI.
productos La verificación de calidad del producto está bien definida
pero la evaluación de calidad del proceso no está
considerada.
Conclusiones
Conclusiones
= La aplicación formal del Proceso Unificado supone:
Desventajas:
= Grandes esfuerzos en la construcción de modelos.

= Necesidad del soporte de herramientas

informáticas.
Ventajas:
= Disminuye el riesgo del error de análisis / diseño
acumulado.
= Aligera el esfuerzo en implementación.

= Proporciona la documentación del ciclo de vida en

el mismo proceso.
Conclusiones
= El Proceso Unificado es flexible y se puede adaptar al
grado de complejidad del modelo de proceso de
desarrollo (descarte de algunos modelos o flujos).

= El Proceso Unificado es abierto y permite la

incorporación de enfoques y artefactos
complementarios:
Patrones de diseño.
Patrones de implementación.
Combinación de varios modelos de proceso.
Arquitecturas Dirigidas por Modelos (v


  pp).
Bibliografía
1. Booch G., Rumbaugh J., Jacobson I. El Lenguaje Unificado de
Modelado, Addison-Wesley, Madrid, 1999.
2. Bruegge B., Dutoit A.H. Ingeniería de Software Orientado a Objetos,
Prentice Hall± Pearson educación, México, 2002.
3. Jacobson I., Booch G., Rumbaugh J. El Proceso Unificado de
Desarrollo de Software, Addison-Wesley, Madrid, 2000.
w. Pressman R.S. Ingeniería del Software. Un enfoque práctico (5ª ed.)
Mc Graw-Hill; New York , 2001.
5. Rumbaugh J., Jacobson I., Booch G. El Lenguaje Unificado de
Modelado. Manual de Referencia, Addison-Wesley, Madrid, 2000.
6. Sommerville I. Ingeniería de software, 6ª edición, Prentice Hall ±
Pearson educación, México, 2002.
7. Stevens P., Pooley R. Utilización de UML en Ingeniería del Software
con Objetos y Componentes, Addison-Wesley, Madrid, 2002.