uc- proceso unificado - ucongreso.edu.ar€¦ · el proceso unificado prof. gustavo j. sabio de...
TRANSCRIPT
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
Dirigido por casos de uso
• 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.
¿¿Por quPor quéé casos de uso?casos de uso?
La selección de conjunto correcto de casos de uso permite construir una arquitectura robusta.
Dirigido por casos de uso
Ayudan a desarrollar iterativamente.
¿¿Por quPor quéé casos de uso?casos de uso?
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
Características principales del RUP
• Está dirigido por los Casos de Uso
• Está centrado en la arquitectura
• Es iterativo e incremental
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
Características principales del RUP
• Está dirigido por los Casos de Uso
• Está centrado en la arquitectura
• Es iterativo e incremental
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.
Características principales del RUP
• Está dirigido por los Casos de Uso
• Está centrado en la arquitectura
• Es iterativo e incremental
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
Diferentes formas de implementación
Una implementación típica
Diferentes formas de implementación
Implementación Rápida
24
Diferentes formas de implementación
Implementación cuidadosa
Diferentes formas de implementación
Implementar un ambiente de desarrollo
25
Desarrollar software con “mi” proceso
“nuestro 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
“nuestro Proceso”
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
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.