CALIDAD Y TÉCNICAS DE EVALUACIÓN DE LOS

SISTEMAS

GESTIÓN DE CICLO DE VIDA DEL

SOFTWARE (RUP)

Pierre Sergei Zuppa Azúa

 RATIONAL UNIFIED PROCESS (RUP)

Es un proceso donde se define quién está haciendo

qué, cuándo y cómo lograr un objetivo, que
puede ser: construir un software o mejorarlo.

Objetivos:
– Asegurar la producción de software de calidad
dentro de plazos y presupuestos predecibles.
– Dirigido por casos de uso, centrado en la
arquitectura, iterativo (mini-proyectos) e
incremental (versiones).

Requerimientos Proceso de Ingeniería de Software Sistema

Nuevos o modificados Nuevo o modificado
 EL PROBLEMA
Requerimientos
•Si un proceso es utilizado, equipos funcionales diferentes
Pruebas
normalmente utilizan procesos y lenguajes de modelación
inconsistentes. Análisis

Diseño

?
•La mayoría de los proyectos de software ? ?
utilizan procesos que no están bien ?
definidos. En su lugar los miembros del equipo ? ?
(re)inventan sus propios procesos. ?

•Los procesos no están apropiadamente relacionados con Proceso ? Herramienta

herramientas, ó no están propiamente automatizados.
 INCREMENTO DE LA PRODUCTIVIDAD EN
EQUIPO
Todos los miembros del equipo comparten:
• Base de conocimiento
• Proceso Ingeniero de
•Vista de cómo desarrollar software Desempeño
• Lenguaje de modelamiento (UML)

Administrador
Base de Datos
Administrador de
Configuración

Líder de
Proyecto

Analista

Diseñador/ Pruebas
Desarrollador
 DESARROLLO ITERATIVO

 Se abordan las tareas más riesgosas Un proceso iterativo permite una
primero, con esto se logra reducir los riesgos comprensión creciente de los
del proyecto y tener un subsistema
requerimientos a la vez que se va
ejecutable tempranamente para no cancelar
haciendo crecer el sistema.
por defectos grandes posteriores.
RUP sigue un modelo iterativo que
 Refinamientos sucesivos.

 Habilita una fácil retroalimentación de aborda las tareas más riesgosas

usuario. primero.
 Metas específicas. Con esto se logra reducir los riesgos
 El progreso es medido conforme avanzan las del proyecto y tener un subsistema
implementaciones.
ejecutable tempranamente.
 El software moderno es complejo y
novedoso. No es realista usar un modelo
lineal de desarrollo como el de cascada.
 DESARROLLO ITERATIVO
Cada iteración resulta en un release
ejecutable

Requerimientos

Planeamiento Análisis y Diseño

Implementación
Ambiente de
Planeamiento Administración
inicial

Evaluación
Prueba

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

 Utiliza UML.
 Gramática bien definida.
 Terminología para los procesos.
 Define nueve disciplinas y faces.
 Base de conocimiento, plantillas y herramientas.
 Modelamiento visual, programación, pruebas, etc.
 Se centra en la producción y mantenimiento de
modelos del sistema más que en producir
documentos.
 6 MEJORES PRÁCTICAS
RUP describe cómo utilizar de forma efectiva procedimientos
comerciales probados en el desarrollo de software para equipos de
desarrollo de software, conocidos como “mejores prácticas”.

Administrar requerimientos

Desarrollar Arquitecturas
Iterativamente Verificar Modelizar
Calidad Visualmente Basadas en
Componentes

Controlar Cambios
 6 MEJORES PRÁCTICAS
Licitar, organizar, y documentar la funcionalidad y restricciones requeridas.
Administración de 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.
Requerimientos Los casos de uso son instrumentos importantes de planeación.

Se enfoca en el pronto desarrollo de una arquitectura ejecutable robusta.

Arquitectura Basada Resistente al cambio mediante el uso de interfaces bien definidas.
en Componentes Intuitivamente comprensible.
Promueve un reúso más efectivo de software.
Es derivada a partir de los casos de uso más importantes.

Captura la estructura y comportamiento de arquitecturas y componentes.

Modelación Visual Muestra como encajan de forma conjunta los elementos del sistema.
de Software Mantiene la consistencia entre un diseño y su implementación.
Promueve una comunicación no ambigua.

Crea pruebas para cada escenario (casos de uso) para asegurar que todos los requerimientos están
Verificación de la Calidad propiamente implementados.
Verifica la calidad del software con respecto a los requerimientos basados en la confiabilidad, funcionalidad,
del Software desempeño de la aplicación y del sistema.
Prueba cada iteración

Controlar, llevar un registro y monitorear cambios para permitir un desarrollo iterativo.

Control de Cambios Establece espacios de trabajo seguros para cada desarrollador
del Software Provee aislamiento de cambios hechos en otros espacios de trabajo
Controla todos los artefactos de software – modelos, código, documentos, etc…

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

