Fases del rup 004

Fases del Rational Unified Process (RUP)

Año de la Integración Nacional y el Reconocimiento de Nuestra Diversidad Página 1

Computacion e Informatica

Codigo 36108

Autor: Arnol Zumaeta Carrillo



¿Que es el RUP?

El Rational Unified Process o Proceso Unificado de Rational Inc es una implementación comercialdel Proceso Unificado. Es un proceso de ingeniería de software que provee un enfoque paraasignar tareas y responsabilidades dentro de una organización de desarrollo. Su objetivo esasegurar la producción de software de alta calidad que satisfaga la necesidad del usuario finaldentro de un tiempo y presupuesto previsible.

El RUP mejora la productividad del equipo ya que permite que cada miembro del grupo sinimportar su responsabilidad específica acceda a la misma base de datos de conocimiento. Estohace que todos compartan el mismo lenguage, la misma visión y el mismo proceso acerca de cómodesarrollar software.

Fases de RUP

Sobre modelos

Las actividades de RUP se centran en crear y mantener modelos, utilizando UML, Lenguaje deModelización Unificado, en forma efectiva.

Como no existe un único proceso que sea apropiado para todos los desarrollos, RUP es un procesoconfigurable. Se adapta tanto a grupos pequeños de desarrollo como a grandes organizaciones.Basándose en lo que se consideran best practices, las mejores prácticas de desarrollo de software,RUP resulta apropiado para un amplia gama de proyectos y organizaciones.


Codigo 36108




Las 6 mejores prácticas de desarrollo que aplica RUP

* Desarrollo de software en forma iterativa

* Gestión de requerimientos

* Uso de arquitecturas basadas en componentes

* Modelización visual del software

* Verificación de calidad del software

* Control de cambios

1. Desarrollo de software en forma iterativa

Dada la complejidad de los sistemas de software modernos no es posible definir el problemaentero en forma secuencial, diseñarlo en su totalidad, construirlo y testearlo. El enfoque iterativopermite ir creciendo en el entendimiento del problema.a través de refinamientos sucesivos. Estotambién permite introducir cambios tácticos en los requerimientos, características del sistema oen los tiempos.

2. Gestión de requerimientos

Las nociones de casos de uso y escenarios resultaron ser una forma excelente de capturarrequerimientos funcionales y de asegurar que estos rijan el diseño, la implementación y el testeode software; haciendo más probable que el sistema final cumpla exactamente con lo que pidió elcliente.

3. Uso de arquitecturas basadas en componentes

RUP apoya el desarrollo de software basado en componentes. Los componentes son módulos notriviales, subsistemas que satisfacen una función definida. RUP proporciona un acercamientosistemático definiendo una arquitectura usando componentes nuevos y existentes. Éstos estánmontados en una arquitectura bien definida, o bien ad hoc, o en una infraestructura decomponentes reutilizables tal como el Internet, el CORBA, y J2EE

4. Modelización visual del software

El proceso le demuestra cómo modelar visualmente software para capturar la estructura y elcomportamiento de arquitecturas y de componentes. Esto permite que usted oculte los detalles yque escriba código usando “bloques de construcción gráficos.” Las abstracciones visuales leayudan a comunicar diversos aspectos del software, ayudan a mantener la consistencia entre undiseño y su puesta en marcha; y favorecen la comunicación inequívoca. El UML es la base de estamodelización visual.


Codigo 36108




5. Verificación de calidad del software

Una performance y una confiabilidad pobres son los factores comunes que inhibendramáticamente la aceptabilidad de los usos del software hoy en día. Por lo tanto, la calidad sedebe revisar con respecto a los requerimientos basados en la confiabilidad, funcionalidad,performance de la aplicación y del sistema. RUP le asiste en el planeamiento, el diseño, la puestaen marcha, la ejecución, y la evaluación de estos tipos de pruebas. El estudio de la calidad estáincorporado como parte del proceso, en todas las actividades, implicando a todos losparticipantes, usando medidas y criterios objetivos, y no se trata de una actividad separadarealizada por otro grupo.

