Seis Sigma Responsabilidad de la administración de la calidad total (página 2)

RESPONSABILIDAD DE LA ADMINISTRACIÓN DE LA CALIDAD TOTAL

En términos prácticos, gran parte de la responsabilidad por la calidad de los sistemas de información recae en los usuarios de éstos y en los directivos. Para que la TQM se vuelva una realidad en los proyectos de sistemas, deben darse dos condiciones. Primero, debe existir un apoyo organicional incondicional por parte de los directivos, lo cual es distinto a simplemente respaldar el nuevo proyecto de los directivos. Este apoyo significa establecer un contexto para que los directivos consideren seriamente cómo afecta su trabajo la calidad de los sistemas de información y la información misma.

FIGURA 16.1

Cada analista de sistemas debe entender la metodología y filoso- fía de seis sigmas.

Es necesario que tanto el analista como la empresa se comprometan desde el principio con la calidad para lograr le meta de calidad. Este compromiso da como resul- tado un esfuerzo uniformemente controlado hacia la calidad durante todo el ciclo de vida del desarrollo de sistemas, y esta en marcado contraste con tener que dedicar gran calidad de esfuerzo para resolver problemas al fin del proyecto.

El apoyo organicional para conseguir calidad en sistemas de información de administración se puede lograr al proporcional el tiempo en el trabajo para los círculos de calidad de SI, los cuales consisten de seis a ocho pares organizacionales específicamente responsable de considerar cómo mejorar los sistemas de información y como implementar las mejoras.mediante el trabajo en los círculos de calidad de SI o a través de otro mecanismos ya colocados, la administración y usuarios deben desarrollar lineamientos para los estándares de calidad de sistemas de información, preferentemente los estándares se diseñaran cada vez que un nuevo sistema o una modificación mayor se proponen formalmente para el equipo de análisis de sistemas.

No es fácil crear los estándares de calidad, pero es posible y se ha hecho. Parte del trabajo del analista de sistema es alentar a usuarios a que cristalicen sus expectativas acerca de los sistemas de información y sus interacciones con éstos.

Los estándares de calidad departamentales se deben comunicar mediante retroalimentación para el equipo de análisis de sistemas. Normalmente el equipo esta sorprendido por lo que se ha desarrollado. Las expectativas generalmente son menos complejas de lo que los analista experimentados saben se podría hacer con un sistema. Además los problemas humanos que se han omitido o menospreciado por el equipo del Analista se podrían diseñar como extremadamente urgentes en los estándares de calidad para los sistemas de información ayudaran al analista a evitar errores costosos en el desarrollo de sistemas no desarrollado o innecesario.

ªMerle, ven aquí y echa un vistazo a estos informes de fin de semanas, su- plica portia. Como uno de los gerentes del comité de aseguración de la calidad/ grupo de trabajo de SI, compuesto por seis integrantes, portia ha estado examinado la salida del sistema producida por el prototipo para su departamento de marketing. El equipo de análisis de sistemas le ha permitido que revise la salida.

ªMerle Chat se encamina hacia el escritorio de portia y da una mirada a los documentos que ella le extiende. ª ¿Por qué?, ¿Cuál es el problema?ª, pregunta. ªA mi me parece que están bien. Creo que le estas dando demasía- da importancia a esta grupo de trabajo. Se supone que también debemos hacer nuestro otro trabajo, ya sabes, ª Merle da la vuelta y regresa a su escritorio ligeramente perturbado por la interrupción.

ª Merle, ten un poco de compasión. Es verdaderamente tonto soportar estos informes tal como están. No puedo encontrar nada de lo que necesito, y se supone que tengo que indicarles a todos los demás en el departamento qué parte del informe deben leer. Por una parte, estoy decepcionada. Este informe es descuidado. No le encuentro ningún sentido. Es tan solo una copia de la salida que estamos recibiendo ahora. De hecho, parece peor. Lo voy a presentar en la próxima reunión del grupo de tra- bajo, manifiesta insistentemente portia.

Merle voltea a verla y dice: la calidad es su responsabilidad, portia. Si el sistema no esta dándonos buenos informes, ellos lo agregaran cuando

Todo esté junto. Nada más estás provocando problemas. Estas actuando como si ellos valoraran realmente nuestra información. Yo no le dedicaría tiempo de mi día, mucho menos haría su trabajo. Ellos son inteligentes, dales la oportunidad de que deduzcan lo que necesitamos.

Portia mira a Merle inexpresivamente, y poco a poco co- mienza a enfadarse, dice .tú has asistido a cuatros reuniones. Nosotros somos los únicos que conocemos el negocio. La idea esencial de TQM es decirles lo que necesitamos, entonces no podemos quejarnos. Esto lo plantearé la próxima vez que nos reunamos. ª

¿Qué tan eficaz cree que será merle para comunicar sus normas de calidad al equipo de análisis de sistemas y a los miembros del grupo de trabajo de SI? Responda en un párrafo. ¿Si los analistas de sistemas pueden percibir la reunión de merle para trabajar con el grupo de trabajo en el desarrollo de las normas de calidad, qué le diría para convencerlo de la importancia de la participación de los usuarios en la TQM? haga una lista de argumentos que apoye el uso de la TQM. ¿Cómo puede responder el equipo de análisis de sistemas a las inquietudes que plantea portia? explique su respuesta en un párrafo.

REPASO ESTRUCTURADO

Una de las acciones de administración de la calidad mas eficaces que puede emprender un equipo de análisis de sistemas es hacer repasos estructurados de manera rutinaria. Los repasos estructurados son una forma de usar expertos para monitorial la programación y el desarrollo general del sistema, señalar los problemas y permitir al programador o analista responsable de dicha parte del sistema hacer los cambios correspondientes.

