uc proceso unificado

1

El Proceso Unificado

Prof. Gustavo J. Sabio

de Desarrollo de Software

Alcance de la presentación

Cliente

Entradas Proceso de desarrollo Salida

necesidades actividades varias Producto software

Clienteequiposistemas

MIMI PROCESOADAPTADO

QAQA

2

Algunos conceptos fundamentales

Conjunto de actividades que interactúan o se relacionan para transformar las entradas de clientes en salidas con un valor

agregado.

• actividades aisladas

• aplicación aleatoria

• áreas independientes

• fusionadas sistemáticamente para un fin

• relacionadas y organizadas

• se complementan para objetivo común

Un proceso define QUIÉN hace QUÉ, CUÁNDO, y CÓMO, con un orden que

permite alcanzar un objetivo definido

¿Qué es un proceso?

Algunos conceptos fundamentalesProceso de desarrollo de software

Cliente

• Las necesidades del cliente son transformadas en un producto software

entradas Proceso de desarrollo salida

necesidades actividades varias Producto softwareCliente

equiposistemas

Anál

isis y

Dise

ño

Anál

isis y

Dise

ñoCo

nstr

ucci

ón

Cons

truc

ción

Prue

ba e

inte

grac

ión

Prue

ba e

inte

grac

ión

Desp

liegu

e y

entr

ega

Desp

liegu

e y

entr

ega

Ciclo de vida del desarrollo de software

Mod

elad

o de

Neg

ocio

Mod

elad

o de

Neg

ocio

y Re

quer

imie

ntos

y Re

quer

imie

ntos

3

Construcción de SW – Panorama mundial

• El mundo tecnológico invade todos los ámbitos.

• Los sistemas software son cada vez más:

– Grandes – Complejos - Distribuidos.

• La demanda del mercado es: software de mejor calidad en menor tiempo!

• Se torna sumamente difícil construir y mantener software de buena calidad de manera predecible.

Muchos proyectos fracasan !

• Algunos causas:

– Manejo de requerimientos ad hoc.– Arquitecturas frágiles.– Inconsistencias entre los requerimientos, el diseño

y la implementación.– Prueba insuficiente.– Valoración subjetiva del estado del proyecto.– No se atacan oportunamente los riesgos.– Propagación de cambios no controlada.

4

La necesidad de un método que:

• Proporcione una guía para ordenar las actividades de un equipo.

• Dirija las tareas de cada desarrollador por separado y del equipo como un todo.

• Especifique los productos que deben desarrollarse.

• Ofrezca criterios para el control y la medición de los productos y actividades del proyecto.

¿Para qué tener un proceso?

Un proceso permite repetir las prácticas exitosas, y dejar de lado las infructuosas o al menos mejorarlas.

• Filosofía basada en las “Mejores Prácticas” y aspectos esenciales

• Un conjunto de Artefactos, Actividades y Roles.

• La guía de cuándo y cómo usarlos.

• Promueve una “Visión” y cultura de trabajo común.

• Reduce los riesgos y hace que el proyecto sea mas predecible

• Información especificada con un lenguaje estándar (UML)

¿Qué es el RUP?

5

Antecedentes del RUP

• Fue creado por Ivar Jacobson, para el desarrollo de sistemas en Suecia, trabajando para Eriksson

• Posteriormente fue adoptado por numerosas empresas

• Cuando Jacobson se incorporó a Rational, Objectory fue complementado con las ideas de Booch.

• El proceso se posiciona fuertemente a nivel mundial. Rational es comprada por IBM (2002)

• Hoy se habla del UP. Es inminente su posicionamiento como estándar de la disciplina

Ficha técnica del RUP¿Qué es el RUP®?

•Un proceso de ingeniería de software.•Un framework para procesos de desarrollo•Una amplia librería de contenidos

RUP® como un producto.•Upgrades regulares.•Utiliza tecnología Web.•Puede personalizarse y configurarse de manera especifica.•Integrado con muchas herramientas de desarrollo de Rational.

