Inspecciones de software
Implican que las personas examinen la representación de la fuente con el propósito de descubrir anomalías y defectos
Las inspecciones no requieren la ejecución de un sistema por lo que debe utilizarse antes de la implementación.
Pueden estar aplicados a cualquier representación del sistema (requerimientos, diseño, configuración, datos, pruebas de datos, etc).
Se ha demostrado que es una técnica efectiva para descubrir errores del programa.
Éxito de la inspección
Pueden descubrirse muchos diferentes defectos en una sola inspección. Al probar, un defecto puede enmascarar a otro así que se requieren varias ejecuciones.
Inspecciones y pruebas
Las inspecciones y pruebas son complementarias y no técnicas opuestas de verificación.
Ambas deben utilizarse durante el proceso V & V.
Las inspecciones pueden comprobar el ajuste con una especificación pero no la conformancia con los requerimientos reales del cliente.
Las inspecciones no pueden comprobar características no funcionales como rendimiento, usabilidad, etc.
Inspecciones de programas
Es la aproximación formalizada a las revisiones del documento
Está pensado explícitamente para la detección de defectos (no su corrección)
Los defectos pueden ser errores lógicos, anomalías en el código que pueden indicar una condición errónea (p.ej: una variable no iniciada) o no conformidad con los estándares.
Precondiciones de la inspección
Debe haber una especificación precisa disponible.
Los miembros del equipo deben estar familiarizados con los estándares de organización.
Debe estar disponible un código sintácticamente correcto u otras representaciones del sistema.
Debería prepararse una lista de errores.
La gestión debe aceptar que la inspección aumentará los costes pronto en el proceso de software.
La gestión no debería utilizar inspecciones para la evaluación del personal, es decir, para encontrar quién comete errores.
El proceso de inspección
Reunión de inspección
Preparación individual
Visión de conjunto
Planificación
Repetición de trabajo
Seguimiento
Proceso de inspección
Visión de conjunto del sistema presentado al equipo de inspección.
Los códigos y documentos asociados se distribuyen al equipo de inspección por adelantado.
La inspección tiene lugar y se anotan los errores encontrados.
Se hacen modificaciones para reparar los errores descubiertos.
Puede requerirse o no una reinspección.
Roles en el proceso de inspección
Listas de inspección
Debería utilizarse una lista de errores comunes para guiar la inspección.
Las listas de errores dependen del lenguaje de programación y reflejan los errores característicos que es probable que aparezcan en el lenguaje.
En general cuanto más «débil» sea la comprobación del tipo, más grande será la lista.
Ejemplos: inicialización, nombramiento de constantes, terminación de bucles, límites de vectores, etc.
Comprobaciones de inspección 1
Comprobaciones de inspección 2
Cifras de inspección
500 sentencias/hora durante la visión de conjunto.
125 sentencias de código fuente/hora durante la preparación individual.
Pueden inspeccionarse de 90 a 125 sentencias/hora.
Por lo anto la inspección es un proceso caro.
Inspeccionar 500 líneas cuesta el esfuerzo de unas 40 horas/hombre (unos 4146 € en cifras españolas).
Análisis estático automatizado
Los analizadores estáticos son herramientas de software para procesar textos fuente.
Estos analizan sintácticamente el texto del programa y tratan de descubrir condiciones potencialmente erróneas y llamar la atención del equipo de V & V.
Son una ayuda muy efectiva en las inspecciones ( son un complemento, no una sustitución de las inspecciones)
Comprobaciones del análisis estático
Etapas del análisis estático
Análisis del flujo de control. Comprueba los bucles con múltiples puntos de entrada o salida, encuentra códigos inalcanzables.
Análisis de uso de los datos. Detecta variables no inicializadas, variables escritas dos veces sin que intervenga una asignación, variables que se declaran pero nunca se usan, etc.
Análisis de interfaz. Comprueba la consistencia de una rutina, las declaraciones del procedimiento y su uso.
Etapas del análisis estático
Análisis de flujo de información. Identifica las dependencias de las variables de salida. No detecta anomalías en sí pero resalta información para la inspección o revisión del código.
Análisis de caminos. Identifica los caminos del programa y arregla las sentencias ejecutadas en el camino. Nuevamente, es potencialmente últil en el proceso de revisión.
Ambas etapas generan grandes cantidades de información. Deben utilizarse con cuidado.
Análisis estático LINT
Uso del análisis estático
Es particularmente valioso cuando se utiliza un lenguaje como C que tiene un tipado débil y por tanto muchos errores no detectados por el compilador
Es menos rentable para lenguajes como Java que tienen una fuerte comprobación de tipado y por lo tanto pueden detectar muchos errores durante la compilación.
Verificación y métodos formales
Los métodos formales pueden utilizarse cuando se produce una especificación formal del sistema
Son la técnica de verificación estática primordial.
Implican análisis matemático detallado de la especificación y pueden desarrollar argumentos formales para que un programa se ajuste a su especificación formal
Argumentos a favor de los métodos formales
Producir una especificación matemática requiere un análisis detallado de los requerimientos y es probable que descubra errores.
Pueden detectar errores de implementación antes de comprobar cuando se analiza el programa a lo largo de la especificación.
Argumentos en contra de los métodos formales
Requieren notaciones especializadas que no pueden comprenderse por los expertos del dominio.
Es muy caro desarrollar una especificación y aún más caro demostrar que un programa cumple esa especificación.
Puede ser posible alcanzar el mismo nivel de confianza en un programa más barato utilizando otras técnicas de V & V.
El nombre se deriva del «Sala limpia» en la fabricación de unidades de semiconductores. La filosofía es evitar los defectos en lugar de eliminarlos.
Este proceso de desarrollo de software se basa en:
Desarrollo incremental;
Especificación formal;
Verificación estática utilizando argumentos de corrección;
Pruebas estáticas para determinar la fiabilidad del programa.
Desarrollo de software de sala limpia
El proceso de Sala limpia
Construir el programa estructurado
Definir los incrementos de software
Verificar formalmente el código
Integrar el incremento
Especificar formalmente el sistema
Desarrollar el perfil operacional
Diseñar las pruebas estáticas
Probar el sistema integrado
Revisión de errores
Características del proceso de Sala limpia
Especificación formal que utiliza un modelo de transición de estados.
Desarrollo incremental en el que el cliente prioriza sus incrementos.
Programación estructurada: se utiliza un número limitado de estructuras de control y de abstracciones de datos.
Verificación estática que utiliza inspecciones rigurosas.
Las pruebas estadísticas del sistema (tratado en el capítulo 24)
 Página anterior | Volver al principio del trabajo | Página siguiente  |