CARATULA

PRESENTACION

INTRODUCCION

INDICE

TITULO DEL TEMA DE LA EXPOSICION

IMPORTANCIA DE LAS PRUEBAS A TRAVEZ DEL CICLO DE VIDA
DEL SOFTWARE

OBJETIVOS

CONTENIDO DEL TEMA :

IMPORTANCIA DE LAS PRUEBAS A TRAVEZ DEL CICLO DE VIDA
DEL SOFTWARE
MODELOS DE DESARROLLO DE SOFTWARE

Pruebas a travez del modelo V-General

El Mtodo-V define un procedimiento uniforme para el desarrollo de productos para las TIC.
Es el estndar utilizado para los proyectos de la Administracin Federal alemana y
de defensa. Como est disponible pblicamente muchas compaas lo usan. Es un mtodo
de gestin de proyectos comparable a PRINCE2 y describe tanto mtodos para la gestin
como para el desarrollo de sistemas.
Es una representacin grfica del ciclo de vida del desarrollo de sistemas. En l se
resumen las principales medidas que deben adoptarse en relacin con las prestaciones
correspondientes en el marco del sistema informtico de validacin.
Es un proceso que representa la secuencia de pasos en el desarrollo del ciclo de vida de
un proyecto. Se describen las actividades y resultados que deben producirse durante el
desarrollo del producto. El lado izquierdo de la V representa la descomposicin de las
necesidades, y la creacin de las especificaciones del sistema. El lado derecho de
la Vrepresenta la integracin de las piezas y su verificacin. V significa Verificacin y
validacin. Es muy similar al modelo de la cascada clsico ya que es muy rgido y
contiene una gran cantidad de iteraciones.
OBJETIVOS
El Mtodo-V fue desarrollado para regular el proceso de desarrollo de software por la
Administracin Federal Alemana. Describe las actividades y los resultados que se
producen durante el desarrollo del software.
Proporciona una gua para la planificacin y realizacin de proyectos. Los
siguientes objetivos estn destinados a ser alcanzados durante la ejecucin del proyecto:
Minimizacin de los riesgos del proyecto
Mejora la transparencia del proyecto y control del proyecto, especificando los enfoques
estandarizados, describe los resultados correspondientes y funciones de responsabilidad.
Permite una deteccin temprana de las desviaciones y los riesgos y mejora la gestin de
procesos, reduciendo as los riesgos del proyecto.
Mejora y Garanta de Calidad
Como un modelo de proceso estndar, asegura que los resultados que se proporcionan
sean completos y contengan la calidad deseada. Los resultados provisionales definidos se
puede comprobar en una fase temprana. La uniformidad en el contenido del producto
mejora la legibilidad, comprensibilidad y verificabilidad.
Reduccin de los gastos totales durante todo el proyecto y sistema de Ciclo de Vida
El esfuerzo para el desarrollo, produccin, operacin y mantenimiento de un sistema
puede ser calculado, estimado y controlado de manera transparente mediante la aplicacin
de un modelo de procesos estandarizados. Reduciendo la dependencia en los
proveedores y el esfuerzo para las siguientes actividades y proyectos.
Mejora de la comunicacin entre todos los inversionistas
La descripcin estandarizada y uniforme de todos los elementos pertinentes y trminos es
la base para la comprensin mutua entre todos los inversionistas. De este modo, se
reduce la prdida por friccin entre el usuario, comprador, proveedor y desarrollador.
La corriente de especificacin (parte izquierda, Project definition) consiste principalmente
de:

Conceptos de operaciones: que debe hacer el sistema a grandes rasgos.

Requisitos del sistema y arquitectura del mismo.
Diseo detallado.
La corriente de pruebas (parte derecha, Project test and integration), por su parte, suele
consistir de:

Integracin de las distintas partes, prueba y verificacin de las mismas.

