miércoles, 25 de julio de 2012

¿Que es Metodologia Rup?

El Proceso Racional Unificado 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.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más detallada, el Rational Unified Process, que se vendiera como producto independiente.

Proceso de Desarrollo del Software

El RUP está basado en 6 procesos que son los siguientes:

Adaptar el proceso:

El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactuar con él. Las características propias del proyecto u organización. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto en un área subformal.

Equilibrar prioridades:

Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.

Demostrar valor iterativamente:

Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados.

Colaboración entre equipos:

El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.

Elevar el nivel de abstracción:

Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilización del código.

Enfocarse en la calidad:

El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente. 

Fundamentos del Enfoque orientado a Objetos

 
El Enfoque Orientado a Objeto se basa en cuatro principios que constituyen la base de todo desarrollo orientado a objetos. Estos principios son: la Abstracción, el Encapsulamiento, la Modularidad y la Herencia.

Fundamento 1: Abstracción:

Es el principio de ignorar aquellos aspectos de un fenómeno observado que no son relevantes, con el objetivo de concentrarse en aquellos que si lo son. Una abstracción denota las características esenciales de un objeto (datos y operaciones), que lo distingue de otras clases de objetos. Decidir el conjunto correcto de abstracciones de un determinado dominio, es el problema central del diseño orientado a objetos.
Los mecanismos de abstracción son usados en el EOO para extraer y definir del medio a modelar, sus características y su comportamiento. Dentro del EOO son muy usados mecanismos de abstracción: la Generalización, la Agregación y la clasificación.
• La generalización es el mecanismo de abstracción mediante el cual un conjunto de clases de objetos son agrupados en una clase de nivel superior (Superclase), donde las semejanzas de las clases constituyentes (Subclases) son enfatizadas, y las diferencias entre ellas son ignoradas. En consecuencia, a través de la generalización, la superclase almacena datos generales de las subclases, y las subclases almacenan sólo datos particulares.La especialización es lo contrario de la generalización. Por ejemplo; La clase Médico es una especialización de la clase Persona, y a su vez, la clase Pediatra es una especialización de la superclase Médico.
• La agregación es el mecanismo de abstracción por el cual una clase de objeto es definida a partir de sus partes (otras clases de objetos). Mediante agregación se puede definir por ejemplo un computador, por descomponerse en: la CPU, la ULA, la memoria y los dispositivos periféricos. El contrario de agregación es la descomposición.
• La clasificación consiste en la definición de una clase a partir de un conjunto de objetos que tienen un comportamiento similar. La ejemplificación es lo contrario a la clasificación, y corresponde a la instanciación de una clase, usando el ejemplo de un objeto en particular.

Fundamento 2: Encapsulamiento:

Es la propiedad del EOO que permite ocultar al mundo exterior la representación interna del objeto. Esto quiere decir que el objeto puede ser utilizado, pero los datos esenciales del mismo no son conocidos fuera de él. La idea central del encapsulamiento es esconder los detalles y mostrar lo relevante. Permite el ocultamiento de la información separando el aspecto correspondiente a la especificación de la implementación; de esta forma, distingue el "qué hacer" del "cómo hacer". La especificación es visible al usuario, mientras que la implementación se le oculta.

Fundamento 3: Modularidad:

Es la propiedad que permite tener independencia entre las diferentes partes de un sistema. La modularidad consiste en dividir un programa en módulos o partes, que pueden ser compilados separadamente, pero que tienen conexiones con otros módulos. En un mismo módulo se suele colocar clases y objetos que guarden una estrecha relación. El sentido de modularidad está muy relacionado con el ocultamiento de información.

Fundamento 4: Herencia:

Es el proceso mediante el cual un objeto de una clase adquiere propiedades definidas en otra clase que lo preceda en una jerarquía de clasificaciones. Permite la definición de un nuevo objeto a partir de otros, agregando las diferencias entre ellos (Programación Diferencial), evitando repetición de código y permitiendo la reusabilidad.
Las clases heredan los datos y métodos de la superclase. Un método heredado puede ser sustituido por uno propio si ambos tienen el mismo nombre. La herencia puede ser simple (cada clase tiene sólo una superclase) o múltiple (cada clase puede tener asociada varias superclases). La clase Docente y la clase Estudiante heredan las propiedades de la clase Persona (superclase, herencia simple). La clase Preparador (subclase) hereda propiedades de la clase Docente y de la clase Estudiante (herencia múltiple).

Fundamento 5: Polimorfismo:

Es una propiedad del EOO que permite que un método tenga múltiples implementaciones, que se seleccionan en base al tipo objeto indicado al solicitar la ejecución del método. El polimorfismo operacional o Sobrecarga operacional permite aplicar operaciones con igual nombre a diferentes clases o están relacionados en términos de inclusión. En este tipo de polimorfismo, los métodos son interpretados en el contexto del objeto particular, ya que los métodos con nombres comunes son implementados de diferente manera dependiendo de cada clase.

Desarrollo de Componentes

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. En la Figura muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una baseline (Línea Base) de la arquitectura. Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de modelado del negocio y de requisitos.
En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la arquitectura.
En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones.
Para cada iteración se seleccionan algunos Casos de Uso, se refinan su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan iteraciones hasta que se termine la implementación de la nueva versión del producto.
En la fase de transición, se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo de la fase el esfuerzo dedicado a una disciplina varía.

Caracteristicas de Campo
  • Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
  • Pretende implementar las mejores prácticas en Ingeniería 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
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. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso).

Documentación

Primer nivel de documentación:

Especifica en términos generales qué actividades deberán integrar el Sistema de Aseguramiento de Calidad, que será implantado en la organización. Este nivel contiene los siguientes elementos:
• Declaración de Visión: Proyecciones de la administración sobre el lugar que ocupará la organización en el futuro.
• Declaración de Misión: Compromiso de la administración para alcanzar la Visión.
• Política de Calidad: Posición de la organización, en cuanto a la manera en que la calidad afectará la manera de cumplir con la Misión.
• Requerimientos de Calidad: Conjunto de actividades que la organización debe llevar a cabo, para asegurar la calidad tanto del proceso como el producto que desarrolla
La Visión, Misión y Políticas de Calidad fueron desarrolladas a partir de los lineamientos estratégicos del Departamento de Sistemas de Información.
El Requerimiento de Calidad se identifica en modelos de calidad como ISO 9000.

Segundo nivel de documentación:

Este nivel incluye especificaciones detalladas, orientadas a la administración, para explicar cómo se llevarán a cabo las actividades que integran el Sistema de Aseguramiento de Calidad. Este nivel está compuesto básicamente por procedimientos Administrativos, que son declaraciones de direcciones sistemáticas, sobre cómo la organización debe llevar a cabo cada uno de los Requerimientos de Calidad, definidos en el Primer Nivel de Documentación.

Tercer nivel de documentación:

Este nivel incluye especificaciones punto a punto, explícito y conciso para llevar a cabo cualquier tarea en la organización. Está compuesto básicamente por Procedimientos de Operativos que describen cada paso que se debe realizar para concretar una tarea o actividad; y Estándares que se utilizan con el fin de registrar datos o información de algo específico. Estos procedimientos y estándares han sido divididos en tres grupos:
1. Los relacionados con el desarrollo del curso Proyecto de Título.
2. Los relacionados con el desarrollo de producto de software.
3. Los que guían la implantación y mejoramiento del Sistema de Aseguramiento de Calidad.
Esta división facilita el uso y mantención del sistema. Por ejemplo, si hay cambios en las normas administrativas que afecten el desarrollo de los cursos en general, entonces sólo se verán afectados los procedimientos y estándares relacionados con el desarrollo del proyecto.

Artefactos

RUP en cada una de sus fases (pertenecientes a la estructura dinámica) realiza una serie de artefactos que sirven para comprender mejor tanto el análisis como el diseño del sistema (entre otros). Estos artefactos (entre otros) son los siguientes:

Inicio:
  • Documento Visión
  • Especificación de Requisitos
Elaboración:
  • Diagramas de caso de uso
Construcción:
  • Documento Arquitectura que trabaja con las siguientes vistas:
    Vista Lógica
    • Diagrama de clases
    • Modelo E-R (Si el sistema así lo requiere)
    Vista de Implementación
    • Diagrama de Secuencia
    • Diagrama de estados
    • Diagrama de Colaboración
    Vista Conceptual
    • Modelo de dominio
  • Vista física
    • Mapa de comportamiento a nivel de hardware.
AUTORES:
ALEJOS, OSMERY, C.I: 22.960.472
BLANCO, MIRIAGNY, C.I: 24.168.255
GUEVARA, DARWIN, C.I: 24.002.492
PINTO, ANGELICA, C.I: 21.300.269
VALERA, ODALYS, C.I: 20.464.013
VASQUEZ, LUSBARDO, C.I: 18.345.798

SECCION: 2402