ESTANDARES DE LA CALIDAD DEL SOFTWARE

JULIO CSAR FLREZ ARTEAGA

LEDALIZ QUROZ GARCA

IX SEMESTRE

EVALUACIN DE SOFTWARE

FERNANDO DAZA ILLERA

INGENIERIA DE SISTEMAS

UNIVERSIDAD DE CARTAGENA
SEDE - LORICA
30 / 09 / 2015

Qu es la ISO 8402?
Es un complemento de la serie de normas ISO 9000. En ella se definen trminos
relacionados con la calidad.
La norma ISO 8402 define los trminos bsicos y fundamentales relacionados con
los conceptos de la calidad, aplicables a todos los campos.
Es un complemento de la serie de normas ISO 9000. En ella se definen trminos
relacionados con la calidad. Clarifica y normaliza los trminos relativos a la calidad
que sean aplicables al campo de la gestin de la calidad. La necesidad de utilizar
una terminologa normalizada para evitar malentendidos o confusiones, oblig al
desarrollo de una norma auxiliar que precisara trminos y conceptos.

ISO/ IEC 15939

ISO / IEC 15939, Ingeniera de Software - Proceso de Medicin del Software es
una norma internacional que define un proceso de medicin para el desarrollo de
software e ingeniera de sistemas. La norma se describe en trminos de los
efectos y los resultados de un proceso conforme, junto con las actividades y tareas
asociadas. La norma tambin define el modelo de informacin de medicin y
terminologa asociada. La norma ISO / IEC 15939 cubre las actividades de
medicin, la informacin requerida, la aplicacin de los resultados del anlisis de
la medida, y determinar si los resultados del anlisis son vlidos. La norma puede
ser utilizada por los proveedores y compradores de sistemas.

Calidad del producto de software ISO/IEC 9126

ISO/IEC 9126: Es un estndar internacional para la evaluacin del software. Est
supervisado por el proyecto SQuaRE, ISO 25000:2005, el cual sigue los mismos
conceptos. El estndar est dividido en cuatro partes las cuales dirigen,

respectivamente, lo siguiente: modelo de calidad, mtricas externas, mtricas

internas y calidad en las mtricas de uso.

Evaluacin de productos de software Norma ISO/IEC 14598

ISO/IEC 14598: Norma para la evaluacin del producto software. Esta norma
comprende las siguientes seis partes que especifican el proceso a seguir para
evaluar software: ISO/IEC 14598-1 Visin general; ISO/IEC 14598-2 Planificacin
y Gestin; SO/IEC 14598-3 Procedimiento para desarrolladores; ISO/IEC 14598-4
Procedimiento

para

compradores;

ISO/IEC

14598-5,

Procedimiento

para

evaluadores; ISO/IEC 14598-6 Documentacin de los mdulos de evaluacin.

ISO/IEC 15504
El ISO/IEC 15504, tambin conocido como Software Process Improvement
Capability Determinacin, abreviado SPICE, en espaol, Determinacin de la
Capacidad de Mejora del Proceso de Software es un modelo para la mejora y
evaluacin de los procesos de desarrollo y mantenimiento de sistemas de
informacin y productos de software.
ISO/IEC 25000 SquaRE (Software product Quality REquirements)
ISO/IEC 25000: Especificacin de requerimientos de calidad del software y
evaluacin de la calidad del software, soportada por el proceso de medicin de
calidad del software.
Es una nueva serie de normas que se basa en ISO 9126 y en ISO 14598
(Evaluacin del software). Uno de los principales objetivos de la serie SQuaRE es
la coordinacin y armonizacin del contenido de ISO 9126 y de ISO 15939:2002
(Measurement Information Model). ISO 15939 tiene un modelo de informacin que
ayuda a determinar que se debe especificar durante la planificacin, performance
y evaluacin de la medicin. Para su aplicacin, cuenta con los siguientes pasos:
Recopilar los datos, Preparacin de los datos y Anlisis de los datos.
SQuaRE incluye un estndar de requerimientos de calidad. Est compuesto por
14 documentos agrupados en 5 tpicos: Administracin de la Calidad 2500n,
Modelo de Calidad 2501n, Medidas de Calidad 2502n, Requerimientos de
Calidad 2503n y Evaluacin de la Calidad 2504n.