Verificacin y validacin del sistema en conjunto.
Mantenimiento del sistema.
La corriente de desarrollo puede consistir (depende del tipo de sistema y del alcance del
desarrollo) en personalizacin, configuracin o codificacin.

PRUEBAS A TRAVEZ DEL MODELO W

El modelo en W es una evolucin del modelo en V. Ms que aportar algo nuevo lo que pretende es
aclarar ciertos aspectos que el modelo en V no termina de dejar claros (si bien bastantes de las
caractersticas del modelo en W ya eran de aplicacin en el modelo en V).
En este caso tenemos dos V, una correspondiente al proceso de desarrollo y otra correspondiente al
proceso de testing. Hay quienes piensan y tal vez no les falte razn que aadir una V especfica para el
testing lo nico que ha hecho es trasladar el mismo defecto a otra dimensin, ya que vamos a seguir
teniendo un caso donde se construye y otro donde se fiscaliza, si bien, el hecho de que este modelo
integre explcitamente las vueltas a atrs acerca ms ambos tipos de tareas.
Entonces, si tenemos ahora dos V, qu representa el lado creciente de cada una de ellas. Pues realmente
lo que hace el modelo en W es diferenciar clramente cules son los hitos de un proyecto software (algo
que poda resultar confuso en el modelo en V) de manera que en la primera recta estn los hitos previos a
la construccin del software (con las pruebas y verificaciones correspondientes a los hitos documentales)
y en la segunda los posteriores a la construccin del software (verificacin sobre el producto software).
PRUEBAS A TRAVVEZ DEL MODELO ITERATIVO

Este modelo, tambin conocido como Evolutivo, es una derivacin del ciclo de vida en
cascada puro, que busca reducir el riesgo que surge entre las necesidades del Usuario y
el Producto final por malos entendidos durante la etapa de solicitud de requerimientos.

En el ciclo de vida iterativo, en cada Iteracin se reproduce el ciclo de vida en cascada a menor
escala. Los objetivos de una Iteracin se establecen en funcin de la evaluacin de
las Iteraciones precedentes. Desde el principio, al final de cada Iteracin se le entrega
al Cliente una versin completa y mejorada del Producto. El Cliente es quien luego de
cada Iteracin evala el Producto y lo corrige o propone mejoras.
Estas Iteraciones irn Refinando el sistema y se repetirn hasta obtener un Producto que
satisfaga al Cliente.
La Especificacin de requisitos se realiza en forma creciente: a medida que los Usuarios logran
un mejor entendimiento del problema, ste es reflejado en el sistema software. Es decir,
el Producto de cada etapa de Especificacin de requisitos es un agregado o mejora
al Producto de la etapa de especificacin anterior.
Este modelo se basa en dos premisas:

1) Los Usuarios a menudo no saben bien lo que quieren o necesitan.

2) Por lo general, los requisitos en algn momento van a cambiar.
Para solucionar el primer punto, los requisitos se determinan en base a alguna forma
operacional del sistema (por ejemplo, un prototipo) para ser revisado por los Usuarios. Para
atender el segundo punto, se realizan entregas parciales del sistema que permiten incorporar
nuevos requisitos o cambios en requisitos existentes en la siguiente entrega. Es decir, cada
versin es una mejora sobre la predecesora.
Este modelo se utiliza cuando no se puede especificar a priori todos los requisitos del
software, sino que el proceso ayudar a ir descubriendo paso a paso los requisitos a partir de
cada nueva Entrega.

NIVELES DE PRUEBA
PRUEBAS DE COMPONENTES
La prueba de componente tambin llamada prueba unitaria es por definicin la prueba que se lleva a
cabo luego de haber construido el componente.

Como los desarrollos son hechos en diferentes lenguajes, puede llegar a haber diferencias de conceptos
y por tal, tendremos que por componentes podemos tener a una: prueba de mdulo, prueba de clase
prueba de unidad, y en estos casos en los que el desarrollador interviene probando, estaremos en
presencia de las pruebas del desarrollador