6. Control de cambios

La capacidad de manejar los cambios - asegurándose que cada cambio sea aceptable, y pudiendocontinuar con los mismos- es esencial en un ambiente en el cual el cambio es inevitable. El procesodescribe cómo controlar, seguir y supervisar cambios para permitir el desarrollo iterativoacertado. También guía sobre cómo establecer los espacios de trabajo seguros para cadadesarrollador proporcionando el aislamiento de los cambios realizados en otros espacios detrabajo y controlando los cambios de todos los dispositivos de software (modelos, código,documentos, etc.). Describiendo cómo automatizar la integración, hace que el equipo trabajecomo una sola unidad.

RUP: Visión del proceso en 2 dimensiones

El proceso se puede describir en dos dimensiones:

* El eje horizontal representa tiempo y demuestra el aspecto dinámico del proceso, se expresa entérminos de ciclos, de fases, de iteraciones, y de hitos o milestones.

* El eje vertical representa el aspecto estático del proceso: cómo se describe en términos deactividades, de dispositivos, de trabajadores y de workflows.

El ciclo de vida del software está particionado en ciclos, cada ciclo trabaja en una nuevageneración del producto. El RUP divide un ciclo de desarrollo en cuatro fases consecutivas.

* Fase de inicio

* Fase de elaboración

* Fase de construcción

* Fase de transición


Codigo 36108




Cada fase constituye un eslabón bien definido, un punto en el tiempo en el cual ciertas decisionescríticas deben tomarse, y por lo tanto afinar metas debe haber sido alcanzadas.

Fase de inicio

Durante la fase del inicio, se establece el caso de negocio para el sistema y delimita el alcance delproyecto. Para lograr esto debe identificar todas las entidades externas con las cuales el sistemainteractúe (los actores) y definir la naturaleza de esta interacción a un nivel alto. Esto implicaidentificar todos los casos de uso y describir sólo los más significativos. El caso de negocio incluyecriterios de éxito, la evaluación de riesgos, y la estimación de los recursos necesarios, y un plan dela fase que muestre las fechas previstas e hitos importantes.

Resultado de la Fase de inicio

El resultado de la fase del inicio es:

* Un documento de la visión: una visión general de los requerimientos básicos del proyecto, de lascaracterísticas dominantes, y de las restricciones principales.

* Un modelo inicial de casos de uso (10%-20% completo).

* Un glosario inicial del proyecto (opcionalmente puede ser expresado como modelo de dominio).* Un caso inicial de negocio, que incluye contexto del negocio, los criterios del éxito (proyeccióndel rédito, reconocimiento del mercado, etcétera), y pronóstico financiero.

* Una estimación de riesgo inicial.

* Un plan de proyecto, demostrando fases e iteraciones.

* Un modelo de negocio, en caso de necesidad.

* Uno o más prototipos.

1er. Hito: Objetivos del Ciclo de vida

Los objetivos del ciclo de vida en el final de la fase del inicio son el primer hito principal delproyecto: el hito de los objetivos del ciclo de vida.

Los criterios de la evaluación para la fase del inicio son:

* Participación de los involucrados en la definición del alcance y estimaciones de costo y tiempos.* Entendimiento de los requerimientos según la fidelidad de los casos de uso primarios.* Estimaciones de costos/tiempos, de las prioridades, de los riesgos, y del proceso del desarrollocreíbles.*Cobertura de cualquier prototipo arquitectónico que se desarrolló.


Codigo 36108




* Gastos reales contra gastos planeados.

El proyecto puede ser cancelado o ser repensado considerablemente si no puede pasar este hito.

Fase de elaboración

El propósito de la fase de elaboración es analizar el dominio del problema, establecer unafundación arquitectónica sana, desarrollar el plan del proyecto, y eliminar los elementos del riesgomás alto del proyecto. Para lograr estos objetivos, usted debe tener una vision completa delsistema. Las decisiones arquitectónicas tienen que tomarse con una comprensión cabal delsistema: su alcance, funcionalidad importante y requerimientos no funcionales tales comorequerimientos de performance.

