Presentaci

1
3.- Introducción al Proceso Unificado Justo N.
Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA
INFORMÁTICA
2
Qué es el Proceso Unificado

• Unified Software Development Process
• Definido por Ivar Jacobson, James Rumbaugh y
  Grady Booch.
• Un proceso define QUIÉN está haciendo QUÉ, CUÁNDO
  y CÓMO para llegar a un objetivo.
• En la ingeniería de sw el objetivo es construir
  un producto sw o mejorar uno ya existente dentro
  de un esquema temporal, económico y de calidad.
• Un proceso de desarrollo es el conjunto de
  actividades necesarias para transformar los
  requisitos de un usuario en un sistema software.
• El proceso unificado no es un único proceso, sino
  un framework genérico.

3
Características

• Es guiado por casos de uso (use-case driven)
• Se centra en la arquitectura (architecture-centric
  )
• Es iterativo (iterative)
• Es incremental (incremental)

4
Use-case driven (I)

• Un sistema sw existe para servir a sus usuarios.
• Por tanto, tiene sentido saber qué es lo que los
  usuarios quieren, no? Pues no siempre es así.
• Un usuario no sólo es la persona que lo utiliza,
  sino cualquier sistema que haga uso de la
  aplicación creada -sistema de gestión, otro
  componente externo, los diferentes tipos de
  usuarios humanos, etc.-
• Las interacciones entre los usuarios y el sistema
  se denominan casos de uso -use cases-. Ya los
  estudiaremos en detalle en el flujo de requisitos.

5
Ejemplo de caso de uso
6
Use-case driven (y II)

• Los casos de uso son los que dirigen toda la
  aplicación.
• A partir de estos casos de uso se dirige todo el
  proceso de desarrollo
• Se crea el diagrama de análisis y el de diseño.
• La implementación se realiza caso de uso a caso
  de uso.
• Las pruebas se realizan sobre los casos de uso.
• Pero no están sólos
• los casos de uso van de la mano de la
  arquitectura del sistema, que también influye en
  cómo se va a realizar el sistema.

7
Architecture-centric (I)

• El proceso se basa en la arquitectura del sw.
• Su papel es parecido al de la arquitectura en la
  construcción de edificios.
• El concepto de arquitectura sw conlleva los
  aspectos tanto estáticos como dinámicos del
  sistema.
• Estáticos diagrama de herencia, diagrama de
  paquetes.
• Dinámicos diagrama de secuencia, de actividad,
  etc.
• Se ve influido por otros temas tales como el
  sistema operativo sobre el que corre el sistema,
  hw, comunicaciones.
• Todo producto tiene Forma y Función
• Función casos de uso.
• Forma arquitectura del sistema.

8
Architecture-centric (y II)

• Pasos básicos del arquitecto
• Crear un boceto de la arquitectura comenzando con
  la parte no específica de los casos de uso
  -plataforma-.
• Aunque esta parte es independiente de los casos
  de uso, el arquitecto ya debe tener una idea
  global de los casos de uso.
• A partir de los casos de uso críticos, se crean
  subsistemas.
• Cuantos más casos de uso se descubren, la
  arquitectura va creciendo y madurando de manera
  iterativa e incremental.
• El proceso continua hasta que el sistema es
  estable.

9
Iterative Incremental (I)

• El desarrollo de un producto comercial es un
  proceso largo, complicado y arriesgado.
• Se suele acometer a través de mini-proyectos.
  Cada mini-proyecto es una iteración del producto
  final.
• El final de cada mini-proyecto es un incremento
  del producto final.
• Un incremento no tiene por qué ser aditivo -sobre
  todo al principio, pueden ser reemplazos de
  implementación de casos de uso-.
• Cada iteración trata un conjunto de casos de uso,
  en cada momento los más críticos que queden.

10
Iterative Incremental (y II)

• Ventajas de las iteraciones controladas
• Se reduce el riesgo de coste.
• Si hay que repetir la iteración, sólo se pierde
  ese tiempo.
• Antes existía el riesgo de tener que repetir el
  proyecto completo por un error del comienzo.
• Se reduce el riesgo de tiempo de salida al
  mercado.
• Los desarrolladores -y el equipo en general-
  mejoran sus tiempos al tener objetivos claros y
  cercanos en el tiempo.
• Y, repitiendo lo anterior las necesidades del
  usuario no siempre pueden definirse al comienzo
  del proyecto -la famosa frase de el cliente no
  tiene ni idea de lo que quiere se repite tantas
  veces que no será que estamos planteando mal el
  esquema de la solución?-.

11
Vida del Proceso Unificado

• El proceso se repite sobre una serie de CICLOS,
  cada uno de los cuáles termina con una release
  versión entregable del producto.
• Cada versión de una herramienta comercial que se
  vende en las tiendas es una release -entrega-.
• Cada ciclo consta de cuatro FASES
• Concepción
• Elaboración
• Construcción
• Transición
• Cada fase se puede subdividir en iteraciones, tal
  y como vimos anteriormente.

12
Representaciones del Producto SW (I)

• Un producto software ha de contar con
• El modelo de casos de uso -use-case model- casos
  de uso y sus relaciones con los usuarios.
• El modelo de análisis -analysis model-
  refinamiento de los casos de uso y conjunto
  básico de objetos.
• El modelo de diseño -design model- define la
  estructura estática y dinámica del sistema.