RUP® como un producto – Beneficios• EL proceso nunca es obsoleto.• Completamente navegable.• Pueden incluirse mejoras locales fácilmente.• Cada departamento maneja su propia versión del proceso.

6

Mapa conceptual de RUP

Algunos conceptos

Artefactos : • Elemento de información producido, modificado o usado por el proceso. Son los productos tangibles del proyecto. • Son usados por los trabajadores para realizar nuevas actividades y son el resultado de esas actividades.

Trabajador : • Es un determinado ROL que define las competencias-habilidades necesarias para desempeñar ese papel dentro del desarrollo de software• Su función hacer una serie de actividades y ser el responsable de una serie de artefactos

Actividades: • Es una unidad de trabajo que se asigna a un trabajador: por ejemplo crear o modificar un artefacto.• Una actividad puede llevar desde un par de horas hasta un par de días, involucra a un solo trabajador responsable y un número acotado de artefactos.

7

Estructura: Ciclo de vida en Fases

•• InicioInicioDefine el alcance del proyecto

•• ElaboraciónElaboraciónPlan de proyecto, especificación de características, arquitectura base

•• ConstrucciónConstrucciónConstruir el producto

•• TransiciónTransiciónDespliegue del producto en el cliente

UP tiene 4 fases:Inicio Elaboración Construcción Transición

tiempo

Grandes Hitos entre las fases

Inicio Elaboración Construcción Transición

tiempo

LCOLCO

Objetivos delCiclo de Vida

LCALCA

Arquitectura delCiclo de Vida

IOCIOC

CapacidadOperativa Inicial

Productoentregado

•Alcance acordado•Riesgos comprendidos y razonables

•Riesgos principales contenidos•Arquitectura estable

•Producto completado•Calidad aceptable

8

Fases e Iteraciones

Inicio Elaboración Construcción Transición

tiempoIter

Tran2

Iter

Tran1

Iter

desa3

Iter

desa2

Iter

desa1

Iter

arq2

Iter

arq1

Iter

inicial

Hitos intermedios: versionesHitos intermedios: versiones

Una Iteración es una secuencia de actividades distintas basadas en establecer un plan y criterios de evaluación, resultando en una

versión ejecutable (interna o externa)

Juntemos todo! : proceso iterativo

Discipline

Las Disciplinas agrupan Las Disciplinas agrupan actividades relacionadas actividades relacionadas

lógicamentelógicamente En una iteración se En una iteración se atraviesan todas las atraviesan todas las

DisciplinasDisciplinas

9

Las Disciplinas producen Modelos

Las Disciplinas guían el desarrollo iterativo

Disciplina

10

Discipline

TRANSICION

• Preparar actividades de distribución.

• Recomendar al cliente sobre hardware necesarios.

• Preparar manuales y otros para la entrega del producto.

• Parametrizar el software.

• Correcciones de defectos y adecuaciones.

ELABORACION

•Crear una línea base para la arquitectura.

•Identificación y mitigación de Riesgos.

•Especificar atributos de calidad (fiabilidad, performance, etc. )

•Recopilar CU para cubrir el 80% de los requisitos funcionales.

•Proponer planificación general (personal, costos, etc.)

CONSTRUCCION

•la descripción y realización de todos los CU.

•La finalización del análisis, diseño, implementación y pruebas.

•Mantener la integridad de la arquitectura.

•Seguimiento y mitigación de los riesgos.

INICIO

•Definir el alcance del sistema propuesto.

•Esbozar una arquitectura candidata

•Identificar Riesgos críticos

•Creación de prototipos (opcional)

Discipline

Modelo RUP en funcionamiento

Características del RUPCaracterísticas del RUP

• Dirigido por Casos de Uso

• Centrado en la Arquitectura

• Iterativo e Incremental

RUP – Recorriendo las Fases.doc

Características principales del RUP

• Está dirigido por los Casos de Uso

• Está centrado en la arquitectura

• Es iterativo e incremental

11

Dirigido por los casos de uso

El proceso avanza a través de las distintas disciplinas, obteniendo sucesivos modelos que parten de los casos de uso.

