Unidad IV Desarrollo e Implemetacion de SI

7/28/2019 Unidad IV Desarrollo e Implemetacion de SI

1/23

4. Verificacin y validacin.

La verificacin y validacin es el nombre que se da a los procesos decomprobacin y anlisis que aseguran que el software que se desarrolla estacorde a su especificacin y cumple las necesidades de los clientes. La V&V es unproceso de ciclo de vida completo. Inicia con las revisiones de los requerimientos y

contina con las revisiones del diseo y las inspecciones del cdigo hasta laprueba del producto.

Verificacin: Estamos construyendo el producto correctamente? El papel de laverificacin comprende comprobar que el software est de acuerdo con suespecificacin. Se comprueba que el sistema cumple los requerimientosfuncionales y no funcionales que se le han especificado. La verificacin y lavalidacin no son la misma cosa, aunque es muy fcil confundirlas, Boehm (1979)expres la diferencia entre ellas de forma sucinta:

Validacin: Estamos construyendo el producto concreto? La validacin es un

proceso ms general. Se debe asegurar que el software cumple las expectativasdel cliente. Va ms all de comprobar si el sistema est acorde con suespecificacin, para probar que el software hace lo que el usuario Es importantellevar a cabo la validacin de los requerimientos del sistema de forma inicial.

Es fcil cometer errores y omisiones durante la fase de anlisis de requerimientosdel sistema y, en tales casos, el software final no cumplir las expectativas de losclientes. Sin embargo, en la realidad, la validacin de los requerimientos no puededescubrir todos los problemas que presenta la aplicacin. Algunos defectos en losrequerimientos solo pueden descubrirse cuando la implementacin del sistema escompleta.

Dentro del proceso de Verificacin y validacin se utilizan dos tcnicas decomprobacin y anlisis de sistemas:

1. Las inspecciones del software analizan y comprueban las representacionesdel sistema como el documento de requerimientos, los diagramas de diseo y elcdigo fuente del programa. Se aplica a todas las etapas del proceso dedesarrollo. Las inspecciones se complementan con algn tipo de anlisisautomtico del texto fuente o de los documentos asociados. Las inspecciones delsoftware y los anlisis automatizados son tcnicas de verificacin y validacinestticas puesto que no requieren que el sistema se ejecute.

2. Las pruebas del software consiste en contrastar las respuestas de unaimplementacin del software a series de datos de prueba y examinar lasrespuestas del software y su comportamiento operacional, para comprobar que sedesempee conforme a lo requerido. Llevar a cabo las pruebas es una tcnicadinmica de la verificacin y validacin ya que requiere disponer de un prototipoejecutable del sistema.


2/23

4.1. Pruebas.

Las pruebas del software consisten en contrastar las respuestas de unaimplementacin del software a series de datos de prueba y examinar lasrespuestas del software y su comportamiento operacional, para comprobar que sedesempee conforme a lo requerido. Llevar a cabo las pruebas es una tcnica

dinmica de la verificacin y validacin ya que requiere disponer de un prototipoejecutable del sistema.

4.1. Objetivo.

Detectar las fallas probables que tenga nuestro software y mejorarlas y as lograr

tener existo en su aplicacin y ejecucin.

4.2. Justificacin.

Tener la certeza de que nuestro software este trabajado bien y no tendr errores.

4.2. Tipos de pruebas.

La confirmacin de un sistema de software es un proceso continuo en cada etapadel ciclo de vida del software. La prueba de los programas sigue siendo la tcnicade confirmacin de sistemas ms utilizada.

La prueba de los programas es parte del proceso de confirmacin que suelerealizarse durante la aplicacin y tambin, en una forma distinta, cuando este haterminado. La prueba consiste en ejercitar el programa utilizando datos similares alos datos reales que harn de ser ejecutados por el programa, observar los

resultados y deducir la existencia de errores o insuficiencias del programa a partirde las anomalas de este resultado.

En ocasiones, se piensa que las pruebas y la depuracin de programas son unamisma cosa. Aunque estn muy relacionadas, en realidad son procesos distintos.La prueba es el proceso de establecer la existencia de errores en el programa.Depuracin es el proceso de localizar dnde se produjeron esos errores y corregirel cdigo incorrecto.

Es muy importante comprender que la prueba nunca demuestra que un programaes correcto. Siempre es posible que existan errores aun despus de la prueba

ms completa. La prueba de programas slo puede demostrar la presencia deerrores en un programa, no su ausencia. De acuerdo con Myers, se consideraprueba acertada aquella que establece la presencia de uno o ms errores en elsoftware objeto de la prueba. La prueba de programas es un proceso destructivo.Se disea para hacer que el comportamiento de un programa sea distinto del queintentaba su diseador o aplicador. Como es una caracterstica humana naturalque un individuo tenga cierta afinidad con los objetos que ha construido, elprogramador responsable de la aplicacin del sistema no es la persona ms


3/23

apropiada para probar un programa. Psicolgicamente, el programador no querrdestruir su creacin, lo cual har que, de manera consciente o inconsciente, elijapruebas que fallan, por lo que no sern adecuadas para demostrar la presencia deerrores en el sistema.

Flujo de la Informacin de la Prueba

Se proporcionan dos clases de entradas al proceso de prueba:

