UNIVERSIDAD DE CARTAGENA.

CENTRO TUTORIA: LORICA, CÓRDOBA.

ASIGNATURA:

EVALUACIÓN DE SOFTWARE.

TUTOR:
FERNANDO DAZA.

ESTUDIANTES:
JOSE LUIS GUERRA AVILA.
JAVER DARIO BARROSO VERTEL
TEMA:
METRICAS DEL SOFTWARE.

ING: DE SISTEMAS.
IX SEMESTRE.

LORICA, CÓRDOBA

2020.
 INTRODUCCIÓN.

Se sabe que algunas de las actividades de desarrollo del proyecto de software

comprenden medición y métricas, estimación, análisis de riesgo, planificación del
programa, seguimiento y control. El recopilar datos (investigación histórica), calcular
métricas de calidad, orientadas a objetos, y evaluar métricas, son algunos de los pasos
que se deben realizarse al comenzar un producto.

Hoy día es cada vez más frecuente la consideración de métricas de software, es por
eso que sé están implantando en la actualidad, llevando consigo puntos débiles
aumento de esfuerzo y fuertes alta calidad, reusabilidad, madurez que están
experimentado los ingenieros y administradores de software. El uso de éstas se ha
adoptado con éxito en el amplio mercado de desarrollo de software introduciendo
reconocimientos y consideraciones por parte de administradores y usuarios, y
estableciendo la necesidad de un enfoque más disciplinado y de una alta calidad. Así
muchos particulares y compañías desarrolladoras de software, están reconociendo la
importancia del uso de las métricas, aunque de igual modo siguen sin conocer el
alcance de madurez y calidad del producto final y la disciplina de ingeniería madura que
llega a alcanzar con la aplicación de los distintos métodos y técnicas y la interpretación
de los resultados que proyecta el uso de las métricas; provocando con esto un cambio.

OBJETIVO GENERAL.

 Conocer a fondo todo lo relacionado con el funcionamiento de las métricas del

software

OBJETIVOS ESPESIFICOS.

 Investigar, definir y explicar las distintas teorías y definiciones de métricas de

Software.
MÉTRICAS DEL SOFTWARE En el campo de la ingeniería del software una métrica es
cualquier medida o conjunto de medidas destinadas a conocer o estimar el tamaño u
otra característica de un software o un sistema de información, generalmente para
realizar comparativas o para la planificación de proyectos de desarrollo. Un ejemplo
ampliamente usado es la llamada métrica de punto función. Las métricas de software
se refieren a un amplio rango de medidas para el software de computadoras dentro del
contexto de la planificación del proyecto de software, las métricas de calidad pueden
ser aplicadas a organizaciones, procesos y productos los cuales directamente afectan a
la estimación de costos. Las medidas directas. Ejemplo la longitud de un tornillo.
Medidas indirectas ejemplo. Calidad de tornillos producidos.

Métricas Orientadas al tamaño. Son utilizadas para obtener medidas directas del
resultado y la calidad de la ingeniería del software.

Métricas Orientadas a la Función. Son medidas indirectas del software y del proceso
por el cual se desarrollará; se centran en la funcionalidad o utilidad del programa
(Puntos de Función).

Métricas de calidad del Software. Desarrollando y analizando una línea base de

métricas de calidad, una organización puede actuar con objeto de corregir esas áreas
de proceso del software que son la causa de los defectos del software. Con la creación
de estas métricas los ingenieros del software pueden obtener una visión más profunda
del trabajo que realizan y del producto que elaboran.

La corrección, facilidad de mantenimiento, integridad, y facilidad de uso son medidas de

calidad que proporcionan indicadores útiles para el equipo del proyecto.

 Corrección. La corrección es el grado en el que el software lleva a cabo su

función requerida.
 Facilidad de mantenimiento. Es la facilidad con la que se puede corregir un
programa si se encuentra un error, se puede adaptar si su entono cambia, o
mejorar si el cliente desea un carnio de requisitos. Esta actividad cuenta con más
esfuerzo que cualquier otra actividad de ingeniería del software.
  Integridad. Mide la capacidad de un sistema para resistir ataques (tanto
accidentales como intencionados) contra su seguridad. El ataque se puede
realizar en cualquiera de los tres componentes del software: programas, datos y
documentos.