Los repasos estructurados involucran por lo menos a cuatros personas: la persona responsable de la parte del sistema o subsistema que se revisará (un programador o analista) o coordinador del repaso, un programador o analista experto y un experto que toma notas acerca de las sugerencias.

Cada persona que participa en un repaso tiene un papel especial que cumplir. El coordinador se encarga de asegurar que otros cumplan los papeles que se le asigne y de que realicen las actividades establecidas. El programador o analista Este para escuchar, no para defender su punto de vista, racionalizar o discutir un problema. El programador o analista experto tiene que señalar los errores o problemas potenciales, sin especificar como se debe resolver. El tomador de notas registra lo que se dice con el fin de que los demás participantes puedan interactuar sin ningún problema.

Los repasos estructurados se pueden hacer siempre que una parte de la codificación, de un subsistema o de un sistema esté terminada. Simplemente asegurarse de que el subsistema bajo revisión sea comprensible fuera del contexto al que pertenece. Los repasos estructurados son especialmente adecuados en un enfoque de administración de la calidad total cuando se realiza durante todo el ciclo de vista de desarrollo de sistemas. El tiempo para realizarlos debe ser de media hora a una hora cuando mucho, lo cual implica que debe coordinarse muy bien. En la figura 16.2 se muestra un formulario útil para organizar el repaso estructurado e informar sus resultados. Debido a que el repa- sos estructurado tomas tiempo, no abuse de ellos.

FIGURA 16.2

Formulario para documen- tar repasos estructurados; los repasos se pueden hacer siempre que se finalice una parte de la codificación, de un sistema o de un subáis- tema.

Utilice los repasos estructurados para obtener (y después emprender acciones acordes con) retroalimentación valiosa desde una perspectiva que le falte. Al igual que con todas las medidas de aseguramiento de la calidad, el propósito de los repasos es evaluar el producto sistemáticamente de manera continua en lugar de esperar hasta la terminación del sistema.

DISEÑO Y DESARROLLO DE SISTEMAS

En esta sección definimos los diseños de sistemas ascendente (de abajo a arriba o bottom-up) y descendente (de arriba abajo o top-down), así como también el enfoque modular para la programación. Discutimos las ventanas de cada uno, así como también las preocupaciones que se deben observar al emplear un enfoque descendente o uno modular.

También discutimos las propiedades de los enfoques descendente y modular para ayudar en el aseguramiento de la calidad de los proyectos de sistemas.

Diseño ascendente este diseño se refiere a identificar los procesos que necesitan computarizarse conformes surgen, analizarlos como sistemas y codificar los procesos o comprar software empaquetado para resolver el problema inmediato. Los problemas que requieren computarizarse normalmente se encuentran en el nivel mas bajo de la organi- zacion. Con frecuencia este tipo de problemas son estructurados y por lo tanto son más sensibles a la computación; también son los más rentables. Por lo tanto, el nombre ascendente se refiere al nivel inferior en el cual se introduce primero la computación. Por ejemplo, con frecuencia los negocios toman este enfoque para el desarrollo de siste-más al adquirir software comercial para la contabilidad, un paquete diferente para la programación de producción y otros para el marketing.

Cuando la programación interna se hace con un enfoque de ascendente, es difícil interconectar los subsistemas de manera que se desempeñen fácilmente como sistema. Es muy costoso corregir las fallas de la interconexión y muchas de ellas no se descubren, sino hasta que se completa la programación, cuando los analistas intentan reunir el sistema en la fecha limite señalada para la entrega. En esta situación, hay poco tiempo, presupuesto o paciencia del usuario para la depuración de las interconexiones delicadas que se han ignorado.

Aunque cada subsistema aparenta conseguir lo que quieren, al considerar el sistema global hay series limitantes para tomar un enfoque de ascendente. Una es que hay duplicidad de fuerza software e incluso introducir los datos. Otra es que se introducen datos inválidos en el sistema. Una tercera, y quizás las desventajas mas serias del enfoque ascendente, es que no se consideran los objetivos organicionales globales, y por lo tanto dicho objetivos no se pueden cumplir.

Diseño descendente es fácil visualizar este enfoque: como se muestra en la figura 16.3 significa ver una descripción amplia del sistema y después dividirla en partes más pequeñas o subsistemas. El diseña descendente permite a los analista de sistemas determinar primero los objetivos organicionales globales, así como también determinar como se reúnen mejor en un sistemas global. Después el analista divide dicho sistemas en subsistemas y requerimientos.

El diseño descendente es compatible con el pensamiento general de sistema que se discutió en el capitulo 2. Cuando los analistas de sistemas utilizan un enfoque descendente están pensando en que las interrelaciones e interdependencia de subsistemas se adaptan a la organización de existencia. el enfoque descendente también proporciona el énfasis deseable en la colaboración o interconexiones que los sistemas y sus subtemas necesitan, cual falta en el enfoque ascendente.

Las ventanas de usar un enfoque descendente para el diseño de sistemas incluyen evitar el caos de intentar diseñar un sistema de repente. Como hemos visto, planear e implementar sistemas de información y administración es increíblemente complejo intentar colocar todos los subsistemas en un lugar ejecutable enseguida es casi un fracaso seguro.

Una segunda ventana de tomar un enfoque descendente para diseñar es que permiten separar a los equipos de análisis de sistemas para trabajar en paralelo en diferentes subsistemas, lo cual puede ahorrar mucho tiempo. El uso del equipo para el diseño de subsistemas se ajusta particularmente bien a un enfoque de control de calidad total.

FIGURA 16.3

Uso de un enfoque descendente para determinar primero los objetivos organicionales generales.

