7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
1/31
Qu es la ISO 8402?
Es un complemento de la serie de normas ISO 9000.
En ella se definen trminos relacionados con la calidad.
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. !a necesidad de utilizar
una terminolog"a normalizada para evitar malentendidos o confusiones# oblig al
desarrollo de una norma au$iliar que precisara trminos y conceptos.
!a norma ISO %&0' define los trminos b(sicos y fundamentales relacionados con
los conceptos de la calidad# aplicables a todos los campos.
ISO/ IEC 15939
ISO ) IEC *+9,9# Ingenier"a de Soft-are /roceso de edicin del Soft-are es
una norma internacional que define un proceso de medicin para el desarrollo de
soft-are e ingenier"a de sistemas. !a norma se describe en trminos de los
efectos y los resultados de un proceso conforme# 1unto con las actividades y tareas
asociadas. !a norma tambin define el modelo de informacin de medicin y
terminolog"a asociada. !a norma ISO ) IEC *+9,9 cubre las actividades de
medicin# la informacin requerida# la aplicacin de los resultados del an(lisis de
la medida# y determinar si los resultados del an(lisis son v(lidos. !a norma puede
ser utilizada por los proveedores y compradores de sistemas.
CALIDAD DEL PRODUCTO DE SOFTWARE ISO/IEC 9126
!a norma ISO)IEC 9*'2 presentan dos modelos de calidad# el primero referido a lacalidad interna y e$terna y el segundo modelo referido a la calidad en uso#
Esta norma Internacional fue publicada en *99'# la cual es usada para la
evaluacin de la calidad de soft-are# llamado 3Informacin de productos de
tecnolog"a de soft-are caracter"sticas evaluacin de calidad y directrices para su
uso45 o tambin conocido como ISO 9*'2 6o ISO)IEC 9*'27. Este est(ndar
https://es.wikipedia.org/wiki/ISO_9000https://es.wikipedia.org/wiki/ISO_90007/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
2/31
describe 2 caracter"sticas generales8 uncionalidad# Confiabilidad# :sabilidad#
Eficiencia# antenibilidad# y /ortabilidad.
!a norma ISO)IEC 9*'2 permite especificar y evaluar la calidad del soft-are
desde diferentes criterios asociados con adquisicin# requerimientos# desarrollo#
uso# evaluacin# soporte# mantenimiento# aseguramiento de la calidad y auditoria
de soft-are.
EVALUACIN DE PRODUCTOS DE SOFTWARE NOR!A ISO"IEC #4$%8
!a norma ISO)IEC *&+9% es un est(ndar que proporciona un marco de traba1o
para evaluar la calidad de todo tipo de producto soft-are e indica los requisitos
para los mtodos de medicin y el proceso de evaluacin# proporcionando
mtricas y requisitos para los procesos de evaluacin# a travs de 2 etapas.
ISO"IEC #4$%8isin
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
3/31
A'()*)+a+es,6Organizacin# /laneamiento# Especificaciones# >ise?o# onta1e7
ISO"IEC #4$%8&4 P./'es/ +e '/1a.a+/.es,!o utilizan las
organizaciones que pretenden comparar o re@usar un producto de soft-are
e$istente# se aplica con el propsito de aceptacin de un producto.
A'()*)+a+es, 6Aequerimientos# Especificacin evaluacin# >ise?o evaluacin#
E1ecucin evaluacin7.
ISO"IEC #4$%8&$ P./'es/ e*alua+/.es8 este proceso es utilizado por
organizaciones encargadas de evaluar# provee los requisitos y gu"as para la
evaluacin del producto soft-are. /romueve las siguientes caracter"sticas
de proceso 6repetible# Aeproducible5 Imparcial# Ob1etivo7
A'()*)+a+es,6Brazabilidad# Aesultados# /roblemas# e1oras# Conclusiones7
ISO"IEC #4$%8& !/+ul/ e*alua')3,Especifica las mediciones que van a
ser tomadas sobre los atributos de calidad que se definieron en la etapa
anterior# provee las gu"as para la documentacin de la evaluacin.
A'()*)+a+es,6Introduccin# =lcance# Entradas# Aesultados7
La N/.a ISO$%8proporciona un marco de traba1o para evaluar la calidad de
todos los tipos de soft-are# indicando los requisitos que ser(n medidos#
y analizados en este proceso. Implementar est(ndares que garanticen una
correcta evaluacin al soft-are y mitigar los errores que pueda presentar cundo se
est e1ecutando.
ISO"IEC #$$04
El ISO"IEC #$$04# tambin conocido como Soft-are /rocess ImprovementCapability >eterminacin# abreviado S/ICE# en espa?ol# >eterminacin de
la Capacidad de e1ora del /roceso de Soft-areD es un modelo para la
me1ora y evaluacin de los procesos de desarrollo y mantenimiento de
sistemas de informacin y productos de soft-are.
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
4/31
La /.a ISO #$$04 SPICEes una norma abierta e internacional para
evaluar y me1orar la capacidad y madurez de los procesos. unto con la ISO
*''0F# la norma aplica a la evaluacin y me1ora de la calidad del proceso
de desarrollo y mantenimiento de soft-are.
ISO"IEC 2$000 S5uaRE 6S/7(a.e 1./+u'( Qual)(9 RE5u).ee(s:
ISO)IEC '+000# conocida como SGuaAE (System and Soft-are Guality
Aequirements and Evaluation), es una familia de normas que tiene por ob1etivo la
creacin de un marco de traba1o comHn para evaluar la calidad del producto
soft-are.
!a familia ISO)IEC '+000 es el resultado de la evolucin de otras normas
anteriores# especialmente de las normas ISO)IEC 9*'2# que describe las
particularidades de un modelo de calidad del producto soft-are# e ISO)IEC *&+9%#
que abordaba el proceso de evaluacin de productos soft-are. Esta familia de
normas ISO)IEC '+000 se encuentra compuesta por cinco divisiones.
ISO"IEC 2$00 D)*)s)3 +e ;es()3 +e Cal)+a+
!as normas que forman este apartado definen todos los modelos# trminos y
definiciones comunes referenciados por todas las otras normas de la familia
'+000. =ctualmente esta divisin se encuentra formada por8
ISO)IEC '+000
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
5/31
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
6/31
ISO"IEC 2$0# D)*)s)3 +e !/+el/ +e Cal)+a+
!as normas de este apartado presentan modelos de calidad detallados incluyendo
caracter"sticas para calidad interna# e$terna y en uso del producto soft-are.
=ctualmente esta divisin se encuentra formada por8
ISO)IEC '+0*0 System and soft-are quality models8 describe el modelo
de calidad para el producto soft-are y para la calidad en uso. Esta orma
presenta las caracter"sticas y subcaracter"sticas de calidad frente a las cuales
evaluar el producto soft-are.
ISO)IEC '+0*' >ata Guality model8 define un modelo general para la
calidad de los datos# aplicable a aquellos datos que se encuentranalmacenados de manera estructurada y forman parte de un Sistema de
Informacin.
ISO"IEC 2$02 D)*)s)3 +e !e+)')3 +e Cal)+a+
Estas normas incluyen un modelo de referencia de la medicin de la calidad del
producto# definiciones de medidas de calidad 6interna# e$terna y en uso7 y gu"as
pr(cticas para su aplicacin. =ctualmente esta divisin se encuentra formada por8
ISO)IEC '+0'0 easurement reference model and guide8 presenta una
e$plicacin introductoria y un modelo de referencia comHn a los elementos de
medicin de la calidad. Bambin proporciona una gu"a para que los usuarios
seleccionen o desarrollen y apliquen medidas propuestas por normas ISO.
ISO)IEC '+0'* Guality measure elements8 define y especifica un con1unto
recomendado de mtricas base y derivadas que puedan ser usadas a lo largode todo el ciclo de vida del desarrollo soft-are.
ISO)IEC '+0'' easurement of quality in use8 define espec"ficamente las
mtricas para realizar la medicin de la calidad en uso del producto.
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
7/31
ISO)IEC '+0', easurement of system and soft-are product quality8
define espec"ficamente las mtricas para realizar la medicin de la calidad de
productos y sistemas soft-are.
ISO)IEC '+0'& easurement of data quality8 define espec"ficamente las
mtricas para realizar la medicin de la calidad de datos.
ISO"IEC 2$0- D)*)s)3 +e Re5u)s)(/s +e Cal)+a+
!as normas que forman este apartado ayudan a especificar requisitos de calidad
que pueden ser utilizados en el proceso de elicitacin de requisitos de calidad del
producto soft-are a desarrollar o como entrada del proceso de evaluacin. /ara
ello# este apartado se compone de8
ISO)IEC '+0,0 Guality requirements8 provee de un con1unto de
recomendaciones para realizar la especificacin de los requisitos de calidad
del producto soft-are.
ISO"IEC 2$04 D)*)s)3 +e E*alua')3 +e Cal)+a+
Este apartado incluye normas que proporcionan requisitos# recomendaciones ygu"as para llevar a cabo el proceso de evaluacin del producto soft-are. Esta
divisin se encuentra formada por8
ISO)IEC '+0&0 Evaluation reference model and guide8 propone un modelo
de referencia general para la evaluacin# que considera las entradas al
proceso de evaluacin# las restricciones y los recursos necesarios para
obtener las correspondientes salidas.
ISO)IEC '+0&* Evaluation guide for developers# acquirers and
independent evaluators8 describe los requisitos y recomendaciones para la
implementacin pr(ctica de la evaluacin del producto soft-are desde el punto
de vista de los desarrolladores# de los adquirentes y de los evaluadores
independientes.
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
8/31
ISO)IEC '+0&' Evaluation modules8 define lo que la orma considera un
mdulo de evaluacin y la documentacin# estructura y contenido que se debe
utilizar a la @ora de definir uno de estos mdulos.
ISO)IEC '+0&+ Evaluation module for recoverability8 define un mdulo
para la evaluacin de la subcaracter"sticas Aecuperabilidad 6Aecoverability7.
!a divisin de e$tensin de SGuaAE 6ISO)IEC '+0+0 a ISO)IEC '+0997 se reserva
para normas o informes tcnicos que aborden dominios de aplicacin espec"ficos
o que puedan ser utilizados para complementar otras normas de la familia
SGuaAE.
Modelo de Madurez de Caa!"dad ara el So#$%are &Caa'"l"$(
Ma$ur"$( Model) CMM*)
!entro de estas se pueden incluir8 el costo y el esfuerzo
aplicado# !as l"neas de cdigo producidas 6!C>7# !a velocidad ree1ecucin# el
tama?o de la memoria y los defectos informados durante un periodo de tiempo
establecido.
!ETRICAS INDIRECTAS, >entro de estas est(n la funcionalidad# !a calidad# !a
comple1idad# !a eficiencia# la iabilidad# !a facilidad de uso y !a facilidad de
mantenimiento.
!ETRICAS ORIENTADAS AL TA!A=O, /rovienen de la normalizacin de las
medidas de calidad y)o productividad considerando el tama?o del soft-are que se
@aya producido# los datos registrados se muestran en la siguiente tabla8
Babla de registro de datos de mtricas orientadas al tama?o.
Beniendo en cuenta los datos de la tabla anterior# se puede derivar otras mtricas
para comparar varios proyectos. /or e1emplo8 Errores por J!>C 6miles de l"neas
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
9/31
de cdigo7# >efectos por J!>C# /(ginas de documentacin por J!>C# Errores por
persona)mes# !>C por persona)mes# Costo 6K7 por p(gina de documentacin.
!entro de las
medidas de calidad del soft-are est(n8
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
10/31
C/..e'')38 Es el grado en el que el soft-are cumple su funcin# la medida m(s
comHn es8 >efectos por J>!C 6miles de l"neas de cdigo7.
Fa')l)+a+ +e a(e))e(/8 es la facilidad con la que se puede corregir un
programa si se encuentra un error. Se utiliza medidas indirectas como8 Biempo
medio de cambio 6BC7# que es el tiempo que tarda en8 =nalizar una peticin#
dise?ar una modificacin# Implementar un cambio o /robar y realizar un cambio.
I(e@.)+a+, mide la capacidad del soft-are para resistir ataques. Se define como#
IntegridadL Sumatoria M6*amenaza7N6*seguridad7# para ello se debe tener en
cuenta los siguientes atributos8 =menaza 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.
Fa')l)+a+ +e Us/, ide la amigabilidad del soft-are con el usuario final. Se mideen funcin de8 Pabilidad intelectual o f"sica para aprender el sistema# el tiempo
requerido para @acer uso eficiente del sistema# =umento de la productividad y la
valoracin sub1etiva de la disposicin de los usuarios @acia el sistema.
E7)'a')a +e la el))a')3 +e +e7e'(/s, !a eficacia de la eliminacin de defectos
6EE>7# es una mtrica que permite medir la @abilidad de filtrar las actividades de la
garant"a de calidad y de control# ya que es aplicable a todas las actividades del
marco de traba1o del proceso. Se definen de la siguiente forma8
EE>L E) 6EQ >7# donde E es el nHmero de errores encontrados antes de la
entrega del soft-are y > es el nHmero de defectos encontrados despus de la
entrega. El valor ptimo de EE> es *# que significa que no se @an encontrado
defectos en el soft-are.
!
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
11/31
cCall y Cavano definieron un 1uego de factores de calidad como los primeros
pasos @acia el desarrollo de mtricas de a calidad del soft-are. Estos factores
evalHan el soft-are desde tres puntos de vista distintos8 Operacin del producto#
Aevisin del producto y Bransicin del producto. = continuacin se muestran los
factores de calidad de cCall# las caracter"sticas asociadas y la definicin de cada
una de ellas8
FACTORES DE CALIDAD DE !CCALL
!
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
12/31
!(.)'as 1a.a el es5uea +e 1u(ua')3
!(.)'as +el /+el/ +e Cal)+a+ FURPS
El modelo de CCall @a servido de base para modelos de calidad posteriores# y
este es el caso del modelo :A/S# producto del desarrollo de Pe-lett/acRard.
En este modelo se desarrollan un con1unto de factores de calidad de soft-are#
ba1o el acrnimo de :A/S. unctionality funcionalidad
A :sability usabilidad facilidad de uso
A Aealiability confiabilidad
/ /erformance desempe?o
S supportabilitycapacidad de soporte.
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
13/31
!a siguiente tabla# presenta la clasificacin de los atributos de calidad que se
incluyen en el modelo# 1unto con las caracter"sticas asociadas a cada uno de ellos8
!(.)'as +el /+el/ +e Cal)+a+ FURPS
Fa'(/.es +e 'al)+a+ ISO %#2El est(ndar ISO)IEC 9*'2 @a sido desarrollado en un intento de identificar los
atributos clave de calidad para un producto de soft-are. Este est(ndar es una
simplificacin del odelo de cCalI# e identifica seis caracter"sticas b(sicas de
calidad que pueden estar presentes en cualquier producto de soft-are. El
est(ndar provee una descomposicin de las caracter"sticas en subcaracter"sticas#
que se muestran en la siguiente tabla8
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
14/31
Ta>la, Ca.a'(e.s()'as 9 Su>'a.a'(e.s()'as /+el/ ISO"IEC %#2
!as mtricas ISO ) IEC 9*'2 no son necesariamente usados para mediciones
directas# pero proveen una valiosa base para medidas indirectas# y una e$celente
lista para determinar la calidad de un sistema.
ESTRUCTURA PARA LAS !
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
15/31
empezar la recoleccin de datos# Bodas las tcnicas sobre mtricas deben
definirse sin ambigTedades# !as mtricas deber"an obtenerse bas(ndose en una
teor"a v(lida para el dominio de aplicacin# Pay que @acer las mtricas a medida
para acomodar me1or los productos y procesos espec"ficos.
Aoc@e sugiere los siguientes principios para la recoleccin y an(lisis de datos8
Siempre que sea posible# la recogida de datos y el an(lisis debe automatizarse#
Se deben aplicar tcnicas estad"sticas v(lidas para establecer las relaciones entre
los atributos internos del producto y las caracter"sticas e$ternas de la calidad# Se
deben establecer directrices de interpretacin y recomendaciones para todas las
mtricas.
!(.)'as +el !/+el/ +e Al)s)s
En esta fase# las mtricas tcnicas proporcionan una visin interna a la calidad del
modelo de an(lisis. Estas mtricas e$aminan el modelo de an(lisis con la
intencin de predecir el 3tama?o4 del sistema resultante5 es probable que el
tama?o y la comple1idad del dise?o estn directamente relacionados. >entro de
las mtricas del modelo de an(lisis tenemos8
!(.)'as >asa+as e la Fu')3, !a mtrica del punto de funcin se utiliza como
medio para predecir el tama?o de un sistema obtenido a partir de un modelo de
an(lisis. /ara visualizar esta mtrica se utiliza un diagrama de flu1o de datos# el
cual se evaluar para determinar las siguientes medidas clave que son necesarias
para el c(lculo de a mtrica de punto de funcin8 Hmero de entradas del usuario#
Hmero de salidas del usuario# Hmero de consultas del usuario# Hmero de
arc@ivos# Hmero de interfaces e$ternas.
!(.)'a Ba@
/uede aplicarse para desarrollar una indicacin del tama?o del soft-are a
implementar como consecuencia del modelo del an(lisis. /ara calcular la mtrica
Uang# el desarrollador de soft-are evalHa primero un con1unto de primitivas. !as
primitivas se determinan evaluando el modelo de an(lisis y desarrollando cuentas
para los siguientes elementos de la tabla8
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
16/31
Ta>la, !(.)'a Ba@
!(.)'as +el !/+el/ +e D)se/
Se concentran en las caracter"sticas de la arquitectura del programa# con nfasis
en la estructura arquitectnica y en la eficiencia de los mdulos. Estas mtricas
son de ca1a negra en el sentido que no requieren ningHn conocimiento del traba1o
interno de un mdulo en particular del sistema. Card y
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
17/31
V Bama?oL n Q a. >onde n es el nHmero de nodos 6mdulos7 y a es el nHmero de
arcos 6l"neas de control7. /ara la arquitectura mostrada se tiene tama?oL
*FQ*%L,+.
V /rofundidadL camino m(s largo desde el nodo ra"z a un nodo @o1a. /ara el
e1emplo /rofundidadL &
V =mplitudLnHmero m($imo de nados de cualquier nivel de la arquitectura. /ara el
e1emplo amplitudL 2
V Aelacin arco a nodo# rLa)n# mide la densidad de conectividad de la arquitectura
y proporciona una indicacin sencilla de acoplamiento de la arquitectura. /ara el
e1emplo rL*%)*FL *.02
!
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
18/31
!(.)'as 1a.a P.ue>as
!as mtricas para pruebas se concentran en el proceso de prueba# no en las
caracter"sticas tcnicas de as pruebas mismas. En general# los responsables de
las pruebas deben fiarse en las mtricas de an(lisis# dise?o y cdigo para que
sirvan de gu"a en el dise?o y e1ecucin de los casos de prueba. El esfuerzo de las
pruebas tambin se puede estimar utilizando mtricas obtenidas de las medidas
de Palstead. :sando la definicin del volumen de un programa# y# y nivel de
programa# /# el esfuerzo de la ciencia del soft-are puede calcularse como8
/ L *)M6n*)'7 $ 6')n'77 6Ec. *7 e L ;)/ 6Ec. '7
El porcenta1e del esfuerzo global de pruebas a asignar a un mdulo R se puede
estimar utilizando la siguiente relacin8
/orcenta1e de esfuerzo de pruebas 6R7 L e6R7) Se6i7 6Ec. ,7
>onde e6R7 se calcula para el mdulo R utilizando las ecuaciones 6Ec. *7 y
6Ec. '7 la suma en el denominador de la ecuacin 6Ec. ,7 es la suma del esfuerzo
de la ciencia del soft-are a lo largo de todos los mdulos del sistema. = medida
que se van @aciendo las pruebas# tres medidas diferentes proporcionan una
indicacin de la complecin de las pruebas8
Ta>la, !e+)+as +e C/1le')3 +e 1.ue>as!(.)'as +el !a(e))e(/
Bodas las mtricas descritas pueden utilizarse para el desarrollo de nuevo
soft-are y para el mantenimiento del e$istente. El est(ndar IEEE 9%'.**9%%
sugiere el "ndice de madurez del soft-are 6IW7 que proporciona una indicacin de
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
19/31
la estabilidad de un producto soft-are basada en los cambios que ocurren con
cada versin del producto. Con el IW se determina a siguiente informacin8
BL Hmero de mdulos en la versin
=ctual c L Hmero de mdulos en la versin actual que se @an cambiado
aL Hmero de mdulos en a versin actual que se @an a?adido
eL Hmero de mdulos en la versin actual que se @an eliminado
El "ndice de madurez del soft-are se calcula de la siguiente manera5
IWL MB 6c Q a Q e7I)B
= medida que el IW se apro$ima a * el producto se empieza a estabilizar.
El IW puede emplearse tambin como mtrica para la planificacin de las
actividades de mantenimiento del soft-are.
LA PRUEBA DEL SOFTWARE
Indiscutiblemente la prueba es una actividad fundamental en los procesos de
desarrollo de soft-are. !a prueba de soft-are permite al desarrollador determinar
si el producto generado satisface las especificaciones que @an sido establecidas
en el dise?o. =s" mismo# una prueba de soft-are permite detectar la presencia de
errores que pudieran generar salidas o comportamientos inapropiados durante su
e1ecucin.
Te @ec@o# una eleccin puramente aleatoria no
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
20/31
proporciona demasiada confianza en que se puedan detectar todos los defectos
e$istentes.
P.ue>as +e 'aa >la'a
!as pruebas de ca1a blanca enfocan su atencin a los detalles procedimentales del
soft-are# por ello la implementacin de estas pruebas depende fuertemente de la
disponibilidad de cdigo fuente. Este tipo de pruebas# permiten generar casos para
e1ercitar y validar los caminos de cada mdulo# las condiciones lgicas# los bucles
y sus l"mites# as" como tambin para las estructuras de datos.
!as pruebas inician con la observacin de que un programa dif"cilmente puede
considerarse como probado por completo si su cdigo contiene partes que nunca
@an sido e1ecutadas. Este mtodo analiza la estructura lgica del programa y# para
cada alternativa que puede presentarse# los datos de prueba ideados conducir(n a
ella. Se procura escoger los que verifiquen cada posibilidad en las proposiciones
case# las cl(usulas de cada proposicin if y la condicin de terminacin de cada
ciclo.
P.ue>a +e 'aa >la'a
!as pruebas de ca1a blanca tambin son conocidas como pruebas de ca1a de
cristal o pruebas estructurales. =lgunas de las pruebas m(s significativas dentro
de este enfoque son mostradas en la siguiente tabla8
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
21/31
Ta>la, P.ue>as +e Caa Bla'a
PRUEBAS DE CAA NE;RA
Estas son conocidas como pruebas funcionales o pruebas de comportamiento#
concentran la atencin en generar casos de prueba que permitan e1ercitar los
requisitos funcionales de un programa. = diferencia de las pruebas de ca1a blanca#
que se basan en la lgica interna del soft-are# este tipo de pruebas se concentran
en su funcionalidad# por lo que muc@o del traba1o se realiza interactuando con la
interfaz del soft-are. !os casos de prueba generados en este enfoque# se dise?ana partir de valores entrada y salida. >e esta forma# se puede determinar la validez
de una salida para un con1unto de entradas proporcionadas.
!os datos de prueba se escoger(n atendiendo a las especificaciones del
problema# sin importar los detalles internos del programa# a fin de verificar que el
programa corra bien. !os criterios m"nimos que guiar(n al escoger los datos de
prueba8
Val/.es F')les8 El programa se depurar( con datos de f(cil comprobabilidad.
Val/.es (1)'/s .eal)s(as8 Se ensayar( un programa con datos seleccionados
para que representen como se aplicar(. !os >atos deben ser sencillos# de modo
que los resultados sean verificables en forma manual.
Val/.es e(.e/s / Val/.es )le@ales8 Cuando en un programa entra basura# su
salida @abr( de ser un mensa1e de error adecuado. Es preferible que el programa
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
22/31
ofrezca indicacin de errores en la entrada y que realice c(lculos que sigan siendo
factibles luego de desec@ar la entrada equivocada.
Pa.()')/es / 'lases +e e5u)*ale')a, :tiliza las cualidades que definen un buen
caso de prueba de la siguiente manera8 Cada caso debe cubrir el m($imo nHmero
de entradas# >ebe tratarse el dominio de valores de entrada dividido en un nHmero
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 dise?o de casos consiste en la identificacin de clases de
equivalencia y la creacin de los casos de prueba correspondientes. /ara
identificar las posibles clases de equivalencia de un programa a partir de su
especificacin deben seguirse los siguientes pasos8 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 v(lidos o de datos no v(lidos o
errneos.
Al)s)s +e Val/.es L)(e 6AVL:, ediante la e$periencia# se @a podido
constatar que los casos de prueba que e$ploran las condiciones l"mite de un
programa producen un me1or resultado pura la deteccin de defectos# es decir# es
m(s probable que los defectos del soft-are se acumulen en estas condiciones. Se
puede definir las condiciones l"mite como las situaciones que se @allan
directamente arriba# aba1o y en los m(rgenes de las clases de equivalencia.
C/e(u.a +e e../.es, Esta tcnica consiste en enumerar una lista de errores
posibles que pueden cometer los desarrolladores o de situaciones propensas a
ciertos errores. >espusse generan casos de prueba en base a dic@a lista que
suelen corresponder condefectos que aparecen comHnmente y no con aspectos
funcionales. o e$istendirectrices eficaces que puedan ayudar a generar este tipo
de casos# lo Hnico quese puede @acer es presentar algunos e1emplos que refle1an
esta tcnica.
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
23/31
P.ue>as Alea(/.)as, En las pruebas aleatorias se simula la entrada @abitual del
programa creando datos para introducir en l que sigan la secuencia y la
frecuencia con lasque podr"an aparecer en la pr(ctica diaria# de forma continua#
sin descanso. Esto implica usar @erramientas 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 @a realizado
correctamente# secrear(n todas las posibles entradas del programa en todas las
combinaciones posibles# aunque no sea necesario @acer esto para una prueba
adecuada.Bambin se puede conseguir# indicando la distribucin estad"stica que
siguen# quela frecuencia de entrada para orientar correctamente nuestras pruebas
@aciaaquello que es m(s probable que suceda en la pr(ctica real.
ESTRATE;IAS DE APLICACIN DE PRUEBAS DEL SOFTWARE
:na estrategia de prueba integra las tcnicas de dise?o de casos de prueba en un
con1unto de pasos bien planeados que dan como resultado la correcta
construccin del soft-are. :na estrategia de prueba de soft-are proporciona una
gu"a para los desarrolladores del soft-are# para la organizacin de control de
calidad y para el cliente. /or tanto una estrategia de soft-are debe incorporar la
planificacin de la prueba# el dise?o de casos de prueba# la e1ecucin de pruebas
y la agrupacin y evaluacin de los datos resultantes.
P.ue>a +e u)+a+, !a prueba de unidad centra el proceso de verificacin en la
menor unidad del dise?o del soft-are. =qu" se prueban los caminos de control
importantes# conel fin de descubrir errores dentro del (mbito de un mdulo. !a
comple1idad relativade las pruebas y errores descubiertos se encuentra limitada
por los lineamientosestablecidos por la prueba de soft-are.
P.ue>as +e )([email protected]')3
!as pruebas de integracin est(n totalmente ligadas a la forma prevista de integrar
los distintos componentes del soft-are @asta contar con el producto global que
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
24/31
debe entregarse. =s"# las pruebas de integracin implican una progresin
ordenada de pruebas que parte desde los componentes y que culmina en el
sistema completo. Su ob1etivo fundamental es la prueba de las interfaces entre
componentes o mdulos.
!a prueba de Integracin es una tcnica sistem(tica para construir la estructura
del programa mientras que al mismo tiempo# se llevan a cabo pruebas para
detectar errores asociados con la interaccin. El ob1etivo es tomar los mdulos
probados en unidad y estructurar un programa que est de acuerdo con lo que
dicta el dise?o.
E$isten ' tipos de integracin# la primera es no incremental en donde se intenta
elaborar soft-are en mdulos grandes# en otros casos un slo mdulo# pero en
ellos es m(s dif"cil 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 peque?os y funcionales que @acen que los errores sean m(s
f(cil de aislar y corregir# es m(s probable que se puedan probar completamente
las interfaces y aplicar un enfoque de prueba sistem(tico.
I([email protected]')3 )'.ee(al as'e+e(e, El proceso empieza combinando primero
los mdulos de m(s ba1o nivel en grupos que realizan alguna subfuncin
espec"fica# donde se busca reducir el nHmero de pasos de integracin. !uego 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 par(metros de llamada y recoger los resultados a travs de los de salida.
/osteriormente# se prueba cada grupo empleando su impulsor y por Hltimo se
eliminan los mdulos impulsores de cada grupo y se sustituyen por los mdulos
del nivel superior de la 1erarqu"a.
I([email protected]')3 I'.ee(al Des'e+e(e, !a integracin incremental descendente
comienza con el mdulo de control principal y va incorporando mdulos
subordinados progresivamente. o e$iste un procedimiento general para
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
25/31
determinar cu(l de los mdulos subordinados posibles es me1or incorporar
primero# es decir# no se puede dar una regla general que permita determinar la
secuencia ptima de incorporacin de mdulos. Pay que estudiar en cada caso
cu(l es el me1or orden de incorporacin para minimizar el esfuerzo o para lograr
una me1or organizacin. !a siguiente figura muestra la integracin incremental
descendente.
I([email protected]')3 / )'.ee(al, En este tipo de integracin cada mdulo requiere de
los siguientes elementos para ser probado8
:n mdulo impulsor# que transmite o impulsa los datos de prueba al mdulo
y muestra los resultados de dic@os casos de prueba.
:no o m(s mdulos ficticios que simulan la funcin de cada mdulosubordinado llamado por el mdulo que se va a probar.
P.ue>a +el s)s(ea
!a prueba del sistema es el proceso de prueba de un sistema integrado de
@ard-are y soft-are para comprobar si cumple los requisitos especificados# es
decir8 Cumplimiento de todos los requisitos funcionales# considerando el producto
soft-are final al completo# en un entorno de sistema# El funcionamiento y
rendimiento en las interfaces @ard-are# soft-are# de usuario y de operador#
adecuacin de la documentacin de usuario# E1ecucin y rendimiento en
condiciones l"mite y de sobrecarga.
!os casos para la prueba del sistema tienen tres fuentes principales para su
dise?o8 Casos basados en los requisitos gracias a tcnicas de ca1a negra
aplicadas a las especificaciones# Casos necesarios para probar el rendimiento del
sistema y de su capacidad funcional 6pruebas de volumen de datos# de l"mites de
procesamiento# etc.7# Casos basados en el dise?o de alto nivel aplicando tcnicas
de ca1a blanca aplicadas a los flu1os de datos de alto nivel 6por e1emplo# de los
diagramas de flu1o de datos7.
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
26/31
P.ue>a +e A'e1(a')3, El ob1etivo 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.
!as caracter"sticas principales de esta prueba son las siguientes8
/articipacin del usuario# se enfoca @acia 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 e$plotacin.
P.ue>a +e *al)+a')3 9 *e.)7)'a')3
!a definicin de ;erificacin y ;alidacin envuelve lo que se conoce como calidad
del soft-are# en donde los mtodos de an(lisis# de dise?o y de implementacin
actHan para me1orar la calidad al proporcionar tcnicas continuas y resultados
predecibles. !as 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 soft-are. !a 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. !a aplicacin adecuada de los mtodos y de las @erramientas# las
revisiones tcnicas formales efectivas y una slida gestin y medida# conducen a
la calidad# que se confirma durante la prueba.
P.ue>a +el s)s(ea
!a prueba del sistema tiene la finalidad de verificar que se @ayan integrado
correctamente cada uno de los elementos del sistema. Comprende las siguientes
pruebas8
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
27/31
P.ue>a +e Re'u1e.a')3, !a prueba de recuperacin es una prueba que se @ace
al sistema forzando a que produzca fallas de soft-are de muc@as maneras y
verificando que la recuperacin se lleve a cabo# ya sea autom(ticamente o
manual# tomando en cuenta los recursos que se requieran para efectuar la
recuperacin.
P.ue>a +e Se@u.)+a+, !a prueba de seguridad intenta verificar la aplicacin de
los mecanismos de proteccin incorporados en el sistema. >urante la prueba el
encargado de la prueba desempe?a el papel de intruso tratando de violar la
seguridad del sistema# intentando obtener las claves de acceso por cualquier
medio e$terno5 debe bloquear el sistema# negando as" el servicio a otras personas
adem(s de producir errores a propsito en el sistema5 o debe curiosear los datos
pHblicos intentando encontrar una clave de acceso al sistema.
P.ue>a +e Res)s(e')a, !a prueba de resistencia est( dise?ada para enfrentar a
los programas en situaciones anormales# es decir e1ecutar el sistema en forma que
demande recursos en cantidad# frecuencia o volHmenes anormales.
El encargado de la prueba debe intentar colapsar el sistema y para lograrlo se
puede tomar en consideracin lo siguiente8 >ise?ar pruebas especiales que
generen *0 o m(s 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# E1ecutar casos de prueba que requieran al
m($imo de memoria o de espacio en disco# >ise?ar casos de prueba que
produzcan e$cesivas bHsquedas de datos almacenados en disco.
De1u.a')3
!a 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
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
28/31
en los casos de prueba# se evalHan los resultados y resulta una falta de
correspondencia entre los esperados y los reales# el proceso de depuracin
intenta @acer corresponder el sistema con una causa# llevando as" a la correccin
del error.
PRUEBA DE SOFTWARE PARA OBETOS
El soft-are construido a partir del modelo orientado a ob1etos tambin requiere ser
sometido a pruebas con el propsito de garantizar su calidad. En trminos
generales# se puede decir que los dos enfoques m(s representativos en materia
de pruebas# de ca1a blanca y de ca1a negra# son aplicables al soft-are orientado a
ob1etos en cierta medida. Sin embargo# e$isten algunas caracter"sticas del
soft-are orientado a ob1etos que generan problemas adicionales no cubiertos por
las tcnicas tradicionales de prueba.
!a unidad b(sica para la prueba de soft-are orientado a ob1etos es la clase.
= pesar de ello# cuando se prueba al soft-are orientado a ob1etos# no es posible
realizar una prueba para una clase por s" misma# sino que @ay que realizarla para
una instancia de sta# es decir para un ob1eto.
!(/+/s +e 1.ue>a +e s/7(a.e /.)e(a+/ a />e(/sG
uc@as de las generalidades de los mtodos de prueba tradicionales @an sido
adaptadas considerando las caracter"sticas del modelo orientado a ob1etos# con el
propsito de que puedan ser aplicables en este nuevo conte$to. =ctualmente# e$isten
muy pocas investigaciones sobre el estudio de prueba de soft-are orientado a
ob1etos5 ya que el (rea de prueba de soft-are es bastante comple1a y dentro de este
marco de ob1etos e$iste 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 soft-are orientado a ob1etos en trminos del nivel deprueba.
P.ue>as +e u)+a+
En el soft-are orientado a ob1etos la menor unidad a considerar para realizar una
prueba es la clase. !a prueba de clases en el (mbito de soft-are Orientado a
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
29/31
Ob1etos es equivalente a la prueba de unidad realizada al soft-are tradicional.
Esta prueba est( fundamentalmente dirigida a las operaciones encapsuladas por
la clase# as" como al estado y comportamiento del ob1eto que se implementa en
ella. El nfasis de la prueba de unidad es verificar que esta peque?a unidad
traba1e correctamente en forma aislada# antes de proceder a integrarla en el
sistema.
P.ue>as +e )([email protected]')3G
Cuando se aplican pruebas de integracin al soft-are orientado a ob1etos# se
pretende demostrar que las unidades que ya @an sido sometidas a un proceso de
prueba y funcionan correctamente# lo @acen de igual forma cuando interactHan y
se integran con otras unidades del sistema. /r(cticamente# el traba1o de esta
prueba se concentra en la interaccin de mtodos en diferentes unidades.
P.ue>as +e s)s(eaG
!as 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 @an generado pocos traba1os# por lo que se emplean muc@os de
los mtodos tradicionales.
Ta>la, P.ue>as +e S)s(ea +e S/7(a.e O.)e(a+/ a O>e(/s
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
30/31
PRUEBA DE SOFTWARE BASADO EN CO!PONENTESG
!a construccin de soft-are a partir de componentes es una pr(ctica
relativamente nueva# por lo que no es e$tra?o que sea escasa la e$istencia de
traba1os generados al respecto. /uesto que el desarrollo basado en componentes
presenta algunas similitudes con el enfoque orientado a ob1etos# para un
componente pueden ser aplicables algunas de sus consideraciones# incluso en
materia de prueba. =spectos como la @erencia# encapsulacin# polimorfismo# liga
din(mica o mecanismos de comunicacin# son comunes entre ambos modelos. Es
evidente que para @acer las pruebas de componentes m(s robustas# ser(
necesario considerar las caracter"sticas propias del enfoque de componentes.
P.ue>as +e u)+a+G=unque la realizacin de pruebas de unidad es una actividad que en algHn
momento es llevada a cabo por el desarrollador# e$iste un marco de traba1o
adicional a considerar8 el de la persona que se interesa en el componente con el
fin de integrarlo en sus sistemas.
=ctualmente son pocos los traba1os en materia de pruebas de unidad para
componentes# dos sobresalientes en este ramo son el proyecto Brusted
Components y el /royecto Jimera# aunque este Hltimo no est( dirigido totalmente
a componentes# sino a la seguridad de las m(quinas virtuales de ava cada vez
que se carga una clase.
P.ue>as +e )([email protected]')3GSi 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 aHn m(s notables. Sin embargo# e$isten coincidencias en cuanto a las
problem(ticas comunes al integrar componentes8
El */lue 9 la le()(u+, Cuando se utilizan componentes dentro de un sistema#
no siempre se utilizan todas sus capacidades# lo que @ace que cierta parte del
cdigo no sea necesario. Este problema se agrava cuando se tienen sistemas
grandes# afect(ndose as" su rendimiento.
7/24/2019 NORMAS DE EVALUACION DEL SOFTWARE DE CALIDAD.docx
31/31
L/s e'a)s/s +e '/u)'a')3 u()l)Ha+/s, Se @an presentado algunas
contrariedades e inconsistencias al utilizar dentro de un mismo sistema varios
mecanismos de comunicacin como eventos# mensa1es o bien el paso de
par(metros.