Modelo de Madurez de Capacidad para el Software (Capahility Maturity

Model, CMM),
Este modelo y el cuestionario culminaron en agosto de 1991 en la versin 1.0 del
Modelo de Madurez de Capacidad para el Software (Capahility Maturity Model,
CMM). Utilizando este modelo como base, el SEI comercializ dos mtodos para
determinar la madurez del proceso software de una empresa:
Evaluacin del Proceso Software y Valoracin de la Capacidad Software. La
versin 1.1 del CMM public en febrero de 1993 junto con la actualizacin del
mtodo SCE (v.2.0) para que estuviese alineado con la versin 1.1 del CMM.
Muchas empresas han modificado el mtodo SPA para alinearlo con la versin 1.1
del CMM; una de estas empresas ha sido el Instituto para la Mejora del Proceso
Software que ha propuesto el mtodo de Evaluacin Enfocado en la Accin. En
mayo de 1995, el SEI actualiz el SPA, denominndose mtodo de Evaluacin
basada en el CMM para la Mejora Interna del Proceso v.1.0 (CMMBased Appraisal
for Internal Process Improvemnent, CBA IPI). Se generaron nuevas versiones ms
consistentes del CBA IPI y de SCE en abril de 1996 donde se utilizan
aproximaciones comunes para interpretar el CMM y para recoger y analizar los
datos. Actualmente, se encuentra disponible el CMMI, que recoge aspectos tanto
del CMM como de ISO/IEC 15504.

MTRICAS DEL SOFTWARE

MEDIDAS DIRECTAS: Dentro de estas se pueden incluir: el costo y el esfuerzo
aplicado, Las lneas de cdigo producidas (LCD), La velocidad reejecucin, el
tamao de la memoria y los defectos informados durante un periodo de tiempo
establecido.
METRICAS INDIRECTAS: Dentro de estas estn la funcionalidad, La calidad, La
complejidad, La eficiencia, la Fiabilidad, La facilidad de uso y La facilidad de
mantenimiento.

METRICAS ORIENTADAS AL TAMAO: Provienen de la normalizacin de las

medidas de calidad y/o productividad considerando el tamao del software que se
haya producido, los datos registrados se muestran en la siguiente tabla:

Tabla de registro de datos de mtricas orientadas al tamao.

Teniendo en cuenta los datos de la tabla anterior, se puede derivar otras mtricas
para comparar varios proyectos. Por ejemplo: Errores por KLDC (miles de lneas
de cdigo), Defectos por KLDC, Pginas de documentacin por KLDC, Errores por
persona/mes, LDC por persona/mes, Costo ($) por pgina de documentacin.
MTRICAS ORIENTADAS A LA FUNCIN: Las mtricas del software orientadas a

la funcin permiten la medida de la funcionalidad de la aplicacin. Esta mtrica fue

propuesta busca identificar los factores crticos que determinan el tamao del
software y por consiguiente, estimar el esfuerzo y el costo para desarrollarlo. De
aqu nace la tcnica de anlisis de puntos de funcin, que mide una aplicacin con
base en las funciones que ste realiza por solicitud del usuario final.
Los puntos de funcin se obtienen utilizando una funcin emprica basado en
medidas cuantitativas del dominio de informacin del software y valoraciones
subjetivas de la complejidad del software.
MTRICAS DE CALIDAD DEL SOFTWARE
El objetivo de la Ingeniera de Software es desarrollar y producir software de alta
calidad y para lograrlo es fundamental aplicar mtodos y herramientas efectivos
dentro del contexto de un proceso de desarrollo de software. Dentro de las
medidas de calidad del software estn:
Correccin: Es el grado en el que el software cumple su funcin, la medida ms
comn es: Defectos por KDLC (miles de lneas de cdigo).
Facilidad de mantenimiento: es la facilidad con la que se puede corregir un
programa si se encuentra un error. Se utiliza medidas indirectas como: Tiempo

medio de cambio (TCM), que es el tiempo que tarda en: Analizar una peticin,
disear una modificacin, Implementar un cambio o Probar y realizar un cambio.
Integridad: mide la capacidad del software para resistir ataques. Se define como,
Integridad= Sumatoria [(1-amenaza)*(1-seguridad)], para ello se debe tener en
cuenta los siguientes atributos: Amenaza que es la probabilidad de que un ataque
ocurra en un tiempo determinado, y la seguridad que es la probabilidad de que se
pueda repeler el ataque de un tipo determinado.
Facilidad de Uso: Mide la amigabilidad del software con el usuario final. Se mide
en funcin de: Habilidad intelectual o fsica para aprender el sistema, el tiempo
requerido para hacer uso eficiente del sistema, Aumento de la productividad y la
valoracin subjetiva de la disposicin de los usuarios hacia el sistema.
Eficacia de la eliminacin de defectos: La eficacia de la eliminacin de defectos
(EED), es una mtrica que permite medir la habilidad de filtrar las actividades de la
garanta de calidad y de control, ya que es aplicable a todas las actividades del
marco de trabajo del proceso. Se definen de la siguiente forma:
EED= E/ (E+ D), donde E es el nmero de errores encontrados antes de la
entrega del software y D es el nmero de defectos encontrados despus de la
entrega. El valor ptimo de EED es 1, que significa que no se han encontrado
defectos en el software.
MTRICAS TCNICAS DEL SOFTWARE
Las mtricas tcnicas para el software proporcionan una manera sistemtica de
valorar la calidad basndose en un conjunto de reglas. Tambin proporcionan al
ingeniero del software descubrir y corregir problemas potenciales antes de que se
conviertan en defectos catastrficos.
Factores de calidad de McCall
McCall y Cavano definieron un juego de factores de calidad como los primeros
pasos hacia el desarrollo de mtricas de la calidad del software. Estos factores
evalan el software desde tres puntos de vista distintos: Operacin del producto,
Revisin del producto y Transicin del producto.