Facilidad de uso. La facilidad de uso es un intento de cuantificar lo amigable que

puede ser el programa con el usuario. Se puede medir en función de cuatro
características: Habilidad intelectual y/o física requerida para aprender el sistema. El
tiempo requerido para llegar a ser moderadamente eficiente en el uso del sistema.
Aumento neto en productividad, medida cuando alguien utiliza el sistema
moderadamente y eficientemente. Valoración subjetiva de la disposición de 1os
usuarios hacia el sistema, a veces obtenida mediante un cuestionario.

Eficacia de la Eliminación de Defectos. Proporciona beneficios tanto a nivel del

proyecto como del proceso, es una medida para filtrar las actividades de la garantía de
calidad y de control al aplicarse a todas las actividades del marco de trabajo del
proceso.

Métricas técnicas del software.

En este punto, nos damos cuenta que la medición del software bajo las técnicas vistas
carece de objetividad, uno que las consideramos técnicas cualitativas y no
cuantitativos. Ahora bien, el problema es cómo definir un método de medición que nos
permitan mostrar a través de una cantidad la complejidad del software.

Factores de calidad de McCall. McCall puedo poner una clasificación de factores que
se concentran en tres aspectos importantes.

 Sus características operativas

 Su capacidad de cambio
 Su adaptabilidad a nuevos entornos

Dentro de tres aspectos McCall analizar los siguientes factores:

Corrección, fiabilidad, eficiencia, integridad, usabilidad, facilidad de mantenimiento,

flexibilidad, facilidad de prueba, portabilidad, reusabilidad, interoperabilidad.
Basándonos en todas estas características la forma de evaluar el software que es dar
una calificación de la métrica, multiplicado por un factor de calidad del software y
finalmente realizar una sumatoria de esto. McCall lo puso en una escala de calificación
del cero al diez, en donde cero es baja calidad y diez es alta calidad. Aunque este
método es bastante flexible y puede adaptarse a cualquier entorno las mediciones se
basan en un criterio subjetivo.

Métrica para el esquema de puntuación. Facilidad de auditoría. La facilidad con la

que se puede comprobar el cumplimiento de los estándares, la exactitud de lo cálculos
y el control. Estandarización de comunicaciones, el grado de empleo de estándares de
interfaces, protocolos y anchos de banda. Compleción: el grado con que se ha logrado
la implementación total de una función. Concisión: Lo compacto que es el programa en
términos de líneas de código.

Métricas del modelo de Calidad FURPS. Hewlett Packard ha desarrollado un conjunto

de factores de calidad del software al que se le ha dado el acrónimo de FURPS:
funcionalidad, facilidad de empleo, fiabilidad, rendimiento y capacidad de soporte. Los
factores de calidad son cinco y se definen de acuerdo al siguiente conjunto de atributos:
Funcionalidad. Se valora evaluando el conjunto de características y capacidades del
programa, la generalidad de las funciones entregadas y la seguridad del sistema global.
Facilidad de uso. Se valora considerando factores humanos, la estética, consistencia y
documentación general.

Factores de calidad ISO 9126. Es reconocida mundialmente como el organismo

certificador de calidad por excelencia, y días bajo el estándar 9126 que define los
siguientes atributos claves de la calidad del software:

 Funcionalidad
 Confiabilidad
 Usabilidad
 Eficiencia
 Facilidad de mantenimiento
 Portabilidad
Al igual que en otros casos los atributos definidos por la iso 9126 son medidas
indirectas una excelente guía para determinar la calidad del software.

Estructura para las métricas técnicas del software.

Conseguir dar valores cuantitativos a las métricas, es necesario establecer un modelo

de medición.

Según Fenton: Desarrollar una métrica única sería semejante a la búsqueda imposible
del santo grial.

Según Shari Pfleeger: Lo mismo que las medidas de temperatura comienzan con un
índice de referencia y evolucionan por sofisticadas escala, herramientas y técnicas, las
medidas del software están evolucionando.

Métricas del Modelo de Análisis. En esta fase es deseable que las métricas técnicas
proporcionen una visión interna a la calidad del modelo de análisis. Estas métricas
examinan el modelo de análisis con la intención de predecir el "tamaño" del sistema
resultante; es probable que el tamaño y la complejidad del diseño estén directamente
relacionadas.

