Introducción
Un sistema se puede definir como un grupo de elementos interdependientes o que interactúan regularmente formando un todo. Para la clasificación de estos existen dos categorías básicas, las cuales son: Sistemas naturales, que a su vez se dividen en sistemas físicos y vivientes, y Sistemas hechos por el hombre, de los cuales existe una gran diversidad de sistemas construidos, organizados y mantenidos por humanos, tales como: sistemas sociales, sistemas de transporte, sistemas de comunicación, sistemas de manufactura, sistemas financieros, entre otros.
En la actualidad, la mayoría de estos sistemas incluyen las computadoras, pero es importante señalar que dichos sistemas estaban antes de que existieran las mismas; de hecho, algunos sistemas continúan por completo sin computarizar y podrían permanecer así durante muchas décadas más. Otros contienen a la computadora como componente, pero también incluyen uno o más componentes no computarizados (o manuales).
Los sistemas automatizados son sistemas hechos por el hombre que interactúan o son controlados por una o más computadoras. Aunque hay diferentes tipos de sistemas automatizados, todos tienden a tener componentes en común, como hardware, software, etc.
Por otra parte, es importante saber que un sistema de información no es más que un conjunto u ordenación de elementos organizados para llevar a cabo algún método, procedimiento o control mediante el proceso de información.
El análisis y diseño de sistemas se basa en examinar la situación de una empresa con el propósito de mejorar con métodos y procedimientos más adecuados.
Metodología de análisis
Modelo Esencial
Es un modelo de lo que el sistema debe hacer para satisfacer los requerimientos del usuario, diciendo lo mínimo posible acerca de como se implanta.
Específicamente, esto significa que cuando el analista habla con el usuario acerca de los requerimientos del sistema, debe evitar describir implantaciones específicos de procesos (burbujas en un diagrama de flujo de datos) en el sistema; es decir, no debe mostrar las funciones del sistema que están siendo realizadas por humanos o por sistemas de cómputo existentes. Como lo ilustran las siguientes figuras, ésta opción arbitraria de cómo podría implantarse el sistema; pero esta decisión debería retrasarse hasta que haya comenzado la actividad de diseño.
Figura 1: Modelo que muestra como hará su labor una función
Figura 2: Muestra un Modelo esencial más apropiado de lo que la función del sistema debe realizar sin importar su implantación final.
Lo mismo se da para los flujos y almacenes de datos: el modelo esencial debe describir el contenido de los flujos o almacenes de datos, sin describir el medio (por ejemplo, disco o cinta) u organización física de los datos.
El modelo esencial consiste en dos componentes principales:
1.- Modelo ambiental
2.- Modelo de comportamiento
Es importante desarrollar el modelo esencial de un sistema, pues muchos sistemas de información grandes tienen una vida media de unos 10 a 20 años. Durante ese período se puede esperar que el hardware mejore por lo menos por un factor de mil.
1.- Modelo ambiental
Para el analista de sistemas, la labor más difícil en la especificación de un sistema es a menudo determinar qué es parte del sistema y qué no.
Así, el primer modelo importante que se debe desarrollar como analista es uno que no haga más que definir las interfaces entre el sistema y el resto del universo, es decir, el ambiente. Por razones obvias, este modelo se conoce como el modelo ambiental. Por lo tanto, se necesita saber qué información entra al sistema desde el ambiente exterior, y qué información produce como salida al ambiente externo.
Otro aspecto crítico del modelo ambiental consiste en identificar los acontecimientos que ocurren en el ambiente al cual debe responder el sistema. No para todos los acontecimientos, ya que el ambiente en su totalidad genera un número infinito de acontecimientos. Sólo importan aquellos que ocurren en el ambiente exterior y los que requieren una respuesta del sistema.
En un sistema grande se puede tomar en cuenta una cantidad de factores cuando se están escogiendo las perspectivas del proyecto. Entre los más importantes están los siguientes:
El deseo del usuario de lograr cierta participación en el mercado para el producto, o incrementarla a más de su nivel actual. Esto se puede hacer ofreciendo un nuevo producto o una mayor funcionalidad de uno existente.
La legislación establecida por el gobierno federal, estatal, o de la ciudad. Por ejemplo tendría que hacerse un nuevo sistema para considerar los cambios en las leyes sobre impuestos.
Deseo del usuario por minimizar gastos operativos de alguna área de su negocio. La mayor parte de las organizaciones que han tenido computadoras instaladas durante 10 años o más ya aprovecharon las oportunidades obvias de reducir el personal de oficina.
Deseo del usuario para lograr alguna ventaja estratégica para la línea de productos o áreas de negocios que opera. Un buen ejemplo de estos son las líneas aéreas donde mejor información acerca de tendencias del mercado y preferencias de los clientes pueden llevar a costos de pasajes e itinerarios de aerolíneas más eficientes.
2.- Modelo de comportamiento
Dentro del modelo de comportamiento se involucrará el desarrollo de un diagrama de flujo de datos.
Para explicar este modelo se utilizará el enfoque de partición por acontecimiento, el cual incluye los siguientes cuatro pasos:
1. Se dibuja una burbuja, o proceso, para cada acontecimiento de la lista.
2. La burbuja se nombra describiendo la respuesta que el sistema debe dar al acontecimiento asociado.
3. Se dibujan las entradas y salidas apropiadas de tal forma que la burbuja pueda dar la respuesta requerida, y se dibujan los almacenes, como sea apropiado, para la comunicación entre burbujas.
4. El borrador de DFD que resulta se compara con el diagrama de contexto y la lista de acontecimientos para asegurar que está completo y sea consistente.
El primer paso es directo y mecánico: si existen 25 acontecimientos en la lista, se deben dibujar 25 burbujas.
El segundo paso también es directo y mecánico: a cada burbuja se le da un nombre apropiado, basado en la respuesta requerida. Esto significa que se debe examinar el acontecimiento y preguntar qué respuesta debe dar el sistema a este Acontecimiento.
El tercer paso definitivamente no es mecánico, pero usualmente es bastante directo: Para cada burbuja dibujada, identifique las entradas que requiere para efectuar su trabajo. Identifique las salidas que cada una produce e identifique los almacenes a los que cada burbuja debe tener acceso. Esto normalmente se hace entrevistando al usuario o usuarios apropiados y concentrándose en cada acontecimiento y su burbuja asociada. Las preguntas son: ¿Qué necesita esta burbuja para hacer su trabajo? y ¿Qué salidas genera?
En muchos casos el acontecimiento está determinado por el flujo; esto significa que el sistema detecta la ocurrencia de un acontecimiento por la llegada de algún dato de un terminador externo, lo que quiere decir que se pueden requerir entradas adicionales (de otros terminadores, y de almacenes de datos) para que un proceso produzca su salida requerida.
De manera similar, como parte de la respuesta dibuje las salidas adecuadas producidas por el proceso. En muchos casos, esto implicar devolver salidas a los terminadores fuera del sistema; sin embargo, puede también involucrar salidas que se envían a los almacenes de datos, para ser usadas como entradas de otros procesos.
Los dos casos anteriores se ilustran en la figura siguiente:
Figura 3: que muestra entradas y salidas de un proceso
El cuarto paso es una actividad de verificación de consistencia: Verifique cada entrada del diagrama de contexto para ver si está conectada con alguna entrada de alguno de los procesos del DFD preliminar, y verifique también que cada salida producida por algún proceso en el DFD preliminar se envíe a un almacén o sea una salida externa incluida en el diagrama de contexto.
Existen dos casos especiales, el primero de ellos son los acontecimientos únicos que causan respuestas múltiples y, el segundo caso comprende los acontecimientos múltiples que causan la misma respuesta.
En el primer caso, un solo acontecimiento puede causar múltiples respuestas, cada una de las cuales se modela con su propia burbuja en el DFD preliminar. Sólo es apropiado si todas las respuestas usan el mismo flujo de datos de entrada, y sólo si todas las respuestas son independientes entre sí.
De manera inversa, habrá situaciones ocasionales en las que un proceso se asocia con más de un acontecimiento. Es válido y apropiado sólo si la respuesta de la burbuja es idéntica para los diversos acontecimientos, y sólo si los datos de entrada y salida son idénticos para las diversas respuestas a acontecimientos.
Obsérvese que en los ejemplos anteriores ninguno de los procesos en el diagrama de flujo de datos preliminar está conectado con otro; las burbujas no se comunican directamente con otras. En vez de eso se comunican entre sí a través de otros almacenes de datos.
Una vez hecho esto se procede a un proceso de limpieza, el cual se describirá posteriormente, para producir un modelo bien organizado del proceso y un modelo de datos para presentarlo al usuario final. Este enfoque se llamó partición por acontecimientos.
Diseño de sistemas
Antes de entrar en materia es importante hacer énfasis en cierto aspecto fundamental del Diseño de Sistemas y es que la labor del analista y la del diseñador no siempre se pueden separar debido a que, el analista debe asegurarse de entender los requerimientos del usuario, mientras que el diseñador debe asegurar que dichos requerimientos se puedan implantar de manera realista con la tecnología computacional actual.
Existe otra razón para tener interés en el diseño de sistemas, sobre todo en los sistemas pequeños y medianos, a menudo se espera que el mismo individuo documente los requerimientos del usuario y además desarrolle el diseño.
La actividad de diseño involucra el desarrollo de una serie de modelos. Los modelos más importantes para el diseñador son el modelo de implementación de sistemas y el modelo de implementación de programas. El modelo de implantación de sistemas se divide luego en un modelo de procesador, y uno de tareas.
En el nivel del modelo del procesador, el diseñador del sistema trata principalmente de decidir como asignar el modelo esencial a los distintos procesadores (CPU) y como deben comunicarse entre sí. Existe típicamente una variedad de opciones:
El modelo esencial completo se le puede asignar a un solo procesador (solución de computadora principal).
Cada burbuja de la figura 0 del DFD del modelo esencial se puede asignar a un procesador distinto (solución distribuida).
Se pude escoger una combinación de computadoras principales, minis y micros para minimizar costos, maximizar confiabilidad o lograr algún otro objetivo.
Así como se deben asignar procesos a los componentes apropiados de hardware, los almacenes de datos se deben igualmente asignar. El diseñador debe de decidir si un almacén se realizará como base de datos en el procesador 1 o el 2. Dado que la mayor parte de los almacenes se comparten entre muchos procesos, también debe decidir si se deben asignar copias del almacén a diferentes procesadores.
En el nivel del modelo de tarea, el diseñador debe, procesador por procesador, asignar procesos y almacenes a las tareas individuales de cada uno. Los procesos dentro de un mismo procesador pueden tener necesidad de comunicarse mediante alguna forma de protocolo de comunicación entre tareas. El mecanismo para hacerlo varía de un proveedor a otro, pero casi siempre se realiza a través del sistema operativo del proveedor.
En el modelo de implementación de programas se llega al nivel de una tarea individual. Dentro de una tarea individual, la computadora opera de una manera no sincronizada: sólo se pueden llevar a cabo una actividad a la vez. El modelo más común de organización de la actividad en una sola unidad sincronizada es el diagrama de estructura, que muestra la organización jerárquica de módulos dentro de una tarea.
DIAGRAMAS DE FLUJO DE DATOS (DFD).
El diagrama de flujo de datos (DFD), es una herramienta que permite visualizar un sistema como una red de procesos funcionales, conectados entre sí por "conductos" y "tanques de almacenamiento" de datos. Siendo éste, una de las herramientas más comúnmente usadas, sobre todo por sistemas operacionales en los cuales las funciones del sistema son de gran importancia y son más complejos que los datos que éste maneja.
Es importante tener en mente: que los DFD no sólo se pueden utilizar para modelar sistemas de sistemas de proceso de información, sino también como manera de modelar organizaciones enteras, es decir, como una herramienta para la planeación estratégica y de negocios.
Los componentes de un diagrama típico de flujo de datos:
Proceso.
Flujo.
Almacén.
Terminador.
Proceso.
El primer componente del DFD se conoce como proceso. Los sinónimos comunes son burbuja, función, transformación. El proceso muestra una parte del sistema que transforma entradas en salidas. El proceso se representa gráficamente como un círculo, como se muestra en figura 4.1.1(a). Algunos analistas prefieren usar un óvalo o un rectángulo con esquinas redondeadas, como se muestra en la figura 4.1.1 (b). Y otros prefieren usar un rectángulo, como se muestra en la figura 4.1.1 (c). Las diferencias entre estas tres formas son puramente cosméticas, aunque obviamente es importante usar la misma forma de manera consistente para representar todas las funciones de un sistema.
Figuras 4.1.1 ( a) (b) (c)
En el proceso se nombra o describe con una sola palabra, frase u oración sencilla. Un buen nombre para un proceso generalmente consiste en una frase verbo-objeto tal como validar entradas o calcular impuesto. En algunos casos, el proceso contendrá el nombre de una persona o un grupo (por ejemplo, un departamento o una división de una organización), o de una computadora o un aparato mecánico.
Flujo.
Un flujo se representa gráficamente por medio de una flecha que entra o sale de un proceso; un ejemplo se muestra en la figura 4.1.2. El flujo se usa para describir el movimiento de bloques o paquetes de información de una parte del sistema a otra.
Figura 4.1.2: Ejemplo de un flujo.
En la mayoría de los sistemas que modele como analista, los flujos realmente representan datos, es decir, bits, caracteres, mensajes, números de punto flotante y los diversos tipos de información con los que las computadoras pueden tratar.
El flujo de la figura 4.1.2 tiene nombre. El nombre representa el significado del paquete que se mueve a lo largo del flujo. Un corolario de esto es que el flujo sólo lleva un tipo de paquete, como lo indica su nombre.
Los flujos muestran también la dirección: una cabeza de flecha en cualquier extremo (o posiblemente ambos) del flujo indica si los datos (o el material) se está moviendo hacia adentro o hacia fuera de un proceso (o ambas cosas).
El flujo que se muestra en la figura 4.1.3 (a) por ejemplo, indica claramente que el número se está mandando hacia el proceso denominado Validar números telefónicos, y el flujo denominado honorarios de entrega de choferes de la figura 4.1.3 (b) claramente indica que es una salida generada por el proceso Generar honorarios de entrega de choferes. Los datos que se mueven a lo largo de dicho flujo viajarán ya sea a otro proceso (como entrada) o a un almacén o a un terminador.
El flujo de dos cabezas que se muestra en la figura 4.1.3 (c) es un diálogo, es decir, un empacado conveniente de dos paquetes de datos (una pregunta y una respuesta) el mismo flujo. En el caso de un diálogo, los paquetes de cada extremo de la flecha deben nombrarse, como se ilustra en la figura 4.1.3 (c).
Figuras 4.1.3: (a):Flujo de entrada.
Figura 4.1.3 (b): Flujo de salida.
Figura 4.1.3(c): Flujo de diálogo.
Almacén.
El almacén se utiliza para modelar una colección de paquetes de datos en reposo. Se denota por dos líneas paralelas. De modo característico el nombre que se utiliza para identificar al almacén es el plural del que se utiliza para los paquetes que entran y salen del almacén por medio de flujos.
Para el analista con conocimiento de proceso de datos es tentador referirse a los almacenes como archivos o base de datos; pero un almacén también pudiera consistir en datos almacenados en tarjetas perforadas, microfilm, microfichas, discos ópticos, etc. y un almacén también puede ser un conjunto de fichas de papel en una caja de cartón, nombres y domicilios en un directorio, diversos archivos en un archivero, o varias formas no computarizadas.
Aparte de la forma física que toma el almacén, también existe la cuestión de su propósito: ¿Existe el sistema por causa de un requerimiento fundamental del usuario o por algún aspecto conveniente de la realización del sistema? En el primer caso, la base de datos existe como un área de almacenamiento diferida en el tiempo, necesaria entre dos procesos que ocurren en momentos diferentes.
Los almacenes se conectan por flujos a los procesos. Así, el contexto en el que se muestra en un DFD es uno de los siguientes (o ambos):
Un flujo desde un almacén.
Un flujo hacía un almacén.
Terminador
El terminador gráficamente se representa como un rectángulo. Los terminadores representan entidades externas con las cuales el sistema se comunica. Comúnmente, puede ser una persona, o un grupo, por ejemplo, una organización externa o una agencia gubernamental, o un grupo o departamento que esté dentro de la misma compañía u organización, pero fuera del control del sistema que se está modelando. En algunos casos, un terminador puede ser otro sistema, como algún otro sistema computacional con el cual se comunica éste.
Existen tres cosas importantes que debemos recordar acerca de los terminadores:
Son externos al sistema que se está modelando.
Es evidente que ni el analista ni el diseñador del sistema están en posibilidades de cambiar los contenidos de un terminador o la manera en que trabaja.
Las relaciones que existan entre los terminadores no se muestran en el modelo de DFD.
Caso Práctico (Ejercicio). Usando el DFD
Una forma de comprender estas ideas sobre el análisis de sistemas es explicando en forma detallada un caso práctico de un sistema real. Nuestro caso de estudio describe los requerimientos de computarización de las actividades de proceso de información de YOURDON Press.
Se abarcaran las siguientes secciones:
El modelo ambiental del sistema.
El modelo de comportamiento.
El modelo de implantación del usuario.
El Modelo Ambiental.
La declaración de propósitos.
El propósito del Sistema de Información de YOURDON Press (YPIS) es almacenar la información necesaria para vender libros a los clientes. Esto incluye ingreso de pedidos, facturación, generación de documentos de envío, control de inventarios y producción de reportes de regalías por derechos de autor y reportes de contabilidad.
La lista de acontecimientos.
La lista de acontecimientos del sistema YPIS consiste en 40 acontecimientos. La mayoría están dirigidos por flujos, aunque la mayoría de los que involucran al departamento de contabilidad son temporales. Los acontecimientos se listan a continuación; los temporales se marcan con una "T" luego de su descripción.
El cliente envía su pago.
El cliente pide información sobre algún libro (precio, etc.).
El cliente pide permiso de devolver un libro
El cliente pregunta sobre el status de algún pedido.
El cliente pregunta sobre el status de alguna factura.
El cliente requiere de una declaración (mensual). (T)
El cliente pide un recordatorio de un crédito.
El cliente desea un cheque de reembolso.
El departamento de contabilidad requiere de recibos (diarios) de efectivo. (T)
El departamento de contabilidad requiere de reportes de ventas (diarios). (T)
El departamento de contabilidad requiere de un reporte (mensual) de ventas netas.(T)
El departamento de contabilidad requiere de un reporte (trimestral) de regalías por derechos de autor. (T)
El departamento de contabilidad requiere de datos (mensual) de inventario. (T)
El departamento de contabilidad requiere de un reporte (mensual) de comisiones sobre ventas. (T)
La gerencia fija un nuevo límite de crédito para un cliente.
El departamento de contabilidad requiere un reporte (mensual) de cuentas por pagar retrasadas.
La imprenta da una cotización de pedido de impresión
La administración autoriza un pedido de impresión.
La imprenta notifica la cantidad exacta de impresos y fechas de entrega.
La imprenta envía factura por concepto de trabajo de impresión.
La administración solicita cotización de un pedido de impresión.
El departamento de mercadeo pide etiquetas de envío de la base de datos de clientes.
El departamento de mercadeo requiere de estadísticas sobre las ventas de libros.
El departamento de mercadeo necesita una fecha de disponibilidad de nuevos títulos.
Los editores anuncian un nuevo título.
Los autores necesitan un reporte trimestral de utilidades por concepto de derechos de autor. (T)
La bodega necesita datos de envío y etiquetas. (T)
La bodega recibe libros de la imprenta.
La bodega recibe devoluciones de libros de un cliente.
La bodega hace un inventario físico (mensual).
La bodega envía un pedido a un cliente.
La bodega anuncia que un libro se ha agotado.
El departamento de adquisiciones anuncia el proyecto de un nuevo libro.
Un vendedor ingresa un pedido de parte de un cliente.
El departamento de mercadeo declara que un libro está agotado.
El cliente notifica un cambio de domicilio.
El autor notifica un cambio de domicilio.
El cliente elige participar en el plan de agencia.
Se necesita enviar facturas a un cliente. (T)
Modelo de Comportamiento.
El modelo preliminar de comportamiento: diagramas de flujo de datos.
Cada uno de los 40 acontecimientos listados en la sección del modelo ambiental tiene un diagrama de flujo de datos asociado.
Al dibujar los DFD preliminares se tomó nota de los errores que se encontraron y los cambios que se tenían que hacer en otras partes del modelo; estas notas se listan debajo de cada DFD. La razón de esto es enfatizar que en un proyecto real el analista raramente dibuja un DFD perfecto al primer intento; después de pensar sobre el sistema, y luego de entrevistas de seguimiento con el usuario, es inevitable que se encuentren errores en el DFD que se está examinando o en alguna otra parte del modelo del sistema.
DIAGRAMAS DE LOS ACONTECIMIENTOS:
Acontecimiento 1.
Acontecimiento 2:
Acontecimiento 3:
Acontecimiento 4:
Acontecimiento 5:
Acontecimiento 6:
Acontecimiento 7:
Acontecimiento 8:
Acontecimiento 9:
Acontecimiento 10:
Acontecimiento 11:
Acontecimiento 12:
Acontecimiento 13:
Acontecimiento 14:
Acontecimiento 15:
Acontecimiento 16:
Acontecimiento 17:
Acontecimiento 18:
Acontecimiento 19:
Acontecimiento 20:
Acontecimiento 21:
Acontecimiento 22:
Acontecimiento 23:
Acontecimiento 24:
Acontecimiento 25:
Acontecimiento 26:
Acontecimiento 27:
Acontecimiento 28:
Acontecimiento 29:
Acontecimiento 30:
Acontecimiento 31:
Acontecimiento 32:
Acontecimiento 33:
Acontecimiento 34:
Acontecimiento 35:
Acontecimiento 36:
Acontecimiento 37:
Acontecimiento 38:
Acontecimiento 39:
Acontecimiento 40
Modelo final del comportamiento: diagramas de flujo de datos (DFD).
El modelo inicial del comportamiento mostrado en las últimas páginas se transformó en un conjunto de DFD por niveles. La nivelación ascendente produjo el diagrama de figura 1 que se muestra a continuación. Las figuras subsecuentes muestran los acontecimientos que se agruparon. En un caso, un solo acontecimiento (el 26) no se niveló de manera ascendente, y aparece como el proceso 5 de la figura 1. Y en un caso (el acontecimiento 1) se ocupó una nivelación descendente adicional debido a la complejidad del proceso.
Conclusiones
Una vez finalizado el presente trabajo de investigación es posible concluir lo siguiente:
1. Los sistemas de información son herramientas necesarias que permiten a las empresas obtener ventajas competitivas mediante su implantación y uso apoyando el máximo nivel de la organización.
2. Los sistemas de información organizacionales, son indispensables para automatizar los procesos operativos y para alcanzar la evolución hacia fuentes importantes de información que sirven de base para la toma de decisiones.
3. La comprensión básica de los sistemas de información facilita la captación o entendimiento en cualquier otra área funcional de la empresa.
4. La cultura informática es de vital importancia en las organizaciones, ya que sin ella seria imposible construir un escenario que permita y de las condiciones necesarias para que los sistemas de información logren los objetivos citados anteriormente.
5. Ignorar la información o resistirse al cambio de la misma representa un riesgo muy grande de fracaso para una organización debido a las amenazas del mercado y a la incapacidad de competir.
Bibliografía
Para realizar el presente trabajo de investigación, se recolectó información de las siguientes páginas electrónicas:
www.monografias.com
www.elprisma.com
http://sistemas.itlp.edu.mx/tutoriales/analisis/index.htm
Autor:
Balza, Leman
Gallardo, José
Gómez, Olga P.
Hernández, Ritcelys
Marín, Ronny
Medina, Audreis
Enviado por:
Profesor:
MSc. Ing. Iván Turmero
UNIVERSIDAD NACIONAL EXPERIMENTAL POLITÉCNICA
"ANTONIO JOSÉ DE SUCRE"
VICE-RECTORADO PUERTO ORDAZ
DEPARTAMENTO DE INGENIERÍA INDUSTRIAL
CÁTEDRA: SISTEMAS DE INFORMACIÓN
Ciudad Guayana, Abril de 2007