6
 Facultad de ingeniería “Escuela profesional de ingeniería de sistemas e informática” ALUMNOS: VALVERDE URTECHO, IRVIN. CICLO: 2011 - I TEMA: “METODOLOGIA ICONIX” DOCENTE: HAYBERT ESCOBEDO NEYRA. CURSO: DESARROLLO Y APLICACIONES I

ICONIX

Embed Size (px)

Citation preview

Page 1: ICONIX

5/9/2018 ICONIX - slidepdf.com

http://slidepdf.com/reader/full/iconix-559ca214508d5 1/6

 

Facultad de ingeniería

“Escuela profesional de ingeniería de sistemas e informática”

ALUMNOS:

VALVERDE URTECHO, IRVIN.

CICLO:

2011 - I

TEMA:

“METODOLOGIA ICONIX”

DOCENTE:

HAYBERT ESCOBEDO NEYRA.

CURSO:

DESARROLLO Y APLICACIONES I

Page 2: ICONIX

5/9/2018 ICONIX - slidepdf.com

http://slidepdf.com/reader/full/iconix-559ca214508d5 2/6

 

ICONIX

A. Concepto

El proceso ICONIX es un proceso de modelado de objetos basado en

casos de uso. Toma ideas de otros modelos como el Proceso Unificadode Rational (RUP), Programación Extrema (XP), Desarrollo Ágil deSoftware, aunque presenta algunas diferencias: es más liviano que elRUP porque utiliza solo cuatro diagramas del UML y, a diferencia del XP yel desarrollo ágil, provee de suficiente documentación de requerimientosy de diseño.

B. Fases

1. Requerimientos

1.1.Obtener/Elaborar requerimientos funcionales: Consiste endefinir de lo que debe de hacer el sistema informático segúnlas necesidades de los usuarios de negocio.

1.2.Realizar el modelo del dominio: Consiste en definir y entender,lo necesario, las entidades de negocio y como estas serelacionan. Esto es para conocer el problema y evitarambigüedad en lo posible. Diagrama a utilizar: Diagrama declases .

1.3.Elaborar los requerimientos de comportamiento: Consiste endescribir como el sistema y los usuarios de negociointeractuarán. Se elaboran casos de uso que se apeguen a losrequerimientos funcionales y al modelo del dominio. Serecomienda hacer un prototipo de la interfaz de usuario.Diagrama a utilizar: Diagrama de casos de uso y susrespectivos escenarios.

1.4.Revisión de los requerimientos: Verificar que los casos de usose ajusten a las expectativas de los usuarios de negocio.

2. Análisis y diseño preliminar

2.1.Realizar Análisis de robustez: Consiste en elaborar undiagrama identificando los pasos en un caso de uso y las

Page 3: ICONIX

5/9/2018 ICONIX - slidepdf.com

http://slidepdf.com/reader/full/iconix-559ca214508d5 3/6

 

entidades, las acciones y las interfaces de usuarios e irdepurando los casos de uso a medida que se avanza.Diagrama a utilizar: Diagrama de colaboración/comunicación(simplificado).

2.2.Actualizar el modelo del dominio: A medida que se realiza elanálisis de robustez y la depuración de los casos de uso, seidentificarán nuevas entidades, se corregirán o eliminaránalgunas entidades y se identificarán atributos que tienen estasentidades. Diagrama a utilizar: Diagrama de clases.

2.3.Listar las funciones lógicas que tendrá el software: Consiste enidentificar y listar las funciones que se encuentran en los casosde uso.

2.4.Depurar los casos de uso: Reescribir los casos de uso que seelaboraron en la fase de requerimientos.

2.5.Revisión del diseño preliminar: Verificar que los diagramas derobustez, los casos de uso y el modelo de dominio coincidan.Esta revisión es el puente entre esta fase y la de DiseñoDetallado.

3. Diseño detallado

3.1.Elaborar diagramas de secuencia: Consiste en elaborar undiagrama de secuencia por cada caso de uso para mostrar endetalle cómo se implementará. El objetivo de elaborar estosdiagramas de secuencia es asignar las funciones respectivas acada clase. Diagrama a utilizar: Diagrama de secuencia.

3.2.Actualizar el modelo del dominio: Consiste en actualizar elmodelo del dominio, depurándolo y agregando las funcionesrespectivas a cada clase. De esta etapa se obtiene el modelo

estático que consiste en un diagrama de clases del sistema.Diagrama a utilizar: Diagrama de Clases.

3.3.Depurar el modelo estático: Consiste en afinar el diagrama declases del sistema.

Page 4: ICONIX

5/9/2018 ICONIX - slidepdf.com

http://slidepdf.com/reader/full/iconix-559ca214508d5 4/6

 

3.4.Revisión Crítica del diseño detallado: Asegurarse que eldiagrama de secuencia este bien elaborado y que el diagramade clases sea consistente con este.

4. Implementación

4.1.Codificación y pruebas: Escribir código y pruebas.4.2.Integración y escenario de pruebas: Realizar estas pruebas en

base a los escenarios descritos en los casos de uso.4.3.Revisión de codificación: Realizar una revisión del código

fuente.

El proceso de ICONIX tiene dos flujos de trabajo enfocados en las partesdinámicas y estáticas del sistema. Con dinámica queremos decir elcomportamiento que tendrá el sistema esto se refleja en el prototipo deinterfaz de usuario, casos de uso, diagramas de robustez, diagramas desecuencia; con estático queremos decir la estructura que tendrá elsistema esto se refleja en el modelo del dominio y hasta convertirse enel diagrama de clases del sistema. Estos flujos de trabajo se puedenobservar en la siguiente figura:

Page 5: ICONIX

5/9/2018 ICONIX - slidepdf.com

http://slidepdf.com/reader/full/iconix-559ca214508d5 5/6

 

C. Características de ICONIX

• Iterativo e incremental: varias interacciones ocurren entre el modelodel dominio y la identificación de los casos de uso. El modelo estático esincrementalmente refinado por los modelos dinámicos.

• Trazabilidad: cada paso está referenciado por algún requisito. Sedefine la trazabilidad como la capacidad de seguir una relación entre losdiferentes artefactos producidos

Page 6: ICONIX

5/9/2018 ICONIX - slidepdf.com

http://slidepdf.com/reader/full/iconix-559ca214508d5 6/6

 

• Dinámica del UML: la metodología ofrece un uso dinámico del UMLcomo los diagramas del caso de uso, diagramas de secuencia y decolaboración. Las tareas que se realizan en la metodología ICONIX son

D. Ventajas

• ICONIX es un modelo pequeño y firme que no desecha el análisis y eldiseño.• Usa un análisis de robustez que reduce la ambigüedad al describir loscasos.• Es usado en proyectos más ligeros que los usados en RUP, por lo quetiene un mayor campo de aplicabilidad.• Proporciona suficientes requisitos y documentación de diseño, pero sinparar el análisis.

• Es refinado y actualizado a lo largo del proyecto, por lo que siemprerefleja la actual comprensión del problema de espacio.

E. Desventajas

• No puede ser usado para proyectos grandes.• Necesita información rápida y puntual de los requisitos, el diseño y lasestimaciones.

• Se debe conocer los diagramas UML.• Gran parte de la información la podemos encontrar en inglés, lo cualrequiere establecer muy bien su comprensión.