Gestionciclode_vida_del_software_RUP.pdf

rup

1. CALIDAD Y TÉCNICAS DE EVALUACIÓN DE LOS
SISTEMAS
GESTIÓN DE CICLO DE VIDA DEL
SOFTWARE (RUP)
Pierre Sergei Zuppa Azúa

2. RATIONAL UNIFIED PROCESS (RUP)
Esunprocesodondesedefinequiénestáhaciendo
qué,cuándoycómolograrunobjetivo,que
puedeser:construirunsoftwareomejorarlo.
Objetivos:
–Asegurarlaproduccióndesoftwaredecalidad
dentrodeplazosypresupuestospredecibles.
–Dirigidoporcasosdeuso,centradoenla
arquitectura,iterativo(mini-proyectos)e
incremental(versiones).
Proceso de Ingeniería de SoftwareRequerimientos
Nuevos o modificados Nuevo o modificado
Sistema

3. EL PROBLEMA
•Siunprocesoesutilizado,equiposfuncionalesdiferentes
normalmenteutilizanprocesosylenguajesdemodelación
inconsistentes.
Requerimientos
Pruebas
Análisis
Diseño
•Lamayoríadelosproyectosdesoftware
utilizanprocesosquenoestánbien
definidos.Ensulugarlosmiembrosdelequipo
(re)inventansuspropiosprocesos.
?
?
?
?
?
?
?
•Losprocesosnoestánapropiadamenterelacionadoscon
herramientas,ónoestánpropiamenteautomatizados.
?
Proceso Herramienta

4. INCREMENTO DE LA PRODUCTIVIDAD EN
EQUIPO
Todos los miembros del equipo comparten:
•Base de conocimiento
•Proceso
•Vista de cómo desarrollar software
•Lenguaje de modelamiento(UML)
Administrador
Base de Datos
Líder de
Proyecto
Analista
Diseñador/
Desarrollador
Ingeniero de
Desempeño
Pruebas
Administrador de
Configuración

5. DESARROLLO ITERATIVO
Seabordanlastareasmásriesgosas
primero,conestoselograreducirlosriesgos
delproyectoytenerunsubsistema
ejecutabletempranamenteparanocancelar
pordefectosgrandesposteriores.
Refinamientossucesivos.
Habilitaunafácilretroalimentaciónde
usuario.
Metasespecíficas.
Elprogresoesmedidoconformeavanzanlas
implementaciones.
Elsoftwaremodernoescomplejoy
novedoso.Noesrealistausarunmodelo
linealdedesarrollocomoeldecascada.
Unprocesoiterativopermiteuna
comprensión crecientedelos
requerimientosalavezqueseva
haciendocrecerelsistema.
RUPsigueunmodeloiterativoque
abordalastareasmásriesgosas
primero.
Conestoselograreducirlosriesgos
delproyectoytenerunsubsistema
ejecutabletempranamente.

6. DESARROLLO ITERATIVO
Planeamiento
inicial
Planeamiento
Requerimientos
Análisis y Diseño
Implementación
Prueba
Distribución
Evaluación
Ambiente de
Administración
Cada iteración resulta en un release
ejecutable

7. RUP
Ventajas Desventaja
Madurez en el tiempo.
UML.
Se adapta a la organización.
Herramientas de adaptación.
Define actividades, roles y
responsabilidades.
Sistema hibrido.
Conocimientos avanzados.
Costosa.
Limitaciones con el ciclo de vida
del software.

8. CARACTERÍSTICAS
UtilizaUML.
Gramáticabiendefinida.
Terminologíaparalosprocesos.
Definenuevedisciplinasyfaces.
Basedeconocimiento,plantillasyherramientas.
Modelamientovisual,programación,pruebas,etc.
Secentraenlaproducciónymantenimientode
modelosdelsistemamásqueenproducir
documentos.

9. 6 MEJORES PRÁCTICAS
RUPdescribecómoutilizardeformaefectivaprocedimientos
comercialesprobadoseneldesarrollodesoftwareparaequiposde
desarrollodesoftware,conocidoscomo“mejoresprácticas”.
Controlar Cambios
Administrar requerimientos
Arquitecturas
Basadas en
Componentes
Desarrollar
Iterativamente
Verificar
Calidad
Modelizar
Visualmente

