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).
Proceso de Ingeniería de Software
Requerimientos
Nuevos o modificados Nuevo o modificado
Sistema
EL PROBLEMA
•Si un proceso es utilizado, equipos funcionales diferentes normalmente utilizan procesos y lenguajes de modelación inconsistentes.
Requerimientos
Pruebas
Análisis
Diseño
•La mayoría de los proyectos de softwareutilizan procesos que no están biendefinidos. 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)
AdministradorBase de Datos
Líder deProyecto
Analista
Diseñador/Desarrollador
Ingeniero deDesempeño
Pruebas
Administrador deConfiguración
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.
Refinamientos sucesivos.
Habilita una fácil retroalimentación de usuario.
Metas específicas.
El progreso es medido conforme avanzan las
implementaciones.
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
Planeamientoinicial
Planeamiento
Requerimientos
Análisis y Diseño
Implementación
Prueba
Distribución
Evaluación
Ambiente deAdministración
Cada iteración resulta en un release ejecutable
RUPVentajas 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 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”.
Controlar Cambios
Administrar requerimientos
ArquitecturasBasadas en
Componentes
DesarrollarIterativame
nte
Verificar Calidad
ModelizarVisualmente
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 Visualde 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 trabajoControla 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 RUPInicio 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.
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.
HITO
Inicio Elaboración Construcción Transición
Objetivos del Ciclo de Vida
Arquitectura de Ciclo de Vida
CapacidadOperacional
Producto
•Las partes interesadas deben acordar el alcance y la estimación de tiempo y costo.
•Comprensión de los requerimientos plasmados en casos de uso.
•Condiciones de éxito de la elaboración:
–¿Es estable la visión del producto?–¿Es estable la arquitectura?–¿Las pruebas de ejecución 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 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?
•Condiciones de éxito:
– ¿Se han alcanzado los objetivos fijados en la fase de Inicio ?
– ¿El usuario está satisfecho ?
Relación entre Diagramas UML y Disciplinas de RUP
Disciplina Diagrama
Requerimientos Diagramas de Casos de Uso
AnálisisRefinamiento y documentación de los casos de usos
Definición preliminar de clases y Diagramas de Interacción (Secuencia y Colaboraciones)
Diseño
EmpaquetamientoDiagramas de Interacción de diseño (Secuencia y
Colaboraciones)Diagrama de Clases de diseño
Modelo de Datos
ImplementaciónDiagrama de Componentes
Diagrama de Despliegue
AdministraciónAmbiente
Modelación de Negocios
Implementación
Prueba
Análisis y Diseño
Iteración(es)Preliminar
Iter.#1
FasesDisciplinas de Procesos
Iteraciones
Disciplinas de 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
DEFINICIONES
Trabajador Actividades• Un trabajador define el
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
• Una actividad es una unidad de trabajo que 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
• 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 deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
FLUJOS DE TRABAJO
VISIÓNEstática
Dinámica
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.
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 ASIGNADASGestor 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
XOX
XOX
XOX
Modelo de análisis Modelo de diseño
Modelo de despliegue Modelo de implementación
Modelo de prueba
Especificado por Realizado por Distribuido por Implementado por
Verificado por
DEPENDENCIA ENTRE LOS CASOS DE USO Y LOS DEMÁS MODELOS
Identificacion
Administrador Consulta<<extend>>
<<communicate>>
• 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.
Casos de uso
• 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 realcon sus relaciones.
• Especificación: uestra la estructura del sistemao sus partes, destacando las interfaces.
• Implementación: el diseño del código fuente.Clases
• 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.•Un escenario concreto, sin condiciones.
• Útiles tanto en análisis (identificación de clases), como en diseño (especificación de componentes).
Secuencia
• 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
• Útiles tanto en análisis (identificación de clases), como en diseño (especificación de componentes).
Colaboración
• Usados para representar el comportamiento del sistema o negocio.
• Muestran actividades y procesos.
• 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.
Actividades
• 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• Actividades realizadas
• Típicamente usados para describir ciclo de vida de un objeto.
Estados
• 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.)
• Destacan:• Dependencias entre los componentes.
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.• Impresoras.• Redes computacionales.
Distribución
• 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 UsoDiagramas de ClasesDiagramas de EstadosDiagramas de ComponentesDiagramas de Implementación
Código
Clases
Subsistemas
Modelización Visualeleva el nivel de
abstracción
DISCIPLINAS
Proceso Soporte1. Modelado del negocio: describe
la estructura y la dinámica de la organización.
2. Requisitos: describe el método basado en casos de uso para extraer los requisitos.
3. Análisis y diseño: describe las diferentes vistas arquitectónicas.
4. Implementación: tiene en cuenta el desarrollo de software, la prueba de unidades y la integración.
5. Pruebas: describe los casos de pruebas, los procedimientos y las métricas para evaluación de defectos.
6. Despliegue: cubre la configuración del sistema entregable.
1. Gestión de configuraciones: controla los cambios y mantiene la integridad de los artefactos de un proyecto.
2. Gestión del Proyecto: describe varias estrategias de trabajo en un proceso iterativo.
3. Ambiente: cubre la infraestructura necesaria para desarrollar un sistema.
WORKFLOW
REQUERIMIENTOSTrabajador 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 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 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 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
Top Related