Iconix

3.3 ICONIX

Es un proceso simplificado que unifica un conjunto de métodos de orientación a objetos con el objetivo de abarcar todo el ciclo de vida de un proyecto, está adaptado a los patrones de UML, dirigido por casos de uso y es un proceso iterativo e incremental. ICONIX fue elaborado por Doug Rosenberg y Kendall Scott a partir de una síntesis del proceso unificado de los “tres amigos”, Booch, Rumbaugh y Jacobson y que han dado soporte y conocimiento a la metodología ICONIX. Además está adaptado a los patrones de UML (Unified Modeling Lenguaje), dirigido por casos de uso y es un proceso iterativo e incremental.

Figura Nº 1: Esquema conceptual del proceso ICONIX

Fuente: Notas del método ICONIX con ampliaciones y mejoras

El proceso ICONIX como metodología de desarrollo de software

El proceso ICONIX es un proceso de modelado de objetos basado en casos de uso. Toma ideas deotros modelos como el Proceso Unificado de Rational (RUP), Programación Extrema (XP),Desarrollo Ágil de Software, aunque presenta algunas diferencias: es más liviano que el RUPporque utiliza solo cuatro diagramas del UML y, a diferencia del XP y el desarrollo ágil, provee desuficiente documentación de requerimientos y de diseño.A continuación se detallan las cuatro fases que componen este proceso:

1.

R

equerimientos

1

.

1

.

Obtener/Elaborar requerimientos funcionales: Consiste en definir de lo que debe dehacer el sistema informático según las necesidades de los usuarios de negocio.

1

.2.

Realizar el modelo del dominio: Consiste en definir y entender, lo necesario, lasentidades de negocio y como estas se relacionan. Esto es para conocer el problema yevitar ambigüedad en lo posible. Diagrama a utilizar: Diagrama de clases

1

.3.

Elaborar los requerimientos de comportamiento: Consiste en describir como elsistema y los usuarios de negocio interactuarán. Se elaboran casos de uso que seapeguen a los requerimientos funcionales y al modelo del dominio. Se recomiendahacer un prototipo de la interfaz de usuario. Diagrama a utilizar: Diagrama de casosde uso y sus respectivos escenarios.

1

.4.

Revisión de los requerimientos: Verificar que los casos de uso se ajusten a lasexpectativas de los usuarios de negocio.

2

.

Análisis y diseño preliminar

2.

1

.

Realizar Análisis de robustez: Consiste en elaborar un diagrama identificando lospasos en un caso de uso y las entidades, las acciones y las interfaces de usuarios e irdepurando los casos de uso a medida que se avanza. Diagrama a utilizar: Diagramade colaboración/comunicación (simplificado).2.2.

Actualizar el modelo del dominio: A medida que se realiza el análisis de robustez y ladepuración de los casos de uso, se identificarán nuevas entidades, se corregirán oeliminarán algunas entidades y se identificarán atributos que tienen estas entidades.Diagrama a utilizar: Diagrama de clases.2.3.

Listar las funciones lógicas que tendrá el software: Consiste en identificar y listar lasfunciones que se encuentran en los casos de uso.2.4.

Depurar los casos de uso: Reescribir los casos de uso que se elaboraron en la fase derequerimientos.2.5.

Revisión del diseño preliminar: Verificar que los diagramas de robustez, los casos deuso y el modelo de dominio coincidan. Esta revisión es el puente entre esta fase y lade Diseño Detallado.

3

.

Diseño detallado

3.

1

.

Elaborar diagramas de secuencia: Consiste en elaborar un diagrama de secuencia porcada caso de uso para mostrar en

...