Calidad del software cap1

CAPITULO 1

Verificación y Validación
Asegurando que un sofware satisface las
necesidades del usuario

Por Julio C. Alsina

Ingeniería de Software

Objetivos

• Introducción a la verificación y validación del
software y discusión acerca de las diferencias
entre ambas.
• Descripción del proceso de inspección de
programa y su rol en la verificación y validación.
• Explicación de análisis estático como técnica de
verificación
• Descripción del proceso de desarrollo del software
Cleanroom


Tópicos cubiertos

• Planificación de la Verificación y
Validación
• Inspecciones de Software
• Análisis estático automatizado
• Desarrollo del software Cleanroom


Verificación vs validación

• Verificación:
“Estamos creando el producto correctamente”
El software debería ajustarse a su especificación

• Validación:
" Estamos creando el producto correcto"
El software debería realizar lo que el usuario realmente
necesita


El proceso de V & V

• Es un proceso de ciclo de vida – V&V
debería aplicarse en cada etapa en el
proceso de software (Rev. Req., Diseño, Insp.Codigo, Prueba)

• Tiene dos objetivos principales:
– El descubrimiento de defectos en un sistema
– El asegurar que un sistema es utilizable en una
situación operacional


V&V Estática y dinámica

• Inspecciones de Software: relacionadas con el
análisis de una representación estática de un
sistema para descubrir problemas (V&V estática)
– Puede ser un suplemento de un documento basado en
una herramienta y análisis de código
• Prueba de Software: relacionadas con pruebas y
observaciones del comportamiento del producto
(V&V dinámica)
– El sistema es ejecutado con datos de prueba y es
observado su comportamiento operacional


V&V estáticas y dinámicas

Static
Verificación
verification
Estática

Requirements
Especif. de High-level
Diseño de Formal
Especificación Detailed
Diseño
specification Program
Programa
specification
Requerim. design
Alto Nivel Formal design
Detallado

Dynamic
Validación
Prototype
Prototipo validation
Dinámica
“Técnicas estáticas solo comprueban correspondencia con las especificaciones”
“No demuestran que SW tiene utilidad operacional ni desempeño o fiabilidad”
“Para validar un sistema de SW se requieren PRUEBAS”

Pruebas de programa

“Son prácticas con programas que utilizan datos similares a los reales”
“Examinan salidas buscando anomalías”
“Pueden realizarse en fase de Implementación o despues de finalizar la misma”
• Pueden revelar la presencia de errores, NO su
ausencia
• Una prueba exitosa es aquella en la que se
descubren uno o mas errores
• La única técnica de validación para requerimientos
no funcionales
• Debe ser utilizada conjuntamente con verificación
estática para proveer un completo proceso de V&V

Tipos de Pruebas

• Pruebas de Defectos
– Pruebas diseñadas para descubrir
defectos en los sistemas
– Una prueba de defectos exitosa es aquella que revela la
presencia de defectos en un sistema
– Controladores obtienen sentimiento intuitivo de la
fiabilidad del SW
• Pruebas estadísticas
– Pruebas diseñadas para reflejar la frecuencia de
entradas de usuario. Utilizadas para estimación de
fiabilidad (número de caidas del sistema).
– Desempeño valora Tiempo Ejec. y Tiempo Respuesta


Metas de V& V

• La Verificación y Validación deberían
conceder confianza en que el software
alcanza su propósito.
• Esto NO significa que esté libre de defectos
• Mas bien debería ser lo suficientemente
bueno para su uso y el tipo de uso
determinará el grado de confianza que es
necesaria


Nivel de Confianza V & V

Depende del propósito del sistema, expectativas del
usuario y del ambiente de marketing
– Función del Software
• El nivel de confianza depende de cuan crítico es el software para una
organización (Ej. sistemas criticos de medicina)
– Expectativas del Usuario
• Los usuarios pueden tener bajas expectativas de ciertos tipos de
software. La tolerancia a fallas de sistema ha decrecido.
– Ambiente de Marketing
• Poner tempranamente un producto a la venta puede ser mas
importante que encontrar defectos en el programa (Ej. Si clientes no
estan dispuestos a pagar alto precio SW, son más tolerantes a fallas)


