Metodología del Sistema
Indice
El modelo esencial.
El modelo ambiental.
El modelo de comportamiento.
Diseño de sistema.
Programación.
Prueba de programas.
Modelo Esencial
z
El modelo esencial del sistema es un modelo de lo que el sistema debe hacer para
satisfacer los requerimientos del usuario,
diciendo lo mínimo posible acerca de como
se implanta.
Modelo Esencial
z
Cuando el analista habla con el usuario acerca de los requerimientos del sistema, debe evitar describir implantaciones
especificas de procesos (burbujas en un diagrama de flujo de datos) en el sistema.
z
No debe mostrar las funciones del sistema
que están siendo realizadas por humanos o
por sistemas de computo existentes.
Modelo que muestra como hará su
labor una función
Un modelo de cual es la función del sistema
z
Modelo esencial más apropiado de lo que la función del sistema debe realizar sin
importar su implantación final.
Modelo Esencial
z
El modelo esencial consiste en dos componentes principales:
1.- Modelo ambiental
2.- Modelo de comportamiento
Modelo Ambiental.
z
Para el analista de sistemas, la labor más
difícil en la especificación de un sistema es a
menudo determinar qué es parte del sistema
y qué no.
Modelo Ambiental
z El primer modelo importante que se debe desarrollar como analista es uno que no haga más que definir las interfaces entre el sistema y el resto del
universo, es decir, el ambiente.
z Por razones obvias, este modelo se conoce como el modelo ambiental. Por lo tanto, se necesita saber qué información entra al sistema desde el ambiente exterior, y qué información produce como salida al ambiente externo.
Modelo Ambiental
z Otro aspecto crítico del modelo ambiental consiste en identificar los acontecimientos que ocurren en el ambiente al cual debe responder el sistema.
z No para todos los acontecimientos;
z El ambiente en su totalidad genera un número infinito de acontecimientos.
z Sólo nos preocupan aquellos que (1) ocurren en el ambiente exterior y (2) requieren una respuesta del sistema.
Modelo Ambiental
z En un sistema grande se puede tomar en cuenta una cantidad de factores cuando se están
escogiendo las perspectivas del proyecto. Los más importantes:
z El deseo del usuario de lograr cierta participación en el mercado para el producto, o incrementarla a más de su nivel actual. Esto se puede hacer ofreciendo un nuevo producto o una mayor funcionalidad de uno existente.
Modelo Ambiental
z La legislación establecida por el gobierno, o de la ciudad. Por ejemplo tendría que hacerse un nuevo sistema para considerar los cambios en las leyes sobre impuestos.
z Deseo del usuario por minimizar gastos operativos de alguna área de su negocio. La mayor parte de las organizaciones que tienen ordenadores desde hace tiempo aprovecharon las oportunidades obvias de reducir el personal de oficina.
Modelo Ambiental
z
Deseo del usuario para lograr alguna ventaja estratégica para la línea de productos o
áreas de negocios que opera.
z
Un buen ejemplo de estos son las líneas aéreas donde mejor información acerca de tendencias del mercado y preferencias de los clientes pueden llevar a costos de
pasajes e itinerarios de aerolíneas más
eficientes.
Modelo Ambiental
z
Dos tópicos importantes en el modelo ambiental:
z
Herramientas usadas para definir el ambiente
z
Construcción del modelo ambiental
Herramientas usadas para definir el ambiente.
z
El modelo ambiental consta de tres componentes:
1.- Declaración de propósitos.
2.- Diagrama de contexto.
3.- Lista de acontecimientos.
La declaración de propósitos
z
Es la declaración textual breve y concisa del propósito del sistema, dirigida al nivel
administrativo superior, la administración de los usuarios, y otros que no están
directamente involucrados con el desarrollo
del sistema.
La declaración de propósitos
z Ejemplo de la declaración de propósito típica:
El propósito del Sistema de Procesamiento de Libros Ajax es manejar todos los detalles de los pedidos de los libros de los clientes, además del envío, facturación y cobro retroactivo a clientes con facturas vencidas.
La información acerca de los pedidos de los libros debe estar disponible para otros sistemas, tales como mercadeo, ventas y contabilidad.
El diagrama de contexto
z
Es un caso especial de diagrama de flujo de datos, en donde una sola burbuja representa todo el sistema.
z
La figura muestra un diagrama de contexto
de un sistema de pedidos de libros.
Diagrama de contexto
Diagrama de contexto Características
z
Características importantes del sistema:
z
Las personas, organizaciones y sistemas con los que se comunica el sistema. Se conocen como terminadores.
z
Los datos que el sistema recibe del mundo
exterior y que deben procesarse de alguna
forma.
Diagrama de contexto Características
z
Los datos que el sistema produce y que se envían al mundo exterior.
z
Los almacenes de datos que el sistema comparte con los terminadores. Estos almacenes de datos se crean fuera del
sistema para su uso, o bien son creados en él y usados fuera.
z
La frontera entre el sistema y el resto del
mundo.
Diagrama de contexto
La lista de acontecimientos
z
Es una lista narrativa de los estímulos que ocurren en el mundo exterior a los cuales el sistema debe responder.
z
A continuación se muestra una lista de
acontecimientos para el sistema de pedidos
de libros.
Diagrama de contexto
La lista de acontecimientos
1.- Un cliente hace un pedido (F).
2.- Un cliente cancela un pedido (F).
3.- La administración pide un reporte de ventas (T).
4.- Llega un pedido de reimpresión de un libro al almacén (C).
z F,T,C. - flujo, temporal, o de control.
Diagrama de contexto
La lista de acontecimientos
z
El orientado a flujos es el que se asocia con un flujo de datos; es decir, el sistema se da cuenta de que ha ocurrido el acontecimiento cuando llega algún dato (o posiblemente
varios).
z
Los acontecimientos temporales arrancan
con la llegada de un momento dado en el
tiempo
Diagrama de contexto
La lista de acontecimientos
z
Ejemplos de acontecimientos temporales :
A las 9:00 de la mañana se requiere un informe diario de todos los pedidos de libros.
Las facturas deben generarse a las 3:00 PM.
Se deben generar reportes administrativos una vez por hora.
Diagrama de contexto
La lista de acontecimientos
z Los acontecimientos de control deben considerarse un caso especial del acontecimiento temporal: un estímulo externo que ocurre en algún momento impredecible.
z A diferencia de un acontecimiento temporal normal, el acontecimiento de control no se asocia con el
paso regular del tiempo, por lo que el sistema no puede anticiparlo utilizando un reloj interno
Construcción del diagrama de contexto
z El diagrama de contexto consiste en terminadores, flujos de datos y flujos de control, almacenes de datos y un solo proceso que representa a todo el sistema.
z La parte más fácil del diagrama de contexto es el proceso; como hemos visto, consiste en una sola burbuja.
z El nombre dentro del proceso suele ser el nombre del sistema completo o un acrónimo convenido.
Diagrama de contexto
z
Nombre típico de proceso para un diagrama
de contexto
Terminadores
z
Los terminadores se representan con
rectángulos en el diagrama de contexto. Se comunican directamente con el sistema a través de flujos de datos o de control.
Comunicación directa entre terminado y sistema
Terminadores
z
Comunicación a través de un almacén
externo
Terminadores
z Punto en consideración de los terminadores:
z Algunos terminadores tienen un buen número de entradas y salidas. Para evitar un diagrama
innecesariamente atiborrado conviene dibujar el terminador más de una vez.
z Los terminadores duplicados se marcan con un asterisco.
Terminadores
z
Cuando el terminador es una persona
individual, generalmente es preferible indicar el rol que desempeña, más que su identidad.
z
Dado que estamos interesados en
desarrollar un modelo esencial del sistema, es importante distinguir entre fuente y
manejadores.
Terminadores
z
Un manejador es un mecanismo, dispositivo, medio físico usado para transportar datos
hacia o fuera del sistema. Dado que a
menudo, dichos manejadores son familiares y visibles para los usuarios de la
implantación actual de un sistema, existe la
tendencia a mostrar al manejador, en lugar
de la verdadera fuente de los datos.
Terminadores
z Los flujos que aparecen en el diagrama de contexto modelan datos que entran y salen del sistema,
además de las señales de control que recibe o genera.
z Los flujos de datos se incluyen en el diagrama de contexto si se ocupan para detectar un
acontecimiento en el ambiente al que deba
responder el sistema, o si se ocupan (como datos) para producir una respuesta.
Construcción de la lista de acontecimiento
z La lista de acontecimiento es un listado textual
sencillo de los acontecimientos del ambiente a los cuales debe responder el sistema. Al crear la lista de acontecimiento se debe asegurar de distinguir entre un acontecimiento y un flujo relacionado con un
acontecimiento.
z Por ejemplo, lo siguiente probablemente no sea un acontecimiento:
z "El sistema recibe el pedido del cliente"
Construcción de la lista de acontecimiento
z
Mas bien, sea el flujo de datos de entrada mediante el cual el sistema se da cuenta de que ha ocurrido el acontecimiento. Un
nombre más apropiado para el acontecimiento sería:
z
"El cliente hace un pedido"
Construcción de la lista de acontecimiento
z
La manera más fácil de identificar los acontecimientos para un sistema es visualizarlo en acción: examinar cada
terminador y preguntar qué efecto pueden
tener sus acciones sobre el sistema.
Construcción de la lista de acontecimiento
z
La lista de acontecimiento debe incluir no
sólo las interacciones normales ente el
sistema y sus terminadores sino también
situaciones de fallos.
Construcción de la lista de acontecimiento
z Por ejemplo, nuestra lista de acontecimiento para el Sistema de Pedido de Libros Ajax incluía un
acontecimiento llamado "el pedido de reimpresión de libro llega al almacen".
z Pero ¿Qué tal si no llega a tiempo (por ejemplo, una semana después de la fecha prometida por el
impresor)? ¿Qué debería hacer el sistema?, Por lo que se necesitaría un acontecimiento adicional
iniciado por el sistema para hacer que se comunique con el impresor y localice el origen del retraso.
Ejemplos
La declaración de propósitos.
z
El propósito del Sistema de Información de
YOURDON Press (YPIS) es almacenar la
información necesaria para vender libros a
los clientes. Esto incluye ingreso de pedidos,
facturación, generación de documentos de
envío, control de inventarios y producción de
reportes de regalías por derechos de autor y
reportes de contabilidad.
Ejemplos
La lista de acontecimientos.
z
La lista de acontecimientos del sistema YPIS consiste en 40 acontecimientos.
z
La mayoría están dirigidos por flujos, aunque la mayoría de los que involucran al
departamento de contabilidad son
temporales.
Ejemplos
La lista de acontecimientos.
Listado de acontecimientos:
"T“ - Temporales
z El cliente pide un libro.
z El cliente envía su pago.
z El cliente pide información sobre algún libro (precio, etc.).
z El cliente pide permiso de devolver un libro
z El cliente pregunta sobre el status de algún pedido.
z El cliente pregunta sobre el status de alguna factura.
z El cliente requiere de una declaración (mensual). (T)
Ejemplos
La lista de acontecimientos.
z El cliente pide un recordatorio de un crédito.
z El cliente desea un cheque de reembolso.
z El departamento de contabilidad requiere de recibos (diarios) de efectivo. (T)
z El departamento de contabilidad requiere de reportes de ventas (diarios). (T)
z El departamento de contabilidad requiere de un reporte (mensual) de ventas netas.(T)
z El departamento de contabilidad requiere de un reporte (trimestral) por derechos de autor. (T)
Ejemplos
La lista de acontecimientos.
z El departamento de contabilidad requiere de datos (mensual) de inventario. (T)
z El departamento de contabilidad requiere de un reporte (mensual) de comisiones sobre ventas. (T)
z La gerencia fija un nuevo límite de crédito para un cliente.
z El departamento de contabilidad requiere un reporte (mensual) de cuentas por pagar retrasadas.
z La imprenta da una cotización de pedido de impresión
Ejemplos
La lista de acontecimientos.
z La administración autoriza un pedido de impresión.
z La imprenta notifica la cantidad exacta de impresos y fechas de entrega.
z La imprenta envía factura por concepto de trabajo de impresión.
z La administración solicita cotización de un pedido de impresión.
z El departamento de almacen pide etiquetas de envío de la base de datos de clientes.
Ejemplos
La lista de acontecimientos.
z El departamento de almacén requiere de estadísticas sobre las ventas de libros.
z El departamento de almacén necesita una fecha de disponibilidad de nuevos títulos.
z Los editores anuncian un nuevo título.
z Los autores necesitan un reporte trimestral de utilidades por concepto de derechos de autor. (T)
z El almacén necesita datos de envío y etiquetas. (T)
z El almacén recibe libros de la imprenta.
z El almacén recibe devoluciones de libros de un cliente.
Ejemplos
La lista de acontecimientos.
z El almacén hace un inventario físico (mensual).
z El almacén envía un pedido a un cliente.
z El almacén anuncia que un libro se ha agotado.
z El departamento de adquisiciones anuncia el proyecto de un nuevo libro.
z Un vendedor ingresa un pedido de parte de un cliente.
z El departamento de mercadeo declara que un libro está agotado.
z El cliente notifica un cambio de domicilio.
z El autor notifica un cambio de domicilio.
z El cliente elige participar en el plan de agencia.
z Se necesita enviar facturas a un cliente. (T)
Ejemplos
La lista de acontecimientos.
z
El cliente envía su pago.
Ejemplos
La lista de acontecimientos.
z El pago puede cubrir diversas facturas distintas, pero no
siempre queda claro de cuáles facturas se trata. A veces los clientes no identifican la factura que están pagando; a veces identifican facturas que ya se pagaron; en ocasiones dan como referencia números de facturas inexistentes.
z A veces no queda claro incluso de dónde viene el pago. Esto sucede sobre todo en el caso de cadenas de librerías.
z No existe garantía de que el pago sea por la cantidad exacta de la factura. Algunos clientes tratan de evitar el pago del impuesto sobre la venta y los gastos de envío.
Ejemplos
La lista de acontecimientos.
z
El cliente pide información sobre algún libro (precio, etc.).
Notas:
El cliente generalmente
pregunta cosas tales como el precio del libro, o cuándo se espera tener en existencia cierto libro, o el programa de descuento por volumen.
Ejemplos
La lista de acontecimientos.
z
El departamento de contabilidad requiere de
recibos (diarios) de efectivo. (T)
Practicas a realizar
Acontecimiento 6.- El cliente pregunta acerca del status de una factura.
Acontecimiento 9: Un cliente desea un cheque de reembolso
Acontecimiento 10: La contabilidad requiere recibos (diarios) de efectivo
Acontecimiento 12: El departamento de contabilidad necesita un reporte de ventas "netas" (mensual)
Practicas a realizar
Acontecimiento 14: El departamento de contabilidad requiere datos de inventario (mensuales).
Acontecimiento 34: El departamento de
adquisiciones anuncia un nuevo proyecto de libro
Acontecimiento 37: El cliente anuncia un cambio de domicilio
Modelo de Comportamiento.
z Dentro del modelo de comportamiento se
involucrará el desarrollo de un diagrama de flujo de datos y un diagrama de entidad-relación
preliminares, además de la elaboración de las entradas iniciales del diccionario.
z Para explicar el modelo de comportamiento utilizaremos el enfoque de partición por
acontecimiento, el cual incluye los siguientes cuatro pasos:
Modelo de Comportamiento
z Se dibuja una burbuja, o proceso, para cada acontecimiento de la lista.
z La burbuja se nombra describiendo la respuesta que el sistema debe dar al acontecimiento asociado.
z Se dibujan las entradas y salidas apropiadas de tal forma que la burbuja pueda dar la respuesta
requerida, y se dibujan los almacenes, como sea apropiado, para la comunicación entre burbujas.
z El borrador de DFD que resulta se compara con el diagrama de contexto y la lista de acontecimientos para asegurar que está completo y sea consistente.
Modelo de Comportamiento
z El primer paso es directo y mecánico: si existen 25 acontecimientos en la lista, se deben dibujar 25 burbujas.
z El segundo paso también es directo y mecánico:
a cada burbuja se le da un nombre apropiado, basado en la respuesta requerida.
z ¿Esto significa que se debe examinar el
acontecimiento y preguntar qué respuesta debe dar el sistema a este Acontecimiento?.
Modelo de Comportamiento
z
El tercer paso definitivamente no es
mecánico, pero usualmente es bastante directo. Para cada burbuja dibujada,
identifique las entradas que requiere para efectuar su trabajo.
z
Identifique las salidas que cada una
produce e identifique los almacenes a los
que cada burbuja debe tener acceso.
Modelo de Comportamiento
z
Esto normalmente se hace entrevistando al usuario o usuarios apropiados y
concentrándose en cada acontecimiento y su burbuja asociada.
z
Las preguntas son: ¿Qué necesita esta
burbuja para hacer su trabajo? y ¿Qué
salidas genera?.
Modelo de Comportamiento
z En muchos casos el acontecimiento está determinado por el flujo.
z El sistema detecta la ocurrencia de un
acontecimiento por la llegada de algún dato de un terminador externo, esto es, se pueden requerir entradas adicionales (de otros terminadores, y de almacenes de datos) para que un proceso produzca su salida requerida.
z
De manera similar, como parte de la
respuesta dibuje las salidas adecuadas producidas por el proceso.
z
En muchos casos, esto implicara devolver salidas a los terminadores fuera del sistema;
sin embargo, puede también involucrar
salidas que se envían a los almacenes de datos, para ser usadas como entradas de otros procesos.
Modelo de Comportamiento
z
Entradas y salidas de un proceso
Modelo de Comportamiento
z El cuarto paso es una actividad de verificación de consistencia.
z Verifique cada entrada del diagrama de contexto para ver si está conectada con alguna entrada de alguno de los procesos del DFD preliminar, y
verifique también que cada salida producida por algún proceso en el DFD preliminar se envíe a un almacén o sea una salida externa incluida en el diagrama de contexto.
Modelo de Comportamiento
Existen dos casos especiales:
– (1) acontecimientos únicos que causan respuestas múltiples y,
– (2) acontecimientos múltiples que causan la misma respuesta.
z En el primer caso, un solo acontecimiento puede
causar múltiples respuestas, cada una de las cuales se modela con su propia burbuja en el DFD
preliminar.
z Sólo es apropiado si todas las respuestas usan el mismo flujo de datos de entrada, y sólo si todas las respuestas son independientes entre sí.
Modelo de Comportamiento
z
De manera inversa, habrá situaciones
ocasionales en las que un proceso se asocia con más de un acontecimiento.
z
Es válido y apropiado sólo si la respuesta de la burbuja es idéntica para los diversos
acontecimientos, y sólo si los datos de entrada y salida son idénticos para las diversas respuestas a acontecimientos.
Modelo de Comportamiento
Modelo de Comportamiento
z Obsérvese que en los ejemplos anteriores ninguno de los procesos en el diagrama de flujo de datos preliminar está conectado con otro; las burbujas no se comunican directamente con otras. En vez de eso se comunican entre sí através de otros
almacenes de datos.
z Una vez hecho esto se procede a un proceso de limpieza, el cual se describirá posteriormente, para producir un modelo bien organizado del proceso y un modelo de datos para presentarlo al usuario final.
Este enfoque se llamó partición por acontecimientos.
Diseño de Sistemas
z Como analista, puede no sentir interés por los detalles del diseño de sistemas o de programas; sin embargo, la labor de analista y la del diseñador no siempre se pueden separar
debido a que, el analista debe asegurarse de entender los requerimientos del usuario, mientras que el diseñador debe asegurar que dichos requerimientos se puedan implantar de manera realista con la tecnología computacional actual.
z Existe otra razón para tener interés en el diseño de sistemas:
tal vez le toque hacerlo.
z Sobre todo en los sistemas pequeños y medianos, a menudo se espera que el mismo individuo documente los
requerimientos del usuario y además desarrolle el diseño.
Diseño de Sistemas
z La actividad de diseño involucra el desarrollo de una serie de modelos.
z Los modelos más importantes para el diseñador son el modelo de implementación de sistemas y el modelo de implementación de programas.
z El modelo de implantación de sistemas se divide luego en un modelo de procesador, y uno de tareas.
z En el nivel del modelo del procesador, el diseñador del sistema trata principalmente de decidir como asignar el modelo
esencial a los distintos procesadores(CPU) y como deben comunicarse entre sí. Existe típicamente una variedad de opciones:
Diseño de Sistemas
z
El modelo esencial completo se le puede asignar a un solo procesador
z
Cada burbuja de la figura del DFD del modelo esencial se puede asignar a un procesador distinto (solución distribuida).
z
Se pude escoger una combinación de
Ordenadores principales, para minimizar
costos, maximizar confiabilidad o lograr
algún otro objetivo.
Programación.
z
La programación comienza cuando termina la actividad de diseño. En esta fase
se involucra la escritura de instrucciones en C++, Pascal, o algún otro lenguaje de
programación para implantar lo que el
analista ha especificado y el diseñador ha organizado en módulos.
z
Como programadores se pueden enfrentar a
los siguientes problemas:
Programación.
z
Productividad: esto es escribir más
software, más rápidamente. La principal
razón de esto es la enorme cantidad de
sistemas y aplicaciones que siguen en
espera en las grandes organizaciones.
Programación.
z Eficiencia: la eficiencia es de gran importancia en muchos sistemas de tiempo real, y en sistemas que procesan grandes volúmenes de datos (ejemplo, sistemas en bancos, reservación en aerolíneas, compañías de bolsas y compañías de seguro).
z La meta de eficiencia usualmente entra en conflicto con otras metas discutidas: si se emplea mucho tiempo en la
construcción de un sistema eficiente, es probable que sea menos mantenible y menos transportable, y que tenga más errores residuales sutiles, además de que tal vez reduzca la productividad de la persona que escribió el programa.
Programación.
z Corrección: se podría argumentar que esto es lo más importante. Después de todo, si el programa no funciona correctamente, no importa que tan eficiente sea. Por ejemplo, se prefieren lenguajes de
programación como Ada y Pascal si la corrección es de importancia crítica, en caso de que se estuviera construyendo sistemas de la Guerra de las Galaxias o el sistema de control para un reactor nuclear,
porque son de "tipos rígidos".
Programación.
z Portabilidad: en algunos ambientes esto es importante;
z El usuario puede desear ejecutar el mismo sistema en distintos medios.
z Por ello, además del lenguaje de programación debemos
preocuparnos por el estilo de programación, sí la portabilidad es un factor importante.
z Mantenibilidad: como los sistemas viven durante mucho tiempo, por lo tanto el software debe mantenerse.
Prueba.
z En muchos casos, el analista trabaja de manera
cercana con el usuario para desarrollar un conjunto eficaz y de gran alcance de casos de prueba
basados en el modelo esencial y el modelo de implantación del usuario.
z Este proceso puede llevarse a cabo en paralelo con las actividades de implantación del diseño y de la programación, para que, cuando los programadores terminen de escribir sus programas y de realizar sus propias pruebas locales, el equipo del
analista/usuario esté listo con sus propios casos de prueba.
Prueba.
z Existen distintas estrategias de prueba, las dos más comunes se conocen como prueba ascendente y descendente.
z El enfoque ascendente empieza por probar módulos individuales separadamente (prueba de módulos).
Luego, los módulos individuales se combinan para forma unidades que se probaran en masas (pruebas de subsistemas).
z Finalmente, todos los componentes del sistema se combinan para probarse (prueba del sistema).
Prueba.
z
El enfoque de prueba descendente empieza con un esqueleto del sistema; es decir, la
estrategia de prueba supone que se han desarrollado los módulos ejecutivos de alto nivel del sistema, pero que los de bajo nivel existen sólo como módulos vacíos;
z
Ejemplo de módulo vacío es uno que no
procesa nada, sino que simplemente termina
luego de ser llamado.
Prueba.
z Tipos de pruebas:
z Prueba funcional: Su propósito es asegurar que el sistema realiza sus funciones normales de manera correcta. Así, los casos de prueba se desarrollan y se alimentan al sistema; las salidas se examinan para ver si son correctos.
z Prueba de recuperación: El propósito de este tipo de prueba es asegurar que el sistema pueda recuperarse adecuadamente de diversos tipos de fallos, como: fallos de hardware, fallos de corriente, fallos en el sistema operativo, etc.
z Prueba de desempeño: El propósito de este tipo de prueba es asegurar que el sistema pueda manejar el volúmen de datos y transacciones de entrada especificados en el módulo de
implantación del usuario, además de asegurar que tenga el tiempo de respuesta requerido.
Prueba.
z
Para poder realizar una excelente prueba se necesita de tres cosas:
z
un plan de prueba,
z
descripciones de pruebas y
z
procedimiento de prueba.
z
Un plan de prueba es un documento
organizado que describe las actividades de
prueba.
Prueba.
Un documento de planeación de pruebas:
z Propósito de la prueba: cuál es el objetivo de la prueba, y qué parte del sistema se está probando.
z Localización y horario de la prueba: dónde y cuando se hará.
z Descripción de la prueba: descripción de las entradas que se proporcionarán al sistema, y las salidas y resultados que se anticipan.
z Procedimiento de prueba: descripción de cómo se deben preparar y presentar los datos de prueba al sistema; cómo
capturar los resultados de salida, cómo analizar los resultados de las pruebas, y cualesquiera otros procedimientos
operacionales que se deben observar.
