SlideShare una empresa de Scribd logo
1 de 21
HISTORIA
             
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 ha dado soporte y conocimiento a
 la metodología ICONIX desde 1993.
CARACTERISTICAS
FUNDAMENTALES DE ICONIX
                         
 Iterativo e incremental.




    DESARROLLO
    DE MODELO       ITERACION   IDENTIFICACION
    DE DOMINIO                  DE CASOS DE USO
CARACTERISTICAS
   FUNDAMENTALES DE ICONIX
                                
    Trazabilidad.


       REQUISITO 1      REQUISITO 2   REQUISITO 3


REFERENCIA         REFERENCIA               REFERENCIA


          PASO 1           PASO 2        PASO 3
CARACTERISTICAS
FUNDAMENTALES DE ICONIX
                       
 Dinámica de UML
1. Diagramas de caso de uso
2. Diagramas de secuencia
3. Diagramas de colaboración
FASES DE ICONIX
              
1)   Análisis de Requisitos.
2)   Análisis y Diseño Preliminar.
3)   Diseño.
4)   Implementacion
ANÁLISIS DE
           REQUISITOS
               
 Identificar en el mundo real los objetos y todas las
  relaciones de agregación y generalización entre ellos.
  Utilizar un diagrama de clases de alto nivel definido
  como modelo de dominio.
ANÁLISIS DE
           REQUISITOS
               
 Presentar una prototipación rápida de las interfaces
   del sistema, los diagramas de navegación, etc.
1. Prototipo de Vialidad.
2. Prototipo de Necesidades.
3. Prototipo de Diseño.
4. Prototipo de Implementacion
ANÁLISIS DE
           REQUISITOS
               
 Identificar los casos de uso del sistema mostrando
  los actores involucrados. Se utiliza el modelo de
  caso de uso.
ANÁLISIS Y DISEÑO
     PRELIMINAR
          
 Describir los casos de uso como un flujo principal de
  acciones, conteniendo los flujos alternativos y de
  excepciones.
 Realizar un diagrama de robustez.
 Actualizar el diagrama de clases con las nuevas
  clases y atributos.
ANÁLISIS Y DISEÑO
     PRELIMINAR
          
 El diagrama de robustez ayuda a identificar los
   objetos que participan en cada caso de uso.
1. Objetos de Interfaz.
2. Objetos Entidad.
3. Objetos de Control.
ANÁLISIS Y DISEÑO
     PRELIMINAR
          
 Las reglas básicas que se deben de aplicar a los diagramas de
  robustez son:
 Actores solo pueden comunicarse con objetos de interfaz.
 Las interfaces solo pueden comunicarse con controles y
  actores.
 Los objetos entidad solo pueden comunicarse con controles.
 Los controles se comunican con interfaces, objetos entidad y
  con otros controles pero nunca con actores.
DISEÑO
                    
 Especificar el comportamiento a través del diagrama
  de secuencia.
 Terminar el modelo estático, agregando los detalles
  del diseño en el diagrama de clases.
 Verificar si el diseño satisface los requisitos
  identificados.
IMPLEMENTACIÓN
       
 Utilizar el diagrama de componentes, en caso
  necesario para ayudar al desarrollo.
 Escribir y Generar el código.
 Realizar pruebas.
IMPLEMENTACIÓN
         
 La reusabilidad.
 La extensibilidad.
 La confiabilidad.

Más contenido relacionado

Similar a Mp.exp.2.330152 (20)

Is.exp.329466
Is.exp.329466Is.exp.329466
Is.exp.329466
 
Proceso unificado de desarrollo de software
Proceso unificado de desarrollo de softwareProceso unificado de desarrollo de software
Proceso unificado de desarrollo de software
 
Is.exp.329466
Is.exp.329466Is.exp.329466
Is.exp.329466
 
ICONIX
ICONIXICONIX
ICONIX
 
Modelado Orientado a Objetos
Modelado Orientado a ObjetosModelado Orientado a Objetos
Modelado Orientado a Objetos
 
Semana8 soft ii
Semana8 soft iiSemana8 soft ii
Semana8 soft ii
 
Clase 02 ciclo de vida
Clase 02 ciclo de vidaClase 02 ciclo de vida
Clase 02 ciclo de vida
 
OOSE
OOSEOOSE
OOSE
 
Modelo de analisis expo
Modelo de analisis expoModelo de analisis expo
Modelo de analisis expo
 
Ingeniería de software II - Parte 4
Ingeniería de software II - Parte 4Ingeniería de software II - Parte 4
Ingeniería de software II - Parte 4
 
UNIDAD I. TRANSICIÓN DEL ANÁLISIS HACIA EL DISEÑO.
 UNIDAD I.  TRANSICIÓN DEL ANÁLISIS HACIA EL DISEÑO.  UNIDAD I.  TRANSICIÓN DEL ANÁLISIS HACIA EL DISEÑO.
