Docstoc

Trabajo de la Metodologia Rup aplicada en la Empresa G-Teknik

Document Sample
Trabajo de la Metodologia Rup aplicada en la Empresa G-Teknik Powered By Docstoc
					                         UNIVERSIDAD DE ORIENTE.
                              NÚCLEO SUCRE.
                           ESCUELA DE CIENCIAS.
                      DEPARTAMENTO DE MATEMÁTICAS.
   COORDINACIÓN DEL PROGRAMA LICENCIATURA EN INFORMÁTICA.




Prof.:                                                 Bachilleres:
Alejandra Galantón.                                 Hernández Alexandra
                                                    Hernández Luis




                            Cumaná-Febrero- 2012.
                                      Introducción:


        El Proceso Unificado de Rational (Rational Unified Process en inglés,
habitualmente resumido como RUP) 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 orientados a objetos.

       RUP se puede definir como una forma disciplinada de asignar tareas y
responsabilidades en una empresa de desarrollo (quién hace qué, cuándo y cómo).

      Requiere un grupo grande de programadores para trabajar con esta metodología.
RUP es un marco del proyecto que describe una clase de los procesos que son iterativos e
incrementales, es el proceso de desarrollo más general de los existentes actualmente.

        Los procesos de RUP estiman tareas y horario del plan midiendo la velocidad de
iteraciones concerniente a sus estimaciones originales. Las iteraciones tempranas de
proyectos conducidos RUP se enfocan fuertemente sobre arquitectura del software; la
puesta en práctica rápida de características se retrasa hasta que se ha identificado y se ha
probado una arquitectura firme.

      La ventaja principal de RUP es que se basa en las mejores prácticas que se han
probado en el campo.
       Definición de Rational Unified Process (RUP).
   Es un proceso de ingeniería de software, el cual, provee un
enfoque disciplinado para asignar tareas y responsabilidades
dentro de una organización desarrolladora. Además es un producto
desarrollado y mantenido por Rational Software e integrado a un
conjunto de herramientas de desarrollo de software.

    Los orígenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken
Hartman, uno de los contribuidores claves de RUP colaboró con Boehm en la
investigación. En 1995 Rational Software compró una compañía sueca llamada Objectory
AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos de uso a los
métodos de desarrollo orientados a objetos. El Rational Unified Process fue el resultado de
una convergencia de Rational Approach y Objectory (el proceso de la empresa Objectory
AB). El primer resultado de esta fusión fue el Rational Objectory Process, la primera
versión de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en jefe Philippe
Kruchten.


       Mejores prácticas en el desarrollo de sistemas.
    Son principios fundamentales en los cuales las
herramientas de Rational se basan para el Desarrollo de
Software. Estos principios son:



   1. Desarrollar Software Iterativamente:

              Los malos entendidos se detectan al inicio.

               El enfoque iterativo facilita los reajustes tácticos de los requerimientos y
               características del cronograma.

              El equipo se concentra en lo esencial.

              Evaluaciones continuas dan un estado más exacto del proyecto.

               Las inconsistencias entre análisis, diseño e implementación se detectan
               tempranamente.

              Permite una mejor gerencia de riesgos.
          Se aplican las lecciones aprendidas.

          El cliente ve resultados a corto plazo.

2. Modelar el Software Visualmente:

          Disminuyen la ambigüedad.

          Los detalles no necesarios se ocultan.

          Se identifican arquitecturas no modulares e inflexibles.

          Un grafico dice más que 1000 palabras.




3. Administración de los requerimientos:

          Las comunicaciones se basan en requerimientos definidos

          Los requerimientos se priorizan y filtran

          Se hace posible una evaluación de la funcionalidad deseada

          Las inconsistencias se detectan tempranamente

          Se puede contar con un repositorio de requerimientos

4. Usar arquitecturas basadas en componentes:

          Se enfoca en el desarrollo inicial y fundamentado de una arquitectura
           ejecutable y robusta.

           Permite el reuso o adaptación de componentes existentes de miles de
           fuentes comercialmente disponibles.

          Permite identificar progresivamente componentes para el desarrollo.

          Permite un diseño arquitectónico flexible que se ajuste a los cambios.
                Los componentes proveen una base natural para la administración de
                configuración.

                El testing es organizado en torno a los componentes simples y luego es
                llevado hacia el conjunto de los componentes integrados.

   5. Verificación continua de la calidad:

               Se hace una evaluación objetiva del estatus del proyecto

               Se detecta inconsistencias entre análisis, diseño e implementación

               Las pruebas se concentran en los aspectos de mayor riesgo

               Los defectos se identifican claramente, se reducen los costos de su
                depuración

   6. Controlar los cambios:

               Las solicitudes de cambios se logran con buena comunicación.

               Las tasas de cambios arrojan información sobre el desempeño del proceso.

               La propagación del cambio es controlada.

               Se mantiene una arquitectura robusta.



       Conceptos básicos dentro de RUP.

           Trabajador: Un trabajador define el comportamiento y las responsabilidades de
            un individuo o grupo de individuos en un grupo de trabajo.

 Tiene como responsabilidades: Hacer una serie de actividades y ser el responsable de una