Una configuracin del software que incluye la Especificacin derequerimientos, la Especificacin de diseo y el Cdigo fuente; y en

Una Configuracin de prueba que incluye un Plan y Procedimiento deprueba, casos de prueba y resultados esperados. En realidad laconfiguracin de prueba es un subconjunto de la configuracin delsoftware cuando se considera el proceso de ingeniera del softwarecompleto.

Se lleva a cabo la prueba y se evala los resultados. O sea, se comparan losresultados de la prueba con los esperados. Cuando se descubren datos errneos,esto indica la existencia de un error y comienza la depuracin.

A medida que se van recopilando y evaluando los resultados de la prueba,comienza a vislumbrarse una medida cualitativa de la calidad y fiabilidad delsoftware. Si se encuentran con regularidad errores serios que requierenmodificaciones en el diseo; la calidad y la fiabilidad del software queda enentredicho, siendo necesarias posteriores pruebas. Si, por otro lado elfuncionamiento del software parece ser correcto y los errores que se encuentran

son de fcil correccin, se puede sacar dos conclusiones:

La calidad y la fiabilidad del software son aceptables.

Las pruebas son inadecuadas para descubrir errores serios.

Finalmente, si la prueba no descubre errores, quedar la sospecha que laconfiguracin de la prueba no ha sido la ms ptima y que los errores estnescondidos en el software. Estos defectos sern descubiertos por el usuario yreparados por el profesional en la etapa de mantenimiento con un costo porarreglo que puede ser entre 40 y 60 veces superior al costo por arreglo en la fasede desarrollo.

Diseo de casos de prueba

Cualquier producto de ingeniera puede ser probado de una de dos formas:

Conociendo la funcin especfica para la que fue diseado el producto, sepueden llevar a cabo pruebas que demuestren que cada funcin escompletamente operativa.


4/23

Conociendo el funcionamiento del producto, se puede desarrollar pruebasque aseguren que todas las piezas encajan, o sea, que la operacininterna se ajusta a las especificaciones y que todos los componentesinternos se han comprobado en forma adecuada.

La primera aproximacin de prueba se denomina Prueba de la caja negra y lasegunda Prueba de la caja blanca.

Prueba de la Caja Blanca

La prueba de la caja blanca es un mtodo de diseo de casos de prueba que usala estructura de control del diseo procedimental para derivar los casos de prueba.Mediante los mtodos de prueba de la caja blanca el ingeniero del software puedederivar casos de prueba que:

Garanticen que se ejercitan al menos una vez todos los caminos

independientes de cada mdulo.

Se ejercitan todas las decisiones lgicas en sus caras verdaderas y falsas.

Se ejecutan todos los bucles en sus lmites y con sus lmites operacionales.

Se ejercitan las estructuras de datos internas para asegurar su validez.

En estas encrucijadas se puede exponer una pregunta razonable: Por qugastar tiempo y energa probando y preocupndose de las minuciosidades lgicascuando podramos gastar mejor el esfuerzo asegurando que se han alcanzado los

requerimientos del programa?. La respuesta se encuentra en la naturaleza mismade los defectos del software.

Los errores lgicos y las suposiciones incorrectas son inversamenteproporcionales a la probabilidad de que se ejecute un camino del programa.Los errores tienden a producirse en nuestro trabajo cuando diseamos oimplementamos funciones, condiciones o controles que se encuentran fueradel normal. El procedimiento habitual tiende a hacer ms comprensible,mientras que el procesamiento de casos especiales tiende a caer en elcaos.

A menudo creemos que un camino lgico tiene pocas posibilidades deejecutarse cuando, de hecho, se puede ejecutar de forma regular. El flujolgico de un programa a veces no es nada intuitivo, lo que significa quenuestras suposiciones intuitivas sobre el flujo de control y los datos nospueden llevar a tener errores de diseo que solo se descubren cuandocomienza la prueba del camino.


5/23

Los errores tipogrficos son aleatorios. Cuando se traduce un programa acdigo fuente de un lenguaje de programacin, es muy probable que se denalgunos errores de escritura. Muchos sern descubiertos por losmecanismos de comprobacin de sintaxis, pero otros permanecernindetectados hasta que comience la prueba. Es igual de probable que haya

un error tipogrfico en un oscuro camino lgico que en un camino principal.

Cada una de estas razones nos da un argumento para llevar a cabo las pruebasde caja blanca. La prueba de caja negra, sin tener en cuenta como sea decompleta, puede pasarse los tipos de errores que acabamos de sealar. Comoestableci Beizer: Los errores se esconden en los rincones y se aglomeran en loslmites. Es mucho ms fcil de descubrirlos con la prueba de caja blanca.

Pruebas del Camino Bsico

La prueba del camino bsico es una tcnica de prueba de la caja blanca propuesta

inicialmente por Tom McCabe. El mtodo del camino bsico permite al diseadorde casos de prueba derivar una medida de complejidad lgica de un diseoprocedural y usar esa medida como gua para la definicin de un conjunto bsicode caminos de ejecucin. Los casos de prueba derivados del conjunto bsicogarantizan que durante la prueba se ejecuta por lo menos una vez cada sentenciadel programa.

Notacin de grafo de flujo

