Metodologia Iconix

METODOLOGIA ICONIX
1-Caracteristicas de Iconix
2- Fases del modelo Iconix
3- Ventajas y desventajas con Iconix
4-Ejemplos de Metodologia Iconix
METODOLOGIA AL DESARROLLO DE SOFTWARE
ING. FABIAN BAUTISTA
NAYELI ABIGAIL CABEZAS GUACHAMIN
0987936079
Nayeli.cabezas@intsuperior.edu.ec
05/01/2023
METODOLOGIA ICONIX
¿Qué es la metodología Iconix?

Iconix es una metodología pesada-ligera de Desarrollo del Software que se halla a
medio camino entre un RUP (Rational Unified Process) y un XP (eXtreme
Programming). Iconix deriva directamente del RUP y su fundamento es el hecho de que
un 80% de los casos pueden ser resueltos tansolo con un uso del 20% del UML, con lo
cual se simplifica muchísimo el proceso sin perder documentación al dejar solo aquello
que es necesario. Esto implica un uso dinámico del UML de tal forma que siempre se
pueden utilizar otros diagramas además de los ya estipulados si se cree conveniente.
Iconix se guía a través de casos de uso y sigue un ciclo de vida iterativo e incremental.
El objetivo es que a partir de los casos de uso se obtenga el sistema final.
CARACTERISTICAS:
Las tres características fundamentales de ICONIX son:
• Iterativo e incremental: varias iteraciones ocurren entre el desarrollo del modelo del
dominio y la identificación de los casos de uso. El modelo estático es incrementalmente
refinado por los modelos dinámicos.
• Trazabilidad: cada paso está referenciado por algún requisito. Se define trazabilidad
como la capacidad de seguir una relación entre los diferentes artefactos producidos.
• Dinámica del UML: La metodología ofrece un uso “dinámico del UML” como los
diagramas del caso de uso, diagramas de secuencia y de colaboración.
Las fases de Iconix

Iconix se estructura en cuatro fases. La primera de ellas es el análisis de requisitos,
seguida del análisis y diseño preliminar, a continuación viene el diseño y finaliza con su
implementación.
1. Análisis de Requisitos: En esta primera fase se realiza un Modelo de Dominio,
que no es más 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.
2. Análisis y Diseño 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. La ficha está formada por un nombre, que suele ser el del
caso de uso, posee una breve descripción (generalmente en vista usuario, es
decir, que hace de forma intuitiva, no como), una precondición que debe cumplir
antes de iniciarse, una postcondición 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.
3. Diseño: En esta fase
se proceden a realizar los diagramas de secuencia, los cuales derivan

directamente de las fichas de caso de uso. Obsérvese 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
diseño, tras refinar nuevamente el diagrama de clases, podremos verificarlo
directamente gracias a este factor de trazabilidad, y prepararnos para la siguiente
fase.
4. Implementación: 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 código tal y
como fue especificado en las fases anteriores y se planean las pruebas
basándonos en los requisitos iniciales, al nivel que fuese necesario. Aquí es
donde hacemos uso real de la trazabilidad y donde realmente ponemos en
práctica esa garantía de calidad que tanto hemos mencionado. Después de tener
un buen diseño, es cuestión de crear un buen software a partir de ese diseño, 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.
5. Final del proceso.

VENTAJAS Y DESVENTAJAS DE ICONIX
VENTAJAS:
 Los usuarios se hacen participantes más activos en los desarrollos del sistema.
Suelen mostrarse mas interesados en los prototipos de trabajo que en las
especificaciones de diseño.
 La definición de necesidades se simplifica por el hecho de que muchos usuarios
finales no comprenden o no son capaces de enumerar detalladamente sus
necesidades hasta que ven un prototipo.
 La probabilidad de que los usuarios aprueben un diseño y luego rechacen su
implantación se reducirá notablemente.
 Según se dice el diseño mediante prototipos reduce el tiempo de desarrollo,
aunque algunos cuestionan este ahorro.
 Los prototipos suelen pasar a las fases de análisis y diseño con demasiada
rapidez. Ello empuja al analista a pasar demasiado rápido a la codificación, sin
haber comprendido las necesidades y los problemas. Condición deseable en un
proceso ágil.

DESVENTAJAS:
Esta metodología es la definición de un proceso ágil para poder obtener la
especificación de requerimientos y poder modelar el sistema haciendo uso del Lenguaje
de Modelamiento Unificado (UML). La principal desventaja de esta metodología es que
necesita información rápida y puntual de los requisitos, del diseño y de las estimaciones,
además, es una metodología que no debe ser usada en proyectos de larga duración.
EJEMPLO:

Metodologia Iconix

Cargado por

Copyright:

Formatos disponibles

Metodologia Iconix

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Metodologia Iconix

Cargado por

Copyright:

Formatos disponibles

METODOLOGIA ICONIX

METODOLOGIA AL DESARROLLO DE SOFTWARE

ING. FABIAN BAUTISTA

NAYELI ABIGAIL CABEZAS GUACHAMIN

¿Qué es la metodología Iconix?

medio camino entre un RUP (Rational Unified Process) y un XP (eXtreme

Programming). Iconix deriva directamente del RUP y su fundamento es el hecho de que

pueden utilizar otros diagramas además de los ya estipulados si se cree conveniente.

El objetivo es que a partir de los casos de uso se obtenga el sistema final.

Las tres características fundamentales de ICONIX son:

dominio y la identificación de los casos de uso. El modelo estático es incrementalmente

refinado por los modelos dinámicos.

diagramas del caso de uso, diagramas de secuencia y de colaboración.

Las fases de Iconix

1. Análisis de Requisitos: En esta primera fase se realiza un Modelo de Dominio,

que no es más 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.

2. Análisis y Diseño Preliminar: A partir de cada caso de uso se obtienen sus

correspondientes fichas de caso de uso. Cabe destacar que estas fichas no

caso de uso, posee una breve descripción (generalmente en vista usuario, es

antes de iniciarse, una postcondición que debe cumplir al terminar si termina

correctamente y un flujo alternativo en caso de que haya cualquier problema.

3. Diseño: En esta fase

se proceden a realizar los diagramas de secuencia, los cuales derivan

diseño, tras refinar nuevamente el diagrama de clases, podremos verificarlo

directamente gracias a este factor de trazabilidad, y prepararnos para la siguiente

4. Implementación: 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 código tal y

como fue especificado en las fases anteriores y se planean las pruebas

basándonos en los requisitos iniciales, al nivel que fuese necesario. Aquí es

donde hacemos uso real de la trazabilidad y donde realmente ponemos en

un buen diseño, es cuestión de crear un buen software a partir de ese diseño, y

mediante los testeos y pruebas adecuados podemos garantizar que el sistema

5. Final del proceso.

Suelen mostrarse mas interesados en los prototipos de trabajo que en las

 La definición de necesidades se simplifica por el hecho de que muchos usuarios

finales no comprenden o no son capaces de enumerar detalladamente sus

necesidades hasta que ven un prototipo.

 La probabilidad de que los usuarios aprueben un diseño y luego rechacen su

implantación se reducirá notablemente.

 Según se dice el diseño mediante prototipos reduce el tiempo de desarrollo,

aunque algunos cuestionan este ahorro.

rapidez. Ello empuja al analista a pasar demasiado rápido a la codificación, sin

haber comprendido las necesidades y los problemas. Condición deseable en un

Esta metodología es la definición de un proceso ágil para poder obtener la

especificación de requerimientos y poder modelar el sistema haciendo uso del Lenguaje

de Modelamiento Unificado (UML). La principal desventaja de esta metodología es que

También podría gustarte