1. Grado en Ingeniería Informática
Lunes, 10 de Octubre de 2011

2. PROCESO UNIFICADO RATIONAL (RUP)
• Definición
01
• Aspectos característicos
02
• Mejores prácticas
03
• Fases del proceso
04
2

3. PROCESO UNIFICADO
DEFINICIÓN
 Proceso de software genérico
 Enfoque disciplinado en la asignación de tareas y
responsabilidades
 Está basado en componentes e interfaces bien definidas
 Utiliza el Lenguaje Unificado de Modelado (UML)
3

4. PROCESO UNIFICADO
ASPECTOS CARACTERÍSTICOS
Dirigido
por casos
de Uso
Centrado en
la
Arquitectura
Iterativo e
Incremental
4

5. 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?
5

6. PROCESO UNIFICADO
CENTRADO EN LA ARQUITECTURA
 Describe diferentes vistas del sistema
 Incluye los aspectos estáticos y dinámicos más
significativos
 La arquitectura y los casos de uso evolucionan en
paralelo
6

7. 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 que extienden la usabilidad
 Trata los riesgos más importantes
 En cada iteración se persiguen unos objetivos concretos
7

8. PROCESO UNIFICADO
ITERATIVO E INCREMENTAL
8

9. PROCESO UNIFICADO
MEJORES PRÁCTICAS
Desarrollo iterativo de software
Gestión de requisitos
Arquitecturas basadas en componentes
Modelado visual del software
Verificación de la calidad del software
Control de cambios del software
9

10. PROCESO UNIFICADO
DESARROLLO ITERATIVO
 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
requisitos a la vez que se va haciendo crecer el sistema.
 Se abordan las tareas con más riesgo primero.
 Con esto se logra reducir los riesgos del proyecto y tener un
subsistema ejecutable tempranamente.
10

11. PROCESO UNIFICADO
GESTIÓN DE REQUISITOS
 El proceso describe cómo:
– Obtener los requisitos
– Organizarlos
– Documentar la funcionalidad y restricciones
– Rastrear y documentar decisiones
– Captar y comunicar los requisitos del negocio
 Los casos de uso y los escenarios indicados por el proceso
han probado ser una buena forma de captar los requisitos y
guiar el diseño, la implementación y las pruebas.
11

12. PROCESO UNIFICADO
ARQUITECTURAS BASADAS EN COMPONENTES
 El proceso se basa en diseñar tempranamente una
arquitectura base ejecutable.
 La arquitectura debe ser:
– Flexible
– Fácil de modificar
– Intuitivamente comprensible
– Promueve la reutilización de componentes
 RUP apoya el desarrollo basado en componentes, tanto
nuevos como preexistentes.
12

13. PROCESO UNIFICADO
MODELADO VISUAL DEL SOFTWARE
 El modelado es importante porque ayuda al equipo a
visualizar, especificar, construir y documentar la estructura y
comportamiento de la arquitectura del sistema.
 Permiten:
– La comunicación en el equipo de desarrollo
– Fácil de entender
– Fácil de modificar
 UML es la base del modelamiento visual.
13

14. PROCESO UNIFICADO
VERIFICACIÓN DE LA CALIDAD DEL SOFTWARE
 La funcionalidad y el rendimiento son factores esenciales.
 Ayuda a planificar, diseñar, implementar, ejecutar y evaluar
pruebas que verifiquen estas cualidades.
 La verificación y administración de la calidad durante el ciclo
de vida del proyecto es esencial para lograr mantener los
objetivos y el tiempo estimado de desarrollo.
14

15. PROCESO UNIFICADO
CONTROL DE CAMBIOS DEL SOFTWARE
 Los cambios son inevitables, pero es necesario evaluar si
éstos son necesarios y rastrear su impacto.
 Indica como controlar, rastrear y monitorizar los cambios
dentro del proceso iterativo de desarrollo.
15

16. PROCESO UNIFICADO
DIMENSIÓN DEL PROCESO
Flujos de Concepción Elaboración Construcción Transición
trabajo /
Fases
Requisitos
Análisis
Diseño
Implementac.
Test
Iter Iter --- --- --- --- --- --- Iter Iter
#1 #2 #n-1 #n
16

17. PROCESO UNIFICADO
FASES DEL PROCESO UNIFICADO
Concepción Elaboración
• Los modelos del caso de uso
• De requerimientos
Planificación • Del diseño
• De la implementación
• Del despliegue
Comunicación Modelado
Despliegue Construcción
Incremento del Software
Construcción
Producción Transición
17

18. DESARROLLO ÁGIL
01
• Manifiesto por el desarrollo ágil de software
02 • La agilidad y el coste del cambio
03 • Un proceso ágil
04 • Principios de agilidad
05 • Programación extrema (XP)
06 • Otros modelos ágiles
07 • Scrum
18

19. DESARROLLO ÁGIL
MANIFIESTO POR EL DESARROLLO ÁGIL
Los individuos
El software que
y sus
funciona, más
interacciones,
que la
sobre los
documentación
procesos y las
exhaustiva
herramientas
La
colaboración Responder al
con el cliente, cambio, mejor
y no tanto la que apegarse
negociación a un plan
del contrato
19

