Diferencia entre revisiones de «ICONIX»

(Página creada con '{{ Definición |Nombre= ICONIX |imagen= Iconix.jpg |concepto= metodología pesada-ligera de Desarrollo del Software. }} '''ICONIX:''' es una metodología pesada-ligera de De...')
(Etiqueta: nuestro-nuestra)
 
(Etiquetas: nuestro-nuestra, Edición visual)
 
Línea 1: Línea 1:
{{
+
{{Definición
Definición
 
 
|Nombre= ICONIX
 
|Nombre= ICONIX
 
|imagen= Iconix.jpg
 
|imagen= Iconix.jpg
Línea 8: Línea 7:
 
'''ICONIX:''' es una metodología pesada-ligera de Desarrollo del Software que se halla a medio camino entre [[RUP]] (Rational Unified Process) y [[XP]] (eXtreme Programming), es una [[metodología]] simplificada en comparación a otras más tradicionales, la cual unifica un conjunto de métodos de orientación a objetos con el objetivo de tener un control estricto sobre todo el ciclo de vida del producto a realizar, cuenta con una secuencia de pasos que se deben seguir y determina claramente las actividades a desarrollar en cada etapa del ciclo de vida del proyecto que la utilice.
 
'''ICONIX:''' es una metodología pesada-ligera de Desarrollo del Software que se halla a medio camino entre [[RUP]] (Rational Unified Process) y [[XP]] (eXtreme Programming), es una [[metodología]] simplificada en comparación a otras más tradicionales, la cual unifica un conjunto de métodos de orientación a objetos con el objetivo de tener un control estricto sobre todo el ciclo de vida del producto a realizar, cuenta con una secuencia de pasos que se deben seguir y determina claramente las actividades a desarrollar en cada etapa del ciclo de vida del proyecto que la utilice.
 
   
 
   
== Metodologías de Desarrollo de Software  ==
+
== Metodologías de Desarrollo del Software  ==
 
Las [[Metodologías de Desarrollo de Software]] surgen debido a la necesidad de emplear una serie de procedimientos y técnicas a la hora de desarrollar un producto de [[software]]. Estas han sido creadas con el propósito de brindarle una guía al desarrollador a la hora de crear un nuevo software. Debido a que no todos los sistemas que se desarrollan tienen la misma complejidad existen una gran variedad de metodologías para la creación de los mismos, están las [[Metodologías Pesadas]], que son aquellas que establecen rigurosamente las actividades a desarrollar, herramientas a utilizar y notaciones que se usarán y las [[Metodologías Ligeras]], que se refieren a una mayor interacción del cliente con el desarrollador del software, mostrándole versiones funcionales del producto en intervalos de tiempo cortos, para que éste pueda evaluar y sugerir cambios en el producto según se va desarrollando.
 
Las [[Metodologías de Desarrollo de Software]] surgen debido a la necesidad de emplear una serie de procedimientos y técnicas a la hora de desarrollar un producto de [[software]]. Estas han sido creadas con el propósito de brindarle una guía al desarrollador a la hora de crear un nuevo software. Debido a que no todos los sistemas que se desarrollan tienen la misma complejidad existen una gran variedad de metodologías para la creación de los mismos, están las [[Metodologías Pesadas]], que son aquellas que establecen rigurosamente las actividades a desarrollar, herramientas a utilizar y notaciones que se usarán y las [[Metodologías Ligeras]], que se refieren a una mayor interacción del cliente con el desarrollador del software, mostrándole versiones funcionales del producto en intervalos de tiempo cortos, para que éste pueda evaluar y sugerir cambios en el producto según se va desarrollando.
 
   
 
   
Línea 109: Línea 108:
 
*http://www.portalhuarpe.com.ar/Seminario09/archivos/MetodologiaICONIX.pdf
 
*http://www.portalhuarpe.com.ar/Seminario09/archivos/MetodologiaICONIX.pdf
 
*http://www.portalhuarpe.com.ar/Seminario09/archivos/UsodeICONIX.pdf
 
*http://www.portalhuarpe.com.ar/Seminario09/archivos/UsodeICONIX.pdf
*http://apurisacav.files.wordpress.com/2012/05/tesis_implementacion-de-sistema-de-gestion-documentaria-mdjayanca.pdf
+
*http://apurisacav.files.wordpress.com/2012/05/tesis_implementacion-de-sistema-de-gestion-documentaria-mdjayanca.pdf   
 
 
 
   
 
 
   
 
   
[[Category:Ciencias_informáticas]] [[Category:Software]] [[Category:Ingeniería_de_software]] [[Category:Metodologías_de_desarrollo_de_software]]
+
[[Category:Ciencias_informáticas]]  
 +
[[Category:Software]]  
 +
[[Category:Ingeniería_de_software]]  
 +
[[Category:Metodologías_de_desarrollo_de_software]]

última versión al 23:23 24 oct 2020

ICONIX
Información sobre la plantilla
Iconix.jpg
Concepto:metodología pesada-ligera de Desarrollo del Software.

ICONIX: es una metodología pesada-ligera de Desarrollo del Software que se halla a medio camino entre RUP (Rational Unified Process) y XP (eXtreme Programming), es una metodología simplificada en comparación a otras más tradicionales, la cual unifica un conjunto de métodos de orientación a objetos con el objetivo de tener un control estricto sobre todo el ciclo de vida del producto a realizar, cuenta con una secuencia de pasos que se deben seguir y determina claramente las actividades a desarrollar en cada etapa del ciclo de vida del proyecto que la utilice.

Metodologías de Desarrollo del Software

Las Metodologías de Desarrollo de Software surgen debido a la necesidad de emplear una serie de procedimientos y técnicas a la hora de desarrollar un producto de software. Estas han sido creadas con el propósito de brindarle una guía al desarrollador a la hora de crear un nuevo software. Debido a que no todos los sistemas que se desarrollan tienen la misma complejidad existen una gran variedad de metodologías para la creación de los mismos, están las Metodologías Pesadas, que son aquellas que establecen rigurosamente las actividades a desarrollar, herramientas a utilizar y notaciones que se usarán y las Metodologías Ligeras, que se refieren a una mayor interacción del cliente con el desarrollador del software, mostrándole versiones funcionales del producto en intervalos de tiempo cortos, para que éste pueda evaluar y sugerir cambios en el producto según se va desarrollando.

Acerca del Autor

Fue elaborado por Doug Rosenberg y Jacobson que ha dado soporte y conocimiento a la metodología ICONIX desde 1993. Presenta claramente las actividades de cada fase y exhibe una secuencia de pasos que deben ser seguidos. Está adaptado a los patrones y ofrece el soporte de UML, dirigido por casos de uso y es un proceso iterativo e incremental.

Carácterísticas de Iconix

Iconix deriva directamente del RUP y su fundamento es el hecho de que un 80% de los casos pueden ser resueltos tan solo 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.

  • Iterativo e Incremental: durante el desarrollo del modelo del dominio y la definición de los casos de uso se producen varias iteraciones. El ciclo de vida incremental consiste en desarrollar por partes el producto de manera que puedas integrarlas funcionalmente. Ciclo de vida Iterativo, en cada ciclo de iteración se revisa y mejora el producto.
  • Trazabilidad: Cada paso que se realiza está definido por un requisito, se define la trazabilidad como la capacidad de seguir una relación entre los diferentes artefactos de software producidos.
  • Dinámica del UML: Ofrece un uso dinámico del UML porque utiliza algunos diagramas UML, sin exigir la utilización de todos, como en el caso de RUP.

Fundamentos de los procesos

  • Tiene que ser lo suficientemente flexible como para adaptarse a diferentes estilos y tipos de problemas.
  • Hay que apoyar la forma de trabajo del personal (incluidos los prototipos y desarrollo iterativo / incremental).
  • Sirve como una guía para los menos experimentados
  • Expone los productos anteriores al código de manera estándar y comprensible.

Fases de la metodología Iconix

  • Revisión de los requisitos/ Análisis de Requisitos:

Identificar en el mundo real, los objetos y todas las relaciones de agregación y generalización entre ellos. Se deben analizar todos los requisitos formaran parte del sistema y con estos construir el diagrama de clases, que representa las agrupaciones funcionales que estructuraran el sistema en desarrollo.

Para esta fase se utilizan 3 herramientas:

Modelo de Dominio: esto se refiere a identificar objetos y cosas del mundo real que intervienen con nuestro sistema. (Estático)

Modelo de Casos de Uso: describe las acciones o el comportamiento que un usuario realiza dentro del sistema. Comprende de actores, casos de uso y el sistema.

Prototipo de Interfaz de Usuario: implica la creación de un modelo o modelos operativos del trabajo de un sistema, en el que analistas y clientes deben estar de acuerdo. (Dinámico/ los usuarios se hacen participantes activos en el desarrollo)

  • Revisión del diseño preliminar /Análisis y Diseño Preliminar

En esta fase a partir de cada caso de uso se obtendrán una ficha de caso de uso, (la cual no pertenece a UML) , está formada por un nombre, una descripción, una precondición que debe cumplir antes de iniciarse, una poscondición que debe cumplir al terminar si termina correctamente. Se deben describir los casos de uso, como un flujo principal de acciones, pudiendo contener los flujos alternativos y los flujos de excepción. la principal sugerencia de Iconix, en esta actividad es que no se debe perder mucho tiempo con la descripción textual. Debería usarse un estilo consistente que sea adecuado al contexto del proyecto. Realizar Diagrama de Robustez: es un híbrido entre un Diagrama de Clases y un Diagrama de Actividades. Es una herramienta que nos permite capturar el Que hacer y a partir de eso él Como hacerlo. Facilita el reconocimiento de objetos y hace más sencilla la lectura del sistema. Ayuda a identificar los objetos que participan en cada caso de uso.

El diagrama de Robustez se divide en:

Objetos fronterizos: usado por los actores para comunicarse con el sistema.

Objetos entidad: son objetos del modelo del dominio.

Objetos de Control: es la unión entre la interfaz y los objetos de entidad.

Diagrama de Clases: describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos

  • Revisión crítica del diseño/Diseño

En esta fase se reconocen todos los elementos que forman parte de nuestro sistema. Diagramas de Secuencia: muestra los métodos que llevaran las clases de nuestro sistema. Muestra todos los cursos alternos que pueden tomar todos nuestros casos de uso. Se debe terminar el modelo estático, añadiendo los detalles del diseño en el diagrama de clases y verificar si el diseño satisface todos los requisitos identificados.

  • Implementación

En esta fase a partir del buen diseño logrado se creara el software; que posteriormente se entregara. Se debe utilizar el diagrama de componentes si fuera necesario para apoyar el desarrollo, es decir mostrar una distribución física de los elementos que componen la estructura interna del sistema. Así como escribir y generar el código.

Pero además se debe tener en cuenta factores como:

Reusabilidad: es la posibilidad de hacer uso de los componentes en diferentes aplicaciones.

Extensibilidad: consiste en modificar con facilidad el software.

Confiabilidad: realización de sistmas descartando las posibilidades de error.

Realizar pruebas: Test de unidades, de casos, datos y resultados. Test de integración con los usuarios para verificar la aceptación de los resultados.

Ventajas

  • Proceso ágil para obtener un sistema informático.
  • Dedicada a la construcción de sistemas de gestión de pequeña y mediana complejidad con la participación de los usuarios finales.

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.

Impacto

  • La metodología ICONIX, es una combinación entre la RUP y XP; está basada en el desarrollo de sistemas a partir del análisis y la documentación.
  • Esta metodología se busca tener una retroactividad con el cliente, en la mitad de los procedimientos, comenzando con un prototipo en donde el analista y el cliente definirán pantallas, funcionalidades, en si lo que se espera obtener del programa.
  • Se definirán los modelos de casos de uso, de secuencia y de robustez, con la finalidad de conseguir un buen sistema.
  • Lo original de la metodología es la definición de un proceso ágil para obtener la especificación de requerimientos y modelar el comportamiento de sistemas, utilizando el lenguaje de modelamiento unificado (UML).
  • Es una alternativa para la comunidad informática dedicada al desarrollo de sistemas de gestión pequeños y medianos, que favorece la participación de los usuarios finales y la documentación de todo el proceso.
  • La participación y el compromiso de los usuarios finales es uno de los pilares fundamentales de las metodologías ágiles que permite verificar la completitud y el cumplimiento de los requisitos. Esto se logra en Iconix con las participación de los usuarios en la protipación temprana, en la descripción de los casos de uso y en las pruebas del sistema.

Enlaces externos

Fuentes

  • E.V.A. UCI, I. D. S.Conferencia #1. Introducción a la Ingeniería de Software, ISW 1.
  • Rosenberg, Doug; Stephens, Matt (2007). Use Case Driven Object Modeling with UML: Theory and Practice. Apress. ISBN 1590597745.
  • Kendall Scott & Doug Rosenberg. ( 2001). Applying Use Case Driven Object Modeling with UML: An Annotated e-Comerce Example. Addison Wesley.
  • Rosenberg, Doug; Stephens, Matt; Collins-Cope, Mark (2005). Agile Development with ICONIX Process. Apress. ISBN 1590594649.

Rferencias