Verificacion y Validacion de Software

VERIFICACION Y VALIDACION DE SOFTWARE SOFTWARE

DEFINICION La valid alidac ació ión n y veri verifi fica caci ción ón (V y V) de soft softw ware are se defi define ne como como un conj conjun unto to de procedimientos, actividades, técnicas 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 visión del desarrollo de software, formada por un conjunto de fases, no sólo facilita el desarrollo desarrollo,, sino tam!ién tam!ién el esfuerzo esfuerzo de la V y V "e puede puede dividir dividir el esfuerzo esfuerzo de V y V indicando las actividades, procedimientos y técnicas a emplear en cada fase del ciclo de vida vida #ara ello es necesari necesario o definir un #lan de Verificac Verificación ión y Validación Validación de software software al inicio del proyecto que determine estas actividades

OBJETIVOS La V y V !usca$ % % % % %

&etect &etectar ar y correg corregir ir los defec defectos tos tan tan pronto pronto como como sea posi! posi!le le en el ciclo ciclo de de vida del del software &isminuir &isminuir los riesgos riesgos,, las desviacion desviaciones es so!re so!re los los presup presupuesto uestos s y so!re so!re el programa programa de tiempos 'ejo 'ejora rarr la cal calid idad ad y fia fia!i !ilid lidad ad del del sof softw twar are e 'ejora 'ejorarr la visi! visi!ili ilidad dad de de la gesti gestión ón del del proce proceso so de de desarr desarroll ollo o Valora Valorarr rpidam rpidament ente e los cam!i cam!ios os propue propuesto stos s y sus consec consecuen uencia cias s

 ntes de continuar es !ueno dejar claros los o!jetivos que tienen la V y V La validación tien tiene e por por o!je o!jeti tivo vo dete determ rmin inar ar la corr correc ecci ción ón del del prod produc ucto to fina finall con con resp respec ecto to a las las neces necesida idades des plant plantead eadas as por los los usuario usuarios s finales finales La verificación tiene por o!jetivo o!jetivo demostrar la consistencia y corrección del software entre las fases del ciclo de desarrollo de un proyecto

PLAN DE V Y V   continuación se presenta presenta un modelo !sico !sico de un plan de verificación y validación %#ropósito % &ocumentos de referencia %&efiniciones %Visión *eneral de las verificaciones y validaciones *estión 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 implementación V y V en fase de prue!as V y V en fase de implantación V y V en fase de mantenimiento % nformes de V y V del software % #rocedimientos administrativos de la V y V

nforme de resolución de anomal-as #ol-tica de iteración de tareas #ol-tica de desviación #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   continuación se presenta el contenido !sico de un plan de prue!as$ % % % % % % % % % % % % % % % %

dentificar el documento ntroducción 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, técnicas, herramientas, etc) .riterios de apro!ación para cada elemento pro!ado .riterios para suspender y requisitos para reanudar actividad &ocumentos a entregar  ctividades de preparación y ejecución de prue!as 0ecesidades de entorno 1esponsa!ilidades en la organización y realización de las prue!as 0ecesidades de personal y de formación .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 realización de controles periódicos /stos controles !uscan una evaluación de la calidad de los productos generados para poder detectar posi!les defectos cuanto antes "in em!argo, todo sistema o aplicación, independientemente de éstas revisiones, de!e ser pro!ado mediante su ejecución controlada antes de ser entregado al cliente /stas ejecuciones o ensayos de funcionamiento, posteriores a la terminación del código de software se denominan ha!itualmente prue!as Las prue!as constituyen un método mas para poder verificar y validar el software "e puede definir prue!a como na ac!ividad en la cal n "i"!e#a $ n$ de "" c$#%$nen!e" "e e&ec!a en circn"!ancia" %revia#en!e e"%ecificada"'  Los resultados de la ejecución se o!servan y registran con el fin de realizar posteriormente una evaluación de alg3n aspecto 2n ca"$ de %re(a )test case) se puede definir como un conjunto de entradas, condiciones de ejecución 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 %re(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 , situación que no es real Las prue!as permiten la rectificación del software Los defectos no son siempre el resultado de la negligencia, si no que en su aparición influyen m3ltiples factores, por ejemplo, la mala comunicación 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 ejecución 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 descomposición .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 regresión Los módulos 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 comprensión .uanta ms información tengamos, mejores sern las prue!as

INSPECCIONES La in"%ección del "$f!,are IEEE e" na !.cnica de evalación f$r#al/ en la cual los requisitos del software, dise+o o la codificación son e5aminados en detalle por una persona diferente al desarrollador, para detectar defectos, incoherencias con las normas de desarrollo y otros pro!lemas La inspección proporciona una indicación inmediata y cuantitativa de la calidad, comenzando con los requerimientos y el dise+o #ara que una inspección 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 documentación /n la inspección de!en participar colegas y todo tipo de personal relacionado con el sistema La inspección se de!e realizar seg3n una serie predefinida de estapas Las reuniones de inspección no de!e superar dos (9) horas Las inspecciones de!en ser dirigidas por personal con e5periencia

% % % %

Los miem!ros del grupo de inspección de!en tener tareas espec-ficas asignados a cada uno /l grupo de inspección de!e contar con listas de chequeo y compro!ación 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 %

%

%

%

% %

#lanificación 2na vez se determina que un producto esta listo para inspección se define un equipo encargado de esa tarea, para lo cual planea una serie de actividades ( para autor e inspector) con miras a la revisión del producto #resentación o visión general /s una etapa opcional que tiene por o!jeto ofrecer una visión glo!al del proyecto y e5plicar las funciones, organización y técnica del producto #reparación qu- se define el tra!ajo que de!e hacer cada inspector, a partir de la documentación que le ha sido entregada /l inspector con los datos o!tenidos se prepara para desempe+ar un !uen papel en la reunión (siguiente etapa) 1eunión 6iene por o!jetivo la !3squeda e5haustiva de defectos del producto analizado y por ello es la etapa ms importante del proceso La reunión de ser dirigida por un moderador quien hacer parte del equipo de inspectores "e recomienda llevar el siguiente orden$ In!r$dcción 2sada para presentar inspectores y recordar sus funciones E"!a(lecer !ie#%$" de %re%aración de in"%ec!$re"  /l moderador verifica el tiempo que dedicaron a prepararse para la reunión Lec!ra de %r$dc!$/ iden!ificación 0 an$!ación de defec!$" #elean los defectos encontrados por cada inspector y se toma nota de ellos Revi"ión de li"!a de defec!$" 6erminada la reunión se verifica cada uno de los defectos encontrados !uscando un consenso entre grupo de inspectores De!er#inar di"%$"ición final del %r$dc!$  "e define el concepto final para el producto Los conceptos posi!les son$ afectados, afectado condicionalmente y rechazado .orrección /n esta etapa el actor de!e corregir los defectos encontrados por los inspectores y entregar el nuevo producto "eguimiento .uando la corrección 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 inspección "i no los aprue!a, el moderador puede solicitar una corrección adicional o convocar a otra inspección