Métricas basadas en la función La métrica del punto de función se puede utilizar

como medio para predecir el tamaño de un sistema obtenido a partir de un modelo de
análisis. Para visualizar esta métrica se utiliza un diagrama de flujo de datos, el cual se
evaluar para determinar las siguientes medidas clave que son necesarias para el
cálculo de la métrica de punto de función:

 Número de entradas del usuario

 Número de salidas del usuario
 Número de consultas del usuario
 Número de archivos
 Número de interfaces externas.

MÉTRICA BANG
Al igual que la métrica de punto de función, la métrica bang puede emplearse para
desarrollar una indicación del tamaño del software a implementar como consecuencia
del modelo de análisis. Desarrollada por DeMarco, la métrica bang es «una indicación
independiente de la implementación del tamaño del sistema». Para calcular la métrica
bang, el desarrollador de software debe evaluar primero un conjunto de primitivas
(elementos del modelo de análisis que no se subdividen más en el nivel de análisis).

Métricas del Modelo del Diseño. Es inconcebible que el diseño de un nuevo avión, un
nuevo chip de computadora o un nuevo edificio de oficinas se realizara sin definir las
medidas del diseño, sin determinar las métricas para varios aspectos de la calidad del
diseño y usarlas para guiar la evolución del diseño. Y sin embargo, el diseño de
sistemas complejos basados en computadora a menudo consigue proseguir sin
virtualmente ninguna medición. La ironía es que las métricas de diseño para el software
están disponibles, pero la gran mayoría de los desarrolladores de software continúan
sin saber que existen. Las métricas de diseño para el software, como otras métricas del
software, no son perfectas. Continúa el debate sobre la eficacia y cómo deberían
aplicarse. Muchos expertos argumentan que se necesita más experimentación hasta
que se puedan emplear las métricas de diseño. Y sin embargo, el diseño sin medición
es una alternativa inaceptable.

Métricas del Código Fuente. La teoría de Halstead de la ciencia del software es

probablemente la mejor conocida y más minuciosamente estudiada. Medidas
compuestas de la complejidad (software). La ciencia del software

Propone las primeras leyes analíticas para el software de computadora. La ciencia del
software asigna leyes cuantitativas al desarrollo del software de computadora, usando
un conjunto de medidas primitivas que pueden obtenerse una vez que se ha generado
o estimado el código después de completar el diseño.

Métricas para Pruebas. Aunque se ha escrito mucho sobre las métricas del software
para pruebas, la mayoría de las métricas propuestas se concentran en el proceso de
prueba, no en las características técnicas de las pruebas mismas. En general, los
responsables de las pruebas deben fiarse de las métricas de análisis, diseño y código
para que les guíen en el diseño y ejecución de los casos de prueba.
Métricas del Mantenimiento. Todas las métricas del software pueden usarse para el
desarrollo de nuevo software y para el mantenimiento del existente. Sin embargo, se
han propuesto métricas diseñadas explícitamente para actividades de mantenimiento.

El estándar EEE 982.1-1988 sugiere un índice de madurez del software (IMS) que
proporciona una indicación de la estabilidad de un producto software (basada en los
cambios que ocurren con cada versión del producto).

PRUEBA DEL SOFTWARE

Los casos de prueba quedarán determinados por los valores a asignar a las entradas
en su ejecución El objetivo es diseñar casos de prueba que, sistemáticamente, saquen
a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y de
esfuerzo. La prueba no puede asegurar la ausencia de errores; sólo puede demostrar
que existen defectos en el software. Pruebas de caja negra: Realizar pruebas de forma
que se compruebe que cada función es operativa.

Pruebas de caja blanca: Desarrollar pruebas de forma que se asegure que la

operación interna se ajusta a las especificaciones, y que todos los componentes
internos se han probado de forma adecuada. El criterio de selección de casos de
prueba buscará cierta cobertura caminos independientes valores de las condiciones
bucles dentro y fuera de sus límites operacionales estructuras de datos los errores se
esconden en los rincones y se acumulan en las fronteras Permiten detectar el
funcionamiento incorrecto o incompleto errores interface errores accesos estructuras
de datos externas problemas de rendimiento errores de inicio y terminación.

 La prueba es un proceso de ejecución de un programa con la intención de

descubrir un error.
 Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un
