Diseño de las pruebas y documentación del sistema.

Diseño de las pruebas.

Calidad, errores y pruebas

La calidad no es algo que se pueda agregar al software después de desarrollado si no se hizo todo el desarrollo con la calidad en mente. Muchas veces parece que el software de calidad es aquél que brinda lo que se necesita con adecuada velocidad de procesamiento. En realidad, es mucho más que eso. Tiene que ver con la corrección, pero también con usabilidad, costo, consistencia, confiabilidad, compatibilidad, utilidad, eficiencia y apego a los estándares.

Todos estos aspectos de la calidad pueden ser objeto de tests o pruebas que determinen el grado de calidad. Incluso la documentación para el usuario debe ser probada.

Como en todo proyecto de cualquier índole, siempre se debe tratar que las fallas sean mínimas y poco costosas, durante todo el desarrollo. Y además, es sabido que cuanto más tarde se encuentra una falla, más caro resulta eliminarla. Es claro que si un error es descubierto en la mitad del desarrollo de un sistema, el costo de su corrección será mucho menor al que se debería enfrentar en caso de descubrirlo con el sistema instalado y en funcionamiento.

Desde el punto de vista de la programación, nos interesa la ausencia de errores (corrección), la confiabilidad y la eficiencia. Dejando de lado las dos últimas, nos concentraremos en este capítulo en las pruebas que determinen que un programa está libre de errores.

Un error es un comportamiento distinto del que espera un usuario razonable. Puede haber errores aunque se hayan seguido todos los pasos indicados en el análisis y en el diseño, y hasta en los requisitos aprobados por el usuario. Por lo tanto, no necesariamente un apego a los requisitos y un perfecto seguimiento de las etapas nos lleva a un producto sin errores, porque aún en la mente de un usuario pudo haber estado mal concebida la idea desde el comienzo. De allí la importancia del desarrollo incremental, que permite ir viendo versiones incompletas del sistema.

Por lo tanto, una primera fuente de errores ocurre antes de los requerimientos o en el propio proceso de análisis. Pero también hay errores que se introducen durante el proceso de desarrollo posterior. Así, puede haber errores de diseño y errores de implementación. Finalmente, puede haber incluso errores en la propia etapa de pruebas y depuración.

Categorías de pruebas:

Según la naturaleza de lo que se esté controlando, las pruebas se pueden dividir en dos categorías:

• Pruebas centradas en la verificación.

• Pruebas centradas en la validación.

Las primeras sirven para determinar la consistencia entre los requerimientos y el programa terminado. Soporta metodologías formales de testeo, de mucho componente matemático. De todas maneras, hay que ser cuidadoso, porque no suele ser fácil encontrar qué es lo que hay que demostrar. La verificación consiste en determinar si estamos construyendo el sistema correctamente, a partir de los requisitos.

En general a los informáticos no les gustan las pruebas formales, en parte porque no las entienden y en parte porque requieren un proceso matemático relativamente complejo.

La validación consiste en saber si estamos construyendo el sistema correcto. Las tareas de validación son más informales. Las pruebas suelen mostrar la presencia de errores, pero nunca demuestran su ausencia.

Las pruebas y el desarrollo de software.

La etapa de pruebas es una de las fases del ciclo de vida de los proyectos. Se la podría ubicar después del análisis, el diseño y la programación, pero dependiendo del proyecto en cuestión y del modelo de proceso elegido, su realización podría ser en forma paralela a las fases citadas o inclusive repetirse varias veces durante la duración del proyecto.

La importancia de esta fase será mayor o menor según las características del sistema desarrollado, llegando a ser vital en sistemas de tiempo real u otros en los que los errores sean irrecuperables.

Las pruebas no tienen el objeto de prevenir errores sino de detectarlos5. Se efectúan sobre el trabajo realizado y se deben encarar con la intención de descubrir la mayor cantidad de errores posible.

Para realizar las pruebas se requiere gente que disfrute encontrando errores, por eso no es bueno que sea el mismo equipo de desarrollo el que lleve a cabo este trabajo. Además, es un principio fundamental de las auditorías. Por otro lado, es bastante común que a quien le guste programar no le guste probar, y viceversa.

A veces se dan por terminadas las pruebas antes de tiempo. En las pruebas de caja blanca (ver más adelante) no es mala idea probar un 85% de las ramas y dar por terminado luego de esto.

