Date post: | 23-Jan-2016 |
Category: |
Documents |
Upload: | marcelo-casas |
View: | 215 times |
Download: | 0 times |
3.- Introducción al 3.- Introducción al Proceso UnificadoProceso Unificado
Justo N. Hidalgo SanzJusto N. Hidalgo Sanz
DEPARTAMENTO DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA INFORMÁTICAINFORMÁTICA
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Características
Es guiado por casos de uso (use-case driven) Se centra en la arquitectura (architecture-
centric) Es iterativo (iterative) Es incremental (incremental)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Ejemplo de caso de uso
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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?-.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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-.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Representaciones del Producto SW (y II): dependencias
Catedral
Modelo de Casos de Uso
Modelo de Pruebas
Modelo de DiseñoModelo de Despliegue
Modelo de Análisis
Modelo de Implementación
especificado porrealizado por
implementado por
distribuido por
verificado por
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Visión global del ciclo de vida
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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?
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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?
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Relaciones de las Cuatro Ps
Process
Product
ProjectTools
People Participantes
AutomatizaciónPlantilla
Resultado
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
People (y II)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.• ...
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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