INSTITUTO TECNOLOGICO SUPERIOR

SAN GABRIEL

TEMA: METODOLIGIA ICONIX

AUTOR: CESAR CAIZA

RIOBAMBA-ECUADOR
METODOLOGA ICONIX

Qu es ICONIX.
Es un proceso simplificado en comparacin con otros ms
tradicionales, que unifica un conjunto de mtodos de
orientacin a objetos con el objetivo de abarcar todo el ciclo
de vida de un proyecto.
Es una metodologa pesada-ligera de Desarrollo del Software
que se halla entre RUP (Rational Unified Process) y XP
(eXtreme Programming), unifica un conjunto de mtodos de
orientacin a objetos con el objetivo de tener un control
estricto sobre todo el ciclo de vida del producto a realizar.
Fue elaborado por Doug Rosenberg y Kendall Scott a partir de
una sntesis del proceso unificado de los tres amigos Booch,
Rumbaugh y Jacobson y que ha dado soporte y conocimiento
a la metodologa ICONIX desde 1993. Presenta claramente las
actividades de cada fase y exhibe una secuencia de pasos que
deben ser seguidos.
Fue elaborado por Doug Rosenberg, y Kendall Scott a partir de
una sntesis del proceso unificado de los 3 amigos Booch,
Rumbaugh y Jacobson. Es una metodologa de desarrollo de
software basada en UML.

Caractersticas Principales
Cuenta con tres caractersticas fundamentales:

Iterativo e Incremental: durante el desarrollo del modelo

del dominio y la definicin de los casos de uso se producen
varias iteraciones. El ciclo de vida incremental consiste en
desarrollar por partes el producto de manera que puedas
integrarlas funcionalmente. Ciclo de vida Iterativo, en cada
ciclo de iteracin se revisa y mejora el producto.
El desarrollo se organiza en series de mini-proyectos cortos,
llamados iteraciones.
Trazabilidad: Cada paso que se realiza est definido por un
requisito, se define la trazabilidad como la capacidad de
seguir una relacin entre los diferentes artefactos de software
producidos.

Dinmica del UML: Ofrece un uso dinmico del UML porque

utiliza algunos diagramas UML, sin exigir la utilizacin de
todos, como en el caso de RUP (Rational Unified Process).

LAS FASES
ICONIX se estructura en cuatro fases. La primera de ellas es el
anlisis de requisitos, seguida del anlisis y diseo preliminar,
a continuacin viene el diseo y finaliza con su
implementacin.
Previamente a esto, sin embargo, deberemos realizar un
pequeo storyboard de la interfaz grfica, con dibujos de las
pantallas principales del sistema a partir de las reuniones con
el cliente.

1) Anlisis de Requisitos:
En esta primera fase se realiza un Modelo de Dominio, que no
es ms que un Diagrama de Clases extremadamente
simplificado. Este modelo contiene nicamente aquellos
objetos de la vida real cuyo comportamiento o datos deban
ser almacenados en el sistema.
Proceso de Desarrollo de Software A partir de este pequeo
modelo, se realiza un pequeo prototipo basndose en
la storyboard de la interfaz grfica obtenida previamente, el
cual se mostrar al cliente y se refinar en sucesivas
reuniones. Normalmente este prototipo suele converger en
dos o tres iteraciones.
Una vez el prototipo ya es final y se han obtenido todos los
requisitos del sistema por parte del cliente, se procede a
realizar los casos de uso. Estos diagramas de casos de uso se
agrupan en diagramas de paquetes (es decir, utilizan
referencias entre diagramas de casos de uso para simplificar
su lectura) y se asocia cada requisito a un caso de uso para
obtener la ya mencionada anteriormente trazabilidad.
2) Anlisis y Diseo Preliminar:
A partir de cada caso de uso se obtienen sus correspondientes
fichas de caso de uso. Cabe destacar que estas fichas no
pertenecen al UML. He aqu un ejemplo de ficha para que se
entienda mejor:

La ficha est formada por un nombre, que suele ser el del

caso de uso, posee una breve descripcin (generalmente en
vista usuario, es decir, que hace de forma intuitiva, no como),
una precondicin que debe cumplir antes de iniciarse, una pos
condicin que debe cumplir al terminar si termina
correctamente, un flujo normal que sigue el sistema en caso
de que todo vaya correctamente y un flujo alternativo en caso
de que haya cualquier problema. El resto de campos son
opcionales.
Despus ser necesario realizar lo que se conoce como
Diagrama de Robustez, el cual pertenece al proceso ICONIX y
tampoco forma parte del UML. A continuacin describiremos
como se realiza un diagrama de este tipo.

Los elementos de un diagrama de robustez son los Objetos

Frontera, los Objetos Entidad y los Objetos Controlador. Los
dos primeros se relacionan con sustantivos y el ltimo con
verbos.
Cabe destacar el hecho de que esto funciona como una frase.
Los sustantivos se relacionan a travs de verbos. Por ejemplo:
ndice, muestra enlace, libro.

Los Sustantivos (Objetos) Verbo (Accin)

Contorno Del Objeto Objeto De Entidad Controlador

As pues, se establece el siguiente flujo:

Actor contorno del objeto Controlador

Objeto De Entidad
Hay una excepcin, y es que los objetos de tipo Controlador
pueden comunicarse entre ellos.
A continuacin se muestra un diagrama de robustez a modo
de ejemplo:

El objetivo del diagrama de robustez es aadir nuevas