Otra posibilidad es la siembra de errores y seguir las pruebas hasta que se encuentren un 85% de los errores sembrados, lo que presumiblemente implica que se encontró un 85% de los no

sembrados6. Otros métodos se basan en la estadística y las comparaciones, ya sea por similitud con otro sistema en cantidad de errores o por el tiempo de prueba usado en otro sistema.

En un proyecto ideal, podríamos generar casos de prueba para cubrir todas las posibles entradas y todas las posibles situaciones por las que podría atravesar el sistema. Examinaríamos así exhaustivamente el sistema para asegurar que su comportamiento sea perfecto. Pero hay un problema con esto: el número de casos de prueba para un sistema complejo es tan grande que no alcanzaría una vida para terminar con las pruebas. Como consecuencia, nadie realiza una prueba exhaustiva de nada salvo en sistemas triviales.

En un sistema real, los casos de prueba se deben hacer sobre las partes del sistema en los cuales una buena prueba brinde un mayor retorno de la inversión o en las cuales un error represente un riesgo mayor.

Las pruebas cuestan mucho dinero. Pero para ello existe una máxima: “pague por la prueba ahora o pague el doble por el mantenimiento después”.

Todo esto lleva a que se deban planificar bien las pruebas, con suficiente anticipación, y determinar desde el comienzo los resultados que se deben obtener.

La idea de extreme programming es más radical: propone primero escribir los programas de prueba y después la aplicación, obligando a correr las pruebas siempre antes de una integración.

Se basa en la idea bastante acertada de que los programas de prueba son la mejor descripción de los requerimientos. Esto lo analizamos en un ítem especial.

Tipos de pruebas:

Analizaremos 5 tipos de pruebas:

• Revisiones de código
• Pruebas unitarias
• Pruebas de integración
• Pruebas de sistema
• Pruebas de aceptación
• No son tipos de pruebas intercambiables, ya que testean cosas distintas. En el ítem siguiente analizamos cada tipo.

Otra posible clasificación de las pruebas es:

• De caja blanca o de código.
• De caja negra o de especificación.

En las primeras se evalúa el contenido de los módulos, mientras en las segundas se trata al módulo como una caja cerrada y se lo prueba con valores de entrada, evaluando los valores de salida.

Vistas de este modo, las pruebas de caja negra sirven para verificar especificaciones.

Las pruebas unitarias suelen ser de caja blanca o de caja negra, mientras que las de integración, sistema y aceptación son de caja negra. Las tareas de depuración luego de encontrar errores son más bien técnicas de caja blanca, así como las revisiones de código. En todos los casos, uno de los mayores desafíos es encontrar los datos de prueba: hay que encontrar un subconjunto de todas las entradas que tengan alta probabilidad de detectar el mayor número de errores.

Revisiones de código:

Las revisiones de código son las únicas que se podrían omitir de todos los tipos de pruebas, pero tal vez sea buena idea por lo menos hacer alguna de ellas:

• Pruebas de escritorio
• Recorridos de código
• Inspecciones de código

La prueba de escritorio rinde muy poco, tal vez menos de lo que cuesta, pero es una costumbre difícil de desterrar. Es bueno concentrarse en buscar anomalías típicas, como variables u objetos no inicializados o que no se usan, ciclos infinitos y demás.

Los recorridos rinden mucho más. Son exposiciones del código escrito frente a pares. El programador, exponiendo su código, encuentra muchos errores. Además da ideas avanzadas a programadores nuevos que se lleva a recorrer.

Las llamadas inspecciones de código consisten en reuniones en conjunto entre los responsables de la programación y los responsables de la revisión. Tienen como objetivo revisar el código escrito por los programadores para chequear que cumpla con las normas que se hayan fijado y para verificar la eficiencia del mismo. Se realizan siguiendo el código de un pequeño porcentaje de módulos seleccionados al azar o según su grado de complejidad. Las inspecciones se pueden usar en sistemas grandes, pero con cuidado para no dar idea de estar evaluando al programador.

Suelen servir porque los revisores están más acostumbrados a ver determinados tipos de errores comunes a todos los programadores. Además, después de una inspección a un programador, de la que surge un tipo de error, pueden volver a inspeccionar a otro para ver si no cayó en el mismo error.