Objetivos del Arquitectura de Capacidad Producto

Ciclo de Vida Ciclo de Vida Operacional
•Las partes interesadas •Condiciones de éxito •Se obtiene un •Condiciones de éxito:
deben acordar el de la elaboración: producto Beta que –¿Se han alcanzado
alcance y la estimación –¿Es estable la debe decidirse si puede los objetivos fijados
de tiempo y costo. visión del producto? ponerse en ejecución en la fase de Inicio ?
–¿Es estable la sin mayores riesgos. –¿El usuario está
•Comprensión de los arquitectura? •Condiciones de éxito: satisfecho ?
requerimientos –¿Las pruebas de –¿El producto está
plasmados en casos de ejecución maduro y estable
uso. demuestran que los para instalarlo en el
riesgos han sido ambiente del cliente?
abordados y –¿Están los
resueltos? interesados listos
–¿Es el plan del para recibirlo?
proyecto algo
realista?
–¿Están de acuerdo
con el plan todas las
personas
involucradas
 Relación entre Diagramas UML
y Disciplinas de RUP
Disciplina Diagrama
Requerimientos Diagramas de Casos de Uso

Refinamiento y documentación de los casos de usos

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

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

Diagrama de Componentes
Implementación Diagrama de Despliegue
 RUP VISIÓN DINÁMICA
Fases
Disciplinas de Procesos Inicio Elaboración Construcción Transición

Modelación de Negocios
Requerimientos
Análisis y Diseño
Implementación
Estática
Prueba
Despliegue
Disciplinas de Soporte
Admin. Configuración
Administración
Ambiente
Iteración(es) Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Preliminar #1 #2 #n #n+1 #n+2 #m #m+1

Iteraciones

Dinámica
 DEFINICIONES
Trabajador
• Un trabajador define
comportamiento y las
responsabilidades de un individuo.
• Es como un “sombrero” que la
persona usa durante el proyecto:
– Una persona puede tener varios
sombreros
– Es el rol que desempeña en un
momento dado
• Responsabilidades:
– Hacer una serie de actividades
– Ser el responsable de una serie
de artefactos
Actividades
• Una actividad es una unidad de trabajo que
el se asigna a un trabajador. Ejemplo:
– Crear o modificar un artefacto
• Una actividad lleva entre un par de horas y
un par de días, involucra un solo trabajador
y un número pequeño de artefactos.
• Las actividades se consideran en la
planificación y evaluación del progreso del
proyecto.
• Ejemplos:
– Planificar una iteración - Administrador
de proyecto
– Encontrar actores y casos de uso -
Analista
– Revisar el diseño - Revisor de diseño
– Ejecutar pruebas de performance - Ing.
de pruebas de performance.
ASIGNACIÓN DE ACTIVIDADES
 FLUJOS DE TRABAJO

• Una lista de actividades, trabajadores y

artefactos constituye un proceso. Análisis de Diseño de Describir Describir
Arquitectura Arquitectura Concurrencia Distribución

• Un flujo de trabajo es una secuencia de Arquitecto

actividades que produce un resultado valioso.

• No siempre es posible representar flujos de Análisis de Diseño de

Casos de Uso Casos de Uso
trabajo.
Diseñador de
• Existen habitualmente problemas de Casos de Uso
comunicación entre ingenieros de software e
ingenieros de negocios. Análisis de Diseño de
Objetos Objetos

• RUP proporciona un lenguaje y proceso común Diseñador

para estos dos ámbitos.

• Para el modelamiento del negocio se usan

“business use cases” (casos de uso del
negocio): Revisor de Revisar el Revisar el Revisar la
Diseño Análisis Diseño Arquitectura
– La forma en que el software dará apoyo
al negocio.
 VISIÓN
Estática
Roles: analista de sistemas, diseñador, diseñador de
pruebas, roles de gestión y roles de administración.
Actividades: 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
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…)
Flujos de trabajo: son el “pegamento” de los roles,
actividades, artefactos y disciplinas, y constituyen la
secuencia de actividades que producen resultados
visibles.
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.
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.- Elaboració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”.
3.- Construcció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”.
4.- Transició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”.
 CONFORMACIÓN DEL EQUIPO
ROLES
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
Ingeniero de componentes
Integrador del sistema
Ingeniero de pruebas
Verificador de integración
Verificador del sistema
TAREAS 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
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
Integrar el Sistema
Planear las Pruebas Diseñar las Pruebas Evaluar las Pruebas
Realizar una Prueba de Integración
Realizar las Pruebas del Sistema
 DEPENDENCIA ENTRE LOS CASOS DE USO Y LOS
DEMÁS MODELOS
<<communicate>>

Administrador Consulta
<<extend>>

Identificacion Especificado por Realizado por Distribuido por Implementado por

