normas de evaluacion del software de calidad.docx

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_9000


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


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.


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


5/31


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/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.


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


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


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.

!


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

!


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.


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


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 !


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


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


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

!


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


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


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


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


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.


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


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


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.


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


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


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


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


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.


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.

normas de evaluacion del software de calidad.docx

Documents