Una tercera ventaja es que un enfoque descendente evita un problema mayor asociado con un enfoque ascendente; evitar que los analistas de sistemas se metan tanto en los detalles que pierdan de vista lo que se supone que el sistema hace.

Hay algunas dificultades con el diseño descendente que el analista de sistema necesita saber. La primera es el riesgo de que el sistema se divida en subsistemas ªerroresª. Se debe por atención a las necesidades que se traslapen y a la comparticion de recursos de manera que la partición en subsistemas tenga sentido para todos los sistemas. Además, es importante que cada subsistema solucione el problema correcto.

Un segundo riesgo es que una vez que se hacen las decisiones de un subsistema, sus interfaces se podrían descuidar o ignorar. Es necesario destallar de quien es la responsabilidad de las interfaces.

Una tercera advertencia es acompaña al uso de un diseño descendente es que los subsistemas se deben reintegrar eventualmente. Los mecanismos para la reintegración se necesitan poner en funcionamiento desde el principio. Una sugerencia es negociar información regular entres los equipos del subsistema; otra es usar herramientas que permiten flexibilidad si se requieren cambios para los subsistemas interrelacionados.

La administración de calidad total y el enfoque descendente para diseñar puede estar relacionada. El enfoque descendente proporciona el grupo de sistemas con una decisión más natural de usuarios en grupos de trabajos para subsistemas. Los grupos de trabajos establecidos de esa forma después pueden servir a una función dual como círculos de calidad para el sistema de información de administración. La estructura necesaria para el control de calidad está en el lugar, así como la motivación apropiada para obtener el subsistema para lograr las metas departamentales que son importantes para los usuarios involucrados.

DESARROLLO MODULAR

Una vez que se toma el enfoque del diseño, el enfoque modular es útil en la programación. Este enfoque implica dividir la programación en partes lógicas y manejables llamada módulos. Este tipo de programación funciona bien con el diseño descendente por da énfasis a las interfaces entre los módulos y no los descuida hasta el final del desarrollo de sistema. Idealmente, cada modulo individual debe ser funcionalmente cohesivo de manera que encargue de realizar una sola función.

El diseño de progre modular tienes tres ventajas principales. Primero, los módulos son más fáciles de escribir y de depurar porque prácticamente son independientes. Rastrear un error en un modulo es menos complicado, debido a que un problema en un modelo no debe causar problemas en otros.

Una segunda ventaja del diseño modular es que los módulos son más fáciles de mantener. Normalmente las modificaciones se limitarán a unos módulos y no seguirán en todo el problema.

Una tercera ventaja del diseño modular es que los módulos son más fáciles de entender, debido a que son subsistemas independientes. Por lo tanto, un lector puede adquirir una lista del código de un modulo y entender su función.

Algunos lineamientos para la programación modular incluyen lo siguiente:

1. mantener cada modulo de un tamaño manejable (incluir a la perfección una solo función).
2. poner particular atención a la interfaces críticas (los datos y variables de control que se pasan a otros módulos).
3. minimizar el numero de modulo que el usuario debe modificar al hacer los cambios.
4. mantener las relaciones jerárquicas establecidas en las fases descendentes.

MODULARIDAD EN EL ENTORNO DE WINDOWS

La modularidad se está volviendo muy importante. Microsoft desarrolló dos sistemas para vincular los programas en un entorno de Windows. El primero se llama intercambio dinámico de datos (DDE), el cual comparte códigos al usar archivos de bibliotecas de vínculos dinámicos (DLL). Al usar DDE, un usuario puede almacenar datos de un programa quizás en una hoja de cálculos tal como Excel y después usar dichos datos en otros programas, por decir, en un paquete de procesamiento de texto tal como Word para Windows. El programa que continúe los datos originales se denominan servidor y el programa que los usa se llama cliente, los datos se actualicen automáticamente y se refleje los cambios hechos en los archivos de hoja de cálculos del servidor desde la última vez que se abrió dicho archivo de procesamiento de texto. (Véase el capitulo 17 para una discusión amplia del modelo/servidor).

Uno de los archivos de la DLL normalmente usados es COMMDLG.DLL, el cual contiene los cuadros de diálogos de Windows para Abrir Archivos, Guardar Archivos, Buscar e Imprimir. Una ventaja de usar este archivo es que los programas tendrán la misma apariencia y funcionamiento que otros programas de Windows. También acelera el desarrollo, debido a que los programadores no tienen que escribir el código contenido en los archivos DLL más comunes.

Un segundo enfoque para vincular programas en Windows se denomina vinculación e incrustación de objetos (OLE). Este método de vincular programas es superior a DDE porque está ligado a los datos y gráficos de la aplicación. Mientras que DDE utiliza un enfoque de cortar y pagar para vincular datos y no retiene el formato, OLE retiene todas las propiedades de los datos creados originalmente. Este enfoque orientado a objetos (Véase en el capitulo 18 para una discusión de principios orientados a objetos) permite al usuario final pertenecer a la aplicación del cliente y evitar los datos originales en la aplicación del servidor. Con OLE, cuando un usuario final hace clic en el objeto incrustado, se despliega una barra de herramienta que permite la edición visual.

USO DE DIAGRAMAS DE ESTRUCTURA PARA DISEÑAR SISTEMAS

Las herramientas recomendadas para diseñar un sistema modular descendente se denomina diagrama de estructura. Este grafico simplemente es un diagrama que consiste de cuadros rectangulares, los cuales representan los módulos, y de flechas de conexión.

