1

19-05-2014
INSTITUTO TECNOLGICO DE ACAPULCO.









Materia: Desarrollo de Proyectos de
Software.


Unidad #4: PRUEBAS DE SOFTWARE.

EQUIPO #4
INTEGRANTES:
Garca Betancur Javier 09320836.
Padilla Nava Jos Luis 09320885.
Lozano Mendoza Jairo Manuel 09320768
Morales Toledo Jos Miguel 09320819



Profesora: Ing. Garca Castro Mara Nancy.












NDICE GENERAL

Antologa: Unidad #4.
2


INTRODUCCIN. ............................................................................................................................................. 3
UNIDAD #4. PRUEBAS DE SOFTWARE. ...................................................................................................... 4
4.1 Definiciones. ............................................................................................................................................. 4
4.1.1 Prueba, caso de prueba, defecto, falla, error, verificacin, validacin. .............................................. 4
4.1.2 Relacin defecto falla error. (Somerville 425). .................................................................................. 6
4.1.3 Pruebas estructurales, funcionales y aleatorias ................................................................................... 7
4.1.4 Documentacin del diseo de las pruebas. ......................................................................................... 9
4.2 Proceso de pruebas. .................................................................................................................................. 9
4.2.1 Generar un plan de pruebas. ............................................................................................................... 9
4.2.2 Disear pruebas especficas. ............................................................................................................. 10
4.2.3 Tomar configuracin del software a probar. .................................................................................... 10
4.2.4 Configurar las pruebas. ..................................................................................................................... 11
4.2.5 Evaluar resultados. ........................................................................................................................... 11
4.3 Tcnicas de diseo de casos de prueba. ................................................................................................. 14
4.4 Enfoque prctico recomendado para el diseo de casos. ........................................................................ 15
4.5 Estrategias de aplicacin de las pruebas. ............................................................................................... 16
4.5.1 Pruebas unitarias. ............................................................................................................................. 16
4.5.2 Prueba de integracin. ...................................................................................................................... 17
4.5.3 Del sistema. ...................................................................................................................................... 18
4.5.4 Pruebas de aceptacin. ..................................................................................................................... 19
SEGUNDO PUNTO DE VISTA. ..................................................................................................................... 20
UNIDAD #4. PRUEBS DE SOFTWARE. ....................................................................................................... 20
4.1 DEFINICIONES. .................................................................................................................................... 20
4.2 PROCESO DE PRUEBAS. ..................................................................................................................... 20
4.2.1 GENERAR UN PLAN DE PRUEBAS. ........................................................................................... 20
4.2.2 DISEAR PRUEBAS ESPECFICAS. ........................................................................................... 21
4.2.3 TOMAR CONFIGURACION DEL SOFTWARE A PROBAR. ..................................................... 21
4.2.4 CONFIGURAR LAS PRUEBAS..................................................................................................... 22
4.2.5 EVALUAR RESULTADOS. ........................................................................................................... 22
4.3 TECNICAS DE DISEO DE CASOS DE PRUEBAS. ......................................................................... 26
4.5 ESTRATEGIAS DE APLICACIN DE LAS PRUEBAS. .................................................................... 28
4.5.1 PRUEBAS DE UNIDAD. ................................................................................................................ 28
4.5.2 PRUEBAS DE INTEGRACIN. .................................................................................................... 29
4.5.3 PRUEBAS DE SISTEMA. ............................................................................................................... 30
4.5.4 PRUEBAS DE ACEPTACION. ...................................................................................................... 30
CONCLUSIONES. ........................................................................................................................................... 31
BIBLIOGRAFIA. .............................................................................................................................................. 32




3


INTRODUCCIN.

Una de las caractersticas ms destacadas de las sociedades modernas es el uso
de la tecnologa en la cual en muchos de los caso se involucra el desarrollo de
sistemas de software que apoyan las actividades diarias en empresa, en nuestra
casa, en procesos de comunicacin donde interviene el manejo de informacin o
en los sistemas de produccin donde se ha sustituido la mano del hombre por
maquinas que controlan la produccin atreves de dispositivos programados y
grabados en una placa de silicio.
El software es algo indispensable en nuestra vida diaria que de manera general se
entiende como programas de computadora; el desarrollo de software es una
actividad donde se involucra la ingeniera; que es el estudio y aplicacin, por
especialistas, de las diversas ramas de la tecnologa. 1El desarrollo de sistemas
de software no es el simple hecho de programar computadoras, instrucciones en
una placa de circuitos integrados para que realice una determinada funcin o el
realizar grandes programas que se ejecuta en una poderosa computadora que
puede realizar miles de operaciones por segundo o que de igual manera se puede
ejecutar en una PDA o en algn otro dispositivo electrnico; por lo que este
proceso involucra a la Ingeniera de Software que comprende todos los aspectos
de la produccin de software desde las etapas iniciales de la especificacin del
sistema (Somerville, 2005, p.6).
Desarrollar un software significa construirlo simplemente mediante su descripcin.
Est es una muy buena razn para considerar la actividad de desarrollo de
software como una ingeniera. Por lo que un producto de software no se limita solo
a programas de computadora sino a la documentacin asociada a este en las
distintas etapas que interviene desde su concepcin, anlisis, diseo,
implementacin, pruebas y mantenimiento. El software no estara completo si no
existiera una especificacin de requerimiento o un diseo de la arquitectura, crear
software es muy similar a la creacin y diseo de muchas otras reas como la
arquitectura donde podemos empezar diseando una casa o departamento hasta
un gran rascacielos o el puente ms largo que comunica dos ciudades.
4





UNIDAD #4. PRUEBAS DE SOFTWARE.

4.1 Definiciones.
4.1.1 Prueba, caso de prueba, defecto, falla, error, verificacin, validacin.

Prueba.
La prueba es el proceso de ejecucin de un programa con la intencin de
descubrir un error. (Pressman 2000)
Las pruebas son un conjunto de actividades que se pueden planificar por
adelantado y llevar a cabo sistemticamente. Por esta razn, se debe definir en el
proceso de la ingeniera del software una plantilla para las pruebas del software:
un conjunto de pasos en los que podamos situar los mtodos especficos de
diseo de casos de prueba (Somerville 2007 pag. 500 ).
Un proceso general de pruebas comienza con la prueba de unidades de
programas individuales tales como funciones u objetos. A continuacin, stas se
integraban en subsistemas y sistemas, y se prueban las interacciones entre estas
unidades. Finalmente, despus de entregar el sistema, el cliente puede llevar a
cabo una serie de pruebas de aceptacin para comprobar que el sistema funciona
tal y como se ha especificado.
Este modelo de proceso de pruebas es apropiado para el desarrollo de sistemas
grandes; pero para sistemas ms pequeos, o para sistemas que se desarrollan
mediante el uso de scripts o reutilizacin, a menudo se distinguen menos etapas
en el proceso. Una visin ms abstracta de las pruebas del software. Las dos
actividades fundamentales de pruebas son la prueba de componentes -probar las
partes del sistema- y la prueba del sistema -probar el sistema como un todo.

