Instituto Profesional AIEP

De la Universidad Andrés Bello

Sede San Felipe

TALLER
DE PRUEBA Y MANTENCION
DE SISTEMAS

Docente: Priscilla Alvares Espejo

Ingeniera en Informática mención Desarrollo y Análisis de Sistemas
1
septiembre de 2016
 Unidad 1
“Pruebas de Sistemas”

Aprendizaje esperado
1. Identifican los conceptos de Validación y Verificación
(V&V), sus diferencias y similitudes.

septiembre de 2016 2
 Introducción

Las pruebas intentan demostrar que un programa

hace lo que se intenta que haga, así como descubrir
defectos en el programa antes de usarlo. Al probar el
software, se ejecuta un programa con datos artificiales. Hay
que verificar los resultados de la prueba que se opera para
buscar errores, anomalías o información de atributos no
funcionales del programa.

septiembre de 2016 3
 El Proceso de Prueba
Este proceso tiene 2 metas.

1)Demostrar al desarrollador y al cliente que el software

cumple con los requerimientos. Para el software
personalizado, esto significa que en el documento de
requerimientos debe haber, por lo menos, una prueba por
cada requerimiento. Para los productos de software
genérico, esto quiere decir que tiene que haber pruebas
para todas las características del sistema, junto con
combinaciones de dichas características que se
incorporarán en la liberación del producto.

septiembre de 2016 4
 El Proceso de Prueba

2) Encontrar situaciones donde el comportamiento del

software sea incorrecto, indeseable o no esté de acuerdo
con su especificación. Tales situaciones son
consecuencia de defectos del software. La prueba de
defectos tiene la finalidad de erradicar el
comportamiento indeseable del sistema, como caídas
del sistema, interacciones indeseadas con otros
sistemas, cálculos incorrectos y corrupción de datos.

septiembre de 2016 5
 El Proceso de Prueba
La primera meta conduce a la prueba de validación;
en ella, se espera que el sistema se desempeñe de manera
correcta mediante un conjunto dado de casos de prueba,
que refleje el uso previsto del sistema.

La segunda meta se orienta a pruebas de defectos,

donde los casos de prueba se diseñan para presentar los
defectos. Los casos de prueba en las pruebas de defecto
pueden ser deliberadamente confusos y no necesitan
expresar cómo se usa normalmente el sistema. Desde
luego, no hay frontera definida entre estos dos enfoques de
pruebas.
septiembre de 2016 6
 El Proceso de Prueba
Las pruebas no pueden demostrar que el software
esté exento de defectos o que se comportará como se
especifica en cualquier circunstancia. Siempre es posible
que una prueba que usted pase por alto descubra más
problemas con el sistema. Como afirma de forma elocuente
Edsger Dijkstra, uno de los primeros contribuyentes al
desarrollo de la ingeniería de software.

“Las pruebas pueden mostrar sólo la presencia de errores, mas no

su ausencia”.

Las pruebas se consideran parte de un proceso más amplio

de verificación y validación (V&V) del software. Aunque
ambas deno
septiembre son lo mismo, se confunden con frecuencia
2016 7
 Tarea
Hacer una Presentación en Power Point sobre las
“Herramientas de Depuración” investigar a fondo
cada una de ellas y hacer la demostración en
tiempo real de como funciona una de ellas.
• Trabajo Grupal: mínimo 2 máximo 4 personas.

-GBD -JDB -Junit -PDB

 Fecha de presentación viernes 26 de agosto

septiembre
Notade 2016
Formativa 8
 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
 Verificación y Validación del Diseño
(La Prueba del Software)
La prueba del software se conoce también como
verificación y validación (V&V).

• Verificación: conjunto de actividades que aseguran que

el software implementa correctamente una función
específica (¿estamos construyendo el producto
correctamente?).

• Validación: son las actividades que buscan asegurar si el

software construido se ajusta a los requisitos del cliente
(¿estamos construyendo el producto correcto?).
 V&V
Durante y después del proceso de implementación, el
programa en desarrollo debe ser comprobado, para
asegurar que satisface su especificación y entrega la
funcionalidad esperada por el cliente.

La verificación y la validación (V & V) es el nombre dado