Es fácil argumentar que la fase de elaboración es la más crítica de las cuatro fases. En el final deesta fase, la “ingeniería dura” se considera completa y el proyecto experimenta su día másimportante: la decisión sobre si o no confiar en las fases de la construcción y de la transición. Parala mayoría de los proyectos, esto también corresponde a la transición de una fase de operatoriamóvil, ligera y ágil, poco arriesgada, a una de alto-costo, riesgo elevado con una inerciasubstancial. Mientras que el proceso siempre debe acomodarse a los cambios, las actividades de lafase de elaboración aseguran que la arquitectura, los requerimientos y los planes sean bastanteestables, y que los riesgos se atenúan lo suficiente, así usted puede determinar el costo y fecha determinación del desarrollo en forma bastante certera.

Durante fase de elaboración, se construye un prototipo ejecutable de la arquitectura en unas omás iteraciones, dependiendo del alcance, del tamaño, del riesgo, y de la novedad del proyecto.Este prototipo debe tratar por lo menos los casos de uso mas críticos identificados en la fase delinicio, que exponen típicamente los mayores riesgos técnicos del proyecto. Mientras que unprototipo evolutivo de un componente de calidad es siempre la meta, no excluye el desarrollo deunos o más prototipos exploratorios, desechables, para atenuar riesgos específicos.

Resultado de la Fase de Elaboración

El resultado de la fase de elaboración es:

* Un modelo de caso de uso (por lo menos 80% completo) - todos los casos de uso y actores debenhaber sido identificados-, y se han desarrollado la mayoría de las descripciones de casos de uso.

* Requerimientos suplementarios que capturan los requerimientos no funcionales o cualquierrequerimiento que no se asocie a un caso de uso específico.

* Una descripción de la arquitectura del software.

* Un prototipo arquitectónico ejecutable.

* Una lista revisada del riesgo y un caso de negocio revisado.


Codigo 36108




* Un plan de desarrollo para el proyecto total, incluyendo el plan de grano grueso del proyecto,demostrando iteraciones “y los criterios de la evaluación para cada iteración.

* Un caso actualizado del desarrollo que especifica el proceso que se utilizará.

* Un manual preliminar del usuario (opcional).

2do. Hito: La arquitectura del ciclo de vida

La arquitectura del ciclo de vida en el final de la fase de elaboración es el segundo hito importantedel proyecto. En este punto, se examinan los objetivos y el alcance detallado del sistema, la opciónde la arquitectura, y la resolución de los riesgos principales. Los criterios principales de laevaluación para la fase de elaboración implican las respuestas a estas preguntas:

* ¿Que tan estable es la visión del producto?

* ¿La arquitectura es estable?

* ¿La demostración ejecutable muestra que se han tratado y resuelto los rincipales elementos deriesgo?

* ¿El plan para la fase de la construcción esta suficientemente detallado?

* ¿Se cuenta con una base creíble de estimaciones?

* ¿Todos los involucrados en el proyecto están de acuerdo en que la visión actual se puedealcanzar si el plan actual se ejecuta para desarrollar el sistema completo, en el contexto de laarquitectura actual?

* ¿La diferencia entre los gastos reales y previstos es aceptable?

El proyecto puede ser abortado o ser repensado considerablemente si no puede pasar este hito.

La fase de la construcción

Durante la fase de la construcción, todos los componentes y características restantes sedesarrollan , se integran en el producto, y se prueban a fondo. La fase de la construcción es, encierto sentido, un proceso de fabricación donde el énfasis se pone en manejar los recursos ycontrolar las operaciones para optimizar costos, tiempos y calidad. Una arquitectura robusta y unplan comprensible estan íntimamente relacionados. Es decir, una de las cualidades críticas de laarquitectura es su facilidad de la construcción. Ésta es una razón por la que durante la fase deelaboración.se pone el enfasis en el desarrollo equilibrado de la arquitectura y del plan.


Codigo 36108




El resultado de la fase de la construcción:

El resultado de esta fase es un producto listo para poner en las manos de los usuarios finales.Como mínimo, consta de:

* El producto de software integrado en las plataformas adecuadas.

* Los manuales del usuario.

* Una descripción del la versión o release actual.

3er. Hito: La capacidad operacional inicial

El final de la fase de construcción es el tercer hito principal del proyecto En este punto, se decide siel software, los sitios, y los usuarios están operativos, sin exponer el proyecto a demasiadosriesgos. Este lanzamiento a menudo se llama un lanzamiento “beta”. Los criterios de la evaluaciónpara la fase de la construcción implican el contestar de estas preguntas:

* ¿Esta versión es lo suficientemente estable y madura para entregar al usuario?* ¿Todos los involucrados están listos para la transición del producto a producción ?* ¿La diferencia entre los gastos reales versus los planeados es aún aceptable?

La transición puede tener que ser pospuesta si el proyecto no puede alcanzar este hito.

Fase de la transición

El propósito de la fase de la transición es justamente la transición del producto de software alambiente de producción . Una vez que el producto se haya entregado al usuario final, surgenalgunos temas que llevan al desarrollo de nuevas versiones, a corregir errores, o a terminaralgunas características que habían sido pospuestas.

Se ingresa a esta fase cuando el producto está lo suficientemente maduro para comenzar a pasar aproducción . Esto requiere que un cierto subconjunto del sistema se encuentre en un nivelaceptable de la calidad y que la documentación del usuario está disponible de modo que latransición proporcione resultados positivos para todas las partes. Esto incluye:

* La “prueba beta” para validar el nuevo sistema contra las expectativas del usuario* Operación en paralelo con un sistema anterior que el nuevo sistema esté sustituyendo* La conversión de las bases de datos operacionales

*Entrenamientos y capacitación de los usuarios y la gente de mantenimiento* Lanzar el producto a los equipos de marketing, distribución y ventas


Codigo 36108




La fase de transición se centra en las actividades requeridas para poner el software en manos delos usuarios. Típicamente, esta fase incluye varias iteraciones, incluyendo lanzamientos beta,lanzamientos de disponibilidad general, así como la reparación de errores y el lanzamiento deversiones mejoradas. Un esfuerzo considerable se realiza en la documentación orientada alusuario final, en entrenar a los mismos, en brindar apoyo en las primeras etapas del uso, y enreaccionar al feedback que generen los mismos usuarios. En este punto del ciclo de vida, sinembargo, el feedback del usuario se debe centrar sobre todo en el ajuste fino del producto, laconfiguración , instalación, y a las cuestiones de usabilidad.

Esta fase puede variar -según el proyecto- de ser muy simple a muy compleja. Por ejemplo unanueva versión de un procesador de texto puede ser muy simple, mientras que substituir el sistemade control de tráfico aéreo de un país sería muy complejo.

4to. Hito: Lanzamiento del Producto

En este, se decide si los objetivos fueron alcanzados, y si se comienza otro ciclo de desarrollo. Enalgunos casos, este hito puede coincidir con el final de la fase del inicio para el ciclo siguiente. Loscriterios primarios de la evaluación para la fase de la transición implica las respuestas a estaspreguntas:

* ¿El usuario está satisfecho?

* ¿Los gastos reales versus los planeados son aun aceptables?

Iteraciones

Cada fase de RUP puede descomponerse en una o más iteraciones. Una iteración es un ciclocompleto de desarrollo que resulta en una versión o release (interno o externo) de un productoejecutable, un subconjunto del producto final que se encuentra bajo desarrollo y que creceincrementalmente en cada iteración hasta llegar al producto final.

Beneficios del enfoque iterativo

El proceso iterativo tienen las ventajas siguientes:

* Los riesgos son mitigados en forma temprana

* Los cambios son más manejables

* Alto nivel de reusabilidad

* El equipo de desarrollo puede aprender durante el proceso

* Mejor calidad global


Codigo 36108


Fases del rup 004

Documents

Transcript of Fases del rup 004