El Proceso Unificado de Desarrollo de Software Prof. Gustavo J. Sabio Alcance de la presentación QA Entradas Proceso de desarrollo Salida equipo Cliente sistemas Cliente necesidades actividades varias Producto software MI PROCESO ADAPTADO 1
Algunos conceptos fundamentales Qué es un proceso? Conjunto de actividades que interactúan o se relacionan para transformar las entradas de clientes en salidas con un valor agregado. Un proceso define QUIÉN hace QUÉ, CUÁNDO, y CÓMO, con un orden que permite alcanzar un objetivo definido actividades aisladas aplicación aleatoria áreas independientes fusionadas sistemáticamente para un fin relacionadas y organizadas se complementan para objetivo común Algunos conceptos fundamentales Proceso de desarrollo de software Ciclo de vida del desarrollo de software entradas Proceso de desarrollo salida Cliente equipo sistemas necesidades actividades varias Producto software Las necesidades del cliente son transformadas en un producto software Modelado Modelado de Negocio Negocio y Requerimientos Requerimientos Análisis Análisis y Diseño Diseño Construcción Construcción Prueba Prueba e integración integración Despliegue Despliegue y entrega entrega Cliente 2
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. 3
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. Qué es el RUP? 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) 4
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. 5
Mapa conceptual de RUP Algunos conceptos 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. 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. 6
Estructura: Ciclo de vida en Fases UP tiene 4 fases: tiempo Inicio Elaboración Construcción Transición Inicio Elaboración Construcción Transición Define el alcance del proyecto Plan de proyecto, especificación de características, arquitectura base Construir el producto Despliegue del producto en el cliente Grandes Hitos entre las fases tiempo Inicio Elaboración Construcción Transición LCO LCA IOC Objetivos del Ciclo de Vida Arquitectura del Ciclo de Vida Alcance acordado Riesgos comprendidos y razonables Riesgos principales contenidos Arquitectura estable Capacidad Operativa Inicial Producto Producto entregado completado Calidad aceptable 7
Fases e Iteraciones Inicio Elaboración Construcción Transición tiempo Iter Iter Iter Iter Iter Iter Iter Iter inicial arq1 arq2 desa1 desa2 desa3 Tran1 Tran2 Hitos 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 actividades relacionadas En una iteración se lógicamente atraviesan todas las Disciplinas 8
Las Disciplinas producen Modelos Las Disciplinas guían el desarrollo iterativo Disciplina 9
Modelo RUP en funcionamiento Discipline Características del RUP INICIO ELABORACION TRANSICION Definir el alcance del sistema propuesto. Crear una Preparar línea CONSTRUCCION base actividades para la Dirigido arquitectura. de distribución. por Casos de Uso Esbozar una arquitectura candidata Identificación Recomendar y mitigación cliente de Riesgos. sobre hardware necesarios. Identificar la descripción Riesgos críticos y realización Centrado de todos en los la CU. Arquitectura Especificar La finalización Preparar atributos del manuales análisis, de calidad y diseño, otros (fiabilidad, para implementación la entrega performance, del y pruebas. producto. etc. ) Creación de prototipos (opcional) Iterativo e Incremental Recopilar Mantener Parametrizar CU la para integridad cubrir el el de software. 80% la arquitectura. de los requisitos funcionales. Proponer Seguimiento Correcciones planificación y mitigación de general defectos los (personal, riesgos. y adecuaciones. costos, etc.) 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 10
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. Por qué 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) Registrar préstamo Se considera la perspectiva de cada usuario qué necesitan para hacer su trabajo? Bibliotecario Comprar material Integrando todas las perspectivas tendremos toda la funcionalidad que se espera del sistema. 11
Dirigido por casos de uso Por qué casos de uso? Al preguntar Qué se quiere que haga el 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. Dirigido por casos de uso Por qué casos de uso? Involucra a los usuarios, clientes, desarrolladores y a todo el equipo del proyecto Todos los involucrados deben acordar 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. Ayudan a desarrollar iterativamente. 12
Características principales del RUP Está dirigido por los Casos de Uso Está centrado en la arquitectura Es iterativo e incremental Centrado en la arquitectura La arquitectura del sistema es: Hola! Soy la arquitectura 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. Bibliotecario Registrar préstamo Comprar material Los CU deben encajar en la arquitectura al momento de crearlos. La arquitectura debe permitir el desarrollo de los CU requeridos ahora y en el futuro. 13
Qué es la arquitectura? Representación n de la arquitectura: el Modelo 4 + 1 DOC ARQUITECTURA Características principales del RUP Está dirigido por los Casos de Uso Está centrado en la arquitectura Es iterativo e incremental 14
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. 15
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 riesgos: 16
Iterativo e incremental Beneficios Gestión de requisitos cambiantes: El tener un sistema en funcionamiento parcial en una fase inicial permite contar con retroalimentación oportuna. 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 incremental Beneficios de la integración continua 17
Iterativo e incremental Beneficios Lograr un aprendizaje temprano Despué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. Los errores no se pagan tan caros Cometer 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 18
En dónde estamos? Entradas Proceso de desarrollo Salida equipo Cliente sistemas Cliente necesidades actividades varias Producto software MI PROCESO ADAPTADO 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? 19
Desarrollar software con un proceso nuestro Proceso RUP y la primera impresión Cuando recorra la extensa cantidad de artefactos, actividades, y documentos de RUP, puede suceder que se formule las siguientes preguntas: Esto es necesario? De todos estos items, cuáles son aplicables a mi proyecto? El RUP es sólo es para grandes proyectos? 20
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 21
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 22
Diferentes formas de implementación Una implementación típica Diferentes formas de implementación Implementación Rápida 23
Diferentes formas de implementación Implementación cuidadosa Diferentes formas de implementación Implementar un ambiente de desarrollo 24
Desarrollar software con mi proceso nuestro Proceso hito s hito s hito s INICIO ELABORACION CONSTRUCCION TRANSICION hito s 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. 25
Proceso y proyecto Nuevos proyectos... Proyecto 1 nuestro Proceso Proyecto 2 Proyecto 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 26
Funcionan las recetas? Construir un primer esqueleto del proceso Proteger al equipo No burocratizar. No incluir actividades ni artefactos que no se justifiquen claramente 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 UML 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 Q 27
FIN Muchas Gracias! Preguntas? Lo nuevo The underlying process definition language. Underlying it all is a process meta-model. This model provides a language of process definition elements for describing a software engineering process. This language is based on the SPEM extension to the UML for software process engineering and the Unified Process methodology. 28