Grado en Ingeniería InformáticaLunes, 10 de Octubre de 2011

RUP / DESARROLLO ÁGIL.

PRODUCTO - PROCESO

2

PROCESO UNIFICADO RATIONAL (RUP)

01• Definición

02• Aspectos característicos

03• Mejores prácticas

04• Fases del proceso

3

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)

PROCESO UNIFICADO

4

ASPECTOS CARACTERÍSTICOSPROCESO UNIFICADO

Dirigido por casos

de Uso

Centrado en la

Arquitectura

Iterativo e Incremental

5

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?

PROCESO UNIFICADO

6

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

PROCESO UNIFICADO

7

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

PROCESO UNIFICADO

8

ITERATIVO E INCREMENTALPROCESO UNIFICADO

9

MEJORES PRÁCTICASPROCESO UNIFICADO

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

10

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.

PROCESO UNIFICADO

11

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.

PROCESO UNIFICADO

12

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.

PROCESO UNIFICADO

13

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.

PROCESO UNIFICADO

14

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.

PROCESO UNIFICADO

15

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.

PROCESO UNIFICADO

16

DIMENSIÓN DEL PROCESOPROCESO UNIFICADO

Iter #n

------------Iter #2

Test

Iter #n-1

------Iter #1

Implementac.

Diseño

Análisis

Requisitos

TransiciónConstrucciónElaboraciónConcepciónFlujos de trabajo / Fases

17

FASES DEL PROCESO UNIFICADOPROCESO UNIFICADO

Comunicación

Planificación

Modelado

Despliegue

Incremento del Software

Construcción

Concepción Elaboración

Construcción

TransiciónProducción

• Los modelos del caso de uso• De requerimientos• Del diseño• De la implementación• Del despliegue

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

19

MANIFIESTO POR EL DESARROLLO ÁGILDESARROLLO ÁGIL

Los individuos y sus

interacciones, sobre los

procesos y las herramientas

El software que funciona,

más que la documentación

exhaustiva

La colaboración con el cliente, y no tanto la negociación del contrato

Responder al cambio, mejor que apegarse

a un plan

20

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 ÁGIL

DESARROLLO TRADICIONAL vs DESARROLLO ÁGIL

21

UN PROCESO ÁGILDESARROLLO ÁGIL

Adaptable IncrementalmenteIncrementos de

software

22

PRINCIPIOS DE AGILIDADDESARROLLO ÁGIL

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

23

PROGRAMACIÓN EXTREMA (XP)DESARROLLO ÁGIL

Planificación Diseño

Prueba

Incremento del SoftwareVelocidad calculada del

proyecto

Codificación

• Historias de usuario• Valores• Orden

Valor Riesgo

• Velocidad del proyecto

Diseño simple

Programación por parejas

Prueba unitariaIntegración continuaPruebas de aceptación

PrototiposSoluciones en punta

Lanzamiento

24

OTROS MODELOS ÁGILESDESARROLLO ÁGIL

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)

25

SCRUMDESARROLLO ÁGIL

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

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).

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.

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.

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.

31

MUCHAS GRACIAS