Caractersticas generales:
Las pruebas comienzan a nivel de mdulo y trabajan hacia fuera, hacia la
integracin de todo el sistema basado en computadora.
Segn el momento, son apropiadas diferentes tcnicas de prueba.
La prueba la lleva a cabo el responsable del desarrollo del software y (para
grandes proyectos) un grupo independiente de pruebas.
La prueba y la depuracin son actividades diferentes, pero la depuracin se debe
incluir en cualquier estrategia de prueba.

Casos de prueba.
Conjunto de condiciones o variables bajo las cules el analista determinar si el
requisito de una aplicacin es parcial o completamente satisfactorio.
El objetivo del proceso de diseo de casos de prueba es crear un conjunto de
casos de prueba que sean efectivos descubriendo defectos en los programas y
muestren que el sistema satisface sus requerimientos.(Somerville: pag:504)
Para disear un caso de prueba, se selecciona una caracterstica del sistema o
componente que se est probando. A continuacin, se selecciona un conjunto de
5

entradas que ejecutan dicha caracterstica, documenta las salidas esperadas o
rangos de salida y, donde sea posible, se disea una prueba automat1zada que
prueba que las salidas reales y esperadas son las mismas.

Defecto.
Un defecto de software (computer bug en ingls), es el resultado de un fallo o
deficiencia durante el proceso de creacin de programas de ordenador o
computadora (software). Dicho fallo puede presentarse en cualquiera de las
etapas del ciclo de vida del software aunque los ms evidentes se dan en la etapa
de desarrollo y programacin. Los errores pueden suceder en cualquier etapa de
la creacin de software.

Falla.
Una falla ocurre cuando un programa no se comporta de manera adecuada. La
falla es una propiedad esttica de un sistema en ejecucin.( Alfredo Weitzenfeld
pag. 599).

Error.
Es una accin humana que provoca que un software contenga una falta. Un error
puede significar la existencia de una falta en el programa lo cual hace que el
sistema falle.

Verificacin.
La verificacin se refiere al conjunto de actividades que aseguran que el software
implementa correctamente una funcin especfica. La validacin se refiere a un
conjunto diferente de actividades que aseguran que el software construido se
ajusta a los requisitos del cliente. Bohem [BOE81] lo define de otra forma:

Verificacin: Estamos construyendo el producto correctamente
Validacin: Estamos construyendo el producto correcto?

Validacin.
La validacin del software o, de forma ms general, la verificacin y validacin (V
& V) se utiliza para mostrar que el sistema se ajusta a su especificacin y que
cumple las expectativas del usuario que lo comprar. Implica procesos de
comprobacin, como las inspecciones y revisiones, en cada etapa del proceso del
software desde la definicin de requerimientos hasta el desarrollo del programa,
Sin embargo, la mayora de los costos de validacin aparecen despus de la
implementacin, cuando se prueba el funcionamiento del sistema,
A excepcin de los programas pequeos, los sistemas no se deben probar como
una simple unidad monoltica. La Figura 4.2 muestra un proceso de pruebas de
tres etapas en el cual se prueban los componentes del sistema, la integracin del
sistema y, finalmente, el sistema con los datos del cliente. En el mejor de los
casos, los defectos se descubren en las etapas iniciales del proceso y los
problemas con la interfaz, cuando el sistema se integra. Sin embargo, cuando se
descubren defectos el programa debe depurarse y esto puede requerir la
repeticin de otras etapas del proceso de pruebas. Los errores en los
componentes del programa pueden descubrirse durante las pruebas del sistema.
6

Por lo tanto, el proceso es iterativo y se retroalimenta tanto de las ltimas etapas
como de la primera parte del proceso.
4.1.2 Relacin defecto falla error. (Somerville 425).

El software libre de defectos es el software que cumple exactamente con su
especificacin. Sin embargo, esto no significa que el software nunca falle. Puede
haber errores en la especificacin que se reflejan en el software. o los usuarios
pueden no comprender o no usar bien el sistema software. Sin embargo, eliminar
los defectos del software ciertamente tiene un enorme impacto sobre el nmero de
fallos de ejecucin del sistema.
Para sistemas de tamao pequeo y medio, nuestras tcnicas de ingeniera del
software son tales que probablemente sea posible desarrollar software libre de
defectos. Para alcanzar este objetivo, es necesario utilizar varias tcnicas de
ingeniera del software:

1. Procesos software confiables. El uso de un proceso software confiable, con
actividades de verificacin y validacin adecuadas resulta esencial si tiene que
minimizarse el nmero de defectos en el programa, y tienen que detectarse
aquellos que se produzcan.

2. Gestin de calidad. La organizacin que desarrolla el sistema debe tener una
cultura en la que la calidad gue el proceso software. Esta cultura debera motivar
a los programadores a escribir programas libres de errores. Deberan establecerse
estndares de diseo y desarrollo, as como procedimientos para comprobar que
dichos estndares se cumplen.

3. Especificacin formal. Debe realizarse una especificacin del sistema precisa
(preferiblemente formal) que defina el sistema que se va a implementar. Muchos
errores de diseo y programacin son el resultado de una mala interpretacin de
una especificacin ambigua o pobremente redactada.

4. Verificacin esttica. Las tcnicas de verificacin estticas, como el uso de
analizadores estticos, pueden encontrar caractersticas anmalas en el programa
que podran ser defectos. Tambin podra usarse verificacin formal, basada en la
especificacin del sistema.

5. Tipado fuerte. Para el desarrollo se debe usar un lenguaje de programacin
fuertemente tipado, como Java o Ada. Si el lenguaje es fuertemente tipado, el
compilador del lenguaje puede detectar muchos errores de programacin antes de
que puedan ser introducidos en el programa entregado.

6. Programacin segura. Algunas construcciones de lenguajes de programacin
son ms complejas y propensas a error que otras, y es ms probable que se
cometan errores si se usan. La programacin segura significa evitar, o al menos
minimizar, el uso de estas construcciones.

