Metodologa para el desarrollo de Sistemas Las metodologas y estndares utilizados en un desarrollo de software nos proporcionan las guas para

poder conocer todo el camino a recorrer desde antes de empezar la implementacin, con lo cual se segura la calidad del producto final, as como tambin el cumplimiento en la entrega del mismo en un tiempo estipulado. Es de suma importancia elegir la metodologa adecuada, as como las herramientas de implementacin adecuadas, es por ello que la metodologa RUP basada en UML nos proporciona todas las bases para llevar al xito la elaboracin del software, para ello la utilizacin de la herramienta RRD es una de las elecciones ms acertadas debido a que se fundamenta en el RUP para el desarrollo rpido de aplicaciones. En la actualidad, la utilizacin de metodologas para el desarrollo de aplicaciones es casi imposible omitirla, debido a la gran necesidad de control de variables que conlleva el mismo desarrollo, y para la ordenada elaboracin de las aplicaciones, por lo tanto, seguir metodologas y estndares nos llevan a estar en competitividad en todo momento. Es de suma importancia conocer el modo como se interrelacionan metodologas con estndares y herramientas siguiendo un nico propsito, el cual consisteen la elaboracin de aplicaciones de manera eficiente, ordenada y con el menor nmero de defectos. La metodologa RUP nos proporciona disciplinas en las cuales se encuentran artefactos con lo cual se podr contar con guas para poder documentar e implement de una manera fcil y ar eficiente, todas las guas para un buen desarrollo, todo esto dentro de las respectivas fases con las cuales cuenta.

Metodologa RUP Introduccin Las siglas RUP en ingles significa Rational Unified Process (Proceso Unificado de Rational) es un producto del proceso de ingeniera de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organizacin del desarrollo. El RUP no es un sistema con pasos firmemente establecidos, sino que tratade un conjunto de metodologas adaptables al contexto y necesidades de cadaorganizacin, donde el software es organizado como una coleccin de unidadesatmicas llamados objetos, constituidos por datos y funciones, que interactanentre s. Su meta es asegurar la produccin del software de alta calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y tiempo establecidos.

Dimensiones del RUP El RUP tiene dos dimensiones: y El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida del proceso.
y

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. En la figura 1 se puede observar como vara el nfasis de cada disciplina en un cierto plazo en el tiempo, y durante cada una de las fases. Por ejemplo, en iteraciones tempranas, pasamos ms tiempo en requerimientos, y en las ltimas iteraciones pasamos ms tiempo en poner en prctica la realizacin del proyecto en s. Figura 1. Disciplinas, fases, iteraciones del RUP

Se puede hacer mencin de las tres caractersticas esenciales que definen al RUP: Caractersticas Esenciales
y

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.
y

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.

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. Todos los miembros del equipo comparten: 1 Base de conocimiento 1 Proceso 1 Vista de cmo desarrollar software 1 Lenguaje de modelamiento (UML)

FASES DEL RUP Figura 2. Fases del RUP

El ciclo de vida del software del RUP se descompone en cuatro fases secuenciales (figura 2). En cada extremo de una fase se realiza una evaluacin (actividad: Revisin del ciclo de vida de la finalizacin de fase) para determinar si los objetivos de la fase se han cumplido. Una evaluacin satisfactoria permite que el proyecto se mueva a la prxima fase. Planeamiento de las fases El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versin del producto, cada ciclo est compuesto por fases y cada una de estas fases est compuesta por un nmero de iteraciones, estas fases son: 1. Concepcin, Inicio o Estudio de oportunidad Durante la fase de inicio las iteraciones hacen poner mayor nfasis en actividades modelado del negocio y de requisitos.
y y

Define el mbito y objetivos del proyecto. Se define la funcionalidad y capacidades del producto.

En esta fase se realizan los siguientes pasos: - Un documento con la visin del proyecto. - El modelo de Casos de Uso con una lista de todos los Casos de Uso y losactores 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 planificacin financiera. - Un estudio inicial de riesgos. - Un plan del proyecto que muestre las fases y las iteraciones. 2. Elaboracin En esta fase las iteraciones se orientan al desarrollo de la arquitectura, que incluye los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), anlisis, diseo y una parte de implementacin orientado a la arquitectura.
y y y

Tanto la funcionalidad como el dominio del problema se estudian en Profundidad. Se define una arquitectura bsica. Se planifica el proyecto considerando recursos disponibles.