10. 6 MEJORES PRÁCTICAS
Administración de
Requerimientos
Licitar, organizar, y documentar la funcionalidad y restricciones requeridas.
Llevar un registro y documentación de cambios y decisiones.
Los requerimientos de negocio son fácilmente capturados y comunicados a través de casos de uso.
Los casos de uso son instrumentos importantes de planeación.
Arquitectura Basada
en Componentes
Se enfoca en el pronto desarrollo de una arquitectura ejecutable robusta.
Resistente al cambio mediante el uso de interfaces bien definidas.
Intuitivamente comprensible.
Promueve un reúso más efectivo de software.
Es derivada a partir de los casos de uso más importantes.
Modelación Visual
de Software
Captura la estructura y comportamiento de arquitecturas y componentes.
Muestra como encajan de forma conjunta los elementos del sistema.
Mantiene la consistencia entre un diseño y su implementación.
Promueve una comunicación no ambigua.
Verificación de la Calidad
del Software
Crea pruebas para cada escenario (casos de uso) para asegurar que todos los requerimientos están
propiamente implementados.
Verifica la calidad del software con respecto a los requerimientos basados en la confiabilidad, funcionalidad,
desempeño de la aplicación y del sistema.
Prueba cada iteración
Control de Cambios
del Software
Controlar, llevar un registro y monitorear cambios para permitir un desarrollo iterativo.
Establece espacios de trabajo seguros para cada desarrollador
Provee aislamiento de cambios hechos en otros espacios de trabajo
Controla todos los artefactos de software –modelos, código, documentos, etc…
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.

11. FASES EN RUP
Inicio Elaboración Construcción Transición
Producto
•Un documento de visión
general:
–Requerimientos
generales del proyecto
–Características
principales
–Restricciones
•Modelo inicial de casos de uso
(10% a 20 % listos).
•Glosario.
•Caso de negocio:
–Contexto
–Criterios de éxito
–Pronóstico financiero
•Identificación inicial de
riesgos.
•Plan de proyecto.
•Uno o más prototipos.
Producto
•Es la parte más crítica del
proceso:
–Al final toda la ingeniería
“dura” está hecha
–Se puede decidir si vale
la pena seguir adelante
•A partir de aquí la arquitectura,
los requerimientos y los planes de
desarrollo son estables.
•Ya hay menos riesgos y se puede
planificar el resto del proyecto con
menor incertidumbre.
•Se construye una arquitectura
ejecutable que contemple:
–Los casos de uso críticos
–Los riesgos identificados
•Modelo de casos de uso (80%
completo) con descripciones
detalladas.
•Otros requerimientos no
funcionales o no asociados a
casos de uso.
•Descripción de la Arquitectura del
Software.
•Un prototipo ejecutable de la
arquitectura.
•Lista revisada de riesgos y del
caso de negocio.
•Plan de desarrollo para el resto
del proyecto.
•Un manual de usuario preliminar.
•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.
•Producto.
•El producto de software
integrado y corriendo en la
plataforma adecuada.
•Manuales de usuario.
•Una descripción del “release”
actual.
•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
•Obtener autosuficiencia de
parte de los usuarios.
•Concordancia en los logros
del producto de parte de las
personas involucradas.
•Lograr el consenso cuanto
antes para liberar el producto
al mercado.

12. ARTEFACTO
Inicio Elaboración Construcción
•Un documento de visión
general:
–Requerimientos generales del
proyecto
–Características principales
–Restricciones
•Modelo inicial de casos de uso
(10% a 20 % listos).
•Glosario.
•Caso de negocio:
–Contexto
–Criterios de éxito
–Pronóstico financiero
•Identificación inicial de riesgos.
•Plan de proyecto.
•Uno o más prototipos.
•Modelo de casos de uso (80%
completo) con descripciones
detalladas.
•Otros requerimientos no
funcionales o no asociados a
casos de uso.
•Descripción de la Arquitectura
del Software.
•Un prototipo ejecutable de la
arquitectura.
•Lista revisada de riesgos y del
caso de negocio.
•Plan de desarrollo para el resto
del proyecto.
•Un manual de usuario
preliminar.
•El producto de software
integrado y corriendo en la
plataforma adecuada.
•Manuales de usuario.
•Una descripción del “release”
actual.