7. Informacin protegida. Debera utilizarse una aproximacin para el diseo e
implementacin del software basada en la ocultacin y encapsulamiento de la
7

informacin. Los lenguajes orientados a objetos como Java, obviamente satisfacen
esta condicin. Se debera fomentar el desarrollo de programas diseados para
ser legibles y comprensibles.

Existen situaciones en las que es econmicamente prctico utilizar todas estas
tcnicas para crear software libre de defectos. El coste de encontrar y eliminar
defectos en el sistema crece exponencialmente a medida que se descubren y
eliminan los defectos en el programa como se muestra en la Figura 4.3. A medida
que el software se hace ms fiable, se necesita emplear ms y ms tiempo y
esfuerzo para encontrar menos y menos defectos. En algn momento, los costes
de este esfuerzo adicional se convierten en injustificables.

















Figura 4.3 relacin costo error.

4.1.3 Pruebas estructurales, funcionales y aleatorias.

Las pruebas estructurales (Figura 4.4) son una aproximacin al diseo de casos
de prueba en donde las pruebas se derivan a partir del conocimiento de la
estructura e implementacin del software. Esta aproximacin se denomina a veces
pruebas de caja blanca, de caja de cristal o de caja transparente para
distinguirlas de las pruebas de caja negra.
La comprensin del algoritmo utilizado en un componente puede ayudar a
identificar particiones adicionales y casos de prueba.(Somerville 2005 pag: 509).

8



Figura 4.4 pruebas estructurales.

Las pruebas funcionales son el proceso de probar una entrega del sistema que
ser distribuida a los clientes. El principal objetivo de este proceso es incrementar
la confianza del suministrador en que el sistema satisface sus requerimientos. Si
es as, ste puede entregarse como un producto o ser entregado al cliente. Para
demostrar que el sistema satisface sus requerimientos, tiene que mostrarse que
ste entrega la funcionalidad especificada, rendimiento y confiabilidad, y que no
falla durante su uso normal. Las pruebas de entregas son normalmente un
proceso de pruebas de caja negra en las que las pruebas se derivan a partir de la
especificacin del sistema. El sistema se trata como una caja negra cuyo
comportamiento slo puede ser determinado estudiando sus entradas y sus
salidas relacionadas. En este sentido al probador slo le interesa la funcionalidad
y no la implementacin del software. La Figura. 4 ilustra el modelo de un sistema
que se admite en las pruebas de caja negra.
El probador presenta las entradas al componente o al sistema y examina las
correspondientes salidas. Si las salidas no son las, entonces la prueba ha
detectado un problema con el software.
Cuando se prueban las entregas del sistema, debera intentarse romper el
software eligiendo casos de prueba que pertenecen al conjunto E, en la Figura
23.4. Es decir, el objetivo debera ser seleccionar entradas que tienen una alta
probabilidad de generar fallos de ejecucin del sistema (salidas del conjunto S,).
Se utiliza la experiencia previa de cules son las pruebas de defectos que
probablemente tendrn xito y las guas de pruebas ayudarn a elegir la
adecuada.

La prueba aleatoria genera arbitrariamente los casos de prueba a partir del
dominio de entrada de las variables del sistema bajo prueba.
Puede aplicarse a cualquier criterio de suficiencia aunque este no influye en el
proceso de generacin de casos. Por ello, la generacin de casos de prueba es
inmediata pero ineficaz. Adems est comprobado que el cumplimiento del criterio
de suficiencia de los datos generados aleatoriamente es muy dependiente del
rango para el cual son generados.
9


Aunque la prueba aleatoria es aparente mente ineficaz. La generacin de casos
de prueba aleatorios es eficiente, puesto que solo se necesita un generador de
nmeros aleatorios junto con un poco de soporte de software, y permite una
automatizacin inmediata.
La prueba aleatoria como prueba por si sola se ha utilizado en raras ocasiones
con objeto de probar software difcil, muy elaborado o muy especfico.
La aplicacin principal de la prueba aleatoria se aplica en comparaciones con
otros mtodos de prueba.

4.1.4 Documentacin del diseo de las pruebas.

Los esfuerzos realizados en la planificacin y preparacin de pruebas se resumen
en un documento denominado plan de pruebas. En su preparacin debe resaltarse
la necesidad de que los casos de prueba estn identificados clara y unvocamente,
con el fin de facilitar las referencias futuras al ser ejecutados. Tambin es
importante detallar concretamente tanto los datos de entrada como las salidas
esperadas, que el encargado de su ejecucin cotejara posteriormente con la
informacin obtenida directamente del sistema. Tales recomendaciones pueden
encontrase en el estndar IEEE 829; 1998. No obstante cada organizacin debe
definis los documentos que quiere producir en sus pruebas con el objeto que la
productividad de estos procesos sea tan alta como sea posible. Notese que el plan
de pruebas no es un fin en s mismo, sino un medio para desarrollar
ordenadamente los procesos de prueba.

4.2 Proceso de pruebas.
4.2.1 Generar un plan de pruebas.
Objetivo del documento
Sealar el enfoque, los recursos y el esquema de actividades de prueba, as como los
elementos a probar, las caractersticas, las actividades de prueba, el personal
responsable y los riesgos asociados

ESTRUCTURA FIJADA EN EL ESTANDAR
1. Identificador nico del documento
2. Introduccin y resumen de elementos y caractersticas a probar
3. Elementos software a probar
4. Caractersticas a probar
5. Caractersticas que no se probarn
6. Enfoque general de la prueba
10

7. Criterios de paso/fallo para cada elemento
8. Criterios de suspensin y requisitos de reanudacin
9. Documentos a entregar
10. Actividades de preparacin y ejecucin de pruebas
11. Necesidades de entorno
12. Responsabilidades en la organizacin y realizacin de las pruebas
13. Necesidades de personal y formacin
14. Esquema de tiempos
15. Riesgos asumidos por el plan y planes de contingencias
16. Aprobaciones y firmas con nombre y puesto desempeado

4.2.2 Disear pruebas especficas.
Objetivo del documento
Especificar los refinamientos necesarios sobre el enfoque general reflejado en el plan e
identificar las caractersticas que se deben probar con este diseo de pruebas

