Hilaida Terán Delgado,
Modelado de los Procesos de Negocio
• El modelado de proceso de negocio es esencial
para desarrollar un sistema de información de la
empresa
• Para describir un sistema claramente y
proporcionar un entendimiento completo de
procesos de negocio tanto al desarrollador como
al usuario final, es necesario adoptar más de un
tipo de técnicas de modelado para establecer un
juego de modelos gráficos que describen un
sistema de vistas diferentes
Modelado de Software en las Empresas
de Fabricación
IDEF (Metodología Estructurada)
• Comprende un conjunto de técnicas gráficas de modelado
diseñadas para comunicar o especificar formalmente
importantes aspectos de la ingeniería de proyectos
empresariales
• Comprende IDEF0, IDEF1, IDEF1x, IDEF3 y otras
notaciones gráficas de modelado:
▫ IDEF0: para representar actividades o procesos estándares
▫ IDEF1:para representar la estructura y la semántica de la

información encontrada dentro de un sistema o entorno
▫ IDEF1X: Versión extendida de IDEF1 y provee una técnica de
modelado de la semántica de datos capaz de soportar el
desarrollo conceptual de esquemas
▫ IDEF3: desarrollada como medio de describir el
comportamiento basado en tiempo de los sistemas y provee los
elementos para representar secuencia, tiempo y estado
DFD (Metodología Estructurada)
• Diagramas de Flujos de Datos
• Diagrama Contextuales y Expandidos
• Propósito: modelar procesos y flujos de
información

ERM
• Diagramas de Entidad Relación
• Propósito: modelar la información que
constituirá las Bases de datos electrónicas.
UML (Lenguaje de Modelado Unificado)
• Orientado a la programación orientada a Objetos
(POO)
• Es un estándar de lenguaje de modelado, no un
estándar de proceso.
• Relativamente joven comparada al
IDEF0, IDEF3 y DFD
• Proporciona un grupo de vistas para poder
definir el sistema de estudio (Casos de
Uso, Clases, Estado, Secuencia, Actividades, etc..
)
GRAI Grid
• Para modelos de decisión
• Capa de alto nivel que representa la estructura
organizacional del sistema de producción usando
una matriz de decisión
• Cada celda es llamada Centro de Decisión

GRAI Net
• Para modelos de decisión
• Capa de bajo nivel para describir en detalle los
centros de decisión (uso de IDEF)
Redes Petri
• Para modelos de simulación
• De apoyo a Sistemas relacionados a
investigación de Operaciones

ABC

• Para modelos económicos
• Modelo de costos basado en Actividades
empresariales

RAD
• Diagramas de Simulación de Roles y Actividades
Consideraciones en el Modelado
(Generales)
• Extensamente ha sido aceptado durante varios
años que un sistema debería ser modelado con
vistas diferentes
• La decisión sobre una opción de técnica
conveniente depende de:
▫ las exigencias de proyecto,
▫ el escenario de la implementación.

• Según cambia el escenario, la técnica también
debería ser cambiada
Consideraciones en el Modelado
En la etapa de Análisis de Requerimientos y
Modelo Conceptual
• un lenguaje que sea comprensible tanto por el usuario
final como por el desarrollador es muy importante.
• El modelado de requerimientos debe ser conducidos por
el negocio y no por la tecnología
• Es difícil para el desarrollador juntar la información
suficiente de repente, lo que restringe el empleo de
Diagramas de Clase en el establecimiento del modelo
POO. El desarrollador también puede encontrarlo difícil
de adoptar ERM O IDEF1X estableciendo el modelo de
datos completo.
• La metodología estructurada es todavía irreemplazable.
Consideraciones en el Modelado
En la etapa de Diseño y Construcción
• UML y ERM puede jugar papeles muy
importantes
• El apoyo de algunas Herramientas
CASE, Diagramas UML y ERM hacen las
técnicas más convenientes para la generación
automática de código y de base de datos física
Hilaida_teran7@yahoo.com