El concepto de extreme programming propone programar de a dos, de modo que uno escribe y el otro observa el trabajo. Si el que está programando no puede avanzar en algún momento, sigue el que miraba. Y si ambos se traban pueden pedir ayuda a otro par. Esta no sólo es una forma más social de programación, sino que aprovecha las mismas ventajas de los recorridos e inspecciones de código, y puede prescindir de ellos.

Pruebas unitarias:

Las pruebas unitarias se realizan para controlar el funcionamiento de pequeñas porciones de código como ser subprogramas (en la programación estructurada) o métodos (en POO).

Generalmente son realizadas por los mismos programadores puesto que al conocer con mayor detalle el código, se les simplifica la tarea de elaborar conjuntos de datos de prueba para testearlo.

Si bien una prueba exhaustiva sería impensada teniendo en cuenta recursos, plazos, etc., es posible y necesario elegir cuidadosamente los casos de prueba para recorrer tantos caminos lógicos como sea posible. Inclusive procediendo de esta manera, deberemos estar preparados para manejar un gran volumen de datos de prueba.

Los métodos de cobertura de caja blanca tratan de recorrer todos los caminos posibles por lo menos una vez, lo que no garantiza que no haya errores pero pretende encontrar la mayor parte.

El tipo de prueba a la cual se someterá a cada uno de los módulos dependerá de su complejidad. Recordemos que nuestro objetivo aquí es encontrar la mayor cantidad de errores posible. Si se pretende realizar una prueba estructurada, se puede confeccionar un grafo de flujo con la lógica del código a probar. De esta manera se podrán determinar todos los caminos por los que el hilo de ejecución pueda llegar a pasar, y por consecuente elaborar los juegos de valores de pruebas para aplicar al módulo, con mayor facilidad y seguridad.

Documentación del sistema.

En general se habla mucho de la documentación, pero no se la hace, no se le asigna presupuesto, no se la mantiene y casi nunca está al día en los proyectos de desarrollo de software.

Lo importante es la disponibilidad de la documentación que se necesita en el momento en que se la necesita.

Muchas veces se hace porque hay que hacerla y se escribe, con pocas ganas, largos textos, a la vez que se está convencido de estar haciendo un trabajo inútil. A veces se peca por exceso y otras por defecto. Ocurre mucho en la Web y con productos RAD. En ocasiones se olvida que el mantenimiento también debe llegar a la documentación.

La documentación se suele clasificar en función de las personas o grupos a los cuales está dirigida:

• Documentación para los desarrolladores.
• Documentación para los usuarios.
• Documentación para los administradores o soporte técnico.

La documentación para desarrolladores es aquélla que se utiliza para el propio desarrollo del producto y, sobre todo, para su mantenimiento futuro. Se documenta para comunicar estructura y comportamiento del sistema o de sus partes, para visualizar y controlar la arquitectura del sistema, para comprender mejor el mismo y para controlar el riesgo, entre otras cosas.

Obviamente, cuanto más complejo es el sistema, más importante es la documentación.

En este sentido, todas las fases de un desarrollo deben documentarse: requerimientos, análisis, diseño, programación, pruebas, etc... Una herramienta muy útil en este sentido es una notación estándar de modelado, de modo que mediante ciertos diagramas se puedan comunicar ideas entre grupos de trabajo.

Hay decenas de notaciones, tanto estructuradas como orientadas a objetos. Un caso particular es el de UML, que analizamos en otra obra. De todas maneras, los diagramas son muy útiles, pero siempre y cuando se mantengan actualizados, por lo que más vale calidad que cantidad.

La documentación para desarrolladores a menudo es llamada modelo, pues es una simplificación de la realidad para comprender mejor el sistema como un todo.

Otro aspecto a tener en cuenta cuando se documenta o modela, es el del nivel de detalle.

Así como cuando construimos planos de un edificio podemos hacer planos generales, de arquitectura, de instalaciones y demás, también al documentar el software debemos cuidar el nivel de detalle y hacer diagramas diferentes en función del usuario de la documentación, concentrándonos en un aspecto a la vez.

De toda la documentación para los desarrolladores, nos interesa especialmente en esta obra aquella que se utiliza para documentar la programación, y en particular hemos analizado la que se usa para documentar desarrollos orientados a objetos en el capítulo respectivo.

La documentación para usuarios es todo aquello que necesita el usuario para la instalación, aprendizaje y uso del producto. Puede consistir en guías de instalación, guías del usuario, manuales de referencia3 y guías de mensajes.