Para comenzar a entender de qu hablamos, debemos tener muy en claro cul es el alcance que
debemos perseguir con este tipo de prueba.

En principio, hay que saber que: (a) slo se prueban componentes individuales, (b) cada componente
es probado en forma independiente, y (c) los casos de prueba podrn ser obtenidos a partir de ciertos
artefactos. Abordemos, de manera sencilla cada uno de estos puntos.

Hay que considerar el aspecto individual, ya que un componente podra estar compuesto por un
conjunto de unidades pequeas y por ende, en estos casos habr que tomar y someter a la/s prueba/s
cada una de ellas. No obstante, a veces suele ocurrir que no se puedan probar de manera individual
estas partes por diversas razones, en estos casos habr que trabajar de otra manera que en un rato
veremos.
Una vez que podemos y no tenemos ningn inconveniente en probar en forma independiente al
componente, el objetivo ser identificar fallos como producto de defectos internos que presente el
componente, sin olvidarse que puede llegar a ocurrir que encontremos defectos cruzados entre los
componentes que estemos tratando y que por ende, es decir por definicin primaria, quedara fuera del
alcance de estas pruebas ya que son de componentes.

En cuanto a los casos de prueba que se puedan escribir para ejecutarlos, debemos tomarnos de ciertos
artefactos como pueden ser: las especificaciones del componente, el diseo de software y/o el modelo
de datos. Cada uno de ellos aportar lo necesario para permitir escribir un caso de prueba bsico que
seguramente podremos mejorar si investigamos ms, pero que de por s, nos ayudar a probar una
condicin particular que presente el componente a probar.

PRUEBAS DE INTEGRACION
Pruebas integrales o pruebas de integracin son aquellas que se realizan en el mbito
del desarrollo de software una vez que se han aprobado las pruebas unitarias y lo que
prueban es que todos los elementos unitarios que componen el software, funcionan juntos
correctamente probndolos en grupo. Se centra principalmente en probar la comunicacin
entre los componentes y sus comunicaciones ya sea hardware o software.
Este tipo de pruebas son dependientes del entorno en el que se ejecutan. Si fallan, puede ser porque el
cdigo est bien, pero haya un cambio en el entorno.

PRUEBAS DE SISTEMA
Lo suyo sera realizar este tipo de pruebas despus de las pruebas de integracin.
Aqu se engloban tipos de pruebas cuyo objetivo es probar todo el sistema software completo e integrado,
normalmente desde el punto de vista de requisitos de la aplicacin.
Aqu apareceran las pruebas funcionales, pruebas de carga, de estrs etc.

Pruebas de aceptacin
Por ltimo, las pruebas de aceptacin se realizan para comprobar si el software cumple con las
expectativas del cliente, con lo que el cliente realmente pidi.

TIPOS DE PRUEBAS
Una prueba funcional es una prueba basada en la ejecucin, revisin y retroalimentacin
de las funcionalidades previamente diseadas para el software (requisitos funcionales).
Hay distintos tipos como por ejemplo:

Pruebas unitarias
Pruebas de componentes
Pruebas de integracin
Pruebas de sistema
Pruebas de humo
Pruebas alpha
Pruebas beta
Pruebas de aceptacin

Pruebas de regresin
PRUEBAS NO FUNCIONALES
Una prueba no funcional es una prueba cuyo objetivo es la verificacin de un requisito que
especifica criterios que pueden usarse para juzgar la operacin de un sistema (requisitos
no funcionales) como por ejemplo la disponibilidad, accesibilidad, usabilidad,
mantenibilidad, seguridad, rendimiento. Podemos clasificar las pruebas no funcionales
segn el tipo de requisito no funcional que abarcan:

Pruebas de compatibilidad
Pruebas de seguridad
Pruebas de Stress
Pruebas de usabilidad
Pruebas de rendimiento
Pruebas de internacionalizacin y localizacin
Pruebas de escalabilidad
Pruebas de mantenibilidad
Pruebas de instalabilidad
Pruebas de portabilidad