error no descubierto hasta entonces.
 Una prueba tiene éxito si descubre un error no detectado hasta entonces

Cobertura valores representativos de conjuntos de datos fronteras, valores o

combinaciones de valores conflictivos capacidad de proceso Técnicas de caja negra
Gracias por su atención.
Las pruebas de caja blanca (también conocidas como pruebas de caja de cristal o
pruebas estructurales) se centran en los detalles procedimentales del software, por lo
que su diseño está fuertemente ligado al código fuente. El testeador escoge distintos
valores de entrada para examinar cada uno de los posibles flujos de ejecución del
programa y cerciorarse de que se devuelven los valores de salida adecuados.

Caja Negra. A 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. En otras palabras, de una caja negra nos interesará su forma
de interactuar con el medio que le rodea (en ocasiones, otros elementos que también
podrían ser cajas negras) entendiendo qué es lo que hace, pero sin dar importancia a
cómo lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus
entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los
detalles internos de su funcionamiento.

Partición Equivalente. La partición equivalente es un método de prueba de caja negra

que divide el campo de entrada de un programa en clases de datos de los que se
pueden derivar casos de prueba.. Un caso de prueba ideal descubre de forma
inmediata una clase de errores, que de otro modo requerirían la ejecución de muchos
casos antes de detectar el error genérico. La partición equivalente se dirige a la
definición de casos de prueba que descubran clases de errores, reduciendo así el
número de casos de prueba que hay que desarrollar.

El diseño de casos de prueba para la partición equivalente se basa en una evaluación

de las clases de equivalencia para una condición de entrada. Una clase de equivalencia
representa un conjunto de estados válidos o inválidos para condiciones de entrada.

 Si una condición de entrada especifica un rango, se define una clase de

equivalencia válida y dos inválidas
 Si una condición de entrada requiere un valor específico, se define una clase de
equivalencia válida y dos inválidas.
 Si una condición de entrada especifica un miembro de un conjunto, se define una
clase de equivalencia válida y una inválida.
 Si una condición de entrada es lógica, se define una clase válida y una inválida.
Análisis de valores límite (AVL) Esta técnica complementa a la de partición
equivalente. En lugar de seleccionar cualquier elemento de una clase de equivalencia,
el AVL lleva a la elección de casos de prueba "en los bordes" de la clase. En lugar de
centrarse solamente en las condiciones de entrada, el AVL deriva casos de prueba
también para el campo de salida.

 Si una condición de entrada especifica un rango delimitado por los valores a y b,

se deben diseñar casos de prueba para los valores a y b y para valores justo por
debajo y justo por encima de a y b, respectivamente.
 Si una condición de entrada especifica un número de valores, se deben
desarrollar casos de prueba que ejerciten los valores máximo y mínimo. También
se deben probar los valores justo por debajo del máximo y del mínimo.
 Aplicar las directrices 1 y 2 a las condiciones de salida. Por ej. supongamos que
se requiere una tabla como salida de un programa, entonces se deben diseñar
casos de prueba que creen un informe de salida que produzca el máximo (y el
mínimo) número permitido de entradas en la tabla.
 Si las estructuras de datos internas tienen límites preestablecidos ( Ej. Un arreglo
de 100 entradas) hay que asegurarse de diseñar un caso de prueba que ejercite
la estructura de datos en sus límites.

Estrategias de aplicación de pruebas del software

Una estrategia de prueba del software integra las técnicas de diseño de casos de
prueba en una serie de pasos bien planificados que dan como resultado una correcta
construcción del software. Y lo que es más importante, una estrategia de prueba del
software proporciona un mapa a seguir para el responsable del desarrollo del software,
a la organización de control de calidad y al cliente: un mapa que describe los pasos que
hay que llevar a cabo como parte de la prueba, cuándo se deben planificar y realizar
esos pasos, y cuánto esfuerzo, tiempo y recursos se van a requerir. Por tanto, cualquier
estrategia de prueba debe incorporar la planificación de la prueba, el diseño de casos
de prueba, la ejecución de las pruebas y la agrupación y evaluación de los datos
resultantes.
Una estrategia de prueba del software debe ser suficientemente flexible para promover
la creatividad y la adaptabilidad necesarias para adecuar la prueba a todos los grandes
sistemas basados en software. Al mismo tiempo, la estrategia debe ser suficientemente
rígida para promover un seguimiento razonable de la planificación y la gestión a medida
que progresa el proyecto. Shooman trata estos puntos:

En muchos aspectos, la prueba es un proceso individualista y el número de tipos

diferentes de pruebas varía tanto como los diferentes enfoques de desarrollo. Durante
muchos años, nuestra única defensa contra los errores de programación era un
cuidadoso diseño y la propia inteligencia del programador. Ahora nos encontramos en
una era en la que las técnicas modernas de diseño (y las revisiones técnicas formales)
nos ayudan a reducir el número de errores iniciales que se encuentran en el código de
forma inherente. De forma similar, los diferentes métodos de prueba están empezando
a agruparse en varias filosofías y enfoques diferentes.

Prueba de unidad. La prueba de unidad centra el proceso de verificación en la menor

unidad del diseño del software: el módulo. Usando la descripción del diseño
procedimental como guía, se prueban los caminos de control importantes, con el fin de
descubrir errores dentro del límite del módulo. La complejidad relativa de las pruebas y
de los errores descubiertos está limitada por el alcance estricto establecido por la
prueba de unidad.

Prueba de integración. Un neófito del mundo del software podría, una vez que se les
ha hecho la prueba de unidad a todos los módulos, cuestionar de forma aparentemente
legítima lo siguiente: «Si todos funcionan bien por separado, ¿por qué dudar de que
funcionen todos juntos?». Por supuesto, el problema es ponerlos juntos (interacción).
Los datos se pueden perder en una interfaz; un módulo puede tener un efecto adverso
e inadvertido sobre otro las sub funciones, cuando se combinan, pueden no producir la
función principal deseada; la imprecisión aceptada individualmente puede crecer hasta
niveles inaceptables; y las estructuras de datos globales pueden presentar problemas;
desgraciadamente, la lista sigue y sigue.

La prueba de integración es una técnica sistemática para construir la estructura del

programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar
errores asociados con la interacción. El objetivo es coger los módulos probados en
unidad y construir una estructura de programa que esté de acuerdo con lo que dicta el
diseño.

A menudo hay una tendencia a intentar una integración no incremental; es decir, a

construir el programa mediante un enfoque de big bang. Se combinan todos los
módulos por anticipado. Se prueba todo el programa en conjunto. ¡Normalmente se
llega al caos! Se encuentra un gran conjunto de errores. La corrección se hace difícil,
puesto que es complicado aislar las causas al tener delante el programa entero en toda
su extensión. Una vez que se corrigen esos errores aparecen otros nuevos y el proceso
continúa en lo que parece ser un ciclo sin fin.

La integración incremental. Es la antítesis del enfoque del big bang El programa se

construye y se prueba en pequeños segmentos en los que los errores son más fáciles
de aislar y de corregir, es más probable que se puedan probar completamente las
interfaces y se puede aplicar un enfoque de prueba sistemática. A continuación se
tratan varias estrategias de integración incremental diferentes.

Integración ascendente. La prueba de la integración ascendente, como su nombre

indica, empieza la construcción y la prueba con los módulos atómicos (es decir,
módulos de los niveles más bajos de la estructura del programa). Dado que los
módulos se integran de abajo hacia arriba, el proceso requerido de los módulos
subordinados a un nivel dado siempre está disponibles y se elimina la necesidad de
resguardos.

Se puede implementar una estrategia de integración ascendente mediante los

siguientes pasos:

 Se combinan los módulos de bajo nivel en grupos (a veces denominados

construcciones) que realicen una sub función específica del software.
 Se escribe un controlador (un programa de control de la prueba) para coordinar
la entrada y la salida de los casos de prueba.
 Se prueba el grupo.
  Se eliminan los controladores y se combinan los grupos moviéndose hacia arriba
por la estructura del programa.

La integración sigue el esquema ilustrado en la Figura 8. Se combinan los módulos

para formar los grupos 1, 2 y 3. Cada uno de los grupos se somete a prueba mediante
un controlador (mostrado como un bloque punteado).

A medida que la integración progresa hacia arriba, disminuye la necesidad de

controladores de prueba diferentes. De hecho, si los dos niveles superiores de la
estructura del programa se integran de forma descendente, se puede reducir
sustancialmente el número de controladores y se simplifica enormemente la integración
de grupos.