Pruebas y Depuración

• Pruebas y depuración de defectos son procesos distintos
• V&V están relacionados con el establecimiento de la
existencia de defectos en un programa
• Depuración está relacionada con
localizar y reparar estos errores
• Depuración considera formular una hipótesis acerca del
comportamiento del programa, luego probar estas
hipótesis para encontrar el error
• Pueden apoyarse en herramientas interactivas
integradas con un sistema de interpretación

El proceso de Depuración

Test
Resultados Test
Casos de
results Specification
Especificación
de pruebas cases
Pruebas

Locate Design Repair Re-test
Localizar Diseñar repair
error
Reparac Reparación de
error
Volver a
error program
error error error probar


Planeamiento de V & V

• V&V es un proceso caro. Puede ocupar la mitad del
presupuesto de desarrollo
• Se necesita una planificación cuidadosa para obtener lo
mejor de los procesos de pruebas e inspección
• La planificación debería estar antes que nada en el
proceso de desarrollo
• El plan debería identificar el balance entre verificación
estática y pruebas
• La planficación de las pruebas se relaciona con la
definición de estándares para el proceso de pruebas,
mas que con la descripción de las pruebas de productos
• Cuanto más crítico, mayor esfuerzo a verif. estáticas

El modelo de desarrollo V

Requir ements
Especif. de System
Especif. de System
Diseño del Detailed
Diseño
specification specification design design
Requerim. Sistema. Sistema. Detallado

PlanAcceptance
de Prueba System
Plan de Prueba PlanSub-system
de Prueba Module and
Codificación
integration integration unit code
y prueba de
test plan
de Aceptación Integración sma. Integr.test plan
Sub-sma.
test plan and tess
unidad y módulo

Servicio
Service
Prueba de
Acceptance Prueba Integra-
System Prueba Integra-
Sub-system
test
Aceptación integration test
ción Sistema integration test
ción sub-sistema

“Derivar planes de prueba a partir de las especificaciones y diseño del sistema”


La estructura de un plan de prueba de software

• Proceso de pruebas ”Descripcion de fases principales del proceso”
• Trazabilidad de requerimientos
“Plantear de forma a probar individualmente todos los requerimientos”
• Items probados ”Especificar los items de proceso de SW a probar”
• Agenda de pruebas ”Calendarizar pruebas y asignar recursos”
• Procedimientos de almacenamiento de pruebas
”Almacenar resultados. Debe ser posible auditar los procesos de prueba”
• Requerimientos de software y hardware
• Limitaciones ”Anticipar restricciones que puedan afectar al proceso”


Inspecciones de Software

• Involucran al equipo examinando la fuente de
representación con el objetivo de descubrir
anomalías y defectos
• No requieren ejecución de un sistema,
de modo que pueden ser utilizadas
antes de la implementación
• Pueden ser aplicadas a cualquier representación
del sistema (requerimientos, diseño, datos de
prueba, etc.)
• Técnica muy efectiva para descubrir errores

Exito de la Inspección

• Muchos y diferentes defectos pueden ser
descubiertos en una sola inspección. En
pruebas, un defecto puede enmascarar otro
de modo que son requeridas varias
ejecuciones. Cada prueba normalmente
conduce a una sola falla o defecto.
• Resaltan la reutilización y el conocimiento
de programación, de modo que los revisores
están preparados para ver aquellos tipos de
errores que aparecen comunmente.

Inspecciones y Pruebas
• Las inspecciones y pruebas son complementarias y
no técnicas de verificación opuestas
• Ambas deberían ser utilizadas
durante el proceso de V&V
• Las inspecciones pueden chequear conformidad con
una especificación, pero no conformidad con los
requerimientos reales del cliente
• Las inspecciones no pueden chequear características
funcionales, como ser rendimiento, usabilidad, etc.
• Las inspecciones sobrecargan el costo inicial pero
conducen a ahorros luego que los equipos adquieren
experiencia en su utilización.


