Sww clase4
- 1. Introducción al RUP R U P Rational Unified Process Proceso Unificado de Rational
- 2. RUP Es un producto del proceso de ingeniería de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización del desarrollo META Asegurar software de alta calidad que resuelva las necesidad de los usuario dentro de un presupuesto y tiempos establecidos
- 3. Dimensiones del RUP Eje Horizontal Representa tiempo y demuestra los aspectos del ciclo de vida del proceso Eje Vertical Representa las disciplinas que agrupan las actividades Aspecto dinámico del proceso y expresa en términos fases, iteraciones finalización de las fases Aspecto estático del proceso y comprende las disciplinas, actividades, flujos de trabajo, roles y artefactos
- 4. Dimensiones del RUP Varía el énfasis de cada disciplina en un cierto plazo en el tiempo, y durante cada una de las fases
- 5. Características del RUP Proceso Dirigido por los Casos de Uso. Proceso Iterativo Incremental Proceso centrado en la arquitectura
- 6. Características del RUP Los Casos de Uso son la base para la implementación de las fases y disciplinas del RUP. Los casos de uso son una secuencia de pasos que conlleva la realización e implementación de un Requerimiento planteado por el Cliente
- 7. Características del RUP Proceso Iterativo e Incremental : Es el modelo utilizado por RUP para el desarrollo de un proyecto de software Proceso Centrado en la Arquitectura : Define la Arquitectura de un sistema, y una arquitectura ejecutable construida como un prototipo evolutivo .
- 8. Planeación de las Fases Se tiene cuatro fases: Concepción , inicio o estudio de oportunidades Elaboración Construcción Transición
- 9. Planeación de las Fases Concepción, Inicio o Estudio de oportunidad Define el ámbito y objetivos del proyecto Se define la funcionalidad y capacidades del producto
- 10. Planeación de las Fases Elaboración Tanto la funcionalidad como el dominio del problema se estudian en profundidad Se define una arquitectura básica Se planifica el proyecto considerando recursos disponibles
- 11. Planeación de las Fases Construcción El producto se desarrolla a través de iteraciones donde cada iteración involucra tareas de análisis, diseño e implementación. Las fases de estudio y análisis sólo dieron una arquitectura básica que es aquí refinada de manera incremental conforme se construye (se permiten cambios en la estructura) Gran parte del trabajo es programación y pruebas Se documenta tanto el sistema construido como el manejo del mismo Esta fase proporciona un producto construido junto con la documentación
- 12. Planeación de las Fases Transición Se libera el producto y se entrega al usuario para un uso real Se incluyen tareas de marketing , empaquetado atractivo, instalación, configuración, entrenamiento, soporte, mantenimiento. Los manuales de usuario se completan y refinan con la información anterior Estas tareas se realizan también en iteraciones
- 13. Disciplinas Conllevan a los flujos de trabajo, los cuales son una secuencia de pasos para la culminación de cada disciplina. Se dividen en : las primarias son las necesarias para la realización de un proyecto de software Las de apoyo . Sirven de apoyo a las primarias
- 14. Disciplinas Primarias Modelado del Negocio, Requerimientos Análisis y Diseño Implementación Pruebas Despliegue
- 15. Disciplinas De Apoyo Entorno Gestión del Proyecto Gestión de Configuración Cambios
- 16. Modelado del negocio Esta disciplina tiene como objetivos comprender la estructura y la dinámica de la organización, comprender problemas actuales e identificar posibles mejoras, comprender los procesos de negocio. Utiliza el Modelo de CU del Negocio para describir los procesos del negocio y los clientes, el Modelo de Objetos del Negocio para describir cada CU del Negocio con los Trabajadores, además utilizan los Diagramas de Actividad y de Clases.
- 17. Requerimientos Esta disciplina tiene como objetivos establecer lo que el sistema debe hacer (Especificar Requisitos), definir los límites del sistema, y una interfaz de usuario, realizar una estimación del costo y tiempo de desarrollo. Utiliza el Modelo de CU para modelar el Sistema que comprenden los CU, Actores y Relaciones, además utiliza los diagramas de Estados de cada CU y las especificaciones suplementarias
- 18. Análisis y diseño Esta disciplina define la arquitectura del sistema y tiene como objetivos trasladar requisitos en especificaciones de implementación, al decir análisis se refiere a transformar CU en clases, y al decir diseño se refiere a refinar el análisis para poder implementar los diagramas de clases de análisis de cada CU, los diagramas de colaboración de de cada CU, el de clases de diseño de cada CU, el de secuencia de diseño de CU, el de estados de las clases, el modelo de despliegue de la arquitectura
- 19. Implementación Esta disciplina tiene como objetivos implementar las clases de diseño como componentes (ej. fichero fuente), asignar los componentes a los nodos, probar los componentes individualmente, integrar los componentes en un sistema ejecutable (enfoque incremental). Utiliza el Modelo de Implementación, conjuntamente los Diagramas de Componentes para comprender cómo se organizan los Componentes y dependen unos de otros
- 20. Pruebas Esta disciplina tiene como objetivos verificar la integración de los componentes (prueba de integración), verificar que todos los requisitos han sido implementados (pruebas del sistema), asegurar que los defectos detectados han sido resueltos antes de la distribución
- 21. Despliegue Esta disciplina tiene como objetivos asegurar que el producto está preparado para el cliente, proceder a su entrega y recepción por el cliente. En esta disciplina se realizan las actividades de probar el software en su entorno final (Prueba Beta), empaquetarlo, distribuirlo e instalarlo, así como la tarea de enseñar al usuario .
- 22. Gestión y configuración de cambios Es esencial para controlar el número de artefactos producidos por la cantidad de personal que trabajan en un proyecto conjuntamente. Los controles sobre los cambios son de mucha ayuda ya que evitan confusiones costosas como la compostura de algo que ya se había arreglado etc., y aseguran que los resultados de los artefactos no entren en conflicto con algunos de los siguientes tipos de problemas
- 23. Gestión y configuración de cambios Actualización simultánea : Es la actualización de algo elaborado con anterioridad, sin saber que alguien más lo está actualizando. Notificación limitada : Al realizar alguna modificación, no se deja información sobre lo que se hizo, por lo tanto no se sabe quien, como, y cuando se hizo. Versiones múltiples : No saber con exactitud, cual es la última versión, y al final no se tiene un orden sobre que modificaciones se han realizado a las diversas versiones
- 24. Gestión del proyecto Administrar proyectos de software intensivos. Planear, dirigir personal, ejecutar acciones y supervisar proyectos. Administrar el riesgo
- 25. Gestión del proyecto Sin embargo, esta disciplina no intenta cubrir todos los aspectos de dirección del proyecto. Por ejemplo, no cubre problemas como: Administración de personal: contratando, entrenando, enseñando. Administración del presupuesto: definiendo, asignando. Administración de los contratos con proveedores y clientes .
- 26. Entorno Esta disciplina se enfoca sobre las actividades necesarias para configurar el proceso que engloba el desarrollo de un proyecto y describe las actividades requeridas para el desarrollo de las pautas que apoyan un proyecto Su propósito es proveer a la organización que desarrollará el software , un ambiente en el cual basarse, el cual provee procesos y herramientas para poder desarrollar el software
- 27. Elementos que conforman el RUP Los elementos que lo componen : Flujos de Trabajo Detalle de los Flujos de Trabajo Actores Actividades Artefactos.
- 28. Elementos que conforman el RUP
- 29. Actores o roles Son los personajes encargados de la realización de las actividades definidas dentro de los flujos de trabajo de cada una de las disciplinas del RUP, estos actores se dividen en varias categorías: Analistas, Desarrolladores, Probadores, Encargados, Otros actores
- 30. Artefactos Los artefactos son el resultado parcial o final que es producido y usado por los actores durante el proyecto. Son las entradas y salidas de las actividades, realizadas por los actores, los cuales utilizan y van produciendo estos artefactos para tener guías. Un artefacto puede ser un documento, un modelo o un elemento de modelo.
- 31. Conjunto de artefactos Se tiene un conjunto de artefactos definidos en cada una de las disciplinas y utilizadas dentro de ellas por lo actores para la realización de las mismas, a continuación se definen cada una de estas categorías o grupos de artefactos dentro de las disciplinas del RUP:
- 32. Conjunto de artefactos Modelado del negocio. Capturan y presentan el contexto del negocio del sistema. Los artefactos del modelado del negocio sirven como entrada y como referencia para los requisitos del sistema
- 33. Conjunto de artefactos Requerimientos . Los artefactos de requerimientos del sistema capturan y presentan la información usada en definir las capacidades requeridas del sistema.
- 34. Conjunto de artefactos Análisis y diseño del sistema . Los artefactos para el análisis y del diseño capturan y presenta la información relacionada con la solución a los problemas se presentaron en los requisitos fijados .
- 35. Conjunto de artefactos Implementación . Los artefactos para la implementación capturan y presentan la realización de la solución presentada en el análisis y diseño del sistema.
- 36. Conjunto de artefactos Pruebas. Los artefactos desarrollados como productos de las actividades de prueba y de la evaluación son agrupadas por el actor responsable, con el cual se lleva un conjunto de documentos de información sobre las pruebas realizadas y las metodologías de pruebas aplicadas.
- 37. Conjunto de artefactos Despliegue . Los artefactos del despliegue capturan y presentan la información relacionada con la transitividad del sistema, presentada en la implementación en el ambiente de la producción
- 38. Conjunto de artefactos Administración del proyecto . El conjunto de artefactos de la administración del proyecto capturan los artefactos asociados con el proyecto, el planeamiento y a la ejecución del proceso.
- 39. Conjunto de artefactos Administración de cambios y configuración . Los artefactos de la configuración y administración del cambio capturan y presentan la información relacionada con la disciplina de configuración y administración del cambio.
- 40. Conjunto de artefactos Entorno o ambiente . El conjunto de artefactos del ambiente presentan los artefactos que se utilizan como dirección a través del desarrollo del sistema para asegurar la consistencia de todos los artefactos producidos.
- 41. Conjunto de artefactos Grado de finalización de artefactos . Son los lineamientos que se necesitan para ser completado. E n la disciplina de Implementación del Sistema los artefactos tienen una poca finalización y van aumentando progresivamente en cada fase hasta llegar a su culminación en la fase de Transición, en la disciplina de Ingeniería del Negocio los artefactos tienen una media finalización y sucede lo mismo que con los artefactos de la disciplina anterior los cuales finalizan también en la fase de Transición.
- 42. Introducción al UML El Lenguaje Unificado de Modelado, UML es una notación estándar para el modelado de sistemas software , resultado de una propuesta de estandarización promovida por el consorcio OMG ( Object Management Group ), del cual forman parte las empresas más importantes que se dedican al desarrollo de softwar e
- 43. Descripción del lenguaje UML es un lenguaje de propósito general para el modelado orientado a objetos, que combina notaciones provenientes desde: Modelado Orientado a Objetos, Modelado de Datos, Modelado de Componentes, Modelado de Flujos de Trabajo ( Workflows
- 44. Inconvenientes en el UML Como todo en el desarrollo de software UML presenta ciertos inconvenientes, entre los cuales se pueden mencionar: Falta integración con respecto de otras técnicas tales como patrones de diseño, interfaces de usuario, documentación, etc., los ejemplos aislados, el monopolio de conceptos, técnicas y métodos en torno a UML.
- 45. Descripción de los diagramas Un modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle. Un diagrama es una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo con vértices conectados por arcos. Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de interés. Es aquí donde se hace evidente la importancia de UML en el contexto de un proceso de desarrollo de software .
- 46. Relaciones de enlaces entre modelos Varios modelos aportan diferentes vistas de un sistema los cuales nos ayudan a comprenderlo desde varios frentes.
- 47. Diagramas, partes de un modelo
- 48. Diagrama de Casos de Uso Modela la funcionalidad del sistema agrupándola en descripciones de acciones ejecutadas por un sistema para obtener un resultado Describe lo que hace un sistema desde el punto de vista de un observador externo, se centra en un Que hace el sistema a diferencia de otros diagramas UML que intentan dar respuesta a un Como logra su comportamiento el sistema.
- 49. Diagrama de Casos de Uso El caso de uso se compone de dos áreas: La descripción escrita del comportamiento de sistema al afrontar una tarea de negocio o un requisito de negocio . Esta descripción se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas. La posición o contexto del caso de uso entre otros casos de uso . Dado que es un mecanismo de organización, un conjunto de casos de uso coherentes, consistentes promueve una imagen fácil del comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo.
- 50. Elementos de los casos de uso Actor : Un actor representa quien o que inicia una acción dentro del sistema, en otras palabras, es simplemente un rol que es llevado acabo por una persona o cosa. Un Actor en un diagrama Uso-Caso es representado por una figura en forma de persona .
- 51. Elementos de los casos de uso Uso-Caso : El uso-caso en sí es representado por un ovalo que describe la funcionalidad a grosso modo que se requiere por el sistema .
- 52. Elementos de los casos de uso Comunicación : Este elemento representa la relación que existe entre un Uso-Caso y un Actor, dicho elemento es representado simplemente por una línea recta que se extiende de la figura del actor hacia el ovalo del uso-caso
- 53. Elementos de los casos de uso Limite de Sistema (System Boundry) : Empleado para delimitar los limites del sistema, y representado por un rectángulo con color de fondo distintivo.
- 54. Elementos de los casos de uso Generalización : Una generalización indica que un uso-caso (ovalo) es un caso especial de otro caso, en otros términos, representa una relación padre-hijo, donde el hijo puede ser suplido directamente por el padre en cualquier momento. Este elemento es representado por una línea con flecha que se extiende del uso-caso hijo hacia el uso caso padre (general).
- 55. Elementos de los casos de uso Inclusión : Una inclusión es utilizada para indicar que un uso-caso (ovalo) depende de otro caso, dicho de otra manera, significa que la funcionalidad de determinado caso se requiere para realizar las tareas de otro. Este elemento es representado por una línea punteada con flecha y comentario <<include>> que se extiende del uso-caso base hacia el uso caso de inclusión.
- 56. Elementos de los casos de uso Extensión : Una extensión representa una variación de un uso-caso a otro, aunque similar a una generalización , una extensión representa una dependencia especifica, mientras una generalización no implica que los usos-casos dependen uno del otro. Este elemento es representado por una línea punteada con flecha y comentario <<extend>> que origina del uso-caso base hacia el uso caso de extensión.
- 57. Elementos de los casos de uso