ANÁLISIS DE SISTEMAS UNIDAD 3. METODOLOGIA DEL ANÁLISIS 3.1 Modelo Esencial El modelo esencial del sistema 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 especificas 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 computo existentes. Como lo ilustran las figuras 3.1.1(a), ésta opción arbitrarias de cómo podría implantarse el sistema; pero esta decisión debería retrasarse hasta que haya comenzado la actividad de diseño.
Figuras: 3.1.1(a):Modelo que muestra como hará su labor una función La figura 3.1.1(b) muestra un modelo esencial más apropiado de lo que la función del sistema debe realizar sin importar su implantación final.
Figura 3.1.1(b): Un modelo de cual es la función del sistema
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 Recuerde que 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.
3.2 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; después de todo, el ambiente en su totalidad genera un número infinito de acontecimientos. Sólo nos preocupan aquellos que (1) ocurren en el ambiente exterior y (2) 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. A continuación se presentan dos tópicos importantes en el modelo ambiental: Herramientas usadas para definir el ambiente Construcción del modelo ambiental
3.2.1 Herramientas usadas para definir el ambiente El modelo ambiental consta de tres componentes: 1.- Declaración de propósitos. 2.- Diagrama de contexto. 3.- Lista de acontecimientos. La declaración de propósitos consiste en la declaración textual breve y concisa del propósito del sistema, dirigida al nivel administrativo superior, la administración de los usuarios, y otros que no están directamente involucrados con el desarrollo del sistema. El siguiente es un ejemplo de la declaración de propósito típica: El propósito del Sistema de Procesamiento de Libros Ajax es manejar todos los detalles de los pedidos de los libros de los clientes, además del envío, facturación y cobro retroactivo a clientes con facturas vencidas. La información acerca de los pedidos de los libros debe estar disponible para otros sistemas, tales como mercadeo, ventas y contabilidad. El diagrama de contexto es un caso especial de diagrama de flujo de datos, en donde una sola burbuja representa todo el sistema. La figura 3.2.1 muestra un diagrama de contexto de un sistema de pedidos de libros.
Figura 3.2.1: Diagrama de contexto
El diagrama de contexto enfatiza varias características importantes del sistema: Las personas, organizaciones y sistemas con los que se comunica el sistema. Se conocen como terminadores. Los datos que el sistema recibe del mundo exterior y que deben procesarse de alguna forma. Los datos que el sistema produce y que se envían al mundo exterior. Los almacenes de datos que el sistema comparte con los terminadores. Estos almacenes de datos se crean fuera del sistema para su uso, o bien son creados en él y usados fuera. La frontera entre el sistema y el resto del mundo. La lista de acontecimientos es una lista narrativa de los estímulos que ocurren en el mundo exterior a los cuales el sistema debe responder. A continuación se muestra una lista de acontecimientos para el sistema de pedidos de libros. 1.- Un cliente hace un pedido (F). 2.- Un cliente cancela un pedido (F). 3.- La administración pide un reporte de ventas (T). 4.- Llega un pedido de reimpresión de un libro a la bodega (C). Obsérvese que cada acontecimiento se etiqueta como F,T,C. Con ello se muestra si es de tipo de flujo, temporal, o de control. El orientado a flujos es el que se asocia con un flujo de datos; es decir, el sistema se da cuenta de que ha ocurrido el acontecimiento cuando llega algún dato (o posiblemente varios). Los acontecimientos temporales arrancan con la llegada de un momento dado en el tiempo. Algunos ejemplos de acontecimientos temporales pudieran ser: A las 9:00 de la mañana se requiere un reporte diario de todos los pedidos de libros. Las facturas deben generarse a las 3:00 PM. Se deben generar reportes administrativos una vez por hora. Los acontecimientos de control deben considerarse un caso especial del acontecimiento temporal: un estímulo externo que ocurre en algún momento impredecible. A diferencia de un acontecimiento temporal normal, el acontecimiento de control no se asocia con el paso regular del tiempo, por lo que el sistema no puede anticiparlo utilizando un reloj interno.
3.2.2 Construcción del modelo ambiental Construcción del diagrama de contexto El diagrama de contexto consiste en terminadores, flujos de datos y flujos de control, almacenes de datos y un solo proceso que representa a todo el sistema. Se analizan uno por uno a continuación. La parte más fácil del diagrama de contexto es el proceso; como hemos visto,
consiste en una sola burbuja. El nombre dentro del proceso suele ser el nombre del sistema completo o un acrónimo convenido. En la figuras 3.2.2 se muestra un ejemplo.
Figura 3.2.2: Nombre tipico de proceso para un diagrama de contexto Los terminadores se representan con rectángulos en el diagrama de contexto. Se comunican directamente con el sistema a través de flujos de datos o de control, como muestra la figura 3.2.3(a),
Figura 3.2.3(a):Comunicación directa entre terminado y sistema o a través de almacenes externos, como se muestra en la figura 3.2.3(b).
Figura 3.2.3(b):Comunicación a través de un almacén externo Los terminadores no se comunican entre sí. En realidad, los terminadores si se comunican entre sí pero, dado que por definición son externos al sistema, la naturaleza y contenido de las interacciones terminador-terminador son irrelevantes para el sistema. Hay que tomar tres punto mas en consideración de los terminadores: 1. Algunos terminadores tienen un buen número de entradas y salidas. Para evitar un diagrama innecesariamente atiborrado conviene dibujar el terminador más de una vez. Los terminadores duplicados se marcan con un asterisco.
2. Cuando el terminador es una persona individual, generalmente es preferible indicar el rol que desempeña, más que su identidad. 3. Dado que estamos interesados en desarrollar un modelo esencial del sistema, es importante distinguir entre fuente y manejadores. Un manejador es un mecanismo, dispositivo, medio físico usado para transportar datos hacia o fuera del sistema. Dado que a menudo, dichos manejadores son familiares y visibles para los usuarios de la implantación actual de un sistema, existe la tendencia a mostrar al manejador, en lugar de la verdadera fuente de los datos. Los flujos que aparecen en el diagrama de contexto modelan datos que entran y salen del sistema, además de las señales de control que recibe o genera. Los flujos de datos se incluyen en el diagrama de contexto si se ocupan para detectar un acontecimiento en el ambiente al que deba responder el sistema, o si se ocupan (como datos) para producir una respuesta. Construcción de la lista de acontecimiento La lista de acontecimiento es un listado textual sencillo de los acontecimientos del ambiente a los cuales debe responder el sistema. Al crear la lista de acontecimiento se debe asegurar de distinguir entre un acontecimiento y un flujo relacionado con un acontecimiento. Por ejemplo, lo siguiente probablemente no sea un acontecimiento: "El sistema recibe el pedido del cliente". Mas bien, sea el flujo de datos de entrada mediante el cual el sistema se da cuenta de que ha ocurrido el acontecimiento. Un nombre más apropiado para el acontecimiento sería: "El cliente hace un pedido" La manera más fácil de identificar los acontecimientos para un sistema es visualizarlo en acción: examinar cada terminador y preguntar qué efecto pueden tener sus acciones sobre el sistema. La lista de acontecimiento debe incluir no sólo las interacciones normales ente el sistema y sus terminadores sino también situaciones de falla. Como señalan Paul Ward y Stephen Mellor en Structured Development for Real-Time System: Puesto que los terminadores están por definición fuera de las fronteras del intento de construcción de sistema representado por el modelo, los realizadores no pueden modificar la tecnología de los terminadores para mejorar su confiabilidad. En lugar de ello, deben construir respuestas para los problemas de los terminadores en el modelo esencial del sistema. Un enfoque útil para modelar respuestas a los problemas de terminadores es construir una lista de acontecimientos "normales" y luego preguntar, para cada acontecimiento, "¿Necesita el sistema responder si este acontecimiento deja de ocurrir como se espera?. Por ejemplo, nuestra lista de acontecimiento para el Sistema de Pedido de Libros Ajax incluía un acontecimiento llamado "el pedido de reimpresión de libro llega a la bodega". Pero ¿Qué tal si no llega a tiempo (por ejemplo, una semana después de la fecha prometida por el impresor)? ¿Qué
debería hacer el sistema?, Por lo que se necesitaría un acontecimiento adicional iniciado por el sistema para hacer que se comunique con el impresor y localice el origen del retraso.
3.3 Modelo de Comportamiento Dentro del modelo de comportamiento se involucrará el desarrollo de un diagrama de flujo de datos y un diagrama de entidad-relación preliminares, además de la elaboración de las entradas iniciales del diccionario. Para explicar el modelo de comportamiento utilizaremos 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, esto es, 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 ilustra en la figuras 3.3.1.
Figura 3.3.1:Figura 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: (1) acontecimientos únicos que causan respuestas múltiples y, (2) 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.
3.5 Diseño de Sistemas Como analista, puede no sentir interés por los detalles del diseño de sistemas o de programas; sin embargo, la labor de 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: tal vez le toque hacerlo. 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 confiabialidad 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. Obsérvese que 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.
3.6 Programación La programación comienza cuando termina la actividad de diseño. En esta fase se involucra la escritura de instrucciones en C++, Pascal, o algún otro lenguaje de programación para implantar lo que el analista ha especificado y el diseñador ha organizado en módulos. Como programadores se pueden enfrentar a los siguientes problemas: Productividad: esto es escribir más software, más rápidamente. La principal razón de esto es la enorme cantidad de sistemas y aplicaciones que siguen en espera en las grandes organizaciones. Eficiencia: la eficiencia es de gran importancia en muchos sistemas de tiempo real, y en sistemas que procesan grandes volúmenes de datos (ejemplo, sistemas en bancos, reservación en aerolíneas, compañías de bolsas y compañías de seguro). La meta de eficiencia usualmente entra en conflicto con otras metas discutidas: si se emplea mucho tiempo en la construcción de un sistema eficiente, es probable que sea menos mantenible y menos transportable, y que tenga más errores residuales sutiles, además de que tal vez reduzca la productividad de la persona que escribió el programa. Corrección: se podría argumentar que esto es lo más importante. Después de todo, si el programa no funciona correctamente, no importa que tan eficiente sea. Por ejemplo, se prefieren lenguajes de programación como Ada y Pascal si la corrección es de importancia crítica, en caso de que se estuviera construyendo sistemas de la Guerra de las Galaxias o el sistema de control para un reactor nuclear, porque son de "tipos rígidos". Portabilidad: en algunos ambientes esto es importante; el usuario puede desear ejecutar el mismo sistema en varios tipos distintos de computadoras. Los lenguajes de tercera generación (C, Pascal, FORTRAN, COBOL, etc.) son más portátiles que los de cuarta generación; aunque no existe un lenguaje universalmente portátil. Por ello, además del lenguaje de programación debemos preocuparnos por el estilo de programación, sí la portabilidad es un factor importante. Mantenibilidad: como los sistemas viven durante mucho tiempo, por lo tanto el software debe mantenerse.
3.7 Prueba En muchos casos, el analista trabaja de manera cercana con el usuario para desarrollar un conjunto eficaz y de gran alcance de casos de prueba basados en el modelo esencial y el modelo de implantación del usuario. Este proceso puede llevarse a cabo en paralelo con las actividades de implantación del diseño y de la programación, para que, cuando los programadores terminen de
escribir sus programas y de realizar sus propias pruebas locales, el equipo del analista/usuario esté listo con sus propios casos de prueba. Existen distintas estrategias de prueba, las dos más comunes se conocen como prueba ascendente y descendente. El enfoque ascendente empieza por probar módulos individuales separadamente (prueba de módulos). Luego, los módulos individuales se combinan para forma unidades que se probaran en masas (pruebas de subsistemas). Finalmente, todos los componentes del sistema se combinan para probarse (prueba del sistema). El enfoque de prueba descendente empieza con un esqueleto del sistema; es decir, la estrategia de prueba supone que se han desarrollado los módulos ejecutivos de alto nivel del sistema, pero que los de bajo nivel existen sólo como módulos vacíos; un ejemplo de módulo vacío es uno que no procesa nada, sino que simplemente termina luego de ser llamado. También existen diferentes tipos de pruebas, tales como: Prueba funcional: Su propósito es asegurar que el sistema realiza sus funciones normales de manera correcta. Así, los casos de prueba se desarrollan y se alimentan al sistema; las salidas se examinan para ver si son correctos. Prueba de recuperación: El propósito de este tipo de prueba es asegurar que el sistema pueda recuperarse adecuadamente de diversos tipos de fallas, como: fallas de hardware, fallas de corriente, fallas en el sistema operativo, etc. Prueba de desempeño: El propósito de este tipo de prueba es asegurar que el sistema pueda manejar el volúmen de datos y transacciones de entrada especificados en el módulo de implantación del usuario, además de asegurar que tenga el tiempo de respuesta requerido. Para poder realizar una excelente prueba se necesita de tres cosas: un plan de prueba, descripciones de pruebas y procedimiento de prueba. Un plan de prueba es un documento organizado que describe las actividades de prueba. Un documento de planeación de pruebas típico contendrá la siguiente información: Propósito de la prueba: cuál es el objetivo de la prueba, y qué parte del sistema se está probando. Localización y horario de la prueba: dónde y cuando se hará. Descripción de la prueba: descripción de las entradas que se proporcionarán al sistema, y las salidas y resultados que se anticipan. Procedimiento de prueba: descripción de cómo se deben preparar y presentar los datos de prueba al sistema; cómo capturar los resultados de salida, cómo analizar los resultados de las pruebas, y cualesquiera otros procedimientos operacionales que se deben observar.