La figura 16.4 muestra tres módulos que se etiquetan como 000, 100 y 200 y se conectan mediante líneas de ángulos rectos. Los módulos del nivel superior se numeran por 100s o 1,000s y los módulos de nivel inferior se numeran por 10s o 100s. Esta enumeración permite a programadores insertar módulos que se usan un número entre los números de módulos adyacentes. Por ejemplo, un modulo insertado entre los módulos 110 y 120 recibiría el numero 115. Si se insertarán dos módulos, los números podrían ser 114 y 117. Estos esquemas de numeración varían, dependiendo de los estándares organicionales usados.

A los datos de las líneas de conexión, se dibujan dos tipos de flechas. Las flechas con los círculos vacíos se denominan parejas de datos y las flechas con los círculos rellenados se denominan bandejas de control o interruptores. Un interruptor es lo mismo que una bandeja de control acepto por que está limitado por dos valores: si o no. Esta flechas indican que algo se pasa hacia abajo al modulo inferior o arriba al superior.

FIGURA 16.4

Un diagrama de estructura muestre el control que se mueve de forma descendente y también muestras los módulos no funcionales.

El analista debe mantener a la perfeccionaste acoplamiento al mínimo. Cuando hay pocas parejas de datos y bandejas de control en el sistema, lo más fácil es cambiar el sistema. Cuando finalmente se programan estos módulos, es importante pasar el menor número de parejas de datos entre los módulos.

Aun mas importante es que se debe evitar las bandejas de control numerosas. El control se diseña para ser pasado de los módulos del nivel inferior a los del nivel superior en la estructura. Sin embargo, en rara ocasiones será necesario pasar el control hacia abajo en la estructura. Las bandejas de control deciden qué parte de un modelo se ejecuta y están asociado con las instrucciones IF…then…else… y otros tipo similares de instrucciones. Cuando el control se pasa en forma descendente, se permiten que un modulo de nivel inferior tome una decisión y el resultado en un modulo que decenpeña dos tareas diferentes. Este resultado rompe con el modelo de modulo funcional: un modulo solo debe desempeñar una tarea.

La figura ilustra que parte de un diagrama de estructura para agregar nuevos empleados. El programa lee un archivo de TRANSACCION DE EMPLEADO y verifica que cada registro en el archivo únicamente tenga datos aceptables. Los informes se imprimen por separados para los registros válidos e inválidos, proporcionando un rasgo para auditoria de todas las transacciones.

FIGURA 16.5

Este diagrama de estructura muestra el control que se mueve de forma descendente también muestra los módulos no funcionales.

El informe que contiene los registros inválidos se envía al usuario para la corrección de errores. Los registros que son validos se ponen en un archivo de transacción válido, el cual se pasa a un programa separado para actualizar el archivo MAESTRO DE EMPLEADOS. El modulo 200, agrega nuevos registro del empleado, representa la lógica de agregar un registro. Debido a que el modulo 230 se usa para imprimir ambos informes, se debe enviar una bandera de control hacia abajo para indicar al modulo que informe imprimir. De esta manera la lógica del modulo 230 se controla por completo mediante una instrucción IF, la cual se ilustra en la figura 16.6.

FIGURA 16.6

El pseudocódigo para el módulo 230 ilustra el efecto de pasar de forma descendente un interruptor.

La figura 16.7 muestra la forma correcta de diseñar la estructura por debajo del modulo 200, AGREGAR NUEVO REGISTRO DEL EMPLEADO. Aquí, cada función de impresión se ha puesto en un modelo separado y las banderas de control solo se pasan a la estructura al modulo del nivel superior.

También se debe examinar los datos que se pasan a través de las parejas de datos. Es mejor pasar sólo los datos requeridos para realizar la función del módulo. Este enfoque se denomina acoplamiento de los datos. El paso excesivo de datos se denomina acoplamiento de sello, y aunque es relativamente imnofencivo, reduce las posibilidades de crear un módulo reutilizable.

FIGURA16.7

Un diagrama de estructura perfeccionado que muestra el flujo del control hacia arriba.

La figura 16.8 ilustra este concepto. Aquí, el módulo EDITAR NUEVO CLIENTE pasa el REGISTRO DEL CLIENTE al módulo EDICTAR NÚMERO TELEFONICO DEL CLIENTE, donde NUMERO TELEFONICO, un elemento encontrado en el REGISTRO DEL CLIENTE, se válida, y una bandera de control se pasa atrás al módulo EDICTAR NUEVO CLIENTE. EL TIPO DE ERROR (si no hay algunos), uno que contiene un mensaje de error tal como CÓDIGO DE ÁREA INVÁLIDOS O EL NUMERO TELEFONICO NO ES NUMÉRICOS, también se pasa hacia arriba. El mensaje se podría imprimir o desplegar en pantalla.

Aunque dichos módulos son bastante fáciles y crear y modificar cada vez que es necesario editar un número telefónico de un registro fuente diferente, se debe crear un nuevo modulo similar al EDITAR NUMERO TEEFONICO DEL CLIENTE. Además, si la forma del número telefónico esta di validando los cambios como ocurre cuando se debe agregar un nuevo código de área o un código de país internacional, cada uno de estos módulos del nivel inferior se debe modificar.

Debido a que modulo de nivel o requiere ninguno de los otros elementos en el REGISTRO DEL CLIENTE, la solución es pasar solo el NÚMERO TELEFÓNICO al modulo del nivel inferior. El nombre del modulo en este escenario cambia a EDITAR NÚMERO TELEFÓNICO y se podría usar para editar cualquier número telefónico: un número telefónico del cliente o un número telefónico del empleado. Los módulos del lado derecho de la figura ilustran este concepto. Cuando cambia las reglas para validar el número telefónico, solo se necesita EDITAR NÚMERO TELEFÓNICO, sin tener en cuenta cuantos programas utilizan dicho modulo. Con frecuencia estos módulos de uso general se ponen en un programa compilado por separado denominado subprograma, función o procedimiento, dependiendo del lenguaje del programa usado.

