1. No category

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
Nuevos o modificados
Proceso de Ingeniería de Software
Sistema
Nuevo o modificado
EL PROBLEMA
Requerimientos
•Si un proceso es utilizado, equipos funcionales diferentes
normalmente utilizan procesos y lenguajes de modelación
inconsistentes.
Pruebas
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
herramientas, ó no están propiamente automatizados.
?
?
?
?
?
Proceso
?
?
Herramienta
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)
Ingeniero de
Desempeño
Administrador
Base de Datos
Administrador de
Configuración
Líder de
Proyecto
Analista
Diseñador/
Desarrollador
Pruebas
DESARROLLO ITERATIVO
 Se
abordan
las
tareas
más
riesgosas
primero, con esto se logra reducir los riesgos
del
proyecto
y
tener
un
subsistema
ejecutable tempranamente para no cancelar
por defectos grandes posteriores.
una
fácil
comprensión
creciente
de
los
requerimientos a la vez que se va
haciendo crecer el sistema.
RUP sigue un modelo iterativo que
 Refinamientos sucesivos.
 Habilita
Un proceso iterativo permite una
retroalimentación
de
aborda
las
tareas
más
riesgosas
primero.
usuario.
 Metas específicas.
Con esto se logra reducir los riesgos
 El progreso es medido conforme avanzan las
del proyecto y tener un subsistema
implementaciones.
 El
software
moderno
ejecutable tempranamente.
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
Ambiente de
Administración
Planeamiento
inicial
Implementación
Evaluación
Prueba
Distribución
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.
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
documentos.
sistema
más
que
en
producir
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
Iterativamente
Verificar
Calidad
Modelizar
Visualmente
Controlar Cambios
Arquitecturas
Basadas en
Componentes
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.
FASES EN RUP
Inicio
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.
Elaboración
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.
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.
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
•El producto de software
integrado y corriendo en la
plataforma adecuada.
•Obtener autosuficiencia de
parte de los usuarios.
•Manuales de usuario.
•Concordancia en los logros
del producto de parte de las
personas involucradas.
•Una descripción del “release”
actual.
•Lograr el consenso cuanto
antes para liberar el producto
al mercado.
ARTEFACTO
Inicio
Elaboració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.
Construcción
•El producto de software
integrado y corriendo en la
plataforma adecuada.
•Manuales de usuario.
•Una descripción del “release”
actual.
HITO
Inicio
Elaboración
Construcción
Transición
Objetivos del
Ciclo de Vida
Arquitectura de
Ciclo de Vida
Capacidad
Operacional
Producto
•Las partes interesadas •Condiciones de éxito
deben
acordar
el de la elaboración:
alcance y la estimación
–¿Es
estable
la
de tiempo y costo.
visión del producto?
–¿Es
estable
la
•Comprensión de los
arquitectura?
requerimientos
–¿Las pruebas de
plasmados en casos de
ejecución
uso.
demuestran que los
riesgos han sido
abordados
y
resueltos?
–¿Es el plan del
proyecto
algo
realista?
–¿Están de acuerdo
con el plan todas las
personas
involucradas
•Se
obtiene
un •Condiciones de éxito:
producto Beta que
–¿Se han alcanzado
debe decidirse si puede
los objetivos fijados
ponerse en ejecución
en la fase de Inicio ?
sin mayores riesgos.
–¿El usuario está
•Condiciones de éxito:
satisfecho ?
–¿El producto está
maduro y estable
para instalarlo en el
ambiente del cliente?
–¿Están
los
interesados
listos
para recibirlo?
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 DINÁMICA
Fases
Disciplinas de Procesos
Inicio
Elaboración
Construcción
Transición
Modelación de Negocios
Requerimientos
Análisis y Diseño
Estática
Implementación
Prueba
Despliegue
Disciplinas de Soporte
Admin. Configuración
Administración
Ambiente
Iteración(es)
Preliminar
Iter.
#1
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iteraciones
Dinámica
Iter.
#m
Iter.
#m+1
DEFINICIONES
Trabajador
Actividades
•
Un
trabajador
define
el
comportamiento
y
las
responsabilidades de un individuo.
•
Una actividad es una unidad de trabajo que
se asigna a un trabajador. Ejemplo:
– Crear o modificar un artefacto
•
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
•
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.
•
Responsabilidades:
– Hacer una serie de actividades
– Ser el responsable de una serie
de artefactos
•
•
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.
•
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
“business use 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
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Estática
VISIÓN
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
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
Prototipar una 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
DEPENDENCIA ENTRE LOS CASOS DE USO Y LOS
DEMÁS MODELOS
<<communicate>>
Administrador
Identificacion
Consulta
<<extend>>
Especificado por
Modelo de análisis
Realizado por
Distribuido por
Implementado por
Modelo de diseño
Verificado por
Modelo de despliegue
Modelo de
implementación
X
OX
X
OX
X
OX
Modelo de prueba
Casos
de uso
• 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
• Usados para verificar
• Que se hayan capturado todos los requerimientos.
• 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.
Clases
•Son los diagramas más frecuentemente usados y se les
puede considerar con tres perspectivas posibles:
•Conceptual: muestra las entidades del mundo real
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
Secuencia
•Destacan:
•Mensajes enviados entre los objetos.
•Orden secuencial entre los mensajes.
•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
Colaboración
• Destacan:
• Mensajes enviados entre los objetos
• Enlaces entre los objetos
• 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 o
negocio.
• Muestran actividades y procesos.
Actividades
• Destacan:
• Condiciones y flujos alternativos.
• Tareas y procesos concurentes.
• 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.
Estados
• Destacan:
• Estados
• Transiciones y condiciones de las transiciones
• 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.
Componentes
• Sin embargo se usan más bien para capturar la
Organización de los componentes de Software (EXE,
DLL, EJB, etc.)
• Destacan:
• Dependencias entre los componentes.
• Usados Para Modelar las Relaciones entre el Software y
el Hardware.
Distribución
• Mapeo de los Componentes de Software a los Nodos de
Hardware.
• Típicamente contienen elementos tales como:
• Servidores.
• Procesadores.
• 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
eleva el nivel de
abstracción
Clases
Código
DISCIPLINAS
Proceso
1.
2.
3.
4.
5.
6.
Modelado del negocio: describe la estructura
y la dinámica de la organización.
Requisitos: describe el método basado en
casos de uso para extraer los requisitos.
Análisis y diseño: describe las diferentes
vistas arquitectónicas.
Implementación: tiene en cuenta el desarrollo
de software, la prueba de unidades y la
integración.
Pruebas: describe los casos de pruebas, los
procedimientos y las métricas para evaluación
de defectos.
Despliegue: cubre la configuración del sistema
entregable.
Soporte
1.
2.
3.
Gestión de configuraciones:
controla los cambios y mantiene
la integridad de los artefactos de
un proyecto.
Gestión del Proyecto: describe
varias estrategias de trabajo en
un proceso iterativo.
Ambiente:
cubre
la
infraestructura necesaria para
desarrollar un sistema.
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
Usuario
Prototipo de interfaz de usuario
Arquitecto
Descripción de la arquitectura
(vista del modelo de casos de
uso)
ANÁLISIS
Trabajador
Arquitecto
Responsable de (artefacto)
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
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.
DISEÑO
Trabajador
Arquitecto
Responsable de (artefacto)
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
Arquitecto
Responsable de (artefacto)
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