FACTORES DE CALIDAD DE MCCALL

Mtricas para el esquema de puntuacin
Las mtricas pueden ir en forma de lista de comprobacin para evaluar y puntuar
atributos especficos del software. La puntuacin va en una escala del O (bajo) al
10 (alto).
Mtricas del modelo de Calidad FURPS
El modelo de MCCall ha servido de base para modelos de calidad posteriores, y
este es el caso del modelo FURPS, producto del desarrollo de Hewlett-Packard.
En este modelo se desarrollan un conjunto de factores de calidad de software,
bajo el acrnimo de FURPS.
F Functionality - funcionalidad
R Usability usabilidad facilidad de uso
R Realiability confiabilidad
P Performance desempeo
S supportability-capacidad de soporte.
Factores de calidad ISO 9126
El estndar ISO/IEC 9126 ha sido desarrollado en un intento de identificar los
atributos clave de calidad para un producto de software. Este estndar es una
simplificacin del Modelo de McCalI, e identifica seis caractersticas bsicas de
calidad que pueden estar presentes en cualquier producto de software.
Las mtricas ISO / IEC 9126 no son necesariamente usados para mediciones
directas, pero proveen una valiosa base para medidas indirectas, y una excelente
lista para determinar la calidad de un sistema.
Estructura para las mtricas tcnicas del software
Es importante establecer una estructura fundamental y un conjunto de principios
bsicos para la medicin de mtricas tcnicas para el software.

Los principios que se pueden asociar con la formulacin de las mtricas tcnicas
son los siguientes: Los objetivos de la medicin que deben establecerse antes de
empezar la recoleccin de datos, Todas las tcnicas sobre mtricas deben
definirse sin ambigedades, Las mtricas deberan obtenerse basndose en una
teora vlida para el dominio de aplicacin, Hay que hacer las mtricas a medida
para acomodar mejor los productos y procesos especficos.
Roche sugiere los siguientes principios para la recoleccin y anlisis de datos:
Siempre que sea posible, la recogida de datos y el anlisis debe automatizarse,
Se deben aplicar tcnicas estadsticas vlidas para establecer las relaciones entre
los atributos internos del producto y las caractersticas externas de la calidad, Se
deben establecer directrices de interpretacin y recomendaciones para todas las
mtricas.
Mtricas del Modelo de Anlisis
En esta fase, las mtricas tcnicas proporcionan una visin interna a la calidad del
modelo de anlisis. Estas mtricas examinan el modelo de anlisis con la
intencin de predecir el tamao del sistema resultante; es probable que el
tamao y la complejidad del diseo estn directamente relacionados. Dentro de
las mtricas del modelo de anlisis tenemos:
Mtricas basadas en la Funcin: La mtrica del punto de funcin se utiliza como
medio para predecir el tamao de un sistema obtenido a partir de un modelo de
anlisis. Para visualizar esta mtrica se utiliza un diagrama de flujo de datos, el
cual se evaluar para determinar las siguientes medidas clave que son necesarias
para el clculo de a mtrica de punto de funcin: Nmero de entradas del usuario,
Nmero de salidas del usuario, Nmero de consultas del usuario, Nmero de
archivos, Nmero de interfaces externas.
Mtrica Bang
Puede aplicarse para desarrollar una indicacin del tamao del software a
implementar como consecuencia del modelo del anlisis. Para calcular la mtrica
Bang, el desarrollador de software evala primero un conjunto de primitivas. Las
primitivas se determinan evaluando el modelo de anlisis y desarrollando cuentas.

Mtricas del Modelo de Diseo