Como se muestra en la figura 16.9, el bucle es otro símbolo usado en los diagramas de estructura. Este símbolo indica que algunos procedimientos encontrados en los módulos 100 y 200 serán respetados hasta terminar. Este ejemplo implica que LEER REGISTRO DEL CLIENTE y EDITAR REGISTRO DEL CLIENTE se repitan hasta que todo el registro del cliente se complete. Después se clasifican en el modulo 300, pero como puede ver, se puede clasificar de tres formas diferentes: por nombre, código postal o código de área. Para mostrar que parte, pero no toda, de las clasificaciones se realizará, se usa otro símbolo, un diamante. Observe que el diamante no indica cual de los tres módulos se desempeñará, ni el bucle indica que modulo se repetirán estos símbolos pretenden deliberadamente ser generales no específicos.

Dibujo del diagrama de estructura

Obviamente, los diagramas de estructura se deben dibujar de arriba hacia abajo, pero ¿dónde se empiezan los procesos que serán los módulos? Probablemente, el mejor lugar para buscar esta información es en el diagrama de flujo de datos (véase el capitulo 7).

Al trasformar un diagrama de flujos de datos en un diagrama de estructura, se debe tener en cuenta varias consideraciones adicionales. El diagrama de flujos de datos indicara la secuencia de los módulos en un diagrama de estructura. Si un proceso proporciona entrada a otro proceso, los módulos correspondientes se deben acompañar en la misma secuencia. La figura 16.10 es un diagrama de flujos de datos para preparar un informe de clasificación del estudiante.

FIGURA 16.9

El bucle y el diagrama son dos símbolos que indican una acción especial en un diagrama de estructura.

FIGURA 16.8

Crea modulo reutilizable

Observe que el proceso 1, LEER REGISTRO DE CALIFICACION, proporciona entrada para el proceso 2, LEER REGISTRO DEL CURSO, Y PARA EL PROCESO 3, LEER REGISTRO DEL ESTUDIANTE. En la figura 16.11 se ilustra el diagrama de estructura creado para este diagrama. Observe que el modulo 110, LEER REGISTRO DE CALIFICACION, se debe ejecutar primero. Después se deben ejecutar los procesos 2 y 3, pero debido a que no proporcionan entrada para otros, el orden de estos módulos (120 y 130) en el diagrama de estructura no es importante y se podría invertir sin afectar Los resultados finales. Los procesos 1 y2 proporcionan entrada para el proceso 4, CALCULAR MEDIA DE PUNTO DE CALIDAD (también conocido como modulo 140). El proceso 5, IMPRIMIR INFORME DE CALIFICACION DEL ESTUDIENTE (modulo 150), recibe flujos de datos de todos los demás procesos y debe se el ultimo modulo en ser ejecutado.

FIGURA 16.10

Diagrama de flujos de datos para imprimir un informe de calificación de estudiante

Si un proceso se divide en un diagrama de flujo de datos de hijo, el modulo correspondiente para el proceso padre tendrá módulos subordínales que correspondan a los procesos encontrado en el diagrama de flujo. El proceso 5, IMPRIMIR INFORME DE CALIFICACION DEL ESTUDIANTE, tiene cuatros flujos de datos de entrada y uno de salida y por ello es buen candidato para un diagrama hijo. En la figura 16.12 se ilustra en el diagrama 5, los detalles del proceso 5. Los procesos en el diagrama 5, traduce los módulos subordinados al modulo 150, IMPRIMIR INFORME DE CALIFICACION DEL ESTUDIANTE.

TIPOS DE MÓDULOS

Los módulos del diagrama de estructura entran en una de las tres categoría generales: (1) control, (2) transformacional ( a veces denominado trabajador) o (3) funcional. Al producir un diagrama de estructura que es fácil de desarrollar y modificar se debe tener cuidado, de no mezclar los diferentes tipos de módulos.

Los módulos de control normalmente se encuentran siempre en la parte superior del diagrama de estructura y contienen las lógicas para decenpeñan los módulos del nivel inferior. Los módulos de control podrían estar, o no estar representado en el día-

grama flujo de datos. Los tipos de instrucciones que normalmente están en los módulos de control son IF, PERFORM DO. Las instrucciones detalladas tal como ADD y MOVE normalmente se mantienen al mínimo. Con frecuencia la lógica de control es la mas difícil de enseñar por lo tanto, los módulos de control no deben de ser muy grande. Si un modulo de control tiene mas de nueve módulos subordinado, se deben crear nuevos módulos de control que sean subordinado de modulo de control original. La lógica de un modulo de control se podría determinar desde un árbol de disición o una tabla de decisión. Una tabla de decisión con demasiada reglas se deben dividir en varias tablas de decisión, con la primera tabla llamando a ejecución a la segunda tabla. Cada tabla de decisión produciría un modulo de control (véase el capitulo 9 para mas información de los árboles y la tabla de decisión).

Los módulos transformacionales son aquello creados de un diagrama de flujos de datos. Normalmente desempeñan una sola tarea aunque varias tareas secundarias se podrían asocial con la principal. Por ejemplo, un modulo denominado IMPRIMIR LINEA TOTAL DEL CLIENTE podría formatear toda la línea, imprimir la línea, agregarla a los totales finales y establecer los totales del cliente a cero en la preparación para acumular las cantidades del siguiente cliente. Los módulos transformacionales normalmente incluyen una mezcla de intrusiones, unas cuantas instrucciones IF y PERFORM o DO y muchas instrucciones detalladas tales como MOVE y ADD. Estos módulos son inferiores en la estructura que los módulos de control.

