CICLO 2012-II Mdulo: I Unidad: 2 Semana: 3 ANALISIS Y DISEO DE SISTEMAS DE INFORMACIN Tema: Rational Unified Process (RUP) 1 Qu es RUP? Rati onal Uni fi ed Process (RUP) es un producto desarrol l ado y Manteni do por RATIONAL SOFTWARE. Potenci a l a Producti vi dad del equi po Las acti vi dades especi fi cadas por RUP crean y manti enen model os. Es una gua de cmo usar UML. Consti tuye l a metodol oga 2 Soportado por herrami entas, que automati zan gran parte del proceso. 3 Qu es RUP? 2 Es un proceso confi gurabl e. No exi ste un ni co proceso adecuado para todo el desarrol l o de software. Si rve para pequeos equi pos de desarrol l o tanto para grandes organi zaci ones. Puede adecuarse a di versas si tuaci ones 4 Qu es RUP? Ori entado a Obj etos. Cual qui er cosa del mundo real que puede ser representada. Caractersti cas, i denti dad, estado y comportami ento 5 Caractersticas del RUP? Iterati vo i ncremental Gui ado por caso de uso Es centrado en tres puntos: o Personas o Procesos o Herrami entas y mtodos 6 Caractersticas del RUP? 3 Controlado e Iterativo Basado en casos de uso Arquitectura centralizada Configurable Captura de requerimientos de usuario Mitigar los mayores riesgos temprano Tomar el ltimo feedback Integrado conherramientas de desarrollo Mejorar la calidad Personalizar el proceso Aumentar el Reuso 7 Caractersticas del RUP? El ciclo de vida esta partido en ciclos, y cada ciclo trabaja sobre una nueva generacin del producto. RUP divide cada ciclo de desarrollo en cuatros fases: Fase de Conceptualizacin Fase de Elaboracin Fase de Construccin Fase de Transicin 8 Ciclo de Vida del RUP 9 Inicio: Definir el alcance del proyecto Elaboracin: Planificar el proyecto, elaborar una arquitectura base Construccin: Construir el sistema Transicin: Transicin a los usuarios tiempo Objetivos (Vision) Arquitectura Capacidad Operacional Inicial Lanzamiento del Producto Inception Elaboration Construction Transition Principales puntos de control (Milestones) 4 tiempo Inception Visin documentada, en donde se define los reqs principales del proyecto, principales caractersticas y restricciones Un inicial modelo USE-CASE del negocio (10% - 20%) Un glosario de conceptos y trminos del proyecto Un inicial modelo del Negocio, que incluya el contexto de la empresa y factores de xito (Costo - Beneficio). Un inicial inventario y costeo de riesgos El plan del proyecto (donde se muestren las etapas e iteraciones) Si es posible un prototipo inicial Resul tados 10 Fase de Conceptualizacin o Incepcin tiempo Inception Conocimiento y compromiso por parte de los Stakeholder en los objetivos definidos yestimacinde tareas yel costode las mismas Evidenciar en los USE - CASE primarios el entendimiento de los reqs del Usuario Credibilidad en la estimacin de tiempos y costeo, prioridades, riesgos y desarrollodel proceso Conocimientodelas arquitecturasinvolucradas enlos sistemas Validar costos actuales vs los costos planificados. Puntos a Control ar (Hi tos) Control 11 Fase de Conceptualizacin o Incepcin tiempo Elaboration Modelo del USE - CASE (80% completado), todos los USE - CASE y actores han sido identificados y las descripciones de los USE - CASE han sido elaboradas Requerimientos suplementarios son recolectados y asociados a un diagrama USE - CASE Descripcin de la arquitectura del Software Prototipo del Software Lista de riesgos y Cases del negocio validados Plan del Proyecto completo y aprobado por el Usuario Lider Manual de Usuario preliminar. Resul tados 12 Fase de Elaboracin 5 Es la visin del producto estable? Es arquitectura estable? La presentacin del prototipo demostr que los principales reqs y riesgos estn resueltos con la solucin elaborada El plan para la construccin del SW es lo suficientemente detallado y de acuerdo a los costos estimados? Estn de acuerdo los Stakeholder con el plan definido? Validacin de los Costos incurridos hasta el momento versus los costos estimados Puntos de Control - Hi tos: Control tiempo Elaboration 13 Fase de Elaboracin tiempo Construction Primera versin del Producto (Versin Beta) Pruebas del Producto Los Manuales de Usuario Validacin de los Costos incurridos hasta el momento versus los costos estimados. Resul tados 14 Fase de Construccin tiempo Se han cumplido el plan de pruebas (en todos los niveles)? Estn todos los Stakeholder listos para colocar la versin actual (realese) en el ambiente del Usuario Estan todos los recursos listos para la transicin hacia la comunidad usuaria. Validacin de los Costos incurridos hasta el momento versus los costos estimados Control Construction Puntos de Control - Hi tos: 15 Fase de Construccin 6 tiempo Transition Testeo de la Versin BETA para validar el nuevo sistema versus las expectativas del usuario Plan de puesta en produccin respecto al sistema antiguo Tareas de migracin y conversin de datos Entrenamiento de usuarios y del Area de Sistemas de la empresa Instalacin del producto en todos los ambientes del usuario Resul tados 16 Fase de Transicin tiempo Transition Obtener autonoma del usuario Obtener el acuerdo de los participantes de que la instalacin ha sido completa y que es consistente con los criterios de evlaucin de la visin Perfeccionar el producto final. Obj eti vos Pri mari os 17 Fase de Transicin tiempo Objetivos hansido alcanzados. Estasatisfechoel usuario? En algunos casos, este punto de control puede coincidir con el final de la etapade conceptualizacindel siguienteciclo. Control Transition Puntos de Control - Hi tos: 18 Fase de Transicin 7 Una iteracines a secuencia de actividades con un plan establecido y criterios de evaluacin, cuyo resultado es una versin del software Arch Iteration ... Dev Iteration Dev Iteration ... Trans Iteration ... Versin Versin Versin Versin Versin Versin Versin Versin Prelim Iteration ... Inception Elaboration Construction Transition 19 Fases e Iteraciones 20 Estructura Esttica del RUP 1. Desarrollo Iterativo del software 2. Administracin de requierimientos 3. Uso de arquitecturas basadas en componentes 4. Modelamiento visual del software 5. Verificacin de la calidad del software 21 Las 6 mejores Prcticas 8 Admi ni strar Desarrol l ar i terati vamente Veri fi car Model i zar vi sual mente Arqui tecturas Basadas en Componentes Control de cambi os 22 Las 6 mejores Prcticas 1. Desarrollo iterativo del software Desarrollo de software dando varios realease al usuario Planeamiento Inicial Planeami ento Requerimiento Anlisis y Diseo Implementacin Prueba Distribucin Evaluacin Ambiente de Administracin Cada iteracin genera una nueva versin 23 Las 6 mejores Prcticas Los puntos no entendidos son puestos en evidencia tempranamente en la vida del ciclo, por lo tanto es posible reaccionar a ellos Permite utilizar el Feedbackpara obtener los reqs reales del sistema El equipo de desarrollo es forzado a dar importancia a las tareas ms crticas en el proyecto, que son en conclusin los puntos de riesgo del proyecto. La revisin del proyecto Testen los puntos claves, permite conocer el estado real del proyecto Las inconsistencias entre los reqs, diseos e implementacin son tempranamente detectados 1. Desarrollo iterativo del software (cont.) Benefi ci os: 24 Las 6 mejores Prcticas 9 Benefi ci os: La carga del equipo, especialmente del equipo de testeo, es extendida a travs de la vida del proyecto El equipo de trabajopuede evidenciar los problemas conrapidez Todos los involucrados en el proyecto Stakeholders, pueden dar un evidencia concreta del estado del proyecto entodas la partes del ciclo de vida. 1. Desarrollo iterativo del software (cont.) 25 Las 6 mejores Prcticas 2. Administracin de requerimientos Un requerimiento es una condicin o capacidad que un sistema debe tener Para definir un requerimiento, se tienen 3 tareas: Obtener la informacin Organizarla Documentacin La documentacin permite: Registro de reqs del sistema Evaluacin y costeo de los cambios Seguimiento Registro de acuerdos y decisiones 26 Las 6 mejores Prcticas Benefi ci os: Comunicaciones basadas en requerimientos bien definidos Los requerimientos pueden ser priorizados, filtrados y monitoreados Es posible realizar evaluaciones objetivas acerca del exito de un proyecto 2. Administracin de requerimientos (cont.) 27 Las 6 mejores Prcticas 10 Desi gn Model Impl ementati on Model Test Model verifies realization influenced by Use-Case Model Importancia de l os Casos de Uso 28 Las 6 mejores Prcticas 3. Uso de a arquitectura basada en compontes Todo si stema se basa en l a uni n de muchas partes l l amados componentes Un componente de software puede defi ni rse como una pi eza no tri vi al de software, un modul o un subsi stema que compl eta una funci n cl ara ti ene li mi tes claros y puede ser i ntegrado a una arqui tectura bi en defi ni da 29 Las 6 mejores Prcticas 3. Uso de a arquitectura basada en compontes (Cont.) Definir arquitecturas muy modulares e identificar, aislar, disear, desarrollar y probar componentes bien formados. Desarrollar componentes para ser reutilizados. Formar la base de reuso de la organizacin. Para desarrol l ar un si stema ori entado a componentes se debe: 30 Las 6 mejores Prcticas 11 4. Modelar Software Visualmente Eleva el nivel de abstraccin, pudiendo administrar ms fcilmente los requerimientos, dando un lenguaje de mas sencillo y administrable. Por ejemplo UML (Unified Modeling Languaje), define un conjunto de modelos (estndar) que permite una comunicacin no ambigua entre el equipo desarrollo 31 Las 6 mejores Prcticas Code Classes Sub Systems Model ami ento Vi sual Permi te el ni vel de Abstracci n 4. Modelar Software Visualmente (cont.) 32 Las 6 mejores Prcticas Model os y Vi stas Use Case Diagrams Use Case Diagrams Use Case Diagrams Scenario Diagrams Scenario Diagrams Collaboration Diagrams State Diagrams State Diagrams Component Diagrams Component Diagrams Component Diagrams Deployment Diagrams State Diagrams State Diagrams Object Diagrams Scenario Diagrams Scenario Diagrams Statechart Diagrams Use Case Diagrams Use Case Diagrams Sequence Diagrams State Diagrams State Diagrams Class Diagrams Activity Diagrams Un modelo es una completa descripcin de un sistema desde una particular perspectiva Models 4. Modelar Software Visualmente (cont.) 33 Las 6 mejores Prcticas 12 Cada flujo de trabajo describe como crear y mantener un modelo particular Modelos y Flujo del trabajo Design Model Implementation Model Test Model realized by implementedby Requi rements Workfl ow Anal ysi s Desi gn Workfl ow Impl ementati on Workfl ow Test Workfl ow Use-Case Model Busi ness Model i ng Business Model verified by 4. Modelar Software Visualmente (cont.) 34 Las 6 mejores Prcticas 5. Verificar la Calidad del Software Crear tareas de testeo para cada escenario clave y asegurar que todos los reqs estn correctamente definidos en las etapas de reqs, diseoe implementacin. Verifica la elasticidaddel diseoy performancedel sistema. Defectos encontradosrpidamentedisminuyenlos costos. La tarea de verificacin forma parte de cada Iteracin en el desarrolloiterativo. Existen herramientas automatizadas para el testing de funcionalidad, confiabilidadyperformance. 35 Las 6 mejores Prcticas 6. Control de Cambios Controlar, registrar y lmonitorear los cambios para posibilitar el desarrolloiterativo Establecer workspacesseguros paracadadesarrollador. Automatizarla integracinyla administracinde builds Fi nal idad 36 Las 6 mejores Prcticas 13 6. Control de Cambios Permite descomponer la arquitectura en subsistemas y asignar la responsabilidad sobre cada uno a un equipo o persona especifico. Establecereas de trabajoseguras para cadadesarrollador. Permite aislarsede cambios efectuados por otros. Controlatodos los artefactos - modelos, cdigo, doc, etc. Estableceunmecanismode control de cambios inexpugnable. Permite saber que cambios aparecenenque versiones. Liberauna versinde referenciaal terminode cadaiteracin. Benefi ci os 37 Las 6 mejores Prcticas 6. Control de Cambios El Proceso Unificado Desarrol l o Iterati vamente El progreso es incremental solo si se controlanlos cambios Admi ni stre requeri mi entos Para evitar los alcances sean variables, evaluar cada cambio antes de aprobarlo Use arqui tectura de componente Los componentes deben ser confiables, las versiones deben componerse a partir de las partes correctas Model e vi sual mente Para asegurar convergencia, se debe controlar modelos incrementalmente Veri fi que cal i dad Los test son muy significativos solo si los tems testeados estn perfectamente identificados y protegidos decambios 38 39 Esfuerzo y dedicacin por Fases en RUP Inicio Elaboracin Construccin Transicin Esfuerzo 5 % 20 % 65 % 10% Tiempo Dedicado 10 % 30 % 50 % 10% 14 40 Distribucin de Recursos por Fases en RUP Disciplina Diagrama Requerimientos Diagramas de Casos de Uso Anlisis Refinamiento y documentacin de los casos de usos Definicinpreliminar de clases y Diagramas de Interaccin(Secuencia y Colaboraciones) Diseo Empaquetamiento Diagramas de Interaccin de diseo (Secuencia y Colaboraciones) Diagrama de Clases de diseo Modelo de Datos Implementacin Diagrama de Componentes Diagrama de Despliegue Relacin entre Diagramas UML y Disciplinas de RUP 41 Gracias por su Atencin 42