diapositivas

Esta es una vista previa del archivo. Inicie sesión para ver el archivo original

Tema 9. Pruebas del Software
1. Definiciones asociadas
2. El proceso de prueba
3. Técnicas de diseño de casos de prueba
4. Pruebas estructurales
5. Pruebas funcionales
6. Pruebas aleatorias
7. Enfoque práctica de diseño de casos
8. Documentación del diseño de pruebas
9. Ejecución de pruebas
10. Estrategia de aplicación de pruebas en el ciclo de vida
 (
PRUEBAS DEL SOFTWARE
12.005
)
Cuando ya dispongamos del código ejecutable de la aplicación
 (
a
Activid.
1
Activid.
2
….........
Activ. N-1
Pruebas
)Ciclo de vid software
 (
….........
)Controles
Pretenden una evaluación de la calidad de los productos generados
Todo Sistema debe haber sido probado exhaustivamente a través de una ejecución controlada antes de ser entregado al cliente
 (
PRUEBAS DEL SOFTWARE
12.010
)
 (
¿Estamos construyendo 
correctamente 
el producto?
) (
¿Estamos construyendo el producto correcto?
) Verificación: El proceso de evaluación de un sistema (o de uno de sus componentes para determinar si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase
 Validación: El proceso de evaluación de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos marcados por el usuario
 (
PRUEBAS DEL SOFTWARE
12.020
)
DEFINICIONES
· (
Proceso de ejecutar un programa con el fin de encontrar errores
)Pruebas (test): «una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluación de algún aspecto»
· Caso de prueba (test case): «un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular»
· (
Instrucción incorrecta
)Defecto (defect, fault, «bug»): «un defecto en el software como, por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos en un programa»
 (
PRUEBAS DEL SOFTWARE
12.030
)
DEFINICIONES
Fallo
Defecto Fallo Error
· 
Fallo (failure): «La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados»
· Error (error): tiene varias acepciones:
· La diferencia entre un valor calculado, observado o medio y el valo verdadero, especificado o teóricamente correcto.
· Un defecto
· Un resultado incorrecto
· Una acción humana que conduce a un resultado incorrecto .
 (
PRUEBAS DEL SOFTWARE
12.040
)
RELACION ENTRE ERROR, DEFECTO Y FALLO
Error
Equivocación del programador
2 + 2 = 5
Sistema de gestión de aeropuerto
Accidente (seguridad)
Defecto (calidad)
S.Aproximación
¡Xyx//	 
???
Error
Se Plasma
Defecto
Da lugar a Fallo
Fallo (fiabilidad)
Que provocEafectos negativos
(del programador)	(en el software)	(el sistema no se	(dependiendo de la
comporta como debería)	criticidad del sistema)
 (
PRUEBAS DEL SOFTWARE
12.045
)
IDEAS PARADÓGICAS DE LAS PRUEBAS
· La prueba exhaustiva del software es impracticable (no se pueden probar todas las posibilidades de su funcionamiento ni siquiera en programas sencillos
· El objetivo de las pruebas es la detección de defectos en el software (descubrir un error es el éxito de una prueba)
· Mito € un defecto implica que somos malos profesionales y que debemos sentirnos culpables € todo el mundo comete errores
· El descubrimiento de un defecto significa un éxito para la mejora de la calidad
 (
PRUEBAS DEL SOFTWARE
12.050
)
RECOMENDACIONES PARA UNAS PRUEBAS EXITOSAS
	Cada caso de prueba debe definir el resultado de salida esperado que se comparará con el realmente obtenido.
	El programador debe evitar probar sus propios programas, ya que desea (consciente o inconscientemente) demostrar que funcionan sin problemas.
€ Además, es normal que las situaciones que olvidó considerar al crear el programa queden de nuevo olvidados al crear los casos de prueba
	Se debe inspeccionar a conciencia el resultado de cada prueba, así, poder descubrir posibles síntomas de defectos.
	Al generar casos de prueba, se deben incluir tanto datos de entrada válidos y esperados como no válidos e inesperados.
 (
PRUEBAS DEL SOFTWARE
12.060
)
RECOMENDACIONES PARA UNAS PRUEBAS EXITOSAS
 Las pruebas deben centrarse en dos objetivos (es habitual olvidar el segundo):
Probar si el software no hace lo que debe hacer
Probar si el software hace lo que debe hacer, es decir, si provoca efectos secundarios adversos
Se deben evitar los casos desechables, es decir, los no documentados ni diseñados con cuidado.
€ Ya que suele ser necesario probar muchas veces el software y por tanto hay que tener claro qué funciona y qué no
No deben hacerse planes de prueba suponiendo que, prácticamente, no hay defectos en los programas y, por lo tanto, dedicando pocos recursos a las pruebas € siempre hay defectos
 (
PRUEBAS DEL SOFTWARE
12.070
)
RECOMENDACIONES PARA UNAS PRUEBAS EXITOSAS
 La experiencia parece indicar que donde hay un defecto hay otros, es decir, la probabilidad de descubrir nuevos defectos en una parte del software es proporcional al número de defectos ya descubierto.
Las pruebas son una tarea tanto o más creativa que el desarrollo de software. Siempre se han considerado las pruebas como una tarea destructiva y rutinaria.
Es interesante planificar y diseñar las pruebas para poder detectar el máximo número y variedad de defectos con el mínimo consumo de tiempo y esfuerzo
 (
PRUEBAS DEL SOFTWARE
12.080
)
CICLO COMPLETO DE LAS PRUEBAS
 (
PRUEBAS DEL SOFTWARE
12.090
)
PROCESO DE PRUEBA
ACTIVIDADES
† La depuración (localización y corrección de defectos)
† El análisis de la estadística de errores
€ Sirve para realizar predicciones de la fiabilidad del software y para detectar las causas más habituales de error y por tanto mejorar los procesos de desarrollo
 (
PRUEBAS DEL SOFTWARE
12.100
)
ENFOQUES DE DISEÑO DE PRUEBAS
Existen tres enfoques principales para el diseño de casos:
1.- El enfoque estructural o de caja blanca. Se centra en la estructura interna del programa (analiza los caminos de ejecución).
2.- El enfoque funcional o de caja negra. Se centra en las funciones, entradas y salidas.
3.- El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones estadísticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba
 (
PRUEBAS DEL SOFTWARE
12.110
)
LOS ENFOQUES DE DISEÑO DE PRUEBAS DE CAJA BLANCA Y DE CAJA NEGRA
Caja blanca
 (
Entrada
Salida
)Estructural
Caja negra
 (
Entrada
Salida
 Funciones 
)Funcional
 (
PRUEBAS DEL SOFTWARE
12.120
)
PRUEBAS ESTRUCTURALES
GRAFO DE FLUJO DE UN PROGRAMA (PSEUDOCODIGO)
 (
1
2
WHILE
O
3
4
WHILE
IF (nacional) THEN
y
5
Sumar venta nacional a total nacional ELSE
Sumar venta extranjero a total extranjero
ENDIF;
6
7a
7b
8,9
ENDWHILE;
10,11
12,13
Cerrar archivos.
Escribir línea de listado;
Limpiar área de impresión;
ENDWHILE;
Leer archivo ventas, al final indicar no más registros;
Total nacional = 0;
Total extranjero = 0;
(haya registros ventas) D
Abrir archivos;
Leer archivo ventas, al final indicar no más registros; Limpiar línea de impresión;
(mismo producto)
(haya reg. ventas)
)El diseño de casos de prueba tiene que estar basado en la elección de caminos importantes que ofrezcan una seguridad aceptable
de que se descubren defectos (un programa de 50 líneas con 25 sentencias if en serie da lugar a 33,5 millones de secuencias posibles), para lo que se usan los criterios de cobertura lógica.
 (
PRUEBAS DEL SOFTWARE
12.130
)
PRUEBAS ESTRUCTURALES
 (
x
) (
x
) (
x
)GRAFO DE FLUJO DE LAS ESTRUCTURAS BASICAS DE PROGRAMA
Secuencia	Si x entonces...
(If x then...else...)
Consejos:
-Separar todas las condiciones
Hacer... hasta x (Do...until x) Repetir
Mientras x hacer... (While x do...)
-Agrupar sentencias ‘simples’ en bloques
-Numerar todos los bloques de sentencias y también las condiciones
(
PRUEBAS DEL SOFTWARE
12.140
)
Menos riguroso (más barato)
PRUEBAS ESTRUCTURALES
CRITERIOS DE COBERTURA LÓGICA
· Cobertura de sentencias. Se trata de generar los casos de prueba necesarios para que cada sentencia o instrucción del programa se ejecute al menos una vez.
· Cobertura de decisiones. Consiste en escribir casos suficientes para que cada decisión tenga, por lo menos una vez, un resultado verdadero y, al menos una vez, uno falso. (Incluye a la cobertura de sentencias)
· Cobertura de condiciones. Se trata de diseñar tantos casos como sea necesario para que cada condición de cada decisión adopte el valor verdadero al menos una vez y el falso al menos una vez. (No incluye cobertura de condiciones)
· Criterio de decisión/condición. Consiste en exigir el criterio de cobertura de condiciones obligando a que se cumpla también el criterio de decisiones.
· Criterio de condición múltiple. En el caso de que se considere que la evaluación de las condiciones de cada decisión no se realiza de forma simultánea, se puede considerar que cada decisión multicondicional se descompone en varias condiciones unicondicionales. Ejemplo en la siguiente diapositiva.
· Criterio de cobertura de caminos. Se recorren todos los caminos (impracticable)
Más riguroso (más caros)
 (
PRUEBAS DEL SOFTWARE
12.150
)
PRUEBAS ESTRUCTURALES
EJEMPLO DE DESCOMPOSICION DE UNA DECISION MULTICONDICIONAL
then
then (a=1)	 	(c=4)	 	
 (
(a=1) and (c=4)
else
)else
 (
PRUEBAS DEL SOFTWARE
12.160
)
PRUEBAS ESTRUCTURALES
LA COMPLEJIDAD DE McCABE V(G) (COMPLEJIDAD CICLOMÁTICA)
· La métrica de McCabe ha sido muy popular en el diseño de pruebas
· Es un indicador del número de caminos independientes que existen en un grafo
La complejidad de McCabe se puede calcular de cualquiera de estas 3 formas
1. 
V (G) = a - n + 2, siendo a el número de arcos o aristas del grafo y n el número de nodos.
2. V (G) = r, siendo r el número de regiones cerradas del grafo.
3. V(G) = c + 1, siendo c el número de nodos de condición.
 (
PRUEBAS DEL SOFTWARE
12.165
)
PRUEBAS ESTRUCTURALES
LA COMPLEJIDAD DE McCABE V(G)
· El criterio de prueba de McCabe es: Elegir tantos casos de prueba como caminos independientes (calculados como V(G))
· La experiencia en este campo asegura que:
· V(G) marca el límite mínimo de casos de prueba para un programa
· Cuando V(G) > 10 la probabilidad de defectos en el módulo o programa crece mucho € quizás sea interesante dividir el módulo
 (
1
) (
a1
) (
a3
) (
a2
) (
2
) (
a4
) (
3
) (
Región 1
) (
a5
) (
a6
) (
a7
) (
4
) (
Región
) (
2
a9
) (
a8
) (
Región 3
) (
5
) (
a10
) (
6
) (
a12
) (
a11
) (
Región 4
) (
8
) (
7
) (
a13
) (
a14
) (
9
) (
10
) (
Región
) (
5
) (
11
V(G) = 14-11+2 = 5
V(G) = 5 regiones cerradas V(G) = 5 condiciones
) (
a)
b)
c)
)
 (
PRUEBAS DEL SOFTWARE
12.170
)
PRUEBAS ESTRUCTURALES
CALCULO DE LA COMPLEJIDAD CICLOMATICA SOBRE UN GRAFO
 (
PRUEBAS DEL SOFTWARE
12.180
)
PRUEBAS FUNCIONALES
Se centran en las funciones, entradas y salidas € Es impracticable probar el software para todas las posibilidades. De nuevo hay que tener criterios para elegir buenos casos de prueba
Un caso de prueba funcional es bien elegido si se cumple que:
· Reduce el número de otros casos necesarios para que la prueba sea razonable. Esto implica que el caso ejecute el máximo número de posibilidades de entrada diferentes para así reducir el total de casos.
· Cubre un conjunto extenso de otros casos posibles, es decir, no indica algo acerca de la ausencia o la presencia de defectos en el conjunto específico de entradas que prueba, así como de otros	conjuntos similares.
 (
PRUEBAS DEL SOFTWARE
12.190
)
PRUEBAS FUNCIONALES
TÉCNICA: PARTICIPACIONES O CLASES DE EQUIVALENCIA
· (
Cualidades que definen un buen caso de prueba
)Cada caso debe cubrir el máximo número de entradas
· Debe tratarse el dominio de valores de entrada dividido en un número finito de clases de equivalencia que cumplan la siguiente propiedad: la prueba de un valor representativo de una clase permite suponer «razonablemente» que el resultado obtenido (existan defectos o no) será el mismo que el obtenido probando cualquier otro valor de la clase
Lo que hay que hacer es:
· 
Identificar clases de equivalencia
· Crear casos de prueba correspondiente
 (
PRUEBAS DEL SOFTWARE
12.200
)
PRUEBAS FUNCIONALES
PARTICIPACIONES O CLASES DE EQUIVALENCIA
PASOS PARA IDENTIFICAR CLASES DE EQUIVALENCIA
1. Identificación 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 válidos
b) De datos no válidos o erróneos
3. Existen algunas reglas que ayudan a identificar clase:
a) Si se especifica un rango de valores para los datos de entrada, secreará una clase válida y dos clases no válidas
b) Si se especifica un número finito y consecutivo de valores, se creará una clase válida y dos no válidas
 (
PRUEBAS DEL SOFTWARE
12.210
)
PRUEBAS FUNCIONALES
PARTICIPACIONES O CLASES DE EQUIVALENCIA
PASOS PARA IDENTIFICAR CLASES DE EQUIVALENCIA
c) Si se especifica una situación del tipo «debe ser» o booleana (por ejemplo, «el primer carácter debe ser una letra»), se identifican una clase válida («es una letra») y una no válida («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 válida por cada valor y una no válida
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
 (
PRUEBAS DEL SOFTWARE
12.220
)
PRUEBAS FUNCIONALES
PARTICIPACIONES O CLASES DE EQUIVALENCIA
PASOS PARA IDENTIFICAR CASOS DE PRUEBA
El último paso del método es el uso de las clases de equivalencia para identificar los casos de prueba correspondientes. Este proceso consta de las siguientes fases:
· Asignación de un número único a cada clase de equivalencia
· Hasta que todas las clases de equivalencia válidas hayan sido cubiertas por (incorporadas a) casos de prueba, se tratará de escribir un caso que cubra tantas clases válidas no incorporadas como sea posible
· Hasta que todas las clases de equivalencia no válidas hayan sido cubiertas por casos de prueba, escribir un caso para una única clase no válida sin cubrir
 (
PRUEBAS DEL SOFTWARE
12.230
)
PRUEBAS FUNCIONALES
TABLA DE CLASES DE EQUIVALENCIA DEL EJEMPLO
 (
 
Condición de entrada
Clases válidas
Clases inválidas
Código área
Nº de 3 dígitos que no empieza con 0 ni 1)
(1) 200 

código 

999
código
 
<200
código
 
>999
no es
 
número
Nombre para identificar la
operación
(5) seis caracteres
menos de 6 caracteres
más de 6
 
caracteres
Orden
Una de las siguientes 
€
«cheque»
«depósito»
«pago
 
factura»
«retirada de
 
fondos»
(12) ninguna orden válida
)Ejemplo: Aplicación bancaria en la que el operador debe proporcionar un código, un nombre y una operación
Habría que diseñar casos de prueba que cubran todas las clases de equivalencia, tanto válidas como inválidas, y para las inválidas en casos de prueba distintos
 (
PRUEBAS DEL SOFTWARE
12.240
)
PRUEBAS FUNCIONALES
TÉCNICA: ANALISIS DE VALORES LIMITE (AVL)
· La experiencia indica que los casos de prueba que exploran las condiciones límite de un programa producen un mejor resultado para detectar defectos
· El AVL es una técnica de diseño de casos de prueba que complementa a la de particiones de equivalencia. Las diferencias son las siguientes:
Más que elegir «cualquier» elemento como	representativo de una clase de equivalencia,	se requiere la selección de uno o más elementos tal que los márgenes se sometan a prueba
Más que concentrarse únicamente en el dominio de entrada (condiciones de entrada), los casos de prueba se generan considerando también el espacio de salida
 (
PRUEBAS DEL SOFTWARE
12.250
)
PRUEBAS FUNCIONALES
ANALISIS DE VALORES LIMITE (AVL)
LAS REGLAS PARA IDENTIFICAR CLASES
SON:
1. 	Si una condición de entrada especifica un rango de valores, se deben generar casos para los extremos del rango y casos no válidos para situaciones justo más allá de los extremos
2. 	Si la condición de entrada especifica un número finito y consecutivo de valores, hay que escribir casos para los números máximo, mínimo, uno más del máximo y uno menos del mínimo de valores
3. Usar la regla 1 para la condición de salida
4. Usar la regla 2 para cada condición de salida
· Los valores límite de entrada no generan necesariamente los valores límite de salida (recuérdese la función seno, por ejemplo)
· No siempre se pueden generar resultados fuera del rango de salida (pero es interesante considerarlo)
5. Si la entrada o la salida de un programa es un conjunto ordenado, los casos se deben concentrar en el primero y en el último elemento
 (
PRUEBAS DEL SOFTWARE
12.260
)
PRUEBAS FUNCIONALES
TÉCNICA: CONJETURA DE ERRORES
Se enumera una lista de posibles equivocaciones típicas que pueden cometer los desarrolladores y de situaciones propensas a ciertos errores
· 	El valor cero es una situación propensa a error tanto en la salida como en la entrada
· 	En situaciones en las que se introduce un número variable de valores, conviene centrarse en el caso de no introducir ningún valor y en el de un solo valor. También puede ser interesante un lista que tiene todos los valores iguales
· 	Es recomendable imaginar que el programador pudiera haber interpretado algo mal en la especificación
· 	También interesa imaginar lo que el usuario puede introducir como entrada a un programa
...
 (
PRUEBAS DEL SOFTWARE
12.270
)
PRUEBAS ALEATORIAS
En las pruebas aleatorias simulamos la entrada habitual del programa creando datos de entrada en la secuencia y con la frecuencia con las que podrían aparecer en la Práctica (de manera repetitiva)
Para ello habitualmente se utilizan generadores automáticos de casos de prueba
 (
PRUEBAS DEL SOFTWARE
12.280
)
ENFOQUE PRACTICO RECOMENDADO PARA EL DISEÑO DE CASOS
Se propone un uso más apropiado de cada técnica (caja blanca y negra) para obtener un conjunto de casos útiles:
· Si la especificación contiene combinaciones de condiciones de entrada, comenzar formando sus grafos de causa-efecto (ayudan a la comprensión de dichas combinaciones)
· En todos los casos, usar el análisis de valores límites para añadir casos de prueba: elegir límites para dar valores a las causas en los casos generados asumiendo que cada causa es una clase de equivalencia
· Identificar las clases válidas y no válidas de equivalencia para la entrada y la salida, y añadir los casos no incluidos anteriormente
 (
PRUEBAS DEL SOFTWARE
12.290
)
ENFOQUE PRACTICO RECOMENDADO PARA EL DISEÑO DE CASOS
· Utilizar la técnica de conjetura de errores para añadir nuevos casos, referidos a valores especiales
· Ejecutar los casos generados hasta el momento y analizar la cobertura obtenida
· Examinar la lógica del programa para añadir los casos precisos (de caja blanca) para cumplir el criterio de cobertura elegido si los resultados de la ejecución del punto anterior indican que no se ha satisfecho el criterio de cobertura elegido
 (
PRUEBAS DEL SOFTWARE
12.300
)
Una cuestión importante es ¿por qué son necesarias las pruebas de caja blanca si comprobamos que las funciones se realizan correctamente?
 Los errores lógicos y las suposiciones incorrectas son inversamente proporcionales a la probabilidad de que se ejecute un camino del programa ( a menor probabilidad de ejecutarse un camino, mayor número de errores)
 Se suele creer que un determinado camino lógico tiene pocas posibilidades de ejecutarse cuando, de hecho, se puede ejecutar regularmente
 Los errores tipográficos son aleatorios; pueden aparecer en cualquier parte del programa (sea muy usada o no)
 La probabilidad y la importancia de un trozo de código suele ser calculada de forma muy subjetiva