a estos procesos de análisis y pruebas.
La verificación y la validación tienen lugar en cada etapa
del proceso del software.
V & V comienza con revisiones de los requerimientos y
continúa con revisiones del diseño e inspecciones de
código, hasta la prueba del producto.
 V&V
La verificación y la validación no son lo mismo, aunque a
menudo se confunden.
La diferencia entre ellas puede plantearse en estas
preguntas:
• «Validación: ¿Estamos construyendo el producto
correcto?»
• «Verificación: ¿Estamos construyendo el producto
correctamente?»
Entonces, la verificación implica comprobar que el software
está de acuerdo con su especificación. Si satisface sus
requerimientos funcionales y no funcionales.
 Validación del Software

La validación, en cambio, es un proceso más general.

Su objetivo es asegurar que el sistema satisface las
expectativas del cliente.
Va más allá de comprobar que el sistema satisface su
especificación (Análisis).
Procura demostrar que el software hace lo que el cliente
espera que haga. Ya que las especificaciones del sistema no
siempre reflejan los deseos o necesidades reales de los
usuarios del sistema.
 Objetivo del Proceso de V & V
Es asegurar que el sistema sea lo suficientemente
bueno para su uso pretendido. El nivel de confianza
requerido depende del propósito del sistema, las
expectativas de los usuarios y el entorno de mercado
actual:
1.Función del software. El nivel de confianza requerido
depende de cuán crítico sea el software para una
organización. El nivel de confianza para un software que
controla un sistema de seguridad es más alto que el
requerido para un software de demostración.
 Objetivo del Proceso de V & V

2. Expectativas del usuario. Muchos usuarios tienen pocas

expectativas sobre su software y no se sorprenden
cuando éste falla. Pueden aceptar estas fallas del
sistema cuando los beneficios de su uso son mayores
que sus desventajas. Sin embargo, la tolerancia de los
usuarios a los fallos de los sistemas está decreciendo
desde los años 90. Actualmente es menos aceptable
entregar sistemas no fiables, por lo que las compañías
de software deben invertir más esfuerzo para verificar y
validar.
 Objetivo del Proceso de V & V
3. Entorno de mercado. Cuando un sistema se
comercializa, los vendedores deben tener en cuenta a: la
competencia, el precio que sus clientes están dispuestos
a pagar por el sistema y la agenda requerida para
entregar dicho sistema. Cuando una compañía tiene
pocos competidores, puede decidir entregar un
programa antes de haber sido completamente probado y
depurado, porque quiere ser el primero en el mercado.
Cuando los clientes no están dispuestos a pagar precios
altos por el software, suelen tolerar más sus defectos.
Todos estos factores deben considerarse al decidir
cuánto esfuerzo invertir en V & V.
 2 Aproximaciones complementarias
en V & V
En el proceso de V & V hay 2 aproximaciones
complementarias para el análisis y comprobación de los
sistemas:

1.Las inspecciones de software: analizan y comprueban las

representaciones del sistema: el documento de
requerimientos, los diagramas de diseño y el código fuente
del programa. Pueden usarse inspecciones en todas las
etapas del proceso. Las inspecciones pueden ser
complementadas con algún análisis automático del código
fuente de un sistema o documentos asociados. Las
inspecciones de software y los análisis automáticos son
técnicas de V & V estáticas => pues no se necesita ejecutar
software en el computador.
 2 Aproximaciones complementarias
en V & V
2. Las pruebas del software implican ejecutar una
implementación del software con datos de prueba. Se
examinan las salidas del software y su entorno
operacional para comprobar que funciona tal y como se
requiere. Las pruebas son una técnica dinámica de
verificación y validación.
Verificación y Validación
Estática y Dinámica
Verificación y Validación
Estática y Dinámica
 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. Altodesign
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”
 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
 Verificación y Validación
Estática y Dinámica
La Figura anterior muestra que las inspecciones del
software y las pruebas son actividades complementarias. Se
pueden utilizar las inspecciones del software en todas las
etapas del proceso de desarrollo.
Comenzando por los requerimientos, puede
inspeccionarse cualquier representación legible del
software. Las revisiones de los requerimientos y del diseño
son las principales técnicas utilizadas para la detección de
errores en el diseño y la especificación.
 Verificación y Validación