serie de artefactos.

           Actividad: Una actividad es una unidad de trabajo que se asigna a un
            trabajador.
Una actividad lleva entre un par de horas y un par de días, involucra un solo trabajador y un
número pequeño de artefactos. Las actividades se consideran en la planificación y
evaluación del progreso del proyecto.

           Artefactos: Elementos de información producidos, modificados o usados por el
            proceso. Son los productos tangibles del proyecto, además son usados por los
            trabajadores para realizar nuevas actividades y son el resultado de esas
            actividades.

           Iteración: Cada fase en RUP puede descomponerse en iteraciones. Una
            iteración es un ciclo de desarrollo completo dando como resultado un release
            (interna o externa) del producto ejecutable, un subconjunto del producto final
            de desarrollo, el cual crece incrementalmente de iteración a iteración hasta
            llegar a ser el sistema final.



       Dimensiones del proceso de RUP:
   El proceso propuesto por RUP posee dos dimensiones:

    La primera, representa el aspecto dinámico del proceso, y está expresado en términos de
ciclos, fases, iteraciones e hitos.

    La segunda, representa el aspecto estático, que se describe en términos de componentes,
actividades, flujos de trabajo y artefactos.
Las fases de la primera dimensión están conformadas por:

   1. Fase de inicio (Inspección, Concepción): Representa la idea, la visión del producto,
      como se enmarca en el negocio, el alcance del proyecto.


Artefactos:

             Un documento con la visión del proyecto.
              El modelo de Casos de Uso con una lista de todos los Casos de Uso y los
              actores que puedan ser identificados.
              Un glosario inicial del proyecto.
             Un Caso de Uso inicial de Negocio el cual incluye: contexto del negocio,
              criterios de éxito y planificación financiera.
              Un estudio inicial de riesgos.
             Un plan del proyecto que muestre las fases y las iteraciones.



   2. Fase de elaboración: Planificar las actividades necesarias y los recursos requeridos,
      especificando las características y el diseño de la arquitectura.

Artefactos:

             Un modelo de Casos de Uso (completo en al menos un 80%), con todos los
              actores identificados y la mayor parte de las descripciones de Casos de Uso.
              Requerimientos adicionales: los no funcionales o no asociados con ningún
              caso de uso.
              Descripción de la arquitectura del software.
             Prototipo ejecutable de arquitectura.
              Una lista revisada de riesgos.
             Plan del proyecto, incluyendo iteraciones y criterios de evaluación para cada
              iteración.
             Manual preliminar de usuario.

   3. Fase de construcción: Construir el producto, la arquitectura y los planes, hasta que
      el producto está listo para ser enviado a la comunidad de usuarios.

Artefactos:

             El producto de software integrado sobre la plataforma adecuada.
             Los manuales de usuario.
             Una descripción de la versión actual.
   4. Fase de transición: Realizar la transición del producto a los usuarios, lo cual
      incluye: manufactura, envío, entrenamiento, soporte y mantenimiento del producto,
      hasta que el cliente esté satisfecho.


    Actividades esenciales

             Ajustes, incluyendo corrección de errores y mejoramiento para desempeño y
              usabilidad.
             Empaque, envío, producción, venta y entrenamiento personal.


   La segunda dimensión están conformadas por flujos de trabajos, estos no son más que
secuencias de actividades que produce un resultado valioso.

   En términos de UML, un flujo de trabajo puede expresarse como un diagrama de
secuencia, un diagrama de colaboración, o un diagrama de actividad.