ESTRUCTURA FIJADA EN EL ESTANDAR
1. Identificador nico para la especificacin. Proporcionar tambin una referencia del
plan asociado (si existe)
2. Caractersticas a probar de los elementos software (y combinaciones de
caractersticas)
3. Detalles sobre el plan de pruebas del que surge este diseo, incluyendo las
tcnicas de prueba especfica y los mtodos de anlisis de resultados
4. Identificacin de cada prueba:
a. identificador
b. casos que se van a utilizar
c. procedimientos que se van a seguir
5. Criterios de paso/fallo de la prueba (criterios para determinar si una caracterstica
o combinacin de caractersticas ha pasado con xito la prueba o no)
4.2.3 Tomar configuracin del software a probar.
Establecer la configuracin de la instalacin a llevar acabo, determinando que
componentes deben instalarse en cada equipo de hardware, y como debe realizarse dicha
instalacin. En muchas ocasiones es recomendable realizarse un manual de instalacin y
11

configuracin, donde se recojan las operaciones de instalacin del software y su posterior
configuracin con los parmetros adecuados de o las maquinasy software base donde se
proceder a instalar.

4.2.4 Configurar las pruebas.
Un elemento importante del proceso de validacin es la revisin de la configuracin. La
intencin de la revisin es asegurarse de que todos los elementos de la configuracin del
software se han desarrollado apropiadamente, se han catalogado y estn suficientemente
detallados para soportar la fase de mantenimiento durante el ciclo de vida del software. La
revisin de la configuracin, a veces denominada auditora,

4.2.5 Evaluar resultados.
4.2.5.1 Depuracin.
La depuracin ocurre como consecuencia de una prueba efectiva. Es decir, cuando un
caso de prueba descubre un error, la depuracin es el proceso que provoca la eliminacin
del error. Aunque la depuracin puede y debe ser un proceso ordenado, sigue teniendo
mucho de arte. Un ingeniero del software, al evaluar los resultados de una prueba, se
encuentra frecuentemente con una indicacin sintomtica de un problema en el
software.
Como se muestra en la Figura 4.7, el proceso de depuracin comienza con la ejecucin
de un caso de prueba. Se evalan los resultados y aparece una falta de correspondencia
entre los esperados y los encontrados realmente. En muchos casos, los datos que no
concuerdan son un sntoma de una causa subyacente que todava permanece oculta. El
proceso de depuracin intenta hacer corresponder el sistema con una causa, llevando as
a la correccin del
error.



12



4.2.5.2 Anlisis de errores.
El cdigo de software escrito deficientemente ocasiona mucho trabajo adicional para el
personal de desarrollo de sistemas, lo mantiene ocupado en tareas de mantenimiento y
agrava la escasez de recursos para el desarrollo de sistemas
Los errores de software pueden causar prdida de ingresos y oportunidades de mercado
as como procesamiento incorrecto de la informacin -y todo ello reduce las utilidades de
la una empresa-,
Los tipos de fallos que pueden ocurrir son especficos del sistema y las consecuencias de
un fallo del sistema dependen de la naturaleza de ese fallo. Cuando se redacte una
especificacin de fiabilidad, habra que identificar los diferentes tipos de fallos, y pensar
sobre si stos deberan ser tratados de forma diferente en la especificacin. En la Figura
9.11 se muestran ejemplos de diferentes tipos de fallos. Obviamente pueden ocurrir
combinaciones de stos, como por ejemplo un fallo que sea transitorio, recuperable y
corruptivo.

La mayora de los sistemas grandes estn compuestos por varios subsistemas con
diferentes requerimientos de fiabilidad. Puesto que el software que tiene una fiabilidad alta
es caro, debera realizarse una valoracin de los requerimientos de fiabilidad para cada
subsistema por separado en lugar de imponer el mismo requerimiento de fiabilidad para
todos los subsistemas. Esto evita imponer altos requerimientos de fiabilidad en aquellos
subsistemas en los que no es necesario.


Figura 4.7 proceso de depuracin de errores de software
13

Los pasos que se requieren para establecer una especificacin de la fiabilidad son:
1. Para cada subsistema. identificar los tipos de fallos de funcionamiento del sistema
que pueden ocurrir y analizar las consecuencias de dichos fallos.
2. A partir del anlisis de fallos del sistema. dividir los fallos en clases. Un punto de
partida razonable es utilizar los tipos de fallos mostrados en la Figura 4.8.

3. Para cada clase de fallo identificada, definir el requerimiento de fiabilidad utilizando
una mtrica de fiabilidad adecuada. No es necesario utilizar la misma mtrica para
diferentes clases de fallos. Si un fallo requiere alguna intervencin para poder
recuperar el sistema, la mtrica ms apropiada podra ser la probabilidad de fallos
en la peticin. Cuando es posible la recuperacin automtica y el efecto del fallo
es la causa de una molestia para el usuario, ROCOF podra ser la ms adecuada.
4. Donde sea apropiado, identificar los requerimientos de fiabilidad funcionales que
definen la funcionalidad del sistema para reducir la probabilidad de fallos crticos.
Clase de fallo Descripcin
Transitorio Ocurre solamente con ciertas entradas.
Permanente Ocurre con todas las entradas.
Recuperable El sistema puede recuperarse sin la intervencin del operador.
Irrecuperable Es necesaria la intervencin del operador para
recuperarse del fallo.
No corruptivo El fallo no corrompe el estado del sistema o los datos.
Corruptivo El fallo corrompe el estado del sistema o los datos.

Figura 4.8Clasificacin de fallos de funcionamiento.

14

4.3 Tcnicas de diseo de casos de prueba.

El diseo de pruebas para el software o para otros productos de ingeniera puede requerir
tanto esfuerzo como el propio diseo inicial del producto. Sin embargo, los ingenieros del
software, a menudo tratan las pruebas como algo sin importancia, desarrollando casos de
prueba que parezcan adecuados, pero que tienen poca garanta de ser completos.
Recordando el objetivo de las pruebas, debemos disear pruebas que tengan la mayor
probabilidad de encontrar el mayor nmero de errores con la mnima cantidad de esfuerzo
y tiempo posible.

Cualquier producto de ingeniera puede probarse de una de estas dos formas: (1)
conociendo la funcin especfica para la que fue diseado el producto, se pueden llevar a
cabo pruebas que demuestren que cada funcin es completamente operativa y, al mismo,
tiempo buscando errores en cada funcin; (2) conociendo el funcionamiento del producto,
se pueden desarrollar pruebas que aseguren que todas las piezas encajan, o sea, que
la operacin interna se ajusta a las especificaciones y que todos los componentes
internos se han comprobado de forma adecuada. El primer enfoque de prueba se
denomina prueba de caja negra y el segundo, prueba de caja blanca.