Se concentran en las caractersticas de la arquitectura del programa, con nfasis
en la estructura arquitectnica y en la eficiencia de los mdulos. Estas mtricas
son de caja negra en el sentido que no requieren ningn conocimiento del trabajo
interno de un mdulo en particular del sistema. Card y Glass definen las siguientes
tres medidas de complejidad:
La complejidad estructural, S (i), de un mdulo i se define de a siguiente manera:
S (i)=f2 out(i) Donde fout(i) es la expansin del mdulo i. La expansin indica el
nmero de mdulos que son invocados directamente por el mdulo i. La
complejidad del sistema, C (i), se define como la suma de las complejidades
estructural y de datos C (i)= S (i) + D (i). La complejidad de datos, D (i),
proporciona una indicacin de la complejidad en la interfaz interna de un mdulo y
se define como: D (i)=v(i)/[fout(i) + 1]. Donde v(i) es el nmero de variables de
entrada y salida que entran y salen del mdulo i. Fenton sugiere varias mtricas
de morfologa simples que permiten comparar diferentes arquitecturas mediante
un conjunto de dimensiones directas.
Las mtricas a aplicar son:
Tamao= n + a. Donde n es el nmero de nodos (mdulos) y a es el nmero de
arcos (lneas de control). Para la arquitectura mostrada se tiene tamao=
17+18=35.
Profundidad= camino ms largo desde el nodo raz a un nodo hoja. Para el
ejemplo Profundidad= 4
Amplitud=nmero mximo de nados de cualquier nivel de la arquitectura. Para el
ejemplo amplitud= 6
Relacin arco a nodo, r=a/n, mide la densidad de conectividad de la arquitectura
y proporciona una indicacin sencilla de acoplamiento de la arquitectura. Para el
ejemplo r=18/17= 1.06
Mtricas del cdigo fuente

Utiliza un conjunto de medidas primitivas que pueden obtenerse una vez que se
han generado o estimado el cdigo despus de completar el diseo. Estas
medidas son:
n1: nmero de operadores diferentes que aparecen en el programa.
N2: nmero de operandos diferentes que aparecen en el programa.
N1: nmero total de veces que aparece el operador.
N2: nmero total de veces que aparecen el operando.
Halstead utiliza medidas primitivas para desarrollar expresiones par la longitud
global del programa; volumen mnimo potencial para un algoritmo; el volumen real
(nmero de bits requeridos para especificar un programa); el nivel del programa
(una medida de la complejidad del software); nivel del lenguaje (una constante
para un lenguaje dado); y otras caractersticas tales como el esfuerzo de
desarrollo, tiempo de desarrollo e incluso el nmero esperado de fallos en el
software.
Halstead propone las siguientes mtricas:
Longitud N se puede estimar como: N = n1 log2 n1 + n2 log2 n2
Volumen de programa se define como: V = N n1 log2 (n1 + n2).
Tomando en cuenta que V variar con el lenguaje de programacin y representa el
volumen de informacin (en bits) necesarios para especificar un programa.
Mtricas para Pruebas
Las mtricas para pruebas se concentran en el proceso de prueba, no en las
caractersticas tcnicas de las pruebas mismas. En general, los responsables de
las pruebas deben fiarse en las mtricas de anlisis, diseo y cdigo para que
sirvan de gua en el diseo y ejecucin de los casos de prueba. El esfuerzo de las
pruebas tambin se puede estimar utilizando mtricas obtenidas de las medidas
de Halstead. Usando la definicin del volumen de un programa, y, y nivel de
programa, NP, el esfuerzo de la ciencia del software puede calcularse como:
NP = 1/[(n1/2) x (N2/n2)) (Ec. 1) e = V/NP (Ec. 2)
El porcentaje del esfuerzo global de pruebas a asignar a un mdulo k se puede
estimar utilizando la siguiente relacin:

Porcentaje de esfuerzo de pruebas (k) = e(k)/ Se(i) (Ec. 3)

Donde e(k) se calcula para el mdulo k utilizando las ecuaciones (Ec. 1) y
(Ec. 2) la suma en el denominador de la ecuacin (Ec. 3) es la suma del esfuerzo
de la ciencia del software a lo largo de todos los mdulos del sistema. A medida
que se van haciendo las pruebas, tres medidas diferentes proporcionan una
indicacin de la complecin de las pruebas:

Mtricas del Mantenimiento

