Proceso Unificado de Desarrollo de Software

Metodologías de Desarrollo Software

​

Javier Sánchez Pérez

Facultad de Informática

Universidad de Las Palmas de Gran Canaria

Contenido

• Parte I: Introducción
• Parte II: Los flujos de trabajo fundamentales
• Parte III: El desarrollo iterativo e incremental

Parte I: Introducción

• El Proceso Unificado
• Personas, Proyecto, Producto y Proceso
• Un proceso dirigido por casos de uso
• Un proceso centrado en la arquitectura
• Un proceso iterativo e incremental

El Proceso Unificado

• Está basado en componentes e interfaces bien definidas
• Utiliza el Lenguaje Unificado de Modelado (UML)
• Aspectos característicos:
• Dirigido por casos de uso
• Centrado en la arquitectura
• Iterativo e incremental

El Proceso Unificado�Dirigido por casos de uso

• Caso de uso: Fragmento de funcionalidad que proporciona al usuario un resultado importante
• Modelo de casos de uso: Funcionalidad total del sistema
• ¿Qué debe hacer el sistema … para cada usuario?
• Guían el proceso de desarrollo

El Proceso Unificado�Centrado en la arquitectura

• Describe diferentes vistas del sistema
• Incluye los aspectos estáticos y dinámicos más significativos
• Es la forma del software
• La arquitectura y los casos de uso evolucionan en paralelo
• Responsable: el arquitecto:
• Empieza por la parte que no es específica de los casos de uso
• Trabaja con casos de uso claves
• Progresa con la especificación de más casos de uso

​

El Proceso Unificado�Iterativo e incremental

• Se divide el trabajo en mini-proyectos
• Cada mini-proyecto es una iteración que resulta en un incremento
• La iteración
• Trata un conjunto de casos de uso
• Trata los riesgos más importantes
• En cada iteración se persiguen unos objetivos concretos

El Proceso Unificado�Iterativo e incremental

• Beneficios de un proceso iterativo controlado:
• Coste del riesgo a un solo incremento
• Reduce el riesgo de no sacar el producto en el calendario previsto
• Acelera el ritmo de desarrollo
• Se adapta mejor a las necesidades del cliente

​

El Proceso Unificado�Iterativo e incremental

Personas, Proyecto, Producto y Proceso

• Personas
• Arquitectos, desarrolladores, ingenieros de prueba, personal de gestión, usuarios, clientes
• El proceso de desarrollo afecta a las personas (viabilidad, gestión del riesgo, estructura de los equipos, planificación, comprensión, cumplimiento)
• Formación, entrenamiento y experiencia
• De recurso a trabajador (puestos que asumen las personas)
• Cada trabajador tiene un conjunto de responsabilidades y lleva a cabo un conjunto de actividades

Personas, Proyecto, Producto y Proceso

• Proyecto
• Elemento organizativo de gestión
• El proyecto construye el producto
• Secuencia de cambio. El sistema evoluciona
• Serie de iteraciones. Cada iteración implementa un conjunto de casos de uso o atenúa algunos riesgos. Mini-proyecto
• Patrón organizativo. Tipos de trabajadores y artefactos a conseguir

Personas, Proyecto, Producto y Proceso

• Producto
• Artefactos que se crean durante la vida del proyecto
• Artefactos: Modelos, código, ejecutables, documentación, diagramas UML, bocetos de la interfaz de usuario, prototipos, componentes, planes de prueba
• Artefactos de ingeniería y de gestión
• Colección de modelos

Personas, Proyecto, Producto y Proceso

• Proceso
• Conjunto de actividades para crear el producto
• Es una plantilla para crear proyectos (Instancia del proceso)
• Se define en términos de flujos de trabajo (conjunto de actividades)
• Se identifican trabajadores y artefactos
• Adaptación o especialización del proceso
• Se utilizan diagramas de actividad de UML para describir los flujos de trabajo

Ejemplo: Captura de requisitos