UNIDAD I. TRANSICIÓN DEL ANÁLISIS HACIA EL DISEÑO.
 
Analisis y Diseños de Sistemas 2-Metodologia OOSE
Analisis y Diseños de Sistemas 2-Metodologia OOSEAnalisis y Diseños de Sistemas 2-Metodologia OOSE
Analisis y Diseños de Sistemas 2-Metodologia OOSE
 
Metodologia uml
Metodologia umlMetodologia uml
Metodologia uml
 
Metodologia uml
Metodologia umlMetodologia uml
Metodologia uml
 
Metodologia UML
Metodologia UMLMetodologia UML
Metodologia UML
 
UML
UMLUML
UML
 
Metodologia para el proyecto
Metodologia para el proyectoMetodologia para el proyecto
Metodologia para el proyecto
 
Tipos de modelo y metodologias
Tipos de modelo y metodologiasTipos de modelo y metodologias
Tipos de modelo y metodologias
 
Desarrollo de Software Orienta a Objetos
Desarrollo de Software Orienta a ObjetosDesarrollo de Software Orienta a Objetos
Desarrollo de Software Orienta a Objetos
 
Desarrollo basado en patrones
Desarrollo basado en patronesDesarrollo basado en patrones
Desarrollo basado en patrones
 

Mp.exp.2.330152

  • 1.
  • 2. HISTORIA  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 ha dado soporte y conocimiento a la metodología ICONIX desde 1993.
  • 3. CARACTERISTICAS FUNDAMENTALES DE ICONIX   Iterativo e incremental. DESARROLLO DE MODELO ITERACION IDENTIFICACION DE DOMINIO DE CASOS DE USO
  • 4. CARACTERISTICAS FUNDAMENTALES DE ICONIX   Trazabilidad. REQUISITO 1 REQUISITO 2 REQUISITO 3 REFERENCIA REFERENCIA REFERENCIA PASO 1 PASO 2 PASO 3
  • 5. CARACTERISTICAS FUNDAMENTALES DE ICONIX   Dinámica de UML 1. Diagramas de caso de uso 2. Diagramas de secuencia 3. Diagramas de colaboración
  • 6.
  • 7.
  • 8.
  • 9. FASES DE ICONIX  1) Análisis de Requisitos. 2) Análisis y Diseño Preliminar. 3) Diseño. 4) Implementacion
  • 10. ANÁLISIS DE REQUISITOS   Identificar en el mundo real los objetos y todas las relaciones de agregación y generalización entre ellos. Utilizar un diagrama de clases de alto nivel definido como modelo de dominio.
  • 11.
  • 12. ANÁLISIS DE REQUISITOS   Presentar una prototipación rápida de las interfaces del sistema, los diagramas de navegación, etc. 1. Prototipo de Vialidad. 2. Prototipo de Necesidades. 3. Prototipo de Diseño. 4. Prototipo de Implementacion
  • 13. ANÁLISIS DE REQUISITOS   Identificar los casos de uso del sistema mostrando los actores involucrados. Se utiliza el modelo de caso de uso.
  • 14. ANÁLISIS Y DISEÑO PRELIMINAR   Describir los casos de uso como un flujo principal de acciones, conteniendo los flujos alternativos y de excepciones.  Realizar un diagrama de robustez.  Actualizar el diagrama de clases con las nuevas clases y atributos.
  • 15.
  • 16. ANÁLISIS Y DISEÑO PRELIMINAR   El diagrama de robustez ayuda a identificar los objetos que participan en cada caso de uso. 1. Objetos de Interfaz. 2. Objetos Entidad. 3. Objetos de Control.
  • 17. ANÁLISIS Y DISEÑO PRELIMINAR   Las reglas básicas que se deben de aplicar a los diagramas de robustez son:  Actores solo pueden comunicarse con objetos de interfaz.  Las interfaces solo pueden comunicarse con controles y actores.  Los objetos entidad solo pueden comunicarse con controles.  Los controles se comunican con interfaces, objetos entidad y con otros controles pero nunca con actores.
  • 18. DISEÑO   Especificar el comportamiento a través del diagrama de secuencia.  Terminar el modelo estático, agregando los detalles del diseño en el diagrama de clases.  Verificar si el diseño satisface los requisitos identificados.
  • 19. IMPLEMENTACIÓN   Utilizar el diagrama de componentes, en caso necesario para ayudar al desarrollo.  Escribir y Generar el código.  Realizar pruebas.
  • 20.
  • 21. IMPLEMENTACIÓN   La reusabilidad.  La extensibilidad.  La confiabilidad.