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 SCREEN
ADD SOFTWARE SCREEN
ACCEPT ADD SOFTWARE SCREEN
EXIT INDICATOR (control)
ADD SOFTWARE SCREEN DATA
VALIDATE ADD SOFTWARE DATA
ADD SOFTWARE SCREEN DATA
CANCEL TRANSACTION (control)
VALID ADD SOFTWARE DATA
READ SOFTWARE RECORD
SOFTWARE INVENTORY NUMBER
RECORD FOUND (control)
VALIDATE HARDWARE REQUIREMENTS
ADD 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 SCREEN
DISPLAY 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 FILE
UPDATE SOFTWARE INSTALLATION LIST, documento
UPDATE INTALLED SOFTWARE SCREEN, pantalla
SOFTWARE RELATIONAL FILE, disco
INSTALLED SOFTWARE TRANSATION, disco
PRINT USER NOTIFICATION REPORT
INSTALLED SOFTWARE TANSATION, disco
USER 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 siguiente |