Universidad del Cauca
mi cuentatablerodirectorioclasificadosftpgruposbibliotecaweb personales

Edificio de la Facultad
Edificio de la Facultad


Mapa del sitio
Contactenos
Derechos reservados
Inicio > Academia > Facultades > F.C.C.E.A > Guillermo A Cuéllar M >
 
  • Niveles de Cambio

  • Reingeniería de Procesos

  • Reingeniería  

  • Admón Proyectos

  • Distintos Enfoques

  • Paquetes Integrados 

  • Metodología para ERP

  • Fracasos

  •  

  • Desarrollo e Implementación de Sistemas de Información
    5. MODELADO DE PROCESOS DIAGRAMA DE FLUJO DE DATOS ESPECIFICACIÓN DE PROCESOS
     

    Modelado de procesos

     

    Tradicionalmente el modelado de procesos ha estado enfocado en el análisis del flujo y transformación de datos. La utilización de las computadoras en tecnología de información no había sido usada más allá del procesamiento de transacciones, como en la comunicación y control. Para hacer una integración satisfactoria de estos sistemas dentro de la empresa, se requiere de modelar desde los procesos organizacionales manuales en los que intervienen estos sistemas.

     

    Algunos ejemplos de esto, son:

     

    Ø        La reingeniería de procesos de negocios, la cual se encarga del rediseño de los procesos de negocios de las organizaciones con el fin de hacerlos más eficientes.

     

    Ø        Tecnología de coordinación, que ayuda en el manejo de las dependencias entre los agentes de un proceso de negocios, y provee soporte automatizado para los componentes más rutinarios del proceso. 

     

    Ø        Ambientes de desarrollo de software dirigidos por el proceso, que es un sistema automatizado que integra el trabajo de toda la administración y personal relacionado con el software. 

     

    El modelado de procesos se distingue de otros tipos de modelado en las áreas de la computación, porque los fenómenos modelados son realizados más por humanos que por máquinas. También porque se centra en las interacciones entre los agentes, independientemente de si una computadora está envuelta en las transacciones. 

     

    Usos para los modelos de procesos

     

    Frecuentemente la gran cantidad de descripciones del ciclo de vida del software que almacenan las organizaciones, no corresponde con el proceso actualmente llevado a cabo en el desarrollo o mantenimiento del software. Esta falta de fidelidad es causada por factores como: 

     

    Ø        Prescripciones del proceso de alto nivel que no están relacionadas con las actividades actuales del proyecto.  

    Ø        Descripciones no utilizadas, imprecisas, ambiguas, incomprensibles, del proceso a ser representado en el proyecto, y  

    Ø        Fallas en la actualización de la documentación cuando ocurren cambios en el proceso.  

     

    Tradicionalmente las descripciones del ciclo de vida son vistas como modelos del proceso, pero estas normalmente se centran en una abstracción de la ingeniería del producto, y fallan al mostrar muchos bloques de construcción del proceso elementales, necesarios para manejar y coordinar el proyecto. 

     

    Cinco usos básicos de los modelos de procesos son: 

     

    1.       Facilitar el entendimiento y comunicación humanos, requiere que un grupo pueda compartir representaciones de formatos comunes.  

     

    2.       El soporte para la mejora de procesos requiere una base para definir y analizar los procesos.  

     

    3.       El soporte para la administración de procesos requiere un proceso definido, contra el cual el comportamiento del proyecto pueda ser comparado.  

     

    4.       La conducción automática del proceso requiere herramientas automatizadas para manipular descripciones de procesos.  

     

    5.       El soporte para ejecución automática requiere bases computacionales para controlar el comportamiento de un ambiente automatizado.  

      

    Estructura conceptual 

     

    Un proceso es una secuencia de pasos o actividades ordenadas necesarias para el logro de un objetivo. 

    Un elemento del proceso es cualquier componente del proceso. 

    Un paso o actividad es una acción atómica de un proceso, que no tiene una estructura externamente visible. 

    Un agente es un actor que desempeña algún elemento del proceso. 

    Un rol es un conjunto coherente de elementos del proceso que son asignados a un agente como una unidad de responsabilidad funcional. 

    Un artefacto es un producto creado o modificado por la ejecución de un elemento del proceso. 

    Un script del proceso, es un modelo del proceso que será desempeñado por un humano.

    Un programa del proceso, es un modelo del proceso que será ejecutado por una máquina. 

     

    Perspectivas en la representación de procesos 

     

    Cuatro de las más comunes perspectivas representadas son: 

     

    Funcional.- Representa que elementos del proceso están siendo ejecutados y que entidades de información son relevantes a estos elementos del proceso.  

     

    De conducta.- Representa cuando los elementos del proceso son ejecutados, asi como aspectos de cómo son ejecutados a través ciclos, iteraciones, toma de decisiones complejas, criterios de entrada y salida, etc.  

     

    Organizacional.- Representa donde y por quién en la organización, se ejecutarán los elementos del proceso, los mecanismos físicos de comunicación usados en las transferencias de entidades, y el medio y localización físico, usado para el almacenamiento de entidades.  

     

    De Información.- Representa las entidades de información producidas o manipuladas por un proceso. Esta representación incluye la estructura de las entidades de información y sus relaciones entre ellas.  

     

    Estas representaciones presentan distintas ventajas desde el punto en que cada una puede ver y observar el proceso.  Podemos asumir que combinando estas perspectivas produciremos un modelo integrado, consistente y completo del proceso analizado. 

     

    Paradigmas del modelado de procesos 

     

    Los lenguajes y representaciones para modelado de procesos pueden ser evaluadas en la medida de que tantas construcciones útiles proveen para representar y razonar acerca de varios aspectos de un proceso.

    Osterweil presentó el siguiente problema : “para encontrar que características de un lenguaje necesitamos, debemos escribir programas de procesos: para escribir programas de procesos, necesitamos características adecuadas de algún lenguaje”. 

     

    Cinco aproximaciones para representar procesos son: 

     

    Modelos de programación.- Esta aproximación parte de la observación de que la especificación de un proceso es una forma de programación, por lo tanto un proceso puede ser modelado con todas las técnicas y herramientas de los programadores.  

     

    Modelos funcionales.- Un proceso es representado como una colección de elementos con atributos de entrada y de salida.  Específicamente, un proceso se define como un conjunto de funciones matemáticas que representan relaciones entre entradas y salidas. Además, cada una de estas funciones puede ser descompuesta jerárquicamente en sub-elementos del proceso donde los atributos de entrada y salida de un elemento padre deben ser satisfechos por los atributos de sus hijos.  

     

    Modelos basados en plan.- Este paradigma provee mecanismos donde los operadores representan posibles acciones que son seleccionadas con base en sus precondiciones. Estos operadores son aplicados al estado actual del domino en el que el proceso opera, con el fin de acercar más ese estado al objetivo deseado.  

     

    Modelos redes de Petri.- Esta técnica modela la estructura de interacción de roles de un proyecto usando un lenguaje y una representación basados en redes de Petri. Las redes de interacción de roles ayudan a la representación y ejecución de tareas estructuradas, que son aquellas que pueden ser planeadas por dependencias conocidas.  

     

    Modelos cuantitativos.- Sistemas dinámicos es una de las pocas técnicas de modelado que involucra representaciones cuantitativas, y aplica retroalimentación y técnicas de sistemas de control a fenómenos sociales e industriales. Los modelos construidos de esta manera intentan definir un conjunto de relaciones cuantitativas entre variables de interés que simulan el comportamiento observado del sistema social.  

     

    Formalidad del modelado de procesos

     

    El nivel de matemática formal requerida en un lenguaje de modelado de procesos, puede depender del propósito para el cual sirve el modelo del proceso y el agente responsable de la ejecución del proceso especificado. Un lenguaje formal es mas fácil de manejar para una máquina que para un humano. Desafortunadamente, el interés en el entendimiento y la comunicación humana, ha recibido menos atención que las máquinas, y las definiciones y modelos de procesos no pueden ser de utilidad si no son entendibles. 

     

    Granularidad y precisión

     

    La granularidad envuelve el tamaño de los elementos del proceso representados en el modelo. La necesidad de una mayor granularidad, es conducida por la necesidad de asegurar la precisión en el proceso. 

     

    Adaptabilidad y Scriptiveness 

     

    Los modeladores de procesos difieren en como las prescripciones que ellos pretenden que sus modelos sean del actual comportamiento a ser desempeñado. Un modelo prescriptivo implica que el proceso se debe  llevar a cabo de una manera particular. 

     

    El modelado descriptivo intenta determinar el proceso actualmente utilizado en una organización para realizar el trabajo, es decir un proceso de la organización que sirva de línea base. 

     

    Una tercera perspectiva es ofrecida por los modelos proscriptivos, que delinean los comportamientos no permitidos. 

     

    Direcciones futuras 

     

    Se han estado realizando trabajos y estudios para acelerar el crecimiento del modelado de procesos, tales como los esfuerzos por realizar un ejemplo que involucre la mayor parte de los aspectos del modelado de procesos de software, a fin de que provea bases importantes para el entendimiento, comparación y evaluación de distintas aproximaciones de modelado. 

     

    Representaciones multiparadigma.- La aplicabilidad de un acercamiento de modelado dependerá de los objetivos del modelo resultante. Un tipo de lenguaje dado será mejor aplicable para algunos objetivos del modelado que otros. Para un modelado de procesos de software efectivo, se considera necesario la integración de múltiples paradigmas de representación, sin embargo esto genera nuevos retos y problemas. 

    Uso en el mejoramiento de procesos.- Cuando se elimina el ruido creado por una pobre definición o mal manejo de un proceso, el impacto de la tecnología es mas fácilmente observado en los proyectos. Por lo tanto algunas compañías de software se han enfocado a definir los procesos del negocio de software, y solo una ves hecho esto, se seleccionan las herramientas y métodos que soporten estos procesos.

     

    Esto provee el fundamento para una productividad y calidad en crecimiento. 

    Uso en la administración de proyectos de software.- Un grupo creciente de trabajo se ha enfocado a usar el modelado de procesos para soportar la administración del desarrollo y evolución de software. Este soporte permite a los administradores realizar planes de tareas, costos y recursos mientras varia el requerimiento de recursos y se adecua un modelado determinista o estocástico.

     

    Ambientes de desarrollo de software basados en el proceso.- Se trata de desarrollar ambientes dirigidos por el proceso. Debido a la ausencia de un proceso de software definido, es difícil identificar: 

     

    • La suite completa de herramientas necesarias para soportar el proceso entero.  

     

    • Como pueden ser integradas estas herramientas para soportar el trabajo actual y  

     

    • Como diseñar un ambiente de desarrollo de software que coordine el trabajo de muchos ingenieros de software. 

     

     

    DIAGRAMAS DE FLUJO DE DATOS 

     

    OBJETIVOS 

    Construir un modelo lógico del sistema que facilite la comprensión del mismo, tanto por parte de los usuarios como del equipo de desarrollo. 

     

    Para ello se dividirá el sistema en distintos niveles de detalle. Esta división permitirá:

    • Simplificar la complejidad del sistema, representando los diferentes procesos sencillos de que consta un sistema complejo.

    • Repartir el trabajo entre los diferentes miembros del equipo de desarrollo. Facilitar el mantenimiento del sistema.

     Los fundamentos de la técnica del Diagrama de Flujo de Datos (DFD) son los siguientes:

    • Representar gráficamente los límites del sistema en estudio.

    • Mostrar el movimiento de los datos y la transformación de los mismos a través del sistema.

    • Diferenciar las restricciones físicas de las lógicas.

     

    Para conseguir estos objetivos el resultado del análisis debe ser:

    • GRÁFICO.

    • LÓGICO, nunca referido a entornos físicos.

    • PRECISO Y BREVE.

    • COMPRENSIBLE.

    • DEBIDAMENTE PARTICIONADO.

    • BIEN DOCUMENTADO.

    • NUNCA REDUNDANTE.

    • ESTABLECERÁ "QUÉ" FUNCIONES SE DEBEN DESARROLLAR, SIN IMPLICAR "CÓMO".

    • NO AMBIGUO.

     

    Como resultado se obtendrá un modelo del sistema completamente independiente de las restricciones físicas del entorno, lo que facilitará su mantenimiento y portabilidad. 

    En los Diagramas de Flujo de Datos, no se deberán modelizar:

    • PROCEDIMIENTOS.

    • PUNTO DE INICIO Y DE TERMINACIÓN DEL DFD.

    • CONDICIONES.

    • TRATAMIENTOS DE ERRORES POCO RELEVANTES.

     

    ELEMENTOS BÁSICOS DE LOS DIAGRAMAS DE FLUJO DE DATOS 

     

    En cualquier Diagrama de Flujos de Datos, aparecerán los objetos siguientes: 

    • ENTIDAD EXTERNA.

    • PROCESO.

    • ALMACÉN DE DATOS.

    • FLUJO DE DATOS.

     

    Algunos de ellos podrán tener alguna restricción con respecto únicamente al nivel en el cual pueden o deben aparecer. Esto ya se detallará más adelante.

     

    La técnica de representación dará lugar a un DFD (Diagrama de Flujo de Datos) en el que se irán detallando los principales procesos o acciones a desarrollar y que se irán detallando en mayor medida según se vaya bajando de nivel (EXPLOSIONANDO) cada uno de esos procesos.

    La comunicación existente entre esas actividades se representa entre el resto de los elementos. 

     

    DIAGRAMA DE FLUJO DE DATOS 

     

    El DIAGRAMA DE FLUJO DE DATOS (DFD) proporciona una representación del sistema a nivel lógico y conceptual. Utiliza una notación y unas reglas predeterminadas.

     

    ENTIDAD EXTERNA

    Las Entidades Externas representan entes ajenos a nuestra aplicación, pero que aportan o reciben información de la misma. Se representa mediante una elipse o un rectángulo con un nombre significativo dentro. 

    Reglas de construcción:

    1. Representa personas, organizaciones o sistemas que no pertenecen al sistema.

    2. En el caso de que las entidades externas se comunicasen entre sí, esto no se contemplaría en el diagrama, por estar fuera del ámbito de nuestro sistema.

    3. Puede aparecer en los distintos niveles de DFD.

    4. Puede aparecer varias veces en un mismo diagrama, para evitar entrecruzamientos de líneas.

    5. Suministra información acerca de la conexión del sistema con el mundo exterior.

     

    PROCESO

    Es una actividad que transforma o manipula datos. Se representa mediante un rectángulo, de la siguiente manera: 

     

    En la parte de PROCESO se expresa el nombre del proceso correspondiente. Dependiendo del nivel de detalle en que nos encontremos dentro de un DFD, el nombre del proceso simbolizará bien el sistema concreto (nivel sistema), bien el subsistema de que se trate (nivel subsistema), o bien acciones concretas y detalladas en niveles inferiores.

     

    En la parte superior izquierda se coloca un número identificativo del proceso. Este número permitirá además indicar el nivel del DFD en que nos encontramos; esto se explicará más en detalle cuando se hable de la descomposición por niveles.

     

    Es importante hacer énfasis en que este número no indica secuencia de realización del proceso, dado que los DFD no representan una secuencialidad en el tratamiento de los datos.

     

    La parte de localización expresa la Unidad o área dentro de la organización donde se realiza este proceso. 

     

    Reglas de construcción:

     

    1. Cuando un Flujo de datos entra en un proceso sufre una transformación. Un proceso no es ni origen ni final de los datos, sólo lugar de transformación de los mismos. Por ello, cualquier flujo de datos que entre en un proceso ha de transformarse (ver Figura DFD3).

    2. Un proceso puede transformar un dato en varios.

    3. Es necesario un proceso como intermediario entre una Entidad Externa y un Almacén de Datos. 

     

    ALMACÉN DE DATOS

    Un almacén de datos representa un depósito de información dentro del sistema.

     

    Se representa dentro del DFD con la siguiente Figura: 

     

    En la parte derecha se indica el nombre del almacén de datos. En la parte izquierda se representa la identificación de dicho almacén dentro del DFD.

     

    En el caso de que dentro de un DFD aparezca repetido el mismo almacén de datos, se puede representar de la siguiente forma: 

     

    Es conveniente distinguir las diferentes utilidades que presentan los almacenes de datos. En primer lugar, el almacenamiento permanente de datos, donde se guardan los datos que sirven de referencia de uso del sistema, es decir, los datos permanentes, sobre los que el sistema necesita guardar información (ALMACENES PRINCIPALES).

     

    Por otra parte, el almacenamiento transitorio de los datos antes de ser usados por un proceso. Para entender el significado de estos almacenes transitorios, se puede imaginar la situación del ejemplo de la Figura DFD5.

     

    En este ejemplo el proceso RECOGER SOLICITUDES, que se ejecuta continuamente a lo largo de la jornada, genera los datos de salida representados por el flujo de datos SOLICITUDES. Estos datos constituyen los datos de entrada al proceso VALIDAR SOLICITUD, que se ejecuta al final de la jornada, en el intervalo esos datos de solicitud "reposarían" en el almacén SOLIC-PROV, cuya utilidad básica es establecer una sincronización en el funcionamiento de ambos procesos. 

     

    Los almacenes transitorios suelen representar restricciones físicas del sistema y por tanto en un DFD, que expresa la lógica de los tratamientos realizados por el sistema, en muchos casos no será necesario representarlos. Sin embargo hay ocasiones en que estos almacenes simbolizan "ficheros de movimientos", donde se guardan los datos porque el proceso siguiente necesita manejarlos todos al mismo tiempo (por ejemplo, en un proceso que compara un conjunto de registros, será necesario mantenerlos guardados en un almacén transitorio, para que dicho proceso los lea todos al mismo tiempo). En este caso sí será conveniente representarlos.

     

    Por último, para asegurar la consistencia entre todas las técnicas utilizadas en la Fase de Análisis, se establecerá una relación precisa entre los almacenes de datos "principales" de un DFD y las entidades de los Diagramas de Estructura de Datos (DED): cada almacén principal de un DFD representa un conjunto completo de entidades del DED (una o varias entidades), y cada entidad de un DED pertenece a un único almacén principal de un DFD; esto facilitará las validaciones cruzadas entre los dos diagramas. 

     

    Reglas de construcción:

    1. Representa la información en reposo.

    2. No puede crear, destruir ni transformar datos.

    3. No puede estar comunicado directamente con otro Almacén o Entidad Externa.

    4. El flujo de datos (Entrada o Salida) no lleva nombre cuando incide sobre su contenido completo.

    5. El almacén de datos aparecerá por vez primera en aquel nivel en que sea accedido por dos o más procesos y en modo lectura y/o escritura.

    6. No debe estar referido al entorno físico y por tanto, no se diferencian los ficheros convencionales de las Bases de Datos.

    7. No se representa la clave de acceso a ese almacén sino sólo la operación que se realiza (lectura, escritura, actualización) 
     

    FLUJO DE DATOS

     

    Los Flujos de Datos establecen la comunicación entre procesos, almacenes y entidades externas, y llevan información necesaria para esos objetos. 

    Reglas de construcción:

    1. El concepto de flujo de datos es similar al de una "tubería" a través de la cual fluye una información de estructura conocida.

    2. Los datos no pueden ser creados ni destruidos por un flujo de datos.

    3. Sirve para conectar el resto de los componentes del DFD.

    4. No es un activador de procesos.

    5. Cuando un proceso almacena datos, la flecha de flujo de datos se indica en la dirección del almacén de datos y a la inversa si es el proceso el que lee datos en el almacén. 

     

    Conclusiones: 

     

    Existen diversas perspectivas para representar un proceso, así como diferentes maneras o paradigmas para modelarlos desde las distintas perspectivas. Debido a la variabilidad de los procesos que pueden presentarse en una organización, resulta difícil estandarizar una manera de representarlos.

     

    Ya que cada representación se centra en distintos aspectos del proceso. Puede ayudarnos el mezclar varias de estas perspectivas y paradigmas a fin de capturar todos los aspectos del proceso. Aunque en el artículo se menciona que se están haciendo esfuerzos por desarrollar herramientas que manejen un paradigma que envuelva todos las representaciones del modelado de procesos, a mi forma de ver, esto resultaría poco factible para su utilización en la mayor parte de las organizaciones, ya que el sistema resultante sería demasiado robusto y costoso, y con características que quizá no fueran de utilidad en la mayor parte de los procesos a ser modelados. Una solución a esto podría ser desarrollar distintos sistemas más pequeños enfocados al modelado de ciertos tipos de procesos, y de esta manera elegir la que mejor se adecue a la forma de llevar a cabo los procesos manejados en nuestra organización.

     
     

    Vicerrectoría Académica
    Facultades
    Admisiones y Registro
    Acreditacion
    Biblioteca


    Universidad Investigación Portafolio
    Academia Cultura y bienestar De Interés

    + Información General + Proyecto Educativo + Consejo superior
    + Rectoría + Vicerrectoría administrativa + Fundación de apoyo
    + Salud Ocupacional
    + Vicerrectoría Académica + Facultades + Biblioteca
    + Admisiones y Registro + Acreditación
    + Información General + Convocatorias + Programas de apoyo
    + Proyectos + Grupos + Boletín Vri
    + Intravri + De interés
    + Información General + Salud integral + Deporte y recreación
    + Sistema de Cultura y Bienestar + Comunicaciones + Egresados
    + Fondo de Empleados + Patrimonio cultural
    + Columna Universitaria + Libros + Actas
    + Noticias + Convocatorias + Resoluciones
    + Eventos + Comunicados + Reglamentos
    + Publicaciones Periódicas + Acuerdos + Trámites

     

     

    Copyright © Universidad del Cauca
    Santo Domingo : Calle 5 No. 4-70 - Tel. (+57 2) 820 9900
    Sector Tulcan : (+57 2) 820 9800
    http://www.ucauca.edu.co/contactenos.php?mailto=internet@unicauca.edu.co
    Popayán (Cauca) - Colombia