PRUEBAS DE ARQUITECTURA DE SOFTWARE k2 ((K2 - entender,

explicar , razonar)
)

Su objetivo es:
1. Comparar cuatro tipos de pruebas de software (funcional, no funcional, estructural y
asociado al cambio) (K2).
2. Reconocer que las pruebas funcionales y estructurales se llevan a cabo en cualquier
nivel de prueba (K1).
3. Identificar y describir los tipos de pruebas no funcionales en base a requisitos no
funcionales (K2).
4. Identificar y describir los tipos de pruebas en base al anlisis de la estructura o
arquitectura o arquitectura de un sistema de software (K2).
5. Describir el objetivo de las pruebas de confirmacin y regresin (K2).

Las pruebas estructurales 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. Para ilustrar esto, se ha implementado la
especificacin de la rutina de bsqueda como una rutina de bsqueda binaria (ver figura). Por
supuesto, sta tiene precondiciones ms estrictas. La secuencia se implementa como un
vector, este vector debe estar ordenado y el valor del lmite inferior del vector debe ser menor
que el valor del lmite superior.

Examinando el cdigo de la rutina de bsqueda, puede verse que la bsqueda binaria

implica dividir el espacio de bsqueda en tres partes. Cada una de estas partes constituye
una particin de equivalencia (ver figura). A continuacin, se disean los casos de prueba
en los que el elemento buscado se sita en los lmites de cada una de estas particiones.

PRUEBAS ASOCIADAS AL CAMBIO

Pruebas asociadas a cambios: Repeticin de pruebas

y pruebas de regresin (K2 - entender, explicar ,
razonar)
Objetivos:

1. Comparar cuatro tipos de pruebas de software (funcional, no funcional,

estructural y asociado al cambio) (K2).
2. Reconocer que las pruebas funcionales y estructurales se llevan a cabo en
cualquier nivel de prueba (K1).
3. Identificar y describir los tipos de pruebas no funcionales en base a requisitos
no funcionales (K2).
4. Identificar y describir los tipos de pruebas en base al anlisis de la estructura o
arquitectura o arquitectura de un sistema de software (K2).
5. Describir el objetivo de las pruebas de confirmacin y regresin (K2).

Una vez detectado y corregido un defecto, el software debe volver a probarse para confirmar que
el defecto original ha sido corregido con xito. A esto se le denomina confirmacin. La
depuracin (correccin de defectos) es una actividad de desarrollo, no una actividad de pruebas.

Las pruebas de regresin son la prueba reiterada de un programa ya probado, despus de haber
sido modificado, con vistas a localizar defectos surgidos o no descubiertos como resultados del
cambio o de los cambios. Estos defectos pueden estar en el software objeto de las pruebas, o
en cualquier otro componente de software asociado o no asociado. Se realizan cuando el
software, o su entorno, sufren modificaciones. El alcance de las pruebas de regresin depende
del riesgo de no encontrar defectos en el software que antes funcionaba.

Las pruebas deben ser repetibles si desean utilizarse a efectos de las pruebas de confirmacin
o para dar soporte de las pruebas de regresin.

PRUEBAS DE MANTENIMIENTO DE SOFTWARE

Pruebas Posteriores a la aceptacin del producto

Es la tarea de modificar, corregir o mejorar los sistemas existentes. Una vez que el sistema pasa
a formar parte de la vida diaria de la empresa cada programa, procedimiento y estructura de datos
pasa a ser una pieza del negocio que como tal debe funcionar en forma constante, exacta y
confiable, por esta razn una vez que el sistema entra en operacin se hace necesario mantenerlo
para ajustar las funciones que puedan requerir cambios o para corregir errores que se le hallan
pasado por alto al desarrollador y mejorarlo para apoyar de mejor manera los objetivos
estratgicos de la empresa.