Todas las mtricas descritas pueden utilizarse para el desarrollo de nuevo
software y para el mantenimiento del existente. El estndar IEEE 982.1-1988
sugiere el ndice de madurez del software (IM_) que proporciona una indicacin de
la estabilidad de un producto software basada en los cambios que ocurren con
cada versin del producto. Con el IM_ se determina a siguiente informacin:
MT= Nmero de mdulos en la versin
Actual Fc = Nmero de mdulos en la versin actual que se han cambiado
Fa= Nmero de mdulos en a versin actual que se han aadido
Fe= Nmero de mdulos en la versin actual que se han eliminado
El ndice de madurez del software se calcula de la siguiente manera;
IM_= [MT - (Fc + Fa + Fe)]I/MT
A medida que el IM_ se aproxima a 1 el producto se empieza a estabilizar.
El IM_ puede emplearse tambin como mtrica para la planificacin de las
actividades de mantenimiento del software.
La prueba del software
Indiscutiblemente la prueba es una actividad fundamental en los procesos de
desarrollo de software. La prueba de software permite al desarrollador determinar
si el producto generado satisface las especificaciones que han sido establecidas
en el diseo. As mismo, una prueba de software permite detectar la presencia de

errores que pudieran generar salidas o comportamientos inapropiados durante su

ejecucin.
Tcnicas de diseo de casos de prueba
El objetivo de las tcnicas de diseo de casos de prueba es el de conseguir una
confianza aceptable en que se detectarn los defectos existentes sin consumir una
cantidad excesiva de recursos. Toda la disciplina de pruebas debe moverse en un
equilibrio entre la disponibilidad de recursos y la confianza que aportan los casos
para descubrir los defectos existentes.
La idea fundamental para el diseo de casos de prueba consiste en la eleccin de
algunas posibilidades de funcionamiento del software que por sus caractersticas,
se consideren representativas del resto. As si no se detectan defectos en el
software al ejecutar dichos casos, se puede tener un cierto nivel de confianza en
que el programa no tiene defectos. La dificultad de esta idea es saber elegir los
casos que se deben ejecutar. De hecho, una eleccin puramente aleatoria no
proporciona demasiada confianza en que se puedan detectar todos los defectos
existentes.
Pruebas de caja blanca
Prueba que se enfoca en la estructura interna de un componente.
Las pruebas de caja blanca enfocan su atencin a los detalles
procedimentales del software, por ello la implementacin de estas pruebas
depende fuertemente de la disponibilidad de cdigo fuente. Este tipo de
pruebas, permiten generar casos para ejercitar y validar los caminos de
cada mdulo, las condiciones lgicas, los bucles y sus lmites, as como
tambin para las estructuras de datos.

Pruebas de caja negra

Prueba que se enfoca en el comportamiento de entrada/salida de un

componente sin considerar su implementacin.

Estas

son

conocidas

como

pruebas

funcionales

pruebas

de

comportamiento, concentran la atencin en generar casos de prueba que

permitan ejercitar los requisitos funcionales de un programa. A diferencia de
las pruebas de caja blanca, que se basan en la lgica interna del software,
este tipo de pruebas se concentran en su funcionalidad, por lo que mucho
del trabajo se realiza interactuando con la interfaz del software.
Particiones o clases de equivalencia: Utiliza las cualidades que definen un buen
caso de prueba de la siguiente manera: Cada caso debe cubrir el mximo nmero
de entradas, debe tratarse el dominio de valores de entrada dividido en un nmero
finito de clases de equivalencia donde la prueba de un valor representativo de una
clase permite suponer que el resultado obtenido ser el mismo que el obtenido
probando cualquier otro valor de la clase.
El mtodo de diseo de casos consiste en la identificacin de clases de
equivalencia y la creacin de los casos de prueba correspondientes. Para
identificar las posibles clases de equivalencia de un programa a partir de su
especificacin deben seguirse los siguientes pasos: primero, la identificacin de Ia
condiciones de entradas al programa, Segundo, a partir de ellas, se identifican
clases de equivalencia que pueden ser de datos vlidos o de datos no vlidos o
errneos.
Anlisis de Valores Lmite (AVL): Mediante la experiencia, se ha podido
constatar que los casos de prueba que exploran las condiciones lmite de un
programa producen un mejor resultado pura la deteccin de defectos, es decir, es
ms probable que los defectos del software se acumulen en estas condiciones. Se