Integración descendente. La integración descendente es un planteamiento

incremental a la construcción de la estructura de programas. Se integran los módulos
moviéndose hacia abajo por la jerarquía de control, comenzando por el módulo de
control principal (programa principal). Los módulos subordinados (de cualquier modo
subordinados) al módulo de control principal se van incorporando en la estructura, bien
de forma primero-en profundidad o bien de forma primero en anchura.

La estrategia de integración descendente verifica los puntos de decisión o de control

principales al principio del proceso de prueba. En una estructura de programa bien
fabricada, la toma de decisiones se da en los niveles superiores de la jerarquía y, por
tanto, se encuentran antes. Si existen problemas generales de control, es esencial
reconocerlos cuanto antes. Si se selecciona la integración primero-en-profundidad, se
puede ir implementando y demostrando las funciones completas del software. Por
ejemplo, considere una estructura de transacción clásica en la que se requiere una
compleja serie de entradas interactivas, obtenidas y validadas por medio de un camino
de entrada. Ese camino de entrada puede ser integrado en forma descendente. Así, se
puede demostrar todo el proceso de entradas (para posteriores operaciones de
transacción) antes de que se integren otros elementos de la estructura. La
demostración anticipada de las posibilidades funcionales es un generador de confianza
tanto para el desarrollador como para el cliente.
La estrategia descendente parece relativamente fácil, pero en la práctica, pueden surgir
algunos problemas logísticos. El más común de estos problemas se da cuando se
requiere un proceso de los niveles más bajos de la jerarquía para poder probar
adecuadamente los niveles superiores. Al principio de la prueba descendente, los
módulos de bajo nivel se reemplazan por resguardos; por tanto, no pueden fluir datos
significativos hacia arriba por la estructura del programa. El responsable de la prueba
tiene tres opciones: (1) retrasar muchas de las pruebas hasta que los resguardos sean
reemplazados por los módulos reales; (2) desarrollar resguardos que realicen funciones
limitadas que simulen los módulos reales; o (3) integrar el software desde el fondo de la
jerarquía hacia arriba. La Figura 10.7 ilustra varias clases de resguardos típicas, desde
la más simple (resguardo A) hasta la más compleja (resguardo D).

El primer enfoque (retrasar pruebas hasta reemplazar los resguardos por los módulos
reales) hace que perdamos cierto control sobre la correspondencia de ciertas pruebas
específicas con la incorporación de determinados módulos. Esto puede dificultar la
determinación de las causas del error y tiende a violar la naturaleza altamente
restrictiva del enfoque descendente. El segundo enfoque es factible pero puede llevar a
un significativo incremento del esfuerzo a medida que los resguardos se hagan más
complejos. El tercer enfoque, denominado prueba ascendente, se estudia a
continuación.

Prueba de validación. Tras la culminación de la prueba de integración, el software

está completamente ensamblado como un paquete; se han encontrado y corregido los
errores de interfaz y puede comenzar una serie final de pruebas del software: la prueba
de validación. La validación puede definirse de muchas formas, pero una simple
(aunque vulgar) definición es que la validación se consigue cuando el software funciona
de acuerdo con las expectativas razonables del cliente.

Las expectativas razonables están definidas en la especificación de requisitos del

software un documento que describe todos los atributos del software visibles para el
usuario. La especificación contiene una sección denominada Criterios de validación. La
información contenida en esa sección forma la base del enfoque a la prueba de
validación.
Prueba del sistema. Al principio, pusimos énfasis en el hecho de que el software es
sólo un elemento de un sistema mayor basado en computadora. Finalmente, el
software es incorporado a otros elementos del sistema (p. ej.: nuevo hardware,
información) y realizan una serie de pruebas de integración del sistema y de validación.
Estas pruebas caen fuera del ámbito del proceso. de ingeniería del software y no las
realiza únicamente el desarrollador del software. Sin embargo, los pasos dados durante
el diseño del software y durante la prueba pueden mejorar enormemente la probabilidad
de éxito en la integración del software en el sistema.

Un problema típico de la prueba del sistema es la «delegación de culpabilidad». Esto