Inspecciones de Programa

• Enfoque formalizado a revisiones de
documentos
• Intento explícito para la
DETECCIÓN de defectos (no la corrección)
• Los defectos pueden ser errores lógicos,
anomalías en el código que pueden indicar
una condición errónea (por ej. una variable
no inicializada) o el no cumplimiento de
estándares.

Pre-condiciones para Inspección

• Una especificación precisa debe estar disponible
• Los miembros del equipo deben estar familiarizados con
los estándares de la organización
• Debe estar disponible el código sintácticamente correcto
• Un checklist de errores debería estar preparado
• La gerencia debe aceptar que la inspección incrementará
los costos tempranamente en el proceso de software
• La gerencia no debe utilizar las inspecciones en las
evaluaciones del personal


El proceso de inspección

Planifica-
Planning
ción Panorama
Overview Follow-up
Seguimiento
general Individual
Preparación Re-elabora-
Rework
preparation
individual ción
Inspection
Reunión de
meeting
Inspección


Procedimiento de Inspección

• Panorama general del sistema presentado al
equipo de inspección (autor describe objetivo del codigo)
• Código y documentos asociados son distribuídos
por adelantado al equipo de inspección
• Preparacion individual de los participantes
• La inspección se realiza y son descubiertos los
errores (< 2hs). Cantidad depende de experiencia
• Se realizan las modificaciones para reparar los
errores descubiertos
• La re-inspección puede o no ser necesaria (seguimiento)
• El documento resultante es aprobado por el
moderador

Equipos de Inspección

• Constituídos por al menos 4 miembros:
– El autor del código a ser inspeccionado
– El inspector que encuentra los errores,
omisiones e inconsistencias
– El lector que lee el código al equipo
– El moderador que dirige la reunión y anota los
errores descubiertos (responsable de planificar)
– Otros roles son secretario y moderador en jefe.


Checklists de Inspección

• Un checklist de errores comunes debería
utilizarse para dirigir la inspección
• Un checklist de errores es dependiente del
lenguaje de programación
• Cuanto mas „débil‟ el tipo de
chequeo, mas largo el checklist
• Ejemplos: inicialización, nombrado de
constantes, terminación de bucles, límites
de arrays, etc.

Chequeos de inspección
Clase de falta Chequeo de Inspección
Fallas de datos -Están todas las variables inicializadas antes de que sus valores sean utilizados?
- Han sido nombradas todas las constantes?
- El límite inferior de los arrays debería ser 0, 1 u otro?
- El límite superior de los arrays debería ser igual al tamño del array o a su tamaño menos 1?
- Si se utilizan cadenas de caracteres, existe un delimitador explícitamente asignado?

Fallas de control - Para cada sentencia condicional, es correcta la condición?
- Cada bucle se termina?
- Están correctamente puestos entre paréntesis las sentencias compuestas?
- En las sentencias CASE, son posibles todos los casos que se incluyen?
Fallas de entrada/salida - Son utilizadas todas las variables?
- Todas las variables de salida tienen un valor asignado antes de que ocurra la salida?
Fallas de interfase - Todas las llamadas a funciones y procedimientos tienen el número correcto de parámetros?
- Coinciden los tipos de parámetros formales y casuales?
- Están los parámetros en el orden correcto?
- Si los componentes accesan la memoria compartida, tienen el mismo modelo de la estructura de
memoria compartida?
Fallas de administración - Si una estructura relacionada es modificada, han sido todos los enlaces correctamente reasignados?
de almacenamiento - Si se utiliza almacenamiento dinámico, se ha distribuído el espacio correctamente?
- Luego de que el espacio ya no sea necesario, es explícitamente desocupado?

