Diagrama de contexto de sistema

De Wikipedia, la enciclopedia libre
Ejemplo de diagrama de contexto de sistema[1]

Un Diagrama de Contexto de Sistema (DCS) en Ingeniería de software e Ingeniería de sistemas es un diagrama que define los límites entre el sistema, o parte del sistema, y su ambiente, mostrando las entidades que interactúan con él.[2]​ Este diagrama es una vista de alto nivel de un sistema. Es similar al Diagrama de bloques.

Vista General[editar]

Un diagrama de contexto de sistema muestra un sistema, usualmente basado en software, como un completo y sus entradas y salidas desde y hacia factores externos. De acuerdo a Kossiakoff y Sweet (2011):[3]

Diagrama de contexto de sistema… representa todas las entidades externas que podrían interactuar con un sistema… Dicho diagrama retrata el sistema en el centro, sin detalles de su estructura interna, rodeado por todos los sistemas, ambientes y actividades con las que interactúa. El objetivo del diagrama es enfocar la atención en los factores externos y eventos que deberían considerarse en el desarrollo de un set completo de requisitos y restricciones del sistema.

Los diagramas de contexto de sistema son usados tempranamente en un proyecto para obtener un acuerdo del alcance de la investigación.[4]​ Son típicamente incluidos en documentos de requisitos. Estos diagramas deben ser leídos por todas las partes interesadas, por lo que deben ser escritos en lenguaje sencillo, para la comprensión de todas las partes.

Bloques de construcción[editar]

Diagramas de contexto pueden ser desarrollados con el uso de dos tipos de bloques de construcción:

Entidades (Actores): cuadros etiquetados; uno en el centro representando el sistema, y varios cuadros alrededor para los factores externos.

Relaciones: líneas etiquetadas entre las entidades y el sistema.

Por ejemplo, “cliente entrega orden.” Diagramas de contexto también pueden utilizar distintos tipos de dibujo para representar entidades externas. Pueden usar óvalos, figuras de línea, imágenes, autoformas o cualquier otra representación que presente un significado. Árboles de decisiones y almacenamiento de datos son representados en diagramas de flujo de sistemas.

Un diagrama de contexto también puede enlistar las clasificaciones de las entidades externas como una de un set de categorías simples,[5]​ lo que añade claridad al nivel de participación de las entidades con respecto al sistema. Esas categorías incluyen:

Activo: entidades externas dinámicas que frecuentemente inician eventos para lograr algún objetivo o propósito.

Pasivo: Entidades externas estáticas que no interactúan frecuentemente con el sistema.

Cooperativo: Entidades externas predecibles que son utilizadas por el sistema para alcanzar algún resultado deseado.

Autónoma (Independiente): Entidades externas que están separadas del sistema, pero que lo afectan indirectamente, a través de restricciones impuestas o influencias similares.

Alternativas[editar]

Los mejores diagramas de contexto de sistema son utilizados para mostrar como un sistema interopera en un nivel muy alto, o como los sistemas operan e interactúan lógicamente. El diagrama de contexto del sistema es una herramienta necesaria para desarrollar la interacción de base entre los sistemas y los actores; actores y sistema o sistema con sistema. Alternativas al diagrama de contexto son:

Ejemplo de Diagrama de interconexión de arquitectura.[6]

Diagrama de interconexión de arquitectura.[6]

Lienzo de modelo de negocios: una plantilla de administración estratégica para desarrollar nuevos o documentar modelos de negocios existentes.

Modelo de información Enterprise: este tipo de modelo de datos, de acuerdo con Simsion (2005) puede contener de 50 a 200 clases de entidades, que resultan de específicos “generalización de alto nivel en modelos de datos”.[7]

Diagrama de contexto de alto nivel IDEF0: El proceso IDEF0 comienza con la identificación de la función principal a ser descompuesta. Esta función es identificada en un “Diagrama de contexto de alto nivel” que define el alcance de un análisis IDEF0 particular.

Diagramas de problema (Marco de problema): En adición al tipo de cosas mostradas en un diagrama de contexto, un diagrama de problema muestra requisitos y sus referencias.

Diagrama de casos de uso: Uno de los diagramas UML(Lenguaje unificado de modelado). También representa el alcance del proyecto a un nivel similar de abstracción. Sin embargo, tiende a concentrarse más en los objetivos de los actores que interactúan con el sistema, y no especifica ninguna solución.

Varios de estos diagramas funcionan bien siempre y cuando exista un número limitado de interconexiones a mostrar. Cuando existen 20 o más interconexiones a mostrar, los diagramas se vuelven muy complejos y difíciles de leer.[6]

Referencias[editar]

  1. NDE Project Management (NPOESS) Data Exploitation web site. 2008.
  2. Manoj Kumar Choubey (2012) IT Infrastructure and Management (For the GBTU and MMTU). p. 53
  3. Alexander Kossiakoff, William N. Sweet (2011). Systems Engineering: Principles and Practices p. 266
  4. Richard Wiener (1998) Journal of Object-oriented Programming. Vol 11. p. 68
  5. Suzanne Robertson, James C. Robertson (2006) Mastering the Requirements Process. Pearson Education, 17 mrt. 2006
  6. a b c US Department of Transportation, Office of Operations (2006)Regional ITS Architecture Guidance Document. July 2006
  7. Graeme C. Simsion, Graham C. Witt (2005). Data Modeling Essentials. p. 512.