Antes de considerar el mtodo del camino bsico se debe introducir una sencillanotacin para la representacin del flujo de control, denominada grafo de flujo.Cada construccin estructurada tiene un correspondiente smbolo en el grafo deflujo.

Cuando en un diseo procedural se encuentran condiciones compuestas, lageneracin del grafo de flujo se hace un poco ms complicada. Una condicincompuesta se da cuando aparecen uno o ms operadores booleanos (OR, AND,NAND, NOR lgicos) en una sentencia condicional.

Prueba de Bucles

Los bucles son la piedra angular de la mayora de los algoritmos implementadosen software. Y por ello debemos prestarle normalmente un poco de atencincuando llevamos a cabo la prueba del software.

La prueba de bucles es una tcnica de prueba de caja blanca que se centraexclusivamente en la validez de las construcciones de bucles. Se pueden definircuatro clases diferentes de bucles: Bucles simples, Bucles concatenados, Bucles

Anidados, y bucles no estructurados.


6/23

Adems de un anlisis del camino bsico que asle todos los caminos de un bucle,se recomienda un conjunto especial de pruebas adicionales para cada tipo debucles. Estas pruebas buscan errores de inicializacin, errores de indexacin o deincremento y errores en los lmites de los bucles.

Bucles Simples: A los bucles simples se les debe aplicar el siguiente conjunto depruebas, donde n es el nmero mximo de pasos permitidos por bucle.

Saltar totalmente el bucle. Pasar una sola vez por el bucle. Pasar dos veces por el bucle. Hacer m pasos por el bucle con m


7/23

todos los requerimientos funcionales de un programa. La prueba de la caja negrano es una alternativa a las tcnicas de prueba de la caja blanca. Ms bien se tratade un enfoque complementario que intenta descubrir diferentes tipos de erroresque los mtodos de la caja blanca.

La prueba de la caja negra intenta encontrar errores de las siguientes categoras:

Funciones incorrectas o ausentes Errores de interfaz Errores en estructura de datos o en acceso a base de datos externas Errores de rendimiento Errores de inicializacin y de terminacin.

A diferencia de la prueba de la caja blanca, que se lleva a cabo previamente en elproceso de prueba, la prueba de la caja negra tiende a ser aplicadas enposteriores fases de prueba. Ya que la prueba de la caja negra intencionadamente

ignora la estructura de control, concentra su atencin en el dominio de lainformacin. Las pruebas se disean para responder a las siguientes preguntas:

Cmo se prueba la validez funcional?

Qu clase de entrada compondrn unos buenos casos de prueba?

Es el sistema particularmente sensible a ciertos valores de entrada?

De qu forma estn aislados los lmites de una clase de datos?

Qu volmenes y niveles de datos tolerar el sistema?

Qu efectos sobre la operacin del sistema tendrn combinacionesespecficas de datos?

Mediante las tcnicas de prueba de la caja negra se derivan un conjunto de casosde prueba que satisfacen los siguientes criterios:

Casos de prueba que reducen, en un coeficiente que es mayor que uno, elnmero de casos de prueba adicionales que se deben disear paraalcanzar una prueba razonable.

Casos de prueba que nos dicen algo sobre la presencia o ausencia declases de errores asociados solamente con la prueba en particular que seencuentra disponible.


8/23

Particin Equivalente

La particin equivalente es un mtodo de prueba de la caja negra que divide eldominio de entrada de un programa en clases de datos de los que se puedenderivar casos de prueba. Un caso de prueba ideal descubre de forma inmediata

una clase de error (por ejemplo procesamiento incorrecto de todos los datos decarcter) que de otro modo requeriran la ejecucin de muchos casos antes dedetectar el error genrico. La particin equivalente se dirige a la definicin decasos de prueba que descubran clases de errores, reduciendo as el nmero totalde casos de prueba que hay que desarrollar.

El diseo de casos de prueba para la particin equivalente se basa en unaevaluacin de las clases de equivalencia para una condicin de entrada. Unaclase de equivalencia representa un conjunto de estados vlidos o invlidos paracondiciones de entrada. Tpicamente una condicin de entrada es un valornumrico especifico, un rango de valores, un conjunto de valores relacionados o

una condicin booleana (si o no). Las clases de equivalencia se pueden definir deacuerdo a las siguientes directrices:

Si una condicin de entrada especifica un rango, se define una clase deequivalencia vlida y dos invlidas.

Si una condicin de entrada requiere un valor especifico, se define unaclase de equivalencia vlida y dos invlidas.

Si una condicin de entrada especifica un miembro de un conjunto, sedefine una clase de equivalencia vlida y una invlidas.

Si una condicin de entrada es booleana, se define una clase vlida y unainvlida.

Aplicando esas directrices para la derivacin de clases de equivalencia, se puedendesarrollar y ejecutar casos de prueba para cada elemento de datos del dominiode entrada. Los casos de prueba se seleccionan de forma que se ejercite el mayornmero de atributos de cada clase de equivalencia a la vez.

Tcnicas de Grafos Causa - Efecto

El uso de grafos de causa - efecto es una tcnica de casos de prueba queproporciona una concisa representacin de las condiciones lgicas y suscorrespondientes acciones. La tcnica sigue cuatro pasos:

Se alistan para un mdulo las causas (condiciones de entrada) y los efectos(acciones), asignando un identificador a cada uno de ellos.