Los módulos funcionales son los más bajos en la estructura, rara vez tiene un módulo subordinado bajos ellos. Solo desempeñan una tarea, tal como formatear, leer, calcular o escribir. Algunos de estos módulos se encuentran en un diagrama de flujo de datos, pero otros se tendrían que agregar, tal como leer un registro o imprimir una línea de error.

La figura 16.13 representa el diagrama de estructura para agregar las reservaciones para los huéspedes de un hotel. Los módulos 000, AGREGAR RESERVACIÓN DEL HUÉSPED y 100, agregar reservación del cuarto, son módulos de control que representan el programa entero (modulo 000) y proporcional el control necesario para hacer una reservación de cuarto (modulo100). El modulo 110, DESPLEGAR PANTALLA DE RESERVACIÓN, es un modulo funcional responsable de mostrar la pantalla de reservación inicial. Los módulos 120, OBTENER RESERVACIÓN DE CUARTO VÁLIDA, y 160, CONFIRMAR CONSERVACIÓN DEL CUARTO, son los módulos de control de nivel inferior

El modulo 120, OBTENER RESERVACIÓN DE CUARTO VÁLIDA, se desempeña relativamente hasta que los datos de la reservación sean válida o hasta que el operador de la reservación cancele la transacción. Este tipo de modulo OBTENER RESERVACIÓN… desahoga el modulo 100 de una cantidad considerable de código completo. Los módulos subordinados para OBTENER RESERVACIÓN DE CUATRO

VÁLIDAD son módulos funcionales responsable de recibir la pantalla de reservación, editar o validar la reservación del cuarto y mostrad una pantalla de error si los datos de entrada no válidos. Debido a que estos módulos están en un bucle, el control permanece en esta parte de la estructura hasta que los datos de la pantalla sean válidos.

FIGURA 16.12

Diagrama hijo para proceso 5, IMPRIMIR INFORME DE CALIFICACIÓN DE ESTUDIANTE.

El modulo 160, CONFIRMARRESERVACION DEL CUARTO, también se desempeña rápidamente y permite al operador verificar que se haya introducido la información correcta. En esta situación, el operador inspeccionará la pantalla y presionará una tecla especificada, tal como Enter, si los datos son correctos, o una tecla diferente para modificar o cancelar la transacción. De nuevo, el programa permanecerá en estos módulos, repitiéndose hasta que el operador acepte o cancele la reservación.

El modulo 190 es un modulo transformacional que formatea el REGISTRO DE RESERVACION y desempeña el modulo 200 para escribir el REGISTRO DE RESERVACION. Los módulos 130, 140, 150, 160, 170, 180, y 200 son módulos funcionales que desempeñan una sola tarea: aceptar una pantalla, desplegar una pantalla o editar o escribir un registro. Estos módulos son los más fáciles de codificar, depurar y mantener.

Subordinación de módulo

Un modulo subordinado es un inferior en el diagrama de estructura llamado por otro modulo superior en le estructura. Cada modulo subordinado debe representar una tarea que es una parte de la función del modulo del nivel superior. Permitir que el modulo del nivel inferior desempeñe una tarea que no es requerida para el modulo que lo llama se denomina subordinación inadecuada. En tal caso, el modulo inferior se debe mover al nivel superior de la estructura.

FIGURA 16.13

Diagrama de estructura para agregar, en líneas, las reservaciones del huésped de un hotel.

La figura 16.14 ilustra este concepto mediante un diagrama de estructura para cambiar un archivo MAESTRO DE CLIENTES. Examine el modulo 120, LEER MAESTRO DE CLIENTES. Este tiene la tarea de usar el NUMERO DEL CLIENTE de CAMBIAR REGISTRO DE TRANSACION para obtener directamente la coincidencia del REGIDTRO DEL CLIENTE. Si no se encuentra el registro, se imprime una línea de error. Por otra parte, el MAESTRO DE CLIENTES se cambia y se vuelve a escribir el registro. Este modulo debe ser un modulo funcional, que simplemente lee un registro, pero en cambio tiene tres módulos subordinados. La pregunta debe ser, º ¿se debe imprimir una línea de error para lograr la lectura del MAESTRO DE CLIENTES?º Además, º¿se debe formatear y volver a escribir el MAESTRO DE NUEVOS CLIENTES par leer el MAESTRO DE CLIENTES?º Debido a que las repuestas no son para ambas preguntas, los módulos 130, 140 y 150 no deben ser subordinados de LEER MAESTRO DE CLIENTES.

La figura 16.15 muestra el diagrama de estructura modificado. Las instrucciones de control se sacaron del registro LEER MAESTRO DE CLIENTES Y se pusieron en los módulos de control principal, CAMBIAR REGISTRO DEL CLIENTE. LEER MAESTRO DE CLIENTES se vuelve un modulo funcional (módulo 120).

FIGURA 16.14

Diagrama de estructura que ilustra una subordinación inadecuada

Aun cuando un diagrama de estructura logra todo los propósitos para los cuales fue diseñado, no puede ser la única técnica usada para diseño y documentación. Primero, no muestra el orden en que se deben ejecutar los módulos (un diagrama de flujos de datos lo hará). Segundo, no muestra suficiente detalles (un pseudocodigo lo hará). El resto de este capitulo discute estas técnicas mas detalladas usando como ejemplo el problema de suscripción a un periódico pensando anteriormente, el cual se describe ahora con mas detalle.

………………………………………………………………………………………………..

INGENIERÍA DE SOFTWARE Y DOCUMENTACIÓN

La plantación y control son elementos fundaménteles en todo sistema exitoso. En el desarrollo de software para el sistema, el analista de sistema debe saber que la plantación tiene lugar en el diseño, incluso antes de que empiece la programación. Necesitamos técnicas que nos ayuden a establecer los adjetivos del programa, de manera que nuestros programas estén completos. También necesitamos técnicas de diseños que nos ayuden a separar el esfuerzo de programación de módulos manejables.

