Descarga la aplicación para disfrutar aún más
Vista previa del material en texto
ANÁLISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN RAFAEL VILCA BARBARAN UNIVERSIDAD NACIONAL DE LA AMAZONÍA PERUANA mailto:Rafael.vilca@unapiquitos.edu.pe mailto:rafaelvilcab@Gmail.com Un lenguaje de modelado, no es suficiente Desarrollo Basado En Equipos Lenguaje de Modelado Unified Process 2 Rational Unified Process ◼ Es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas OO. Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo) . Pretende implementar las mejores practicas en ingenieria de Software: Desarrollo iterativo Administración de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificación de la calidad del software Rational Unified Process ◼ El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. ◼ El RUP divide el proceso de desarrollo en ciclos, teniendo un producto final al final de cada ciclo, cada ciclo se divide en fases que finalizan con un hito donde se debe tomar una decisión importante: Inicio: se hace un plan de fases, se identifican los principales casos de uso y se identifican los riesgos Elaboración: se hace un plan de proyecto, se completan los casos de uso y se eliminan los riesgos Construcción: se concentra en la elaboración de un producto totalmente operativo y eficiente y el manual de usuario Transición: se implementa el producto en el cliente y se entrena a los usuarios. Como consecuencia de esto suelen surgir nuevos requerimientos a ser analizados. Seis “Mejores Prácticas” Controlar Cambios Administrar requerimientos Arquitecturas Basadas en Componentes Desarrollar Iterativamente Verificar Calidad Modelizar Visualmente 5 Planeamiento Inicial Planeamiento Requerimientos Análisis y Diseño Implementación Prueba Distribución Evaluación Ambiente de Administración 1. Desarrollar Software Iterativamente ◼ Cada iteración resulta en un release ejecutable 6 1. Desarrollar Software Iterativamente ◼ Los desentendimientos importantes se evidencian tempranamente ◼ Se alienta el feedback del usuario ◼ Focalización en los temas más críticos, sin distracciones ◼ Testing continuo e iterativo: evaluación objetiva ◼ Inconsistencias entre requerimientos, diseños e implementaciones se detectan tempranamente 7 1. Desarrollar Software Iterativamente ◼ Carga de trabajo mejor repartida en el tiempo ◼ El equipo puede analizar las lecciones aprendidas en las primeras iteraciones ◼ Integración progresiva en lugar de Big Bang ◼ Evidencias concretas a los sponsors ◼ Se facilita la reutilización ◼ Arquitectura más robusta 8 2. Administrar los requerimientos ◼ Requirements Management, enfoque sistemático que involucra: ◼ Obtener, organizar y documentar la funcionalidad y restricciones requeridas a un sistema ◼ Analizar los cambios solicitados y evaluar impactos ◼ Registrar y documentar las alternativas y decisiones tomadas 9 2. Administrar los requerimientos ◼ Los requerimientos pueden ser adecuadamente capturados y comunicados a través de Casos de Uso ◼ Los Casos de Uso son importantes instrumentos de planificación Modelo de Diseño Modelo de Implementación Modelo de Test verificaRealización influenciados por Los Casos de Uso direccionan el trabajo desde el análisis hasta el test Modelo de Casos de Uso 10 2. Administrar los requerimientos: Beneficios ◼ Las comunicaciones están basadas en requerimientos bien definidos ◼ Los requerimientos pueden ser priorizados, filtrados y monitoreados ◼ Es posible realizar evaluaciones objetivas acerca del éxito de un proyecto ◼ Las inconsistencias se detectan fácilmente ◼ Con herramientas adecuadas: repositorio de requerimientos, con atributos y relaciones 11 3. Utilizar Arquitecturas Basadas en Componentes ◼ La Arquitectura de Software representa el conjunto de decisiones significativas sobre la organización de un sistema de software ◼ selección de los elementos estructurales, y sus interfaces, por los cuales el sistema está compuesto ◼ comportamiento, especificado como colaboraciones entre los elementos ◼ composición en subsistemas de los elementos estructurales y de comportamiento ◼ estilo de arquitectura que guía a la organización 12 3. Utilizar Arquitecturas Basadas en Componentes ◼ La Arquitectura de Software representa el conjunto de decisiones significativas sobre la organización de un sistema de software ◼ selección de los elementos estructurales, y sus interfaces, por los cuales el sistema está compuesto ◼ comportamiento, especificado como colaboraciones entre los elementos ◼ composición en subsistemas de los elementos estructurales y de comportamiento ◼ estilo de arquitectura que guía a la organización 13 3. Utilizar Arquitecturas Basadas en Componentes Vista Lógica Usuario Funcionalidad Vista de Implementación Programadores Administración del Software Vista del Proceso Performance Escalabilidad Rendimiento Integradores Vista de Desarrollo Topología Distribución, Instalación Comunicación Ingeniería Conceptual Física Vista de Caso de Uso Vistas 14 3. Utilizar Arquitecturas Basadas en Componentes ◼ Un componente de software puede definirse como una pieza no trivial de software, un módulo o un subsistema que completa una función clara, tiene límites claros y puede ser integrado en una arquitectura bien definida ◼ Realización física de una abstracción en el diseño System- software Middleware Negocio Aplicación Arquitectura basada en componentes 15 3. Utilizar Arquitecturas Basadas en Componentes ◼ Definir arquitecturas muy modulares e identificar, aislar, diseñar, desarrollar y probar componentes bien formados ◼ Desarrollar componentes para ser reutilizados. Formar la base de reuso de la organización ◼ Industria de infraestructura de componentes ◼ COM+ - Microsoft Component Object Model ◼ CORBA - Common Object Request Broker Architecture - OMG ◼ JavaBeans - SUN 16 4. Modelar Software Visualmente ◼ Diagramas de Casos de Uso ◼ Diagramas de Clases ◼ Diagramas de Estados ◼ Diagramas de Componentes ◼ Diagramas de Implementación Código Clases Subsistemas Modelización Visual eleva el nivel de abstracción 17 4. Modelar Software Visualmente: Beneficios ◼ Los casos de uso permiten especificar comportamiento sin ambigüedades ◼ Quedan expuestas las arquitecturas inflexibles o no modulares ◼ El diseño refleja sus inconsistencias más rápidamente ◼ Existen herramientas que proveen soporte para la modelización visual 18 5. Verificar la Calidad del Software ◼ La actividad fundamental de esta práctica es el testing ◼ Evaluar continuamente la calidad de un sistema con respecto a funcionalidad, confiabilidad, performance Desarrollo Implementación Costo Encontrar y reparar un problema de software después de la implementación puede resultar de 100 a 1000 veces más costoso 19 5. Verificar la Calidad del Software: Beneficios ◼ La evaluación del estado del proyecto es objetiva, se evalúan resultados de test. ◼ Se exponen inconsistencias en requerimientos, diseños e implementaciones ◼ Se focaliza en las áreas de riesgo más alto ◼ Los defectos se identifican en forma temprana ◼ Existen herramientas automatizadas para el testing de funcionalidad, confiabilidad y performance 20 6. Controlar los Cambios al Software ◼ Controlar, registrar y monitorear los cambios para posibilitar el desarrollo iterativo ◼ Establecer “workspaces” seguros para cada desarrollador ◼ Automatizar la integración y la administración de “builds” ALERTREPORT Workspace de Administración Integración Desarrollo enparalelo Administración del Build 21 6. Controlar los Cambios al Software: Beneficios ◼ Las solicitudes de cambios formales facilitan la claridad de comunicación ◼ Los espacios de trabajo aislados reducen la interferencia entre los miembros del equipo que trabajan en paralelo ◼ Las estadísticas de cantidad de cambios proveen buenas métricas para evaluar objetivamente el estado del proyecto ◼ La propagación del cambio es evaluable y controlable ◼ Los cambios pueden ser mantenidos en sistemas automáticos 22 Rational Unified Process (RUP) Provee: Lineamientos, templates para herramientas, que guían una implementación efectiva de las 6 Mejores Practicas Controlar Cambios Administrar Requerimientos Arquitecturas Basadas en Componentes Desarrollar Iterativamente Verificar Calidad Modelar Visualmente 23 El Ciclo de Vida del Software - Etapas ◼ Concepción ◼ La idea. La visión del producto y su objeto de negocio ◼ Elaboración ◼ Planeamiento de actividades. Recursos. Cualidades. Arquitectura ◼ Construcción ◼ Construcción del producto. Evolución de la visión, Arquitectura, Planes ◼ Transición ◼ Liberación del producto a la comunidad de usuarios ◼ Evolución ◼ Siguientes versiones Tiempo Concepción Elaboración Construcción Transición Evolución 24 El Ciclo de Vida del Software - Etapas La “Evolución” 25 El Ciclo de Vida del Software - Perspectivas Dos Perspectivas 26 Estructura Estática de RUP Entorno Modelado del negocio Implementación Pruebas Análisis & Diseño Preliminary Iteration(s) Iter. #1 Iter. #2 Iter. # n Iter. # n Iter. # n Iter. # m Iter. # m Implantación Gestión de configuraciones Requerimientos Elaboration TransitionInception Construction Administración del proyecto Flujo de trabajo de Soporte Flujo de trabajo de Proceso Fases 27 Rational Unified Process (RUP) y UML Desarrollados en armonía por Rational RUP y Unified Modeling Language (UML) 28
Compartir