Se desarrolla un grafo causa efecto.

Se convierte el grafo en una tabla de decisin.

Se convierten las reglas de la tabla de decisin a casos de prueba.


9/23

Si se ha usado una tabla de decisin como herramienta de diseo, los grafoscausa - efecto ya no son necesarios.

Prueba de Correccin

Hemos visto que la prueba se puede usar perfectamente para descubrir errores,pero no se puede usar para demostrar la correccin de un programa. Si sepudiese realizar una herramienta infalible de prueba de la correccin delprograma, el esfuerzo de la prueba se reducira considerablemente, desaparecerala necesidad de modelos de fiabilidad y no existira ms que una de las mayorescontribuciones a la crisis del software (la pobre calidad del software). Las pruebasde correcciones manuales, tales como el uso de induccin matemtica o declculo de predicado, puede ser de algn valor en la prueba de pequeosprogramas, pero tienen muy poca utilidad cuando se deben validar grandessubsistemas de software.

Si alguna vez se desarrolla un buen mtodo de propsito general para la pruebade correccin de software, probablemente incluira lo siguiente:

Un mtodo validado y que se aplique de forma sencilla para especificarafirmaciones sobre la correcta operacin del software.

Un mtodo para indicar la variacin respecto de la operacin correcta(errores).

Una tcnica para descubrir la causa del error.

Una aproximacin totalmente automatizada que coja el cdigo fuente oalgn otro elemento de la configuracin del software (por ejemplo, unarepresentacin del diseo) como entrada.

Durante la dcada pasada se han desarrollado varias aproximacionesautomatizadas a la prueba de correccin de software de computadoras. Lasherramientas automatizadas de comprobacin de la correccin, que no se debenconfundir con las herramientas automticas de prueba, generalmente encierranuna especificacin formal de la lgica del programa. Esa especificacin se puedeobtener con un macro compilador que produzca una representacin simblica delsoftware. La correccin de un programa es comprobada mediante el uso detcnicas automatizadas [SMI85] basada en la teora de la inteligencia artificial y delclculo de predicados.

El proceso de Prueba

Excepto para programas de computador muy pequeos, no es realista intentar laprueba de los sistemas como si se tratara de una sola unidad. Los sistemasgrandes se componen por subsistemas formados por mdulos que, a su vez,


10/23

pueden componerse de procedimientos. Si se intenta probar el sistema como unasola entidad, es posible que no se identifiquen ms que un pequeo porcentaje deerrores. El proceso de prueba, al igual que el de programacin, debe avanzar enetapas, siendo cada una de ellas la continuacin lgica de la anterior.

En el proceso de prueba se pueden encontrar 5 etapas:

Prueba de Unidad. Este tipo de prueba es considerada una de las primordiales yaque los resultados obtenidos de esta repercutirn directamente en la ejecucin delas dems pruebas. El modo de operacin de este tipo de prueba se basadirectamente en concepto de caja blanca controlando, a base de condicioneslimites, el buen funcionamiento interno del mdulo, esto se refiere al manejo deflujos de datos internos en el mdulo controlando las iteraciones, bucles ycomparaciones que este realice para verificar todos los posibles caminos quepuedan tomar la informacin recibida. Si los datos no son ingresadoscorrectamente, o no se tratan de igual manera, esto nos indicar especialmente

problemas en los clculos internos como por ejemplo:

Precedencia aritmtica incorrecta o mal interpretada.

Operaciones de modo mixto.

Inicializaciones incorrectas.

Falta de precisin.

Incorrecta representacin simblica de una expresin.

Tomando en cuenta los errores antes mencionados, las pruebas de unidad debendescubrir errores como:

Comparaciones entre tipos de datos distintos.

Operadores lgicos o precedencia incorrecta.

Igualdad esperada cuando los errores de precisin la hacen poco probable.

Variables o comparadores incorrectos.

Terminacin de bucles inapropiada o inexistente.

Fallo de salida cuando se encuentra una iteracin divergente.

Variables de bucle modificadas de forma inapropiadas.


11/23

Las pruebas de lmites son las ltimas y probablemente las ms importantesdentro de las pruebas de unidad, ya que normalmente un software falla en suscondiciones lmites, o sea, cuando sus datos son tratados a n repeticiones. Loscasos de prueba que ejercitan las estructuras de datos, el flujo de control y losvalores de datos por debajo, en y por encima de los mximos y los mnimos son

muy apropiados para descubrir este tipo de errores.

Pruebas de Validacin

Tras la culminacin de las pruebas de integracin, el software est completamenteensamblado como un paquete; se han encontrado y corregido los errores deinterfaces, y debe comenzar una serie final de pruebas del software -la prueba devalidacin. La validacin puede ser definida de muchas formas, pero una simpleindicacin es que la validacin se logra cuando el software funciona de acuerdocon las expectativas razonables del cliente. En este punto, un realizador desoftware estricto podra protestar: Quin o qu es el rbitro de las expectativas

razonables?

Las Expectativas razonables estn definidas en la Especificacin deRequerimientos del Software. Las especificaciones contienen una seccindenominada Criterios de Validacin. La informacin contenida en esa seccinforma la base de la aproximacin a la prueba de validacin.

Criterios de Validacin

