METODOLOGIA ICONIX

Es una metodologa de desarrollo de software, basada en la complejidad de

anlisis de la metodologa RUP (Rational Unified Processes) y la practicidad
para desarrollar de la metodologa XP (Extreme Programming) .
Unifica un conjunto de mtodos de orientacin a objetos, con el objetivo de
abarcar todo el ciclo de vida de un proyecto. Se considera un enfoque
minimalista, ya que comprende el conjunto mnimo de medidas que son
necesarias para el proyecto de desarrollo. Es una metodologa de desarrollo de
software basada en UML.
Cuenta con una secuencia de pasos que se deben seguir y determina
claramente las actividades a desarrollar en cada etapa del ciclo de vida del
proyecto que la utilice.

Caractersticas
Iterativo e Incremental: Ocurren varias iteraciones entre el desarrollo del
modelo del dominio y los casos de uso. El modelo esttico es incremental
Trazabilidad: es la capacidad de seguir una relacin entre los diferentes
artefactos producidos, por lo que cada paso esta referenciado por algn
requisito.
Dinmica del UML: ofrece un uso dinmico del UML, como los diagramas
de caso de uso, diagramas de secuencia y de colaboracin.

ETAPA 1: REQUISITOS

1. Requisitos funcionales: Definir lo que el sistema debe ser capaz de hacer.
Dependiendo de la forma en que el proyecto est organizado, ya sea que se
participe en la creacin de los requisitos funcionales, o los requisitos sean
proporcionados por el cliente o un equipo de anlisis de negocios.
2. Modelo del Dominio: Entender el espacio del problema en trminos
inequvocos.
3. Comportamiento: Define la forma en que el usuario y el sistema interactan.
Se recomienda empezar con un prototipo de interfaz grfica e identificar todos
los casos de uso que van ser aplicados, o al menos llegar a un primer paso con
la lista de casos de uso, los cuales se espera cambiar dependiendo de
requisitos que aparezcan posteriormente.
4. HITO ETAPA 1: Revisin de Requisitos: Asegurarse de que el texto del caso
coincida con las expectativas del cliente. Tener en cuenta que se puede revisar
los casos de uso en pequeos lotes, justo antes de disearlos. Luego, en cada
iteracin (es decir, por cada lote de casos de uso), hacer lo que sigue.




ETAPA 2: ANLISIS Y DISEO PRELIMINAR

1. Anlisis de Robustez: Dibujar un diagrama de robustez, reescribiendo la
descripcin de los casos de uso.
2. Actualizar el modelo de dominio mientras que se escriben los casos de uso y
se dibuja el diagrama de robustez. Aqu se descubrirn las clases faltantes, se
corregirn ambigedades, y se agregarn atributos a los objetos de dominio.
3. Nombrar de todas las funciones lgicas del software (controladores)
necesarios para hacer que el caso de uso funcione.
4. Reescribir el primer proyecto de casos de uso.
5. HITO ETAPA 2: Revisin del Diseo preliminar (PDR): Una vez que se han
determinado los casos de uso el texto puede ser escrito para que describa la
forma en que el usuario y sistema deben interactuar. Un anlisis de robustez se
realiza para encontrar posibles errores en el texto de los casos de uso, y el
modelo de dominio se actualizar como consecuencia. La utilizacin de la
descripcin los casos de uso es importante para determinar cmo los usuarios
interactan con el sistema, tambin proporcionan al desarrollador algo que
mostrar al cliente y ayudan a verificar que los resultados de los anlisis de
requisitos sean correctos.

TAPA 3: DISEO DETALLADO

1. Diagramas de Secuencia: Dibujar un diagrama de secuencia para mostrar en
detalle cmo se va a aplicar el caso de uso. La funcin principal de los
diagramas de secuencia es asignar el comportamiento a sus clases.
2. Actualizar el modelo de dominio mientras se estn dibujando los diagramas
de secuencia, y aadir operaciones a los objetos de dominio. En esta etapa, los
objetos de dominio son realmente clases de dominio, o entidades, y el modelo
de dominio debe convertirse rpidamente en un modelo esttico, o diagrama de
clase.
3. Limpiar el modelo esttico.
4. HITO ETAPA 3: Revisin crtica del diseo: Durante esta fase del proceso de
ICONIX el modelo de dominio y la descripcin de los caso de uso de la Etapa 2
se utilizan para disear el sistema que se est construyendo. Un diagrama de
clases es producido a partir del modelo de dominio y la descripcin de los
casos de uso es usada para hacer diagramas de secuencia..








ETAPA 4: IMPLEMENTACIN

1. Codificacin / Pruebas de unidad: Escribir el cdigo y las pruebas de unidad.
2. Integracin y pruebas de hiptesis: Basar las pruebas de integracin en los
casos de uso, de modo que se pruebe tanto el flujo bsico como los flujos
suplentes.
3. HITO ETAPA 4: Revisin de Cdigo: Realizar una Revisin de Cdigo y
Actualizacin del Modelo para preparar la prxima iteracin del desarrollo del
trabajo.

Ventajas