En el caso de los usuarios que son programadores, verbigracia los clientes de nuestras clases, esta documentación se debe acompañar con ejemplos de uso recomendados o de muestra y una reseña de efectos no evidentes de las bibliotecas.

Más allá de todo esto, debemos tener en cuenta que la estadística demuestra que los usuarios no leen los manuales a menos que nos les quede otra opción. Las razones pueden ser varias, pero un análisis de la realidad muestra que se recurre a los manuales solamente cuando se produce un error o se desconoce cómo lograr algo muy puntual, y recién cuando la ayuda en línea no satisface las necesidades del usuario. Por lo tanto, si bien es cierto que debemos realizar manuales, la existencia de un buen manual nunca nos libera de hacer un producto amigable para el usuario, que incluso contenga ayuda en línea. Es incluso deseable proveer un software tutorial que guíe al usuario en el uso del sistema, con apoyo multimedia, y que puede llegar a ser un curso online.

Buena parte de la documentación para los usuarios puede empezar a generarse desde que comienza el estudio de requisitos del sistema. Esto está bastante en consonancia con las ideas de extreme programming y con metodologías basadas en casos de uso.

La documentación para administradores o soporte técnico, a veces llamada manual de operaciones, contiene toda la información sobre el sistema terminado que no hace al uso por un usuario final. Es necesario que tenga una descripción de los errores posibles del sistema, así como los procedimientos de recuperación. Como esto no es algo estático, pues la aparición de nuevos errores, problemas de compatibilidad y demás nunca se puede descartar, en general el manual de operaciones es un documento que va engrosándose con el tiempo.

Diseño de entradas, procesos y salidas.

Diseño de entradas: 

(Diseñar el sistema de recopilación de datos)

Las especificaciones de entrada describen la manera en que los datos ingresarán al sistema para su procesamiento.  Las características de diseño de la entrada pueden asegurar la confiabilidad del sistema y producir resultados a partir de datos exactos, o también pueden dar como resultado la producción de información errónea.  Asimismo, el diseño de la entrada determina sí el usuario puede interactuar con el sistema de manera eficiente.  El diseño de la entrada es el enlace que une al sistema de información con el mundo y sus usuarios.  Algunos aspectos del diseño cambian, lo que depende si el sistema está orientado hacia lotes o en línea.  Pero sin considerar el sistema, existen aspectos generales en la entrada que todos los analistas deben tener en cuenta.

El diseño de la entrada consiste en el desarrollo de especificaciones y procedimientos para la preparación de datos, la realización de los pasos necesarios para poner los datos de una transacción en una forma utilizable para su procesamiento, así como la entrada de éstos.  La entrada de estos los datos se logra al instruir la computadora para que los lea ya sea de documentos escritos o impresos, o por personas que los escriben directamente en el sistema.

Controles de la cantidad de entrada. 
Existen varias razones que explican por qué un buen diseño debe controlar la cantidad de datos en la entrada.  Primero, las operaciones de preparación y entrada dependen de las personas.  Dado que los costos de la mano de obra son altos, los asociados con la preparación e ingreso de los datos también lo son altos.  Disminuir los requerimientos de datos puede reducir los costos y ocurrir lo mismo con los costos de mano de obra.  Segundo, la fase de entrada puede ser un proceso lento que toma mucho más tiempo que el que necesitan las computadoras para llevar a cabo sus tareas.  De hecho, la computadora quizá permanezca sin hacer nada durante el tiempo en que se preparan los datos y la entrada para su procesamiento.  Al disminuir los requerimientos de la entrada, el analista puede acelerar todo el proceso desde la captura de datos hasta que los resultados llegan a manos de los usuarios.

• Evitar Retrasos. Un retraso en el procesamiento, que es un resultado de las operaciones de preparación o de entrada de datos, recibe el nombre de cuello de botella.  Evitar los cuellos de botella debe ser siempre uno de los objetivos que el analista persiga al diseñar la entrada.

• Evitar errores de datos. En cierto sentido la tasa de errores depende de la cantidad de datos, ya que entre más pequeña sea ésta, menores serán las oportunidades para cometer errores.  Es común encontrar en las operaciones de venta al por menor una tasa promedio del 3% de error en las operaciones de entrada de datos.  Si el volumen de datos es de 10,000 transacciones por semana, entonces se presentarán aproximadamente 300 errores.  A pesar de lo anterior, el analista puede reducir el número de errores al disminuir el volumen de datos que deben ingresarse por cada transacción.  El analista también puede modificar las tasas de error de una operación a través del diseño de la entrada, ya que la forma en que deben ingresar los datos puede tener efectos sobre la incidencia de los errores.  Otro aspecto del control de errores es la necesidad de detectarlos cuando éstos se presentan.  Las verificaciones y balances en los programas para entrada de datos, denominadas técnicas de validación de entradas, también descubren errores en la entrada.