Fallas de administración - Han sido consideradas todas las posibles condiciones de error?
de excepciones


Ratio de Inspección

• 500 declaraciones/hora durante el panorama general
• 125 declaraciones de origen/hora durante la
preparación individual
• 90-125 declaraciones/hora pueden ser
inspeccionadas
• Sin embargo, la inspección es un proceso caro
• Inspeccionar 500 líneas cuesta acerca de 40 horas
hombre
(4 personas  1 hs. panorama gral. + 4 hs. Prep.Individual + 4 a 5 hs. Inspección)


Análisis estático automatizado

• Los analizadores estáticos son herramientas
de software para el procesamiento
de texto fuente
• Analizan el texto del programa e intentan
descubrir condiciones potenciales de error y
las ponen a disposición del equipo de V&V
• Es muy efectivo como soporte para las
inspecciones. Es un suplemento pero no
puede reemplazar el proceso de inspección

Chequeos de análisis estático

Clase de falta Chequeo de Análisis estático
Fallas de datos - Variables utilizadas antes de su inicialización
- Variables declaradas pero nunca utilizadas
- Variables asignadas dos veces pero nunca utilizadas entre
asignaciones
- Posibles violaciones de límites de arrays
- Variables no declaradas
Fallas de control - Código no encontrado
- Segmentos incondicionales dentro de bucles
Fallas de entrada/salida - Variables de salida dobles
Fallas de interfase - No coinciden los tipos de parámetros
- No coinciden los números de parámetros
- Resultados de función sin utilizarse
- Funciones y procedimientos que no son llamados
Fallas de administración de - Punteros no asignados
almacenamiento - Punteros aritméticos


Etapas del análisis estático

• Análisis de Control de Flujo. Chequea los bucles
con salidas o entradas múltiples, encuentra código
perdido, etc.
• Análisis de uso de datos. Detecta variables no
inicializadas, variables escritas dos veces sin una
intervención asignada, variables que fueron
declaradas pero nunca fueron usadas, etc.
• Análisis de Interfase. Chequea la consistencia de
declaraciones de rutinas y procedimientos y sus
usos.


Etapas del Análisis Estático

• Análisis del flujo de información. Identifica las
dependencias de variables de entrada y salida.
No detecta anomalías, pero resalta información
para la inspección o revisión de código.
• Análisis de rutas. Identifica las rutas utilizadas en
el programa y analiza las declaraciones ejecutadas
en esas rutas. Potencialmente útil en el proceso de
revisión.
• Estas etapas generan gran cantidad de
información, que debe ser usada con cuidado

138% more lint_ex.c  Listar programa
#include <stdio.h>  Define función con 1 parametro
printarray (Anarray)
int Anarray;
{
printf(“%d”,Anarray);
}
main ()
{  Se llama función c/3 parametros
int Anarray[5]; int i; char c;
printarray (Anarray, i, c); Variables i y c declaradas
printarray (Anarray) ; no reciben valor y result.no se usa
}

139% cc lint_ex.c
 Compilación sin errores
140% lint lint_ex.c  Lint SI DETECTA ERRORES

lint_ex.c(10): warning: c may be used before set  Variables usadas sin inicializar
lint_ex.c(10): warning: i may be used before set
printarray: variable # of args. lint_ex.c(4) :: lint_ex.c(10) #Argum. dif.a los declarados
printarray, arg. 1 used inconsistently lint_ex.c(4) ::
lint_ex.c(10)
printarray, arg. 1 used inconsistently lint_ex.c(4) :: Análisis estático
lint_ex.c(11)
printf returns value which is always ignored LINT

Utilización del análisis estático

• Particularmente valioso cuando un lenguaje
como por ej. C es utilizado, el cual tiene un
tipeo débil y por lo tanto varios errores
pueden no ser detectados por el compilador
• Menos efectivo en términos de costos para
lenguajes como Java, que tienen fuertes
controles de tipeo y pueden por lo tanto,
detectar varios errores durante la
compilación