En esta fase se realizan las siguientes subfases: - Un modelo de Casos de Uso con todos los actores identificados y la mayor parte de las descripciones de Casos de Uso. - Requerimientos adicionales: no funcionales o pseudo-requerimientos. - Descripcin de la arquitectura del software. - Prototipo ejecutable de arquitectura. - Una lista revisada de riesgos. - Plan del proyecto, incluyendo iteraciones y criterios de evaluacin para cada iteracin. - Manual preliminar de usuario. 3. Construccin Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y dems. El resultado final es un sistema ejecutable.
y y y y y

El producto se desarrolla a travs de iteraciones donde cada iteracinInvolucra tareas de anlisis, diseo e implementacin. Las fases de estudio y anlisis slo dieron una arquitectura bsica queaqu es refinada de manera incremental conforme se construye (SePermiten cambios en la estructura) Gran parte del trabajo es programacin y pruebas. Se documenta tanto el sistema construido como el manejo del mismo. Esta fase proporciona un producto construido junto con laDocumentacin.

Para ello se realizarn las siguientes subfases: - El producto de software integrado sobre la plataforma adecuada. - Los manuales de usuario. - Una descripcin de la versin actual. - 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. 4. Transicin 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.
y

y y

Se libera el producto y se entrega al usuario para un uso real Se incluyen tareas de marketing, empaquetado atractivo, instalacin, configuracin, entrenamiento, soporte, mantenimiento, etc. Los manuales de usuario se completan y refinan con la informacin Anterior. Estas tareas se realizan tambin en iteraciones.

DISCIPLINAS Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia de pasos para la culminacin de cada disciplina, estas disciplinas se dividen en dos grupos: las primarias y las de apoyo. Las primarias son las necesarias para la realizacin de un proyecto de software, aunque para proyectos no muy grandes se pueden omitir algunas; entre ellas se tienen: Modelado del Negocio, Requerimientos, Anlisis y Diseo, Implementacin, Pruebas, Despliegue. Las de apoyo son las que como su nombre lo indica sirven de apoyo a las primarias y especifican otras caractersticas en la realizacin de un proyecto de software; entre estas se tienen: Entorno, Gestin del Proyecto, Gestin de Configuracin y Cambios. A continuacin se describe rpidamente cada una de estas disciplinas. 1) Modelado del negocio: Esta disciplina tiene como objetivos comprender la estructura y la dinmica de la organizacin, 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, adems utilizan los Diagramas de Actividad y de Clases. 2) Requerimientos Esta disciplina tiene como objetivos establecer lo que el sistema debe hacer (Especificar Requisitos), definir los lmites del sistema, y una interfaz de usuario, realizar una estimacin del costo y tiempo de desarrollo. Utiliza el Modelo de CU para modelar el Sistema que comprenden los CU, Actores y Relaciones, adems utiliza los diagramas de Estados de cada CU y las especificaciones suplementarias. 3) Anlisis y diseo Esta disciplina define la arquitectura del sistema y tiene como objetivos trasladar requisitos en especificaciones de implementacin, al decir anlisis se refiere a transformar CU en clases, y al decir diseo se refiere a refinar el anlisis para poder implementar los diagramas de clases de anlisis de cada CU, los diagramas de colaboracin de de cada CU, el de clases de diseo de cada CU, el de secuencia de diseo de CU, el de estados de las clases, el modelo de despliegue de la arquitectura. 4) Implementacin Esta disciplina tiene como objetivos implementar las clases de diseo 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 Implementacin, conjuntamente los Diagramas de Componentes para comprender cmo se organizan los Componentes y dependen unos de otros. 5) Pruebas Esta disciplina tiene como objetivos verificar la integracin de los componentes (prueba de integracin), verificar que todos los requisitos han sido implementados (pruebas del sistema), asegurar que los defectos detectados han sido resueltos antes de la distribucin.

6) Despliegue Esta disciplina tiene como objetivos asegurar que el producto est preparado para el cliente, proceder a su entrega y recepcin 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 ensear al usuario. 7) Gestin y configuracin de cambios Es esencial para controlar el nmero 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 haba arreglado etc., y aseguran que los resultados de los artefactos no entren en conflicto con algunos de los siguientes tipos de problemas:
y y y

Actualizacin simultnea: Es la actualizacin de algo elaborado con anterioridad, sin saber que alguien ms lo est actualizando. Notificacin limitada: Al realizar alguna modificacin, no se deja informacin sobre lo que se hizo, por lo tanto no se sabe quin, como, ycuando se hizo. Versiones mltiples: No saber con exactitud, cual es la ltima versin, yal final no se tiene un orden sobre que modificaciones se han realizadoa las diversas versiones.