La validacin del software se consigue mediante una serie de pruebas de cajanegra que demuestre la conformidad de los requerimientos que fueron entregadoscon anterioridad. Un plan de prueba traza las pruebas que han de llevarse a cabo,y un procedimiento de prueba define los casos de pruebas especficos que seaplicaran para demostrar la conformidad de los requerimientos.

Una vez que se procede con cada uno de los casos de prueba de validacin,puede darse uno de dos condiciones

1. Las caractersticas de funcionamiento o de rendimiento estn de acuerdocon las especificaciones y son aceptadas.

2. Se descubre una desviacin de la especificacin y se crea una lista dediferencias. Las desviaciones o errores descubiertos en esta fase delproyecto raramente se pueden corregir antes de terminar el plan. A menudoes necesario negociar con el cliente un mtodo para resolver lasdiferencias.

Pruebas alfa y beta:

Es virtualmente imposible que un encargado del desarrollo pueda prever como uncliente usar realmente un programa, se puede interpretar mal las instrucciones de


12/23

uso, se pueden usar regularmente extraas combinaciones de datos y una salidaque puede estar clara para el que realiza la prueba pero puede resultar ininteligiblepara un usuario normal.

Al memento de construir un software a medida se llevan a cabo una serie de

pruebas de aceptacin para que el cliente valide todos los requerimientos. Estaspruebas pueden tener lugar a lo largo de semanas o meses, descubriendo as,errores acumulados que podran degradar el sistema.

Si el software se desarrolla como un producto para muchos clientes, no es practicorealizar pruebas de aceptacin para cada una de ellos. La mayora de losconstructores de productos de software llevan a cabo un proceso denominadopruebas alfa y beta para descubrir errores que parezcan que solo el usuario finalpueda descubrir.

La prueba alfa es conducida por un cliente en el lugar de desarrollo. Se usa el

software de forma natural, con el encargado del desarrollo mirando por encimadel hombro del usuario y registrando errores y problemas de uso. Las pruebasalfa se desarrollan en un entorno controlado.

La prueba beta se lleva a cabo en uno o ms lugares de clientes por los usuariosfinales del software. A diferencia de la prueba alfa, el encargado del desarrollonormalmente no est presente. As, la prueba beta es una aplicacin en vivo delsoftware en un entorno que no puede ser controlado por el equipo de desarrollo. Elcliente registra todos los problemas (reales o imaginarios) que encuentra durantela prueba beta e informa a intervalos regulares al equipo de desarrollo. Comoresultado de los problemas anotados durante la prueba beta, el equipo dedesarrollo del software lleva a cabo modificaciones y as prepara una versin delproducto de software para toda la base de clientes.

Pruebas de Recuperacin

Muchos sistemas basados en computadoras deben recuperarse de los fallos yresumir el procesamiento en un tiempo previamente especificado. En algunoscasos un sistema debe ser tolerante a fallos, o sea, los fallos de procesamiento nodeben hacer que cese el funcionamiento de todo el sistema. En otros casos, sedebe corregir un fallo del sistema en un determinado periodo de tiempo a riesgoque se produzca un serio dao econmico.

La prueba de Recuperacin es una prueba de sistema que fuerza el fallo delsoftware de muchas formas y verifica que la recuperacin se lleva a caboapropiadamente. Si la recuperacin es automtica hay que evaluar la correccinde la re inicializacin, de los mecanismos de recuperacin del estado del sistema,de la recuperacin de datos y del re arranque. Si la recuperacin requiere laintervencin humana hay que evaluar los tiempos medios de reparacin paradeterminar si estn dentro de los lmites aceptables.


13/23

Pruebas de Seguridad:

Estas pruebas intentan verificar que los mecanismos de proteccin incorporadosen el sistema, lo protejan, de hecho, de la penetracin impropia. Durante la pruebade seguridad, el encargado de la prueba juega el papel de un individuo que desea

penetrar el sistema. Todo vale! Debe intentar hacerse con las claves de accesopor cualquier medio externo del oficio; debe atacar el sistema con cualquiersoftware a medida, diseado para romper cualquier defensa que haya sidoconstruida; debe bloquear el sistema, negando as el servicio a otras personas;debe producir a propsito errores del sistema, intentando penetrar durante larecuperacin; o debe curiosear en los datos pblicos intentando encontrar lasclaves de acceso al sistema.

Con el suficiente tiempo y los suficientes recursos, una buena prueba deseguridad termina por penetrar el sistema. El papel del diseador del sistema eshacer que el costo de la penetracin sea mayor que el valor de la informacin

obtenida mdiate la penetracin.

4.2.1. Integracin.

Se prueban la respuesta de grupos de mdulos interconectados a fin de detectarfallos resultantes de la interaccin entre los componentes.Las pruebas de integracin se realizan con referencia a las especificaciones delprograma. La principal dificultad de las pruebas de integracin es laLocalizacin de los fallos. Para facilitar la deteccin de los errores se utilizantcnicas incrementales.

Prueba de Integracin: Dando un caso como ejemplo, una persona despus determinar las pruebes de unidad en todos los mdulos que intervienen en elprograma y que estos los hayan pasado sin ningn problema, podra considerarque el programa en su totalidad debera funcionar sin problemas; lo cual no escierto, porque uno es fusin total de todos los mdulos que fueron probados demanera independiente que fueron probados de una sola vez, nos producira elconcepto de Big-Bang y es casi seguro que se llegar a un caos total debido a quelos errores producidos sern muy difcil aislarlos y a su vez corregirlos. A esteconcepto se aplica la prueba de integridad con la finalidad de producir la anttesisde Big-Bang.

