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:
- mantener cada modulo de un tamaño manejable
(incluir a la perfección una solo
función). - poner particular atención a la interfaces
críticas (los datos y variables de
control que se pasan a otros módulos). - minimizar el numero de modulo que el usuario debe
modificar al hacer los cambios. - 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.
 Página anterior | Volver al principio del trabajo | Página siguiente  |