Calidad del software cap1

Ingeniería de Software

CAPITULO 1CAPITULO 1

Asegurando que un sofware satisface las necesidades del usuario

Verificación y ValidaciónVerificación y Validación

Por Julio C. Alsina


ObjetivosObjetivos

• 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 cubiertosTó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: “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

Verificación vs validaciónVerificación vs validación


• 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

El proceso de V & VEl proceso de V & V


• 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ática y dinámicaV&V Estática y dinámica


V&V estáticas y dinámicasV&V estáticas y dinámicas

Formalspecification

High-leveldesign

Requirementsspecification

Detaileddesign

Program

PrototypeDynamicvalidation

Staticverification

VerificaciónEstática

Especif. deRequerim.

Diseño deAlto Nivel

EspecificaciónFormal

DiseñoDetallado

Programa

Prototipo ValidaciónDinámica

ValidaciónDiná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”


• 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

Pruebas de programaPruebas 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”


• 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

Tipos de PruebasTipos de Pruebas


Metas de V& VMetas 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 & VNivel 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 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

Pruebas y DepuraciónPruebas y Depuración


El proceso de DepuraciónEl proceso de Depuración

Locateerror

Designerror repair

Repairerror

Re-testprogram

Testresults Specification Test

casesResultadosde pruebas

Resultadosde pruebas EspecificaciónEspecificación Casos de

Pruebas

Casos dePruebas

Localizarerror

Localizarerror

Diseñar Reparac error

Diseñar Reparac error

Reparación deerror

Reparación deerror

Volver a probar

Volver a probar


• 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

Planeamiento de V & VPlaneamiento de V & V


El modelo de desarrollo VEl modelo de desarrollo V

Requirementsspecification

Systemspecification

Systemdesign

Detaileddesign

Module andunit codeand tess

Sub-systemintegrationtest plan

Systemintegrationtest plan

Acceptancetest plan

ServiceAcceptance

testSystem

integration testSub-system

integration test



Especif. deSistema.

Especif. deSistema.

Diseño delSistema.

Diseño delSistema.

DiseñoDetallado

DiseñoDetallado

Prueba Integra-ción sub-sistema

Prueba Integra-ción sub-sistema

Prueba Integra-ción Sistema

Prueba Integra-ción Sistema

Prueba deAceptación

Prueba deAceptaciónServicioServicio

Plan de Pruebade Aceptación

Plan de PruebaIntegración sma.

Plan de PruebaIntegr. Sub-sma.

Codificación y prueba de

unidad y módulo

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


La estructura de un plan de prueba de softwareLa 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 SoftwareInspecciones 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ónExito 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 PruebasInspecciones 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 ProgramaInspecciones 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ónPre-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ónEl proceso de inspección

Inspectionmeeting

Individualpreparation

Overview

Planning

Rework

Follow-up

Planifica-ción Panorama

general Preparaciónindividual Reunión de

Inspección

Re-elabora-ción

Seguimiento


Procedimiento de InspecciónProcedimiento 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ónEquipos 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ónChecklists 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ónChequeos 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 de almacenamiento

- Si una estructura relacionada es modificada, han sido todos los enlaces correctamente reasignados? - 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 de excepciones

- Han sido consideradas todas las posibles condiciones de error?


Ratio de Inspección 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 automatizadoAná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áticoChequeos 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 almacenamiento

- Punteros no asignados - Punteros aritméticos


Etapas del análisis estáticoEtapas 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áticoEtapas 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

#include <stdio.h>printarray (Anarray) int Anarray;{ printf(“%d”,Anarray);}main (){ int Anarray[5]; int i; char c; printarray (Anarray, i, c); printarray (Anarray) ;}

139% cc lint_ex.c140% lint lint_ex.c

lint_ex.c(10): warning: c may be used before setlint_ex.c(10): warning: i may be used before setprintarray: variable # of args. lint_ex.c(4) :: lint_ex.c(10)printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(10)printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(11)printf returns value which is always ignored

Análisis estático Análisis estático LINTLINT

Listar programa

Define función con 1 parametro

Se llama función c/3 parametros

Variables i y c declaradas

no reciben valor y result.no se usa Compilación sin errores Lint SI DETECTA ERRORES

Variables usadas sin inicializar

#Argum. dif.a los declarados


Utilización del análisis estáticoUtilizació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


• 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

Desarrollo de software de ‘Sala Limpia’Desarrollo de software de ‘Sala Limpia’


El proceso de ‘Sala Limpia’ El proceso de ‘Sala Limpia’

Constructstructuredprogram

Definesoftware

increments

Formallyverifycode

Integrateincrement

Formallyspecifysystem

Developoperational

profileDesign

statisticaltests

Testintegrated

system

Error reworkFormalizar

Especificación

Formalizar Especificación

Desarrollarperfil

operacional

Desarrollarperfil

operacional

Definir incrementos de

software

Definir incrementos de

software

Construir programa

estructurado

Construir programa

estructurado

Diseñarpruebas

estadísticas

Diseñarpruebas

estadísticas

Verificarcódigo

formalmente

Verificarcódigo

formalmente

Integrarincremento

Integrarincremento

Pruebassistema

integrado

Pruebassistema

integrado

Reparación del Error


Características del proceso de Sala LimpiaCaracterí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 IncrementalDesarrollo Incremental

Formalspecification

Develop s/wincrement

Establishrerquirements

Deliversoftware

Frozenspecification

Requirements change request

Establecerrequerimientos

Establecerrequerimientos



Desarrollo de Incremento de sw

Desarrollo de Incremento de sw

Entrega delSoftware

Entrega delSoftware

Especificacióncongelada

Solicitud de cambio de requerimientos


Especificación Formal e InspeccionesEspecificació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


• 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.

Equipos del proceso de ‘Sala Limpia’Equipos 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

Evaluación del proceso de ‘Sala Limpia’Evaluación del proceso de ‘Sala Limpia’


Puntos clavesPuntos 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


• 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

Puntos clavesPuntos claves

Calidad del software cap1

Education

Transcript of Calidad del software cap1