Las pruebas de integracin atacan directamente a un acoplamiento paulatino delos mdulos anteriormente probados, este tipo de prueba maneja dos conceptosfundamentales.

4.2.1.1. Descendente.

Integracin Descendente. Esta ataca directamente a la implementaron de losmdulos desde el programa principal hacia los mdulos inferiores de manera

jerrquica. El modo de funcionamiento consiste en que el mdulo de control


14/23

principal maneje toda la informacin de las pruebas y las distribuya directamente alos mdulos que se encuentren inmediatamente subordinados, y a su vez estosvan realizando el mismo procedimiento a sus mdulos dependientes. Hay quetener presente que las pruebas se tienen que realizar cada vez que se vaincorporando un nuevo mdulo.

La estrategia descendente suena relativamente fcil, pero en la realidad puedenproducirse algunos problemas logsticos que podran llegar a repercutir en losresultados de nuestras pruebas, esto se refiere a, que ocurrira si un mdulo denivel jerrquico superior depende de clculos realizados en un mdulo de nivelinferior. El encargado de realizar la prueba tiene tres opciones ante estaproblemtica:

Retrasar muchas de las pruebas hasta que se fusionen los mdulosfaltantes.

Realizar resguardos que realicen funciones limitadas que simulen los

mdulos reales. Integrar el software desde el fondo de la jerarqua hacia arriba.

La primera aproximacin hace que perdamos cierto control sobre lacorrespondencia de ciertas pruebas especficas con la incorporacin de estosmdulos y por ende el control que realicemos no ser tan exacto y acabado,adems de producir incongruencia en los resultados, por ende, dificulta ladeterminacin de la causa del error y tiende a violar la naturaleza altamente derestrictiva de la aproximacin descendente. La segunda aproximacin es factible,pero puede llevar a un significativo incremento del esfuerzo a medida que losresguardos se hagan ms y ms complejos.

4.2.1.2. Ascendente.

Las pruebas de integracin ascendente, como su nombre lo indica, consistebsicamente en tratar el mdulo atmico (mdulo de nivel jerrquico ms bajo)hacia arriba. Dado que los mdulos son integrados de abajo hacia arriba, eprocesamiento requerido de los mdulos subordinados siempre est disponible yse elimina la necesidad de resguardo.

Una estrategia de integracin ascendente puede ser implementada mediante lossiguientes pasos:

Se combinan los mdulos de bajo nivel en grupos que realicen una funcinespecfica del software.

Se escribe un conductor (Programa de control de la prueba) para coordinarla entrada y la salida de los casos de prueba.

Se prueba el grupo. Se eliminan los conductores y se combinan los grupos movindose hacia

arriba por la estructura del programa.


15/23

A medida que la integracin progresa hacia arriba, disminuye la necesidad deconductores de pruebas separados. De hecho si los niveles superiores delprograma se integran de forma descendente, se pueden reducir sustancialmenteen nmero de conductores y se simplifica enormemente la integracin de grupos.

Hay muchas discusiones sobre las ventajas y desventajas de las pruebas deintegracin ascendentes frente a las descendentes, pero los que tenemos quetener claro, que se lleg a la conclusin que las ventajas de una, son lasdesventajas de la otra.

La seleccin de un tipo de prueba de integracin depender directamente delsoftware y a veces del plan del proyecto. En general el mejor compromiso puedeser una aproximacin combinada (a veces denominada prueba sndwich) que usela descendente para los niveles superiores de la estructura del programa junto conla ascendente para los niveles subordinados.

A medida que progresen las pruebas de integracin, el encargado debe identificarlos mdulos crticos. Un mdulo crtico es aquel que tiene una o ms de lassiguientes caractersticas:

Est dirigido a varios requerimientos del software.

Tiene un mayor nivel de control (Reside relativamente alto en la estructuradel programa).

Es complejo o propenso a errores.

Tiene unos requerimientos de rendimientos muy definidos.

Los mdulos crticos deben ser probados lo antes posible. Adems las pruebas deregresin se deben centrar en el funcionamiento de los mdulos crticos.

4.2.1.3. Regresin.

Cualquier tipo de pruebas de software que intentan descubrir nuevoserrores inducidos por cambios recientemente realizados en partes de la

aplicacin que anteriormente al citado cambio no eran propensas a estetipo de error.

Volver a ejecutar un subconjunto de pruebas que se han llevado a caboanteriormente para asegurarse de que los cambios no han propagadoefectos colaterales no deseados.

La prueba de regresin es la actividad que ayuda a asegurar que loscambios no introducen un comportamiento no deseado o erroresadicionales.


16/23

Cada vez que se aade un nuevo mdulo como parte de una prueba deintegracin, el software cambia.

Se establecen nuevos caminos de flujo de datos.

Pueden ocurrir nuevas E/S.

Se invoca una nueva lgica de control.

Estos cambios pueden causar problemas con funciones que antestrabajaban perfectamente.