13. HITO
Inicio Elaboración Construcción Transición
Objetivos del
Ciclo de Vida
Arquitectura de
Ciclo de Vida
Capacidad
Operacional
Producto
•Laspartesinteresadas
deben acordarel
alcanceylaestimación
detiempoycosto.
•Comprensióndelos
requerimientos
plasmadosencasosde
uso.
•Condicionesdeéxito
delaelaboración:
–¿Esestablela
visióndelproducto?
–¿Esestablela
arquitectura?
–¿Laspruebasde
ejecución
demuestranquelos
riesgoshansido
abordados y
resueltos?
–¿Eselplandel
proyecto algo
realista?
–¿Estándeacuerdo
conelplantodaslas
personas
involucradas
•Se obtiene un
productoBetaque
debedecidirsesipuede
ponerseenejecución
sinmayoresriesgos.
•Condicionesdeéxito:
–¿Elproductoestá
maduroyestable
parainstalarloenel
ambientedelcliente?
–¿Están los
interesadoslistos
pararecibirlo?
•Condiciones de éxito:
–¿Se han alcanzado
los objetivos fijados
en la fase de Inicio?
–¿El usuario está
satisfecho?

14. 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

15. Administración
Ambiente
Modelación de Negocios
Implementación
Prueba
Análisis y Diseño
Iteración(es)
Preliminar
Iter.
#1
Fases
Disciplinas de Procesos
Iteraciones
Disciplinasde Soporte
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Despliegue
Admin. Configuración
Requerimientos
Elaboración TransiciónInicio Construcción
Estática
RUP VISIÓN DINÁMICA
Dinámica

16. DEFINICIONES
Trabajador Actividades
•Un trabajadordefine el
comportamiento y las
responsabilidadesdeunindividuo.
•Escomoun“sombrero”quela
personausaduranteelproyecto:
–Unapersonapuedetenervarios
sombreros
–Eselrolquedesempeñaenun
momentodado
•Responsabilidades:
–Hacerunaseriedeactividades
–Serelresponsabledeunaserie
deartefactos
•Unaactividadesunaunidaddetrabajoque
seasignaauntrabajador.Ejemplo:
–Crearomodificarunartefacto
•Unaactividadllevaentreunpardehorasy
unpardedías,involucraunsolotrabajador
yunnúmeropequeñodeartefactos.
•Lasactividadesseconsideranenla
planificaciónyevaluacióndelprogresodel
proyecto.
•Ejemplos:
–Planificarunaiteración-Administrador
deproyecto
–Encontraractoresycasosdeuso-
Analista
–Revisareldiseño-Revisordediseño
–Ejecutarpruebasdeperformance-Ing.
depruebasdeperformance.

17. ASIGNACIÓN DE ACTIVIDADES

18. •Una lista de actividades, trabajadores y
artefactos constituye un proceso.
•Un flujo de trabajo es una secuencia de
actividades que produce un resultado valioso.
•No siempre es posible representar flujos de
trabajo.
•Existen habitualmente problemas de
comunicación entre ingenieros de software e
ingenieros de negocios.
•RUP proporciona un lenguaje y proceso común
para estos dos ámbitos.
•Para el modelamiento del negocio se usan
“businessuse cases” (casos de uso del
negocio):
–La forma en que el software dará apoyo
al negocio.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Revisor de
Diseño
Diseñador
Diseñador de
Casos de Uso
Arquitecto
FLUJOS DE TRABAJO