8) Gestin del proyecto Su objetivo es equilibrar los objetivos competitivos, administrar el riesgo, y superar restricciones para entregar un producto que satisface las necesidades de ambos clientes con xito (los que pagan el dinero) y los usuarios. Con la Gestin del Proyecto se logra una mejora en el manejo de una entrega exitoso de software. En resumen su propsito consiste en proveer pautas para:
y y y

Administrar proyectos de software intensivos. Planear, dirigir personal, ejecutar acciones y supervisar proyectos. Administrar el riesgo.

Sin embargo, esta disciplina no intenta cubrir todos los aspectos de direccin del proyecto. Por ejemplo, no cubre problemas como:
y y y

Administracin de personal: contratando, entrenando, enseando. Administracin del presupuesto: definiendo, asignando. Administracin de los contratos con proveedores y clientes

9) 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 propsito es proveer a la organizacin que desarrollar el software, un ambiente en el cual basarse, el cual provee procesos y herramientas para poder desarrollar el software.

El

Ya c ce varias partes de RUP nos concentrare os ahora en los ele entos que lo componen, entre estos se tienen: Flujos de rabajo, Detalle de los Flujos de rabajo Actores, Actividades y Arte actos En la figura se muestran msclaramente como se representan grficamente cada uno de estos elementos y la interrelacin entre ellos Se puede observar que el Flujo de rabajo de requerimientos conlleva varios pasos, cada uno de estos pasos tiene asociado uno o varios actores, los cua a su ve son los encargados de la ejecucin de les varias actividades, las cuales a la ve estn definidas en artefactos o guas para su realizacin.

Eleme t eq erimie t

q e

f rm

el

Anli i del Pr blem

# $ "

!

 

  

'

 

ntos

&

%%

"

 Actores o roles Son los personajes encargados de la realizacin de las actividades definidas dentro de los flujos de trabajo de cada una de las disciplinas del RUP, estos actores se dividen en varias categoras: Analistas, desarrolladores, Probadores, Encargados, Otros actores.  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 guas. Un artefacto puede ser un documento, un modelo o un elemento de modelo.
y

Conjuntos 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 realizacin de las mismas, a continuacin se definen cada una de estas categoras o grupos de artefactos dentro de las disciplinas del RUP: a) Modelado del negocio Los artefactos del modelado del negocio capturan y presentan el context del o negocio del sistema. Los artefactos del modelado del negocio sirven como entrada y como referencia para los requisitos del sistema. b) Requerimientos Los artefactos de requerimientos del sistema capturan y presentan lainformacin usada en definir las capacidades requeridas del sistema. c) Anlisis y diseo del sistema Los artefactos para el anlisis y del diseo capturan y presenta la informacin relacionada con la solucin a los problemas se presentaron en los requisitos fijados. d) Implementacin Los artefactos para la implementacin capturan y presentan la realizacin de la solucin presentada en el anlisis y diseo del sistema. e) Pruebas Los artefactos desarrollados como productos de las actividades deprueba y de la evaluacin son agrupadas por el actor responsable, con el cual se lleva un conjunto de documentos de informacin sobre las pruebas realizadas y las metodologas de pruebas aplicadas. f) Despliegue Los artefactos del despliegue capturan y presentan la informacinrelacionada con la transitividad del sistema, presentada en la implementacin en el ambiente de la produccin. g) Administracin del proyecto El conjunto de artefactos de la administracin del proyecto capturan los artefactos asociados con el proyecto, el planeamiento y a la ejecucin del proceso.

h) Administracin de cambios y configuracin Los artefactos de la configuracin y administracin del cambio capturan y presentan la informacin relacionada con la disciplina de configuracin y administracin del cambio. i) Entorno o ambiente El conjunto de artefactos del ambiente presentan los artefactos que se utilizan como direccin a travs del desarrollo del sistema para asegurar la consistencia de todos los artefactos producidos.

CONCLUSIN RUP realiza un levantamiento exhaustivo de requerimientos. Busca detectar defectos en las fases iniciales. Intenta reducir al nmero de cambios tanto como sea posible. Realiza el Anlisis y diseo, tan completo como sea posible. Diseo genrico, intenta anticiparse a futuras necesidades. Las necesidades de clientes no son fciles de discernir. Existe un contrato prefijado con los clientes. Cada caso de uso proporciona uno o ms escenarios que indicancmo debera interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo especfico.