capitulo#2 metodología de sistemas
TRANSCRIPT
Capitulo#2Metodología del sistema
Análisis y Diseño de SistemasIng. Rosalba Arredondo Martínez
2.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.
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.
Ejemplo
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.
Modelo Escencial
MODELO ESCENCIAL
MODELO AMBIENTAL
MODELO DE COMPORTAMIENTO
HERRAMIENTAS USADAS PARA DEFINIR
CONSTRUCCION DEL MODELO AMBIENTAL
DECLARACION DE PROPOSITOS
DIAGRAMA DE CONTEXTO
LISTA DE ACONTECIMIENTOS
DECLARACION DE PROPOSITOS
DIAGRAMA DE CONTEXTO
LISTA DE ACONTECIMIENTOS
2.2 Modelo Ambiental. 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.
Modelo Ambiental. 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.
Dos tópicos importantes en el modelo ambiental:
1. Herramientas usadas para definir el ambiente
2. Construcción del modelo ambiental
2.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.
Declaración de PropósitosLa 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.
Diagrama de Contexto
Es un caso especial de diagrama de flujo de datos, en donde una sola burbuja representa todo el sistema. La figura muestra un diagrama de contexto de un sistema de pedidos de libros.
Fuente 1
Fuente 2
Proceso Maestro Destino
Ejemplo de Diagrama de Contexto
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.
Lista de Acontecimientos
Es una lista narrativa de los estímulos que
ocurren en el mundo exterior a los cuales el
sistema debe responder.
EjemploA 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 Flujo: 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).
T Temporal: arrancan con la llegada de un momento dado en el tiempo.
C 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.
Construcción del diagrama de contexto
Consiste en una sola burbuja. El nombre dentro del proceso suele ser el nombre del sistema completo o un acrónimo convenido.
Construcción del 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.
Construcción del diagrama de contexto
O a través de almacenes externos.
Construcción del diagrama de contexto
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.
Consideraciones sobre los terminadores 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.
Cuando el terminador es una persona individual, generalmente es preferible indicar el rol que desempeña, más que su identidad.
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.
Consideraciones sobre los flujos de datos en el Diagrama de Contexto
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.
Construcción de la lista de acontecimiento
Por ejemplo, lo siguiente probablemente no sea un acontecimiento:
"El sistema recibe el pedido del cliente" Más 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.
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?.
2.3 Modelo de Comportamiento.
Dentro del modelo de comportamiento se involucrarán 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:
Se dibuja una burbuja, o proceso, para cada acontecimiento de la lista.
La burbuja se nombra describiendo la respuesta que el sistema debe dar al acontecimiento asociado.
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.
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
Primer Paso
El primer paso es directo y mecánico: si existen 25 acontecimientos en la lista, se deben dibujar 25 burbujas.
Segundo Paso
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?.
Tercer Paso 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?.
Tercer Paso 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.
Ejemplo
Cuarto Paso 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: Acontecimientos únicos que causan
respuestas múltiples y: 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í.
Acontecimientos múltiples que causan la misma respuesta: 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.
2.4 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.
Diseño de Sistemas
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.
Diseño de Sistemas 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.
2.5 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.
2.6 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.
PruebaExisten distintas estrategias de prueba, las dos más
comunes se conocen: 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 volumen 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.
Plan 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.