19. VISIÓN
Estática Dinámica
Roles:analistadesistemas,diseñador,diseñadorde
pruebas,rolesdegestiónyrolesdeadministración.
Actividades:determinaeltrabajodecadarolatravés
deactividades.Cadaactividaddelproyectodebetener
unpropósitoclaro,yseasignaaunrolespecífico.Las
actividadespuedentenerduracióndehorasode
algunosdías;ysonelementosbasedeplanificacióny
progreso
Artefactos:Sonloselementosdeentradaysalidade
lasactividades.Sonproductostangiblesdelproyecto.
Lascosasqueelproyectoproduceousapara
componerelproductofinal(modelos,documentos,
código,ejecutables…)
Flujosdetrabajo:sonel“pegamento”delosroles,
actividades,artefactosydisciplinas,yconstituyenla
secuenciadeactividadesqueproducenresultados
visibles.
Disciplinas:son“contenedores”empleadospara
organizarlasactividadesdelproceso.RUPcomprende
6disciplinasdeprocesoy3desoporte.
Proceso:modeladodelnegocio,requisitos,análisisy
diseño,implementación,pruebasydesarrollo.
Soporte:gestióndeproyecto,gestióndeconfiguración
ycambio,yentorno.
Ensuvisióndinámica,lavisióndelaestructura
delciclodevidaRUPsebasaenundesarrollo
iterativo,jalonadoporhitospararevisarel
avanceyplanearlacontinuidadolosposibles
cambiosderumbo.
Cuatrosonlasfasesquedividenelciclodevida
deunproyectoRUP:
1.-Inicio.Eslafasedelaidea,delavisióninicial
deproducto,sualcance.Elesbozodeuna
arquitecturaposibleylasprimerasestimaciones.
Concluyeconel“hitodeobjetivo”.
2.-Elaboración.Comprendelaplanificaciónde
lasactividadesydelequiponecesario.La
especificacióndelasnecesidadesyeldiseñode
laarquitectura.Terminaconel“hitode
Arquitectura”.
3.-Construcción.Desarrollodelproductohasta
queseencuentradisponibleparasuentregaa
losusuarios.Terminaconel“hitodeliniciodela
capacidadoperativa”.
4.-Transición.Traspasodelproductoalos
usuarios.Incluye:manufactura,envío,formación,
asistenciayelmantenimientohastalograrla
satisfaccióndelosusuarios.Terminaconel“hito
deentregadelproducto”.

20. CONFORMACIÓN DEL EQUIPO
ROLES TAREAS 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 Prototiparuna Interfaz de Usuario
Ingeniero de casos de uso Analizar un Caso de Uso Diseñar un Caso de Uso
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

21. X
OX
X
OX
X
OX
Modelo de análisis
Modelo de diseño
Modelo de despliegue Modelo de
implementación
Modelo de prueba
Especificado por Realizado por Distribuido porImplementado por
Verificado por
DEPENDENCIA ENTRE LOS CASOS DE USO Y LOS
DEMÁS MODELOS
Identificacion
Administrador Consulta
<<extend>>
<<communicate>>

22. •Usados para comunicarse con el usuario final y el experto de dominio.
•Proporcionacredibilidaden unaetapainicialdel desarrollodel sistema.
•Aseguraunacomprensiónmutuade los requisitos
•Usados para verificar
•Quese hayancapturadotodoslos requerimientos.
•Quelos desarrolladoreshayanentendidolos requerimientos.
Casos de
uso
•Usadosparamostrarla estructuraEetáticade un sistema
computacionalo unaparte relevantedel mundoreal.
•Son los diagramasmásfrecuentementeusadosyse les puede
considerar con tres perspectivasposibles:
•Conceptual: muestralasentidadesdel mundoreal
con susrelaciones.
•Especificación:uestrala estructuradel sistema
o suspartes, destacandolasinterfaces.
•Implementación:el diseñodel códigofuente.
Clases

23. •Usadospararepresentarel comportamientodel sistema.
•Muestran colaboración a través de mensajes entre los objetos del sistema
•Destacan:
•Mensajesenviadosentre los objetos.
•Ordensecuencialentre los mensajes.
•Un escenario concreto, sin condiciones.
•Útilestantoen análisis(identificaciónde clases), comoen diseño
(especificaciónde componentes).
Secuencia
•Usados para representar el comportamiento del sistema
•Muestran colaboración entre los objetos del sistema
•Destacan:
•Mensajesenviadosentre los objetos
•Enlaces entre los objetos
•Un escenario concreto, sin condiciones
•Útilestantoen análisis(identificaciónde clases), comoen diseño
(especificaciónde componentes).
Colaboración

24. •Usadospararepresentarel comportamientodel sistemao negocio.
•Muestranactividadesy procesos.
•Destacan:
•Condicionesy flujosalternativos.
•Tareasy procesosconcurentes.
•Responsabilidadessobreciertasactividades.
•Útilesen análisisde negocioparacapturar
procesosde alto nivel.
Actividades
•Usadospararepresentarel comportamientoINTERNO de un objetoo de un
módulodel sistema.
•Muestran estados en los cuales un objeto se puede encontrar.
•Destacan:
•Estados
•Transicionesy condicionesde lastransiciones
•Actividades realizadas
•Típicamenteusadosparadescribirciclode vidade un objeto.
Estados