relaciones a los diagramas de clase, de forma que ya
tendremos un esqueleto aceptable de la arquitectura y del
diseo a partir del cual podremos proseguir nuestro proceso.
Con esto y las fichas, refinamos el diagrama de clases tanto
como sea necesario y obtenemos una nueva versin
preparada para la siguiente fase.
3) Diseo:
En esta fase se proceden a realizar los diagramas de
secuencia, los cuales derivan directamente de las fichas de
caso de uso. Obsrvese como, los diagramas de secuencia se
relacionan con fichas de caso de uso que se relacionan con
casos de uso que se relacionan con requisitos. Esto implica
que una vez finalizado el diseo, tras refinar nuevamente el
diagrama de clases, podremos verificarlo directamente
gracias a este factor de trazabilidad, y prepararnos para la
siguiente fase.
En caso de que no estemos satisfechos con el resultado, ser
necesario repasar todo el proceso hasta que ste sea correcto.
Es vital que los requisitos se satisfagan correctamente para el
xito del proyecto.
4) Implementacin:
De cara a poder distribuir el software correctamente, puede
ser adecuado realizar un diagrama de componentes en
algunos casos, pero no siempre es necesario. En cualquier
caso, aqu es donde se escribe el cdigo tal y como fue
especificado en las fases anteriores y se planean las pruebas
basndonos en los requisitos iniciales, al nivel que fuese
necesario.
Aqu es donde hacemos uso real de la trazabilidad y donde
realmente ponemos en prctica esa garanta de calidad que
tanto hemos mencionado. Despus de tener un buen diseo,
es cuestin de crear un buen software a partir de ese diseo,
y mediante los testeos y pruebas adecuados podemos
garantizar que el sistema final cumple con los requisitos
iniciales y por tanto proceder a su entrega.
Revisin crtica del diseo/Diseo
En esta fase se registran todos los elementos que forman
parte de nuestro sistema.
Diagramas de Secuencia: muestra los mtodos que
llevaran las clases de nuestro sistema. Muestra todos los
cursos alternos que pueden tomar todos nuestros casos de
uso. Se debe terminar el modelo esttico, aadiendo los
detalles del diseo en el diagrama de clases y verificar si el
diseo satisface todos los requisitos identificados.
Implementacin
Despus de tener el diseo se creara el software; que
posteriormente se entregara. Se debe utilizar el diagrama de
componentes si fuera necesario para apoyar el desarrollo, es
decir mostrar una distribucin fsica de los elementos que
componen la estructura interna del sistema. As como escribir
y generar el cdigo.

Ejemplo de la metodologa ICONIX

Empresa: Softdem, Desarrollo Bajo Demanda.

Cmo se trabaja? SOFTDEM utiliza un modelo de trabajo

basado en procesos, lo cual permite una mayor velocidad en
el desarrollo del proyecto, con la seguridad y solidez
metodolgica que se requiere.

Anlisis de Requisitos
Identificar objetos del dominio y relaciones de agregacin y
generalizacin
Identificar casos de uso
Organizar casos de uso en grupos (paquetes)
Asignar requerimientos no funcionales a casos de uso y
objetos del dominio
Revisin de requerimientos

Diseo
Diseo de usuarios y datos hacia sistema.
Detalle a partir de modelos de alto nivel.
Para cada caso de uso.
Identifica mensajes y mtodos.
Dibujar diagramas de secuencia.
Actualizar clases.
Terminar modelo esttico
Verificar cumplimiento de requerimientos

Anlisis y diseo preliminar

Descripcin de Casos de uso
Anlisis de robustez
Identificar grupos de objetos que realizan escenario
Actualizar diagramas de clases del dominio
Diagramas de clases

Implementacin y pruebas
Producir diagramas necesarios
Despliegue
Componentes
Escritura de cdigo
Pruebas de sistema y aceptacin basadas en casos de uso

Conclusin.
Se entendi ICONIX como un mtodo que utiliza un modelo
de trabajo basado en varios procesos, lo cual permite una
mayor y mejor velocidad en el desarrollo de un ejercicio, con
la seguridad y solidez que permite utilizarlo de manera
correcta.
ICONIX permite tener ejercicio de calidad, en un tiempo corto
que permite a los usuarios estar al pendiente y tener ms
conocimientos acerca del proyecto, esto para que el proyecto
se valla generando tal y como el cliente lo necesita, este
mtodo no se utiliza en proyectos que requieran mucho
tiempo de elaboracin.
BIBLIOGRAFIA
http://metodologiaiconix.blogspot.com/
http://ingsoftware072301.obolog.es/metodologia-iconix-
2011212
http://iconixprocess.files.wordpress.com/2007/01/showbookdetails-
robustness.png
http://www.portalhuarpe.com.ar/Seminario09/archivos/MetodologiaICONI
X.pdf
http://www.portalhuarpe.com.ar/Seminario09/archivos/UsodeICONIX.pdf
http://metodologiaiconix.blogspot.com/
Ventajas de ICONIX.
Proceso gil para obtener un sistema informtico.
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.
Dedicada a la construccin de sistemas de gestin de
pequea y mediana complejidad con la participacin de los
usuarios finales.

Desventajas de ICONIX.
Necesita informacin rpida y puntual de los requisitos, el
diseo y las estimaciones.
Necesita informacin rpida y puntual de los requisitos, el
diseo y las estimaciones.
Gran parte de la informacin la podemos encontrar en ingls,
lo cual requiere establecer muy bien su comprensin.