Cuando se considera el software de computadora, la prueba de caja negra se refiere a las
pruebas que se llevan a cabo sobre la interfaz del software. O sea, los casos de prueba
pretenden demostrar que las funciones del software son operativas, que la entrada se
acepta de forma adecuada y que se produce un resultado correcto, as como que la
integridad de la informacin externa (por ejemplo, archivos de datos) se mantiene. Una
prueba de caja negra examina algunos aspectos del modelo fundamental del sistema sin
tener mucho en cuenta la estructura lgica interna del software.

La prueba de caja blanca del software se basa en el minucioso examen de los detalles
procedimentales. Se comprueban los caminos lgicos del software proponiendo casos de
prueba que ejerciten conjuntos especficos de condiciones y/o bucles. Se puede examinar
el estado del programa en varios puntos para determinar si el estado real coincide con
el esperado o mencionado.

15
A primera vista parecera que una prueba de caja blanca muy profunda nos llevara a
tener programas cien por cien correctos. Todo lo que tenemos que hacer es definir
todos los caminos lgicos, desarrollar casos de prueba que los ejerciten y evaluar los
resultados, es decir, generar casos de prueba que ejerciten exhaustivamente la lgica del
programa.

Desgraciadamente, la prueba exhaustiva presenta ciertos problemas logsticos. Incluso
para pequeos programas, el nmero de caminos lgicos posibles puede ser enorme.

Se pueden elegir y ejercitar una serie de caminos lgicos importantes. Se pueden
comprobar las estructuras de datos ms importantes para verificar su validez. Se pueden
combinar los atributos de la prueba de caja blanca as como los de caja negra, para llegar
a un mtodo que valide la interfaz del software y asegure selectivamente que el
funcionamiento interno del software es correcto
4.4 Enfoque prctico recomendado para el diseo de casos.

Un enfoque prctico debe especificar los pasos para la ejecucin de un conjunto de casos
de prueba o, ms generalmente, los pasos utilizados para analizar un elemento software
con el propsito de evaluar un conjunto de caractersticas del mismo

Estructura fijada en el estndar
1. Identificador nico de la especificacin y referencia a la correspondiente
especificacin de diseo de prueba
2. Objetivo del procedimiento y lista de casos que se ejecutan con l
3. Requisitos especiales para la ejecucin (por ejemplo, entorno especial
o personal especial)
4. Pasos en el procedimiento. Adems de la manera de registrar los
resultados y los incidentes de la ejecucin, se debe especificar:
a) La secuencia necesaria de acciones para preparar la
ejecucin
b) Acciones necesarias para empezar la ejecucin
c) Acciones necesarias durante la ejecucin
d) Cmo se realizarn las medidas ( por ejemplo, el tiempo de
respuesta)
e) Acciones necesarias para suspender la prueba (cuando los
acontecimientos no previstos lo obliguen)
f) Puntos para reinicio de la ejecucin y acciones necesarias
para el reinicio en estos puntos
g) Acciones necesarias para detener ordenadamente la
ejecucin
h) Acciones necesarias para restaurar el entorno y dejarlo en la
situacin existente antes de las pruebas
i) Acciones necesarias para tratar los acontecimientos anmalos
89

16
4.5 Estrategias de aplicacin de las pruebas.

4.5.1 Pruebas unitarias.

La prueba de unidad centra el proceso de verificacin en la menor unidad del diseo del
software: el componente software o mdulo.

Las pruebas que se dan como parte de la prueba de unidad estn esquemticamente
ilustradas en la Figura 4.9. Se prueba la interfaz del mdulo para asegurar que la
informacin fluye de forma adecuada hacia y desde la unidad de programa que est
siendo probada. Se examinan las estructuras de datos locales para asegurar que los
datos que se mantienen temporalmente conservan su integridad durante todos los pasos
de ejecucin del algoritmo. Se prueban las condiciones lmite para asegurar que el
mdulo funciona correctamente en los lmites establecidos como restricciones de
procesamiento.

Se ejercitan todos los caminos independientes (caminos bsicos) de la estructura de
control con el fin de asegurar que todas las sentencias del mdulo se ejecutan por lo
menos una vez. Y, finalmente, se prueban todos los caminos de manejo de errores.

Antes de iniciar cualquier otra prueba es preciso probar el flujo de datos de la interfaz del
mdulo. Si los datos no entran correctamente, todas las dems pruebas no tienen sentido.
Adems de las estructuras de datos locales, durante la prueba de unidad se debe
comprobar (en la medida de lo posible) el impacto de los datos globales sobre el mdulo.
FIGURA 4.9 Prueba de unidad
17
17
Durante la prueba de unidad, la comprobacin selectiva de los caminos de ejecucin es
una tarea esencial. Se deben disear casos de prueba para detectar errores debidos a
clculos incorrectos, comparaciones incorrectas o flujos de control inapropiados. Las
pruebas del camino bsico y de bucles son tcnicas muy efectivas para descubrir una
gran cantidad de errores en los caminos.

4.5.2 Prueba de integracin.

La prueba de integracin se dirige a todos los aspectos asociados con el doble problema
de verificacin y de construccin del programa. Durante la integracin, las tcnicas que
ms prevalecen son las de diseo de casos de prueba de caja negra, aunque se pueden
llevar a cabo algunas pruebas de caja blanca con el fin de asegurar que se cubren los
principales caminos de control.

Las pruebas de integracin parten de los componentes individuales previamente
probados y tienen como objetivo descubrir errores que se, pueden producir en la
interaccin entre los mdulos. En teora; la combinacin de componente vlidos debera
dar como resultado software en el que no se delectan errores, pero en la prctica hay
mltiples ocasiones en las que las pruebas de unidad no detectan errores que si se
revelan al ejecutar pruebas sobre el software integrado.

Las interfaces entre los mdulos suelen ser fuente de errores de integracin, pero
tambin los tratamientos concurrentes, como el acceso a estructuras de datos comunes o
la definicin de transacciones sobre las bases de datos. En otros

En la integracin incremental. El programa se construye y se prueba en pequeos
segmentos en los que los errores son ms fciles de aislar y de corregir, es ms probable
que se puedan probar completamente las interfaces y se puede aplicar un enfoque de
prueba sistemtica.

La prueba de integracin descendente es un planteamiento incremental a la construccin
de la estructura de programas. Se integran los mdulos movindose hacia abajo por la
jerarqua de control, comenzando por el mdulo de control principal (programa principal).
Los mdulos subordinados (subordinados de cualquier modo) al mdulo de control
principal se van incorporando en la estructura, bien de forma primero-en-profundidad, o
bien de forma primero-en-anchura.