Modelo de análisis Modelo de diseño Verificado por

Modelo de despliegue Modelo de

implementación
X
OX

X
OX
X
OX

Modelo de prueba
 • Usados para comunicarse con el usuario final y el experto de dominio.
• Proporciona credibilidad en una etapa inicial del desarrollo del sistema.
• Asegura una comprensión mutua de los requisitos

Casos de • Usados para verificar

• Que se hayan capturado todos los requerimientos.

uso • Que los desarrolladores hayan entendido los requerimientos.

• Usados para mostrar la estructura Eetática de un sistema

computacional o una parte relevante del mundo real.

• Son los diagramas más frecuentemente usados y se les puede

considerar con tres perspectivas posibles:

• Conceptual: muestra las entidades del mundo real

Clases
con sus relaciones.
• Especificación: uestra la estructura del sistema
o sus partes, destacando las interfaces.
• Implementación: el diseño del código fuente.
 • Usados para representar el comportamiento del sistema.

• Muestran colaboración a través de mensajes entre los objetos del sistema

•Destacan:
•Mensajes enviados entre los objetos.
•Orden secuencial entre los mensajes.
Secuencia •Un escenario concreto, sin condiciones.

• Útiles tanto en análisis (identificación de clases), como en diseño

(especificación de componentes).

• Usados para representar el comportamiento del sistema

• Muestran colaboración entre los objetos del sistema

• Destacan:
• Mensajes enviados entre los objetos
• Enlaces entre los objetos
• Un escenario concreto, sin condiciones

Colaboración • Útiles tanto en análisis (identificación de clases), como en diseño

(especificación de componentes).
 • Usados para representar el comportamiento del sistema o negocio.

• Muestran actividades y procesos.

• Destacan:
• Condiciones y flujos alternativos.
• Tareas y procesos concurentes.
Actividades • Responsabilidades sobre ciertas actividades.

• Útiles en análisis de negocio para capturar

procesos de alto nivel.

• Usados para representar el comportamiento INTERNO de un objeto o de un

módulo del sistema.

• Muestran estados en los cuales un objeto se puede encontrar.

• Destacan:
• Estados
• Transiciones y condiciones de las transiciones
Estados • Actividades realizadas

• Típicamente usados para describir ciclo de vida de un objeto.

 • Usados para mostrar los Módulos Físicos de software:
• Los ejecutables y librerías dinámicas.
• Las páginas WEB y los scripts.
• Los módulos o funciones, etc.

• Sin embargo se usan más bien para capturar la Organización de los

componentes de Software (EXE, DLL, EJB, etc.)
Componentes
• Destacan:
• Dependencias entre los componentes.

• Usados Para Modelar las Relaciones entre el Software y el Hardware.

• Mapeo de los Componentes de Software a los Nodos de Hardware.

• Típicamente contienen elementos tales como:

• Servidores.
• Procesadores.
Distribución • Impresoras.
• Redes computacionales.
 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.
 Diagramas de Casos de Uso
 Diagramas de Clases
 Diagramas de Estados
 Diagramas de Componentes
 Diagramas de Implementación

Subsistemas

Modelización Visual
Clases
eleva el nivel de
abstracción
Código
 DISCIPLINAS

Proceso Soporte
1. Modelado del negocio: describe la estructura
y la dinámica de la organización.
1. Gestión de configuraciones:
2. Requisitos: describe el método basado en
controla los cambios y mantiene
casos de uso para extraer los requisitos. la integridad de los artefactos de
3. Análisis y diseño: describe las diferentes un proyecto.
vistas arquitectónicas.
2. Gestión del Proyecto: describe
4. Implementación: tiene en cuenta el desarrollo
de software, la prueba de unidades y la varias estrategias de trabajo en
integración. un proceso iterativo.
5. Pruebas: describe los casos de pruebas, los 3. Ambiente: cubre la
procedimientos y las métricas para evaluación
de defectos. infraestructura necesaria para
6. Despliegue: cubre la configuración del sistema desarrollar un sistema.
entregable.
WORKFLOW
 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 Prototipo de interfaz de usuario

Usuario

Arquitecto Descripción de la arquitectura

(vista del modelo de casos de
uso)
 ANÁLISIS

Trabajador Responsable de (artefacto)

Arquitecto Modelo de Análisis
Descripción de la
arquitectura

Ingeniero de Casos de Uso Realización de casos de

usos - Análisis -

Ingeniero de Componentes Clases del Análisis

Paquete del análisis
 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 Específico para una implementación

diseños)
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.
 DISEÑO

Trabajador Responsable de (artefacto)

Arquitecto Modelo de diseño
Modelo de despliegue
Descripción de la
arquitectura

Ingeniero de Casos de Uso Realización de casos de

usos - Diseño -

Ingeniero de Componentes Clases del diseño

Subsistema de Diseño
Interfaz
 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
 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