La prueba de regresin es una estrategia importante para reducir efectoscolaterales. Se deben ejecutar pruebas de regresin cada vez que serealice un cambio importante en el software (incluyendo la integracin denuevos mdulos).

El conjunto de pruebas de regresin contiene tres clases diferentes de casos deprueba:

Una muestra representativa de pruebas que ejercite todas las funciones delsoftware.

Pruebas adicionales que se centran en las funciones del software que sevan a ver probablemente afectadas por el cambio.

Pruebas que se centran en los componentes del software que hancambiado.

Tipos de regresin segn el mbito:

Local-Los cambios introducen nuevos errores en un mdulo concreto.

Desenmascarada-Los cambios revelan errores previos.

Remota-Los cambios vinculan algunas partes del programa (mdulo) eintroducen errores en ella.

4.2.2. Validacin.

La validacin se refiere a la construccin de un modelo correcto. La validacin esel proceso de determinar si el modelo, como abstraccin, es una buenarepresentacin del sistema.Usualmente la validacin se consigue a travs de la calibracin del modelo, en unproceso iterativo de comparacin del comportamiento del modelo con el delsistema y usar las diferencias entre ambos para mejorar el modelo. Este proceso

se repite hasta que el modelo se considera aceptable.

Las pruebas de validacin en la ingeniera de software son el proceso de revisinque verifica que el sistema de software producido cumple con las especificacionesy que logra su cometido. Es normalmente una parte del proceso de pruebas desoftware de un proyecto, que tambin utiliza tcnicas tales como evaluaciones,inspecciones y tutoriales. La validacin es el proceso de comprobar que lo que seha especificado es lo que el usuario realmente quera.
http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_softwarehttp://es.wikipedia.org/wiki/Softwarehttp://es.wikipedia.org/wiki/Pruebas_de_softwarehttp://es.wikipedia.org/wiki/Pruebas_de_softwarehttp://es.wikipedia.org/wiki/Cursillohttp://es.wikipedia.org/wiki/Usuariohttp://es.wikipedia.org/wiki/Usuariohttp://es.wikipedia.org/wiki/Cursillohttp://es.wikipedia.org/wiki/Pruebas_de_softwarehttp://es.wikipedia.org/wiki/Pruebas_de_softwarehttp://es.wikipedia.org/wiki/Softwarehttp://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software


17/23

4.2.2.1. Alfa.

Prueba alfa:

Se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software deforma natural con el desarrollador como observador del usuario y registrando los

errores y problemas de uso. Las pruebas alfa se llevan a cabo en un entornocontrolado.

4.2.2.2. Beta.

Prueba beta:

Se llevan a cabo por los usuarios finales del software en los lugares de trabajo delos clientes. A diferencia de la prueba alfa, el desarrollador no est presentenormalmente. As, la prueba beta es una aplicacin en vivo del software en unentorno que no puede ser controlado por el desarrollador. El cliente registra todoslos problemas que encuentra durante la prueba beta e informa a intervalosregulares al desarrollador.

4.2.3. Sistema.

Antes del proceso de la implantacin del sistema es necesario un periodo de

prueba para poder determinar si an existen problemas no resueltos y no hacer un

doble trabajo de acondicionamiento al sistema.

Un problema tpico es la delegacin de culpabilidad, esto ocurre cuando se

descubre un error y cada uno de los creadores de cada elemento del sistema echa

la culpa del problema a los otros. Se debe anticipar a los posibles problemas y:

1. Disear caminos de manejo de errores que prueben toda la informacin

procedente de los elementos del sistema.

2. Llevar a cabo una serie de pruebas que simulen la presencia de datos en

mal estado o de otros posibles errores en la interfaz del software.

3. Registrar los resultados de las pruebas como evidencia en el caso de que

se le seale con el dedo.

4. Participar en la planificacin y el diseo de pruebas del sistema para

asegurarse de que el software se prueba de forma adecuada.


18/23

4.2.3.1. Recuperacin.

La prueba de recuperacin es una prueba del sistema que fuerza el fallo del

software de muchas formas y verifica que la recuperacin se lleva a cabo

apropiadamente. Si la recuperacin es automtica hay que evaluar la correccinde la inicializacin, de los mecanismos de recuperacin del estado del sistema, de

la recuperacin de datos y del proceso de re-arranque. Si la recuperacin requiere

la intervencin humana, hay que evaluar los tiempos medios de reparacin (TMR)

para determinar si estn dentro de unos lmites aceptables.

4.2.3.2. Seguridad.

Este acceso al sistema incluye un amplio rango de actividades: piratas

informticos que intentan entrar en los sistemas por deporte, empleados

disgustados que intentan penetrar por venganza e individuos deshonestos que

intentan penetrar para obtener ganancias personales ilcitas.

La prueba de seguridad intenta verificar que los mecanismos de proteccin

incorporados en el sistema lo protegern, de hecho, de accesos impropios.

4.2.3.3. Resistencia

Permite observar la demanda que tiene el sistema en cuanto a cantidad de

recursos, la prueba de resistencia ejecuta un sistema de forma que demande

recursos en cantidad, frecuencia o volmenes anormales. Por ejemplo:

1. Incrementar las frecuencias de datos de entrada en un orden de magnitud

con el fin de comprobar cmo responden las funciones de entrada.

2. Disear pruebas especiales que generen diez, interrupciones por segundo,