Como se muestra en la Figura 4.10, la integracin primero-en-profundidad integra todos
los mdulos de un camino de control principal de la estructura. La seleccin del camino
principal es, de alguna manera, arbitraria y depender de las caractersticas especficas
de la aplicacin.
18
18


FIGURA 4.10. Integracin descendente

La estrategia de integracin descendente verifica los puntos de decisin o de control
principales al principio del proceso de prueba. En una estructura de programa bien
fabricada, la toma de decisiones se da en los niveles superiores de la jerarqua y, por
tanto, se encuentran antes. Si existen problemas generales de control, es esencial
reconocerlos cuanto antes. Si se selecciona la integracin primero en profundidad, se
puede ir implementando y demostrando las funciones completas del software.

4.5.3 Del sistema.

Los objetivos de las pruebas de sistema son la deteccin de errores en el producto ya
integrado. En ellas se ejercitan condiciones que anteriormente habra sido difcil
comprobar, como las interfaces entre subsistemas, la comunicacin con el entorno o el
cumplimiento de los requisitos no funcionales. En la Tabla 3.3 se resumen los objetivos de
los tipos de pruebas de sistema ms importantes.

Cabe destacar que, aunque el producto haya sido realizado a medida para ser implantado
en una instalacin concreta, las pruebas de sistema se ejecutan tambin en entornos de
prueba controlados.


19


Tipo de pruebas Breve descripcin de tus objetivos
Funcionales
Orientadas a detectar si el software implemonla adecuadamente la funcionalidad
descrita en los requisitos.
De comunicaciones
Se prueban las interfaces de comunicacin entre diferentes compo-
nentes del sistema

Se determina si los tiempos de respuesta del sistema, tanto en con-
Rendimiento
diciones normales como en condiciones especiales, se encuentran dentro de tos
limites predclinidos.
Volumen
Dedicadas a probar el software trabajando con grandes cantidades de datos, similares
a las esperadas en produccin.

Se prueba el sistema con cargas masivas de trabajo. Permiten identili-
Sobrecaro,;)
car los limites soportables por el software y eliminar comportamientos indeseados en
situaciones de sobrecarga.
Disponibilidad
Conisten en probar la disponibilidad del sistema ante fallos de diferente! componentes
de la arquitectura, fsicos o lgicos.
Utilizabilidad o
usauilidad
Se intenta determinar si el sistema ser fcil de utilizar para sus usuarios.
De enlomo
Orientad a probar las interacciones entre el sistema y otros internas de su entorno.
Seguridad (mcuri ty)
Se tratara dt viofar toOa proteccin det sistema, por ejemplo probando aspectos
relativos a la contidcrHiad.id o iniecjndd de 1*1 informacin.
Seguridad ( ofcty) Se prueba si el sistema puede generar riesgos de segundad en su enlomo fsico.

Figura 4.11 pruebas de sistema

4.5.4 Pruebas de aceptacin.

Estas pruebas se realizan para que el cliente certifique que el sistema es vlido para l.
La planificacin detallada de estas pruebas debe haberse realizado en etapas tempranas
del desarrollo del proyecto, con el objetivo de utilizar los resultados como indicador de su
validez: si se ejecutan las pruebas documentadas a satisfaccin del cliente, el producto se
considera correcto y. por tanto, adecuado para su puesta en produccin.

20
SEGUNDO PUNTO DE VISTA.
UNIDAD #4. PRUEBS DE SOFTWARE.
4.1 DEFINICIONES.

4.2 PROCESO DE PRUEBAS.
4.2.1 GENERAR UN PLAN DE PRUEBAS.
Objetivo del documento:
Sealar el enfoque, los recursos y el esquema de actividades de prueba, as
como los elementos a probar, las caractersticas, las actividades de prueba, el
personal responsable y los riesgos asociados.
Estructura del documento segn el estndar:
1. Identificador nico del documento.
2. Introduccin y resumen de elementos y caractersticas a probar.
3. Elementos de software a probar.
4. Caractersticas a probar.
5. Caractersticas que no se probarn.
6. Enfoque general de la prueba.
7. Criterios de paso / fallo para cada elemento.
8. Criterios de suspensin y requisitos de reanudacin.
9. Documentos a entregar.
10. Actividades de preparacin y ejecucin de pruebas.
11. Necesidades de entorno.
12. Responsabilidades en la organizacin y realizacin de pruebas.
13. Necesidades de personal y formacin.
14. Esquema de tiempos.
15. Riesgos asumidos por el plan y planes de contingencias.
16. Y las aprobaciones y firmas con nombre y puesto desempeado.