20. DESARROLLO ÁGIL
LA AGILIDAD Y EL COSTE DEL CAMBIO
 Recomienda las estructuras de equipo y las actitudes que
hacen más fácil la comunicación
 Pone énfasis en la entrega rápida de software funcional y
resta importancia a los productos intermedios.
 Adopta al cliente como parte del equipo de desarrollo
 Un plan de proyecto debe ser flexible.
DESARROLLO TRADICIONAL vs DESARROLLO ÁGIL
20

21. DESARROLLO ÁGIL
UN PROCESO ÁGIL
Incrementos de
Adaptable Incrementalmente
software
21

22. DESARROLLO ÁGIL
PRINCIPIOS DE AGILIDAD
Satisfacción al cliente
Adaptación a los cambios
Entregas de software
Trabajo en equipo
Motivación en el trabajo
Diálogo
Software funcional
Desarrollo sostenible
Atención continua
Simplicidad
Organización
Efectividad
22

23. DESARROLLO ÁGIL
PROGRAMACIÓN EXTREMA (XP)
• Historias de usuario
Diseño simple
• Valores Prototipos
• Orden Soluciones en punta
 Valor
 Riesgo
• Velocidad del
proyecto
Planificación Diseño
Prueba Codificación
Lanzamiento
Incremento del Software
Velocidad calculada del
proyecto
Programación por parejas
Prueba unitaria
Pruebas de aceptación Integración continua
23

24. DESARROLLO ÁGIL
OTROS MODELOS ÁGILES
Desarrollo adaptativo de software (DAS)
Scrum
Método de desarrollo de sistemas dinámicos
Cristal
Desarrollo impulsado por las características (DIC)
Desarrollo esbelto de software (DES)
Modelo ágil
Proceso unificado ágil (PUA)
24

25. DESARROLLO ÁGIL
SCRUM
25

26. PRODUCTO - PROCESO
 No hay producto sin proceso, pero el proceso puede matar al
producto
 Si el proceso es deficiente, no cabe duda de que el producto
final sufrirá
 Privilegiar un punto de vista sobre otro supone un error
 El producto y el proceso son tratados como si fueran
contrarios en lugar de ser comprendidos como una dualidad
26

27. PRODUCTO - PROCESO
…La empresa en la que trabajo es resultado de la fusión de dos
y en su momento viví la experiencia del grupo de trabajo
orientado al producto y donde el método brillaba por su
ausencia. Reconozco que el producto final ganaba mucho y que
todos nos sentíamos identificados con nuestros trabajos pero las
desviaciones en los presupuestos y los problemas con los
clientes eran demasiado frecuentes.
Cuando digo que no había metodología me refiero a que no se
controlaban las horas, la tecnología dominaba sobre los
requisitos del cliente, en muchísimas ocasiones ni siquiera
existían esos requisito (un comercial había vendido una web,
venga todos a currar), no había ningún tipo de entrega, etc.. No
había metodología ni externa (de cara al cliente) ni interna (en el
propio proceso de desarrollo).
27

28. PRODUCTO - PROCESO
No funcionaba, en esa línea acabar todos en la calle era
cuestión de tiempo. Y eso les ha pasado a muchos pequeños
estudios que han terminado cerrando: no salen los números.
Solución: hay que poner orden, definamos un método.
Nos vamos la lado contrario, el desarrollo del proyecto se define
por un método definido en un esquema precioso lleno de flechas
y diagramas de alguien que realmente disfruta con el Visio y que
hay que seguir con todo rigor. Resultados: gente cabreada,
alejamiento del desarrollador del producto y, lo peor, productos
mediocres. Además en esa época desarrollábamos proyectos
pequeños y la burocratización del proceso de desarrollo hacía
que tampoco fuesen demasiado rentables; no se puede pasar
más tiempo reunido o comentando incidencias que
desarrollando.
28

29. PRODUCTO - PROCESO
Sin embargo la experiencia fué positiva, de esa larga lista de
procedimientos que implicaba el desarrollo de una web fueron
quedando los realmente necesarios y, lo más importante, la
gente se fue acostumbrando a asumir las horas que se habían
comprometido, a hacer la parte del trabajo que le correspondía,
a trabajar por fases… todas esas cosas que a muchos os
parecerán lo más normal del mundo pero que no lo son tanto.
Finalmente y una vez asumida e interiorizada una metodología
interna que ya está más o menos implícita en cualquier trabajo
podemos volver a orientarnos al producto y esto se nota
muchísimo en tres cosas: satisfacción de los clientes, mejora de
los productos e identificación de los desarrolladores con lo que
hacen.
29

30. PRODUCTO - PROCESO
Resumiendo, creo que en ningún caso puede haber una
orientación al producto sin tener asumido un proceso
metodológico básico y que funcione pero si se cumple ese
requisito lo que manda es el producto, es la estrella. Una
empresa de desarrollo web que haga malas webs, que vamos a
decir.
30

31. MUCHAS GRACIAS
31