Diagrama de procesos y datos

Un diagrama de procesos y datos (PDD) , también conocido como diagrama de procesos y entregables, es un diagrama que describe los procesos y los datos que actúan como resultado de estos procesos. En el lado izquierdo se puede visualizar el modelo de metaproceso y en el lado derecho el modelo de metadatos . ^{[ 1 ]}

Un diagrama de procesos y datos puede considerarse como una combinación de un modelo de proceso de negocio y un modelo de datos .

Descripción general

El diagrama de procesos y datos que se muestra a la derecha ofrece una visión general de todas estas actividades, procesos y entregables. Los cuatro recuadros grises representan las cuatro fases principales de implementación , cada una con varios procesos que, en este caso, son secuenciales. Los recuadros de la derecha muestran todos los entregables y conceptos que resultan de los procesos. Los recuadros sin sombra no tienen subconceptos. Los recuadros con sombra negra representan conceptos cerrados complejos, es decir, conceptos con subconceptos que, sin embargo, no se describirán con mayor detalle. Los recuadros con sombra blanca (un recuadro detrás) representan conceptos abiertos y cerrados, donde los subconceptos se desarrollan con mayor detalle. Las líneas con rombos muestran una relación de dependencia entre conceptos.

El proceso de implementación de SAP se compone de cuatro fases principales: la preparación del proyecto, donde se define la visión del estado futuro de la solución SAP; la fase de dimensionamiento y diseño, donde se adquiere el conjunto de software y se imparte la formación ; la fase de desarrollo funcional; y, finalmente, la fase de preparación final, en la que se realizan las últimas pruebas antes de la puesta en marcha. En cada fase, se abordan las actividades clave y se explican los entregables / productos .

bloques de construcción de diagramas de procesos y datos

Actividades secuenciales

Las actividades secuenciales son aquellas que deben realizarse en un orden predefinido. Se conectan mediante una flecha, lo que indica que deben seguirse en esa secuencia. Tanto las actividades como las subactividades pueden modelarse de forma secuencial. La Figura 1 muestra un diagrama de actividades con una actividad y dos subactividades secuenciales. Un ejemplo especial de actividades secuenciales son los estados de inicio y fin, que también se ilustran en la Figura 1.

En la Figura 2 se ilustra un ejemplo práctico. Este ejemplo se basa en el flujo de trabajo de captura de requisitos en la ingeniería web con UML. La actividad principal, el modelado de usuarios y dominios, consta de tres actividades que deben realizarse en un orden predefinido.

1: Actividades secuenciales
2: Ejemplo
3: Actividades sin orden específico
4: Ejemplo

Actividades no ordenadas

Las actividades no ordenadas se utilizan cuando las subactividades de una actividad no tienen una secuencia predefinida para su ejecución. Solo las subactividades pueden ser no ordenadas. Las actividades no ordenadas se representan como subactividades sin transiciones dentro de una actividad, como se muestra en la Figura 3.

En ocasiones, una actividad consta de subactividades tanto secuenciales como no secuenciales. La solución a este problema de modelado consiste en dividir la actividad principal en distintas partes. La Figura 4 ilustra un ejemplo que aclara la necesidad de poder modelar actividades no secuenciales. El ejemplo se basa en el flujo de trabajo de análisis de requisitos del Proceso Unificado. La actividad principal, «describir los requisitos candidatos», se divide en dos partes. La primera es una actividad secuencial. La segunda consta de cuatro actividades que no requieren secuencia para ejecutarse correctamente.

Actividades simultáneas

Las actividades pueden desarrollarse simultáneamente. Esto se gestiona mediante bifurcaciones y uniones. Al representar las actividades en paralelo en el diagrama, conectadas con una barra de sincronización, se pueden bifurcar varias actividades. Posteriormente, estas actividades simultáneas pueden volver a unirse utilizando la misma barra de sincronización. Tanto las actividades como las subactividades pueden desarrollarse simultáneamente. En el ejemplo de la Figura 5, la Actividad 2 y la Actividad 3 son actividades simultáneas.

En la Figura 6 se muestra un fragmento del proceso de captura de requisitos. Dos actividades, la definición de los actores y la definición de los casos de uso, se llevan a cabo simultáneamente. La razón para realizar estas actividades de forma simultánea es que la definición de los actores influye considerablemente en los casos de uso, y viceversa.

5: Actividades simultáneas
6: Ejemplo
7: Actividades condicionales
8: Ejemplo

Actividades condicionales

Las actividades condicionales son aquellas que solo se ejecutan si se cumple una condición predefinida. Esto se representa gráficamente mediante una rama. Las ramas se ilustran con un rombo y pueden tener transiciones de entrada y salida. Cada transición de salida tiene una condición, que es una expresión booleana que determina la dirección a seguir. Tanto las actividades como las subactividades pueden modelarse como actividades condicionales. En la Figura 7 se ilustran dos actividades condicionales.

En la Figura 8 se ilustra un ejemplo práctico. Un análisis de requisitos comienza con el estudio del material. A partir de este estudio, se decide si se realiza o no una sesión exhaustiva de obtención de requisitos. La condición para no realizar esta sesión se representa a la izquierda de la rama, concretamente [requisitos claros]. Si no se cumple esta condición, [de lo contrario], se sigue la otra flecha.

La integración de ambos tipos de diagramas es bastante sencilla. Cada acción o actividad da como resultado un concepto. Estos se conectan mediante una flecha punteada a los artefactos producidos, como se muestra en la Figura 9. En esta imagen, los conceptos y las actividades son abstractos.

En la Tabla 1 se presenta una tabla genérica con la descripción de las actividades, subactividades y su relación con los conceptos. En la sección 5 se incluyen ejemplos de diagramas de procesos y datos, así como de tablas de actividades.

Tabla 1: Tabla de actividades

Ejemplo de un diagrama de proceso-datos

En la Figura 10 se ilustra un ejemplo de diagrama de proceso-datos. Se trata de un ejemplo de la fase de orientación de un proyecto complejo en un método de ingeniería web. ^{[ 1 ]}

Cabe destacar el uso de conceptos abiertos y cerrados. Dado que la gestión de proyectos no se encuentra dentro del alcance de esta investigación, el concepto de GESTIÓN DE CONTROL no se ha desarrollado. Sin embargo, en un proyecto complejo, la GESTIÓN DE RIESGOS es de suma importancia. Por lo tanto, se optó por desarrollar el concepto de GESTIÓN DE RIESGOS.

Figura 10: Ejemplo de diagrama de proceso-datos - Fase de orientación en un proyecto complejo

En la Tabla 2 se describen las actividades y subactividades, y su relación con los conceptos.

Tabla 2: Actividades y subactividades en una fase de orientación compleja

Véase también

Referencias

^ I. Van de Weerd, J. Souer, J. Versendaal y Sjaak Brinkkemper (2005). Ingeniería de Requisitos Situacionales de Implementaciones de Gestión de Contenidos Web . PRES2005.

[WSVB-1] I. Van de Weerd, J. Souer, J. Versendaal y Sjaak Brinkkemper (2005). Ingeniería de Requisitos Situacionales de Implementaciones de Gestión de Contenidos Web . PRES2005.

[ 1 ]