ocurre cuando se descubre un error y cada uno de los creadores de cada elemento del
sistema echa la culpa del problema a los otros. En vez de verse envuelto en esta
absurda situación, el ingeniero del software debe anticiparse a los posibles problemas
de interacción y: (1) diseñar caminos de manejo de errores que prueben toda la
información procedente de otros elementos del sistema; (2) llevar a cabo una serie de
pruebas que simulen la presencia de datos en mal estado o de otros posibles errores
en la interfaz del software; (3) registrar los resultados de las pruebas como «evidencia»
en el caso de que se le señale con el dedo; (4) participar en la planificación y el diseño
de pruebas del sistema para asegurarse de que el software se prueba de forma
adecuada.

La prueba del sistema, realmente, está constituida por una serie de pruebas diferentes
cuyo propósito primordial es ejercitar profundamente el sistema basado en
computadora. Aunque cada prueba tiene un propósito diferente, todas trabajan para
verificar que se han integrado adecuadamente todos los elementos del sistema y que
realizan las funciones apropiadas.

Prueba de recuperación. Muchos sistemas basados en computadora deben

recuperarse de los fallos y continuar el proceso en un tiempo previamente especificado.
En algunos casos, un sistema debe ser tolerante con los fallos; es decir, los fallos del
proceso no deben hacer que cese el funcionamiento de todo el sistema.

En otros casos, se debe corregir un fallo del sistema en un determinado periodo de

tiempo para que no se produzca un serio daño económico.
La prueba de recuperación es una prueba del sistema que fuerza el fallo del software
de muchas formas y verifica que la recuperación se lleva a cabo apropiadamente. Si la
recuperación es automática (llevada a cabo por el propio sistema) hay que evaluar la
corrección de la inicialización, de los mecanismos de recuperación del estado del
sistema, de la recuperación de datos y del proceso arranque. Si la recuperación
requiere la intervención humana, hay que evaluar los tiempos medios de reparación
para determinar si están dentro de unos límites aceptables.

Prueba de seguridad. Cualquier sistema basado en computadora que maneje

información sensible o lleve a cabo acciones que puedan perjudicar o beneficiar
impropiamente a las personas es un posible objetivo para entradas al sistema
impropias o ilegales. Este acceso al sistema incluye un amplio rango de actividades:
«piratas informáticos» que intentan entrar en los sistemas por deporte, empleados
disgustados que intentan penetrar por venganza e individuos deshonestos que intentan
penetrar para obtener ganancias personales ilícitas.

La prueba de seguridad intenta verificar que los mecanismos de protección

incorporados en el sistema lo protegerán, de hecho, de accesos impropios.

Durante la prueba de seguridad, el responsable de la prueba desempeña el papel de un

individuo que desea entrar en el sistema. ¡Todo vale! Debe intentar conseguir las claves
de acceso por cualquier medio, puede atacar al sistema con software a medida,
diseñado para romper cualquier defensa que se haya construido, debe bloquear el
sistema, negando así el servicio a otras personas, debe producir a propósito errores del
sistema, intentando acceder durante la recuperación o debe curiosear en los datos sin
protección, intentando encontrar la clave de acceso al sistema, etc. Con tiempo y
recursos suficientes, una buena prueba de seguridad terminará por acceder en el
sistema. El papel del diseñador del sistema es hacer que el coste de la entrada ilegal
sea mayor que el valor de la información obtenida.

Prueba de resistencia. Las pruebas de resistencia están diseñadas para enfrentar a

los programas con situaciones anormales. En esencia, el sujeto que realiza la prueba
de resistencia se pregunta: ¿A qué potencia puedo ponerlo a funcionar antes de que
falle?
La prueba de resistencia ejecuta un sistema de forma que demande recursos en
cantidad, frecuencia o volúmenes anormales. Por ejemplo: (1) diseñar pruebas
especiales que generen diez interrupciones por segundo, cuando las normales son una
o dos; (2) incrementar las frecuencias de datos de entrada en un orden de magnitud
con el fin de comprobar cómo responden las funciones de entrada; (3) ejecutar casos
de prueba que requieran el máximo de memoria o de otros recursos; (4) diseñar casos
de prueba que puedan dar problemas en un sistema operativo virtual o (5) diseñar
casos de prueba que produzcan excesivas búsquedas de datos residentes en disco.
Esencialmente, el responsable de la prueba intenta romper el programa.

Una variante de la prueba de resistencia es una técnica denominada prueba de