25. •Usadosparamostrarlos MódulosFísicosde software:
•Los ejecutablesy libreríasdinámicas.
•Las páginasWEB y los scripts.
•Los móduloso funciones, etc.
•Sin embargo se usanmásbienparacapturarla Organizaciónde los
componentesde Software(EXE, DLL, EJB, etc.)
•Destacan:
•Dependenciasentre los componentes.
Componentes
•UsadosPara ModelarlasRelacionesentre el Softwarey el Hardware.
•Mapeode los Componentesde Software a los Nodosde Hardware.
•Típicamentecontienenelementostalescomo:
•Servidores.
•Procesadores.
•Impresoras.
•Redescomputacionales.
Distribución

26. •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

27. DiagramasdeCasosdeUso
DiagramasdeClases
DiagramasdeEstados
DiagramasdeComponentes
DiagramasdeImplementación
Código
Clases
Subsistemas
ModelizaciónVisual
elevael nivelde
abstracción

28. DISCIPLINAS
Proceso Soporte
1.Modeladodelnegocio:describela
estructurayladinámicadela
organización.
2.Requisitos:describeelmétodobasado
encasosdeusoparaextraerlos
requisitos.
3.Análisisydiseño:describelas
diferentesvistasarquitectónicas.
4.Implementación:tieneencuentael
desarrollodesoftware,lapruebade
unidadesylaintegración.
5.Pruebas:describeloscasosdepruebas,
losprocedimientosylasmétricaspara
evaluacióndedefectos.
6.Despliegue:cubrelaconfiguracióndel
sistemaentregable.
1.Gestióndeconfiguraciones:
controlaloscambiosy
mantienelaintegridaddelos
artefactosdeunproyecto.
2.GestióndelProyecto:
describevariasestrategiasde
trabajoenunproceso
iterativo.
3.Ambiente:cubrela
infraestructuranecesariapara
desarrollarunsistema.

29. WORKFLOW

33. 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)

34. ANÁLISIS
Trabajador Responsable de (artefacto)
Arquitecto Modelo de Análisis
Descripción de la
arquitectura
Ingeniero de Casos de UsoRealización de casos de
usos -Análisis -
Ingeniero de Componentes Clases del Análisis
Paquete del análisis

35. DISEÑO
Modelo de Análisis Modelo de Diseño
Modelo conceptual. Modelo físico (implementación)
Genérico respecto al diseño (aplicable a varios
diseños)
Específico para una implementación
Tres estereotipos: entidad, control, interface. Cualquier nro. de estereotipos físicos.
Menos formal. Mas formal.
Menos caro de desarrollar Más caro.
Menos capas. Más capas.
Dinámico (no muy centrado en la secuencia) Dinámico (muy centrado en la secuencia)
Creado principalmente como trabajo manual Creado fundamentalmente como "programación
visual" en ing.de ida y vuelta.
Puede no mantenerse todo el ciclo de vida. Debe ser mantenido todo el ciclo de vida.

36. DISEÑO
Trabajador Responsable de (artefacto)
Arquitecto Modelo de diseño
Modelo de despliegue
Descripción de la
arquitectura
Ingeniero de Casos de UsoRealización de casos de
usos -Diseño -
Ingeniero de Componentes Clases del diseño
Subsistema de Diseño
Interfaz

37. IMPLEMENTACIÓN
Trabajador Responsable de (artefacto)
Arquitecto Modelo de implementación
Modelo de despliegue
Descripción de la
arquitectura
Integrador de sistema Integración de sistema
Ingeniero de Componentes Componente
Implementación de
subsistema
Interfaz

38. PRUEBA
Trabajador Responsable de (artefacto)
Diseñador de Pruebas Modelo de pruebas
Casos de Prueba
Procedimientos de prueba
Evaluación de pruebas
Plan de pruebas
Ingeniero de Componentes Componente de pruebas
Ingeniero de Pruebas de Integración Defecto
Ingeniero de Pruebas de Sistema Defecto