![Referencias:
[1] L. Olivia et al., “Aplicación de la metodología semi-ágil ICONIX para el
desarrollo de software: implementación y publicación de un sitio WEB para una
empresa SPIN-OFF en el Sur de Sonora, México”.
[2] “Manual Introductorio de Iconix: 1-¿Qué es Iconix?”
[3] C. Rebeca, P. De San, y M. Oliva, “Metodología ICONIX”.
[4] B. Chica y E. Xavier, “CD-5411”.
[5] D. Rosenberg y M. Stephens, Use case driven object modeling with UML:
Theory and Practice. 2007.](https://image.slidesharecdn.com/iconix-200819173736/85/Metodologia-ICONIX-25-320.jpg)
Metodología ICONIX
- 2. ANÁLISIS Y DISEÑO DE SISTEMAS Jimmy Leonel Vicente Guayanay Jorge Gustavo Tandazo Cueva Jimmy José Jaramillo Narvaez Bryan Alberto Requenes Troya Edmundo José Pezantes Urrego Facultad de la Energía, las Industrias y los Recursos Naturales No Renovables Carrera de Ingeniería en Sistemas/Computación Julio, 2020 Loja, Ecuador
- 4. Historia Fue elaborado por Doug Rosenberg y Jacobson que ha dado soporte y conocimiento a la metodología ICONIX desde 1993.
- 5. Iconix ICONIX es una metodología pesada-ligera de desarrollo de software, unifica un conjunto de métodos de orientación a objetos con el objetivo de tener un control escrito sobre el ciclo de vida de un proyecto.
- 6. Características Principales Iterativo e Incremental ● Se organiza en series de mini-proyectos cortos Trazabilidad ● Capacidad de seguir una relación entre los diferentes artefactos de software producidos. Dinámica del UML ● Ofrece un uso dinámico del UML.
- 7. Fases de Iconix 1 Análisis de requisitos 2 Análisis y diseño prelim inar 3 Diseño 4 Im plem entación
- 8. Fases de Iconix 1 Análisis de requisitos ● Se realiza un levantamiento de todos los requisitos que en principio deberían ser parte del sistema ● Se debe capturar información sobre lo que les gusta y lo que les desagrada a los usuarios Se lo puede resolver a través de las siguientes técnicas: ● Modelo del dominio ● Prototipación rápida ● Modelo de Casos de Uso Pasos a seguir: 1. Identificar objetos del dominio 2. Prototipo rápido 3. Identificar caso de uso 4. Organizar casos de uso en grupos Meta: revisión de requerimientos
- 9. Fases de Iconix 1 Análisis de requisitos Requisitos de usuario Funcionales No Funcionales 1. Registrar usuario(DNI, NOMBRE EMPLEADO, APELLIDO EMPLEADO, DIRECCIÓN, TELÉFONO, CELULAR, CORREO, TÍTULO, CARGO, USUARIO, CONTRASEÑA) 2. Registrar proyectos(NOMBRE PROYECTO, CLIENTE, DESCRIPCIÓN, TIEMPO ESTIMADO, CANT FASES, FECHA_INICIAL, FECHA_FINAL, PRESUPUESTO) 3. Registrar fases de un proyecto(NOMBRE_BASE,DESCRIPCION,TIEMPO ESTIMADO, FEHCA_INICIO, FECHA_FINAL PRESUPUESTO) 4. Asignar un usuario a un proyecto(fase) 5. Registrar hora de ingreso y hora de salida del sistema por dia 1. Acceder mediante un usuario y clave 2. El administrador puede designar los usuarios a las diferentes fases 3. El administrador puede crear proyectos 4. El administrador puede registrar usuario
- 10. Fases de Iconix 1 Análisis de requisitos ● Modelo del dominio Abstracción de los objetos y las relaciones de agregación y generalización que existen entre ellos. Utiliza un diagrama de clases de alto nivel. Ejemplo:
- 11. Enfoques para desarrollar el modelo de dominio 1 Análisis de requisitos 10) Enfocar objetos del mundo real(problemas del dominio) 9) Relaciones entre objetos(herencias y agregaciones) 8) Limitar el esfuerzo para construir el modelo de dominio 7) Organizar clases 6) No confundir el modelo de dominio con el modelo de datos 5) No confundir el modelo de dominio con una tabla de base de datos 4) Usar el modelo de dominio como un glosario de términos 3) Diagramar el MD antes del DUC 2) Dont expect (Diagrama de clases sea el final de su diagrama de dominio) 1) No ubicar screem, GUI classe dentro del MD
- 12. Fases de Iconix 1 Análisis de requisitos ● Prototipación rápida Se intenta, en la medida de lo posible, presentar un prototipación rápida de las interfaces del sistema, diagramas de navegación, entre otros, para dar a los clientes una mayor comprensión del sistema propuesto.
- 13. Fases de Iconix 1 Análisis de requisitos ● Prototipación rápida
- 14. Fases de Iconix 1 Análisis de requisitos ● Modelo de Casos de Uso El modelo de caso de uso comprende los actores, el sistema y los propios casos de uso. Los casos de uso permiten a los usuarios estructurar y articular sus deseos
- 15. Enfoques para desarrollar el modelo de dominio 1 Análisis de requisitos 1. Seguir la regla de 2 párrafos 2. Organizar los UC en Diagrama 3. Escribir su UC en voz pasiva 4. Escribir el UC usando event/response flow 5. Use los GUI prototipos 6. Recuerde el UC ejecución de comportamiento 7. Escribir UC en el contexto del modelo del objeto 8. Escribir UC sustantivo/verbo/sustantivo 9. Referencias al modelo del dominio por el nombre 10. Referencia los boundary class por nombre
- 16. Fases de Iconix 2 Análisis y diseño preliminar Pasos a seguir: 1. Escribir descripciones de casos de uso ● curso principal y alterno 2. Análisis de robustez ● Identificar grupos de objetos que realizan escenario ● Actualizar diagramas de clases del dominio Meta: Revisión del diseño preliminar ❖ de usuario hacia el sistema ❖ de datos hacia el sistema
- 17. Fases de Iconix 2 Análisis y diseño preliminar ● Descripción de casos de Uso Se describen los casos de uso con un flujo principal de acciones y posibles flujos alternos
- 18. Fases de Iconix 2 Análisis y diseño preliminar
- 19. Fases de Iconix 2 Análisis y diseño preliminar ● Diagrama de Robustez Es un híbrido entre diagrama de clases y diagrama de actividades. Se realiza un diagrama de robustez, en donde se debe ilustrar las interacciones existentes entre los objetos participantes de un caso de uso. Componentes: ● Objetos fronterizos ● Objetos Controladores ● Objetos entidad
- 20. Diagrama de Robustez ● Diagrama de Robustez Componentes: ● Objetos fronterizos ● Objetos Controladores ● Objetos entidad Conexiones ● Boundary - Controller ● Entity - Controller ● Controller Controller
- 21. Fases de Iconix 3 Diseño Pasos a seguir: 1. Asignar comportamiento 2. Para cada caso de uso ● Identificar mensajes y métodos ● Dibujar diagramas de secuencias ● Actualizar clases 3. Terminar el modelo 4. Verficar el cumpliento de los requerimientos Meta: Revisión crítica del diseño
- 22. Fases de Iconix 3 Diseño ● Diagrama de secuencias ● Es el núcleo del modelo dinámico y muestra todos los cursos alternos que pueden tomar los casos de uso ● Especifica el comportamiento. La representación se concentra sobre la expresión de las interacciones ● Se componen de 4 elementos que son: el curso de acción, los objetos, los mensajes y los métodos
- 23. Pasos a seguir: 1. Escribir el código 2. Realizar pruebas Meta: Entrega del sistema 4 Implementación Fases de Iconix
- 24. Ventajas Desventajas ● Desarrollo incremental e iterativo y la relativa facilidad con que se puede utilizar en otras metodologías de desarrollo u otras técnicas ● Satisface la mayor parte de los requisitos del cliente ● Usa un análisis de robustez que reduce la ambigüedad al describir los casos. ● Es usado en proyectos más ligeros que los usados en RUP ● Proporciona suficientes requisitos y documentación de diseño, pero sin parar el análisis ● Es refinado y actualizado a lo largo del proyecto ● Es necesario tener información rápida y puntual de los requisitos, del diseño y de las estimaciones ● No puede ser usado para proyectos grandes ● Se debe de conocer los diagramas de UML ● Gran parte de la información la podemos encontrar en inglés, lo cual requiere establecer muy bien su comprensión Iconix
- 25. Referencias: [1] L. Olivia et al., “Aplicación de la metodología semi-ágil ICONIX para el desarrollo de software: implementación y publicación de un sitio WEB para una empresa SPIN-OFF en el Sur de Sonora, México”. [2] “Manual Introductorio de Iconix: 1-¿Qué es Iconix?” [3] C. Rebeca, P. De San, y M. Oliva, “Metodología ICONIX”. [4] B. Chica y E. Xavier, “CD-5411”. [5] D. Rosenberg y M. Stephens, Use case driven object modeling with UML: Theory and Practice. 2007.