sensibilidad. En algunas situaciones (la más común se da con algoritmos matemáticos),
un rango de datos muy pequeño dentro de los límites de una entrada válida para un
programa puede producir un proceso exagerado e incluso erróneo o una profunda
degradación del rendimiento. Esta situación es análoga a una singularidad en una
función matemática. La prueba de sensibilidad intenta descubrir combinaciones de
datos dentro de una clase de entrada válida que pueda producir inestabilidad o un
proceso incorrecto.

Prueba de rendimiento Para sistemas de tiempo real y sistemas empotrados, es

inaceptable el software que proporciona las funciones requeridas pero no se ajusta a
los requisitos de rendimiento. La prueba de rendimiento está diseñada para probar el
rendimiento del software en tiempo de ejecución dentro del contexto de un sistema
integrado. La prueba de rendimiento se da durante todos los pasos del proceso de la
prueba. Incluso al nivel de unidad, se debe asegurar el rendimiento de los módulos
individuales. pruebas de caja blanca. Sin embargo, hasta que no están completamente
integrados todos los elementos del sistema no se puede asegurar realmente el
rendimiento del sistema.

Las pruebas de rendimiento, a menudo, van emparejadas con las pruebas de

resistencia y, frecuentemente, requieren instrumentación tanto de software como de
hardware. Es decir, muchas veces es necesario medir la utilización de recursos (p. ej.:
ciclos de procesador), de un modo exacto. La instrumentación externa puede
monitorizar los intervalos de ejecución, los sucesos ocurridos (p. ej.: interrupciones) y
muestras de los estados de la máquina en un funcionamiento normal. Instrumentando
un sistema, el encargado de la prueba puede descubrir situaciones que lleven a
degradaciones y posibles fallos del sistema.

El arte de la depuración. La prueba del software es un proceso que puede planificarse

y especificarse sistemáticamente. Se puede llevar a cabo el diseño de casos de prueba,
se puede definir una estrategia y se pueden evaluar los resultados en comparación con
las expectativas prescritas.

La depuración ocurre como consecuencia de una prueba efectiva. Es decir, cuando un

caso de prueba descubre un error, la depuración es el proceso que provoca la
eliminación del error. Aunque la depuración puede y debe ser un proceso ordenado,
sigue teniendo mucho de arte. Un ingeniero del software, al evaluar los resultados de
una prueba, se encuentra frecuentemente con una indicación «sintomática» de un
problema en el software. Es decir, la manifestación externa de un error, y la causa
interna del error pueden no estar relacionados de una forma obvia. El proceso mental,
apenas comprendido, que conecta un síntoma con una causa es la depuración.

El proceso de depuración. La depuración no es una prueba, pero siempre ocurre

como consecuencia de la prueba. Como se muestra en la Figura 10.9, el proceso de
depuración comienza con la ejecución de un caso de prueba. Se evalúan los resultados
y aparece una falta de correspondencia entre los esperados y los encontrados
realmente. En muchos casos, los datos que no concuerdan son un síntoma de una
causa subyacente que todavía permanece oculta. El proceso de depuración intenta
hacer corresponder el síntoma con una causa, llevando así a la corrección del error.

El proceso de depuración siempre tiene uno de los dos resultados siguientes: (1) se
encuentra la causa, se corrige y se elimina; o (2) no se encuentra la causa. En este
último caso, la persona que realiza la depuración debe sospechar la causa, diseñar un
caso de prueba que ayude a confirmar sus sospechas y el trabajo vuelve hacia atrás a
la corrección del error de una forma iterativa.
Las pruebas de software. Son las investigaciones empíricas y técnicas cuyo objetivo
es proporcionar información objetiva e independiente sobre la calidad del producto a la
parte interesada o stakeholder. Es una actividad más en el proceso de control de
calidad.

Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de

software. Dependiendo del tipo de pruebas, estas actividades podrán ser
implementadas en cualquier momento de dicho proceso de desarrollo. Existen distintos
modelos de desarrollo de software, así como modelos de pruebas. A cada uno
corresponde un nivel distinto de involucramiento en las actividades de desarrollo.

Conclusiones

Las medidas y las métricas que podemos construir con ellas son fundamentales para
tener datos palpables con los que hacer estimaciones, ya sean de recursos o de costes,
en Ingeniería del Software.