You are on page 1of 11

FUNDAMENTOS DEL ENFOQUE ORIENTADO A OBJETOS.

El Enfoque Orientado a Objeto se basa en cuatro principios que constituyen labase de todo desarrollo
orientado a objetos. Estos principios son: la Abstraccin, elEncapsulamiento, la Modularidad y la
Herencia.Fundamento
1: AbstraccinEs el principio de ignorar aquellos aspectos de un fenmeno observado que noson
relevantes, con el objetivo de concentrarse en aquellos que si lo son. Unaabstraccin denota las
caractersticas esenciales de un objeto (datos y operaciones),que lo distingue de otras clases de
objetos. Decidir el conjunto correcto deabstracciones de un determinado dominio, es el problema
central del diseo orientado aobjetos.Los mecanismos de abstraccin son usados en el EOO para
extraer y definir delmedio a modelar, sus caractersticas y su comportamiento. Dentro del EOO son
muyusados mecanismos de abstraccin: la Generalizacin, la Agregacin y la clasificacin.La
generalizacin es el mecanismo de abstraccin mediante el cual un conjunto declases de objetos son
agrupados en una clase de nivel superior (Superclase), donde lassemejanzas de las clases
constituyentes (Subclases) son enfatizadas, y las diferenciasentre ellas son ignoradas.
En consecuencia, a travs de la generalizacin, la superclasealmacena datos generales de las
subclases, y las subclases almacenan slo datosparticulares.La especializacin es lo contrario de la
generalizacin. Por ejemplo;
Laclase Mdico es una especializacin de la clase Persona, y a su vez, la clase Pediatraes una
especializacin de la superclase Mdico.La agregacin es el mecanismo de abstraccin por el cual una
clase de objeto esdefinida a partir de sus partes (otras clases de objetos). Mediante agregacin se
puededefinir por ejemplo un computador, por descomponerse en: la CPU, la ULA, la memoriay los
dispositivos perifricos. El contrario de agregacin es la descomposicin.La clasificacin consiste en la
definicin de una clase a partir de un conjunto deobjetos que tienen un comportamiento similar. La
ejemplificacin es lo contrario a laclasificacin, y corresponde a la instanciacin de una clase, usando
el ejemplo de unobjeto en particular.Fundamento
2: EncapsulamientoEs la propiedad del EOO que permite ocultar al mundo exterior la
representacininterna del objeto. Esto quiere decir que el objeto puede ser utilizado, pero los
datosesenciales del mismo no son conocidos fuera de l. La idea central delencapsulamiento es
esconder los detalles y mostrar lo relevante. Permite elocultamiento de la informacin separando el
aspecto correspondiente a laespecificacin de la implementacin; de esta forma, distingue el "qu
hacer" del "cmohacer". La especificacin es visible al usuario, mientras que la implementacin se
le oculta. El encapsulamiento en un sistema orientado a objeto se representa en cadaclase u objeto,
definiendo sus atributos y mtodos con los siguientes modos de acceso:
Pblico (+): Atributos o Mtodos que son accesibles fuera de la clase.
Pueden ser llamados por cualquier clase, aun si no est relacionada con ella.Privado (-): Atributos o
Mtodos que solo son accesibles dentro de laimplementacin de la clase.Protegido (#): Atributos o
Mtodos que son accesibles para la propia clase y susclases hijas (subclases).Los atributos y los
mtodos que son pblicos constituyen la interfaz de la clase,es decir, lo que el mundo exterior conoce
de la misma.Normalmente lo usual es que seoculten los atributos de la clase y solo sean visibles los
mtodos, incluyendo entoncesalgunos de consulta para ver los valores de los atributos. El mtodo
constructor (Nuevo,New) siempre es Pblico.Fundamento
3: ModularidadEs la propiedad que permite tener independencia entre las diferentes partes de
unsistema. La modularidad consiste en dividir un programa en mdulos o partes, quepueden ser

compilados separadamente, pero que tienen conexiones con otros mdulos.En un mismo mdulo se
suele colocar clases y objetos que guarden una estrecharelacin. El sentido de modularidad est muy
relacionado con el ocultamiento deinformacin.Fundamento
4: HerenciaEs el proceso mediante el cual un objeto de una clase adquiere propiedades definidasen
otra clase que lo preceda en una jerarqua de clasificaciones. Permite la definicinde un nuevo objeto
a partir de otros, agregando las diferencias entre ellos(Programacin Diferencial), evitando repeticin
de cdigo y permitiendo la reusabilidad.Las clases heredan los datos y mtodos de la superclase. Un
mtodo heredado puedeser sustituido por uno propio si ambos tienen el mismo nombre. La herencia
puede ser simple (cada clase tiene slo una superclase) o mltiple (cada clase puede tener asociada
varias superclases). La clase Docente y la clase Estudiante heredan laspropiedades de la clase Persona
(superclase, herencia simple). La clase Preparador (subclase) hereda propiedades de la clase Docente
y de la clase Estudiante (herenciamltiple).Fundamento 5: PolimorfismoEs una propiedad del EOO que
permite que un mtodo tenga mltiplesimplementaciones, que se seleccionan en base al tipo objeto
indicado al solicitar laejecucin del mtodo. El polimorfismo operacional o Sobrecarga operacional
permiteaplicar operaciones con igual nombre a diferentes clases o estn relacionados entrminos de
inclusin. En este tipo de polimorfismo, los mtodos son interpretados en el contexto del objeto
particular, ya que los mtodos con nombres comunes sonimplementados de diferente manera
dependiendo de cada clase.Por ejemplo, el rea de un cuadrado, rectngulo y crculo, son calculados
de maneradistinta; sin embargo, en sus clases respectivas puede existir la implementacin delrea
bajo el nombre comn rea. En la prctica y dependiendo del objeto que llame almtodo, se usar el
cdigo correspondiente.Ejemplos:Superclase: Clase AnimalSubclases:Clases Mamfero, Ave, Pez.Se
puede definir un mtodo Comer en cada subclase, cuya implementacincambia de acuerdo a la clase
invocada, sin embargo el nombre del mtodo es elmismo.Mamifero.Comer Ave.Comer
Pez.Comer Otro ejemplo de polimorfismo es el operador +. Este operador tiene dosfunciones
diferentes de acuerdo al tipo de dato de los operandos a los que se aplica. Silos dos elementos son
numricos, el operador + significa suma algebraica de losmismos, en cambio si por lo menos uno de los
operandos es un String o Carcter, eloperador es la concatenacin de cadenas de
caracteres.Caractersticas del Enfoque Orientado a Objetos.Las caractersticas siguientes son las ms
importantes:Abstraccin: Denota las caractersticas esenciales de un objeto, donde se capturansus
comportamientos.Cada objeto en el sistema sirve como modelo de un "agente"abstracto que puede
realizar trabajo, informar y cambiar su estado, y "comunicarse" conotros objetos en el sistema sin
revelar cmo se implementan estas caractersticas. Losprocesos, las funciones o los mtodos pueden
tambin ser abstrados y cuando loestn, una variedad de tcnicas son requeridas para ampliar una
abstraccin.Elproceso de abstraccin permite seleccionar las caractersticas relevantes dentro de
unconjunto e identificar comportamientos comunes para definir nuevos tipos de entidadesen el mundo
real. La abstraccin es clave en el proceso de anlisis y diseo orientado aobjetos, ya que mediante
ella podemos llegar a armar un conjunto de clases quepermitan modelar la realidad o el problema que
se quiere atacar.Encapsulamiento: Significa reunir a todos los elementos que pueden
considerarsepertenecientes a una misma entidad, al mismo nivel de abstraccin. Esto
permiteaumentar la cohesin de los componentes del sistema. Algunos autores confunden
esteconcepto con el principio de ocultacin, principalmente porque se suelen emplear
conjuntamente.
Modularidad: Se denomina Modularidad a la propiedad que permite subdividir unaaplicacin en partes
ms pequeas (llamadas mdulos), cada una de las cuales debeser tan independiente como sea posible
de la aplicacin en s y de las restantes partes.Estos mdulos se pueden compilar por separado, pero

tienen conexiones con otrosmdulos. Al igual que la encapsulacin, los lenguajes soportan la
Modularidad dediversas formas.Principio de ocultacin: Cada objeto est aislado del exterior, es un
mdulo natural, ycada tipo de objeto expone una interfaz a otros objetos que especfica cmo
puedeninteractuar con los objetos de la clase. El aislamiento protege a las propiedades de unobjeto
contra su modificacin por quien no tenga derecho a acceder a ellas, solamentelos propios mtodos
internos del objeto pueden acceder a su estado. Esto asegura queotros objetos no pueden cambiar el
estado interno de un objeto de manerasinesperadas, eliminando efectos secundarios e interacciones
inesperadas. Algunoslenguajes relajan esto, permitiendo un acceso directo a los datos internos del
objeto deuna manera controlada y limitando el grado de abstraccin. La aplicacin entera sereduce a
un agregado o rompecabezas de objetos.Polimorfismo: Comportamientos diferentes, asociados a
objetos distintos, puedencompartir el mismo nombre, al llamarlos por ese nombre se utilizar el
comportamientocorrespondiente al objeto que se est usando. O dicho de otro modo, las referencias
ylas colecciones de objetos pueden contener objetos de diferentes tipos, y la invocacinde un
comportamiento en una referencia producir el comportamiento correcto para eltipo real del objeto
referenciado. Cuando esto ocurre en "tiempo de ejecucin", estaltima caracterstica se llama
asignacin tarda o asignacin dinmica. Algunoslenguajes proporcionan medios ms estticos (en
"tiempo de compilacin") depolimorfismo, tales como las plantillas y la sobrecarga de operadores de
C++.Herencia: Las clases no estn aisladas, sino que se relacionan entre s, formandouna jerarqua de
clasificacin. Los objetos heredan las propiedades y elcomportamiento de todas las clases a las que
pertenecen. La herencia organiza yfacilita el polimorfismo y el encapsulamiento permitiendo a los
objetos ser definidos ycreados como tipos especializados de objetos preexistentes. Estos pueden
compartir (yextender) su comportamiento sin tener que volver a implementarlo. Esto suele
hacersehabitualmente agrupando los objetos en clases y estas en rboles o enrejados quereflejan un
comportamiento comn. Cuando un objeto hereda de ms de una clase sedice que hay herencia
mltiple.Recoleccin de basura: La recoleccin de basura o garbage collector es la tcnicapor la cual
el entorno de objetos se encarga de destruir automticamente, y por tantodesvincular la memoria
asociada, los objetos que hayan quedado sin ninguna referenciaa ellos. Esto significa que el
programador no debe preocuparse por la asignacin oliberacin de memoria, ya que el entorno la
asignar al crear un nuevo objeto y laliberar cuando nadie lo est usando. En la mayora de los
lenguajes hbridos que seextendieron para soportar el Paradigma de Programacin Orientada a Objetos
como C++ u Object Pascal, esta caracterstica no existe y la memoria debe desasignarse manualmente.

Componentes del Software


La reutilizacin es una caracterstica e implementarse para que pueda volver a ser reutilizado en
muchos programas diferentes.
Los componentes de software se construyen mediante un lenguaje de programacin que tiene un
vocabulario limitado, una gramtica definida explcitamente y reglas bien formadas de sintaxis y
semntica.
Aplicaciones del Software
El software puede aplicarse en cualquier situacin en la que se haya definido previamente un conjunto
especifico de pasos procedimentales (es decir, un algoritmo). (Excepciones notables a esta regla son el
software de los sistemas expertos y de redes neuronales).
Las siguientes reas del software indican la amplitud de las aplicaciones potenciales:

Software de Sistemas: El software de sistemas es un conjunto de programas que han


sido escritos para servir a otros programas. El rea del Software de Sistemas se caracteriza

por una fuerte interaccin con el hardware de la computadora; una gran utilizacin por
mltiples usuarios; una operacin concurrente que requiere una planificacin, una
comparticin de recursos y una sofisticada gestin de procesos; unas estructuras de datos
complejas y mltiples interfaces externas. (p. Ej.: compiladores, editores, utilidades, ciertos
componentes del sistema operativo, utilidades de manejo de perifricos, procesadores de
telecomunicaciones).
Software de Tiempo Real: El software que mide/analiza/controla sucesos del mundo
real conforme ocurren, se denomina de tiempo real. Entre los elementos del software de
tiempo real se incluyen: un componente de adquisicin de datos que recolecta y da formato
a la informacin recibida del entorno externo, un componente de anlisis que transforma la
informacin recibida del entorno externo, un componente de anlisis que transforma la
informacin segn lo requiera la aplicacin, un componente de control/salida que responda
al entorno externo y un componente de monitorizacin que coordina todos los dems
componentes, de forma tal que pueda mantenerse la respuesta en tiempo real.
Software de Gestin: El procesamiento de informacin comercial constituye la mayor
de las reas de aplicacin del software. Los sistemas discretos (p. Ej.: nominas, cuentas de
haberes/dbitos, inventarios, etc.), han evolucionado hacia el software de sistemas de
informacin de gestin (SIG), que accede a una o ms bases de datos grandes que contienen
informacin comercial. Las aplicaciones en esta rea reestructuran los datos existentes para
facilitar las operaciones comerciales o gestionar la toma de decisiones. Adems de las
tareas convencionales de procesamiento de datos, las aplicaciones de software de gestin
tambin realizan calculo interactivo (p. Ej. : el procesamiento de transacciones en puntos de
ventas).
Software de Ingeniera y Cientfico: El software de Ingeniera y Cientfico est
caracterizado por los algoritmos de manejo de nmeros. Las aplicaciones van desde la
astronoma a la vulcanologa, desde el anlisis de la presin de los automotores a la
dinmica orbital de los lanzadores espaciales y desde la biologa molecular a la fabricacin
automtica.
Software Empotrado: El software Empotrado reside en memoria de solo lectura y se
utiliza para controlar productos y sistemas de los mercados industriales y de consumo. El
software empotrado puede ejecutar funciones muy limitadas y curiosas (p. Ej.: el control de
las teclas de un horno de microondas) o suministrar una funcin significativa y con
capacidad de control (p. Ej.: funciones digitales en un automvil, tales como control de la
gasolina, indicaciones en el salpicadero, sistemas de frenado, etc.).
Software de Computadoras Personales: El mercado del software de computadoras
personales ha germinado en la pasada dcada. El procesamiento de textos, las hojas de
calculo, los grficos por computadora, multimedia, entretenimientos, gestin de bases de
datos, aplicaciones financieras de negocios y personales, y redes o acceso a bases de datos
externas son algunas de los cientos de aplicaciones.
Software de Inteligencia Artificial: El software de inteligencia artificial (IA) hace uso
de algoritmos no numricos para resolver problemas complejos para los que no son
adecuados el calculo o el anlisis directo. El rea ms activa de la IA es la de los sistemas
expertos, tambin llamados sistemas basados en el conocimiento.Hoy en da el software tiene
un doble papel. Es un producto y, al mismo tiempo, el vehculo para hacer entrega de un producto.
Como producto, hace entrega de la potencia informtica del hardware informtico. Si reside dentro de
un telfono celular u opera dentro de una computadora central, el software es un transformador de

informacin, produciendo, gestionando, adquiriendo, modificando, mostrando o transmitiendo


informacin que puede ser tan simple como un solo bit, o tan compleja como una simulacin en
multimedia. Como vehculo utilizado para hacer entrega del producto, el software acta como la base
de control de la computadora (sistemas operativos), la comunicacin de informacin (redes), y la
creacin y control de otros programas (herramientas de software y entornos).
El software de computadora, se ha convertido en el alma mater. Es la maquina que conduce a la toma
de decisiones comerciales. Sirve como la base de investigacin cientfica moderna y de resolucin de
problemas de ingeniera. Es el factor clave que diferencia los productos y servicios modernos. Est
inmerso en sistemas de todo tipo: de transportes, mdicos, de telecomunicaciones, militares, procesos
industriales, entretenimientos, productos de oficina, etc. El software ser el que nos lleve de la mano
en los avances en todo desde la educacin elemental a la Ingeniera Gentico.
DESARROLLO DE SOFTWARE METODOLOGA RUP
El Proceso Unificado Racional, Rational Unified Process en ingls, y sus siglas RUP, es un proceso de
desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa
estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a
objetos. El RUP no es un sistema con pasos firmemente establecidos, sino que trata de un conjunto de
metodologas adaptables al contexto y necesidades de cada organizacin, donde el software es
organizado como una coleccin de unidades atmicas llamados objetos, constituidos por datos y
funciones, que interactan entre s.
RUP es un proceso para el desarrollo de un proyecto de un software que define claramente quien,
cmo, cundo y qu debe hacerse en el proyecto
RUP como proceso de desarrollo
RUP es explcito en la definicin de software y su trazabilidad, es decir, contempla en relacin causal
de los programas creados desde los requerimientos hasta la implementacin y pruebas.
RUP identifica claramente a los profesionales (actores) involucrados en el desarrollo del software y
sus responsabilidades en cada una de las actividades.
Fases de desarrollo del software
Inicio
Elaboracin
Construccin
Transicin
Fase de inicio
Se hace un plan de fases, donde se identifican los principales casos de uso y se identifican los riesgos.
Se concreta la idea, la visin del producto, como se enmarca en el negocio, el alcance del proyecto. El
objetivo en esta etapa es determinar la visin del proyecto.
Modelado del negocio
En esta fase el equipo se familiarizar ms al funcionamiento de la empresa, sobre conocer sus
procesos.
Entender la estructura y la dinmica de la organizacin para la cual el sistema va ser desarrollado.
Entender el problema actual en la organizacin objetivo e identificar potenciales mejoras.
Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento comn de la
organizacin objetivo.
Requisitos
En esta lnea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales
tienen que comprender y aceptar los requisitos que especifiquemos.
Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que el sistema podra
hacer.
Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema.
Definir el mbito del sistema.
Proveer una base para estimar costos y tiempo de desarrollo del sistema.
Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario.

Fase de elaboracin
Se realiza el plan de proyecto, donde se completan los casos de uso y se mitigan los riesgos. Planificar
las actividades necesarias y los recursos requeridos, especificando las caractersticas y el diseo de la
arquitectura. En esta etapa el objetivo es determinar la arquitectura ptima.
Anlisis y Diseo
En esta actividad se especifican los requerimientos y se describen sobre cmo se van a implementar en
el sistema.
Transformar los requisitos al diseo del sistema.
Desarrollar una arquitectura para el sistema.
Adaptar el diseo para que sea consistente con el entorno de implementacin.
Fase de construccin
Se basa en la elaboracin de un producto totalmente operativo y en la elaboracin del manual de
usuario. Construir el producto, la arquitectura y los planes, hasta que el producto est listo para ser
enviado a la comunidad de usuarios. En esta etapa el objetivo es llevar a obtener la capacidad
operacional inicial.
Implementacin
Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y dems. El resultado
final es un sistema ejecutable.
Planificar qu subsistemas deben ser implementados y en qu orden deben ser integrados, formando
el Plan de Integracin.
Cada implementador decide en qu orden implementa los elementos del subsistema.
Si encuentra errores de diseo, los notifica.
Se integra el sistema siguiendo el plan.
Pruebas
Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando,
pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino que debe ir
integrado en todo el ciclo de vida.
Encontrar y documentar defectos en la calidad del software.
Generalmente asesora sobre la calidad del software percibida.
Provee la validacin de los supuestos realizados en el diseo y especificacin de requisitos por medio
de demostraciones concretas.
Verificar las funciones del producto de software segn lo diseado.
Verificar que los requisitos tengan su apropiada implementacin.
Etapa de transicin
El objetivo es llegar a obtener el release del proyecto. Se realiza la instalacin del producto en el
cliente y se procede al entrenamiento de los usuarios. Realizar la transicin del producto a los
usuarios, lo cual incluye: manufactura, envo, entrenamiento, soporte y mantenimiento del producto,
hasta que el cliente quede satisfecho, por tanto en esta fase suelen ocurrir cambios.
Despliegue
Esta actividad tiene como objetivo producir con xito distribuciones del producto y distribuirlo a los
usuarios. Las actividades implicadas incluyen:
Probar el producto en su entorno de ejecucin final.
Empaquetar el software para su distribucin.
Distribuir el software.
Instalar el software.
Proveer asistencia y ayuda a los usuarios.
Formar a los usuarios y al cuerpo de ventas.
Migrar el software existente o convertir bases de datos.

Figura donde se muestra las fases de la metodologa RUP


Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en
reproducir el ciclo de vida en cascada a menor escala. Los objetivos de una iteracin se establecen en
funcin de la evaluacin de las iteraciones precedentes.
A medida que se avanza en el proyecto, es decir, cuando se va pasando de una fase a otra, la
importancia relativa de cada uno de los Flujos de Trabajo va cambiando. As, en las iteraciones de la
Fase de Inicio el trabajo se centra principalmente en el Modelamiento del Negocio y en la captura y
especificacin de requisitos. Pero en la fase de Construccin el desarrollo est enfocado en la
Implementacin (codificacin) y, en menor medida, en el Diseo
Como filosofa RUP maneja 6 principios clave
Adaptacin del proceso
El proceso deber adaptarse a las caractersticas propias de la organizacin. El tamao del mismo, as
como las regulaciones que lo condicionen, influirn en su diseo especfico. Tambin se deber tener
en cuenta el alcance del proyecto.
Balancear prioridades
Los requerimientos de los diversos inversores pueden ser diferentes, contradictorios o disputarse
recursos limitados. Debe encontrarse un balance que satisfaga los deseos de todos.
Colaboracin entre equipos
El desarrollo de software no hace una nica persona sino mltiples equipos. Debe haber una
comunicacin fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc.
Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de modo interno, en etapas iteradas. En cada iteracin se
analiza la opinin de los inversores, la estabilidad y calidad del producto, y se refina la direccin del
proyecto as como tambin los riesgos involucrados.
Elevar el nivel de abstraccin
Este principio dominante motiva el uso de conceptos reutilizables tales como patrn del software,
lenguajes 4GL o esquemas (Frameworks) por nombrar algunos. Estos se pueden acompaar por las
representaciones visuales de la arquitectura, por ejemplo con UML.
Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteracin, sino en todos los aspectos de la
produccin.
Roles que se cumplen en el RUP
Analistas:
Analista de procesos de negocio.
Diseador del negocio.
Analista de sistema.
Especificador de requisitos.
Desarrolladores:
Arquitecto de software.
Diseador.

Diseador de interfaz de usuario


Diseador de cpsulas.
Diseador de base de datos.
Implementador.
Integrador.
Gestores:
Jefe de proyecto
Jefe de control de cambios.
Jefe de configuracin.
Jefe de pruebas
Jefe de despliegue
Ingeniero de procesos
Revisor de gestin del proyecto
Gestor de pruebas.
Apoyo:
Documentador tcnico
Administrador de sistema
Especialista en herramientas
Desarrollador de cursos
Artista grfico
Especialista en pruebas:
Especialista en Pruebas
Analista de pruebas
Diseador de pruebas
Otros roles:
Stakeholders
Revisor
Coordinacin de revisiones
Revisor tcnico
Gestin del proyecto
Se vigila el cumplimiento de los objetivos, gestin de riesgos y restricciones para desarrollar un
producto que sea acorde a los requisitos de los clientes y los usuarios.
Proveer un marco de trabajo para la gestin de proyectos de software intensivos.
Proveer guas prcticas realizar planeacin, contratar personal, ejecutar y monitorear el proyecto.
Proveer un marco de trabajo para gestionar riesgos.
Configuracin y control de cambios
El control de cambios permite mantener la integridad de todos los mdulos que se crean en el proceso,
as como de mantener informacin del proceso evolutivo que han seguido.
Entorno
La finalidad de esta actividad es dar soporte al proyecto con las adecuadas herramientas, procesos y
mtodos. Brinda una especificacin de las herramientas que se van a necesitar en cada momento, as
como definir la instancia concreta del proceso que se va a seguir.
En concreto las responsabilidades de este flujo de trabajo incluyen:
Seleccin y adquisicin de herramientas.
Establecer y configurar las herramientas para que se ajusten a la organizacin.
Configuracin del proceso.
Mejora del proceso.
Servicios tcnicos.
Niveles de documentacin de la metodologa RUP
Primer nivel de documentacin
Especifica en trminos generales qu actividades debern integrar el Sistema de Aseguramiento de

Calidad, que ser implantado en la organizacin. Este nivel contiene los siguientes elementos:
Declaracin de Visin: Proyecciones de la administracin sobre el lugar que ocupar la organizacin
en el futuro.
Declaracin de Misin: Compromiso de la administracin para alcanzar la Visin.
Poltica de Calidad: Posicin de la organizacin, en cuanto a la manera en que la calidad afectar la
manera de cumplir con la Misin.
Requerimientos de Calidad: Conjunto de actividades que la organizacin debe llevar a cabo, para
asegurar la calidad tanto del proceso como el producto que desarrolla
La Visin, Misin y Polticas de Calidad fueron desarrolladas a partir de los lineamientos estratgicos
del Departamento de Sistemas de Informacin.
El Requerimiento de Calidad se identifica en modelos de calidad como ISO 9000.
Segundo nivel de documentacin
Este nivel incluye especificaciones detalladas, orientadas a la administracin, para explicar cmo se
llevarn a cabo las actividades que integran el Sistema de Aseguramiento de Calidad. Este nivel est
compuesto bsicamente por procedimientos Administrativos, que son declaraciones de direcciones
sistemticas, sobre cmo la organizacin debe llevar a cabo cada uno de los Requerimientos de
Calidad, definidos en el Primer Nivel de Documentacin.
Tercer nivel de documentacin
Este nivel incluye especificaciones punto a punto, explcito y conciso para llevar a cabo cualquier
tarea en la organizacin. Est compuesto bsicamente por Procedimientos de Operativos que describen
cada paso que se debe realizar para concretar una tarea o actividad; y Estndares que se utilizan con
el fin de registrar datos o informacin de algo especfico. Estos procedimientos y estndares han sido
divididos en tres grupos:
1. Los relacionados con el desarrollo del curso Proyecto de Ttulo.
2. Los relacionados con el desarrollo de producto de software.
3. Los que guan la implantacin y mejoramiento del Sistema de Aseguramiento de Calidad.
Esta divisin facilita el uso y mantencin del sistema. Por ejemplo, si hay cambios en las normas
administrativas que afecten el desarrollo de los cursos en general, entonces slo se vern afectados los
procedimientos y estndares relacionados con el desarrollo del proyecto.
Ciclo de iteraciones de la metodologa RUP
Vale mencionar que el ciclo de vida que se desarrolla por cada iteracin, es llevada bajo dos
disciplinas:
Disciplina de Desarrollo
Ingeniera de Negocios: Entendiendo las necesidades del negocio.
Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado.
Anlisis y Diseo: Trasladando los requerimientos dentro de la arquitectura de software.
Implementacin: Creando software que se ajuste a la arquitectura y que tenga el comportamiento
deseado.
Pruebas: Asegurndose que el comportamiento requerido es el correcto y que todo lo solicitado est
presente.
Disciplina de Soporte
Configuracin y administracin del cambio: Guardando todas las versiones del proyecto.
Administrando el proyecto: Administrando horarios y recursos.
Ambiente: Administrando el ambiente de desarrollo.
Los elementos del RUP son:
Actividades, Son los procesos que se llegan a determinar en cada iteracin.
Trabajadores, Vienen hacer las personas o entes involucrados en cada proceso.
Artefactos, Un artefacto puede ser un documento, un modelo, o un elemento de modelo.
Una particularidad de esta metodologa es que, en cada ciclo de iteracin, se hace exigente el uso de
artefactos, siendo por este motivo, una de las metodologas ms importantes para alcanzar un grado
de certificacin en el desarrollo del software.

Mtodo pesado
Costo del cambio

Un cambio en las etapas de vida del sistema incrementara notablemente el costo.


Requiere un grupo grande de programadores para trabajar con esta metodologa.
Cada fase en RUP puede descomponerse en iteraciones. Una iteracin es un ciclo de desarrollo
completo dando como resultado una entrega de producto ejecutable (interna o externa).
El proceso define una serie de roles:
Los roles se distribuyen entre los miembros del proyecto y que definen las tareas de cada uno y el
resultado (artefactos) que se espera de ellos.

Figura donde se muestra la definicin de roles


Dimensiones del RUP
El RUP tiene dos dimensiones:
El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida del proceso.
El eje vertical representa las disciplinas, que agrupan actividades definidas lgicamente por la
naturaleza.
La primera dimensin representa el aspecto dinmico del proceso y se expresa en trminos de fases,
de iteraciones, y la finalizacin de las fases. La segunda dimensin representa el aspecto esttico del
proceso: cmo se describe en trminos de componentes de proceso, las disciplinas, las actividades, los
flujos de trabajo, los artefactos, y los roles.
Caractersticas esenciales que definen al RUP
Proceso Dirigido por los Casos de Uso:
Con esto se refiere a la utilizacin de los Casos de Uso para el desenvolvimiento y desarrollo de las
disciplinas con los artefactos, roles y actividades necesarias. Los Casos de Uso son la base para la
implementacin de las fases y disciplinas del RUP. Un Caso de Uso es una secuencia de pasos a seguir
para la realizacin de un fin o propsito, y se relaciona directamente con los requerimientos, ya que
un Caso de Uso es la secuencia de pasos que conlleva la realizacin e implementacin de un
Requerimiento planteado por el Cliente.
Proceso Iterativo e Incremental: Es el modelo utilizado por RUP para el desarrollo de un proyecto de
software. Este modelo plantea la implementacin del proyecto a realizar en Iteraciones, con lo cual se
pueden definir objetivos por cumplir en cada iteracin y as poder ir completando todo el proyecto
iteracin por iteracin, con lo cual se tienen varias ventajas, entre ellas se puede mencionar la de
tener pequeos avances del proyectos que son entregables al cliente el cual puede probar mientras se
est desarrollando otra iteracin del proyecto, con lo cual el proyecto va creciendo hasta completarlo

en su totalidad.
Proceso Centrado en la Arquitectura:
Define la Arquitectura de un sistema, y una arquitectura ejecutable construida como un prototipo
evolutivo. Arquitectura de un sistema es la organizacin o estructura de sus partes ms relevantes.
Una arquitectura ejecutable es una implementacin parcial del sistema, construida para demostrar
algunas funciones y propiedades. RUP establece refinamientos sucesivos de una arquitectura
ejecutable, construida como un prototipo evolutivo.
Alcance de la metodologa RUP
La metodologa RUP es ms apropiada para proyectos grandes, tambin pequeos, dado que requiere
un equipo de trabajo capaz de administrar un proceso complejo en varias etapas. En proyectos
pequeos, es posible que no se puedan cubrir los costos de dedicacin del equipo de profesionales
necesarios.
Antecedentes del RUP
Los orgenes 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 investigacin. En 1995 Rational Software
compr una compaa sueca llamada Objectory AB, fundada por Ivar Jacobson, famoso por haber
incorporado los casos de uso a los mtodos de desarrollo orientados a objetos. El Rational Unified
Process fue el resultado de una convergencia de Rational Approach y Objectory. El primer resultado de
esta fusin fue el Rational Objectory Process, la primera versin de RUP, fue puesta en el mercado en
1998, siendo el arquitecto en jefe Philippe Kruchten. Desde all hasta la actualidad es la metodologa
ms empleada en el mundo.
Un FRAMEWORK de mtodos y mdulos reutilizables
Antes de que se puede aplicar a proyectos especficos dentro de una organizacin. Del mismo modo,
necesita terminar el esqueleto RUP y sus bibliotecas para adaptarlos a la organizacin.
El marco RUP es definido por una familia de mtodo plug-ins que se basan en las necesidades nicas
del negocio, as como el contexto (complejidad tcnica y de gestin), las organizaciones son capaces
de crear sus propias configuraciones de mtodo y a la medida de procesos. RUP proporciona un
Fundacin arquitectnica y gran cantidad de material que puede construirse en una definicin de
proceso, por lo tanto, lo que permite la organizacin adoptando configurar y ampliar esa fundacin
como desee.
Flujos de trabajo de fase RUP
Cada fase en RUP tiene un flujo de trabajo, en el que se describe la secuencia en que las actividades
de todas las diversas disciplinas se pueden realizar para alcanzar los objetivos del hito fase
respectivos.
Fases RUP frente a las fases de la cascada
Las Fases RUP difieren de las fases SDLC de cascada tradicional. Para ayudar a las organizaciones a
adoptar el RUP. El hecho es que las fases en el RUP no equivalen a las fases en el ciclo de vida de
cascada. Para lograr esto se realiza a travs de mltiples disciplinas.

You might also like