Metodologa del Sistema

Indice
El modelo esencial.
El modelo ambiental.
El modelo de comportamiento.
Diseo de sistema.
Programacin.
Prueba de programas.
Modelo Esencial
El modelo esencial del sistema es un modelo
de lo que el sistema debe hacer para
satisfacer los requerimientos del usuario,
diciendo lo mnimo posible acerca de como
se implanta.
Modelo Esencial
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.
No debe mostrar las funciones del sistema
que estn siendo realizadas por humanos o
por sistemas de computo existentes.
Modelo que muestra como har su
labor una funcin
Un modelo de cual es la funcin del
sistema
Modelo esencial ms apropiado de lo que la
funcin del sistema debe realizar sin
importar su implantacin final.
Modelo Esencial
El modelo esencial consiste en dos
componentes principales:
1.- Modelo ambiental
2.- Modelo de comportamiento
Modelo Ambiental.
Para el analista de sistemas, la labor ms
difcil en la especificacin de un sistema es a
menudo determinar qu es parte del sistema
y qu no.
Modelo Ambiental
El primer modelo importante que se debe desarrollar
como analista es uno que no haga ms que definir
las interfaces entre el sistema y el resto del
universo, es decir, el ambiente.
Por razones obvias, este modelo se conoce como el
modelo ambiental. Por lo tanto, se necesita saber
qu informacin entra al sistema desde el ambiente
exterior, y qu informacin produce como salida al
ambiente externo.
Modelo Ambiental
Otro aspecto crtico del modelo ambiental consiste
en identificar los acontecimientos que ocurren en el
ambiente al cual debe responder el sistema.
No para todos los acontecimientos;
El ambiente en su totalidad genera un nmero
infinito de acontecimientos.
Slo nos preocupan aquellos que (1) ocurren en el
ambiente exterior y (2) requieren una respuesta del
sistema.
Modelo Ambiental
En un sistema grande se puede tomar en cuenta
una cantidad de factores cuando se estn
escogiendo las perspectivas del proyecto. Los ms
importantes:
El deseo del usuario de lograr cierta participacin en
el mercado para el producto, o incrementarla a ms
de su nivel actual. Esto se puede hacer ofreciendo
un nuevo producto o una mayor funcionalidad de
uno existente.
Modelo Ambiental
La legislacin establecida por el gobierno, o de la
ciudad. Por ejemplo tendra que hacerse un nuevo
sistema para considerar los cambios en las leyes
sobre impuestos.
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
Deseo del usuario para lograr alguna ventaja
estratgica para la lnea de productos o
reas de negocios que opera.
Un buen ejemplo de estos son las lneas
areas donde mejor informacin acerca de
tendencias del mercado y preferencias de
los clientes pueden llevar a costos de
pasajes e itinerarios de aerolneas ms
eficientes.
Modelo Ambiental
Dos tpicos importantes en el modelo
ambiental:
Herramientas usadas para definir el
ambiente
Construccin del modelo ambiental
Herramientas usadas para definir el
ambiente.
El modelo ambiental consta de tres
componentes:
1.- Declaracin de propsitos.
2.- Diagrama de contexto.
3.- Lista de acontecimientos.
La declaracin de propsitos
Es la declaracin textual breve y concisa del
propsito del sistema, dirigida al nivel
administrativo superior, la administracin de
los usuarios, y otros que no estn
directamente involucrados con el desarrollo
del sistema.
La declaracin de propsitos
Ejemplo de la declaracin de propsito tpica:
El propsito del Sistema de Procesamiento de
Libros Ajax es manejar todos los detalles de los
pedidos de los libros de los clientes, adems del
envo, facturacin y cobro retroactivo a clientes con
facturas vencidas.
La informacin acerca de los pedidos de los libros
debe estar disponible para otros sistemas, tales
como mercadeo, ventas y contabilidad.
El diagrama de contexto
Es un caso especial de diagrama de flujo de
datos, en donde una sola burbuja representa
todo el sistema.
La figura muestra un diagrama de contexto
de un sistema de pedidos de libros.
Diagrama de contexto
Diagrama de contexto
Caractersticas
Caractersticas importantes del sistema:
Las personas, organizaciones y sistemas
con los que se comunica el sistema. Se
conocen como terminadores.
Los datos que el sistema recibe del mundo
exterior y que deben procesarse de alguna
forma.
Diagrama de contexto
Caractersticas
Los datos que el sistema produce y que se
envan al mundo exterior.
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.
La frontera entre el sistema y el resto del
mundo.
Diagrama de contexto
La lista de acontecimientos
Es una lista narrativa de los estmulos que
ocurren en el mundo exterior a los cuales el
sistema debe responder.
A continuacin 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 administracin pide un reporte de ventas (T).
4.- Llega un pedido de reimpresin de un libro al
almacn (C).
F,T,C. - flujo, temporal, o de control.
Diagrama de contexto
La lista de acontecimientos
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 algn dato (o posiblemente
varios).
Los acontecimientos temporales arrancan
con la llegada de un momento dado en el
tiempo
Diagrama de contexto
La lista de acontecimientos
Ejemplos de acontecimientos temporales :
A las 9:00 de la maana 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
Los acontecimientos de control deben considerarse
un caso especial del acontecimiento temporal: un
estmulo externo que ocurre en algn momento
impredecible.
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
Construccin del diagrama de
contexto
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.
La parte ms fcil del diagrama de contexto es el
proceso; como hemos visto, consiste en una sola
burbuja.
El nombre dentro del proceso suele ser el nombre
del sistema completo o un acrnimo convenido.
Diagrama de contexto
Nombre tpico de proceso para un diagrama
de contexto
Terminadores
Los terminadores se representan con
rectngulos en el diagrama de contexto. Se
comunican directamente con el sistema a
travs de flujos de datos o de control.
Comunicacin directa entre terminado y sistema
Terminadores
Comunicacin a travs de un almacn
externo
Terminadores
Punto en consideracin de los terminadores:
Algunos terminadores tienen un buen nmero de
entradas y salidas. Para evitar un diagrama
innecesariamente atiborrado conviene dibujar el
terminador ms de una vez.
Los terminadores duplicados se marcan con un
asterisco.
Terminadores
Cuando el terminador es una persona
individual, generalmente es preferible indicar
el rol que desempea, ms que su identidad.
Dado que estamos interesados en
desarrollar un modelo esencial del sistema,
es importante distinguir entre fuente y
manejadores.
Terminadores
Un manejador es un mecanismo, dispositivo,
medio fsico usado para transportar datos
hacia o fuera del sistema. Dado que a
menudo, dichos manejadores son familiares
y visibles para los usuarios de la
implantacin actual de un sistema, existe la
tendencia a mostrar al manejador, en lugar
de la verdadera fuente de los datos.
Terminadores
Los flujos que aparecen en el diagrama de contexto
modelan datos que entran y salen del sistema,
adems de las seales de control que recibe o
genera.
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.
Construccin de la lista de
acontecimiento
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.
Por ejemplo, lo siguiente probablemente no sea un
acontecimiento:
"El sistema recibe el pedido del cliente"
Construccin de la lista de
acontecimiento
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 ms apropiado para el
acontecimiento sera:
"El cliente hace un pedido"
Construccin de la lista de
acontecimiento
La manera ms fcil de identificar los
acontecimientos para un sistema es
visualizarlo en accin: examinar cada
terminador y preguntar qu efecto pueden
tener sus acciones sobre el sistema.
Construccin de la lista de
acontecimiento
La lista de acontecimiento debe incluir no
slo las interacciones normales ente el
sistema y sus terminadores sino tambin
situaciones de fallos.
Construccin de la lista de
acontecimiento
Por ejemplo, nuestra lista de acontecimiento para el
Sistema de Pedido de Libros Ajax inclua un
acontecimiento llamado "el pedido de reimpresin de
libro llega al almacen".
Pero Qu tal si no llega a tiempo (por ejemplo, una
semana despus de la fecha prometida por el
impresor)? Qu debera hacer el sistema?, Por lo
que se necesitara un acontecimiento adicional
iniciado por el sistema para hacer que se comunique
con el impresor y localice el origen del retraso.
Ejemplos
La declaracin de propsitos.
El propsito del Sistema de Informacin de
YOURDON Press (YPIS) es almacenar la
informacin necesaria para vender libros a
los clientes. Esto incluye ingreso de pedidos,
facturacin, generacin de documentos de
envo, control de inventarios y produccin de
reportes de regalas por derechos de autor y
reportes de contabilidad.
Ejemplos
La lista de acontecimientos.
La lista de acontecimientos del sistema YPIS
consiste en 40 acontecimientos.
La mayora estn dirigidos por flujos, aunque
la mayora de los que involucran al
departamento de contabilidad son
temporales.
Ejemplos
La lista de acontecimientos.
Listado de acontecimientos:
"T - Temporales
El cliente pide un libro.
El cliente enva su pago.
El cliente pide informacin sobre algn libro (precio, etc.).
El cliente pide permiso de devolver un libro
El cliente pregunta sobre el status de algn pedido.
El cliente pregunta sobre el status de alguna factura.
El cliente requiere de una declaracin (mensual). (T)
Ejemplos
La lista de acontecimientos.
El cliente pide un recordatorio de un crdito.
El cliente desea un cheque de reembolso.
El departamento de contabilidad requiere de recibos
(diarios) de efectivo. (T)
El departamento de contabilidad requiere de
reportes de ventas (diarios). (T)
El departamento de contabilidad requiere de un
reporte (mensual) de ventas netas.(T)
El departamento de contabilidad requiere de un
reporte (trimestral) por derechos de autor. (T)
Ejemplos
La lista de acontecimientos.
El departamento de contabilidad requiere de datos
(mensual) de inventario. (T)
El departamento de contabilidad requiere de un
reporte (mensual) de comisiones sobre ventas. (T)
La gerencia fija un nuevo lmite de crdito para un
cliente.
El departamento de contabilidad requiere un reporte
(mensual) de cuentas por pagar retrasadas.
La imprenta da una cotizacin de pedido de
impresin
Ejemplos
La lista de acontecimientos.
La administracin autoriza un pedido de impresin.
La imprenta notifica la cantidad exacta de impresos
y fechas de entrega.
La imprenta enva factura por concepto de trabajo
de impresin.
La administracin solicita cotizacin de un pedido de
impresin.
El departamento de almacen pide etiquetas de envo
de la base de datos de clientes.
Ejemplos
La lista de acontecimientos.
El departamento de almacn requiere de estadsticas sobre las
ventas de libros.
El departamento de almacn necesita una fecha de
disponibilidad de nuevos ttulos.
Los editores anuncian un nuevo ttulo.
Los autores necesitan un reporte trimestral de utilidades por
concepto de derechos de autor. (T)
El almacn necesita datos de envo y etiquetas. (T)
El almacn recibe libros de la imprenta.
El almacn recibe devoluciones de libros de un cliente.
Ejemplos
La lista de acontecimientos.
El almacn hace un inventario fsico (mensual).
El almacn enva un pedido a un cliente.
El almacn anuncia que un libro se ha agotado.
El departamento de adquisiciones anuncia el proyecto de un
nuevo libro.
Un vendedor ingresa un pedido de parte de un cliente.
El departamento de mercadeo declara que un libro est
agotado.
El cliente notifica un cambio de domicilio.
El autor notifica un cambio de domicilio.
El cliente elige participar en el plan de agencia.
Se necesita enviar facturas a un cliente. (T)
Ejemplos
La lista de acontecimientos.
El cliente enva su pago.
Ejemplos
La lista de acontecimientos.
El pago puede cubrir diversas facturas distintas, pero no
siempre queda claro de cules facturas se trata. A veces los
clientes no identifican la factura que estn pagando; a veces
identifican facturas que ya se pagaron; en ocasiones dan
como referencia nmeros de facturas inexistentes.
A veces no queda claro incluso de dnde viene el pago. Esto
sucede sobre todo en el caso de cadenas de libreras.
No existe garanta 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 envo.
Ejemplos
La lista de acontecimientos.
El cliente pide informacin sobre algn libro
(precio, etc.).
Notas:
El cliente generalmente
pregunta cosas tales como el
precio del libro, o cundo se
espera tener en existencia
cierto libro, o el programa de
descuento por volumen.
Ejemplos
La lista de acontecimientos.
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.
Dentro del modelo de comportamiento se
involucrar el desarrollo de un diagrama de flujo de
datos y un diagrama de entidad-relacin
preliminares, adems de la elaboracin de las
entradas iniciales del diccionario.
Para explicar el modelo de comportamiento
utilizaremos el enfoque de particin por
acontecimiento, el cual incluye los siguientes cuatro
pasos:
Modelo de Comportamiento
Se dibuja una burbuja, o proceso, para cada
acontecimiento de la lista.
La burbuja se nombra describiendo la respuesta que
el sistema debe dar al acontecimiento asociado.
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 comunicacin entre burbujas.
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
El primer paso es directo y mecnico: si existen
25 acontecimientos en la lista, se deben dibujar
25 burbujas.
El segundo paso tambin es directo y mecnico:
a cada burbuja se le da un nombre apropiado,
basado en la respuesta requerida.
Esto significa que se debe examinar el
acontecimiento y preguntar qu respuesta debe
dar el sistema a este Acontecimiento?.
Modelo de Comportamiento
El tercer paso definitivamente no es
mecnico, pero usualmente es bastante
directo. Para cada burbuja dibujada,
identifique las entradas que requiere para
efectuar su trabajo.
Identifique las salidas que cada una
produce e identifique los almacenes a los
que cada burbuja debe tener acceso.
Modelo de Comportamiento
Esto normalmente se hace entrevistando
al usuario o usuarios apropiados y
concentrndose en cada acontecimiento
y su burbuja asociada.
Las preguntas son: Qu necesita esta
burbuja para hacer su trabajo? y Qu
salidas genera?.
Modelo de Comportamiento
En muchos casos el acontecimiento est
determinado por el flujo.
El sistema detecta la ocurrencia de un
acontecimiento por la llegada de algn 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.
De manera similar, como parte de la
respuesta dibuje las salidas adecuadas
producidas por el proceso.
En muchos casos, esto implicara devolver
salidas a los terminadores fuera del sistema;
sin embargo, puede tambin involucrar
salidas que se envan a los almacenes de
datos, para ser usadas como entradas de
otros procesos.
Modelo de Comportamiento
Entradas y salidas de un proceso
Modelo de Comportamiento
El cuarto paso es una actividad de verificacin
de consistencia.
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 tambin que cada salida producida por
algn proceso en el DFD preliminar se enve a un
almacn o sea una salida externa incluida en el
diagrama de contexto.
Modelo de Comportamiento
Existen dos casos especiales:
(1) acontecimientos nicos que causan respuestas
mltiples y,
(2) acontecimientos mltiples que causan la misma
respuesta.
En el primer caso, un solo acontecimiento puede
causar mltiples respuestas, cada una de las cuales
se modela con su propia burbuja en el DFD
preliminar.
Slo es apropiado si todas las respuestas usan el
mismo flujo de datos de entrada, y slo si todas las
respuestas son independientes entre s.
Modelo de Comportamiento
De manera inversa, habr situaciones
ocasionales en las que un proceso se asocia
con ms de un acontecimiento.
Es vlido y apropiado slo si la respuesta de
la burbuja es idntica para los diversos
acontecimientos, y slo si los datos de
entrada y salida son idnticos para las
diversas respuestas a acontecimientos.
Modelo de Comportamiento
Modelo de Comportamiento
Obsrvese 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 atravs de otros
almacenes de datos.
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 particin por acontecimientos.
Diseo de Sistemas
Como analista, puede no sentir inters por los detalles del
diseo de sistemas o de programas; sin embargo, la labor de
analista y la del diseador no siempre se pueden separar
debido a que, el analista debe asegurarse de entender los
requerimientos del usuario, mientras que el diseador debe
asegurar que dichos requerimientos se puedan implantar de
manera realista con la tecnologa computacional actual.
Existe otra razn para tener inters en el diseo de sistemas:
tal vez le toque hacerlo.
Sobre todo en los sistemas pequeos y medianos, a menudo
se espera que el mismo individuo documente los
requerimientos del usuario y adems desarrolle el diseo.
Diseo de Sistemas
La actividad de diseo involucra el desarrollo de una serie de
modelos.
Los modelos ms importantes para el diseador son el modelo
de implementacin de sistemas y el modelo de implementacin
de programas.
El modelo de implantacin de sistemas se divide luego en un
modelo de procesador, y uno de tareas.
En el nivel del modelo del procesador, el diseador del sistema
trata principalmente de decidir como asignar el modelo
esencial a los distintos procesadores(CPU) y como deben
comunicarse entre s. Existe tpicamente una variedad de
opciones:
Diseo de Sistemas
El modelo esencial completo se le puede
asignar a un solo procesador
Cada burbuja de la figura del DFD del
modelo esencial se puede asignar a un
procesador distinto (solucin distribuida).
Se pude escoger una combinacin de
Ordenadores principales, para minimizar
costos, maximizar confiabilidad o lograr
algn otro objetivo.
Programacin.
La programacin comienza cuando termina
la actividad de diseo. En esta fase
se involucra la escritura de instrucciones en
C++, Pascal, o algn otro lenguaje de
programacin para implantar lo que el
analista ha especificado y el diseador ha
organizado en mdulos.
Como programadores se pueden enfrentar a
los siguientes problemas:
Programacin.
Productividad: esto es escribir ms
software, ms rpidamente. La principal
razn de esto es la enorme cantidad de
sistemas y aplicaciones que siguen en
espera en las grandes organizaciones.
Programacin.
Eficiencia: la eficiencia es de gran importancia en muchos
sistemas de tiempo real, y en sistemas que procesan grandes
volmenes de datos (ejemplo, sistemas en bancos, reservacin
en aerolneas, compaas de bolsas y compaas de seguro).
La meta de eficiencia usualmente entra en conflicto con otras
metas discutidas: si se emplea mucho tiempo en la
construccin de un sistema eficiente, es probable que sea
menos mantenible y menos transportable, y que tenga ms
errores residuales sutiles, adems de que tal vez reduzca la
productividad de la persona que escribi el programa.
Programacin.
Correccin: se podra argumentar que esto es lo
ms importante. Despus de todo, si el programa no
funciona correctamente, no importa que tan eficiente
sea. Por ejemplo, se prefieren lenguajes de
programacin como Ada y Pascal si la correccin es
de importancia crtica, 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 rgidos".
Programacin.
Portabilidad: en algunos ambientes esto es importante;
El usuario puede desear ejecutar el mismo sistema en distintos
medios.
Por ello, adems del lenguaje de programacin debemos
preocuparnos por el estilo de programacin, s la portabilidad
es un factor importante.
Mantenibilidad: como los sistemas viven durante mucho
tiempo, por lo tanto el software debe mantenerse.
Prueba.
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
implantacin del usuario.
Este proceso puede llevarse a cabo en paralelo con
las actividades de implantacin del diseo y de la
programacin, 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.
Existen distintas estrategias de prueba, las dos ms
comunes se conocen como prueba ascendente y
descendente.
El enfoque ascendente empieza por probar mdulos
individuales separadamente (prueba de mdulos).
Luego, los mdulos individuales se combinan para
forma unidades que se probaran en masas (pruebas
de subsistemas).
Finalmente, todos los componentes del sistema se
combinan para probarse (prueba del sistema).
Prueba.
El enfoque de prueba descendente empieza
con un esqueleto del sistema; es decir, la
estrategia de prueba supone que se han
desarrollado los mdulos ejecutivos de alto
nivel del sistema, pero que los de bajo nivel
existen slo como mdulos vacos;
Ejemplo de mdulo vaco es uno que no
procesa nada, sino que simplemente termina
luego de ser llamado.
Prueba.
Tipos de pruebas:
Prueba funcional: Su propsito 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.
Prueba de recuperacin: El propsito 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.
Prueba de desempeo: El propsito de este tipo de prueba
es asegurar que el sistema pueda manejar el volmen de datos
y transacciones de entrada especificados en el mdulo de
implantacin del usuario, adems de asegurar que tenga el
tiempo de respuesta requerido.
Prueba.
Para poder realizar una excelente prueba se
necesita de tres cosas:
un plan de prueba,
descripciones de pruebas y
procedimiento de prueba.
Un plan de prueba es un documento
organizado que describe las actividades de
prueba.
Prueba.
Un documento de planeacin de pruebas:
Propsito de la prueba: cul es el objetivo de la prueba, y qu
parte del sistema se est probando.
Localizacin y horario de la prueba: dnde y cuando se har.
Descripcin de la prueba: descripcin de las entradas que se
proporcionarn al sistema, y las salidas y resultados que se
anticipan.
Procedimiento de prueba: descripcin de cmo se deben
preparar y presentar los datos de prueba al sistema; cmo
capturar los resultados de salida, cmo analizar los resultados
de las pruebas, y cualesquiera otros procedimientos
operacionales que se deben observar.
Preguntas?