21
4.2.2 DISEAR PRUEBAS ESPECFICAS.
Objetivo del documento:
Especificar los refinamientos sobre el enfoque general reflejado en el plan e
identificar las caractersticas que se deben probar con este diseo de pruebas.
Estructura del documento segn el estndar:
1. Identificador nico para la especificacin (proporcionar tambin una
referencia del plan asociado (si existe).
2. Caractersticas a probar de los elementos de software (y combinaciones
de caractersticas).
3. Detalles sobre el plan de pruebas del que surge este diseo, incluyendo
las tcnicas de prueba especfica y los mtodos de anlisis de
resultados.
4. Identificacin de cada prueba:
Identificador.
Casos que se van a utilizar.
Procedimientos que se van a seguir.

5. Criterios de paso / fallo de la prueba (criterios para determinar si una
caracterstica o combinacin de caractersticas ha pasado con xito la
prueba o no)
4.2.3 TOMAR CONFIGURACION DEL SOFTWARE A PROBAR.
Objetivo del documento:
Definir uno de los casos de prueba identificado por una especificacin del
diseo de las pruebas.
Estructura del documento segn el estndar:
1. Identificador nico de la especificacin.
2. Elementos de software (por ejemplo, mdulos) que se van a probar:
definir dichos elementos y las caractersticas que ejercitar este caso.
3. Especificaciones de cada entrada requerida para ejecutar el caso (
incluyendo las relaciones entre las diversas entradas; por ejemplo: la
sincronizacin de las mismas).
4. Especificaciones de todas las salidas y las caractersticas requeridas
(por ejemplo, el tiempo respuesta) para los elementos que se van a
probar.
5. Necesidades de entorno (hardware, software y otras, como por ejemplo
el personal).
6. Requisitos especiales de procedimiento (o restricciones especiales en
los procedimientos) para ejecutar este caso.

22
7. Dependencias entre casos (por ejemplo, listar los identificadores de los
casos que se van a ejecutar antes de este caso de prueba).
4.2.4 CONFIGURAR LAS PRUEBAS.
Objetivo del documento:
Especificar los pasos para la ejecucin de un conjunto de casos de prueba, o
ms generalmente, los pasos utilizados para analizar un elemento de software
con el propsito de evaluar un conjunto de caractersticas del mismo.
Estructura del documento segn el estndar:
1. Identificador nico de la especificacin y referencia a la correspondiente
especificacin de diseo de prueba.
2. Objetivo del procedimiento y lista de casos que se ejecutan con el.
3. Requisitos especiales para la ejecucin (por ejemplo, entorno especial o
personal especial)
4. Pasos en el procedimiento. Adems de la manera de registrar los
resultados y los incidentes de la ejecucin, se debe especificar:
La secuencia necesaria de acciones para preparar la ejecucin.
Acciones necesarias para empezar la ejecucin.
Acciones necesarias durante la ejecucin.
Como se realizarn las medidas (por ejemplo, el tiempo de respuesta)
Acciones necesarias para suspender la prueba (cuando los
acontecimientos no previstos lo obliguen).
Puntos para reinicio de la ejecucin y acciones necesarias para el
reinicio en estos puntos.
Acciones necesarias para detener ordenadamente la ejecucin.
Acciones necesarias para restaurar el entorno y dejarlo en la situacin
existente antes de las pruebas.
Acciones necesarias para tratar los acontecimientos anmalos.

4.2.5 EVALUAR RESULTADOS.
Proceso de pruebas, tras el diseo de casos, segn el estndar IEEE 1008.

23



DOCUMENTACION DE LOS RESULTADOS
Histrico de pruebas: Documenta todos los hechos relevantes ocurridos
durante la ejecucin de las pruebas.
Informe de incidentes: Documenta cada incidente (por ejemplo, una
interrupcin en las pruebas debido a un corte de electricidad, bloqueo del

24
teclado, etc.) ocurrido durante la prueba y que requiera una posterior
investigacin.
Resumen de pruebas: Lista los resultados de las actividades de prueba y
aporta una evaluacin del software basada en dichos resultados.

4.2.5.1 DEPURACION.
Es el proceso de analizar y corregir los defectos que se sospecha que contiene
el software.


CONSEJOS PARA LA DEPURACION
Localizacin del error:
Analizar la informacin y pensar (analizar bien, en lugar de aplicar un
enfoque aleatorio de bsqueda del defecto)
Al llegar a un punto muerto, pasar a otra cosa (refresca la mente)
Al llegar a un punto muerto, describir el problema a otra persona (el
simple hecho de describir el problema a alguien puede ayudar)
Usar herramientas de depuracin slo como recurso secundario (no
sustituir el anlisis mental)
No experimentar cambiando el programa (no s qu est mal, as que
cambiar esto y ver lo que sucede )
Se deben atacar los errores individualmente
Se debe fijar la atencin tambin en los datos (no slo en la lgica del
programa)


25
Correccin del error:
Donde hay un defecto, suele haber ms (lo dice la experiencia)
Debe fijarse el defecto, no sus sntomas (no debemos enmascarar
sntomas, sino corregir el defecto)
La probabilidad de corregir perfectamente un defecto no es del 100%
(cuando se corrige, hay que probarlo)
Cuidado con crear nuevos defectos (al corregir defectos se producen
otros nuevos)
La correccin debe situarnos temporalmente en la fase de diseo (hay
que retocar desde el comienzo, no slo el cdigo)
Cambiar el cdigo fuente, no el cdigo objeto

4.2.5.2 ANALISIS DE ERRORES.
El objetivo del anlisis causal es proporcionar informacin sobre la naturaleza
de los defectos. Para ello es fundamental recoger para cada defecto detectado
esta informacin:
Cundo se cometi?
Quin lo hizo
Qu se hizo mal?
Cmo se podra haber prevenido?
Por qu no se detect antes?
Cmo se podra haber detectado antes?
Cmo se encontr el error?





















26

4.3 TECNICAS DE DISEO DE CASOS DE PRUEBAS.




1. Pasos para identificar las clases de equivalencia.
1.- Identificacin de las condiciones de las entradas del programa, es decir,
restricciones de formato o contenido de los datos de entrada.
2.- A partir de ellas, se identifican clases de equivalencia que pueden ser:
a) De datos vlidos.
b) De datos no vlidos errneos.
3.- Existen algunas reglas que ayudan a identificar las clases:
a) Se especifica un rango de valores para los datos de entrada, se creara
una clase vlida y dos clases no vlidas.
b) Se especifica un numero finito y consecutivo e valores, se creara una
clase vlida y dos clases no vlidas.
c) Se especifica una situacin del tipo << debe ser>> o booleana (por
ejemplo, <<el primer caracter debe ser una letra>>), se identifican una clase
vlida (<<es una letra>>) y una no vlida (<<no es una letra>>).
d) Si se especifica un conjunto de valores admitidos y se sabe que el programa
trata de forma diferente cada uno de ellos, se identifica una clase vlida por
cada valor y una no vlida.
e) En cualquier caso, si se sospecha que ciertos elementos de una clase no
se tratan igual que el resto de la misma, deben dividirse en clases menores.

27
d) Si se especifica un conjunto de valores admitidos y se sabe que el programa
trata de forma diferente cada uno de ellos, se identifica una clase vlida por
cada valor y una no vlida.
e) En cualquier caso, si se sospecha que ciertos elementos de una clase no
se tratan igual que el resto de la misma, deben dividirse en clases menores.
2. Pasos para crear los casos de prueba.
Asignacin de un numero nico a cada clase de equivalencia.
Hasta que todas las clases de equivalencia vlidas hayan sido cubiertas
por (incorporadas a) casos de prueba, se tratara de escribir un caso que
cubra tantas clases vlidas no incorporadas como sea posible.
Hasta que todas las clases de equivalencia no vlidas hayan sido
cubiertas por casos de prueba, escribir un caso para una nica clase no
vlida sin cubrir.
EJEMPLO: Aplicacin bancaria en la que el operador debe proporcionar
un cdigo, un nombre y una operacin. Habra que disear casos d
prueba que cubran todas las clases de equivalencia, tanto vlidas como
invlidas en casos de prueba distintos.


TECNICA: Conjetura de errores.
Se enumera una lista de posibles equivocaciones tpicas que pueden cometer
los desarrolladores y de situaciones propensas a ciertos errores.
El valor cero es una situacin propensa a error tanto en la salida como
en la entrada.
En situaciones en las que se introduce un nmero variable de valores,
conviene centrarse en el caso de no introducir ningn valor y en el de un
solo valor. Tambin puede ser interesante una lista que tiene todos los
valores iguales.
Es recomendable imaginar que el programador pudiera haber
interpretado algo mal en su especificacin.
Tambin interesa imaginar lo que el usuario puede introducir como
entrada a un programa.