Se clasifican en:

   1. Flujo de trabajo de proceso, los cuales están comprendido por:

             Modelación de negocios:

                     Proporciona un idioma y un proceso común para los ingenieros de
                      negocio y los ingenieros de software a fin de que ambos se
                      comuniquen apropiadamente, mostrando además como crear y
                      mantener la trazabilidad entre el modelo del negocio y el modelo de
                      software.
                     El modelo de negocio se describe a través de los procesos de negocio,
                      utilizando para ello casos de uso de negocio. Esto asegura una
                      comprensión común entre todos los stakeholders de qué proceso de
                      negocio necesita ser apoyado por la organización.

             Requerimientos:

                     La meta es describir lo que el sistema debe hacer y permitir a los
                      desarrolladores y clientes estar de acuerdo en esa descripción.
                     Traslada las necesidades del negocio en comportamientos en un
                      sistema de software.
                     Se identifican actores y casos de uso.
        Se realiza la descripción de cada caso de uso y se obtiene el modelo
           de casos de uso.
   Análisis y Diseño:

        La meta es describir Cómo el sistema debe ser realizado en
         implementación.
        Trasladar los requisitos a una arquitectura de Software.
        Particionar y mezclar la actividad de análisis de objetos con la
         actividad de análisis de UC y el diseño de la arquitectura.
        Se obtiene el modelo de diseño, el modelo de análisis es opcional.

   Implementación:

    El propósito:
         Definir la organización del código en término de implementar
           subsistemas organizados en capas.
         Implementar clases y objetos en términos de componentes.
         Probar las componentes desarrolladas.
         Integrar las componentes en un sistema ejecutable.

   Prueba:

    El propósito:
         Verificar la interacción entre los objetos.
         Verificar la integración apropiada de componentes.
         Verificar que se satisfacen los requisitos.
         Identificar los defectos y corregirlos antes de la instalación.

   Despliegue:

    El propósito es producir un producto y hacerlo llegar a sus usuarios finales.
    Incluye varias actividades.

             Empaquetar el software.
             Distribuir el software.
             Instalar el software.
             Apoyar a los usuarios.

    La mayor parte de este flujo de trabajo ocurre durante la fase de Transición.
2. Flujo de trabajo de soporte, formado por:

         Administración, configuración y cambios:

              En este flujo de trabajo se describe como controlar los diferentes
               artefactos producidos por los miembros de un equipo de desarrollo.
              Gerenciar múltiples variantes de sistemas de software evolutivos.
              Gerenciar el desarrollo paralelo y solicitudes de cambio.
              Se describe como ejecutar auditoria sobre las actualizaciones de los
               artefactos.

         Administración de proyectos:

              La Administración/gerencia de proyectos de software es el arte de
               conciliar objetivos, gerenciar los riesgo, y superar las restricciones
               para entregar con éxito, un producto de software, que satisface las
               necesidades de los clientes (los inversionistas / usuarios).
              Para cumplir con esta tarea RUP incluye:
                    Un framework para manejo de proyectos de software.
                    Guías para planificación, provición de personal, ejecución y
                       monitoreo de proyectos.
                    Un framework para manejar riesgos

         Ambiente:

              El propósito del Flujo de trabajo de ambiente es proporcionar el
               ambiente de desarrollo a la organización de desarrollo, los procesos y
               las herramientas necesarias para apoyar al equipo de desarrollo.
              Se enfoca en actividades para configurar el proceso de desarrollo en
               el contexto de un proyecto.
              Contiene un kit de desarrollo que proporcional las guías, plantillas y
               herramientas necesarias para adaptar el proceso. “Development Kit
               for Process Customization”.
       Beneficios de implementar RUP en una empresa.
Algunas de las ventajas que nos brinda la implementación de RUP son:

      Nos permite asegurar la producción de un software de alta calidad que reúna las
       necesidades de los usuarios finales dentro de un plan y un presupuesto predecible.

       Provee un enfoque disciplinado para asignar tareas y responsabilidades dentro del
       desarrollo del sistema.

       Brinda un camino metódico, sistemático para desarrollar, diseñar y validar una
       arquitectura.

       Reduce en gran medida el riesgo que representa la construcción de sistemas
       complejos, porque evoluciona de forma incremental partiendo de sistemas más
       pequeños en los que ya se tiene confianza.
                                       Conclusión:


       Rational Unified Process (RUP) realiza un levantamiento exhaustivo de
requerimientos, busca detectar defectos en las fases iniciales, intenta reducir al número de
cambios tanto como sea posible, realiza el análisis y diseño e intenta anticiparse a futuras
necesidades.


   RUP posee dos dimensiones:

   La primera, está expresado en términos de ciclos, fases, iteraciones e hitos.

   Estas fases son:

      Inicio (Define el alcance del proyecto)
      Elaboración (Definición, análisis, diseño)
      Construcción (Implementación)
      Transición (Fin del proyecto y puesta en producción)

    Planear estas cuatro fases incluye: Asignación de tiempo, hitos principales, iteraciones
por fases y planes de proyectos.


   La segunda dimensión, representa el aspecto estático, que se describe en términos de
componentes, actividades, flujos de trabajo y artefactos.
                               Bibliografía:


   http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational

   http://prof.usb.ve/lmendoza/Documentos/PS-6116/Teoria%20PS6116%20O-
    O%20y%20RUP.pdf

   http://www.usmp.edu.pe/publicaciones/boletin/fia/info49/articulos/RUP%20vs.
    %20XP.pdf

				
DOCUMENT INFO
Shared By:
Tags:
Stats:
views:202
posted:4/18/2012
language:
pages:13