Modelado de Software en las Empresas de Fabricación

  • 1.
  • 2.
    Modelado de losProcesos de Negocio • El modelado de proceso de negocio es esencial para desarrollar un sistema de información de la empresa • Para describir un sistema claramente y proporcionar un entendimiento completo de procesos de negocio tanto al desarrollador como al usuario final, es necesario adoptar más de un tipo de técnicas de modelado para establecer un juego de modelos gráficos que describen un sistema de vistas diferentes
  • 3.
    Modelado de Softwareen las Empresas de Fabricación
  • 4.
    IDEF (Metodología Estructurada) •Comprende un conjunto de técnicas gráficas de modelado diseñadas para comunicar o especificar formalmente importantes aspectos de la ingeniería de proyectos empresariales • Comprende IDEF0, IDEF1, IDEF1x, IDEF3 y otras notaciones gráficas de modelado: ▫ IDEF0: para representar actividades o procesos estándares ▫ IDEF1:para representar la estructura y la semántica de la información encontrada dentro de un sistema o entorno ▫ IDEF1X: Versión extendida de IDEF1 y provee una técnica de modelado de la semántica de datos capaz de soportar el desarrollo conceptual de esquemas ▫ IDEF3: desarrollada como medio de describir el comportamiento basado en tiempo de los sistemas y provee los elementos para representar secuencia, tiempo y estado
  • 5.
    DFD (Metodología Estructurada) •Diagramas de Flujos de Datos • Diagrama Contextuales y Expandidos • Propósito: modelar procesos y flujos de información ERM • Diagramas de Entidad Relación • Propósito: modelar la información que constituirá las Bases de datos electrónicas.
  • 6.
    UML (Lenguaje deModelado Unificado) • Orientado a la programación orientada a Objetos (POO) • Es un estándar de lenguaje de modelado, no un estándar de proceso. • Relativamente joven comparada al IDEF0, IDEF3 y DFD • Proporciona un grupo de vistas para poder definir el sistema de estudio (Casos de Uso, Clases, Estado, Secuencia, Actividades, etc.. )
  • 7.
    GRAI Grid • Paramodelos de decisión • Capa de alto nivel que representa la estructura organizacional del sistema de producción usando una matriz de decisión • Cada celda es llamada Centro de Decisión GRAI Net • Para modelos de decisión • Capa de bajo nivel para describir en detalle los centros de decisión (uso de IDEF)
  • 8.
    Redes Petri • Paramodelos de simulación • De apoyo a Sistemas relacionados a investigación de Operaciones ABC • Para modelos económicos • Modelo de costos basado en Actividades empresariales RAD • Diagramas de Simulación de Roles y Actividades
  • 9.
    Consideraciones en elModelado (Generales) • Extensamente ha sido aceptado durante varios años que un sistema debería ser modelado con vistas diferentes • La decisión sobre una opción de técnica conveniente depende de: ▫ las exigencias de proyecto, ▫ el escenario de la implementación. • Según cambia el escenario, la técnica también debería ser cambiada
  • 10.
    Consideraciones en elModelado En la etapa de Análisis de Requerimientos y Modelo Conceptual • un lenguaje que sea comprensible tanto por el usuario final como por el desarrollador es muy importante. • El modelado de requerimientos debe ser conducidos por el negocio y no por la tecnología • Es difícil para el desarrollador juntar la información suficiente de repente, lo que restringe el empleo de Diagramas de Clase en el establecimiento del modelo POO. El desarrollador también puede encontrarlo difícil de adoptar ERM O IDEF1X estableciendo el modelo de datos completo. • La metodología estructurada es todavía irreemplazable.
  • 11.
    Consideraciones en elModelado En la etapa de Diseño y Construcción • UML y ERM puede jugar papeles muy importantes • El apoyo de algunas Herramientas CASE, Diagramas UML y ERM hacen las técnicas más convenientes para la generación automática de código y de base de datos física
  • 12.