puede definir las condiciones lmite como las situaciones que se hallan
directamente arriba, abajo y en los mrgenes de las clases de equivalencia.
Conjetura de errores: Esta tcnica consiste en enumerar una lista de errores
posibles que pueden cometer los desarrolladores o de situaciones propensas a
ciertos errores. Despus se generan casos de prueba en base a dicha lista que
suelen corresponder con defectos que aparecen comnmente y no con aspectos
funcionales. No existen directrices eficaces que puedan ayudar a generar este tipo
de casos, lo nico que se puede hacer es presentar algunos ejemplos que reflejan
esta tcnica.
Pruebas Aleatorias: En las pruebas aleatorias se simula la entrada habitual del
programa creando datos para introducir en l que sigan la secuencia y la
frecuencia con las que podran aparecer en la prctica diaria, de forma continua,
sin descanso. Esto implica usar herramientas denominadas generadores de
pruebas a las que se alimenta con una descripcin de datos y secuencias de
entradas posibles as como una estimacin de probabilidad de ocurrir cada una de
ellas en el uso real. Si el proceso de generacin de pruebas se ha realizado
correctamente, se crearn todas las posibles entradas del programa en todas las
combinaciones posibles, aunque no sea necesario hacer esto para una prueba
adecuada. Tambin se puede conseguir, indicando la distribucin estadstica que
siguen, que la frecuencia de entrada para orientar correctamente nuestras pruebas
hacia aquello que es ms probable que suceda en la prctica real.
Estrategias de aplicacin de pruebas del software
Una estrategia de prueba integra las tcnicas de diseo de casos de prueba en un
conjunto de pasos bien planeados que dan como resultado la correcta
construccin del software. Una estrategia de prueba de software proporciona una
gua para los desarrolladores del software, para la organizacin de control de
calidad y para el cliente. Por tanto una estrategia de software debe incorporar la
planificacin de la prueba, el diseo de casos de prueba, la ejecucin de pruebas
y la agrupacin y evaluacin de los datos resultantes.

Prueba de unidad: La prueba de unidad centra el proceso de verificacin en la

menor unidad del diseo del software. Aqu se prueban los caminos de control
importantes, con el fin de descubrir errores dentro del mbito de un mdulo. La
complejidad relativa de las pruebas y errores descubiertos se encuentra limitada
por los lineamientos establecidos por la prueba de software.
Pruebas de integracin
Las pruebas de integracin estn totalmente ligadas a la forma prevista de integrar
los distintos componentes del software hasta contar con el producto global que
debe entregarse. As, las pruebas de integracin implican una progresin
ordenada de pruebas que parte desde los componentes y que culmina en el
sistema completo. Su objetivo fundamental es la prueba de las interfaces entre
componentes o mdulos.
La prueba de Integracin es una tcnica sistemtica para construir la estructura
del programa mientras que al mismo tiempo, se llevan a cabo pruebas para
detectar errores asociados con la interaccin. El objetivo es tomar los mdulos
probados en unidad y estructurar un programa que est de acuerdo con lo que
dicta el diseo.
Existen 2 tipos de integracin, la primera es no incremental en donde se intenta
elaborar software en mdulos grandes, en otros casos un slo mdulo, pero en
ellos es ms difcil aislar los errores y cuando alguno de ellos es corregido produce
otros errores. El segundo tipo de integracin es incremental en donde se
desarrollan mdulos pequeos y funcionales que hacen que los errores sean ms
fcil de aislar y corregir, es ms probable que se puedan probar completamente
las interfaces y aplicar un enfoque de prueba sistemtico.
Integracin incremental ascendente: El proceso empieza combinando primero
los mdulos de ms bajo nivel en grupos que realizan alguna subfuncin
especfica, donde se busca reducir el nmero de pasos de integracin. Luego se
describe para cada grupo un mdulo impulsor o conductor, que es un mdulo que
permite simular la llamada a los mdulos, introducir los datos de prueba a travs
de los parmetros de llamada y recoger los resultados a travs de los de salida.

Posteriormente, se prueba cada grupo empleando su impulsor y por ltimo se

eliminan los mdulos impulsores de cada grupo y se sustituyen por los mdulos
del nivel superior de la jerarqua.
Integracin Incremental Descendente: La integracin incremental descendente
comienza con el mdulo de control principal y va incorporando mdulos
subordinados progresivamente. No existe un procedimiento general para
determinar cul de los mdulos subordinados posibles es mejor incorporar
primero, es decir, no se puede dar una regla general que permita determinar la
secuencia ptima de incorporacin de mdulos. Hay que estudiar en cada caso
cul es el mejor orden de incorporacin para minimizar el esfuerzo o para lograr
una mejor organizacin. La siguiente figura muestra la integracin incremental
descendente.
Integracin no incremental: En este tipo de integracin cada mdulo requiere de
los siguientes elementos para ser probado:

Un mdulo impulsor, que transmite o impulsa los datos de prueba al mdulo

y muestra los resultados de dichos casos de prueba.

Uno o ms mdulos ficticios que simulan la funcin de cada mdulo
subordinado llamado por el mdulo que se va a probar.

Prueba del sistema