• Evitar pasos adicionales. Algunas veces el volumen de transacciones y la cantidad de datos en preparación, o en el trabajo de entrada de datos, es algo que no se puede controlar.  Cuando no es posible reducir el volumen de transacciones, el analista debe asegurar que el proceso sea lo más eficiente posible.  El analista experimentado también evitará diseños para la entrada que traigan como consecuencia una mayor cantidad de pasos a seguir.  El efecto que trae consigo ya sea añadir o quitar un paso cuando se alimentan los cheques al proceso bancario, será multiplicado muchas veces en el transcurso de un día de trabajo.

• Mantener la sencillez del proceso. Quizá el mejor consejo para los analistas es alcanzar todos los objetivos ya mencionados en la forma más sencilla posible.  Claro está que al incluir tantos controles sobre los errores las personas puedan tener dificultades al emplear el sistema.  En otras palabras. el control de los errores puede obstruir la tarea.  El sistema mejor diseñado se ajusta a las personas que lo utilizarán y al mismo tiempo, proporcionarán métodos para el control de los errores.  La simplicidad funciona y es aceptada por los usuarios.  En contraste, cuesta trabajo que los usuarios acepten diseños para la entrada que sean complejos o confusos, y no existe ninguna garantía para el éxito al instalar un sistema complejo.  En consecuencia, es aconsejable evitar la complejidad cuando hay opciones más sencillas.

• Validación dela entrada. Los diseños de las entradas tienen como finalidad reducir la posibilidad de cometer errores o equivocaciones durante la entrada de datos.  Sin embargo, siempre debe suponer que se presentarán errores. Estos deben detectarse durante la entrada y corregirse antes de guardar los datos o procesarlos.  Es mucho más difícil corregir datos equivocados después de almacenarlos que antes de hacerlo.  De hecho los datos equivocados se olvidan con frecuencia hasta que alguien utilice un reporte basado en esos datos y cuestiona su exactitud y validez.

Los analistas de sistemas deciden los siguientes detalles del diseño de entradas.

1. Qué datos ingresan al sistema.
2. Qué medios utilizar.
3. La forma en que se deben disponer o codificar los datos.
4. El diálogo que servirá de guía a los usuarios para dar entrada a los datos.
5. Validación necesaria de datos y transacciones para detectar errores.
6. Métodos para llevar a cabo la validación de las entradas y los pasos a seguir cuando se presentan errores.

Las decisiones de diseño para el manejo de entradas, especifican la forma en que serán aceptados los datos para su procesamiento por computadora. Los analistas deciden si los datos serán proporcionados directamente, quizá a través de una estación de trabajo, o por el uso de documentos, como talones de venta, cheques bancarios o facturas, donde los datos a su vez son transferidos hacia la computadora para su procesamiento.

Diseño de procedimientos: 
(Diseñar el sistema de procesamiento de datos)

Los procedimientos especifican qué tareas deben efectuarse al utilizar en sistema y quiénes son los responsables de llevarlas a cabo. Entre los procedimientos importantes se encuentran:

• Procedimientos para entrada de datos. Métodos para la captura de datos de las transacciones y su ingreso en el sistema de información.

• Procedimientos durante la ejecución. Pasos y acciones emprendidos por los operadores del sistema y, en ciertos casos, por los usuarios finales que interactúan con el sistema para alcanzar los resultados deseados.

• Procedimientos para el manejo de errores. Acciones a seguir cuando se presentan resultados inesperados.

• Procedimientos de seguridad y respaldo. Acciones para proteger al sistema y sus recursos contra posibles daños.

Diseño de las salidas:
(Diseño del sistema de informes y producción de documentos)

El término salida, como es probable que el lector lo conozca, se refiere a los resultados e información generados por el sistema. Para muchos usuarios finales, la salida es la única razón para el desarrollo del sistema y la base sobre la que ellos evaluarán la utilidad de la aplicación. En la realidad, muchos usuarios no operan el sistema de información y tampoco ingresas datos en él, pero utilizan la salida generada por el sistema. Cuando diseñan la salida, los analistas deben de realizar lo siguiente:

• Determinar qué información presentar.
• Decidir si la información será presentada en forma visual, verbal o impresa y seleccionar el medio de salida.
• Disponer la presentación de la información en un formato aceptable.
• Decidir cómo distribuir la salida entre los posibles destinatarios.

Para llevar a cabo las actividades antes mencionadas, se requieren decisiones específicas tales como el empleo de formatos ya impresos cuando se preparan reportes, cuántas líneas planear sobre una página impresa o si se debe emplear gráficas y colores.

 La salida es la única razón para el desarrollo del sistema y la base sobre la que ellos evaluarán la utilidad de la aplicación.  En la realidad, muchos usuarios no operan el sistema de información y tampoco ingresan datos en él, pero utilizan la salida generada por el sistema.

El diseño de la salida de la computadora debe avanzar en una forma organizada y bien pensada: tiene que desarrollarse correctamente mientras que al mismo tiempo se garantice que cada elemento de la salida está diseñado para que las personas encuentren que el sistema es fácil de emplear.

El termino salida se utiliza para denotar cualquier información, ya sea impresa o en una pantalla.  Cuando los analistas diseñan la salida:

• Identifican la salida específica que es necesaria para satisfacer los requerimientos de la información.
• Seleccionan los métodos para presentar la información.
• Crean los documentos, reportes u otros formatos que contienen la información producida por el sistema.

Un sistema de información debe alcanzar uno o más de los siguientes objetivos:

1. Expresar información relacionada con actividades pasadas, estado actual o protecciones para el futuro.
2. Señalar eventos importantes, oportunidades, problemas o advertencias.
3. Iniciar una acción.
4. Confirmar una acción.

El buen diseño de la salida de los sistemas, no puede ser desarrollado en forma independiente del uso que se dará a la salida.  En otras palabras, no se puede clasificar como buena una salida estéticamente atractiva o que haga uso de una nueva tecnología, a menos que satisfaga las necesidades de la organización y de sus usuarios.  El propio proceso de diseño comienza cuando el analista de sistemas identifica la salida que debe producir el sistema (un proceso que se inicia durante la determinación de requerimientos).

Aspectos importantes de las Salidas.
Cuatro preguntas, a las que debe darse respuestas en forma completa y apropiada, ayudan a los expertos de diseño de sistemas a comprender mejor lo que debe ser la salida de un nuevo sistema:

¿Quiénes Recibirán La Salida?
El usuario, ¿forma o no parte de la organización?, Quizá los usuarios externos tengan requerimientos específicos que no se pueden cambiar y que dictan los requerimientos de contenido, formato y medio de presentación.  Tal vez las organizaciones decidan presentar la misma información en forma diferente cuando ésta es enviada a los usuarios tanto externos como internos.

¿Cuántos Detalles Son Necesarios?
Pocos detalles son necesarios para indicarle a alguien que renové una licencia de manejo (nombre, dirección, fecha de renovación, cuota y una identificación de la salida como aviso de renovación).  Sin embargo, un informe trimestral de venta de ventas contiene muchos detalles con formatos diferentes que son de ayuda para trasmitir un mensaje (qué sucedió, cómo ocurrió y cuál fue el resultado) a todos los usuarios.  Asimismo, la cantidad de datos también sugiere si deben emplear métodos de impresión o de presentación en una pantalla.

¿Cuántos Y Que Tan Frecuente Es La Salida?
El calendario junto con la oportunidad de la salida, son guías específicas del diseño.  Algunas salidas se producen con poca frecuencia y sólo cuando aparecen ciertas condiciones: la emisión del aviso de renovación de licencia puede ocurrir cada 4 años, la emisión de una notificación de pago sucede cuando el saldo de la cuenta está vencido. sin embargo, la organización puede requerir cada mes una salida que indique todas las licencias que deben renovarse el próximo mes, o una salida cada semana que señale todas aquellas cuentas cuyo saldo se venció durante la semana. 

¿Qué Método Utilizar?
¿Debe ser impresa o presentada en pantalla?  La salida impresa se emplea con bastante frecuencia.  Sin embargo, si un sistema da respuestas del tipo sí o no a las consultas, a menudo es apropiado presentar la respuesta en una pantalla, algunos sistemas emplean una salida de audio para informarles sobre un nuevo número telefónico o el cambio de éste.