Personas, Proyecto, Producto y Proceso

• Herramientas
• Automatizan las actividades definidas en el proceso
• Mantienen las cosas estructuradas, gestionan gran cantidad de información y nos guían
• Gracias a ellas se obtiene un proceso más formal y preciso
• El proceso dirige las herramientas
• Deben ser fáciles de utilizar y permitir reutilizar

Un proceso dirigido por casos de uso

• Se capturan requisitos de usuario a través de casos de uso
• Son fundamentales para:
• Identificar y especificar clases, subsistemas e interfaces
• Identificar y especificar casos de prueba
• Planificar las iteraciones e integración del sistema
• Nos guían a través de los flujos de trabajo

Un proceso dirigido por casos de uso

• En cada iteración se identifican e implementan unos cuantos casos de uso
• Los casos de uso sirven para idear la arquitectura
• Se seleccionan los casos de uso más representativos
• Se utiliza como partida para escribir el manual de usuario

Un proceso dirigido por casos de uso

• Requisitos funcionales a través de casos de uso
• Requisitos no funcionales:
• Se “adjuntan” a los casos de uso
• Se guardan en una lista

​

Sacar dinero

Ingresar dinero

Transferencia

Un proceso dirigido por casos de uso

• Actores: usuarios, otros sitemas, hardware, software, etc.
• Un usuario puede actuar como varios actores
• Varios usuarios pueden actuar como un mismo tipo de actor
• La comunicación con el sistema se realiza mediante el paso de mensajes

Un proceso dirigido por casos de uso

• Modelo de análisis a partir de casos de uso
• Crece incrementalmente
• Se especifican a través de diagramas de clases y de colaboración
• Al principio se examinan unos pocos casos de uso y se crean sus realizaciones
• Cada clasificador puede participar en varias realizaciones distintas con distintos roles
• Clases estereotipadas de análisis (entorno, control y entidad)

Un proceso dirigido por casos de uso

Sacar dinero

Modelo de casos de uso

Modelo de análisis

«trace»

Realización de un caso de uso (análisis):

Un proceso dirigido por casos de uso

Sacar dinero

Ingresar dinero

Transferencia

Modelo de casos de uso

Modelo de análisis

Un proceso dirigido por casos de uso

Diagrama de colaboración para describir una realización:

Un proceso dirigido por casos de uso

• Modelo de diseño a partir del modelo de análisis
• Se adapta al entorno de implementación
• Se define con los mismos diagramas
• El modelo de diseño es más “físico” y el modelo de análisis más “conceptual”

Un proceso dirigido por casos de uso

Dispositivo de visualización

Sensor de salida

Teclado

Alimentador de la salida

Lector de tarjetas

Contador de efectivo

Retirada de efectivo

Gestor de Cliente

Gestor de Transacciones

Cuenta

Gestor de Cuentas

Clase Persistente

«trace»

«trace»

«trace»

«trace»

Modelo de análisis

Modelo de diseño

Un proceso dirigido por casos de uso

Un proceso dirigido por casos de uso

Un proceso dirigido por casos de uso

• Las clases se agrupan en subsistemas

Un proceso dirigido por casos de uso

• Modelo de implementación a partir del modelo de diseño

Sensor de salida

Alimentador de la salida

Contador de efectivo

Gestor de Cliente

Modelo de diseño

Modelo de implementación

«compilation»

«trace»

«trace»

Un proceso dirigido por casos de uso

• Pruebas
• Modelo de pruebas compuesto por:
• Casos de prueba
• Procedimientos de prueba

Un proceso centrado en la arquitectura

• La arquitectura se representa mediante vistas del modelo del sistema
• Representa elementos significativos de cada modelo
• Es una descripción “pequeña” del sistema
• Sirve como visión común para los desarrolladores
• Responsable: el arquitecto del software

Un proceso centrado en la arquitectura

• Casos de uso y arquitectura

​

Un proceso centrado en la arquitectura