La prueba del sistema es el proceso de prueba de un sistema integrado de
hardware y software para comprobar si cumple los requisitos especificados, es
decir: Cumplimiento de todos los requisitos funcionales, considerando el producto
software final al completo, en un entorno de sistema, El funcionamiento y
rendimiento en las interfaces hardware, software, de usuario y de operador,
adecuacin de la documentacin de usuario, Ejecucin y rendimiento en
condiciones lmite y de sobrecarga.
Los casos para la prueba del sistema tienen tres fuentes principales para su
diseo: Casos basados en los requisitos gracias a tcnicas de caja negra
aplicadas a las especificaciones, Casos necesarios para probar el rendimiento del
sistema y de su capacidad funcional (pruebas de volumen de datos, de lmites de

procesamiento, etc.), Casos basados en el diseo de alto nivel aplicando tcnicas

de caja blanca aplicadas a los flujos de datos de alto nivel (por ejemplo, de los
diagramas de flujo de datos).
Prueba de Aceptacin: El objetivo de esta prueba es comprobar si el producto

est listo para ser implantado para el uso operativo en el entorno del usuario. Si la
prueba del sistema determin la capacidad real del sistema y permiti a la
organizacin de desarrollo tener confianza en que estaba listo para su
funcionamiento, la prueba de aceptacin es la prueba planificada y organizada
formalmente para determinar si se cumplen los requisitos de aceptacin marcados
por el cliente.
Las caractersticas principales de esta prueba son las siguientes:
Participacin del usuario, se enfoca hacia la prueba de los requisitos de usuario
especificados, es la fase final del proceso para crear una confianza en que el
producto es el apropiado para su uso en explotacin.

Prueba de validacin y verificacin

La definicin de Verificacin y Validacin envuelve lo que se conoce como calidad
del software, en donde los mtodos de anlisis, de diseo y de implementacin
actan para mejorar la calidad al proporcionar tcnicas continuas y resultados
predecibles. Las revisiones tcnicas formales de inspeccin ayudan a asegurar la
calidad la calidad de los productos, a lo largo del proceso la medicin y el control
se aplican sobre cada elemento de una configuracin del software. La prueba
constituye un elemento importante para evaluar la calidad y de descubrir los
errores. Cabe mencionar que la prueba no se debe contemplar como una red de
seguridad. La aplicacin adecuada de los mtodos y de las herramientas, las
revisiones tcnicas formales efectivas y una slida gestin y medida, conducen a
la calidad, que se confirma durante la prueba.
Prueba del sistema

La prueba del sistema tiene la finalidad de verificar que se hayan integrado

correctamente cada uno de los elementos del sistema. Comprende las siguientes
pruebas:
Prueba de Recuperacin: La prueba de recuperacin es una prueba que se hace
al sistema forzando a que produzca fallas de software de muchas maneras y
verificando que la recuperacin se lleve a cabo, ya sea automticamente o
manual, tomando en cuenta los recursos que se requieran para efectuar la
recuperacin.
Prueba de Seguridad: La prueba de seguridad intenta verificar la aplicacin de
los mecanismos de proteccin incorporados en el sistema. Durante la prueba el
encargado de la prueba desempea el papel de intruso tratando de violar la
seguridad del sistema, intentando obtener las claves de acceso por cualquier
medio externo; debe bloquear el sistema, negando as el servicio a otras personas
adems de producir errores a propsito en el sistema; o debe curiosear los datos
pblicos intentando encontrar una clave de acceso al sistema.
Prueba de Resistencia: La prueba de resistencia est diseada para enfrentar a
los programas en situaciones anormales, es decir ejecutar el sistema en forma que
demande recursos en cantidad, frecuencia o volmenes anormales.
El encargado de la prueba debe intentar colapsar el sistema y para lograrlo se
puede tomar en consideracin lo siguiente: Disear pruebas especiales que
generen 10 o ms interrupciones por segundo, Incrementar las frecuencias de
datos de entrada en un orden de magnitud con el fin de comprobar cmo
responden las funciones de entrada, Ejecutar casos de prueba que requieran al
mximo de memoria o de espacio en disco, Disear casos de prueba que
produzcan excesivas bsquedas de datos almacenados en disco.
Depuracin
La depuracin aparece como resultado de una prueba efectiva, es decir, cuando
en un caso de prueba se encuentra un error, la depuracin es el proceso que
resulta en la eliminacin de un error. Se debe tomar en cuenta que la depuracin

no es una tcnica de prueba, aunque siempre se da como consecuencia de la