ICONIX es un modelo pequeo y firme que no desecha el anlisis y el diseo.
Usa un anlisis de robustez que reduce la ambigedad al describir los casos.
Es usado en proyectos ms ligeros que los usados en RUP, por lo que tiene
un mayor campo de aplicabilidad.
Proporciona suficientes requisitos y documentacin de diseo, pero sin parar
el anlisis.
Es refinado y actualizado a lo largo del proyecto, por lo que siempre refleja la
actual comprensin del problema de espacio.

Desventajas

No puede ser usado para proyectos grandes.
Necesita informacin rpida y puntual de los requisitos, el diseo y las
estimaciones.
Se debe conocer los diagramas UML.
Gran parte de la informacin la podemos encontrar en ingls, lo cual requiere
establecer muy bien su comprensin.















METODOLOGIA RUP

El Proceso Racional Unificado 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 un conjunto
de metodologas adaptables al contexto y necesidades de cada organizacin.
Originalmente se dise un proceso genrico y de dominio pblico, el Proceso
Unificado, y una especificacin ms detallada, el Rational Unified Process, que
se vendiera como producto independiente.
Caracteristicas
Forma disciplinada de asignar tareas y responsabilidades (quin hace
qu, cundo y cmo)
Pretende implementar las mejores prcticas en Ingeniera de Software
Desarrollo iterativo
Administracin de requisitos
Uso de arquitectura basada en componentes
Control de cambios
Modelado visual del software
Verificacin 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 cdigo fuente, etc.) y roles (papel que
desempea una persona en un determinado momento, una persona puede
desempear distintos roles a lo largo del proceso).
En RUP se han agrupado las actividades en grupos lgicos definindose 9
flujos de trabajo principales. Los 6 primeros son conocidos como flujos de
ingeniera y los tres ltimos como de apoyo.


Flujo
s de
traba
jo:


Mode
lamie
nto
del
nego
cio:
Describe los procesos de negocio, identificando quines participan y las
actividades que requieren automatizacin.
Requerimientos: Define qu es lo que el sistema debe hacer, para lo cual se
identifican las funcionalidades requeridas y las restricciones que se imponen.
Anlisis y diseo: Describe cmo el sistema ser realizado a partir de la
funcionalidad prevista y las restricciones impuestas (requerimientos), por lo que
indica con precisin lo que se debe programar.
Implementacin: Define cmo se organizan las clases y objetos en
componentes, cules nodos se utilizarn y la ubicacin en ellos de los
componentes y la estructura de capas de la aplicacin.
Prueba (Testeo): Busca los defectos a los largo del ciclo de vida.
Instalacin: Produce relase del producto y realiza actividades (empaque,
instalacin, asistencia a usuarios, etc.) para entregar el software a los usuarios
finales.
Administracin del proyecto: Involucra actividades con las que se busca
producir un producto que satisfaga las necesidades de los clientes.
Administracin de configuracin y cambios: Describe cmo controlar los
elementos producidos por todos los integrantes del equipo de proyecto en
cuanto a: utilizacin/actualizacin concurrente de elementos, control de
versiones, etc.
Ambiente: Contiene actividades que describen los procesos y herramientas
que soportarn el equipo de trabajo del proyecto; as como el procedimiento
para implementar el proceso en una organizacin.

Fases de la metodologa RUP

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias
iteraciones en nmero variable segn el proyecto y en las que se hace un
mayor o menor hincapi en las distintas actividades.

En la fase de elaboracin, las iteraciones se orientan al desarrollo de la
baseline de la arquitectura, abarcan ms los flujos de trabajo de requisitos,
modelo de negocios (refinamiento), anlisis, diseo y una parte de
implementacin orientado a la baseline de la arquitectura.
En la fase de construccin, se lleva a cabo la construccin del producto por
medio de una serie de iteraciones.
Para cada iteracin se seleccionan algunos Casos de Uso, se refinan su
anlisis y diseo y se procede a su implementacin y pruebas. Se realiza una
pequea cascada para cada ciclo. Se realizan iteraciones hasta que se termine
la implementacin de la nueva versin del producto.
En la fase de transicin, 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 vara.

RUP en cada una de sus fases (pertenecientes a la estructura dinmica) realiza
una serie de artefactos que sirven para comprender mejor tanto el anlisis
como el diseo del sistema (entre otros). Estos artefactos (entre otros) son los
siguientes:

Inicio:
Documento Visin
Especificacin de Requisitos
Elaboracin:
Diagramas de caso de uso
Construccin:

Documento Arquitectura que trabaja con las siguientes vistas:
Vista Lgica
o Diagrama de clases
o Modelo E-R (Si el sistema as lo requiere)
Vista de Implementacin
o Diagrama de Secuencia
o Diagrama de estados
o Diagrama de Colaboracin
Vista Conceptual
o Modelo de dominio
Vista fsica
o Mapa de comportamiento a nivel de hardware.


Desventajas del Modelo RUP
-Mtodo pesado
-Por el grado de complejidad puede ser no muy adecuado.
-En proyectos pequeos, es posible que no se puedan cubrir los costos de
dedicacin del equipo de profesionales necesarios.