28
4.5 ESTRATEGIAS DE APLICACIN DE LAS PRUEBAS.
Se analiza como plantear las pruebas en el ciclo de vida del software.
La estrategia de pruebas suele seguir estas etapas:
Comenzar pruebas a nivel de modulo
Continuar hacia la integracin del sistema completo y su
instalacin
Culminar con la aceptacin del producto por la parte del cliente
Relacin entre productos de desarrollo y niveles de prueba:

4.5.1 PRUEBAS DE UNIDAD.

Se trata de las pruebas formales que permiten declarar que un mdulo est
listo y terminado (no las informales que se realizan mientras se desarrollan los
mdulos)
Hablamos de una unidad de prueba para referirnos a uno o ms mdulos que
cumplen las siguientes condiciones [IEEE, 1986a]:
Todos son del mismo programa
Al menos uno de ellos no ha sido probado
El conjunto de mdulos es el objeto de un proceso de prueba
La prueba de unidad puede abarcar desde un mdulo hasta un grupo de
mdulos (incluso un programa completo)
Estas pruebas suelen realizarlas el propio personal de desarrollo, pero evitando
que sea el propio programador del mdulo.



29
4.5.2 PRUEBAS DE INTEGRACIN.

Implican una progresin ordenada de pruebas que van desde los componentes
o mdulos y que culminan en el sistema completo.
El orden de integracin elegido afecta a diversos factores, como lo siguientes:
La forma de preparar casos
Las herramientas necesarias
El orden de codificar y probar los mdulos
El coste de la depuracin
El coste de preparacin de casos
Tipos fundamentales de integracin:
Integracin incremental. Se combina el siguiente mdulo que se debe probar
con el conjunto de mdulos que ya han sido probados.
ascendente. Se comienza por los mdulos hoja.
descendente. Se comienza por el mdulo raz.
Integracin no incremental. Se prueba cada mdulo por
separado y luego se integran todos de una vez y se prueba el
programa completo.
Habitualmente las pruebas de unidad y de integracin se solapan y mezclan en
el tiempo.
Ventajas de los tipos de pruebas de integracin:




30
4.5.3 PRUEBAS DE SISTEMA.

Es el proceso de prueba de un sistema integrado de hardware y software para
comprobar lo siguiente:
Cumplimiento de todos los requisitos funcionales, considerando el
producto software final al completo en un entorno de sistema.
El funcionamiento y rendimiento en las interfaces hardware, software, de
usuario y de operador.
Adecuacin de la documentacin de usuario.
Ejecucin y rendimiento en condiciones lmite y de sobrecarga.




4.5.4 PRUEBAS DE ACEPTACION.

Es la prueba planificada y organizada formalmente para determinar si se
cumplen los requisitos de aceptacin marcados por el cliente.
Sus caractersticas principales son las siguientes:
Participacin del usuario
Est enfocada hacia la prueba de los requisitos de usuario
especificados.
Est considerada como la fase final del proceso para crear una
confianza en que el producto es el apropiado para su uso en explotacin











31
CONCLUSIONES.

Jos Luis Padilla Nava.

Al desarrollar un software es de suma importancia efectuar pruebas acerca de
su funcionamiento, si cumple con lo que el cliente haba solicitado, adems de
que al realizar pruebas nos ayuda a encontrar cualquier fallo que no habamos
visto, validamos el producto y podemos as eliminar cualquier defecto o alguna
caracterstica que no cumpla con nuestra visin a final.
En esta unidad hemos aprendido acerca de las diferentes pruebas que se
aplican al software, el proceso que conlleva efectuar cada prueba y algunas
estrategias sobre la aplicacin de las pruebas.


Javier Garca Betancur.

En esta unidad se conocieron los diferentes procesos que se tienen que aplicar
a los diferentes proyectos o software, los procesos el cual se le debe aplicar a
cada software como las pruebas el cual debe pasar por ese proceso para
verificar la calidad as como los errores, la verificacin y validacin. La
documentacin del desarrollo, las estrategias y las tcnicas que se utilizan
para el buen desarrollo de un proyecto.

Jairo Manuel Lozano Mendoza.

Esta unidad se aprendi lo que son las pruebas de un software son un conjunto
de actividades que permiten verificar y revelar la calidad de un producto
software. Son utilizadas para identificar posibles fallos de implementacin,
calidad, o usabilidad de un programa de la computadora.
Las pruebas de software se integran dentro de las diferentes fases del ciclo del
software dentro de la Ingeniera de software. As se ejecuta un programa y
mediante tcnicas experimentales se trata de descubrir que errores tiene.

Jos Miguel Morales Toledo.

El aprendizaje de esta unidad es ms que otros conceptos son las pruebas que
nos dice que son un conjunto de actividades que se pueden planificar por
adelantado y llevar a cabo sistemticamente.
La prueba la lleva a cabo el responsable del desarrollo del software y (para
grandes proyectos) un grupo independiente de pruebas tambin la validacin
del software se utiliza para mostrar que el sistema se ajusta a su especificacin
y que cumple las expectativas del usuario que lo comprar.












32


BIBLIOGRAFIA.

Sommerville, lan. Ingeniera de Software. Prentice Hall. 2001.

Pressman Roger S. Ingeniera del Software, 5/E. Mc.Gaw-Hill. 2001.

Jacobson, Ivar. Object-Oriented Software Engineering: A Use Case Driven
Approach. Addison-Wesley, 1992.
Bruegge, Bernd. Ingeniera de software Orientada a objetos. Prentice Hall.
2000 UML.
[AG92] Robert Allen y David Garlan. A formal approach to
software architectures. Proceedings of the IFIP Congress 92,
Setiembre de 1992.
[AAG93] Gregory Abowd, Robert Allen y David Garlan. Using
style to understand descriptions of software architecture.
Proceedings of SIGSOFT'93: Foundations of Software
Engineering, Software Engineering Notes 18(5), pp. 9-20. ACM
Press, Diciembre de 1993.
[AAG95] Gregory Abowd, Robert Allen y David Garlan.
Formalizing style to understand descriptions of software
architecture. Technical Report, CMU-CS-95-111, Enero de
1995.
[Abd96] Ahmed Abd-Allah. Composing heterogeneous software
architectures. Tesis doctoral, Department of Computer
Sciences, USC, Agosto de 1996.