• El modelo de implementación -implementation
  model- componentización y desarrollo de los
  casos de uso.
• El modelo de despliegue -deployment model-
  define los nodos físicos y la relación entre los
  componentes y esos nodos.
• El modelo de pruebas -test model- verificación
  de los casos de uso.
• Arquitectura del sistema -system architecture-.

13
Representaciones del Producto SW (y II)
dependencias
14
Visión global del ciclo de vida
15
Fases del Proceso Unificado (I)

• Como hemos dicho antes, cada ciclo se divide en
  cuatro fases concepción, elaboración,
  construcción y transición.
• Una fase acaba de un hito -milestone-
• Un hito ocurre cuando se encuentran disponibles
  un conjunto de artefactos, es decir, modelos o
  documentos en un estado prescrito determinado.
• Por qué?
• Decisiones a tomar antes de pasar a la siguiente
  fase.
• Monitorización del trabajo por parte de
  desarrolladores y gestores.
• Categorización de los datos obtenidos análisis.

16
Fases del Proceso Unificado (II)

• Concepción -inception-
• A partir de la idea se desarrolla la visión del
  producto final y se elabora el caso de negocio.
• Esta fase responde a las siguientes cuestiones
• Qué va a realizar el sistema principalmente.
• Cómo sería un esqueleto de arquitectura del
  sistema.
• Cuál es el plan de proyecto y cuánto costaría.

17
Fases del Proceso Unificado (III)

• Elaboración -elaboration-
• Se diseña la arquitectura del sistema
• desde todos los puntos de vista -modelos del
  sistema-.
• Se definen todos los casos de uso.
• Los casos de uso más críticos se desarrollan
• ARCHITECTURE BASELINE la línea base de la
  arquitectura.
• Al final de esta fase, el gestor ya es capaz de
  planificar las actividades y recursos necesarios
  para completar el proyecto
• Hemos logrado la estabilidad suficiente en casos
  de uso, arquitectura y planificación como para
  asegurar el éxito del proyecto?

18
Fases del Proceso Unificado (IV)

• Construcción -construction-
• El producto se construye.
• Ahora se añade el músculo al esqueleto.
• La línea base crece hasta convertirse en el sw
  completo.
• Se supone que la arquitectura del sistema es
  estable, a pesar de que puede haber
  modificaciones menores.
• Al final de la fase el producto está terminado
  -todos los casos de uso implementados-, aunque
  todavía nos podemos encontrar con bugs
• Satisface el producto las necesidades del
  usuario?

19
Fases del Proceso Unificado (y V)

• Transición -transition-
• Período durante el cuál el SW está en beta
  release.
• Otras tareas
• Manufactura.
• Formación, ayuda en línea,
• Corrección de defectos.

20
Las Cuatro Ps o algo así

• Las cuatro Ps en el Proceso Unificado
• People Peña )
• Arquitectos, desarrolladores, probadores,
  usuarios,
• Cuando hablamos de Gente hablamos de seres
  humanos. Cuando hablemos de workers no tiene
  que ser así.
• Project Proyecto
• Elemento de organización dentro del cuál el
  producto es gestionado y desarrollado.
• Product Producto
• Artefactos creados durante la vida del proyecto
  modelos, códiugo fuente, ejecutables,
  documentación.
• Process Proceso
• conjunto completo de actividades necesarias para
  transformar los requisitos del usuario en un
  producto.

21
Relaciones de las Cuatro Ps
Process
Automatización
Plantilla
Tools
People
Project
Participantes
Resultado
Product
22
People (I)

• Obviamente, la gente es crucial para el
  desarrollo de un producto, pero el proceso de
  desarrollo también afecta a la gente dentro de
  él
• El PU ayuda a convertir un proyecto en factible.
  Nadie quiere estar en un barco que se hunde.
• El PU gestiona los riesgos.
• El PU es gestionado por casos de uso, lo cuál
  provoca la creación de grupos pequeños de
  trabajo.
• La descripción de arquitectura ayuda a comprender
  el proyecto como un todo, lo cuál siempre es
  agradable.
• Worker cargos que una persona tiene en un
  proyecto.
• Worker type rol.
• Cada worker es responsable de una serie de
  tareas.
• Un individuo puede ser diferentes workers
  durante la vida de un proyecto.

23
People (y II)
24
Producto

• Un producto es algo más que código os lo juro!
• Artefacto -artifact- cualquier tipo de
  información creada, producida, cambiada o
  utilizada por workers para desarrollar el
  sistema. Tipos
• Engineering artifacts
• Texto.
• Interfaces de usuario, prototipos.
• Documentación técnica.
• Código.
• MODELO abstracción del sistema, que especifica
  el sistema modelado desde un punto de vista y un
  cierto grado de abstracción -impuesto por los
  workflows-.
• Management artifacts
• Planificaciones.
• Plan de proyecto.
• Gestión de recursos.
• ...

25
Bibliografía

• Artículos
• Rational Unified Process. Best practices for
  Software Development Teams. Rational Software.
• Using the Rational Unified Process for Small
  Projects Expanding upon eXtreme Programming. G.
  Pollice, Rational Software.
• Introduction to UML Structural and Use Case
  Modeling. C. Kobryn. Co-chair UML Revision Task
  Force OMG. www.omg.org.
• Enlaces
• Rational www.rational.com