cuando las normales son una o dos.

3. Ejecutar casos de prueba que requieran el mximo de memoria o de otrosrecursos.

4. Disear casos de prueba que puedan dar problemas en un sistema

operativo virtual.


19/23

Los tipos de resistencia a las cuales se somete el sistema son:

Diseo de pruebas sobre interrupciones por segundo.

Aumento de la frecuencia de datos de entrada.

Pruebas que requieran uso excesivo de memoria u otro recurso.

Pruebas sobre el sistema operativo u otro software. Crear excesivas bsquedas de datos.

4.2.3.4. Rendimiento

La prueba de rendimiento est diseada para probar el rendimiento del software

en tiempo de ejecucin dentro del contexto de un sistema integrado.

La prueba de rendimiento se da durante todos los pasos del proces de la prueba.

Incluso al nivel de unidad, se debe asegurar el rendimiento de los mdulosindividuales a medida que se llevan a cabo las pruebas de caja blanca. Sin

embargo, hasta que no estn completamente integrados todos los elementos del

sistema no se puede asegurar realmente el rendimiento del sistema.

La prueba en el contexto de espiral


20/23

4.3. Mantenimiento.

4.3.1. Concepto.

El mantenimiento de un sistema es la continuacin del ciclo de vida, luego dehaber completad una versin de este. Aunque parte del objetivo es resolverproblemas, durante el mantenimiento se deben consideran las extensiones delsistema de acuerdo con las nuevas necesidades. De cierta manera, elmantenimiento significa seguir un nuevo ciclo de actividades de desarrollo, pero apartir de un sistema existente.

4.3.2. Objetivo.

La capacidad de mantenimiento es la habilidad que se tiene para realizar cambiosal producto en el tiempo y la capacidad de actualizacin es la habilidad que setiene para entregar las versiones del producto a bajo costo a los clientes con unmnimo de tiempo de descarga. Una caracterstica clave para apoyar este objetivoes la descarga automtica de parches o actualizaciones y actualizaciones delequipo del usuario final. Tambin debemos utilizar formatos para archivos dedatos que incluyan suficientes metadatos para permitirnos trasformar conseguridad la informacin existente del usuario durante una actualizacin.

Es la ltima fase del Ciclo de Vida de Desarrollo de Sistemas, en donde los SI son

sistemticamente reparados y mejorados.

Por definicin, el proceso de mantenimiento de un SI es un proceso de

devolucin al principio del Ciclo de Vida y de repeticin de los pasos de desarrollo

para la implementacin de cambios.

Las 4 actividades ms importantes que ocurren dentro del mantenimiento son:

Obtencin de los requerimientos de mantenimiento.

Transformacin de los requerimientos en cambios.

Diseo de los cambios.

Implementacin de los cambios.


21/23

4.4. Caractersticas del mantenimiento.

Con posterioridad a la fase de implementacin de los sistemas, se impone la fase

de mantenimiento.

El mantenimiento de sistemas es el mantenimiento continuo despus del inicio del

funcionamiento.

Cuando se elaboran planes para la estrategia de informacin, las organizaciones

no pueden dejar de considerar que el mantenimiento de sistemas es la fase ms

prolongada y costosa del ciclo de vida de los sistemas. Las implicaciones del

volumen de trabajo para mantenimiento para los planes de estrategia de

informacin en una organizacin es un tema que merece atencin especial. La

estructura de organizacin necesita flexibilidad para apoyar el mantenimiento de

los sistemas existentes concurrentemente con la ejecucin de nuevas tecnologas.

Es importante considerar la evaluacin y el monitoreo de un sistema en trminosdel mantenimiento necesario y, en consecuencia, reducir o contener los costos

implcitos.

4.4.1. Costos.


22/23

4.4.2. Efectos.

4.4.3. Tipos. 4.4.3.1. Correctivo.

Mantenimiento correctivo. Independientemente de cun bien diseado,

desarrollado y probado est un sistema o aplicacin, ocurrirn errores

inevitablemente. Este tipo de mantenimiento se relaciona con la solucin o la

correccin de problemas del sistema. Atae generalmente a problemas no

identificados durante la fase de ejecucin. Un ejemplo de mantenimiento correctivo


23/23

es la falta de una caracterstica requerida por el usuario, o su funcionamiento

defectuoso.

Correctivo: son aquellos cambios precisos para corregir errores del producto

software.

4.4.3.2 Preventivo/perfectivo.

Mantenimiento preventivo. Este tipo de mantenimiento es probablemente uno de

los ms eficaces en funcin de los costos, ya que si se realiza de manera oportuna

y adecuada, puede evitar serios problemas en el sistema.

Perfectivo: son las acciones llevadas a cabo para mejorar la calidad interna de lossistemas en cualquiera de sus aspectos: reestructuracin del cdigo, definicinms clara del sistema y optimizacin del rendimiento y eficiencia.

4.4.3.3. Adaptativo.

Adaptativo: son las modificaciones que afectan a los entornos en los que elsistema opera, por ejemplo, cambios de configuracin del hardware, software debase, gestores de base de datos, comunicaciones, etc.

4.4.4.4. Actividades.

Unidad IV Desarrollo e Implemetacion de SI

Documents

Transcript of Unidad IV Desarrollo e Implemetacion de SI