FIGURA 16.15

Diagrama de estructura modificado que muestra la subordinación adecuada.

Sin embargo, no es satisfactorio insertar tener éxito tan solo con las etapas de la planeación. Después que se completa los programas, se deben mantener y los esfuerzos de mantenimientos normalmente son mayores que el esfuerzo empleado en el diseño y la programación originales.

Las técnicas descritas en la siguiente sección no solo están hechas para usarse inicialmente en el diseño de software, sino también en un mantenimiento. Debido a que la mayorías de los sistemas no se consideran desechables, muy probablemente necesitarán ser mantenidos. El esfuerzo de aseguramiento de la calidad total requiere que los programas se documenten adecuadamente.

El software y los procedimientos se documentan de manera que se codifiquen en un formato que pueda acceder fácilmente. El acceso a esta documentación es necesario para las nuevas personas que aprenden el sistema y como un recordatorio para aquellos que no usan el programa con frecuencia. La documentación permite a usuario, programadores y analista ªverª el sistema, su software y procedimientos sin tener que interactuar con él.

Cierta documentación proporciona una aparición global del propio sistema, mienta que la documentación de procedimiento detalla lo que se debe hacer para ejecutar el software en el sistema y la documentación del programa detalla el código del programa que se usa.

La rotación del personal de servicio de información tradicionalmente ha sido alta en la comparación con otros departamentos, de manera que probablemente las personas que concibieron e instalaron el sistema original no serán mismas que las que lo mantienen.

La documentación consistente y bien actualizada acortará el número de horas requerido para que las nuevas personas aprendan el sistema antes de realizar el mantenimiento.

Hay muchas razones por las cuales los sistemas y programas no están documentados o presentan subdocumentacion. Algunos de los problemas residen en los sistemas y programas, otros en los analistas de sistemas y programadores.

Algunos sistemas heredados fueron escritos antes de que un negocio estandarizara sus técnicas de documentación, pero todavía se usan (sin documentación). Muchos otros sistemas han sufrido modificaciones mayores o menores y se han actualizados durantes los años, pero su documentación no se ha modificado para reflejar esto. Incluso se puede dar el caso que se hayan comprados algunos sistemas especificados para aplicaciones importantes a pesar de su falta de documentación.

Los analistas de sistemas podrían no documentar adecuadamente los sistemas debido a que no tiene tiempo usado en la documentación. Algunos analistas no documentan porque tienen miedo de hacerlo o piensan que no es su trabajo. Además, muchos analistas son reservados sobre documentar sistemas que no son suyo, quizás temen a las represalias si incluyen material incorrecto en el sistema de alguien mas la documentación lograda por medio de una herramienta CASE durante las fases del análisis puede resolver mochos de estos problemas.

Actualmente no se usa una sola técnica estándar de diseño y documentación. En las siguientes secciones, discutimos varias técnicas diferentes que actualmente se usan. Cada técnica tiene sus propias ventajas y desventajas, debido a que cada una tiene propiedades únicas.

PSEUDOCÓDIGO

En el capitulo 9, introducimos el concepto de español estructurado como una técnica de analizar decisiones. El pseudoscódigo es similar al español estructurado porque no es un tipo particular de programar códigos, pero se puede usar como un paso intermedio para desarrollar el código de programa.

La figura 16.16 es un ejemplo de pseudocódigo para chenoweth enterprises, un conglomerado del periodo que publica el charlie brown’s journal, the steel pier observer wicked, el siempre popular periódico orientado a los adolescente. El conglomerado del periódico pasa por un proceso de actualizar, imprimir y proporcionar informe de administración para cada una de sus periódicos. El pseudocódigo para este proceso involucra un proceso de actualizar cada lista de suscritores al periódico. Esta estructura se puede ver fácilmente en el pseudocódigo.

En la industria es común el uso del pseudocódigo, pero falta la estandarización evitará que sea aceptado por todo. Debido a que su pseudocódigo esta tan cerca del código de programa, naturalmente es favorecido por programadores y por consiguientes no es favorecido por analista de negocio. El pseudocódigo con frecuencia se usa para representar la lógica de cada modulo en un diagrama de estructura.

El diagrama de flujos de datos se podría usar para escribir la lógica del pseudocódigo. Al usar un nivel del programa en un lugar de un nivel de sistema, el diagrama de flujo de datos podría agregar varios símbolos adicionales. El asterisco (*), que significa º y º, se usa para indicar que deben estar presente los dos flujos de datos nombrado. Consulte la parte de datos de un diagrama de flujos de datos que se ilustra en la figura 16.17 si los flujos de datos de entrada son de procesos diferentes, la presencia del conector º y º significa que el proceso que recibe cuencial, leer todo los registro de ambos archivos o una lectura indexada de un segundo archivo usando un campo importante obtenido del primer archivo.

El signo de suma encerrado en un circulo (+) representa un º o º exclusivo e indica que uno u otros flujos de datos esta presente en cualquier momento dado. Usar este símbolo implica que el proceso que recibe o produce el flujo de datos debe tener una instrucción correspondiente IF… THEN…ELSE…

FIGURA 16.16

Usar pseudocódigo para describir un servicio de actualización de suscripción para una compañía editorial especializadas en periódicos

MANUALES DE PROCEDIMIENTOS

Los materiales de procedimiento son documentos organicionales comunes que la mayoría de las personas ha visto. Son el componente en español de la documentación, aunque también podrían contener códigos de programas, diagramas de flujos, etc. se pretende que los manuales comuniquen a aquellos que lo usan. Podrían contener comentarios de fondos, los pasos requeridos para lograr diferentes transacciones, instrucciones de como recuperarse de los problemas y qué hacer si algo no funciona (solucionar problema). Actualmente muchos manuales están disponible en línea, con capacidad de hipertexto que facilita el uso.

