VERIFICACION Y VALIDACION DE SOFTWARE

DEFINICION
La validacin y verificacin (V y V) de software se define como un conjunto de
procedimientos, actividades, tcnicas y herramientas que se utilizan, paralelamente al
desarrollo, para asegurar que un producto de software cumpla con los requerimientos
planteados por los usuarios finales
La visin del desarrollo de software, formada por un conjunto de fases, no slo facilita el
desarrollo, sino tam!in el esfuerzo de la V y V "e puede dividir el esfuerzo de V y V
indicando las actividades, procedimientos y tcnicas a emplear en cada fase del ciclo de
vida #ara ello es necesario definir un #lan de Verificacin y Validacin de software al
inicio del proyecto que determine estas actividades
OBJETIVOS
La V y V !usca$
% &etectar y corregir los defectos tan pronto como sea posi!le en el ciclo de vida del
software
% &isminuir los riesgos, las desviaciones so!re los presupuestos y so!re el programa
de tiempos
% 'ejorar la calidad y fia!ilidad del software
% 'ejorar la visi!ilidad de la gestin del proceso de desarrollo
% Valorar r(pidamente los cam!ios propuestos y sus consecuencias
)ntes de continuar es !ueno dejar claros los o!jetivos que tienen la V y V La validacin
tiene por o!jetivo determinar la correccin del producto final con respecto a las
necesidades planteadas por los usuarios finales La verificacin tiene por o!jetivo
demostrar la consistencia y correccin del software entre las fases del ciclo de desarrollo
de un proyecto
PLAN DE V Y V
) continuacin se presenta un modelo !(sico de un plan de verificacin y validacin
%#ropsito
% &ocumentos de referencia
%&efiniciones
%Visin *eneral de las verificaciones y validaciones
*estin de la V y V
V y V en fase de requerimientos
V y V en fase de dise+o
V y V en fase de implementacin
V y V en fase de prue!as
V y V en fase de implantacin
V y V en fase de mantenimiento
% ,nformes de V y V del software
% #rocedimientos administrativos de la V y V
,nforme de resolucin de anomal-as
#ol-tica de iteracin de tareas
#ol-tica de desviacin
#rocedimientos de .ontrol
/st(ndares, pr(cticas y convenciones
PLAN DE PRUEBAS
/s un documento que tiene como o!jetivo se+alar el enfoque, los recursos y el esquema
de actividades de prue!a, as- como los elementos a pro!ar, las caracter-sticas, las
actividades de prue!a, el personal responsa!le y los riesgos asociados
) continuacin se presenta el contenido !(sico de un plan de prue!as$
% ,dentificar el documento
% ,ntroduccin y resumen de elementos y caracter-sticas a pro!ar
% /lementos de software que se van a pro!ar
% .aracter-sticas que se van a pro!ar
% .aracter-sticas que no se prue!an
% /nfoque general de la prue!a ()ctividades, tcnicas, herramientas, etc)
% .riterios de apro!acin para cada elemento pro!ado
% .riterios para suspender y requisitos para reanudar actividad
% &ocumentos a entregar
% )ctividades de preparacin y ejecucin de prue!as
% 0ecesidades de entorno
% 1esponsa!ilidades en la organizacin y realizacin de las prue!as
% 0ecesidades de personal y de formacin
% .ronograma de tiempos y actividades
% 1iesgos asumidos por el plan
% )pro!aciones y firmas con nom!re y puesto desempe+ado
PRUEBAS
2na de las caracter-sticas t-picas del desarrollo de software !asado en el ciclo de vida es
la realizacin de controles peridicos /stos controles !uscan una evaluacin de la
calidad de los productos generados para poder detectar posi!les defectos cuanto antes
"in em!argo, todo sistema o aplicacin, independientemente de stas revisiones, de!e
ser pro!ado mediante su ejecucin controlada antes de ser entregado al cliente /stas
ejecuciones o ensayos de funcionamiento, posteriores a la terminacin del cdigo de
software se denominan ha!itualmente prue!as Las prue!as constituyen un mtodo mas
para poder verificar y validar el software
"e puede definir prue!a como na ac!ividad en la cal n "i"!e#a $ n$ de ""
c$#%$nen!e" "e e&ec!a en circn"!ancia" %revia#en!e e"%ecificada"' Los
resultados de la ejecucin se o!servan y registran con el fin de realizar posteriormente
una evaluacin de alg3n aspecto
2n ca"$ de %re(a )test case) se puede definir como un conjunto de entradas,
condiciones de ejecucin y resultados esperados desarrollados para un o!jetivo particular,
por ejemplo verificar el cumplimiento de un determinado requerimiento
Las caracter-sticas especiales del software (no f-sico, ausencia de leyes, que rijan su
comportamiento, y complejidad) hacen aun m(s dif-cil la tarea de pro!arlo La %re(a"
e*+a"!iva" del "$f!,are "$n i#%rac!ica(le" ya que no se pueden pro!ar todas la
posi!ilidades de su funcionamiento incluso en programas peque+os y sencillos
4ay que recordar que el o!jetivo de las prue!as es detectar defectos en el software y que
descu!rir un defecto de!er-a considerarse como el 5ito de una prue!a
6radicionalmente, e5iste el mito de la a"encia de err$re" en el (en %r$fe"i$nal,
situacin que no es real Las prue!as permiten la rectificacin del software
Los defectos no son siempre el resultado de la negligencia, si no que en su aparicin
influyen m3ltiples factores, por ejemplo, la mala comunicacin entre usuarios y
programadores
ASPECTOS A TENER EN CUENTA EN LA APLICACI-N DE UNA PRUEBA
% 7peratividad .uanto mejor funcione el software, m(s eficientemente se puede
pro!ar 0ing3n error de!e !loquear la ejecucin de las prue!as
% 7!serva!ilidad Lo que ves es loq eu prue!as 2n resultado incorrecto se
identifica f(cilmente
% .ontrola!ilidad .u(nto mejor podamos controlar el software m(s se puede
automatizar y optimizar Las prue!as pueden especificarse, automatizarse y
reproducirse convenientemente
% .apacidad de descomposicin .ontrolando el (m!ito de las prue!as podemos
aislar m(s r(pidamente los pro!lemas y llevar a ca!o mejores prue!as de
regresin Los mdulos de software se pueden pro!ar independientemente
% "implicidad .uanto menos haya que pro!ar m(s r(pidamente podemos pro!arlo
% /sta!ilaidad .u(nto menos cam!ios haya, menos interrupciones a las prue!as
% 8acilidad de comprensin .uanta m(s informacin tengamos, mejores ser(n las
prue!as
INSPECCIONES
La in"%eccin del "$f!,are IEEE e" na !.cnica de evalacin f$r#al/ en la cual
los requisitos del software, dise+o o la codificacin son e5aminados en detalle por una
persona diferente al desarrollador, para detectar defectos, incoherencias con las
normas de desarrollo y otros pro!lemas
La inspeccin proporciona una indicacin inmediata y cuantitativa de la calidad,
comenzando con los requerimientos y el dise+o
#ara que una inspeccin tenga 5ito se de!en cumplir ciertas normas$
% Las inspecciones se realizan en varios puntos del ciclo e vida del producto
% "e de!en inspeccionar todo tipo de defecto en toda la documentacin
% /n la inspeccin de!en participar colegas y todo tipo de personal relacionado con
el sistema
% La inspeccin se de!e realizar seg3n una serie predefinida de estapas
% Las reuniones de inspeccin no de!e superar dos (9) horas
% Las inspecciones de!en ser dirigidas por personal con e5periencia
% Los miem!ros del grupo de inspeccin de!en tener tareas espec-ficas asignados a
cada uno
% /l grupo de inspeccin de!e contar con listas de chequeo y compro!acin para el
control de las inspecciones realizadas
% "e de!e inspeccionar el producto a una velocidad adecuada para encontrar
posi!les fallas
% "e de!en archivar estad-sticas de las inspecciones
ETAPAS DE LAS INSPECCIONES
% #lanificacin 2na vez se determina que un producto esta listo para inspeccin se
define un equipo encargado de esa tarea, para lo cual planea una serie de
actividades ( para autor e inspector) con miras a la revisin del producto
% #resentacin o visin general /s una etapa opcional que tiene por o!jeto ofrecer
una visin glo!al del proyecto y e5plicar las funciones, organizacin y tcnica del
producto
% #reparacin )qu- se define el tra!ajo que de!e hacer cada inspector, a partir de la
documentacin que le ha sido entregada /l inspector con los datos o!tenidos se
prepara para desempe+ar un !uen papel en la reunin (siguiente etapa)
% 1eunin 6iene por o!jetivo la !3squeda e5haustiva de defectos del producto
analizado y por ello es la etapa m(s importante del proceso La reunin de ser
dirigida por un moderador quien hacer parte del equipo de inspectores "e
recomienda llevar el siguiente orden$
In!r$dccin 2sada para presentar inspectores y recordar sus funciones
E"!a(lecer !ie#%$" de %re%aracin de in"%ec!$re" /l moderador verifica el
tiempo que dedicaron a prepararse para la reunin
Lec!ra de %r$dc!$/ iden!ificacin 0 an$!acin de defec!$" #elean los
defectos encontrados por cada inspector y se toma nota de ellos
Revi"in de li"!a de defec!$" 6erminada la reunin se verifica cada uno de los
defectos encontrados !uscando un consenso entre grupo de inspectores
De!er#inar di"%$"icin final del %r$dc!$ "e define el concepto final para el
producto Los conceptos posi!les son$ afectados, afectado condicionalmente y
rechazado
% .orreccin /n esta etapa el actor de!e corregir los defectos encontrados por los
inspectores y entregar el nuevo producto
% "eguimiento .uando la correccin finalice, el autor en el moderador se re3nen de
nuevo para revisar los resultados "i el moderador aprue!a los resultados se da
por terminada la inspeccin "i no los aprue!a, el moderador puede solicitar una
correccin adicional o convocar a otra inspeccin