prueba. En la siguiente figura se muestra que el proceso de depuracin comienza
en los casos de prueba, se evalan los resultados y resulta una falta de
correspondencia entre los esperados y los reales, el proceso de depuracin
intenta hacer corresponder el sistema con una causa, llevando as a la correccin
del error.
Prueba de software para objetos
El software construido a partir del modelo orientado a objetos tambin requiere ser
sometido a pruebas con el propsito de garantizar su calidad. En trminos
generales, se puede decir que los dos enfoques ms representativos en materia
de pruebas, de caja blanca y de caja negra, son aplicables al software orientado a
objetos en cierta medida. Sin embargo, existen algunas caractersticas del
software orientado a objetos que generan problemas adicionales no cubiertos por
las tcnicas tradicionales de prueba.
La unidad bsica para la prueba de software orientado a objetos es la clase.
A pesar de ello, cuando se prueba al software orientado a objetos, no es posible
realizar una prueba para una clase por s misma, sino que hay que realizarla para
una instancia de sta, es decir para un objeto.
Mtodos de prueba de software orientado a objetos.
Muchas de las generalidades de los mtodos de prueba tradicionales han sido
adaptadas considerando las caractersticas del modelo orientado a objetos, con el
propsito de que puedan ser aplicables en este nuevo contexto. Actualmente, existen
muy pocas investigaciones sobre el estudio de prueba de software orientado a
objetos; ya que el rea de prueba de software es bastante compleja y dentro de este
marco de objetos existe una carencia de mtodos robustos para garantizar la
realizacin de las pruebas de forma eficaz. En este panorama se presenta el estado
actual en cuanto a prueba de software orientado a objetos en trminos del nivel de
prueba.

Pruebas de unidad

En el software orientado a objetos la menor unidad a considerar para realizar una

prueba es la clase. La prueba de clases en el mbito de software Orientado a
Objetos es equivalente a la prueba de unidad realizada al software tradicional.
Esta prueba est fundamentalmente dirigida a las operaciones encapsuladas por
la clase, as como al estado y comportamiento del objeto que se implementa en
ella. El nfasis de la prueba de unidad es verificar que esta pequea unidad
trabaje correctamente en forma aislada, antes de proceder a integrarla en el
sistema.
Pruebas de integracin.
Cuando se aplican pruebas de integracin al software orientado a objetos, se
pretende demostrar que las unidades que ya han sido sometidas a un proceso de
prueba y funcionan correctamente, lo hacen de igual forma cuando interactan y
se integran con otras unidades del sistema. Prcticamente, el trabajo de esta
prueba se concentra en la interaccin de mtodos en diferentes unidades.
Pruebas de sistema.
Las pruebas de unidad se concentran en verificar si las funcionalidades descritas
en las especificaciones o en los requisitos iniciales corresponden a las que se
presentan en el producto final. En esta rea, al igual que la de pruebas de
integracin, se han generado pocos trabajos, por lo que se emplean muchos de
los mtodos tradicionales.
Prueba de software basado en componentes.
La construccin de software a partir de componentes es una prctica
relativamente nueva, por lo que no es extrao que sea escasa la existencia de
trabajos generados al respecto. Puesto que el desarrollo basado en componentes
presenta algunas similitudes con el enfoque orientado a objetos, para un
componente pueden ser aplicables algunas de sus consideraciones, incluso en
materia de prueba. Aspectos como la herencia, encapsulacin, polimorfismo, liga
dinmica o mecanismos de comunicacin, son comunes entre ambos modelos. Es
evidente que para hacer las pruebas de componentes ms robustas, ser
necesario considerar las caractersticas propias del enfoque de componentes.

Pruebas de unidad.
Aunque la realizacin de pruebas de unidad es una actividad que en algn
momento es llevada a cabo por el desarrollador, existe un marco de trabajo
adicional a considerar: el de la persona que se interesa en el componente con el
fin de integrarlo en sus sistemas.
Actualmente son pocos los trabajos en materia de pruebas de unidad para
componentes, dos sobresalientes en este ramo son el proyecto Trusted
Components y el Proyecto Kimera, aunque este ltimo no est dirigido totalmente
a componentes, sino a la seguridad de las mquinas virtuales de Java cada vez
que se carga una clase.
Pruebas de integracin.
Si las pruebas de nivel de unidad para componentes muestran severas carencias,
en nivel de integracin, al igual que en otros enfoques de desarrollo, las carencias
son an ms notables. Sin embargo, existen coincidencias en cuanto a las
problemticas comunes al integrar componentes:
El volumen y la lentitud: Cuando se utilizan componentes dentro de un sistema,
no siempre se utilizan todas sus capacidades, lo que hace que cierta parte del
cdigo no sea necesario. Este problema se agrava cuando se tienen sistemas
grandes, afectndose as su rendimiento.
Los mecanismos de comunicacin utilizados: Se han presentado algunas
contrariedades e inconsistencias al utilizar dentro de un mismo sistema varios
mecanismos de comunicacin como eventos, mensajes o bien el paso de
parmetros.