Se desea un enfoque directo y estandarizado para crear documentación de apoyo de usuario. Para ser útil, la documentación del usuario se debe mantener actualizada. El uso de Web ha revolucionado la velocidad con lo que los usuario pueden obtener asistencia. Muchos diseñadores de software están desplazando el soporte de usuario- con la lista de preguntas frecuentes (FAG), escritorio de ayuda, soporte técnico y servicio de fax– para Web. Además, muchos vendedores de software COTS incluyen archivos ºLeameº con descarga o envió de nuevos software. Estos archivos sirven para varios propósitos: documentan cambios, agostan o reparan fallas recientemente descubiertas en la aplicación que han ocurrido demasiado tarde en su desarrollo para poder ser incluida en el manual del usuario.

Las selecciones importante de un Manuel deben incluir una introducción, como usar el software, que hacer si las cosas salen mal, una sección de referencia técnica, un índice e información de cómo contactar al fabricante. Los manuales en línea en los sitios Web también deben incluir información sobre descargar actualizaciones y una pagina de FAQ. Los problemas con los manuales de procedimiento son que (1) están mal organizados,(2) es difícil encontrar la información necesaria en ellos,(3) el caso especifico en cuestión no aparece en el manual y (4) el manual no esta inscrito en español. Mas adelante, en la selección donde se habla de pruebas, discutimos la importancia de tener usuario que ºpruebaº los manuales de sistemas y prototipos de los sitios Web antes de que se terminen.

EL MÉTODO DE FOLKLORE

El folklore: es una técnica de documentación de subte mas creada para complementar algunas de las técnicas ya tratada. Aun con la abundancia de técnicas disponible, muchos sistemas se documentan inadecuadamente o no se documentan en absoluto. EL FOLKLORE recopila información que normalmente se comparte entre los usuarios pero raramente se pone por escrito.

EL FOLKLORE es una técnica sistemática, basada en métodos tradicionales usado para recopilar el folklore sobre las personas y leyenda. Este enfoque para la documentación de sistemas requiere que el analista entreviste a los usuarios, investigue la documentación existente en los archivos y observe el procedimiento de información. El objetivo es recopilar la información correspondiente a una de cuatros categoría: costumbre, anedota, proverbios forma artística. La figura 16.18 siguiere como se relaciona cada categoría a la documentación de sistemas de información.

Al documentar las costumbres, el analista (u otros folkloristas) intenta capturar por escrito lo que los usuarios hacen para conseguir que los programas puedan ejecutar sin problemas. Por ejemplo de unas costumbres es: º normalmente nos toma dos días actualizar los registros mensuales por que la tarea es bastante grande. Ejecutamos cuentas comerciales en un día y guardamos las otras para el siguiente día.

Las anécdotas son historias que los usuarios dicen respecto a como funcionó el sistema. Por supuesto, la exactitud de la anécdotas depende de la memoria del usuario y es, en el mejor de los casos, una opinión sobre como funcionó el programa. Lo siguiente es un ejemplo de una anécdota:

El problema ocurrió de nuevo en 1995. Esa vez, el trabajo LIB 409 (actualización mensual) solo se ejecutó con los registro tipo º6 º. Debido a este error no había registrado financiero en el archivo LIBFIN. Cuando intentamos leer el archivo vació este inmediatamente se serraba y por consiguiente los totales se reportaron como cero. Pudimos corregir este problema agregando un registro tipo 7 º y ejecutando el trabajo.

Las anécdotas normalmente tienen un principio, un cuerpo y un fin. En este caso tenemos una historia sobre un problema (el principio), una descripción de los efectos (el cuerpo) y la solución (el fin).

Los proverbios son declaraciones breves que representan generalizaciones o consejos. Tenemos muchos proverbios en la vida cotidiana, tal como mas vale pájaro en manos que cinto volando ºoº centavos ahorrado, centavos ganados º. En la documentación de sistemas, tenemos muchos proverbios, tal como Omita éstas sección de código y el programa fallarán o º Haga frecuentemente copia de seguridad. A los usuarios le gusta dar consejos y el analista debe intentar captura dicho consejos e incluirlo en la documentación del FOLKLORE.

Recopilar formas artísticas es otra actividad importante del folklorista tradicional, y también el analista de sistemas debe entender su importancia. Los diagramas de flujos, diagrama sí tablas que los usuario diseñan algunas veces podrían ser mejores o mas útil que los diseñados por el autor de sistema original. Los analistas con frecuencias entrarán tal arte en los carteles de anuncios o podrían pedir a los usuarios vaciar sus archivos y recuperar cualquier diagrama útil

Figura 16.18

Las costumbres, anécdotas, proverbios, y formas artísticas que se usan en el método FOLKLORE de documentación se aplican a los sistemas de información

El enfoque FOLKLORE funciona debido a que puede ayudar a reparar la falta de conocimiento cuando un autor de programa se retira. Los construyen tes al documento FOLKLORE no tiene que documentar el sistema entero, sólo las partes que conozcan. Por ultimo, es divertido para los usuarios contribuir, quitando así algo de cargas de los analistas. Observe que la clase de sistema recomendación que se discutió anteriormente en el libro está muy cerca de la conceptualizacion de FOLKLORE. Estos sistemas amplían la idea de FOLKLORE para incluir todos los tipos de recomendaciones, tales como las calificaciones de restaurantes y películas. Usando métodos económicos o gratuito como el correo electrónico, se han superados algunas barreras iniciales para recopilar y compartir la información informal.