Estática y Dinámica
Prueba: Sólo puede probarse un sistema cuando está
disponible un prototipo o una versión ejecutable del
programa.
Ventaja del desarrollo incremental => una versión
probable del sistema está disponible en etapas tempranas
del desarrollo.
Las funcionalidades pueden probarse a medida que se van
añadiendo al sistema, por lo que no tiene que realizarse
una implementación completa antes de que comiencen las
pruebas.
 Verificación y Validación
Estática y Dinámica
Las técnicas de inspección comprenden las
inspecciones de programas, el análisis automático del
código fuente y la verificación formal.
Las técnicas estáticas sólo pueden comprobar la
correspondencia entre un programa y su especificación
(verificación).
No pueden demostrar que el software es
operacionalmente útil.
Tampoco pueden comprobar el rendimiento y fiabilidad
del software.
 Verificación y Validación
Estática y Dinámica

• Por eso, la prueba de programas siempre será la

principal técnica de verificación y validación.
• Las pruebas implican ejecutar el programa utilizando
datos similares a los datos reales.
• Los defectos en los programas se descubren examinando
las salidas del programa y buscando las anomalías.
• Hay 2 tipos distintos de pruebas que pueden utilizarse
durante el proceso del software:
 Tipos de Pruebas
• 1. Las pruebas de validación intentan demostrar que el software
es el que el cliente quiere y que satisface sus requerimientos.
• Se pueden utilizar pruebas estadísticas para probar el
rendimiento y la fiabilidad de los programas, y comprobar
cómo trabaja bajo ciertas condiciones.
• 2. Las pruebas de defectos intentan revelar defectos en el
sistema en vez de simular su uso operacional.
• El objetivo es hallar inconsistencias entre un programa y su
especificación.
• Durante las pruebas de validación, se encontrarán defectos en el
sistema.
• Durante las pruebas de defectos, podemos demostrar que el
programa satisface sus requerimientos.
 V & V Vs. Depuración

• Normalmente, los procesos de V & V y depuración se

intercalan.
• A medida que se descubren defectos en el programa que
se está probando, se tiene que cambiar el programa para
corregir tales defectos.
• Las pruebas (V & V) y la depuración tienen diferentes
objetivos:
• 1. Los procesos de V & V intentan establecer la
existencia de defectos en el software.
• 2. La depuración es un proceso que localiza y corrige
estos defectos.
 V & V Vs. Depuración
• No hay un método sencillo para depurar programas.
• Los depuradores habilidosos buscan patrones en las
salidas de las pruebas, que revelen las fallas y utilizan
su conocimiento sobre el tipo de defecto, el patrón de
salida, el lenguaje de programación y el proceso de
programación para localizar el defecto.
• Durante la depuración, puede utilizarse el conocimiento
de errores comunes de programación (olvidar
incrementar un contador).
• También se buscan errores característicos (como
direccionamiento de punteros, etc.).
 V & V Vs. Depuración
• Localizar los defectos en un programa no siempre es
sencillo.
• Pues, el defecto puede no estar cerca del punto donde
falló el programa.
• Para localizar un defecto, se pueden tener que diseñar
pruebas adicionales que reproduzcan el defecto original y
determinen con precisión su localización en el programa.
• Se puede tener que hacer manualmente una traza del
programa, línea por línea.
• Las herramientas de depuración que recopilan
información sobre la ejecución del programa también
ayudan a localizar la fuente de un problema.
 Depuración

• Hay herramientas de depuración interactivas dentro de

las herramientas de soporte del lenguaje (integradas al
compilador).
• Éstas proporcionan un entorno de ejecución
especializado y permite acceder a los valores de las
variables del programa.
• Se puede controlar la ejecución «paso a paso» del
programa sentencia por sentencia.
• Despuésde ejecutar cada sentencia, pueden examinar los
valores de las variables y así descubrir dónde está el
error.
 Depuración
Pruebas de Regresión
• Cuando se ha descubierto un defecto en el programa,
hay que corregirlo y volver a validar el sistema.
• Esto puede implicar volver a inspeccionar el programa o
hacer pruebas de regresión, donde se ejecutan de nuevo
los tests existentes.
• Las pruebas de regresión se utilizan para comprobar que
los cambios en el programa no introducen nuevos
defectos.
• La experiencia ha demostrado que una alta proporción
de «reparaciones» de defectos son incompletas o
introducen nuevos defectos en el programa.
 Depuración