• La arquitectura es necesaria para:
• Comprender el sistema: Los desarrolladores, directivos, clientes y usuarios deben estar capacitados
• Organizar el desarrollo: Subsistemas, interfaces bien definidas y responsables por subsistemas
• Fomentar la reutilización: Desarrollo de componentes reutilizables
• Hacer evolucionar el sistema

Un proceso centrado en la arquitectura

​

​

​

​

​

• Negociar con el cliente para ajustar los casos de uso

Un proceso centrado en la arquitectura

• La arquitectura se desarrolla principalmente en la fase de elaboración
• ¿Qué casos de uso tener en cuenta?
• Los que representen riesgos más importantes
• Los más importantes para el usuario
• Funcionalidades significativas
• Línea base de la arquitectura
• Esqueleto con pocos músculos

Un proceso centrado en la arquitectura

• Línea base de la arquitectura:
• Sistema pequeño y flaco
• Versión de todos los modelos del sistema
• Arquitectura estable
• Descripción de la arquitectura
• Constituye los pilares del sistema
• Utilización de patrones de diseño

Un proceso centrado en la arquitectura

• Descripción de la arquitectura
• Conjunto de vistas de los modelos de la línea base de la arquitectura
• Incluye elementos arquitectónicamente significativos
• Debe mantenerse actualizada
• Incluye requisitos adicionales (seguridad, distribución, concurrencia, etc.)
• Destaca los temas de diseño más importantes

Un proceso centrado en la arquitectura

• Descripción de la arquitectura
• Elementos privados de los subsistemas no suelen ser significativos
• Se obtiene a partir de una fracción de los casos de uso
• Menos del 10% de las clases son relevantes
• La mayoría de la funcionalidad es fácil de implementar a partir de la arquitectura
• El arquitecto crea la arquitectura

Un proceso centrado en la arquitectura

• La vista de la arquitectura del modelo de casos de uso
• Se representan los actores y casos de uso más importantes

​

Sacar dinero

Un proceso centrado en la arquitectura

• La vista de la arquitectura del modelo de diseño
• Subsistemas e interfaces más importantes
• Clases muy importantes (activas)

Gestor de Cliente

Gestor de Cuentas

Gestor de Transacciones

ITransferen

«subsystem»

Gestión de Cuentas

«subsystem»

Transacciones

IRetirada

IEntrega

«subsystem»

Interfaz del CA

Un proceso centrado en la arquitectura

• La vista de la arquitectura del modelo de despliegue
• Arquitectura física del sistema
• Los objetos activos se asignan a los nodos

​

Un proceso centrado en la arquitectura

• La vista de la arquitectura del modelo de implementación
• Correspondencia entre modelos de diseño y despliegue
• Subsistema de servicio →componente

​

Un proceso iterativo e incremental

• Objetivos:
• Atenuación de riesgos
• Obtención de una arquitectura robusta
• Gestión de requisitos cambiantes
• Permitir cambios tácticos
• Conseguir una integración continua
• Conseguir un aprendizaje temprano

Un proceso iterativo e incremental

• Iteración genérica:
• Planificación
• Requisitos
• Análisis
• Diseño
• Implementación
• Prueba
• Evaluación de la iteración

Un proceso iterativo e incremental

• Fases del proceso:
• Inicio: Objetivos del ciclo de vida
• Establecer ámbito del sistema
• Reducir peores riesgos
• Preparar el análisis del negocio
• Elaboración: Arquitectura del ciclo de vida
• Obtener línea base de la arquitectura
• Capturar mayoría de requisitos
• Reducir siguientes riesgos

Un proceso iterativo e incremental

• Fases del proceso
• Construcción: Funcionalidad operativa inicial
• Desarrollo del sistema entero
• Transición: Versión del producto
• Producto preparado para su entrega al usuario
• Se enseña a los usuarios a utilizarlo

Referencias

• Ivar Jacobson, Grady Booch, James Rumbaugh, “El Proceso Unificado de Desarrollo Software”, Addison Wesley, 1999