Dirigido por casos de uso

• Medio sistemático e intuitivo de capturar requisitos funcionales (sólo lo que brinda valor para el usuario)

• Se considera la perspectiva de cada usuario ¿qué necesitan para hacer su trabajo?

• Integrando todas las perspectivas tendremos toda la funcionalidad que se espera del sistema.

¿¿Por quPor quéé casos de uso?casos de uso?

Bibliotecario

Registrar préstamo

Comprar material

12


• Al preguntar ¿¿QuQuéé se quiere que haga el se quiere que haga el sistema para cada actor?sistema para cada actor?

– Mantenernos centrados en la comprensión de cómo el sistema debe dar soporte a cada uno de los usuarios.

– Nos ayuda a abstenernos de sugerir funciones superfluas que ninguno de los usuarios necesita.


La selección de conjunto correcto de casos de uso permite construir una arquitectura robusta.


Ayudan a desarrollar iterativamente.


Involucra a los usuarios, clientes, desarrolladores y a todo el equipo del proyecto

Todos los involucrados deben acordaracordar y consensuar en el

modelo de casos de uso.

Son el punto de partida ideal para explicar como

puede interactuar el usuario con el sistema en los manuales de usuario.

13





Hola!Soy la arquitectura

Centrado en la arquitectura

La arquitectura del sistema es:

Una representación del sistema que incluye los componentes estructurales,

el comportamiento visible de esos componentes para el resto del sistema y el modo en que dichos componentes

interactúan.

Los CU deben encajar en la arquitectura al momento de Los CU deben encajar en la arquitectura al momento de crearlos. La arquitectura debe permitir el desarrollo de crearlos. La arquitectura debe permitir el desarrollo de

los CU requeridos ahora y en el futuro.los CU requeridos ahora y en el futuro.Bibliotecario

Registrar préstamo

Comprar material

14

¿Qué es la arquitectura?RepresentaciRepresentacióón de la arquitectura: el Modelo 4n de la arquitectura: el Modelo 4 + 1+ 1

DOCARQUITECTURA





15

Es iterativo e incremental

El ciclo de vida iterativo

se basa en la evolución de

prototipos ejecutables

que se muestran a los

usuarios y clientes

Iterativo e incremental.

El proceso iterativo está organizado en fases.

Dentro de cada fase el proceso pasa por una

serie de iteraciones e incrementos.

16

Iterativo e incremental.• La estrategia para desarrollar un producto de software en pasos

pequeños y manejables consiste en:

– Planificar un poco.– Especificar, diseñar e implementar un poco.– Integrar, probar, ejecutar un poco en cada iteración.

• Iteraciones, entregas internas y externas y objetivos parciales.

Beneficios vs. Modelo cascada

Atenuación de riesgosAtenuación de riesgos::

17

Iterativo e incremental

Gestión de requisitos cambiantes:

El tener un sistema en funcionamiento parcial en una fase inicial permite contar

con retroalimentación oportuna.

BeneficiosBeneficios

Conseguir una integración continua.

• Cada iteración arroja resultados tangibles.• Al final de cada iteración se superan ciertos riesgos.• El cliente hace su retroalimentación en el momento oportuno• Las sucesivas iteraciones nos indican claramente el estado del proyecto.

Iterativo e incrementalBeneficios de la integración continuaBeneficios de la integración continua

18

Iterativo e incremental

Lograr un aprendizaje tempranoDespués de un par de iteraciones todas

las personas del equipo tienen una buena comprensión de lo que

significan y pretenden los diferentes flujos de trabajo.

BeneficiosBeneficios

Los errores no se pagan tan carosCometer un error no es tan crítico para el proyecto, debido a que se

atenderá en la siguiente iteración.





19

¿En dónde estamos?

Cliente

Entradas Proceso de desarrollo Salida

necesidades actividades varias Producto software

Clienteequiposistemas

MIMI PROCESOADAPTADO

Definir nuestro proceso

• ¿Qué actividades y artefactos se usarán?, ¿cuáles serán optativos? ¿Cuáles se podrá desistir de usarlos?