Pruebas de Regresión
• En principio, deberían repetirse todos los tests después
de la reparación de cada defecto.
• En la práctica, esto es muy caro.
• Como parte del plan de pruebas, deberían identificarse
dependencias entre los componentes y las pruebas
asociadas con cada componente.
• Esto es, debe establecerse una traza entre los casos de
prueba y los componentes probados.
• Si esta trazabilidad se documenta, entonces se puede
ejecutar un subconjunto de los casos de prueba del
sistema para comprobar el componente modificado y
sus dependientes.
 Planificación de la verificación y
validación
• La verificación y validación es un proceso caro.
• Para algunos sistemas, más de la mitad del presupuesto
para desarrollar el sistema se invierte en V & V.
• Es necesaria una planificación cuidadosa para obtener el
máximo provecho de las inspecciones y pruebas y
controlar los costos del proceso de V & V.
• Debe comenzarse la planificación de la V & V del
sistema en etapas tempranas del proceso de desarrollo.
 Planificación de la verificación y
validación
• Dentro del proceso de planificación de V & V, hay que
buscar un equilibrio entre las aproximaciones estáticas y
dinámicas de V & V.
• También hay que pensar procedimientos para las
inspecciones y pruebas del software, establecer listas de
comprobación para conducir las inspecciones de
programas y definir el plan de pruebas del software.
• El esfuerzo destinado a las inspecciones y las pruebas
depende del tipo de sistema a desarrollar y de los
expertos de la organización en V & V con que se cuente.
 Planificación de la verificación y
validación
• Como regla general, cuanto más crítico sea el sistema,
debe dedicarse más esfuerzo a las técnicas de
verificación estáticas.
• Los planes de pruebas, además de ayudar a asignar
recursos y estimar el calendario de pruebas, son útiles
para los ingenieros del software implicados en el diseño
y la realización de las pruebas del sistema.
• Ayudan a obtener una panorámica general de las
pruebas del sistema y ubicar su propio trabajo en este
contexto.
 Plan de Pruebas

• Además de determinar el calendario y procedimientos

para las pruebas, el plan de pruebas define los recursos
de hardware y software que se requieren.
• Es útil para los gestores del sistema (responsables de
asegurar que estos recursos están disponibles para el
equipo de pruebas).
• Los planes de pruebas deben incluir cantidades
significativas de contingencias, para que los desajustes
puedan solucionarse y el personal pueda ser reasignado
a otras actividades.
 Plan de Pruebas
• Para sistemas más pequeños, se puede utilizar un plan
de pruebas menos formal, pero sigue siendo necesario
un documento formal para la planificación de las
pruebas.
• Para algunos procesos ágiles (programación extrema),
las pruebas son inseparables del desarrollo.
• Como otras actividades de planificación, la planificación
de las pruebas también es incremental.
• Los planes de pruebas no son documentos estáticos.
• Evolucionan durante el proceso de desarrollo.
• Los planes de pruebas cambian debido a retrasos en
otras etapas del proceso de desarrollo.
 Inspecciones de software
• Proceso de V & V estático donde un software se revisa
para encontrar errores, omisiones y anomalías.
• Las inspecciones se suelen centrar en el código fuente,
pero puede inspeccionarse cualquier representación
legible del software.
• Hay 3 ventajas fundamentales de la inspección sobre las
pruebas:
• 1. Durante las pruebas, los errores pueden ocultar
otros errores.
• Cuando se descubre un error, nunca se puede estar
seguro de si otras anomalías de salida son debidas a un
nuevo error o son efectos laterales del error original.
 Inspecciones de software
• Como la inspección es un proceso estático, no hay que
preocuparse de las interacciones entre errores.
• Así, una única sesión de inspección puede descubrir
muchos errores en un sistema.
• 2. Pueden inspeccionarse versiones incompletas de un
sistema sin costos adicionales.
• Si un programa está incompleto, entonces se necesita
desarrollar software de pruebas, para probar las partes
disponibles.
• Esto, obviamente, añade costos al desarrollo del sistema.
 Inspecciones de software