No obstante las pruebas de caja blanca sólas tampoco garantizan el éxito:
if (x+y+z)/3=x then print (x,y y z son iguales) else print (x,y y z no son iguales)
Una prueba de caja blanca como esta
x=5 y=5 z=5	x=2 y=3 z=7^12
No detecta el error lógico, que si sería detectado con otro tipo de pruebas funcionales.
 (
PRUEBAS DEL SOFTWARE
12.310
)
DOCUMENTOS RELACIONADOS CON EL DISEÑO DE LAS PRUEBAS SEGUN EL ESTANDAR IEEE std. 829
 (
Especificación 
de 
diseño
de 
las 
pruebas
) (
Especificación 
de 
diseño
de 
las 
pruebas
) (
Plan 
de 
Pruebas
)Documentación
 (
...............
Especificación 
d
e 
caso 
de 
prueba
Especificación 
de 
procedimiento 
de
 
pruebas
)
EJECUCIÓN 
Informes
 (
PRUEBAS DEL SOFTWARE
12.320
)
PLAN DE PRUEBAS
Objetivo del documento
Señalar el enfoque, los recursos y el esquema de actividades
de prueba, así como	los elementos a probar, las características, las actividades de prueba, el personal responsable y los riesgos asociados
 (
PRUEBAS DEL SOFTWARE
12.330
)
PLAN DE PRUEBAS
Estructura fijada en el estándar
1. Identificador único del documento
2. Introducción y resumen de elementos y características a probar
3. Elementos software a probar
4. Características a probar
5. Características que no se probarán
6. Enfoque general de la prueba
7. Criterios de paso/fallo para cada elemento
8. Criterios de suspensión y requisitos de reanudación
9. Documentos a entregar
10. Actividades de preparación y ejecución de pruebas
11. Necesidades de entorno
12. Responsabilidades en la organización y realización de las pruebas
13. Necesidades de personal y formación
14. Esquema de tiempos
15. Riesgos asumidos por el plan y planes de contingencias
16. Aprobaciones y firmas con nombre y puesto desempeñado
 (
PRUEBAS DEL SOFTWARE
12.340
)
ESPECIFICACION DEL DISEÑO DE PRUEBAS
Objetivo del documento
Especificar los refinamientos necesarios sobre el enfoque general reflejado en el plan e identificar las características que se deben probar con este diseño de pruebas
 (
PRUEBAS DEL SOFTWARE
12.350
)
ESPECIFICACION DEL DISEÑO DE PRUEBAS
Estructura fijada en el estándar
 Identificador único para la especificación. Proporcionar también una referencia del plan asociado (si existe)
 Características a probar de los elementos software (y combinaciones de características)
 Detalles sobre el plan de pruebas del que surge este diseño, incluyendo las técnicas de prueba específica y los métodos de análisis de resultados
 Identificación de cada prueba:
identificador
casos que se van a utilizar procedimientos que se van a seguir
 Criterios de paso/fallo de la prueba (criterios para determinar si una característica o combinación de características ha pasado con éxito la prueba o no)
 (
PRUEBAS DEL SOFTWARE
12.360
)
ESPECIFICACION DE CASO DE PRUEBA
Objetivo del documento
Definir uno de los casos de prueba identificando por una especificación del diseño de las pruebas
 (
PRUEBAS DEL SOFTWARE
12.370
)
ESPECIFICACION DE CASO DE PRUEBA
Estructura fijada en el estándar
 Identificador único de la especificación
 Elementos software (por ejemplo, módulos) que se van a probar: definir dichos elementos y las características que ejercitará este caso
 Especificaciones de cada entrada requerida para ejecutar el caso (incluyendo las relaciones entre las diversas entradas; por ejemplo, la sincronización de las mismas)
 Especificaciones de todas las salidas y las características requeridas (por ejemplo, el tiempo respuesta) para los elementos que se van a probar
 Necesidades de entorno (hardware, software y otras como, por ejemplo, el personal)
 Requisitos especiales de procedimiento (o restricciones especiales en los procedimientos para ejecutar este caso).
 Dependencias entre casos (por ejemplo, listar los identificadores de los casos que se van a ejecutar antes de este caso de prueba)
 (
PRUEBAS DEL SOFTWARE
12.380
)
ESPECIFICACION DE PROCEDIMIENTO DE PRUEBA
Objetivo del documento
Especificar los pasos para la ejecución de un conjunto de casos de prueba o, más generalmente, los pasos utilizados para analizar un elemento software
con el propósito de evaluar un conjunto de características del mismo
 (
PRUEBAS DEL SOFTWARE
12.390
)
ESPECIFICACION DE PROCEDIMIENTO DE PRUEBA
Estructura fijada en el estándar
 Identificador único de la especificación y referencia a la correspondiente especificación de diseño de prueba
 Objetivo del procedimiento y lista de casos que se ejecutan con él
 Requisitos especiales para la ejecución (por ejemplo, entorno especial o personal especial)
 Pasos en el procedimiento. Además de la manera de registrar los resultados y los incidentes de la ejecución, se debe especificar:
· La secuencia necesaria de acciones para preparar la ejecución
· Acciones necesarias para empezar la ejecución
· Acciones necesarias durante la ejecución
· Cómo se realizarán 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 ejecución y acciones necesarias para el reinicio en estos puntos
· Acciones necesarias para detener ordenadamente la ejecución
· Acciones necesarias para restaurar el entorno y dejarlo en la situación existente antes de las pruebas
· Acciones necesarias para tratar los acontecimientos anómalos
 (
PRUEBAS DEL SOFTWARE
12.400
)
PROCESO DE PRUEBAS, TRAS EL DISEÑO DE CASOS, SEGUN EL ESTANDAR IEEE 1008
1. EJECUTAR
2. COMPROBAR SI TERMINÓ LA PRUEBA
3. EVALUAR RESULTADOS
3. PRUEBAS ADICIONALES
 (
PRUEBAS DEL SOFTWARE
12.410
)
DETALLES DEL PROCESO EJECUTAR
DEPURAR LAS
PRUEBAS
Si
DEFECTOS EN LAS
PRUEBAS
EJECUTAR PRUEBAS
¿ALGUN	Si FALLO?
No
COMPROBAR TERMINACIÓN
DEPURACIÓN
DEFECTOS SOFTWARE
DEL CÓDIGO
 (
PRUEBAS DEL SOFTWARE
12.420
)
DETALLES DEL PROCESO DE COMPROBACION DE LA TERMINACION DE LAS PRUEBAS
PRUEBAS
ADICIONALES	EJECUCIÓN
No	CONDICIONES	Si ANORMALES
¿Pruebas adicionales?
Criterios de compleción descritos en el plan de pruebas
TERMINACIÓN ANORMAL
No
EVALUACIÓN
TERMINACIÓN NORMAL
 (
PRUEBAS DEL SOFTWARE
12.430
)
DOCUMENTACION RELACIONADA CON LA EJECUCION DE LAS PRUEBAS SEGUN EL ESTANDAR IEEE 829
Especificación de las pruebas
Casos procedimientos
 (
EJECUCION
)
 (
In incidente
forme de
Histórico 
de pruebas
) (
Informe de incidente
Histórico 
de pruebas
) (
Se pueden distinguir históricos, incidencias y resúmenes
) (
Informe Resúmen
)Ejecución	Ejecución
 (
PRUEBAS DEL SOFTWARE
12.440
)
HISTORICO DE PRUEBAS
Objetivo
El histórico de pruebas (test log) documenta todos los hechos relevantes ocurridos durante la ejecución de las pruebas
 (
PRUEBAS DEL SOFTWARE
12.450
)
HISTORICO DE PRUEBAS
Estructura fijada en el estándar:
 Identificador
 Descripción de la prueba: elementos probados y entorno de la prueba
 Anotación de datos sobre cada hecho ocurrido (incluido el comienzo y el final de la prueba)
