El peligro de confiar en el FOLKLORE en
que la información recopilada de los usuarios
podrían ser correcta, particularmente correctas
incorrecta. Sin embargo, a menos que alguien se tome el tiempo de
rehacer completamente la documentación de programa, la
descripción de costumbres, anécdotas
proverbios y formas artísticas podrían ser la
única información escrita acerca de cómo
funciona un grupo de
programas.
SELECCIÓN DE UNA TÉCNICA DE
DISEÑO Y DOCUMENTACIÓN
Las técnicas
discutidas en este capitulo son sumamente valiosas como herramientas
de diseños, ayudas de memoria,
herramienta de productividad y
como medio de reducir las dependencias en los miembros de
personal
claves. Sin embargo, el analista de sistema se
encuentra con una decisión difícil con respecto a
qué modulo adoptar. Lo siguiente es un grupo de
lineamiento para ayudar al analista a seleccionar la
técnica adecuada.
Escoja una técnica que:
- Es compatible con la documentación
existente.
- Se entiende por otro en la
organización.
- Le permite regresar a trabajar en el sistema
después que ha estado fuera
de él por un periodo.
- Sea conveniente para el tamaño del sistema en
que está trabajando.
- permita un enfoque de diseño estructurado si se considera como
más importante que otros factores.
- permita fácil modificación.
…………………………………………………
CÓMO PROBAR,
MANTENER Y AUDITAR
Una vez que el analista ha diseñado y modificado
el sistema, probar, mantener y auditar son las primeras
consideraciones.
EL PROCESO DE
PROBAR
Todos los programas de aplicación del sistema
recién escrito o modificado ─así como
también nuevos manuales de
procedimiento,
nuevo hardware y
todas las interfaces del sistema─ se deben probar
completamente. Probar al azar y por tanteo no será
suficiente.
Las pruebas se
hacen durante todo el proceso de desarrollo de
sistemas, no solo
al final. Se busca descubrir errores desconocidos hasta ahora, no
demostrar la perfección de programas, manuales o
equipos.
Aunque probar es tedioso, es una serie esencial de pasos
que ayuda a asegurar la calidad eventual
sistema. Es mucho menos inquietante probar de antemano que tener
un sistema probado deficientemente que falle después de la
instalación. Las pruebas se realizan en subsistemas o
módulos del programa enfoque avance su desarrollo. Las
pruebas se hacen en muchos niveles diferentes a varios
intervalos. Antes de que el sistema se ponga en producción, todos los programas se deben
verificar en el escritorio, verificar con datos de prueba y
verificar para ver si los módulos trabajan entre sí
como se planeó.
El sistema también se debe probar como todo en
funcionamiento. Incluso hay que probar las interfaces entre los
subsistemas; la exactitud de salida; y la utilidad y
entendimiento de la documentación y la salida de sistemas.
Como se muestra en la
figura 16.19, los programadores, analista, operadores y usuarios
cumplen un papel diferente en los varios aspectos a probar. Las
pruebas d hardware normalmente se proporcionan como un servicio por
los vendedores de equipo quienes ejecutarán sus propias
pruebas en el equipo cuando se libere en el sitio.
Pruebas de programas con datos de prueba Mucha de
la responsabilidad para probar el programa radica en
el autor(es) original de cada programa. El analista de sistema
sirve como consejo y coordinador para las pruebas del programa.
En esta capacidad, el analista trabaja para asegurar que los
programadores implementen las técnicas de pruebas
correctas pero probablemente no desempeñe personalmente
este nivel de verificación.
En esta FACE, los programadores deben hacer pruebas de
escritorio de sus programas para verificar las formas en que
funcionará el sistema. En la verificación de
escritorio, el programador sigue cada paso en el programa impreso
para verificar si la rutina funciona como se espera.
Luego, los programadores deben crear datos de pruebas
válidos e inválidos. Estos datos se ejecutan
después para ver si la rutinas de base trabajan y
también para descubrir errores.
FIGURA 16.19
Los programadores, analistas,
operadores y usuarios desempeñan un papel diferente en
probar el software y
sistemas.
Si las salidas de los módulos principales es
satisfactoria, puede agregar más datos de pruebas para
verificar otros módulos. Los datos de pruebas creados
deben probar posibles valores
mínimos y máximos así como también
todas las variaciones posibles en el formato y códigos.
Los archivos de
salidas de los datos de pruebas de deben verificar
cuidadosamente. Nunca se fue creado y accesado.
A lo largo de este proceso, el analista de sistemas
verifica la salida de búsqueda de errores, abusando al
programador de cualesquiera correcciones necesarias. El analista
normalmente no recomendará o creará datos de
pruebas para las pruebas de programas pero podría
señalar al programador las omisiones de tipos de datos a
ser agregados en
pruebas posteriores.
Prueba de vínculos con datos de pruebas
Cuando los programas pasan la verificación de escritorio y
la verificación de datos de pruebas, se debe pasar por las
pruebas de vínculos, que también se conocen como
prueba de cadena. Estas pruebas verifican si los programas que
realmente son interdependientes trabajan juntos como se
planeo.
Una pequeña cantidad de datos de prueba,
normalmente diseñado por el analista de sistema para
probar las especificaciones del sistema así como
también los programas, se usan para las pruebas de
vinculación. Podría tomar varios pasos a
través del analista para probar todas las combinaciones,
debido a que es inmediatamente difícil resolver los
problemas si
intenta probar todo a la vez.
El analista crea datos de pruebas especiales que cubren
una variedad de situaciones de procedimientos
para la pruebas de vinculación. Primero se procesan datos
de pruebas típicos para ver si el sistema puede manejar
transacciones normales, se agregan las variaciones, incluyendo
los datos inválidos para asegura que el sistema puede
detectar adecuadamente los errores.
Prueba completa de sistemas de datos de pruebas
Cuando las pruebas de vinculación se concluyen
sastifactoriamente, se debe probar el sistema como una entidad
completa. En esta fase, los operadores y usuarios finales se
involucran activamente en la prueba. Los datos de prueba, creados
por el equipo de análisis de
sistemas para el propósito expreso de probar los
objetivos de
analista, se usan.
Como se puede esperar, hay varios factores a considerar
cuando se prueban los sistemas de datos de pruebas:
- examinar si los operadores tienen la
documentación adecuadas en los manuales de
procedimientos (en papel o en línea) para asegurar un
funcionamiento correcto y eficaz.
- verificar si los manuales de procedimientos son lo
bastante claro como para comunicar cómo se deben
preparar los datos para la entrada.
- determinar si los flujos de trabajos necesarios para
el sistema nuevo o modificado realmente Fluyen.
- determinar si las salidas es correcta y si los
usuarios entienden que esta salida es como se verá en su
formulario final.
Recuerde fijar el tiempo adecuado para la prueba del
sistema. Desafortunadamente, con frecuencia este paso se elimina
si la instalación del sistema se retrasa de la fecha
indicada.
La prueba de sistema incluye reafirmar los
estándares de calidad para el desempeño del sistema que se
estableció cuando se hicieron las especificaciones
iniciales del sistema. Todos los involucrados deben estar de
acuerdo una ve mas en cómo determinar si el sistema
está haciendo lo que se supone que hace. Este paso
incluirá medidas de error, oportunidades, facilidad de
uso, clasificación apropiada de transacciones, tiempo
fuera de servicio aceptable y manuales de procedimiento
entendible.
Prueba completa de sistemas con datos reales
Cuando las pruebas de sistemas con datos de prueba se realizan de
manera satisfactoria, es bastante recomendable probar el nuevo
sistema repetidas con lo que se conoce como datos reales, datos
que se han procesados de manera exitosa con el sistema existente.
Este paso permite una comparación precisa de la salida del
nuevo sistema con la salida que sabe ha sido procesada
correctamente, y también es una buena opción para
probar como se manejarán los datos reales. Obviamente,
este paso no es posible al crear salida completamente nueva (por
ejemplo, salida de una transacción de comercio
electrónico de un nuevo sitio Web
corporativo).al igual que con los datos de prueba. Sólo se
usa pequeñas cantidades de datos reales en este tipo de
pruebas de sistemas.
Las pruebas constituyen un periodo importante para
evaluar la manera en que los usuarios finales y los operadores
interactúan realmente con el sistema. Aunque se da mucha
importancia a la interacción de usuario-sistema
(véase el capitulo 14), nunca podrá producir
totalmente el amplio rango de diferencias en la forme en que los
usuarios interactuarán realmente con el sistema. No basta
con entrevistar a los usuarios sobre cómo
interactúan con el sistema, debe observarlos
directamente.
OPORTUNIDAD DE CONSULTARÍA 16.3
ESTUDIANDO PARA SU PRUEBA DE SISTEMAS
Tenemos el tiempo encima. Tan solo mira esta
proyección, dice lou ecuntroll, el miembro mas nuevo de su
equipo de analisis de sistemas, mientras le muestra el diagrama
PERT que el
equipo ha estado usando para proyectar la fecha en que el nuevo
Sistema quedaría listo. Quizá no podemos cumplir la
fecha prevista de julio para reaLizar las pruebas con datos
reales. Estamos atrasados tres semanas debido a que el equipo se
embarcó tardes. Como uno de los analistas de sistemas que
han vivido la presión de
fijar y reprogramar fechas limite en otro proyectos, usted
intenta permanecer tranquilo y evaluar cuidadosamente la
situación antes de hablar. Lentamente usted planeas a lou
posibilidad de postergar las pruebas.
Lou contesta: sí tratamos de retrasar las pruebas
hasta las primeras semanas de agosto, en esas fechas dos personas
importante de contavalidad estarán de vacaciones. Lou
está visiblemente molesto con la posibilidad de retrasar
la fecha limite. Stan Dards, otro miembro reciente de su equipo
de análisis de sistemas, entra en la oficinas
de lou. Ambos tienen un aspectos pesimo. Todo está bien,
¿no es cierto? No me reasignaron a programar una
aplicación de Nómina,
¿o sí?A lou no le hace gracia el sentido del
humor
De Stan ni su aparente preocupación por sí
mismo. Todo estaba bien hasta antes de que lle- garas.
Estábamos apunto de tomar algunas dediciones importante
sobre el calendario. Lou le pasa a Stan el diagrama PERT para que
revise.
Observa la fecha de prueba de junio. Como podrás
darte cuenta, no hay manera de cumplirla. ¿Algunas
brillantes ideas?
Stan completa unos instantes el diagrama, luego
señala. Algo ha pasado. Veamos aquí…
quizá si movemos el modulo de contabilidad
a…
Lou lo interrumpe bruscamente: ¡no!, ya pensamos
en eso, pero estanford y bidet, de contabilidad, esta de
vacaciones en agosto. Quizás podríamos omitir esas
partes de las pruebas. Ellos han sido muy cooperativos. No creo
que ponga ninguna objeción si sacamos los sistemas y
hacemos las pruebas ya que estamos en las fases de
producción.
Creo que esa es una buena idea, lou, coincide Stan,
tratando de congraciarse con Lou después de su bromas
anteriores. No hemos tenidos ningún problema real con eso,
y los programadores son confiables. Así podríamos
mantener el calendario con todos los demás. Yo voto por no
probar la parte de contabilidad, y solo darle un vistazo cuando
se ponga en marcha.
Como el miembro con mas eperiensia del equipo,
¿Qué puede usted argumentar para convencer a Lou y
Stan de la importancia de probar el modulo de contabilidad con
datos reales? ¿Qué pueden hacer los analistas de
sistemas para planificar sus actividades de tal manera que le
dediquen un tiempo razonable a realizar las pruebas con datos
reales? ¿Cuáles son algunos de los posibles
problemas que los miembros de equipos podrían encontrar si
no prueban el sistema completamente con datos reales antes de
poner el sistema en producción? ¿Hay en el proceso
de análisis y diseños de sistemas pasos que pueden
omitirse con el propósito de poner al dia un proyecto
retrasado?
Los aspectos que debe vigilar con la facilidad con que
un usuario aprende el sistema y sus reacciones con su retroalimentación del sistema, incluyendo
lo que hace cuando recibe un mensaje de error y cuando se le
informa que el sistemas esta ejecutando sus comandos. Ponga
especial atención a las maneras en que racionan los
usuarios al tiempo de respuesta de sistema y a la redacción de las respuestas. También
escuche lo que dicen los usuarios acerca del sistema cuando
trabajan con él. Es necesario resolver todos los problemas
reales antes de que el sistema se ponga en producción, no
solo considerarlo como ajustes al sistema que los usuarios y
operadores deben hacer por sí mismos.
Como se mencionó anteriormente,
también los manuales de procedimientos necesitan ser
probados. Aunque los manuales se puedan corregir por el personal
de apoyo, y verificar su exactitud técnica por el equipo
de análisis de sistemas, la única forma real de
probarlo es tener usuarios y operadores que lo prueben, de
preferencia durante la pruebe de sistemas completos con datos
reales. Haga que usen versiones precisas, pero no necesariamente
versiones finales de los manuales.
Es difícil comunicar con precisión
los procedimientos. Demasiado información será con
un oct aculo para el uso del sistema. El uso de documento basado
en Web puede ayudar en esta consideración. Los usuraos
pueden pasar a los temas de interés y
recargar e imprimir lo que quieren conservar. Considere las
sugerencias de los usuarios e incorpórela en las versiones
finales de la página
Web, manuales impresos y otras
documentaciones.
PRÁCTICAS DE
MANTENIMIENTO
Su objetivo como
analistas de sistemas debe ser instalar o modificar sistemas que
tienen una vida bastante útil. Quiere crear un sistema
cuyo diseño es bastante comprensivo y previsivo para
atender las necesidades actuales y proyectadas del usuario
durante varios años. Debe usar parte de su experiencia
para proyectar lo que podría ser esas necesidades y
después construir flexibilidad y adaptabilidad en el
sistema. Lo mejor y más fácil del diseño de
sistemas será asegurar que el negocio tendrá
que gastar menos dineros en el mantenimiento.
Reducir los costos de
mantenimiento es una consideración principal, debido a que
el mantenimiento de software aislado puede consumir más de
50% del presupuesto de
procedimiento de datos para un negocio. Los costos de
mantenimiento excesivo se reflejan directamente en el
diseñador de sistemas, debido a que aproximadamente 70% de
errores de software se han atribuido al diseño de software
inadecuado. Desde una perspectiva de sistemas, tiene sentido que
detectar y corregir los errores de diseños de software es
menos costoso que permitir que permanezcan advertido hasta que
sea necesario el mantenimiento.
Por lo regular el mantenimiento se realiza para
mejorar el software existente en un lugar de responder a una
crisis o falla
del sistema. Al igual con el cambio de
requerimiento del usuario, el software y la documentación
se deben cambiar como parte del trabajo de
mantenimiento. Además, los programas se podrían
decodificar para mejorar la eficacia del
programa original. Mas de la mitad de todo el mantenimiento
está compuesto de dicho trabajo de
mejoras.
El mantenimiento también se hace para
actualizar el software en respuestas a la organización cambiante. Este trabajo no es
tan sustancial como mejorar el software, pero se debe hacer. El
mantenimiento de emergencia y de adaptación representa
menos de la mitad de todo el mantenimiento del
sistema.
Parte del trabajo del analista de sistemas es
asegurar que en el lugar haya procedimientos y canales adecuados
para permitir retroalimentación sobre ─y respuestas
sucecuente para ─las necesidades de mantenimientos. Los
usuarios deben poder
comunicar fácilmente los problemas y sugerencias aquellos
que estarán manteniendo el sistema. Es muy desalentador si
el sistema no se mantiene adecuadamente. Las soluciones
consisten en proporcionar a los usuarios accesos
a
Correo electrónicos para el soporte
técnico, así como también permitirle
descargar actualizaciones de productos o
ajusté de Web.
El analista de sistema también necesita
establecer un esquema de clasificación para permitir a los
usuarios designar las importancias percibidas durante el
mantenimiento sugerido o solicitado. Clasificar las solicitudes
permite a programadores de mantenimientos entender como estiman
los usuarios de importancia de sus solicitudes. Este punto de
vistea, junto con otros factores, se pueden tener en cuentas al
establecer el mantenimiento.
CÓMO AUDITAR
Auditar es otras formas de asegurar la calidad de
información contenida en el sistema ampliamente definido,
auditar se refiere a pedirle a un experto, qué no
esté involucrado en crear o usar un sistema, examinar la
información para determinar su fiabilidad ya sea que la
información se establezca o no para ser fiable, el
descubrimiento en su fiabilidad se comunica a otros con el
propósito de hacer la información del sistema mas
útil para ellos.
Generalmente hay dos tipos de auditores b para los
usuarios de información: interno y externo. Determinar si
ambos son necesarios para los sistemas que usted diseña.,
dependerá de que tipo de sistema sea. Los auditores
internos trabaja para la misma organización que posee el
sistema de
información, mientras que los externos (también
llamados independientes) se contractas por
fuera.
Los auditores externos se usan cuando el sistema
de información procesa datos qué influyen en las
declaraciones financieras de una compañía. Los
auditores externos auditan el sistema para asegurar la veracidad
de las declaraciones financieras que se producen. También
se podrían traer si ocurre algo fuera de lo normal que
involucra a los empleados de la compañía, tal como
la sospecha de un fraude
electrónico o un defalco.
Los auditados internos estudian los controles
usado en sistema de información para estar seguro que son
adecuados y que esta naciendo lo que deben hacer. También
prueban las suficiencias de controles de seguridad. Aunque
trabajan para la misma organización, los auditores
internos os informan a las personas responsables del sistemas que
está auditándole trabajo de los auditores internos
con frecuencia es mas detallado que el de los auditores
externos.
…………….
RESUMEN
El analista de sistema usa tres enfoques amplios,
de la
administración de calidad total
(TQM) para analizar y diseñar sistemas de
información: diseñar sistemas y software con un
enfoque descendente y modular; diseñar y documentar
sistemas y software usando métodos
sistemáticos; y probar sistemas y software de manera que
se pueda mantener y auditar fácilmente.
Seis sigmas son una cultura,
filosofía, metodología y enfoque para la calidad que
tiene como meta la eliminación de datos los defectos. Los
sietes pasos de enfoque seis sigma
son: (1) definir el problema; (2) observar el problema; (3)
analizar las causas; (4) actual en las causas; (5) estudiar los
resultados; (6) estandizar los cambios, y (7) sacar
conclusiones.
Los usuarios son extremadamente importantes para
establecer y evaluar, desde varias dimensiones, la calidad de los
sistemas de información de administración y de los sistemas de apoyo a
la toma de
decisiones. Se puede involucrar en la evaluación
entera de sistemas a trabas del establecimiento de fuerza de
tareas de SI o círculos de calidad.
TQM se puede implementar con éxitos al
tomar un enfoque descendente (arriba a abajo) para
diseñar. Este enfoque se refiere a observar primero lo
objetivos generales de las organización y después
dividirlos en requerimientos manejables de subsistemas. El
desarrollo modular hace la programación, depuración y
mantenimientos más fáciles de lograr. La
programación en módulos se complementa bien en un
enfoque descendente.
Dos sistemas vinculan programas en el entorno de
Windows. Uno e
DDE (intercambio dinámico de datos), el cual comparte
códigos usando archivos de bibliotecas de
vínculos dinámicos (DLL). Al usar DDE, un usuario
puede almacenar datos en un programa y después usarlo en
otro. Un segundo enfoque para vincular programas en Windows es
OLE (vinculación e incrustación de objetos). Debido
a su enfoque orientado a objetos, este método de
vinculación es superior a DDE para vincular datos y
gráficos de la
aplicación.
Una herramienta recomendada para diseñar un
sistema con enfoque descendente y modular se denomina diagrama de
estructura. Se
usan dos tipos de flechas para indicar los tipos de
parámetros que se pasan entre los módulos. El
primero se denomina pareja de datos y el segundo se denomina
bandejas de control. Los
módulos de un diagrama de estructura entran en una de tres
categorías: control, transformacional (a veces denominados
trabajador) y funcional o especializados.
"este es un lugar fascinante para trabajar. Estoy
seguro de que usted coincide conmigo ahora que ha tenido la
oportunidad de observarnos. A veces creo que debe ser divertido
ser de fuera… ¿no se siente como un
antropólogo que descubre una nueva cultura? Recuerdo
cuando llegue aquí por primera vez. Todo era tan nuevo,
tan extraño. ¡Vaya!, incluso el idioma era
diferente. No era un consumidor; era
un cliente. No
teníamos departamentos; teníamos unidades. No es
una cafetería para en empleados; es la taberna. Estos
también se aplican a la manera en que trabajamos. Todos
tenemos diferentes maneras de enfocar las casas. Creo que ha
logrado entender lo que Snowden quiere, pero también de
vez en cuando cometo algún error. Por ejemplo, si le doy
trabajo en un disco, igual de censillo es para él verlo
así que en un informe impreso.
¡Por eso también tengo computadoras
en mi escritorio! Siempre lo veo a usted tomar tantos
apuntes… sin embargo, creo que todo esto tiene sentido. Se
supones que usted documenta los que nosotros hacemos con nuestros
sistemas e información, así como lo que su equipo
hace, ¿no es así?"
PREGUNTAS
DE HYPERCASE
- Use el modulo FOLKLORE para completar la
documentación del sistema GEMS de la unidad de sistemas
de información general. Asegúrese de incluir
costumbres, anécdotas, proverbios y formas
artísticas. - En dos párrafos, sugiera una manera de
capturar los elementos de FOLKLORE en una PC de tal manera que
no sea necesario usar un registro en
papel. Asegúrese de que la solución que surgiera
incluya gráficos y textos. - Diseñe pantallas de entradas y salidas
para FOLKLORE que permitan ingresar datos con facilidad, y
proporcione mensaje que recuerden de inmediato los elementos de
FOLKLORE.
FIGURA
16.HC1
En Hypercase puede utilizar FOLKLORE para
documentar formas artísticas que los usuarios hayan creado
o corepilado para darle sentido a sus sistemas.
La parte de TQM es para ver que los programas y
sistemas se diseñan, documentan y mantienen adecuadamente.
Algunas de las técnicas estructuradas que pueden ayudar al
analista de sistemas son pseudos códigos, manuales de
procedimientos y FOLKLORE. El pseudo código
se usa con frecuencia para representar la lógica
de cada módulo o diagramas de
estructura. El seudo código se usar para repasos
estructurados. Los analistas de sistemas deben escoger una
técnica que se adapta bien con lo que se usó
previamente en la organización y que permita
flexicivilidad y fácil
modificación.
La prueba de programas específicos,
subsistemas y sistemas totales es esencial para la calidad. Las
pruebas se hacen para detectar cualquier programa existente con
los programas y sus interfaces antes de que el sistema se use
realmente. Las pruebas normalmente se hacen en formas ascendente,
con códigos de programas que primero se verifican en el
escritorio. La prueba del sistema completo con datos reales
(datos reales que se han procesados exitosamente con el sistema
viejo), se logra siguiendo varios pasos intermedios de pruebas.
Esta pruebe proporciona una oportunidad de resolver cualquier
problemas que surjan antes de que el sistema se ponga en
producción.
El mantenimiento del sistema es una
consideración importante. El software bien diseñado
puede ayudar a reducir los costos de mantenimientos. Los
analistas de sistemas necesitan establecer canales para reducir
la retroalimentación del usuario en las necesidades del
mantenimiento, debido a que los sistemas que no se mantienen
quedarán aspsoleto. Los sistemas Web pueden ayudar al
respecto al proporcional acceso electrónico con personal
técnico.
Los auditores internos y externos se usan para
determinar la falibilidad de la información del sistema.
Ellos comunican sus resultados de las auditoras a otros para
mejorar la utilidad de la información del
sistema.
……………………………………………
PALABRAS Y FACES CLAVE
Acoplamiento de sello
Administración de calidad total
(TQM)
Auditor interno
Bandeja de control (interruptor)
Biblioteca de vínculos dinámicos
(DLL)
Círculos de calidad de SI
Desarrollo modular
Diagrama de estructura
Diseño ascendente
Diseño descendente
Documentación de software
FOLKLORE
Intercambio dinámico de datos
(DDE)
Mantenimientos de software
Modulo de control
Modulo funcional
…………………………………….
Modulo transformacional
Parejas de datos
Pruebas completas sistemas con datos de
pruebas
Pruebas completas sistemas con datos
reales
Pruebas de programas con datos de
pruebas
Pruebas de vínculos con datos de prueba
(prueba de cadenas)
Pseudos código
Repaso estructurado
Seis sigmas
Subordinación inadecuada
Verificación de
escritorio
Vinculación e incrustación de
objetos (OLE)
PREGUNTAS DE REPASO
- ¿Cuáles son las tres enfoques
amplios disponibles para analista de sistemas para lograr la
calidad en los sistemas recientemente
desarrollados? - ¿Cuál es el factor mas importante
para establecer y evaluar la calidad de sistemas de informaron
o sistemas de apoyo a la toma de decisiones? ¿por
qué? - Defina el enfoque de administración de calidad total (TQM)
conforme se aplica al análisis y
diseño de sistemas de
información. - ¿Qué significa el término
seis sigmas? - ¿Qué es un circulo de calidad
SI? - Defina el significado de hacer un repaso
estructurado. ¿Quién debe estar involucrado?
¿Cuándo se debe hacer un repaso
estructurado? - Mencione las ventajas de tomar un enfoque
descendente para diseñar. - ¿Cuáles son las tres desventajas
principales de tomar un enfoque descendente para
diseñar? - Defina el desarrollo
modular. - Menciones cuatros lineamientos para la
programación modular correcta. - ¿Cómo ayudan los diagramas de
estructura al analista? - Mencione los dos tipos de flechas usados en los
diagramas de estructura. - ¿Por qué queremos mantener el
número de flechas al mínimo al usar los diagramas
de estructura? - ¿Por qué se deben pasar hacia
arriba las banderas de control en los diagramas de
estructura? - Mencione dos formas en que el diagrama de
flujo de datos ayuda a construir diagramas de
estructura. - Menciones las tres categorías de
módulos. ¿por qué se usan en los diagramas
de estructura? - ¿Cómo puede ayudar un sitio de
Web a mantener el sistema y su
documentación? - Proporcione dos razones que apoyen la necesidad
de sistemas bien desarrollado y documentación de
software. - defina los pseudos
códigos. - menciones las cuatros quejas principales que
los usuarios expresan sobre los manuales de
procedimiento. - ¿en cuales cuatros categorías el
método de documentación de FOLKLORE recopila la
información? - menciones seis lineamientos para escoger una
técnica de diseño y
documentación. - ¿de quien es la responsabilidad
principal para probar los programas de
cómputo? - ¿cuales es la diferencia entre datos de
pruebas y datos reales? - ¿Cuáles son los dos tipos de
auditores de sistemas?
…………………..
PROBLEMAS
- Unos de los miembro de sus equipo de
análisis ha estado desalentado los comentarios de los
usuarios sobre los estacares de calidad, argumentados que
debido a que ustedes son los expertos, realmente son los
únicos que hacen lo que constituye un sistema de
calidad. En un párrafo, explique a los miembros de su
equipo ¿Por qué es importante obtener las
opiniones de los usuarios para la calidad de sistemas. Use un
ejemplo. - dibuje un diagrama de estructura para el
sistemas de reporte crédito en la figura
16.EX1. - escribe el pseudocodigo para el problema numero
2. - escribe el pseudocodigo para la política de renta
de citron car proporcionada en la oportunidad de
consultaría 9.3. - escribe una tabla de contenido detallada para
un manual de
procedimientos que explique a los usuarios como conectarse
a la red de
computo de su escuela,
así como también la política de la red
(quien es un usuario autorizado, etc.). asegúrese de que
el manual se
escriba pensando en el usuario. - su equipo de análisis de sistema
está cerca de completar un sistema para meecham feeds.
Roger está bastante seguro de que los programas que ha
escrito para el sistema de inventario
meecham funcionario como se requiere, debido a que son
similares a los programas que han hecho antes. Su equipo ha
estado muy ocupado y le gustaría empezar a realizar las
pruebas completas de sistemas tan pronto como sea
posible.
Dos miembros jóvenes de su equipo han
propuesto lo siguiente:
- Omitir la verificación del escritorio de
los programas (debido a que programas similares se verifican en
otras instalaciones; rober está
deacuerdo). - Hacer la prueba de vínculos de
cantidades de datos para comprobar que el sistema
funcionará. - Hacer la prueba completa del sistema para la
prueba de datos reales para comprobar que el sistema
está funcionando.
Responda a cada uno de los tres pasos del programa
de prueba propuesto. Explique sus respuestas en un
párrafo.
7. proponga un plan de pruebas
modificado para meecham feeds (problema 6). Divida su plan en una
secuencia de pasos detallados.
………………………………
PROYECTOS DE GRUPO
- Divida su grupo en dos subgrupos. Un subgrupo
debe entrevistar a los miembros de otro subgrupo sobre sus
experiencias al registrarse en una clase. Se
deben diseñar preguntas que ayudará a documentar
el proceso del registro de su escuela. - Reúna a sus grupos para
desarrollar una página Web para un extracto de un manual
de FOLKLORE que documente el proceso de registro para una
clase, basado en el FOLKLORE que se utilizó en las
entrevistas
del proyecto 1. recuerde incluir ejemplos de costumbre,
anécdotas, proverbios y formas
artísticas.
……………………………………………….
BIBLIOGRAFÍA
SELECCIONADA
Dean, j. w., jr y j, r. Evans, total
quality, st. Paul, mn: west, 1964.
Deming, q. e., management for quality and
productivity, Cambridge, MA: MIT center for advanced
engineering study, 1981.
Juran,j. m., managerial breakthrough, new
York: McGraw-Hill, 1964.
Kendall, j. e. y p. kerola, ºA Foundation for
the use of Hypertext based documentation techniquesº,
journal of END USE Computing, Vol. 6, num. 1, invierno de
1994, pp. 4-14.
Kendall, K. E. y R. Losee, ºinformation
System FOLKLORE: A New Techninque for System
Documentationº, Information and management, Vol. 10,
num. 2, 1986, pp. 103-111.
Kendall, K. E. y S. Yoo, Pseudocodigo-Box
Diagrams: An Approach to More Understandable, Productive, And
Adaptable Software Desing and Codingº International
Journal on Policy and Information, vol. 12, num. 1, junio de
1988, pp. 39-51.
Lee, S. M. y M. J. Schniederjans, Operations
Management, Boston: Houghton-Mifflin, 1994.
ALLEN SCHMIDT, E KENDALL Y KENNETH
E. KENDALL
Aquí las tienes, como lo prometimos, dicen
chip y anna triunfalmente al entregar sus especificaciones a Mack
ROE, EL PROGRAMADOR DEL PROYECTO.
GRACIA º, responde Mack. ºT.tengo mucho
trabajo por delante. º
MACK empieza a crear un diagrama de estructura
para cada programa y luego pasar al diseño de cada
módulo. En la figura e 16.1 se muestra el diagrama de
estructura PRODUCE SOFTWARE CROSS-REFERENCE REPORT. La
ºcº antes de cada numero de modulo se refiere al
CROSS-REFERENCE REPOT(visible Analyst requiere una letra como
primer carácter en el nombre de un modulo). Este
borrador es el primero que Mack utiliza en un repaso estructurado
con Dee Ziner, una programada con experiencia.
FIGURA
E16.1
Diagrama de estructura PRODUCE
SOFTWARE CROSS-REFERENCE REPORT. El asterisco censillo (*) y el
asterisco doble (**) indican la segunda y la tercera ocurrencia
del modulo C140.
EPISODIO
Dee Ziner tiene varias sugerencias importantes
para mejorar la estructura. Ella dice: ºEl modulo C130,
PRINT ERROR LINE, está erróneamente subordinado al
modulo de llamada C120, READ HARDWARE RECORD. Se podría
hacer la pregunta: º ¿El programa debe imprimir una
línea de error para leer un HARDWARE RECORD ¿º
Puesto que la repuesta es no, el modulo debe colocarse en el
mismo nivel que C120, READ HARDWARE
RECORDº.
Dee continua analizando la situación con
Mack, y dice: "Lo mismo ocurre con el modulo C160, PRINT
SUBTOTALS LINES. Esta no es una función de
acumulación de subtotales de hardware y por lo tanto no se
debe llamar desde el modulo C150, ACUMULATE HARDWARE SUBTOTALS".
Dee continua el repaso y planea la pregunta: "¿Un SOFTWARE
RECORD se podría localizar en muchas maquinas?" Mack
responde que eso si es válido, y otro modulo de control,
PRINT SOFTWARE CROSS-REFERENCE LINE, se incluye en el diagrama de
estructura.
Mack procede a incorporar los cambios al diagrama
de estructura. Cuando se establece la jerarquía correcta,
se agrega al acoplamiento. Se pone especial cuidado a pasar el
mínimo de datos y a pasar control sólo hacia arriba
del diagrama de estructura. En la figura E16.2 se ilustra la
versión final. El modulo C116 es nuevo, y se utiliza el
archivo
SOFTWARE/HARDTWARE RELATION para enlazar un SOFTWARE RECORD se
pasa hacia abajo el modulo y el archivo de relación se lee
de manera aleatoria. EL HARTWARE INVENTORY NUMBER y el
interruptor de control RELATION NOT FOUND se pasan hacia arriba
de la estructura.
El diagrama de estructura final tiene una forma
funcional. Unos cuantos módulos de control en la parte
superior de la estructura, varios módulos trabajadores en
la mitad y unos cuantos módulos especializados en la parte
inferior le dan un aspecto general desquilibrado. Todos los
nombres de los módulos tiene la estructura
verbo-adjetivo-sustantivo, y describen la tarea que se realiza
una vez que termina la ejecución del modulo. Por ejemplo,
el modulo C150 tiene el verbo "accumulate", que describe la tarea
que desempeña el modulo "subtotals", un sustantivo, se
acumula, y "hardware" describe cuales subtotales se
acumulan.
Cada uno de los módulos del diagrama de
estructura se describió en el depósito. La figura
E16.3 ilustra la pantalla que describe la función del
modulo C100, PRODUCE SOFTWARE LINES. Observe que la
descripción del modulo contiene pseudocódigo que
muestran la lógica del modulo. Dado que PRODUCE SOFTWARE
LINES es un modulo de control, sus lógicas deben consistir
de bucles y tomas de decisiones, con muy pocas instrucciones
relativas a los detalles del procesamiento, como ADD o
READ.
Cada pareja de datos y control del diagrama de
estructura se podría describir también en el
depósito. El área related to ofrece un
vinculo a las entradas del deposito que contiene los detalles de
los elementos contenidos en las parejas de
datos.
"Bueno, creo que estamos apunto de terminar los
diagramas para los programadores", comenta
Chip.
"De crear los diagramas, sí", responde ana,
"pero lo podemos dar un poco mas", "¿Qué quieres
decir?", pregunta Chip, un tanto desconcertado.
"Usemos visible analyst para general las tablas de
la base de datos
para Microsoft
Access" responde Anna. "pienso que podríamos comenzar
con unas de las entidades principales, como SOFTWARE MASTER, y
utilizar la características de generación de
códigos de visible Analyst."
FIGURA
E16.3
Pantalla del deposito para el
modulo PRODUCE SOFTWARE LINES.
Anna y Chip proceden a trabajar con visible
Analyst para asegurarse de que se hayan definido todo los
elementos de SOFTWARE MASTER. Anna hace clic en Repository
y en Generaate Database Schema. Seleccionan el diagrama
COMPUTER SYSTEM y le dan el mismo nombre al esquema. Se genera el
esquema completo para el sistema de cómputo. E la figura
E13.4 se ilustra una parte del código que se
generó.
"Voy a copiar una parte de l esquemas para
trabajar sólo con el SOFTWARE MASTER", comenta Anna a
chip. Anna copia el código SQL generado
para el archivo SOFTWARE MASTER. El siguiente paso es crear una
consulta en banco en Microsoft
Access. Anna
ejecuta Microsoft Access y crea la
consulta. A continuación hace clic en el botón SQL
y pega el archivo SOFTWARE MASTER en la ventana
SQL.
"Tengo que cambiar el nombre de la tabla por el de
SOFTWARE y cambiar el tipo de consulta a Make Table", continua
Anna. Le da el nombre SOFTWARE a la nueva tabla. Anna hace clic
en el botón Run Quero y sierra la
consulta.
"¿Qué ocurrió? ", pregunta
Chip DESCONCERTADO. "No veo ninguna salida."
FIGURA
E16.4
Ejemplo de generación de
código.
Anna hace clic en el botón Tables.
"¡Dale un vistazo a nuestra nueva tabla"¡, exclama
Anna. Ella hace clic en la tabla SOFTWARE y en la vista
diseño. "Aquí tienes nuestra estructura de visible
Analyst, implementada en Microsoft Access."
"Ahora se ve fenomenal", DICE Chip con una amplia
sonrisa.
Los siguen generando tablas hasta que finalizan el
diseño.
"Creo que podemos dejarle el resto a los
programadores", comenta Anna. "Haríamos mejor en comenzar
el desarrollo de los planes de pruebas para cada
programa."
Los planes de pruebas contienen detalles acerca de
cómo determinar si los programas funcionan correctamente,
y se lo envía a Mack y Dee, quienes crearán los
datos para las pruebas. En cada archivo de prueba que se utiliza
en los programas por lotes se incluyen datos validos e
inválidos. Lo mismo ocurre con los sistemas interactivos,
excepto que los datos de prueba se escriben en formas semejantes
al diseño de las pantallas. Una vez que Mack termina de
probar sus programas y se convence de que funcionan
correctamente, reta a Dee a que encuentre algún error en
los programas. A su vez, Dee le pide a Mack que pruebes sus
programas en una especie de competencia
amistosa. Ambos están conscientes de que los programadores
no siempre detectan sus propios errores, porque conocen tanto sus
propios programas que podrían ignorar errores sutiles de
lógica.
EJERCICIOS
- Vea el diagrama de estructura PRODUCE SOFTWARE
CROSS-REF REP. Haga dable clic en algunos módulos para
ver sus entradas en el depósito. - Modifique el diagrama de estructura PRODUCE
HARDWARE INVESTMENT RPT. Agregue la función PRINT
INVESTMENT LINE en el rectángulo vacío que se
proporciona. PRINT HEADING LINES y WRITE REPORT LINE estan
subordinados a Este modulo. Describe cada function en el
desposito.- SHOW CHANGE DISPLAY
- ACCPET COMPUTER CHANGES
- VALIDATE CHANGES
- DISPLAY ERROR MESSAGE
- CONFIRM CHANGES
- Modifique el diagrama de estructura del archive
CHANGE COMPUTER. Incluya el símbolo de bucle y agregue
los siguientes módulos subordinados al modulo 160,
CHANGE COMPUTER RECORD (también vea
abajo):
Los siguientes módulos deben subordinarse
al modulo 220, PUT COMPUTER RECORD:
- FORMAT COMPUTER RECORD
- REWRITE COMPUTER RECORD
Pasando hacia arriba:
- Modulo:
Pasando hacia arriba:
- Modulo:
Pasando hacia abajo:
Pasando hacia arriba:
- Modulo:
Pasando hacia abajo:
Pasando hacia arriba:
- Modulo:
Pasando hacia abajo:
Pasando hacia arriba:
- Modulo:
Pasando hacia abajo:
- Modulo:
Pasando hacia abajo:
- Modulo:
DISPLAY ADD SOFTWARE
SCREENADD SOFTWARE SCREEN
ACCEPT ADD SOFTWARE
SCREENEXIT INDICATOR (control)
ADD SOFTWARE SCREEN DATA
VALIDATE ADD SOFTWARE
DATAADD SOFTWARE SCREEN DATA
CANCEL TRANSACTION
(control)VALID ADD SOFTWARE DATA
READ SOFTWARE RECORD
SOFTWARE INVENTORY
NUMBERRECORD FOUND (control)
VALIDATE HARDWARE
REQUIREMENTSADD SOFTWARE SCREEN DATA
VALID DATA (control)
ERROR MENSSAGE
DISPLAY ERROR MENSSAGE
ERROR MENSSAGE
PUT NEW SOFTWARE RECORD
VALID ADD SOFTWARE DATA
FORMAT SOFTWARE RECORD
Pasando hacia abajo:
Pasando hacia arriba:
VALID ADD SOFTWARE DATA
FORMATTED SOFTWARE
RECORD - Modulo:
- Modulo:
WRITE SOFTWARE RECORD
Pasando hacia abajo:
FORMATTED SOFTWARE RECORD
- Modifique el diagrama de estructura ADD SOFTWARE
RECORD agregando un símbolo de bucle y acoplando las
conexiónese siguientes acoplamiento se debe colocar en
la línea de conexión arriba de cada modulo
(también vea abajo):PRINT PROBLEM MACHINE REPORT
PRINT PROBLEM MACHINE LINES
READ MACHINE RECORD
DETERMINE PROBLEM MACHINE
PRINT PROBLEM MACHINE LINES
PRINT HEADING LINES
WRITE REPORT LINE
PRINT FINAL REPORT LINES
WRITE REPORTLINE
- Elabore el diagrama de estructura PRINT PROBLEM
MACHINE REPORT. A continuación se da un esquema de los
módulos, con cada módulos subordinados
sangrados:CHANGE SOFTWARE FILE
CHANGE SOFTWARE RECORD
GET SOFTWARE RECORD
DISPLAY SOFTWARE ID SCREEN
ACCEPT SOFTWARE ID SCREEN
FIND SOFTWARE RECORD
DISPLAY ERROR LINE
OBTAIN SOFTWARE CHANGES
DISPLAY CHANGE SCREEN
ACCEPT SOFTWARE CHANGE
VALIDATE CHANGES
DISPLAY ERROR LINE
PUT SOFTWARE RECORD
FORMT SOFTWARE RECORD
REWRITE SOFTWARE RECORD
- Elabore el diagrama de estructura CHANGE SOFTWARE
RECORD. Los módulos del programa con sus
módulos subordinados sangrados:INQUIRE SOFTWARE DETAILS
INQUIRE SOFTWARE RECORD
GET SOFTWARE RECORD
DISPLAY SOFTWARE ID SCREEN
ACCEPT SOFTWARE ID SCREEN
FIND SOFTWARE RECORD
DISPLAY ERROR LINE
DISPLAY INQUIRY SCREEN
FORMAT SOFTWARE INQUIRY
SCREENDISPLAY SOFTWARE INQUIRY
SCREEN - Elabore el diagrama de estructura SOFTWARE
DETAILS INQUIRY. los módulos se enlistan con sus
módulos subordinados sangrados: - Vea el diagrama de flujo del sistema ADD
COPMUTER.Programa:
Entrada:
Salida:
Programa:
Entrada:
Salida:
UPDATE SOFTWARE RELATIONAL
FILEUPDATE SOFTWARE INSTALLATION LIST,
documentoUPDATE INTALLED SOFTWARE SCREEN,
pantallaSOFTWARE RELATIONAL FILE,
discoINSTALLED SOFTWARE TRANSATION,
discoPRINT USER NOTIFICATION
REPORTINSTALLED SOFTWARE TANSATION,
discoUSER NOTIFICATION REPORT,
informe. - Modifique el flujo del sistema ADD SOFTWARE.
Agregue los siguientes rectángulos del diagrama abajo
del proceso manual INSTALL SOFTWARE. Incluye los archivos e
informes de
entrada y salida especificados para cada
programa: - Elabore el diagrama de flujo del sistema ADD
STAFF. Hay dos programas: ADD - STAFF y PRINT NEW STAFF LIST. La entrada para
el diagrama ADD STAFF es un listado NEW STAFF y una pantalla de
entrada ADD NEW STAFF. El archivo STAFF MASTER se actualiza y
se produce un nuevo archivo NEW STAFF LOG. Este último
archivo es entrada para el programa PRINT NEW STAFF LIDT, que
produce el informe NEW STAFF LIST. - Diseñe datos de pruebas en papel para
probar el programa ADD COMPUTER. Utilice Microsoft Access para
probar la pantalla. Anote cualquier
inconsistencia. - diseñe datos de pruebas y resultados
previstos para el programa ADD SOFTWARE. Utilice Microsoft
Access para probar la pantalla y anote si los resultados se
apagaron a sus predicciones. - diseñe datos de pruebas y resultados
previstos para el programa ADD TRANINIG CLASS. Utilice
Microsoft Access para probar la pantalla y anote si los
resultados se apagaron a sus perdiciones. - diseñe datos de pruebas en papel para
probar el programa CHANGE SOFTWARE EXPERT. Utilice Microsoft
Access para probar la pantalla. anote cualquier
inconsistencia.
Anderson Méndez
Estudiante de informática
Del politécnico de Azua República
Dominicana.
Trabajo final de procesadores de
texto.
 Página anterior | Volver al principio del trabajo | Página siguiente  |