• ¿Cuánto dura una Fase? ¿Cómo reconocer el momento de cada fase?

• ¿Qué nivel de formalidad debe aplicarse? ¿ Puedo definir formatos propios?

20

Desarrollar software con un proceso

“nuestro Proceso”

RUP y la primera impresión

¿Esto es necesario?

¿De todos estos items, cuáles son aplicables a mi proyecto?

¿El RUP es sólo es para grandes proyectos?

Cuando recorra la extensa cantidad de artefactos, actividades, ydocumentos de RUP, puede suceder que se formule las siguientes

preguntas:

21

Términos de una implementación

• Caso de desarrollo – development case

• Guías – guidelines

• Entorno de desarrollo organizacional

• Proyecto piloto

• Ingeniero de proceso

• Líder de proyecto

Implementación: la experiencia dice…• Motivos de fracaso

– Fallas en la introducción incremental del proceso y las herramientas.

– Falta de apoyo de la dirección

– Sponsors e involucrados mal informados.

– Mala predisposición o incapacidad para el cambio

– Incertidumbre en la Visión y Fundamentos del cambio

22

Un proyecto de implementación exitoso

• Evaluar el proyecto y la organización

• Implementar el proceso y herramientas en forma incremental

• Planificar y dirigir las actividades de entorno

• Usar tutores

• Transmitir que el proceso es de todos(Académicos y expertos de dominio)

• Ser prágmatico y simple(Primero HACER, después mejorar!)

• Comunicar el estado de avance

• Brinde entrenamiento a las personas

Pasos para implementar el proceso y herramientas en una Organización

Diferentes formas de implementación

Una implementación típica

Implementación Rápida

Implementación Cuidadosa

Implementar un ambiente de desarrollo

23


Una implementación típica


Implementación Rápida

24


Implementación cuidadosa


Implementar un ambiente de desarrollo

25

Desarrollar software con “mi” proceso


INICIO ELABORACION CONSTRUCCION TRANSICION

hitos

hitos

hitos

hitos

Beneficios de tener un proceso• Todo el mundo en el equipo comprende lo que tiene que hacer para

desarrollar el producto.

• Se puede medir lo que se está haciendo, saber cómo vamos, qué es lo que sigue....

• La Empresa puede contar con “formación” estandarizada.

• La descripción de la arquitectura ayuda a los stakeholders entender lo que se está desarrollando.

• Se puede planificar y estimar costos de forma efectiva.

• Le brinda garantías a nuestro clientes.

26

Proceso y proyecto

Nuevos proyectos...

Proyecto 1Proyecto 1Proyecto 2Proyecto 2

Proyecto 3Proyecto 3


Caso real: implementación UP

• Organización dedicada al desarrollo de software

• Implementación focalizada en el desarrollo de adaptaciones por cliente

• 1 proyecto piloto

• Mucho consenso y participación sobre la adecuación de templates

• Definición minimalista del proceso

EJ.FASE I

27

Funcionan las recetas ¿?

Construir un primer esqueleto del proceso

No incluir actividades ni artefactos que no se justifiquen claramente

Proteger al equipo – No burocratizar.

Minimizar los artefactos formales.

Usar formatos convenientes – generación automática

Usar internet e intranet.

Revisar regularmente el proceso.

Adaptar mientras se mantengan las “mejores prácticas”

Haciendo bien nuestro trabajo…

• Tener Mi proceso de desarrollo definido

• Emplear las herramientas de UUMMLL

• Mejorar continuamente la manera en que hacemos las cosas.

• Asegurando la calidad de nuestro proceso

• Podremos certificar estándares de calidad– ISO 9001:2000; CMM o CMMi

QQ

28

FIN

Muchas Gracias!

Preguntas?

Lo nuevo…

• The underlying process definition language.

• Underlying it all is a process meta-model. This modelprovides a language of process definition elements fordescribing a software engineering process. Thislanguage is based on the SPEM extension to the UML for software process engineering and the UnifiedProcess methodology.

uc proceso unificado

Documents