• 3. Además de buscar los defectos en el programa, una
inspección también puede considerar otros atributos de
calidad más amplios: cumplimiento con los estándares,
portabilidad y mantenibilidad.
• Puede buscarse ineficiencias, algoritmos no adecuados y
estilos de programación que podrían tornar al sistema
difícil de mantener y actualizar.
• Muchos autores observaron que la revisión estática de
código era más efectiva y menos costosa que las pruebas
de defectos, a la hora de encontrar fallas en los
programas.
 Revisiones y Pruebas
• Las revisiones y pruebas tienen ventajas e
inconvenientes y deberían utilizarse conjuntamente en el
proceso de V & V.
• Se puede empezar la V & V con inspecciones en etapas
tempranas del ciclo de desarrollo.
• Una vez que se integra un sistema, se necesita
comprobar sus propiedades emergentes y que su
funcionalidad sea la que su propietario quiere.
• A pesar del éxito de las inspecciones, es difícil utilizarlas
en muchas organizaciones de desarrollo de software.
 Revisiones y Pruebas

• Los ingenieros de software con experiencia en la prueba

de programas son reacios a aceptar que las inspecciones
pueden ser más efectivas para detectar defectos que las
pruebas.
• Además, las inspecciones requieren costos adicionales.
• No hay duda de que las inspecciones sobrecargan al
principio los costos de V & V y conducen a un ahorro
sólo después de que los equipos de desarrollo adquieran
experiencia en su uso.
 Revisiones y Pruebas

• Además, las inspecciones requieren tiempo para

organizarse y parecen demorar el desarrollo.
• Es difícil convencer a un gestor muy presionado que este
tiempo puede recuperarse más tarde, cuando deba
emplear menos tiempo depurando el programa.
 El proceso de inspección de
programas
• Las inspecciones de programas son revisiones para la
detección de defectos en el programa.
• Es un método bastante utilizado de verificación de
programas, especialmente en ingeniería de sistemas
críticos.
• Se realizan con profesionales con diferentes
conocimientos que efectúan una revisión cuidadosa,
línea por línea, del código fuente del programa.
• El objetivo primordial de las inspecciones es encontrar
defectos en el programa, en lugar de considerar
cuestiones de diseño más generales.
 El proceso de inspección de
programas
• Los defectos pueden ser errores lógicos, anomalías en el
código, o el incumplimiento de los estándares del
proyecto o de la organización.
• Por otra parte, otros tipos de revisión pueden estar más
relacionados con la agenda, los costos, el progreso frente
a hitos definidos o la evaluación de si es probable que el
software cumpla los objetivos fijados por la
organización.
• La inspección de programas es un proceso formal
realizado por un equipo de al menos cuatro personas.
• Los miembros del equipo analizan sistemáticamente el
código y señalan posibles defectos.
 El proceso de inspección de
programas
• Algunos sugieren estos roles: conductor, lector,
probador y moderador.
• El lector lee el código en voz alta al equipo de
inspección.
• El probador inspecciona el código, desde una
perspectiva de prueba.
• El moderador organiza el proceso.
• Otros no creen que sea necesario leer el programa en voz
alta.
• La misma persona puede adoptar más de un rol y el
tamaño del equipo puede variar de una inspección a
otra.
Roles en el Proceso de Inspección
 El proceso de inspección de
programas
• Antes de que comience una inspección del programa, es
esencial que:
• 1. Se tenga una especificación precisa del código a
inspeccionar.
• Es imposible inspeccionar un componente en detalle,
para detectar defectos, sin una especificación completa.
• 2. Los miembros del equipo de inspección estén
familiarizados con los estándares de la organización.
• 3. Que todos los miembros del equipo tengan una
versión compilable y actualizada del código.
• No se debe inspeccionar código «casi completo».
 El proceso de inspección de
programas
• El moderador del equipo de inspección es el responsable
de la planificación de la inspección.
• Esto implica seleccionar un equipo de inspección,
organizar una sala de reuniones y asegurar que el
material a inspeccionar y sus especificaciones estén
completas.
• El programa a inspeccionar se presenta al equipo de
inspección.
• Después viene un periodo de preparación individual.
• Cada miembro del equipo de inspección estudia la
especificación y busca defectos en el código.
El proceso de inspección de
programas
 El proceso de inspección de