Desarrollo de software de „Sala Limpia‟

• El nombre se deriva del proceso de „Sala Limpia‟
en la fabricación de semiconductores. La filosofía
es evitar los defectos antes que corregirlos.
• Reemplaza a pruebas de unidades de componentes
por inspeccion para comprobacion de consistencia
con especificaciones
• El proceso de desarrollo está basado en:
– Especificación formal
– Desarrollo incremental
– Verificación estática utilizando argumentos de
corrección
– Pruebas estadísticas para determinar la fiabilidad de los
programas


El proceso de „Sala Limpia‟

Formally Reparación del Error
Error rework
Formalizar
specify
system
Especificación

Define
Definir Construct
Construir Formally
Verificar Integrate
Integrar
software
incrementos de structured
programa verify
código increment
incremento
increments
software program
estructurado code
formalmente
Develop
Desarrollar
operational
perfil Design
Diseñar Test
Pruebas
profile
operacional statistical integrated
pruebas sistema
tests system
estadísticas integrado


Características del proceso de Sala Limpia

• Especificación formal utilizando un modelo
de transición de estados
• Desarrollo incremental
• Programación estructurada – se utilizan
técnicas de control limitado y abstracción
• Verificación estática utilizando
inspecciones rigurosas
• Pruebas estadísticas del sistema (se basa en
el perfil operacional)


Desarrollo Incremental

Especificación
Frozen
specification
congelada

Establish
Establecer Formal
Especificación Develop s/w
Desarrollo de Deliver
Entrega del
rerquirements
requerimientos specification
Formal increment
Incremento de sw software
Software

Solicitud de ements change request
Requir cambio de requerimientos


Especificación Formal e Inspecciones

• El modelo basado en estados es una
especificación del sistema y el proceso de
inspección chequea el programa
contra este modelo
• El enfoque de programación es definido de
manera a que la correspondencia entre el
modelo y el sistema sea clara
• Argumentos matemáticos (no pruebas) son
utilizados para elevar la confianza en el
proceso de inspección

Equipos del proceso de „Sala Limpia‟

• Equipo de Especificación.. Responsable del
desarrollo y mantenimiento de la especificación
del sistema.
• Equipo de Desarrollo. Responsable por desarrollar
y verificar el software. El software NO es
ejecutado o compilado durante este proceso.
• Equipo de Certificación. Responsable por el
desarrollo de una serie de pruebas estadísticas para
ejercitar el software luego del desarrollo. Modelos
de crecimiento de la fiabilidad son utilizados para
determinar cuando la fiabilidad es aceptable.

Evaluación del proceso de „Sala Limpia‟

• Los resultados en IBM han sido impresionantes
con algunas fallas descubiertas en sistemas
entregados
• Evaluación independente muestra que el proceso
no es mas costoso que otros enfoques
• Menos errores que en un proceso
de desarrollo „tradicional‟
• No está claro como este enfoque puede ser
transferido a un ambiente con ingenieros menos
capacitados o menos motivados

Puntos claves

• La verificación y validación no son lo mismo. La
verficación muestra conformidad con la
especificación; la validación muestra que el
programa satisface las necesidades del cliente
• Los planes de prueba deberían ser elaborados para
guiar el proceso de pruebas
• Las técnicas de verificación estática consideran la
examinación y el análisis del programa para la
detección de errores
• Las inspecciones de programa
son muy efectivas para descubrir errores

Puntos claves
• Las inspecciones de código de programa son
realizadas por un equipo pequeño para localizar
fallas
• Las herramientas de análisis estático pueden
descubrir anomalías en los programas las cuales
pueden ser indicadores de fallas en el código
• El proceso de desarrollo de „Sala Limpia‟ depende
del desarrollo incremental, verificación estática y
pruebas estadísticas


Calidad del software cap1

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (13)

Semelhante a Calidad del software cap1

Semelhante a Calidad del software cap1 (20)

Último

Último (20)

Calidad del software cap1