· Fecha y hora
· Identificador de informe de incidente
 Otras informaciones
 (
PRUEBAS DEL SOFTWARE
12.460
)
INFORME DE INCIDENTE
Objetivo:
El informe de incidente (test incident report) documenta cada incidente (por ejemplo, una interrupción en las pruebas debido a un corte de electricidad, bloqueo del teclado, etc.) ocurrido en la prueba y que requiera una posterior investigación.
 (
PRUEBAS DEL SOFTWARE
12.470
)
INFORME DE INCIDENTE
Estructura fijada en el estándar:
 Identificador
 Resumen del incidente
 Descripción de datos objetivos (fecha/hora, entradas, resultados esperados, etc)
 Impacto que tendrá sobre las pruebas
 (
PRUEBAS DEL SOFTWARE
12.480
)
INFORME RESUMEN DE PRUEBAS
Objetivo:
El informe resumen (test summary report) resume los resultados de las actividades
de prueba (las señaladas en el propio informe) y aporta una evaluación del software basada en dichos resultados
 (
PRUEBAS DEL SOFTWARE
12.490
)
INFORME RESUMEN DE LAS PRUEBAS
Estructura fijada en el estándar:
 Identificador
 Resumen de la evaluación de los elementos probados
 Variaciones del software respecto a su especificación de diseño, así como las variaciones en las pruebas
 Valoración de la extensión de la prueba (cobertura lógica, funcional, de requisitos, etc.)
 Resumen de los resultados obtenidos en las pruebas
 Evaluación de cada elemento software sometido a prueba (evaluación general del software incluyendo las limitaciones del mismo)
 Firmas y aprobaciones de quienes deban supervisar el informe
 (
PRUEBAS DEL SOFTWARE
12.500
)
RELACION ENTRE LAS PRUEBAS Y LA DEPURACION
 (
Casos 
de
prueba
)Resultados
Ejecución
Causas ignoradas
 (
Depuración
)Correcciones
Causas
Síntomas de defectos (errores)
Depuración: el proceso de analizar y corregir los defectos que se sospecha que contiene el software
 (
PRUEBAS DEL SOFTWARE
12.510
)
CONSEJOS PARA LA DEPURACION
Localización del error
· Analizar la información y pensar (analizar bien, en lugar de aplicar un enfoque aleatorio de búsqueda 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 depuración sólo como recurso secundario (no sustituir el análisis mental)
· No experimentar cambiando el programa (no sé qué está mal, así que cambiaré esto y veré lo que sucede € NO)
· Se deben atacar los errores individualmente
· Se debe fijar la atención también en los datos (no sólo en la lógica del programa)
 (
PRUEBAS DEL SOFTWARE
12.520
)
CONSEJOS PARA LA DEPURACION
Corrección del error
· Donde hay un defecto, suele haber más (lo dice la experiencia)
· Debe fijarse el defecto, no sus síntomas (no debemos enmascarar síntomas, 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 corrección debe situarnos temporalmente en la fase de diseño (hay que retocar desde el comienzo, no sólo el código)
· Cambiar el código fuente, no el código objeto
 (
PRUEBAS DEL SOFTWARE
12.530
)
ANALISIS DE ERRORES O ANALISIS CAUSAL
El objetivo del análisis causal es proporcionar información sobre la naturaleza de los defectos. Para ello es fundamental recoger para cada defecto detectado esta información:
¿Cuándo se cometió?
¿Quién lo	hizo
¿Qué se hizo mal?
¿Cómo se podría haber prevenido?
¿Por qué no se detectó antes?
¿Cómo se podría haber detectado antes?
¿Cómo se encontró el error?
Esta información no debería ser usada para evaluar al personal, sino para la formación del mismo sobre cómo prevenir los errores. También se utiliza para predecir futuros fallos software
 (
PRUEBAS DEL SOFTWARE
12.535
)
ESTRATEGIA DE APLICACIÓN DE LAS PRUEBAS
· Se analiza cómo plantear las pruebas en el Ciclo de Vida.
· La estrategia de pruebas suele seguir estas etapas
· Comenzar pruebas a nivel de módulo
· Continuar hacia la integración del sistema completo y a su instalación
· Culminar con la aceptación del producto por parte del cliente
 (
PRUEBAS DEL SOFTWARE
12.540
)
ESTRATEGIA DE APLICACIÓN DE LAS PRUEBAS
· Se comienza en la prueba de cada módulo, que normalmente la realiza el propio personal de desarrollo en su entorno
· (
Etapas típ
icas más e
n detalle
)Con el esquema del diseño del software, los módulos probados se integran para comprobar sus interfaces en el trabajo conjunto (prueba de integración)
· El software totalmente ensamblado se prueba como un conjunto para comprobar si cumple o no tanto los requisitos funcionales como los requisitos de rendimientos, seguridad, etc. (prueba funcional o de validación).
· El software ya validado se integra con el resto del sistema (por ejemplo, elementos mecánicos, interfaces electrónicas, etc.) para probar su funcionamiento conjunto (prueba del sistema)
· Por último, el producto final se pasa a la prueba de aceptación para que el usuario compruebe en su propio entorno de explotación si
lo acepta como está o no (prueba de aceptación)
 (
PRUEBAS DEL SOFTWARE
12.550
)
RELACION ENTRE PRODUCTOS DE DESARROLLO Y NIVELES DE PRUEBA
 (
Pruebas de aceptación
) (
Requisitos de usuario
)El usuario comprueba que el
 		sistema hace lo especificado en
el contrato
 (
Especificac. de
 
requisitos
Pruebas de sistema
)	 Sistema (cumplimiento de objetivos)
 (
Pruebas de integración
)Validación (desajustes entre el software y los requisitos)
 (
Diseño modular
)Agrupación de módulos
 	
Interfaces
 (
Especific. y lógica de módulo
) (
Código
) (
Pruebas de unidad
)Lógica de módulos (caja blanca) Funciones (caja negra)
Existe una correspondencia entre cada nivel de prueba y el trabajo realizado en cada etapa del desarrollo
 (
PRUEBAS DEL SOFTWARE
12.560
)
PRUEBA DE UNIDAD
Se trata de las pruebas formales que permiten declarar que un módulo está listo y terminado (no las informales que se realizan mientras se desarrollan los módulos)
Hablamos de una unidad de prueba para referirnos a uno o más módulos que cumplen las siguientes condiciones [IEEE, 1986a]:
· Todos son del mismo programa
· Al menos uno de ellos no ha sido probado
· El conjunto de módulos es el objeto de un proceso de prueba
La prueba de unidad puede abarcar desde un módulo hasta un grupo de módulos (incluso un programa completo)
Estas pruebas suelen realizarlas el propio personal de desarrollo, pero evitando que sea el propio programador del módulo
 (
PRUEBAS DEL SOFTWARE
12.570
)
PRUEBAS DE INTEGRACION
Implican una progresión ordenada de pruebas que van desde los componentes o módulos y que culminan en el sistema completo
El orden de integración elegido afecta a diversos factores, como lo siguientes:
· La forma de preparar casos
· Las herramientas necesarias
· El orden de codificar y probar los módulos
· El coste de la depuración
· El coste de preparación de casos
 (
PRUEBAS DEL SOFTWARE
12.580
)
PRUEBAS DE INTEGRACION
Tipos fundamentales de integración
 Integración incremental. Se combina el siguiente módulo que se debe probar con el conjunto de módulos que ya han sido probados
· ascendente. Se comienza por los módulos hoja. descendente. Se comienza por el módulo raíz.
Integración no incremental. Se prueba cada módulo por separado y luego se integran todos de una vez y se prueba el programa completo
Habitualmente las pruebas de unidad y de integración se solapan y mezclan en el tiempo.
 (
PRUEBAS DEL SOFTWARE
12.580
)
INTEGRACIÓN INCREMENTAL ASCENDENTE
El proceso es el siguiente
· Se combinan los módulos de bajo nivel en grupos que realicen una función o subfunción específica (o quizás si no es necesario, individualmente) € de este modo reducimos el número de pasos de integración.
· Se escribe para cada grupo un módulo impulsor o conductor € de este modo permitimos simular la llamada a los módulos, introducir datos de prueba y recoger resultados.
· Se prueba cada grupo mediante su impulsor
· Se eliminan los módulos impulsores y se sustituyen por los módulos de nivel superior en la jerarquía.
 (
B
) (
D
C
) (
G
) (
F
) (
E
) (
PRUEBAS DEL SOFTWARE
12.590
)
DISEÑO MODULAR SOBRE EL QUE SE REALIZA LA INTEGRACION
Supongamos esta estructura de programa
 (
A
)
 (
PRUEBAS DEL SOFTWARE
12.600
)
PRIMERA FASE DE LA INTEGRACION ASCENDENTE DEL EJEMPLO
1ª fase
Se definen los impulsores para nodos hoja y se ejecutan
 (
Impulsor de E
)	 (
Impulsor de F
)	 (
Impulsor de G
)	 (
Impulsor de D
)
 (
G
) (
F
) (
E
)D
Pruebas de Unidad
 (
PRUEBAS DEL SOFTWARE
12.610
)
SEGUNDA Y TERCERA FASE DE LA INTEGRACION ASCENDENTE DEL EJEMPLO
 (
B
) (
D
C
)2ª fase	3ª fase
 (
Impulsor de E
) (
Impulsor de F
) (
A
)
	
 (
B
)	 (
C
)
 (
G
) (
F
) (
E
) (
G
) (
F
) (
E
)Prueba de unidad de E
Prueba de integración de B con E
 (
PRUEBAS DEL SOFTWARE
12.615
)
INTEGRACIÓN INCREMENTAL DESCENDENTE
Comienza por el módulo de control principal y va incorporando módulos subordinados progresivamente.
No hay un orden adecuado de integración, pero unos consejos son los siguientes:
-Si hay secciones críticas (especialmente complejas) se deben integrar lo antes posible.
-El orden de integración debe incorporar cuanto antes los módulos de entrada/salida para facilitar la ejecución de puebas
Existen dos formas básicas de hacer esta integración:
-Primero en profundidad: Se van completando ramas del árbol (A B E C F G D)
-Primero en anchura: Se van completando niveles de jerarquía (A B C D E F G)
 (
PRUEBAS DEL SOFTWARE
12.620
)
ETAPAS FUNDAMENTALES	DE LA INTEGRACION DESCENDENTE
 El módulo raíz es el primero: Se escriben módulos ficticios que simulan los subordinados
 Una vez probado el módulo raíz (sin detectarse ya ningún defecto), se sustituye uno de los subordinados ficticios por el módulo correspondiente según el orden elegido
 Se ejecutan las correspondientes pruebas cada vez que se incorpora un módulo nuevo
 Al terminar cada prueba, se sustituye un ficticio por su correspondiente real
 Conviene repetir algunos casos de prueba de ejecuciones anteriores para asegurarse de que no se ha introducido ningún defecto nuevo
 (
PRUEBAS DEL SOFTWARE
12.630
)
MÓDULOS FICTICIOS
La creación de módulos ficticios subordinados es más complicada que la creación de impulsores
-Complejidad
+Complejidad
Módulos que sólo muestran un mensaje de traza
Módulos que muestran los parámetros que se les pasa
Módulos que devuelven un valor que no depende de los parámetros que se pasen como entrada
Módulos que, en función de los parámetros pasados, devuelven un valor de salida que más o menos se corresponda con dicha entrada
 (
PRUEBAS DEL SOFTWARE
12.640
)
UNA POSIBLE CLASIFICACION	DE LOS MODULOS FICTICIOS
 (
Tipo 1
)	 (
Tipo 2
)	 (
Tipo 3
)	 (
Tipo 4
)
Muestra		Muestra	Devuelve		Recibe y mensaje	param. de entrada		valor	devuelve valor
 (
PRUEBAS DEL SOFTWARE
12.650
)
 (
B
) (
Ficticio D
Ficticio C
)UN PASO INTERMEDIO EN LA INTEGRACION DESCENDENTE PRIMERO EN LA PROFUNDIDAD DEL EJEMPLO
 (
A
)
 (
E
)Recordar el recorrido de árboles en profundidad
 (
PRUEBAS DEL SOFTWARE
12.660
)
UN PASO INTERMEDIO EN LA INTEGRACION DESCENDENTE PRIMERO EN LA ANCHURA DEL EJEMPLO
 (
A
)
 (
B
) (
C
) (
ficticio D
)
 (
Ficticio E
)Recordar el recorrido de árboles en anchura
 (
PRUEBAS DEL SOFTWARE
12.670
)
INTEGRACION NO INCREMENTAL
Cada módulo que tiene que ser probado necesita lo siguiente:
 Un módulo impulsor, que transmite o «impulsa» los datos de prueba al módulo y muestra los resultados de dichos casos de prueba
Uno o más módulos ficticios que simulan la función de cada módulo subordinado llamado por el módulo que se va a probar
Una vez probado cada módulo por separado, se ensamblan todos de una vez y se prueban en conjunto
 (
ficticio 1
) (
Módulo que se va a probar
) (
PRUEBAS DEL SOFTWARE
12.680
)
 (
Casos de prueba
) (
Resultados
) (
Impulsor
)PRUEBA TIPICA DEL MODULO EN LA INTEGRACION NO INCREMENTAL
 (
ficticio 3
ficticio 2
)
 (
PRUEBAS DEL SOFTWARE
12.690
)
COMPARACION DE LOS DISTINTOS TIPOS DE INTEGRACION
Ventajas de la no incremental:
· Requiere menos tiempo de máquina para las pruebas, ya que se prueba de una sola vez la combinación de los módulos
· Existen más oportunidades de probar módulos en paralelo
Ventajas de la incremental:
· Requiere menos trabajo, ya que se escriben menos módulos impulsores y ficticios
· Los defectos y errores en las interfaces se detectan antes, ya que se empieza antes a probar las uniones entre los módulos
· La depuración es mucho más fácil, ya que si se detectan los síntomas de un defecto en un paso de la integración hay que atribuirlo muy probablemente al último módulo incorporado
· Se examina con mayor detalle el programa, al ir comprobando cada interfaz poco a poco
 (
PRUEBAS DEL SOFTWARE
12.700
)
 (
Ascendente
Descendente
Ventajas
Es un método ventajoso si aparecen grandes fallos en la parte inferior del programa, ya que se prueba
 
antes.
La entradas para las pruebas son
 
más
fáciles de
crear, puesto que los módulos inferiores tienen funciones más específicas.
Es más fácil observar los resultados
 
de
la prueba, ya que es en los módulos inferiores donde se elaboran los datos
(los superiores suelen ser módulos de control).
Ventajas
Es ventajosa si aparecen grandes defectos en los niveles superiores del programa, ya que se prueban
 
antes.
Una vez incorporadas las funciones de entrada/salida, es fácil manejar los casos de
 
prueba.
Permite ver antes una estructura previa del programa, lo que facilita el
 
hacer
demostraciones y ayuda a mantener la moral.
Desventajas
Se requieren módulos impulsores, que deben
 
codificarse.
El programa, como entidad, sólo aparece cuando se agrega el último módulo.
Desventajas
Se requieren módulos ficticios que suelen ser complejos de
 
crear.
Antes de incorporar la entrada/salida resulta complicado el manejo de los casos de
 
prueba.
Las entradas para las pruebas pueden ser difíciles o imposibles de crear, puesto que, a menudo, se carece de los módulos inferiores que proporcionan los detalles de
 
operación.
Es más difícil observar la salida, ya que los resultados surgen de los módulos
 
inferiores.
Pueden inducir a diferir la terminación de la prueba de ciertos
 
módulos.
)VENTAJAS Y DESVENTAJAS DE	LAS INTEGRACIONES ASCENDENTE Y DESCENDENTE
 (
PRUEBAS DEL SOFTWARE
12.710
)
PRUEBA DEL 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
· Adecuación de la documentación de usuario
· Ejecución y rendimiento en condiciones límite y de sobrecarga
 (
PRUEBAS DEL SOFTWARE
12.720
)
FUENTES DE DISEÑO DE CASOS DE PRUEBA DEL SISTEMA
· Casos basados en los requisitos gracias a técnicas de caja negra aplicadas a las especificaciones
· 	Casos necesarios para probar el rendimiento del sistema y de su capacidad funcional (pruebas de volumen de datos, de límites de procesamiento, etc.). Este tipo de pruebas suelen llamarse pruebas de sobrecarga (stress testing)
· Casos basados en el diseño de alto nivel aplicando técnicas de caja blanca a los flujos de datos de alto nivel (por ejemplo, de los diagramas de flujo de datos)
 (
PRUEBAS DEL SOFTWARE
12.730
)
PRUEBA DE ACEPTACION
Es la prueba planificada y organizada formalmente para determinar si se cumplen los requisitos de aceptación marcados por el cliente.
Sus características principales son las siguientes:
Participación 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 explotación
 (
PRUEBAS DEL SOFTWARE
12.740
)
RECOMENDACIONES GENERALES
 Debe contarse con criterios de aceptación previamente aprobados por el usuario
 No hay que olvidar validar también la documentación y los procedimientos de uso (por ejemplo,mediante una auditoría)
 Las pruebas se deben realizar en el entorno en el que se utilizará el sistema (lo que incluye al personal que lo maneja)
PRUEBAS
TIPOS DE PRUEBAS DE SOFTWARE
1
PRUEBAS Y DEPURACIÓN
· LA FASE DE PRUEBA SE REALIZA UNA VEZ INTEGRADO CADA UNO DE
LOS MÓDULOS DEL SISTEMA.
· LA FASE DE PRUEBAS SE REALIZA DE DISTINTAS FORMAS TRATANDO DE ENCONTRAR LA MAYORÍA DE LOS ERRORES QUE SE ENCUENTRAN DE MANERA INHERENTE EN EL SOFTWARE.
DEPURACIÓN
· UNA VEZ IDENTIFICADO LOS ERRORES EN LA FASE DE PRUEBAS, SE
PROCEDE A CORREGIRLOS. A ESTA FASE SE LE LLAMA DEPURACIÓN.
· EN LA FASE DE DEPURACIÓN TAMBIÉN SE ARREGLAN DETALLES SUPERFICIALES DEL SOFTWARE ADEMÁS DE OPTIMIZAR Y MEJORAR ALGUNOS PROCESOS.
DEPURACIÓN
· ES LA DETECCIÓN, CORRECCIÓN Y ELIMINACIÓN DE ERRORES DE
SOFTWARE.
· EL TENER UN PLAN DE PRUEBAS AYUDA A CLARIFICAR EL PROCESO DE
DEPURACIÓN.
· EL PLAN DE PRUEBAS DEBE DE ESTAR MUCHO ANTES DE LA CONSTRUCCIÓN DEL SOFTWARE.
CICLO DE PRUEBAS DE SOFTWARE
5
DEPURACIÓN
· EXISTEN MUCHOS TIPOS DE PRUEBAS DEPENDIENDO DE LA
LABOR Y CARACTERÍSTICAS DE CADA UNA DE ELLAS.
· PRUEBAS ALFA: SE REALIZAN POR EL USUARIO FINAL EN UN
AMBIENTE CONTROLADO.
· PRUEBAS BETA: SE REALIZAN POR EL USUARIO SIN CONTROLAR
EL AMBIENTE.
DEPURACIÓN
· A CONTINUACIÓN SE MENCIONAN ALGUNAS CARACTERÍSTICAS
DESEABLES QUE DEBEN CONTENER LOS PLANES DE PRUEBA:
· DISEÑAR UN CASO DE PRUEBA PARA CADA FUNCIONALIDAD DEL
SOFTWARE.
· ESTABLECER COMO MÍNIMO UN CASO DE PRUEBA DE DATOS CORRECTO.
DEPURACIÓN
· ESTABLECER COMO MÍNIMO UN CASO DE PRUEBA DE DATOS
INCORRECTO.
· EJEMPLO: CASO DE PRUEBA DE UN MÓDULO DE RAÍZ CUADRADA.
· QUÉ EL USUARIO INGRESE UN NÚMERO MAYOR QUE 0.
DEPURACIÓN
· QUÉ EL USUARIO INGRESE UN NÚMERO 0
· QUÉ EL USUARIO INGRESE UN NÚMERO MENOR QUE 0.
· TODA ACTIVIDAD DE CONSTRUCCIÓN (CODIFICACIÓN) ES SUSCEPTIBLE DE COMETER ERRORES DADO QUE SE TRATA DE UNA ACTIVIDAD HUMANA.
DEPURACIÓN
· AL REALIZAR LA DEPURACIÓN DE UN PROGRAMA EXISTE LA
POSIBILIDAD DE UN 50% DE COMETER OTRO ERROR.
· ES RECOMENDABLE REALIZAR PRUEBAS DE TRAZADO (ASSERT) PARA
VISUALIZAR EN DONDE OCURREN LOS ERRORES.
DEPURACIÓN
· SE RECOMIENDA PROBAR LO ANTES POSIBLE CUALQUIER
FRAGMENTO DE CÓDIGO.
· LAS PRUEBAS AYUDAN AL ASEGURAMIENTO DE CALIDAD PERO NO
GARANTIZAN QUE UN SOFTWARE ESTÉ 100% LIBRE DE ERRORES.
DEPURACIÓN
· LAS PRUEBAS DE CAJA BLANCA TAMBIÉN LLAMADAS TRANSPARENTES
SE CONCENTRAN EN LO QUE ES EL CÓDIGO FUENTE.
· NO SE PUEDEN TENER PRUEBAS QUE ABARQUEN EL 100% DE LOS
CASOS DE USO. SE DEBEN REALIZAR PRUEBAS DE SEGMENTOS
DEPURACIÓN
· LAS PRUEBAS DE SEGMENTOS SON BLOQUES DE INSTRUCCIONES.
· LAS PRUEBAS DE CAJA NEGRA ESTÁN ORIENTADAS A LO QUE SE
ESPERA REALICEN LOS COMPONENTES MODULARES DEL SISTEMA.
DEPURACIÓN
· SON PRUEBAS FUNCIONALES Y NO INTERESA COMO SE REALIZAN
LAS COSAS SÓLO QUE EL RESULTADO OBTENIDO SEA EL CORRECTO.
· SE RECOMIENDA QUE SEAN LOS USUARIOS QUIENES LAS REALICEN.
· EXISTEN DIVERSAS FILOSOFÍAS DE PRUEBAS COMO LA PROGRAMACIÓN DEFENSIVA.
DEPURACIÓN
· LA PROGRAMACIÓN DEFENSIVA ES UNA TÉCNICA DE PROBAR PRIMERO. ES CONSIDERADA UNA TÉCNICA DE CODIFICACIÓN. SE BASA EN EL PRINCIPIO DE DIVIDE Y VENCERÁS.
· SE CODIFICA EL ESQUELETO DE LA APLICACIÓN.
· SE REALIZAN PRUEBAS.
DEPURACIÓN
· SE CORRIGEN LOS ERRORES Y SE VUELVEN A HACER PRUEBAS.
· LAS PRUEBAS DE ESTRÉS SE ENCARGAN DE OBSERVAR EL RENDIMIENTO DE LA APLICACIÓN SOBRE CARGAS DEMANDANTES DE TRABAJO: GRANDES VOLÚMENES DE DATOS CON POCO ESPACIO EN DISCO, 90% DE USO DE CPU, MÚLTIPLES CONEXIONES, ETC.
DEPURACIÓN
· EXISTEN OTROS TIPOS DE PRUEBA COMO:
· PRUEBAS DE UNIDAD: SE ENCARGAN DE UN MÓDULO DE SOFTWARE EN PARTICULAR.
· PRUEBAS DE INTEGRACIÓN: SON PRUEBAS QUE SE REALIZAN CON DOS O MÁS MÓDULOS TRABAJANDO EN CONJUNTO.
DEPURACIÓN
· EXISTEN OTRO TIPOS DE PRUEBA COMO LAS DE ACEPTACIÓN QUE ESTÁN MÁS INVOLUCRADAS EN EL CONCEPTO EN SÍ QUE EN EL DESARROLLO.
· TAMBIÉN SE PUEDEN APLICAR PRUEBAS ALEATORIAS. LO IDEAL ES PODER UTILIZAR UN FRAMEWORK DE PRUEBAS.
DEPURACIÓN
· LA MAYORÍA DE LOS IDES MODERNOS PRESENTAN FRAMEWORKS PARA LA DEPURACIÓN DESDE EL CLÁSICO STEP BY STEP O STEP OVER SOBRE CADA UNO DE LOS MÓDULOS HASTA LA REALIZACIÓN DE PRUEBAS DE UNIDAD.
· ENTRE LAS MÁS FAMOSAS DESTACAN JUNIT PARA REALIZAR PRUEBAS DE UNIDAD EN JAVA.
GUÍA PARA LA PRUEBA DE PROGRAMAS
· SE NECESITA ESPECIFICAR LAS SALIDAS O RESULTADOS ESPERADOS.
· UN PROGRAMADOR DEBE DE EVITAR PROBAR SUS PROPIOS
PROGRAMAS.
· UNA ORGANIZACIÓN NO DEBE DE PROBAR SUS PROPIOS PROGRAMAS.
20
GUÍA PARA LA PRUEBA DE PROGRAMAS
· INSPECCIONAR LOS RESULTADOS OBTENIDOS DE CADA PRUEBA.
· LOS CASOS DE PRUEBA DEBEN ESCRIBIRSE CON CONDICIONES DE ENTRADA QUE SON INVÁLIDAS E INESPERADAS, ASÍ COMO TAMBIÉN AQUELLAS QUE SON VÁLIDAS Y ESPERADAS.
21
GUÍA PARA LA PRUEBA DE PROGRAMAS
· EXAMINAR UN PROGRAMA PARA
VERIFICAR QUE HACE LO QUE DEBA DE HACER ES SÓLO PARTE DE LA PRUEBA, LA OTRA MITAD ES ASEGURARSE QUE EL PROGRAMA NO HAGA LO QUE NO DEBA DE HACER.
· NO REALIZAR PLANEACIONES ASUMIENDO QUE NO SE ENCONTRARÁN ERRORES.
22
GUÍA PARA LA PRUEBA DE PROGRAMAS
· LA PROBABILIDAD DE LA EXISTENCIA DE MAS ERRORES EN UNA SECCIÓN DE UN PROGRAMA ES PROPORCIONAL AL NÚMERO DE ERRORES ENCONTRADOS EN ESA SECCIÓN.
· LA REALIZACIÓN DE PRUEBAS ES UNA ACTIVIDAD EXTREMADAMENTE CREATIVA E INTELECTUALMENTE RETADORA.
23
GUÍA PARA LA PRUEBA DE PROGRAMAS
· SE DEBE DE REALIZAR UNA LISTA DE VERIFICACIÓN PARA INSPECCIONES DE PRUEBA QUE CONTENGA LOS SIGUIENTES PUNTOS:
· DATOS
· DECLARACIÓN DE DATOS
· ERRORES COMPUTACIONALES
· ERRORES DE COMPARACIÓN
24
GUÍA PARA LA PRUEBA DE PROGRAMAS
· ERRORES DE CONTROL DE FLUJO
· ERRORES DE INTERFACE
· ERRORES DE ENTRADA/SALIDA
· SE PUEDEN UTILIZAR MÉTODOS DEDUCTIVOS E INDUCTIVOS PARA LA PRUEBA DE SOFTWARE.
25
DEPURACIÓN POR INDUCCIÓN
SE SIGUEN LOS SIGUIENTES PASOS:
· LOCALIZAR LOS DATOS PERTINENTES
· ORGANIZAR LOS DATOS
· ESTUDIAR LAS RELACIONES
· DIVISAR LAS HIPÓTESIS
· PROBAR LAS HIPÓTESIS
· CORREGIR EL ERROR
26
DEPURACIÓN POR DEDUCCIÓN
· ENUMERAR LAS POSIBLES CAUSAS
· USAR PROCEDIMIENTOS DE ELIMINACIÓN
· REFINAR LAS HIPÓTESIS RESTANTES
· PROBAR LAS HIPÓTESIS RESTANTES
· SI NO SE PUEDEN PROBAR LAS HIPÓTESIS ENTONCES COLECCIONAR MÁS DATOS Y REPETIR EL PROCESO
· EN CASO CONTRARIO CORREGIR EL ERROR
27
XP EXTREME PROGRAMMING
· SE TIENEN DOCE PRINCIPIOS BÁSICOS:
· PLANEACIÓN Y REQUERIMIENTOS
· ENTREGAS PEQUEÑAS E INCREMENTALES
· METÁFORAS DE SISTEMAS
· DISEÑOS SIMPLES
· PRUEBAS CONTINUAS
· REFACTORIZACIÓN
28
XP EXTREME PROGRAMMING
· PROGRAMACIÓN EN PARES
· PROPIEDAD COLECTIVA DEL CÓDIGO
· INTEGRACIÓN CONTINUA
· SEMANAS DE 40 HORAS
· CLIENTES COMO MIEMBROS DEL EQUIPO
· CODIFICAR CON ESTÁNDARES
29
EXTREME TESTING
· LAS PROGRAMACIÓN EXTREMA TIENEN LAS SIGUIENTES VENTAJAS EN
LO QUE RESPECTA AL PROCESO DE PRUEBAS:
· SE GANA CONFIANZA YA QUE EL CÓDIGO DEBE CUMPLIR LAS
ESPECIFICACIONES.
· SE TIENE EL RESULTADO FINAL DEL CÓDIGO ANTES DE CODIFICAR
30
EXTREME TESTING
· SE ENTIENDE MUCHO MEJOR LAS ESPECIFICACIONES Y
REQUERIMIENTOS DE LA APLICACIÓN.
· SE INICIA CON DISEÑOS SIMPLES Y SE REFACTORIZA EL CÓDIGO DESPUÉS PARA MEJORAR EL DESEMPEÑO SIN PREOCUPARSE DE QUE SE ESTÉN ROMPIENDO LAS ESPECIFICACIONES.
31
PLAN DE PRUEBAS
· SE RECOMIENDA UTILIZAR LA METODOLOGÍA Y FORMATOS DEL ESTÁNDAR
IEEE 829 PARA DOCUMENTACIÓN DE PRUEBAS DE SOFTWARE:
· PASOS QUE INCLUYE:
· IDENTIFICADOR DE PLAN DE PRUEBAS (SE MUESTRA EL ESTÁNDAR A SEGUIR PARA EL NOMBRE DE LAS PRUEBAS)
32
PLAN DE PRUEBAS
· INTRODUCCIÓN (EN QUE CONSISTE LAS PRUEBAS DEL SISTEMA)
· ELEMENTOS A PROBAR
· CARACTERÍSTICAS A SER PROBADAS
· CARACTERÍSTICAS QUE NO SE PROBARÁN
· ENFOQUE
· CRITERIO DE FALLO O ACEPTACIÓN DE LOS ELEMENTOS
33
PLAN DE PRUEBAS
· CRITERIO DE SUSPENSIÓN Y REANUDACIÓN DE REQUERIMIENTOS
· ENTREGABLES DE LAS PRUEBAS
· TAREAS DE LAS PRUEBAS
· NECESIDADES DEL ENTORNO
· RESPONSABILIDADES
· EQUIPO Y NECESIDADES DE CAPACITACIÓN
· AGENDA
34
PLAN DE PRUEBAS
· RIESGOS Y CONTINGENCIAS
· ACUERDOS
· A LAS PRUEBAS SE LES HA EMPEZADO A LLAMAR DE MANERA FORMAL
VERIFICACIÓN Y VALIDACIÓN.
· EXISTEN METODOLOGÍAS MÁS ROBUSTAS COMO EL TMMI (TEST
MATURITY MODEL)
35
 (
36
)PLAN DE PRUEBAS
 (
37
)EJEMPLO
REFERENCIAS
· MYERS, ET AL. (2004), “THE ART OF SOFTWARE TESTING”, WILEY,
ESTADOS UNIDOS, 2004, ISBN: 0-471-46912-2
38
¿PREGUNTAS, DUDAS Y COMENTARIOS?
39
RESUMEN
40
PRUEBAS GENERALES DE SOFTWARE
	Prueba Unitaria
· Ejecutar cada módulo
· Particionar, definir los casos de prueba.
· Comparar el resultado
	Prueba de Regresión
· Identificar errores introducidos por la combinación de programas probados unitariamente.
· Determina cómo la base de datos de prueba
será cargada
· Utilizar la técnica down-top.
	Pruebas de Humo
· Detectar los errores en realeases tempranos y de manera fácil
· su objetivo es probar el sistema constantemente
buscando que saque “humo”
· Realizar una integración de todo el sistema cada cierto periodo (se recomienda un día, máximo una semana)
	Pruebas del Sistema
· Asegurar la apropiada navegación dentro del sistema, ingreso de datos, procesamiento y recuperación.
· deben enfocarse en requisitos que puedan ser
tomados directamente de casos de uso y reglas y funciones de negocios
· Ejecute cada caso de uso, flujo básico o función
utilizando datos válidos e inválidos
PRUEBAS GENERALES DE SOFTWARE
	Pruebas de Stress
· Verificar que el sistema funciona apropiadamente y sin errores
· Las	pruebas	de	stress	se	proponen	encontrar
errores debidos a recursos bajos o completitud de recursos
· Use	los	scripts	utilizados	en	las	pruebas	de
desempeño
	Pruebas de desempeño
· Validar	el	tiempo	de	respuesta	para	las transacciones
· Miden	tiempos	de	respuesta,	índices	de
procesamiento de transacciones y otros requisitos sensibles al tiempo
· Modifique archivos de datos (para incrementar el
número de transacciones) o los scripts para incrementar el número de veces que ocurre cada transacción
	Pruebas de carga
· Validar	el	tiempo	de	respuesta	para	las transacciones
· Miden	tiempos	de	respuesta,	índices	de
procesamiento de transacciones y otros requisitos sensibles al tiempo
· Modifique archivos de datos (para incrementar el
número de transacciones) o los scripts para incrementar el número de veces que ocurre cada transacción
	Pruebas de volumen
· Verificar el tamaño de la BD, el equipo si es suficiente etc.
· Las	pruebas	de	volumen	hacen	referencia	a
grandes cantidades de datos para determinar los límites en que se causa que el Sistema falle
· Deben usarse múltiples clientes, ya sea corriendo
las mismas pruebas o pruebas complementarias para producir el peor caso de volumen
PRUEBAS GENERALES DE SOFTWARE
	Pruebas de Recuperación y Tolerancia a fallas
· Verificar que los procesos de recuperación (manual o automática) restauran apropiadamente la Base de datos
· Estas pruebas aseguran que una aplicación o
sistema se recupere de una variedad de anomalías de hardware, software o red con pérdidas de datos o fallas de integridad.
· Se deben utilizar las pruebas creadas para la
Funcionalidad del sistema y Procesos de Negocios
para crear una serie de transacciones
	Prueba de Múltiples Sitios
· Detectar fallas en configuraciones y comunicaciones de datos entre múltiples sitios
· El propósito de esta prueba es evaluar el correcto
funcionamiento	del	sistema	o	subsistema	en múltiples instalaciones.
· Consistencia, empaquetamiento, sincronización
	Prueba de Compatibilidad y Conversión
· Buscar problemas de compatibilidad y conversión en los sistemas
· El propósito es demostrar que los objetivos de
compatibilidad no han sido logrados y que los procedimientos de conversión no funcionan.
· Compatibilidad entre programas y Conversión de
datos
	Pruebas de Integridad de Datos y Base de Datos
· Asegurar que los métodos de acceso y procesos funcionan adecuadamente y sin ocasionar corrupción de datos.
· La Base de datos y los procesos de Base de datos
deben ser probados como sistemas separados del proyecto
· Invoque cada método de acceso y proceso de la
Base de datos, utilizando en cada uno datos válidos e inválidos. Analizar la BD.
PRUEBAS GENERALES DE SOFTWARE
	Pruebas de Seguridad y Control de Acceso
· Nivel de seguridad de la aplicación: Verifica que un actor solo pueda acceder a las funciones y datos que su usuario tiene permitido
· Seguridad del sistema, incluyendo acceso a datos o
Funciones de negocios e incluyendo accesos remotos
· Funciones / Seguridad de Datos: Identificar cada tipo de usuario y las funciones y datos a los que se debe autorizar.
	Pruebas del Ciclo del Negocio
· Asegurar que el sistema funciona de acuerdo con el modelo de negocios emulando todos los eventos en el tiempo y
en función del tiempo.
· Deberían emular las actividades ejecutadas en el a
través del tiempo. Debería identificarse un periodo, como por ejemplo un año, y las transacciones y actividades que podrían ocurrir durante un periodo
· Ejecute cada caso de uso, flujo básico o función
utilizando datos válidos e inválidos…
	Pruebas de GUI
· La navegación, Los objetos de la ventana y características, tales como menús, medidas, posiciones, estados y focos
· La prueba de interfaz de usuario verifica la
interacción del usuario con el software
· Pruebas de crear / modificar cada ventana para verificar la adecuada navegación y estado de los objetos.
	Pruebas de Configuración
· Validar y verificar que el cliente del sistema funciona apropiadamente en las estaciones de trabajo recomendadas.
· Estas pruebas verifican la operación del sistema en
diferentes configuraciones de hardware y software
· Incluya la apertura o cierre de varias aplicaciones Microsoft, como Excel y Word (o algún tipo de software similar a la que se está probando)
PRUEBAS GENERALES DE SOFTWARE
	Prueba de Estilo
· Comprobar que la aplicación sigue los estándares de estilo propios del cliente.
· Se entienden como tales el formato de las ventanas,
colores corporativos, tipos de letra etc.
· Se realiza una navegación por la aplicación verificando si se cumplen con los estándares de GUI del cliente.
	Prueba de Aceptación
· Determinación	por	parte	del	cliente	de	la aceptación o rechazo del sistema desarrollado.
· La prueba de aceptación es ejecutada antes de
que la aplicación sea instalada dentro de un ambiente de producción
· Realización de los documentos de planes de
prueba de aceptación y especificación de los mismos, basados en los criterios de aceptación del cliente.
	Prueba de Instalación
· Verificar y validar que el sistema se instala apropiadamente en cada cliente, bajo las siguientes condiciones: Instalaciones nuevas y actualizaciones
· El primero es asegurar que el sistema puede ser
instalado en todas las configuraciones posibles .El segundo propósito verificar que, una vez instalado, el sistema opera correctamente.
· Diseñar scripts para validar las condiciones de la
máquina a instalar.
	Prueba de Documentación y Procedimiento
· Evaluar la documentación del usuario
· Evaluar la exactitud y claridad de la documentación del usuario y para determinar si el manual de procedimientos trabajará correctamente como una parte integral del sistema.
· Revisar la documentación del proyecto contra las
funcionalidades del sistema y su configuración física.
PRUEBAS GENERALES DE SOFTWARE
	Pruebas Funcionales
· Se asegura la trabajo apropiado de los requisitos funcionales, incluyendo la navegación, entrada de datos, procesamiento y obtención de resultados
· Las pruebas Funcionales deben enfocarse en los
requisitos funcionales Diseñar scripts para validar las condiciones de la máquina a instalar
· Que los resultados esperados ocurran cuando se
usen datos válidos.
	Prueba de Usabilidad
· Determinar la usabilidad del sistema.
· Determina cuán bien el usuario podrá usar y entender la aplicación. Identifica las áreas de diseño que hacen al sistema de difícil uso para el usuario.
· Verificar que la aplicación no presenta los
siguientes problemas de usabilidad típicos: sistema es demasiado complejo , recuperación de errores es pobre , procedimientos no son simples ni obvios
	Prueba de Campo
· Correr el sistema en el ambiente real para encontrar errores y validar el producto contra sus especificaciones originales.
· Realizar un subconjunto válido de pruebas de
sistema.
· Determinar que pruebas de sistema serán corridas para validar el sistema en producción.
	Pruebas Alfa
· Prueba de aceptación para detectar errores en el
sistema bajo un ambiente controlado.
· La verificación involucra la ejecución de partes o todo del sistema en ambientes simulados, con el fin de encontrar errores.
· Se llevan a cabo en el lugar en donde fue
desarrollado el sistema
PRUEBAS GENERALES DE SOFTWARE
	Pruebas Beta
· Realizar la validación del sistema por parte del usuario.
· Prueba de aceptación donde La validación (o
pruebas beta) involucra el uso del software en un ambiente real.
· Se selecciona un grupo de usuarios que ponen a
trabajar el sistema en un ambiente real. Usan el sistema en sus actividades cotidianas, procesan transacciones y producen salidas normales del sistema
	
Métodos de desarrollo para web
Pruebas para aplicaciones web
CAJAS NEGRAS Y BLANCAS
CAJA NEGRA
AQUEL ELEMENTO QUE ES ESTUDIADO DESDE EL PUNTO DE VISTA DE LAS ENTRADAS QUE RECIBE Y LAS SALIDAS O RESPUESTAS QUE PRODUCE, SIN TENER EN CUENTA SU FUNCIONAMIENTO INTERNO.
CAJAS BLANCAS
TIPO DE PRUEBAS DE SOFTWARE QUE SE REALIZA SOBRE LAS FUNCIONES INTERNAS DE UN MÓDULO. ASÍ COMO LAS PRUEBAS DE CAJA NEGRA EJERCITAN	LOS	REQUISITOS FUNCIONALES DESDE EL EXTERIOR DEL MÓDULO, LAS DE CAJA BLANCA ESTÁN DIRIGIDAS A LAS FUNCIONES INTERNAS.
FRASE
"TENEMOS QUE CAMBIAR LA TRADICIONAL ACTITUD ANTE LA CONSTRUCCIÓN DE SOFTWARE. EN VEZ DE PENSAR QUE NUESTRA PRINCIPAL TAREA ES INDICAR A UN ORDENADOR QUÉ HACER, CONCENTRÉMONOS EN EXPLICAR A LAS PERSONAS LO QUE QUEREMOS QUE EL ORDENADOR HAGA“
DONALD E. KNUTH
Tema 3. Requerimiento del software y procesos de requerimientos
Entender los requisitos de un software y relacionarlo con partes de las especificaciones
Procesos de Ingeniería de Requerimientos
La meta del proceso de ingeniería de requerimientos es crear y mantener un documento de requerimientos del sistema.
Proceso de Ingeniería de Requerimientos
Estudio de factibilidad
· Informe de factibilidad
Obtención y análisis de requerimientos
· Modelos del Sistema
Especificación de requerimientos
· Requerimientos del usuario del sistema
Validación de
requerimientos
· Documento de requerimientos
 (
Estudios de factibilidad
)
 (
Para todos los sistemas nuevos, el proceso de ingeniería de requerimientos debería empezar con un 
estudio de factibilidad
.
)
 (
Un estudio de factibilidad es un estudio corto y orientado a resolver cuestiones:
)
· ¿Contribuye el sistema a los objetivos generales de la organización?
· Se puede implementar el sistema utilizando la tecnología actual y dentro de las restricciones de coste y tiempo?
· Puede integrarse el sistema con otros sistemas existentes en la organización?
· Para evitar desarrollar proyectos que no son
factibles en relación a los recursos disponibles.
· Para planear los recursos.
· Lograr el conocimiento general del problema y la estructura de los requerimientos de información, con el fin de estimar los recursos necesarios.
· Para “aterrizar” al personal administrativo de sistemas, usuarios, auditores, etc. respecto a las expectativas reales del sistema.
Para qué sirve el estudio de factibilidad ?
 (
¿Quiénes participan en el análisis?
) (
Los usuarios: proporcionan los requerimientos del sistema.
) (
Los analistas,
 
programadores, 
jefes 
de 
proyecto, 
director de sistemas.
) (
Personal de auditoría: asegura los controles y seguridad del sistema.
)
Factibilidad operacional.
Comprende una determinación de posibilidad que un nuevo sistema se use como se supone. Se deben considerar cuatro aspectos:
· La utilización de un nuevo sistema puede ser demasiado complejo para los usuarios de la organización o los operadores del sistema.
· Este nuevo sistema puede hacer que los usuarios se resistan a él como consecuencia de una técnica de trabajo, miedo a ser desplazado u otras razones.
· Un sistema nuevo puede introducir cambios demasiado rápidos que no permita al personal adaptarse a él y aceptarlo.
· La probabilidad de obsolescencia en el sistema. Cambios anticipados en la práctica o políticas administrativas pueden hacerse que un nuevo sistema sea obsoleto muy pronto.
 (
nuevos.
) (
Factibilidad Técnica
)Permite evaluar si el equipo y software están disponibles y tienen las capacidades técnicas requeridas por cada alternativa del diseño que se esté planificando,
también se consideran las interfases entre los sistemas actuales y los
Así mismo, estos estudios consideran si las organizaciones tienen el personal que posee la experiencia técnica requerida para diseñar, implementar, operar y mantener el sistema propuesto.
Factibilidad económica
Dentro de estos estudios se pueden incluir el análisis de costo y beneficios asociados con cada alternativa del proyecto.
Con análisis de costo/beneficios, todos los costos y beneficios de adquirir y operar cada sistema alternativo se identifican y se establece una comparación entre ellos. Esto permite seleccionar el más conveniente para la empresa. Dentro de esta comparación se debe tomar en cuenta lo siguiente:
· Se comparan los costos esperados de cada alternativa con los beneficios esperados para asegurarse que los beneficios excedan los costos.
· La proporción costo/beneficio de cada alternativa se comparan con las que proporcionan los costos/beneficios de las otras alternativas para escoger la mejor.
· Se determinan las formas en que la organización podría gastar su dinero.
Obtención y Análisis de Requerimientos
Es la siguiente etapa de procesos de ingeniería de requerimientos, en ella, los ingenieros de software trabajan con los clientes y los usuarios finales del sistema para determinar el dominio de la aplicación, qué servicios debe proporcionar el sistema, el rendimiento requerido del sistema, las restricciones de hardware, etc.
Obtención y Análisis de Requerimientos
Requerimientos no funcionales Requerimientos funcionales
Obtención y Análisis de Requerimientos
· Requerimientos.- necesidades que provienen del negocio o del usuario.
· Requisito.- describe los servicios que debe ofrecer el sistema y sus restricciones. Especificaciones puntuales sobre el sistema, software que vienen a ser las soluciones a las necesidades del negocio.
· Requisito funcional.- define lo que se espera que debe hacer un sistema; se debe describir la interacción entre el sistema y el entorno; se detalla los servicios o funciones que proveerá el sistema. Ej. el sistema debe generar un reporte estadístico de los lugares con mayor riesgo de accidente.
· Requisito no funcional.- define como debe ser el sistema. Describe restricciones que limitan las selecciones para construir una solución. Es decir, son atributos relacionados con la calidad como rendimiento, escalabilidad, usabilidad, seguridad, fiabilidad, mantenibilidad, etc. Ej. Lenguaje de programación debe ser java, alta velocidad de procesamiento de datos o interfaz grafica de fácil manejo.
	
 (
Completa: describe todas las necesidades relevantes para los
stakeholders
)
 (
Consistente: carece de conflictos entre requisitos
) (
Correcta: todo es pertinente y no contiene errores
) (
Modificable: facilidad para efectuar cambios de forma sencilla, completa y consistente
) (
Verificable: existencia de un proceso acotado que determine si el
sistema final satisface el requisito
) (
Trazable: el origen del requisito está marcado de forma clara; y se puede seguir el impacto del requisito a lo largo del SDLC
)Obtención y análisis de requerimientos. Cómo debería ser una especificación de requisitos.
 (
Clara y no ambigua: una única interpretación
)
Obtención y análisis de requerimientos. Requisitos específicos.
Debe contener una lista detallada y completa de los requisitos que debe cumplir el sistema a desarrollar. El nivel de detalle de los requisitos debe ser el suficiente para que el equipo de desarrollo pueda diseñar un sistema que satisfaga los requisitos y los encargados de las pruebas puedan determinar si éstos se satisfacen.
Los requisitos se dispondrán en forma de listas numeradas para su identificación, seguimiento, trazabilidad y validación (ej. RF 10, RF 10.1, RF 10.2,...).
Obtención y análisis de requerimientos. Requisitos específicos. Redacción del requisito.
Emplear la estructura correcta de redacción.
 (
Obtención y análisis de 
requerimientos.
Requisitos específicos.
)Para cada requisito debe completarse la tabla descrita.
Requisitos comunes de las interfaces
· Interfaces de usuario
· Interfaces de hardware
· Interfaces de software
· Interfaces de comunicación
Requisitos funcionales
· Requisitos de Actores
· Requisitos de Escenarios - Interfaz
· Requisitos de Procesamiento
· Requisito de Gestión y Administración
Obtención y análisis de requerimientos. Requisitos específicos.
Requisitos no funcionales
· Requisitos de Disponibilidad
· Requisitos de Rendimiento
· Requisitos de Almacenamiento
· Requisitos de Seguridad
· Requisitos de Escalabilidad
Otros requisitos
Cualquier otro requisito que no encaje en ninguna de las secciones anteriores. Por ejemplo:
· Requisitos culturales y políticos
· Porcentaje de componentes dependientes del servidor.
· Porcentaje de código dependiente del servidor.
· Uso de un determinado lenguaje por su portabilidad.
· Uso de un determinado compilador o plataforma de desarrollo.
· Uso de un determinado sistema operativo.
Obtención y análisis de requerimientos. Requisitos específicos.
Obtención y análisis de requerimientos. Requisitos específicos.
Formato para recolección de requisitos y/o requerimientos del software basado en la norma IEEE Std 830-1998.
Obtención y análisis de requerimientos. Ejemplo 1.
Generalmente, el sistema debe ser capaz de terminar el proceso
de rastreo sin sobrecargar excesivamente el servidor
· Evite expresiones vagas como: ‘generalmente’, ‘comúnmente’
· Verifique si cada aserción puede ser medida de forma sencilla
El sistema debe ser capaz de terminar el proceso de rastreo en un tiempo inferior a 2 segundos y sin que el proceso sobrepase los 250 MB de memoria
Obtención y análisis de requerimientos. Ejemplo 2.
Los clientes podrán remitir órdenes por Internet. Estas órdenes deben incluir fecha de envío y cantidad de artículos.
Una vez que se recibe la orden, el equipo de empaquetado debe recoger todos los artículos y enviar un mail al cliente.
Deben soportarse los protocolos http y https, así como los navegadores Explorer y Firefox. La resolución mínima será de 1024x768
· Un exceso de términos diferentes en el mismo requisito puede indicar:
· Que se están mezclando diferentes
necesidades en un único requisito
· Que se está proporcionando demasiado detalle
· Igualmente, muchos verbos pueden involucrar diferentes necesidades mezcladas en un único requisito.
Obtención y análisis de requerimientos. Ejemplo 3.
El administrador deberá ser capaz de crear facturas asociadas con las diferentes compañías que estén dadas de alta en el sistema y éste también deberá estar al tanto de facturas impagas para que puedan generar un mail y enviárselos a ellos.
El proceso para localizar impagados es el siguiente:
· 1. Iterar sobre todas las facturas
· 2. Si Fecha_Factura + CondicionesPago es
mayor que la fecha actual, entonces:
· Si la categoría del cliente es A, entonces se le deja un mes extra
· SI no, mientras la factura no esté pagada no se le permite generar nuevas facturas y se le enviará un mail cada semana
· Evite el uso de pseudocódigo en sus
requisitos
· Los requisitos extensos (en caracteres o párrafos) pueden indicar baja calidad
Validación de Requerimientos
· La validación de requerimientos trata de mostrar que éstos realmente definen el sistema que el cliente desea. Coincide parcialmente con el análisis ya que éste implica encontrar problemas con los requerimientos.
· Se deben llevar a cabo verificaciones sobre requerimientos en el documento de requerimientos y/o requisitos.
Verificaciones que comprende la validación de requerimientos
	Verificaciones de validez
	· Un usuario puede pensar que se necesita un sistema para llevar a cabo ciertas funciones.
	Verificaciones de consistencia	• Los requerimientos en el documento no deben
contradecirse
	Verificaciones de completitud	• El documento debe incluir requerimientos que
definan todas las funciones.
	Verificaciones de realismo
	· Los requerimientos deben
verificarse para asegurar que se pueden implementar.
	Verificabilidad
	· Los requerimientos del sistema siempre deben
redactarse de tal forma que sean verificables.
	
	
	
	
Gestión de Requerimientos
· Los requerimientos para software/sistemas grandes son siempre cambiantes. Una razón es que estos sistemas normalmente se desarrollan para abordar problemas.
· La gestión de requerimientos es el procesos de comprender y controlar los cambios en los requerimientos del sistema.
Gestión de Requerimientos
Requerimientos duraderos y volátiles
Planificación de la gestión de requerimientos
Gestión del cambio de los requerimientos
 (
Marco de Trabajo
)Establece las bases para un proceso de software completo al identificar un número pequeño de actividades aplicables a todos los proyectos de software, sin importar su tamaño o complejidad.
 (
requisitos.
)Comunicación,	Con los clientes, investigación de
Marco de Trabajo Genérico
Planeación,
Modelado,
Plan para el trabajo de la ingeniería de sw. Describe las tareas técnicas, los riesgos probables, los recursos y un programa de trabajo.
Creación de modelos que permita al desarrollador y al cliente entender mejor los requisitos del sw y el diseño que logrará satisfacerlos.
 (
necesarias.
)Construcción,	Generación del código y las pruebas
Despliegue,
El sw se entrega al cliente, quien evaluará el producto y dará información sobre la evaluación.
Preguntas de repaso
1. ¿Qué es un requisito y/o requerimiento?
2. ¿Qué es un estudio de factibilidad?
3. Mencione 3 objetivos del estudio de factibilidad.
4. Mencione los tipos de factibilidad de un proyecto.
5. ¿Cuál	es	la	diferencia	entre	el	análisis	de	factibilidad	técnica	y operativa?
6. Realizar	el	estudio	de	factibilidad	técnica,	operativa	y	económica para el caso “Kiosko de prensa Zipizape”
7. Investigar los tipos de pruebas de software.
TEMA 4.
ADMINISTRACIÓN DE PROYECTOS DE SOFTWARE
NOTAS DEL CURSO
INGENIERÍA DE SOFTWARE
Reconocer el proceso de planificación de un proyecto de software
UPSE. 2019
Tópicos
	Tópicos
	Objetivos
	Actividades de gestión y calidad del
proyecto
	Analizar las actividades que se realizan en la administración de
proyectos de software.
	Planificación del proyecto, costo,
duración y personal del proyecto
	Reconocer el proceso de planificación de un proyecto de software.
	El plan de proyecto
	Aplicar el proceso de planificación de un proyecto de software.
	Hitos y entrega
	Identificar los hitos y entregables del proyecto
	Calendarización del proyecto,
gráficos y barras
	Planificar el tiempo que lleva cada etapa en la realización de
proyectos.
	
Gestión del riesgo
	Introducir a la noción de gestión del riesgo y a algunos de los riesgos que pueden surgir en los proyectos de software
	Identificación del riesgo
	Identificar los riesgos mediante el uso de técnicas y herramientas.
	Análisis del riesgo
	Analizar los riesgos mediante el uso de técnicas y herramientas.
	Planificación del riesgo
	Establecer planificación de respuestas ante riesgos detectados
	Supervisión del riesgo
	Establecer planificación para supervisión y control de riesgos.
Administración del desarrollo de software
Para poder realizar exitosamente un proyecto de software debemos	entender:
· El alcance del trabajo a realizarse
· Los riesgos que estamos enfrentando
· Los recursos requeridos
· Las tareas a realizarse
· Los eventos importantes a observar
· El esfuerzo (costo) a invertir
· El calendario a seguir
La ADMINISTRACIÓN comienza antes que el trabajo técnico empiece, continúa con la transformación del SW desde que es una idea hasta que es una realidad, y termina cuando el SW es discontinuado.
Elementos Clave en la Administración del Proyecto de Software
1. Definición de objetivos y alcances.
2. Medidas y métricas
3. Estimación, que incluye:
-Esfuerzo humano (en meses-persona)
-Duración (en unidades de tiempo)
-Costo (en unidades monetarias $$$)
Elementos Clave en la Administración del	Proyecto de Software
4. Análisis de Riesgo, que implica:
· Identificación del riesgo
· Evaluación del riesgo
· Determinación de prioridades
· Administración del riesgo
· Monitoreo del riesgo
5. Calendarización
6. Seguimiento y Control
Conceptos básicos
PROYECTO
Un proyecto es un esfuerzo temporal	que se lleva a cabo para crear un producto, servicio o resultado único: TEMPORAL
Significa que cada proyecto tiene un comienzo definido y
un final definido.
PRODUCTOS, SERVICIOS O RESULTADOS ÚNICOS
Un proyecto crea productos entregables únicos. Productos entregables son productos, servicios o resultados.
ELABORACIÓN GRADUAL
Significa desarrollar en pasos e ir aumentando mediante incrementos graduales.
Algunos ejemplos de proyectos:
Un concierto de musica, construcción de un puente. fabricación de un software, entre otros.
La construcción de una casa de playa tiene de duración 6 meses, el producto final es la casa de playa y se ejecuta inicia en los cimientos hasta culminar en el techo.
Ciclo de vida de un proyecto
Los proyectos "nacen" cuando el cliente, las personas o la organización dispuestas
a proporcionar los fondos para satisfacer la necesidad identifica una necesidad.
Por ejemplo, para una familia que está creciendo en tamaño, la necesidad quizá
sea una casa más amplia.
Gerencia de proyectos
LA DIRECCIÓN DE PROYECTOS
Es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto para satisfacer los requisitos del proyecto. La dirección de proyectos se logra mediante la aplicación e integración de los procesos de dirección de proyectos de inicio, planificación, ejecución, seguimiento y control, y cierre. El director del proyecto es la persona responsable de alcanzar los objetivos del proyecto.
La dirección de un proyecto incluye:
· Identificar los requisitos
· Establecer unos objetivos claros y posibles de realizar
· Equilibrar las demandas concurrentes de calidad, alcance, tiempo y costes
· Adaptar las especificaciones, los planes y el enfoque a las diversas inquietudes y expectativas de los diferentes interesados
El término “dirección de proyectos” se usa a veces para describir un enfoque de la organización o de dirección respecto a la gestión de los proyectos y de algunas operaciones continuas, que pueden ser redefinidas		como proyectos, que también se	denomina “dirección			por proyectos”
Triple restricción
Alcance
 (
Los
) (
directores
) (
del
)
· (
proyecto a menudo 
hablan de una “triple restricción” —alcance, tiempos y costes del proyecto— a la hora de gestionar los requisitos concurrentes de un proyecto. La calidad del proyecto se ve afectada por el equilibrio de estos tres factores
)Costo
· Tiempo
· Alcance
· Calidad
Tiempo
· Cost
o
Áreas de experiencia
FUNDAMENTOS DE LA DIRECCION DE PROYECTOS
Los estándares de PMI se encuentran en la intersección de estas 5 aéreas de experiencia
9 áreas de conocimiento de PmBook
9 áreas de conocimiento del pmbok en los prosecos de gestion de proyectos
Gestión del alcance del proyecto
Alcance del Proyecto.- definición de requisitos.
Delimitación funcional del proyecto, indica hasta donde se logrará el avance del trabajo. Puntualiza las partes específicas sobre las que se trabajará, ya sean áreas, departamentos, artículos, leyes, educación, sistemas tecnológicos, etc.
Para el caso de sistemas de información se deben describir los módulos contemplados. Para el caso de prototipos o soluciones no informáticas debe especificarse lo que se va a poder lograr como resultado.
Ejemplo 1. Definición de Objetivos y Alcances
El sistema informático para la línea de transporte se encargará de ordenar cajas que se desplazan a través de una línea. Cada caja estará definida por un código de barras que contiene el número de parte y se colocará en alguno de los 4 estantes que están al final de la línea, siguiendo