programas
• La inspección debe ser corta (no más de dos horas) y
debería centrarse en la detección de defectos,
cumplimiento de los estándares y programación de baja
calidad.
• El equipo de inspección no debería sugerir cómo deben
repararse estos defectos ni recomendar cambios en los
componentes.
• A continuación, el programador debe corregir los
problemas identificados.
• Luego, el moderador debe decidir si se requiere una
reinspección de código.
 El proceso de inspección de
programas
• El moderador puede decidir que no se requiere una
reinspección completa y que los defectos han sido
reparados con éxito.
• El programa entonces es aprobado por el moderador
para su entrega.
• Durante una inspección, se usa una lista de
comprobación de errores de programación comunes
para centrar el análisis.
• Esta lista de comprobación puede basarse en ejemplos de
defectos comunes en una aplicación particular.
 El proceso de inspección de
programas
• Se necesitan diferentes listas de comprobación para
distintos lenguajes de programación debido a que cada
lenguaje tiene sus propios errores característicos.
• Con 4 personas en un equipo de inspección, el costo de
inspeccionar 100 líneas de código es equivalente a un
esfuerzo de una persona-día.
• Los costos de las pruebas son muy variables y dependen
del número de defectos en el programa.
 El proceso de inspección de
programas
• El esfuerzo requerido para la inspección de programas
es menor a la mitad del que se requeriría para una
prueba de defectos equivalente.
• Algunas organizaciones han abandonado la prueba de
componentes a favor de las inspecciones.
• Han comprobado que las inspecciones de programas son
tan efectivas a la hora de encontrar errores que los costos
de las pruebas de componentes no son justificables.
• Estas organizaciones observan que las inspecciones de
componentes, combinados con las pruebas del sistema,
son la estrategia de V & V más rentable.
 El proceso de inspección de
programas
• La inspección de programas es un proceso público de
detección de errores comparado con el proceso más
privado de prueba de componentes.
• Inevitablemente, los errores cometidos por individuos
se muestran a todo el equipo de programación.
• Los líderes de los equipos de inspección deben gestionar
el proceso cuidadosamente y desarrollar una cultura de
apoyo cuando se detectan errores, para que no exista el
sentimiento de culpa asociado a dichos errores.
 El proceso de inspección de
programas
• A medida que una organización gana experiencia en el
proceso de las inspecciones, puede usar sus resultados
para mejorar sus proceso.
• Las inspecciones son una forma ideal de recopilar datos
sobre el tipo de defectos que se producen.
• El equipo de inspección y los programadores pueden
sugerir por qué se produjeron estos errores.
• En lo posible, el proceso debe ser modificado para
eliminar las causas de los defectos, para que éstos
puedan evitarse en sistemas futuros.
 Análisis estático automatizado
• Las inspecciones son una forma de análisis estático —se
examina el programa sin ejecutarlo—.
• Las inspecciones suelen estar dirigidas por listas de
comprobación de errores y heurísticas que identifican
errores comunes en diferentes lenguajes de
programación.
• Para algunos errores y heurísticas, es posible
automatizar el proceso de comprobación de programas
frente a estas listas, las cuales han propiciado el
desarrollo de analizadores estáticos automatizados para
diferentes lenguajes.
 Análisis estático automatizado
• Los analizadores estáticos son herramientas de software
que escanean el código fuente de un programa y
detectan posibles defectos y anomalías.
• Analizan el código del programa y así reconocen los
tipos de sentencias en el programa.
• Pueden detectar si las sentencias están bien formadas,
hacer inferencias sobre el flujo de control del programa
y, en muchos casos, calcular el conjunto de todos los
posibles valores para los datos del programa.
• Complementan las facilidades de detección de errores
proporcionadas por el compilador del lenguaje.
 Análisis estático automatizado

• El objetivo del análisis estático automatizado es llamar la

