Sistemas de Información II (IS445)  Primera Semana 

Introducción a la Metodología ICONIX MSc. Ing. Efraín Elías Porras Flores   Página 1 

CAPITULO I

INTRODUCCION A LA METODOLOGIA ICONIX

La metodología ICONIX se encuentra entre el proceso unificado (PU) y la

programación extrema (XP). ICONIX está conducido por casos de uso, igual

que el proceso unificado, pero sin la sobrecarga del PU. Es relativamente

pequeño y ligero, igual que XP, pero no descarta el análisis y diseño formal

como la XP. ICONIX usa racionalmente el lenguaje unificado de modelado

(Rumbaugh et al., 2005), haciendo referencia a la trazabilidad de los requisitos.

Las actividades principales de ICONIX son: análisis de requisitos, diseño

preliminar, diseño e implementación (Rosenberg, et al., 2005).

1.1 EL ENFOQUE ICONIX

Esta compuesto por los lineamientos siguientes:

a. Modelado de objetos conducido por casos de uso.

b. Se descompone en fronteras de datos.

c. Basado en escenarios que descomponen los casos de uso.

d. Enfoque iterativo e incremental.

e. Proporciona trazabilidad de requisitos.

f. Uso directo de UML.

1.2 RAZONES PARA USAR ICONIX EN UN PROYECTO DE SOFTWARE

La mayoría de negocios que existen son PYMES y, requieren software de

calidad (Caballero, 2007). Al afrontar un proyecto para desarrollar software, se

debe usar una metodología ágil y formal como ICONIX, en tiempos cortos, con

recursos financieros limitados y, equipos de desarrollo de 10 a 20 personas. Al

escribir los casos de uso inconsistentes, generamos ambigüedad, si esta no se

controla, los casos de uso, el diseño y, el código fuente está mal enfocado.

Esto, origina errores y sobre costos durante el desarrollo y mantenimiento del

software (Pressman, 2001), (Sommerville, 2005).

Sistemas de Información II (IS445)  Primera Semana 

Introducción a la Metodología ICONIX MSc. Ing. Efraín Elías Porras Flores   Página 2 

1.3 RESUMEN DE LA METODOLOGIA ICONIX

El proceso ICONIX se divide en una parte estática y otra dinámica, que

son iterativos, podemos hacer una iteración de todo el proceso para un par de

casos de uso, hasta codificar y hacer las pruebas. Por esto, el proceso ICONIX

es ideal para proyectos pequeños y medianos, en resumen la metodología

ICONIX es:

a. Primer paso.- Identificar el mundo real y los objetos de dominio del

negocio (modelo de dominio).

b. Segundo paso.- Definir los requisitos de comportamiento (casos de uso).

c. Tercer paso.- Realizar análisis de robustez para eliminar la ambigüedad

de los casos de uso y determinar los defectos del modelo de dominio

(diagrama de robustez).

d. Cuarto paso.- Asignar comportamiento a los objetos (diagrama de

secuencia).

e. Quinto paso.- Finalizar el modelo estático (diagrama de clases).

f. Sexto paso.- Escribir y generar el código (código fuente).

g. Séptimo paso.- Realizar pruebas de aceptación (prueba).

ANALISIS DE REQUISITOS

a. Requisitos funcionales.- Define lo que el software debe ser capaz de

hacer, la creación de requisitos funcionales debe ser realizada por el

usuario o cliente, analista y experto del negocio.

b. Modelo de dominio.- Debe comprender el ámbito del problema sin

ambigüedad.

c. Requisitos de comportamiento.- Define la forma en que el usuario y el

software interactúan. Escribir el primer proyecto de casos de uso,

comenzar con un prototipo GUI e identificar todos los casos de uso o

por lo menos, tener una primera lista de casos de uso, que cambiará a

medida que se explora los requisitos en mayor profundidad.

Etapa 1: Revisión de Requisitos

En esta etapa la descripción de los casos de uso debe coincidir con los

requisitos del cliente. Revisar los casos de uso por grupos pequeños, antes de

diseñarlos. Luego, en cada iteración, para un pequeño grupo de casos de uso,

Sistemas de Información II (IS445)  Primera Semana 

Introducción a la Metodología ICONIX MSc. Ing. Efraín Elías Porras Flores   Página 3 

hacer lo que describimos a continuación.

DISEÑO PRELIMINAR

a. Dibujar diagrama de robustez.- Es una "imagen del objeto" descripción

por pasos de un caso de uso, reescribir los casos de uso a medida que

avanza.

b. Actualizar modelo de dominio.- Mientras escribe los casos de uso y

dibuja el diagrama de robustez, descubrirá algunas clases “perdidas”,

corregir las ambigüedades y, añadir atributos a los objetos de dominio.

c. Nombrar controladores.- Nombre todas las funciones lógicas del

software, necesarios para que los casos de uso funcionen.

d. Escribir.- Reescribir el borrador de los casos de uso.

Etapa 2: Revisión del Diseño Preliminar

DISEÑO DETALLADO

a. Diagrama de secuencia.- Dibuje un diagrama de secuencia, uno para

cada caso de uso, diagrama que muestra en detalle cómo va a

implementarse el caso de uso. La función principal de un diagrama de

secuencia es asignar comportamiento a sus clases.

b. Actualizar modelo de dominio.- Al dibujar los diagramas de secuencia,

añadir operaciones a los objetos entidad, el modelo de dominio debe

convertirse en un modelo estático o diagrama de clases.

c. Depurar el modelo estático.- Quitar inconsistencias diagrama de clases.

Etapa 3: Revisión Crítica del Diseño

IMPLEMENTACION

a. Código y pruebas unitarias.- Escribir el código fuente y formular las

pruebas unitarias o, escriba las pruebas unitarias y luego el código.

b. Integración y pruebas de escenario.- Base las pruebas de integración

en los casos de uso, para probar los cursos básico y alterno.

c. Revisar código y actualizar el modelo.- prepararse para la siguiente

iteración del proceso ICONIX, con otro pequeño grupo de casos de uso.