atención del inspector sobre las anomalías del programa,
tales como:
• Variables que se utilizan sin inicialización,
• Variables que no se usan,
• Datos cuyo valor podría estar fuera de alcance.
• Estas anomalías suelen ser el resultado de errores de
programación u omisiones.
• Resaltan aspectos del programa que podrían funcionar
mal.
 Análisis estático automatizado
• Sin embargo, estas anomalías pueden no ser
necesariamente defectos en el programa.
• Pueden ser deliberadas o no tener consecuencias
adversas.
• Los analizadores estáticos son particularmente valiosos
cuando se utiliza un lenguaje de programación como C.
• Este lenguaje no tiene reglas estrictas, y la comprobación
que puede hacer el compilador de C es limitada.
• Por lo tanto, es fácil para los programadores cometer
errores, y la herramienta de análisis estático puede
automáticamente descubrir algunos defectos de los
programas.
 Análisis estático automatizado

• Esto es particularmente importante en el desarrollo de

sistemas críticos.
• Aquí, el análisis estático puede descubrir muchos errores
potenciales y reducir los costos de prueba, de forma
significativa.
• Los diseñadores de lenguajes modernos (Java) han
eliminado algunas características propensas a error.
• Así, es menos probable crear código con errores, de forma
accidental.
• Esta aproximación de evitar errores en vez de detectar
errores es más efectiva a la hora de mejorar la fiabilidad
del programa.
 Verificación y métodos formales
• Los métodos formales de desarrollo del software se
basan en representaciones matemáticas del software.
• Se ocupan principalmente del análisis matemático de la
especificación; de transformar la especificación a una
representación más detallada, semánticamente
equivalente; o de verificar si una representación del
sistema es semánticamente equivalente a otra.
• Son una técnica de verificación estática.
• Los métodos formales requieren un análisis muy
detallado de la especificación del sistema.
• Su uso consume tiempo y resulta caro.
 Verificación y métodos formales

• Entonces, los métodos formales están restringido

principalmente a procesos de desarrollo de seguridad
crítico y seguro (sistemas de defensa).
• Los métodos formales pueden utilizarse en diferentes
etapas en el proceso V & V:
• 1. Puede desarrollarse una especificación formal del
sistema y analizarse matemáticamente para buscar
inconsistencias.
• Esta técnica es efectiva para descubrir errores y
omisiones de especificación.
 Verificación y métodos formales
• 2. Puede verificarse con argumentos matemáticos, que
el código es consistente con su especificación.
• Esto requiere una especificación formal y es efectiva
para descubrir errores de diseño y programación.
• La especificación formal fuerza un análisis detallado de
la especificación.
• Puede revelar inconsistencias u omisiones potenciales
que podrían no ser descubiertas hasta que el sistema sea
operacional.
• Demuestra que el programa desarrollado satisface su
especificación, por lo que los errores de implementación
no comprometen la confiabilidad.
 Argumentos en contra de la
Verificación Formal
• Requiere notaciones especializadas.
• Sólo se pueden utilizar por personal entrenado
especialmente y no pueden ser comprendidas por
expertos del dominio.
• Los problemas con los requerimientos pueden estar
encubiertos por la formalidad.
• Los ingenieros software no comprenden el dominio.
• Los expertos en el dominio no pueden encontrar estos
problemas porque no comprenden la especificación.
• Aunque la especificación puede ser matemáticamente
consistente, puede no especificar las propiedades del
sistema realmente necesarias.
 Argumentos en contra de la
Verificación Formal
• Verificar un software así consume mucho tiempo y
requiere herramientas especializadas (demostradores de
teoremas y expertos matemáticos).
• Por lo tanto, es un proceso muy caro y, a medida que el
tamaño del sistema crece, los costos de la verificación
formal crecen desproporcionadamente.
• Mucha gente piensa que la verificación formal no es muy
rentable.
• Lo mismo puede lograrse, de forma más económica,
usando otras técnicas de validación como las
inspecciones y pruebas de sistemas.
 Argumentos en contra de la
Verificación Formal
• Se ha dicho que el uso de métodos formales para
desarrollar conduce a sistemas más fiables y seguros.
• No hay duda de que un sistema testeado con una
especificación formal es menos probable que contenga
anomalías.
• Sin embargo, no garantiza que el software será fiable en
el uso práctico.
 Continuara…

septiembre de 2016 70